# Designing an AES-based protocol for controlling and acessing ioT boards via RF

I'm designing an open ioT protocol to be used on ioT boards based on Texas Instruments RF-based MCUs. These MCUs have an AES module to easily encrypt and decrypt AES content, so that's why I choose a symmetric key algorithm rather than a public key one (also, RSA would need licensing). So, obviously, there are some problems I want to avoid:

1. It should not be possible to other people read or control the ioT boards, except for the 'master' board, the one that's gonna be connected to the internet and broadcast messages to the 'slave' boards.
2. Replay attacks must be avoided. I could avoid this by having one-directional communication (master-slave) using time-signed messages, but this would need a clock to be maintaned in both sides. I prefer to have bi-directional communication, so I can avoid time-syncing problems.
3. I don't want to share the master's key with every slave device, because if one gets stolen, the key will be compromised. So I've opted to use different keys for every slave, and store them all in the master board.
4. To avoid radio interference (normal RF doesn't have all the channels and things that prevents wifi and bluetooth to interfere with each other) I'm thinking about the commands being broadcast messages that only the right slave would answer. However, I still have to think about when a slave must send a random message to the master, I don't want more than one slave sending a message at the same time.

Given these constraints, I've been thinking in a protocol like this:

1. Master sends AES(slaveKey,command+challenge+nonce) (the master keeps track of all used nonces so it doesn't send the same again, so every message is gonna be different, therefore invalidating replay attacks or identification of the type of message by frequency of it being sent. For example, someone who listens enough of the same message could know for what that message is for)
2. All slaves receive the message, but only the one who's able to decrypt it is gonna read the command and the challenge. So, the slave respond with AES(slaveKey, commandResponse+challengeResponse+newChallenge+nonce2). Again, the slave maintains track of the nonce so it never sends the same one. After the message is sent, the slave starts counting for like, 5 seconds, and wait for the master's response (this time constraint ensures the message will not work later if someone tries to replay it).
3. Master receives the slave's answer to the challenge, and then finally responds it with AES(slaveKey, command+newChallengeResponse+nonce3).
4. If the message is received by the slave within 5 seconds, then the message is accepted by the slave as true and the slave does its action. When the action is done, the slave again sends the status of the action for the master in the form: AES(slaveKey, commandStatus+nonce4)

I'm also thinking in adding an ID in all messages, so both the master and the slave will be able to know for which action they're responding too. I'm thinking about the possible vulnerabilities of this model. Is there any need to message authentication? Because the very act of being able to decrypt the message and answer the challenge is a form of knowing that only the right slave or master could have read that message. If it needs authentication, I'll use SHA2 because its easy to implement in the chip.

Also, is there any work in this field? TLS seems too complicated for a RF chip that's not wireless (wireless MCUs from Texas have a TLS module, but they're too expensive for the project). What's the model used in these new car keys that avoid replay attacks? I've read this entire PDF from Atmel about rolling code and it addresses the replay attack vulnerability because it's an one-way transmission.

• AES is not an encryption algorithm, it is a block cipher. AES in itself can therefore not be used, you need a mode of operation. The protocol is not well described enough to be analyzed; for instance what is challengeResponse? And yes, in general you do need an authentication tag. – Maarten Bodewes Oct 22 '15 at 11:10