Hacker News new | past | comments | ask | show | jobs | submit login
A quick look at the Ikea Trådfri lighting platform (mjg59.dreamwidth.org)
412 points by dankohn1 on Apr 9, 2017 | hide | past | web | favorite | 137 comments



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.


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


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


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


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.


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.

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


> 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)


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


Specifically, in the case of the firmware running on the Trådfri gateway, it already supports TLS.


Yeah, https may be insecure in 5 years so we better use http and be insecure from the start. Never mind that https likely is insecure only in rather esoteric scenarios that cannot occur when you're only downloading firmware upgrades.


11 years.

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?


Well, the device can auto-update - this just means that it would need to be plugged in within 11 years of manufacture in order to be able to receive firmware updates, not that it would break after 11 years.

And reastically, the server could even eliminate that requirement by supporting old protocols just for the updating old firmware.


Basically, anything hooked up to the internet needs to be updated over time to stay secure (whether it's patching security holes, new protocols, or using new methods of security.)

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


> BearSSL is only 25KB and there are even microcontrollers

Thank you, came here to mention this. So many people seem to think that OpenSSL is the ONLY tool to be used.


BearSSL is my favourite crypto software of 2016, however it's still in alpha stages of development and is not production ready, Ikea couldn't use it for this product: https://www.bearssl.org/todo.html


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

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.


Isn't the same true of whatever signing certificate you're using to provide signed images? You'd still need to either control DNS or be able to interfere with traffic to do anything.


The difference is: to sign images your private key do not need to leave your build farm (or single build machine) and when you discontinue the product, you just wipe the server, keeping already built (and signed) images.

But to serve updates via https you have to constantly keep the certifcate on internet-facing servers.


You can generate your own CA certificate, and then use that to generate SSL certificates.

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.


This comment screams KISS


This is not at all complicated to implement.


They're using Cloudflare as their frontend, and if they're broken we're basically so fucked anyway I don't think lights are going to be our biggest concern


Might be, if the lights are in YOUR house. If one's bathroom and hallway lights gets hijacked or disabled remotely, it becomes an immediate safety issue if you're in that bathroom in the middle of the night.

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?


We're getting into the territory of "Guns don't kill people, people kill people with guns".

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.


No we aren't.

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?


I don't want to alarm anyone, but in many countries someone can walk up and switch off your power from the external meter box. They could even turn it off and on constantly to flash.

Just saying #perspective


No-one is flicking my lightswitch from across the globe. The chances of some 4Chan troll doing it are slim.


Pretty much I think. I don't know a way around it either and I think it's only going to get worse for now as more states look at passing laws like California or more Companies end up with FTC suits and settlements like trendnet (20 years of mandated 3rd party auditing)


Any thoughts on PolarSSL?


Less well tested than OpenSSL, but historically has been relatively secure.


PolarSSL is now mBedTLS


I understand where you're coming from, but you're making a logical leap: you assume that HTTP over TLS somehow means that it needs to be interoperable with the full and real internet.

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.


The firmware signature ensures the updates are authentic, but not that they are fresh. An attacker could force devices to stay on an older authentic but vulnerable piece of software.

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.


An attacker could just as easily block the SSL connections - unless you're suggesting it fail if it can't check for a firmware update, but that proposal would mean that if your servers are gone the devices are bricked. Many of such devices function fine in a Lan only setting behind a nat where they're virtually untouchable.

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.


The are less drastic options. You can start warning loudly if the servers haven't responded for weeks.


Via what? Flashing the apartment lights?


Reporting to the app controlling them.


An attacker who can change the http content, could also block access to https upgrade servers, ensuring stale firmware.


I mentioned this elsewhere, but signing can tell you whether it's an authentic object, but usually not whether it's THE authentic object you had requested. So you then need something extra to validate that what you got is what you wanted, for example check the version number in the signed image. But how do you know what version number you should be looking for without HTTPS?

In this case the article points out that the metadata itself is downloaded over HTTP.


A silly solution:

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?


Simpler solution: just refuse to install a firmware update that doesn't verify, or whose version number is less than the currently installed version.


I agree. I had to dust off my WRT54G for a few days when my modern router died. I accidentally switched it to https only, and none of Safari, Chrome and Firefox would connect to it because of the SSL version.


That's unrelated. The lights need to be able to connect, not your browser. It's not about having a website where you can download a new image, it's about having the lights download a new firmware image. What browsers do or do not support doesn't matter.

The WRT54G is also 15 years old. That's probably longer than the lifespan of a smart lighting system.


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


If you haven't replaced your lighting system in the last ten years, now might be a good time to buy LEDs. They have improved in reliability, colour spectrum (warm white), and price. Incandescent bulbs are no longer sold in the EU.

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.


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


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.


Do you know where I can read more about this?


This is the definitive thread I've seen: http://www.dslreports.com/forum/r29903721-AT-T-Residential-G...

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. :)


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.


