- Hardware-wise, the device is pretty minimal – it seems to be based on the Cypress WICED IoT platform, with 100MBit ethernet and a Silicon Labs Zigbee chipset.
- As IoT devices go, it’s pleasingly minimal.That single port seems to be a COAP server running with DTLS and a pre-shared key that’s printed on the bottom of the device.
- The Android app has code for using the insecure COAP port rather than the encrypted one, but the device doesn’t respond to queries there so it’s presumably disabled in release builds.
- _udp.local query to allow for discovery.From a security perspective, this is pretty close to ideal.
- You can only authenticate with the device if you have physical access to read the (decently long) key off the bottom.
@mikko: IKEA sets an example on how to do IoT security.
Ikea recently launched their Trådfri smart lighting platform in the US. The idea of Ikea plus internet security together at last seems like a pretty terrible one, but having taken a look it’s surprisingly competent. Hardware-wise, the device is pretty minimal – it seems to be based on the Cypress WICED IoT platform, with 100MBit ethernet and a Silicon Labs Zigbee chipset. It’s running the Express Logic ThreadX RTOS, has no running services on any TCP ports and appears to listen on two single UDP ports. As IoT devices go, it’s pleasingly minimal.
That single port seems to be a COAP server running with DTLS and a pre-shared key that’s printed on the bottom of the device. When you start the app for the first time it prompts you to scan a QR code that’s just a machine-readable version of that key. The Android app has code for using the insecure COAP port rather than the encrypted one, but the device doesn’t respond to queries there so it’s presumably disabled in release builds. It’s also local only, with no cloud support. You can program timers, but they run on the device. The only other service it seems to run is an mdns responder, which responds to the _coap._udp.local query to allow for discovery.
From a security perspective, this is pretty close to ideal. Having no remote APIs means that security is limited to what’s exposed locally. The local traffic is all encrypted. You can only authenticate with the device if you have physical access to read the (decently long) key off the bottom. I haven’t checked whether the DTLS server is actually well-implemented, but it doesn’t seem to respond unless you authenticate first which probably covers off a lot of potential risks. The SoC has wireless support, but it seems to be disabled – there’s no antenna on board and no mechanism for configuring it.
However, there’s one minor issue. On boot the device grabs the current time from pool.ntp.org (fine) but also hits http://fw.ota.homesmart.ikea.net/feed/version_info.json . That file contains a bunch of links to firmware updates, all of which are also downloaded over http (and not https). The firmware images themselves appear to be signed, but downloading untrusted objects and then parsing them isn’t ideal. Realistically, this is only a problem if someone already has enough control over your network to mess with your DNS, and being wired-only makes this pretty unlikely. I’d be surprised if it’s ever used as a real avenue of attack.
Overall: as far as design goes, this is one of the most secure IoT-style devices I’ve looked at. I haven’t examined the COAP stack in detail to figure out whether it has any exploitable bugs, but the attack surface is pretty much as minimal as it could be while still retaining any functionality at all. I’m impressed.
 Formerly Broadcom
Reading up on the product it seems like they want to add ‘away from home’ features in the future that would probably contact their servers. Would you retest if/when they do?
Without having looked inside the signed images at all and only having superficially looked at version_info.json, I don’t see anything that obviously contributes to freshness checking; if this is indeed missing then it might be possible for an attacker to silently prevent legitimates updates reaching the device or (depending what other checks are done elsewhere) roll firmware back.
It’s actually mildly worse than that. The hub sends an if-modified-since request and is happy to take a 304, so that’s all an attacker would need to send. But it’s not clear what it would be meaningfully able to do if an attacker just inserted 404s instead, so I suspect the answer remains “Don’t lose control of your DNS”
Depends what the higher level behavior is like – “everything is fine, no updates required” is distinct from “I have not been able to reach my update server for a year”.