Re: [Ace] Group Communication Security Disagreements

[Michael StJohns <[e-mail]>]

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


Hi Hannes -

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

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

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

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

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


Mike

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

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

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