Re: [Dtls-iot] FW: New Version Notification for draft-keoh-dice-multicast-security-08.txt

[Michael StJohns <[e-mail]>]

Hi Carsten - inline.

On 7/8/2014 12:04 PM, Carsten Bormann wrote:
> I consider a definition of (integrity) protection more useful that figures in the attacker.
> If an attacker can steal a lamp out of my home and tamper with it, I probably have larger issues than whether they can do some morse code on my lights.  (If they can “hack” it, they already can do the morse code thing.)
> So, yes, I consider group keying to provide integrity protection — against attackers outside the group.

If I can hack an individual light to turn it on and off, I can hack it 
to hand over the key material.  I can then turn on and off all of the 
lights in the group.

The attacker may start outside the group - its just that the security of 
the group is that of the least secure device making it trivial for the 
attacker to be "inside" the group as far as key material.

Also, unless I'm mistaken,  the usage case for lighting isn't limited to 
personal residences (nor can that limitation be enforced in the 
protocol), but also (and probably more commonly) to commercial 
buildings.  Even 1 mesh controlled light in a public access space makes 
you vulnerable to someone walking off with the light.

>
>> application-based group keying is still significant progress for those cases where the attack model doesn’t rule out group keying.
>>
>> The use cases where this works all seem to involve a secure processing element and that's not exactly within the DICE charter.
> Tamper-proofing is not required for the above use case.

If the key is not kept in storage not available to the general purpose 
processor running the node, then hacking the node allows the hacker to 
extract the key.

The hack can be physical (e.g. unscrew the lightbulb and take it with 
you and then plug it into a flash reader), or OTA (smash that stack!!).

I'm assuming you're using "tamper-proofing" where I used "secure 
processing element" - you don't necessarily need tamper-proofing (or 
even tamper detection), but you do need a way to keep the key from being 
extracted and that has to exist in each and every node, otherwise it's 
trivial to hack the mesh.

>
>> The most successful group keying system I'm aware of is pay TV (either satellite or cable).  Those systems - obviously - use a secure processing element (e.g. smart card or built in) to manage group keys and decryption based on credentials.
> This has a quite different attack model — here you hand over the entire environment (smart card, decoder) to any interested attacker.  This is not the case we are interested in.

In the pay tv environment, you've got millions of devices available to 
be hacked either remotely or physically.  In the lighting control case 
you've got 100s of lightbulbs (in one building, 100's of 1000's in many 
buildings) available to be hacked either remotely or physically.  Not 
sure I understand why the attack models are different.

The *threat* model for lightbulbs may generate less concern than the 
threat model for pay TV because the value of hacking lightbulbs may be 
less - but that is not a general property of all systems that might 
possibly use symmetric key multicast DTLS.  Even then, hacking a 
building's lighting control system is going to generate enough interest 
that it will be done and probably in a spectacular fashion.


Mike

>
>> I literally can't think of a use case without an SPE where the attack model doesn't rule out group keying for integrity protection and most attack models for most use cases rule it out for confidentiality.
> See above.
>
> Grüße, Carsten
>