Subject: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 20 Jul 2016 12:07:21 +0200

Hi all,

at the ACE meeting today I asked the participants whether they are in
favor of adding low latency group communication security work in the ACE
group.

20 persons were in favor of doing the work.

5 people argued against doing this work.

If you haven't been at the meeting please contribute your thoughts here
on the list. If you believe you do not have enough information please
also speak up.

Ciao
Hannes

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 20 Jul 2016 14:47:50 +0000

Agree with the direction toward group communication. This roughly aligns
with goals of 
<https://datatracker.ietf.org/doc/draft-hardjono-ace-fluffy/> which is
inclusive of group key management for symmetric. Fluffy has broader key
management goals, but symmetric group key management is a great place to
start. 

It also aligns with directions the OCF are heading as they see value in
the use of group keys for doing secure discovery.

Ned Smith
Principal IoT Security Architect
Intel SSG-OTC
[email-masked]
+1.503.712.3695

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 20 Jul 2016 15:00:05 +0000

>favor of adding low latency group communication security work in the
>ACE group.

+1.

>on the list. If you believe you do not have enough information please

My extra input is that whatever is done should also try to enhance the security functionality of CoAP Group Communication [RFC 7390] as described in:

https://tools.ietf.org/html/rfc7390#section-5

Best Regards,

Akbar

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Smith, Ned
Sent: Wednesday, July 20, 2016 10:48 AM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

Agree with the direction toward group communication. This roughly aligns with goals of <https://datatracker.ietf.org/doc/draft-hardjono-ace-fluffy/> which is inclusive of group key management for symmetric. Fluffy has broader key management goals, but symmetric group key management is a great place to start.

It also aligns with directions the OCF are heading as they see value in the use of group keys for doing secure discovery.

Ned Smith

On 7/20/16, 3:07 AM, "Hannes Tschofenig" <[email-masked]> wrote:

>favor of adding low latency group communication security work in the
>ACE group.
>

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Wed, 20 Jul 2016 19:32:15 +0000

+1 in favor of doing the work in ACE. There is a clear need in the lighting industry (but also others like window blinds) where low latency (human noticeable delay of around 200 ms) needs to be protected with an appropriate type of security. There are differences in opinion what current or near future hardware can support and we need to get more clarity on that (not just from one single vendor).

Sandeep

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, July 20, 2016 12:07 PM
To: [email-masked]
Subject: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

Hi all,

at the ACE meeting today I asked the participants whether they are in favor of adding low latency group communication security work in the ACE group.

If you haven't been at the meeting please contribute your thoughts here on the list. If you believe you do not have enough information please also speak up.

Ciao
Hannes

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 20 Jul 2016 22:05:54 +0000

Generally I'm in support of any efforts to secure multicast messaging for IoT 
applications However, I have some concerns about the ACE WG:

(a) Mixing authorization with key management: authorization and key-management 
are separate functions, so they need separate specs.

(b) Application-independent key management: a good key management protocol 
should be deployable for a reasonably broad set of applications area 
(including Consumer IoT and Industrial IoT).

So while its useful to have a solution for lighting application, it remains to 
be seen if the solution works for other applications.

(c) ACE WG work-pace:  The ACE use-cases document took over a year to finish, 
with numerous argumentative & boring emails (I'm not going to name names). 
Sigh. If it takes over 1 year just to agree on use-cases, I can't imagine how 
long it will take to complete an IoT secure multicast key management protocol. 
Double sigh.

(d) Reinventing stuff:  The IETF did have a secure multicast WG that produced 
a lot of drafts and some RFCs, notably RFC 3740 and RFC3547 (RFC6407). There's 
product out there implementing these already.

There's also a draft in DICE on multicast for DTLS (not sure what happened to 
it).

There is the Fluffy draft, but so far the ACE WG has not been very interested 
in it.

(e) Re-chartering:  Will the ACE WG need rechartering and how long.

/thomas/

------------------------------------------

>>> Sent: Wednesday, July 20, 2016 6:07 AM
>>> To: [email-masked]
>>> Subject: [Ace] Adoption of Low Latency Group Communication Security Work 
>>> in
>>> ACE
>>>
>>> Hi all,
>>>
>>> favor
>>> of adding low latency group communication security work in the ACE group.
>>>
>>> If you haven't been at the meeting please contribute your thoughts here on
>>> the list. If you believe you do not have enough information please also
>>> speak up.
>>>
>>> Ciao
>>> Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Jul 2016 00:30:17 +0200

Hi Thomas,

thanks for the response.

> are separate functions, so they need separate specs.

This is probably a document management aspect and from a protocol point
of view there are indeed certain areas where authorization can separated
from the key distribution.

For example, separating the aspect where permissions are granted to
access a specific resource are separately from key distribution.

> be seen if the solution works for other applications.

We have been looking at other application domains outside lighting as
well but so far what we have are several companies interested from the
lighting community asking for a specification. If there are other use
cases as well then I am sure the group is interested to hear about them.

> long it will take to complete an IoT secure multicast key management protocol. 

Yes, that's indeed a fair concern. I am also worried about the speed.

> product out there implementing these already.

Re-using work sounds useful.

> There's also a draft in DICE on multicast for DTLS (not sure what happened to 

The DTLS multipath was discontinued. Instead, the current approach is to
work on an application layer layer multicast security solution.

> There is the Fluffy draft, but so far the ACE WG has not been very interested 

The group decided to go for an OAuth-based approach in ACE but there are
certainly multicast security aspects in the Fluffy draft that should be
explored IMHO.

> (e) Re-chartering:  Will the ACE WG need rechartering and how long.

The ACE group needs to be re-chartered to work on low latency group
communication security. Whether this happens at all depends on the
outcome of this discussion.

Ciao
Hannes

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jul 2016 05:04:17 -0400

Why will ACE succeed when DICE failed?
Does ACE now have some knowledge or mechanism that DICE couldn't have created
because it was out of scope?

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Jul 2016 11:26:49 +0200

> Why will ACE succeed when DICE failed?

Because DICE tried to hack something into TLS.  That had no support.

> because it was out of scope?

ACE has COSE.

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 21 Jul 2016 11:29:41 +0200

> because it was out of scope?

ACE is (also) about authorization, which DICE wasn't. A compromised 
lightbulb might well have the possibility to talk to a door lock (using 
it's group key), but it would lack the authorization to do anything with 
the lock.

IMHO that's what ACE add that DICE didn't have (and wasn't chartered to 
have).

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jul 2016 06:19:20 -0400

> ACE has COSE.

Good answer, and I agree. I just want to be sure that we understand how not
to rathole.

---

From: Michael StJohns <[email-masked]>
Date: Thu, 21 Jul 2016 08:49:00 -0400

On 7/21/2016 5:29 AM, Ludwig Seitz wrote:
> lightbulb might well have the possibility to talk to a door lock 
> (using it's group key), but it would lack the authorization to do 
> anything with the lock.
>
> IMHO that's what ACE add that DICE didn't have (and wasn't chartered 
> to have).

Hi Ludwig -

Sorry - you are incorrect.

The group key is also the authorization key in the model proposed. Any 
entity that holds that key can forge a message that can cause the action 
authorized by the issuance of that key. In your example, assuming that 
the door lock and the lightbulb share the same group key, then 
compromising the lightbulb allows you to control the door lock.

In general, authentication comes with the key that you have - 
authorization is then tied to that key.  In DTLS  (as in TLS), your 
session key is also your authorization key once your TLS session is tied 
to a particular identity (e.g. via an HTTP login, via a client cert 
exchange, via OAuth).

So - cosmetic differences only.

Mike

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Jul 2016 14:55:45 +0200

Hi Hannes,

+1.

> cases as well then I am sure the group is interested to hear about them.

Somebody has to be first.  Others should step forward.

> Yes, that's indeed a fair concern. I am also worried about the speed.

Yes, but this is not a reason to not adopt a document.  It's a reason to
have editors and chairs who can move the ball.  What is a reason is the
above and below.
> outcome of this discussion.
Fair.

Eliot

---

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

> Because DICE tried to hack something into TLS.  That had no support.

Actually, that's not the complete story.  It was one of the things that 
finally killed this off (e.g. DICE was supposed to make a profile of 
DTLS for constrained devices, BUT DTLS didn't already support multicast, 
so its difficult to profile it in...; we have to come up with message 
formats for a DTLS extension)

It wasn't the only thing.  Again, there's a very long record of why this 
was a bad idea in DICE.  It's trivially easy to map each and every one 
of those arguments to why the equivalent thing in ACE is bad.

>> because it was out of scope?

*sigh* If this had any application to the stated lighting problem, then 
sending a COSE message with a public key signed payload to trigger state 
changes would be the solution, not a symmetric group multicast key.

E.g. use section 4 of the 
https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ document.  Do NOT 
use any of the symmetric key sections.

  I've said similar things before, but there continues to be this belief 
from certain folk that its too expensive to do public key cryptography 
for lightbulbs.

So to be clear - yes COSE is useful.  No, it does not actually do 
anything to fix the problem of symmetric key group communications UNLESS 
you stick to the public key sections.

Later, Mike

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 21 Jul 2016 16:39:05 +0200

> compromising the lightbulb allows you to control the door lock.

That is certainly not the model I had in mind. Why on earth would a sane 
Authorization Server issue OAuth access tokens that authorize operations 
on the door-locks and that are bound to the lightbulb-group key?

The way I see this play out is this: In the low latency cases, with low 
security requirements (such as turning on lights, or operating blinds) 
you can use the group key for authorization, but this authorization 
would be clearly scoped to the lights or blinds.
Resources with higher security requirements (such as door-locks) 
shouldn't be on the same multicast-group to start with, but even if they 
were, they SHOULD NOT be configured to accept actuator commands 
authorized by access tokens bound to a multicast group key.

Would that address your concerns?

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Jim Schaad <[email-masked]>
Date: Thu, 21 Jul 2016 17:17:38 +0200

> From: Ace [mailto:[email-masked]] On Behalf Of Michael StJohns
> Sent: Thursday, July 21, 2016 3:05 PM
> To: [email-masked]
> Actually, that's not the complete story.  It was one of the things that finally killed
> this off (e.g. DICE was supposed to make a profile of DTLS for constrained
> devices, BUT DTLS didn't already support multicast, so its difficult to profile it
> in...; we have to come up with message formats for a DTLS extension)
> 
> It wasn't the only thing.  Again, there's a very long record of why this was a bad
> idea in DICE.  It's trivially easy to map each and every one of those arguments to
> why the equivalent thing in ACE is bad.
> 
> >

I completely agree with this.  The problem is not how the messages are distributed and how the protection is done on the message.  The problem is that the authentication of the message is being done with a value which cannot be assigned to a single command generation entity and thus anybody with the key can masquerade as a command generation entity.

Jim

---

From: Derek Atkins <[email-masked]>
Date: Fri, 22 Jul 2016 10:10:03 -0400

Michael StJohns <[email-masked]> writes:

>  I've said similar things before, but there continues to be this
> belief from certain folk that its too expensive to do public key
> cryptography for lightbulbs.

People can believe the Earth is flat; that doesn't make them right.

> anything to fix the problem of symmetric key group communications
> UNLESS you stick to the public key sections.
>
> Later, Mike

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

---

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 25 Jul 2016 11:57:19 +0000

Hi All,

see attached a Use-case document that was prepared within the OpenAIS consortium (http://www.openais.eu/) for requirements on low latency multicast in lighting. Might help to understand the requirements at least from a lighting point of view.

Abhinav

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Mittwoch, 20. Juli 2016 12:07
To: [email-masked]
Subject: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

Hi all,

Ciao
Hannes

________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

---

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 25 Jul 2016 12:21:21 +0000

Hi Mike,

The group key is also the authorization key in the model proposed.  Any entity that holds that key can forge a message that can cause the action authorized by the issuance of that key. In your example, assuming that the door lock and the lightbulb share the same group key, then compromising the lightbulb allows you to control the door lock.
[AS] This is not the model we have in mind in the document. It is clear that the document needs some more specification work which relies on OSCOAP/COSE being complete. However, if you look at sections 3.3 and 3.4 both the AT-R and AT-KDC assume that there is a field "Scope" which mentions permissions of the entity holding the token including "which resources maybe accessed with the token". So, compromising a lightbulb group key does not automatically imply that the door-lock can be controlled with the same key.

In general, authentication comes with the key that you have - authorization is then tied to that key.  In DTLS  (as in TLS), your session key is also your authorization key once your TLS session is tied to a particular identity (e.g. via an HTTP login, via a client cert exchange, via OAuth).

Mike

/Ludwig

Ace mailing list

[email-masked]<mailto:[email-masked]>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 25 Jul 2016 12:03:33 -0400

On 7/25/2016 8:21 AM, Somaraju Abhinav wrote:
>
> Hi Mike,
>
>
> The group key is also the authorization key in the model proposed.  
> Any entity that holds that key can forge a message that can cause the 
> action authorized by the issuance of that key. In your example, 
> assuming that the door lock and the lightbulb share the same group 
> key, then compromising the lightbulb allows you to control the door lock.
> [AS] This is not the model we have in mind in the document. It is 
> clear that the document needs some more specification work which 
> relies on OSCOAP/COSE being complete. However, if you look at sections 
> 3.3 and 3.4 both the AT-R and AT-KDC assume that there is a field 
> “Scope” which mentions permissions of the entity holding the token 
> including “which resources maybe accessed with the token”. So, 
> compromising a lightbulb group key does not automatically imply that 
> the door-lock can be controlled with the same key.
>

Let's try one more time here.

1) If a group of devices share a key, and
2) If some of that group of devices are controllers, and
3) The majority are actuators (e.g. lightbulbs, locks), and,
4) The shared key is the only cryptographic protection on 
authentication, THEN,
5) The compromise of any device, even an actuator can be used to 
successfully forge messages that appear to come from controller nodes.

