-
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: get_token
API add runtime_data paramter
#465
Draft
jialez0
wants to merge
1
commit into
confidential-containers:main
Choose a base branch
from
jialez0:fix-get-token
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Even once the AS provides the nonce for the runtime data, how is the KBS supposed to verify the freshness? Normally in RCAR the KBS provides the nonce as part of the challenge, then the attestation must include the nonce. The KBS then insures that the nonce in the attestation matches the nonce that it chose for the challenge. The flow you have here isn't RCAR, it's just A, which I don't think is going to work. Even once you add an additional call to the AA to get a nonce, you still wouldn't be able to verify that the nonce was actually used.
I think we have a somewhat fundamental issue here. I think to be secure the protocol for connecting to the AS would need to look a lot more like RCAR. As in, the AA would return a token similarly to how a KBS would return a resource. I would envision
One issue is that currently the AS is not stateful so I don't know how it would do step 4. Looking at the steps, this is basically exactly what the KBS does. So I wonder if we should really bother with replacing it.
cc: @Xynnn007
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.
You are right. A challenge-response protocol like RCAR (which requires 4-round communication) would effciently prevent replay-attack in CoCoAS and I think @jialez0 will add that support inside CoCoAS later.
Another question is how we design the API of
get_token()
.Try to think about this: if we already had a challenge-response protocol in CoCoAS, the challenge-response protocol could be handled inside the CoCoAS'
get_token()
handler. The only reason why we need the API ofget_token()
to have extraruntime_data
argument is to specify the TEE public key. This is somehow a complicated situation.Overall, KBS and CoCoAS should be different separate component. We can embed the public key claims as runtime data to request CoCoAS to check integrity, but
runtime_data
like the public key and the other is thenonce
got from CoCoAS during the protocol logic insideget_token()
function.The reason why we face the delima is that we try to couple AS token's with KBS token.
AS token semantically means the endorsement of the evidence, and the claims against the reference values/policies are correct.
KBS token semantically means it is authorized to access specific resources. It is hard to say AS token have ability to work as an authorized token.
The coincidence is that they are the same now. TBO we now are using them without distinguishment, but it works fine so far regardless of the coupling.
My personal preference, in short term is
runtime_data
parameter toget_token()
.coco-as
token logic as what is implemented in this PR. This means this handler would support user-defined random runtime claims. The usage is defined by the caller.get_token()
will support public key generation, handshake with CoCoAS, and return the token with format that KBS recognizes. The handler of this token will not care about the givenruntime_data
parameter. This seems like a workaround before we have a more clear boundary between KBS token and AS token.In long term, we should carefully think about the authentication and authorization of attestation system, including
We'd better design this align with current standards without inventing new wheels. After initdata, we will have richer toolbox to achieve this.
does this make sense? @fitzthum @jialez0
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 think you're right that we are conflating the KBS Token and the AS Token. I think we're also trying to split the RCAR protocol between three different parties. This is very confusing.
Since we already have a way to support a passport mode, I am hesitant to go forward with something that isn't clear. I know that the existing approach is not semantically correct, but otherwise it seems like it works.
Here is one way we could think about passport mode with only one KBS. Maybe we should think about the AS token not as something that can stand in for the KBS token, but as something that can stand in for evidence. There is one problem with this approach but generally I think it makes sense.
Basically, the AA would still go through a full RCAR flow with the KBS, but instead of providing hw evidence in the attestation, it would provide the AS token. Then instead of contacting the AS to verify the attestation, the KBS would use this AS token directly.
The issue here is that if the AS token were generated before connecting to the KBS, I'm not sure how we would bind it to the public key and nonce needed in the RCAR.
Anyway, enjoy the new year. Afterwards maybe we can try to draw some diagrams.