From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.171.2.60; helo=ma1-aaemail-dr-lapp01.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8D5B721B02822 for ; Tue, 2 Oct 2018 17:28:30 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id w930LgIv059430; Tue, 2 Oct 2018 17:28:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=e5gbrYffDILJ+7gvXvWqnSdn806beXkLh3xOwbKermk=; b=PwPf1eq2tJaExiS1Bujax6bCqoldH5dDeD48wmgzjcudRnlCbmpXXv2e4h909okLO7D9 8z6uPhKIQ52isjSDLU03s9IX1OaY6pt+pFM4UvV5T2yn7PdtZnGWsHwY3+rgLyHkRKrg WOiVycYYeBmTZ6xuOOoJscMQ0I5Usj10t/XoxocO3a/gVKGb/qVP1lHM8bGYQx/8RuAH a7M5aWWePsGcFDwJv8hbSgGqLxqIunOLz9GRsd9wgm3yqWoDKuYaOnGQ/VgPTfVLExNu fRrMAbcdeIOXgcjVovInJr6PVq9dvwiy+6yOMvFdSosvAuDPaZgIbtgINYABzHwRTnDq Sg== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2mt8297eac-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 02 Oct 2018 17:28:29 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PFZ00HC5YNFZ660@ma1-mtap-s03.corp.apple.com>; Tue, 02 Oct 2018 17:28:28 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PFZ00M00Y9K6400@nwk-mmpp-sz11.apple.com>; Tue, 02 Oct 2018 17:28:27 -0700 (PDT) X-Va-A: X-Va-T-CD: 52598b7559084744ba285118ccbb5e7a X-Va-E-CD: a4c7e5fdb44b7fa99cf5d96908ba2740 X-Va-R-CD: e4d92ad1e7a5a9a2612ed8602d610412 X-Va-CD: 0 X-Va-ID: f197c9a9-8ed8-44c8-b3b3-b7f70e5e640e X-V-A: X-V-T-CD: 214c7cbf61a9c062c96ac8e0eb61c876 X-V-E-CD: a4c7e5fdb44b7fa99cf5d96908ba2740 X-V-R-CD: e4d92ad1e7a5a9a2612ed8602d610412 X-V-CD: 0 X-V-ID: e29529e6-948e-4d57-861d-b334bc92b032 Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PFZ00400YLY8600@nwk-mmpp-sz11.apple.com>; Tue, 02 Oct 2018 17:28:27 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-02_10:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1 Received: from [17.235.1.101] (unknown [17.235.1.101]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PFZ00KISYNEYN30@nwk-mmpp-sz11.apple.com>; Tue, 02 Oct 2018 17:28:27 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: <7fbefed2-f287-7dd2-4271-fba23ffaae8d@vmware.com> Date: Tue, 02 Oct 2018 17:28:19 -0700 Cc: edk2-devel@lists.01.org Message-id: References: <7fbefed2-f287-7dd2-4271-fba23ffaae8d@vmware.com> To: Petr Vandrovec X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-02_10:, , signatures=0 Subject: Re: How to correctly sign EFI Firmware Volume? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 00:28:31 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Petr, Mike Kinney and I just had an interesting conversation that relates to your question. It has to do with the FV being a file system and not really the FLASH layout. In the UEFI PI Spec and edk2 lingo you produce and FD (Flash Device) that consists of a set of FVs. There is not a standard way to discover the FVs in an FD, and this is something that is missing in the PI Spec. On most platforms there are multiple FVs so there should be a defined signing scheme for the entire FD. > On Oct 2, 2018, at 2:12 PM, Petr Vandrovec wrote: > > Hi, > I've sent this ot fw_os_forum, and was redirected here. Sorry if you are receiving this twice. > > > I'm looking at options how to sign our EFI firmware through some industry-standard embedded signature option, and signing whole firmware volume as described in Platform Initialization spec would definitely fit the bill. > > Unfortunately problem is that I cannot make sense of what should be actually signed. Chapter 3.2.1.1 of PI_Spec_1_6.pdf says: > > > 3.2.1.1 EFI Signed Firmware Volumes > > There may be one or more headers with a FormatType of value EFI_FIRMWARE_CONTENTS_SIGNED_GUID. > > A signed firmware volume is a cryptographic signature across the entire volume. To process the contents and verify the integrity of the volume, the EFI_FIRMWARE_VOLUME_EXT_ENTRY_GUID_TYPE Data[] shall contain an instance of WIN_CERTIFICATE_UEFI_GUID where the CertType = EFI_CERT_TYPE_PKCS7_GUID or EFI_CERT_TYPE_RSA2048_SHA256_GUID. > > > Part about WIN_CERTIFICATE_UEFI_GUID is easy. But what should be signed? > > Text says 'A signed firmware volume is a cryptographic signature across the entire volume.' - beside that 'firmware volume' is not a signature, what is 'the entire volume' ? Clearly Data[] entry holding signature cannot be part of the signature, as otherwise adding signature would invalidate that very same signature, so it cannot be signature of entire volume from first 16 reserved bytes in the header to the last byte of the image, but something else. > > Can someone provide clarification what should be signed? It seems to me like that intention is to only sign data portion of the volume, from the end of extended header to the end of volume. But that means that anyone can modify anything in the header or extended header without breaking signature. > > Are there any examples of signed firmware volumes? Unfortunately there does not seem to be any code in UDK for this feature. > > > On fw_os_forum I got recommendation to use EFI capsule format for signing. > > Unfortunately I cannot figure out how to make out-of-band signatures work for firmware volumes in a secure way: firmware module has to be multiple of (at least) 4KB, and must cover last 16 bytes of ROM (as that is where execution starts). Then I need to prepend capsule header (or wrapping firmware volume header) and signature in front of that. Dual SHA1/256 signing with timestamps takes about 5KB, so there are 3KB of free unsigned space left. > > If I leave those 3KB unsigned, anybody can remove them, shift signed image down by 3KB, and then have 3KB of unsigned code running at the reset vector :-( If some one can write your FLASH device they can just skip checking the result of your HASH, no need to shift things about. A really secure boot usually requires a mask ROM that checks the NOR FLASH. Something akin to Intel Boot Guard. Thanks, Andrew Fish > > Or I can do trial signing, figure out how long signature will probably be, and then extend signed area so that only capsule header and signature unsigned. That could work, but then I'm not signing firmware volume, but firmware volume with 3KB of data prepended to it (or firmware volume that is not multiple of 4KB, if I let our firmware volume to have arbitrary size), which is not exactly industry standard. > > And even if I do this, as image is dual signed, someone can remove SHA1 signature, shift rest down, and get about 1KB for the malicious code. > > So for all non-embedded signatures I'm always coming up with and require that signed payload ends with end of ROM, while I'm looking for just , without strings attached. > > > Thanks, > Petr Vandrovec > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel