With the rise of low-energy wireless communication, come new implications and security threats one may consider, before releasing a new product.
In this post, we are going to take a closer look at the enOcean technology, how security is implemented, and if the security measures and options available are sufficient.
We will do that, with a case study of a switch.
What is enOcean
enOcean is a wireless technology for low-energy and energy harvesting applications and systems. Its range is lower than 30m and thus is primarily used in building automation systems and communication in devices such as wireless sensors and switches without batteries.
It is the equivalent of LoRAWAN, but for close range, similar to Bluetooth:
A nice feature of enOcean is encryption. We will look into it, once we analyze the packet structure. But first, let us take a look at the setup for our case study. If you want, you can follow along and analyze it by yourself as well!
Setup
- PTM215 Push-Button (Sender)
- USB 300 (Receiver)
- DolphinView Advanced (Visualizer- Software)
- Software Defined Radio Device like the nuand BladeRF (I will call this SDR Device from now on)
The PTM215 button can send encrypted and unencrypted messages.
The USB300 Receiver will be connected to a Windows PC, which has DolphinView installed. Every message sent from the PTM215 will now be visible in DolphinView.
If the button sends the messages encrypted, DolphinView will show them encrypted as well. This can be circumvented (if desired) by sharing the symmetric key of the button with DolphinView.
The SDR Device may come in handy later on when analyzing the packets on a more low-level basis.
Transmitted Information
With the setup done, we are now able to analyze the traffic on different levels and see what information is transmitted over the air. The goal of this section is to determine, if we can gather useful information for an attack or exploit.
Telegrams
The packets in enOcean are called telegrams.
There are different telegram types:
- SWITCH telegram
- Standard telegram
- Encrypted telegram
A comparison of the telegram types can be read from this illustration:
Parts
- RORG: Radio ORG = organization number for enOcean radio telegram types
- RORG S: The four RORG 0x30, 0x31, 0x32, 0x35 are reserved for encrypted telegrams. If the “RORG” is one of them it is a RORG S and indicates that the telegram is encrypted.
- Payload: Data that should be transmitted. The encrypted payload consists of the encrypted RORG, encrypted payload and CMAC
- ID: The ID is always transmitted plain, since the receiver has a map of <ID, EncryptionKey>.
- State: The state has to be changed by repeaters and is therefore not encrypted as well.
- Checksum: Used to verify that no transmission errors occurred
Switch telegram
The switch telegram is shorter than a standard telegram. It does not contain any state and can have the RORG 0x5 or 0x6.
It is possible to convert the RORG of the switch telegram into a “real” RORG and a state:
| switch telegram RORG | converted RORG | state |
|---|---|---|
| 0x5 | 0xF6 | 0x20 |
| 0x6 | 0xF6 | 0x30 |
Encrypted telegram
The enOcean encrypted telegram use a custom scheme to generate a keystream which is XORed with the data. This allows for the output to be the same length as the input.
Most payloads are shorter than 128 bit and with the Variable-Mode much overhead can be saved, which is nice for Low- Energy devices, but could have some security implications.
Signal
By using the SDR Device, we can capture signals from 300MHz to 3.8GHz. That is great, because the enOcean signals have a frequency of 868.3 MHz.
We could now use this device to record, store and replay the messages, which allows us to perform simple replay- attacks. The goal is to read the signal as a binary stream.
To transform the signal into binary, “readable” data, we can use a software like Gnuradio- Companion and Inspectrum. We will use a simple plain signal for simplicity
With Inspectrum, we are able to determine that it uses On-Off Keying and that the baud rate is 125kHz.
We can use this information together with Gnuradio- companion and process the signal by building the processing with a block diagram.
This should return the follwing data:
| Binary | Hex |
|---|---|
| 0000 0000 0000 0000 0101 0101 0110 1010 0110 1010 1110 1001 0010 0001 1001 0010 0101 0001 1010 0001 1001 0010 1110 1010 0101 0000 0000 0000 0000 00 | 0x00 00 55 6A 6A E9 21 92 51 A1 92 EA 50 00 00 |
With the help of the ISO/IEC 14543-3-10 standard, we can decode our “physical layer”. It states that the bits should be read inverted:
All elements except data are used for synchronization and signal quality checks. If we strip them and keep just the data we get the following message:
| Binary | Hex |
|---|---|
| 0101 0001 0000 1111 1110 1111 1011 1101 1110 1111 0000 1010 | 0x51 0F EF BD EF 0A |
Or as telegram:
| RORG | 0x5 |
|---|---|
| Payload | 0x10 |
| Sender-ID | 0xFE FB DE F0 |
| 4Bit- Checksum | 0xA |
Which is a SWITCH telegram, that can be converted into a standard telegram:
| RORG | 0xF6 |
|---|---|
| Payload | 0x10 |
| Sender-ID | 0xFE FB DE F0 |
| Status | 0x20 |
| 4Bit- Checksum | 0xA |
The analysis of a encrypted signal gives an equivalent result.
Conclusion
We were able to identify some interesting data, but we could not get any information about the encryption key or information about the transmitted data (if it iss encrypted).
So far the attacker could:
- Determine if it is an encrypted message based on the RORG
- Determine the size of the plain message from the encrypted message
- Analyze the plain ID’s and determine with statistical analysis, what kind of sender it could be (e.g. button → irregular sending, sensor → regular sending)
Possible attacks
DolphinView allows transmitting telegrams, but does not allow to choose an arbitrary Sender-ID. The Online Docs of DolphinView state: “Due to
security reasons it is only possible to set an ID within the range of the base ID, other ID’s will be rejected.“
But by using our handy SDR Device, we could create a python script to send arbitrary data via the physical layer. We have all the information we need to construct our telegram from the section about the physical layer.
When trying this, you can see, that DolphinView can’t distinguish it from a real telegram. This allows an attacker to repeat a message or manipulate it and the repeat it.
We are aware of a public building that features enOcean emergency push buttons which could become a victim to the following attacks:
- Listening in on the traffic of a home, by installing a “repeater” that will send all messages to a C2 server
- Jamming the signals. This could prevent light control, temperature control or even emergency buttons (like the ones they use in nursing homes) to work properly
- If the signals are not sent encrypted, an attacker could capture, manipulate and replay arbitrary signals. This would allow him to control components like light, temperature and more
Special mention
The findings on enOcean were developed as part of a master’s thesis and in collaboration with the HSR electrical engineering department, Reto Bonderer and Heinz Hofmann.
Leave a Reply