I'd like to add a 5th option to the list. Sorry for top-posting, I'm using a different device. ;-)
* Don't encrypt or sign the messages. Encrypt and authenticate the links between devices. * A user enrols a new device by pairing it with an existing device over a local channel. * The existing device introduces the new device to the user's other devices (if any) and the user's contacts' devices. This involves brokering a key exchange between each pair of devices to set up an encrypted and authenticated link. * The user's devices sync messages among themselves in a p2p fashion, so a message written or received on any device propagates to the others. * Any of the user's devices can revoke another device's access by propagating a special revocation message. Syncing with the revoked device is suspended until it's paired over a local channel again. Cheers, Michael Trevor Perrin <[email protected]> wrote: >On Sat, Dec 27, 2014 at 7:23 PM, David Leon Gil <[email protected]> wrote: >> >> So, we all have multiple devices. And any messaging design >> should work as seamlessly as possible (given the particular >> design's security goals) for this "multi-device" case. > >Hi David, > >Good topic, I agree on some points and disagree on others. My analysis: > >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. > >There's some nuance to the idea of a "decryption-involved" long-term key, e.g. > > * If you're using a PGP signing key to sign short-lived subkeys I'd >consider the signing key "decryption-involved", since new devices will >need to frequently either sign device-specific subkeys or receive >shared subkeys. > > * If you're using a PGP signing key to *infrequently* sign long-lived >subkeys, then the subkey is the "decryption involved" key that needs >to be available to other devices. > >Anyways, short-lived or one-time subkeys / prekeys are a good idea for >forward secrecy. However, I don't think they affect the rest of this >analysis, so I'll ignore them and focus on the decryption-involved key >pair. > >Here's a few possibilities for dealing with it: > >(1) The initial device serves as a "decryption gateway" for other >devices. For example, users might install a home server to handle >decryption, and configure their devices to access messages through it. > >(2) All devices have device-specific decryption-involved keys, and >cross-sign each other's keys. > >(3) All devices have device-specific decryption-involved keys, and a >master device uses a signing key to authorize subordinate devices. > >(4) The initial device copies its decryption-involved key pair to >other devices, which become peers. > >Analysis: > >I think (1) might have some uses, but isn't a "consumer-grade" user experience. > >(2) has the potential benefit that old devices could be revoked and >new devices could be added to the cross-signed set. However, this >adds a level of complexity that seems impractical: > * The user ceases to have a single public-key and fingerprint, and >instead has an evolving "cloud" of cross-signed keys. It's not clear >how you would apply public-key verification like TOFU or >fingerprint-validation in this case. > * Adding a new device requires acquiring a cross-signature from all >existing devices, which is awkward and has to be managed carefully so >users can't be tricked into signing wrong keys. > * Revoking or expiring old keys has less value than one might think. >Revocation data might not arrive, and expiration depends on time sync >which is a dangerous assumption for reliability and security reasons. > >The UX and security considerations for signing a key (3) and >transferring a private key (4) are similar: in either case, the >receiving device would provide and authenticate a public key (e.g. >over a "local channel"), and the sending device would either sign it >(3) or encrypt the decryption-involved private key to it (4). > >(4) is simpler and more efficient, since (3) involves transmitting and >verifying signatures and potentially chains of signatures (if the >initial device authorizes one device, which authorizes another, etc). >(4) also doesn't have the master / subordinate distinction, which >should make it easier for users to understand and work with. > >Signatures give you the possibility of binding subordinate devices to >a limited set of privileges, but in the text / email scenario I have >trouble seeing uses for that complexity. So (4) seems preferable >here. > >You criticized (4) on a few grounds I don't agree with: > > * The Whiteout implementation uses a QR code to display a >symmetric-key instead of a public-key. I agree that seems suboptimal, >but it's not a general problem. > > * You argue that "Anyone who obtains the private key from any device >can impersonate the user." That's true in any system, multidevice or >not. > > * You argue "If messages aren't signed, [someone who compromises the >private key] can (usually) carry out KCI attacks against the account". >But it's easy to use device-specific key pairs for authenticating the >remote party, so that compromise of one device doesn't enable >key-compromise impersonation (KCI) against other devices. > >--- > >A second question is how to handle the long-term key pairs used for >message authentication. This question is relevant whether >authentication is done with signatures (e.g. PGP) or key agreement >(e.g. TextSecure). > >I'd suggest handling the authentication-involved keypair the same as >the decryption-involved key pair. In the simplest case, use the same >"identity" key pair for authentication and decryption, and use (4) to >share that key pair between devices (TextSecure will do this [1]). > >You mentioned sharing the decryption-involved key per (4), but then >using cross-signed key pairs for authentication. You suggest the >benefit that "Key compromise can be attributed to a device", but I'm >skeptical that small benefit justifies dragging in the complexity from >(2). > >Trevor > >[1] https://moderncrypto.org/mail-archive/messaging/2014/001022.html >_______________________________________________ >Messaging mailing list >[email protected] >https://moderncrypto.org/mailman/listinfo/messaging _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