Permissions notwithstanding - if more than two entities share a 
symmetric key, a receiver of a symmetrically signed message cannot trust 
that the message it received came from the identified source.

[If two entities share a key, and I get a message that's signed by that 
key, and I didn't sign the message then obviously it came from the other 
guy.  If three entities share a key Alice, Bob and Charlie, and Alice 
receives a message that purports to be from Bob, but is actually 
originating from Charlie, she cannot determine that the message did not 
come from Bob through any cryptographic means with this key]

Continuing:

The usual model for symmetric key authentication of a message is:

Sender does:  messageAuthenticationCode = MAC (sharedKey, Message). Send 
Message || messageAuthenticationCode.

Receiver does:  receivedMessageAuthenticationCode = MAC (sharedKey, 
Message).  Compare receivedMessageAuthenticationCode with 
messageAuthenticationCode and if they match (according to match rules), 
message is authenticate.

Note the similarities.  In a symmetric key authentication -  the sign 
and verify steps differ only on what you do with the output of the MAC 
calculation.  Which implies that basically if you can verify it, you can 
forge it.

Please let's consider the cryptography rather than something that 
doesn't actually provide an enforceable mechanism.

Mike

ps - someplace along the way someone came up with the meme that the 
lightbulbs and locks were on the same key domain and that was what I was 
complaining about.  Instead, see above.    What I'm complaining about - 
indeed what we settled upon in DICE - is that symmetric key group 
communications systems are not secure enough for any cyber-physical 
control system without specific mitigations.   (For a definition of 
cyber-physical - Wiki is pretty good - 
https://en.wikipedia.org/wiki/Cyber-physical_system)

> session key is also your authorization key once your TLS session is 
> tied to a particular identity (e.g. via an HTTP login, via a client 
> cert exchange, via OAuth).
>

---

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 25 Jul 2016 16:59:50 +0000

________________________________
Let's try one more time here.
[AS] Good. Much clearer now.

1) If a group of devices share a key, and
2) If some of that group of devices are controllers, and
3) The majority are actuators (e.g. lightbulbs, locks), and,
4) The shared key is the only cryptographic protection on authentication, THEN,
5) The compromise of any device, even an actuator can be used to successfully forge messages that appear to come from controller nodes.
[AS] Agree.

Permissions notwithstanding - if more than two entities share a symmetric key, a receiver of a symmetrically signed message cannot trust that the message it received came from the identified source.
[AS] Agree, but I have a few comments:
1) Source authentication vs group membership authentication: I agree with you that the receiver can not authenticate the source of the message. However, if the key is not compromised, then the receiver can authenticate that the source of the message is from a group member.
2) Group membership authentication is sufficient: I am only knowledgeable about lighting applications and will talk about how this occurs (but this is also applicable to other building automation applications AFAIK). In this application, a commissioner verifies the existence of devices that are permanently installed in a building using public key crypto and can give group keys to devices that should be a part of the group. Note that these groups are not dynamically changing and members of the group are permanently installed in a building. Therefore, typically authentication of group membership is sufficient for application requirements.
3) Probability of key compromise: This is the point where group symmetric key crypto suffers compared to using symmetric key for a pair of devices. The claim here is that it is easier to compromise a key that is stored in a large number (e.g. 1000) of identical devices rather than a specific device in a network. I do not disagree with this claim. However, I do not think this is a big price to pay at least for lighting applications. The claim here is that it is easier to hack into one of a thousand identical devices than a small number of these identical devices. You have to weigh this against the fact that it solves an application problem with no other feasible solution. I am prepared to be educated in this regard but we essentially have 50-100 ms for the signing+verification process and I do not know of a solution that does this.

[If two entities share a key, and I get a message that's signed by that key, and I didn't sign the message then obviously it came from the other guy.  If three entities share a key Alice, Bob and Charlie, and Alice receives a message that purports to be from Bob, but is actually originating from Charlie, she cannot determine that the message did not come from Bob through any cryptographic means with this key]

Continuing:

Sender does:  messageAuthenticationCode = MAC (sharedKey, Message).  Send Message || messageAuthenticationCode.

Receiver does:  receivedMessageAuthenticationCode = MAC (sharedKey, Message).  Compare receivedMessageAuthenticationCode with messageAuthenticationCode and if they match (according to match rules), message is authenticate.

Note the similarities.  In a symmetric key authentication -  the sign and verify steps differ only on what you do with the output of the MAC calculation.  Which implies that basically if you can verify it, you can forge it.
[AS] This point is completely clear. We CAN NOT DO SOURCE AUTHENTICATION.

Please let's consider the cryptography rather than something that doesn't actually provide an enforceable mechanism.
[AS] Again, I repeat the comments above. It is clear that if a symmetric group key is used, then source authentication is no longer possible. But, considering cryptography, it is possible to authenticate group membership. Authentication of group membership is sufficient for this use case. The main issues to weigh are: "The greater likelihood of key compromise when the secret is shared by a large number of identical and permanently installed nodes compared to a similar single node" vs "The requirements of low latency communication".

Mike

ps - someplace along the way someone came up with the meme that the lightbulbs and locks were on the same key domain and that was what I was complaining about.  Instead, see above.    What I'm complaining about - indeed what we settled upon in DICE - is that symmetric key group communications systems are not secure enough for any cyber-physical control system without specific mitigations.
[AS] Agree. We are looking at various mitigation issues. The main ones are: Ensure permissions are properly scoped so that compromise of group key only results in little harm. Propose methods for recycling group key. Ensure that devices use PKI to authenticate themselves before receiving a group key. This list is clearly not complete and would be great to receive more input as to how more mitigation is possible.

(For a definition of cyber-physical - Wiki is pretty good - https://en.wikipedia.org/wiki/Cyber-physical_system)
Cyber-physical system - Wikipedia, the free encyclopedia<https://en.wikipedia.org/wiki/Cyber-physical_system>
en.wikipedia.org
A cyber-physical system (CPS) is a mechanism controlled or monitored by computer-based algorithms. Examples of CPS include smart grid, autonomous automobile systems, ...

Mike

---

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 25 Jul 2016 17:49:38 +0000

Hi Mike,
Would it help if the draft allows two solutions one based on symmetrical keys and one based on asymmetric keys and allows the system designers to pick one of the two options?
Abhinav
________________________________
From: Somaraju Abhinav<mailto:[email-masked]>
Sent: ‎25/‎07/‎2016 19:00
To: Michael StJohns<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

Continuing:

Mike

Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 25 Jul 2016 14:07:47 -0400

On 7/25/2016 12:59 PM, Somaraju Abhinav wrote:
>
>
>
>
> ------------------------------------------------------------------------
> symmetric key, a receiver of a symmetrically signed message cannot 
> trust that the message it received came from the identified source.
> 1) Source authentication vs group membership authentication: I agree 
> with you that the receiver can not authenticate the source of the 
> message. However, if the key is not compromised, then the receiver can 
> authenticate that the source of the message is from a group member.

