Subject: [Dtls-iot] Compromise numbers for multicast

From: Michael StJohns <[email-masked]>
Date: Tue, 11 Feb 2014 23:49:22 -0500

I was trying to figure out a way of expressing the issues with shared 
group symmetric key multicast security and the dangers of not properly 
constraining the size of the multicast group that shares a single key.  
I came up with the table below.

The following  table is read with the number of nodes down along the 
left side, and the probability of any one given node being 
"compromisable" running along the top.  The intersection is the 
probability of the multicast mesh being compromised.

The formula is 1-((1-Pnode)^numNodes) where Pnode is the probability of 
a given node being compromisable.

For the IOT constrained node model, I'm generally considering a node 
compromisable if it is physically accessible to an attacker.  It *may* 
also be compromisable if its accessible via RF (e.g. stack smashing 
attacks etc).  The compromise I care about is an extraction attack on 
the group key as that gives an attacker the ability to masquerade as any 
node in the mesh, eavesdrop on any traffic, and insert traffic at will.

So in a mesh of 250 nodes, if there's a .1% chance that any given node 
is compromisable, the probability of a mesh compromise is 22.13%.  But I 
would guess that the per node percentage will probably be closer to 1% 
or greater given the wide set of devices, protections and implementation 
strategies.

This is no better than a swag, and it's hard to characterize the per 
node probability of compromise given the vast scope of IOT and the huge 
possible difference between the least and most capable nodes in a 
multicast group.  That said, taking 1% probability of mesh compromise as 
an arbitrary acceptable high water mark and .01% as an arbitrary Pnode, 
I wouldn't use shared key multicast security for anything over a group 
of 100 nodes and that only for low sensitivity applications.  If we're 
talking a Pnode of .1%, that falls to about 10 nodes.  With a Pnode of 
1%, that falls to about 2 nodes.

The mitigations for these (physically separate network, hardware 
security module, physical protections) are mostly not going to be 
available for constrained nodes, and the effective Pnode for the whole 
mesh is the MIN() of all of the Pnode's of the mesh (weakest link issue).

Mike

	5.000000% 	1.000000% 	0.100000% 	0.010000% 	0.001000% 	
5 	22.62% 	4.90% 	0.50% 	0.05% 	0.00% 	
20 	64.15% 	18.21% 	1.98% 	0.20% 	0.02% 	
100 	99.41% 	63.40% 	9.52% 	1.00% 	0.10% 	
250 	100.00% 	91.89% 	22.13% 	2.47% 	0.25% 	
500 	100.00% 	99.34% 	39.36% 	4.88% 	0.50% 	
1000 	100.00% 	100.00% 	63.23% 	9.52% 	1.00% 	
2500 	100.00% 	100.00% 	91.80% 	22.12% 	2.47% 	
5000 	100.00% 	100.00% 	99.33% 	39.35% 	4.88% 	
10000 	100.00% 	100.00% 	100.00% 	63.21% 	9.52%

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 13 Feb 2014 13:49:38 +0000

Dear Mike

A good characterization of the inherent difficulty of enabling multicast security. Even assuming that the multicast security was based on public keys in a multiple sender group, which is often the case in IoT, then based on your  Pnode of .1%, a group with 10 senders with private key has a 1% mesh probability compromise (it is enough to compromise any one of the senders). Considering that public-key based crypto is much  more side-channel leaky and often hard for developers to get it right compared to directly using the AES co-processor available in most 802.15.4 chips, the Pnode probability is going to be much more higher.

Like every building block, the risks associated  with compromise of a node need to be taken carefully into account, especially with multicast that risk goes exponentially as you show. Therefore as you mention a limit to group sizes and additional mitigations need to be in place. Public key in itself will not provide that mitigation, it may actually worsen the situation by making DoS easier by tying up constrained devices in heavy computation. One has to look at the deployment scenario, perform a risk analysis identifying the threats, and make a solid design to eliminate those risks. Although you are right and one should not use this building block in all deployments/use cases, we also firmly believe that the current approach can be an effective building block for reducing risks in many practical scenarios. Other complementary solutions may need to be created and one solution is not going to solve all problems.

Regards
Sandeep , Sye, Oscar

From: dtls-iot [mailto:[email-masked]] On Behalf Of Michael StJohns
Sent: Wednesday, February 12, 2014 5:49 AM
To: [email-masked]
Subject: [Dtls-iot] Compromise numbers for multicast

