Subject: [KEYPROV] Rationale for separating key encryption and key integrity checks (was KW-AES-128 vs. AES-128-CBC)

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 22 Jan 2009 20:52:07 +0100

- You obviously want key integrity checking
- You obviously want key length independence

I have found that there is another characteristic that you may want in a key provisioning scheme and that is the ability to securely bind a key to a set of attributes, with the acceptable algorithm(s) as the primary candidate.  An example:

<Key EndorsedKeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
     MAC="cOpiQ/H7Zlj6ywiYWtwgz9cRaOA="
     MACAlgorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
   <xenc:EncryptedKey>
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
      <xenc:CipherData>
         <xenc:CipherValue>cymS8WW+a92n/ . WcqAxD+ndOPo=</xenc:CipherValue>
      </xenc:CipherData>
   </xenc:EncryptedKey>
</Key>

A possible way of achieving all three goals would be to do as follows.
K is the actual cryptographic key we want to provision.
KEK is a pre-shared secret used for encrypting K.

Issuer operations:

MAC = HMACSHA1 (K, "http://www.ietf.org/keyprov/pskc#hotp")
ChiperValue = AES128CBC (KEK, K)

This means that the provisioning client must first decrypt CipherValue with KEK in order to get K.
Then it can verify that the declared algorithm returns a matching MAC when using K.
If the MAC doesn't match, either K, KEK, MAC, or the algorithm is wrong.

The nice thing with this arrangement is that it opens the possibility to make a slightly cooler version of provisioning inside of a secure container like this:

provsionKey (ChipherValue, MAC, MACAlgorithm, EndorsedKeyAlgorithm, EncryptionMethod);

The container could thus potentially protect against algorithm "misuse".

Although KEYPROV does not fully address secure containers (since an issuer can't verify the the client is using such), maybe a future version will?

The described scheme is BTW equally applicable to PKI-based KEKs!

Anders Rundgren
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sat, 24 Jan 2009 13:41:47 +0200

Hi Anders, 
 
that's a good point. 

The current version of the draft applies the keyed message digest only
to the encrypted key without including further information from the PSKC
document into the digest computation. 

Incorporating additional information in the keyed message digest makes a
lot of sense to me (maybe in a fashion similar to the approach we use in
Section 7 regarding digital signatures). 
 
Ciao
Hannes
________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Anders Rundgren
	Sent: 22 January, 2009 21:52
	To: KEYPROV
	Subject: [KEYPROV] Rationale for separating key encryption and
key integritychecks (was KW-AES-128 vs. AES-128-CBC)

	I have found that there is another characteristic that you may
want in a key provisioning scheme and that is the ability to securely
bind a key to a set of attributes, with the acceptable algorithm(s) as
the primary candidate.  An example:
	
	<Key
EndorsedKeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
	     MAC="cOpiQ/H7Zlj6ywiYWtwgz9cRaOA="
	     MACAlgorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
	   <xenc:EncryptedKey>
	      <xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc
<http://www.w3.org/2001/04/xmlenc#aes128-cbc> "/>
	      <xenc:CipherData>
	         <xenc:CipherValue>cymS8WW+a92n/ ...
WcqAxD+ndOPo=</xenc:CipherValue>
	      </xenc:CipherData>
	   </xenc:EncryptedKey>
	</Key>
	 
	A possible way of achieving all three goals would be to do as
follows.
	K is the actual cryptographic key we want to provision.
	KEK is a pre-shared secret used for encrypting K.
	 
	Issuer operations:

	This means that the provisioning client must first decrypt
CipherValue with KEK in order to get K.
	Then it can verify that the declared algorithm returns a
matching MAC when using K.
	If the MAC doesn't match, either K, KEK, MAC, or the algorithm
is wrong.
	 
	The nice thing with this arrangement is that it opens the
possibility to make a slightly cooler version of provisioning inside of
a secure container like this:
	 
	provsionKey (ChipherValue, MAC, MACAlgorithm,
EndorsedKeyAlgorithm, EncryptionMethod);
	 
	The container could thus potentially protect against algorithm
"misuse".
	 
	Although KEYPROV does not fully address secure containers (since
an issuer can't verify the the client is using such), maybe a future
version will?
	 
	The described scheme is BTW equally applicable to PKI-based
KEKs!
	 
	Anders Rundgren

---

From: "Philip Hoyer" <[email-masked]>
Date: Mon, 26 Jan 2009 15:03:49 +0100

Ladies and Gentlemen,
The current draft allows a separate MAC for all elements under the
<Data> element. Hence it is incorrect saying that it allows only a MAC
on the key value.

If other elements outside of <Data> need to be integrity protected the
whole container can be signed.

Do you see this as insufficient?

Are you saying that securely binding the Key to its Data element we
should allow for a MAC or signature at each Key level?

Philip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Saturday, January 24, 2009 11:42 AM
To: ext Anders Rundgren; KEYPROV
Subject: Re: [KEYPROV] Rationale for separating key encryption and
keyintegritychecks (was KW-AES-128 vs. AES-128-CBC)

Hi Anders, 
 
that's a good point. 

 
Ciao
Hannes

	
	
	<Key

	Issuer operations:

	 

	 

	Anders Rundgren

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 26 Jan 2009 22:45:26 +0100

Philip,

Maybe we are talking about different things?

I'm proposing that K (the actual Key) could be used used to create a
MAC based on one more attributes related to K.  The best shot would
be the algorithm that is supposed to be used with K.  I see that as an
alternative to using encryption algorithms with built-in integrity checks.

The MAC of K is primarily for verifying that K is properly recovered
*after* decryption with KEK (Key Encrypting Key), something which
signing or additional MACing does not accomplish.  That does not mean
that signing is useless, only that it has another purpose.

Another effect of this arrangement is that it enables a cryptographic
binding between a K and an attribute that may be carried out inside of
the crypto module in a fully end-2-end-secured fashion.

Anders

----- Original Message ----- 
From: "Philip Hoyer" <[email-masked]>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>; "ext Anders Rundgren" 
<[email-masked]>; "KEYPROV" <[email-masked]>
Sent: Monday, January 26, 2009 15:03
Subject: RE: [KEYPROV] Rationale for separating key encryption and keyintegritychecks (was 
KW-AES-128 vs. AES-128-CBC)

Ladies and Gentlemen,

Philip

-----Original Message-----

Hi Anders,

that's a good point.

Ciao
Hannes

<Key

Issuer operations:

Anders Rundgren