MAC Distributed Security Proposal - PowerPoint PPT Presentation

1 / 17
About This Presentation
Title:

MAC Distributed Security Proposal

Description:

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) – PowerPoint PPT presentation

Number of Views:52
Avg rating:3.0/5.0
Slides: 18
Provided by: ReneS7
Learn more at: https://grouper.ieee.org
Category:

less

Transcript and Presenter's Notes

Title: MAC Distributed Security Proposal


1
Project 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.
2
MAC Distributed Security Proposal
  • Gregg Rasor, Motorola
  • RenĂ© Struik, Certicom Research
  • Scott Vanstone, Certicom Research

3
Outline
  • 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

4
IEEE 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

5
IEEE 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.

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

7
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
  • -Enforces security policy.
  • Role of portal considered out of scope, since it
    deals with communications with outside world.

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

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

10
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). 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.
11
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).
12
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. 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.
13
Security 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).
14
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).
15
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

16
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 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

17
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).
Write a Comment
User Comments (0)
About PowerShow.com