1. May 26, 2019
doc.: IEEE r0
December, 2001
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [MAC Distributed Security Proposal]
Date Submitted: [22 February, 2002]
Source: [Rene Struik] Company [Certicom Corp.]
Address [5520 Explorer Drive, 4th Floor, Mississauga, ON Canada L4W 5L1]
Voice:[+1 (905) ], FAX: [+1 (905) ],
Re: []
Abstract: [This document describes elements of the security architectural framework for the Wireless Personal Area Network, based on the characteristics of this network and its intended operational usage.]
Purpose: [Highlight issues that need to be solved to ensure the success of the WPAN security.]
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. MAC Distributed Security Proposal
December, 2001
MAC Distributed Security Proposal
Gregg Rasor, Motorola
René Struik, Certicom Research
Scott Vanstone, Certicom Research
Rene Struik, Certicom Corp.

3. Outline IEEE 802.15.3 WPAN Technology
May 26, 2019
doc.: IEEE r0
December, 2001
Outline
IEEE WPAN Technology
IEEE WPAN Security Objectives
Modes of Operation of the Piconet
Devices and their Roles
Security Policy
Access Control to the Piconet
The Need for a Distributed Security Model
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

4. IEEE 802.15.3 WPAN Technology Communication technology.
May 26, 2019
doc.: IEEE r0
December, 2001
IEEE WPAN Technology
Communication technology.
- Radio transmissions at unlicensed 2.4 GHz frequency band;
- High data rates, up to 55 Mbps;
- Short range communication (10 meters) between static and moving devices.
Devices.
- Computers, PDAs, handheld PCs, printers;
- Digital imaging systems, microphones, speakers, headsets;
- Personal & professional video streams (e.g., set top box, security camera);
- Barcode readers, sensors, displays, pagers, mobile and PCS phones.
Personal Area Networks (Piconets).
- Network of at most 252 devices, at close mutual distance;
- Communication patterns include peer-to-peer and broadcast;
- Piconet Controller (PNC), one of most capable devices in piconet.
Tasks:
(1) admission control; (2) message control; (3) bandwidth allocation.
Interaction with outside world.
- child and neighbor piconet. Via common device or PNC of particular piconet;
- other networks (e.g., LANs, WLANs). Via so-called portal, which communicates MAC service
data units back and forth.
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

5. IEEE 802.15.3 WPAN Security Objectives
December, 2001
IEEE WPAN Security Objectives
Access control to the piconet.
Restriction of access to scarce network resources to authorized devices only, to ensure objectives
including the following:
- proper bandwidth allocation;
- protection of radio-related commands;
- quality of service (QoS);
- power savings.
Control of access to message traffic between piconet devices.
Restriction of access to information secured between members of a group of piconet 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.
Prevent external parties from modifying or injecting messages in undetected way.
Rene Struik, Certicom Corp.

6. Modes of Operation of the Piconet
December, 2001
Modes of Operation of the Piconet
No security.
No cryptographic security services are provided.
- Any device may join the piconet (no evidence regarding the true identity of devices,
nor authorization hereof);
- Any device may claim scarce resources (no protection of commands);
- All message traffic is unsecured (no provisions for confidentiality or data integrity).
Authentication only.
- Only authorized devices may join the piconet (evidence regarding the true identity
of devices and authorization hereof);
- Only admitted devices may claim scarce resources (protection of commands);
Authentication and encryption.
- All message traffic is secured (provisions for confidentiality or data integrity).
Rene Struik, Certicom Corp.

7. Devices and their Roles (1)
December, 2001
Devices and their Roles (1)
Role model
Security Manager. Sole source of local trust management.
-Facilitates establishment of keying material between ordinary devices;
-Facilitates maintenance of keying relationships;
-Enforces security policy.
Ordinary device. Part of piconet or could become part hereof.
- Responsible for secure processing and storage of keying material.
Piconet controller (PNC). Sole source of local message control.
-Facilitates admission of ordinary devices to the piconet;
-Allocates time slots for message exchanges between devices;
-No security responsibilities (apart from access control to the piconet).
Portal. Sole source that ensures integration with external networks.
-No security responsibilities.
External trusted party. Sole source of global trust management.
-Facilitates establishment of public keying material between ordinary devices;
-Facilitates maintenance of public keying relationships;
Role of portal considered out of scope, since it deals with communications with outside world.
Rene Struik, Certicom Corp.

