XML Security Generic Hybrid Ciphers

Editor's Draft 07 March 2010

$Revision: 1.5 $ $Date: 2010/03/08 16:37:07 $

This version:
http://www.w3.org/TR/2010/WD-xmlsec-generic-hybrid-20100307/
Latest version:
http://www.w3.org/TR/xmlsec-generic-hybrid/
Editor:
Magnus Nyström, Microsoft Corporation

Abstract

Generic hybrid ciphers allow for a consistent treatment of asymmetric ciphers when encrypting data and consist of a key encapsulation algorithm with associated parameters and a data encapsulation algorithm with associated parameters. Further, the key encapsulation algorithms introduced in this specification have attractive security properties.

This document augments XML Encryption Version 1.1 [XMLENC11] by defining algorithms, XML types and elements necessary to enable use of generic hybrid ciphers in XML Security applications.

Status of this Document

This document is an editors' copy that has no official standing.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the second Public Working Draft of "XML Security Generic Hybrid Ciphers".

This document was developed by the XML Security Working Group. The Working Group expects to advance this Working Draft to Recommendation Status.

Please send comments about this document to public-xmlsec-comments@w3.org (with public archive).

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1 Introduction
    1.1 Editorial
2 Versions, Namespaces and Identifiers
3 Generic Hybrid Ciphers Overview
4 Algorithms
    4.1 Algorithm Identifiers and Implementation Requirements
    4.2 Generic Hybrid Encryption Algorithms
        4.2.1 Generic-Hybrid
    4.3 Key Encapsulation Algorithms
        4.3.1 RSAES-KEM
        4.3.2 ECIES-KEM
5 Using Key Encapsulation Algorithms for Key Transport
6 Examples
    6.1 Key Transport Example
7 Security Considerations
8 Conformance
9 Acknowledgments
10 Schema
    10.1 XSD Schema and Valid Example
    10.2 RNG Schema
11 References
12 Change Log


1 Introduction

This document specifies an XML syntax and processing rules for generic hybrid ciphers and key encapsulation mechanisms based on [ISO18033-2]. The document augments XML Encryption [XMLENC11].

This document does not normatively specify when and how generic hybrid ciphers and key encapsulation mechanisms are to be used; rather it focuses on the basis for interoperability, namely the fundamental data types required for usage of these algorithms in XML-based security applications and the meaning of those data types, as well as identification of specific algorithms.

1.1 Editorial

The key words "MUST" and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [RFC2119]:

" they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm "

Consequently, these capitalized keywords are used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements. For instance, an XML attribute might be described as being "optional."

Note also that this entire specification is OPTIONAL; hence the keywords apply only when compliance with this specification is claimed.

2 Versions, Namespaces and Identifiers

No provision is made for an explicit version number in this syntax. If a future version is needed, it will use a different namespace. The XML namespace [XML-NS] URI that MUST be used by implementations of this (dated) specification is:

xmlns gh="http://www.w3.org/2009/xmlsec-gh#"

Warning: this namespace URI is currently subject to change.

This namespace is also used as the prefix for identifiers defined by this specification. While applications MUST support XML and XML namespaces, the use of internal entities or our gh XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.

This specification uses Uniform Resource Identifiers [RFC2396] to identify resources, algorithms, and semantics. The URI in the namespace declaration above is also used as a prefix for URIs under the control of this specification.

This document does not change the URI associated with XML Encryption itself.

3 Generic Hybrid Ciphers Overview

The term "generic hybrid cipher" is defined in [ISO18033-2] as an asymmetric cipher that combines both asymmetric and symmetric cryptographic techniques. Generic hybrid ciphers that meet the requirements laid out in [ISO18033-2] have attractive security properties. They are introduced in this document to enable applications to use cryptographic algorithms with tight security proofs.

Generic hybrid ciphers allow for a consistent treatment of asymmetric ciphers when encrypting data and consists of a key encapsulation algorithm with associated parameters and a data encapsulation algorithm with associated parameters. The key encapsulation algorithm results in an encapsulated shared key that is then used with the data encapsulation algorithm, e.g. for encryption.

4 Algorithms

This section discusses and identifies algorithms to be used with this specification. Entries contain the identifier to be used as the value of the Algorithm attribute of the EncryptionMethod element or other element representing the role of the algorithm, a reference to the formal specification, definitions for the representation of keys and the results of cryptographic operations where applicable, and general applicability comments.

4.1 Algorithm Identifiers and Implementation Requirements

