<div dir="ltr">> The USB 3.1 specs are available here:<br>><br>>  <a href="http://www.usb.org/developers/docs/usb_31_040816.zip">http://www.usb.org/developers/docs/usb_31_040816.zip</a><br>><br>> Within the zip file is a "USB Power Delivery" directory and a<br>> "USB_PD_R2_0 V1.2 -20160325.pdf" power delivery spec.<br><br>Authentication isn't part of the USB Power Delivery spec, it's a separate document in the zipfile:<br>"USB Authentication/USB_AUTHENTICATION_R1_0-20160325.pdf".<br><br>Take a look - it's fairly readable and I'm sure the USB-IF would appreciate a few more eyes.<br><br>Authentication messages can be sent either using Power Delivery messages over the Type-C CC wire (to authenticate chargers, etc) or as USB control transfers (to authenticate "normal" USB devices). Both transports use the same underlying protocol.<br><br><div><br></div><div>> Anyone know exactly what crypto is going into these things, and what<br>> its capabilities are?<br><br>From section 2.2 of the spec:<br><br>Certificate Format: X.509v3, DER encoding<br><br>Digital signing of Certificates and Authentication Messages: ECDSA using the NIST P256, secp256r1 curve, uncompressed point format <br><br>Hash algorithm: SHA256 <br><br>Here's a brief protocol summary:<br><br>1) Initiator requests X.509 certificate chain(s) from the responder.<br>  (Chains can be cached and just the SHA256 digests requested, to speed up subsequent connections).<br><br>2) Initiator sends a challenge with a random nonce.<br><br>3) Responder responds with an ECDSA signature of various fields, including the challenge from 2).<br><br>It's up to the Authentication Initiator's policy to decide what to do if authentication fails. This might be to limit charging to a lower power from a (potentially dangerous) uncertified charger, or an end-user (or their employer) might configure their device to refuse access to an unrecognised USB thumb drive or ignore keystrokes from an unrecognised "keyboard".</div><div><br></div></div>