Add attested-tls crate

[ameba23]

This adds a the attested TLS crate which provides an attested certificate resolver, providing and handling renewal of TLS certificates with embedded attestations, and an attested certificate verifier, which can verify these attestations during the TLS handshake.

Note: This PR targets peg/add-attestation-crate as i needed stuff from that branch.

Attestation input data is computed as

SHA512(
  Der-encoded public key 
  || not before date as seconds big endian u64
  || not after date as seconds big endian u64
  || hostname
)

Features

• Both self-signed certificates and private certificate authorities are supported
• Verifier caches trusted certificates and skips subsequent attestation verification for them
• Attested client authentication supported

Things to be aware of

• Panics on poisoned mutex - which happens if a thread panics while holding the gaurd. If the code is correct this is acceptable because there should be no execution path in which this can happen.
• Attestation verifier currently blocks over an async call - see Calling async verify function from synchronous verify_server_cert function #2 - but this is being addressed in Add synchronous attestation verifier method #7

[0x416e746f6e]

question:

why do we prefer this method over underlying CryptoProvider::get_default()?

[ameba23]

Just for convenience it handles the error and clones.

[0x416e746f6e]

question:

similarly to above, why not just use the default? are there cases when user will want to have 2 different providers at the same time?

[ameba23]

Because otherwise we have to handle the case that there is no provider available during signature verification. We could actually replace this with just the signature algorithms for that provider, which is what we need it for.

[0x416e746f6e]

question:

should this be async too?

basically the whole chain of calls:

• AttestedCertificateResolver::new()
• AttestedCertificateResolver::new_with_provider()
• AttestedCertificateResolver::issue_ra_cert_chain()
• AttestedCertificateResolver::create_attestation_payload()
• AttestationGenerator::generate_attestation()
• AttestationGenerator::use_attestation_provider()

^-- is made async because we are calling external provider's URL via reqwest.

but since in normal scenarios this URL is supposed to be on a localhost, can we just use a blocking call instead?

[0x416e746f6e]

also, just in case some of these commits are useful: #20

[ameba23]

I actually was thinking of going in the opposite direction - to make attestation generation always be async by using tokio's filesystem API when getting the quotes. See entropyxyz/configfs-tsm#10

We know that quote generation is generally slow. I don't fully understand the tradeoffs of using blocking APIs from the tokio runtime, but in my understanding it is something you are supposed to avoid. So this choice depends a bit whether the caller is using tokio right?

[0x416e746f6e]

even though quote generation is slow, we are not winning anything by marking AttestationGenerator::generate_attestation() async on the path where it uses dcap::create_dcap_attestation() b/c the latter is blocking.

it's the same as marking function async while still using std::thread::sleep() in it (instead of tokio::time::sleep()).

unless underlying configfs-tsm crate offers async counterparts to its quote-generating methods I don't see a point of tagging functions async just because they are slow.

[ameba23]

I am the maintainer of that crate, which really just reads and writes files using std::fs, and i have an open PR to use tokio::fs (linked above).

But we could also switch to dstack's quote generation crate, which is likely much better. I can't remember whether it is async or not, need to find it...

[0x416e746f6e]

if dstack uses tokio::fs (or configfs-tsm starts to), yes, then switching to async would make sense. this way we would at least avoid blocking tokio workers

[ameba23]

dstack's tdx-attest crate also provides a synchronous api, using std::fs to read and write to configfs-tsm:

https://github.com/Dstack-TEE/dstack/blob/3a456dd6e332509f97e7ef3d83758ca3ea35770c/tdx-attest/src/linux.rs#L286-L329

I would strongly consider switching to their crate as generally their stuff is used in production and well maintained. It also has some extra features like falling back to vsock if configfs is not available. But i would wanna give it a proper review before switching.

So:

• I think we should move to synchronous api for AttestationGenerator as you propose.
• but if attestation generation is called from a tokio runtime, it should really be wrapped in spawn_blocking to prevent it from causing the tokio executor to wait.

[0x416e746f6e]

agree. let's do it

[0x416e746f6e]

🚢 🛳️ 🐑

[0x416e746f6e]

issue:

#25

[0x416e746f6e]

issue:

#25

[ameba23]

Good catch