I was trying to figure out a way of expressing the issues with shared group symmetric key multicast security and the dangers of not properly constraining the size of the multicast group that shares a single key.  I came up with the table below.

The following  table is read with the number of nodes down along the left side, and the probability of any one given node being "compromisable" running along the top.  The intersection is the probability of the multicast mesh being compromised.

The formula is 1-((1-Pnode)^numNodes) where Pnode is the probability of a given node being compromisable.

For the IOT constrained node model, I'm generally considering a node compromisable if it is physically accessible to an attacker.  It *may* also be compromisable if its accessible via RF (e.g. stack smashing attacks etc).  The compromise I care about is an extraction attack on the group key as that gives an attacker the ability to masquerade as any node in the mesh, eavesdrop on any traffic, and insert traffic at will.

So in a mesh of 250 nodes, if there's a .1% chance that any given node is compromisable, the probability of a mesh compromise is 22.13%.  But I would guess that the per node percentage will probably be closer to 1% or greater given the wide set of devices, protections and implementation strategies.

This is no better than a swag, and it's hard to characterize the per node probability of compromise given the vast scope of IOT and the huge possible difference between the least and most capable nodes in a multicast group.  That said, taking 1% probability of mesh compromise as an arbitrary acceptable high water mark and .01% as an arbitrary Pnode, I wouldn't use shared key multicast security for anything over a group of 100 nodes and that only for low sensitivity applications.  If we're talking a Pnode of .1%, that falls to about 10 nodes.  With a Pnode of 1%, that falls to about 2 nodes.

The mitigations for these (physically separate network, hardware security module, physical protections) are mostly not going to be available for constrained nodes, and the effective Pnode for the whole mesh is the MIN() of all of the Pnode's of the mesh (weakest link issue).

Mike

5.000000%

1.000000%

0.100000%

0.010000%

0.001000%

5

22.62%

4.90%

0.50%

0.05%

0.00%

20

64.15%

18.21%

1.98%

0.20%

0.02%

100

99.41%

63.40%

9.52%

1.00%

0.10%

250

100.00%

91.89%

22.13%

2.47%

0.25%

500

100.00%

99.34%

39.36%

4.88%

0.50%

1000

100.00%

100.00%

63.23%

9.52%

1.00%

2500

100.00%

100.00%

91.80%

22.12%

2.47%

5000

100.00%

100.00%

99.33%

39.35%

4.88%

10000

100.00%

100.00%

100.00%

63.21%

9.52%

________________________________
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: Rene Struik <[email-masked]>
Date: Thu, 13 Feb 2014 10:01:39 -0500

Dear Kumar:

I just wanted to respond to part of your email.

To-date, state of the art public-key implementations can be done 
securely and quite efficiently without imposing undue energy cost for 
computations when compared to communication cost, certainly in hardware. 
There has been tremendous technical progress the last 15 years, but 
unfortunately perceptions of that time do not seem to have adapted to 
newer realities since (at least with IETF email traffic). Please take 
the quiz in my email to Olaf Bergman on this 
(http://www.ietf.org/mail-archive/web/ace/current/msg00226.html -- 
excerpted below).

It is under the control of implementers to do a good job; any suggestion 
that they may not be qualified to do so says more about these 
implementers than about the technology being implemented. {Happy to help 
if you need advise}

When discussing compromise of keying material, one has to look at 
impact: with symmetric group keys, compromise of a group key on any 
device of the key-sharing group compromises any traffic secured by any 
of them; with public keys, a private signature key is shared with one 
device only, so its compromise affects that device only and not any 
other device (assuming no inter dependencies in key hierarchy).

Best regards, Rene

[excerpt of my email as of February 7, 2014 to the ACE mailing list]

I have a quiz question for you all:

What is the estimated *total* energy cost of carrying out 30 billion elliptic curve scalar multiplications on RFID-style devices using a best-of-breed hardware only implementation. For simplicity, let us consider 163-bit binary curves. We will ignore any other aspects.

Answer options:
a) 1 kWh; {10c}
b) 1 thousand kWh;
c) 1 million kWh;
d) 1 billion kWh.

There are no prizes. However, I hope this puts the contribution that best-of-breed crypto computations make to global warming (vs. the contribution hereto of email traffic regarding the ACE charter and activities) into perspective.

Note: This question was triggered by Cisco's and Intel's forecast that by 2020 there would be 30 billion interconnected objects swarming the planet.

