[Back| Home| Programs| Documentation| Internet| People]


Corporate PKI



A corporation or a bank would like to provide secure communications between the client and server. The corporation or bank would also need a way to verify an individual's identity. Another feature that corporation would like is for users to log on to the system without the use of a the traditional password and username. And finally a corporation would like to give individuals access to only the specific documents and information that they are allowed to access. A necessity would be to encrypt all transactions made. Banks have the same needs as a corporation except that a bank would like to authenticate their customers and allow clients to access only their account information. A corporate PKI is the solution that a corporation and a bank could use since banks and corporations are structured and know who all the users are. As the use of public key grows more corporations and banks will be using PKI. Our federal government is currently in the process of creating a DoD PKI in the corporate manner that will be described here. To find out more about the US government PKI look here.

The first step that a corporation will take is to become its own CA. By being its own CA the corporation will have full control of its PKI and save money. Since the certificates will only be issued to individuals in the corporation only the individuals associated with the organization need to trust that CA as a root CA. Once the CA is setup and the CA is trusted within the corporation, the CA can begin to issue certificates to individuals that require them. At this point individuals will have a certificate and a public and private key pair.

Finding a Public Key

Now that certificates have been issued the CA has database of all the certificates that it has issued. Attached to each certificate, the owners public key. All this information is held in the form of a certificate. The CA will place all the certificates it has issued in a special database known as a LDAP (Lightweight Directory Access Protocol) directory. An LDAP directory is unique in that it was designed to hold certificates and allow for very fast access time of certificates. When an individual needs a public key that individual only has to check the LDAP directory to access the other persons certificate with the public key included.

Individuals in a corporation would like to access a certificate and/or public key for three reasons. First, if one individual wants to send an encrypted message to another individual the sender must access the recipients public key and encrypt the message with the recipients public key. Secondly, when an individual receives a digital signature, created with the senders private key, the recipient needs to verify the signature by accessing the senders public key and decrypting the message. If you forgot how digital signatures work function, reread this. And finally, one can verify a certificates validity by comparing it to the certificate in the LDAP directory. This eliminates any need to check digital signatures because the certificate in the LDAP directory is an exact copy of the certificate that the individual was issued. By no means does this prevent you from validating the certificate in the manner that was described in the digital certificate section of this document, but it allows a faster method of authenticating certificates.

Authentication and PKI Log on

Corporations would like to authenticate an individual as being a valid user of the system. This is very useful at log on time. You are probably most familiar with entering your username and password to log on to a computer network. With certificates, just the certificate can be sent instead of the normal username and password. Since your certificate contains you name nothing else needs to sent at log on time. This eliminates forgotten or compromised passwords. Once the certificate is sent the certificate will be validated by comparing it to the same certificate in the LDAP directory. Once the certificate is authenticated the system needs to check the name on the certificate and see if the owner of the certificate has access to network or a particular part of the network. No functionality is lost by using certificates as log on information and the log on procedure is actually made easier for the user. Since certificates are tamperproof the system can also sure of the user's identity whereas anyone could try to guess the right password for another user when password/username pairs are used. Since certificates establish identity, controlling who can access what data, is very easy to implement.

SSL Again

Since the corporation would like to encrypt all transactions across the network SSL channels needs to be created. This again is no problem as all users will have a certificates. Then the SSL handshake software will take care of validating the users and setting up the secure channel. The SSL handshake could also be extended so that a user could log on to the network during the handshake. Access control could also be implemented at this time. This would allow the user to send his certificate once and be logged on the system and placed in his home directory.

A PKI Example

A bank could require that all customers needing to access account information and/or make transactions over the web, would have to obtain a certificate from the bank's CA or another predefined CA. The client would then have to trust this CA in his/her browser if it is not already trusted. Once the initial setup is complete the client would only need to access the https page for the bank. Since the client has a certificate, and he is entering an SSL site, the SSL handshake would authenticate the userís identity and set up a secure channel of encryption as it always would. The name could also be taken from the certificate and matched with that users bank account. The banks computer could then take the user directly to a page that contains his account information. The client would also be sure that no one else could access this account information because only the user has a copy of his certificate. Even if a hacker tried to fake the userís certificate the certificate would not match the one in the banks LDAP directory. The bank on the other hand is also positive that the client is really the client as the certificates match also. This is just one simple overview how PKI would actually be used.

This method of PKI has a lot of overhead and maintaince. Setting up and runnig a CA is a lot of work since certificates must be issued and managed by a human. Identities need to be vertified and the CA must be kept running so it can recieve certificate requests. Another issue is that the amount of software and data is greatly under estimated. There must be software to set up SSL channels of communication, authenticate certificates, and control access to the network. An in order for this software to function properly an LDAP database must be kept along with database of the users and what data each users has access to.

Once this infrastrute is in place, however, it can be used for a varitey of applications. These would include the coproration and bank, which would use the PKI to log users on to the network and control access to data. This PKI could also be extended to Internet commerece as SSL is in place and there is a method for strong authentication via certificates. This PKI is by far the most robust and secure solution but alos the most difficult and costly to maintain.

To go back to main page click here or to proceed to the page describing SSL, click here


Send your comments and sugestions to
rrwallac@ucsd.edu


Contact information URL: http://sdcc10.ucsd.edu/~rrwallac e-mail: rrwallac@ucsd.edu



 
 
[Back| Home| Programs| Documentation| Internet| People]