> 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?


Parser exploits aside, HTTPS would help ensure the signed image you received was the one you asked for. So say there's an exploitable security flaw in 1.1.5 of the firmware and the firmware requests an upgrade from http://whatever.com/images/latest.img. Someone could return the legitimate 1.1.5 image instead, and assuming no other version validation, cause a downgrade that will allow further attacks.

If you assume there IS further version validation, then the question is how do you know what version you should be expecting without HTTPS?


To prevent downgrade attacks, include a list of banned signatures/hashes of previous versions in an upgrade? Plus only allow higher version numbers?

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.


A device running 1.0 could still be upgraded to a vulnerable signed 1.1 when a patched 1.2 with blacklist is current on the site.


A device running a vulnerable signed 1.1 could still be denied an upgrade to 1.2 by a MITM blocking port 443 even if you used HTTPS.


Yeah but it's kind of irrelevant because the device is already vulnerable in your example. The point of this was to say that you can turn a safe device into a vulnerable device as part of a multi-phase attack.


So assuming the version is signed (likely given they seem to have done this competently) the worst an adversary can do is prevent upgrades? They could do that by blocking HTTPS too.


I think so, but I don't think it's actually a correct assumption. The article talks about the list of firmware versions (and where to download them from) as being fetched from a JSON file delivered over HTTP. That json file isn't signed in any way, so you could first intercept that, change the links and expected versions, and you're home free.


Generate a new package every day or week and include current date. Do not allow to update to package older than X.

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.


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


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.


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


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


Undoubtedly true, assuming you use something well-scrutinized like signify or gnupg for that signature verification.


There's a parser on unauthentic input either way. Given the choice to do it online with NSS or OpenSSL or offline with the same library, I think it's a hair safer to do it offline---but this will be swamped by other factors particular to the project.


Yeah, don't get me wrong. Not implementing TLS because you're worried about attack surface is a bad idea. But if all you're doing is verifying a gpg signature on some firmware, a TLS stack is probably overkill.


> Not implementing TLS because you're worried about attack surface is a bad idea.

[citation needed]


