第1页 / 共378页
第2页 / 共378页
第3页 / 共378页
第4页 / 共378页
第5页 / 共378页
第6页 / 共378页
第7页 / 共378页
第8页 / 共378页
ZigBee-Specification-2004(IEEE802.15.4-ZigBee协议规范).pdf
Figures
Tables
Figure 1 Outline ZigBee stack architecture
[B1] Institute of Electrical and Electronics Engineers, Inc., IEEE Std. 802.15.4-2003, IEEE Standard for Information Technology - Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks - Specific Re...
[B2] IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic, IEEE, 1985.
[B3] Document 03285r0: Suggestions for the Improvement of the IEEE 802.15.4 Standard, July 2003.
[B4] Document 02055r4: Network Requirements Definition, August 2003.
[B5] ISO/IEC 639-1:2002 Codes for the representation of names of languages - Part 1: Alpha-2 code.
[B6] ISO/IEC 646:199 Information technology -- ISO 7-bit coded character set for information interchange.
[B7] ANSI X9.63-2001, Public Key Cryptography for the Financial Services Industry - Key Agreement and Key Transport Using Elliptic Curve Cryptography, American Bankers Association, November 20, 2001. Available from http://www.ansi.org.
[B8] FIPS Pub 197, Advanced Encryption Standard (AES), Federal Information Processing Standards Publi cation 197, US Department of Commerce/N.I.S.T, Springfield, Virginia, November 26, 2001. Available from http://csrc.nist.gov/.
[B9] FIPS Pub 198, The Keyed-Hash Message Authentication Code (HMAC), Federal Information Process ing Standards Publication 198, US Department of Commerce/N.I.S.T., Springfield, Virginia, March 6, 2002. Available from http://csrc.nist.gov/.
[B10] ISO/IEC 9798-2, Information Technology - Security Techniques - Entity Authentication Mechanisms - Part 2: Mechanisms Using Symmetric Encipherment Algorithms, International Standardization Organiza tion, Geneva, Switzerland, 1994 (first ...
[B11] NIST Pub 800-38A 2001 ED, Recommendation for Block Cipher Modes of Operation - Methods and Techniques, NIST Special Publication 800-38A, 2001 Edition, US Department of Commerce/N.I.S.T., December 2001. Available from http://csrc.nist.gov/.
[B12] FIPS Pub 140-2, Security requirements for Cryptographic Modules, US Department of Commerce/ N.I.S.T., Springfield, Virginia, June 2001 (supersedes FIPS Pub 140-1). Available from http://csrc.nist.gov/.
[B13] IEEE Standards Style Manual, published and distributed in May 2000 and revised on September 20, 2001. Available from http://standards.ieee.org/guides/style/.
[B14] ISO/IEC 7498-1:1994 Information technology - Open systems interconnection - Basic reference model: The basic model.
[B15] ISO/IEC 10731:1994, Information technology - Open Systems Interconnection - Conventions for the definition of OSI services.
[B16] ISO/IEC 9646-1:1991, Information technology - Open Systems Interconnection - Conformance test ing methodology and framework - Part 1: General concepts.
[B17] ISO/IEC 9646-7:1995, Information technology - Open Systems Interconnection - Conformance test ing methodology and framework - Part 7. Implementation conformance statements.
[B18] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied Cryptography, Boca Raton: CRC Press, 1997.
[B19] FIPS Pub 113, Computer Data Authentication, Federal Information Processing Standards Publication 113, US Department of Commerce/N.I.S.T., May 30, 1985. Available from http://csrc.nist.gov/.
[B20] R. Housley, D. Whiting, N. Ferguson, Counter with CBC-MAC (CCM), submitted to N.I.S.T., June 3, 2002. Available from http://csrc.nist.gov/encryption/modes/proposedmodes/.
[B21] J. Jonsson, On the Security of CTR + CBC-MAC, in Proceedings of Selected Areas in Cryptography - SAC 2002, K. Nyberg, H. Heys, Eds., Lecture Notes in Computer Science, Vol. 2595, pp. 76-93, Berlin: Springer, 2002.
[B22] J. Jonsson, On the Security of CTR + CBC-MAC, NIST Mode of Operation - Additional CCM Documentation. Available from http://csrc.nist.gov/encryption/modes/proposedmodes/.
[B23] P. Rogaway, D. Wagner, A Critique of CCM, IACR ePrint Archive 2003-070, April 13, 2003.
Chapter 1 Application Layer Specification
1.1 General description
1.1.1 Application support sub-layer
1.1.2 Application framework
1.1.2.1 Key value pair service
1.1.2.2 Message service
1.1.3 Addressing
1.1.3.1 Node addressing
Figure 2 Multiple subunits in a single node
1.1.3.2 Endpoint addressing
1.1.4 Application communication fundamentals
1.1.4.1 Profiles
1.1.4.2 Clusters
1.1.5 Discovery
1.1.5.1 Device discovery
1.1.5.2 Service discovery
1.1.6 Binding
Figure 3 ZigBee binding and binding table
1.1.7 Messaging
1.1.7.1 Direct addressing
1.1.7.2 Indirect addressing
1.1.7.3 Broadcast addressing
1.1.8 ZigBee device objects
1.1.8.1 Discovery management
1.1.8.2 Binding management
1.1.8.3 Security management
1.2 The ZigBee application support (APS) sub-layer
1.2.1 Scope
1.2.2 Purpose
1.2.3 Application support (APS) sub-layer overview
1.2.3.1 Application support sub-layer data entity (APSDE)
1.2.3.2 Application support sub-layer management entity (APSME)
1.2.4 Service specification
Figure 4 The APS sub-layer reference model
1.2.4.1 APS data service
1.2.4.1.1 APSDE-DATA.request
1.2.4.1.1.1 Semantics of the service primitive
1.2.4.1.1.2 When generated
1.2.4.1.1.3 Effect on receipt
1.2.4.1.2 APSDE-DATA.confirm
1.2.4.1.2.1 Semantics of the service primitive
1.2.4.1.2.2 When generated
1.2.4.1.2.3 Effect on receipt
1.2.4.1.3 APSDE-DATA.indication
1.2.4.1.3.1 Semantics of the service primitive
1.2.4.1.3.2 When generated
1.2.4.1.3.3 Effect on receipt
1.2.4.2 APS management service
1.2.4.3 Binding Primitives
1.2.4.3.1 APSME-BIND.request
1.2.4.3.1.1 Semantics of the service primitive
1.2.4.3.1.2 When generated
1.2.4.3.1.3 Effect on receipt
1.2.4.3.2 APSME-BIND.confirm
1.2.4.3.2.1 Semantics of the service primitive
1.2.4.3.2.2 When generated
1.2.4.3.2.3 Effect on receipt
1.2.4.3.3 APSME-UNBIND.request
1.2.4.3.3.1 Semantics of the service primitive
1.2.4.3.3.2 When generated
1.2.4.3.3.3 Effect on receipt
1.2.4.3.4 APSME-UNBIND.confirm
1.2.4.3.4.1 Semantics of the service primitive
1.2.4.3.4.2 When generated
1.2.4.3.4.3 Effect on receipt
1.2.4.4 Information base maintenance
1.2.4.4.1 APSME-GET.request
1.2.4.4.1.1 Semantics of the service primitive
1.2.4.4.1.2 When generated
1.2.4.4.1.3 Effect on receipt
1.2.4.4.2 APSME-GET.confirm
1.2.4.4.2.1 Semantics of the service primitive
1.2.4.4.2.2 When generated
1.2.4.4.2.3 Effect on receipt
1.2.4.4.3 APSME-SET.request
1.2.4.4.3.1 Semantics of the service primitive
1.2.4.4.3.2 When generated
1.2.4.4.3.3 Effect on receipt
1.2.4.4.4 APSME-SET.confirm
1.2.4.4.4.1 Semantics of the service primitive
1.2.4.4.4.2 When generated
1.2.4.4.4.3 Effect on receipt
1.2.5 Frame formats
1.2.5.1 General APDU frame format
Figure 5 General APS frame format
1.2.5.1.1 Frame control Field
Figure 6 Format of the frame control field
1.2.5.1.1.1 Frame type sub-field
1.2.5.1.1.2 Delivery mode sub-field
1.2.5.1.1.3 Indirect address mode sub-field
1.2.5.1.1.4 Security sub-field
1.2.5.1.1.5 Acknowledgement request sub-field
1.2.5.1.2 Destination endpoint field
1.2.5.1.3 Cluster identifier field
1.2.5.1.4 Profile identifier field
1.2.5.1.5 Source endpoint field
1.2.5.1.6 Frame payload field
1.2.5.2 Format of individual frame types
1.2.5.2.1 Data frame format
Figure 7 Data frame format
1.2.5.2.1.1 Data frame APS header field
1.2.5.2.1.2 Data payload field
1.2.5.2.2 APS command frame format
Figure 8 APS command frame format
1.2.5.2.2.1 APS command frame APS header field
1.2.5.2.2.2 APS command identifier field
1.2.5.2.2.3 APS command payload field
1.2.5.2.3 Acknowledgement frame format
Figure 9 Acknowledgement frame format
1.2.5.2.3.1 Acknowledgement frame APS header field
1.2.6 Command frames
1.2.7 Constants and PIB attributes
1.2.7.1 APS Constants
1.2.7.2 APS Information Base
1.2.8 Functional description
1.2.8.1 Binding
1.2.8.1.1 Binding table implementation
1.2.8.1.2 Binding
Figure 10 Direct binding on a ZigBee coordinator or SrcAddr device
1.2.8.2 Transmission, reception and acknowledgement
1.2.8.2.1 Transmission
1.2.8.2.2 Reception and rejection
1.2.8.2.3 Use of acknowledgements
1.2.8.2.3.1 No acknowledgement
Figure 11 Successful data transmission without an acknowledgement
1.2.8.2.3.2 Acknowledgement
Figure 12 Successful data transmission with an acknowledgement
1.2.8.2.4 Retransmissions
1.3 The ZigBee application framework
1.3.1 Creating a ZigBee profile
1.3.1.1 Getting a profile identifier from the ZigBee Alliance
1.3.1.2 Defining device descriptions and clusters
1.3.1.3 Deploying the profile on endpoints
1.3.1.4 Enabling service discovery
1.3.1.5 Mixing standard and proprietary profiles
1.3.1.6 Enabling backward compatibility
1.3.2 Standard data type formats
1.3.2.1 No data type
1.3.2.2 Unsigned 8-bit integer
1.3.2.3 Signed 8-bit integer
1.3.2.4 Unsigned 16-bit integer
1.3.2.5 Signed 16-bit integer
1.3.2.6 Semi-precision number
Value = -1Sign * (Hidden + Mantissa/1024) * 2 (Exponent-15)
-1Sign * (1 +1023/1024) * 2 (30 -15) = ± 1.9990234 * 32768 = ± 65504
1.3.2.7 Absolute time
1.3.2.8 Relative time
1.3.2.9 Character string
Figure 13 Format of the character string type
1.3.2.10 Octet string
Figure 14 Format of the octet string type
1.3.3 ZigBee descriptors
1.3.3.1 Transmission of descriptors
Figure 15 Format of the complex descriptor
Figure 16 Format of an individual complex descriptor field
1.3.3.1.1 Field count field
1.3.3.1.1.1 Compressed XML tag field
1.3.3.1.1.2 Field data field
1.3.3.2 Discovery via descriptors
1.3.3.3 Composite devices
1.3.3.4 Node descriptor
1.3.3.4.1 Logical type field
1.3.3.4.2 APS flags field
1.3.3.4.3 Frequency band field
1.3.3.4.4 MAC capability flags field
Figure 17 Format of the MAC capability flags field
1.3.3.4.5 Manufacturer code field
1.3.3.4.6 Maximum buffer size field
1.3.3.4.7 Maximum transfer size field
1.3.3.5 Node power descriptor
1.3.3.5.1 Current power mode field
1.3.3.5.2 Available power sources field
1.3.3.5.3 Current power source field
1.3.3.5.4 Current power source level field
1.3.3.6 Simple descriptor
1.3.3.6.1 Endpoint field
1.3.3.6.2 Application profile identifier field
1.3.3.6.3 Application device identifier field
1.3.3.6.4 Application device version field
1.3.3.6.5 Application flags field
1.3.3.6.6 Application input cluster count field
1.3.3.6.7 Application input cluster list
1.3.3.6.8 Application output cluster count field
1.3.3.6.9 Application output cluster list
1.3.3.7 Complex Descriptor
1.3.3.7.1 Language and character set field
Figure 18 Format of the language and character set field
1.3.3.7.2 Manufacturer name field
1.3.3.7.3 Model name field
1.3.3.7.4 Serial number field
1.3.3.7.5 Device URL field
1.3.3.7.6 Icon field
1.3.3.7.7 Icon URL field
1.3.3.8 User descriptor
1.3.4 AF frame formats
Figure 19 Format of the general application framework command frame
Figure 20 Format of a transaction field
1.3.4.1 Transaction count field
1.3.4.2 Frame type field
1.3.4.3 Transaction sequence number field
1.3.4.4 Transaction data field
1.3.4.5 Format of individual frame types
1.3.4.5.1 Key value pair (KVP) frame format
Figure 21 Format of the general KVP command frame
1.3.4.5.1.1 Command type identifier field
1.3.4.5.1.2 Attribute data type field
1.3.4.5.1.3 Attribute identifier field
1.3.4.5.1.4 Error code field
1.3.4.5.1.5 Attribute data field
1.3.4.5.2 MSG frame format
Figure 22 Format of the MSG transaction frame
1.3.4.5.2.1 Transaction length field
1.3.4.5.2.2 Transaction data field
1.3.5 KVP command frames
1.3.5.1 Get with acknowledgement command frame
Figure 23 Format of the get with acknowledgement command frame
1.3.5.1.1 When generated
1.3.5.1.2 Effect on receipt
1.3.5.2 Get response command frame
Figure 24 Format of the get response command frame
1.3.5.2.1 When generated
1.3.5.2.2 Effect on receipt
1.3.5.3 Set/set with acknowledgement command frame
Figure 25 Format of the set/set with acknowledgement command frame
1.3.5.3.1 When generated
1.3.5.3.2 Effect on receipt
1.3.5.4 Set response command frame
Figure 26 Format of the set response command frame
1.3.5.4.1 When generated
1.3.5.4.2 Effect on receipt
1.3.5.5 Event/event with acknowledgement
Figure 27 Format of the event/event with acknowledgement command frame
1.3.5.5.1 When generated
1.3.5.5.2 Effect on receipt
1.3.5.6 Event response command frame
Figure 28 Format of the event response command frame
1.3.5.6.1 When generated
1.3.5.6.2 Effect on receipt
1.3.6 Functional description
1.3.6.1 Aggregate transactions
1.3.6.2 Reception and rejection
1.4 The ZigBee device profile
1.4.1 Scope
1.4.2 Device Profile overview
1.4.2.1 Device and service discovery overview
1.4.2.2 End device bind overview
1.4.2.3 Bind and unbind overview
1.4.2.4 Network management overview
1.4.2.5 Device Descriptions for the Device Profile
1.4.2.6 Service Type usage
1.4.2.7 Configuration and roles
1.4.2.8 Cluster ID format within the Device Profile
Figure 29 Cluster ID Format for the Device Profile
1.4.3 Client services
1.4.3.1 Device and Service Discovery client services
1.4.3.1.1 NWK_addr_req
1.4.3.1.1.1 Semantics of the service primitive
1.4.3.1.1.2 When generated
1.4.3.1.1.3 Effect on receipt
1.4.3.1.2 IEEE_addr_req
1.4.3.1.2.1 Semantics of the service primitive
1.4.3.1.2.2 When generated
1.4.3.1.2.3 Effect on receipt
1.4.3.1.3 Node_Desc_req
1.4.3.1.3.1 Semantics of the service primitive
1.4.3.1.3.2 When generated
1.4.3.1.3.3 Effect on receipt
1.4.3.1.4 Power_Desc_req
1.4.3.1.4.1 Semantics of the service primitive
1.4.3.1.4.2 When generated
1.4.3.1.4.3 Effect on receipt
1.4.3.1.5 Simple_Desc_req
1.4.3.1.5.1 Semantics of the service primitive
1.4.3.1.5.2 When generated
1.4.3.1.5.3 Effect on receipt
1.4.3.1.6 Active_EP_req
1.4.3.1.6.1 Semantics of the service primitive
1.4.3.1.6.2 When generated
1.4.3.1.6.3 Effect on receipt
1.4.3.1.7 Match_Desc_req
1.4.3.1.7.1 Semantics of the service primitive
1.4.3.1.7.2 When generated
1.4.3.1.7.3 Effect on receipt
1.4.3.1.8 Complex_Desc_req
1.4.3.1.8.1 Semantics of the service primitive
1.4.3.1.8.2 When generated
1.4.3.1.8.3 Effect on receipt
1.4.3.1.9 User_Desc_req
1.4.3.1.9.1 Semantics of the service primitive
1.4.3.1.9.2 When generated
1.4.3.1.9.3 Effect on receipt
1.4.3.1.10 Discovery_Register_req
1.4.3.1.10.1 Semantics of the service primitive
1.4.3.1.10.2 When generated
1.4.3.1.10.3 Effect on receipt
1.4.3.1.11 End_Device_annce
1.4.3.1.11.1 Semantics of the service primitive
1.4.3.1.11.2 When generated
1.4.3.1.11.3 Effect on receipt
1.4.3.1.12 User_Desc_set
1.4.3.1.12.1 Semantics of the service primitive
1.4.3.1.12.2 When generated
1.4.3.1.12.3 Effect on receipt
1.4.3.2 End Device Bind, Bind and Unbind client services
1.4.3.2.1 End_Device_Bind_req
1.4.3.2.1.1 Semantics of the service primitive
1.4.3.2.1.2 When generated
1.4.3.2.1.3 Effect on receipt
1.4.3.2.2 Bind_req
1.4.3.2.2.1 Semantics of the service primitive
1.4.3.2.2.2 When generated
1.4.3.2.2.3 Effect on receipt
1.4.3.2.3 Unbind_req
1.4.3.2.3.1 Semantics of the service primitive
1.4.3.2.3.2 When generated
1.4.3.2.3.3 Effect on receipt
1.4.3.3 Network Management Client Services
1.4.3.3.1 Mgmt_NWK_Disc_req
1.4.3.3.1.1 Semantics of the service primitive
1.4.3.3.1.2 When generated
1.4.3.3.1.3 Effect on receipt
1.4.3.3.2 Mgmt_Lqi_req
1.4.3.3.2.1 Semantics of the service primitive
1.4.3.3.2.2 When generated
1.4.3.3.2.3 Effect on receipt
1.4.3.3.3 Mgmt_Rtg_req
1.4.3.3.3.1 Semantics of the service primitive
1.4.3.3.3.2 When generated
1.4.3.3.3.3 Effect on receipt
1.4.3.3.4 Mgmt_Bind_req
1.4.3.3.4.1 Semantics of the service primitive
1.4.3.3.4.2 When generated
1.4.3.3.4.3 Effect on receipt
1.4.3.3.5 Mgmt_Leave_req
1.4.3.3.5.1 Semantics of the service primitive
1.4.3.3.5.2 When generated
1.4.3.3.5.3 Effect on receipt
1.4.3.3.6 Mgmt_Direct_Join_req
1.4.3.3.6.1 Semantics of the service primitive
1.4.3.3.6.2 When generated
1.4.3.3.6.3 Effect on receipt
1.4.4 Server services
1.4.4.1 Device and Service Discovery Server Services
1.4.4.1.1 NWK_addr_rsp
1.4.4.1.1.1 Semantics of the service primitive
1.4.4.1.1.2 When generated
1.4.4.1.1.3 Effect on receipt
1.4.4.1.2 IEEE_addr_rsp
1.4.4.1.2.1 Semantics of the service primitive
1.4.4.1.2.2 When generated
1.4.4.1.2.3 Effect on receipt
1.4.4.1.3 Node_Desc_rsp
1.4.4.1.3.1 Semantics of the service primitive
1.4.4.1.3.2 When generated
1.4.4.1.3.3 Effect on receipt
1.4.4.1.4 Power_Desc_rsp
1.4.4.1.4.1 Semantics of the service primitive
1.4.4.1.4.2 When generated
1.4.4.1.4.3 Effect on receipt
1.4.4.1.5 Simple_Desc_rsp
1.4.4.1.5.1 Semantics of the service primitive
1.4.4.1.5.2 When generated
1.4.4.1.5.3 Effect on receipt
1.4.4.1.6 Active_EP_rsp
1.4.4.1.6.1 Semantics of the service primitive
1.4.4.1.6.2 When generated
1.4.4.1.6.3 Effect on receipt
1.4.4.1.7 Match_Desc_rsp
1.4.4.1.7.1 Semantics of the service primitive
1.4.4.1.7.2 When generated
1.4.4.1.7.3 Effect on receipt
1.4.4.1.8 Complex_Desc_rsp
1.4.4.1.8.1 Semantics of the service primitive
1.4.4.1.8.2 When generated
1.4.4.1.8.3 Effect on receipt
1.4.4.1.9 User_Desc_rsp
1.4.4.1.9.1 Semantics of the service primitive
1.4.4.1.9.2 When generated
1.4.4.1.9.3 Effect on receipt
1.4.4.1.10 Discovery_Register_rsp
1.4.4.1.10.1 Semantics of the service primitive
1.4.4.1.10.2 When generated
1.4.4.1.10.3 Effect on receipt
1.4.4.1.11 User_Desc_conf
1.4.4.1.11.1 Semantics of the service primitive
1.4.4.1.11.2 When generated
1.4.4.1.11.3 Effect on receipt
1.4.4.2 End Device Bind, Bind and Unbind server services
1.4.4.2.1 End_Device_Bind_rsp
1.4.4.2.1.1 Semantics of the service primitive
1.4.4.2.1.2 When generated
1.4.4.2.1.3 Effect on receipt
1.4.4.2.2 Bind_rsp
1.4.4.2.2.1 Semantics of the service primitive
1.4.4.2.2.2 When generated
1.4.4.2.2.3 Effect on receipt
1.4.4.2.3 Unbind_rsp
1.4.4.2.3.1 Semantics of the service primitive
1.4.4.2.3.2 When generated
1.4.4.2.3.3 Effect on receipt
1.4.4.3 Network Management server services
1.4.4.3.1 Mgmt_NWK_Disc_rsp
1.4.4.3.1.1 Semantics of the service primitive
1.4.4.3.1.2 When generated
1.4.4.3.1.3 Effect on receipt
1.4.4.3.2 Mgmt_Lqi_rsp
1.4.4.3.2.1 Semantics of the service primitive
1.4.4.3.2.2 When generated
1.4.4.3.2.3 Effect on receipt
1.4.4.3.3 Mgmt_Rtg_rsp
1.4.4.3.3.1 Semantics of the service primitive
1.4.4.3.3.2 When generated
1.4.4.3.3.3 Effect on receipt
1.4.4.3.4 Mgmt_Bind_rsp
1.4.4.3.4.1 Semantics of the service primitive
1.4.4.3.4.2 When generated
1.4.4.3.4.3 Effect on receipt
1.4.4.3.5 Mgmt_Leave_rsp
1.4.4.3.5.1 Semantics of the service primitive
1.4.4.3.5.2 When generated
1.4.4.3.5.3 Effect on receipt
1.4.4.3.6 Mgmt_Direct_Join_rsp
1.4.4.3.6.1 Semantics of the service primitive
1.4.4.3.6.2 When generated
1.4.4.3.6.3 Effect on receipt
1.4.5 ZDP enumeration description
1.4.6 Conformance
1.5 The ZigBee device objects (ZDO)
1.5.1 Scope
1.5.2 Device Object Descriptions
1.5.2.1 Device and Service Discovery
1.5.2.2 Security Manager
1.5.2.3 Network Manager
1.5.2.4 Binding Manager
1.5.2.5 Node Manager
1.5.3 Layer Interface Description
1.5.4 System Usage
Figure 30 ZigBee Device Object details
1.5.5 Object Definition and Behavior
1.5.5.1 Object Overview
1.5.5.2 Optional and Mandatory Objects and Attributes
1.5.5.3 Security key usage
1.5.5.4 State Machine Functional Descriptions
1.5.5.4.1 ZigBee Coordinator
1.5.5.4.1.1 Initialization
1.5.5.4.1.2 Normal operating state
1.5.5.4.1.3 Trust center operation
1.5.5.4.2 ZigBee Router
1.5.5.4.2.1 Initialization
1.5.5.4.2.2 Normal operating state
1.5.5.4.3 ZigBee End Device
1.5.5.4.3.1 Initialization
1.5.5.4.3.2 Normal operating state
1.5.5.5 Device and Service Discovery
1.5.5.5.1 Optional and Mandatory Attributes within Device and Service Discovery
1.5.5.6 Security Manager
1.5.5.6.1 Optional and Mandatory Attributes within Security Manager
1.5.5.7 Binding Manager
1.5.5.7.1 Optional and Mandatory Attributes within Binding Manager
1.5.5.8 Network Manager
1.5.5.8.1 Optional and Mandatory Attributes within Network Manager
1.5.5.9 Node Manager
1.5.5.9.1 Optional and Mandatory Attributes within Node Manager
1.5.6 Configuration Attributes
1.5.6.1 Configuration Attribute Definitions
Chapter 2 Network Specification
2.1 NWK layer status values
2.2 General description
2.2.1 Network (NWK) layer overview
2.2.1.1 Network layer data entity (NLDE)
2.2.1.2 Network layer management entity (NLME)
2.3 Service specification
Figure 31 The NWK layer reference model
2.3.1 NWK data service
2.3.1.1 NLDE-DATA.request
2.3.1.1.1 Semantics of the service primitive
2.3.1.1.2 When generated
2.3.1.1.3 Effect on receipt
2.3.1.2 NLDE-DATA.confirm
2.3.1.2.1 Semantics of the service primitive
2.3.1.2.2 When generated
2.3.1.2.3 Effect on receipt
2.3.1.3 NLDE-DATA.indication
2.3.1.3.1 Semantics of the service primitive
2.3.1.3.2 When generated
2.3.1.3.3 Effect on receipt
2.3.1.3.4 NWK management service
2.3.2 Network discovery
2.3.2.1 NLME-NETWORK-DISCOVERY.request
2.3.2.1.1 Semantics of the service primitive
2.3.2.1.2 When generated
2.3.2.1.3 Effect on receipt
2.3.2.2 NLME-NETWORK-DISCOVERY.confirm
2.3.2.2.1 Semantics of the service primitive
2.3.2.2.2 When generated
2.3.2.2.3 Effect on receipt
2.3.3 Network formation
2.3.3.1 NLME-NETWORK-FORMATION.request
2.3.3.1.1 Semantics of the service primitive
2.3.3.1.2 When generated
2.3.3.1.3 Effect on receipt
2.3.3.2 NLME-NETWORK-FORMATION.confirm
2.3.3.2.1 Semantics of the service primitive
2.3.3.2.2 When generated
2.3.3.2.3 Effect on receipt
2.3.4 Allowing devices to join
2.3.4.1 NLME-PERMIT-JOINING.request
2.3.4.1.1 Semantics of the service primitive
2.3.4.1.2 When generated
2.3.4.1.3 Effect on receipt
2.3.4.2 NLME-PERMIT-JOINING.confirm
2.3.4.2.1 Semantics of the service primitive
2.3.4.2.2 When generated
2.3.4.2.3 Effect on receipt
2.3.5 Begin as a router
2.3.5.1 NLME-START-ROUTER.request
2.3.5.1.1 Semantics of the service primitive
2.3.5.1.2 When generated
2.3.5.1.3 Effect on receipt
2.3.5.2 NLME-START-ROUTER.confirm
2.3.5.2.1 Semantics of the service primitive
2.3.5.2.2 When generated
2.3.5.2.3 Effect on receipt
2.3.6 Joining a network
2.3.6.1 NLME-JOIN.request
2.3.6.1.1 Semantics of the service primitive
2.3.6.1.2 When generated
2.3.6.1.3 Effect on receipt
1) The router belongs to the network identified by the PANId parameter.
2) The router is open to join requests.
3) The link quality for frames received from this device is such that a link cost of at most 3 is pro duced when calculated as described in sub-clause 2.7.3.1.
2.3.6.2 NLME-JOIN.indication
2.3.6.2.1 Semantics of the service primitive
2.3.6.2.2 When generated
2.3.6.2.3 Effect on receipt
2.3.6.3 NLME-JOIN.confirm
2.3.6.3.1 Semantics of the service primitive
2.3.6.3.2 When generated
2.3.6.3.3 Effect on receipt
2.3.7 Joining a device directly to a network
2.3.7.1 NLME-DIRECT-JOIN.request
2.3.7.1.1 Semantics of the service primitive
Figure 32 Capability Information parameter format
2.3.7.1.2 When generated
2.3.7.1.3 Effect on receipt
2.3.7.2 NLME-DIRECT-JOIN.confirm
2.3.7.2.1 Semantics of the service primitive
2.3.7.2.2 When generated
2.3.7.2.3 Effect on receipt
2.3.8 Leaving a network
2.3.8.1 NLME-LEAVE.request
2.3.8.1.1 Semantics of the service primitive
2.3.8.1.2 When generated
2.3.8.1.3 Effect on receipt
2.3.8.2 NLME-LEAVE.indication
2.3.8.2.1 Semantics of the service primitive
2.3.8.2.2 When generated
2.3.8.2.3 Effect on receipt
2.3.8.3 NLME-LEAVE.confirm
2.3.8.3.1 Semantics of the service primitive
2.3.8.3.2 When generated
2.3.8.3.3 Effect on receipt
2.3.9 Resetting a device
2.3.9.1 NLME-RESET.request
2.3.9.1.1 Semantics of the service primitive
2.3.9.1.2 When generated
2.3.9.1.3 Effect on receipt
2.3.9.2 NLME-RESET.confirm
2.3.9.2.1 Semantics of the service primitive
2.3.9.2.2 When generated
2.3.9.2.3 Effect on receipt
2.3.9.3 Network layer reset message sequence chart
Figure 33 Message sequence chart for resetting the network layer
2.3.10 Receiver synchronization
2.3.10.1 NLME-SYNC.request
2.3.10.1.1 Semantics of the Service Primitive
2.3.10.1.2 When generated
2.3.10.1.3 Effect on receipt
2.3.10.2 NLME-SYNC.indication
2.3.10.2.1 Semantics of the service primitive
2.3.10.2.2 When generated
2.3.10.2.3 Effect on receipt
2.3.10.3 NLME-SYNC.confirm
2.3.10.3.1 Semantics of the Service Primitive
2.3.10.3.2 When generated
2.3.10.3.3 Effect on receipt
2.3.10.4 Message sequence charts for synchronizing with a coordinator
Figure 34 Message sequence chart for synchronizing in a non-beaconing network
Figure 35 Message sequence chart for synchronizing in a beacon-enabled network
2.3.11 Information base maintenance
2.3.11.1 NLME-GET.request
2.3.11.1.1 Semantics of the Service Primitive
2.3.11.1.2 When Generated
2.3.11.1.3 Effect on Receipt
2.3.11.2 NLME-GET.confirm
2.3.11.2.1 Semantics of the Service Primitive
2.3.11.2.2 When Generated
2.3.11.2.3 Effect on Receipt
2.3.11.3 NLME-SET.request
2.3.11.3.1 Semantics of the Service Primitive
2.3.11.3.2 When Generated
2.3.11.3.3 Effect on Receipt
2.3.11.4 NLME-SET.confirm
2.3.11.4.1 Semantics of the Service Primitive
2.3.11.4.2 When Generated
2.3.11.4.3 Effect on Receipt
2.4 Frame formats
2.4.1 General NPDU frame format
Figure 36 General NWK frame format
2.4.1.1 Frame control Field
Figure 37 Frame control field
2.4.1.1.1 Frame type sub-field
2.4.1.1.2 Protocol version sub-field
2.4.1.1.3 Discover route sub-field
2.4.1.1.4 Security sub-field
2.4.1.2 Destination address field
2.4.1.3 Source address field
2.4.1.4 Radius field
2.4.1.5 Sequence number field
2.4.1.6 Frame payload field
2.4.2 Format of individual frame types
2.4.2.1 Data frame format
Figure 38 Data frame format
2.4.2.1.1 Data frame NWK header field
2.4.2.1.2 Data payload field
2.4.2.2 NWK command frame format
Figure 39 NWK command frame format
2.4.2.2.1 NWK command frame NWK header field
2.4.2.2.2 NWK command identifier field
2.4.2.2.3 NWK command payload field
2.5 Command frames
2.5.1 Route request command
Figure 40 Route request command frame format
2.5.1.1 MAC data service requirements
2.5.1.2 NWK header fields
2.5.1.3 NWK payload fields
2.5.1.3.1 Command options field
Figure 41 Route request command options field
2.5.1.3.2 Route request identifier
2.5.1.3.3 Destination address
2.5.1.3.4 Path cost
2.5.2 Route reply command
Figure 42 Route reply command format
2.5.2.1 MAC data service requirements
2.5.2.2 NWK header fields
2.5.2.3 NWK payload fields
2.5.2.3.1 Command options field
Figure 43 Route reply command options field
2.5.2.3.2 Route request identifier
2.5.2.3.3 Originator address
2.5.2.3.4 Responder address
2.5.2.3.5 Path cost
2.5.3 Route error command
Figure 44 Route error command frame format
2.5.3.1 MAC data service requirements
2.5.3.2 NWK header fields
2.5.3.3 Error code
2.5.3.4 Destination address
2.5.4 Leave command
Figure 45 Leave command frame format
2.5.4.1 MAC data service requirement
2.5.4.2 NWK header fields
2.5.4.3 Command options
Figure 46 Leave command options field
2.5.4.3.1 Request/indication sub-field
2.5.4.3.2 Remove children sub-field
2.6 Constants and NIB attributes
2.6.1 NWK constants
2.6.2 NWK information base
2.7 Functional description
2.7.1 Network and device maintenance
2.7.1.1 Establishing a new network
Figure 47 Establishing a new network
2.7.1.2 Permitting devices to join a network
Figure 48 Permitting devices to join a network
2.7.1.3 Joining a network
2.7.1.3.1 Joining a network through association
2.7.1.3.1.1 Child procedure
Figure 49 Procedure for joining a network through association
2.7.1.3.1.2 Parent procedure
Figure 50 Procedure for handling a join request
2.7.1.3.2 Joining a network directly
Figure 51 Joining a device to a network directly
2.7.1.3.3 Joining or re-joining a network through orphaning
2.7.1.3.3.1 Child procedure
Figure 52 Child procedure for joining or re-joining a network through orphaning
2.7.1.3.3.2 Parent procedure
Figure 53 Parent procedure for joining or re-joining a device to its network through orphaning
2.7.1.3.4 Neighbor tables
2.7.1.4 Distributed address assignment mechanism
Figure 54 Address assignment in an example network
2.7.1.5 Higher-layer address assignment mechanism
2.7.1.6 Installation and addressing
2.7.1.7 Leaving a network
2.7.1.7.1 Method for a child to initiate its own removal from a network
1) The status returned by the initial MCPS-DATA.confirm above has a value of SUCCESS, and
2) If the NLME attempts to remove the children of the device in turn, then each of the children is successfully removed, and
3) The status returned by the MLME.DISASSOCIATE.confirm primitive, if any, is also SUC CESS.
2.7.1.7.2 Method for a parent to force a child to leave its network
1) The status value returned by the MLME-DATA.confirm resulting from the transmission of the leave command frame was SUCCESS, and
2) The leave command frame issued by the device's was received before the time-out, and
3) The recursive removal of children was not called for, or else recursive removal of children was called for and the remove children subfield of the command options field of the command frame payload of the received leave command frame above...
Figure 55 Sequence diagrams for NLME-LEAVE.request, various scenarios
Figure 56 Leave command, various scenarios
2.7.1.8 Changing the ZigBee coordinator configuration
2.7.1.9 Resetting a device
2.7.2 Transmission and reception
2.7.2.1 Transmission
2.7.2.2 Reception and rejection
2.7.3 Routing
2.7.3.1 Routing cost
where each of the values is referred to as a link cost. The link cost for a link is a function with values in the interval defined as: where is defined as the probability of packet delivery on the link .
2.7.3.2 Routing tables
2.7.3.3 Upon receipt of a data frame
.
Figure 57 Basic routing algorithm
2.7.3.4 Route discovery
2.7.3.4.1 Initiation of route discovery
2.7.3.4.2 Upon receipt of a route request command frame
Figure 58 Receipt of route request
2.7.3.4.3 Upon receipt of route reply command frame
Figure 59 Receipt of route reply
2.7.3.5 Route maintenance
2.7.3.5.1 Route repair for mesh network topology
2.7.3.5.2 Route repair for tree network topology
2.7.4 Scheduling beacon transmissions
2.7.4.1 Scheduling method
Figure 60 Typical frame structure for a beaconing device
Figure 61 Parent-child superframe positioning relationship
2.7.4.2 MAC enhancement
2.7.5 Broadcast communication
Figure 62 Broadcast transaction message sequence chart
2.7.6 NWK information in the MAC beacons
Figure 63 Format of the MAC sub-layer beacon payload
2.7.7 Persistent data
Chapter 3 Security Services Specification
3.1 Document Organization
3.2 General Description
3.2.1 Security Architecture and Design
3.2.1.1 Security Assumptions
3.2.1.2 Security Design Choices
3.2.1.3 Security Keys
3.2.1.4 ZigBee Security Architecture
3.2.2 MAC Layer Security
Figure 64 ZigBee frame with security at the MAC level
3.2.3 NWK Layer Security
Figure 65 ZigBee frame with security on the NWK level
3.2.4 APL Layer Security
Figure 66 ZigBee frame with security on the APS level
3.2.4.1 Key Establishment
3.2.4.2 Transport Key
3.2.4.3 Update Device
3.2.4.4 Remove Device
3.2.4.5 Request Key
3.2.4.6 Switch Key
3.2.5 Trust Center Role
3.3 MAC Layer Security
3.3.1 Frame Security
3.3.1.1 Security Processing of Outgoing Frames
1. Obtain the security material (as specified in sub-clause 3.3.2), including the key, outgoing frame counter FrameCount, key sequence count SeqCount, and security level identifier (as specified in Table 169) from the MAC PIB using the follow...
a) First, an attempt shall be made to retrieve the security material and security level identifier associ ated with the destination address of the outgoing frame from the macACLEntryDescriptorSet attribute in the MAC PIB.
b) If the first attempt fails, then security material shall be obtained by using the macDefaultSecurity Material attribute from the MAC PIB and the security level identifier shall be obtained from the MacDefaultSecuritySuite attribute from the MAC PIB.
2. The Security Control Field SecField is the 1-octet field formatted as in sub-clause 3.6.1.1, with the following settings:
a) The security level subfield shall be set to the security level obtained in Step 1 above;
b) The key identifier subfield shall be set to the 2-bit field '00';
c) The extended nonce subfield shall be set to the 1-bit field '0';
d) The reserved bits shall be set to the 2-bit field '00'.
3. Execute the CCM* mode encryption and authentication operation, as specified in Annex A, with the following instantiations:
a) The parameter M shall be obtained from Table 169 corresponding to the security level from step 1;
b) The bit string Key shall be the key obtained from step 1;
c) The nonce N shall be the 13-octet string constructed using the local device’s 64-bit extended address, SecField from Step 1, and FrameCount from step 1 (see Figure 72 from [B1]);
d) If the security level requires encryption, the octet string a shall be the string MacHeader and the octet string m shall be the string Payload. Otherwise, the octet string a shall be the string Mac Header || Payload and the octet string m ...
4. If the CCM* mode invoked in step 3 outputs ‘invalid’, security processing shall fail and no further security processing shall be done on this frame.
5. Let c be the output from step 4 above. If the security level requires encryption, the secured outgoing frame shall be MacHeader || FrameCount || SeqCount || c, otherwise the secured outgoing frame shall be MacHeader || FrameCount || SeqCou...
6. If the secured outgoing frame size is greater than aMaxPHYPacketSize (from [B1]), security processing shall fail and no further security processing shall be done on this frame.
7. The outgoing frame counter from step 1 shall be incremented by one and stored in the location from which the security material was obtained in step 1 (i.e., either the macDefaultSecurityMaterial attribute or the MacDefaultSecuritySuite attribute).
3.3.1.2 Security Processing of Incoming Frames
1. If ReceivedFrameCount has as value the 4-octet representation of the integer 232-1, security processing shall fail and no further security processing shall be done on this frame.
2. Obtain the security material (as specified in sub-clause 3.3.2), including the key, optional external frame counter FrameCount, optional key sequence count SeqCount, and security level identifier (as specified in Table 169) from the MAC PI...
a) First, an attempt shall be made to retrieve the security material and security level identifier associ ated with the source address of the incoming frame from the macACLEntryDescriptorSet attribute in the MAC PIB.
b) If the first attempt fails, then security material shall be obtained by using the macDefaultSecurity Material attribute from the MAC PIB and the security level identifier shall be obtained from the MacDefaultSecuritySuite attribute from the MAC PIB.
3. If FrameCount exists and if ReceivedFrameCount is less than FrameCount, security processing shall fail and no further security processing shall be done on this frame.
4. The Security Control Field SecField is the 1-octet field formatted as in Clause 7.1.1, Figure 18, with the following settings:
a) The security level subfield shall be set to the security level from the MACPIB (as specified in Table 29);
b) The key identifier subfield shall be set to the 2-bit field '00';
c) The extended nonce subfield shall be set to the 1-bit field '0';
d) The reserved bits shall be set to the 2-bit field '00'.
5. Execute the CCM* mode decryption and authentication checking operation, as specified in Annex A.3, with the following instantiations:
a) The parameter M shall be obtained from Table 169 corresponding to the security level from step 1;
b) The bit string Key shall be the key obtained from step 2;
c) The nonce N shall be the 13-octet string constructed using the 64-bit extended sender address, SecField from Step 4, and ReceivedFrameCount from step 1 (see Figure 72 from [B1]);The nonce N shall be formatted according to the endianness co...
d) Parse the octet string SecuredPayload as Payload1 || Payload2, where the right-most string Payload2 is an M-octet string. If this operation fails, security processing shall fail and no further security pro cessing shall be done on this frame;
e) If the security level requires encryption, the octet string a shall be the string MacHeader || Received FrameCount || ReceivedSeqCount and the octet string c shall be the string SecuredPayload. Other wise, the octet string a shall be the s...
6. Return the results of the CCM* operation:
a) If the CCM* mode invoked in step 5 outputs ‘invalid’, security processing shall fail and no fur ther security processing shall be done on this frame;
b) Let m be the output of step 5 above. If the security level requires encryption, set the octet string UnsecuredMacFrame to the string a || m. Otherwise, set the octet string UnsecuredMacFrame to the string a;
7. If the optional FrameCount (obtained in step 2) exists, set it to ReceivedFrameCount and update MAC PIB. UnsecuredMacFrame now represents the unsecured received MAC layer frame.
3.3.2 Security-Related MAC PIB Attributes
3.4 NWK Layer Security
3.4.1 Frame Security
3.4.1.1 Security Processing of Outgoing Frames
1. Obtain the nwkActiveKeySeqNumber from the NIB and use it to retrieve the active Network key key, outgoing frame counter OutgoingFrameCounter, and key sequence number KeySeqNumber from the nwkSecurityMaterialSet attribute in the NIB. Obtain...
2. Construct auxiliary header AuxiliaryHeader (see sub-clause 3.6.1):
a) The security control field shall be set as follows:
1) The security level sub-field shall be the security level obtained from step 1.
2) The key identifier sub-field shall be set to ‘01’ (i.e., the Network key).
3) The extended nonce sub-field shall be set to 1.
b) The source address field shall be set to the 64-bit extended address of the local device.
c) The frame counter field shall be set to the outgoing frame counter from step 1.
d) The key sequence number field shall be set to the sequence number from step 1.
3. Execute the CCM* mode encryption and authentication operation, as specified in Annex A, with the following instantiations:
a) The parameter M shall be obtained from Table 169 corresponding to the security level from step 1;
b) The bit string Key shall be the key obtained from step 1;
c) The nonce N shall be the 13-octet string constructed using the security control field from step 2a, the frame counter field from step 2c, and the source address field from step 2b (see sub-clause 3.6.2.2);
d) If the security level requires encryption, the octet string a shall be the string NwkHeader || Auxiliar yHeader and the octet string m shall be the string Payload. Otherwise, the octet string a shall be the string NwkHeader || AuxiliaryHea...
4. If the CCM* mode invoked in step 3 outputs ‘invalid’, security processing shall fail and no further security processing shall be done on this frame.
5. Let c be the output from step 3 above. If the security level requires encryption, the secured outgoing frame shall be NwkHeader || AuxiliaryHeader || c, otherwise the secured outgoing frame shall be NwkHeader || AuxiliaryHeader || Payload || c.
6. If the secured outgoing frame size is greater than aMaxMACFrameSize (see [B1]), security processing shall fail and no further security processing shall be done on this frame.
7. The outgoing frame counter from step 1 shall be incremented by one and stored in the OutgoingFrameCounter element of the network security material descriptor referenced by the nwkActiveKeySeqNumber in the NIB (i.e., the outgoing frame coun...
8. Over-write the security level subfield of the security control field by the 3-bit all-zero string '000'.
3.4.1.2 Security Processing of Incoming Frames
1. Determine the security level from the nwkSecurityLevel attribute from the NIB. Over-write the 3-bit security level subfield of the security control field of the AuxillaryHeader with this value. Determine the sequence number SequenceNumber,...
2. Obtain the appropriate security material (consisting of the key and other attributes) by matching SequenceNumber to the sequence number of any key in the nwkSecurityMaterialSet attribute in the NIB. If the security material cannot be obtai...
3. If there is an incoming frame count FrameCount corresponding to SenderAddress from the security material obtained in step 2 and if ReceivedFrameCount is less than FrameCount, security processing shall fail and no further security processin...
4. Execute the CCM* mode decryption and authentication checking operation, as specified in Annex A.3, with the following instantiations:
a) The parameter M shall obtained from Table 169 corresponding to the security level from step 1;
b) The bit string Key shall be the key obtained from step 2;
c) The nonce N shall be the 13-octet string constructed using the security control, the frame counter, and the source address fields from AuxiliaryHeader (see sub-clause 3.6.2.2). Note that the security level subfield of the security control ...
d) Parse the octet string SecuredPayload as Payload1 || Payload2, where the right-most string Payload2 is an M-octet string. If this operation fails, security processing shall fail and no further security pro cessing shall be done on this frame;
e) If the security level requires encryption, the octet string a shall be the string NwkHeader || Auxiliar yHeader and the octet string c shall be the string SecuredPayload. Otherwise, the octet string a shall be the string NwkHeader || Auxil...
5. Return the results of the CCM* operation:
a) If the CCM* mode invoked in step 4 outputs ‘invalid’, security processing shall fail and no further security processing shall be done on this frame;
b) Let m be the output of step 4 above. If the security level requires encryption, set the octet string UnsecuredNwkFrame to the string a || m. Otherwise, set the octet string UnsecuredNwkFrame to the string a;
6. Set FrameCount to (ReceivedFrameCount + 1) and store both FrameCount and SenderAddress in the NIB. UnsecuredNwkFrame now represents the unsecured received network frame and security processing shall succeed. So as to never cause the storag...
3.4.2 Secured NPDU Frame
Figure 67 Secured NWK layer frame format
3.4.3 Security-Related NIB Attributes
3.5 APS Layer Security
3.5.1 Frame Security
3.5.1.1 Security Processing of Outgoing Frames
1. Obtain the security material and key identifier KeyIdentifier using the following procedure. If security material or key identifier cannot be determined, then security processing shall fail and no further security processing shall be done ...
a) If the frame is a result of a APSDE-DATA.request primitive:
i) If the useNwkKeyFlag parameter is TRUE, then security material shall be obtained by using the nwkActiveKeySeqNumber from the NIB to retrieve the active Network key, out going frame counter, and sequence number from the nwkSecurityMaterialS...
ii) Otherwise, the security material associated with the destination address of the outgoing frame shall be obtained from the apsDeviceKeyPairSet attribute in the AIB. KeyIdentifier shall be set to ‘00’ (i.e., a data key). Note, if the frame ...
b) If the frame is a result of an APS command:
i) First, an attempt shall be made to retrieve the security material associated with the destina tion address of the outgoing frame from the apsDeviceKeyPairSet attribute in the AIB. For all cases, except transport-key commands, KeyIdentifier...
ii) If the first attempt fails, then security material shall be obtained by using the nwkAc tiveKeySeqNumber from the NIB to retrieve the active Network key, outgoing frame counter, and sequence number from the nwkSecurityMaterialSet attribut...
2. If the key identifier is equal to 01 (i.e. network key), the APS layer shall first verify that the NWK layer is not also applying security. If the NWK layer is applying security, then the APS layer shall not apply any security. The APS lay...
3. Extract the outgoing frame counter (and, if KeyIdentifier is 01, the key sequence number) from the security material obtained from step 1. If the outgoing frame counter has as its value the 4-octet representation of the integer 232-1, or i...
4. Obtain the security level from the nwkSecurityLevel attribute from the NIB. If the frame is a result of an APS command, the security level shall be forced to 7 (ENC-MIC-128).
5. Construct auxiliary header AuxiliaryHeader (see sub-clause 3.6.1):
a) The security control field shall be set as follows:
i) The security level sub-field shall be the security level obtained from step 3.
ii) The key identifier sub-field shall be set to KeyIdentifier.
iii) The extended nonce sub-field shall be set to 0.
b) The frame counter field shall be set to the outgoing frame counter from step 2.
c) If KeyIdentifier is 1, the key sequence number field shall be present and set to the key sequence number from step 2. Otherwise, the key sequence number field shall not be present.
6. Execute the CCM* mode encryption and authentication operation, as specified in Annex A.2, with the following instantiations:
a) The parameter M shall obtained from Table 169 corresponding to the security level from step 3;
b) The bit string Key shall be the key obtained from step 1;
c) The nonce N shall be the 13-octet string constructed using the security control and frame counter fields from step 4 and the 64-bit extended address of the local device (see sub-clause 3.6.2.2);
d) If the security level requires encryption, the octet string a shall be the string ApsHeader || Auxiliary Header and the octet string m shall be the string Payload. Otherwise, the octet string a shall be the string ApsHeader || AuxiliaryHea...
7. If the CCM* mode invoked in step 3 outputs ‘invalid’, security processing shall fail and no further security processing shall be done on this frame.
8. Let c be the output from step 3 above. If the security level requires encryption, the secured outgoing frame shall be ApsHeader || AuxiliaryHeader || c, otherwise the secured outgoing frame shall be ApsHeader || AuxiliaryHeader || Payload || c.
9. If the secured outgoing frame size will result in the MSDU being greater than aMaxMACFrameSize octets (see [B1]), security processing shall fail and no further security processing shall be done on this frame.
10. The outgoing frame counter from step 1 shall be incremented and stored in the appropriate location(s) of the NIB, AIB, and MAC PIB corresponding to the key that was used to protect the outgoing frame.
11. Over-write the security level subfield of the security control field by the 3-bit all-zero string '000'.
3.5.1.2 Security Processing of Incoming Frames
1. Determine the sequence number SequenceNumber, key identifier KeyIdentifier, and received frame counter value ReceivedFrameCounter from the auxiliary header AuxiliaryHeader. If ReceivedFrameCounter is the 4-octet representation of the integ...
2. Determine the source address SourceAddress from the address-map table in the AIB, using the source address in the APS frame as the index. If the source address is incomplete or unavailable, security processing shall fail and no further sec...
3. Obtain the appropriate security material in the following manner. If the security material cannot be obtained, security processing shall fail and no further security processing shall be done on this frame.
a) If KeyIdentifier is ‘00’ (i.e., data key), the security material associated with the SourceAddress of the incoming frame shall be obtained from the apsDeviceKeyPairSet attribute in the AIB.
b) If KeyIdentifier is ‘01’ (i.e., Network key), the security material shall be obtained by matching SequenceNumber to the sequence number to the sequence number of any key in the nwkSecurity MaterialSet attribute in the NIB. If the sequence ...
c) If KeyIdentifier is ‘02’ (i.e., key-transport key), the security material associated with the SourceAd dress of the incoming frame shall be obtained from the apsDeviceKeyPairSet attribute in the AIB and the key for this operation shall be ...
d) If KeyIdentifier is ‘03’ (i.e., key-load key), the security material associated with the SourceAddress of the incoming frame shall be obtained from the apsDeviceKeyPairSet attribute in the AIB and the key for this operation shall be derive...
4. If there is an incoming frame count FrameCount corresponding to SourceAddress from the security material obtained in step 3 and if ReceivedFrameCount is less than FrameCount, security processing shall fail and no further security processin...
5. Determine the security level SecLevel as follows. If the frame type subfield of the frame control field of ApsHeader indicates an APS data frame, then SecLevel shall be set to the nwkSecurityLevel attribute in the NIB. Otherwise SecLevel s...
6. Execute the CCM* mode decryption and authentication checking operation, as specified in Annex A.3, with the following instantiations:
a) The parameter M shall obtained from Table 169 corresponding to the security level from step 5;
b) The bit string Key shall be the key obtained from step 3;
c) The nonce N shall be the 13-octet string constructed using the security control and frame counter fields from AuxiliaryHeader, and SourceAddress from step 2 (see sub-clause 3.6.2.2);
d) Parse the octet string SecuredPayload as Payload1 || Payload2, where the right-most string Payload2 is an M-octet string. If this operation fails, security processing shall fail and no further security pro cessing shall be done on this frame;
e) If the security level requires encryption, the octet string a shall be the string ApsHeader || Auxiliary Header and the octet string c shall be the string SecuredPayload. Otherwise, the octet string a shall be the string ApsHeader || Auxil...
7. Return the results of the CCM* operation:
a) If the CCM* mode invoked in step 4 outputs ‘invalid’, security processing shall fail and no further security processing shall be done on this frame;
b) Let m be the output of step 4 above. If the security level requires encryption, set the octet string UnsecuredApsFrame to the string a || m. Otherwise, set the octet string UnsecuredApsFrame to the string a;
8. Set FrameCount to (ReceivedFrameCount + 1) and store both FrameCount and SourceAddress in the appropriate security material as obtained in step 3. If storing this frame count and address information will cause the memory allocation for thi...
3.5.2 Key-Establishment Services
3.5.2.1 APSME-ESTABLISH-KEY.request
3.5.2.1.1 Semantics of the service primitive
3.5.2.1.2 When generated
3.5.2.1.3 Effect on receipt
3.5.2.2 APSME-ESTABLISH-KEY.confirm
3.5.2.2.1 Semantics of the service primitive
3.5.2.2.2 When generated
3.5.2.2.3 Effect on receipt
3.5.2.3 APSME-ESTABLISH-KEY.indication
3.5.2.3.1 Semantics of the service primitive
3.5.2.3.2 When generated
3.5.2.3.3 Effect on receipt
3.5.2.4 APSME-ESTABLISH-KEY.response
3.5.2.4.1 Semantics of the service primitive
3.5.2.4.2 When generated
3.5.2.4.3 Effect on receipt
3.5.2.5 Data Service Message Sequence Chart
Figure 68 Sequence chart for successful APSME-ESTABLISH-KEY primitives
3.5.2.6 The SKKE Protocol
3.5.2.6.1 Generating and sending the initial SKKE-1 frame
3.5.2.6.2 On receipt of the SKKE-1 frame
1. If the device given by the responder address field is not a child of the local device, the SKKE-1 frame shall be discarded.
2. Otherwise, the APSME of the local device shall send the SKKE-1 frame to the responder device using the NLDE-DATA.request primitive, with the DestAddr parameter set to the 16-bit address corresponding to the 64-bit address in the responder ...
3. Otherwise, the APSME shall perform the following steps:
4. If the device does not have a master key corresponding to the initiator address field, the SKKE-1 frame shall be discarded and the APSME-ESTABLISH-KEY.confirm primitive shall be issued with the Status parameter set to NO_MASTER_KEY (see Ta...
5. Otherwise, the APSME shall issue an APSME-ESTABLISH-KEY.indication primitive with the InitiatorAddress parameter set to the initiator address field of the SKKE-1 frame and the KeyEstablishmentMethod parameter set to 0 (i.e., the SKKE protocol).
6. After issuing the APSME-ESTABLISH-KEY.indication primitive, and upon receipt of the corresponding APSME-ESTABLISH-KEY.response primitive, the APSME shall evaluate the InitiatorAddress and Accept parameters of the received APSME-ESTABLISH-K...
7. Otherwise, it shall construct an SKKE-2 frame as specified in sub-clause 3.5.9.1. If the source of the SKKE-1 frame indicates the same device as the initiator address field of the SKKE-1 frame, the device shall send this SKKE-2 frame direc...
3.5.2.6.3 On receipt of the SKKE-2 frame
1. If the device given by the responder address field is not a child of the local device, the SKKE-2 frame shall be discarded.
2. Otherwise, the device shall send the SKKE-2 to the initiator device using the NLDE-DATA.request primitive with NWK layer set to the default level.
3.5.2.6.4 On receipt of the SKKE-3 frame
1. If the device given by the responder address field is not a child of the local device, the SKKE-3 frame shall be discarded.
2. Otherwise, the device shall send the SKKE-3 to the responder device using the NLDE-DATA.request primitive with NWK layer security disabled.
3.5.2.6.5 On receipt of the SKKE-4 frame
1. If the device given by the responder address field is not a child of the local device, the SKKE-4 frame shall be discarded.
2. Otherwise, the APSME of the local device shall send the SKKE-4 to the initiator device using the NLDE-DATA.request primitive with NWK layer set to the default level.
3.5.3 Transport-Key Services
3.5.3.1 APSME-TRANSPORT-KEY.request
3.5.3.1.1 Semantics of the service primitive
3.5.3.1.2 When generated
3.5.3.1.3 Effect on receipt
3.5.3.2 APSME-TRANSPORT-KEY.indication
3.5.3.2.1 Semantics of the service primitive
3.5.3.2.2 When generated
3.5.3.2.3 Effect on receipt
3.5.3.3 Upon Receipt of a Transport-Key Command
3.5.4 Update-Device Services
3.5.4.1 APSME-UPDATE-DEVICE.request
3.5.4.1.1 Semantics of the service primitive
3.5.4.1.2 When generated
3.5.4.1.3 Effect on receipt
3.5.4.2 APSME-UPDATE-DEVICE.indication
3.5.4.2.1 Semantics of the service primitive
3.5.4.2.2 When generated
3.5.4.2.3 Effect on receipt
3.5.5 Remove Device Services
3.5.5.1 APSME-REMOVE-DEVICE.request
3.5.5.1.1 Semantics of the service primitive
3.5.5.1.2 When generated
3.5.5.1.3 Effect on receipt
3.5.5.2 APSME-REMOVE-DEVICE.indication
3.5.5.2.1 Semantics of the service primitive
3.5.5.2.2 When generated
3.5.5.2.3 Effect on receipt
3.5.6 Request Key Services
3.5.6.1 APSME-REQUEST-KEY.request
3.5.6.1.1 Semantics of the service primitive
3.5.6.1.2 When generated
3.5.6.1.3 Effect on receipt
3.5.6.2 APSME-REQUEST-KEY.indication
3.5.6.2.1 Semantics of the service primitive
3.5.6.2.2 When generated
3.5.6.2.3 Effect on receipt
3.5.7 Switch Key Services
3.5.7.1 APSME-SWITCH-KEY.request
3.5.7.1.1 Semantics of the service primitive
3.5.7.1.2 When generated
3.5.7.1.3 Effect on receipt
3.5.7.2 APSME-SWITCH-KEY.indication
3.5.7.2.1 Semantics of the service primitive
3.5.7.2.2 When generated
3.5.7.2.3 Effect on receipt
3.5.8 Secured APDU Frame
Figure 69 Secured APS layer frame format
3.5.9 Command Frames
3.5.9.1 Key-Establishment Commands
Figure 70 Generic SKKE frame command format
3.5.9.1.1 Command identifier field
3.5.9.1.2 Initiator address field
3.5.9.1.3 Responder address field
3.5.9.1.4 Data field
3.5.9.1.4.1 SKKE-1 frame
3.5.9.1.4.2 SKKE-2 frame
3.5.9.1.4.3 SKKE-3 frame
3.5.9.1.4.4 SKKE-4 frame
3.5.9.2 Transport-Key Commands
Figure 71 Transport-key command frame
3.5.9.3 Command identifier field
3.5.9.3.1 Key type field
3.5.9.3.2 Key descriptor field
3.5.9.3.2.1 Trust center master key descriptor field
Figure 72 Trust center master key descriptor field in transport-key command
3.5.9.3.2.2 Network key descriptor field
Figure 73 Network key descriptor field in transport-key command
3.5.9.3.2.3 Application master and link key descriptor field
Figure 74 Application master key descriptor in transport-key command
3.5.9.4 Update-Device Commands
Figure 75 Update-device command frame format
3.5.9.4.1 Command identifier field
3.5.9.4.2 Device address field
3.5.9.4.3 Device short address field
3.5.9.4.4 Status field
3.5.9.5 Remove Device Commands
Figure 76 Remove-device command frame format
3.5.9.5.1 Command identifier field
3.5.9.5.2 Child address field
3.5.9.6 Request-Key Commands
Figure 77 Request-key command frame format
3.5.9.6.1 Command identifier field
3.5.9.6.2 Key type field
3.5.9.6.3 Partner address field
3.5.9.7 Switch-Key Commands
Figure 78 Switch-key command frame format
3.5.9.7.1 Command identifier field
3.5.9.7.2 Sequence number field
3.5.10 Security-Related AIB Attributes
3.6 Common Security Elements
3.6.1 Auxiliary Frame Header Format
Figure 79 Auxiliary frame header format
3.6.1.1 Security Control Field
Figure 80 Security control field format
3.6.1.1.1 Security level sub-field
3.6.1.1.2 Key identifier sub-field
3.6.1.1.3 Extended nonce sub-field
3.6.1.2 Source Address Field
3.6.1.3 Counter Field
3.6.1.4 Key Sequence Number Field
3.6.2 Security Parameters
3.6.2.1 CCM* Mode of Operation and Parameters
3.6.2.2 CCM* Nonce
Figure 81 CCM* nonce
3.6.3 Cryptographic Key Hierarchy
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.
3.6.4 Implementation Guidelines (Informative)
3.6.4.1 Random Number Generator
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.
3.6.4.2 Security Implementation
3.6.4.3 Conformance
3.7 Functional Description
3.7.1 ZigBee Coordinator
3.7.2 Trust Center Application
3.7.2.1 Commercial Mode
3.7.2.2 Residential Mode
3.7.3 Security Procedures
3.7.3.1 Joining a Secured Network
Figure 82 Example of joining a secured network
3.7.3.2 Authentication
3.7.3.2.1 Router operation
3.7.3.2.2 Trust center operation
3.7.3.2.2.1 Residential mode
3.7.3.2.2.2 Commercial mode
3.7.3.2.3 Joining device operation
3.7.3.2.3.1 Preconfigured Network key
3.7.3.2.3.2 Preconfigured trust center key
3.7.3.2.3.3 Not preconfigured
3.7.3.2.4 Message sequence charts
Figure 83 Example residential-mode authentication procedure
Figure 84 Example commercial-mode authentication procedure
3.7.3.3 Network Key Update
3.7.3.3.1 Trust center operation
3.7.3.3.2 Network device operation
3.7.3.3.3 Message sequence chart
Figure 85 Example Network key-update procedure
3.7.3.4 Network Key Recovery
3.7.3.4.1 Network device operation
3.7.3.4.2 Trust Center operation
3.7.3.4.3 Message sequence chart
Figure 86 Example Network key-recovery procedure
3.7.3.5 End-to-End Application Key Establishment
3.7.3.5.1 Device operation
3.7.3.5.1.1 Upon receipt of link key
3.7.3.5.1.2 Upon receipt of a master key
3.7.3.5.2 Trust center operation
3.7.3.5.3 Message sequence chart
Figure 87 Example end-to-end application key establishment procedure
3.7.3.6 Network Leave
3.7.3.6.1 Trust center operation
3.7.3.6.2 Router operation
3.7.3.6.3 Leaving device operation
3.7.3.6.4 Message sequence charts
Figure 88 Example remove-device procedure
Figure 89 Example device-leave procedure
Annex A CCM* Mode of Operation
1. A block-cipher encryption function E shall have been chosen, with a 128-bit block size. The length in bits of the keys used by the chosen encryption function is denoted by keylen.
2. A fixed representation of octets as binary strings shall have been chosen (e.g., most-significant-bit first order or least-significant-bit-first order).
3. The length L of the message length field, in octets, shall have been chosen. Valid values for L are the integers 2, 3,..., 8 (the value L=1 is reserved).
4. The length M of the authentication field, in octets, shall have been chosen. Valid values for M are the integers 0, 4, 6, 8, 10, 12, 14, and 16. (The value M=0 corresponds to disabling authenticity, since then the authentication field is t...
A.1 Notation and representation
A.2 CCM* mode encryption and authentication transformation
1. A bit string Key of length keylen bits to be used as the key. Each entity shall have evidence that access to this key is restricted to the entity itself and its intended key sharing group member(s).
2. A nonce N of 15-L octets. Within the scope of any encryption key Key, the nonce value shall be unique.
3. An octet string m of length l(m) octets, where 0 £ l(m) < 28L.
4. An octet string a of length l(a) octets, where 0 £ l(a) < 264.
A.2.1 Input transformation
1. Form the octet string representation L(a) of the length l(a) of the octet string a, as follows:
a) If l(a)=0, then L(a) is the empty string.
b) If 0 < l(a) < 216-28, then L(a) is the 2-octets encoding of l(a).
c) If 216-28 £ l(a) < 232, then L(a) is the right-concatenation of the octet 0xff, the octet 0xfe, and the 4- octets encoding of l(a).
d) If 232 £ l(a) < 264, then L(a) is the right-concatenation of the octet 0xff, the octet 0xff, and the 8- octets encoding of l(a).
2. Right-concatenate the octet string L(a) with the octet string a itself. Note that the resulting string contains l(a) and a encoded in a reversible manner.
3. Form the padded message AddAuthData by right-concatenating the resulting string with the smallest non-negative number of all-zero octets such that the octet string AddAuthData has length divisible by 16.
4. Form the padded message PlaintextData by right-concatenating the octet string m with the smallest non-negative number of all-zero octets such that the octet string PlaintextData has length divisible by 16.
5. Form the message AuthData consisting of the octet strings AddAuthData and PlaintextData:
AuthData = AddAuthData || PlaintextData. (1)
A.2.2 Authentication transformation
1. Form the 1-octet Flags field consisting of the 1-bit Reserved field, the 1-bit Adata field, and the 3-bit representations of the integers M and L, as follows:
Flags = Reserved || Adata || M || L. (2)
2. Form the 16-octet B0 field consisting of the 1-octet Flags field defined above, the 15-L octet nonce field N, and the L-octet representation of the length field l(m), as follows:
3. Parse the message AuthData as B1 || B2 || ... ||Bt, where each message block Bi is a 16-octet string.
X0 := 0128; Xi+1 := E(Key, Xi Å Bi ) for i=0, ... , t. (3)
A.2.3 Encryption transformation
1. Form the 1-octet Flags field consisting of two 1-bit Reserved fields, and the 3-bit representations of the integers 0 and L, as follows:
Flags = Reserved || Reserved || 0 || L. (4)
Ai = Flags || Nonce N || Counter i, for i=0, 1, 2, … (5)
Ci := E( Key, Ai ) Å Mi for i=1, 2, ... , t. (6)
S0:= E( Key, A0 ). (7)
2. The encrypted authentication tag U is the result of XOR-ing the string consisting of the leftmost M octets of S0 and the authentication tag T.
A.3 CCM* mode decryption and authentication checking transformation
1. A bit string Key of length keylen bits to be used as the key. Each entity shall have evidence that access to this key is restricted to the entity itself and its intended key-sharing group member(s).
2. A nonce N of 15-L octets. Within the scope of any encryption key Key, the nonce value shall be unique.
3. An octet string c of length l(c) octets, where 0 £ l(c)-M < 28L.
4. An octet string a of length l(a) octets, where 0 £ l(a) < 264.
A.3.1 Decryption transformation
1. Parse the message c as C ||U, where the right-most string U is an M-octet string. If this operation fails, output ‘invalid’ and stop. U is the purported encrypted authentication tag. Note that the leftmost string C has length l(c)-M octets.
2. Form the padded message CiphertextData by right-concatenating the string C with the smallest non- negative number of all-zero octets such that the octet string CiphertextData has length divisible by 16.
3. Use the encryption transformation in sub-clause A.2.3, with as inputs the data CipherTextData and the tag U.
4. Parse the output string resulting from applying this transformation as m || T, where the right-most string T is an M-octet string. T is the purported authentication tag. Note that the leftmost string m has length l(c)-M octets.
A.3.2 Authentication checking transformation
1. Form the message AuthData using the input transformation in sub-clause A.2.1, with as inputs the string a and the octet string m that was established in sub-clause A.3.1 (step 4).
2. Use the authentication transformation in sub-clause A.2.2, with as input the message AuthData.
3. Compare the output tag MACTag resulting from this transformation with the tag T that was established in sub-clause A.3.1 (step 4). If MACTag=T, output ‘valid’; otherwise, output ‘invalid’ and stop.
A.4 Restrictions
Annex B Security Building Blocks
B.1 Symmetric-key cryptographic building blocks
B.1.1 Block-cipher
B.1.2 Mode of operation
1. Each entity shall use the block-cipher E as specified in sub-clause B.1.1;
2. All octets shall be represented as specified in section "Preface";
3. The parameter L shall have the integer value 2;
4. The parameter M shall have one of the following integer values: 0, 4, 8, or 16.
B.1.3 Cryptographic hash function
1. Each entity shall use the block-cipher E as specified in section sub-clause B.1.1;
2. All integers and octets shall be represented as specified in section "Preface".
B.1.4 Keyed hash function for message authentication
1. Each entity shall use the cryptographic hash H function as specified in sub-clause B.1.3;
2. The block size B shall have the integer value 16 (this block size specifies the length of the data integrity key, in bytes, that is used by the keyed hash function, i.e., it uses a 128-bit data integrity key);
3. The output size HMAClen of the HMAC function shall have the same integer value as the message digest parameter hashlen as specified in sub-clause B.1.3.
B.1.5 Specialized keyed hash function for message authentication
B.1.6 Challenge domain parameters
B.2 Key Agreement Schemes
B.2.1 Symmetric-key key agreement scheme
1. Each entity shall be identified as specified in "Preface";
2. Each entity shall use the HMAC-scheme as specified in sub-clause B.1.4;
3. Each entity shall use the specialized HMAC-scheme as specified in sub-clause B.1.5;
4. Each entity shall use the cryptographic hash function as specified in sub-clause B.1.3.,
5. The parameter keydatalen shall have the same integer value as the key size parameter keylen as specified in sub-clause B.1.1;
6. The parameter SharedData shall be the empty string; parameter shareddatalen shall have the integer value 0;
7. The optional parameters Text1 and Text2 as specified in sub-clause B.7.1 and sub-clause B.7.2 shall both be the empty string.
8. Each entity shall use the challenge domain parameters as specified in sub-clause B.1.6.
9. All octets shall be represented as specified in section "Preface".
B.3 Challenge Domain Parameter Generation and Validation
B.3.1 Challenge Domain Parameter Generation
1. Choose two nonnegative integers minchallengelen and maxchallengelen, such that minchallengelen £ maxchallengelen.
B.3.2 Challenge Domain Parameter Verification
1. Check that minchallengelen and maxchallengelen are nonnegative integers.
2. Check that minchallengelen £ maxchallengelen.
B.4 Challenge Validation Primitive
1. Compute the bit-length challengelen of the bit string Challenge.
2. Verify that challengelen Π[minchallengelen, maxchallengelen]. (That is, verify that the challenge has an appropriate length.)
B.5 Secret Key Generation (SKG) Primitive
1. Each entity shall be bound to a unique identifier (e.g., distinguished names). All identifiers shall be bit strings of the same length entlen bits. Entity U1’s identifier will be denoted by the bit string U1. Entity U2’s identifier will be...
2. A specialized MAC scheme shall have been chosen, with tagging transformation as specified in Section 5.7.1 of ANSI X9.63-2001 [B7]. The length in bits of the keys used by the specialized MAC scheme is denoted by mackeylen.
1. A bit string MACKey of length mackeylen bits to be used as the key of the established specialized MAC scheme.
2. A bit string QEU1 owned by U1.
3. A bit string QEU2 owned by U2.
1. Form the bit string consisting of U1’s identifier, U2’s identifier, the bit string QEU1 corresponding to U1’s challenge, and the bit string QEU2 corresponding to QEU2’s challenge:
MacData = U1 || U2 || QEU1 || QEU2. (8)
2. Calculate the tag MacTag for MacData under the key MacKey using the tagging transformation of the established specialized MAC scheme:
MacTag = MACMacKey(MacData). (9)
3. If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop.
4. Set Z=MacTag.
B.6 Block-Cipher-Based Cryptographic Hash Function
1. A block-cipher encryption function E shall have been chosen, with a key size that is equal to the block size. The Matyas-Meyer-Oseas hash function has a message digest size that is equal to the block size of the established encryption func...
2. A fixed representation of integers as binary strings or octet strings shall have been chosen.
1. A bit string M of length l bits, where 0£ l < 2n.
1. Pad the message M according to the following method:
a) Right-concatenate to the message M the binary consisting of the bit ‘1’ followed by k ‘0’ bits, where k is the smallest non-negative solution to the equation
l+1+k º 7n (mod 8n). (10)
b) Form the padded message M’ by right-concatenating to the resulting string the n-bit string that is equal to the binary representation of the integer l.
2. Parse the padded message M’ as M1 || M2|| … || Mt where each message block Mi is an n-octet string.
3. The output Hasht is defined by
Hash0 =08n; Hashj =E(Hashj-1, Mj) Å Mj for j=1,…,t. (11)
B.7 Symmetric-Key Authenticated Key Agreement Scheme
Figure 90 Symmetric-Key Authenticated Key Agreement Scheme
1. Each entity has an authentic copy of the system’s challenge domain parameters D=(minchallengelen, maxchallengelen).
2. Each entity shall have access to a bit string Key of length keylen bits to be used as the key. Each party shall have evidence that access to this key is restricted to the entity itself and the other entity involved in the symmetric-key aut...
3. Each entity shall be bound to a unique identifier (e.g., distinguished names). All identifiers shall be bit strings of the same length entlen bits. Entity U’s identifier will be denoted by the bit string U. Entity V’s identifier will be de...
4. Each entity shall have decided which MAC scheme to use as specified in Section 5.7 of ANSI X9.63- 2001 [B7]. The length in bits of the keys used by the chosen MAC scheme is denoted by mackeylen.
5. A cryptographic hash function shall have been chosen for use with the key derivation function.
6. A specialized MAC scheme shall have been chosen for use with the secret key generation primitive with tagging transformation as specified in Section 5.7.1 of ANSI X9.63-2001 [B7]. The length in bits of the keys used by the specialized MAC ...
7. A fixed representation of octets as binary strings shall have been chosen. (e.g., most-significant-bit-first order or least-significant-bit-first order).
B.7.1 Initiator Transformation
1. An integer keydatalen that is the length in bits of the keying data to be generated.
2. (Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.
1. Use the challenge generation primitive in Section 5.3 of ANSI X9.63-2001 [B7] to generate a challenge QEU for the challenge domain parameters D. Send QEU to V.
2. Then receive from V a challenge QEV’ purportedly owned by V. If this value is not received, output ‘invalid’ and stop.
3. Receive from V an optional bit string Text1, and a purported tag MacTag1’. If these values are not received, output ‘invalid’ and stop.
4. Verify that QEV’ is a valid challenge for the challenge domain parameters D as specified in section sub- clause B.3.2. If the validation primitive rejects the challenge, output ‘invalid’ and stop.
5. Use the SKG primitive in clause B.5 to derive a shared secret bit string Z from the challenges Q1=QEU owned by U and Q2=QEV’ owned by V, using as key the shared key Key. If the SKG primitive outputs ‘invalid’, output ‘invalid’ and stop.
6. Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] with the established hash function to derive keying data KKeyData of length mackeylen+keydatalen bits from the shared secret value Z and the shared data [SharedData].
7. Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the remaining bits as keying data KeyData.
8. Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the bit string QEV’, the bit string QEU, and if present Text1:
MacData1 = 0216 || V || U || QEV’ || QEU || [Text1]. (12)
9. Verify that MacTag1’ is the tag for MacData1 under the key MacKey using the tag checking transformation of the appropriate MAC scheme specified in Section 5.7.2 of ANSI X9.63-2001 [B7]. If the tag checking transformation outputs ‘invalid’,...
10. Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the bit string QEU corresponding to U’s challenge, the bit string QEV’ corresponding to V’s challenge, and optionally a bit string Text2:
MacData2 = 0316 || U || V || QEU || QEV’ || [Text2]. (13)
11. Calculate the tag MacTag2 on MacData2 under the key MacKey using the tagging transformation of the appropriate MAC scheme specified in Section 5.7.1 of ANSI X9.63-2001 [B7]:
MacTag2 = MACMacKey(MacData2). (14)
12. If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send MacTag2 and, if present, Text2 to V.
B.7.2 Responder Transformation
1. A challenge QEU’ purportedly owned by U.
2. An integer keydatalen that is the length in bits of the keying data to be generated.
3. (Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.
4. (Optional) A bit string Text1 that consists of some additional data to be provided from V to U.
1. Verify that QEU’ is a valid challenge for the challenge domain parameters D as specified in sub- clause B.3.2. If the validation primitive rejects the challenge, output ‘invalid’ and stop.
2. Use the challenge generation primitive in Section 5.3 of ANSI X9.63-2001 [B7] to generate a challenge QEV for the challenge domain parameters D. Send to U the challenge QEV.
3. Use the SKG primitive in clause B.5 to derive a shared secret bit string Z from the challenges Q1=QEU’ owned by U and Q2=QEV owned by V, using as key the shared key Key. If the SKG primitive outputs ‘invalid’, output ‘invalid’ and stop.
4. Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] with the established hash function to derive keying data KKeyData of length mackeylen+keydatalen bits from the shared secret value Z and the shared data [SharedData].
5. Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the remaining bits as keying data KeyData.
6. Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the bit string QEV, the bit string QEU’, and, optionally, a bit string Text1:
MacData1 = 0216 || V || U || QEV || QEU’ || [Text1]. (15)
7. Calculate the tag MacTag1 for MacData1 under the key MacKey using the tagging transformation of the appropriate MAC scheme specified in Section 5.7 of ANSI X9.63-2001 [B7]:
MacTag1 = MACMacKey(MacData1). (16)
8. Then receive from U an optional bit string Text2 and a purported tag MacTag2’. If this data is not received, output ‘invalid’ and stop.
9. Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the bit string QEU’ corresponding to U’s purported challenge, the bit string QEV corresponding to V’s challenge, and the bit string Text2 (if present):
MacData2 = 0316 || U || V || QEU’ || QEV || [Text2]. (17)
10. Verify that MacTag2’ is the valid tag on MacData2 under the key MacKey using the tag checking transformation of the appropriate MAC scheme specified in Section 5.7 ANSI X9.63-2001 [B7]. If the tag checking transformation outputs ‘invalid’...
Annex C Test Vectors for Cryptographic Building Blocks
C.1 Data Conversions
C.2 AES Block Cipher
C.3 CCM* Mode Encryption and Authentication Transformation
1. The parameter M shall have the integer value 8.
1. The key Key of size keylen=128 bits to be used:
Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF. (18)
2. The nonce N of 15-L=13 octets to be used:
Nonce = A0 A1 A2 A3 A4 A5 A6 A7 || 03 02 01 00 || 06. (19)
3. The octet string m of length l(m)=23 octets to be used:
m = 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E. (20)
4. The octet string a of length l(a)=8 octets to be used:
a = 00 01 02 03 04 05 06 07. (21)
C.3.1 Input Transformation
1. Form the octet string representation L(a) of the length l(a) of the octet string a:
2. Right-concatenate the octet string L(a) and the octet string a itself:
3. Form the padded message AddAuthData by right-concatenating the resulting string with the smallest non-negative number of all-zero octets such that the octet string AddAuthData has length divisible by 16:
4. Form the padded message PlaintextData by right-concatenating the octet string m with the smallest non-negative number of all-zero octets such that the octet string PlaintextData has length divisible by 16:
5. Form the message AuthData consisting of the octet strings AddAuthData and PlaintextData:
C.3.2 Authentication Transformation
1. Form the 1-octet Flags field as follows:
2. Form the 16-octet B0 field as follows:
3. Parse the message AuthData as B1 || B2 ||B3, where each message block Bi is a 16-octet string.
4. The CBC-MAC value X4 is computed as follows:
C.3.3 Encryption Transformation
1. Form the 1-octet Flags field as follows:
2. Define the 16-octet Ai field as follows:
3. Parse the message PlaintextData as M1 ||M2, where each message block Mi is a 16-octet string.
4. The ciphertext blocks C1, C2 are computed as follows:
5. The string Ciphertext is the result of omitting all but the leftmost l(m)=23 octets of the string C1 ||C2:
6. Define the 16-octet encryption block S0 by
7. The encrypted authentication tag U is the result of XOR-ing the string consisting of the leftmost M=8 octets of S0 and the authentication tag T:
C.4 CCM* Mode Decryption and Authentication Checking Transformation
1. The parameter M shall have the integer value 8.
1. The key Key of size keylen=128 bits to be used:
2. The nonce N of 15-L=13 octets to be used:
3. The octet string c of length l(c)=31 octets to be used:
4. The octet string a of length l(a)=8 octets to be used:
C.4.1 Decryption Transformation
1. Parse the message c as C ||U, where the right-most string U is an M-octet string:
2. Form the padded message CiphertextData by right-concatenating the string C with the smallest non- negative number of all-zero octets such that the octet string CiphertextData has length divisible by 16.
3. Form the 1-octet Flags field as follows:
4. Define the 16-octet Ai field as follows:
5. Parse the message CiphertextData as C1 ||C2, where each message block Ci is a 16-octet string.
6. The ciphertext blocks P1, P2 are computed as follows:
7. The octet string m is the result of omitting all but the leftmost l(m)=23 octets of the string P1 || P2:
8. Define the 16-octet encryption block S0 by
9. The purported authentication tag T is the result of XOR-ing the string consisting of the leftmost M=8 octets of S0 and the octet string U:
C.4.2 Authentication Checking Transformation
1. Form the message AuthData using the input transformation in sub-clause C.3.1, with as inputs the string a and the octet string m that was established in sub-clause C.4.1(step 7.):
2. Use the authentication transformation in sub-clause C.3.2, with as input the message AuthData to compute the authentication tag MACTag:
3. Compare the output tag MACTag resulting from this transformation with the tag T that was established in sub-clause C.4.1(step 9.):
C.5 Cryptographic Hash Function
C.5.1 Test Vector Set 1
1. The bit string M of length l=8 bits to be used:
1. Pad the message M by right-concatenating to M the bit ‘1’ followed by the smallest non-negative number of ‘0’ bits, such that the resulting string has length 14 (mod 16) octets:
2. Form the padded message M’ by right-concatenating to the resulting string the 16-bit string that is equal to the binary representation of the integer l.
3. Parse the padded message M’ as M1, where each message block Mi is a 16-octet string.
4. The hash value Hash1 is computed as follows:
C.5.2 Test Vector Set 2
5. The bit string M of length l=128 bits to be used:
1. Pad the message M by right-concatenating to M the bit ‘1’ followed by the smallest non-negative number of ‘0’ bits, such that the resulting string has length 14 (mod 16) octets:
2. Form the padded message M’ by right-concatenating to the resulting string the 16-bit string that is equal to the binary representation of the integer l.
3. Parse the padded message M’ as M1 || M2, where each message block Mi is a 16-octet string.
4. The hash value Hash2 is computed as follows:
C.6 Keyed Hash Function for Message Authentication
C.6.1 Test Vector Set 1
1. The key Key of size keylen=128 bits to be used:
2. The bit string M of length l=8 bits to be used:
1. Create the 16-octet string ipad (inner pad) as follows:
2. Form the inner key Key1 by XOR-ing the bit string Key and the octet string ipad:
3. Form the padded message M1 by right-concatenating the bit string Key1 with the bit string M:
4. Compute the hash value Hash1 of the bit string M1:
5. Create the 16-octet string opad (outer pad) as follows:
6. Form the outer key Key2 by XOR-ing the bit string Key and the octet string opad:
7. Form the padded message M2 by right-concatenating the bit string Key2 with the bit string Hash1:
8. Compute the hash value Hash2 of the bit string M2:
C.6.2 Test Vector Set 2
1. The key Key of size keylen=256 bits to be used:
2. The bit string M of length l=128 bits to be used:
1. Compute the hash value Key0 of the bit string Key:
2. Create the 16-octet string ipad (inner pad) as follows:
3. Form the inner key Key1 by XOR-ing the bit key Key0 and the octet string ipad:
4. Form the padded message M1 by right-concatenating the bit string Key1 with the bit string M:
5. Compute the hash value Hash1 of the bit string M1:
6. Create the 16-octet string opad (outer pad) as follows:
7. Form the outer key Key2 by XOR-ing the bit string Key0 and the octet string opad:
8. Form the padded message M2 by right-concatenating the bit string Key2 with the bit string Hash1:
9. Compute the hash value Hash2 of the bit string M2:
C.7 Specialized Keyed Hash Function for Message Authentication
C.8 Symmetric-Key Key Agreement Scheme
1. The unique identifiers of the entities U and V to be used:
2. The key Key of length keylen=128 bits to be used:
3. The optional parameter SharedData of length shareddatalen=48 bits to be used:
C.8.1 Initiator Transformation
1. The length keydatalen in bits of the keying data to be generated: keydatalen=128.
2. The optional bit string Text2 to be used is not present, i.e., Text2 = e (the empty string).
1. Use the challenge generation primitive in Section 5.3 of ANSI X9.63-2001 [B7] to generate a challenge QEU for the challenge domain parameters D. Send QEU to V.
2. Then receive from V a challenge QEV’ purportedly owned by V. If this value is not received, output ‘invalid’ and stop.
3. Receive from V an optional bit string Text1, and a purported tag MacTag1’. If these values are not received, output ‘invalid’ and stop.
4. Verify that QEV’ is a valid challenge for the challenge domain parameters D as specified in sub-clause B.3.2. If the validation primitive rejects the challenge, output ‘invalid’ and stop.
5. Use the SKG primitive in clause B.5 to derive a shared secret bit string Z from the challenges Q1=QEU owned by U and Q2=QEV’ owned by V, using as key the shared key Key. If the SKG primitive outputs ‘invalid’, output ‘invalid’ and stop.
a) Form the bit string MACData = U || V || QEU || QEV’:
b) Calculate the MACTag for MACData under the key Key using the tagging transformation of the HMAC-Matyas-Meyer-Oseas MAC scheme:
c) Set Z=MACTag:
6. Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] with the Matyas-Meyer- Oseas hash function to derive keying data KKeyData of length 256 bits from the shared secret value Z and the shared data SharedData:
a) The hash values Hash1, Hash2 are computed as follows:
b) Set KKeyData=Hash1 || Hash2:
7. Parse the leftmost 128 bits of KKeyData as a MAC key MacKey and the remaining bits as keying data KeyData.
8. Form the bit string MacData1 = 0216 || V || U || QEV’ || QEU || [Text1]:
9. Verify that MacTag1’ is the tag for MacData1 under the key MacKey using the tag checking transformation specified in Section 5.7.2 of ANSI X9.63-2001 [B7]. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop.
a) Calculate MacTag1=MACMacKe y (MacData1) = E6 C3 DE 1F E8 63 15 B9 E6 A0 2B 44 FF 63 D8 D0.
b) Verify that MacTag1=MacTag1’.
10. Form the bit string MacData2 = 0316 || U || V || QEU || QEV’ || [Text2]:
11. Calculate the tag MacTag2 on MacData2 under the key MacKey using the tagging transformation specified in Section 5.7.1 of ANSI X9.63-2001 [B7] with the HMAC-Matyas-Meyer-Oseas MAC scheme:
MacTag2 = MACMacKey (MacData2) = 66 36 8D 61 0F E0 0B 7F 06 3E 74 C4 78 0A A3 6D. (22)
C.8.2 Responder Transformation
1. A challenge QEU’ purportedly owned by U.
2. The length keydatalen in bits of the keying data to be generated: keydatalen=128.
3. The optional bit string Text1 to be used is not present, i.e., Text1 = e (the empty string).
1. Verify that QEU’ is a valid challenge for the challenge domain parameters D as specified in sub-clause B.3.2. If the validation primitive rejects the challenge, output ‘invalid’ and stop.
2. Use the challenge generation primitive in Section 5.3 of ANSI X9.63-2001 [B7] to generate a challenge QEV for the challenge domain parameters D. Send to U the challenge QEV.
3. Use the SKG primitive in clause B.5 to derive a shared secret bit string Z from the challenges Q1=QEU’ owned by U and Q2=QEV owned by V, using as key the shared key SharedKey. If the SKG primitive outputs ‘invalid’, output ‘invalid’ and stop.
a) Form the bit string MACData=U || V || QEU’ || QEV:
b) Calculate the MACTag for MACData under the key Key using the tagging transformation of the HMAC-Matyas-Meyer-Oseas MAC scheme:
c) Set Z=MACTag:
4. Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] with the Matyas-Meyer- Oseas hash function to derive keying data KKeyData of length 256 bits from the shared secret value Z and the shared data SharedData:
a) The hash values Hash1, Hash2 are computed as follows:
b) Set KKeyData=Hash1 || Hash2:
5. Parse the leftmost 128 bits of KKeyData as a MAC key MacKey and the remaining bits as keying data KeyData.
6. Form the bit string MacData1 = 0216 || V || U || QEV || QEU’ || [Text1]:
7. Calculate the tag MacTag1 for MacData1 under the key MacKey using the tagging transformation specified in Section 5.7 of ANSI X9.63-2001 [B7] with the HMAC-Matyas-Meyer-Oseas MAC scheme:
8. If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send to U, if present the bit string Text1, and MacTag1.
9. Then receive from U an optional bit string Text2 and a purported tag MacTag2’. If this data is not received, output ‘invalid’ and stop.
10. Form the bit string MacData2 = 0316 || U || V || QEU’ || QEV || [Text2]:
11. Verify that MacTag2’ is the valid tag on MacData2 under the key MacKey using the tag checking transformation specified in Section 5.7 ANSI X9.63-2001 [B7]. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop.
a) Calculate MacTag2=MACMacKey (MacData2) = 66 36 8D 61 0F E0 0B 7F 06 3E 74 C4 78 0A A3 6D.
b) Verify that MacTag2=MacTag2’.
Annex D ZigBee Protocol Stack, Settable Values (Knobs)
D.1 Network Settings
D.1.1 nwkMaxDepth and nwkMaxChildren
D.1.1.1 Description
D.1.1.2 Cost impact
D.1.1.3 Value range
D.1.2 NwkMaxRouters
D.1.2.1 Description
D.1.2.2 Cost impact
D.1.2.3 Value range
D.1.3 Size of routing table
D.1.3.1 Description
D.1.3.2 Cost impact
D.1.3.3 Value range
D.1.4 Size of neighbor table
D.1.4.1 Description
D.1.4.2 Cost impact
D.1.4.3 Value range
D.1.5 Size of route discovery table
D.1.5.1 Description
D.1.5.2 Cost impact
D.1.5.3 Value range
D.1.6 Number of reserved routing table entries
D.1.6.1 Description
D.1.6.2 Cost impact
D.1.6.3 Value range
D.1.7 Buffering pending route discovery
D.1.7.1 Description
D.1.7.2 Cost impact
D.1.7.3 Value range
D.1.8 Buffering on behalf of end devices
D.1.8.1 Description
D.1.8.2 Cost impact
D.1.8.3 Value range
D.1.9 Routing cost calculation
D.1.9.1 Description
D.1.9.2 Cost impact
D.1.9.3 Value range
D.1.10 nwkSymLink
D.1.10.1 Description
D.1.10.2 Cost Impact
D.1.10.3 Value Range
D.2 Application Settings
D.2.0.1 Logical device type
D.2.0.2 Description
D.2.0.3 Cost impact
D.2.0.4 Value Range
D.2.0.5 Stack profile and beacon payload parameters
D.2.0.6 Description
D.2.0.7 Cost impact
D.2.0.8 Value Range
D.2.0.9 Number of active endpoints per device (maximum)
D.2.0.10 Description
D.2.0.11 Cost impact
D.2.0.12 Value Range
D.2.0.13 Discovery Information Cache Size
D.2.0.14 Description
D.2.0.15 Cost impact
D.2.0.16 Value Range
D.2.0.17 Binding Table Size
D.2.0.18 Description
D.2.0.19 Cost impact
D.2.0.20 Value Range
D.2.0.21 End to End Response Messaging
D.2.0.22 Description
D.2.0.23 Cost impact
D.2.0.24 Value Range
D.2.0.25 Acknowledged Service in APS
D.2.0.26 Description
D.2.0.27 Cost impact
D.2.0.28 Value Range
D.3 Security Settings
D.3.0.1 Security level
D.3.0.2 Description
D.3.0.3 Cost impact
D.3.0.4 Value Range
D.3.0.5 Master key source
D.3.0.6 Description
D.3.0.7 Cost impact
D.3.0.8 Value Range
D.3.0.9 Always use Network layer security - on or off
D.3.0.10 Description
D.3.0.11 Cost impact
D.3.0.12 Value Range
D.3.0.13 Number of NWK Keys
D.3.0.14 Description
D.3.0.15 Cost impact
D.3.0.16 Value Range
D.3.0.17 Number of Application Keys
D.3.0.18 Description
D.3.0.19 Cost impact
D.3.0.20 Value Range
D.3.0.21 Number of Frame Counters Used
D.3.0.22 Description
D.3.0.23 Cost impact
D.3.0.24 Value Range
D.3.0.25 Security timeout periods
D.3.0.26 Description
Annex E ZigBee Stack Profiles
E.1 Stack Profiles
a) Home Controls
b) Building Automation
c) Plant Control
E.2 Stack Profile Definitions
E.3 Home Controls Stack Profile
E.3.1 Network Settings
E.3.2 Application Settings
E.3.3 Security Settings
E.4 Building Automation Stack Profile
E.4.1 Network Settings
E.4.2 Application Settings
E.4.3 Security Settings
E.5 Plant Control Stack Profile
E.5.1 Network Settings
E.5.2 Application Settings
E.5.3 Security Settings
Annex F KVP XML schemas
F.1 XML schema for the get command
F.2 XML schema for the get response command
F.3 XML schema for the set command
F.4 XML schema for the set response command
F.5 XML schema for the event command
F.6 XML schema for the event response command
F.7 Example KVP commands
Figure 91 Example of a set with acknowledgement command frame
Figure 92 Example of a set response command frame
Figure 93 Example of a KVP set command frame
F.8 Example MSG command
Figure 94 Example of an MSG command frame to set the speed of a fan
Figure 95 Example of an MSG command frame to set x and y coordinates of a sensor
ZigBee Specification
ZigBee Document 053474r06, Version 1.0
December 14th, 2004
Sponsored by: ZigBee Alliance
Accepted by
ZigBee Alliance Board of Directors.
Abstract
Keywords
The ZigBee Specification describes the infrastructure and services available to
applications operating on the ZigBee platform.
ZigBee, Stack, Network, Application, Profile, Framework, Device description, Bind-
ing, Security
June 27, 2005
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
2
Copyright © 2005 ZigBee Standards Organization. All rights reserved.
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
ZigBee Specification
Legal Notice
The ZigBee Specification is available to individuals, companies and institutions free of
charge for all non-commercial purposes (including university research, technical evalua-
tion, and development of non-commercial software, tools, or documentation). For ease of
use, clearly marked errata have been incorporated into this document. These errata may
not have been subjected to an Intellectual Property review, and as such, may contain
undeclared Necessary Claims. No part of this specification may be used in development
of a product for sale without becoming a member of ZigBee Alliance.
Copyright © ZigBee Alliance, Inc. (2005). All rights Reserved. This information within this
document is the property of the ZigBee Alliance and its use and disclosure are restricted.
Elements of ZigBee Alliance specifications may be subject to third party intellectual prop-
erty rights, including without limitation, patent, copyright or trademark rights (such a third
party may or may not be a member of ZigBee). ZigBee is not responsible and shall not be
held responsible in any manner for identifying or failing to identify any or all such third
party intellectual property rights.
This document and the information contained herein are provided on an “AS IS” basis
and ZigBee DISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO (A) ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OF THIRD PARTIES (INCLUDING WITH-
OUT LIMITATION ANY INTELLECTUAL PROPERTY RIGHTS INCLUDING PATENT,
COPYRIGHT OR TRADEMARK RIGHTS) OR (B) ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-
INFRINGEMENT. IN NO EVENT WILL ZIGBEE BE LIABLE FOR ANY LOSS OF PROF-
ITS, LOSS OF BUSINESS, LOSS OF USE OF DATA, INTERRUPTION OF BUSINESS,
OR FOR ANY OTHER DIRECT, INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTIAL,
PUNITIVE OR CONSEQUENTIAL DAMAGES OF ANY KIND, IN CONTRACT OR IN
TORT, IN CONNECTION WITH THIS DOCUMENT OR THE INFORMATION CON-
TAINED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAM-
AGE. All Company, brand and product names may be trademarks that are the sole
property of their respective owners.
The above notice and this paragraph must be included on all copies of this document that
are made.
ZigBee Alliance, Inc.
2400 Camino Ramon, Suite 375
San Ramon, CA 94583
3
Copyright © 2005 ZigBee Standards Organization. All rights reserved.
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
4
Copyright © 2005 ZigBee Standards Organization. All rights reserved.
Contents
Chapter 1 Application Layer Specification..................................................... 29
1.1 General description .......................................................................................................... 29
1.1.1 Application support sub-layer............................................................................... 29
1.1.2 Application framework.......................................................................................... 29
1.1.3 Addressing........................................................................................................... 30
1.1.4 Application communication fundamentals............................................................ 32
1.1.5 Discovery ............................................................................................................. 32
1.1.6 Binding................................................................................................................. 33
1.1.7 Messaging............................................................................................................ 34
ZigBee device objects.......................................................................................... 35
1.1.8
1.2 The ZigBee application support (APS) sub-layer ............................................................. 35
1.2.1 Scope................................................................................................................... 35
1.2.2 Purpose................................................................................................................ 36
1.2.3 Application support (APS) sub-layer overview..................................................... 36
1.2.4 Service specification ............................................................................................ 37
1.2.5
Frame formats...................................................................................................... 51
1.2.6 Command frames ................................................................................................ 56
1.2.7 Constants and PIB attributes ............................................................................... 56
1.2.8
Functional description.......................................................................................... 57
1.3 The ZigBee application framework................................................................................... 62
1.3.1 Creating a ZigBee profile ..................................................................................... 62
1.3.2 Standard data type formats.................................................................................. 64
1.3.3
ZigBee descriptors............................................................................................... 67
1.3.4 AF frame formats ................................................................................................. 77
1.3.5 KVP command frames......................................................................................... 81
Functional description.......................................................................................... 86
1.3.6
1.4 The ZigBee device profile................................................................................................. 86
1.4.1 Scope................................................................................................................... 86
1.4.2 Device Profile overview........................................................................................ 86
1.4.3 Client services...................................................................................................... 89
1.4.4 Server services .................................................................................................. 109
1.4.5
ZDP enumeration description ............................................................................ 132
1.4.6 Conformance ..................................................................................................... 133
1.5 The ZigBee device objects (ZDO) .................................................................................. 133
1.5.1 Scope................................................................................................................. 133
1.5.2 Device Object Descriptions................................................................................ 134
1.5.3
Layer Interface Description................................................................................ 136
1.5.4 System Usage.................................................................................................... 137
1.5.5 Object Definition and Behavior .......................................................................... 140
1.5.6 Configuration Attributes ..................................................................................... 151
Chapter 2 Network Specification................................................................... 159
2.1 NWK layer status values ................................................................................................ 159
2.2 General description ........................................................................................................ 160
2.2.1 Network (NWK) layer overview.......................................................................... 160
Copyright © 2005 ZigBee Standards Organization. All rights reserved.
5
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
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
ZigBee Specification
2.3 Service specification....................................................................................................... 161
2.3.1 NWK data service .............................................................................................. 161
2.3.2 Network discovery.............................................................................................. 166
2.3.3 Network formation.............................................................................................. 169
2.3.4 Allowing devices to join...................................................................................... 172
2.3.5 Begin as a router................................................................................................ 173
Joining a network............................................................................................... 175
2.3.6
Joining a device directly to a network ................................................................ 181
2.3.7
2.3.8
Leaving a network.............................................................................................. 183
2.3.9 Resetting a device ............................................................................................. 186
2.3.10 Receiver synchronization................................................................................... 188
2.3.11 Information base maintenance........................................................................... 192
2.4 Frame formats ................................................................................................................ 195
2.4.1 General NPDU frame format.............................................................................. 195
2.4.2
Format of individual frame types........................................................................ 197
2.5 Command frames........................................................................................................... 198
2.5.1 Route request command.................................................................................... 199
2.5.2 Route reply command........................................................................................ 200
2.5.3 Route error command........................................................................................ 202
2.5.4
Leave command ................................................................................................ 203
2.6 Constants and NIB attributes.......................................................................................... 204
2.6.1 NWK constants .................................................................................................. 204
2.6.2 NWK information base....................................................................................... 206
2.7 Functional description..................................................................................................... 209
2.7.1 Network and device maintenance...................................................................... 209
2.7.2
Transmission and reception............................................................................... 230
2.7.3 Routing............................................................................................................... 231
2.7.4 Scheduling beacon transmissions ..................................................................... 245
2.7.5 Broadcast communication.................................................................................. 247
2.7.6 NWK information in the MAC beacons .............................................................. 249
2.7.7 Persistent data................................................................................................... 251
Chapter 3 Security Services Specification ................................................... 253
3.1 Document Organization.................................................................................................. 253
3.2 General Description........................................................................................................ 253
3.2.1 Security Architecture and Design....................................................................... 253
3.2.2 MAC Layer Security........................................................................................... 255
3.2.3 NWK Layer Security........................................................................................... 256
3.2.4 APL Layer Security ............................................................................................ 258
3.2.5
Trust Center Role............................................................................................... 259
3.3 MAC Layer Security........................................................................................................ 260
3.3.1
Frame Security................................................................................................... 260
3.3.2 Security-Related MAC PIB Attributes ................................................................ 262
3.4 NWK Layer Security ....................................................................................................... 262
3.4.1
Frame Security................................................................................................... 263
3.4.2 Secured NPDU Frame....................................................................................... 265
3.4.3 Security-Related NIB Attributes ......................................................................... 265
3.5 APS Layer Security ........................................................................................................ 267
Frame Security................................................................................................... 268
3.5.1
6
.
Copyright © 2005 ZigBee Standards Organization. All rights reserved.
Contents
3.5.2 Key-Establishment Services .............................................................................. 271
3.5.3
Transport-Key Services ..................................................................................... 278
3.5.4 Update-Device Services .................................................................................... 283
3.5.5 Remove Device Services................................................................................... 285
3.5.6 Request Key Services........................................................................................ 287
3.5.7 Switch Key Services .......................................................................................... 289
3.5.8 Secured APDU Frame ....................................................................................... 291
3.5.9 Command Frames ............................................................................................. 291
3.5.10 Security-Related AIB Attributes ......................................................................... 296
3.6 Common Security Elements........................................................................................... 297
3.6.1 Auxiliary Frame Header Format......................................................................... 298
3.6.2 Security Parameters .......................................................................................... 299
3.6.3 Cryptographic Key Hierarchy............................................................................. 300
Implementation Guidelines (Informative) ........................................................... 300
3.6.4
3.7 Functional Description.................................................................................................... 301
ZigBee Coordinator............................................................................................ 301
3.7.1
Trust Center Application .................................................................................... 301
3.7.2
3.7.3 Security Procedures........................................................................................... 302
A.2.1
A.2.2
A.2.3
Annex A CCM* Mode of Operation .............................................................. 315
A.1 Notation and representation............................................................................................. 315
A.2 CCM* mode encryption and authentication transformation.............................................. 315
Input transformation........................................................................................... 316
Authentication transformation ............................................................................ 316
Encryption transformation.................................................................................. 317
A.3 CCM* mode decryption and authentication checking transformation............................... 318
Decryption transformation.................................................................................. 318
Authentication checking transformation............................................................. 318
A.4 Restrictions....................................................................................................................... 318
A.3.1
A.3.2
B.1.1
B.1.2
B.1.3
B.1.4
B.1.5
B.1.6
Annex B Security Building Blocks .............................................................. 319
B.1 Symmetric-key cryptographic building blocks .................................................................. 319
Block-cipher ....................................................................................................... 319
Mode of operation.............................................................................................. 319
Cryptographic hash function .............................................................................. 319
Keyed hash function for message authentication .............................................. 319
Specialized keyed hash function for message authentication ........................... 320
Challenge domain parameters........................................................................... 320
B.2 Key Agreement Schemes................................................................................................. 320
Symmetric-key key agreement scheme............................................................. 320
B.3 Challenge Domain Parameter Generation and Validation ............................................... 320
Challenge Domain Parameter Generation......................................................... 321
Challenge Domain Parameter Verification......................................................... 321
B.4 Challenge Validation Primitive.......................................................................................... 321
B.5 Secret Key Generation (SKG) Primitive ........................................................................... 322
B.3.1
B.3.2
B.2.1
Copyright © 2005 ZigBee Standards Organization. All rights reserved.
7
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
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
ZigBee Specification
B.6 Block-Cipher-Based Cryptographic Hash Function.......................................................... 323
B.7 Symmetric-Key Authenticated Key Agreement Scheme.................................................. 323
Initiator Transformation...................................................................................... 325
Responder Transformation ................................................................................ 326
B.7.1
B.7.2
C.4.1
C.4.2
C.3.1
C.3.2
C.3.3
Annex C Test Vectors for Cryptographic Building Blocks ....................... 329
C.1 Data Conversions............................................................................................................. 329
C.2 AES Block Cipher............................................................................................................. 329
C.3 CCM* Mode Encryption and Authentication Transformation............................................ 329
Input Transformation.......................................................................................... 329
Authentication Transformation........................................................................... 330
Encryption Transformation................................................................................. 331
C.4 CCM* Mode Decryption and Authentication Checking Transformation............................ 331
Decryption Transformation................................................................................. 332
Authentication Checking Transformation........................................................... 333
C.5 Cryptographic Hash Function........................................................................................... 333
Test Vector Set 1 ............................................................................................... 333
Test Vector Set 2 ............................................................................................... 334
C.6 Keyed Hash Function for Message Authentication .......................................................... 335
Test Vector Set 1 ............................................................................................... 335
Test Vector Set 2 ............................................................................................... 335
C.7 Specialized Keyed Hash Function for Message Authentication....................................... 336
C.8 Symmetric-Key Key Agreement Scheme......................................................................... 337
Initiator Transformation...................................................................................... 337
Responder Transformation ................................................................................ 339
C.5.1
C.5.2
C.6.1
C.6.2
C.8.1
C.8.2
Annex D ZigBee Protocol Stack, Settable Values (Knobs) ....................... 341
D.1 Network Settings .............................................................................................................. 341
nwkMaxDepth and nwkMaxChildren.................................................................. 341
D.1.1
NwkMaxRouters................................................................................................. 342
D.1.2
Size of routing table ........................................................................................... 344
D.1.3
Size of neighbor table ........................................................................................ 345
D.1.4
Size of route discovery table.............................................................................. 346
D.1.5
Number of reserved routing table entries........................................................... 347
D.1.6
Buffering pending route discovery ..................................................................... 348
D.1.7
Buffering on behalf of end devices..................................................................... 349
D.1.8
D.1.9
Routing cost calculation..................................................................................... 349
D.1.10 nwkSymLink....................................................................................................... 350
D.2 Application Settings.......................................................................................................... 351
D.3 Security Settings .............................................................................................................. 360
Annex E ZigBee Stack Profiles.................................................................... 367
8
.
Copyright © 2005 ZigBee Standards Organization. All rights reserved.
相关推荐
FX系列微型可编程控制器用户手册（通信篇）.pdf
FX2N系列PLC培训教程.pdf
Modbus协议资料.pdf
WM8978中文资料(芯片资料).doc
5-1.【Codelab】HarmonyOS基于图像模块实现图库图片的四种常见操作.pdf
GX Developer 编程软件使用说明.pdf
uCOS-III的任务调度算法研究.pdf
STM32F407ZGT6(芯片资料).pdf
ModBus通讯规约-0701中文版.pdf
ATK-NEO-6M GPS模块常见问题汇总_201400721.pdf
STM32F103x8B_DS_CH_V10(7STM32中文数据手册).pdf
MR-E伺服与FX3G接线图.pdf
