Random Numbers

When we started our look at cryptography in .NET, we began by looking at random numbers. Secure random numbers are essential to modern cryptography as we depend on this ability to create encryption lets for our symmetric algorithms like AES, keys for HMAC and salts for password hashing. The most common random number generator in .NET is the System.Random class, but while this is fine for generating a set of lottery numbers or simulating a dice roll, the results it produces are very deterministic unless you provide a different seed value every time. The ideal random number generator to use in the .NET ecosystem is the RngCryptoServiceProvider that offers a cryptographically secure means of generating non-deterministic random numbers for encryption keys.

Hashing and Authentication

You should not be able to find two input messages that result in the same hash code. Another way to frame the concept of a hash function is to think of it as the digital equivalent of a fingerprint for a piece of data. Once you have generated a hash code for that piece of data, the hash code is always the same if you calculate it again, unless the original data changes in any way, no matter how small that difference is.

The process of calculating a hash code (or message digest) of an item of data is straightforward to do in the .NET Framework or .NET Core. There are different algorithms you can use in .NET such as MD5, SHA-1, SHA-256, and SHA-512. The properties of hashing, such as only being able to hash in one direction and the hash code is unique to a piece of data, makes hashing the perfect mechanism for checking the integrity of data. The integrity checking means when you send data across a network to someone else, you can use hashing as a way to tell if the original data has been tampered with or corrupted.

Before sending the data, you calculate a hash of the data to get its unique fingerprint. You then send that data and the hash to the recipient. They then compute the hash of the data they have received, and then compare it to the hash you sent. If the generated hash codes are identical, then the data has been successfully received without data loss or corruption. If the hash codes fail to match up correctly, then the data received is not the same as the data initially sent.

For the examples in this book, we used the secure hash based on generating a 256-bit (32-byte) hash code (SHA-256). If you need to use a higher strength hash, you can swap out the hashing code to use SHA-512 because the coding interfaces are the same between them.

Storing Passwords

Storing passwords in a database is a very common task for our systems to perform, but this task is so commonly done badly that it leaves the integrity of our systems exposed when passwords are leaked in a data breach. We started our exploration of securely storing passwords by examining some of the bad ways to do it. Let’s remind ourselves of these bad techniques.

The first and the worst solution is to store passwords as plaintext in a database. Doing this offers no protection at all should your database tables get leaked in a data breach. Sadly, there are a lot of old websites out there that do use this plaintext technique, but for a new system under your control, you should never do this.

The next technique that we looked at, which is better than plaintext passwords is basic hashing of passwords. A hash is a one-way function, where once a password has been hashed, you shouldn’t be able to go back the other way to recover the password. This principle works in theory, but plain hashed passwords are relatively easy to recover by performing either a brute-force attack or a rainbow table/dictionary attack. Many people use simple passwords, such as a spouse’s name or a pet’s name, which are very susceptible to attack. If you use a long and complex passphrase, you are afforded a little more protection, but not by much. Modern password cracking tools like Hashcat are designed to use the powerful graphics processing units (GPUs) built into modern graphics cards. These GPU cards allow tools like Hashcat to perform billions of hashing operations per second and as these graphics cards get more powerful each year, standard hashed passwords get easier to crack.

To try and remedy the ease of cracking hashed passwords the next technique builds on hashing by the inclusion of a salt to the password before hashing. The salt is a random piece of data that adds entropy to the password making them much harder to brute force or perform a dictionary attack. Salting a password makes their cracking much harder to perform, but with GPU hardware power increasing every year, what is considered a safe password today, could be cracked and compromised in a few short years.

The final option was a variation of the salted hash using a technique called a Password Based Key Derivation Function (PBKDF2). The main difference, compared to a SHA hash, is you specify a “number of iterations” parameter. This parameter is the number of times the hash is repeated. So, if that number was 10, then the password and salt combination is hashed ten times. The intention with this iteration parameter is to slow down the hashing process which means if someone does get a copy of your password table, instead of performing billions of passwords hash cracks per second you drastically reduce the number that can be attempted per second making the cracking process much less desirable to a would-be hacker. The .NET object that we used to generate one of these PBKDF2 password hashes was Rfc2898DeriveBytes.

Symmetric Encryption

