Hi, as mentioned in whats-the-status-of-io-homecontrol-velux, there seems to be no one having the io-homecontrol wireless protocol decoded yet.
My question is: Would it be feasible to decode the wireless protocol?
My first thoughts about this are:
- Use a software defined radio (SDR) and maybe GNU Radio to capture the signal
- Gather information about the encoding
- See if one can get something out
- Re-Implement the protocol with sub 1GHz transmitter chip?? (e.g. cc1101)
Some (weak) information about the protocol
- Sadly they use “3 split sub-wavebands” (868.25 MHz, 868.95 MHz and 869.85 MHz) according to the adf7022 product site, which I dont know how to handle with GNU Radio
- They use AES 128bit encryption for some of their communication
- On page 14 of interconnectionconsulting’s-pdf there is a single graphic about the authentication process
- The following link is currently (07.2016) down, but (if up again) he is already usesing GNU Radio to capture a io-homecontrol signal From_Baseband_to_bitstream
- BitRate 38,4Kbps, AES 128 bit encryption
- io-homecontrol guide_io_en.pdf points out that there is a keyexchange at some point:
Each io-homecontrol ® installation has its own encryption key, which is present in all io products in the home.
This key is automatically activated when the installation is first used. The emitter (the remote control) issues its encryption key to the receiver (e.g. an io roller shutter) once and once only.
Oh and I already tested a cheap SDR (a rtl-sdr device) with GNU Radio, but its currently very low tech, but I received signals from one of my remotes.
I managed to record the transmitted frames and started dissecting them.
I own some Somfy-devices running on the homecontrol-standard.
My learnings so far:
- the slides from the nccgroup are misleading. The data seesm NOT to be manchester encoded - it is just a bare bitstream @ 38.4 kbaud
- Bitsynchronisation happens via a quite long snyc sequence in front of the actual data.
The packet length I see is 37 bytes
- Quite a lot of data seems to be “clear text” as it can be predicted easily and is repeated, so the packets are not encrypted, but just “signed”
- There are 88 bits which seem random and are likely the signature and the CRC.
- even though stated otherwise, at least somfy does not seem to use a bidirectional communication for normal commands. (Unplugging the receiver does not change anything seen from the transmitter)
- My devices send three packages, each slightly different from the other and repeats each of the three four times. The first contains the command itself, the others are even more static.
- I guess it would be easy to build a receiver which detects the commands, but it will be very hard to dig deeper into the data to beeing able to transmit. Nevertheless, analyzing different packets will give a good hint of the difficulties with the encryption.
As I don’t own a SDR Device that is able to TX, I cannot test to replay data.
Did you gain any more insights yet?
Sidenote: Cryptography experts usually say: A system which is based on hiding the underlying algorithm is never safe. Somfy/Velux/Io-Homecontrol are trying exactly that - let’s see how successful they will be…
My guess: It will be possible to fully decode/encode it
great work, I’d love to see more…
Could you share your setup (e.g. GNU Radio config exports, screenshots, data, … you name it) to maybe get things going a little bit more easily for others?
I agree, sadly I’m neither a crypto- nor a radio-expert - yet.
sure, I can share that stuff. Due to limitations for ne usesr here of just one picture per post, I have to split this into multiple postings. Hope this does not matter too much.
Reception and Demodulation
I use a NESDR SMArt from NooElec.com (simple and cheap SDR based on the RTL2838)
to be continued…
The resulting “analog” signal can be stored in a wav file which, cropped to one transmission, looks like this:
- There are three groups of four packets each
- The four packets in each of the groups are bitwise identical.
… to be continued … some other time - I cannot create any more posts due to another limitation for new users… max three posts.
You can find all I wanted to post in the docu_post.pdf file on GitHub whei I also placed the code and GRC-Files.
Direct Link: https://github.com/101010b/io-home/blob/master/docu_post.pdf
Hope that works…at least
I hate to revive this topic after two years, but the documentation of the io-homecontrol key exchange process is so poor. Has someone been able to find out about it more than this?
Each io-homecontrol® installation has its own encryption key,
which is present in all io products in the home.
This key is automatically activated when the installation is first
used. The emitter (the remote control) issues its encryption key
to the receiver (e.g. an io roller shutter) once and once only.
Like, what exactly is an io-homecontrol installation? Is it the remote control which has the encryption key? And what is ment by “automatically activated when the installation is first used”? What installation can be used only once?
I understand this “Documentation” as:
- Some device has the encryption key.
- When adding a new io device to your home it receives the encryption key from this device.
- Now they can validate each others messages.
But who exactly has the key in the first place? And why is there no in depth documentation to this process?
One thing that bothers me is the part in which they explain the installation key is sent. Is it in clear? If an attacker can force a master device to enter sync mode, it may be stolen.
To answer your question about an io-homecontrol installation, this is either the remote/actuators set or the base station (TaHoma, Connexoon, etc.) and all its sensors/remote controls/actuators.
To put it simply, if you have several io-homecontrol devices associated with a TaHoma - or equivalent - station, all the devices will share a same installation key. In the other case, each remote control has its own installation key shared among all the associated devices. If you have several remotes with no common devices, they will have different installation keys.
I don’t clearly know for the remote controls, but the TaHoma generates an installation key at its first launch. I saw some lua functions dedicated to refresh it although I don’t know in which circumstances they are called.
The installation key is given only once to a device associated (to avoid replay attacks maybe?). The same device won’t be able to request one more time a same installation key (e.g. if it is associated with another installation). But all this is only hypothetical since I don’t have much more details.
The installation key is, according to my understanding, owned by the controller. Either the base station (TaHoma) or the remote control.
And for the documentation part, Somfy has made the choice to not let its users customize its products and protocols. The io-homecontrol documentation exists but you need to have an NDA. Because, you know, intellectual property.
Some people are working to get a reverse engineered specification (at least I’m trying) though.
I’m not sure whether this information adds any value, but anyway:
Let’s say you have two windows and two KLR100 remote controls. You can either set up each KLR100 to control exactly one window, each using different keys. Or you can set up one KLR100 to control both windows using the same key. You can then transfer the key and information about the windows between the two KLR100s, resulting in all four devices using the same key.
The KLR100 has a menu option to reset the key. It generates a new key (16 bytes) and stores the old key in a backup location. The old key might be used to send a key update to other devices, but I’m unsure about that. IIRC my KLR100 was isolated immediately after triggering the reset and the active key had to be resent from a second remote control to restore operation. Reset it two times in a row, and the remote control will have no knowledge of the previous key. If you resend the key from a second remote afterwards, you should be able to capture the transmission (if not every time).
Windows usually have a way to reset their key, too, or at least to enter a learning mode. Usually when they’re already open and were without power for a few seconds.
Anyway, initial key transmission has to be either cleartext or protected by a PSK known to all compatible devices. If the latter, then I’d guess this key, as well as the signature algorithm, resides in the MCU firmware, which can be found in TaHoma’s filesystem, for example. Unfortunately, it uses a pretty rare instruction set.