|
|
Post by michaeldu on Nov 23, 2021 9:46:42 GMT
Currently it is able to use SecureBoot.ResetKeys or SecureBootDatabase.ResetKeys to Delete/Reset the secure boot key database. We have the request to install the certificate for secure boot. But the property "Certificates" in SecureBootDatabase is readonly and no action defined for certificate installation. Is there any concern to add this support?
Let me elaborate a bit more on the request. We want to enable the secure boot for a specific OS while its certificate is not in the secure boot db, so we have to install certificate by USB stick. Obviously it is not convenient for a bunch of servers. We are looking at the redfish to provide an interface to normalize this case. I'd appreciate your comments on this.
|
|
|
|
Post by shawn on Nov 23, 2021 9:59:36 GMT
It's reasonable that the property "Certificates" in SecureBootDatabase is readonly since it's only a link links to the CertificateCollection. I think it's fine to create a certificate by POSTing to CertificateCollection with those requiredOnCreate described in Certificate_v1.xml like others creating a resource in a collection.
|
|
|
|
Post by michaeldu on Nov 24, 2021 9:23:54 GMT
Thanks. It works for me if we can install the certificate by posting it to CertificateCollection in SecureBootDatabase. Anyone has more comments?
|
|
|
|
Post by mraineri on Nov 24, 2021 21:12:29 GMT
Shawn is exactly right; the normal method would be to POST to the collection.
|
|
|
|
Post by michaeldu on Nov 25, 2021 13:17:54 GMT
Thanks. The redfish interface is clarified. The question is back to the secure boot. Is it OK to install the certification for secure boot by POSTing to collection. Currently the uEFI either needs the physical presence to install the certificate without KEK verification or use KEK to verify the certificate while installing using uEFI API from OS. Any concern to install the certificate without KEK verification via Redfish interface? I think it should be OK in terms of security that uEFI fetches the certificate from BMC and installs the cerficate without KEK verification. It might be a UEFI question.
|
|
|
|
Post by mraineri on Nov 25, 2021 15:48:18 GMT
I think that will largely be dependent on the scope and capabilities of your implementation. I can see KEK verification could be done by the Redfish service, and when the user attempts to install the certificate, the POST request is rejected (likely a 400 Bad Request with messages indicating KEK verification failures). One other possibility is if the certificate needs to be actively consumed and verified by UEFI, the POST operation could result in a task, and the task doesn't finish until UEFI extracts the certificate from the BMC, verifies it, and responds to the BMC with the outcome of the sequence.
|
|
|
|
Post by michaeldu on Nov 26, 2021 1:52:37 GMT
Thanks, Mike. What you described makes sense. Currently the server vendor has PK/KEK/DB/DBX preloaded in uEFI, but that's limited to the specific OS vendor like MSFT. Unfortunately there is no signing of preloaded KEK for our certificate but we need to install it and enable the secure boot. So far there is no consensus on the verification, It depends on the implementation. It could be your described implentation. The net is we want to install the certificate without KEK verification. How can we make it clear that no verification for the certificate installation? ... Add a new action with explicit parameter ...? Any idea?
|
|
|
|
Post by mraineri on Nov 26, 2021 13:49:09 GMT
If this is something you expect a user to control directly, it sounds like you'd need to use an OEM property that the client can provide when installing the certificate. If this is going to be a common use case for others, then we probably need to discuss this further internally.
However, I suspect quite a few users don't necessarily understand this type of control. You could simply accept the certificate as is at all times. There could also be logic internally to make decisions on whether or not to verify the certificate.
|
|
|
|
Post by michaeldu on Nov 27, 2021 1:18:42 GMT
It is common use case in secure boot especially for the OS vendor. It is new to install secure boot certificate thru Redfish interface. I don't see any implementation for it so far. Correct me if my misunderstanding. It is good to discuss it further and clarity the expected behavior. I think it can ease the secure boot, for OS vendor in particular.
|
|
|
|
Post by mraineri on Nov 29, 2021 13:30:08 GMT
The question I have is specifically around the aspect of whether a user is able to specify a certificate is to be verified when installed. If this is something UEFI, OS vendors, and other expect to be available, then we should discuss this further.
As far as I can tell everything else other than that one aspect is in place today in Redfish.
|
|
|
|
Post by michaeldu on Nov 30, 2021 2:22:45 GMT
Yes, that's the key point.
|
|
sd
Minnow
Posts: 1
|
Post by sd on May 3, 2022 18:19:49 GMT
To just add to micheldu's request. This is a use that even we are looking for.
Is it possible to programmatically add secure boot keys to the DB?
|
|
|
|
Post by mraineri on May 5, 2022 1:01:24 GMT
From discussions with some of the UEFI folks, my understanding is that keys are stored as certificates. So, if you're adding a new key to the database, you install it as a certificate.
samer would you be able to help confirm this? |
|
|
|
Post by samer on May 24, 2022 19:21:58 GMT
If I understand the question correctly, it is whether updating the SecureBoot databases (including adding an OS cert in DB) from Redfish requires the normal signature validation as described in the UEFI spec. Per UEFI spec, when SecureBoot is in User Mode, an OS (or SW) may attempt to modify the SecureBoot databases (by calling SetVariable() ), but that requires that the payload is signed (as a Signed UEFI Variable) using a key that is chained either to the KEK or PK.
You can think of the Redfish POST/DELETE to the SecureBoot Certificates (or Hashes) collections to be something similar to the "add or delete entry" method that a user can do from the UEFI setup menu. In the UEFI Setup menu, the user is considered "physically present", and is able to enroll (and delete) entries to/from all SecureBoot databases, including PK/KEK/DB/DBX. For example, the user may be able to add a certificate of a new OS to DB, without having that entry signed (as a Signed UEFI Variable payload) with the KEK key. In this scenario, it is also assumed that the user is authenticated (e.g. entered the UEFI Setup Menu Administrator password, etc ...). All of this however depend on the platform security policy. A platform may be locked down and not allow such operations, or require a special privilege or being in a special mode , etc..
Similarly from Redfish, if the user authenticates with sufficiently high privilege, they could be allowed by the implementation to POST/DELETE certificates (or hashes) from all of the SecureBoot databases, without requiring the payload to be a "Signed UEFI variable" that is chained to the KEK/PK for verification. This becomes a platform security policy, and whether this operation is allowed in all modes, or require the machine to be in some specific mode (such as manufacturing, deployment, ..). For example, a platform may allow this to be done out-of-band (remotely) over a secure HTTPs connection to the Redfish service, but the same platform may not allow this operation to be done in-band over the Redfish Host Interface. These are all platform security policy implementations.
|
|
