The evolution of security systems on electronic keys
This article is devoted to the development of protection systems on hardware keys, the types of attacks that have been faced in recent years, and how they managed to resist. The possibilities of electronic keys that directly affect the degree of protection of software, and the main problems inherent in this technology are considered. The author of the article is the leading developer of the Guardant project, Aktiv company.
Modern electronic keys are divided into keys with symmetric cryptography, keys with asymmetric cryptography, and keys with downloadable code. The latter type of device requires more detailed analysis beyond the scope of this article.
Consider the protection of Windows-based applications developed using compiled programming languages (C, C ++, Pascal, Delphi, Fortran, etc.).
The main way to build reliable protection is to use the API library to work with the electronic key. As a rule, API is delivered in the form of static and dynamic library.
')
Static libraries, in contrast to dynamic ones, are joined (linked) to the executable program during the build process. Their use is most preferable, since eliminates the possibility of a simple file substitution. Next, we will consider the protection of applications using exactly the static library.
The program communicates with the electronic key through the API library, which directly interacts with the electronic key driver. A typical exchange scheme between a protected program and an electronic key is shown in Fig.1.
Attacks in such a scheme are aimed at the interaction between different security modules. Interception of requests to the electronic key at the level of the electronic key driver (1) or USB bus driver (2) does not require any modification of each new version of the application, unlike the variant with interception of static API library calls (3).
This type of attack is the simplest. The original electronic key driver is replaced with an emulator driver. Data transmitted to the key and returned back are intercepted and stored in a file on disk. Then the original key is removed from the computer and the program begins to interact with the emulator, continuing to sincerely believe that communicates with the key.
Turning to the particulars, I would like to dwell in more detail on the protection from software emulators in Guardant electronic keys. Guardant dongle drivers contain an electronic signature (ES). When you call Guardant API functions, the protected application automatically checks the driver signature in RAM. Since the private key is not known, it is impossible to create a driver emulator with the correct signature. The virtual machine (pseudocode), through which the executable driver files and the Guardant API libraries, is prevented from removing the check. The verification scheme is shown in Fig.2.
After the implementation of such protection in practice, software emulators have shifted to the USB-bus level (2nd version of the attack).
The creation of such an emulator required the study of the exchange protocol between the dongle driver and the USB bus driver. Paradoxically it sounds, but in such a situation LPT-keys turned out to be more reliable, since The dongle driver directly interacts with the LPT dongle through the computer I / O ports, bypassing the intermediate driver.
Unfortunately, it is impossible to completely get rid of software emulators at the USB bus level using keys with symmetric cryptography. However, good protection, built on a constant exchange with an electronic key, may require more than one day to record all possible parcels and answers to the key and work for an illegal user at the most inappropriate moment. Hacked programs that stop working for unknown reasons, only to confirm.
Separately, I want to mention the protection, when developers are limited to a simple test of the presence of an electronic key. This is a blunder. Using the disassembler, “independence” can be presented to such a program in 15 minutes.
In electronic keys with asymmetric cryptography, the data exchange between the protected program and the electronic key is encrypted on the session keys. For this reason, the third option is the only possible attack.
This attack is the most logical for keys with asymmetric cryptography. It is expedient only if the electronic key manufacturer takes care of the protection of its libraries, otherwise it is much easier to attack the library itself.
With the help of modern disassembler, you can quickly recognize the functions of the API in the program. And if so, then all function calls are easy to intercept. This means that access codes, requests and responses are still vulnerable. And if the program developer himself did not protect calls to API functions, then this is the best place to attack.
To exclude the possibility of intercepting calls to the static API library in a protected program, you need to combine the key functions of the application and the API functions into a single whole. Only then will it be really difficult to analyze the parameters, intercept calls or modify requests and responses to API functions. In practice, the development of protection is started after the main application code has been written. Very often, there is not enough time and, perhaps, desire for a deep integration of the interaction between the program and electronic keys. The least time consuming way to improve the quality of protection is to additionally use software tools that complicate code analysis. In this case, the interaction of the program functions and the functions of the static API library becomes difficult to understand.
Returning to Guardant dongles, let's say that all Guardant API libraries are protected from analysis and modification using a virtual machine. By virtual machine is meant pseudocode obtained from the original binary code of the program, and the corresponding interpreter. Pseudocode instructions can only be executed on the interpreter for which it was generated. The interpreter is responsible for protecting the pseudocode instructions and itself against modification using multiple integrity controls. All parameters of instructions, constants, addresses of transitions are decrypted on the hashes of the pseudo-code and interpreter fragments. To make analysis difficult, the pseudocode interpreter is protected using polymorphic obfuscation. The listed characteristics are implemented in a unique way in each copy of the virtual machine.
The pseudocode protection technology is available to anyone using the Guardant Armor service. This approach has a number of advantages: the protection tool is constantly updated and is not available for study. At the same time, developers who use Guardant dongles receive special benefits. The service allows you to protect the program's functions simultaneously with the functions of the Guardant API static library ( Guardant Monolith technology). The presence of the Guardant API library within the application is determined automatically, so no additional recompilation of the application is required. As a result, each time the application is protected, a unique copy of the virtual machine is created with its own instructions, constants, obfuscation, in which the logic of the program is closely related to the electronic key library. Now, in order to intercept calls to a static library or attack the library itself, you will have to deal with each defense individually.
Consider this on the example of a small test application, a fragment of which is shown in Fig.4. This example very clearly characterizes the vulnerability of calls to any static library within an application. The problem concerns all manufacturers of electronic keys.
Suppose that the application function
Now let's protect the API functions and key functions of the application using Guardant Online service. A fragment of the protected application is shown in Fig. five.
After protection, the
A number of recommendations for building reliable protection.
1. It is necessary to use static API libraries in the program. API library calls must be tightly integrated with the logic of the program being protected - this is a guarantee of creating persistent protection.
2. It is better to use keys with asymmetric cryptography, since for them there is no easy way to create tabular emulators.
3. Application code and static API library must be protected from analysis using software protection tools, where there is no simple ability to intercept API function calls in the program. For developers using Guardant technology, the ideal solution is Guardant Monolith.
Modern electronic keys are divided into keys with symmetric cryptography, keys with asymmetric cryptography, and keys with downloadable code. The latter type of device requires more detailed analysis beyond the scope of this article.
Consider the protection of Windows-based applications developed using compiled programming languages (C, C ++, Pascal, Delphi, Fortran, etc.).
Data exchange between the program and the electronic key
The main way to build reliable protection is to use the API library to work with the electronic key. As a rule, API is delivered in the form of static and dynamic library.
')
Static libraries, in contrast to dynamic ones, are joined (linked) to the executable program during the build process. Their use is most preferable, since eliminates the possibility of a simple file substitution. Next, we will consider the protection of applications using exactly the static library.
The program communicates with the electronic key through the API library, which directly interacts with the electronic key driver. A typical exchange scheme between a protected program and an electronic key is shown in Fig.1.
Attacks in such a scheme are aimed at the interaction between different security modules. Interception of requests to the electronic key at the level of the electronic key driver (1) or USB bus driver (2) does not require any modification of each new version of the application, unlike the variant with interception of static API library calls (3).
Attack on the dongle driver
This type of attack is the simplest. The original electronic key driver is replaced with an emulator driver. Data transmitted to the key and returned back are intercepted and stored in a file on disk. Then the original key is removed from the computer and the program begins to interact with the emulator, continuing to sincerely believe that communicates with the key.
Turning to the particulars, I would like to dwell in more detail on the protection from software emulators in Guardant electronic keys. Guardant dongle drivers contain an electronic signature (ES). When you call Guardant API functions, the protected application automatically checks the driver signature in RAM. Since the private key is not known, it is impossible to create a driver emulator with the correct signature. The virtual machine (pseudocode), through which the executable driver files and the Guardant API libraries, is prevented from removing the check. The verification scheme is shown in Fig.2.
After the implementation of such protection in practice, software emulators have shifted to the USB-bus level (2nd version of the attack).
USB bus driver attack
The creation of such an emulator required the study of the exchange protocol between the dongle driver and the USB bus driver. Paradoxically it sounds, but in such a situation LPT-keys turned out to be more reliable, since The dongle driver directly interacts with the LPT dongle through the computer I / O ports, bypassing the intermediate driver.
Unfortunately, it is impossible to completely get rid of software emulators at the USB bus level using keys with symmetric cryptography. However, good protection, built on a constant exchange with an electronic key, may require more than one day to record all possible parcels and answers to the key and work for an illegal user at the most inappropriate moment. Hacked programs that stop working for unknown reasons, only to confirm.
Separately, I want to mention the protection, when developers are limited to a simple test of the presence of an electronic key. This is a blunder. Using the disassembler, “independence” can be presented to such a program in 15 minutes.
In electronic keys with asymmetric cryptography, the data exchange between the protected program and the electronic key is encrypted on the session keys. For this reason, the third option is the only possible attack.
Attack to intercept static library API calls
This attack is the most logical for keys with asymmetric cryptography. It is expedient only if the electronic key manufacturer takes care of the protection of its libraries, otherwise it is much easier to attack the library itself.
With the help of modern disassembler, you can quickly recognize the functions of the API in the program. And if so, then all function calls are easy to intercept. This means that access codes, requests and responses are still vulnerable. And if the program developer himself did not protect calls to API functions, then this is the best place to attack.
To exclude the possibility of intercepting calls to the static API library in a protected program, you need to combine the key functions of the application and the API functions into a single whole. Only then will it be really difficult to analyze the parameters, intercept calls or modify requests and responses to API functions. In practice, the development of protection is started after the main application code has been written. Very often, there is not enough time and, perhaps, desire for a deep integration of the interaction between the program and electronic keys. The least time consuming way to improve the quality of protection is to additionally use software tools that complicate code analysis. In this case, the interaction of the program functions and the functions of the static API library becomes difficult to understand.
Returning to Guardant dongles, let's say that all Guardant API libraries are protected from analysis and modification using a virtual machine. By virtual machine is meant pseudocode obtained from the original binary code of the program, and the corresponding interpreter. Pseudocode instructions can only be executed on the interpreter for which it was generated. The interpreter is responsible for protecting the pseudocode instructions and itself against modification using multiple integrity controls. All parameters of instructions, constants, addresses of transitions are decrypted on the hashes of the pseudo-code and interpreter fragments. To make analysis difficult, the pseudocode interpreter is protected using polymorphic obfuscation. The listed characteristics are implemented in a unique way in each copy of the virtual machine.
The pseudocode protection technology is available to anyone using the Guardant Armor service. This approach has a number of advantages: the protection tool is constantly updated and is not available for study. At the same time, developers who use Guardant dongles receive special benefits. The service allows you to protect the program's functions simultaneously with the functions of the Guardant API static library ( Guardant Monolith technology). The presence of the Guardant API library within the application is determined automatically, so no additional recompilation of the application is required. As a result, each time the application is protected, a unique copy of the virtual machine is created with its own instructions, constants, obfuscation, in which the logic of the program is closely related to the electronic key library. Now, in order to intercept calls to a static library or attack the library itself, you will have to deal with each defense individually.
Consider this on the example of a small test application, a fragment of which is shown in Fig.4. This example very clearly characterizes the vulnerability of calls to any static library within an application. The problem concerns all manufacturers of electronic keys.
Suppose that the application function
MyLogicAndVerifyDongle contains some software calculations using an electronic key. Work without this function is impossible, since it contains part of the key application logic. In this case, the function call is made from a less important part of the program code. To access the dongle, calls are made to the Guardant API static library. In this example, these are calls to the GrdRead and GrdCrypt . At the beginning of each function there is only a transition to the protected area VM_Start. However, the MyLogicAndVerifyDongle function MyLogicAndVerifyDongle remains unprotected and may be subject to attack.Now let's protect the API functions and key functions of the application using Guardant Online service. A fragment of the protected application is shown in Fig. five.
After protection, the
MyLogicAndVerifyDongle function MyLogicAndVerifyDongle contains a transition to the protected area Guardant_VirtualMachine . The addresses where the executable function code was previously located are garbage instructions. The function itself is translated into pseudo-code and executed on the same virtual machine as the Guardant API functions. It is no longer possible to set breakpoints on calls to API functions, since transitions are hidden inside the virtual machine. This means that hacking the program will have to unwind the entire logic of the virtual machine, and it is an order of magnitude more complicated than just intercepting API functions.findings
A number of recommendations for building reliable protection.
1. It is necessary to use static API libraries in the program. API library calls must be tightly integrated with the logic of the program being protected - this is a guarantee of creating persistent protection.
2. It is better to use keys with asymmetric cryptography, since for them there is no easy way to create tabular emulators.
3. Application code and static API library must be protected from analysis using software protection tools, where there is no simple ability to intercept API function calls in the program. For developers using Guardant technology, the ideal solution is Guardant Monolith.
Source: https://habr.com/ru/post/138641/
All Articles