Skip to content
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.

Sign up for GitHub

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

Jump to bottom

CMIDs should hold key material #1753

Open
bluegate010 opened this issue Oct 30, 2024 · 0 comments
Open

CMIDs should hold key material #1753

bluegate010 opened this issue Oct 30, 2024 · 0 comments
Assignees
@swenson

Comments

@bluegate010
Copy link
Contributor

https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md describes CMIDs, which hold metadata describing keys held in Caliptra DCCM. This imposes use-case scaling restrictions based on the amount of DCCM available. In addition, the ability to import keys of varying size mean that fragmentation may occur.

We can resolve these concerns by having CMIDs also hold the relevant key material. CMIDs are encrypted with random per-boot keys, meaning Caliptra remains the only entity that can observe the raw keys.

ML-DSA should not be a concern, because key material is stored as a seed.
@bluegate010 bluegate010 mentioned this issue Oct 31, 2024
Open
swenson added a commit that referenced this issue Nov 15, 2024
@swenson
runmtime docs: Remove storage from cryptographic mailbox
4133625 
Mostly.

We need to keep a limited amount of storage per AES-256-GCM key to track
usage, since these keys can only be used a certain number of times due
to their IV problems.

For HMAC, we don't specify a key usage on the output MAC, since it has
to be imported back into Caliptra to be used as a key, where its usage
will have to be specified.

We also fix a few other minor issues with the mailbox documentation:

Fixes #1753
Fixes #1754
Fixes #1755
Fixes #1756
swenson added a commit that referenced this issue Nov 15, 2024
@swenson
runtime docs: Remove storage from cryptographic mailbox
018e058 
Mostly.

We need to keep a limited amount of storage per AES-256-GCM key to track
usage, since these keys can only be used a certain number of times due
to their IV problems.

For HMAC, we don't specify a key usage on the output MAC, since it has
to be imported back into Caliptra to be used as a key, where its usage
will have to be specified.

We also fix a few other minor issues with the mailbox documentation:

Fixes #1753
Fixes #1754
Fixes #1755
Fixes #1756
@swenson swenson mentioned this issue Nov 15, 2024
Open
swenson added a commit that referenced this issue Nov 20, 2024
@swenson
runtime docs: Remove storage from cryptographic mailbox
99919dc 
Mostly.

We need to keep a limited amount of storage per AES-256-GCM key to track
usage, since these keys can only be used a certain number of times due
to their IV problems.

For HMAC, we don't specify a key usage on the output MAC, since it has
to be imported back into Caliptra to be used as a key, where its usage
will have to be specified.

We also fix a few other minor issues with the mailbox documentation:

Fixes #1753
Fixes #1754
Fixes #1755
Fixes #1756
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@swenson swenson

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@swenson @bluegate010