- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Mon, 28 Nov 2011 19:14:31 +0100
- 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 UTC