[zz]An Introduction to PKI (Public Key Infrastructure)

http://www.articsoft.com/public_key_infrastructure.htm

 

An Introduction to PKI (Public Key Infrastructure)

PKIis a security architecture that has been introduced to provide anincreased level of confidence for exchanging information over anincreasingly insecure Internet.  

This guide provides thereader with a basic introduction to key terms and concepts used in aPKI including the use of encryption, digital signatures, keys,certificates, Certificate Authorities, certificate revocation andstorage.  It mentions the features and services used by the PKIand the techniques involved in public key cryptography.  

1.1  Introduction

Theterm PKI can be very confusing, even to a technologist, because it isused to mean several different things.  On the one hand PKI maymean the methods, technologies and techniques that together provide asecure infrastructure.  On the other hand, it may mean the use ofa public and private key pair for authentication and proof of content. A PKI infrastructure is expected to offer its users the followingbenefits:

• certainty of the quality of information sent and received electronically
• certainty of the source and destination of that information
• assurance of the time and timing of that information (providing the source of time is known)
• certainty of the privacy of that information
• assurance that the information may be introduced as evidence in a court or law

Thesefacilities are delivered using a mathematical technique called publickey cryptography, that uses a pair of related cryptographic keys toverify the identity of the sender (signing) and/or to ensure privacy(encryption).  

PKI facilities have been developedprincipally to support secure information exchange over insecurenetworks - such as the Internet - where such features cannot otherwisebe readily provided.  PKI facilities can, however, be used just aseasily for information exchanged over private networks, includingcorporate internal networks.  PKI can also be used to delivercryptographic keys between users (including devices such as servers)securely, and to facilitate other cryptographically delivered securityservices.

1.2   How the Public Key Cryptography concept works

Public-keycryptography uses a pair of mathematically related cryptographic keys. If one key is used to encrypt information, then only the relatedkey can decrypt that information.  If you know one of the keys,you cannot easily calculate what the other one is.  As a result,in a public key system you have the following:

• A public key.  This is something that you make public - it is freely distributed and can be seen by all users.
• Acorresponding (and unique) private key.  This is something thatyou keep secret - it is not shared amongst users.

Your private key enables you to prove, unequivocally, that you are who you claim to be.

Thenext sections describe how these keys are used in practice.  Theyconsider using separate public and private keys for encryption thanthose used for signing.

The Public Key used for Encryption

Anotherperson uses your public encryption key when they want to send youconfidential information. The information to be sent is encrypted usingyour public key*.  You can provide your public key to thesender, or it can be retrieved from the directory in which it ispublished.  

*Note:  In normal practice, theactual information being sent is encrypted using a secret key algorithm(symmetric cryptography). Symmetric algorithms are much faster thanpublic/private key algorithms (asymmetric cryptography).  A randomkey (the session key) is generated, and it is used with the symmetricalgorithm to encrypt the information. The public key is then used toencrypt that key and both are sent to the recipient.

The Private Key used for Decryption

Aprivate key is used to decrypt information that has been encryptedusing its corresponding public key. The person using the private keycan be certain that the information it is able to decrypt must havebeen intended for them, but they cannot be certain who the informationis from.

Note:  In normal practice the private key is usedto decrypt the session key, and that key is used to decrypt the actualinformation rather than the private key decrypting all the information.

The Private Key for Signature

If thesender wishes to prove to a recipient that they are the source of theinformation (perhaps they accept legal responsibility for it) they usea private key to digitally sign a message (a digital signature). Unlikethe handwritten signature, this digital signature is different everytime it is made.  A unique mathematical value, determined by thecontent of the message, is calculated using a 'hashing' or 'messageauthentication' algorithm, and then this value is encrypted with theprivate key - creating the digital signature for this specific message. The encrypted value is either attached to the end of the messageor is sent as a separate file together with the message.  ThePublic Key corresponding to this private key may also be sent with themessage, either on its own or as part of a certificate.

Note: Anyone receiving information protected simply by a digitalsignature can check the signature and can read and process theinformation.  Adding a digital signature to information does notprovide confidentiality.

The Public Key for Signature

Thereceiver of a digitally signed message uses the correct public key toverify the signature by performing the following steps.  Anon-technical example is given after these steps.  

1. The correct public key is used to decrypt the hash value that the sender calculated for the information
2. Usingthe hashing algorithm (where certificates are in use it will be statedin the public key certificate sent with the message), the hash of theinformation received is calculated
3. Thenewly calculated hash value is compared to the hash value that thesender originally calculated. This was found in step 1 above.  Ifthe values match, the receiver knows that the person controlling theprivate key corresponding to the public key sent the information. They also know that the information has not been altered since itwas signed
4. If a public key certificate wassent with the information it is then validated with the CA that issuedthe certificate to ensure that the certificate has not been falsifiedand therefore the identity of the controller of the private key isgenuine
5. Finally, if one is available, therevocation list for the CA is checked to ensure that the certificatehas not been revoked, or if it has been revoked, what the date and timeof revocation were.

