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.

  • 2
    "Something that remains secure even with access to the device firmware." means that you either need to use asymmetrical cryptography that is computationally expensive to reverse, or you need to store a symmetric key where it cannot be retrieved or exercised to recovery (known plaintext attack, etc). Typically in the latter case, each copy of the product has a unique key so that recovery from one sample does not break the entire system; but this means your receiver needs to store all those keys. – Chris Stratton Jan 21 '17 at 19:45
up vote 8 down vote accepted

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.

  • Sounds convincing, and puts quite a different spin on the problem, which I'd not thought too much about this time. – Sean Houlihane Jan 20 '17 at 21:32
  • 2
    Beware that CTR does not provide data authenticity. You should use an authenticated encryption mode unless you understand why authenticity is not a concern in your application. – Gilles Jan 20 '17 at 22:34

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 2126.1 operations, AES-192 requires 2189.7 operations, and AES-256 requires 2254.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 263.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.

  • 1
    "On a 2.9 GHz processor, assuming each 'operation' is 1 CPU cycle (probably not true)" - probably compensated by parallel processors (like GPUs) running at lower speeds but producing multiple results per cycle [and even on CPU IIRC you can achieve close to 1 operation/clock on single core]. It doesn't change the orders of magnitude too much. – Maciej Piechotka Jan 21 '17 at 3:46
  • @MaciejPiechotka That's a good point. As you suggest, the order of magnitude shouldn't be affected too much, and at the scales that we're working at, a factor of 10 is still quite insignificant (10^33 days vs 10^32 days won't matter an awful lot!). – Aurora0001 Jan 21 '17 at 10:43
  • 1
    A symmetric system like AES is problematic unless each device has a unique key - otherwise getting it out of just one dissected sample breaks the whole system. – Chris Stratton Jan 21 '17 at 19:52

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.

  • 2
    The question suggests a 2.5GHz SoC and sending a 32-bit value every 10 minutes. The amount of computation needed for crypto is utterly negligible. Granted, that SoC does seem overpowered for the task. But for 32 bits every 10 minutes, the cheapest base processor you can find will be more than enough. – Gilles Jan 20 '17 at 22:32
  • 3
    With 10 minute intervals, it doesn't matter how much time it takes to encrypt, it only matters how much energy. You have to look at the implementation details like parasitic loads to figure out if a fast chip that does it in 1 ms or a slow one that takes 500ms will win on power consumption, assuming both effectively sleep when not busy. A hardware engine could well be better than software, but for energy efficiency - that it gets the job done faster is irrelevant. – Chris Stratton Jan 21 '17 at 19:56

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.