CCT 124: Integrity Unhashed through Ensuring Message Authenticity with the CISSP (D3.6)

Could your passwords withstand a cyber siege by expert Russian hackers? My latest podcast episode serves as a wakeup call to the cyber threats looming over us, showcasing the recent breach of Microsoft's test environment. As Sean Gerber, I dissect the pivotal missteps in password management and underscore the lifesaving grace of multi-factor authentication. We then shift gears to the bedrock of cyber training, examining message authenticity and integrity controls. By unpacking the intricacies of message digests and hashing algorithms, I highlight how they are the unsung heroes in maintaining data sanctity from sender to receiver.

The digital realm's trust hinges on the integrity of digital signatures and certificates—crucial allies in the war against data manipulation. Tune in as I break down how hash functions like MD5 and SHA are your first line of defense on file-sharing platforms. But there's more: I pull back the curtain on the encrypted world of digital signatures, revealing their role in sender verification and message security. Diving into the complex trust web spun by Certificate Authorities and the X.509 standard, we explore how digital certificates serve as digital passports in the online world. Brace yourself for an enlightening journey through the landscape of email protection with S/MIME, ensuring that your virtual conversations are sealed, secure, and verifiably authentic.

Gain access to 30 FREE CISSP Exam Questions each and every month by going to FreeCISSPQuestions.com and sign-up to join the team for Free. 

TRANSCRIPT

Welcome to the CISSP Cyber Training Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is Sean Gerber and I'm your host for this action-packed, informative podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cybersecurity knowledge. All right, let's get started.

Speaker 2: 0:25 

Hey all it's Sean Gerber with CISSP's Cyber Training, and today we are going to be talking about some various aspects around message authenticity. We're going to get into message integrity controls, hashing algorithms, we're going to get into the overall piece of that, digital signatures, digital certificates and finally we're going to get into what we call S-MIME. Those are going to be the topics for today's podcast. Hope you guys haven't already been ready to hang on to this one. This one's going to be a fun one, but before we do, we're going to get into one topic that I saw from some news that was in the news just yesterday Actually, it was released on Friday is that Microsoft confirms Russian hackers have stole the source code and potentially some customer secrets based on their test environment that they have within their production and test aspects. So this came to light on, I guess in January is where it originally came out, but it sounds like the attack occurred in November of 23. Now, with that being said, it appears they leveraged a test environment that Microsoft had in place, for whatever reason that they're testing their production stuff, and they were able to leverage it from a password spraying model. So it basically got someone's password and they compromised it using known passwords that are probably out on the internet right now, and they were able to breach this information. Now there's, they were able to get in there. It appears that they were actually able to gain access to some of the source code of that what Microsoft had within that test environment. They didn't have multi factor enabled because it was a test environment, and I'm sorry, but they're just going to have to do better than this. I mean, we've I've dealt with developers in the past and one of the things that we've had is you have your production, you have your test environment and in many cases, you have your source, same source code that you use in a repository such as a Git lab, GitHub, and you end up having that that feeds into both of those product, those environments. Well, when you leverage, if you don't have the same level of controls that you have on your test environment that you have within your production environment, now you're in a situation where one they have access in some cases maybe not in this, but in some cases to the various code repositories that are available, because they have to do it in the test environment to then push it into production, and so it seems like they didn't have multi factor enabled. Well, having mob, having multi factor and then having bad passwords on your test test environment, it's just a bad idea. And you've got that. What that also shows is that they're not enforcing any sort of password complexity to the level that they do in their production environment. So it's telling is a lot of telling little breadcrumbs that are built into there and, just like anybody else, people get lazy. They do.

Speaker 2: 3:05 

And the people that are in this test environment don't think that you know, it's just a test environment. We're not. It's not like the full production. But one other thing is they talked about in here with the customer data. When I've seen in the past where you'll have a test environment set up, they will take customer data specifically from the production environment and put it into their test environment. Maybe not all of it, but they'll put a substantial amount. Why? Because they want to make sure it works. So if you're going to be a hacker, you're going to go after these tests environments, because what it can do is one, give you a lot of great information. Two, can also tell you a lot about how the production environment is laid out from an overall structure standpoint, and then, in many cases, the same passwords they're using in the test environment are most likely being used pretty strongly in a production environment.

Speaker 2: 3:54 

