Re: Security for the Internet of Things and Other Things (Was: Re: Observations on (non-technical) changes affecting IETF operations)

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 10 March 2016 04:43 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F27112D595 for <ietf@ietfa.amsl.com>; Wed, 9 Mar 2016 20:43:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level:
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 eBpeDGnOLvfM for <ietf@ietfa.amsl.com>; Wed, 9 Mar 2016 20:43:44 -0800 (PST)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92C412D837 for <ietf@ietf.org>; Wed, 9 Mar 2016 20:34:52 -0800 (PST)
Received: by mail-lb0-x229.google.com with SMTP id bc4so95098362lbc.2 for <ietf@ietf.org>; Wed, 09 Mar 2016 20:34:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=aYwxU1CPFfhlUPaKqSizVVnZValucMnqoi8IwBzzVhA=; b=tOu/rtCNwgz50nEvbysOFzGPpUDYWFz+2tFDxv1kV3E41f/cKKmeWPKhg8ov72O8fX Eb9clxk1VQkuAJD6inqtI1LGlo7Wy+ri/iL9lp0lteVGoiTu/s51DfRe3uu+DTMgRRa2 lwxnEz5M3Il9I3RaJUEY3kuLK65/Dv9GWoNrtkUZkeWFYtpnWFr90vnV9nObnt7c4edO 8fI4MQyC1/TN5Q//xIILOMuh5+W6VyJPgZqLpCtWo/UGwiRUKTeAT8e7sD3bTi3Rx9d9 Hl3PvCGqQLgVvF1LeNc4Nz4hXD+XYzmgaXXovIhEi1L2HAHoD4b4UAdDoYoKXTcmd1Wa 8WLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=aYwxU1CPFfhlUPaKqSizVVnZValucMnqoi8IwBzzVhA=; b=QglZF3H+I9hXGckQiCbbio039n9AoSYc9gw6jWStQ96p8jIFlKoYjEWlxYcQcHLP6j 98aDBvEErHOJG0WlNlmIJllJBeVS6eFl6D3GMDrwj/keIjo3qM1d3cVZe6OgO6SwYS/j Kwlw9l/3hzEpH26tzqvzAAQZtPXbDhpc40GxcqhOc+kuQvjy15kKx7Q8fP+RuNQVj3sQ TgeoclAx99NXJc5qoAj65UaHT8ki1+T5DqLSo99VqOMYDLKryPmP6jKvERP2zfDiOCNw HNZfqA9j6w9ppvRSo2v1eBLfzBkk7bl3M3uOROgopEPkX0oXJiU99WOqboQrcnltdmaw RWqQ==
X-Gm-Message-State: AD7BkJLfL0ahHH76vxW98xTf1u7jr5S5tkvTQzDaQXS1IYB1e7Dx6faJXpCxibrOUATCiNrQ459w0z4jBvg3sg==
MIME-Version: 1.0
X-Received: by 10.112.140.129 with SMTP id rg1mr472474lbb.80.1457584490785; Wed, 09 Mar 2016 20:34:50 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.151.67 with HTTP; Wed, 9 Mar 2016 20:34:50 -0800 (PST)
In-Reply-To: <D305C9B8.12B536%jason_livingood@cable.comcast.com>
References: <E83FC2B4-867D-44C9-AE1B-F4C414ABD041@piuha.net> <4A95BA014132FF49AE685FAB4B9F17F657DF2330@dfweml701-chm> <EDFB7D0B-2A49-46BD-A84C-0E1FA07793FA@piuha.net> <20160307133944.GB25576@gsp.org> <56DD876C.6050008@cs.tcd.ie> <CAMm+LwiBT9S-twGVzC-7yVBZ9dHA3+8f4ffPv3LyoZ_8+kdqmw@mail.gmail.com> <32C28750-37FF-4EDC-B0A8-A532B175C201@piuha.net> <9806.1457534345@obiwan.sandelman.ca> <D305C9B8.12B536%jason_livingood@cable.comcast.com>
Date: Wed, 09 Mar 2016 23:34:50 -0500
X-Google-Sender-Auth: xVVH99UZHjXkFILSA0Eo9kAJKG0
Message-ID: <CAMm+LwhC7zW8L+he7NkiZycbEWczAwth=i7giUTWzY_t0NsEaQ@mail.gmail.com>
Subject: Re: Security for the Internet of Things and Other Things (Was: Re: Observations on (non-technical) changes affecting IETF operations)
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "Livingood, Jason" <Jason_Livingood@comcast.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/U_BON93XY70O93eDahyq0O834qE>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, IETF <ietf@ietf.org>, Rich Kulawiec <rsk@gsp.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2016 04:43:46 -0000

On Wed, Mar 9, 2016 at 12:41 PM, Livingood, Jason
<Jason_Livingood@comcast.com> wrote:
> Sure, WiFi security is an issue for IoT. But there are probably much more
> fundamental IoT security issues. IMHO I think one of the largest is the
> lack of a secure & automatic (no end user interaction) software update
> channel.

I think Jari has a very different set of concerns to mine.

My first concern is to bind a device to my portfolio in such a way that:

* The device can recognize data (commands, requests, data) from other
devices in my portfolio as such

* Other devices in my portfolio can recognize that device.


So in PKI terms, what I need to achieve is to 1) install my personal
root of trust onto that device and 2) sign the cryptographic public
keys of the new device with an administration key authorized for that
purpose under my personal root of trust.

If I can achieve those two things, I have a framework of trust that I
can then leverage to securely support any machine configuration or
management operation. I could send the device a message to the effect
'download and install the latest BIND updates, check the sigs match
this root, signed <me>'

Once you have bilateral authentication, many things that are now
complex become straightforward.


Now that is not all I would want from a software update scheme. I
would probably want to have some mechanism that makes it possible to
know that updates exist, that this is the latest one. And that leads
to blockchain like constructs. I am probably also going to want some
means of engaging a third party to curate updates for me. For example,
check that the patch works on my devices. If I have redundant systems,
I certainly don't want them both to patch at the same time.


If I get the binding I describe, all things become possible. But
achieving that binding requires a communication of some sort between
my devices. And that gets me into a bootstrap problem. How does my
device know what the network configuration parameters are to connect
to the network and download the parameters?

Yes, this can be made easy but I have yet to see it made easy in
practice. Once upon a time, my Linksys boxen came with a button that
was 'all I needed to press' to connect up a device. Only it didn't
work because I would have to download the proprietary software drivers
to make it work with their PCMCIA cards.

I am pretty uncompromising where ease of use is concerned. This is not
a problem I have seen any commercial product solve to my satisfaction
to date.