Re: [Ace] Group Communication Security Disagreements

[Michael Richardson <[e-mail]>]

Michael StJohns <[e-mail]> wrote:
    > On 7/27/2016 5:56 PM, Michael Richardson wrote:


    > Kathleen Moriarty <[e-mail]> wrote:
    >>> Mohit Sethi <[e-mail]> wrote:
    >>> > designed/developed/specified for their use-case. I could definitely
    >>> > see some IoT startup building a solution that switches on the lights
    >>> > in a room as soon as you unlock the door (thus keeping them in the
    >>> > same group).
    >>>
    >>> Or perhaps more usefully, turning the lights (and the oven) off when you
    >>> leave the house.

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

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

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

Well, who other than Nixon could go to China?

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

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

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

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

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

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

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

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

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

+1.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-