Re: [Rats] EAT claims for composite and layered attestation

"Smith, Ned" <ned.smith@intel.com> Mon, 05 April 2021 20:29 UTC

Return-Path: <ned.smith@intel.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 4C91D3A2697 for <rats@ietfa.amsl.com>; Mon, 5 Apr 2021 13:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intel.onmicrosoft.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 k0k3AxBbxbFB for <rats@ietfa.amsl.com>; Mon, 5 Apr 2021 13:29:18 -0700 (PDT)
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (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 D4EBF3A2695 for <rats@ietf.org>; Mon, 5 Apr 2021 13:29:16 -0700 (PDT)
IronPort-SDR: CEUEDANZnAX9EyJuilU0dr5rtr1ElC6wIcviLxxFfX4S7OCfPDng2G/D3x+ODOnMIbgmjro+GG Fd3nY32d1Pgg==
X-IronPort-AV: E=McAfee;i="6000,8403,9945"; a="190742060"
X-IronPort-AV: E=Sophos;i="5.81,307,1610438400"; d="scan'208,217";a="190742060"
Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2021 13:29:15 -0700
IronPort-SDR: 0KjMO9bN1hT2gLsb90bg+b+LKVlF59JnXasheIl/+2um4quBXrWs6fqTUFOYTxYeUo4GANRwZU zuuwJv93Y7Tg==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.81,307,1610438400"; d="scan'208,217";a="608998343"
Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by fmsmga006.fm.intel.com with ESMTP; 05 Apr 2021 13:29:15 -0700
Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 5 Apr 2021 13:29:14 -0700
Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 5 Apr 2021 13:29:14 -0700
Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Mon, 5 Apr 2021 13:29:14 -0700
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.58) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Mon, 5 Apr 2021 13:29:14 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h5i9e1Q4/oQ/IUV7gcEIh1b5JLhZvLr3iH9/RfzEGVvZ1dWjOEKrT0daNHsr1XjO6nM99JjzAIEZVGvFfVqmuJf4KO+ENKRvQGp7jglN3IgHeA5Mqc4iH87DLYdMXGbQszwpi6g8eGrvCTzMSiaofvLn+95CAw0omPD1TX+iRBDM8nSA0JijNoe/UCaCUguX5SYWS95ql6tMOL1zpLyeDPRJabqQFdb9H8gc7QdWmUebQNQ6laDK2y/HpUDlISTWuRCVgbwRHeESaJ5gOiENB9dtB898G6Fp9oA3dlgCbrY8BSnVI6tIGkehRFAXRHy+eS0Z0EhoUOQcj0eCxY8Isw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JDL0UzUrxAmKYcGVgIpClkBTPiEPt7qq4R1i8WkrFUo=; b=DhJCPDjrTNdr5UPcLA1L1CShw4m9NljvXTwSQwCUuuvLyTtAR8XCOh3ahQNIkarVxYEc8JsYNWU8oW9C2W6vWXQV6TdEkEgYpYQ5DwOj+fZd2hTxWcwrGlZpbEXuTWoyoD6whTw2zjZuBTrPdgmwzewsQwOJEPwxDMPBB6WSwf9+RPES5P4R65W+4hUVMvKZdao7i/EGXNMs6OV+HkG0BmQCamy1xQ6qvsTXR1/3FW3Cg39R31o/4CghyY+YkTu2iV5oY94HVO7OgnLmRkGhellL8ptNFPDX9T1Y8lbvFGirOl6sHRL81q/GIDBmm45ZO8RDv3swRgkL5CppbrF/jQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JDL0UzUrxAmKYcGVgIpClkBTPiEPt7qq4R1i8WkrFUo=; b=Sa///6MPZ2aT13eisnHqGXlu6/v0rUSvxJqQ+FH4bZRWTTIbUV8ZHwiZS45Tim7SRcMFvzHisqinbOvFaoOc/+5Jk0rV5h/JFWjOyHyH4VkNH8eL7ktgWYAvwjxs0JZHQ/pUiLf8nuj6R/JQqqAhPZ9JXn3PlyHSoWnSGEPIdEY=
Received: from CO1PR11MB5169.namprd11.prod.outlook.com (2603:10b6:303:95::19) by MWHPR11MB1533.namprd11.prod.outlook.com (2603:10b6:301:e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.32; Mon, 5 Apr 2021 20:29:12 +0000
Received: from CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::b424:905d:3819:d9f0]) by CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::b424:905d:3819:d9f0%3]) with mapi id 15.20.3999.032; Mon, 5 Apr 2021 20:29:12 +0000
From: "Smith, Ned" <ned.smith@intel.com>
To: Laurence Lundblade <lgl@island-resort.com>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] EAT claims for composite and layered attestation
Thread-Index: AQHXJ/FBdZ9d7HreWEaj7ZvlR3M/nKql73CA
Date: Mon, 5 Apr 2021 20:29:12 +0000
Message-ID: <F3A7B322-D60E-41FC-981F-4A32F12922AB@intel.com>
References: <9A7D356D-23EE-4E84-8682-E6E8C81E78E2@island-resort.com>
In-Reply-To: <9A7D356D-23EE-4E84-8682-E6E8C81E78E2@island-resort.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.47.21031401
authentication-results: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=intel.com;
x-originating-ip: [50.53.43.22]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c4d41cc9-0c44-4a77-2250-08d8f8717982
x-ms-traffictypediagnostic: MWHPR11MB1533:
x-microsoft-antispam-prvs: <MWHPR11MB1533EB8BB1403F59BBE4591BE5779@MWHPR11MB1533.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: La3HZEf90iLteK/UEO0UzNVwdVns6jcosLelZdgHYEB0w2HaKT2XRUJIZNWzxLyNViUsqRn9cv5so43qiI8pgY3PYXUjGOFAgXm6Vl92cG4UAzfkhobShVZDKnnROfF+tqFoehgRoDAVJ1YFHOqe74jn//fPXRo4Ho3iOd2m7rC0AI9skqbE5eyWhDtVK8S+KdjZL5vob3AjFYEDBemgQZNH5WEBXo6OL71oEydS98Evw2hxWDSwFWMAYeA48t4Zxl3t8mD615FaNIsYSdb8zJhqpGikbXLMyANAUPIeqOyTDsp6wHvITDH7uEfc5FMk6uBAuA90+3HJ/X9RGul/b5o6ymSTG2eTo3wvtik2elSYOWFghxlE7hQGIJVgQJPQomamHt1Or9cjJMrr8gnKgygSzULTNyTv0t1J2rJeRONj/MiMjwV72LsV7zXuJ2FJFg944xOrsTS7hXdEpRmSqT+cnI206AwHDKCSZ85iWOW0IRGi0VeQ9IzaDEeKPrwkc1LIhGY+QWhhrgTBM8NAhfka/XS9UClsA0YWlsVfbFh1iM4lvwYrTBoIX5cYCtFMeON5VcVGbvVaCbb3SBlxtKi/bCmGTFMG8CyHX80kku/xFMPN7G4JBZlYaEAPc2BRRRa1ClCc1dP8FG+RHXYHsqaSmz5pVErHpvbb+1iVDYcyyUZks1+cJzTK2mXqs42eMUQYJ6W1xtzaxD7qjlykVXfYAJbyLkZRTRJzRClzKfnp6O98fTahy/+XILM5Gdu1/he3JieQO3KQQfMMomv87uqupvF733/u416ORmEK4Ng=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB5169.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(366004)(376002)(136003)(396003)(966005)(83380400001)(478600001)(110136005)(6512007)(2616005)(71200400001)(6486002)(53546011)(186003)(5660300002)(36756003)(166002)(66946007)(8936002)(33656002)(76116006)(26005)(66476007)(38100700001)(2906002)(64756008)(66446008)(66556008)(8676002)(316002)(6506007)(86362001)(45980500001)(15398625002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?MGJQVFhrZnFuSHJEOE1RTm9RcUpoUkp4bndLckhPU0NkWUVIUk01U1Y4elVM?= =?utf-8?B?cnMvWVBuUFM1Skl2aHZ1Y3NGMDBPaGpjelVPZHN6bExEbE9yU1FrT1A4ODQy?= =?utf-8?B?ajRoQnYyT1U5Qm90OFlpWXFGbTlEeE91Z3FRWHQwb3V3M01iRnY4cHhuQVY1?= =?utf-8?B?ZkI2RGpWaVFFcFNlTjROK21ySXNLVE94Q0tPK2VmZXAxWURkU2pKbGtPck5X?= =?utf-8?B?R0lWYVFRVEQ2Z0JjTW9OdDhxdTFFZE5sT2x3cDQreHIzU0pHU3FWbTZKNWdz?= =?utf-8?B?a0s5UFM5NDVlTjhFR3NkYVA3SUU4TEFDMitLS25DQm9kV0Q3MGFnM29sSGZr?= =?utf-8?B?cE1lUjN4dGNqMWZJT2kwOC9tVnFJNFpjYWxsbFcxZGtiK0NybnB6VDFqeFN4?= =?utf-8?B?djFLSXZTZzNmRTN3bDMyeFBMekVvUzhENVdERUNUc1RjaXEreXVPQm1GMXJu?= =?utf-8?B?NGU3WER5cmkxSEtaYkF6S1o3eDN4VXBmNEhqSmtMcHEyam9qVUQvNHBmb3ZL?= =?utf-8?B?V1ZtcXMxUkNoaFJ2YVRBZHZMS01sd3UvRjlHRkVGWkpIWXUrNk0vbVc5UXFO?= =?utf-8?B?cGpFMnpqUlZveUdMaE5iTzBFTFFTc0I4dUg3UzFQcVdJRERkZlU0Q0JwaFBZ?= =?utf-8?B?MlhQcnNleDdSOWwwT3VrdnNYN3JBdk9xMGNJYm1qRzJFbm50OHFVUjRSWTRu?= =?utf-8?B?cU9idzVHSjlmR1BxVUhoS1JjUkNRbFVhNEp6VE5KY2llK05mbkhYRHkvRnBi?= =?utf-8?B?TXJsbURqM05WOFVJVXVWUmNWMkZtWTZGUk1KbHl4SlpTOWdtMFNpSkpnRUs3?= =?utf-8?B?Y001M3F0OHorSmxrcG04VmR0RW9ZbUZidW96cjN4TE5IYUlWalpCZlAwbnBv?= =?utf-8?B?OThEWnBRRXpLYjZ1aWU2UjZjMkJwd3c3dG53OEFRNmx5empDNEh5YTkzUyt1?= =?utf-8?B?d210ZDNIMXMzaEJ5TGdJRVVsQjRnZHZwT28xVnRSQzNxVjZnb3VOUmQ0QVls?= =?utf-8?B?NGdoQjlvUWc4S09ucFdGd3ZUTDExbDdDQUlkQlkxUWRHSkNSVDMxaVZLbVAv?= =?utf-8?B?TGd4N3hTZUE0dkhxTlF2cDhkNzNXd201TGVQZUZQVUdXRXp4dHRWVDMzZVlh?= =?utf-8?B?LzlmSzdoUk1BeVZyVUZoRUE2OXdZZ3g0RWthVGZBWVliZlVZc1Q1TTBMS1Rr?= =?utf-8?B?NzFtYWVNSlBacW4rOGtrUFBjOUw1QVg4MnZNQWMrOGd3WlI4dStnaHpiR0FY?= =?utf-8?B?aVBBM1VBaDloQWZWa1ZTYmFheGVEYWpOamJ0T04vbC9GeFdOaUQ5c0xmdWNv?= =?utf-8?B?alBsaEkwT0NUNERtRUFZWHZ3SUdmK25haGFJbE9IWkQrSXFrY2tSNHZCMWo1?= =?utf-8?B?ckVaTVZZSXVSTGN0SFFDVWQxaTBxcVoybkd3Sk0wMHhicFFNWlVqVDV3SUdD?= =?utf-8?B?RlBicEplSEI2NU03eHFIdkVzNnBldmVyTlE2N1RZLzgzdFpTZkVrSS9EajVh?= =?utf-8?B?OGdsQnhBZXI3K0tna29JUmM1L0hwbWtVR2NEdkZyWWtUL0VKUEtJWEF0VEhj?= =?utf-8?B?S0tEYzFKNE9ZbVhqUHpyVStBaVZOSVFrRjNra0hvdzc2MGlDVTExQTl1T0hB?= =?utf-8?B?aEgxcTV6VkN5RmV6ZklyeHN1bDgzRWczR2dXQlEzcnJZM3NWSkpzUElSeUN6?= =?utf-8?B?aXZSS0lpRVU3NXJKT0liZTlGYlVVWjRWRlUrUHVYZDVGUjE2dTdIcUNTelJw?= =?utf-8?Q?3Fxr1+f/CE4mrCmHPgNsWb/LLrPX5bdjVFmiGUN?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_F3A7B322D60E41FC981F4A32F12922ABintelcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5169.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c4d41cc9-0c44-4a77-2250-08d8f8717982
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2021 20:29:12.5752 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OXOYX1Xb7bqDdNB3iugadthrTHkfD0SJ9KW31XVGKs+35KmU2Tjb09qjSZ1x/LZWBQj7j3j0m7ow76OztFKV6g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1533
X-OriginatorOrg: intel.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/P0AcSd97AqRnlJxu8gidUUb0I7Y>
Subject: Re: [Rats] EAT claims for composite 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: Mon, 05 Apr 2021 20:29:24 -0000