The receiver has no guaranteed way of knowing whether or not ANY group 
member is compromised so the authentication is pretty much meaningless.

Also any assertion in the message as to the role of the purported sender 
is meaningless as well as you can't actually enforce responsible 
behavior on an end-node.

> 2) Group membership authentication is sufficient: I am only 
> knowledgeable about lighting applications and will talk about how this 
> occurs (but this is also applicable to other building automation 
> applications AFAIK). In this application, a commissioner verifies the 
> existence of devices that are permanently installed in a building 
> using public key crypto and can give group keys to devices that should 
> be a part of the group. Note that these groups are not dynamically 
> changing and members of the group are permanently installed in a 
> building. Therefore, typically authentication of group membership is 
> sufficient for application requirements.

Again - no.  Compromise of a single device that is legitimately part of 
the group can be done on an on-going basis.  E.g. the device gets and 
keeps getting group keys and then sends them off to the attacker.

> 3) Probability of key compromise: This is the point where group 
> symmetric key crypto suffers compared to using symmetric key for a 
> pair of devices. The claim here is that it is easier to compromise a 
> key that is stored in a large number (e.g. 1000) of identical devices 
> rather than a specific device in a network. I do not disagree with 
> this claim. However, I do not think this is a big price to pay at 
> least for lighting applications. The claim here is that it is easier 
> to hack into one of a thousand identical devices than a small number 
> of these identical devices. You have to weigh this against the fact 
> that it solves an application problem with no other feasible solution. 
> I am prepared to be educated in this regard but we essentially have 
> 50-100 ms for the signing+verification process and I do not know of a 
> solution that does this.

*sigh*  The formula for the probability of the compromised of a mesh is  
1-(1-p)^N.  Where p is the probability of the compromise of a single 
device and N is the number of devices.

The table is here: 
https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00165.html

The cost formula for actually attacking the mesh is MIN 
(costAttack[0..N]) where costAttack[0..N] is the array of costs to break 
into any given node.

The probability approaches unity that someone will figure out how to 
hack any give product assuming that product is wide spread (cf Philips 
lightbulbs).

And - I repeat - there is a feasible solution - public key control 
message authentication.   (I note with amusement that the figure of 
merit of 50-100ms performance is a decrease from what I think was the 
original figure of merit of 200-300ms and that it seems to be getting 
lower as the performance of commodity hardware increases). And note that 
special purpose hardware can do this will within this time window. 
(https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00316.html, 
https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00317.html)

>
> [If two entities share a key, and I get a message that's signed by 
> that key, and I didn't sign the message then obviously it came from 
> the other guy.  If three entities share a key Alice, Bob and Charlie, 
> and Alice receives a message that purports to be from Bob, but is 
> actually originating from Charlie, she cannot determine that the 
> message did not come from Bob through any cryptographic means with 
> this key]
>
> Continuing:
>
> Sender does:  messageAuthenticationCode = MAC (sharedKey, Message).  
> Send Message || messageAuthenticationCode.
>
> messageAuthenticationCode and if they match (according to match 
> rules), message is authenticate.
>
> calculation.  Which implies that basically if you can verify it, you 
> can forge it.

To be clear, you can't do source authentication with group symmetric keys.

So given that you can't do source authentication, why do group keys at 
all?  It's no better than a sturdy lock on an outhouse with no roof.

> [AS] Again, I repeat the comments above. It is clear that if a 
> symmetric group key is used, then source authentication is no longer 
> possible. But, considering cryptography, it is possible to 
> authenticate group membership. Authentication of group membership is 
> sufficient for this use case. The main issues to weigh are: "The 
> greater likelihood of key compromise when the secret is shared by a 
> large number of identical and permanently installed nodes compared to 
> a similar single node" vs "The requirements of low latency communication".

You've stated your restrictions.  I've stated my objections.  I see 
nothing at all new in the discussion since DICE.

> lightbulbs and locks were on the same key domain and that was what I 
> was complaining about.  Instead, see above.    What I'm complaining 
> about - indeed what we settled upon in DICE - is that symmetric key 
> group communications systems are not secure enough for any 
> cyber-physical control system without specific mitigations.
> [AS] Agree. We are looking at various mitigation issues. The main ones 
> are: Ensure permissions are properly scoped so that compromise of 
> group key only results in little harm. Propose methods for recycling 
> group key. Ensure that devices use PKI to authenticate themselves 
> before receiving a group key. This list is clearly not complete and 
> would be great to receive more input as to how more mitigation is 
> possible.

You have locked on to one particular solution that will not work. Using 
PKI to get symmetric group keys WILL NOT give you any protection.

