Level: Intermediate Peter Horner, Advisory Software Engineer, IBM
Rebecca Liong, Associate Software Engineer, IBM
14 Sep 2007 Secure web communication has become essential for e-commerce,
business-to-business solutions and enterprise applications.
Typically, SSL is used to secure communications in a secure web environment,
but SSL has a performance cost associated.
This article highlights the benefits of using cryptographic hardware for cryptographic
acceleration within a Tivoli Access Manager for e-Business® WebSEAL environment.
The different deployment architectures available for hardware devices are discussed. It
steps through the configuration needed to configure an nCipher netHSM network hardware
security module in WebSEAL® through the Global Security Kit (GSKit) on Solaris.
Objectives
- Understand the benefits of using a cryptographic hardware device in a
Tivoli Access Manager for e-Business(TAMeB)
environment
- Configure WebSEAL to use the nCipher network hardware security
module(netHSM) and verify installation
Introduction: Simplified SSL Overview
SSL (Secure Sockets Layer) is a protocol for sending data securely over a network connection.
A SSL session begins with a negotiation (handshake) process that
involves the server sending its public key to the client, and then sending information to the
client encrypted with its private key. This information can only be decrypted using the public key previously sent.
These operations are known as asymmetric encryption and decryption, since the keys used to encrypt and decrypt are different.
Asymmetric operations are very CPU intensive. Both ends then agree on a symmetric encryption algorithm and a key which is sent over this secure channel.
From then on all data that is sent is encrypted using this key. A SSL session can be resumed
while both client and server maintain the session ID. Otherwise, new session parameters will
have to be negotiated.
Relative cost of SSL cryptographic operations
Asymmetric key operations (During the handshake)
- The amount of data being encrypted is small.
- The processing cost of asymmetric encryption is high.
- So the potential benefit in offloading the processing is high.
Symmetric key operations (After the handshake)
- The amount of data being encrypted is large.
- The processing cost of symmetric cryptographic operations is low.
- So the potential benefit of offloading the processing is less pronounced, as the overhead in sending the data to and from the hardware
can become significant.
Hardware Security Modules
Hardware Security Modules typically provide one or more of the following
- Secure tamper resistant Key/Certificate Storage.
- Symmetric key functions
- Asymmetric key functions
- Ability to be shared by multiple machines
- Hash functions
- Random Number generation
- Asymmetric Key generation
WebSEAL supports access to hardware security modules through the PKCS#11
interface standard.
For a list of PKCS#11 cryptographic hardware that GSKit supports, please refer to [2] in the reference list.
Please note that WebSEAL only provides access to a subset of the PKCS#11 functions by GSKit.
WebSEAL's use of PKCS#11 functions provided by GSKit is limited to
- Asymmetric key generation and secure storage
- Certificate storage
- Asymmetric key operations (Sign & Verify, and Decryption during SSL key-exchange)
- Symmetric key operations
Cryptographic hardware selection
There are several types of cryptographic hardware available.
One choice to be made is whether to use network or server-side devices.
Server-side
devices are installed on the server itself and include accelerator PCI cards. Network devices
are stand-alone, such as a hardware security module appliance, and can be shared among several
servers. Depending on the manufacturer, both server-side and network devices can support
clustering.
It is worthwhile to check how a candidate network device communicates
with its clients. You should ensure that the network device uses secure
communication with the server.
Administrators have to consider the cost of managing
certificates relating to purchase, storage and renewal for example. In a small site,
rather than each server
having their individual digital certificate on PCI accelerator cards, the accelerator cards
could be substituted with a shared stand-alone appliance, which may help by providing a central
location for certificate administration.
The software interface differs between cryptographic hardware. A
common standard is PKCS#11. Therefore it is important
to consider the interface requirements of application software, as well as specific
functionality needed as discussed above(eg. key storage).
Whether network or server-side devices are used, they appear the same from WebSEAL's (and GSKit's) perspective.
Finally, device selection would also be influenced by the SSL transaction throughput requirement.
The common cryptographic hardware measure is the number of transactions per second(TPS).
SSL in a TAMeB environment
This section describes where SSL is relevant in an example
TAMeB environment.
Figure 1 shows a typical TAMeb system deployment, including the servers
involved, and connections between them.
Figure 1. Example
TAMeb environment
All the SSL connections in the above diagram can potentially benefit from the use of cryptographic hardware.
The greatest benefit can be gained by using a hardware security module at
the front end, to offload WebSEAL's asymmetric cryptographic load when a client browser
connects via HTTPS.
At the backend, there are fewer independent negotiations, since multiplexing is used in the SSL
layer to re-use SSL keys.
Symmetric cryptography operations are not usually offloaded, and if they are, can actually
degrade performance.
This article focuses on using cryptographic hardware for SSL communication at the 'front-end' between
WebSEAL and client browser using the PKCS#11 interface to the nCipher netHSM.
The remainder of the article describes how to configure WebSEAL to use a nCipher hardware security module through GSKit,
and how to verify correct installation.
Setup the test environment
Default installations were carried out for the following.
Install registry server and policy server
The LDAP Registry Server and Policy Server from Tivoli
Access Manager e-Business v6.0 are installed and configured using the
provided wizards. Refer to the TAM Installation Guide. For this
article, defaults were kept during installation.
Install WebSEAL
WebSEAL 6.0 is installed using the install_amweb wizard on the same machine
as the HTTP server(refer to [1]). GSKit 7 comes with this version
of WebSEAL. Fixpack 5 for WebSEAL was also installed.
Enable SSL between WebSEAL and client browser
Obtain a certificate
Typically in real-world applications, a digital certificate would be
requested and received from a trusted certificate authority(CA). For test purposes the default
certificate provided with the WebSEAL installation, called WebSEAL-Test-Only, can be used.
Alternatively generate a self-signed certificate.
Use GSKit iKeyman to create a new key database and generate a self-signed
certificate for testing. Refer to Managing Digital Certificates with iKeyman in [3].
Using iKeyman, import the certificate to the WebSEAL certificate database called
/opt/pdweb/default/certs/pdsrv.kdb as a signer certificate. See [3] for instructions. The
default password for pdsrv.kdb is pdsrv. This signer certificate is later added to the netHSM.
Verify that SSL is working without Cryptographic Hardware
Create a test user for WebSEAL in pdadmin if necessary. On the command prompt
- Log into pdadmin:
pdadmin -a <AdminName> -p <password>
- For our default install:
pdadmin -a sec_master -p passw0rd
-
pdadmin> user create testuser password passw0rd
- Set user account to be valid:
pdadmin> user modify
testuser account-valid yes
Verify that SSL was set up correctly by accessing WebSEAL's default web page such as https://servername.domain.com/index.html. The client browser should ask if the user wants to trust the server. The certificate is viewable by, for example, clicking View Certificate in the pop-up box in Internet Explorer 6. Check that the expected certificate is presented. If the user logs in successfully, he is able to view the web page.
Configuring WebSEAL for Cryptographic Hardware in Key Management and Acceleration Mode
WebSEAL will be configured to communicate with the nCipher netHSM device via
PKCS#11. The procedure to use the netHSM device can be grouped into server-side and client-side setup.
Where nCipher is concerned, this document assumes that there is a netHSM device running, with
its security world and remote file system at the point where clients can be configured to use
it. Please refer to the nCipher netHSM Administration Guide for Solaris for more detail.
This guide comes on a CD with the netHSM.
Install nCipher netHSM client software on the WebSEAL machine
An nCipher hardserver has to be installed on each client of the netHSM. The client in this case is the WebSEAL machine. The following is an extract from the nCipher Key Loading Solution Guide.
"On netHSM modules, the hardserver software controls communication
between the internal hardware security module and applications on the network."
Refer to the nCipher Administrator Guide for Solaris which
describes preparing the client. The following instructions are an adaptation.
- Insert Disc 1 of the CipherTools Development Kit(Release 10.50) for Solaris in the WebSEAL machine. Any existing nCipher installation on the computer should be removed first. Ensure that there is no nCipher server running by giving the command:
/opt/nfast/sbin/init.d-nfast stop. Note that the command does not exist if nCipher software has not been installed.
- Install the nCipher hardserver using
/usr/sbin/pkgadd -d /cdrom/cd-name/solaris/2_7/nfast/nfast.pkg. Enter the
comma-separated list of package numbers for
Core Tools, PKCS#11 Library and Hardware Support.
- Run the server installation script:
/opt/nfast/sbin/install
- After the software is installed, the client must be configured to
work with the netHSM, beginning with configuration of the Ethernet interface(page 57 of
nCipher Administrator Guide for Solaris). The netHSM should have already been configured
to listen on the appropriate interfaces by its Administrator as per page 56 of the nCipher Administrator Guide for Solaris.
netHSM server-side configuration
These steps have to be performed by the netHSM Administrator.
Set up client cooperation
This has to be done, particularly when multiple clients require access
to the remote file system. Refer to Setting up client cooperation in page 63 of
the nCipthe Administrator Guide for Solaris.
Register the client
machine
Refer to Configuring the client and module to work together on
page 84 of the nCipher Administrator Guide for Solaris. It involves adding the IP
address of the client(in this case that of the
WebSEAL machine) to the netHSM. An Unprivileged Connection type should be sufficient.
Token creation
A token device label and password must be created to store the WebSEAL
public/private key pair.
Configuration
on the netHSM's client (WebSEAL machine)
Information required from the netHSM Administrator before
proceeding:
- netHSM device IP address
- netHSM's remote file system IP address
- Token label and password to store WebSEAL keys
On the WebSEAL machine, give the following command: /opt/nfast/bin/nethsmenroll -f -V mmm.mmm.mmm.mmm
mmm.mmm.mmm.mmm
is the IP address of the netHSM device.
Give the following command to enable TCP sockets for Java and KeySafe:
config-serverstartup -sp
Restart the hardserver by entering /opt/nfast/sbin/init-d_nfast stop and
/opt/nfast/sbin/init-d_nfast start
Download security world data to the client:
rfs-sync -setup -no-authenticate rfs.rfs.rfs.rfs
, where rfs.rfs.rfs.rfs
is the IP address of the machine where the remote file system is located. Then run rfs-sync -update
You can check that the WebSEAL machine is successfully communicating with the netHSM device by entering:
/opt/nfast/bin/enquiry. You should get output which includes server
and module details.
You can also run /opt/nfast/bin/ckcheckinst.
All tests should pass. Choose the slot number with the operator card for testing(not the
accelerator).
Enter the passphrase for the token when prompted. These PKCS#11 tests should run
successfully.
Configure iKeyman to use the nCipher PKCS#11 shared library
- Locate the file ikmuser.sample in /opt/ibm/gsk7/classes.
- Copy and rename this file to ikmuser.properties.
- Edit this new file by adding the following line that specifies the location of the module (shared library) for the netHSM device:
DEFAULT_CRYPTOGRAPHIC_MODULE=/opt/nfast/toolkits/pkcs11/libcknfast.so
- The GSKit iKeyman utility needs to be configured
for the PKCS#11 device module (shared library) of the installed nCipher hardware device.
This module allows iKeyman to understand the hardware device's WebSEAL token label
, the password (or PIN) for the token, and the key label of any WebSEAL key stored on the device.
Create the self-signed certificate on the netHSM
Before doing the steps in this section, your netHSM Administrator
should have already created a token in the hardware.
An operator smartcard must be inserted in the netHSM device before you can create certificates on it.
Use iKeyman to open libknfast.so
- Start iKeyman
- Go to the menu, Key database>Open
- Select the Key Database Type as CMS Cryptographic Token from the dropdown menu.
Browse to
/opt/nfast/toolkits/pkcs11/32/libcknfast.so.
- In the Cryptographic token label dropdown menu, select the name of the token
created by the netHSM Administrator for this purpose, for example hsm2000,
and not accelerator.
- Enter the token's password. Clear both check
boxes. Click OK. The token should open up and will show any certificates already present.
- Create a self-signed certificate for testing by clicking
New Self-Signed. Fill out the form with appropriate information.
Remember what Key Label is given, as this will need to be entered in the
WebSEAL configuration file shown later.
Configure WebSEAL to
use PKCS#11 device shared library
Edit the webseald.conf configuration file. It may be found in
/opt/pdweb/etc/webseald-<host-and-instance
-name>.conf.
Add the library location of the shared library under the [ssl]
stanza. WebSEAL also has to be configured to use the new hardware-based
key rather than its default key in its communications with client browsers.
Hence the server certificate label is also modified.
Listing1. Changes to webseald.conf
webseal-cert-keyfile-label=<token-name>:<key-label>
pkcs11-driver-path =/opt/nfast/toolkits/pkcs11/32/libcknfast.so
pkcs11-token-label =<token-name>
pkcs11-token-pwd =<password>
disable-ncipher-bsafe=yes
|
Token-name is the name for the token created on the netHSM for
this purpose. Key-label would be the name of the self-signed certificate in the token
created previously. Restart WebSEAL for the settings to take effect using pd_start restart.
Verify that WebSEAL is
using the netHSM device
Test that the certificate stored on netHSM is successful accessed by
WebSEAL on https request from client. Try to access
a WebSEAL protected web page (eg. https://server.domain.com/index.html) using a browser. Log
in as testuser (created earlier) when prompted by WebSEAL. Click "View
Certificate" when dialogue box pops up in
the browser, and verify that its details match those of the self-signed certificate created on
the netHSM.
Conclusion
This article has described some of the benefits of using a
cryptographic hardware device in the Tivoli Access manager for e-Business environment.
Cryptographic hardware choices were discussed. It
has provided the configuration steps for WebSEAL to use a nCipher netHSM, and verify successful
installation.
Resources Learn
Discuss
About the authors  | 
| | Peter Horner is an Advisory Software Engineer in the Australia Development Laboratory. |
| 
| | Rebecca Liong BEng(CompSysEng)(Hons) is an Associate Software Engineer in the Australia Development Laboratory. |
Rate this page
| 
