Re: [Suit] Suit manifest with variable recipients

[Brendan Moran <[e-mail]>]

> On 21 Jul 2021, at 21:22, Michael Richardson <[e-mail]> wrote:
>
>
> Not sure why I'm explicitely in the CC, reply-all I guess.

Yup.

>> 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 that such an on-path attacker can also drop the entire update, right?
> Or such an on-path attacker could selectively suppress the manifest getting
> to specific devices anyway.  The summary is that this is not something new
> that is enabled by fine-grained control of the encryption.

It depends where the on-path attacker is. If they are resident between the firmware author and the status tracker, then it was all or nothing: suppress the manifest in its entirety or don’t. This fine-grained control of encryption allows them fine-grained suppression control with repudiation: a single recipient can be suppressed by an attacker upstream of the status tracker without any evidence they have done so. It is impossible to tell whether an attacker suppressed the recipient or the manifest author suppressed the recipient.

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

So, this is wrong. It’s not that the COSE_Encrypt MUST be authenticated by the manifest; it’s that the COSE_Encrypt MUST be authenticated! More below.

> I think that this barks up the wrong tree.
> Let's go back to the architecture (now RFC9019: woohoo!)

Hurray!

> Isn't the Status Tracker supposed to keep track of what version each device
> is running, and let it know that there is something new?

There are two threats that we need to concern ourselves with:

1: The threat described above: An on-path attacker upstream of the status tracker suppresses a device. This is different from existing SUIT DoS threats because of the targeting of single devices from outside a network. To be clear, this is not simply a DoS; it is an Elevation of Privilege (unprivileged actor decides which devices are updated) AND a Repudiation threat (Not possible to know who chose which devices received updates). The status tracker CAN inform the device of the new update, but the device appears not to have been authorised by the owner of the firmware (via the Content Encryption Key)

2: An on-path attacker (upstream or downstream of the status tracker) tampers with the COSE_Encrypt, causing a device to spend extra energy on receiving data, cryptographic operations, flash writes, etc.


These two threats are detected in different parts of the infrastructure and so may require different solutions.

For threat 1, the status tracker needs to validate that there has been no tampering with the list of recipient devices. This requires a signature that covers the recipient list. This signature does NOT need to be verified by a Manifest Processor. Therefore, this signature does not need to be integrated into the manifest dependency hierarchy and it does not need to be integrated as metadata in the manifest; it can exist purely in the envelope. Furthermore, the signature MAY be severed prior to delivery to a Recipient Device.

For threat 2, we want to prevent a device from performing unnecessary payload fetches, public key cryptographic operations, and flash writes. For the sake of argument, the energy cost to receive a byte over LoRa is approximately 15x the energy cost to write it to flash [1]. There’s not much we can do to make sure the cipher text of the payload is correct before fetching it. The manifest already provides a mechanism for verifying before decrypting, but that is not always applicable nor desirable from an energy perspective.

The COSE_Recipients structure is more interesting. We cannot verify the whole structure without public key operations unless there is already a trusted PSK with the distributor, but this simply recreates the key distribution problem.

In the Hybrid Public-Key Encryption (HPKE, non-interactive ephemeral-static Diffie-Hellman exchange) case, COSE_Encrypt contains the ephemeral public key and COSE_Recipients structure contains the cipher text of the Content Encryption Key (CEK) and a key id. The ephemeral public key is the same for all recipients. Similarly, the CEK is the same for all recipients. The CEK ciphertext and the key id are different for each recipient. While the ephemeral public key could be different for multiple “batches” of recipient devices, the CEK MUST be the same for the same payload.

In this case, it would make sense to authenticate the CEK. The digest of the CEK could be added to the manifest trivially in the parameter that references the COSE_Encrypt in the envelope. This would resolve Threat 2. We could potentially authenticate the ephemeral public key. I’m not certain that this improves over CEK authentication in a meaningful way since we can’t reasonably authenticate the CEK ciphertext without additional public key operations

1 public key operation to validate the manifest
1 public key operation to compute the shared secret
1 digest of CEK

A separately-signed COSE_Encrypt list makes this worse:

1 public key operation to validate the manifest
1 public key operation to validate the COSE_Encrypt & COSE_Recipients (including a digest of the whole COSE_Encrypt, not just a CEK)
1 public key operation to compute the shared secret

Including a digest of the CEK adds no public key operations and allows us to avoid fetching, decrypting, and storing a payload if the CEK is invalid. It takes less space to encode and less energy to verify. It costs 1 SUIT_Digest to encode this in the manifest. Given that this is a scenario where there is a COSE_Encrypt containing a public key, and a COSE_Recipient containing a key id, and a ciphertext key, a single SUIT_Digest is not a substantial increase in size.



To summarise, I think that the best course of action is to add a detached COSE_Sign for each COSE_Encrypt OR wrap the whole SUIT_Envelope in a COSE_Sign—though this becomes much more complex with dependencies that have encrypted payloads. The COSE_Sign allows the author and status tracker to exchange manifests without tampering by on-path attackers between. This COSE_Sign MAY be pruned prior to distribution to Recipients.

>
> AFAIK, standardization of the status tracker was not a goal in this round of
> SUIT.  I'm unclear if we this was an ordering/chartering decision, or if it
> was because we really didn't think we could accomplish this without boiling
> oceans.  RFC9019 mentions that LwM2M already has this functionality, and so
> maybe we will never ever have a single standard, but maybe it's time to
> identify what other places we can place the Status Tracker functionality.

This isn’t about the status tracker. This is about document format support for ensuring that the recipient list isn’t tampered with between Author and Status Tracker, between Status Trackers, or between Status Tracker and Recipient.

> We have also been discussing SBOM pointers via MUD and/or Remote Attestation.

I wrote a draft that’s very related to this for iotops! https://datatracker.ietf.org/doc/draft-moran-iot-nets/

>
> At this time, I think that the manifest has became a bit of a hammer, and
> we'e actually run out of nail-shaped things.

Overall, I think I agree. However, we have a few use cases left to cover, or cover more explicitly, I think.



Cheers,
Brendan

[1] The background for receive vs write estimates is as follows; but it may vary substantially with data rates, models of transceiver & MCU, etc.
SX1262 LoRa transceiver quotes up to 62.5kb/s, 8.2mA @ 1.8V in RX mode => 0.236 pJ/b or 1.89pJ/B
STM32F401RE quotes 12mA erase current (3.3V & 32-bit mode) and 16us word programming time => 0.119pJ/B



> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> Suit mailing list
> [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.