Re: ACTION-301: Example of KEM message and how to create it

Responding to Pratik's question on use of NIST approved mechanisms.

First, note that ECIES is not the same mechanism as ECIES-KEM.

Sec. 7 of NIST SP 800-56 states that a key transport scheme may be 
obtained by combining an appropriate ECC key agreement scheme with an 
approved key wrapping scheme.  ECIES in X9.63 provides the former (it 
meets item 3 on page 90) but not the latter, hence it is not approved.

ECIES-KEM in 18033-2 (and hopefully soon in XMLEnc) with data 
encapsulation mechanism = AES-KeyWrap provides both - under the assumption 
that ECIES-KEM in 18033-2 fits the other requirements of NIST SP 800-56, 
e.g., acceptable KDF and its inputs.

-- Magnus

On Mon, 8 Jun 2009, Pratik Datta wrote:

> Ok, so the EncryptedKey is still inline with KEM, thats good.
>
> Can you also also comment on the whether NIST Suite B includes ECIES? I see 
> in the page 108 of 
> http://csrc.nist.gov/groups/ST/toolkit/documents/SP800-56Arev1_3-8-07.pdf 
> that is says the ECIES of ANSI 9.63 is not allowed.  Is that different from 
> the ISO ECIES?  We definitely need to support a NIST approved encryption, as 
> that is one of major factors for supporting elliptic curves in the first 
> place.  So maybe we need to have two EC encryption mechanims - one NIST 
> approved and the other with KEM benefits.
>
> Pratik
>
> Magnus Nyström wrote:
>> Assuming the KDF has certain properties relating to ECIES-KEM (in 
>> particular the inclusion of the public ephemeral key in the key derivation) 
>> we would not, since in the case of EC (or DL more generally) we're first 
>> generating a random key pair (the ephemeral key pair) and from that we're 
>> generating a shared key which in turn is used to encrypt something - be it 
>> some data or a content-encryption key. So this is OK and in line with KEM.
>> 
>> As I mentioned on the call this week, you will have the same functionality 
>> with the ECDH agreement method but the benefit of KEM is that we're 
>> introducing a framework for key encapsulation that fits all public-key 
>> systems and which also has some provable security benefits.
>> 
>> -- Magnus
>> 
>> On Wed, 3 Jun 2009, Pratik Datta wrote:
>> 
>>> Are we losing the value of Key Encapsulation, if we use the EncryptedKey 
>>> mechanism? (I know I had asked for it, but I am wondering if it is the 
>>> right thing to do)
>>> 
>>> What I understood of the KeyEncapulation presentation in the F2F is that 
>>> if you generate a symmetric key first, and then encrypt it, it results in 
>>> looser or no proof of security. The better thing is to not generate the 
>>> symmetric key directly, but use the ECIES-KEM algorithm to generate a 
>>> symmetric key from the recepient's public key and the ephemeral key, and 
>>> then encrypt the data directly with this generated symmetric key.
>>> 
>>> Pratik
>>> 
>>> Magnus Nyström wrote:
>>>> This is an attempt to respond to ACTION-301 that I got yesterday. Given 
>>>> the schema in my earlier proposal
>>>> 
>>>> http://lists.w3.org/Archives/Public/public-xmlsec/2009May/0056.html
>>>> 
>>>> one can construct the following example <xenc:EncryptedKey> element:
>>>> 
>>>> <xenc:EncryptedKey
>>>>   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
>>>>   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>>>>   xmlns:dsig11="http://www.w3.org/2009/xmldsig11#"
>>>>   xmlns:dkey="http://www.w3.org/2009/xmlsec-dkey#"
>>>>   xmlns:kem="http://www.w3.org/2009/xmlsec-kem#">
>>>>   <xenc:EncryptionMethod
>>>>     Algorithm="http://www.w3.org/2009/xmlenc11#GenericHybridCipher">
>>>>     <kem:GenericHybridCipherMethod>
>>>>       <kem:KeyEncapsulationMethod
>>>>         Algorithm="http://www.w3.org/2009/xmlenc11#EC-KEM-KTS">
>>>>         <dkey:KeyDerivationMethod Algorithm="KDF2"/>
>>>>         <kem:KeyLen>16</kem:KeyLen>
>>>>       </kem:KeyEncapsulationMethod>
>>>>       <kem:DataEncapsulationMethod
>>>>         Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
>>>>     </kem:GenericHybridCipherMethod>
>>>>   </xenc:EncryptionMethod>
>>>>   <ds:KeyInfo>
>>>>     <dsig11:ECKeyValue>
>>>>       <dsig11:NamedCurve URI="urn:oid:1.2.840.10045.3.1.7"/>
>>>>       <dsig11:PublicKey>MIIB</dsig11:PublicKey>
>>>>     </dsig11:ECKeyValue>
>>>>   </ds:KeyInfo>
>>>>   <xenc:CipherData>
>>>>     <xenc:CipherValue>DEADBEEF</xenc:CipherValue>
>>>>   </xenc:CipherData>
>>>> </xenc:EncryptedKey>
>>>> 
>>>> In the above, what has happened is:
>>>> 
>>>> 1) EncryptionMethod is "GenericHybrid" - as in ISO/IEC 18033 and S/MIME
>>>> 2) There is a parameter set for GenericHybrid that gives
>>>>    a) the key encapsulation method (EC-KEM-KTS for Elliptic Curve Key
>>>>       Encapsulation Method - Key Transport Scheme (since we're doing key
>>>>       wrapping here), along with its params (derived key length and key
>>>>       derivation method, leveraging the DerivedKeys schema)
>>>>    b) the data encapsulation method (AES key wrap in this case)
>>>> 3) The key info does *not* need the AgreementMethod even though I
>>>>    suggested this earlier. I realized it is not needed as we have already
>>>>    specified the encapsulation scheme as EC-KEM-KTS, and so this
>>>>    element simply contains an ECKeyValue that is the recipient's public 
>>>> key
>>>> 4) The CipherData is the concatenation of the ephemeral public key of the
>>>>    originator (as an octet string) and the wrapped key.
>>>> 
>>>> For RSA, we would have the same structure, it is just that instead of the 
>>>> (algorithm identifier being RSA-KEM-KTS and the) ephemeral key we would 
>>>> have the CipherData consisting of the concatenation of the public-key 
>>>> encrypted random value and the wrapped key.
>>>> 
>>>> (And in addition this structure brings us pretty close to "ordinary" RSA 
>>>> key transport as Pratik was asking for.)
>>>> 
>>>> -- Magnus
>>>> 
>>> 
>>> 
>>> 
>
>
>