virtee/kbs-types

Rust (de)serializable types for KBS

kbs-types's Issues

Version 0.5.3 may break users of the crate

Version 0.5.3 includes a commit bumping the version of sev from 1.x to 2.x. Since those two versions of that crate are not compatible, users consuming both crates (which should be pretty common) will get a broken build after updating from 0.5.2 to 0.5.3 (which may happen automatically). I'd suggest reverting this release and making it a 0.6.0 instead.

Missing testdata for the attestation

Example how to request the attestation

Cut a release for v0.3.0

With the changes introduced with 8d3a0, 46b82, and ac893, it would probably be a good idea to cut a release, as they introduce breaking changes to an enum.

• Create a tag for v0.3.0
• Create a release on crates.io

Add a new TEE type: SE (IBM Secure Execution)

I was wondering if I could raise a PR to add a new TEE type named Se like #20, even if the TEE is not specified at https://virtee.io/.

SEV-SNP KBS Types

@slp I figured we could take this discussion here while I work on the SEV-SNP KBS implementation.

If we look here at AMD's attestation notes, We see that in order for a SEV-SNP guest to attest correctly, all we really need is:

• Attestation report signature
• Host/Guest Certificate chain (VCEK, ASK, ARK)
• Host/Guest ID Block

The document also mentions "The hash of the public keys included in the attestation report matches the expected value." I would assume by "the public keys" it is speaking of the ID key digest and Author key digest?

If so, I am proposing the following protocol for SEV-SNP attestation:

HOST PROTOCOL

1. Register certificate chain, ID key, and Author key for a specific workload.

• Guest must be able to verify its signature with the VCEK. Yet by the time the guest is looking to attest, it cannot retrieve the VCEK and has no way to obtain it. So, it should be registered beforehand by the host, no?

GUEST PROTOCOL (KBS Authentication Phase)

1. -> POST /kbs/v0/auth [Payload: Request]

• One thing Request must contain is the some identifier to associate it with a workload previously registered by the host. The host can get this identifier from the host_data field, which comes from the host on SNP_LAUNCH_FINISH, and is described by the AMD firmware spec as the following: Opaque host-supplied data to describe the guest. The firmware does not interpret this value. Could the identifier be the workload_id provided on register_workload?

2. <- Response [Set-Cookie: <session-id>] [Payload: Challenge]

The Challenge to the SEV-SNP would require the following:

• Report Signature
• ID key digest
• Author key digest

With all of this information, the server will be able to fully attest the integrity of the system.

3. -> POST /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
The Payload here would contain the Signature, ID key digest, and Author key digest for the server to attest.

4. <- Response [Set-Cookie: <session-id>]

RESOURCE ACCESS

Depending on the results here, the server would then be able to obtain the key from the server via the resource access phase.

What do you think about this design?