NFR - Unified Joining Process –
14-0159-01
The New Feature Request (NFR) form is used to submit an NFR for consideration and approval AND track progress of
work.
Process Stage /
Information
Content
Proposal
To Be Completed by Submitting Organization/Organizations
Name of
Feature
(Proposed)
Unified Joining Process
Author
Jonathan Cressman, Energate Inc., jcressman@energateinc.com
Date Submitted
March 19, 2014
Feature
Description
The hardest part of communicating with embedded devices is securely joining embedded devices
to the correct network. We are proposing a single common joining algorithm for all devices and
all networks.
A joining process must do the following 12 things*
a. Be flexible and allows for trade off between security and ease of use
b. Is always secure against a passive attacker regardless to the security level chosen
and only insecure at the lowest security setting to an active attacker during a
small time window.
c. Result in a shared common secure key
d. Be immune to brute force attacks but still use a short secret!
e. Support devices with limited or no user interface.
f. Steer devices to attempt to join the correct network
g. Protect devices from joining the wrong network and validate the network
h. and networks from allowing unauthorized devices to join
i. Symmetric – all devices perform same basic operations regardless of role or
security level and out of band data (joining code) can be communicated from the
joining device to the network or vice versa.
j. Does not require a certificate authority
k. Computationally inexpensive
l. Avoids two generals paradox where one party thinks it has joined the network,
the other thinks joining has failed and neither side can resolve this conflict
without outside intervention.
Current Limitations
The two (three) current joining methods have many limitations and do not satisfy the 12
requirements listed above and force a vendor to choose methods based on the security
concerns. The new method is the same for all environments.
ZigBee Alliance New Feature Request Form
Page 1 of 9
Confidential: For Alliance Members Only
NFR - Unified Joining Process –
14-0159-01
Specifically:
HA and ZLL Joining method (using well known key)
 Lacks any real security
 Lacks steering – devices can accidentally join the wrong network and network will
accept unauthorized devices.
Install Code – without CBKE
 Codes of 52 digits are hard to print on devices
 Codes are hard to read and communicate accurately by humans
 MAC address is not protected by the CRC
 48 bit Code is insecure (64 bit is on the edge)
 Not symmetric – the code can only go from the joining device to the network
SE (install code with CBKE)
 Requires a Certificate Authority
 Computationally expensive – each device performs 3 Elliptic curve operations
 Potential for devices to get stuck in a two generals like problem where one device
thinks it has joined but the other side doesn’t.
a
b
c
d
e
f
g
h
i
j
k
l
HA well
known key












Install
code












Install code
plus CBKE












Unified
Joining












