Using a Cryptographic Hardware Token with Linux: the OpenSSL Project's New Engin

In past Linux Journal articles (in the January and February 2001 issues), Mick Bauer presented an overview of the OpenSSH project and its efforts to build upon the Secure Shell protocols. In this article, I discuss our experience of integrating a hardware cryptographic token under Linux, using another open-source project known as OpenSSL.

Public Key Infrastructure (PKI) is a
critical technology in today's computer oriented world. Without it
there would be no secure e-commerce transactions or secure
connections. Remember the days when clear-text passwords regularly
flew across the Net? That's history now due to the increasing
diligence of "bad people" sniffing the Net, looking for potential
security loopholes to exploit. These days, paranoia is the normal
state for computer security, and PKI plays a role in helping to
ease that paranoia.

PKI provides a high level of protection by allowing the
signing of e-mails, encryption of sockets and other cryptographic
functions. A large standards base has evolved around PKI, and the
open-source domain has taken on the task of implementing those
standards to a high degree. PKI is based on the now well known
public/private key-pair interaction. In this interaction a
public/private key-pair is generated, and the public-key is used by
external entities to verify data signed or encrypted by the private
key. The private-key is held securely by the owner. The key can be
held secure by a passphrase on either an encrypted file or a
hardware token.

Another important component of PKI is a certificate (X.509
format), a document that is signed by a known authority (known as a
certificate authority or CA) and says the originator of the
public-key is who they really say they are. In order to obtain a
valid certificate, the key-pair owner must sign a certificate
request using their private-key and send it to the CA. The
certificate request provides the certificate authority with
information about the owner of the key and a copy of the
public-key.

Integrating a Token

With this background, I can start explaining our adventure
with PKI. A client wanted to provide digitally signed e-mails for
critical data originating from a Linux PC. The critical data had to
arrive at a site and be assured that it originated from a given
Linux PC. The client needed to perform this task using S/MIME, a
standard designed for this purpose (see glossary). The client also
wanted to use a hardware cryptographic token for security reasons.
Hardware tokens are nearly tamper proof and assure that the data
are originating from a given Linux PC provided that the token is
plugged into it. Tamper switches on the PC and the token prevented
either from being moved without authorities' knowledge.

Since my company prefers to start with open source tools,
rather than dive into proprietary libraries or write new code from
the "ground up", we quickly discovered the OpenSSL project. The
OpenSSL project supported almost all of the necessary components
needed to complete our client's project. I say almost all,
otherwise our story would have ended here and proven rather boring.
The client required the ability to store a 1,024-bit DSA
private-key on a specific PCMCIA-based hardware token, generate a
certificate request and then, using the certificate and the
private-key, clear sign an e-mail using the S/MIME format.

As luck would have it, back in September 2000, the OpenSSL
project released version 0.9.6 and a parallel release that included
an engine component. The engine component caught our eye because it
dealt with using cryptographic hardware tokens. Sadly, the token we
were requested to integrate, the Chrysalis-ITS Luna2 PC card, was
not on the list of the three tokens implemented in the engine. This
forced us to go under the hood of the OpenSSL engine code.

Chrysalis-ITS provided our client with the libraries needed
to interact with their token under both Solaris and Linux and the
OpenSSL code-base compiles for both. Chrysalis-ITS's Luna2 toolkit
library is based on the PKCS#11 standard that is documented by RSA
Laboratories. The PKCS#11 is a C/C++ programming standard library
for using a cryptographic hardware token with public-key
technology. A quick e-mail to the author of the OpenSSL engine
component, Geoff Thorpe, confirmed that it would be possible to use
a PKCS#11 library with the way the engine was designed.
Unfortunately, none of the other 3 cards implemented in the engine
were using this standard library (they all had proprietary
libraries), so we had to develop an engine implementation without
any example code.

Actually, it is not true that we didn't have any example code
to work with; we had access to the implementations for the other
three hardware tokens. We also had done some work with the PKCS#11
library for the Luna2 token. However, each of these other hardware
tokens used RSA (see glossary) and not DSA as the cryptographic
mechanism. It seems RSA is the more prevalent method because it is
a stronger cryptographic mechanism than DSA. One step forward with
an example, but two steps backward since none implemented DSA.
However, the CryptoSwift token implementation in OpenSSL, by Geoff
Thorpe, did provide a DSA acceleration, so this was the best
starting point to implement a solution for the Luna2.

It's interesting to watch different people's approaches to
integrating systems. Some like to sit down and spend time reading
manuals, and others like to dive in and get into the guts. I am one
of the latter types. Rather than rely on reading volumes of manuals
to understand how something is glued together, I prefer to run
through the code with a debugger
(ups is my particular favorite
open source debugger). That way I can step in and out of all the
functions, look at structures and see all the details being passed
around. Once I get a handle on how it all glues together, I proceed
to the manuals to get more specifics on code not presented clearly.
While the OpenSSL project is doing a great job, some of the
documentation on the cryptographic library (libcrypto) is a bit
sparse. After testing the command line OpenSSL interface by running
all of the tasks, without using the engine (using only text files
holding the keys), I had a pretty good understanding of the way it
was pieced together.

I next implemented the necessary engine structures for the
token and tied the PKCS#11 calls to the appropriate functions. The
only conversions necessary were the data types from the native
PKCS#11 data into the OpenSSL values. The tricky part was binding
all of the necessary PKCS#11 function calls dynamically at run time
to the OpenSSL engine.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.