Subject: [Ace] Group Communication Security Disagreements

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Jul 2016 11:04:50 +0200

Hi all,

this is an attempt to summarize the discussions around the group
communication security topic from the ACE meeting yesterday. Please
correct me if I am wrong.

The concern is the following: How can we ensure that a compromised
IoT device, which is part of a multicast group, is unable to trigger
actions at other nodes?

The underlying assumption is that one can use the obtained group key
to then trigger actions that such a device would normally not be able
to do.

Here is an example: Imagine a luminare A that belongs to a group that
consists of a light switch and other luminaires. Luminare A gets
compromised and is not able to issue on/off commands to other luminaires
in that group. Normally, only the light switch would issue such commands.

The story then continues that such a compromised luminare would then
also be able to issue commands to a door lock.

So far, so good. Here is the disagreement.

Some folks in the group believe that in order to disallow a compromised
luminare to have such a functionality we need to introduce source
authentication. So, instead of using symmetric group keys we would be
using digital signatures and the luminaires in our example would then
verify whether the command came from a light switch.

Some other folks, including myself, believe that we would not just
use the group key to determine the authorization decision but would
instead rely on the authorization mechanism to prevent larger harm.
This means that a compromised luminare would indeed turn on and off
other luminaires in the group but they would not be able to successfully
send commands to a door lock since those would (a) not use group
communication and (b) if they use group communication then that would
require an interaction with the authorization server to first obtain a
different group key for such an interaction. Most likely there is no
need for a luminare to obtain a group key for communicating with a door
lock.

As a way forward it was suggested to explore the use of digital
signatures and to make use of some of the more recent developments done
in the CFRG. So, if a researcher has free cycles please contribute your
thoughts on this subject. What we would like to know is the following:

* How large would a message be when we use some command (like a CoAP
packet) with an application layer digital signature (e.g., using COSE)
using ECC? We are particularly interested in the verification operation.

* What is the performance impact on processors in the M-class category?

* What are the implications for power consumption?

Here is my initial impression regarding the second aspect from a
performance analysis I ran on an LPC1768. It took 458 msec to do a
verify computation with optimization enabled* for a secp256r1 curve.
The LPC 1768 demo board uses a ARM Cortex-M3 CPU running at 96MHz.

I also did a performance test with the STM DISCO-F746NG, which uses
a Cortex-M7 CPU running at 216 MHz. For the ECDSA secp256r1 verify
operation it took 10, 205 msec.

No hardware speedup or assembly optimizations were used in these tests.

I believe we would need something that accomplishes the verify operation
in about 150 msec to meet the delay budget we have since the verify
operation is not the only processing task.

Ciao
Hannes

*: Optimizations in this case means:

- NIST Optimization
Utilizes special structure of NIST chosen curves. Appendix 1 of
http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf
Longer version in FIPS PUB 186-4:
http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf

- Fixed Point Optimization:
Pre-computes points, as described in https://eprint.iacr.org/2004/342.pdf

- Window:
Technique for more efficient exponentiation
Sliding window technique described in
https://en.wikipedia.org/wiki/Exponentiation_by_squaring

---

From: Rene Struik <[email-masked]>
Date: Thu, 21 Jul 2016 09:37:13 -0400

Hi Hannes:

In addition to the optimizations you mentioned, one could also use the 
acceleration technique for ECDSA signature verification described in 
[1], which results in roughly 40% speed-ups compared to plain vanilla 
approaches. Larger speed-ups are possible if one stores a few multiples 
of the signer's public key. For details, see the SAC 2005 paper.

With your experiments (STM DISCO-F746NG using a Cortex-M7 CPU @216 MHz), 
you reported 205ms timing for ECDSA verify with the NIST P-256 curve. 
Using the techniques of [1], one can potentially reduce the 
computational time latency by roughly a factor 1.4x, from 205 ms to 
146ms (i.e., just under your suggested 150ms  time "budget"). Precise 
speed-ups are somewhat implementation platform dependent, but can be 
expected to be in the same ballpark.

