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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1EF03C3DA78 for ; Tue, 17 Jan 2023 20:30:42 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4NxLB82kbbz3ch5 for ; Wed, 18 Jan 2023 07:30:40 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=permerror header.d=sandelman.ca header.i=@sandelman.ca header.a=rsa-sha1 header.s=mail header.b=LqokGJ0g; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=sandelman.ca (client-ip=2607:f0b0:f:3:216:3eff:fe7c:d1f3; helo=tuna.sandelman.ca; envelope-from=mcr@sandelman.ca; receiver=) Authentication-Results: lists.ozlabs.org; dkim=permerror header.d=sandelman.ca header.i=@sandelman.ca header.a=rsa-sha1 header.s=mail header.b=LqokGJ0g; dkim-atps=neutral X-Greylist: delayed 476 seconds by postgrey-1.36 at boromir; Wed, 18 Jan 2023 07:29:45 AEDT Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4NxL951rsyz3cg0 for ; Wed, 18 Jan 2023 07:29:44 +1100 (AEDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CBF143899E; Tue, 17 Jan 2023 15:50:47 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1CfRSs6KsBh7; Tue, 17 Jan 2023 15:50:47 -0500 (EST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 3166B3899A; Tue, 17 Jan 2023 15:50:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1673988647; bh=pUZ5T9TI5aCpwYbLupV7Z3pCgqToqpQsfVOV6GvmlOo=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=LqokGJ0gl75aV91rDYdWoqBvl0QX+F8ZZKcUWnE+h19lM+po9XYMeFER7DiHdbhgH QYpNevaf4QIUzocG0pAepCUHWQUZHaxudoUSdhzeH71joiyvTK+rtWDRmpdK1l80kP cQhMJ1w948DIoh2Fcm4wiGjG0zoayj8d1TikfxFRVMv6UlTaMkVm6jw5PHYJzrIujh bXgmXIrdEw/tmeCrVk5jtgvtIp970iBWmllFGvXPc/StyCMmqxfQbd/waLorzPWxTE jpWI1cNheo0D5wRGF/4ejv3t/97QbbtKs8bHy3pA6EzY661SqjhyLGdr8k4Ic1yCkX rG7j4/wkhWbpg== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E7A4749; Tue, 17 Jan 2023 15:21:40 -0500 (EST) From: Michael Richardson To: Lei Yu Subject: Re: BMC image generation without private key In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;<'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: openbmc Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" --=-=-= Content-Type: text/plain Lei Yu wrote: > For dev builds, it uses the insecure development key in the tree. > For release builds, it requires the `SIGNING_KEY` env to point to a > secure key to sign the image. > It is considered insecure because it requires the build server to > access the private key. The build server requires authorization from the holder of the private key to create signatures. One way is have direst access to the private key. I think that if the build server is so untrusted, then maybe there are other problems :-) I didn't find where SIGNING_KEY is used. I suspect that the signature is generated by an openssl command, and so actually it could be directed to an engine/HSM. BUT, in some cases the process is to build something as a devel-ish build, and then if QA approves, it is signed with the release key afterwards, and so your process would make sense. > An alternative is proposed: > * A new `SIGNING_PUBLIC_KEY` env is defined to point to a public key. > * The above key is default to empty, and the behavior is the same as > before, using the insecure development key to generate and sign the > image. > * With a valid `SIGNING_PUBLIC_KEY`: > * The public key is installed into the BMC image. > * The generated tarball is not signed, only containing the MANIFEST > and the image. > * A new `gen-bmc-tar` tool will be introduced to sign the above > tarball, like `gen-bios-tar`. > * If both `SIGNING_PUBLIC_KEY` and `SIGNING_KEY` is set, throw an error. There is a chain of custody concern between building tarbar and running gen-bmc-tar. So, I'd always sign with the development key, and I'd validate that signature and then replace it. > With the above proposal, the build does not require the private key > anymore and the user could install the public key during build, and > sign the image separately. > Comments are welcome. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFFBAEBCgAvFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmPHA1QRHG1jckBzYW5k ZWxtYW4uY2EACgkQgItw+93Q3WUnxAgAwYKtAgcBl3Fp0Yfv8Veqe7NfVEzud4sU NqBTMhEabzbXi8TvRmxBOg8LzwUQ98lvybsHdKkZLuFfZE+I9LjBa8hvfBiUzCOj bUr6IYQLtrrtZfli8jUCL6TagXjm8hMohLwZOF6rv1ct0AKTV80mjvVsXvVrddlA CqGRBl6i7r0x4nAUisHb7bo2gOlpTYefM/W81tJQLdt597fPUoARgwGVwvJP/qa3 4AjvMTguj3vppvbg7nhlcyxkMskdU3srvKXWx3U++VwaZv8awDRz5sfTFkKuR3iw VYdvUt1a7VxRSEMOnlrFYDuy5DLJLOJWCBpUoaPDPzTYz2G4ENaXsg== =RYy4 -----END PGP SIGNATURE----- --=-=-=--