Re: [isar-cip-core][PATCH 6/8] change ebg sb signer and secrets to pk kek db

From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Schultschik,
	Sven (DI PA DCP R&D 2)" <sven.schultschik@siemens.com>,
	"cip-dev@lists.cip-project.org" <cip-dev@lists.cip-project.org>
Subject: Re: [isar-cip-core][PATCH 6/8] change ebg sb signer and secrets to pk kek db
Date: Mon, 21 Nov 2022 18:25:11 +0100	[thread overview]
Message-ID: <cc87f549-be75-00c9-dbf0-f37d6f9dd04d@siemens.com> (raw)
In-Reply-To: <DU2PR10MB503009A3EF056F4DAD581ADB900A9@DU2PR10MB5030.EURPRD10.PROD.OUTLOOK.COM>

On 21.11.22 16:10, Schultschik, Sven (DI PA DCP R&D 2) wrote:
> 
>> On 20.11.22 21:47, sven.schultschik@siemens.com wrote:
>>> From: Sven Schultschik <sven.schultschik@siemens.com>
>>>
>>> The secure boot setup with OP-TEE, u-boot and EFI works with a platform 
>>> key
>> (pk), key exchange key (kek) and signature database (db). isar-cip-core 
>> should
>> only provide one secure boot solution and so the key structure and setup 
>> needed
>> to be adjusted.
>>>
>>
>> I don't understand the purpose yet, specifically as the touched keys and the
>> signing structure was already use for UEFI secure boot, on x86 and ARM[64]. 
>> It
>> rather looks to me like you are committing a lot of stuff that can be easily
>> generated, given the secure boot key pair.
>>
> 
> It depends on the purpose you want to create.
> 
> My idea was to provide the complete PK,KEK,db structure as sankeoil and 
> possibility to be added to the build.
> 
> Your idea is to use the existing key end pem as "PK" and generate KEK and db 
> while the build is running.
> 
> - But then my question would be, why then not generating all snakeoil keys and 
> certs on the fly?

Because we use existing provisioning for x86 OVMF.

> - Or do you want only the PkKek-1-snakeoil key/cert to be provisioned in qemu 
> as "db"
> - or should the PkKek-1-snakeoil key/cert be used as "PK" and KEK and db 
> should be generated on the fly and signed
> by the PkKek-1-snakeoil key/cert?
> 
> It depends on the goal you want to achieve.
> 
> For production you only need the "db" to sign the efi file, but for qemu you 
> would need PK and KEK as well to be
> provisioned to the efi environment.

sbsign takes the private key and the cert to sign a binary. That cert
then has to be added into the cert DB on the target in order to validate
the signature later on. We do that during the build so far for U-Boot
and expect the x86 firmware to have been provisioning accordingly.

However, in order to model a complete UEFI device lifecycle, there
should also be the Platform Key and the Key Exchange Key involved. We
don't do anything about those yet for U-Boot, just set them to be
identical to the signing key. We can change that eventually, but I don't
see that related to adding RPMB as secure storage.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux