Draft: draft-ietf-suit-firmware-encryption

Commentary: moving into . 
  , here is the reasoning for moving encryption functionality outside the SUIT manifest : When the firmware author needs to encrypt a payload for a specific recipient it needs to know its public key ( for HPKE ) or its symmetric key ( for AES - KW ) . Since the firmware author does not typically know the recipients ahead of time , it can not perform this encryption operation . What he can , however , do is to digitally sign the manifest ( and thereby the firmware image ) since it only requires its private key . Later the distribution system , before delivering the firmware to the devices , will encrypt the firmware images . It can not modify the manifest anymore since otherwise the signature previously generated would be invalidated . Hence , any information regarding firmware encryption has to go into the envelope . I hope this makes sense . For this reason , I believe the current text in the document is correct . 
 I 've misunderstood your intention . Are these correct ? Author has the raw firmware image and creates by signing the with its signing key . Distribution System receives the raw firmware image and its from the Author , then encrypts the firmware . It appends to ( outside the ) . Device verifies the and decrypts encrypted firmware image using . My concern is that the would be untrusted because it locates outside the signature . How about this one ? The order of suit - protection - wrappers array corresponds to the suit - components array in suit - common it can be if no decryption is required The Device can verify whether the decrypted firmware image is correct using the digest hash of raw firmware image the image digest and the image size are trusted because they are inside the though the s are untrusted because they are outside the The Author MUST aware that the firmware will be encrypted by Distribution System to create appropriate suit - install section 
 The distribution system is not untrusted but rather trusted to do the encryption of the plaintext firmware image and to distribute it to the intended recipients . If the author already knows the recipients ahead of time and has their public keys , then it can also encrypt the firmware image without relying on the distribution system . Hence , I do not believe that the wording that the distribution system is untrusted is correct . Note that the recipient will get to learn that the encryption has been applied by the distribution system since the encryption info is also signed . The recipient ( device ) can still check the signature of the manifest to verify whether the plaintext image has been unchanged . Hence , I do n't see a problem with the approach 
  , I agree with you that the manifest needs to carry a hash of the plaintext firmware and it also needs to contain instructions for matching the hash against a specific value . The reason why I believe that no commands for processing the encrypted payload are needed is simply because the encryption must happen before any of the other processing steps need to take place . Otherwise nothing can proceed . Is this the right approach ? I do n't know . 
 I wonder whether we should bring this up on the SUIT mailing list since it is an important design decision . 
 The term " untrusted " I used was ambiguous , but I meant the part was outside the signature . Before discussing in the mailing list let me confirm this : Distribution System is trusted case A-1 ) as a firmware server and a device management infrastructure case A-2 ) as a firmware server and a device management infrastructure , and also a manifest signer The firmware is encrypted by case B-1 ) the Author case B-2 ) the Distribution System With case A-2 , the Distribution System can just update the manifest and then update the signature because Devices trusts its public key . With case B-1 , the Author can create encrypted firmware and its manifest , so that there is no need Distribution System to modify the manifest . They work well with current SUIT Manifest , but our case does not especially with non - integrated payload . Am I correct ? 
 I think you are saying that because a non - integrated payload requires a URI to be included in the manifest , which will then be integrity protected . Hence , the distribution system will not be able to change that URL and it will typically not have permissions to replace the content of the referenced file . Is this correct ? FYI : I think it would be good to have examples of all these cases in the draft . 
 Here is what Øyvind proposes in 
 In the firmware encryption draft we have defined an extension to the envelope that indicates what encryption parameters are applied to which component . Here is the CDDL : Currently the text provides no explanation or an example of how this linkage works . 
 This aspect is related to and to the mailing list discussion 
 This issue is also related to 
 With in PR , this issue is solved . 
 SUITEncryptionInfo was defined in the past SUIT Manifest core document describing how to decrypt the firmware image , but in this document it may not be associated with any component . I will create a   to move SUITEncryptionInfo under the suit - manifest . 
 See also