So understand what happened here. This is a pretty big deal, and it's from the APT 29 folks that are the fuzzy bear or the what was that there? They're the bears, I can't remember the name of it. But there's the APT 29 folks that are tied to the Russians for an intelligence service, or that otherwise known as their SVR. These are the same folks that went after solar winds, and so it is a pretty significant thing that you can know that Microsoft's just going to have to do better at this. Because I come back to the point of let's look at is from a critical infrastructure standpoint or a smaller, medium sized business standpoint, which many of the critical infrastructures are within the United States. A lot of them are using old Microsoft type systems. Many of them aren't updated. Many of them may not even be patched to the level they need to be, and so now you got access to the source code. It's just bad, bad business. And Microsoft they make a lot of money. They need to do a better job. They have to do a better job because so much of what they have out there is tied to all these systems are all tied to them. So something to keep in mind again that comes down to this is the Russian hackers that stole source code from the Microsoft environment. Okay, so now we're gonna get into the.

Speaker 2: 5:10 

Where our podcast is about today is the message integrity controls or what we're gonna first start off with Now a message integrity check. This is where it's designed, and this is a very basic level version of this, where it's designed to ensure the integrity of a message between the time it is created and the overall time it is read. Now the MIC works by creating a representation of the message which is actually sent with the message, and these integrity checks are based upon more simple math, but they're based on the fact that they're gonna create this message digest. So we're gonna get into a little bit more of a deeper message digest, but they're gonna create this second message based on math, and the design is that it was ultimate goal is to ensure that the message has integrity when it goes from point A to point B, but because of a basic message integrity check, it is based on this simple math. There is the possibility you could run into a collision, which basically means there's two different message can have the same representation of what it created. So let's kinda walk through an example of how this works.

Speaker 2: 6:11 

Now, this is done through what they call a checksum. So you have a cyclic redundancy check or a CRC, and this is that simple math that I talked about, where it performs this on the block of data that's in this message, such as a packet or file. It'll create this CRC. We'll create this, what they call a checksum and this checksum. So the CRC takes the simple math. Let's just say, for example, it takes your message and it's got Bill loves Frida loves George I don't know whatever you wanna say and you have this message. It then does this check on it and creates what they call a checksum the message. Then it performs this calculation and it sends it with it.

Speaker 2: 6:49 

Once they receive the message, it decrypts that piece of it and it looks at that checksum from the same math and then, if they match, it considers the message to be not. There's nothing wrong with it, that it was not compromised in any way, it was not corrupted in any way. That's the ultimate goal. So if they're different, it potentially could have been tampered with or the overall message has been corrupted. This is the simple piece of this. It's called message integrity controls. Now, to take it up a notch, you'd go and you'd add in some level of what they call a hashing algorithm. Now, these hashing algorithms is using complex encryption technologies to create the same concept, but using it in a way that is not easily tampered with. It's not in a situation where it would have be corrupted or potentially run into collisions. So these are much more sensitive to small bit changes and therefore they are resistant to the collisions. That doesn't mean that they are totally benign from having a collision, but they're much more resistant from it and they work really well as an integrity control for messages that are being sent out.

Speaker 2: 7:57 

Now, when you're talking hashing algorithms, there's some key concepts to understand about a hashing algorithm. One they have a fixed length digest. So what does that mean? It means the output of the hashing algorithm is always the same length, so you're not gonna get some varying level lengths when it comes to the hashing algorithm. So you have different types of algorithms that are of different lengths. But for an example, we'll use MD5, MD5 hash always produces 128 bit digest, which is basically 32 hexadecimal digits, right? So you get 32 times four is 128. Now that's an MD5 hash, but that's a known digest that's available for you. So that's a fixed length digest.

Speaker 2: 8:42 

It's also one way which basically means it's able to easily compute the hash from one message, but it's very hard to recover the message from the hash. That doesn't mean you can't do it, but it's challenging. You have a smaller digest but it's easier. I say easier, I can't even do one plus one but it's easier to recover the hash or the message from a hash that's smaller. The longer the hash, the harder that is. But what it basically comes right down to is that there's no real good way to reverse engineer the original message from the hash value, especially based on higher bit numbers.

Speaker 2: 9:19 

