|
|
ITS 2110 - Introduction to Network Security
Chapter 4 - Advanced Cryptography and PKI
Objectives:
This lesson continues our discussion of cryptography. Objectives important
to this lesson:
- Digital certificates
- Use of digital certificates
- Public Key Infrastructure
- Key management
- Transport protocols
Concepts:
Chapter
4 continues the
discussion of cryptography. On page 152, it turns to the topic of digital
certificates.
As discussed above, it can be based on the public key system, but it
has a problem. Consider the discussion in the text of the way it should
work: If you and I both have public and private keys, I can encrypt
something with my private key that you can decrypt with my public key.
Anyone else could decrypt it as well, but this step proves that the
encrypted form came from me, or at least from the person whose public
key you have.
In
the example in the text, I can send a message to you encrypted with your
public key (which only you
can decrypt) along with a hash made from the message
and
encrypted with my private key. The encryption
of the hash proves that it came from me: you can decrypt it with my
public key. The hash itself will match a hash you can make from the
decrypted message, proving that it has not changed. This is a secure
system as long as our private keys remain private,
and our public keys are not available except
by a secure method. As the
book explains, the system fails if you think you have my public key,
but you really have the key of an impostor who sent the message in the
first place. In other words, you know that the message is unchanged
since it left the person who sent it, but how can you be sure that it
came from the person you think it came from? How do you know my public
key is really mine?
You need to get my public key from a trusted source, like Verisign,
which is now affiliated with Symantec/Norton. If I register my public
key with a trusted source (typically a certificate authority),
or have them create it in the first place, they provide me with a copy
of the key that is endorsed by them, which makes it a digital
certificate. When I send this certificate to someone, they
can verify that it is from an authority that can be trusted. Note the
properties of a digital certificate listed on page 154:
- name or alias of the public key owner
- public key
- name of the certificate issuer
- digital signature of the issuer
- serial number of the certificate
- expiration date of the certificate (technically, not of the
key, but they may be the same)
This leads us to an industry that supports verified identities
by
the use of digital certificates. Some terms associated with it:
- certificate authority
(CA) - an agency that issues digital certificates; the CA may create
key pairs for users or accept them from users who create them; the CA
is responsible for verifying the identity of the key owner;
organizations with the proper software can act as their own internal CA
- registration authority (RA) - an entity
that takes on some of the tasks of a CA and operates on their behalf
- certificate revocation list (CRL) - a list
of certificates that are no longer valid for various reasons
- certificate repository (CR) - a public
directory of valid certificates; may contain invalid certificates as
well or may link to a CRL
The
text moves on to discuss different types of digital
certificates.
- personal digital certificates (class 1) - for individuals
to use as needed
- server digital certificates (class 2) - for web servers,
mail servers, and other type servers to confirm identity of the
operator; also used by servers to confirm secure SSL sessions
- software publisher digital certificates (class 3) - to
confirm data integrity of published software
- X.509 - a standard defined by the ITU; features are listed in the
text
The
certificates described so far have been single-sided,
which means they only confirm identity. Dual-sided
certificates are actually two certificates: one to
confirm identity (signing certificate), and the other
to confirm encryption (encryption certificate).
Public
Key Infrastructure
The Public Key Infrastructure is the system (or a specific system) that
includes all the concepts listed so far in this chapter.
Trust Models
The
text lists five trust models, but discusses three of them. One that is
only mentioned is the web
of trust, which is the model that would exist without any
Certificate Authorities. The text describes this situation as one in
which all entities know and trust each other directly (direct
trust). The other models involve third party trust,
in which Certificate Authorities are used.
- Hierarchical Trust Model - one
CA (the root) grants all
certificates with a single key, and all entities in the system trust
it; there is a single point of failure and all work falls on the one CA
- Distributed Trust Model - multiple
CAs exist; a CA can
delegate certificate duties to other CAs; a single failure will not
break the entire system
- Bridge Trust
Model - a model that is actually a hybrid of the
other two; a bridge
CA links CAs in the other kinds of models
Managing PKI
The text describes three concepts to manage the PKI entities
better. More acronyms to recognize.
- Certificate Policy (CP) -
a set of rules that dictate what the CAs, RAs, and
other entities must do to operate
- Certificate Practice Statement (CPS)
- if a CP is a set of rules, a CPS is a set of procedures for
implementing those rules; the CPS states how entities
request and perform services
- Certificate Life Cycle
- certificates should have a planned creeation and removal process, so
this concept addresses four life events for a certificate:
- creation - includes the procedures to follow to verify
identity, grant and issue a certificate, and publish a certificate
- suspension - when a certificate should go out of use
temporarily, the suspension process is used
- revocation
- when a certificate is found to be invaalid because it has been
compromised, the owner is out of business, or for other reasons, the
certificate is revoked and moved to the CRL
- expiration
- the normal end of a certificate's lifee; one might wonder if this is
to sell the owner another one, but it is also sensible to end
certificates regularly in case they have neither been suspended nor
revoked but should have been and the CA knew nothing about it
The text continues with a discussion of the care of keys used
in PKI. Three concepts and more subconcepts once again:
- Key storage
- the text recommends storing public keyys in digital certificates, or
on hardware devices from the CA; it recommends storing private keys on
hardware like smart cards or tokens, since they can be vulnerable to
attackers when left in file storage
- Key usage - this concerns how to use
multiple key pairs to maintain as much security as possible
- Key handling procedures
- this is similar to the life cycle conccept for certificates; it could
have been called a key life cycle but it is called key handling instead
- escrow - a third party, such as a CA,
holds the keys
- expiration - keys expire so that a
stolen key is not good forever
- renewal - this is an extension to the
life of a key about to expire; this invalidates the security aspect of
expiration
- revocation - turning off the
functionality of a key before the expiration date; there is no
reinstatement from this
- recovery - although it is not listed
as a handling method, a key can be archived, and
removing it from that status is recovery
- suspension - a temporary status to
remove the key from use
- destruction
- a permanent status that erases the infformation about the key and the
user from the CA, which is not done for expiration or revocation
Cryptographic Transport Protocols
The
last major concept for the chapter discusses types of protocols
associated with encrypted data flowing across a network:
- File Transfer Protocol (FTP)
- FTP does what it sounnds like,
it moves or copies files in a TCP/IP environment; the text describes
its problem: no encryption, which makes it vulnerable to
man-in-the-middle attacks
The text recommends using a secure protocol instead when updating web
sites or moving sensitive data. Secure
FTP (SFTP)
can use either of the next
two protocols as
a basis.
- Secure Sockets Layer (SSL)/Transport
Layer Security (TLS)
- You have probably used SSL every time you have made
a
purchase across the Internet. The vendor site sends a public key to
your computer, your computer encrypts the transaction, and the
resulting SFTP data stream can only be decrypted with the vendor's
private key. (You should know this concept very well by now.)
The text explains that TLS is an improvement over SSL.
This
link goes to a Wikipedia article that discusses the same point,
as well as the uses of TLS which include email.
- Secure Shell (SSH) - SSH
is another method used to
implement SFTP. This is a Unix based protocol, that can be used to
replace Telnet, and it is used to provide secure login, file
operations, and command line operations on the remote server.
- Web protocols - such as HTTPS
and SHTTP,
provide SSL versions of HTTP. Note the discussion of ports: HTTP
typically uses port 80, while HTTPS
typically uses port 443.
- IP Security (IPsec) -
IPsec is described as a preferred protocol because it is implemented at
a lower layer in the ISO network model (Network layer) than PGP
(Application layer), Kerberos, or SSL (both at the Session layer). As
such, it is more transparent to processes that occur at higher layers,
to users, and to software running on the workstation. The text
discusses the virtues of IPsec for several pages.
- S/MIME -
uses digital certificates to protect email. This
protocol is built into most email applications.
|
