XML Security Derived Keys

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

3.1 Introduction

These scenarios are for illustrative purposes only and is not to be seen as inclusive. Clearly there are many more usages for derived keys than described in these scenarios.

3.2 Passphrase-based Derived Keys

In this scenario, two users, Alice and Bob, need to exchange encrypted data by use of XML Encryption. They agree on a password that they both can remember. Alice then derives a cryptographic key from this password, encrypts the data using the derived key, and provides information about the used password and the key derivation technique in the XML instance containing the encrypted data. Bob, recognizing which password has been used (possibly through a password hint conveyed in the MasterKeyName element, see below), provides the password to his local application which then decrypts the data for him.

3.3 Digital Signatures Using Derived Keys

An application has access to a long-term secret (cryptographic key) but in order to reduce exposure of this secret it periodically derives short-lived keying material from the secret, e.g. by hashing the long-term secret with the current time. The short-lived keying material is then used to digitally sign messages (e.g. to integrity-protect an event log). In this case, the application signs the messages using XML Signature and indicates in the instance document the master keying material as well as the method used to derive the actual signing key (along with any other information required to verify the signature such as the time used).

3.4 Key Separation

An application has access to a long-term secret but needs to make use of this secret for multiple purposes. For key separation purposes, it therefore derives multiple keys (one derived key for each usage) from the long-term secret and use the derived keys instead of the secret when performing the cryptographic operations.

5.1 The DerivedKey Element

Type="http://www.w3.org/2009/01/xmlsec-derived-key#DerivedKey

(This can be used within a ds:RetrievalMethod element to identify the referent's type.)

The DerivedKey element is used to transport information about a derived key from the originator to recipient(s). It may be used as a stand-alone XML document, be placed within an application document, or appear inside an EncryptedData or Signature element as a child of a ds:KeyInfo element. The key value itself is never sent by the originator. Rather, the originator provides information to the recipient(s) by which the recipient(s) can derive the same key value. When the key has been derived the resulting octets are made available to the EncryptionMethod or SignatureMethod algorithm without any additional processing.

5.2 Schema Definition

<element name="DerivedKey" type="dkey:DerivedKeyType"/> 
   <complexType name="DerivedKeyType">
  <sequence>
    <element ref="dkey:KeyDerivationMethod" minOccurs="0"/>
    <element ref="xenc:ReferenceList" minOccurs="0"/>
    <element name="CarriedKeyName" type="string" minOccurs="0"/>
    <element name="MasterKeyName" type="string" minOccurs="0"/>
  </sequence>
  <attribute name="Recipient" type="string" use="optional"/>
  <attribute name="Id" type="ID" use="optional"/>
  <attribute name="Type" type="anyURI" use="optional"/>
</complexType>

<element name="KeyDerivationMethod" type="dkey:KeyDerivationMethodType"/>
<complexType name="KeyDerivationMethodType">
  <sequence>
    <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
  </sequence>
  <attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>

KeyDerivationMethod is an optional element that describes the key derivation algorithm applied to the master (underlying) key material. If the element is absent, the key derivation algorithm must be known by the recipient or the recipient's key derivation will fail.

ReferenceList is an optional element containing pointers to data and keys encrypted using this key. The reference list may contain multiple references to EncryptedKey or EncryptedData elements. This is done using KeyReference and DataReference elements from XML Encryption.

The CarriedKeyName element is used to identify the derived key value which may be referenced by the KeyName element in ds:KeyInfo.

MasterKeyName is an optional element for associating a user readable name with the master key (or secret) value. This element may also be used to reference the key using the ds:KeyName element within ds:KeyInfo. The same MasterKeyName label, unlike an ID type, may occur multiple times within a single document. The value of the master key is to be the same in all DerivedKey elements identified with the same MasterKeyName label within a single XML document. Note that because whitespace is significant in the value of the ds:KeyName element, whitespace is also significant in the value of the MasterKeyName element. If no MasterKeyName is provided, the master key material must be known by the recipient or key derivation will fail.

Recipient is an optional attribute that contains a hint as to which recipient this derived key value is intended for. Its contents are application dependent.

The optional Id attribute provides for the standard method of assigning a string id to the element within the document context.

The Type attribute can be used to further specify the type of the derived key if the KeyDerivationMethod algorithm does not define an unambiguous encoding/representation.

7.1 Passphrase-based Data Encryption

In this (fictitious, but syntactically correct) example, which builds on PKCS #5 v2.0 Amendment 1, a derived key element is illustrated. The underlying passphrase is identified by the name "Our shared secret".

<dkey:DerivedKey
   xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
   xmlns:pkcs-5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#">
   <dkey:KeyDerivationMethod 
       Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
     <pkcs-5:PBKDF2-params>
       <Salt>
         <Specified>Df3dRAhjGh8=</Specified>
       </Salt>
       <IterationCount>2000</IterationCount>
       <KeyLength>16</KeyLength>
       <PRF/>
     </pkcs-5:PBKDF2-params>
   </dkey:KeyDerivationMethod>
   <xenc:ReferenceList>
     <xenc:DataReference URI="#ED"/>
   </xenc:ReferenceList>
   <dkey:MasterKeyName>Our shared secret</dkey:MasterKeyName>
</dkey:DerivedKey>

8.1 General

As derived keys are to be used with XML Signature and XML Encryption, the security considerations of those specifications applies.

8.2 Use of Passwords

The usual warnings and recommendations apply when basing security schemes on passwords to be remembered by users. In particular, bad choices for the MasterKeyName may provide an attacker with information which can simplify brute-force attacks. As an example, using "My Spouse's Name" as the value of the MasterKeyName element would not be a good choice (if the value of the master key (password) is the user's spouse's name, that is).