|
| 1 | +# AMD Secure Encrypted Virtualization (AMD-SEV) |
| 2 | + |
| 3 | +# Concepts |
| 4 | +- AMD-SEV is targeted at securing virtual machines by encrypting the memory of each virtual machine with a unique key. |
| 5 | +- SEV can protect your machine from a potentially malicious hypervisor. |
| 6 | +- SEV can calculate a signature of virtual machine's memory content which can be sent to the VM's owner as an attestation that the memory on the target host, was encrypted correctly by firmware. |
| 7 | +- AMD-SEV SNP is an extension to SEV which adds new hardware-based security protections |
| 8 | + |
| 9 | +## Keys used in SEV |
| 10 | +The AMD SEV firmware provides a mechanism to verify that it is executing on AMD hardware that supports SEV. The following key hierarchy, rooted in an AMD-owned key, is used in this process: |
| 11 | + |
| 12 | +- $PDH$ (Platform Diffie Hellman) key - This key is used to negotiate a master secret which is then used with a key derivation function to establish a trusted channel |
| 13 | +- $PEK$ (Platform Endorsement Key) - This key signs the $PDH$ to anchor the $PDH$ to the AMD root of trust and the platform owner's root of trust |
| 14 | +- $CEK$ (Chip endorsement key) - This key signs the $PEK$ to anchor the $PEK$ to the AMD root of trust. Each chip has a unique $CEK$ which is derived from secrets stored in the chip's one-time programmable (OTP) memory |
| 15 | +- $ASK$ (AMD Signing Key) - The $ASK$ private key signs the $CEK$ public key to demonstrate that the $CEK$ is an authentic AMD key |
| 16 | +- $ARK$ (AMD Root Key) - The $ARK$ private key signs the $ASK$ public key to demonstrate that the $ASK$ is an authentic AMD key. This key is the root of trust of AMD and its signatures signify AMD authencity |
| 17 | + |
| 18 | +Therefore the following certificate chain is produced: |
| 19 | + |
| 20 | + |
| 21 | +$ARK \rightarrow ASK \rightarrow CEK \rightarrow PEK \rightarrow PDH$ |
| 22 | + |
| 23 | + |
| 24 | +Therefore if the secure channel can be established using the $PDH$ key, then it is ensured that, the attesting workload is executed on, is an authentic AMD system which has the SEV feature. |
| 25 | + |
| 26 | +## AMD-SEV SNP Attestation report measurements |
| 27 | + |
| 28 | +### Platform measurements |
| 29 | +- CHIP_ID - The unique chip identifier |
| 30 | +- PLATFORM_INFO - Indicates properties of the platform configuration, for example whether whole system memory encryption (TSME) or simultaneous multithreading (SMT) is enabled |
| 31 | +- CURRENT_TCB - Security Version Numbers (SVNs) of the current executing platform firmware and microcode |
| 32 | +- COMMITTED_TCB - SVNs of the anti-rollback minimum of the platform firmware and microcode |
| 33 | +- REPORTED_TCB - SVN of the hypervisor. The hypervisor has the option to report a lower version |
| 34 | +- LAUNCH_TCB - SVNs of the platform firmware and microcode at the time the guest was launched or imported |
| 35 | + |
| 36 | +### Guest measurements |
| 37 | +- FAMILY_ID - The family ID of the guest that is provided at launch |
| 38 | +- IMAGE_ID - The image ID of the guest that is provided at launch |
| 39 | +- GUEST_SVN - The guest SVN |
| 40 | +- MEASUREMENT - Measurement of the guest address space |
| 41 | +- ID_KEY_DIGEST - SHA-384 digest of the ID public key that signed the [ID block](https://www.amd.com/system/files/TechDocs/56860.pdf#page=91) provided in `SNP_LAUNCH_FINISH` |
| 42 | +- AUTHOR_KEY_DIGEST - SHA-384 digest of the Author public key that certified the ID key, if provided in `SNP_LAUNCH_FINISH` |
| 43 | +- POLICY - The [guest policy](https://www.amd.com/system/files/TechDocs/56860.pdf#page=26) |
| 44 | +- REPORT_ID - Report ID of this guest |
| 45 | +- REPORT_ID_MA - Report ID of this guest's migration agent, if the guest is associated with a migration agent |
| 46 | + |
| 47 | +More details on other elements of the produced attestation report are outlined [here](https://www.amd.com/system/files/TechDocs/56860.pdf#page=44). |
| 48 | + |
| 49 | +# AMD-SEV SNP from Veraison's perspective |
| 50 | +Veraison needs two things to verify the attestation of an AMD-SEV SNP system: |
| 51 | + |
| 52 | +- The signed attestation report |
| 53 | + - $VCEK$ (Versioned Chip Endorsement Key) - The [$VCEK$](https://www.amd.com/system/files/TechDocs/57230.pdf) is the key that signs the attestation report. The key is derived from chip unique secrets and a [TCB_VERSION](https://www.amd.com/system/files/TechDocs/56860.pdf#page=18) |
| 54 | +- The following certificate chain that is tied to the signed attestation report |
| 55 | + - $ARK \rightarrow ASK \rightarrow VCEK \rightarrow$ Attestation Report |
| 56 | + |
| 57 | +## Current prototyping |
| 58 | +A protoypte of an attestation verification flow is for AMD SEV-SNP evidence can be found [here](https://github.com/SabreenKaur/amd-snp-prototype). The library used for verification of the AMD SEV-SNP reports is [here](https://github.com/google/go-sev-guest). |
| 59 | + |
| 60 | +### Structure of attestation verification flow |
| 61 | +1. Report is obtained from attester |
| 62 | +2. A full Attestation is derived from the report. In this step two things will happen to obtain the certificate chain (that forms part of this attestation): |
| 63 | + - AMD KDS (Key Distribution Service) is queried to get the ASK and ARK certificates if they are not already in the internal library cache |
| 64 | + - AMD KDS is queried to obtain the VCEK certificate if it is not already in the implemented time-to-live cache |
| 65 | +3. Non-signature fields of the report are matched against a provided JSON policy |
| 66 | +4. The Attestation is verified. Three things happen: |
| 67 | + - AMD KDS is queried to get the certificate chain (ASK, ARK and VECK) if they are not already in the their respective caches |
| 68 | + - Certificate revocation lists are checked |
| 69 | + - The Attestation report's signature is verified based on the report's signature algorithm |
| 70 | + |
| 71 | +### Structure of the TTL (Time-to-live) cache |
| 72 | +The implemented time-to-live cache is designed to hold: |
| 73 | +- VCEK certificates |
| 74 | +- CRLs (Certificate Revocation Lists) |
| 75 | + |
| 76 | +Structure of the implemented cache: |
| 77 | +- Key: `string` format of the url used to query the AMD KDS |
| 78 | +- Value: `byte[]` format of the certificates or CRLs returned after querying the AMD KDS |
| 79 | + |
| 80 | +Expiry of cache entries: |
| 81 | +- VCEK certificates: time to live is set to be the duration between the current time and the `vcek.NotAfter` field. VCEK certificates typically expire every 7 years after being issued |
| 82 | +- CRLs (Certificate Revocation Lists): time to live is set to be the duration between the current time and the `crl.NextUpdate` field. CRLs typically get refreshed every year |
| 83 | + |
| 84 | +A [custom getter](https://github.com/SabreenKaur/amd-snp-prototype/blob/main/ttl_getter.go) is implemented to allow us to interface with the ttl cache. |
| 85 | + |
| 86 | +### Veraison in a TEE with AMD SEV-SNP |
| 87 | +- We can setup up an AWS EC2 instance with support for AMD SEV-SNP to obtain Attestation Reports. |
| 88 | + - Instructions on running the EC2 instance with AMD SEV SNP support are outlined [here](https://confluence.arm.com/display/~sabgur01/Creating+an+amd+sev+snp+instance+using+AWS+console) |
| 89 | +- Reports can be obtain using this golang [library](https://github.com/google/go-sev-guest) (currently a [WIP](https://github.com/google/go-sev-guest/issues/53)) or using the AMD offical tooling following these [instructions](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snp-attestation.html). This [guide](https://confluence.arm.com/display/~sabgur01/Generating+a+VLEK+using+AMD+tools) helps with installing the modules needed to complete the steps in the instructions. |
| 90 | +- Caveat: To verify SNP VMs within AWS, we need to obtain an VLEK instead of a VCEK certificate |
| 91 | + |
| 92 | +## Open Questions |
| 93 | +1. What sort of background tasks need to be performed behind the kvstore exisiting functionality, when querying the AMD key service? |
| 94 | + - Does it need to be per scheme? |
| 95 | + - What are the common logics? |
| 96 | +- UPDATE: We can use ttl caches to store the certificates that are queried from the AMD KDS |
| 97 | +2. Through what mechanism can we do the checking of CRLs (certificate revocation list) or similiar? |
| 98 | +- UPDATE: This can be done by enabling the CheckRevocations in the Options struct |
| 99 | +3. How can platform (OCA) specific fields of the attestation report be verified? |
| 100 | + - Could it be handled by policies? |
| 101 | +4. Which non-signature fields of the attestation report should be validated by Veraison? |
| 102 | +5. Where can nonce-like freshness data be represented? Possibly in the [REPORT_DATA](https://www.amd.com/system/files/TechDocs/56860.pdf#page=43) field? |
| 103 | +6. Logic and functions within `trustedservices_grpc.GetAttestation` need to be refactored to account for that fact that trust anchors cannot be assumed in the SEV-SNP scheme, initial thoughts on functions to be refactored: |
| 104 | + - `initEvidenceContext(...)` - make it optional to `GetTrustAnchorID` within this function |
| 105 | + - `getTrustAnchor(...)` - make it optional to call this function |
| 106 | + |
| 107 | +## References: |
| 108 | +1. [AMD SEV API specification](https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf) |
| 109 | +2. [AMD SEV-SNP ABI specification](https://www.amd.com/system/files/TechDocs/56860.pdf) |
| 110 | +3. [AMD VCEK certificate and KDS interface specification](https://www.amd.com/system/files/TechDocs/57230.pdf) |
| 111 | +4. [Presentation on attestation in AMD SEV-SNP](https://www.amd.com/content/dam/amd/en/documents/developer/lss-snp-attestation.pdf) |
0 commit comments