If you're doing things that should be done over an encrypted channel, but forego TLS (or a suitable alternative like Noise Framework or WireGuard) because it adds attack surface, you are adding more risk than you are removing. A better solution would be to separate the parts of the stack that are sensitive from the parts that do things that you don't trust/are not in your control. This could be openbsd/POSIX style separation between your sensitive and the TLS-terminating process, or ideally placing them on completely separate machines. (Just make sure you trust your internal network if you aren't going to encrypt traffic on the inside...)


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

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.


Closing an easy attack vector by using HTTPS seems a safe bet here, with no particular drawbacks. Are there chip-level power concerns that could make their IoT thing unable to do SSL, but able to validate firmware signatures?


HTTPS for firmware download is a maintenance nightmare. In a couple of months, TLS 1.3 is going to be finalized, and then calls for everyone to drop support for TLS 1.2 will begin. But they can't drop TLS 1.2 support, without breaking firmware updates for all the unopened boxes out there.

They probably should have signed the json listing of firmware images though, in addition to just the firmware images.


People even support TLS 1.0 for Enterprise clients. I feel like you'll support your legacy protocols for at least 20 years.


I guess what they could do to avert that is to have versioned (by subdomain) upgrade sites where each version is as secure as the associated device.


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


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


Thanks Matthew.

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


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


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.


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.


The designs of their physical products are generally good, granted, it's the implementation that is lacking, often severely.


They do regularly recall toys that were found to be dangerous.


No kidding. Just seeing what goes by on https://twitter.com/internetofshit makes my head spin.

It is a shame that the firmware updates go over http, but that's about the only obvious flaw with their implementation.


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

https://www.youtube.com/watch?v=uRe9w5PKmsE

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


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


At least in tech circles it seems to be in. My point of view may be biased, but 50% of the techy folk I socialize with in Sweden are very much into this stuff.


> 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?


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.


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.


I only have my own experience on this subject, so I'm definitely projecting.

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.


Thinking back, the fact that the Pirate Party actually managed to get Parliament seats in Sweden suggests, at the least, a uncommon level of sympathy with the hacker ethos.


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


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.


> And Denmark has hills.

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


Of course you were not inside all the time during winter but surely you must agree that you were inside more than during summer time?


Interesting peek into another country's computer culture!

Thanks for the replies.


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.


Almost all Ikea product names are either place names or Swedish words that are somewhat but not always directly/logically connected to the product.

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


I'm struggling with the 'a' in this one which has the weird accent, "å". I have no idea what that accent above the 'a' is indicating.


Most of the time it's pronounced as the "a" in ball.


It is certainly a brand name made from a literal translation of wireless. Although "trådlös" (without wires) is the normal Swedish translation.


Yeah, "trådlös" is more common than "sladdlös", just forgot about that word for some reason.


Trådfri is valid Danish for "wire free", as far as I can tell. This being said, I don't know whether it's idiomatic.

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.


In Danish you would say "trådløs" for cordless. "Trådfri" is not used, but it is easy to understand the meaning.


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.


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


Oh, "trådlös" is probably the most common one actually, now that you mention it. Completely forgot about that word for some reason.


It's hard to trademark common or idiomatic words. So using words that are almost right makes sense.


It would feel similarly odd in Dutch. Perhaps they tested both names and the former 'sounded' nicer in other languages?


Similar in German: "drahtlos" is the real word, but "drahtfrei" is understandable, and conveys being freed from something.

"einwandfrei": a thing free of problems or restrictions


IKEA uses Swedish, Norwegian, and Danish. They have a bed named after the Norwegian town I live in.

trådfri sounds like half Danish half Norwegian to me; English cordless or wireless is Norwegian trådløs.


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


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


And for the bedroom, having a melody recognizer would be interesting. If I want to go to sleep, I can whistle Brahms' Lullaby melody; and when I want to turn on the lights in the morning it can either be activated by my alarm, or I can whistle the melody of Good Morning (by Nacio Herb Brown).


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?


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.


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

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


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.


Local only with no cloud support. Hallelujah.


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.


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.


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.


And unlike startups and anonymous Chinese OEMs, IKEA has experience and procedures for long-term support (25 year warranties on mattresses, kitchens) and recalls (they've had recalls of furniture, lamps, etc in the past).


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


FAQ here http://www.ikea.com/gb/en/customer-service/smart-lighting-su...

says no API access in the first version but IKEA is working towards an open system.


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.


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


You're correct. It says in their FAQ that they're using ZigBee Light Link, AES-128 and have put time and effort into preventing them from being hacked. They also say that they work in a mesh and should be compatible with other products per the ZigBee Alliance.


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


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.


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

https://github.com/bwssytems/ha-bridge/issues/570

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


> 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?


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.


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.


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.


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


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


Helo




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: