ZLL和PRO区别

1、Differences Between ZLL and ZigBee PRO While ZLL is built upon the ZigBee PRO stack, there are differences between the two. The following sections will

outline the differences.

 

1.1、Security Differences

At the ZigBee network layer, ZLL security functions in the same manner as classical ZigBee security, although ZLL

security does not require a centralized security controller (known as a “Trust Center” in ZigBee PRO) to

authenticate incoming devices. The major difference between the ZigBee PRO and ZLL security schemes lies in

security key exchange. During ZLL network commissioning, known as “Touchlinking,” a fixed secret key known as

the ZLL key encrypts the exchanged network key. The ZLL key is stored in each ZLL device.

The transfer of the network key is handled differently depending on the type of network commissioning being

performed. During classical ZigBee commissioning where a non-ZLL device is being joined to a ZLL network

without a trust center, a pre-installed link key is used to secure the transfer of the network key when authenticating.

All certified ZLL devices share the secret pre-installed link key, however, prior to certification, a certification key is

used for testing purposes. If APS decryption fails via use of the certification pre-installed link key, ZLL devices try to

decode the APS message using a known default trust center link key, which is the same default trust center link key

used by the ZigBee Home Automation (ZHA) profile and defined in the ZHA specification.

In the case of ZLL touchlink commissioning, sixteen possible algorithms can be utilized to encrypt the network key

during the transfer between an initiator and possible target (at present, three algorithms have been allocated.)

Within its scan response inter-PAN command frame, the possible target indicates in the key bitmask field which key

encryption algorithms are supported. When the initiator receives a scan response inter-PAN frame from the

potential target, it compares its internal key bitmask with the received key bitmask field. If no common key is found

through this comparison, the initiator will not select this target for further commissioning. Otherwise, the initiator will

set the key index to the bit position corresponding to the matching key with the highest index, encrypt the network

key using the appropriate algorithm, and include both the index and the encrypted key in the key index and

encrypted network key fields, respectively, of the network start request, network join router, or network join end

device inter-PAN command frames.

Listed below are descriptions of the various ZLL key encryption algorithms

• Key index 0 (Development Key)

This algorithm encrypts the network key with AES in ECB mode in one step. The associated AES key takes

the form “PhLi” || TrID || “CLSN” || RsID, where “PhLi” and “CLSN” are character strings to be converted to

their hexadecimal equivalents, TrID is the transaction identifier field of the original scan request command

frame passed between the initiator and target, and RsID is the response identifier of the scan response

command frame passed between the target and the initiator.  This algorithm is not to be used or supported

within Commercial ZLL products.

• Key Indices 4 and 15 (Master and Certification Keys)

The algorithm itself for key encryption using the master and certification keys is the same; the difference

comes in the keys used in Network encryption. Key index 4 indicates the usage of the ZLL master key,

which is a secret key shared by all certified ZLL devices, whereas key index 15 indicates the usage of a

fixed, predetermined key for use during the certification phase known as the ZLL certification key.

As outlined in the development key algorithm, the transaction and response identifiers are exchanged

during the touchlink procedure, and for both encryption and decryption, they are expanded to form 128 bit

nonces of the form Transaction identifier || transaction identifier || response identifier || response identifier.

For encryption, a transport key is calculated by performing 128-bit AES encryption with the aforementioned

nonce as plaintext, and the ZLL master or certification key (as the case may be) as key. The initiator

encrypts the network key using the calculated transport key and AES ECB mode, and then transmits the

encrypted network key as part of the touchlinking process. The target receives the encrypted key and,

using the calculated transport key, decrypts with AES ECB mode. The target then stores the received

network key in the NIB parameter of the ZLL target.

 

1.2 Network Formation Differences

During the device discovery phase of touchlinking, an initiator will have found an appropriate target. To start a new

network, the initiator generates a network start request inter-PAN command frame as follows:

• The initiator may, if it desires, specify the PAN ID, extended PAN ID, and logical channel for the new

network within the command frame. Otherwise, they are set to zero and are determined by the target.

• The initiator sets the key index and encrypted network key fields of the command frame accordingly to

describe the ZigBee network key to be used for securing the network.

• The initiator sets the network address field of the command frame to the selected network address with

which the target shall operate on the network. If the beginning of the free network address range is equal to

0x0000, the initiator stochastically generates an address according to the classical ZigBee mechanism. If

not, the initiator gives the target the stored beginning address and increments the value. The network

address is not changed by the target unless it leaves the network and joins another, or if it is required to do

so to resolve an address conflict.

• If during the device discovery phase the target requested a set of group identifiers and the beginning of the

free group ID range is not equal to 0x0000, the initiator allocates a range of group identifiers for the target

and set the group identifiers begin and group identifiers end fields of the command frame accordingly. If

instead it is equal to 0x0000, the aforementioned fields in the command frame are set to 0x0000.

• If during the device discovery phase the target indicated that it was address assignment capable and the

beginning network address is not 0x0000, the initiator allocates a range of network addresses and group