As an example, suppose you are sent a Worddocument by e-mail.  The sender has signed it by calculating ahash value for that Word document, and then encrypted that value withtheir private key. You receive the Word document, and calculate thehash value for it.  You decrypt the hash vale that the senderencrypted and compare the two.  If they are equal, the documenthasn't changed and you are certain who sent the document. (If theydon't match you know that the document has changed or the sender is notwho they claimed.)

If no errors have been found, the receivercan now be certain of the authenticity and accuracy of the informationthat has been received.

The following table summarizes who uses public and private keys and when:

Key Function	Key Type	Whose Key Used
Encrypt data for a recipient	Public key	Receiver
Sign data	Private key	Sender
Decrypt data received	Private key	Receiver
Verify a signature	Public key	Sender

Toencrypt information that will be stored for your own use (that is, youwill be the only person able to read it), you must use your own PublicKey as the recipients key (you are the recipient) in order to be ableto decrypt and read the information later.  If you use someoneelse's Public Key, then only they will be able to decrypt and read theinformation. (To avoid the difficulty associated with not being able toread encrypted messages if you are not one of the recipients, somesystems do not delete the original message after encryption whilstothers store a copy of the key used for encryption either under thesender's Public Key or under a System Recovery Key.  These latter methods are also referred to as key escrow or key recovery.)

PublicKey Cryptography is therefore used for the encryption/decryption andsigning/verification of information.  Encrypting informationensures privacy by preventing unintended disclosure, and signingmessages authenticates the sender of the message and ensures themessage has not been modified since it was sent.  It has to beremembered that only the information signed/encrypted has beenprotected.  Commonly in e-mail systems headers, addresses and bodymessages may have no protection at all and should not be consideredsecure or part of the protected information.

1.2.1   The certificate

Inthe section on public and private keys, references were made tocertificates.  A certificate is information referring to a publickey, that has been digitally signed by a Certification Authority (CA). The information normally found in a certificate conforms to theITU (IETF) standard X.509 v3.  Certificates conforming to thatstandard include information about the published identity of the ownerof the corresponding private key, the key length, the algorithm used,and associated hashing algorithm, dates of validity of the certificateand the actions the key can be used for.

A certificate is notessential to operating a PKI, however, some scheme is necessary to locate information about the controller of a private key, and theX.509 certificate is the most commonly implemented scheme.

1.2.2   Controlling Key Usage

Oneof the fields in a public key certificate (certificate) is the keyusage field.  It is used by the CA to state the uses the CA hasapproved.  It does not mean that the corresponding private keycannot be used in any other ways.  There is no certificate with aprivate key.  People receiving information protected using apublic key system should check, where a certificate is provided, thatthe key usage stated in the certificate corresponds to the actual use.

1.3.2   Storing methods for Public and Private Keys

Certificates

Publickeys are stored within digital certificates along with other relevantinformation (user information, expiration date, usage, who issued thecertificate etc.).  The CA enters the information contained withinthe certificate when it is issued and this information cannot bechanged. Since the certificate is digitally signed and all theinformation in it is intended to be publicly available there is no needto prevent access to reading it, although you should prevent otherusers from corrupting, deleting or replacing it.

Protection

Ifsomeone gains access to your computer they could easily gain access toyour private key(s).  For this reason, access to a private key isgenerally protected with a password of your choice.  Private keypasswords should never be given to anyone else and should be longenough so that they are not easily guessed.  This is the same aslooking after your ATM CARD and its PIN.  If someone manages toget hold of your card then the only thing that prevents him or herusing it is the PIN (password) protecting it.  If someone has yourPIN then they can take your money and you can't stop them.

Differentvendors often use different and sometimes proprietary storage formatsfor storing keys.  For example, Entrust uses the proprietary .epfformat, while Verisign, GlobalSign, and Baltimore, to name a few, usethe standard .p12 format.

1.3   The components of a PKI

A public key infrastructure is created by combining a number of services and technologies:

1)  Certification authority (CA)

ACA issues and verifies certificates (see above).  The CA takesresponsibility for identifying (to a stated extent) the correctness ofthe identity of the person asking for a certificate to be issued, andensures that the information contained within the certificate iscorrect and digitally signs it.  

Generating key pairs

TheCA may generate a public key and a private key (a key pair) or theperson applying for a certificate may have to generate their own keypair and send a signed request containing their public key to the CAfor validation.  The person applying for a certificate may preferto generate their own key pair so as to ensure that the private keynever leaves their control and as a result is less likely to beavailable to anyone else.

Issuing Certificates

Unlessyou generate your own certificate (some applications software willenable you do this) you will generally have to purchase one from a CA.Before a CA issues you with a certificate they will make various checksto prove that you are who you say you are.

The CA could bethought of as the PKI equivalent of a passport agency - the CA issuesyou a certificate after you provide the credentials they require toconfirm your identity, and then the CA signs (stamps) the certificateto prevent modification of the details contained in the certificate.

