From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0C14CC433F5 for ; Thu, 10 Feb 2022 07:55:31 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 076B581109; Thu, 10 Feb 2022 08:55:29 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="KVAl9USi"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 95681810F3; Thu, 10 Feb 2022 08:55:26 +0100 (CET) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 403A880FE1 for ; Thu, 10 Feb 2022 08:55:23 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ilias.apalodimas@linaro.org Received: by mail-wr1-x42a.google.com with SMTP id k1so7970964wrd.8 for ; Wed, 09 Feb 2022 23:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=VgN/kSSV5pnCc5EHUl2spg+yWroLu71jydPgmJsUn2k=; b=KVAl9USi29KthFKncF0S7mSSd85rfoztMCjPLEWFufpQ9tTHlbTP2R64FTbozPEs2H f4L/5O/CFNWmHrjVqbQ+aQqRpIpdN+YWRuGWsfLQd48vO7x+tLypm/zhgmK2hjeqF89+ 0QpNWmiTfXGgwL99IOsTKAxDYgVLamIH1qmY2pWZR8R/c46Q/h70EuBVdWkTb+eAXBk3 SD+YShGwaQsJKHK8qC/3ZF8dFIkSO3rfpU61mzf5l4Dhpoc7DWy5Z69ajUlYydcJjUsW nd7v/FpzrYQw/Pzt0yl1unTNTplpRVH1RnrFSUOgXA7sKCPrXjvxzm0U6G3ZyWdScs9z sFIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=VgN/kSSV5pnCc5EHUl2spg+yWroLu71jydPgmJsUn2k=; b=4Yz3QdmsNccVT/itO+zMkd/snIe2WVWbqClukeHDF4G2xxsCCui0L5NzUOeN09MPMI AEldAuvhCWwnFYFb/TkzrSo8jVcuXGCS/RJu7U5L6vGNgF0BL9mnWn4v8CN1JO0aGB2n UZRrJXvROm2hoddQtW2Gmm0eZmQmi6o4EIeRMuwevXqR/QtVjvskk04ng/PFwUhrysL3 /CKeTTzSgZs/IuzNv7GYvepclFyUwwfAK3M8g/Rs61EIZZmLmgNCjE4SJLgFBCyD5tVB sLcCa8ZvDv0BbClPha43z7wpXZot0ABC7BKHCS6doUcqLqqMDWA8hFD3R0N4T+MHMN4Z UH/w== X-Gm-Message-State: AOAM533IkJRIhy/VYJ+TKI3ope2bsSmUEkmVKjDrbHdfc2INj56UhoBw JVaeF5zdfIqFd8aAl7p+dLb7sVetrVjwrw== X-Google-Smtp-Source: ABdhPJwUXXWwL644Ik9ofQDXpChRIo8awoh1UI1PyKQW5fotEuN8XrhcRU+0G5CSUBvCuERVLhB5iQ== X-Received: by 2002:adf:fe4f:: with SMTP id m15mr5252718wrs.133.1644479722857; Wed, 09 Feb 2022 23:55:22 -0800 (PST) Received: from hades (athedsl-4461669.home.otenet.gr. [94.71.4.85]) by smtp.gmail.com with ESMTPSA id n14sm18259789wri.80.2022.02.09.23.55.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 23:55:22 -0800 (PST) Date: Thu, 10 Feb 2022 09:55:20 +0200 From: Ilias Apalodimas To: AKASHI Takahiro , Heinrich Schuchardt , u-boot@lists.denx.de Subject: Re: [RFC PATCH 1/2] efi_loader: fix dual signed image certification Message-ID: References: <20220204073202.4141198-1-ilias.apalodimas@linaro.org> <20220210051348.GD12412@laputa> <730ecf32-43d3-58be-63a3-122985d25583@gmx.de> <20220210074115.GH12412@laputa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220210074115.GH12412@laputa> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean On Thu, Feb 10, 2022 at 04:41:15PM +0900, AKASHI Takahiro wrote: > On Thu, Feb 10, 2022 at 09:33:46AM +0200, Ilias Apalodimas wrote: > > > > > > msg = pkcs7_parse_message(auth, auth_size); > > > > [...] > > > > > > > > @@ -717,32 +665,32 @@ static bool efi_image_authenticate(void *efi, size_t efi_size) > > > > > > */ > > > > > > /* try black-list first */ > > > > > > if (efi_signature_verify_one(regs, msg, dbx)) { > > > > > > + ret = false; > > > > > > EFI_PRINT("Signature was rejected by \"dbx\"\n"); > > > > > > - continue; > > > > > > + goto out; > > > > > > > > > > If we go to "out" here, we have no chance to verify some cases: > > > > > 1) An image has two signatures, for instance, one signed by SHA1 cert > > > > > and the other signed by SHA256 cert. A user wants to reject SHA1 cert > > > > > and put the cert in dbx. > > > > > > > > I am not sure I am following, what does he gain be rejecting the SHA1 > > > > portion only? Avoid potential collisions? > > > > > > If an image has a SHA1 and a SHA256 signature attached and SHA1 *or* > > > SHA256 is in dbx, we must reject the image. Don't expect a dbx entry for > > > each of the hashes. - But isn't this what your are doing here: for all > > > signatures of the image look for one hit in dbx? > > > > > > > Yes exactly. Any match on dbx of any certificate or sha256 of a certificate > > or a sha256 of the executable will reject the image. > > But we believe that SHA256-based signature is still valid > even if we don't trust SHA1. UEFI spec 2.9 page 1715 describes exaclty what we propose here as a change. The SHAxxx choise is irrelevant, any potential match should reject the image. > > > Regards > > /Ilias > > > Best regards > > > > > > Heinrich > > > > > > > > > > > > But this image can and should yet be verified by SHA256 cert. > > > > > > > > Why should it be verified? My understanding of the EFI spec is that any match > > > > in dbx of any certificate in the signing chain of the signature being verified means > > > > reject the image. > > > > > > > > > 2) A user knows that a given image is safe for some reason even though > > > > > he or she doesn't trust the certficate which is used for signing > > > > > the image. Then he should resign his image with a proper certificate. Regards /Ilias > > What do you think of this case? > > -Takahiro Akashi > > > > > > -Takahiro Akashi > > > > > > > > > > > } > > > > > > > > > > > > if (!efi_signature_check_signers(msg, dbx)) { > > > > > > + ret = false; > > > > > > EFI_PRINT("Signer(s) in \"dbx\"\n"); > > > > > > - continue; > > > > > > + goto out; > > > > > > } > > > > > > > > > > > > /* try white-list */ > > > > > > if (efi_signature_verify(regs, msg, db, dbx)) { > > > > > > ret = true; > > > > > > - break; > > > > > > + continue; > > > > > > } > > > > > > > > > > > > EFI_PRINT("Signature was not verified by \"db\"\n"); > > > > > > + } > > > > > > > > > > > > - if (efi_signature_lookup_digest(regs, db, false)) { > > > > > > - ret = true; > > > > > > - break; > > > > > > - } > > > > > > > > > > > > - EFI_PRINT("Image's digest was not found in \"db\" or \"dbx\"\n"); > > > > > > - } > > > > > > + /* last resort try the image sha256 hash in db */ > > > > > > + if (!ret && efi_signature_lookup_digest(regs, db, false)) > > > > > > + ret = true; > > > > > > > > > > > > -err: > > > > > > +out: > > > > > > efi_sigstore_free(db); > > > > > > efi_sigstore_free(dbx); > > > > > > pkcs7_free_message(msg); > > > > > > -- > > > > > > 2.32.0 > > > > > > > > > > > > > > Thanks > > > > /Ilias > > >