Re: The "korean bank" use-case

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.

> M.

Received on Monday, 28 November 2011 18:15:21 UTC