Keys to the Kingdom
Every step of the key management process has an element of risk. You have to balance security and usability, weighing risk against reward as you plan your implementation.

Generation. Keys must be generated in a secure manner so that an administrator generating them does not actually have access to them. Private keys need to be generated in a similar manner to passwords, where no one but the user knows them.

Assignment. The key must be given to the user in a secure manner, guaranteed not to disclose the key. This can be accomplished through the use of third-party software. Typically, the key pair would be generated by the user clicking a link; only the public key is sent to a central repository, and the private key is kept by the user.

Accountability. Everyone understands the importance of protecting Social Security numbers and signatures, but doesn't realize that a key has the same impact. Users must be held accountable fo...

Exchange. Public keys must be exchanged so people can send and receive encrypted data. A public key does not need to be secure, but you must guarantee that it really belongs to a particular user. The best practice for distributing keys is through the use of certificates. A corporation should have a single key signed by a global CA (certificate authority). They use that key to self-sign subordinate keys, which, in turn, sign user keys so they can be validated with minimal cost.

Storage and access. Keys must be stored on a drive in some manner that makes it difficult for anyone but the owner of the key to get access to it. Generally, this means the user needs a password or pass phrase to use the key, which is long and complex and never entered directly by the user. Instead, the key is stored in an encrypted virtual safe on the hard drive, and the user only has to remember the combination--the password.

< PREV PAGE   |   1  |   2  |   3  |   4  |   5  |   NEXT PAGE  >