Asymmetric key cryptography enables secure end to end communications using public-private encryption key pairs. Given knowledge of a recipient's public key, a sender can encrypt information in such a way that only the recipient who possesses the corresponding private key may decrypt and view that information. Public keys convey no information that will compromise the confidentiality of the transmission and may be freely shared with anyone. In contrast, private keys must never be shared. The obvious advantage of this system over symmetric key cryptographic systems is that secrets (e.g. passwords or keys) need not be shared between the sender and recipient in order to communicate privately.
To enable asymmetric key cryptography, the following is generally required: (i) the public key must be widely known or available, and (2) the identity associated with a public-private key pair must be trusted. A key certificate encapsulates identity information and binds it to a specific public-private key pair and a Certificate Authority (or CA) asserts the validity of this information. The validity of a given CA may in turn be asserted by another CA and the result is a hierarchical chain of trust that ends with a Root Certificate Authority, the trust of which is asserted by an alternate but definitive source of authority (e.g. MICROSOFT® asserts the validity of Root Certificate Authorities installed on Windows based computers). If the Root CA is trusted and all intermediate CAs are valid then the identity described by the original certificate is valid and the public-private key pair may be trusted. The term Public Key Infrastructure, or PKI, is used to describe the set of technologies needed for distributing and sharing certificates (and public keys) and asserting and verifying the validity of the identity in certificates bound to public-private key pairs.
Asymmetric key cryptography enables assertion and verification of identity in PKI through the use of digital signatures. A digital signature is created by encrypting with a private key instead of a public key; signature verification is performed by decrypting with the public key. Digital signatures preclude forgery and ensure authenticity as a result of two key premises: (1) public-private key pairs are unique and have one to one correspondence—for a given private key there exists only one matching public key and vice versa; (2) cryptographic hash functions used in creating digital signatures (e.g. SHA-256) create very good random numbers. For example, to sign and validate a certificate a CA first hashes the contents of the certificate and encrypts the result with its own private key to create a signature. A system wishing to verify the authenticity of the certificate decrypts the signature with the CA's public key and compares the result to a recomputed hash. If the decrypted signature matches the recomputed hash then the signature is valid and the certificate contains the information the CA intended. Forgery is not practically possible because (1) only the corresponding public key will correctly decrypt the signature for a given private key and (2) guessing the private key is hard because the data that's actually encrypted/signed (the result of the hash) is highly random and consequently, very little information about the private key is exposed even if many signatures are available for analysis.
Digital signatures are also used to bind a certificate to a specific public-private key pair. A request for a certificate includes the requestor's identifying information as well as its public key and the whole structure is signed by the requestor's private key. This signature binds the requestor's identity to its public-private key pair-only the possessor of the private key corresponding to the public key in the request could have signed the request. The CA verifies the requestor's signature and identity information, then creates a certificate from this identity information and the requestor's public key and signs the whole structure with its private key. Now, if the CA is trusted then the identity information in the certificate is trusted and known to correspond to one public-private key pair.
One implicit requirement in PKI systems is that the underlying functional components (e.g. hardware or software) that rely on the certificates and keys to perform cryptographic operations must ensure that certificates and the corresponding public-private key pairs are valid before using them. This is usually done by verifying the content and signature of each certificate in a chain of certificates up to a trusted Root Certificate before performing any operation or relying on a result.
PKI, in its entirety, is a complex technology, and solutions designed to manage this complexity are equally complex and consequently difficult to use and maintain. To encapsulate this complexity, PKI is typically managed separately from the applications that use it. Furthermore, applications that utilize PKI to send and receive encrypted confidential information are difficult to configure. As a result, the powerful combination of these technologies is out of reach for individuals and small business that lack the technical sophistication or resources.
PKI, on a large scale, with its hierarchies and chains of trust can enable secure and trusted communication between a large number of people, machines and services. For example, many online banking sites utilize PKI to manage their customer interactions, such as bill payment or security trades. In some European and Asian countries, government entities issue digital identities to their citizens and enable them to use online services such as filing tax returns that require strong, two-factor authentication. At a large scale, when all of the components are in place and well managed and maintained, PKI works relatively well.
Other data security infrastructures have included Rights of Management Service. Such technology controls access to information embedded in specific documents. In general, the author of a document provisions the recipient's rights to access the information before sending the document and when the recipient attempts to view the document it must first prove its identity to the Rights Management Service before access is granted. Such systems are bound to specific application and document types and like PKI, access rights and policies are typically managed separately from the applications that use them.