keys wusb security

8/13/2019 Keys WUSB Security

1/37

Wireless USB SecurityJohn Keys

Intel Corporation


2/37

2

AgendaAgenda

Introduction to WUSB Security The Connection Context

Operation Minutiae


3/37

3

IntroductionIntroduction

Security Required No sub bullets, security is required

Mutual Authentication device and hosteach able to authenticate

Protect device as well as host


4/374

How Much Security?How Much Security?

Threat follows value, so whats the value of WUSB traffic?

Basic Security rule: Threat follows value

What is the value of attacking WUSB?

What can be gained from an attack? Notoriety, for the first few known successes

Personal data could be family pictures, but could also be sensitivedata like financials, credit-card info, etc.

Corporate data wired USB is used as an interconnect today

Conclusion: Assume the value is reasonably priceless


5/375

Prevent Common AttacksPrevent Common Attacks

Man In The Middle

Defense: Verification during authentication Replay

Defense: Freshness embedded in messages

Message Modification (bit-flip)Defense: Message Integrity Codes (MIC)

Traffic Analysis

Defense: Strong Cryptography Denial of Service

Defense: Protocol level careful design, Phy level no defense

Social EngineeringDefense: education


6/376

Support Protocol AnalyzersSupport Protocol Analyzers

We need analyzers to sort out themess during initial development

How to analyze encrypted traffic?

Secure but dont encrypt commontrigger information:

Addressing Handshakes

Packet Type


7/377

WUSB Encryption - CCMWUSB Encryption - CCM

Counter with CBC-MAC

Uses AES-128 encryption logic

AES-128 decryption logic not used

Implemented in Hardware

Must process packets in real-time

Transmitter must re-encrypt retries

Provides Integrity as well as Encryption

Integrity proof that message hasnt been tampered withproof that message really came from sender

Produces 64-bit MIC for the entire packet

Can provide integrity over entire packet but encryptonly the data payload


8/378

AgendaAgenda


Operation Minutiae


9/379

The Connection Context (CC)The Connection Context (CC)

How WUSB hosts and devicesremember each other

Contains the Context that will be usedto establish a secure connection:

A globally unique ID for the host

A host-unique ID for the device

A 128-bit Symmetric CCM key used

as the master key


10/3710

CC DefinitionCC Definition

Offset Name Size Description

0

16

32

Connection Host ID(CHID)

16 bytes Unique Host ID. The device uses this ID to locatethe hosts Wireless USB Channel.

Connection Device ID(CDID)

16 bytes Unique Device ID. This ID uniquely identifies thedevice to the host specified by CHID. It is notguaranteed to be unique across multiple hosts.

Connection Key (CK) 16 bytes The key used to establish reconnections using thiscontext. This key should be changed periodically.

Connection Context


11/37

11

CC DeliveryCC Delivery

Set Connection Context

Allows host to give new/updated CC to device

CC is always protected wire or encryption

Host can use to revoke CC by zeroing CHIDor CDID field

bmRequestType bRequest wValue wIndex wLength Data

00000000B SET_CONNECTION Zero Zero 48 ConnectionContext


12/37

12

AgendaAgenda


Operation Minutiae


13/37

13

OperationOperation

Operational encryption keys Establishing a connection

Making the connection secure Keeping the connection secure


14/37

14

PTK (Pair-wise Temporal Key)PTK (Pair-wise Temporal Key)

128-bit symmetric CCM key Derived by Host and Device from 4-wayHandshake protocol

Used for encryption of all data packetsfrom host and all packets from device

Never sent over the medium


15/37

15

GTK (Group Temporal Key)GTK (Group Temporal Key)

128-bit Symmetric CCM key Distributed to device immediately after4-way Handshake and later as needed

Used by host to secure MMC packets

Used by device to authenticateMMC packets

Device never encrypts with GTK


16/37

16

Connection Request & ResponseConnection Request & Response

Device powers up and scans for host

Looks for MMC packets with known CHID(contained in Host ID IE)

When located, device sends a DN_Connectpacket to request connection with host includes CDID

Host responds by adding a Connect ACK IEto MMCs supplies device with uniquedevice address

Host begins sending MMCs with commandstargeted to device at unique address


17/37

17

4-way Handshake4-way Handshake

Classic 4-way handshake derives keysand authenticates both parties

Uses 3 handshake requests to

accomplish 4-way handshake

Can be initiated by host at anytime


18/37

18

4-way Handshake

Message Data