Best regards, Rene

On 2/13/2014 8:49 AM, Kumar, Sandeep wrote:
>
> Dear Mike
>
> A good characterization of the inherent difficulty of enabling 
> multicast security. Even assuming that the multicast security was 
> based on public keys in a multiple sender group, which is often the 
> case in IoT, then based on your Pnode of .1%, a group with 10 senders 
> with private key has a 1% mesh probability compromise (it is enough to 
> compromise any one of the senders). Considering that public-key based 
> crypto is much  more side-channel leaky and often hard for developers 
> to get it right compared to directly using the AES co-processor 
> available in most 802.15.4 chips, the Pnode probability is going to be 
> much more higher.
>
> Like every building block, the risks associated  with compromise of a 
> node need to be taken carefully into account, especially with 
> multicast that risk goes exponentially as you show. Therefore as you 
> mention a limit to group sizes and additional mitigations need to be 
> in place. Public key in itself will not provide that mitigation, it 
> may actually worsen the situation by making DoS easier by tying up 
> constrained devices in heavy computation. One has to look at the 
> deployment scenario, perform a risk analysis identifying the threats, 
> and make a solid design to eliminate those risks. Although you are 
> right and one should not use this building block in all 
> deployments/use cases, we also firmly believe that the current 
> approach can be an effective building block for reducing risks in many 
> practical scenarios. Other complementary solutions may need to be 
> created and one solution is not going to solve all problems.
>
> Regards
>
> Sandeep , Sye, Oscar
>
> *From:*dtls-iot [mailto:[email-masked]] *On Behalf Of 
> *Michael StJohns
> *Sent:* Wednesday, February 12, 2014 5:49 AM
> *To:* [email-masked]
> *Subject:* [Dtls-iot] Compromise numbers for multicast
>
> constraining the size of the multicast group that shares a single 
> key.  I came up with the table below.
>
> the group key as that gives an attacker the ability to masquerade as 
> any node in the mesh, eavesdrop on any traffic, and insert traffic at 
> will.
>
> is compromisable, the probability of a mesh compromise is 22.13%.  But 
> I would guess that the per node percentage will probably be closer to 
> 1% or greater given the wide set of devices, protections and 
> implementation strategies.
>
> node probability of compromise given the vast scope of IOT and the 
> huge possible difference between the least and most capable nodes in a 
> multicast group.  That said, taking 1% probability of mesh compromise 
> as an arbitrary acceptable high water mark and .01% as an arbitrary 
> Pnode, I wouldn't use shared key multicast security for anything over 
> a group of 100 nodes and that only for low sensitivity applications.  
> If we're talking a Pnode of .1%, that falls to about 10 nodes.  With a 
> Pnode of 1%, that falls to about 2 nodes.
>
> ------------------------------------------------------------------------
> 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.
>
>
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

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

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 13 Feb 2014 15:18:04 +0000

Dear Rene

Sure you can help creating the right implementation but in a multi-vendor setting where one device can compromise the group, you need to advice all the vendors - will make you a billionaire ;)

I do not agree with your statement "with public keys, a private signature key is shared with one device only, so its compromise affects that device only and not any other device'. In a multicast scenario compromising one private key of  any sender would be enough to send control commands to all devices in the group, so it does affect all devices until that key is revoked.

Regards
Sandeep

From: Rene Struik [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 4:02 PM
To: Kumar, Sandeep; Michael StJohns; [email-masked]
Subject: Re: [Dtls-iot] Compromise numbers for multicast

Dear Kumar:

To-date, state of the art public-key implementations can be done securely and quite efficiently without imposing undue energy cost for computations when compared to communication cost, certainly in hardware. There has been tremendous technical progress the last 15 years, but unfortunately perceptions of that time do not seem to have adapted to newer realities since (at least with IETF email traffic). Please take the quiz in my email to Olaf Bergman on this (http://www.ietf.org/mail-archive/web/ace/current/msg00226.html  -- excerpted below).

It is under the control of implementers to do a good job; any suggestion that they may not be qualified to do so says more about these implementers than about the technology being implemented. {Happy to help if you need advise}

When discussing compromise of keying material, one has to look at impact: with symmetric group keys, compromise of a group key on any device of the key-sharing group compromises any traffic secured by any of them; with public keys, a private signature key is shared with one device only, so its compromise affects that device only and not any other device (assuming no inter dependencies in key hierarchy).

Best regards, Rene

Answer options:

a) 1 kWh; {10c}

b) 1 thousand kWh;

