PKI Uses
Understood Nothing
You've probably heard
the term PKI being used in a work environment. And if you're into IT security,
you'll be well familiar with the term. PKI stands for Public Key Infrastructure. Essentially, what it is, if we can water
it down to a single sentence, is it's a hierarchy
of digital security certificates, where unique public and private key pairs
are issued for each certificate. So certificate authorities, otherwise called
CAs, are authorities that issue certificates. They can renew certificates
because certificates have an expiration date, and they could be renewed before
they expire. They also do have an expiration date where they will simply expire
by themselves, where they can no longer be used.
And also certificate
authorities are responsible for revoking certificates, maybe due to compromise
of a station or because a user is leaving the organization. We also have the
option of working with our own private internal certificate authority. You
might install a product like Microsoft Active Directory Certificate Services or
maybe you would use OpenSSL. But either way you can have a private CA where you
sign your own certificates. The only issue with that is that devices out there
on the network don't trust your private, self-created certificate authority.
So you would have to
install the root certificate for your CA on those devices. Of course, we've got
public CAs where we could have a certificate signing request that we've
generated issued up to the public CA. And after they've done their due
diligence, their CA can digitally sign and return our certificate. We might do
that, for example, if we need a website certificate that's trusted globally. So
what is PKI used for? Well, it uses a public key. And the public key can be shared publicly with any user or device, that's
why it's called a public key.
So the recipient public
key then would be used when we encrypt a message that we're sending to that
recipient. We need their public key to encrypt it. Public keys are also used to
verify digital signatures. Now the private
key must be available only to the key owner, whether that's a device or
whether it's a user. So it's not like a public key. Private keys are going to
be kept private only to the owner, and they can also be embedded in things like
cards, like smartcards. So encrypted messages then are decrypted using this
key.
Remember up above you
need a public key to encrypt the message to somebody. You need their public
key. Well, they need their mathematically related private key from the key pair
to decrypt that message. The private key is also used to create a digital
signature. So if we have a need, let's say, of e-mail confidentiality, how does PKI serve this need? Well, we can encrypt the message with the
recipient's public key. The second item here is what if we need e-mail authenticity and integrity?
Well, a solution is to generate a
message hash and encrypt that hash with the sender's private key.
And often, that's done
seamlessly and transparently in modern e-mail programs. What if we have a need
to secure network communication to a web
server? Well, we would use a PKI
certificate issued to that web server and make sure that TLS version 1.1 or
higher are used. And then we would enable HTTPS on the web server. Now TLS
version 1.1 is a secure way to secure network communications using a PKI
certificate.
Using the older SSL
security protocol should never be done due to its large number of
vulnerabilities. And there are even vulnerabilities associated with TLS v1.0.
And that's why we're saying here you should start at TLS version 1.1. What if
we have a need to use Multi-Factor
Authentication to a VPN? Well, PKI could solve that because we might embed a private key on a smartcard,
which would be used. The smartcard would have to be available and presented
when we need to authenticate the VPN.
Finally, what if we have
a need to have a single card, a physical
card that people carry with them, that would allow things like facility
access, as well as computer access? Well, that's called a Common Access Card or a CAC. Essentially, it's a smartcard that has
multiple uses that contains an embedded private key.
PKI Hierarchy
The PKI hierarchy is a hierarchy
of digital security certificates, where certificates are issued and also
managed after they're issued by a certificate authority. We could have a
private certificate authority or a private CA that we set up within our own
organization and that private CA issues certificates and manages them. The only
thing we would have to consider is on all devices that need to trust
certificates issued by that private CA, we would have to install that private
CA's root certificate.
Public CAs are available for a
fee as well. Where we could send a certificate signing request up to the public
CA, either through a web form or through an e-mail file attachment. And after
the public certificate authority does their due diligence to ensure that the
information that we have provided in the request is valid, they can use their
CA, private key to digitally sign our certificate.
And if it's a public CA, it will
be trusted globally. So we might do this for example, if we have a public
website that we want to secure using HTTPS.
The PKI hierarchy starts at the
very top with the root certificate
authority or root CA. Now from there, the root CA could issue certificates
directly, but in a larger enterprise, you would have subordinate CAs.
Maybe for different parts of the
world, different countries, different provinces, different regions. Or even
within a large corporation, we might have different CAs for different
departments, or different projects. And each of those subordinate CAs, in turn,
can issue its own certificates.
A diagram explaining the PKI
hierarchy is displayed. The Root CA is at the top. The Root CA is connected to
Subordinate CA1 and Subordinate CA2. Subordinate CA1 and Subordinate CA2 are
connected to Certificates.
Now if that's the case, then the
root CA doesn't need to be there, doesn't need to be online and available all
the time, unless you're going to be doing something like creating a new
subordinate CA. So the issuing certificate authority digitally signs issued
certificates. And as we were saying, the root CA really, from a security
perspective, should be brought offline when it's not being used.
The reason is because if the root
CA is always left online and by chance, it gets compromised. Now it has a
higher degree of being compromised if it's always online. If that root CA at
the top of the hierarchy is compromised, all subordinate certificates are
compromised, including subordinate certificate authorities. So you can see why
this is a big deal.
Now, if we have a compromised
subordinate CA, then certificates issued by that CA are compromised, nothing
above it in the hierarchy. So it's always important then that we consider the
PKI hierarchy when we're planning our public key infrastructure, or if we're
making changes to an existing configuration and trying to harden it.
Create a PKI Certificate Authority Using Linux
In this demonstration, I'm going
to use Linux to create a PKI Certificate Authority. The first thing you're
going to need to do is to make sure you have the appropriate module or tools
installed to work with PKI in Linux. So for example, I could use the apt-get
install command if I wanted to install the openssl
package. Here I can see that openssl is already installed with the newest
version.
He opens the root@kali: /
window on the Linux operating system. The root@kali: /# prompt is displayed.
Then he executes the following command: apt-get install openssl. The output
displays the status of the latest version of the openssl installed.
So now what I'm going to do is
make a directory here on the root of the file system, and I'm going to call it
pki. And I'm going to change directory into the pki directory. Because any
files that are generated, I want organized in this location.
So what I want to do then is use
openssl, this is the command that's built-in once you've installed this. And I
got to tell it I want to generate some RSA keys, rsa, I want to use aes256 bit
keys. So AES is the algorithm. And I have to give it the name for an output
file. So I'm going to call this let's say ca_priv for private.key. That's the
private key file that will be generated. And then we're going to tell it that
at the RSA level, we want to make sure that we use 2048 bits. And we going to go
ahead and press Enter.
Generating CA Private Key:
He executes the following
command: openssl genrsa -aes256 -out
ca_priv.key 2048. The output displays a message: Generating RSA private
key, 2048 bit long modulus, and asks to enter a pass phrase for ca_priv.key.
Okay, so we now have a private
key that's 2048 bits, that's good. So the next thing we're going to do is enter
a pass phrase for the private key. I'm going to put in a password, and then I
will verify that same password.
Now the next thing that we want
to do is actually generate a CA or certificate
authority certificate. So to do that I'm going to run openssl req for
request -new and then -x509. x509 is the standard that's used for PKI
certificates. I'm going to specify my private key with -key. So that was called
ca_priv.key. Then I'm going to specify the signature algorithm, because
remember a certificate authority digitally signs certificates.
Here it's going to use sha256.
I'm going to specify in days, the lifetime of this certificate, so it's going
to be let's say, only 365 days, that's not very long for a CA. Commonly it
might be five years, maybe even ten years, but here I'm just going to make it
one year. And I'm going to specify the name of the output file for this CA
certificate. So -out and I'm going to call it ca, let's say .pem, standard file
format.
He executes the following
command: openssl req -new -x509 -key
ca_priv.key -sha256 -days 365 -out ca.pem. The output prompts to Enter the
pass phrase for ca_priv.key.
Now because we referenced our
private key it wants the pass phrase for it, that's good. You always want a
pass phrase on a private key file. So I'll go ahead and enter that, and then I
have to fill in some details because we're establishing a certificate
authority, so it has questions. So the country name, two letter code, in this case,
for Canada, I'll put in CA.
He enters the pass phrase and
presses the Enter key. The output includes a message that reads, You are about
to be asked to enter information that will be incorporated into your
certificate request. Country Name (2 letter code) [AU]:.
State or province, I'll fill in the
appropriate value, same with the locality, that's city name. Locality is filled
in, the organization name, I'll just put in here as FakeCo and organizational
unit, maybe Hq, headquarters. And a common name, so this would be for my
certificate authority, I'm going to call it MyCA. And then an email address for
a user. So that would be an administrative account, for example, so I'll fill
that in.
He enters the email address
as user@fakeco.com. He again presses the Enter key and the prompt remains the
same.
ca_priv.key -> Private Key
ca.pem -> Certificate
Authority
Web of Trust
When you acquire a passport or a driver's license, that is trusted
by other government departments, and agencies, and institutions, because they
trust the issuer of the passport or the driver's license. And with Public Key
Infrastructure or PKI, the same type of web of trust exists.
So in the PKI hierarchy, the
issuing certificate authority or CA digitally signs issued certificates using
its private key. Now, only the CA owner has access to that private key and the
signatures created from it. Now, the signature is then used to establish trust,
because if we trust at the certificate authority then by extension, we also
trust any certificates that have that certificate authority digital signature.
Pictured on the screen, we've got a screenshot on the right of the trusted root's
certification authority's store on a Windows machine.
The screenshot of Trusted
Root Certification Authorities displays a table which includes Issued To and
Issued By column headers.
In other words, different types of operating
systems, in this case, Windows, have a list of public certification
authorities who they trust. And if they trust that public certification
authority, by extension, they trust any certificates issued by that authority.
So devices then, like your laptop, your desktop, your smartphone, needs to
trust certificate signers. Now, we're looking at the Windows trusted
certificate store, that's what we were talking about. But the same type of
system exists on a Linux host using the Linux CA certs key store.
So certificate trust stores then
have a list of trusted root and subordinate certificate authorities. And, as we
know, if you trust the certificate authority, then you also trust all the
certificates issued by that certificate authority. That's what the web of trust
is about. Now, with private certificate authorities that you might create
within your own organization, as opposed to public certificate authorities.
Certificate trust stores on devices will not automatically trust the CA. They
won't contain the certificate, the root certificate, and so they will not trust
any issued certificates.
So the trusted root certificate
then you would simply have to import on devices in your organization. Now, the
private CA will issue certificates and remember that they will then be trusted
on devices. The trust is established based on the CA signature contained within
issued certificates. So again, the overall theme is very simple. If you trust
the certificate authority, then you trust all of these certificates that are
issued by that authority. Just as in the same case, if you trust an issuer of
passports within a country, then you will trust all of the passports issued by
that country.
PKI Certificates
With Public Key Infrastructure,
PKI certificates are issued by a certificate authority, by a CA. And these
certificates could be issued to a user. Or may have a certificate issued to a
device like a smartphone that needs to authenticate to a VPN. Or we can even
have certificates issued to be used by software components or services. So
these certificates are issued by the CA for security purposes such as to
encrypt files or encrypt network communications.
To verify file integrity or
message integrity over a network to ensure it's not been changed. And also for
authentication such as over the network with messages so we can trust that the
message came from the sender it says it came from. So we can store PKI
certificates in many different places. It might be stored in a file, in the
file system on a device. A PKI certificate might be stored on a smartcard. So
there are many different ways that we can store these PKI certificates.
As a matter of fact, if you're
using a business computer like a laptop, you might even have the trusted
platform module TPM firmware chip which can also incidentally store PKI
certificate information. So what's in a PKI certificate anyway? How does this
work to allow security in an environment? Well, we know the PKI certificate is
issued by a CA and that it can be stored in a variety of different ways. What's
in it?
Well, the version of the X.509
standard that's used to generate that PKI certificate. The digital signature of
the certificate authority, which is important to establish trust. The signature
algorithm that was used by the certificate authority to create the signature.
For example, maybe it was SHA256. The certificate serial number is certainly
stored within the certificate.
The date the certificate was
issued, when it expires, how the certificate and the keys can be used whether
only for encryption, or maybe only for authentication, or both. The subject
name which is important. The subject name could be the URL of a website, which
has to match what people are typing in for the certificate to be trusted. Or
maybe the subject name is a user e-mail address, if we're using user
certificates to encrypt and digitally sign e-mail communications. So the
certificate can also contain public and, in some cases, private keys.
Now the purpose here would be for
encryption and decryption. For example, we would encrypt with the recipient's
public key if we sent something to them. And they decrypt with the related
private key. Digital signatures are created with the private key and verified
with the public. In some cases, the private key will not be stored within a
certificate. So it really depends on the environment and how the certificates
are being used.
PKI certificates can also be
issued from templates depending on the solution that you're using. And as you
would guess, the template is just a blueprint of all of the details that will
be placed within the PKI certificate. The items that we just talked about.
Certificates and public or private keys can also be exported.
Now if we think about this, we
might have a certificate that contains a private key. And we might want to
backup the private key in a safe place. So we can actually export it as long as
when that certificate was issued, exportation of the private key was marked as
being allowed. Now public keys can be shared with anybody. And so it's okay to
provide a public key to anyone over the internet, whether you trust them
already or not, however, not the private key. And as we said, you might export
the private key from a certificate for backup purposes. Private keys should
only be available to the entity to which it was issued, be that a piece of
software, or user, or a device.
Now in the PKI certificate, we
mentioned the subject name field. And we said that this must match the entity such as the URL of the website or the
e-mail address of the user. So if that's not the case, then we won't have trust
established. So in the case of a secured website, if the URL that people are
typing in doesn't match the URL in the subject name field in the certificate,
then depending on the web browser people are using will determine exactly what
message pops up. But in essence, that site will not be trusted. And that is not
a good thing.
Issue a PKI Certificate Using Linux
In this demonstration, I will use
OpenSSL in Linux to issue a PKI
certificate to be used by a Linux web server.
The first time here, we're going
to use it to generate a private key file that will be used by our web server
certificate. And to do that, I'll run openssl genrsa, I want to generate an RSA
type of key, that's the algorithm that will be used. And the output file will
be, let's say, the file name can be anything, but I'm going to say
www.site.com.priv.key. So I know it's the private key and I want it to be a
2048 bit RSA key.
He executes the following
command: openssl genrsa -out
www.site.com.priv.key 2048. The output displays a message: Generating RSA
private key, 2048 bit long modulus.
Now, I have to generate a
certificate signing request. What I'm doing is preparing a file here that needs
to be submitted to the certificate authority whether it's on this host or
whether we send it through e-mail or paste it in to a web form field. One way
or another, the certificate signing request has to be sent to the CA because we
need the CA to digitally sign it and send it back to us. So let's generate a
certificate signing request, openssl req -new.
And I have to tell it to the key
-key, the private key that is, that I've generated previously for this web
server certificate. And then I have to specify an output file for this
certificate signing request. So how about we call it www.site.com.csr, for
certificate signing request.
He executes the following
command: openssl req -new -key
www.site.com.priv.key -out www.site.com.csr. The output includes a message
that reads, You are about to be asked to enter information that will be
incorporated into your certificate request and the field: Country Name (2
letter code) [AU].
It's going to ask me for a bunch
of stuff like the Country name and so on. I'm going to specify, let's say, CA
two character country code, state or a province of some kind, so I'll spell
that out. A city name, organization name, and I'll just fill in some values
here. And the common name is important because if people will be entering,
let's say, www.site.com in a web browser to access my secured web server, then
I'm going to have to make sure that that is in the certificate. So I'm going to
put that in as the Common Name, for the Email Address, maybe admin@fakeco.com.
He types CA for the Country
Name (2 letter code) [AU] and presses the Enter key. The output prompts: State
or Province Name (full name) [Some-State] and he types Nova Scotia. He presses
the Enter key, the output prompts: Locality Name (eg, city) [], and he types
Halifax. He presses the Enter key, the output prompts: Organization Name (eg,
company) [Internet Widgits Pty Ltd], and he types FakeCo. He presses the Enter
key, the output prompts: Organizational Unit Name (eg, section) [], and he
types Hq. He presses the Enter key, the output prompts: Common Name (e.g.
server FQDN or YOUR name) [], and he types www.site.com.
Now, when you do this with public
certificate authorities out on the internet, you don't just make this
stuff up. It has to be filled in correctly. So do I want a challenge password
to be used with this signing request? No, so I'll just press Enter, optional
company name, Enter.
And if I clear the screen and
type ls, we now have a certificate
signing request file, csr.
So as you might have guessed, the
next order of business is we need to ask the certificate authority, which is on
the same host, it doesn't have to be. But we've got the private key for the
certificate authority and the certificate file for a certificate authority I've
previously created already available here.
He highlights the private
key: ca_priv.key and certificate file: ca.pem in the output.
So that in conjunction with the
certificate signing request will allow us to actually generate a usable PKI
certificate for the web server.
In the real world, when you
request a certificate from a public authority, they'll do some due diligence to
make sure that the information you provided is accurate and correct. So trust
is very important with this. Now notice here, I've got a file I've already
prepared called otherinfo.ext. It's extension, or additional information, you
can think of it as a template that will be used to issue certificates. And if I
used the cat command to display the contents of that file, you're going to see
what I've typed in here.
So I've typed in a bunch of
stuff, notably, keyUsage, how can this be used, for digitalSignature, for
keyEncipherment. In other words, for encryption of keys and also for the
encryption of data, dataEncipherment. But what's really important here is the
subjectAltName, san, S-A-N which is referring to a section further in the file
called @alt_names. And here it is down here. So the first DNS name, DNS.1 is
going to be the URL people will enter to connect to my site, www.site.com. So I
actually want that injected into the certificate that we're about to issue.
Okay, so let's just clear the screen, let's just do an ls so we can see our
file names again here.
So I've created the command here.
It's openssl x509, that's the type of certificate we're creating, a PKI
certificate. We are looking at a request for an actual certificate, and we're
getting that from our certificate signing request input file, so -in. And I'm
just referring to the name of the CSR that we generated. Then I'm going to
specify the CA certificate file which happens beyond this machine that's called
ca.pem, then the CA private key file, same thing. It's on this machine.
I'll specify that and then the
output file I want to create here which is my actual web server certificate
file, the number of days that the web server certificate will be valid. So here
it's only one year, 365 days. The signature algorithm that will be used by the
CA to digitally sign the certificate, in this case, sha256 is the algorithm
that will be used, telling it to create a serial number. Because PKI
certificates are uniquely tracked by a serial number and then I'm specifying to
use that otherinfo.ext file with the extensions file parameter -ext file. And
remember, that maps our subject name to our alternative name, so the URL of the
host. And I'm going to go ahead and press Enter.
He executes the following
command: openssl x509 -req -in
www.site.com.csr -CA ca.pem -CAkey ca_priv.key -out www.site.com.crt -days 365
-sha256 -CAcreateserial -extfile otherinfo.ext. The output prompts: Enter
pass phrase for ca_priv.key.
So of course, it wants the pass
phrase for the CA private key, I'm going to go ahead and specify that value,
and then I'll press Enter. And that's it, it's done. If I clear the screen with
the clear command and type ls, we've now got an actual PKI certificate file
that can be used, in this case, for a web server, such as with the Apache web
server.
So then when we configure our web
server engine whether it's nginx or Apache or whatever it is to use that as the
PKI file to secure the connection normally over port 443.
