Mike,

My concern with this thread is that you seem to have a very black/white
assumption regarding the use of a symmetric group key. Defining a protocol
which allows use of a symmetric group key does not in itself imply that it
will be misused. It's a bit like saying we can't design an automobile
because the driver may be inept and cause a serious accident.

However, I do agree with almost all the statements you have made regarding
the use of a symmetric group key apart from this one:

MSJ >The receiver has no guaranteed way of knowing whether or not ANY group
member is compromised so the authentication is pretty much meaningless.

It is not meaningless, it still applies to the holder of the group key.
Sure, one of the group could be compromised and as you say purport to be
any member of the group (and there are still probably mitigations against
this) but an entity outside of the group will not be able to purport to be
in the group. So it is not meaningless. There are many cases where groups
can be small and therefore (as you explain) the impact of compromise
decreases.

This leads to the points Abhinav and Kathleen have made. Security policies
can be put in place to limit the scope and distribution of group keys. If
the potential number in a group for a particular use case (taking into
account all the properties of that use case which may provide additional
mitigation) exceeds a certain amount then we can recommend that symmetric
group keys are not used.

You mentioned secure element in an earlier e-mail; these facilities are
becoming more widely available and cheaper and are starting to appear in
low-cost microcontrollers today. As indeed are crypto elements, which would
then suggest the use of signing+verifying would be more appropriate as you
suggest.

In a nutshell, I agree with your assessment regarding symmetric group keys
but there are always tradeoffs and I don't see how we can ban something
simply because it might be problematic if misused.

Robert


On 26 July 2016 at 20:30, Garcia Morchon O, Oscar <oscar.garcia@philips.com>
wrote:

> 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:ace-bounces@ietf.org] *On Behalf Of *Kathleen Moriarty
> *Sent:* Tuesday, July 26, 2016 1:26 PM
> *To:* Michael StJohns
> *Cc:* ace@ietf.org
>
> *Subject:* Re: [Ace] Adoption of Low Latency Group Communication Security
> Work in ACE
>
>
>
>
>
>
>
> On Tue, Jul 26, 2016 at 12:08 PM, Michael StJohns <mstjohns@comcast.net>
> 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 <
> kathleen.moriarty.ietf@gmail.com> wrote:
>
> Hello,
>
>
>
>
>
>
>
> On Tue, Jul 26, 2016 at 7:10 AM, Kumar, Sandeep <sandeep.kumar@philips.com>
> 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:rstruik.ext@gmail.com]
> *Sent:* Tuesday, July 26, 2016 3:00 AM
> *To:* Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav; Michael StJohns;
> ace@ietf.org
>
>
> *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:ace-bounces@ietf.org <ace-bounces@ietf.org>] On Behalf
> Of Stephen Farrell
> Sent: Monday, July 25, 2016 9:26 PM
> To: Somaraju Abhinav; Michael StJohns; ace@ietf.org
> 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
>
> Ace@ietf.org
>
> https://www.ietf.org/mailman/listinfo/ace
>
>
>
>
>
> --
>
> email: rstruik.ext@gmail.com | Skype: rstruik
>
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>
>
>
> _______________________________________________
>
> Ace mailing list
>
> Ace@ietf.org
>
> https://www.ietf.org/mailman/listinfo/ace
>
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>