A quick look at the Ikea Trådfri lighting platform
mjg59.dreamwidth.org
mjg59.dreamwidth.org
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.
In this case the article points out that the metadata itself is downloaded over HTTP.
Recreate a package every day, week or month and update package date to current time. A device will refuse to install an update that is older than factory specified interval. Of course the problem then is that your device now needs to have secure channel to NTP servers. Possibly they could use radio synchronization instead - same as used in radio controlled watches. It could be exploited, but it would be much harder to do remotely by network.
It needs a bit of gymnastics, but it may still be easier on the long run than HTTPS. Your mileage can vary.
Edit: Dear downvoter: Was I overly dumb or inaccurate with my proposition?
The WRT54G is also 15 years old. That's probably longer than the lifespan of a smart lighting system.
This is probably true, but also depressing. Dumb lighting systems have a very long lifespan, essentially as long as the wiring survives, which is mostly until a remodel or a catastrophic failure; but a smart lighting system is only expected to last 10 years at which time we have to rebuild the system at great expense with whatever is new and hip and trendy (not to mention, the ten year old system was already greatly expensive).
All the smart stuff and home automation is still very new and in a state of flux. I hope it will settle down in the next few years.
This device presumably already ships with a public key that verifies the integrity of the images it downloads. Why not ship with a single CA (owned by IKEA), or even single certificate?
It doesn't even need to be signed by a public CA, this can all be self-signed by the org. This completely solves the issue with regards to anchors, as you call them.
The next thing you mention is firmware update post-EOL. Again, TLS doesn't change much about this. If we apply Occam's razor, what is more likely: that Ikea's servers are upgraded beyond compatibility with today's TLS stack, or that the servers are shut down? Once EOL hits, you're SOL anyway.
PS: A current nginx or Apache can still easily communicate with IE6.
PPS: I'm not saying that I think TLS is required in this case. Just that the right argumentation has to be used.
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.
As you say this is dangerous but it's not as obvious how dangerous. To work with this trust anchor and keep it secur e you've now got a lot of physical and software security you now have to deal with for the next 50 years even if you stop supporting a given device. Since if anyone gets a hold of that root certificate they can all the sudden pretend to be you to everyone continuing to use your devices and you've now got a massive PR issue, if not legal liability. It's not an easy problem to deal with.
But to serve updates via https you have to constantly keep the certifcate on internet-facing servers.
Also are there any protections against cycling them quickly (or really slowly, depending on how you look at it) to trigger seizures? Didn't someone recently get done for sending a seizure-inducing gif to an epileptic?
If someone has Epilepsy this might be a concern, but as the story around the gif sent to Kurt Eichenwald, which you reference, points out gifs don't hurt people, assholes do. It's not IKEA's responsibility to ensure that every product they sell cannot be used in any destructive manner. People have to take responsibility for purchasing and introducing new components into their home, much like I as a software developer have to take responsibility for every line of code that I write which has the potential to have a bug that compromises the system I deploy it on, or enables someone to leak the database the application is connected to. IKEA sells knives, for christ sakes.
Can these items be hijacked, what is the risk of that happening, and what is the damage they can cause?
> It's not IKEA's responsibility to ensure that every product they sell cannot be used in any destructive manner.
No, but they have a reasonable due of care.
I'm not saying that they shouldn't go on sale without the protections I mentioned. But it's surely a reasonable question to ask if those protections are in there, so as to better understand the risks.
>People have to take responsibility for purchasing and introducing new components into their home,
Yeah, but what ARE the risks? You can't answer my question, so how am I supposed to make an informed decision if I'm epileptic?
I know the balance of risks of knives. Everyone does. How many people know the potential risks of Zigbee-connected bulbs with a wifi hub?
Just saying #perspective
Typical organisations who need their own CA will create a root CA with a 20 to 30 year lifetime. This CA is then used to sign a sub-CA (sometimes called Principal CA, or Issuance CA), with a lifetime of 5-10 years.
The sub-CA is then used to sign a TLS cert, with a lifetime of 1-2 years.
This means that you only trust the root CA. Whether the TLS certificate gets compromised or not is irrelevant and completely besides the point, because the CA doesn't get compromised, and can revoke the compromised certificates.
I can go into detail about a few banks and governments whose CA I setup. Especially the smart card/PIN code distribution to unlock the root CA and sub-CAs was fun.
Thank you, came here to mention this. So many people seem to think that OpenSSL is the ONLY tool to be used.
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.
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.
This cuts both ways though - maybe your package parsing and signature verification code has a security flaw in it, in which case you'll find yourself wishing you had the protection of only trying to parse packages from the HTTPS-verified legitimate source.
So the answer to the question posed earlier, "...so what value does HTTPS provide in those cases?" is that it avoids have a single point of failure in your security architecture.
It's also worth pointing out that most of those protocol-level TLS vulnerabilities mentioned wouldn't have been exploitable in the far more restricted setting of "device that phones home to check for updates".
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)
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
What do I do in 20 years? 30?
Will all my tech just break?
People are still using furniture and lamps from their great-grandparents.
Do we have to become a society producing so much garbage?
And reastically, the server could even eliminate that requirement by supporting old protocols just for the updating old firmware.
Don't buy products that hook up to the internet if you want them to last 20 years, unless you're sure the manufacturer will continue to update it. (Don't buy anything with a non-standard battery either.)
The Google Omaha design docs discuss this a little bit: https://github.com/google/omaha/blob/master/doc/cup.html
I think plain HTTP is not appropriate for most update schemes Interestingly, Google Omaha actually chose not to use TLS to ensure freshness, but has something custom.
Disallowing downgrades via a signed datestamp is about the best you can do. Anything else will either be trivially blocked or result in other user problems.
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.
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. :)
Why? What security benefit do you gain by using HTTPS when you already check the signature/hash of the firmware file?
They probably should have signed the json listing of firmware images though, in addition to just the firmware images.
[citation needed]
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..
If you assume there IS further version validation, then the question is how do you know what version you should be expecting without HTTPS?
Downside: Reverting is not possible if you make a serious mistake in an upgrade. If you can't initiate another upgrade process, bricking is possible...
I don't know much about the world of really small devices aka IoT, but from my laymen perspective: Is a full TLS stack still a huge obstacle there? Sane signature checks are at least a step in the right direction.
Synchronize time using one of the time signals available in the area or use signed channel for time sync. Using radio time signal it can be easy to spoof it if your location is known by the intruder, but makes it practically impossible for remote exploits. But radio signals may have bad reception inside a house.
B/c without HTTPS you can't verify you're actually talking to IKEA's update servers. Even if there's firmware signature implemented an attacker could still MITM you over HTTP and simply not serve you a file with updates. Which means that they can prevent your devices from upgrading, i.e to receive an update that closes a known flaw they might be exploiting.
It's nice to see that some serious vendors actually do things mostly right.
It is a shame that the firmware updates go over http, but that's about the only obvious flaw with their implementation.
https://www.youtube.com/watch?v=uRe9w5PKmsE
It's also a pretty darn good piece of kit.
For what it's worth, 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?
A lot of the early Internet's game cracking scene originated in Sweden, too.
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.
I didn't mean that hacking is as culturally significant as the Dala horse or Semla. Just that, for example, nearly every kid in our town came to the LAN parties, even the "jocks." And everyone needed to troubleshoot networking issues, figure out how to get the games to run (cough without a serial key cough,) and so on. The biggest jock in town was cool because he played a MUD without ASCII colors, making him "hardcore." (Not to mention that the largest LAN party in the world, Dreamhack, which continues to this day, is in Sweden.)
Does that mean that all those kids became hackers? Of course not. But clearly being exposed to system internals coupled with a driving curiosity is how a lot of hackers got started, and so it's no surprise to me that IKEA has capable infosec talent.
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.)
And Denmark has hills.
Yes but only baby ones. Your highest point is only 170m!
Thanks for the replies.
I've never heard anyone say "trådfri" before. The normal word would be "sladdlös" at least where I'm from.
"einwandfrei": a thing free of problems or restrictions
Men min dansk er ikke så godt, så...
I think it might be a clever IKEA marketing trick: a lot of countries know exactly what it means (I would assume that most of Scandinavia, and the Germanic languages would be able to figure it out). For the others, it's just another random Scandinavian word and orthography to remember.
Given how tenuous some of the connections can be, I'm assuming they're often picked with more emphasis on how they sound/read/works in other countries rather than precision.
I live in London, and the most entertaining part about visiting my local Ikea is hearing English people trying to pronounce the product names...
trådfri sounds like half Danish half Norwegian to me; English cordless or wireless is Norwegian trådløs.
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?
https://github.com/bwssytems/ha-bridge/issues/570
P.S. Thanks for the nice article and bringing this interesting development to light!
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.
says no API access in the first version but IKEA is working towards an open system.
Prices seem to be only slightly lower than comparable Philips products.
https://github.com/bwssytems/ha-bridge/issues/570
Developers there are trying to reverse engineer it for open source home automation software.
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
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?
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.