Question: Guess or brute force the device S2 DSK pin?

[LordMike]

Hey,

I have a bunch of z-wave devices inside walls now, and it would be cumbersome to pull them out in order to inspect the (hopefully present) S2 QR code / PIN to enable secure S2 inclusion..

I was wondering though, when including, the PIN is requested from the user, and then some validation occurs. Would it be possible to guess the actual PIN?

I'm hoping it could be entirely automated, so:

• Inclusion starts
• S2 authenticated is used
• PIN is requested
  • System enters 00000
• Devices refuses / something doesn't work
• Device loops in the inclusion
• PIN is requested
  • System enters 00001
• ... repeat.

I don't know what actually happens when the DSK is refused, but I can see something will happen when the pin was invalid (#3421)

[AlCalzone]

AFAIK you have exactly one chance to guess the PIN correctly, after which the S2 bootstrapping will be aborted, either by the device or the controller.

What you want to do is essentially S2 Unauthenticated. The only difference between Unauthenticated and Authenticated is that the latter makes sure that you're including the correct device by requiring the PIN for validation. Unauthenticated shares the entire DSK, so the PIN isn't needed.

[LordMike]

Does this mean I can do unauthenticated, dump the DSK, and then do authenticated?

It seems odd to me to make the distinction then... Surely it is highly unlikely, that in the 3 minutes you're including stuff - somebody comes along and presents their own (possibly simulated) device to fool you.. .. And if that somebody can get the DSK anyways, by doing their own Unauthenticated inclusion - they'll then have the full key to fool you, again..

:|

[AlCalzone]

Does this mean I can do unauthenticated, dump the DSK, and then do authenticated?

You're missing the point. Unauthenticated was meant exactly for these scenarios where you don't have the DSK handy or don't want to go through the hassle of entering the PIN - and where it is highly unlikely that in the few seconds between you starting the inclusion on the controller and pushing the button on the device, that someone else puts a different device in inclusion mode.

Unauthenticated just bootstraps the device without asking for further confirmation - note that applications may decide not to present the user with a choice of security classes, in this case the security key exchange will just go through.

Authenticated makes sure that you are including the device that was meant to be included by forcing you to enter the PIN. This way, when someone else tries to sneak a device in your network to grab the S2 key, bootstrapping will be aborted before any actual keys are exchanged because the PIN won't match. Granted, I'd expect such an attack to target something else than random people's smart homes. The most you're getting here will be the S2 Unauth key and maybe 1-2 (Unauth) devices you might be able to control via direct commands.

TL;DR: If you're not afraid of this potential attack scenario, just include the device as Unauthenticated and leave it at that. You can then write down the DSK for the next time you want to include it.

[LordMike]

Just to confirm: Zwave-js exposes the DSK to any app that needs it?

Also - now we're on S2 - as you write, then these keys (unauthenticated, authenticated, ..) are shared between all devices in the class. Does this then mean, that an S2_AUTHENTICATED device cannot communicate securely with an S2_UNAUTHENTICATED (different/lower class).

But, is an S2_AUTHENTICATED device able to communicate securely with S2_UNAUTHENTICATED devices ? (I read somewhere the classes are inclusive, so that lower classes are included in higher classes)

... or, is the dialogue that ZJS2MQTT shows me (checkboxes), actually that all the selected keys are shared with the device - so that the higher class devices can communicate with lower classes, because they actually have the shared keys.

... and if that's the case, aren't all keys then exposed on secure device inclusion, as users will just check all boxes and move on - thereby sharing all keys in one go?

[AlCalzone]

Just to confirm: Zwave-js exposes the DSK to any app that needs it?

Yes

[...] I read somewhere the classes are inclusive, so that lower classes are included in higher classes

A device MUST NOT react to commands it received on a lower class than its highest granted one, even if it can decode the commands. So Unauth -> Auth will not work, Unauth -> Auth+Unauth will not work either.
A device SHOULD detect the security classes of another device before attempting to communicate. So Auth+Unauth -> Unauth SHOULD work, but it is not guaranteed.

aren't all keys then exposed on secure device inclusion, as users will just check all boxes and move on - thereby sharing all keys in one go?

No, only the classes the device actually requested AND that are granted by the user will be shared. I've asked @robertsLando to disable the checkboxes for classes that aren't requested, to reduce possible confusion.

[LordMike]

Awesome - ok, it clears up a lot - but also means that users in general will encounter situations where a bulb won't be controllable from a button, as the two are on different S2 security levels - in case the basic sets/multilevels be sent securely. Probably unlikely, but more likely that a door sensor will send its notifications (possibly as a basic set) securely, to a light that won't be able to react to it.

I'm covered. :)