Chapter 7. Securing the Message
There exists an important class of application where the originator and the recipient of electronic information need not be active at the same time. An example is e-mail. An e-mail message may get stored at intermediate mail servers a number of times before being delivered to the ultimate recipient. The same holds for application-to-application communication where the messaging infrastructure might do store-and-forward delivery of messages. The security requirements of these applications cannot be met by transport level security, the kind offered by SSL protocol covered in Chapter 6, Securing The Wire. Recall that SSL relies on a handshake between the sender and the receiver, involving an exchange of messages to establish a secure channel, which requires both communicating end-points to be active at the same time.
Even in situations where both the communicating end-points are active simultaneously, there may be a need for an intermediary to look at parts of the message and make a routing or delivery decision based on what it finds there. This is not possible with a transport level protocol like SSL, which encrypts everything flowing over the secure channel. Recall the discussion of how SSL prevents content-based filtering at HTTP proxies, potentially invalidating certain security-enhancing capabilities of proxies.
Somewhat similar is the need to cryptographically protect data in secondary storage. This is usually done as a safeguard against theft or accidental loss of the media storing the data. Imagine losing a laptop with confidential documents on its hard disk. Anyone who gets hold of the laptop can access all these documents. This kind of information leak can be avoided by keeping sensitive files encrypted. Encryption of data stored on secondary storage also provides some degree of protection against break-ins or unauthorized access to the computer systems.
What these applications need is the ability to secure certain messages or their parts, independent of the transport. The meaning of security remains the same as one or more of the following: the sender can make sure the message is read only by the intended recipient(s), the recipient(s) can be sure of the fact that the message indeed originated from the claimed sender, and no one in the middle is able to read or alter the message. In other words, the end-points are able to authenticate each other and guarantee confidentiality and integrity of the message. This process is quite similar to signing a letter, placing it inside an envelope, sealing it and then using public postal service to mail the sealed envelope. In contrast, the transport level security is like hiring a dedicated messenger to carry a series of letters.
As indicated earlier, e-mail is an obvious example of an application that benefits from message-level security. Other examples include business-to-business applications that exchange electronic documents to perform critical business operations such as supply chain management, order processing and fulfillment, electronic funds transfer, and so on. As we see in Chapter 11, Web Services Security, a set of transport, interface definition and document packaging standards are increasingly being used to build such applications over the open Internet. Ensuring security of these messages is an important goal.
As discussed in Chapter 3, Cryptography with Java, message security can be achieved with digital signature and encryption. Digital signature relies on public-key cryptography and assumes the existence of some form of PKI (Public Key Infrastructure) to guarantee secure distribution and management of keys and certificates. In contrast, encryption is possible without PKI, through secret-key cryptography. Encryption with public-key cryptography requires PKI.
Digital signature provides a means to validate the identity of the originator (authentication), detects any modification to the signed content (integrity) and can be used as evidence of the fact that the message was indeed sent by the sender (non-repudiation). Recall that the process of signing requires a private key but the verification process needs only the public key.
Encryption makes the data incomprehensible (confidentiality) to anyone other than the sender and intended recipient(s). As mentioned earlier, it is possible to use either secret-key or public-key cryptography for encryption. In the former, the originator and the recipient must share a secret key. For this reason, secret-key-based encryption is well suited for data stored on disk. Even in public-key cryptography, a secret key is used to encrypt the content. This secret key is then encrypted with the public key, so that only the intended recipient, the one who holds the corresponding private key, is able to retrieve the secret key and decrypt the content.
Different degrees of protection can be accomplished through digital signature alone, encryption alone or a combination of both. When using both digital signature and encryption, you could apply them to a message in any order, though there are distinct advantages of first applying digital signature and then encryption. We have more to say on this later in this chapter.