2

(I am not a native speaker and might not be correct in terms of terminology. Sorry about that.)

I am transmitting data via radio between AVR microcontrollers for personal use and would like for clients to demonstrate the authenticity of transmitted data in that it originates from one of the authorized clients. This means I am not requiring non-repudiation and would be able to pre-define a shared key. I have done some research on different approaches and found that I need some assistance on chosing one that best meets my requirements.

Please understand that I do not require maximum security. I would simply like to prevent a potential script kiddie neighbor from breaking in within a matter of hours. Should breaking in with average consumer gear require a number of weeks as of today I would be OK.

The messages I am transmitting are rather small in size (no more than 30 bytes with only a few bytes payload) and the frequency would be no more than 30 messages / min.

One use case is a motion detector sending a message over the air to a processing unit which then sends another message over the air to a light switch. Please do not focus on transport. This question is only on data autheticity.

I am running the client / server software (in C) on 20 MHz AVR microcontrollers with very limited Flash and RAM. So I am looking for a solution with small code size and RAM utilization while still providing a high data rate.

I did some performance testing with an MD5 implementation (C) creating hashes from 20 bytes data and found that it might be too slow. I understand that an MD5 implementation by itself would not solve the requirement. I did the testing only for evaluating hashing performance.

Thanks for comments

