Subject: [Dtls-iot] IOT and security - thoughts on the "Tyranny of the Lightswitch"

From: Michael StJohns <[email-masked]>
Date: Thu, 10 Jul 2014 08:48:20 -0400

Some general comments on "minimum necessary security".

There's this old joke about a guy who comes up on another guy on his 
hands and knees under a streetlight at night.  The first guy asks the 
guy on his knees what he's looking for and get's told he's looking for a 
$20 gold coin (told you it was old).  The first guy offers to help and 
gets down with the other guy and looks around. After 5 minutes or so of 
not finding anything, the first guy asks the second guy "Where exactly 
were you when you lost it?" The second guy get up and points to a dark 
spot about 15 feet away.  The first guy then asks "So why are you 
looking here rather than there?"  The second guy says "Because the 
light's better here".

Reasoning about security based on the (unknown) minimum capabilities of 
the IOT nodes rather than the security requirements of the DICE use 
cases is a bit like looking for the coin under the light rather than 
where you dropped it.  It may be easier to say "we MUST use symmetric 
key because the poor node can't handle anything else", but chances are 
you're not going to actually meet even minimal security requirements 
that way.

This argument is not new - we've been having it in various groups 
related to IOT (smart objects, zigbee, smart energy, sensors mesh etc) 
for years.  SEP2, after going around and around finally decided that 
building standards to the least capable chips available at the time was 
probably a bad idea given the time to complete the standard and then get 
first commercial products (e.g. because the least capable chips of the 
future were more capable than the least capable chips now).  SEP2 ended 
up including EC public key support in all nodes after heated debates and 
with substantial pushback from the manufacturers of the smallest of the 
SEP2 devices (light switches and power outlet controllers).

The thing to understand is that silicon is actually pretty cheap. Adding 
support for baseline public key processing to purpose built IOT chips 
will happen if the standard requires it and there's a commercial need 
for the IOT product.  I would guess that coming expiration of relevant 
elliptic patents will also speed this along. So designing for security 
that can meet general IOT requirements, rather than designing for 
security that fits into the current absolutely dirt cheap chips is 
really where we need to go with DICE solutions.  That is,  if we want 
our specifications to be relevant for more than a week past publication 
of the RFC.

The above is - obviously - opinion.  YMMV.

Mike

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Jul 2014 14:53:33 +0200

Hey Mike,

> you're not going to actually meet even minimal security requirements
This seems to be a common problem, indeed.

Here is another pointer that supports your argument:
http://contextis.co.uk/blog/hacking-internet-connected-light-bulbs/

> SEP2 devices (light switches and power outlet controllers).

I wouldn't necessarily refer to SEP2, which seems to head in the
direction of market failure but that's probably beside the point.

> our specifications to be relevant for more than a week past publication

+1

Ciao
Hannes

---

From: Mohit Sethi <[email-masked]>
Date: Thu, 10 Jul 2014 15:58:04 +0300

+1
On Thursday 10 July 2014 03:48 PM, Michael StJohns wrote:
> guy on his knees what he's looking for and get's told he's looking for 
> a $20 gold coin (told you it was old).  The first guy offers to help 
> and gets down with the other guy and looks around. After 5 minutes or 
> so of not finding anything, the first guy asks the second guy "Where 
> exactly were you when you lost it?" The second guy get up and points 
> to a dark spot about 15 feet away.  The first guy then asks "So why 
> are you looking here rather than there?"  The second guy says "Because 
> the light's better here".
>
> Reasoning about security based on the (unknown) minimum capabilities 
> of the IOT nodes rather than the security requirements of the DICE use 
> building standards to the least capable chips available at the time 
> was probably a bad idea given the time to complete the standard and 
> then get first commercial products (e.g. because the least capable 
> chips of the future were more capable than the least capable chips 
> now).  SEP2 ended up including EC public key support in all nodes 
> after heated debates and with substantial pushback from the 
> manufacturers of the smallest of the SEP2 devices (light switches and 
> power outlet controllers).
>
> The thing to understand is that silicon is actually pretty cheap. 
> Adding support for baseline public key processing to purpose built IOT 
> chips will happen if the standard requires it and there's a commercial 
> need for the IOT product.  I would guess that coming expiration of 
> relevant elliptic patents will also speed this along. So designing for 
> security that can meet general IOT requirements, rather than designing 
> for security that fits into the current absolutely dirt cheap chips is 
> our specifications to be relevant for more than a week past 
> publication of the RFC.
>
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 10 Jul 2014 13:51:46 +0000

