MODSIGN: Use PKCS#7 for module signatures [ver #4]

Provide a utility that:

(1) Digests a module using the specified hash algorithm (typically sha256).

[The digest can be dumped into a file by passing the '-d' flag]

(2) Generates a PKCS#7 message that:

(a) Has detached data (ie. the module content).

(b) Is signed with the specified private key.

(c) Refers to the specified X.509 certificate.

(d) Has an empty X.509 certificate list.

[The PKCS#7 message can be dumped into a file by passing the '-p' flag]

(3) Generates a signed module by concatenating the old module, the PKCS#7 message, a descriptor and a magic string. The descriptor contains the size of the PKCS#7 message and indicates the id_type as PKEY_ID_PKCS7.

(4) Either writes the signed module to the specified destination or renames it over the source module.

This allows module signing to reuse the PKCS#7 handling code that was added for PE file parsing for signed kexec.

Note that the utility is written in C and must be linked against the OpenSSL crypto library.

Note further that I have temporarily dropped support for handling externally created signatures until we can work out the best way to do those. Hopefully, whoever creates the signature can give me a PKCS#7 certificate.

Signed-off-by David Howells <[email protected]>

Tested-by Vivek Goyal <[email protected]>

---

  include/crypto/public_key.h |    1
  scripts/sign-file.c         |  205 +++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 206 insertions(+)

create mode 100755 scripts/sign-file.c

include/crypto/public_key.h +0 -0

index b6f27a240856..fda097e079a4 100644

include/crypto/public_key.h extern const struct public_key_algorithm *pkey_algo[PKEY_ALGO__LAST]; · line 38

Quoted 7 lines

  enum pkey_id_type {
  	PKEY_ID_PGP,		/* OpenPGP generated key ID */
  	PKEY_ID_X509,		/* X.509 arbitrary subjectKeyIdentifier */

include/crypto/public_key.h +1 -0

+	PKEY_ID_PKCS7,		/* Signature in PKCS#7 message */
  	PKEY_ID_TYPE__LAST
  };

I don't understand these comments. "OpenPGP generated key ID" refers to the name of a key. "X.509 arbitrary subjectKeyIdentifier" also refers to a name of a key.

"Signature in PKCS#7 message" refers to a signature style. This seems inconsistent.

Also, I think we're really going to want signatures that specify their purpose, e.g. "module named xyz" or "firmware file named abc" or "kexec image". Let's get this right the first time rather than needing yet another type in the very near future.

Finally, why are we using PKCS#7 for this? Can't everything except kexec images use raw signatures in some trivial non-ASN.1-ified format? A raw signature can reference a UEFI-sourced key just fine.

It could be as simple as:

4 bytes of signature type
(length of pubkey identifier, pubkey identifier) 4 bytes of purpose
(length of purpose-specific data, purpose-specific data)

Quoted 11 lines · Andy Lutomirski

Quoted 7 lines

enum pkey_id_type {

    PKEY_ID_PGP,            /* OpenPGP generated key ID */
    PKEY_ID_X509,           /* X.509 arbitrary subjectKeyIdentifier */
+   PKEY_ID_PKCS7,          /* Signature in PKCS#7 message */

PKEY_ID_TYPE__LAST
};

I don't understand these comments. "OpenPGP generated key ID" refers to the name of a key. "X.509 arbitrary subjectKeyIdentifier" also refers to a name of a key.

OpenPGP was how we did things originally. We then switched to X.509 because we had to take account of UEFI. These values are implicit parts of the kernel ABI.

Quoted 2 lines

"Signature in PKCS#7 message" refers to a signature style. This seems inconsistent.

Not precisely. The format of the descriptor is immutable given the particular magic number. You set the ID type to that and all the other fields bar one to zero and you put the signature and all the metadata in the PKCS#7 blob which you place directly prior to the descriptor (the length of the blob is the one thing you do need to specify). Effectively, it's an override.

Quoted 5 lines

Also, I think we're really going to want signatures that specify their purpose, e.g. "module named xyz" or "firmware file named abc" or "kexec image". Let's get this right the first time rather than needing yet another type in the very near future.

If this is so, then this _must_ also apply to your hash list idea.

Quoted 4 lines

Finally, why are we using PKCS#7 for this? Can't everything except kexec images use raw signatures in some trivial non-ASN.1-ified format? A raw signature can reference a UEFI-sourced key just fine.

We have PKCS#7 already in the kernel. It's a standard. We can add attributes of our own devising to extend it if necessary (say your typing idea referenced above).

Quoted 6 lines

It could be as simple as:

4 bytes of signature type
(length of pubkey identifier, pubkey identifier) 4 bytes of purpose
(length of purpose-specific data, purpose-specific data)

Let's not create yet another unextendable non-standard standard.

Hi Luis,

As David Woodhouse pointed out to me, you don't need sign-file if you're just going to create a detached PKCS#7 message as your signature. You can just use "openssl smime" directly.

The reason that sign-file is needed for module signing is that the signature is added to the module with a little bit of metadata to indicate its presence
- but if you're having detached signatures, that isn't relevant.

You can do this with two steps:

(1) Require that an X.509 certificate is made available to the kernel to provide the public key. One way to do this is to convert it to DER form and place it in the source directory as <name>.x509 when you build the kernel.

(2) Document that to produce a signature for a firmware blob, you just run

     the following command:

		openssl smime -sign \
		 -in $FIRMWARE_BLOB_NAME \
		 -outform DER \
		 -inkey $PRIVATE_KEY_FILE_IN_PEM_FORM \
		 -signer $X509_CERT_FILE_IN_PEM_FORM \
		 -nocerts \
		 -md $DIGEST_ALGORITHM \

>$PKCS7_MESSAGE_FILE_IN_DER_FORM

Note that if you have crypto hardware available that openssl can use, you can do that in this command.

To summarise, what you have to present to the kernel is the following:

(A) A DER-encoded X.509 certificate containing the public key.

(B) A DER-encoded PKCS#7 message containing the signatures.

(C) A binary blob that is the detached data for the PKCS#7 message.

There's a missing -binary argument here, other than that this works fine.

Quoted 1 line

>$PKCS7_MESSAGE_FILE_IN_DER_FORM

I however cannot figure out how to use openssl to verify this signature.

Quoted 1 line · Luis R. Rodriguez

There's a missing -binary argument here, other than that this works fine.

Good point.

Quoted 3 lines

Quoted 1 line

>$PKCS7_MESSAGE_FILE_IN_DER_FORM

I however cannot figure out how to use openssl to verify this signature.

Something like:

	openssl smime -verify \
		-in $PKCS7_MESSAGE_FILE_IN_DER_FORM \
		-inform DER \
		-content $FIRMWARE_BLOB_NAME \
		-inkey $PRIVATE_KEY_FILE_IN_PEM_FORM \
		-signer $X509_CERT_FILE_IN_PEM_FORM

I would guess.

Quoted 9 lines

Something like:

	openssl smime -verify \
		-in $PKCS7_MESSAGE_FILE_IN_DER_FORM \
		-inform DER \
		-content $FIRMWARE_BLOB_NAME \
		-inkey $PRIVATE_KEY_FILE_IN_PEM_FORM \
		-signer $X509_CERT_FILE_IN_PEM_FORM

Quoted 1 line

I would guess.

I tried a few things and no luck with that.

Quoted 9 lines · Luis R. Rodriguez

Quoted 9 lines

Something like:

	openssl smime -verify \
		-in $PKCS7_MESSAGE_FILE_IN_DER_FORM \
		-inform DER \
		-content $FIRMWARE_BLOB_NAME \
		-inkey $PRIVATE_KEY_FILE_IN_PEM_FORM \
		-signer $X509_CERT_FILE_IN_PEM_FORM

Quoted 3 lines

Quoted 1 line

I would guess.

I tried a few things and no luck with that.

Try this:

	openssl smime -verify \
		-in $PKCS7_MESSAGE_FILE_IN_DER_FORM \
		-inform DER \
		-certfile $X509_CERT_FILE_IN_PEM_FORM \
 		-content $FIRMWARE_BLOB_NAME \
		-binary \
		-noverify \
		>/dev/null

I'll also mention:

---
The $DIGEST_ALGORITHM needs to be supported on the running kernel and can differ from CONFIG_MODULE_SIG_HASH.
---

As I do no think that is quite obvious to a system integrator at first.

Quoted 2 lines · Luis R. Rodriguez

I'll also mention:

Quoted 6 lines

---
The $DIGEST_ALGORITHM needs to be supported on the running kernel and can differ from CONFIG_MODULE_SIG_HASH.
---

As I do no think that is quite obvious to a system integrator at first.

Actually, this isn't necessarily so for the firmware.

It *is* for the module signing, but you can always load the module to give you the digest algorithm (or public key algorithm) for the firmware.

Though you would still have to be careful with firmware loaded during the initramfs phase.

Quoted 2 lines

Though you would still have to be careful with firmware loaded during the initramfs phase.

Make sense, how about:

---
The $DIGEST_ALGORITHM needs to be enabled as built-in (=y) or modular (=m) in the running kernel and can differ from CONFIG_MODULE_SIG_HASH. If you are enabling the $DIGEST_ALGORITHM as a module take care to ensure that this module will also be present on the initramfs used as some modules within the initramfs may need it if using the

firmware_class APIs and firmware signing has been enabled.
---

Note that David Woodhouse is looking at making sign-file work with PKCS#11, so bringing back -s might not be necessary.

Signed-off-by David Woodhouse <[email protected]>

---
 scripts/Makefile.modinst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

scripts/Makefile.modinst +0 -0

index e48a4e9..07650ee 100644

scripts/Makefile.modinst +0 -0

 # Modules built outside the kernel source tree go into extra by default

Quoted 1 line · David Woodhouse

Signed-off-by David Woodhouse <[email protected]>

I assume the patch descriptions will be added before being upstreamed.

With this patch, as expected the modules_install aborted on failure. Is
there any way to capture the reason for the failure? In my case,
dropping the '-j <num>' option resolved the problem.

Quoted 7 lines · Mimi Zohar

Quoted 1 line · David Woodhouse

Signed-off-by David Woodhouse <[email protected]>

With this patch, as expected the modules_install aborted on failure. Is
there any way to capture the reason for the failure? In my case,
dropping the '-j <num>' option resolved the problem.

Hm, was there no output from sign-file when this happened? Remember that with a parallel make the error which stops the build might not be the last thing it printed. Can you show the full output?

It's possible that there's a limit on the number of sessions you can have open to the hardware token, and we are exceeding it with a parallel build. I thought that pcscd was going to serialize the access and it should work properly though. I can certainly do 'make -j modules_install' with a Yubikey NEO here (although my test build only has about 20 modules).

Any better ideas on how to specify the key passphrase/PIN? Just put it in a file in the top-level directory?

/bin/sh: line 1: 22771 Segmentation fault (core dumped)
scripts/sign-file "sha256" "pkcs11:manufacturer=piv_II;id=%01" ./signing_key.x509 /lib/modules/4.1.0-rc1 -test+/kernel/net/ipv6/netfilter/ip6table_filter.ko /home/zohar/src/kernel/linux-integrity/scripts/Makefile.modinst:35:
recipe for target 'net/ipv6/netfilter/ip6table_filter.ko' failed make[2]: *** [net/ipv6/netfilter/ip6table_filter.ko] Error 139

Quoted 8 lines · Mimi Zohar

/bin/sh: line 1: 22771 Segmentation fault (core dumped)
scripts/sign-file "sha256" "pkcs11:manufacturer=piv_II;id=%01" ./signing_key.x509 /lib/modules/4.1.0-rc1 -test+/kernel/net/ipv6/netfilter/ip6table_filter.ko /home/zohar/src/kernel/linux-integrity/scripts/Makefile.modinst:35:
recipe for target 'net/ipv6/netfilter/ip6table_filter.ko' failed make[2]: *** [net/ipv6/netfilter/ip6table_filter.ko] Error 139

Hm, can you get a backtrace of that? It would be impressive if that were a bug in the very few lines of code we have in sign-file.c to handle the engine; I suspect it's more likely to be elsewhere in the OpenSSL/p11-kit-proxy/OpenSC/pcsc stack.

It only happens with 'make -j', yes?

Signed-off-by David Woodhouse <[email protected]>

---
 Documentation/module-signing.txt |  2 ++
 Makefile                         |  1 +
 init/Kconfig                     |  6 ++++++
 scripts/sign-file.c              | 39 ++++++++++++++++++++++++++++++++++++++-
 4 files changed, 47 insertions(+), 1 deletion(-)

Documentation/module-signing.txt +0 -0

index c72702e..b0ed080 100644

Documentation/module-signing.txt +0 -0

 ============================
 SIGNED MODULES AND STRIPPING

Makefile +1 -0

index 9590e67..70c066c 100644
@@ -875,6 +875,7 @@ ifdef CONFIG_MODULE_SIG_ALL
 MODSECKEY = $(CONFIG_MODULE_SIG_KEY)
 MODPUBKEY = ./signing_key.x509
 export MODPUBKEY
+export CONFIG_MODULE_SIG_KEY_PASSWORD
 mod_sign_cmd = scripts/sign-file $(CONFIG_MODULE_SIG_HASH) $(MODSECKEY) $(MODPUBKEY)
 else
 mod_sign_cmd = true

init/Kconfig +6 -0

index 1ca075a..7bbc857 100644
@@ -1967,6 +1967,12 @@ config MODULE_SIG_KEY
          Provide the file name of a private key in PEM format, or a PKCS#11
          URI according to RFC7512 to specify the key.
 
+config MODULE_SIG_KEY_PASSWORD
+       string "Passphrase or PIN for module signing key if needed" if MODULE_SIG_EXTERNAL_KEY
+       help
+         If a passphrase or PIN is required for the private key, provide
+         it here.
+
 config MODULE_COMPRESS
        bool "Compress modules on installation"
        depends on MODULES

scripts/sign-file.c +38 -1

index 39aaabe..9a54acc 100755
@@ -80,9 +80,32 @@ static void drain_openssl_errors(void)
                }                                       \
        } while(0)
 
