Draft: draft-ietf-suit-firmware-encryption

Commentary: Mostly focused on replacing the term " firmware " with " payload " .
Paragraph (version A):
The SUIT manifest provides the data needed for authorized recipients
of the firmware image to decrypt it.  The firmware image is encrypted
using a symmetric key.  This symmetric cryptographic key is
established for encryption and decryption, and that key can be
applied to a SUIT manifest, firmware images, or personalization data,
depending on the encryption choices of the firmware author.
Paragraph (version B):
The SUIT manifest provides the data needed for authorized recipients
of the firmware image to decrypt it.  The firmware image is encrypted
using a symmetric key.
Paragraph (version A):
The document also contains a number of examples.
Paragraph (version A):
The original motivating use case of this document was to encrypt
firmware.  However, SUIT manifests may require other payloads than
firmware images to experience confidentiality protection using
encryption, for example software, personalization data, configuration
data, or machine learning models.  While the term firmware is used
throughout the document, plaintext other than firmware images may get
encrypted using the described mechanism.  Hence, the terms firmware
(image), software and plaintext are used interchangeably.
Paragraph (version B):
While the original motivating use case of this document was firmware
encryption, SUIT manifests may require payloads other than firmware
images to experience confidentiality protection, such as - software
(other than firmware), - personalization data, - configuration data,
- machine learning models, etc.
Paragraph (version B):
Hence, the term payload is used to generically refer to those objects
that may be subject to encryption.
Paragraph (version A):
Sender: Role of the entity that sends an encrypted message.
Paragraph (version A):
Recipient: Role of the entity that receives an encrypted message.
The terms firmware consumer and recipient are used interchangeably
in this document.
Paragraph (version B):
Sender: Role of the entity that sends an encrypted payload.
Paragraph (version B):
Recipient: Role of the entity that receives an encrypted payload.
Paragraph (version A):
RFC9019 describes the architecture for distributing firmware images
and manifests from the author to the firmware consumer.  It does not,
however, detail the use of encrypted firmware images.
Paragraph (version A):
This document enhances the SUIT architecture to include firmware
encryption.  arch-fig shows the distribution system, which represents
the firmware server and the device management infrastructure.  The
distribution system is aware of the individual devices to which a
firmware update has to be delivered.
Paragraph (version A):
Firmware encryption requires the sender to know the firmware
consumers and the respective credentials used by the key distribution
mechanism.  For AES-KW the KEK needs to be known and, in case of
HPKE, the sender needs to be in possession of the public key of the
recipient.
Paragraph (version A):
The firmware author may have knowledge about all devices that need to
receive an encrypted firmware image but in most cases this is not
likely.  The distribution system certainly has the knowledge about
the recipients to perform firmware encryption.
Paragraph (version A):
The firmware author acts as the sender and the recipient is the
firmware consumer (or the firmware consumers).
Paragraph (version A):
The firmware author encrypts the firmware image with the
distribution system as the initial recipient.  Then, the
distribution system decrypts and re-encrypts the firmware image
towards the firmware consumer(s).  Delegating the task of re-
encrypting the firmware image to the distribution system offers
flexiblity when the number of devices that need to receive
encrypted firmware images changes dynamically or when updates to
KEKs or recipient public keys are necessary.  As a downside, the
author needs to trust the distribution system with performing the
re-encryption of the firmware image.
Paragraph (version A):
Irrespectively of the two variants, the key distribution data (in the
form of the COSE_Encrypt structure) is included in the SUIT envelope
rather than in the SUIT manifest since the manifest will be digitally
signed (or MACed) by the firmware author.
Paragraph (version A):
Since the SUIT envelope is not protected cryptographically an
adversary could modify the COSE_Encrypt structure.  For example, if
the attacker alters the key distribution data then a recipient will
decrypt the firmware image with an incorrect key.  This will lead to
expending energy and flash cycles until the failure is detected.  To
mitigate this attack, the optional suit-cek-verification parameter is
added to the manifest.  Since the manifest is protected by a digital
signature (or a MAC), an adversary cannot successfully modify this
value.  This parameter allows the recipient to verify whether the CEK
has successfully been derived.
Paragraph (version B):
RFC9019 describes the architecture for distributing payloads and
manifests from an author to devices.  It does, however, not detail
the use of payload encryption.
Paragraph (version B):
This document enhances this architecture to support encryption.  The
author and the distribution system are logical roles.  In some
deployments these roles are separated in different physical entities
and in others they are co-located.
Paragraph (version B):
arch-fig shows the distribution system, which represents the firmware
server and the device management infrastructure.  The distribution
system is aware of the individual devices to which a payload has to
be delivered.  The author is typically unaware which devices need to
receive these payloads.
Paragraph (version B):
To apply encryption the sender needs to know the recipient.  For AES-
KW the KEK needs to be known and, in case of HPKE, the sender needs
to be in possession of the public key of the recipient.
Paragraph (version B):
If the author delegates the task of identifying devices that are the
recipients of the payloads to the distribution system, it needs to
trust the delivery system to perform the encryption of the plaintext
firmware image.
Paragraph (version B):
The author acts as the sender and the recipient is the device (or
the devices).
Paragraph (version B):
The author treats the distribution system as the initial
recipient.  Then, the distribution system decrypts and re-encrypts
the payload for consumption by the device (or devices).
Delegating the task of re-encrypting the payload to the
distribution system offers flexiblity when the number of devices
that need to receive encrypted payloads changes dynamically or
when updates to KEKs or recipient public keys are necessary.  As a
downside, the author needs to trust the distribution system with
performing the re-encryption of the payload.
Paragraph (version B):
For both variants the key distribution data (embedded inside the
COSE_Encrypt structure) is included in the SUIT envelope rather than
in the SUIT manifest since the manifest will be digitally signed (or
MACed) by the author.
Paragraph (version A):
If all authorized recipients have access to the KEK, a single
COSE_recipient structure contains the encrypted CEK.  This means
KEK(*,S) ENC(CEK,KEK), and ENC(firmware,CEK).
Paragraph (version A):
If recipients have different KEKs, then multiple COSE_recipient
structures are included but only a single CEK is used.  Each
COSE_recipient structure contains the CEK encrypted with the KEKs
appropriate for the recipient.  In short, KEK_1(R1, S),...,
KEK_n(Rn, S), ENC(CEK, KEK_i) for i=1 to n, and ENC(firmware,CEK).
The benefit of this approach is that the firmware image is
encrypted only once with a CEK while there is no sharing of the
KEK across recipients.  Hence, authorized recipients still use
their individual KEKs to decrypt the CEK and to subsequently
obtain the plaintext firmware.
Paragraph (version A):
The third option is to use different CEKs encrypted with KEKs of
the authorized recipients.  Assume there are KEK_1(R1, S),...,
KEK_n(Rn, S), and for i=1 to n the following computations need to
be made: ENC(CEK_i, KEK_i) and ENC(firmware,CEK_i).  This approach
is appropriate when no benefits can be gained from encrypting and
transmitting firmware images only once.  For example, firmware
images may contain information unique to a device instance.
Paragraph (version A):
The COSE_Encrypt conveys information for encrypting the firmware
image, which includes information like the algorithm and the IV, even
though the firmware image is not embedded in the
COSE_Encrypt.ciphertext itself since it conveyed as detached content.
Paragraph (version B):
If all authorized recipients have access to the KEK, a single
COSE_recipient structure contains the encrypted CEK.  This means
KEK(*,S) ENC(CEK,KEK), and ENC(payload,CEK).
Paragraph (version B):
If recipients have different KEKs, then multiple COSE_recipient
structures are included but only a single CEK is used.  Each
COSE_recipient structure contains the CEK encrypted with the KEKs
appropriate for the recipient.  In short, KEK_1(R1, S),...,
KEK_n(Rn, S), ENC(CEK, KEK_i) for i=1 to n, and ENC(firmware,CEK).
The benefit of this approach is that the payload is encrypted only
once with a CEK while there is no sharing of the KEK across
recipients.  Hence, authorized recipients still use their
individual KEKs to decrypt the CEK and to subsequently obtain the
plaintext.
Paragraph (version B):
The third option is to use different CEKs encrypted with KEKs of
the authorized recipients.  Assume there are KEK_1(R1, S),...,
KEK_n(Rn, S), and for i=1 to n the following computations need to
be made: ENC(CEK_i, KEK_i) and ENC(firmware,CEK_i).  This approach
is appropriate when no benefits can be gained from encrypting and
transmitting payloads only once.  For example, payloads may
contain information unique to an instance of a device rather than
information that is independent of a device instance and therefore
applies to an entire class of devices.
Paragraph (version B):
The COSE_Encrypt conveys information for encrypting the payload,
which includes information like the algorithm and the IV, even though
the payload is not embedded in the COSE_Encrypt.ciphertext itself
since it conveyed as detached content.
Paragraph (version A):
For use with firmware encryption the scheme works as follows: HPKE,
which internally utilizes a non-interactive ephemeral-static Diffie-
Hellman exchange to derive a shared secret, is used to encrypt a CEK.
This CEK is subsequently used to encrypt the firmware image.  Hence,
the plaintext passed to HPKE is the randomly generated CEK.  The
output of the HPKE SealBase function is therefore the encrypted CEK
along with HPKE encapsulated key (i.e., the ephemeral ECDH public
key).
Paragraph (version B):
For use with this specification the scheme works as follows: HPKE,
which internally utilizes a non-interactive ephemeral-static Diffie-
Hellman exchange to derive a shared secret, is used to encrypt a CEK.
This CEK is subsequently used to encrypt the firmware image.  Hence,
the plaintext passed to HPKE is the randomly generated CEK.  The
output of the HPKE SealBase function is therefore the encrypted CEK
along with HPKE encapsulated key (i.e., the ephemeral ECDH public
key).
Paragraph (version A):
As explained in arch, the suit-cek-verification parameter is optional
to implement and optional to use.  When used, it reduces the risk of
a battery exhaustion attack against the IoT device.
Paragraph (version B):
While the SUIT manifest is integrity protected and authenticated, the
SUIT envelope is not protected cryptographically.  Hence, an
adversary located along the communication path between the sender and
the recipient could modify the COSE_Encrypt structure (assuming that
no other communication security mechanism is in use).
Paragraph (version B):
For example, if the attacker alters the key distribution data then a
recipient will decrypt the firmware image with an incorrect key.
This will lead to expending energy and flash cycles until the failure
is detected.
Paragraph (version B):
To mitigate this attack, a new parameter, called suit-cek-
verification, is added to the manifest.  The suit-cek-verification
parameter is optional to implement and optional to use.  When used,
it reduces the risk of a battery exhaustion attack against the IoT
device.
Paragraph (version B):
Since the manifest is protected by a digital signature (or a MAC), an
adversary cannot successfully modify this value.  This parameter
allows the recipient to verify whether the CEK has successfully been
derived.
Paragraph (version A):
is in possession of the public key of the firmware consumer (for
use with HPKE).
Paragraph (version A):
Both cases require some upfront communication interaction, which is
not part of the SUIT manifest.  This interaction is likely provided
by an IoT device management solution, as described in RFC9019.
Paragraph (version B):
is in possession of the public key of the recipient (for use with
HPKE).
Paragraph (version B):
Both cases require some upfront communication interaction.  This
interaction is likely provided by an IoT device management solution,
as described in RFC9019.
Paragraph (version A):
In some cases third party companies analyse binaries for known
security vulnerabilities.  With encrypted firmware images this type
of analysis is prevented.  Consequently, these third party companies
either need to be given access to the plaintext binary before
encryption or they need to become authorized recipients of the
encrypted firmware images.  In either case, it is necessary to
explicitly consider those third parties in the software supply chain
when such a binary analysis is desired.
Paragraph (version B):
In some cases third party companies analyse binaries for known
security vulnerabilities.  With encrypted payloads this type of
analysis is prevented.  Consequently, these third party companies
either need to be given access to the plaintext binary before
encryption or they need to become authorized recipients of the
encrypted payloads.  In either case, it is necessary to explicitly
consider those third parties in the software supply chain when such a
binary analysis is desired.