Re: [Suit] Suit manifest with variable recipients

[Dick Brooks <[e-mail]>]

This also appears to be a provenance/chain of custody issue, if Brendan's scenario is feasible. 

Thanks,

Dick Brooks

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

-----Original Message-----
From: Suit <[e-mail]> On Behalf Of Russ Housley
Sent: Tuesday, July 20, 2021 10:35 AM
To: Brendan Moran <[e-mail]>
Cc: Michael Richardson <[e-mail]>; suit <[e-mail]>
Subject: Re: [Suit] Suit manifest with variable recipients

Brendan:

This is a DoS issue.  We wanted distribution to be able to add recipients and remove recipients.  This means that an attacker can also add recipients and remove recipients.  A second signature to bind the recipient information to the author-signed firmware would be a way to prevent attackers from doing this manimulation, but it comes at the cost of a second signature and the management of the trust anchor to validate it.

Russ


> On Jul 20, 2021, at 5:58 AM, Brendan Moran <[e-mail]> wrote:
> 
> There is another possibility that I don’t think we’ve discussed. It has some pros and a really big con. For the sake of completeness, here it is: We keep the COSE_Encrypt exactly as it is and allow standard manifest overrides via dependencies. This is good because it means that only authorised parties can edit the recipients list. This is bad because it means that the unused recipients structures cannot be severed.
> 
> 
> I do have a big concern about the existing proposals: It is not possible to detect tampering with the recipients list. An on-path attacker could remove one or many devices from the recipients list. This would not be flagged as corruption because all signatures and digests are still correct. This would appear exactly as though the target device was not authorised to receive the update. This gives an on-path attacker an elevation of privilege because they can now control the recipients list without the explicit rights to do so. This is different from a normal denial of service attack; it is far less detectable.
> 
> For example, suppose a Firmware Author provides firmware to many Device Operators. Under normal DoS conditions, the location of an on-path attacker dictates how much control they have: if they are between the Firmware Author and the Device Operator, then either all the Device Operator’s devices are upgraded, or none of them are. If they are between the Device Operator and the Recipient (Device), then they can control whether that specific device is upgraded. This attack is detectable and not scalable.
> 
> However in our situation, an on-path attacker upstream of the Device Operator gains fine-grained control of which of the Device Operator’s devices are upgraded. This is scalable and difficult to detect. A Device Operator would need to communicate with the Firmware Author to determine why certain devices were not upgraded before the attack was discovered, giving attackers a window of opportunity. Depending on implementation details, competency, level of automation, and any other coincident attacks launched by the threat actor, this window could be longer or shorter.
> 
> 
> 
> 
> I don’t believe that this is inline with our goals, however this specific threat is not listed in the threat model within draft-ietf-suit-information-model—evidence that threat models are living documents, I suppose! Perhaps this threat should be discussed in draft-ietf-suit-firmware-encryption?
> 
> 
> I think the solution, though less than ideal, is to place some metadata in the manifest about the COSE_Encrypt within the manifest. In short, if COSE_Encrypt is external to the manifest, it must be authenticated by the manifest. If it is altered by an authorised party, that must be explicit and authenticated as well.
> 
> 
> I can see two possible implementations for this:
> 1) manifest override. A digest of the COSE_Encrypt is placed in the manifest. This digest can be replaced by an authorised party by creating a dependent manifest that overrides it. This approach suggests that we should add the facility to digest integrated payloads/images as Øyvind requested..
> 
> 2) COSE_Sign: If the COSE_Encrypt (actually a COSE_Encrypt_Tagged in this case) is overridden, then it must be replaced with a COSE_Sign_tagged containing the altered COSE_Encrypt. This initially seems less complex, but 1) reuses existing code paths, whereas 2) requires the creation of new ones.
> 
> I think we should consider requiring a digest of the COSE_Encrypt to be verified in advance of using the COSE_Encrypt in order to detect tampering. However if the COSE_Encrypt has been tampered with, but the resulting key is still usable, there’s no reason to halt installation. This presents an unusual problem: the verification of COSE_Encrypt is more important at the distribution level than at the Recipient level. At the Recipient level, it’s most important for reporting purposes.
> 
> The “correct” answer for this issue is not immediately clear to me.
> 
> Best Regards,
> Brendan
> 
>> On 13 Jul 2021, at 02:09, Michael Richardson <[e-mail]> wrote:
>> 
>> 
>> Brendan Moran <[e-mail]> wrote:
>>> The result is that COSE_Recipients MUST be held outside of the 
>>> manifest’s chain of trust. This complicates matters somewhat. It 
>>> would be better if most of the COSE_Encrypt was held under the trust 
>>> umbrella while the COSE_Recipients were held outside the umbrella. 
>>> However, COSE does not support detached Recipient lists. This may be 
>>> a failing of COSE, and perhaps it should be discussed there. In the 
>>> interim, however, SUIT needs to move forward with some solution to 
>>> deploying variable recipient lists.
>> 
>> I think it is reasonable that SUIT give COSE a clear set of requirements.
>> (Let's not do CBOR packed goof again)
>> 
>>> I can see several options:
>> 
>> 
>>> Option 1: Place the COSE_Encrypt outside the manifest, reference it 
>>> by URI (remote) or Integer (envelope) Modify 
>>> suit-parameter-encryption-info to take a tstr (URI) or integer 
>>> (Envelope Reference)
>> 
>>> This means that all devices supporting the encryption-info parameter 
>>> MUST support both integrated, detached local, and detached remote 
>>> modes. I don’t think this is really in the spirit of SUIT.
>> 
>> I see your point.
>> 
>>> Option 2: Place the COSE_Encrypt outside the manifest, reference it 
>>> by Integer (envelope) Add a new 
>>> suit-parameter-encryption-info-detached
>>> that takes the integer (Envelope Reference)
>> 
>>> This has the benefit of being unambiguous. However, it creates a new
>>> problem: what happens if both the
>>> suit-parameter-encryption-info-detached and the 
>>> suit-parameter-encryption-info are set? Does there need to be a rule 
>>> that one explicitly unsets the other? How does that work with 
>>> permissions?
>> 
>> It sounds to me that either it's invalid (manifest rejected 
>> outright), or one simply has a higher priority than the other.
>> 
>>> Option 3: Abuse COSE slightly: Place a COSE_Encrypt0 in the 
>>> manifest. Place a list of recipients outside the manifest.
>> 
>>> This has the benefit of being what we actually want, but it probably 
>>> won’t play nice with COSE libraries.
>> 
>> I think that few devices will have totally generic COSE libraries anyway.
>> Encoders can cope.
>> 
>> 
>> --
>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>>          Sandelman Software Works Inc, Ottawa and Worldwide
>> 
>> 
>> 
>> 
> 
> 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]
> https://www.ietf.org/mailman/listinfo/suit

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