Use Java smart cards to protect software. Chapter 5. Security

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

In 90% of cases you will not be able to come up with an algorithm that would have all the following properties:

• removing this algorithm from the program would make your software completely non-functional.
• a hacker could not guess and emulate this algorithm

If you hit this 90%, then you should:

• Encrypt all communications with the card
• Protect your software with Themida-type protector

1. Encryption of data exchange with the card

If you want to build strong protection, traffic encryption keys should change. A new key should be generated at least every time your application starts. Generate session keys should be based on the data, as provided by the card, and your program. The mechanism of a protected session may look, in a primitive version , for example, like this:

• There is a master key DES M. They know the card and software.
• The card generates 4 bytes of random data (Ccard), the software generates 4 bytes of random data (Csoft). They exchange this information with each other.
• The card and software combine both arrays (Ccard + Csoft), encrypting the resulting set of bytes with the M master key. 8 bytes of the 1DES key are obtained, which will later encrypt the entire exchange in the current session.

Attention! Do not do as described.

In case the decrypted data seems incorrect to the card, it should be blocked. The easiest option to implement a similar option is to start the CardIsLocked boolean field in the applet class and check its contents in the process method before calling the method corresponding to the passed command code. If CardIsLocked - give the software an error instead of data.

2. Using Themida features

Themida is considered one of the most difficult to remove protectors. However, just hanging the projector from above is not enough. If you want to build a truly reliable protection, you should use the Themida API to the full extent:

• Be sure to use Themida virtual machine protection mechanism
• Pay particular attention to the Themida help section, which is called “SecureEngine Macros”. When developing your own secure session mechanism for communicating with a card, enclose all the code that enables communication with the card in such macros as VM_Start / End, Code_Replace_Start / End.
• Typically, a secure communication session with the card is established once when the application is launched. If this is also true in your case, put the code responsible for the start of the protected session in the Clear_Start / End macros so that after setting up the protected session, the code that does this is deleted from the process address space.
• Use the macros CheckProtectionStart / End, CheckCodeIntegrityStart / End inside the functions that work with the card.
• Do not let your program run under virtual machines (unless your application requires it)

3. Cryptographic traps. A few of the millions waiting for you.

Working with cryptography, it is important to understand what you are doing, what you can do, and what not. Of course, if you are protecting a console card with a smart card, you can afford anything you want. But if this tetris is unique and brings you a million dollars tomorrow ... For example, once having used a certain initialization vector with a specific DES key, do not do it again.

Do not invent your own super-secret-no-one-known proprietary encryption and hashing algorithms. Remember the fate of the GSM A5 / 3 cipher and its poor authors who have decided that they are superkriptograf.

Having designed a super-resistant security system, do not leave blunt holes in it, like the one in the banking client based on BS-Client .

4. 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.