I was thinking about the feasibility of one way remote control using radio signals. The sending hardware would be bound to a computer and therefore have enough computing power, while the reciever would be a limited hardware device that have some rudimentary computing power.

Putting aside the obvious drawbacks of one way communication (acknowledgement), would the proposition I have in mind be feasible.

  • The reciever has the private, and the sender has the public key
  • The sender sends a encrypted data stream containing a random string
  • The reciever decrypts the data
  • The sender uses the unencrypted string as header for the bulk data
  • The sender encrypts header+data and sends them to the reciever
  • The reciever can verify that the data is authentic

Problems(I assume that the channel will transfer the data without too much interference):

  • Acknowledgement(of course)
  • Repeating the same data streams from a third party

I thought about the second problem, and it came to mind that a time stamp could be helpful(put it into the header before encryption). But the reciever won't be connected to any network to update the time, so it would need a synchronised clock. I don't know if synchronisation through this channel would be a security risk.

I tried to find something on the internet regarding one way communication but haven't found anything very helpful. I tried to stick to the KISS principle, as I hoped it would be less error prone. What are your thoughts of the system? Are there any obvious flaws?

P.S. I'm no security expert, but I had some minimal stuff in some broad engineering courses though.

  • 1
    What is your threat model? Meaning: what are you trying to protect, and what are you trying to protect it from? May 2, 2014 at 15:39
  • For now it is theoretical, I wanted to know about the feasibility. I wanted to try to implement something like this, to learn about stuff and maybe do some non-critical automation with it. I don't expect attacks, but I want to make sure that no stray broadcasts trigger actions in the system. Some basic security is a nice thing too. Well security through obscurity will probably be the case anyway.
    – WalyKu
    May 2, 2014 at 16:59
  • Consider the case of satellite radio and satellite tv and how encrytion works in those cases.
    – Eric G
    May 2, 2014 at 23:33
  • I must admit I didnt't think about that. It is a well established system so it will be something worth considering. Thanks.
    – WalyKu
    May 3, 2014 at 0:23

2 Answers 2


For one-way communication you have three classes of issues to contend with:

  • Confidentiality: you want the messages to be unreadable by eavesdropper. Only the receiver (and possibly the sender) should be able to read the message.

  • Integrity and authenticity: you want the receiver to make sure that what it receives is indeed what the authentic sender sent. Thus, there must be reliable detection mechanisms for both alterations (message is modified while in transit) and impersonations (attacker sends a synthetic message that the sender never produced).

  • Replay, drop and reorder: an attacker could record genuine messages, sent at one time by the sender, and replay them to duplicate the effect. He could also block some messages. And he could combine both, so that the receiver obtains the messages in the wrong order.

For confidentiality, the receiver must store and use a secret value which embodies its power to actually read the data. This secret may be a simple symmetric key (a mere bunch of bytes) that the sender also knows; symmetric encryption is then used. If you don't want the sender to know that key (e.g. you have several senders, and no sender should be able to read the messages from other senders to the same receiver), then asymmetric encryption is to be used.

For integrity and authenticity, there is no escaping it: the sender must also own a secret, that attackers do not know. Otherwise, if there is nothing secret in the sender, then the sender can be perfectly emulated by any attacker, and you won't be able to prevent impersonation (i.e. in your description, the part about "the receiver can verify that the data is authentic" is wrong: the receiver cannot obtain that guarantee if the sender does not have and use some secret). If you used the "shared secret" principle with symmetric encryption, then the same secret could be used as part of a MAC to ensure that altered or forged messages are detected as such. There are nifty symmetric encryption modes (e.g. GCM or EAX) which combine encryption and MAC properly, using the same key for both. If you follow the asymmetric road, then the sender will also need a public/private key pair, and use signatures. The receiver will need to know the sender's public key with some guarantee that it is using the right one.

The asymmetric setup, where both sender and receiver have their own key pair, is the same model as the one used for emails in S/MIME and OpenPGP. One may note that asymmetric encryption can be "heavy" for the really small hardware. A 33 MHz ARM processor can grope asymmetric cryptography (it can do RSA, but it will be happier with elliptic curves); an 8-bit microcontroller will have trouble (so, if you use Arduino boards, ARM is OK for asymmetric crypto, AVR is not, unless you are very patient).

The defence against replay attacks is the hard part. Since the communication is one-way, you cannot defend against dropped messages by the attacker; the sender cannot know if his messages got through. However, you may be able to detect skipped messages on the receiver side. More generally, what you need is a stateful receiver: the receiver must maintain some memory of past messages, in order to detect foul play. The simplest method is to have a sequence number:

  • The message contents contain a numerical value. The sender increments that value for each message.
  • The receiver remembers the sequence number of the last received message.

That way, the receiver can detect dropped messages (there are "gaps" in the received sequence numbers), out-of-order messages, and replays.

Radio communication is supposed to be strongly ordered: messages won't arrive out of order under normal or even abnormal (but non-malicious) conditions. This is not true of all transport mediums; e.g. over the Internet, packets can be reordered, duplicated and dropped, and receivers must deal with it. The generic method is to maintain a window of "acceptable sequence numbers" (e.g. all numbers from n to n+9, for a window of size 10), and the receiver applies timeout strategies to know whether it should still wait for the missing messages, or just consider them as lost. In the case of radio, a simple sequence number is sufficient.

If the receiver cannot store permanently the last received sequence numbers, then time stamps can be used, but this requires the receiver to have a reasonably accurate clock, and it cannot use an external time source (because it could be faked by the attacker, because of one-wayness again). With a time stamp:

  • Each request has both a sequence number and a time stamp.
  • The receiver remembers temporarily (e.g. in RAM) the last received sequence number.
  • When a message is received and the receiver still remembers the last received sequence number, then it uses it to detect replay.
  • Otherwise, the receiver uses its clock and compares it to the time stamp to detect replay.

The sequence number + time stamp reliably prevents replay attacks provided that the receiver's clock accuracy is better than the hardware reboot latency. Meaning that if the receiver is reset, then it forgets the last received sequence number; if the reset is done within 5 seconds and the receiver's clock is accurate only to within 15 seconds of the current time, then there is a 10-second window during which replay is feasible. Depending on the context, this may or may not be a problem.


Public key cryptography is very resource intensive, if your receiving device has limited resources you would be much better off using lighter weight symmetric encryption like AES and using pre-shared keys. Use hashing for data integrity checks. I'd suggest you simplify:

  1. Send the AES encrypted data block
  2. Send a piece of random data
  3. Hash the encrypted block, then add the random data and hash again - send
  4. The receiver uses the random data to re-create the hash sent in step 3. If the self-generated one and the sent one match then the data block's integrity is good
  5. If the data integrity checks out decrypt the block

You can replace AES with whichever symmetric protocol you want, and you have a choice of hashes.

I think this is all a bit hypothetical though as you are going to have to solve numerous issues around the transfer of the data. IP, even UDP isn't designed for one-way radio transmissions, so you will need another way to get the data there. You will probably want to send the data several times in order to ensure delivery.

  • Thanks for the answer. Yes hardware will be a constraint, and the proposed approach would help alevitate that indeed. I'll see to the other aspects on later ocasion, I just wanted to see what the comunity thinks about the security aspect!
    – WalyKu
    May 2, 2014 at 18:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .