Re: [Suit] Parameters and Commands

Brendan Moran <Brendan.Moran@arm.com> Fri, 28 February 2020 11:40 UTC

Return-Path: <Brendan.Moran@arm.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9ACE3A165F for <suit@ietfa.amsl.com>; Fri, 28 Feb 2020 03:40:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=QxP05SnL; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=QxP05SnL
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 Q0wPPOzWz35x for <suit@ietfa.amsl.com>; Fri, 28 Feb 2020 03:40:31 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30068.outbound.protection.outlook.com [40.107.3.68]) (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 D52143A165B for <suit@ietf.org>; Fri, 28 Feb 2020 03:40:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SHXIbvmVD/0+jIJpsCb/pUu0tBij5QCugHIEqnuIr+s=; b=QxP05SnL/EcDbmaIidMXkYLCucN5Ytrik7By6T97AMsEg/GyEdqh5gsOw7r/h0QdEAvAzrk4KukiRMBxOUDXJcHHHju43B27z1Lx9MpUSdY9FDbuQTRs4PczAFlkdEbcs8PlJ9qAZfkjzUa5TTlo4Lzb3zWaPVqRIose+cHjyZw=
Received: from VI1PR08CA0269.eurprd08.prod.outlook.com (2603:10a6:803:dc::42) by AM5PR0801MB2049.eurprd08.prod.outlook.com (2603:10a6:203:42::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 28 Feb 2020 11:40:26 +0000
Received: from DB5EUR03FT009.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::201) by VI1PR08CA0269.outlook.office365.com (2603:10a6:803:dc::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Fri, 28 Feb 2020 11:40:26 +0000
Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT009.mail.protection.outlook.com (10.152.20.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Fri, 28 Feb 2020 11:40:26 +0000
Received: ("Tessian outbound d1ceabc7047e:v42"); Fri, 28 Feb 2020 11:40:26 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: deec98c42564ffcd
X-CR-MTA-TID: 64aa7808
Received: from 91ebdb8d0679.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 7A6B642B-6C1B-4F2D-82F6-0521FFF94C39.1; Fri, 28 Feb 2020 11:40:21 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 91ebdb8d0679.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 28 Feb 2020 11:40:21 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GU6xsz1Dr57q/0Lpo4VI2jAeOPe7lA24o3nHtX/X7E+PTRoW1br44p3mRexjEDreEwA4c4FbNT8q+CjRnb3ceERavaijcSZ1ZuhKuz/7e41kouAwpl72ZTe0KCYSLFkhYLY0wPEaXKnvli+nTIseBXoB5a96JVvM3tabxWmIKuEOkXd3mHmGgp3UuNkue/m0/o1FjDCwUS3ElzrjkKQ5YpFGDHD0TWw1l++JbdvR/C2LgAYg2PDHAws6mxoURkZzazMbJ71vtAyh1+DeKAuGjBp1Q/SmpMKAmJtAuUfu5ZN7HAf4yFL+akTtRf6O1M7k40aOKFmrEmKMgDeaMeWzFA==
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=SHXIbvmVD/0+jIJpsCb/pUu0tBij5QCugHIEqnuIr+s=; b=GZcgJTsNnjd8lu72fXAaDqqdbUlsu0KRv5UoFjCerjwh5zjxnloQ0mXH8QMKaYmPHgT8AdktTzG6MOdKU8mRJx0NxdwHo2TwYaS670Svafmqnidh+i1E/RDUjA4wdyB7mS6/Vv9PPdPSLM2EEm8mFEI+fy06yBg/cTrIYyMx0jfPSEuaGBfZoaDReh+BQkQk/GpfC6IYZ0RDsbHu5qU5ye4PVBTeCiuKlcDjND3g3u6R/4XK6j9J24w9aDwIyOWY8XKsdMuIBVIFcDNnI4Cks9k8LKVOEf124K+suQMjcqK+E1Pv1kK26H+s9E47ugZT9rwOtNdjZyQnkQgIuesCDw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SHXIbvmVD/0+jIJpsCb/pUu0tBij5QCugHIEqnuIr+s=; b=QxP05SnL/EcDbmaIidMXkYLCucN5Ytrik7By6T97AMsEg/GyEdqh5gsOw7r/h0QdEAvAzrk4KukiRMBxOUDXJcHHHju43B27z1Lx9MpUSdY9FDbuQTRs4PczAFlkdEbcs8PlJ9qAZfkjzUa5TTlo4Lzb3zWaPVqRIose+cHjyZw=
Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (10.255.99.138) by AM6PR08MB4966.eurprd08.prod.outlook.com (10.255.123.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Fri, 28 Feb 2020 11:40:18 +0000
Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::7960:8949:a754:4288]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::7960:8949:a754:4288%7]) with mapi id 15.20.2750.024; Fri, 28 Feb 2020 11:40:18 +0000
From: Brendan Moran <Brendan.Moran@arm.com>
To: Thomas Fossati <Thomas.Fossati@arm.com>
CC: Adrian Shaw <Adrian.Shaw@arm.com>, Koen Zandberg <koen@bergzand.net>, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>, suit <suit@ietf.org>
Thread-Topic: [Suit] Parameters and Commands
Thread-Index: AQHV7XQQ5gRwvIJ0lUyjBRqJJXWLg6gvGNGAgAAgvYCAAA9lgIABM9gA
Date: Fri, 28 Feb 2020 11:40:18 +0000
Message-ID: <798F1A9A-6B23-4999-9D1F-6BD5AB47EFF8@arm.com>
References: <27913A6B-F42C-4AA9-8A7A-64B1D546C13C@arm.com> <5CBBCF38-5431-4BF7-891D-E4451ECDEAC5@arm.com> <D2CE89E8-BCBA-4BBF-BCAD-2A2C2A558786@arm.com> <817B5E95-C304-4AE6-A950-9514DDB2A3FD@arm.com>
In-Reply-To: <817B5E95-C304-4AE6-A950-9514DDB2A3FD@arm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.60.0.2.5)
Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com;
x-originating-ip: [217.140.106.53]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 9c2031b3-ae23-4408-3e60-08d7bc430115
X-MS-TrafficTypeDiagnostic: AM6PR08MB4966:|AM6PR08MB4966:|AM5PR0801MB2049:
x-ms-exchange-transport-forked: True
X-Microsoft-Antispam-PRVS: <AM5PR0801MB2049C20F5499EBD24185EDD9EAE80@AM5PR0801MB2049.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:9508;
x-forefront-prvs: 0327618309
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(376002)(346002)(136003)(39860400002)(199004)(189003)(186003)(26005)(5660300002)(81166006)(37006003)(8936002)(81156014)(54906003)(2906002)(66556008)(8676002)(53546011)(478600001)(71200400001)(316002)(6512007)(6506007)(6486002)(66446008)(6862004)(33656002)(4326008)(66946007)(76116006)(66476007)(64756008)(6636002)(36756003)(86362001)(2616005)(91956017); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4966; H:AM6PR08MB4738.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: iWIwKK4/KWCXqTF/eBTY2vJJ8OSiZEYbMYMaC+XKh4CwD0kTG/ngwXVId2B08GgAWfpft14xyETN+AV9oiNfGimWIGTztBgKxbNVjpZ1GoZno5IQfF0VD31zfmNNgT/mH3BP9asTJyPB5WGvZNDO3MfX8Dq5zef4yUuzo6QgbGgVLyoLfcDe3HN/NOfXyFxaC7vd0zYJGOJbpTMVUQxSD970YxZ0GwpshPZcPVkX1x2IQ/93WnZABj9TTyfAkjX9PSffsx/Wy5dPwQ2e8LunYp9tEJi1BJzydoal22hYHSepYfJXXFFVHafVvxxchQmidbRs31h3Averu4HqfnF49OLJuSBVpZ/kkDpc7ACvAj0kp3xFSg6O1RlGBBm17dNjlu7Cvo/Jl4J5gTio49Ulv4KlexDUy78N4ezjrHHXpAQthXv+EIyWD0hYFPq0uCnA
x-ms-exchange-antispam-messagedata: hbWb1/G/PxZQTLTANYaIizQiJSENshXDaQJsO2CBRM9UpHevXcFiLxxdB9S9380T8GkXeYGkEMr/BbCEDRWcgMs/xx9Y7uCibV9H8FPuZn2sj2m3GS4ZIC675rVCj7bA9vLmVw/CNLBsRVdsZfiB2Q==
Content-Type: multipart/alternative; boundary="_000_798F1A9A6B2349999D1F6BD5AB47EFF8armcom_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4966
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT009.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(396003)(376002)(346002)(199004)(189003)(316002)(70586007)(70206006)(26005)(5660300002)(6512007)(81166006)(81156014)(6862004)(2906002)(4326008)(2616005)(86362001)(336012)(33656002)(186003)(6636002)(6506007)(53546011)(37006003)(8936002)(54906003)(33964004)(6486002)(45080400002)(8676002)(26826003)(356004)(36756003)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0801MB2049; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 7b038c5d-ccd6-4018-17a8-08d7bc42fc7a
X-Forefront-PRVS: 0327618309
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: pPI0y+OeExTcYgFDAlKcyG6++OSiULtPXFMHLE3TI0t/uSqEi5MgGYBVgRi3kmjr0lrS6LEpbFYX//hbm7Csm6QX1BE9pheW0FA17SB2TUe73PtX0kFlFkX+gG6wUFTsOF1TqpGBi+OrknQB0JgIp3/XAW37SMdLLVwcljVO/SFoKAOQIjEOtwdj+LcXGn2s6jp/1vuBCcfDx9Px+f1HMMlaASb/AQGOr87oUTFsfvG99yOzBV1vTqXDZr6TiNsgNMwpcHOt5bHn/Us21HyCXpVS/tyICJUx1OmFvqZyvn9WoA3+qy9qj1TNFV4jFhfX2i2fBuN27BJ6BnaRWUdXp4zC1tk1mzGrGRXggEEoqY+Hz12GRkWfE+twbcIvZac6KgL58RTe2RtJ4pc+XYTxMel7stcEKGI9uj/Fkj3KdcDSpnFGeH7vag5bKHjSnCFy
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2020 11:40:26.3134 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c2031b3-ae23-4408-3e60-08d7bc430115
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB2049
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/PvkOIrEXeM0cF8d0uMmBxFAzbPM>
Subject: Re: [Suit] Parameters and Commands
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 11:40:36 -0000

Hi Thomas,

I think we’re confusing the steps of validation/execution a bit here. The order is:


  1.  Verify firmware author’s authorization. (Signature validation)
  2.  Execute Manifest
     *   Each time a condition is encountered:
        *   If measurement is requested in manifest, record measurement
        *   If measurement is required by internal policy, record measurement
  3.  Seal the measurements (e.g. signature)
  4.  Execute the firmware image

You’ve said that BL2 is only trusted after BL1 verifies it. However, this is handled in a modular way in SUIT. The manifest is verified prior to execution, so BL1 can trust it. When BL2 is verified, the BL2 manifest is already verified and trusted, so it can be trusted to indicate the need for a measurement to be recorded.

I think it’s important that we strongly define the purpose of each security mechanism we have in place. Secure boot is for authority enforcement: only authorised parties can place firmware on a device. This leaves some gaps: Is the firmware authorised, but old? A device with no secure time source can’t know that. If a third party wants to interact with a device, knowing that the firmware is authorised isn’t good enough, they have to know it’s the expected firmware—version numbers can lie—so we need a strong guarantee of exact version that secure boot alone cannot provide.

Measured boot fills these gaps. The “version” of the firmware is exposed precisely via a trusted third party: the previous execution stage.



Let’s try and define exactly which threat could be opened by allowing the signer of the manifest to also set measurement policy. First an assumption: the holder of the private key for authorising firmware has become nefarious: change of heart, theft of keys, etc.


  1.  The manifest author tries to hide that a version has changed by not to reporting the firmware.
     *   The verifier notices that firmware version isn’t being reported and takes corrective action.
  2.  The manifest author tries to hide that a version has changed by making a measurement before an update, but not reporting after
     *   This attempt at subterfuge is visible in the manifest and its lifetime is limited. The next measurement will make it irrelevant.
  3.  The manifest author tries to hide that a version has changed by recording a measurement of one offset, but executing from another.
     *   This attempt at subterfuge is visible in the manifest. It can be further exposed by requiring offset measurements in multi-image devices.

