[RFC] Init Time Configuration for image-rs

[bodzhang]

[RFC] Init Time Configuration for image-rs

Policy File for image-rs

The policy file is a critical component of the image-rs container image integrity protection scheme. It contains the configuration information such as public keys to be used to verify container image signature or container image repo identity. A forged policy file would allow an attacker to inject unauthorized containers into the Confidential Container guest VM.

In the current implementation, the policy file is either part of the guest VM image or downloaded by image-rs from a KBS.

When the policy file is provided as part of the guest VM image, its content is covered by the guest VM image measurement, reflected in Attestation. Any tampering of the expected policy file would be detected by the Rely Party through the Attestation. The drawback of this approach is that a K8S customer would need to customize the guest VM image, typically managed/maintained by the Service Provider, to enforce deployment-specific and/or Pod-specific policy. Service Provides can offer a deployment time interface to accept and integrate customer-provided policy file into the guest VM image, before initializing the guest VM for the Confidential Container deployment, but such design still presents a challenge for the Relying Party and the customer. The measurement of the guest VM image would change, based on the policy file integrated, putting a burden on the Relying Party and the customer to track and manage the mapping between the expected measurement value and the deployed Pod.

When the policy file is to be downloaded from a KBS, the authenticity of the policy file provided by the KBS needs to be verified. Typically, it can be accomplished by verifying a signature applied to the policy file by a trusted KBS, or by authenticating the KBS identity as part of a protected transport protocol establishment, such as TLS. Regardless of the authentication solution used, the image-rs needs to be configured with a trusted KBS public key. The trusted KBS public key can be integrated into the guest VM image as discussed above. The challenges with regard to expected measurement value remains.

SEV-SNP and TDX/SGX Init Time Configuration for image-rs Configuration

AMD(r) SEV-SNP supports a 256-bit Host_Data when initializing the SEV-SNP protected guest VM. The Host_Data is set by the Host in the SNP_LAUNCH_FINISH command. The SEV-SNP firmware does not interpret this value, but includes this value in SEV-SNP ATTESTATION_REPORT, in parallel with Launch Measurement. More details are discussed in SEV Secure Nested Paging Firmware ABI Specification section 8.18 and section 7.3.

Similarly, Intel(r) TDX supports a 384-bit host provided MRCONFIGID in the SNP_LAUNCH_FINISH command, for runtime of OS configuration. MRCONFIGID is part of TDX ATTESTATION_REPORT, and does not affect MRTD. More info on TDX MRCONFIGID is available in Architecture Specification: Intel(r) Trust Domain Extensions (Intel(r) TDX) Module section 11.2, Section 20.2.4 and Section 20.6.5.

Host_Data or MRCONFIGID can be utilized to provide configuration data to the guest VM at VM initialization time, without affecting the measurement value of the guest VM image. The Host can set Host_Data/MRCONFIGID to the sha256 hash of the policy file (with 0-padding appended to fill the 384-bit or 512-bit field). After the guest VM is initialized, image-rs running inside the protected guest VM can retrieve the ATTESTATION REPORT from the TEE HW, and verify the hash of the policy file provided to it through a Pod deployment time interface, for example, an Annotation field in the Pod YAML file, matches the value inside the ATTESTATION REPORT. Only after the verification, image-rs will utilize the information inside the provided policy file.The Rely Party would verify the Host_Data/MRCONFIGID in the ATTESTATION_REPORT matches the expected value, in addition to checking for the known/trusted guest VM image measurement value.

Intel(r) SGX 2.0 also supports a 512-bit OS provided CONFIGID and includes it in SGX REPORT. So enclave-cc can also utilize the same mechanism for image-rs policy file configuration.

For TEEs that do not support init time configuration, integrating the policy file in the guest VM image is still required.

[bodzhang]

issue #29

[dcmiddle]

+1 This is a good use of the config fields for SGX and TDX. Note that TDX has a couple options.. either MRCONFIGID or MROWNERCONFIG would be appropriate. For SGX, config_id is the only field so it's easier to choose. :)

[fitzthum]

