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

["Garcia Morchon O, Oscar" <[e-mail]>]

Hi Kathleen and Mike,

I would like to contribute to the discussion on the threat model.

The discussion so far was about a technical solution to enable low latency group communication. There are different technical solutions for this, based on symmetric-keys or asymmetric keys. Which solution (security control) is suitable for a system depends indeed on different aspects such as cost or risk assessment.

The creation of a secure system involves a careful analysis of the risks and the corresponding mitigation strategies. This is not new and this is broadly used, for instance, there are many documents that describe this in detail including: i) the security categorization of systems and information systems, ii) how to determine the minimum security requirements, or iii) that summarize security controls that could/should be used in different cases. In the end, what these documents say is that as the “As the risk to an information system’s confidentiality, integrity and/or availability increases, the need for additional controls to protect the system may also increase accordingly”.

When doing a risk assessment, the threats for the specific system under discussion (detailing its architecture and boundaries of the information system) are identified, and for each threat the impact and likelihood are assessed. The combination of impact and likelihood gives the risk of the threat. When systems and their information (confidentiality, integrity, availability) are categorized according to their risk (typically, in low, moderate, or high) then proper security controls are selected to create a proper security architecture, and the overall system  is re-evaluated to make sure that risks for that system are mitigated. This is a continuous process that should be done for any (IoT) information system.

If I think about the discussion, a standardized solution for low latency group communication based on symmetric keys is a security control that removes risks in many Lighting systems and use cases.

Obviously, this same security control might not be enough to decrease the associated risk in a different system. But those are just different systems, and therefore, we cannot just say that a security control based on symmetric-keys is not useful or not secure. In my opinion, this statement does not make sense.

The crucial thing to understand is that when a secure system is designed, this should be done by picking up the proper security controls that remove the risks associated to that system.

The proposed work related to low latency group communication is asking for a standardized security control based on symmetric-keys that will remove the risks in very relevant IoT use cases such as Lighting use cases.

For other systems in which this security control is not enough, then other type of solution would be required, e.g., based on PKC for source authentication in group communication. Now, saying that we should apply a PKC-based solution to all use cases, including Lighting, is also not appropriate since the systems are different so that the same security controls are not required. Otherwise, someone could also start arguing that we should use AES256 for all IoT communications since it is more secure than AES128. However, we are not using AES256 but AES128 since AES-128 provides enough security to mitigate the risks of most of the (IoT) systems.

I believe that both solutions for secure group communication in IoT – namely, solutions based on symmetric-keys and asymmetric-keys -- might be useful in the long run to address the needs of different IoT systems. However, I also believe that ACE should definitely start with the secure group communication protocol based on symmetric keys due to two reasons: a) the Lighting industry has been and is already asking for this specific security control after careful risk analysis of its use cases and b) the protocol based on symmetric-keys is easier to start with.

Thanks, Oscar.

From: Ace [mailto:[e-mail]] On Behalf Of Kathleen Moriarty
Sent: Tuesday, July 26, 2016 1:26 PM
To: Michael StJohns
Cc: [e-mail]
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE



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.



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