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

[Kathleen Moriarty <[e-mail]>]

On Tue, Jul 26, 2016 at 12:08 PM, Michael StJohns <[e-mail]>
wrote:

> 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.
>

A question remains unanswered about the possibility of support for what you
propose in hardware asked earlier in the thread.  If there are real
constraints that prevent using the better solution, we need to understand
those constraints and work with what we have and determine the threat
model.  You are assuming a zero trust model, which I would too for many
situations, but I'm not sure that's necessary here.



>
> 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.
>

I understand the security implications fully.  I also understand that
security is a balancing act with constraints, threat models and a risk
assessment.  You might not use this to set the colors of the lights for the
empire state building or you'd recommend that it be on an isolated network
if you wanted to prevent tampering.
 There are ways to assess and mitigate threats and I don't think we should
assume that isolated networks are out of the question unless the lighting
manufacturers and IoT vendors working with us say that's not practical for
the real use cases they have.



>
> 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.
>

Or you say what the understood constraints are for using this protocol and
recommend the use for isolated networks to prevent tampering.  We have a
lower bar for the security of DHCP and connections to a DHCP server and I
want to know that there is or is not a way to mitigate the threats
associated with these concerns.  I don't see anything that helps in this
response as you don't discuss the threat model or constraints that prevent
the attacks you are worried about.  The message reads as one to scare off
responses rather than get to the questions I asked.

Thanks,
Kathleen


> I'm sure there are others.
>
> Mike
>
>
>
>
> Thanks,
> Kathleen
>
> On Tue, Jul 26, 2016 at 10:52 AM, Kathleen Moriarty <
> [e-mail]> wrote:
>
>> Hello,
>>
>>
>>
>> On Tue, Jul 26, 2016 at 7:10 AM, Kumar, Sandeep <
>> [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]]
>>> *Sent:* Tuesday, July 26, 2016 3:00 AM
>>> *To:* Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav; Michael
>>> StJohns; [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.
>>>
>>> [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:[e-mail] <[e-mail]>] On
>>> Behalf Of Stephen Farrell
>>> Sent: Monday, July 25, 2016 9:26 PM
>>> To: Somaraju Abhinav; Michael StJohns; [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]
>>>
>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> email: [e-mail] | Skype: rstruik
>>>
>>> cell: [phone] | US: [phone]
>>>
>>>
>>> _______________________________________________
>>> Ace mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>
>
>
> --
>
> Best regards,
> Kathleen
>
>
> _______________________________________________
> Ace mailing [e-mail]://www.ietf.org/mailman/listinfo/ace
>
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>
>


-- 

Best regards,
Kathleen