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
- [Dtls-iot] DTLS multicast security Dorothy Gellert
- Re: [Dtls-iot] DTLS multicast security Ludwig Seitz
- Re: [Dtls-iot] DTLS multicast security Kumar, Sandeep
- Re: [Dtls-iot] DTLS multicast security Rahman, Akbar
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Rahman, Akbar
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Rahman, Akbar
- Re: [Dtls-iot] DTLS multicast security Carsten Bormann
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Nelson B Bolyard
- Re: [Dtls-iot] DTLS multicast security Carsten Bormann
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Kumar, Sandeep
- Re: [Dtls-iot] DTLS multicast security Carsten Bormann
- Re: [Dtls-iot] DTLS multicast security Dorothy Gellert
- Re: [Dtls-iot] DTLS multicast security Dorothy Gellert
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Kumar, Sandeep
- Re: [Dtls-iot] DTLS multicast security peter van der Stok
- Re: [Dtls-iot] DTLS multicast security Stefanie Gerdes
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Kumar, Sandeep
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Ludwig Seitz
- Re: [Dtls-iot] DTLS multicast security Stefanie Gerdes
- Re: [Dtls-iot] DTLS multicast security Kumar, Sandeep
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Dorothy Gellert
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Dorothy Gellert
- Re: [Dtls-iot] DTLS multicast security Kumar, Sandeep
- Re: [Dtls-iot] DTLS multicast security Dorothy Gellert
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Kumar, Sandeep
- Re: [Dtls-iot] DTLS multicast security Michael StJohns
- Re: [Dtls-iot] DTLS multicast security Kumar, Sandeep
- Re: [Dtls-iot] DTLS multicast security Ludwig Seitz
- Re: [Dtls-iot] DTLS multicast security Rahman, Akbar
- Re: [Dtls-iot] DTLS multicast security Carsten Bormann
- Re: [Dtls-iot] DTLS multicast security Sye Loong Keoh
- Re: [Dtls-iot] DTLS multicast security Robert Cragie
- [Dtls-iot] Further analysis of the problem space … Rene Struik
- Re: [Dtls-iot] Further analysis of the problem sp… Michael StJohns
- Re: [Dtls-iot] Further analysis of the problem sp… Dorothy Gellert
- Re: [Dtls-iot] Further analysis of the problem sp… Rene Struik
- Re: [Dtls-iot] Further analysis of the problem sp… Michael StJohns
- Re: [Dtls-iot] Further analysis of the problem sp… Carsten Bormann
- Re: [Dtls-iot] Further analysis of the problem sp… Dorothy Gellert