+static char *key_pass;
+
+static int pem_pw_cb(char *buf, int len, int w, void *v)
+{
+       int pwlen;
+
+       if (!key_pass)
+               return -1;
+
+       pwlen = strlen(key_pass);
+       if (pwlen >= len)
+               return -1;
+
+       strcpy(buf, key_pass);
+
+       /* If it's wrong, don't keep trying it. */
+       free(key_pass);
+       key_pass = NULL;
+
+       return pwlen;
+}
+
 int main(int argc, char **argv)
 {
        struct module_signature sig_info = { .id_type = PKEY_ID_PKCS7 };
+       const char *pass_env;
        char *hash_algo = NULL;
        char *private_key_name, *x509_name, *module_name, *dest_name;
        bool save_pkcs7 = false, replace_orig;

@@ -96,6 +119,7 @@ int main(int argc, char **argv)
        BIO *b, *bd = NULL, *bm;
        int opt, n;
 
+       OpenSSL_add_all_algorithms();
        ERR_load_crypto_strings();
        ERR_clear_error();
 

@@ -127,12 +151,25 @@ int main(int argc, char **argv)
                replace_orig = true;
        }
 
+       pass_env = getenv("CONFIG_MODULE_SIG_KEY_PASSWORD");
+       if (pass_env) {
+               int pwlen = strlen(pass_env);
+
+               if (pass_env[0] == '\"' && pass_env[pwlen - 1] == '\"') {
+                       pass_env++;
+                       pwlen -= 2;
+               }
+               if (pwlen)
+                       key_pass = strndup(pass_env, pwlen);
+       }
+
        /* Read the private key and the X.509 cert the PKCS#7 message
         * will point to.
         */
        b = BIO_new_file(private_key_name, "rb");
        ERR(!b, "%s", private_key_name);
