How can cryptography be applied to authentication

Basics of cryptography

Everything that is used today in terms of encryption in the IT sector, such as SSL, SSH, VPN's, PGP or GnuPG, is based on certain cryptographic procedures. If you know the basic principles of cryptographic procedures, these techniques can be better understood.

In general, cryptography describes procedures for generating a cipher from a given plain text. Nowadays, a mathematical process is always used to generate the cipher. Steganography is not part of cryptography. It describes options for sending a message via hidden channels, such as another (harmless) message. Usually, a file is hidden in another file for this purpose (for example a text file that is hidden in the bit sequences of an image file). Steganography and cryptography can be combined with one another.

Both a key and an encryption algorithm are usually used for a cryptographic process. The algorithm is the applied mathematical procedure, the key is used for the concrete encryption or decryption of the message.

cryptographic procedures

Basically, 3 different cryptographic procedures can be distinguished: symmetrical cryptography, asymmetrical cryptography and so-called hash or fingerprint procedures.

symmetric cryptography
Methods that use the same key for encryption and decryption are referred to as symmetric cryptography. These procedures are the oldest, but have one disadvantage: everyone involved in the communication must know the key. The key itself must have been exchanged beforehand via a secure channel, for example through personal contact. As the number of communication participants increases, this becomes more and more difficult to handle. Typical algorithms for symmetrical encryption are DES, 3DES, Blowfish, Twofish and AES.
asymmetric cryptography
Asymmetric cryptography is the term used to describe processes which each require a different key to encrypt a message and to decrypt the message. For asymmetric procedures, key pairs are formed, each with a public key and a private (or secret) key. Everything that has been encrypted with one key can only be decrypted with the other. This allows the public key to be made known. Other people can encrypt their messages with the key holder's public key and send them to him. As long as only the key holder is in possession of the private key (which must be protected accordingly), only he can decrypt the message. Asymmetric methods are more computationally expensive than symmetric methods. The mathematical possibility for asymmetrical procedures was discovered later than the symmetrical procedure. Common asymmetric algorithms are RSA and DSA.
Hash method
Hash processes, also known as fingerprint processes, are algorithms that work without a key and repeatedly generate the same cipher from a specific plain text. The cipher is not reversible, i.e. the plain text can no longer be determined from the cipher. Such methods are therefore suitable, for example, for encrypting passwords or for determining the integrity of a file or message. Typical algorithms for this are MD5 and SHA1.

Security of procedures

Uninformed people often believe that the security of an encryption only depends on the length of a key (measured in bits). In fact, the key length is generally only a minor part of what makes encryption secure. The essential part of security depends on the algorithm used. Cryptographic algorithms are based on extremely difficult to solve mathematical problems. An algorithm is considered to be sufficiently secure if the effort to calculate the key with the computing power available today or probably in the next few years is so great that a no longer manageable period (e.g. millennia) would be necessary to calculate the key. Of course, this also means major breakthroughs in the performance of computers, just as advances in mathematics can make processes that were previously considered safe become uncertain.

In order to prove the security of an algorithm, it is therefore common to publish an algorithm and to find a weak point through as many mathematicians and cryptologists as possible. Algorithms based on secrecy can never be as secure as an algorithm that has been published and yet has not been exposed as too weak by any mathematician. If new cryptographic algorithms are to be introduced as a standard, competitions are therefore usually held among cryptologists, in which each contribution has to withstand the critical eyes of the others. Such a competition made AES, for example, the successor standard to DES. Currently (2011) there is also a competition running for a successor to the SHA1 standard, which is to be standardized as SHA3.

The publication of encryption algorithms for general assessment also prevents the possibility of building a back door into an encryption algorithm so that those who know about the back door can still access the content of an encrypted communication. When publishing an algorithm, a backdoor would be discovered sooner or later.

Of course, it is also possible (but rather unlikely) that a cryptologist discovered but not published a weakness in an algorithm that was considered to be secure and that all of his colleagues overlooked. It is therefore quite conceivable that organizations that have a considerable interest in cracking encryption and that have considerable resources, as well as experienced cryptologists, will find weaknesses in encryption before they become generally known. One organization to which this applies is the NSA.

DES (Data Encryption Standard) was the first standardized algorithm for symmetric encryption. It uses a 56-bit key. DES was developed in collaboration between IBM and NSA. The involvement of the NSA and the design of the algorithm, which showed some fundamental weaknesses together with the key length of only 56 bits, gave room for speculation right from the start that the NSA wanted to establish an encryption standard that could be cracked by itself. DES is nowadays outdated and more or less crackable. A data stream encrypted with DES can still not be cracked in real time, but it can now be decrypted with sufficient computing power in a reasonable time frame. In 1998, DES decryption was demonstrated in less than 3 days for the first time. Nevertheless, a DES-based algorithm called 3DES (or Triple-DES) is still often used in practice. With 3DES, DES encryption is used three times, which also leads to a key that is three times as long (but does not automatically lead to triple security).

