Product Overview

ProtectToolkit-J is a Cryptographic Service Provider for the Java Cryptographic Architecture (JCA) / Java Cryptographic Extension (JCE) interface. ProtectToolkit-J implements a number of cryptographic algorithms that are supported by SafeNet’s hardware encryption devices. These devices support encryption, signature generation and verification, message digests, key storage and message authentication. ProtectToolkit-J also includes a clean-room implementation of the JCA/JCE framework, allowing for immediate use with Java 6.x/7.x/8.x/9.x/10.x/11.x.

This document assumes some knowledge of the Java programming language, the JCA/JCE application programming interfaces, and some understanding of the underlying adapter interface, which is based on PKCS#11 (Cryptoki). See About the ProtectToolkit-C Administration Guide for more information on Cryptoki. For general information on the JCA/JCE, consult:

>JCA/JCE API Overview

>JCA/JCE API Tutorial

>JCA reference material found at http://docs.oracle.com/

This document does not discuss the security properties of the various algorithms in general; please consult the standard cryptography texts for this information.

ProtectToolkit-J is known to the JCA/JCE by the provider name SAFENET. To request an algorithm implemented by this provider, the string "SAFENET" should be passed to the getInstance()method.

ProtectToolkit-J is SafeNet’s Java Cryptographic Architecture (JCA) / Java Cryptographic Extension (JCE) provider. It allows Cryptographic processing using the Java development language. It requires that ProtectToolkit-C Runtime and an appropriate access provider are installed.

The ProtectToolkit-C Runtime package is needed to perform Cryptoki (PKCS#11) processing. The ProtectToolkit-C hardware runtime needs an access provider. There are two access provider install packages in order to operate the runtime in a local PCIe bus or network attached remote server arrangement.

The ProtectToolkit-C Software Development Kit (SDK) is needed to develop applications using PKCS#11 processing. The ProtectToolkit-C SDK includes the ProtectToolkit-C runtime as well as a software emulation that does not require any access providers.

Refer to ProtectToolkit Software Installation for instructions on how to install this SDK.


Hardware

The hardware version of ProtectToolkit-C requires a ProtectServer HSM.

Refer to About the ProtectServer HSM and ProtectToolkit Installation Guide for instructions on how to install the adapter and the runtime or SDK package.

Software

The software-only version of ProtectToolkit-C requires a compatible PC, and would primarily be used in a development or testing environment.

Refer to ProtectToolkit Software Installation for instructions on how to install the software-only version of the SDK package.

Remote Client/Server

This version of ProtectToolkit-C requires a TCP/IP network with one or more machines and a server. ProtectToolkit-C processing is performed by the server at the request of the client. The server must be running the runtime package or the hardware version of the SDK package.

Working With Slots

ProtectToolkit-J is capable of interfacing to multiple adapters. This is achieved by using different “virtual providers” which map to each adapter. The virtual providers are named SAFENET.n, where n is the slot number as configured with the ProtectToolkit-C runtime tools. The special provider SAFENET always maps to the first slot.

A provider class exists (SAFENETProvider) for each of the slots in the package au.com.safenet.crypto.provider.slot<n>. These providers may be statically installed. Alternatively, they may be added dynamically by calling the SAFENETProvider.addProviders()method.

Resource Management

Resource management is an important consideration when using the SafeNet provider. In general, creation of a provider instance (a Cipher object or Key object, for example) consumes resources within the adapter. This consumption is less than that of the main JVM and so the garbage collection is not tuned to its needs. The application programmer must therefore manage collection.

Two main techniques may be employed:

>Explicitly track resource usage, invoking garbage collector on certain thresholds. For example, after the creation of 100 “session” Key objects, which are only required for a short transaction and then discarded, it may be necessary to run the garbage collector to clean up those unused instances.

>The second technique requires some tuning of the Cryptoki configuration on the adapter. If ProtectToolkit-J cannot create a new “session” with the adapter it invokes the garbage collection (in the hope that there are some old unused sessions awaiting cleanup). By reducing the maximum number of sessions allowed by the adapter, the adapter may be tuned to the application's requirements so that explicit resource management is not required.

The Software

The latest versions of the client software and HSM firmware can be found on the Thales Technical Support Customer Portal. See Support Contacts for more information. The following ProtectToolkit-J packages can be found in the installation package:

Package Windows UNIX

ProtectToolkit-J Runtime

PTKjprt.msi

PTKjprov

ProtectToolkit-J SDK

PTKjpsdk.msi

PTKjpsdk

The ProtectToolkit-J Runtime includes the necessary shared libraries required to interface to the ProtectToolkit-C Runtime, as well as the Java class libraries that implement the JCE specification and the ProtectToolkit-J provider.

For instructions on ProtectToolkit-C Runtime installation and ProtectToolkit 5.9.1 system requirements, please refer to ProtectToolkit Software Installation.

The ProtectToolkit-J SDK is provided as a software development platform.

NOTE   If you will be using larger key sizes or non-FIPS algorithms, install the JCE Unlimited Strength Jurisdiction Policy Files patch. They are available for download on the Oracle website (http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html).