Re: [Suit] suit-firmware-encryption-00

[Dick Brooks <[e-mail]>]

Brendan,

 

               I understand your position.

 

               I have my doubts that the approach you describe will pass a NERC audit for CIP-010-3 software verification requirements R1, part 1.6 requirement 1.6.1, because it requires sending the SW to the device, essentially changing the baseline, in violation of the NERC CIP standard, before performing the necessary identity verification; https://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-010-3 <https://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-010-3&title=Cyber%20Security%20%E2%80%94%20Configuration%20Change%20Management%20and%20Vulnerability%20Assessments&Jurisdiction=United%20States> &title=Cyber%20Security%20%E2%80%94%20Configuration%20Change%20Management%20and%20Vulnerability%20Assessments&Jurisdiction=United%20States 

 



 

Thanks,

 

Dick Brooks



 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

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

Email:  <mailto:[e-mail]> [e-mail]

Tel: [phone]

 

From: Brendan Moran <[e-mail]> 
Sent: Wednesday, June 2, 2021 9:54 AM
To: Dick Brooks <[e-mail]>
Cc: Hannes Tschofenig <[e-mail]>om>; Russ Housley <[e-mail]>om>; Michael Richardson <[e-mail]>ca>; suit <[e-mail]>
Subject: Re: [Suit] suit-firmware-encryption-00

 

Hi Dick





Brendan,


You make an excellent point that the devices themselves have built in trust relationships that the device is capable of verifying. 

The scenario I'm describing goes like this:

A SW vendor announces that a new security patch is available for download.

End use customer downloads the SW per vendor instructions.

Customer wants to perform a SCRM  software supply chain risk assessment before installing the SW patch on a device. 

What standard/formal process is available to the SW customer to verify that the signer of the SW patch was authorized to sign the package by the original software supplier?
I have not found any specific standard or formal practices that prescribe a method to verify the trust relationship between a software supplier and an authorized software code signer. 

 

Really, this is just an extension of the device use-case. If the device reports to its management system (the SW Customer) what public keys it trusts, then the SW customer can verify a manifest prior to distribution. Regardless, if the device receives a manifest signed by an untrusted source, it can identify that when it checks the `kid` header in the signature. That means it can reject the manifest before even validating the signature. This means the device only pays the cost of receiving the manifest.

 