8. Devices and their Roles (2)
December, 2001
Devices and their Roles (2)
Motivation role model
Distributed implementation possible, since roles only conceptually centralized.
- Allowance for more than 1 PNC (since not fixed in time and place);
- Allowance for more than 1 Security Manager or more than 1 External Trusted Party.
Roles independent of actual implementation.
- Different roles may be implemented on a single device (e.g, PNC and Security Manager).
Separation of roles and devices that assume these roles
- Allowance for dynamic mappings of roles to devices possible (e.g., changes to PNC and Security Mgr).
- Different devices may associate different roles with the same device, depending on their view on the
role(s) this device should play (e.g., device is Security Mgr for one device, ordinary device for another).
PNC need not be fixed in time and place. Hence, not prudent to assign a priori security functionality to it
(for otherwise, trust might need to be established over and over again, at each change of PNC).
External Trusted Party is sole source of global trust, since it is external to the network and might have the
resources deemed necessary for proper key management, e.g., secure key generation facilities, proper
authentic storage of keying material, availability.
Mapping of roles to devices
Devices need way to recognize which role(s) other devices play or should play.
- Static mapping. Mapping may be defined at initialization.
- Dynamic mapping. Mapping must be realized by securely associating roles to devices, allowing dynamic
verification (e.g., via attribute certificates).
Rene Struik, Certicom Corp.

9. Devices and their Roles (3)
December, 2001
Devices and their Roles (3)
‘Permanent’ mappings of roles to devices
The following mapping of roles to devices are always in effect:
Each device assumes the role of ordinary device (for all devices);
The PNC device assumes the role of PNC (for all devices);
Each device may assume the role of (alternate) PNC (but there is only 1 PNC device at a time);
Each device may assume the role of security manager (for any subset of devices that include itself).
The role of the external trusted party includes facilitating the generation of authentic public keying material for each device. As such, it includes
- (facilitating) the generation of a public/private key pair for each device, if needed;
- generation of certificates for each device’s public key;
- (facilitating) the storage of an authentic copy of the trusted party’s own public key signature verification
key in each device, prior to its operational deployment.
There is (conceptually) only 1 entity that assumes the role of external trusted party (for all devices).
(If there is actually more than 1 external trusted party, each device is assumed to have access to the other external trusted party’s ‘root’ key, either directly or via cross-certification techniques.)
The role of the external trusted party is implemented outside the network (CA functionality).
Remark The PNC mapping is quasi-static, since the local address of the PNC is always fixed as 0x00.
Rene Struik, Certicom Corp.

10. Devices and their Roles (4)
December, 2001
Devices and their Roles (4)
Other mappings of roles to devices
The actual mapping of the PNC role to a device and that of the Security Manager role to a device might change over time.
EXAMPLES
I. Centralized security model (Mapping of roles to devices as in Draft D09)
The Draft D09 document uses a quasi-static mapping, where one has the ‘permanent’ mappings and where
the PNC device assumes the role of Security Manager (for all devices).
There are no other mappings of roles to devices in effect.
II. Distributed security model (Our proposed mapping of roles to devices)
The distributed security model uses a quasi-static mapping, where one has the ‘permanent’ mappings and
where
each device assumes the role of Security Manager (for himself only).
(If desired, one can ‘relax’ this mapping by postulating that each device assumes the role of Security Manager for himself and for all other devices that trust him (‘friendship’ scenario).) .
A detailed discussion of properties to follow later.
Rene Struik, Certicom Corp.

