Title: MAC Distributed Security Proposal
1Project IEEE P802.15 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 Voice1 (905) 501-6083, FAX 1
(905) 507-4230, E-Mailrstruik_at_certicom.com Re
Abstract This document describes elements
of the security architectural framework for the
802.15.3 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 802.15.3 WPAN security. Notice Th
is 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.
2MAC Distributed Security Proposal
- Gregg Rasor, Motorola
- René Struik, Certicom Research
- Scott Vanstone, Certicom Research
3Outline
- IEEE 802.15.3 WPAN Technology
- IEEE 802.15.3 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
4IEEE 802.15.3 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
5IEEE 802.15.3 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.
6Modes 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) - - All message traffic is unsecured (no provisions
for confidentiality or data integrity). - Authentication and encryption.
- - 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) - - All message traffic is secured (provisions for
confidentiality or data integrity).
7Devices 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 - -Enforces security policy.
- Role of portal considered out of scope, since it
deals with communications with outside world.
8Devices 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.
9Devices 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 devices
public key - - (facilitating) the storage of an authentic copy
of the trusted partys 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 partys
root key, either directly or via
cross-certification techniques.) - The role of the external trusted party is
implemented outside the network (CA
functionality).
10Devices 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). There are no other mappings of roles to
devices in effect. (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.
11Security 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).
12Security 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. Securit
y 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.
13Security Policy (3)
I. Effect of security events - change of group
structure (contd) 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 members role as
PNC and as ordinary device have no impact on the
group structure, hence these do not impact the
group key(s).
14Access 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).
15Access 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
16Access 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 others 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
17The 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).