Are there other threats here? I don’t think there’s much space for a bad actor in this.

I would argue that we make it required for:

  1.  A condition-image to specify either Record-on-success or Record-always.
  2.  Run Image to specify either Record-on-success or Record-always, and to require Run Image to automatically invoke a condition-image

I think that would remove any scope for bad actors to even attempt to hide, while still allowing flexible reporting and, more importantly, a sensible way to communicate verification policy to a verifier.

Best Regards,
Brendan


On 27 Feb 2020, at 17:18, Thomas Fossati <Thomas.Fossati@arm.com<mailto:Thomas.Fossati@arm.com>> wrote:

Hey Brendan,

I'm having a bit of trouble parsing this bit:

On 27/02/2020, 16:23, "Brendan Moran" <Brendan.Moran@arm.com<mailto:Brendan.Moran@arm.com>> wrote:
[...] For example, BL1 loads BL2. BL1 trusts the author of BL2
(which is the basis of secure boot).  BL1 executes the policy laid out
by BL2’s signer.

BL1 can trust BL2 only after it has measured it, therefore "executing
the policy laid out by BL2's signer" can only happen *after* a
successful verification, do you agree?  If so, there is a temporal
mismatch in the logic above.  That, or I am missing something important,
which is what usually happens :-)

cheers!


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.