KBS: Update KBS protocol to 0.2.0 to fix JWE format due to RFC7516

[Xynnn007]

Fixes #583.

This patch does a bunch of fixes per RFC 7516.

1. AEAD Auth Tag is now expcilitly included inside the tag part.
2. Add new JWE algorithms RSA OAEP and ECDH-ES+A256KW
3. Mark RSA PKCS#1 v1.5 padding scheme as deprecated as it is not recommended.
4. Add unit tests based on josekit to check the compatibility of JWE used by Response.
5. Update rust toolchain to 1.83.0

depends on
virtee/kbs-types#53

[Xynnn007]

Ok the test error happened because the guest-components side code is old. I just put another commit that references my repo to include the commit that includes the AEAD update.

I think we can merge GC side code firstly. Then go back to this PR. Then another PR on gc side to revert the test image change.

[Xynnn007]

I removed the kbs_protocol updating commit. The CI must fail. We can merge confidential-containers/guest-components#820 (comment) first and I will add the kbs_protocol updating commit back to this PR to make the CI happy.

[Xynnn007]

cc @deeglaze

[Xynnn007]

Test locally and passed. Let's wait for virtee/kbs-types#45 to be merged and update the kbs-types crate rev.

[Xynnn007]

Hi @tylerfanelli I added the aad and tag parts to this document. They all follow RFC7516. Thanks for the help from upstream kbs-types.

[tylerfanelli]

Test locally and passed. Let's wait for virtee/kbs-types#45 to be merged and update the kbs-types crate rev.

Released here.

[deeglaze]

also, we get a build warning now, similar to jwcrypto, RSA1_5 seems to be deprecated in josekit:

This is my plan. To use ecdsa keys in this PR, too

hmm, I wouldn't switch to EC for TEE keys without more consideration.

All the technologies depend on ECC already, and it’s much faster to generate keys at boot for ECC. The coconut-svsm project will be switching to ecc from rsa.

[mkulke]

All the technologies depend on ECC already, and it’s much faster to generate keys at boot for ECC. The coconut-svsm project will be switching to ecc from rsa.

I guess that's fair. I remember asking about this at one point and there was a limitation for some TEE that would make switching the TEE keypair to EC hard. I don't remember details though and the concern might not be valid anymore. We can just go ahead, and we'll notice problems on a CI somewhere.

[deeglaze]

also, we get a build warning now, similar to jwcrypto, RSA1_5 seems to be deprecated in josekit:

warning: use of deprecated variant josekit::jwe::RSA1_5: This algorithm is no longer
recommended.

is this something that should concern us, can we change our TEE key algo? it might be a good point in time since we're about to have a breaking protocol change anyway

Please. I’d advocate for a couple changes actually. KBS ought to distinguish between keys and secrets to allow for different handling. For example, we would prefer to store a key encryption key (aes-256-kw or kwp) wrapped by an HSM key and use attestation as part of authorization to rewrap the key to a key derived from a shared secret between the TEE and HSM. This is the COSE algorithm ECDH-ES-HKDF-256. The salt for the hkdf can be a parameter. It does mean sending more data to kbs, but it allows kbs to be less stateful, and it allows keys to be hsm protected in an attestable way, provided you have key creation attestations for the wrapping key. The key material is only visible to the HSM and the TEE. You’ll want to ensure through attestation that the TEE key forwarded from the verifier to the HSM is only the one from the TEE to make sure the verifier isn’t sneakily rewrapping the key to its own key too, but we’ve known that verifiers should be attested.

Initial provisioning of keys from first boot becomes a requirement.

When you have keys protected in their own way, you can use the appropriate algorithms for key wrapping in transit. For secrets like rollback counters, you can use the current JWE, since there’s generally no service-specific non-extraction requirement for secrets the way there are with keys.

[mkulke]

Please. I’d advocate for a couple changes actually. KBS ought to distinguish between keys and secrets to allow for different handling. For example, we would prefer to store a key encryption key (aes-256-kw or kwp) wrapped by an HSM key and use attestation as part of authorization to rewrap the key to a key derived from a shared secret between the TEE and HSM. This is the COSE algorithm ECDH-ES-HKDF-256. The salt for the hkdf can be a parameter. It does mean sending more data to kbs, but it allows kbs to be less stateful, and it allows keys to be hsm protected in an attestable way, provided you have key creation attestations for the wrapping key. The key material is only visible to the HSM and the TEE. You’ll want to ensure through attestation that the TEE key forwarded from the verifier to the HSM is only the one from the TEE to make sure the verifier isn’t sneakily rewrapping the key to its own key too, but we’ve known that verifiers should be attested.

Initial provisioning of keys from first boot becomes a requirement.

When you have keys protected in their own way, you can use the appropriate algorithms for key wrapping in transit. For secrets like rollback counters, you can use the current JWE, since there’s generally no service-specific non-extraction requirement for secrets the way there are with keys.

thx, it might be good to copy your thoughts to a discrete issue on this repo (verbatim is fine), since we probably won't fully address it in this PR (i hope 😅) and it's easier to track this way. I understand there are venues to decouple kbs from the handling of key material, so I feel there might be a conceptual overlap with sealed secrets/KMS/HSM backends and it's probably good to understand which role those facilities would play in the suggested scheme. There's also a dedicated Trustee Sync, which would be a great place to present those ideas.

[Xynnn007]

@deeglaze Thanks for the suggestion! If interested, please feel free to join our bi-weekly meeting mentioned by Magnus to share your great ideas.

I replaced RSA PKCS1v15 with ECDH-ES+A256KW (Concat KDF is used as KDF) on curve P256.

I still worry about the perfect forward secrecy that seems not to be fully conquered by JWE. Thus I am considering to promote it in future with existing TLS suites to improve this.

Newly edited: ECDH-ES-HKDF-256 looks similar with ECDH-ES+A256KW. They both use an ephemeral Elliptic Curve key pair from KBS side and the Elliptic Curve public key stated by TEE public key to negotiate a shared secret to derive a shared encryption key. The flaw is once the TEE private key is exposed to an attacker, the historical data flow can be decrypted by recalculating the shared secret. To cover this, we might need some mechanism to negotiate a shared secret based on both sides' ephemeral Elliptic Curve key pair, where the TEE public key is only used to sign the ephemeral Elliptic Curve public key part from TEE side. In this case, even if the TEE public key is exposed to an attacker, the attacker still cannot recover the historical ephemeral Elliptic Curve key pair thus cannot re-construct the shared encryption key. Thus the historical data flow is still confidential.

[Xynnn007]

I did some change upon the PR description. Compability tests are passed with josekit crate. Now we can wait for upstream PR to get merged and then I rebase the dep.

[fitzthum]

LGTM. Thanks for taking care of this