[Suit] SUIT Conference Call Minutes - 14th June 2018

[Hannes Tschofenig <[e-mail]>]

Participants:
- Frank Audun Kvamtrø (Nordic Semiconductor)
- Øyvind Rønningstad (Nordic Semiconductor)
- Carsten Bormann (Uni Bremen TZI)
- Markus Gueller (Infineon)
- Brendan Moran (Arm)
- Hannes Tschofenig (Arm)
- Henk Birkholz (Fraunhofer)

Changes to the informational model have been discussed at the Hackathon and at the virtual interim meeting.

Brendan went through the document.

A question about protocol extensibility was raised by Carsten. This is something we need to look into.

Brendan states that a new security requirement (MFSR8) has been added about access control list.

Carsten: Are there any hooks that the manifest needs to provide? For example, do we need to provide names for the fields so that they can be referenced in the ACLs. The approach of explicit names for elements was discussed and also the approach of considering the path into the parse tree of the manifest. The latter was seen as a bit brittle.

Q: Which elements do you consider to be overrideable? URIs, conditions, and directives

Brendan: The ACL should say whether it is allowed to add or delete from that list.

Q about the signed payload descriptor (MFSR4): The idea with the list of elements documented in the draft is that they need to be signed. The conclusion is that they need to be placed into the manifest. The requirements need to be formatted so that the correlation between the implementation and the threat.

Suggestion to change the name of MFSR4 to Authenticated Resource Descriptor

MFSR5: Cryptographic Authenticity --> Needs to come before MFSR4.

MFSR7 (firmware encryption): The manifest information model must support encryption of firmware images.

Carsten: Is this only for the firmware image or also for other fields?  The expectation is that channel security is sufficient to protect the manifest content itself against information disclosure. Brendan will document it.

The difficulty with encrypted payloads is key distribution. Therefore the manifest must convey the information required to allow an intended recipient to decrypt an encrypted payload. The idea is that every device can receive an encrypted key that only that device can decrypt. Class keys are obviously possible too. Brendan talked about the key table structure. Not entire sure whether the information model is the right document to put this information in there.

Does the group think that the information model document should contain the key table concept for uniquely distributing content encryption keys to the device? The group discussed where the best place would be to place the information. No conclusion was made. Possible places are: information model, serialization document, or separate document.

Carsten: What do we sign and in what order (encrypted or unencrypted payload)?

Brendan says that it might be best to have the signature cover the installed image. The payload description should specify what appears on the payload after all the processing has happened. The raw payload digest refers to the state before any decryption has happened.

Frank mentioned that they shared an email about the post condition idea. Here is the email:
https://www.ietf.org/mail-archive/web/suit/current/msg00467.html

The pre-conditions need to hold before the update is started and the post-conditions need to hold when the update is applied.

Discussions didn't not consider the sign after encryption vs. encryption after sign case but rather about what is being signed.

Hannes points out that there are security implications of the order.
Brendan mentions that there are denial of service.

Brendan can see the benefits of the proposed format for post- and pre-conditions. How well does this format deals with nested containers isn't clear to him though? Does this support "Use Case MFUS7: Prevent Devices from Unpacking Unknown Formats"?

Brendan thinks there should be a list of processing steps the device has to take. Brendan argues for the ability to determine as quickly as possible what the processing steps are.

... quite a long discussion about the different alternatives ...

A tentative conclusion, which needs to be described to the group on the mailing list is: We will use out-of-band containers (to put a nil in the cose structure; when it is nil the meaning is that the protected content is somewhere else). The manifest would follow immediately afterwards. If you follow this approach for them manifest then the rest is an application specific decision.  The processing steps list will be something that can be transmitted separately. The goal is to make the manifest parsing friendly to nested and non-nested structures.

Since we ran out of time we were thinking about having another conference call next week.

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.