KMS: add API definitions and crate for KMS integration #189
Conversation
Xynnn007
force-pushed
the
feat-kms
branch
3 times, most recently
from
f5cff4b
to
96f486a
Compare
deps/kms/src/plugins/sample.rs
Outdated
| const IV: &[u8] = b"unique nonce"; | ||
|
|
||
| /// Only for sample | ||
| pub const EXAMPLE_CMK: &[u8] = &[ |
There was a problem hiding this comment.
It is Customer Master Key abstraction. Different KMS will call it a different name. The core idea of this key is that it never leave KMS in plaintext. Sometimes it is also named "key encryption key".
deps/kms/src/api.rs
Outdated
| async fn decrypt(&mut self, ciphertext: &[u8]) -> Result<Vec<u8>>; | ||
|
|
||
| /// Export the key blob that can be used to reconstruct the Datakey | ||
| /// except the plaintext of the Datakey. |
There was a problem hiding this comment.
what does this part mean "except the plaintext of the datakey"?
There was a problem hiding this comment.
In my mind the key blob will be stored in KBS. When the datakey is to be used, KBS can use this blob to reconstruct the plaintext of this datakey. But the plaintext cannot appear when the key blob is being stored. Usually the ciphertext of the datakey, the CMK (a.k.a key encryption key) id to encrypt this datakey, etc are in the key blob.
deps/kms/src/lib.rs
Outdated
| //! - KMS can help to decrypt the ciphertext of the key to get the plaintext | ||
| //! of the key. |
There was a problem hiding this comment.
why do we need the KMS to "decrypt the ciphertext of the key", if "the plaintext of the key can be exported outside the KMS".
i thought keys were going to be wrapped using a TEE pubkey.
There was a problem hiding this comment.
This design philosophy comes from the API design from aliyun KMS, aws KMS etc. It is similiar to "Envelope encryption", s.t. wrap the datakey with CMK.
deps/kms/src/plugins/sample.rs
Outdated
| async fn encrypt(&mut self, plaintext: &[u8]) -> Result<Vec<u8>> { | ||
| let encryption_key = Key::<Aes256Gcm>::from_slice(&self.key); | ||
| let cipher = Aes256Gcm::new(encryption_key); | ||
| let nonce = Nonce::from_slice(IV); |
There was a problem hiding this comment.
This is kind of a bad example, because the IV needs to be returned together with the ciphertext.
And decrypt needs to receive the IV.
This commit include the following: - Added a crate `deps/kms` - Added Datakey API abstraction inside `deps/kms` - Added KMS module API abstraction inside `deps/kms` - Implemented an example for KMS Signed-off-by: Xynnn007 <[email protected]>
Also, use rstest dep v0.17.0 for all subcrates under this repo Signed-off-by: Xynnn007 <[email protected]>
Signed-off-by: Xynnn007 <[email protected]>
|
Hi @jepio , I've updated the PR to try to simplify the API. Also, |
|
So the interface now is:
If this is only for image decryption/encryption then that's probably good enough, but we'll need to see how the API fits existing implementations. |
|
I'm gone for 1 week so don't wait for me. |
|
@jepio This is a basic abstraction for KMSes. We can use this as a primitive to construct the image en/decryption. After this PR I will open another to impl this. |
This PR include the following:
deps/kmsdeps/kmsdeps/kmsrelated to confidential-containers/guest-components#188
This PR will help to give a basic lib for image en/decryption using KMS.
cc @fitzthum @jialez0