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

[Kvamtrø, Frank Audun <[e-mail]>]

Some comments and clarifications.

> -----Original Message-----
> From: Martin Pagel <[e-mail]>
> Sent: 20. desember 2018 02:37
> To: Kvamtrø, Frank Audun <[e-mail]>; 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 - boot vs update
> 
> 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.
> 

No, this is not at all what I was saying. I don't recommend a packed binary 
format. A packed binary format is a security risk in my opinion. Far 
outweighing the benefits. 


What I do argue is that in IETF SUIT manifests, binary encoding of data can 
be used to let IETF SUIT manifests be agnostic to some parts of the overall 
firmware upgrade process. IETF SUIT doesn't need to know *all* the details.
There is ample room to use the IETF SUIT manifest format to handle any data you
need during the firmware upgrade process in an agnostic way. You just need to 
utilize the payload concept to transmit the data to the device as if it is a 
binary blob. 
 
An example where this may be necessary if your secure boot ROM code requires a 
specialized format of the data to be parsed during the boot. Having multiple 
formats is not discouraged in the IETF SUIT manifest description. Some 
implementers might be required to use this approach. Especially if you need to 
couple multiple heterogenous Firmware upgrade mechanisms. There are Security 
chips available in the market today requires the use of ASN.1 encoded 
certificates, public keys, signatures etc. IETF SUIT can handle that. It only 
needs to pass the data forward as a binary blob and rely on external parsing.

If you look at modern schemes of doing secure architecture design in the 
embedded domain, like the GlobalPlatform or ARM Platform Security Architecture
(PSA), you will find that the ruleset of said standards will base the security
on the chip on specific rules of how to deal with for instance secure boot. 

What you will find is that the security is based on setting up a root-of-trust
by ab immutable first-stage bootloader. This immutable boot-stage is required
to be simple and to not contain any errors. You can't fix any errors in it
as it is intended to reside in e.g. OTP ROM or emulated OTP in FLASH. 
This process must set up the root-of-trust using a public key validation or 
MAC calculation. My interpretation of said standards is that the metadata 
needed to set up this root-of-trust should be done using a standardized, 
interchangeable format, if you have an intention of certifying your design 
and implementation according to secure engineering guidelines.

If the immutable first-stage bootloader is intended to be simple, then it 
begs the question of how complex the parser can be. I argue that you don't
need to support the whole IETF SUIT manifest format to facilitate the basic
operations of setting up an initial root-of-trust. The parser specific to this
operation can be quite limited. It doesn't need to support all the features
made available in the IETF SUIT, as the use-case of this parser should be
limited to basic operations needed for the boot. 
 
I think it is worthwhile to allow for a simplified IETF SUIT format
to handle the requirements of having an immutable first-stage bootloader.
This format could be a subset of the whole manifest, and should be
designed with its own use-cases isolated from the complete set of use-cases in 
the information model in the IETF SUIT. I think it is a bad idea to change the
encoding just because you think "this is too big". In my opinion this is due
to not looking at the real problem. The natural resolve of supporting a
standardized security architecture like GlobalPlatform or PSA requirements 
for an immutable first-stage bootloader is to have multiple parsers in 
your firmware upgrade mechanism. The size of the parser in the immutable 
bootloader can be scaled down quite extensively. I have also alluded to the 
special case when you can't use IETF SUIT manifest data, e.g. when you are  
using an external security chip expects something else for the initial
root-of-trust. IMO the resolve still stays the same - use multiple parsers 
according to the specific use-case.

The first stage bootloader should be designed to parse something simple, while 
the parser in subsequent boot stages (e.g. a background firmware upgrade 
mechanism in your main application) can be much more complex. This goes to the 
scalability of the IETF SUIT manifest format. We should be able to handle all 
potential requirements, even the very constrained limited on FLASH or RAM. On 
the most constrained devices there is a threshold between how much security and
how many features you are able to support. The problem of immutable boot vs
full featured IETF SUIT manifest is the same as the case of wanting to 
support a very constrained device. You have to cut features, which the 
CDDL allows you to do. An immutable boot is a tiny subsystem of the IETF
manifest format.

And for the record. I have worked on and am still working with constrained
devices. I have personally been part of making bootloaders and firmware
upgrade mechanisms for tiny MSP430s, Cortex-M0, and small footprint Cortex-M3 
and Cortex-M4 devices. An ASN.1 parser can be extremely small. The same would 
go for a CBOR formatted parser. ASN.1 and CBOR have the benefit of 
standardization, something that is alpha-omega when it comes to third-party 
certification. Standardization normally means that your serialization format 
and the implementations used to encode or parse it has gone through the proper 
security reviews to ensure the transmitted data isn't an attack surface.


With regards
Frank Audun Kvamtrø


> 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]; dev-
> [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.wikiped
> ia.org%2Fwiki%2FComparison_of_data_serialization_formats&amp;data=02%7C01%7C
> Martin.Pagel%40microsoft.com%7Ced6b7c5a58b3435c261b08d6650a016c%7C72f988bf86
> f141af91ab2d7cd011db47%7C1%7C1%7C636807490989019277&amp;sdata=qaBP7Rs3ky5I27
> UVV42xbYuoyaB9kCMgSa4ow0O45nQ%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%7Ced6b7c5a58b3435c261
> b08d6650a016c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63680749098901927
> 7&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