See inline (NMS>)

From: RATS <rats-bounces@ietf.org> on behalf of Laurence Lundblade <lgl@island-resort.com>
Date: Friday, April 2, 2021 at 11:51 AM
To: "rats@ietf.org" <rats@ietf.org>
Subject: [Rats] EAT claims for composite and layered attestation

To try to get clarity on architecture for devices with multiple attesting environments, I’ve started thinking about what an EAT would look like for such.


I think composite attestation is straight forward.

In composite attestation, the attesting environments are trusted independently. The verifier will get a separate endorsement for each attesting environment. There’s no claim in one set of attestation evidence that is involved in establishing another, so no special claims are needed.

What is needed is the ability to embed the attestation evidence from one attesting environment in attestation evidence from another. We have that now in EAT with nested tokens in the submodule section.


The distinguishing characteristic of layered attestation is that the trust in attesting environments is NOT independent. One attesting environment plays a role in the verifier coming to trust another.

There is clearly has to be root attesting environment, trust in which is established by the usual way, most likely by an endorsement from the manufacturer.

From there, it seems there are two paths.

In the first one, the root attesting environment can collect evidence about a layered attesting environment, put it in an EAT and send it to the verifier. It is the *verifier* that evaluates and decides on the trust in the layered attesting environment. Probably the evidence about the layered attesting environment appears in EAT as a submodule. The verifier will look at the evidence and decide if the layered attesting environment is trustworthy. It may look at measurements, debug state for the attesting environment.

