Z-Wave S2 Security Work

Starting a new discussion for this work. Been reading through the documentation to get familiar with the S2 spec and getting acclimated with the OH2 Zwave codebase.

@chris I see this note in the class javadoc of CommandClassSecurityV1:
Note that this code is autogenerated. Manual changes may be overwritten.

Do you have a tool that generates code/template from the C headers in the
Device and Command Class Types and Defines Specification ?

Or is that just wishful thinking? :grinning:

Update: my work on the S2 + Smart Start is going well, I almost to the point where I am ready to do some basic testing. But, I need to put this work on hold temporarily to give attention to the Lowes Iris shutdown work. Once I make some headway there I will resume this work.

1 Like

Update and future plans for the S2 security work


  1. Implement base S2 spec in code - DONE
  2. Alpha testing of S2 logic with ZLink ZL-PA-100 Plug Switch - In Progress
  3. Alpha regression testing of S0 logic
  4. Publish build for public beta testing

Help Wanted
Not ready for beta testing yet, but here is a list of areas that need attention

  1. GUI work - S2 includes device authentication during the inclusion process. This requires that, in the middle of the pairing process, the zwave binging needs to trigger the UI (basicUI, habmin, etc) to prompt the user to input (or scan a QR code) the number printed on the device. I’m not familiar with the OH GUIs at all so could use some help exploring if this is currently possible or what it would take to implement this
  2. A Java 8 compatible implementation of AES CTR_DBRG. Background: Java 8 does not natively support AES CTR_DBRG, but Java 9+ does. Currently this means that, when testing the S2 branch the code must be run under Java 9+. OH supports Java 8, so we need to find a compatible AES CTR_DBRG implementation before publishing/merging

Is there any update on the progress of S2 or the status is the same as in April ?

Still in the “Alpha testing of S2 logic with ZLink ZL-PA-100 Plug Switch” stage.

One item that is slowing me down quite a bit is that the powers that be refuse to publish test vectors for the custom functions (CKDF-TempExpand and CKDF-TempExtract) of the ZWave S2 spec. This means I’m stuck testing everything at once without a way to narrow down problems. It would be great to have a second set of eyes to compare my code to what’s in the spec to look for problems.

I’m also working on rebasing my changes against Chris’ latest changes and migrating to the new OH build system. Last time I tried to move the new build system it didn’t go well, but it’s probably time I try it again.

I’m interested in giving you a hand.

I have OpenHAB 2.5.0M2 installed (Windows 10), with Zooz Z-Wave stick (Zooz Z-Wave Plus S2 USB Stick ZST10).

Also have 1 S2 enabled device (HomeSeer Z-Wave Plus Floodlight Sensor [HS-FLS199+])

Forgive me, but I haven’t sniffed any network traffic to see what (if anything) appears during pairing, but I was wondering if we could pair the device, but not “enable” it (without adding the DSK [Device Specific Key] via the Configuration of Things UI)?

That way, we would not have to intercept the pairing with a UI injection. Presumably (in my mind), if the DSK is needed to complete the pairing, a SUBSEQUENT pairing could look to see if we have that UID and thingTypeUID (for the device being paired), that already has the DSK key recorded (thereby allowing the pairing to complete).

Granted that would make pairing a multi-step process, but it would eliminate having to hack the pairing process and/or UI.

Can you point me to the S2 spec you’re basing your code on?


Looks good. My branch is still based on 2.4, but I should be able to rebase against 2.5 soon, now that I have a 2.5 eclipse dev environment working again

If I understand correctly, you are suggesting a way to avoid the user from having to enter a portion of the DSK. Couple of thoughts:

  1. The DSK key is a unique key that is different for every device (even of devices of the same model. It’s printed on the device)
  2. During pairing, the device doesn’t transmit the full key, only part of it. The user HAS to enter the rest of the key somehow (GUI, config file, somewhere)
  3. @chris wants the OH implementation to be spec compliant

It’s here. IIRC, you just have to create a free account to download the docs