I'm developing software for a university satellite project, and am currently working on the communications protocols. Here are the restrictions:
- Radio packets should be assumed to be no larger than 256 bytes
- Radio packets should incorporate some sort of forward error correction
- 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?