In any case, device operators (SW Customers) should have access to the public keys of any trust anchors so that they can do pre-distribution checks. (https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-12#section-4.3.19)

 





Current code signing and verification practices allow any party to sign software and an "unauthorized signature" will be reported as verified by tools such as Microsoft's signtool. This is the security gap that needs to be plugged. 

 

I don’t think we should take the policies used by signtool as an indication of how IoT devices built with SUIT will work. I think it’s more important to consider the SUIT threat model and security requirements.





A SW customer MUST be able to perform a SCRM risk assessment to ascertain some level of assurance that a SW package is trustworthy before any attempt to install. This is a current requirement of NERC CIP-010-3 software verification requirements. 

 

Best Regards,

Brendan





Thanks,

Dick Brooks

Never trust software, always verify and report! ™
 <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com
Email:  <mailto:[e-mail]> [e-mail]
Tel: [phone]

-----Original Message-----
From: Brendan Moran < <mailto:[e-mail]> [e-mail]> 
Sent: Wednesday, June 2, 2021 9:13 AM
To: Dick Brooks < <mailto:[e-mail]> [e-mail]>
Cc: Hannes Tschofenig < <mailto:[e-mail]> [e-mail]>gt;; Russ Housley < <mailto:[e-mail]> [e-mail]>gt;; Michael Richardson < <mailto:[e-mail]> [e-mail]>gt;;  <mailto:[e-mail]> [e-mail]
Subject: Re: [Suit] suit-firmware-encryption-00

Hi Dick,

To verify any signature, you have to get a public key from somewhere. If the recipient device doesn’t have the relevant public key, then the signature isn’t valid. The flaw that you describe is based entirely on a system that’s overeager to deliver public keys to devices without applying any ACL.

This is why we explicitly call out ACLs in the information model: https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-12#section-4.3.13

Constrained devices have access to a constrained set of public keys. They have one trust anchor, sometimes two or three. However those trust anchors have specific duties. For example, one might be the trust anchor for firmware updates, a second might be for the remote management system, and a third might be for data reporting. If you have the ability to dynamically install new trust anchors, then you create a problem. This needs to be carefully considered.

But whatever the case, this is a security consideration. Manifests MUST be signed by known public keys. Public keys MUST have endorsements for specific capabilities on the target device. That mechanism is not in-scope for the manifest itself, but it is certainly in-scope for the manifest security considerations. The manifest security considerations are covered int he information model, which contains the section about ACLs.

Is that adequate coverage?

Best Regards,
Brendan




On 2 Jun 2021, at 14:03, Dick Brooks <[e-mail] <mailto:[e-mail]> > wrote:

Brendan,

I agree that a trust anchor is specified in SUIT, however when you 
look at the basis for this trust anchor (COSE) you find this 
information

https://datatracker.ietf.org/doc/html/rfc8152#section-4.4
COSE's Signing and Verification process contains the following guidance:

In addition to performing the signature verification, the application
 may also perform the appropriate checks to ensure that the key is
 correctly paired with the signing identity and that the signing
 identity is authorized before performing actions.

The problem seems to be that there is no formal/standard define method 
for a SW consumer to verify that a signer has been authorized by the 
original source supplier to sign software on their behalf. Anyone can 
sign anyone's software package, and it is verified as successful by Microsoft's signtool.
This is a problem for the SCRM community.

Thanks,

Dick Brooks

Never trust software, always verify and report! T 
http://www.reliableenergyanalytics.com
Email: [e-mail] <mailto:[e-mail]> 
Tel: [phone]

-----Original Message-----
From: Brendan Moran <[e-mail] <mailto:[e-mail]> >
Sent: Wednesday, June 2, 2021 8:53 AM
To: Dick Brooks <[e-mail] <mailto:[e-mail]> >
Cc: Hannes Tschofenig <[e-mail] <mailto:[e-mail]> >; Russ Housley 
<[e-mail] <mailto:[e-mail]> >; Michael Richardson <[e-mail] <mailto:[e-mail]> >; 
[e-mail] <mailto:[e-mail]> 
Subject: Re: [Suit] suit-firmware-encryption-00






DB>> Currently software consumers do not have a standard method to 
DB>> verify
that a signing party has been authorized to sign on behalf of a 
software source supplier, when performing digital signature 
verification on a software package. Many people "assume" that the 
signing party is the software source supplier.  A digital signature 
alone is insufficient at identifying the software source supplier 
because anyone with a code signing key can sign any software package, 
as

demonstrated in this article:



https://energycentral.com/c/ec/who-ya-gonna-trust


This may well be true in the general case, but this is not true for SUIT.
SUIT manifests must be verified all the way back to a trust anchor.

https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13#section-5.
2




 Delegation Chains allow a Recipient to establish a chain of trust
 from a Trust Anchor to the signer of a manifest by validating
 delegation claims.  Each delegation claim is a [RFC8392] CBOR Web
 Tokens (CWTs).  The first claim in each list is signed by a Trust
 Anchor.  Each subsequent claim in a list is signed by the public key
 claimed in the preceding list element.  The last element in each list
 claims a public key that can be used to verify a signature in the
 Authentication Block (
Section 5.3).

See also
https://datatracker.ietf.org/doc/html/draft-ietf-suit-manifest-13#section-8.
3

This is also described in the information model:
https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-mode
l-12#s
ection-3.25

See also REQ.SEC.ACCESS_CONTROL:
https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-mode
l-12#s
ection-4.3.13




 If a device grants different rights to different actors, then an
 exercise of those rights MUST be validated against a list of rights
 for the actor.  This typically takes the form of an Access Control
 List (ACL).  ACLs are applied to two scenarios:

 1.  An ACL decides which elements of the manifest may be overridden
     and by which actors.

 2.  An ACL decides which component identifier/storage identifier
     pairs can be written by which actors.

 Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13),
 THREAT.UPD.UNAPPROVED (Section 4.2.11)


Best Regards,
Brendan





DB>> I plan to raise the need for a formal method to verify 
DB>> authorized code
signing parties on behalf a software source supplier during digital 
signature validation as a topic during NIST's EO workshop in 6/2-3.

(It is not unlikely that the delegation mechanism would benefit from 
more
details...)

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, June 1, 2021 3:20 PM
To: Hannes Tschofenig <[e-mail] <mailto:[e-mail]> >; 'Russ Housley'
<[e-mail] <mailto:[e-mail]> >
Cc: 'Michael Richardson' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: RE: [Suit] suit-firmware-encryption-00

Hannes,

Will the SUIT manifest contain an attestation of a clean malware scan 
that can be verifiably validated for the encrypted software in hand?
That would help, if a malware scan is not an option.

