Goals of Cryptography

The goal of cryptographic systems is to provide a high level of confidentiality, integrity, non-repudiation, and authenticity to information that is exchanged over networks, especially public networks such as the Internet where people and businesses are involved in electronic commerce. These key areas are described below.

•  Confidentiality. Provides privacy for messages and stored data by hiding information using encryption techniques.

•  Message Integrity. Provides assurance to all parties that a message remains unchanged from the time it was created to the time it was opened by the recipient. Altered messages may cause people or systems to take actions that are inappropriate.

•  Non-repudiation. Can provide a way to prove that a document came from someone even if they try to deny it.

•  Authentication. Provides two services. The first is to identify the origin of a message and provide some assurance that it is authentic. The second is to verify the identity of a person logging onto a system and after doing so, continue to verify their identity in case someone tries to break into the connection and masquerade as the user.

How are these services typically used and how do they employ cryptography? Cryptography can be used in a number of ways to keep information private and provide a framework for secure message exchange and transactions. All of the following are enabled through cryptographic technologies:

•  Certificates (Digital IDs). Authenticates users, web sites, software code, and information in general using third-party certification authorities.

•  Digital signatures. “Sign” messages to validate the source and integrity of the contents.

•  Secure channels. Encryption can be used to create secure channels over private or public networks to provide privacy. Three examples are pictured in figure 10.3.

Figure 10.3  Three types of secure channels can provide confidential data transmissions.

With the above services, enabling a number of interesting services is possible. For example, a web administrator can restrict access to pages on her web server to a specific group of people. Legal and business transactions can be undertaken by using digital signatures. Users can also be assured that the web site they are visiting is authentic and not spoofed by someone out to collect credit card numbers and personal information.

The following sections describe some of the more common services provided by these technologies. For the most part, these services are enabled through public key (asymmetric) schemes rather than private schemes.

Digital IDs, Certificates, and Certificate Authorities

The distribution of keys is difficult even in the public key (asymmetric) scheme if the Internet is the communication channel. On an internal network, the network administrator can set up a separate security server and everybody can put their public keys on that server. Alternatively, a user can just ask someone for their public key.

On the Internet, obtaining a public key requires a certain level of trust. You must know that the public key belongs to the person you think it does. Someone might be masquerading as someone else. A solution is to work with a trusted third-party organization called certificate authorities (CA) that distributes public keys for people and organizations and that verifies the credentials of the people associated with the public keys. For example, Verisign (http://www.verisign.com) and the U.S. Post Office (http://www.usps.gov) are certificate authorities.

CAs issue certificates, which are essentially equivalent to personal calling cards. A certificate is a package that contains your public key along with information about you such as your e-mail address, full name, and even credit card number. Certificates are becoming as important on the Internet as drivers licenses and passports are to travelers.

Most important is that the certificate contains a user’s public key. A typical transaction using a public key is pictured in figure 10.4.

Figure 10.4  Certificate-based transactions include the steps pictured here.

The sequence of certificate-based transactions is relatively simple to understand. It is broken down here into steps that highlight the process.

1.  Joe accesses a private web site.

2.  The web server requests to see Joe’s certificate before proceeding further.

3.  Joe’s web browser automatically presents his certificate.

4.  The web server verifies that the certificate is a valid certificate from the issuing certificate authority and extracts the user’s public key if valid.

5.  All subsequent session information is encrypted with Joe’s key.

6.  Joe’s web browser decrypts the transmission with his private key.

The above assumes that Joe has a certificate. If Joe does not have a certificate, the web server cannot validate Joe (at least not using the scheme discussed here), but a secure transmission channel can still be set up by using the web server’s public key to encrypt all transmitted data. In fact, this is the most common method for setting up secure channels, at least until user-held certificates become more widespread.

Conveniently, a certificate is like a container that can hold personal information for its owner that can be used to complete transactions or to give the user special privileges on the server. Certificates even do away with the need for a user to log on to remote servers because the information in the certificate provides all the information to perform the logon. Certificate authorities will create custom certificates for organizations that have special requirements. For example, an insurance company might require its customers to hold certificates that contain medical information.

But this brings up a very important question. How does a user or server that is accepting a certificate know that it is authentic? The answer is that the certificate is actually a package of information that has itself been signed by a certificate authority. A web server that accepts a certificate from a user can use the public key of the issuing certificate authority to verify the certificate. But what if the user or server does not trust the certificate authority? This scenario is handled by a hierarchy of trust in which certificate authorities are verified by higher and higher levels of certificate authorities. Basically, a local CA in your home town that certifies its citizens might itself be certified by a state CA, which is certified by a national CA, and so on.