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 [phone], FAX 1
[phone], 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
Grand Overview
Wireless Everywhere - From the Office to the
Street to Your Home, Automobile, or Person -
Wherever You May Be in the World (and Beyond)
Satellite
Neighborhood
In-Building
Personal
Pico
Micro
Global
Macro
4
WLAN/WPAN Market Opportunities
5
Automotive Use Case (1)

• Three identical cars, each with an active
  802.15.3 piconet
• Based on their security model, they dont
  associate with each other.
• Owners use interface on their PDA to unlock their
  car and provide access to information while in
  their car.
• Passenger in a car may also have their own PDA in
  a friends car that they can use to set
  environmental controls or provide entertainment.
• PNC in vehicle must be able to authenticate
  devices for different purposes
• Owner access provides full control
• Friend access provides limited access
• When all three owners pull out their PDAs to
  unlock their car, all cars respond quickly to
  only their owners.
• When a friend gets in a car he does not own, the
  owner allows him limited access so they can
  listen to the friends MP3 files on the PDA.

6
Automotive Use Case (2)

• Three identical cars, each with an active
  802.15.3 piconet
• Based on their security model, they dont
  associate with each other.
• When car drives into a gas station, the PNC in
  the car associates with the gas station PNC as a
  child piconet to allow limited information
  content to flow between the gas station and the
  vehicle.
• Gas station piconet looks different than another
  car piconet?
• Operator may need to select which pump from his
  PDA or dash.
• When car drives into owners garage, the PNC in
  the car associates with the home PNC as a child
  piconet with the ability to have full access to
  home systems in order to check security status of
  home for owner.
• Car and garage must have some mutual
  authentication information.
• Car may assume owner (driver) authentication from
  owners PDA.
• Owner may have multiple cars which are in garage
  at same time.
• There may be multiple owners of a car (husband,
  wife, children)

7
Automotive Use Case (3)

• Three identical cars, each with an active
  802.15.3 piconet
• Based on their security model, they dont
  associate with each other.
• When car drives into dealer service facility, the
  cars piconet associates as a child piconet with
  the dealers system or employees
• Employees have device that allows them to operate
  vehicle while in the care of the dealer.
• Dealer diagnostic systems have access to vehicle
  information that may not be available to the car
  owner.
• Owner private information and resources in the
  car not available to dealer.
• When car is dropped off with valet parking, the
  valet can be given a token that allows the car to
  be parked, secured, and located later.
• Token may be transferred from owners PDA
• Limited services available in the car while under
  control of valet
• Owner can retrieve history of car operation while
  under control of the valet.
• Valet token unique to each car in the parking
  facility.

8
Home use cases
Home gateway ltPNCgt
Phone
PDA
TV (parents)
Desktop Computer
AV AmpliTuner
TV (kids)
MP3
VCR/ DVD
Printer
Laptop computer
N-Speakers
Clouds indicate dynamic devices
9
Wireless Multimedia Applications

• Basic Requirement
• Enable the high-speed, wireless interconnection
  of consumer devices to support the transfer of
  large multi-media data files and high speed,
  real-time data streams.
• Typical Applications
• Video distribution from set-top boxes to remote
• TV sets, VCR to portable screen, computer to
  projector, etc.
• In-home Internet connectivity from set-top boxes
  to
• personal devices and computers.
• Wireless video camera linkages.
• Wireless Audio and Video distribution for
• Home Theater Systems.

10
Wireless Multimedia Applications

• Applications (continued)
• Low cost, high speed networking
• Communications devices (cell phones, etc.) to
  peripherals.
• Computer to computer.
• Computer to printer.
• Digital still camera to printer.
• Appliance to appliance.
• Point of sale kiosk.
• ATMs

11
4G Wireless Applications
3rd Party Applications
Network Operator Applications
HOT SPOT
WLAN/PAN 802.15.3
Internet
SNAP
Digital Cable
IP
IP Core
GPRS WCDMA
Corporate
PSTN
802.11
Wireless Office
TDMA GSM CDMA
12
Messaging Hot Spots
Internet
Gas Stations
Homes
ISP Broadband Backbone
Packet Cable
Community Buildings / Airports
Hotels
Enterprises
Coffee Shops / Malls
13
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
• Protection of Messages
• Mutual Authenticated Key Agreement Protocol
• Mutual Symmetric Entity Authentication Protocol
• Combined Key Agreement and Entity Authentication
  Protocol
• ECC-Based Public Key Cryptography

14
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

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

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

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

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

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

20
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.
21
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).
22
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.
23
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).
24
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).
25
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

26
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

27
The Need for a Distributed Security Model
The centralized security model from Draft D09 is
completely unacceptable from a security
perspective, 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).

28
Protection of Messages (1)

• Unsecured transport
• Initial set-up none
• Message A ? B msg
• Security services none
• Secure transport
• Initial set-up Establishment of shared data
  encryption key key between A and B
• Message A ? B Encryptkey (msg)
• Security services Secure transfer of message msg
• Authentic transport
• Initial set-up Establishment of shared data
  integrity key key between A and B
• Message A ? B msg, hashkey (msg)
• Security services Authentic transfer of message
  msg
• Secure and authentic transport
• Initial set-up Establishment of shared
  encryption key key1 between A and B
• Establishment of shared data integrity key
  key2 between A and B
• Message A ? B msg1 Encryptkey1 (msg2
  hashkey2 (msg1 msg2))

29
Protection of Messages (2)

• Assumptions on capabilities
• Sender A should be able to encrypt messages and
  to compute keyed hash functions hereover.
• Recipient B should be able to decrypt messages
  and to verify keyed hash values.
• Header info can be bound to message to be
  authenticated if needed, e.g.,
• Algorithm Ids specifies the particular
  cryptographic primitives used
• Key Ids prevents use of improper data keys
• Sequence No. prevents undetected reordering (or
  replay) of message frames
• Message length prevents misalignment in
  decryption and verification process.
• Example 1 (secure and authentic key transfer)
• Key originator A authentic
• Key-sharing group G (this includes A and
  B) authentic (implicit if peer-to-peer only)
• Key Id 0x314159 authentic
• Key usage data encryption authentic
• Key mode pre-operational authentic
• Piconet Id 0x112358 authentic (sent in
  beacon)
• Key recipient B authentic (optional)
• Id key encryption key KAB(1) (shared between A
  and B) authentic

30
Protection of Messages (3)
Example 2 (command transfer between ordinary
device and PNC) Unsecured transfer -Association/d
isassociation commands -Cryptographic
protocol messages (including entity
authentication, authenticated key
agreement, key transfer, and challenge response
protocols) -The election process of a new
PNC. Authentic transfer All other commands that
affect the allocation of scarce resources in the
piconet (if piconet is operating in one of the
secure modes of operation).
31
Mutual Public Key Authenticated Key Agreement
Protocol (1)

• Initial Set-up
• Publication of system parameters of public key
  systems A and B
• Publication of keyed hash function hk
• Distribution of authentic public keys PA and PB
• Constraints
• RNDA and RNDB random
• SA and SB private to Party A, resp. Party B
• Public keys PA and PB valid and authentic during
  execution of protocol
• Security Services
• Key agreement on the shared key K
• Mutual entity authentication of A and B
• Mutual explicit key authentication (if hk is
  secure)
• Known-key resilience
• Perfect forward secrecy

secret and authentic channel
32
Mutual Public Key Authenticated Key Agreement
Protocol (2)
K f(GA,RNDB, PA,SB) f(RNDA,GB, SA, PB)
Public-private key pair A (PA,SA)
Public-private key pair B (PB,SB) FA, FB
(trapdoor) one-way functions of A,
resp. B
(1) compute hash over the string (GA GB IdB)
using keyed hash function hK with key K, to
yield string hashverifyA (2) verify
whether hashAhashverifyA
hashA, IdB
33
Mutual Symmetric Key Entity Authentication
Protocol (1)

• Initial Set-up
• Publication of keyed hash function hk
• Establishment of shared symmetric key KAB
  between A and B
• Constraints
• RNDA and RNDB random
• KAB secret to Party A, resp. Party B
• Security Services
• Mutual entity authentication of A and B

34
Mutual Symmetric Key Entity Authentication
Protocol (2)
(1) compute hash over the string (GA GB IdB)
using keyed hash function hK with key K, to
yield string hashverifyA (2) verify
whether hashAhashverifyA
hashA, IdB
35
Combined Key Agreement and Entity Authentication
Protocol

• Implementation issues
• Efficient implementation possible (for public
  key system)
• No usage constraints
• Channel should be simplex channel both ways
• Flexibility
• No restrictions between cryptographic building
  blocks (in particular, good fit for ECC)
• Full scalability (PKI-like)
• Survivability, since no status information
  maintained
• Alternative uses using same implementation
• Mutual Public Key Authenticated Key Agreement
  Protocol
• Unilateral Public Key Authenticated Key
  Agreement Protocol
• One-Pass Public Key Authenticated Key Agreement
  Protocol (in DL Scenario)
• Mutual Symmetric Key Entity Authentication
  Protocol
• Unilateral Symmetric Key Entity Authentication
  Protocol
• Example (uses of protocols in WPAN setting)
• Authenticated association Mutual Public Key
  Authenticated Key Agreement Protocol

36
ECC-Based Public Key Cryptography (1)

• Cipher suite selection criteria
• Security
• Sufficient scrutiny by the cryptographic
  community and acceptance hereby
• Quantification of security level provided
• Endorsement by standardization bodies and
  government agencies
• Performance metrics on constrained devices
• Speed
• Footprint
• Battery drain
• IP Issues

37
ECC-Based Public Key Cryptography (2)

• Key size comparison
• Block cipher Skipjack 3DES AES-small AES-medium
  AES-high
• Bit security 80 112 128 192
  256
• ECC size (prime) 192 224
  256 384
  512
• ECC size (binary) 163 233
  289 409
  571
• Sources
• -ANSI X9.30-1997
• -FIPS Pub 186-2, Appendix 6
• ECC curve K-283 conforms with ANSI X9.62, IEEE
  P1363, WAP
• recommended by ANSI X9.63, echeck,
  IPSec, NIST
• MQV Key Agreement will become FIPS this year
• Implicit Certificates
• Rigorous security proofs in random oracle model
  (Brown, Johnson, Vanstone, Financial Crypto 2001)
• Used by Canada Post and US Postal Service