![[personal profile]](https://web.archive.org/web/20170717133102im_/http://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Ikea 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[1] 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/
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.
[1] Formerly Broadcom
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/
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.
[1] Formerly Broadcom
no subject
Date: 2017-04-09 02:00 am (UTC)no subject
Date: 2017-04-09 02:07 am (UTC)COAP
Date: 2017-04-09 02:05 am (UTC)no subject
Date: 2017-04-09 02:36 am (UTC)no subject
Date: 2017-04-09 02:37 am (UTC)no subject
Date: 2017-04-09 08:49 am (UTC)no subject
Date: 2017-04-09 09:23 am (UTC)no subject
Date: 2017-04-09 09:39 am (UTC)no subject
Date: 2017-04-10 05:46 pm (UTC)no subject
Date: 2017-04-09 10:39 am (UTC)it's painful to read
Date: 2017-04-09 04:17 pm (UTC)Re: it's painful to read
Date: 2017-04-11 01:58 pm (UTC)wireless connection
Date: 2017-04-09 06:20 pm (UTC)Re: wireless connection
Date: 2017-04-09 07:21 pm (UTC)no subject
Date: 2017-04-10 07:02 am (UTC)https://github.com/bwssytems/ha-bridge/
no subject
Date: 2017-04-10 09:19 am (UTC)Also a really bad default passphrase(key_file.txt) which I think is used for generating some kind of key/cert.... I have not looked at the actual gateway at all yet.
cloudfront
Date: 2017-04-11 01:02 pm (UTC)it should be zero effort to set it up to redirect to HTTPS .
but since there isnt HSTS or preloaded, it wont help much either.
do you know if it supports IPv6? wouldnt it be internet exposed then?
Re: cloudfront
Date: 2017-04-13 11:14 am (UTC)no subject
Date: 2017-04-11 08:08 pm (UTC)ntp.org with no valid SSL
Date: 2017-04-12 10:15 am (UTC)ouch
Re: ntp.org with no valid SSL
Date: 2017-04-29 05:31 pm (UTC)Re: ntp.org with no valid SSL
Date: 2017-04-29 05:32 pm (UTC)Wireless
Date: 2017-04-12 04:16 am (UTC)Not enabled yet though. Boot messages imply it will support Apple homekit at some point.
Trajectio support Tradfri
Date: 2017-04-17 01:13 pm (UTC)