16.1 General Considerations


Let's look at the simplest case, signing and encrypting a single block of data. Should we encrypt and then sign or should we sign and then encrypt? You need to examine each case individually to determine the best option. Even in the case of a single data block, multiple possibilities exist. The following sections describe three general possibilities along with their advantages and disadvantages.

graphics/note.gif

In the absence of other considerations, signing and then encrypting is the best choice. Evidence indicates that, for certain secure symmetric encryption algorithms and secure symmetric authentication algorithms, either authenticating and then encrypting or encrypting and then authenticating can lead to compromise when subject to certain attacks [Krawczyk]. This weakness is not present if you use either CBC chained or stream encryption, so the types of encryption described in Chapter 18 are safe in this regard. Nevertheless, this point demonstrates that blindly combining secure cryptographic mechanisms can result in an insecure system.


16.1.1 Encryption of Signed Data and Signature

Suppose you have some signed data, and that data and the Signature element are all encrypted into a cipher text described by an EncryptedData element. Figure 16-1 shows a maximally detached case, and Figure 16-2 shows a maximally enveloping case. (Mixed detached and enveloped cases are also possible.)

Figure 16-1. Encryption of signed data and Signature (detached)

graphics/16fig01.gif

Figure 16-2. Encryption of signed data and Signature (enveloping)

graphics/16fig02.gif

Advantages
  • This arrangement hides the maximum amount of data, making the encryption the most effective. When some forms of public key cryptography are in use, the signature key identifies the signer. In that case, the signature key must be encrypted, as it is here, to conceal the identity of the signer.

  • This nesting hides the Signature element, preventing failed attempts to verify it while the data it signed as plain text remain cipher text.

  • Because the signature covers the plain text, it is still verifiable after removing the encryption; it can also be kept with the data if desired. It is possible to reencrypt the signed data in the same or a different way after decrypting the signed data.

Disadvantages
  • If the data has been damaged, you must go through the effort to decrypt it before you can check the signature and find that the data is damaged.

  • In many encryption systems based on public keys, anyone can encrypt a message to any recipient. Care should be taken in designing a system such that a naïve recipient will not be misled into believing that, because data is encrypted to them, the data were originally sent to the recipient. For example, assume Alice creates the message "Let's elope," signs it, and then encrypts it for and sends it to Bob. For whatever reason, Bob decrypts the message, then reencrypts it for and sends it to Charlie. This transfer could cause confusion. As a solution to this specific problem, you might simply include intended recipient and date information in the signed data.

graphics/soapbox.gif

The second disadvantage cited here doesn't actually relate to the encryption or even to the existence of the data in digital form. If Alice manually signs a two-word message on a piece of paper and physically mails it to Bob, he could physically forward it to Charlie. Somehow, performing this transfer digitally seems to confuse people. Some [Davis] consider this issue to be a critical problem that should be fixed by changing basic formats. Most such complaints come from a document view, usually based on electronic mail examples (see Appendix E). As most of the data in electronic mail is intended for human interpretation without context, this perspective pushes your thinking in a document direction. From the secure protocol point of view, a basic secure design criterion calls for protection against the replay or forwarding of parts of messages, or similar actions, by malicious parties or through error. Unfortunately, human languages, such as English, were not designed with these criteria in mind.


16.1.2 Encryption of Signed Data But Not Signature

An intermediate possibility, if the signature is detached, is to encrypt only the data signed, but not the Signature element (see Figure 16-3). The encryption could be enveloped without changing the advantages and disadvantages associated with this strategy.

Figure 16-3. Encryption of signed data but not of Signature (detached)

graphics/16fig03.gif

Advantages
  • Because the signature covers the plain text, it remains verifiable after removing the encryption; it can also be kept with the data if desired. It is possible to reencrypt the signed data in the same or a different way after decrypting it.

Disadvantages
  • Placing the Signature element outside the encryption makes the Reference DigestMethod and DigestValue information accessible in plain text. This approach may reveal information that the encryption is intended to hide.

  • If the data has been damaged, you must go through the effort to decrypt it before you can check the signature and find that it fails.

  • The Signature key may reveal signer identity information that should have remained concealed.

16.1.3 Signing Encrypted Data

In this situation, the cipher text and EncryptedData element are signed. Figure 16-4 shows a maximally detached example. As described in Section 16.1.1, maximally enveloped and mixed versions are possible.

Figure 16-4. Signature of cipher text and EncryptedData (detached)

graphics/16fig04.gif

Advantages
  • If someone has tampered with the data, you will find out at an early stage when the signature fails without having to go through the effort of decrypting it.

Disadvantages
  • The signature covers the cipher text and is invalidated when the data is decrypted. Thus, the cipher text and decryption key must be remembered or rederived to be able to store the data with a verifiable signature. Furthermore, to demonstrate the signature to a third party requires revealing the decryption key. This approach might compromise other data encrypted with the same or a related key.

  • The Signature key may reveal signer identity information that should have remained concealed.



Secure XML(c) The New Syntax for Signatures and Encryption
Secure XML: The New Syntax for Signatures and Encryption
ISBN: 0201756056
EAN: 2147483647
Year: 2005
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net