1. A brief review of history

CPU smart card concept was proven in the late 70s ~ early 80s and commercial applications started in the late 80s. The CPU of the smart card were mainly 8 bits 8051 core or 6805 core. Even today many smart card is still using these cores but with enhanced performance and much bigger memory. If I remember correctly, in 1991 the EEPROM memory size is 2 Kbytes, in 1995 8 Kbytes, 1998 32 Kbytes etc, as predicted by  Moores＊ Law ( http://en.wikipedia.org/wiki/Moore's_law).

Smart card chip operating system (COS) was developed in assembly language and / or C programming language, with the COS residing in the ROM. The late 80s ~ early 90s ROM size is typically 6 to 16 Kbytes. This type of COS is today referred to as native COS, in order to differentiate it from Javacard and MultOS which we called open platform COS.

In around 1994 ~ 1995, the consortium company of some smart card industry players, MAOSCO becomes known to the industry setup to promote MultOS, on which Mondex is one of the application sitting on MultOS. In 1996 Mastercard bought 51% of Mondex International, thus Mastercard interest in MultOS is understandable. Around the same period, Visa and Mastercard where preparing the EMV specification. Industry professionals can recalled the EMV ＊96 specification (version 3.1) ! The MultOS platform OS is developed by Dai Nippon and Keycorp. During this period there was a bloom in the smart card embedders due to the hype in smart card technology. Jumping into smart card manufacturing were typically the plastic card manufacturers and printers. The value-add seems irresistible because of the low price of the magnetic stripe card and by sticking a micro-module the value add  jumps many fold ! At the peak there were more than 200 embedders in China alone ! This lead to a plunge in memory card prices such as SLE4442 and SLE4428 since the embedders simply buys the module and embed it 每 some even glue it by hand !

At around the same period, a group of industry professionals begins to push the idea of Javacard. It is understandable that Sun Microsystems likes the idea too ! It is understandable why Visa likes the idea too ! Unlike MultOS whereby the platform is only from Dai Nippon and Keycorps, thus implying that any embedders, with the required authorization is able to produce MultOS, technically almost like memory card production, Javacard requires the card manufacturer to develop the Java Virtual Machine, with very expensive developer＊s license. Unlike MultOS which the design is from scratch so that it is designed for smart  card usage, Javacard is trying to fit the Java concept which ran on powerful computer into smart card. Java also does not define the applet loading and deletion and post-issuance security. Thus Visa defined the Visa Open Platform. In 1997 the concept of GSM SIMToolKit becomes available for value-added services in GSM handphone; and in 1998 Microsoft began to go into smart card called Windows Smart Card.  The issues of applets loading & deletion and post-issuance needs to be addressed. In order not to be seen as a proprietary technology of Visa, the specification becomes open and was renamed to Global Platform.

In the early days of MultOS, because of security and also because one needs to pay quite a sum to get the information, not much information is available freely. On the other hand, because of the hype of Javacard 每 the write-once run-anywhere, which was not really the card, at least in the early days and not until the leading vendors sat down to sort things out; the vested interest of the card manufacturers in pushing for Javacard rather than reduced to a little or no value-add embedder, Javcard has to be a better card. If many people in the industry said that it is a good or a better card, then it got to be a better card, isn＊t it, despite the fact that not many people in the industry know much about what is a Javacard and what is MultOS ! Thus it can be imagined that with the hype of write-once, run-anywhere, multi-applications and one can download another application in the future etc, a bureaucrat will play save to recommend an open platform card rather an much more cost effective and efficient native chip operating system. To put it cynically, an open platform card is ideal  for people who does not know what they want !

2. Technical Difference Between Open Platform Card & Native COS

Native COS is how smart card were developed since day 1 in the evolution of the smart card and still so till day, but today there are also open platform  card such as MultOS or Javacard. In the early days, native smart card COS is only 6 to 16 Kbytes, with 128 or 256 bytes of RAM. Open platform card requires  much more processing power, ROM size and RAM size, and hence it is one reason that helps to push the sophistication of the smart card where today it is common to have several hundreds Kbytes of ROM and a few Kbytes of RAM. Today there are also smart card that has only flash memory instead of ROM and EEPROM. Another reason for the increased power and capacity is the improvement in technology that is able to pack more power and bytes into the silicon.  Doubling of the silicon size increases the cost by 10% to 20%, and the price is also dependent of the quantity. Needless to say, everything remain the same the price of a smaller silicon is always cheaper than that of a bigger  silicon. The difference becomes much more critical as the profit margin of smart card is getting very thin.

Regardless of whether it is a native COS or an open platform smart card, smart card application program is not aware of the differences as it only communicate with the smart card via commands called APDU commands 每 a standard 5 bytes command header Instruction_class, Instruction_Code, Parameter 1, Parameter 2 and Parameter 3, followed by the command data and the smart card returns a 2 bytes response status.

Major Similarities & Differences In Native COS & Open Platform COS

a. ROM Space If Not Fully Utilised Is Un-usable - Same

Native COS resides in the ROM, which is very efficient  storage. Regardless of where it is a native COS or an open platform card, ROM space if it is not fully utilized becomes un-useable.

b. Concept Of An APDU Command Dispatcher - Same

Both native and open platform COS has a APDU command dispatcher that interprets and APDU command and process it accordingly. It is the building blocks of the application  inside the card. Thus for an electronic purse application there will be a set of APDU commands like Credit and Debit related commands. It is much more complex that what a layman will think off because it needs to take care of  card authentication, terminal authentication, the proof  that the purse has been debited and the credit certificate and the anti-tearing, transaction row-back etc.

c. Where Application APDU Command Resides 每 Difference

Native COS application APDU command resides in the ROM 每 it is there whether you used it or not, but open platform card application resides on the more expensive EEPROM., which is meant for application data, secret keys & secret codes.

d. Ability To Re-use The Same APDU For Difference Applications 每 Difference

In a multi-applications smart card it common to have a few applications but they are very similar. For example there can be an electronic purse, a few other prepaid applications and a few loyalty applications. These applications has different application operators. In a native COS, each application just need a DF which takes up only 16 to 32 bytes in the DF Header. In  an open platform card, each application will probably takes up some 10 Kbytes because the application APDU commands are duplicated !

e. Card Ready To Be Used 每 Difference

A native COS smart card is ready to be used  by the application developer. He just need to understand the COS command set and personalize the card with the directories and files, load in the secret keys and secret codes and application data. It is ready to be used. On the other hand, after buying the open platform card, the application developer will still need to develop the applet. The applet is almost close to developing the native COS APDU command set 每 minus the so called administrative command set to create the directories and files.

f. APDU Command Set Security Loop Holes

There is a misconception that open platform smart card applet, for example Javacard applet can be designed and implemented by a Java programmer, a known-how which is easily available. This is strictly speaking not true because smart card is about security and the applet designer must be competent in smart card COS security. COS programmers came from the smart card industry and are trained in smart card application security considerations. Smart card applet is likely to be developed by Java programmers and there is a much higher chance that they do not understand the smart card application security considerations. Thus the risk of a security loophole is much higher.

f. Cost & Performance - Difference

Native COS resides in the ROM. It is also where the application resides, and is executed directly with the machine code. Open platform has a virtual machine in the ROM. The application resides in the EEPROM. It is in the virtual machine opcode, which is interpreted by the virtual machine. Thus a more powerful processor is required and a much bigger EEPROM is required. Each applet will take around 10 Kbytes i.e. a simple applet may take less than 10 Kbytes and a more complex one can take more than 10 Kbytes. Therefore just the hardware alone, a native card will have a better performance and a lower price, not to mention the expensive Java developer＊s license, its annual maintenance fee and the per card licensing fee.

g.  Take It Or Leave It - Difference

Native COS comes with its set of APDU commands.  Nothing can be done if  it does not meet your requirements. The so called requirements must be those that affect the security 每 not something that looks nice or make the programmer＊s life easy. Competent designers and programmers profession must be one that makes the application secured and cost effective, not one that makes their life easy !

h.  Do Whatever You Want  - Difference

Open platform card is able to do whatever you want, not worrying about the card being unable to do it 每 and this must be from a security stand point ! This is achieve-able because you are developing the applet. If a native COS is to be developed from scratch, it can also do whatever you want !

i.  Write Once Run Anywhere ?  - Difference

It is always been said that Java allows write once run anywhere. However it was just a hype until a few years ago as it was only achieve-able after a certain version of the Virtual Machine (VM) and a certain version of Global Platform (GP). Today＊s  version is VM2.2.X and  GP 2.1.  Even if theoretical inter-operate-ability is possible, the application operator cannot assume that it is possible without doing a qualification. This is because an applet may require certain resources e.g. the RAM space but different chips may offer different RAM space especially a smaller chip has lesser RAM.

3. When To Use Open Platform Smart Card

Open platform smart card is the ideal choice under the following scenarios:

a.        none of the smart card available in the market is able to meet the requirements

b.       the quantity required is not very much

By saying meeting the requirements refer to the security requirements, requirements that mandate decisions to be  made and cryptographic computation to be done inside the smart card ! This is to allow de-coupling of security sensitive operations from the application programmers. Typical examples of where such requirements arises are :

﹞         security modules for smart card devices & key management

﹞         maintaining backward compatibility of existing smart card application with new applications but cannot be satisfied by existing cards

Security module needs to be in complement with how the smart card does the security operations and is dependent on the system security management. Thus how the smart card computes a cryptogram will determine how the security module does the verification (e.g. internal authentication, debit certificate and signature) and how the card verifies the certificates (e.g. external authentication, credit certificate) will requires how the security modules computes the cryptogram in a certain way.

As the cards usually holds the diversified keys and the devices and host hold the master key, even if two system uses the same type of cards but with different diversification methods the security modules will not be compatible.  Thus it is very unlikely that of-the-shelf security modules is able to meet the requirements and even if it exists, it is very often at an exorbitant prices e.g. US$50 each, although the quantity required may not be very much (usually not more than tens of thousands) ! Under such scenario it make sense to develop an applet so that the cost is reduced from say US$50 to below US$5 each !

Must smart card applications with the exception of electronic purse and PKI can be satisfied by many smart card COS which only requires generic ISO-7816 part 4 file structures and card, terminal and cardholder authentications. Electronic purse application is very security sensitive and every country and every vendor do it quite differently. This is still OK as long as the application operator is willing to accept one of them to be used in the pilot project. The same applies to PKI application. However there are very, very few cards that combines electronic purse and PKI application in a single card. This is because many card vendors do not believed in such combined complex applications and would rather spend their resources on mass application smart card like GSM and EMV and would rather lobby for their electronics purse only or PKI only smart card to be used and not be bothered to spend effort to combine them or spend effort to customize then in applications that from their experience has little chance to be successful. The initial quantity is small anyway. The vendors are also aware that when the quantity becomes very big they can comes in with a custom native COS smart card at lower price to hijack the order.

Thus the above scenarios are situation that makes sense for the application operator to use open platform card, develop the applets to be used as a security modules or in the pilot phase of the project.

Open platform card is also good if the application does not know what he wants to do with the card, but in such a case it may be a better idea to wait until he comes clear what he want the cards to do. In smart card and generally in semi-conductor the memory size doubles every 18 months.  There is no point buying for the future 每 just issue another card. This is because usually the smart card will be expired after a few years. New generation of cards will be more powerful and cheaper. The operation and administrative cost of having the can to be added with new applications would also be expensive. The savings from just using a card that meets exactly the current requirements may be sufficient to replace the card with a new one a few years later !

There are also scenario where Javacard is probably the best choice. This is in the case of  Value-added smart card applications on the GSM SIMToolKit Pgase 2+ hand phone and the Near Field Communication (NFC) on GSM hand phone. GSM SIMtoolkit application resides on the GSM SIM and NFC applications may reside in the SIM card or in another Java smart card chip inside the hand phone in additional to the SIM card.

5. How To Define A Tender Specification For Smart Card

Seasoned smart card vendors knows how to go in to spec-in the tender specification 每 a specification that can be met by his smart card with little or no modification and yet make it as difficult and as expensive as possible for their competitors. Thus the first priority is for them to push for their proprietary native COS or when it is not possible, to push for a Javacard, which has a high barrier for many vendors. Some Javacard, because of the ample ROM code space available, is thrown in with  native application APDU commands, and is the ideal choice to be spec-in to lock the specification ! This is likely to pose the greatest difficulties to their competitors. Sometimes, in order to make it even more difficult for their competitors, the silicon vendor chip is specified, which may seem ridiculous  can be common. Because of the big potential order, sometimes silicon vendors are directly involved in the lobbying.

Instead of being driven by smart card vendors, a smart card application operator needs to know what he requires. Smart card features can be classified into the following, which should meet the requirements of all types of applications :

﹞         Portable file application features with basic authentication

﹞         Electronic Purse Security

﹞         PKI Security

Portable file applications with basic authentication is able to meet most of the smart card applications with the exception of electronic purse and PKI application. Portable file application requires the generic file organization of directories and different file structures, namely transparent file, linear fixed record file, variable record file and cyclic file; and the corresponding file access commands for reading and updating. The basic authentication includes card / internal authentication, terminal / external authentication, cardholder authentication and file access secured messaging. This capability is able to meet the security requirements such as Health Card, Driving License, Loyalty, Company ID Card etc, almost all applications except electronic purse and PKI / electronic commerce & identification.

Electronic purse application has additional security requirement such as a debit and credit authorization, a debit that is capable to return a debit certificate that countersign a terminal signature and the debit amount, a credit that is non-replay-able and cannot amount be tampered, incremental debit etc. The smart card security requirements for electronic purse is pretty standard but the implementation is non-standard, which varies from vendor to vendor.

PKI / Electronic commerce / Electronic Identification requires the use of public key algorithm, the ability to generate public-private key pairs, public key encryption and private key signing etc. The smart card security requirements for PKI application is pretty standard but the implementation is non-standard, which varies from vendor to vendor.

If a tender for the smart card needs to be called, and the application operator wants to be genuinely not to be locked by any vendors and want to have the most cost competitive product, then the application operator needs to have competent engineers that really understand smart card and the security requirements of the application. The engineers should previously been involved in the design and implementation of such application 每 be it as a smart card vendor, an application solution house or an application operator. Based on the understanding of smart card and smart card application, he would have studied various native COS. He would have found one that is likely to meet his requirements or close to meeting his requirements. Then he will extract only the relevant application related APDU commands and ignore the administrative command. He would also provide the APDU command flow for all the basic operations as a reference in the tender specification. This is because without in-depth study and thinking, it is not a straight forward process having to think about the sequence of the flow from the individual APDU command.

With the specification defined, it becomes the minimum specification for the tender. It is up to the tender to meet the requirements with native COS, a customization of their native COS or an open platform card such as Javacard or MultOS.

(Need further info, pls contact us our advisor will educate you.)