Parameterize secure boot keys

[jqueuniet]

Parameterize Secure Boot keys

The current Secure Boot pipeline uses two different set of keys, one is public, hard-coded in the SDK container filesystem, and intended for test builds, the other is pulled from an Azure KMS and intended for release builds. Neither can be meaningfully parameterized to sign builds with custom keys.

This merge request attempts to parameterize the test keys to allow using custom keys instead. I tried to minimize actual changes to the codebase and as such opted for environment variables, at least to validate the initial approach. I feel they're a bit too "magic" and obscure though, and CLI arguments could be added to the necessary scripts if preferred.

Also, the generation, env preparation and artefact verification could be offloaded to proper scripts (ie, verify_sbkey_images, generate_sbkeys and set_sbkeys_env) to ease custom key workflow as well as act as documentation for the process.

How to use

Generate keys:

OUTPUT_DIR="./sb-keys"
SUBJ_PREFIX="Flatcar Derivative"
DAYS=7300

openssl req -new -x509 -newkey rsa:2048 -sha256 -days "${DAYS}" \
    -subj "/CN=${SUBJ_PREFIX} Platform Key/" -nodes \
    -keyout "${OUTPUT_DIR}/PK.key" -out "${OUTPUT_DIR}/PK.crt"

openssl req -new -x509 -newkey rsa:2048 -sha256 -days "${DAYS}" \
    -subj "/CN=${SUBJ_PREFIX} Key Exchange Key/" -nodes \
    -keyout "${OUTPUT_DIR}/KEK.key" -out "${OUTPUT_DIR}/KEK.crt"

openssl req -new -x509 -newkey rsa:2048 -sha256 -days "${DAYS}" \
    -subj "/CN=${SUBJ_PREFIX} Secure Boot DB/" -nodes \
    -keyout "${OUTPUT_DIR}/DB.key" -out "${OUTPUT_DIR}/DB.crt"

openssl genrsa -out "${OUTPUT_DIR}/shim.key" 2048
openssl req -new -x509 -sha256 -days "${DAYS}" \
    -subj "/CN=${SUBJ_PREFIX} Shim Key/" \
    -key "${OUTPUT_DIR}/shim.key" -out "${OUTPUT_DIR}/shim.pem"
openssl x509 -in "${OUTPUT_DIR}/shim.pem" -inform PEM \
    -out "${OUTPUT_DIR}/shim.der" -outform DER

Set a proper environment:

CONTAINER_KEYS_DIR="/home/sdk/trunk/src/scripts/sb-keys"

export SBSIGN_KEY="${CONTAINER_KEYS_DIR}/shim.key"
export SBSIGN_CERT="${CONTAINER_KEYS_DIR}/shim.pem"
export SBSIGN_DB_KEY="${CONTAINER_KEYS_DIR}/DB.key"
export SBSIGN_DB_CERT="${CONTAINER_KEYS_DIR}/DB.crt"
export SHIM_SIGNING_CERTIFICATE="${CONTAINER_KEYS_DIR}/shim.der"

Build Flatcar as usual:

./build_packages
./build_image ...
./image_to_vm.sh ...

Testing done

Verify artefacts have been signed with the correct keys:

sbverify __build__/images/images/amd64-usr/latest/flatcar_production_image.vmlinuz --cert sb-keys/shim.pem
Signature verification OK

[chewi]

Thank you very much for this! Apart from the one suggestion and some overquoting (no quotes needed in [[ ]]), this looks fine. I think using environment variables is perfectly valid here, otherwise we'll need to add and remember to use arguments in several places. I ran this under GHA, which had some unrelated issues, so I tried it locally, including Kola's cl.basic test, and it just worked. If you can make that change, I'd be happy to merge without doing another build.

For us, we need to do things differently for official vs unofficial builds because our sources are public, and we obviously cannot publish the official private key. You won't have this problem, but I wondered whether you were satisfied with keeping the private key in a file, as opposed to using a safer PKCS11-based mechanism.

[jqueuniet]

Thank you very much for this! Apart from the one suggestion and some overquoting (no quotes needed in [[ ]]), this looks fine.

I see, I'm used to [ ] and did not know that [[ ]] did not require such agressive quoting. So it's more of a style/consistency issue.

I think using environment variables is perfectly valid here, otherwise we'll need to add and remember to use arguments in several places. I ran this under GHA, which had some unrelated issues, so I tried it locally, including Kola's cl.basic test, and it just worked. If you can make that change, I'd be happy to merge without doing another build.

Sure, I made the change

For us, we need to do things differently for official vs unofficial builds because our sources are public, and we obviously cannot publish the official private key. You won't have this problem, but I wondered whether you were satisfied with keeping the private key in a file, as opposed to using a safer PKCS11-based mechanism.

For now we're operating from my Github fork so we're subject to the same constraints, and I would certainly not commit such keys to a git repository, even a private one. You're right that we will definitely not be satisfied by files in the long run, government regulation pressure will very likely steer us toward PKCS11 or similar mechanisms eventually. But I'm not sure yet how that will take place, it could be a remote KMS, a standard smartcard, a full-fledged HSM, etc. The only thing I'm pretty sure of is that it will not be cloud-based. So I'd rather look at this through a separate PR at a later time, once the picture is clear.