Cryptography Question

ezra_

Hello,

I have a question about crypto and satellites.

Reading the EIRSAT-1 thread on the Boards AMA, it is clear that the satellite is controlled by communication over amateur radio, but that commands are encrypted.

However, given that we know a) the encrypted message (it is public) and b) the response of the satellite to the command (this is public... I think).

Would it not be the case where the encrypted message itself can be repeated by a third party to alter the satellites position (or whatever), the plaintext itself is not actually needed and therefore unless there is a system of dynamic and unique salts (one per day, given there is a 6.5 minute daily window for commands to be received) going into the command, commands could be arbitraly echoed by a third party?

However, I'm a newb to all of this, so I'm sure I've missed something obvious

Razzen

What you are describing is a replay attack.

Most protocols include some unique element or nonce to prevent such attacks. This could be a sequence number, a time stamp, id etc. some element that allows the receiver to check if the message has already been received and can hence be ignored.

ezra_

Thanks for that, I wasn't aware of the term for it.

Given that

a) engagement with the satellite is by radio (and with low baud rates),
b) the team on the ground don't know for how long the satellite will be in orbit for (estimates from 9-24 months)
c) responses from the satellite will be in plaintext

Is it possible to prevent such an attack?

Unlike a TCP/IP engagement, I don't think that the team and the device can 'handshake' in the normal sense, which makes this harder to defend against?

ED E

All you need is a command number. As long as you send them sequentially the sat will never receive one before a predecessor. It might miss one, but you can account for that on the ground with the lack of a response.

Pick a datatype that allows larger numbers if you think you'll need them over 24 months, though that seems unlikely enough.

ezra_

ED E wrote: »

All you need is a command number. As long as you send them sequentially the sat will never receive one before a predecessor. It might miss one, but you can account for that on the ground with the lack of a response.

Pick a datatype that allows larger numbers if you think you'll need them over 24 months, though that seems unlikely enough.

thanks for that - so you'd have something like:

Message: encrypt(Command, Authentification Number)

Where for every command, the authentification number would have to increase by 1 (or something along those lines)

Very simple!

jmcc

You would have to establish the protocol first before figuring out how to compromise it. Some communications protocols may include an errorcheck or a packet hash as a security feature.

Regards...jmcc