
A quick look at the Ikea Trådfri lighting platform - dankohn1
https://mjg59.dreamwidth.org/47803.html
======
bsamuels
I dont get everyones gripe about the lack of HTTPS as long as there's firmware
signing.

HTTPS as a protocol ages extremely fast, trust anchors always change, and
there's no guarantee that today's state of the art won't be completely
incompatible with TLS implementations in 5 years.

For HTTPS to work properly on an embedded device, it needs to have an up to
date OpenSSL library and updated certificate anchors. These are always packed
as part of the firmware image itself, so any update to certificate anchors or
OpenSSL would require an entire new image to be deployed.

This isn't a problem for websites because updating is usually as simple as
apt-get upgrade, but this is a massive problem for embedded devices because
publishing a new firmware image usually means pumping a few hundred hours of
QA time into the image, then back and forthing with your manufacturer to get
them to use the new image on newly minted units.

This isn't even considering the changes in OpenSSL over time. Many older
routers simply cannot use HTTPS for updates because newer versions of OpenSSL
simply won't fit on the flash.

Then there's the question of how end-of-life will be handled. People often use
products long after they've gone EOL. You have to ask yourself what happens
when someone plugs in a lighting unit that has an old firmware version on it,
and the unit can't communicate with the update server because the product was
EOL'd 5 years ago. There won't be a transition firmware for such an old
product, and the people who know how to roll the firmware images probably
don't even work there any more. That user is now SOL unless you have a method
for manually updating firmware.

~~~
iancarroll
> HTTPS as a protocol ages extremely fast

You do not need to frequently upgrade TLS versions to be secure. TLSv1.2 will
likely be fine for many years and TLSv1.1 has been fine for 11 years. If you
do need to upgrade, it won't be often, but the QA is the only hard part.

> trust anchors always change

Indeed an issue, especially with the public PKI, but you can roll your own
root certificate with a lifespan of 50 years or something. This is somewhat
dangerous as there's now a non-expiring trust anchor instead of the usual 1-3
year key rotation, but it's still practical, especially if HTTPS is only a
layer of protection around your already signed firmware.

> there's no guarantee that today's state of the art won't be completely
> incompatible with TLS implementations in 5 years

Well, TLS is designed to negotiate the version to avoid this exact issue, but
even if TLSv1.x is not backwards compatible there is nothing blocking the
update server from supporting the older version?

> Many older routers simply cannot use HTTPS for updates because newer
> versions of OpenSSL simply won't fit on the flash.

OpenSSL is far from the only implementation here. BearSSL is only 25KB and
there are even microcontrollers with their own TLS stack built into hardware,
like the CC3220 from TI, which I've been using at my job. There are concerns
there too with updating TLS, but again, should be a relatively rare concern.

> the people who know how to roll the firmware images probably don't even work
> there any more

Indeed another issue. But realistically, yes, IoT devices are going to have a
finite lifetime if they depend on cloud services.

~~~
josteink
> You do not need to frequently upgrade TLS versions to be secure. TLSv1.2
> will likely be fine for many years and TLSv1.1 has been fine for 11 years

Famous last words.

I'm also in favor of keeping IOT devices as simple as possible. In that
regard, dropping HTTPS is a no-brainer (as long as some verification is done
through other means).

I'm making a bet that anyone here who religiously advocates HTTPS on embedded
devices never have tried it in practice and over time.

~~~
johnp_
There's a TLS 1.2 Long Term Support draft in the works, specifically for those
devices with "multi-year or even decade-long update cycles":

[https://tools.ietf.org/html/draft-gutmann-tls-
lts-07](https://tools.ietf.org/html/draft-gutmann-tls-lts-07)

~~~
josteink
It only takes a single incident like Heartbleed, Shellshock, Backblaze or
whatever to render a formerly assumed secured component or protocol insecure.

And if you're building something on a platform where you can't rely on the
ability to upgrade past the latest SSL security vulnerability in the future,
you effectively can't count on HTTPS to provide the security you need for the
lifetime of the device. That means you'll have to implement additional means
of securing your data anyway, so what value does HTTPS provide in those cases?

In some cases the library affected may now instead provide a security _risk_
in itself, which you wouldn't have had you only gone with plain HTTP. So it
can be argued that deploying HTTPS in environments where the ability to
perform updates are limited is a security risk in itself and should be avoided
at all cost.

So if you're going to have to implement your own security anyway, why bother
with all the additional work, complexity and security-risks using HTTPS
involves? Especially considering you probably won't gain anything out of it,
except more work.

Counter to popular HN religion, HTTPS everywhere is actually not always going
to represent a security benefit.

In lots of cases, plain HTTP just makes sense.

Edit: Not to mention the increase in complexity brought you by HTTPS
effectively means you now need to provide more updates for your devices, or
leave them vulnerable and hope nobody notices.

Basically, blindly applying HTTPS where it doesn't provide value, now just
increased the cost for companies w.r.t. maintaining their devices in the
future. If a company sees increased per-device-lifetime-costs associated with
updates, guess how many companies will then decide on limiting the number of
models they are willing to provide updates for, labelling older models
"obsolete"?

All in all, HTTPS in cases like this represent a negative value proposition
both for the companies and the customers.

~~~
johnp_
> It only takes a single incident like Heartbleed, Shellshock, Backblaze or
> whatever to render a formerly assumed secured component or protocol
> insecure.

Yes, just as your firmware verification and update mechanism and every other
interface your device provides to the outside world. That's just a general
argument against feature creep.

> [...] so what value does HTTPS provide in those cases?

Defense in Depth.

> [...] provide a security risk in itself [...]

Just like any other component. I'd argue that a slimmed down , globally
deployed implementation of a several decades battle-tested protocol has a
lower security risk than some vendor specific, device specific, single-
developer self-designed integrity and authenticity scheme.

Overall, if your IoT device handles any potentially confidential user data at
all you already need a TLS stack, so enabling it for the firmware update
mechanism doesn't add any more of an attack surface.

If you only ever need authenticity and integrity HTTP is already more complex
than necessary and you'd be better served with a simpler protocol. (e.g. CoAP)

~~~
toast0
> I'd argue that a slimmed down , globally deployed implementation of a
> several decades battle-tested protocol has a lower security risk than some
> vendor specific, device specific, single-developer self-designed integrity
> and authenticity scheme.

Is there a TLS client library released in April 2007 or earlier you are
comfortable running today?

Is there a data signature checking library released in April 2007 or earlier
you are comfortable running today? Note that OpenSSL didn't support TLS 1.1 or
1.2 until OpenSSL 1.0.1 release march 2012

My guess is that if you took the signature checks from an OpenSSL build from
2007, they're either still fine today if you used them separate from the TLS
stack, or they're broken enough that you can easily bypass certificate
authentication. From a brief look at the openssl vulnerability list, it's also
likely that there's a certificate handling bug that you could exploit to
bypass the checks anyway.

HTTP may be more complex than necessary, but it travels through firewalls with
pretty good ease, and it's not that complex if you speak HTTP 1.0 without
transfer-encoding, and only need to understand response headers enough to
discard them. HTTP 0.9 is even easier, but some transparent proxies have
trouble finding the destination server, so the Host header available in HTTP
1.0 is helpful to ensure requests can be routed. The MVP HTTP 1.0 client is:

    
    
       int where = 0;
       char rnrn[4] = "\r\n\r\n";
       int c;
       fprintf(fd, "GET %s HTTP/1.0\r\nHost: %s\r\n\r\n", url, host);
       shutdown (SHUT_WR, fd);
       while (c = read(fd, buf, 1)) {
         if (!c) { return -1; } // bad server
         if (buf[0] == where[0]) {
            ++where;
            if (where == 4) {
               break;
            }
         } else {
            where = 0;
         }
       }
       // here comes the data
       // be sure to have a reasonable sized buffer
       // and stop reading when its full
       // check the signature before you process the data
    

That's not really that complex (I didn't test the code, it's an illustration).
You could also abort without checking the signature if the server sends data
beyond your buffer, but the signature check should fail anyway. You could look
for a content-length header as well, but header parsing is some amount of
work.

------
matt_wulfeck
> 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.

This is excellent. I can't even say the same thing about my AT&T fiber
gateway. It listens on two random ports with no way to turn it off (and also
you can't use your gigabit internet without the AT&T gateway in front). I
don't know what it is, but I'm sure it's probably insecure.

~~~
toast0
This is super off-topic, but it is possible to bypass the 'residential
gateway', if you have the fiber to ethernet gateway (possibly on the outside
of your house), and then the separate gateway inside that turns ethernet into
ethernet. You basically need to bridge the 802.1x authentication packets, and
then you can do whatever.

~~~
matt_wulfeck
Do you know where I can read more about this?

~~~
toast0
This is the definitive thread I've seen:
[http://www.dslreports.com/forum/r29903721-AT-T-
Residential-G...](http://www.dslreports.com/forum/r29903721-AT-T-Residential-
Gateway-Bypass-True-bridge-mode)

I implemented it differently, but probably less sensibly. I have a FreeBSD as
my NAT box anyway, so I added some network cards, and run a ethernet bridge in
front of the gateway (I commented out the lines that dropped traffic to
reserved multicast addresses because that include 802.1X), and divert only a
small fraction of the incoming packets (ipv6 tunnel from he.net, most udp 123
packets, icmp pings, port 25), that the gateway won't give to the DMZ host (I
have the Pace 5268AC gateway which likes to ruin things; the NVG599 one is
probably better). You can PM me on DSL Reports with the same username, if you
want more details on my crazy setup. :)