c) 1 million kWh;

d) 1 billion kWh.

Best regards, Rene

Regards
Sandeep , Sye, Oscar

From: dtls-iot [mailto:[email-masked]] On Behalf Of Michael StJohns
Sent: Wednesday, February 12, 2014 5:49 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dtls-iot] Compromise numbers for multicast

Mike

5.000000%

1.000000%

0.100000%

0.010000%

0.001000%

5

22.62%

4.90%

0.50%

0.05%

0.00%

20

64.15%

18.21%

1.98%

0.20%

0.02%

100

99.41%

63.40%

9.52%

1.00%

0.10%

250

100.00%

91.89%

22.13%

2.47%

0.25%

500

100.00%

99.34%

39.36%

4.88%

0.50%

1000

100.00%

100.00%

63.23%

9.52%

1.00%

2500

100.00%

100.00%

91.80%

22.12%

2.47%

5000

100.00%

100.00%

99.33%

39.35%

4.88%

10000

100.00%

100.00%

100.00%

63.21%

9.52%

dtls-iot mailing list

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

--

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

---

From: Michael StJohns <[email-masked]>
Date: Thu, 13 Feb 2014 11:38:16 -0500

On 2/13/2014 10:18 AM, Kumar, Sandeep wrote:
> I do not agree with your statement "with public keys, a private 
> signature key is shared with one device only, so its compromise 
> affects that device only and not any other device'. In a multicast 
> scenario compromising one private key of  any sender would be enough 
> to send control commands to all devices in the group, so it does 
> affect all devices until that key is revoked.

Let's try stating this a slightly different way -

A private key is shared with one device only, but that device is one of 
many and requires an attacker to identify it and target it 
specifically.  So the Pnode for that device is Pdisc * MAX (Pphys, 
Plog), where Pdisc is the probability an attacker can identify it, Pphys 
is the probability the node is physically compromisable, and Plog is the 
probability that the node is compromisable OTA.  The probability of mesh 
compromise is 1-((1-Pnode)^numControllers) - or Pnode if there is only 
one controller.

You're correct that if you compromise the device, you can send control 
commands, but given that your example is lighting control, that the 
typical control for lighting is a light switch, and that if you're 
physically next to the light switch you can flip it on or off without 
any need to compromise the device.... well.

The key point about sequestering control credentials to only those 
devices authorized to issue commands is that it's relatively easy to 
identify which devices a) need more physical protection, b) need more 
logical protection, c) have enough value that spending money to protect 
the credentials does not break the bank (e.g. 1 expensive light switch, 
100 inexpensive light bulbs).

Mike

---

From: Michael StJohns <[email-masked]>
Date: Thu, 13 Feb 2014 11:40:42 -0500

On 2/13/2014 8:49 AM, Kumar, Sandeep wrote:
> Other complementary solutions may need to be created and one solution 
> is not going to solve all problems.

Which is probably the strongest argument for moving security protections 
to the "problem" or application level!

Mike

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 13 Feb 2014 16:46:47 +0000

It not just moving, but creating the complementary solution for source authenticity at the application level, the transport level provides the one level of defense in the layered approach.

Sandeep

From: Michael StJohns [mailto:[email-masked]]
Sent: Thursday, February 13, 2014 5:41 PM
To: Kumar, Sandeep; [email-masked]
Subject: Re: [Dtls-iot] Compromise numbers for multicast

On 2/13/2014 8:49 AM, Kumar, Sandeep wrote:
Other complementary solutions may need to be created and one solution is not going to solve all problems.

Which is probably the strongest argument for moving security protections to the "problem" or application level!

Mike

---

From: Michael StJohns <[email-masked]>
Date: Thu, 13 Feb 2014 11:51:23 -0500

> available in most 802.15.4 chips, the Pnode probability is going to be 

If you have unfettered physical access to a device and time to work, 
Pnode is 100% barring hardware protection of the key material and 
operating environment (e.g. wiping the keys if the device is physically 
penetrated, verifying the OS and firmware, etc).    If you only have OTA 
access, or are sniffing the protocols, side channel attacks tend to be a 
bit more difficult to execute.

With respect to hardware chips - if they'd spec'd decent public key 
security in the various protocols that the chips were built for in the 
first place, we wouldn't be arguing this much.  So let's not build our 
protocols based on the limitations of the hardware of the previous years 
and weak protocols.

