1

Background

I am building a Home Automation system using RF 315/433 MHz Transmitter-receiver module, an Ethernet shield and AT Mega AVR Micro controller(ATMega328 PPU) that works as follows.

A set of REST APIs are integrated with a back end database. A web and mobile application interface with this DB to change settings. The AT Mega MC interfaces with the Ethernet shield connects to my home ADSL router.

AT Mega MC reads (HTTPS) API values via Ethernet shield and try to control devices (my roller door, light switches, heating etc..) using a RF 315/433 MHz Transmitter-receiver module. The end point featuring by the RF Receiver and AT Mega MC sends control messages using the RF Transmitter.

Problem

I have the following security problems in this setup.

  1. What is the most efficient way that I can encrypt my messages from the RF transmitter to receiver ? Right now I do a simple XOR operation to the control messages in both ends. So the value of the XOR is simply acts as a shared key. I know this is not secure at all! I cannot implement resource consuming algorithm in my end point (receiver end) because it is using the ATtiny85 MC.

  2. Even If I encrypt the message from RF TX to RX, someone can intercept the outgoing message (using some tool like HackRF) and replay the message later. So they can do a replay attack easily and open up my gate any time later.

Questions

  1. What are the best security precautions that I can use to secure my RF transmission? Please remember that I am working with IoT devices which do not have extensive computing power.

  2. How can I prevent this replay attack ?

Jedi
  • 3,936
  • 2
  • 24
  • 42
user3496510
  • 1,277
  • 2
  • 13
  • 26

2 Answers2

0

IoT limitations will be serious to your system security. It may be fun to build but personally I would like strong security for the garage door. Anyhow, some general answers below.

  1. AES is common secure alternative in the modern communication protocols. XOR will reveal your password to the eavesdroppers. Search e.g. "whats wrong with xor encryption" in this forum.

  2. The TLS nonce is a good example of preventing replays. Its use is discussed here: nonce in SSL/TLS handshake

Community
  • 1
Risto Mononen
  • 1
  • 1
  • OP mentions that AWS is not feasible for an ATtiny85. A TLS nonce may not helps for the HTTPS communication, but not for the outgoing RF? – Jedi Jan 06 '17 at 07:10
  • I am not sure if I understand the question. If ATtiny can not compute AES then there are not many alternatives for encryption. RF link can protect message integrity and authenticity if we so design, just like TLS. Nonce protects from replays and it can be part of the solution on any protocol layer. DepressedDaniel gave a better detailed answer above. – Risto Mononen Jan 08 '17 at 08:11
0

What is the most efficient way that I can encrypt my messages from RF Transmitter to Receiver ?

Perhaps the AES implementation from axTLS could be used:

https://electronics.stackexchange.com/questions/13275/smallest-aes-implementation-for-microcontrollers

http://codesearch.google.com/codesearch/p?hl=en#RGCD84x9Jg0/trunk/xbmc/lib/libUPnP/Neptune/ThirdParty/axTLS/crypto/aes.c

Even If I encrypt the message from RF TX to RX, someone can intercept the outgoing message (using some tool like HackRF) and replay the message later.

That's why you need to include a nonce and HMAC, as encryption alone does not guarantee the message was not tampered with. HMAC means you will need a hash function. However, if your messages are of a constant length, you can use CBC-MAC (see https://en.wikipedia.org/wiki/CBC-MAC) as a hash function, thus reusing the AES implementation. You can probably even fit SHA-2 on the ATtiny85, but of course you may need the space/RAM for your actual functionality as well.

Community
  • 1
DepressedDaniel
  • 1,240
  • 7
  • 8