~~~
matt_wulfeck
Thank you for sharing! I can't wait until somebody pops the gateway and dumps
the cert so I can just use a single DD-WRT router.

------
okket
> 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.

Why? What security benefit do you gain by using HTTPS when you already check
the signature/hash of the firmware file?

~~~
patrickmn
Metadata leakage aside: If you run a parser on unauthenticated input, bugs in
your parser can be exploited. This is partly why mac-then-encrypt is a bad
idea (you have to decrypt to verify the MAC.)

~~~
mortehu
One could take the view that a full TLS stack is so complicated that it is
much more likely to contain exploitable flaws than some simple signature
checking code.

~~~
mjg59
There are plenty of off the shelf TLS stacks, but people tend to end up hand-
rolling their own signature validation code badly.

~~~
revelation
And all of them are universally terrible and a _MAJOR_ hassle to integrate
with any embedded system. If you read _mbedTLS_ or _PolarSSL_ run far far
away.

Maybe people hand-roll their own signature validation code badly, but those
same people will just as much screw up or plain disable the CA verification.

If you have the knowledge to use the primitives from something like NaCl, you
have nothing to gain from using a full TLS stack but pain building, upgrading,
programming your firmware and massive middleware problems in the field. And
when they inevitably find issues in the TLS stack you used, your device is now
fucked since there is no virtual address space, W^X, even stack cookies..

------
floatboth
CoAP server on LAN? This is excellent. This is exactly how I set up my DIY
ESP8266 "smart" devices. More LAN of Things please, not "Internet".

