1. April 13, 2018
doc.: IEEE r0
March, 2003
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Rationale for Public Key Security in ]
Date Submitted: [12 March, 2003]
Source: [Rene Struik] Company [Certicom Corp.]
Address [5520 Explorer Drive, 4th Floor, Mississauga, ON Canada L4W 5L1]
Voice:[+1 (905) ], FAX: [+1 (905) ],
Re: [03/054r1]
Abstract: [This document discusses the impact of and lacking rationale for the removal of public key security from the draft during Sponsor Ballot comment resolution (of Draft D15) at the IEEE Interim Meeting in Ft. Lauderdale (January 13-17, 2003).]
Purpose: [Highlight major changes in WPAN security, inconsistencies in approach within the IEEE WPAN task group and between different IEEE 802 groups. Raise awareness in and a community of limited remaining security provisions in Draft D16.]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

2. Rationale for Public Key Security in IEEE 802.15.3(a) WPANs
March, 2003
Rationale for Public Key Security in IEEE (a) WPANs
René Struik, Certicom Research
Rene Struik, Certicom Corp.

3. Outline WPAN Network Security
April 13, 2018
doc.: IEEE r0
March, 2003
Outline
WPAN Network Security
Security Changes to the Specification
– Impact on (a)
– Rationale (?) —
ANNEX A (Security across IEEE 802 standards)
ANNEX B (Sponsor Ballot Comment #19, SB1)
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

4. WPAN Network Security (1)
March, 2003
WPAN Network Security (1)
Access control to the piconet itself
Restriction of access to scarce network resources to authorized devices only, to
ensure objectives including the following:
- proper bandwidth allocation;
- protection of commands (e.g., those regulating network membership);
- power drain savings.
Control of access to message traffic between piconet devices
Restriction of access to information secured between members of a group of WPAN
devices to precisely these group members. This includes any of the following
objectives:
- Confidentiality.
Prevent external parties from learning the content of exchanged messages.
- Data integrity/message authentication.
Prevent external parties from modifying or injecting messages in undetected way.
Rene Struik, Certicom Corp.

5. WPAN Network Security (2)
March, 2003
WPAN Network Security (2)
Access control to the piconet itself
Restriction of access to scarce network resources to authorized devices only, to
ensure objectives including the following:
- proper bandwidth allocation;
- protection of commands (e.g., those regulating network membership);
- power drain savings.
PNC A
piconet
Authorization:
Authentication +
Membership test (ACL)
(side-effect: shared link key A – PNC) A
PNC
enlarged piconet
Public key techniques, since ad-hoc, spontaneous network
Rene Struik, Certicom Corp.

6. WPAN Network Security (3)
March, 2003
WPAN Network Security (3)
Control of access to message traffic between Network devices
Restriction of access to information secured between members of a group of WPAN
devices to precisely these group members. This includes any of the following
objectives:
- Confidentiality.
Prevent external parties from learning the content of exchanged messages.
- Data integrity/message authentication.
Prevent external parties from modifying or injecting messages in undetected way.
PNC A B
Key transport: distribution of keys to devices
Peer-to-peer security:
Data: Encryption + Integrity
Commands: Integrity C
PNC
Broadcast security:
Data: Encryption + Integrity
Beacons: Integrity D B A
Rene Struik, Certicom Corp.

7. WPAN Network Security (4)
March, 2003
WPAN Network Security (4)
Access control to the piconet itself
Restriction of access to scarce network resources to authorized devices only, to
ensure objectives including the following:
- proper bandwidth allocation;
- protection of commands (e.g., those regulating network membership);
- power drain savings.
PNC A
Draft D15  D16:
‘Public key Exorcism (03/054r1)’
piconet
Declared
Out of scope
Authorization:
Authentication +
Membership test (ACL)
(side-effect: shared link key A – PNC) A
PNC
enlarged piconet
Public key techniques, since ad-hoc, spontaneous network
Rene Struik, Certicom Corp.

8. WPAN Network Security (5)
March, 2003
WPAN Network Security (5)
Control of access to message traffic between Network devices
Restriction of access to information secured between members of a group of WPAN
devices to precisely these group members. This includes any of the following
objectives:
- Confidentiality.
Prevent external parties from learning the content of exchanged messages.
- Data integrity/message authentication.
Prevent external parties from modifying or injecting messages in undetected way.
PNC A B
Key transport: distribution of keys to devices
Peer-to-peer security:
Data: Encryption + Integrity
Commands: Integrity C
Draft D15  D16: No changes
PNC
Broadcast security:
Data: Encryption + Integrity
Beacons: Integrity D B A
Rene Struik, Certicom Corp.

9. Security Changes to 802.15.3 Specification (1)
March, 2003
Security Changes to Specification (1)
Impact of Security Changes Draft D15  D16
NO mechanism left for device authentication in specification
REMAINS: mechanism for key updates and secure data transport
Inconsistent: key transport left in, key agreement left out (conceptually the same)
Consequences:
IEEE (a) WPANs: no secure piconet access mechanism specified
(since MAC re-used for a)
Lack of interoperability between devices
Uncertainty about secure operation of networks
Severe impact on:
- time-to-market (someone else has to define authentication now)
- market size (no interoperability, so no ‘network effects’)
- industry acceptance
In short: Change sacrifices secure piconet operation (what is rationale?)
Rene Struik, Certicom Corp.

10. Security Changes to 802.15.3 Specification (2)
March, 2003
Security Changes to Specification (2)
Rationale Security Changes Draft D15  D16 (according to 03/054r1)
‘Paul Nikolich felt authentication to be out of scope’
Comments:
Opinion expressed as 802 member, not as Chair IEEE 802
Interpretation problems by Chair (Opinion vs. interpretation hereof):
- ‘security suites out of scope’  authentication for higher layers
- ‘to be discussed at March Plenary’  premature removal authentication
(put process in place to solve issue)
- options: remains within WG, LinkSec, or  1 option: removal
Opinion inconsistent with practices elsewhere in IEEE 802 standards (see Annex A)
Improper use of Sponsor Ballot comments (CID #19):
- (speculation) Comment based on ‘yet another break of NTRUEncrypt’
Insufficient discussion about alternative means for solving authentication problem:
x mechanism: in ‘adhoc’ network to be integrated with each device!!
- LinkSec ECSG will solve this: just formed, composed of people alien to
WPAN requirements, no desire to solve WPAN problems (mainly Ethernet)
{Agenda Monday (03/062r4): ‘Security Study Group Position’ – where is it?’}
- Industry consortium will solve this: timeline??
Uncertainty about secure operation of networks
Severe impact on:
- time-to-market (someone else has to define authentication now)
- market size (no interoperability, so no ‘network effects’)
- industry acceptance
In short: Change sacrifices secure piconet operation (what is rationale?)
Rene Struik, Certicom Corp.

11. ANNEX A Security Architectural Framework
April 13, 2018
doc.: IEEE r0
March, 2003
ANNEX A
Security Architectural Framework
Partitioning within various IEEE 802 Standards
– IEEE WLAN
– IEEE WPAN
– IEEE WPAN (Draft D15)
– IEEE WPAN (Draft D16)
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

12. Security Architectural Framework
March, 2003
Security Architectural Framework
Rene Struik, Certicom Corp.

13. Outline Overview Key Establishment Key Transport Data Transport
April 13, 2018
doc.: IEEE r0
March, 2003
Outline
Overview
Key Establishment
Key Transport
Data Transport
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

14. Security Architectural Framework: Overview (1)
March, 2003
Security Architectural Framework: Overview (1)
Security mechanisms:
Public-key or symmetric-key key establishment mechanism. Derivation of link
key between two devices, based on authentic public keys or symmetric keys of
both parties, including evidence on whom this link key is shared with.
Symmetric-key key transport mechanism. Secure transfer of data key from
one device to other(s), based on link key(s) between sender and recipient(s).
Symmetric-key data transfer mechanism(s). Secure and/or authentic data transfer
between devices that share the data key (confidentiality/data integrity/authenticity).
Security policy: …
Note: Security mechanisms 1 and 2 may be combined (distinction based on
implementation cost considerations only).
Rene Struik, Certicom Corp.

15. Security Architectural Framework: Overview (2)
March, 2003
Security Architectural Framework: Overview (2)
key distribution A B
Data key
repository
maintenance
Wrapped
data key info
ACL
Maintenance
initialization
Authentication,
key establishment
Wrapped public
key info
Extracted public
Public key
verification
CA key
Certificate
(Link key, A, B)
data transfer
Wrapped data
Encryptor/
decryptor
data
Data
key
Key
info
Other Key Management
Key Usage
Rene Struik, Certicom Corp.

16. Security Architectural Framework: Authorization (1)
March, 2003
Security Architectural Framework: Authorization (1)
Authorization and key establishment is based on each of the following:
Evidence regarding the true identity of the other device;
Evidence whether one wants to communicate with this explicitly identified
device.
Cryptographic mechanisms:
Public-key key establishment mechanism. Derivation of link key between
two devices, based on authentic public keys of both parties, including
evidence on whom this link key is shared with.
Symmetric-key key establishment mechanism. Derivation of link key between
two devices, based on secret and authentic pre-shared key between both parties,
including evidence on whom this link key is shared with.
Non-cryptographic mechanisms:
Acceptability test. Establishment whether a particular device is to be accepted,
based on a membership test of a so-called Access Control List (ACL).
Rene Struik, Certicom Corp.

17. Security Architectural Framework: Authorization (2a)
March, 2003
Security Architectural Framework: Authorization (2a)
(public-key scenario)
ACL
Maintenance
initialization B A
Authentication,
key establishment
Wrapped public
key info
Extracted public
Public key
verification
CA key
Certificate
maintenance
(Link key, A, B)
Notes:
- The authentication protocol establishes a symmetric link key between the devices
(since it is an authenticated key establishment protocol).
Authenticated key establishment is based on a specific public-key protocol (e.g.,
ECC-based), using manual, explicit (e.g., X509), or implicit certificates.
- Certificate maintenance and ACL maintenance are not discussed any further here.
Rene Struik, Certicom Corp.

18. Security Architectural Framework: Authorization (2b)
March, 2003
Security Architectural Framework: Authorization (2b)
(symmetric-key scenario)
ACL
Maintenance
initialization B A
Authentication,
key establishment
Symmetric
key info
Extracted
symmetric key
Symm. key
verification
Symmetric-key
maintenance
(Link key, A, B)
Notes:
- The authentication protocol establishes a symmetric link key between the devices
(since it is an authenticated key establishment protocol).
- Authenticated key establishment is based on a specific symmetric-key protocol, using
pre-shared secret keys.
- Symmetric-key maintenance and ACL maintenance are not discussed any further here.
Rene Struik, Certicom Corp.

19. Security Architectural Framework: Key transport (1)
March, 2003
Security Architectural Framework: Key transport (1)
Key transport is based on each of the following:
Availability of a shared link key with the recipient;
Evidence whether one wants to communicate with this explicitly identified
device.
Cryptographic mechanisms:
1. Symmetric-key key transport mechanism. Secure transfer of data key from
one device to other(s), based on link key(s) between sender and recipient(s).
Rene Struik, Certicom Corp.

20. Security Architectural Framework: Key transport (2)
March, 2003
Security Architectural Framework: Key transport (2)
Data key
repository
key distribution A B
maintenance
Wrapped
data key info
(Link key, A, B)
Notes:
- Authenticated key transport may be based on the data protection mode that yields
both confidentiality and authenticity.
- Key transport must include authentic info on, e.g., the key originator, the distribution
group (key-sharing parties), and the version of the key.
(The string Key Id:=(Key originator || KeySeqNo) seems to be a good choice.)
- Key storage and key update mechanisms are not discussed any further here.
Rene Struik, Certicom Corp.

21. Security Architectural Framework: Data transport (1)
March, 2003
Security Architectural Framework: Data transport (1)
Data transport is based on each of the following:
Availability of a shared data key with the recipient(s);
Evidence whether one wants to communicate with this explicitly identified
device.
Cryptographic mechanisms:
1. Data transfer mechanism(s). Secure and/or authentic data transfer between
devices that share the data key (confidentiality/data integrity/authenticity).
Rene Struik, Certicom Corp.

22. Security Architectural Framework: Data transport (2)
March, 2003
Security Architectural Framework: Data transport (2)
Data key
repository
data transfer A B
Wrapped data
Encryptor/
decryptor
data
Data
key
Key
info
Notes:
- Data transport may be based on any negotiated data protection mode that yields a
combination of confidentiality and authenticity (for predefined taxonomy)
- Data transport must include authentic info on, e.g., the used data key(s), the sender,
and a message sequence number (to prevent replay attacks).
Rene Struik, Certicom Corp.

23. Security Architectural Framework –
March, 2003
Security Architectural Framework –
Partitioning within various IEEE 802 standards
Rene Struik, Certicom Corp.

24. Outline IEEE 802.11 WLAN IEEE 802.15.4 WPAN IEEE 802.15.3 WPAN
April 13, 2018
doc.: IEEE r0
March, 2003
Outline
IEEE WLAN
IEEE WPAN
IEEE WPAN
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

25. Security Architectural Framework: 802.11 WLAN (1)
March, 2003
Security Architectural Framework: WLAN (1)
ACL
initialization
ACL
initialization
ACL
Maintenance
ACL
Maintenance
ACL
ACL
Symm. key
verification
Symmetric key
initialization
Symmetric-key
maintenance
Symmetric key
initialization
IEEE
External
Symmetric
key info
Extracted
Symmetric key
Symmetric
key info
Symmetric-key
maintenance A
Authentication,
key establishment B
Symm. key
verification
Extracted
Symmetric key
(Link key, A, B)
(Link key, A, B)
Other Key Management
Other Key Management
Wrapped
data key info
Wrapped
data key info
Data key
maintenance
Data key
repository
Data key
maintenance
key distribution A B
Data key
repository
Key
info
Data
key
Key Usage
Key Usage
Data
key
Key
info
Wrapped data
Wrapped data
data transfer A B
data
Encryptor/
decryptor
Encryptor/
decryptor
data
Rene Struik, Certicom Corp.

26. Security Architectural Framework: 802.11 WLAN (2)
March, 2003
Security Architectural Framework: WLAN (2)
key distribution A B
Data key
repository
maintenance
Wrapped
data key info
ACL
Maintenance
initialization
Authentication,
key establishment
Wrapped public
key info
Extracted public
Public key
verification
CA key
Certificate
(Link key, A, B)
data transfer
Wrapped data
Encryptor/
decryptor
data
Data
key
Key
info
Other Key Management
Key Usage
IEEE
External: IEEE 802.1x
Rene Struik, Certicom Corp.

27. Security Architectural Framework: 802.15.4 WPAN
March, 2003
Security Architectural Framework: WPAN
ACL
initialization
ACL
initialization
ACL
Maintenance
ACL
Maintenance
ACL
ACL
Public key
verification
CA key
initialization
Certificate
maintenance
CA key
initialization
Wrapped public
key info
Extracted public
Wrapped public
key info
Certificate
maintenance A
Authentication,
key establishment B
Public key
verification
Extracted public
key info
External (e.g., ZigBee)
External (e.g., ZigBee)
(Link key, A, B)
(Link key, A, B)
Other Key Management
Other Key Management
IEEE
Wrapped
data key info
IEEE
Wrapped
data key info
Data key
maintenance
Data key
repository
Data key
maintenance
key distribution A B
Data key
repository
Key
info
Data
key
Key Usage
Key Usage
Data
key
Key
info
Wrapped data
Wrapped data
data transfer A B
data
Encryptor/
decryptor
Encryptor/
decryptor
data
Rene Struik, Certicom Corp.

28. Security Architectural Framework: 802.15.3 WPAN (1)
March, 2003
Security Architectural Framework: WPAN (1)
key distribution A B
Data key
repository
maintenance
Wrapped
data key info
ACL
Maintenance
initialization
Authentication,
key establishment
Wrapped public
key info
Extracted public
Public key
verification
CA key
Certificate
(Link key, A, B)
data transfer
Wrapped data
Encryptor/
decryptor
data
Data
key
Key
info
Other Key Management
Key Usage
Pre-‘Exorcism’
Situation
External
External
IEEE
IEEE
Rene Struik, Certicom Corp.

29. Security Architectural Framework: 802.15.3 WPAN (2)
March, 2003
Security Architectural Framework: WPAN (2)
key distribution A B
Data key
repository
maintenance
Wrapped
data key info
ACL
Maintenance
initialization
Authentication,
key establishment
Wrapped public
key info
Extracted public
Public key
verification
CA key
Certificate
(Link key, A, B)
data transfer
Wrapped data
Encryptor/
decryptor
data
Data
key
Key
info
Other Key Management
Key Usage
Post-‘Exorcism’
Situation
Unknown!
Unknown!
IEEE
IEEE
Rene Struik, Certicom Corp.

30. Relevant Sponsor Ballot Comments
March, 2003
Relevant Sponsor Ballot Comments
Rene Struik, Certicom Corp.

31. Single Comment on Removal of Public-Key Key Establishment (1)
March, 2003
Single Comment on Removal of Public-Key Key Establishment (1)
SB1: CID #19 (Dan Bailey, NTRU)
There is little consistency among the options for public-key establishment in the draft.
Moreover, there are too many. Further, the standard lacks extensibility to 802.1x and
the forthcoming 802 link security standard. The MAC handles public-key
authentication transparently: it's all in the DME recognized this and left
key establishment to industry bodies or other follow-on documents. That simplified
their standard and let ZigBee work toward industry consensus on public-key
establishment.
Comments:
802.1x mechanism: in ‘adhoc’ network to be integrated with each device!!
LinkSec ECSG will solve this: just formed, composed of people alien to
WPAN requirements, no desire to solve WPAN problems (mainly Ethernet)
{Monday March 10, 2003: Security Study Group Position (03/062r4) – where is it?}
Industry consortium will solve this: timeline??
parallel i): motivation based on avoiding political derailment, as in
parallel ii): Low-Rate WPAN does not have DME (cf. Draft D18)
Rene Struik, Certicom Corp.

32. Single Comment on Removal of Public-Key Key Establishment (2)
March, 2003
Single Comment on Removal of Public-Key Key Establishment (2)
SB1: CID #19 (Dan Bailey, NTRU)
There is little consistency among the options for public-key establishment in the draft.
Moreover, there are too many. Further, the standard lacks extensibility to 802.1x and
the forthcoming 802 link security standard. The MAC handles public-key
authentication transparently: it's all in the DME recognized this and left
key establishment to industry bodies or other follow-on documents. That simplified
their standard and let ZigBee work toward industry consensus on public-key
establishment.
Comments (cont’d):
‘Little consistency’: only difference is claimed security level; frame formats the same!
‘Too many protocols’: security compromise (02/323, July 9, 2003) caused move from
1 protocol (ECC-based) to 3 (ECC, NTRUEncrypt, RSA)
What is real motivation comment (commenter put considerable time in standard effort)?
NTRUEncrypt: attack on padding scheme (CRYPTO 2002, Aug 2002)
NTRUEncrypt attack on main scheme (John Proos, posted Jan 7, 2003)
(Related Sponsor ballot comments on NTRUEncrypt robustness….)
Rene Struik, Certicom Corp.