Re: [Rats] Out-of-band key material set up in architecture document

Laurence Lundblade <lgl@island-resort.com> Wed, 06 November 2019 16:58 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA83120089 for <rats@ietfa.amsl.com>; Wed, 6 Nov 2019 08:58:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 mG4MkRYt6SpW for <rats@ietfa.amsl.com>; Wed, 6 Nov 2019 08:58:24 -0800 (PST)
Received: from p3plsmtpa12-01.prod.phx3.secureserver.net (p3plsmtpa12-01.prod.phx3.secureserver.net [68.178.252.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5D6120072 for <rats@ietf.org>; Wed, 6 Nov 2019 08:58:24 -0800 (PST)
Received: from [10.122.0.166] ([45.56.150.85]) by :SMTPAUTH: with ESMTPA id SOdTiDnOmISIwSOdTiL8RW; Wed, 06 Nov 2019 09:58:24 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <5050A16A-68D3-4D6A-859F-EAFF74FAF096@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_149AF028-8C07-4BAB-B5EC-1675FA879DC5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 6 Nov 2019 08:58:20 -0800
In-Reply-To: <MWHPR21MB0784D3762243B2D09E0E6DC8A37E0@MWHPR21MB0784.namprd21.prod.outlook.com>
Cc: "rats@ietf.org" <rats@ietf.org>
To: Dave Thaler <dthaler@microsoft.com>
References: <9B93F41C-3707-4822-B3F5-5F9978872786@island-resort.com> <MWHPR21MB0784D3762243B2D09E0E6DC8A37E0@MWHPR21MB0784.namprd21.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfCiehx0yMFFP9Rt7ceFJqJ+y/LX0PyBOnEsWUZ4wbHhtMzjOzphMMdA7XGS/l1U/6a6chMTmwVKXB25Lw/hacbT3T4E12iMlV3hx/jd8GzpUwF6L1W6T DDC80cqcg/QFmUxGvAxXzuh835buwCGdvS8PXcfWyMf6hmm/EVwwqErhIdKIJjmQYQY8mehCv+MStN+FsOOcRa5OfHFmJmEQl4c=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/JRn1-XbFlfyMUQ8L_gRXJWerED0>
Subject: Re: [Rats] Out-of-band key material set up in architecture document
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2019 16:58:27 -0000


> On Nov 5, 2019, at 3:40 PM, Dave Thaler <dthaler@microsoft.com> wrote:
> 
> Inline below…
>  
> From: RATS <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>> On Behalf Of Laurence Lundblade
> Sent: Tuesday, November 5, 2019 12:17 PM
> To: rats@ietf.org <mailto:rats@ietf.org>
> Subject: [Rats] Out-of-band key material set up in architecture document
>  
> An issue I have with both the current architecture documents is that they do not discuss the need for some out of band key material set up to make verification work.
>  
> The manufacturer of the device must put some private key into each device so that the device can sign attestation evidence. Most likely the manufacturer also creates the verifying key material, but they may or may not be the verifier.  If they are not the verifier, somehow the verifier of attestation evidence must have corresponding key material to verify the signature.
>  
> This paragraph could be a start of the text. I think this is a critical part of the architecture because attestation doesn’t work without it. 
>  
> I agree that a private key is needed in each device for attestation to work (at least using any techniques
> I’m aware of). Saying “the manufacturer must put it there”, is however I think too narrow, as it implies the
> manufacturer actually knows the key. In some arguably more secure designs, the device itself creates the
> key pair and the manufacturer per se never knows the private key, only the public key, so it would be
> confusing to say the manufacturer “put” it there, or that the “manufacturer creates” the key material.

We could say “establish the signing key”? Certainly don’t want to exclude those more secure designs.

>  
> ...
>  
> Furthermore, the RATS charter does not constrain attestation to only *hardware* based roots of trust.
> There are some cases where it may be in a hypervisor or bios or firmware or whatever, and only attest
> things above that, with obviously a weaker level of security than hardware-rooted attestation.   But any
> protocol mechanisms should still work (mainly because it’s almost impossible to rule them out except via
> a security policy that says which keys to trust), even if it’s not the primary focus we care most about.  The
> point here being that in such a case it may not be the “manufacturer”, but may be another entity.  That’s
> actually true in some cases even for hardware-based roots of trust.

Yes, the “manufacturer” could be a SW vendor or even the author of a dumb Android app. We need a much broader term or description.

LL