<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 29, 2014 at 5:34 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=trevp@trevp.net&cc=&bcc=&su=&body=','_blank');return false;">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Imagine a user has an initial device with a long-term key pair that is<br>
involved in decrypting messages.  The first question is how to make<br>
this "decryption-involved key", or at least its output, available to<br>
the user's other devices.</blockquote><div><br></div><div>If you'll indulge my crypto hardware fantasies for a moment... </div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>- 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</div><div>- 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'</div><div>- 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</div><div>- 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)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div></div>-- <br><div class="gmail_signature">Tony Arcieri<br></div>
</div></div>