-        private_key = PEM_read_bio_PrivateKey(b, NULL, NULL, NULL);
+       private_key = PEM_read_bio_PrivateKey(b, NULL, pem_pw_cb, NULL);
+       ERR(!private_key, "%s", private_key_name);
        BIO_free(b);
 
        b = BIO_new_file(x509_name, "rb");

Signature · 1 line

2.4.0

Hi Rusty,

Here's a set of patches that does the following:

(1) Extracts both parts of an X.509 AuthorityKeyIdentifier (AKID) extension. We already extract the bit that can match the subjectKeyIdentifier (SKID) of the parent X.509 cert, but we currently ignore the bits that can match the issuer and serialNumber.

Looks up an X.509 cert by issuer and serialNumber if those are provided in the AKID. If the keyIdentifier is also provided, checks that the subjectKeyIdentifier of the cert found matches that also.

If no issuer and serialNumber are provided in the AKID, looks up an X.509 cert by SKID using the AKID keyIdentifier.

This allows module signing to be done with certificates that don't have an SKID by which they can be looked up.

(2) Makes use of the PKCS#7 facility to provide module signatures.

sign-file is replaced with a program that generates a PKCS#7 message that has no X.509 certs embedded and that has detached data (the module content) and adds it onto the message with magic string and descriptor.

