www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Temme <san...@temme.net>
Subject Re: Official code signing certificate
Date Wed, 27 Mar 2013 11:19:39 GMT

I have not read this entire thread and will have no time to do so.  But I did want to add
some comments to this discussion

On Mar 25, 2013, at 11:48 PM, Clint Modien <cmodien@gmail.com> wrote:

> Should the key/cert ever be _suspected_ of being compromised and the key/cert needs to
be changed… it will invalidate the currently signed code running on users systems.  

This is not the case if the binary is time-stamped as well as signed: the Windows OS will
trust the signature on a signed, time-stamped binary if the signature was made during the
validity period, and before any revocation, of the certificate.  See:


for more information.  Various components of Windows itself are signed and time-stamped this
way to ensure that your operating system does not break as the certificate for the key that
signed the binaries expires.

> And infra could then provide a strongly worded wiki page about the protection of the
certs and keys and the consequences associated with compromised keys/certs.

Unfortunately, it's not that easy.  Code signing keys are a weapon, with far-reaching implications
in spite of the best intentions.  The code signing certificate issued for your key is trusted
by millions of PCs, and of great value to malicious actors for that reason alone.  There have
been multiple cases of malware signed with official keys/certificates, sometimes subverting
build servers deep inside vendors' infrastructure.  Signed malware is blindly trusted by the
operating system that is asked to load it: the capability to get a signature is of more value
to said malicious actors than anything else in our infrastructure.  In our case, the signing
server would be directly on the public Internet, or at best one hop away.  Please don't subject
our Infrastructure team to the burden of defending this high profile target.

Code signing keys, especially ones that have a real, trusted code signing certificate, should
only be used in specialized cryptographic hardware, under physical control of one, preferably
multiple authorized persons.  This means signing should be done offline, in a signing ceremony
during which said authorized persons can verify the integrity of the release before issuing
the signature.  This process is not unlike  what Clint sketches below, except I would not
consider a USB stick to be sufficiently secure storage for a code signing key.  

For Continuous Integration builds, you can create certificates outside the official Windows
trust store. This doesn't have to be your own infrastructure: you can have this hosted by
Symantec et. al. (for a price no doubt) or perhaps ask someone like CACert.org who already
have infrastructure and processes set up.  The benefit of this is that anyone can install,
run and test signed software by dropping the root certificate into their trust store, but
CI builds are not trusted by the PCs used by the public at large.   The doc linked above discusses
this approach to signing software for QA purposes.

I'm not saying that you shouldn't sign software, or should't get an officially signed code
signing certificate.  But be sure to surround the signing keys with the proper process and


> On Mar 25, 2013, at 10:27 AM, Clint Modien <cmodien@gmail.com> wrote:
>> When I worked on a project for Amazon the binaries were submitted via ssh to the
security department along with an md5 file for each binary.
>> Before the project started I was required to produce a step by step document for
signing the code. (tools, downloads, setup)
>> After the binaries were checked against their associated md5 hashes, security then
simply signed the binaries according to the process outlined in the document.
>> I was told that the cert and private key were kept on a usb stick in a safe and the
protocols surrounding the handling of the usb stick were as strict as those used for nuclear
launch codes.
>> I feel like the process to sign most code nowadays does not require the cert+key
be available during compilation… but I could be wrong.
>> On Mar 25, 2013, at 9:06 AM, Rob Weir <robweir@apache.org> wrote:
>>> I like the idea of having multiple PMC members attest to the RC, by
>>> signing or whatever.  But we still would need to tie that back to a
>>> SVN revision number somehow.   In other words, how we do prove the
>>> revision number that was used to build the RC?
>>> Perhaps the flow is like this:
>>> 1) RC built by buildbot and that records the SVN revision.
>>> 2) Three PMC members sign the RC
>>> 3) Comparison of the MD5 hashes for the signed RC and the buildbot
>>> output confirms the revision that was used.
>>> 4) Infra then releases the signing cert for use by buildbot automation
>>> to rebuild the same revision

sander@temme.net              http://www.temme.net/sander/
PGP FP: FC5A 6FC6 2E25 2DFD 8007  EE23 9BB8 63B0 F51B B88A

View raw message