First functional chunk of server code #5
Merged
Conversation
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
- Common types derived from OpenAPI specification. - Server adopts popular actix_web framework and stubs out handlers for the contracts defined in OpenAPI specification. - Veraison client integration code is sketched in but not working yet, possibly due to async/sync mismatch in programming styles. - No key store or key wrapping code implemented yet - this is a very partial first commit. Signed-off-by: Paul Howard <[email protected]>
Indicates how errors will be structured and mapped from inner-errors in the dependent libraries (using 'thiserror' crate). Use this to start stripping out some of the spurious unwrap() and expect() calls to reduce panic risks. Signed-off-by: Paul Howard <[email protected]>
…running in an async context. Veraison call-outs are now succeeding! Signed-off-by: Paul Howard <[email protected]>
Signed-off-by: Paul Howard <[email protected]>
Signed-off-by: Paul Howard <[email protected]>
Signed-off-by: Paul Howard <[email protected]>
…ces and remembers the information about the requested key. Challenges contain the state that needs to be remembered in between when the key access is first requested, and when the attestation evidence is submitted. Challenges are remembered in a simple hash table with random u32 keys. This code is not wired into the rest of the service yet. Signed-off-by: Paul Howard <[email protected]>
Signed-off-by: Paul Howard <[email protected]>
…P handlers using shared application state. Signed-off-by: Paul Howard <[email protected]>
…ugh still defaulting to the Linaro Veraison server. Signed-off-by: Paul Howard <[email protected]>
Signed-off-by: Paul Howard <[email protected]>
Signed-off-by: Paul Howard <[email protected]>
Signed-off-by: Paul Howard <[email protected]>
Signed-off-by: Paul Howard <[email protected]>
thomas-fossati
approved these changes
Aug 20, 2024
Signed-off-by: Paul Howard <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
feat: First functional chunk of code for the key broker server.
Implements the documented API, but with various limitations and TODOs. It provides enough that it can be tested and demonstrated.
Only supports Arm CCA attestation at the moment, although this restriction would be easy to lift.
The nonce/challenge value is currently hardcoded and not properly randomised. This allows the server to be tested with a mock client that just replays pre-baked CCA example tokens. Once we have a working client that gets real attestation tokens from the system, we can move to using properly randomised nonces.
The key broker stores a single key called "skywalker", and its value decodes to "May the force be with you.". This is hard-coded in the initialisation path at the moment. It would be better to read these from an input config file so that multiple keys can be stored.
Signed-off-by: Paul Howard [email protected]