How to encrypt sensor data in low-power wireless communication like LoRa, BLE, ...?

Question

Wireless sensors communication have limitation in message size due to low power consumption.

Assume that we have a heart rate sensor sending data via BLE, or a GPS data sending via LoRa to a receiver: the message size is a few bytes.

If we use standard encryption algorithms, the message size will be increased tremendously to hundreds of bytes. Also, the encryption and decryption will use much more power during processing.

So, there should be trade-off for that.

What are the best practices to encrypt/decrypt the tiny data?

Answer 1

"If we use standard encryption algorithms, the message size will be increased tremendously to hundreds of bytes" - what do you base that on? (and what are standard encryption algorithms).

AES is a fairly standard encryption algorithm which is supported by, for instance, the ESP32, which is a very widely used board .

This page says

Most symmetric ciphers work on blocks of data considerably larger than a single byte (AES-128, for example, works 16 bytes at a time). As a result, if the file isn't a multiple of the block size, you need to pad the end to fill a complete block. There are ways (such as "ciphertext stealing") to do this without making the encrypted file larger than the original file, but just adding a few bytes of padding is usually simpler.

so, you may have a concern with message size < 16 bytes.

If so, you have to ask yourself if you can't buffer your data and send it when you have 16 bytes.

A Basic Introduction to BLE Security says

The way that BLE overcomes this is by encrypting the data being transferred using AES-CCM cryptography.

So you probably don't need to encrypt on chip, unless you are buffering data (or want double encryption).

It would help us if you can define exactly what size of data you are sending, how often, and how time sensitive is it (can you buffer it)?

Maximizing BLE Throughput Part 3: Data Length Extension (DLE) might be of help if you use BLE 5. To quote ...

DLE is a feature added to the Link Layer that allows the Data Channel Protocol Data Unit (PDU) Payload field to be increased from the default 27 bytes to up to 251 bytes

In short, I think that BLE 5 can solve your problems. What do you think?

Answer 2

You do not have to increase message size if you pick the right standard encryption algorithm for your application. You can check how it's done in the LoRaWAN protocol and apply the same methodology to any PHY protocol you want, LoRa, FSK or any other kind of modulation.

LoRaWAN uses AES in CTR mode for encryption, and this mode doesn't add any overhead (if payload is 1 byte, encrypted payload is 1 byte). For authentication, LoRaWAN uses CMAC to generate a 4-byte signature. This is probably acceptable overhead in all but the most resource-limited application. All those cryptosystems are based on symmetric keys. To avoid common attacks, a long term secrete symmetric key (specific to each device) is used to generate session keys that are negotiated in a secure way between both end of the link.

For BLE, if you want a smartphone to be able to understand heart-rate data (a value that is part of a standard BLE profile), you have no other option than following the BLE standard and using the security that is build in the protocol.