Re: [Suit] self-describing format vs fixed/binary manifest structure - boot vs update

[Martin Pagel <[e-mail]>]

Frank, 
If I understand you correctly, you do support a packed binary encoding to keep boot process lean but not as an update manifest. I believe there is an advantage in using the same structure for both processes, in particular constrained devices with a hardware crypto accelerator. Both processes would benefit from lean implementation and shared code would further reduce implementation and testing efforts.

https://tools.ietf.org/html/draft-pagel-suit-manifest-00 proposes such structure. Yes, it does provide versioning to allow for future expandability. 

Again, I could see that a CBOR based manifest could be converted (and resigned) by the Update Server to generate such lean format and then made available for the device to update itself as well as for boot validation.
Martin

-----Original Message-----
From: Kvamtrø, Frank Audun <[e-mail]> 
Sent: Tuesday, December 18, 2018 8:58 AM
To: Martin Pagel <[e-mail]>; Carsten Bormann <[e-mail]>
Cc: Michael Richardson <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: [Suit] self-describing format vs fixed/binary manifest structure

I didn't have a specific e-mail to respond to with regards to the proposal for using packed C structs, but the discussion has gone on for quite a while and I don't believe it is very fruitful. I hear security experts have been mentioned in previous threads, and I want to point out that this is a logical fallacy called "argument from authority". If some security experts want to comment on this, then please add them to this discussions so we can discuss the issues first-hand. Or else the claims are difficult to argue against. 
The authors of this draft come from many different forums and I expect that the IETF SUIT working group is packed with security experts. A base tenet of this design process it to adhere to threat based analysis as well as using sane standardized methods of cryptography and security. Packed C structs raises a few flags for me, security wise. It is ad hoc, and I fail to see that this approach can be certified to be secure. Especially since the content will differ on many devices.

Please note that I don’t intend to be unnecessarily negative. I've used
18 of the 32 most known serialization formats (according to Wikipedia) myself.
I've even done the error of writing two proprietary serialization formats. 
The main reason for writing my own was either to be more efficient or to be more secure. I now know that I was mostly succeeding with the efficiency part.
For the most part I believe that we don't need another serialization format.

I don't think that packed C structs is a valid approach in an IETF standard. 
The formatting is not interoperable or interchangeable. I expect it to only work on one device with one configuration, which is asking too little from a firmware upgrade mechanism. I question the alleged security benefits that has been alluded to in previous e-mails when using packed structs. Simpler does not mean better, especially when you have to come up with a proprietary system for versioning to handle interchangeability, and a custom interoperability information format to ensure that the data isn't misrepresented or misused.

I want to note that I am not arguing against using multiple serialization formats in context of a complex firmware upgrade mechanisms. This may be the only way to support firmware upgrades for heterogenous systems that needs to be upgraded in unison. We have discussed this in previous e-mail threads covering payload encoding and NUMA/UMA architectures. I do take issue with an intent to describe manifest data using a non-serializing serialization format, without the exactness that I would expect when encoding and parsing data sent over any medium. That includes support for versioning and optional fields that can be skipped as well as a schema to understand how the data should look to be valid.

The method of having parts of the manifest data in a binary encoding instead of using the full IETF SUIT manifest format may make sense in context of a simplified boot validation. This is the case if you are reliant on an external security chip that only supports one format of data (e.g. ASN.1). A specialized boot validation process can even be encoded in a simpler manifest format than the full IETF SUIT, to keep the boot validation parser lean, and to ensure that there aren't any ways to hijack this sensible part of the process

> -----Original Message-----
> From: Suit <[e-mail]> On Behalf Of Martin Pagel
> Sent: 14. desember 2018 17:28
> To: Carsten Bormann <[e-mail]>
> Cc: Michael Richardson <[e-mail]>; [e-mail]; dev- 
> [e-mail]
> Subject: Re: [Suit] self-describing format vs fixed/binary manifest 
> structure
> 
> Different MCUs support and need different image formats, crypto 
> algorithms, keys, software components etc.  The Update Server already 
> needs to understand the capabilities and needs of the MCU it wants to 
> update, there is no generic way to update any type of MCU. The 
> question is how to transfer that MCU specific data to the MCU. Two approaches have been proposed:
> 1. The Update Server generates a CBOR representation to pack the data 
> and the MCU applies some type of CBOR parser to unpack it.
> 2. The Update Server generates a packed C struct the MCU can just 
> load/map into memory.

First I want to understand what an update server means is in this context. I don't see its role clearly stated in the draft documents. Maybe this is something that we need to be more explicit about in the architecture or in the information model. I feel you are mixing a concept of manifest data generation (with signing) and the role of hosting a firmware upgrade on a server. The key reason I believe this to be the case is that you state that the CBOR/packed C struct is server-generated. I think that this is not possible if you want to support the multiple signer requirements as described the information model use-cases, as well as the broad description inside the architecture draft.

There is a similar concept described in the architecture draft that has some clearer restrictions in usage. This is the "firmware server" concept, which is described as a server that holds the generated firmware images and manifests en route to the device where they are to be applied (either through push or pull).

The use of the term update server to describe encoding mechanisms begs the question on how to allow the device operator and the network operator to authorize a firmware upgrade in a combined signing operation. If support for multiple signers is needed, I assume the full firmware upgrade instructions is either a combination of multiple manifests that are individually signed or a manifest that has multiple signers. The key here is that the signed material can't be altered or else it loses the signers authorization. This makes an "update server" with generation capabilities difficult. Changing the content on an intermediate server breaks the concept of multiple authorities. 
Limiting the capabilities of the firmware server to pure device management tasks ensures good end-to-end security in the firmware upgrade process.

Using a well-defined serialization format is beneficial to a firmware server.
The firmware server can authenticate the content, e.g. by looking at "best before" combined with signature validation to ensure the addition is not part of a denial-of-service attack. It is also possible for the firmware server to decode information about the vendor, class and device ID to ensure the correct device gets the update (in a push scenario). This is data that is described in the IETF SUIT manifest format, and if this is serialized using a standardized format it becomes much more available for any intermediary actor in the overall firmware upgrade process.

Using a well-defined serialization format is also beneficial to multiple signers, as parts of the content of the full firmware upgrade can be dealt with remotely, protecting each signers private keys. It also has clear interoperability benefits, as you only need to follow the standard to create your part of the combined firmware upgrade instruction.

Using a packed C struct approach removes these flexibilities. In some cases it even demands an additional device management information outside of the scope of what is defined in the IETF SUIT to facilitate the firmware upgrade. 
This is a very bad thing for the standard. I don't think you can even call it a standard in that case...

> 
> Yes, the first approach might be a bit easier for the Update Server as 
> it doesn't have to worry about byte alignment etc, but I would rather 
> put the burden on the server rather than the MCU in particular if the 
> MCU needs this data to boot. As the Update Server already needs to 
> understand the target MCU, it might as well understand how to pack the 
> data in a way the MCU can easily digest. If I would have to develop a 
> tight boot ROM, I would favor the second approach.

I whole-heartedly don't favor the second approach. It has been mentioned before that here be dragons. Let me try to exemplify some dragons:

-What kind of endianness have you compiled your data to be in this build?
-What are the actual type sizes you are compiling with? Can they change?
-What about alignment issues on the packed types? Will you know when you got  that wrong in a graceful manner or will you just hard-fault on unaligned  access?
-How large are the enum types in your compilation? Should you disallow enums  outright due to potential interoperability issues?
-What happens when you need to amend this format to conform to an issue you  have discovered? 
-Is there a schema to conform to and how will you deal with optional features?

If these issues aren't addressed in the format of the data then usage could very easily lead to undefined behavior and potential crashes. There is a real risk of bricking a lot of devices if you get this wrong. And it can come with a change of the compiler/linker or by setting one faulty define in your build system. I believe the minor convenience of a RAM loaded RPC format is quite easily overshadowed by how restrictive you need to be to ensure that it doesn't lead to failures without any warnings.

All compatibility and interoperability issues can be avoided by using a real serialization format. For a list of alternatives, please look at the following link:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FComparison_of_data_serialization_formats&amp;data=02%7C01%7CMartin.Pagel%40microsoft.com%7Ced6b7c5a58b3435c261b08d6650a016c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636807490989019277&amp;sdata=qaBP7Rs3ky5I27UVV42xbYuoyaB9kCMgSa4ow0O45nQ%3D&amp;reserved=0

IETF SUIT has picked CBOR as the standard and I have no problem with that (TM).
Depending on the complexity of the manifest format, it is fairly easy to create a parser generator that uses the CDDL schema as input.

If you want a fast binary encoder then you could look at https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcapnproto.org%2F&amp;data=02%7C01%7CMartin.Pagel%40microsoft.com%7Ced6b7c5a58b3435c261b08d6650a016c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636807490989019277&amp;sdata=3kK467sWHhzm0sggw9M20gvAe7IjqcfTN7pspuK2AmA%3D&amp;reserved=0
It has all you need. Like many other binary formats, It has not gone through a full security review. But at least it addresses the interoperability and interchangeability aspects. It is eons better than a simple packed C struct. 
It even conforms to a schema, which is apt in case of having multiple versions or differences in supported features.

The rest of the e-mail has been skipped as it has some invalid formatting with regards to who says what.

With regards
Frank Audun