>> Public key infrastructure or PKI.
The learning objectives for this lesson are to explore
how PKI functions and its role,
to define the parts involved with PKI,
and to explore how PKI is implemented and used.
Let's get started. You may remember in
the previous lesson where we discuss the difficulties of
sending symmetric encrypted data to
someone and then supplying
the password to them to decrypt it.
It's very difficult to ensure that
that password is not intercepted,
so asymmetric encryption solves this problem.
It does so by creating a key pair.
The first is the public key they
can be freely given to anyone,
and the second is
the private key which we have to keep secure;
it's used to decrypt messages that have been sent to us.
But this is a key part of how PKI functions,
and I want to make sure you understand
this before we move deeper.
I'm going to use a visual on the next slides to
show you how this process works from start to finish.
We have Alice, and she wants to send a message to Bob.
Bob will send his public key to Alice.
Alice will then use
Bob's public key and encrypt a message to him.
Then she'll send that message directly to Bob.
Bob will take his
private key and decrypt the message and then read it.
This gives you a basic flow of
how asymmetric encryption works.
But these are the key points that
I wanted you to keep in mind.
Public key and private key are a matching pair.
Our public key can be freely given to anyone but
we've got to keep our private key safe and secure.
We can use asymmetric encryption to
digitally sign messages or files and by doing that,
I am proving that I'm the one who did that.
Let's move on into how this connects over to PKI.
Public key infrastructure or PKI are tools
that support not only
encryption and digital certificates,
but also integrity checks and authentication is
a central control over
the digital certificates that can be used
to identify users and services.
Those digital certificates will have
a public key embedded in them and
allows for message signing or
for message integrity and authentication.
When we're signing messages with
a digital certificate or our public key,
we're proving that I'm the one who did this.
That gives us non-repudiation.
Let's talk about some common uses of PKI.
Code signing is a very good example of this.
We have to be able to show that this code that we're
producing it may be an executable or a driver,
are validated by us that we're the ones that did this,
and it is trustworthy.
This is becoming a really big deal
because we need to ensure
that the drivers we're installing,
the executables we're installing,
come from sources that have been
validated and their certificates are
trusted by a certificate authority and
that certificate authority itself is a trusted CA.
If you remember Stuxnet that I
discussed in a previous lesson,
they use stolen digital certificates
to install malware onto systems,
and they did this by signing drivers that
Microsoft when Windows saw these particular drivers
had been signed by a certificate
that was accepted they allowed those drivers to
be installed directly onto the system without even
taking it further to check them out or to block that.
By doing that they just snuck right past
all the defenses and that really allowed
for the virus to first begin its exploitation part,
but to really spread further.
You can see the importance of making sure
that we're assigning our software
or our code because it's
such a key part to ensuring
we're not installing bad things in there.
Now we can't stop it if a certificate has
stolen in the case of Stuxnet,
but we can at least prevent
the easier attacks by installing drivers or apps on
our devices by not allowing
them to be installed from sources that are not trusted.
A digital certificate is a public assertion of identity.
I'm saying this is me,
and my digital certificate has a public key in that.
Not only that, my digital certificate has
been validated by a certificate authority.
That CA has said yes,
we know who this person is
they are who they say they are,
it is safe to send a message to him.
We can not only use this for sending messages,
or encrypting messages, or signing messages,
but we can also use it for encrypting web traffic.
Your browser has its own digital certificate and then
when we're going to a website via HTTPS,
we're using our digital certificate
and the site's digital certificate to
negotiate encryption to ensure
that the traffic is encrypted back and forth.
If we would have a third party
that jumped in there and put
a bad certificate on that web server,
then they would be able to intercept
that traffic so we have to make sure that
our web servers that we're
browsing to or if we have our servers and our own company
that we have valid digital
certificates that are in place to
validate who we are as a web server,
or end users need to make sure that when they're going to
different websites that were certificates
we see are valid and match the website we're going to.
We can also use our digital certificates
for secure authentication.
We need to be able to ensure that
two parties or two entities can
authenticate to each other in a secure way.
Sometimes this may involve multifactor authentication.
We can also use device certificates,
or the device itself has its own certificate,
and they can authenticate to another device or service.
A good example of this would be
if you had a remote user who was
wanting to connect via
your corporate VPN back to the corporate network.
Maybe it's not enough just to have a password
because the password could be guessed or cracked.
You may want them to use something
like a smartcard, for example,
and that smartcard would have
a digital certificate stored
on a chip that's on that card,
and the user would plug their card in,
and then they have to activate
it by using their PIN code.
Now we've established a multifactor authentication system
for this user to connect to our VPN.
They first had to have a password,
they add to use their smartcard,
and then their smartcard to be activated,
had to have a pin code.
That's multifactor to ensure that we have
the right person authenticating to our VPN server.
We can also use PKI automation support.
When our certificates are used for authentication,
we're logging a lot of events.
Sometimes these are going to be denials,
and sometimes it's going to be the granting of access.
But either way we can set up
different triggers to happen based
on certain thresholds on
the actions that we want it to happen.
For example, with our VPN user
that we discussed earlier,
maybe we don't want to allow
anyone to connect to our VPN after
midnight or we don't want to
allow anyone to connect before a certain time.
When those authentications come in,
even if they're valid,
we can have an automated playbook that will go into
effect to ensure that certain actions
are taken on those authentications based on
the steps or actions that we have set up ourselves.
This is really helpful
when we're looking for malicious events.
We want to be able to respond to
those as quickly as possible.
It's a lot easier to have
an automated process that performs
certain specified actions rather than having someone
sitting there looking for
events and then having them respond.
We could even take this a step further that if
someone successfully authenticates to our network,
we want to make sure that their device even reaches
a certain standard before it's allowed to gain access.
We may want to make sure that they have
a certain patch level or they
have a specific anti-malware products in place,
and we want to put all of that in
our automation so that even
if someone successfully authenticates,
if their device doesn't meet a certain standard or
our corporate policy that
we're not going to allow them to authenticate.
Federated PKI.
This is where we have two independent PKI hierarchies
that each support their own trust domains.
They have their own root certificate authorities
but they trust each other.
By doing this,
the users in the first group
automatically will trust the users in the second group.
This greatly expands the ability for organizations
to trust each other without
having to set up complex policies.
In a Federated PKI situation
you make sure that both of the organizations that
are involved have a common set of
policies there so that you're not giving
too many levels of trust away too easily,
you want to make sure that your policies
match each other.
I also wanted to clear up that it
doesn't have to be just two organizations.
They can be any number of organizations,
but for sake of an example we're
discussing two different organizations
that trust each other,
but you can have as many as you want it on
a global scale and
all those organizations will be able to trust each other.
Let's summarize. We went over
asymmetric encryption and public key infrastructure.
We also went over the components of
PKI and certificate authorities.
We discussed the common usages of PKI,
Federated PKI, and secure authentication.
Let's do some example questions. Question 1.
True or false, in public key encryption,
the receiver's private key is used to encrypt
messages to them/ false.
The receiver's public key is used. Question 2.
Blank is a set of independent PKI hierarchies that
trust each other. Federated PKI.
Question 3. This is used for PKI that involves
software proving its authenticity as safe to be used.
Code signing. Question 4.
A blank will validate
certificates so that their authenticity can be proven.
Certificate authority. I hope
this lesson was helpful for you
, and I'll see you in the next one.