Shared Key Technologies

Shared key technologies, including shared key encryption and Kerberos, will be your critical tool for guaranteeing information security principle number one: confidentiality of Web services messages. The following sections discuss the cryptography behind the algorithms, the mechanisms for managing keys, and the relationship between shared key technologies and public key technologies.

Shared Key Encryption

Other synonyms for shared key encryption are frequently used. This technology is sometimes referred to as symmetric encryption or secret key encryption because the same key is used to both encrypt and decrypt the message, and this key must be kept secret from all non-participating parties to keep the encrypted message secret. For clarity and simplicity, in this book we consistently use the term shared key encryption because sender and receiver share the same key, which is distinct from public key encryption where one key is made open and public to the entire world. Shared key encryption is the key technology to achieve the security principle of message confidentiality. Message confidentiality means that no one other than the intended recipient will be able to read a message because it is encrypted strongly enough that no one without the correct key can decrypt it by any other means. We reproduce the shared key encryption diagram from Chapter 1, "Basic Concepts of Web Services Security," here in Figure 3.1.

Figure 3.1. Shared key encryption.

The key to message confidentiality is in the key , so to speak. Because both sender and receiver must utilize the exact same key (it is shared) , this solitary key must somehow be separately and confidentially exchanged so that both parties have it ”and no one else does ”prior to message exchange. Under other circumstances, you might think you could send the key via U.S. Mail or read it over the phone, but neither of these approaches would be consistent with the goals of computer-to-computer Web services communication. For Web services, this exchange must be made over the same channel that the encrypted messages will flow. Cryptographers and security practitioners have determined that the best way to accomplish this is to encrypt the shared key using public key encryption before exchange. Public key encryption is described in the next section.

Only the shared key is secret, not the encryption algorithm itself. It is very important that the encryption algorithms themselves are public and well scrutinized. In the early days of information security, encryption algorithms were kept strictly secret and proprietary; however, after they were put into use, users found that they had dangerous flaws. Now the field of cryptography understands that the open study of algorithms enhances confidence in the algorithm's security due to the extensive testing and analysis by all the world's cryptographers. A proof of this point is how long the modern shared key encryption algorithms Advanced Encryption Standard (AES) and Triple Data Encryption Standard (3DES) have been in use, withstanding extensive testing with no flaws found.

Without going into extensive mathematical derivations to prove our points (see Appendix A for some details), we need you to take on faith the three most important factors you need to know about shared key encryption:

• Shared key encryption is much faster than public key encryption.

• Shared key encryption can operate on arbitrarily large plaintext messages, whereas public key encryption cannot.

• Shared key encryption utilizes public key encryption to manage distribution of the shared key securely to the recipient.

Shared key encryption uses cryptographic algorithms known as block ciphers . This means that the algorithms work by taking the starting plaintext message and first breaking it into fixed- size blocks before encrypting each block. Two strong encryption algorithms used throughout the software industry are part of the XML Encryption standard: the long-standing 3DES and the relatively new, but highly reviewed and analyzed AES.

DES involves many computationally fast and simple substitutions, permutations , XORs, and shifting on a data block at a time to produce ciphertext from an input plaintext message. The design of DES is so clever that decryption uses exactly the same algorithm as encryption. The only difference is that the order in which the key parts are used in the algorithm is exactly reversed .

DES is 25 years old and still going strong. Part of the reason for this is that DES was designed (and adapted over the years ) to work really well in hardware. Numerous companies now include DES chips in their devices. Virtual private networks (VPNs) frequently use 3DES ”the stronger version of DES described next ”directly in the hardware to create secure IPSec tunnels. DES uses a 64-bit key: 56 effective bits, and 8 bits for parity. DES operates on an 8-byte fixed-block size. In the past decade , weaknesses found in DES have been addressed by 3DES.

Note

It is rumored that the NSA has machines costing under $50K that can brute-force crack DES with its 64-bit key in 15 minutes.

