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: Thu, 1 Dec 2011 22:13:05 -0800
Message-ID: <4ED86C71.4060008@netflix.com>
To: Anders Rundgren <anders.rundgren@telia.com>
CC: <public-identity@w3.org>
Hi Anders,

On 12/1/2011 12:55 AM, Anders Rundgren wrote:
> 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.

It appears that I'm lacking some context. If you don't mind educating 
the less informed, can you let me know what you're referring to here?

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

We're ok with this. If we were to get simplistic about this (The devil 
is in the details, I know.) then what we're really looking for is 
something like this (please excuse Java-like syntax; I'm not a JS coder):

--- BEGIN EXAMPLE CODE ---
// get a unique ID for current domain
String id = getUniqueID();
// get a handle to our Netflix session key if such exists
KeyHandle kh = getKeyHandle("NetflixSession");
if(kh == null) {
     // we need to "register" to netflix.com

     // look for a pre-shared key
     kh = getKeyHandle("NetflixPreShared");
     if(kh == null) {
         // we're running on a generic browser, create a key
         kh = generateKey();
         if(kh == null) {
             error();
         }
         // we will register below using our generated key
     }
     // register to "netflix.com" using our key
     // register() returns a KeyHandle to our new session key
     KeyHandle session_kh = register(kh);
     if(session_kh == null) {
         error();
     }
     // if success, use the new session key instead
     // of pre-shared or generated key.
     kh = session_kh;
}
// create an arbitrary message
String msg = "Hello, Netflix!";
// create an HMAC to authenticate msg
String hmac = kh.hmac(msg);
// send authenticated msg to netflix.com
sendMsg(msg, hmac, "netflix.com");
--- END EXAMPLE CODE ---

Is the key naming shown above palatable? This would allow us to operate 
on a generic browser and on an embedded platform in almost the same way. 
The generic named "KeyHandle" (in reality, we might want to have a 
CipherContext for symmetric encryption keys, an HMACContext for HMAC 
keys, etc.) allows this to work in the above contrived example.

Mitch

>
>
> 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 Friday, 2 December 2011 06:13:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 2 December 2011 06:13:34 GMT