---

From: Rene Struik <[email-masked]>
Date: Thu, 13 Feb 2014 12:17:15 -0500

Hi Sandeep:

Perhaps, I was not clear. Of course, if a device's signature key gets 
compromised it affects traffic emanating from that device. It does not 
impact signed messages sent by another device, though, which was my 
point. With group keys, key compromise on one device in the key-sharing 
group compromises the corresponding key for all other members of that 
group and, thereby, traffic emanating from any group member. (The group 
key security model is that devices in the group try and not impersonate 
each other, so that claimed source authentication and actual source 
authentication collide.)

I think you underestimate the capabilities of vendors and those who can 
complement their skill set (there is an existence proof of those with 
reasonable, not billionaire aspirations).

I hope this helps.

Rene

On 2/13/2014 10:18 AM, Kumar, Sandeep wrote:
>
> Dear Rene
>
> Sure you can help creating the right implementation but in a 
> multi-vendor setting where one device can compromise the group, you 
> need to advice all the vendors -- will make you a billionaire ;)
>
> *From:*Rene Struik [mailto:[email-masked]]
> *Sent:* Thursday, February 13, 2014 4:02 PM
> *To:* Kumar, Sandeep; Michael StJohns; [email-masked]
> *Subject:* Re: [Dtls-iot] Compromise numbers for multicast
>
> Dear Kumar:
>
> computations when compared to communication cost, certainly in 
> hardware. There has been tremendous technical progress the last 15 
> years, but unfortunately perceptions of that time do not seem to have 
> adapted to newer realities since (at least with IETF email traffic). 
> Please take the quiz in my email to Olaf Bergman on this 
> It is under the control of implementers to do a good job; any 
> suggestion that they may not be qualified to do so says more about 
> these implementers than about the technology being implemented. {Happy 
> to help if you need advise}
>
>     based on public keys in a multiple sender group, which is often
>     the case in IoT, then based on your  Pnode of .1%, a group with 10
>     senders with private key has a 1% mesh probability compromise (it
>     is enough to compromise any one of the senders). Considering that
>     public-key based crypto is much  more side-channel leaky and often
>     hard for developers to get it right compared to directly using the
>     AES co-processor available in most 802.15.4 chips, the Pnode
>     probability is going to be much more higher.
>
>     Like every building block, the risks associated  with compromise
>     of a node need to be taken carefully into account, especially with
>     multicast that risk goes exponentially as you show. Therefore as
>     you mention a limit to group sizes and additional mitigations need
>     to be in place. Public key in itself will not provide that
>     mitigation, it may actually worsen the situation by making DoS
>     easier by tying up constrained devices in heavy computation. One
>     has to look at the deployment scenario, perform a risk analysis
>     identifying the threats, and make a solid design to eliminate
>     those risks. Although you are right and one should not use this
>     building block in all deployments/use cases, we also firmly
>     believe that the current approach can be an effective building
>     block for reducing risks in many practical scenarios. Other
>     complementary solutions may need to be created and one solution is
>     not going to solve all problems.
>
>     Regards
>
>     Sandeep , Sye, Oscar
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     I was trying to figure out a way of expressing the issues with
>     shared group symmetric key multicast security and the dangers of
>     not properly constraining the size of the multicast group that
>     shares a single key.  I came up with the table below.
>
>     The following  table is read with the number of nodes down along
>     the left side, and the probability of any one given node being
>     The formula is 1-((1-Pnode)^numNodes) where Pnode is the
>     probability of a given node being compromisable.
>
>     For the IOT constrained node model, I'm generally considering a
>     node compromisable if it is physically accessible to an attacker. 
>     It *may* also be compromisable if its accessible via RF (e.g.
>     stack smashing attacks etc).  The compromise I care about is an
>     extraction attack on the group key as that gives an attacker the
>     ability to masquerade as any node in the mesh, eavesdrop on any
>     traffic, and insert traffic at will.
>
>     So in a mesh of 250 nodes, if there's a .1% chance that any given
>     node is compromisable, the probability of a mesh compromise is
>     22.13%.  But I would guess that the per node percentage will
>     probably be closer to 1% or greater given the wide set of devices,
>     protections and implementation strategies.
>
>     This is no better than a swag, and it's hard to characterize the
>     per node probability of compromise given the vast scope of IOT and
>     the huge possible difference between the least and most capable
>     nodes in a multicast group.  That said, taking 1% probability of
>     mesh compromise as an arbitrary acceptable high water mark and
>     .01% as an arbitrary Pnode, I wouldn't use shared key multicast
>     security for anything over a group of 100 nodes and that only for
>     low sensitivity applications.  If we're talking a Pnode of .1%,
>     that falls to about 10 nodes.  With a Pnode of 1%, that falls to
>     about 2 nodes.
>
>     available for constrained nodes, and the effective Pnode for the
>     whole mesh is the MIN() of all of the Pnode's of the mesh (weakest
>     link issue).
>
>     Mike
>
>
>
>
>     	
>
>     5.000000%
>
>     	
>
>     1.000000%
>
>     	
>
>     0.100000%
>
>     	
>
>     0.010000%
>
>     	
>
>     0.001000%
>
>     	
>
>     5
>
>     	
>
>     22.62%
>
>     	
>
>     4.90%
>
>     	
>
>     0.50%
>
>     	
>
>     0.05%
>
>     	
>
>     0.00%
>
>     	
>
>     20
>
>     	
>
>     64.15%
>
>     	
>
>     18.21%
>
>     	
>
>     1.98%
>
>     	
>
>     0.20%
>
>     	
>
>     0.02%
>
>     	
>
>     100
>
>     	
>
>     99.41%
>
>     	
>
>     63.40%
>
>     	
>
>     9.52%
>
>     	
>
>     1.00%
>
>     	
>
>     0.10%
>
>     	
>
>     250
>
>     	
>
>     100.00%
>
>     	
>
>     91.89%
>
>     	
>
>     22.13%
>
>     	
>
>     2.47%
>
>     	
>
>     0.25%
>
>     	
>
>     500
>
>     	
>
>     100.00%
>
>     	
>
>     99.34%
>
>     	
>
>     39.36%
>
>     	
>
>     4.88%
>
>     	
>
>     0.50%
>
>     	
>
>     1000
>
>     	
>
>     100.00%
>
>     	
>
>     100.00%
>
>     	
>
>     63.23%
>
>     	
>
>     9.52%
>
>     	
>
>     1.00%
>
>     	
>
>     2500
>
>     	
>
>     100.00%
>
>     	
>
>     100.00%
>
>     	
>
>     91.80%
>
>     	
>
>     22.12%
>
>     	
>
>     2.47%
>
>     	
>
>     5000
>
>     	
>
>     100.00%
>
>     	
>
>     100.00%
>
>     	
>
>     99.33%
>
>     	
>
>     39.35%
>
>     	
>
>     4.88%
>
>     	
>
>     10000
>
>     	
>
>     100.00%
>
>     	
>
>     100.00%
>
>     	
>
>     100.00%
>
>     	
>
>     63.21%
>
>     	
>
>     9.52%
>
>     	
>
>     	
>     	
>     	
>     	
>     	
>     	
>
>     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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Feb 2014 18:56:25 +0100

