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

[Michael StJohns <[e-mail]>]

On 7/26/2016 1:26 PM, Kathleen Moriarty wrote:
>
>
> On Tue, Jul 26, 2016 at 12:08 PM, Michael StJohns 
> <[e-mail] <mailto:[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.

And again, I ask how you would differentiate this in the protocol?

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

They have said that public key cryptography is not practical for the use 
cases many times.  However, this belief seems to come more from 
over-constraining the implementation environment than from a real 
balancing.  I understand that they'd like to pay effectively zero for 
effectively perfect security.  It's not going to happen.  But paying 
effectively zero for no security and claiming that it actually *is* 
security also seems to be the wrong end of the balance too.

>
>
>     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 mostly don't do that.  Or haven't had to do that as the use cases 
were somewhat obvious.   In this particular case, if there is a claim of 
security, there needs to be a corresponding claim of insecurity.  Hence 
the Black Box warning.  It's up to the folks that want weak security to 
convince me that the chance of people (or things) being hurt is 
acceptably small.  (And they don't get a pass by saying that one small 
possible application *might* be ok if implemented correctly and with all 
appropriate guidance followed from protocol development through 
deployment - humans are not protocol elements.)

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

Let's start first with the point that DHCP (and many/most of the IETF 
protocols) does not fall into the category of "cyber-physical control 
protocol".  The security model for DHCP is the result of long legacy 
decisions and deployed base and the fact is that screwing up a DHCP 
query response probably won't result in your toilet exploding.  I could 
be wrong and it might be interesting to explore that point.

For your second point - we've discussed the threat model and constraints 
for this lighting thing with hand waves about just how limited the 
applicability is (e.g. 4 lights in a room by Hannes) and how that's such 
a limited threat model.  And if that were all this protocol could be 
used for....

But wait - the document is not "Small lighting group control through 
symmetric key multicast security".

I have to assume that considering only this lighting thing and that 
constraint as a case doesn't represent the actual full potential use of 
the protocol.  That in turn suggests that doing such an analysis is 
meaningless and misleading with respect to the actual IETF applicability.

So answering your questions - (which so far pretty much exactly mirror 
the discussion we had on this in DICE)  let me instead to direct you to 
a framework I find useful and have used in the past.

For security to be cost effective, it must have (at least) the following 
three conditions be true:

  * cProtection < vData  -- The cost of protecting the system must be
    less the the value of what you're trying to protect.  If you're
    spending $100 to protect $5 of stuff, you're probably doing it wrong
    and will go broke.
  * vData < cAttack -- the value of what you're trying to protect must
    be less that what it costs an attack to get in.  If it costs an
    attacker $100 to reap $101 of benefit each time he attacks, he makes
    a profit and can keep attacking every day all day.  Note that this
    is the expected investment to get the payout, not necessarily per
    attack cost.  (I.e., it might cost $1/system to attack 100 systems
    with a 1% probability of success per system and with a payout of
    $101 for each system you manage to break).
  * cProtection < cAttack -- the cost of protecting the system must be
    less that what it costs an attack to get in.  If it costs you more
    to protect the system that it costs for the attacker to get it, you
    will eventually lose the arms race and go broke.

Note that vData may be different for you vs the attacker - he may think 
the reputation he gains for breaking in is worth the cost of attacking.

So let's consider this current proposal.

cProtection  - effectively 0.  Its possible that its 0+, in which case 
the analysis is even worse. (This is the delta cost for security, not 
the full system cost)

cAttack - also effectively 0 for any but the most trivial of systems.  
(There will be a one time cost in time for someone to figure out where 
to break in - but that may have already been paid as the IOT platforms 
tend to get reused. You can pay additional monies to cProtection, to try 
and raise cAttack faster, but without hardware security elements its a 
lost cause).

vData - hopefully greater than 0.

so:

cProtection (0) < vData (0+) - that's fine.

vData (0+) >= cAttack (0) - OOPS!

cProtection (0) = cAttack (0) -- OOPS - it would be nice if we could 
force someone to work up at least a little sweat, or at least figure out 
how to force them to have to attack a controller.

We can argue both about vData and cAttack, but I would argue that as 
vData goes up (by installing more lights), cAttack will remain the same 
(or worse, decrease) and at some point vData will exceed cAttack,even if 
cAttack is non-zero.  Also as vData increases, the probably of success 
of an attack will increase.

So your (document authors etc)  mission, should you decide to accept it, 
is to try and figure out how to make the above conditions hold for all 
possible instances of the protocol.  Hint - it probably involves public 
key cryptography.

Later, Mike



>
> Thanks,
> Kathleen
>
>
>     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] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/ace
>
>
>
>     _______________________________________________
>     Ace mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ace
>
>
>
>
> -- 
>
> Best regards,
> Kathleen