Encryption

Key derivation

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:

         1         2         3         4         5         6         7         8
12345678901234567890123456789012345678901234567890123456789012345678901234567890
bbbbbbbbbbbbbbbbbbbbbbbbssssssssssssssssssssssssssssssLLLLLttttttttttttttttttttt international
bbbbbbbbbbbbbbbbbbbbbbbbssssssssssssssssssssssssLLLLLLLLLLLttttttttttttttttttttt German
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbsssssssssssssssssssttttttttttttttttttttt US

• 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 the Gateway. The transaction must also contain the KSN from step (3).

When the Gateway receives 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.
The Gateway 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

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

Example TDES

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

Terminals used for the example:

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

The iPEKs for the different terminals and purposes are:

Protected Card Data in NEXO message

The data to encrypt must be the subtree starting with the tag . 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:

<PlainCardData>
	<PAN>4035874000424977</PAN>
	<CardSeqNb>0</CardSeqNb>
	<XpryDt>2022-12</XpryDt>
	<SvcCd>000</SvcCd>
	<Trck2>417666XXXXXX551=2212</Trck2>
</PlainCardData>

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

<PlainCardData><PAN>4035874000424977</PAN><CardSeqNb>000</CardSeqNb><XpryDt>2019-12-31</XpryDt><Trck2>4035874000424977=19122060000097700977</Trck2></PlainCardData>

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

0000: 3C 50 6C 61 69 6E 43 61 | 72 64 44 61 74 61 3E 3C <PlainCardData><
0010: 50 41 4E 3E 34 30 33 35 | 38 37 34 30 30 30 34 32 PAN>403587400042
0020: 34 39 37 37 3C 2F 50 41 | 4E 3E 3C 43 61 72 64 53 4977</PAN><CardS
0030: 65 71 4E 62 3E 30 30 30 | 3C 2F 43 61 72 64 53 65 eqNb>000</CardSe
0040: 71 4E 62 3E 3C 58 70 72 | 79 44 74 3E 32 30 31 39 qNb><XpryDt>2019
0050: 2D 31 32 2D 33 31 3C 2F | 58 70 72 79 44 74 3E 3C -12-31</XpryDt><
0060: 54 72 63 6B 32 3E 34 30 | 33 35 38 37 34 30 30 30 Trck2>4035874000
0070: 34 32 34 39 37 37 3D 31 | 39 31 32 32 30 36 30 30 424977=191220600
0080: 30 30 30 39 37 37 30 30 | 39 37 37 3C 2F 54 72 63 00097700977</Trc
0090: 6B 32 3E 3C 2F 50 6C 61 | 69 6E 43 61 72 64 44 61 k2></PlainCardDa
00a0: 74 61 3E                                          ta>

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):

0000: 3C 50 6C 61 69 6E 43 61 | 72 64 44 61 74 61 3E 3C <PlainCardData><
0010: 50 41 4E 3E 34 30 33 35 | 38 37 34 30 30 30 34 32 PAN>403587400042
0020: 34 39 37 37 3C 2F 50 41 | 4E 3E 3C 43 61 72 64 53 4977</PAN><CardS
0030: 65 71 4E 62 3E 30 30 30 | 3C 2F 43 61 72 64 53 65 eqNb>000</CardSe
0040: 71 4E 62 3E 3C 58 70 72 | 79 44 74 3E 32 30 31 39 qNb><XpryDt>2019
0050: 2D 31 32 2D 33 31 3C 2F | 58 70 72 79 44 74 3E 3C -12-31</XpryDt><
0060: 54 72 63 6B 32 3E 34 30 | 33 35 38 37 34 30 30 30 Trck2>4035874000
0070: 34 32 34 39 37 37 3D 31 | 39 31 32 32 30 36 30 30 424977=191220600
0080: 30 30 30 39 37 37 30 30 | 39 37 37 3C 2F 54 72 63 00097700977</Trc
0090: 6B 32 3E 3C 2F 50 6C 61 | 69 6E 43 61 72 64 44 61 k2></PlainCardDa
00a0: 74 61 3E 80 00 00 00 00 |                         ta>.....

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):