------
jjuhl
Using 'pool.ntp.org' is not cool. Ikea should get a Vendor Zone -
[http://www.pool.ntp.org/en/vendors.html#vendor-
zone](http://www.pool.ntp.org/en/vendors.html#vendor-zone)

------
robert_foss
Thanks Matthew.

It's nice to see that some serious vendors actually do things mostly right.

~~~
TeMPOraL
It's like... first vendor I've heard of doing this right? And it turns out to
be IKEA, of all the companies.

~~~
bberrry
Not very surprising to me. IKEA is always very thoughtful and clever in their
design of even the most mundane things. I've never seen them botch anything
ever.

~~~
cdegroot
Also, IIRC, they were a very early Linux adopter, I think in the '90s one of
the largest users. It seems that Ikea has some smart techs on board and that -
here comes the actual surprise - they listen to them.

------
fnord123
Also of interest is this teardown of the Koppla USB power supply:

[https://www.youtube.com/watch?v=uRe9w5PKmsE](https://www.youtube.com/watch?v=uRe9w5PKmsE)

It's also a pretty darn good piece of kit.

------
patrickmn
> 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.

For what it's worth, hacking is a big part of Swedish culture.

~~~
saganus
> hacking is a big part of Swedish culture.

Really? how so?

I've never heard about this before so I'm curious about it.

You mean it's a big part as in there are a lot of Swedish hackers or because
it's encouraged as part of the culture/education system?

~~~
patrickmn
I grew up in Denmark and Sweden but I'm not sure I can give you a single
reason. It's more that kids are more likely to be exposed to computer
internals than in most other countries. PC gaming and LAN parties much more
commonplace, an unfriendly climate most of the year encourages indoor
activities, there isn't much going on (the downsides of peaceful countries...)
and so on.

A lot of the early Internet's game cracking scene originated in Sweden, too.

~~~
sebcat
I think you may be projecting your own experience growing up on a nation as a
whole.

Yes, Fairlight and some other groups were Swedish. Yes, a strong middle class
meant that a lot of kids had access to ABC80s, C64s, Amiga 500s, IBM PCs,
Macintoshes growing up. BBSes were popular in certain groups of the
population. People grew up with this and started companies. A lot of existing
companies were open to new things. That does not mean that "hacking is a part
of Swedish culture".

> an unfriendly climate most of the year encourages indoor activities

Anecdotally, I seem to recall a lot of sledge riding, snowball throwing and
various other winter activities from my youth.

~~~
Symbiote
> sledge riding, snowball throwing and various other winter activities

Presumably further north, since Denmark and Skåne don't have that much snow,
and Denmark doesn't have any hills.

(I've moved here as an adult, and so far haven't seen much outdoor activity in
the winter.)

~~~
sebcat
Denmark and Skåne does not have much snow compared to the north, but there is
snow, especially outside of the cities.

And Denmark has hills.

~~~
kwhitefoot
> And Denmark has hills.

Yes but only baby ones. Your highest point is only 170m!

------
wingerlang
Trådfri literally translated is "threadless" but it can probably be
interpreted as cordless as well.

I've never heard anyone say "trådfri" before. The normal word would be
"sladdlös" at least where I'm from.

~~~
iiv
Where I live (eastern Sweden) we all say "trådlös", so almost "trådfri". But
IKEA have many names that either sound like gibberish or are just strange.

~~~
moogly
'Trådlös' is the usual way to say it. Though arguably '-lös' (-'less') could
be construed as having a negative connotation, whereas '-fri' ('-free') has a
positive one. That's probably why they went with 'Trådfri'.

------
microcolonel
Might get me a few of these and write some client libraries. I think it would
be swell to hook it up to ambient light sensors to set the lights exactly when
it's time to replace sunlight in a given room.

And it looks like they've separated the concerns somewhat properly, so the
lightbulbs can be somewhat separate from firmware updates and the suchlike.
Big improvement over some folks....[0]

[0]:
[https://twitter.com/internetofshit/status/849667478385037317](https://twitter.com/internetofshit/status/849667478385037317)

~~~
tomkinstinch
Also cool would be to use this library to turn on lights based on where one's
phone is located:

[https://github.com/kootenpv/whereami/blob/master/README.md](https://github.com/kootenpv/whereami/blob/master/README.md)

------
tostitos1979
I watched the videos and this lighting system seems very nice. Why does the
gateway need an a internet connection though? For firmware updates and
supporting the mobile app? Since it says local only, I assume the mobile
device has to be on the same LAN?

If so, I guess they are saying that the API between the app and the gateway is
currently closed (according o the IKEA website) but they are working to change
that. So what is speaking COAP? The gateway?

~~~
mjg59
If you've got a remote bound to it, I suspect that the gateway will work fine
without a network connection. You can already control the gateway with any app
that speaks COAP with DTLS, so there doesn't seem to be much more to do on
Ikea's side from that perspective. If you can make that port available outside
your local network, you can probably write your own remote control app.

~~~
brutus1213
I wish there was an official API spec for the gateway. It seems people are
attempting to reverse engineer. Your article has made it there:

[https://github.com/bwssytems/ha-
bridge/issues/570](https://github.com/bwssytems/ha-bridge/issues/570)

P.S. Thanks for the nice article and bringing this interesting development to
light!

------
Matthias247
Interesting to see CoAP deployed to an embedded device. I already wondered if
it will also be some never-widely-deployed standard. Also intersting that they
use it on the gateway and not on the (more constrained) lightbulbs. I guess
the always-on gateway would also have been powerful enough to run HTTP[S],
which would have made 3rd integration easier.

------
api
Local only with no cloud support. Hallelujah.

------
PhasmaFelis
I was surprised too, but I guess a furniture company might not have the same
pressure to "move fast and break things" (scare quotes intended) as
established tech companies. They don't have a culture of rushing products to
market as fast as possible.

~~~
Symbiote
I'm not surprised at all.

Ikea has a trusted brand, with a strong reputation for safety, quality (for
the price) and family-friendliness.

They make things cheap with clever design, logistics and home assembly. A €5
table isn't comparable to a €500 one (and they sell both), but they don't sell
the €2-including-delivery electronics you can find on eBay. They sell wireless
chargers for €30, and normal ones for €8.

~~~
PhasmaFelis
Sure, they do quality in general. I'm just saying it's a bit surprising for a
non-tech company to outperform long-established tech companies in a tech
field, and I think that tech schedules vs. furniture schedules may explain
that.

------
afashglaksnhb
Is this a closed platform? Or can one integrate with one's own/third party
solutions?

~~~
oflannabhra
I haven't confirmed this, but I've heard they are Zigbee Light Link devices,
which should work with any other ZLL devices on the same mesh.

~~~
jacquesgt
I believe they're Zigbee Home Automation, not ZLL. Either that or they're
improperly reporting that they support ZHA instead of ZLL, which causes issues
for 3rd party bridges like Philips Hue.
[https://developers.meethue.com/comment/2686#comment-2686](https://developers.meethue.com/comment/2686#comment-2686)

------
chvid
Side question: Is there a way to make trådfri control an arbitrary 220 v
device?

------
vanviegen
Okay, so it's basically Philips Hue, but without the API (for now), and with a
lot less to offer in terms of hardware variety. In particular: color bulbs?

Prices seem to be only slightly lower than comparable Philips products.

------
Harley78
There is a lot of development inforomation about communicating with Ikea
Trådfri Gateway here:

[https://github.com/bwssytems/ha-
bridge/issues/570](https://github.com/bwssytems/ha-bridge/issues/570)

Developers there are trying to reverse engineer it for open source home
automation software.

------
zAy0LfpBZLC8mAC
> It's also local only, with no cloud support.

Is that actually true? Or is this just confusing "non-local" with "cloud"?

If it's speaking IP, how would it even distinguish "local" packet from "non-
local" packets? What prevents you from talking to your device at home using IP
connectivity elsewhere on the planet?

~~~
Nexxxeh
It's always going to be behind NAT, so unless it implements UPnP or polls the
server or does some other kind of NAT traversal, it's never going to receive
any packets. You'd jave to DMZ, manually port forward, or VPN/proxy for
packets from outside of the LAN to hit it.

~~~
zAy0LfpBZLC8mAC
So, it's a new product that only speaks legacy IP?

But even then, it's not really sensible to take that for granted: Sure, most
consumers will only have NAT at home, but why should only consumers buy this
device?

Also, NAT does not prevent unsolicited packets from outside the LAN, just from
across the global internet.

------
oflannabhra
The EFR32 chips they are are using are Thread-capable. It will be interesting
to see if IKEA migrates to Thread as the network layer and dotdot as the
application layer. Their on boarding method, CoAP + DTLS sure seems to
indicate that would be possible.

------
redsummer
Will the lights work with Home Assistant on pi - home-assistant.io - without
the gateway? With perhaps a zigbee hat or USB dongle?

~~~
mjg59
The bulbs apparently work fine with the Smartthings hub, so should work with
HA without a gateway once direct Zigbee support is merged.

------
longhust9x
Helo