AES (Advanced Encryption Standard) was therefore chosen as the successor to DES. AES was determined through a competition between cryptologists. The process known today as AES was called Rijndael before its introduction as the standard. Another promising final candidate in the AES competition was Twofish (a further development of Blowfish). AES is generally considered unbreakable to this day (this also applies to Twofish and Blowfish). AES can optionally be used with key lengths of 128, 192 or 256 bits.

In cracking the MD5 and SHA1 hash processes, major successes have been achieved in recent years. These procedures are therefore no longer considered to be sufficiently secure and should be replaced by others in the future. For this purpose there is currently (2011) a competition to determine an algorithm for the new standard SHA3 (SHA2 exists, but has never been standardized). In general, SHA1 can currently still be classified as somewhat more secure than MD5.

The asymmetrical procedures that are common today, such as RSA and DSA and also elliptic curve cryptography, are currently still considered sufficiently secure and unbreakable. In the future, however, this could change with the development of so-called quantum computers, which could perform the underlying arithmetic operations many times faster. However, there are currently no functioning quantum computers.

In general, the following applies to all security measures: The security of the weakest point determines the overall security. This also applies to cryptography and has the consequence that even if algorithms that are considered to be secure are used, attackers could reach their target via channels other than the encryption itself. If, for example, data is exchanged between two systems with secure algorithms over the network via SSL, it is practically hopeless that an attacker can intercept the data transmitted via SSL, but the use of a Trojan on one of the two computers involved promises the attacker a much greater chance of success. The data is decrypted on the target computer so that a Trojan can simply read it along. Instead of the pointless attempt to crack a non-crackable encryption, the attacker has found a much easier way to achieve his goal.

application

Encryption can be used at very different points in computer systems. To see what a specific application of cryptography can look like, four application examples are explained here: SSL, email encryption, email signing and password encryption.

SSL (Secure Sockets Layer) is network encryption. Plain text data is encrypted on one system before it is sent through the line and decrypted again on another system. SSL uses a hybrid method that combines asymmetric and symmetric cryptography. Symmetric cryptography has the advantage of being quick and easy. If 2 systems want to communicate via network and want to use symmetrical encryption, they both have to use a common key. Now the problem arises that every key that is exchanged beforehand in plain text can also be intercepted by someone else who is eavesdropping on it. Asymmetric cryptography solves this problem: When establishing a connection, asymmetric cryptography is used to exchange a key for symmetric encryption. A switch is then made to symmetric encryption, which is faster and requires less computing power than asymmetric cryptography. In order to enable the initial key exchange via asymmetric cryptography, at least one of both sides (normally the server to which the connection is to be established) has a key pair consisting of private and public keys. The server sends the public key to the client. This can now generate a session key for symmetrical encryption and encrypt it with the public key. Then it sends the result to the server. Since only the owner of the associated private key can decrypt a text that has been encrypted with the public key, only the server can determine the session key encrypted by the client. Server and client now have a shared session key that no one else can know and with which a symmetrical connection can be established. The actual procedure used is a little more complicated, but only the principle is explained here.

Asymmetric cryptography is used for email encryption. The person who wants to receive encrypted emails has to generate a key pair in advance. The public key is then published. For example, key servers that are publicly accessible and contain public keys to email addresses can be used for this purpose. It is also possible to send the public key to all friends via unencrypted email. Someone who would like to send an encrypted email to this mail recipient must use the public key to encrypt his email. The mail recipient can then open the message with his or her private key. Since only he is in possession of the private key, no one else can decrypt the message; this naturally also applies to the original sender, who can, however, keep an unencrypted copy of the message instead. If the recipient wants encrypted replies, he must use the public key of the original mail writer.

A signature is a type of electronic signature. It confirms that the message was actually written by the author. Signing works in a similar way to encryption with asymmetric keys. Signing takes advantage of the fact that the private key is only known to the key creator. To write a signed email, the sender encrypts the email with his private key. Since everything that has been encrypted with one key of a key pair can only be decrypted with the other associated key, the mail text can then only be decrypted again with the public key. But since the public key is public, it seems strange why something should be encrypted with the private key. The point, however, lies in the verifiability of the possession of the private key. The email is sent as a file with 2 versions: on the one hand the unencrypted mail text and on the other hand the mail text encrypted with the private key. The recipient can now decrypt the encrypted mail text with the public key and compare this text with the unencrypted variant. If both match, the sender must be in possession of the associated private key, otherwise the mail text cannot be correctly decrypted with the public key. Since the private key is secret, the sender confirms his identity.

In order to check passwords as they are entered, they must be saved on a system. Since such a password store is a primary target for attackers, the password file must be protected as well as possible. In addition to the restrictive setting of rights to the password file, the encryption of the passwords in this file also serves this purpose. Hashing algorithms are mostly used for password encryption. Since hashing algorithms cannot be reversed, how does the system know the password to be able to check entries? The answer is simple: it doesn't even know, but when a password is to be checked, the same hash process is used on the password to be checked. If the resulting hash of the password is identical to the one saved, the entered password is correct.

