1) Backlog review https://github.com/orgs/tianocore/projects/10/views/1
2 new items submitted. See section 3. 2) Old issue refresh https://github.com/tianocore/edk2/issues/12561 ( https://github.com/tianocore/edk2/issues/12561 ) Doug created PR https://github.com/Flickdm/UEFI-Specification-Release/pull/1. It is not linked to backlog yet. Not sure why. We will review next time, when Doug is back. 3) New issue 3.1) https://github.com/tianocore/edk2/issues/12688 EU-CRA spec: https://forge.etsi.org/rep/cyber/stan4cr2/en-304-623 https://labs.etsi.org/rep/stan4cra/en-304-623/-/blob/main/EN-304-623.md?ref_type=heads CRA issues with removing IEIT: The requirements that seem to have issues currently: ===== 5.6.21 [RQ-INTEGRITY-021] text: Requirement: The boot manager shall verify the entire certificate chain to a trusted root, including validity periods and revocation status. Applicability: Applies to all boot managers with verified boot. Arguably this says the root certificate revocation has to work in a way we can't support, i.e. if an intermediate cert is in "db" but its issuer is in "dbx", that's a revocation. On a technical basis we support revocations by TBS hash, which means we can't necessarily tie the trust anchor in "db" to anything above it in its issuance chain. I think instead we can interpret "a trusted root" to mean the trust anchor in "db" and not the root of the chain it belongs to, but I have no way to know if this would be acceptable or not, because there's no evaluative criteria in the spec. 5.8.18 [RQ-AVAIL-018] text: Requirement: The boot manager shall indicate errors with sufficient detail to guide recovery actions. Applicability: Applies to all boot managers with recovery capability. This means if "Boot0000" fails and "Boot0001" succeeds, we need to somehow know why and /indicate/ it (where/how? not specified.) Fundamentally the OS can only know that some of the time, as some failures could result in OS code not even being run. There's no mechanism to get this kind of thing from the firmware aside from just noting that "BootCurrent" is set to something other than the first entry in "BootOrder", but of course that could have been selected by the user. There's no way to know. 5.11.1 [RQ-LOG-001] text: Requirement: The boot manager shall record measurements of boot components and security-critical configuration in tamper-resistant storage before execution or handoff. Applicability: Applies to all boot managers with measured boot. This could apply to the IEIT or the TPM log, though in either case there's no such thing as tamper-resistant storage we could put the TPM log in. Unless we just define "we removed the writable bit and unsigned code can't be running" as tamper-resistant storage. Why not? 5.11.2 [RQ-LOG-002] text: Requirement: The boot manager shall protect measurement records from unauthorised modification or deletion using cryptographic mechanisms, hardware-protected storage, or tamper-evident recording. Applicability: Applies to all boot managers with verified or measured boot. Same issues as 5.11.1, plus I don't know how we'd use cryptographic mechanisms to prevent deletion. I can come up with some ideas for /detecting/ modification or deletion (i.e. sign the log), but that's not what the rule says. Again we could define some bits around what "unauthorized" means, since there's absolutely no obvious definition of what that means in this context to begin with, but it's not great. 5.11.4 [RQ-LOG-004] text: Requirement: The boot manager shall indicate security-relevant failures and state changes including verification failures, authentication failures, security policy violations, recovery mode activation, and execution of unsigned code. Applicability: Applies to all boot managers. If one boot entry fails the Secure Boot check and we continue and run the next one instead, and it works fine, is that a security-relevant failure? It seems like a verification failure and a policy violation, though it /isn't/ "execution of unsigned code". Like 5.8.18 above, we likely have no strong indication this even happened. ===== It seem EU-CRA did put some requirement for error recording. Image Execution Information Table may help here. The language of EU-CRA is not clear enough. E.g "indicate". We are still not sure if the current implementation meet the requirement or not. Some requirement (such as measurement) is not UEFI spec related. We can leave it to other working group (such as TCG). *AR: All* to review the text off line. We will discuss again in the next week. 3.2) https://github.com/tianocore/edk2/issues/12706 PKCS7 Protocol Usages: * James mentioned that EFI-TOOL is using PKCS7.VerifySignature() for PE image verification - See https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/lib/pkcs7verify.c * Peter mentioned that SHIM is not using PKCS7 protocol. It just copied the crypto pkg code and use AuthenticodeVerify() - See https://github.com/rhboot/shim/blob/main/Cryptlib/Pk/CryptAuthenticode.c Some discussion: * It seems the intention of PKCS7.VeriySignature() is to verify PE image. It is not a generic Pkcs7Verify. (See the difference between AuthenticodeVerify and Pkcs7Verify in EDK2 CryptoPkg. AuthenticodeVerify() adds wrapper first, then call Pkcs7Verify(), because "OpenSSL PKCS7 Decoder didn't work for Authenticode-format signed data due to some authenticode-specific structure.") * In efi-tool, since the hash of DB is NOT evaluated in PKCS7.VeriySignature(), the efi-tool will do DB hash evaluation before the VerifySignature, and allow the image if there is match. This is NOT aligned with EFI image verification flow, because DBX is ignored. All in all, the current text is not clear at least on 2 part. * The PKCS7.VerifySignature must support PE image verification, which is beyond PKCS7. * The NOTE for PKCS7.VerifySignature is NOT clear enough, which may cause the misuse of this API. *AR: Jiewen* to create a patch to clarify. 4) Some idea for image verification https://github.com/microsoft/mu_basecore/pull/1809 ( https://github.com/microsoft/mu_basecore/pull/1809 ) Jiewen added additional rule for one signer: * PE image multiple signature PE/COFF image: the three "multiple signer" mechanisms There are three structurally distinct ways a PE/COFF image can carry more than one signature. They live at different layers of the format: ``` PE Attribute Certificate Table (DataDirectory[SECURITY]) │ ├─ WIN_CERTIFICATE#1 ──► PKCS#7 SignedData │ ├─ SignerInfo#1 ─┐ │ ├─ SignerInfo#2 ─┤ (3) multiple SignerInfos │ └─ SignerInfo#1's unsigned attrs │ └─ nested PKCS#7 (2) nested signature ├─ WIN_CERTIFICATE#2 ──► PKCS#7 SignedData (1) multiple WIN_CERTIFICATE entries └─ WIN_CERTIFICATE#3 ──► ... ``` (1) Multiple WIN_CERTIFICATE entries — SUPPORTED. (2) Nested signature — SUPPORTED, but it is fundamentally single-signer. (3) Multiple SignerInfos in one SignedData — NOT supported. Reference: * UEFI Specification, driver signing. "Multiple signatures are allowed to exist in the binary’s certificate table (as per the “Attribute Certificate Table” section of the Microsoft PE/COFF Specification)". * PE Authenticode Specification. "signerInfos — This field contains a set of SignerInfo structures, which contains information about the signatures. Because Authenticode supports only one signer, only one SignerInfo structure is in signerInfos.". Also "digestAlgorithms — Because Authenticode signatures support only one signer, digestAlgorithms must contain only one digestAlgorithmIdentifier structure and the structure must match the value set in the SignerInfo structure's digestAlgorithm field. If not, the signature has been tampered with." Thank you Yao, Jiewen -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#122006): https://edk2.groups.io/g/devel/message/122006 Mute This Topic: https://groups.io/mt/119968405/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
