[Cscwg-public] Signature authorization checks for signed code (SBOM)

Fri Jun 4 07:53:00 UTC 2021

Hello All,

I wanted to bring something to your attention that a partner of ours has
shared with us. In short, in securing software supply chains there's some
concern about tools for the validation of code signing signatures (e.g.
SignTool) not taking into account whether the signer is actually authorized
to sign that software package. As a suggestion to resolving this problem, a
system similar to DNS CAA is being suggested (while being well aware that it
could not work the exact same way).

Full message below:

Copied from
https://energycentral.com/c/ec/we-cannot-secure-software-supply-chain-withou
t-sbom 

A Software Bill of Materials (SBOM) <https://ntia.gov/sbom>  has received
considerable attention since the Cybersecurity Executive order was released
on May 12, 2021
<https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/ex
ecutive-order-on-improving-the-nations-cybersecurity/>  calling on
government agencies to require SBOM's from software vendors, "(vii)
providing a purchaser a Software Bill of Materials (SBOM) for each product
directly or by publishing it on a public website" 

The Executive Order goes on to describe an SBOM, with an emphasis on it's
component inventory capabilities, "Software Bill of Materials" or "SBOM"
means a formal record containing the details and supply chain relationships
of various components used in building software", "It is analogous to a list
of ingredients on food packaging."

All of these claims are indeed accurate, however there is another essential
and critically important element that SBOM's provide, which is essential to
secure the software supply chain; The identity of the software source
supplier that produced and licensed the software, which can be verified
using digital signing keys issued by trustworthy Certificate Authorities. 

Current practices used in the software supply chain do not require
identification of the actual software supplier and licensor of a software
package. Some practices require that software packages be digitally signed,
however there is no verification or validation that the signer of a software
package and the supplier/licensor are related, or that the supplier/licensor
has authorized a given party to sign a software object on their behalf. This
creates a false sense of security when parties rely on tools such as
Microsoft's signtool to validate a digital signature. Signtool does not
validate that a digital signature belongs to a party authorized to sign a
software product on behalf of the original source supplier/licensor - it has
no way of verifying that a given signer is authorized to digitally sign a
software package. Signtool will report a valid signature if the
cryptographic verifications and trust chain reports produce successful
results, which do not verify the authorization of a signing party and
supplier arrangement. This issue is similar to a past scenario where
Certificate Authorities were issuing SSL certificates to domains without
authorization to do so, which resulted in the implementation of DNS CAA
(IETF RFC 6844 <https://datatracker.ietf.org/doc/html/rfc6844> ) records to
identify authorized parties to issue SSL certificates. A similar
authorization scheme may be appropriate to authorize the issuance of digital
certificates and signing keys to parties that have been authorized by a
software supplier/licensor to sign software objects on their behalf.

The ability to determine trustworthiness is the key to securing the software
supply chain. SBOM is the foundation for establishing this trust by
specifying the identification of the actual source supplier/licensor of a
software product. This supplier information can then be used to validate a
digital signature applied to a software object by verifying the relationship
of the software supplier and software signer using a trusted method to
verify this relationship. A solution similar to DNS CAA, ref: "DNS
Certification Authority Authorization (CAA) Resource Record", IETF RFC 6844
<https://datatracker.ietf.org/doc/html/rfc6844>  may be worth exploring to
address this need.

There is no doubt that securing the software supply chain requires a
software consumer to verify the identity of a software source supplier and
licensor of a software object. SBOM is a critical requirement in this
process due to its standard method for identifying a software
supplier/licensor of a software object. Having this SBOM supplier identifier
will enable a software consumer to verify this party using digital
signatures based on digital certificates issued by trusted Certificate
Authorities.  What is missing today is a means to verify the authorization
of a signing party by the software source supplier/licensor using trusted
mechanisms, similar to RFC 6844. Perhaps, one day, we may see a DNS Digital
Signature Authorization (DSA) record to meet this need. 

Everyone in the Energy industry really needs to follow this wise guidance
provided by NIST:

SP 800-161 R1: https://doi.org/10.6028/NIST.SP.800-161r1-draft  

SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | CODE AUTHENTICATION 

Supplemental C-SCRM Guidance: The organization should ensure that code
authentication mechanisms such as digital signatures are implemented to
assure the integrity of software, firmware, and information.

This NIST guidance, combined with Software Supplier Identification
information contained in a digitally signed SBOM will go a long way to
addressing software supply chain issues.

Best,
Seb

Sebastian Schulz
Product Manager Client Certificates

 <http://www.globalsign.com/> 

Diestseveest 14, 3000 Leuven, Belgium
T +32 1652 0000 ext 5955 |  
Email:  <mailto:masebastian.schulz at globalsign.comrk.freeman@globalsign.com>
sebastian.schulz at globalsign.com 

 <https://www.linkedin.com/in/sebschulz/> Connect on LinkedIn

 <https://downloads.globalsign.com/acton/media/2674/preference-center-login>
Sign up to receive news and content from GlobalSign

 <https://twitter.com/globalsign>
<http://www.linkedin.com/company/globalsign>
<http://www.facebook.com/globalsignssl>
<https://www.instagram.com/globalsign/>
<https://www.youtube.com/channel/UC8sZHRv5heWZpckgTAMBuJg> 

This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and may include trade secrets or privileged or
otherwise confidential information. Any unauthorized review, use,
forwarding, printing, copying, disclosure or distribution is strictly
prohibited. If you received this message in error, or have reason to believe
you are not authorized to receive it, please promptly delete this message,
destroy all copies, and notify the sender by e-mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210604/6effb17b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 12116 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210604/6effb17b/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 791 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210604/6effb17b/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 878 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210604/6effb17b/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 862 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210604/6effb17b/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1309 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210604/6effb17b/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 1159 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210604/6effb17b/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8432 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210604/6effb17b/attachment-0001.p7s>