To complete, that submodule probably needs to contain the public key of the layered attesting environment. It probably needs to be clearly labeled as the verification key for attestations from that layered attesting environment, so we need to define a new claim for this.


In the second one, the *root attesting environment* is the one that decides whether the layered environment is trustworthy. It can do this however it sees fit. It might just trust it because they are in the same HW running from the same ROM. It might do some staged secure boot. It might do run time integrity checks.

It then tells the verifier that the layered attesting environment is trustworthy. This basically amounts to the root attesting environment sending an endorsement or the equivalent of an endorsement to the verifier. The root attesting environment might construct the endorsement on the fly or
                                                                                                                                                                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NMS> It would likely not be viewed by Verifier as an Endorsement unless it was signed by a trusted Endorser (aka mfg). Since, the root attesting env isn’t a traditional CA (that can be physically audited), the Verifier isn’t likely to have TA policy for it. It would likely still be considered a ‘device’. The TCG DICE Layering Architecture specification https://trustedcomputinggroup.org/wp-content/uploads/DICE-Layering-Architecture-r19_pub.pdf describes this sort of thing as an ‘embedded CA’ because it issues the certificate for the next layer environment. It is also an Attesting Environment because it might also include Evidence in the certificate.

This sort of root attesting environment wouldn’t be called an Endorser since it is also being called an Attesting Environment. The mfg CA that signs the root attesting env key is the likely line of demarcation; i.e., the mfg CA (and the cert chain to the root CA) is the Endorser, while the root attesting environment cert + any additional embedded CA issued certs + the ‘target environment’ claims would be the “Attester” Evidence.  (Assuming Certs contain evidence extensions).

Note:  The https://trustedcomputinggroup.org/wp-content/uploads/TCG_DICE_Attestation_Architecture_r22_02dec2020.pdf defines an OID for UCCS evidence as a certificate extension. This might be used to include EAT claims as evidence in an X.509 certificate that is issued by an attesting environment in a layering pattern.
<SMN

it might have been programmed in a the factory.

Probably this endorsement should be in attestation evidence from the root attesting environment so that the verifier knows that the root attesting environment did the checks it needed to do. That means we need a claim that holds an endorsement like those based on X.509 or to consider some set of attestation evidence that includes a public key to be considered and endorsement.

(I’ve worded this in terms of two layers, the root and a layered attesting environment. I don’t mean to exclude multiple layers, though there’s just one root).


I don’t really know what was intended by layered attestation in the architecture draft. It seems halfway the first path and halfway the second path. Seems just fine to have both paths, but they need to be described distinctly.  I filed an issue<https://github.com/ietf-rats-wg/architecture/issues/293> and a PR<https://github.com/ietf-rats-wg/architecture/pull/294> to try to sort this out in the architecture document. Hopefully, this email helps clarify those.

I’m interested in what the consensus is here before I go off and try to define the EAT claims I’ve mentioned above.

LL