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

Re: The "korean bank" use-case

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Mon, 28 Nov 2011 19:14:31 +0100
Message-ID: <4ED3CF87.9030609@telia.com>
To: Mo McRoberts <Mo.McRoberts@bbc.co.uk>
CC: "Richard L. Barnes" <rbarnes@bbn.com>, channy@gmail.com, "public-identity@w3.org" <public-identity@w3.org>
On 2011-11-28 15:45, Mo McRoberts wrote:
> 
> On 28 Nov 2011, at 14:23, Richard L. Barnes wrote:
> 
>>>> AFAICT, this is essentially an improved version of Mozilla's current
>>>> JS crypto.  That's fine but IMO it doesn't support security HW
>>>> in a way that makes sense to a bank since there is no way you can
>>>> assure that keys are stored in HW or SW.
>>>
>>> How can you •assure• that in the first place? Surely you’re always
> just taking the interface’s word for it, even if it claims to provide such guarantees?
>>
>> Presumably, this is assured by the fact that the public key is accepted by the remote side? 
> If the private key is only held in an HSM / smart card, then any crypto operations with that
> private key are known to be performed within that HSM (assuming that you trust the HSM).
> 
> Right, either
> 
> a) the private key is generated on the HSM before it's issued to the end-user, and you
> maintain a copy of the public key; in which case you know — because the keys
> match — that it's stored in HW, so don’t need an API to tell you that; or

Yes, that is the static one-issuer approach.

> 
> b) the private key is generated on the HSM by the end user and you need an
> API to attest to that fact, but it could obviously lie.
> 
> Now, there might — presumably — be some variation on the theme where the HSM contains
> a private key whose public key is known to the relaying party, and *that* key is used
> to sign the newly-generated keys, allowing positive confirmation that the key was
> indeed generated on the HSM (because it won't sign keys which haven't been) — but
> I honestly don't know if any HSMs do this or not?

Here comes the surprising part: This is essentially what the $2 Google Wallet
chip does, but your $20 000 HSM can't.

Well, to be entirely correct the built-in key is used for creating sessions
which can be used to import and export data in a fully E2ES (End To End Security)
fashion through derived encryption keys, sequence counters and MACs.
The session key "attests" created key-pairs as well.

Since Google wallet is already rolled out I feel it would be a waste of
time creating a system that doesn't build on similar concepts.  This
is also the way you deploy PIN-codes; it is just another object in
such a session.


Anders
> 
> M.
> 
Received on Monday, 28 November 2011 18:15:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 28 November 2011 18:15:23 GMT