>> It may be easier to say "we MUST use symmetric

[SK] I doubt this example supports your argument in any way. You can do stupid things like handing out your wifi credentials to anyone who asks for it. This is just an example of poor boostrapping (or onbaorading as they refer) with a product global key. This could well have been done equally bad with public keys.

Sandeep

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Jul 2014 16:08:06 +0200

On 10 Jul 2014, at 15:51, Kumar, Sandeep <[email-masked]> wrote:

> This could well have been done equally bad with public keys.

Indeed, it is really easy do design bad systems with public key crypto.

(I think we are all aware of another incident:
http://googleonlinesecurity.blogspot.de/2014/07/maintaining-digital-certificate-security.html)

Much more important than whether the scheme used for an application is based on symmetric or asymmetric keys is whether the workflow actually makes sense.  Yes, some workflows require asymmetric cryptography to enable them, as do some security services (e.g., nonrepudiation).  But the danger from re-using pre-IoT workflows is greater than the danger from symmetric-only workflows (if those are done right).

Saying we must have asymmetric crypto for anything IoT creates a wide gap in resource requirements between IoT and 1-2-7 solutions.
That gap will then be filled by more 1-2-7 ****.

I’m not willing to accept this as an inevitable outcome.

Grüße, Carsten

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 10 Jul 2014 14:34:13 +0000

> From: dtls-iot [[email-masked]] on behalf of Michael StJohns [[email-masked]]
> Sent: Thursday, July 10, 2014 8:48 AM
>

The flip side is that the requiring more capable devices slows
and limits market adoption.  You need both minimal security
requirements and minimum required capabilities.  EC public key
is a great hammer, but that doesn't mean that every security
requirement is a nail.

> for years.

I think you are conflating two different arguments.  There has
been arguing going on for years about whether IOT-type devices
can do public key.  I think that argument is over; yes, they can.

The current discussion is on whether or not IOT-type devices can
do per-message public key operations.  That's a very different
question.  There are lots of chips going into light fixtures and
switches today that can do EC public key for joining networks and
establishing connections.  Those are relatively rare events don't
have tight latency requirements.  Those same chips can't do
public key every time a switch wants to turn on some lights.  It
just takes way too long.

At some point better security just costs too much and isn't
adopted.  It may be easier to say "we MUST use public key because
symmetric is just too insecure", but chances are you're not going
to actually meet even minimal cost requirements that way.

It's harder, but we need to consider both risks and costs.

 -Richard Kelsey
This email and any attachments may be confidential. If so, do not distribute or forward this email or any attachments without the sender’s authorization. If you are not the intended recipient, please delete this email and notify the sender. Email transmissions cannot be guaranteed to be error-free or virus-free and Silicon Labs accepts no liability for such transmissions. Silicon Labs does not intend or authorize emails to act as legally binding contracts.

---

From: Rene Struik <[email-masked]>
Date: Thu, 10 Jul 2014 11:00:09 -0400

The following paper may be of interest here: Multicast Security - 
Efficient and Secure Source Authentication (Perrig, Cannetti et al, 
2001). Some of those ideas seem to have found there way into RFC 4082 - 
Timed Efficient Stream Loss-Tolerant Authentication (TESLA) - Multicast 
Source Authentication Transform Introduction (June 2005).

BTW - I tend to agree with Michael St. John's thesis that desired 
functionality and deployment use cases need to drive security 
architectural design. Moreover, it remains to be seen whether arguments 
(that I have seen for at least 15 years now) would remain if one 
considers the cost over the entire lifecycle of a device and/or network 
(including provisioning, device replacement, and ultimately disposal).

Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 10 Jul 2014 15:07:21 +0000

Hi Rene

>
> The following paper may be of interest here: Multicast Security - Efficient and
> Secure Source Authentication (Perrig, Cannetti et al, 2001). Some of those
> ideas seem to have found there way into RFC 4082 - Timed Efficient Stream
> Loss-Tolerant Authentication (TESLA) - Multicast Source Authentication
> Transform Introduction (June 2005).

[SK] We did look at this, and me, Mike and also some others came to the conclusion that the time synchronization does not really work at the higher layers and especially in lossy networks.

>
> BTW - I tend to agree with Michael St. John's thesis that desired functionality
> and deployment use cases need to drive security architectural design.
> Moreover, it remains to be seen whether arguments (that I have seen for at
> least 15 years now) would remain if one considers the cost over the entire
> lifecycle of a device and/or network (including provisioning, device
> replacement, and ultimately disposal).
>
> Rene
>

[SK] Don't get me wrong here, I am not arguing against public key crypto. It has value for certain provisioning scenarios and device replacement where latency is not an issue. I am referring to the use of public key to sign each and every message that is sent.

Sandeep

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Jul 2014 17:22:48 +0200

On 10 Jul 2014, at 16:34, Richard Kelsey <[email-masked]> wrote:

>  whether IOT-type devices
> can do public key

This question is about as useful as the question whether a car can carry a sofa.
Sure, they can (but I may still want to buy one that can't).

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Jul 2014 17:41:55 +0200

> This question is about as useful as the question whether a car can carry a sofa.

Works for class-1 devices, too.

http://metrouk2.files.wordpress.com/2013/03/rtr3et7k.jpg

(BTW, I fully agree with the rest of Richard’s message.)

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Thu, 10 Jul 2014 12:28:49 -0400

On 7/10/2014 11:00 AM, Rene Struik wrote:
> 2001). Some of those ideas seem to have found there way into RFC 4082 
> - Timed Efficient Stream Loss-Tolerant Authentication (TESLA) - 
> Multicast Source Authentication Transform Introduction (June 2005).
>

Hi Rene -

I did take a look at this and at the RFC and the interesting statement 
is (second para of section 3.5 of the RFC)

> Although a newly arriving packet_cannot immediately be
>     authenticated_, it may disclose a new key so that earlier, buffered
>     packets can be authenticated.

Basically, a packet is signed with a key that isn't yet available to the 
recipients and won't be available to the recipients until after its 
utility for signing has expired.  The RFC has a more complete 
description, but that's basically it.  The delay in being able to verify 
things seems to be somewhere around the round trip time for the maximum 
distance from sender to possible recipient.  Maybe manageable for a 
small network with a shallow RF mesh and good loss characteristics.  
Maybe not so much otherwise.

Which seems to be problematic for something like lighting control which 
is looking for small latency between initiation and action. There is the 
other problem that Sandeep mentioned as well - that of trying to keep 
the mesh time synchronized within tolerances.

It's an interesting idea in theory - less so in practice.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Thu, 10 Jul 2014 12:52:19 -0400

> [SK] Don't get me wrong here, I am not arguing against public key crypto. It has value for certain provisioning scenarios and device replacement where latency is not an issue. I am referring to the…

Let me be clear here.  I'm not and have never advocated the use of 
public key for each and every message, but for each and every 
*multicasted* *control* message.

Just how many times a second do you think you'll be turning on and off 
those lights?  A quick survey of the literature suggests that for some 
of the possible EC curves you can do a verification in about 250ms even 
for extremely constrained devices without any special hardware.  With 
purpose built hardware that drops to less than 100ms.  In either event 
call it 4 control actions per second.

For the non-control multicasted traffic I've seen no evidence that 
spending the resources to encrypt and mac them makes any sense give the 
low bar to hacking.

For control or non-control unicast traffic, symmetric key (with a 
negotiated key ala DTLS) encrypt/mac makes perfect sense.

Mike

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Jul 2014 20:28:14 +0200

Hi Richard,

On 07/10/2014 04:34 PM, Richard Kelsey wrote:
> and limits market adoption.

I think that this seems to be the core argument. Unfortunately, it is
somewhat hard to argue about it.

The cost of a product, particularly for small start-ups, is a complex
topic. The volumes for many IoT products sold today is rather small
since these products obviously address a very specific class of
customers. Not everyone wants to control fans via smart phone apps,
track their dog/cat, or have an Internet enabled fridge. So, there is a
premium you have to pay for these gadgets.

Often, the development cost dominates. That might change in the future
once it gets easier to use Internet stuff on these embedded devices and
meets the mental model of engineers working at those companies. We are
obviously not there yet.

Even hardware cost is not just about the cost of a single chip but you
might have to design the PCB, talk to many vendors to get the different
parts, etc.

Of course the security of many products isn't great (as you can see in
news articles). However, this can hardly be attributed to the hardware
capabilities but rather to the skill set of the engineers working for
those companies.

