This clause describes security-related features that are used in more than one ZigBee layer. The NWK and APS layers shall use the auxiliary header as specified in sub-clause 3.6.1. The MAC, NWK, and APS layers shall use the security parameters specified in sub-clause 3.6.2. The formatting of all frames and fields in this specification are depicted in the order in which they are transmitted by the NWK layer, from left to right, where the leftmost bit is transmitted first in time. Bits within each field are numbered from 0 (leftmost and least significant) to k-1 (rightmost and most significant), where the length of the field is k bits. Fields that are longer than a single octet are sent to the next layer in the order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits.200
apsTrustCenterAddress 0xabb Device address
Any valid 64-bit address
Identifies the address of the device’s trust center
-
apsSecurityTime-OutPe-riod 0xacc Integer
0x0000-0xFFFF
The period of time a device will wait for an expected security pro-tocol frame (in milli-seconds).
1000
aCCB Comment #150
bIbid
cIbid
Table 168 Elements of the key-pair descriptor
Name Type Range Description Default
DeviceAddress Device address
Any valid 64-bit address
Identifies the address of the entity with which this key-pair is shared.
-MasterKey Set of 16 octets
- The actual value of the master key.
-LinkKey Set of 16
Unique identifier of the key originating with the device indicated by KeySr-cAddress.
Incoming frame counter value corre-sponding to DeviceAddress.
0x00000000
200CCB Comment #98
Table 167 AIB security attributes
ZigBee Specification
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
3.6.1 Auxiliary Frame Header Format
The auxiliary frame header, as illustrated by Table 79, shall include a security control field and a frame counter field, and may include a sender address field and key sequence number field.
3.6.1.1 Security Control Field
The security control field shall consist of a security level, a key identifier, and an extended nonce sub-field and shall be formatted as shown in Table 80.
3.6.1.1.1 Security level sub-field
The security level identifier indicates how an outgoing frame is to be secured, respectively, how an incoming frame purportedly has been secured: it indicates whether or not the payload is encrypted and to what extent data authenticity over the frame is provided, as reflected by the length of the message integrity code (MIC). The bit-length of the MIC may take the values 0, 32, 64 or 128 and determines the probability that a random guess of the MIC would be correct. The security properties of the security levels are listed in Table 169.
Figure 79 Auxiliary frame header format
Octets: 1 4 0/8 0/1
Security control Frame Counter Source Address Key Sequence Number
Figure 80 Security control field format
Bit: 0-2 3-4 5 6-7
Security level Key identifier Extended Nonce Reserved
Table 169 Security levels available to the MAC, NWK, and APS layers Security
level identifier
Security Level
Sub-Field (Table 80)
Security Attributes
Data Encryption
Frame Integrity (length M of MIC,
in number of octets)
0x00 ‘000’ None OFF NO (M = 0)
0x01 ‘001’ MIC-32 OFF YES (M=4)
0x02 ‘010’ MIC-64 OFF YES (M=8)
0x03 ‘011’ MIC-128 OFF YES (M=16)
0x04 ‘100’ ENC ON NO (M = 0)
0x05 ‘101’ ENC-MIC-32 ON YES (M=4)
0x06 ‘110’ ENC-MIC-64 ON YES (M=8)
0x07 ‘111’ ENC-MIC-128 ON YES (M=16)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 3.6.1.1.2 Key identifier sub-field
The key identifier sub-field consists of two bits that are used to identify the key used to protect the frame.
The encoding for the key identifier sub-field shall be as listed in Table 170.
3.6.1.1.3 Extended nonce sub-field
The extended nonce sub-field shall be set to 1 if the sender address field of the auxiliary header is present.
Otherwise, it shall be set to 0.
3.6.1.2 Source Address Field
The source address field shall only be present when the extended nonce sub-field of the security control field is 1. When present, the source address field shall indicate the extended 64-bit address of the device responsible for securing the frame.
3.6.1.3 Counter Field
The counter field is used to provide for frame freshness and to prevent processing of duplicate frames.
3.6.1.4 Key Sequence Number Field
The key sequence number field shall only be present when the key identifier sub-field of the security control field is 1 (i.e., the Network key). When present, the key sequence number field shall indicate the key sequence number of the Network key used to secure the frame.
3.6.2 Security Parameters
This clause specifies the parameters used for the CCM* security operations.
3.6.2.1 CCM* Mode of Operation and Parameters
Applying security to a MAC, NWK, or APS frame on a particular security level corresponds to a particular instantiation of the AES-CCM* mode of operation as specified in section B.1.2. The AES-CCM* mode of operation is an extension of the AES-CCM mode that is used in the 802.15.4-2003 MAC specification and provides capabilities for authentication, encryption, or both.
The nonce shall be formatted as specified in sub-clause 3.6.2.2.
Table 169 gives the relationship between the security level subfield of the security control field (Table 80), the security level identifier, and the CCM* encryption/authentication properties used for these operations.
Table 170 Encoding for the key identifier sub-field Key Identifier Key Identifier Sub-Field
(Table 80) Description
0x00 ‘00’ A link key.
0x01 ‘01’ A Network key.
0x02 ‘10’ A key-transport key.
0x03 ‘11’ A key-load key.
ZigBee Specification
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
3.6.2.2 CCM* Nonce
The nonce input used for the CCM* encryption and authentication transformation and for the CCM*
decryption and authentication checking transformation consists of data explicitly included in the frame and data that both devices can independently obtain. Figure 81 specifies the order and length of the subfields of the CCM* nonce. The nonce's security control and frame counter fields shall be the same as the auxiliary header’s security control and frame counter fields (as defined in sub-clause 3.6.1) of the frame being processed. The nonce’s source address field shall be set to the extended 64-bit MAC address of the device originating security protection of the frame. When the extended nonce sub-field of the auxiliary header’s security control field is 1, the extended 64-bit MAC address of the device originating security protection of the frame shall correspond to the auxiliary header’s source address field (as defined in sub-clause 3.6.1) of the frame being processed.
3.6.3 Cryptographic Key Hierarchy
The link key established between two (or more) devices via one of the key-establishment schemes specified in sub-clause 3.5.2 (or transport-key commands specified in sub-clause 3.5.3) is used to determine related secret keys, including data keys, key-transport keys, and key-load keys. These keys are determined as follows:
1. Key-Transport Key. This key is the outcome of executing the specialized keyed hash function specified in clause B.1.5 under the link key with as input string the 1-octet string ‘0x00’.
2. Key-Load Key. This key is the outcome of executing the specialized keyed hash function specified in clause B.1.5 under the link key with as input string the 1-octet string ‘0x02’.
3. Data Key. This key is equal to the link key.
All keys derived from the link key shall share the associated frame counters. Also, all layers of ZigBee shall share the Network key and associated outgoing and incoming frame counters.
3.6.4 Implementation Guidelines (Informative)
This clause provides general guidelines that should be followed to ensure a secure implementation.
3.6.4.1 Random Number Generator
A ZigBee device implementing the key-establishment (i.e., see sub-clause 3.2.4.1) security service may need a strong method of random number generation. For example, when link keys are pre-installed (e.g., in the factory), a random number may not be needed.
In all cases that require random numbers, it is critical that the random numbers are not predictable or have enough entropy, so an attacker will not be able determine them by exhaustive search. The general recommendation is that the random number generation shall meet the random number tests specified in FIPS140-2 [B12]. There are methods for generation of random numbers:
1. Base the random number on random clocks and counters within the ZigBee hardware 2. Base the random number on random external events
3. Seed each ZigBee device with a good random number from an external source during production. This random number can then used as a seed to generate additional random numbers.
Figure 81 CCM* nonce
Octets: 8 4 1
Source address Frame counter Security control
1 2