This specification defines a set of algorithms, their URIs, and requirements for implementation. Levels of requirement specified, such as MUST or OPTIONAL, refer to implementation, not use.

Generic Hybrid Encryption
  1. MUST Generic-Hybrid http://www.w3.org/2009/xmlsec-gh#generic-hybrid
Key Encapsulation
  1. MUST RSAES-KEM http://www.w3.org/2009/xmlsec-gh#rsaes-kem
  2. MUST ECIES-KEM http://www.w3.org/2009/xmlsec-gh#ecies-kem

4.2 Generic Hybrid Encryption Algorithms

Generic-hybrid encryption algorithms combines both asymmetric and symmetric cryptographic techniques. Schema definition:

  <element name="GenericHybridCipherMethod" type="gh:GenericHybridCipherMethodType"/>
  <complexType name="GenericHybridCipherMethodType">
    <sequence>
      <element name="KeyEncapsulationMethod" type="gh:KeyEncapsulationMethodType"/>
      <element name="DataEncapsulationMethod" type="xenc:EncryptionMethodType"/>
    </sequence>
  </complexType>

The KeyEncapsulationMethod element identifies the key encapsulation method as well as provides values for its parameters.

The DataEncapsulationMethod element identifies the data encapsulation (encryption) method as well as provides any parameters associated with the data encapsulation method.

4.2.1 Generic-Hybrid

Identifier:
http://www.w3.org/2009/xmlsec-gh#generic-hybrid (REQUIRED)

The Generic-Hybrid encryption algorithm may be used for a variety of purposes; in particular, when used with a key encapsulation mechanism such as those specified in Section 4.3 Key Encapsulation Algorithms and a suitable key wrap algorithm, it can be used for key transport with tight security proofs.

The GenericHybridCipherMethod element shall appear as a child element of xenc:EncryptedData or xenc:EncryptedKey when Generic-Hybrid is specified as the Algorithm value of an xenc:EncryptedData or xenc:EncryptedKey element.

4.3 Key Encapsulation Algorithms

This document specifies two key encapsulation algorithms, RSAES-KEM and ECIES-KEM, for use with the Generic-Hybrid cipher in, e.g., key transport scenarios.

  <complexType name="KeyEncapsulationMethodType">
    <sequence>
      <element ref="xenc11:KeyDerivationMethod"/>
      <element name="KeyLen" type="positiveInteger"/>
      <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="Algorithm" type="anyURI" use="required"/>
  </complexType>

The xenc11:KeyDerivationMethod element of the KeyEncapsulationMethodType specifies a key derivation method to use when deriving a key from key material generated in accordance with the key encapsulation mechanism. The xenc11:KeyDerivationMethod element is defined in [XMLENC11]. The KeyLen element specifies length of the derived key. The Algorithm attribute identifies the actual key encapsulation method used.

4.3.1 RSAES-KEM

Identifier
http://www.w3.org/2009/xmlsec-gh#rsaes-kem (REQUIRED)

RSAES-KEM is a key encapsulation algorithm based on the RSA encryption scheme.

Given a recipient's public RSA key (n, e) where n is the RSA modulus and e is the public exponent, the following steps shall be taken to encapsulate a symmetric key when the RSAES-KEM key encapsulation algorithm is used (these are the same steps as specified in Section 11.5.3 of [ISO18033-2]):

  1. Generate a non-negative random number r less than the modulus n;
  2. Set R = I2OSP(r, len(n)) where I2OSP is the integer to octet string conversion specified in Section 4.1 of PKCS #1 [PKCS1] and len(n) is the length of the modulus n;
  3. Set c0 = RSAEP((n , e), r) where RSAEP is the RSA encryption primitive defined in Section 5.1.1 of PKCS #1 [PKCS1] (i.e. no padding);
  4. Set C0 = I2OSP(c0, len(n));
  5. Compute K = KDF(R, KeyLen, OtherInfo) where KDF is the key derivation function, KeyLen is the length of the encapsulated key and OtherInfo is optional other info (subject to the input parameters for the key derivation function, see [XMLENC11] Section 5.4);
  6. Output the key K and ciphertext C0.

