This section deals with the issues of personalization, first of all, of microprocessor bank cards of international payment systems, although the described approaches and software solutions can easily be extended (which we have already done in a number of cases) not only to cards of various local payment systems, but also to identification cards with a chip (for example, driver’s licenses, party tickets, insurance policies), for SIM cards for mobile phones, transport and “petrol” cards, etc.
1. Background of the issue
How long ago was that… Probably, last year and this year are significant for the ten-year anniversaries of the first payment systems on smart chip cards. At that time, there were still disputes whether memory cards could be attributed to smart cards or not, the choice of a card was often determined not by its functionality and security, but only by the price and ease of programming the chip. But such systems were in demand and appeared literally by the dozens. There are no others. Sometimes to the deepest regret. So, for example, the Poliscart system, which the authors were directly involved in creating, ceased to exist. But it was almost the first system in the world with the real use of microprocessor cards with encryption, with off-line card servicing at ATMs. But other “peers” – the Savings Card, the Golden Crown, the Accord are in good health and flourishing with might and main.
Millions of microprocessor cards are issued by existing and existing payment systems. So, somehow all these millions of cards were personalized. But even with a big stretch, all the personalization methods used for these purposes cannot be called “industrial”. Very often, a number was simply applied to the card, then the card was inserted into the reader or terminal by the operator’s hands. That’s it, personalization is over. As one esteemed colleague said, “why do I need an embosser, I’d rather hire two dozen students, let them work at night, and not walk…”. And from the point of view of the level of automation, productivity, and the use of advanced technologies, a paradox finally arose – in the field of personalization, “at the very forefront” smart cards were significantly inferior to traditional, well-known since “immemorial” times, that is, for several decades, cards with a magnetic stripe. However, the issue of these cards did not amount to millions, but if we take tens of billions of pieces “on a global scale”. After all, the technologies of personalization of magnetic cards were developed thanks, among other things, to such giants as Visa and Mastercard.
New times – new problems. Visa and Mastercard took their time. But there was a development of international ISO standards for cards with a microprocessor, general specifications – EMV specifications, own specifications of payment systems – VSDC (Visa) and M/Chip (Mastercard). At the moment when it became clear that the transition of these payment systems to microprocessor cards was inevitable, the task arose to extend the versatility and adaptability of personalization of magnetic cards to cards with a microprocessor. And this task turned out to be very, very difficult. In particular, because if the “communication” of the EMV card and the payment terminal is almost completely specified, then there are still no strict completed requirements for how these cards should be personalized.
2. What exactly is it about?
According to the payment systems themselves, the most difficult thing in the so-called EMV migration is personalization. And this complex issue, it seems to us, requires a fairly detailed consideration.
The personalization process involves:
• the actual card with the chip,
• personalized device,
• data placed on the card,
• software for managing the entire process.
Thus, first of all, it is necessary to have an idea of the various
EMV cards, how they differ from each other, how they are produced, when and where they are personalized.
It is also necessary to understand how it is necessary to transform the familiar technology of personalization of bank magnetic cards, including how to modernize the existing personalization equipment.
What data is placed on the card, how to prepare them, how to personalize the cards most efficiently. At the same time, we must proceed from the fact that today we need to personalize some cards, and tomorrow others, today’s circulation is limited to several thousand cards, and tomorrow there will be several hundred thousand of them, which will require the use of completely different equipment in terms of performance. And from these points of view, the software should have high adaptive qualities. In addition, it is desirable to have a tool that allows you to check whether the cards are personalized correctly, make sure that the data recorded in the chip corresponds to the original ones, see how the card behaves in a dialogue with the terminal device.
3. Functional and technological types of cards
Cards that meet the EMV specification (EMV stands for Europay-Mastercard-Visa) differ from other microprocessor-based payment cards (such as, for example, “electronic wallets”) in that they strictly regulate the sequence of joint functioning with receiving devices (terminals). This sequence (some steps are optional and can be omitted) consists of the following steps:
• Application selection (Select command). The terminal asks the card about which applications it supports (for example, Cirrus and local), and if there are matches with the applications that the terminal itself supports, one of them is selected.
• Terminal request for basic information about the application (Get Processing Option command). The card provides basic information about the application, in particular, what functionality it supports and the data storage structure of the selected application.
• Reading application data (Read Record command). Based on the information about the structure of the data files obtained in the previous step, the terminal reads this data.
• Data Authentication. The terminal in the off-line mode checks that the data read from the card is true and has not been previously tampered with or illegally corrected. There are the following authentication methods: static (SDA), dynamic (DDA) and clone-improvement of dynamic– combined (CDA).
Somewhat simplistically, the essence of the simplest, static, authentication is as follows. In the process of issuing cards, the issuing bank creates a pair of asymmetric keys. The public key is sent to the Certification Authority of this payment system, from where it is returned with a signed secret key of the system. The public key pair and its certificate are uploaded to the card. At the same time, part of the data (unclassified, but most sensitive according to the system and the issuer) is signed with the secret key of the issuing bank. The payment terminal, knowing the public key of the system, reads the issuer’s public key and its certificate from the card, makes sure that this public key is genuine. And knowing the issuer’s public key and the signed data certificate, he can make sure that they have not changed since the card was issued. Thus, the terminal sequentially checks the truth of the information read from the card twice – first, the truth of the bank’s public key, then the truth of the data.
During the execution of DDA and CDA, the Internal Authentication and Generate Application Cryptogram commands are used. The essence of the algorithm used is that the card data, as well as the “dynamic” characteristics of the transaction, such as the card transaction counter indicator and a random number issued to the card by the terminal, are signed with a secret RSA key, individual for each card. In turn, the public key paired with this key is signed with the issuer’s secret key (similar to how in SDA the issuer’s public key is signed with the payment system’s secret key). The knowledge of the card’s public key confirmed by the trust center (in this case, the issuing bank) is sufficient to verify the correctness of the cryptogram. Thus, in DDA and CDA, as compared to SDA, a third (additional stage) appears. If the SDA first verifies the truth of the issuer’s public key, and then the truth of the “static” data, then in the cases under consideration, after verifying the truth of the issuer’s public key, we are convinced of the truth of the card’s public key, and then of the “static” and “dynamic” card and terminal data.
• Checking the restrictions on the use of the card (Processing Restrictions). The terminal analyzes the information received earlier from the card and determines whether it can be serviced at this time, in this geographical location, at this point of sale (by type), etc.
• Verification of the cardholder’s credentials (Cardholder Verification). Among the data read from the card, there are also parameters that determine how the verification of the person who presented the card is carried out). Along with the methods known for the case of a magnetic card, such as customer signature and PIN verification in on-line mode, off-line PIN verification is also used.
To ensure this procedure, it is first checked whether the the limit of unsuccessful input attempts, and then, if everything is in order, the PIN itself is entered (the Verify command). At the same time, there are 2 input methods – plaintext and encrypted. In the second case, the PIN is encrypted using the card’s public RSA key using a random number issued by the card and decrypted inside the card with a secret key. At the same time, it is possible to use a key pair for DDA, and it is possible to have a separate pair for PIN encryption.
It is clear that both DDA and encrypted PIN have the same requirements for the card, namely support for RSA encryption. Thus, both of these functions are connected – if the card cannot support DDA, there is nothing to talk about PIN encryption, etc.
• Risk verification (Terminal Risk Management). The terminal checks whether the card is on the “black” list, whether the floor limit has been exceeded, whether the transaction value exceeds the limit for servicing the card in off-line mode, whether it is necessary to send an on-line request, etc.
• Terminal decision-making on further actions (Terminal Action Analysis). Based on the operations listed earlier (data authentication, checking usage restrictions, checking off-line PIN, checking risks), the terminal decides how to proceed with the transaction. There are three options – reject the transaction, send the transaction for authorization in on-line mode, accept the authorization off-line.
The terminal offers the card (Generate Application Cryptogram – AC command) calculate the 3DES cryptogram of the transmitted request. In accordance with the listed solutions, there are also three types of cryptograms – Application Authentication Cryptogram (AAC), Authorization Request Cryptogram (ARQC), Transaction Certificate (TC).
• Making a decision on further actions by the card (Card Action Analysis). Based on the behavior logic and parameter values set by the issuer, upon receiving a request for a cryptogram, the card first analyzes the accepted risks itself. At the same time, the solution proposed by the terminal, the card can only be tightened. That is, the decision to send an on-line request can be either confirmed or revised to reject the transaction immediately, the terminal’s decision to accept the transaction in off-line mode can be accepted or replaced with a transaction rejection or on-line request. In accordance with the decision of the card, cryptograms of the AAC, ARQC or TC type are formed.
• Authorization of the card in on-line mode (Online Processing). If the terminal and the card have decided to send an on-line request to the issuer, the terminal transmits the ARQC cryptogram and the card data and transactions used to receive it via communication lines. The issuing bank’s host system verifies the correctness of the cryptogram (using a unique 3-DES card key), makes a decision on this transaction and sends a response with an Authorization Response Cryptogram (ARPC) type cryptogram using the same card key. If the host system supports changing data on the card using scripts, the corresponding script is sent in the response.
If the card supports the issuer’s authentication, the terminal, after receiving the authorization data, sends it to the card using the External Authentication command. At the same time, the card calculates the ARPC value and compares it with the one received from the terminal. If everything fits together, then the answer came from the issuer. If authentication failed, the following transactions will be sent on-line until ARPC comparison is successful. The issuer has the ability to set a parameter on the card that rejects the transaction in case of failed authentication.
• Changing card parameters (Issuer-to-Card Script Processing). The issuer has the opportunity, by sending special scripts in the authorization response, to change the card parameters used when working offline, as well as the PIN and the number of attempts to present it, to block or unblock the application, to block the card. Scritps are signed using a special 3DES key of the card, the new PIN value is encrypted with the same key.
• Completion of the process (Completion). Based on the information received from the issuer, the transaction is either accepted or rejected. Accordingly, TC or AAC cryptograms are formed.
There is a fairly wide range of certified cards on the market that meet the specifications of EMV and international payment systems. Let’s try to classify these sentences. Let’s pay attention to the fact that if the behavior of the card “in battle” (when working with the terminal) is sufficiently described, then the questions (and commands) concerning the personalization of the card are given “at the mercy” of the developers of the chips and the cards themselves.
There are two types of cards – cards with “closed” operating systems (so-called proprietary or native cards) and cards with open OS.
As a rule, operating systems (masks) for native cards are developed by smart card manufacturers themselves, primarily such large ones as Gemlpus, Axalto, Oberthur, G&D. In these cards, the application is a two–level data structure (PC analog files inside a directory). According to their functionality, these cards can be divided into cards with only one EMV application (VSDC or M/Chip Lite) and mgofunctional cards. The advantage of the first is relative cheapness, the second is the possibility of using additional applications.
In the simplest case, it can be an application of the “loyalty” type – an application that provides encouragement to customers when serving in a certain retail network by accruing bonus points (bonuses), the value of which, as a rule, depends on the size of the purchase. In addition, it is possible to create, as it were, additional local EMV applications similar to applications of payment systems (here, however, there may be a problem of settling such a decision with the international payment system itself). Finally, with the help of a number of cards, various “wallet” schemes can be built, including well-known in systems of pre-authorized debit or “gasoline” systems such as “electronic wallet”, as well as various identification systems (pension fund, medical insurance, logical access to corporate networks, physical access, etc.). In the vast majority of the chips of these cards do not have a crypto processor and do not support dynamic authentication and encrypted PIN (although there are exceptions).
Open OS cards include Java cards (or cards close to them that meet the Global Platform specifications) and cards with the Multos operating system. Applications on these cards are programs (applets) that provide a particular functionality. When the applet is activated, it becomes possible to write and store data. The M/Chip Select application owned by Mastercard is implemented on Multos cards. The cards support DDA.
Global Platform cards can be either with DDA and encrypted PIN support (that is, with a crypto processor), or supporting SDA. As a rule, there is only a VSDC applet for these cards, designed for issuing Visa cards. However, some card manufacturers also have applets for Mastercard (M/Chip Lite – SDA cards). Among the certified Global Platform cards with DDA support (the card manufacturers are the copyright holders on the OS – Oberthur, G&D and Gemplus), it is worth noting the JCOPx0 (x=2.3) cards, the copyright holder of which is Visa itself, which transfers the right to make cards for a sufficiently larger number of productions and regulates the final price). Global Platform cards are also interesting from the point of view of personalization. For these cards, there are strict recommendations on the personalization mechanism and the structure of the personalization file (Common Personalization specification). It should be noted that following this specification is convenient and expedient when personalizing any cards.
Cards with open operating systems are multifunctional, moreover, and are intended mainly for multifunctional systems, more expensive than proprietary cards. Some of them are able to safely support the so-called post-issue, when the application is not only activated and/or personalized, but also created after the card is personalized.
4. The life cycle of the card
Before the card gets a “start in life” and is issued to the owner, it goes through three stages sequentially:
• Chip manufacturing;
• Card making;
• Card personalization.
At the stage of manufacturing a chip with a microprocessor , the following basic actions are performed:
• Burning (hard-coding) in the ROM (ROM) of the microprocessor of the operating system of the chip (mask).
• Generation of the microprocessor number and its entry into the chip.
• Generation of the secret key K(IC) (diversification from the mother key M(IC) by chip number) for the microprocessor and its storage in the chip.
• The key K(IC) is used to close access to the card, as well as to transfer secret information to the card at the stage of its manufacture.
• The parent key is transferred to the Card Manufacturer.
At the stage of manufacturing the card itself, after implantation of the chip into the plastic base, the following procedures are carried out:
• The card manufacturer confirms knowledge of the key K(IC), while using the standard authentication procedure, namely, some pseudo-random number received from the card by the pre-personalization device is encrypted and returned to the card for verification.
• The card is initialized (the file system is initiated in the EEPROM – partially at the top level or completely, including card applications).
• A unique serial number of the card is generated and recorded on the chip.
• A KDC secret key is generated (diversification from the KMC parent key by the serial number of the card) and loaded into the chip (sometimes in encrypted form using the K(IC) key or similar).
• The KDC key is used to close access to the card during transportation, as well as when transferring secret information to the card at the stage of its personalization.
• The mother key is transferred to the card’s personalizer.
It should be noted that the general scheme of the production of cards with a microprocessor is given, taking into account the differentiation of responsibility for security. So, in particular, in the described sequence there is one transport key for the chip and the smart card itself. In fact, there may be several such keys – one for authentication of the card and the device, the second for encryption when loading secret parameters (the same keys), the third for encryption of the cryptographic signature when executing particularly important commands (for example, when creating a file structure of the card).
Certain features are available for cards with open and “closed” operating systems. For example, for Java cards and cards with Multos, the card Manufacturer ensures that the corresponding certified applets of international payment systems are loaded into ROM.
Finally, the very process of creating an application (implementing the required file structure) it can occur during card production (prepersonalization, followed by data loading), and at the stage of personalization itself.
Card personalization directly
• The card personalizer confirms knowledge of the KDC key.
• The card is personalized (a file system is created in the EEPROM, data is recorded, secret data is recorded using the KDC key).
5. Data preparation
It is generally accepted to divide the entire process of personalization of smart cards of international payment systems into two stages: data preparation and
personalization itself, including both the personalization of the chip and the traditional personalization of conventional magnetic cards.
The main task of the first stage is to form a data file that is transmitted to the personalization machine, whether it is an embosser or a conveyor device for the subsequent release of the card.
Personalized data
• Customer database is a set of data related to customers – their names and names (Cardholder Name); expiration dates of cards
(Application Effective and Application Expiration Date); number or PAN (Primary Account Number), etc. All these data, as a rule, are available in the back-office system of the issuer of traditional magnetic stripe cards.
• Risk procedures – in this context, a set of parameters that determine organizational decisions that are made by the issuer and relate to the security of the functioning of the system and the level of service provided to the client. Here we mean authentication methods (static, dynamic, a set of authentication data), the possibility of offline authentication, the number of attempts to enter a PIN, limits for offline transactions, etc. At the same time, different customers may be served differently, respectively, and the risk parameters of their cards may differ.
• The key management system is responsible for the cryptographic procedures carried out during card personalization. This includes a list of necessary keys and their areas of application, methods of their generation, generation and placement on the card itself.
To understand the process of data preparation and further the process of loading data into the chip, it is necessary to consider in detail the functions performed by the main participants in the entire process and the information flows arising between them:
A general flowchart of the personalization process.
In this scheme, in the order of events:
• The card manufacturer creates KMC master keys for access to cards during the personalization process and forwards it through secret channels to the Issuing Bank, as well as to the Personalizer. The methods of generating the key and transmitting it may be different. In the future, the card Manufacturer “closes” access to them using KDC keys, which are derived from KMC. When forming the KDC, the serial number of the card is used, which makes each key unique for each card. The personalizer that received the KMC from the issuer will “open” the cards using KDC keys, which will be generated according to the same algorithm that the Manufacturer did it. The encryption algorithms used in these procedures, like most of the others described below, are symmetric, usually based on DES and 3DES, more often one of these two. Of course, if we are not talking about public cryptography used to generate and verify certificates.
• The card manufacturer makes them, “closes” access to them with KDC keys and sends them to the Personalizer.
• The issuing bank’s back-office system generates data for transmission to the Data Preparation Complex (KPD). Some of this data is classified. PIN certainly applies to them, and other values may also apply, depending on the decisions of the bank itself. Secret data is encrypted using the key KEK1 (Key Exchange Key 1), which, in turn, is transmitted to the KPD via some secret channel.
Among the data transmitted by the Issuer to the efficiency, there are also those that will be contained on the surface of the card (in printed or embossed form), as well as on the magnetic strip.
• KPD generates a pair of asymmetric keys of the Issuer and transfers the public keys to the Certification Body of the payment system to create certificates. The certification body signs the issuer’s public key with its secret key and creates certificates that will confirm the “authenticity” of the card issuer in front of the terminal during the authentication process. In addition to the Issuer’s public keys, other data such as the Issuer Identification Number, Certificate Expiration Date, Certificate Serial Number, Hash Algorithm Indicator are also involved in creating certificates. Note that since the process of obtaining certificates is quite lengthy, it can be carried out in advance, even before the production of blank cards. The generated certificate is forwarded to the KPD.
• The KPD, using the Issuer’s secret keys for each card, signs the data included in the list of static authentication data. These include: Application Effective Date, Application Expiration Date, Application Usage Control, Application Primary Account Number (PAN), etc.
If dynamic authentication is supported, its own pair of asymmetric keys is created for each card, the card’s public key is signed with the issuer’s secret key (similar to the procedure described above), and the secret key is uploaded to the card to participate in the authentication process later.
In addition to creating asymmetric issuer keys and cards, standard efficiency functions include generation of 3-DES issuer master keys and card keys generated by them. These keys include:
A) authorization keys used in generating and verifying cryptograms, B) keys that sign scripts that change card parameters,
C) keys encrypting new PIN values.
In addition to generating all the necessary secret values, the efficiency completely generates a file with EMV data for a personalized device. Secret data, including those encrypted with the key KEK1, are “re-encrypted” with the key (set of keys) KEK2. The resulting file is sent to the Personalizer. The key KEK2 is also forwarded there via a secret channel.
• Personalized equipment “meets” cards closed by KDC and data encrypted by KEK2. Inside the secure cryptographic device used at this stage, the data is decrypted using the received KEK2. Similarly, KDC keys are formed from the KMC key received from the Issuer, with the help of which the cards are “opened” and the data for the chip is “re-encrypted”. There is an “external” and “electrical” personalization.
It is worth noting that in the above scheme, as it often happens, some of the participants may represent the same legal entity. The standard situation is when the personalization equipment and data preparation complex belong to the Issuer and are located on the Bank’s territory. At the same time, technologically, they are all different participants in the process.
So, data preparation is a key stage of smart card personalization, both literally and figuratively. The hardware and software complex, which includes a cryptographic device, is responsible for its implementation. Let’s take a closer look at the possible (and often required!) its functionality.
At the first stage, the KPD receives data for issuing cards with a magnetic stripe, including information about cardholders. In addition, a certificate of the Issuing Bank’s public key signed with the public key of the payment system is received from the payment system certification body (Visa, MasterCard). Before forming the SDA, the necessary application and issuer parameters are also added to the certificate. The SDA digital signature is calculated using the Issuer’s public key. Further, by diversifying the issuer’s symmetric master key (set of keys) The efficiency generates symmetric keys of the card. Then, if a DDA scheme is provided, non-symmetric card keys are generated and a public key certificate is calculated (for each card). After adding parameters specific to the card, as well as risk parameters set by the issuer, the data is formatted and ready for personalization on the device.
Formatting data
Efficiency functionality:
In the course of its work , the Data Preparation Complex operates with the following objects:
• EMV application templates. They include the data necessary for the personalization of the application, the grouping of this data by files and records, data sets for calculating SDA and DDA certificates, the cryptographic data used and how to obtain them.
• Constant values for a number of parameters used. Such values include, for example, bank BIN, country code, currency code.
• Personalized card templates. They include templates of the applications used, as well as groups of constant values used by each application.
• Data preparation task. It includes the card templates used, the data entry script used, and a list of operators allowed to run this task.
The efficiency checks the processed data for the correctness of the format and acceptable values (for example, the month in the date cannot be more than 12, and the day cannot be more than 31).
The following software functionality is a feature of the “full-fledged” Data preparation Complex:
• Interaction with any “Back Office” system;
• Support for a wide range of cryptographic devices used to generate cryptographic data;
• Flexible redistribution of data preparation functions between the “Back Office” system and the efficiency.
• Support for multiple information sources to generate personalized data. This is especially true for the release of multifunctional smart cards, when there are more than one application, and information can come from different sources.
• Support for open Visa and EMV Common Personalization formats,
which are expected to become standard for all personalization systems in the near future.
6. Means of production
Specifics of card issuance are such that most banks prefer to purchase personalized equipment in order to issue cards, practically without resorting to outside help. The main motive for this behavior is the natural reluctance of banks to provide confidential information about customers to third–party companies – personalizing bureaus.
Thus, one of the most important issues is the rational choice of personalized equipment. Below is a brief overview of the most common types of devices of various performance (for personalization bureaus and large banks, for medium and small banks and branch network) and some of their characteristics.
The world leader in the production of card personalization devices is the American company DataCard (about 85% of the global market). The equipment produced by this company prevails in banks in most countries. Exception in this sense, moreover, almost all of our EMV cards are personalized on DataCard equipment (at least 98%).
We will make our review using the example of the equipment of this particular company, highlighting two types of devices – desktop embossers and high-performance conveyor complexes.
Embossers
Desktop embossers manufactured by Datacard are currently produced in three models – DC150i, DC280P, DC450. Here they are listed in ascending order of performance. All devices can be used to personalize microprocessor cards. To do this, optional modules with a built-in chip reader/writer are installed on them. If the embossers were previously purchased without the intention to produce microprocessor cards, these modules can be installed additionally. The actual performance of the most powerful of the DC450 embossers on international magnetic stripe cards can reach up to 300 cards per hour (which is approximately 12 seconds per card). At the same time, the DC-150i is able to personalize only about a hundred such cards per hour.
What happens to the performance of embossers in the case of the release of cards with a chip? In our experience, it takes at least 6-7 seconds to personalize only one EMV application in the best case (HSM is used for cryptography, a fairly “fast” card, not a very complex application). In other cases, even for personalization of only one application, this time may increase to 15 seconds. Therefore, only 120-180 cards can be issued per hour when using DC-450 and no more than 70 cards on DC-150i.
When personalizing chip cards on desktop embossers, two main problems arise. The first is the need to monitor the process of work at all stages of moving the card from module to module in order to respond to abnormal erroneous situations so as to ensure the release of cards with consistent information (placed on different modules – embossing, strip coding, data recording into the chip) and to have a protocol of work on which cards were successfully released, and which are not. The second task is to build a technology that would allow flexible management of the personalization of the chip, since this process itself (unlike standardized processes for other types of personalization) is quite arbitrary and depends on both the chips used and the applications placed on them.
Thus, it is advisable to use special software (software) to manage the personalization process on the embosser.
Such software, from our point of view, should be designed to solve a wide range of tasks related to design development (determining a set of personalization fields and their parameters), determining information and logical connections for the fields described in the design, as well as directly with the manufacture of plastic cards, that is, to perform the role of an embosser controller.
The software converts the format of the data contained in the source file or database into the format required for the device. At the same time, the data can be of a very different nature – from graphic images to data intended for recording into a chip. When initializing the chip, an interface to the application program library (DLL) or program (COM object) is provided. In the future, we will name the application software component of loading data into the ScApp chip – Smart Card Application. With the help of this interface, data exchange is provided between the embosser controller and ScApp, events that occur during the personalization of the chip are processed.
The figure below shows a possible scheme for solving the problem of card personalization on a desktop embosser.
Conveyor personalization devices
Of the high-performance personalization equipment manufactured by DataCard, the DC500, DC7000, DC9000 complexes are the most relevant for the market. All of them are also used to personalize smart cards.
The functional modules of these complexes (for example, modules of magnetic recording, graphic printing, laser engraving, embossing) are sequentially connected to each other, forming a conveyor. At the same time, the modules work in parallel, that is, several cards are personalized at each time. It is due to this that the highest performance is ensured. At the same time, the machine controller provides information synchronization of the issued cards.
The DC500 may include a smart module with three chip initialization stations. The performance of the device is forcibly limited to 500 cards per hour.
On the DC7000 and DC9000 complexes, up to two smart card personalization modules can be installed, each of which contains up to seven chip initialization stations or up to six such stations and a discarded card marking station. The complexes differ among themselves in the possible number of functional modules to be installed. For DC 7000, this number does not exceed six, for DC 9000 – 20.
The performance of the complex is determined by the operation of the slowest module in its composition. Usually this is a color image printing module (300-500 cards per hour). The productivity of the complexes during card embossing is 500-700 cards per hour. At the same time, with graphic printing and laser engraving, 1000 or more cards can be produced per hour.
It should be noted that 3-4 programming stations are quite enough to issue embossed smart cards (such as cards of international payment systems) with one EMV application.
The operation of the device is controlled by a specialized computer included in its composition – the controller of the personalization device, which provides the following functions:
• creating and editing sets of parameters that determine the implementation of data entry procedures and card personalization procedures;
• input and storage in the internal format of the data stream intended for personalization of the card package;
• managing the personalization process of the card package;
• testing and configuring the parameters of the card personalization modules.
The controller operates under the control of the operating system OS/2.
The module of electrical initialization of card chips (Smart module)
consists of:
• a carousel device that provides a mechanical supply of cards to several initialization stations,
• card initialization stations, each of which is equipped with a connector for connecting to the card chip and connected to an electronic board that controls the initialization of the chip (TBP board);
• encryption stations, in which SAM cards used for personalization and performing certain cryptographic procedures can be placed; each of these stations corresponds to an initialization station and is also connected to a TBP board, in addition, the module can have up to 4 common encryption stations;
• own TBP chip initialization control boards;
• the main electronic board that performs the functions of controlling the mechanisms of the module, interacting with other modules of the complex and transmitting data between the controller of the complex and the TBP boards.
The figure below shows an image of the electrical personalization module of the chip.
Carousel mechanism
To increase the performance of the personalization device as a whole, the Smart module allows you to simultaneously perform electrical initialization of several cards by the number of initialization stations and TBP cards.
To control the initialization process of the card chip installed in the station, the TBP driver program is loaded into the TBP board.
It should be noted that the task of personalization of microprocessor cards is an order of magnitude more difficult than the same for cards with a magnetic stripe. It becomes especially difficult in relation to personalization on conveyor devices. There are several reasons for this. Among them:
• Complexity of software component development (OS/2 environment and Franklin cross-compiler environment for Intel 8051 single-chip computer).
• The complexity of debugging – the need to use special equipment. A large proportion of debugging should take place directly on the complex.
• Uniqueness of application software components for this equipment.
6. Industrial personalization technology
Currently, the SPSC technology (Smart Card Personalization Server) has been developed to manage the personalization process of cards on conveyor devices, as well as on embossers. The technology allows you to personalize cards on several, including different types of devices at the same time. It is so versatile that when switching from one card to another, as well as from one type of equipment to another, only
changing the ScApp module (Application Personalization Program) responsible for initializing a specific application on a specific card. At the same time, when developing SCAPP, you may not know anything about the device on which personalization will take place.
The figure below shows a diagram illustrating the composition and interaction of SPSC software modules when working with a conveyor device.
1. BY Controller
The Personalization Device Controller software provides device management during personalization. Before starting the personalization of the card package, it performs the actions necessary to initialize the hardware modules of the complex. Also, under the control of the Controller software, the Library of the chip initialization application and the TBP Card Drivers are loaded and initialized into the TBP Smart module cards.
After performing the initialization procedures, the controller software begins to personalize the cards for the current data package. For each record of a data package containing information necessary for personalization of one card, the Controller software allocates fields, each of which contains data intended for a specific hardware personalization module.
The Controller software interacts with the Library of the chip initialization application, transmitting data intended for personalization of the current package card. This is done in order to enable the developers of the card chip initialization application to process data immediately before the chip initialization procedure. An example of such data processing is the decoding procedures of encrypted information.
After the “pre-personalization” processing of data in the Library, the Controller software transmits data fields to the hardware personalization modules of the card. Data from the field containing information for initializing the chip is transmitted to the Smart module and gets into the TBP board (or rather, the Driver loaded into it), which is connected to the chip initialization station into which the corresponding card will be inserted.
After completion of the personalization procedure in each module of the device, the operation completion status is transmitted to the Controller software. The status of completion of the chip initialization procedure is transmitted to the Controller software from the corresponding TBP Card Driver.
Based on the completion status received from the hardware module, the Controller software either transmits to the next module a command to personalize the card and the data corresponding to this card, or a command to transport the card through the module without personalization in case of an error at the previous stage. Depending on whether the card personalization was successful in all modules or not, the Controller software controls the placement of the card in the output tray of ready-made cards or in the output tray of defective cards.
The Controller software takes into account the facts of successful or unsuccessful personalization of cards and assigns the corresponding statuses to the corresponding records of the data package.
The Controller software is a universal software module. It provides the release of various types of cards that require different ways of personalization by creating sets of parameters describing the required operating modes of the device, data formats, etc.
2. The library of the chip initialization application
The chip Initialization application library provides interaction between the Controller software and the Chip Initialization Server.
At the moment of initialization of the Personalization Device, before the personalization of the card package begins, the Library establishes a connection with the Server
and transmits the package type identifier to the Server. Based on the received identifier, the Server selects the appropriate set of parameters (Task) to control the initialization of the card chips of this package.
Depending on the specifics of the chip initialization technology of this type of card and the card application, the Library, on command from the Server, may request the Controller operator to enter the necessary data to start the personalization process. Such data can be, for example, the password required to initialize the world schemes of this type of cards.
During card personalization, the Library receives data from the Controller to personalize the next card before they enter the hardware modules of the Device. It transmits this data to the Server for possible “pre-personalization” processing. An example of such processing, as mentioned above, may be the decoding of encrypted data.
In addition to preprocessing personalization data, the Library receives data from the TBP Card Driver with information via the Controller software
about the completion of the initialization procedure of the chip. The Library also transmits this data to the Server for possible processing, the result of which it returns to the Controller software for logging operations performed.
3. TBP Board Driver
The TBP card driver controls the TBP card for the electrical initialization of the card chip.
It interacts with the Controller software to receive data for card initialization. The driver transmits the received data to the Personalization Server. The Driver receives read commands from the Personalization Server
and writing data to the chip of the card. The sequence of these commands is determined by the Chip Initialization Module running in the Server. After the card initialization procedure is completed, the Server transmits information about the completion status of the procedure and accompanying data to the Driver. The driver transmits the status and data to the Controller software.
The driver program implements various protocols that implement commands to read/write data to the chip to interact with various types of card chips.
4. Chip initialization server
The chip initialization server manages software modules that implement various chip initialization applications for cards of various types, and also ensures the interaction of these modules with software modules operating in the Card Personalization Device.
The server provides management of an arbitrary number of personalized devices with an arbitrary number of chip initialization stations in each device.
The server supports the establishment of a connection with the Library of the chip initialization application, receives from it the identifier of the package type of personalized cards. Using this identifier, the Server selects the appropriate set of configuration parameters, called a Task.
The task contains the following descriptions:
• on which Device will the card personalization be performed,
• which chip initialization modules should be used,
• is it necessary, and if so, which Controller library Extension Module should be used for this task,
• application operation parameters during chip initialization. After the Job is identified, the Server performs the upload and initialization of the corresponding software modules.
Further, the server ensures the interaction of these modules with each other and with the software modules running in the Personalization Device.
For the Controller Library Extension Module, the Server provides mechanisms for receiving and transmitting data to/from the chip initialization Application Library during initialization procedures, for processing data before card personalization, and for processing data before placing them in the Personalization Controller operations log. In addition, the Server provides the Module with mechanisms for transferring data to the chip Initialization Module. As a rule, these data are parameters, entered by the Controller operator at the time of initialization. An example would be a password for initializing a chip.
For each Chip Initialization Module, the Server provides interaction between the Module and the TBP Card Driver. In addition, the Server provides the Module with mechanisms for receiving data transmitted from the controller Library Extension Module.
For all software modules running in its environment, the Server provides mechanisms for reading configuration parameters, as well as mechanisms for logging and tracing events that occur during the operation of modules.
The chip initialization server is a universal software module. It provides management of chip initialization procedures by various Chip Initialization Modules
and Controller Library Expansion Modules implementing various application personalization technologies on card chips of various types.
5. Application Personalization Program
The application personalization program (Smart Card Application, SCApp) implements the operations necessary for initialization on a specific type of chip of an application card or a set of applications of a specific type.
The application personalization program works in an environment created by the Chip Initialization Server. This environment is called a Context. The context provides the Module with programming interfaces that implement the following functions:
• management of the chip personalization device at the level of the ISO 7816 protocol APDU commands,
• receiving data from the controller software and the extension library (see below),
• logging of events that occur during the personalization of the chip.
The context interacts with the TBP Card Driver and, when receiving data from it to initialize the next card, calls the corresponding module functions, transmitting the data received from the TBP Card Driver to ScApp. After completing the chip initialization procedure, ScApp returns the operation status and accompanying information to the Context. The context passes this data to the TBP Card Driver.
The application personalization program is a software module specific to a specific type of personalized card package.
Currently, a script technology has been developed, characterized by the following properties:
• Data for personalization of the application is presented in the form of a script;
• The application personalization algorithm is determined by the script;
• When switching to a different type of card, the script changes, not the application personalization program.;
Modification of cryptographic mechanisms does not require modification of the application personalization program.
Thus, the script technology allows you to use a single SCApp for all types of cards, this ScApp is a script interpreter, and the functions of loading data into the chip are implemented by script programs.
6. Controller Library Extension Module
The controller library extension module provides an extension of the initialization procedures of the card personalization process and data processing procedures specific to this type of application initialized on this type of cards.
The controller library extension module operates in an environment created by the Chip Initialization Server. This environment provides the Module with programming interfaces that implement the following functions:
• data transfer to the chip initialization modules,
• logging of events that occur during the operation of the Module. In addition, the Server environment calls the corresponding Module functions when the Server receives requests from the application Library to initialize the chip. These requests correspond to the following actions:
initialization of the personalization process of the card package in the Device; The module can, in response to this request, transmit to the Device an indication of the operator’s input of any data;
transmission by the application Library of the chip initialization to the Server of the data entered by the operator;
transfer by the Application Library to the Server of data intended for personalization of the next card for their “pre-personalization” processing;
the transfer of data by the Application Library to the Server accompanying the status of the completion of the operation and initialization of the chip, for processing them before placing them in the Device log.
The Module functions perform the appropriate data processing and return them to the Server for transmission to the Library of the chip initialization application.
The controller library extension module is not required to perform card initialization procedures. In the event that the set of parameters of the Chip Initialization Server Task does not require the use of the Controller Library Extension Module, the Server itself processes requests from the Chip Initialization Application Library.
The use of the Controller Library Extension Module is necessary when the technology of initialization of a specific application on a specific type of chip requires specialized data processing.
The controller Library extension module is a software module specific to a specific type of personalized card package.
Resume. Comprehensive solution
From all of the above, it follows that the process of personalization of EMV cards is quite complex, it requires a whole set of organizational, technical, and software tools to solve it.
The integrated personalization software solution includes the following main components:
• A data preparation system for personalization (KPD) ,
• Smart Card personalization server for managing the Chip Personalization Process (SPSC),
• The actual application personalization program running under server management (ScApp).
In addition to these software components, it is advisable to use a tester of personalized smart cards to check the data recorded in the chip. Thus, this is how the general scheme of the personalization system may look like: