kinvolk / azure-cvm-tooling Goto Github PK

I think we can use container images as a mechanism to transport artifacts from the GH runners to the CVM? This enables reproducibility of the test manually, if needed. No need to keep environments or make those keys available for later use.

But this won't remove the need of SSH key we will still need it because we want to execute commands on the CVM. Unless we use userdata or something like that to run commands inside the CVM.

Right now the e2e-test document uses a point in time fork, use upstream code instead of these branches.

The fork are used in the following places:

• https://github.com/kinvolk/azure-cvm-tooling/blob/main/docs/end-to-end-test.md#download-kbs-fork
• https://github.com/kinvolk/azure-cvm-tooling/blob/main/docs/end-to-end-test.md#download-the-aa-fork-code

Description

Compilation will fail if the lib is used in attester-only mode:

Checking az-snp-vtpm v0.2.0
error[E0433]: failed to resolve: use of undeclared crate or module `openssl`
   --> /home/magnuskulke/.cargo/registry/src/github.com-1ecc6299db9ec823/az-snp-vtpm-0.2.0/src/hcl.rs:155:21
    |
155 |     OpenSSL(#[from] openssl::error::ErrorStack),
    |                     ^^^^^^^ use of undeclared crate or module `openssl`

error[E0433]: failed to resolve: use of undeclared crate or module `openssl`
   --> /home/magnuskulke/.cargo/registry/src/github.com-1ecc6299db9ec823/az-snp-vtpm-0.2.0/src/vtpm.rs:142:21
    |
142 |     OpenSsl(#[from] openssl::error::ErrorStack),
    |                     ^^^^^^^ use of undeclared crate or module `openssl`

Impact

Cannot use the lib in attester-only mode. Openssl needs to be included.

Environment and steps to reproduce

included the lib w/ `default-features=false, features = ["attester"]

Expected behavior

Using the lib w/ attester-only feature should be possible.

Current situation

At the moment it's unclear how the individual functions can be composed into a remote attestation workflow.

Impact

Users might not be aware on how to use crate correctly.

Ideal future situation

Have an example that illustrates a workflow.

Implementation options

• Workspace example project that is consuming the crate
• Separate crate in a subfolder

Current situation

Currently the handling of HCL Runtime Data is not optimal for remote attestation workflows. In HclReportWithRuntimeData we store a parsed HCL Report struct (which is an envelope around an SNP report) and a parsed HCL Runtime Data struct. However, verification code also needs to access raw unparsed HCL Runtime Data bytes to compute a hash over it. Hence we have to expose multiple, overlapping deserialization functions:

let hcl_report: HclReportWithRuntimeData = evidence.report[..].try_into()?;
...
let (_, var_data) = buf_to_hcl_data(evidence.report)?;`

Context

This hash is included in the SNP report's report_data field, thereby linking the vTPMs public Attestation Key, which is embedded in HCL Runtime Data, to the SNP report.

Impact

Unintuitive API could make it harder to use the libraries primitives correctly.

Ideal future situation

The API adjust to the attestation workflow steps.

Implementation options

Two different parsing fn's are exposed for HCL Report and HCL Runtime Data.

Current situation

At the moment we just expose a function whether the tpm device can be opened, this doesn't necessarily mean that the host is a Azure SEV-SNP CVM.

Impact

A library user cannot detect with certainty that the platform is supported.

Ideal future situation

Expose a fn that will indicate that the platform is a CVM capable of performing SEV-SNP guest attestations.

Implementation options

There is probably useful information in:

• tpm sysfs
• IMDS

Current situation

The ARK and ASK keys are either retrieved from either IMDS or AMD KDS. Both ways are problematic, the former is not a trustworthy source for the ARK (root key) to use in verification of an SNP report¹ while the latter is subject to rate limits.

Impact

A verification process can fail due to unavailable KDS and impact the availability of a confidential workload.

Ideal future situation

The verification process should not depend on availability of a third party service or connectivity issues.

Implementation options

• Caching of ARK from KDS, use VCEK + ASK from IMDB
• Use bundled ARK from sev crate

• Right now, we update dependencies manually, but this can be automated pretty easily using dependabot.
• Enable cargo audit in the GHA pipelines.

In GH action workflow we only test SNP and there is no test for TDX, add support for TDX tests as well.

This documentation currently is good first start, but it can be improved to run AA & KBS both. Then talking to AA to see if we can retrieve the data.

Current situation

There is a security issue with the rsa crate, as tracked in #46. The issue is unlikely to be addressed in the medium term.

Impact

We should not be impacted by a security issue in that crate, since we only use its public key type. We won't be able to pass rustsec audit checks, however.

Ideal future situation

Pass the audit checks.

Implementation options

• Export DER byte slice. Leave it up to the consumer to convert.
• Create our own public key type. Leave it up to the consumer to convert.
• Use Openssl's pubkey type, currently only the verifier requires openssl, but since the tpm lib is linked to openssl we could also just use openssl for attester + verifier code

Additional information

Formally a breaking change because this is public api.

Description

az-cvm-vtpm: vtpm::VerifyError is unused and redundant. The actual error enum is in vtpm::verify::VerifyError. Removing this will be breaking change, because it's exposed publicly.

Impact

It's confusing for users.

Environment and steps to reproduce

n/a

Expected behavior

az-cvm-vtpm: vtpm::VerifyError should not be available.

Current situation

The current crate name doesn't reflect that it is covering an attestation flow specific to az cvms. There are alternative implementations combining vTPM w/ SEV-SNP.

Impact

Confusion. We shouldn't upload the package to crates.io using this name.

Ideal future situation

Have a name that reflects what the crate is providing.

https://github.com/kinvolk/azure-cvm-tooling/blob/main/az-snp-vtpm/src/hcl.rs

Static setup using terraform (or whatever is convenient)

• Create a RG that will run the CVM tests.
• Permissions to bring up a CVM in a RG only will be given via federated auth.

For each CI run

• Clone code and build binaries locally in the normal runners.
• Bring up a CVM, install dependencies for dynamically linked libraries.
• Copy (scp) the binaries over the the CVM.
• Run the example code and other tests. (replace the code that uses local check-in artifacts with the artifacts available on the machine)
• Clean up the CVM.

Marvin Attack: potential key recovery through timing sidechannels

Impact

Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

Patches

No patch is yet available, however work is underway to migrate to a fully constant-time implementation.

Workarounds

The only currently available workaround is to avoid using the rsa crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.

References

This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

See advisory page for additional details.

Current situation

Milan and Genoa use a different pair of ASK + ARK certificate chain. Milan is hardcoded (when requesting cert chain from AMD KDS). It makes for the time being, as the Azure CVM instances are Milan-based so far.

Impact

With the introduction of Genoa-Familiy instance types, KDS will be called with the wrong parameters fetched.

Ideal future situation

We provide forward compatibility for Genoa CPUs.

Implementation options

In the sev crate there is a platform detection heuristic (check which ASK signs the VCEK).

Additional information

This issue is mostly for tracking, it's not yet clear how CVM support would be implemented on Genoa instance types.

Current situation

Both the attester and verifier code parts are built as part of the library. In a remote attestation scenario, those functionalities will be executed on different machines. An attester executable doesn't need the verifier code and vice versa.

The verifier code relies on OpenSSL for elliptic curve cryptography, the attester code can be implemented by rust-native rsa crates.

Impact

It might be required to produce small, statically linked attester binaries for restricted targets like initrd. This can be challenging with an OpenSSL dependency.

Ideal future situation

We are able to build attester binaries without bundling or linking to OpenSSL (twice if the tpm lib is built w/ ossl as a dependency).

Implementation options

With feature toggles we opt out of a verifier dependency and thus openssl.