Public key infrastructure: Difference between revisions
No edit summary |
No edit summary |
||
Line 52: | Line 52: | ||
* ''[[CoSign]]'' - A built-in CA, leveraging existing user directory management systems (e.g. [[Active Directory]], [[Novell eDirectory]] and [[Lightweight Directory Access Protocol|LDAP]]). The solution automatically generates digital certificates for users on the user directory, eliminating the common overhead found with other traditional PKI solutions. |
* ''[[CoSign]]'' - A built-in CA, leveraging existing user directory management systems (e.g. [[Active Directory]], [[Novell eDirectory]] and [[Lightweight Directory Access Protocol|LDAP]]). The solution automatically generates digital certificates for users on the user directory, eliminating the common overhead found with other traditional PKI solutions. |
||
* ''[[Linux]]'': Linux supports [[OpenSSL]] and [[OpenCA]], which are two [[open source]] CA solutions. |
* ''[[Linux]]'': Linux supports [[OpenSSL]] and [[OpenCA]], which are two [[open source]] CA solutions. |
||
* ''[[EJBCA]]'': [[open source]Open source], [[Platform_independent]platform independent], feature-rich, fully [[Computer_cluster]clusterable] [[Certificate_authority]CA] solution implemented in [[Enterprise_Java]Enterprise Java]. |
|||
* ''[[NEWPKI]]'': Free software which generates and controls users' public keys. |
* ''[[NEWPKI]]'': Free software which generates and controls users' public keys. |
Revision as of 08:33, 29 April 2008
This article's use of external links may not follow Wikipedia's policies or guidelines. |
In cryptography, a public key infrastructure (PKI) is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA). The user identity must be unique for each CA. The binding is established through the registration and issuance process, which, depending on the level of assurance the binding has, may be carried out by software at a CA, or under human supervision. The PKI role that assures this binding is called the Registration Authority (RA) . For each user, the user identity, the public key, their binding, validity conditions and other attributes are made unforgeable in public key certificates issued by the CA.
The term trusted third party (TTP) may also be used for certificate authority (CA). The term PKI is sometimes erroneously used to denote public key algorithms, which do not require the use of a CA.
Purpose and functions
PKI arrangements enable computer users without prior contact to be authenticated to each other, and to use the public key information in their public key certificates to encrypt messages to each other.[1] In general, a PKI consists of client software, server software, hardware (e.g., smart cards), legal contracts and assurances, and operational procedures. A signer's public key certificate may also be used by a third-party to verify the digital signature of a message, which was made using the signer's private key. In general, a PKI enables the parties in a dialogue to establish confidentiality, message integrity and user authentication without having to exchange any secret information in advance, or even any prior contact. The validity of a PKI between the communicating parties is, however, limited by practical problems such as uncertain certificate revocation, CA conditions for certificate issuance and reliance, variability of regulations and evidentiary laws by jurisdiction, and trust.[2] These problems, which are significant for the initial contact, tend to be less important as the communication progresses in time (including the use of other communication channels) and the parties have opportunities to develop trust on their identities and keys.[2]
Typical use
Most enterprise-scale PKI systems rely on certificate chains to establish a party's identity, as a certificate may have been issued by a certificate authority computer whose 'legitimacy' is established for such purposes by a certificate issued by a higher-level certificate authority, and so on. This produces a certificate hierarchy composed of, at a minimum, several computers, often more than one organization, and often assorted interoperating software packages from several sources. Standards are critical to PKI operation, and public standards are critical to PKIs intended for extensive operation. Much of the standardization in this area is done by the IETF PKIX working group.
Enterprise PKI systems are often closely tied to an enterprise's directory scheme, in which each employee's public key is often stored (embedded in a certificate), together with other personal details (phone number, email address, location, department, ...). Today's leading directory technology is LDAP and in fact, the most common certificate format (X.509) stems from its use in LDAP's predecessor, the X.500 directory schema.
Alternatives
Web of Trust
An alternative approach to the problem of public authentication of public key information across time and space is the web of trust scheme, which uses self-signed certificates and third party attestations of those certificates. Speaking of the Web of Trust does not imply the existence of a single web of trust, or common point of trust, but any number of potentially disjoint "webs of trust". Examples of implementations of this approach are PGP (Pretty Good Privacy) and GnuPG (The GNU Privacy Guard; a free implementation of OpenPGP, the standardized specification of PGP). Because PGP and implementations allow the use of email digital signatures for self-publication of public key information, it is relatively easy to implement one's own Web of Trust.
One of the benefits of the Web of Trust, for example in PGP, is that it can interoperate with a PKI CA fully-trusted by all parties in a domain (such as an internal CA in a company) that is willing to guarantee certificates, as a trusted introducer.[2]
Simple public key infrastructure
Another alternative, which however does not deal with public authentication of public key information, is the simple public key infrastructure (SPKI) that grew out of 3 independent efforts to overcome the complexities of X.509 and PGP's web of trust. SPKI does not bind people to keys, as the key is the principal -- the one that "speaks".[clarification needed] SPKI does not use any notion of trust, as the verifier is also the issuer. This is called an "authorization loop" in SPKI terminology, where authorization is integral to its design.
Additionally, PKI supports message encryption and digital signatures that further enhance transactional security. While essential services such as certificate validation and revocation, key backup and recovery, and simultaneous update of key pairs minimize the administrative workload for a PKI infrastructure, features such as audit of key history and time-stamping enhance security control and management. And last but not least, the PKI infrastructure supports cross-certification, which is key to creating a truly federated identity by enabling seamless integration among circles of trust.
This article contains content that is written like an advertisement. (December 2007) |
In comparison to Kerberos, PKI provides enhanced security, greater scalability and easier administration, control and management of the infrastructure. As a result, PKI enables a larger community of users, consumers and partners to communicate and transact more dynamically, securely, reliably and cost-effectively.
History
The public disclosure of both secure key exchange and asymmetric key algorithms in 1976 by Diffie, Hellman, Rivest, Shamir, and Adleman changed secure communications entirely. With the further development of high speed digital electronic communications (the Internet and its predecessors), a need became evident for ways in which users could securely communicate with each other, and as a further consequence of that, for ways in which users could be sure with whom they were actually interacting.
Assorted cryptographic protocols were invented and analyzed within which the new cryptographic primitives could be effectively used. With the invention of the World Wide Web and its rapid spread, the need for authentication and secure communication became still more acute. Commercial reasons alone (e.g., e-commerce, on-line access to proprietary databases from Web browsers, etc.) were sufficient. Taher ElGamal and others at Netscape developed the SSL protocol ('https' in Web URLs); it included key establishment, server authentication (prior to v3, one-way only), and so on. A PKI structure was thus created for Web users/sites wishing secure (or more secure) communications.
Vendors and entrepreneurs saw the possibility of a large market, started companies (or new projects at existing companies), and began to agitate for legal recognition and protection from liability. An American Bar Association technology project published an extensive analysis of some of the foreseeable legal aspects of PKI operations (see ABA digital signature guidelines), and shortly thereafter, several US states (Utah being the first in 1995) and other jurisdictions throughout the world, began to enact laws and adopt regulations. Consumer groups and others raised questions of privacy, access, and liability considerations which were more taken into consideration in some jurisdictions than in others.
The enacted laws and regulations differed, there were technical and operational problems in converting PKI schemes into successful commercial operation, and progress has been far slower than pioneers had imagined it would be.
By the first few years of the 21st century, it had become clear that the underlying cryptographic engineering was not easy to deploy correctly, that operating procedures (manual or automatic) were not easy to correctly design (nor even if so designed, to execute perfectly, which the engineering required), and that such standards as existed were in some respects inadequate to the purposes to which they were being put.
PKI vendors have found a market, but it is not quite the market envisioned in the mid-90s, and it has grown both more slowly and in somewhat different ways than were anticipated. PKIs have not solved some of the problems they were expected to, and several major vendors have gone out of business or been acquired by others. PKI has had the most success in government implementations; the largest PKI implementation to date is the Defense Information Systems Agency (DISA) PKI infrastructure for the Common Access Cards program.
PKI software
When deploying a PKI, the most important part is an appropriate CA software. There are several solutions on the market:
- Microsoft: Windows 2000 Server and Server 2003 both contain CA software, which is integrated into the Active Directory and doesn't require additional license fees. This is currently the most popular solution on the market.[citation needed]
- OpenTrust: Offers a product called OpenTrust-PKI.
- CoSign - A built-in CA, leveraging existing user directory management systems (e.g. Active Directory, Novell eDirectory and LDAP). The solution automatically generates digital certificates for users on the user directory, eliminating the common overhead found with other traditional PKI solutions.
- Linux: Linux supports OpenSSL and OpenCA, which are two open source CA solutions.
- EJBCA: [[open source]Open source], [[Platform_independent]platform independent], feature-rich, fully [[Computer_cluster]clusterable] [[Certificate_authority]CA] solution implemented in [[Enterprise_Java]Enterprise Java].
- NEWPKI: Free software which generates and controls users' public keys.
- Novell: Offers the Novell Certificate Server, which is integrated into the eDirectory. Alternatively, the eDirectory add-on product cv act PKIntegrated (provided by a third party vendor at additional costs) can be used.
- GlobalSign: Offers TrustedRoot" a PKI CA Rootstore chaining program (Root Sign) which allows you to get immediate trust for your SSL, S/MIME and code signing certificates by chaining your Microsoft CA or Inhouse CA Root Certificate to the pre-trusted GlobalSign root certificate.
- Entrust: The product Entrust Authority is the most popular among the not-for-free CA solutions.[citation needed] Entrust offers PKI software and a managed service options mainly in the .gov space.
- CyberTrust: Offers a product calledTrustedCA.
- RSA Security: Offers a product called Keon.
- Cryptomathic: Offers a product called CCA.
- openWebPKI: open source PKI Web GUI project.
- Red Hat Certificate System: Formerly the Netscape Certificate Server.
- ChosenSecurity: Offers a managed PKI for the enterprise using TC TrustCenter technology.
- IdenTrust: Offers a managed PKI for the banking community.
- IBM: Offers PKI Services for z/OS.
- Safelayer: Offers a family of products called KeyOne and a PKI-broker called TrustedX.
- Operational Research Consultants, Inc.: Offers Federally compliant managed PKI services for Government-to-Government, Business-to-Government, and Citizen-to-Government trusted transactions.
Usage examples
PKIs of one type or another, and from any of several vendors, have many uses, including providing public keys and bindings to user identities which are used for:
- Encryption and/or sender authentication of e-mail messages (e.g., using OpenPGP or S/MIME).
- Encryption and/or authentication of documents (e.g., the XML Signature [1] or XML Encryption [2] standards if documents are encoded as XML).
- Authentication of users to applications (e.g., smart card logon, client authentication with SSL).
- Bootstrapping secure communication protocols, such as Internet key exchange (IKE) and SSL. In both of these, initial set-up of a secure channel (a "security association") uses asymmetric key (a.k.a. public key) methods, whereas actual communication uses faster secret key (a.k.a. symmetric key) methods.
See also
- Public key cryptography
- Public key certificate Certificates and Web Site security
- Key authentication
- Certificate revocation list
- Certification path validation algorithm
- Microsoft CAPI
- FIPS 201 PIV (Personal Identity Verification of Federal Employees and Contractors)
- PKCS Public Key Cryptography Standards
- Robot certificate authority
- Wireless Public Key Infrastructure
- Federation for Identity and Cross-Credentialing Systems (FiXs)
References
- ^ To decrypt, each user has their own private key, that is usually protected by a password and stored locally.
- ^ a b c 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 and http://mcwg.org/mcg-mirror/cert.htm
External links
- PKI tutorial by Peter Gutmann
- PKI Tutorial using Fingerpuppets
- PKIX workgroup
- Easing the PAIN — a detailed explanation of PKI Privacy, Authentication, Integrity and Non-repudiation (PAIN)
- NIST PKI Program — in which the National Institute of Standards and Technology (NIST) is attempting to develop a public key infrastructure
- What is a PKI (Entrust FAQ)?
- Detailed overview of Entrust v5 from Luke O'Connor
- Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure by C. Ellison and B. Schneier