Messages in this thread | | | Subject | Re: [PATCH v2] scripts/sign-file.c: Add support for signing with a raw signature | From | David Woodhouse <> | Date | Wed, 10 Feb 2016 10:25:13 +0000 |
| |
On Wed, 2016-02-10 at 10:12 +0000, David Howells wrote: > Juerg Haefliger <juerg.haefliger@hpe.com> wrote: > > > This patch adds support for signing a kernel module with a raw > > detached PKCS#7 signature/message. > > > > The signature is not converted and is simply appended to the module so > > it needs to be in the right format. Using openssl, a valid signature can > > be generated like this: > > $ openssl smime -sign -nocerts -noattr -binary -in -inkey \ > > -signer -outform der -out > > > > The resulting raw signature from the above command is (more or less) > > identical to the raw signature that sign-file itself can produce like > > this: > > $ scripts/sign-file -d > > What's the usage case for this? Can it be done instead with openssl PKCS#11?
Ah, right. That's what it was doing. Yeah, I have a vague recollection of looking at this as we were doing the conversion to C, and concluding that it was indeed a hackish workaround for the fact that the existing setup didn't allow using external crypto devices via PKCS#11.
If you want to generate your signatures using external hardware, then using sign-file with a PKCS#11 key definitely seems like the way to do it. I believe I even tested it with the p11-kit remote mechanism, doing the signing on a remote system over SSH.
There doesn't seem to be much of an excuse for doing otherwise on security grounds — if this is the build system and you're going to trust the modules which were built here, then copying them to separate system and producing the signatures there is not really any different to just allowing this system to invoke the signature-creation for itself via PKCS#11, is it?
-- -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation
[unhandled content-type:application/x-pkcs7-signature] | |