doc.: ieee 802.15-03/174r0 submission march, 2003 rene struik, certicom corp.slide 1 project: ieee...

March, 2003

Rene Struik, Certicom Corp.Slide 1

doc.: IEEE 802.15-03/174r0

Submission

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)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:[[email protected]]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.

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Rationale for Public Key Securityin

IEEE 802.15.3(a) WPANs

René Struik, Certicom Research

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Outline

1. WPAN Network Security2. Security Changes to the 802.15.3 Specification

– Impact on 802.15.3(a)– Rationale (?)

—ANNEX A

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

• Access control to the piconet itselfRestriction 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 devicesRestriction of access to information secured between members of a group of WPANdevices 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.

WPAN Network Security (1)

March, 2003


doc.: IEEE 802.15-03/174r0

Submission



PNCA

PNCA

piconet

enlarged piconet

Authorization: Authentication + Membership test (ACL) (side-effect: shared link key A – PNC)

Public key techniques, since ad-hoc, spontaneous network

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

• Control of access to message traffic between Network devicesRestriction of access to information secured between members of a group of WPANdevices 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

AB

Peer-to-peer security:Data: Encryption + IntegrityCommands: Integrity

PNC

D BBroadcast security:

Data: Encryption + IntegrityBeacons: IntegrityA

C

Key transport: distribution of keys to devices

March, 2003


doc.: IEEE 802.15-03/174r0

Submission



PNCA

PNCA

piconet

enlarged piconet

Authorization: Authentication + Membership test (ACL) (side-effect: shared link key A – PNC)

Draft D15 D16:‘Public key Exorcism (03/054r1)’

Declared Out of scope

Public key techniques, since ad-hoc, spontaneous network

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

• Control of access to message traffic between Network devicesRestriction of access to information secured between members of a group of WPANdevices 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

AB

Peer-to-peer security:Data: Encryption + IntegrityCommands: Integrity

PNC

D BBroadcast security:

Data: Encryption + IntegrityBeacons: IntegrityA

C

Key transport: distribution of keys to devices

Draft D15 D16: No changes

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

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?)

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

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• Opinion poorly interpreted by 802.15.3 Chair:

- ‘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, Dan Bailey):

- (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)- 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?)

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

ANNEX A

1. Security Architectural Framework2. 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)

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

• Overview• Key Establishment• Key Transport• Data Transport

Outline

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework: Overview (1) Security mechanisms:1. 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.

2. 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).

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

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework: Overview (2)

key distributionA B Data keyrepository

Data keymaintenance

Data key repository

Data keymaintenance

Wrappeddata key info


ACL ACLACLMaintenance

ACLMaintenance

ACL initialization

ACL initialization

BA Authentication,key establishment

Wrapped public key info

Extracted public key info



Public key verification

CA keyinitialization

Certificatemaintenance




(Link key, A, B)(Link key, A, B)

data transferA B

Wrapped data Wrapped dataEncryptor/decryptor

Encryptor/decryptordata data

Datakey

Keyinfo

Keyinfo

Datakey

Other Key Management Other Key Management

Key Usage Key Usage

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

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 key establishment mechanism. Derivation of link key between

two devices, based on authentic public keys of both parties, includingevidence on whom this link key is shared with.

2. Symmetric-key key establishment mechanism. Derivation of link key betweentwo 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).

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework: Authorization (2a) (public-key scenario)


ACLMaintenance

ACL initialization

ACL initialization













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.

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework: Authorization (2b) (symmetric-key scenario)


ACLMaintenance

ACL initialization

ACL initialization


Symmetric key info

Extracted symmetric key

Symmetric key info

Extracted symmetric key

Symm. key verification

Symm. keyinitialization

Symmetric-keymaintenance


Symm. keyinitialization



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.

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

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 key transport mechanism. Secure transfer of data key from

one device to other(s), based on link key(s) between sender and recipient(s).

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework: Key transport (2)

Data keyrepository

key distributionA BData key

maintenanceData key repository

Data keymaintenance




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.

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

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

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework: Data transport (2)

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

Data keyrepository

Data key repository

data transferA B



Datakey

Keyinfo

Keyinfo

Datakey

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework –

Partitioning within various IEEE 802 standards

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

• IEEE 802.11 WLAN• IEEE 802.15.4 WPAN• IEEE 802.15.3 WPAN

Outline

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework: 802.11 WLAN (1)


Data keymaintenance

Data key repository

Data keymaintenance




ACLMaintenance

ACL initialization

ACL initialization


Symmetric key info

Extracted Symmetric key

Symmetric key info

Extracted Symmetric key


Symmetric keyinitialization



Symmetric keyinitialization



data transferA B



Datakey

Keyinfo

Keyinfo

Datakey


Key Usage Key Usage

IEEE 802.11 IEEE 802.11

External External

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework: 802.11 WLAN (2)


Data keymaintenance

Data key repository

Data keymaintenance




ACLMaintenance

ACL initialization

ACL initialization













data transferA B



Datakey

Keyinfo

Keyinfo

Datakey


Key Usage Key Usage

IEEE 802.11 IEEE 802.11

External: IEEE 802.1x External: IEEE 802.1x

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework: 802.15.4 WPAN


Data keymaintenance

Data key repository

Data keymaintenance




ACLMaintenance

ACL initialization

ACL initialization













data transferA B



Datakey

Keyinfo

Keyinfo

Datakey


Key Usage Key Usage

IEEE 802.15.4 IEEE 802.15.4

External (e.g., ZigBee) External (e.g., ZigBee)

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework: 802.15.3 WPAN (1)


Data keymaintenance

Data key repository

Data keymaintenance




ACLMaintenance

ACL initialization

ACL initialization













data transferA B



Datakey

Keyinfo

Keyinfo

Datakey


Key Usage Key Usage

Pre-‘Exorcism’Situation

IEEE 802.15.3 IEEE 802.15.3

External External

March, 2003


doc.: IEEE 802.15-03/174r0

Submission

Security Architectural Framework: 802.15.3 WPAN (2)


Data keymaintenance

Data key repository

Data keymaintenance




ACLMaintenance

ACL initialization

ACL initialization













data transferA B



Datakey

Keyinfo

Keyinfo

Datakey


Key Usage Key Usage

Post-‘Exorcism’Situation

IEEE 802.15.3 IEEE 802.15.3

Unknown! Unknown!

doc.: ieee 802.15-03/174r0 submission march, 2003 rene struik, certicom corp.slide 1 project: ieee...

Documents