# Encryption

## Key derivation

<details><summary><b>Click</b> to show the explanation of the basics</summary>

`BDK` - Base derivation key

`iPEK` - Initial PIN encryption key. This is a terminal specific key, which is derived from the BDK using the iKSN

`KSN `- Key sequence number. It specifies how to derive a key from the BDK to get the correct session key. KSN is sent in each transaction where encryption was used.

`iKSN `- Initial KSN. A KSN used to derive the terminal specific key from the BDK. It is injected into the terminal together with the iPEK

`BDK-ID` - This ID is a unique identifier to find a BDK. It is a 6 hex-digit number which must be also contained as the first 6 hex-digits in the KSN For the US-format of the KSN it is a 10 hex-digit.

`Future-key` - Intermediate key derived from iPEK for a single transaction. From this key 5 more keys are derived:

  • PIN encryption key.

  • Data encryption key for request

  • Data encryption key for response

  • MAC key for request

  • MAC key for response

`BDK-1/2 `- The difference between BDK-1 and BDK-2 is:

  • When a BDK-1 is used, only 3 different keys are generated for a transaction. The Data encryption key for request is also used for the response. The MAC key for requet ist also used for the response.

  • When a BDK-2 is used, there are 5 different keys. The Data encryption key for request is different from the one for the response. The MAC key for request is different from the one for the response.

The Data encryption key for a request generated using a BDK-2 is equal to the Data encryption key for request and response, which was generated by a BDK-1. The MAC key for a request generated using a BDK-2 is equal to the MAC key for request and response, which was generated by a BDK-1.

`PIN-BDK / SRED-BDK / MAC-BDK` - It is possible to have only one single BDK and to derive all keys for one transaction from it, but in IPG normally three BDKs are used:

  • PIN-BDK is used to derive the key for the PIN encryption. This is normally a BDK-2 key.

  • SRED-BDK is used to derive the key for the data encryption. This is normally a BDK-2 key.

  • MAC-BDK is used to derive the key for MAC calculation. This can be either a BDK-1 or BDK-2 key.


The KSN is a 10 byte (80 bits) value. If AES is used, it is 12 byte long (except the legacy format is used).

There are three different formats:

  • `b` - BDK-ID In the international and German format the BDK-ID has a length of 24 bits. In the US format the BDK-ID has a length of 40 bits.

  • `s` - serial number Its size is 30 bits for the international, 24 bits for the German and 19 bits for the US format. It is a value which is normally unique for a terminal. It is not required that it is really the serial number of the terminal, but it should be a number which was generated especially for a terminal.

  • `L` - load counter Its size is 5 bits for international and 11 bits for the German format. It does not exist in the US format. It is used when a new key is generated and loaded into a terminal. It should ensure that the complete KSN is still growing from transaction to transaction, even so the transaction-counter ('t's) are reset to 0 when a new key is injected into the terminal.

  • `t` - transaction-counter Its size is always 21 bits. This value is incremented for every transaction.

For Giro-Cards it is important, that load-counter concatenated with the transaction-counter and interpreted as a single integer is incremented for every transaction when used for PIN encryption. If there is a transaction t1 and t2 and t2 was sent to IPG after t1, then unsigned-int(L...t of t1) \< unsigned-int(L...t of t2).

The KSN is the rule, how to derive a key from a given BDK.

When a new key must be injected into a terminal, the following will be done:

  1. The BDK-ID of the BDK to use is loaded.

  2. A serial-number for the terminal is generated/loaded.

  3. The load-counter for the terminal is loaded.

  4. Transaction-counter is set to 0

  5. The iKSN is build from the above values (BDK-ID, serial-number, load-counter and 0 for the load-counter)

  6. The iPEK is derived from the BDK using the iKSN.

  7. iPEK and iKSN are injected into the terminal. The above will be done for each BDK type (PIN-, SRED- and MAC-BDK).

When a terminal needs a key for a transaction. It selects the iPEK and iKSN for the specific purpose and does the following:

  1. Get iPEK and iKSN for the specific purpose (PIN- or data-encryption or MAC calculation).

  2. Set the current transaction counter in the iKSN (the last 21 bits) so it becomes the KSN for this transaction.

  3. Derive the required key(s) for the current transaction using the KSN (created in 2) and the iPEK.

  4. Use the key for encryption/MAC calculation.

  5. Send the transaction to IPG. The transaction must also contain the KSN from step (3).

When IPG gets the transaction it does the following:

  1. Pick the KSN from the transaction. There may be multiple KSNs included in the transaction depending on what was encrypted and whether a MAC is available.

  2. Get the BDK-ID from the KSN and find the corresponding BDK.

  3. Derive the required key from the BDK (in a first step the iPEK in a second step the key for the specific purpose).

  4. Use the key.

For initial sending of NEXO messages our NEXO interface accepts requests with plain card data. As mandated by DCPOS and NEXO, productive transaction have to support encryption. Fiserv supports DUKPT with 3DES and AES, whereas 3DES and AES should not be mixed for sred, mac and pin encryption.

3 BDKs will be shared with the terminal vendor:

  1. BDK Type 2 (PIN used to derive the key for PIN block encryption)

  2. BDK Type 2 (SRED, used to encrypt the card data )

  3. BDK Type 2 (MAC, used to generate the security trailer)

Each of the keys could be used for everything, but this is not wanted. When a BDK is deliverd, also the BDK-ID assigned to in within IPG is delivered. It is important that this BDK-ID is set in the iKSN and KSN which is used to derive session keys

