Embedded System Communications Security

Question

I am getting ready to start deploying an embedded sensor network that is internet connected (via the cell network) and reports private data on a regular basis back to a central server. Unfortunately, the device has neither the connectivity (very high latencies) nor the processing power to use SSL, so I think I am left to come up with something myself, in violation of rule #1 of cryptography.

What I have come up with:

We have essentially three channels (out-of-band commands, http requests to the internet, http responses), so will store three independent keys (generated randomly during assembly) on a per-device basis.

HTTP data is encrypted as E(iv, key, payload || H(key, payload)) where E is AES 128 in CBC mode and H is a SHA256 HMAC. On the embedded side iv is generated as H(current time) and transmitted in the clear, along with the device's unique id for selecting the correct key. There is no RNG on the microcontroller so I'm doing the best I can for the IV. Is that good enough?

Since commands are not private but need to be authenticated, they are transmitted as payload || H(key, payload) using a different key than HTTP requests or responses.

I know getting this right is really hard, am I missing anything obvious or do I have any details wrong?

Answer 1

To see what others have done in this space, you can look at the following systems:

• MiniSec is an encrypted packet format for low-power embedded devices. It represents approximately the state-of-the-art in this area, and is well-designed. See the following research paper:

  • MiniSec: A Secure Sensor Network Communication Architecture. Mark Luk, Ghita Mezzour, Adrian Perrig, and Virgil Gligor. IPSN 2007.

• 802.15.4 (Zigbee) has a packet format for encrypted communications among low-power embedded devices. It is pretty well-designed, though there are a few details you need to watch out for. See the following security analysis of 802.15.4:

  • Security Considerations for IEEE 802.15.4 Networks. Naveen Sastry and David Wagner. ACM Wireless Security 2004.

• TinySec is a packet encryption scheme for encrypting in sensor networks. It is pretty old, does not provide replay protection, and uses a simplistic key management approach that may not be suitable for your setting. See the following research paper:

  • TinySec: A Link Layer Security Architecture for Wireless Sensor Networks. Chris Karlof, Naveen Sastry, and David Wagner. ACM SenSys 2004.

Here are some possible weaknesses I spotted in your scheme (this is answering only "do I have any details wrong?", not "what should I do?".):

• You are using the same key for both encryption and authentication. Not a good idea.

• You are using authenticate-then-encrypt. That's got security weaknesses. Whether those are a problem in practice will depend upon the specifics of your packet format. However, at least in some plausible instantiations of your scheme, there will be chosen-ciphertext attacks. For instance, with some padding schemes you will be vulnerable to padding oracle attacks.

• You have no protection against replay.

What you should do:

• Use SSL.

• Or, if you can't use SSL: follow Thomas Pornin's advice or follow in the footsteps of one of the systems I mentioned above -- and in either case hire a cryptographer as a consultant to make sure you got it right.

Answer 2

I'd reexamine the point about not having the connectivity to use SSL; I don't know how often the connections are established, but any modern SSL stack that supports resumes would only impose an extra couple of packets of overhead after the initial handshake. As for not having the horsepower to run the crypto, again, you should seriously double-check that assumption. I haven't tried to parse your design, since I stick to standards-based crypto at all costs, but you'd have to make a strong argument that you don't have any fundamental need for the things that SSL is doing. If you don't use SSL, you'll have to do something to authenticate your peer, and a static pre-shared key, if that's your answer, is begging for trouble. How will you update the key if it's compromised?

Use SSL.

Answer 3

First, you should define precisely what kind of attack you are trying to defend against:

• Do you fear attackers who spy on the messages exchanged between the sensor and the server, and learn the contents of the messages ?
• Do you fear attackers who impersonate the server and talk to the sensor as if they were the server ?
• Do you fear attackers who impersonate the sensor, and send fake requests to the server ?
• Do you fear attackers who drop, duplicate, replay and reorder messages between client and server ?

A symmetric-only lightweight protocol which covers all of the above -- to some extent -- looks like this:

• For any communication channel between the sensor and the server, there are two symmetric keys which both the server and the sensor know, one for data sent by the server to the sensor, and one for data sent by the sensor to the server.
• Every message sent by either the server or the sensor is encrypted with AES in EAX mode.
• EAX mode requires a non-repeating IV; the sensor and the server will use counters.
• Each message contains the IV (counter value) for that message, followed by the AES-EAX encryption of the message.
• For each communication channel, the sensor stores the current counter value for the message it sends, and the IV of the last message it received from the server over that channel.
• When it sends a new message, the sensor increments its counter (for that channel), stores the new value, and then (only then) uses the new value as IV for AES-EAX.
• When it receives a message from the server, the sensor checks that the new message uses an IV which is strictly greater than the last received from the server; the sensor stores that new IV and then (only then) decrypts and processes the message from the server.
• The server employs the same techniques than the sensor (counter for the messages it send, saved IV from the last message from the sensor, and so on).

Assuming that counters start at 0, this means that the first message that the sensor will send will use 1 as IV; the second message will use 2, and so on. Similarly for the messages sent by the server. This enables the server and the sensor to detect replayed messages, out-of-order messages, and missing messages; what they should do in such a case is up to you to decide.

On EAX: combining encryption and MAC together with a given key is not completely easy. Reusing the same key for the encryption and the MAC is, theoretically, risky. An authenticated encryption mode such as EAX takes care of the fine details. As a fine bonus, EAX does not need uniformly random, unpredictable IV, as CBC does; it only requires IV values never to be repeated (for a given key), so a counter is fine -- as long as you can store the current IV value in a resilient way, and do it at the right time. Beware of an attacker switching the sensor off in order to force an IV reset !

On keys: I have talked here about bidirectional channels. You need one key per channel direction. This means two keys for the HTTP thing (one for requests, one for responses), and one key for the command channel, assuming it to be unidirectional (commands from the server to the sensor, no response from the sensor). If storing three 128-bit keys is problematic, you can store a single 128-bit key (a "master key") and dynamically rebuild the three keys from that, with a key derivation function. Since you are in a constrained environment, and EAX uses AES only, I suggest using AES for that too: using the master key as key, encrypt three fixed constant values (e.g. "0", "1" and "2") with a single raw AES invocation for each; this will yield three 128-bit blocks which will do fine as your channel keys.

On tamper resistance: I suppose that the sensors will be deployed "on the field", so an attacker may succeed in catching a sensor, opening it, and then trying to recover its logical contents. Unless the sensor is specially hardened against tampering (as a smartcard would be), this means that the attacker will be able to learn the sensor keys, and, from that moment, "emulate" the sensor as seen by the server. At a minimum, every deployed sensor should have its own keys, and the server will have to know the keys of all deployed sensors.