Hi,
This is the second document I read recently about how zigbee and z-wave work and what mecanism are used to offer significant security.
Well, for the moment all this sounds pretty scary…
This one of the documents I’m refering to : http://bsidesvienna.at/slides/2015/zigbee_smart_homes_a_hackers_open_house.pdf
Anyone from SmartThings to comment ?
Are your devices using a private certificate or the default one ?
Some good reading that answers you question: 
the search feature does work well 
The fact is, here, that the security breach is in the sensor mesh network.
This is nothing a user can configure. So yes, users have to ensure their (internet) network (the wifi…) is configured correctly with all the security features your ISP/box can offer.
This will not prevent a “hacker” or more generaly a thief to use a tool (a raspberry with a xbee module, or worse, an arduino ?) to get access to the SSL security key and unlock your door or ring your alarm (or shut it down).
In few weeks, when a “complete solution” will be available, any script kiddy, like the son of your neigbour, will be able to fuck up your setup, turn your lights on in the night or set your thermostat to 10 degree C and freeze you in the night.
My point here is, there is now a known flow in the z-wave and xbee protocol, and I wonder how is ST doing with this ?
Maybe it is using it’s own certificate which is a good starting point, but maybe it is not. In the later, I expect ST to come with a solution to upgrade the hub and re-pair the devices so a new “private” certificate is used instead of the factory once.
I don’t want to scare anybody. Maybe I should ask this question to the support. Or maybe some ST engineer reading this thread will be able to provide some technical details.
Having anybody able to hack, control or read my devices is a security concern to me. If ST is prone to this kind of risks, owners have to be told.
If ST know about it and do nothing, customers may take actions and ask to be refund for their “unsecure” hardware.
From my understanding they are grabbing the network key when a device is allowed to join the network. So you have to tell your hub to allow new devices to join for this all to take place. That is something you don’t do very often but is a risk with both zWave and ZigBee. When you open up your network to allow new devices to join your neighbor could have a device sitting there trying to join over and over and when you open your network bang he is in your network (if he is within range). That has always been there, I don’t know why this is big news all of a sudden or that it is even a security flaw.
The ZigBee HA profile uses two sets of keys when joining a network. One is the public key that is the same for every HA network. That key is used to get a private key from the trust center (ZigBee coordinator) that is unique to your network and only known to your network. That network key is what sniffers and hackers need to snoop on your traffic and It is only exchanged during the join process.
SmartThings does a good job of identifying devices that join its network. If you have concerns you can always check your device listing under the MyDevices tab in your IDE. Look for any devices just labeled “thing” and track them down to make sure they are your devices.
There are really two distinct things at play here, and I’ll do my best to describe them, what their potential impacts are, and what we’re doing at SmartThings to eliminate or mitigate them. I apologize in advance if this is overly dense, but there’s a lot to get to here.
What are the issues?
First, as @JohnR points out above, there is a designed “moment of insecurity” in the Zigbee HA 1.2 specification that uses a well-known symmetric encryption key known as the Trust Center Link Key to distribute a unique network key when a device first joins the network. This is a tradeoff that the ZigBee Alliance chose to make between security and simplicity - with a mitigated impact given that an attacker would have to be capturing ZigBee network traffic at the same time that a new device is being joined to the network.
This method has been removed from the upcoming ZigBee 3.0 specification and replaced with a process that requires a per-device installation code that is used to generate a unique joining key, which is then used to acquire the ZigBee network key. The install code may be printed on the device, be a 2D barcode that is scanned by a camera, or some other out-of-band method of passing the code from the end-device to the ZigBee Coordinator device (in our case, the SmartThings Hub) such as NFC or Bluetooth Smart.
The second issue described by CognoSec is with a method known as “insecure rejoin.” Insecure rejoin also exists in the ZigBee HA 1.2 specification as a tradeoff between security and simplicity. This method allows a previously paired device to rejoin a network using the same well-known Trust Center Link Key in the event that the network key changed since the last time the device joined the network. This enables battery powered devices that aren’t always listening for commands from the ZigBee Coordinator (otherwise known as “sleepy” devices) to rejoin a network if the network key changed, as the sleeping device wouldn’t have received the new key from the ZigBee Coordinator.
So if an end-device such as a motion sensor or contact sensor fails to join the network using their stored network key, they can ask for the new key which is transmitted using the well-known Trust Center Link Key. The specific issue that CognoSec describes in their publication is the ability to spoof a device on the network to send a false insecure rejoin request, triggering the network key to be sent using the well-known Trust Center Link Key. This bypasses the mitigation effect described above, as an attacker could potentially cause the network key to be transmitted at will.
How is SmartThings impacted, and what are we doing about it?
SmartThings currently supports insecure rejoin, as many ZigBee HA devices will only attempt to rejoin once with their stored key before reverting to an insecure rejoin mode. This means that without insecure rejoin, if there are any issues rejoining the network after a Hub reboots or a router in the mesh goes away, the device would not be able to rejoin the network and would be effectively stranded. The only way to resolve a stranded device would be to delete it from SmartThings, perform a factory reset on the device, and put it back through the initial join process.
We do recognize the security concerns presented by spoofed insecure rejoin requests, and since the issue was brought to our attention we’ve been developing an update that will give users the option of turning off insecure rejoin while we work to understand the broader negative impact of simply disabling it by default. We hope to have this update in place within the next 60 days. Once the feature is available, we’ll let you know how to go about disabling insecure rejoin. In the longer term, the ZigBee 3.0 specification eliminates the insecure rejoin process.
As for the initial joining process, SmartThings must support the standard ZigBee HA 1.2 Trust Center Link Key join process because it’s how nearly all ZigBee HA 1.2 certified devices join a ZigBee network, and as an open platform we support many ZigBee HA certified devices from many manufacturers. As mentioned above ZigBee 3.0 will eliminate the “moment of insecurity”, but we’re also exploring methods for enhancing communication security and add the ability to validate and trust devices that join the network - but this will be limited to our own devices whose firmware we directly control, as the solution will be outside of the ZigBee specification.
I hope this helps, and thank you for taking the time to read this far. As always, please let us know here if there are further questions we can answer or clarifications we can make.
ok thanks for the explanation.
What will have to do if ST moves to zigbee 3.0 spec ? Will this need new hub ? new devices ?
Dan,
I think your response goes a long way in building trust between SmartThings and your customers. I understand there are flaws in just about everything. In this case we are talking about a flaw that is part of the ZigBee spec (SmartThings had nothing to do with) and I feel a little better knowing you guys recognize it and are working on options to mitigate it!!
Thanks for the informative response!
I’m not sure on the timeline, but when we do make the move to Z3.0, all of our current devices should be upgradable.
Would it not be simpler to implement a proxy system where the end user has to choose the type of device to allow to join first and then start the join and only allow that device to join?
This would eliminate the forced join vulnerability and put the end user in control of what devices are added.
Sure it means you have to set up the devices ahead of time, one at a time, but this would also allow for swapping of defective devices as well.
Just my two cents.