[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography
Subject:    Re: [Cryptography] [FORGED] Re: HSM's to be required for Code	Signing Certificates
From:       Dirk-Willem van Gulik <dirkx () webweaving ! org>
Date:       2017-01-31 14:40:32
Message-ID: 6ECC3247-A4FE-4CAA-A5BF-6EC36EFF444F () webweaving ! org
[Download RAW message or body]


> On 31 Jan 2017, at 12:20, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> 
> Salz, Rich <rsalz@akamai.com> writes:
> 
> > The HSM's used in the SET key-signing included in every reply, an operation
> > count, and a digest of the input parameters. It was custom code embedded in
> > the HSM by CertCo.  I have one as a souvenir.  I wish all HSM's did that.
> 
> Fortezza cards did this too, they had both a monotonic counter and a real-time
> clock in the device.  The way it worked was that the untrusted host could read
> out the time and counter value from the secure device to the untrusted host
> and then bind it into the signature they told they secure device to create.
> 
> This is why I refer to some HSMs as crypto yes-boxes…

In this context - code signing - why would that be wrong ? 

If you have the common situation that some sort of governance process sees a piece of \
code ultimately declared fit for distribution; and this is tied to a release manager \
(or a cabal thereof) — why would it be inappropriate for a HSM to simply be the yes \
man. 

I.e. sign the executable hash if the release manager requests it to do so - with only \
a modicum of counting or audit to keep everyone honest and detecting something \
‘extra' signed within days or weeks.

As in the code signing case - it is the fact that you do not want the signing key to \
sit on every developers laptop; the threats w.r.t. the binary are often tackled \
elsewhere/are not part of what an HSM can really help with.

Or am I missing something ?

Dw
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


[prev in list] [next in list] [prev in thread] [next in thread]