Public Key Infrastructure

Building Trusted Applications and Web Services

John R. Vacca

• Publisher: Auerbach Publications
• Year: 2004
• ISBN:
  9781135517038
• Edition: 1
• Topic: Ciencia de la computación
• Subtopic: Tecnología de la información

With the recent Electronic Signatures in Global and National Commerce Act, public key cryptography, digital signatures, and digital certificates are finally emerging as a ubiquitous part of the Information Technology landscape. Although these technologies have been around for over twenty years, this legislative move will surely boost e-commerce act

I
OVERVIEW OF PKI TCCHNOLOGY

Protecting the private keys that are tied to a digital certificate’s public key, especially those keys that are used to sign lower-level digital certificates, is very serious business under any PKI uses. Without this protection, the notion of any trust goes out the window and the infrastructure will inevitably fail.

Stolen (copied) private keys from any end entity could be used to transact or communicate without any cause for suspicion. It is the same as a stolen identity, where a thief masquerades as the legitimate key holder without any reason to suspect wrongdoing. Similarly, if the keys for a certificate authority (CA) are compromised, the repercussions could be severe. With a stolen (copied) CA key in hand, a would-be forger could issue bogus certificates without any way to detect the forgery. Protection of all CA keys is absolutely critical to maintain the PKI’s level of trust.

The more a private key is used to sign messages, the more instances a wouldbe attacker can obtain for cryptanalysis. If these keys are changed often and regularly, stored under North American Air Defense Command (NORAD)-like conditions, and managed well, they will remain safe from all forms of attack.

PKI cryptographic keys are extremely sophisticated in deterring would-be cryptosystem attackers. Because of its robustness, it is not really worth the effort to try breaking the cryptography. Even with all the computers on the planet working in tandem, an attacker would have a tough time trying to reverse-engineer or attempting brute-force methods (trying all possible combinations of a key) to determine the key. CAs will normally guard against such attacks anyway by using extremely long keys. They will also change their keys regularly and reissue new certificates whenever they do. Rather than try to discover the key, thieves are better off trying to steal the actual key from where it is stored, so extra precautions must be taken to ensure that this cannot happen. Because CAs clearly understand the value of the keys in their possession, they go out of their way to keep them safe from all possible attacks, both physical and logical.

Every end entity under a PKI is responsible for the safety of its own keys and certificates. This is a central theme and cannot be over-emphasized. A PKI’s ability to guarantee assurances of authentication, message integrity, privacy, and security cannot be realized once keys get into the wrong hands. Private keys are valuable. Although some are considered more valuable than others, that does not lessen the degree of care required for all keys at all times.

It is extremely important that the private keys of certifying authorities be stored securely. The compromise of this information would allow the generation of certificates for fraudulent public keys. One way to achieve the desired security is to store the key in a tamper-resistant device. This device should preferably destroy its contents if ever opened, and be shielded against attacks using electromagnetic radiation. Not even employees of the certifying authority should have access to the private key itself, but only the ability to use the private key in the process of issuing certificates.

If your private key is compromised—that is, if you suspect an attacker may have obtained your private key—then you should assume that the attacker can read any encrypted messages sent to you under the corresponding public key, and forge your signature on documents as long as others continue to accept that public key as yours. The seriousness of these consequences underscores the importance of protecting your private key with extremely strong mechanisms.

