IETF Logo Mail Archive

Re: [Rats] Two types of secure attestation

Laurence Lundblade <lgl@island-resort.com> Fri, 22 November 2019 00:55 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 0C73412081E for <rats@ietfa.amsl.com>; Thu, 21 Nov 2019 16:55:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Nx9vO0JAhT_B for <rats@ietfa.amsl.com>; Thu, 21 Nov 2019 16:55:19 -0800 (PST)
Received: from p3plsmtpa07-01.prod.phx3.secureserver.net (p3plsmtpa07-01.prod.phx3.secureserver.net [173.201.192.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 26A1912081C for <rats@ietf.org>; Thu, 21 Nov 2019 16:55:19 -0800 (PST)
Received: from dhcp-9fd9.meeting.ietf.org ([31.133.159.217]) by :SMTPAUTH: with ESMTPA id XxEBiMRQQqGFCXxEDiXKXz; Thu, 21 Nov 2019 17:55:18 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <8BE6C775-6E2F-491A-923B-D751220A5B67@intel.com>
Date: Fri, 22 Nov 2019 08:55:15 +0800
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "rats@ietf.org" <rats@ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E0FF98C-ABB5-4E6F-95D7-356E94F762ED@island-resort.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> <8BE6C775-6E2F-491A-923B-D751220A5B67@intel.com>
To: "Smith, Ned" <ned.smith@intel.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfCAiPAXPkJFGYRT0Xd5Z72u7oHbjMgA2LWsY0LnYuYGgabSd6OflWq/+AELjlToO0dcbNSxb9+xzu3RjXCcZJyZt0PHALvF/6IbNBb3tAyq0GuCm5ymu AUY86qdW8TuESHGjz5T6stJDhCrO1abNuzzZskOo9bRQjOBveqjaMWWRUtQ9QiB8QW7oJamzf2gcP+Z746RKCZ9UiDaaExY02l9H3/q2cwbu0ITv+z6E+ZbK zYUo4DOmpmWUcUROs474kb9YkE+I0RTwzdDvsM+DAsMyt8J8jyk4cfUUBRTjvdz+f29M7K6kmXOBkuMbMRJA0g==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/jcy7BtKXr-kJv2YAwmif7o6UTcc>
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, 22 Nov 2019 00:55:21 -0000

Agree with Ned’s characterization of the system behavior. 

However I think calling this a RATS verifier + RATS attester is very confusing. A RATS verifier consumes RATS format attestation evidence. It will often produces RATS format attestation results.

This part of the boot ROM usually uses highly propriety formats for signed operating system code, nothing that looks like COSE, CBOR or CoSWID. It might look like ELF. Maybe the TCG has some standards in this area, but I think it is far outside the RATS charter. 

I’ve had some exposure to commercial work on that sort of boot ROM code. It is the some of most cared-for, sacred and tested code in existance.

LL


> On Nov 22, 2019, at 12:52 AM, Smith, Ned <ned.smith@intel.com> wrote:
> 
> 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
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats

v2.23.0 | Report a Bug | By Email