Now, deterministic means that the same message always produces the same hash. So if you have the message that talks about whatever it is, no matter how many times you hash it, it will always come up with the same overall digest. No matter how many times you hash it, it'll always come up with the same one, the same numbers. That will be there, the same 128 bits. Okay, so the ultimate goal is that it's going to be the same, so that it can verify the integrity and the authenticity of the message so that it's not tampered with and modified. So you want to ensure that that's the case and it does calculate on the entire message. This means that the hash value depends on every bit of that specific message, not just a small part of it, like we talked about earlier on the message integrity checks. So when you're talking the hash it does the entire message. The message integrity check could just take one piece of that overall message and therefore it's much more open to have collisions. It's much easier to not have a good potential message that's sent out. Now this property makes the hash is more sensitive to changes, obviously in the message, and it does resist against collisions where there are two different messages that potentially could produce the same hash. That's a collision. So I have Bill has his long message that he sends and they hash it up and then Fred sends the long message that he sends. Those two message digest should not match and that's a collision if they would. So that's therefore that's how the MD5 has his work. They're also uniformly distributed, which means that the hash values are evenly spread over all the possible output space. So there's no predictable pattern or there's no correlation between them. This produces, this reduces the chances of collisions as well and it makes it a much more secure and random type of environment.

Speaker 2: 11:05 

Now there's some several popular hashing algorithms out there. You got your MD5, which we mentioned is 128 bit digest. Shaw one is 160. You got your shot two and three and they have varying ranges of their digest from 224 up to 512 bit. But MD5, most people is deprecated to this point where it doesn't really use an MD5 hash. But it was the staple that was out there forever and you still may see it. So it's good for you to know what an MD5 hash is. But in many cases now you're expecting to see shot two and three hashes that are being used within these environments. So let's walk through an example of how this could be done within what you'd want to expect to see, so the steps that you would attempt anticipate to see.

Speaker 2: 11:48 

So, first off, you have Carol. She'll see uploads of file to a cloud storage service, right, and she wants to verify that has not been corrupted or modified by any way else anyone else. So she uses a hashing algorithm to generate a digest of the file. So she's got her file, my report, and she creates an MD5, or I should say, let's say a Shaw three digest. So a Shaw three digest, she did it at 512 bits, so she wants to make sure that is really secure. So she says this fixed length, one way, deterministic and uniformly distributed value, right, so she's going to take this, that's the old, the big terms. Right, she's going to get that digest, she's going to get that form it's going to create a digest of. It's going to create this hexadecimal number, that's like really long. And then she's going to upload that file to the cloud source storage service. Before she does, she takes an MD5, or I should say a Shaw three hash. She has that number, so she stores it. She knows what that number is.

Speaker 2: 12:47 

So now she wants to download that file and check its integrity to make sure that the file that she uploaded is the same one that she downloaded. She wants to make sure of that. She doesn't want to have a situation where maybe somebody tampered with it. So what she'll do then is she will download the file and then she will run the Shaw three algorithm against it again and she compares the digest from the original one and the one that she just did. If they match, boom, she's in business, they're the same. If they don't match, then something has happened to that file.

Speaker 2: 13:18 

Now, as an example you may see this out there in the real world is let's say you go to a file sharing site. They will tell you what the MD or the, depending on what they're using if it's MD5 or Shaw, whatever it might be, they'll tell you what the hash should be. So when you download that file, it should compare to what the overall hash should be that's downloaded. That's the expectation that they know. That way, you know, someone didn't go and put something into that actual file that could potentially be malicious. So that's the differences, is understanding. How do these digestors work? And so if they match that's the ultimate goal is that that you then can entrust the integrity of that specific file.

Speaker 2: 13:57 

Okay, so now we're getting to digital signatures. Now a digital signature will provide three different types of services integrity, authenticity and repudiation, or non repudiation. I should say Integrity, this is the service that ensures a message has not been tampered with or altered during the transmission. Okay, digital signatures, these provide three different services. You have integrity, authenticity and non-repudiation. So integrity, this is the service that ensures that the message has not been tampered with or altered during the specific transmission. So the digital signature can provide integrity, basically verifying the message digest which we talked about earlier, is computed by the receiver and matches the one sent by the sender. This implies, obviously, the message is intact, authentic and has not been tampered. The authenticity is a service by which a message originates from the claim sender and not from an impostor.

Speaker 2: 14:53 

Digital signatures provide authenticity using the sender's private key. So you have your private key and you have a public key, and the private key encrypts the message digest, which can only be decrypted by the corresponding public key. So you have your two keys out there, a public and a private, and only the private key can be decrypted by the public key. Now, in non-repudiation, this prevents the sender from denying having sent the message or the receiver from denying having ever received it. This, the digital signature, will provide the non-repudiation that is needed by creating a unique and verifiable link between both the message and the sender's identity. So if you ever have a situation where someone would dispute it, that's where the digital signature says no, it was signed by you. It's the same legal kind of signatures, legal significance that you could have if you got a pen and paper and you went inside it yourself.

Speaker 2: 15:46 

So again, process of creating a digital signature is quite easy, and it fundamentally involves two specific steps. The sender hashes a message and produces a fixed-length message digest, like we talked about earlier, and then the sender encrypts the hash value with the sender's private key. Once that's done, then the recipient will then decrypt the hash value with the sender's private public key, and then the recipient hashes the message and compares the result to the decrypted hash value. If they match, then you're in business. That's the ultimate goal. So let's give you an example of how this would work. So you have Alice and you have Bob.

Speaker 2: 16:24 

Alice wants to send a message to Bob. Alice has the message, she signs it with her private key. The key thing here to remember is that your private key should never be compromised. The moment your private key is compromised, then all of this goes out the window. So this is something that's very important to be kept within your system, and this is all done automatically, but it is probably one of the most important aspects that you need to ensure remains consistent is your private key is never compromised. The public key, on the other hand, is out there on the internet and is available for anybody's use. But the goal is that it can begin this part of communication back and forth between the two entities.

Speaker 2: 17:04 

So Alice, again, she has this message and she wants to send it to Bob and she sends it with her private key. She uses the hash function to generate a hash value which has the fixed length of strings which we talked about earlier and it has unique representation of that specific message. She then encrypts the hash value with her private key, forming the digital signature. They then attach the digital signature to the message and it's sent to Bob. Bob receives the message and with the digital signature it's already attached from Alice. So if he wants to verify this came from Alice and it hasn't been tampered with, he takes Alice's public key, decrypts the digital signature. She gets a hash value that Alice generated. He also uses the same hash function to hash the overall message that was sent and they basically producing another hash. So you have two hashes the one that was encrypted as a digital signature and the other one which is the actual message itself. You compare the two and if they both match, then at that point in time you can say that it was not compromised and it's legitimate. So it's a really simple process, but there's a lot of little moving parts, which makes it kind of complicated and confusing. But just remember, you have, like we talked about, you have your hashing function like a shaw, you have your private and public keys and then you have the overall digital signature itself. That comes from what we call a message digest. That's created.

Speaker 2: 18:25 

Okay, so let's roll into what are digital certificates Now. Digital certificate certificates bind an individual to their public key and all certificate authorities confirm that. They call it. An X 509 certificate is the specific standard. So you're going to be dealing with some different types of terms.

Speaker 2: 18:43 

Now that come out of the certificates, you're going to have what we call a root certificate authority or root CA. These are considered what they call the root of trust or the trust anchor, and they're the foundation of all digital certificates that are out there. Each of the major brands have these the Microsofts, the Godetis. They have it what they call it. They were considered what they call a root certificate or certificate authority. Many of the hackers would love to go after the certificate authorities, and they do, because the ultimate goals if you can be get, get that certificate authority capability. You now can sign whatever you want from a digital certificate standpoint. And then in the past, there's been various situations that have occurred where the root CA's have been compromised. Now there's intermediate CA's can also sign certificates that can and can issue these, and but they have a very strict process by which they have to become a certificate authority.

Speaker 2: 19:35 

Now, digital certificates best practice suggests when a public and private key pairs are periodically replaced. That is usually the best thing that's associated with a digital certificate. That's especially when a digital certificate is also replaced. You want to ensure that your public and private keys are replaced. Now, when a private key has been compromised, a digital certificate should be revoked as quickly as possible, and it's happened in the past where that you've had to have ever revocation plan in place for these keys. Now there's basically a replacement revocation process and we'll kind of walk you through those how that happens. Now, when it comes to replacement, there's regular replacement of expired certificates. These replacement certificates are issued are associated with private keys that have potentially been compromised.

Speaker 2: 20:20 

Well, the CA's will have a revocation process by which they're going to give you a replacement certificate. The client will download and search all the list of serial numbers of revoked certificates from the CA. The client queries the CA for revocation status of the specific certificate and their serial number that's tied with this. So this is a manual process that you can do or the system will do it for you. You get some people that are very interested into this. They will actually go out and manually do this process, but the computer itself will go out and compare your digital certificates based on ones that potentially have been revocated. So you don't have to go through this entire process. But it's important to know, especially when you're dealing with web servers. They'll want to make sure that your certificate is a legitimate and up-to-date certificate and if not, they're going to want to get you a new one. So let me walk through a process of how this would happen.

Speaker 2: 21:15 

So you have a digital certificate that's issued by an intermediate CA to Alice. You know we got Alice again and Alice owns a public key for encrypting and signing messages. Now the information that's in this digital certificate has the name and the public key of Alice, the name and the signature of the intermediate CA and the serial number and expiration date of the certificate itself. Specifically, it talks about the purpose of the certificate for both as for signing documents, whatever it might be, and then the potential scope for it. The X05 standard has various versions and extensions that tie into this as well. So the digital certificate that is tied to Alice can be validated by checking the signature of this intermediate CA against the public key, which is obtained, obviously, from the root CA certificate. The digital certificate then can be revoked by the CA if Alice's private key is potentially compromised or if she violates the terms of the certificate itself, using it for something it shouldn't be. This digital certificate also be renewed by the intermediate CA before it specifically retires or expires and I've had to do this myself, where you can actually go out and get a new digital certificate before it actually goes out. Most of the time this is done, like I said, automatically. It will do this for you, but you can actually manually go and do this process as well. This, once this happens, this digital certificate is then pinned directly to Alice, who it trusts, and the client does not have the ability to do anything with it. It validates the certificate every time it communicates with Alice and it verifies that is who she specifically is.

Speaker 2: 22:48 

Now let's kind of walk through the life cycle of a digital certificate. So we have enrollment, so Alice again requests a certificate from the intermediate CA that provide her identity and her public key. So obviously we talked about intermediate CA. So you have your root CA's and then you have your intermediate CA's Most various companies. There's lots of intermediate CA's out there. You can actually get that list off your computer. You can understand who are all of the authorities that are tied to your certificates on your computer. That can all be looked at, depending on what version you have and where it's located whether it's Windows, whether it's Linux or whether it's actually in a Apple type version.

Speaker 2: 23:28 

Now the intermediate CA will verify Alice's identity and her public key and then issues a certificate to her. A client who wants to communicate with Alice will validate her certificate by checking the signature of the intermediate CA and the expiration of the overall certificate. Then if that becomes a problem and she has to revoke, they get the certificate revoked. The intermediate CA will then revoke her certificate if her private key is ever compromised and they're aware of that, or if she obviously violates the terms of service. And then that's part of what they call a CRL, which is your certificate revocation list. There's also an online version of this called the online certificate status protocol, OCSP. That's a server that's out there that will look for these certificates as well and then, once that occurs, the intermediate, CA, will renew Alice's certificate before it expires, or if it has been compromised, they'll renew that as well, depending upon what occurred and why it was actually compromised. So, again, these certificates are important factor, digital certificates are, and you have various pieces of this as it relates to how you're going to handle this certificate for your specific identity.

Speaker 2: 24:38 

Last thing we're going to get into is S-MIME. So S-MIME is a standard for public key encryption that it provides security services for digital messaging applications. Now it originally starts off. It's tied into PKI, which is your public key infrastructure. Now the basic security services that are with S-MIME are authentication, non-repudiation of the origin, message integrity and then confidentiality. Now S-MIME is a culmination of what started off as MIME. So we're talking MIME, it's M-I-M-E. So Mike India, Mike, Echo. Now MIME did not address security issues. It was just basically developed for messages. But as time has gone on, there needed to be some level of security added to this overall standard. So they created what they call a S-slash MIME, which adds features to your email messaging, including the digital signatures which we talked about encryption for message privacy and then obviously hashing for message integrity and non-repudiation. So that's where the S-MIME comes into play.

Speaker 2: 25:37 

Now, an example of an S-MIME we'll kind of get put this into action again is we got Alice and Bob. Now Alice wants to send the message, a secure message, to Bob, who has her public key, and he has this public key from the certificate issued by a trusted CA. So Alice uses Bob's public key to encrypt the message content and generate what she calls what they call is a message digest we talked about earlier, which hashes the message. Alice then signs the message digest with her own private key, creating a digital signature that proves her identity as the sender and prevents anyone from altering the message. Alice then takes and attaches her public key certificate and Bob's public key certificate to the email, along with the encrypted message and the digital signature. So you've got four things in place here Alice's public key, Bob's public key, the message itself that's encrypted, and the digital signature. Alice will then send the email to Bob using standard MIME format, but with a secure MIME header indicating that the security features have been used. So that's the key piece of this is that it's a MIME message, MIME format, but it's a slash source data system s slash mime, so it show you that the security features have been used. Specifically, Bob receives this email and then verifies the certificates with the CA, ensures that they're valid and then that they have been revoked, and then Bob uses his own private key which is in compromise to decrypt the message content and Alice's public key to verify her signature. So you got Alice's public key to verify the signature. You got Bob's private key to decrypt the message, because you use his public key and then the message and then also to verify the digital signature and the message digest confirming Alice's identity and the message integrity. Bob uses his own private key to decrypt the message and then Alice's public key to verify the digital signature and the message digest so that verifies that Alice is who she says she is. Bob can read the message and reply to Alice using the same procedure, going backwards or if he uses a different security protocol, if he chooses.

