A post was published recently about a vulnerability of the Z-Wave pairing routine. An attacker exploiting this vulnerability is able to gain access to your house key and therefore gain access to read and write all transmitted data to all nodes, including secrets like PINs and security data.
This has to happen while you are pairing, though. Until fixed I recommend using a very low radio power while pairing and bring the node very close to the controller. If you are especially paranoid, you could do the pairing inside a tinfoiled bag or you microwave.
This thread is for discussion about the risks. Most of the controllers do not support the secure pairing anyway, so we probably were vulnerable to an older vulnerability from 2013 anyways.
This is nothing new - if using secure inclusion, there is a small window of opportunity to capture the keys using well known keys before the real key is exchanged. This allows the key to be intercepted. This window is around 10 seconds during the inclusion only. Personally I think the risk is low as someone has to be sitting outside your house with the sniffer, waiting for you to include a new device, but there is of course a small risk.
I’m not really sure what this means - the controller doesn’t support secure pairing at all - it’s done by the binding.
I am referring to the second paragraph, where the PenTestPartners wrote
The earlier pairing process (‘S0’) had a vulnerability – the network key was transmitted between the nodes using a key of all zeroes, and could be sniffed by an attacker within RF range. This issue was documented by Sensepost in 2013. We have shown that the improved, more secure pairing process (‘S2’) can be downgraded back to S0, negating all improvements.
Maybe this is something else but it sounds to me like they refer to a protocol of pairing, that is a feature of the controller.
S0 is the security protocol used by nearly all devices. This is implemented in the binding. S2 is the new security protocol - it was only brought in to effect last year, and I only only of 1 or 2 devices that use it so far.
The binding currently only supports S0 which is supported by all (secure) devices.
Pairing (ie inclusion) is a feature of the controller - but key exchange (ie secure inclusion) is not. This is coded in the binding.
Downgrade attacks are generally something you have to be careful of when designing security protocols, especially in the case where legacy exists.
There is also a big difference between a simple passive eavesdropper attack and an active attack (this one).
I wonder whether this is the first of a more to come - it is easy to imagine a couple of ideas for future attacks (all well known techniques) which might also be possible.
Displaying the security method used is all well and good on a controller, but it depends on the user knowing or caring about what they are being told.
A recent example I encountered was where a car dealership was pairing by phone to a new car using Bluetooth. I quote “You don’t need to check the numbers they are always the same.” This is only true if there is not an active attacker. In this case the user has trained themselves to ignore the warnings and just hit ok. This is the same as just pressing ok on those annoying dialog boxes that get in your way on your favorite OS when you are trying to do something.
I suspect there are easier ways for people to get in (smash doors/windows, rubber hose cryptanalysis, or more sophisticated - removing cryptographic information from devices outside the home, etc), each with their trade-offs and traceability.
I am not worried by this, as I think when you consider the balance between the cost of the attack (active vs passive) and temporal element (having to be there at the right time), it is very unlikely in the end today.
Interesting never the less, if you like that sort of thing.
Out of pure curiosity, since S0 is implemented by the binding, is the all zero key referenced above just a bad implementation from whatever zwave software they were using, or is this dictated by S0 itself?
It’s dictated by the protocol. There obviously has to be an agreed key used for the initial key exchange otherwise it’s impossible to exchange keys. ZigBee 2 does exactly the same thing (not with zeros, but it’s a well known key that’s used). Other (more complex) options include some sort of out of band transfer of initial keys (such as using a PIN or QR code that is compiled into the device, and entered in some way into the controller before it’s included) - this is the concept is used in S2 and ZigBee 3 to ensure that keys are always fully secured.
When I see stuff like this I wonder why they bothered to have the key at all. Though key exchange is hard and doing key exchange with devices like these is bound to be really hard. I wonder how feasible it would be to do Diffie–Hellman on constrained devices like these. Probably impossible or else they would be doing it (one would hope).
I think a good future solution to this problem would be to design a system where the key isn’t negotiated over RF, but rather transmitted to the device via a separate IR dongle to pair it. It would be pretty cheap to add an IR receiver to each wireless device and a handheld token that you would first program with the key from the controller, then use to pair each peer device. You could add a small optical fibre poking through a faceplate for devices that are embedded inside walls, and a rubber boot on the dongle that prevents light leakage when it sends the key should make such a system really hard to eavesdrop on
It’ll be interesting to see what the industry does to secure next-generation wireless protocols!
But really, the risk is tiny. If someone wants to break into your house a brick through your window is still the easiest method, and even if they try to stealth their way in by hacking a z-wave network you will most likely quickly get a notification from one of the many sensors inside your home.
Fundamentally, this is what is done with S2, and ZigBee 3. The code isn’t transmitted over IR - there’s no real need for this i think and not many systems have IR - you can use just a number printed on the box, or a QR code (etc) to input the initial join code into the controller. I know some companies are pushing RFID for this purpose as well…
This is a new issue - S2 is meant to prevent a passive eavesdropper, or even active attacker, from obtaining access to the network key or the node being paired. To quote the Z-Wave Alliance:
"The Z-Wave Security 2 (S2) framework [...] completely removes the vulnerability of the network during inclusion by requiring a QR code or a pin-code on the device itself."
"S2 completely removes the risk of devices being hacked while they are included in the network."
Unfortunately, the design of the protocol is such that the inclusion can always be downgraded to S0, which then opens the system up to the vulnerability of sniffing the key. The risk of this is small, but:
It doesn’t require someone outside your house, a tiny AA battery powered node can do it, with a battery life of weeks.
The range the attack can be carried out over is as far, if not further, than Z-Wave range.
Low power inclusion isn’t used often.
The current implementation of the downgrade warning can be suppressed in a further attack (they are changing the standard to deal with this)
There are virtually no S2 controllers or devices, despite it being “mandatory” since April 2017.
S2 already uses Diffie-Hellman for key exchange, combined with authentication using the first 5 digits of the device-specific key. It seems secure so far.
@cybergibbons first off, thanks for your reaserch. I wrote the original S0 openhab code that @chris had to clean up ;).Hope to start on S2 very soon.
I think we could eliminate the downgrade attack in software by knowing/tracking which devices support S2 and refusing to downgrade. We already have the device database so we could add a flag there. This of course would only take effect when both the controller and device support S2. Thoughts?
Just for reference ( ) the OH2 implementation was pretty much a rewrite and I think only used the encryption block from your OH1 implementation…
If you are thinking about S2 though, which would really be cool, we should discuss further. We need to be mindful of the requirements, so any such restrictions would have to be configurable if they are not already stated in the requirements - otherwise if we look at certification one day, this will be a problem.
Ha, that’s right, I forgot my original work was against OH1. Been awhile. I remember how intrusive the security hooks were. Now that you smoothed out the S0 work in OH2, I hope the S2 integration will be less disruptive to the code base.
Just to be clear, you are referring to the proposed downgrade attack prevention, not S2 in general, is that correct? Understood about not wanting to stray from the standard and having a flag with the downgrade prevention.
Going to get my development env setup. What is the best place to start my work from? OH2 zwave master? One of your fork branches? I have a much better understanding of git now, so I plan on rebasing frequently to keep in sync
) the OH2 implementation was pretty much a rewrite and I think only used the encryption block from your OH1 implementation…
.