CSC 479/579 Public Key Certificates Lab

We want to look at how various types of cryptographic tools that we have been learning about can be put to work to solve the problems of authentication, confidentiality, privacy, and integrity in real-world programs. This lab does not need to be handed in for grading. However, other graded homework will build on this lab.

We are particularly interested in solutions to the problems of authentication and integrity in the context of network programming and web applications.

Public Key Certificates

To use public key encryption, a person (Alice) must first generate a pair of keys: one private, kept secret; and the other public, distributed to all who wish to communicate with Alice. Whatever is encrypted with one of the keys in the pair can only be decrypted with other key in the same pair.

Public key cryptography can be used for encryption. To ensure confidentiality, a second person (Bob) needing to send Alice a message encypts it with Alice's public key: because Alice is the only one who knows the corresponding private key, she is able to decrypt the message.

Public key cryptography can also be used for digital signatures. If Alice encrypts a message with her private key, then anybody can use Alice's public key to decrypt it. Any message that is successfully decrypted using Alice's public key must have been encrypted by Alice's private key. Because Alice is the only one who know this private key, we can be sure that the message was sent by Alice.

But how do we know we are using Alice's public key? That is, how can we be sure that we are not really using the public key of someone (Eve) pretending to be Alice? This is where digital certificates come in. We learned about digital certificates earlier in the course. You can refresh your memory by consulting your notes, the class textbook, or online sources. To be trustworthy, a certificate must be digitally signed by trusted Certificate Authority (CA).

We are interested in certificates because almost all approaches to Internet or web applications rely on certificates to authenticate servers to clients (for example, to authenticate web servers to web browsers) and sometimes, to authenticate clients to servers.

Contents of a Digital Certificate

The most common standard for a digital certificate is X.509. The most recent X.509 standard for digital certificates is v3. The structure and contents of X.509 certificates is here. You can learn about digital certificates in general here.

The contents of a digital certificate include:

Viewing Certificates

Servers that support HTTPS (HTTP over SSL) and (SSL) Secure Sockets Layer (We will learn more about SSL later) must have a certificate that vouches for the server's public key.

To view a web server certificate, Use Internet Explorer to navigate to Discover Card web site. It is essential to use IE because different browsers behave differently.

Click on the little DFS Services window (the one with the padlock icon)

From the General tab, you can find answers to the following questions:

  1. Who the certificate is issued to
  2. Who is the issurer of the certificate
  3. What version of X.509 the certificate is
  4. The span of time during which the certificate is valid

Next, click on the Details tab. Note that you can determine all information pertinent to the digital certificate. Note also the the CRL list: which is the Certification Revocation List. You can learn more about the CRL online.

Finally, click on the Copy to File... button on the Details tab. This will lead to a page that allows you to copy a certificate and store it on disk in one of several standard forms or export file formats. Make a note of these forms. In particular, make a note of the language used for the place on disk where you store a certificate: certificate store.

Getting and Using Certificates

Different operating systems and different servers come with different utilities and/or procedures for creating public key encryption key pairs and the certificates to go along with them. A self-signed certificate is one that you create yourself: self-signed certificates are useful for testing and development. In general, you would obtain a certificate by creating a self-signed certificate, or by gettting one from a recognized certificate authority. You then store the certificate on your disk in a file called a certificate store (or a sometimes, a key store). Lastly, you configure your network servers and web servers with the location of the certificate. Many of these tools allow you to create a certificate request that you can send to a recognized certificate authority such as Verisign to obtained a CA-signed certificate. More about this later.

Viewing Certificates in Firefox

Bring up the same Discovercard web page in Mozilla Firefox. In one version of Mozilla, the DFS Services appears in the address bar just to the left of the URL. Click on it. You should see the dialog box below

This gives the same information as before, albeit in slightly different forms. If you press the Details tab, you can see more information about the certificate. For example, you can see that Mozilla Firefox identifies the Digital Signature Algorithm used by the CA to sign the certificate.

Certificates in Java

Java uses a file (database) called a keystore to store keys and certificates. The JDK comes with a command line tool called keytool that can be used to work with key stores.

Open a DOS command prompt and type the command

    C:\>keytool
    

This simply displays the different command-line options you can use with the keytool utility.

Note: You need to make sure that the PATH environment variable is set to the directory that contains the JDK binaries. If the above does not work, there are two options you can try. The first option is to type the full pathname to the keytool utility, something similar to the following

    C:\"Program Files"\Java\jdk1.7.0_17\bin\keytool
    

You will have to make appropriate modifications depending on the version of Java on your system.

The second option is to add the path to the Java bin directories to your system path. If you do not have Administrator privileges, you can add it to your user's path rather than the system path.