(3) The PKCS#7 message (and matching X.509 cert) supply all the information that is needed to select the X.509 cert to be used to verify the signature by standard means (including selection of digest algorithm and public key algorithm). No kernel-specific magic values are required.

(4) Makes it possible to get sign-file to just write out a file containing the PKCS#7 signature blob. This can be used for debugging and potentially for firmware signing.

(5) Extract the function that does PKCS#7 signature verification on a blob from the module signing code and put it somewhere more general so that other things, such as firmware signing, can make use of it without depending on module config options.

Note that the revised sign-file program no longer supports the "-s <signature>" option as I'm not sure what the best way to deal with this is. Do we generate a PKCS#7 cert from the signature given, or do we get given a PKCS#7 cert? I lean towards the latter. Note that David Woodhouse is looking at making sign-file work with PKCS#11, so bringing back -s might not be necessary.

They can be found here also:

http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7

and are tagged with:

	modsign-pkcs7-20150515

Should these go via the security tree or your tree?

David
---
David Howells (7):
X.509: Extract both parts of the AuthorityKeyIdentifier X.509: Support X.509 lookup by Issuer+Serial form AuthorityKeyIdentifier PKCS#7: Allow detached data to be supplied for signature checking purposes
MODSIGN: Provide a utility to append a PKCS#7 signature to a module
MODSIGN: Use PKCS#7 messages as module signatures system_keyring.c doesn't need to #include module-internal.h
MODSIGN: Extract the blob PKCS#7 signature verifier from module signing

Luis R. Rodriguez (1):
sign-file: Add option to only create signature file

 Makefile                                  |    2 
 crypto/asymmetric_keys/Makefile           |    8 -
 crypto/asymmetric_keys/pkcs7_trust.c      |   10 -
 crypto/asymmetric_keys/pkcs7_verify.c     |   80 ++++--
 crypto/asymmetric_keys/x509_akid.asn1     |   35 ++
 crypto/asymmetric_keys/x509_cert_parser.c |  142 ++++++----
 crypto/asymmetric_keys/x509_parser.h      |    5 
 crypto/asymmetric_keys/x509_public_key.c  |   86 ++++--
 include/crypto/pkcs7.h                    |    3 
 include/crypto/public_key.h               |    4 
 include/keys/system_keyring.h             |    5 
 init/Kconfig                              |   28 +-
 kernel/module_signing.c                   |  212 +--------------
 kernel/system_keyring.c                   |   51 +++-
 scripts/Makefile                          |    2 
 scripts/sign-file                         |  421 -----------------------------
 scripts/sign-file.c                       |  212 +++++++++++++++
 17 files changed, 578 insertions(+), 728 deletions(-)
 create mode 100644 crypto/asymmetric_keys/x509_akid.asn1
 delete mode 100755 scripts/sign-file
 create mode 100755 scripts/sign-file.c

We don't want this in the Kconfig since it might then get exposed in /proc/config.gz. So make it a parameter to Kbuild instead. This also means we don't have to jump through hoops to strip quotes from it, as we would if it was a config option.

We don't want this in the Kconfig since it might then get exposed in /proc/config.gz. So make it a parameter to Kbuild instead. This also means we don't have to jump through hoops to strip quotes from it, as we would if it was a config option.

Quoted 4 lines · David Woodhouse

We don't want this in the Kconfig since it might then get exposed in /proc/config.gz. So make it a parameter to Kbuild instead. This also means we don't have to jump through hoops to strip quotes from it, as we would if it was a config option.

If it were on a network-less, secure sign/build server i'd say it is OK.

However, exposing your private key's password in an environment variable on a regular Linux box is a bit fishy.

Quoted 10 lines · Petko Manolov

Quoted 4 lines · David Woodhouse

We don't want this in the Kconfig since it might then get exposed in /proc/config.gz. So make it a parameter to Kbuild instead. This also means we don't have to jump through hoops to strip quotes from it, as we would if it was a config option.

If it were on a network-less, secure sign/build server i'd say it is OK.

However, exposing your private key's password in an environment variable on a regular Linux box is a bit fishy.

