Re: [Suit] Draft-ietf-suit-manifest encryption use

[Hannes Tschofenig <[e-mail]>]

Hi Russ, Hi Brendan,

Approach #1 below moves the key management outside SUIT. That's not necessarily bad, particularly since we have a solution for carrying this information --> TEEP. However, I would prefer to have the COSE_Encrypt structure attached to the manifest unless we want to re-use a single COSE_Encrypt structure across multiple firmware updates. Although never mentioned explicitly I thought we wanted to use new keys with every update. This would then argue for attaching / embedding the COSE_Encrypt structure to the manifest (or more precisely to the envelope).

I believe during the virtual interim meeting we had a preference for the approach Russ outlined. I hope we are not suggesting that the COSE_Encrypt structure is unauthenticated but rather that it is protected by the distribution network (instead of the firmware author). The main reason is that the firmware author does not necessarily know the keys for all the recipients. Needless to say that we need to describe this in draft-tschofenig-suit-firmware-encryption.

Moving the COSE_Encrypt structure to the envelope, as Russ mentioned below, raises a few issues. One of them is the question about authentication. There is less of a problem with AES key wrap because the CEK is protected by the KEK. However, I would still want to tie the COSE_Encrypt structure to the manifest. The COSE_Encrypt structure is obviously tied to the firmware image. The problem is with the hybrid public key encryption mode, as it is currently defined (since I assumed that there is a signature covering the COSE_Encrypt structure). We would have to extend the description by using one of the authentication options already defined for HPKE.

Before working out the details, let me try to illustrate an example to see whether it matches your understanding? The envelope was enhanced by a new structure (called encryption), which sits in between the authentication-wrapper and the manifest  (in this example).

  {  / Envelope /
      / authentication-wrapper / 2:bstr .cbor ([
          digest: bstr .cbor ([
              / algorithm-id / 2 / "sha256" /,
              / digest-bytes /
  h'987eec85fa99fd31d332381b9810f90b05c2e0d4f284a6f4211207ed00fff750'
          ]),
          signature: bstr .cbor (18([
                  / protected / bstr .cbor ({
                      / alg / 1:-7 / "ES256" /,
                  }),
                  / unprotected / {
                  },
                  / payload / F6 / nil /,
                  / signature / h'0008d2678ddda1afd6846cb9272f539a789e4c
  ed4c874774e58dbe4cf1607e755668029ad6383d4e14c72083ba43002fe3f5cda48859
  90c9b59135976b80ebc9'
              ]))
          ]
      ]),
       / encryption / 4:bstr .cbor (
       [
           // protected field with alg=AES-GCM-128
           h'A10101',
           {
              // unprotected field with iv
              5: h'26682306D4FB28CA01B43B80'
           },
           // null because of detached ciphertext
           null,
           [ // recipients array
              h'', // protected field
              {    // unprotected field
                 1: -3,            // alg=A128KW
                 4: h'6B69642D31'  // key id
              },
              // CEK encrypted with KEK
              h'AF09622B4F40F17930129D18D0CEA46F159C49E7F68B644D'
           ]
       ]
       ),
      / manifest / 3:bstr .cbor ({
          / manifest-version / 1:1,
          / manifest-sequence-number / 2:1,
          / common / 3:bstr .cbor ({
              / components / 2:[
                  [h'00']
              ],
              / common-sequence / 4:bstr .cbor ([
                  / directive-override-parameters / 20,{
                      / vendor-id /
  1:h'fa6b4a53d5ad5fdfbe9de663e4d41ffe' / fa6b4a53-d5ad-5fdf-
  be9d-e663e4d41ffe /,
                      / class-id / 2:h'1492af1425695e48bf429b2d51f2ab45'
  / 1492af14-2569-5e48-bf42-9b2d51f2ab45 /,
                      / image-digest / 3:bstr .cbor ([
                          / algorithm-id / 2 / "sha256" /,
                          / digest-bytes /
  h'00112233445566778899aabbccddeeff0123456789abcdeffedcba9876543210'
                      ]),
                      / image-size / 14:34768,
                  } ,
                  / condition-vendor-identifier / 1,15 ,
                  / condition-class-identifier / 2,15
              ]),
          }),
          / install / 9:bstr .cbor ([
              / directive-set-parameters / 19,{
                  / uri / 21:'http://example.com/file.bin',
              } ,
              / directive-fetch / 21,2 ,
              / condition-image-match / 3,15
          ]),
          / validate / 10:bstr .cbor ([
              / condition-image-match / 3,15
          ]),
      }),
  }

Ciao
Hannes

-----Original Message-----
From: Suit <[e-mail]> On Behalf Of Russ Housley
Sent: Wednesday, June 2, 2021 10:00 PM
To: Brendan Moran <[e-mail]>
Cc: suit <[e-mail]>
Subject: Re: [Suit] Draft-ietf-suit-manifest encryption use

Brendan:

I thought we talked about moving the whole COSE_Encrypt structure so that it was not covered by the signature.  That would allow a party in the distribution path to change the COSE_Recipients without damage to the signature.  Since we a re using detached payload, the implementation needs to remember the resulting CEK.  Which is still needed in your proposal, I believe.

Russ


> On Jun 2, 2021, at 5:59 AM, Brendan Moran <[e-mail]> wrote:
>
> During the virtual interim, we raised the point that the COSE_Recipients for a COSE_Encrypt should not be covered by a signature or digest. This prevents a management system from sending each recipient only the COSE_Recipient structure that pertains to it. This is not ideal for the structure of the manifest.
>
> I can see several ways forward:
> 1. Key agreement is explicitly out-of-band. The manifest uses COSE_Encrypt0 exclusively. No changes are needed to the manifest. The kid header parameter is used to distinguish between keys for different payloads.
>
> 2. The manifest references encryption information by URI. The typical approach is to place the encryption info in the SUIT_Envelope, then reference it by a numeric reference. (e.g. 12 for key 12 in the current SUIT_Envelope). This approach permits the distributor to edit the COSE_Recipients, which allows a firmware author to include all recipients. The distributor can then remove all but the intended recipient. Federated distributors are also possible, where the COSE_Recipients is reduced at each level of distribution.
>
> 3. Break COSE’s existing conventions: set COSE_Recipients to nil in order to represent that COSE_Recipients is detached. This is problematic for two reasons: first, it means that we break compatibility with existing COSE libraries, since they will not expect a detached COSE_Recipients; second, it leaves no way to indicate where to find COSE_Recipients. Instead of ’nil’ we could use an int.
>
> I think we should probably discard Option 3. I worry that Option 2 exposes a number of options for tampering with the COSE_Encrypt. It also means that the parser has to advance past the manifest in order to locate the COSE_Encrypt blocks. The envelope should not contain an enormous number of elements, so it may be acceptable to simply hold a table in memory of the key, start, end of each element of the envelope.
>
> We could enable both 1 and 2 by changing the current SUIT Parameter:
> ORIGINAL:
>        SUIT_Encryption_Info = COSE_Encrypt_Tagged/COSE_Encrypt0_Tagged
> PROPOSED:
>        SUIT_Encryption_Info = int / COSE_Encrypt_Tagged/COSE_Encrypt0_Tagged
>
>
> Alternatively, we could enable both 1 and 2 by adding a new parameter:
>
> SUIT_Parameters //= (suit-parameter-encryption-ref
>    => int)
>
> Best Regards,
> Brendan
> 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.
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit

_______________________________________________
Suit mailing list
[e-mail]
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.