Mailing list commentary: A new idea to leverage SUIT Dependency for Firmware Encryption has come up to my mind . Please review and make comments , especially for SUIT Manifest usage and security considerations . # Background # # Condition The Author creates firmware and its manifest The Distribution System encrypts the firmware and distribute it to Devices The Device fetches and decrypts encrypted firmware , then check and install it # # Current I - D It introduces new section suit - security - wrapper holding SUITEncryptionInfo , which is appended by the Distribution System The Device decrypts the encrypted firmware with SUITEncryptionInfo and then check it with condition - image - match # # Issues Distribution System can not modify the URI in the manifest where the encrypted firmware is stored SUITEncryptionInfo is used without verification because it locates out of the Author 's signature # New idea # # Proposal The Author and the Distribution System create manifest respectively Distribution System 's manifest fetches encrypted firmware and decrypts it , and depends on Author 's manifest Author 's manifest check the decrypted firmware with condition - image - match The Device MUST trust both Author and Distribution System keys to verify manifests # # Solves The Distribution System can freely set the URI to distribute encrypted firmware in Distribution System 's manifest SUITEncryptionInfo is inside signature created by the Distribution System # # Author 's manifest ( dependee ) ( Only important parts are shown in this example ) / SUITEnvelope = / { suit - authentication - wrapper : SUITAuthentication / by Author / , / inside the signature / suit - manifest : & gt ; , suit - install : & gt ; , suit - parameter - image - size : & gt ; } , suit - condition - image - match ] & gt ; & gt ; } & gt ; & gt ; } # # Distribution System 's manifest ( dependent ) ( Only important parts are shown in this example ) / SUITEnvelope = / { suit - authentication - wrapper : SUITAuthentication / by Distribution System / , / inside the signature / suit - manifest : & gt ; , suit - dependency - resolution : & gt ; , suit - install : & lt ; & lt ; [ / loads encrypted firmware / suit - directive - set - component - index 1 / [ h'01 ' ] / , suit - directive - override - parameters { suit - parameter - uri : " " } , suit - directive - fetch , / decrypts it / suit - directive - set - component - index 0 / [ h'00 ' ] / , suit - directive - override - parameters { suit - parameter - source - component : 1 / [ h'01 ' ] / suit - parameter - encryption - info : SUITEncryption_Info / how to decrypt / } , suit - directive - copy , / request to parse Author 's manifest / suit - directive - set - dependency - index 0 / Author 's Manifest / , suit - process - dependency / triggers suit - install section in Author 's manifest / ] & gt ; & gt ; } & gt ; & gt ; } Best ,
missing
Paragraph (version A):
This specification introduces two extensions to the SUIT envelope and
the manifest structure, as motivated in arch.
Paragraph (version A):
The SUIT envelope is enhanced with a key exchange payload, which is
carried inside the suit-protection-wrappers parameter, see envelope-
fig.  One or multiple SUIT_Encryption_Info payload(s) are carried
within the suit-protection-wrappers parameter.  The content of the
SUIT_Encryption_Info payload is explained in AES-KW (for AES-KW) and
in HPKE (for HPKE).  When the encryption capability is used, the
suit-protection-wrappers parameter MUST be included in the envelope.
Paragraph (version A):
The manifest is extended with a CEK verification parameter (called
suit-cek-verification), see manifest-fig.  This parameter is optional
and is utilized in environments where battery exhaustion attacks are
a concern.  Details about the CEK verification can be found in cek-
verification.
Paragraph (version B):
This specification introduces two extensions to the SUIT_Parameters,
as motivated in arch.
Paragraph (version B):
The SUIT manifest is enhanced with a key exchange payload, which is
carried within the suit-directive-override-parameters or suit-
directive-set-parameters for each encrypted payload.  One
SUIT_Encryption_Info is carried with suit-parameter-encryption-info,
see parameter-fig.  The content of the SUIT_Encryption_Info is
explained in AES-KW (for AES-KW) and in HPKE (for HPKE).  When the
encryption capability is used, the SUIT_Encryption_Info parameter
MUST be included in the SUIT_Directive.
Paragraph (version B):
A CEK verification parameter (called suit-parameter-cek-
verification), see parameter-fig, also extends the manifest.  This
parameter is optional and is utilized in environments where battery
exhaustion attacks are a concern.  Details about the CEK verification
can be found in cek-verification.