[Cryptography] Simple IoT sensor encryption ?

[Henry Baker]

Suppose we have some relatively simple, cheap IoT *sensors* with an SoC processor with perhaps AES capabilities.

We consider only send-only sensors here, because the authentication requirements on *actuators* should be far, far stronger.

For simplicity, this sensor is single-threaded in its communications with a data repository in the "cloud".

Threat model: since the sensors are cheap & widely distributed, we have to assume that anyone can get physical access to such a sensor & perform any amount of analysis on it that s/he wants.  Furthermore, the data channels between the sensor and the data repository are available for everyone to see -- e.g., wireless transmission, with the possibility of MITM attacks.

So it is obvious that the system is most secure if it contains no *secrets*, at all.

This situation is a perfect case for public key crypto: the sensor contains only the *public key* needed to encode the data, but it has no capability to decode the data.  We can watch the sensor all we want, we can single step it if we want, and all we will learn is that particular sensor measurement and the *public* key; but since we have physical access, we could have done the measurement ourselves and the public key is already public!

The sensor can obviously be jammed and/or spoofed (including MITM spoofing), but the information from a legitimate sensor is protected by the public key crypto system -- assuming that the information eventually arrives at the data repository and is somehow authenticated.  We leave the authentication problem aside for the moment.

So, the obvious implementation has the sensor storing only the data repository's public key, and the sensor encrypts its information using this public key and passes it along.

(We also ignore the problem of revoking the public key of the data repository.)

First problem: the computational requirements of full public key encryption could overwhelm the cheap little IoT CPU.

So this means that we may have to encrypt with a symmetric key system -- e.g., AES -- and somehow encrypt this AES key with the public key, and then send the pair (PK-encrypted symmetric key, AES-encrypted data) to the data repository.

But now we have a problem, because the little sensor now has an AES key secret that it can be forced to divulge.

Ok, so now we have 2 choices: engage in a DH exchange with the repository or utilize random numbers.

Using a DH exchange is a real problem due to 1) latency and 2) we now need the little sensor to be able to *receive* data from the data repository, which complicates the system enormously and opens up whole new vistas of attack surfaces.  It also doesn't solve the problem of fully protecting the session keys so negotiated from physical attacks.

So the sensor decides to use a random number generator.  If it generates a random AES key every time it starts up, then it can PK-encode this AES key and send it along with the AES-encoded data.

However, our little CPU can now be compromised in any number of ways: someone can watch and/or glitch its power supply, so that it reveals its secrets.  Someone could conceivably deduce the current AES key from these power supply variations.

We can also periodically (e.g., 1x per second or 1x per hour) generate new AES keys and send along the PK-encrypted new AES keys.  This at least might provide perfect forward secrecy so that future data isn't compromised.

But we haven't been able to *emulate* all of the features of public key crypto for our particular threat model using a combination of public & symmetric key crypto.

--

Should we just "bite the bullet" and brute force PK-encrypt all the sensor data?  This works, although it may use a heck of a lot more power, and may doom this scheme to quite low-bandwidth signals.

Or is there a more elegant way that doesn't also make the sensor vulnerable to physical attacks?