Despite the encryption of password files, they should never be publicly accessible, as encrypted passwords can also be determined via so-called dictionary attacks. Password encryption is an additional hurdle for cracking passwords, but the main obstacle for an attacker is always to get to the file. If the attacker has the file, he can use pre-calculated hashes of frequently used passwords in order to determine them more quickly. So-called salted hashes are often used to prevent this. A salted hash contains an additional random component (the salt) and thus prevents the use of pre-calculated hashes. The random component is also saved in the password file. The stored password hash is then the hash value from the combination of the random value and the actual password. When checking a password, the random value is read from the password file and combined with the password. The hash obtained from this can again be compared with the stored hash. It is important that the random value is different for each user. As a result, the same password leads to a different hash value for different users. An attacker cannot use precalculated hashes, but has to go through all options for each user individually.

Since the usual hash procedures MD5 and SHA1 are no longer considered secure enough, symmetrical encryption procedures such as Blowfish are now also used as password encryption on some systems. The password is not used as a key, but as plain text to be encrypted. The key is then usually a sentence that is always the same and is also generally known. In this way, a hash process is created from a symmetrical process.

When transmitting passwords over the network, hash processes can also be used so that the password is not transmitted in plain text. For this purpose there are so-called Challenge / Response procedures. With a Challenge / Response procedure (for example CRAM-MD5) the server sends a random number (the so-called challenge) to the client who wants to authenticate itself. The client combines the random number with the password and uses it to determine a hash value. The hash value is transmitted to the server. For its part, the server has also determined the hash value from the random number and the password it knows. If the value determined by the server matches the value transmitted by the client, the client has successfully authenticated itself. This way the password never has to be sent over the line in clear text. In addition, it is also not possible to send the same hash value again, as the random number will be different again the next time the client is authenticated. A disadvantage of this method is the fact that the server must know the client's password in plain text, which requires that the password was also stored in plain text on the server.

PKI and Web of Trust

Network encryptions such as SSL always have to solve two problems: The actual transport encryption and ensuring that communication takes place with the correct communication partner (authentication). Why is that?

The purpose of network encryption is to protect the transmitted data from being viewed by others. However, if a potential attacker cannot access the data in the network, he can try to gain access to the data. For example, it could try to pretend to be the target server. In this case, the client would establish the connection to the attacker instead of to the actual target. Since SSL decrypts the data at the destination, encryption does not help in this case. The attacker can read the data in plain text. In order not to arouse suspicion, it can also forward the data to the actual target server. This scenario is known as a man-in-the-middle attack, because the attacker sits like a proxy between the client and the server and can read all data in plain text despite encryption.

To prevent this, asymmetric cryptography is also used during the establishment of an SSL connection to check the identity of the server. The public key used by the server serves as proof of identity. The public key of the server is signed by a trusted third party of the Certificate Authority, or CA for short. The CA itself has a key pair for this purpose. The CA's public key is made public so that everyone can use it. If a server operator wants to sign his public key, he contacts the CA. The CA verifies his identity. This check can turn out differently, but it is an essential point that guarantees the security of the system. Once the CA is satisfied that the server's public key really belongs to the domain for which the certificate is to be issued, the CA signs the server's public key with its own private key. This turns the server's public key into a so-called certificate. A client can verify the certificate by verifying the signature with the CA's public key. If the signature is correct, this means that the CA confirms the identity of the server.

In order for a client to be able to do this, it must know the public keys of all CAs. In web browsers, for example, these are located in the certificate store. In Firefox this can be found via the Firefox settings under Advanced -> Encryption tab -> Show certificates button -> Certification authorities tab. This also means that the browser manufacturer has already made the decision for me which CAs I trust and which not.

This complete system is called Public Key Infrastructure, or PKI for short.

The weakest part of a PKI solution is always the CA. The CAs are mostly commercial companies that issue certificates for money. Of course, they want to make it as easy as possible for their customers to identify themselves. How exactly a CA checks the identity of a customer is of great importance for trust in the certificate. The CA's private key is a key that must be particularly well protected. Should an unauthorized person get hold of this key, he could issue any certificates that would be accepted by any client as valid and trustworthy certificates.

Of course, it is also possible to operate a separate CA for an internal structure within an intranet. The certificates of this CA would not be recognized by external clients, but this does not matter in an intranet. The public key of the internal CA could be distributed to all internal clients, which means that they see the key as trustworthy.

If a client program reports an unknown certificate or an unknown certification authority, this can mean that either the issuing certification authority is not known to the client or that the certificate may have been signed by the server operator himself. The connection is still encrypted, the warning message only states that the identity of the server could not be determined beyond doubt. If you know that the certificate is correct, the server certificate can be added to the client's certificate store, which means that all future connections are checked for this certificate and the warning message is also omitted.

The Web of Trust is an alternative to a PKI. The Web of Trust is used, for example, by the PGP and GnuPG mail encryptions. In a web of trust, communication partners occasionally meet in person. If there is a face-to-face meeting, the communication partners sign each other's public keys. If, for example, Alice has now signed Bob's key and Conrad has signed Alice's key, Conrad can also trust Bob's key due to the trust in Alice's key. In this way, a web of trust develops over time, with the trust decreasing as the communication partner is removed from the web of trust.


René Maroufi, lecturer (at) maruweb.de