0000: 52 E6 52 B3 32 5D 83 8C | 98 02 89 AC 2E 44 22 67 R.R.2].......D"g
0010: F9 0C A4 9B 94 F2 6C 9B | B8 6C 01 36 B1 68 8B B2 ......l..l.6.h..
0020: CC F2 8D 75 D7 CE 8F 40 | 9F A8 31 07 F8 94 7B 3E [email protected]...{>
0030: CE 09 44 CE 09 31 E2 E4 | EB D1 E8 03 8A CE E2 32 ..D..1.........2
0040: 3F 8F 73 9F 11 54 E2 61 | 4B D7 D3 3A 33 30 08 77 ?.s..T.aK..:30.w
0050: 78 2F C9 E7 65 23 65 A6 | FA B8 88 A4 50 2E A4 20 x/..e#e.....P..
0060: 3A A3 0A A2 B8 AA E0 A9 | BC EC 9F B1 6F 71 43 12 :...........oqC.
0070: 06 03 39 A4 54 53 31 B7 | 3F F9 1B 48 DF 1E 14 92 ..9.TS1.?..H....
0080: 50 31 0D 02 CF 7A C3 15 | B7 F6 6A DA 3D 2F FD 10 P1...z....j.=/..
0090: D1 9D 77 0D AE 52 B0 9C | F2 1A C1 C3 97 29 36 AB ..w..R.......)6.
00a0: E3 86 20 35 6A EC 60 E6 |                         .. 5j.`.

Now the encrypted data is base64 encoded:

0000: 55 75 5A 53 73 7A 4A 64 | 67 34 79 59 41 6F 6D 73 UuZSszJdg4yYAoms
0010: 4C 6B 51 69 5A 2F 6B 4D | 70 4A 75 55 38 6D 79 62 LkQiZ/kMpJuU8myb
0020: 75 47 77 42 4E 72 46 6F | 69 37 4C 4D 38 6F 31 31 uGwBNrFoi7LM8o11
0030: 31 38 36 50 51 4A 2B 6F | 4D 51 66 34 6C 48 73 2B 186PQJ+oMQf4lHs+
0040: 7A 67 6C 45 7A 67 6B 78 | 34 75 54 72 30 65 67 44 zglEzgkx4uTr0egD
0050: 69 73 37 69 4D 6A 2B 50 | 63 35 38 52 56 4F 4A 68 is7iMj+Pc58RVOJh
0060: 53 39 66 54 4F 6A 4D 77 | 43 48 64 34 4C 38 6E 6E S9fTOjMwCHd4L8nn
0070: 5A 53 4E 6C 70 76 71 34 | 69 4B 52 51 4C 71 51 67 ZSNlpvq4iKRQLqQg
0080: 4F 71 4D 4B 6F 72 69 71 | 34 4B 6D 38 37 4A 2B 78 OqMKoriq4Km87J+x
0090: 62 33 46 44 45 67 59 44 | 4F 61 52 55 55 7A 47 33 b3FDEgYDOaRUUzG3
00a0: 50 2F 6B 62 53 4E 38 65 | 46 4A 4A 51 4D 51 30 43 P/kbSN8eFJJQMQ0C
00b0: 7A 33 72 44 46 62 66 32 | 61 74 6F 39 4C 2F 30 51 z3rDFbf2ato9L/0Q
00c0: 30 5A 31 33 44 61 35 53 | 73 4A 7A 79 47 73 48 44 0Z13Da5SsJzyGsHD
00d0: 6C 79 6B 32 71 2B 4F 47 | 49 44 56 71 37 47 44 6D lyk2q+OGIDVq7GDm

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).

<PrtctdCardData>
    <CnttTp>EVLP</CnttTp>
    <EnvlpdData>
        <Rcpt>
            <KEK>
                <KEKId>
                    <KeyId>TestKey</KeyId>
                    <KeyVrsn>20160920</KeyVrsn>
                    <DerivtnId>AAPpAAA=</DerivtnId>
                </KEKId>
                <KeyNcrptnAlgo>
                    <Algo>DKP9</Algo>
                </KeyNcrptnAlgo>
                <NcrptdKey>AQAgAAE=</NcrptdKey>
            </KEK>
        </Rcpt>
        <NcrptdCntt>
            <CnttTp>DATA</CnttTp>
            <CnttNcrptnAlgo>
                <Algo>E3DC</Algo>
            </CnttNcrptnAlgo>
            <NcrptdData>UuZSszJdg4yYAomsLkQiZ/kMpJuU8mybuGwBNrFoi7LM8o11186PQJ+oMQf4lHs+zglEzgkx4uTr0egDis7iMj+Pc58RVOJhS9fTOjMwCHd4L8nnZSNlpvq4iKRQLqQgOqMKoriq4Km87J+xb3FDEgYDOaRUUzG3P/kbSN8eFJJQMQ0Cz3rDFbf2ato9L/0Q0Z13Da5SsJzyGsHDlyk2q+OGIDVq7GDm</NcrptdData>
        </NcrptdCntt>
    </EnvlpdData>
</PrtctdCardData>

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.

MAC'ing (or "make use of Message Authentication Code

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

Key derivation algorithm:

Algorithm to be used:

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

<SctyTrlr>
 <CnttTp>AUTH</CnttTp>
	<AuthntcdData>
	<Rcpt>
		<KEK>
			<KEKId>
				<KeyId>XXMacTestKey</KeyId>
				<KeyVrsn>2016051911</KeyVrsn>
				<DerivtnId>EAM3AAA=</DerivtnId>
			</KEKId>
			<KeyNcrptnAlgo>
				<Algo>DKP9</Algo>
			</KeyNcrptnAlgo>
			<NcrptdKey>AJMADMQ=</NcrptdKey>
		</KEK>
	</Rcpt>
	<MACAlgo>
		<Algo>MCCS</Algo>
	</MACAlgo>
	<NcpsltdCntt>
	<CnttTp>DATA</CnttTp>
	</NcpsltdCntt>
	<MAC>mLLVSIBLmwE=</MAC>
	</AuthntcdData>
</SctyTrlr>