What is the best way to send two floating point numbers to a server on the internet from a small device such as an arduino?

Question

I was thinking about sending some sensitive data (temperature) from an arduino (AVR 8-bit processor) to a server on the internet.

But I would like to make sure that it would not be possible for Eve to find the temperature.

I understand that the only way to solve this is to share a secret between the arduino and the server that Eve doesn't know. But where is the line between security by obscurity and a compile-time constant shared by server and arduino? (I ruled out asymmetric encryption due to performance & (expected) implementation problems).

So assuming they can encrypt the data with a secret key, I still have a sort of known-plaintext problem since Eve knows (from reading the source) that I'm sending 2 floats in a predictable range (-20C..50C). The only solution I could think about is interleaving the 2 floats in an array of random floats and an initial (random) byte to signal the kind of interleaving used. While this sounds to add security, I wonder if it actually does.

So perhaps to recap: what would be the best scenario for sending two temperature measurements to a server on the internet?

ps. at the moment I'm not worrying about authentification but if needed I could add a H/CMAC?

Answer 1

You have to define precisely what Eve can and cannot do. For instance, has Eve occasional physical access to the Arduino-based device ? If yes, then she can (at least conceptually) grab the device, "open" it, extract the shared secret, and replace the device with one of here own which does the same job, except that it also sends a copy of the data to another server that Eve controls. Arguably, she could also add her own measuring device along yours, to achieve the same effect. This would be a quite hard security model.

If Eve does not have occasional physical access to the device, then the "shared secret" model is fine. You still want to be careful with the secret; e.g., if you deploy several Arduino-based devices, have each of them use its own secret key, uncorrelated with the secrets in the other devices.

As for the encryption part:

• You do want an integrity check, i.e. a Message Authentication Code. Otherwise, Eve could, for instance, intercept messages and replace them with older messages. Eve would not directly learn the data, but that would probably be harmful to your system.

• You need either some randomness to each message, or some memory on the device, to avoid problem. Without either, the same pair of temperature values would yield the same encrypted message, and this would be visible to Eve. Actually, if you use only randomness but no memory, Eve could reorder messages at will, which could also be a problem. By "memory" I mean that the device must be able to store a value and change it, and such that the storage resists reboots.

Here is a specific scheme which will ensure security: to encrypt a pair of temperature values, encode them into a 128-bit word containing, in that order: the first temperature (over 24 bits), the second temperature (24 bits), a field containing only zeroes (48 bits), and counter (32 bits). Then encrypt this as one block with AES (the key being the secret shared between the device and the server). This yields a 128-bit value which you can send to the server. The counter must be managed with some care:

• The counter must start at 0. For every message, the counter must be incremented. It must not be possible to "reset" the counter to a previous value, even in case of temporary power loss.
• The server must verify, upon decryption, that the field containing zeroes indeed contains only zeroes. That's what serves as a MAC.
• The server must store the counter value from the last received message from the device. The new message is accepted only if it has a counter value which is greater than the stored counter value. (Potentially, the server could enforce stricter rules, e.g. refusing to increase the counter value by more than 100 as well.)

Under these conditions, the device will be good for four billions of messages or so. Even if it sends one message every second, this will still take 120 years before running out of counter values.

Security comes from the indistinguishability of AES from a random permutation over the space of 128-bit blocks. It would not work with a block cipher with smaller blocks, e.g. DES (or TripleDES). Also, the "zero-field" which serves as a MAC must not be too short; Eve could send messages with random junk, and a 48-bit field means that the risks of seeing one such message accepted by the server as genuine are around $2^{-48}$ -- since each message has length 16 bytes, it would take on average $2^{52}$ bytes (4000 terabytes) for Eve to succeed. 4000 terabytes, that's huge, but not impossibly huge. If you shorten this field to, say, 30 bytes, then these become 16 gigabytes, and that's highly doable.

Answer 2

Using your recap, your problem is the same as the person who wants to securely send their credit card number to a remote server. If you get rid of the need to securely agree on a one-time symmetric key, you get rid of the majority of the complications. In your case, the symmetric key is hard-coded and the attacks from the adversary are confined to non-physical access. So the ideal situation would be that you send encrypted data that:

• Cannot be used to recover information about the plaintext

  To address this issue, use an block mode of operation with an IV. The IV should be non-repeating; not necessarily random, just unique per message.

• Cannot be manipulated

  Attacks exist on some block modes that may allow the adversary to intelligently modify plaintext. If you use a MAC you can avoid this.

• Cannot be spoofed

  I assume that if an attacker deluged the server with invalid data, this would be undesirable. A MAC will also prevent this.

Known plaintext isn't that much of a problem with modern ciphers. In practice, almost all encrypted data contains known plaintext somewhere. Document metadata, protocol headers, etc. It's not really something that we worry about in general if we authenticate the data.