Similar speed-ups can be realized using the recent CFRG curves and 
EdDSA, since they all satisfy the conditions under which these tricks 
work. Since Edwards curves have slightly faster addition formulae, one 
can combine niftier curves + accelerated verification methods to reduce 
time latencies (I guesstimate this to allow approximately 120ms time 
latencies  on your Cortex-M7 platform above [real-life data points 
should be established via an implementation on your platform]).

The above suggests that computational time latency may not be a 
show-stopper for using signatures.

Best regards, Rene

[1] A. Antipa, D.R. Brown, R. Gallant, R. Lambert, R. Struik, S.A. 
Vanstone,

“Accelerated Verification of ECDSA Signatures,”

in /Proceedings of Selected Areas of Cryptography – SAC 2005/,

B. Preneel, S. Tavares, Eds., Lecture Notes in Computer Science, Vol. 
3897, pp. 307-318,

Berlin: Springer, 2006. Available from 
http://cacr.uwaterloo.ca/techreports/2005/cacr2005-28.pdf

On 7/21/2016 5:04 AM, Hannes Tschofenig wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Michael StJohns <[email-masked]>
Date: Thu, 21 Jul 2016 09:48:13 -0400

> need for a luminare to obtain a group key for communicating with a door

Hi Hannes -

If the protocol were constrained to a small number of group members - 
say 16 for example - then solving this problem is as simple as sending a 
control message with multiple message integrity tags - one per target 
device.  In the lighting problem, you could probably make this work with 
about a 3 byte overhead per device for a total of 48 MIC bytes (4 bits 
for EP identifier, 20 bits for the MIC) and still have reasonable 
security.   And all without having to have a group key.

If you go larger than this, then the group key becomes more attractive, 
but also less secure.   The probability of compromise of the group - if 
its an interesting target - approaches unity assuming physical access to 
any device in the group.

Without unique source identification (and for that matter role 
identification either inband or implicit) any compromised device results 
in your attacker being able to act as a controller for the group.  
Again, not a large problem (but a problem nonetheless) for a small group 
of lights inside an office behind locked doors. But a very large problem 
for a system that's possibly controlling 100 or 1000 lights in a group.

As I said at the microphone, if I thought you could just do this as the 
"ACE protocol for group control of lights" and keep people from using it 
for other things I'd be a lot less concerned (but still there's the 
whole threat of turning off all the lights in a building all at once).  
But the reality is this protocol will be used for control of things 
beyond lights and it would be irresponsible to standardize a protocol 
with a real possibility for direct real-world negative impacts on safety 
and health.

The way to solve this for a general involves public key cryptography - 
that's just how the security and physics and math work out.

Mike

ps - the idea of secure group multicast for controlling things is indeed 
a  wonderful idea - but think for a moment.   If it's such a great idea, 
why isn't it already in use somewhere?

MSEC did quite a lot of work on providing confidentiality for 
multicasted messages, but the work it did on integrity/authentication 
produced only a document that allowed you to authenticate the sender 
after the event was supposed to occur. (E.g. TESLA) That's probably not 
useful for controlling things in real time.

Given the amount of work that was done there, and in various academic 
settings and with a large number of people and with money and with 
impetus to make this work on symmetric key systems, why will ACE be more 
successful?  What has changed in our understanding of the problem and 
the solutions set?

---

From: Derek Atkins <[email-masked]>
Date: Mon, 25 Jul 2016 10:17:38 -0400

Hannes,

> operation it took 10, 205 msec.

Is this Ten Thousand Two Hundred Five msec (e.g. 10+ seconds)?  Or is
this Ten decimal Two Hundred Five msec?

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Jul 2016 16:23:39 +0200

This is copy-and-past error. Sorry!

The correct wording is: "For the ECDSA secp256r1 verify
operation it took 205 msec on a Cortex-M7 running at 216 MHz."

Ciao
Hannes

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Jul 2016 17:12:44 +0200

