USB Type-C™ Authentication€¦ · USB Developer Days –October 24 –25, 2017 USB Implementers...

USB Developer Days – October 24 – 25, 2017 USB Implementers Forum © 2017

USB Type-C™ Authentication

Stephanie Wallick – Intel

USB Developer Days 2017

Taipei, Taiwan

October 24 – 25, 2017

1

Welcoming Slideshow 1.ppsx



USB Type-C™ Authentication

• Introduction

• Architecture

• Protocol

• Certificates

2


Specification Overview• What USB Type-C Authentication Specification does

• Provides primitives and protocol for one-way authentication• Verify vendor and product are what they claim to be

• Bus-agnostic, but specification provides mapping to USB and USB PD• Authenticates USB Devices, USB PD Sources, USB PD Sinks, and USB PD Cables• Defines optional normative framework – products are not required to support

• What USB Type-C Authentication Specification does not do• Define policy or criteria to accept/reject a product

• Policy defined by user and/or vendor• Not intended to limit interoperability – just weed out “untrusted” devices

• Provide method/criteria for certificate revocation• Define method for telling user that authentication failed

• Important that implementation adds – NO SILENT FAILURES

3


Example Use Cases

4

Desktop authenticates storage driveLaptop authenticates camera used for biometric login

Charger authenticates cable

Policy = Warning to user if charger cannot be authenticated

Policy = “Reject” if drive cannot be authenticated

Policy = Limit charge if cable cannot be authenticated

Phone authenticates charger

Policy = Require alternate login or deny access if camera cannot be authenticated


Cryptographic methods

Use Method References

Certificate format X.509v3 format withDER-encoding

ITU X.509ITU-T X.690

Digital signing of certificates and authentication messages

ECDSA using NIST P256, secp256r1 curve

ANSI X9.62NIST-FIPS-186-4

Hash algorithm SHA256 NIST-FIPS-180-4

Random numbers NIST-compliant PRNG source seeded with a 256-bit fullentropy value

SP800-90ASP800-90B

5

• Specification targets 128-bit security for all cryptographic methods

• Intent is to use widely available and accepted methods


Architectural Overview – Part 1• Authentication Initiator

• Product that initiates authentication

• Typically a USB Host or USB PD Sink

• Authentication Responder• Product that is being authenticated

• Typically a USB Device, USB PD Source, or USB PD Cable

• Must be provisioned with at least one certificate chain

• Each product must have its own unique key

6

Auth Initiator Auth Responder


Architectural Overview – Part 2• Certificate Chains

• Series of concatenated certificates where:• Root certificate is self signed

• Intermediate and/or Leaf certificates are signed by preceding certificate

• Used to verify identity and key ownership

• An Authentication Responder can contain up to 8 certificate chains• First 4 chains are for chains rooted with USB-IF root certificate

• Last 4 chains are vendor specific

• Digests• SHA256 hash of a certificate chain

• Used to identify/cache certificate chains

7


Example Certificate Chain

8

Certificate Chain

Signature

Public Key

Vendor Info

Signature

USB-IF Public Key

USB-IF Info

Signature

ACD

Product Info

Signature

Public Key

Subsidiary InfoVID VID

PIDVID

Public Key

XID

RootHash

RSVD

Length

SHA256

Root 1st Intermediate 2nd Intermediate LeafHeader

USB-IF Private Key

Vendor Private Key

Subsidiary Private Key

Product Private Key


Authentication Initiator Authentication Responder

Example Implementation

9


USB Type-C Cable

Digest Cache

PD3.0 Extended Messages

Authentication Protocol Engine



RNG

Authentication Policy Manager

Cryptography Library

ECDSA SHA256


ECDSA SHA256

Secure Storage

Private Key

X509 Parser

Certificate Chain


USB Type-C Cable

Digest Cache





RNG

Authentication Policy Manager


ECDSA SHA256


ECDSA SHA256

Secure Storage

Private Key

X509 Parser

Certificate Chain


Authentication Messages• Three types of exchanges:

• Get Digests• Returns hash of each certificate chain in Responder

• Allows Initiator to cache certificate chains

• Get Certificate Chain• Returns segment of certificate chain

• Request specifies offset and length of read

• Authentication Challenge• Returns signed message with context info

• Initiator verifies signature to verify authenticity of Responder

• Exchanges can be performed in any order

10

CAUTION: debugging message signature is

difficult, pay close attention to message format


Authentication over USB PD and USB Data

Via USB PD

• Uses PD 3.0 extended messages • Security_Request/Security_Response

• Source/Cable capabilities and certifications are in certificate

• PD-specific timeouts and response times for authentication messages

• Bridge Class device allows USB Host to authenticate a USB PD product

Via USB Data Bus

• Uses standard USB control requests• AUTH_IN/AUTH_OUT

• USB device descriptors are in signed authentication message

