One method used to distribute keys (any type of key) is to use a key server. You can set one up for corporate use or you can buy a PKI system from one of the many vendors. Basically, you’re dealing with a database with set fields to hold information about the keys and you use access lists to control who can get which keys. It sounds easy, but it can quickly become a quagmire, depending on how many keys you are storing and sharing and what the keys are used for. (See “Keys for Different Purposes,” above.)
One main drawback to key servers is that they can become a single point of failure. That is, if the server is attacked or an electronic part goes “zap,” no one can get any keys and the whole system falls apart. It’s also a beefy target for unscrupulous types who have one repository for all the keys. If you have all the keys, you quite likely can read just about anything you want. (Although the passphrases would have to be cracked, too.) That means they must be extremely robust servers (with the elusive 99.9 percent uptime) and extremely well protected with security mechanisms, too.
You can set up fail-over systems with redundant key servers, but they must monitor one another constantly for changes and complete updates as soon as possible. If the redundant key server is out of sync with the main key server, it can still work, but there will be some problems.
Keeping keys up to date
Imagine that your building is protected with just one door (improbably, but just go along with me for a minute). Let’s say that you have ten people who need to have copies of the keys so they can come into work after hours. You can expect that at least one person will lose a key. But what if that key was so important that you couldn’t chance a lost copy floating around. You’d have to change the lock, make new keys, and gather all the old keys from the ten people. A real pain, right? Well, imagine that at least one of those people loses their office key once a month. Now that’s a royal pain and it would get to be very expensive, too.
That can happen with encryption keys, too. Some keys are so important that they have a limited distribution but you can always count on the fact that at least one person is either going to lose the key or forget the passphrase to the key. To be really safe, you’d have to revoke the existing keys, generate new ones, distribute the new keys, and probably change some applications to accept the new keys, too. That’s one of the jobs that is expected of a key server
— to manage the keys.
On a normal day, even regular (not-as-sensitive) keys get lost or the passphrase forgotten. Therefore, the key server needs to have the information about the revoked key and the information about the new key — and the key server needs to get that information to all the users. How do you do that? If all the users’ desktop and laptop computers are constantly querying the key server for updates, the key server wouldn’t have much time to do anything else. Yes, this is a problem and it has no simple answer. It’s just something you have to decide how to handle yourselves.
In addition to lost keys, you’ll have keys that have expired and need to be re-instated, you’ll have new keys for new employees, you’ll have old keys for staff who have left the company, you’ll have keys for part-timers or contract personnel, and you’ll have keys for staff who have been promoted. Their key’s permissions need to be changed. So, you can see why key servers are a great idea in theory, but a lot of work in practice.
Just a note — PGP key servers, because they are open to the public, rely totally upon the owner of the key to update his information. That’s one reason you should contact the owner of a PGP key to make sure the one you have is current.
Policies for keys
Whether you are going to have a key server or not, you really owe it to yourself to come up with your policies (rules) for the use and maintenance of keys before you even set one up. You won’t think of everything ahead of time, but it sure saves doing everything by the seat of your pants as you build and implement a key server.
What am I talking about? I’m talking about things like:
This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks.
Who has access to the key server?
Who is in charge of keeping the server working?
How do you handle emergencies with the server?
Who on the staff can use keys to digitally sign data?
Who is allowed to use keys to encrypt data?
What data should be digitally signed and what data should be encrypted?
Who has the authority to issue keys?
What are the requirements to obtaining a key?
How do you handle key revocation and updating of desktops and laptops?
And so on, and so on, and so on. There are numerous sites on the Internet that can help you with these decisions.
After you make these decisions, you need to write them down to make them policy. A note of caution, however — make your policies realistic. If they are not realistic, they won’t do you any good. For example, you can’t say that the CEO is in charge of deciding who gets keys — that’s an administrative job, and I’m sure the CEO would get really sick of being interrupted every time someone needs a new key!
Key escrow and key recovery
These terms are often confused as meaning the same thing, but they’re not. Key escrow is the actual storing of the key and the passphrase somewhere, somehow so that it can be pulled out of storage and used when needed. Key recovery is the process of storing a key in broken pieces and having the ability to recombine the pieces when needed.
Key escrow is something the government has wanted to be able to handle themselves for many years now. The agencies want this ability so they can easily read encrypted messages of those they suspect are involved in some sort of illegal activity — like drug running, counterfeiting, terrorism, and so on. Civil libertarians have successfully defeated the government’s attempts to do this many times. It’s an invasion of privacy thing. And, we’d never know if and when the government agencies were abusing the power.
Key escrow for organizations is something you should consider, but the difficulty is how to implement it. I’ve heard of administrators putting each individual key on individual floppies and then putting each individual passphrase on individual floppies, too. Those floppies are then stored in a safe with limited access. At first it sounds reasonable. Then you start to think of all the times the administrator would need to access the safe and get a floppy when changes are made to a key or the person who owns the key leaves the company. What a chore! And how do you make sure that all the people who have access to the safe don’t go snooping themselves? You’d never know if a floppy had been copied.
There’s also the problem of erasing the key from a floppy. Forensically, you should never trust anything except a factory-fresh floppy disk. Even if you erase and reformat the disk a dozen times, someone who has the skill and the tools can still read the information on the disk. You’d have to literally shred all the old floppies to make sure the key didn’t fall into the wrong hands.
You certainly don’t want to escrow all the keys on a server. That would be like a diamond shop with no locks on the door. Believe me, if a hacker heard that you were storing all your keys and passphrases on one server (or even many), the hacker would find a way to get in and steal that data. It’s just too tempting to pass up.
The better method is key recovery. Key recovery is like splitting keys into pieces, which I mentioned earlier, but this time you use many servers instead of people to handle the pieces of the keys. And, yes, there are programs that can help you with this process.
So, you break the keys into a number of pieces and you store the pieces in random locations. Tied in with these pieces are security questions. When a key needs to be recovered, the owner has to answer a number of random security questions before the application will reconstitute the key. The best way to do it is to have something like seven security questions and the owner has to answer five of the seven questions correctly to be able to get the key put back together.
This sort of key recovery has a lot of appeal because it can be done without the involvement of one of the IT staff or the manager of the keys. I’ve heard rumors that a new version of the “enterprise” version of PGP is going to come with this feature built in. Sounds pretty cool to me.
Of course, there are security problems with key recovery as well, but there aren’t as many problems as there are with a key escrow system. Whichever you eventually use, remember that the servers need very limited access (both physical and logical) and there ought to be a number of security mechanisms in place.
This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks.