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

[Martin Pagel <[e-mail]>]

Thanks, Michael, 
for sharing your experience. 

In general I actually agree with your assessment. If you have many options, a well defined format like CBOR is much better than custom C structures as you can use a standard, already vetted parsing library. The standard parser library turns the CBOR data into a data structure, in IoT usually a pretty complex C structure. As the generic parser does not understand the semantics of the fields (only the syntax as defined by the CDDL), the developer still has to write code to verify a complex data structure and enforce semantics and you still have to test/verify such code. If you have lots of options, then again, that's a good approach. But, as others already pointed out, a manifest only uses a fraction of the power of CBOR and simple MCUs can only handle a fraction of the options proposed in the current Moran manifest draft. Each MCU still needs to make sure that any CBOR generated data structure is either properly processed or rejected, that is complex code which cannot be subjected to automated generic testing like the parser library can and therefore can lead to vulnerabilities. 

If you start with a binary manifest however, you skip the parsing step, you just load the data structure into memory. The data structure is much simpler as it only handles the few fields and options the MCU can actually handle. Yes, you need to do some more boundary checks on those few fields, something the CBOR parser might have done for you in the other case, but boundary checks on a simple data structure are pretty easy to implement. Far more important however is the fact that the code to enforce semantics is much smaller as it only has to deal with a few fields as your degree of freedom is far smaller.

If you want to use the manifest for secure boot via boot ROM, you want to make sure you get 100% code coverage during testing as you can't update the ROM. A generic parser often won't fit in the ROM and the number of options you would need to verify during testing becomes prohibitive. 

Therefore I believe that for constrained MCUs, in particular secure boot scenarios, a binary format has clear advantages. For larger, more flexible MCUs a CBOR based manifest may offer advantages.

Martin

-----Original Message-----
From: Suit <[e-mail]> On Behalf Of Michael Richardson
Sent: Wednesday, December 12, 2018 12:50 PM
To: [e-mail]; [e-mail]
Subject: Re: [Suit] self-describing format vs fixed/binary manifest structure


Martin Pagel <Martin.Pagel=[e-mail]> wrote:
> I had further discussions with some security experts about the two 
> different manifest drafts, I thought it would be useful to summarize 
> it for the work group:

I'm a security expert of 30+ years.

I've written both ASN.1 and CBOR parsers (more ASN.1 than CBOR thanks to widely available CBOR libraries), and dozens and dozens of custom format parsers for a large variety of 8-bit (back when that was "current"), 16-bit, and 32/64-bit architectures.  I've written them in C, assembler, perl (yes. bash even hardware via /dev/mem and unpack), Tcl, BASIC (PEEK/POKE), and this includes things like bespoke mailboxes and ring structures for things like ethernet and NPU devices. (Not just on the "OS"/Linux/BSD side, but on the "microcontroller" side too).

ASN.1 and CBOR are in completely opposite sides of the design space: anyone who is older than 50 desperately wishes we had CBOR back in 1984 (when ASN.1 was hatched my a committee).  The broken process that led to the design is a probably a major reason for why the IETF does things the way we do things.

I'm also one of the maintainers of tcpdump, and I've extensive experience with network attacks on custom C-written parsers for protocols.
(It's not pretty: even extensively reviewed code winds up with issues.
The google bounty program has had an interesting affect)

> A self-describing format such as CBOR obviously has the advantage that 
> it is more extensible.

No, this is not really the advantage of CBOR.
Many structures can be defined that are easily extensible.
The IETF has dozens of TLV structures (sadly different).

The advantage is that CBOR libraries can easily be tested against a wide variety of inputs on a machine that enforces NULL deferences, structure overflow and underflows, and where the develop/compile/test cycle can be measured in dozens of seconds rather than dozens of minutes.
These libraries are widely used and widely tested.

Pull parsers can be written that uses almost no storage at all (at the cost of cycles).  Our manifest should be a simple CBOR map, and if we put a constraint on how the keys are ordered then the pull parser could be implemented with almost no cycles at the cost of one pointer of storage.
Such a piece of code could be in a library and be widely used/tested, along side full CBOR parsers that map to Python/Ruby/Perl.

--
Michael Richardson <[e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-