Identity certificates
Currently there are three certificates involved in each secure Web transaction.
- Server certificate: Attests to the identity of the Web server owner.
- Client certificate: Attests to the identity of the Web user (customer).
- Certificate authority certificate: Attests to the identity of the certificate authority (CA) that signed the server and client certificates.
In principal, there is a root CA certificate that is self signed and that everyone trusts. If the root CA certificate is compromised, the whole certificate structure falls apart. It is perhaps a philosophical issue, but the original goal of a certificate authority hierarchy, which would allow each certificate to be traced up to the root CA, was never established because the notion of an identity does not scale well. In a small community, everyone knows everyone else so the binding of a name to an identity is not difficult. However, if your friend John Smith moved to New York City, it will be very difficult to know which John Smith in the telephone book is your friend. Fortunately, the SensorNet community is smaller and most users will have government-issued credentials to vouch for their identities, so we can be confident of identities. For SensorNet, less formal measures are called for. SensorNet is its own root CA and has self signed the SensorNetCA certificate (in the name of SensorNet). Due care is taken to keep the CA computer backed up and locked up in a secure location. This is the correct thing to do because for our purposes, we trust ourselves more than we trust an external CA such as VeriSign.
The format for identity certificates is spelled out in the PKI (public key infrastructure) specifications called X.509. Currently, the certificates we issue correspond to the latest, version 3 specification. These certificates bind an identity in the real world to a public key. For our purposes, our unique identity is specified by what is called a distinguished name (DN) which is composed of a person's real name, country, organization, organizational unit, city, state, and e-mail address. However, since certificates can also be issued to computers and other non-human entities, the notion of an identity is actually broader and fuzzier than might be ideal. An X.509v3 certificate allows a certificate holder to create a digital signature, to use the keys for encryption, to create S/MIME e-mail, and to sign trusted objects (e.g., Active-X controls). These privileges are actually delegated separately by different bits in the certificate's extensions. The contents of my SensorNet certificate show that I can use my certificate as an SSL client, for secure E-mail, and for object signing.
Uses of identity certificates
Once you have an identity certificate, what good is it? Here are some of the things you can do with your certificate:
Secure Web access
Identity certificates allow user-friendly, secure access to a Web site with strong authentication. Modern Web servers (Netscape, IIS, Apache) can all be set up to require client certificates for site access. Out of the box, it is trivial to configure the server to accept only SensorNet certificates, so that anyone with a valid SensorNet certificate will be authenticated securely and can use SSL for secure access. No user ids and passwords are required. However, once per browser session, the user will have to unlock his private certificate key with a local password. The SensorNet CA web site is set up this way on a Tomcat server.
Access to a site can also be controlled by using "basic" authentication ? user ids and passwords. There are several problems with this approach. The biggest problem is that this solution does not scale well. If a new user is added and we used basic authentication, we would have to enroll the user separately at each server. Then there is the problem of allowing the user to securely set his password on each of these machines, especially if you do not want to give the user a login account on the machine (an invitation to a security breach). With SensorNet issued certificates, new users are automatically granted access to all SensorNet sites requiring certificates for access.
Passwords also present several security problems. If the host computer gets hacked, the (hashed) password file may become compromised (thus allowing offline brute force attacks) requiring that all users get new passwords. This has proved to be a logistical problem. Passwords can be easily sniffed if the user's computer gets hacked, and good passwords are hard to remember and thus get written down on stickys attached to the computer for all to see. There is also generally no restriction to the number of times that a password-based Web access pop up can fail (or else there could be easy denial of service attacks). Therefore, access via user id and password is subject to password guessing attacks.
Digital signatures
Client certificates allow users to sign things, solving the authenticity security requirement. It is very easy to spoof E-mail, so it is good practice to sign all electronic communications. The PGP community has been routinely signing all their mail for years, but I feel that the X.509 solution scales better and more user friendly than PGP.
PGP uses identity certificates also. However, PGP certificates are not signed by a CA. They are signed by your friends and acquaintances, or other people who vouch for your identity. This is called the "web of trust" model. X.509 certificates are signed by a CA that presumably you trust. There is much less baggage associated with X.509 because you do not have to go to key signing parties to get your PKI key well validated -- That is the function of the CA.
Digital signatures
Your public key is your cyber identity. It can be used in other contexts to grant you authority to do things. The concept of authority certificates is the basis for the SPKI (simple public key infrastructure) that is currently in an IETF draft. See http://theworld.com/~cme/html/spki.html. Provided that you can access your private key to unlock your certificate (to prevent spoofing), extremely complicated security policies can be implemented using a collection of authorization certificates.
S/MIME e-mail
S/MIME is a specification for secure electronic messaging. In 1995, several software vendors got together and created S/MIME to solve a very real problem -- interception and forgery of e-mail. Protecting sensitive data is a real concern, especially in a world that is becoming increasingly more wired. The goal of S/MIME is to make it easy to secure messages from prying eyes. Since its creation, S/MIME has come a long way. Most mail clients support S/MIME encrypted and signed e-mail. All of the major industry players have also agreed to support the S/MIME standard. Again, sending secure e-mail is like practicing safe sex - you need to do it. Yes, not everything you send needs to be encrypted. However, it is very easy to intercept e-mail and to modify it. A malicious entity can put damaging words into your innocent e-mail. In today's world, security by obscurity does not work any more.
Object signing
To combat the threat of computer viruses, executable code is now being signed to prove its authenticity and integrity. Java applets and Active-X controls are examples of the types of things that should be signed. If we create code that runs on a user's machine, it should be signed for both the user's peace of mind and for our legal protection. Various PKI tools allows you to use SensorNet Client Certificates for code signing.