Cryptography is an important part of today’s IT world. It is essential to ensure the protection goals of confidentiality, integrity and authenticity. Current cryptography algorithms are considered mathematically secure. Even if the NSA, Google, and Amazon join forces, it would take them billions of years to crack algorithms like AES-128. Why do you keep reading about security vulnerabilities related to cryptography?
The problem usually lies in the implementation and configuration. More precisely, the most common problems can be divided into the following categories:
Configuration errors or poor parameter selection can weaken a cryptosystem. Here are two examples of symmetrical and asymmetrical cryptosystems:
Often old cryptographic algorithms are still used in order to be compatible with old devices and software. Mozilla and the BSI recommend the use of TLS 1.2 and 1.3. Still, many still use TLS 1.0 or even SSLv3 for backward compatibility. But even TLS 1.0 can still offer an acceptable level of security and still a high degree of compatibility if the insecure cypher suites are removed.
Cyphers that use hash procedures such as MD5, SHA1 or cryptographic algorithms such as DES, RC4 and AES in ECB mode should not be used. So-called null, anonymous or export processes must never be used. Null procedures are only there for test purposes; no encryption takes place here. Anonymous methods do not authenticate the server.
An attacker can take advantage of this and push himself into the connection unnoticed (man-in-the-middle) and transmit his public keys to the other sides. He can now read and change the content of the messages without it being noticed. Export processes have drastically limited key sizes and can be cracked in a few minutes with the appropriate hardware.
Modern symmetric cryptography is based on the encryption idea of the OneTimePad. Since it is not very practical to exchange key material in the length of the message with the recipient first, pseudo-random number generators (PRNG) are used.
Insufficiently good random numbers, however, can lead to the encryption being cracked, as happened in the Debian OpenSSH debacle. Even if good random numbers are generated on the system, appropriate functions must still be used. Most programming languages offer several methods for generating random numbers. Only functions that access the operating system’s entropy pool are suitable for cryptography.
For example, in Java the java.security.SecureRandom function must be used instead of java.util.Random.
The best-known example of unused random numbers is the PlayStation 3. It uses the ECDSA (Elliptic Curve Digitial Signature Algorithm) based on elliptic curve cryptography to sign executable files.
A nonce (random number, which should only be used once), k, is included in the calculation of the signature. However, this random number k was constant on the PlayStation 3.
If an attacker succeeds in obtaining two signatures with the same k, he can determine the value of k. If he knows k, he can calculate the private key. The attacker can thus sign his own programs and, in the case of the PlayStation, circumvent the restriction on the use of official software.
Another pitfall is the plethora of different algorithms that exist and from which one must carefully choose. For example, passwords should be hashed and saved. There are hash algorithms such as Argon2 or Scrypt that have been specially developed for the secure hashing of passwords. However, they are unsuitable for hashing large amounts of data due to their slow speed.
Due to a large number of possible security gaps in the field of cryptography and the potentially great damage that can result, it is advisable to consult an expert who will examine the use of cryptography in the product.
If an attacker can physically access the hardware in which cryptography operations take place, he can attempt side-channel attacks. In a side-channel attack, it is not the algorithm itself that is attacked, but its physical implementation: the attacker tries to draw conclusions about the key or plain text from the data that the chip generates during cryptography operations.
This data can be the duration (timing attack), the power consumption or the electromagnetic radiation during the operation. It is even possible to draw conclusions based on the noises made by the chip. The following image file shows the power consumption using a power calculation.
Binary exponentiation is often used in order to calculate this as quickly as possible. The exponent is broken down into ones and zeros and then worked through step by step. In this picture, the exponent is 11000 so 24 in the decimal system.
For every 1 it is squared and multiplied. With a 0, however, only multiplied. This requires different amounts of electricity or takes different times. With a trained eye, the exponent can be derived from the power consumption analysis. Exponents play a major role in RSA, for example. Textbook RSA encrypts a message m as follows: c = me mod n. The decryption is done by m = c mod n. An attacker can find out e or d through the analysis. If he can carry out a stream analysis during decryption, he comes into possession of the private key d and can decrypt the message.
Differential Power Analysis is even more effective. This is based on the fact that processing numbers use different amounts of electricity. The more ones there are, the higher the power consumption. However, this effect is so minimal that the fluctuations make it impossible to detect it. However, if the measurement is carried out several 100 times, the fluctuations can be calculated out. This makes it possible, for example, to recalculate the AES 16-byte key.
The side-channel attacks presented can be made more difficult relatively easily by random dummy operations. There are also a number of side-channel attacks based on error induction, as well as mitigations against it.
Despite secure cryptosystems, errors occur due to many things that should be observed but are often unknown to developers. Under no circumstances should developers give up and develop their own cryptography systems, as experience shows that these are often more prone to errors.
Current, secure cryptographic algorithms must be used and implemented according to best practice guidelines. If you want to be on the safe side, it is advisable to have this tested later by external penetration testers and cryptographers.
As someone who’s spent years working in an office setting, I’ve seen firsthand how energy… Read More
Background checks are a staple in the hiring process. They can make or break a… Read More
There's so much talk about AI at the moment, with a lot of opinions on… Read More
Improving user experience (UX) is not just about making things look pretty; it's about creating… Read More
In the incessant whirlwind of technological advances, where new smartphone launches follow one another at… Read More
What should organizations consider while searching for answers to secure their cross-breed server farm? Against… Read More