3 ms·

(1) Dont use unique keys per service, but per service per device you use. Private keys should never be transmitted. They should contain some marker that raises

(1) Dont use unique keys per service, but per service per device you use. Private keys should never be transmitted. They should contain some marker that raises a big warning somewhere in the OS I/O stack if going through. (2) See (1). Don't. Instead, register any new device with a new keypair. Have the user confirm the registration of a new device, using a trusted communication channel (low security requirements: e-mail confirmation, medium: SMS or RSA token handed out to users, high: token coupled with bio-information such as fingerprint scan). (3) See (1) and (2). (4) Well, let them expire, prompt the user to reregister their device according to (2) 1-3 months in advance with increasing frequency. (5) Store the key in an OS controlled keychain that gets locked on device lock. Avoid OSes such as Windows, that still don't offer this feature.

hnha 13y ago
1) how do I read my mail on both my desktop and phone then?
- m_mueller 13y ago
  Simple, your mailserver encrypts traffic using the public key of the respective device you use to access your mail. To keep things simple, the client could simply send its public key to the server together with the request - if it matches a registered public key for the requested resource, it will be used for encryption.
malandrew 13y ago
If I have specific keys per service device pairs, how do I go about retiring the keys from a device that has been compromised? What if a service doesn't allow you to register multiple keys per account? If I'm using an OS controlled keychain, what is the best way to handle it's contents in a OS agnostic way that is easy to back up just like dotfiles work? Are there any resources that go into how to handle keys safely in a lot more specific detail?
- m_mueller 13y ago
  The problem about compromised devices is first to recognize it, right? There is basically no way to know for the server, other than a lock request sent by a user using a different, already authenticated device (if that's not available, the user first needs to authenticate a device using the e-mail/sms/rsa token process mentioned above). When such a request is sent, the public key of the compromised device stored on the server gets deauthorized. In fact, a per-device public keys makes the whole process much easier, obviously, since specific devices can be locked out, rather than locking a whole user account. About OS keychains: I'd imagine there are some multi-platform wrapper libraries to deal with this, but I've never specifically looked for such a thing, sorry. If there isn't already such a library in place I'll probably write one in javascript in 2014, since we're going to need it for the PaaS we're currently developing.

hnha 13y ago

1) how do I read my mail on both my desktop and phone then?

m_mueller 13y ago
Simple, your mailserver encrypts traffic using the public key of the respective device you use to access your mail. To keep things simple, the client could simply send its public key to the server together with the request - if it matches a registered public key for the requested resource, it will be used for encryption.

malandrew 13y ago

If I have specific keys per service device pairs, how do I go about retiring the keys from a device that has been compromised? What if a service doesn't allow you to register multiple keys per account? If I'm using an OS controlled keychain, what is the best way to handle it's contents in a OS agnostic way that is easy to back up just like dotfiles work? Are there any resources that go into how to handle keys safely in a lot more specific detail?

m_mueller 13y ago
The problem about compromised devices is first to recognize it, right? There is basically no way to know for the server, other than a lock request sent by a user using a different, already authenticated device (if that's not available, the user first needs to authenticate a device using the e-mail/sms/rsa token process mentioned above). When such a request is sent, the public key of the compromised device stored on the server gets deauthorized. In fact, a per-device public keys makes the whole process much easier, obviously, since specific devices can be locked out, rather than locking a whole user account. About OS keychains: I'd imagine there are some multi-platform wrapper libraries to deal with this, but I've never specifically looked for such a thing, sorry. If there isn't already such a library in place I'll probably write one in javascript in 2014, since we're going to need it for the PaaS we're currently developing.