Re: [Rats] Propose a new event-log-type in CHARRA

"Panwei (William)" <william.panwei@huawei.com> Sat, 29 August 2020 02:04 UTC

Return-Path: <william.panwei@huawei.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 B9EF43A0F12 for <rats@ietfa.amsl.com>; Fri, 28 Aug 2020 19:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 1k9bfRFrED8M for <rats@ietfa.amsl.com>; Fri, 28 Aug 2020 19:04:12 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 4697F3A0F10 for <rats@ietf.org>; Fri, 28 Aug 2020 19:04:12 -0700 (PDT)
Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B7208617BDBC88392AEB; Sat, 29 Aug 2020 03:04:10 +0100 (IST)
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 29 Aug 2020 03:04:10 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 29 Aug 2020 10:04:07 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Sat, 29 Aug 2020 10:04:07 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Propose a new event-log-type in CHARRA
Thread-Index: AdZ9F2S3YE6HUmniRGqctvSTG8eYFQAIIfcAABnn4vA=
Date: Sat, 29 Aug 2020 02:04:07 +0000
Message-ID: <49bfbed9e55f4089aa2f9e57b1201725@huawei.com>
References: <f92d4256061948a3aa89952b912c81e3@huawei.com> <28425.1598647020@localhost>
In-Reply-To: <28425.1598647020@localhost>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.99.125]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/7I-ucfERYxK8jNg_YSXkz0Zhjh4>
Subject: Re: [Rats] Propose a new event-log-type in CHARRA
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: Sat, 29 Aug 2020 02:04:14 -0000

From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]
> Panwei (William) <william.panwei@huawei.com> wrote:
>     > When the device boots, it needs to load/execute a lot of files, but the
>     > order in which these files are loaded/executed is not deterministic or
>     > hard to keep fixed, so it's difficult to give an accurate reference
>     > value.
> 
>     > The method to overcome this difficulty is below:
>     > 1. The Attester measures each file before execution, extends the hash
>     > value of the file into PCR, and records the measurement information
> of
>     > the file in the log.
> 
> Does the Attester measure the files in a deterministic order?

No, the order can't be guaranteed.

>     > 2. When doing the remote attestation, the Attester sends the final
>     > values of the PCRs and the detailed logs to the Verifier.
> 
> I remember this discussion.
> 
>     > 3. The Verifier has a list of reference values for all files. It
>     > compares the hash value of each file recorded in the log with the
>     > corresponding reference value. If all files' hash values match with
>     > their reference values, then the Verifier extends the hash values one
>     > by one according to the order recorded in the log, gets the final
>     > value, and compares the final value with the PCR value sent by the
>     > Attester.
> 
> Why not impose some canonical ordering (even alphabetical) to how the
> files are recorded into the PCR, regardless of the order they are executed?

This is not a secure manner, you need to cache the hash values before they are extended into the PCR, so if a malicious file is executed it has the opportunity to change its hash value before being extended into the PCR.
So the secure manner is to extend the hash value of the file into PCR before executing it.

Regards & Thanks!
Wei Pan

> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software
> Works  -= IPv6 IoT consulting =-