Given a recipient's private RSA key (n, d) where n is the RSA modulus and d is the private exponent, the following steps shall be taken to decrypt an encapsulated symmetric key from ciphertext C0 when the RSAES-KEM key encapsulation algorithm is used (these are the same steps as specified in Section 11.5.4 of [ISO18033-2]):

  1. Set c0 = OS2IP(C0) where OS2IP is the octet string to integer conversion specified in Section 4.2 of PKCS #1 [PKCS1];
  2. Set r = RSADP((n , d), c0) where RSADP is the RSA decryption primitive defined in Section 5.1.2 of PKCS #1 [PKCS1] (i.e. no padding);
  3. Set R = I2OSP(r, len(n));
  4. Compute K = KDF(R, KeyLen, OtherInfo) where KDF is the key derivation function, KeyLen is the length of the encapsulated key and OtherInfo is optional other info (subject to the input parameters for the key derivation function, see [XMLENC11] Section 5.4);
  5. Output the secret key K.

For use of the RSAES-KEM key encapsulation algorithm with Key Transport, see Section 5 Using Key Encapsulation Algorithms for Key Transport.

4.3.2 ECIES-KEM

Identifier
http://www.w3.org/2009/xmlsec-gh#ecies-kem (REQUIRED)

ECIES-KEM is a key encapsulation algorithm based on the Elliptic Curve scheme.

Given a recipient's public EC key h and an elliptic curve E with base point g and order (size) o, the following steps shall be taken to encapsulate a symmetric key when the ECIES-KEM key encapsulation algorithm is used (these are the same steps as specified in Section 10.2.3 of [ISO18033-2]):

  1. Generate a positive random number r less than o;
  2. Compute the elliptic curve point G = r * g where * denotes scalar multiplication;
  3. Compute the elliptic curve point H = r * h;
  4. Set C0 = ENCODE ( G ) where ENCODE is the encoding of the elliptic curve point G as specified in Section 4.4.2 of [XMLDSIG11].
  5. Set P = ENCODE ( H ) where ENCODE is the encoding of the elliptic curve point H; since H is a point on the curve the encoding shall again be as specified in Section 4.4.2 of [XMLDSIG11];
  6. Set K = KDF( C0 | P, KeyLen, OtherInfo ) where KDF is the key derivation function, KeyLen is the length of the derived key and OtherInfo is optional other info (subject to the input parameters for the key derivation function, see [XMLENC11] Section 5.4);
  7. Output the key K and ciphertext C0.

Given a recipient's private EC key x and an elliptic curve E with base point g and order (size) o, the following steps shall be taken to decrypt an encapsulated symmetric key from ciphertext C0 when the ECIES-KEM key encapsulation algorithm is used (these are the same steps as specified in Section 10.2.4 of [ISO18033-2]):

  1. Set G = DECODE ( C0 ) where DECODE is the decoding function which is the reverse of the ENCODE function previously described;
  2. Compute the elliptic curve point H = x * G where * denotes scalar multiplication;
  3. If H = 0, then fail;
  4. Set P = ENCODE ( H ) where ENCODE is the encoding of the elliptic curve point H as specified in Section 4.4.2 of [XMLDSIG11].
  5. Set K = KDF( C0 | P, KeyLen, OtherInfo ) where KDF is the key derivation function, KeyLen is the length of the derived key and OtherInfo is optional other info (subject to the input parameters for the key derivation function, see [XMLENC11] Section 5.4);
  6. Output the secret key K.

For use of the ECIES-KEM key encapsulation algorithm with Key Transport, see Section 5 Using Key Encapsulation Algorithms for Key Transport.

5 Using Key Encapsulation Algorithms for Key Transport

