What is the power implication of encrypting my sensor traffic?

Question

Considering a typical type of application, a battery powered sensor taking readings (32 bit value) every 10 minutes, what is the likely impact on battery life if I choose a simple un-encrypted on-air protocol, compared with an encrypted transmission?

Assume that my data isn't particularly secret, but according to this question I probably need to consider encrypting it, so long as there isn't actually a significant design cost.

For simplicity, let's assume I'm using a nRF51822 SoC which supports a BLE stack and a simpler 2.4 GHz protocol as well.

Since I'm thinking of a commercial product application rather than a one-off installation, the encryption needs to be compute intensive to break (say at least $500 of 2016 cloud compute), rather than a simple obfuscation. Something that remains secure even with access to the device firmware.

Answer 1

The bulk of your power will likely be expended on RF transmission, not CPU cycles spent in encryption routines. Every additional bit transmitted will cost you more power than the encryption you're proposing. That means if you take a naive approach, like using AES in CBC mode, you risk increasing the message size to carry the extra bits in each block.

If you determine your business needs the data to be encrypted, consider using AES in CTR mode to generate stream cypher bits. Counter mode is practical for dealing with cases where reception can be unreliable and packets may be lost. You'll have to keep the counters synchronized, so be aware that periodically transmitting the counter's value will add to the overhead. And you'll have to reserve a few bytes of state to hold the counter, because reuse of an encrypted bit stream can lead directly to data recovery.

Answer 2

There are a variety of encryption methods you could use to secure your traffic, and each one has a slightly different power usage, so I'm going to pick a couple of popular choices. The methodology I use to evaluate each method should be applicable to any other ciphers you find and wish to compare.

AES

AES is one of the most popular symmetric-key encryption algorithms (which means you use the same key to encrypt and decrypt). In terms of security, AES is a safe bet:

Best public cryptanalysis

Attacks have been published that are computationally faster than a full brute force attack, though none as of 2013 are computationally feasible.

- Wikipedia

The paper Biclique Cryptanalysis of the Full AES describes that AES-128 requires 2^126.1 operations, AES-192 requires 2^189.7 operations, and AES-256 requires 2^254.4 operations to break. On a 2.9 GHz processor, assuming each 'operation' is 1 CPU cycle (probably not true), breaking AES-128 would take a very long time. With 10 000 of them running, it will still take nearly forever. So, security isn't a concern here; let's consider the power aspect.

This paper shows (on page 15) that encrypting a block with AES used 351 pJ. I'll compare this a little later after talking about some other common algorithms.

SIMON

I asked a question about SIMON and SPECK previously, which is worth a read. Where SIMON excels is in situations where you need to encrypt a little bit of data, frequently. The paper I linked earlier states that SIMON 64/96 uses 213 pJ for 64 bits, which is practical when you only need to send 32 bits of payload.

SIMON 64/96 is significantly easier to break than AES though; the paper I linked suggests a 2^63.9 operations, so our 10 000 CPU setup could crack the encryption in only a few years, as opposed to millions of millennia.

Does it really matter?

At the rate you plan to transmit, the answer is almost certainly no; the energy usage from cryptography will be entirely negligible. For AES, you would use 50 544 pJ per day, so a cheap carbon-zinc AA battery with 2340 J of energy would last far beyond the device's lifetime. If you re-evaluate the calculations with SIMON, you find that it also has a very long lifetime

In short, unless you're transmitting very frequently, the radio is far more of a concern for power. Wikipedia quotes the power usage as between 0.01 and 0.5 W. If you transmit for 1 second at 0.01 W, you've already used more power than AES did over the whole day.

For BLE, though, you're probably fine just relying on the default security; BLE uses AES-CCM by default for link-layer security:

Encryption in Bluetooth with low energy uses AES-CCM cryptography. Like BR/EDR, the LE Controller will perform the encryption function. This function generates 128-bit encryptedData from a 128-bit key and 128-bit plaintextData using the AES-128-bit block cypher as defined in FIPS-1971.

There is some concern that there are security flaws with BLE's implementation of the link-layer security though; this is not a flaw in AES; rather Bluetooth SIG decided to roll their own key exchange mechanism in 4.0 and 4.1. The issue is now resolved in 4.2 as the Elliptical Curve Hellman-Diffie is now supported.

Answer 3

Unless you are doing hardware accelerated crypto, the power cost is likely to be high as you land up having a processor that is essentially overpowered for the basic (not crypto) needs. However, in most cases it is the use of the radio that consumes the most power anyway.

Since you are specifically looking at a bluetooth SOC, consider the BGM-111, which has hardware-accelerated crypto on the chip. I have played with this chip and it seems good, although I haven't looked at the crypto functions specifically.

Another route, and possibly the 'best' route if you want to ensure that nobody can get your keys even if they disassemble the device. It to include a TPM chip, like the OPTIGA TPM, which has I2C and SPI TPM chips that are supported by Linux kernels.

In short, you'll burn through batteries without specific hardware crypto. Either build a board with a TPM chip, or choose a more modern SoC that has hardware crypto already built-in.