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

Since we are apparently *not* getting any information from the platform vendors
mentioned on how *they* address these issues in *already released* and
soon-to-be released products this activity remains firmly dead-in-the-water
including the "Korean bank" use-case.

W3C needs to move on to more fruitful areas like non-controversial
*domain-restricted* cryptographic JS APIs with [IMO] fairly limited use-cases
and leave "the real stuff" to the vendors and Darwin (the market) to sort out.

The TrustedComputingGroup (which I am an invited expert member of) dismissed
standardization of the enrollment part for TPMs, presumably for a reason.

Actually there is already a JS-callable Crypto API in MSIE.  It is known
as "CertEnroll" and verifies my claims that opening up a cryptographic
subsystem to untrusted browser-code is a unwieldy concept.  However, it was
introduced with Windows 98 and at that time we didn't know better :-)

Anders



On 2011-12-01 01:25, Mitch Zollinger wrote:
> 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 08:55:58 UTC