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.

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

Allow the usage of builtin keys in verification #1932

Merged
merged 3 commits into from
Apr 10, 2024

Conversation

davidvincze
Copy link
Collaborator

Introduce a new MCUBOOT_BUILTIN_KEY option to enable the usage of
builtin keys for signature verification. This way the details of the key
handling mechanism are abstracted away from the boot code and this
responsibility is delegated to the given crypto library.
This is an alternative option to the existing MCUBOOT_HW_KEY feature,
however in this case we can entirely rely on key IDs and not only the
code, but also the image metadata does not contain any public key data.

Enable the usage of builtin keys in the ECDSA verification module with
the PSA Crypto API based cryptographic backend.
This way parsing and importing the verification keys can also be avoided.

@nvlsianpu nvlsianpu added the area: core Affects core functionality label Apr 4, 2024
Introduce a new MCUBOOT_BUILTIN_KEY option to enable the usage of
builtin keys for signature verification. This way the details of the key
handling mechanism are abstracted away from the boot code and this
responsibility is delegated to the given crypto library.
This is an alternative option to the existing MCUBOOT_HW_KEY feature,
however in this case we can entirely rely on key IDs and not only the
code, but also the image metadata does not contain any public key data.

Change-Id: Id01b67951310549b2734730c58bfa7210a2d5236
Signed-off-by: David Vincze <[email protected]>
Enable the usage of builtin keys in the ECDSA verification module with
the PSA Crypto API based cryptographic backend.
This way parsing and importing the verification keys can also be avoided.

Change-Id: I6ada1ef8ed04a3f12c228ef399e3a7b8ebc7fb5e
Signed-off-by: David Vincze <[email protected]>
Signed-off-by: David Vincze <[email protected]>
Change-Id: I730a02067c0c51c46189e86fa5ddd0f325311874
@tamasban
Copy link
Collaborator

tamasban commented Apr 8, 2024

LGTM as an initial support for builtin keys. However, in the long run, might be better to provide a user-facing solution to specify the key ID. In the current solution, it is the responsibility of the crypto library. It seems hidden to me, and might not fit to a general crypto library.

Options could be:

  • provide a HAL API
  • add a TLV which holds the key-id

Could you open an issue to track this?

@davidvincze
Copy link
Collaborator Author

davidvincze commented Apr 9, 2024

LGTM as an initial support for builtin keys. However, in the long run, might be better to provide a user-facing solution to specify the key ID. In the current solution, it is the responsibility of the crypto library. It seems hidden to me, and might not fit to a general crypto library.

Options could be:

  • provide a HAL API
  • add a TLV which holds the key-id

Could you open an issue to track this?

I've just opened an issue to track: #1935
The current code was meant as an initial "solution", a better mechanism is up for discussion.

@d3zd3z d3zd3z merged commit 93c3f78 into mcu-tools:main Apr 10, 2024
55 checks passed
@davidvincze davidvincze deleted the builtin-keys branch April 11, 2024 07:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: core Affects core functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants