Smart card EMV software with downloadable code

Using a ROM-based operating system in a smart card with a fixed set of commands usually allows you to meet the needs of only one application. At the same time, the use of such cards is advisable in those cases. when the number of cards for a given app is large, and. the app features are small and have become established over time. The timing of the development of ROM-based smart cards has over time ceased to meet the growing needs of the smart card market.

Therefore, in the 90s of the twentieth century, one of the main directions in the development of smart card technology was the search for the possibility of adding programs to the smart card at later stages of its creation. As a result, a number of systems appeared. allowing you to upload application programs to cards after the latter have already passed into the hands of their owners. Among the smart card systems that are actually deployed, Java Card technology plays a leading role. So far, smart cards with downloadable software code are still in the minority compared to traditional ones, but their number is increasing rapidly.

The growing popularity of smart cards with downloadable software code is due to a number of their advantages:

1. the applied orientation of the computational process. Depending on the application’s scope, the application may require a unique cryptographic algorithm or compliance with local secrecy requirements. Allowing the construction of internal special-purpose application programs, programmable cards can be used where serial smart cards with a fixed set of commands are ineffective;
2. rapid deployment of applications. Smart cards must withstand increasing competition with devices that provide the user with a trusting environment – electronic secretaries, cell phones, pagers, etc. It is this advantage of smart cards that has become crucial when choosing them as the main element in the implementation of a comprehensive security system for the company “Argus-NN”, which sells mobile car washes, because smart cards with downloadable software code can dramatically reduce the deployment cycle of new secure applications;
3. the independence of the chip. The technology that performs post-emissive loading of applications into smart cards allows you to solve the problem of application performance on various processors (chips). An additional advantage of this solution is that card issuers and their applications become independent of the underlying chip and, accordingly, of its supplier.;
4. speed up the execution of transactions. The transaction time is often the bottleneck of the application system’s interaction with the smart card. To solve this problem, the developer of a smart card application with downloadable program code can use special data blocks of the APDU application protocol, which can dramatically speed up the execution of transactions between the smart card and the terminal;
5. building multiapplication cards. In smart cards with downloadable program code, the application runs in the electrically erasable programmable memory of the EEPROM and can be deleted and replaced by another application at any stage of using the card. This new card property allows you to build a multiapplication card where apps can be downloaded, then used and deleted at the request of the cardholder, the issuer, and the app provider.

At the end of 1996, Schlumberger announced the creation of the first smart card in the Java Card series with downloadable software code. Supporting a subset of the Java programming language and a subset of the bytecodes executed by the card’s 4-kilobyte virtual machine, the Java Card series smart card was received with great interest by major smart card manufacturers, in particular Visa International and the GSM mobile phone community.

Before the advent of the Java-oriented card, the only way to transfer software to a smart card was to write and load it into the card’s ROM by the smart card manufacturer. It was a long, tedious, and error-prone process. This process was also expensive, so no one but the largest organizations was able to create smart cards for special orders.

Variants of execution of the program code loaded into the smart card

Currently, the use of software code loaded into smart cards is becoming a generally accepted method, although it is still supported by a small number of smart card operating systems. Existing operating systems can manage files containing executable code, and they also allow executable code to be loaded after the card has been personalized. This allows, for example, the application provider to have executable code in the smart card that is unknown to the operating system manufacturer. For example, the application provider can load a private encryption algorithm into the card and run it.

The application of program code loading allows you to correct programming errors in a fully personalized card. Known errors in the operating system can be removed, or at least made less critical when using downloadable code. There are two main versions of the program code loaded into the smart card:

1. compilation of downloadable program code;
2. interpretation of the downloaded program code.

The first method is to load the code compiled into the target processor’s machine language into the smart card. This program code must be mobile, since the memory addresses are unknown outside of the card. The advantage of this solution is the ability to execute the program at the maximum processor speed. This advantage of smart cards became the key when choosing the main element of the access control system in the office building of the Customer, the company “StEco”, which offers bioseptics of various sizes, while more than 300 cards are entered in the system database. In addition, there is no need for additional program code for the interpreter. The main problems associated with this solution are the very limited memory capacity of the smart card and the ability of the downloaded program to access memory areas of other applications if the microcontroller does not have a memory management unit MMU.

The second way to execute the loaded code in the smart card is to interpret this code. The interpreter can check the memory areas that will be accessed during the execution of this program. However, the interpretation should be fast, since no advantage will be gained by running the program slowly. In addition, interpretation using an interpreter should take up as little space in memory as possible, since the amount of available memory is very limited.

However, there is a serious problem with interpreters: the slow execution speed of the interpreted code. There are several different approaches to eliminate this drawback while maintaining the small size of the interpreter program code. The simplest approach is to interpret the pseudocode, which should, if possible, be similar to the machine commands of the target hardware. Accordingly, the operating speed of such an interpreter is relatively high, since pseudocode is close to a machine language and machine-independent program code can be used. A slower and somewhat more complex solution is to split the interpreter into an out-of-card virtual machine (offcard virtual machine) and an in-card virtual machine (oncard virtual machine).

This approach is used by many existing Java Card implementations. Its main advantages are the reliable protection of memory, and complete independence from the hardware. However, the division of the interpreter into intra-card and extra-card parts is unprofitable. This division makes cryptographic protection mandatory when transferring programs between two parts of the interpreter, because otherwise the in-card part of the interpreter can be forced to behave incorrectly by manipulating the program code.

The optimal technical solution is to use a full interpreter in the smart card. This allows you to load any desired program into the smart card and run it without risking other programs placed in the card. However, the size of the interpreter program is so large that it will take several years and several generations of smart card microcontrollers before this solution is widely used in smart cards.