Shortly after its release in 2017, we put the smart lighting system IKEA TRÅDFRI through its paces in our security test. Three years have passed since then: Time to look back and see what has been achieved with this product. Can the system, now renamed IKEA Home smart and with a wider product portfolio, still be recommended as a secure smart home solution? You will find out in the following test report.
In recent years, IKEA has continuously maintained and expanded its smart home programme. In addition to numerous light sources, roller blinds and smart speakers are now also available from the Swedish furniture giant. The Smart Speakers were developed together with Sonos. The Sonos Play:1 was not only the basis, but was also already in our security test.
Setup
Unlike the setup of other smart home systems, IKEA Home smart does not require any registration. Once the TRÅDFRI gateway is connected to power and connected to the network via Ethernet cable, the user can add the gateway to the app by scanning the QR code on the gateway. This contains both the MAC address and a security code that is used for encryption in the ongoing communication.
Once the lights have been added through the app, the system is ready for operation. At the time of testing, there is no remote access available yet. However, other solutions such as Homematic IP show that online access is possible without any registration – we therefore hope that IKEA will use similar means if this should ever be implemented.
Local communication
The system does not necessarily have to be controlled via the available Android or iOS app. The lights can also be controlled directly via the remote control or motion sensor, for example.
The TRÅDFRI Gateway, which can be controlled via the app, enables precise control of light color and brightness, setting of timers, grouping of devices in rooms and connection to Amazon Alexa or Google Assistant.
The communication between Android/iOS App and the gateway takes place over UDP and is always DTLS1.2 encrypted, a TLS implementation for UDP. This protects the communication against many threats such as replay attacks by design.
For the communication between app and gateway CoAP (Constrained Application Protocol) is used, a REST-like interface. Various open source products make use of this API and thus integrate the Ikea Home smart system into other smart home solutions.
Online communication
When the TRÅDFRI Gateway is started, TLS1.2 encrypted communication to webhook.logentries.com takes place. The gateway contacts the server at regular intervals during operation. Logentries.com is an analysis service for log files, which enables IKEA to analyze errors more quickly, for example.
Subsequently, an unencrypted channel is used to check for available firmware updates, which we will discuss in a separate section. Internet communication to servers other than those mentioned did not take place during the test.
App
As stated in the last test, IKEA has done a good job in developing the IKEA Home smart app and has placed great emphasis on the security of the solution right from the start.
The app data, which includes the needed credentials to access the TRÅDFRI gateway, is securely encrypted using the Android KeyStore. Therefore they are secure from unauthorized access even on rooted devices. For this purpose, the app generates a secure key pair and stores it in the KeyStore provided by Android. With the help of the public key the sensitive information is then stored encrypted.
According to static analysis, the app does not contain any known trackers, so it does not monitor every single action of the user.
Firmware-Update
The only point where we already wanted an improvement in our 2017 test was the firmware update. As it turned out, unfortunately nothing has changed in this point. We will nevertheless go into the update process in more detail in the following.
At boot time, the TRÅDFRI Gateway checks for new firmware versions both for itself and for all devices connected via Zigbee Light Link ( lights, remote controls, motion sensors etc.). For this purpose, the version_info.json is downloaded via an unencrypted connection, which contains information about all current firmware versions. This was already mentioned by us in the test 3 years ago and we still wonder, why the available HTTPS endpoint, which also got a correct certificiate, is not being used.
We took a closer look at the firmware of the gateway. It mainly contains an ELF (Executable and Linking Format) binary file (for 32bit ARM CPU, Duo Cortex-M3) and is signed.
The signature of the firmware enables the gateway to check whether the firmware has been manipulated. Nevertheless, there are attack scenarios that should not be left out.
By redirecting the DNS requests to a dedicated server or a man-in-the-middle attack, the version_info.json could be manipulated. This could lead to a firmware downgrade attack as well as a denial of service attack. For both attacks, the version number of the available firmware would be incremented. In the case of a downgrade attack, a link to an older firmware would be created, for example with known, exploitable vulnerabilities. In the case of a DoS attack, it would be sufficient to leave the original links in place and increment the version number continuously. This would permanently disable the gateway through reboots and firmware installations.
Both can be resolved by using authenticated DNS answers (DNSSEC) and an encrypted transmission including correct certificate validation.
Projects can be found in the web, which can access the firmware via the contacts of the respective board. This opens up a wide range of possibilities, example links are given below. We name the projects here only for completeness – the methods used are not included in the evaluation.
- Heise: Trådfri: ESP8266-Lampen-Gateway (in German language)
- Github: TRADFRI-Hacking
- Trammell Hudson: Trådfri Hardware Modifications
Privacy
For a system that hardly communicates with the Internet, the privacy policy was already very detailed in 2017. In the meantime, it has become possible to connect Ikea Home smart to Amazon Alexa and Google Assistant. For this purpose, an access code is generated that enables the TRÅDFRI gateway to be uniquely identified.
The current privacy policy for the IKEA Home Smart programme is easily understandable and provides the user with very detailed information on all privacy related topics. No registration is required for operation, only a small amount of personal data is collected. The recorded data includes the IP address and, if used, the access code for Amazon Alexa and Google Assistant. In addition, diagnostic information is recorded, consisting for example of technical information on the product, smartphone and network used. Usage information of the App is recorded in a non-identifiable form. In addition to diagnostic data, this information is used for product development or improvement and support and is stored for a maximum of one year.
Anonymised/pseudonymised usage data is shared with partners. Furthermore, an analysis of the usage is carried out by analysis services which are not necessarily located in the European Union, but are certified by the Privacy-Shield.
Apart from the exemplary privacy policy, however, one point remains open: The Android app now requires a phone permission in addition to the camera permission (scanning the QR code to set up the product). This is not mentioned in the privacy policy, but was also not asked for in the test. You might think that this permission is required for the built-in Sonos components, but the Sonos app does not use this permission. It is up to IKEA to provide clarification here.
Conclusion
The Swedish furniture giant has not cut back on the budget for the security of the product, despite its low price. The actually secure product is compromised by downloading the firmware via HTTP, even though the potential danger in private households is probably not worth mentioning. In households with increased security needs, we recommend using a separate network/VLAN.
You didn’t mention open http port though, which may presumably be used as a backdoor. No idea what it does but it exists:
20:48:12.920796 IP 10.0.0.225.49956 > 10.0.0.238.80: Flags [S], seq 1729271498, win 64240, options [mss 1460,sackOK,TS val 3638891478 ecr 0,nop,wscale 7], length 0
20:48:12.921011 IP 10.0.0.238.80 > 10.0.0.225.49956: Flags [S.], seq 443710303, ack 1729271499, win 7168, options [mss 1460,wscale 0,eol], length 0
20:48:12.924308 IP 10.0.0.225.49956 > 10.0.0.238.80: Flags [.], ack 1, win 502, length 0
20:48:12.925085 IP 10.0.0.225.49956 > 10.0.0.238.80: Flags [P.], seq 1:322, ack 1, win 502, length 321: HTTP: GET / HTTP/1.1
20:48:12.925297 IP 10.0.0.238.80 > 10.0.0.225.49956: Flags [.], ack 322, win 7168, length 0
20:48:12.925299 IP 10.0.0.238.80 > 10.0.0.225.49956: Flags [P.], seq 1:51, ack 322, win 7168, length 50: HTTP: HTTP/1.1 470 Connection Authorization Required
20:48:12.930403 IP 10.0.0.225.49956 > 10.0.0.238.80: Flags [.], ack 51, win 502, length 0
20:48:13.924453 IP 10.0.0.238.80 > 10.0.0.225.49956: Flags [F.], seq 51, ack 322, win 7168, length 0
20:48:13.928024 IP 10.0.0.225.49956 > 10.0.0.238.80: Flags [F.], seq 322, ack 52, win 502, length 0
20:48:13.928224 IP 10.0.0.238.80 > 10.0.0.225.49956: Flags [.], ack 323, win 7168, length 0
Hi Ruff,
Thanks for your message. Yes you are right there is an open HTTP port which we saw as well. Since our analysis didn’t show any security problems we didn’t mention it this time.