W3C home > Mailing lists > Public > public-identity@w3.org > December 2011

Re: Crypto HW Requirements (why it is out of scope)

From: Mitch Zollinger <mzollinger@netflix.com>
Date: Wed, 30 Nov 2011 16:25:19 -0800
Message-ID: <4ED6C96F.2030706@netflix.com>
To: <public-identity@w3.org>
On 11/22/2011 10:02 PM, Anders Rundgren wrote:
> The main point with crypto hardware is strong protection of secret/private keys, right?
>
> If an API doesn't make it possible to distinguish if keys are created in crypto hardware
> or are stored in a file on the harddisk, such an API seems fairly useless from an issuer
> perspective.

I believe this is true in the generic browser case, yes. However, when 
WebKit is customized for use case like ours, the generic API used to 
access runtime generated "session" keys and the HW embedded 
pre-provisioned keys can be (and actually are with our current 
implementation) one and the same. Only the names of the keys differ & 
since we know what our keys are called & which ones are embedded, we 
kinda' skirt the whole "find out which keys are protected in hardware 
via the API" issue.

So long as the APIs don't preclude arbitrarily named keys, we're happy.

Mitch

>
> I'm pretty sure that this is addressed in the Google Wallet but this scheme is currently
> secret so I don't see how we (at this stage) could even have a meaningful dialog
> about methods and requirements regarding schemes for supporting crypto hardware.
>
> Microsoft has also publicly demonstrated Win8/TPM and U-Prove/smart card schemes
> without disclosing any details on how keys are provisioned.
>
> Trying to create related standards under these circumstances is IMHO simply put silly.
>
> I don't consider my own effort in this space a "standardization effort" since it doesn't
> build on existing crypto hardware or software standards.  I don't believe the latter is
> even workable as a starting point for both political and technical reasons.
>
> Anders
>
>
Received on Thursday, 1 December 2011 00:25:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 December 2011 00:25:49 GMT