Vulnerability of cryptographic protection systems

 Currently, software protection methods based on the use of cryptographic algorithms are widely used. Regarding the effectiveness of protection of this class, I would like to cite the opinion of Chris Kaspersky, author of the book "The Technique and philosophy of hacker attacks": "These defenses look unbreakable. They "look" because developers do not take into account the difference between theoretical models and practical implementation... a lot of the cryptosystems used are unreliable, and almost all are vulnerable to one degree or another"[20, p. 30].

  The most common mistake of novice authors is decrypting the code of the protected program in its entirety before starting the main program and encrypting it before shutting down the program. To remove such protection, it is enough to get a memory dump at the moment after decrypting the executable program code and analyze the received codes.

          The password (key) stored in encrypted form is obviously also decrypted at some stage. With the help of the debugger, you can easily get the original password at the moment after decrypting it.

          Therefore, to enhance protection based on encryption of the program code or password, the following techniques can be recommended first of all.

* Block-by-block decryption. The decryption of the program code should be carried out in stages, part by part, ensuring that the fully executable code would never be in memory in open form.

* Encryption with feedback. It is necessary to implement a scheme in which the key for decrypting code fragments changes dynamically and depends on previously obtained values or conditions, for example, it is calculated as a function of the previous block (possible options).

* Use the checksum of the executable code to decrypt a piece of code.

* Experts propose to design part of the protection mechanism in the form of a resident module, whose task may include, for example, prohibiting writing to disk for some time or monitoring segment registers for changes. At the same time, it is desirable to organize protection so that the codes of the protective mechanism always fall into the dump along with the codes of the main program.

* Combining cryptographic methods with compression. In this case, a copy of the decrypted section cannot be entered in the same place.

______________________________

Let's focus on the technique of hacking programmers' favorite technique - encryption using the XOR operation. It is believed that the durability of the mechanism of such protection is determined by the choice of the key. That is, the authors strive to come up with a "more interesting" key, and "hide" it better. It doesn't really make sense. Since the protection is quite simply opened by an open-text attack. The hacking method is based on the specifics of the XOR operation. Let's remind you.      Text   xor  Key  = Shifr       

              Shifr  xor  Key  = Text

Now it should be noted that and

    Shifr  xor  Text = Key.

That is, knowledge of the open (source) text allows you to determine the encryption key. (Note that to find an eight-bit key, it is enough to know one (!) byte of plaintext.) When hacking the protection of a program, the intruder has an advantage: he can proceed from the assumption that some sequence of bytes occurs in plaintext. The range for checking is very wide - string messages can be used, for example, Ok, Copyright, etc., and the carriage return symbol, and interrupt commands, and much more.

          Experts have sufficiently studied the issues of the unreliability of cryptographic protection systems. Let's list the reasons for the unreliability of cryptosystems [24].

1. The impossibility of using persistent crypto algorithms.

The factors contributing to this fact are:

· low speed of persistent crypto algorithms;

· Export restrictions. For example, the export of cryptographic algorithms with a key length of more than 40 bits is prohibited from the United States, but a cryptographic algorithm with such a key length cannot provide even minimal reliability;

· using your own crypto algorithms. We have already noted the reasons for the weakness of our own crypto algorithms.

2. Incorrect implementation of crypto algorithms.

Examples of incorrect implementation are the following errors.

· Reduction of cryptographic strength during key generation. This refers to mechanisms in which the security system either truncates the user's password or generates a key with a shorter length from it.

· Lack of verification for weak keys. For many crypto algorithms, there are so-called weak keys, when using which the crypto algorithm does not have sufficient power. 

!

 It is necessary to check for weak keys.

 
· Insufficient protection against so-called destructive software tools, that is, programs capable of intercepting a secret key or unencrypted data and even replacing a cryptographic algorithm.

· There is a dependency on the key processing time. The point is that the cryptosystem can process different input data (key and/or directly encrypted data) for different periods of time. The hacker, measuring the processing time of various data, has the ability to select a key.

· Errors in the software implementation. (Murphy's law says: every program has at least one error.)

· The presence of hatches. As in any program, hatches in the protection system can be intentionally or accidentally left by the developer.

· Disadvantages of the random number sensor. To create a key, security authors often use a pseudorandom number sensor. In this case, the stability of the mechanism is affected by the initialization of the sensor, the short period and the poor spread of the generated numbers. 

!

 Experts do not recommend using your own random number sensor. Otherwise, at least the initialization of the sensor should depend on the physical quantities. It is recommended to use a hardware device, for example, a special board, to generate random numbers.

3. Incorrect use of crypto algorithms.

· Small key length.

· Storing the key together with the data.

4. The human factor.

As with any system, human user errors are the most common. For example, the user's choice of a short or meaningful password will reduce the most cryptographic algorithm to zero.

 So, when designing and implementing systems using cryptographic protection, the listed factors that cause insufficient reliability of protection mechanisms should be taken into account, as well as implementation errors should be avoided.