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