identifiers that the target can use for its own purposes and set the free network address range begin, free

network address range end, free group identifier range begin and free group identifier range end fields of

the command frame accordingly. If instead the beginning network address is 0x0000, the aforementioned

fields in the command frame are set to 0x0000. Both TrID and RsID are random 32-bit integers.

• The initiator sets the initiator IEEE address and initiator network address fields of the command frame to its

IEEE address and the network address it will use on the new network, respectively.

Once the network start request inter-PAN command frame has been generated, the initiator unicasts it to the

selected target. It then enables its receiver and waits for a pre-specified amount of time or until a network start

response inter-PAN command frame is received with a valid transaction identifier. If the wait exceeds this duration

or the response frame is received with a non-zero status parameter value, the initiator terminates the operation with

the target in question. If there are no further targets, the operation at large is terminated and no further processing

is performed. Upon receipt of a network start response frame with a valid transaction identifier from the desired

target, the initiator first copies the network parameters to its network information base if the network parameters

were to be determined by the target, then waits to allow the target to start the network correctly. The initiator then

issues a network rejoin request to the NWK layer. If the rejoin is successful, the initiator broadcasts a device

announcement.

On the target side, when the network start request command frame is received with a valid transaction identifier,

the target decides via application specific means whether or not to join the network. If it decides not to join the

network, it generates a network start response command frame with a status indicating failure. It then performs no

additional processing. If the target decides to join the network, it checks the PAN ID, extended PAN ID, and logical

channel fields. For each field, if the value is equal to zero, the target determines an appropriate value. In order to

verify the uniqueness of the PAN and extended PAN IDs, the target issues a network discovery request to the NWK

layer over the primary ZLL channels and waits for a confirmation. The target then sets the trust center address to

0xffffffffffffffff. The target then generates a network start response command frame and unicasts it to the initiator. If

the target is not factory new, it leaves its old network, resets its network parameters to the default values, then

copies the new network parameters to its network information base and start operating on the new network by

issuing a start router request to the NWK layer. After the router has successfully started, it broadcasts a device

announcement. In order to allow direct communication via the ZigBee network between the initiator and the target,

the target finally performs a ZigBee direct join procedure in order to create an entry in the neighbor table with the

IEEE address and the network address of the initiator.

 

1.3 Addressing

Devices that are address assignment capable assign network addresses. All network addresses must be unique.

The method ZLL uses to ensure this is to assign subdivisions of the available address space to devices that join the

network and that are address assignment capable. Since ZigBee reserves the network address 0x0000 for the

coordinator and the address range (0xfff8…0xffff) for broadcast, the total ZLL network address space is defined in

the range (Nmin=0x0001…Nmax=0xfff7). Address assignment capable ZLL devices keep track of their current free

address range; when such devices are factory new, the address range is (0x0001…0xfff7). When a factory-new

initiator device, which is address assignment capable, has just formed a new network, it assigns itself the network

address Nmin (i.e., 0x0001) and then increments Nmin. When a device is joined to an existing network, it is assigned

the first (i.e. Nmin) network address from the free network address range of the initiator through which it is joining.

The initiator that started the network then increments Nmin. If a device cannot be assigned a network address, it is

not permitted to operate on the network. If a device that is address assignment capable joins the network, it also

receives its own free network address range (N’min… N’max). The initiator splits its own free network address range

at an implementation specified point and the upper range (i.e., highest in value) is assigned to the new address

assignment capable device. If after splitting the free network address range the resulting two address ranges are

smaller than an implementation specific threshold, the new device is not joined to the network.

ZLL also supports group identifiers in a similar fashion to its treatment of network addressing. Group identifiers are

used when addressing a subset of devices using broadcast mechanisms and they are typically used by a controller

application residing at a certain endpoint. The group identifiers need to be unique in the network and their range is

(0x0001…0xfeff). Group identifier 0x0000 is reserved for the default group in the ZCL scene cluster, and group identifiers in the range (0xff00…0xffff) are reserved. The number of group identifiers needed by an application

residing on an endpoint is given in the device information table. Since group identifier assignment is linked to

network address assignment, the total number of group identifiers needed by all endpoints on a node is reported in

the scan response command frame. Group management is handled as above, where Gmin ~ Nmin, Gmax ~ Nmax, G’min

~ N’min, and G’max ~ N’max.

 

1.4 Other

ZLL devices are able to operate on all channels available at 2.4 GHz, numbered from 11-26. The primary ZLL

channels are defined to be 11, 15, 20, and 25. All other channels constitute the secondary ZLL channels.

Additionally, ZLL supports a channel change mechanism in an application-defined way. When the channel change

mechanism is instigated, the device broadcasts a network update with the scan channels field set to indicate the

ZLL channel on which to begin operating. Routers receiving the update request update their NIB and execute their

channel change procedure. Routers that miss the request can be brought back into the network through a touchlink

procedure. If a touchlink initiator wants to bring a router back into the network, it sends a unicast inter-PAN network

update request command frame. If the touch-link initiator is an end device, it executes a re-join procedure.