[Suit] Fwd WGLC on draft-ietf-suit-firmware-encryption-14 due on September 11, 2023

[Hannes Tschofenig <[e-mail]>]

In this email I am forwarding review comments of
draft-ietf-suit-firmware-encryption-14 from Ruud Derwig. Ruud chaired a
EEMBC security group for many years, which developed the SecureMark-TLS
benchmark. I asked him to review the draft because of his unique
security expertise.

Thanks again for the review comments, Ruud.


Ciao

Hannes


----



Hi Hannes,



I finally had some time to look at this. Please find my feedback notes
below – not sure it all makes sense, I may miss some context/goals or
assumptions…



     Introduction

“Encryption prevents third parties, including attackers, from gaining
access to the firmware binary. Hackers typically need intimate knowledge
of the target firmware to mount their attacks. For example,
return-oriented programming (ROP) [ROP] requires access to the binary
and encryption makes it much more difficult to write exploits.”



All good, maybe (could be considered out of scope for this) add a remark
that beside confidentiality of the binary, confidentiality of the
sources (e.g. in case of open-source) may be required as well to prevent
reverse engineering and/or reproduction of the binary firmware)



     Conventions

This seems not only about conventions, but also some
assumptions/use-models. E.g. “The author, which is responsible for
creating the firmware image, does not know the recipients.”. I can
imagine a different scenario where the channel/distribution system is
not trusted, and the author does know the recipient.

Is the goal protection of images during transportation, or when at rest
stored inside a device?

These may be different, and e.g. devices may have a unique key
programmed into OTP for firmware decryption. In such a case, the
provider of the firmware / provisioning service could encrypt the
firmware with that device unique key (in a secure environment) and
simply use that as payload with the firmware update service (no need to
trust the ‘channel’).



Or, maybe this is just a matter of definitions, and the role for the one
doing the encryption is what the document calls “distribution”, but
could be the same as the ‘author’.



     Architecture

Reading on, I see the author does may know the recipient? Or at least
get that info from the distributor.



4 to 6 : didn’t review in detail, need to dive into the latest SUIT
stuff first…



7 firmware updates in flash memory

Is this an informative section, or part of the proposed standard?



More and more devices support HW-based, inline/on-the-fly decryption. Is
that in scope of this proposal? In such a case, the encryption details
are determined by the specific HW (and could be a differentiating
feature/secret of the vendor), and firmware could still execute in place
(XIP) instead of being copied.



“Since the image in primary slot is available in cleartext” -> this
seems to imply that the encryption is only for protection of the
distribution. How about protection of firmware images inside devices? If
it is only about the channel, aren’t their simpler ways (TLS) to ensure
confidentiality?





Regards,



Ruud.