 |
|
|
January 2004
Introduction With the growth in use of the Internet for business transactions, the need for confidentiality and positive identification of all parties involved is increasingly vital. The use of encryption and digital signatures are important tools in the ongoing struggle to maintain privacy and confidentiality over insecure transports such as the Internet. Confidentiality of data stored on the corporate network is also becoming increasingly important for many organisations. Historically, operating system access control has been enough to keep all but the most determined employees from browsing through company confidential data. However, it has always been an accepted fact that IT personnel could access any data stored on the network � the only assurance we have against this is trust and personal integrity, and that is not always enough. Using encryption, any organisation can ensure that all the data stored on its network remains secure from any prying eyes � whether in the IT department or not. Public key cryptography is the perfect solution for ensuring the privacy of data employed in distributed systems of all kinds. This is especially true in the kinds of systems implemented as part of e-commerce solutions, where organisations are engaging in transactions with individuals who are hitherto unknown to them, and with whom they may never have any further contact. The cost of deploying secret keys for such transactions is high, both in pure financial terms and in terms of the loss of a large number of customers who would not have the patience to wait for some sort of secure key distribution to take effect. Internet shopping is often about spur-of-the-moment purchases and instant gratification, after all. Public key systems, on the other hand, allow us to communicate securely between individual and organisation using keys which can be freely distributed and published anywhere � much like your telephone number in a directory. This can be augmented still further by the use of digital certificates, which bind a public key to an individual or organisation and carry the signature of a trusted Certification Authority (CA), thus verifying its authenticity. Secure Sockets Layer (SSL), Secure/Multimedia Internet Mail Extensions (S/MIME), Secure Electronic Transactions (SET), and code-signing services for both Java and ActiveX all make use of public key encryption, and thus all require some means of managing those keys. To date, most use of public keys has been driven from the client end � end-users obtaining Class 1 certificates from organisations such as VeriSign for their browsers or e-mail clients. Application and renewal of such certificates and their associated keys are entirely under the control of the client, and renewal is more a commercial event than a strategic one. For instance, VeriSign forces a refresh of a certificate every year purely to collect fees rather than as a means to force key updates. A properly implemented Public Key Infrastructure (PKI) supported by an effective security policy will force key updates at regular intervals that will be driven entirely by the security needs of the organisation rather than any overriding commercial decision. That key update will also be completely under the control of the PKI administrator or security officer. Key management imposes a significant burden on an organisation, since it requires far more than just a piece of certificate server software to create and distribute digital certificates. To date, however, many organisations have found it confusing when looking for products. Is CA software the same as PKI? Are there any standards in place? Do they need separate directory services? It�s true that to date standards have been pretty thin on the ground, leaving companies to hang fire or settle for one of the widely available � yet essentially proprietary � PKI systems. The rapid adoption of the Internet as a business communications medium, however, has accelerated the requirement for robust and effective key management systems and PKI is suddenly under the spotlight. When is a PKI System Not A PKI System? When choosing a PKI system, there are a number of features to watch out for. It is easy to pass a certificate server off as a PKI solution, and the terminology is not entirely inaccurate. Most certificate products, however, are focused primarily on the creation, publication, and management of certificates. Products such as Netscape Certificate Server and Microsoft Certificate Server, for example, enable managers to generate �root� keys used to sign the certificates they generate. Both allow details of the certificates generated to be published in a directory and support the use of Certificate Revocation Lists (CRL). All these are important functions, but stop short of full key management facilities � such as backup, recovery and update � that are necessary to support a full-blown PKI. The astute buyer therefore needs to be aware that certificate generation and distribution is only one small part of a complete PKI solution. If you are looking for that complete solution, you should expect the products on your short list to contain most, if not all, of the following components: Certificate Server � this is the platform that generates, serves and manages the certificates and binds them to the appropriate public keys � both for signing and encryption. It will also renew these on demand or at regular intervals as defined by security policies. Note that private signing keys are not held at the server in order to provide non-repudiation (see point 7). Directory � a repository of all the public information that is pertinent to a PKI, including the public key certificates, CRL, ARL, CA certificates, and so on. It is critical that this element of the PKI has high availability, and it is often distributed throughout an organisation. LDAP compatibility is a must. Revocation system � the ability to revoke a key to prevent further access to encryption and/or signing functions by the user using a particular key pair (perhaps because the user has left the company or because his or her keys have been compromised in some way). Certificate Revocation Lists (CRL) must be maintained automatically and distributed regularly throughout the system to ensure that access is always restricted only to those with valid certificates. In addition to CRLs, other methods can be used to provide more timely and efficient notification of certificate status, such as the Online Certificate Status Protocol (OCSP). Whichever method is used, it is vitally important that end-user applications actually use them to verify certificate status, of course. Automatic key update � The only reason for a certificate to have an expiry date is to ensure that new key pairs are generated at regular intervals. However, the end user should be unaware of this process if possible, unless the security policy dictates that a positive action is required by the user. If a positive action is not required, the key update should be completely automatic and transparent, ensuring that the user is always using keys that conform to the corporate security policy. Key histories � As keys are updated at regular intervals, it will become necessary to access data encrypted under a previous generation of keys for a particular user (or to verify a signature created with an earlier key pair). The user should not have to keep copies of every version of every certificate and associated key pair they have ever used � matching key pairs to documents would be a time-consuming and error-prone task. Instead, the PKI should provide the means to maintain a complete key history against a user, and should access the appropriate version each time a decryption or signature validation operation is performed. Key backup and recovery � Not to be confused with key escrow, key recovery ensures that copies of decryption keys are maintained at the certificate server for all users, and can subsequently be recovered should the need arise (such as when the user forgets a password, leaves the company, or if a court order is produced by a law enforcement agency to recover encrypted data). Support for non-repudiation � the idea of key backup and recovery opens a loophole in the system. Now a user could claim that because someone else potentially has access to their signing key, that they were not actually responsible for particular transactions that had apparently been signed by them. It is thus necessary to maintain dual key pairs for every user. The encryption key pair can be backed up and recovered, whereas the signing key pair should never leave the user�s possession. Cross certification � If Bob and Alice work for Acme Inc, they trust it as their Certification Authority. If Fred works for Bloggs Inc., he trusts it as his CA. But how does Bob know whether or not he can trust Fred? In order to remove the need for multiple trusts to be created between individual users, a PKI should be able to create high-level mutual or one-way trusts between CA�s. Thus, if Acme trusts Bloggs, then by implication, Bob and Alice can both trust Fred. Of course, Acme and Bloggs must exercise due diligence to ensure that they both have similar risk models and procedures. In addition to peer cross-certification, today�s PKI should also support a multi-level hierarchical model of CA�s and sub-CA�s. Client-side software � If all of these functions are to be supported fully, then some form of PKI interface is required at the client PC. Only then can the PKI ensure that CRL's are checked rigorously, that key lifecycles are managed correctly, and that key histories are maintained transparently. This client-side software can take the form of a proprietary PKI client for the PKI vendor, or various PKI-aware applications such as browsers or e-mail clients, or applications that have been PKI-enabled using various tool kits from the PKI vendors. Such applications will support PKI functionality in varying degrees. This last point is often contentious, with PKI vendors that do not require a client criticising those who do for being �proprietary�. However, it is worth considering for a moment the implications of not having some form of client-side component in the PKI: Separate certificates and keys may be required for every application attempting secure communication, with the resulting management overhead for both user and administrator. Without the means to manage complete key histories locally, users may be forced to keep copies of all keys ever used on their system to ensure they can decrypt an older document after the original encryption keys have expired. The older keys will inevitably go missing, forcing the user to approach the security officer to perform key recovery operations before data can be accessed.Finally, there is no way to force regular and rigorous checking of CRL�s, thus opening a potential loophole in the PKI Note that recent developments have seen vendors moving towards providing lightweight or zero-footprint �clients� in the form of automatically-downloaded Web browser plug-ins or Java applets. This means that it is possible to provide the advantages of client-side software without having to physically install it on each machine that is likely to require its use. Of course, not all of the above components are always supplied by the PKI vendors themselves. The most obvious element which may be already installed in an organisation or which may be provided by a third party is the directory service. Those using an enterprise X.500 directory or one of the more recent offerings from Novell (NDS) or Microsoft (Active Directory) will require their chosen PKI solution to integrate fully. Indeed, any PKI product that does not include all of the above components out of the box, should at least provide support for third party options via standards-based interfaces. In the best tradition of the James Bond novel, encryption is all about secret codes, transforming plain text into a form unreadable by anyone without a secret decryption key. It thus allows secure communication over a general purpose insecure channel, such as the Internet. Although the mathematics behind it can be very complex, encryption itself is pretty straightforward. Cast your minds back to when you were children and you wanted to send secret messages to each other. The simplest form of encryption was the one where every letter of the alphabet was substituted for the one �n� positions following it. Here we are introduced fairly painlessly to the two most important buzzwords in the cryptography world: the �key� is the number of positions we are shifting the letters, whilst the �algorithm� is simply the idea that the encrypted letter is the one �n� places following the plain text letter. There are two ways you can beef up security on this � increase the length of the key, and devise ever more complex algorithms. Luckily, we do not have to get involved in creating our own algorithms, since there are some perfectly acceptable standards out there. The main ones currently available are DES (Data Encryption Standard), triple DES, IDEA (International Data Encryption Algorithm) and RC4 (an algorithm developed by Ron Rivest of RSA as a stream cipher with a variable key length). Whereas the original DES algorithm uses 56 bit keys, later and more powerful systems use much longer ones, forcing potential hackers to run through trillions of combinations in any attempt to find the right one by brute force. Triple DES is an enhanced version of the original DES algorithm and encrypts data three times using two different keys (providing an effective key length of 112 bits). There is also an implementation of Triple DES � known as 3DES3KEY � which encrypts data three times with three keys providing an effective key length of 168 bits, though this is much less widely deployed. IDEA is a 128 bit mechanism developed by the University of Zurich in 1992 and is a favourite of European financial institutions. As you would imagine, the longer the key length, the more secure the encryption. Going back to our simple cipher, if our single digit key is represented by a letter of the alphabet, a potential hacker only has to try 26 possible combinations in order to crack the cipher using brute force. Now, if we increased the length of the key and wrote it beneath our original message (repeating the key over and over until it was equal to the length of the message), each character in the key would represent a different shift for the letter above. Of course, if short keys are used, then repeating patterns may begin to emerge in the message - the most secure method is to use a key the same length as the message itself, but this is impractical in real life situations. Combine long keys with sophisticated algorithms, however (something a little more complex than �shift each letter of the message by the value of the key character beneath�) and you are in business. Unfortunately, �secret key� or �symmetric key� cryptography (as it is known) clearly relies on both parties involved having access to the same secret key, since the sender uses the key to encrypt the message, and the receiver uses the same key (together with the same algorithm in reverse) to decrypt the message. This naturally introduces a potential problem � how do we ensure that the key is distributed in a secure manner? If we have regular contact with the person, we can pass the key face to face � you cannot get much more secure than that. In business terms, secret keys (such as bank PIN numbers) are often distributed by mail in special tamper-proof envelopes, or can be encapsulated in hardware devices such as smart cards, where the issuing authority never gives the customer access to the key information at all. But in the case of one-off Internet transactions with hitherto unknown parties, we do not have that luxury, since as a result of the unique key-pair arrangement between the two parties, it is impossible to exchange data with someone to whom you have not already been �introduced�. Neither of you has a shared secret key, and there is no secure channel over which to exchange one. For this reason, secret key cryptography works best when a single issuing authority is maintaining a service for a user base where there is some kind of registration process that takes place prior to the exchange of information. With �public key� or �asymmetric key� cryptography, however, each person gets a pair of keys, known as the public key and the private key. The public key is generated from the private key using a complex algorithm, following which the public key can be published, whilst the private key remains secret. The mathematics behind public key cryptography are exceedingly complex, and beyond the scope of this paper, so you are simply going to have to trust me on this one � any message encrypted with a given public key can only be decrypted using the corresponding private key, and there is no known way to derive the private key from the public key. Honest � this really works. Now, if Bob wishes to send a message to Alice (Bob and Alice are the cryptography industry�s favourite couple), he will encrypt it using Alice�s public key (which can be published in a directory or distributed via unsecured e-mail). The only person who can decrypt the resulting message is the holder of the appropriate private key � Alice. The need for sender and receiver to share secret information is eliminated, since all communications involve only public keys, and no private key is ever transmitted or shared. The best known and most widely used asymmetric key technologies are Diffie-Hellman (for key exchange) and RSA (for encryption and signing). Although providing the highest levels of security, public key cryptography is notoriously heavy on system resources, particularly when working on large messages. For performance reasons, therefore, RSA is usually used only to exchange keys, whilst a conventional secret-key cryptosystem (such as DES) is used for the bulk of the message. Suppose Alice wishes to send an encrypted message to Bob. She first encrypts the message with DES, using a randomly chosen DES �secret� key which can be different for every message sent. Then she uses Bob's public key to encrypt the DES key. The DES-encrypted message and the RSA-encrypted DES key together form a �digital envelope� and are sent to Bob. Upon receiving the digital envelope, Bob decrypts the DES key with his private key, finally using the DES key to decrypt the message itself. Once we have our data encrypted to prevent snoopers discovering its content, we still have to prove who we are to the other party involved in the transaction. In a real-life commerce scenario the most important piece of evidence available to the merchant is the customer�s signature. Although it is possible to forge someone else�s signature, we have to accept that it is beyond the means of most casual thieves providing the merchant takes sufficient care when checking it. We therefore require an electronic equivalent � something the merchant can hold up in a court of law and say �here is proof that this particular customer placed the order�. Digital signatures � for that is the name of the technology involved - also provide one other useful feature: complete non-repudiation. Not only can we prove that the transaction originated from a particular source, but we can also prove that it has not been tampered with in any way during transit. To ensure that no one can forge your electronic signature, digital signatures make use of public key techniques, using algorithms such as DSA and RSA (the latter being the most common implementation). Suppose Alice now wishes to send a signed message to Bob using RSA. She uses a �hash function� to create a uniquely concise version of the original text - known as a �message digest� - which serves as a very much smaller "digital fingerprint" of the message. As with general encryption, there are several secure hash functions available such as Message Digest 5 (MD-5) or Secure Hash Algorithm (SHA-1). After a couple of potential weaknesses were discovered with MD5, SHA-1 has become the preferred method. It is infeasible that different documents will have the same message digest, and even small changes in a document will cause significant changes in the digest. Next, Alice encrypts the message digest with her RSA private key (or a secret key, if preferred), and this becomes the digital signature, which she sends to Bob along with the message itself (which may or may not be encrypted). Bob, upon receiving the message and signature, decrypts the signature with Alice's public key to recover the message digest. He then hashes the message with the same hash function Alice used and compares the result to the message digest decrypted from the signature. If they are exactly equal, the signature has been successfully verified and he can be confident that the message did indeed come from Alice. If, however, they are not equal, then the message either originated elsewhere or was altered after it was signed, and he rejects the message. Note that for authentication, the roles of the public and private keys are converse to their roles in encryption, where the public key is used to encrypt and the private key to decrypt. Note also that signing only guarantees integrity and authenticity, it does not guarantee privacy � encryption of the actual message content must be performed separately if required. DSS � developed for use by companies that do business with the US Government � is a signature-only system, whereas RSA can be used both for signing and generally encrypting a message. Digital signatures provide the highest levels of data integrity, since any tampering after signing invalidates the signature. They also provide unforgeable origin authentication, since they are based on the sender�s private signing key, and authenticated by the public verifying key. Note that in most PKI systems today, two key pairs are generated for each user � one pair for encryption/decryption and the other for signing/verification. This allows the administrator to keep backup copies of users� encryption keys in case those keys are lost or the employee leaves the company and data encrypted with those keys needs to be recovered. The signing keys, however, never leave the possession of the user (they are never backed up), since they are intended to be as personal � and inaccessible to others - as the user�s physical signature. This is the only way we can ensure non-repudiation, since unless the keys are compromised in some way (i.e. the token on which they are stored is lost or stolen) the user can never claim that someone else signed on his or her behalf. Although public key cryptography is well established and generally accepted as secure, it too suffers from one potential drawback. Since public keys are designed to be readily available, it is difficult to ensure that a particular public key does indeed belong to the person you are expecting, and is not a forgery. After all, the key is just an apparently random jumble of meaningless data, bearing no resemblance to an actual person and carrying no personal data about the owner. This means that Fred could create a false public key purporting to come from Bob, which he then publishes. Alice, wanting to send a personal message to Bob, encrypts using the forged public key. The resulting message is useless to Bob, but if Fred can intercept it, he can use his �fake Bob� private key to decrypt the content. In the �real� business world, when we are about to do business with a complete stranger we may ask for references, or for a third party whom we know and trust to vouch for the stranger. It would be nice to be able to have similar assurances in the electronic commerce world too, and as it happens we can � using something called a �digital certificate�. The simplest form of a certificate contains only the public key, the identity of the certificate owner and the signature of a trusted third party - someone to �vouch� for the owner of the certificate. That third party is the �Certification Authority� (CA) in our PKI, and it is important that the CA is trusted in order that the certificate can be considered genuine. The owner of the certificate also has the private key - the private key is never encoded in the certificate itself. Only when the owner does some operation with the certificate we can assume that the private key is present. So, for example, when someone requests that Bob send his certificate, he will send the certificate, but not his private key. CA�s can be either public or private. An organisation operating as its own CA (with its own root certificate) is a private CA, whereas a public CA offers its services to both end-users (say for browser or e-mail certificates) and to corporate bodies who wish to outsource their PKI. VeriSign is a typical example of a public CA. Certification authorities can also issue certificates to other CAs, which leads to a tree-like certification hierarchy. The highest trusted CA in the tree is called the root CA, and within the hierarchy, every certificate is signed by the CA immediately above it. An exception is the root CA certificate which is usually signed by the root CA itself. The certification path refers to the path of certificates from one certificate to another certificate, based on the relation of a CA and its �children�. When verifying the validity of a certificate, it is necessary to have the certification path from the trusted root CA certificate to the certificate in question. As things progress, it should be possible (and desirable) to have a hierarchy of CA�s, going from banks or reputable organisations at the bottom, all the way up to government bodies and even, perhaps, the United Nations. The highest certification authority in the hierarchy is known as the top-level CA. Specifically, at the very top of the hierarchy is the root public key. That root public key signs the certificates for all top-level certification authorities, which can then sign certificates for lower-level certification authorities. This provides the infrastructure for implicit trust between organisations and users without the need for explicit cross certification, since everyone in a trusted community will ultimately trust the same root authority. Until this is established, however, peer-to-peer cross-certification is possible for simple business-to-business relationships. How Are Digital Certificates Used? The basic idea of a PKI is to have a trusted CA which, as a trusted third party (TTP), can be used to build trust between the end entities possessing the certificates. To add a new end entity to a PKI, that entity has to create a key pair, and a Certification Authority (CA) has to certify the key pair. This process of an end entity enrolling to a PKI is commonly known as certificate enrolment. Certificate enrolment involves (usually) two parties - a client (the end entity) and a server (the CA) - and they need to communicate to have the certificate issued. A typical certificate enrolment process consists of the following steps:
There are several security requirements in certificate enrolment. The end entity first has to be able to prove the possession of the key to the CA (this is known as PoP, or proof of possession). Usually this is achieved by signing the certificate request with the private key. Additionally, the CA has to authenticate the end entity, and this can be done automatically by using pre-shared keys, or manually in an out-of-band way. In the certification request, the end entity may define the values wanted for the certificate. The CA, however, considers the request as a wish list, and under its own policies it can deny the request completely or modify the requested values. The Certification Authorities that process the requests can be roughly divided into two categories: manual CAs and automatic CAs. Manual CAs require a human operator to manually approve the request, whereas automatic CAs issue the certificates automatically based, for example, on shared secrets (one-time passwords). However, in real life, automatic CAs also need a human operator at some stage in the process for creating and distributing the one-time passwords. If manual actions are needed, the processing of a certification request may take some time, and the end entity has to later poll for the certificate. Several online protocols have been developed for certificate enrolment, and these are described in the section on standards which follows. Authentication vs. Authorisation Certificates by themselves only provide authentication, not authorisation. After a certificate has been validated, we know that the identity of the certificate is valid and that it is issued by a specific CA. Because the digital identity is provided by the CA, we must trust that the CA has somehow checked that the certificate owner actually matches the claimed identity. For personal certificates, this means that prior to issuing a certificate, somebody has to check that the person requesting the certificate is really who they claim to be. If we trust a specific CA, we already trust that it does this - but this is not always the case. Some online CAs, for example, issue certificates based only on the applicant presenting a valid e-mail address, so it is not possible to use those certificates for identity-based authorisation. In some systems, there are special Registration Authorities (RAs) which verify the end-entity identity for the CAs. They may insist on physical presence for registration, at which point the RA Officer will examine physical ID such as passport or driving license. In such cases, the RAs can issue proof that a person is the owner of a certain private key. It is then possible for authorisation to follow authentication. When we know, for example, that the verified identity �Bob� has contacted us, we need to check if Bob has the rights to do something. We might also do the authorisation by specifying that certificates issued by a certain CA have specific rights no matter what their identities are. The choice is up to the application, although the particular certificate system may impose constraints upon this. In a typical electronic commerce example, a potential customer - Alice - will first obtain a certificate from a trusted CA by providing proof of identity. As already discussed, this can range from a valid e-mail address to being required to appear in person with a birth certificate and passport, depending on the level of digital ID required. At the time of registration, a request for a digital ID is generated and her signing and/or encryption public keys will be bound to their respective digital certificates and stored at the CA. Depending on the PKI system the key pairs may be generated at registration time, or they may be generated ahead of time and transported to the registration site on a secure token such as a smart card. In a pure Web model, as we have already discussed, registration is not as stringent (usually tied only to a valid e-mail address and not requiring extensive proof of identity). The keys are then generated locally on the user�s PC and a request for a digital ID is submitted automatically by the client-side software (Web browser or e-mail client). Most public CA�s will not usually wish to store copies of any of the keys themselves because of liability issues, and will only maintain copies of the certificates. Most private CA�s, however, will take a copy of the signing public key and the encryption key pair for backup and recovery purposes. In any situation, copies of the user�s private keys always remain with the user and are never transmitted over the network or stored anywhere in the PKI system. Once she has registered with her CA, Alice is ready for her e-commerce experience. When she wishes to purchase her new PC from Acme Computers over the Internet, she digitally signs the order (she may or may not encrypt it, depending on its sensitivity) and provides a copy of the certificate (this is done automatically in S/MIME applications). If she wishes, to encrypt the order, she must first obtain a copy of Acme�s public key, the authenticity of which she will be able to verify by virtue of the fact that the digital certificate has been signed by a trusted CA (providing the CA�s root certificate is held in Alice�s browser software). When a CA issues a public-key certificate, it also specifies a lifetime for which the certificate is valid. The validity period can be anything from a couple of days to twenty years, and once the end date is passed the certificate should no longer be trusted. There also needs to be a system in place to allow certificates to be revoked immediately in certain cases - say where an employee has left the company or the user�s private key has been compromised. If the cancellation of the certificate is not required to be permanent, it is possible to suspend the certificate instead of revoking it. Suspended certificates can be reactivated at a later time, whereas revoked certificates are permanently cancelled. Certificate Revocation List (CRL) This is achieved via a mechanism called the Certificate Revocation List (CRL), which contains a list of revoked and suspended certificates. More precisely, it contains some unique key to identify the certificate and its revocation time. The unique key could be the serial number of the certificate, or some other identifier. CRLs are usually stored in public directories which can be accessed by LDAP, HTTP or other protocols. Multiple CAs can share the same CRL directory. Every certificate may have a pointer to a specific CRL it uses, and this is defined when the certificate is created. The pointer identifies the place from where the CRL is to be retrieved. For instance, with X.509 this could be a URL with a HTTP server, or a server address with LDAP. However, in some cases no pointer exists and the application must have other knowledge of the CRL distribution site. How CRL�s are made available by CA�s varies considerably from CA to CA, and also by how much you are willing to pay for the service! A CA might, for example, have a default policy of publishing CRL�s once a day. Institutions which require a more immediate notification of revoked certificates could be asked to pay extra for twice daily, two hourly, or even hourly publication. Most CA�s provide a single, monolithic CRL which can be cumbersome to access and slow to check. Some, however, offer more efficient validation protocols such as a segmented CRL with separate distribution points that is very much quicker to interrogate, or via the use of Online Certificate Status Protocol (OCSP). Online Certificate Status Protocol (OCSP) OCSP is specified in RFC 2560, and provides applications with the means to query for the validity status of an identified certificate in (almost) real-time. When utilising OCSP, the OCSP client sends the responder a request message containing information on the certificate for which validation information is required. While the OCSP client waits for the response, the certificate is suspended. When a response is received the OCSP client�s action is based on the response as the client either accepts or rejects the certificate. Unfortunately, most applications today do not support automated checking of CRL�s even when they are available, and this means that CRL checking must be added to applications that require valid certificates. Different methods of validation between CA�s is yet another challenge of deploying large-scale PKI, though this can be alleviated by using third parties such as ValiCert. ValiCert�s Validator Suite has the ability to check the status of any X.509 certificate using any of today�s popular validation mechanisms, including CRL�s, OCSP, CRL Distribution Points (CRLDP) and ValiCert�s own Certificate Revocation Tree (CRT) solution. It is more than a little disturbing to realise that in the four years since we first published this report, very little has changed in this area in terms of making CRL checking as automated and seamless as possible for the end user. In addition to the validity period, a certificate usually has other constraints that limit its use. A certain CA may specify that the certificate and the associated key may be used only to sign and decrypt e-mails, for example. Whenever a certificate is presented as a means of authentication, the recipient must verify the validity of the certificate. This includes the following steps:
Note that successful validation does not equal authorisation. After the validation, the recipient knows that the certificate is valid for the time period selected, and it can be used for further security related operations such as authorisation and access control. In our previous e-commerce example, therefore, Acme Computers will validate Alice�s certificate on receipt, and because it has been signed by a trusted CA, the company knows it has a genuine copy of Alice�s public key. It can then use this to verify the digital signature on the order, which was, of course, signed by Alice using the corresponding private key. At the same time, the expiry date on the certificate will be checked to make sure it is still valid. As a separate operation (or automatically if it is supported by the client software) Acme will check to see that the certificate has not been revoked (the equivalent of a credit card company cutting up Alice�s card). Once both parties have satisfied themselves of the other�s credentials they can begin trading, safe in the knowledge that they have genuine copies of each other�s public keys, and can thus effectively encrypt and digitally sign all future transmissions between them. CRL�s must still be checked each time a certificate is presented, however, since the certificate could have been revoked in the mean time. This provides for complete �non-repudiation�, whereby digitally signed messages can be proved authentic to a third party, such as a judge, thus allowing such transactions to be legally binding. The ability to �extend� a certificate is also inherent within the X.509 version 3 standard, providing the means to hold additional personal information - such as a credit limit or signing authority, perhaps - within the certificate itself (though this raises privacy issues, of course). In the future � as we move towards an increasingly cashless society � public key certificate details can be stored securely in devices such as smart cards, providing a truly portable and secure (providing you keep your smart card safe) means of performing electronic transactions. Other Uses For Digital Certificates Note that digital certificates are not always associated purely with people - network resources can be allocated a certificate too. For instance, two firewalls could each be assigned a digital certificate with an associated encryption key pair. These could then be used to provide positive identification and encryption capabilities for each end of a Virtual Private Network (VPN) link. A certificate could also be allocated to a Remote Access Service (RAS) server allowing remote users to be sure they are connected to the correct device, and allowing the RAS server to positively identify each user. Finally, digital certificates can be used as a method of securing application access. At the point a user is asked for his or her network logon credentials a smart card could be inserted into a reader of a virtual smart card invoked from the hard disk to provide secure logon capability. From that point onwards, all communications across the network or between applications could be secured and encrypted - a database server, for example, could have its own public key pair assigned to it, allowing secure communication between client and server. There are several standards that relate to public key cryptography, and a certain level of interoperability is provided as a result of this. The cornerstone is the ITU-T X.509 standard (currently version 3) that includes the specification for the digital certificate format. RSA has a series of Public Key Certificate Standards (PKCS) available that define many essential PKI components, including digital signatures and certificate request formats (see Appendix A). Under the auspices of the IETF, the Public Key Infrastructure Working Group (PKIX) has also created a set of proposals that provide a well-rounded definition of an interoperable public key infrastructure. It is unlikely that the PKIX specifications will displace PKCS, however - the two will undoubtedly coexist and interoperate. Several online protocols have been developed for certificate enrolment. These protocols are described below. Certificate Management Protocol (CMP) CMP is a certificate life-cycle management protocol developed by the PKIX Working Group of the Internet Engineering Task Force (IETF), and it is described in documents RFC 2510 and RFC 2511. CMP supports PKCS #10 and Certificate Request Message Format (CRMF) as the request message formats. These formats provide the mechanisms for proof of possession (PoP) for the private key that is being certified and they are wrapped inside CMP messages. The CMP messages can be transported with either HTTP or TCP. CMP is a full certificate life-cycle management protocol, and initial enrolment is only part of it. In CMP, an end entity needs to send an initial request when the first certificate is enrolled from a given CA. Consequent certification requests can be signed with the valid private key to facilitate automatic key renewal. Revocation requests can be used to inform the CA about the need to revoke a certificate. Currently CMP is not widely supported by the end-entity clients and devices, but as a result of intensive interoperability efforts it is likely that more client-side implementations will emerge. Simple Certificate Enrolment Protocol (SCEP) SCEP was developed by the IPSec community to overcome the problem of enrolling certificates for routers and other network devices. SCEP is widely supported both on the client and the server sides. SCEP uses PKCS #10 as the certification request format and PKCS #7 as the digital envelope syntax. HTTP is used as the transport protocol. A prerequisite for SCEP enrolment is that the end entity must have the appropriate CA certificate. This needs to be verified using some offline method (fingerprint check) in order to prevent man-in-the-middle attacks, in which a third party impersonates the CA. The initial end-entity authentication in SCEP is done either manually or by using shared secrets. When using a shared secret scheme, the CA administrator generates a one-time password for the entity and distributes the password to the entity in a secure way. When the entity generates the certification request, it includes the password in the request. After approving the request the CA issues the certificate and packs it to a PKCS #7 cryptographic packet and sends it to the end user (and possibly publishes the certificate to a directory). Many clients support Web-based certificate enrolment. The end entity generates a key pair, creates the certification request on a Web browser, and submits the request to the CA with an HTTP POST operation. After approving the request, the CA returns the certificate to the end entity. Transport Layer Security (TLS) can be used to protect the enrolment session. If the certificate policy requires manual administrator approval, the user can poll the certificate via the Web pages. Most Web browsers support exporting the private key and the certificate in PKCS #12 format. PKCS #12 is a portable file format for storing user credentials and many PKI client applications, in turn, support it for importing keys and certificates. PKCS #10 is the simplest form of certificate enrolment. However, it requires more manual work than SCEP and CMP. In this enrolment method an end entity generates a key pair and a base64-encoded (PEM-encoded) PKCS #10 certification request in a file. The PKCS #10 request is then sent to the CA, usually via a Web form. If the certificate policy requires manual administrator approval, the user needs to download the certificate later after it has been approved. Unfortunately, although most public key applications support the appropriate standards this still does not guarantee interoperability due to slight differences in implementation. When shopping for applications, purchasers should be careful to specify not only the standards they require, but also their interoperability requirements, such as the CA�s whose certificates must work with an application. At the time of writing, current implementations of PKI are, unfortunately, still tightly integrated into the applications that use them. Of course, this has the advantage of seamless use for the user, but does little to foster interoperability, restricting the use of public key technology to the functions that can be performed by each individual application. It is still frustrating to note that it is often difficult to share keys between applications and the PKI functionality of the applications themselves are severely limited. Microsoft - in its client software - has certainly attempted to make life a little more straightforward when it comes to simple tasks such as moving a digital certificate and associated key pair from a PC at work to one at home. But some would argue that this simply opens an additional batch of potential security loopholes. It is the PKCS#12 standard which provides a way to move certificates, keys and passwords not only between applications, but between systems as well. However, even this is unsatisfactory, since it requires some knowledge and manual intervention on the part of the user in order to effect a secure transfer. Some PKI vendors have also taken matters into their own hands and provided tight integration between their PKI and popular desktop and server products such as Outlook and Exchange Server. Whilst this is a huge step forward, things are still moving too slowly to encourage widespread demand and adoption of PKI. Ultimately, we need to see widespread adoption of hardware tokens such as smart cards or cryptographic USB tokens that are capable of storing a users certificate(s) and key pairs in a single location. This provides the user with a straightforward means of transferring his or her digital identity from system to system � simply unplug the smart card from one reader and plug it onto another. Another unfortunate side effect of the hardwiring of PKI functionality is the issue of CA support. Checking in the security options of your browser will reveal a relatively short list of supported Certification Authorities, and adding support for new root keys requires touching every client in the enterprise. At the heart of every Public Key Infrastructure (PKI) is the Certification Authority, and the foundation of the CA is the Root Signing Key. The security of the Root Signing key is paramount, since it is used to sign all certificates issued by the CA itself. Thus, should the integrity of the Root Key ever legitimately be called into question, the certificates and CRLs issued by that CA would be suspect. At that point, the credibility of the CA itself is called into question, and in a live commercial environment that could have dire consequences. One of the main functions of a PKI is to verify the identity of its users, ensuring that they are who they claim to be. The primary use of the CA�s own digital signature is thus to provide non-repudiable proof of users� identities by binding their identity to their public key and signing it using its own private Root Signing Key - thus creating a digital certificate for the user. The signed digital certificate is undeniable proof to third parties that trust a particular CA that the user is who he represents himself to be. That trust of the CA is, of course, of vital importance. Without that trust, the digital certificates issued by a CA are worthless. The critical point of any security solution based on PKI is thus the Root Signing Key that the CA uses to sign its digital certificates. If this key is compromised, an intruder could forge certificates and use them to falsely represent himself to other users in the PKI (or other users who trust that particular CA). Once such a breach becomes public knowledge, the credibility of the CA, and of the company which operates it, is destroyed � perhaps forever. The compromise of a CA Root Key is one of the worst security breaches that can befall a company, and thus every possible precaution should be taken to ensure its protection. Clearly the security of the CA machine itself is of vital importance. It should be protected by layers of physical security such as locked doors, electronic surveillance, biometric devices to control access to specific personnel, and so on. However, whilst the CA Root Key is stored in software on the CA host server (the default state when PKI software is installed), it is still potentially vulnerable to a number of attacks: The Copy Attack: Here the attacker, having gained access to the CA host server, can copy the CA Root Key onto any unsecured media, such as floppy disk, smart card, or portable hard drive. If the location of the Root Key is not immediately obvious, attackers could simply copy the entire PKI directory structure, which can then be examined at leisure for hidden secrets. Having obtained the encrypted Root Key, various brute force attacks can be launched against it in an attempt to compromise the key. Providing the data theft is not discovered, once the key has been compromised, the attacker is free to masquerade as a bona fide user. Modification Attacks: An attacker could introduce hidden � or Trojan � software onto the host server which could monitor and record critical cryptographic traffic within the host PC. Although the cryptographic keys are themselves stored as encrypted data under a secure key, in many systems but they must be decrypted and transported as plain text into memory or registers that are used in the cryptographic process. Even if the keys are split, or �disguised� somehow, if registers are monitored for these values during the cryptographic calculations, it may be possible to reconstruct the keys. Another option would be for the Trojan software to modify the cryptographic algorithms themselves � perhaps forcing them to use the same key over and over again rather than change it for each session. Once the intruder can be assured that the system is using a single, never-changing key, it provides a larger window of opportunity to launch a brute force attack against that key. Equipment Theft: The most obvious attack of the three, possession of the server running the CA software will provide the attacker with the time to brute force attack the cryptographic secrets held on the hard drive. To be honest, there is little value in going on to extract the Root Key since it is highly likely that the theft will be noticed quickly and appropriate action taken. However, the damage has been done � once the Root Key is no longer in the possession of the organisation operating the CA, it calls the integrity of the entire PKI into question, and the only recourse is to invalidate all certificates issued by that CA and start again from scratch. Reputations will suffer as a result. For Certification Authorities, the concept of �trusted path� is a critical one. The Root Signing Key must be generated securely, using sound cryptographic principles and a true random number generator. Since the root signing key is the lynch pin to the entire PKI chain of trust it is important to only allow this key to be �live� inside of a trusted hardware device such as a Hardware Security Module. For disaster recovery purposes, any recovery keys should be split and stored securely at alternative sites, and finally the key must be securely entered into the CA�s signing engine. This provides complete preservation of the trust level of the CA key both inside and outside the cryptographic processing environment. A formal CA Root Key generation ceremony should be designed to help assure the non-refutability of the integrity of each CA�s Root Key pairs and, in particular, the private signing keys. This ceremony should be witnessed by an independent external auditor, and in cases where a PKI is used as an external business-to-business service, such a ceremony offers the assurance that certificates are generated and protected in a trusted and reliable way. The only way to preserve this trusted path completely is to permit the CA Root Signing Key to be live �in the clear� only inside a Hardware Security Module (HSM), which offers secure usage capabilities for cryptographic keys in an independent, tamper-proof environment. This device should be so constructed that no secret key is ever exposed in plain text outside the module, and also that the module itself is completely tamper proof. If secret keys need to be exported (for secure distribution or backup) then they should be securely encrypted and split into several parts, such that a compromise of an individual part will not reveal the original key. The standard to consider when acquiring an HSM is the Federal Information Processing Standard (FIPS) PUB 140-2, which was developed by the United States Department of Commerce's National Institute of Standards and Technology (NIST) and the Canadian Communication Security Establishment (CSE). NIST publishes and has editorial responsibility for the standard. FIPS PUB 140-2 defines eleven categories of security requirements and identifies one to four levels of security for each category. As the level increases, the security requirements become more stringent. For example, a product that meets a level 2 requirement provides more security assurance than a product that meets a level 1 requirement in the same category. Level 3 provides the highest level of protection in commonly available commercial products, and enforces such precautions as:
When it comes to implementing PKI, companies have the choice of using a public CA, operating a private CA, or using a public CA organisation to operate an outsourced private CA on their behalf. Where a managed solution is adopted, the internal CA is replaced with a local registration authority (LRA) that handles enrolment, authentication and key-pair generation for the outsourced CA component. The external CA then receives certificate requests from the LRA, issues, distributes and stores the certificates, and keeps the CRL up to date. Clearly the in-house approach provides the maximum level of control for an organisation, but the costs can be prohibitive when you realise that it is not just the software licenses and maintenance fees that need to be found, but enough money to purchase and deploy the entire supporting infrastructure too. The technical aspects of whether a company hosts its own CA or uses an outsourced service usually concern operational capacity:
If the answer to any of these questions is no, then the company should carefully weigh the costs of adding the necessary hardware, staff and infrastructure against the costs of outsourcing. Because of the mission-critical nature of the service associated with a Public Key Infrastructure, the competence of the end-user organisation to perform the critical operations correctly should be carefully considered. However, if the organisation�s IT unit has successfully demonstrated its ability to operate other vital systems, such as an accounting, billing or corporate messaging systems, then the issues encountered in operating a public key infrastructure in support of inter-organisational business processes should be familiar, and represent no unusual risk. There are points in favour of an in-house solution, of course, the main one being total control over what is a very sensitive area � there is often a great deal of nervousness displayed when it comes to outsourcing security of any kind. Also, if a public key infrastructure is required only to support confidentiality, integrity and authenticity services for the organisation�s own employees, then the considerations are much more relaxed, and there is no reason not to in-source the service. Bringing the operation in-house will ensure that interoperability problems between CA and corporate applications are eliminated, and the issue of CRL�s is greatly simplified. It also ensures that there is never the risk of breaching an outsourcer�s Certificate Practices Statement (CPS), either intentionally or otherwise. Consider the case of a �hybrid� outsourced service where certificates are signed by the company�s root signing key, which is turn signed with the outsourcer�s root signing key. What would happen if the outsourcer either intentionally (following a breach of the CPS) or unintentionally revoked the organisation�s root signing certificate? All the certificates issued by the organisation would then be instantly invalidated � and there is no way back following revocation. Once the problem had been resolved, the organisation would have to re-issue every single certificate to its users. While this may not be a big deal in a trial implementation, a year or so down the line in a live banking application it could present a single point of failure for the entire business. Unlikely? Maybe � but would you want to take the risk? Consequential damage resulting from a failure by the certificate issuing body can far outweigh any direct costs. Therefore, if the certification service is outsourced, the service provider must be covered by credible insurance for consequential damages, and it must be able to demonstrate that the insurance is continuously in-place. Simply entering into a contract with a provider which places liability on them is not sufficient, because it does not guarantee their ability to assume that liability for consequential damages in the event of failure. Causing the service provider to go out of business brings no satisfaction when the corporation�s critical systems have been compromised. In PKI, as with all security implementations, the issues of policy and procedure are crucial. In the world of PKI these issues are covered by two key documents, the Certificate Policy (CP) and the Certificate Practice Statement (CPS), which every PKI will have. It is here that the trust model the PKI supports is documented, and this is the one area which must be approached very carefully when considering an outsourced PKI. The CPS details the policies that govern the issuance of certificates, the level of security check performed to validate a certificate applicant�s identity, how long certificates remain valid, the rules that govern the revocation of certificates, and so on. The policies, responsibilities and liabilities defined in the CPS form the bedrock upon which a PKI is built. Importantly it outlines the warranty and liability issues that must be clearly understood and addressed by both those providing the service and those benefiting from it. The CPS is written by the �Issuing Authority�, one of the three �authorities� that form a fully working PKI. Most generic managed PKI solutions will attempt to force the customer into a �one size fits all� CPS. However, a single trust model will never adequately secure all applications, and whilst this approach may be valid for pilot projects, it is unlikely to provide adequate cover for a full-blown PKI. Bear in mind that an inadequate CP and CPS could well compromise your entire trust model, and the certificates issued against that CPS could be worthless. This is somewhat ironic, given that the vendor�s revenue stream is based on charging you for them! The only way it becomes acceptable to buy a PKI under these circumstances is if one of the �off-the-shelf� trust models on offer matches exactly the CPS that you hope to implement (or is so close that the vendor can be convinced to perform some upgrades to the software in order to reflect it). Even though you will still have to accept full liability, the chances of exposure to risk should, hopefully be minimised (given the appropriate nature of the trust model). However, such a scenario is highly unlikely and may deliver a technology that can handle only one of your trust models, making it impossible to leverage that technology investment as more applications seek PKI services. Although the outsourced approach is clearly cheaper, because vendors in this area have already made the necessary investment in hardware, software and staff, the ugly issue of liability raises its head. Will an outsourcing company take on the liability for failures? If the potential exposure to risk is too high they will almost certainly limit their liability to an agreed figure. At this point the customer must weigh up the cost of a full in-house implementation against the outsourced option and make an informed decision, based on possible losses against system costs. Whatever route is selected, it is vitally important to take responsibility for security policy at the outset, and make sure that there is a well thought CP and CPS in place as a result.. Deciding upon that policy is something only the customer can do. Of course there are numerous technology vendors who will be prepared to offer advice � perhaps for a fee, or perhaps as part of the sales process. Some will be more useful than others. One indication of how firmly they believe in their own advice will be the amount of liability they are willing to take for any failure in a security implementation that uses their products. It is essential that both parties understand clearly the levels of risk involved and their respective responsibilities. There are three separate roles involved in the provision of a PKI-based service. These are: Issuing Authority (IA) - the entity which defines the rules, liabilities and processes for a particular PKI. The IA is the author of the Certificate Practice Statement that governs the operation of the PKI. Registration Authority (RA) - the entity that authenticates individuals and organisations using documented and agreed procedures (performing ID and credit checks for example). The output from the RA is a list of individuals or organisations that �have clearance� to be issued with a proof of identity by the Certification Authority (CA). Certification Authority (CA) - the entity that creates and manages the certificates and associated directory, revocation and re-issuance processes on a day-to-day basis. It is important to note that the roles outlined above are �logical� in nature. Often there are no distinct �authorities� in place, rather a set of processes that fulfil a role. Often, PKI vendors will talk of the three authorities in a way that makes them appear separate to the organisation - some may try to sell software products that claim to be a �certification authority in a box� for example. It should be recognised that such an approach may be too simplistic for many organisations, since all three logical roles must be integrated into the real world of business and cannot be regarded as �islands of automation�. However, when it comes to making decisions about PKI implementations it is important to consider who will handle each of the roles of IA, RA and CA. Once again, some commercial PKI solutions can make assumptions about this, giving control of both the certificate policy and its management to a single entity, thus failing to identify the separate role of a policy maker � the �Issuing Authority�. This is because many PKI business models give control of the certification policy to the Certification Authority. Whilst this may seem sensible in some instances, it could be a dangerous practice in others. Brands are international reference points that shape society both at the corporate and the consumer level. Services to protect brand value and integrity, therefore, represent another important element in business confidence. It is a recognised fact that a company�s brand is its most valuable asset. Protecting an organisation�s brand online is, therefore, imperative. If the PKI provider you are using suffers a crisis of confidence, then so does your brand (after all, the certificate they have given your customers and suppliers represents you in cyberspace). If the certificates become questionable, so do you. Simply put, you are trusting the guardianship of your brand name to a third-party. Crucial to any decisions about a digital certificate policy is the answer to the question �who owns the CPS?� If someone else fulfils the role of Issuing Authority then that someone else has taken over some of the responsibility for your brand and there are inescapable restrictions to the usefulness of the certificates you are using. Given that �someone else� is unlikely to understand your business, or give it the priority you would, giving this level of control to them may not always be wise. Note that the brand implications can be very visible too. For example, when your customers view the certificates supposedly issued by you to them, do you want them to see your company name on there, or the name of the managed PKI vendor who is issuing the certificates on your behalf? The NSS Group has conducted the first comprehensive PKI test of its kind. This exhaustive review will give readers a complete perspective of the capabilities, maturity and suitability of the products tested for their particular needs. If a particular PKI has been designated as NSS Approved, customers can be confident that the product will provide the range of features and capabilities that are necessary for a large scale corporate PKI deployment. Click here to view the latest Public Key Infrastructure test report in full on-line |
Send mail to webmaster
with questions or
|