[Cryptography] Simple IoT sensor encryption ?

[Henry Baker]

At 08:01 AM 4/15/2016, Andrew Donoho wrote:
>> On Apr 14, 2016, at 14:50 , Henry Baker <hbaker1 at pipeline.com> wrote:
>> 
>> 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.
>
>Henry,
>
>        I think you should unpack this concern a bit.  First, what is a sensor reading?  For our purposes, lets say it is a single 32 bit int32_t/float32_t and a monotonically increasing "time" int32_t.  What else would you have the payload contain?  It could contain more identifying info but lets put those burdens on the servers.
>
>Does using PK require a "heck of a lot more power?
>
>        Is this a wireless device?
>                If so, what is the relative power consumption of encryption with PK or AES versus turning on the radios?
>                If so, what is the marginal increase of power consumption due to using PK over AES?
>        Is this a battery operated device?
>                If so, what is the integrated energy consumption of the data reporting event? 
>                Can you even measure the power consumption contributed by the PK? Is it material?
>
>If the device is wired, say with Power over Ethernet, then just use the PK and be done with it.
>
>        I suspect that with modern embedded 8 bit processors, encrypting a sensor reading, 64 bits, with PK, is just not that expensive. The power cost of turning on the radios is so much larger than the encryption power cost as to not be a real concern. Only the power consumption numbers will tell the tale.
>
>        I'm betting that PK is all that is needed.

Let's take a totally trivial wireless application: a sports heart rate transmitter strap.  (There are lots of other applications, including audio & video, but let's focus on a much simpler, much less resource intensive application to start with.)

Because this is a *sports* application, this application doesn't have to come under any of the FDA or HIPAA rules.

The heart rate strap (should be) cheap & ubiquitous, but it does need to know where (i.e., the public key of the receiver) to send the information *to*.

While it's called "pairing", it really need only be "un-ing", as the heart rate strap only needs the public key of the receiver device (typically worn on the wrist).

Notice that even this "un-ing" process can occur in public, since the public key is already public, so eavesdropping on the communication can only reveal that a HR strap is being initialized.  The worst that can happen is that someone else's strap starts sending data to you, but you'll quickly notice this.

If you somehow accidently install someone else's public key into your own HR strap, you'll also notice this, because you won't be receiving any HR data from your own strap.

The reason for encryption is

1) so that no one else's receiver can decode your heart rate (even by mistake), and
2) so that even a malicious competitor won't be able to grab your heart rate.

(If you're in the last 100m of a race & can tell that your competitor's HR is maxed out, you may be able to beat him.  If you & your competitor are climbing a hill on your bikes, and his HR is 10 bpm below yours, you may want to consider giving him a flat tire!)

It's unlikely that your competitor will get you to install one of his HR belts, and you would notice if your wrist monitor didn't receive any HR data.

Your competitor could disassemble your belt to his/her heart's (!) content, and still not learn any of your secrets -- in particular, any secrets associated with your wrist monitor.  So you are free to leave your belt in your locker, or leave it out while taking a shower.

You should, however, keep your (waterproof, of course!) wrist monitor on during your shower so that you can control access to this device which contains secret decryption keys.