April 13, 2018 doc.: IEEE 802.15-02030r0 March, 2003 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Rationale for Public Key Security in 802.15.3] 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) 501-6083], FAX: [+1 (905) 507-4230], E-Mail:[rstruik@certicom.com] Re: [03/054r1] Abstract: [This document discusses the impact of and lacking rationale for the removal of public key security from the 802.15.3 draft during Sponsor Ballot comment resolution (of Draft D15) at the IEEE 802 Interim Meeting in Ft. Lauderdale (January 13-17, 2003).] Purpose: [Highlight major changes in 802.15.3 WPAN security, inconsistencies in approach within the IEEE 802.15.3 WPAN task group and between different IEEE 802 groups. Raise awareness in 802.15.3 and 802.15.3a community of limited remaining security provisions in Draft D16.] Notice: This document has been prepared to assist the IEEE P802.15. 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 P802.15. Rene Struik, Certicom Corp. Rene Struik, Certicom Corp.

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

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

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.

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.

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.

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.

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.

Security Changes to 802.15.3 Specification (1) March, 2003 Security Changes to 802.15.3 Specification (1) Impact of Security Changes Draft D15  D16 NO mechanism left for device authentication in 802.15.3 specification REMAINS: mechanism for key updates and secure data transport Inconsistent: key transport left in, key agreement left out (conceptually the same) Consequences: IEEE 802.15.3(a) WPANs: no secure piconet access mechanism specified (since 802.15.3 MAC re-used for 802.15.3a) 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.

Security Changes to 802.15.3 Specification (2) March, 2003 Security Changes to 802.15.3 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 802.15.3 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 802.1  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: - 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) {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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

Security Architectural Framework: 802.11 WLAN (1) March, 2003 Security Architectural Framework: 802.11 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 802.11 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.

Security Architectural Framework: 802.11 WLAN (2) March, 2003 Security Architectural Framework: 802.11 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 802.11 External: IEEE 802.1x Rene Struik, Certicom Corp.

Security Architectural Framework: 802.15.4 WPAN March, 2003 Security Architectural Framework: 802.15.4 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 802.15.4 Wrapped data key info IEEE 802.15.4 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.

Security Architectural Framework: 802.15.3 WPAN (1) March, 2003 Security Architectural Framework: 802.15.3 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 802.15.3 IEEE 802.15.3 Rene Struik, Certicom Corp.

Security Architectural Framework: 802.15.3 WPAN (2) March, 2003 Security Architectural Framework: 802.15.3 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 802.15.3 IEEE 802.15.3 Rene Struik, Certicom Corp.

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

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. 802.15.4 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?? 802.15.4 parallel i): motivation based on avoiding political derailment, as in 802.15.3 802.15.4 parallel ii): Low-Rate WPAN does not have DME (cf. Draft D18) Rene Struik, Certicom Corp.

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. 802.15.4 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.