We have discussed how hashing and hashed message authentication codes are one-way operations. Once you hash some data, you shouldn’t be able to reverse the hash to go back to the original data. Symmetric encryption algorithms, on the other hand, are a two-way operation where you use the same key for both encryption and decryption of your message; you can reverse the encryption process to recover the original data provided you use the same key, which is why it is referred to as symmetric.

Symmetric encryption has both advantages and disadvantages to its use.

Asymmetric Encryption

Symmetric encryption is a two-way encryption process that uses the same key for both encryption and decryption of your message. The main problem with symmetric encryption is that of securely sharing keys. For a recipient to decrypt a message, they need the same key as the sender, and this exchange of keys can be difficult to do securely. An excellent solution to this problem is to use asymmetric cryptography, which is also referred to as public key cryptography.

With public key cryptography, you have two keys; a public key, which anyone can know, and a private key, which only the recipient of a message knows. These keys are mathematically linked. The message sender uses the public key to encrypt a message, and the recipient uses their private key to decrypt the message.

The word asymmetric is used because this method uses two different linked keys that perform inverse operations from each other whereas symmetric cryptography uses the same key to perform both operations.

It is quite straightforward to generate both the public and private key pair, but the power of asymmetric cryptography comes from the fact it is impossible for a private key to be determined from its corresponding public key. It is only the private key that needs to be kept secret in the key pair.

The primary advantage of using asymmetric encryption is that two parties don’t need to pre-share a secret key to communicate using asymmetric encryption. The person encrypting a message only needs to know the recipients public key which is available to anyone on request. Then only the recipient can decrypt the message with their private key. The main disadvantage is that the asymmetric algorithm is comparatively complex when compared to symmetric encryption which means that messages take longer to encrypt and decrypt.

When using RSA in .NET, we used the RSACryptoServiceProvider class. We looked at three ways of handling our keys, using the Windows CSP to store keys, writing them out as XML (a really bad idea), and storing them in memory.

Digital Signatures

Digital signatures are based on asymmetric cryptography. For the receiver of the message, a digital signature allows the receiver to believe the correct sender sent the message; this can be thought of as a digital equivalent to a signature on a letter, except a digital signature is much harder to forge.

Digital signatures give you both authentication and non-repudiation. Authentication because the signatures have to be created by a user with a valid private key, and non-repudiation as the receiver can trust that a known sender signed the message as only, they know the private key. So, how do digital signatures do all this? Digital signatures in .NET and .NET Core are based on RSA, so some of the same rules for RSA apply for digital signatures. This is why you cannot sign data that is larger than the size of the key; that is, 1024 bits, 2048 bits, or 4096 bits. Because of this, it is common first to take a SHA-256 hash of the data that you want to sign digitally. You then use that hash to create the digital signature.

When you use RSA to encrypt data, you use the recipient’s public key, and then the recipient uses their private key to decrypt the data. It is the other way around with digital signatures, to create the signature the sender uses their private key to generate the signature, and the recipient uses the sender’s public key to verify the signature.

The digital signature implementation we looked at in .NET was based on RSA, so to generate the keys we use the same process as with RSA which is to use the RSACryptoServiceProvider class. The generation of the digital signature is handled by the RSAPKCS1SignatureFormatter class, and the verification of the digital signature is handled by RSAPKCS1SignatureDeformatter.

Hybrid Encryption

Once we had finished covering the main cryptographic primitives to cover our four pillars of cryptography (confidentiality, integrity, authentication, and non-repudiation), we then looked at combining these primitives to create a more powerful set of tools called hybrid encryption.

First, we looked at combining RSA and AES. Sharing keys securely between two or more people is very hard to do.

For asymmetric encryption, the actual process of encryption is much slower due to the modular based mathematical nature of the RSA, and there are limits to the amount of data that you can encrypt at once. A real benefit for RSA is how keys are managed. With RSA, you use a public and private key pair. The recipient of the message knows the private key, and they keep that key safe and secret; anyone can know the public key. If Alice wants to send a message to Bob, she first gets his public key. Encrypts the message with that public key and sends the message to Bob. Bob then uses his private key to read the message; which is a much better solution to keys exchange than with symmetric encryption algorithms like AES.

Now we want the best of both worlds. We want the fast and efficient encryption properties of AES coupled with the more robust key sharing mechanism of RSA. We explored hybrid encryption, which is achieved using unique symmetric session keys along with asymmetric encryption.

The sender first uses the recipient’s public key to encrypt a freshly generated AES session key. The data you want to send to the recipient is encrypted with AES and that session key, and that encrypted message along with the RSA encrypted session key is sent to the recipient who then uses their private key to decrypt the session key. Once the session key is recovered, it is then used to decrypt the message.

The combination of encryption methods has various advantages. One is that a connection channel is established between two users’ sets of equipment. Users can communicate using this hybrid encryption technique. A downside of asymmetric encryption is that it can slow down the encryption process, but with using it along with symmetric encryption, both of them together use their best parts, the efficiency of the symmetric encryption and the key splitting of the asymmetric encryption. The result is added security to the message sending process along with overall improved system performance.

To further extend the hybrid encryption example we added some integrity checking to the code. We wanted to add some integrity checking to ensure that the message that is sent between two people is not corrupted or tampered with in transit.

The simplest way to do this is by taking a hash of the encrypted data and the initialization vector, which could be done using any of the hashing operations, such as MD5, SHA-1, or SHA-2. The hash would be calculated after the message has been encrypted with AES and sent to the recipient inside the encrypted packet.

When the recipient wants to decrypt the message, they first recalculate the hash of the encrypted message and IV. If the hashes match, then the data is intact and hasn’t been corrupted or tampered with which means the recipient can safely decrypt the message. If the hash codes do not match, then there has been an issue during transmission of the message; it has either been corrupted or tampered with, and the recipient should discard the message entirely and not trust it.

As a solution, this worked quite well, but we went one better. With the solution of hashing the encrypted data and initialization vector, nothing is stopping an attacker intercepting the message, corrupting the encrypted data or IV and then recalculating the hash. It would be much better if the strength of our session key could also protect the hashing of the data; this is possible by a hashed message authentication code or HMAC.

Like a standard hash code, a HMAC is used to verify the integrity of a message. A HMAC also allows you to verify the authentication of that message because only the person who knows the private key to recover the session key can calculate the same hash of the message. Without that session key, you cannot recalculate the same hash code of the encrypted data. A HMAC can be used with different hashing functions like MD5 or the SHA family of algorithms. In the examples in the remainder of this chapter, we use SHA-256. The cryptographic strength of an HMAC depends on the size of the key that is used.

Extending our example using HMACs for integrity provided a lot of benefits when it came to sending data from the sender to the receiver because we can detect if the encrypted messages have been corrupted or tampered with. By using a HMAC, we can ensure that the recipient can only recalculate the HMAC if they first recover the session key using their private key.

Next, we extended the example by incorporating non-repudiation with digital signatures. This means that before the sender sends the message to the recipient, the sender first takes a digital signature of the HMAC using her private key. When the recipient receives the packet of data and verifies the digital signature, if it returns true, he is confident that the original sender sent the message, and not someone else.

Combining all the cryptographic primitives this way gives you the ability to create systems that not only encrypt data but can also move that data securely between systems and detect authenticity and the potential for any tampering.

Azure Key Vault

Key management is an essential feature of any enterprise system and there are appliances like hardware security modules (HSM) that let you store keys securely. The problem with HSMs is that they are traditionally costly appliances for companies, which means they are typically used by larger organizations, such as banks or pharmaceutical companies. With the advent of cloud computing and products like Azure, we now have access to abstract HSM systems like Azure Key Vault, which brings the power of HSM to the masses.

Azure Key Vault is a service provided by Microsoft as part of their Azure cloud computing platform that makes the functionality of hardware security modules available to anyone for a fraction of the cost. Even though Microsoft is providing software abstraction to the service, underneath there is real HSM hardware. Microsoft has put into each regional data center a series of devices called nShield by Thales Security, which means that Microsoft has taken the financial hit on the cost of the hardware that they rent for a minimal price to software developers. The fundamental shift between you paying for a HSM to a pay-as-you consume module has enormous implications as this means you can now take advantage of secure key management that banks have been enjoying for many years.

Azure Key Vault lets you store encryption keys and secrets, which are encrypted blobs of text where you can safely store secret information like database connection strings or API keys to third-party systems. Azure Key Vault then lets you perform different operations as a developer such as encryption and decryption, storage and retrieval or secrets and the generation and verification of digital signatures.