Closed g-k closed 5 years ago
Links:
https://docs.microsoft.com/en-us/windows/desktop/SecCrypto/time-stamping-authenticode-signatures
https://docs.microsoft.com/en-us/dotnet/framework/tools/signtool-exe
more links in https://github.com/erocarrera/pefile#additional-resources
the v1 spec from 2008 http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx (https://www.microsoft.com/whdc/winlogo/drvsign/Authenticode_PE.mspx 404s but web.archive.org used to redirect there as of 2017) which says:
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. ...
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.
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.
:+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/
/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?
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:
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.
It's not clear to me PSS will work?
Fixed in #319
refs: https://bugzilla.mozilla.org/show_bug.cgi?id=1540276
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode
cc @catlee @escapewindow