Netzoss
  • 45
  • 4
  • I am considering HMAC but am not sure what Hash function to use. – Netzoss Apr 02 '12 at 18:02
  • Are you happy with any clients also being able to create valid messages, or do you need clients to be able to authenticate a message but not create them? – Nick Johnson Apr 05 '12 at 06:51
  • @Nick: Thanks for your comment. Are you referring to non-repudiation? I do not require it (as mentioned in the question). – Netzoss Apr 18 '12 at 21:27
  • No, I'm asking if verifiers can be allowed to create valid messages as well, or if they should only be able to verify. If it's okay for verifiers to be able to issue messages, an HMAC will work fine. If not, you'll need public key crypto. – Nick Johnson Apr 19 '12 at 03:02
  • @Nick: I understand that that is all about non-repudiation ([http://en.wikipedia.org/wiki/Non-repudiation#Non-repudiation_in_digital_security](http://en.wikipedia.org/wiki/Non-repudiation#Non-repudiation_in_digital_security) – Netzoss Apr 19 '12 at 10:48
  • No, it's not about non-repudiation. The point is that you can very easily verify the authenticity of data using an HMAC, but all it tells you is "the data was generated by someone in posession of this key". You need the key to check the authenticity, but with the key, you can also generate your own valid hashes - so it only works if you trust the verifiers. – Nick Johnson Apr 19 '12 at 13:10
  • Non repudiation is the ability to prove that someone issued a certain plaintext. That's only the case with private key crypto - with an HMAC, anyone who can verify the signature can also generate signatures. All I'm trying to ask (over and over again) is if it's okay for your verifiers to be able to generate keys. You can be in a situation where you're not concerned about non repudiation, but you still don't want verifiers to be able to generate their own valid signatures - for instance, where you don't trust your verifiers. – Nick Johnson Apr 22 '12 at 00:25
  • @Nick: I appreciate your comments and would like to first answer your question. No I am not concerned about verifiers also being able to sign messages. You are saying that there could be occasions where one would not be concerned about non-repudiation but still would not want verifiers to create MACs. I do not see that. What else would be the issue if not that you cannot know where a message originated at (non-repudiation). – Netzoss Apr 23 '12 at 13:27
  • An example would be signing of binaries. The main concern is to make sure it hasn't been tampered with in transit; a side-effect is non-repudiation, but it's not the primary goal. – Nick Johnson Apr 24 '12 at 00:42
  • @Nick: I can only point to the Wikipedia article again (unless you don't trust it): "Regarding digital security, the cryptological meaning and application of non-repudiation shifts to mean: A service that provides proof of the integrity and origin of data. An authentication that with high assurance can be asserted to be genuine." ([http://en.wikipedia.org/wiki/Non-repudiation#Non-repudiation_in_digital_security](http://en.wikipedia.org/wiki/Non-repudiation#Non-repudiation_in_digital_security)). – Netzoss Apr 24 '12 at 09:54
  • @ Nick: This sounds identical to what you were saying by "The main concern is to make sure it hasn't been tampered with in transit". – Netzoss Apr 24 '12 at 09:55
  • I don't know how I can explain it any more clearly than I already have. – Nick Johnson Apr 26 '12 at 03:03

2 Answers2

5

I would use 128-bit AES to sign the messages. Here is an excellent source that has already implemented this for AVR, with full documentation of sizes and cycle counts, including different versions that trade off size/speed. http://avrcryptolib.das-labor.org/trac/wiki/AES

TJD
  • 11,349
  • 1
  • 22
  • 32
  • Thanks for the comment. Can you explain how you would use AES to sign the messages (Signing might not be the best term. A signature needs asymetric cryptography)? How would you use the implementation you mentioned for creating a MAC? – Netzoss Apr 02 '12 at 22:22
  • @Netzoss, you're right. I mean generate a MAC with AES. Sender computes the MAC using secret key and appends it to payload. Receiver computes MAC using secret key and compares to what it received. You also need to add a nonce/sequence number that increments to prevent replay attacks. Here's an example of AES MAC http://cr.yp.to/mac.html – TJD Apr 02 '12 at 22:33
  • Don't use non-standardized cryptography if you don't need to. I would seriously recommend looking at AESCMAC instead. Chances are better for finding a reference implementation too, and it would not even be too hard to create it yourself (using AES of course) and test it against the official NIST test vectors (from experience, in this case). See [here](http://en.wikipedia.org/wiki/CMAC) – Maarten Bodewes Apr 03 '12 at 00:22
  • Of course, you could do worse than an algorithm by the honorable mr Bernstein, but still :) – Maarten Bodewes Apr 03 '12 at 00:24
  • It seems that AES-CCM does the trick. From first tests with the authentication portion it seems quick enough. I am going to implement the complete AES-CCM and let you know if it works well enough. – Netzoss Apr 12 '12 at 22:28
  • @Netzoss, I don't see any edit or way to approve. Maybe I don't have privilege or review goes elsewhere? – TJD Apr 18 '12 at 20:57
  • I ended up implementing AES-CCM (128 bit block size) according to RFC3610 which gave me even more than I initialy looked for. In addition to only authenticating a message it is now also encrypted. On average it takes less than 1 ms to decode a 2 block message create a 2 block reply and encode it again (both decoding and encoding include calculating the MAC) on a 20 MHz AVR ... – Netzoss Apr 18 '12 at 21:14
  • AES-CCM uses a shared key, provides authentication as well as encryption and guarantees unique cyphertexts. If you have an AES implementation which only supports the ECB mode, you need to first implement AES-CBC. This allows you to do authentication. Then you need to implement AES-CTR which allows you to encrypt the authenticated messages. Put both together according to RFC3610 and you get AES-CCM. Be aware that you need to guarantee unique Nonces per Message. – Netzoss Apr 18 '12 at 21:14
1

If you are happy with a compromise, calculated the CRC-32 or CRC-64 of the message payload with a secret key appended to the end (of the payload, not the CRC checksum). Both ends can do this with the same secret key to get the same result. Not sure of the exact hackability of this but it sure isn't zero.

Michael Slade
  • 13,476
  • 2
  • 36
  • 44
  • Thanks Michael. I suppose this approach would be very prone to a number of attacks so I do not know if it meets the requirement of not beeing able to break within a few days, regular consumer gear provided. – Netzoss Apr 10 '12 at 15:52
  • +1 for mentioning this approach, which definitely *is* high performance. Security is indeed pretty low: For a CRC-32 there's only about 4 billion values to brute-force - nothing that can't be done within seconds on current PC hardware. Worth noting: The "secret key" need not be any longer than the CRC value, i.e. 32 or 64 bit, since longer keys do not add to security at all. – JimmyB May 18 '12 at 17:47