Subject: [Cbor] To be signed with packed CBOR

From: Jim Schaad <[email-masked]>
Date: Sat, 1 Aug 2020 16:29:14 -0700

Brendan,

I know that this is currently an academic question, but something you said
in the SUIT meeting has me slightly worried.  The problem with being the
note taker is that you never have anytime to mentally go down the channels
of ideas that pop up.

One of the things that you said is that the use of packed CBOR would make
things better when there are multiple authentication structures on what is
basically the same data.  The problem is that if you do the packing prior to
doing the signature, then you end up in the situation where you need somehow
to also include the packing dictionary in the data that is being signed.  I
don't have enough knowledge of how the manifest works but if after a
signing, one can add more information to the manifest and then apply packing
to that section which could add more items to the packed lookup tables thus
breaking the signatures.  

All,

This is one of the reasons that I was asking questions about doing the
signature on a packed or unpacked version of the data.  The idea of adding
things which might alter the lookup tables at the root means that you have
problems knowing that what was signed is what is validated without doing
things like walking the content to extract a new pair of lookup tables to
include as part of the signed content.

Jim

---

From: Brendan Moran <[email-masked]>
Date: Mon, 3 Aug 2020 08:57:51 +0000

Hi Jim,

> On 2 Aug 2020, at 00:29, Jim Schaad <[email-masked]> wrote:
>
> Brendan,
>

I think we probably got our wires crossed here. There’s a few points to this:

1. SUIT is organised in such a way that one would probably pack the COSE objects and the non-COSE objects in separate, non-overlapping packed CBOR structures. This should mean that you do not require a signature over the dictionary for COSE packing.

2. With nested packed CBOR, we might need a way to specify whether the packer recursed into an already-packed object or not. That would bring us back to the situation in 1.

As a rule, I suspect we should assume that any dictionary should apply to either unauthenticated objects OR authenticated objects, but NEVER both. This will require us to distinguish between recursively packed (nested object contains references to enclosing object dictionary) and simply packed (nested object contains no references to enclosing object dictionary) objects. This may require a tag.

Brendan

> include as part of the signed content.

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.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Aug 2020 13:21:44 -0400

> include as part of the signed content.

Yes, I agree that this is a concern.
I really think one needs to sign the packed content.

The unpacking process seems like a place where exploitable bugs could
surface, so allowing an attacker to control that input seems imprudent.
Signing the packed content keeps attackers from being able to change things.
A manufacturer that became aware of a problem in some path of the unpack code
could avoid that kind of compression.

Bootloaders may be hard/inconvenient to upgrade outside of controlled environments.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Aug 2020 15:39:42 -0400

Brendan Moran <[email-masked]> wrote:
    > As a rule, I suspect we should assume that any dictionary should apply
    > to either unauthenticated objects OR authenticated objects, but NEVER
    > both.

Why?  I don't understand.
I think you are talking about external dictionaries, right?

I agree that one needs to be sure that any dictionary is securely identified.
A hash over the dictionary, included into the packed headers, and within the
COSE signature should be enough.

If another unauthenticated object wants to reference the same dictionary, how
can that hurt?

---

Now if we want to be able to form expandable dictionaries, maybe this won't
quite work.
I can imagine that it would be nice to have a dictionary that could be
expanded with new items placed at the end, while still being able to serve
older packed content.
What if one asked for a dictionary with X items, with hash Y?

    > This will require us to distinguish between recursively packed
    > (nested object contains references to enclosing object dictionary) and
    > simply packed (nested object contains no references to enclosing object
    > dictionary) objects. This may require a tag.

I think that I don't understand the origin of the attack you are concerned
about here.  Maybe some diagrams would help.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Aug 2020 00:24:50 +0200

> I really think one needs to sign the packed content.

Generally, we don’t sign the content (XMLDSig anyone?), but the message.  And that was packed.  (And the whole point about packed CBOR is that you may never need to fully unpack it.)

The signing input does not need to be limited to that.  So if there is an external context that provides, e.g., dictionary IDs, I would expect that to be part of the  signing input (where the “ID” needs to uniquely identify an immutable dictionary for a signature, either by hash, or by registry).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Aug 2020 15:30:39 -0400

> Generally, we don’t sign the content (XMLDSig anyone?), but the
    > message.  And that was packed.  (And the whole point about packed CBOR
    > is that you may never need to fully unpack it.)

So we are all in agreement.

    > The signing input does not need to be limited to that.  So if there is
    > an external context that provides, e.g., dictionary IDs, I would expect
    > that to be part of the  signing input (where the “ID” needs to uniquely
    > identify an immutable dictionary for a signature, either by hash, or by
    > registry).

We both agree that dictionary IDs (or hashes) have to be part of the signed
content.

But, are you saying that dictionaries used would be visible at the COSE
level, such as in the protected bucket?

I would think it's part of the signing input, because it's part of the "tag-6" structure.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Aug 2020 21:36:23 +0200

> I would think it's part of the signing input, because it's part of the "tag-6" structure.

It is conceivable that an application has pre-defined dictionaries (e.g., see RFC 3485).  You would never send these on the wire, possibly not even a hash.  So the signing input somehow needs to uniquely imply the context that makes you include that dictionary.

By the way, the order in the prefix/sharing tables is only relevant at the boundaries between 1-byte, 2-byte, and 3-byte references.  There will be very few 1-byte references (in the current proposal, 16 for sharing and 1 for prefix), so the packer should have control over what goes there.  It is getting a bit more relaxed after that.

Grüße, Carsten