1 February, 2002 doc:.: 802.15-02/106r0 Daniel V. Bailey, Ari Singer, NTRU 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

11

February, 2002 doc:.: 802.15-02/106r0

Daniel V. Bailey, Ari Singer, NTRU

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: [Overview of NTRU Security Suite]Date Submitted: [February 22, 2002]Source: [Daniel V. Bailey, Product Manager for Wireless Networks and Ari Singer, Principal Engineer] Company [NTRU]Address [5 Burlington Woods, Burlington, MA 01803]Voice:[(781) 418-2500], FAX: [(781) 418-2507], E-Mail:[[email protected]]

Re: [Draft P802.15.3/D09, P802.15-02-074r1 802.15.3 Call For Proposals for a Security Suite]

Abstract: [This presentation gives an overview of NTRU’s proposal for security suite for the 802.15.3 draft standard.]

Purpose: [To familiarize the working group with the NTRU proposed security suite.]

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.

22

February, 2002 doc:.: 802.15-02/106r0


Agenda

• Use Cases

• Threat Model

• Trust Model

• Why Public-Key?

• How Will This Work?

33

February, 2002 doc:.: 802.15-02/106r0


• Let’s assume I live in a free-standing house, far enough away from neighbors -- lots of compensating controls

• I unpack everything, turn it on.– A device with a rich user interface (TV, Receiver) becomes PNC– PNC prompts for enrollment mode: open, closed, prompt

• Or open as the default when you take it out of the box

– I choose open, so the PNC trusts every device it hears for the next (say) 30 seconds

– Each device has an and open/closed and “open acceptance/require intervention” switch. I choose open and open acceptance

• Open acceptance trusts any PNC• Require intervention requires some device-specific user action

• All devices associate and authenticate automatically.• Afterward, I set mobile devices to “require intervention” to keep them

from associating to other PNCs without my permission• Requires confidentiality and access control

Home Entertainment Center

Use Cases

44

February, 2002 doc:.: 802.15-02/106r0


• Now I’m taking my projector and laptop on the road• I’m away from home, so more wary about other devices

– A device with a rich user interface (laptop) becomes PNC– PNC prompts for enrollment mode: open, closed, or prompt– I choose prompt, and set my laptop’s “require intervention” switch– Projector has an “open acceptance/require intervention” switch. I choose require

intervention

• Projector attempts secure association with Laptop– Both Projector and Laptop display both of their 48-bit MAC addresses and

hashes of their public keys– I see that they match and press Accept on both

• I close enrollment on the PNC– Any device can still associate, but no new devices can authenticate

• Confidentiality, integrity, and access control needed

Wireless Portable Projector/Laptop

Use Cases

55

February, 2002 doc:.: 802.15-02/106r0


• Now I’m taking my Tablet PC to Starbucks• For only 99 cents, I can watch transient video on demand

– News, weather, sports. No DRM!– A fixed device in the ceiling is the PNC– PNC is in closed mode: only its DME can add trusted devices– I place my tablet on the cash register, pay, and they exchange public

keys via low-power radio transmission– Cash register forwards ID/pub key to PNC’s DME

• Tablet attempts secure association with hot spot– If I paid, PNC’s DME added my tablet to its trusted list– My tablet displays PNC’s ID, hash of public key, and range. I accept.

• Confidentiality, integrity, and access control needed

Portable LCD Tablet/Hot Spot

Use Cases

66

February, 2002 doc:.: 802.15-02/106r0


Agenda

• Use Cases

• Threat Model

• Trust Model

• Why Public-Key?


77

February, 2002 doc:.: 802.15-02/106r0


• You can NEVER thwart EVERY threat.• So we identify the most troubling threats and thwart those• Third-party passive attacks – meet Ophelia the Opponent

– Ophelia wants to mount attacks by merely listening to the radio traffic– WEP failed to protect against these

• Third-party active attacks– Ophelia wants to inject messages, forge MAC headers, intercept

messages, replay messages, hijack sessions– 802.1x failed to protect against these

• First-party attacks– Not much we can do, but not that troubling…– If the PNC allows a device into the network, it can read and write

network traffic

Threat Model

Threat Model

88

February, 2002 doc:.: 802.15-02/106r0


• Identity-based attacks– Ophelia pretends to be another device

• Denial of Service– Any device can jam radio transmissions

• Physical attacks– Ophelia can always crack a device open, place probes and read out

keys

• Side-channel attacks– Ophelia can always monitor power, RF emissions, timing, … long

enough to learn enough bits of a key.

Threat Model 2

Use Cases

99

February, 2002 doc:.: 802.15-02/106r0


• The things we most care about are:– Identity-based attacks

– Third-party passive attacks

– Third-party active attacks

• Not coincidentally, these are exactly the attacks that wires traditionally thwart…

Threat Model 3

Use Cases

1010

February, 2002 doc:.: 802.15-02/106r0


Ethernet Threat Model

• What does Ethernet provide?– Only devices I want can join the network

– Only devices I want can read network traffic

– Only devices I want can write network traffic

– …since I’d notice if someone plugged in

• These are our goals!– Authentication and Access Control restrict association

– Encryption provides privacy on transmitted data

– Integrity shows transmitted data wasn’t altered and came from an authenticated device

• Authentication is the building block

1111

February, 2002 doc:.: 802.15-02/106r0


Agenda

• Use Cases

• Threat Model

• Trust Model

• Why Public-Key?


1212

February, 2002 doc:.: 802.15-02/106r0


Trust Model

• Devices presumed to be mutually untrusted• Primary security role of the PNC is to provide strong

authentication and piconet-wide keys to DEVs• Both the PNC and the associating DEV are responsible for:

– validating each other’s public keys• Is this really Device xxx’s public key?

– deciding if the other is a desired partner• Do I want you in my piconet?• Do I want to join this piconet?

• Both must appeal to a trusted third party to answer these questions!

1313

February, 2002 doc:.: 802.15-02/106r0


The Limitations of Classic PKI

• The traditional trusted third party is a Certifying Authority (CA)– Makes signed statements like “At time zzz, ID xxx is the owner of public key yyy”– Answers the question: “Is this statement still valid?”

• Traditional PKI literature focuses on PCs connected to the Internet– We can’t assume the ability to contact remote hosts like Cas– We can’t assume we have a time of day clock

• Can help establish device-key binding– IF all manufacturers agree to trust a common third party, embed certificates, and

ignore revocation and prohibitive cost issues• For another time: why hasn’t PKI lived up to its promise on plugged-in, Internet-

connected PCs?

• Can’t help establish if the other device is a desired partner– A decision that can’t be made at manufacturing time

1414

February, 2002 doc:.: 802.15-02/106r0


The Trusted Third Party in a WPAN

• A WPAN is a PERSONAL area network• We have to trust the user to decide to allow a device to join the

piconet• We can also trust the user to establish a binding between a

device’s identity and its public key– Low-power transmission of public key allows only active (hard!) attacks

• I could transmit my key louder, but the genuine devices couldn’t talk!

– Analog Certificates: printed on a card or the bottom of the device

– User action: Press a button on both devices at once

– Open enrollment: PNC trusts every public key it hears in the next 30 seconds, then “locks down”

– Range: The user confirms the device sending the key is x meters away

1515

February, 2002 doc:.: 802.15-02/106r0


Agenda

• Use Cases

• Threat Model

• Trust Model

• Why Public-Key?


1616

February, 2002 doc:.: 802.15-02/106r0


Why Not Just Use Symmetric-Key Cryptography?

• Key establishment is difficult with an all-symmetric system:– User-entered keys/passwords– Low-power transmission of symmetric key allows for passive (easy!)

attacks• I could use a parabolic dish antenna, obtain the key and just listen