The other issue that needs to be addressed is the ability for a 
software consumer to verify that the signing party of a software 
object has been given authorization to sign code on behalf of a 
software source supplier (VENDOR ID) in the manifest, using a 
standard method - something similar to DNS CAA records, but for 
digital signatures,

e.g. maybe DNS DSA records.




Ref: "Vendor ID is not intended to be a human-readable element.  It 
is intended for binary match/mismatch comparison only."

Thanks,

Dick Brooks

Never trust software, always verify and report! T 
http://www.reliableenergyanalytics.com <http://www.reliableenergyanalytics.com/> 
Email: [e-mail] <mailto:[e-mail]> 
Tel: [phone]

-----Original Message-----
From: Hannes Tschofenig <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, June 1, 2021 9:05 AM
To: [e-mail] <mailto:[e-mail]> ; 'Russ Housley'
<[e-mail] <mailto:[e-mail]> >
Cc: 'Michael Richardson' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: RE: [Suit] suit-firmware-encryption-00

It is a challenge.

The SUIT manifest provides the capabilities to give authorized 
parties extra information (via the manifest meta-data and software
description*) while providing less info to adversaries.

(*): I am assuming that the info offered via MUD, COSWID, and the 
textual description is of any help to you. If it is not, then you 
need to let us know what other pieces of information will have to be 
included in the manifest to become valuable to make the risk assessment.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, June 1, 2021 1:32 PM
To: Hannes Tschofenig <[e-mail]>om>; 'Russ Housley'
<[e-mail] <mailto:[e-mail]> >
Cc: 'Michael Richardson' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: RE: [Suit] suit-firmware-encryption-00

Hannes,

I definitely see your point, it seems the real problem to solve is:
- How do we (1) prevent the bad guys from discovering SW details 
(source
code) from binaries while simultaneously (2) providing end use 
customers the ability to conduct malware scans, and other risk 
management

functions?




If we encrypt a binary distribution we achieve 1 but not 2 If we do 
not encrypt we achieve 2, but not 1

Are we really looking at a mutually exclusive choice?

Both of these objectives are trying to achieve the same thing: Keep 
the bad guys from causing harm.

Thanks,

Dick Brooks

Never trust software, always verify and report! T 
http://www.reliableenergyanalytics.com <http://www.reliableenergyanalytics.com/> 
Email: [e-mail] <mailto:[e-mail]> 
Tel: [phone]

-----Original Message-----
From: Hannes Tschofenig <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, June 1, 2021 6:40 AM
To: [e-mail] <mailto:[e-mail]> ; 'Russ Housley'
<[e-mail] <mailto:[e-mail]> >
Cc: 'Michael Richardson' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: RE: [Suit] suit-firmware-encryption-00

Dick, I understand your line of argument.

At the same time I want to create awareness for the attacker point of

view.



They need to get access to plaintext firmware of an embedded device 
(unless the attacker already knows what the source was used). This is 
why there are advanced disassemblers available (such as IDA Pro, 
Binary Ninja, and Ghidra
-- to name a few).

As a way forward I am proposing to use the additional data carried in 
the manifest for doing the SCRM risk assessment step. I believe that 
this should work.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[e-mail] <mailto:[e-mail]> >
Sent: Monday, May 31, 2021 10:00 PM
To: Hannes Tschofenig <[e-mail] <mailto:[e-mail]> >; 'Russ Housley'
<[e-mail] <mailto:[e-mail]> >
Cc: 'Michael Richardson' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: RE: [Suit] suit-firmware-encryption-00

Thanks, Hannes. I just submitted a concern regarding the problem 
encryption creates for malware scanning, which is one of the SCRM 
risk assessment steps, performed before installation

Thanks,

Dick Brooks

Never trust software, always verify and report! T 
http://www.reliableenergyanalytics.com <http://www.reliableenergyanalytics.com/> 
Email: [e-mail] <mailto:[e-mail]> 
Tel: [phone]

-----Original Message-----
From: Hannes Tschofenig <[e-mail] <mailto:[e-mail]> >
Sent: Monday, May 31, 2021 3:57 PM
To: [e-mail] <mailto:[e-mail]> ; 'Russ Housley'
<[e-mail] <mailto:[e-mail]> >
Cc: 'Michael Richardson' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: RE: [Suit] suit-firmware-encryption-00

Hi Dick,

with the SUIT manifest format I hope we can make information 
available to trusted third parties (MUD, COSWID and alike) and at the 
same time use encrypted binaries. Having access to the plaintext 
binary is essential for adversaries to mount attacks. (Happy to give 
a tutorial about how this
works.)

