summaryrefslogtreecommitdiff
path: root/scripts/sign-file.c
AgeCommit message (Collapse)AuthorFilesLines
2015-09-25MODSIGN: Change from CMS to PKCS#7 signing if the openssl is too oldDavid Howells1-17/+77
The sign-file.c program actually uses CMS rather than PKCS#7 to sign a file since that allows the target X.509 certificate to be specified by subjectKeyId rather than by issuer + serialNumber. However, older versions of the OpenSSL crypto library (such as may be found in CentOS 5.11) don't support CMS. Assume everything prior to OpenSSL-1.0.0 doesn't support CMS and switch to using PKCS#7 in that case. Further, the pre-1.0.0 OpenSSL only supports PKCS#7 signing with SHA1, so give an error from the sign-file script if the caller requests anything other than SHA1. The compiler gives the following error with an OpenSSL crypto library that's too old: HOSTCC scripts/sign-file scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or directory #include <openssl/cms.h> Reported-by: Vinson Lee <vlee@twopensource.com> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: David Woodhouse <David.Woodhouse@intel.com>
2015-09-15modsign: Fix GPL/OpenSSL licence incompatibilityDavid Woodhouse1-5/+8
The GPL does not permit us to link against the OpenSSL library. Use LGPL for sign-file and extract-file instead. [ The whole "openssl isn't compatible with gpl" is really just fear-mongering, but there's no reason not to make modsign LGPL, so nobody cares. - Linus ] Reported-by: Julian Andres Klode <jak@jak-linux.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Julian Andres Klode <jak@jak-linux.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-08-13sign-file: Fix warning about BIO_reset() return valueDavid Howells1-1/+1
Fix the following warning: scripts/sign-file.c: In function ‘main’: scripts/sign-file.c:188: warning: value computed is not used whereby the result of BIO_ctrl() is cast inside of BIO_reset() to an integer of a different size - which we're not checking but probably should. Reported-by: James Morris <jmorris@namei.org> Signed-off-by: David Howells <dhowells@redhat.com>
2015-08-12PKCS#7: Appropriately restrict authenticated attributes and content typeDavid Howells1-2/+3
A PKCS#7 or CMS message can have per-signature authenticated attributes that are digested as a lump and signed by the authorising key for that signature. If such attributes exist, the content digest isn't itself signed, but rather it is included in a special authattr which then contributes to the signature. Further, we already require the master message content type to be pkcs7_signedData - but there's also a separate content type for the data itself within the SignedData object and this must be repeated inside the authattrs for each signer [RFC2315 9.2, RFC5652 11.1]. We should really validate the authattrs if they exist or forbid them entirely as appropriate. To this end: (1) Alter the PKCS#7 parser to reject any message that has more than one signature where at least one signature has authattrs and at least one that does not. (2) Validate authattrs if they are present and strongly restrict them. Only the following authattrs are permitted and all others are rejected: (a) contentType. This is checked to be an OID that matches the content type in the SignedData object. (b) messageDigest. This must match the crypto digest of the data. (c) signingTime. If present, we check that this is a valid, parseable UTCTime or GeneralTime and that the date it encodes fits within the validity window of the matching X.509 cert. (d) S/MIME capabilities. We don't check the contents. (e) Authenticode SP Opus Info. We don't check the contents. (f) Authenticode Statement Type. We don't check the contents. The message is rejected if (a) or (b) are missing. If the message is an Authenticode type, the message is rejected if (e) is missing; if not Authenticode, the message is rejected if (d) - (f) are present. The S/MIME capabilities authattr (d) unfortunately has to be allowed to support kernels already signed by the pesign program. This only affects kexec. sign-file suppresses them (CMS_NOSMIMECAP). The message is also rejected if an authattr is given more than once or if it contains more than one element in its set of values. (3) Add a parameter to pkcs7_verify() to select one of the following restrictions and pass in the appropriate option from the callers: (*) VERIFYING_MODULE_SIGNATURE This requires that the SignedData content type be pkcs7-data and forbids authattrs. sign-file sets CMS_NOATTR. We could be more flexible and permit authattrs optionally, but only permit minimal content. (*) VERIFYING_FIRMWARE_SIGNATURE This requires that the SignedData content type be pkcs7-data and requires authattrs. In future, this will require an attribute holding the target firmware name in addition to the minimal set. (*) VERIFYING_UNSPECIFIED_SIGNATURE This requires that the SignedData content type be pkcs7-data but allows either no authattrs or only permits the minimal set. (*) VERIFYING_KEXEC_PE_SIGNATURE This only supports the Authenticode SPC_INDIRECT_DATA content type and requires at least an SpcSpOpusInfo authattr in addition to the minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and an S/MIME capabilities authattr because the pesign program doesn't remove these). (*) VERIFYING_KEY_SIGNATURE (*) VERIFYING_KEY_SELF_SIGNATURE These are invalid in this context but are included for later use when limiting the use of X.509 certs. (4) The pkcs7_test key type is given a module parameter to select between the above options for testing purposes. For example: echo 1 >/sys/module/pkcs7_test_key/parameters/usage keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7 will attempt to check the signature on stuff.pkcs7 as if it contains a firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE). Suggested-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Marcel Holtmann <marcel@holtmann.org> Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-12sign-file: Generate CMS message as signature instead of PKCS#7David Howells1-24/+27
Make sign-file use the OpenSSL CMS routines to generate a message to be used as the signature blob instead of the PKCS#7 routines. This allows us to change how the matching X.509 certificate is selected. With PKCS#7 the only option is to match on the serial number and issuer fields of an X.509 certificate; with CMS, we also have the option of matching by subjectKeyId extension. The new behaviour is selected with the "-k" flag. Without the -k flag specified, the output is pretty much identical to the PKCS#7 output. Whilst we're at it, don't include the S/MIME capability list in the message as it's irrelevant to us. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-By: David Woodhouse <David.Woodhouse@intel.com
2015-08-07modsign: Allow signing key to be PKCS#11David Woodhouse1-5/+24
This is only the key; the corresponding *cert* still needs to be in $(topdir)/signing_key.x509. And there's no way to actually use this from the build system yet. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: David Howells <dhowells@redhat.com>
2015-08-07modsign: Allow password to be specified for signing keyDavid Woodhouse1-1/+26
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 <David.Woodhouse@intel.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2015-08-07sign-file: Add option to only create signature fileLuis R. Rodriguez1-3/+10
Make the -d option (which currently isn't actually wired to anything) write out the PKCS#7 message as per the -p option and then exit without either modifying the source or writing out a compound file of the source, signature and metadata. This will be useful when firmware signature support is added upstream as firmware will be left intact, and we'll only require the signature file. The descriptor is implicit by file extension and the file's own size. Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: David Howells <dhowells@redhat.com>
2015-08-07MODSIGN: Provide a utility to append a PKCS#7 signature to a moduleDavid Howells1-0/+205
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 <dhowells@redhat.com> Tested-by: Vivek Goyal <vgoyal@redhat.com>