Custom USB PD Implementation on STM32G0

[TLaux]

Hi everyone,

I have been searching for about 3 days straight for a reasonable solution to a USB PD project, and I am still feeling lost. Maybe someone can point me in the right direction.

We need to design a USB PD sink circuit which authenticates the power source before applying VBUS to any internal circuits. We need to reject non-genuine sources due to operator safety reasons. We have close control over the source's firmware (since we are the source manufacturer). We are working with a large customer to develop this authentication solution for their system.

We have two possible solutions:

1.) Simple: Send "Discovery Identity" request to source. If VendorID reply is correct, request higher power USB PD profile, and apply VBUS.

2.) More complicated(?): Use USB PD3.0 authentication messages via extended messages. I'm very lose on this one, regarding how we could implement this. (If it seems reasonable, please let me know.)

I spent many hours looking through the code for the X-CUBE USB PD software: https://github.com/st-one/X-CUBE-USB-PD

It appears to have just about all USB PD functions implemented, so I could conceive how we could implement our solution. This code seems to be targeted at STM32F0 and STUSB1602, so it would require two ICs.

Then, I noticed that STM32G0 supports USB PD natively. Does that mean we don't need an external IC like STUSB1602?

If so, what would be the easiest way to develop a custom USB PD solution for the STM32G0? Is there firmware/libraries available? Example projects we can modify? We need to be able to implement non-standard logic like checking for ProductID and preventing further negotiation if authentication failed. That is, we need more than just set a few custom USB PD profiles.

Any and all suggestions are greatly appreciated.

Thank you for your time.

Tim

[Guenael Cadier]

Hello Tim,

As you noticed, X-CUBE-USB-PD package has been designed as an expansion package for STM32F0 serie. Goal of this package was to provide a first implementation of USB PD solution based on existing STM32F0 device + additional HW or external component (as STUSB1602).

Inside this package, you could find inside Middlewares/ST/STM32_USBPD_Library/ directory :

- ST USBPD Core stack library. This part is platform independent from STM32 it is running on, only need to select the proper library version, according to Cortex M version within your device.

- ST USBPD Device component (F0 or STUSB1602 depending of which HW kit you are using). This part is platform dependent.

After this X-CUBE package has been made available, new serie STM32G0 is embedding a USBPD IP. So, with a G0, no more need of complex HW AFE nor external component as STUSB1602.

So to answer your first question : no need for STUSB1602 when using G0.

Some of the basic functions required for USBPD implementation are natively achieved by STM32G0, lightening CPU load :

- Preamble generation/recovery

- EOP detection

– 4b5b encoding/decoding

– BMC (bi-phase mark) coding/decoding

– CRC generation (Tx) and checking (Rx)

- ...

So in STM32G0 Cube Firmware Package (please look for STM32CubeG0 on st.com website, v1.2.0 package now available, 1.3.0 to come), you could also find our USBPD Core stack (up to date version compared to the one delivered in X-Cube package) and G0 dedicated device.

STM32G0 Firmware package also contains some examples of USBPD applications. 2 basic applications (located into Projects\STM32G081B-EVAL\Applications\USB-PD directory) :

- 1 Consumer (Sink, 1 port, built using CubeMx)

- 1 Provider (Source, 1 port, built using CubeMx)

In addition, you could also have a look at the demo project available in Projects\STM32G081B-EVAL\Demonstrations\DemoUCPD directory, which is handling 2 ports (1 DRP + 1 SNK).

All these examples are provided in full source (except the core Stack library) so you could easily update SW on your side for all applicative part.

Regarding your question on authentication, indeed, a Sink, i.e. being charged when connected to a Source, might want to prevent that out of specs charging devices (Source) may be used.

can set a policy in their products requiring that only certified PD products be used for charging.

Authentication procedure allows Sink to authenticate the connected Source entity. When Source is authenticated, Sink could request safely highest offered power.

Among the 2 solutions for authenticating a Source, that you mentioned, 1st one might be easier to implement, but also easier to workaround.

2nd one, consists in implementing method described in the USB Type C Authentication Specification.

From USB-PD stack point of view, implementation of Authentication only requires support of USB Type-C Power Delivery, revision 3.0, with support of Extended messages.

All data exchanged between the 2 ports will be carried through Security messages exchange

Implementation of the authentication mechanism is then done on application side.

What is needed :

- Random numbers generation : used in challenge procedure. Could be achieved using STM32G0 RNG IP.

- X509v3 ASN.1 structure parsing (DER encoding) : used for Certificate format

- ECDSA (NIST P256 secp256r1 curve, uncompressed point) : used for Digital signing of Certificates and Authentication Messages

- SHA256 : used for HASH computations. Not available on G0, but available on STM32 G4 which also embeds same UCPD IP (1 port only).

- Secure storing of Certificates, and especially of Private key on Responder side (the authenticated side).

Hope this helps a little.

Please feel free to raise new questions if needed.

Regards

Guenael

[TLaux]

Hi Guenael,

Thank you so much for your detailed reply. I unfortunately have to leave the office early today, but I will reply in greater detail soon. Just wanted to let you know I saw your answer and appreciate it.

I think this information will help a lot with our implementation.

Thanks,

Tim

[TLaux]

Hi Guenael,

I am finally getting around to this issue again...Hopefully you're still there.

First off, I apologize for my ignorance regarding most things related to micro-controllers and especially crypto/authentication. But, for the USB Type-C Authentication method (using USB PD 3.0 extended messages)...the power-adapter side would need special hardware to store private keys, correct?

Our current power adapters, in production, use a USB PD controller from another manufacturer...I believe based on an 8051 core. I highly doubt it has any provisions for secure keys.

Therefore, if we wanted to implement this solution on our end (as the power adapter manufacturer), we would need to incorporate an STM32G0 or another microcontroller with a crypto block, right? I know a few of the Apple USB PD chargers use STM32, presumably for this feature..

Thanks!

[Guenael Cadier]

Hello Tim,

You are right : implementing an Authentication procedure over USB-PD extended messages between a source and a sink, implies that private key at the minimum is kept secret on responder side (Certificates are less sensitive).

More globally thinking, having devices without access to flash/source code nor to debug facilities makes sense here.

This could be achieved on STM32 devices using flash memory protection features as Read protection (RDP) and proprietary code readout protection (PCROP). This is possible on STM32G0.

Of course, it will always be a trade-off between security/robustness and cost of the global solution.

For instance, we made a demo of USB-PD authentication running on a STM32F0 + ST-SAFE security component : All "sensitive" stuff, as key storage, signature generation, was handled by the ST SAFE component (communication between STM32 and ST-SAFE on I2C).

This solution could be considered as more expensive or complex but achieve a higher security level due to ST-SAFE characteristics.

In other words, various solutions could be implemented, suitable or not depending on the global security level of the solution you want to achieve.

Regards

Guenael