4-way Handshake

Message Data

Defines which stage this data payload isassociated with. Valid values are:

The base name for the PTK to be derivedNumber3tTKID2

Number1bStatus1

Number1bMessageNumber0

Handshake33

Handshake22

Handshake11

Aborted, TKID conflict3

Aborted, handshake in progress withsame master key

2

Aborted per security policy1

Normal, the handshake sequence

proceeds

0

DescriptionValueSizeFieldOffs

et

5 bReserved 1 Constant Reserved for future use; Must be zero

6 CDID 16 Number The devices CDID. Note, this corresponds tothe MKID used by the MAC Layer, seereference [3]

22 Nonce 16 NONCE The Nonce being exchanged for thehandshake

88 MIC 8 Number The MIC calculated over the previous fields ofthis packet payload. The value of this field forHandshake1 is zero.


19/37

19

4-way Handshake Commands4-way Handshake Commands

bmRequestType bRequest wValue wIndex wLength Data

00000000B SET_HANDSHAKE HandshakeNumber

Zero 46 Handshake Data

Handshake 1 host creates h-nonce and TKID and sendsto device

Device creates d-nonce and derives PTK from both d-nonceand h-nonce

Handshake 2- device returns d-nonce and uses key-derivation resultto compute MIC over handshake data

Host derives PTK from d-nonce and h-nonce, checks deviceMIC calculation

Handshake 3 Host creates MIC-protected handhshake dataand sends to device

Device verifies MIC and installs if successful

(The classic Handshake-4 is accomplished by the status phase of theHandshake 3 control request)


20/37

20

Psuedo-Random Function (PRF)Psuedo-Random Function (PRF)

Re-uses CCMs CBC-MAC mode tocreate 64-bit pseudo-random numbers

Number created by computing MIC over

unique input

Results concatenated to form longer

random numbers, i.e. 128-bit or 256-bit


21/37

21

PRF DefinitionPRF Definition

RN_ARBLENGTH // returns key of arbitrary lengthPRF(KEY k, // CCM key

NONCE n, // CCM nonceTEXT a, // text that defines use of PRFDATA b, // data to calculate MIC overINT blen, // length of MIC dataINT len // key length requested in bits

);

RN64 PRF_64(k,n,a,b,blen)


22/37

22

Deriving a PTKDeriving a PTK

PTK Derivation uses PRF_256

PTK Parameters:K Connection Key (CK)N - b11-12=host ID, b9-10=device ID, b6-8=TKID,b0-5=zero

A Pair-wise keys

B Hnonce Concatenated with DnonceBlen - 32

Result split into two keys, PTK and KCK :KCK = returnValueBytes[0-15]PTK = returnValueBytes[16-31]

KCK used only for MIC calculation of 4-way handshakemessages discarded after completion of

Handshake3 message


23/37

23

MIC Calculation for HandshakeMIC Calculation for Handshake

MIC Calculation uses PRF_64

PTK Parameters:

K KCK from PTK derivation

N - b11-12=host ID, b9-10=device ID, b6-8=TKID,b0-5=zeroA out-of-bandMICB Handshake Data minus MIC fieldBlen sizeof(Handhake Data) sizeof(MIC)

Result copied into MIC field of handshake data


24/37

24

Getting an Initial GTKGetting an Initial GTK

Initial GTK delivered immediately following4-way handshake

GTK delivered in Key Descriptor using Set

Key control request

Device must latch SFC (secure frame counter)

of MMC containing SetKey request. This SFCvalue is used to initialize GTK replay counter.


25/37

25

Updating the Current GTKUpdating the Current GTK

Host must update GTK periodically or whengroup membership changes

Host distributes new GTK with incremented

key index Device installs new GTK deletes old GTK

when it sees host using new GTK

Always delivered encrypted with PTK

For subsequent GTKs, replay counter is

initialized to zero


26/37

26

Trust TimeoutTrust Timeout

In security work, unused keys become

un-trusted keys: Other party may have been compromised

Other party may have given out key

In WUSB, if keys are idle for longer thanTrust Timemout, the connection must bere-established:

The device can make a reconnection request

and/or

The host can initiate a new 4-wayhandshake sequence


27/37

27

AgendaAgenda

Introduction to WUSB Security

The Connection Context

Operation Minutiae


28/37

28

Replay PreventionReplay Prevention

Protection against replay in addition to CCM

Each secured packet contains a 48-bit SecureFrame Number (SFN)