Speaker 2: 27:48 

The bottom line is again we'll walk this through one more time. Alice wants to send a message to Bob, a secure message, who has a public key certificate that's issued out out there in the internet by a trusted CA. Alice uses Bob's public key, so she takes his public key, she encrypts the message content and generates a message digest. Okay, so that's again. That's the hash. That's the hash of the overall message itself.

Speaker 2: 28:12 

Alice signs the message digest that she was just created with her own private key. So the private key she owns no one else has. She then signs it with that, creating a digital signature that proves she is who she says she is. She then sends this, or she attaches the public key certificate okay, that Bob's public key to the email, along with the encrypted message and the digital signature that she created. She sends us to Bob through an email using standard MIME format with an s slash header, and then Bob receives the email and verifies that the certificate with the CA. So her certificate is confirmed with the CA, ensuring that they're valid and it hasn't been revoked.

Speaker 2: 28:55 

Bob then uses his own private key to decrypt the message. Okay, he's got a private key, it's been encrypted with his public key. It now verifies the message. So the message is unencrypted. But then he's able to utilize the Alice's public key, which is out on the internet, to verify her digital signature and the message digest are correct. So then they're both equal. So that hasn't had anything that's happened to the message digest at all. It's all there and then Bob can read the message and obviously reply to her as he sees fit. So that is the overall example of an S-MIME.

Speaker 1: 29:27 

Okay, that's all I have for you today. I hope you all have a wonderful day.

Speaker 2: 29:32 

Head on over to CISSP cyber training and catch out when we got all these videos are there free for you to gain access to their online blog? You can go check them out also if you're interested. I have some paid products out there as well for you to help you pass the CISSP. The first time I have a blueprint. That's amazing. Everybody that uses it passes. They are doing a great job with this. If they follow the what the blueprint offers, you will pass the CISSP exam.

Speaker 2: 29:57 

If you're interested in just getting the free content, it's there and available for you as well. All of that is there at CISSP cyber training. Go check it out. Cissp cyber training dot com. Check it out. Let me know if you have any questions. I'll feel free to respond to me in the. There's different places. You can reply to me or just let me know what you need, but I'm here for you at that. Cissp cyber training. Head on over there, check it out. Also, you can get 30 or 60 free CISSP questions. Just go to free CISSP questions dot com and you can get answers those as well. All right, have a wonderful day and we will catch you on the flip side, see ya.

OUTLINE

• Message Integrity Controls

• Message integrity check (MIC) helps to ensure the integrity of a message between the time it is created and the time it is read.
• A MIC works by creating a representation of the message, which is sent with the message.
• The message integrity checks are based upon math, some more complex—and therefore more effective—than others.
• The use of simple math can result in a collision, meaning two different messages can result in the same representation.
• Example:
• One example of a message integrity check is the cyclic redundancy check (CRC), which is a simple mathematical calculation that is performed on a block of data, such as a packet or a file.
• The CRC generates a fixed-length value, called a checksum, that is appended to the message.
• The receiver of the message performs the same calculation on the received data and compares the resulting checksum with the one sent by the sender.
• If the checksums match, the message is assumed to be intact and unaltered.
• If the checksums differ, the message is corrupted or tampered with.

• Hashing Algorithms

• Hashing algorithms are much more sensitive to small bit changes and much more resistant to collisions, and they are, therefore, much more effective as integrity control mechanisms.
• The key elements that make hashing algorithms so effective are:
• Fixed length digest- This means that the output of the hashing algorithm is always the same length, regardless of the size or content of the input message.
• For example, MD5 always produces a 128-bit digest, which can be represented by 32 hexadecimal digits
• One-way - This means that it is easy to compute the hash from the message, but very hard to recover the message from the hash.
• In other words, hashing is irreversible and there is no way to reverse engineer the original message from the hash value.
• Deterministic - This means that the same message always produces the same hash, and any change in the message, even a single bit, will result in a different hash.
• This property ensures that the hash can be used to verify the integrity and authenticity of the message, as any tampering or modification will be detected by comparing the hashes.
• Calculated on the entire message - This means that the hash value depends on every bit of the message, and not just on some part or subset of it.
• This property makes the hash more sensitive to changes in the message and more resistant to collisions, which are situations where two different messages produce the same hash.
• Uniformly distributed - This means that the hash values are evenly spread over the possible output space, and there is no predictable pattern or correlation between them.
• This property reduces the chances of collisions and makes the hash more secure and random
• Several of the most popular hashing algorithms are noted below:
• MD5: 128-bit digest
• SHA-1: 160-bit digest
• SHA-2: 224/256/384/512-bit digests
• SHA-3: 224/256/384/512-bit digests
• Example:
• Carol wants to upload a file to a cloud storage service and verify that it has not been corrupted or modified by anyone else.
• She uses a hashing algorithm to generate a digest of the file, which is a fixed-length, one-way, deterministic, and uniformly distributed value that depends on the entire file.
• She chooses SHA-3, which produces a 512-bit digest.
• Carol's file: "My report.docx"
• Carol's SHA-3 digest: 3a3b2c7d3c9b1a7f1d3e5e6f2b4a8b9c0d4c6d7e8e9f0a1b2c3d4e5f6a7b8c9d0e1f2d3c4e5f6a7b8c9d0e1f2d3c4e5f6a7b8c9d0e1f2d3c4e5f6a7b8c9d0e1f
• She uploads both the file and the digest to the cloud storage service.
• Later, she wants to download the file and check its integrity.
• She downloads the file and the digest from the cloud storage service and uses the same hashing algorithm, SHA-3, to compute her own digest of the file.
• She compares her digest with the original digest.
• If they match, she can be sure that the file has not been corrupted or modified by anyone else.
• If they differ, she knows that the file has been compromised or damaged.
• Carol's downloaded file: "My report.docx"
• Carol's SHA-3 digest: 3a3b2c7d3c9b1a7f1d3e5e6f2b4a8b9c0d4c6d7e8e9f0a1b2c3d4e5f6a7b8c9d0e1f2d3c4e5f6a7b8c9d0e1f2d3c4e5f6a7b8c9d0e1f2d3c4e5f6a7b8c9d0e1f
• Carol's digest matches the original digest, so she trusts the integrity of the file.

• Digital Signatures

• Digital signatures provide three services:
• Integrity - The service that ensures that the message has not been tampered with or altered during transmission.
•  A digital signature can provide integrity by verifying that the message digest computed by the receiver matches the one sent by the sender, which implies that the message is intact and authentic.
• Authenticity - The service that ensures that the message originates from the claimed sender and not from an impostor.
• A digital signature can provide authenticity by using the sender's private key to encrypt the message digest, which can only be decrypted by the corresponding public key that is known to belong to the sender.
• Nonrepudiation - The service that prevents the sender from denying having sent the message or the receiver from denying having received it.
• A digital signature can provide nonrepudiation by creating a unique and verifiable link between the message and the sender's identity, which can be used as evidence in case of a dispute.
• A digital signature uses include having the same legal significance as a written signature, code signing to verify the integrity and authenticity of software, and nonrepudiation (of origin and delivery).
• The process of creating a digital signature is quite easy and fundamentally involves two steps:
• The sender hashes the message, which produces a fixed-length message digest.
• The sender encrypts the hash value with the sender’s private key.

• The recipient of the message decrypts the hash value with the sender’s public key.
• The recipient hashes the message and compares the result to the decrypted hash value.
• If the two values match, the recipient can be sure that the message has not been altered since it was signed by the sender.
• Digital signatures are used to provide integrity, authenticity, and non-repudiation of messages.

• An example of a digital signature:
  • Alice wants to send a message to Bob and sign it with her private key.
  • She uses a hash function to generate a hash value of the message, which is a fixed-length string that uniquely represents the message.
  • She then encrypts the hash value with her private key, forming the digital signature.
  • She attaches the digital signature to the message and sends it to Bob.
  • Bob receives the message and the digital signature from Alice.
  • He wants to verify that the message came from Alice and has not been tampered with.
  • He uses Alice's public key to decrypt the digital signature, obtaining the hash value that Alice generated.
  • He also uses the same hash function to hash the message, producing another hash value.
  • He compares the two hash values and sees that they are identical.
  • He concludes that the message is authentic and intact, since only Alice could have encrypted the hash value with her private key.