By default, keytool assumes that the keystore database is named .keystore, and that it is stored in your home folder. In Windows XP, this is

    C:\Documents and Settings\username\.keystore
    

and in Windows 7, it will be something like
    C:\users\username
    

while in Unix systems, this will be in a location such as

    /home/username/.keystore
    

The .keystore database will be created at the given location the first time you invoke the keytool command.

What you can do with keytool

Note the list of commands you can execute with the keytool command:

C:\>keytool
Key and Certificate Management Tool

Commands:

 -certreq            Generates a certificate request
 -changealias        Changes an entry's alias
 -delete             Deletes an entry
 -exportcert         Exports certificate
 -genkeypair         Generates a key pair
 -genseckey          Generates a secret key
 -gencert            Generates certificate from a certificate request
 -importcert         Imports a certificate or a certificate chain
 -importpass         Imports a password
 -importkeystore     Imports one or all entries from another keystore
 -keypasswd          Changes the key password of an entry
 -list               Lists entries in a keystore
 -printcert          Prints the content of a certificate
 -printcertreq       Prints the content of a certificate request
 -printcrl           Prints the content of a CRL file
 -storepasswd        Changes the store password of a keystore

Use "keytool -command_name -help" for usage of command_name

Note that you can use this tool to generate a pair of keys for public key cryptography (-genkeypair); or a secret key (-genseckey), and to generate a certificate request to be sent off to a certificate authority. In fact the tool allows you play the role of a certificate authority so you can generate your own certificates (gencert).

Creating a Java Certificate

To create a certificate with a name test in the default keystore using the default signature algorithm (DSA), use the incantation

    C:\>keytool -genkey -alias test
    

At this, keytool will open the default keystore, create a certificate, and add it to the keystore. Keystores are password protected, so you will be asked for a password. If this is the first time you are creating a keystore, you will be asked to specify the keystore password. Otherwise, you must use the password you established when you created the keystore. Here is a sample interaction:

C:\Users\gcmuganda>keytool -genkey -alias test
Enter keystore password:
Re-enter new password:
What is your first and last name?
  [Unknown]:  Godfrey Muganda
What is the name of your organizational unit?
  [Unknown]:  Computer Science
What is the name of your organization?
  [Unknown]:  North Central
What is the name of your City or Locality?
  [Unknown]:  Naperville
What is the name of your State or Province?
  [Unknown]:  IL
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=Godfrey Muganda, OU=Computer Science, O=North Central, L=Naperville, ST=IL
, C=US correct?
  [no]:  yes

Enter key password for 
        (RETURN if same as keystore password):
    
    

The last line asks for a password you want to use to protect the newly created certificate inside the keystore. (You have the option of protecting each certificate in the keystore with its own password). If you press ENTER, the keystore will use the keystore password for the certificate entry password.

At this point, you can issue the following command to view a list of all entries in the keystore:

    C:\>keytool -v -list
    

Results look like this:

T=IL, C=US
Issuer: CN=Godfrey Muganda, OU=Computer Science, O=North Central, L=Naperville,
ST=IL, C=US
Serial number: 1e1c98b7
Valid from: Thu May 07 14:42:12 CDT 2015 until: Wed Aug 05 14:42:12 CDT 2015
Certificate fingerprints:
         MD5:  79:46:7C:75:AB:9F:12:1B:60:90:4E:2B:3A:58:02:13
         SHA1: 2D:BB:88:D6:EE:E0:F6:AF:10:8F:64:00:DF:E2:FF:15:B7:E0:EB:5A
         SHA256: C7:EE:7E:DE:79:A5:A3:89:C6:FC:FE:57:CA:F9:1D:C8:69:E7:61:2F:9E:
95:97:BC:D4:AC:5B:B7:2A:47:14:CE
         Signature algorithm name: SHA1withDSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: B7 78 26 D8 E8 D2 3A 06   F9 CF E3 E9 D8 76 3D 70  .x&...:......v=p
0010: 77 8F BF B0                                        w...
]
]

	

Note the occurrence of concepts we have been studying: the certificate fingerprints are just cryptographic hashes of the entire certificate with different hashing algorithms. The digital signature algorithm for the certificate is SHA1withDSA, that is, you form a cryptographic hash with SHA1 and then sign the has with DSA.

Working with Certificates and Keystores in Java

Here are a couple of classes you should look at to learn more:

    java.security.KeyStore
    java.security.cert.Certificate
    java.security.cert.X509Certificate
    

Here are the respective links for KeyStore class, the Certificate class, and the X509Certificate class.

Continue to the lab on SSL Programming .