> I was trying to figure out a way of expressing the issues with shared group symmetric key multicast security and the dangers of not properly constraining the size of the multicast group that shares…

Nice demonstration of the issue with sharing keys in a group.
It clearly proves that pay TV is impossible :-)

Now, of course, the table only would make literal sense if the probabilities of compromise were uncorrelated, which is never the case.
You either have an attacker, and then the number of compromisable instances is almost irrelevant (although the ease of getting one may increase with the number, the increase is rarely as pronounced).
Or you don’t have an attacker, and then you are safe (!).
More interesting is the damage a single compromised key can do, which may be linear to the group size, and which may influence the likelihood of an attacker being interested.

The group size is one important factor influencing the risk/cost relationship.
But questions of threat model, incentive for compromise etc. are usually more important.
The most important guideline may be to avoid putting large chests of gold behind some thin security.
Other advice, such as enabling regular (and thus necessarily cheap) rekeying, may also be useful.

For controlling the lights in my living room, a symmetric shared key is entirely adequate.

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Thu, 13 Feb 2014 13:34:23 -0500

On 2/13/2014 12:56 PM, Carsten Bormann wrote:
> It clearly proves that pay TV is impossible:-)

Given the number of times pay tv has been compromised, I rest my case.  

> mesh is the MIN() of all of the Pnode's of the mesh (weakest link issue).

