Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
The issue of standardizing the process of personalization of microprocessor cards was opened until June 2003, when the EMV Card Personalization Specification (CPS) appeared. Until that time, depending on the microprocessor card chosen for the issue, card issuers had to purchase / develop a special program for their personalization machine, which implements the protocol for the machine with a chip based on personalization commands supported by the microprocessor of the selected card.
With the advent of the EMV Card Personalization Specification, card personalization procedures and commands, as well as the interfaces between the Personalization Data Preparation Center (CPC) and the personalization machine, personalization machine, and card have been largely standardized. Moreover, following the CPS standard, its projections appeared on the most common EMV applications, including VSDC, M / Chip, CPA applications. These projections, being a special case of the CPS standard, offer specific implementations for organizing the recording of data objects of the listed applications on the card.
Standardizing the card personalization process does not mean, of course, that all IPC vendors support the EMV Card Personalization Specification for all their products. At the same time, on many cards, including static ones, one or another CPS projection is supported.
The CPS standard is actively supported in cards using the GlobalPlatform / Java Card. This is understandable, since in the part of the interface between the personalization machine and the card, the specifications define only the procedure for mutual authentication of the card and the personalization equipment program, as well as the secure transmission of card personalization data. It is assumed that the creation of files and records in which the transmitted data will be stored on the card (the so-called card layout) remains outside the standard, again depends on the selected card microcircuit and is usually performed during the pre-personalization phase of the card. Since the GlobalPlatform environment has at its disposal mechanisms for loading and installing executable application modules, creating / deleting files, creating records, etc., as well as in connection with the fact
Moreover, the CPS specification is clearly influenced by the GlobalPlatform Card Specification (GPCS). In fact, the procedure for mutual authentication of the card application and the personalization machine, the derivation of the session personalization keys, ensuring the confidentiality and integrity of data circulating between the card and the personalization equipment are written off from the description of the Secure Channel Protocol (SCP02) in the GPCS specification.
The personalization data preparation process is performed in the back office system of the issuer or third party personalization bureau. This process can use data stored on different hosts of the bank. Its purpose is to prepare data to be loaded into the IPC.
Some of the prepared data may be common to a set of cards. Some data changes from card to card. Part of the data can be transmitted to the card in clear text. At the same time, there is data (keys, PIN codes), which must be encrypted during the entire personalization process.
The prepared data in a specific format is transferred to the personalization machine, which acts in accordance with the instructions defined for it. To implement the EMV Card Personalization Specification, the personalization engine must support it.
A personalization engine must have access to a cryptographic processor (SAM or HSM (Hardware Security Module)) to support secure interfaces with the personalization data center and card. To protect data, these interfaces use data encryption and generation / verification of MAC (Message Authentication Code) codes, which ensure the integrity of the transmitted information and the authentication of its source.
The personalization machine transfers the data prepared for it to the card application for storing it in the EEPROM memory. To do this, the card application must support the commands received from the personalization machine. In other words, the card application must also support the EMV Card Personalization Specification.
Of great importance in the EMV Card Personalization Specification is the uniform format of the data circulating between the DCP, machine personalization, and the card. Several physical modules of the personalization machine take part in the card personalization process (for example, embossing modules, magnetic stripe coding, data entry into a microprocessor), each of which requires its own data set. The data intended for a specific module of the personalization machine is identified in the general personalization data set by the identifier of that module's Module Identifier Code (MIC).
There is a MIC identifier that identifies the microprocessor personalization module. The value of this MIC is preset by agreement between the JRC and the personalization machine. In fig. 5.1 shows the general data structure for card personalization. In this case, the module with the MIC2 code is responsible for personalizing the microprocessor.
Rice. 5.1. General structure of personalization data
The IPC can be multi-application, and the EMV Card Personalization Specification provides for the ability to personalize multiple card applications at once. The data structure for each card application is shown in Fig. 5.2.
Title | | |
(header) Data for Application 1 Data for Application 2 Data for Application 3
Data for the car. Data . Data,
personalizations for logging sent to the application
Rice. 5.2. Data for personalizing the card application
From fig. 5.2 it can be seen that the dataset for one application consists of three parts: data for the personalization machine, data for alloying, data for loading onto the card.
The data for the personalization machine contains information about the application identifier AID, the identifier of the transport key used to transfer confidential data from the personalization data preparation center to the personalization machine, and the like.
The data to be stored (logged) on the personalization machine is a duplicate of some (or all) of the data sent to the microprocessor. These data are determined by the issuer and used by him for various purposes. The logged data can only be the numbers of the personalized cards, but it can be all the data used to personalize the cards, if this data is prepared by a third-party personalization bureau.
Finally, the data for transmission to the microprocessor consists of several Data Grouping, each identified by a Data Grouping Identifier (DGI). Data Grouping (DG) is a key element of the card personalization process. In general, each application line file entry should be transferred in one GD. For application data not stored in linear files, specific DGs are also used.
Let's list the requirements and guidelines that should be used when creating data groups.
When personalizing a card application, keys are used that are not related to the keys used in the card application when processing card transactions. The personalization key management system is as follows. The K ENC keys are loaded onto the card at the stage of pre-personalization performed by the IPC supplier before the start of the personalization process ,
Tab. 5.1. Personalization data example
The end of the table. 5.1
Kmds, K DEK, which are derived from the KMS key. The KMC key is the 16-byte issuer key passed to the card supplier by the issuer.
The KMC key is identified by the KMC 1D key identifier . The identifier can be the identifier of the financial institution - the card issuer and the BIN number of the card. Each key corresponds to a 10-byte KEYDATA parameter, the structure of which is shown in Table. 5.2.
The K ENC key is output using the KMC key and the KEYDATA parameter using the following formula:
K ENC = DES3 (KMC) [Z || 'F0' || '01 '] || DES3 (KMC) [Z ||' 0F '|| '01'],
where Z is the least significant six bytes of the KEYDATA element.
The K ENC key is used to generate the SKU RNC session key used to generate / check the cryptogram of the card application and the cryptogram of the personalization machine, as well as to encrypt the data field of the STORE DATA command in the CBC mode, if required by the security level set in the EXTERNAL AUTHENTICATE command.
The K MAC key is displayed using the KMC key and the KEYDATA parameter using the following formula:
K MAC = DES3 (KMC) [Z || 'F0' || '02 '] || DES3 (KMC) [Z ||' 0F '|| '02'].
The K МАС key is used to generate the SKU MAC session key used by the card to calculate / check the Message Authentication Code (МАС) value for the EXTERNAL AUTHENTICATE command (always) and STORE DATA commands (if required by the security level set in the EXTERNAL AUTHENTICATE command). The MAC value used to ensure the integrity of the command data will be denoted C-MAC (Command MAC). The C-MAC value, in contrast to the MAC value used in the commands of the Issuer Script Processing procedure, has a size of 8 bytes.
The K DEK key is output using the KMC key and the KEYDATA parameter using the following formula:
K DEK = DES3 (KMC) [Z11 'F0' 11 '03'] 11DES3 (KMC) [Z11 '0F' 11 '03'].
The K DEK key is used to generate the SKU DEK session key , which is used by the card application to decrypt in ECB mode the secret data received by the card in the STORE DATA command.
Session keys SKU ENC, SKU MAC and SKU DEK are double-length SDES keys and are calculated using the corresponding card keys and the Triple DES algorithm applied in the CBC encryption mode to the data shown in Table. 5.3.
Tab. 5.3. Data for displaying session keys
Table 5.3 SC (Sequence Counter) denotes the card counter value returned to the personalization machine in response to the INITIALIZE UPDATE command. The SC counter is incremented by 1 each time the card application establishes a new secure connection with an external program.
A card that complies with the EMV Card Personalization Specification must support the following set of commands:
Rice. 5.3. The flow of commands in the card personalization process
After the initial card insertion, performed by the personalization machine, the card responds with an ATR (Answer To Reset) bit string, which defines the protocol and data exchange rate between the card and the personalization machine. Next, the personalization machine sends a SELECT command to the card specifying the name of the AID application to be personalized (this means that the FCI Template for this application has already been created (possibly not completely personalized) at the stage of pre-personalizing the card). The SELECT command has a standard structure (see section 3.10).
Next, the personalization machine sends the INITIALIZE UPDATE command to the card, the structure of which is shown in Table. 5.4.
The structure of the response block to the INITIALIZE UPDATE command is shown in Table. 5.5.
The cryptogram of the card is computed according to Algorithm 1 of ISO 9797-1 for MAC computation described in 3.11.3 and applied to the 16 byte R term 11 SC 11 Rc ARD sequence . As algog tc
Tab. 5.4. INITIALIZE UPDATE Command Structure
Tab. 5.5. INITIALIZE UPDATE Response Structure
The ALG encryption rhythm in Algorithm 1 of ISO 9797-1 uses Triple DES. The personalization engine verifies the cryptogram by recalculating the MAC value on the data R term II SC || R < ; ard . If the cryptograms match, the card authentication is considered successful. Otherwise, authentication is considered failed and the card application personalization process is complete.
After receiving a response to the INITIALIZE UPDATE command, the personalization engine generates an EXTERNAL AUTHENTICATE command, the structure of which is shown in Table. 5.6.
The cryptogram of the personalization machine is computed according to Algorithm 1 of ISO 9797-1 for computing the MAC described in 3.11.3 and applied to the SC || Rc ARD || R term is 16 bytes in size. The ALG encryption algorithm in Algorithm 1 of ISO 9797-1 uses Triple DES. The card should check the cryptogram by recalculating the MAC value on the SC data || Rc ARD || R term . If the cryptograms match, the authentication of the personalization machine is considered completed successfully. 5.6. EXTERNAL AUTHENTICATE Command Structure
but. Otherwise, authentication is considered failed and the card application personalization process is complete.
The C-MAC value is calculated in accordance with Algorithm 3 of ISO 9797-1 for the MAC calculation described in clause 3.11.3. DES is used as the ALG encryption algorithm in Algorithm 3 of ISO 9797-1. The MAC calculation algorithm is applied to a sequence that includes a modified command header and a command data field (see section 5.4.2 of the EMV Card Personalization Specification). The session key SKU MAK is used to calculate С-МАС .
Parameter P1, which determines the Security Level for the card personalization session, is set in accordance with Table. 5.7.
Tab. 5.7. Defining the security level for the card personalization session
If the security level requires only the generation of MAC, then the C-MAC value is calculated for all STORE DATA commands of this personalization session.
If the security level corresponds to the "Encryption and MAC" case, then for all STORE DATA commands of this personalization session, the command data field is encrypted using the SKU RNC session key and the Triple DES algorithm used in the CBC mode. In addition, after this from to r 1
MasterCard to A
using the session key SKU MAK for all commands, the value of the C-МАС value is calculated.
If the security level corresponds to the case "No encryption and MAC", then the command does not use data encryption and data integrity.
The most commonly used command in the card personalization session is the STORE DATA command, the structure of which is shown in Table. 5.8.
Tab. 5.8. STORE DATA command structure
Note that the data field of the STORE DATA command contains a set of multiple DGs. Each DG is transmitted using the STORE DATA command. In this case, one STORE DATA command can be used to transfer several DGs to the card.
In the special field ENC of the data coming from the personalization data preparation center, the DGI values of those DGs whose data must be encrypted before they are transferred to the card, as well as the identifiers of the transport keys used to encrypt this data when they are transferred from the data preparation center to the machine are indicated personalization. The data specified in the ENC field must be decrypted in the personalization machine on the corresponding transport key and then encrypted on the SKU DEK session key . To encrypt the data of the State Duma, the Triple DES algorithm is used in the ECB mode. Moreover, if the security level "Encryption and MAC" is used for this session, then after some data is closed on the SKU DEK key , the entire field of the STORE DATA command will be closed on the keyth SKU FNC .
Parameter P1 of the STORE DATA command is defined in table. 5.9.
If the personalization machine needs to indicate that the GD is the last for the selected application, then this GD is assigned an identifier. 5.9. Structure of P1 parameter of STORE DATA command
Cator DGI equal to '7FFF'h. A data group with this DGI value must be placed in the last STORE DATA command.
Note that if the DGI value is present in the ENC field of the data coming from the DPC, even if bits 7 and 6 of the P1 parameter are O (the DG is not encrypted), the DG data with the specified DGI indicator value must be encrypted.
A set of transport keys is used to transfer confidential data from the CPD to the personalization machine. The reason why a certain set of transport keys is used instead of one key is to increase the security of information exchange. Transport keys are usually divided into keys used to encrypt PIN blocks (PIN Encryption Key), other keys (Key Encryption Key) and other data (Data Encryption Key).
Note that the CPS standard (section 2.1.2 EMV Card Personalization Specification) considers the case when the card keys for the asymmetric encryption algorithm are generated by the issuer, not the card. Obviously, in the second case, the security of the scheme is higher, since in this case the private keys of the card for the asymmetric encryption algorithm are not known to anyone (private keys are stored only on the card).
The CPC generates a public key certificate for the card used to calculate the cryptogram, as well as a public key certificate for the card used to encrypt the PIN, if the card supports the Enciphered Offline PIN cardholder verification method and uses a separate key for this. Certificates are generated using RSA encryption with the card issuer's private key and downloaded to the card.
The card is also loaded in encrypted form with the corresponding private asymmetric keys of the card application.
In turn, the card issuer receives a certificate of its public key from the certification center of the payment system. The issuer's public key certificate, together with the details of the used public key of the system's certification authority, is stored on the card.
The CPD also prepares symmetric card keys intended for:
If the card uses the offline PIN-code verification method to verify its holder, the CPD transmits the encrypted PIN-code value to the personalization machine. The PIN value is encrypted using the 3DES algorithm and the PIN Encryption Key. On the controller of the personalization machine, the PIN-code value is re-encrypted using the 3DES algorithm and the SKU DEK key and transmitted to the card.
The DPC also prepares and transfers data objects to the card for storage Application Primary Account Number, PAN Sequence Number, Application Effective Date, Application Expiration Date, Application Version Number, Application Interchange Profile, Application File Locator, Static Data to be Authenticated and Data Authentication Code (if card directly supports static authentication method), SDA Tag List, Application Usage Control, Issuer Action Code, CDOL1, CDOL2, DDOL, TDOL, Card Issuer Action Code, CVM List (if the card supports verification of its holder), PIN Try Limit (if the card supports offline verification of the PIN value), limits for offline transactions, etc. The purpose of the listed data objects was explained earlier.
Today on the market there are offers for the supply of personalization machines from Datacard, NBS and others. However, the undisputed world leader here is Datacard, which, according to various estimates, accounts for about 85% of the market for card personalization devices. In Russia, almost all EMV cards are personalized on the machines of this company. To personalize the IPC, both desktop embossers DC150, DC280, DC450 and conveyor-type devices DC500, DC7000, DC9000, MAXSYS, MX2000, MX6000 from DataCard can be used.
Complexes DC500, DC7000 and DC9000 are discontinued today. Up to two smart card personalization modules can be installed on DC7000 and DC9000 complexes, each of which contains up to seven IC initialization stations (for DC9000 machines, there are IPC personalization modules containing up to 11 stations). The presence of several programming stations in each personalization module is due to the fact that personalization of one card application can take up to 15 seconds, i.e. the productivity of the entire complex in this case is not higher than 240 cards per hour, since the productivity of the personalization machine is determined by the speed of the slowest module in its composition. Typically, this is a color image printing module (300-500 cards per hour) or, if this module is not used, an embossing module (500-700 cards per hour). This implies,
New conveyor-type personalization machines from DataCard - MAXSYS, MX2000, MX6000 - depending on the model, can have from 2 to 4 microprocessor personalization modules, each of which contains up to 11 stations.
Chapter 6
With the advent of the EMV Card Personalization Specification, card personalization procedures and commands, as well as the interfaces between the Personalization Data Preparation Center (CPC) and the personalization machine, personalization machine, and card have been largely standardized. Moreover, following the CPS standard, its projections appeared on the most common EMV applications, including VSDC, M / Chip, CPA applications. These projections, being a special case of the CPS standard, offer specific implementations for organizing the recording of data objects of the listed applications on the card.
Standardizing the card personalization process does not mean, of course, that all IPC vendors support the EMV Card Personalization Specification for all their products. At the same time, on many cards, including static ones, one or another CPS projection is supported.
The CPS standard is actively supported in cards using the GlobalPlatform / Java Card. This is understandable, since in the part of the interface between the personalization machine and the card, the specifications define only the procedure for mutual authentication of the card and the personalization equipment program, as well as the secure transmission of card personalization data. It is assumed that the creation of files and records in which the transmitted data will be stored on the card (the so-called card layout) remains outside the standard, again depends on the selected card microcircuit and is usually performed during the pre-personalization phase of the card. Since the GlobalPlatform environment has at its disposal mechanisms for loading and installing executable application modules, creating / deleting files, creating records, etc., as well as in connection with the fact
Moreover, the CPS specification is clearly influenced by the GlobalPlatform Card Specification (GPCS). In fact, the procedure for mutual authentication of the card application and the personalization machine, the derivation of the session personalization keys, ensuring the confidentiality and integrity of data circulating between the card and the personalization equipment are written off from the description of the Secure Channel Protocol (SCP02) in the GPCS specification.
The personalization data preparation process is performed in the back office system of the issuer or third party personalization bureau. This process can use data stored on different hosts of the bank. Its purpose is to prepare data to be loaded into the IPC.
Some of the prepared data may be common to a set of cards. Some data changes from card to card. Part of the data can be transmitted to the card in clear text. At the same time, there is data (keys, PIN codes), which must be encrypted during the entire personalization process.
The prepared data in a specific format is transferred to the personalization machine, which acts in accordance with the instructions defined for it. To implement the EMV Card Personalization Specification, the personalization engine must support it.
A personalization engine must have access to a cryptographic processor (SAM or HSM (Hardware Security Module)) to support secure interfaces with the personalization data center and card. To protect data, these interfaces use data encryption and generation / verification of MAC (Message Authentication Code) codes, which ensure the integrity of the transmitted information and the authentication of its source.
The personalization machine transfers the data prepared for it to the card application for storing it in the EEPROM memory. To do this, the card application must support the commands received from the personalization machine. In other words, the card application must also support the EMV Card Personalization Specification.
Of great importance in the EMV Card Personalization Specification is the uniform format of the data circulating between the DCP, machine personalization, and the card. Several physical modules of the personalization machine take part in the card personalization process (for example, embossing modules, magnetic stripe coding, data entry into a microprocessor), each of which requires its own data set. The data intended for a specific module of the personalization machine is identified in the general personalization data set by the identifier of that module's Module Identifier Code (MIC).
There is a MIC identifier that identifies the microprocessor personalization module. The value of this MIC is preset by agreement between the JRC and the personalization machine. In fig. 5.1 shows the general data structure for card personalization. In this case, the module with the MIC2 code is responsible for personalizing the microprocessor.
| Data length for MIC 1 | Data length for MIC 2 | Data length for MIC 3 | |||||||
| MIC 1 | Data for MIC 1 | MIC 2 U | Data for MIC 2 | MIC3 | Data for MIC 3 | ||||
| .Header (header) | Data for Appendix 1 | Data for Appendix 2 | Data for Appendix 3 |
Rice. 5.1. General structure of personalization data
The IPC can be multi-application, and the EMV Card Personalization Specification provides for the ability to personalize multiple card applications at once. The data structure for each card application is shown in Fig. 5.2.
Title | | |
(header) Data for Application 1 Data for Application 2 Data for Application 3
Data for the car. Data . Data,
personalizations for logging sent to the application
Rice. 5.2. Data for personalizing the card application
From fig. 5.2 it can be seen that the dataset for one application consists of three parts: data for the personalization machine, data for alloying, data for loading onto the card.
The data for the personalization machine contains information about the application identifier AID, the identifier of the transport key used to transfer confidential data from the personalization data preparation center to the personalization machine, and the like.
The data to be stored (logged) on the personalization machine is a duplicate of some (or all) of the data sent to the microprocessor. These data are determined by the issuer and used by him for various purposes. The logged data can only be the numbers of the personalized cards, but it can be all the data used to personalize the cards, if this data is prepared by a third-party personalization bureau.
Finally, the data for transmission to the microprocessor consists of several Data Grouping, each identified by a Data Grouping Identifier (DGI). Data Grouping (DG) is a key element of the card personalization process. In general, each application line file entry should be transferred in one GD. For application data not stored in linear files, specific DGs are also used.
Let's list the requirements and guidelines that should be used when creating data groups.
- 1. Any data transmitted by the IPC must belong to one DG.
- 2. For ease of management of the personalization process, each line file record should be transferred in one GD. Conversely, if the GD contains records of linear files, then the GD contains exactly one such record.
- 3. When defining a DGI for a DG containing a linear file record, it is recommended to use the SFI linear file name and record number.
- 4. Some application data (for example, application counters and limits, internal card parameters, keys, etc.) are not stored in linear files. It is recommended to place such data in separate DGs containing data elements of the same type in terms of their purpose.
- 5. If the FCI Template of the application contains data that requires personalization, then such data is placed in a separate GD (separate GDs are created for the FCI Templates of different applications).
- 6. DES keys must be transferred to a DG containing only DES keys.
- 7. It is recommended to place fixed-length data items in one DG and variable-length data items in another.
- 8. It is recommended that the size of data in one DG should not exceed 237 bytes.
- 9. The DGI value '9F66' is reserved for transferring the Card Production Life Cycle Data Item (CPLC) to the card.
- 10. DGI values' 7FF0 'to 7FFE' should not be used to personalize the EMV application and are reserved for DGs containing data not used in any card application.
- 11. The number of GDs should be minimized in order to increase the productivity of the card personalization complex.
- 12. If GD data is to be encrypted and the group data elements are DES keys or a PIN block, then data encryption is performed without adding service characters (padding). In other cases, encryption uses an extra '80'h byte followed by' 00'h bytes. The number of '00'h bytes varies from 0 to 7 and is determined by the fact that the number of bytes of the encrypted part of the DG must be a multiple of 8.
- 13. The Key Check Value for any DES key is calculated by applying the 3DES algorithm in ECB mode to a sequence of 8 bytes like '00'h.
- 14. It is recommended that the data preparation system generate a PIN block in accordance with ISO 9564-1 (format 1). If necessary, the card can reformat the PIN block to the format it uses.
- 15. The first two or three bytes of each line file record consists of Tag '70' and the record's data length field.
- 16. Data transmitted to the DG with the DGI identifier, the leftmost byte of which is '80'h or' 8F'h, must be encrypted. At the same time, encrypted data can be located in other GDs.
When personalizing a card application, keys are used that are not related to the keys used in the card application when processing card transactions. The personalization key management system is as follows. The K ENC keys are loaded onto the card at the stage of pre-personalization performed by the IPC supplier before the start of the personalization process ,
Tab. 5.1. Personalization data example
| Data Group Identifier (DGI) | Tag | Data element | Length of Data Element |
| '0101' | |||
| '57' | Track 2 Equivalent Data | 16 | |
| '5F28' | Issuer Country Code | 2 | |
| '5F20' | Cardholder Name | 26 | |
| '9FOB' | Cardholder Name Extended | thirty | |
| Total Record Length | 87 | ||
| '0201' | |||
| '8F' | Certificate Authority Public Key Index | 1 | |
| '90' | Issuer Public Key (IPK) Certificate | 144 | |
| '92' | IPK Remainder | 36 | |
| Total Record Length | 188 | ||
| '0202' | |||
| '9F32' | IPK Exponent | 1 | |
| '9F2E' | ICC PIN Encipherment | 1 | |
| '9F47' | ICC Public Key Exponent | 1 | |
| '93' | Signed Static Application Data | 144 | |
| Total Record Length | 159 | ||
| '0203' | |||
| '9F46' | ICC Public Key Certificate | 144 | |
| '9F48' | ICC Public Key Remainder | 42 | |
| Total Record Length | 193 | ||
| '0204' | |||
| '9F2D' | ICC PIN Encipherment Public Key Certificate | 144 | |
| '9F2F' | ICC PIN Encipherment Public Key Remainder | 42 | |
| Total Record Length | 193 | ||
| '0301' | |||
| '5F25' | Application Effective Date | 3 | |
| '5F24' | Application Expiration Date | 3 | |
| '9F07' | Application Usage Control | 2 | |
| '5A' | Application Primary Account Number (PAN) | 12 | |
| '5F34' | Application PAN Sequence Number | 2 | |
| '8E' | Cardholder Verification Method (CVM) List | eighteen | |
| '9F0D' | Issuer Action Code (IAC) Default | 5 | |
| '9F0E' | IAC Denial | 5 | |
| '9F0F' | IAC Online | 5 | |
| '8C' | CDOL1 | 33 | |
| '8D' | CDOL2 | 12 |
The end of the table. 5.1
| Total Record Length | 132 | ||
| '0203' | |||
| '9F4A' | SDA Tag List | 1 | |
| '9F49' | DDOL | 4 | |
| '9F44' | Application Currency Exponent | 1 | |
| '9F42' | Application Currency Code | 2 | |
| '5F30' | Service Code | 2 | |
| '9F08' | Application Version Number | 2 | |
| Total Record Length | thirty |
Kmds, K DEK, which are derived from the KMS key. The KMC key is the 16-byte issuer key passed to the card supplier by the issuer.
The KMC key is identified by the KMC 1D key identifier . The identifier can be the identifier of the financial institution - the card issuer and the BIN number of the card. Each key corresponds to a 10-byte KEYDATA parameter, the structure of which is shown in Table. 5.2.
| Tab. 5.2. KEYDATA structure | |
| Field | Size, bytes |
| KMC ID | 6 |
| Chip Serial Number | 4 |
The K ENC key is output using the KMC key and the KEYDATA parameter using the following formula:
K ENC = DES3 (KMC) [Z || 'F0' || '01 '] || DES3 (KMC) [Z ||' 0F '|| '01'],
where Z is the least significant six bytes of the KEYDATA element.
The K ENC key is used to generate the SKU RNC session key used to generate / check the cryptogram of the card application and the cryptogram of the personalization machine, as well as to encrypt the data field of the STORE DATA command in the CBC mode, if required by the security level set in the EXTERNAL AUTHENTICATE command.
The K MAC key is displayed using the KMC key and the KEYDATA parameter using the following formula:
K MAC = DES3 (KMC) [Z || 'F0' || '02 '] || DES3 (KMC) [Z ||' 0F '|| '02'].
The K МАС key is used to generate the SKU MAC session key used by the card to calculate / check the Message Authentication Code (МАС) value for the EXTERNAL AUTHENTICATE command (always) and STORE DATA commands (if required by the security level set in the EXTERNAL AUTHENTICATE command). The MAC value used to ensure the integrity of the command data will be denoted C-MAC (Command MAC). The C-MAC value, in contrast to the MAC value used in the commands of the Issuer Script Processing procedure, has a size of 8 bytes.
The K DEK key is output using the KMC key and the KEYDATA parameter using the following formula:
K DEK = DES3 (KMC) [Z11 'F0' 11 '03'] 11DES3 (KMC) [Z11 '0F' 11 '03'].
The K DEK key is used to generate the SKU DEK session key , which is used by the card application to decrypt in ECB mode the secret data received by the card in the STORE DATA command.
Session keys SKU ENC, SKU MAC and SKU DEK are double-length SDES keys and are calculated using the corresponding card keys and the Triple DES algorithm applied in the CBC encryption mode to the data shown in Table. 5.3.
Tab. 5.3. Data for displaying session keys
| Card key | Session key | Data encrypted in SHS mode |
| Kenc | SKU ENC | '0182' II SC II '000000000000000000000000' |
| Kmac | SKU MAC | '0101' II SC II '000000000000000000000000' |
| Kdek | SKU DEK | '0181' II SC II '000000000000000000000000' |
Table 5.3 SC (Sequence Counter) denotes the card counter value returned to the personalization machine in response to the INITIALIZE UPDATE command. The SC counter is incremented by 1 each time the card application establishes a new secure connection with an external program.
A card that complies with the EMV Card Personalization Specification must support the following set of commands:
- SELECT;
- INITIALIZE UPDATE;
- EXTERNAL AUTHENTICATE;
- STORE DATA.
Rice. 5.3. The flow of commands in the card personalization process
After the initial card insertion, performed by the personalization machine, the card responds with an ATR (Answer To Reset) bit string, which defines the protocol and data exchange rate between the card and the personalization machine. Next, the personalization machine sends a SELECT command to the card specifying the name of the AID application to be personalized (this means that the FCI Template for this application has already been created (possibly not completely personalized) at the stage of pre-personalizing the card). The SELECT command has a standard structure (see section 3.10).
Next, the personalization machine sends the INITIALIZE UPDATE command to the card, the structure of which is shown in Table. 5.4.
The structure of the response block to the INITIALIZE UPDATE command is shown in Table. 5.5.
The cryptogram of the card is computed according to Algorithm 1 of ISO 9797-1 for MAC computation described in 3.11.3 and applied to the 16 byte R term 11 SC 11 Rc ARD sequence . As algog tc
Tab. 5.4. INITIALIZE UPDATE Command Structure
| Code | Meaning | Size, bytes |
| CLA | '80'h | 1 |
| INS | '50'h | 1 |
| Pl | '00'h (' 00'h is a typical value, but the parameter can take other values) | 1 |
| P2 | '00'h | 1 |
| Lc | '08'h | 1 |
| Data | Random number R TEMP | eight |
| Le | '00'h | 1 |
Tab. 5.5. INITIALIZE UPDATE Response Structure
| Response block field | Size, bytes |
| KEYDATA | ten |
| KMS key version number | 1 |
| Protocol ID (ALGSCP = 'O2') | 1 |
| Card counter (SC) | 2 |
| Random card number R <- ard | 6 |
| Cryptogram card | eight |
| SW1SW2 | 2 |
The ALG encryption rhythm in Algorithm 1 of ISO 9797-1 uses Triple DES. The personalization engine verifies the cryptogram by recalculating the MAC value on the data R term II SC || R < ; ard . If the cryptograms match, the card authentication is considered successful. Otherwise, authentication is considered failed and the card application personalization process is complete.
After receiving a response to the INITIALIZE UPDATE command, the personalization engine generates an EXTERNAL AUTHENTICATE command, the structure of which is shown in Table. 5.6.
The cryptogram of the personalization machine is computed according to Algorithm 1 of ISO 9797-1 for computing the MAC described in 3.11.3 and applied to the SC || Rc ARD || R term is 16 bytes in size. The ALG encryption algorithm in Algorithm 1 of ISO 9797-1 uses Triple DES. The card should check the cryptogram by recalculating the MAC value on the SC data || Rc ARD || R term . If the cryptograms match, the authentication of the personalization machine is considered completed successfully. 5.6. EXTERNAL AUTHENTICATE Command Structure
| Code | Meaning | Size, bytes |
| CLA | '84'h | 1 |
| INS | '82'h | 1 |
| Pl | Security Level (see table 5.7) | 1 |
| P2 | '00'h | 1 |
| Lc | '10'h | 1 |
| Data | The cryptogram of the personalization machine | eight |
| C-MAC | eight |
but. Otherwise, authentication is considered failed and the card application personalization process is complete.
The C-MAC value is calculated in accordance with Algorithm 3 of ISO 9797-1 for the MAC calculation described in clause 3.11.3. DES is used as the ALG encryption algorithm in Algorithm 3 of ISO 9797-1. The MAC calculation algorithm is applied to a sequence that includes a modified command header and a command data field (see section 5.4.2 of the EMV Card Personalization Specification). The session key SKU MAK is used to calculate С-МАС .
Parameter P1, which determines the Security Level for the card personalization session, is set in accordance with Table. 5.7.
Tab. 5.7. Defining the security level for the card personalization session
| B8 | B7 | B6 | B5 | B4 | B3 | B2 | NS | Meaning |
| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | Encryption and MAC |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | MAC |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Lack of encryption and MAC |
If the security level requires only the generation of MAC, then the C-MAC value is calculated for all STORE DATA commands of this personalization session.
If the security level corresponds to the "Encryption and MAC" case, then for all STORE DATA commands of this personalization session, the command data field is encrypted using the SKU RNC session key and the Triple DES algorithm used in the CBC mode. In addition, after this from to r 1
MasterCard to A
using the session key SKU MAK for all commands, the value of the C-МАС value is calculated.
If the security level corresponds to the case "No encryption and MAC", then the command does not use data encryption and data integrity.
The most commonly used command in the card personalization session is the STORE DATA command, the structure of which is shown in Table. 5.8.
Tab. 5.8. STORE DATA command structure
| Code | Meaning | Size, bytes |
| CLA | '80'h or' 84'h | 1 |
| INS | 'E2'h | 1 |
| Pl | see table. 5.9 | 1 |
| P2 | Sequence Number | 1 |
| Lc | Command data field length | 1 or 3 |
| Data | Sequence of groups of data loaded onto the card | variable |
| С-МАС, if CLA = '84'h | eight |
Note that the data field of the STORE DATA command contains a set of multiple DGs. Each DG is transmitted using the STORE DATA command. In this case, one STORE DATA command can be used to transfer several DGs to the card.
In the special field ENC of the data coming from the personalization data preparation center, the DGI values of those DGs whose data must be encrypted before they are transferred to the card, as well as the identifiers of the transport keys used to encrypt this data when they are transferred from the data preparation center to the machine are indicated personalization. The data specified in the ENC field must be decrypted in the personalization machine on the corresponding transport key and then encrypted on the SKU DEK session key . To encrypt the data of the State Duma, the Triple DES algorithm is used in the ECB mode. Moreover, if the security level "Encryption and MAC" is used for this session, then after some data is closed on the SKU DEK key , the entire field of the STORE DATA command will be closed on the keyth SKU FNC .
Parameter P1 of the STORE DATA command is defined in table. 5.9.
If the personalization machine needs to indicate that the GD is the last for the selected application, then this GD is assigned an identifier. 5.9. Structure of P1 parameter of STORE DATA command
| B8 | B7 | B6 | B5 | m | B3 | B2 | NS | Meaning |
| X | Last STORE DATA indicator | |||||||
| 1 | The last STORE DATA command | |||||||
| 0 | Not the last STORE DATA command | |||||||
| X | X | Encryption indicators | ||||||
| 1 | 1 | All DGs are encrypted | ||||||
| 0 | 0 | DGs are not encrypted | ||||||
| 0 | 1 | Some GDs are encrypted | ||||||
| 1 | 0 | Reserved for use | ||||||
| X | X | X | X | X | Reserved for use |
Cator DGI equal to '7FFF'h. A data group with this DGI value must be placed in the last STORE DATA command.
Note that if the DGI value is present in the ENC field of the data coming from the DPC, even if bits 7 and 6 of the P1 parameter are O (the DG is not encrypted), the DG data with the specified DGI indicator value must be encrypted.
A set of transport keys is used to transfer confidential data from the CPD to the personalization machine. The reason why a certain set of transport keys is used instead of one key is to increase the security of information exchange. Transport keys are usually divided into keys used to encrypt PIN blocks (PIN Encryption Key), other keys (Key Encryption Key) and other data (Data Encryption Key).
Note that the CPS standard (section 2.1.2 EMV Card Personalization Specification) considers the case when the card keys for the asymmetric encryption algorithm are generated by the issuer, not the card. Obviously, in the second case, the security of the scheme is higher, since in this case the private keys of the card for the asymmetric encryption algorithm are not known to anyone (private keys are stored only on the card).
The CPC generates a public key certificate for the card used to calculate the cryptogram, as well as a public key certificate for the card used to encrypt the PIN, if the card supports the Enciphered Offline PIN cardholder verification method and uses a separate key for this. Certificates are generated using RSA encryption with the card issuer's private key and downloaded to the card.
The card is also loaded in encrypted form with the corresponding private asymmetric keys of the card application.
In turn, the card issuer receives a certificate of its public key from the certification center of the payment system. The issuer's public key certificate, together with the details of the used public key of the system's certification authority, is stored on the card.
The CPD also prepares symmetric card keys intended for:
- calculating the cryptogram of the transaction;
- ensuring integrity;
- ensuring confidentiality of classified data;
- to calculate the value of ICC Dynamic Number in the case of a card that supports dynamic authentication and a mechanism for the terminal to check the fact of card authentication.
If the card uses the offline PIN-code verification method to verify its holder, the CPD transmits the encrypted PIN-code value to the personalization machine. The PIN value is encrypted using the 3DES algorithm and the PIN Encryption Key. On the controller of the personalization machine, the PIN-code value is re-encrypted using the 3DES algorithm and the SKU DEK key and transmitted to the card.
The DPC also prepares and transfers data objects to the card for storage Application Primary Account Number, PAN Sequence Number, Application Effective Date, Application Expiration Date, Application Version Number, Application Interchange Profile, Application File Locator, Static Data to be Authenticated and Data Authentication Code (if card directly supports static authentication method), SDA Tag List, Application Usage Control, Issuer Action Code, CDOL1, CDOL2, DDOL, TDOL, Card Issuer Action Code, CVM List (if the card supports verification of its holder), PIN Try Limit (if the card supports offline verification of the PIN value), limits for offline transactions, etc. The purpose of the listed data objects was explained earlier.
Today on the market there are offers for the supply of personalization machines from Datacard, NBS and others. However, the undisputed world leader here is Datacard, which, according to various estimates, accounts for about 85% of the market for card personalization devices. In Russia, almost all EMV cards are personalized on the machines of this company. To personalize the IPC, both desktop embossers DC150, DC280, DC450 and conveyor-type devices DC500, DC7000, DC9000, MAXSYS, MX2000, MX6000 from DataCard can be used.
Complexes DC500, DC7000 and DC9000 are discontinued today. Up to two smart card personalization modules can be installed on DC7000 and DC9000 complexes, each of which contains up to seven IC initialization stations (for DC9000 machines, there are IPC personalization modules containing up to 11 stations). The presence of several programming stations in each personalization module is due to the fact that personalization of one card application can take up to 15 seconds, i.e. the productivity of the entire complex in this case is not higher than 240 cards per hour, since the productivity of the personalization machine is determined by the speed of the slowest module in its composition. Typically, this is a color image printing module (300-500 cards per hour) or, if this module is not used, an embossing module (500-700 cards per hour). This implies,
New conveyor-type personalization machines from DataCard - MAXSYS, MX2000, MX6000 - depending on the model, can have from 2 to 4 microprocessor personalization modules, each of which contains up to 11 stations.
Chapter 6