3DES saved DES from being abrogated to the cryptography scrap heap by responding to the fact that 2 ⁵⁶ (72 quintillion) possible keys made plain DES susceptible to a brute-force attack, so the DES algorithm is run three times with a much longer key. 3DES uses a 192-bit key, of which the effective key length is 168 bits. The idea is to use DES three times: sequencing Encrypt-Decrypt-Encrypt with a different third of the 168-bit key used at each stage, as shown in Figure 3.2. This approach makes it relatively slow but very secure; on hardware, relatively slow is still plenty fast. Note that the middle step ”Decrypt ”does not actually decrypt the ciphertext created by the first step because a completely distinct key is used; it actually scrambles the message further.

Figure 3.2. How 3DES uses DES encryption three times in succession to be much more secure than DES alone.

AES is the newest shared key encryption standard. AES came out of a government-sponsored contest won by the cryptographers Joan Daemen and Vincent Rijmen (the algorithm was called Rijndael, pronounced "rain doll)." It also works well in hardware and can have keys up to 256 bits long, taking it out of the realm of ever being susceptible to a brute-force attack.

A critical concept for shared key encryption is padding. The blocks that are input to the cipher must be of a fixed size, so if the plaintext input is not already of the correct size, it must be padded . However, you cannot just add random data; to do so, you would need to communicate to the receiver the correct size of the data, which would be a dangerous clue to an attacker. You also cannot just add zeros because the message itself might have leading or trailing zeros. Consequently, padding must include sentinel information that identifies the padding and must not give an attacker any critical information that might compromise the message.

Kerberos

No discussion of shared key technologies would be complete without mention of Kerberos. Kerberos was originally part of MIT's project Athena. The goal set out for Kerberos was real-time authentication in an insecure (the client is not trusted) distributed environment. This technology predates the Web. Plus, it appears to be getting a new lease on life with Microsoft's adoption of it in the base Windows operating system security model. Kerberos is also one of the recognized security tokens ”pieces of information used for authentication or authorization added to a SOAP header ”in the emerging WS-Security standard, which is presented in Chapter 7, "Building Security into SOAP."

Kerberos is a trusted third-party authentication protocol. Users and services obtain an authentication token called a ticket that they use for identity and shared keys that they use for secure communications. A shared key known only to the server that encrypts tickets. The Kerberos model calls for a centralized authentication server. Kerberos performs centralized key management and administration. The server maintains all users' shared keys and generates session keys whenever two users want to communicate securely. It authenticates the identity of a user who requests access to secure network services. A client must have a valid password and ticket (which only the server can validate) to use any services.

The basic Kerberos authentication flow is as follows :

1. The client sends a request to the authentication server requesting "credentials" for a given application server. These credentials can be applied directly to an application server or to a ticket-granting server.
   
   
2. The authentication server responds with credentials encrypted with the client's key; it includes a ticket for the server and a session key.
   
   
3. If the ticket is for the ticket server, the client then requests a ticket for the application server from the ticket server.
   
   
4. The ticket server responds with the ticket.
   
   
5. The client transmits its ticket with the client identity and a session key copy encrypted using the server's key to the application server.
   
   
6. The session key is now shared between the client and application server, which authenticates the client and can be used to authenticate the server. It can also be used to encrypt further communication between the two parties.
   
   

Kerberos plays an important, but not leading, role in Web services security. Systems running Microsoft Windows frequently use the built-in Kerberos model, which is appropriate only for closed systems, but they still may want to connect to external organizations via Web services. Those external systems need to have their authentication scheme mapped into the Kerberos model for the two organizations to interact.

The WS-Security standard recognizes Kerberos tickets as one of the valid types of security tokens. A very important attribute and goal of WS-Security is to be able to bridge between different security models and trust domains ”for example, one system that runs Kerberos connected to another that uses X.509 public key infrastructure.

Limitations of Shared Key Technologies

As we said earlier, shared key technologies fail to solve the problem of scalable key distribution. Shared key algorithms are fast and can handle infinitely large messages; however, both ends of the communication need access to the same key, and you need to get it to your recipient securely. Shared key cryptography also fails to solve the issue of repudiation . At times, you will need to be able to prove that a certain identity created and attests to sending a message (or document) and no one else could have. The sender must not be able to deny having sent this exact document at this moment in time. Shared key cryptography provides no help here.