Lines Matching refs:the
10 - Public keys in the kernel.
15 - Administering/protecting the private key.
23 installation and then checks the signature upon loading the module. This
24 allows increased kernel security by disallowing the loading of unsigned modules
26 making it harder to load a malicious module into the kernel. The module
27 signature checking is done by the kernel so that it is not necessary to have
30 This facility uses X.509 ITU-T standard certificates to encode the public keys
32 type. The facility currently only supports the RSA public key encryption
35 SHA-512 (the algorithm is selected by data in the signature).
42 The module signing facility is enabled by going to the "Enable Loadable Module
43 Support" section of the kernel configuration and turning on
51 This specifies how the kernel should deal with a module that has a
52 signature for which the key is not known or a module that is unsigned.
54 If this is off (ie. "permissive"), then modules for which the key is not
55 available and modules that are unsigned are permitted, but the kernel will
56 be marked as being tainted, and the concerned modules will be marked as
57 tainted, shown with the character 'E'.
60 signature that can be verified by a public key in the kernel's possession
63 Irrespective of the setting here, if the module has a signature block that
69 If this is on then modules will be automatically signed during the
70 modules_install phase of a build. If this is off, then the modules must
78 This presents a choice of which hash algorithm the installation phase will
79 sign the modules with:
87 The algorithm selected here will also be built into the kernel (rather
95 "certs/signing_key.pem" will disable the autogeneration of signing keys
96 and allow the kernel modules to be signed with a key of your choosing.
99 the OpenSSL ENGINE_pkcs11 is functional — a PKCS#11 URI as defined by
100 RFC7512. In the latter case, the PKCS#11 URI should reference both a
103 If the PEM file containing the private key is encrypted, or if the
105 means of the KBUILD_SIGN_PIN variable.
110 This option can be set to the filename of a PEM-encoded file containing
111 additional certificates which will be included in the system keyring by
114 Note that enabling module signing adds a dependency on the OpenSSL devel
115 packages to the kernel build processes for the tool that does the signing.
123 private key is used to generate a signature and the corresponding public key is
124 used to check it. The private key is only needed during the build, after which
125 it can be deleted or stored securely. The public key gets built into the
126 kernel so that it can be used to check the signatures as the modules are
130 default, the kernel build will automatically generate a new keypair using
131 openssl if one does not exist in the file:
135 during the building of vmlinux (the public part of the key needs to be built
136 into vmlinux) using parameters in the:
144 Most notably, in the x509.genkey file, the req_distinguished_name section
145 should be altered from the default:
158 It is also possible to manually generate the key private/public files using the
159 x509.genkey key generation configuration file in the root node of the Linux
160 kernel sources tree and the openssl command. The following is an example to
161 generate the public/private key files:
167 The full pathname for the resulting kernel_key.pem file can then be specified
168 in the CONFIG_MODULE_SIG_KEY option, and the certificate and key therein will
185 Beyond the public key generated specifically for module signing, additional
186 trusted certificates can be provided in a PEM-encoded file referenced by the
189 Further, the architecture code may take public keys from a hardware store and
190 add those in also (e.g. from the UEFI key database).
200 Note, however, that the kernel will only permit keys to be added to
201 .system_keyring _if_ the new key's X.509 wrapper is validly signed by a key
202 that is already resident in the .system_keyring at the time the key was added.
209 To manually sign a module, use the scripts/sign-file tool available in
210 the Linux kernel source tree. The script requires 4 arguments:
222 The hash algorithm used does not have to match the one configured, but if it
223 doesn't, you should make sure that hash algorithm is either built into the
226 If the private key requires a passphrase or PIN, it can be provided in the
234 A signed module has a digital signature simply appended at the end. The string
235 "~Module signature appended~." at the end of the module's file confirms that a
236 signature is present but it does not confirm that the signature is valid!
238 Signed modules are BRITTLE as the signature is outside of the defined ELF
239 container. Thus they MAY NOT be stripped once the signature is computed and
240 attached. Note the entire module is the signed payload, including any and all
241 debug information present at the time of signing.
250 signature checking is all done within the kernel.
258 the kernel command line, the kernel will only load validly signed modules
260 unsigned. Any module for which the kernel has a key, but which proves to have
270 Since the private key is used to sign modules, viruses and malware could use
271 the private key to sign modules and compromise the operating system. The
273 in the root node of the kernel source tree.