The Initium X.509 Certificate Wizard
Douglas Lyon, Fairfield University, Fairfield CT, U.S.A. |
 |
COLUMN
PDF Version |
barf [ba:rf]
2. "He suggested using FORTRAN,
and everybody barfed."
From The Shogakukan
- DICTIONARY OF NEW ENGLISH
(Second edition)
Abstract
This paper describes the use of the Thawte’s "Web of Trust" X.509
certificates for signing and distributing executable Jar resources.
A keytool wizard (called the Initium X.509 Certificate Wizard) was
developed in order to help with the importation and management of certificates.
A
signed Jar file generally indicates that the signer authorizes the
contents. Signing is accomplished using a certificate that has been
issued by a Certificate Authority (CA). Several CA’s are available
for this task; however, few of them are free, like the Thawte CA. Once
a free certificate is obtained, Jar files may be distributed and named
as verified from the signer. Trusted Jar files can be run outside of
the "sandbox" and thus be given improved access to the
target system.
The impact of having a trusted Jar file is that Jar distribution
systems (like Java Web Start, or Browser-based Applets) can run the
program
in the trusted manner. Therefore, such trusted programs can have access
to the files, or be able to open connections to hosts other than the
web host.
The keytool wizard addresses a subproblem of the Initium project,
a joint, on-going project between the Fairfield University and DocJava,
Inc. Initium is a Latin word that means: "at the start".
1 THE THAWTE WEB OF TRUST
In order for Java Web Start to give unrestricted permission for a
Java program to execute, it must use a "signed" Jar file.
A signed Jar file is designed to prove that the originator is the author
of the code. This does NOT prevent the author from writing harmful
code. On the other hand, if you trust the author to write non-harmful
code, you may feel safer about running the authors’ programs.
In order to sign a Jar file, you need a digital certificate. Certificates
are issued after a proper background check, by a Certification Authority
(CA). This is not generally a free service. For example, Verisign asks
for $200 or $400 per year, in order to issue a certificate.
Applications
that are signed by an untrusted signature (i.e., a signature that is
not verified by a known CA) cause a dialog to be displayed
saying:
"
It is highly recommended not to install and run this code".
The
software that I write is typically given away. As a result, I am disinclined
to pay $200-$400 per year. Therefore, a free (or at least
very cheap) approach to obtaining a certificate appeals to my sense
of thrift. The Thawte personal e-mail certificate can be used indefinitely,
and at no cost. Thawte is a CA that can issue a digital certificate
to an organization or an individual. It is the role of the CA to verify
that the company ordering the certificate is a registered organization
that controls its domain and that the person in the company, who ordered
the certificate, is authorized to do so.
Authentication helps to prevent
spoofing. It is harder to substitute illegitimate programs for programs
that come from established organizations
when the programs must be properly signed. Con artists could make
use of such untrusted programs to steal credit card numbers or create
software
that destroys or distorts data. Thus having an authentication procedure
in place helps to establish trust and adds value to the Java programs
that you distribute.
From the point of view of grid computing, a grid
operator will want some assurance that the program being submitted
for execution is safe.
At the very least, the program can be attributed to its signer before
being deployed on the grid. In the event the grid application contained
damaging code, the compute servers on the grid would become infected
with the code faster than normally propagated computer contagions.
Such a program places the entire grid as risk.
2 HOW DO I GET A CERTIFICATE?
This section presents the steps that
are needed in order to obtain a free personal e-mail certificate from
Thawte. First you must visit
https://www.thawte.com/email/index.html# , run by Thawte. You then
click on "join" and fill out the application. Information
needed includes, name, data of birth, and a "national identification
number". This can consist of a diver’s license number,
social security number or passport number. You must also enter an e-mail
address. Other information needed includes: your phone number, your
mother’s maiden name, your father’s middle name, what is
the make of your fridge, etc. Your free certificate will not show your
name when you sign your jar files. Java Web Start, for example, will
show your name as: "Thawte Freemail Member".
In order to
obtain a certificate for signing your jar, you will have to wait for
a confirmation e-mail from Thawte. This will contain the
codes that you need in order to confirm your e-mail address. Scroll
down to "Developers of New Security Applications ONLY".
Then select:
"Paste-in CSR Certificate Enrollment". Since my identity
had not been verified by Thawte’s web of trust, my name appears
as "Thawte
Freemail Member".
There are several screens that you must follow. Eventually
you will reach the screen shown in Figure 1, which contains a text box that
enables the entry
of a public key.
Figure 1. The Key Dialog Box
At this point you must generate a public
key using keytool. An RSA key can be created using the following
command:
keytool -genkey -keyalg RSA -keystore keystore -alias docjava
A public
and private key pair is created when the "-genkey" parameter
is specified. The "–keyalg" specifies the algorithm that
will be used to encode the certificate, in this case RSA. The -keystore option
specifies
the name and location of the persistent keystore file for the keystore managed
by the keytool. You will want to alter the "docjava" alias to
reflect your own domain. You will be prompted for a password. As implemented,
the password
will be echoed on the command line, so don’t type it in front of anyone
(a keytool man page details additional options). A sample session follows:
keytool
-genkey -keyalg RSA -keystore keystore -alias docjava
<
password prompt appears here, the password is echoed on the console, so do not
let anyone look over your shoulder>
The next step is to
export the key as a text file. This is done with the following command:
keytool
-certreq -keystore keystore -file keystore.txt -alias docjava
Once
the keytool.txt file is available, you must list it out to
the console and paste it into the key dialog box, shown in Figure 1.
A
confirmation
certificate request dialog will appear, unless you make an error in
the above steps.
The confirmation informs you that:\
"The certificate will have a distinguished name
that looks like this: Common: Thawte Freemail Member
Email:lyon@docjava.com
If you need a certificate with your full name in it, then you need
to join the Freemail Web of Trust."
That is, you now have a certificate
that you can use to sign files. However, the certificate identifies
you as a generic "Thawte Freemail Member".
If you want the certificate to identify you, by name, then you need
join the "Freemail
Web of Trust" membership, described in the following section.
3
FREEMAIL WEB OF TRUST
This section describes how you can get a certificate
that proves you are who you say you are (by using the best efforts
of the CA). This
enables you to
sign Jar files and have them executed by Java Web Start identifying
you as the author
and signer of the Jar file. Thus, your Jar files will be signed by
a certificate
issued by the CA, after the CA conducts a background check.
There are
two ways in which to join the WOT, the free way and the non-free way.
The free way requires that you meet with "Web of Trust" notaries.
They will require two forms of identification and will vouch that you
are who you say you are. WOT notaries may (as in my case) be spread
out over some geographic
distance. As a result, this may not be easy to do. Notaries can assign
between 10 and 35 points. Once you have accumulated 50 Trust Points
you become trusted,
and you can put your name in your personal certificate. Once you accumulate
100 points you can apply to become a WOT notary.
The second (non-free)
way to join the WOT is to obtain a "Remote Authentication" (RA).
RA requires you to meet with two trusted third parties. Examples include,
a bank manager, a practicing attorney or a CPA.
A bank manager must
be the manager of a branch of a registered banking institution. The
branch must be listed in the local telephone directory.
A practicing
attorney must be registered with the state bar association or your
countries equivalent,
and currently practice as an attorney. The attorney's law offices
must be listed in the local telephone directory. A CPA must be licensed
as a certified
public
accountant, with the relevant state or country authorities, and must
be practicing as a CPA from an office that is listed as such in the
local telephone directory.
There is a $25 fee for using RA and, once
authorized, you become a notary yourself. I elected to pay the fee
and went to two different
notaries
at two different
local banks. As I had accounts there, they did not charge for the
service
of notarizing the Thawte forms.
The first time I made out the paperwork
there was some sort of clerical error, which I still do not understand.
As a result, I
sent over
16 e-mails over
a 4-week period. It was claimed that the notarized forms were
not signed (which
is impossible,
since they were notarized). In response, I went and had the forms
filled out and notarized again. The second attempt worked, and
soon I had
the coveted e-mail confirming that I had been notarized through
the Thawte
Remote Authentication
System. 4 GETTING YOUR NEW CERTIFICATE
In order to get a new certificate
(one that verifies that you are who you say you are) proceed to the
Thawte web site https://www.thawte.com/cgi/personal/cert/enroll.exe
and login. Select the link labeled "Developers of New Security
Applications ONLY". Then select:
Paste-in CSR Certificate Enrollment".
To begin the process,
I list the certificates loaded into my default keystore:
keytool -list
Enter keystore password:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 2 entries
docjava, Apr 14, 2004, keyEntry,
Certificate fingerprint (MD5): C0:67:B8:72:2D:DA:A3:7F:4B:A1:F0:D2:A6:24:2D:DD
mycert, Apr 20, 2004, keyEntry,
Certificate fingerprint (MD5): CD:C1:A7:AB:3E:CA:5B:4D:B0:CA:BB:DF:66:61:73:83
The
default keystore type is "jks" (the proprietary type
of the keystore implementation provided by Sun). I then proceed to
print information about my new Thawte x.509 certificate:
keytool -printcert
-file deliver.exe
This outputs a chain of certificate data that, upon
inspection, looks correct and trustworthy. Now I shall generate a public
key using keytool.
This is the same procedure as outlined in Section 1, except that now
I am a confirmed Thawte notary:
Now to get my certificate:
keytool -certreq -file keystore.txt -alias
docjavaInc
Here is the output from the certificate request:
ls
deliver.exe keystore.txt
cube.local{lyon}76: more *.txt
-----BEGIN NEW CERTIFICATE REQUEST-----
JLMEF (Junky Looking MIME Encoded Flotsam)
-----END NEW CERTIFICATE REQUEST-----
I then paste in the key tool output
into the key dialog box, as shown in Figure 1. A confirmation dialog
appears that says:
The certificate will have a distinguished name that
looks like this:
Surname:lyon
Given Names:Douglas
Common:Douglas lyon
Email:lyon@docjava.com
Compare the above output with that from Section
2:
"The certificate will have a distinguished name
that looks like this: Common: Thawte Freemail Member
Email:lyon@docjava.com
If you need a certificate with your full name
in it, then you need to join the Freemail Web of Trust."
So far, so good. Now I proceed to my Thawte
accounts’ certificate manager
page, at: https://www.thawte.com/cgi/personal/cert/status.exe and check
the status of my X509 certificate request. After a few minutes, it changes
status
from pending to issued and I fetch my new X.509 certificate. The delivered
certificate contents follows:
more deliver.exe
We deliver your developer cert as a chain, and we
deliver it in two formats. The first is the Netscape Cert Sequence
format, documented
on the Netscape Security Site at http://www.netscape.com/eng/security/.
The next is a degenerate PKCS7 SignedDate, with certificates and
possibly CRL's but no content.
-----BEGIN NETSCAPE CERTIFICATE CHAIN-----
MIII6wYJYIZIAYb4QgIFoIII3DCCCNgwggJgMIIByaADAgECAgMMzA0wDQYJKoZI
hvcNAQEEBQAw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx
0aW5nIChQdHkpIEx0ZC4xLDAq
In order to import the certificate into the
key store, the PKCS7 part of the certificate must be saved into a
file and then altered so that
it looks like the following:
-----BEGIN PKCS #7 SIGNED DATA-----
MIII7AYJKoZIhvcNAQcCoIII3TCCCNkCAQExADALBgkqhkiG9w0BBwGgggjBMIICSTCCAbKgAwIB
AgIDDB2VMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u
That
is, there must be 76 characters, per line. Thus, the carriage returns
were inserted improperly. To extract the PKCS7 key, you can
hand-edit the file, then fix the returns. As an alternative, I have
written a small Java procedure called cleanThawtes. The cleanThawtes
procedure automates the processing of certificates returned by Thawte.
It is based on the work of Richard Dallaway [Dallaway]. As a part of
the Initium keywizard, cleanThawtes was wrappered with a GUI and placed
on the web under Web Start Applications, available at: http://www.docjava.com/.
I used the program to create a file called pk8.cert. This was imported
into the default location for the keystore file using:
keytool -import
-file pk8.cert -alias docjavainc –trustcacerts
Errors in the
parameters passed to the keytool command result in cryptic
exceptions. For example:
keytool -import -file pk8.cert -trustcacerts
Enter keystore password:
keytool error: java.lang.Exception: Input
not an X.509 certificate
5 WHERE HAVE ALL THE KEYS GONE?
The default location for the keystore
file is .keystore and is located in the users’ home directory.
In order to obtain this file, a public method was created in a new
class called
the KeyUtils:
To import a PKCS7 certificate, after it has been properly formatted, I have
added the following code to KeyUtils:
In order to deal
with the case of an improperly formatted certificate, I have created a more
sophisticated way to get certificates, one that
invokes the
Thawte cleaner:
After adding more error correction prompts, we are able to run the Initium
key wizard under a series of different situations. For example, when
no .keystore file appears in the users’ home, the program will
prompt you for a key store file. If you don’t have one, the program will
offer to make one for you, adding a self-signed certificate. The program will
also offer
to create
a certificate request file, which can be used to obtain a trusted certificate.
This simplifies key management.
6 RELATED WORK
The creation of key tool API’s is not new [BouncyCastle].
Verisign has an API, but it is no longer supported, as far as I can tell
[Verisign]. The
interesting thing about the Verisign API is that it enables users
to revoke public keys at the CA (which is an excellent idea). This is something
that
would enable the automation of Thawte interactions and is a topic
of
future work.
There have been articles on the signing of Java Web Start applications
[Dallaway]. There have also been articles on the signing of Applets
[Gallant].
The creation of a key wizard seems like a logical evolution
of the key tool. It is surprising, therefore, that keytool wizards are so
few and far between. A reason for this is that Sun has not open-sourced the JKS (Java
Key Store) API. On the other hand, there are open-source versions of a JKS system
[Marshall]. I have yet to test this system.
One notable keytool
wizard is the BEA systems wizard for their Weblogic product [BEA]. This systems
is closed-source, expensive and only
works on Weblogic. 7 CONCLUSION
Basic elements of key management need to be automated in support
of the automation of Java Web Start application deployment. In
fact, it is the Initium project that provided the primary motivation for creating the key wizard.
The automation of key tool functions is not hard, give proper error handling
and GUI implementation effort. One of the surprising elements
is that
the API upon which the key tool is based is neither public, nor
open-sourced. What
this means to the key wizard author is that a substantial implementation
library has to be created, tested and documented in order to
provide the key tool function points.
Even more disconcerting is the general lack of programmatic
support for the retrieval of trusted certificates. After a certificate request is
created, the user must still interact with a CA in order to go through a process of
getting a certificate. This limitation is less a technical
one than a security one.
For those in organizations where there may be multiple
employees (or students) who want to sign applications, obtaining certificates
using remote authentication is cumbersome, at best. In such cases, several notaries could
be established so that students/employees can be issued certificates quickly and at
little additional cost.
REFERENCES
[Bea] "The Bea Systems Keytool Wizard" http://edocs.bea.com/wli/docs70/b2bsecur/keystore.htm
[BouncyCastle] http://www.bouncycastle.org/specifications.html,
An open-source API that provides JCE features.
[Dallaway] Richard Dallaway, "Java Web Start and Code Signing",
May 2002 http://www.dallaway.com/acad/webstart/
[Gallant] Michel I. Gallant, "Thawte Code Signing Certs with Authenticode,
Netscape and Sun Signing", http://www.jensign.com/JavaScience/Thawte/
[Marshall] Casey Marshall, "An implementation of the JKS key
store", http://metastatic.org/source/JKS.html
[Versign] "Trust Services Integration Kit 1.7" http://home.postech.ac.kr/~chokee/cs499/tsik-1.7/tsik-1.7/api/com/verisign/xkms/tools/XKMSKeyStore.html,
and http://www.verisign.com/static/005314.pdf
APPENDIX - The KeyUtils API
The general lack of high-level tools for performing key tool functions has led to
the creation of the following API for key and certificate manipulations.
About the author
|
 |
After receiving his Ph.D. from Rensselaer
Polytechnic Institute, Dr. Lyon worked at AT&T Bell Laboratories.
He has also worked for the Jet Propulsion Laboratory at the California
Institute of Technology. He is currently the Chairman of the Computer
Engineering Department at Fairfield University, a senior member
of the IEEE and President of DocJava, Inc., a consulting firm in
Connecticut. E-mail Dr. Lyon at Lyon@DocJava.com.
His website is http://www.DocJava.com. |
Cite this column as follows: Douglas Lyon: "The Initium X.509
Certificate Wizard", in Journal of Object Technology,
vol. 3, no. 10, November-December 2004, pp. 75-88. http://www.jot.fm/issues/issue_2004_11/column6
|
