How to decrypt magnetic track data using DUKPT
I offer the readers of "Habrakhabr" a translation of the article "How To Decrypt Magnetic Card Data With DUKPT" .
Recently, I needed to decipher card data from a magnetic track reader. It would seem simple. I take the key and perform a specific decryption algorithm. But it was not there.
It turned out that my readers use a scheme known as DUKPT (Derived Unique Key Per Transaction - Definition of Unique Key On Transaction). The idea of this scheme is that for each transaction (or in our case for each card rental) the data is encrypted using the key calculated for the individual card rental.
')
Thus, in order to decrypt data that has been encrypted using this scheme, you must be able to calculate the key for a separate card rental. The process of calculating such a key (session key) is far from simple.
The process is described in ANSI X9.24 part 1. However, the document costs about $ 140. Free, easy-to-access documentation describing this process is difficult to find. The best resource I managed to find is here ; There is a pretty good explanation of how IPEK is calculated (Initial Pin Encryption Key - the initial key for calculating keys). Unfortunately, this is only part of the complete scheme. In this post I will try to fully explain the DUKPT scheme.
BDK : This is an abbreviation for Base Derivation Key. This key is known only to the manufacturer and developer of software that interacts with a magnetic track scanner.
IPEK : This is short for Initial Pin Encryption Key. This key is determined from the BDK. This key is downloaded to the device by the manufacturer and used to generate future keys. Compromising IPEK does not compromise BDK.
KSN : This is short for Key Serial Number. KSN is a combination of the serial number of the magnetic track scanner and the card rental quantity counter, which was performed on the device.
The BDK is used by the manufacturer to generate IPEK, which is downloaded to the device during development. The device uses IPEK and KSN to calculate the session key that encrypts data readable from the card.
BDK is required by software developers to calculate IPEK. After receiving IPEK, they can request KSN from the device. IPEK and KSN are used to obtain the key for a separate transaction / rental card. Having these keys, developers can decipher card data.
To get the initial key to calculate the keys (IPEK), we need the basic key of the algorithm (BDK) and the serial number of the key (KSN). IPEK is determined using the TripleDES algorithm. TripleDES is a simple DES algorithm that runs in three passes.
The algorithm uses a key length of 24 bytes. The DES algorithm is used three times, first with a key of 1-8 bytes, then 9-16 bytes and, finally, 17-24 bytes separately for each pass.
TripleDES can use a key length of 16 bytes, this method is called EDE3. Bytes 1-8 will be used first, then 9-16 and, again, 1-8 emitting a 24-byte key.
Some implementations of TripleDES may not automatically use the short key. Before you understand it, I spent a lot of time trying to figure out what the problem was. Assuming that this is a special implementation of TripleDES, I used an emitted 24 byte key of 16 bytes.
After much anguish, it descended on me to try to take the first 8 bytes and add them to the end of the key before transferring it to the TripleDES algorithm. This solved the problem.
IPEK consists of two 8-byte parts, which are obtained as a result of two separate passes of the TripleDES algorithm. Both are obtained by encrypting the higher 8 bytes of KSN with a zero counter. The difference between the left and right sides is that the right side is obtained by encrypting KSN using a slightly modified version of the BDK. I will describe this process below.
Suppose there is a 16-byte BDK represented by the hexadecimal string "0123456789ABCDEFFEDCBA9876543210". We also have a 10 byte KSN with a counter equal to 8, represented by the hexadecimal string "FFFF9876543210E00008".
Get the BDK to encrypt the left side of the IPEK by adding the first 8 bytes to the end of the BDK, this will be the next 24 byte key.
If the length of KSN is not equal to 10 bytes, then we supplement it with 10 bytes of hexadecimal "F" (1111). It is important to note that IPEK is the very first key on the device. This means that we calculate it with a counter in KSN equal to 0. To get a KSN with counter 0, we superimpose a mask on it in hexadecimal representation of which is the string "FFFFFFFFFFFFFFE00000".
Wonderful. Now we have zero KSN. However, we need the upper 8 bytes of KSN. We get them by moving the KSN to the right by 16 bits.
Fine. The next step is TripleDES encryption of the string “FFFF9876543210E0” with the BDK key of 24 bytes “0123456789ABCDEFFEDCBA98765432100123456789ABCDEF”. The result of this encryption will be the left side of the IPEK.
If you remember, I mentioned that a slightly modified version of the BDK will be used to get the right part. Thus, to do this, we need to take the original 16 byte BDK "0123456789ABCDEFFEDCBA9876543210" and perform the XOR using the following mask "C0C0C0C000000000C0C0C0C000000000". It looks like a completely arbitrary mask, but alas, it is necessary to get the right IPEK.
We will do the same thing that we did with the key for the left side, take the upper 8 bytes and add them to the end, we get the next 24 byte key.
Next, take the upper 8 bytes of KSN with a zero counter (which we calculated earlier) and encrypt it with the help of TripleDES with the key that we just calculated. This will give us the right IPEK register, we get the next 16 byte IPEK (I separated the left and right parts for clarity).
We have IPEK. Next, we need to get from IPEK a unique key for a separate rental card (session key). To get it, a certain subroutine is used, let's call it a black box, the purpose of which is to return a separate session key. What is happening in the black box is not our concern yet. Right now we will look at the input of this subroutine.
Our black box has two entrances. One is the key and the second is the string to encrypt. The string is a modified KSN.
If you remember, the lower 21 bits of KSN contain a count of the number of card rentals on the device. We will transfer the modified KSN to the subroutine as many times as the units in the binary representation of the counter. The key that is transmitted with the modified KSN is IPEK at the first iteration, and at the next iterations it will be the key obtained from the black box at the previous iteration.
Let's start by changing the KSN. To begin, we will take the lower 8 bytes of KSN and reset the counter value in KSN. This can be done by masking the KSN using the following mask.
We will use the resulting value to calculate each message sent to the black box. In our example with a counter equal to 8, we must transfer to the black box the binary representation of the number 8 (1000). For demonstration, assume that the counter has a more complex value of 10 (1010).
We will extract a set of binary numbers from the counter. In our case, for the number 10 (1010) there will be two binary numbers: 1000 and 0010. Have you caught the scheme? We get a set of numbers representing each binary unit of the number 10.
Next, we take the first number and apply the OR operation with KSN, which has the counter reset to zero, as shown earlier (note that the hexadecimal representation of the first number will be 0008).
Now we transfer IPEK as a key and just modified KSN to a black box. The black box will return the new key. This is the first session key (presented in hexadecimal): "27f66d5244ff62e1aa6f6120edeb4280".
Next, repeat the process with the following binary number, calculated earlier, 2 (0010). This time, we will use the first session key, which we have just received and we will calculate the new modification of KSN.
To calculate the new KSN modification, we will perform the OR operation with the latest modification obtained: 9876543210E00008.
Now we will transfer our new key “27f66d5244ff62e1aa6f6120edeb4280” and the new modification KSN “9876543210E0000A” to the black box and get another future key, “6cf2500a22507c7cc776ceadc1e33014”. This is the session key for our device with a counter of 10.
However, our real counter was 8, and we calculated the real session key “27F66D5244FF62E1AA6F6120EDEB4280” at the first stage.
The last operation we have to do with the obtained value is the final transformation of the key, with which we will decrypt the data. We must perform the XOR key with the mask "00000000000000FF00000000000000FF".
This is the key that is required to decrypt the data.
I called the black box an algorithm that calculates session keys. The black box accepts the current session key, which I denote current_sk , and the KSN modification, denoted ksn_mod .
If at the beginning the assumption that IPEK obtained above was transmitted as current_sk , and ksn_mod was equal to the value "9876543210E00008", which we calculated above.
First we need to take current_sk , get the upper 8 bytes and move them 64 bits to the right, we get “6AC292FAA1315B4D”. This can be obtained using a bit mask.
Here we need to shift this value 64 bits to the right to get "6AC292FAA1315B4D". Let's call it left_key (looks like the left side of current_sk ).
Next, we get 8 low bytes current_sk , using a mask.
Let's call this value (you guessed it) right_key . Next, take the right_key and execute the XOR with ksn_mod "9876543210E00008".
This value is called message. Next, take a message and encrypt it using DES (simple DES). We will transmit the message algorithm to DES as data to be encrypted and left_key , which will encrypt the key. The result is “2FE5D2833A3ED1BA”. Now you need to XOR this value and right_key .
This value is the lower 8 bytes of our session key! Now we need to repeat the operations just described with other inputs. This time we take current_sk and XOR it with “C0C0C0C000000000C0C0C0C000000000”. As far as I can judge this value is arbitrary, but it is part of the ANSI standard, so you just have to believe my words.
If we take the value “AA02523AA1315B4D454A7363D7D5933A” and substitute it for the current_sk in the operation described above, we get “27F66D5244FF62E1”. This is the upper 8 bytes of our session key. Combining them we get "27F66D5244FF62E1AA6F6120EDEB4280".
I hope I explained the DUKPT scheme and how it relates to the effectiveness of magnetic track scanners. Waiting for corrections and questions in the comments section.
Recently, I needed to decipher card data from a magnetic track reader. It would seem simple. I take the key and perform a specific decryption algorithm. But it was not there.
It turned out that my readers use a scheme known as DUKPT (Derived Unique Key Per Transaction - Definition of Unique Key On Transaction). The idea of this scheme is that for each transaction (or in our case for each card rental) the data is encrypted using the key calculated for the individual card rental.
')
Thus, in order to decrypt data that has been encrypted using this scheme, you must be able to calculate the key for a separate card rental. The process of calculating such a key (session key) is far from simple.
The process is described in ANSI X9.24 part 1. However, the document costs about $ 140. Free, easy-to-access documentation describing this process is difficult to find. The best resource I managed to find is here ; There is a pretty good explanation of how IPEK is calculated (Initial Pin Encryption Key - the initial key for calculating keys). Unfortunately, this is only part of the complete scheme. In this post I will try to fully explain the DUKPT scheme.
Definitions
BDK : This is an abbreviation for Base Derivation Key. This key is known only to the manufacturer and developer of software that interacts with a magnetic track scanner.
IPEK : This is short for Initial Pin Encryption Key. This key is determined from the BDK. This key is downloaded to the device by the manufacturer and used to generate future keys. Compromising IPEK does not compromise BDK.
KSN : This is short for Key Serial Number. KSN is a combination of the serial number of the magnetic track scanner and the card rental quantity counter, which was performed on the device.
How does it work
The BDK is used by the manufacturer to generate IPEK, which is downloaded to the device during development. The device uses IPEK and KSN to calculate the session key that encrypts data readable from the card.
BDK is required by software developers to calculate IPEK. After receiving IPEK, they can request KSN from the device. IPEK and KSN are used to obtain the key for a separate transaction / rental card. Having these keys, developers can decipher card data.
IPEK calculation
To get the initial key to calculate the keys (IPEK), we need the basic key of the algorithm (BDK) and the serial number of the key (KSN). IPEK is determined using the TripleDES algorithm. TripleDES is a simple DES algorithm that runs in three passes.
The algorithm uses a key length of 24 bytes. The DES algorithm is used three times, first with a key of 1-8 bytes, then 9-16 bytes and, finally, 17-24 bytes separately for each pass.
TripleDES can use a key length of 16 bytes, this method is called EDE3. Bytes 1-8 will be used first, then 9-16 and, again, 1-8 emitting a 24-byte key.
Some implementations of TripleDES may not automatically use the short key. Before you understand it, I spent a lot of time trying to figure out what the problem was. Assuming that this is a special implementation of TripleDES, I used an emitted 24 byte key of 16 bytes.
After much anguish, it descended on me to try to take the first 8 bytes and add them to the end of the key before transferring it to the TripleDES algorithm. This solved the problem.
Details
IPEK consists of two 8-byte parts, which are obtained as a result of two separate passes of the TripleDES algorithm. Both are obtained by encrypting the higher 8 bytes of KSN with a zero counter. The difference between the left and right sides is that the right side is obtained by encrypting KSN using a slightly modified version of the BDK. I will describe this process below.
Suppose there is a 16-byte BDK represented by the hexadecimal string "0123456789ABCDEFFEDCBA9876543210". We also have a 10 byte KSN with a counter equal to 8, represented by the hexadecimal string "FFFF9876543210E00008".
Get the BDK to encrypt the left side of the IPEK by adding the first 8 bytes to the end of the BDK, this will be the next 24 byte key.
0123456789ABCDEFFEDCBA98765432100123456789ABCDEF If the length of KSN is not equal to 10 bytes, then we supplement it with 10 bytes of hexadecimal "F" (1111). It is important to note that IPEK is the very first key on the device. This means that we calculate it with a counter in KSN equal to 0. To get a KSN with counter 0, we superimpose a mask on it in hexadecimal representation of which is the string "FFFFFFFFFFFFFFE00000".
FFFF9876543210E00008 and FFFFFFFFFFFFFFE00000 = FFFF9876543210E00000 Wonderful. Now we have zero KSN. However, we need the upper 8 bytes of KSN. We get them by moving the KSN to the right by 16 bits.
FFFF9876543210E00000 >> 16 = FFFF9876543210E0 Fine. The next step is TripleDES encryption of the string “FFFF9876543210E0” with the BDK key of 24 bytes “0123456789ABCDEFFEDCBA98765432100123456789ABCDEF”. The result of this encryption will be the left side of the IPEK.
6AC292FAA1315B4D If you remember, I mentioned that a slightly modified version of the BDK will be used to get the right part. Thus, to do this, we need to take the original 16 byte BDK "0123456789ABCDEFFEDCBA9876543210" and perform the XOR using the following mask "C0C0C0C000000000C0C0C0C000000000". It looks like a completely arbitrary mask, but alas, it is necessary to get the right IPEK.
0123456789ABCDEFFEDCBA9876543210 xor C0C0C0C000000000C0C0C0C000000000 = C1E385A789ABCDEF3E1C7A5876543210 We will do the same thing that we did with the key for the left side, take the upper 8 bytes and add them to the end, we get the next 24 byte key.
C1E385A789ABCDEF3E1C7A5876543210C1E385A789ABCDEF Next, take the upper 8 bytes of KSN with a zero counter (which we calculated earlier) and encrypt it with the help of TripleDES with the key that we just calculated. This will give us the right IPEK register, we get the next 16 byte IPEK (I separated the left and right parts for clarity).
6AC292FAA1315B4D 858AB3A3D7D5933A Calculation of session keys
We have IPEK. Next, we need to get from IPEK a unique key for a separate rental card (session key). To get it, a certain subroutine is used, let's call it a black box, the purpose of which is to return a separate session key. What is happening in the black box is not our concern yet. Right now we will look at the input of this subroutine.
Our black box has two entrances. One is the key and the second is the string to encrypt. The string is a modified KSN.
If you remember, the lower 21 bits of KSN contain a count of the number of card rentals on the device. We will transfer the modified KSN to the subroutine as many times as the units in the binary representation of the counter. The key that is transmitted with the modified KSN is IPEK at the first iteration, and at the next iterations it will be the key obtained from the black box at the previous iteration.
Let's start by changing the KSN. To begin, we will take the lower 8 bytes of KSN and reset the counter value in KSN. This can be done by masking the KSN using the following mask.
FFFF9876543210E00008 and 0000FFFFFFFFFFE00000 = 00009876543210E00000 We will use the resulting value to calculate each message sent to the black box. In our example with a counter equal to 8, we must transfer to the black box the binary representation of the number 8 (1000). For demonstration, assume that the counter has a more complex value of 10 (1010).
We will extract a set of binary numbers from the counter. In our case, for the number 10 (1010) there will be two binary numbers: 1000 and 0010. Have you caught the scheme? We get a set of numbers representing each binary unit of the number 10.
Next, we take the first number and apply the OR operation with KSN, which has the counter reset to zero, as shown earlier (note that the hexadecimal representation of the first number will be 0008).
9876543210E00000 OR 0000000000000008 = 9876543210E00008 Now we transfer IPEK as a key and just modified KSN to a black box. The black box will return the new key. This is the first session key (presented in hexadecimal): "27f66d5244ff62e1aa6f6120edeb4280".
Next, repeat the process with the following binary number, calculated earlier, 2 (0010). This time, we will use the first session key, which we have just received and we will calculate the new modification of KSN.
To calculate the new KSN modification, we will perform the OR operation with the latest modification obtained: 9876543210E00008.
9876543210E00008 OR 0000000000000002 = 9876543210E0000A Now we will transfer our new key “27f66d5244ff62e1aa6f6120edeb4280” and the new modification KSN “9876543210E0000A” to the black box and get another future key, “6cf2500a22507c7cc776ceadc1e33014”. This is the session key for our device with a counter of 10.
However, our real counter was 8, and we calculated the real session key “27F66D5244FF62E1AA6F6120EDEB4280” at the first stage.
The last operation we have to do with the obtained value is the final transformation of the key, with which we will decrypt the data. We must perform the XOR key with the mask "00000000000000FF00000000000000FF".
27F66D5244FF62E1AA6F6120EDEB4280 XOR 00000000000000FF00000000000000FF = 27F66D5244FF621EAA6F6120EDEB427F This is the key that is required to decrypt the data.
Black box
I called the black box an algorithm that calculates session keys. The black box accepts the current session key, which I denote current_sk , and the KSN modification, denoted ksn_mod .
If at the beginning the assumption that IPEK obtained above was transmitted as current_sk , and ksn_mod was equal to the value "9876543210E00008", which we calculated above.
First we need to take current_sk , get the upper 8 bytes and move them 64 bits to the right, we get “6AC292FAA1315B4D”. This can be obtained using a bit mask.
6AC292FAA1315B4D858AB3A3D7D5933A AND FFFFFFFFFFFFFFFF0000000000000000 = 6AC292FAA1315B4D0000000000000000 Here we need to shift this value 64 bits to the right to get "6AC292FAA1315B4D". Let's call it left_key (looks like the left side of current_sk ).
Next, we get 8 low bytes current_sk , using a mask.
6AC292FAA1315B4D858AB3A3D7D5933A AND 0000000000000000FFFFFFFFFFFFFFFF = 0000000000000000858AB3A3D7D5933A Let's call this value (you guessed it) right_key . Next, take the right_key and execute the XOR with ksn_mod "9876543210E00008".
858AB3A3D7D5933A AND 9876543210E00008 = 1DFCE791C7359332 This value is called message. Next, take a message and encrypt it using DES (simple DES). We will transmit the message algorithm to DES as data to be encrypted and left_key , which will encrypt the key. The result is “2FE5D2833A3ED1BA”. Now you need to XOR this value and right_key .
2FE5D2833A3ED1BA XOR 858AB3A3D7D5933A = AA6F6120EDEB4280 This value is the lower 8 bytes of our session key! Now we need to repeat the operations just described with other inputs. This time we take current_sk and XOR it with “C0C0C0C000000000C0C0C0C000000000”. As far as I can judge this value is arbitrary, but it is part of the ANSI standard, so you just have to believe my words.
6AC292FAA1315B4D858AB3A3D7D5933A XOR C0C0C0C000000000C0C0C0C000000000 = AA02523AA1315B4D454A7363D7D5933A If we take the value “AA02523AA1315B4D454A7363D7D5933A” and substitute it for the current_sk in the operation described above, we get “27F66D5244FF62E1”. This is the upper 8 bytes of our session key. Combining them we get "27F66D5244FF62E1AA6F6120EDEB4280".
Conclusion
I hope I explained the DUKPT scheme and how it relates to the effectiveness of magnetic track scanners. Waiting for corrections and questions in the comments section.
Source: https://habr.com/ru/post/254109/
All Articles