| View previous topic :: View next topic |
| Author |
Message |
mirthical
n00b
Joined: 18 Dec 2024
Posts: 7
|
 Posted: Wed Dec 18, 2024 6:52 pm Post subject: PKCS#11 for Kernel Module Signing on Gentoo Kernel |
 |
|
Hello Gentoo community,
This is my first post here, and I’m seeking guidance on an issue I’ve encountered while trying to use PKCS#11 for signing kernel modules during the build/install process of the sys-kernel/gentoo-kernel package.
Current Setup:
- Kernel version: 6.12.5
- dev-libs/openssl-3.3.2-r1
- Signing mechanism: PKCS#11
The Problem:
In order to successfully use PKCS#11 for signing kernel modules, I’ve had to revert the extract-cert.c and sign-file.c files to their versions from kernel 6.11.11. Without doing this, signing with PKCS#11 fails during the kernel compilation or installation process. I get a bunch of errors like this:
| Quote: |
...
SSL error:12800067:DSO support routines::could not load the shared library: ../openssl-3.3.2/crypto/dso/dso_dlfcn.c:118 kernel
...
could not bind to the requested symbol name: ../openssl-3.3.2/crypto/dso/dso_dlfcn.c |
Additionally, reverting these files alone is not sufficient. I’ve previously had to:
- Define the environment variable KBUILD_SIGN_PIN with the necessary PIN for the PKCS#11 token.
- Comment the my line MODULES_SIGN_KEY="pkcs11:token=MyVerySecretKernel" at /etc/portage/make.conf only to uncomment after merging (so that other emerge can sign with it, e.g. nvidia-drivers)
- Set CONFIG_MODULE_SIG_KEY="pkcs11:token=MyVerySecretKernel" in my savedconfig file
What I Need Help With:
- Is there a better or proper way to achieve PKCS#11-based signing for kernel modules?
- I currently have the full .config in my savedconfig, but it seems that there is a way to just have there the things that are different from the gentoo default, how can see that default so that I only keep the lines that are different? I'm getting a bunch of lines saying that fragment is redundant - not a problem but clearly there seems to have been an effort to make things cleaner.
- Are the steps I’m taking (reverting files, applying patches, setting environment variables, commenting/uncommenting) the only way to get this working?
- Why does specifying MODULES_SIGN_KEY in make.conf cause an error while the same value works fine with other packages?
Any suggestions or guidance to streamline this process would be highly appreciated.
Thank you in advance for your help! Let me know if more details are needed. |
|
| Back to top |
|
 |
Nowa
Developer
Joined: 25 Jun 2014
Posts: 459
Location: Nijmegen
|
| Posted: Wed Dec 18, 2024 7:49 pm Post subject: Re: PKCS#11 for Kernel Module Signing on Gentoo Kernel |
|
|
| mirthical wrote: |
Additionally, reverting these files alone is not sufficient. I’ve previously had to:
- Define the environment variable KBUILD_SIGN_PIN with the necessary PIN for the PKCS#11 token.
- Comment the my line MODULES_SIGN_KEY="pkcs11:token=MyVerySecretKernel" at /etc/portage/make.conf only to uncomment after merging (so that other emerge can sign with it, e.g. nvidia-drivers)
- Set CONFIG_MODULE_SIG_KEY="pkcs11:token=MyVerySecretKernel" in my savedconfig file
|
This sounds a lot like there is some bug in kernel-build.eclass, MODULES_SIGN_KEY should work fine, it should set the CONFIG_MODULE_SIG_KEY for you (though I am not sure how this interacts with USE=savedconfig). I would love to see the full build log to figure out where this is going wrong.
| Quote: | I currently have the full .config in my savedconfig, but it seems that there is a way to just have there the things that are different from the gentoo default, how can see that default so that I only keep the lines that are different? I'm getting a bunch of lines saying that fragment is redundant - not a problem but clearly there seems to have been an effort to make things cleaner.
Are the steps I’m taking (reverting files, applying patches, setting environment variables, commenting/uncommenting) the only way to get this working? |
What you are looking for is /etc/kernel/config.d, we have documented this here: https://wiki.gentoo.org/wiki/Project:Distribution_Kernel#Modifying_kernel_configuration The easiest way to find the current default is to emerge with USE=-savedconfig, and then to copy the resulting /usr/lib/modules/x.y.z-gentoo-dist/config. You can also extract it from the build directory after the configure phase has finished.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
mirthical
n00b
Joined: 18 Dec 2024
Posts: 7
|
| Posted: Thu Dec 19, 2024 11:28 am Post subject: |
|
|
Thank you Nowa.
Regarding your point about the .eclass
| Quote: |
This sounds a lot like there is some bug in kernel-build.eclass, MODULES_SIGN_KEY should work fine, it should set the CONFIG_MODULE_SIG_KEY for you (though I am not sure how this interacts with USE=savedconfig). I would love to see the full build log to figure out where this is going wrong. |
[/topic]
On the kernel-build.eclass I have this:
| Code: |
# @FUNCTION: kernel-build_pkg_setup
# @DESCRIPTION:
# Call python-any-r1 and secureboot pkg_setup
kernel-build_pkg_setup() {
python-any-r1_pkg_setup
if [[ ${KERNEL_IUSE_MODULES_SIGN} && ${MERGE_TYPE} != binary ]]; then
secureboot_pkg_setup
if use modules-sign && [[ -n ${MODULES_SIGN_KEY} ]]; then
# Sanity check: fail early if key/cert in DER format or does not exist
local openssl_args=(
-noout -nocert
)
if [[ -n ${MODULES_SIGN_CERT} ]]; then
openssl_args+=( -inform PEM -in "${MODULES_SIGN_CERT}" )
else
# If no cert specified, we assume the pem key also contains the cert
openssl_args+=( -inform PEM -in "${MODULES_SIGN_KEY}" )
fi
if [[ ${MODULES_SIGN_KEY} == pkcs11:* ]]; then
openssl_args+=( -engine pkcs11 -keyform ENGINE -key "${MODULES_SIGN_KEY}" )
else
openssl_args+=( -keyform PEM -key "${MODULES_SIGN_KEY}" )
fi
openssl x509 "${openssl_args[@]}" ||
die "Kernel module signing certificate or key not found or not PEM format."
if [[ ${MODULES_SIGN_KEY} != pkcs11:* ]]; then
if [[ -n ${MODULES_SIGN_CERT} && ${MODULES_SIGN_CERT} != ${MODULES_SIGN_KEY} ]]; then
MODULES_SIGN_KEY_CONTENTS="$(cat "${MODULES_SIGN_CERT}" "${MODULES_SIGN_KEY}" || die)"
else
MODULES_SIGN_KEY_CONTENTS="$(< "${MODULES_SIGN_KEY}")"
fi
fi
fi
fi
}
|
Which doesn't work
| Quote: |
emerge -1av gentoo-kernel:6.11.11
These are the packages that would be merged, in order:
Calculating dependencies... done!
Dependency resolution took 2.08 s (backtrack: 0/20).
[ebuild R ~] sys-kernel/gentoo-kernel-6.11.11:6.11.11::gentoo USE="debug hardened initramfs modules-sign savedconfig strip -experimental -generic-uki -modules-compress -secureboot -test" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No]
>>> Verifying ebuild manifests
>>> Running pre-merge checks for sys-kernel/gentoo-kernel-6.11.11
* Assuming you do not have a separate /boot partition.
* Assuming you do not have a separate /efi partition.
* Assuming you do not have a separate /boot/efi partition.
* Assuming you do not have a separate /boot/EFI partition.
>>> Emerging (1 of 1) sys-kernel/gentoo-kernel-6.11.11::gentoo
* linux-6.11.tar.xz BLAKE2B SHA512 size  ... [ ok ]
* genpatches-6.11-13.base.tar.xz BLAKE2B SHA512 size ... [ ok ]
* genpatches-6.11-13.extras.tar.xz BLAKE2B SHA512 size ... [ ok ]
* gentoo-kernel-config-g14.tar.gz BLAKE2B SHA512 size ... [ ok ]
* kernel-x86_64-fedora.config.6.11.5-gentoo BLAKE2B SHA512 size ... [ ok ]
* Checking whether python3_13 is suitable ...
* dev-lang/python:3.13 ... [ ok ]
* Using python3.13 to build (via PYTHON_COMPAT iteration)
Engine "pkcs11" set.
Enter PKCS#11 token PIN for MyVerySecretKernel:
Could not open file or uri for loading certificate from pkcs11:token=MyVerySecretKernel
80EBC12EC07F0000:error:80000002:system library:file_open:No such file or directory:../openssl-3.3.2/providers/implementations/storemgmt/file_store.c:263:calling stat(pkcs11:token=MyVerySecretKernel)
80EBC12EC07F0000:error:1608010C:STORE routines:inner_loader_fetch:unsupported:../openssl-3.3.2/crypto/store/store_meth.c:360:No store loader found. For standard store loaders you need at least one of the default or base providers available. Did you forget to load them? Info: Global default library context, Scheme (pkcs11 : 0), Properties (<null>)
* ERROR: sys-kernel/gentoo-kernel-6.11.11::gentoo failed (setup phase):
* Kernel module signing certificate or key not found or not PEM format.
*
* Call stack:
* ebuild.sh, line 136: Called pkg_setup
* ebuild.sh, line 374: Called kernel-build_pkg_setup
* kernel-build.eclass, line 156: Called die
* The specific snippet of code:
* die "Kernel module signing certificate or key not found or not PEM format."
*
* If you need support, post the output of `emerge --info '=sys-kernel/gentoo-kernel-6.11.11::gentoo'`,
* the complete build log and the output of `emerge -pqv '=sys-kernel/gentoo-kernel-6.11.11::gentoo'`.
* The complete build log is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-6.11.11/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-6.11.11/temp/die.env'.
* Working directory: '/var/tmp/portage/sys-kernel/gentoo-kernel-6.11.11/empty'
* S: '/var/tmp/portage/sys-kernel/gentoo-kernel-6.11.11/work/linux-6.11'
>>> Failed to emerge sys-kernel/gentoo-kernel-6.11.11, Log file:
>>> '/var/tmp/portage/sys-kernel/gentoo-kernel-6.11.11/temp/build.log'
* Messages for package sys-kernel/gentoo-kernel-6.11.11:
* ERROR: sys-kernel/gentoo-kernel-6.11.11::gentoo failed (setup phase):
* Kernel module signing certificate or key not found or not PEM format.
*
* Call stack:
* ebuild.sh, line 136: Called pkg_setup
* ebuild.sh, line 374: Called kernel-build_pkg_setup
* kernel-build.eclass, line 156: Called die
* The specific snippet of code:
* die "Kernel module signing certificate or key not found or not PEM format."
*
* If you need support, post the output of `emerge --info '=sys-kernel/gentoo-kernel-6.11.11::gentoo'`,
* the complete build log and the output of `emerge -pqv '=sys-kernel/gentoo-kernel-6.11.11::gentoo'`.
* The complete build log is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-6.11.11/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-6.11.11/temp/die.env'.
* Working directory: '/var/tmp/portage/sys-kernel/gentoo-kernel-6.11.11/empty'
* S: '/var/tmp/portage/sys-kernel/gentoo-kernel-6.11.11/work/linux-6.11'
|
Btw, doing something like this would work to check the certificate without even requiring the pin to be inserted at this stage
| Quote: |
/usr/src/linux/certs/extract-cert "pkcs11:token=MyVerySecretKernel" /var/tmp/portage/sys-kernel/gentoo-kernel-6.11.11/temp/signing_key.x509
openssl x509 -in /var/tmp/portage/sys-kernel/gentoo-kernel-6.11.11/temp/signing_key.x509 -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=****
Validity
Not Before: *** * 00:00:00 **** GMT
Not After : *** * 00:00:00 **** GMT
Subject: CN=****
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
ASN1 OID: secp384r1
NIST CURVE: P-384
Signature Algorithm: ecdsa-with-SHA256
Signature Value:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:
|
Later on, calling /usr/src/linux/scripts/sign-file sha256 pkcs11:token=MyVerySecretKernel /usr/src/linux/certs/signing_key.x509 /path/to/module.ko will ask you for the pin unless you've already done so at KBUILD_SIGN_PIN |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 459
Location: Nijmegen
|
| Posted: Thu Dec 19, 2024 11:34 am Post subject: |
|
|
| Quote: | | Which doesn't work |
Does an equivalent manual call to openssl work with that pkcs11 uri? Which flags do you have enabled for openssl? This code worked on my end with a pkcs11 uri, at least it did when I tested it a couple of months ago. The error message "No store loader found" makes me think that some required package/flag is missing.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
mirthical
n00b
Joined: 18 Dec 2024
Posts: 7
|
| Posted: Thu Dec 19, 2024 12:04 pm Post subject: |
|
|
| Quote: |
Does an equivalent manual call to openssl work with that pkcs11 uri? Which flags do you have enabled for openssl? This code worked on my end with a pkcs11 uri, at least it did when I tested it a couple of months ago. The error message "No store loader found" makes me think that some required package/flag is missing.
|
The openssl call doesn't work.
| Code: |
openssl x509 -noout -nocert -inform PEM -in pkcs11:token=MyVerySecretKernel -engine pkcs11 -keyform ENGINE -key pkcs11:token=MyVerySecretKernel
Engine "pkcs11" set.
Enter PKCS#11 token PIN for MyVerySecretKernel:
Could not open file or uri for loading certificate from pkcs11:token=MyVerySecretKernel
80FBF5D3A77F0000:error:80000002:system library:file_open:No such file or directory:../openssl-3.3.2/providers/implementations/storemgmt/file_store.c:263:calling stat(pkcs11:token=MyVerySecretKernel)
80FBF5D3A77F0000:error:1608010C:STORE routines:inner_loader_fetch:unsupported:../openssl-3.3.2/crypto/store/store_meth.c:360:No store loader found. For standard store loaders you need at least one of the default or base providers available. Did you forget to load them? Info: Global default library context, Scheme (pkcs11 : 0), Properties (<null>)
equery u openssl
[ Legend : U - final flag setting for installation]
[ : I - package is installed with flag ]
[ Colors : set, unset ]
* Found these USE flags for dev-libs/openssl-3.3.2-r1:
U I
- - abi_x86_32 : 32-bit (x86) libraries
+ + asm : Enable using assembly for optimization
+ + fips : Enable FIPS provider
- - ktls : Enable support for Kernel implementation of TLS (kTLS)
+ + quic : Enable support for QUIC (RFC 9000); a UDP-based protocol intended to replace TCP
- - rfc3779 : Enable support for RFC 3779 (X.509 Extensions for IP Addresses and AS Identifiers)
- - sctp : Support for Stream Control Transmission Protocol
- - static-libs : Build static versions of dynamic libraries as well
- - test : Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)
- - tls-compression : Enable support for discouraged TLS compression
- - vanilla : Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically
+ + verify-sig : Verify upstream signatures on distfiles
- - weak-ssl-ciphers : Build support for SSL/TLS ciphers that are considered "weak"
|
Maybe I'm missing something in the /etc/ssl/openssl.cnf ?
| Code: |
...
[openssl_init]
providers = provider_sect
# List of providers to load
[provider_sect]
default = default_sect
pkcs11 = pkcs11_section
...
[pkcs11_section]
module = /usr/lib64/engines-3/pkcs11.so
|
|
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 459
Location: Nijmegen
|
| Posted: Thu Dec 19, 2024 12:10 pm Post subject: |
|
|
| mirthical wrote: |
The openssl call doesn't work.
Maybe I'm missing something in the /etc/ssl/openssl.cnf ? |
Strange, for me it works out-of-the-box, no openssl.cnf required. Do you have libp11 installed?
| Quote: | | Btw, doing something like this would work to check the certificate without even requiring the pin to be inserted at this stage |
The problem with this is that certs/extract-cert does not exist at this stage, it is compiled in the compile phase of this package.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400
Last edited by Nowa on Thu Dec 19, 2024 12:12 pm; edited 1 time in total |
|
| Back to top |
|
|
mirthical
n00b
Joined: 18 Dec 2024
Posts: 7
|
| Posted: Thu Dec 19, 2024 12:12 pm Post subject: |
|
|
Yes I do
| Code: |
[I] dev-libs/libp11
Available versions: 0.4.12-r7^t {doc static-libs test}
Installed versions: 0.4.12-r7^t(23:34:26 10/12/2024)(-doc -static-libs -test)
Homepage: https://github.com/opensc/libp11/wiki
Description: Abstraction layer to simplify PKCS#11 API
|
|
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 459
Location: Nijmegen
|
| Posted: Thu Dec 19, 2024 12:14 pm Post subject: |
|
|
Could you try without your "/etc/ssl/openssl.cnf"? It works for me without any config file, so perhaps something is wrong here.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
mirthical
n00b
Joined: 18 Dec 2024
Posts: 7
|
| Posted: Thu Dec 19, 2024 12:16 pm Post subject: |
|
|
| Quote: |
The problem with this is that certs/extract-cert does not exist at this stage, it is compiled in the compile phase of this package.
|
Don't we have the one from the previous kernel compilation?
Also, starting with 6.12.x the extract-cert and sign-file fail similarly - so this might not be an option unless we keep patching them to 6.11.11 versions (which is what I'm doing right now)
Thank you again for your help in advance.
Without those options in the openssl.conf, I get the exact same erros... |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 459
Location: Nijmegen
|
| Posted: Thu Dec 19, 2024 12:20 pm Post subject: |
|
|
| mirthical wrote: | | Quote: |
The problem with this is that certs/extract-cert does not exist at this stage, it is compiled in the compile phase of this package.
|
Don't we have the one from the previous kernel compilation? |
Usually yes, but we cannot create a circular dependency in the kernel packages on the kernel packages.
| Quote: | | openssl x509 -noout -nocert -inform PEM -in pkcs11:token=MyVerySecretKernel -engine pkcs11 -keyform ENGINE -key pkcs11:token=MyVerySecretKernel |
Wait a minute, this does not look correct. The -key can be a pkcs11 uri, but the -in cannot, this should be the certificate belonging to the key. In other words, the MODULES_SIGN_KEY may be a (private) pkcs11 uri, but the MODULES_SIGN_CERT should be a PEM certificate file on the disk.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
mirthical
n00b
Joined: 18 Dec 2024
Posts: 7
|
| Posted: Thu Dec 19, 2024 12:26 pm Post subject: |
|
|
The token holds both the private and the public certificate. Also, unless I'm getting this wrong, I'm not taking the private certificate out of the hardware key, that defeats the whole purpose of this.
| Quote: |
pkcs11-tool --list-token-slots
Available slots:
Slot 0 (0x0): Yubico YubiKey FIDO+CCID 00 00
token label : MyVerySecretToken
token manufacturer : piv_II
token model : PKCS#15 emulated
token flags : login required, rng, token initialized, PIN initialized
hardware version : 0.0
firmware version : 0.0
serial num : 9e12344b23aade2d
pin min/max : 4/8
|
The hardware key does the signing too...but what you're proposing seems to be that you get the "private key" and use it to sign. I was wondering how you got out of inputing 1000x times the pin during the kernel compilation without defining the KBUILD_SIGN_PIN
EDIT:
Doing openssl x509 -noout -nocert -in /usr/src/linux/certs/signing_key.x509 -engine pkcs11 -keyform ENGINE -key pkcs11:token=MyVerySecretToken does work...but the -inform PEM requires me to have a version of the certificate in PEM format. Which shouldn't be a problem, just feels redundant.
I still unsure about the pin issue - how do you get out of having to define KBUILD_SIGN_PIN?
Also, for the 6.12.x I cannot extract or sign anything from pkcs11, did you try it? I fails very early on, after compiling everything it will fail trying to sign with something that doesn't exist. You can do find /var/tmp/portage/sys-kernel/ -name "*.x509" during compilation to try to see if it extracted the certificate.
Last edited by mirthical on Thu Dec 19, 2024 12:38 pm; edited 1 time in total |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 459
Location: Nijmegen
|
| Posted: Thu Dec 19, 2024 12:35 pm Post subject: |
|
|
| mirthical wrote: | | The token holds both the private and the public certificate. Also, unless I'm getting this wrong, I'm not taking the private certificate out of the hardware key, that defeats the whole purpose of this. |
You indeed cannot extract the private key, but you can extract the public certificate. The MODULES_SIGN_KEY should contain the private key, and the MODULES_SIGN_CERT should contain the public certificate, since it is the public part it does not have to be stored on the token. Many tokens do indeed support storing the certificate on the token as well, however due to limitations in openssl/sbsign we cannot (easily) make use of this. Therefore we currently only support pkcs11 for the MODULES_SIGN_KEY/SECUREBOOT_SIGN_KEY, but not for the MODULES_SIGN_CERT/SECUREBOOT_SIGN_CERT.
| Quote: | | I was wondering how you got out of inputing 1000x times the pin during the kernel compilation without defining the KBUILD_SIGN_PIN |
You cannot avoid this other than with KBUILD_SIGN_PIN or by setting pin= in the pkcs11 uri. This is because there unfortunately is no caching in openssl like there is for gpg.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
mirthical
n00b
Joined: 18 Dec 2024
Posts: 7
|
| Posted: Thu Dec 19, 2024 12:46 pm Post subject: |
|
|
I didn't know about the pin= option in the uri. Thank you.
It doesn't feel very safe, but if it's the only way to do it...so be it.
Sorry about my mix up about getting the private cert out of the hw key. It's just a PEM format, got it
How about doing something like this
| Code: |
echo "Please enter your PKCS#11 PIN:"
read -s KBUILD_SIGN_PIN
export KBUILD_SIGN_PIN
|
And then doing unset KBUILD_SIGN_PIN after merging? We could do this for every package that requires signing and not have the pin in the uri...?
And if you could please test the 6.12.x series for pkcs11, that would be great. |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 459
Location: Nijmegen
|
| Posted: Thu Dec 19, 2024 12:52 pm Post subject: |
|
|
| mirthical wrote: | | It doesn't feel very safe, but if it's the only way to do it...so be it. |
It is indeed not safe, but there is a fundamental conflict here between safety via PKCS11/PIN and automated signing in bulk. Any solution will require specifying the PIN beforehand and storing it somewhere which is fundamentally a security problem. For this reason I personally use a different dedicated key (without a PIN) for module/secureboot signing, I don't want to expose my key that I do want to keep very safe to this kind of semi-automation.
| Quote: | How about doing something like this
| Code: |
echo "Please enter your PKCS#11 PIN:"
read -s KBUILD_SIGN_PIN
export KBUILD_SIGN_PIN
|
And then doing unset KBUILD_SIGN_PIN after merging? We could do this for every package that requires signing and not have the pin in the uri...? |
To make that work we would first have to check (somehow) if the key requires a PIN. And we should also account for keys that are not a pkcs11 but do require a PIN. There is also this bug[1] that needs some solution for this to work reliably.
[1] https://bugs.gentoo.org/935733
| Quote: | | And if you could please test the 6.12.x series for pkcs11, that would be great. |
I'll check later, it sounds like there is some upstream change/bug introduced in 6.12.
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
