IBM Crypto and EMV - United States · Key Type 1 & Key Type 2: TOKEN – indicates the key...

© 2014 IBM Corporation

1

IBM Crypto and EMVKey Management

IBM Crypto Team

IBM Systems & Technology Group


2

EMV and CCA Key Management

IBM Crypto with ICSF provides a comprehensive set of key management functions.

We have the capability to create, generate, derive, import and export the keys that are needed for EMV online authorization processing.

The next few slides will cover how to use IBM Crypto to:

Create and share Key Encrypting Keys (KEKs)

Create Issuer Master Keys (IMKs)

Create Chip Card Master Keys (ICC MKs)

Create Session Keys

Create PIN Encrypting Keys

We'll cover how to use ICSF functions to create an iCVV

Finally, we have provided a REXX script which demonstrates these services.


3

EMV Online Payment Framework

Keys must be created and shared to complete the necessary operations.


4

Sharing a Key Encrypting Key The first key to be shared is a key encrypting key.

This key material will be shared between the Issuer and the Personalization system as a first step.

It will be used to share(EXPORT) the Issuer Master Keys (IMKs). To create the KEK for operational use in ICSF, a Trusted Key Entry (TKE) system is

needed.• Use the TKE to create a 16 byte TDES CCA EXPORTER key.• This key will be imported into ICSF using TSO panels as a NO-CV KEK.• This KEK can now be referenced by key label and used to export the Issuer Master

Keys when they are created. Keys wrapped by this KEK are in CCA tokens and can be sent to the personalization

system. On the personalization system, the encrypted Issuer Master Keys can be parsed from the

CCA key tokens starting at offset 16. The encrypted IMKs can be decrypted using the KEK that was shared earlier.

The next few charts cover creating an EXPORTER key with TKE and importing that key using ICSF.

Note: if desired, a second KEK can be created for use with the ICC MKs during the pre-personalization phase.


5

Use the TKE to create a 16 byte TDES CCA EXPORTER key

The Operational key –DES -> EXPORTER is one of the many key types that can be loaded from the TKE:

All TKE Operational key loading is done using the same basic process:

1. Generated key part material (All keys loaded from TKE require at least 2 parts)

NOTE: Methods exist for using known key material also.

2. Load the First and at least 1 Additional key part (Add part ... )

3. Complete the key after the last part is loaded


6

Use the TKE to create a 16 byte TDES CCA EXPORTER key, cont.

Overview information for the TKE can be provided if necessary. Resources:

YouTube channel: www.youtube.com/user/IBMTKE

TKE Workstation User’s Guide

Step 1: Generated key parts

If new parts are needed, use “generate” features to create them

If parts are known, skip this step

Step 2: Load key parts (First and Additional)

Process is straight forwards, once the source of the parts are known

If known parts are used, parts would likely be entered from the keyboard

If parts were generated, they will come from binary files or smart cards

Step 3: Complete the key

Process is simple and straight forward. You are putting the register in a state so ICSF can now use it.

A lot of factors influence the guidance. The TKE team would like to discuss situation with client so guidance is appropriate to the situation.


7

ICSF Operational KEK Import Process, part 1

From the ICSF main panel, select option 1.


8


On the Coprocessor Management panel, put a K by the coprocessor with the key.


9


The Operational Key Load panel will appear. On this panel select Control Vector – NO.


10

Issuer Master Keys: Online Auth. & Secure Messaging (Scripting)

Session Keys

Issuer MasterApplication

Cryptogram Key (AC)

Issuer MasterSecure Messaging

Authen. Key (MAC)

Issuer Master Secure

ConfidentialityKey (ENC)

IssuerBased

Derivation

IssuerBased

Derivation

IssuerBased

Derivation

Card Unique DataPAN and PAN Seq.

Unique ICCApplication

Cryptogram Key (AC)

ICCSecure MessagingAuthen. Key (MAC)

ICCSecure Messaging

Confidentiality Key (ENC)

Personalization

Issuer

IMKs


11

CCA Key Tokens

DES CCA Key Tokens are data structures which house key material and key material attributes. This is a high level view of the structure:

In CCA, a control vector is a non-secret quantity that expresses permissible usages for an associated key. When a CCA DES key is encrypted, the key-encrypting key is exclusive-ORed with the control vector to form the actual key used in the DES key-encrypting process. This technique allows the generator or introducer of a key to specify how the key is to be distributed and used.

A key type is encoded in the control vector.

The next chart shows the key types that are of interest for online EMV processing.

Token ID Version Flags Master Key Verification Pattern

Key Material Control vector

Token Validation Value


12

CCA Key Types and Attributes

Shared KEK – EXPORTER: Used to export keys

Issuer Master Key – DKYGENKY: Used to derive other keys

– CV Attribute DMAC – Can derive a MAC or DATAM keys

– CV Attribute DMPIN – Can derive SECMSG with SMPIN: secure messaging key for encrypting PINs.

ICC Master key – DKYGENKY: Used to derive other keys. Common to DKYGENKY Keys:

– CV Attribute DKYL1 – Can derive other key generating keys– CV Attribute DKYL0 – Can derive operational keys (i.e. MAC, SECMSG)

Session keys – Used for application cryptogram generation, issuer authentication, and secure messaging.

MAC: Used to generate or authenticate a MAC. SECMSG with SMPIN: Used to encrypt a message that will contain a PIN. Application Cryptogram(AC) keys have a CCA MAC key type. Secure Messaging with Integrity/Authentication keys have a CCA MAC key type. Secure Messaging with Confidentiality keys have a CCA SECMSG key type with

SMPIN attribute.


13

Creating the Issuer Master AC Key Two verbs must be called – Key Token Build and Key Generate:

Use the CSNBKTB (Key Token Build) callable service to create two skeleton tokens which will be populated with the key material. The verb will be called twice.

• Operational Key (used on the local system) specify: A buffer to hold the assembled skeleton token

Key Type – DKYGENKY

Rule Array Keywords: INTERNAL, DES, DOUBLE, DKYL1*, DMAC**

• Key to be Exported specify: A buffer to hold the assembled skeleton token


Rule Array Keywords: EXTERNAL, DES, DOUBLE, DKYL1, DMAC

Use the CSNBKGN callable service to populate the key tokens with key material.

*DKYL1 indicates that this key is derivation level 1 and will be used to derive another key generating key. **DMAC indicates the key can be used to derive a MAC key.


14

Creating the Issuer Master AC Key, cont. This is the input for the CSNBKGN (Key Generate) callable service:

Key Form: OPEX - A key pair; one key that is operational and one key to be sent from this system. Both keys have the same clear value.

Key Length: DOUBLE

Key Type 1 & Key Type 2: TOKEN – indicates the key characteristics are defined in the skeleton.

KEK_identifier 1: Initialize to binary zeros.

KEK_identifier 2: Set to the label of the shared KEK that was created earlier.

Generated key identifier1 - this field contains a valid DES skeleton token of the key type you want to generate. (Operational key skeleton created earlier).

Generated key identifier2 - this field contains a valid DES skeleton token of the key type you want to generate. (External key skeleton created earlier which will be shared).

After calling the service the skeleton tokens will be populated by the HSM with random key material which is encrypted by the CCA master key and the shared KEK.


15

Creating the Issuer Master AC Key, cont. Write the IMK to the CKDS

– Call the CSNBKRC ( Key Record Create) callable service to add a key record label to the CKDS that will be used to store the DES token in the generated key identifier1 parameter.

– Call the CSNBKRW (Key Record Write) callable service to write the internal DES key token to the CKDS record specified by the key_label parameter.

Share the External Key from the previous step with the Personalization System.


16

Creating Other Issuer Master Keys To create other IMKs, modify the inputs to the key token build callable service to

create skeletons with the desired characteristics.

Use the CSNBKTB (Key Token Build) callable service inputs to create an Issuer Secure Messaging key which will be used to create an ICC MK used for deriving secure messaging encryption keys. The verb will be called twice.

• Operational Key specify: A buffer to hold the assembled skeleton token


Rule Array Keywords: INTERNAL, DES, DOUBLE, DKYL1, DMPIN

• Key to be Exported specify: A buffer to hold the assembled skeleton token


Rule Array Keywords: EXTERNAL, DES, DOUBLE, DKYL1, DMPIN

Use the CSNBKGN callable service to populate the key tokens with key material.