When using a Key Encapsulation algorithm such as RSAES-KEM or ECIES-KEM for key transport, the key K which is one of the outputs of the KEM algorithm (see RSAES-KEM and ECIES-KEM) is now used as a wrapping key, encrypting a data-encryption key DEK: C1 = WRAP(K, DEK). The combined ciphertext C0 | C1 (where C0 is the other output of the KEM algorithm) is then placed in the xenc:CipherValue element of the xenc:CipherData child element of the xenc:EncryptedKey (the ds:KeyInfo element will identify the recipient's public key).

6 Examples

6.1 Key Transport Example

The following is a syntactically correct example of an xenc:EncryptedKey element using the Generic-Hybrid method together with the ECIES-KEM algorithm for key encapsulation and AES-128 KeyWrap for wrapping the content key using the encapsulated key (the example would look precisely the same when using the RSAES-KEM algorithm except for the identification of the Key Encapsulation Algorithm which instead would have the value "http://www.w3.org/2009/xmlsec-gh#rsaes-kem" and the identification of an RSA public key instead of an ECC key in the ds:KeyInfo element.)

Example: EncryptedKey element with Key Encapsulation
<xenc:EncryptedKey
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  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:xenc11="http://www.w3.org/2009/xmlenc11#"
  xmlns:gh="http://www.w3.org/2009/xmlsec-gh#"
  <xenc:EncryptionMethod
    Algorithm="http://www.w3.org/2009/xmlsec-gh#GenericHybrid">
    <gh:GenericHybridCipherMethod>
      <gh:KeyEncapsulationMethod
        Algorithm="http://www.w3.org/2009/xmlsec-gh#ecies-kem">
        <xenc11:KeyDerivationMethod Algorithm="http://www.w3.org/2009/xmlenc11#ConcatKDF">
          <xenc11:ConcatKDFParams AlgorithmID="0000" PartyUInfo="03D8" PartyVInfo="">
            <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
          </xenc11:ConcatKDFParams>
        <gh:KeyLen>16</gh:KeyLen>
      </gh:KeyEncapsulationMethod>
      <gh:DataEncapsulationMethod
        Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
    </gh:GenericHybridCipherMethod>
  </xenc:EncryptionMethod>
  <ds:KeyInfo>
    <dsig11:ECKeyValue>
      <dsig11:NamedCurve URI="urn:oid:1.2.840.10045.3.1.7"/>
      <dsig11:PublicKey>DEADBEEF</dsig11:PublicKey>
    </dsig11:ECKeyValue>
  </ds:KeyInfo>
  <xenc:CipherData>
    <xenc:CipherValue>DEADBEEF</xenc:CipherValue>
    <!-- Is concatenation of C0 (expressed as
    an octet string) and the wrapped key -->
  </xenc:CipherData>
</xenc:EncryptedKey>

7 Security Considerations

Generic hybrid ciphers with key encapsulation mechanisms as specified in this document provides a high security level assuming key derivation algorithms and other security parameters have been properly chosen. See further [ISO18033-2], Annex B for a deeper security discussion on these constructions.

8 Conformance

An implementation is conformant to this specification if it successfully generates syntax according to the schema definitions and satisfies any and all MUST/REQUIRED/SHALL requirements.

The full normative grammar is defined by the XSD schema and the normative text in this specification. The standalone XSD schema file is authoritative in case there is any disagreement between it and the XSD schema portions in this specification.

9 Acknowledgments

TBD

10 Schema

10.1 XSD Schema and Valid Example

XML Security Generic Hybrid Schema Instance
xmlsec-gh-schema.xsd

Valid XML schema instance based on the XML Schema Second Edition [XMLSchema1], [XMLSchema2].

XML Security Generic Hybrid Example
gh-example.xml

A cryptographically fabricated XML example that validates under the schema.

10.2 RNG Schema

Non-normative RELAX NG schema [RELAXNG-SCHEMA] information is available in a separate document [XMLSEC-RELAXNG].

11 References

ISO18033-2
ISO/IEC 18033-2:2006: Information technology -- Security techniques -- Encryption algorithms -- Part 2: Asymmetric ciphers, International Organization for Standardization, May 2006, http://www.iso.org/iso/home.htm.
PKCS1
Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1, Jonsson, J., and Kaliski, B. February 2003. http://ietf.org/rfc/rfc3447.txt
RELAXNG-SCHEMA
XML Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG. ISO/IEC 19757-2:2008. http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
RFC2119
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF RFC 2119, March 1997, http://ietf.org/rfc/rfc2119.txt.
RFC2396
Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter. IETF RFC 2396, August 1998, http://ietf.org/rfc/rfc2396.txt.
XML-NS
Namespaces in XML, T. Bray, D. Hollander, A. Layman. W3C Recommendation, January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114.
XMLDSIG11
XML Signature Syntax and Processing Version 1.1 , D. Eastlake, et al, W3C Working Draft, 2009, http://www.w3.org/208/xmlsec/Drafts/xmldsig-core-11/
XMLENC11
XML Encryption Syntax and Processing Version 1.1 , D. Eastlake, J. Reagle, W3C Working Draft, 2010, http://www.w3.org/2008/xmlsec/Drafts/xmlenc-core-11/
XMLSEC-RELAXNG
XML Security RELAX NG Schemas. Frederick Hirsch. 16 March 2010. W3C Working Draft. (Work in progress.) http://www.w3.org/TR/2010/WD-xmlsec-rngschema-20100316/
XMLSchema1
XML Schema Part 1: Structures Second Edition, W3C Recommendation 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.
XMLSchema2
XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.

12 Change Log

Date Author Description
20090616 MN Initial draft
20090623 MN Corrections based on FJH's review.
20100114 FJH Add clarification on authoritative schema per ACTION-493
20100302 FJH Add RNG schema section.