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

Add ECDSA signature support to PSA Crypto backend #1734

Merged
merged 5 commits into from
Sep 12, 2023

Conversation

Roolli
Copy link

@Roolli Roolli commented Jun 29, 2023

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.

boot/bootutil/include/bootutil/caps.h Outdated Show resolved Hide resolved
@Roolli Roolli force-pushed the psa-ecdsa-enablement branch 2 times, most recently from 79b113e to d698133 Compare June 30, 2023 16:28
sim/Cargo.toml Outdated Show resolved Hide resolved
sim/mcuboot-sys/Cargo.toml Outdated Show resolved Hide resolved
sim/mcuboot-sys/Cargo.toml Outdated Show resolved Hide resolved
sim/mcuboot-sys/build.rs Outdated Show resolved Hide resolved
sim/mcuboot-sys/build.rs Outdated Show resolved Hide resolved
sim/mcuboot-sys/csupport/config-ecdsa.h Outdated Show resolved Hide resolved
boot/bootutil/include/bootutil/crypto/sha.h Outdated Show resolved Hide resolved
boot/bootutil/src/image_validate.c Outdated Show resolved Hide resolved
boot/bootutil/src/image_validate.c Outdated Show resolved Hide resolved
boot/bootutil/src/image_validate.c Show resolved Hide resolved
@davidvincze
Copy link
Collaborator

@nordicjm could someone from Nordic have a look at the SHA-related modifications? Thanks for the help!

@de-nordic
Copy link
Collaborator

@nordicjm could someone from Nordic have a look at the SHA-related modifications? Thanks for the help!

I will take a look.

@Roolli Roolli force-pushed the psa-ecdsa-enablement branch 2 times, most recently from 7b91822 to 39a49cc Compare July 20, 2023 14:53
Copy link
Collaborator

@de-nordic de-nordic left a 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

@davidvincze
Copy link
Collaborator

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.
If this PR is breaking something I would like to know about it and I would like to understand how.

@de-nordic
Copy link
Collaborator

de-nordic commented Jul 21, 2023

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. If this PR is breaking something I would like to know about it and I would like to understand how.

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
@davidvincze
Copy link
Collaborator

davidvincze commented Aug 3, 2023

@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!

@davidvincze
Copy link
Collaborator

@Roolli please check the ext/nrf/cc310_glue.h file and update it as required.

@de-nordic
Copy link
Collaborator

@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

@davidvincze
Copy link
Collaborator

davidvincze commented Aug 3, 2023

@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?

@@ -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"
Copy link

@oberon-sk oberon-sk Aug 7, 2023

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)

Copy link
Author

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.

@@ -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();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove "use" for consistency

Copy link
Collaborator

@nvlsianpu nvlsianpu left a 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.

Copy link
Collaborator

@nvlsianpu nvlsianpu left a 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?

Roland Mikhel added 4 commits August 22, 2023 09:39
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
@d3zd3z
Copy link
Member

d3zd3z commented Sep 5, 2023

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?

@adeaarm
Copy link
Contributor

adeaarm commented Sep 5, 2023

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

 SEQUENCE  {
     INTEGER r
     INTEGER s
 }

This means that the length information is part of the signature, in the length field of the ASN-1 TLV. When the signature is verified this structure is parsed and if the length does not match the length of (r,s) the verification fails. This is similar to how the curve information is encoded as part of the key encoding.

@d3zd3z
Copy link
Member

d3zd3z commented Sep 6, 2023

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.

@adeaarm
Copy link
Contributor

adeaarm commented Sep 6, 2023

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 image.h

/*
 * Image trailer TLV types.
 *
 * Signature is generated by computing signature over the image hash.
 * Currently the only image hash type is SHA256.
 *
 * Signature comes in the form of 2 TLVs.
 *   1st on identifies the public key which should be used to verify it.
 *   2nd one is the actual signature.
 */

the public key for ECDSA encodes the OID of the curve in ASN-1:

 SEQUENCE {
    SEQUENCE {
        OBJECT idEcPublicKey
        OBJECT namedCurve
    }
    BIT STRING publicKey
 }

i.e. from namedCurve you have the precise information about the curve used and this TLV is always present with the actual signature TLV (encoded as shown in the other comment). Please correct me if I am making wrong assumptions here, but I believe you have all the information you need already in the ASN-1 encodings to precisely identify the curve used and the associated signature pair.

@d3zd3z
Copy link
Member

d3zd3z commented Sep 7, 2023

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.

@de-nordic de-nordic self-requested a review September 7, 2023 16:09
@davidvincze davidvincze merged commit 5c00da4 into mcu-tools:main Sep 12, 2023
55 checks passed
@Roolli Roolli deleted the psa-ecdsa-enablement branch September 13, 2023 06:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants