February, 2002

Rene Struik, Certicom Corp.Slide 1

doc.: IEEE 802.15-02/123r0

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: [MAC Security Threat ModelDate Submitted: [27 February, 2002]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: []

Abstract: [This document further explains some threats in the 802.15.3 WPAN ooperational environment, based on requests from the Task Group, as formulated in document IEEE 02/121r0.]

Purpose: [Highlight issues that need to be solved to ensure the success of the 802.15.3 WPAN security.]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.

February, 2002

Rene Struik, Certicom Corp.Slide 2

doc.: IEEE 802.15-02/123r0

Submission

MAC Security Threat Model(Further Explanatory Slides)

René Struik, Certicom Research

February, 2002

Rene Struik, Certicom Corp.Slide 3

doc.: IEEE 802.15-02/123r0

Submission

The access control policy specifies how devices shall communicate in a piconet.

Discussions are relative to a particular piconet and do assume the piconet to operate in one of its secure modes (‘authentication only’, respectively ‘authentication and encryption’).

I. Admission to the piconetAdmission to the piconet is based on the outcome of the following protocols between the prospective joining device and the PNC of the piconet (in order):1. Mutual entity authentication protocol. The device and the PNC engage in a mutual entity authentication protocol based on public key techniques. This protocol provides evidence regarding the true device identity of both the joining device and the PNC, based on authentic public keys.2. (optional) Authorization techniques between both devices, based on, e.g., access control lists (ACLs). If devices have been positively authenticated and have been authorized, these are admitted to the piconet. Addressing these devices within the piconet takes place using a local Id (of 8 bits), rather than their global Id (IEEE MAC Address of 48 bits). For this an unused local Id is assigned to the joining device.

RemarkDevices in the piconet fully depend on information provided by the PNC regarding which devices have been admitted to the piconet (since admission is based on communication between the PNC anda joining device only).

Access Control to the Piconet (1)

February, 2002

Rene Struik, Certicom Corp.Slide 4

doc.: IEEE 802.15-02/123r0

Submission

Corollary (Effect of improper device list in broadcast scenario - the scenario of Draft D09)Assume the following scenario:• All devices in the piconet share a common broadcast key;• The list of admitted devices to the piconet is L:={(local 8-bit device Id, global 48-bit device Id)}.Then failure to obtain the complete and authentic list of admitted devices has the following consequences:• ‘Fly on the wall’. If a device obtains an incomplete list L’ L (L’ L) of admitted devices, all devices in the complementary set L\ L’ are ‘invisible’ to the device. Hence, the device might mistakenly think to share secured information only with devices from the list L’, whereas actually it is with other devices of the set L as well, and unknowingly so. This obviously violates sound security practice.

Access Control to the Piconet (2a)

PNC listIntended behavior: to A, PNC Actual behavior: to A, B, PNC

Global Id Local IdA 0x314159 0x01B 0x271739 0x02C 0x456123 0x03

Global Id Local IdA 0x314159 0x01

C 0x456123 0x03

C’s local list

0 1

3

PNC A

C B

0 1

3 2

PNC A

C

C wants to broadcast info based on his local address book

February, 2002

Rene Struik, Certicom Corp.Slide 5

doc.: IEEE 802.15-02/123r0

Submission

Corollary (Effect of improper device list in broadcast scenario - the scenario of Draft D09)Assume the following scenario:• All devices in the piconet share a common broadcast key;• The list of admitted devices to the piconet is L:={(local 8-bit device Id, global 48-bit device Id)}.Then failure to obtain the complete and authentic list of admitted devices has the following consequences:• ‘Switchboard problem’. If the binding between the local device Id and the global device Id is incorrectly received (e.g., 2 entries are interchanged) a device might direct information to the improper device and so compromise the intended security.

Access Control to the Piconet (2b)

Global Id Local IdA 0x314159 0x01B 0x271739 0x02C 0x456123 0x03

PNC list

Global Id Local IdA 0x314159 0x02B 0x271739 0x01C 0x456123 0x03

C’s local list

0 1

3 2

PNC A

C B

0 1

3 2

PNC A

C B

Intended behavior: to A Actual behavior: to B

C wants to send info toA, based on his local address book

February, 2002

Rene Struik, Certicom Corp.Slide 6

doc.: IEEE 802.15-02/123r0

Submission

Consequences (Effect of improper device lists on security policy)According to the security policy,

“changes to the group structure shall invoke a change to the common group keys.”

This rule can only be enforced if each device takes one of the following two stands:• Completely rely on the PNC and on all key generating devices for key-sharing groups to which he belongs, to provide up-to-date and authentic information on the current group composition. This requires a complete dependency on the key generating devices and on the PNC.• Maintain up-to-date and authentic information on ‘aliveness’ of devices with whom the device shares keying material himself. This requires no reliance on the key generating devices, nor on the PNC. It does, however, require regular re-authentication of all key-sharing devices (similar to the ‘heartbeat’ scenario the devices and the PNC have to perform to verify each other’s ‘aliveness’, as specified in Draft D09).

SolutionSince complete trust in a moving PNC is not realistic in all usage scenarios, this threat can only be diverted properly as follows:• Each device generates its own keys for its intended audience;• Each device regularly performs a ‘heartbeat’ function, to obtain semi-continuous authentication information.

The centralized security model from Draft D09 is therefore completely flawed for general scenarios.

Access Control to the Piconet (3)