Nothing Special   »   [go: up one dir, main page]

How To Build A Pin Block

Download as pdf or txt
Download as pdf or txt
You are on page 1of 2

PINBlock

When a cardholder enters his PIN into any PED [POS, ATM, etc.], we need to make sure that the PIN is safe and secure during its
journey from the acquirer to the issuer.

So the first step is to build a bock of data [Pin Block] which combines the PIN and the card PAN using one of the standards for building
such data.

one of the commonly used standards for encoding a PINBlock is ISO 9564-1 Format 0 [i.e. ANSI X9.8, VISA-1]. The ISO-0 PINBlock
format supports a PIN length of 4 to 12 digits.

How it works
Steps for calculating this type of encoding by example:

1. Format a 16-byte PIN as follows: [0] [Length] [PIN] [Padding]


where [0] indicates using ISO-0 format, [Length] is one byte Length, [PIN] is the provided PIN, and [Padding] is usually 'F'
So, for a PIN= '123456' the padded PIN should be:'06123456FFFFFFFF'

2. format a 16 byte PAN as follows: [0000][12 digit PAN]


get the 12 rightmost digits of the PAN [excluding the check digit] and left pad the result with zeros.
So, for a PAN= '5432101234567890' the padded PAN should be: '0000210123456789'

3. XOR the 2 values:


06123456FFFFFFFF XOR 0000210123456789 = [0612157DCBA9876]
This is the clear PIN block.

There are several other PINBlock formats out there, you may want to check out ISO 9564 for more details.

Ship PINBlock safe and secure to the acquirer


The Next step in our journey is to pass this PinBlock [using various methods of encryption] from acquirer to issuer, making a few stops
at the institutions [payment gateways] in between, and without being compromised.

To do this is simple, we need to encrypt the PINBlock with a key before being transmitted from the PED to the acquirer.

The not so simple part is how we are going to manage the encryption key so that it won't be compromised.

For that, acquirer needs to follow one of the common key management schemes, which are:

1- Master/Session
2- DUKPT

Master/Session

With master/session scheme, the acquirer generates a TMK [terminal master key] and a TPK [terminal PIN key] which is derived from
TMK (this is sometimes called session key or working key).

The steps for Master/Session process are as follows:


- TMK is injected into PED and hardly changed, while TPK is dynamically exchanged between PED and acquirer [where TPK is always
encrypted under TMK].

- When PED creates a PINBlock and want to send a transaction to the acquirer, the PED will first decrypt TPK under TMK to get the
clear TPK, then using the clear TPK, PED will encrypt PINBlock (usually using triple DES encryption algorithm).

- PINBlock is transmitted encrypted to the acquirer [making the first Stop in its journey].

- having TMK & TPK, the acquirer will be able to translate PINBlock.

DUKPT1

While master/session sounds good, yet a compromised TPK [session key] will compromise all subsequent transactions which use this
key.

In this case, the strength of DUKPT appears, The strength of DUKPT as an algorithm is its ability to generate unique keys for every
transaction, so if an encryption key [session key] is compromised, all subsequent transactions will be safe as it uses a different key.

The steps for DUKPT process are as follows:

- The algorithm starts with an initial single key or base derivation key BDK. BDK is saved inside Tamper-Resistant security module
or HSM at the acquirer side.
- Then a key is derived from the DBK along with the PED’s own unique Key Serial Number (KSN), this key will be known as initial
pin encryption key [IPEK].
- IPEK is injected into the PED.
- IPEK creates another set of keys [pool of future keys], then IPEK itself is discarded.
- At this point we have three levels of keys.
- DBK, the one and only [inside acquirer HSM].
- IPEK, one per device [initially injected to device then discarded after generating future keys].
- Future keys [session keys], up to 21 key generated from IPEK which will actually be used for encryption.
-
- - One of the future keys are used to encrypt the PINBlock [one can argue that this is currently the TPK or the session key] (usually
using triple DES encryption algorithm).
-
- - The process of encryption will also involve creating a key serial number [KSN] which is formed from PED unique id [terminal
ID] and PED transaction counter.
- PED then increment the transaction counter, discard the key just used, and generate more future keys.
- PINBlock is transmitted encrypted to the acquirer along with the new KSN [making the first Stop in its journey].
- having DBK & KSN, the acquirer will be able regenerate the IPEK and goes through a similar process as PED to regenerate the
session key.
- Finally, the acquirer will be able to translate PINBlock.

The first stop in our journey is now completed, our next and final article will talk about moving the PINBlock between institutions
[zones] all the way to the card issuer.

1 Derived Unique Key Per Transaction

You might also like