Re: [Ace] Summary of ACE Group Communication Security Discussion

[Michael Richardson]

Michael StJohns  wrote:
>> I'm less sure that I agree with the subsequent view that we can't
>> adopt this item until we have assurance; I'd say that asking for the
>> issue to be addressed as part of the adoption process is reasonable,
>> and objecting at WGLC if it has not been addressed is the right way.

> 
http://www.techworm.net/2016/11/researchers-use-drones-hijack-philips-hue-smart-lights.html
> describes how the use of multi-party symmetric key systems weakens even
> minimal security guarantees in a IOT system.  In this article, its
> noted that the HUE lights have firmware that's signed/encrypted by a
> symmetric key (which - by definition then needs to be included in every
> device to decrypt/verify the firmware), and that the attackers were
> able to extract the key from a lightbulb with relative ease; craft
> their own firmware and cause the lightbulbs to load it in a chain
> reaction.

I had read all about this, and I wondered how they had gotten the bogus
firmware accepted; I thought that this was the "bug", but I hadn't read (or I
had missed) that the firmware was symmetric signed.  That's really really dumb.

> So I'd turn this around and ask for a offer of proof that we can find a
> way to do this safely *BEFORE* having the IETF invest time and
> resources in the work.  I don't expect a fully fleshed out solution,
> but I haven't seen even a hint that anyone knows how to mitigate the
> risks.

I see your point.


-- 
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Summary of ACE Group Communication Security Discussion

[Michael StJohns]

On 11/12/2016 5:11 PM, Michael Richardson wrote:

I realize that this thread is months old: I haven't seen any newer
conversation, so I'll continue anyway.

I would concur with MSJ's view that having an informational draft might be a
way to let this work go forward, but I suggest instead the right track might
be experimental.
I suggested Informational as the IETF has a long history of republishing 
things developed elsewhere as "Here's how we did it documents".  
Experimental documents generally describe ideas either where we know 
there is a way forward, but we're not sure which of several paths work, 
or ideas where the general utility may not be readily apparent.I 
could live with experimental/non-WG.



I'm less sure that I agree with the subsequent view that we can't adopt this
item until we have assurance; I'd say that asking for the issue to be
addressed as part of the adoption process is reasonable, and objecting at
WGLC if it has not been addressed is the right way.


http://www.techworm.net/2016/11/researchers-use-drones-hijack-philips-hue-smart-lights.html 
describes how the use of multi-party symmetric key systems weakens even 
minimal security guarantees in a IOT system.  In this article, its noted 
that the HUE lights have firmware that's signed/encrypted by a symmetric 
key (which - by definition then needs to be included in every device to 
decrypt/verify the firmware), and that the attackers were able to 
extract the key from a lightbulb with relative ease; craft their own 
firmware and cause the lightbulbs to load it in a chain reaction.


There really isn't a lot of difference in the key extraction attack for 
the above vs extracting a symmetric key used for group communications.  
The only saving grace in group comms is that the group is smaller than 
unity.


So I'd turn this around and ask for a offer of proof that we can find a 
way to do this safely *BEFORE* having the IETF invest time and resources 
in the work.  I don't expect a fully fleshed out solution, but I haven't 
seen even a hint that anyone knows how to mitigate the risks.






I will say I'm scared that garage door actuators and doors and security
systems will be sold with "lighting" interfaces.  This same thing happened in
USB space: zillions of inappropriate USB devices were given HID designations
because the windows drivers were easier to write/get-signed.



At least most of those weren't cyber physical (except maybe the USB nerf 
turret and its ilk 
http://weburbanist.com/2009/11/18/truly-geeky-gadgets-15-usb-weapons-from-fail-to-fantastic/).


Mike


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Summary of ACE Group Communication Security Discussion

[Michael Richardson]

see inline as well.

In the summary, it was unclear if I was against the symmetric method or not.
I will admit that I'm sitting on the fence here.  I would prefer not to have
a standardized symmetric method.

My preference would be to start running code that shows the price/performance
of asymmetric methods in a lighting context.  It would have to be done by a
sufficiently resourced group motivated to show positive results.

Michael StJohns  wrote:
>> Without a hat on, you can add my support to Abhinav's proposal.
>> Perfect is ideal, but you often can not make any progress if you
>> accept nothing less.  The security considerations section will have to
>> be thorough.

> Hi Kathleen et al -

> To attain "rough consensus", RFC 7282 requires that "all issues be
> addressed" even if not all issues are accommodated.  So far the basic
> issues of "this is unsafe as a mechanism for 'securing' a control
> protocol" or even "how the heck do we keep this off the broader
> internet" have not been addressed.

> I once again suggest that the lighting folk go off and write something
> that they implement as a group, and bring it back to the IETF as an
> informational "here's how we did it" document, rather than adopting
> this as a WG item.  The ONLY thing that even argues for considering
> symmetric key multicast (vice asymmetric key multicast) is the latency
> claims for lighting.  I haven't yet heard of another use case with the
> particular combination of cheapness and latency of lighting which would
> suggest this particular combination is useful elsewhere.

I realize that this thread is months old: I haven't seen any newer
conversation, so I'll continue anyway.

I would concur with MSJ's view that having an informational draft might be a
way to let this work go forward, but I suggest instead the right track might
be experimental.

I'm less sure that I agree with the subsequent view that we can't adopt this
item until we have assurance; I'd say that asking for the issue to be
addressed as part of the adoption process is reasonable, and objecting at
WGLC if it has not been addressed is the right way.

I will say I'm scared that garage door actuators and doors and security
systems will be sold with "lighting" interfaces.  This same thing happened in
USB space: zillions of inappropriate USB devices were given HID designations
because the windows drivers were easier to write/get-signed.












signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace