Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
The choice of the hardware and software platform of the microprocessor card and the configuration of its application is largely determined by the tasks formulated by the bank's business in its card programs. Here are some examples to illustrate what has been said.
If the bank plans to use prepaid cards, then, apparently, most of the operations with such cards will be carried out offline. Therefore, in order to avoid the possibility of SDA cards cloning by fraudsters, it is recommended to use chips that support dynamic authentication methods for the prepaid card. Despite the fact that a card that supports dynamic authentication methods costs 30-40 cents more than a card without a cryptographic coprocessor, it makes sense to use a DDA / CDA card as a prepaid card to ensure the security of operations.
The second example is an innovative bank offering its clients a set of various services, including not only performing standard payment transactions with the card, but also implementing loyalty schemes, client authentication methods, etc. In such cases, it makes sense to consider using cards that support multi-application operating systems, such as Java Card or MULTOS. The use of such cards will allow the bank to ensure the required level of data security related to various applications, remote loading of new applications to the card, rapid development and implementation of new applications.
In this case, special requirements are imposed on the characteristics of the card. This is especially true of the size of the EEPROM memory, which must be able to store data from a multi-application operating system and applications, as well as the program codes of some loaded applications. For example, when using a GlobalPlatform / Java Card, select a chip with at least 16KB EEPROM.
Another example is a bank that is simultaneously a member of the two largest payment systems VISA and MasterCard. In December 2005, EMVCo released the Common Payment Application (CPA) standard, which describes an application that is simultaneously supported by both leading payment systems. A bank that has chosen the CPA application as a universal payment application, in addition to expanding the functionality of its cards in comparison with the case of using the M / Chip 4 and VSDC applications, makes it easier for itself to solve the problem of risk management and personalization of microprocessor cards, and also unifies the processing transactions on your host in both payment systems.
Finally, the last example is the introduction by a bank of a card for quick customer service, for example, in a fast food restaurant or when paying for a toll road or subway. In this case, the bank may consider using contactless cards.
Thus, if we try to generalize, then the statement of the bank's task for the choice of its card should include:
Today the bank has at its disposal a wide range of cards from various manufacturers. EEPROM memory of bank cards varies from 2 to 72 Kb. The size of the rewritable memory of 16, 32, 64 KB is not surprising for anyone today. The ROM memory of most cards contains applications of both leading payment cards, as well as numerous additional applications - MODS, CAP / DPA, PSE, some kind of loyalty application, etc.
The applications of the leading payment systems are implemented with support for the CPS specification, which makes it easy to personalize them. In addition, the executable software modules of these applications often run in multi-instance mode, which allows multiple applications to be implemented using one software module. For cards supporting the GlobalPlatform platform, the ability to use the multiinstance mode, in which multiple applications can be implemented using one applet, follows from the properties of the GlobalPlatform.
In order to save EEPROM memory on cards, as well as for reasons of correlation of functionality of some applications, the data sharing mode is used by several applications. Shared data may include the value of the PIN, PTC counter and PTL limit, as well as application keys, PBX and LATC transaction counters, etc.
More and more cards with EEPROM over 16KB are GlobalPlatform / Java Cards. Such cards open up opportunities for the bank to introduce new applications, not only in the process of personalizing the card, but also after the card has been issued to its holder.
The list of questions that should be answered when choosing a particular card should include:
Note that the most critical parameters of the transaction processing time on the card side are the speed of implementation of the RSA algorithm and the speed of data exchange between the card and the terminal. To illustrate this, consider a CDA card that uses a public key for offline authentication with a modulus length of 1024 bits. In this case, we will assume that the card issuer has a public key with a modulus of 1536 bits, and its certificate is made on a system key with a modulus of 1984 bits.
In the case of a CDA card, when performing online authorization and approval of the transaction by the issuer, the card signs the data twice in order to authenticate itself and ensure the integrity of information exchange between the card and the terminal. If the card supports the Enciphered PIN Offline cardholder verification method, then it signs the data using the RSA algorithm three times. Assuming that the signature time on the long exponent is 150 ms, we find that the card will spend about 0.45 seconds to create Signed Dynamic Application Data and decrypt the PIN block.
Let us now estimate the amount of data transmitted by the card to the terminal. The card must transmit to the terminal the issuer's key certificate (in order of 2 Kbit), the card key certificate (in order of 1.5 Kbit) and twice Signed Dynamic Application Data (in order of 2x1 Kbit). In addition, the terminal transmits to the card the value of the signed PIN-block (in order of 1 Kbit). Thus, the lower bound for transmitted data is 6.5 Kbps. Assuming that the speed between the terminal and the card is 9600 bit / s and the communication protocol T = 0 is used, which requires 12 bits of information to transmit one character, we get that the transfer of only the listed data will take at least 1.02 seconds.
If the bank plans to use prepaid cards, then, apparently, most of the operations with such cards will be carried out offline. Therefore, in order to avoid the possibility of SDA cards cloning by fraudsters, it is recommended to use chips that support dynamic authentication methods for the prepaid card. Despite the fact that a card that supports dynamic authentication methods costs 30-40 cents more than a card without a cryptographic coprocessor, it makes sense to use a DDA / CDA card as a prepaid card to ensure the security of operations.
The second example is an innovative bank offering its clients a set of various services, including not only performing standard payment transactions with the card, but also implementing loyalty schemes, client authentication methods, etc. In such cases, it makes sense to consider using cards that support multi-application operating systems, such as Java Card or MULTOS. The use of such cards will allow the bank to ensure the required level of data security related to various applications, remote loading of new applications to the card, rapid development and implementation of new applications.
In this case, special requirements are imposed on the characteristics of the card. This is especially true of the size of the EEPROM memory, which must be able to store data from a multi-application operating system and applications, as well as the program codes of some loaded applications. For example, when using a GlobalPlatform / Java Card, select a chip with at least 16KB EEPROM.
Another example is a bank that is simultaneously a member of the two largest payment systems VISA and MasterCard. In December 2005, EMVCo released the Common Payment Application (CPA) standard, which describes an application that is simultaneously supported by both leading payment systems. A bank that has chosen the CPA application as a universal payment application, in addition to expanding the functionality of its cards in comparison with the case of using the M / Chip 4 and VSDC applications, makes it easier for itself to solve the problem of risk management and personalization of microprocessor cards, and also unifies the processing transactions on your host in both payment systems.
Finally, the last example is the introduction by a bank of a card for quick customer service, for example, in a fast food restaurant or when paying for a toll road or subway. In this case, the bank may consider using contactless cards.
Thus, if we try to generalize, then the statement of the bank's task for the choice of its card should include:
- list of applications supported on the card and application requirements for card resources (memory, security, operation speed);
- the need to develop and implement new applications that can function in the operating environment of the card;
- the need to download applications after the card is issued;
- the conditions for using the card (in particular, the limitation on the time of the operation, the typical size of the transaction, the conditions for accepting the card - for example, only online authorization or only offline, work through a contact and / or contactless interface, etc.);
- requirements for the security of transaction processing;
- availability of payment system certificates confirming the fulfillment of the payment system requirements by the card and the application of the card.
Today the bank has at its disposal a wide range of cards from various manufacturers. EEPROM memory of bank cards varies from 2 to 72 Kb. The size of the rewritable memory of 16, 32, 64 KB is not surprising for anyone today. The ROM memory of most cards contains applications of both leading payment cards, as well as numerous additional applications - MODS, CAP / DPA, PSE, some kind of loyalty application, etc.
The applications of the leading payment systems are implemented with support for the CPS specification, which makes it easy to personalize them. In addition, the executable software modules of these applications often run in multi-instance mode, which allows multiple applications to be implemented using one software module. For cards supporting the GlobalPlatform platform, the ability to use the multiinstance mode, in which multiple applications can be implemented using one applet, follows from the properties of the GlobalPlatform.
In order to save EEPROM memory on cards, as well as for reasons of correlation of functionality of some applications, the data sharing mode is used by several applications. Shared data may include the value of the PIN, PTC counter and PTL limit, as well as application keys, PBX and LATC transaction counters, etc.
More and more cards with EEPROM over 16KB are GlobalPlatform / Java Cards. Such cards open up opportunities for the bank to introduce new applications, not only in the process of personalizing the card, but also after the card has been issued to its holder.
The list of questions that should be answered when choosing a particular card should include:
- 1) the cost of the card for the volume of purchases of interest to the bank;
- 2) a list of applications supported by the card;
- 3) application functionality:
- - supported methods of authentication and verification of the cardholder;
- - card application data that can be transferred to the issuer during the transaction;
- - parameters of the card application, which can be changed using the Issuer Script Processing procedure.
- 4) type of operating environment of the card: static (native) or multi-application;
- 5) the main parameters of the microprocessor: size of EEPROM, RAM, bit width and clock frequency of the processor, interface types - contact / contactless (these parameters have the greatest impact on the speed of card operation and at the same time on the cost of the card);
- 6) the speed of performing read / write operations, checking the PIN code, the RSA algorithm with the size of the key module of interest, the 3DES algorithm, generating a random number;
- 7) the availability of tools for the development of new applications;
- 8) support for secure loading of the application after the card is issued, for example, GlobalPlatform;
- 9) the possibility of “standard” personalization of applications, for example, by means of CPS or already developed personalization scripts used in the native operating environment of the card;
- 10) supported communication interfaces and protocols, as well as data transfer rates;
- 11) physical security means implemented on the card microcircuit (countermeasures against SPA / DPA, DFA and Timing attacks, the presence of various sensors and filters to combat power surges, surges in the supplied clock frequency, etc., encryption of memory and data transmitted in data buses and addresses, etc.);
- 12) availability of a payment system certificate for compliance of the payment card application with the specifications of the payment system;
- 13) availability of certificates of safety of the card and its operating environment according to the criteria of Common Criteria and / or ITSEC.
Note that the most critical parameters of the transaction processing time on the card side are the speed of implementation of the RSA algorithm and the speed of data exchange between the card and the terminal. To illustrate this, consider a CDA card that uses a public key for offline authentication with a modulus length of 1024 bits. In this case, we will assume that the card issuer has a public key with a modulus of 1536 bits, and its certificate is made on a system key with a modulus of 1984 bits.
In the case of a CDA card, when performing online authorization and approval of the transaction by the issuer, the card signs the data twice in order to authenticate itself and ensure the integrity of information exchange between the card and the terminal. If the card supports the Enciphered PIN Offline cardholder verification method, then it signs the data using the RSA algorithm three times. Assuming that the signature time on the long exponent is 150 ms, we find that the card will spend about 0.45 seconds to create Signed Dynamic Application Data and decrypt the PIN block.
Let us now estimate the amount of data transmitted by the card to the terminal. The card must transmit to the terminal the issuer's key certificate (in order of 2 Kbit), the card key certificate (in order of 1.5 Kbit) and twice Signed Dynamic Application Data (in order of 2x1 Kbit). In addition, the terminal transmits to the card the value of the signed PIN-block (in order of 1 Kbit). Thus, the lower bound for transmitted data is 6.5 Kbps. Assuming that the speed between the terminal and the card is 9600 bit / s and the communication protocol T = 0 is used, which requires 12 bits of information to transmit one character, we get that the transfer of only the listed data will take at least 1.02 seconds.