• Digital Certificates
• Digital certificates bind an individual to their public key, and all certificate authorities conform to the X.509 certificate standard.
• The “root of trust” or “trust anchor” is the foundation of all digital certificates and is represented by a root certificate authority (CA).
• The Root CA self-signs its certificate, and it is then used to sign subordinate certificates, usually known as intermediate CAs.
• Intermediate CAs can also sign certificates, shown as Issuing CAs.
• Digital certificate best practices suggest that public/private key pairs be periodically replaced, which means the associated digital certificate is also replaced.
• When a private key has been compromised, a digital certificate should be revoked by the issuing certificate authority.
• Digital certificate replacement and revocation are summarized here:
• Replacement
• Regular replacement of expired certificates
• Replacement of certificate when associated private key has been compromised
• Revocation
• Client downloads and searches the list of serial numbers of all revoked certificates from the CA
• Client queries CA for revocation status of specific certificate serial number
• With certificate pinning, when a certificate from a web server is trusted, each subsequent visit to the site does not include a request for a new copy of the certificate.

• Example:
  • A digital certificate issued by an Intermediate CA to Alice, who owns a public key for encrypting and signing messages.
  • The digital certificate contains the following information:
  • The name and public key of Alice
  • The name and signature of the Intermediate CA
  • The serial number and expiration date of the certificate
  • The purpose and scope of the certificate
  • The X.509 standard version and extensions
• The digital certificate can be validated by checking the signature of the Intermediate CA against its public key, which can be obtained from the Root CA's certificate.
• The digital certificate can be revoked by the Intermediate CA if Alice's private key is compromised or if Alice violates the terms of the certificate.
• The digital certificate can be renewed by the Intermediate CA before it expires, or Alice can request a new certificate with a new public/private key pair.
• The digital certificate can be pinned by a client who trusts Alice, so that the client does not have to validate the certificate every time it communicates with Alice.
• The digital certificate life cycle includes the following phases:
  • Enrollment: Alice requests a certificate from the Intermediate CA and provides her identity and public key.
  • Issuance: The Intermediate CA verifies Alice's identity and public key and issues a certificate to her.
  • Validation: A client who wants to communicate with Alice validates her certificate by checking the signature of the Intermediate CA and the expiration date of the certificate.
  • Revocation: The Intermediate CA revokes Alice's certificate if her private key is compromised or if she violates the terms of the certificate.
    • The revocation status is published in a certificate revocation list (CRL) or an online certificate status protocol (OCSP) server.
  • Renewal: The Intermediate CA renews Alice's certificate before it expires, or Alice requests a new certificate with a new public/private key pair.

• S/MIME
• S/MIME is a standard for public key encryption and provides security services for digital messaging applications.
• It requires the establishment or utilization of public key infrastructure (PKI) in order to work properly.
• The basic security services offered by S/MIME are:
• Authentication
• Nonrepudiation of origin
• Message integrity
• Confidentiality
• MIME does not address security issues, but security features were developed and added to MIME to create S/MIME.
• S/MIME adds features to email messaging, including:
• Digital signatures for authentication of the sender
• Encryption for message privacy
• Hashing for message integrity and nonrepudiation of origin
• Example of example of S/MIME in action is as follows:
• Alice wants to send a secure email message to Bob, who has a public key certificate issued by a trusted authority (CA).
• Alice uses Bob's public key to encrypt the message content and generate a message digest, which is a hash of the message.
• Alice then signs the message digest with her own private key, creating a digital signature that proves her identity as the sender and prevents anyone from altering the message.
• Alice attaches her public key certificate and Bob's public key certificate to the email, along with the encrypted message and the digital signature.
• Alice sends the email to Bob using the standard MIME format, but with an S/MIME header indicating the security features used.
• Bob receives the email and verifies the certificates with the CA, ensuring that they are valid and not revoked.
• Bob then uses his own private key to decrypt the message content and Alice's public key to verify the digital signature and the message digest, confirming Alice's identity and the message integrity.
• Bob can read the message and reply to Alice using the same procedure, or use a different security protocol if he prefers.

• Public Key Infrastructure

• Public key infrastructure (PKI) is the basis for keys to be distributed and owners of public keys to be verified.
• It consists of several components:
• Certificate Authority (CA)
• Root of trust
• Registration Authority (RA)
• Intermediate/ Issuing CA
• Validation Authority (VA)
• Certificate DB
• The root of trust in any PKI is the CA, which ultimately issues certificates.

• Key Management
  • Proper key management is paramount to the security of any cryptographic system and contains numerous key management activities:

Table