I addressed many of your issues in another post, so I will be relatively brief... On Sun, May 11, 1997 at 10:24:46AM +0200, Alan Barrett wrote: [...]
There are many similarities between your idea of a "key safe" for CAK (corporate access to keys), and the idea espoused by Carl and others of encrypting everything to a corporate key as well as to the other recipients.
If the corporation expects to be successful at forcing it's staff to run special software that talks to the CAK key safe, then the corporation should also expect to be successful at forcing its staff to run special software that adds the special coprorate key as a recipient of all encrypted messages.
True.
If the corporation expects to be successful at keeping the keys to the CAK key safe secure, while still allowing an appropriate coalition of high level managers to get access to the contents of the key safe, then the corporation should also expect to be successful at keeping the private part of the corporate key secure, while still allowing an appropriate coalition of high level managers to use the special corporate private key to decrypt messages.
If the coproration trusts those with access to the CAK key safe not to abuse their access, then the corporation should also trust those with access to the special corporate key not to abuse it.
Not true. The activities are quite different in detail. In the multiple recipients (MR) case the coalition keymeisters get together to decrypt a single document; in the key safe (KS) case the keymeisters get together to decrypt a key, which can then be used to decrypt many documents. In the multiple recipient case, therefore, the master key is potentially used quite frequently, and hence much more exposed. There are many other differences: I won't try to go into detail here. The frequent use of the master key is a major problem, because in the MR case, when a master key is compromised every document in the company is exposed; whereas in the KS case, given appropriate security around the keysafe, it is not anywhere as much of a problem.
With this background, perhaps now you can see why I say that Carl's solution doesn't even address the problem. The problem is management of complexity. Carl says "encrypt to Acme Corp". Who in Acme Corp? What part of the organization that is Acme Corp is authorized to know this particular bit of information?
Whatever the answer to the latter question is, it's the same in the CAK case as it is in the "encrypt to a special coprorate key" case.
Not if the encryption client encrypts to different company recipients depending on a policy (which one might want if one tries to limit the compromised master key problem described above.) Then the policy, contrary to what you state below, must be reflected in the client.
Because some of the employees are idiots you want this built automatically into the application they are using for encryption/email/whatever. How does this software know what policy is appropriate for which employee? How is that policy distributed? What is the interface that allows a policy to be defined? How do you protect the policy definition from subversion?
The same problems arise in the CAK case. And the same solution: you make the user's software do the same thing every time, and implement the policy elsewhere.
Sigh. The situations are really quite different. In the KS case the policy never impacts the software; in the MR case I don't think you can avoid it.
Access to the key-safe is critical, of course, but it can be made very secure -- a special-purpose piece of hardware that requires passwords from n out of m key czars before access is granted, for example. Or the contents of the key safe can be encrypted via keys escrowed through a secret sharing mechanism
The same problems and solutions apply in both the CAK case and in the "corporate key as extra crypto recipient" case.
Not at all. The corporate master key is used to decrypt documents in the MR case; in the KS case the master key is used to get to the key database. Two totally different functions, two totally different security paradigms. The old saw -- you can either hide your eggs all over the case, and hope not too many of them get found, or you can put them all in one basket and guard the basket.
Now, having spent some time attempting to show that the two cases are almost identical in many respects, let me point out a few ways in which I think encrypting to a special corporate key is better than CAK.
- With CAK, the key safe contains at least a copy of every key used by every staff member. All that needs to be kept secure. This storage problem does not arise in the non-CAK case.
But a relatively straightforward storage problem, really.
- With CAK, every time a user creates a new key, the user's software needs to talk to teh key safe. This needs a secure channel, which raises further authentication problems (how does the user know that he's not talking to a fake key safe). These don't arise in the non-CAK case.
Not so. You have to exactly the same issue -- how does the user find out the master key to encrypt to?
- Once a CAK infrastructure is in place, it is likely to be easier for a government to impose GAK. It's better not to set up the CAK infrastructure in the first place.
To be fair, similar arguments apply to the "add an extra crypto recipient" case: just add two extra crypto recipients (corporate key and big-brother key). But I think that the general public is more likely to understand what the government wants and to reject the idea in this case than in the GAK case.
Arguable. Guv won't say "everybody has encrypt every file to the government key". Instead they will insist that the corporate master key be escrowed. Any master key is an easy target. And they will have very good excuses for it -- corporations are public entities, tax records, etc, so I don't think the public will get worked up about it. Corporations won't, either. Note that the keysafe model doesn't really need a master key -- it will work with just good physical security. In that case the Gov would just issue a subpoena, I guess. -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html