>
> (For a definition of cyber-physical - Wiki is pretty good - 
> Cyber-physical system - Wikipedia, the free encyclopedia 
> <https://en.wikipedia.org/wiki/Cyber-physical_system>
> en.wikipedia.org
> A cyber-physical system (CPS) is a mechanism controlled or monitored 
> by computer-based algorithms. Examples of CPS include smart grid, 
> autonomous automobile systems, ...
>
>
>
>
>
>
>
>>
> ________________________________________________________ The contents 
> of this e-mail and any attachments are confidential to the intended 
> recipient. They may not be disclosed to or used by or copied in any 
> way by anyone other than the intended recipient. If this e-mail is 
> received in error, please immediately notify the sender and delete the 
> e-mail and attached documents. Please note that neither the sender nor 
> the sender's company accept any responsibility for viruses and it is 
> your responsibility to scan or otherwise check this e-mail and any 
> attachments.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Jul 2016 20:23:00 +0200

> member is compromised so the authentication is pretty much meaningless.

I would just add that it is also more difficult to determine just which
device has been broken into after the fact.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 25 Jul 2016 20:25:55 +0100

On 25/07/16 17:59, Somaraju Abhinav wrote:
> we essentially have 50-100 ms for the signing+verification process
> and I do not know of a solution that does this

Just a clarifying question: why can't the signing possibly be
done asynchronously? E.g. the private key holder could sign a
value that will only be sent later - as long as it has one of
those ready to emit whenever needed one can ignore the signing
time. That can have power consumption consequences but I'd
guess that's ok for a lightswitch.

If signing can be done ahead of time, then only verification
time has to be considered.

S.

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Mon, 25 Jul 2016 21:34:05 +0000

Because sometimes a lightswitch can have more than two states.

[http://images.philips.com/is/image/PhilipsConsumer/6916431PH-IMS-en_GB?wid=494&hei=435&$pnglarge$]

The color dial on this switch (src: http://www.philips.co.uk/c-p/6916431PH/livingcolors-remote-control) can set the color of lights one chooses. That would be quite some precomputations.

Sandeep

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Monday, July 25, 2016 9:26 PM
To: Somaraju Abhinav; Michael StJohns; [email-masked]
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

On 25/07/16 17:59, Somaraju Abhinav wrote:

> we essentially have 50-100 ms for the signing+verification process and

> I do not know of a solution that does this

Just a clarifying question: why can't the signing possibly be done asynchronously? E.g. the private key holder could sign a value that will only be sent later - as long as it has one of those ready to emit whenever needed one can ignore the signing time. That can have power consumption consequences but I'd guess that's ok for a lightswitch.

If signing can be done ahead of time, then only verification time has to be considered.

S.

---

From: Rene Struik <[email-masked]>
Date: Mon, 25 Jul 2016 21:00:21 -0400

Hi Sandeep:

Fair enough, but with, e.g., ECDSA, computation of the ephemeral key 
R:=kG can be carried out independently of the remainder of the signature 
computation (where one computes e:=h(m), and calculates 
s:=(1/k)(e-r*d)(mod n) and subsequently outputs (r,s), where r is 
derived from R). So, if one wishes to, one can pre-compute many 
ephemeral key pairs (k, kG) and use those on demand {David Naccache, if 
I remember correctly, elaborated on these types of "labor division" in a 
1998 paper}. So, in the Philips high-granularity luminary, the one 
simply hashes the state (still only a few-bytes entry) and then combines 
e with r, d, k, to produce signature component s -- a simple linear 
equation with two modular multiplies as cost.

Let's make things better...

Rene

On 7/25/2016 5:34 PM, Kumar, Sandeep wrote:
> http://images.philips.com/is/image/PhilipsConsumer/6916431PH-IMS-en_GB?wid=494&hei=435&$pnglarge$
>
> The color dial on this switch (src: 
> http://www.philips.co.uk/c-p/6916431PH/livingcolors-remote-control) 
> can set the color of lights one chooses. That would be quite some 
> precomputations.
>
> Sandeep
>
> Just a clarifying question: why can't the signing possibly be done 
> asynchronously? E.g. the private key holder could sign a value that 
> will only be sent later - as long as it has one of those ready to emit 
> whenever needed one can ignore the signing time. That can have power 
> consumption consequences but I'd guess that's ok for a lightswitch.
>
> The information contained in this message may be confidential and 
> legally protected under applicable law. The message is intended solely 
> for the addressee(s). If you are not the intended recipient, you are 
> hereby notified that any use, forwarding, dissemination, or 
> reproduction of this message is strictly prohibited and may be 
> unlawful. If you are not the intended recipient, please contact the 
> sender by return e-mail and destroy all copies of the original message.
>
>

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

---

From: Somaraju Abhinav <[email-masked]>
Date: Tue, 26 Jul 2016 10:23:33 +0000

The receiver has no guaranteed way of knowing whether or not ANY group member is compromised so the authentication is pretty much meaningless.
[AS] But this is also the case when we have two entities. The receiver has no way of knowing whether the other entity is compromised. You are simply stating my point 3 below again here. It is more likely that a group key is stolen.

Also any assertion in the message as to the role of the purported sender is meaningless as well as you can't actually enforce responsible behavior on an end-node.
[AS] Again this applies to the two entity case. If we cannot enforce responsible behaviour on the senders then having crypto makes no sense.

Again - no.  Compromise of a single device that is legitimately part of the group can be done on an on-going basis.  E.g. the device gets and keeps getting group keys and then sends them off to the attacker.
[AS] Again, this is the case with the single sender. The only issue goes back to greater likelihood of stealing a key that is shared between multiple senders.

*sigh*  The formula for the probability of the compromised of a mesh is  1-(1-p)^N.  Where p is the probability of the compromise of a single device and N is the number of devices.
[AS] You are assuming an independent probability distribution in this calculation - if the probability of key compromise from one device is p then the probability of key compromise from N devices is clearly greater than p but it is only equal to your formula in a theoretic world of independent distributions. Now if we have N identical devices in a building, I do not know what this number is but without proper experimentation there is no way to determine this number.

The table is here: https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00165.html

The cost formula for actually attacking the mesh is MIN (costAttack[0..N]) where costAttack[0..N] is the array of costs to break into any given node.
[AS] Agree.

The probability approaches unity that someone will figure out how to hack any give product assuming that product is wide spread (cf Philips lightbulbs).
[AS] Agree. But you are saying here the p goes to 1 in your formula. So we get to the situation of no difference between the group key vs pairwise keys because (1-p ~= (1 - (1-p)^N).

And - I repeat - there is a feasible solution - public key control message authentication.   (I note with amusement that the figure of merit of 50-100ms performance is a decrease from what I think was the original figure of merit of 200-300ms and that it seems to be getting lower as the performance of commodity hardware increases).
[AS] The original figure of merit of 200ms is still valid. However, not all of these 200 ms are available for crypto. It is difficult to come up with an exact number for how much is available for crypto because this really depends on the number of hops in the mesh and also whether or not a controller is present as an intermediate step between sensor and actuator. The 50-100ms I provided is already very generous from an application point of view - which we understand quite will.

And note that special purpose hardware can do this will within this time window.  (https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00316.html, https://www.ietf.org/mail-archive/web/dtls-iot/current/msg00317.html)
[AS] I do not know of any special purpose hardware that does this at the cost levels we need. We are already using ECDSA capable hardware in our development because we use asymmetric crypto for almost everything other than to turn light on/off (e.g. to configure/commission the system). The best parts we have seen offer us about 200 ms for sing+verify. The links you provided do not tell me what hardware parts you are proposing we use.

Continuing:

So given that you can't do source authentication, why do group keys at all?  It's no better than a sturdy lock on an outhouse with no roof.

You've stated your restrictions.  I've stated my objections.  I see nothing at all new in the discussion since DICE.

Mike

You have locked on to one particular solution that will not work.  Using PKI to get symmetric group keys WILL NOT give you any protection.

Mike

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 26 Jul 2016 11:10:09 +0000

Hi Rene

Makes more sense this way. Need to also add replay protection but that should be just part of the hash. Will it make things better for user experience? That depends on how big the pool of (good randomized) pre-computed values can be created before they run out and causes a stuck behavior.

Regards
Sandeep

From: Rene Struik [mailto:[email-masked]]
Sent: Tuesday, July 26, 2016 3:00 AM
To: Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav; Michael StJohns; [email-masked]
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

Hi Sandeep:

Fair enough, but with, e.g., ECDSA, computation of the ephemeral key R:=kG can be carried out independently of the remainder of the signature computation (where one computes e:=h(m), and calculates s:=(1/k)(e-r*d)(mod n) and subsequently outputs (r,s), where r is derived from R). So, if one wishes to, one can pre-compute many ephemeral key pairs (k, kG) and use those on demand {David Naccache, if I remember correctly, elaborated on these types of "labor division" in a 1998 paper}. So, in the Philips high-granularity luminary, the one simply hashes the state (still only a few-bytes entry) and then combines e with r, d, k, to produce signature component s -- a simple linear equation with two modular multiplies as cost.

Rene

Sandeep

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Monday, July 25, 2016 9:26 PM
To: Somaraju Abhinav; Michael StJohns; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

S.

Ace mailing list

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 26 Jul 2016 10:52:11 -0400

Hello,

On Tue, Jul 26, 2016 at 7:10 AM, Kumar, Sandeep <[email-masked]>
wrote:

> Hi Rene
>
>
>
> Makes more sense this way. Need to also add replay protection but that
> should be just part of the hash. Will it make things better for user
> experience? That depends on how big the pool of (good randomized)
> pre-computed values can be created before they run out and causes a stuck
> behavior.
>

If things can be made better, we should of course do that.  However, there
are risk tradeoffs that sometimes make sense.  If it is not possible to
precompute keys for speed, storage or some other reason, we need to figure
that out and have it factored into a threat model.  This should all be part
of a security considerations section (whatever is decided).  We are talking
about cyber physical devices and controllers, in this case lightbulbs.
Sure, lightbulbs are evolving, so it may make a difference if we are
talking about lightbulbs that can turn on/off, dim, change colors, or ones
that perform other functions (MIT Media Lab type stuff).  It also matters
if we are talking about use of lights within a controlled area and whether
it is connected to other networks or not (IoT devices, Internet, protected
network, etc.).  No one is suggesting that the same key be used in multiple
environments, but a single group key for one environment.

There are always tradeoffs in security and that's okay.  What is the bigger
threat model?

Lights turning on/off in large buildings could result in increased energy
costs.
Lights turning on/off could result in safety issues (they could be extreme).

What measures would mitigate these (and maybe other risks)?  Suggest
dividing up large buildings into sets so that a single group key could be
used in that set.  Limit connections to other networks or have protective
measures between them.

Maybe someone in this space can help more to build out the threat model to
help the WG with this decision.  There are still some unanswered questions
about the capabilities of hardware, are the alternate solutions to a group
key feasible?  Will blocking the use of a single group key prevent the
ability to move forward with a standard?

Thanks,
Kathleen

>
>
> Regards
>
> Sandeep
>
>
>
>
>
>
>
> *From:* Rene Struik [mailto:[email-masked]]
> *Sent:* Tuesday, July 26, 2016 3:00 AM
> *To:* Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav; Michael StJohns;
> [email-masked]
>
> *Subject:* Re: [Ace] Adoption of Low Latency Group Communication Security
> Work in ACE
>
>
>
> Hi Sandeep:
>
> Fair enough, but with, e.g., ECDSA, computation of the ephemeral key R:=kG
> can be carried out independently of the remainder of the signature
> computation (where one computes e:=h(m), and calculates s:=(1/k)(e-r*d)(mod
> n) and subsequently outputs (r,s), where r is derived from R). So, if one
> wishes to, one can pre-compute many ephemeral key pairs (k, kG) and use
> those on demand {David Naccache, if I remember correctly, elaborated on
> these types of "labor division" in a 1998 paper}. So, in the Philips
> high-granularity luminary, the one simply hashes the state (still only a
> few-bytes entry) and then combines e with r, d, k, to produce signature
> component s -- a simple linear equation with two modular multiplies as cost.
>
> [image:
> http://images.philips.com/is/image/PhilipsConsumer/6916431PH-IMS-en_GB?wid=494&hei=435&$pnglarge$]
>
> http://www.philips.co.uk/c-p/6916431PH/livingcolors-remote-control) can
> set the color of lights one chooses. That would be quite some
> precomputations.
>
>
>
> Sandeep
>
>
>
>
>
> From: Ace [mailto:[email-masked] <[email-masked]>] On Behalf
> Of Stephen Farrell
> asynchronously? E.g. the private key holder could sign a value that will
> only be sent later - as long as it has one of those ready to emit whenever
> needed one can ignore the signing time. That can have power consumption
> consequences but I'd guess that's ok for a lightswitch.
>
>
>
> ------------------------------
>
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby
> notified that any use, forwarding, dissemination, or reproduction of this
> message is strictly prohibited and may be unlawful. If you are not the
> intended recipient, please contact the sender by return e-mail and destroy
> all copies of the original message.
>
>
>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 26 Jul 2016 11:20:00 -0400

Just to note, I'm interested to see Mike's response on why this higher
level of security is necessary in terms of a threat model.  I'm not
convinced it is for lightbulbs, but that depends on how the threat
model/solution is scoped and the advice for use - lightbulbs of current day
capabilities and not other IoT devices with higher risk factors.

Thanks,
Kathleen

On Tue, Jul 26, 2016 at 10:52 AM, Kathleen Moriarty <
[email-masked]> wrote:

> Hello,
>
>
>
> On Tue, Jul 26, 2016 at 7:10 AM, Kumar, Sandeep <[email-masked]
> > wrote:
>
>> Hi Rene
>>
>>
>>
> There are always tradeoffs in security and that's okay.  What is the
> bigger threat model?
>
>> *To:* Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav; Michael
>> StJohns; [email-masked]
>>
>> *Subject:* Re: [Ace] Adoption of Low Latency Group Communication
>> Security Work in ACE
>>
>>
>>
>> Hi Sandeep:
>>

-- 

Best regards,
Kathleen

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Jul 2016 17:59:27 +0200

Hi Kathleen,

On 7/26/16 4:52 PM, Kathleen Moriarty wrote:
> What is the bigger threat model?  
>
> Lights turning on/off in large buildings could result in increased
> energy costs.

It's also a matter of changing colors, misappropriation of sensors, and
perhaps more important: expropriation of the lighting systems to attack
other systems.  Thus the concern over transitory trust, especially
should these systems have multiple functions.

Eliot

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 26 Jul 2016 12:06:16 -0400

On Tue, Jul 26, 2016 at 11:59 AM, Eliot Lear <[email-masked]> wrote:
> other systems.

Sure, but only if it's connected to other devices in a way that
permits this.  I haven't seen what the intended architecture is for
the proposed solution.

>  Thus the concern over transitory trust, especially should
> these systems have multiple functions.
>
> Eliot
>

-- 

Best regards,
Kathleen

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 Jul 2016 12:08:13 -0400

On 7/26/2016 11:20 AM, Kathleen Moriarty wrote:
> model/solution is scoped and the advice for use - lightbulbs of 
> current day capabilities and not other IoT devices with higher risk 
> factors.
>

Hi Kathleen -

Can you describe how you would prevent this protocol from being used in 
"lower security threat environments"?  I can't and I've thought about 
how to write in various crippling conditions in the protocol structure 
without any useful conclusions.

Given that, and given that public key cryptography has the desired 
security properties, I remain unwilling to support symmetric key 
multicast for any cyberphysical protocol.  It's too risky and way too 
shortsighted.

Or put another way - you might as well use hashed passwords for the 
lighting problem - it has similar security properties to symmetric key 
multicast for control.

If we went forward with this, you'd need one of the biggest, blackest 
Black Box warnings on the protocol that we could conceive of to try to 
constrain this to the "low level of security" domains:

DON'T Use this protocol for anything but lighting control.
DON'T Use this protocol where the the maximum output of the lighting 
system could present a fire, thermal or blinding threat to safety.
DON'T Use this protocol to control lighting systems involved in 
decontamination and sterilization. (E.g. UV decontamination).
DON'T Use this protocol to control any power outage backup lighting system.
DON'T Implement this in a way that prevents local physical override of 
the lighting systems.

I'm sure there are others.

Mike

> Thanks,
> Kathleen
>
> On Tue, Jul 26, 2016 at 10:52 AM, Kathleen Moriarty 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello,
>
>
>
>     On Tue, Jul 26, 2016 at 7:10 AM, Kumar, Sandeep
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Rene
>
>         Makes more sense this way. Need to also add replay protection
>         but that should be just part of the hash. Will it make things
>         better for user experience? That depends on how big the pool
>         of (good randomized) pre-computed values can be created before
>         they run out and causes a stuck behavior.
>
>
>     If things can be made better, we should of course do that. 
>     However, there are risk tradeoffs that sometimes make sense.  If
>     it is not possible to precompute keys for speed, storage or some
>     other reason, we need to figure that out and have it factored into
>     a threat model.  This should all be part of a security
>     considerations section (whatever is decided).  We are talking
>     about cyber physical devices and controllers, in this case
>     lightbulbs. Sure, lightbulbs are evolving, so it may make a
>     difference if we are talking about lightbulbs that can turn
>     on/off, dim, change colors, or ones that perform other functions
>     (MIT Media Lab type stuff). It also matters if we are talking
>     about use of lights within a controlled area and whether it is
>     connected to other networks or not (IoT devices, Internet,
>     protected network, etc.).  No one is suggesting that the same key
>     be used in multiple environments, but a single group key for one
>     environment.
>
>     There are always tradeoffs in security and that's okay.  What is
>     the bigger threat model?
>
>     What measures would mitigate these (and maybe other risks)? 
>     Suggest dividing up large buildings into sets so that a single
>     group key could be used in that set.  Limit connections to other
>     networks or have protective measures between them.
>
>     Maybe someone in this space can help more to build out the threat
>     model to help the WG with this decision.  There are still some
>     unanswered questions about the capabilities of hardware, are the
>     alternate solutions to a group key feasible?  Will blocking the
>     use of a single group key prevent the ability to move forward with
>     a standard?
>
>     Thanks,
>     Kathleen
>
>         Regards
>
>         Sandeep
>
>         *From:*Rene Struik [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *To:* Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav;
>         Michael StJohns; [email-masked] <mailto:[email-masked]>
>
>
>         *Subject:* Re: [Ace] Adoption of Low Latency Group
>         Communication Security Work in ACE
>
>         Hi Sandeep:
>
>         Fair enough, but with, e.g., ECDSA, computation of the
>         ephemeral key R:=kG can be carried out independently of the
>         remainder of the signature computation (where one computes
>         e:=h(m), and calculates s:=(1/k)(e-r*d)(mod n) and
>         subsequently outputs (r,s), where r is derived from R). So, if
>         one wishes to, one can pre-compute many ephemeral key pairs
>         (k, kG) and use those on demand {David Naccache, if I remember
>         correctly, elaborated on these types of "labor division" in a
>         1998 paper}. So, in the Philips high-granularity luminary, the
>         one simply hashes the state (still only a few-bytes entry) and
>         then combines e with r, d, k, to produce signature component s
>         -- a simple linear equation with two modular multiplies as cost.
>
>             can set the color of lights one chooses. That would be
>             quite some precomputations.
>
>             Sandeep
>
>             <mailto:[email-masked]>
>             Just a clarifying question: why can't the signing possibly
>             be done asynchronously? E.g. the private key holder could
>             sign a value that will only be sent later - as long as it
>             has one of those ready to emit whenever needed one can
>             ignore the signing time. That can have power consumption
>             The information contained in this message may be
>             confidential and legally protected under applicable law.
>             The message is intended solely for the addressee(s). If
>             you are not the intended recipient, you are hereby
>             notified that any use, forwarding, dissemination, or
>             reproduction of this message is strictly prohibited and
>             may be unlawful. If you are not the intended recipient,
>             please contact the sender by return e-mail and destroy all
>             copies of the original message.
>
>
>
>             [email-masked] <mailto:[email-masked]>
>
>         email:[email-masked] <mailto:[email-masked]>  | Skype: rstruik
>
>         cell:+1 (647) 867-5658 <tel:%2B1%20%28647%29%20867-5658>  | US:+1 (415) 690-7363 <tel:%2B1%20%28415%29%20690-7363>
>
>
>         [email-masked] <mailto:[email-masked]>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 26 Jul 2016 13:26:04 -0400

On Tue, Jul 26, 2016 at 12:08 PM, Michael StJohns <[email-masked]>
wrote:

> "lower security threat environments"?  I can't and I've thought about how
> to write in various crippling conditions in the protocol structure without
> any useful conclusions.
>
> security properties, I remain unwilling to support symmetric key multicast
> for any cyberphysical protocol.  It's too risky and way too shortsighted.
>

A question remains unanswered about the possibility of support for what you
propose in hardware asked earlier in the thread.  If there are real
constraints that prevent using the better solution, we need to understand
those constraints and work with what we have and determine the threat
model.  You are assuming a zero trust model, which I would too for many
situations, but I'm not sure that's necessary here.

> lighting problem - it has similar security properties to symmetric key

I understand the security implications fully.  I also understand that
security is a balancing act with constraints, threat models and a risk
assessment.  You might not use this to set the colors of the lights for the
empire state building or you'd recommend that it be on an isolated network
if you wanted to prevent tampering.
 There are ways to assess and mitigate threats and I don't think we should
assume that isolated networks are out of the question unless the lighting
manufacturers and IoT vendors working with us say that's not practical for
the real use cases they have.

> DON'T Implement this in a way that prevents local physical override of the
> lighting systems.
>

Or you say what the understood constraints are for using this protocol and
recommend the use for isolated networks to prevent tampering.  We have a
lower bar for the security of DHCP and connections to a DHCP server and I
want to know that there is or is not a way to mitigate the threats
associated with these concerns.  I don't see anything that helps in this
response as you don't discuss the threat model or constraints that prevent
the attacks you are worried about.  The message reads as one to scare off
responses rather than get to the questions I asked.

Thanks,
Kathleen

>> On Tue, Jul 26, 2016 at 7:10 AM, Kumar, Sandeep <
>> [email-masked]> wrote:
>>
>>> Hi Rene
>>>
>>>
>>>
>> If things can be made better, we should of course do that.  However,
>> there are risk tradeoffs that sometimes make sense.  If it is not possible
>> to precompute keys for speed, storage or some other reason, we need to
>> figure that out and have it factored into a threat model.  This should all
>> be part of a security considerations section (whatever is decided).  We are
>> talking about cyber physical devices and controllers, in this case
>> lightbulbs.  Sure, lightbulbs are evolving, so it may make a difference if
>> we are talking about lightbulbs that can turn on/off, dim, change colors,
>> or ones that perform other functions (MIT Media Lab type stuff).  It also
>> matters if we are talking about use of lights within a controlled area and
>> whether it is connected to other networks or not (IoT devices, Internet,
>> protected network, etc.).  No one is suggesting that the same key be used
>> in multiple environments, but a single group key for one environment.
>>
>> Maybe someone in this space can help more to build out the threat model
>> to help the WG with this decision.  There are still some unanswered
>> questions about the capabilities of hardware, are the alternate solutions
>> to a group key feasible?  Will blocking the use of a single group key
>> prevent the ability to move forward with a standard?
>>
>> Thanks,
>> Kathleen
>>
>>
>>>
>>>
>>> Regards
>>>
>>> Sandeep
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: Ace [mailto:[email-masked] <[email-masked]>] On
>>> Behalf Of Stephen Farrell
>>> legally protected under applicable law. The message is intended solely for
>>> the addressee(s). If you are not the intended recipient, you are hereby
> Ace mailing [email-masked]://www.ietf.org/mailman/listinfo/ace
>
>
>

-- 

Best regards,
Kathleen

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 Jul 2016 14:31:06 -0400

On 7/26/2016 1:26 PM, Kathleen Moriarty wrote:
>
>
> On Tue, Jul 26, 2016 at 12:08 PM, Michael StJohns 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     Just to note, I'm interested to see Mike's response on why this
>>     higher level of security is necessary in terms of a threat model.
>>     I'm not convinced it is for lightbulbs, but that depends on how
>>     the threat model/solution is scoped and the advice for use -
>>     lightbulbs of current day capabilities and not other IoT devices
>>     with higher risk factors.
>>
>
>     Hi Kathleen -
>
>     Can you describe how you would prevent this protocol from being
>     used in "lower security threat environments"?  I can't and I've
>     thought about how to write in various crippling conditions in the
>     protocol structure without any useful conclusions.
>
>     multicast for any cyberphysical protocol.  It's too risky and way
>     too shortsighted.
>
>
> A question remains unanswered about the possibility of support for 
> what you propose in hardware asked earlier in the thread.  If there 
> are real constraints that prevent using the better solution, we need 
> to understand those constraints and work with what we have and 
> determine the threat model.  You are assuming a zero trust model, 
> which I would too for many situations, but I'm not sure that's 
> necessary here.

And again, I ask how you would differentiate this in the protocol?

>
>
>     Or put another way - you might as well use hashed passwords for
>     the lighting problem - it has similar security properties to
>     symmetric key multicast for control.
>
>
> assessment.  You might not use this to set the colors of the lights 
> for the empire state building or you'd recommend that it be on an 
> isolated network if you wanted to prevent tampering.
>  There are ways to assess and mitigate threats and I don't think we 
> should assume that isolated networks are out of the question unless 
> the lighting manufacturers and IoT vendors working with us say that's 
> not practical for the real use cases they have.

They have said that public key cryptography is not practical for the use 
cases many times.  However, this belief seems to come more from 
over-constraining the implementation environment than from a real 
balancing.  I understand that they'd like to pay effectively zero for 
effectively perfect security.  It's not going to happen.  But paying 
effectively zero for no security and claiming that it actually *is* 
security also seems to be the wrong end of the balance too.

>
>
>     If we went forward with this, you'd need one of the biggest,
>     blackest Black Box warnings on the protocol that we could conceive
>     of to try to constrain this to the "low level of security" domains:
>
>     DON'T Use this protocol where the the maximum output of the
>     lighting system could present a fire, thermal or blinding threat
>     to safety.
>     DON'T Implement this in a way that prevents local physical
>     override of the lighting systems.
>
>
> Or you say what the understood constraints are for using this protocol 
> and recommend the use for isolated networks to prevent tampering.

We mostly don't do that.  Or haven't had to do that as the use cases 
were somewhat obvious.   In this particular case, if there is a claim of 
security, there needs to be a corresponding claim of insecurity.  Hence 
the Black Box warning.  It's up to the folks that want weak security to 
convince me that the chance of people (or things) being hurt is 
acceptably small.  (And they don't get a pass by saying that one small 
possible application *might* be ok if implemented correctly and with all 
appropriate guidance followed from protocol development through 
deployment - humans are not protocol elements.)

> We have a lower bar for the security of DHCP and connections to a DHCP 
> server and I want to know that there is or is not a way to mitigate 
> the threats associated with these concerns.  I don't see anything that 
> helps in this response as you don't discuss the threat model or 
> constraints that prevent the attacks you are worried about.  The 
> message reads as one to scare off responses rather than get to the 
> questions I asked.

Let's start first with the point that DHCP (and many/most of the IETF 
protocols) does not fall into the category of "cyber-physical control 
protocol".  The security model for DHCP is the result of long legacy 
decisions and deployed base and the fact is that screwing up a DHCP 
query response probably won't result in your toilet exploding.  I could 
be wrong and it might be interesting to explore that point.

For your second point - we've discussed the threat model and constraints 
for this lighting thing with hand waves about just how limited the 
applicability is (e.g. 4 lights in a room by Hannes) and how that's such 
a limited threat model.  And if that were all this protocol could be 
used for....

But wait - the document is not "Small lighting group control through 
symmetric key multicast security".

I have to assume that considering only this lighting thing and that 
constraint as a case doesn't represent the actual full potential use of 
the protocol.  That in turn suggests that doing such an analysis is 
meaningless and misleading with respect to the actual IETF applicability.

So answering your questions - (which so far pretty much exactly mirror 
the discussion we had on this in DICE)  let me instead to direct you to 
a framework I find useful and have used in the past.

For security to be cost effective, it must have (at least) the following 
three conditions be true:

  * cProtection < vData  -- The cost of protecting the system must be
    less the the value of what you're trying to protect.  If you're
    spending $100 to protect $5 of stuff, you're probably doing it wrong
    and will go broke.
  * vData < cAttack -- the value of what you're trying to protect must
    be less that what it costs an attack to get in.  If it costs an
    attacker $100 to reap $101 of benefit each time he attacks, he makes
    a profit and can keep attacking every day all day.  Note that this
    is the expected investment to get the payout, not necessarily per
    attack cost.  (I.e., it might cost $1/system to attack 100 systems
    with a 1% probability of success per system and with a payout of
    $101 for each system you manage to break).
  * cProtection < cAttack -- the cost of protecting the system must be
    less that what it costs an attack to get in.  If it costs you more
    to protect the system that it costs for the attacker to get it, you
    will eventually lose the arms race and go broke.

Note that vData may be different for you vs the attacker - he may think 
the reputation he gains for breaking in is worth the cost of attacking.

So let's consider this current proposal.

cProtection  - effectively 0.  Its possible that its 0+, in which case 
the analysis is even worse. (This is the delta cost for security, not 
the full system cost)

cAttack - also effectively 0 for any but the most trivial of systems.  
(There will be a one time cost in time for someone to figure out where 
to break in - but that may have already been paid as the IOT platforms 
tend to get reused. You can pay additional monies to cProtection, to try 
and raise cAttack faster, but without hardware security elements its a 
lost cause).

vData - hopefully greater than 0.

so:

cProtection (0) < vData (0+) - that's fine.

vData (0+) >= cAttack (0) - OOPS!

cProtection (0) = cAttack (0) -- OOPS - it would be nice if we could 
force someone to work up at least a little sweat, or at least figure out 
how to force them to have to attack a controller.

We can argue both about vData and cAttack, but I would argue that as 
vData goes up (by installing more lights), cAttack will remain the same 
(or worse, decrease) and at some point vData will exceed cAttack,even if 
cAttack is non-zero.  Also as vData increases, the probably of success 
of an attack will increase.

So your (document authors etc)  mission, should you decide to accept it, 
is to try and figure out how to make the above conditions hold for all 
possible instances of the protocol.  Hint - it probably involves public 
key cryptography.

Later, Mike

>>         <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>             Hi Rene
>>
>>             Makes more sense this way. Need to also add replay
>>             protection but that should be just part of the hash. Will
>>             it make things better for user experience? That depends
>>             on how big the pool of (good randomized) pre-computed
>>             values can be created before they run out and causes a
>>             stuck behavior.
>>
>>
>>         However, there are risk tradeoffs that sometimes make sense. 
>>         If it is not possible to precompute keys for speed, storage
>>         or some other reason, we need to figure that out and have it
>>         factored into a threat model. This should all be part of a
>>         security considerations section (whatever is decided).  We
>>         are talking about cyber physical devices and controllers, in
>>         this case lightbulbs.  Sure, lightbulbs are evolving, so it
>>         may make a difference if we are talking about lightbulbs that
>>         can turn on/off, dim, change colors, or ones that perform
>>         other functions (MIT Media Lab type stuff).  It also matters
>>         if we are talking about use of lights within a controlled
>>         area and whether it is connected to other networks or not
>>         (IoT devices, Internet, protected network, etc.).  No one is
>>         suggesting that the same key be used in multiple
>>         There are always tradeoffs in security and that's okay.  What
>>         is the bigger threat model?
>>
>>         Lights turning on/off in large buildings could result in
>>         increased energy costs.
>>         Suggest dividing up large buildings into sets so that a
>>         single group key could be used in that set.  Limit
>>         connections to other networks or have protective measures
>>         between them.
>>
>>         Maybe someone in this space can help more to build out the
>>         threat model to help the WG with this decision.  There are
>>         still some unanswered questions about the capabilities of
>>         hardware, are the alternate solutions to a group key
>>         feasible?  Will blocking the use of a single group key
>>             ephemeral key R:=kG can be carried out independently of
>>             the remainder of the signature computation (where one
>>             computes e:=h(m), and calculates s:=(1/k)(e-r*d)(mod n)
>>             and subsequently outputs (r,s), where r is derived from
>>             R). So, if one wishes to, one can pre-compute many
>>             ephemeral key pairs (k, kG) and use those on demand
>>             {David Naccache, if I remember correctly, elaborated on
>>             these types of "labor division" in a 1998 paper}. So, in
>>             the Philips high-granularity luminary, the one simply
>>             hashes the state (still only a few-bytes entry) and then
>>             combines e with r, d, k, to produce signature component s
>>                 can set the color of lights one chooses. That would
>>                 be quite some precomputations.
>>
>>                 Sandeep
>>
>>                 Just a clarifying question: why can't the signing
>>                 possibly be done asynchronously? E.g. the private key
>>                 holder could sign a value that will only be sent
>>                 later - as long as it has one of those ready to emit
>>                 whenever needed one can ignore the signing time. That
>>                 can have power consumption consequences but I'd guess
>>                 that's ok for a lightswitch.
>>
>>                 confidential and legally protected under applicable
>>                 law. The message is intended solely for the
>>                 addressee(s). If you are not the intended recipient,
>>                 you are hereby notified that any use, forwarding,
>>                 dissemination, or reproduction of this message is
>>                 strictly prohibited and may be unlawful. If you are
>>                 not the intended recipient, please contact the sender
>>                 by return e-mail and destroy all copies of the
>>                 original message.
>>
>>
>>

---

From: "Garcia Morchon O, Oscar" <[email-masked]>
Date: Tue, 26 Jul 2016 19:30:01 +0000

Hi Kathleen and Mike,

I would like to contribute to the discussion on the threat model.

The discussion so far was about a technical solution to enable low latency group communication. There are different technical solutions for this, based on symmetric-keys or asymmetric keys. Which solution (security control) is suitable for a system depends indeed on different aspects such as cost or risk assessment.

The creation of a secure system involves a careful analysis of the risks and the corresponding mitigation strategies. This is not new and this is broadly used, for instance, there are many documents that describe this in detail including: i) the security categorization of systems and information systems, ii) how to determine the minimum security requirements, or iii) that summarize security controls that could/should be used in different cases. In the end, what these documents say is that as the “As the risk to an information system’s confidentiality, integrity and/or availability increases, the need for additional controls to protect the system may also increase accordingly”.

When doing a risk assessment, the threats for the specific system under discussion (detailing its architecture and boundaries of the information system) are identified, and for each threat the impact and likelihood are assessed. The combination of impact and likelihood gives the risk of the threat. When systems and their information (confidentiality, integrity, availability) are categorized according to their risk (typically, in low, moderate, or high) then proper security controls are selected to create a proper security architecture, and the overall system  is re-evaluated to make sure that risks for that system are mitigated. This is a continuous process that should be done for any (IoT) information system.

If I think about the discussion, a standardized solution for low latency group communication based on symmetric keys is a security control that removes risks in many Lighting systems and use cases.

Obviously, this same security control might not be enough to decrease the associated risk in a different system. But those are just different systems, and therefore, we cannot just say that a security control based on symmetric-keys is not useful or not secure. In my opinion, this statement does not make sense.

The crucial thing to understand is that when a secure system is designed, this should be done by picking up the proper security controls that remove the risks associated to that system.

The proposed work related to low latency group communication is asking for a standardized security control based on symmetric-keys that will remove the risks in very relevant IoT use cases such as Lighting use cases.

For other systems in which this security control is not enough, then other type of solution would be required, e.g., based on PKC for source authentication in group communication. Now, saying that we should apply a PKC-based solution to all use cases, including Lighting, is also not appropriate since the systems are different so that the same security controls are not required. Otherwise, someone could also start arguing that we should use AES256 for all IoT communications since it is more secure than AES128. However, we are not using AES256 but AES128 since AES-128 provides enough security to mitigate the risks of most of the (IoT) systems.

I believe that both solutions for secure group communication in IoT – namely, solutions based on symmetric-keys and asymmetric-keys -- might be useful in the long run to address the needs of different IoT systems. However, I also believe that ACE should definitely start with the secure group communication protocol based on symmetric keys due to two reasons: a) the Lighting industry has been and is already asking for this specific security control after careful risk analysis of its use cases and b) the protocol based on symmetric-keys is easier to start with.

Thanks, Oscar.

From: Ace [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: Tuesday, July 26, 2016 1:26 PM
To: Michael StJohns
Cc: [email-masked]
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

On Tue, Jul 26, 2016 at 12:08 PM, Michael StJohns <[email-masked]<mailto:[email-masked]>> wrote:
On 7/26/2016 11:20 AM, Kathleen Moriarty wrote:
Just to note, I'm interested to see Mike's response on why this higher level of security is necessary in terms of a threat model.  I'm not convinced it is for lightbulbs, but that depends on how the threat model/solution is scoped and the advice for use - lightbulbs of current day capabilities and not other IoT devices with higher risk factors.

Hi Kathleen -

Can you describe how you would prevent this protocol from being used in "lower security threat environments"?  I can't and I've thought about how to write in various crippling conditions in the protocol structure without any useful conclusions.

Given that, and given that public key cryptography has the desired security properties, I remain unwilling to support symmetric key multicast for any cyberphysical protocol.  It's too risky and way too shortsighted.

A question remains unanswered about the possibility of support for what you propose in hardware asked earlier in the thread.  If there are real constraints that prevent using the better solution, we need to understand those constraints and work with what we have and determine the threat model.  You are assuming a zero trust model, which I would too for many situations, but I'm not sure that's necessary here.

Or put another way - you might as well use hashed passwords for the lighting problem - it has similar security properties to symmetric key multicast for control.

I understand the security implications fully.  I also understand that security is a balancing act with constraints, threat models and a risk assessment.  You might not use this to set the colors of the lights for the empire state building or you'd recommend that it be on an isolated network if you wanted to prevent tampering.
 There are ways to assess and mitigate threats and I don't think we should assume that isolated networks are out of the question unless the lighting manufacturers and IoT vendors working with us say that's not practical for the real use cases they have.

If we went forward with this, you'd need one of the biggest, blackest Black Box warnings on the protocol that we could conceive of to try to constrain this to the "low level of security" domains:

DON'T Use this protocol for anything but lighting control.
DON'T Use this protocol where the the maximum output of the lighting system could present a fire, thermal or blinding threat to safety.
DON'T Use this protocol to control lighting systems involved in decontamination and sterilization. (E.g. UV decontamination).
DON'T Use this protocol to control any power outage backup lighting system.
DON'T Implement this in a way that prevents local physical override of the lighting systems.

Or you say what the understood constraints are for using this protocol and recommend the use for isolated networks to prevent tampering.  We have a lower bar for the security of DHCP and connections to a DHCP server and I want to know that there is or is not a way to mitigate the threats associated with these concerns.  I don't see anything that helps in this response as you don't discuss the threat model or constraints that prevent the attacks you are worried about.  The message reads as one to scare off responses rather than get to the questions I asked.

Thanks,
Kathleen

Mike

Thanks,
Kathleen

On Tue, Jul 26, 2016 at 10:52 AM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

On Tue, Jul 26, 2016 at 7:10 AM, Kumar, Sandeep <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rene

If things can be made better, we should of course do that.  However, there are risk tradeoffs that sometimes make sense.  If it is not possible to precompute keys for speed, storage or some other reason, we need to figure that out and have it factored into a threat model.  This should all be part of a security considerations section (whatever is decided).  We are talking about cyber physical devices and controllers, in this case lightbulbs.  Sure, lightbulbs are evolving, so it may make a difference if we are talking about lightbulbs that can turn on/off, dim, change colors, or ones that perform other functions (MIT Media Lab type stuff).  It also matters if we are talking about use of lights within a controlled area and whether it is connected to other networks or not (IoT devices, Internet, protected network, etc.).  No one is suggesting that the same key be used in multiple environments, but a single group key for one environment.

There are always tradeoffs in security and that's okay.  What is the bigger threat model?

Lights turning on/off in large buildings could result in increased energy costs.
Lights turning on/off could result in safety issues (they could be extreme).

What measures would mitigate these (and maybe other risks)?  Suggest dividing up large buildings into sets so that a single group key could be used in that set.  Limit connections to other networks or have protective measures between them.

Maybe someone in this space can help more to build out the threat model to help the WG with this decision.  There are still some unanswered questions about the capabilities of hardware, are the alternate solutions to a group key feasible?  Will blocking the use of a single group key prevent the ability to move forward with a standard?

Thanks,
Kathleen

Regards
Sandeep

From: Rene Struik [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 26, 2016 3:00 AM
To: Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav; Michael StJohns; [email-masked]<mailto:[email-masked]>

Hi Sandeep:

Rene

Sandeep

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Monday, July 25, 2016 9:26 PM
To: Somaraju Abhinav; Michael StJohns; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

S.

Ace mailing list

--

cell: +1 (647) 867-5658<tel:%2B1%20%28647%29%20867-5658> | US: +1 (415) 690-7363<tel:%2B1%20%28415%29%20690-7363>

--

Best regards,
Kathleen

--

Best regards,
Kathleen

Ace mailing list

--

Best regards,
Kathleen

---

From: Robert Cragie <[email-masked]>
Date: Wed, 27 Jul 2016 00:55:24 +0100

Mike,

My concern with this thread is that you seem to have a very black/white
assumption regarding the use of a symmetric group key. Defining a protocol
which allows use of a symmetric group key does not in itself imply that it
will be misused. It's a bit like saying we can't design an automobile
because the driver may be inept and cause a serious accident.

However, I do agree with almost all the statements you have made regarding
the use of a symmetric group key apart from this one:

MSJ >The receiver has no guaranteed way of knowing whether or not ANY group
member is compromised so the authentication is pretty much meaningless.

It is not meaningless, it still applies to the holder of the group key.
Sure, one of the group could be compromised and as you say purport to be
any member of the group (and there are still probably mitigations against
this) but an entity outside of the group will not be able to purport to be
in the group. So it is not meaningless. There are many cases where groups
can be small and therefore (as you explain) the impact of compromise
decreases.

This leads to the points Abhinav and Kathleen have made. Security policies
can be put in place to limit the scope and distribution of group keys. If
the potential number in a group for a particular use case (taking into
account all the properties of that use case which may provide additional
mitigation) exceeds a certain amount then we can recommend that symmetric
group keys are not used.

You mentioned secure element in an earlier e-mail; these facilities are
becoming more widely available and cheaper and are starting to appear in
low-cost microcontrollers today. As indeed are crypto elements, which would
then suggest the use of signing+verifying would be more appropriate as you
suggest.

In a nutshell, I agree with your assessment regarding symmetric group keys
but there are always tradeoffs and I don't see how we can ban something
simply because it might be problematic if misused.

Robert

On 26 July 2016 at 20:30, Garcia Morchon O, Oscar <[email-masked]>
wrote:

> The discussion so far was about a technical solution to enable low latency
> group communication. There are different technical solutions for this,
> based on symmetric-keys or asymmetric keys. Which solution (security
> control) is suitable for a system depends indeed on different aspects such
> as cost or risk assessment.
>
>
>
> The creation of a secure system involves a careful analysis of the risks
> and the corresponding mitigation strategies. This is not new and this is
> broadly used, for instance, there are many documents that describe this in
> detail including: i) the security categorization of systems and information
> systems, ii) how to determine the minimum security requirements, or iii)
> that summarize security controls that could/should be used in different
> cases. In the end, what these documents say is that as the “As the risk to
> an information system’s confidentiality, integrity and/or availability
> increases, the need for additional controls to protect the system may also
> increase accordingly”.
>
>
>
> When doing a risk assessment, the threats for the specific system under
> discussion (detailing its architecture and boundaries of the information
> system) are identified, and for each threat the impact and likelihood are
> assessed. The combination of impact and likelihood gives the risk of the
> threat. When systems and their information (confidentiality, integrity,
> availability) are categorized according to their risk (typically, in low,
> moderate, or high) then proper security controls are selected to create a
> proper security architecture, and the overall system  is re-evaluated to
> make sure that risks for that system are mitigated. This is a continuous
> process that should be done for any (IoT) information system.
>
>
>
> If I think about the discussion, a standardized solution for low latency
> group communication based on symmetric keys is a security control that
> removes risks in many Lighting systems and use cases.
>
>
>
> Obviously, this same security control might not be enough to decrease the
> associated risk in a different system. But those are just different
> systems, and therefore, we cannot just say that a security control based on
> symmetric-keys is not useful or not secure. In my opinion, this statement
> does not make sense.
>
>
>
> The crucial thing to understand is that when a secure system is designed,
> this should be done by picking up the proper security controls that remove
> the risks associated to that system.
>
>
>
> The proposed work related to low latency group communication is asking for
> a standardized security control based on symmetric-keys that will remove
> the risks in very relevant IoT use cases such as Lighting use cases.
>
>
>
> For other systems in which this security control is not enough, then other
> type of solution would be required, e.g., based on PKC for source
> authentication in group communication. Now, saying that we should apply a
> PKC-based solution to all use cases, including Lighting, is also not
> appropriate since the systems are different so that the same security
> controls are not required. Otherwise, someone could also start arguing that
> we should use AES256 for all IoT communications since it is more secure
> than AES128. However, we are not using AES256 but AES128 since AES-128
> provides enough security to mitigate the risks of most of the (IoT) systems.
>
>
>
> I believe that both solutions for secure group communication in IoT –
> namely, solutions based on symmetric-keys and asymmetric-keys -- might be
> useful in the long run to address the needs of different IoT systems.
> However, I also believe that ACE should definitely start with the secure
> group communication protocol based on symmetric keys due to two reasons: a)
> the Lighting industry has been and is already asking for this specific
> security control after careful risk analysis of its use cases and b) the
> protocol based on symmetric-keys is easier to start with.
>
>
>
> Thanks, Oscar.
>
>
>
> *From:* Ace [mailto:[email-masked]] *On Behalf Of *Kathleen Moriarty
> *Sent:* Tuesday, July 26, 2016 1:26 PM
> *To:* Michael StJohns
> *Cc:* [email-masked]
>
> A question remains unanswered about the possibility of support for what
> you propose in hardware asked earlier in the thread.  If there are real

---

From: Michael StJohns <[email-masked]>
Date: Wed, 27 Jul 2016 12:06:15 -0400

On 7/26/2016 7:55 PM, Robert Cragie wrote:
> Mike,
>
> My concern with this thread is that you seem to have a very 
> black/white assumption regarding the use of a symmetric group key. 
> Defining a protocol which allows use of a symmetric group key does not 
> in itself imply that it will be misused. It's a bit like saying we 
> can't design an automobile because the driver may be inept and cause a 
> serious accident.

Hi Robert -

I tend to have a very black/white assumption with most of the laws of 
physics.

>
> However, I do agree with almost all the statements you have made 
> regarding the use of a symmetric group key apart from this one:
>
> MSJ >The receiver has no guaranteed way of knowing whether or not ANY 
> group member is compromised so the authentication is pretty much 
> meaningless.
>
> It is not meaningless, it still applies to the holder of the group 
> key. Sure, one of the group could be compromised and as you say 
> purport to be any member of the group (and there are still probably 
> mitigations against this) but an entity outside of the group will not 
> be able to purport to be in the group.

I remain confused as to how you think that is.

I'm not a member of the group, but I convinced a member of the group to 
give me his copy of the group key (e.g. I broke in and stole it and he 
was none the wiser).  How do you differentiate between me and him?  In a 
message, what cryptographic evidence proves that a message came from a 
member of the group?  If you say group key, I say "stolen".

