[Cryptography] On the deployment of client-side certs

Ray Dillinger bear at sonic.net
Tue Nov 15 17:18:49 EST 2016

On 11/15/2016 01:13 AM, Natanael wrote:
> I keep seeing hardware tokens being NOT mentioned.
> Is it really that hard to convince people to carry a U2F / OpenPGP token
> with USB/NFC/BLE capabilities in their keychain? It shouldn't be.

This is actually a quite good idea.  The mental model of a keyed
lock, with a physical key, works reasonably well for at least some
plausible implementations of client-side authentication.

If you want your device to do secure transactions with the bank, you
have to 'unlock' the bank secure channel by sticking the bank key into
it.  If you want your device to do secure transactions with Amazon, you
have to 'unlock' the Amazon secure channel by sticking the Amazon key
into it. And so on.  The USB port is also the keyhole.

I think most people could compass the idea that you have a single device
(your e-keychain) which is all of these keys but only one of them at a
time, and that you have to turn a knob on it (or whatever) to make it
produce the "right" key. I think they could also handle 2FA that way;
the key opens the secure channel, then the bank, or amazon,
or whatever, asks for your password to make sure it's you using the key.

I think that amount of key management, with a physical device, is within
reach of most people.  Under the hood, the device contains a
set of certificates and can do cryptographic operations to prove
possession of each of them, negotiate session keys, etc.  But we want to
make sure it's "each" rather than "any."  When Alice has her 'bank key'
in the keyhole, we don't want Bob to be able to spoof a form and get her
to unlock a secure channel between Bob-impersonating-Alice and Amazon.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161115/3c500051/attachment.sig>

More information about the cryptography mailing list