Subject: Re: [Suit] SUIT Charter: Multisource signed manifest and permission model

From: Brendan Moran <[email-masked]>
Date: Tue, 5 Dec 2017 10:31:07 +0000

Hi Suhas,

Thank you for pointing out the missing part of my threat model! I’ll add the following threat in when I update the draft next.

Earlier, there was a discussion on the ability of users to NOT update a device. If this is to be possible at an operator level, then signatures are a prerequisite.

Best Regards,
Brendan

Threat MFT10: Unqualified Firmware
-----------------------------------
Classification: Denial of Service, Escalation of Privilege

This threat can manifest in several ways, however it is ultimately about interoperability of devices with other systems. The owner or operator of a network needs to approve firmware for their network in order to ensure interoperability with other devices on the network, or the network itself. If the firmware is not qualified, it may not work. Therefore, if a device installs firmware without the approval of the network owner or operator, this is a threat to the network.

Example 1:
We assume that OEMs expect the rights to create firmware, but that Operators expect the rights to qualify firmware as fit-for-purpose on their networks.

An attacker obtains a manifest for a device on Network A. They send that manifest to a device on Network B. Because Network A and Network B are different, and the firmware has not been qualified for Network B, the target device is disabled by this unqualified, but signed firmware.

This is a Denial of Service because it can render devices inoperable. This is an Escalation of Privilege because it allows the attacker to make installation decisions that should be made by the Operator.

Example 2:
Multiple devices that interoperate are used on the same network. Some devices are made by OEM A. Some devices are made by OEM B. These devices communicate with each other  A new firmware is released by the OEM A, that breaks compatibility with OEM B devices. An attacker sends the new firmware to the OEM A devices without approval of the network operator. This breaks the behaviour of the larger system, causing Denial of Service and possibly other threats. Where the network is a distributed SCADA system, this could cause misbehaviour of the process that is under control.

Threat Escalation: If the firmware expects configuration that is present in Network A devices, but not Network B devices, then the device may experience degraded security, leading to threats of All Types.

Security Requirement MFSR6: Rights require Authenticity
-----------------------------------
If a device grants different rights to different actors, exercising those rights MUST be accompanied by proof of those rights, in the form of proof of authenticity. Authenticity mechanisms such as those required in MFSR5 are acceptable. Network authenticity, such as TLS MUST NOT be used as proof of rights, since this exposes the network to new threats.

For example, if a device has a policy that requires that firmware have both an Authorship right and a Qualification right and if that device grants Authorship and Qualification rights to different parties, such as an OEM and an Operator, respectively, then the firmware cannot be installed without proof of rights from both the OEM and the Operator.

Mitigates: MFT10

On 22 Nov 2017, at 23:43, Suhas Nandakumar <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

The current charter says the following about allowing manifest and firmware signed by different sources and having an expressive permissions model.

"""

To support a wide range of deployment scenarios, the formats are expected to be expressive enough to allow the use of different software sources and permission models.

"""

I think the whole idea of multiple people signing is very unclear on the requirements and its applicability or its widespread use. Most common deployments today follow the model of single vendor signing the firmware. A certification lab might certify that a given version meets some requirements and and an operator might use that information to decide what version they deploy but neither the certification lab or the operator sign anything.

I propose that the WG should reconsider this requirement for scoping purposes and should consider multi-vendor signing/permissions model  as a future extension instead. This should be removed unless we can specify what the need is and be clear on the trust models supported.

Cheers
Suhas Nandakumar
_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
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.