Re: [Suit] CEK Distribution Method

[Hannes Tschofenig <[e-mail]>]

Hi Markus,

I guess we will have to look into the symmetric key mechanism in the near future and I have taken your wording changes into account when submitting the -02 version. Thanks for the text proposals.

Ciao
Hannes

From: [e-mail] [mailto:[e-mail]]
Sent: 02 March 2018 11:51
To: Hannes Tschofenig; Brendan Moran; [e-mail]
Subject: CEK Distribution Method


Hannes,



I added comments regarding your suggestion, question to CEK Distribution Method marked with [mg].



Thanks,

Markus

Page 9, Section 4 Architecture

It states: "
For confidentiality protection of firmware images the author needs
      to be in possession of the certificate/public key of a device."

There are also Symmetric Key Options (Recipient Algorithms) for Content Encryption Key (CEK) Distribution, which is actually already stated in the manifest draft .
-Therefore the above sentence should be updated to reflect, clarify also usage of symmetric keys as an additional option for confidentiality protection!?

[Hannes] I believe this is correct since the use of a key transport mechanism would require the use of public key encryption of the content encryption key. The CEK would then be used to encrypt the firmware image itself. This would still require the author to know the public keys of all the device.

The pure use of symmetric keys has only been envisioned but not described so far.

[mg] Regarding your point that it has not been described so far I had a different understanding when I browsed through the manifest.
That was actually my original motivation for that comment to have consistency between what is stated in the architecture and in the manifest.
The current manifest version, Page 8, Secion 3.2 states:
" Encryption is handled by the COSE_Encrypt structure.  Most encryption
   modes are already supported via the COSE_Encrypt structure, only per-
   device pre-shared keys (or per-device ECDH derivation of pre-shared
   keys) needs to be described."

'Most encryption modes are already supported via the COSE_Encrypt structure'
implied to me that one can use any Mode defined in COSE_Encrypt including symmetric keys to 'protect' the CEK.
Also the text 'only per- device pre-shared keys' implied usage of symmetric keys to me.

This has been described in the initial FUD manifest version, which had explicit text describing pre-shared keys :
Encryption using a symmetric key (mode="preSharedKey").  The
      assumption is that the symmetric key is pre-provisioned (in an
      out-of-band fashion) on the IoT device and also available to the
      developer.

In addition to have consistency with the manifest, I don't see why SUIT should limit the options provided by COSE  (e.g. stated in section 5.1.1) or CMS to Public Key only (Key Transport using RSA or Key Agreement using ECC) for CEK Distribution.
Therefore I would still propose the text in section 4 to something like this:

"For confidentiality protection of firmware images the author needs
      to be in possession of the certificate/public key or a pre-shared key of a device."





[Hannes] This is a good idea. I added the following text:
...

A.6.15.  Manifest Field: Key Table



   Encrypting firmware images requires symmetric content encryption keys

   to be provided in the manifest, which themselves have to be encrypted

   using the public keys of devices.


   Implements: Security Requirement MFSR7

[mg] What you describe is a good option, but not the only one. As stated above I would prefer not to limit it only to public keys and keep it more generic.
In addition the Heading 'Key Table' is also one option to do that, but not the only one.
Here is a proposal for more generic text, considering what you suggested as an example:

A.6.15.  Manifest Field: Content Key Distribution Method
Encrypting firmware images requires symmetric content encryption keys.
Since there are several methods to protect or distribute the symmetric content encryption keys, the manifest contains a field for the Content Key Distribution Method.
One examples for such a Content Key Distribution Method is the usage of Key Tables, pointing to content encryption keys, which themselves are encrypted using the public keys of devices.

Implements: Security Requirement MFSR7.

Would this be acceptable?
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.