On 7/21/16 3:48 PM, Michael StJohns wrote:
> identification either inband or implicit) any compromised device
> results in your attacker being able to act as a controller for the
> group.  Again, not a large problem (but a problem nonetheless) for a
> small group of lights inside an office behind locked doors. But a very
> large problem for a system that's possibly controlling 100 or 1000
> lights in a group.

+1, and I'm not even sure if it's not a problem for a small group of
lights behind locked doors if wireless is involved.

>
> As I said at the microphone, if I thought you could just do this as
> the "ACE protocol for group control of lights" and keep people from
> using it for other things I'd be a lot less concerned (but still
> there's the whole threat of turning off all the lights in a building
> all at once).  But the reality is this protocol will be used for
> control of things beyond lights and it would be irresponsible to
> standardize a protocol with a real possibility for direct real-world
> negative impacts on safety and health.
>

Yes, but I would go further and say that network owners ask two questions:

 1. What is this Thing?
 2. And what access does it require/not want?

Absent device identity they cannot answer the 2nd question.  This is as
important for lighting as for any other application, because it is how a
network will distinguish what those applications are.

> that's just how the security and physics and math work out.

Yes.  And as I believe has also been discussed, use of PSK seems to
cause us to muddle the authentication and authorization aspects of
OAUTH, for instance.

Eliot

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Jul 2016 17:47:12 +0200

Hi Eliot,

a quick response.

> lights behind locked doors if wireless is involved.

In order for the attack to work a luminary and a door lock need to be in
the same group and share the same group key.

For me the question is (from an authorization point of view) why the
door lock as well as a luminary belong to the same group. Would a door
lock participate in a group communication interaction altogether?

> network will distinguish what those applications are.

In ACE we don't care what the network does. This is outside the scope of
the charter, intentionally. The identifier for the device is what the
device uses to authenticate itself to the authorization server in our
setup. We don't call this "device identity" though.

The authorization server is, as the name indicates, about storing
authorization decisions typically provided by some human. This human
could be a user in a home network or could as well an administrator in
an enterprise network. We don't care that much. Call it policy.

> cause us to muddle the authentication and authorization aspects of

I am not sure this is a fair summary of the work in OAuth. OAuth 2.0 as
used today on the Web and in smart phone applications with bearer tokens
makes heavy use of public key cryptography. It just has to work in a
fragile environment -- the Web.

Ciao
Hannes

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Jul 2016 18:29:36 +0200

Hi Hannes,

On 7/25/16 5:47 PM, Hannes Tschofenig wrote:
> lock participate in a group communication interaction altogether?a

I agree in part (the part that if you have a clean separation of
authorization and authentication it *should* be possible to authorize
specific devices into a group and then determine which specific device
is misbehaving).  Also see Mike St. John's email, and I had thought what
you were asking about is what sort of transitive trust is granted.

> setup. We don't call this "device identity" though.

Point taken, but even so, this isn't a matter of what the network does,
but how the device identifies itself to other devices, including network
devices.

> an enterprise network. We don't care that much. Call it policy.

Ok.

> fragile environment -- the Web.

Use: yes as a means to authenticate transactions.  Not as authorization
itself.

Eliot

---

From: Mohit Sethi <[email-masked]>
Date: Mon, 25 Jul 2016 12:36:17 -0400

Hi

A quick comment. Developers often end up using 
things/protocols/technologies which were not 
designed/developed/specified for their use-case. I could definitely see 
some IoT startup building a solution that switches on the lights in a 
room as soon as you unlock the door (thus keeping them in the same group).

Thanks
/--Mohit

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Jul 2016 19:06:07 +0200

Hi Mohit,

there are always things that can go wrong.

I have not seen a solution where nothing can go wrong.

Even not standardizing anything isn't a preventing companies, or
developers designing their own solutions. We know how well that works.

Ciao
Hannes

---

From: Mohit Sethi <[email-masked]>
Date: Mon, 25 Jul 2016 13:09:33 -0400

I Agree.

Thanks
/--Mohit

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Jul 2016 13:58:23 -0400

Mohit Sethi <[email-masked]> wrote:
    > designed/developed/specified for their use-case. I could definitely
    > see some IoT startup building a solution that switches on the lights
    > in a room as soon as you unlock the door (thus keeping them in the
    > same group).

Or perhaps more usefully, turning the lights (and the oven) off when you
leave the house.

(How long did it take to get automobiles that turned the headlights off when the key
was removed?)

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 27 Jul 2016 15:01:25 -0400

> Or perhaps more usefully, turning the lights (and the oven) off when you

Good points, but you could do this without them being in the same
group with some controller that managed the interactions with each.
This would be a good set of examples for the security considerations
sections, providing guidance to use a controller rather than group
keys to perform useful functions like these.

Kathleen

-- 

Best regards,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Jul 2016 17:56:35 -0400

> keys to perform useful functions like these.

I agree.
Perhaps we could convince Mike St.Johns to write that section?

And ACE has the right mechanisms to make this work well.

We've had a thread now on performance of asymmetrical crypto, and it seems
that controllers ought to be able to talk to other controllers quickly enough
to make this workable.

We should also consider whether we can use hash-chains, like S/KEY did, to
authenticate messages that should only go out in emergencies.  Such messages
would clearly *need* to be multicast, but once used, they can never be
reused.  They can't be originated by more than one sender though.... so it's
really the message stored by the "EMERGENCY STOP" button.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 27 Jul 2016 19:21:24 -0400

> Perhaps we could convince Mike St.Johns to write that section?
Probably not - as long as symmetric key group communications is used as 
a control protocol.

> And ACE has the right mechanisms to make this work well.
I agree - public key systems.  But that seems to be out of scope here.

> really the message stored by the "EMERGENCY STOP" button.

That's an interesting idea - but AIRC, hash chains could be originated 
by anyone that held the signing/verification key.

Again - if you don't touch the physical world, I'm pretty much not 
worried about how screwed up the protocol is.  But you touch the 
physical world.

Let's do this the right way.  Let's not bow to the "tyranny of the light 
switch" in accepting solutions that are NOT secure, even for the limited 
scope they are proposing.

Later, Mike

---

From: "Grunwald, Markus" <[email-masked]>
Date: Thu, 28 Jul 2016 15:14:25 +0200

Hello,

Let's do this the right way.  Let's not bow to the "tyranny of the light switch" in accepting solutions that are NOT secure, even for the limited scope they are proposing.

Later, Mike

If this is a bait, I’ll bite ;)

I think everybody already agreed that private/public key encryption is the way for a bullet proofed group communication. But there are other questions:

-        Does it have to be bullet proofed?

-        How are applications handled that are not able to provide private/public key encryption?

I may (most possibly) have missed something, but the only answer that you seem to accept is “public key encryption”, period. Then let me ask directly: how should systems that have to reply in a tight margin be handled? People will simply not buy a lighting solution where the light will switch on 500ms after you pressed the switch. They will lough at this “solution”.

So, throw more hardware at it? For light switches that cost €100, adding a crypto chip for ¢50 might not be a problem. But there are parts like ECG where ¢2 matter. One of them will be in every luminaire…

This means, there are systems that cannot afford to provide public key encryption. Do you want an IoT without light? Let’s not bow to the “discrimination of the light switch”, at least not for the parking house/ parking lot. An Airport is a different beast.

Mit freundlichen Grüßen

Markus Grunwald
Development Engineer

OSRAM GmbH
DS D LMS-COM DE-1
Parkring 33
85748 Garching, Deutschland
Tel. +49 89 6213-3678
mailto:[email-masked]
www.osram.com

Bitte prüfen Sie der Umwelt zuliebe, ob der Ausdruck dieser Mail erforderlich ist!

