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 <rstruik.ext@gmail.com> 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
> 
> 
> On 7/10/2014 6:38 PM, Kumar, Sandeep wrote:
>> 
>>> -----Original Message-----
>>> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] 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.
>> 
>>> 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?
>> [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.
>>>> _______________________________________________
>>>> dtls-iot mailing list
>>>> dtls-iot@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dtls-iot
>>> _______________________________________________
>>> dtls-iot mailing list
>>> dtls-iot@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dtls-iot
>> ________________________________
>> 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.
>> _______________________________________________
>> dtls-iot mailing list
>> dtls-iot@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtls-iot
> 
> 
> -- 
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
> 
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot