Use Java smart cards to protect software. Chapter 1. General Information

1. Introduction

In this series of articles we will discuss the use of Java smart cards (cheaper analog keys of electronic keys) to protect software. The cycle is divided into several chapters.

To read and understand the information from the articles you will need the following skills:

• Basics of software development for Windows (programming skills are enough in any visual environment, such as Delphi or Visual Basic)
• Basic knowledge from the field of cryptography (what is a cipher, symmetric, asymmetric algorithm, initialization vector, CBC, etc. I recommend Applied Cryptography by Bruce Schneier for mandatory reading).
• Basic programming skills in any language, even remotely resembling Java syntax (Java, C ++, C #, PHP, etc.)

The purpose of the cycle is to acquaint the reader with Java maps (there is very little literature in Russian on their use). The cycle does not claim the status of "Guidelines for the development of software protection based on Java cards" or the title of "Handbook of Java cards."
')

The composition of the cycle:

• Chapter 1. Java card. General information.
• Chapter 2. Java map from the point of view of the applet developer
• Chapter 3. Installing and Configuring IDE
• Chapter 4. We write the first applet
• Chapter 5. Security

2. Assumptions

No article in the cycle claims to be complete and accurate, although the author tried very hard to make all of them the most complete and accurate.
When using any information from this series of articles, remember that you do this at your own peril and risk. The author is not responsible for any damage that may be caused to you by using this information.

The series of articles deals with Java cards that comply with the GlobalPlatform version 2.1.1 and JavaCard 2.2.1, such as NXP JCOP or Gemalto TOP GX. All information in this series of articles or part of it may not be applicable to Java-cards that do not meet these standards (the exception, of course, is the later versions of the standards mentioned). Using cards that do not meet these standards for software protection may be unsafe for the project.

Since the description of the GlobalPlatform standard of one particular version takes about 350 printed A4 sheets, the author deliberately goes to some simplification of the terms and theories underlying the architecture of the described cards, which in his opinion does not contradict the actual data.

3. Basic Java Card Information

What is a java card? A java card is a small computer enclosed in a SIM card case, similar to the one you use in your cell phone. This microcomputer has its own microprocessor (such as Philips P8WE5017 , for example), a certain amount of “flash” memory for storing programs (usually from 32 to 128 kilobytes), a cryptographic coprocessor.

The computer communicates with the computer through a special reader, usually inserted into the USB port. But there are also contactless cards that you simply bring to the reader to establish a connection.

In memory cards can be stored programs called applets. Applets are written in a slightly truncated version of the Java language (a text file with the .java extension), then compiled into a byte code using a regular Java compiler (you get a * .class file) and are converted by a special converter program to directly load into the map (usually, * .cap or * .ijc file). The Java language variant used to write applets is simplified so that applets are as fast and compact as possible (for example, support for types such as string has been removed from the language, and most of the cards do not support int, either. this in the following articles). Communication with the card is accomplished by sending a command to the card, called an APDU (Application protocol data unit), consisting of a header, 5 bytes long and the data of the command. In response, the card can respond with a double-byte code: either an error code or a code indicating successful execution of the operation (as a rule, 90 00). Together with the successful execution code, the card can transmit to the application a stream of bytes corresponding to the result of the command execution (for example, decrypted data).

On a card, usually by default, at least one applet already exists, called ISD or Card Manager, which provides basic functionality (for example, installing and removing applets). Sometimes the manufacturer installs a card and other applets (for example, an applet supporting PKCS # 11 or an electronic wallet).

Most Java cards carry a cryptographic coprocessor that speeds up the execution of encryption and checksum calculations by applets. The most commonly used are DES, AES, RSA and SHA1. A complete list of supported algorithms can be found in the JavaCard SDK. The list of algorithms supported by a specific card is in the documentation for specific cards (yes, as a rule, the card does not fully support the standard, for example, due to export restrictions).

Technically, the applet code is an instance of a class inherited from some abstract JavaCard API class (Applet), whose methods provide basic functionality (installation processing, response to commands from a computer). All members of the applet class are persistent and stored in the EEPROM card. Thus, if the instance of the applet class has a field short x = 5 and as a result of the execution of the APDU command, the applet changed this value, after removing the card from the computer and inserting it back into the reader, the applet will have the modified value available.

The amount of memory card (RAM) is usually small and depends on the implementation. Usually no more than 1Kb.

Access keys are used to protect the card. There are usually three of them - encryption key (ENC / AUTH), signature key (MAC) and important data encryption key (DEK / KEK), which is used when changing access keys to the card, as a rule). This is usually 3DES2 keys of 16 bytes each. Knowledge of these keys is necessary only for manipulations with the applet (writing and deleting, reading the list of applets installed on the card). Sending a command to your applet and getting a response from it does not require knowledge of these keys.

To communicate with the card from your Windows-based software, SmartCard API is used, which allows you to transparently communicate with all cards that meet the standard, regardless of the type of card and reader. In many programming languages ​​(Java, .NET, Delphi and others) there are wrapper libraries for communicating with the map, providing the required functionality in a convenient for the developer form of classes / components.

Some cards on the market (such as Gemalto CyberFlex Egate 32k) have a built-in USB interface and can be used with a reader that can be “soldered” almost at home. True, such cards are noticeably more expensive than ordinary ones. The cost of a reader for cards with a USB interface for large batches can be about $ 1. The cost of a standard reader, as a rule, which has built-in Windows drivers for production on Chinese capacities is a few dollars.

Cards are supplied in the form factor of a SIM-card of a cell phone, and in the "big" format.

The API for working with cards is able to respond to inserting and extracting a card, which allows it to be implemented using cards, for example, employee time management systems (you need to leave - put the card in the reader or the reader with his card in the PC. Soft responded, asked the applet to sign random data, checked the signature and made the registration).

4. Why Java cards are useful for software protection

The owner of the Java card can load one or several applets that implement almost any algorithms (complexity, of course, is limited by the speed of the card's processor and the amount of available memory). But these applets cannot be read from the card by anyone, including the cardholder (the applet can only be erased and the new one replaced in its place). You can only give the applet some command and get an answer. Perfect black box.

The GlobalPlatform standard allows for remote secure update of applets, for example, via the Internet. In this case, using cryptographic algorithms ensures that the source code of the applet cannot be intercepted by a third party (I had to write client-server solutions for such operations. I cannot say that everything is simple, since the cards are still different, but, nevertheless, quite possible).

A Java card is usually protected from electronic retrieval of information by special methods (that is, it is impossible to make a copy of it). Remember that we are talking about specific cards that implement specific standards. Some Mifare cards, for example, which our metro system used in the past, can be easily cloned (although this is not a Java card), whereas IBM JCOP-based technology is usually very difficult.

The applet can independently block (to unblock it, you need to establish a secure session, which requires knowledge of the card access keys) or destroy the card (further work with it by any means will be impossible, the card will always respond with an error).

Many Java cards are certified by EAL standards (some JCOP are certified, for example, by EAL4 +, EAL5 ), which guarantees reliable protection. Some cards use, for example, such companies as Visa as e-wallets.

The cost of some Java-cards for purchases in large quantities is very small (some simple JCOP variants cost a few euros for large lots). Compare this cost with the cost of some specialized protection keys like HASP or Guardant , the majority of which, by the way, do not allow arbitrary algorithms to be stored in the key's memory.

The Java language variant used to write applets is extremely simple to learn and use.
All tools for working with most cards on the market are open and free.

5. Is it possible to hack software protected by a Java card?

The complexity of hacking software protected by a card depends on the complexity of the algorithm that you put on the card. For example, if you place an applet in the map that will summarize the two numbers transferred and return the result, there are good chances that the first hacker will make an emulator. He will not even have to break the software for this (it is enough to replace the dll in Windows, which communicates with the map). However, it should be noted that in this case you will be able to release the V2 version of your applet, which will summarize three numbers already and will thus be “more resistant” to cracking.

But, for example, if you wrote software that uses the card to generate electronic signature of documents using RSA keys that you put in the applet, such software will not be able to be hacked, since it is absolutely impossible to extract the RSA key from the applet if the applet itself does not want . However, as a rule, the protection mechanisms placed in the applet are a cross between the two examples and we will talk about this later.

6. Select Java card

When choosing cards to protect your software, be careful.

• Examine all the documents and specifications of the cards that you offer.
• Make sure the cards are certified and protected from attacks.
• Pay attention to the list of algorithms supported by the card. For example, on some cheap JCOPs, AES and RSA are disabled (algorithms may not be completely disabled. Let's say that only keys with limited length will be available).

As for me, with a light heart, I can advise you to use only NXP JCOP or Gemalto TOP (and their older versions).

7. Where to buy

In general, it is better to buy cards abroad from trusted suppliers who work with large companies. In Russia, their prices are simply wild (although, of course, everything depends on the quantity). But for tests or initial development, you can buy them in online stores. Unfortunately, very few people will give you a good price for a small batch of cards. But on trial it is quite possible to buy a couple of pieces.

8. Gratitude to patient readers.

Thanks to everyone who read to this place. Gratitude and indignation are accepted.

I will welcome any questions in the comments and try to update the article so that it includes the answers.