IKEA Trådfri Gateway [Zigbee]

Development
1

Started playing around with the gateway that I bought earlier tonight. I’ve been able to setup my router so that I can monitor traffic between my phone (hosting the IKEA app) and the gateway.I realize that I’m a bit over my head here but who knows, there might be someone here who can help me progress my work?

192.168.0.188 is my phone and 192.168.0.129 is the IKEA gateway. This is the tcpdump-command I’m using to monitor data:

tcpdump -ennvvvXXSs 1514 -i eth0 'dst 192.168.0.129 or ( vlan and dst 192.168.0.129 )'

This is what happens when I set the light to max in the app:

01:09:19.553148 xx:xx:xx:xx:xx:xx > xx:xx:xx:xx:xx:xx, ethertype 802.1Q (0x8100), length 79: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 49576, offset 0, flags [none], proto UDP (17), length 61)
    192.168.0.188.57891 > 192.168.0.129.5684: [udp sum ok] UDP, length 33
        0x0000:  xxxx xxxx xxxx xxxx xxxx xxxx 8100 0001  .r.'...A_q.i....
        0x0010:  0800 4500 003d c1a8 0000 4011 367a c0a8  [email protected]..
        0x0020:  00bc c0a8 0081 e223 1634 0029 4c11 17fe  .......#.4.)L...
        0x0030:  fd00 0100 0000 0000 1400 1400 0000 0000  ................
        0x0040:  0000 14d9 30bf f309 7937 08c0 ba0b 86    ....0...y7.....

And this is what happens I set the light to min (turn it off.) Yes, two commands are sent

01:10:02.016296 xx:xx:xx:xx:xx:xx > xx:xx:xx:xx:xx:xx, ethertype 802.1Q (0x8100), length 79: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 31962, offset 0, flags [none], proto UDP (17), length 61)
    192.168.0.188.57891 > 192.168.0.129.5684: [udp sum ok] UDP, length 33
        0x0000:  xxxx xxxx xxxx xxxx xxxx xxxx 8100 0001  .r.'...A_q.i....
        0x0010:  0800 4500 003d 7cda 0000 4011 7b48 c0a8  ..E..=|...@.{H..
        0x0020:  00bc c0a8 0081 e223 1634 0029 0196 17fe  .......#.4.)....
        0x0030:  fd00 0100 0000 0000 1d00 1400 0000 0000  ................
        0x0040:  0000 1dba d111 bf7f 0d5f c695 efdf ca    ........._.....
01:10:02.022176 xx:xx:xx:xx:xx:xx > xx:xx:xx:xx:xx:xx, ethertype 802.1Q (0x8100), length 79: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 35537, offset 0, flags [none], proto UDP (17), length 61)
    192.168.0.188.57891 > 192.168.0.129.5684: [udp sum ok] UDP, length 33
        0x0000:  xxxx xxxx xxxx xxxx xxxx xxxx 8100 0001  .r.'...A_q.i....
        0x0010:  0800 4500 003d 8ad1 0000 4011 6d51 c0a8  [email protected]..
        0x0020:  00bc c0a8 0081 e223 1634 0029 358f 17fe  .......#.4.)5...
        0x0030:  fd00 0100 0000 0000 1e00 1400 0000 0000  ................
        0x0040:  0000 1eeb 15b9 42b2 e36c e5a5 30be 96    ......B..l..0..

Since “xxx xxxx xxxx xxxx xxxx xxxx 8100 0001” shows up every time, I’m guessing (for now) that’s the address of the bulb. However, the app references iCoAP and Wolfssl. Is that to say that strong encryption is used, thus rendering any attempt to build a custom integration uesless? What do you guys think?

5 Likes
2

Had some time this morning to play around a bit more. Didn’t have any prior experience to the UDP-protocol, but I now understand that much of the excerpt above is header information, which contains IP- and MAC-address among other things. Imported my tcpdump into Wireshark and noted that everything listed under Application Data is communicated under the DTSLv1.2 protocol:

Hope to be able to continue exploring during the day.

1 Like
3

yeah, and soon integrated in HASS!

1 Like
4

I also spoofed the traffic yesterday and found out that they are using DTLS v1.2 for security. The cipher used is TLS_PSK_WITH_AES_128_CCM_8. The problem right now is to “find” the shared key used. A security code is printed on the gateway. This is used when pairing the application with the gateway. l tried to use this (converted it to hex first) in Wireshark but the data is still encrypted.

Perhaps is the code hashed with MD5 and then used in the TLS handshake…it can also have been “or:ed” with the MAC and hashed and used as a key…

Still a lots of trial and error…any suggestions?

5

Interestingly, I was able to add my Philips Hue bulbs into the IKEA app by using the IKEA remote to pair the lights. Unfortunately, I could no longer control the light from the Hue app having done this pairing.

1 Like
6

Downloaded the APK-file for the app from Google Play, renamed it to a .zip-ending and had a look at the files in there. There is, among other things, a key-file and reference to WolfSSL and CoAP in the dex-file.

7

Decompiled the dex using dex2jar and viewed it in jd-gui. Still on the search for the structure of the psk (pre-shared key) and the client identity. Found a key-file in the apk with the key Bar12345Bar12345 (seems to be default when using CoAp library). Tried that one as psk but no luck.

Some suggestions for psk

  • Security code (printed on the gateway)
  • Serial number (MAC-address). Also printed on the gateway
  • Key from file, key-file.txt (Bar12345Bar12345)
  • Some of the parameters above hashed together

More info regarding the libraries used:

8

Do you have multiple bulbs it would be nice with 2 dumps, one where you turn off 1 light and another where you turn off the other.

Also it could be usefull if you provide multiple dumps turning off the same light, just to see if it sends the exact same data each time.

But the good news is that it seems to send the data directly from the phone to the gateway instead of using some cloud service.

Also could you include the response the app sends?
Now i have never used tcpdump but couldn’t you write something like (dst 192.168.0.129 and src 192.168.0.188) or (src 192.168.0.129 and dst 192.168.0.188)?

Also the following might be usefull the java documentation for wolfSSL https://www.wolfssl.com/documentation/wolfssl-jni-javadocs/index.html

Edit: It seems the WolfSSLContext controls the encryption and it is created in the /com/ikea/tradfri/lightning/coap/WolfConnector.java class, the problem is if DTLS works the same way that TLS does then we wont be able to decrypt it even if we manage to find the key as that key is only used to encrypt not decrypt…
At least i managed to find the cipherlist PSK-AES128-CCM-8:PSK-AES128-CBC-SHA256;

9

I found the same keys when listening to the traffic between ios and gateway. I.e. PSK-AES128-CCM-8:PSK-AES128-CBC-SHA256

10

@stenehall i don’t think that is the key, my guess is that it just describes how to encrypt and sign the packets.

11

As the network packets are encrypted the way forward has to be to decompile the APK and add breakpoints to study the data.
I have some other projects i want to finish first then ill look at it (not having a physical android phone might make this impossible for me to do), but i found a nice tutorials if anyone is up for the task.

12

Perhaps useful information (Newer version of Wireshark to decode DTLS properly).

https://ask.wireshark.org/questions/55487/decrypt-application-data-pending-dtls-abbreviated-handshake-using-psk

More information about cipher used

http://vs0.inf.ethz.ch/

Client identity and pre-shared key are mandatory to make the magic happen. Then we could listen to the traffic from the application to the server and write an application that act as the app (still have to use DTLS but thats a minor issue).

13

It seems they are working on DTLS 1.2 in PyDTL so that shouldn’t be a problem, tho it would add a dependency on OpenSSL.

14

https://bitsex.net/software/2017/coap-endpoints-on-ikea-tradfri/

6 Likes
15

Thanks for the link @Danielhiversen! From there, it shouldn’t be that tricky to build an integration into HA. Just tried downloading a few python-based CoAP-implementations, of which one was based on Python3. Have to resume tomorrow as I’m on a too low version level of Python.

1 Like
16

Nice work. Had problems with PSK in a too old version of Wireshark when rev. engineering communication. Are you using the PSK unmodified from the sec code? What are they using as “Client Identity” in DTLS?

…and again, really great work. Time to download CoAP- and DTLS-library in fav. lang.

17

Another forum has linked to this thread and an interesting post regarding libcoap and the dtls branch was just posted. Check out the post by arturo182 here:
ttps://github.com/bwssytems/ha-bridge/issues/570

1 Like
18

After pairing the hue bulb with the IKEA gateway did it work as intended from the IKEA app? (Was it a white or multi colored bulb?)
Also any chance you could try with a hue light strip? (it seems IKEA has no plans of adding a smart light strip when i asked their support last time).

19

Based on what I’ve found so far online, I’ve put together a very simple implementation on my raspberry pi. Taking no credit of all the hard work others have put in and just put my code here if you want to play around :slight_smile:

I first installed the libcoap-library as such:

apt-get install libtool

git clone --recursive https://github.com/obgm/libcoap.git
cd libcoap
git checkout dtls
git submodule update --init --recursive
./autogen.sh
./configure --disable-documentation --disable-shared
make
sudo make install

I’ve put together a very simple Python-script that I’m planning to execute by running a shell_command:

Edit: depreceated, please look at the Github-link below instead.

You then run the code by invoking:

python ikea.py "65537"  "100" "Yellow"

Or, from within Home assistant as a shell command:

ikealight_off: '/usr/bin/python3 /home/homeassistant/.homeassistant/extraconfig/python_code/ikea.py "65537"  "0" "Yellow"'
1 Like
20

To make code maintenance a bit easier, I’ve put the script here:

https://github.com/ggravlingen/home-assistant/blob/master/extraconfig/python_code/ikea.py

2 Likes