Lecture 18: Encryption #3 -- Practical Encryption
Key CertificationIn the last tutorial,
we saw an example of a "man-in-the-middle" attack -- Trudy
convinces Bob that her (Trudy's) public key is that of Alice, and Bob is none
the wiser. Public key systems are vulnerable to varieties of such attacks
whenever the validity of a public key cannot be positively verified.
This problem can be solved by the use of a Certificate
Authority, or CA. A CA is a trusted
intermediary who certifies a public key as follows:
- The CA first verifies the identity of the person or organisation seeking
to have their public key certified. How this happens is up to the CA itself --
we simply have to trust that their methods are sufficient.
- The verified applicant's public key is incorporated into an X.509
certificate. The certificate contains, in addition to the
public key, the "distinguished name" of the applicant (sufficient to uniquely
identify them), plus some other stuff. The certificate is digitally
signed by the trusted CA's private key.
The CA's public key can subsequently be used by anyone to
verify the validity (and truth) of the certificate, and thus can verify its
holder's public key. For this to work, the CA's public key must be widely
disseminated in such a way that everyone knows it and trusts that it
is, indeed, the public key of the CA that it purports to be. It should be so
well-known and widely available as to become "common knowledge" -- any attempt
to fraudulently represent another key as being that of the CA should be easily
Typical CertificatesAs we shall see, one of the most common uses of
CA-signed X.509 certificates is in Web Commerce, where they are
normally called site certificates. Here are two examples:
NB: Web browsers normally
are configured to trust a small set of CAs (or certificate issuers) -- either by
configuration (see Preferences), or (in earlier versions) established at
compile-time, see later.
Secure Sockets Layer (SSL)Internet Web-based commerce ("E-Commerce")
relies for security on a hybrid symmetric/public key system called
SSL, originally developed by Netscape,
but widely adopted by others. SSL adds a new protocol layer between the
application and transport (TCP) layers. It provides the following:
- Authentication of identity of server, using an X.509 site
certificate as above. Recall that the sample certificates contain the
domain name of their owner -- this can be checked against the
sitename which supplied the certificate, so that we know that we are, for
example, connecting to
www.amazon.com and not
hackers-r-us.com masquerading as them.
- Optional (and currently rarely used) authentication of client. The
protocol has provision for the initiating client to identify him/herself with
a personal certificate. This has potential usefulness in
future (so-called) "Business-to-business" E-Commerce applications.
- Encryption of HTTP session, whereby all subsequent
communication between the client and server is secured using a negotiated
symmetric session key.
SSL ProtocolAn SSL session is (as usual) initiated by the client, by
connecting to a server on port 443:
- The initial connection ("Hello") message contains details of the client's
preferred symmetric encryption algorithms -- SSL provides for a large
number of different technologies -- so that the two parties can
negotiate the use of a a common algorithm.
- The server's response consists of an X.509 site certificate containing its
public key and some other stuff, as well as its preferred symmetric
- The client verifies the contents of the server's site certificate, by
checking both its contents (domain name, date, etc) and that it has been
signed by a known and trusted CA. It also chooses an acceptable symmetric
algorithm from those available.
- The client generates a new, random "session key" appropriate to the
negotiated symmetric algorithm. This is encrypted using the server's public
key and sent back to the server.
- All HTTP traffic between the client and the browser is encrypted using the
Certificate Authorities and PKIMost Web-based E-Commerce SSL sites
purchase site certificates from a commercial provider such as Verisign, Thawte and many others. In future, a
Public Key Infrastructure will be needed to manage aspects of
applications will involve certificates issued (for example) for use within an
organisation, or department. In this case, a certificate is
signed by its issuer. In order to establish the validity of the
issuer's signature, the application may need to obtain the issuer's CA
certificate as well, which is, in turn, signed by the next higher authority --
verifying a certificate chain. Note that the root CA is
implicitly trusted -- as soon as the client software encounters a certificate
signed by this CA, authentication is complete.
The protocols and procedures for issuing, managing and revoking signatures,
certificates and registration authorities are still under development. Watch
PGP (Pretty Good Privacy)The history of PGP is outside the scope of our unit, but is well documented. PGP is a
free, "clean room" implementation of the original RSA public key cryptosystem,
created with the honourable intention of facilitating encrypted email. It has
become the most widely used public key software in the world.
PGP can operate in two modes: either encrypting a message
where both authentication and secrecy are required, or simply
signing a message if only authentication and message integrity
PGP encryption is actually a hybrid symmetric/public key
system. A new session key is created for each encryption, and is used to encrypt
the document, using a standard algorithm such as IDEA. The session key is then
encrypted with the recipient's public key, and the two items
are rolled together into a single package. The receiver can use his private key
to decrypt the session key, and thus recover the original message:
This approach combines
the best features of symmetric and public key encryption.
PGP Digital SignaturesPGP uses the modern terminology for digital
signatures, where the document itself is not encrypted, but an encrypted
message digest is appended for transmission:
It's obvious that it is
possible to both sign and encrypt a document in PGP if required.
PGP Key ManagementPGP has the same difficulty as other public key
systems: how to distribute keys in such a way as to avoid a successful
"man-in-the-middle" attack. In commercial RSA-based products (such as SSL for
Web-based E-Commerce) the solution is commercial Certificate Authorities. PGP
adopts a more "low-tech" (but highly effective) approach called a Web of
PGP implements certificates, exactly analogous to the X.509 certificates
discussed earlier -- in fact, PGP can use X.509 certificates. The PGP
certificate extends to allowing multiple signatures, which
allows several people to independently attest that the certificate is genuine.
In the PKI slide, earlier,
the trust model was hierarchic. In PGP it is
cumulative -- a certificate gains authority as more people sign
it. A signer for a certificate becomes an introducer for that
certificate. For example, if you trust me, and
I appear as an introducer of a new certificate, then you will tend to trust the
certificate as well -- as in: "I trust him, and he trusts the other guy, so I
guess I trust the other guy as well..." Trust becomes
In the early days of PGP, an initial Web of Trust was established by holding
PGP signing parties, where people would identify themselves to
others, and then sign their certificates. PGP also has the notion of
complete trust and marginal trust, in addition
to untrusted certificates.
More InformationThe links in the body of this lecture were primary
sources. The following might also be useful:
In VeriSign We
Copyright © 2003 by Philip
Scott, La Trobe University.