 |
|
|
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 smartcards, 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. This is a small block of data which contains the user�s public key together with the a confirmation of authenticity from a third party in the form of that party�s digital signature. The 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. 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. Probably the best known public CA at the moment is VeriSign, though other systems are available such as IBM�s World Registry, GTE�s CyberTrust (now owned by Baltimore), and even the Royal Mail has established a PKI using Nortel�s Entrust technology. 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? In terms of electronic commerce, a potential customer � Alice - will first obtain a certificate from a trusted CA by providing proof of identity. 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 smartcard. In a pure Web model, 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 usually not want 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). Acme Computers checks Alice�s certificate on receipt, and because it has been signed by a trusted CA, the company knows it has a valid 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. Certificates based on the X.509 standard (the most commonly used type) incorporate an expiry date to ensure that certificates and their associated key pairs are renewed automatically after a given period of time. 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 your card). 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. This is done via a mechanism called the Certificate Revocation List (CRL). The issuing CA can revoke a certificate, thus preventing further use, by adding the serial number of the certificate to a CRL which is published at regular intervals. 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 would pay extra for twice daily, two hourly, or even hourly publication. Most CA�s also 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), which allows a client to request directly information regarding the validity of one or more individual certificates. This request is processed, answered and digitally signed � in real time � by a �responder�. 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 two 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. 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 smartcards, providing a truly portable and secure (providing you keep your smartcard safe) means of performing electronic transactions. 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 smartcard could be inserted into a reader of a virtual smartcard 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. In addition to standards that relate to certificates, there are several that incorporate the use of public key cryptography. These include SSL (web), S/MIME (e-mail) and SET (credit card transactions). When dealing with SSL it is important to note the version that is supported � version 3 supports client authentication, whereas version 2 does not. Digital certificates also provide the foundation for SET (Secure Electronic Transactions), a group of standards developed by Visa and MasterCard for Internet commerce, and supported by, for example, Terisa Systems, Microsoft, Netscape, IBM, American Express and VeriSign.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. Ultimately, we need to see widespread adoption of hardware tokens such as smartcards 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 smartcard 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 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 CRL�s 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, a backup Key created and stored securely in a trusted crypto module at an alternative site for disaster recovery purposes, 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 store the CA Root Signing Key in a Hardware Security Module (HSM), which offers secure storage capabilities for cryptographic keys in an external, tamper-proof environment. This module 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-1, 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-1 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 : No security object reuse within the device Tamper detection and response Physically separate ports for critical security parameters and other data items Use of NIST-approved cryptographic algorithms Positive identification and authentication of security officers Physical protection of all circuitry such that tampering results in total destruction of the contents. 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: Does the organisation have a 24 x 7 support capability? Does the expertise for security policy creation and management exist in-house? Do internal IT operations have staff who are qualified and capable of running a CA? Are physical security measures sufficient? Can the organisation guarantee the security and integrity of its root signing keys? Is the company equipped to handle registration of users to the required standard, particularly when physical registration is demanded by the environment or sensitivity of the applications? Can the company provide an adequate quality of service for the required number of digital ID users? Is the company better equipped, due to strategic advantage or core competence, to provide this service than a CA specialising in outsourcing? 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? In this section of the report we move from general PKI information to detailed evaluations of some of the market-leading products. For this important group test we invited a number of major vendors in the PKI market place. Eight agreed to take part: De La Rue InterClear ClearCert Vendors will also be encouraged to submit new releases for testing, thus allowing us to update this report at regular intervals and maintain an accurate appraisal of the PKI market place. Those of you who have been following the previous editions of this report will note that there are some newcomers to the test - and some surprising omissions.� The addition of InterClear to the fold allows us to divide this report into two sections � one dealing with in-house, software-only solutions, and one dealing with outsourced solutions. The participation of nCipher has allowed us to add a section on Hardware Security Modules (HSM), and we hope to expand this in future editions. BT/VeriSign and IBM both felt that they had not released any significant new versions since last they were tested, and those entries remain unchanged until those vendors choose to submit updated products for testing. Both Entrust and RSA submitted new product for testing in the software-only section, and Safelayer is a new addition to that section. We hope to test release 5 of Baltimore�s UniCERT product in the next edition of the report. If you would like to see a particular vendor included in this report, please let us (and the vendor) know. This report is currently the only source of comprehensive, yet completely independent technical evaluations of the leading products in the PKI arena, and is likely to become the definitive guide to the market place and a major source of information and advice to security professionals. Click here to return to Table of Contents
|
 |
Send mail to webmaster
with questions or�
|
