[Suit] Meeting Minutes - 21 June 2018

[Hannes Tschofenig <[e-mail]>]

Participants:

* Carsten Bormann
* Brendan Moran
* David Brown
 * Markus Gueller
 * Hannes Tschofenig
 * Frank Audun Kvamtrø
* Øyvind Rønningstad
* Michael Richardson

Notes:

Brendan goes through the current draft:
https://github.com/suit-wg/information-model/tree/v01

MFUS7: Brendan explained the use case for preventing devices from unpacking.

Frank & Øyvind:  Anything that can be done prior to starting the process is super convenient for implementations. We can foresee that some implementations will select only a few encoding methods, including some of the encryption mechanisms. If we can stop the downloading and the parsing by just parsing the format.

The question is only at what stage this should be enforced.

Brendan: This can be enforced at various stages. There will be a service component, a management system. If you go through a management system then that system should query the device for capabilities and it should ensure that it communicates that info to the system that provides the update. The device will have to again make the check. There would be a multi-stage process.

Frank & Øyvind:  In the resource information we have a way to change what the source is (based on the digest). Hence, you can use a local server rather than a cloud server. Could the negotiation be taken over by a third party?

Brendan: If you can fully trust a third party then I don't see a reason why not. Regarding the data structure I haven't thought about how and whether at all they would be impacted.
Has anyone looked at how a third party does the validation check? Nobody in the group has. Brendan speculates about the possible implications in terms of a new manifest or a manifest that is counter-signed. This assumes that public key crypto is used.

David: Do you have some examples where this

Frank & Øyvind:  It could be an external chip that does the decryption.

Brendan: Are we talking about one-device operations?

Brendan: One of the discussion that has come up are "primary and secondary" devices. This is where the storage identifier came from.

Hannes: We need to update the architecture document to explain the primary/secondary verification.

David: There are various deployment use cases today, which we could capture.

David brings up an example:
http://www.cypress.com/products/32-bit-arm-cortex-m4-psoc-6

In this case Flash and RAM is shared between the two processors. One processor is generic and the second processor is used for security functionality. For the update the security processor would be involved and it would write to memory to update the software of the application processor.

David agreed to produce a short write-up.

Note for MRSR7: Indicate what was done, indicate trust level or provability.

Brendan argues that it would be have a solution that just uses another manifest since it keeps the manifest parsing simpler.

Frank & Øyvind:  I see the possibility to offload payload processing to other systems so that the manifest does not really know what is being conveyed.

David: We are going to discuss the MCU Boot info

Brendan: The manifest contains information that is not necessarily needed by a bootloader.

David: The installation step is part of the bootloader:

1) Do I replace the old with the new firmware image?
2) Can I boot the new image?

Brendan: If it also does installation then it has to have more information

Frank & Øyvind:  I hope that the MCU Boot can be parsed in a simpler manner.

David: We want to mitigate complexity. The bootloader has to make the determination about  two images and it has to boot them together then it has to have more complex logic.
Do we extend our manifest or do we make MCU Boot understand the SUIT manifest?

David will post info about the conference call to the SUIT mailing list.

Frank & Øyvind:  As long as you can be agnostic about the payload then you can have a way to bridge into a different system.

Brendan: I think we will see bootloaders that understand SUIT but also those that do not understand them because the SUIT functionality is handled at a higher layer. In addition we will also see that bootloaders that will launch second stage bootloaders that are networking capable and understand manifests.

MFUR8:

Frank & Øyvind:  In our email we elaborated on this topic. We would cover this scenario with storage identifiers.

Brendan: This use case came from discussion at the Hackathon. Someone wanted to be able to replace versions A, B, and D but not version C. They wanted to target different types of devices but with a single manifest.

David: Do we know the bounds on the complexity of the rules (e.g., nested Boolean evaluation)?

Brendan: I am scared of the complexity. I prefer "match all" style comparisons only. It appears that this does not address all requirements. The approach that makes most sense is to add special conditions on a case-by-case basis.

Brendan: You ship 4 different device versions - A, B, C, and D.
Later you discover that there is a flaw on versions A, B, and D. You ship an update that applies to these three versions but you skip the update of version C. The idea was to provide a "match-any" list (in addition to the current "match-all" list).

Markus: We brought this functionality up. It came from our legacy versions and we have been trying to map this into SUIT. Previously the manifest didn't had a version identification at all. The only other possibility was to include a list of cryptographic hashes but this takes up some space in the manifest (depending on the number of devices). Another option would be a firmware version list. As Brendan said it could be a separate condition; alternatively it would be a proprietary vendor condition.

Brendan: The great thing about these conditions is that they don't cost you something if you don't want to use them.

Brendan: The question is whether all conditions are mandatory to implement.

Markus: I hope not

Brendan: Then, any condition that is not understood leads to an update failure.

David: That's also my understanding.

Michael: Whether all these conditions will be written by the manufacturer vs. written by operators. The manufacturer has to provide some description of what is being implemented.

David: This affects the previous use case. The processing engine needs to know what features are available in a later stage.

Brendan: This requires a capability negotiation with the bootloader.

David: The trust is still determined by the bootloader in our case. We don't trust the application.

Brendan: The application is trusted that the bootloader is capable of verifying the manifest.

Hannes: There are different trust models on who verifies the manifest. For example, one can image a case where an update service verifies the manifest and then lets the bootloader just jump to the received image vs. having the bootloader verify the manifest itself.

Carsten: We should be explicit about the threat model we use.

Brendan: We need to make this more explicit.
(It is essentially a question about where the 'ends' in the end-to-end security is. )

Frank & Øyvind:  We could have an array of all the versions that are supported then this would fit into the existing design. This would not be difficult to do. There are two different concepts here: First, the version concept. Second, there would be the new matching criteria. I believe you only need to support one of the two in order to satisfy the use case. Brendan, you have been looking into the match-any concept rather than the other one.

Brendan: I think it makes sense to use the existing conditions and then for any given condition that already exists then you can provide it with an array and then you can match any. This would be added to the existing type definition. I am concerned about the complexity.

Markus: We didn't want to create more manifest.

Brendan: I prefer a product of sums than an arbitrary complex Boolean condition.
I assume the complexity will be low in most cases.

Frank & Øyvind:  How about a separate condition that contains an array of conditions? (with the exception of not containing itself)

Brendan: If we got for a product of sum and all conditions contain lists then it would simplify the schema.

Frank & Øyvind:  I am fine with that.

Carsten: I think we can decide that later. We can for now have it as an array.

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.