Signature over EncryptedXXX

[merlin <merlin@baltimore.ie>]

I had an action to provide some text to Hal wrt signing
data that are already encrypted.

The issue is this:

XML encryption provides two mechanisms for transporting
the raw ciphertext associated with an Encrypted structure:

1) Use CipherData/CipherValue/#base64Data to embed the
   ciphertext within the Encrypted element.

2) Use CipherData/CipherReference/@URI to reference the
   externally-located ciphertext.

A signature over the first form will cover the algorithms,
keying information and the ciphertext, thereby securing the
encrypted data.

A signature over the second form will cover just the
algorithms, keying information and URI, and will therefore
provide no assurance that the encrypted data have not been
modified wherever they are externally stored.

Three solutions that I see:

1) Prohibit the second form. 'Attachments' are a more
efficient mechanism for transporting large binary blobs,
so this might meet some resistance.

2) Define a transform that dereferences the CipherReference
and replaces it with a CipherValue. This turns out to be
identical to our SecurityTokenReference transform; maybe we
could extend that.

3) What's really the issue here... Quoting Hal, re line 1526:

> New: One method to avoid this attack is encrypt the signature. This is
> difficult to arrange while complying with this specification. Another
> alternative is to ensure that the signed and encrypted data the not exactly
> the same. For example, this can be done by signing an element and encrypting
> its contents.

> However, in this case the difference between the data sets will be known to
> a potential attacker. This might still permit some cryptanalytic attacks.
> Another approach is to make use of CBC padding to introduce random data to
> the cleartext. All of the symmetric ciphers defined for use with XML
> Encryption are block ciphers to be used in CBC mode. XML Encryption
> specifies a CBC padding scheme that has two important properties: 1)
> regardless of the length of the cleartext, there will always be some padding
> bytes and 2) the padding data (except for a byte indicating the amount of
> padding) can have any value. If the CBC implementation introduces random
> bits in the padding (which is allowed, but not required by XML Encryption)
> this threat will effectively be countered.

I'm a bit confused, but I think there are two issues
here: The first is using a plaintext signature to mount a
plaintext guessing attack on encrypted data. The second is
a cryptographic uncertainty over signing and encrypting the
same data.

The first issue is not solved by signing and encrypting
different data. Without including a nonce in the signed
data (e.g. a wsu:Nonce attribute or somesuch) or encrypting
the signature, an attacker can try to guess the plaintext,
regardless of the exact bits that were encrypted.

As to the second issue; I have yet to see a formal statement
of what this vulnerability truly is, although I too have heard
of it. Some things worth noting, however:

XMLDSIG computes a message digest over the canonicalized XML
data; XMLENC encrypts a serialized form of the XML data. These
may not be the same (in particular, note the apex xmlns=""
issue). If they are the same, then even if random padding is
used, if the canonical form is a multiple of the block size,
then you can drop the final random padding block and you have
ciphertext over the same data that were signed. Even in the
other case, I'm just not sure about this vulnerability, and
thus whether random padding addresses it any differently to
fixed padding. In either case, 'something' different will
be encrypted to what was signed.

Unless we can get more info on this attack, I'd be concerned
about us recommending signatures over encrypted data (and the
associated legal problems) when there are other straightforward
solutions such as using a nonce, or encrypting the signature.
Using an EncryptedKey with two DataReferences, we can even
perform the separate data and signature encryption operations
using a single public-key encrypted session key, and thus a
single asymmetric operation.

Merlin


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com