Every transmitter keeps a 48-bit SecureFrame Counter (SFC) for each key used tosecure packet. Counter is incremented every

time a packet is secured Receivers keep a Replay Counter (RC) for

every key


29/37

29

Replay Prevention (cont)Replay Prevention (cont)

When a packet is secured, the transmitter

increments its SFC and copies this value intothe SFN of the packet. The SFN becomes partof the nonce used to secure the packet

When receiving a packet, the receiver firstinsures that the SFN of the new packet is >the current RC for that key

Greater than packet ok, SFN copied to RC Less than or equal replay attack,

packet discarded


30/37

30

Proper Packet Reception OrderProper Packet Reception Order

Validate FCS this step is performed prior to

validating security elements Validate the received frame has the correct

secure frame settings as per MAC Layer rules

Validate the MIC for the received frame

Check for replay attacks

Update RC only if the previous checks haveall passed

Packets that fail security checks are discarded


31/37

31

PRF ImplementationPRF Implementation

CCM-MAC-FUNCTION(K, N, A, B, Blen)

For mat Bl ock B0 f r om l ( m) = 0, N, and f l ags = 0x59

For mat Bl ock B1 f r om A and l ( a) = Bl en + 14For mat addi t i onal bl ocks f r om B as speci f i ed by Blen

(note, last block is padded with zero as needed)

For mat bl ock A0 f r om f l ags = 0x01, N and Count er = 0

return encrypted MIC

The Bx blocks are processed in CBC-Counter mode to generate the MIC value for the blocks.The MIC is then encrypted with the keystream generated with the A0 block.

PRF(K, N, A, B, Blen, Len)

r esul t = empt y

f or ( i = 0; i < ( Len + 63) / 64; i ++, N. SFN++)

r esul t | | = CCM- MAC- FUNCTI ON( K, N, A, B, Bl en)// where ||= signifies concatenation)

return r esul t


32/37

32

CCM NonceCCM Nonce

Offset Field Size Description

0 SFN 6 The secure frame number value

associated with this message.

6 TKID 3 The Temporal Key ID valuenames the key used toencrypt/decrypt this message.

9 DestAddr 2 The address of the destinationdevice.

11 SrcAddr 2 The address of the source device.

Used in every encryption and decryption operation

Provides uniqueness across time/space for each

use of a CCM key


33/37

33

Counter-Mode Bn BlocksCounter-Mode Bn Blocks

How data is formed for MIC calculation

B0 block special case:

Offset Field Size Value Description

0 Flags 1 59H As per CCM specification

1 CCM Nonce 13 variable The CCM Nonce as described above.

14 MSB_l(m) 1 variable The most significant byte of the l(m)value.

15 LSB_l(m) 1 variable The least significant byte of the l(m)value.


34/37

34

Counter-Mode B1 BlockCounter-Mode B1 Block

B1 block also special case:


0 MSB_l(a) 1 variable The most significant byte of the l(a)value.

1 LSB_l(a) 1 variable The least significant byte of the l(a)

value.

2 MAC Header 10 variable The entire MAC header in transmissionorder

12 EO 2 variable The Encryption Offset component of the

MAC header.14 Security

Reserved1 variable The Security Reserved component of

the MAC header.

15 Padding 1 0 This byte is only used to pad the block.

It is not part of the message and nevertransmitted.


35/37

35

Counter-Mode Bn BlockCounter-Mode Bn Block

Additional blocks are formed out of

packet data in transmission orderAdditional blocks are formed as needed

The last block is padded with zero

Important to note: the resultant MIC isalways encrypted with the keystreamthat results from block A

0


36/37

36

Encryption An BlocksEncryption An Blocks

An blocks generate the key stream used for

encryption/decryption(note: CCM encyrption/decryption is XOR of packet data withkey stream data)

As noted, A0

is used for MIC, packet data uses A1

An


0 Flags 1 01H As per CCM specification

1 CCM Nonce 13 variable The CCM Nonce as described above.

14 MSB Counter i 1 variable The most significant byte of Counter i.

15 LSB_Counter i 1 variable The least significant byte of Counter i.


37/37

37

WUSB CCM Test VectorsWUSB CCM Test Vectors

Integration of crypto logic can be challenging

For some, a swirling world of little-endiansand MSBs

WUSB Spec has CCM Test Vectors regardless of your MSBs and your LSBs, yourimplementation must match these vectors!

If you match these vectors, youre cryptowill interoperate

keys wusb security

Documents