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

From: "Philip Hoyer" <[email-masked]>
Date: Tue, 27 Jan 2009 11:29:37 +0100

Anders,
Could you go into a bit more detail with respect to PSKC here please.

I am assuming that your MAC would be over each single attribute otherwise we would need to introduce canonicalization correct?

So let's assume a simple HOTP key where we have they key value K the algorithm URN and the Counter C.

Am I correct in assuming you mean that the ValueMac of the key would be HMAC-SHA1(K,URN)

Now the Valuemac of the counter would be HMAC-SHA1(K,C) correct?

What do we do when the size of K is smaller than that required by HMAC? Append same values until we reach desired size?

Sounds interesting!

Philip

----- Original Message -----
From: Anders Rundgren <[email-masked]>
To: Philip Hoyer; Tschofenig, Hannes (NSN - FI/Espoo) <[email-masked]>; KEYPROV <[email-masked]>
Sent: Mon Jan 26 22:45:26 2009
Subject: Re: [KEYPROV] Rationale for separating key encryption and keyintegritychecks (was KW-AES-128 vs. AES-128-CBC)

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,
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.

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)

- 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
<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

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 27 Jan 2009 22:29:16 +0100

Philip
c-i-l

>I am assuming that your MAC would be over each single attribute
>otherwise we would need to introduce canonicalization correct?

To be completely honest, I was mainly trying to come up with an alternative to creating a new KW-AES
scheme that would offer advantages such a algorithm binding and universality.

>So let's assume a simple HOTP key where we have they key value K the algorithm URN and the Counter 

I did never consider MACing Counter C because it is clear-text.
Clear text data could be signed if the issuer and client thinks that's necessary.

>Am I correct in assuming you mean that the ValueMac of the key would be HMAC-SHA1(K,URN)

Absolutely!

>Now the Valuemac of the counter would be HMAC-SHA1(K,C) correct?

I would not MAC this one.  If all attributes should be MACed, a signature seems
more approprioate.

>What do we do when the size of K is smaller than that required by HMAC?
>Append same values until we reach desired size?

According to the RFC K may be of any length although length is recommended to
be 20 for HMAC-SHA1.  Even with 16-byte keys, the scheme should be on par
with KW-AES-128.

ADDITIONAL INPUT:
off-list I have gotten a suggestion that is more elaborate (three different algorithms
instead of two) but accomplishes a thing that my scheme does not; namely eliminates
the need for "using" K for creating a MAC.  I personally don't see a _single_ use
of a key by a potentially "alien" algorithm as a threat.  If you feel I'm wrong, please
shout and you will get the suggestion...

The #1 problem security-wise is still the fact that any scheme will not be better
than the surrounding environment (OS).

Anders

----- Original Message -----
From: Anders Rundgren <[email-masked]>
To: Philip Hoyer; Tschofenig, Hannes (NSN - FI/Espoo) <[email-masked]>; KEYPROV 
<[email-masked]>
Sent: Mon Jan 26 22:45:26 2009
Subject: Re: [KEYPROV] Rationale for separating key encryption and keyintegritychecks (was 
KW-AES-128 vs. AES-128-CBC)

Philip,

Anders

----- Original Message -----
From: "Philip Hoyer" <[email-masked]>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>; "ext Anders Rundgren"

Ladies and Gentlemen,

Philip

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

Hi Anders,

that's a good point.

Ciao
Hannes

<Key

Issuer operations:

Anders Rundgren