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

Hi Mitch,

On 2011-12-02 07:13, Mitch Zollinger wrote:
> 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?

http://lists.w3.org/Archives/Public/public-identity/2011Nov/0114.html
http://lists.w3.org/Archives/Public/public-identity/2011Nov/0060.html

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

This is an example of code that should work flawlessly in a domain-restricted
context but fail miserably outside of it (you cannot ask for keys from
untrusted JS to an open keystore without adding a selection GUI like in TLS).

The subject line is of course a little big orthogonal here since nothing
prevents a domain-constrained keystore to be cast in HW but I was really
thinking about the more conventional uses of crypto HW like PIV and eID.
And the Wallet...


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

Looks ok to me given that there is a domain-dimension involved as well.

Anders

> 
> 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 07:00:39 UTC