doc.: ieee 802.15-02/114r2 submission february, 2002 rene struik, certicom corp.slide 1 project:...

February, 2002

Rene Struik, Certicom Corp.Slide 1

doc.: IEEE 802.15-02/114r2

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 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) 501-6083], FAX: [+1 (905) 507-4230], E-Mail:[[email protected]]

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


doc.: IEEE 802.15-02/114r2

Submission

MAC Distributed Security Proposal

Gregg Rasor, Motorola

René Struik, Certicom Research

Scott Vanstone, Certicom Research

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

Wireless Everywhere - From the Office to the Street Wireless Everywhere - From the Office to the Street to Your Home, Automobile, or Person - Wherever to Your Home, Automobile, or Person - Wherever

You May Be in the World (and Beyond)You May Be in the World (and Beyond)

Grand Overview

In-BuildingIn-Building

NeighborhoodNeighborhood

PersonalPersonal

SatelliteSatellite

Wide AreaWide Area

BeyondBeyond

PicoPicoMicroMicroGlobalGlobal MacroMacro

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

WLAN/WPAN Market Opportunities

Multi-User Gaming

Local Connection for MobileWireless Devices

• Wireless phone• Automobile

Entertainment Distribution

• Streaming audio

• In-home distribution

Wireless PC Access• Shared internet access• Shared peripherals

Long Term

(2 years +)

Intermediate Term

(12-24 months)

Near Term

(0-12 months)

HomePNA HomeRF 802.11b BlueTooth HomePlug 802.11a/802.15.3


Streaming audio/video

In-home distribution

•

•

Multi-User Gaming Multi-User Gaming

Local Connection for MobileWireless Devices• Messaging device

Local Connection for MobileWireless Devices• Messaging device

• Wireless phone• Messaging device




February, 2002


doc.: IEEE 802.15-02/114r2

Submission

• Three identical cars, each with an active 802.15.3 piconet

– Based on their security model, they don’t 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.

Automotive Use Case (1)

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

• Three identical cars, each with an active 802.15.3 piconet– Based on their security model, they don’t 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 owner’s 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 owner’s PDA.– Owner may have multiple cars which are in garage at same time.– There may be multiple owners of a car (husband, wife, children)


February, 2002


doc.: IEEE 802.15-02/114r2

Submission

• Three identical cars, each with an active 802.15.3 piconet– Based on their security model, they don’t associate with each other.

• When car drives into dealer service facility, the car’s piconet associates as a child piconet with the dealer’s 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.


February, 2002


doc.: IEEE 802.15-02/114r2

Submission

Home use cases

Home gateway<PNC>

Home gateway<PNC>

TV(kids)TV

(kids)

TV(parents)

TV(parents)

VCR/DVDVCR/DVD

N-SpeakersN-Speakers

AV AmpliTunerAV AmpliTuner

PhonePhone PDAPDA

MP3

MP3

PrinterPrinter

DesktopComputerDesktop

Computer

Laptop computerLaptop

computer

Clouds indicatedynamic devices

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

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.

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

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

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

Internet

802.11

Corporate

IP

IP Core

PSTN

Wireless Office

SNAPSNAP

“HOT SPOT”Network Operator Applications

3rd PartyApplications

TDMAGSM

CDMA

V

WLAN/PAN802.15.3

GPRSWCDMA

DigitalCable

ReFLEXMobitex

4G Wireless Applications

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

InternetGas Stations

Homes

Coffee Shops / Malls

Community Buildings /Airports Enterprises

Hotels

ISP Broadband Backbone

PacketCable

Messaging “Hot Spots”

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

• 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

Outline

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

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

IEEE 802.15.3 WPAN Technology

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

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

IEEE 802.15.3 WPAN Security Objectives

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

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

Modes of Operation of the Piconet

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

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.

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

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

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

‘Permanent’ mappings of roles to devicesThe 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.

Devices and their Roles (3)

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

Other mappings of roles to devicesThe actual mapping of the PNC role to a device and that of the Security Manager role to a device might change over time.

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

Devices and their Roles (4)

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

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 events1. 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 thoughtof as to occur subsequently (in any order).

Security Policy (1)

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

I. Effect of security events - change of group structureScenario where information shared between group members is secured via a common (symmetric) group key.

Security invariantAt 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 ruleChanges to the group structure shall invoke a change to the common group keys.

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

Security Policy (2)

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

I. Effect of security events - change of group structure (cont’d)

Key storage invariantAt any given moment of time, devices maintain symmetric keying relationships with groups to which they belong only.

Key storage ruleChanges 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).

RationaleThis 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 roleScenario 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).

Security Policy (3)

February, 2002


doc.: IEEE 802.15-02/114r2

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


doc.: IEEE 802.15-02/114r2

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.• ‘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 thisgroup.


February, 2002


doc.: IEEE 802.15-02/114r2

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.


February, 2002


doc.: IEEE 802.15-02/114r2

Submission

The centralized security model from Draft D09 is completely unacceptable from a security perspective, even in the ‘authentic’ mode of operation.

The Need for a Distributed Security Model

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

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

Protection of Messages (1)

Unsecured transport: 1. Initial set-up: none 2. Message: A B: msg3. Security services: none

Secure transport:1. Initial set-up: Establishment of shared data encryption key key between A

and B 2. Message: A B: Encryptkey (msg)3. Security services: Secure transfer of message msg

Authentic transport: 1. Initial set-up: Establishment of shared data integrity key key between A and

B 2. Message: A B: msg, hashkey (msg)3. Security services: Authentic transfer of message msg

Secure and authentic transport: 1. Initial set-up: Establishment of shared encryption key key1 between A and

B Establishment of shared data integrity key key2 between A

and B 2. Message: A B: msg1 || Encryptkey1 (msg2 || hashkey2 (msg1 || msg2))3. Security services: Authentic transfer of messages msg1 and msg2

Secure transfer of message msg2

Encryptkey: encryption functionhashkey: keyed hash function

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

Protection of Messages (2) Assumptions on capabilities:1. Sender A should be able to encrypt messages and to compute keyed hash functions hereover.2. 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., 1. Algorithm Ids: specifies the particular cryptographic primitives used;2. Key Ids: prevents use of improper data keys; 3. Sequence No.: prevents undetected reordering (or replay) of message frames;4. 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 authenticKey usage: data encryption authenticKey mode: pre-operational authenticPiconet Id: 0x112358 authentic (sent in ‘beacon’)Key recipient: B authentic (optional)Id key encryption key KAB

(1) (shared between A and B) authentic

Id key integrity key KAB(2)(shared between A and B) authentic

Key value: k secure and authentic

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

Protection of Messages (3) Example 2 (command transfer between ordinary device and PNC)Unsecured transfer: -Association/disassociation 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).

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

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• No key control by either party

A B

authentic channel

PB

PA

A BKAB

secret and authentic channel

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

Mutual Public Key Authenticated Key Agreement Protocol (2)GA

hashB, IdA, GB

(1) generate random number RNDA

(2) compute ‘exponent’ GA= FA (RNDA)

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) generate random number RNDB

(2) compute ‘exponent’ GB= FB (RNDB)

(4) compute hash over the string (GB ||GA ||IdA) using keyed hash function hK with key K, to yield string hashB

(3) compute key K=f(GA,RNDB, PA,SB)

hashA, IdB

(1) compute key K=f(RNDA,,GB SA,PB)

(2) compute hash over the string (GB||GA ||IdA)

using keyed hash function hK with key K, to yield string hashverifyB

(3) verify whether hashB=hashverifyB

(4) compute hash over the string (GA||GB

||IdB) using keyed hash function hK with key K, to yield string hashA

(1) compute hash over the string (GA ||GB ||IdB)

using keyed hash function hK with key K, to yield string hashverifyA

(2) verify whether hashA=hashverifyA

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

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

authentic channel

A BIdB

IdA

A BKAB

secret and authentic channel

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

Mutual Symmetric Key Entity Authentication Protocol (2)GA

hashB, IdA, GB

(1)

(2) generate random ‘exponent’ GA

(1)

(2) generate random ‘exponent’ GB

(4) compute hash over the string (GB ||GA ||IdA) using keyed hash function hK with key K, to yield string hashB

(3) [retrieve shared key K]

hashA, IdB

(1) [retrieve shared key K]

(2) compute hash over the string (GB||GA ||IdA)

using keyed hash function hK with key K, to yield string hashverifyB

(3) verify whether hashB=hashverifyB

(4) compute hash over the string (GA||GB

||IdB) using keyed hash function hK with key K, to yield string hashA

(1) compute hash over the string (GA ||GB ||IdB)

using keyed hash function hK with key K, to yield string hashverifyA

(2) verify whether hashA=hashverifyA

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

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• ‘Heartbeat’ functionality: Unilateral or Mutual Symmetric Key Entity Authentication Protocol

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

ECC-Based Public Key Cryptography (1)

Cipher suite selection criteriaSecurity• Sufficient scrutiny by the cryptographic community and acceptance hereby• Quantification of security level provided• Endorsement by standardization bodies and government agenciesPerformance metrics on constrained devices• Speed• Footprint• Battery drainIP Issues

February, 2002


doc.: IEEE 802.15-02/114r2

Submission

ECC-Based Public Key Cryptography (2)

Key size comparison

Block cipher Skipjack 3DES AES-small AES-medium AES-highBit security 80 112 128 192 256ECC size (prime) 192 224 256 384 512ECC 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

Numerous deployments of ECC certificates

doc.: ieee 802.15-02/114r2 submission february, 2002 rene struik, certicom corp.slide 1 project:...

Documents