Subject: [KEYPROV] A NIST-ified Provisioning Session Key Proposal

From: Anders Rundgren <[email-masked]>
Date: Tue, 23 Mar 2010 09:06:38 +0100

Dear fellow protocol designers,

Although the SKS/KeyGen2 scheme is "ready", I got second thoughts when I 
studied NIST's SP 800-56A and begin to wonder if I should abandon my 
homegrown solution (inspired by DSKPP BTW) , and try to adopt something 
that could be referred to as "standard" instead.  After carefully 
looking into the various solutions I came up with the following which I 
would be *very* happy to get feedback on if possible.  I'm not really a 
cryptographer so I could it surely need it :-)

Since this is a part of a protocol having 10 (!) active passes, there 
are constraints on how the scheme can work unless the protocol should be 
revised as well.

*Goals:
*/- Create a random shared session key between the SKS and the issuer
- Allow *both* parties to contribute to the randomness of the session key
- Assure the issuer that the created session key is authentic
- Assure the issuer that issuer-specified session parameters have been 
honored
- Authenticate the SKS to the issuer
- Eliminate clear text transmission of session key subcomponents
- Exploit SKS' strong cryptographic capabilities but don't overdo it

/*Non-goal:
*/Verify the identity of th issuer.  An SKS in an open-ended 
key-container concept where it is the *user* who in a GUI web-browser 
dialog decides if an issuer should be permitted to create keys in the SKS.
/
*Prerequisites:
*In a preceding protocol pass, the issuer has been informed about the 
target SKS' ability regarding ECC support in terms of predefined ECC 
curves like P256, but no key material whatsoever has been exchanged.

*Basic operation:
*The scheme builds on the NIST algorithm C(2,0,ECC EDC) where unilateral 
key confirmation has been added.

Issuer:
Creates an /ephemeral/ ECDH key-pair

Sends the following to the SKS
- the generated Issuer Ephemeral Public Key (IEPK)
- a set of session parameters (lifetime, ID etc) called SESSPARMS

SKS:
In an *atomic* operation does the following:

Creates a compatible /ephemeral/ ECDH key-pair and is now able to create 
the shared session key through proper use of a KDF.

Uses a /static device attestation key/ (RSA or ECDSA) to sign a blob made of
   IEPK ||
   The SKS-generated Ephemeral Public Key (SEPK) ||
   SESSPARMS ||
   Locally gathered data (like current time and ID), called LOCDAT

Sends the following to the issuer
- SEPK
- attestation signature blob
- /static device attestation certificate/
- LOCDAT

Issuer:
Should now (if I'm not wrong) be able to reach the earlier stated goals.

Feel free to "diss" or come up with a better proposal.  The purpose of 
this message is also to publish this scheme to find out/destroy any IPR 
that may be associated with it.

Regards,
Anders
http://webpki.org/auth-token-4-the-cloud.html