Draft: draft-ietf-suit-firmware-encryption

Commentary: Run the kramdown and xml2rfc tools to update the .xml and .txt files . This generates numerous warnings , which can be fixed in subsequent changes . kramdown - rfc2629 1.6.6 xml2rfc 3.13.1 kramdown - rfc2629 draft - ietf - suit - firmware- draft - ietf - suit - firmware- ' No link definition for link ID '' [ editor ' 's note : add examples for a complete manifest here ( including a digital signature ) , multiple recipients , encryption of manifests ( in comparison to firmware images ) . ] '' found on line 532 ' ' No link definition for link ID '' editor ' 's note : add examples for a complete manifest here ( including a digital signature ) , multiple recipients , encryption of manifests ( in comparison to firmware images ) . '' found on line 532 ' .refcache / reference . I - D.ietf - suit- renewing ( stale by 3.0 days ) from .refcache / reference . I - D.ietf - cose- renewing ( stale by 3.0 days ) from .refcache / reference . I - D.housley - cose - aes - ctr - and- renewing ( stale by 3.0 days ) from xml2rfc draft - ietf - suit - firmware- /home / davidb / linaro / suit - firmware - encryption / draft - ietf - suit - firmware-(23 ): Warning : Expected a valid submissionType ( stream ) setting , one of IETF , IAB , IRTF , independent , but found None . Will use ' IETF ' /home / davidb / linaro / suit - firmware - encryption / draft - ietf - suit - firmware-(342 ): Warning : Artwork too wide , reducing indentation from 0 to 0 /home / davidb / linaro / suit - firmware - encryption / draft - ietf - suit - firmware-(342 ): Warning : Figure too wide , reducing indentation from 3 to 1 Created file draft - ietf - suit - firmware- 
 There are also numerous whitespace errors ( usually space at the end of a line ) in the source . I 'll address these as I also address some of the other formatting issues .
Paragraph (version A):
This document specifies a firmware update mechanism where the
firmware image is encrypted.  Firmware encryption uses the IETF SUIT
manifest with key establishment provided by hybrid public-key
encryption (HPKE) and AES Key Wrap (AES-KW).  HPKE uses public key
cryptography while AES-KW uses a pre-shared key-encryption key.
Encryption of the firmware image is accomplished with convential
symmetric key cryptography.
Paragraph (version B):
This document specifies techniques for encrypting software, firmware
and personalization data by utilizing the IETF SUIT manifest.  Key
establishment is provided by hybrid public-key encryption (HPKE) and
AES Key Wrap (AES-KW).  HPKE uses public key cryptography while AES-
KW uses a pre-shared key-encryption key.  Encryption of the plaintext
is accomplished with conventional symmetric key cryptography.
Paragraph (version A):
The main use case of this document is to encrypt firmware.  However,
SUIT manifests may require other payloads than firmware images to
experience confidentiality protection using encryption, for example
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) and plaintext are used
interchangably.
Paragraph (version B):
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 A):
Sender: Role of entity which sends an encrypted message.
Paragraph (version A):
Recipient: Role of entity which receives an encrypted message.
Paragraph (version B):
Sender: Role of the entity that sends an encrypted message.
Paragraph (version B):
Recipient: Role of the entity that receives an encrypted message.
The terms firmware consumer and recipient are used interchangeably
in this document.
Paragraph (version A):
RFC9019 describes the architecture for distributing firmware images
and manifests from the author to the firmware consumer.  It does,
however, not detail the use of encrypted firmware images.
Paragraph (version B):
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):
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 B):
likely.  The distribution system certainly has the knowledge about
the recipients to perform firmware encryption.
Paragraph (version A):
Irrespectively of the two variants, the key distribution data (in
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 B):
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):
When the firmware image is encrypted for use by multiple recipients,
there are three options.  We use the following notation KEK(R1,S) is
the KEK shared between recipient R1 and the sender S.  Likewise,
CEK(R1,S) is shared between R1 and S.  If a single CEK or a single
KEK is shared with all authorized recipients R by a given sender S in
a certain context then we use CEK(_,S) or KEK(_,S), respectively.
The notation ENC(plaintext, key) refers to the encryption of
plaintext with a given key.
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 accross recipients.  Hence, authorized recipients still use
their individual KEKs to decrypt the CEK and to subsequently
obtain the plaintext firmware.
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 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 resulting COSE_Encrypt structure in a dignostic format is shown
in aeskw-example.
Paragraph (version B):
The resulting COSE_Encrypt structure in a diagnostic format is shown
in aeskw-example.
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 A):
Only the holder of recipient's private key can decapsulate the CEK to
decrypt the firmware.  Key generation in HPKE is influced by
additional parameters, such as identity information.
Paragraph (version A):
This approach allows all recipients to use the same CEK to encrypt
the firmware image, in case there are multiple recipients, to fulfill
a requirement for the efficient distribution of firmware images using
a multicast or broadcast protocol.
Paragraph (version B):
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):
Only the holder of recipient's private key can decapsulate the CEK to
decrypt the firmware.  Key generation in HPKE is influenced by
additional parameters, such as identity information.
Paragraph (version B):
This approach allows all recipients to use the same CEK to decrypt
the firmware image, in case there are multiple recipients, to fulfill
a requirement for the efficient distribution of firmware images using
a multicast or broadcast protocol.
Paragraph (version A):
The suit-cek-verification parameter contains a byte string resulting
from the encryption of 8 bytes of 0xA5 using the CEK with a nonce of
all zeros and empty additional data using the cipher algorithm and
mode also used to encrypt the plaintext.
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
an battery exhaustion attack against the IoT device.
Paragraph (version B):
The suit-cek-verification parameter contains a byte string resulting
from the encryption of 8 bytes of 0xA5 using the CEK with a nonce of
all zeros and empty additional data using the cipher algorithm and
mode also used to encrypt the plaintext.  The same nonce used for CEK
verification MUST NOT be used to encrypt plaintext with the same CEK.
Paragraph (version B):
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 A):
The ability to restart an interrupted firmware update is often a
requirement for low-end IoT devices.  To fulfill this requirement it
is necessary to chunk a larger firmware image into blocks and to
encrypt each block individually using a cipher that does not increase
the size of the resulting ciphertext (i.e. by not adding an
authentication tag after each encrypted block).
Paragraph (version B):
The ability to restart an interrupted firmware update is often a
requirement for low-end IoT devices.  To fulfill this requirement it
is necessary to chunk a larger firmware image into blocks and to
encrypt each block individually using a cipher that does not increase
the size of the resulting ciphertext (i.e., by not adding an
authentication tag after each encrypted block).
Paragraph (version A):
This document registers several cipher algorithms for use with
firmware encryption that do not offer integrity protection.  These
ciphers are registered within the COSE algorithm registry but are
dedicated for this specific applications only.  Hence, all algorithms
listed in iana-algo are not recommended for general use.
Paragraph (version B):
I-D.housley-cose-aes-ctr-and-cbc registers several ciphers that do
not offer integrity protection.
Paragraph (version A):
Since the CEK is randomly generated, it must be ensured that the
guidelines for random number generations are followed, see RFC8937.
Paragraph (version B):
Since the CEK is randomly generated, it must be ensured that the
guidelines for random number generation in RFC8937 are followed.