Computer Security: Public Key Cryptography
Two main threats to the security of your information
come from the following:
1
- unauthorised access to files and programs stored on computer through network connections; and
- Interception of information you are sending from your computer to others.
The first may involve malicious code (programs) that
you download whilst browsing the web. This download could be deliberate because
you believe the code is from a trusted source (such as Apple or Microsoft) or
unintentional such as code hidden in web-pages or email attachments. The second threat arises when you send files to
others, as attachments to emails, or perhaps more significantly, when you are
logging in to remote servers. If your
username and password are intercepted while logging into remote servers, then
there is a risk that an unknown third party may access your data by posing as
yourself.
The following sections look at basic technical
approaches to dealing with these two threats.
There are other threats which are not covered here. Included in these other threats are those in relation to how your
information is managed by organisations who have obtained it and how
information is collected based on your patterns of usage. However, this post looks only at methods
of restricting access to your system and your communications, not at what
others may do with it once they have access to it. The primary technical
approach we look at here is the use of digital signatures and certificates to
identify organisations and parties you trust and as a means of keeping your
communications secret when they are sent across a publicly accessible network
such as the internet. The material below is drawn from the author’s own
knowledge accumulated from various sources over the years, however, for those
who are interested in reading further a bibliography is provided.
Digital
Signatures and Certificates
Digital signatures and certificates are used when
we need to know if some information or computer code has come from a trusted
source or not. They are also used when we want our own communication across the
internet to be kept secret, for example, when logging in to internet banking. So how can we make sure that some code we download
from the web is safe to run on our computer without installing a virus,
damaging our files or secretly stealing our private information? One method is for programmers to sign their code
using a form of encryption to generate a digital signature using a
method known as Public key cryptography. Public key cryptography uses a
pair of keys which are generated to produce a private key and a public
key. The private key is held by the code producer and never revealed to
another party, while the public key is freely distributed to anyone using the
code.
Encryption done using the private key can be read
by anyone using the public key. Reading and verifying who created code is
usually managed by applications without the user’s knowledge (for example
Mozilla). The public key can also be used to encrypt messages which can only be
read by using the private key. This is the method used when sending your
username and password to internet banking sites.
Cryptography based on using the same key (rather
than a private and public key) is referred to here simply as Secret Key
Cryptography or symmetric cryptography. Public/private key cryptography is referred to
as asymmetric cryptography.
How can you then be sure that I am who I say I am?
One way is to check that the public key I sent is in fact my public key. Since
no-one else can encrypt messages for reading with my public key, this
verification should be sufficient.
Third party organisations are set up to
issue digital certificates that the holder of a public key is in fact
who they say they are. These certificates are usually signed with the
certifying organisation's own key to ensure the certificate is genuine.
Programs such as the Java runtime and web-browsers maintain
a local database of trusted code signers along with information on who each signer
is and what verification they have of their key. Each entity from which you are receiving code or
encrypted information has an identity created in this database which indicates
whether they are a trusted or untrusted signer.
The database allows for you (or
programs you use) to record details of that entity, such as their organisation
name, their public encryption key, the algorithm used by that signer and the
third party which authorised that key.
Associated with each key is a digital certificate
which authorises that key for the entity, this ensures that the key has been
verified as belonging to the signer. These certificates can be provided by a
third party or created yourself for signers you can trust. As mentioned, the
certificate is usually itself digitally signed with the key of third party
issuing the certificate.
Once you have recorded an entity's public key and
associated a verification signature with it you can determine if files signed
with that digital signature come from a trusted source.
The files are signed incorporating the output of a hashing algorithm which produces a digest
(a kind of checksum) based on the characters in the
jar file they are signing. If you can decrypt the signature associated with
file, you can then check that the code has not been changed by checking the
output of the hashing algorithm with output generated by running that algorithm
over the file on your machine. This process is illustrated in Figure 1 below. The code provider wants clients to be able to
check who produced and sent the code.
The provider produces a digest from the code using a hashing
algorithm. This digest is then encrypted
with the private key and sent with the code.
The client already has the public key (or can easily download it) and
uses this to decrypt the digest. The
client then uses the same hashing algorithm as the sender to producing the
digest locally. If this local digest matches the decrypted digest then the
receiver knows that it was sent by the owner of the private key. As a bonus,
the receiver can also be sure the code was not changed or damaged during
transit.
Figure 1: Signing code to be sent
across the internet.
Figure
2 shows the process of encoding and
sending a message (as a file) using a symmetric key. The message is passed to an encryption
algorithm (program) with a key (a number) that produces an encrypted version of
the file. The file is then sent across
the network to the receiver. The
receiver uses the same algorithm (in reverse) and key to decrypt the received
file into its original form. Symmetric
encryption algorithms are desirable because they can produce encoded messages
that are difficult to ‘break’ (i.e decode without knowing the key) whilst not
slowing the computer down too much. The biggest problem with symmetric keys is
that you need some way of sharing the key without other’s being able to read
it. One solution to this problem is to
use asymmetric encryption which we
look at next.
Figure 2: Symmetric Encryption.
Asymmetric
encryption is similar to symmetric, except it uses special algorithms that
allow the use of two mathematically related keys. The relationship is such that data encrypted
using a public key can only be decrypted using the private key (and
vice-versa). This depicted below. However, the algorithms to encrypt and
decrypt asymmetric keys are very resource intensive and could cause serious
delays on servers dealing with hundreds or thousands of clients over a short period.
Figure 3: Asymmetric encryption.
The
fact that the asymmetric nature of public/private keys also works in reverse
solves the main problem of symmetric communication i.e of how to secretly share
a symmetric key. The problem is solved by the client encoding a symmetric key
using the server’s public key and then providing the server with this before
communications starts. This key can only be read by the server who uses it to
establish communications using a cheaper symmetric encryption agreement. This process is depicted as Model 1 in Figure
4.
Figure 4:
Private-public key communication.
An
alternative model is to use a third party server such as Kerberos. This process is shown as Model 2 in Figure 5.
It replies on a trusted third party (the Kerberos server) holding copies of
each entity’s session keys. When two or more entities want to communicate
secretly one of them asks the Kerberos server to create a key they can all
share just for this communication session. The Kerberos server then creates
encrypted session keys upon this request. A copy is made for each participant
and encoded using their stored entity key. The session keys are then
distributed between the communicating entities. Each entity then decrypts the
Kerberos message using its own symmetric key to access the session symmetric
key.
Figure 5: Kerberos
Communication.
In addition to the standard HTTP protocol, most
web-servers (and browsers) also support the Secure Sockets Layer (SSL) protocol
using HTTPS.
SSL allows you to communicate with a web server
using public and private keys to establish communication using symmetric
encryption.
Bibliography
Kerberos: An Authentication
Service For Computer Networks Neuman, B.C and Ts'o, T USC/ISI Technical
Report ISI/RS-94-399.