How can I decrypt S2 frames using the Z-Wave Zniffer?
The Zniffer can decrypt S2 frames, by following a few steps.
First configure the PC Controller to save the network keys. Click on the small Shield icon in the upper right corner to open the ‘Security Settings’ menu.
You can either copy a key to the clipboard and paste it into the Zniffer, or you can by default save the keys to a storage folder, where the Zniffer can load them.
In the Zniffer, click on a S2 encrypted frame and notice that it cannot be decrypted just yet.
Click on either ‘Decrypt’ or ‘Load Key’ depending on if you want to copy the key from clipboard or load from a folder. The frame can now be decrypted.
Finally, it is required that the Zniffer knows the S2 singlecast nonce, which are shared during inclusion. If the trace does not include the frames from the inclusion, it is necessary to force a resynchronization between the nodes. To resynchronize, select the node in the PC controller and click "Reset SPAN". This will result in an exchange of new nonces which, in combination with the network keys, enables the Zniffer to decrypt the payload.
I’m developing a Z-Wave device with a device type that does not match one of the Sample Applications. The needed Command Classes for this device is missing from the framework. Where can I find it?
The framework does not implement all Z-Wave command class. It only contains implementations of a subset of command classes required for the Z-Wave Plus device types of the implemented sample applications.
This means that some commonly used command classes are not implemented, and you must develop and implement these yourself.
Information on how to implement a new command class can be found in the Application Framework Guide.
Z-Wave 500: Application Framework Guide, Appendix A.
Since the inclusion process is the same for both S2-AccessControl as it is for S2-Authenticated, what is the real difference between these two security classes?
The S2-AccessControl group is not using a more secure communication than S2-Authenticated. The improved security comes from segmenting the network so that access control devices are only accessible by controllers that need to control them.
As such it is recommended to separate the device types into the following Security Classes.
All types of secure end devices including, but not limited to:
Security S2 has three security classes including S2-AccessControl, S2-Authenticated and S2-Unauthenticated. Why use the least secure method knowing it is not authenticated by the DSK?
The Z-Wave Security-2 (S2) Command Class supports many application spaces. The S2-Unauthenticated class enables secure applications at the low end of security scale provided by S2.
While the S2-Unauthenticated class is less secure than other S2 classes, it still represents a significant improvement over the protection level that can be achieved with the original Z-Wave Security-0 (S0).
The S2 Unauthenticated class enables the deployment of simple networks with very constrained network controllers. One example is a wood cabin, where a battery powered wireless wall switch controls a few LED bulbs running off a car battery and a solar panel. The wall switch also acts as the network controller, but as it has no QR scanner and no keypad for decimal entry, it is more convenient to only assign the S2-Unauthenticated class key to the LED bulbs.
Z-Wave certification will prohibit some products from operating via the S2 Unauthenticated class. This includes gateways and door locks. In other cases, manufacturers may decide that their particular application needs a protection level of at least the S2-Authenticated class.
Products may be designed to accept multiple S2 classes. For instance, a full-functional LED bulb may accept joining the S2-Unauthenticated class as well as the S2-Authenticated class
However; Device manufacturers not making access control devices should aim at including their devices in the S2-Authenticated group to maximize network security.
What is the S2 DSK and what is it used for?
The S2 DSK (Device Specific Key) is used to authenticate the included device before exchanging the network keys.
The DSK is a part of the public key. The DSK is printed physically on the device – or it can be shown on a display if that is available. The DSK is a truncated version of the public key. The public key is 32 bytes long. The DSK is the first 16 bytes of the public key. The PIN code is the first 2 bytes of the public key.
Authentication ensures that the device being included in the network is actually the intended device, and not a malicious device under the control of an attacked.
For the highest S2 security classes, S2-AccessControl and S2-Authenticated, the DSK must be exchanged out of band, e.g. by manually entering it on the controller, or through a QR code. This out of band authentication prevents the nodes participating in the key exchange from establishing a shared secret, if an incorrect DSK was entered, effectively eliminating the possibility of doing a key exchange with a malicious device.
For the lowest S2 security class, S2-Unauthenticated, the DSK is transferred in-band, and is only there for verification purposes, while the key exchange may continue if the users falsely verifies a device with a non-matching DSK.
One of the shortcomings in S0 security is the vulnerability during inclusion process, where an in-band unsecure transmission of encryption keys happened during a narrow window of the inclusion process.
How does S2 security handle key exchange?
The S2 key exchange is encrypted with a temporary key that is exchanged using the Diffie-Hellman algorithm. This temporary encryption key is known only to the two nodes participating in the key exchange, and the key is unique to these two nodes.
As the temporary key is different from the network keys, it is not among the keys that can be exported from the PC Controller, thus the Zniffer has no means to decrypt the secure inclusion.
The exception is the "Network Key Verify" frame, which is encrypted with the key it is intended to verify. This frame will be encrypted with a network key, and can be decrypted using the Zniffer.
While Key Exchange and cryptography generally relies on sophisticated mathematics, the actual principle of Diffie-Hellman Key Exchange is straightforward: It is relatively simple to multiply very large prime numbers, but it is very difficult reverse the calculation if one does not know one of the factors.
It is recommended to watch this video, to get more information on Diffie-Hellman key exchange.
Video: Diffie-hellman key exchange
Z-Wave support has asked me to provide a Support Tag. How do I find that?
In certain cases, Z-Wave Support may require you to provide the production tag from the Z-Wave module.
The production tag can be read using the Z-wave Programmer.
In the NVR tab, click on the Read button and the Z-Wave Programmer will start to read to NVR content of the module.
The production tag is marked in the screen shot.
Which TX channels do I need to adjust for a 2 or 3 channel device, respectively?
While the Z-Wave Programmer has three fields for setting TX power, only the field for Channel 0 is used on two channel devices.
This means that the setting set for channel 0 will affect both the 9.6/40 and the 100 kbps frequency. When setting the TX power for a 2 channel devices, it must be set with respect to the frequency operating closest to the limit for that particular frequency.
For three channel devices (currently Japan and Korea), the TX power for each of the three channels can be adjusted separately.
My device is reporting a version that does not seem to match my SDK version. Why is that?
A Z-Wave Embedded SDK contains several software packages, which each has a version number. These includes:
When using the Command Class ‘Version’ the returned version is for the Z-Wave Protocol and for the Z-Wave Plus Framework.
To get the full overview of which versions a giving SDK includes, refer to:
Why do I need to use a SAW filter in my design?
In several regions, upload in the LTE band occurs at frequencies located closer than 10 MHz from frequencies used by Z-Wave. Due to the high power level allowed, in addition to the loose restrictions on side band emissions granted to the LTE band, the LTE upload may interfere significantly with the operation of a listening Z-Wave node located nearby.
To reduce the impact from other devices, the Z-wave device must incorporate a SAW filter which attenuates these technologies, thus preventing saturation of the receiver.
The effects of interference from LTE is outlined in LTE Case Study.