Re: SWUpdate - Multiple key configuration

[Stefano Babic]

Hi Andrew,

On 27.04.21 01:22, Mulbrook, Andrew wrote:
> Hi Stefano,
>
>
> We were looking at utilizing swupdate in a project, but have some use
> cases where supporting a package signed multiple ways may be necessary.
> I've attached a patch to show a potential solution we were looking at
> (patch compiles but hasn't been tested).

The first thing to understand is not the implementation, but which are
the goals and the use cases. Having multiple signature let me think to
some use cases, that are already solved in other ways. One common use
case is the OEM: manufacturer sends device and software to OEM, an dhe
shouuld be able to sign it as well. However, this is solved using a PKI
and certificates, and manufacturer is the CA and delivers certificates
to his OEMs. SWUpdate is already able to work with it.

I do not find a use case where all signatures must be verified at once -
please explain which is the use case and what is thought to be solved
adding multiple signatures.

>
>
> Apologies for the direct email, I'm still looking at sending mails to
> the public google group

Forwarded to ML

> but wanted to make sure there weren't any strong
> objections that would lead to another approach being required.

Nevertheless, there is a weak dependency with the file type of the
signature, even if it is today hard-coded as sw-descriuption.sig. The
hard dependency is that signature is the second file in the stream,
while sw-description must be the first.

Best regards,
Stefano Babic

>
>
> Thanks for your time!
>
>
> Best Regards,
>
> Andrew
>
>
> ------------------------------------------------------------------------
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole
> use of the intended recipient(s) and contain information that may be
> Garmin confidential and/or Garmin legally privileged. If you have
> received this email in error, please notify the sender by reply email
> and delete the message. Any disclosure, copying, distribution or use of
> this communication (including attachments) by someone other than the
> intended recipient is prohibited. Thank you.


--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Mulbrook, Andrew]

> From: Stefano Babic <sba...@denx.de>

