"Soft mask" and "hard Mask"-Smart IC Card

Directory

One, "soft mask" and "Hard Mask" ... 2

Second, EMV migration process ... 3

Third, the PBOC norms and the EMV standard comparison ... 3

Iv. Summary ... 5

V. About SDA and DDA. 6

One, "soft mask" and "Hard Mask"

The terms "soft mask" and "hard mask" are often used in field tests and smart card operating systems. Strictly speaking, both terms are meaningless from a purely logical point of view, because the so-called Rom mask means that the program code in the ROM is always constant and therefore "hard". However, in the common jargon of the smart card world, the term "soft mask" only represents something similar to masking, which is used when some or all of the program code of the smart card operating system and related application commands are placed in the EEPROM . This means that the program code can be changed relatively easily without the time and expense of making a new ROM mask. This type of "mask" is variable, or "soft". Soft masks are primarily used during or on-site tests, which can correct errors and quickly modify the program to the minimum cost. The disadvantage is that they need to use EEPROM chips with a larger capacity , which are indeed more expensive than the same ROM chips as the program code . However, since field trials do not involve the issue of millions of cards, the cost of using a high-capacity EEPROM chip can be affordable.

Once the soft mask test or field test is complete, the program code placed in the EEPROM is no longer modified and will be used formally by the cast, the program code can be transferred from the EEPROM to the ROM through the real ROM mask production process. The result of this is called a " hard mask " because it can no longer be easily modified. Strictly speaking, the only advantage of the hard mask is that for a given number of memory ROM compared to the chip area of the EEPROM is greatly reduced, so that you can have the same number of program code in the case of a smaller, cheaper microcontroller.

The two-step process of soft and hard masking provides more flexibility for new card applications in a short period of time before the card is released to the user. If a rom mask (equivalent to a hard mask) is used, it is impossible to make changes to the program code once the manufacturer has completed the mask . The two-step approach has a distinct advantage over the old approach, and now, when a new smart card application is introduced, the soft mask technique is used almost at the beginning , only to be transferred to the hard mask after all the required modifications to the program code have been completed .

3. API for the operating system

The original smart card operating system did not publicly provide the 3rd party to invoke the operating system functions of the programming interface, can not put the 3rd party software into the card execution. However, smart card operating systems, such as Multos and Java-enabled operating systems, are now being developed to provide the possibility of loading 3rd party programs into smart cards. Because these operating systems include a thoughtful application programming interface API (Application programming Interface), they have the ability to access the operating system. This means that 3rd party programs do not need to be included in routines already provided by the operating system. Of course, virtually all operating systems have their own internal APIs, which are not designed for external use and are usually confidential.

The smart card realm, unlike usual, does not yet have a common standard for smart card operating system APIs. On the contrary, only two industrial standards have been preliminarily developed so far. One of these is the Java Card API, and the other is the Multos API. The APIs described in the relevant specification allow file managers to access files , invoke appropriate secrecy, and, of course, send and receive data. A smart card operating system with a full operating system API and allows the download of program code is actually different from the number of memory used by the PC operating system alone.

Second, EMV migration process

The PBoC borrowing and petty payments will bring new business opportunities to the Java card, and from the global perspective, the first wave of EMV migration is nearing its end, and there is now a focus on how to upgrade from SDA (static data authentication) to DDA (Dynamic Data authentication) or CDA (on SDA, DDA, The definition of CDA is described in the EMV specification, mixed data authentication) to further enhance the fraud prevention capability of the card.

In view of the domestic market, EMV migration is almost still in its infancy, with only a handful of banks issuing a small number of EMV cards. More banks are still in a frenzy to promote ordinary magnetic stripe credit card , a variety of promotional means and overwhelming advertising, let people dizzying. Domestic banks in partnership with Visa, MasterCard, JCB (Japan), American Express issued a variety of dual-currency credit card , not only let ordinary consumers at a loss, but also let the domestic interbank transaction processing business of China UnionPay feel the market is grim, so China UnionPay to take a variety of strategies, It is hoped that domestic banks will be able to issue UnionPay cards and spare no effort to promote the use of PBOC lending and petty payment practices, thus removing the drag from the market for the massive popularity of PBOC lending and small payments.

Iii. comparison of the PBOC norms and EMV norms

After the EMV2000 chip Card specification promulgated, each major bank card organization in accordance with its own needs of the EMV specification has been refined and revised, including Visa launched by VSDC, MasterCard launched the Mchip and JCB launched Jsmart and so on. Through the refinement of the various bank card organizations, further clarified some general definitions in the EMV specification, and made clear that some of the card issuers can be flexibly defined, so as to ensure that the same bank card brand in the global member banks in the EMV chip migration can be consistent, Better interoperability, of course, this also for a number of smart card manufacturers in product development has provided the necessary reference.

The PBOC specification is the PBOC's localized version of the EMV specification, which, within the overall framework of the EMV specification, is appropriately revised according to the actual situation of the bank card in China, so that the process of the card transaction and the personalization guide are almost identical to the EMV specification. .

PBOC specification and Java Card and GP specifications

We all know that the Java card is a Java architecture for smart cards introduced by Sun, and the use of Java cards can accelerate application development and prevent developers from delving into the underlying structure of a specific smart card chip. Enables more flexible ways to support card multi-application and app additions and deletions after card release. There is a firewall between the different applications, and secure communication between the card and the terminal can be achieved by means of a safe channel.

Of course, if only functionally, the various functions of Java (equivalent to the Android platform ) card can also be implemented on the native card (equivalent to the iOS operating system), but the native card implementation The method of function in different manufacturers will have a great difference, increase the user in the personalization, application development difficulties .

Native card is the concept corresponding to the Java card, commonly referred to as the native card refers to the card's Cos and hardware platform closely related, the card is not universal and two development API interface , application development and the underlying COS is inseparable, And the majority of native cards only support a single application, even support multi-application is also pre-cured in the chip of the multi-application, not like the Java card to support multi-application dynamic download .

The content of the GP (Global Platform) specification is clearly defined for the Java Card in terms of the download, deletion, personalization, and card lifecycle management of the app. Many smart card manufacturers, chip manufacturers, bank card organizations and telecom operators are members of the GP, and the GP specification was originally developed by Visa's open Platform, so it is not surprising to refer to the GP specification for EMV card personalization.

The PBOC specification is consistent with the commands and processes defined in part 10th of the China Financial Integrated Circuits (IC) card debit and Credit Application personalization guide , and the personalization process of EMV cards, that is, the same as the GP specification.

Therefore, if the use of Java card for the PBOC borrowing credit application development, personalization is easy to meet the requirements of personalized guidance. But for native cards, it is not only the long development cycle required to achieve the same results, but also the difficulty of development. ( so the standard financial cards are now using the Java platform, only the Social security card or native platform )

So from a normative point of view, although the PBOC specification does not explicitly define open Platform like visa, it is consistent with both the Java card and the GP specification in terms of content, as well as defining how to use Initialize UPDATE in the PBOC specification. EXTERNAL Authenticate,store data (see the GP specification for details), and so on.

Domestic Java card and native card applications

Although the Java card that supports GP specification has been widely popularized in the global market , some projects in the domestic market are mainly dominated by native card. The reasons for this are in addition to cost considerations (visible native cards are cheaper than Java cards) , there are several other factors:

The division of interests between different application departments in China is serious, it is difficult to achieve a unified multi-application platform, the lack of Java card application environment, making Java Card Multi-application advantage is difficult to play effectively;

Because the development of Java card to the Sun Company to pay a certain amount of technology transfer fees , so some domestic card companies rather invest a lot of manpower and material resources, development belongs to their own native card, also do not want to develop Java card, so from the technical lack of corresponding reserves;

Some foreign manufacturers entering the domestic market, although there is a good Java card products, but in the domestic application environment in the slightest play the advantage of Java card, such as the OTA application in the field of telecommunications, in the Java card has a very good implementation, but whether China Mobile or Chinese unicom are put aside the mature technology, The development of their own OTA system, the number of cards to confuse;

Some system integrators who develop domestic bank IC card E-wallet applications and social security applications are already familiar with the set of key delivery, management mechanisms, and file-building processes that are widely used in native cards and lack understanding of Java cards.

But we also see the relevant units and departments in the smart card multi-application has been action, such as the establishment of the National Gold Card Project , a multi-application alliance last year, calling for coordination between the various application departments, push one card multi-use (to achieve a card to load multiple applications, This can only be the Java card of the world). and Java Card is widely recognized by the global users of multi-application products, in the future of China's multi-functional card applications will also play its unique role.

Some domestic banks began to choose Java cards, with the PBOC credit card project gradually started, some banks in the card selection has been tilted to the Java card. The reason why banks choose Java cards is that the GP specification supported by the Java Card provides the possibility for banks to develop their own value-added applications.

From the experience of EMV migration abroad, everyone was eager to find a business model at the start of the project so that it could balance the input from the EMV migration, although it included factors to reduce the loss of fraud, but the bank wanted to be able to tap more potential on this powerful chip card. So people will naturally focus on the multi-application of chip cards, banks will also be based on different customer groups to develop different value-added applications , both to prevent customer churn, but also bring value-added income.

For example, some domestic commercial banks are doing some project prediction, I would like to use a certain amount of storage space Java card, so that some of their own development of the application to download to the Java card, and can use their own issuer rights to better manage a variety of applications.

In addition, China UnionPay has drafted the PBOC to support non-contact transactions and the regulation of small payments, so commercial banks in the PBOC card distribution will have their own different application combination mode, Java Card application download, installation, deletion of the versatility and flexibility will undoubtedly become the best choice.

The advantages of the Java card in the PBoC debit and micro payment applications

Able to meet different market needs: because the PBOC loan program and the small payment project are just beginning to start, and there may be some differences between commercial banks as to how the project chooses to choose data items that are not clearly defined by the PBOC code. At this point, however, it is difficult to have the flexibility to use native cards that are completely cured to the chip. But Java card because the application itself can be flexibly downloaded , so can better adapt to the changeable market;
Ability to quickly enter the market: Because the native cards used by most banks need to mask the Cos, and this process usually takes 2-3 months to cycle, it certainly slows the time to market. And the Java card after the application development is completed, can be sold externally, equivalent to save the mask of time, for the rapidly changing market, the 2-3 months seems to be valuable;

Can simplify the product development process: If using native card to develop PBOC debit and small payment applications, need to start from the bottom bit by bit, including communication protocols, encryption algorithms, memory management, data storage, any link errors will lead to the entire project crash. The use of Java Card development, then only need to focus on the application itself, as long as the entire transaction process can quickly develop to meet the specifications of the product, the above mentioned the underlying development work has been included in the Java Card API inside, making the development work easy and easy;

The initial overall cost of the project is low: In general, the cost of a single Java card is slightly higher than the native card , but the cost advantage of native card can only be reflected in the large-scale application, because chip manufacturers will charge a lot of mask fees. For the initial PBOC debit and small payment project applications, the general pilot scale is limited to tens of thousands of, so the Java card has a better cost advantage.

Iv. Summary

At present, the Java card in the domestic market, although the share is still very small, but we see the future trend is in favor of the Java card in the direction of development. And some of the country's forward-looking cards are also beginning to carry out the development of Java Card, in the list of GP members also have a Chinese company figure. This illustrates the gradual improvement in the internal and external environment in which the Java card is popularized, and we believe that the future of the Java Card will be more and more optimistic with the gradual start-up of the PBoC's borrowing, small payments and QPBOC chip card projects and the development of the NFC mobile payment business in the coming years for domestic commercial banks.

V. About SDA and DDA

Offline data authentication is an important part of PBOC2.0, and it is an effective means to verify the Financial IC card. In the future, consumers in the use of PBOC2.0 requirements of the financial IC card to carry out the card consumption, the POS system is arranged in the merchant and IC card to complete the offline data authentication work, to determine whether the card has been maliciously tampered with (SDA) or illegal replication (DDA). Two methods of offline data authentication, namely static data authentication and Dynamic Data authentication, are defined in PBOC2.0.

Static data authentication (SDA), which is performed by the terminal to verify the digital signature in the IC card. The purpose is to confirm the legitimacy of the key static data stored in the IC card, and to discover that the unauthorized alteration of the card issuer data after the card personalization can not only effectively detect the authenticity of the key static data inside the IC card, but also prevent the illegal copying and forgery of the card.

Dynamic Data authentication (DDA). In the process of Dynamic Data authentication, the terminal verifies the static data on the card and the signature of the transaction information generated by the card, and DDA can confirm that the card issuing bank application data has not been illegally tampered with since the card was personalized. The DDA can also confirm the authenticity of the card and prevent the card from being copied illegally . DDA can be either standard Dynamic Data authentication or composite Dynamic Data Authentication/application Milvinson (CDA).

"Soft mask" and "hard Mask"-Smart IC Card