www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Official code signing certificate
Date Sat, 30 Mar 2013 19:15:00 GMT

It looks like there needs to be two processes that are identical except for the conditions
in which they occur.

On Mar 27, 2013, at 4:19 AM, Sander Temme wrote:

> All, 
> 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:
> http://msdn.microsoft.com/en-gb/library/windows/hardware/gg487309.aspx
> 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.

From my experience with codesigning of Assemblies I know you are correct.

>> 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.  

(1) Releases signed with the real trusted code signing certificate must be built in a secure

Is it possible to define the requirements for the ultra secure environment?

> 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.

(2) CI build process. This means that we concentrate on creating reproducible builds with
this style of certificate. Does this approach work on the Mac in an analogous way?

> 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 equipment.  

Let's outline the proper process from a high level:

- PMC starts an RC process.

- In the secure environment the Release Manager builds release artifacts signed using the
QA signing process used in CI builds.

- The state of the secure environment is preserved.

- The community tests and votes on the QA signed artifacts.

- The release vote passes.

- The state of the secure environment is restored.

- In the secure environment the Release Manager builds release artifacts signed using the
officially signed code signing certificate.

- The officially signed artifacts are released.

Some questions about the secure environment.

Must it be a physical environment?
What sign and build steps in the secure environments must be performed by a "Security Officer"?


> S.
>> 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