Like-wise differential updates may make it difficult for SCRM vendors 
to make their analysis but the information in the manifest can help them.

Severable fields allows to remove information from the manifest 
before it is sent to the device. This reduces overhead and prevents 
untrusted parties from gathering information from the manifest.

Ciao
Hannes

-----Original Message-----
From: Dick Brooks <[e-mail] <mailto:[e-mail]> >
Sent: Monday, May 31, 2021 7:07 PM
To: 'Russ Housley' <[e-mail] <mailto:[e-mail]> >
Cc: 'Michael Richardson' <[e-mail] <mailto:[e-mail]> >; Hannes Tschofenig 
<[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: RE: [Suit] suit-firmware-encryption-00

I agree, Russ.

Parties subject to the 5/12 Executive Order
(https://www.whitehouse.gov/briefing-room/presidential-actions/2021/0
5
/12/ex
ecutive-order-on-improving-the-nations-cybersecurity/) will likely 
want to perform a proactive SCRM risk assessment prior to 
installation, if my interpretation of the EO is accurate.

Thanks,

Dick Brooks

Never trust software, always verify and report! T 
http://www.reliableenergyanalytics.com <http://www.reliableenergyanalytics.com/> 
Email: [e-mail] <mailto:[e-mail]> 
Tel: [phone]

-----Original Message-----
From: Russ Housley <[e-mail] <mailto:[e-mail]> >
Sent: Monday, May 31, 2021 12:56 PM
To: Dick Brooks <[e-mail] <mailto:[e-mail]> >
Cc: Michael Richardson <[e-mail] <mailto:[e-mail]> >; Hannes Tschofenig 
<[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: Re: [Suit] suit-firmware-encryption-00

Dick:

Yes, and there are other use cases that require encryption.

Russ





On May 31, 2021, at 12:53 PM, Dick Brooks

<[e-mail] <mailto:[e-mail]> > wrote:




" If a trustworthy party in the middle of the distribution path is 
able to detect a problem with cleartext (but signed) firmware, they 
can report a vulnerability and refuse to pass the update along."

This is precisely the function SCRM vendors are performing today.
Encrypting a binary object would be an impediment to software supply 
chain risk assessment functions in place today.

Thanks,

Dick Brooks

Never trust software, always verify and report! T 
http://www.reliableenergyanalytics.com <http://www.reliableenergyanalytics.com/> 
Email: [e-mail] <mailto:[e-mail]> 
Tel: [phone]

-----Original Message-----
From: Suit <[e-mail] <mailto:[e-mail]> > On Behalf Of Russ Housley
Sent: Monday, May 31, 2021 12:49 PM
To: Michael Richardson <[e-mail] <mailto:[e-mail]> >
Cc: Hannes Tschofenig <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: Re: [Suit] suit-firmware-encryption-00

Michael:




I agree that there are also challenges with certification schemes 
that prevent developers from seeing the source code (or from 
publishing the source code). That's yet another issue.





SUIT is using signature for the authentication and integrity of 
the firmware.  If the signature remains in place, a party in the 
middle of the distribution cannot insert any malware.


The encryption of the firmware keeps third parties from auditing 
the software updates to determine if malware has been inserted at 
the

"factory"



Both white and black hats are currently using binary diff systems 
to look at patches.  Black hats use this to develop exploits in the 
gap between 9am EST and 9am PST!
I am suggesting that this is a "Security Consideration"


Yes, this is a reasonable thing to add to the Security Considerations.

If a trustworthy party in the middle of the distribution path is 
able to detect a problem with cleartext (but signed) firmware, they 
can report a vulnerability and refuse to pass the update along.

Russ
_______________________________________________
Suit mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/suit



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended 
recipient, please notify the sender immediately and do not disclose 
the contents to any other person, use it for any purpose, or store or 
copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended 
recipient, please notify the sender immediately and do not disclose 
the contents to any other person, use it for any purpose, or store or 
copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended 
recipient, please notify the sender immediately and do not disclose 
the contents to any other person, use it for any purpose, or store or 
copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended 
recipient, please notify the sender immediately and do not disclose 
the contents to any other person, use it for any purpose, or store or 
copy the information in any medium. Thank you.

_______________________________________________
Suit mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/suit


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended 
recipient, please notify the sender immediately and do not disclose 
the contents to any other person, use it for any purpose, or store or 
copy the information in any medium. Thank you.


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.