IPG will have no direct connectivity to the POI. So neither terminal management nor Key injection to the terminals will be controlled by IPG. Key injection and synchronization with the terminals will be handled by a system (terminal concentrator) of the terminal vendor. For test environments Fiserv will share a set of keys directly with the Terminal concentrator. For production environment keys will loaded directly to the key exchange facility of the terminal vendor. The keys are need within the communication with our gateway (see security zone 2 in the below diagram).

## Example TDES

In the examples for TDES, the following clear-text BDKs are used:

BDK typeClear-text BDKKCVBDK-IDBDK-ID hex

Terminals used for the example:

Terminal IDSerial number

With the above values, we get the following iKSNs (German format):

BDK typeTerminal IDiKSN (hex)

The iPEKs for the different terminals and purposes are:

PurposeTerminal IDiPEKiKSN

## Protected Card Data in NEXO message

The data to encrypt must be the subtree starting with the tag <PlainCardData>. It is not required to contain every field. It is created as if the card data would be send unencrypted.

The following is the formatted sub-tree with the card related data:

Normally spaces and newlines are not sent, so this results in the following:

Next step is to get the UTF-8 bytestream for this text:

For TDES encryption, the data to encrypt must be padded. This is done by adding 0x80 and enough 0x00 to fill the last block (a block is 8 bytes in length for TDES):

To encrypt it on terminal T0001 we have to create the KSN to derive the session key: In this example the transaction counter in the terminal is 1, the resulting KSN is therefore 0003E900000100200001. It is the iKSN which belongs to the SRED iPEK of terminal T0001 and the transaction counter is set in the last 21 bits.

Now we can derive the key for data encryption from the iPEK: futureKey = 43E46555AADE72BFBABFE711BD1D809E reqDataKey = FE80268C0DE63E70B99157045B4926F1 The futureKey is just an intermediate key from which the keys for the different purposes are derived. In our case we are interested in the key to encrypt data in a request message.

The reqDataKey is a TDES key. The encryption algorithm we use is TDES with chained block mode and init-vector (0, ..., 0):

Now the encrypted data is base64 encoded:

Or simply as string: UuZSszJdg4yYAomsLkQiZ/kMpJuU8mybuGwBNrFoi7LM8o11186PQJ+oMQf4lHs+zglEzgkx4uTr0egDis7iMj+Pc58RVOJhS9fTOjMwCHd4L8nnZSNlpvq4iKRQLqQgOqMKoriq4Km87J+xb3FDEgYDOaRUUzG3P/kbSN8eFJJQMQ0Cz3rDFbf2ato9L/0Q0Z13Da5SsJzyGsHDlyk2q+OGIDVq7GDm

The final block to insert into the transaction contains:

The KSN, which was used. The KSN (0003E900000100200001) is splitted into two parts (each of them is 5 bytes in length). Each of the two parts are then base64 encoded: "AAPpAAA=", "AQAgAAE=" The encrypted data: "UuZSszJdg4yYAomsLkQiZ/kMpJuU8mybuGwBNrFoi7LM8o11186PQJ+oMQf4lHs+zglEzgkx4uTr0egDis7iMj+Pc58RVOJhS9fTOjMwCHd4L8nnZSNlpvq4iKRQLqQgOqMKoriq4Km87J+xb3FDEgYDOaRUUzG3P/kbSN8eFJJQMQ0Cz3rDFbf2ato9L/0Q0Z13Da5SsJzyGsHDlyk2q+OGIDVq7GDm" Some information which key derivation algorithm (DKP9) and which encryption algorithm was used (E3DC).

<details><summary><b>Click</b> to show the example</summary>


## PIN block encryption

The encryption of the PINBlock is optional - only used for online PIN transactions. Currently ISO-0 and ISO-1 PIN blocks are supported.

PIN-Block formatEncryption-MethodLength (in bytes)FormatDescription




## MAC'ing

Only body part (from <AuthstnReq> to </AuthstnReq>) needs to be mac'ed. The security trailer itself isn't part of it.

Key derivation algorithm:

DKP9DUKPT (Derived Unique Key Per Transaction) algorithm, as specified in ANSI X9.24-2009 Annex A.DUKPT (Derived Unique Key Per Transaction) key, as specified in ANSI X9.24-2009 Annex A.
DA12AESDUKPT128ECBAES DUKPT (Derived Unique Key Per Transaction) ECB algorithm, as specified in ANSI X9.24-3-2017 Annex A, With key length of 128 bits. Not supported yet: This value is only defined for higher version of NEXO Acquirer protocol (NEXO v7+). Because Fiserv currently only supports v6, this value cannot be set.

Algorithm to be used:

MCCSRetailSHA256MACRetail-CBC-MAC with SHA-256 (Secure Hash standard) - (ASN.1 Object Identifier: id-retail-cbc-mac-sha-256).
CMA1SHA256CMACwithAES128CMAC (Cipher based Message Authentication Code) defined by the National Institute of Standards and Technology (NIST 800-38B - May 2005), using the block cipher Advanced Encryption Standard with a 128 bits cryptographic key, approved by the Federal Information Processing Standards (FIPS 197 - November 6, 2001 - Advanced Encryption Standard). The CMAC algorithm is computed on the SHA-256 digest of the message.

NOTE: Each change in the AuthstnReq block, even adding line breaks or spaces, will lead to a change of the MAC.

<details><summary><b>Click</b> to show the example</summary>


Want a quick overview?