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

RFC2617 - HTTP Digest Access and Authentication. 

Kerberos: An Authentication Service For Computer Networks Neuman, B.C and Ts'o, T USC/ISI Technical Report ISI/RS-94-399.

Mozilla Development Network: Introduction to Public-key encryption

Mozilla Development Network: Introduction to SSL