As I’ve mentioned, the major part of PKI is the infrastructure itself. The infrastructure is built to create, organize, store, distribute, and maintain Public Keys — which are the PK in PKI. In this case you’re dealing with Digital Certificates which are just another name — or another form — of public keys and private keys. But, instead of a person creating those keys himself (as you do with PGP), a person goes to a Certificate Authority (or CA) to have the keys created.
The CA is a computer system that requires human interaction to issue digital certificates. Basically, you request a digital certificate from your computer which interacts with the CA computer. The CA “operator” then needs to see some sort of personal identification (such as a drivers license) before the operator tells the CA computer that it’s okay to issue you a certificate. The certificate is then sent from the CA computer to your computer.
Before I get too deep into the explanations here, let me outline the infrastructure for you. This infrastructure consists of special servers and software — some of it you own and operate and others are outside your domain. Without further ado, here’s what you are dealing with:
Certificate Authority (CA) — Usually an outside entity such as Verisign, CyberTrust, or RSA. These are sometimes referred to as Trusted Authorities because, for PKI to work, you have to be able to place your trust in an outside third party to issue Digital Certificates.
Digital Certificates — Essentially two files: private key and the public key. These are originally issued by the CA and, if you need to verify a Digital Certificate, that is who you go to for verification. Digital Certificates are usually kept on your computer and may also kept on key servers within an
organization.
Desktop computers and servers — Frequently need to have a special application or PKI “client” for the user to be able to encrypt and decrypt data.
LDAP or X.500 Directories — Databases that collect and distribute keys internally. Often you’ll have one directory for internal use and another for remote users or outside business partners.
Registration Authority (RA) — Internal version of a CA. If a large organization has many offices and/or divisions, they will often let the RA handle requests for Digital Certificates, verify identities, and then forward that information to the CA to actually issue the Digital Certificates.
That, in a nutshell, is a PKI system. As you can surmise, it takes a lot of coordination to plan a PKI solution, obtain the necessary hardware and software, install the system network-wide, and start using it. Of course you can buy a total solution from a vendor that includes the servers, software, instructions, and support. If you have a small to
medium-size business, this might be the more cost-effective way to go. It all depends on what you need the PKI for and whether or not you expect your needs to grow.
So many companies and top executives have jumped on the PKI bandwagon without a good understanding of what, exactly, they will be using it for. They’ve heard that it’s the latest thing and it will solve lots of problems, but they haven’t stopped to identify their problems or what they hope PKI will solve. Make that a priority at your company — plan before you leap!
PKI solutions vary from vendor to vendor on how they are set-up and operated. A main part of this involves the encryption technology used and the different forms of digital certificates. Because of this, not all PKI systems will understand one another. For example, if your company wants to be able to communicate via PKI with another company or a client, you need to make sure that your system and theirs will be compatible. If you plan to use the PKI system internally only, then that is not such a major concern.
Certificate Authorities (CAs)
This is the Grand Poobah of PKIs. Without a CA you can’t issue Digital Certificates, which contain the public/private encryption keys that a person (or a company) uses to encrypt and decrypt data. The security of a Digital Certificate is tied to the CA; if you don’t know or don’t trust the CA, you probably shouldn’t trust Digital Certificates issued by that This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks.
CA.
Digital Certificates are available in different levels of trust; depending upon the amount of identity verification done by the Certificate Authority. The first level of trust is normally used to identify an individual rather than a company. To positively identify an individual, the CA usually asks for a driver’s license and/or a notarized letter as proof of identity.
Another, higher, level of trust available in a Digital Certificate involves a background and credit check and lots of other hoops to jump through. Because these certificates are usually reserved for persons or e-commerce sites responsible for a high level of trust, they can also be based on biometrics such as a fingerprint or iris scan.
If you have a small office or Web site, you can get away with using a third-party CA, such as the ones I mention. Be careful who you choose to be your CA, though. The CA should have been in business for a reasonable amount of time, have a solid reputation, and likely to be recognized by others as a trusted party. If your CA is “Bob’s Discount Certificate Authority” you may find that other individuals or companies won’t want to trust your Digital Certificate because the CA that issued it is either unknown (and thus, “untrusted”) or because the CA has a dubious reputation.
Large companies who will only be using digital certificates internally often set themselves up as the CA because they trust themselves and they know who to extend that trust to. An internal CA won’t hold the same level of trust with outside users, but because it’s intended to be used only internally (within the organization, its partners, and employees), trust doesn’t usually become an issue.
Digital Certificates
Digital Certificates are used to verify the identity of a person or business via the CA. For a person, a Digital Certificate can also be used to identify access rights and responsibility roles. Some Digital Certificates are limited to use only for encrypting (and decrypting) e-mail while others may allow access to sensitive files. They can also be issued to specific computers to identify their roles, such as desktops, laptops, firewalls, and routers. When the Digital Certificate is issued, its uses and limitations are spelled out within the certificate itself. Figure 5-1 is an example of the area within a Digital Certificate that spells out what it can be used for.
Figure 5-1: The purposes for which this digital certificate can be used.
Digital Certificates are files stored on your computer that contain the public keys that an individual uses to encrypt and decrypt data. You need to have PKI-aware or PKI-compliant software programs to be able to use your Digital
Certificates. One software program almost everyone has that is able to use and recognize Digital Certificates is your Web browser. In the Internet options or preferences area of your browser, you can find a listing of all the certificates that are stored in your browser. Figure 5-2 shows you where the certificates are stored in the Mozilla Web browser.
Figure 5-2: The Digital Certificate options in the Mozilla Web browser are found in the Preferences menu.
In fact, that’s one of the main usages of PKI today: authenticate users and servers over the Web for e-commerce transactions. Digital Certificates are also used to encrypt email and data and ensure that remote users (home workers, road warriors, partners, clients, customers, etc.) have a secure connection with which to communicate. PKI can’t do all that alone, so many companies have set up VPNs for the secure, encrypted connections, and PKI for the
authentication and data encryption. That’s not a bad combination and it normally works very well.
One of the biggest problems with Digital Certificates is making sure you have the right one. Is Betty Smith the same person who goes by Liz Smith at the office? Is she the same person who has a Digital Certificate under the name Elizabeth Smith on her home computer and uses the certificate to send encrypted email? When you look for the certificate for Bob Jones, you see that there are no less than 20 Bob Joneses and all of them have different e-mail addresses. Which one is your Bob Jones using? Are some of these certificates old ones that your Bob Jones forgot to revoke? It’s important that you get the correct Digital Certificate because you are placing trust in these people based on their certificates.
PGP key certificates come with what is referred to as a fingerprint. This fingerprint is a series of alpha-numeric characters (or occasionally various words) which are unique to each public key attached to the certificate. Figure 5-3 shows my PGP key with the fingerprint clearly marked in a separate area towards the bottom of the dialog box. If someone wants to make sure that they have the right key for me, they can call me or send an email and ask me to verify my fingerprint.
This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks.
Figure 5-3: The PGP properties dialog box which shows the fingerprint associated with the public key.
Desktops, laptops, and servers
Now that we’ve opened the Pandora’s Box of who a Digital Certificate belongs to, we can look at the inanimate objects that are issued certificates: computers. You have to place your trust in various computers from time to time, so Digital Certificates can help to not only identify computers, but also to give you information on the level of trust the certificate gives them. Web browsers often use the certificates stored in the browser program to verify Web servers used in e-commerce transactions. The reasoning behind this is that you want to be sure that you are connecting to the real online shop and not an imitator.
Firewalls, routers, and servers can also have Digital Certificates to help identify them and identify their roles and their security policies. For example, a firewall can exchange certificates with other companies’ firewalls and servers for secure communications and to establish rules for their connection.
Although the Digital Certificates used to identify servers and other computers are really no different than the ones used to identify individuals, you still need to make sure that the certificate is the correct one. Our Web browsers
automatically check the properties of the certificates and tell us when there is a problem by popping up a dialog box that tells you that something is not right. Many people just ignore these dialog boxes and click “OK” but they really should check the certificate properties and find out why the certificate isn’t working. For this you will need to call the owner of the certificate and ask them what is wrong (you will probably be referred to the technical assistance personnel). Figure 5-4 shows a certificate that cannot be verified.
Figure 5-4: Checking the properties of an invalid digital certificate.
How various software programs deal with certificates varies quite a bit from program to program. For example, MS Outlook and Qualcomm Eudora are both email applications. You would think that they would both handle Digital Certificates the same way, but they don’t. This is due to the way the program was written and is not the fault of the certificates themselves. All certificates are basically the same and contain the same types of information. However it is the software programmers who make the difference — not every programmer writes a program to deal with Digital Certificates in the same manner. That’s where incompatibilities happen.
Key servers
Because CA servers are used to issue Digital Certificates and to verify their authenticity, there must be some other method used to store and distribute keys. And there is — they are called key servers. These servers become the equivalent of air traffic controllers because they make sure the right keys are in the right areas and they keep track of what all the keys are doing. As air traffic controllers identify planes and then make sure all the airplanes are in the right place at the right time, key servers do almost the same thing with keys. In order to do this appropriately and efficiently, key servers need to contain the correct information about all the keys that are floating around in cyberspace.
Key servers are the one of the most problematic portions of a PKI system. They hold all the Digital Certificates’ public keys and distribute them to computers that request them. The servers contain information on who can ask for which keys, which keys are allowed to do what, and, just as importantly, which keys are invalid and should no longer be used. The hard part is making sure that all the key servers have this information. Keeping the key servers up to date is a big chore, especially when this task is being handled manually by the support staff.
If a person in a company changes jobs, it’s very likely that his responsibilities will also change. Those changes need to be made to his Digital Certificate and his key. If a person leaves a company, then his or her Digital Certificate and key need to be revoked. Sub-contractors who work onsite need to have certificates and keys that will only work for a limited period of time and then expire automatically. The possible scenarios for changes in keys is endless but all these changes need to be made so the PKI system will work appropriately. Not only do the changes need to be made on the key servers, but the desktop computers and laptops need to query the key servers on a regular basis and ask for updates.
This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks.
Registration Authorities (RAs)
Registration Authorities (RAs) are strange birds in the PKI system. They are roughly equivalent to a CA, but are one level down in a trust hierarchy. In some governmental PKI systems one office is deemed the CA and agencies and subordinate offices have their own RAs. The RAs screen the applications for Digital Certificates, do the background checks or identification checks, and then submit the paperwork to the CA to issue the Digital Certificate. The reasoning behind the use of RAs is to help reduce the workload on CAs.
In some situations, the RAs can issue sort of a temporary Digital Certificate so the applicant can begin using his or her Digital Certificate immediately. Normally these “temporary” Digital Certificates are limited as to what they can be used for. These Digital Certificates are not fully trusted until they are eventually signed and approved by the CA.
I’ve been to multinational companies that set up all of their overseas offices with RAs and the CAs are located in the U.S. Once a month or so, all of the overseas offices forward the certificates issued by the RAs so that the CAs can review them, sign them, and send them back. Only certificates that have been digitally signed by CAs are highly trusted.