March 2003 doc IEEE 802 15 03174 r

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Project: IEEE P 802. 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, 4 th Floor, Mississauga, ON Canada L 4 W 5 L 1] Voice: [+1 (905) 501 -6083], FAX: [+1 (905) 507 -4230], E-Mail: [rstruik@certicom. com] Re: [03/054 r 1] 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 D 15) 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. 3 a community of limited remaining security provisions in Draft D 16. ] Notice: This document has been prepared to assist the IEEE P 802. 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 P 802. 15. Submission 1 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Rationale for Public Key Security in IEEE 802. 15. 3(a) WPANs René Struik, Certicom Research Submission 2 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Outline 1. 2. 3. 4. 5. 6. 7. WPAN Network 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, SB 1) Submission 3 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 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. Submission 4 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 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. A PNC piconet A Authorization: Authentication + Membership test (ACL) PNC enlarged piconet (side-effect: shared link key A – PNC) Public key techniques, since ad-hoc, spontaneous network Submission 5 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 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. Key transport: distribution of keys to devices PNC B Peer-to-peer security: Data: Encryption + Integrity Commands: Integrity B Broadcast security: Data: Beacons: A PNC D C A Submission 6 Encryption + Integrity Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 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. A PNC Draft D 15 D 16: ‘Public key Exorcism (03/054 r 1)’ piconet A Declared Authorization: Out of scope Authentication + Membership test (ACL) PNC enlarged piconet (side-effect: shared link key A – PNC) Public key techniques, since ad-hoc, spontaneous network Submission 7 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 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. Key transport: distribution of keys to devices PNC Peer-to-peer security: Data: Encryption + Integrity Commands: Integrity B A PNC D Draft D 15 D 16: No changes C Broadcast security: Data: Beacons: B A Submission 8 Encryption + Integrity Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Changes to 802. 15. 3 Specification (1) Impact of Security Changes Draft D 15 D 16 • 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. 3 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? ) Submission 9 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Changes to 802. 15. 3 Specification (2) Rationale Security Changes Draft D 15 D 16 (according to 03/054 r 1) • ‘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, Link. Sec, 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. 1 x mechanism: in ‘adhoc’ network to be integrated with each device!! - Link. Sec ECSG will solve this: just formed, composed of people alien to WPAN requirements, no desire to solve WPAN problems (mainly Ethernet) {Agenda Monday (03/062 r 4): ‘Security Study Group Position’ – where is it? ’} - Industry consortium will solve this: timeline? ? Submission 10 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 ANNEX A 1. 2. 3. 4. 5. 6. Security Architectural Framework Partitioning within various IEEE 802 Standards – IEEE 802. 11 WLAN – IEEE 802. 15. 4 WPAN – IEEE 802. 15. 3 WPAN (Draft D 15) – IEEE 802. 15. 3 WPAN (Draft D 16) Submission 11 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Architectural Framework Submission 12 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Outline • Overview • Key Establishment • Key Transport • Data Transport Submission 13 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Architectural Framework: Overview (1) Security mechanisms: 1. Public-key or symmetric-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. 2. Symmetric-key transport mechanism. Secure transfer of data key from one device to other(s), based on link key(s) between sender and recipient(s). 3. 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). Submission 14 Rene Struik, Certicom Corp.

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

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Architectural Framework: Authorization (1) Authorization and key establishment is based on each of the following: (1) Evidence regarding the true identity of the other device; (2) Evidence whether one wants to communicate with this explicitly identified device. Cryptographic mechanisms: 1. Public-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. 2. Symmetric-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: 1. Acceptability test. Establishment whether a particular device is to be accepted, based on a membership test of a so-called Access Control List (ACL). Submission 16 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Architectural Framework: Authorization (2 a) (public-key scenario) ACL initialization CA key initialization ACL Maintenance ACL initialization ACL Wrapped public key info Certificate Public key maintenance verification CA key initialization Wrapped public key info A Extracted public key info ACL Maintenance Authentication, B key establishment (Link key, A, B) Extracted public key info Public key verification 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. , X 509), or implicit certificates. - Certificate maintenance and ACL maintenance are not discussed any further here. Submission 17 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Architectural Framework: Authorization (2 b) (symmetric-key scenario) ACL initialization Symm. key initialization Symmetric-key maintenance ACL Maintenance ACL initialization ACL Symmetric key info Symm. key verification Symm. key initialization Symmetric key info A Extracted symmetric key ACL Maintenance Authentication, B key establishment (Link key, A, B) 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. Submission 18 Rene Struik, Certicom Corp.

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

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Architectural Framework: Key transport (2) (Link key, A, B) Data key maintenance Data key repository (Link key, A, B) Wrapped data key info A key distribution B Wrapped data key info Data key repository Data key maintenance 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 || Key. Seq. No) seems to be a good choice. ) - Key storage and key update mechanisms are not discussed any further here. Submission 20 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Architectural Framework: Data transport (1) Data transport is based on each of the following: (1) Availability of a shared data key with the recipient(s); (2) 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). Submission 21 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Architectural Framework: Data transport (2) Data key repository Key info data Encryptor/ decryptor Data key repository Data key Wrapped data A data transfer Wrapped data B Key info Encryptor/ decryptor data 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). Submission 22 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Architectural Framework – Partitioning within various IEEE 802 standards Submission 23 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Outline • IEEE 802. 11 WLAN • IEEE 802. 15. 4 WPAN • IEEE 802. 15. 3 WPAN Submission 24 Rene Struik, Certicom Corp.

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

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

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Security Architectural Framework: 802. 15. 4 WPAN CA key initialization ACL ACL Maintenance Wrapped public key info Certificate maintenance Public key verification External (e. g. , Zig. Bee) ACL Maintenance Wrapped public key info A Extracted public key info Authentication, key establishment B Extracted public key info (Link key, A, B) Other Key Management IEEE 802. 15. 4 Data key maintenance Key info data Encryptor/ decryptor Submission Data key Certificate maintenance Public key verification External (e. g. , Zig. Bee) (Link key, A, B) Other Key Management Wrapped data key info Data key repository CA key initialization A key distribution B Key Usage Wrapped data A Wrapped data key info data transfer 27 Wrapped data B IEEE 802. 15. 4 Data key maintenance Data key repository Data key Key info Encryptor/ decryptor data Rene Struik, Certicom Corp.

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

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

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Relevant Sponsor Ballot Comments Submission 30 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Single Comment on Removal of Public-Key Establishment (1) SB 1: 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. 1 x 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 Zig. Bee work toward industry consensus on public-key establishment. Comments: - 802. 1 x mechanism: in ‘adhoc’ network to be integrated with each device!! - Link. Sec 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/062 r 4) – 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 D 18) Submission 31 Rene Struik, Certicom Corp.

March, 2003 doc. : IEEE 802. 15 -03/174 r 2 Single Comment on Removal of Public-Key Establishment (2) SB 1: 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. 1 x 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 Zig. Bee 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…. ) Submission 32 Rene Struik, Certicom Corp.