AES-CMAC on an ATtiny85? You bet!
Our friends at Hackaday recently brought to our attention a nifty little custom door chime, powered by an ATtiny85 and equipped with AES-CMAC for message signing. While Daniel Neville could’ve used a commercial product, it’s evident that the Maker wanted to pack a little extra security into the pint-sized device.
Controlled by the tinyAVR MCU, the gate buzzer features an LM380N audio amplifier as well as a low-cost 315 MHz receiver. Using AVR assembly, the Maker managed to cram everything into the 8 Kbytes of Flash on the ATtiny85, including an AES cypher-based message authentication code. The transmitting gadget signs the request with a key shared between both devices, and the receiver verifies that the message is indeed from a trusted sender.
“The chime learns up to eight transmitters with the same shared key but with different serial numbers and different secret AES-CMAC keys. Each transmitter can have either one or two sensors to monitor. Each sensor on each transmitter is associated with one of sixteen possible sets of sounds. Some sound sets include activation, deactivation and prolonged activation reminder sounds while others only include the activation sound,” Neville writes.
Intrigued? You can read all about the build and access its source codes here.
I’ve been looking at doing similar security on nRF24L01 links for IoT-style applications.
The security applied with this setup isn’t really sufficient against all kinds of attack. Specifically, a one-shot signed message like this doesn’t in any way protect it against a replay attack. That is; an attacker could record a message over the air, then send it again at some other time, to cause the same effect – namely, the bell to ring.
In order to protect against that, you either need:
1) sequence numbering – once you’ve received some message N, don’t accept it again, only accept numbers > N.
2) challenge-response – have the bell station send out a randomised “challenge” which the button station has to then reply to by signing it
3) time-of-day bounds – embed the current time in the message and only accept a small margin from the current time
Each of these defences adds some complexity however – numbering requires a manual reset/resequence to set the thing up intiially and a memory of what numbers have come before; challenge-response requires both stations to have half-duplex transceivers; time-of-day bounds requires some kind of realtime clock at both stations.
LikeLike