Monday, 15 October 2012

Cubesat packet authentication with HMAC

Cubesats typically transmit telemetry and scientific measurements back to Earth without any security mechanisms. While this has been ok so far, it is fundamentally insecure. There is nothing to stop an adversary from fabricating packets that appear to be from the spacecraft but actually contain incorrect data. Incorrect data may cause confusion or even undermine the mission.

Luckily, there is a simple method to protect against this called Hash-based Message Authentication Code (HMAC). HMAC is widely used on the internet today as part of TLS (HTTPS) and IPsec. There are many open-source implementations available (some are listed at the end of this post).

HMAC works using a cryptographic hash function and a secret key known only to the spacecraft and its operator. For each data packet, the hash function is computed over a concatenation of the data and the secret key. The result is appended to the packet when it is transmitted. When the packet is received by the operator, they can run the same hash procedure again to verify that the sender knew the secret key. It's impossible for an adversary to fabricate a packet since they don't know the secret key (and they can't infer it because we used a cryptographic hash function).


Naturally, the Carpcomm Ground Station Network is compatible with HMAC packets. Since the network processes raw packets regardless of their contents, satellite operators can easily include HMAC. Furthermore, our telemetry decoding system is flexible enough to include HMAC authentication of packets if desired.

Example. Suppose that
key = "secret" = 73 65 63 72 65 74,
data = "packetid:42" = 70 61 63 6b 65 74 69 64 3a 34 32,
hash function = SHA-256.
Then the HMAC is
1b cb 5c ad 3c 9b 2b c4 58 81 ec 54 2b 21 58 0c
c6 85 d9 f3 60 b7 0e 99 a8 5e 1c a2 4f 8c c0 4d.
Since this is quite long, it can be truncated e.g. by taking the leftmost 8 bytes.
Truncated HMAC = 1b cb 5c ad 3c 9b 2b c4
These bytes would then be appended to the packet when it is transmitted.

The Consultative Committee for Space Data Systems (CCSDS) recommends using a SHA-256-based HMAC. They also recommend not truncating the HMAC. However, some truncation is probably needed for cubesats to avoid overhead.

There is another issue that HMAC alone does not solve: replay attacks. In this scenario, an adversary resends an old packet with data from a year before. Since they are making an identical copy, they can keep the original HMAC and the packet will still authenticate. To protect against this, it's advisable to include a timestamp or packet counter within the data. Then if an old packet is resent, it's obvious that it's old.

HMAC standards and recommendations:
Open-source HMAC implementations:

No comments:

Post a Comment