3

I'm developing software for a university satellite project, and am currently working on the communications protocols. Here are the restrictions:

  1. Radio packets should be assumed to be no larger than 256 bytes
  2. Radio packets should incorporate some sort of forward error correction
  3. Radio packets should be encrypted, if at all possible.

With this in mind, we've selected the Reed-Solomon forward error correction protocol, which provides 223 bytes of data for a message length of 255, adding in 32 parity blocks for up to 16 bytes of error recovery.

The primary contents of our transmissions will be based on an internally developed file transfer protocol that allows you to select the binary within a file into "chunks" for transmission. These chunks are restricted to be of length 223, per Reed-Solomon. The files we up- and down-link will be tar archives, containing mission schedules and shell scripts.

To allow us to multiplex to multiple satellite on the same frequency (or near enough that they might all receive a given packet), and to offer some protection against replay attacks, each "session" is given a 1 byte session ID, which must fall into a given satellite's allotted equivalence class in order for the satellite to pay heed. It must also be the next one in the sequence based on the size of the modulus we assign (16 in this case, to allow 16 sats on the same frequency). This will be part of the non-plaintext blocks we transmit.

We also have, per mission requirements, direct access to the shell through use of "command forwarding" packets, which essentially fill the 223 bytes with some metadata, and a string to be passed directly into the shell with root permissions. This is the huge hole in our current setup, but it cannot be made more restrictive, as we need maximal control over the satellite from the ground in emergency situations.

I just recently got approval to fly AES, which I believe I will use to encrypt these packets entirely, and prevent any unwanted access. We have full access to libcrypto from OpenSSL. I can include extra metadata to provide auhentication as well as the string to be executed in the shell, but we still need said string to be at least ~100 bytes long. All of this needs to fit into one radio packet, as we cannot be certain that packets will all make it to the radio on the other end.

I've been thinking we could use AES-192, as it would give us 216 encrypted bytes, leaving the last 7 bytes to go plaintext. We could even enforce those to be 0'ed out, or filled with data from a PRNG, but I'd like to keep them fully used if at all possible. The plaintext is probably even okay for transmitting chunks of binary files, the contents of which are mostly uniformly random according to my analysis.

Is there a tractable way to secure the root shell hole while still providing ourselves with a "decent" downlink rate?

  • 2
    Am I correct that you only fear that somebody can sniff the traffic but not that somebody can modify the data or sent their own? Because I can neither see a proper check to detect targeted modification (no MAC, error correction does not help here) nor can I see resistance against replay (no IV). – Steffen Ullrich Aug 7 '17 at 15:17
  • I'm worried that, given enough packets, someone could craft their own and target the satellite. Reed-Solomon leaves the data blocks unmodified, so if someone can learn the transmission protocol, they could potentially gain root access. We do have a replay resistance sort of thing, I'll add it to the post. I've not heard about MAC, maybe you could expand on that? – ijustlovemath Aug 7 '17 at 15:20
  • For MAC see en.wikipedia.org/wiki/Message_authentication_code. Using AES without MAC will happily decrypt anything as cipher text, i.e. will not notice changes to the cipher text but it will just result in a different plain text. – Steffen Ullrich Aug 7 '17 at 15:21
  • 1
    No, a MAC and a salt are completely different things - but it might be that you don't understand what a salt in password storage is used for (not for verification but to increase search space for brute force attacks). Apart from that to get to rm -r /; the attacker just has to brute force at most 8^8 messages - unless you change the encryption key with every shell error. – Steffen Ullrich Aug 7 '17 at 15:38
  • 2
    It is impossible to say what harm can be done when the attacker can sniff the last 7 bytes since it is unknown what information they might contain. If they contain for example a major part of a valuable secret it is probably a big problem if they can be sniffed. – Steffen Ullrich Aug 7 '17 at 15:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.