On Wed, May 07, 1997 at 09:56:21PM -0700, Lucky Green wrote:
At 11:47 PM 5/7/97 -0400, Carl Ellison wrote:
I was saying that if Sam needs to read my encrypted file/mail, then I should list Sam as a crypto-recipient. If Acme,Inc. needs to read my encrypted file/mail, then I should list Acme,Inc. as a crypto-recipient.
There's no safe of keys. It's even simpler to explain to an executive.
Several people on this list asked me to elaborate on my claim that KR is not required. I doubt that I could put it more succinctly than Carl has in his post.
Unfortunately, it doesn't solve the problem at all. In fact it doesn't even address the problem. So much so that reading these replies makes me think that I am looking at different problem than you. So perhaps backing up to discuss the problem a bit would be helpful. I hope you will forgive me if this is old ground. The problem is key management for an organization. The keys are used to protect and authenticate data owned, not by any individual, but by an organization. Keys are generated for the organization's purposes, not the purposes of any individual. Furthermore, the individual privacy of an individual who works for an organization is not a necessary priority for the organization. Organizations are composed of many individuals, some of which may not share the goals of the organization, or who may indeed be inimical to the organization. And the members of an organization may vary widely in competence, personal responsibility, and so on. Thus, the members of an organization cannot be trusted to do the "right thing". [I am using "organization" in a loose sense, so that we can consider a business an organization, and an employee as a member of that organization.] In fact, in most cases, only a small fraction of the members of an organization care more about the welfare of the organization than about their personal welfare. So people will almost always be more concerned about their own personal data security than they will for that of an organization. This, coupled with difficulties of coordination and control, and the above conditions, means that in a global sense information security for an organization will always be difficult, regardless of the security of the crypto they use. For a moment consider the analogy with physical keys. Consider the key management problem of a moderate sized corporation that occupies a large office building. There are office keys, storeroom keys, supply room keys, conference room keys, bathroom keys, keys to filing cabinets -- there are *lots* of keys, lots of different delegations of authority involved. In many cases there is a "key czar", a "building coordinator" that hands out keys, and gets them back when someone changes offices or jobs. It *has* to be this way -- you can't rekey the entire building when a janitor quites. So, occasionally it is necessary to rekey a lock, but typically keys are just reused. Many office keys are designed to be difficult to casually duplicate, for this reason. Of course any key *can* be duplicated, but that's not really that important -- the building is full of employees during the day, and the night watchman checks each person that enters after normal hours. All these physical keys all fit locks that can be broken quite easily -- there is essentially *no* possibility of something valuable being lost behind a lock that cannot be broken. This is vastly different from cryptographic keys -- for all systems of interest, encryption represents locks that cannot be broken. Data behind a lost cryptographic key is gone forever. You can't call a locksmith or a safe cracker. It's really just gone. 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? 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? Contrast that with a key-safe model, where a copy of every encryption key is kept in a secure database. The encryption client software only talks to the key-safe when a new key is generated, over a cryptographically secure channel, of course. There is no policy the client has to know. The user encrypts freely without concern about who else should get copies. The organization knows that there is very little chance of data loss because of lost keys, and can use any policy it chooses to recover keys, from the company president's ad hoc whim to a carefully specified organization al security policy. 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 -- 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