[Cryptography] Simple IoT sensor encryption ?

[sebastien riou]

> 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?
>

Let's take the use case mentioned by Christian:
> Simple threat: the attacker spoofs the cheap sensor, and convinces the system that it is really freezing in the master room. Based on that input, the system cranks the boiler way up. The people sleeping in the master room end up being cooked.

That highlights that even a sensor node needs a lot more than just a
public key. At least it needs to have a private key (symmetric or
asymmetric) to be able to prove its identity.

If the sensor can prove its identity, the attacker cannot simply
replace it with a fake one she controls.
The next level of attack would be to fool the sensing mechanism. This
is much more difficult to prevent and beyond the scope of crypto,
let's put that aside for now.

The sensor node has to keep at least one secret key, the only way to
deal with that is to store that key inside the chip and implement the
crypto with side channel and fault attacks countermeasures. This is
easier said than done but that's possible even on low end
micro-controllers (well depends on bandwidth requirements, the crypto
algo and the amount of RAM of course).

A word of caution about implementing such things: the published
countermeasures have a long history of being advertised as "provably
secure" only to be broken the next year so it is highly recommended to
hire an expert on that rather than taking a paper and try to follow it
(and very few paper address both side channels and fault anyway). This
is very much like cryptographers saying "don't make your own crypto",
I don't like saying or hearing that kind of thing nevertheless this is
so true. Last word of caution: stay away from any "expert" who don't
know how to perform those attacks.

There are also advanced lab attack such as micro probing and FIB. A
standard micro-controller is helpless against those ones fortunately
they are rarely seen as realistic threat due to their complexity and
cost. If they are realistic for a particular use case, then a high
security IC such as secure element from NXP/Infineon/Samsung/ST is
really needed.

Sebastien