Subject: [Suit] COSE_Sign vs. COSE_Mac

From: Russ Housley <[email-masked]>
Date: Mon, 4 Jun 2018 11:16:11 -0400

I am struggling to see a case where COSE_Mac provides acceptable protection.  With a MAC, the sender and the recipient must use the same key.  This means that any recipient can make a modification and produce a valid MAC for the modified object.

With a digital signature, the sender uses a private key, and the recipients use a public key, so the recipients cannot produce modified objects.

Why accept this possibility?

Russ

---

From: Brendan Moran <[email-masked]>
Date: Mon, 4 Jun 2018 15:24:01 +0000

This is a solution that is intended to address a segment of devices that cannot use public-key due to code size or processing overhead, and cannot use hash-based signatures due to data overhead. Provided that every device has a unique PSK, COSE_Mac provides adequate security. However, it introduces significant key management overhead.

Thanks,
Brendan

> On 4 Jun 2018, at 16:16, Russ Housley <[email-masked]> wrote:
>
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

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: Russ Housley <[email-masked]>
Date: Mon, 4 Jun 2018 11:52:19 -0400

Brendan:

That is a significant key management burden.  I would like to explore the assertion that hash-based signatures have too much data overhead.  Are you saying that they can buffer the firmware load, but not the signature value?

Russ

> On Jun 4, 2018, at 11:24 AM, Brendan Moran <[email-masked]> wrote:
>

---

From: Koen Zandberg <[email-masked]>
Date: Mon, 4 Jun 2018 17:59:41 +0200

Hi Russ,

My 2 cents for this scenario: the device I'm currently developing for
(samr21-xplained pro) takes around 8 seconds for ed25519 signature
verification (TweetNaCl implementation). An HMAC based verification
would be a lot faster here (saving me battery power). If you like I can
provide you some numbers on flash requirements for both HMAC and
public-key implementations.

Thanks,
Koen

---

From: Russ Housley <[email-masked]>
Date: Mon, 4 Jun 2018 15:50:59 -0400

Koen:

I was pushing back on the hash-based signature part of the statement from Brandan.  The hash-based signature algorithms use small private and public keys, and it has low computational cost; however, the signatures are quite large. Depending on the depth of the tree used by the signer, the computational cost will be a few times greater than HMAC, but it would eliminate the need to have a different file for each device.

Russ

> On Jun 4, 2018, at 11:59 AM, Koen Zandberg <[email-masked]> wrote:
> 
> Hi Russ,
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 4 Jun 2018 22:18:32 +0200

Hi Koen,

On 04/06/2018 17:59, Koen Zandberg wrote:

> verification (TweetNaCl implementation). 

Could this work be significantly flawed?

We've done the same Edwards curve on the same board with RIOT for 
SIGCOMM '15 and an ID-based authentication scheme: 3 sec verification, 1 
sec generation.

See https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p603.pdf

It could be much faster when optimized in assembly code.

Cheers,
  Thomas
-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                  Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group   20099 Hamburg, Germany °
° http://inet.haw-hamburg.de/members/schmidt      Fon: +49-40-42875-8452 °

---

From: Brendan Moran <[email-masked]>
Date: Tue, 5 Jun 2018 10:05:05 +0000

Hi Russ,
It depends on the size of the payload. When we’re talking about whole-image updates, it’s completely reasonable, however that won’t always be the case. If we have diff images, they can be quite small, depending on the scope of the change. A 2KiB signature on a 2KiB compressed diff may be a deal-breaker on low-bandwidth networks.

Brendan

> On 4 Jun 2018, at 17:52, Russ Housley <[email-masked]> wrote:
>
> Brendan:
>

---

From: Jim Schaad <[email-masked]>
Date: Tue, 5 Jun 2018 08:29:44 -0400

I would assume that the key management can be localized to the installation
That is the file can be signed from the manufacturer to the company and then
the PSK work can be done inside of the company.  Strip the COSE_Sign and
switch to COSE_Mac.  Given that one could have run a one time protocol to
derive the update PSK, I don't see that this is going to give a significant
loss of security.  The main issue is that one would need to scope the use of
PSKs to a small area with the SUIT manager doing the PSK computation

Jim

> -----Original Message-----
> From: Suit <[email-masked]> On Behalf Of Brendan Moran
> Sent: Monday, June 4, 2018 11:24 AM
> To: Russ Housley <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Suit] COSE_Sign vs. COSE_Mac
> 
> This is a solution that is intended to address a segment of devices that
cannot
> use public-key due to code size or processing overhead, and cannot use
> hash-based signatures due to data overhead. Provided that every device has
> a unique PSK, COSE_Mac provides adequate security. However, it introduces
> significant key management overhead.
> 
> Thanks,
> Brendan
> 
> > I am struggling to see a case where COSE_Mac provides acceptable
> protection.  With a MAC, the sender and the recipient must use the same
> key.  This means that any recipient can make a modification and produce a
> valid MAC for the modified object.
> >
> > With a digital signature, the sender uses a private key, and the
recipients
> use a public key, so the recipients cannot produce modified objects.
> >
> 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: David Brown <[email-masked]>
Date: Thu, 7 Jun 2018 10:05:49 -0600

>public-key implementations.

I think this more points out that there is a need for a better ed25519
implementation for this kind of scenario.  On my mcu (120Mhz Cortex
M7), TweetNaCl takes 1-2 seconds for a signature verification.  It is
nice because it is only about 3kb of code.  The other implementation I
have, from NaCl, takes on the order of 20-30ms for the same
verification.  However, it is about 130Kb of code, which makes it
unreasonable to use in many situations.

What would be nice to have would be something in between.  A little
bit larger code, but that runs faster than TweetNaCl.  There is a
https://munacl.cryptojedi.org/faq.shtml microNaCl library that tries
to do this.  However, it seems to be largely hand-written assembly,
and targeted to very specific mcus.

For this MCU, RSA code (using mbed TLS) is about 12Kb of code, and
takes 400-500ms to do the signature verification.  Gut feeling is that
Ed25519 could be implemented with similar code size and performance,
or slightly better.

I don't really have the depth of understanding needed to produce this
implementation, however, but maybe someone does.

David

---

From: David Brown <[email-masked]>
Date: Thu, 7 Jun 2018 10:07:26 -0600

>It could be much faster when optimized in assembly code.

I don't think assembly is really what is needed, but is more about
pre-computed tables and the algorithms used for the underlying EC
operations.

David

---

From: Derek Atkins <[email-masked]>
Date: Fri, 15 Jun 2018 11:04:42 -0400

Hi,

> unreasonable to use in many situations.

For the record, based on our experience on a Cortex M4 and Cortex R5, a
WalnutDSA signature verification would take you on the order of 5ms on
your M7 using only ~3kB of code.  (WalnutDSA is one of the NIST PQC
submissions).  The downside is that the signature is larger than ECC.

> implementation, however, but maybe someone does.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant