-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AA/kbs_protocol: Update to 0.2.0 to fix JWE decryption logic due to RFC7516 #820
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we should also bump KBS_PROTOCOL_VERSION
. Is there a rationale how we increase the versions. would it be 0.2.0
or 0.1.1
. if it's a breaking change, not merely additive, I would assume we have to bump it to 0.2.0
.
@mkulke Updated the protocol version.
|
cc @deeglaze |
We don't need to change the test image if the protocol version changes so the |
This will make the CI red. The client side code now will use the If you do not want to change the test image. It would make sense once I get approvals of this PR w/ the commit that changes test image built from the KBS side code. Then I revert the test image part of the commit. The CI will be red, but we all know what happened and get the PR merged. |
c89b96b3 has regression. There is no |
Once confidential-containers/trustee#600 gets merged, we can restart the failed CI here and it will be green. |
Ok. All tests passed. I think it can be merged now |
This still doesn't protect the protected headers. And example https://datatracker.ietf.org/doc/html/rfc7516#section-3.3 particularly this item:
|
@deeglaze Thanks for this! Let me do a deeper fix tomorrow. |
Seems that the current |
c496ed0
to
1729cf0
Compare
Let's wait for virtee/kbs-types#45 to be merged, too |
The lint error is not related to this PR. Fixed in #828 |
80308ec
to
a739c05
Compare
182f0c0
to
7d280e2
Compare
Let's wait for the upstream fix to be merged and then I will take a rebase. Other parts are ready for review. |
b0fee4f
to
169af3d
Compare
Changes happen since last approvals. PTAL @huoqifeng @mkulke |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I finally reviewed this PR. I have maybe 2 comments that are important (possibly there is a little bug) and a bunch of less important suggestions.
let nonce = Nonce::from_slice(iv); | ||
let mut plaintext = encrypted_data.to_vec(); | ||
cipher | ||
.decrypt_in_place_detached(nonce, aad, &mut plaintext, tag.into()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we using the detached
version of this function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The non-detached
version implies the tag
lies as the suffix of the cipher text, while jwe detaches tag
as a separate claim in jwt.
bail!("Unmatched curve: {}", crv); | ||
} | ||
|
||
let cek = key.unwrap_key(cipher_text, x, y, KeyWrapAlgorithm::EcdhEsA256Kw)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are using x
and y
from the header here. Should we be using them from the public key that we store? The RSA methods don't take the public key from the header but for EC we do. What is the thinking behind this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Due to https://datatracker.ietf.org/doc/html/rfc7518#section-4.6, The x
and y
here are of ephemeral key
. They are used to make a Diffie Hellman protocol with x
and y
of the key we store to finally derive the decryption key to decrypt the ciphertext. The logic of obtaining decryption key with elliptic curve is different from that of RSA directly decrypting with private key.
This patch adds more crypto suites to the crypto crate 1. Add AES-256-GCM AEAD API. 2. Mark RSA PKCS#1 v1.5 Padding encryption scheme as "deprecated". 3. Add EC suites for key wrapping. Now supports P256 curve and ECDH-ES-A256KW algorithm. Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
This patch updates KBS protocol to v0.2.0. The change mainly includes 1. Replace RSA-PKCS1v15 to ECDH-ES-A256KW. The former algorithm is not declared as deprecated in https://www.ietf.org/archive/id/draft-madden-jose-deprecate-none-rsa15-00.html#section-1.2 Also, some fixups to make the KBS protocol's Response fully compatible with JWE standard are made, including explicitly parse `tag` in the flattened JSON serialization. Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
Fixed the comments and take a rebase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for taking this on.
Last call for review before this is merged.
Ok, let's try to get the Trustee side in soonish. |
Per RFC7516, the AEAD's auth tag should be included inside the JWE body. We fix this to align with trustee sideconfidential-containers/trustee#597
Let's wait after confidential-containers/trustee#597 gets merged.This patch does a bunch of fixes per RFC7516.
tag
part.RSA OAEP
andECDH-ES+A256KW
(by default)RSA PKCS#1 v1.5
padding scheme as deprecated as it is not recommended.