First, I think if we implement something like this, we definitely want to have the attestation agent be the one that handles the verification rather than image-rs. Currently image-rs can get the config file from the attestation agent using the get_resource API. It wouldn't be too much work to implement a KBC that verifies the config against the host data before sending it to image-rs. This would be a good way to hide the platform-specific details from image-rs and other components, which I think is important.

Next week I am planning to propose adding a non-measured configuration to Kata. This would allow us to pass values from the shim to the guest without altering the launch measurement. I think what you're proposing would be yet another use for that.

As you may have seen in some of our older issues, we've gone back and forth a lot about the best way to have the KBC verify the identity of the KBS. So far we keep coming back to the idea that the KBS has to provide some secret that is verified not by the KBS, but by some other trusted party. For example, the KBS can provide a key that allows the workload to authenticate with a database. Only the authentic KBS can provide these credentials. This is more difficult with signatures because an attacker could use a fake KBS to send the wrong public key and could also use a fake registry to provide an image that is signed by the fake keypair. There is a chicken and egg problem when it comes to provisioning a key that verifies the identity of the KBS. I think this proposal is also susceptible. A malicious host could put the wrong hash values in the host_data field and then have a fake KBS approve the measurement. I think this is still worth pursuing, but I"m not sure it gives us a fool-proof way to verify the KBS identity. Let's talk about it next week.

[bodzhang]

It makes sense to rely on the attestation agent to verify HostData/ConfigID = hash(policy_file).

the best way to have the KBC verify the identity of the KBS

I would state that the security requirement as - the KBC shall only utilize configuration/policy from a KBS or other configuration/policy source after confirming the identity of the configuration/policy source is covered by Attestation.

In an implementation where the KBC accepts additional configuration/policy from a KBS whose public key is part of the policy file provided by the host (untrusted), with the hash of the policy file in HostData/CONFIGID within the Attestation REPORT, the identity of the KBS (its public key) is covered by the Attestation. If the untrusted host replaces the expected KBS' public key inside the policy file, during remote attestation, the Relying Party (for example, the real KBS holding the database decryption key) will detect that HostData/CONFIGID value does not match expectation, and should refuse to release the decryption key to the guest VM with the unexpected policy file. Similarly, in an implementation that utilizes a policy file containing only the pubic key of the expected KBS to retrieve configuration/policy from, the identity of the configuration/policy source is also reflected in HostData/CONFIGID field within the Attestation Evidence.

[fitzthum]

Ok, I think we're talking about two slightly different issues here. I agree that all sensitive configuration info needs to be accounted for by the evidence. There is a separate question about how the KBC can be sure that it is talking to the correct KBS in the first place. I don't think this proposal answers that question, but maybe that isn't the goal.

[dcmiddle]

My understanding is similar to Bo's. The KBS will only release keys to an enclave/VM with the correctly attested binary measurement and configuration (policy file). The binary measurement implies that the enclave/VM has the right software (e.g. AA) to check and enforce the policy file. That software knows what hash to expect of the policy file based on the hostdata/ConfigID.

We still need to be careful in the implementation to prevent Time of Check Time of Use attacks on the policy file.

I think the enclave/VM configured to contact a malicious KBS is out of scope because workload attestation is out of scope. i.e., Any pod can be used to launch any workload. There is no guarantee that the desired workload is running. The CoCo claim is that if you have an encrypted container it will only be decrypted in a correctly configured enclave/vm.

I may not be understanding your KBS concern correctly though so feel free to describe the threat you have in mind.

[fitzthum]

What TOCTOU issue are you envisioning?

I think it's more accurate to say that the hardware measurement is decoupled from the workload measurement than to say that workload attestation is entirely out of scope. Signatures and a correctly configured policy file can give some assurances about which workloads can be run inside of an enclave, but there's still the old gotcha that you might have connected to the wrong KBS. All I am saying is that this proposal does not change anything in that regard. Even though the public key of the KBS will be covered by the measurement, there are some circumstances in which we still cannot trust it because it is still the KBS itself that is verifying the measurement. So generally as you say you need to rely on some injected secret to be sure that you connected to the right KBS, although there are a few exceptions to that as well.

[bodzhang]

This proposal does not provide any mean for a KBC detect locally an invalid/forged configuration, for example the intended KBS public key. It only supports the Relying Party to detect invalid/forged configuration.

@fitzthum , do you have an example of a usage that requires the KBC to detect locally invalid/forged configuration?

[fitzthum]

Generally most workloads will rely on some kind of secret either because the container image is encrypted or because the workload needs credentials to pull data from another location. The use case that makes me a bit nervous is when a pod only contains signed images (and no secrets or other information that confirms the identity of the KBS). If we can't be sure that we're talking to the right KBS, we can't be sure that the keys we use to verify the image signatures are correct. Now really I don't think this is a fundamental problem, because I don't think that pods with only signed images make sense in a confidential computing context. What worries me is that this limitation is not at all obvious. The typical end user will probably assume that if they run a signed container image with confidential containers then only a signed container image can be run. This is not always the case.

[dcmiddle]

What TOCTOU issue are you envisioning?

I'm interpreting that the proposal is the AA verifies the measurement of the policy file, and image-rs is responsible for enforcing the policy.

If the AA and image-rs both independently read the file there's an opportunity for the file to change in between reads or for the reads to be directed at different locations.

[fitzthum]

If the AA and image-rs both independently read the file there's an opportunity for the file to change in between reads or for the reads to be directed at different locations.

Currently we either put the policy file inside the initrd or get it from the AA. If anything the gap between the C and the U will probably be smaller with this proposal. Hopefully anything that could modify the policy file will be measured and trusted.

[ariel-adam]

@bodzhang is this issue still relevant or can be closed? If it's still relevant to what release do you think we should map it to (mid-November, end-December, mid-February etc...)?

[bodzhang]

@ariel-adam, this issue is still relevant. The design relies on TEE supports, specifically, SEV-SNP and TDX. Depending on the progress of Kata CC SEV-SNP support, my guess for intercept timeline is mid-February, also considering the holiday season coming up.

[ariel-adam]

Set it to priority medium and drop CC-V0.4.0 (February)

[haosanzi]

First, I think if we implement something like this, we definitely want to have the attestation agent be the one that handles the verification rather than image-rs. Currently image-rs can get the config file from the attestation agent using the get_resource API. It wouldn't be too much work to implement a KBC that verifies the config against the host data before sending it to image-rs. This would be a good way to hide the platform-specific details from image-rs and other components, which I think is important.

Next week I am planning to propose adding a non-measured configuration to Kata. This would allow us to pass values from the shim to the guest without altering the launch measurement. I think what you're proposing would be yet another use for that.

As you may have seen in some of our older issues, we've gone back and forth a lot about the best way to have the KBC verify the identity of the KBS. So far we keep coming back to the idea that the KBS has to provide some secret that is verified not by the KBS, but by some other trusted party. For example, the KBS can provide a key that allows the workload to authenticate with a database. Only the authentic KBS can provide these credentials. This is more difficult with signatures because an attacker could use a fake KBS to send the wrong public key and could also use a fake registry to provide an image that is signed by the fake keypair. There is a chicken and egg problem when it comes to provisioning a key that verifies the identity of the KBS. I think this proposal is also susceptible. A malicious host could put the wrong hash values in the host_data field and then have a fake KBS approve the measurement. I think this is still worth pursuing, but I"m not sure it gives us a fool-proof way to verify the KBS identity. Let's talk about it next week.

hi, could you please provide the related link about non-measured configuration to Kata? Thank you very much @fitzthum

[fitzthum]

@haosanzi

hi, could you please provide the related link about non-measured configuration to Kata?

Nothing has been implemented, but I made this issue for it. https://github.com/kata-containers/kata-containers/issues/4541

[ariel-adam]

@bodzhang should this be moved to 0.6.0 or to a later release?

[bodzhang]

Closing this issue in the guest-components repo. The discussion is now happening in confidential-containers/confidential-containers#126 and confidential-containers/confidential-containers#171