Previous Z-Wave Controller SDK Versions

Z-Wave SDK 6.7x offers best in class security for Personal Area Network (PAN) by using industry standard security features. To improve Z-Wave application and network security we have redesigned the Z-Wave security.

Security S2 enables secure communication for sensor devices that run for years on a single battery. At the same time it enables secure multicast addressing of lights, window coverings and similar devices.

Consumer product manufacturers will appreciate that the S2 Security solution only requires a small code footprint in embedded devices while installers benefit from the simple installation procedure.

S2 complements similar optimized mechanisms for IP domains that allow Z-Wave services to operate securely in an end-to-end fashion.

Z-Wave nodes are added to the Z-Wave network (PAN) with Out-of-Band (OOB) authentication to ensure that they can be trusted.

A strong temporary key is used to assign keys for one or more security classes.

Z/IP* GW SDK 2.11 Downloads and Support Documents

Starting up with SDK 6.7x? We recommend to go through the Security S2 white paper and the following important documents. These documents is the stepping stone for Security S2 and latest Z-Wave SDK 6.70.

*The Z/IP gateway is a free reference design intended for development and demonstration purposes only.  It is provided as is, with no warranties. Customers are advised to conduct security and compliance testing of all gateways during the product design process.

Z-Wave Security S2 for SDK 6.7x Features

Security classes and network keys

Like Wi-Fi, Z-Wave S2 security also operates with the concept of a network key. All nodes may use this key to communicate to each other. Both Security S2 and S0 use AES-128 bit encryption. The US Government considers AES-128 safe enough for classified information up to the SECRET level [NSA_AES].

Combined with S2 authentication and Nonce scrambling, there is no known way to break this protection – even with the aid of a super computer.
 

Device Authentication

The S2 authentication process allows an including controller to verify that a joining node is indeed the physical device that it claims to be. Depending on the UI, an including controller may allow the installer to enter a Device-Specific Key (DSK) string of decimal digits that can be read visually or scanned as a QR code.

The DSK is the first 16 bytes of the 32-byte long ECDH public key of the joining node.
 

Key Exchange

The latest Security S2 in SDK 6.7x uses Diffie-Hellman key exchange.

A popularly illustration of Diffie-Hellman key exchange [DIFFIE-HELLMAN] is the mixing of colors and finding it hard to separate them again. This is known as a one-way function.

A similar mathematical one-way function is raising large prime numbers to the power of large numbers. Given sufficiently large numbers, even today’s supercomputers will have a hard time reversing this operation.

The size of exchanged keys is reduced significantly by using Elliptic Curve cryptography [ECDH].

Due to concerns that earlier curves had been compromised, the security industry moved to Curve25519 [CURVE 25519] in 2014. Curve25519 is perfect for Z-Wave because it requires less computation power than earlier curves, hence saves battery.

Z-Wave Security S2 Advantages

Secure multicast with no addressing overhead

S2 makes a virtue of necessity and uses plain Z-Wave Broadcast frames for S2 Multicast transmissions, thereby avoiding the 30-byte overhead associated with Z-Wave Multicast transmissions.

The length of an S2 Multicast frame is comparable to the S2 Singlecast follow-up frame.
 

Application status polling not needed

Z-Wave’s bandwidth is limited. Yet, a number of control applications have a need for precise status information.

For example, a door lock control panel, which needs to know if the door was really locked after sending a “Lock” command. It may take several seconds for that operation to complete.

The classic approach would be to use polling. But Z-Wave Plus puts restrictions on the use of polling as it affects the performance of the entire network.

With S2, there is no need for polling. All S2 capable devices support the Supervision Command Class as it also serves to acknowledge the secure delivery of an S2 encrypted command.

The Supervision Report allows a destination node to advertise its current and future operational state. A receiving door lock may immediately advertise its current Supervision state as “Working” with an expected duration of three seconds, and later, its updated Supervision state “Success”.
 

50% less energy consumption than S0

Let's take an example of a sensor based on the Z-Wave 500 series chip. The sensor reports the temperature every five minutes. It also queries a mailbox for pending commands every 30 minutes.

• Without security, the sensor draws an average current of 2.2 µA.
• The S0 challenge-response overhead leads to an average current of 5.9 µA.
• A similar S2 sensor uses only 30% more energy than the non-secure sensor (2.9 µA) which is 50% less than S0.
   

200% less bandwidth usage for OTA firmware update compared to S0

Individual frame delivery confirmation may not always be needed. One such example is an over the air (OTA) firmware update which employs its own retransmission state machine. S2 encryption can be used in one-frame-mode.

This mode only has a small overhead compared to the non-secure variant. A node can receive an S2 protected OTA firmware update at virtually the same time and battery cost as a nonsecure node.

When compared to S0, a node running S0 would need 200% more bandwidth and energy for the same task.
 

Active protection against attacks via Nonce

IS2 network keys are secret among trusted nodes and should not be revealed to others via predictable patterns in the payload. Therefore, any frame is scrambled by a long Nonce before encryption.

The 13-byte singlecast Nonce (SPAN) is auto-updated before each new transmission. This prevents an attacker from recording a command and replaying it later.

Z-Wave Security S2 Command Class

S2 Class 0 - Unauthenticated

The first risk class is S2 Class 0 or Unauthenticated. Device manufacturers can use this risk class for low-cost Z-Wave devices without DSK label.

Controllers, which do not have any DSK authentication mechanism, also use S2 Class 0.

For example, a light dimmer device may advertise S2 Class 0 (Unauthenticated).

S2 Class 1 - Authenticated

All Z-Wave nodes which can have DSK label may advertise S2 Class 1 or Authenticated. There are some restriction for Secure Door Lock and similar devices.

At the time of inclusion user needs to input first 5 digits of DSK.

S2 Class 2- Access Control

This is the highest risk level in Z-Wave Security S2.

A door lock may advertise S2 Class 2 (Access Control) as its only class because it requires the highest protection level.

Z/IP GW SDK 2.1x

Z-Wave Security 2 Command Class Version 1

The Z/IP Gateway MUST communicate using Security 2 to Z-Wave nodes that support Z-Wave Security 2 Command Class. All Security is terminated in the Z/IP Gateway and never leaves the Z-Wave network.
 

Network Management Command Classes Version 2

Network Management Command Classes Version 2 provides required Security 2 functionality:

• Network Management Inclusion - Updated Add / Remove / Replace
• Network Management Basic - Updated Learn Mode - New DSK Get/Report
• Network Management Proxy - Updated Node Info Cached Get / Report
   

Z/IP Packet Command Class Version 3

The Encapsulation Format Info Header Extension is added to the Z/IP Packet Command Class Version 3. The extension serves two purposes:

• Indication of the encapsulations used when the frame was received by the Z/IP Gateway
• Which encapsulations should be used by the Z/IP Gateway when sending a frame
   

Transport Service Command Class Version 2
 

The Transport Service Command Class version 2 provides the following features:

• Reliable Checksum
• Transport protocol style transmission, providing means for fragmentation of frames exceeding the PHY frame length, re-transmission of missing fragments and robust error handling
   

Two Unsolicited Destinations

Z/IP Gateway 2.x supports a secondary unsolicited destination to be configured through the configuration file. The secondary destination cannot be configured remotely.