* If there is a feature that is needed that I have missed I am open to suggestions. I have
intentionally left one feature of the SE method out because it would require a CA and I don’t
think it is useful.
ZigBee Alliance New Feature Request Form
Page 2 of 9
Confidential: For Alliance Members Only
NFR - Unified Joining Process –
14-0159-01
Rough outline
Every device will have a variable length Joining Code printed on it of length 0 to 20 digits. The
format of the Joining Code is:
Steering ID/Shared Secret/Check Sum
1. The Joining Code is shared between the joining device and the network. Unlike a WiFi
laptop joining a router, most embedded devices will not have a user interface to choose
a network and enter a password. Therefore the most common way of sharing the
Joining Code is to read the code off the joining device and enter it into a device on the
network. The Check Sum, if present, is to give the user immediate feedback if they have
entered the Joining Code incorrectly.
2. The network then is set to allow devices to join and the joining device is told to look for a
network to join. This will most often just be pressing a button on the joining device and
another button on a device on the network.
3. The joining device will attempt to join any network that has signalled that it is allowing
devices to join, the network will look at the join attempt and check if the devices
Steering ID matches the Steering ID of a joining code that it knows. If the Steering ID
does not match the device is not allowed to continue. A steering ID of length zero
means allow all devices to attempt to join.
4. Both devices use the Shared Secret to choose the same generator of an elliptic curve.
This choosing algorithm allows for a zero length Shared Secret. Both devices then
independently choose a random number between zero and the number of elements of
the curve. We are then essentially doing Diffie-Hellman key exchange using the
generator as the common base. If both sides generate the same number we will know
that both sides started with the same generator and we will now have a large random
number to use as a basis for a symmetric encryption key a passive attacker will have no
knowledge of.
a. Let those random numbers be A and B and the generator of the curve be G. ‘^’
shall mean exponentiation. The joining device sends G^A to the network and the
network sends G^B to the joining device. The joining device knows A and takes
the G^B it just received and calculates (G^B)^A = G^(BA) = G^AB. Likewise the
network can calculate (G^A)^B = G^(AB). A passive attacker, even if he now uses
brute force to guess G, will only know G, G^A and G^B.
b. Based on the type of network the network now sends information uniquely
identifying it and any network layer keys to the joining device.
c. The joining device on confirming it can decrypt the network information knows it
is now successfully joined to the network. It then sends a deprecate Joining
Code message to the network.
ZigBee Alliance New Feature Request Form
Page 3 of 9
Confidential: For Alliance Members Only
NFR - Unified Joining Process –
14-0159-01
d. The network receives the deprecate Joining Code message and removes that
joining code from its list of joining codes
Variations
No Joining Code
Low security devices that give obvious feedback that they have joined the correct network (e.g.
light bulbs) could use the zero length Joining Code. These devices would still do the key
exchange step and create a secure key known only by the network and the light. If an active
attacker was present the attacker could perform a man-in-the-middle attack but the
convenience of the joining experience outweighs the risk.
Short Shared Secret
This is likely the most common joining method for devices of medium importance where only
one device is being added to the network at a time and there likely are not multiple networks
allowing devices to join at the same time.(e.g. home owner outdoor temperature sensors,
factory adding energy monitors). Here the Joining code could be /1234/. Such a device will look
for any network to join. To prevent a brute force attack on the Shared secret the device and the
network will both only allow a small number of join attempts. If after this small number of
attempts the devices have failed to agree on a new key no further joining attempts will be
possible without an person intervening and re-permitting joining on the device and the network.
Continuously Joining Device
A device being installed to a network where the network is controlled remotely may want to be
continuously attempting to join a network (e.g. a utility controlled load control device for a pool
pump, utility capacitor bank switch, remote sensors). In such a case a long Steering Code is
used. Thus the device could be looking for a network to join for hours or days and it might see
many networks that are permitting joining but only the network that knows its Steering ID will
allow the device to attempt to join.
Joining Code Entered on the Joining Device
Some embedded devices will have a limited user interface and want to join a network with an
even more limited interface (e.g. a smart thermostat like the Nest attempting to join a WiFi
network). In this case the WiFi router would have a Joining Code such as 98/222222/34. The
joining code would be entered on the thermostat and the router and thermostat would be told
to start joining. The thermostat will only join the WiFi network and even though the router
always uses the same shared secret the risk, even if multiple devices are allowed to join it, is still
very low that an attacker could compromise the network.
Limitations and Criticisms
Requires elliptic curve library
ZigBee Alliance New Feature Request Form
Page 4 of 9
Confidential: For Alliance Members Only
NFR - Unified Joining Process –
14-0159-01
Does not explicitly prove the identity of the devices involved
A malicious active attacker can:
 Perform man-in-the-middle attacks if no shared secret is present,
 Can use up the joining attempts of devices with Shared Secrets and require human
intervention.
Scope and
Purpose
Limitations of
the current
version
This Joining method is to replace the current joining methods for profile interoperability. The
new joining method exceeds the requirements of all the existing profiles.
HA and ZLL Joining method (using well known key)
 Lacks any real security
 Lacks steering – devices can accidentally join the wrong network and network will
accept unauthorized devices.
Install Code – without CBKE
 Codes of 52 digits are hard to print on devices
 Codes are hard to read and communicate accurately by humans
 MAC address is not protected by the CRC
 48 bit Code is insecure (64 bit is on the edge)
 Not symmetric – the code can only go from the joining device to the network
SE (install code with CBKE)
 Requires a Certificate Authority
 Computationally expensive – each device performs 3 Elliptic curve operations
 Potential for devices to get stuck in a two generals like problem where one device