I'm a member of the group but a bad actor - I'm masquerading as a 
controller instead of an actuator.  How do you prove I'm not a 
controller?  In a message, what cryptographic evidence proves that the 
message came from a controller?  If you say group key, I say "hacked".

Forget for a moment about the process of getting keys to the various 
devices (e.g. let's leave off the key management topic for a moment) and 
consider this case::

A device builder builds 1000 devices, of which 900 are lightbulbs and 
100 are lightswitches and installs within all of them a single group 
key.  That group key is used - as is being described here - as the key 
for the switches to control all of the light bulbs.

Note that at this point we're effectively at the same place a mesh with 
a key management protocol that is distributing a group key would be.  We 
just got there manually.

An attacker manages to get his hands on one of the lightbulbs and 
extracts the group key.  He places his own device in the system which 
has the lighting network  interface on one side, a more general IP 
network interface on the other (complete with HTTP or Telnet or 
somesuch), and contains a copy of the group key and all the relevant 
protocols. Whenever the attacker wants,  he may use that group key to 
send out a control message to any of the lightbulbs.

The addition of a key management protocol to distribute symmetric group 
keys does not improve this much if at all -- UNLESS you have wickedly 
good compromise detection mechanisms that allow you to identify and 
eject bad actors quickly.  But I can't actually think of a scenario 
where depending on good compromise detection without a human in the loop 
works well.

Continuing - the addition of the key management protocol allows you to 
update the group key and hopefully send it to only good actors. But, 
even that provides little or no mitigation as an attacker can a) steal 
the identity keys for a device and passively tap the over the air 
negotiations. b) if that doesn't work, can steal the identity keys and 
replace a legitimate device with his own clone and use that to fake 
control messages, c) re-purpose an existing device to tell him the keys, 
etc.   There are mitigations for most of these, but they require secure 
elements.  Once you have secure elements, then the argument for not 
doing public key pretty much goes away.

