-
Notifications
You must be signed in to change notification settings - Fork 674
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
Add ECDSA signature support to PSA Crypto backend #1734
Conversation
2fbdb4f
to
458b69b
Compare
79b113e
to
d698133
Compare
@nordicjm could someone from Nordic have a look at the SHA-related modifications? Thanks for the help! |
I will take a look. |
7b91822
to
39a49cc
Compare
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 have enough #1754
Could you please elaborate on this in the focus of this change? You mention encryption in the issue, and I know there is at least one PR that I know of introducing some modifications to the encryption code, but in this case it's about the signature. |
Build me MCUboot for Zephyr with BOOT_ENCRYPT_EC256 enabled; you can use latest Zephyr with current mcutools/main, preferred platform is nrf52840dk. |
This commit enables ECDSA signature verification using PSA Crypto API. Signed-off-by: Roland Mikhel <roland.mikhel@arm.com> Change-Id: I51c7aadba03348f335e89d9252e70c09f8787f30
39a49cc
to
d28eeea
Compare
@de-nordic may I ask you to review the changes around the hash functions, just to make sure these modifications won't cause you any problems with the integration work. Please request changes or approve because currently this PR is blocked for unrelated reasons thus delaying our work as well. Thank you! |
@Roolli please check the ext/nrf/cc310_glue.h file and update it as required. |
Here is commit, on sdk-nrf, that fixes th cc310 for us: nrfconnect/sdk-mcuboot@ae4344b |
Thank you for the patch. Is this broken? Has the CC-310 API been changed in the meantime? Could you recommend a preferred Zephyr platform with CC-310 to test these modifications with? |
.github/workflows/sim.yaml
Outdated
@@ -44,6 +44,8 @@ jobs: | |||
- "sig-rsa validate-primary-slot ram-load multiimage" | |||
- "sig-rsa validate-primary-slot direct-xip multiimage" | |||
- "sig-ecdsa hw-rollback-protection multiimage" | |||
- "sig-ecdsa-psa psa-crypto-api" |
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.
towards a consistent naming, psa
should not be specified twice
how about:
sig-ecdsa psa-crypto-api sig-p256
sig-ecdsa psa-crypto-api sig-p384
or
sig-ecdsa-psa sig-p256
sig-ecdsa-psa sig-p384
the latter fits better with the previous scheme and the psa-crypto-api
feature should then be removed
(both proposals require changes in built.rs)
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.
Hi, thanks for the suggestions. I've implemented the second approach as it fits the current scheme more, but I opted not to add an algorithm specifier for p256 as that's the default.
d28eeea
to
383338e
Compare
sim/mcuboot-sys/build.rs
Outdated
@@ -15,6 +15,8 @@ fn main() { | |||
let sig_rsa3072 = env::var("CARGO_FEATURE_SIG_RSA3072").is_ok(); | |||
let sig_ecdsa = env::var("CARGO_FEATURE_SIG_ECDSA").is_ok(); | |||
let sig_ecdsa_mbedtls = env::var("CARGO_FEATURE_SIG_ECDSA_MBEDTLS").is_ok(); | |||
let sig_ecdsa_psa = env::var("CARGO_FEATURE_SIG_ECDSA_PSA").is_ok(); | |||
let sig_use_p384 = env::var("CARGO_FEATURE_SIG_USE_P384").is_ok(); |
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.
remove "use" for consistency
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 reviewed the code roughly,
looks sane to me. Don't see any regression.
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.
@de-nordic Can you run your smoke tests suite on this PR?
This commit enables ECDSA signature verification using PSA Crypto API. Signed-off-by: Roland Mikhel <roland.mikhel@arm.com> Change-Id: I33f559ecdd59b1ce41c6a2d5f315212300d585e3
Currently all the hashing functionality is done with SHA256 but if we would like to use ECDSA-P384 that requires SHA384 as the hashing algorithm, but MCUboot is using SHA256 for image hashing and public key hashing. This commit modifies the hashing operations to use SHA384 thus SHA256 can be omitted which is beneficial from a code size standpoint. Signed-off-by: Roland Mikhel <roland.mikhel@arm.com> Change-Id: I59230f76f88e0b42ad6383b2c9b71b73f33d7dd7
Currently all the hashing functionality is done with SHA256 but if we would like to use ECDSA-P384 that requires SHA384 as the hashing algorithm. However, MCUboot is using SHA256 for image hashing and public key hashing. This commit modifies the hashing operations to use SHA384 thus SHA256 can be omitted which is beneficial from a code size standpoint. Signed-off-by: Roland Mikhel <roland.mikhel@arm.com> Change-Id: I364eefe334e4fe6668b8a3b97991b5dbb0c80104
Add ECDSA verification tests to the CI using the PSA Crypto API Signed-off-by: Roland Mikhel <roland.mikhel@arm.com> Change-Id: I904c8929f355ec791ff28ac7c3e0ca3832b2403d
383338e
to
b885890
Compare
So, one question that isn't clear to me. How are we distinguishing 256 and 384 bit ECDSA signatures in the TLV? Do we just rely on the size of the signature? What happens if there is a 256 bit signature in the TLV, but the build is configured for 384 bit signatures? Does it fail properly, or does something confusing happen. I thought we were going to add an extra TLV to specify the signature size that should be given before the ECDSA signature, and would default to 256, but in the 384 case would be present to suggest a new signature length? |
Signatures encoding in ASN-1 is
This means that the |
This does work to distinguish a given 256 bit key and a given 384 bit key. However, there are multiple curves possible at each of these sizes. Perhaps we are just saying in MCUboot that we will only ever support one key of a given size, but it seems like it might be a good idea to at least think of encoding the actual key type used, as the size isn't sufficient to determine which key is being used. |
From
the public key for ECDSA encodes the OID of the curve in ASN-1:
i.e. from |
The public key has the OID of the algorithm used, but the signature itself is just r and s encoded in asn.1. We do reference a hash of the public key, so perhaps that is sufficient. I'm just going off other signature formats, such as COSE where the algorithm is always encoded as part of the signature. |
Following up on the recent addition of the PSA Crypto API in MCUBoot, this PR adds the ability to verify ECDSA P256 and P384 signatures. If P384 is being used the hashing algorithm switches to SHA384.