thinks it has joined but the other side doesn’t.
Will this
features be
mandatory or
optional?
Affected TSC
and Work
Groups
MANDITORY – this method is being proposed as the common joining method for all ZigBee
devices.
Does this affect
Base Device
operations?
Does this affect
existing
application
clusters,
commands,
Yes – Steering, joining
Profile interop
Foundation
ZigBee Pro
No – only affects joining.
Yes – the joining would now result in a secure APS link key that would be acceptable by SE
networks so HA devices would be able to access SE clusters directly.
ZigBee Alliance New Feature Request Form
Page 5 of 9
Confidential: For Alliance Members Only
NFR - Unified Joining Process –
14-0159-01
etc.?
Will this affect
interoperability?
Will this be
backward
compatible?
YES
YES – this is a new joining method
NO – this will not affect the joining experience for many users. For secure networks there will
still be out of band information that needs to be passed (although it is shorter), for EZ mode
users the zero length joining code would be used so the experience would be the same.
Technical
Requirements
ZibBee Pro needs a way to pass a message from the joining device to the network.
All devices will need the Elliptic curve library.
Related
Documents
[List any other related documents check into the ZigBee Alliance document management system]
Supporting
Alliance
members
[List the Alliance members that are requesting this new feature]
Effort
Participants
Energate
Rainforest Automation
Develco
Schneider Electric
Silabs
Sensus
If necessary, please contact the chairs of relevant work groups and secure time to discuss in
order to recruit participants or develop support for the proposed NFR.
Once an author believes the proposed NFR is complete and has sufficient support, please submit
for approval to the TC Chair and the Alliance Marketing lead.
To be completed by TC based on Marketing action
Marketing
Review
Approved by
Marketing?
When?
[ YES/NO – Date]
Comments
Initial TC
Review
To be completed by TC
Approved by TC? [ YES/NO – Date]
When?
ZigBee Alliance New Feature Request Form
Page 6 of 9
Confidential: For Alliance Members Only
NFR - Unified Joining Process –
14-0159-01
Actions from TC
review
ID
Description
Target Completion Date
Feature ID
Assigned
Champion
[Person, Organization, e-mail address]
Priority
[High / Medium / Low]
Affected TSC
and Work
Groups
Affected TSC and WG:
[Enter all possible working groups that may be affected by this new feature]
TC to forward to affected TSC or WGs for review.
TSC or Working
Group Review
To be completed by TSC or WG. Section should be duplicated if multiple groups are affected.
Approved by TSC [ YES/NO – Date]
or WG? When?
Interfaces to
other affected
groups
Where work
should be
performed?
[Work Group(s) affected and description of required interfaces.]
[List existing task groups or work groups or recommendations for new groups.]
Deliverables and
Actions to
Realize
Deliverables
Describe major milestones of development including spec text delivery date, ballots for
0.7, test plan development, interoperability testing, ballots for 0.9, SVE testing etc.
ID
Description
Target Completion Date
[1]
[e.g. Deliverable X]
[1.1] [e.g. Freeze specification for Deliverable X]
[2]
[e.g. Deliverable Y]
Additional
Comments
[Comments related to interoperability, backward compatibility or similar issues should be noted
here.
Chairperson(s) of work group(s) to refer back to TC for second review
Second TC
ZigBee Alliance New Feature Request Form
Page 7 of 9
Confidential: For Alliance Members Only
NFR - Unified Joining Process –
14-0159-01
Review
Approved by TC? [ YES/NO – Date]
When?
Actions from TC
review
ID
Where will the
work be done?
[Name of group and work group where will will be performed.]
New Task
groups or Work
Groups Created
[List of work groups, document containing scope and charter]
Feature
Creation
Documents &
CCBs for
Approval by TC
Final TC Review
Description
Target Completion Date
Once specification, test plan, PICs are created, they must be submitted for final TC review.
??? Suggest deleting this section. Don’t think this form should be a project tracking thing.
Should be covered by normal work group processes and minutes.
Document or CCB #
Title
Description
This section to be completed by TC during final review.
Approved by TC? [ YES/NO – Date]
When?
Actions from TC
Review
ID
Description
Completion date
of errata and
CCBs
[Date]
ZigBee
specification
where feature is
[ZigBee specification release containing this new feature]
ZigBee Alliance New Feature Request Form
Target Complete Date
Page 8 of 9
Confidential: For Alliance Members Only
NFR - Unified Joining Process –
14-0159-01
included
Additional
Comments
ZigBee Alliance New Feature Request Form
Page 9 of 9
Confidential: For Alliance Members Only