...
$ openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Platform Key/" -keyout PK.key -out PK.crt -days 3650 -nodes -sha256
$ openssl x509 -in PK.crt -out PK.cer -outform DER
$ openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Key Exchange Key/" -keyout KEK.key -out KEK.crt -days 3650 -nodes -sha256
$ openssl x509 -in KEK.crt -out KEK.cer -outform DER
$ openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Database/" -keyout DB.key -out DB.crt -days 3650 -nodes -sha256
$ openssl x509 -in DB.crt -out DB.cer -outform DER
Choose an EFI application in your edk2 build aritfacts to do the test, or use this EmptyApplication-Riscv.efi
$ sbsign --key DB.key --cert DB.crt --output EmptyApplication-Riscv.efi.signed EmptyApplication-Riscv.efi
Update the sbsigntool to the latest one if you encounter "invalid PE header magic" issue in signing riscv64 binary
...
By default, TianoCore boots up into Setup Mode, meaning the platform is not provisioned with any keys and the user can take control. To take control, go to the EFI menu screens (type 'exit' command if you’re at the efi boot prompt) select the “Device Manager” entry, then “Secure Boot Configuration”. Here you will see the status of the Secure Boot flag (“Attempt Secure Boot”) and the platform mode. Setting the platform from “Standard Mode” to “Custom Mode” will allow you to edit the keys. Once the platform is in “Custom Mode”, a “Custom Secure Boot Options” menu will appear and you will be able to manipulate the four sets of key databases from here. The format of all key files for openssl generated keys is DER format (by default openssl generates PEM format). Note that the KEK, db and dbx options will ask you for a GUID as well as a key file. The GUID is the platform’s way of identifying the key. It serves no purpose other than for you to tell which key is which when you delete them (it’s not used at all in signature verification). By default, since GUIDs aren’t really human readable, I just ignore this and the GUID is set to all zeros.
...