11. December, 2001
Security Policy (1)
The security policy specifies rules that must be adhered to to keep security properties of system
invariant, in the event of security events.
Discussions are relative to a specific set of piconet devices (group).
Security events
1. Change of group structure.
(a) Exclusion of an old group member from the group:
- Expiration of group membership. Disassociation due to time-out.
- Cancellation of group membership. Disassociation due to cancellation request.
- Denial of access. Disassociation due to enforcement of security policy.
(b) Introduction of a new group member to the group:
- Subscription of the member. Authentication of newly associated device.
2. Change of (security relevant) role.
Due to mapping of roles to devices, this refers to PNC hand over only:
- Resigning PNC. PNC that actively gives up its role, while remaining member.
- Assuming PNC. Ordinary device that assumes role of PNC.
Simultaneous changes to the group structure and to the security relevant role are conceptually thought
of as to occur subsequently (in any order).
Rene Struik, Certicom Corp.

12. December, 2001
Security Policy (2)
I. Effect of security events - change of group structure
Scenario where information shared between group members is secured via a
common (symmetric) group key.
Security invariant
At any given moment of time, access to information shared between members of a group is
restricted to precisely these group members. As such, this includes access to integrity information.
Security rule
Changes to the group structure shall invoke a change to the common group keys.
Rationale
1. This prevents a new group member from gaining access to secured information communicated
prior to the moment he obtained access to the key-sharing group.
2. This prevents an old group member from gaining access to secured information communicated
after the moment he was denied access to the key-sharing group.
Rene Struik, Certicom Corp.

13. December, 2001
Security Policy (3)
I. Effect of security events - change of group structure (cont’d)
Key storage invariant
At any given moment of time, devices maintain symmetric keying relationships with groups to which
they belong only.
Key storage rule
Changes to the group structure shall invoke the secure destruction of the old group key(s) and the secure
and authentic storage of the new group key(s).
Rationale
This limits the impact of the potential compromise of symmetric keying material to exposure of
information to which the device already has access as a legitimate group member.
II. Effect of security events - change of security relevant role
Scenario where information shared between group members is secured via a common (symmetric)
group key.
Changes between a group member’s role as PNC and as ordinary device have no impact on the group
structure, hence these do not impact the group key(s).
Rene Struik, Certicom Corp.

14. Access Control to the Piconet (1)
December, 2001
Access Control to the Piconet (1)
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 piconet
Admission 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.
Remark
Devices 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 and
a joining device only).
Rene Struik, Certicom Corp.

15. Access Control to the Piconet (2)
December, 2001
Access Control to the Piconet (2)
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.
‘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.
Remark (generalization of threat scenario)
This property also holds in other settings where a key-generating party does not share complete and
authentic information on the composition of the key-sharing group itself with the other members of this
group.
Rene Struik, Certicom Corp.

16. Access Control to the Piconet (3)
December, 2001
Access Control to the Piconet (3)
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).
Solution
Since 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 seems therefore to be too restrictive.
Rene Struik, Certicom Corp.

17. The Need for a Distributed Security Model
December, 2001
The Need for a Distributed Security Model
The centralized security model from Draft D09 seems to be too restrictive, even in the ‘authentic’ mode
of operation.
I. Centralized security model (Mapping of roles to devices as in Draft D09)
The Security Manager role is identified with the current PNC for all devices, hence one has the following:
Concentration of all trust in 1 device:
- each device must trust the same Security Manager (PNC);
- each device must trust each subsequent Security Manager (PNC).
Change of PNC invokes by definition a change of Security Manager:
- potentially expensive re-establishment of keying relationship between devices and the Security
Manager.
At any given moment in time, the PNC must provide each piconet device with complete and authentic
information on the current composition of the piconet membership (in reality: at regular time intervals).
II. Distributed security model (Our proposed mapping of roles to devices)
The Security Manager role is identified with each individual device, hence one has the following:
No reliance on other devices for trust functionality:
- each device need only trust himself as Security Manager.
Change of PNC does not invoke any change of Security Manager.
At any given moment in time, each device must re-authenticate with each of its key sharing parties, to obtain
‘aliveness’ guarantees (in reality: at regular time intervals).
Rene Struik, Certicom Corp.