1. Cryptography (OBJ 1.7)
In this section of the course, we’re going to discuss cryptography and public key infrastructure. Throughout this section, we’re going to be focused on domain one security architecture, and specifically Objective 1. 7, which states that you must explain how cryptography and public key infrastructure, or PKI, support security objectives and requirements. Now, in this section, we’re not going to dive deep into the inner workings of cryptography, such as the protocols and the algorithms, because there’s an entire objective on the CAS Plus exam in domain Three that focuses on that. Instead, we’re going to be focused on the use of cryptography to secure our enterprise architecture and when we might use different types of cryptography such as symmetric key encryption, asymmetric key encryption, hashing, and public key infrastructure.
As a general rule, if you want to ensure confidentiality, you need to use cryptography to encrypt your data. If you want to ensure integrity, you need to use cryptography to hash your data. If you want to ensure identity, you need to use PKI to prove your identity. So as we move through this section, we’re going to discuss privacy, confidentiality, integrity, nonrepudiation compliance, and policy requirements. Then we’re going to focus on some common cryptographic use cases such as Data at Rest, data in Transit, and Data in Use.
We’ll also discuss use cases such as the protection of Web services, embedded systems, key escrow and key management, mobile security, secure authentication, and the use of smart cards. Finally, we’re going to talk about some common PKI use cases such as Web services, email code signing federation, trust models, VPNs and enterprise and security Automation and Orchestration. So get ready to discuss how we can best use cryptography and PKI to secure various systems, services and resources of our enterprise security architecture.
2. Privacy and Confidentiality (OBJ 1.7)
Let’s talk about privacy and confidentiality requirements and how they can be met using cryptography and public key infrastructure. First, what is privacy? When dealing with data security, we consider privacy to have been achieved if we have the ability to protect sensitive information about somebody’s personal, identifiable information. Now, confidentiality is considered to be more broad than privacy because we expand our definition to cover protecting data against unintentional, unlawful, or unauthorized access, disclosure, or theft of any sensitive information. Often, though, people are going to use these two terms interchangeably in the cybersecurity world of privacy and confidentiality. Now, in order to achieve privacy or confidentiality, we need to put security controls in place when we design our security architectures for our enterprise networks.
The most common technology used to protect privacy and confidentiality of our data is to implement encryption using cryptography and public key infrastructure. Now, cryptography is broken down into two main types based upon the type of keys that are used to protect the data. These are symmetric key encryption and asymmetric key encryption. With symmetric key encryption, the same key is used for both the person transmitting or storing the data and the person who receives or reads the data. For example, if you’re storing files on a BitLock or encrypted hard drive on a Windows computer, you’re using symmetric encryption to store those files on the drive and again to read those files from the drive. And you’re doing that with the same key asymmetric encryption instead uses two keys a public key and a private key, which is supported by a public key infrastructure or PKI system.
When you send an email to a colleague at work and encrypt it, you’re usually doing this using an asymmetric key. Now, first your email client is going to take the message that you want to send and it’s going to encrypt it using the recipient’s public key, which it gets by going to the PKI system. Then the message is sent over to the receiver and once it’s received, their email client will decrypt that message using their own private key. Because each person using PKI has both a public and a private key, this key pair can be used to encrypt and decrypt the contents of a message. If the public key is used to encrypt it, then the matching private key must be used to decrypt it.
This is how privacy and confidentiality is maintained because only the individuals themselves have a copy of their private key. But everybody can access their public key from a central authoritative server. This means only the person who’s receiving it and using their private key can actually open that message and read it. Now, when might you want to use symmetric key encryption versus asymmetric key encryption as your solution? Well, a symmetric key encryption system is preferred anytime you value speed, because it’s about a thousand times faster than an equivalently secure asymmetric key system. If you’re going to send a lot of data.
Using a symmetric key encryption is going to make a lot of sense because it can handle more data at any given time due to its increased speed. But if symmetric key is so wonderful, why do we even need asymmetric key encryption? Well, it comes down to the concept of key distribution. Remember, with symmetric key encryption, we’re using the same key to encrypt and decrypt the data. So if I want to send an email to you and I encrypt it using a symmetric key encryption, that means I need to have a way to give you that key before I send you the email. Otherwise you won’t be able to decrypt it.
Additionally, if I wanted to send an email to somebody else, let’s say my friend Scott, I need to share a different key between Scott and myself. So now the two of us are able to communicate privately without you or anybody else being able to read the messages we send. So now I have two keys. One for me and you, and one for me and Scott. So if I’m using symmetric key encryption for sending my emails, I’m literally going to need hundreds or thousands of different keys. And each individual key would need to be shared between me and the person I want to securely communicate with. As you can see, this gets to be really cumbersome and impractical pretty darn quickly. So instead, we use asymmetric encryption because now each person only needs to have two keys a private key and a public key.
Those public keys are, well, public. So anybody can have a copy of your public key. It can just be hosted on a centralized server. For example, now when I want to send you a message, I can connect to the trusted centralized server and get your public key. Then I use your public key to encrypt the message I want to send. This completely eliminates the key distribution challenges that are experienced with symmetric key encryption. But we still have the issue of speed because asymmetric encryption is a thousand times slower than symmetric key encryption. For sending emails, this really isn’t too big of a deal because it’s an asynchronous process anyway. But for other applications, this would create a massive bottleneck in our systems.
So to overcome this, we can use a hybrid solution and combine both symmetric and asymmetric solutions together. For example, let’s say you want to connect to an ecommerce website like Amazon. com. You’re first going to get a copy of Amazon’s public key from the centralized server. Your computer then chooses a long random string of numbers and encrypts that string using the public key for Amazon server. When the Amazon server receives that encrypted string, it can then use the private key that it has to decrypt it. This portion of the process is asymmetric, and we’re using PKI here. Now, the server takes that random long string and it uses that to initiate a secure encrypted connection.
Between my client using a symmetric key encryption method and their server. Now, we have securely exchanged a symmetric key since I just created it and I already know what it is, and then I send it over using an asymmetric model so that the server also has that key using PKI. This allows us to use the slower asymmetric encryption to do our key exchange, which is relatively a small amount of data, so the slower speed isn’t a major issue here. But once we both have that same shared secret, we can establish a symmetric encryption path between the client and the server and use that for the bulk of our data transfer, such as browsing on Amazon to buy a new textbook or even to watch some videos from the site.
In addition to encryption, enterprise architects also use authentication mechanisms like passwords, smart cards, key fobs, biometric verification, and others to ensure only authorized people can access a particular resource on a given network. So remember, encryption is the most commonly used technology when it comes to meeting the privacy and confidentiality requirements for your security architecture. To provide this confidentiality, you need to use either a symmetric key encryption algorithm or an asymmetric key encryption algorithm, where the sender of the data uses the receiver’s public key to secure that data.
3. Integrity and Non-repudiation (OBJ 1.7)
Let’s talk about integrity and nonrepudiation requirements and how they can be met using cryptography and public key infrastructure. First, let’s talk about integrity. What is integrity? Well, integrity is a characteristic of data that’s focused on the accuracy and completeness of that data. To protect the integrity of the data, you should design security controls that prevent data from being modified or misused by an unauthorized party. Here we’re, we’re focused on maintaining the consistency and trustworthiness of the data throughout its lifecycle.
The most commonly used method to protect the integrity of our information is to use a specific type of encryption algorithm known as a hashing function. Now, a hashing function or hash function is any function that can be used to map data of an arbitrary size to a fixed size. Now, each value returned by a hash function is known as a hash digest. And this serves as a unique digital identifier, or fingerprint that represents the data received as an input to the function. Common hashing algorithms include things like MD Five, Sha One, and Sha 256. With an MD Five hash, an arbitrary length message is the input to this hashing algorithm and you’re always going to receive 128 bit hash digest as the result. With Sha One, you’ll receive 160 bit hash digest, and with Sha 256, you’re going to get a 256 bit hash digest.
The larger the resulting hash digest, the less likely it is that two different inputs could create the same output. Now, if you have two different inputs that do create two identical outputs, this is known as a collision inside the world of hashing. So if I wanted to send you a file and I wanted to make sure that you knew that it wasn’t modified or changed from the time I sent it to the time you received it, we could use a hashing algorithm to do that. To do this, I would take the file that I intend to send to you and I’d run it through a hashing function to receive the hash digest. Now, when you receive the original file from me, you’re going to run it through the same hashing algorithm that I used, like MD Five or Sha One or Sha 256, and then you’ll receive a newly calculated hash digest on your system.
You can compare the digest that you calculated against the digest that I created prior to sending the file. And if they match, this means the file was sent and maintained its integrity throughout the entire process and it has not been modified or changed. This is because hashing functions are designed so that even if you add a single character, such as a white space or a period, it’s going to vastly change the resulting hash digest. So if they’re identical, it means nothing has changed. Now, there is one problem with relying solely on a hash function for integrity, and that’s the fact that I need a way to securely send you that hash digest that I calculated for the file that I did before I sent it.
How do I do that and make sure it hasn’t changed in process? Well, let’s say I wanted to send you a message and a hash, but it was intercepted by somebody using an onpath attack or a man in the middle attack. That attacker could modify the original file being sent and rehash it and replace my hash digest with the new one that they just created. And when you receive it, it’s going to match the one you calculate on receiving the file because both the file and the hash digest were changed. To solve this challenge, we use one of two methods. The first one is used when you’re providing the same file to a lot of different people, such as placing a file that’s going to be downloaded with the latest version of a piece of software onto your website.
In this case, you could simply post the file to your website and right before the file’s download link, you could provide the hash digest. This way, the person can download the file, run it through the hashing function on their system, and compare that result against the known good hash that’s posted on your web page. This is a useful method if you only want to rely on hashing functions and don’t want to rely on any complexity by adding PKI or other encryption mechanisms. Now, the second method involves the use of digital signatures, which relies on the use of PKI.
This is commonly used when you want to send an email to somebody and provide them a level of assurance that the integrity of the message hasn’t been changed. To create a digital signature for your email, your email client is going to take the message you wrote and run it through a hashing algorithm. Like the Shaw 256 algorithm, this creates the unique hash digest based on your message. Next, the client is then going to use the sender’s private key to encrypt the hash digest. This encrypted hash digest is appended to the email and is known as a digital signature. Note I did not encrypt the email message itself here because we’re focused on integrity, not confidentiality.
At this point, we’re going to take this hash digest that’s been encrypted with the sender’s private key, and that way anyone in the world who receives this message could look at that sender’s public key and decrypt this hash digest. And now they know that that message hasn’t been tampered with. So upon receiving this digitally signed email, your email client is going to retrieve the sender’s public key from the centralized server. It uses that public key to decrypt the hash digest that was encrypted using the private key. Next, the email client is going to run the email message through the same hashing function to calculate the hash digest. If the calculated hash digest matches the received hash digest, this indicates that the email message was not modified in transit and the message has good integrity.
In addition to knowing the message has good integrity, we also implement this as a form of nonrepudiation by using this digital signature. You see, nonrepudiation is the assurance that the sender of the message can’t deny the validity of the message or the fact that they actually sent it. After all, the only person who can encrypt this hash digest with the sender’s private key is the sender themselves because they’re the only person in the world who has their private key. So using a digital signature does provide you with both integrity and non repudiation. Because we have a hash which is used for integrity and we encrypted it using our private key, leading to non repudiation. But if we also want to provide confidentiality and privacy, we still need to encrypt the message itself when we’re sending it.
And we do that using the receiver’s public key. So that way only the receiver can decrypt the message using their own private key. This is where many people get a bit confused, and so you need to remember that to provide privacy and confidentiality, the receiver’s public key is being used to encrypt the message. To ensure that you have integrity of the message, you need to have a hash in that message. And to ensure you have non repudiation of that message, you need to encrypt the hash digest with the sender’s private key. If you do all three of these actions, we call this encrypting and digitally signing the message. Most email clients can be configured to support this as long as you have public private key pairs assigned to your users using a Pkibased system.
4. Compliance and Policy (OBJ 1.7)
Let’s talk about compliance and policy requirements and how they can be met using cryptography and public key infrastructure. First, let’s define what compliance and policies are. Compliance is the act of complying with orders, rules or requests. Normally, compliance is seen as part of your larger governance, risk and compliance program within your organization. Now, the basis of compliance is policies though, because we need something to act as the baseline for all the different orders, rules, and requests that we need to meet. A policy is the thing that we are working on. Complying with a policy sets the standards of behaviors for activities within your organization’s enterprise network, and it dictates how we must conduct cybersecurity as part of our security architectures.
There are several different policies that we are going to support through the use of cryptography and public key infrastructure. For example, your policies might dictate that all sensitive data types need to be protected for regulatory compliance or to comply with your own organization’s internal policies and procedures. To implement this, you might implement BitLocker to encrypt data at rest on your storage devices, or you might use SSL and TLS tunnels when moving data over the network from the server to a client. If your organization accepts credit card payments, then you need to meet the requirements for PCI DSS compliance, which includes strong cryptography and key management requirements.
This includes the protection of stored cardholder data by hashing Truncating or encrypting the information stored on a credit card. Additionally, anytime a cardholder data is going to be transmitted over an open or public network, such as the Internet, that data has to be encrypted. This is done by creating an SSL or TLS tunnel between the user’s web browser and the ecommerce processing server. Or if the credit card information is being sent over email, then PKI should be used to maintain confidentiality of that data. If your organization is in the financial services industry, you’re going to be affected by the Graham Leach Bliley Act or GLBA. This act states that financial service organizations are mandated with protecting the security and confidentiality of nonpublic personal information.
To achieve this, it’s considered a best practice to implement full disk encryption on any systems that store this type of data, to implement folder encryption on directories that contain highly sensitive data, to encrypt all sensitive data in your databases, and to use an encrypted VPN when transmitting data between networks. Another example is found in the Sarbanes Oxley act or Sox. This act states that publicly traded companies need to protect sensitive data related to their financial reporting. Again, this involves using encryption to protect sensitive data at rest and and transit, as well as conducting proper cryptographic key management to keep your encryption scheme secure. The final example we’re going to discuss here is the Health Information Technology for Economic and Clinical Health Act or High tech. This was introduced as a follow on legislation to HIPAA.
This regulation is focused on the use of encryption to protect patient health information, as well as the implementation of hashing to provide integrity of the data and digital signatures to provide nonrepudiation and authenticity of the data being stored, transmitted or processed. Now, there are many other laws around the globe that create regulations for companies to follow and comply with, but you’re going to find that most are requiring the same types of things protection for your data at Rest and in transit by using secure encryption schemes, proper key management to protect your encryption and decryption keys hashing to maintain the integrity of the data and the employment of digital signatures to provide nonrepudiation and authenticity for that data.