ACA may also state the quality of the checks that were carried outbefore the certificate was issued. Different classes of certificate canbe purchased that correspond to the level of checks made.  Thereare three or four general classes of certificate: Class 1 certificatescan be easily acquired by supplying an email address, Class 2certificates require additional personal information to be supplied,and Class 3 certificates can only be purchased after checks have beenmade as to the requestors identity.  A 4th class may be used bygovernments and organizations needing very high levels of checking.

Using certificates

Anindividual may have any number of certificates issued by any number ofCAs.  Different Web applications may insist that you usecertificates issued only by certain CAs.  For example, a bank mayinsist that you use a certificate issued by them in order to use theirservices, whereas a public Web site may accept any certificate youoffer (just as some allow free choice of ID and password).

The CA can be a unit within your organization, a company (i.e. a bank or a post office), or an independent entity (VeriSign).

Verifying Certificates

Thepublic key certificate is signed by the CA to prevent its modificationor falsification.  This signature is also used when checking thatthe public key is still valid.  The signature is validated againsta list of 'Root CAs' contained within various 'PKI aware' applications(e.g. your browser). Some CA certificates are called 'RootCertificates' as they form the root of all certificate validation. Certificate validation occurs automatically using the appropriatepublic certificate contained within the root CA list.

Note: PGP (Pretty Good Privacy) users normally act as their own issuingauthority, so you accept their certificate on the basis that they arewho they say they are without further verification.  This methodis called the 'Web of trust' because it is based upon people you trustrather than liability by contract.

2)  Revocation

Wherea system relies upon publishing certificates so that people are able tocommunicate with each other, there has to  be a system for lettingpeople know when certificates are no longer valid.  It can be donein one of two ways.  Certificates can be deleted from theDirectory or database in which they should be found.  As a result,any attempt to find them to check that they still exist will fail andanyone looking for them would know that they have been revoked.

Thereare two problems with this approach. The first is that a denial ofservice attack on the Directory or database might create the appearanceof a failed certificate.  The second is that the Directory wasdesigned to optimize the time to read information, so deletinginformation is normally avoided, as is updating.  Also, deletingthe record does not tell the person asking for the information why it is not there, and they may need to know why and when it was removed.

Asa result, a system of revocation lists has been developed that existsoutside the Directory or database.  This is a list of certificatesthat are no longer valid (for whatever reason), equivalent to a lost orstolen ATM card list.  There are currently two different methodsfor checking for certificate revocation - 'CRL' or 'OCSP'. Revocation lists may be publicly available even when the matchingDirectory or database is not.  This is because certificates mayhave been distributed for use beyond the private network of theorganization involved.

3)  Registration Authority (RA)

A CA may use a third-party Registration Authority (RA) to performthe necessary checks on the person or company requesting thecertificate to ensure that they are who they say they are.  ThatRA may appear to the certificate requestor as a CA, but they do notactually sign the certificate that is issued.

 

4)  Certificate publishing methods

Oneof the fundamentals of PKI systems is the need to publish certificatesso that users can find them. (You must be able to get hold of thepublic encryption key for the recipient of encrypted information.)There are two ways of achieving this.  One is to publishcertificates in the equivalent of an electronic telephone directory. The other is to send your certificate out to those people youthink might need it by one means or another.  The commonestapproaches are listed below.

Directories

Directoriesare databases that are X.500/LDAP-compliant.  This means that theycontain certificates in the X.509 format, and that they providespecific search facilities as specified in the LDAP standards publishedby the IETF.  Directories may be made publicly available or theymay be private to a specific organization - i.e. a company may have itsown directory where it holds the certificates for its users and onlyits users can access this directory.  A Directory is kept privatewhen it contains information that the owner does not wish to bepublicly available.  Public directories on the other hand can beread by anyone with access to them.

Databases

Adatabase can be configured to accept X.509 format certificates. This may be done for private systems where the search methods forlocating certificates do not follow the LDAP structure.  Becauseit is essentially proprietary, this method is not used for publicsystems.

Email, floppy discs etc.

Certificates maybe sent within an e-mail so that the recipient can add them to theirown collection on their server or desktop, depending upon the way theirsecurity systems have been configured.  They may also be put ontofloppy discs, or any other medium.

5)  Certificate Management System

Thisterm refers to the management system through which certificates arepublished, temporarily or permanently suspended, renewed or revoked. Certificate management systems do not normally deletecertificates because it may be necessary to prove their status at apoint in time, perhaps for legal reasons.  A CA (and perhaps anRA) will run certificate management systems to be able to keep track oftheir responsibilities and liabilities.

6)  'PKI aware' applications

Thisterm usually refers to applications that have had a particular CAsoftware supplier's toolkit added to them so that they are able to usethe supplier's CA and certificates to implement PKI functions. The term does not mean that the applications have any 'knowledge'built into them about what the security requirements really are, orwhich PKI services are relevant to delivering them.  These issuesare quite separate from having PKI services available.