Digital IDs make use of a technology called public key cryptography. During the initial enrollment process for obtaining a digital ID, your computer creates two keys: one public, which is published within your certificate and posted within VeriSign’s (http://www.verisign.com) repository, for example; and, one private, which is stored on your computer. VeriSign does not have access to your private key. It is generated locally on your computer and is never transmitted to VeriSign. The integrity of your certificate (your “digital identification”) depends on your private key being controlled exclusively by you.

Caution: It is your responsibility to protect your private key. Anyone who obtains your private key can forge your digital signature and take actions in your name!

Digital certificates were created to overcome the general anonymity afforded by unsecured networks like the Internet, by providing a reliable and trustworthy proof of identity in much the same way as passports and driver’s licenses. Used in conjunction with modern Web browsers, e-mail software, and other applications, digital certificates (and the public key technology they are based on) offer the potential for ensuring secure electronic commerce and transactions over these networks. Like a passport without a photograph attached, a digital certificate stored in the usual manner on a PC hard drive is susceptible to compromise and fraudulent use; and before they can be widely accepted as proof of identity, a way must be found to protect them.

Consequently, protecting the private key is the single most important aspect of using digital certificates because if the private key becomes known to others, it is possible for them to assume that identity and engage in fraudulent use of the certificate. Most digital certificates today—and more importantly, their associated private keys—are simply encrypted with a password and stored on the owner’s PC hard disk drive where they may be vulnerable to attack either directly or through the network. The private key is vulnerable to many of the same password-related problems mentioned earlier, and several programs are available to either divert PC files or attack password mechanisms. Therefore, with the preceding in mind, you should:

Secure your private key.

Make sure your private key file is protected.

Store the key file in a directory that only you or authorized administrators have access to.

It is also important to know whether the file is stored on backup tapes or is otherwise available for someone to intercept. If so, you must protect your backups as much as you protect your server.

The private key protection solution works in concert with other PKI components to provide strong authentication for your Web-based content and applications. Users are issued a software-only smart card. The smart card contains the user’s credentials (the private key and the digital certificate) and is protected by a personal identification number (PIN). This technique is called cryptographic camouflage, and is used to protect a user’s private key. With this technique, the user’s private key is stored in the smart card and is camouflaged with the user’s PIN. To use the card, the user simply enters his PIN, which reveals the private key. However, when a hacker attempts to decrypt the key by entering an invalid PIN, he or she also gets back a plausible key. Unlike other password-protected key containers, the hacker has no way of detecting that the key he or she has decrypted is a decoy, because it looks structurally similar to a valid key.

The public key can be freely distributed without compromising the private key, which must be kept secret by its owner. Because these keys only work as a pair, an operation (e.g., encryption) done with the public key can only be undone (decrypted) with the corresponding private key, and vice versa. A digital certificate securely binds your identity, as verified by a trusted third party (a CA), with your public key.

Now, in cryptography, a private or secret key is an encryption/decryption key known only to the party or parties that exchange secret messages. In traditional secret key cryptography, a key is shared by the communicators so that each can encrypt and decrypt messages. The risk in this system is that if either party loses the key or it is stolen, the system is broken. A more recent alternative is to use a combination of public and private keys. In this system, a public key is used together with a private key.

In the unlikely event of a private key compromise, the effects differ, depending on which keys were stolen, who performed the theft, and what their motivation was. A user’s private key theft could occur if the user’s PC was stolen or was used by someone else. Although some form of an electronic wallet will store the keys and certificates (which are usually protected by a password), if a correct guess does open the e-wallet, the thief instantly assumes the identity of the authorized key holder. If the theft is not reported, message and transaction recipients are left with no other choice but to believe that they were performed in earnest. At certificate issuance time, users must be made aware of these consequences when they agree to the use policies before accepting their certificates.

The theft of a CA private key is a whole other matter. With the proper systems, a CA key thief could establish himself as a CA, ready to issue certificates. These forged certificates would be undetectable as forgeries and could be used without question.

When it comes to maliciously poking around a system or a network, finding encrypted data, and decrypting it, the movies make it look easy. However, according to cryptography experts, a massive grid of interconnected and powerful systems would be required to break today’s encryption algorithms in a timely fashion. Most bad guys do not have those kinds of resources. Even if they did, what sort of ciphertext would be...

Table of contents

• COVER PAGE
• TITLE PAGE
• COPYRIGHT PAGE
• DEDICATION
• FOREWORD
• ACKNOWLEDGMENTS
• INTRODUCTION
• I. OVERVIEW OF PKI TCCHNOLOGY
• II. ANALYZING AND DESIGNING PUBLICKEY INFRASTRUCTURES
• III. IMPLEMENTING PKI
• IV. MANAGING PKI
• V. APPENDICES