In the cable tv case, the value of data protected allows them to provide 
a hardware security module (e.g. smart card, smart chip, cablecard, set 
top box)  as part of the cost of doing business. They also make this 
work by having a single sender, non-control system with fairly rapidly 
rotating traffic keys.

> You either have an attacker, and then the number of compromisable instances is almost irrelevant (although the ease of getting one may increase with the number, the increase is rarely as pronounced…
As I explained, I suggested that Pnode was a rough estimate of the 
average compromisability of the nodes of the mesh and was nothing more 
than a swag to illustrate the issues with the increase of mesh size.
> Or you don’t have an attacker, and then you are safe (!).

Pattacker approaches 100% as the number of installations reaches an 
interesting number, as the hackers write script kiddy kits and as the 
system transitions from a security savvy installer to an IT security 
illiterate building manager.

> But questions of threat model, incentive for compromise etc. are usually more important.

The issue here is that we're trying to write general purpose TLS based 
IOT profiles.  Given that a single general purpose IOT mesh can be 100s 
of 1000s of nodes, its pretty clear to me that ANY symmetric key 
approach is not going to be generally applicable.

> Other advice, such as enabling regular (and thus necessarily cheap) rekeying, may also be useful.

We (IETF) write protocols and applicability statements.  We can provide 
constraints (e.g. don't use this on any mesh that's not Carsten's living 
room and only if there are 5 lights or less), but given that people tend 
to ignore the designed applicability of our protocols (e.g. DNS being 
used as a swiss army knife), it's unclear the constraints will be strong 
enough or provide enough weight of consideration for the possible 
implementers.  We mostly don't write usage guidance - the closest we 
come is the security considerations section, and it would kind of defeat 
the purpose to write "don't use this on meshes in size > 5 without 
physical security mitigations"

> For controlling the lights in my living room, a symmetric shared key is entirely adequate.
For controlling the lights in your living room, the link-layer security 
to prevent strangers from inserting traffic in your RF mesh is entirely 
adequate.  And that's not a TLS function.

Mike

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Feb 2014 21:16:18 +0100

I think we are in violent agreement, up to here:

> The issue here is that we're trying to write general purpose TLS based IOT profiles.  Given that a single general purpose IOT mesh can be 100s of 1000s of nodes, its pretty clear to me that ANY symmetric key approach is not going to be generally applicable.

So far, this is proof by lack of imagination.
(But, clearly, we’d have to substantiate “ANY symmetric key approach” to prove the opposite.)

> For controlling the lights in your living room, the link-layer security to prevent strangers from inserting traffic in your RF mesh is entirely adequate.  And that's not a TLS function.

Here I completely disagree: 
We have to do whatever we can to get rid of the current consumer electronics notion that the keying protecting access to the home network also is the perfect means to authorize control over everything in the entire home.

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Thu, 13 Feb 2014 18:37:09 -0500

> (But, clearly, we’d have to substantiate “ANY symmetric key approach” to prove the opposite.)

No, this is proof by statistical analysis.  Assuming the figure of merit 
number of 1% chance of compromise of the mesh, with a mesh of 100000 
devices, you'd need an average Pnode of less than .00001%. If you 
believe its possible to build a device class that has an average Pnode < 
.00001% then I have a bridge to sell you.  Cash please! Small bills.

Again, this (as does my original email) assumes NO mitigation in the 
form of hardware security modules, physically protected nodes and 
physically isolated nodes.

> We have to do whatever we can to get rid of the current consumer electronics notion that the keying protecting access to the home network also is the perfect means to authorize control over everyth…

We have to do whatever we can to understand that multicast DTLS as 
described in the current document with a common shared key does not 
provide any additional security over that provided by the link-layer.   
It's an investment that looks like it provides some additional security, 
but it really and truly doesn't.

Here's the underlying problem:  cProtection < vData < cAttack.  Cost 
effective security needs to have this set of relationships.  You don't 
want to pay more for protection, than the value of what you're 
protecting.  You don't want to pay more for protection than what it will 
cost the attacker to break in, and you don't want the value of the data 
to be more than what it costs the attacker to get it.   In a mesh with a 
single key system, vData becomes SUM(vData) - the total value of what's 
being protected by the single key.  As you add more nodes, SUM(vData) 
increases. Eventually it becomes a really interesting target for the 
attacker. That suggests as the number of nodes protected by the same key 
increases, you need to increase your cProtection spending past that 
appropriate for DICE.