>> We were looking at utilizing swupdate in a project, but have some use
>> cases where supporting a package signed multiple ways may be necessary.
>> I've attached a patch to show a potential solution we were looking at
>> (patch compiles but hasn't been tested).

> The first thing to understand is not the implementation, but which are the goals and the use cases. Having multiple signature let me think to some use cases, that are already solved in other ways. One common use case is the OEM: manufacturer sends device and software to OEM, an dhe shouuld be able to sign it as well. However, this is solved using a PKI and certificates, and manufacturer is the CA and delivers certificates to his OEMs. SWUpdate is already able to work with it.

> I do not find a use case where all signatures must be verified at once - please explain which is the use case and what is thought to be solved adding multiple signatures.

The main goal is to allow key-rotation in situations where hardware in the field is not yet updated (assume no in field network connectivity, updates are hand-delivered). Signing the same software with both new and rotated out key allows updates without forcing the new key to be distributed first. They key element is 1 update for hardware with differing installed key sets / authorities. Ideally, we'd like to keep the simple RSA signature mechanism.

>> but wanted to make sure there weren't any strong objections that would
>> lead to another approach being required.

> Nevertheless, there is a weak dependency with the file type of the signature, even if it is today hard-coded as sw-descriuption.sig. The hard dependency is that signature is the second file in the stream, while sw-description must be the first.

This explains some things I was seeing when testing this. Would a patch to add multiple signatures to the sw-description.sig be more acceptable? We could simply append all signatures together and rotate through. This could be guarded by menuconfig option.

Best Regards,
Andrew

________________________________

[Stefano Babic]

Hi Andrew,

On 27.04.21 17:09, Mulbrook, Andrew wrote:
>> From: Stefano Babic <sba...@denx.de>
>>> We were looking at utilizing swupdate in a project, but have some use
>>> cases where supporting a package signed multiple ways may be necessary.
>>> I've attached a patch to show a potential solution we were looking at
>>> (patch compiles but hasn't been tested).
>
>> The first thing to understand is not the implementation, but which are the goals and the use cases. Having multiple signature let me think to some use cases, that are already solved in other ways.
> One common use case is the OEM: manufacturer sends device and software to OEM, an dhe shouuld be able to sign it as well. However, this is solved using a PKI and certificates, and manufacturer is the CA and delivers certificates to his OEMs. SWUpdate is already able to work with it.
>
>> I do not find a use case where all signatures must be verified at once - please explain which is the use case and what is thought to be solved adding multiple signatures.
>
> The main goal is to allow key-rotation in situations where hardware in the field is not yet updated (assume no in field network connectivity, updates are hand-delivered). Signing the same software with both new and rotated out key allows updates without forcing the new key to be distributed first. They key element is 1 update for hardware with differing installed key sets / authorities.

Just appearently : if the new key is delivered due to a security reason,
you have tons of HW accepting software with the old key. This can help
in a mixed conditions (a mix in field of devices with new and old keys,
and nobody can track it) - but again, it is even a well known use case
with certificates. It does not matter if your SWU is signed with an old
or new certificate, until they are released by the same CA SWUpdate is
able to verify both.

> Ideally, we'd like to keep the simple RSA signature mechanism.

Yes, but RSA keys suffer for this limitattion - you will be better
served by switching to CMS.

>
>>> but wanted to make sure there weren't any strong objections that would
>>> lead to another approach being required.
>
>> Nevertheless, there is a weak dependency with the file type of the signature, even if it is today hard-coded as sw-descriuption.sig. The hard dependency is that signature is the second file in the stream, while sw-description must be the first.
>
> This explains some things I was seeing when testing this. Would a patch to add multiple signatures to the sw-description.sig be more acceptable?

Yes, it is. It is quite transparent to the code,

> We could simply append all signatures together and rotate through. This could be guarded by menuconfig option.

Another point you can consider is to extend SWUpdate's keystore.
Currently, SWUpdate loads just one key or one CA certificate. Having
multiple keys or multiple certificates that SWUpdate (or better, openSSL
or the other crypto implementation) could be an option for you.


Best regards,
Stfeanon Babic

[Mulbrook, Andrew]

>> From: Stefano Babic <sba...@denx.de>

> Just appearently : if the new key is delivered due to a security reason,
> you have tons of HW accepting software with the old key. This can help
> in a mixed conditions (a mix in field of devices with new and old keys,
> and nobody can track it) - but again, it is even a well known use case
> with certificates. It does not matter if your SWU is signed with an old
> or new certificate, until they are released by the same CA SWUpdate is
> able to verify both.

I think this is the fundamentals of the use case. We have multiple
devices in field with potentially outdated PKI information and no network
connectivity. The desire is to allow acceptance of an update by including
a signature done with the outdated signer information and require
devices with updated software to accept only the newer signature. In
other words, we want a single update to operate correctly on old
hardware without updated certificates and new hardware with updated
certificates.

> Yes, but RSA keys suffer for this limitattion - you will be better
> served by switching to CMS.

The issue I found with CMS is that the default verification handling
routines of OpenSSL verify ALL signatures within the archive, and
that means that a signature provided by an unknown CA or signature
done with a revoked certificate would trip the verification.

After some tinkering, I managed to find a solution to that I think hits
our use case and maintains swupdate well. The attached patch adds
an option that skips out the OpenSSL check of all signatures and
instead requires that at least one of the signatures matches the public
key certificate passed to swupdate. I think this in combination with
ignoring key expirey dates gets us where we need.

I hope the attached patch technique works - if another approach would
be better to get included in the upstream, we're open to revising
further. At this point, I'm scratching my head for more ideas that don't
involve more complicated PKI on the device side.

> Another point you can consider is to extend SWUpdate's keystore.
> Currently, SWUpdate loads just one key or one CA certificate. Having
> multiple keys or multiple certificates that SWUpdate (or better, openSSL
> or the other crypto implementation) could be an option for you.

If we are utilizing CMS signatures, I think this might make sense as
an extension to the included patch. The main use case now is simply
trying to update devices with outdated key information.

Thanks for your time,

[Stefano Babic]

Hi Andrew,

On 05.05.21 21:43, 'Mulbrook, Andrew' via swupdate wrote:
>
>>> From: Stefano Babic <sba...@denx.de>
>
>> Just appearently : if the new key is delivered due to a security reason,
>> you have tons of HW accepting software with the old key. This can help
>> in a mixed conditions (a mix in field of devices with new and old keys,
>> and nobody can track it) - but again, it is even a well known use case
>> with certificates. It does not matter if your SWU is signed with an old
>> or new certificate, until they are released by the same CA SWUpdate is
>> able to verify both.
>
> I think this is the fundamentals of the use case. We have multiple
> devices in field with potentially outdated PKI information and no network
> connectivity. The desire is to allow acceptance of an update by including
> a signature done with the outdated signer information and require
> devices with updated software to accept only the newer signature. In
> other words, we want a single update to operate correctly on old
> hardware without updated certificates and new hardware with updated
> certificates.

Ok, use case understood. The bigger requirement is to have a single SWU
that is accepted by both.

>
>> Yes, but RSA keys suffer for this limitattion - you will be better
>> served by switching to CMS.
>
> The issue I found with CMS is that the default verification handling
> routines of OpenSSL verify ALL signatures within the archive, and
> that means that a signature provided by an unknown CA or signature
> done with a revoked certificate would trip the verification.
>
> After some tinkering, I managed to find a solution to that I think hits
> our use case and maintains swupdate well. The attached patch adds
> an option that skips out the OpenSSL check of all signatures and
> instead requires that at least one of the signatures matches the public
> key certificate passed to swupdate. I think this in combination with
> ignoring key expirey dates gets us where we need.
>
> I hope the attached patch technique works - if another approach would
> be better to get included in the upstream, we're open to revising
> further. At this point, I'm scratching my head for more ideas that don't
> involve more complicated PKI on the device side.

I think that a new feature can be added, only when it is around openSSL
I have to reopen the openSSL documentation and understand what is going
on. It would really help if you can send your patch inline using
git-send-email, else it cannot be reviewd here.

My first concern is how this patch overlap with the check_signer_name()
function. What you are saying above is not full correct. SWUpdate can be
instructed to accept only certificates from a specific signer, and this
is already mainline:

--forced-signer-name <cn>


So a certificate issued by an unknown authority is already rejected if
the required signer-name is passed.

Can you explain (I saw the code, but I have to understand the
differences in openSSL calls, and you have already investigated this)
which are the main difference with your code ?

>
>> Another point you can consider is to extend SWUpdate's keystore.
>> Currently, SWUpdate loads just one key or one CA certificate. Having
>> multiple keys or multiple certificates that SWUpdate (or better, openSSL
>> or the other crypto implementation) could be an option for you.
>
> If we are utilizing CMS signatures, I think this might make sense as
> an extension to the included patch. The main use case now is simply
> trying to update devices with outdated key information.
>

Best regards,
Stefano Babic

[Mulbrook, Andrew]

> I think that a new feature can be added, only when it is around openSSL
> I have to reopen the openSSL documentation and understand what is going
> on. It would really help if you can send your patch inline using
> git-send-email, else it cannot be reviewd here.

> My first concern is how this patch overlap with the check_signer_name()
> function. What you are saying above is not full correct. SWUpdate can be
> instructed to accept only certificates from a specific signer, and this
> is already mainline:
>
> --forced-signer-name <cn>

> So a certificate issued by an unknown authority is already rejected if
> the required signer-name is passed.

The use case here is to ignore unknown authority signatures
if there is a known authority signature present. (This patch loosens
requirements of CMS_verify instead of tightening requirements done
by check_signer_name). CMS_verify says "all the signers look good"
and "all the signatures match". The patch tells CMS_verify to no
longer verify signatures (as the check is all-or-nothing) and adds a
new stage performing the same operations as OpenSSL but allowing
for "at least one" known signer. While the signers are not authenticated,
the previous condition of "all the signatures match" will still be required.

In theory, the check_common_name logic could be used here as well,
but it would also need to verify the certificate as well (requires setting
up a certificate verification context and verifying the matched name
certificate). We don't need / want the more restrictive check for name
because the use case is "recognize signer with unupdated CA info".

The following example case might help:

PKI Set 1 - earlier publish date (6 years out of date, maybe CAs revoked, etc...)
PKI Set 2 - currently active

Device A - outdated PKI and certificates from set 1
Device B - current data from PKI set 2

Goal - construct an update that works on both device A and device B.

Update includes no signer:
* Both devices reject unsigned

Update includes signer from set 1:
* Device A ok.
* Device B will reject as set 1 is no longer verifiable

Update includes signer from set 2:
* Device A will reject as set 2 is unrecognized (no certificate authority chain)
* Device B ok

Update signed with both set 1 and set 2:
* Device A will reject as set 2 can not be verified
* Device B will accept if and only if the set 1 signer tests valid

Best Regards,