mozilla-services / autograph

Mozilla's digital signature service
https://hub.docker.com/r/mozilla/autograph/
Mozilla Public License 2.0
152 stars 34 forks source link

support Windows authenticode signing #259

Closed g-k closed 5 years ago

g-k commented 5 years ago

refs: https://bugzilla.mozilla.org/show_bug.cgi?id=1540276

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode

cc @catlee @escapewindow

g-k commented 5 years ago

Links:

Authenticode is based on the Public-Key Cryptography Standards (PKCS) #7 standard and uses X.509 v3 certificates to bind an Authenticode-signed file to the identity of a software publisher. ... The Authenticode signature in a PE file is in a PKCS #7 SignedData structure. The signature asserts that: • The file originates from a specific software publisher. • The file has not been altered since it was signed. ...

image

We'll have to figure out how to talk to the timestamp authority and whether autograph should do that or signingscript should otherwise a quick glance makes this look like we could use a /sign/hash of PKCS7 data.

catlee commented 5 years ago

We have tools that can take an existing PKCS7 signature and inject it into a PE file. I think the next step here would be to see if we can reproduce that signature by passing along just the relevant content hash from the original file.

g-k commented 5 years ago

:+1: /sign/hash should work then.

Does RelEng have a dummy key, cert, hash and signed result we can use as a testcase or should we generate new ones for autograph?

Should be able to test against this implementation: https://code.google.com/archive/p/verify-sigs/

catlee commented 5 years ago

/sign/hash should be a good starting point :)

The PE signatures have a bunch of extra/legacy content in them (e.g. the spcPEImageData section). Would that make sense to add into autograph, or in signingscript?

g-k commented 5 years ago

The PE signatures have a bunch of extra/legacy content in them (e.g. the spcPEImageData section). Would that make sense to add into autograph, or in signingscript?

signingscript makes sense to me. Assuming the extra content isn't included in the submitted hash (looks like there are a bunch of optional fields in the spec) and it's not much data, signingscript could submit the extra data with /sign/hash requests. Also, delegating parsing and repacking to signingscript/signtool should be more flexible for testing and deployment and avoid parser mismatches leading to bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=1534483

That said, I haven't dug into the signature format and there is a go stdlib PE file parser https://golang.org/pkg/debug/pe/ and a port of pefile https://github.com/omarghader/pefile-go so we could handle more signature data or go the /sign/file route too.

Implementation-wise:

Looks like I can generate a test CA and cert following this procedure: https://mana.mozilla.org/wiki/display/RelEng/Signing#Signing-GeneratenewCAandcertificate

More links:

jvehent commented 5 years ago

So we're going with /sign/hash on autograph's side (probably just rsa-pss) and @catlee will wrestle with existing tools to get the pkcs7 issued.

We'll have to manage the authenticode cert renewal with private key in the hsm. I'm planning to clean up the gencsr tool for that.

jethrogb commented 5 years ago

It's not clear to me PSS will work?

g-k commented 5 years ago

Fixed in #319