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?

  • $\begingroup$ The answer depends on your attacker model. If you model your attacker as never having physical access to either the arduino or the server, a compile time constant is fine. So really, you'll need to specify the capabilities of your attacker. Then, since you are using a constant key, you will need an IV included in your cipher. $\endgroup$
    – mikeazo
    Jan 26, 2012 at 18:59
  • $\begingroup$ ah, yes. I forgot to mention that I assume that if the attacker has physical access to the arduino/server than all bets are off. $\endgroup$ Jan 26, 2012 at 19:02

3 Answers 3


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.

  • $\begingroup$ thanks for your elaborate answer, the only problem I see is with the counter reset during powerloss.. I could use the EEProm, but is is slow to write to and has a fairly low threshold for read/writes.. which would mean the memory would become corrupt... $\endgroup$ Jan 26, 2012 at 19:53
  • $\begingroup$ @DavyLandman: without some kind of memory, there is no way for the device to send messages which will resist malicious reordering by Eve -- unless you go with a two-directional protocol, in which the server interactively exchanges messages with the device: at that point, things become really complex, both to implement and to analyze. $\endgroup$ Jan 26, 2012 at 19:57
  • $\begingroup$ okay, thanks for the clarification. BTW I was thinking of using CBC, so I guess I should also send a random IV along? Or since I'm already making sure that each block is different the same IV could be used? $\endgroup$ Jan 27, 2012 at 9:16
  • $\begingroup$ @DavyLandman: what I described is a single block encryption, which does not use any encryption mode -- it provides the desired properties only because it is a single block encryption, and has the specific format and rules that I mandate. CBC encryption handles longer messages but does not provide a MAC by itself; and CBC requires an IV which MUST be selected randomly and uniformly, and a new IV MUST be generated for each message. CBC is needy. I suggest you investigate EAX, which includes a MAC and has lighter IV needs (a counter suffices). $\endgroup$ Jan 27, 2012 at 13:29
  • $\begingroup$ You only have to write to EEPROM the nonce or counter value you will resume from in case of power loss. You could increment it by quite a large number to manage write wear. $\endgroup$
    – joeforker
    Jul 6, 2013 at 1:12

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.


The NaCl library has been implemented for the AVR: http://cryptojedi.org/papers/avrnacl-20130220.pdf; http://cryptojedi.org/crypto/#avrnacl . It provides a pretty much no compromises set of easy to use cryptographic operations. Including public key encryption and authenticated encryption.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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