Advocates of the model where software is automatically archived on receipt, either in cleartext or re-encrypted with a corporate key, need to be aware that there are problems with it: No notification to sender about the policy. Imagine encrypting this mail to your friend sue@microsoft.com: "Hey Sue - it's been a while. Is your boss still being such a wiener? That was a great imitation you did of the jerk at the party last month. He still doesn't know you're shopping your resume around, right? What a luser." You might have thought you had a certain level of privacy when you encrypted it to your friend's personal key, but you didn't. This is going to cause embarrassment and misunderstandings. People should know if their mail is going to be automatically saved in the clear to a company archive. The best way to make sure of that is to have the sender be the one to do it, or not. No way to prevent third-party access. With the corporate message recovery feature, the sender has the option of simply ignoring the recovery key and sending it encrypted just to the recipient. Some corporations won't let it through, others will. Some companies will want mail to be made recoverable by default, while still allowing an escape clause for personal mail and special purposes (like for "sensitive" mail which needs protection against subpoena and discovery). They can use the "optional" CMR mode. Again, senders are always notified as to which mode is being used by a given company, and senders can be confident that if they don't use the third-party key, no access will be possible. With automatic encryption and archival on receipt, all mail will be archived, and senders have no notice and no guarantee that stated policies will be followed. No escape via super-encryption. Even if the company is mandating a recovery key and filtering out messages which aren't encrypted to it, the sender still has the option to super-encrypt with the recipient key alone, before sending the message encrypted to the corporate recovery key. This ensures that only the recipient's personal key can read the message. With software which automatically saves the cleartext of the message, once the user reads the data it is available to the corporation via the snoopware. Facilitates GAK! Suppose this solution is adopted, and software is developed which automatically re-encrypts received email and sends it to a secure archive. It's robust and works with a wide variety of email packages. Now the government could simply mandate this to be used for all mail reading software. The secure archive would be a remote archive maintained by the FBI to protect public safety. All plaintext would be sent there, encrypted by the FBI key. The business software would already support this. This is GAKware! Unlike with a CMR system, the sender would have no way to prevent access. Can't handle forgotten passphrases. People forget passphrases all the time. With re-encryption on receipt, there is no way to recover gracefully from this error. All the incoming encrypted data is lost until you can notify everyone who has sent mail to resend it, and get your new key out to all of them. These may be purchase orders, sales leads and other important documents which represent lost business if they can't be recovered. This is going to invite people to use poor security practices like writing down passphrases or choosing ones which are easy to guess. Worse, it... Invites key escrow. In order to prevent this problem, employees may be forced to share their secret keys with corporate management. Software will be written to facilitate this process. Crypto companies are already doing this. Nortel Entrust allows key generation by management, where employees are given the keys and management keeps a copy. Shades of Clipper! This also fails the notification requirement. Don't believe me? Take a look at this description of the Nortel Entrust product:
Recovering Lost Keys
Many data security systems require that users have passwords to access their keys. However, with some information security systems, disaster strikes when users forget their passwords. When users of such systems forget their passwords, not only do they lose their keys -- they also lose all the information encrypted with those lost keys (forever). Entrust, however, provides an easy way to securely recover keys.
If users forget their Entrust passwords, they call their Entrust Administrator to request that their encryption key pairs be recovered. After setting up the users for key recovery using Entrust/Admin, the Entrust Administrator provides each recovered user with a new reference number and authorization code. Users then enter this information as part of the Recover User operation in Entrust/Client. This operation sets up a protected communication session between Entrust/Client and Entrust/Manager for encryption key pair recovery. When Entrust/Client recovers a user's encryption key pair, it automatically creates a new signing key pair.
Updating Keys
While users can recover their key pairs if they forget their passwords, there are some situations in which users may want to get new key pairs altogether. For instance, the security policy of an organization may dictate that users get new key pairs every two years. In this case, a Security Officer uses Entrust/Officer to specify that key update occurs every 24 months. The term key update refers to the automatic creation of new encryption key pairs and signing key pairs at specified times. Any Security Officer can specify the frequency of key updates.
Every time users log on to Entrust, the software checks to see if key update is required. If this is the case, Entrust/Client makes a request to Entrust/Manager for a new encryption key pair. Once the new encryption key pair is generated, Entrust/Manager delivers the new key pair in a protected communications session. Delivery of the new encryption key pair is completely transparent to the user.
No system is ideal. Before pushing this re-encryption model as a panacea, think about the implications. No system which provides automatic access to business data is going to be privacy friendly. Any such system can be perverted into supporting GAK. Load it up with all the disclaimers you like, but if you advocate software which contains key escrow and which automatically provides cleartext to third parties, you are not advocating software which protects privacy. Be prepared to be called an advocate of GAK next time you push for software which automatically archives cleartext, because if it can save it for business, it can save it for government.