Re: [Rats] Two types of secure attestation

"Smith, Ned" <ned.smith@intel.com> Thu, 21 November 2019 16:53 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 5B99B120B40 for <rats@ietfa.amsl.com>; Thu, 21 Nov 2019 08:53:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KZw03PIoQ3HJ for <rats@ietfa.amsl.com>; Thu, 21 Nov 2019 08:53:06 -0800 (PST)
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (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 D80C21200BA for <rats@ietf.org>; Thu, 21 Nov 2019 08:53:05 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2019 08:53:03 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.69,226,1571727600"; d="scan'208";a="290376017"
Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga001.jf.intel.com with ESMTP; 21 Nov 2019 08:53:03 -0800
Received: from orsmsx123.amr.corp.intel.com (10.22.240.116) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 21 Nov 2019 08:52:57 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX123.amr.corp.intel.com ([169.254.1.236]) with mapi id 14.03.0439.000; Thu, 21 Nov 2019 08:52:57 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Laurence Lundblade <lgl@island-resort.com>
CC: "rats@ietf.org" <rats@ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Thread-Topic: [Rats] Two types of secure attestation
Thread-Index: AQHVntzp4M6ZJzqVJUiVsZ6c2vuAXaeTFYmAgACwdgCAAA6xgIAAu9YAgAEdtgCAAAn4gIAABdyAgAADQoCAAAxJgIAAES0AgAATcYD//+hLAA==
Date: Thu, 21 Nov 2019 16:52:57 +0000
Message-ID: <8BE6C775-6E2F-491A-923B-D751220A5B67@intel.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> <02ec1d3f-3ef6-fbb6-3f59-b846cba1b3ce@sit.fraunhofer.de>
In-Reply-To: <02ec1d3f-3ef6-fbb6-3f59-b846cba1b3ce@sit.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-originating-ip: [10.255.231.167]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5428C520956F5C4DA9C5311CBDEB050C@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/P_15ftbUau2_PfdwNfywl2ypxT8>
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: Thu, 21 Nov 2019 16:53:08 -0000

I think this is a case where the verifier role is combined with the attester role such that an implicit attestation is all that is required by a remote verifier to arrive at a conclusion that the detailed policies applied by the verification logic in the boot code were applied. In other words, the system couldn't have booted incorrectly if it is able to supply implicit attestation to the remote verifier. 

On 11/21/19, 2:18 AM, "Henk Birkholz" <henk.birkholz@sit.fraunhofer.de> wrote:

    I re-read this as it made really no sense to me. I realize that I 
    actually do not understand this sentence:
    
    On 21.11.19 09:06, Laurence Lundblade wrote:
    > In this non-TPM style attestation there is hashing of code booted as part of secure boot implemented in the boot ROM, but that all happens inside the boot sequence and never manifests outside of it (I also do not think it is helpful to refer to this part of the boot ROM as a “verifier” in this context because it is not the same as a RATS verifier that produces attestation evidence, is remote and such).
    
    What is "this part of the boot ROM" and why should anything in the boot 
    ROM be called "verifier". It seems that it has occurred already. Could 
    someone please tell me where and why? Was it mentioned on this list?
    
    Viele Grüße,
    
    Henk