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

Hannes Tschofenig <> Thu, 24 November 2016 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A838312960D for <>; Thu, 24 Nov 2016 06:10:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.098
X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LPFFZnXNN9xC for <>; Thu, 24 Nov 2016 06:10:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0C1F1293F2 for <>; Thu, 24 Nov 2016 06:10:07 -0800 (PST)
Received: from [] ([]) by (mrgmx003 []) with ESMTPSA (Nemesis) id 0MEnjW-1byK823J4E-00Fzpj; Thu, 24 Nov 2016 15:09:44 +0100
To: Michael StJohns <>,
References: <> <> <> <> <> <> <> <>
From: Hannes Tschofenig <>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <>
Date: Thu, 24 Nov 2016 15:09:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="RFXqaTdSAkWV6BTQEUsE4AU2LgwAAJX4T"
X-Provags-ID: V03:K0:UmVdcAaJhuegtsjZErWuI26zvYoksMoyKazXoM/ejC5aBqvMRXa ScB/syEY+pAXrFY1QDVuKZjpki4wyp+CScq5/I+7Gplt15G8TVF7m97KZqNxKJT4beBRTpV jLZn69IOi/I+O2aeeesLnQALoXBpN/gYIzt4NeE38YOF4ODhJiaHwvzN4wyn5QK8smk1EfC pLiaVM+Kixi2IIdZIwlhg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:5kT+NL60Snw=:T0xd4I2a4czNcM4Oh1Tm5g Ai9AsvNQoI3pfegi3VKzrmfFzXi6whERxapoMyrm6xKUhKh60tXSFWWWOEpbnUd/xr17sS1kV 4YSXDOZaZ+2e5yu7x+Ff5C2VToyFhHgwjtmP81ygEeuXGM0DNQCnihGIgFjSqWnyF8FL45BH3 34t9sIXOudNKinsEPDj6ffu5lx+0BVL0kHIZe6dO5vn02ZG0i7eXcDngNjDodO6UzLq+p2puL SkjspsIgrtCGRe1PZza0L/OVaWSQUBumzXpkI31/IYFZDVvfv1urA5pe6n7wGrjiiHpCMyq3/ Kpum/Mw5OSblKdjMzfOxC+s4Sr2llEPdW4LalS9EhyUtybIJLHBlaV1Ymm4dwF55gMFcxMsBT Y2YhWfSFyNarCkfBLWAyPjPjpXjNcUeKGP1qIcbxxZ+FNHaj/zmd+WgTDFyGfPZ9CX4I5fH1F GFF7cX42T0LUElv4KMKqkqyyq0KXr8bxtdBrRAITy9mSiOIROH6lCHtdE8/96UNAGxXifkDLQ uk3N93poTu6GiL/C/c9BGhoXvov+zm1p/KhbwDcALpf/t8Xv8bzAGrStsjK70qVoEdAX9/FPx ABO3bE4sbjv0vTvdvX8JPXBGCYmqYxMJv5jmWLrwD2NG6LhrEbGdENzlAMdCB/JB7uNsMtnk6 krp+AHQpgSBe+gZHX+B6qW6X7mzNcsctkvFd4mowBgw0ic+oZy0OW7SVVmCBwMQc3BsIazQcQ CA9C1czj/y6RORIVQEVzWjippjNWJbI8eCW2T+xw4BDJI26iwD2DyhUrukJHraB8oqa0ed+oS NgnGA9E
Archived-At: <>
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Nov 2016 14:10:09 -0000

Hi Mike

On 11/17/2016 06:50 AM, Michael StJohns wrote:
> There is no case (absent hardware mitigation) in which a symmetric group
> key solution can be made secure/safe and no one has made an offer of
> proof that they can make it secure.    I've asked repeatedly - no one
> has come forward with more than "oh we can lock the symmetric key stuff
> in a corner and make sure it isn't used for anything important".

Security is not a black and white thing. What has been clear is that any
solution that was proposed for symmetric keys did not meet your

> Given the recent attacks on the internet by IOT botnets, there is a
> further consideration that should be undertaken - whether the symmetric
> group key solution applied to 10s of 1000s of IOT devices is an active
> threat to the rest of the internet (e.g. enabling DDOS, cyber physical
> issues, etc)?

The recent attack was made possible because all devices were provisioned
with the same password, which was publically known.

What we are proposing here is a key distribution protocol where
* each device is provisioned with unique keys (symmetric or asymmetric
* uses those keys to authenticated to the trusted third party (the KDC),
* then gets provisioned with temporary shared secrets for used with
group communication (whereby non-persistent symmetric keys are used for
different groups, keys change over time and where there is an
authorization step before you can join a group).

> The multiparty (group) symmetric key solution is only wanted for a
> single corner of the solution space - low latency, no cost systems. 
> E.g. lightbulbs.  Given there is a worked example of the insecurity of
> multiparty symmetric key systems (e.g. the attack on the symmetric
> signing key of the HUE lights), I'm unclear why anyone at all would
> think that pursuing a known bad solution in the IETF is a good idea.

While the lighting sector is only one part of the IoT industry I think
it is OK to standardize a solution for one industry that consists of
different vendors.

The hack against the HUE lightbulbs you are referring to was also
different. The issue there was that the entire product series was using
the same shared secret provisioned during manufacturing. What we are
doing, however, is to utilize a key distribution protocol to dynamically
create shared secrets. So, each device has unique keys to authenticate
to the KDC and then gets group keys dynamically provisioned. Note that
the security difference here is huge.

I know that you are aware of the differences between the attacks and
what we do in the ACE working group. Hence I am a bit disappointed that
you are trying to make others in the group, who are less knowledgeable
in security, believe that these attacks are actually related.