> So it is not meaningless. There are many cases where groups can be 
> small and therefore (as you explain) the impact of compromise decreases.

It really is meaningless when N > 2.  And becomes even more meaningless 
(true, hard to go down from zero...) as N increases.

>
> This leads to the points Abhinav and Kathleen have made. Security 
> policies can be put in place to limit the scope and distribution of 
> group keys. If the potential number in a group for a particular use 
> case (taking into account all the properties of that use case which 
> may provide additional mitigation) exceeds a certain amount then we 
> can recommend that symmetric group keys are not used.

You and I agree here.  My number is 3.  (It's actually 2, but Kerberos 
like systems are actually somewhat useful so its 3 with caveats).   I 
haven't heard an argument that makes sense for anything larger.

>
> You mentioned secure element in an earlier e-mail; these facilities 
> are becoming more widely available and cheaper and are starting to 
> appear in low-cost microcontrollers today. As indeed are crypto 
> elements, which would then suggest the use of signing+verifying would 
> be more appropriate as you suggest.
>
> In a nutshell, I agree with your assessment regarding symmetric group 
> keys but there are always tradeoffs and I don't see how we can ban 
> something simply because it might be problematic if misused.

Hmm... the IETF seems poised to ban clear-text transmissions of any kind 
because they might be problematic if misused...

Never mind.  In any case, Cyber-Physical is a different beast. We've 
started to see an upswing of attacks on poorly secured physical systems 
(power, military drones, etc).  I'm not sanguine about introducing a 
known bad solution that CANNOT be made secure without other assumptions 
(e.g. the secure element stuff).

I've sketched out a few symmetric key multicast protocols that might 
work with secure elements, but they all require an interesting thing to 
provide any guarantees - that the secure element be able to prove 
(during the key exchange/update protocol) that it is a secure element by 
the definition of the protocol.  Think of it this way - it doesn't help 
to build a protocol that depends on secure elements for guarantees, if 
you can trivially defeat those guarantees by introducing a device that 
implements the protocols, but doesn't actually keep the keys in a secure 
element.

So, I fall back on public key systems as being a lot less complex, a lot 
more flexible and a lot easier to understand than the nuances of 
symmetric key multicast.

Later, Mike

---

From: Robert Cragie <[email-masked]>
Date: Wed, 27 Jul 2016 19:42:37 +0100

Mike,

Apart from the black/white aspect, I think we are actually in agreement,
i.e. I agree that using a public key-based signature is easily the most
practical and secure mechanism from a crypto perspective. If it is
practical for the application, it should be what is recommended, However,
Markus has concisely summed up different security levels. In other words,
there are alternatives to "use public key-based signatures or the sky will
fall on your head".

Robert

On 27 July 2016 at 17:06, Michael StJohns <[email-masked]> wrote:

>> in the group.
> give me his copy of the group key (e.g. I broke in and stole it and he was
> none the wiser).  How do you differentiate between me and him?  In a
> controller instead of an actuator.  How do you prove I'm not a controller?
> In a message, what cryptographic evidence proves that the message came from
> a controller?  If you say group key, I say "hacked".
>
> A device builder builds 1000 devices, of which 900 are lightbulbs and 100
> are lightswitches and installs within all of them a single group key.  That
> group key is used - as is being described here - as the key for the
> switches to control all of the light bulbs.
>
> Note that at this point we're effectively at the same place a mesh with a
> key management protocol that is distributing a group key would be.  We just
> got there manually.
>
> An attacker manages to get his hands on one of the lightbulbs and extracts
> the group key.  He places his own device in the system which has the
> lighting network  interface on one side, a more general IP network
> interface on the other (complete with HTTP or Telnet or somesuch), and
> contains a copy of the group key and all the relevant protocols. Whenever
> the attacker wants,  he may use that group key to send out a control
> message to any of the lightbulbs.
>
> keys does not improve this much if at all -- UNLESS you have wickedly good
> compromise detection mechanisms that allow you to identify and eject bad
> actors quickly.  But I can't actually think of a scenario where depending
> on good compromise detection without a human in the loop works well.
>
> update the group key and hopefully send it to only good actors. But, even
> that provides little or no mitigation as an attacker can a) steal the
> identity keys for a device and passively tap the over the air negotiations.
> b) if that doesn't work, can steal the identity keys and replace a
> legitimate device with his own clone and use that to fake control messages,
> c) re-purpose an existing device to tell him the keys, etc.   There are
> mitigations for most of these, but they require secure elements.  Once you
> have secure elements, then the argument for not doing public key pretty
> much goes away.
>
> So it is not meaningless. There are many cases where groups can be small
>> and therefore (as you explain) the impact of compromise decreases.
>>
>
>> policies can be put in place to limit the scope and distribution of group
>> keys. If the potential number in a group for a particular use case (taking
>> into account all the properties of that use case which may provide
>> additional mitigation) exceeds a certain amount then we can recommend that
>> symmetric group keys are not used.
>>
>
> (power, military drones, etc).  I'm not sanguine about introducing a known
> bad solution that CANNOT be made secure without other assumptions (e.g. the
> secure element stuff).
>
>
> I've sketched out a few symmetric key multicast protocols that might work
> with secure elements, but they all require an interesting thing to provide
> any guarantees - that the secure element be able to prove (during the key
> exchange/update protocol) that it is a secure element by the definition of
> the protocol.  Think of it this way - it doesn't help to build a protocol
> that depends on secure elements for guarantees, if you can trivially defeat
> those guarantees by introducing a device that implements the protocols, but
> doesn't actually keep the keys in a secure element.
>
> more flexible and a lot easier to understand than the nuances of symmetric
> key multicast.
>
> Later, Mike
>
>
>
>
>
>> Robert
>>
>>
>