• USB-specific timeouts and response times for Authentication messages

11


Certificate Contents• Required x509 attributes

• Distinguished Name • Must be unique - recommend using serial number attribute for uniqueness

• Common Name • Contains one of three string formats with “USB”, VID, PID

• Once declare a VID or PID in certificate chain, it cannot change

• Validity• Recommend using wide time window to maximize interoperability

• Spec does not prohibit other x509 attributes/extensions, but …• USB-IF CA may limit; issue of practicality – can’t support everything

• Max cert size = 512B for intermediate or 640B for leaf

12


USB-IF Extension (ACD)• Required in Leaf Certificates

• Prohibited in all others

• ACD = Additional Certificate Data• OID = 2.23.145.1.2

• Consists of TLV data structures• TLV = formatted product information

• Contents differ for USB PD Source/Sink/Cable and USB Device

13

ISO/ITU-T Joint OID(2)

International Organizations

(23)

USB-IF(145)

Reserved(3n)

ACD Extension(2)

Type-C Authentication(1)

Extended Key Usage(1)

Reserved(2n)

ISO/ITU-T Joint OID(2)

International Organizations

(23)

USB-IF(145)

Type-C Authentication(1)

ACD Extension(2)


Example TLV - Security Description TLV

Offset Field Size Description

0 Type 1 0x05 (SECURITY_DESCRIPTION)

1 Length 1 6 bytes of data (defined below)

2 FIPS/ISO Identifier 1 Indicates certification for NIST-FIPS-140-2 or ISO-19790 security level.Can either put encoding for security level or indicate no certification.

3 Common Criteria Identifier 2 Bitmap encoding Common Criteria information such as Vulnerability Assessment, EAL Level, Protection Profile Encoding, Development Security, Certificate Maintenance, and Certification Year.

5 Security Analysis Identifier 1 Indicates the level of attack resistance that was established outside FIPS or Common Criteria certification.Measured according to JIL/JHAS ratings.

6 IC Vendor 2 Optionally contains the VID of the IC Vendor.

• TLV Required for USB PD and USB – Security certifications are optional

• Contact applicable organization for details on how to obtain security certifications

14


USB-IF Certificate Authority• Certificate application will be available at www.usb.org

• Applicant generates own key pair and CSR

• Application fees TBD

• Certificate Proxy• Vendor can designate 3rd party to apply for/receive vendor certificate

• Allows vendor to delegate maintenance of Intermediate CA to supplier/contractor

• USB-IF issues 1st Intermediate only – no Leaf certificates

15

http://www.usb.org/


USB PD Firmware UpdateStephanie Wallick – Intel

USB Developer Days 2017

Vancouver BC

September 26 – 27, 2017

16




USB PD Firmware

Update

• Overview

• Architecture

• Example Firmware Update Flow

• Pause/Termination

17


Overview• Common method to update firmware in a USB PD-capable device

• Exe: USB Type-C Charger, USB Type-C Alt Mode device

• Designed to thwart installation of compromised firmware• Firmware image includes vendor signature

• Complements existing USB DFU Class implementations• Similar data structures and encodings where possible

• Uses USB PD 3.0 PDFU extended messages• Firmware_Update_Request/Firmware_Update_Response

18


Architecture – Part 1• PDFU Initiator

• Starts firmware update process

• Usually laptop or desktop

• PDFU Responder• Receives firmware update

• Usually PD Sink, Source or Cable

• Architecture varies depending on how firmware images are stored and accessed• See spec for more details

19

Sink / Source Source / Sink

PDFU Initiator PDFU Responder

USB Type-C cable

PDFU Initiator

PD Port Partner

USB Type-C cablePDFU SOP’ Responder

PDFU SOP” Responder

PDFU Responder

Hub Source/SinkUSB Type-C cable

PDFU Initiator

USB

USB data communication USB PD communications


Architecture – Part 2• PDFU Depot

• Collection of one or more firmware images• Spec defines file naming convention for firmware images in PDFU depot• Spec does not define how image is retrieved by responder

• PDFU File Prefix• Used to confirm that firmware image is for PDFU Responder• Based on DFU file suffix• Prepended to firmware image file in PDFU Depot • Removed by PDFU Initiator before transferring to PDFU Responder

• Firmware Signature• All firmware images must be signed - method of signing is up to vendor • Recommend:

• PKCS1 PSS signature format• SHA256 (or better) hash• RSA key size = 3072 or greater

20


PDFU Initiator (Sink)

PDFU Responder (Source)

USB Type-C Cable

PDFU Depot

DevDays_Example-0000-12AB-0001002300040056-00-201708143256

Example Block Diagram

21





USB Type-C Cable

PDFU Protocol Engine



PDFU Depot

Image Holding Area

Updateable Application Image

Bootloader



User Interface



USB Type-C Cable




PDFU Depot

