Public Key Cryptography Free Essays

string(201) " might encrypt a piece of information using the site’s public key and ask the web server to decrypt it, thereby demonstrating that the server has the right private key, and proving its identity\." Abstract- Public-key cryptography is a key technology for e-commerce, intranets, extranets and other web-enabled applications. However, to garner the benefits of public-key cryptography, a supporting infrastructure is needed. The Microsoft ® Windows ® 2000 operating system includes a native public-key infrastructure (PKI) that is designed from the ground up to take full advantage of the Windows 2000 security architecture. We will write a custom essay sample on Public Key Cryptography or any similar topic only for you Order Now This paper describes the fundamentals of public-key security systems, including what benefits they offer and what components are required to implement them. It also describes how the Windows 2000 PKI components deliver the needed services while providing interoperability, security, flexibility, and ease of use. I. Overview Public-key cryptography offers significant security benefits when it’s properly implemented. Like other enabling technologies, public-key cryptography requires an infrastructure to deliver its benefits. However, the public-key infrastructure, or PKI, isn’t a physical object or software process; instead, it’s a set of useful services provided by a collection of interconnected components These components work together to provide public-key-based security services to applications and users. This white paper has two goals: to explain public-key technology and its uses, and to describe the features and benefits provided by the native PKI in the Microsoft ® Windows ® 2000 operating system. Understanding both of these topics will help you to decide where you can use PKI technology to improve your business processes and increase your ability to securely handle transactions with others. In this paper, you’ll learn what a public key infrastructure is, what desirable benefits it can offer your operations, and how the Windows 2000 PKI delivers interoperability, security, flexibility, and ease of use. II. History During the early history of cryptography, two parties would agree upon a key using a secure, but non-cryptographic, method; for example, a face-to-face meeting or an exchange via a trusted courier. This key, which both parties kept absolutely secret, could then be used to exchange encrypted messages. A number of significant practical difficulties arise in this approach to distributing keys. Public-key cryptography addresses these drawbacks so that users can communicate securely over a public channel without having to agree upon a shared key beforehand. In 1874, a book by William Stanley Jevons[1] described the relationship of one-way functions to cryptography and went on to discuss specifically the factorization problem used to create the trapdoor function in theRSA system. Since the 1970s, a large number and variety of encryption, digital signature, key agreement, and other techniques have been developed in the field of public-key cryptography. The ElGamal cryptosystem (invented by Taher ElGamal) relies on the (similar, and related) difficulty of the discrete logarithm problem, as does the closely related DSA developed at the US National Security Agency (NSA) and published by NIST as a proposed standard. The introduction of elliptic curve cryptography by Neal Koblitz and Victor Miller independently and simultaneously in the mid-1980s has yielded new public-key algorithms based on the discrete logarithm problem. Although mathematically more complex, elliptic curves provide smaller key sizes and faster operations for equivalent estimated security. III. What is public key cryptography? When most people hear the words encrypt or cryptography, they immediately think of secret-key cryptography, wherein two parties share a single secret key that’s used both to encrypt and decrypt data. Loss or compromise of the secret key makes the data it encrypts vulnerable. By contrast, public-key systems use two keys: a public key, designed to be shared, and a private key, which must be closely held. These keys are complementary: if you encrypt something with the public key, it can only be decrypted with the corresponding private key, and vice versa. Public-key systems depend on the mathematical relationship between the public and private keys. It’s not feasible to derive one from the other. There are two fundamental operations associated with public key cryptography: encryption and signing. The goal of encryption is to obscure data in such a way that it can only be read by the intended party. In public-key cryptography, if Bob wants to send Alice some private data, he uses her public key to encrypt it, then sends it to her. Upon receiving the encrypted data, Alice uses her private key to decrypt it. The important concept here is that Alice can freely distribute her public key in order to allow anyone in the world to encrypt data that only she can decrypt. If Bob and Chuck both have copies of her public key, and Chuck intercepts an encrypted message from Bob to Alice, he will not be able to decrypt it; only Alice’s private key can do that, and she is the only person who holds it. These two operations can be used to provide three capabilities A Privacy Privacy is a necessity for businesses of all kinds, but it’s of vital importance for ones that use the Internet. The Internet allows anyone in the world to communicate with anyone else, but it doesn’t provide security. Even within your company’s internal network, if someone can gain physical access to your network media, they can eavesdrop on any data that traverses it. Public-key cryptography provides privacy via data encryption, whether the data is in the form of e-mail messages, credit card numbers sent over the Internet, or network traffic. Because public keys can be posted freely, complete strangers can establish private communications simply by retrieving each other’s public keys and encrypting the data. B. Authentication Any transaction involves two parties, whether they’re a client and a server or a customer and a vendor. For many transactions, it’s desirable for one or both sides to be able to authenticate, or verify the identity of, the other. For instance, before a customer provides their credit card number to an e-commerce web site, they will want to know that they are not talking to an imposter. One way that a customer can do this is by making the web site prove that it holds the right private key. For example, a web browser might encrypt a piece of information using the site’s public key and ask the web server to decrypt it, thereby demonstrating that the server has the right private key, and proving its identity. You read "Public Key Cryptography" in category "Papers" Authentication can also take the form of assuring your customers that you produced a particular piece of data and that it has not been tampered with. Public-key cryptography enables you to do this by means of a digital signature, a concept which is an extension of the public-key signing operation discussed above. If Bob wants to digitally sign his company’s annual report, he first generates a unique fingerprint of the report using an algorithm called a hash algorithm. Hash algorithms are specially designed to guarantee that even a single changed byte in the document will generate a completely different hash. Next, he encrypts the report and the hash using his private key. Alice (or anyone else) can verify the origin and authenticity of the signed report by first decrypting it using Bob’s public key, then calculating her own version of the fingerprint and comparing it to the fingerprint she received. If the two match, it proves two things: that the report has not been tampered with, and it came from Bob. C. Non-repudiation Businesses require the ability to enter into binding agreements, whether in the physical world or on the Internet. Suppliers and buyers need the assurance that if they enter into an agreement, the other party will not be able to repudiate the agreement at some later point. Digital signatures on electronic purchase orders, contracts, and other agreements are legally binding in several countries and in many U. S. states, and legal acceptance is rapidly growing. D. infrastructure Manage keys: a PKI makes it easy to issue new keys, review or revoke existing keys, and manage the trust level attached to keys from different issuers. Publish keys: a PKI offers a well-defined way for clients to locate and retrieve public keys and information about whether a specific key is valid or not. Without the ability to retrieve keys and know that they are valid, your users can’t make use of public key services. Use keys: a PKI provides an easy-to-use way for users to use keys—not just by moving keys around where they’re needed, but also by providing easy-to-use applications that perform public-key cryptographic operations, making it possible to provide security for e-mail, e-commerce, and networks. E. A capability,not a thing A common misperception is that a PKI is a thing. In fact, it’s a capability—the capability to easily publish, manage, and use public keys. Think of a PKI like a municipal water system. A water system is made up of purification plants, storage towers, pumps, water mains, and so on, as well as the pipes and faucets in your house. All of the disparate service-providing objects work together to provide a capability for users to obtain water on demand. In a similar way, a PKI consists of a group of discrete components that work together to allow you to use public keys, and public-key cryptography, seamlessly and transparently. The best place to implement a PKI is in the operating system. Operating systems already provide a number of other infrastructures, like the printing infrastructure that moves documents to printers and the file service infrastructure that retrieves files from shared storage. In both cases, the operating system provides a capability to transparently and easily use a network service, just as a PKI does. F. Digital certificates:packaging for public key So far, this paper has mentioned public keys when talking about the objects that a PKI uses. While public keys are required for PKI-based security, they’re usually packaged as digital certificates. (It’s important to stress that only public keys are packaged into certificates. The private key is never shared, so it doesn’t require packaging—it’s simply stored securely). The certificate contains the public key and a set of attributes, like the key holder’s name. These attributes may be related to the holder’s identity, what they’re allowed to do, or under what conditions the certificate is valid. The binding between attributes and the public key is present because the certificate is digitally signed by the entity that issued it; the issuer’s signature on the certificate vouches for its authenticity and correctness. For a real-world analogy, look in your wallet. If you have a drivers’ license, you have the equivalent of a digital certificate. Your license contains a unique key (your license number) and some attributes (an expiration date, your name, address, hair color, and so on). It’s issued by a trusted agency and laminated to prevent it from being tampered with. Anyone who trusts the agency that issued your license and verifies that the lamination is intact can rely on its authenticity. At that point, though, the analogy breaks down—in the real world, only the government can issue a driver’s license, so everyone knows that a license issued by Joe’s Really Good DMV isn’t valid. How do you make the same determination with a digital certificate? The answer lies in the concept of a certificate hierarchy. In a hierarchy, as shown in Figure 1, each issuer, or certificate authority, signs (using its own private key) the certificates it issues. The public half of the CA’s keypair is itself packaged in a certificate—one that was issued by a higher-level CA. This pattern can continue through as many levels as desired, with each CA certifying the authenticity of the certificates it has issued. Eventually, though, there must be a top-level CA, called a root certificate authority. Since there’s nobody above the root CA in the hierarchy, there’s nobody to vouch for the authenticity and origin of its certificate. Instead, the root CA signs its own certificate—it simply asserts that it is the root. Figure 1: What a certificate hierarchy looks like Clearly, it’s not secure to accept a root CA’s assertion of its own identity. To verify a root CA’s certificate, a trusted copy of its public key is obtained via an out-of-band method-—that is, it’s delivered by a third party instead of over the network—and the key is used to verify that the root certificate is bona fide. Microsoft provides the public keys for many popular root CAs in PK-enabled products like Internet Explorer, allowing users to verify those roots transparently. Root CAs can also provide copies of their public keys for downloading from public web sites. Once the root key has been delivered via an out-of-band means, the user can verify the root certificate, and hence the entire certificate chain. Even better, because each certificate’s digital signature protects it from tampering, certificate chains can be freely passed over insecure media like the Internet. G. Public key enabled application Once your PKI can issue, publish, and control certificates, the next step is to deploy applications that can use them. A well-written application that is tightly integrated with the rest of the PKI can make the use of public-key cryptography all but transparent to the user. The user should not need to know how cryptography works, where certificates are stored, or any of the other details—they should simply indicate what they want done, and leave it to the applications and the PKI to make it happen. Applications can use digital certificates to deliver the benefits of public-key cryptography, and they can combine cryptographic functions like signing and encryption to make possible e-commerce, secure network access, or other desirable services. All Microsoft applications that use public-key cryptography are natively public-key enabled. For example, the Microsoft Outlook ® messaging and collaboration client offers built-in signing and encryption support, combined with the ability to use certificate publishers and root certificates from a number of sources. Internet Explorer, Microsoft Money, and Internet Information Server provide the ability to set up encrypted web sessions. PKI-enabled applications can build on industry-standard protocols to speed development and allow easy interoperability with other organizations, too. H. Hardware support The increasing market demand for PKI implementations has spurred hardware vendors to develop cryptographic hardware, including smart cards, PC cards, and PCI cards that offer onboard cryptographic processing. These hardware devices offer a wide range of capabilities. On the low end, smartcards offer limited cryptographic processing combined with secure key storage; on the high end, multiprocessor crypto-accelerators allow high-volume web services to secure data without suffering from bottlenecks caused by software cryptographic modules. The best thing about PKI hardware devices is that they’re optional—if your application requires additional performance or security, you can add hardware to provide it as necessary, but you can still build a completely functional PKI in software. I. Models The standalone CA model The standalone CA model (see Figure 2) is probably familiar to you if you’ve used SSL-protected web sites. In the standalone model, some third-party entity holds the root key and certificate for your organization, and it issues and revokes all certificates for your users. This third party might be a commercial CA like VeriSign, Thawte, Belsign, or GTE Cybertrust; it could also be a bank, a law firm, a trade association, or any other organization that you trust to issue certificates on your behalf. Figure 2: The standalone CA model This model allows trust both within and outside your organization, so you can exchange secure e-mail and e-commerce transactions with outsiders. Standalone CAs also free you from the complexities of issuing, revoking, and tracking certificates. However, it requires you to trust some outside entity with your certificate management, and many third-party CAs levy an individual charge for each issued certificate. The enterprise CA model In this model (see Figure 3), your enterprise acts as its own CA, issuing and revoking certificates subject to your business requirements. Because no outsourcing provider is involved, your organization maintains complete control over its PKI. In addition to that control, though, you can guarantee that no one outside the enterprise can obtain a certificate unless you issue it to them. This model works well for controlling access to internal resources, or for generating certificates whose attributes would be meaningless to an outside entity. For example, you could issue certificates to managers that would allow them to make electronic travel reservations through the company travel office. Figure 3: The enterprise CA model Enterprise CAs with subordinates You can expand the flexibility of the enterprise CA model by adding subordinate CAs for individual departments, business units, or subdivisions of the organization. Most organizations already delegate some amount of administrative control to their subunits. For example, individual managers at most companies have some level of purchasing authority; higher-ranking managers can write bigger checks. Even though there’s a centralized purchasing department that does much of the enterprise-wide buying, individual units still have the ability to perform day-to-day purchasing tasks. Choose your trust model If the choice of a CA model is the most important one you face when implementing a PKI, choosing a trust model comes in a very close second. When you trust a root, you’re making an implicit statement that you trust them to be careful about who they issue certificates to. In this case, careful isn’t quite the right word; what you’re really saying is that you trust them to follow their prescribed policies and procedures to verify the identity of a certificate holder when they issue the certificate. When you choose to trust a root certificate, you’re also choosing to trust certificates signed by that root. Depending on the CA model you use, the practical impact of this choice could be large (as when you choose to trust a large, widely used commercial root CA) or small (like deciding to trust your own accounting department). Normally these decisions are made for the enterprise as a whole; however, the Windows 2000 PKI allows individual users (or their administrators) to make their own trust decisions. In addition, administrators may override or augment user trust decisions with group policies. You also have to choose what you trust certificates to be used for. The X. 509 v3 certificate standard allows you to specify whether certificates can be used for signing, encryption, or both. For example, you might want to give everyone signature certificates but restrict the use of encryption-capable certificates to certain departments or individuals. Microsoft has extended this feature to allow you to specify additional uses, including signing software components, logging on using a smart card, or recovering an encrypted file. When using the Windows 2000 PKI, the issuer has total control over what the certificate can be used for. IV Conclusion Public key cryptography offers critical business advantages, including the ability to conduct e-commerce and normal business operations with increased privacy, security, and assurance. To deliver these benefits, a public-key infrastructure is necessary that makes it easy to manage, publish and use public keys. Windows 2000 offers a PKI that is completely integrated with the operating system and provides flexible, secure, interoperable services that are easy to use, easy to deploy, and easy to manage. References N. Ferguson; B. Schneier (2003). Practical Cryptography. Wiley. ISBN 0-471-22357-3. J. Katz; Y. Lindell (2007). Introduction to Modern Cryptography. CRC Press. ISBN 1-58488-551-3. J. Menezes; P. C. van Oorschot; S. A. Vanstone (1997). Handbook of Applied Cryptography. ISBN 0-8493-8523-7. IEEE 1363: Standard Specifications for Public-Key Cryptography Single Sign-On Technology for SAP Enterprises: What does SAP have to say? [1] ^ Ed Gerck, Overview of Certification Systems: x. 509, CA, PGP and SKIP, in The Black Hat Briefings ’99, http://www. securitytechnet. com/resource/rsc-center/presentation/black/vegas99/certover. pdf andhttp://mcwg. org/mcg-mirror/cert. htm ^ Stephen Wilson, Dec 2005, â€Å"The importance of PKI today†, China Communications, Retrieved on 2010-12-13 ^ Mark Gasson, Martin Meints, Kevin Warwick (2005), D3. 2: A study on PKI and biometrics, FIDIS deliverable (3)2, July 2005 How to cite Public Key Cryptography, Papers