0

We are manufacturing a sensor which transmits in 8 byte packets. This sensor will be used by several different receivers, some of which have very little spare RAM available (< 3 kb). On some of the receivers we will provide the software, in other cases, we will be providing the code to the manufacturer under NDA.

It is a commercial application and the sensor could be copied relatively easily. To create a small obstacle for copycat designs, we would like to add some encryption or obfuscation to the packets.

A few details on the radio packet:

  • 8 byte packet
  • tx several times a second
  • the sensor measures analog conditions which can be altered by someone looking to 'crack' the encryption. Part of the packet will be this data. Sometimes the sensor will repeatedly send a null signal.

I thought of using Blowfish, but it is more RAM than I would like to allocate, and it is probably overkill in terms of encryption. Is there a lower RAM alternative of Blowfish?

I know that replacement ciphers are relatively easy to crack, but as I am only looking to slow someone down it may be suitable? Can someone point me towards a mehtod which is RAM efficient and requires some work to crack?

Disco Stu
  • 103
  • 1

1 Answers1

1

To encrypt an 8-byte packet for the question's purpose, one could do worse than use a 64-bit cipher applied to the 8 byte packet, and a secret key.

Candidates include

  • TEA, which has among the lowest code footprint and is very simple to implement
  • Speck or Simon (64/128 or 64/96), which may be a tad more efficient
  • IDEA, but it requires multiplication, which might be hard to get constant time.
  • DES or 3DES, but the code is larger and requires table lookup, which can be problematic from a security standpoint especially on an CPU with cache.

Any of these can be implemented with very little RAM (64 bytes is ample).


Note: this substitution do not provide

  • robust confidentiality (in particular identical values always get encrypted the same)
  • integrity protection
  • protection against replay
  • strong protection against copy, which remains possible e.g. by blindly cloning the sensor's code and data, or reverse engineering the sensor or something that uses it.
fgrieu
  • 131,696
  • 12
  • 284
  • 553