[Cryptography] HSM's to be required for Code Signing Certificates

[Dirk-Willem van Gulik]

> On 29 Jan 2017, at 11:04, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> 
> Bill Frantz <frantz at pwpconsult.com> writes:
> 
>> It seems to me one could build a HSM auditor which passively monitors the
>> interface to the HSM and records the time of every signing operation. If the
>> communication between the computer and the HSM is in the clear, more
>> information could be recorded, but just the time the signing operations are
>> performed would provide a useful audit trail.
> 
> That's been hypothesised before, a transaction-sequence enforcement mechanism
> that only allows particular sequences of operations, assigned to user roles,
> with auditing, and so on.  Unfortunately it gets complicated really quickly,
> and by and large it's just an awkward way to build a higher-level API using a
> sort of macro capability.  So in the long run it's better to provide an API
> like "turn this text document into an S/MIME signed message" than to provide a
> capability to string together a sequence of operations yourself that do the
> same thing.


Agreed. And the current APIs make things like signing a hash/blob really rather robust and cross tool compatible. 

So we do something rather much simpler (and this was driven not so much by security but by the need to reduce audit/compliance costs) to allow very low organisational impact of the signing of binaries - with conversely a fairly strong governance role for a human (which we really do not want to have too much unfettered access to the enterprise signing key):

Going back to code signing (in an agile/playstore/appstore world):

- We have introduced the concept of naming the final ‘ready for rollout’ release always by its sha256 — thus making it harder to guess or ‘assume’ a +1 version number indicates ‘they prolly did a new release; it smells newer, so lets push it through’ thing.

- The HSM issues signs CSRs/issues chipcards to persons in the release manager role.

- End users (release managers) use dead normal PKI (chipcards) in to sign (the hash of) a file in their standard windows/mac (s/mime) environment & tools.

- The HSM will sign any hash that it is offered provided it is signed by a key it has issued itself.  It ‘valid from’ date is 6 hours in the future during normal working days (the pre-seed and organisational processes take some 24 hours or more)

- On the older systems we use a simple counter (part of the serial); for the newer systems we copied the log proofs of the Certificate Transparency project.

- The end user gets a message from the HSM which he or she needs for the further governance process around rollot.

Most of this works well - the one issue we have is that the HSM is really rather exposed/too smart.

But it does solve the audit trail issue (at the expense of security).

Dw.