Image Holding Area

Updateable Application Image

Bootloader



User Interface

USB Type-C cable


PDFU Flow

22

Enumeration

Acquisition

Reconfiguration

Manifestation

Validation

Transfer






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow

23

PD Explicit Contract established, any data role and power role swaps performed






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow - Enumeration

24

Initiate firmware update

GET_FW_ID Request






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow - Enumeration

25

Respond with product info needed for firmware update (HW version, FW version,

VID, PID, PDFU capabilities, etc.)

GET_FW_ID Response

- No Silent Update- Limited functionality during update- Hard Reset needed to finish update






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow - Acquisition

26

Retrieve appropriate firmware image from PDFU Depot


Verify PDFU File Prefix, then remove






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow - Acquisition

27

Alert User that firmware update is available

User approves and firmware update continues






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow - Reconfiguration

28

Tell PDFU Responder to prepare for new firmware image

PDFU_INITIATE Request






USB Type-C Cable

PDFU Depot



29

Responder requires 200ms to prepare for firmware update and indicates in WaitTime

field in PDFU_Initiate Response

PDFU_INITIATE Response (WaitTime = 20)






USB Type-C Cable

PDFU Depot



30

Wait 200ms, then send second PDFU_INITIATE Request

PDFU_INITIATE Request






USB Type-C Cable

PDFU Depot



31

After 200ms, PDFU Responder is ready to receive firmware update

PDFU_INITIATE Response (WaitTime = 0)






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow - Transfer

32

Break firmware image into 258B blocks and send first block

PDFU_DATA Request (258B)






USB Type-C Cable

PDFU Depot



33

Responder has the receive buffer space for 4 additional blocks

PDFU_DATA Response (NumDataNR = 4)






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow - Transfer

34

Send 3 PDFU_DATA_NR Requests with 258B each , followed by a PDFU_DATA

Request with 108B

PDFU_DATA_NR Request (258B)

PDFU_DATA_ Request (108B)








USB Type-C Cable

PDFU Depot



35

PDFU_DATA Response

Only PDFU_DATA Request gets a response






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow - Validation

36

Tell PDFU Responder to validate new firmware image

PDFU_VALIDATE Request






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow - Validation

37

Validate firmware image, then send PDFU_VALIDATE Response

PDFU_VALIDATE Response






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow - Manifestation

38

Tell user that firmware image transfer was successful and that

reset needed






USB Type-C Cable

PDFU Depot


Example Firmware Update Flow - Manifestation

39

Hard Reset

Switch to new firmware image, firmware update is complete!


Firmware Update Pause/Termination• Pause

• PDFU Initiator can pause update mid-transfer• Pause before firmware image transfer starts or after completes is prohibited• PDFU_PAUSE Request initiates pause

• PDFU Responder can accept or reject pause• PDFU Initiator resumes update by sending PDFU_DATA Request

• Or can terminate without resuming• PD Contract negotiations and role swaps still prohibited while paused

• If need to renegotiate, must terminate firmware update

• Termination• PDFU Initiator can terminate at any time by sending PDFU_ABORT Request• PDFU Responder can terminate by setting WaitTime = 255 or Status > 0• If Silent Update prohibited, must notify User of termination/error

• Otherwise, User notification is optional• Reset/disconnect terminates firmware update

• Disconnect from Responder • Loss of power

40


Q&A

41


Backup

• Sample Certificate

• Example Digests Read

• Example Certificate Read

• Example Authentication Challenge

42


Sample Certificate (PD Source)

43

ACD



Example Digests Read

44

Authentication Policy Manager decides to authenticate newly connected power supply

GET_DIGESTS Request




45

Return digests for all certificate chains.

DIGESTS Response




46

Parse DIGEST Response

Look for digest match in digest cache

Policy Manager chooses certificate chain to use for authentication



Example Certificate Read

47

Read first 36 bytes of certificate chain to get chain length and root hash

GET_CERTIFICATE Request (Offset = 0; length = 36)




48

Verify that length and offset are valid

CERTIFICATE Response (36B)

Return requested segment of chain




49

Certificate chain length = 656 bytes (obtained from 1st 2 bytes of chain)

GET_CERTIFICATE Request (offset = 36; length = 256)

Get certificate chain in 256-byte segments




50







51







52







53







54







55

Verify certificate chain



Example Authentication Handshake

56

Certificate chain is valid, initiate authentication handshake

CHALLENGE Request




57

Generate and sign message contents

CHALLENGE_AUTH Response



58

Source is trusted, so can increase power consumption

Verify CHALLENGE_AUTH signature


USB Type-C™ Authentication€¦ · USB Developer Days –October 24 –25, 2017 USB Implementers...

Documents

Transcript of USB Type-C™ Authentication€¦ · USB Developer Days –October 24 –25, 2017 USB Implementers...