17

Creating ICC Master Keys

ICC Master Keys are derived from the Issuer Master Key.

Creating these keys requires the use of the Key Token Build callable service and the Diversified Key Generate callable service.

• First, call Key Token Build to create a skeleton token for the ICC Master Key you wish to create.

• Let's start with the Unique ICC Application Cryptogram Master Key

• For the operational key to be used on the local system specify: A buffer to hold the assembled skeleton token


Rule Array Keywords: INTERNAL, DES, DOUBLE, DKYL0*, DMAC**

*DKYL0 indicates that this key is derivation level 0 and will be used to derive an operational key.

**DMAC indicates the key can be used to derive a MAC key.


18

Creating the ICC Master Keys, cont.

Next call the CSNBDKG (Diversified Key Generate) callable service specifying the following: Rule Array Keyword: TDES-ENC. This indicates how to process the derivation data.

Generating Key Identifier: This is the operational Issuer AC Master Key created earlier.

Generated Key Identifier: Skeleton token from the previous step. On output, this field will contain the ICC Master Key.

Data: This is the derivation data. This data must be prepared as described in EMV 4.3 Book 2 Annex A1.4 Master key derivation. Here is a summary of the 2 options:

• Application PAN <=16 decimal digits: First 8 bytes of data Y = PAN||PAN Seq. No. w/padding on left if needed.

Second 8 bytes of data = First 8 bytes bitwise inverted (Y ⊕ ('FF'||'FF'||'FF'...)

These 16 bytes are passed in the Data parameter to the HSM.

• Application PAN > 16 decimal digits:

SHA1(PAN||PAN Seq. No. w/padding on left as needed)

Scan for decimal digits and apply decimalization table if needed.

These 16 digits are passed in the Data parameter to the HSM.


19

Creating Other ICC Master Keys, cont.

To create other ICC MKs, modify the inputs to the Key Token Build callable service to create skeletons with the desired characteristics.

Use the CSNBKTB (Key Token Build) callable service inputs to create an ICC secure messaging key which will be used to create a secure messaging key which encrypts a message containing a PIN. For the operational key to be used on the local system specify:

A buffer to hold the assembled skeleton token


Rule Array Keywords: INTERNAL, DES, DOUBLE, DKYL0*, DMPIN

*DKYL0 indicates that this key is derivation level 0 and will be used to derive an operational key.


20

Creating the ICC Master Keys, cont. As indicated before, next call the CSNBDKG (Diversified Key Generate) callable

service specifying the following: Rule Array Keyword: TDES-ENC. This indicates how to process the derivation data.

Generating Key Identifier: This is the operational Issuer AC Master Key created earlier

Generated Key Identifier: Skeleton token from the previous step. On output, this field will contain the ICC Master Key.

Data: This is the derivation data. This data must be prepared as described in EMV 4.3 Book 2 Annex A1.4 Master key derivation. Here is a summary of the 2 options:

• Application PAN <=16 decimal digits: First 8 bytes of data Y = PAN||PAN Seq. No. w/padding on left if needed.

Second 8 bytes of data = First 8 bytes bitwise inverted (Y ⊕ ('FF'||'FF'||'FF'...)

These 16 bytes are passed in the Data parameter to the HSM.

• Application PAN > 16 decimal digits:

SHA1(PAN||PAN Seq. No. w/padding on left as needed)

Scan for decimal digits and apply decimalization table if needed.

These 16 digits are passed in the Data parameter to the HSM.


21

Creating Session Keys Session keys are used to generate and verify the Application Cryptogram and

ARPC as well as for secure messaging.

The common session key derivation option generates a unique session key for each transaction performed by the application. It does this by enciphering an n-byte diversification value with the k-bit ICC Master Key (MK) to produce a k-bit ICC Session Key (SK) using an n-byte block cipher algorithm ALG in ECB mode. Creating these keys requires the use of the Key Token Build callable service and the

Diversified Key Generate callable service.

• First, call Key Token Build to create a skeleton token for the ICC Session Key you wish to create.

• Let's start with the session key used to generate and verify the Application Cryptogram and ARPC.


Key Type – MAC (In CCA, MAC keys can generate and verify MACs)

Rule Array Keywords: INTERNAL, DES, DOUBLE


22

Creating Session Keys, cont. Next call the CSNBDKG (Diversified Key Generate) callable service specifying the

following: Rule Array Keyword: TDES-ENC. This indicates how to process the derivation data.

Generating Key Identifier: This is the operational ICC AC Master Key created earlier

Generated Key Identifier: Skeleton token from the previous step. On output, this field will contain the CCA operational MAC key that can be used with transaction data.

Data: This is the derivation data. This data must be prepared as described in EMV 4.3 Book 2 Annex A1.3.1 Common Session Key Derivation Option. Here is a summary of how to format the derivation data for the session key used to generate and verify the Application Cryptogram and the ARPC:

Start by creating R which is the ATC followed by n-2 bytes of '00' where n is the cipher block size. For ALG= TDES, n is 8 and k-bits = 128.

Use R to create 2 n-byte blocks:

F1 = R0 || R1 || 'F0' || … || Rn-1.

F2 = R0 || R1 || '0F' || … || Rn-1.

These values will be encrypted with the ICC MK using TDES to recreate the the session key. SK := Leftmost k-bits of {ALG (MK) [F1] || ALG (MK) [F2] }

Pass F1||F2 in the Data parameter so the HSM can perform the encryption and return the key.


23

Creating Other Session Keys The processing for creating session keys used for secure messaging is similar. Creating these keys requires the use of the Key Token Build callable service and the

Diversified Key Generate callable service. Let's create a secure messaging session key used to encrypt data which includes a

PIN. This key has a key type in CCA of SECMSG. Usage bits can be specified in

CSNBKTB using rule array keywords.

Specify SMPIN for a key that will be used to encrypt data which includes a PIN.

Call Key Token Build to create a skeleton token for the ICC Session Key you wish to create.


Key Type – SECMSG

Rule Array Keywords: INTERNAL, DES, DOUBLE, SMPIN


24

Creating Other Session Keys, cont. Next call the CSNBDKG (Diversified Key Generate) callable service specifying the

following: Rule Array Keyword: TDES-ENC. This indicates how to process the derivation data. Generating Key Identifier: This is the operational ICC PIN or ENC Master Key created

earlier. Generated Key Identifier: Skeleton token from the previous step. On output, this field will

contain the CCA SECMSG key that can be used for encrypting data with PINs or Keys. Data: This is the derivation data. This data must be prepared as described in EMV 4.3

Book 2 Annex A1.3.1 Common Session Key Derivation Option. Here is a summary of how to format the derivation data for the session key used for secure messaging.

Start by creating R which is the Application Cryptogram returned in the response to the first GENERATE AC command followed by n-8 bytes of '00' where n is the cipher block size. For ALG= TDES, n is 8 and k-bits = 128.

Use R to create 2 n-byte blocks:

F1 = R0 || R1 || 'F0' || … || Rn-1.

F2 = R0 || R1 || '0F' || … || Rn-1.

These values will be encrypted with the ICC MK using TDES to recreate the session key. SK := Leftmost k-bits of {ALG (MK) [F1] || ALG (MK) [F2] }

Pass F1||F2 in the Data parameter so the HSM can perform the encryption and return the operational key.


25

The pre-Personalization Key Creation Process

Creating the UDK (Unique ICC Derived Master Keys) can be done using techniques similar to those described earlier. Step one is to establish a shared secret key which will be used as the key encrypting

key(KEK) using the TKE.

Next create the ICC Master Key in two forms.

• Use the steps described earlier to derive the ICC Master Key.

• Use the Key Export callable service to export the key under the shared KEK from the first step. This places the key token in external form.

• Use the Key Test Extended callable service to generate a key verification pattern. Specify the external key for which the pattern is to be generated.

Specify the shared KEK

Specify these rule array keywords: GENERATE, KEY-ENCD, ENC-ZERO

Generate a pattern for a double length key by encrypting a binary zero field.


26

The pre-Personalization Key Creation Process, cont.

Send the external key token and the verification pattern to the personalization system.

On the personalization system,

Parse the encrypted key material starting at offset 16 of the token.

Note: The key is 16 bytes long.

Decrypt the key material using the shared key encrypting key.

The clear key can be used to re-compute the “encrypt zeros*” verification pattern and a comparison with the verification pattern send along with the key can be made.

*The encrypt zeros method encrypts 8 bytes of binary zeros for TDES.


27

Creating PIN Encryption Keys

In CCA, PIN blocks are encrypted using keys with the key type – OPINENC. OPINENC stands for outbound PIN encrypting key.

This key is used for encrypting a PIN block to be send out of the system.

An OPINENC key is created in a pair with an IPINENC.

IPINENC stands for inbound PIN encrypting key.

This key is used for decrypting a PIN block to be brought into the system.

To create these keys, you will need the Key Generate callable service which will create the key token populated with key material.

You will create two keys. One will have an IPINENC key type and one will have an OPINENC key type.

Both keys have the same clear key value but the key type will enforce usage control.


28

Creating PIN Encrypting Keys, cont. This is the input for the CSNBKGN (Key Generate) callable service:

Key Form: OPEX* - A key pair; one key that is operational and one key to be sent from this system. Both keys have the same clear value.

Key Length: DOUBLE Key Type 1: OPINENC – indicates the key will be used to encrypt an outbound PIN

block.

Key Type 2: IPINENC – indicates the key will be used to decrypt an inbound PIN block.

KEK_identifier 1: Initialize to binary zeros.

KEK_identifier 2: Set to the label of a shared KEK that was loaded via TKE.

Generated key identifier1 – Set this field to a CCA null token (null token - 64 bytes of X'00'). On output it will contain the operational key.

Generated key identifier2 - Set field contains to a CCA null token (null token - 64 bytes of X'00'). On output it will contain the key wrapped by the KEK which can be shared.

* Please see the next chart for the valid Key Form options when creating PIN encrypting keys.


29

Creating PIN Encrypting Keys, cont.

The key form you select is determined by whether you want the key wrapped by a shared key encryption key or by the CCA master key for use on the current system. Keys for use on the current system are INTERNAL. Keys wrapped under a shared key encrypting key are EXTERNAL.

These are the key form options that are available when creating a PIN encrypting key pair with the CSNBKGN (Key Generate) callable service: – OPEX: Returns two enciphered copies of the random key,one ready for immediate use

at the local node, and the other for distribution to a remote node.

– EXEX: Returns two enciphered copies of the random key, both for distribution to a remote node.

– IMEX: Returns two enciphered copies of the random key, one to be imported later to the local node, and the other for distribution to a remote node.

After performing the key generation step, two copies of the key are available for use.


30

Creating an iCVV using CCA

The iCVV – Card Verification Value for Integrated Circuit Cards is an alternative method for creating a card verification value defined for storage on a Visa EMV chip card.

This method uses “999” instead of the service code on the magnetic stripe image for the iCVV calculation.

The Visa CVV Generate Callable Service can be used to calculate the iCVV. Specify Rule Array Keyword for the PAN length and CVV length.

Specify the PAN Data.

Specify the Expiration Date.

Specify a Service Code with a value of “999”.

Specify a CCA key which has key type DATA or MAC.

Specify a buffer to hold the calculated value.


31

Creating an iCVV using CCA

The iCVV – Card Verification Value for Integrated Circuit Cards is an alternative method for creating a card verification value defined for storage on a Visa EMV chip card.

This method uses “999” instead of the service code on the magnetic stripe image for the iCVV calculation.

The Visa CVV Generate Callable Service can be used to calculate the iCVV. Specify Rule Array Keyword for the PAN length and CVV length.

Specify the PAN Data.

Specify the Expiration Date.

Specify a Service Code with a value of “999”.

Specify a CCA key which has key type DATA or MAC.

Specify a buffer to hold the calculated value.


32

Supporting Material

The provided REXX file contains these samples for EMV processing: Create & Store Issuer Master Keys (IMKs) for AC, MAC and ENC Generate ICC Master Keys from AC, MAC and ENC Issuer Mks Generate Session Keys from ICC Master Keys Export ICC Master Keys

Additional Samples included: Create & Store Pin Encrypting Keys Create an iCVV

IBM Crypto and EMV - United States · Key Type 1 & Key Type 2: TOKEN – indicates the key...

Documents

Transcript of IBM Crypto and EMV - United States · Key Type 1 & Key Type 2: TOKEN – indicates the key...