Advice on encryption for micro controller - Page 1
Forum section: electronics / general

author: Helix70
author_rank: Unknown
timestamp: January 28, 2015, 08:48:28 am
content: Hi everyone,I have a need to encrypt 64 bit blocks of data in real time, which is then transmitted with a low power radio. Does anyone have any advice for a 64 bit block cypher algorithm that:1) fast encryption and decryption in software (and thus ultra-low power consuming)2) uses low amounts of RAM (< 1K)4) is reasonably hard to crack, brute force takes more than an hour for example, no known instant back doors5) open source or freeware/public domain6) fast key generation - RC4 takes a long time to generate a new key - not really ideal, but maybe. I need a new key every 5 minutes or so.Sadly, it must be 64 bit blocks (or smaller) of data, so AES is out. I am not trying to send top secret information, but the information is structured so simple XOR'ing is not enough.

author: rt
author_rank: Regular Contributor
timestamp: January 28, 2015, 08:55:09 am
content: Some questions:- to understand "realtime" can you indicate what type of microcontroller? Clock speed? ATTiny or Arm7?- are you assuming the cracker will only have access to your broadcasts and not to the physical device?rt

author: Helix70
author_rank: Unknown
timestamp: January 28, 2015, 09:01:19 am
content: MSP430 @ 16Mhz, and yes, I want to obfuscate the broadcasts. The radio traffic has no real value, but some customers need to know it is not in the clear. Preventing unauthorised control is more important.

author: Codemonkey
author_rank: Regular Contributor
timestamp: January 28, 2015, 09:06:44 am
content: I don't see why you can't use AES. ZigBee uses AES based encryption to encode packets that are frequently smaller than 64 bytes. If your AES implementation can only handle larger blocks, just pad the data at both ends.

author: Helix70
author_rank: Unknown
timestamp: January 28, 2015, 09:13:12 am
content: Each broadcast data packet is only 8 bytes (64bits), not 64 bytes.

author: Codemonkey
author_rank: Regular Contributor
timestamp: January 28, 2015, 09:16:45 am
content: Doh!, should learn to read!You could look at something like blowfish, not sure how quick it is though:https://www.schneier.com/blowfish.html

author: sirhaggis
author_rank: Regular Contributor
timestamp: January 28, 2015, 09:38:14 am
content: My encryption theory is a bit rusty but it sounds like a combination of a symmetrical key exchange combined with a one-time key generation would work in this situation. One-time keys are very fast and cheap to use for encryption without consuming much RAM. Just negotiate a symmetric key exchange on setup and generate a random one-time key which you can use for following encryption. You can then re-negotiate for new one-time keys every so often to prevent pattern based attacks. I think SSL uses a mechanism like this but the protocol itself is probably too bloated for an MCU application. You could probably roll your own if you're game.

author: nctnico
author_rank: Super Contributor
timestamp: January 28, 2015, 03:09:03 pm
content: AES sounds nice but it needs an enormous amount of processing power so it is not suitable for a low power device. If you built in a limit for the time a packet is valid you can use a far less strong encryption method because the time required to catch a packet, crack it and inject it again will be longer than it's lifetime. Also include some random pattern in the data otherwise each packet will be the same and is easy to replay without needing any cracking.

author: bingo600
author_rank: Super Contributor
timestamp: January 28, 2015, 08:49:02 pm
content: What about Xtea ?Have seen it used in small MCU implementations/Bingo

author: Codemonkey
author_rank: Regular Contributor
timestamp: January 28, 2015, 09:08:46 pm
content: Quote from: nctnico on January 28, 2015, 03:09:03 pmThat depends on the micro. This has a hardware AES engine built in and can encode or decode packets on the fly whilst also being very low power and cheap!http://www.nxp.com/products/microcontrollers/zigbee/JN5168.html

