Encrypting and Authenticating The Simplex Communication Between Embedded Devices

Question

I am planning to build temperature sensor nodes for my home heater control. Central device will control the heater using temperature data read by nodes. These nodes will send temperature data to central device over RF communication periodically. There will be no acknowledge from central device to nodes. I want to learn something about encrypted communication at the same time. I have little general knowledge and no experience about encryption.

It is common that today microcontrollers have built-in cryptographic engine supporting AES with ECB, CBC, OFB, CTR and CFB128 modes with true random number generator. (ref)

I have two goals:

1. Communication should be encrypted. Attacker can't read the temperature value by sniffing.
2. Once a node sends a encrypted message, this messages should become invalid for retransmission. For example, each message should be different even if a node transmits the same temperature value. Attacker can't act as a true sensor node by transmiting false temperature values to my heater.

My questions are: (Please consider that I have no background in cryptography.)

1. Encryption is not so hard. For example, I may use AES-128. But simple ECB mode doesn't satisfy my goal #2. If temperature doesn't change, AES-128 output will also be the same. AFAIU I should use encryption + authentication. I have to ensure that encrypted message is sent from a valid node not from an attacker. Is authentication term is the correct one for this case? For example, does AES-CCM overcome this problem? I read several sources about AES-CCM and other encryption + authentication methods and I couldn't correlate my problem with the authentication term used in cryptography.

2. Let's say that node increments a counter by one at each transmission. Plain data is now value of counter + temperature. Plain data is encrypted and sent. Counter ensures that data changes even if temperature is the same. Receiver now tracks value of the counter and ignores the message if it is not incremented by one (or within a range). It should help me to satisfy goal #2. I think this approach is similar to Keeloq algorithm. Attacker shouldn't guess the next encrypted text easily. Does it make sense?

3. Hardware has true random number generator. Can it be used somehow to make communication more "secure"? For example plain text = value of counter + data + some random bits. Does random bit stuffing make any improvement?

4. Probably my ideas are the worst ones. What would you suggest for data validation? How can a node "sign" its data?

Answer 1

For my answer, I'll assume that you have symmetric keys pre-shared between your heater and your sensors. If your devices have enough computational power to support asymmetric cryptography (which will increase workload by a large factor and message length by at least 32 bytes) the answer will be different (and provide stronger guarantees).

1. AES-128 CCM is a good choice for your use-case because your hardware supports the required primitives, e.g. AES-CTR and AES-CBC.
   Authentication in cryptography means ensuring the correct source of information. If information is tampered in transit, the tampering party is the new source. Assuming you pre-share the symmetric keys in advance, AES-CCM will ensure the data actually came from a party holding the key or otherwise return an error upon decryption.
2. Actually you can do better than that. AES-CCM requires a so-called (12-byte) nonce for operation for each message. This nonce only needs to be unique to provide the full security guarantees and so you can define the nonce to be a counter whereby the nonce gets incremented by one each message. If a too-small counter (IV) arrives, you can simply reject the message. You only need to ensure that the length field for CCM is long enough to describe your message length (4 bytes would be good).
3. Sadly no. If you use pre-shared keys, there's no further need for randomization from the cryptographic side of things. If you'd involve asymmetric cryptography, the RNG would actually prove useful (for generating temporary keys and such).
4. The best solution would be for your nodes to actually digitally sign the data they send, assuming the heater has the public keys in advance, so he can validate the signatures. However, such signatures tend to be computationally expensive and so may not be an option for you.