PKI is a comprehensive and general-purpose technology
supported by a large number of different applications. Here are brief descriptions of common ones
that
Authentication
for Web Applications
S/MIME
Email Signing and Encryption
Millions of people are PKI users without ever realizing it. Every time anyone uses an HTTPS secured web server connection, they are using a PKI server identity certificate in the SSL handshake. The purpose of this is so the server can assert its identity to the client in a verifiable manner. For example, it is important for Amazon customers to be sure it is really an Amazon server they are accessing before supplying their credit card number for an online purchase. Mail servers commonly use SSL, and virtually any socket-based client server application can use SSL for greater security (both encryption and increased assurance that the server is what it claims to be). VPN appliances can also use PKI server identity certificates to identify themselves to VPN clients.
Server applications commonly need to verify who their client is before they can show them sensitive information or do certain actions on their behalf. For example, customers expect their bank to verify their identity before allowing them to view account balances or transfer funds via an online application. This authentication is often accomplished using user names and passwords, but PKI provides an attractive alternative. SSL has the optional ability to require a client-side certificate before establishing a secure and encrypted connection. So a web server can require a valid client certificate before allowing an HTTPS connection to be established to it. Furthermore, during the connection establishment process, the server gains access to information in the client certificate, so it can identify the client and learn other information about it in the process. A big advantage of authentication using PKI is that the server does not need to have access to a database of user passwords. Users may still need to supply a password to unlock their private key in their certificate, but that password is stored and managed locally on the client. This is inherently more secure and easier to manage than server password databases.
Most current web servers have hooks for PKI authentication built in. See http://www.dartmouth.edu/~pkilab/pages/Web_Access_Control.html for details about how to set this up with Apache. Authorization is typically integrated into the web application itself and typically uses information from the client-side PKI certificate obtained from the HTTPS connection. Sometimes, just the information in the certificate is enough for the application to determine whether the user is authorized, and sometimes the application will consult other systems or databases to determine authorization. Two examples are documented in:
In this case, once the application has established identity of the user via SSL client-side certificates, it then consults with a Shibboleth server to see if this user is authorized via a federation to use the service in question.
This document shows how Oracle PL/SQL code can acquire the client-side certificate identity information so it can use this information for authorization decisions (possibly consulting separate databases) such as whether the user has an account or not or what parts of the service to allow them to access.
Servers can also make authorization decisions based on certificate information. For example, an institution’s certificates could identify employees’ departments. If Human Resources employees are allowed access to a system which the general population is not, then the system can permit or reject access based on this information in the certificate. We should note that authorization management generally requires more flexibility than this scenario gracefully allows. For example, what if a certain user from another department also needs access to the Human Resources database? Their department information in the certificate will not suffice now, or we need a more complex mechanism where they can have two departments which may confuse other issues. The PKI Lab and others are conducting research into the use of delegation and PKI attributes certificates in order to address authorization more generally, and in some cases it may make sense to main authorization role information in separate services.
In addition to its ability to establish user identity, PKI can digitally “sign” electronic documents. This consists of computing a hash value of the document’s contents and attaching an encrypted signature which contains the hash value. With PKI’s asymmetric keys, only the possessor of the private key for a certificate can do this signing operation just as each person is the only one who can put their written signature on a paper document. But anyone can verify the PKI digital signature and (by checking the hash value) that the document contents haven’t been modified using the certificate’s public key and appropriate software just as anyone can verify a written signature (although verification of written signatures is nowhere near as precise and conclusive as digital signature verification).
This capability enables paperless transactions requiring approvals from individuals. Approvers sign documents or forms electronically and forward them to the next step in the process. Signatures and document integrity can be checked and acted upon automatically and/or by a person with the right software. They can be signed once or by multiple individuals. As software improves and organizations learn to take advantage of this capability, digital signing promises significant cost and time savings and also improvement in reliability and security.
Here are two products
A product suite dedicated to signing which
Some VPN appliances can use client certificates to authenticate users. The Cisco VPN3000 series also has the ability to group users according to information contained in their certificates and give groups different access and privileges. This amounts to authorization in addition to authentication.
A link to a document about using Cisco VPN3000 series VPN concentrators with PKI authentication will appear in this space soon. J
It is very easy to spoof the sender fields in plain-text email, and frequently easy to “sniff” plain text email while in transmission (especially on an unencrypted wireless network). These factors open the door to all kinds of email fraud and thievery. A good way to think about plain-text email is it is like getting an unsigned postcard written in pencil. The mailman and others can easily read or even modify your message if they are in the right place while it is in transit, and you can’t even be sure it was written by the apparent sender. S/MIME email with encryption is more like a signed letter in a sealed envelop – nobody can read or modify it while it is in transit, and you are assured of who sent it by the signature.
PKI combined with the S/MIME standard allow users to verify whether email really came from the apparent source or not and to send and receive encrypted email, thereby thwarting these problems. Users obtain personal certificates with a private key and their email address and use private key operations to sign email messages and to decrypt messages sent to them. Others use the sender’s certificate and public key to verify their signature and to encrypt email before sending it. The asymmetric nature of PKI keys ensures that only the possessor of a personal certificate’s private key can sign S/MIME email, thus assuring that the email came from that individual. Likewise, only the possessor of the private key can decrypt email intended for that user and encrypted with their certificate’s public key, thus ensuring the confidentiality of that user’s email contents. S/MIME is getting significant interest and use in organizations affected by HIPAA and other privacy regulations, in industries with important business secrets, and in government agencies needing to ensure confidential communications. It should have general appeal to all users once it is sufficiently easy to use.
Using S/MIME email has interesting implications for mail servers. An additional feature it enables is the server can perform authentication/authorization operations based on S/MIME signatures. For example, it can only allow certain users to post to certain lists. If users want to send S/MIME encrypted email to a list, they have the problem that each recipient has a different public key which means the message needs to be encrypted differently for each user. A list server which is S/MIME enabled and maintains certificates with public keys for each user can automate this process, accepting the message encrypted with its own public key, decrypting it internally, and then re-encrypting it with each recipient’s public key as it forwards the message to each person on the list.
802.1x has a PKI authentication option and is part of an emerging standards-based solution to authenticate users to a wireless network and encrypt their data in a more secure fashion using WPA.
AOL’s AIM instant messaging application recently acquired PKI capabilities so its messages can optionally be digitally signed and encrypted. This protects the privacy of the messages and helps assure that the person on the other end of the conversation is who they claim to be.