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.
