Re: [Rats] Definition of an Attesting Environment (and layered attestation)
Laurence Lundblade <lgl@island-resort.com> Fri, 16 July 2021 18:24 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 7A9AC3A4001 for <rats@ietfa.amsl.com>; Fri, 16 Jul 2021 11:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 WfC5nXfYSiyE for <rats@ietfa.amsl.com>; Fri, 16 Jul 2021 11:24:36 -0700 (PDT)
Received: from p3plsmtpa08-02.prod.phx3.secureserver.net (p3plsmtpa08-02.prod.phx3.secureserver.net [173.201.193.103]) (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 0A35A3A3FFF for <rats@ietf.org>; Fri, 16 Jul 2021 11:24:35 -0700 (PDT)
Received: from [192.168.0.100] ([71.92.144.145]) by :SMTPAUTH: with ESMTPSA id 4SVmmZweQFkBS4SVmmu89P; Fri, 16 Jul 2021 11:24:35 -0700
X-CMAE-Analysis: v=2.4 cv=b4R3XvKx c=1 sm=1 tr=0 ts=60f1cee3 a=E5cCtQzjhQJ5yJ7bKjC7Hg==:117 a=E5cCtQzjhQJ5yJ7bKjC7Hg==:17 a=QyXUC8HyAAAA:8 a=4ipSCZwJb94HMdbjmIcA:9 a=V1n5ADHWLQmbYs-g:21 a=9f4kTIMSXnEVyES9:21 a=QEXdDO2ut3YA:10 a=a4MPHgmAdfJr8U62opYA:9 a=Hz-UEJsw4kz5i1wv:21 a=xElt-kH30QaKWXrx:21 a=oMZ-aU5S6TpW5pUu:21 a=_W_S_7VecoQA:10
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <A663DF45-B72E-422B-85A2-05C0651D4550@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B48AB5C5-9727-4DAC-9BD7-1EBA36A6A58F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Fri, 16 Jul 2021 11:24:33 -0700
In-Reply-To: <13651801-BEC5-450B-B814-BD85A1D1C08E@intel.com>
Cc: Thomas Fossati <tho.ietf@gmail.com>, "rats@ietf.org" <rats@ietf.org>
To: "Smith, Ned" <ned.smith@intel.com>
References: <617FC3B4-5C1B-4D35-BD4B-9AC2D1362930@island-resort.com> <CAObGJnNRbA1sKuTCBLpdUtLmjNW+qgRZrGd=dHZ7ZrfXkJJizw@mail.gmail.com> <5426682C-48CB-4D7D-A9DF-01FB17B168E8@island-resort.com> <9EDE7661-4443-4D2E-BF72-FBF238A6EF4D@intel.com> <CABF0A5F-DC51-4D38-8772-6351FA80E6A8@island-resort.com> <A998AEAF-3E1C-480A-866D-410D0B0D4362@intel.com> <B525A1CF-C9CE-46DC-BCCD-BF3BE6684A22@island-resort.com> <13651801-BEC5-450B-B814-BD85A1D1C08E@intel.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-CMAE-Envelope: MS4xfKsDFO4bhlfLBUa3MCO6rY1r+DTXF9cnOXom3ZTWH2xeqR/tt+DgyS5BFN3reYMr8JxlkAaaAVl1COMlskcmxAtNvjtT2aBJV9R9QZHo4gE4ZyR3tcE6 F00lojsgzl0GIioboGDHRpnpGretfRJCaK+SZiT+MRnsnrxpHjGv6c7Ld3MZbaVRcPKXOebfDzl9a1vqjEXlBELfAJSDrdVV/RfYTTAyfKYa9QbNMr4EKvch DPhXtZ1EpyRzsiDZj1X9jw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/uEX7y61DKTWWNDCFk0u-AdSVL0s>
Subject: Re: [Rats] Definition of an Attesting Environment (and layered 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, 16 Jul 2021 18:24:41 -0000
> On Jul 15, 2021, at 10:55 AM, Smith, Ned <ned.smith@intel.com> wrote: > > The Arch draft captures two duties of an Attesting Env fairly clearly (1- collect Claims, 2- create Evidence). In a layering context the Attesting Env has another duty (3- pass execution thread to the Target Env). > > #3 is probably also true for composite device as well, though in composite device the Attesting Env retains a thread of control. > > Does the list believe these points should be in the arch draft or are they reasonably inferred? Hi Ned, I don’t think #3 should be part of RATS. - It is not necessary in composite devices - Many devices using composite attestation will not do it Here’s an example of a mobile phone. It has three Attesting Environments: - A TrustZone-based TEE that is the lead Attester - The HLOS, say Android - A Secure Element soldered to the PCB The Secure Element boots fully on its own using SW from the Secure Element vendor. The HW and SW on the Secure Element is certified to EAL 5 or such. The TEE and HLOS have no role in its security or its startup. The Secure Element is connected to the TEE by HW that can’t be manipulated by the HLOS. The Secure Element produces full, proper signed Attestation Evidence. That goes to the Attester on the TEE and gets cryptographically bound into the Attestation Evidence produced by the TEE as a nested token. The Endorser for the Secure Element is one that just handles Secure Elements, knows about their certification levels and such. It is separate from the Endorser for the TEE. That is the main point about #3. To go a little further… The HLOS also has an attester that collects evidence about itself and about apps. It feeds its Attestation Evidence to the TEE, but this is probably not signed and secured as a nested token. It’s just a common submodule as per EAT. Perhaps the TEE was involved in the start up and validation of the HLOS. Perhaps it wasn’t. It can work either way if the Endorsements are done right. Note also that all three of the Attestation Environments are up and running all the time. None are short-lived running only during the boot cycle. A good use of this architecture is to produce fully live Attestation Evidence each time a payment is made by the user of the mobile phone. This is a useful thing to do because payment app, the HLOS, the TEE, the fingerprint authentication in the TEE and the Secure Element all are used to make the payment. So new fresh attestations of large parts of the system are produced day in and day out. It’s not just re sending the measurements that were taken and stored when the device booted. (Any interest in this as an example as an addition to section 3 next to the layered attestation example?) LL
- [Rats] Definition of an Attesting Environment (an… Laurence Lundblade
- Re: [Rats] Definition of an Attesting Environment… Thomas Fossati
- Re: [Rats] Definition of an Attesting Environment… Laurence Lundblade
- Re: [Rats] Definition of an Attesting Environment… Smith, Ned
- Re: [Rats] Definition of an Attesting Environment… Laurence Lundblade
- Re: [Rats] Definition of an Attesting Environment… Panwei (William)
- Re: [Rats] Definition of an Attesting Environment… Laurence Lundblade
- Re: [Rats] Definition of an Attesting Environment… Laurence Lundblade
- Re: [Rats] Definition of an Attesting Environment… Smith, Ned
- Re: [Rats] Definition of an Attesting Environment… Laurence Lundblade
- Re: [Rats] Definition of an Attesting Environment… Smith, Ned
- Re: [Rats] Definition of an Attesting Environment… Laurence Lundblade
- Re: [Rats] Definition of an Attesting Environment… Smith, Ned
- Re: [Rats] Definition of an Attesting Environment… Laurence Lundblade
- Re: [Rats] Definition of an Attesting Environment… Jeremy O'Donoghue
- Re: [Rats] Definition of an Attesting Environment… Smith, Ned