Then again, a digital signature.
Digital signature is a hash or integrity
check of a message, and then you encrypt that with the private key of the signer.
You sign it, which is really encryption,
the holder of your public key can decrypt the hash that would rehash the
message, determine if the two hashes match.
So if it lines up the two hashes match, then you assert the confidence that the
signer is in fact who they say they are because they're in possession of the
private key to which that public key is paired.
So again, typically that public key is bound to the user's identity through a
digital certificate, which we're going to talk about here in a second.
Again, creating a digital signature at the
sender side and at the recipient side, you're just reversing the process.
Key exchange through digital envelopes.
We talked a bit about this already in SSL and TLS set ups.
Generating a digital envelope is encrypting a message with a symmetric key
and then encrypting the symmetric key and then sending that along to the recipient.
In an earlier module, we went through some whiteboard diagrams of how that works.
Just remember this, if it's any amount of
bulk data, it's encrypted with a symmetric key.
The distribution of that symmetric key often happens asymmetrically.
If you are the recipient, I get your certificate, your public key, I come up
with the symmetric key, I thought it up, I encrypted with your public key, I sent it
to you, you decrypted with your private key, which you're the only person on the
planet that has a copy of it, and now we've securely exchanged the key.
I came up with it, I securely sent it to you.
Now you know it because you decrypted it successfully.
The digital envelope or hybrid encryption,
same concept, the symmetric key is tucked away safe and sound using a symmetric.
Perfect forward secrecy is
technique that protects previously encrypted session data against unintended
decryption, even if the private key of the server is compromised.
It uses the Diffie Hellman Key Exchange to
generate a unique session key for each session.
The key can be used only for that specific session.
All right, Diffie Hellman.
Let's talk a little bit about that.
All right, Diffie Hellman is key agreement.
So when we talked about...
Let's just whiteboard this real fast.
You got Bob, you got Alice.
Alice has a key pair.
Bob has a key pair.
Certificate.
Normally, if Bob wanted to send Alice an encrypted message, he would symmetrically
encrypt the message and then encrypt it with Alice's public key.
In Diffie Hillman, they exchange public keys.
A Modulus value mathematically combine them on either side and they happen to
come up with the same symmetric key, which is weird that it works, but it does.
It's a key agreement protocol or algorithm versus a key exchange, but it's used for
negotiating session keys and you'll actually see it used in IPsec.
We talked a little bit about that in our first IPsec discussion.
Digital certificates.
Digital certificates are used for dealing
with security concerns regarding transmission of public keys securely.
You want to make sure that that public key
is in fact does in fact belong to who you think it belongs to.
It's a digitally notarized file that's been signed by a certifying authority that
you've chosen to trust, which just means they've done an integrity check on that
file, signed it with their private key, and you hold the public key for it.
The sender and the receiver and digital
certificates, anybody can send you the certificate.
The sender will have that if signing a message has their private key, and we've
talked about this already, the receiver use their public key to decrypt it.
Digital certificates, same concept.
It's a digitally signed document.
The receiver verifies the signer's signature using the signer's public key.
This is going to come up a little bit
later, so I'm just going to pop it up here.
But your certificates
are stored in the certificate manager local certificate store.
Here's copies of all the certificates.
If you've got a certificate from a trusted
certification authority or intermediates, you automatically trust these certifying
authorities and you can verify or validate their certificates.
We'll come back to that Windows certificate manager tool here in a bit.
Digital certificate attributes, the serial number, subject, signature algorithm, key
usage, public key issuer, valid from and so forth.
If I was to open one of these certificates and go to the details, they're all there.
Version, serial number, signature algorithm, hash algorithm, issuer, etc.
I'll let you read through, but the probably most pertinent information is the
subject, the validity dates, and the signature and the public key.
Now, you can argue other fields are fairly
important as well, but when I receive a digital certificate, I'm going to validate
that it's A, signed by a certifying authority I've chosen to trust, B, that it
matches the subject that I think it came from and it's also valid.
Validity dates does today fall between the start and end date.
If all three of those criteria line up, I'll accept the certificate and I will use
that and trust it because it's been verified.
There's digital certificates follow a standard.
The X.
Standard is an international telecommunications ITU specification.
There's two digital standards that you'll see in security discussions.
X. 509 is the most prevalent, X.
500 refers to directory services.
A digital certificate standard, X.
509 is your conventional certificates.
There's also proprietary certificate formats for things like old school PGP.
Version, serial number, algorithm identifier, we just looked at all these.
It's the most widely used digital certificate standard.
All right, the digital certificate formats.
There's a variety of formats used by different operating systems.
You're going to generate some certificates
in a lab, personal information exchange, or PFX, or R.
There's Cert format, P KCS, P7B, CER,
Privacy Enhanced Mail for digital email, and Distribution Coding Rules.
These are based on different OSs, different implementations.
Here's your formats.
Pfx is a pretty standard format.
And again, you're going to be creating certificates in the lab.
Public key infrastructure is the
collective hardware software, people, policies, and procedures for creating,
managing, distributing, using, storing, and revoking digital certificates.
The components, a CA that generates issues and verifies digital certificates, a
registration authority that acts as a verifier, which receives and validates
registration requests, a management system for generation, distribution, storage and
verification, and one or more directories where the certificates are stored.
Quite often these days that's done in
active directory. All right, so a little bit on the model.
The certification authority, you may have a couple of tiers or layering a hierarchy,
is what actually generates the certificates.
The registration authority verifies the applicant information.
The user generates a key pair, holds on to the private key,
never shows that or disclosed to anyone, sends the public key in a certificate
request for binding to the registration authority.
Registration authority verifies the applicant's identity based on the
practices in their certificate practice statement.
If they've been validated, it issues it to the CA, the CA issues the certificate.
That certificate can then be accessed from
a certificate store or published somewhere, active directory, and it could
also be handed directly to whoever you're communicating with.
The validation authority could be used to validate certificate trust and so forth.
We're not going to dig too much into that.
But as long as everybody trusts the same common root CA, they trust the whole PGI.
Online versus offline CAS.
It's recommended that you take your root CA offline.
You generate a certificate, you generate
issuing certificates to subordinates or intermediates.
They actually generate the certificates.
You take this guy offline because if he gets compromised in his private key, then
you've compromised the entire infrastructure.
If this guy is offline and can't be accessed, then you're in business.
These guys then you have a division or separation of duties here.
If one gets compromised, it doesn't take down the whole infrastructure.
You can have multiple layers of issuing CAs if you like.
Ppi trust models.
A peer to peer trust model, you can have two CAs cross certify or trust each other,
which is useful in situations where you're doing business with another organization
and you don't want to implement a common structure.
You can cross certify those CAs.
A hierarchical trust model is, again, based on hierarchy.
The root CA, the subordinates, the subordinates all the way down.
Alice and Bob here, as long as they both
trust the same root CA, then they would trust any of the subordinates and say Bob
gets his certificate from this subordinate CA, Alice gets hers from this, they'll
still trust each other even though they don't directly trust the subordinates
because they'll still verify the certificates down the chain.
A hybrid trust model is a combination of both.
You might have two hierarchies that are
cross certified, and a bridge trust model reduces the cross certificates.
It actually creates one CA as a central
hub for connecting all other CAs and acts as a communication intermediary for them.
The web of trust.
When you think of web of trust, you'll typically think of Mesh trust.
You typically think of PGP, which used proprietary certificates and everybody
trusted everybody directly versus a CA and a hierarchy.
Old school PGP uses web of trust.
You trust people directly.
Indirect trust, you could actually vouch for other entities and in that situation,
if Alice trusts Allen and Allen trusts Bob, then any friend of Allen's is a
friend of mine, Alice might trust Bob indirectly.
Types of digital certificates.
Wildcards allow you to configure a domain
and all its subdomains to minimize the complexity and cost.
So you just put a wildcard domain.
Subject alternative name used to protect
multiple websites with a single certificate.
Code signing is a certificate that
specifically is generated for the purpose of signing code.
We talked about code signing.
Self signed, right.
That's like me creating my own driver's license.
Do you trust it? Probably not.
Self signed certificates signed by the
person or company that created it instead of a trusted CA.
Don't necessarily know that they are who they say they are.
Then machine or computer certificate
generated at the time of activation of a computer that can be used for
authentication and a variety of other purposes.
E mail for self explainatory, for encrypting or signing email.
User certificate, mapped to user account,
which again can be used for authentication.
Root is a self signed certificate that belongs to the issue in the CA.
We've talked about roots.
Server, used to validate a server's identity.
The client shares the information provided is safe and secure.
You'll see that actually used in SSL
certificates, which you're going to create some.
Domain and extended validation allow you to prove a degree of control over domain.
Issued by CA is the highest class of SSL certificates.
Again, you're going to generate some certificates in the labs.
You're going to do one under Parrots under Linux and one under IIS.
It's a lot easier under IS.
A couple of clicks and you're done.
Get the Internet Key Exchange or Ike.
Ipsec relies on the Internet Key Exchange for secure exchange and authentication.
Just to reiterate, I know we talked about
this earlier, but Internet Key Exchange or IKE, UDP Port 500.
It's a newer term for ISOCAMP, which is
Internet Security and Key Management Protocol.
Isocamp uses Oakley and Oakley uses Diffie Hellman.
They're all part of the same process.
Diffie Hellman, again, is a key agreement.
Diffie Hellman, however, doesn't have a mechanism for authentication.
The key exchange accommodates that.
Typically, when you think of an IPsec connection set up, it's certificate based,
it's pre shared key based, or it is Kerberos based.
Phase 1 of an internet key exchange sets up the initial rules, algorithm, telmo
mode, transport mode, AHA, ESP, key rotational intervals, and so forth, and
creates security associations that are then used as a master template for Phase
2, which are used to generate security parameters for each subsequent section.
Two IPsec systems want to communicate, they make an agreement, right?
Yeah, tunnel mode transport, tunnel transport, transport.
Awesome. Hey, AHA, ESP, ESP, ESP, ESP.
They'll typically negotiate the most
secure protocol that each one of them is configured to allow.
The security associations are inbound outbound rule sets.
A security parameters index is a list of security associations, and you just
basically set up all of the rules for how the data is going to be processed.
That allows you to easily determine how to apply decryption and so forth to each
inbound packet, and it gets more detailed than that.
But those security associations are initial handshakes.
Key escrow and certificate chaining.
Key escrow we've talked about, keeping
secret keys that the certified third party.
Talked about government access to keys,
which is key escrow, ensures that critical keys are kept safe in case of disasters.
Certificate chaining is where you're chaining a chain of trust.
Certificates starting from the server roots and ending with the roots.
Again, you got issuing CAs below the route.
Again, you'll see a bunch of fields on intermediaries.
Certificate pinning, it allows the application to verify the
server certificate using a pre installed certificate.
Basic validation procedure using server's
public key verifies whether the certificate matches the pin certificate.
You're pre determining the certificate to match the site.
Allows a web client to associate a specific public key certificate with a
particular server to minimize the risk of man and middle attacks.
Again, come back for CEH.
We'll talk about session hijacking SSL,
and I'll show you some certificate spoofing.
A certificate revocation list. All right, so imagine that I have a driver's license.
I do have a driver's license.
I can imagine that I'm not the greatest driver in the world.
Imagine that I speed a lot and maybe
travel long distances between Atlanta and Florida and that thing.
Imagine that I've got some outstanding
speeding tickets that I have not taken care of.
My license might be revoked, right?
So I've got a valid license and if I showed it to you, it would look valid.
It's issued by state of Florida.
It's issued or state of Georgia or wherever.
It's issued by a certifying authority that you've chosen to trust.
It's got my face on it, which looks legit.
It also has my validity dates.
It's currently valid.
Is it possible, though, that that license has been revoked?
Sure. How would you ever know that, though?
Well, you'd have to call it in. Let's say I get pulled over for exceeding
the speed limit and I hand my license to the officer and
I'm just sweating it because I know I've got some outstanding speeding tickets.
This is completely fabricated scenario, by the way.
This is not me.
Would he ever know that? No.
He'd look at it and say, This is a valid license, right?
If he called it in, though, that's a different story.
So a certificate revocation, when a
certificate is revoked before the end of its life cycle, then you have to actually
notify through a certificate revocation list, and that still has to be checked.
So you publish the revoked certificate to a certificate revocation list, and then
that revocation list is downloaded by whoever's checking it.
There's latency with that, that's a problem.
Online certificate status protocol is a more real time check of the CRL and the
OCP agents give you less latency, less late in response.
Checks the CA, the external number determines certificate status.
You have an intermediary component that's doing the checking for you.
Certificate stapling is interval based more or less.
Certificate stapling is an alternative to OSCP.
The web server running SSL TLS caches timestamp OCSP responses from the CA.
Instead of the CA, the web server
responds, the timestamp responds the timestamp response from its cash records.
Both of these are meant to alleviate the
latency issue and the necessity to download the full CRO.
Openssl is an open standard.
Openssl very widely used cryptographic toolkit for applications, protecting
communications across a network from sniffing or spoofing.
We've talked about how SSL works.
Openssl usage, that's just some key
generation and you are going to be doing this in the lab.
I'll let you refer to the lab for the specific steps on that.
Our Windows certificates.
Again, the certificate manager in Windows
has all of your default certificates, and you can also add certificates for a
variety of purposes, but it's a Rolodex almost of different purposes for
certificates, different folders, different categories, trusted, untrusted.
A lot of these are empty for the default.
That's where you manage your certificates on a Windows machine.