Secure Channel Key Diversification and Programming

Introduction

The term “key diversification” refers to the process of deriving a secure channel static transport key set from a Batch Master Key (BMK), the YubiKey identifier (part of serial number), and additional metadata.

Benefits and Usage

Key diversification enables simplified and secured distribution of secure channel transport key sets as only the Batch Master Key must be shared with the CMS system to derive the YubiKey transport key sets.

Hence, the secure channel transport key sets can be pre-programmed by Yubico, assuming that Yubico has access to the BMK of the CMS vendor.

Another option is for the CMS system to generate the secure channel transport key sets based on the YubiKey serial number, the BMK, and additional metadata. The CMS can then use the initial secure channel transport key set for writing additional secure channel transport key sets to the YubiKeys.

_images/SCP03-key-diversification.png

SCP03 Key Diversification

Secure Channel and Security Domains

The YubiKey supports up to 3 secure channel transport key sets. This is to enable more granular control over the establishment of a secure channel to a specific device. The keys in each of these key sets can be overwritten once connected to the YubiKey, allowing for a YubiKeys to be shipped with a default key set, then have the key set be changed to a random set of keys at initialization, ensuring only the CMS server has the actual keys.

Key Diversification Option

When purchasing YubiKeys from Yubico, there is an option to custom-configure the transport keys from the default to values derived from details specific to the hardware and a BMK. This means these keys can be distributed with locked down key sets, ensuring they cannot be connected to remotely by third parties. The BMK is generated and owned by the customer, who in turn can provide it to Yubico and their CMS deployment. The CMS can then use the BMK to establish a secure channel to a customer’s YubiKeys, and set new transport keys during initialization, limiting access to just that CMS. As with other custom configuration options, these keys can be overwritten or deleted by the customer; they are not “baked into” the YubiKey firmware.

Batch Master Key (BMK) Generation

Each custom order with diversified keys has a unique BMK used when Yubico programs them. A BMK is a 32-bit AES key - for more details on this function, see: https://www.yubico.com/wp-content/uploads/2015/04/YubiHSM-Manual_1_5_0.pdf, section 4.8.

Before every order with Key Diversification the customer will generate and provide the BMK to Yubico by secure means. After the YubiKeys have been programmed using the BMK provided, the BMK on the Yubico programming station is destroyed, leaving the customer with the only extant BMK. The customer must maintain and securely archive their BMK if required for future orders.

Key Diversification Function (KDF)

The diversification function used is the AES-CMAC-KDF Counter Mode derivation algorithm specified in NIST SP800-108.

Scroll horizontally to see the diversified key on the next line:

AES CMAC of [ Counter (1 byte) || Label (4 bytes) || 00 || Context (10 bytes) || Key Length in bits (2 Bytes) ]

Note

AES256 and 3DES keys require two rounds of KDF to generate a 32-byte key value and 24-byte key value respectively, the first one with a counter value set to 01 and the second one with a counter value set to 02.

The Key Length in the KDF input filed is expressed in hexadecimal value. It is:

  • 0100 for a 256-bit key,
  • 00C0 for a 192-bit Key (e.g. PIV Admin Key),
  • 0080 for a 128-bit key (e.g. ISD Keys & Interfaces Management Key) and
  • 0040 for a 64-bit code (e.g. the PUK).

Labels for Key Diversification

The KDF function of separating keys uses the following labels as input. Note that these are example values, keeping Yubikey 5 Series implementation with ISD Keys as 16-byte values, YubiKey Interfaces Management Key as a 16-byte value, , the PIV Admin Key as a 24-byte value and the PUK as an 8-byte value.

Factory Key Codes Key Length in bits KDF Label
Issuer Security Domain DAK (Authentication Key) ‘0080’ ‘00000001’
Issuer Security Domain DMK (MAC Key ) ‘0080’ ‘00000002’
Issuer Security Domain DEK (Encryption Key) ‘0080’ ‘00000003’
PIV Application Administrative Key ‘00C0’ ‘00000004’
PIV Application PUK ‘0040’ ‘00000007’
Capabilities Lock Code (YubiKey Interfaces Management Key) ‘0080’ ‘00000010’

In general the Key Length should be derived from the table below.

Key Size Key Length in Bits
32 Bytes ‘0100’
24 Bytes ‘00C0’
20 Bytes ‘00A0’
16 Bytes ‘0080’
8 Bytes ‘0040’

Context for Key Diversification

The value of the Context field in the KDF input data is the Issuer Context and is equal to the first 10 bytes of the value returned from the Global Platform INITIALIZE UPDATE command.

PUK Generation from Diversified Value

We use the trailing 8 bytes of the Diversified Value and generate the PUK using the pseudocode below. In the HTML version of this guide, you may need to scroll horizontally to see the full line.

for (int i = 0; i < 8; i++) { diversifiedVal[i] = (byte) (0x30 + ((diversifiedVal[i] & 0x7F) % 10));}

Global Platform: CPLC Data

Description

Although this format is officially deprecated and not part of the GlobalPlatform specification, some organizations need support for the information stored in the so-called CPLC (Card Production Life Cycle).

This consists of a static set of bytes can can be retrieved with a GET DATA command (INS 0xca) and TAG 0x9f7f after selecting the SD application.

The response is 42 bytes that can be parsed into different fields with different meanings. However, Yubico elected not to attribute any specific meaning to 40 of those bytes. Only the first two bytes are meaningful.

Example Command

To retrieve the value (scroll horizontally if necessary):

opensc-tool -c default -s '00a4040008a000000151000000' -s '00ca9f7f'

Relevant Output

40 90 73 F9 53 94 C0 01 23 D8 E9 F0 68 3A 48 9A @.s.S...#...h:H.
76 30 4C D8 F6 CC 41 66 61 0F C4 F5 8C DE D6 93 v0L...Afa.......
77 32 09 82 1B EA 0C 78 3D 8B                   w2.....x=.

Of those 42 bytes, only the first two (40 90) are meant to signify an Infineon SLE 78 chipset, the rest are random bytes generated when the SD application is (re)initialized.