Subject: [Suit] Review comments on draft-urien-suit-security-classes-00

From: Amyas Phillips <[email-masked]>
Date: Tue, 6 Nov 2018 11:48:45 +0000

1.  I'd say the properties FLD and FLD-SEC are prerequisites for SUIT,
which expects a secure firmware loader to be always present.

2. Should protection of firmware confidentiality and authenticity at rest
be considered as a separate property?  I'm not aware of any hardware-level
features except debug-lock, which is practically universal, so I guess
there's no need.

3. TRT-KEY and DIV-KEY only impact firmware update security where symmetric
class keys are used, for authenticity and/or confidentiality, and must be
protected.  The security model in draft-ietf-suit-architecture-01 doesn't
use symmetric keys at all, unless for encryption, which it says is out of
scope. I guess SUIT WG can ignore these properties, at least until it
considers symmetric-only scenarios.

4. I guess that e.g. a ROM bootloader is included under the category OTP.

5. Flash can be protected against writes from outside a trusted enclave.
 This isn't quite as immutable as a trusted bootloader in OTP but it is
more immutable than a bootloader residing somewhere writable by the main
application.  Should this be considered a weaker version of the OTP
property?

6.  There are quite a variety of security features available on MCUs and
boot processes and if, for the purposes of understanding security of
firmware updates, they can all be boiled down to whether there is OTP
(trusted boot) or not that's very useful and simplifying.

Thanks

Amyas Phillips

---

From: Pascal Urien <[email-masked]>
Date: Tue, 6 Nov 2018 20:29:36 +0700

>
> 3. TRT-KEY and DIV-KEY only impact firmware update security where
> symmetric class keys are used, for authenticity and/or confidentiality, and
> must be protected.  The security model in draft-ietf-suit-architecture-01
> doesn't use symmetric keys at all, unless for encryption, which it says is
> out of scope. I guess SUIT WG can ignore these properties, at least until
> it considers symmetric-only scenarios.
>

Private keys may be broken by side channel attacks
Asymetric keys could be broken by quantum crypto
If a single public key is stored in an OTP, the private key recovery (some
where else in the system) brakes all the updates

> 4. I guess that e.g. a ROM bootloader is included under the category OTP.

Yes if Rom is OTP, i.e. can not be erasable  (for example not EEPROM)

> application.  Should this be considered a weaker version of the OTP

A kind of TEE with OTP ?

> (trusted boot) or not that's very useful and simplifying.

One important thing could be to define the risk for erasing pseudo OTP

> Amyas Phillips

Pascal

> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit
>

---

From: Amyas Phillips <[email-masked]>
Date: Wed, 7 Nov 2018 12:41:20 +0000

Thanks Pascal for the responses.

I take your point that DIV-KEY is always a significant security property.

I still think SUIT WG doesn't need to consider TRT-KEY in its use cases,
being concerned only with authenticating firmware using public keys.
Unless, that is, there's something I don't know (entirely possible) about
theoretical quantum attacks working back from pubkeys to obtain privkeys,
making it necessary to keep pubkeys secret.

Regarding TEEs, yes that's what I have in mind, with NVRAM reserved for the
TEE (not necessarily OTP).

Amyas Phillips

---

From: Brendan Moran <[email-masked]>
Date: Wed, 7 Nov 2018 15:16:34 +0000

Further to Amyas’s comments, I have some additional points to raise.

I don’t see the value in distinguishing between physical loaders and firmware loaders. For example, external serial flash MCUs must copy some portion of external flash into internal RAM prior to executing. Does it matter if this is done by an OTP (mask ROM) bootloader or by a silicon state machine (serial loader)?

The important properties are:

  1.  Self-Updatability: Can the application code storage be written to by the application? (Fundamental requirement)
  2.  Reliability: Does the device recover if an update fails part way?
  3.  Security: Does the device cryptographically validate its boot artefacts?

FLD is a foundational requirement of SUIT.
FLD-SEC, and OTP are covered in draft-ietf-suit-information-model-01: 3.3.8, draft-ietf-suit-architecture-01: 3.5

TRT-KEY:
Only algorithms that rely on shared secrets are vulnerable to side-channel key-recovery attacks. Public key algorithms, including RSA, ECDSA, and Hash-based OTS do NOT have side-channel vulnerabilities at time of verification. This is because all information used in verification is already public. Were there a plausible side-channel attack against one of these algorithms, the algorithm would be fundamentally broken.

TRT-KEY is only relevant for MAC-based firmware authentication. A far more important property is the prevention of overriding the the public key held on-device.

Here is a proposal:

Threat: An attacker modifies firmware/data in the device.
Classification: All Types

By modifying firmware or firmware authenticity keys, the attacker can assume complete control of a device. By modifying data, an attacker can alter the behaviour of the device (Privilege Escalation).

Security Requirement OTP-RoT-KEY:

Devices MUST prevent modification of root firmware authenticity keys. Delegate keys MAY be erased and replaced when verified against the root key.

