Assume Joe wants to send Alice a signed message. The procedure is outlined next and pictured in figure 10.5.

1.  Joe runs a one-way function to create a fixed-length message digest from the message to be sent.

2.  Joe encrypts the message digest with his private key to create a digital signature.

3.  Joe sends the signature and the message to Alice.

4.  Alice decrypts the signature using Joe’s public key to reveal the message digest.

5.  Alice then applies the same one-way function to the message she received from Joe to produce a message digest.

6.  Alice compares the message digest she created with the message digest sent by Joe. If they compare, the integrity of the message is verified.

Figure 10.5  The steps for using digital signatures involve creating the signature (the sender) and checking the signature (the recipient).

Digital signatures and digital certificates are encryption-based methods for proving the identities of users (user authentication), the origin of messages (message authentication), and the integrity of documents. They can also provide non-repudiation as well as digital time stamping, which effectively binds a document to the time it was created or sealed.

Security for Network Logon and Authentication

Secure network operating systems use various schemes to verify the identity of a person logging in. In the simplest form, the user must type a user name and password. A user account matching the name is referenced to see if the password is correct. If so, the user gains access.

Of course, this scheme breaks down if the password is found out by someone else or if it is captured and read during transmission. One problem that exists on some networks is that users may use the same password to log onto different systems. However, one of those systems might accept unencrypted passwords (that is, plaintext passwords sent “in-the-clear”). An attacker could somehow capture passwords that are sent to the unsecure system, then attempt to use them to gain access to more secure systems.

One way to solve this problem is the challenge-response method, which does not require you to send any kind of password over the wire, either plaintext or encrypted. With the challenge-response scheme, the client is issued a challenge and must provide an appropriate response to log on. The response is calculated using the user’s password, but the password itself is never sent. The reason this works is that the authenticating server performs the same calculation using the challenge it sent to the user and the user’s password, which it has stored. If its own calculated response compares to the user’s response, then the user is considered valid.

---

Note:  Refer to Chapter 9, “Kerberos,” for a discussion of the Kerberos authentication model.

---

Authentication within the corporate environment has been relatively easy to implement compared to validating remote users or Internet users who want to access your systems. Internally, you can create accounts for known users, validate the user based on the machine they are logging in from, and require the use of a preferred authentication scheme by every system in the organization. You simply have more control over the security of the entire system.

Authenticating remote users and Internet users is another matter. Assume you set up a web server that contains sensitive information. Only select users can access the information on the server. What techniques can you use to authenticate users over the Internet to prevent spoofing? There are two possibilities:

•  Two-factor authentication. You might not know it, but you already use this scheme because you use it every time you take money from an Automatic Teller Machine (ATM). When you insert your bank card, the ATM asks you to type a password. This scheme is based on something you have (the bank card) and something you know (the password). If someone steals your card, they can’t use it without the password. If someone learns your password, they can’t use it unless they have your bank card. Applying this scheme to your own security system requires that you issue a token access device to each remote user. The token access device looks like a credit card with a display. The display presents a number that constantly changes with time and is synchronized with the authentication server. When a user wants to log on, he types his user name and password as normal, then he looks at the token device and enters the number on its display. When the server receives this information, it checks the user name, password, and token access value to validate the user.

•  Certificates. For this user authentication scheme, we can again use our banking analogy, but this time, assume you are at a foreign bank and you need to prove to a teller that you are who you say you are. At the teller’s window, you present your passport. It has been issued by a trusted authority (that is., the State Department). The teller “trusts” that this is an official document and matches your picture with your face. This computerized certificate scheme is not much different. When a user logs on, the authenticating server first verifies that the certificate is valid by opening it with the CA’s public key. The contents, which include the user’s public key and personal information, are extracted from the certificate. Next, the server sends a challenge to the user. This challenge is a random, one-time value that the user must sign with his private key and return to the server. The server then signs the same value with the public key extracted from the user’s certificate. If the results compare, the user is considered valid. No passwords need to be stored or transmitted.

Of course, these schemes may differ slightly, based on the implementation. Certificates are available from the certificate authorities listed earlier. See table 10.3 for a list of sites where token authentication devices are available.