OSRAM GmbH: Vorsitzender des Aufsichtsrates: Peter Bauer; Geschäftsführung: Dr. Olaf Berlien (Vorsitzender), Dr. Stefan Kampmann;
Sitz der Gesellschaft: München; Registergericht: München, HRB 201526; WEEE-Reg.-Nr. DE 71568000

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Jul 2016 10:02:29 -0400

>> keys to perform useful functions like these.

    mcr> I agree.
    mcr> Perhaps we could convince Mike St.Johns to write that section?

    msj> Probably not - as long as symmetric key group communications is used
    msj> as a control protocol.

Well, who other than Nixon could go to China?

    mcr> And ACE has the right mechanisms to make this work well.

    msj> I agree - public key systems. But that seems to be out of scope here.

I'm not convinced.  What I have taken home is that people think they want to
use symmetric keys, and perhaps it might be safe among completely equivalent
devices. I take your point (strongly) that this bubble will be broken, with
catastrophic results.  We need asymmetric methods between bubbles, and we
need to define that early.

    mcr> We should also consider whether we can use hash-chains, like S/KEY did, to
    mcr> authenticate messages that should only go out in emergencies.  Such messages
    mcr> would clearly *need* to be multicast, but once used, they can never be
    mcr> reused.  They can't be originated by more than one sender though.... so it's
    mcr> really the message stored by the "EMERGENCY STOP" button.

    msj> That's an interesting idea - but AIRC, hash chains could be originated
    msj> by anyone that held the signing/verification key.

Yes, provided they distributed the initial (asymmetrically signed) h^n(k)
value out in advance, and gave all the devices enough time to verify that
signature.  Plus flash to store the n-th hash.

For the single sender/controller, multiple receiver/actuator situation this
would be almost as fast as the symmetric group key, yet much more secure.

For the multiple sender situation, you need to replicate things n-times.
But it's still not n*m keys.

    msj> Let's do this the right way. Let's not bow to the "tyranny of the
    msj> light switch" in accepting solutions that are NOT secure, even for the
    msj> limited scope they are proposing.

+1.

---

From: Paul Duffy <[email-masked]>
Date: Thu, 28 Jul 2016 10:31:05 -0400

+1

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Jul 2016 17:07:39 +0200

>> need to define that early.

But enterprise managers will still want to identify sources of
infection.  If messages aren't signed that must come from lower layers
in as secure fashion as the manager requires (that will probably depend
on media).

Eliot

---

From: Derek Atkins <[email-masked]>
Date: Thu, 28 Jul 2016 11:30:35 -0400

Hi,

"Grunwald, Markus" <[email-masked]> writes:

> I may (most possibly) have missed something, but the only answer that you seem
> to accept is “public key encryption”, period. Then let me ask directly: how
> should systems that have to reply in a tight margin be handled? People will
> simply not buy a lighting solution where the light will switch on 500ms after
> you pressed the switch. They will lough at this “solution”.

True, but there are other public-key games in town.

> So, throw more hardware at it? For light switches that cost €100, adding a
> crypto chip for ¢50 might not be a problem. But there are parts like ECG where
> ¢2 matter. One of them will be in every luminaire…

Indeed.  Cost is an important characteristic.  On the other hand it's
definitely not going to come for free.  So where is the cost/benefit
curve cross over?

> This means, there are systems that cannot afford to provide public key
> encryption. Do you want an IoT without light? Let’s not bow to the
> “discrimination of the light switch”, at least not for the parking house/
> parking lot. An Airport is a different beast.

For the record, I've been working on a group theoretic public-key
signature scheme that's looking very promising.  It's designed to run
extremely efficiently in these extremely constrained devices.  In our
tests so far signature verification is 1-2 orders of magnitude faster
than ECDSA verification, and runs extremely well in 8, 16, and 32-bit
environments.  For example, on an ARM Cortex-M3 the verification runs in
under 10ms.  (I believe Hannes was reporting 200-400ms for ECDSA
verification).  Something to keep in mind when thinking about how hard
it is to work with public key signature verification on these devices.

-derek