Giters

rhboot / shim

UEFI shim loader

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

QUESTION: About Generating Precise MOK x509 Certificate Configurations

hollowaykeanho opened this issue · comments

commented

Hi dev team,

Quick questions:

  1. Are the following x509 key and cert generations configurations over/under allocating the required privileges for MOK key generations (usr_cert)?
    screen-2022-08-12-18-16-37

  2. Given the cert is signed by an internal intermediate CA (complying to Chain of Trust referencing LetsEncrypt (https://letsencrypt.org/certificates/) implementations), can uploading the root / intermediate CA to MOK system works or should I just stick to the end-left MOK certificate?

  3. Are ED25519 generated keys and certificate applicable? Currently, guides over the places recommend RSA-2048 like (https://wiki.debian.org/SecureBoot). Asking because if ED25519 is possible I would stick to that for its effectiveness and efficiencies.

Context of Asking

I'm currently enhancing my Debian build tool (that I rush-built successfully in the past 4 days) and I wanted to properly implement SB this time. I managed to generate the root and intermediate CA credentials and sealed root private credentials offline and off the grid. I want the SB to be done in a proper control, allocating only the required privileges rather than simply generate all and dump a key.

Also, it seems the the public key of the MOK can be served as the cryptsetup keyfile for passwordless decryption so yeah, if this MOK path is working, I see good potentials.

Thanks in advance!

commented

I don't fully speak openssl but this misses codeSigning extendedKeyUsage. And then you likely want to restrict that to just allow kernel modules or whatever, e.g. in Ubuntu we set 1.3.6.1.4.1.2312.16.1.2 extended key usage for the MOK certificate:

$ cat /usr/lib/shim/mok/openssl.cnf
HOME                    = /var/lib/shim-signed/mok
RANDFILE                = /var/lib/shim-signed/mok/.rnd

[ req ]
distinguished_name      = req_distinguished_name
x509_extensions         = v3_ca
string_mask             = utf8only

[ req_distinguished_name ]

[ v3_ca ]
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer
basicConstraints        = critical,CA:FALSE

# We use extended key usage information to limit what this auto-generated
# key can be used for.
#
# codeSigning:  specifies that this key is used to sign code.
#
# 1.3.6.1.4.1.2312.16.1.2:  defines this key as used for module signing
#                           only. See https://lkml.org/lkml/2015/8/26/741.
#
extendedKeyUsage        = codeSigning,1.3.6.1.4.1.2312.16.1.2

nsComment               = "OpenSSL Generated Certificate"
commented

Thanks @julian-klode. I just tested and manage to generate the certificates and keys after applying your feedbacks (along with this document: https://www.openssl.org/docs/manmaster/man5/x509v3_config.html) yielded:

[ mok_ca ]
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
extendedKeyUsage = clientAuth, codeSigning, emailProtection, OCSPSigning, timeStamping
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always

[ mok_cert ]
basicConstraints = critical, CA:FALSE
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment, keyAgreement
extendedKeyUsage = clientAuth, codeSigning, emailProtection, timeStamping
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always

So what happens is the [ mok_ca ] certificate is used for SB Manager to verify while [ mok_cert ] is used to perform local DKIM signing and etc and the cert file itself can be used for cryptsetup input keyfile for full disk decryption.

I did some research about the Linux OID extended usage but for now I will refrain from using it given the following reasons:

  1. Appearently https://lkml.org/lkml/2015/8/26/741 is a diccussion about the patch was rejected, hence the extension OID source codes are not appearing in kernel v5.19 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto/asymmetric_keys?h=v5.19.
  2. I'm aware of this issue: https://unix.stackexchange.com/questions/701612/cant-load-self-signed-kernel-with-secure-boot-on-bad-shim-signature
  3. The learning from this page (https://wiki.ubuntu.com/UEFI/SecureBoot/KeyManagement/KeyGeneration) was applied. =)
  4. I'm still open for this but hopefully there are official references I can use for those specific OIDs.

What about the ED25519 private key application? Can the shim layer use it?

Thanks in adv!

commented

Investigated the implementations for ED25519. Appearently, it looks like not supported (compiled shown the following error):

SSL error:2E0AA07D:CMS routines:cms_sd_asn1_ctrl:not supported for this key type: ../crypto/cms/cms_sd.c:231

Hence, for those who wants elliptic curves support, as of date of this post, stick to rsa2048 for now (Debian team discovered some issue with rsa4096 as well).

Closing this issue as all the questions are answered.