I don't quite understand the objection.

If you want the modules to be signed with an external key of your choice, then for the duration of the 'make modules_sign' run (or 'make modules_install if CONFIG_MODULE_SIG_ALL=y) surely the password has to be available *somehow*?

You are, of course, free to sign the modules by invoking sign-file directly. In which case you *still* need to provide it with the password for the key somehow, if there is one.

Mimi quite rightly pointed out that my original mechanism for this, a CONFIG_MODULE_SIG_KEY_PASSWORD option, was inadvertently exposing it more than was necessary.

As it is now, you *only* need it in the environment for the duration of the operations that actually *use* it.

Do you have a better suggestion?

We don't want this in the Kconfig since it might then get exposed in /proc/config.gz. So make it a parameter to Kbuild instead. This also means we don't have to jump through hoops to strip quotes from it, as we would if it was a config option.

Signed-off-by David Woodhouse <[email protected]>

---
 Documentation/kbuild/kbuild.txt  |  5 +++++
 Documentation/module-signing.txt |  3 +++
 scripts/sign-file.c              | 27 ++++++++++++++++++++++++++-
 3 files changed, 34 insertions(+), 1 deletion(-)

Documentation/kbuild/kbuild.txt +5 -0

index 6466704..0ff6a46 100644
@@ -174,6 +174,11 @@ The output directory is often set using "O=..." on the commandline.
 
 The value can be overridden in which case the default value is ignored.
 
+KBUILD_SIGN_PIN
+--------------------------------------------------
+This variable allows a passphrase or PIN to be passed to the sign-file
+utility when signing kernel modules, if the private key requires such.
+
 KBUILD_MODPOST_WARN
 --------------------------------------------------
 KBUILD_MODPOST_WARN can be set to avoid errors in case of undefined

Documentation/module-signing.txt +3 -0

index c72702e..faaa6ea 100644
@@ -194,6 +194,9 @@ The hash algorithm used does not have to match the one configured, but if it
 doesn't, you should make sure that hash algorithm is either built into the
 kernel or can be loaded without requiring itself.
 
+If the private key requires a passphrase or PIN, it can be provided in the
+$KBUILD_SIGN_PIN environment variable.
+
 
 ============================
 SIGNED MODULES AND STRIPPING

scripts/sign-file.c +26 -1

index 39aaabe..720b9bc 100755
@@ -80,6 +80,27 @@ static void drain_openssl_errors(void)
 		}					\
 	} while(0)
 
+static const char *key_pass;
+
+static int pem_pw_cb(char *buf, int len, int w, void *v)
+{
+	int pwlen;
+
+	if (!key_pass)
+		return -1;
+
+	pwlen = strlen(key_pass);
+	if (pwlen >= len)
+		return -1;
+
+	strcpy(buf, key_pass);
+
+	/* If it's wrong, don't keep trying it. */
+	key_pass = NULL;
+
+	return pwlen;
+}
+
 int main(int argc, char **argv)
 {
 	struct module_signature sig_info = { .id_type = PKEY_ID_PKCS7 };

@@ -96,9 +117,12 @@ int main(int argc, char **argv)
 	BIO *b, *bd = NULL, *bm;
 	int opt, n;
 
+	OpenSSL_add_all_algorithms();
 	ERR_load_crypto_strings();
 	ERR_clear_error();
 
+	key_pass = getenv("KBUILD_SIGN_PIN");
+
 	do {
 		opt = getopt(argc, argv, "dp");
 		switch (opt) {

@@ -132,7 +156,8 @@ int main(int argc, char **argv)
 	 */
 	b = BIO_new_file(private_key_name, "rb");
 	ERR(!b, "%s", private_key_name);
-        private_key = PEM_read_bio_PrivateKey(b, NULL, NULL, NULL);
+	private_key = PEM_read_bio_PrivateKey(b, NULL, pem_pw_cb, NULL);
+	ERR(!private_key, "%s", private_key_name);
 	BIO_free(b);
 
 	b = BIO_new_file(x509_name, "rb");

Signature · 1 line

2.4.0

Definitely better. (FYI, Dmitry's modsig patches from 2012 used the keyring for safely storing a password. )

Quoted 2 lines · Mimi Zohar

Definitely better. (FYI, Dmitry's modsig patches from 2012 used the keyring for safely storing a password. )

Can I add that as a reviewed-by for Dave?

Quoted 4 lines · David Howells

Quoted 2 lines · Mimi Zohar

Definitely better. (FYI, Dmitry's modsig patches from 2012 used the keyring for safely storing a password. )

Without the environment variable set, there's a pop up prompt to enter the pin. A pain to have to enter for each and every kernel module, but definitely a nice option.

Hi Rusty,

Here's a set of patches that does the following:

(1) Extracts both parts of an X.509 AuthorityKeyIdentifier (AKID) extension. We already extract the bit that can match the subjectKeyIdentifier (SKID) of the parent X.509 cert, but we currently ignore the bits that can match the issuer and serialNumber.

Looks up an X.509 cert by issuer and serialNumber if those are provided in the AKID. If the keyIdentifier is also provided, checks that the subjectKeyIdentifier of the cert found matches that also.

If no issuer and serialNumber are provided in the AKID, looks up an X.509 cert by SKID using the AKID keyIdentifier.

This allows module signing to be done with certificates that don't have an SKID by which they can be looked up.

(2) Makes use of the PKCS#7 facility to provide module signatures.

sign-file is replaced with a program that generates a PKCS#7 message that has no X.509 certs embedded and that has detached data (the module content) and adds it onto the message with magic string and descriptor.

(3) The PKCS#7 message (and matching X.509 cert) supply all the information that is needed to select the X.509 cert to be used to verify the signature by standard means (including selection of digest algorithm and public key algorithm). No kernel-specific magic values are required.

I think this is way more complicated than it has to be. Can't we look up certificates by their subjectPublicKeyInfo?

Why is PKCS#7 better than whatever we're using now?

Quoted 2 lines · Andy Lutomirski

I think this is way more complicated than it has to be. Can't we look up certificates by their subjectPublicKeyInfo?

I want to be able to handle an X.509 chain to a root key that we have in the kernel. X.509 certs don't chain on subjectPublicKeyInfo unless that happens to be what's in the SKID (which is a pretty indefinite standard in its own right:-( ). So we need to be able to match on the two things I made available anyway. PKCS#7 matches on one of them too, so that then just works.

Quoted 2 lines

Why is PKCS#7 better than whatever we're using now?

It has a standard form[*]. It has standard ways to specify things such as the key to use and the digest to use. It can carry multiple signatures from different keys and can carry key chains (something that's more likely to be useful for kexec or firmware, admittedly). It can be generated by extant tools (though adding it onto a module needs a special tool).

Would it make more sense to permit X.509 chains to be loaded into the keyring instead if we actually need that feature? IOW, let userspace (or early initramfs stuff) extend our keyring trust to intermediate certs that validly chain to already-trusted things? I think that a reasonable design goal would be that everything overcomplicated that's involved should be optional, and moving toward embedding PKCS#7 signatures in the modules themselves does the other direction?

Quoted 8 lines · Andy Lutomirski

Would it make more sense to permit X.509 chains to be loaded into the keyring instead if we actually need that feature? IOW, let userspace (or early initramfs stuff) extend our keyring trust to intermediate certs that validly chain to already-trusted things? I think that a reasonable design goal would be that everything overcomplicated that's involved should be optional, and moving toward embedding PKCS#7 signatures in the modules themselves does the other direction?

This is similar to what i am doing right now - create CA hierarchy so we can have something like:

                               +-> KeyB
                               |
RootCA --->  CertA ---> CertB ---> CertC ---> KeyC
                    |
                    +-> CertA' ---> KeyA"

The RootCA may be the one whose private key was used to sign the modules and all downstream certificates are either directly signed by it or one of the others. Not all of the infrastructure is in the mainline kernel, but this can easily be rectified.

Now, as Mimi pointed out this scheme is flawed and should be used with care if at all. Revoking certificates is always a PITA. Being valid for one year only adds to the fun.

Petko

Quoted 19 lines · Petko Manolov

Quoted 8 lines · Andy Lutomirski

Would it make more sense to permit X.509 chains to be loaded into the keyring instead if we actually need that feature? IOW, let userspace (or early initramfs stuff) extend our keyring trust to intermediate certs that validly chain to already-trusted things? I think that a reasonable design goal would be that everything overcomplicated that's involved should be optional, and moving toward embedding PKCS#7 signatures in the modules themselves does the other direction?

This is similar to what i am doing right now - create CA hierarchy so we can have something like:

                               +-> KeyB
                               |
RootCA --->  CertA ---> CertB ---> CertC ---> KeyC
                    |
                    +-> CertA' ---> KeyA"

Quoted 4 lines

The RootCA may be the one whose private key was used to sign the modules and all downstream certificates are either directly signed by it or one of the others. Not all of the infrastructure is in the mainline kernel, but this can easily be rectified.

Right. I guess that I can imagine some uses for this, but I don't see why those intermediate certs would be embedded with the signatures being verified as opposed to being loaded beforehand.

Quoted 4 lines

Now, as Mimi pointed out this scheme is flawed and should be used with care if at all. Revoking certificates is always a PITA. Being valid for one year only adds to the fun.

Valid for only one year is worse than that. We might be verifying the signature on our clock driver :) I think that, at best, we could reject certificates that expired before the running kernel was built.

Quoted 8 lines · Andy Lutomirski

Would it make more sense to permit X.509 chains to be loaded into the keyring instead if we actually need that feature? IOW, let userspace (or early initramfs stuff) extend our keyring trust to intermediate certs that validly chain to already-trusted things? I think that a reasonable design goal would be that everything overcomplicated that's involved should be optional, and moving toward embedding PKCS#7 signatures in the modules themselves does the other direction?

This is similar to what i am doing right now - create CA hierarchy so we can have something like:

                               +-> KeyB
                               |
RootCA --->  CertA ---> CertB ---> CertC ---> KeyC
                    |
                    +-> CertA' ---> KeyA"

The RootCA may be the one whose private key was used to sign the modules and all downstream certificates are either directly signed by it or one of the others. Not all of the infrastructure is in the mainline kernel, but this can easily be rectified.

Now, as Mimi pointed out this scheme is flawed and should be used with care if at all. Revoking certificates is always a PITA. Being valid for one year only adds to the fun.

Quoted 10 lines · Petko Manolov

Quoted 8 lines · Andy Lutomirski

Would it make more sense to permit X.509 chains to be loaded into the keyring instead if we actually need that feature? IOW, let userspace (or early initramfs stuff) extend our keyring trust to intermediate certs that validly chain to already-trusted things? I think that a reasonable design goal would be that everything overcomplicated that's involved should be optional, and moving toward embedding PKCS#7 signatures in the modules themselves does the other direction?

Quoted 8 lines

This is similar to what i am doing right now - create CA hierarchy so we can have something like:

                               +-> KeyB
                               |
RootCA --->  CertA ---> CertB ---> CertC ---> KeyC
                    |
                    +-> CertA' ---> KeyA"

How exactly do you go about uploading CertB to the kernel BTW? And could fw signing replace that functionality? Keep in mind "fw uploading" should be rebranded as "system data upload", which is one of the goals I have when extending the firware_class module.

One option would be to add another type of verifiable thing. We can verify modules, and we should add firmware to the types of things that can be signed. We could add signing keys, too. IOW, you could ask the kernel to load a signing key with certain rights, and, if they key is validly signed by some other key that has the same rights and has a bit set saying that it can delegate those rights, then the kernel will add that signing key to the keyring.

If the general infrastructure were there, this would be very little additional code.

Quoted 11 lines · Andy Lutomirski

One option would be to add another type of verifiable thing. We can verify modules, and we should add firmware to the types of things that can be signed. We could add signing keys, too. IOW, you could ask the kernel to load a signing key with certain rights, and, if they key is validly signed by some other key that has the same rights and has a bit set saying that it can delegate those rights, then the kernel will add that signing key to the keyring.

If the general infrastructure were there, this would be very little additional code.

I really like this idea, but I've heard of many great ideas before followed by nothing but vaporware. So is it a direct requirement to implicate blocking a change for current module signature checking strategy to a new one given the concerns you raise, or can we enable those who wish to want additional better solutions as the one you propose to opt-in to develop those solutions? I like the idea of the later given that it seems those using the current module signing infrastructure would prefer the change and enabling what you say does not seem to be a not possible based on allowing that to be advanced.

From my POV (and keep in mind that I'm not really involved in this

Given that, I would say that merely shoving firmware files through the module verifier as-is would not be okay.

Quoted 2 lines · Andy Lutomirski

Given that, I would say that merely shoving firmware files through the module verifier as-is would not be okay.

Replacing one dog and pony show for another is what is going on, what you describe and suggest seems best, and I welcome patches, it seems you know what you are talking about :)

Quoted 4 lines · Luis R. Rodriguez

Quoted 2 lines · Andy Lutomirski

Given that, I would say that merely shoving firmware files through the module verifier as-is would not be okay.

Quoted 4 lines

Replacing one dog and pony show for another is what is going on, what you describe and suggest seems best, and I welcome patches, it seems you know what you are talking about :)

Don't hold your breath. My plate is over-full. I'm probably a decent reviewer of crypto, though.

Quoted 5 lines · Andy Lutomirski

Quoted 4 lines · Luis R. Rodriguez

Quoted 2 lines · Andy Lutomirski

Given that, I would say that merely shoving firmware files through the module verifier as-is would not be okay.

Quoted 7 lines

Quoted 4 lines

Replacing one dog and pony show for another is what is going on, what you describe and suggest seems best, and I welcome patches, it seems you know what you are talking about :)

Don't hold your breath. My plate is over-full. I'm probably a decent reviewer of crypto, though.

Well as good as you are in 10 years we'll have better ones. So when module signature went into the kernel the real expectation should have been:

This code looks good now but is going to be complete shit and breakable a few years from now.

Hence my first implicit and now explicit claims on dog and pony shows. Best thing we can do IMHO is to just allow us to replace stupid human code with better human code later, and eventually hopefully better AI code, and so on. Since you don't have time for a real replacement maybe what we can do is at least document / target / agree for what pipe dream we want and shoot for it with time. Hopefully folks will find time to implement it.

In the meantime should that block current dog and pony show trading? I don't think so.

Quoted 8 lines · Luis R. Rodriguez

Well as good as you are in 10 years we'll have better ones. So when module signature went into the kernel the real expectation should have been:

This code looks good now but is going to be complete shit and breakable a few years from now.

Quoted 7 lines

Hence my first implicit and now explicit claims on dog and pony shows. Best thing we can do IMHO is to just allow us to replace stupid human code with better human code later, and eventually hopefully better AI code, and so on. Since you don't have time for a real replacement maybe what we can do is at least document / target / agree for what pipe dream we want and shoot for it with time. Hopefully folks will find time to implement it.

I disagree. I'm a firm believer in security proofs. While I'm not trained in formal crypto proofs, I can sketch out a proof of why a system that properly tags its signatures is secure against a reasonable threat model. I can also show why that proof wouldn't work for a scheme without tags, and I can demonstrate the actual weakness in a scheme without tags.

In ten years, the only reason a scheme that I say looks good would be because (a) I screwed up, (b) an underlying assumption is wrong, or
(c) the implementation is subtly wrong. In particular, it won't fail because I'm insufficiently clever.

A real professional expert would be less likely to screw up.

(For reference, I wrote an actual doctoral thesis involving crypto.)

Quoted 2 lines

In the meantime should that block current dog and pony show trading? I don't think so.

Yes, since I can demonstrate the actual weakness without tags,

and
crypto is notoriously hard to fix once done poorly and there's a great history of obviously-theoretically-weak systems being meaningfully attacked in the real world. See, for example, every single old SSL/TLS cipher. (And yes, the crypto community knew what was wrong in theory and how to fix it when the protocol was designed. People just didn't pay attention.)

Quoted 24 lines · Andy Lutomirski

Quoted 8 lines · Luis R. Rodriguez

Well as good as you are in 10 years we'll have better ones. So when module signature went into the kernel the real expectation should have been:

This code looks good now but is going to be complete shit and breakable a few years from now.

Quoted 7 lines

Hence my first implicit and now explicit claims on dog and pony shows. Best thing we can do IMHO is to just allow us to replace stupid human code with better human code later, and eventually hopefully better AI code, and so on. Since you don't have time for a real replacement maybe what we can do is at least document / target / agree for what pipe dream we want and shoot for it with time. Hopefully folks will find time to implement it.

I disagree. I'm a firm believer in security proofs. While I'm not trained in formal crypto proofs, I can sketch out a proof of why a system that properly tags its signatures is secure against a reasonable threat model. I can also show why that proof wouldn't work for a scheme without tags, and I can demonstrate the actual weakness in a scheme without tags.

Quoted 8 lines

In ten years, the only reason a scheme that I say looks good would be because (a) I screwed up, (b) an underlying assumption is wrong, or
(c) the implementation is subtly wrong. In particular, it won't fail because I'm insufficiently clever.

A real professional expert would be less likely to screw up.

(For reference, I wrote an actual doctoral thesis involving crypto.)

OK, I think what I mentioned still holds:

these premises must hold true for a period of time, and provided you have all information. You cannot have all the information, so the "threat model" depends on the reviewer, and the information they have access to. So, still its still a dog and pony show, at least a temporal one or one with a set of clauses.

Quoted 4 lines

Quoted 2 lines

In the meantime should that block current dog and pony show trading? I don't think so.

Yes, since I can demonstrate the actual weakness without tags,

But you don't want to do the work to provide a better replacement?

Quoted 8 lines

and
crypto is notoriously hard to fix once done poorly and there's a great history of obviously-theoretically-weak systems being meaningfully attacked in the real world. See, for example, every single old SSL/TLS cipher. (And yes, the crypto community knew what was wrong in theory and how to fix it when the protocol was designed. People just didn't pay attention.)

Its a fair argument, but still -- we have the vaporware problem.

Without tagging the purpose of the signed file, you simply don't have a cryptographic guarantee of that. The bad guy can load something else that was signed for an entirely different purpose into the wrong device, possibly crashing it, causing buffer overflows because the format is wrong, or doing any number of other bad things.

Quoted 5 lines · Andy Lutomirski

Without tagging the purpose of the signed file, you simply don't have a cryptographic guarantee of that. The bad guy can load something else that was signed for an entirely different purpose into the wrong device, possibly crashing it, causing buffer overflows because the format is wrong, or doing any number of other bad things.

One suggestion David Woodhouse made with regard to tagging is that the tag could just be added into the digest before it is signed/verified and not actually stored in the signature.

This means that if you try loading the firmware for the wrong request, the signature verification will fail.

It's an interesting approach that's simple to achieve, but it has the downside that the signature will be invalid in the mismatch situation and you can't tell whether it's because the module is being misused or the signature is just wrong. However, that might be livable with.

In PKCS#7 land, you don't. Instead you stick CertB and CertC into the PKCS#7 signature on the module signed by KeyC.

Quoted 8 lines

This is similar to what i am doing right now - create CA hierarchy so we can have something like:

                               +-> KeyB
                               |
RootCA --->  CertA ---> CertB ---> CertC ---> KeyC
                    |
                    +-> CertA' ---> KeyA"

How exactly do you go about uploading CertB to the kernel BTW?

Quoted 9 lines · Luis R. Rodriguez

Quoted 8 lines

This is similar to what i am doing right now - create CA hierarchy so we can have something like:

                               +-> KeyB
                               |
RootCA --->  CertA ---> CertB ---> CertC ---> KeyC
                    |
                    +-> CertA' ---> KeyA"

Quoted 1 line

How exactly do you go about uploading CertB to the kernel BTW?

Assuming RootCA or CertA is present in the kernel, the idea would be to use the add_key() system call or the request_key() mechanism to add the key to the system keyring. The key in the cert would only be added to the keyring if it is trusted by a key already there.

From Petko's description, the RootCA is on the system keyring, but CertA

Quoted 13 lines · David Howells

Quoted 10 lines · Luis R. Rodriguez

Quoted 8 lines

This is similar to what i am doing right now - create CA hierarchy so we can have something like:

                               +-> KeyB
                               |
RootCA --->  CertA ---> CertB ---> CertC ---> KeyC
                    |
                    +-> CertA' ---> KeyA"

How exactly do you go about uploading CertB to the kernel BTW?

Quoted 4 lines

Assuming RootCA or CertA is present in the kernel, the idea would be to use the add_key() system call or the request_key() mechanism to add the key to the system keyring. The key in the cert would only be added to the keyring if it is trusted by a key already there.

From Petko's description, the RootCA is on the system keyring, but CertA is on a new IMA trusted CA keyring. So everything you said is true, but on this new, yet to be upstreamed, IMA trusted CA keyring.

That being said, are you actually planning on implementing X.509 chain validation correctly? ISTM you can't really do it usefully, as we don't even know what time it is when we run this code.