Git-Mirrors/constellation
1
0
Fork 0
mirror of https://github.com/edgelesssys/constellation.git synced 2025-05-04 15:25:00 -04:00
Code Issues Projects Releases Packages Wiki Activity

Make PCRs part of payload in Security Overview (#3480)

Browse source 
* Make RTMRs part of "aux data"

* Introduce Sig-TPM
This commit is contained in:
Felix Schuster 2025-03-12 15:18:13 +01:00 • committed by GitHub
parent eb9dc01425
commit df06022e9e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 23 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

30
dev-docs/security-overview.md
View file

@ -79,12 +79,16 @@ Abstractly, a remote-attestation statement `R` from a CVM looks as follows:
R = Sig-CPU(<launch digest>, <auxiliary data>, <payload>) R = Sig-CPU(<launch digest>, <auxiliary data>, <payload>)
``` ```
The `payload` is controlled by the software running inside the CVM. The field `payload` is controlled by the software running inside the CVM.
In the case of a Constellation node, the `payload` is always the public key of the respective Bootstrapper running inside the CVM. In the case of a Constellation node, the `payload` is always the public key of the respective Bootstrapper running inside the CVM.
Thus, `R` can be seen as a certificate for that public key issued by the CPU. Thus, `R` can be seen as a certificate for that public key issued by the CPU.
Based on this, nodes establish attested TLS (aTLS) connections. Based on this, nodes establish attested TLS (aTLS) connections.
aTLS is used during [cluster creation](#cluster-creation) and when [growing a cluster](#cluster-growth). aTLS is used during [cluster creation](#cluster-creation) and when [growing a cluster](#cluster-growth).
The field `auxiliary data` is populated automatically by the CVM platform and, among others, includes information like CPU firmware versions.
Note that this description of `R` is highly abstract.
### Measurements ### Measurements
In the ideal case, the underlying CVM platform does not inject any of its own software into a CVM. In the ideal case, the underlying CVM platform does not inject any of its own software into a CVM.
@ -97,16 +101,26 @@ In this case, the launch digest is the only measurement that's required to verif
However, currently, all supported CVM platforms (AWS, Azure, and GCP) inject custom firmware into CVMs. However, currently, all supported CVM platforms (AWS, Azure, and GCP) inject custom firmware into CVMs.
Thus, in practice, Constellation relies on conventional [measured boot](https://docs.edgeless.systems/constellation/architecture/images#measured-boot) to reflect the identity and integrity of nodes. Thus, in practice, Constellation relies on conventional [measured boot](https://docs.edgeless.systems/constellation/architecture/images#measured-boot) to reflect the identity and integrity of nodes.
In measured boot, in general, the software components involved in the boot process of a system are "measured" into the 16 registers of a Trusted Platform Module (TPM). In measured boot, in general, the software components involved in the boot process of a system are "measured" into the 16 platform configuration registers (PCRs) of a Trusted Platform Module (TPM).
The values of these registers are also called "runtime measurements". The values of these registers are also called "runtime measurements".
All supported CVM platforms provide TPMs to CVMs. All supported CVM platforms provide TPMs to CVMs.
Constellation nodes use these to measure their boot process.
They include the 16 runtime measurements as `auxiliary data` in `R`.
On each CVM platform, runtime measurements are taken differently.
Details on this are given in the [Constellation documentation](https://docs.edgeless.systems/constellation/architecture/attestation#runtime-measurements).
With measured boot, Constellation only checks the 16 runtime measurements during the verification of a node's remote-attestation statement. With measured boot, Constellation relies on TPM-based remote attestation for nodes.
The launch digest is not considered, because it only covers the firmware injected by the CVM platform and may change whenever the CVM platform is updated. TPM-based remote attestation is similar to confidential computing-based remote attestation. Instead of the value `R`, the value `R'` is used.
```
R' = Sig-TPM(<auxiliary data>, <payload>)
```
The field `auxiliary data` is populated automatically by the TPM and most notably contains the 16 PCRs.
Constellation uses the field `payload` as usual and sets it to the public key of the respective CVM's Bootstrapper.
When verifying `R'`, Constellation compares the 16 PCRs to those given in the attestation config.
#### Differences between CVM platforms
Each supported CVM platform populates the 16 PCRs in different ways. Details can be found in the [Constellation documentation](https://docs.edgeless.systems/constellation/architecture/attestation#runtime-measurements).
Sig-TPM itself is also verified differently for each cloud.
Currently, on AWS and GCP the TPM implementation resides outside the CVM. Currently, on AWS and GCP the TPM implementation resides outside the CVM.
On Azure, the TPM implementation is part of the injected firmware and resides inside the CVM. On Azure, the TPM implementation is part of the injected firmware and resides inside the CVM.
More information can be found in the [Constellation documentation](https://docs.edgeless.systems/constellation/overview/clouds). More information can be found in the [Constellation documentation](https://docs.edgeless.systems/constellation/overview/clouds).