Zigbee Smart Energy (ZSE) Security#
Due to the complexity of the security used in ZSE application development, this topic has been given its own section detailing the implementation and design requirements and considerations. Note that more detailed information about ZSE can be found in the Zigbee Smart Energy Profile Specification, available at the https://www.zigbee.org website.
Overview#
The following sections explain the concepts used in ZSE to provide additional security beyond the Zigbee standard security.
Installation Codes#
ZSE devices are required to have and use installation code keys to join the network. Trust centers are required to use them as part of the initial joining. For more information, see section Installation Code Keys. You can find more information about this process in the "Out of Band PreConfigured Link Key Process" section of the Zigbee Smart Energy Profile Specification.
Certificates and Key Establishment#
Once a device has joined to the ZSE network and obtained the network key from the trust center, the new device must then re-negotiate its trust center link key through certificate-based key establishment (CBKE). This takes the place of the Zigbee 3.0 link key request mechanism that a standard Zigbee 3.0 device uses.
The CBKE protocol ensures that the new link key is unrelated to the preconfigured key, ensures that the key that is random and unreproducible, and provides proof of identity by validating the authenticity of the certificates at both devices. The new link key derived from this CBKE process replaces the original, preconfigured trust center link key, such that the preconfigured key is not used again unless this new ZSE device is purged from the network and later needs to re-enter. ZSE networks require that a CBKE-based link key shall be used for unicast data communications on most ZSE clusters. (Refer to the "Cluster Usage of Security Keys" section of the Zigbee Smart Energy Profile Specification for details about which clusters require only Network layer security and which require both Network and APS layer security.)
CBKE is variation of Public Key-Key Establishment (PKKE, as opposed to SKKE, Symmetric Key-Key Establishment) between a pair of devices. PKKE is a process whereby a link key is established based on each party’s shared, static, public key and ephemeral, public key. Since these keys are public, they do not require secrecy in their storage and transmission. These keys by themselves (without the non-public certificate data) aren’t enough to recreate the key, so knowledge of these public keys doesn’t compromise the established link key. In CBKE, specifically, each device’s static, public key is transported as part of a device-implicit certificate signed by the sender’s certificate authority (CA), allowing the receiver to validate the device’s identity during key establishment; this differs from traditional PKKE, where certificates are manually created.
The digital certificates used in the CBKE process are programmed into each device at manufacturing time and are issued by the CA. For the process to complete successfully, both devices must contain certificates signed by the same CA. For ZSE networks using Smart Energy 1.x protocol versions, Certicom (www.certicom.com) is the only Zigbee-approved certificate issuer. Certicom offers certificates signed by either of the following CAs:
Test SE CA: A special certificate authority used exclusively for non-commercial testing purposes. Certificates signed by this CA are free to generate through Certicom’s website.
Production CA: The normal certificate authority used by Certicom to sign certificates for production-grade devices used in commercial deployments. These certificates require paid licensing terms with Certicom to generate and will not interoperate with test certificates signed by the Test SE CA.
There are actually two different certificate formats and two different elliptic curves used by the CBKE protocol. The original Smart Energy 1.0 specification used the sect163k1 elliptic curve, which has a symmetric key equivalent length of 80 bits. The NIST standard recommends a key strength of 128 bits for all devices deployed after 2010 (see NIST sp800-57-part1, Table 4: Recommended algorithms and minimum key sizes). Therefore, the Smart Energy 1.2 standard introduced a second elliptic curve, sect283k1, which has an equivalent strength of128 bits. Smart Energy labelled the certificate format and curve for the SE 1.0 release Crypto Suite 1, and labelled the certificate format for the SE 1.2 release Crypto Suite 2. Smart Energy 1.2 supports both Crypto Suite 1 and Crypto Suite 2.
The Crypto Suite 1 certificate data stored on each device consist of the fields described in the following table.
| Size (bytes) | Name | Description |
|---|---|---|
22 | CA Public Key | Public key specific to the CA who signed the certificate. During CBKE, this is used to verify the authenticity of the CA. |
48 | Device-Implicit Certificate | Unique data signed by the CA (using the CA's private key) and representing the digital certificate for this specific device. This is the portion of the certificate that is shared over the air during CBKE and contains the following subfields: |
" | " | Reconstruction data for the device's public key (22 bytes) |
" | " | This device's IEEE MAC address (EUI64), also known as the Subject for the certificate (8 bytes in MSB order) |
" | " | Issuer ID for the CA who created this device-implicit certificate (8 bytes in MSB order) |
" | " | Profile-specific data as defined by the Zigbee application profile using the certificate. The first 2 bytes represent the 16-bit Zigbee application profile ID (in most significant byte notation), such as 0x0109 for ZSE. (10 bytes) |
21 | Device Private Key | A unique, device-specific value chosen by the CA during certificate generation. During CBKE, this is used as an input (along with the Device Public Key) to an Elliptic-Curve Cryptography (ECC) algorithm. |
The Crypto Suite 2 certificate data stored on each device consist of the fields described in the following table.
| Size (bytes) | Name | Description |
|---|---|---|
| 1 | Type | Type of certificate. 0 = implicit, no extensions. |
| 8 | SerialNo | Serial Number of the Certificate |
| 1 | Curve | Curve identifier (sect283k1 is 0x0D) |
| 1 | Hash | Hash identifier (AES-MMO is 0x08) |
| 8 | Issuer | 8 byte identifier, 64-bit IEEE 802.15.4 address. |
| 5 | ValidFrom | 40-bit Unix time from which the certificate is valid. |
| 4 | ValidTo | 32-bit # seconds from the ValidFrom time for which the certificate is considered valued (0xFFFFFFFF = infinite) |
| 8 | SubjectID | 8 byte identifier, 64-bit IEEE 802.15.4 address |
| 1 | KeyUsage | Bit flag indicating key usage (0x88 = digital signature or key agreement allowed) |
| 37 | PublicKey | 37-byte compressed public key value from which the public key of the Subject is reconstructed. |
This certificate data is used at runtime to establish a shared secret (the new link key) through ECC computations along an elliptic-curve. While the computational details of the CBKE process are beyond the scope of this document, the Zigbee Cluster Library (ZCL) messages exchanged as part of this process are illustrated in the following figure. Additional details about this process can be found in Appendix C of the Zigbee Smart Energy Profile Specification. All of these messages are encrypted at the Network layer without any APS layer encryption. The Initiator in this process is typically the new device that entered the network, while the Responder is typically the trust center or Energy Services Interface (ESI) for the Home Area Network (HAN).
Once the key has been established, it can be used for future ZSE-related transactions among this pair of devices. If ZSE-related communications is desired between another pair of devices in the HAN, the two devices can request a mutual link key by requesting one from the trust center (who is a trusted party by virtue of CBKE having succeeded). For information about third-party application link key requests, refer to section Application Link Keys.
Application Layer Requirements#
To ensure ZSE end-product compliance, ZSE devices have a number of special design requirements including the following, which make them unique from other Zigbee devices:
Support for CBKE, including the underlying ECC algorithm used for key generation.
Support for Elliptic-Curve Digital Signature Authentication (ECDSA), which is needed for validating firmware image data transferred in the ZSE Over-the-Air (OTA) Bootload cluster.
Pre-installed certificates issued by the proper certificate authority.
Pre-installed installation codes chosen by the manufacturer.
Access to the installation code and EUI64 during network setup (to facilitate out-of-band communication of this data to the trust center).
(Trust center only) Key table space sufficient to track the maximum number of ZSE devices that the HAN will support.
(Trust center only) Support for inputting installation codes (for deriving link key values through an AES-MMO hash function) or link key values and EUI64 addresses (for creating key table entries for new devices).
APS data messages for certain clusters (most ZSE clusters) require APS security with an application (or trust center) link key.
The Zigbee application framework ensures that the above requirements are satisfied (where applicable) when the Simplicity Studio AppBuilder or Project Configurator tool is used to configure a ZSE device. For more information about Zigbee application framework-based development, refer to document UG391: Zigbee Application Framework Developer's Guide for SDK 6.x and Lower or UG491: Zigbee Application Framework Developer’s Guide for SDK 7.0 and Higher.
Additional Sources of Information#
For more information regarding ZSE security concepts, refer to the following resources:
ZSE AMI Profile Specification – Zigbee document #07-5356. This is the top-level application profile specification for ZSE and is available for public (non-member) download through the www.zigbee.org website.
AN708: Setting Smart Energy Certificates for Zigbee Devices. This is an application note explains how to program the necessary manufacturing data (certificates and installation codes) into Silicon Labs chips using Silicon Labs programming tools and how to verify these data once they have been programmed into the device.
AN714: Smart Energy ECC-Enabled Device Setup Process. This application note describes how to set up a device with the security resources required to support Smart Energy (SE) security. While these security resources are not necessary for testing SE networks, any devices designed to participate in or host a Zigbee-compliant, production-grade (non-test) SE network must implement these features.
UG391: Zigbee Application Framework Developer's Guide for SDK 6.x and Lower or UG491: Zigbee Application Framework Developer’s Guide for SDK 7.0 and Higher. This document describes the command line interface (CLI) commands available for inspecting and altering the security configuration of a Silicon Labs Zigbee application framework-based application at runtime. It also explains any callbacks or components/plugins used by the Zigbee application framework to implement security behavior in the application.