CHALLENGE succeeds even when Root CA is not installed on requester

[venkyn2]

Hi team,

In the SPDM requester application I’m developing (based on libspdm), I observe that the CHALLENGE command succeeds even when the Root CA is not installed.

Steps

• Load Root CA using:
  libspdm_set_data(ctx, LIBSPDM_DATA_PEER_PUBLIC_ROOT_CERT, ...)
• VCA full handshake — works fine, CHALLENGE succeeds, and measurements are retrieved.
• Modify code to skip Root CA installation (i.e., do not call libspdm_set_data() for root CA).
• Re-run handshake.

Observation

• Even without the Root CA loaded, the CHALLENGE still succeeds and measurements are retrieved successfully.

My expecation
As per SPDM specification, the responder’s certificate chain should be verified against the installed Root CA (trust anchor).
If the Root CA is not installed, the requester should fail the CHALLENGE verification.

Question

• Should I explicity call "libspdm_verify_peer_cert_chain_buffer" against trust certificate?
• Can someone throw light on the flow.

Regards,
Venky
[ P.S - I reffered some of testcases and userguide.md ]

[steven-bellock]

libspdm_verify_peer_cert_chain_buffer_authority is executed when the Requester retrieves the Responder's certificate chain via libspdm_get_certificate*. Currently, if the Integrator modifies trust anchors then they should re-run libspdm_get_certificate*.

[jyao1]

Root-CA is irrelevant to CHALLENGE.
For CHALLENGE, you just need to have pub key from the peer.

Where is the document saying: the requester must have the right root-ca to make CHALLENGE success?

[venkyn2]

This is based on my current understanding — please feel free to share your thoughts. I am referring to section SPDM spec 1.3 version and code below.

• In "Figure 8 — Responder authentication: Example certificate retrieval flow, we see the rootCert on the top of requestor", this wasn't clear to me so, was checking other code bases and i see many implementation importing Peer root certificates and installing them through "LIBSPDM_DATA_PEER_PUBLIC_ROOT_CERT". What is the use of it when the device already presents it? can you please explain.

• 7.2.3 Runtime authentication, If the public key of the Responder was provisioned to the Requester in a trusted environment
  In this section, the spec says, if the publick key of the responder was provisioned, does it mean through "LIBSPDM_DATA_PEER_PUBLIC_ROOT_CERT"

I got more curios after seeing the few lines of the function because, it first refer to the installed trust anchor.
result = libspdm_verify_peer_cert_chain_buffer_authority(
442 spdm_context, cert_chain,cert_chain_size_internal,
443 trust_anchor, trust_anchor_size);

Regards,
Venky

[steven-bellock]

When an Integrator adds a root certificate via LIBSPDM_DATA_PEER_PUBLIC_ROOT_CERT that means that they trust the certification authority and any certificate chained to that CA. The flow then is

1. Add root certificates via LIBSPDM_DATA_PEER_PUBLIC_ROOT_CERT.
2. Issue libspdm_get_certificate* for each populated certificate slot.
   • If the Responder returns a certificate chain that is not rooted in one of the provisioned root certificates (LIBSPDM_STATUS_VERIF_NO_AUTHORITY) then presumably the Integrator will not specify this certificate slot when issuing CHALLENGE.
3. Issue libspdm_challenge using a certificate slot whose root certificate is trusted.

[venkyn2]

Thanks again @steven-bellock, for the clarification. Now I/O card is authenticating correctly with the responder CA certificates. One more question is, what are the general guidelines to use the measurment values for attestation, is there any reference on how it needs to be consumed, like every reboot, or dynamic etc..

[steven-bellock]

what are the general guidelines to use the measurment values for attestation, is there any reference on how it needs to be consumed, like every reboot, or dynamic etc..

The draft for TCG Attestation Framework Part 1 describes issues like that, although it does not necessarily offer guidance.