Re: [Rats] Two types of secure attestation

Laurence Lundblade <lgl@island-resort.com> Fri, 29 November 2019 22:09 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 062B01200DE for <rats@ietfa.amsl.com>; Fri, 29 Nov 2019 14:09:59 -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 9tIN9By7wVw5 for <rats@ietfa.amsl.com>; Fri, 29 Nov 2019 14:09:56 -0800 (PST)
Received: from p3plsmtpa07-03.prod.phx3.secureserver.net (p3plsmtpa07-03.prod.phx3.secureserver.net [173.201.192.232]) (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 837A7120052 for <rats@ietf.org>; Fri, 29 Nov 2019 14:09:56 -0800 (PST)
Received: from [10.182.0.86] ([45.56.150.186]) by :SMTPAUTH: with ESMTPA id aoSZiAxIyxpO0aoSZiocUa; Fri, 29 Nov 2019 15:09:55 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <29A9E618-69D4-4765-B516-2F8F69AB7406@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0B71A7C5-16E7-4831-A700-C1FE17181AD9"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 29 Nov 2019 14:09:54 -0800
In-Reply-To: <7e387a02-4d49-3a52-572d-f7e61b4e729f@gmail.com>
Cc: rats@ietf.org
To: Monty Wiseman <montywiseman32@gmail.com>
References: <B099349B-711D-4A11-9E58-0886307FB7AF@island-resort.com> <CAHbuEH6qtVbzRXUALKBrr3butc8qT8Y81X-nQ6+PjC1n08CkvA@mail.gmail.com> <5DB30E08-9AB2-452A-B8D6-55BFD0AE5264@island-resort.com> <CAHbuEH4R4GZQCq9E1Nza8uPC=jxiM-FkV4tMrv9B==GsjvCLtw@mail.gmail.com> <34EB67FD-E76A-4132-87C4-C89EA70C9365@intel.com> <DC9F1051-E33A-477F-A855-2FBA33F8E8DF@island-resort.com> <cbb5f662-b073-5b5b-e504-56ea66b72744@sit.fraunhofer.de> <5A3105EA-8E54-4BB9-B266-96B6645811A1@island-resort.com> <c4967ed2-e484-d8c9-406b-8e1bb1b3b88d@sit.fraunhofer.de> <FF6F2CEE-1049-4B6C-8E12-9E21FE92D2F2@island-resort.com> <3285c3da-0748-5607-90ed-ac024ac826d0@sit.fraunhofer.de> <0384FAEE-6C5B-4A99-BBA0-F080DD27AA9B@island-resort.com> <def7a722-e357-a12a-1467-8ff8c442337e@sit.fraunhofer.de> <A9E1ED3A-80D1-4585-9029-A49CA5AE3AB6@island-resort.com> <52AC3EB5-1BD0-4A41-8EAD-5A779E125BF8@intel.com> <06543a46-8218-fa9c-827f-8a0e2d364963@sit.fraunhofer.de> <F74104BF-35C6-4375-A5A0-93FFA34619B6@island-resort.com> <7e387a02-4d49-3a52-572d-f7e61b4e729f@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfLo3iA+vhB5sOLm+RC4Nr3Dp8TovgdF2rlrXV6UAR/EE+DZLIa5CLu2RikCg/fGRIp38gZpzeMTsGHCBlV88N2OfD6aiDCOixXt0FZLVidIksgTcjft5 ISW84+OU0fZUdROxZEbl2BIr5mtAWncXJuSngol9WYuOLdWH/fs/HkaB3JNZ++yAEuhGk8lurVBQui+3rPpxAiARy5ro5M6F2kw=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/4WeHHHcXWhWzjqMu2YTO16Ub5I4>
Subject: Re: [Rats] Two types of secure attestation
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: Fri, 29 Nov 2019 22:09:59 -0000

That is really helpful, Monty. Thank you!

My understanding is that TPM-based remote attestation is all about sending the Measured Boot result to a server / service that is the verifier + relying party. That is what the Yang module draft, before EAT was added, is about, what Guy’s RIV drafts is about, and Franke pub-sub draft is about. 

My understanding is that Verified Boot is not directly relevant to the these just-mentioned IETF drafts. Devices doing remote Measured Boot might have used Verified Boot or might not have. It doesn’t matter. The remote server / service doesn’t know. It is not reported to them in the remote attestation.

In this regard, EAT is in a way the opposite. For SW-based implementations of EAT, Verified Boot is critical. The EAT is of little value without it. The server / service trusts an EAT because the manufacturer committed to not putting EAT signing keys into devices that don’t implement Verified Boot.

Does this line up with how you understand it?

LL


> On Nov 27, 2019, at 12:11 PM, Monty Wiseman <montywiseman32@gmail.com> wrote:
> 
> Let's not use confusing terms like TPM-style / TCG language. I propose
> we start with lower-level fundamental definitions or even axioms for
> boot types. Within those definitions, I recommend deprecating the term
> "Secure Boot" as it's imprecise and even misleading. I expect there to
> be variations on these creating derivative definitions but I postulate
> these are fundamental as basic building blocks.
> 
> Root of Trust: Something that is assumed to always operate in the
> expected manner. The implementation is assumed to be correct. How it is
> implemented it outside the scope of its definition.
> 
> Verified Boot: Starts with a Root of Trust. For this type of boot the
> Root of Trust is the Root of Trust for Verification (RTV). The RTV
> includes a boot policy which is likely a verification key. The RTV
> enforces the boot policy which continues through the boot process
> assuming each component continues enforcing the boot policy or other
> policies authorized by the RTV's boot policy. The trust in the device
> depends on the RTV's boot policy and not on any external entity such as a
> Verifier. The boot policy is locked by the RTV and cannot be further
> evaluated beyond a binary "Trusted" or "Not Trusted" state. The evidence
> of whether this device is trusted is, therefore, determined by whether
> it boot to the correct state. (Some would say this is "existential boot.)
> 
> The TPM has no dependency on Verified Boot and Verified boot has no
> architectural dependence on the TPM.
> 
> Measured Boot: Starts with the Root of Trust. For this type of boot it
> is the Root of Trust for Measurement (RTM). The RTM contains no boot
> policy. The device's components are recorded and stored through the boot
> process as each component is assumed to continue measurement process. At
> some time during the boot process these measurements are converted to
> evidence and send to a Verifier. The trust in the device depends on a
> Verifier's evaluation of this evidence. The Verifier has a rich set of
> policy options available it beyond a binary "Trusted" or "Not Trusted"
> state. The type of boot depends on a trusted component (such as a TPM)
> record and converted the measurements into evidence.
> 
> Summary:
> The difference between Verified Boot and Measured boot is where the
> policy is enforced.
> 
> Verified Boot:
>       1> Policy is hard coded at boot time, is immutable, and binary.
>       (This form of boot is "existential" -- The device either boots to
>       a valid state, or not)
> 
>       2> Is simpler to implement but less flexible
> 
> Measured Boot:
>       1> The trust state is determined by a Verifier using evidence
>       about the device and a flexible set of policies.
> 
>       2> Is more complex to implement but more flexible.
> 
> Diagram:
> 
> Verified Boot===>
> 
>     Policy
> 
>     |
> 
>     V
> 
>     RTV --- Component --- Component --- Component --- End State:
> 
>     A trusted device state is created only if all policies were met
>     (i.e, the device booted). If any policy was not met, the device (as
>     it is expected) doesn't really exist (it appears as a different
>     device)
> 
> Measured Boot===>
> 
>                                                             Policy
> 
>                                                                |
> 
>                                                                V
> 
>     RTM --- Component --- Component --- Component --- End State:
> 
>    Trust State determined by a Verifier by appraising evidence collected 
>    using a set of policies.
> 
> Monty
> 
> Disclaimer: This is my personal opinion and not that of my employeer or
> the Trusted Ccomputing Group. While I co-chair TCG's Trusted Network
> Connect and Infrastructure Working Groups, the above defintions have
> not been officially adopted by the TCG's Technical Committee or Board of
> Directors.
> 
> 
> On 11/24/19 3:01 PM, Laurence Lundblade wrote:
>> 
>> 
>>> On Nov 24, 2019, at 7:31 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de>> wrote:
>>> 
>>> Hi all,
>>> 
>>> in a nutshell, one of the things I tried to express is that the following quite is simply not correct wrt to what is called here the "TPM-style" (I would really like to not use the words "TPM-style" and not to mixing authenticated & secure boot. Authenticated Boot is fine):
>>> > Primarily the difference between TPM-style that doesn’t rely on secure boot and non-TPM-style that does rely on secure boot.
>> 
>> It’s hard to know what to call things. I’m learning the “TCG language” slowly and we’re also evolving (in the architecture document) a common language. I keep trying terms and definitions to see what sticks and what doesn’t. Pretty sure we agree on “attestation evidence”, “verifier” and “attestation result”, but I don’t know what “secure boot”, “authenticated boot” and “trusted boot” mean to you so I don’t know which term to use.
>> 
>>> 
>>> It is never possible to create TPM structures that are signed Attestation Evidence, if a device that is explicitly intended to conduct "secure boot" did actually not do so successfully. That is one of the key-features of TPM/TSS remote attestation procedures.
>> 
>> It seems to me that TPM-style attestation where you measure each step in the boot sequence and report to a verifier was designed to work without secure boot. However I can see that it could also work with secure / trusted / authenticated boot.
>> 
>> 
>>> 
>>> On the other hand, what leaves me puzzled is the following. If these three quotes are all correct...
>>> 
>>>> You cannot create an EAT unless the authenticated boot was successful. The key material with which to sign the EAT is inaccessible if authenticated boot fails (or else the device just won’t boot at all).
>>> 
>>> draft-ietf-rats-eat-01:
>>> 
>>>> All claims are optional
>>> 
>>> and draft-ietf-rats-eat-01 again:
>>> 
>>>> 3.7.  Secure Boot and Debug Enable State Claims (boot_state)
>>>>   This claim is an array of five Boolean values indicating the boot and
>>>>   debug state of the entity.
>>> 
>>> ... one is allowed either to omit that Claim in an EAT or set some values of the Claim members to false. Therefore indicating that the boot state is, e.g. "secure_boot_enabled=> false", and still be able to create the EAT. Is that correct? If not, why include this member of the boot_state Claim at all? It always made me think until now that it allows for a device to not conduct "secure boot" and still be able to create an EAT.
>> 
>> Yes, you are right that in some cases it would make no sense to have the secure boot claim. It is basically an implicit claim. Here’s some where it does make sense to have an explicit secure boot claim.
>> 
>> The main attester might boot securely, but submods might not.
>> 
>> It is possible to build pure HW that implements EAT attestation. It might be a part of a SoC. That attestation HW doesn’t use the main CPU to implement the attester, but can report on how the main CPU booted.
>> 
>> 
>>> 
>>> Besides that, what I think we are actually talking about is implicit and explicit attestation.
>> 
>> Seems like you have to say which claims are implicit and which claims are explicit and in many attestations you need and get both.
>> 
>> For example, you called out a situation where the secure boot claim is implicit and questioned the need for the claim. I then called out a situation where the secure boot claim is explicit. 
>> 
>> In one attestation the secure boot claim might be implicit and the GPS location is explicit.
>> 
>> LL
>> 
>> 
>> 
>> 
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org <mailto:RATS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats