draft-ietf-keyprov-portable-symmetric-key-container-02.txt   draft-ietf-keyprov-portable-symmetric-key-container-03.txt 
keyprov P. Hoyer keyprov P. Hoyer
Internet-Draft ActivIdentity Internet-Draft ActivIdentity
Intended status: Standards Track M. Pei Intended status: Standards Track M. Pei
Expires: May 9, 2008 VeriSign Expires: August 25, 2008 VeriSign
S. Machani S. Machani
Diversinet Diversinet
S. Chang February 22, 2008
Gemalto
November 6, 2007
Portable Symmetric Key Container Portable Symmetric Key Container
draft-ietf-keyprov-portable-symmetric-key-container-02.txt draft-ietf-keyprov-portable-symmetric-key-container-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 9, 2008. This Internet-Draft will expire on August 25, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies a symmetric key format for transport and This document specifies a symmetric key format for transport and
provisioning of symmetric keys (One Time Password (OTP) shared provisioning of symmetric keys (One Time Password (OTP) shared
secrets or symmetric cryptographic keys) to different types of strong secrets or symmetric cryptographic keys) to different types of strong
authentication devices. The standard token format enables authentication devices. The standard token format enables
enterprises to deploy best-of-breed solutions combining components enterprises to deploy best-of-breed solutions combining components
from different vendors into the same infrastructure. from different vendors into the same infrastructure.
skipping to change at page 2, line 27 skipping to change at page 2, line 27
common and shared specification will facilitate adoption of two- common and shared specification will facilitate adoption of two-
factor authentication on the Internet by enabling interoperability factor authentication on the Internet by enabling interoperability
between commercial and open-source implementations. between commercial and open-source implementations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6 3.1. Offline Use Cases . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Credential migration by end-user . . . . . . . . . . . 6 3.1.1. Key migration by end-user . . . . . . . . . . . . . . 6
3.1.2. Bulk import of new credentials . . . . . . . . . . . . 6 3.1.2. Bulk import of new keys . . . . . . . . . . . . . . . 6
3.1.3. Bulk migration of existing credentials . . . . . . . . 6 3.1.3. Bulk migration of existing keys . . . . . . . . . . . 7
3.1.4. Credential upload case . . . . . . . . . . . . . . . . 7 3.1.4. Key upload case . . . . . . . . . . . . . . . . . . . 7
3.2. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 7 3.2. Online Use Cases . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Online provisioning a credential to end-user's 3.2.1. Online provisioning a key to end-user's
authentication token . . . . . . . . . . . . . . . . . 7 authentication token . . . . . . . . . . . . . . . . . 7
3.2.2. Server to server provisioning of credentials . . . . . 8 3.2.2. Server to server provisioning of keys . . . . . . . . 8
3.2.3. Online update of an existing authentication token 3.2.3. Online update of an existing authentication token
credential . . . . . . . . . . . . . . . . . . . . . . 8 key . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Symmetric Key Attributes . . . . . . . . . . . . . . . . . . . 11 5. Portable Key container definition . . . . . . . . . . . . . . 11
5.1. Common Attributes . . . . . . . . . . . . . . . . . . . . 11 5.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 11 5.2. Device . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. KeyAlgorithm (MANDATORY) . . . . . . . . . . . . . . . 11 5.2.1. DeviceId . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.3. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 12 5.3. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.4. KeyId (MANDATORY) . . . . . . . . . . . . . . . . . . 13 5.3.1. Data (OPTIONAL) . . . . . . . . . . . . . . . . . . . 17
5.1.5. Issuer (MANDATORY) . . . . . . . . . . . . . . . . . . 13 5.3.2. Usage (MANDATORY) . . . . . . . . . . . . . . . . . . 17
5.1.6. FriendlyName (OPTIONAL) . . . . . . . . . . . . . . . 13 5.3.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . 21
5.1.7. AccessRules (OPTIONAL) . . . . . . . . . . . . . . . . 13 5.3.4. PINPolicy . . . . . . . . . . . . . . . . . . . . . . 22
5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute 6. Usage and profile of algorithms for the portable symmetric
is encrypted)) . . . . . . . . . . . . . . . . . . . . 13 key container . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.9. DigestMethod (MANDATORY when Digest is present) . . . 14 6.1. Usage of EncryptionKey to protect keys in transit . . . . 24
5.1.10. OTP and CR specific Attributes (OPTIONAL) . . . . . . 14 6.1.1. Protecting keys using a pre-shared key via
5.1.11. Logo (OPTIONAL) . . . . . . . . . . . . . . . . . . . 17 symmetric algorithms . . . . . . . . . . . . . . . . . 24
6. Key container XML schema definitions . . . . . . . . . . . . . 18 6.1.2. Protecting keys using passphrase based encryption
6.1. XML Schema Types . . . . . . . . . . . . . . . . . . . . . 18 keys . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. KeyType . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Protecting keys using asymmetric algorithms . . . . . . . 27
6.1.2. UsageType . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Profile of Key Algorithm . . . . . . . . . . . . . . . . . 28
6.1.3. DeviceType . . . . . . . . . . . . . . . . . . . . . . 22 6.3.1. OTP Key Algorithm Identifiers . . . . . . . . . . . . 28
6.1.4. DeviceIdType . . . . . . . . . . . . . . . . . . . . . 23 6.3.2. PIN key value compare algorithm identifier . . . . . . 28
6.1.5. UserType Type . . . . . . . . . . . . . . . . . . . . 24 7. Reserved data attribute names . . . . . . . . . . . . . . . . 30
6.1.6. KeyContainerType . . . . . . . . . . . . . . . . . . . 25 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1.7. EncryptionMethodType . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
6.1.8. DigestMethodType . . . . . . . . . . . . . . . . . . . 28 9.1. Payload confidentiality . . . . . . . . . . . . . . . . . 35
6.2. KeyAlgorithmType . . . . . . . . . . . . . . . . . . . . . 29 9.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 36
6.3. ValueFormat . . . . . . . . . . . . . . . . . . . . . . . 29 9.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 36
6.4. Data elements . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
6.4.1. KeyContainer . . . . . . . . . . . . . . . . . . . . . 29 11. Appendix A - Example Symmetric Key Containers . . . . . . . . 38
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Symmetric Key Container with a single Non-Encrypted
8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 38
8.1. Payload confidentiality . . . . . . . . . . . . . . . . . 39 11.2. Symmetric Key Container with a single PIN protected
8.2. Payload integrity . . . . . . . . . . . . . . . . . . . . 40 Non-Encrypted HOTP Secret Key . . . . . . . . . . . . . . 38
8.3. Payload authenticity . . . . . . . . . . . . . . . . . . . 40 11.3. Symmetric Key Container with a single AES-256-CBC
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 39
10. Appendix A - Example Symmetric Key Containers . . . . . . . . 42 11.4. Symmetric Key Container with signature and a single
10.1. Symmetric Key Container with a single Non-Encrypted Password-based Encrypted HOTP Secret Key . . . . . . . . . 40
HOTP Secret Key . . . . . . . . . . . . . . . . . . . . . 42 11.5. Symmetric Key Container with a single RSA 1.5
10.2. Symmetric Key Container with a single Password-based
Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 42 Encrypted HOTP Secret Key . . . . . . . . . . . . . . . . 42
11. Normative References . . . . . . . . . . . . . . . . . . . . . 44 12. Normative References . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . . . . 47
1. Introduction 1. Introduction
With increasing use of symmetric key based authentication systems With increasing use of symmetric key based authentication systems
such as systems based one time password (OTP) and challenge response such as systems based one time password (OTP) and challenge response
mechanisms, there is a need for vendor interoperability and a mechanisms, there is a need for vendor interoperability and a
standard format for importing, exporting or provisioning symmetric standard format for importing, exporting or provisioning symmetric
key based credentials from one system to another. Traditionally keys from one system to another. Traditionally authentication server
authentication server vendors and service providers have used vendors and service providers have used proprietary formats for
proprietary formats for importing, exporting and provisioning these importing, exporting and provisioning these keys into their systems
credentials into their systems making it hard to use tokens from making it hard to use tokens from vendor A with a server from vendor
vendor A with a server from vendor B. B.
This Internet draft describes a standard format for serializing This Internet draft describes a standard format for serializing
symmetric key based credentials such as OTP shared secrets for system symmetric keys such as OTP shared secrets for system import, export
import, export or network/protocol transport. The goal is that the or network/protocol transport. The goal is that the format will
format will facilitate dynamic provisioning and transfer of a facilitate dynamic provisioning and transfer of a symmetric keys such
symmetric key such as an OTP shared secret or an encryption key of as an OTP shared secret or an encryption key of different types. In
different types. In the case of OTP shared secrets, the format will the case of OTP shared secrets, the format will facilitate dynamic
facilitate dynamic provisioning using an OTP provisioning protocol to provisioning using an online provisioning protocol to different
different flavors of embedded tokens for OTP credentials or allow flavors of embedded tokens or allow customers to import new or
customers to import new or existing tokens in batch or single existing tokens in batch or single instances into a compliant system.
instances into a compliant system.
This draft also specifies the token attributes required for This draft also specifies the key attributes required for computation
interoperability such as the initial event counter used in the HOTP such as the initial event counter used in the HOTP algorithm [HOTP].
algorithm [HOTP]. It is also applicable for other time-based or It is also applicable for other time-based or proprietary algorithms.
proprietary algorithms.
To provide an analogy, in public key environments the PKCS#12 format To provide an analogy, in public key environments the PKCS#12 format
[PKCS12] is commonly used for importing and exporting private keys [PKCS12] is commonly used for importing and exporting private keys
and certificates between systems. In the environments outlined in and certificates between systems. In the environments outlined in
this document where OTP credentials may be transported directly down this document where OTP keys may be transported directly down to
to smartcards or devices with limited computing capabilities, a smartcards or devices with limited computing capabilities, a format
format with small (size in bytes) and explicit shared secret with small (size in bytes) and explicit shared secret configuration
configuration attribute information is desirable, avoiding complexity attribute information is desirable, avoiding complexity of PKCS#12.
of PKCS#12. For example, one would have to use opaque data within For example, one would have to use opaque data within PKCS#12 to
PKCS#12 to carry shared secret attributes used for OTP calculations, carry shared secret attributes used for OTP calculations, whereas a
whereas a more explicit attribute schema definition is better for more explicit attribute schema definition is better for
interoperability and efficiency. interoperability and efficiency.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. server respectively.
skipping to change at page 6, line 18 skipping to change at page 6, line 18
inspired the development of this specification. These requirements inspired the development of this specification. These requirements
were used to derive the primary requirement that drove the design. were used to derive the primary requirement that drove the design.
These requirements are covered in the next section. These requirements are covered in the next section.
These use cases also help in understanding the applicability of this These use cases also help in understanding the applicability of this
specification to real world situations. specification to real world situations.
3.1. Offline Use Cases 3.1. Offline Use Cases
This section describes the use cases relating to offline transport of This section describes the use cases relating to offline transport of
credentials from one system to another, using some form of export and keys from one system to another, using some form of export and import
import model. model.
3.1.1. Credential migration by end-user 3.1.1. Key migration by end-user
A user wants to migrate a credential from one authentication token A user wants to migrate a key from one authentication token
(container) to a different authentication token. For example, the (container) to a different authentication token. For example, the
authentication tokens may be soft tokens on two different systems authentication tokens may be soft tokens on two different systems
(computers or mobile phones). The user can export the credential in (computers or mobile phones). The user can export the key and
a standard format for import into the other authentication token. related data in a standard format for import into the other
authentication token.
The key protection mechanism may rely on password-based encryption The key protection mechanism may rely on password-based encryption
for soft tokens, a pre-placed hardware-protected transfer key shared for soft tokens, a pre-placed hardware-protected transfer key shared
between the two systems or may also rely on asymmetric keys/ PKI if between the two systems or may also rely on asymmetric keys/ PKI if
available. available.
3.1.2. Bulk import of new credentials 3.1.2. Bulk import of new keys
Tokens are manufactured in bulk and associated credentials (key Tokens are manufactured in bulk and associated keys and algorithm
records) need to be loaded into the validation system through a file data need to be loaded into the validation system through a file on
on portable media. The manufacturer provides the credentials in the portable media. The manufacturer provides the keys and related data
form of a file containing records in standard format, typically on a in the form of a file containing records in standard format,
CD. Note that the token manufacturer and the vendor for the typically on a CD. Note that the token manufacturer and the vendor
validation system may be the same or different. for the validation system may be the same or different.
In this case the file usually is protected by a symmetric transport In this case the file usually is protected by a symmetric transport
key which was communicated separately outside of the file between the key which was communicated separately outside of the file between the
two parties. two parties.
3.1.3. Bulk migration of existing credentials Some devices will allow local PIN management (the device will have a
PIN pad) hence random initial PINs set at manufacturing should be
transmitted together with the respective keys they protect.
An enterprise wants to port credentials from an existing validation 3.1.3. Bulk migration of existing keys
system A into a different validation system B. The existing
validation system provides the enterprise with a functionality that
enables export of credentials (OTP tokens) in a standard format.
Since the OTP tokens are in the standard format, the enterprise can An enterprise wants to port keys and related data from an existing
import the token records into the new validation system B and start validation system A into a different validation system B. The
using the existing tokens. Note that the vendors for the two existing validation system provides the enterprise with a
validation systems may be the same or different. functionality that enables export of keys and related data (e.g. for
OTP tokens) in a standard format. Since the OTP tokens are in the
standard format, the enterprise can import the token records into the
new validation system B and start using the existing tokens. Note
that the vendors for the two validation systems may be the same or
different.
In this case the file usually is protected by a symmetric transport In this case the file usually is protected by a symmetric transport
key which was communicated separately outside of the file between the key which was communicated separately outside of the file between the
two validation systems. two validation systems.
3.1.4. Credential upload case In this case it is also important to be able to communicate the
existing assignment (binding) of a device to a specific user.
User wants to activate and use a new credential against a validation 3.1.4. Key upload case
system that is not aware of this credential. This credential may be
User wants to activate and use a new key and related data against a
validation system that is not aware of this key. This key may be
embedded in the authentication token (e.g. SD card, USB drive) that embedded in the authentication token (e.g. SD card, USB drive) that
the user has purchased at the local electronics retailer. Along with the user has purchased at the local electronics retailer. Along with
the authentication token, the user may get the credential on a CD or the authentication token, the user may get the key on a CD or a
a floppy in a standard format. The user can now upload via a secure floppy in a standard format. The user can now upload via a secure
online channel or import this credential into the new validation online channel or import this key and related data into the new
system and start using the credential. validation system and start using the key.
The key protection mechanism may rely on password-based encryption, The key protection mechanism may rely on password-based encryption,
or a pre-placed hardware-protected transfer key shared between the or a pre-placed hardware-protected transfer key shared between the
token manufacturer and the validation system(s) if available. token manufacturer and the validation system(s) if available.
3.2. Online Use Cases 3.2. Online Use Cases
This section describes the use cases related to provisioning the This section describes the use cases related to provisioning the keys
credentials using some form of a online provisioning protocol. using some form of a online provisioning protocol.
3.2.1. Online provisioning a credential to end-user's authentication 3.2.1. Online provisioning a key to end-user's authentication token
token
A mobile device user wants to obtain an OTP credential (shared A mobile device user wants to obtain an OTP key for use with an OTP
secret) for use with an OTP soft token on the device. The soft token soft token on the device. The soft token client from vendor A
client from vendor A initiates the provisioning process against a initiates the provisioning process against a provisioning system from
provisioning system from vendor B using a standards-based vendor B using a standards-based provisioning protocol such as
provisioning protocol such as [DSKPP]. The provisioning system [DSKPP]. The provisioning system delivers one or more keys in a
delivers one or more OTP credential(s) in a standard format that can standard format that can be processed by the mobile device. The user
be processed by the mobile device. The user can download a payload can download a payload that contains more than one key.
that contains more than one credential.
In a variation of the above, instead of the user's mobile phone, a In a variation of the above, instead of the user's mobile phone, a
credential is provisioned in the user's soft token application on a key is provisioned in the user's soft token application on a laptop
laptop using a network-based online protocol. As before, the using a network-based online protocol. As before, the provisioning
provisioning system delivers an OTP credential in a standard format system delivers an OTP key in a standard format that can be processed
that can be processed by the soft token on the PC. by the soft token on the PC.
3.2.2. Server to server provisioning of credentials 3.2.2. Server to server provisioning of keys
Sometimes, instead of importing token information from manufacturer Sometimes, instead of importing keys from a manufacturer using a
using a file, an OTP validation server may download the credential file, an OTP validation server may download the keys using an online
seed records using an online protocol. The credentials can be protocol. The keys can be downloaded in a standard format that can
downloaded in a standard format that can be processed by a validation be processed by a validation system.
system.
In another scenario, an OTA (over-the-air) credential provisioning In another scenario, an OTA (over-the-air) key provisioning gateway
gateway that provisions credentials to mobile phones may obtain that provisions keys to mobile phones may obtain key material from a
credentials from the credential issuer using an online protocol. The key issuer using an online protocol. The keys are delivered in a
credentials are delivered in a standard format that can be processed standard format that can be processed by the OTA key provisioning
by the OTA credential provisioning gateway and subsequently sent to gateway and subsequently sent to the end-user's mobile phone.
the end-user's mobile phone.
3.2.3. Online update of an existing authentication token credential 3.2.3. Online update of an existing authentication token key
The end-user or the credential issuer wants to update or configure an The end-user or the key issuer wants to update or configure an
existing credential in the authentication token and requests a existing key in the authentication token and requests a replacement
replacement credential container. The container may or may not key container. The container may or may not include a new key and
include a new secret key and may include new or updated secret key may include new or updated key attributes such as a new counter value
attributes such as a new counter value in HOTP credential case, a new in HOTP key case, a modified response format or length, a new
logo, a modified response format or length, a new friendly name, etc. friendly name, etc.
4. Requirements 4. Requirements
This section outlines the most relevant requirements that are the This section outlines the most relevant requirements that are the
basis of this work. Several of the requirements were derived from basis of this work. Several of the requirements were derived from
use cases described above. use cases described above.
R1: The format MUST support transport of multiple types of R1: The format MUST support transport of multiple types of
symmetric key credentials including HOTP, other OTP, challenge- symmetric keys and related attributes for algorithms including
response, etc. HOTP, other OTP, challenge-response, etc.
R2: The format MUST handle the symmetric key itself as well of R2: The format MUST handle the symmetric key itself as well of
attributes that are typically associated with symmetric keys. attributes that are typically associated with symmetric keys.
Some of these attributes may be Some of these attributes may be
* Unique Key Identifier * Unique Key Identifier
* Issuer information * Issuer information
* Algorithm ID * Algorithm ID
* Algorithm mode * Algorithm mode
* Issuer Name * Issuer Name
* Issuer logo * Key friendly name
* Credential friendly name
* Event counter value (moving factor for OTP algorithms) * Event counter value (moving factor for OTP algorithms)
* Time value * Time value
R3: The format SHOULD support both offline and online scenarios. R3: The format SHOULD support both offline and online scenarios.
That is it should be serializable to a file as well as it That is it should be serializable to a file as well as it
should be possible to use this format in online provisioning should be possible to use this format in online provisioning
protocols protocols
R4: The format SHOULD allow bulk representation of symmetric key R4: The format SHOULD allow bulk representation of symmetric keys
credentials.
R5: The format SHOULD be portable to various platforms. R5: The format SHOULD allow bulk representation of PINs related to
specific keys
R6: The format SHOULD be portable to various platforms.
Furthermore, it SHOULD be computationally efficient to process. Furthermore, it SHOULD be computationally efficient to process.
R6: The format MUST provide appropriate level of security in terms R7: The format MUST provide appropriate level of security in terms
of data encryption and data integrity. of data encryption and data integrity.
R7: For online scenarios the format SHOULD NOT rely on transport R8: For online scenarios the format SHOULD NOT rely on transport
level security (e.g., SSL/TLS) for core security requirements. level security (e.g., SSL/TLS) for core security requirements.
R8: The format SHOULD be extensible. It SHOULD enable extension R9: The format SHOULD be extensible. It SHOULD enable extension
points allowing vendors to specify additional attributes in the points allowing vendors to specify additional attributes in the
future. future.
R9: The format SHOULD allow for distribution of key derivation data R10: The format SHOULD allow for distribution of key derivation data
without the actual symmetric key itself. This is to support without the actual symmetric key itself. This is to support
symmetric key management schemes that rely on key derivation symmetric key management schemes that rely on key derivation
algorithms based on a pre-placed master key. The key algorithms based on a pre-placed master key. The key
derivation data typically consists of a reference to the key, derivation data typically consists of a reference to the key,
rather than the key value itself. rather than the key value itself.
R10: The format SHOULD allow for additional lifecycle management R11: The format SHOULD allow for additional lifecycle management
operations such as counter resynchronization. Such processes operations such as counter resynchronization. Such processes
require confidentiality between client and server, thus could require confidentiality between client and server, thus could
use a common secure container format, without the transfer of use a common secure container format, without the transfer of
key material. key material.
R11: The format MUST support the use of pre-shared symmetric keys to R12: The format MUST support the use of pre-shared symmetric keys to
ensure confidentiality of sensitive data elements. ensure confidentiality of sensitive data elements.
R12: The format MUST support a password-based encryption (PBE) R13: The format MUST support a password-based encryption (PBE)
[PKCS5] scheme to ensure security of sensitive data elements. [PKCS5] scheme to ensure security of sensitive data elements.
This is a widely used method for various provisioning This is a widely used method for various provisioning
scenarios. scenarios.
R13: The format SHOULD support asymmetric encryption algorithms such R14: The format SHOULD support asymmetric encryption algorithms such
as RSA to ensure end-to-end security of sensitive data as RSA to ensure end-to-end security of sensitive data
elements. This is to support scenarios where a pre-set shared elements. This is to support scenarios where a pre-set shared
encryption key is difficult to use. encryption key is difficult to use.
5. Symmetric Key Attributes 5. Portable Key container definition
The symmetric key includes a number of data attributes that define The portable key container is based on an XML schema definition and
the type of the key its usage and associated meta-information contains the following main entities:
required during the provisioning, configuration, access or usage in
the host device.
5.1. Common Attributes 1. KeyContainer entity as defined in Section 5.1
5.1.1. Data (OPTIONAL) 2. Device entity as defined in Section 5.2
Defines the data attributes of the symmetric key. Each is a name 3. Key entity as defined in Section 5.3
value pair which has both a base64 encoded value and a base 64
encoded ValueDigest. The value can be encrypted. If the container
has been encrypted the ValueDigest MUST be populated with the digest
of the unencrypted value.
This is also where the key value is held, therefore the following Additionally other XML schema types have been defined and are
list of attribute names have been reserved: detailed in the relevant subsections of this document
SECRET: the shared secret key value in binary, base64 encoded A KeyContainer MAY contain one or more Device entities. A Device MAY
contain one or more Key entities
COUNTER: the event counter for event based OTP algorithms. 8 bytes The figure below indicates a possible relationship diagram of a
unsigned integer in big endian (i.e. network byte order) form container.
base64 encoded
TIME: the time for time based OTP algorithms. 8 bytes unsigned --------------------------------------------
integer in big endian (i.e. network byte order) form base64 | KeyContainer |
encoded (Number of seconds since 1970) | |
| ------------------ ----------------- |
| | Device 1 | | Device n | |
| | | | | |
| | ------------ | | ------------ | |
| | | Key 1 | | | | Key n | | |
| | ------------ | | ------------ | |
| | | | | |
| | | | | |
| | ------------ | | ------------ | |
| | | Key m | | | | Key p | | |
| | ------------ | | ------------ | |
| ------------------ ----------------- |
| |
--------------------------------------------
TIME_INTERVAL: the time interval value for time based OTP The following section describe in detail all the entities and related
algorithms. 8 bytes unsigned integer in big endian (i.e. network XML schema elements and attributes:
byte order) form base64 encoded.
TIME_DRIFT: the device clock drift value for time based OTP 5.1. KeyContainer
algorithms. The value indicates number of seconds that the device
clock may drift each day. 2 bytes unsigned integer in big endian
(i.e. network byte order) form base64 encoded.
5.1.2. KeyAlgorithm (MANDATORY) The KeyContainer represents the key container entity. A Container
MAY contain more than one Device entity; each Device entity MAY
contain more than one Key entity.
Defines the type of algorithm of the secret key. The following The KeyContainer is defined as follows:
algorithm URIs are among the default support list.
o http://www.w3.org/2001/04/xmlenc#tripledes-cbc <xs:complexType name="KeyContainerType">
<xs:sequence>
<xs:element name="EncryptionKey"
type="ds:KeyInfoType" minOccurs="0"/>
<xs:element name="MACAlgorithm"
type="pskc:KeyAlgorithmType" minOccurs="0"/>
<xs:element name="Device"
type="pskc:DeviceType" maxOccurs="unbounded"/>
<xs:element name="Signature"
type="ds:SignatureType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Version" type="pskc:VersionType" use="required"/>
</xs:complexType>
o http://www.w3.org/2001/04/xmlenc#aes128-cbc The elements of the KeyContainer have the following meanings:
o http://www.w3.org/2001/04/xmlenc#aes192-cbc
o http://www.w3.org/2001/04/xmlenc#aes256-cbc o <EncryptionKey (OPTIONAL)>, Identifies the encryption key,
algorithm and possible parameters used to protect the Secret Key
data in the container, for profile and usage please see
Section 6.1
o http://www.ietf.org/keyprov/pskc#hotp o <MACAlgorithm (OPTIONAL)>, Identifies the algorithm used to
generate a keyed digest of the the Secret Key data values when
protection algorithms are used that do not have integrity checks.
The digest guarantees the integrity and the authenticity of the
key data. for profile and usage please see Section 6.1.1
5.1.2.1. OTP Key Algorithm Identifiers o <Device>, the host Device for one or more Keys as defined in
Section 5.2 The KeyContainer MAY contain multiple Device data
elements, allowing for bulk provisioning of keys.
OTP key algorithm URIs have not been defined in a commonly available o <Signature (OPTIONAL)>, the signature value of the Container.
standard specification. This document defines the following URIs for When the signature is applied to the entire container, it MUST use
the known open standard OTP algorithms. XML Signature methods as defined in [XMLSIG]. It MAY be omitted
when application layer provisioning or transport layer
provisioning protocols provide the integrity and authenticity of
the payload between the sender and the recipient of the container.
When required, this specification recommends using a symmetric key
based signature with the same key used in the encryption of the
secret key data. The signature is enveloped.
5.1.2.1.1. HOTP o <Version (MANDATORY)>, the version number for the portable key
container format (the XML schema defined in this document).
Standard document: RFC4226 5.2. Device
Identifier: http://www.ietf.org/keyprov/pskc#hotp The Device represents the Device entity in the Container. A Device
MAY be bound to a user and MAY contain more than one keys. It is
recommended that a key is bound to one and only one Device.
Note that the actual URL will be finalized once a URL for this The Device is defined as follows:
document is determined.
5.1.2.1.2. Other OTP Algorithms <xs:complexType name="DeviceType">
<xs:sequence>
<xs:element name="DeviceId" type="pskc:DeviceIdType" minOccurs="0"/>
<xs:element name="Key" type="pskc:KeyType" maxOccurs="unbounded"/>
<xs:element name="UserId" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
An implementation should refer to vendor supplied OTP key algorithm The elements of the Device have the following meanings:
URIs for proprietary algorithms.
5.1.3. Usage (MANDATORY) o <DeviceId>, a unique identifier for the device, defined in
Section 5.2.1
Defines the intended usage of the key and is a combination of one or o <Key>, represents the key entity as defined in Section 5.3
more of the following (set to true):
OTP: the key will be used for OTP generation o <UserId>, optionally identifies the owner or the user of the
Device TODO
CR: the key will be used for Challenge/Response purposes 5.2.1. DeviceId
Encrypt: the key will be used for data encryption purposes The DeviceId represents the identifying criteria to uniquely identify
the device that contains the associated keys. Since devices can come
in different form factors such as hardware tokens, smartcards, soft
tokens in a mobile phone or PC etc this type allows different
criteria to be used. Combined though the criteria MUST uniquely
identify the device. For example for hardware tokens the combination
of SerialNo and Manufacturer will uniquely identify a device but not
SerialNo alone since two different token manufacturers might issue
devices with the same serial number (similar to the IssuerDN and
serial number of a certificate). For keys hold on banking cards the
identification of the device is often done via the Primary Account
Number (PAN, the big number printed on the front of the card) and an
expiry date of the card. DeviceId is an extensible type that allows
all these different ways to uniquely identify a specific key
containing device.
Sign: the key will be used to generate a signature or keyed The DeviceId is defined as follows:
hashing for data integrity or authentication purposes.
Unlock: the key will be used for an inverse challenge response in <xs:complexType name="DeviceIdType">
the case a user has locked the device by entering a wrong PIN too <xs:sequence>
many times (for devices with PIN-input capability) <xs:element name="Manufacturer" type="xs:string"/>
<xs:element name="SerialNo" type="xs:string"/>
<xs:element name="Model" type="xs:string" minOccurs="0"/>
<xs:element name="IssueNo" type="xs:string" minOccurs="0"/>
<xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
Additional attributes that are specific to the usage type MAY be The elements of DeviceId have the following meanings:
required. Section 6.1 describes OTP and CR specific attributes.
5.1.4. KeyId (MANDATORY) o <Manufacturer>, the manufacturer of the device.
A unique and global identifier of the symmetric key. The identifier o <SerialNo>, the serial number of the device or the PAN (primary
is defined as a string of alphanumeric characters. account number) in case of EMV (Europay-MasterCard-Visa) smart
cards.
5.1.5. Issuer (MANDATORY) o <Model>, the model of the device (e.g one-button-HOTP-token-V1)
The key issuer name, this is normally the name of the organization o <IssueNo>, the issue number in case of smart cards with the same
that issues the key to the end user of the key. For example MyBank PAN, equivalent to a PSN (PAN Sequence Number).
issuing hardware tokens to their retail banking users 'MyBank' would
be the issuer. The Issuer is defined as a String.
5.1.6. FriendlyName (OPTIONAL) o <ExpiryDate>, the expiry date of a device (such as the one on an
EMV card,used when issue numbers are not printed on cards).
The user friendly name that is assigned to the secret key for easy o <StartDate>, the start date of a device (such as the one on an EMV
reference. The FriendlyName is defined as a String. card,used when issue numbers are not printed on cards).
5.1.7. AccessRules (OPTIONAL) 5.3. Key
Defines a set of access rules and policies for the protection of the The Key represents the key entity in the KeyContainer. The Key is
key on the host Device. Currently only the UserPIN policy is defined as follows:
defined. The UserPIN policy specifies whether the user MUST enter a
PIN (for devices with PIN input capability) in order to unlock or
authenticate to the device hosting the key container. The UserPIN is
defined as a Boolean (TRUE or FALSE). When the user PIN is required,
the policy MUST be set to TRUE. If the UserPIN is NOT provided,
implementations SHALL default the value to FALSE.
5.1.8. EncryptionMethod (MANDATORY when 'Data' attribute is encrypted)) <xs:complexType name="KeyType">
<xs:sequence>
<xs:element name="Issuer" type="xs:string" minOccurs="0"/>
<xs:element name="Usage" type="pskc:UsageType"/>
<xs:element name="CardAppPersoProfileId" type="xs:string"
minOccurs="0"/>
<xs:element name="FriendlyName" type="xs:string" minOccurs="0"/>
<xs:element name="Data" type="pskc:DataType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="PINPolicy" type="pskc:PINPolicyType"
minOccurs="0"/>
<xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="KeyId" type="xs:string" use="required"/>
<xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType"
use="required"/>
</xs:complexType>
Identifies the encryption algorithm and possible parameters used to The attributes of the Key entity have the following meanings:
protect the Secret Key data in the container. The encryption
algorithm URI can be one of the following.
o http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 o KeyId (MANDATORY), a unique and global identifier of the symmetric
key. The identifier is defined as a string of alphanumeric
characters.
o http://www.w3.org/2001/04/xmlenc#tripledes-cbc o <KeyAlgorithm (MANDATORY)>, the unique URI of the type of
algorithm to use with the secret key, for profiles are described
in Section 6.3
o http://www.w3.org/2001/04/xmlenc#aes128-cbc The elements of the Key entity have the following meanings:
o http://www.w3.org/2001/04/xmlenc#aes192-cbc o <Issuer (OPTIONAL)>, The key issuer name, this is normally the
name of the organization that issues the key to the end user of
the key. For example MyBank issuing hardware tokens to their
retail banking users 'MyBank' would be the issuer. The Issuer is
defined as a String.
o http://www.w3.org/2001/04/xmlenc#aes256-cbc o <Usage (MANDATORY)>, defines the intended usage of the key and
related metadata as defined in Section 5.3.2
o http://www.w3.org/2001/04/xmlenc#rsa-1_5 o <CardAppPersoProfileId (OPTIONAL)>, A uniquie identifier used
between the sending and receiving party of the container to
establish a set of constant values related to a key that are not
transmitted via the container. For example a smart card
application personalisation profile id related to attributes
present on a smart card application that have influence when
computing a response. An example could be an EMV MasterCard CAP
[CAP] application on a card personalised with data for a specific
batch of cards such as:
o http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p IAF Internet authentication flag
o http://www.w3.org/2001/04/xmlenc#kw-tripledes
o http://www.w3.org/2001/04/xmlenc#kw-aes128 CVN Cryptogram version number, for example (MCHIP2, MCHIP4,
VISA 13, VISA14)
o http://www.w3.org/2001/04/xmlenc#kw-aes256 AIP (Application Interchange Profile), 2 bytes
o http://www.w3.org/2001/04/xmlenc#kw-aes512 TVR Terminal Verification Result, 5 bytes
When an PBE algorithm is used for encryption, the URI CVR The card verification result
http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2 and the
encryption algorithm in PBEEncryptionParamType defines the exact PBE
key derivation and encryption algorithms.
When the value is not provided, implementations SHALL ensure the AmountOther
privacy of the key data through other standard mechanisms e.g.
transport level encryption.
When the container (payload) contains more than one key and TransactionDate
EncryptionMethod is specified, the same encryption key MUST be used
to encrypt all the key data elements in the container.
5.1.9. DigestMethod (MANDATORY when Digest is present) TerminalCountryCode
Identifies the algorithm and possible parameters used to generate a TransactionCurrencyCode
digest of the the Secret Key data. The digest guarantees the
integrity and the authenticity of the key data.
See Section 6.1.8 for more information on Digest data value type. AmountAuthorised
5.1.10. OTP and CR specific Attributes (OPTIONAL) IIPB
These values are not contained within attributes in the container
but are shared between the manufacturing and the validation
service through this unique CardAppPersoProfileId. The
CardAppPersoProfileId is defined as a String.
o <FriendlyName (OPTIONAL)>, The user friendly name that is assigned
to the secret key for easy reference. The FriendlyName is defined
as a String.
o <Data (OPTIONAL)>, the element carrying the data related to the
key as defined in Section 5.3.1
o <PINPolicy (OPTIONAL)>, the policy of the PIN relating to the
usage of this key as defined in Section 5.3.4
o <ExpiryDate (OPTIONAL)>, the expiry date of the key, it MUST not
be possible to use this key after this date
o <StartDate (OPTIONAL)>, the start date of the key, it MUST not be
possible to use this key before this date
5.3.1. Data (OPTIONAL)
Defines the data attributes of the symmetric key. Each is a name
value pair which has either a plain value (in case of no encryption)
or an encrypted value as defined in EncryptedDataType in XML
Encryption.
This is also where the key value is transported, Section 7 defines a
list of reserved attribute names.
Data element is defined as follows:
<xs:complexType name="DataType">
<xs:sequence>
<xs:choice>
<xs:element name="PlainValue" type="xs:base64Binary"/>
<xs:element name="EncryptedValue" type="xenc:EncryptedDataType"/>
</xs:choice>
<xs:element name="ValueMAC" type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Name" type="xs:string" use="required"/>
</xs:complexType>
The attributes of the Data element have the following meanings:
o Name, defines the name of the name-value pair, Section 7 defines a
list of reserved attribute names
The elements of the Data element have the following meanings:
o The <PlainValue> conveys an unencrypted value of the name-value
pair in base 64 encoding.
o The <EncryptedValue> element in the DataType conveys an encrypted
value of the name-value pair inside an EncryptedDataType as
defined in XML Encryption.
o The <ValueMAC (OPTIONAL)> element in the DataType conveys a keyed
MAC value of the unencrypted data for the cases where the key
protection algorithm does not support integrity checks
5.3.2. Usage (MANDATORY)
The Usage element defines the usage attribute(s) of the key entity.
Usage is defined as follows:
<xs:complexType name="UsageType">
<xs:sequence>
<xs:element name="ResponseFormat">
<xs:complexType>
<xs:attribute name="Format"
type="pskc:ValueFormatType" use="required"/>
<xs:attribute name="Length"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="CheckDigits"
type="xs:boolean" default="false"/>
</xs:complexType>
</xs:element>
<xs:element name="ChallengeFormat" minOccurs="0">
<xs:complexType>
<xs:attribute name="Format"
type="pskc:ValueFormatType" use="required"/>
<xs:attribute name="Min"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="Max"
type="xs:unsignedInt" use="required"/>
<xs:attribute name="CheckDigits"
type="xs:boolean" default="false"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="OTP" type="xs:boolean" default="false"/>
<xs:attribute name="CR" type="xs:boolean" default="false"/>
<xs:attribute name="Integrity" type="xs:boolean" default="false"/>
<xs:attribute name="Encrypt" type="xs:boolean" default="false"/>
<xs:attribute name="Unlock" type="xs:boolean" default="false"/>
</xs:complexType>
The attributes of the Usage element define the intended usage of the
key and are a combination of one or more of the following (set to
true):
o OTP, the key will be used for OTP generation
o CR, the key will be used for Challenge/Response purposes
o Encrypt, the key will be used for data encryption purposes
o Integrity, the key will be used to generate a keyed message digest
for data integrity or authentication purposes.
o Unlock, the key will be used for an inverse challenge response in
the case a user has locked the device by entering a wrong PIN too
many times (for devices with PIN-input capability)
5.3.2.1. OTP and CR specific Usage elements (OPTIONAL)
When the key usage is set to OTP or CR, additional attributes MUST be When the key usage is set to OTP or CR, additional attributes MUST be
provided to support the OTP and/or the response computation as provided to support the OTP and/or the response computation as
required by the underlying algorithm and to customize or configure required by the underlying algorithm and to customize or configure
the outcome of the computation (format, length and usage modes). the outcome of the computation (format, length and usage modes).
5.1.10.1. ChallengeFormat (MANDATORY) 5.3.2.1.1. ChallengeFormat element (MANDATORY)
The ChallengeFormat attribute defines the characteristics of the The ChallengeFormat element defines the characteristics of the
challenge in a CR usage scenario. The Challenge attribute is defined challenge in a CR usage scenario. The Challenge element is defined
by the following sub-attributes: by the following attributes:
1. Format (MANDATORY) o Format (MANDATORY)
Defines the format of the challenge accepted by the device and Defines the format of the challenge accepted by the device and
MUST be one of the values defined in Section 6.3 MUST be one of the values defined in Section 5.3.3
2. CheckDigit (OPTIONAL)
o CheckDigit (OPTIONAL)
Defines if the device needs to check the appended Luhn check Defines if the device needs to check the appended Luhn check
digit contained in a provided challenge. This is only valid digit contained in a provided challenge. This is only valid if
if the Format attribute is 'DECIMAL'. Value MUST be: the Format attribute is 'DECIMAL'. Value MUST be:
TRUE device will check the appended Luhn check digit in a TRUE device will check the appended Luhn check digit in a
provided challenge provided challenge
FALSE device will not check appended Luhn check digit in FALSE device will not check appended Luhn check digit in
challenge challenge
3. Min (MANDATORY) o Min (MANDATORY)
Defines the minimum size of the challenge accepted by the Defines the minimum size of the challenge accepted by the
device for CR mode. device for CR mode.
If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the minimum number of 'ALPHANUMERIC' this value indicates the minimum number of
digits/characters. digits/characters.
If the Format attribute is 'BASE64' or 'BINARY', this value If the Format attribute is 'BASE64' or 'BINARY', this value
indicates the minimum number of bytes of the unencoded value. indicates the minimum number of bytes of the unencoded value.
Value MUST be: Value MUST be:
Unsigned integer. Unsigned integer.
4. Max (MANDATORY) o Max (MANDATORY)
Defines the maximum size of the challenge accepted by the Defines the maximum size of the challenge accepted by the
device for CR mode. device for CR mode.
If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the maximum number of 'ALPHANUMERIC' this value indicates the maximum number of
digits/characters. digits/characters.
If the Format attribute is 'BASE64' or 'BINARY', this value If the Format attribute is 'BASE64' or 'BINARY', this value
indicates the maximum number of bytes of the unencoded value. indicates the maximum number of bytes of the unencoded value.
Value MUST be: Value MUST be:
Unsigned integer. Unsigned integer.
5.1.10.2. ResponseFormat (MANDATORY) 5.3.2.1.2. ResponseFormat element (MANDATORY)
The ResponseFormat attribute defines the characteristics of the The ResponseFormat element defines the characteristics of the result
result of a computation. This defines the format of the OTP or of of a computation. This defines the format of the OTP or of the
the response to a challenge. The Response attribute is defined by response to a challenge. The Response attribute is defined by the
the following sub-attributes: following attributes:
1. Format (MANDATORY) o Format (MANDATORY)
Defines the format of the response generated by the device and Defines the format of the response generated by the device and
MUST be one of the values defined in Section 6.3 MUST be one of the values defined in Section 5.3.3
2. CheckDigit (OPTIONAL) o CheckDigit (OPTIONAL)
Defines if the device needs to append a Luhn check digit to Defines if the device needs to append a Luhn check digit to the
the response. This is only valid if the Format attribute is response. This is only valid if the Format attribute is
'DECIMAL'. Value MUST be: 'DECIMAL'. Value MUST be:
TRUE device will append a Luhn check digit to the response. TRUE device will append a Luhn check digit to the response.
FALSE device will not append a Luhn check digit to the FALSE device will not append a Luhn check digit to the
response. response.
3. Length (MANDATORY) o Length (MANDATORY)
Defines the length of the response generated by the device. Defines the length of the response generated by the device.
If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or If the Format attribute is 'DECIMAL', 'HEXADECIMAL' or
'ALPHANUMERIC' this value indicates the number of digits/ 'ALPHANUMERIC' this value indicates the number of digits/
characters. characters.
If the Format attribute is 'BASE64' or 'BINARY', this value If the Format attribute is 'BASE64' or 'BINARY', this value
indicates the number of bytes of the unencoded value. indicates the number of bytes of the unencoded value.
Value MUST be: Value MUST be:
Unsigned integer. Unsigned integer.
5.1.10.3. AppProfileId (OPTIONAL) 5.3.3. ValueFormat
Defines the application profile id related to attributes present on a
smart card that have influence when computing a response. An example
could be an EMV MasterCard CAP [CAP] application on a card that
contains attributes or uses fixed data for a specific batch of cards
such as:
IAF Internet authentication flag
CVN Cryptogram version number, for example (MCHIP2, MCHIP4, VISA
13, VISA14)
AIP (Application Interchange Profile), 2 bytes
TVR Terminal Verification Result, 5 bytes
CVR The card verification result
AmountOther
TransactionDate
TerminalCountryCode The ValueFormat element defines allowed formats for challenges or
responses in OTP algorithms.
TransactionCurrencyCode ValueFormat is defined as follows:
AmountAuthorised <simpleType name="ValueFormat">
<restriction base="string">
<enumeration value="DECIMAL"/>
<enumeration value="HEXADECIMAL"/>
<enumeration value="ALPHANUMERIC"/>
<enumeration value="BASE64"/>
<enumeration value="BINARY"/>
</restriction>
</simpleType>
IIPB DECIMAL Only numerical digits
These values are not contained within attributes in the container but HEXADECIMAL Hexadecimal response
are shared between the manufacturing and the validation service
through this unique AppProfileId.
5.1.11. Logo (OPTIONAL) ALPHANUMERIC All letters and numbers (case sensitive)
Specifies the logo image information associated with a key. The logo BASE64 Base 64 encoded
type is defined in a separate schema file with namespace
urn:ietf:params:xml:ns:keyprov:logo:1.0.
6. Key container XML schema definitions BINARY Binary data, this is mainly used in case of connected
devices
The portable key container is defined by the following entities: 5.3.4. PINPolicy
1. KeyContainer entity The PINPolicy element defines a mean to define how the usage of a
specific key is protected by a PIN. The PIN itself can be
transmitted using the container as another Key
2. Device entity PINPolicy is defined as follows:
3. Key entity <xs:complexType name="PINPolicyType">
<xs:sequence>
<xs:element name="PINUsageMode" type="pskc:PINUsageModeType"/>
<xs:element name="WrongPINtry" type="xs:unsignedInt"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="PINKeyId" type="xs:string" use="required"/>
</xs:complexType>
4. User entity The attributes of PINPolicy have the following meaning
A KeyContainer MAY contain one or more Device entities. A Device MAY o PINKeyId, the unique key Id within this container that contains
contain one or more Key entities and may be associated to one or more the value of the PIN that protects the key
User entities.
The figure below indicates a possible relationship diagram of a The elements of PINPolicy have the following meaning
container.
-------------------------------------------- o <PINUsageMode>, the way the PIN is used during the usage of the
| KeyContainer | key as defined in Section 5.3.4.1
| |
| ------------------ ----------------- |
| | Device 1 | | Device n | |
| | | | | |
| | ------------ | | ------------ | |
| | | Key 1 | | | | Key n | | |
| | ------------ | | ------------ | |
| | | | | |
| | | | | |
| | ------------ | | ------------ | |
| | | Key m | | | | Key p | | |
| | ------------ | | ------------ | |
| ------------------ ----------------- |
| | | | |
| | | | |
| ---------- ---------- ---------- |
| | User 1 | | User 1 | | User n | |
| ---------- ---------- ---------- |
| |
--------------------------------------------
6.1. XML Schema Types o <WrongPINtry>, the number of times the PIN can be entered wrongly
before it MUST not be possible to use the key anymore
The following types are defined to represent the portable key 5.3.4.1. PINUsageMode
container entities and associated attributes.
6.1.1. KeyType The PINUsageMode element defines how the PIN is used with a specific
key
The KeyType represents the key entity in the KeyContainer. The PINUsageMode is defined as follows:
KeyType is defined as follows:
<complexType name="KeyType"> <xs:complexType name="PINUsageModeType">
<sequence> <xs:choice maxOccurs="unbounded">
<element name="Issuer" type="string"/> <xs:element name="Local"/>
<element name="Usage" type="pskc:UsageType"/> <xs:element name="Prepend"/>
<element name="FriendlyName" type="string" minOccurs="0"/> <xs:element name="InAlgo"/>
<element name="Data" type="pskc:DataType" minOccurs="0" </xs:choice>
maxOccurs="unbounded"/> </xs:complexType>
<element name="AccessRules" minOccurs="0">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="UserPIN" type="boolean"
default="false"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="Logo" type="logo:LogoType" minOccurs="0"/>
<element name="Expiry" type="string" minOccurs="0"/>
</sequence>
<attribute name="KeyId" type="string" use="required"/>
<attribute name="KeyAlgorithm" type=
"pskc:KeyAlgorithmType" use="required"/>
</complexType>
The components of the KeyType have the following meanings (see The elements of PINPolicy have the following meaning
Section 5 for further information):
o <Usage> of type UsageType defines the usage of the Secret Key. The o <Local>, the PIN is checked locally on the device before allowing
Usage attribute is described in Section 5.1.3. the key to be used in executing the algorithm
o <Issuer> identifies the issuer of the Secret Key. The Issuer o <Prepend>, the PIN is prepended to the OTP or response hance it
attribute is described in Section 5.1.5. MUST be chacked by the validation server
o <FriendlyName> is a user friendly name that is assigned to the o <InAlgo>, the PIN is used as part of the algorithm computation
Secret Key for easy reference.
o <Data> conveys the data attributes (eg the Secret Key) in name 6. Usage and profile of algorithms for the portable symmetric key
(string) value (base64 encoded) pairs. The value can be container
encrypted, in this case a digest of the non-encrypted data is
present. The <Data> component is further described below.
o <AccessRules> Defines the rules for accessing the credential on This section details the use of the XML encryption and XML signature
the device e.g. a password must be provided by the user to view elements to protect the keys transported in the cotainer. It also
credential info or use the credential to generate an OTP response profiles the number of algorithms supported by XML encryption and XML
signature to a mandatory subset for interoperability.
o KeyId is a global identifier of the Secret Key. See Section 5.1.4. When no algorithm is provided the values within the container are
unencrypted, implementations SHALL ensure the privacy of the key data
through other standard mechanisms e.g. transport level encryption.
o KeyAlgorithm defines the algorithm used with the Secret Key. The 6.1. Usage of EncryptionKey to protect keys in transit
type values are defined in Section 6.2.
o Logo of type LogoType associates display logos with this Secret The EncryptionKey element in the KeyContainer defines the key,
Key algorithm and parameters used to encrypt the Secret Key data
attributes in the Container. The encryption is applied on each
individual Secret Key data in the Container. The encryption method
MUST be the same for all Secret Key data in the container.
o Expiry defines the expiry date of the Secret Key in format DD/MM/ The following sections define specifically the different supported
YYYY means to protect the keys:
The <Data> element is of type <DataType> and is defined as follows: 6.1.1. Protecting keys using a pre-shared key via symmetric algorithms
<complexType name="DataType"> When protecting the payload with pre-shared keys implementations
<sequence> SHOULD set the name of the specific pre-shared key in the KeyName
<element name="Value" type="base64Binary"/> element of the EncryptionKey of the KeyContainer. For example:
<element name="ValueDigest" type="base64Binary" minOccurs="0"/>
<attribute name="Name" type="string" use="required"/>
</sequence>
</complexType>
The 'Name' attribute defines the name of the name-value pair, the <KeyContainer Version="1.0"
following list of attribute names have been reserved: xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey>
<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
</EncryptionKey>
....
SECRET: the key key value in binary, base64 encoded The following is the list of symmetric key encryption algorithm and
possible parameters used to protect the Secret Key data in the
container. Systems implementing PSKC MUST support the MANDATORY
algorithms detailed below.
COUNTER: the event counter for event based OTP algorithms. 8 bytes The encryption algorithm URI can be one of the following.
unsigned integer in big endian (i.e. network byte order) form
base64 encoded
TIME: the time for time based OTP algorithms. 8 bytes unsigned o http://www.w3.org/2001/04/xmlenc#tripledes-cbc - MANDATORY
integer in big endian (i.e. network byte order) form base64 o http://www.w3.org/2001/04/xmlenc#aes128-cbc - MANDATORY
encoded (Number of seconds since 1970)
TIME_INTERVAL: the time interval value for time based OTP o http://www.w3.org/2001/04/xmlenc#aes192-cbc - OPTIONAL
algorithms. 8 bytes unsigned integer in big endian (i.e. network
byte order) form base64 encoded.
The <Value> element in the DataType conveys the value of the name- o http://www.w3.org/2001/04/xmlenc#aes256-cbc - MANDATORY
value pair in base 64 encoding. The value MAY be encrypted or in
clear text as per the EncryptionMethod data element in the
KeyContainer (see Section 6.1.6 for details about KeyContainerType).
When the value is encrypted, the digest value in 'ValueDigest' MUST
be provided. The digest MUST be calculated on the unencrypted value
and MUST use the Digest algorithms specified in DigestMethodType
element of the KeyContainer. The MAC key for the MAC calculation
should use the same key as the encryption key specified in the
EncryptionMethod unless a separate MAC key is specified. When PBE
method is used for encryption, a different password is recommended
for the MAC key derivation. When the key data is in clear text, the
KeyContainer payload signature MAY be used to check the integrity of
the key octets.
6.1.2. UsageType o http://www.w3.org/2001/04/xmlenc#kw-tripledes - MANDATORY
The UsageType defines the usage attribute of the key entity. The o http://www.w3.org/2001/04/xmlenc#kw-aes128 - MANDATORY
UsageType is defined as follows:
<complexType name="UsageType"> o http://www.w3.org/2001/04/xmlenc#kw-aes256 - MANDATORY
<sequence>
<element name="ResponseFormat">
<complexType>
<attribute name="Format" type="pskc:ValueFormat"
use="required"/>
<attribute name="Length" type="unsignedInt"
use="required"/>
<attribute name="CheckDigits" type="boolean"
default="false"/>
</complexType>
</element>
<element name="ChallengeFormat" minOccurs="0">
<complexType>
<attribute name="Format" type="pskc:ValueFormat"
use="required"/>
<attribute name="Min" type="unsignedInt" use="required"/>
<attribute name="Max" type="unsignedInt" use="required"/>
<attribute name="CheckDigits" type="boolean"
default="false"/>
</complexType>
</element>
<element name="AppProfileId" type="string" minOccurs="0"/>
</sequence>
<attribute name="OTP" type="boolean"
default="false"/>
<attribute name="CR" type="boolean"
default="false"/>
<attribute name="Sign" type="boolean" default="false"/>
<attribute name="Encrypt" type="boolean" default="false"/>
<attribute name="Unlock" type="boolean" default="false"/>
</complexType>
The UsageType components have the following meanings: o http://www.w3.org/2001/04/xmlenc#kw-aes512 - OPTIONAL
o <ResponseFormat> holds the algorithm response attributes. When algorithms without integrity checks are used (e.g.
http://www.w3.org/2001/04/xmlenc#aes256-cbc) a keyed MAC value using
the same key as the encryption key SHOULD be placed in the ValueMAC
element of the Data element. In this case the MAC algorithm type
MUST be set in the MACAlgorithm element in the key container entity
as defined in Section 5.1. Implementations of PSKC MUST support the
MANDATORY MAC algorithms detailed below. The MACAlgorithm URI can be
one of the following:
o <ChallengeFormat> hold the challenge attributes in CR based o http://www.w3.org/2000/09/xmldsig#hmac-sha1 - MANDATORY
algorithm computations.
o <AppProfileId> Is the unique shared identifier for out of band For example:
shared common parameters.
6.1.3. DeviceType <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<EncryptionKey>
<ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
</EncryptionKey>
<MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
</MACAlgorithm>
.....
The DeviceType type represents the Device entity in the Container. A 6.1.2. Protecting keys using passphrase based encryption keys
Device MAY be bound to a user and MAY contain more than one keys. It
is recommended that a key is bound to one and only one Device.
The DeviceType is defined as follows: To be able to support passphrase based encryption keys as defined in
PKCS#5 the following XML representation of the PBE relates parameters
have been introduced in the schema. Although the approach is
extensible implementations of PSKC MUST support the
KeyDerivationMethod algorithm URI of
http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2.
<complexType name="DeviceType"> <xs:complexType name="DerivedKeyType">
<sequence> <xs:sequence>
<element name="DeviceId" type="pskc:DeviceIdType" <xs:element name="KeyDerivationMethod"
type="pskc:KeyDerivationMethodType" minOccurs="0"/>
<xs:element ref="xenc:ReferenceList" minOccurs="0"/>
<xs:element name="CarriedKeyName" type="xs:string"
minOccurs="0"/> minOccurs="0"/>
<element name="Key" type="pskc:KeyType" </xs:sequence>
maxOccurs="unbounded"/> <xs:attribute name="Id" type="xs:ID" use="optional"/>
<element name="User" type="pskc:UserType" minOccurs="0"/> <xs:attribute name="Type" type="xs:anyURI" use="optional"/>
</sequence> </xs:complexType>
</complexType> <xs:complexType name="KeyDerivationMethodType">
<xs:sequence>
The components of the DeviceType have the following meanings: <xs:any namespace="##other" minOccurs="0"
o <DeviceId>, a unique identifier for the device, defined by the
DeviceId type.
o <Key>, represents the key entity defined by the KeyType.
o <User>, optionally identifies the owner or the user of the Device,
as defined by the UserType .
6.1.4. DeviceIdType
The DeviceId type represents the identifying criteria to uniquely
identify the device that contains the associated keys. Since devices
can come in different form factors such as hardware tokens,
smartcards, soft tokens in a mobile phone or PC etc this type allows
different criteria to be used. Combined though the criteria MUST
uniquely identify the device. For example for hardware tokens the
combination of SerialNo and Manufacturer will uniquely identify a
device but not SerialNo alone since two different token manufacturers
might issue devices with the same serial number (similar to the
IssuerDN and serial number of a certificate). For keys hold on
banking cards the identification of the device is often done via the
Primary Account Number (PAN, the big number printed on the front of
the card) and an expiry date of the card. DeviceId is an extensible
type that allows all these different ways to uniquely identify a
specific key containing device.
The DeviceIdType is defined as follows:
<complexType name="DeviceIdType">
<sequence>
<element name="Manufacturer" type="string"/>
<element name="SerialNo" type="string"/>
<element name="Model" type="string" minOccurs="0"/>
<element name="IssueNo" type="string" minOccurs="0"/>
<element name="Expiry" type="string" minOccurs="0"/>
</sequence>
</complexType>
The components of the DeviceId type have the following meanings:
o <Manufacturer>, the manufacturer of the device.
o <Model>, the model of the device (e.g one-button-HOTP-token-V1)
o <SerialNo>, the serial number of the device or the PAN (primary
account number) in case of EMV (Europay-MasterCard-Visa) smart
cards.
o <IssueNo>, the issue number in case of smart cards with the same
PAN, equivalent to a PSN (PAN Sequence Number).
o <Expiry>, the expiry date of a device (such as the one on an EMV
card,used when issue numbers are not printed on cards). In format
DD/MM/YYYY
6.1.5. UserType Type
The UserType represents the identifying criteria to uniquely identify
the user who is bound to this device.
The UserType is defined as follows:
<complexType name="UserType">
<sequence>
<sequence>
<element name="UserId" type="string" minOccurs="0"/>
<element name="FirstName" type="string" minOccurs="0"/>
<element name="LastName" minOccurs="0"/>
</sequence>
<element name="Org" type="string" minOccurs="0"/>
</sequence>
</complexType>
The components of the UserType type have the following meanings:
o <FirstName>, user first name.
o <LastName>, user last name.
o <UserId>, user id (UID) or user name.
o <Org>, user organization name.
6.1.6. KeyContainerType
The KeyContainerType represents the key container entity. A
Container MAY contain more than one Device entity; each Device entity
MAY contain more than one Key entity.
The KeyContainerType is defined as follows:
<complexType name="KeyContainerType">
<sequence>
<element name="EncryptionMethod" minOccurs="0">
<complexType>
<complexContent>
<extension base="pskc:EncryptionMethodType"/>
</complexContent>
</complexType>
</element>
<element name="DigestMethod">
<complexType>
<complexContent>
<extension base="pskc:DigestMethodType"/>
</complexContent>
</complexType>
</element>
<element name="Device" type="pskc:DeviceType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<element name="Signature" type="ds:SignatureType" </xs:sequence>
minOccurs="0"/> <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</sequence> </xs:complexType>
<attribute name="Version" type="pskc:VersionType" use="required"/>
</complexType>
The components of the KeyContainer have the following meanings:
o Version, the version number for the portable key container format
(the XML schema defined in this document).
o <EncryptionMethod>, the encryption method used to protect the Key
data attributes
o <DigestMethod>, the digest method used to sign the unencrypted the
Secret Key data attributes
o <Device>, the host Device for one or more Keys.
o <Signature>, contains the signature value of the Container. When
the signature is applied to the entire container, it MUST use XML
Signature methods as defined in [XMLSIG]. The signature is
enveloped.
6.1.7. EncryptionMethodType The attributes of the DerivedKey have the following meanings:
The EncryptionMethodType defines the algorithm and parameters used to o ID (OPTIONAL), the unique ID for this key
encrypt the Secret Key data attributes in the Container. The
encryption is applied on each individual Secret Key data in the
Container. The encryption method MUST be the same for all Secret Key
data in the container.
The EncryptionMethodType is defined as follows: o Type (OPTIONAL), TODO
<complexType name="EncryptionMethodType"> The elements of the DerivedKey have the following meanings:
<sequence>
<element name="EncKeyLabel" minOccurs="0"/>
<choice>
<sequence>
<element name="KeyInfo"
type="ds:KeyInfoType" minOccurs="0"/>
<element name="OAEPParams"
type="base64Binary" minOccurs="0"/>
</sequence>
<sequence>
<element name="PBEEncryptionParam"
type="pskc:PBEEncryptionParamType" minOccurs="0"/>
<element name="IV" type="base64Binary" minOccurs="0"/>
</sequence>
<any namespace="##other" processContents="strict"/>
</choice>
</sequence>
<attribute name="Algorithm"
type="anyURI" use="required"/>
</complexType>
<complexType name="PBEEncryptionParamType"> o <KeyDerivationMethod>: URI of the algorithms used to derive the
<sequence> key e.g.
<element name="PBESalt" type="base64Binary" (http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2)
minOccurs="0"/>
<element name="PBEIterationCount" type="int"
minOccurs="0"/>
</sequence>
<attribute name="EncryptionAlgorithm" type="anyURI"/>
</complexType>
The components of the EncryptionMethodType have the following o <ReferenceList (OPTIONAL)>: a list of IDs of the elements that
meanings: have been encrypted by this key
o <EncKeyLabel>: identifies a unique label for a pre-shared o <CarriedKeyName (OPTIONAL)>: friendly name of the key
encryption key.
o Algorithm: identifies the encryption algorithm used to protect the When using the PKCS5 PBE algorithm
Secret Key data. If EncryptionMethod is absent in (URI=http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2)
KeyContainerType, implementations MUST guarantee the privacy of and related parameters, the DerivedKey element MUST be used within
the Secret Key Data through other mechanisms e.g. through the EncryptionKey element of the KeyContainer in exactly the form as
transport level security. shown below:
o <KeyInfo>: conveys the information of the key if an RSA algorithm <?xml version="1.0" encoding="UTF-8"?>
has been used. <KeyContainer
xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:pkcs-5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Version="1.0">
<EncryptionKey>
<DerivedKey Id="#Passphrase1">
<CarriedKeyName>Passphrase1</CarriedKeyName>
<KeyDerivationMethod
Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
<Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
<Salt>
<Specified>Df3dRAhjGh8=</Specified>
</Salt>
<IterationCount>2000</IterationCount>
<KeyLength>16</KeyLength>
<PRF/>
</Parameters>
</KeyDerivationMethod>
</DerivedKey>
</EncryptionKey>
....
o <OAEPParams>: conveys the OAEP parameters if an RSA algorithm has 6.2. Protecting keys using asymmetric algorithms
been used.
o <PBEEncryptionParam>: conveys the PBE parameters if a password- The following is the list of asymmetric key encryption algorithm and
based encryption (PBE) algorithm has been used. possible parameters used to protect the Secret Key data in the
container. Systems implementing PSKC MUST support the MANDATORY
algorithms detailed below. The encryption algorithm URI can be one
of the following.
o o http://www.w3.org/2001/04/xmlenc#rsa-1_5 - MANDATORY
* <PBESalt>: conveys the Salt when [PKCS5] password-based o http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p - OPTIONAL
encryption is applied.
* <PBEIterationCount>: conveys the iteration count value in For example:
[PKCS5] password-based encryption if it is different from the
default value.
* <EncryptionAlgorithm>: specifies the encryption algorithm after TODO
a PBE key is derived. For example, PBE-AES128-CBC should use
URI http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc
o <IV>: conveys the initialization vector for CBC based encryption 6.3. Profile of Key Algorithm
algorithms. It is recommended for security reasons to transmit
this value out of band and treat it the same manner as the key
value.
6.1.8. DigestMethodType This section profiles the type(s) of algorithm of that can be used by
the key(s) transported in the container. The following algorithm
URIs are among the default support list.
The DigestMethodType defines the algorithm and parameters used to o http://www.w3.org/2001/04/xmlenc#tripledes-cbc
create the digest on the unencrypted Secret Key data in the
Container. The digest is applied on each individual Secret Key data
in the Container before encryption. The digest method MUST be the
same for all Secret Key data in the container. Unless a different
digest key is specified it is assumed that keyed digest algorithms
will use the same key as for encryption
The DigestMethodType is defined as follows: o http://www.w3.org/2001/04/xmlenc#aes128-cbc
<complexType name="DigestMethodType"> o http://www.w3.org/2001/04/xmlenc#aes192-cbc
<sequence>
<element name="DigestKeyLabel" minOccurs="0"/>
</sequence>
<attribute name="Algorithm"
type="anyURI" use="required"/>
</complexType>
The components of the DigestMethodType have the following meanings: o http://www.w3.org/2001/04/xmlenc#aes256-cbc
o Algorithm, identifies the digest algorithm used to protect the o http://www.ietf.org/keyprov/pskc#hotp
Secret Key data.
o <DigestKeyLabel>: identifies a unique label for a pre-shared o http://www.ietf.org/keyprov/pskc#valuecompare
digest key.
6.2. KeyAlgorithmType 6.3.1. OTP Key Algorithm Identifiers
The KeyAlgorithmType defines the algorithms in which the Secret Key OTP key algorithm URIs have not been defined in a commonly available
data is used. It refers to anyURI. standard specification. This document defines the following URIs for
the known open standard OTP algorithms.
6.3. ValueFormat 6.3.1.1. HOTP
The ValueFormat defines allowed formats for challenges or responses Standard document: RFC4226
in the OTP algorithms.
The ValueFormat is defined as follows: Identifier: http://www.ietf.org/keyprov/pskc#hotp
<simpleType name="ValueFormat"> Note that the actual URL will be finalized once a URL for this
<restriction base="string"> document is determined.
<enumeration value="DECIMAL"/>
<enumeration value="HEXADECIMAL"/>
<enumeration value="ALPHANUMERIC"/>
<enumeration value="BASE64"/>
<enumeration value="BINARY"/>
</restriction>
</simpleType>
DECIMAL Only numerical digits 6.3.1.2. Other OTP Algorithms
HEXADECIMAL Hexadecimal response An implementation should refer to vendor supplied OTP key algorithm
URIs for proprietary algorithms.
ALPHANUMERIC All letters and numbers (case sensitive) 6.3.2. PIN key value compare algorithm identifier
BASE64 Base 64 encoded PIN key algorithm URIs have not been defined in a commonly available
standard specification. This document defines the following URIs for
a straight value comaprison of the transported secret key data as
when required to compare a PIN.
BINARY Binary data, this is mainly used in case of connected Identifier: http://www.ietf.org/keyprov/pskc#valuecompare
devices
6.4. Data elements Note that the actual URL will be finalized once a URL for this
document is determined.
6.4.1. KeyContainer 7. Reserved data attribute names
The KeyContainer data element is defined as: The following key data attribute names have been reserved:
<element name="KeyContainer" type="pskc:KeyContainerType"/> SECRET: the shared secret key value in binary, base64 encoded
The KeyContainer data element is of type KeyContainerType defined in COUNTER: the event counter for event based OTP algorithms. 8 bytes
Section 6.1.6. unsigned integer in big endian (i.e. network byte order) form
base64 encoded
The EncryptionMethod data element in the KeyContainer defines the TIME: the time for time based OTP algorithms. 8 bytes unsigned
encryption algorithm used to protect the Key data. In a multi-key integer in big endian (i.e. network byte order) form base64
KeyContainer, the same encryption method and the same encryption key encoded (Number of seconds since 1970)
MUST be used for all key data elements.
The KeyContainer data element MAY contain multiple Device data TIME_INTERVAL: the time interval value for time based OTP
elements, allowing for bulk provisioning of keys. algorithms. 8 bytes unsigned integer in big endian (i.e. network
byte order) form base64 encoded.
The Signature data element is of type <ds:Signature> as defined in TIME_DRIFT: the device clock drift value for time based OTP
[XMLSIG] and MAY be omitted in the KeyContainer data element when algorithms. The value indicates number of seconds that the device
application layer provisioning or transport layer provisioning clock may drift each day. 2 bytes unsigned integer in big endian
protocols provide the integrity and authenticity of the payload (i.e. network byte order) form base64 encoded.
between the sender and the recipient of the container. When
required, this specification recommends using a symmetric key based
signature with the same key used in the encryption of the secret key
data. The signature is enveloped.
7. Formal Syntax 8. Formal Syntax
The following syntax specification uses the widely adopted XML schema The following syntax specification uses the widely adopted XML schema
format as defined by a W3C recommendation format as defined by a W3C recommendation
(http://www.w3.org/TR/xmlschema-0/). It is a complete syntax (http://www.w3.org/TR/xmlschema-0/). It is a complete syntax
definition in the XML Schema Definition format (XSD) definition in the XML Schema Definition format (XSD)
All implementations of this standard must comply with the schema All implementations of this standard must comply with the schema
below. below.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 31, line 16 skipping to change at page 31, line 16
The following syntax specification uses the widely adopted XML schema The following syntax specification uses the widely adopted XML schema
format as defined by a W3C recommendation format as defined by a W3C recommendation
(http://www.w3.org/TR/xmlschema-0/). It is a complete syntax (http://www.w3.org/TR/xmlschema-0/). It is a complete syntax
definition in the XML Schema Definition format (XSD) definition in the XML Schema Definition format (XSD)
All implementations of this standard must comply with the schema All implementations of this standard must comply with the schema
below. below.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:logo="urn:ietf:params:xml:ns:keyprov:logo:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
targetNamespace="urn:ietf:params:xml:ns:keyprov:container:1.0" targetNamespace="urn:ietf:params:xml:ns:keyprov:container:1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified" elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0"> version="1.0">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
xmldsig-core-schema.xsd"/> xmldsig-core-schema.xsd"/>
<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
<xs:import namespace="urn:ietf:params:xml:ns:keyprov:logo:1.0" schemaLocation="http://www.w3.org/TR/2002/
schemaLocation="keyprov-logo-1.0.xsd"/> REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<xs:complexType name="KeyContainerType"> <xs:complexType name="KeyContainerType">
<xs:sequence> <xs:sequence>
<xs:element name="EncryptionMethod" minOccurs="0"> <xs:element name="EncryptionKey" type="ds:KeyInfoType"
<xs:complexType> minOccurs="0"/>
<xs:complexContent> <xs:element name="MACAlgorithm" type="pskc:KeyAlgorithmType"
<xs:extension base="pskc:EncryptionMethodType"/> minOccurs="0"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="DigestMethod" minOccurs="0">
<xs:complexType>
<xs:complexContent>
<xs:extension base="pskc:DigestMethodType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="Device" type="pskc:DeviceType" <xs:element name="Device" type="pskc:DeviceType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:element name="Signature" type="ds:SignatureType" <xs:element name="Signature" type="ds:SignatureType"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="Version" type="pskc:VersionType" <xs:attribute name="Version" type="pskc:VersionType"
use="required"/> use="required"/>
</xs:complexType> </xs:complexType>
<xs:simpleType name="VersionType" final="restriction"> <xs:simpleType name="VersionType" final="restriction">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}"/> <xs:pattern value="\d{1,2}\.\d{1,3}"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="KeyType"> <xs:complexType name="KeyType">
<xs:sequence> <xs:sequence>
<xs:element name="Issuer" type="xs:string"/> <xs:element name="Issuer" type="xs:string" minOccurs="0"/>
<xs:element name="Usage" type="pskc:UsageType"/> <xs:element name="Usage" type="pskc:UsageType"/>
<xs:element name="FriendlyName" type="xs:string" minOccurs="0"/> <xs:element name="CardAppPersoProfileId" type="xs:string"
<xs:element name="Data" type="pskc:DataType" minOccurs="0"/>
minOccurs="0" maxOccurs="unbounded"/> <xs:element name="FriendlyName" type="xs:string"
<xs:element name="AccessRules" minOccurs="0"> minOccurs="0"/>
<xs:complexType> <xs:element name="Data" type="pskc:DataType" minOccurs="0"
<xs:simpleContent> maxOccurs="unbounded"/>
<xs:extension base="xs:string"> <xs:element name="PINPolicy" type="pskc:PINPolicyType"
<xs:attribute name="UserPIN" type="xs:boolean" minOccurs="0"/>
default="false"/> <xs:element name="ExpiryDate" type="xs:dateTime"
</xs:extension> minOccurs="0"/>
</xs:simpleContent> <xs:element name="StartDate" type="xs:dateTime"
</xs:complexType> minOccurs="0"/>
</xs:element>
<xs:element name="Logo" type="logo:LogoType" minOccurs="0"/>
<xs:element name="Expiry" type="xs:string" minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="KeyId" type="xs:string" use="required"/> <xs:attribute name="KeyId" type="xs:string" use="required"/>
<xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType" <xs:attribute name="KeyAlgorithm" type="pskc:KeyAlgorithmType"
use="required"/> use="required"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="DerivedKeyType">
<xs:sequence>
<xs:element name="KeyDerivationMethod"
type="pskc:KeyDerivationMethodType" minOccurs="0"/>
<xs:element ref="xenc:ReferenceList" minOccurs="0"/>
<xs:element name="CarriedKeyName" type="xs:string"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Id" type="xs:ID" use="optional"/>
<xs:attribute name="Type" type="xs:anyURI" use="optional"/>
</xs:complexType>
<xs:complexType name="KeyDerivationMethodType">
<xs:sequence>
<xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="PINPolicyType">
<xs:sequence>
<xs:element name="PINUsageMode"
type="pskc:PINUsageModeType"/>
<xs:element name="WrongPINtry" type="xs:unsignedInt"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="PINKeyId" type="xs:string"
use="required"/>
</xs:complexType>
<xs:complexType name="PINUsageModeType">
<xs:choice maxOccurs="unbounded">
<xs:element name="Local"/>
<xs:element name="Prepend"/>
<xs:element name="Embed"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="DeviceIdType"> <xs:complexType name="DeviceIdType">
<xs:sequence> <xs:sequence>
<xs:element name="Manufacturer" type="xs:string"/> <xs:element name="Manufacturer" type="xs:string"/>
<xs:element name="SerialNo" type="xs:string"/> <xs:element name="SerialNo" type="xs:string"/>
<xs:element name="Model" type="xs:string" minOccurs="0"/> <xs:element name="Model" type="xs:string" minOccurs="0"/>
<xs:element name="IssueNo" type="xs:string" minOccurs="0"/> <xs:element name="IssueNo" type="xs:string" minOccurs="0"/>
<xs:element name="Expiry" type="xs:string" minOccurs="0"/> <xs:element name="ExpiryDate" type="xs:dateTime" minOccurs="0"/>
<xs:element name="StartDate" type="xs:dateTime" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="DeviceType"> <xs:complexType name="DeviceType">
<xs:sequence> <xs:sequence>
<xs:element name="DeviceId" type="pskc:DeviceIdType" <xs:element name="DeviceId" type="pskc:DeviceIdType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="Key" type="pskc:KeyType" <xs:element name="Key" type="pskc:KeyType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:element name="User" type="pskc:UserType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="UserType">
<xs:sequence>
<xs:sequence>
<xs:element name="UserId" type="xs:string" minOccurs="0"/> <xs:element name="UserId" type="xs:string" minOccurs="0"/>
<xs:element name="FirstName" type="xs:string" minOccurs="0"/>
<xs:element name="LastName" minOccurs="0"/>
</xs:sequence>
<xs:element name="Org" type="xs:string" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="UsageType"> <xs:complexType name="UsageType">
<xs:sequence> <xs:sequence>
<xs:element name="ResponseFormat"> <xs:element name="ResponseFormat">
<xs:complexType> <xs:complexType>
<xs:attribute name="Format" type="pskc:ValueFormatType" <xs:attribute name="Format"
use="required"/> type="pskc:ValueFormatType" use="required"/>
<xs:attribute name="Length" type="xs:unsignedInt" <xs:attribute name="Length" type="xs:unsignedInt"
use="required"/> use="required"/>
<xs:attribute name="CheckDigits" type="xs:boolean" <xs:attribute name="CheckDigits" type="xs:boolean"
default="false"/> default="false"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="ChallengeFormat" minOccurs="0"> <xs:element name="ChallengeFormat" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:attribute name="Format" type="pskc:ValueFormatType" <xs:attribute name="Format"
use="required"/> type="pskc:ValueFormatType" use="required"/>
<xs:attribute name="Min" type="xs:unsignedInt" <xs:attribute name="Min" type="xs:unsignedInt"
use="required"/> use="required"/>
<xs:attribute name="Max" type="xs:unsignedInt" <xs:attribute name="Max" type="xs:unsignedInt"
use="required"/> use="required"/>
<xs:attribute name="CheckDigits" type="xs:boolean" <xs:attribute name="CheckDigits" type="xs:boolean"
default="false"/> default="false"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="AppProfileId" type="xs:string" minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="OTP" type="xs:boolean" <xs:attribute name="OTP" type="xs:boolean" default="false"/>
default="false"/> <xs:attribute name="CR" type="xs:boolean" default="false"/>
<xs:attribute name="CR" type="xs:boolean" <xs:attribute name="Integrity" type="xs:boolean"
default="false"/>
<xs:attribute name="Sign" type="xs:boolean"
default="false"/> default="false"/>
<xs:attribute name="Encrypt" type="xs:boolean" <xs:attribute name="Encrypt" type="xs:boolean"
default="false"/> default="false"/>
<xs:attribute name="Unlock" type="xs:boolean" <xs:attribute name="Unlock" type="xs:boolean"
default="false"/> default="false"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="DataType">
<xs:complexType name="EncryptionMethodType">
<xs:sequence> <xs:sequence>
<xs:element name="EncKeyLabel" minOccurs="0"/>
<xs:choice> <xs:choice>
<xs:sequence> <xs:element name="PlainValue" type="xs:base64Binary"/>
<xs:element name="KeyInfo" <xs:element name="EncryptedValue"
type="ds:KeyInfoType" minOccurs="0"/> type="xenc:EncryptedDataType"/>
<xs:element name="OAEPParams"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
<xs:sequence>
<xs:element name="PBEEncryptionParam"
type="pskc:PBEEncryptionParamType" minOccurs="0"/>
<xs:element name="IV" type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
<xs:any namespace="##other" processContents="strict"/>
</xs:choice> </xs:choice>
</xs:sequence> <xs:element name="ValueMAC" type="xs:base64Binary"
<xs:attribute name="Algorithm"
type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="PBEEncryptionParamType">
<xs:sequence>
<xs:element name="PBESalt" type="xs:base64Binary"
minOccurs="0"/>
<xs:element name="PBEIterationCount" type="xs:int"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="EncryptionAlgorithm" type="xs:anyURI"/> <xs:attribute name="Name" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="DigestMethodType">
<xs:sequence>
<xs:element name="DigestKeyLabel" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Algorithm"
type="xs:anyURI" use="required"/>
</xs:complexType> </xs:complexType>
<xs:simpleType name="KeyAlgorithmType"> <xs:simpleType name="KeyAlgorithmType">
<xs:restriction base="xs:anyURI"/> <xs:restriction base="xs:anyURI"/>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="ValueFormatType"> <xs:simpleType name="ValueFormatType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="DECIMAL"/> <xs:enumeration value="DECIMAL"/>
<xs:enumeration value="HEXADECIMAL"/> <xs:enumeration value="HEXADECIMAL"/>
<xs:enumeration value="ALPHANUMERIC"/> <xs:enumeration value="ALPHANUMERIC"/>
<xs:enumeration value="BASE64"/> <xs:enumeration value="BASE64"/>
<xs:enumeration value="BINARY"/> <xs:enumeration value="BINARY"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element name="KeyContainer" type="pskc:KeyContainerType"/>
<xs:element name="KeyContainer"
type="pskc:KeyContainerType"/>
<xs:complexType name="DataType">
<xs:sequence>
<xs:element name="Value" type="xs:base64Binary"/>
<xs:element name="ValueDigest"
type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Name" type="xs:string"
use="required"/>
</xs:complexType>
</xs:schema> </xs:schema>
LogoType is defined in the following schema. 9. Security Considerations
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:logo="urn:ietf:params:xml:ns:keyprov:logo:1.0"
targetNamespace="urn:ietf:params:xml:ns:keyprov:logo:1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0">
<!-- LogoType -->
<complexType name="LogoType">
<annotation>
<documentation xml:lang="en">
Type to include logo information.
</documentation>
</annotation>
<sequence>
<element name="CommunityLogos" type="logo:LogoInfoType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="IssuerLogo" type="logo:LogoInfoType"
minOccurs="0"/>
<element name="OtherLogos" type="logo:LogoInfoType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="LogoInfoType">
<annotation>
<documentation xml:lang="en">
Define logo information for a given logo. It can either embed
full logo data information, or includes only a reference URI
where the full log data information with type LogoDataType
can be downloaded.
</documentation>
</annotation>
<sequence>
<choice>
<element name="LogoData" type="logo:LogoDataType"/>
<element name="LogReference" type="anyURI"/>
</choice>
</sequence>
</complexType>
<complexType name="LogoDataType">
<annotation>
<documentation xml:lang="en">
Define logo data information for a given logo image.
</documentation>
</annotation>
<sequence>
<element name="LogoImageDetails"
type="logo:LogoImageDetailsType"/>
<element name="LogoImageInfo" type="logo:LogoImageInfoType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="LogoImageDetailsType">
<annotation>
<documentation xml:lang="en">
Define logo image data for a given logo image.
</documentation>
</annotation>
<sequence>
<choice>
<element name="ImageData" type="base64Binary"/>
<element name="ImageReference" type="anyURI"/>
</choice>
</sequence>
<attribute name="MIMEType" type="logo:MIMETypeType"
use="required"/>
</complexType>
<complexType name="LogoImageInfoType">
<annotation>
<documentation xml:lang="en">
Define logo image parameters for a given logo image.
</documentation>
</annotation>
<sequence>
<element name="Size" type="integer" minOccurs="0"/>
<element name="xSize" type="integer" minOccurs="0"/>
<element name="ySize" type="integer" minOccurs="0"/>
<element name="Resolution" type="logo:LogoImageResolutionType"
minOccurs="0"/>
</sequence>
<attribute name="colored" type="boolean" default="true"/>
<attribute name="lang" type="string" use="optional"/>
</complexType>
<complexType name="LogoImageResolutionType">
<annotation>
<documentation xml:lang="en">
Define logo image resolution parameters.
</documentation>
</annotation>
<sequence>
<element name="NumBits" type="integer"/>
<element name="TableSize" type="integer"/>
</sequence>
</complexType>
<!-- MimeTypeType -->
<simpleType name="MIMETypeType">
<annotation>
<documentation xml:lang="en">
Can be one of the following supported image content types.
</documentation>
</annotation>
<restriction base="string">
<enumeration value="image/gif"/>
<enumeration value="image/jpeg"/>
</restriction>
</simpleType>
</schema>
8. Security Considerations
The portable key container carries sensitive information (e.g., The portable key container carries sensitive information (e.g.,
cryptographic keys) and may be transported across the boundaries of cryptographic keys) and may be transported across the boundaries of
one secure perimeter to another. For example, a container residing one secure perimeter to another. For example, a container residing
within the secure perimeter of a back-end provisioning server in a within the secure perimeter of a back-end provisioning server in a
secure room may be transported across the internet to an end-user secure room may be transported across the internet to an end-user
device attached to a personal computer. This means that special care device attached to a personal computer. This means that special care
must be taken to ensure the confidentiality, integrity, and must be taken to ensure the confidentiality, integrity, and
authenticity of the information contained within. authenticity of the information contained within.
8.1. Payload confidentiality 9.1. Payload confidentiality
By design, the container allows two main approaches to guaranteeing By design, the container allows two main approaches to guaranteeing
the confidentiality of the information it contains while transported. the confidentiality of the information it contains while transported.
First, the container key data payload may be encrypted. First, the container key data payload may be encrypted.
In this case no transport layer security is required. However, In this case no transport layer security is required. However,
standard security best practices apply when selecting the strength of standard security best practices apply when selecting the strength of
the cryptographic algorithm for payload encryption. Symmetric the cryptographic algorithm for payload encryption. Symmetric
cryptographic cipher should be used - the longer the cryptographic cryptographic cipher should be used - the longer the cryptographic
skipping to change at page 39, line 44 skipping to change at page 35, line 44
key, the more secure the protection is. key, the more secure the protection is.
If the payload is encrypted with a method that uses one of the If the payload is encrypted with a method that uses one of the
password-based encryption methods provided above, the payload may be password-based encryption methods provided above, the payload may be
subjected to password dictionary attacks to break the encryption subjected to password dictionary attacks to break the encryption
password and recover the information. Standard security best password and recover the information. Standard security best
practices for selection of strong encryption passwords apply practices for selection of strong encryption passwords apply
[Schneier]. [Schneier].
Practical implementations should use PBESalt and PBEIterationCount Practical implementations should use PBESalt and PBEIterationCount
when PBE encryption is used. Different PBESalt value per credential when PBE encryption is used. Different PBESalt value per key
record should be used for best protection. container should be used for best protection.
The second approach to protecting the confidentiality of the payload The second approach to protecting the confidentiality of the payload
is based on using transport layer security. The secure channel is based on using transport layer security. The secure channel
established between the source secure perimeter (the provisioning established between the source secure perimeter (the provisioning
server from the example above) and the target perimeter (the device server from the example above) and the target perimeter (the device
attached to the end-user computer) utilizes encryption to transport attached to the end-user computer) utilizes encryption to transport
the messages that travel across. No payload encryption is required the messages that travel across. No payload encryption is required
in this mode. Secure channels that encrypt and digest each message in this mode. Secure channels that encrypt and digest each message
provide an extra measure of security, especially when the signature provide an extra measure of security, especially when the signature
of the payload does not encompass the entire payload. of the payload does not encompass the entire payload.
Because of the fact that the plain text payload is protected only by Because of the fact that the plain text payload is protected only by
the transport layer security, practical implementation must ensure the transport layer security, practical implementation must ensure
protection against man-in-the-middle attacks [Schneier]. Validating protection against man-in-the-middle attacks [Schneier]. Validating
the secure channel end-points is critically important for eliminating the secure channel end-points is critically important for eliminating
intruders that may compromise the confidentiality of the payload. intruders that may compromise the confidentiality of the payload.
8.2. Payload integrity 9.2. Payload integrity
The portable symmetric key container provides a mean to guarantee the The portable symmetric key container provides a mean to guarantee the
integrity of the information it contains through digital signatures. integrity of the information it contains through digital signatures.
For best security practices, the digital signature of the container For best security practices, the digital signature of the container
should encompass the entire payload. This provides assurances for should encompass the entire payload. This provides assurances for
the integrity of all attributes. It also allows verification of the the integrity of all attributes. It also allows verification of the
integrity of a given payload even after the container is delivered integrity of a given payload even after the container is delivered
through the communication channel to the target perimeter and channel through the communication channel to the target perimeter and channel
message integrity check is no longer possible. message integrity check is no longer possible.
8.3. Payload authenticity 9.3. Payload authenticity
The digital signature of the payload is the primary way of showing The digital signature of the payload is the primary way of showing
its authenticity. The recipient of the container may use the public its authenticity. The recipient of the container may use the public
key associated with the signature to assert the authenticity of the key associated with the signature to assert the authenticity of the
sender by tracing it back to a preloaded public key or certificate. sender by tracing it back to a preloaded public key or certificate.
Note that the digital signature of the payload can be checked even Note that the digital signature of the payload can be checked even
after the container has been delivered through the secure channel of after the container has been delivered through the secure channel of
communication. communication.
A weaker payload authenticity guarantee may be provided by the A weaker payload authenticity guarantee may be provided by the
transport layer if it is configured to digest each message it transport layer if it is configured to digest each message it
transports. However, no authenticity verification is possible once transports. However, no authenticity verification is possible once
the container is delivered at the recipient end. This approach may the container is delivered at the recipient end. This approach may
be useful in cases where the digital signature of the container does be useful in cases where the digital signature of the container does
not encompass the entire payload. not encompass the entire payload.
9. Acknowledgements 10. Acknowledgements
The authors of this draft would like to thank the following people The authors of this draft would like to thank the following people
for their contributions and support to make this a better for their contributions and support to make this a better
specification: Apostol Vassilev, Jon Martinson, Siddhart Bajaj, Stu specification: Apostol Vassilev, Shuh Chang, Jon Martinson, Siddhart
Veath, Kevin Lewis, Philip Hallam-Baker, Hannes Tschofenig, Andrea Bajaj, Stu Veath, Kevin Lewis, Philip Hallam-Baker, Hannes
Doherty, Magnus Nystrom, Tim Moses, and Anders Rundgren. Tschofenig, Andrea Doherty, Magnus Nystrom, Tim Moses, and Anders
Rundgren.
10. Appendix A - Example Symmetric Key Containers 11. Appendix A - Example Symmetric Key Containers
All examples are syntactically correct and compatible with the XML All examples are syntactically correct and compatible with the XML
schema in section 7. However, <Signature>, Key <Value> and Key schema in section 7.
<ValueDigest> data values are fictitious
10.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret 11.1. Symmetric Key Container with a single Non-Encrypted HOTP Secret
Key Key
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:container:1.0
keyprov-pskc-1.0.xsd" Version="1.0">
<Device> <Device>
<DeviceId> <DeviceId>
<Manufacturer>Token Manufacturer</Manufacturer> <Manufacturer>ACME</Manufacturer>
<SerialNo>98765432188</SerialNo> <SerialNo>0755225266</SerialNo>
<Expiry>12/31/2012</Expiry>
</DeviceId> </DeviceId>
<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="77654321871"> KeyId="0755225266">
<Issuer>Credential Issuer</Issuer> <Issuer>AnIssuer</Issuer>
<Usage OTP="true"> <Usage OTP="true">
<ResponseFormat Format="DECIMAL" Length="6"/> <ResponseFormat Length="6" Format="DECIMAL"/>
</Usage> </Usage>
<FriendlyName>MyFirstToken</FriendlyName> <Data Name="COUNTER">
<PlainValue>AprkuA==</PlainValue>
</Data>
<Data Name="SECRET"> <Data Name="SECRET">
<Value> <PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>
zOkqJENSsh6b2hdXz1WBK/oprbY=
</Value>
</Data> </Data>
<ExpiryDate>2012-12-31T00:00:00</ExpiryDate>
</Key>
</Device>
</KeyContainer>
11.2. Symmetric Key Container with a single PIN protected Non-Encrypted
HOTP Secret Key
<?xml version="1.0" encoding="UTF-8"?>
<KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0">
<Device>
<DeviceId>
<Manufacturer>ACME</Manufacturer>
<SerialNo>0755225266</SerialNo>
</DeviceId>
<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="0755225266">
<Issuer>AnIssuer</Issuer>
<Usage OTP="true">
<ResponseFormat Length="6" Format="DECIMAL"/>
</Usage>
<Data Name="COUNTER"> <Data Name="COUNTER">
<Value>AAAAAAAAAAA=</Value> <PlainValue>AprkuA==</PlainValue>
</Data>
<Data Name="SECRET">
<PlainValue>/4h3rOTeBegJwGpmTTq4F+RlNR0=</PlainValue>
</Data>
<PINPolicy PINKeyId="07552252661">
<PINUsageMode>
<Local/>
</PINUsageMode>
</PINPolicy>
</Key>
<Key KeyId="07552252661"
KeyAlgorithm="http://www.ietf.org/keyprov/pskc#pin">
<Usage>
<ResponseFormat Length="4" Format="DECIMAL"/>
</Usage>
<Data Name="SECRET">
<PlainValue>MTIzNA==</PlainValue>
</Data> </Data>
<Expiry>10/30/2012</Expiry>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
10.2. Symmetric Key Container with a single Password-based Encrypted 11.3. Symmetric Key Container with a single AES-256-CBC Encrypted HOTP
HOTP Secret Key Secret Key
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<KeyContainer <KeyContainer Version="1.0"
xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0" xmlns="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
xsi:schemaLocation="urn:ietf:params:xml:ns:keyprov:container:1.0 <EncryptionKey>
keyprov-pskc-1.0.xsd" Version="1.0"> <ds:KeyName>PRE_SHARED_KEY</ds:KeyName>
<EncryptionMethod Algorithm= </EncryptionKey>
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbes2"> <MACAlgorithm>http://www.w3.org/2000/09/xmldsig#hmac-sha1
<PBEEncryptionParam EncryptionAlgorithm= </MACAlgorithm>
"http://www.w3.org/2001/04/xmlenc#kw-aes128-cbc">
<PBESalt>y6TzckeLRQw=</PBESalt>
<PBEIterationCount>1024</PBEIterationCount>
</PBEEncryptionParam>
<IV>c2FtcGxlaXY=</IV>
</EncryptionMethod>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<Device> <Device>
<DeviceId> <DeviceId>
<Manufacturer>Token Manufacturer</Manufacturer> <Manufacturer>ACME</Manufacturer>
<SerialNo>98765432187</SerialNo> <SerialNo>0755225266</SerialNo>
<Expiry>12/31/2012</Expiry>
</DeviceId> </DeviceId>
<Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp" <Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="77654321870"> KeyId="0755225266">
<Issuer>Credential Issuer</Issuer> <Issuer>AnIssuer</Issuer>
<Usage OTP="true"> <Usage OTP="true">
<ResponseFormat Format="DECIMAL" Length="6"/> <ResponseFormat Length="8" Format="DECIMAL"/>
</Usage> </Usage>
<FriendlyName>MyFirstToken</FriendlyName>
<Data Name="SECRET">
<Value>
JSPUyp3azOkqJENSsh6b2hdXz1WBYypzJxEr+ikQAa22M6V/BgZhRg==
</Value>
<ValueDigest>
i8j+kpbfKQsSlwmJYS99lQ==
</ValueDigest>
</Data>
<Data Name="COUNTER"> <Data Name="COUNTER">
<Value>AAAAAAAAAAA=</Value> <PlainValue>AprkuA==</PlainValue>
</Data>
<Data Name="SECRET">
<EncryptedValue>
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
kyzrWTJuhJKQHhZtf2CWbKC5H3LdfAPvKzHHQ8SdxyE=
</xenc:CipherValue>
</xenc:CipherData>
</EncryptedValue>
<ValueMAC>cwJI898rRpGBytTqCAsegaQqPZA=</ValueMAC>
</Data> </Data>
<Expiry>10/30/2012</Expiry>
</Key> </Key>
</Device> </Device>
</KeyContainer> </KeyContainer>
11. Normative References 11.4. Symmetric Key Container with signature and a single Password-
based Encrypted HOTP Secret Key
<?xml version="1.0" encoding="UTF-8"?>
<pskc:KeyContainer
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:pkcs-5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Version="1.0">
<pskc:EncryptionKey>
<pskc:DerivedKey Id="#Passphrase1">
<pskc:CarriedKeyName>Passphrase1</pskc:CarriedKeyName>
<pskc:KeyDerivationMethod
Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2">
<pkcs-5:Parameters xsi:type="pkcs-5:PBKDF2ParameterType">
<Salt>
<Specified>Df3dRAhjGh8=</Specified>
</Salt>
<IterationCount>2000</IterationCount>
<KeyLength>16</KeyLength>
<PRF/>
</pkcs-5:Parameters>
</pskc:KeyDerivationMethod>
<xenc:ReferenceList>
<xenc:DataReference URI="#ED"/>
</xenc:ReferenceList>
</pskc:DerivedKey>
</pskc:EncryptionKey>
<pskc:Device>
<pskc:DeviceId>
<pskc:Manufacturer>ACME</pskc:Manufacturer>
<pskc:SerialNo>0755225266</pskc:SerialNo>
</pskc:DeviceId>
<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="0755225266">
<pskc:Issuer>AnIssuer</pskc:Issuer>
<pskc:Usage OTP="true">
<pskc:ResponseFormat Length="6" Format="DECIMAL"/>
</pskc:Usage>
<pskc:Data Name="COUNTER">
<pskc:PlainValue>AprkuA==</pskc:PlainValue>
</pskc:Data>
<pskc:Data Name="SECRET">
<pskc:EncryptedValue Id="ED">
<xenc:EncryptionMethod Algorithm=
"http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
<xenc:CipherData>
<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
</pskc:Data>
</pskc:Key>
</pskc:Device>
<pskc:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="">
<ds:DigestMethod Algorithm=
"http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>CN=KeyProvisioning'R'Us.com,C=US
</ds:X509IssuerName>
<ds:X509SerialNumber>12345678</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</ds:KeyInfo>
</pskc:Signature>
</pskc:KeyContainer>
11.5. Symmetric Key Container with a single RSA 1.5 Encrypted HOTP
Secret Key
<?xml version="1.0" encoding="UTF-8"?>
<pskc:KeyContainer Version="1.0"
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:container:1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<pskc:EncryptionKey>
<ds:X509Data>
<ds:X509Certificate>miib</ds:X509Certificate>
</ds:X509Data>
</pskc:EncryptionKey>
<pskc:Device>
<pskc:DeviceId>
<pskc:Manufacturer>ACME</pskc:Manufacturer>
<pskc:SerialNo>0755225266</pskc:SerialNo>
</pskc:DeviceId>
<pskc:Key KeyAlgorithm="http://www.ietf.org/keyprov/pskc#hotp"
KeyId="0755225266">
<pskc:Issuer>AnIssuer</pskc:Issuer>
<pskc:Usage OTP="true">
<pskc:ResponseFormat Length="8" Format="DECIMAL"/>
</pskc:Usage>
<pskc:Data Name="COUNTER">
<pskc:PlainValue>AprkuA==</pskc:PlainValue>
</pskc:Data>
<pskc:Data Name="SECRET">
<pskc:EncryptedValue Id="ED">
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa_1_5"/>
<xenc:CipherData>
<xenc:CipherValue>rf4dx3rvEPO0vKtKL14NbeVu8nk=
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
</pskc:Data>
</pskc:Key>
</pskc:Device>
</pskc:KeyContainer>
12. Normative References
[CAP] MasterCard International, "Chip Authentication Program [CAP] MasterCard International, "Chip Authentication Program
Functional Architecture", September 2004. Functional Architecture", September 2004.
[DSKPP] "Dynamic Symmetric Key Provisioning Protocol", Internet [DSKPP] "Dynamic Symmetric Key Provisioning Protocol", Internet
Draft Informational, URL: http://tools.ietf.org/wg/ Draft Informational, URL: http://tools.ietf.org/wg/
keyprov/draft-doherty-keyprov-dskpp-00.txt, June 2007. keyprov/draft-doherty-keyprov-dskpp-00.txt, June 2007.
[HOTP] MRaihi, D., "HOTP: An HMAC-Based One Time Password [HOTP] MRaihi, D., "HOTP: An HMAC-Based One Time Password
Algorithm", RFC 4226, Algorithm", RFC 4226,
skipping to change at page 46, line 8 skipping to change at page 46, line 8
[XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.", [XMLENC] Eastlake, D., "XML Encryption Syntax and Processing.",
URL: http://www.w3.org/TR/xmlenc-core/, December 2002. URL: http://www.w3.org/TR/xmlenc-core/, December 2002.
[XMLSIG] Eastlake, D., "XML-Signature Syntax and Processing", [XMLSIG] Eastlake, D., "XML-Signature Syntax and Processing",
URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
W3C Recommendation, February 2002. W3C Recommendation, February 2002.
Authors' Addresses Authors' Addresses
Philip Hoyer Philip Hoyer
ActivIdenity, Inc. ActivIdentity, Inc.
109 Borough High Street 109 Borough High Street
London, SE1 1NL London, SE1 1NL
UK UK
Phone: +44 (0) 20 7744 6455 Phone: +44 (0) 20 7744 6455
Email: Philip.Hoyer@actividentity.com Email: Philip.Hoyer@actividentity.com
Mingliang Pei Mingliang Pei
VeriSign, Inc. VeriSign, Inc.
487 E. Middlefield Road 487 E. Middlefield Road
skipping to change at page 46, line 35 skipping to change at page 47, line 5
Salah Machani Salah Machani
Diversinet, Inc. Diversinet, Inc.
2225 Sheppard Avenue East 2225 Sheppard Avenue East
Suite 1801 Suite 1801
Toronto, Ontario M2J 5C2 Toronto, Ontario M2J 5C2
Canada Canada
Phone: +1 416 756 2324 Ext. 321 Phone: +1 416 756 2324 Ext. 321
Email: smachani@diversinet.com Email: smachani@diversinet.com
Shuh Chang
Gemalto Inc.
Email: shuh.chang@gemalto.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 279 change blocks. 
1067 lines changed or deleted 1019 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/