author: Howardlong
author_rank: Super Contributor
timestamp: January 28, 2015, 10:03:25 pm
content: Microchip have encryption routines including AES available on all their devices from the PIC16 up.I've used it on both the PIC24 and PIC32. It's reasonably fast, certainly good enough for real time at reasonable rates Code size is not the best, 3KB for AES on PIC24, owing to the use of const lookup tables to aid speed.Microchip app notes AN821, AN953, AN1044.

author: jeremy
author_rank: Super Contributor
timestamp: January 28, 2015, 10:04:23 pm
content: Sorry, I don't have a good answer. All of the crypto I know of is slow on a micro. Have you considered an external solution, something like this guy:http://www.atmel.com/devices/ATSHA204A.aspx?Why do you need a new key every 5 minutes?

author: ttt
author_rank: Regular Contributor
timestamp: January 28, 2015, 10:17:53 pm
content: Quote from: Helix70 on January 28, 2015, 08:48:28 amDo you maybe mean RC5? RC4 is a stream cypher, while RC5 is a block cypher.That said you will be hardly able to find something faster than RC4/RC5. Something close to RC5 might be Blowfish, depending on instruction set/compiler. The cost you pay is indeed the setup for a new key. But if power is an issue that's usually the better balance to make. Or do packets need to be sent at exactly known time intervals?

author: Helix70
author_rank: Unknown
timestamp: January 28, 2015, 10:46:44 pm
content: Thanks guys. AES is not usable for this application due to the 128 bit block size. XXTEA looks promising, so does blowfish.The five minute key change is to thwart replay attacks, and as previously mentioned, if the key changes rapidly, the encryption algorithm can be "weaker".I want to use this technique as it will overlay an existing message structure without too much modification. 5 minutes may be a bit too severe, might wind it back to an hour...

author: jeremy
author_rank: Super Contributor
timestamp: January 28, 2015, 11:00:23 pm
content: Quote from: Helix70 on January 28, 2015, 10:46:44 pmReplay is easy to fix, use a nonce. I'm no crypto expert, but even if you use an incrementing integer or the current time (divided into your packet intervals of course) that should give you the anti-replay security you need.http://en.wikipedia.org/wiki/Cryptographic_nonceIf someone really wanted to perform a replay attack, does it really matter how long the time between the keys is? They will still have a window to replay. Perhaps for a really malicious attack which would try to affect later results, but not for a denial of service immediate record and replay.Edit: you could also generate the nonce using a secretly seeded LFSR without much computational work.

author: ttt
author_rank: Regular Contributor
timestamp: January 28, 2015, 11:51:10 pm
content: Quote from: Helix70 on January 28, 2015, 10:46:44 pmI am not sure that's the best way of avoiding replay attacks. I question if it's even necessary to change the key every once in a while. If the two radios can send&receive (which I assume is the case since you want to update keys every 5 minutes) you should use a randomly generated session token and create a block cypher key based on that.- How are you planning to do the initial key exchange on startup?- Can you create good random numbers? Using something based on time or serial numbers tends to be easily defeated if someone really wants to try, especially if they have an idea of how it's implemented.- Where/how do you store your private keys (which you will need)? Are they unique per device pairs? Are the devices physically accessible?

author: Psi
author_rank: Super Contributor
timestamp: January 29, 2015, 02:16:51 am
content: I used PC1 for a bootloader a while back.No idea if its suitable for you, check it out.Its easy\fast on a 8bit mcu

author: Kjelt
author_rank: Super Contributor
timestamp: January 29, 2015, 01:14:36 pm
content: Quote from: bingo600 on January 28, 2015, 08:49:02 pm+1tested it once on ultralow power (NFC) microcontroller.http://en.wikipedia.org/wiki/XTEA

author: helius
author_rank: Super Contributor
timestamp: January 29, 2015, 03:27:52 pm
content: Quote from: mojo-chan on January 29, 2015, 11:34:34 amThis scheme is vulnerable to MITM attacks.