• Messy (secret) key management– Requires either long-term key storage (NVRAM or unique fixed key

burned into all devices) or – New user-assisted key establishment for every association– A device that regularly joins n piconets needs n symmetric keys

• If stored, they add up like web-browser cookies

– If my device talks to your device, your device gets my fixed key• You can control my device from then on or• Read my content from then on!

1717

February, 2002 doc:.: 802.15-02/106r0


Agenda

• Use Cases

• Threat Model

• Trust Model

• Why Public-Key?


1818

February, 2002 doc:.: 802.15-02/106r0


How Will This Work?

• A device may be in one of three states:1. Unassociated, unauthenticated

A device may only issue Class I commands like Associate and may not send data

2. Associated, unauthenticatedA device may only issue Class II or Class III commands like Authenticate-

Request

3. Associated, authenticatedA device may issue any applicable command

• Any command received from a device in excess of its authorization is ignored

• Any data sent or received when group keys are active is rejected unless it is protected by the group keys

1919

February, 2002 doc:.: 802.15-02/106r0


Command Classes

• Class I – Commands that may be sent when the device is not yet associated (e.g. associate)

• Class II – Commands that never require cryptographic protection (e.g. authentication request or distribute info)

• Class III – Commands that require group key cryptographic protection (e.g. New PNC announcement)

• Class IV – Commands that require key management key cryptographic protection (e.g. distribute key request)

2020

February, 2002 doc:.: 802.15-02/106r0


How Does a Device Authenticate to the PNC?

UnauthenticatedState D0.0

Waiting forChallengeState D0.1

CheckingChallengeState D0.2

Waiting forAuthentication

ResponseState D0.3

CheckingAuthentication

ResponseState D0.4

Figure 8 - Successful Authentication Protocol Run

AuthenticationRequest Command

Challenge RequestCommand

ChallengeAccepted and

Response Sent

AuthenticationResponseReceived


RequestState SM0.1

Waiting forChallengeResponse

State SM0.2

CheckingChallengeResponse

State SM0.3

AuthenticationRequest Accepted

and Challenge Sent

Startup ModeState SM0.0 orSecure ModeState SM1.1

Challenge ResponseCommand

DEVICE SECURITY MANAGER

AuthenticationRequest Sent

ChallengeReceived

ChallengeResponseReceived


and Challenge Sent


AuthenticationAccepted and

Response Sent

Authentication ResponseCommand

Secure GroupMembershipState D1.0

AuthenticationResponseAccepted

2121

February, 2002 doc:.: 802.15-02/106r0


How Does a Device Authenticate?

UnauthenticatedState D0.0

Waiting forChallengeState D0.1

D0.2

CheckingChallengeState D0.2

D0

.4 D

0.6

Waiting forAuthentication

ResponseState D0.3


ResponseState D0.4

D0.8

D0.3

D0.5

D0.7

Authentication State DiagramDevice Perspective

Level 0

SendAuthentication

Request

Timeout and FailureSent or Failure

Message Received

ChallengeReceived

ID/Public-keyRejected or Failed

Decryption andFailure Sent Challenge

Accepted andResponse Sent

Timeout and Failure Sentor Failure Message

Received

AuthenticationFailed and Failure

SentAuthenticationResponseReceived

D0.9

Any State

D0.1

ValidDisassociation

Request Sent orReceived

2222

February, 2002 doc:.: 802.15-02/106r0


How Does a PNC Authenticate a Device?



RequestState SM0.1

SM0.1Waiting forChallengeResponse

State SM0.2

SM

0.3

CheckingChallengeResponse

State SM0.3

SM

0.5

SM0.7

SM0.2

SM0.4

SM0.6

Authentication State DiagramSecurity Manager Perspective

Level 0

AuthenticationRequest Received

ID/Public KeyRejected


and Challenge Sent

Timeout or FailureMessage ReceivedChallenge

ResponseReceived

Decryption orAuthentication

