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

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

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://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

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://capnproto.org/
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