The difference between Java card and native card

	Javacard	Native
Functional characteristics
development language	l  a subset of the pure object-oriented Java language. java language advanced and flexible, the development of debugging fast, flexible. l  Java no pointer , And there is internal security mechanism can effectively avoid the cross-border access caused by the program errors and crashes. l  all variables are initialized automatically when they are created in Java.	l  assembly and standard C, process-oriented language. l  assembly language as a machine, more obscure, slow development, so that the existing limitations, but run fast, high efficiency. l  C language has pointers that can flexibly implement various memory operations, but is prone to errors and crashes due to cross-border access. l  C need to be initialized manually, and it is easy to ignore the errors.
architecture The	l  the bottom line for Javacard platforms implemented in accordance with the Javacard specification, providing an interface (API) for specification definition, typically supporting Javacard API and GP API. l  upper layer is an applet developed in accordance with the requirements of the application, equivalent to the ADF on the native card. You can develop multiple applets based on different types of applications. These applets are independent of each other and are selected through aid.	unified through the card operating system (COS) to achieve all the functions. l  cos internal also according to the function of different, divided into several levels, including application layer specific transaction APDU implementation, communication protocol layer implementation, and the specific interaction with the chip and so on. l  often distinguishes between different applications by creating different ADF files.
Application (ADF) selection	L Javacard specification definition, only supported by the aid selection Application (ADF). L within the application, can be implemented by the program, with aid or DFID select ADF.	L can select the application (ADF) via aid or DFID.
Personalization process	The Javacard specification recommends a unified general personalization process (CPS) that, after creating a secure channel, completes the personalization of the card with the Unified Store data command.	Different manufacturers to define a completely different personalized process, the use of completely different personalized instructions, complex, not easy to grasp, nor easy to unify.
Card lock	After the card is locked, it sends instructions to the card, which is handled uniformly by the Javacard platform on the card according to the specification definition, and is not controlled by the specific application (Applet).	After the card is locked, the instruction is sent to the card, which is still processed by the card operating system (COS), and the application instruction is masked within the program.
SS Key Length Support	Supported by Javacardapi interface V2.2.1, 736,768, 896, 1024x768,1280 , 1536, 1984, 2048 bit-length key.	The length of the key that is incremented by 8 bytes or 4 bytes can be supported by the chip.
Collaborative development	L can develop a special applet as a generic function module (Library) that can be called by other application applets to provide a unified implementation of some functionality. L can use shareable interface to secure calls to other applets to authorize access to the method.	Collaborative development at the source code level, through the reuse of code, to achieve functional collaboration.
Security
specification definition	l  Javacard specification, currently generally supports 2.2.1 version. l  GP specification, currently generally supports 2.1.1 version. l  security is defined and guaranteed by these specifications and is certified by Sun.	There is no uniform international norm. security by each card cos manufacturer, through management and testing to ensure.
security control mechanism	firewall, security Domain and secure channel control.	mainly through state machine to achieve. Special instructions enable the state machine to jump to determine whether the state machine satisfies the condition when accessing the file.
apply data Independence	javacard platform implementation of the firewall implementation of physical isolation.	organize data from different applications into different ADF files ,
data access	cached data stored on RAM, available in The app loses its choice, or card reset automatically, cannot be accessed again to ensure that temporary data is not compromised.	cached data stored on RAM , in card reset automatically cleans up and cannot be accessed again. Ensure that temporary data is not compromised.
Data storage	Data storage is divided into two ways of file and internal data objects. • For sensitive data such as keys, internal data object storage, defined by the Javacard specification, is implemented by the Javacard platform, which is specially protected for sensitive data. L Other normal storage data, organized in file form, easy to access and manage.	Data is organized and stored in the form of files. • Both the key and the data, whether sensitive or normal, are stored in the file. • Sensitive data, such as keys, may be stored in encrypted form or stored in a file with special access rights.
Modification and enhancement/deletion of functions
modify APDU directive	l  a separate modification of the corresponding applet source code, It does not affect the implementation and stability of other applications, and does not affect the implementation and stability of the underlying Javacard platform. l  only needs to test and certify the modified applets.	l  modify the card operating system (COS), The implementation and stability of instructions that may affect other applications. l  needs to be re-tested and certified as a whole.
Add new directives	l  a separate modification of the corresponding applet source code, It does not affect the implementation and stability of other applications, and does not affect the implementation and stability of the underlying Javacard platform. l  only needs to test and certify the modified applets.	l  modify the card operating system (COS), The implementation and stability of instructions that may affect other applications. l  needs to be re-tested and certified as a whole.
under different applications, the same instruction supports different functions	l  Individual applets for different applications are individually modified, independent of each other, and do not cause conflicts. l  implementation is simple and secure.	l  modify the card operating system (COS), Because there are different interpretations of the same instruction, there may be conflicts. l  needs to be interpreted by escaping the table to determine which application is currently in the corresponding ADF file. l  is more complex and risky to implement.
Add new apps and deals	l Develop a new applet application. It does not affect the implementation and stability of other applications, and does not affect the implementation and stability of the underlying Javacard platform. L only need to test and certify the new applets.	L Modify the Card operating system (COS) to add new applications and transactions. The implementation and stability of instructions that may affect other applications. L need to re-test and certify the whole.
Remove support for an app	Remove the applet from the card directly from the app.	The card operating system (COS) is modified to delete the corresponding application of the trade and instructions.
Applications and Cases
Main application Range	L EMV2000 Debit Application (VSDC, mchip, PBOC2.0 DC), L Integral, L ED/EP, L NFC and other new business application areas, L composite applications, such as financial applications + integration applications, NFC applications + telecom applications, L Telecom SIM card.	L EMV 96,pboc1.0 Ed/ep, L PBOC2.0 DC, L Social Security, L PSAM or Esam, L key Card, L Usbkey.
Number of cases	Gradually increased in number, highlighting the application of credit, new business areas and composite application areas	have been widely used in some traditional areas, or have a certain history of the project.
Capacity and price
EEPROM Space Size	Typically 20K, 36K, 72K or larger for multi-application support	Usually 8k,16k or 32k,36k, easy to save costs, large-scale deployment.
Chip platform	L usually use high-end chip platform, L usually support RSA and dual interface, L High chip frequency and fast processing speed.	L use a variety of chip platforms in mid and Low end L Optional support RSA and dual interface.
Card Price	L because the card eeprom space is usually relatively large, the chip platform is higher than the upper end, so the price is higher. L There are also issues with javacard authorization, which may be subject to payment of the licensing fee to Sun, which is included in the card fee and paid by the card manufacturer.	Because the card EEPROM space is usually smaller, the price is relatively cheap.

The difference between Java card and native card