Excited to say I worked on this feature! (Standard disclaimer: thoughts and opinions are my own and may or may not be shared by my employer.)
To give an idea of the kinds of things you can do now:
- Keys or other secrets can only be decrypted (via KMS) by an EC2 instance if it is running an approved AMI.
- You could build a certificate authority (CA) which only issues a certificate to an instance running an approved AMI.
This is similar to the functionality that was available in Nitro Enclaves. However, enclaves came with restrictions (such as only being able to communicate through a vsock) that made them not a great fit for all use cases.
On AWS, if I run my software (some VM image), what guarantee is there that you are indeed running the image I provided to you? And, if is an approved image, what guarantee is there that image being run is the one publicly disclosed?
At some point it does come down to "we have to trust the provider isn't outright lying to us about what they're doing."
That was a hard bridge for me to cross for a long time; I got there via sustained in-depth conversations with folks there who simply wouldn't stand for something that breathtakingly opposed to everything AWS has strived to achieve from a trust perspective, that they'd sooner tear it all down than implement such a thing.
Some folks can't get there, and that's okay; if you don't have that level of trust, perhaps the cloud is not a fit for all of your workloads.
The point I am concerned about is that I am forced to trust a single party. AWS is not ever explicit in admitting this, at which point does it matter that your workload is on Nitro-this or attested-that? No university researcher, afaik, has physical access to audit these systems. I think the other major player(s) have a better story for this by harnessing features of certain cpu vendors.
To every cloud/server vendor: This is a big deal. I need a system I can audit, from silicon and firmware up, but I don’t want to water it, give it sunlight, or whisper sweet nothings to it, just to rent it out as needed.
If I understand correctly, it basically works the same as Trusted Boot on a local machine, with the host's CPU used as the root of trust. The difference is that the CPU creates multiple completely independent environments, with for example independent memory encryption keys.
Once you've got that, it's the usual TPM dance: each phase of the boot process verifies the next step and "ratchets" the TPM forward. The final OS uses the TPM's attestation to prove the TPM is genuine and not emulated, and the TPM's final state is used to prove it's running a genuine image booted through the proper process.
AMD had a whole bunch of SEV extensions for stuff like this. I reckon Intel isn't any different.
This doesn't appear to he exclusively anti-evil maid. It takes "build an AMI that doesn't have enough userland to extract the keys" and extends it to "only approved AMI's can access the keys."
Lateral movement of attackers.
Shadow IT.
People modifying things between test and Prod.
All easy examples that don't require you to trust AWS hasn't backdoored it to still get better security.
This is described as being related to 'NitroTPM', which is described as a 'virtual device [...] which conforms to the TPM 2.0 specification'.
Ordinarily, the way you do attestation with a TPM is to perform a TPM quote operation, which provides a TPM-signed attestation of a set of PCRs.
This is... not that. This appears (judging by looking at the source code for some of the provided tools) to be invoking an undocumented(?) vendor-specific command on the TPM device which appears related to the previous Nitro Secure Enclaves support. When AWS introduced Nitro Secure Enclaves, they came up with their own signed attestation document format rather than reusing the TPM standard, then added support for that format to KMS.
The documentation also states: "An Attestation Document is generated by the NitroTPM and it is signed by the Nitro Hypervisor."
This seems to suggest that different entities are responsible for generating AWS's Attestation Document and for signing it, which seems rather odd. What's going on here?
If AWS's claims that NitroTPM is TPM 2.0 compliant are true, it seems like there are now basically two completely different APIs for remote attestation exposed via the TPM virtual device: TPM 2.0 Quote operations and AWS Attestation Documents via an undocumented(?) vendor-specific API.
I can understand wanting to take this approach for consistency with their previous Nitro Secure Enclaves API but it's at the expense of consistency with the existing TPM 2.0 standard. Presumably if you want to use KMS with this you have to use their Attestation Document format rather than a TPM 2.0 Quote, forcing you to use a vendor specific API with it.
Just some thoughts, and this is just my quick impression. I could be mistaken. In any case, having this functionality with a viable KMS tie-in is certainly valuable, so it's nice to see in the sense that you no longer have to create a Nitro Secure Enclave to get this kind of functionality if you don't need the dual compartments separated via a vsock.
Excited to say I worked on this feature! (Standard disclaimer: thoughts and opinions are my own and may or may not be shared by my employer.)
To give an idea of the kinds of things you can do now:
This is similar to the functionality that was available in Nitro Enclaves. However, enclaves came with restrictions (such as only being able to communicate through a vsock) that made them not a great fit for all use cases.On AWS, if I run my software (some VM image), what guarantee is there that you are indeed running the image I provided to you? And, if is an approved image, what guarantee is there that image being run is the one publicly disclosed?
At some point it does come down to "we have to trust the provider isn't outright lying to us about what they're doing."
That was a hard bridge for me to cross for a long time; I got there via sustained in-depth conversations with folks there who simply wouldn't stand for something that breathtakingly opposed to everything AWS has strived to achieve from a trust perspective, that they'd sooner tear it all down than implement such a thing.
Some folks can't get there, and that's okay; if you don't have that level of trust, perhaps the cloud is not a fit for all of your workloads.
The point I am concerned about is that I am forced to trust a single party. AWS is not ever explicit in admitting this, at which point does it matter that your workload is on Nitro-this or attested-that? No university researcher, afaik, has physical access to audit these systems. I think the other major player(s) have a better story for this by harnessing features of certain cpu vendors.
To every cloud/server vendor: This is a big deal. I need a system I can audit, from silicon and firmware up, but I don’t want to water it, give it sunlight, or whisper sweet nothings to it, just to rent it out as needed.
If I understand correctly, it basically works the same as Trusted Boot on a local machine, with the host's CPU used as the root of trust. The difference is that the CPU creates multiple completely independent environments, with for example independent memory encryption keys.
Once you've got that, it's the usual TPM dance: each phase of the boot process verifies the next step and "ratchets" the TPM forward. The final OS uses the TPM's attestation to prove the TPM is genuine and not emulated, and the TPM's final state is used to prove it's running a genuine image booted through the proper process.
AMD had a whole bunch of SEV extensions for stuff like this. I reckon Intel isn't any different.
It's less about being able to prove to yourself and more about being able to prove to _other_ people.
Who is this for? I don’t know of any customers that are this paranoid but also trust the public cloud.
This doesn't appear to he exclusively anti-evil maid. It takes "build an AMI that doesn't have enough userland to extract the keys" and extends it to "only approved AMI's can access the keys."
Lateral movement of attackers. Shadow IT. People modifying things between test and Prod.
All easy examples that don't require you to trust AWS hasn't backdoored it to still get better security.
I'm a bit confused.
This is described as being related to 'NitroTPM', which is described as a 'virtual device [...] which conforms to the TPM 2.0 specification'.
Ordinarily, the way you do attestation with a TPM is to perform a TPM quote operation, which provides a TPM-signed attestation of a set of PCRs.
This is... not that. This appears (judging by looking at the source code for some of the provided tools) to be invoking an undocumented(?) vendor-specific command on the TPM device which appears related to the previous Nitro Secure Enclaves support. When AWS introduced Nitro Secure Enclaves, they came up with their own signed attestation document format rather than reusing the TPM standard, then added support for that format to KMS.
The documentation also states: "An Attestation Document is generated by the NitroTPM and it is signed by the Nitro Hypervisor."
This seems to suggest that different entities are responsible for generating AWS's Attestation Document and for signing it, which seems rather odd. What's going on here?
If AWS's claims that NitroTPM is TPM 2.0 compliant are true, it seems like there are now basically two completely different APIs for remote attestation exposed via the TPM virtual device: TPM 2.0 Quote operations and AWS Attestation Documents via an undocumented(?) vendor-specific API.
I can understand wanting to take this approach for consistency with their previous Nitro Secure Enclaves API but it's at the expense of consistency with the existing TPM 2.0 standard. Presumably if you want to use KMS with this you have to use their Attestation Document format rather than a TPM 2.0 Quote, forcing you to use a vendor specific API with it.
Just some thoughts, and this is just my quick impression. I could be mistaken. In any case, having this functionality with a viable KMS tie-in is certainly valuable, so it's nice to see in the sense that you no longer have to create a Nitro Secure Enclave to get this kind of functionality if you don't need the dual compartments separated via a vsock.