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

[Michael StJohns <[e-mail]>]

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.

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 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hello,
>
>
>
>     On Tue, Jul 26, 2016 at 7:10 AM, Kumar, Sandeep
>     <[e-mail] <mailto:[e-mail]>> 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:[e-mail]
>         <mailto:[e-mail]>]
>         *Sent:* Tuesday, July 26, 2016 3:00 AM
>         *To:* Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav;
>         Michael StJohns; [e-mail] <mailto:[e-mail]>
>
>
>         *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.
>
>         Let's make things better...
>
>         Rene
>
>         On 7/25/2016 5:34 PM, Kumar, Sandeep wrote:
>
>             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:[e-mail]] On Behalf Of
>             Stephen Farrell
>             Sent: Monday, July 25, 2016 9:26 PM
>             To: Somaraju Abhinav; Michael StJohns; [e-mail]
>             <mailto:[e-mail]>
>             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.
>
>             ------------------------------------------------------------------------
>
>             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.
>
>
>
>             _______________________________________________
>
>             Ace mailing list
>
>             [e-mail] <mailto:[e-mail]>
>
>             https://www.ietf.org/mailman/listinfo/ace
>
>         -- 
>
>         email:[e-mail] <mailto:[e-mail]>  | Skype: rstruik
>
>         cell:[phone] <tel:%2B1%20%28647%29%20867-5658>  | US:[phone] <tel:%2B1%20%28415%29%20690-7363>
>
>
>         _______________________________________________
>         Ace mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/ace
>
>
>
>
>     -- 
>
>     Best regards,
>     Kathleen
>
>
>
>
> -- 
>
> Best regards,
> Kathleen
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace