Encryption is only part of the solution

So, in the previous two posts I have covered:

And talked about how, although they are useful techniques to make an alarm better, they need to be implemented correctly.

Now, I am going to briefly cover encryption, and how it can go wrong.

What is encryption?

At a very basic level, encrypting something is encoding a message in a way which means an eavesdropper cannot determine the contents of the message.

There are many techniques – the one most familiar to people is a substitution cipher, where each letter is substituted for another.

In the real world, encryption uses more advanced techniques than this. Some encryption techniques are, to all intents and purposes, impossible to crack – unless you know the secret key, you are not going to find out what is in the message.

Sounds great! Where do I sign up? Many alarm manufacturers use encryption, and many don’t do it quite right.

Designing a good encryption scheme is hard

A famous saying is:

“Anyone can invent an encryption algorithm they themselves can’t break; it’s much harder to invent one that no one else can break”

Time and time again, custom built encryption algorithms have been broken.

Again, I’m sure there is a more concise saying about this, but I subscribe to this:

For a defender to succeed, he must have a 100% success rate against multiple attacks and attackers.

For an attacker to succeed, he only needs to succeed once.

What’s the solution to this:

  1. Use something off-the-shelf. There are mathematicians and developers who only develop encryption. Use their skills, don’t try to use your own.
  2. Open your code up – no encryption algorithm or implementation should be weakened by an attacker seeing the code. So open it up and let other people tell you the problems!

Encryption is often good in theory and fails in the implementation

Very closely linked to the above point – even if you use something off the shelf, make sure you use it right!

Common mistakes are:

  • Leaking key material by XORing the key with a constant padding value (in a previous post!)
  • Building a really strong encryption scheme but then failing to exchange the key in a secure way (i.e. you show everyone the key!)

Encryption by itself does not stop replay attacks

If the message “disarm the system” becomes “fodst, yjr dudyr,” when encrypted, there may be no easy way for the attacker to decode that message. Indeed, there would be no easy way for him to encode that message unless he had the key.

This may not matter though. You can infer what the message contains based on timing (the homeowner has just arrived, and pressed the disarm button), and replay the encrypted packet alone. You need to combine encryption with other techniques to ensure integrity and protect against replays.

Using a fixed key across all products

Again, this is partly the result of using a one-way radio system. Before the detector and panel can communicate, they need to perform key exchange, so that they both know the secret key. There are a few options here:

  1. You can send the key in the clear when paired and hope no one is listening.
  2. You can use a secure method of exchanging keys (like public key cryptography)
  3. You can program the key in during manufacture

Method 3 is attractive. On paper, your system is “encrypted” – you could even claim AES-128 encryption. But if that key is constant across every detector and every panel you sell, you have a problem. Why is this?

Firstly, you can never really assume that your code is safe. Whilst most modern microprocessors have some means of protecting code, this is by no means fail-safe. Sometimes designers forget to set the lock bits (well, quite often in fact), and the code can just be read out. Some PIC processors are vulnerable to a simple attack where you can recover 75% of the code from one device, and the remaining 25% from another (one manufacturer’s detectors have this issue). If you want to go further, you can decapsulate the microcontroller and read one-time-programmable memory visually – this is possible in the real world.

Secondly, it is sometimes the case that the alarm architecture means that I don’t need to know this key. Some alarms have an RF SoC performing all encryption – the main microcontroller just passes it simple unencrypted data. I can decouple the RF SoC and send my own, unencrypted data, and let the SoC do the hard work for me.

Thirdly, manufacturers offer firmware upgrades for download. These can contain the secret key material. It’s often easy to find – key material should look very random (more random than normal code). I have a simple tool to scan a file and graph entropy. It’s fairly easy to find key material using this, especially if you know how long the key is.

Using too short a key

One method of breaking encryption is to just try every single key and hope for the best – this is called “brute forcing“.

If the key is short, this process can be very quick.

Each time I add a single bit to a key, I double how many possibilities there are. A 1-bit key has 2, a 2-bit key 4, 3-bit has 8. This rapidly hits very large numbers – even at 32-bit we have 4294967296 keys. But modern computers are very, very fast – checking 100,000 keys a second is possible. That 32-bit key would fall in under 12 hours.

So key length has a big impact on how long it takes to perform this process. It’s now pretty much assumed a key length of 64-bits and under is too short to protect against brute forcing. But DES and other encryption methods still support 40-bit and 56-bit keys. If the option is there, people will take it.


Encryption is important in a wireless protocol if you want it to be genuinely secure – but it is only part of picture. If implemented badly, it can add little security and decrease reliability and usability.

2 thoughts on “Encryption is only part of the solution

  1. Permalink  ⋅ Reply


    May 3, 2013 at 1:05pm

    word up. btw these days for scanning entropy in files i use this branch of libdisorder and gnuplot instead of my python script:

    > ./tools/tropy /bin/ls | gnuplot -p -e ‘plot “-” using 2:4;’

    https://github.com/cyphunk/libdisorder (push still waiting for merge so just use that version. provides tropy)

Leave a Reply

Your email will not be published. Name and Email fields are required.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">