generating ID_BLOCK about go-sev-guest HOT 7 CLOSED

That's correct, the attestation report does not include the original ID or Author key public keys in their entirety because that's an assumed vendor info channel. If a CSP were to publish a "gold measurement" of their firmware, then they would likely want to publish more information about it than what is in an ID_AUTH_STRUCT. The CSP is responsible for documenting their certificate location, and it's up to verifiers to only accept keys from trusted sources. That's a human problem, not a hardware problem. That is why the validate library takes trusted keys as input options.

So in terms of generating an ID_BLOCK to provide at SNP_LAUNCH_FINISH time instead of verification time, you need to look at the PAGE_INFO struct documentation in the SNP_LAUNCH_UPDATE section of https://www.amd.com/system/files/TechDocs/56860.pdf

I've written software internally that generates these structs from a UEFI binary and plan to open source it later, but in the mean time I think IBM already has something similar that might work for you https://github.com/IBM/sev-snp-measure
The OVMF guid table is fiddly to work with so starting there is probably good if you need something short term. Note, however, that you also need to know the exact initial VMSA values. This is more likely something you'll need your CSP to publish, since it might not be uniformly the same across providers. I know that the g_pat in IBM's code differs from that in GCE (0x07010600070106 vs 0x00070106 respectively)

from go-sev-guest.

Thanks. This is very interesting because it's confusing what this is even supposed to be used for. My customer insists that the idblock is signed by their private key, but I'm not sure how they could at all, since it includes the hash of OVMF and other CSP things.

Does Google just provide a list of signer pubkeys somewhere ?

from go-sev-guest.

anyway, is it of value to put a tool that does generate the idblock in this package or rather not?

from go-sev-guest.

The idblock generation code is likely to be a separate software package, since this is only for client-side attestation report fetching and fundamental report verification logic. Owner responsibilities that deal with OVMF specifically deserves a separate project.

As for signing the ID_BLOCK, you're facing a difficult management problem. All the CSPs currently manage their own firmware, and update it frequently. If you require that the firmware is signed by a non-CSP owner, then you're asking for one of a few things:

1. Bring your own firmware, ID_BLOCK, and ID_AUTH. This is a rather sizable product ask since it's difficult to make firmware management a good customer experience when your hypervisor is not readily usable outside the cloud. I know Azure has a preview of trying out bringing your own firmware, but you'll be using their source and build tools as a starting point in order to have a chance of having it be operational in their cloud.

2. The CSP provides a way for a customer to provide their own ID_BLOCK and ID_AUTH for the CSP's firmware. I can think of a few ways this could work:

   a. The CSP provides a way for a VM owner to sign any new CSP firmware's ID_BLOCK through an external key management system, so that the owner to automatically agree to an access justification for routine updates provided the CSP's golden measurement signature passes.

   b. The CSP's ID_BLOCK, ID_AUTH comes from a repository managed with a new project API, and the CSP also provides an API that lists the n-most-recent firmware releases that you might see in production. The customer can have their own workflow to fetch the firmware binaries, compute the new ID_BLOCK and ID_AUTH struct, and then push those to the repository.

In all these instances, you're asking for a lot of work. I'm not saying that it wouldn't get done since there might be enough customer demand to amortize the costs, but you'd need to talk to some product managers.

from go-sev-guest.

If you're satisfied enough with this answer, please close this issue. If not, let me know what else you'd like to know.

from go-sev-guest.

Thanks! Sounds like we will not contribute an idblock Generation thing to this project because it's not generic enough.

from go-sev-guest.

Hi, @aep. I wrote a tool to generate id block here.

If you still need this tool, feel free to use it and leave comments. Now I'm waiting for the approval for my PR IBM/sev-snp-measure#10

Besides, do you know the right way to get chip id and tcb version on host? As far as I know they are presented in attestation reports but it seems one cannot access the report from host

from go-sev-guest.