Whether the use of asymmetric crypto vs. symmetric crypto (from the
difference in hardware cost) makes the difference for the success of a
product is a bit hard to say but I doubt it. In my recent experiments
with generating public/private key pairs on low-end ARM platforms
(Cortex M0) told me that this is a piece of cake.

I don't know how to any make progress on this topic. I could ask one of
my co-workers to share his insight on cost of hardware and embedded
industry with the rest of the group. This would be one data point. Maybe
there are other companies willing to share their experience.

Ciao
Hannes

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 10 Jul 2014 20:09:14 +0000

> From: Michael StJohns [[email-masked]]
> Sent: Thursday, July 10, 2014 12:52 PM
>

It's more about latency than throughput.  When someone flips a
switch, how long are they willing to wait before the light comes
on?  The use cases I have seen have this at most 500ms and often
less (people are conditioned to expect the performance of wired,
incandescent bulbs).  250ms for verification leaves far too little
time for signing and message propagation.  Even 100ms each for
signing and verification is likely to be a problem if the message
has to go multiple hops over, say, 802.15.4.  In addition to being
harder for security, multicasts also tend to take longer to propagate.

-Richard Kelsey

---

From: Michael StJohns <[email-masked]>
Date: Thu, 10 Jul 2014 18:10:44 -0400

> harder for security, multicasts also tend to take longer to propagate.

So to translate to mike speak - what you're saying is that there's a 
certain budget, and all of the budget has been taken up by multicast 
transmission so we can't spend more than a pittance on multicast 
security. Hmm....

Have you considered that for most commercial lights, the latency for 
going from off to on is usually in the 1-2 seconds range making the 
latency of both transmission and verification in the noise?  (I've 
replaced most of my floods with LED - there's a noticeable delay - call 
it 750ms - between throwing the switch and having the light turn on - 
and let's not even talk about CFL - so the latency comment probably 
applies to consumer products in the home as well).

Have you considered that for consumer products in the home, you get much 
more  protection from your firewall and from your RF link layer security 
mechanisms than you would get from pretty much any symmetric key 
multicast solution so why bother?

Mike

---

From: Don Sturek <[email-masked]>
Date: Thu, 10 Jul 2014 15:26:56 -0700

Hi Mike,

Having worked on a few of these applications particularly with residential
lighting companies, the generally accepted latentcy from throwing the
switch to having the light come on (or some action taking place) is 250
ms.  More than that invites the person to try again.........

Don

On 7/10/14 3:10 PM, "Michael StJohns" <[email-masked]> wrote:

>> This email and any attachments may be confidential. If so, do not
>>distribute or forward this email or any attachments without the sender¹s
>>authorization. If you are not the intended recipient, please delete this
>>email and notify the sender. Email transmissions cannot be guaranteed to
>>be error-free or virus-free and Silicon Labs accepts no liability for
>>such transmissions. Silicon Labs does not intend or authorize emails to
>>act as legally binding contracts.

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 10 Jul 2014 22:38:18 +0000

> -----Original Message-----
> From: dtls-iot [mailto:[email-masked]] On Behalf Of Michael
> StJohns
>
> So to translate to mike speak - what you're saying is that there's a certain
> budget, and all of the budget has been taken up by multicast transmission so
> we can't spend more than a pittance on multicast security. Hmm....
>
> Have you considered that for most commercial lights, the latency for going
> from off to on is usually in the 1-2 seconds range making the latency of both
> transmission and verification in the noise?  (I've replaced most of my floods
> with LED - there's a noticeable delay - call it 750ms - between throwing the
> switch and having the light turn on - and let's not even talk about CFL - so the
> latency comment probably applies to consumer products in the home as
> well).
>
[SK] Richard is right in terms of latency expectations that the industry wants to achieve with such systems. There will always be manufacturers who will not manage to get those results and consumers willing to (or rather unwillingly)  buy them, but that’s a completely different issue. You may not see much annoyance now, but get some dimmable light and try dimming to the required level with that latency, you can spend some fun time dimming up and down.

> multicast solution so why bother?
[SK] Sure the RF link provides security however this is shared with all the other Internet connected devices at home/office. A weakness in one would mean that everything else is affected. I would rather have one more additional layer (maybe weak) as a buffer to virtually separate the traffic on the same link. As more devices connect externally and are controlled from the backend clouds, I really do not think that just link layer security would be enough when they all share the same link.

>
> Mike
>
>
>
> >
> > -Richard Kelsey
> > This email and any attachments may be confidential. If so, do not distribute
> or forward this email or any attachments without the sender’s authorization.
> If you are not the intended recipient, please delete this email and notify the
> sender. Email transmissions cannot be guaranteed to be error-free or virus-
> free and Silicon Labs accepts no liability for such transmissions. Silicon Labs
> does not intend or authorize emails to act as legally binding contracts.

---

From: Rene Struik <[email-masked]>
Date: Thu, 10 Jul 2014 20:14:39 -0400

Hi all:

I think this discussion would benefit from less position-based arguing 
and more of a fine-grained, analytical approach that stipulates 
communication and computational time latencies expected, expected packet 
sizes, potential fragmentation/re-assembly, and the-like. Right now, it 
is not even clear to me that the time latencies with multi-hop 
communications will be dominated by security-related aspects (with 
6TiSCH, time slot spacing may dominate propagation effects, for example, 
and Richard Kelsey's email suggested [from my understanding] that 
multicast may consume quite a bit of the "time latency budget").

Just a pragmatic note:
a) with signed messages in use case scenarios where state changes can be 
reversed without too much impact (as seems the case with lighting), one 
can already act on a received message presuming source authentication 
and revert this once one finds out signature verification fails. This by 
itself may make computational time latencies vanish from a human 
experience perspective (except, perhaps, when packets are spoofed). 
{Obviously, this approach should not be tried with critical 
infrastructure (or other non-reversible state change scenarios).}
b) when signing a message, most computations are intrinsically offline 
computations and can be anticipated.
Note: Obviously, a) also applies if one simply uses a message 
authentication code, but then authentication is relative to a random 
group member.

So, there are simple tricks one can do to make life easy, even when one, 
at first thought, balks at *perceived* cost.

I only gave the examples above as reminder that, please, let us try and 
be a little bit creative over here!

There are other schemes that are really efficient, cryptographically 
sound, and also work in non-reversible uses cases (such as critical 
infrastructure). For those, please contact me offline and we will work 
on those.

Best regards, Rene

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Jul 2014 20:47:40 -0400

Michael, I would definitely like your view on draft-richardson-6tisch-security-6top.

It uses asymmetric crypto and 802.1AR certificate chains (anchored at the
manufacturer) to do secure enrollment; the final goal of which is to
facilitate a CoAP/DTLS provisioning connection.  The provisioning connection
can provision symmetric groups keys (akin to "WPA-PSK" / network password),
symmetric authorization tokens, or locally rooted assymetric certificates.

My take is that even if a device can not regularly do assymetric operations,
it can probably do so at least once or twice during enrollment.

Any resemblance to the Behring/Pritikin autonomic drafts is purely
intentional, and the next revision will address stuff like co-authors and
acknowledgements properly.   Any resemblance to Cullen/Cisco's presentation
at the Smart Objects Security workship is also intentional; it is just that
we felt that EAP/TLS involved EAP, PANA and TLS: three protocols which 
would not otherwise be required.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael StJohns <[email-masked]>
Date: Thu, 10 Jul 2014 21:51:16 -0400

> would not otherwise be required.

I'll take a look.  Where would you like me to send comments?

Mike

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 11 Jul 2014 10:38:17 +0200

Hi all,

In support of Rene’s mail, I just wanted to stress that we use a similar approach at STMicroelectronics in France with pre-signed/pre-verified objects and group keys. Your light bulb then only needs to check if the received command (signed object) is identical to the one cached in memory.

Obviously, if one considers compromised nodes within the group, an attacker may replay the signed command on behalf of the source and change the destination state.

Depending on your network capabilities, to reduce the attacker’s gain in that case, one could:

- Include an expiry date within the signed command, if time synchronization is available.
- If no time synchronization is available, play with sequence numbers, again within the signed command and declare that a command with the same sequence number can be used for at most N state changes at destination (cache hits). 

Essentially, the cost of the verification is then amortized either over N commands or over the expiry interval. On the source side, as Rene said, signing can be well anticipated such that it does not affect the latency.

The idea and the approach are described in our OSCAR paper: http://arxiv.org/abs/1404.7799

Best regards.
Mališa Vučinić

On 11 Jul 2014, at 02:14, Rene Struik <[email-masked]> wrote:

> Hi all:
> 
> I think this discussion would benefit from less position-based arguing and more of a fine-grained, analytical approach that stipulates communication and computational time latencies expected, expected packet sizes, potential fragmentation/re-assembly, and the-like. Right now, it is not even clear to me that the time latencies with multi-hop communications will be dominated by security-related aspects (with 6TiSCH, time slot spacing may dominate propagation effects, for example, and Richard Kelsey's email suggested [from my understanding] that multicast may consume quite a bit of the "time latency budget").
> 
> Just a pragmatic note:
> a) with signed messages in use case scenarios where state changes can be reversed without too much impact (as seems the case with lighting), one can already act on a received message presuming source authentication and revert this once one finds out signature verification fails. This by itself may make computational time latencies vanish from a human experience perspective (except, perhaps, when packets are spoofed). {Obviously, this approach should not be tried with critical infrastructure (or other non-reversible state change scenarios).}
> b) when signing a message, most computations are intrinsically offline computations and can be anticipated.
> Note: Obviously, a) also applies if one simply uses a message authentication code, but then authentication is relative to a random group member.
> 
> So, there are simple tricks one can do to make life easy, even when one, at first thought, balks at *perceived* cost.
> 
> I only gave the examples above as reminder that, please, let us try and be a little bit creative over here!
> 
> There are other schemes that are really efficient, cryptographically sound, and also work in non-reversible uses cases (such as critical infrastructure). For those, please contact me offline and we will work on those.
> 
> Best regards, Rene
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Jul 2014 11:06:57 +0200

On 11 Jul 2014, at 02:14, Rene Struik <[email-masked]> wrote:

> Richard Kelsey's email suggested [from my understanding] that multicast may consume quite a bit of the "time latency budget").

FYI: We may not yet have the right kind of “multicast” for this application in constrained node networks (I think Richard was thinking about trickle-multicast, which is more about information dissemination than about real-time performance).  So that may be fixable.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Jul 2014 10:39:58 -0400

Michael StJohns <[email-masked]> wrote:
    msj> Have you considered that for most commercial lights, the latency for

Yes, we can argue the story for changing the budget, but I'm pretty sure that
someone will come up with other use cases where push the budget harder.

    msj> Have you considered that for consumer products in the home, you get
    msj> much more protection from your firewall and from your RF link layer
    msj> security mechanisms than you would get from pretty much any
    msj> symmetric key multicast solution so 
    msj> why bother?

This is the orange-peel/coconut security argument.   It's what gave us ten
years of insecure desktops despite a 2yr replacement cycle during that period
of time.   The RF mesh layer security is going to be pretty porus in the
home: adding new devices regularly, throwing them out, lending them to your
neighbour, changing houses, etc.  

I think that we can find a symmetric multicast security system that uses
asymmetric for bootstrap.  Some of the smallest devices might still want help
on the asymmetric stage, which means they might not be touch less, but I
think the market will select against them.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 11 Jul 2014 11:24:54 -0400

Hi Hannes,

> Date: Thu, 10 Jul 2014 20:28:14 +0200
> From: Hannes Tschofenig <[email-masked]>
> 

I agree that it is hard.  The alternative is for us to
continue repeating 'is not'/'is too', which doen't get
us anywhere.

> might have to design the PCB, talk to many vendors to get the different

There are a number of large companies producing IOT-type devices
in high volume.  From talking to a sales engineer here, the big
concerns are cost and power consumption.  They'll pay for a 24mhz
or so Cortex and be willing to power it long enough to get a
message out.  Getting more processing power or energy is not a
realistic option.  Pennies matter to these folks.

Obviously, there are and will be other manufactuers and other
products.  My point is that there are millions of IOT-type
devices being made today that don't have the resources to use
public key operations when turning on a light, and that adding
those resources would cost a prohibitive amount.

I understand the benefits of using public key to sign multicast
messages.  We need to have a symmetric option as well.

> capabilities but rather to the skill set of the engineers working for

And to the companies' general level of investment in security.
My experience is that lots of product people don't see any 
point is spending anything on security, let alone adding
significantly to the BOM cost or reducing battery life.  It's
a struggle.

  -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Jul 2014 17:38:46 +0200

On 11 Jul 2014, at 17:24, Richard Kelsey <[email-masked]> wrote:

> there are millions of IOT-type
> devices being made today

I think some of the confusion here is that there is a large-volume market segment that is operating behind the scenes, and then there is a flashy “Internet of Things” market segment in the yellow press, with power sockets running Linux (I kid you not).  The latter of course have no problem at all running complex software (of course, their current security is invariably as shoddy as can be despite their steep BOMs).

If your perceptions are based on the flashy $40-$200 devices, it may be hard to appreciate that there also is a penny-conscious market.  In the end, it is that market that we need to address, to make a true Internet of Things a reality*).  Shutting out that market by insisting on expensive technology choices is not an option.

Grüße, Carsten

*) Do the math: 200 billion $40 devices? Just won’t happen.

---

From: Rene Struik <[email-masked]>
Date: Fri, 11 Jul 2014 12:16:24 -0400

Hi Carsten:

Any major uptake of sensor networks (towards the 30-50 billion devices 
Intel and Cisco refer to, or the 200 billion devices you seem to 
predict) depends on proper security underpinnings that support flexible 
deployment.

The per-device cost of implementing cryptograpic building blocks (block 
cipher, scalar multiplication unit, random number generator, perhaps PUF 
technology) is really low and will turn out to be a commodity element 
(please see Jari Arkko's and your own slides of the Smart Object 
Workshop 2012, which show crypto cost is only a small portion of, e.g., 
DTLS code size). So, I am somewhat surprised by references to 
"inappropriate technology choices" and "steep BOM" here.

The main impetus does not seem to be crypto cost, but resistance to 
change, as Richard Kelsey already pointed out in his email earlier this 
morning, Fri July 11, 2014, 11:24am EDT:

    "And to the companies' general level of investment in security. My experience is that lots of product people don't see any point is spending anything on security, let alone adding significantly to the BOM cost or reducing battery life.  It's a struggle."

If 802.15.4 chips already ship with AES hardware support for 10 years, 
it should not be too hard to add some field arithmetic for crypto as 
well. (If people do  not understand crypto, they can simply reach out to 
people who do.)

The real culprit in these discussions popping up again and again may 
very well be that one cannot convince one's own managers and may have 
nothing to do with technology cost at all.

Best regards, Rene

On 7/11/2014 11:38 AM, Carsten Bormann wrote:
> I think some of the confusion here is that there is a large-volume market segment that is operating behind the scenes, and then there is a flashy "Internet of Things" market segment in the yellow press, with power sockets running Linux (I kid you not).  The latter of course have no problem at all running complex software (of course, their current security is invariably as shoddy as can be despite their steep BOMs).
>
> *) Do the math: 200 billion $40 devices? Just won't happen.
>

---

From: Rene Struik <[email-masked]>
Date: Tue, 22 Jul 2014 12:14:07 -0400

Hi Sandeep:

As already suggested, it would be good to have more insight into your 
real constraints (e.g., is 25ms computational latency okay, etc.). {So 
far, I have not seen this.}

Let us then come up with a scheme that works in your context.

This is relevant to your multicast drafts that are on the DICE agenda 
for this afternoon; hence, the reminder.

Best regards, Rene

On 7/10/2014 8:14 PM, Rene Struik wrote:
> communication and computational time latencies expected, expected 
> packet sizes, potential fragmentation/re-assembly, and the-like. Right 
> now, it is not even clear to me that the time latencies with multi-hop 
> 6TiSCH, time slot spacing may dominate propagation effects, for 
> example, and Richard Kelsey's email suggested [from my understanding] 
> that multicast may consume quite a bit of the "time latency budget").
>
> Just a pragmatic note:
> a) with signed messages in use case scenarios where state changes can 
> be reversed without too much impact (as seems the case with lighting), 
> one can already act on a received message presuming source 
> authentication and revert this once one finds out signature 
> verification fails. This by itself may make computational time 
> latencies vanish from a human experience perspective (except, perhaps, 
> when packets are spoofed). {Obviously, this approach should not be 
> tried with critical infrastructure (or other non-reversible state 
> change scenarios).}
> So, there are simple tricks one can do to make life easy, even when 
> one, at first thought, balks at *perceived* cost.
>
>>> certain
>>> going
>> [SK] Richard is right in terms of latency expectations that the 
>> industry wants to achieve with such systems. There will always be 
>> manufacturers who will not manage to get those results and consumers 
>> willing to (or rather unwillingly)  buy them, but that’s a completely 
>> different issue. You may not see much annoyance now, but get some 
>> dimmable light and try dimming to the required level with that 
>> latency, you can spend some fun time dimming up and down.
>>
>> [SK] Sure the RF link provides security however this is shared with 
>> all the other Internet connected devices at home/office. A weakness 
>> in one would mean that everything else is affected. I would rather 
>> have one more additional layer (maybe weak) as a buffer to virtually 
>> separate the traffic on the same link. As more devices connect 
>> externally and are controlled from the backend clouds, I really do 
>> not think that just link layer security would be enough when they all 
>> share the same link.
>>
>>
>>> Mike
>>>
>>>
>>>
>>>> -Richard Kelsey
>>>> distribute
>> 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.