[messaging] Multiple devices and key synchronization: some thoughts

[Tony Arcieri]

On Mon, Dec 29, 2014 at 5:34 PM, Trevor Perrin <trevp at trevp.net> wrote:

> Imagine a user has an initial device with a long-term key pair that is
> involved in decrypting messages.  The first question is how to make
> this "decryption-involved key", or at least its output, available to
> the user's other devices.


If you'll indulge my crypto hardware fantasies for a moment...

I kind of like the previously described idea of having a user register many
public keys in a directory, one for each device they currently have
enrolled, signed by a master key, and having the sender encrypt the
symmetric key of a message to all of a user's currently enrolled public
keys. This gets rid of the idea of having a single encryption key for a
user, and replaces it with an address people can look up in a directory, as
well as a set of keys that a user can mentally model as physical objects in
the real world. Lose one? Just delete it from the publicly advertised
directory.

However, if we did want to go with having some sort of long-lived keypair
for the user to encrypt messages, and wanted a Consumer Grade(TM) user
experience, this is how I'd go about moving it around:

- The original key is on a "Yubikey"-like device. Imagine some small
hardware token that can be kept on a keyring which contains private keys
and is allegedly sidechannel resistant. We'll call this key A
- We purchase an identical version of the same device, and want to copy the
long-lived keypair onto it. Let's call this key A'
- The user wants to move the long-lived keypair from A -> A'. They do this
by authenticating to the advice (via e.g. a PIN) and putting it into a
pairing mode where it can pair with other hardware tokens over NFC
- The user taps key A' to A. This authenticates A' to A over NFC, and A can
now deliver its keypair to A' in some manner (e.g. over NFC, obtaining a
device-specific public key from A' that it can encrypt the user keypair to)

If you buy into the whole idea of modeling cryptographic keys as hardware
devices, the important point here is that we're able to move a
cryptographic key from device-to-device without any devices but the two
involved in the exchange ever seeing the raw unencrypted keying material.
This is hard to do today with most crypto hardware tokens, e.g. GPG keys
stored on Yubikeys.

Typically this sort of "cloning" is actively avoided by modern crypto
hardware devices though. I think it might make more sense to have a
separate key per devices so if devices are lost we can revoke keys
accordingly.

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141229/f063dc18/attachment.html>