IETF Logo Mail Archive

Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 22 July 2020 15:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD6D3A0916; Wed, 22 Jul 2020 08:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 6uhuoty_7HGd; Wed, 22 Jul 2020 08:39:55 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3E43A090B; Wed, 22 Jul 2020 08:39:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F7F238A26; Wed, 22 Jul 2020 11:19:26 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2cJHfdR22g9q; Wed, 22 Jul 2020 11:19:25 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 07E2538A24; Wed, 22 Jul 2020 11:19:25 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 322FF1CC; Wed, 22 Jul 2020 11:39:51 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tomas Gustavsson <tomas@primekey.se>
cc: secdispatch@ietf.org, spasm@ietf.org
In-Reply-To: <08ab938b-deee-09f2-697b-657049cc4192@primekey.se>
References: <159176190855.9169.7350787463977998504@ietfa.amsl.com> <10463.1591763623@localhost> <13107.1591804306@localhost> <f7cdd360-7ab7-28f6-86b9-9f8c4ae04aaf@primekey.com> <5843.1591897975@localhost> <092308c1-dc44-4989-e3a5-1a248a3c361e@primekey.com> <20595.1593377487@localhost> <841240ae-f610-dcf8-1e29-c73371ae976b@primekey.com> <22303.1595374300@localhost> <08ab938b-deee-09f2-697b-657049cc4192@primekey.se>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 22 Jul 2020 11:39:51 -0400
Message-ID: <19924.1595432391@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/HL07xO7HRgB7FWlIxunwiscuMO4>
Subject: Re: [Secdispatch] [lamps] IDevID considerations document to secdispatch
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2020 15:39:57 -0000

Tomas Gustavsson <tomas@primekey.se> wrote:
    >> > 2.1.2.  Off-device private key generation
    >> > Typically CA-generates-keystore process. Some protocols, i.e.
    >> > CMP/RFC4210 have standard support for encrypting the private key sent
    >> > back to the client
    >>
    >> I have named this:
    >> a) _factory-generated_ / _mechanically-transfered_
    >> Like a serial console connection, or a JTAG flash writer.
    >>
    >> for b) _factory-generated_/ _network-transfered_
    >>
    >> yes, but what key would you use? :-)
    >> The device has nothing....

    > Very good question, I thought the same.
    > In the case I see, the device don't talk directly with the PKI.
    > There can be a secure HW device in the factory interacting with
    > production line on one side, and the CA on the other. It can talk
    > something device specific, direct connect, with the device on the
    > production line, and make the CMP calls to the PKI. The private key
    > generated (by the CA) is then encrypted with the gateways public key
    > (where the private key is kept in an HSM/TPM/SmartCard).
    > Yes, the "gateway" becomes a point where the private key is decrypted
    > and vulnerable for a short time, so it's not for every scenario.

    > The CA can be off-site, not in the factory, i.e. central organization
    > PKI. The the term _factory_generated_ can be a bit misleading. The CA
    > can of course be in the factory as well, I just don't want to trigger a
    > specific architecture image in the readers mind.

Should I say _ca-generated_ then?

    >> So I think that it really has to always be used in the factory with a
    >> physically secure network connection.

    > Physically secure on the production line itself, but can be internet
    > between the gateway on the production line and the CA.

Agreed.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email