On Fri, Sep 27, 2013 at 11:37 AM, Carl Wallace <[email protected]>wrote:
> There is no security advantage to having mail sent to me encrypted under a > different key per device. There is however an advantage to having mail > signed under a different key per device and not sharing those across > devices . > > > No security advantage, but a usability advantage. > I think it is better to work on making it easier and more secure to import the keys. Here is the scheme that I am currently coding for. Note that at present I am only considering how to configure to RECEIVE and decrypt the emails in existing clients. I know that much work is going to have to be done with those clients before it is practical to use them for signed mail or to send encrypted mail. But I don't need to be able to send encrypted mail on every single machine and this can be done with a local proxy in any case. But I absolutely MUST be able to read anywhere. Step 1: To generate my first key: I run the KeyMan tool as follows: keyman /generate [email protected] /service hallambaker.com /share 5 hallambaker.com is just the pki equivalent of a news server, it is a gateway to the trust infrastructure (whatever that turns out to be) not the infrastructure itself. I assume that there will be multiple trust models. In production mode, the omniconnect service to use and the necessary credentials will be defined as a Windows registry or other platform/user config file. I have included it here so that it is visible. [This is the line mode version of the tool but it is easy to write a UI version as the interaction is trivial.] What this does is to * Generate an RSA2408 keypair (the default alg) * Choose a random 256 bit password to encrypt it with AES256 in a PKCS #12 * Generate a self signed certificate for 10 year validity and a CSR * Submit the CSR, Self Signed cert and PKCS12 to the OmniRegistration service at hallambaker.com * Installs the private key on the machine and configures any email client on the machine to allow use of the key/self signed cert to decrypt messages. * Prints out the five key shares for the 256 bit password to the console in groups of five Base32 characters. [The arbitrary defaults can be over-ridden of course] The user is instructed to write down the five key shares, three of which can be used to reconstruct the key. These can be sent to a printer, but that leads to security issues with the printer having a cache and we probably don't want to add a printer to some builds such as a Raspberry Pi running a stripped / secured stack. The ordinary user would just choose the default and have one password to write down. At this point the email clients on that particular machine can decrypt email encrypted under the self-signed certificate. Now one twist that I have not looked into quite yet is whether this would also allow those email readers to decrypt messages to the same key but under a different certificate. I suspect not for the existing clients and protocols but we could make this possible in principle by adding an extension into any certificates generated by a CA to tell clients that the private key is to be found in the self signed cert container. Alternatively an IMAP proxy might rewrite the S/MIME messages for me. This would allow the next step to be eliminated. 1a) To enable use of a CA issued certificate on the machine keyman /register [email protected] /service hallambaker.com Note that there are no files involved. The tool is going to talk to the service and only the service. * Tool retrieves the issued cert(s) from the service and installs them for use transferring the private key obtained earlier. At this point the tool might ask the user for the key shares so that the ability of the user to decrypt their key can be verified before telling the service to mark it as 'live'. 2) To enable use of a CA issued certificate on a different device keyman /register [email protected] /service hallambaker.com [user types in their key shares] If the device is a completely new one it will configure the email service info as well as the private key. Considerations: This is only for encryption keys. There should be a separate signature key for every device. Private keys should never move off a device to which they have been installed. It might well be desirable to let a user generate keypairs on one particular device under controlled circumstances. For example, I might dedicate an SD card to containing a Raspberry Pi build for this exact purpose and only use it for this purpose, generating an encryption keypair and a set of signing keypairs for all my devices in one go, then erasing the contents at the end. While some folk might object to storing their encrypted private key in the cloud, I doubt that the risk is worth worrying about. If AES256 is broken then we are toasty toast and no need to worry about anything. The data is almost certainly going to have to sit on the endpoint machine in less than perfect security. Most users probably don't need to bother with keyshares. A single password will be enough for them. Or they might have a password for personal use and keyshares registered so that survivors can reconstruct the key if needed. Printing the keyshares out on paper is much simpler and more reliable than use of USB fobs or the like. A malicious actor could copy the data but I don't see that mattering in this particular application. The point is to convince the user that they are not going to loose their data due to a hardware failure under any circumstances. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
