Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
To ensure the security of operations performed using the IPC, the card stores the keys of both symmetric and asymmetric encryption algorithms. Asymmetric encryption algorithms are used for offline dynamic card authentication procedures and encryption of the PIN-code transmitted by the terminal to the card. Key pairs (public and private) for asymmetric encryption algorithms are generated either directly by the IPC or by the card issuer. These keys are associated with the card issuer through the card's public key certificates generated by the card issuer.
The situation is different with symmetric encryption algorithms. These algorithms assume the existence of a shared secret between the parties using them and therefore are used in EMV only for the interaction of the card and its issuer.
To improve the security of operations in terms of the use of symmetric encryption algorithms, a hierarchical structure of key management is used. Symmetric keys in the EMV standard can be used for different purposes: to form cryptograms, to ensure confidentiality and integrity of information exchange between the card and the issuer. The issuer creates a master key for a specific purpose, designed to generate keys for a card of the same purpose. The issuer's master key is used for a number of issuer's cards, usually identified by an identifier issued to the bank by the payment system (Bank Identification Number, or BIN for short). With some by the issuer of the diversification fashion, it generates for each card from the aforementioned set a personal card key of the same purpose as the issuer's key. In turn, the card, using the card key and the diversification mode defined by the issuer, for each transaction generates a session key for the same purpose.
Such a hierarchical system for generating symmetric keys increases the costs of fraudsters for the implementation of fraud, which means that it can improve the security of transactions performed using the IPC. Indeed, a fraudster who has access only to the details of a card operation (the most accessible and, therefore, the cheapest option for a fraudster) can hope to compromise the card's session keys. Even by compromising these keys, the fraudster will achieve practically nothing, since the next operation will use new session keys and, in order to find them, the card keys must be compromised.
Having spent a lot of effort and compromising the card keys, the fraudster will be able to emulate transactions with only one card. To emulate the operations of other cards, knowledge of the issuer's key is required.
Thus, ensuring the confidentiality of the issuer's keys becomes the holy of holies in security schemes for IPC transactions. However, here is the time to remind you that the IPC stores a whole set of keys for symmetric and asymmetric encryption. So, compromising the key of an issuer of a certain purpose, in addition to being difficult to implement, practically does not give a fraudster a chance of success. Unfortunately, there are other methods of fraud using the IPC, which will be discussed separately in clause 6.6.
Let's consider algorithms for generating card keys and session keys.
3.16.1. Procedure for withdrawing card keys from the issuer's keys
The EMV card application for performing a transaction (about keys for personalizing cards is described in Chapter 5) can use the following 16-byte keys of symmetric encryption algorithms:
All the listed keys, in turn, are obtained from the corresponding keys of the issuer of this card (Table 3.25).
Tab. 3.25. Matching card and issuer keys
In general, the choice of the algorithm for deriving the card key from the issuer's key is the prerogative of the issuer. Meanwhile, the EMV standard offers its own version of the key derivation. In addition, payment systems, on behalf of the card issuer, in case of unavailability of the latter (failure in the issuer's processing center or communication problems) perform the function of backup authorization on behalf of the issuer (Stand-In mode). To be able to do this, the payment system must be able to derive the card key and the session key from the issuer's key. As a result, in specific implementations, the algorithm for deriving the card key from the issuer's key is determined by the payment systems.
The EMV v.4.2 standard offers the following algorithm for deriving the key of the MK card from the key of the issuer IMK.
Case 1. The size of the PAN card number is 16 digits or less. An 8-byte number Y is obtained by concatenating the PAN data elements and the PAN Sequence Number (if the last data element on the card is not present, it is replaced by the '00'h byte). Note that if the concatenation of the PAN and PAN Sequence Number results in a number less than 8 bytes, then it is padded on the left with 'O'h nibbles to produce a number of 8 bytes. If the size is obtained g AH
MasterCard to J
If the number is more than 8 bytes, then the rightmost 8 bytes of this number are taken as Y.
After the number Y is obtained, the left and right components of the card key Z L and Z R are calculated :
Z L = DES3 (IMK) [Y];
Z R = DES3 (IMK) [Y ® (FF || 'FF' || 'FF' || 'FF' || 'FF' || 'FF' || 'FF' || 'FF')]; MK = (Z L || Z R ).
Case 2. The size of the PAN card number is more than 16 digits. In this case, the algorithm for deriving the card key is as follows:
When moving from left to right along the "decimylized" nibbles, the last one after another are added to the right of Y until a sequence of Y consisting of 16 decimal digits is obtained.
After receiving Y, the card key MK = (Z L || Z R ) is calculated as in case 1.
3.16.2. Session keys output procedure
The choice of the procedure for withdrawing the session key SK - (SK, || SK R ), where SK E and SK R are 8-byte numbers, from the card master key is the prerogative of the card issuer. In the EMV specifications prior to version 4.0, there was a single informal restriction on the transformation of the session key output SK = F (MK) [X], which was that the number of possible values of the function F was large enough and uniformly distributed. Later, in version 4.0 of the EMV standard, there was also a requirement that the probability of repetition of diversification data X was low, and also a key tree derivation algorithm (AVDK) was proposed for deriving the session key from the value of the card key and the ATC transaction counter.
In the EMV v.4.2 standard (Appendix A1.3.1), to display all session keys, it is proposed to use the SKD (MK) [X] function from the MK key, for which the session key is displayed, and the 8-byte diversification sequence X = (X o || X, || X 2 1 | X 3 1 | X 4 1 | X 5 1 | X 6 1 | X 7 ). The SKD (M) [X] function is defined by the equalities:
SKD (MK) [X] = (SK L || SK R );
SK L = DES3 (MK) [X 0 II Xi II 'F0' || X 3 1 | X 4 1 | X 5 1 | X 6 || X 7 ];
SK R = DES3 (MK) [X 0 II Xi II 'OF' || X 3 1 | X 4 || X 5 1 | X 6 || X 7 ],
When deriving the session key SK AC, which is necessary for calculating the applied cryptogram, the EMV standard uses the sequence
X = (ATC || '00' || '00' || '00' || '00' || '00' || '00')
8 bytes long, where ATC is a 2-byte application transaction counter. The resulting SK AC value is used to generate all cryptograms calculated by both the card and the issuer (to calculate the AR.PC cryptogram) during the transaction.
When outputting session keys SK SMC and SK SMI for Secure Messaging in the EMV standard, the sequence X - АС is used as a diversification mode, where АС is the cryptogram value of 8 bytes, returned by the card in response to the first GENERATE АС command.
The method for calculating session keys described above is called EMV CSK (Card Session Key). Note that the type of transformation SKD (M) [X] is explained, among other things, by the structure of the diversification mode. Indeed, the conversion value does not depend on the third byte X 2 , which, with the used diversification mode structure, always consists of zero bits, since the ATC unit has a size of 2 bytes.
Leading payment systems, along with the EMV CSK method, use their own methods for withdrawing session keys. In the MasterCard payment system, the method for withdrawing session keys is called MasterCard Proprietary SKD. In accordance with this method , the SKD (MK) [X] function is used to output the SK AC session key , and the sequence X - (АТС || '00' || '00' || UN) 8 bytes long, where ATC is a counter of application transactions of 2 bytes in size, UN is a random number (Unpredictable Number) of 4 bytes, generated by the terminal and transmitted to the card in the GENERATE AC command.
In this case, to display the ARPC cryptogram, the issuer uses the key of the MK AC card . The issuer does not withdraw the session key.
For the Secure Messaging procedure in accordance with the MasterCard Proprietary SKD, the issuer calculates its own session key for each Script Processing command. In this case, for the first Script Processing command, the cryptogram returned by the card in response to the first GENERATE AC command is used as a diversification mode. For each next Script Processing command, the diversification mode is obtained from the diversification mode for the previous command by increasing it by 1 (with a preliminary representation of the diversification mode in decimal notation).
The VSDC application has simplified its own procedure for displaying session keys as much as possible. When outputting session keys for the algorithm for ensuring the integrity of the data transmitted in the command and for authenticating the data source SK SMI , as well as for the algorithm for ensuring the confidentiality of the data transmitted in the command SK SMC , the following algorithm is used. The first component of the corresponding key for Secure Messaging is added modulo 2 with the PBX value padded on the right by six zero bytes, and the second component is added modulo 2 with the inverted PBX value padded on the right with six zero bytes. As a result, the compromise of the session key leads to the compromise of the card key, and the meaning of entering the session keys is largely lost.
As for the internal VSDC algorithm for outputting the session key for generating the SK AC cryptogram , in accordance with it, the session key coincides with the card key.
In version 4.0 of the EMV standard, an additional optional algorithm for deriving the key tree was proposed for calculating session keys, which is described below. This algorithm was also used in version 4.1 of the EMV standard.
A tree with height H and branching size of each vertex b is considered. Obviously, at the level 0 <i <H, the number of tree vertices is equal to b '. It is necessary that the number of vertices at the lowest level exceeds the maximum value of the ATC transaction counter, that is, for the inequality b "> 2 16 - 1 to hold.
Consider the transformation Ф (X, Y, j) of two 16-byte numbers X, Y, each 16 bytes in size, and an integer j into a 16-byte number. The transformation Ф (Х, Y, j) has the form:
Z = Ф (X, Y, j) = (DES3 (X) [Y l © j (mod b)] || DES3 (X) [Y R © j (mod b)]),
where Y l and Y r are 8-byte numbers such that Y = (Y L || Y R ).
Obviously, the inverse transformation exists and is determined by the equality:
Y = Ф'ЧХ, Y, j) = (DES3- 1 (X) [Z l ] © j (mod b) || DES3 " 1 (X) [Z R ] © j (mod b)),
where Z L and Z R are 8-byte numbers such that Z = (Z L || Z R ).
For each vertex of the tree, recursively define 16-byte numbers 1K ( j as follows:
1K 0 .o = MK,
where MK is the master key of the card;
1K C = F (MK, IV, j),
where IV is an initial sequence of 16 bytes, 0 <j <b - 1;
IKi, j = F (1K W / L , IKi 2 . J / bS j),
where the sign "/" denotes division entirely (only the whole part of the number obtained as a result of division remains), 2 <i <H, 0 <j <b 1 - 1.
Then, for a given value of the ATC, we determine the value of the session key SK (ATC): = IK H ATC © 1K n _ 2> dts / b 2,
Note that the above definition has one very important property. To determine the value of SK (ATC), it is required to calculate only the values of IK, ATC / b n-> for 0 <i < H . Note that all points of the form i, ATC / b H-1 , where 1 <i <H, lie on one branch of the tree originating from its root (0, 0). Therefore, for any 1 <i <H, the value of IK, ATC / b low depends on
g an
MasterCard
^? 9
IK values. j for two adjacent vertices of this branch of the tree located directly above the vertex (i, ATC / b H “').
Consider the following PBX representation:
ATC = a 0 b n 1 4- a, b n 2 4- ... 4- a n _ 2 b 4- a H _ v
Then the recurrent definition of SK (ATC) can be expressed as the following algorithm:
GP: = MK;
P: = F (MK, IV, a 0 );
For 1 <i <H - 1 do
T: = P;
P: = F (P, GP, aD;
GP: = T
end;
SK (ATC): = F (P, GP, a n _!) © GP.
The VISA payment system for the withdrawal of session keys has included the described AVDK algorithm in its VIS 1.4.x specifications. The applied cryptogram resulting from the use of AVDK was named after the version number of the application "Cryptogram version 14". Due to some legal problems related to the patent purity of using the AVDK algorithm, the payment system sent a letter to participating banks at the beginning of September 2005 to discontinue the use of Cryptogram 14 in VISA cards.
In the latest version of the EMV standard (v.4.2), the AVDK algorithm is absent. It should be admitted that among the known algorithms AVDK is the most "unpredictable" algorithm for generating session keys. This means that it is almost impossible to make any useful assumptions about the new value of the session key from the PBX value and the previously generated session key values.
3.16.3. Limitations on the size of asymmetric encryption keys
Recall that for the lengths (expressed in bytes) of the asymmetric encryption public key modules of the payment system certification authority N ca , the issuer N, and the N IC card , the following relationship is true: NIC <N, < N ac <248.
At the same time, there are additional restrictions on the size of the modules of the specified keys. In particular, the length of the Value field of the AEF Data Template does not exceed 251 bytes (see 3.6). This means that the ICC Public Key Certificate (Tag '9F46') and ICC PIN Encipherment Public Key Certificate (Tag '9F2D') data objects are less than or equal to 251 bytes. Since when the length of the key module exceeds 127 bytes, the length of the Length field of these objects is 2 bytes, it follows that the size of the Value field does not exceed 247 bytes. Since the length of the card key certificate is equal to the length of the issuer's public key module, it follows that the inequality N IC <N, <247 always holds .
The CDA method also imposes a limitation on the size of the N IC card key module . The structure of the Response Template (Tag '77') in the response to the AC GENERATE command when using the CDA method is shown in Table. 3.26 (all sizes in bytes).
Tab. 3.26. Structure of the Response Template
Since the Issuer Application Data object is optional, then, as follows from table. 3.26, the Response Template size ranges from N IC 4-16 to N 1C + 51 bytes. On the other hand, according to EMV, the size of the command response data field does not exceed 256 bytes.
Hence, when using the CDA method, the size of the card key module can vary in the range from 205 to 240 bytes. Today, on cards, keys with a card's public key module length of 128 bytes are most often used. Therefore, the considered limitation is not yet critical.
The size limitation of the N IC card key module may be imposed by the DDA card authentication method. The response to the INTERNAL AUTHENTICATE command may, in addition to the mandatory Signed Dynamic Application Data data element, contain some special data objects not specified by the EMV standard, presented in the encoding
MasierCa k
BER-TLV. In this case, format 2 of the command response data field is used (the Tag '77' template is used for composite data objects represented in the BER-TLV encoding). This means that 7 bytes will be spent on the Tag and Length fields of the template and the Signed Dynamic Application Data (Tag '9F4B') data object. Thus, the limit on the size of the card's public key modulus, expressed in bytes, in this case is as follows: N IC <249 - Z, where Z is the total size of all special data objects returned to the terminal in response to the INTERNAL AUTHENTICATE command.
Chapter 4
The situation is different with symmetric encryption algorithms. These algorithms assume the existence of a shared secret between the parties using them and therefore are used in EMV only for the interaction of the card and its issuer.
To improve the security of operations in terms of the use of symmetric encryption algorithms, a hierarchical structure of key management is used. Symmetric keys in the EMV standard can be used for different purposes: to form cryptograms, to ensure confidentiality and integrity of information exchange between the card and the issuer. The issuer creates a master key for a specific purpose, designed to generate keys for a card of the same purpose. The issuer's master key is used for a number of issuer's cards, usually identified by an identifier issued to the bank by the payment system (Bank Identification Number, or BIN for short). With some by the issuer of the diversification fashion, it generates for each card from the aforementioned set a personal card key of the same purpose as the issuer's key. In turn, the card, using the card key and the diversification mode defined by the issuer, for each transaction generates a session key for the same purpose.
Such a hierarchical system for generating symmetric keys increases the costs of fraudsters for the implementation of fraud, which means that it can improve the security of transactions performed using the IPC. Indeed, a fraudster who has access only to the details of a card operation (the most accessible and, therefore, the cheapest option for a fraudster) can hope to compromise the card's session keys. Even by compromising these keys, the fraudster will achieve practically nothing, since the next operation will use new session keys and, in order to find them, the card keys must be compromised.
Having spent a lot of effort and compromising the card keys, the fraudster will be able to emulate transactions with only one card. To emulate the operations of other cards, knowledge of the issuer's key is required.
Thus, ensuring the confidentiality of the issuer's keys becomes the holy of holies in security schemes for IPC transactions. However, here is the time to remind you that the IPC stores a whole set of keys for symmetric and asymmetric encryption. So, compromising the key of an issuer of a certain purpose, in addition to being difficult to implement, practically does not give a fraudster a chance of success. Unfortunately, there are other methods of fraud using the IPC, which will be discussed separately in clause 6.6.
Let's consider algorithms for generating card keys and session keys.
3.16.1. Procedure for withdrawing card keys from the issuer's keys
The EMV card application for performing a transaction (about keys for personalizing cards is described in Chapter 5) can use the following 16-byte keys of symmetric encryption algorithms:
- MKsd - ICC Master Key for AC generation (a key for outputting a session key intended for generating applied card cryptograms);
- MK SMI - ICC Master Key for Secure Messaging for Integrity and Authentication (key for outputting the session key used to ensure the integrity of the data transmitted in the command and to authenticate the command sender);
- MK SMC - ICC Master Key for Secure Messaging for Confidentiality (key for displaying the session key used to ensure the confidentiality of the data transmitted in the command);
- MK IDN - ICC Master Key for ICC Dynamic Number Generation (the key used to generate the ICC Dynamic Number value).
All the listed keys, in turn, are obtained from the corresponding keys of the issuer of this card (Table 3.25).
Tab. 3.25. Matching card and issuer keys
| ICC Master Key | Withdrawn from Issuer Master Key |
| mk AC | 1MK AC |
| MK SMI | IMK SM , |
| mk smc | IMK smc |
| MK IDN | IMK 1DN |
In general, the choice of the algorithm for deriving the card key from the issuer's key is the prerogative of the issuer. Meanwhile, the EMV standard offers its own version of the key derivation. In addition, payment systems, on behalf of the card issuer, in case of unavailability of the latter (failure in the issuer's processing center or communication problems) perform the function of backup authorization on behalf of the issuer (Stand-In mode). To be able to do this, the payment system must be able to derive the card key and the session key from the issuer's key. As a result, in specific implementations, the algorithm for deriving the card key from the issuer's key is determined by the payment systems.
The EMV v.4.2 standard offers the following algorithm for deriving the key of the MK card from the key of the issuer IMK.
Case 1. The size of the PAN card number is 16 digits or less. An 8-byte number Y is obtained by concatenating the PAN data elements and the PAN Sequence Number (if the last data element on the card is not present, it is replaced by the '00'h byte). Note that if the concatenation of the PAN and PAN Sequence Number results in a number less than 8 bytes, then it is padded on the left with 'O'h nibbles to produce a number of 8 bytes. If the size is obtained g AH
MasterCard to J
If the number is more than 8 bytes, then the rightmost 8 bytes of this number are taken as Y.
After the number Y is obtained, the left and right components of the card key Z L and Z R are calculated :
Z L = DES3 (IMK) [Y];
Z R = DES3 (IMK) [Y ® (FF || 'FF' || 'FF' || 'FF' || 'FF' || 'FF' || 'FF' || 'FF')]; MK = (Z L || Z R ).
Case 2. The size of the PAN card number is more than 16 digits. In this case, the algorithm for deriving the card key is as follows:
- 1) PAN and PAN Sequence Number data items are concatenated (if the last data item on the card is missing, it is replaced by the '00'h byte). If the card number contains an odd number of digits, then a nibble 'O'h is added to the left of the previously received sequence;
- 2) the SHA-1 hashing algorithm is applied to the sequence obtained at the previous step. The result is an X sequence of 40 nibbles. Moving along the sequence X from left to right, we sequentially select those nibbles that correspond to decimal digits (0, 1, ..., 9). The result of this procedure is a sequence of decimal digits Y. If its size is more than 16 digits, then the leftmost 16 digits are selected from it. Otherwise (Y is less than 16 decimal digits), the nibbles of X corresponding to non-decimal digits are converted to nibbles corresponding to decimal digits using the decimalization table:
| Nibble X | A | v | with | D | E | F |
| "Decimized" nibble | 0 | 1 | 2 | 3 | 4 | 5 |
When moving from left to right along the "decimylized" nibbles, the last one after another are added to the right of Y until a sequence of Y consisting of 16 decimal digits is obtained.
After receiving Y, the card key MK = (Z L || Z R ) is calculated as in case 1.
3.16.2. Session keys output procedure
The choice of the procedure for withdrawing the session key SK - (SK, || SK R ), where SK E and SK R are 8-byte numbers, from the card master key is the prerogative of the card issuer. In the EMV specifications prior to version 4.0, there was a single informal restriction on the transformation of the session key output SK = F (MK) [X], which was that the number of possible values of the function F was large enough and uniformly distributed. Later, in version 4.0 of the EMV standard, there was also a requirement that the probability of repetition of diversification data X was low, and also a key tree derivation algorithm (AVDK) was proposed for deriving the session key from the value of the card key and the ATC transaction counter.
In the EMV v.4.2 standard (Appendix A1.3.1), to display all session keys, it is proposed to use the SKD (MK) [X] function from the MK key, for which the session key is displayed, and the 8-byte diversification sequence X = (X o || X, || X 2 1 | X 3 1 | X 4 1 | X 5 1 | X 6 1 | X 7 ). The SKD (M) [X] function is defined by the equalities:
SKD (MK) [X] = (SK L || SK R );
SK L = DES3 (MK) [X 0 II Xi II 'F0' || X 3 1 | X 4 1 | X 5 1 | X 6 || X 7 ];
SK R = DES3 (MK) [X 0 II Xi II 'OF' || X 3 1 | X 4 || X 5 1 | X 6 || X 7 ],
When deriving the session key SK AC, which is necessary for calculating the applied cryptogram, the EMV standard uses the sequence
X = (ATC || '00' || '00' || '00' || '00' || '00' || '00')
8 bytes long, where ATC is a 2-byte application transaction counter. The resulting SK AC value is used to generate all cryptograms calculated by both the card and the issuer (to calculate the AR.PC cryptogram) during the transaction.
When outputting session keys SK SMC and SK SMI for Secure Messaging in the EMV standard, the sequence X - АС is used as a diversification mode, where АС is the cryptogram value of 8 bytes, returned by the card in response to the first GENERATE АС command.
The method for calculating session keys described above is called EMV CSK (Card Session Key). Note that the type of transformation SKD (M) [X] is explained, among other things, by the structure of the diversification mode. Indeed, the conversion value does not depend on the third byte X 2 , which, with the used diversification mode structure, always consists of zero bits, since the ATC unit has a size of 2 bytes.
Leading payment systems, along with the EMV CSK method, use their own methods for withdrawing session keys. In the MasterCard payment system, the method for withdrawing session keys is called MasterCard Proprietary SKD. In accordance with this method , the SKD (MK) [X] function is used to output the SK AC session key , and the sequence X - (АТС || '00' || '00' || UN) 8 bytes long, where ATC is a counter of application transactions of 2 bytes in size, UN is a random number (Unpredictable Number) of 4 bytes, generated by the terminal and transmitted to the card in the GENERATE AC command.
In this case, to display the ARPC cryptogram, the issuer uses the key of the MK AC card . The issuer does not withdraw the session key.
For the Secure Messaging procedure in accordance with the MasterCard Proprietary SKD, the issuer calculates its own session key for each Script Processing command. In this case, for the first Script Processing command, the cryptogram returned by the card in response to the first GENERATE AC command is used as a diversification mode. For each next Script Processing command, the diversification mode is obtained from the diversification mode for the previous command by increasing it by 1 (with a preliminary representation of the diversification mode in decimal notation).
The VSDC application has simplified its own procedure for displaying session keys as much as possible. When outputting session keys for the algorithm for ensuring the integrity of the data transmitted in the command and for authenticating the data source SK SMI , as well as for the algorithm for ensuring the confidentiality of the data transmitted in the command SK SMC , the following algorithm is used. The first component of the corresponding key for Secure Messaging is added modulo 2 with the PBX value padded on the right by six zero bytes, and the second component is added modulo 2 with the inverted PBX value padded on the right with six zero bytes. As a result, the compromise of the session key leads to the compromise of the card key, and the meaning of entering the session keys is largely lost.
As for the internal VSDC algorithm for outputting the session key for generating the SK AC cryptogram , in accordance with it, the session key coincides with the card key.
In version 4.0 of the EMV standard, an additional optional algorithm for deriving the key tree was proposed for calculating session keys, which is described below. This algorithm was also used in version 4.1 of the EMV standard.
A tree with height H and branching size of each vertex b is considered. Obviously, at the level 0 <i <H, the number of tree vertices is equal to b '. It is necessary that the number of vertices at the lowest level exceeds the maximum value of the ATC transaction counter, that is, for the inequality b "> 2 16 - 1 to hold.
Consider the transformation Ф (X, Y, j) of two 16-byte numbers X, Y, each 16 bytes in size, and an integer j into a 16-byte number. The transformation Ф (Х, Y, j) has the form:
Z = Ф (X, Y, j) = (DES3 (X) [Y l © j (mod b)] || DES3 (X) [Y R © j (mod b)]),
where Y l and Y r are 8-byte numbers such that Y = (Y L || Y R ).
Obviously, the inverse transformation exists and is determined by the equality:
Y = Ф'ЧХ, Y, j) = (DES3- 1 (X) [Z l ] © j (mod b) || DES3 " 1 (X) [Z R ] © j (mod b)),
where Z L and Z R are 8-byte numbers such that Z = (Z L || Z R ).
For each vertex of the tree, recursively define 16-byte numbers 1K ( j as follows:
1K 0 .o = MK,
where MK is the master key of the card;
1K C = F (MK, IV, j),
where IV is an initial sequence of 16 bytes, 0 <j <b - 1;
IKi, j = F (1K W / L , IKi 2 . J / bS j),
where the sign "/" denotes division entirely (only the whole part of the number obtained as a result of division remains), 2 <i <H, 0 <j <b 1 - 1.
Then, for a given value of the ATC, we determine the value of the session key SK (ATC): = IK H ATC © 1K n _ 2> dts / b 2,
Note that the above definition has one very important property. To determine the value of SK (ATC), it is required to calculate only the values of IK, ATC / b n-> for 0 <i < H . Note that all points of the form i, ATC / b H-1 , where 1 <i <H, lie on one branch of the tree originating from its root (0, 0). Therefore, for any 1 <i <H, the value of IK, ATC / b low depends on
g an
MasterCard
^? 9
IK values. j for two adjacent vertices of this branch of the tree located directly above the vertex (i, ATC / b H “').
Consider the following PBX representation:
ATC = a 0 b n 1 4- a, b n 2 4- ... 4- a n _ 2 b 4- a H _ v
Then the recurrent definition of SK (ATC) can be expressed as the following algorithm:
GP: = MK;
P: = F (MK, IV, a 0 );
For 1 <i <H - 1 do
T: = P;
P: = F (P, GP, aD;
GP: = T
end;
SK (ATC): = F (P, GP, a n _!) © GP.
The VISA payment system for the withdrawal of session keys has included the described AVDK algorithm in its VIS 1.4.x specifications. The applied cryptogram resulting from the use of AVDK was named after the version number of the application "Cryptogram version 14". Due to some legal problems related to the patent purity of using the AVDK algorithm, the payment system sent a letter to participating banks at the beginning of September 2005 to discontinue the use of Cryptogram 14 in VISA cards.
In the latest version of the EMV standard (v.4.2), the AVDK algorithm is absent. It should be admitted that among the known algorithms AVDK is the most "unpredictable" algorithm for generating session keys. This means that it is almost impossible to make any useful assumptions about the new value of the session key from the PBX value and the previously generated session key values.
3.16.3. Limitations on the size of asymmetric encryption keys
Recall that for the lengths (expressed in bytes) of the asymmetric encryption public key modules of the payment system certification authority N ca , the issuer N, and the N IC card , the following relationship is true: NIC <N, < N ac <248.
At the same time, there are additional restrictions on the size of the modules of the specified keys. In particular, the length of the Value field of the AEF Data Template does not exceed 251 bytes (see 3.6). This means that the ICC Public Key Certificate (Tag '9F46') and ICC PIN Encipherment Public Key Certificate (Tag '9F2D') data objects are less than or equal to 251 bytes. Since when the length of the key module exceeds 127 bytes, the length of the Length field of these objects is 2 bytes, it follows that the size of the Value field does not exceed 247 bytes. Since the length of the card key certificate is equal to the length of the issuer's public key module, it follows that the inequality N IC <N, <247 always holds .
The CDA method also imposes a limitation on the size of the N IC card key module . The structure of the Response Template (Tag '77') in the response to the AC GENERATE command when using the CDA method is shown in Table. 3.26 (all sizes in bytes).
Tab. 3.26. Structure of the Response Template
| Data object | Tag | Length field size | Value size | Overall size | |
| Response Template | 1 | 2 | 3 | ||
| CID | 2 | 1 | 1 | 4 | |
| ATC | 2 | 1 | 2 | 5 | |
| Signed Dynamic Data | 2 | 2 | Nc | N IC + 4 | |
| Issuer Application Data | 2 | 1 | Up to 32 | Up to 35 |
Since the Issuer Application Data object is optional, then, as follows from table. 3.26, the Response Template size ranges from N IC 4-16 to N 1C + 51 bytes. On the other hand, according to EMV, the size of the command response data field does not exceed 256 bytes.
Hence, when using the CDA method, the size of the card key module can vary in the range from 205 to 240 bytes. Today, on cards, keys with a card's public key module length of 128 bytes are most often used. Therefore, the considered limitation is not yet critical.
The size limitation of the N IC card key module may be imposed by the DDA card authentication method. The response to the INTERNAL AUTHENTICATE command may, in addition to the mandatory Signed Dynamic Application Data data element, contain some special data objects not specified by the EMV standard, presented in the encoding
MasierCa k
BER-TLV. In this case, format 2 of the command response data field is used (the Tag '77' template is used for composite data objects represented in the BER-TLV encoding). This means that 7 bytes will be spent on the Tag and Length fields of the template and the Signed Dynamic Application Data (Tag '9F4B') data object. Thus, the limit on the size of the card's public key modulus, expressed in bytes, in this case is as follows: N IC <249 - Z, where Z is the total size of all special data objects returned to the terminal in response to the INTERNAL AUTHENTICATE command.
Chapter 4
Last edited by a moderator:
