0
\$\begingroup\$

I'm designing myself a custom home automation system. Eventually, I want to expand the system to include security/alarm. The easiest way I know to do this is to include wireless capabilities.

This got me thinking about wireless security. The messages from let's say motion detectors should be encrypted, that's a given. The motion should have a regular keep-alive type message so that when a sensor goes dead or is disable the system would flag it.

This is where I see a weakness. If a sensor is constantly transmitting the same message ("no motion detected" for example), the message can be recorded and spoofed. Even if the message is encrypted because it is constantly transmitted, the same encrypted packet would be seen. Without knowing its content the packet could be captured and spoofed after disabling the sensor. I know it's paranoid but I'm trying to cover all my bases.

Is there a wireless protocol that automatically accounts for transmission of repetitive messages in their encryption? If not, how can the repetitive transmission weakness be patched?

\$\endgroup\$
1
  • \$\begingroup\$ Does being wireless have anything to do with the security? You'd be much better off asking this on security.se. \$\endgroup\$
    – Phil Frost
    Sep 23, 2017 at 12:24

2 Answers 2

1
\$\begingroup\$

Firstly: wired is going to be more secure than wireless. It is much harder to tap into a wires system and add messages, and (with a bit of thought) it is possible to make it very hard to cut the wires without being detected first. Wireless can be jammed easily, and is more vulnerable to spoofed messages etc.

That aside, to avoid a replay attack you need to make sure that each transmission from the remote sensor is different. There are many ways of doing that, offering different levels of security, and which one to use will depend on what you think of as acceptable security, acceptable complexity, acceptable component const, and acceptable energy use at the sensor if it is battery powered. Some ideas:

  • Timestamp each "I'm alive" transmission, before encrypting it. This needs a reasonably accurate realtime clock on the sensor, and probably an occasional re-synchronisation process. The synchronisation process could be as simple as the base station keeping track of the drift as it receives timestamps.
  • Use a nonce. A nonce is a single-use random number. The base station generates it and sends it out with an "are you alive" packet. The sensor includes the nonce in the encrypted reply.
  • Another way of using a nonce is for the sensor to generate one which is almost random but guaranteed not to repeat for a long time. The base station then checks that it hasn't seen that nonce before. The message needs to be signed such that the attacker can't forge it with a new nonce.
  • Both the sensor and base station share a secret, such as a long one-time-use pad, or a good pseudo RNG. Each transmission contains the next part of the secret. The base station should probably accept any one of the next three parts, in case a transmission gets garbled or lost. Even then, it's probably possible to get out of sync.

Roll-your-own encryption is not usually considered a good idea. There are probably some good, well researched, and thoroughly checked-out systems out there. The folks over on this stack exchange site might be able to help you pick a good one for your needs.

\$\endgroup\$
3
  • \$\begingroup\$ I was thinking of using plain old Wi-Fi. Let WPA2 take care of the encryption. Set the base station and all the sensors to static IP and place them outside of the DHCP range. Any thoughts? \$\endgroup\$
    – vini_i
    Sep 23, 2017 at 12:58
  • 1
    \$\begingroup\$ I believe (but am not certain) that WPA2 has built-in protections against replay attacks. Packets have a unique packet number, which always increases. Packets with 'already used' numbers are dropped. \$\endgroup\$
    – Jack B
    Sep 23, 2017 at 13:18
  • \$\begingroup\$ I did some reading, you are correct. The message integrity check (MIC) in WPA2 incorporates a temporal component. \$\endgroup\$
    – vini_i
    Sep 23, 2017 at 15:57
1
\$\begingroup\$

sounds like you want to thwart a replay attack.

You can do that by adding a counter/timestamp and encrypt it along. Then make sure the packet for "I'm alive no movement" and "I'm alive and there is movement" are the same length.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ That would require very good synchronization of the clocks. Probably not feasible. \$\endgroup\$
    – Phil Frost
    Sep 23, 2017 at 12:21
  • \$\begingroup\$ @PhilFrost not necessarily, all you need to do it make sure that the timestamp is within the jitter+drift ballpark and that there are no repeats for a long time. \$\endgroup\$ Sep 23, 2017 at 12:37

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .