Re: [Dtls-iot] DTLS multicast security

Michael StJohns <msj@nthpermutation.com> Tue, 23 September 2014 16:26 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93D01A8721 for <dtls-iot@ietfa.amsl.com>; Tue, 23 Sep 2014 09:26:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT7cjQtkIDBl for <dtls-iot@ietfa.amsl.com>; Tue, 23 Sep 2014 09:26:45 -0700 (PDT)
Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D101A86ED for <dtls-iot@ietf.org>; Tue, 23 Sep 2014 09:26:45 -0700 (PDT)
Received: by mail-qg0-f50.google.com with SMTP id q107so4750544qgd.9 for <dtls-iot@ietf.org>; Tue, 23 Sep 2014 09:26:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3Ab2ra9YUduY9kMQQUSFeQpFYQTCAa7+CrmvRPIy0d4=; b=fKJirLuB1xopint4Wb08WPQNIMSnSCOmGNy+b0qUUQVmGAe/t0bRTkCbvhBeo/r+pP MfBUMJC407HWlcz5QnpOKZcCYbsQy/0IykzfDHoTCWTyM5wGTNsVj+8TvR6MHBlXkwKZ vkM+ap6uiZo5WzLd+60bydPKyJz664HmLwzjJNbB6aihlqSoEy3CqEdQvrVQyfjAAAUb YWZR5kLFxsto2IVj8ropjtx63CTyygJ2xW9M8W3TY5o6mGt1mFRZR5YvXqN3Luz2JIbX QM3yPP4da24BGMVLXhq6eSsPfj/1I16SJCpUL1q8WtJbEAqx9afd7ghG59aPeJEqjIho 1GXw==
X-Gm-Message-State: ALoCoQng3eT71nqXX4pcWjwkPZiYywnmEeJwCj4LZg6yDFmdU3fsdxR0/STrKNiy1/5wVjylD5Wj
X-Received: by 10.140.21.85 with SMTP id 79mr840330qgk.69.1411489604146; Tue, 23 Sep 2014 09:26:44 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:226:b4b7:cac9:c25a:2d51? ([2601:a:2a00:226:b4b7:cac9:c25a:2d51]) by mx.google.com with ESMTPSA id h91sm10609961qge.38.2014.09.23.09.26.43 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Sep 2014 09:26:43 -0700 (PDT)
Message-ID: <54219F43.30004@nthpermutation.com>
Date: Tue, 23 Sep 2014 12:26:43 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Stefanie Gerdes <gerdes@tzi.de>, Carsten Bormann <cabo@tzi.org>
References: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> <541BD0E0.1090409@sics.se> <36F5869FE31AB24485E5E3222C288E1FFAFA@NABESITE.InterDigital.com> <541C452D.9090302@nthpermutation.com> <EBE85F86-00E2-40F8-9205-1B6AE20CAAE9@tzi.org> <541C5336.9040406@nthpermutation.com> <394E30E1-378D-4F37-B86D-F05297A2D8B6@tzi.org> <541C5B46.8060406@nthpermutation.com> <2819E45A-6B1B-4B14-8A7E-3B9358AA3B12@tzi.org> <541C6BC5.7070308@nthpermutation.com> <5420517B.60502@tzi.de> <54206086.1040707@nthpermutation.com> <54214ED3.9020104@tzi.de>
In-Reply-To: <54214ED3.9020104@tzi.de>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/Bzis8iSYfzWvOFgC28S3gT8sDMs
Cc: dtls-iot@ietf.org
Subject: Re: [Dtls-iot] DTLS multicast security
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Sep 2014 16:26:48 -0000

On 9/23/2014 6:43 AM, Stefanie Gerdes wrote:
> Hi Michael,
>
> On 09/22/2014 07:46 PM, Michael StJohns wrote:
>>
> So OE is only okay as long as a sender does not care about it or is not
> sure if it is there? That seems difficult to assure.

Wow.  How did you get there?

The characteristic of OE is that the traffic is going to be sent 
regardless of any protections.  The sender may flip a bit, his system 
may be configured to flip a bit or a border box may be configured to 
flip a bit - said bit causing OE to happen.

Think about sending a letter - some end up in locked mailboxes at the 
recipients apartment, others are thrust into mailboxes that abut a 
street.  The sender generally has no idea of the at rest protections 
that will be applied to the letter he's sending, but he sends it 
anyways.  Think about how your cell phone conversation is encrypted 
between your cell and the cell tower, but not end to end. Most people 
making calls don't actually understand that their calls are unprotected 
on the hard wire.

There are a lot of similar analogies.  It's not that OE is OK if the 
sender doesn't care, its that OE MAY improve one tiny little piece of 
the security and the applying it or not does not generally change the 
equation with respect to whether the transmission happens or not.

>
> I don't think that authorization necessarily requires a unique identity.
> My (physical) door key has no identity attached to it. I only give it to
> people that are allowed to enter my home. As long as the key is not lost
> or stolen there is no problem with that. Companies may want to authorize
> all their employees to open the door to the company building. In this
> case, the authorization is based on their employment. The important
> point for the door is if they are authorized to enter.

This is where people get confused about authorization and 
authentication.  In digital security terms, the person is using your 
authentication and authorization as a proxy.  Also, it's trivially easy 
to replicate a physical key, so the authorization and authentication 
aspect breaks down quickly.  For example, I have a key, I get fired, I 
tell them I lost the key, but there are 100s of them out there so they 
don't rekey.

The physical world is not an exact analog for the digital world. A 
better analog is a company that's replaced the keyed door locks with 
those that respond to swipe or RFID cards.  The cards are unique and the 
authorization to enter the building is tied to the card.  The employment 
status is irrelevant to the system (e.g. contractor, building 
maintenance staff, caterers etc), but may be relevant to the person 
managing the system (when adds/deletes are done).
>
> If the company hands out individual digital keys to its employees and an
> attacker manages to steal only one of the keys, he is able to enter the
> building with it. Unique identities cannot prevent that.
Nope.  But the revocation of the unique digital identity is a hell of a 
lot easier than revoking a single key used by 100s.  Also the guy losing 
the key is going to report it quickly - if for no other reason that to 
limit his liability.  Lose a common key, physical or digital and there's 
no incentive to report how you screwed up.


>
>> Using symmetric key multicast keys as your credentials for that means
>> that you can never be sure of the identity of the sender.  You know only
>> that whoever sent the multicast packet had a copy of the multicast key.
>> So while you might have thought that only the control station
>> (lightswitch, access control panel, utility panel) was turning things on
>> and off, in reality it could be anyone including someone who hacked your
>> simple lightbulb that shared keys with your door locks.
> If I use a key for authenticating a sender, the receiver always only
> knows that the sender has this key. There is no difference between
> symmetric and asymmetric keys. If a key is stolen, the thief can use
> this key to pretend to be someone else. No difference there, either.

In two party symmetric systems (not N party), the guarantee is "only two 
people share this key, I'm one of them and A is the other.  I didn't 
send it, so A must have, or he was hacked".

In a control model in a two party symmetric system where the key is used 
to have A order B to do something, then breaking in to A or breaking in 
to B is no worse than stealing the key.  In an N party system where A is 
the controller and B-F are actuators, then breaking in to F allows you 
to order B-E around even though F wasn't designated as a controlling node.

In an asymmetric system, I have to break into one specific device - A - 
to use the private key.  Breaking into F does not give me the 
credentials to control B-E.

>
> The difference in your scenario is that there are different sets of
> permissions bound to a single key. A control station might have
> different permissions than a lightbulb. If the lightbulb has the same
> permissions that means that it can act as a control station.
>
> If an attacker steals a key that has too many permissions bound to it,
> it can do more harm with it. That is again true for both symmetric and
> asymmetric keys.
>
> So if I understand your problem right you are suggesting that device
> owners will have more difficulties to do authorization right when they
> are using symmetric keys.

No, I'm actually not.  This is crypto 101.  The guidelines for symmetric 
keys is that you share them between at most two entities. For asymmetric 
keys, the private key is never shared.   If you follow these guidelines, 
you have a pretty good idea of who "signed" a control message.  If you 
don't, then you're screwed and it has nothing at all to do with whether 
or not your controller remains secure.

I'm specifically saying that using multi-party symmetric keys to do 
control actions is insecure out of the box.  For absence of doubt, that 
applies whether we're talking multicast or using the same key for 
multiple unicast messages.

To continue, in general, using multi-party symmetric keys for 
confidentiality is ALSO a bad idea.  For multicast, its only slightly 
less of a bad idea because the compromise of the node with the multicast 
key, gets you the data being sent with the multicast key anyways.  
Multiparty symmetric keys provide no authentication of sent data.  2 
party symmetric keys provide authentication that the other holder of the 
key - to the extent he or I haven't been compromised - sent the data 
that I received under that key.

>
> It might in theory be easier for a device owner to bind the right
> permissions to a key that strictly belongs to an identified device. But
> what does identity mean for a constrained device? An ID is not that
> meaningful for authorization. The type of the device might be
> meaningful, e.g. only switches must be allowed to access lightbulbs. I
> wonder if it is less likely in this scenario that a device owner will
> give all his devices the same permissions.
>
> I learn from this that access permissions must be granted using the
> need-to-know principle (each device must only have the permissions it
> needs to fulfill its tasks) to mitigate the risk from a compromised
> device. Whether or not it is more likely that an owner is unable to do
> authorization right for symmetric or asymmetric scenarios I am not so sure.
>
> Steffi

You need to go back an review role based authorization vs identity based 
authentication.  They are different.  I can have many many 
lightswitches, but the one at the top of my stairs is unique.  And 
should only be controlling the lights on my top landing.  I might have a 
lightswitch with a role of "master controller" that can turn on and off 
all the lights in my house, and tie the "master controller" 
authorization to that privilege in each light switch, but that's 
different from a) the identity of the light switch, and b) the 
assignment of the role of master controller to that lightswitch.

Later, Mike