Failed and FailureResponse Sent

AuthenticationAccepted and

Response Sent

CriticalSection

2323

February, 2002 doc:.: 802.15-02/106r0


How Does the Device Handle Payload-Protected Data?

• Assumes packets arrive to this process in order!

Any StateCheckingMessage

State DR0.0 DR0.2

DR0.3

Secure Data Reception State DiagramDevice Perspective

Level 0

DR0.1

Secure DataMessage Received

Unknown or Invalid Key orFailed Integrity Check and

Data Rejected

Integrity CheckSuccessful and Data

Accepted

2424

February, 2002 doc:.: 802.15-02/106r0


How Do We Protect the Beacon?

• The beacon includes a Security Session ID (SSID) so devices know which piconet-wide key is in use

• Beacon also includes a Time Token. It’s really a beacon counter to be used in all messages to prevent replay of messages in future superframes.

• We use a message authentication code, or MAC. Let’s call it an integrity code.

• The integrity code prevents an outside attacker from modifying data in the beacon.

Beacon Header

Current SSID

Time Token

Integrity Code

2525

February, 2002 doc:.: 802.15-02/106r0


How Do We Protect Commands?

• 802.1x was broken due to failure to protect commands!• Commands are protected independently from each other.• Commands include the current SSID and time token that were

sent in the protected beacon for group related commands.• Commands also include the counter from the peer relationship

for key management commands.

Command Header

Current SSID

Time Token

Counter IV Encrypted Command Data

Integrity Code

2626

February, 2002 doc:.: 802.15-02/106r0


How Do We Protect Data?

• Data is encrypted using the current group DEK.• Header and data are integrity protected using the current group

DIK.• Data includes the current SSID and time token that were sent in

the protected beacon.

Data Header

Current SSID

Time Token

IV Encrypted Data

Integrity Code

2727

February, 2002 doc:.: 802.15-02/106r0


What Does a Device Need to Know?

• A device has a public/private key pair, installed at provisioning time.

• An authenticated device shares a unique DEK and DIK with the PNC agreed on during the authentication process

• An authenticated device shares a different DEK and DIK with the rest of the piconet.

2828

February, 2002 doc:.: 802.15-02/106r0



• A device keeps a table (access control list) of the other DEVs with which it has a trust relationship

• A simple device only needs one entry: the PNC!• The public key itself need not be stored• The PNC will need storage for each associated DEV• Ideally, we’d like to put this in EEPROM

– When the electricity goes out, I don’t want to have to reintroduce every device to the PNC

Device ID

Hash of Public Key & ID

DEV or SM

Shared Keys & SSID

Sequence Numbers

2929

February, 2002 doc:.: 802.15-02/106r0



• Each device keeps some data about the current group keys

• If the beacon has the same SSID and a greater time token, the time token is updated and the key is valid for that superframe

• If the PNC ID and the PNC ID in the beacon are different, a new device is now PNC and the device attempts to authenticate to the new PNC

PNC ID SSID Shared Keys

Last Trusted Time Token

Valid in this super-frame?

PNC ID in Beacon

3030

February, 2002 doc:.: 802.15-02/106r0


What About PNC Handover?

• We’ve got two options– A device explicitly establishes trust (if it hadn’t already done so) with the

new PNC• Could disrupt the piconet if some devices need user intervention!

– A device trusts the new PNC because the old PNC trusts it• No disruption, but problematic

• Since this is a PERSONAL Area Networking standard, it’s likely the DEV, the old PNC, and the new PNC will be trusting the same user

• So let the user decide! • If I’m facilitating trust for all these devices, I don’t care who the

PNC is. Let it hand off.• If I’m not facilitating this trust, I’d rather my devices ask before

associating to a new PNC.

3131

February, 2002 doc:.: 802.15-02/106r0


Conclusion

• There’s a LOT of information here.• But we can succeed where 802.11 failed!• Documents will be coming for St. Louis