Re: ConcatKDF in xmlenc-core1: ambiguous concatenation

Thanks Pratik and Magnus.

comments inline

regards, Party F :)

Frederick Hirsch
Nokia



On Jul 9, 2013, at 9:47 PM, ext Magnus Nystrom wrote:

To answer the questions regarding the test vectors:

a)      Yes, Bruce did use a 272-byte key.
b)      The plaintext was actually 320 bytes, no padding was used (I realize now this is incorrect given the URI used for the encryption algorithm, and we (MSFT) initially had padding but IBM wasn’t using it so we created a new test vector w/o it. Presumably a note should be added in the test vector folder about this. I think you’ll find the same thing in IBM’s test vectors; no use of padding).

As for your other question James (the security concerns around the absence of a delimiter, potentially collapsing what would have been different derived keys onto the same key): I agree that our text preferably would have stated: “The concatenation SHALL be done using the original, unpadded bit string values encoded as specified in [SP800-56A].”

Shall we log this as an erratum - it seems a clarification that could only help interop?


But the current text does not state that. Let’s therefore assume that two communicating implementations, Party U and Party V, follows XML Encryption 1.1 and just concatenates w/o using the SP800-56A encoding (and don’t expect/use fixed-length fields which also is a possibility). Assume Party U only shares a given master key K with Party V. I think this is a reasonable assumption. In this situation, for different AlgorithmID values, different keys will still be derived (assuming Party U and Party V always are represented the same way). However, whenever the concatenated encoding of the SuppPubInfo and SuppPrivInfo equals the concatenated encoding of some other SuppPubInfo and SuppPrivInfo for the same AlgorithmID, Party U and Party V values, the derived key will end up the same (I doubt SuppPrivInfo will ever be sent since it is supposed to be private information, but let’s assume it is). Is this then a security concern? I agree that SP 800-56 A’s encoding does not allow this derived key collapse to occur since in the case of variable-length components, each component would have been preceded by a length indicator in the encoding before the derivation. My (current) inclination would be to say that the security risk is low, since the parties anyway share a secret key. And if Party U shares a key K2 with both Party V and Party W, then clearly (at least in the absence of a not-sent-but-still-shared SuppPrivInfo), Party W will be able to anyway derive any key that is derived between Party U and Party V when K2 is the master just by observing the inputs to the derivation. But perhaps there are also other scenarios with malicious parties?


Very good point, the derived key depends on a master key which should never be shared with more than one counter party; sharing with more than one counter party would be a mistake. Thus the risk overall requires a sensible security practice for the master key...



Best,
Party M

From: pratik datta [mailto:pratik.datta@oracle.com]
Sent: Friday, 5 July, 2013 10:35
To: Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>
Cc: James.H.Manger@team.telstra.com<mailto:James.H.Manger@team.telstra.com>; magnus@rsa.com<mailto:magnus@rsa.com>; public-xmlsec@w3.org<mailto:public-xmlsec@w3.org>; Mark.Priestley@vodafone.com<mailto:Mark.Priestley@vodafone.com>; Magnus Nystrom
Subject: Re: ConcatKDF in xmlenc-core1: ambiguous concatenation

James,

The concatenation, as it is currently in the xml encryption spec, neither prepends/appends a  length field nor makes it a fixed length.   Which means that once concatenated, the components cannot be split apart, because there is no demarcation between the components. There is really no need to split it up once concatenated, because concatenation only needs to happen just before key derivation. The XML markup does not have them as concatenated.

Also the spec mentions that  "Note  While any bit string can be used with ConcatKDF, it is RECOMMENDED to keep byte aligned for greatest interoperability."  - All the interop examples are byte aligned.

For example  http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/files/microsoft/dkey-example-ConcatKDF-crypto.xml  has
<xenc11:ConcatKDFParams PartyVInfo="00424F424259343536" PartyUInfo="00414C494345313233" AlgorithmID="00123456789ABCDEF0">

In this example PartyVInfo, PartyUInfo and AlgorithmID are all byte aligned - notice how all of them start with "00".

So we just need to remove the 00 and concatenate these three parts. 123456789ABCDEF0414C494345313233424F424259343536.

It is also possible for PartUInfo and PartyVInfo to be empty in which case they are not included in the concatenation at all.



You are right about the padding issue.  I think the plain text is actually 312 bytes, and 8 padding bytes are added to it. Magnus can you confirm?

I think for DRV3, the shared secret key is really 272 bytes / 2176 bits, but Bruce should be able to confirm this.

Pratik

On 7/5/2013 9:10 AM, Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com> wrote:
James

Thanks for sharing these concerns on the list ;

re:  ConcatKDF section of spec: http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/#sec-ConcatKDF

 I have some comments inline.

re: issues with interop test cases

Pratik, Magnus - do you have any comment on interop questions at the end?

regards, Frederick

Frederick Hirsch
Nokia



On Jun 19, 2013, at 4:03 AM, ext Manger, James H wrote:


Hello W3 security group,

The ConcatKDF key derivation function as specified in XML Encryption Syntax and Processing Version 1.1 doesn’t look quite right.
http://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF
The derivation involves the hash calculation:
  H(counter || secret || AlgorithmID || PartyUInfo || PartyVInfo || SuppPubInfo || SuppPrivInfo)

The problem is that concatenating the last 5 components is ambiguous. The boundaries between these components are not preserved.

Perhaps there is an unstated assumption that (for any given secret) each component is unambiguous by having a fixed length or starting with its own internal length field. To be secure, the unstated requirement is that the recipient confirms the lengths of each component before performing the key derivation. It seems very unlikely that implementations will ever be that careful — and certainly not without a prominent warning to do so.


I think the spec is pretty clear that each component has its own length indication:

"In [SP800-56A<http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/#bib-SP800-56A>], AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo attributes are all defined as arbitrary-length bitstrings, thus they may need to be padded in order to be encoded into hexBinary for XML Encryption. "

Regarding integrity, a DerivedKey may be conveyed in a variety of ways, each of which could be protected:

"The DerivedKey element is used to transport information about a derived key from the originator to recipient(s). It may be used as a stand-alone XML document, be placed within an application document, or appear inside an EncryptedData or Signature element as a child of a ds:KeyInfo element. "

Thus I believe you are suggesting that the specification should have a security consideration that key derivation information may need integrity protection.



The last 5 components are specified in XML attribute values of type hexBinary, with a leading byte indicating the number of unused bits in the last byte (so each component can have an arbitrary bit length).

Example 25 includes:
<xenc11:ConcatKDFParams AlgorithmID="0000" PartyUInfo="03D8" PartyVInfo="03D0">

So AlgorithmID is 8 bits (00000000), PartyUInfo is 5 bits (11011), PartyVInfo is 5 bits (11010). Presumably SuppPubInfo and SuppPrivInfo are empty. Concatenating gives 18 bits: 00000000 11011 11010. You get the same 18 bits, and hence the same derived key by splitting these 18 bits differently. Eg 0000000011 0111 1010. In XML this would be:
<xenc11:ConcatKDFParams AlgorithmID="060000" PartyUInfo="0470" PartyVInfo="04A0">


Another problem is Example 36 (and Example 34 and Example 42), which includes:

<xenc11:ConcatKDFParams AlgorithmID="00" PartyUInfo="" PartyVInfo<

span style="color: rgb(102, 102, 0); ">="">


In this case AlgorithmID is presumably the empty bit string, but PartyUInfo and PartyVInfo look invalid.



On a related note, I think there is a mistake in the interop test DRV.1 for ConcatKDF at http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/Overview.html. The plaintext is not padded before it is encrypted (or the plaintext is 312 bytes, not the stated 320 bytes).
320 bytes of plaintext -> 1 block for IV + 20 blocks of plaintext + 1 block padding -> 352 bytes of ciphertext -> 470 base64 chars
However the <xenc:CipherValue> element has only 448 base64 chars.
http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/files/microsoft/dkey-example-ConcatKDF-crypto.xml

I cannot get the interop test DRV.3 to work either. Is the shared secret key really supposed to be 2176 bits long?
http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core1-interop/files/ibm/secret.concat.kdf


The interop participants should be able to help with this - Pratik, Magnus, do you have any comment?



--
James Manger (Telstra)