Internet Engineering Task Force (IETF) P. Hoyer
Request for Comments: 6030 ActivIdentity
Category: Standards Track M. Pei
ISSN: 2070-1721 VeriSign
S. Machani
Diversinet
October 2010
Portable Symmetric Key Container (PSKC)
Abstract
This document specifies a symmetric key format for the transport and
provisioning of symmetric keys to different types of crypto modules.
For example, One-Time Password (OTP) shared secrets or symmetric
cryptographic keys to strong authentication devices. A standard key
transport format enables enterprises to deploy best-of-breed
solutions combining components from different vendors into the same
infrastructure.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6030.
Hoyer, et al. Standards Track [Page 1]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................4
1.1. Key Words ..................................................4
1.2. Version Support ............................................4
1.3. Namespace Identifiers ......................................5
1.3.1. Defined Identifiers .................................5
1.3.2. Referenced Identifiers ..............................5
2. Terminology .....................................................6
3. Portable Key Container Entities Overview and Relationships ......6
4. Element: The Basics ..............................8
4.1. : Embedding Keying Material and Key-Related
Information ................................................8
4.2. Key Value Encoding ........................................10
4.2.1. AES Key Value Encoding .............................11
4.2.2. Triple-DES Key Value Encoding ......................11
4.3. Transmission of Supplementary Information .................12
4.3.1. Element: Unique Device
Identification .....................................13
4.3.2. Element: CryptoModule
Identification .....................................15
4.3.3. Element: User Identification ..............15
4.3.4. Element:
Supplementary Information for OTP and CR Algorithms 15
4.4. Transmission of Key Derivation Values .....................17
5. Key Policy .....................................................19
5.1. PIN Algorithm Definition ..................................23
6. Key Protection Methods .........................................23
6.1. Encryption Based on Pre-Shared Keys .......................24
6.1.1. MAC Method .........................................26
6.2. Encryption Based on Passphrase-Based Keys .................27
6.3. Encryption Based on Asymmetric Keys .......................29
Hoyer, et al. Standards Track [Page 2]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
6.4. Padding of Encrypted Values for Non-Padded
Encryption Algorithms .....................................31
7. Digital Signature ..............................................31
8. Bulk Provisioning ..............................................33
9. Extensibility ..................................................35
10. PSKC Algorithm Profile ........................................36
10.1. HOTP .....................................................36
10.2. PIN ......................................................37
11. XML Schema ....................................................38
12. IANA Considerations ...........................................44
12.1. Content-Type Registration for 'application/pskc+xml' .....44
12.2. XML Schema Registration ..................................45
12.3. URN Sub-Namespace Registration ...........................46
12.4. PSKC Algorithm Profile Registry ..........................46
12.5. PSKC Version Registry ....................................47
12.6. Key Usage Registry .......................................47
13. Security Considerations .......................................48
13.1. PSKC Confidentiality .....................................49
13.2. PSKC Integrity ...........................................50
13.3. PSKC Authenticity ........................................50
14. Contributors ..................................................50
15. Acknowledgements ..............................................50
16. References ....................................................51
16.1. Normative References .....................................51
16.2. Informative References ...................................52
Appendix A. Use Cases ............................................54
A.1. Online Use Cases ..........................................54
A.1.1. Transport of Keys from Server to Cryptographic
Module ................................................54
A.1.2. Transport of Keys from Cryptographic Module to
Cryptographic Module ..................................54
A.1.3. Transport of Keys from Cryptographic Module to
Server ................................................55
A.1.4. Server-to-Server Bulk Import/Export of Keys ...........55
A.2. Offline Use Cases .........................................55
A.2.1. Server-to-Server Bulk Import/Export of Keys ...........55
Appendix B. Requirements .........................................56
Hoyer, et al. Standards Track [Page 3]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
1. Introduction
With the increasing use of symmetric-key-based systems, such as
encryption of data at rest or systems used for strong authentication,
such as those based on One-Time Password (OTP) and Challenge/Response
(CR) mechanisms, there is a need for vendor interoperability and a
standard format for importing and exporting (provisioning) symmetric
keys. For instance, traditionally, vendors of authentication servers
and service providers have used proprietary formats for importing and
exporting these keys into their systems, thus making it hard to use
tokens from two different vendors.
This document defines a standardized XML-based key container, called
Portable Symmetric Key Container (PSKC), for transporting symmetric
keys and key-related metadata. The document also specifies the
information elements that are required when the symmetric key is
utilized for specific purposes, such as the initial counter in the
HMAC-Based One-Time Password (HOTP) [HOTP] algorithm. It also
creates an IANA registry for algorithm profiles where algorithms,
their metadata and PSKC transmission profile can be recorded for a
centralized, standardized reference.
1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Version Support
There is a provision made in the syntax for an explicit version
number. Only version "1.0" is currently specified.
The numbering scheme for PSKC versions is ".". The
major and minor numbers MUST be treated as separate integers and each
number MAY be incremented higher than a single digit. Thus, "PSKC
2.4" would be a lower version than "PSKC 2.13", which in turn would
be lower than "PSKC 12.3". Leading zeros (e.g., "PSKC 6.01") MUST be
ignored by recipients and MUST NOT be sent.
The major version number should be incremented only if the message
format (e.g., element structure) has changed so dramatically that an
older version implementation would not be able to interoperate with a
newer version. The minor version number indicates new capabilities,
and it MUST be ignored by an entity with a smaller minor version
number but used for informational purposes by the entity with the
larger minor version number.
Hoyer, et al. Standards Track [Page 4]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
1.3. Namespace Identifiers
This document uses Uniform Resource Identifiers (URIs) [RFC3986] to
identify resources, algorithms, and semantics.
1.3.1. Defined Identifiers
The XML namespace [XMLNS] URI for Version 1.0 of PSKC is:
"urn:ietf:params:xml:ns:keyprov:pskc"
References to qualified elements in the PSKC schema defined in this
specification and used in the example use the prefix "pskc" (defined
as xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"). It is
RECOMMENDED to use this namespace in implementations.
1.3.2. Referenced Identifiers
The PSKC syntax presented in this document relies on algorithm
identifiers and elements defined in the XML Signature [XMLDSIG]
namespace:
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
References to the XML Signature namespace are represented by the
prefix "ds".
PSKC also relies on algorithm identifiers and elements defined in the
XML Encryption [XMLENC] namespace:
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
References to the XML Encryption namespace are represented by the
prefix "xenc".
When protecting keys in transport with passphrase-based keys, PSKC
also relies on the derived key element defined in the XML Encryption
Version 1.1 [XMLENC11] namespace:
xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
References to the XML Encryption Version 1.1 namespace are
represented by the prefix "xenc11".
When protecting keys in transport with passphrase-based keys, PSKC
also relies on algorithm identifiers and elements defined in the PKCS
#5 [PKCS5] namespace:
Hoyer, et al. Standards Track [Page 5]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
References to the PKCS #5 namespace are represented by the prefix
"pkcs5".
2. Terminology
NOTE: In subsequent sections of the document, we highlight
**mandatory** XML elements and attributes. Optional elements and
attributes are not explicitly indicated, i.e., if it does not say
mandatory, it is optional.
3. Portable Key Container Entities Overview and Relationships
The portable key container is based on an XML schema definition and
contains the following main conceptual entities:
1. KeyContainer entity - representing the container that carries a
number of KeyPackage entities. A valid container MUST carry at
least one KeyPackage entity.
2. KeyPackage entity - representing the package of at most one key
and its related provisioning endpoint or current usage endpoint,
such as a physical or virtual device and a specific CryptoModule.
3. DeviceInfo entity - representing the information about the device
and criteria to identify uniquely the device.
4. CryptoModuleInfo entity - representing the information about the
CryptoModule where the keys reside or to which they are
provisioned.
5. Key entity - representing the key transported or provisioned.
6. Data entity - representing a list of metadata related to the key,
where the element name is the name of the metadata and its
associated value is either in encrypted (for example, for
element ) or plaintext (for example, the element
) form.
Figure 1 shows the high-level structure of the PSKC data elements.
Hoyer, et al. Standards Track [Page 6]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
-----------------
| KeyContainer |
|---------------|
| EncryptionKey |
| Signature |
| ... |
-----------------
|
|
/|\ 1..n
---------------- ----------------
| KeyPackage | 0..1| DeviceInfo |
|--------------|--------|--------------|
| |-- | SerialNumber |
---------------- | | Manufacturer |
| | | .... |
| | ----------------
/|\ 0..1 |
---------------- | --------------------
| Key | | 0..1| CryptoModuleInfo |
|--------------| -----|------------------|
| Id | | Id |
| Algorithm | |.... |
| UserId | --------------------
| Policy |
| .... |
----------------
|
|
/|\ 0..n
--------------------------------------- - -
| | |
------------------ ---------------- -------- - -
| Data:Secret | | Data:Counter | | Data:other
|----------------| |--------------| |-- - -
| EncryptedValue | | PlainValue |
| ValueMAC | ----------------
------------------
Figure 1: PSKC Data Elements Relationship Diagram
The following sections describe in detail all the entities and
related XML schema elements and attributes.
Hoyer, et al. Standards Track [Page 7]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
4. Element: The Basics
In its most basic form, a PSKC document uses the top-level element
and a single element to carry key
information.
The following example shows a simple PSKC document. We will use it
to describe the structure of the element and its child
elements.
Issuer-AMTIzNA==
Figure 2: Basic PSKC Key Container Example
The attributes of the element have the following
semantics:
'Version': The 'Version' attribute is used to identify the version
of the PSKC schema version. This specification defines the
initial version ("1.0") of the PSKC schema. This attribute MUST
be included.
'Id': The 'Id' attribute carries a unique identifier for the
container. As such, it helps to identify a specific key container
in cases in which multiple containers are embedded in larger XML
documents.
4.1. : Embedding Keying Material and Key-Related Information
The following attributes of the element MUST be included at a
minimum:
Hoyer, et al. Standards Track [Page 8]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
'Id': This attribute carries a unique identifier for the symmetric
key in the context of key provisioning exchanges between two
parties. This means that if PSKC is used in multiple interactions
between a sending and receiving party, using different containers
referencing the same keys, the 'Id' attribute of MUST use
the same value (e.g., after initial provisioning, if a system
wants to update key metadata values in the other system, the value
of the 'Id' attribute of the where the metadata is to be
updated MUST be the same of the original 'Id' attribute value
provisioned). The identifier is defined as a string of
alphanumeric characters.
'Algorithm': This attribute contains a unique identifier for the
PSKC algorithm profile. This profile associates specific
semantics to the elements and attributes contained in the
element. This document describes profiles for open standards
algorithms in Section 10. Additional profiles are defined in the
following informative document: [PSKC-ALGORITHM-PROFILES].
The element has a number of optional child elements. An
initial set is described below:
: This element represents the name of the party that issued
the key. For example, a bank "Foobar Bank, Inc." issuing hardware
tokens to their retail banking users may set this element to
'Foobar Bank, Inc.'.
: A human-readable name for the secret key for easier
reference. This element serves informational purposes only. This
element is a language-dependent string; hence, it SHOULD have an
attribute xml:lang="xx" where xx is the language identifier as
specified in [RFC5646]. If no xml:lang attribute is present,
implementations MUST assume the language to be English as defined
by setting the attribute value to 'en' (e.g., xml:lang="en").
: This element carries parameters that
influence the result of the algorithmic computation, for example,
response truncation and format in OTP and CR algorithms. A more
detailed discussion of the element can be found in Section 4.3.4.
: This element carries data about and related to the key. The
following child elements are defined for the element:
: This element carries the value of the key itself in a
binary representation. Please see Section 4.2 for more details
on Key Value Encoding.
Hoyer, et al. Standards Track [Page 9]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
: This element contains the event counter for event-
based OTP algorithms.
: This element contains the time for time-based OTP
algorithms. (If time intervals are used, this element carries
the number of time intervals passed from a specific start
point, normally it is algorithm dependent).
: This element carries the time interval value for
time-based OTP algorithms in seconds (a typical value for this
would be 30, indicating a time interval of 30 seconds).
: This element contains the device clock drift value
for time-based OTP algorithms. The integer value (positive or
negative drift) that indicates the number of time intervals
that a validation server has established the device clock
drifted after the last successful authentication. So, for
example, if the last successful authentication established a
device time value of 8 intervals from a specific start date but
the validation server determines the time value at 9 intervals,
the server SHOULD record the drift as -1.
All the elements listed above (and those defined in the future)
obey a simple structure in that they MUST support child elements
to convey the data value in either plaintext or encrypted format:
Plaintext: The element carries a plaintext value
that is typed, for example, to xs:integer.
Encrypted: The element carries an encrypted
value.
ValueMAC: The element is populated with a Message
Authentication Code (MAC) generated from the encrypted value in
case the encryption algorithm does not support integrity
checks. The example shown in Figure 2 illustrates the usage of
the element with two child elements, namely and
. Both elements carry a plaintext value within the
child element.
4.2. Key Value Encoding
Two parties receiving the same key value OCTET STRING, resulting in
decoding the xs:base64Binary, inside the or
elements, must make use of the key in exactly the
same way in order to interoperate. To ensure that, it is necessary
to define a correspondence between the OCTET STRING and the notation
in the standard algorithm description that defines how the key is
Hoyer, et al. Standards Track [Page 10]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
used. The next sections establish that correspondence for the AES
algorithm [FIPS197] and the Triple Data Encryption Algorithm (TDEA or
Triple DES) [SP800-67]. Unless otherwise specified for a specific
algorithm, the OCTET STRING encoding MUST follow the AES Key Value
Encoding.
4.2.1. AES Key Value Encoding
[FIPS197], Section 5.2, titled "Key Expansion", uses the input key as
an array of bytes indexed starting at 0. The first octet of the
OCTET STRING SHALL become the key byte in the AES, labeled index 0 in
[FIPS197]; the succeeding octets of the OCTET STRING SHALL become key
bytes in AES, in increasing index order.
Proper parsing and key load of the contents of the OCTET STRING for
AES SHALL be determined by using the following value for the
element (binaryBase64-encoded) to generate and match the
key expansion test vectors in [FIPS197], Appendix A, for AES
Cipher Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
...
K34VFiiu0qar9xWICc9PPA==
...
4.2.2. Triple-DES Key Value Encoding
A Triple-DES key consists of three keys for the cryptographic engine
(Key1, Key2, and Key3) that are each 64 bits (56 key bits and 8
parity bits); the three keys are also collectively referred to as a
key bundle [SP800-67]. A key bundle may employ either two or three
independent keys. When only two independent keys are employed
(called two-key Triple DES), the same value is used for Key1 and
Key3.
Each key in a Triple-DES key bundle is expanded into a key schedule
according to a procedure defined in [SP800-67], Appendix A. That
procedure numbers the bits in the key from 1 to 64, with number 1
being the leftmost, or most significant bit (MSB). The first octet
of the OCTET STRING SHALL be bits 1 through 8 of Key1 with bit 1
being the MSB. The second octet of the OCTET STRING SHALL be bits 9
through 16 of Key1, and so forth, so that the trailing octet of the
OCTET STRING SHALL be bits 57 through 64 of Key3 (or Key2 for two-key
Triple DES).
Hoyer, et al. Standards Track [Page 11]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
Proper parsing and key load of the contents of the OCTET STRING for
Triple DES SHALL be determined by using the following
element (binaryBase64-encoded) to generate and match the key
expansion test vectors in [SP800-67], Appendix B, for the key bundle:
Key1 = 0123456789ABCDEF
Key2 = 23456789ABCDEF01
Key3 = 456789ABCDEF0123
...
ASNFZ4mrze8jRWeJq83vAUVniavN7wEj
...
4.3. Transmission of Supplementary Information
A PSKC document can contain a number of additional information
regarding device identification, cryptographic module identification,
user identification, and parameters for usage with OTP and CR
algorithms. The following example, see Figure 3, is used as a
reference for the subsequent sub-sections.
Hoyer, et al. Standards Track [Page 12]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
Manufacturer987654321DC=example-bank,DC=netCM_ID_001IssuerMTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
0UID=jsmith,DC=example-bank,DC=net
Figure 3: PSKC Key Container Example with Supplementary Data
4.3.1. Element: Unique Device Identification
The element uniquely identifies the device to which the
is provisioned. Since devices can come in different
form factors, such as hardware tokens, smart-cards, soft tokens in a
mobile phone, or as a PC, this element allows different child element
combinations to be used. When combined, the values of the child
elements MUST uniquely identify the device. For example, for
hardware tokens, the combination of and
elements uniquely identifies a device, but the element
alone is insufficient since two different token manufacturers might
issue devices with the same serial number (similar to the Issuer
Distinguished Name and serial number of a certificate).
Hoyer, et al. Standards Track [Page 13]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
The element has the following child elements:
: This element indicates the manufacturer of the
device. Values for the element MUST be taken from
either [OATHMAN] prefixes (i.e., the left column) or from the IANA
Private Enterprise Number Registry [IANAPENREG], using the
Organization value. When the value is taken from [OATHMAN],
"oath." MUST be prepended to the value (e.g., "oath."). When the value is taken from [IANAPENREG],
"iana." MUST be prepended to the value (e.g., "iana.").
: This element contains the serial number of the device.
: This element describes the model of the device (e.g., one-
button-HOTP-token-V1).
: This element contains the issue number in case there are
devices with the same serial number so that they can be
distinguished by different issue numbers.
: This element allows a provisioning server to ensure
that the key is going to be loaded into the device for which the
key provisioning request was approved. The device is bound to the
request using a device identifier, e.g., an International Mobile
Equipment Identity (IMEI) for the phone, or an identifier for a
class of identifiers, e.g., those for which the keys are protected
by a Trusted Platform Module (TPM).
and : These two elements indicate the start
and end date of a device (such as the one on a payment card, used
when issue numbers are not printed on cards). The date MUST be
expressed as a dateTime value in "canonical representation"
[W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely
on time resolution finer than milliseconds and MUST NOT generate
time instants that specify leap seconds. Keys that reside on the
device SHOULD only be used when the current date is after the
and before the . Note that usage
enforcement of the keys with respect to the dates MAY only happen
on the validation server, as some devices such as smart cards do
not have an internal clock. Systems thus SHOULD NOT rely upon the
device to enforce key usage date restrictions.
Depending on the device type, certain child elements of the
element MUST be included in order to uniquely identify a
device. This document does not enumerate the different device types
and therefore does not list the elements that are mandatory for each
type of device.
Hoyer, et al. Standards Track [Page 14]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
4.3.2. Element: CryptoModule Identification
The element identifies the cryptographic module to
which the symmetric keys are or have been provisioned. This allows
the identification of the specific cases where a device MAY contain
more than one crypto module (e.g., a PC hosting a TPM and a connected
token).
The element has a single child element that MUST
be included:
: This element carries a unique identifier for the CryptoModule
and is implementation specific. As such, it helps to identify a
specific CryptoModule to which the key is being or was
provisioned.
4.3.3. Element: User Identification
The element identifies the user of a distinguished name, as
defined in [RFC4514], for example, UID=jsmith,DC=example,DC=net.
Although the syntax of the user identifier is defined, there are no
semantics associated with this element, i.e., there are no checks
enforcing that only a specific user can use this key. As such, this
element is for informational purposes only.
This element may appear in two places, namely as a child element of
the element, where it indicates the user with whom the key is
associated, and as a child element of the element, where
it indicates the user with whom the device is associated.
4.3.4. Element: Supplementary Information for OTP
and CR Algorithms
The element is a child element of the
element, and this document defines three child elements: ,
, and .
:
The optional element defines additional characteristics of
the algorithm used, which are algorithm specific. For example, in
an HMAC-based (Hashed MAC) OTP algorithm, it could designate the
strength of the hash algorithm used (SHA1, SHA256, etc.). Please
refer to the algorithm profile section, Section 10, for the exact
semantics of the value for each algorithm profile.
Hoyer, et al. Standards Track [Page 15]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
:
The element defines the characteristics of the
challenge in a CR usage scenario whereby the following attributes
are defined:
'Encoding': This attribute, which MUST be included, defines the
encoding of the challenge accepted by the device and MUST be
one of the following values:
DECIMAL: Only numerical digits
HEXADECIMAL: Hexadecimal response
ALPHANUMERIC: All letters and numbers (case sensitive)
BASE64: Base-64 encoded, as defined in Section 4 of [RFC4648]
BINARY: Binary data
'CheckDigit': This attribute indicates whether a device needs to
check the appended Luhn check digit, as defined in
[ISOIEC7812], contained in a challenge. This is only valid if
the 'Encoding' attribute is set to 'DECIMAL'. A value of TRUE
indicates that the device will check the appended Luhn check
digit in a provided challenge. A value of FALSE indicates that
the device will not check the appended Luhn check digit in the
challenge.
'Min': This attribute defines the minimum size of the challenge
accepted by the device for CR mode and MUST be included. If
the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or
'ALPHANUMERIC', this value indicates the minimum number of
digits/characters. If the 'Encoding' attribute is set to
'BASE64' or 'BINARY', this value indicates the minimum number
of bytes of the unencoded value.
'Max': This attribute defines the maximum size of the challenge
accepted by the device for CR mode and MUST be included. If
the 'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or
'ALPHANUMERIC', this value indicates the maximum number of
digits/characters. If the 'Encoding' attribute is set to
'BASE64' or 'BINARY', this value indicates the maximum number
of bytes of the unencoded value.
Hoyer, et al. Standards Track [Page 16]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
:
The element defines the characteristics of the
result of a computation and defines the format of the OTP or the
response to a challenge. For cases in which the key is a PIN
value, this element contains the format of the PIN itself (e.g.,
DECIMAL, length 4 for a 4-digit PIN). The following attributes
are defined:
'Encoding': This attribute defines the encoding of the response
generated by the device, it MUST be included and MUST be one of
the following values: DECIMAL, HEXADECIMAL, ALPHANUMERIC,
BASE64, or BINARY.
'CheckDigit': This attribute indicates whether the device needs
to append a Luhn check digit, as defined in [ISOIEC7812], to
the response. This is only valid if the 'Encoding' attribute
is set to 'DECIMAL'. If the value is TRUE, then the device
will append a Luhn check digit to the response. If the value
is FALSE, then the device will not append a Luhn check digit to
the response.
'Length': This attribute defines the length of the response
generated by the device and MUST be included. If the
'Encoding' attribute is set to 'DECIMAL', 'HEXADECIMAL', or
ALPHANUMERIC, this value indicates the number of digits/
characters. If the 'Encoding' attribute is set to 'BASE64' or
'BINARY', this value indicates the number of bytes of the
unencoded value.
4.4. Transmission of Key Derivation Values
element, which is a child element of the
element, carries a unique identifier used between the sending and
receiving parties to establish a set of key attribute values that are
not transmitted within the container but are agreed upon between the
two parties out of band. This element will then represent the unique
reference to a set of key attribute values. (For example, a smart
card application personalization profile id related to specific
attribute values present on a smart card application that have
influence when computing a response).
For example, in the case of MasterCard's Chip Authentication Program
[CAP], the sending and the receiving party would agree that
KeyProfileId='1' represents a certain set of values (e.g., Internet
Authentication Flag (IAF) set to a specific value). During
transmission of the , these values would not be
transmitted as key attributes but would only be referred to via the
Hoyer, et al. Standards Track [Page 17]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
element set to the specific agreed-upon profile (in
this case '1'). The receiving party can then associate all relevant
key attributes contained in the profile that was agreed upon out of
band with the imported keys. Often, this methodology is used between
a manufacturing service, run by company A, and the validation
service, run by company B, to avoid repeated transmission of the same
set of key attribute values.
The element contains a reference to an external key to
be used with a key derivation scheme. In this case, the parent
element will not contain the subelement of , in which
the key value (secret) is transported; only the reference to the
external master key is transported (e.g., a PKCS #11 key label).
Manufacturer987654321CM_ID_001IssuerkeyProfile1MasterKeyLabel
0OTP
Figure 4: Example of a PSKC Document Transmitting an HOTP Key via Key
Derivation Values
Hoyer, et al. Standards Track [Page 18]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
The key value will be derived using the value of the
element, values agreed upon between the sending and the receiving
parties and identified by the 'keyProfile1', and an
externally agreed-upon key referenced by the label 'MasterKeyLabel'.
5. Key Policy
This section illustrates the functionality of the element
within PSKC, which allows a key usage and key PIN protection policy
to be attached to a specific key and its related metadata. This
element is a child element of the element.
If the element contains child elements or values within
elements/attributes that are not understood by the recipient of the
PSKC document, then the recipient MUST assume that key usage is not
permitted. This statement ensures that the lack of understanding of
certain extensions does not lead to unintended key usage.
We will start our description with an example that expands the
example shown in Figure 3.
Manufacturer987654321CM_ID_001IssuerMTIzNDU2Nzg5MDEyMzQ1Njc4OTA=
0
Hoyer, et al. Standards Track [Page 19]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
OTPManufacturer987654321CM_ID_001IssuerMTIzNA==
Figure 5: Non-Encrypted HOTP Secret Key Protected by PIN
This document defines the following child elements:
and : These two elements denote the validity
period of a key. It MUST be ensured that the key is only used
between the start and the end date (inclusive). The date MUST be
expressed as a dateTime value in "canonical representation"
[W3C.REC-xmlschema-2-20041028]. Implementations SHOULD NOT rely
on time resolution finer than milliseconds and MUST NOT generate
time instants that specify leap seconds. When this element is
absent, the current time is assumed as the start time.
Hoyer, et al. Standards Track [Page 20]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
: The value in this element indicates the
maximum number of times a key carried within the PSKC document can
be used by an application after having received it. When this
element is omitted, there is no restriction regarding the number
of times a key can be used.
: The element puts constraints on the intended
usage of the key. The recipient of the PSKC document MUST enforce
the key usage. Currently, the following tokens are registered by
this document:
OTP: The key MUST only be used for OTP generation.
CR: The key MUST only be used for Challenge/Response purposes.
Encrypt: The key MUST only be used for data encryption purposes.
Integrity: The key MUST only be used to generate a keyed message
digest for data integrity or authentication purposes.
Verify: The key MUST only be used to verify a keyed message
digest for data integrity or authentication purposes (this is
the opposite key usage of 'Integrity').
Unlock: The key MUST only be used for an inverse Challenge/
Response in the case where a user has locked the device by
entering a wrong PIN too many times (for devices with PIN-input
capability).
Decrypt: The key MUST only be used for data decryption purposes.
KeyWrap: The key MUST only be used for key wrap purposes.
Unwrap: The key MUST only be used for key unwrap purposes.
Derive: The key MUST only be used with a key derivation function
to derive a new key (see also Section 8.2.4 of [NIST800-57]).
Generate: The key MUST only be used to generate a new key based
on a random number and the previous value of the key (see also
Section 8.1.5.2.1 of [NIST800-57]).
The element MAY also be repeated to allow several key usages to be
expressed. When this element is absent, no key usage constraint
is assumed, i.e., the key MAY be utilized for every usage.
Hoyer, et al. Standards Track [Page 21]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
: The element allows policy about the PIN
usage to be associated with the key. The following attributes are
specified:
'PINKeyId': This attribute carries the unique 'Id' attribute vale
of the element held within this that
contains the value of the PIN that protects the key.
'PINUsageMode': This mandatory attribute indicates the way the
PIN is used during the usage of the key. The following values
are defined:
Local: This value indicates that the PIN is checked locally on
the device before allowing the key to be used in executing
the algorithm.
Prepend: This value indicates that the PIN is prepended to the
algorithm response; hence, it MUST be checked by the party
validating the response.
Append: This value indicates that the PIN is appended to the
algorithm response; hence, it MUST be checked by the party
validating the response.
Algorithmic: This value indicates that the PIN is used as part
of the algorithm computation.
'MaxFailedAttempts': This attribute indicates the maximum number
of times the PIN may be entered wrongly before it MUST NOT be
possible to use the key anymore (typical reasonable values are
in the positive integer range of at least 2 and no more than
10).
'MinLength': This attribute indicates the minimum length of a PIN
that can be set to protect the associated key. It MUST NOT be
possible to set a PIN shorter than this value. If the
'PINFormat' attribute is set to 'DECIMAL', 'HEXADECIMAL', or
'ALPHANUMERIC', this value indicates the number of digits/
characters. If the 'PINFormat' attribute is set to 'BASE64' or
'BINARY', this value indicates the number of bytes of the
unencoded value.
'MaxLength': This attribute indicates the maximum length of a PIN
that can be set to protect this key. It MUST NOT be possible
to set a PIN longer than this value. If the 'PINFormat'
attribute is set to 'DECIMAL', 'HEXADECIMAL', or
'ALPHANUMERIC', this value indicates the number of digits/
Hoyer, et al. Standards Track [Page 22]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
characters. If the 'PINFormat' attribute is set to 'BASE64' or
'BINARY', this value indicates the number of bytes of the
unencoded value.
'PINEncoding': This attribute indicates the encoding of the PIN
and MUST be one of the values: DECIMAL, HEXADECIMAL,
ALPHANUMERIC, BASE64, or BINARY.
If the 'PinUsageMode' attribute is set to 'Local', then the device
MUST enforce the restriction indicated in the 'MaxFailedAttempts',
'MinLength', 'MaxLength', and 'PINEncoding' attributes; otherwise,
it MUST be enforced on the server side.
5.1. PIN Algorithm Definition
The PIN algorithm is defined as:
boolean = comparePIN(K,P)
Where:
'K' is the stored symmetric credential (PIN) in binary format.
'P' is the proposed PIN to be compared in binary format.
The function comparePIN is a straight octet comparison of K and P.
Such a comparison MUST yield a value of TRUE (credentials matched)
when the octet length of K is the same as the octet length of P and
all octets comprising K are the same as the octets comprising P.
6. Key Protection Methods
With the functionality described in the previous sections,
information related to keys had to be transmitted in cleartext. With
the help of the element, which is a child element of
the element, it is possible to encrypt keys and
associated information. The level of encryption is applied to the
value of individual elements and the applied encryption algorithm
MUST be the same for all encrypted elements. Keys are protected
using the following methods: pre-shared keys, passphrase-based keys,
and asymmetric keys. When encryption algorithms are used that make
use of Initialization Vectors (IVs), for example, AES-128-CBC, a
random IV value MUST be generated for each value to be encrypted and
it MUST be prepended to the resulting encrypted value as specified in
[XMLENC].
Hoyer, et al. Standards Track [Page 23]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
6.1. Encryption Based on Pre-Shared Keys
Figure 6 shows an example that illustrates the encryption of the
content of the element using AES-128-CBC and PKCS #5
Padding. The plaintext value of is
'3132333435363738393031323334353637383930'. The name of the pre-
shared secret is "Pre-shared-key", as set in the element
(which is a child element of the element). The value
of the encryption key used is '12345678901234567890123456789012'.
The IV for the MAC key is '11223344556677889900112233445566', and the
IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'.
As AES-128-CBC does not provide integrity checks, a keyed MAC is
applied to the encrypted value using a MAC key and a MAC algorithm as
declared in the element (in our example,
"http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the
algorithm and the value of the MAC key is randomly generated, in our
case '1122334455667788990011223344556677889900', and encrypted with
the above encryption key). The result of the keyed-MAC computation
is placed in the child element of .
Pre-shared-key
ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1sbeBMSvIhRejN9vJa2BOlSaMrR7I5wSX
Manufacturer987654321
Hoyer, et al. Standards Track [Page 24]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
CM_ID_001Issuer
AAECAwQFBgcICQoLDA0OD+cIHItlB3Wra1DUpxVvOx2lef1VmNPCMl8jwZqIUqGv
Su+NvtQfmvfJzF6bmQiJqoLRExc=
0
Figure 6: AES-128-CBC Encrypted Pre-Shared Secret Key with HMAC-SHA1
When protecting the payload with pre-shared keys, implementations
MUST set the name of the specific pre-shared key in the
element inside the element. When the encryption
method uses a CBC mode that requires an explicit initialization
vector (IV), the IV MUST be passed by prepending it to the encrypted
value.
For systems implementing PSKC, it is RECOMMENDED to support
AES-128-CBC (with the URI of
http://www.w3.org/2001/04/xmlenc#aes128-cbc) and KW-AES128 (with the
URI of http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that
KW-AES128 requires that the key to be protected must be a multiple of
8 bytes in length. Hence, if keys of a different length have to be
protected, then the usage of the key-wrap algorithm with padding, as
described in [RFC5649] is RECOMMENDED. Some of the encryption
algorithms that can optionally be implemented are:
Hoyer, et al. Standards Track [Page 25]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
Algorithm | Uniform Resource Locator (URL)
---------------+-------------------------------------------------------
AES192-CBC | http://www.w3.org/2001/04/xmlenc#aes192-cbc
AES256-CBC | http://www.w3.org/2001/04/xmlenc#aes256-cbc
TripleDES-CBC | http://www.w3.org/2001/04/xmlenc#tripledes-cbc
Camellia128 | http://www.w3.org/2001/04/xmldsig-more#camellia128
Camellia192 | http://www.w3.org/2001/04/xmldsig-more#camellia192
Camellia256 | http://www.w3.org/2001/04/xmldsig-more#camellia256
KW-AES128 | http://www.w3.org/2001/04/xmlenc#kw-aes128
KW-AES192 | http://www.w3.org/2001/04/xmlenc#kw-aes192
KW-AES256 | http://www.w3.org/2001/04/xmlenc#kw-aes256
KW-TripleDES | http://www.w3.org/2001/04/xmlenc#kw-tripledes
KW-Camellia128 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia128
KW-Camellia192 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia192
KW-Camellia256 | http://www.w3.org/2001/04/xmldsig-more#kw-camellia256
6.1.1. MAC Method
When algorithms without integrity checks are used, such as AES-128-
CBC, a keyed-MAC value MUST be placed in the element of
the element. In this case, the MAC algorithm type MUST be set
in the element of the element. The MAC
key MUST be a randomly generated key by the sender, be pre-agreed
upon between the receiver and the sender, or be set by the
application protocol that carries the PSKC document. It is
RECOMMENDED that the sender generate a random MAC key. When the
sender generates such a random MAC key, the MAC key material MUST be
encrypted with the same encryption key specified in
element of the key container. The encryption method and encrypted
value MUST be set in the element and the
element, respectively, of the element in the
element. The element of the
element MAY be used to indicate a pre-shared MAC key or a
provisioning protocol derived MAC key. For systems implementing
PSKC, it is RECOMMENDED to implement the HMAC-SHA1 (with the URI of
'http://www.w3.org/2000/09/xmldsig#hmac-sha1'). Some of the MAC
algorithms that can optionally be implemented are:
Algorithm | Uniform Resource Locator (URL)
---------------+-----------------------------------------------------
HMAC-SHA224 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha224
HMAC-SHA256 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
HMAC-SHA384 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
HMAC-SHA512 | http://www.w3.org/2001/04/xmldsig-more#hmac-sha512
Hoyer, et al. Standards Track [Page 26]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
6.2. Encryption Based on Passphrase-Based Keys
Figure 7 shows an example that illustrates the encryption of the
content of the element using passphrase-based key derivation
(PBKDF2) to derive the encryption key as defined in [PKCS5]. When
using passphrase-based key derivation, the element
defined in XML Encryption Version 1.1 [XMLENC11] MUST be used to
specify the passphrased-based key. A element is set as
the child element of element of the key container.
The element is used to specify the key derivation
function and related parameters. The encryption algorithm, in this
example, AES-128-CBC (URI
'http://www.w3.org/2001/04/xmlenc#aes128-cbc'), MUST be set in the
'Algorithm' attribute of element used inside the
encrypted data elements.
When PBKDF2 is used, the 'Algorithm' attribute of the element MUST be set to the URI
'http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2'. The
element MUST include the
child element to indicate the PBKDF2 parameters, such as salt and
iteration count.
When the encryption method uses a CBC mode that uses an explicit
initialization vector (IV) other than a derived one, the IV MUST be
passed by prepending it to the encrypted value.
In the example below, the following data is used.
Password: qwerty
Salt: 0x123eff3c4a72129c
Iteration Count: 1000
MAC Key: 0xbdaab8d648e850d25a3289364f7d7eaaf53ce581
OTP Secret: 12345678901234567890
The derived encryption key is "0x651e63cd57008476af1ff6422cd02e41".
The initialization vector (IV) is
"0xa13be8f92db69ec992d99fd1b5ca05f0". This key is also used to
encrypt the randomly chosen MAC key. A different IV can be used, say
"0xd864d39cbc0cdc8e1ee483b9164b9fa0", in the example. The encryption
with algorithm "AES-128-CBC" follows the specification defined in
[XMLENC].
Hoyer, et al. Standards Track [Page 27]
RFC 6030 Portable Symmetric Key Container (PSKC) October 2010
Ej7/PEpyEpw=100016My Password 1
2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx
TokenVendorAcme987654321CM_ID_001