Anjuna Enclave boot sequence
AMD SEV-SNP on Azure
The boot process in Azure for SEV-SNP involves three entities: the enclave, the Trusted Platform Module (TPM), and the Anjuna Policy Manager.
Initially, the TPM is loaded with an attestation key (asymmetric), an encryption key (asymmetric), and an SEV-SNP attestation report that attests to the TPM attestation key. This report is generated at system startup by the Azure firmware. During boot, each component measures the next component. These measurements are stored in the TPM’s Platform Configuration Registers (PCRs).
If remote attestation is required, the enclave first requests a challenge from the Anjuna Policy Manager (APM). This challenge is random and can be considered unique across all iterations of this protocol. Then, the enclave produces a TPM attestation report (not to be confused with the SEV-SNP attestation report), which attests to the challenge and contains the list of PCR values. The enclave then sends the attestation key, the encryption key, the SEV-SNP attestation report, and the TPM attestation report back to the APM. The APM then validates the SEV-SNP attestation report. Using it, it validates the attestation key. Using this key, it validates the TPM attestation report. Using this report, it validates the challenge.
Once the whole attestation evidence chain is verified by the APM, the APM trusts the enclave. The APM then uses the PCR values in the TPM attestation report to calculate the Enclave and Signer IDs. It then creates a token with all the policies associated with these IDs. Finally, it encrypts the token with a generated asymmetric key, and encrypts this key using the TPM encryption key provided by the enclave, and produces a TPM import request. TPM import requests allow data to be decrypted only when the TPM’s PCR values are as specified by the request. This import request is then sent back to the enclave. The enclave uses the TPM to decrypt the generated key, which is used to decrypt the APM access token. The enclave is now ready to fetch secrets from the APM.
Trusting the AMD SEV-SNP on Azure boot process
This protocol ensures that only authorized enclaves can receive valid Anjuna Policy Manager tokens using their attestation quote.
To understand why, first consider the two keys in play; the TPM encryption key, and the key generated by the APM.
The TPM encryption key never leaves the TPM. Even the enclave has no direct access to the key, but rather can only request data to be decrypted through the import requests.
While the generated key does leave the APM, it only does so in an encrypted form. This encrypted key can only be decrypted by the TPM encryption key, and since it only sits in the TPM, only the TPM can decrypt the generated key. Moreover, the generated key is wrapped in an import request, requiring the TPM to be in a specific state before it can be decrypted. This state is dependent on the PCR values, and since these PCR values uniquely identify enclaves, this means that only the authorized enclave can decrypt the generated key.
Therefore, the generated key can only be accessed by the APM and the enclave, so the plaintext token is only visible to these two.
Man-in-the-middle attacks are prevented using the CA certificate for the APM, which is pinned in the enclave configuration. If the APM uses a certificate signed by the CA, the enclave can trust the APM. Any attacker would not be able to present a valid certificate, and the enclave would abort.
Replay attacks are prevented using the challenge-response protocol. Since the protocol begins with a unique challenge for each new enclave, an attacker cannot use a previously-captured token request to fetch a token from the APM. The replayed token request would be rejected because the challenge nonce has been re-used. The TLS protocol also prevents replay attacks by design.
Finally, only authorized enclaves can produce valid attestation quotes. This is enforced by the AMD SEV-SNP hardware.