DIV-KEY: This section confuses me. It appears to be conflating key reuse within a device and key reuse among a class of devices (class keys).

Keys should be diversified by OPERATION and by AUTHORITY: keys used for ECDSA MUST NOT be used for ECDH, for example. Likewise, keys used to authorise firmware installation MUST NOT be used for other purposes, such as authenticating remote systems.  Devices MUST NOT use class-wide private keys whether symmetric or asymmetric. That is to say, only a single entity MUST have access to a given private key (M-of-N key ceremonies excluded).

This is standard practice and SHOULD NOT require explicit documentation, however I can add security requirements to that effect into the information model if the WG believes it is necessary.

Best Regards,
Brendan Moran

On 7 Nov 2018, at 12:41, Amyas Phillips <[email-masked]<mailto:[email-masked]>> wrote:

I still think SUIT WG doesn't need to consider TRT-KEY in its use cases, being concerned only with authenticating firmware using public keys.  Unless, that is, there's something I don't know (entirely possible) about theoretical quantum attacks working back from pubkeys to obtain privkeys, making it necessary to keep pubkeys secret.

Regarding TEEs, yes that's what I have in mind, with NVRAM reserved for the TEE (not necessarily OTP).

Amyas Phillips
_______________________________________________
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.

---

From: Pascal Urien <[email-masked]>
Date: Thu, 8 Nov 2018 12:21:56 +0700

Hello Brendan

Thanks for your comments

Le mer. 7 nov. 2018 à 22:16, Brendan Moran <[email-masked]> a écrit :

> I don’t see the value in distinguishing between physical loaders and
> firmware loaders. For example, external serial flash MCUs must copy some
> portion of external flash into internal RAM prior to executing. Does it
> matter if this is done by an OTP (mask ROM) bootloader or by a silicon
> state machine (serial loader)?
>
>    1. Self-Updatability: Can the application code storage be written to
>    by the application? (Fundamental requirement)
Tthe point of the draft is more about how is flashed the bootloader. In
this mind the bootloader is flashed with some "physical protocol". In many
case a guenine bootloader may be erased and replaced by a malicious other
one

> FLD-SEC, and OTP are covered in draft-ietf-suit-information-model-01:
> 3.3.8, draft-ietf-suit-architecture-01: 3.5
>
>
If OTP is available part/full  image of the bootloader may be stored in a
permanent way.

>
>
> TRT-KEY:
> Only algorithms that rely on shared secrets are vulnerable to side-channel
> key-recovery attacks. Public key algorithms, including RSA, ECDSA, and
> Hash-based OTS do NOT have side-channel vulnerabilities at time of
> verification. This is because all information used in verification is
> already public. Were there a plausible side-channel attack against one of
> these algorithms, the algorithm would be fundamentally broken.
>
> TRT-KEY is only relevant for MAC-based firmware authentication. A far more
> important property is the prevention of overriding the the public key held
> on-device.
>

Agree. There is no full sotfware secure implementation of symetric keys
(AES) known today This paper  https://eprint.iacr.org/2018/098.pdf comments
the result of the WhibOx Contest https://whibox-contest.github.io/

if a public key is used  for signature checking, it should the the target
of malicious bootloader

> By modifying firmware or firmware authenticity keys, the attacker can
> assume complete control of a device. By modifying data, an attacker can
> alter the behaviour of the device (Privilege Escalation).
>
>

> Devices MUST prevent modification of root firmware authenticity keys.
> Delegate keys MAY be erased and replaced when verified against the root key.
>
>
>
> OTP root key implies some part of the bootloader stored in the OTP, like
in TEE

>
> DIV-KEY: This section confuses me. It appears to be conflating key reuse
> within a device and key reuse among a class of devices (class keys).
>
> Keys should be diversified by OPERATION and by AUTHORITY: keys used for
> ECDSA MUST NOT be used for ECDH, for example. Likewise, keys used to
> authorise firmware installation MUST NOT be used for other purposes, such
> as authenticating remote systems.  Devices MUST NOT use class-wide private
> keys whether symmetric or asymmetric. That is to say, only a single entity
> MUST have access to a given private key (M-of-N key ceremonies excluded).
>
> This is standard practice and SHOULD NOT require explicit documentation,
> however I can add security requirements to that effect into the information
> model if the WG believes it is necessary.
>
>
>
When a public key is used for update integrity checking, the main threats
come from inegrity of bootloader and secure storage of the associated
private key somewhere in the iot platform

When is asymetric key is used an important security property is to known is
there is one key per device a key for a set of devices,  especially is no
tamper resistant computing resource is available in the chip. this paper
https://eprint.iacr.org/2016/1047.pdf is a good illustration of this class
of threat.

Best Regards,
> Brendan Moran

Best Regards

Pascal

>
> On 7 Nov 2018, at 12:41, Amyas Phillips <[email-masked]> wrote:
>
> 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.
>