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.
Thanks, Kathleen On Tue, Jul 26, 2016 at 10:52 AM, Kathleen Moriarty < [email protected]> wrote: > Hello, > > > > On Tue, Jul 26, 2016 at 7:10 AM, Kumar, Sandeep <[email protected] > > 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:[email protected]] >> *Sent:* Tuesday, July 26, 2016 3:00 AM >> *To:* Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav; Michael >> StJohns; [email protected] >> >> *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. >> >> [image: >> 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:[email protected] <[email protected]>] On Behalf >> Of Stephen Farrell >> Sent: Monday, July 25, 2016 9:26 PM >> To: Somaraju Abhinav; Michael StJohns; [email protected] >> 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 >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/ace >> >> >> >> >> >> -- >> >> email: [email protected] | Skype: rstruik >> >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> _______________________________________________ >> Ace mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ace >> >> > > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
