Product Overview
SafeNet ProtectToolkit-J is a Cryptographic Service Provider for the Java Cryptographic Architecture (JCA) / Java Cryptographic Extension (JCE) interface. SafeNet 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. SafeNet ProtectToolkit-J also includes a clean-room implementation of the JCA/JCE framework, allowing for immediate use with Java 6.x, 7.x, and 8.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). Refer to the SafeNet ProtectToolkit-C Administration Manual for more information on Cryptoki. For general information on the JCA/JCE, consult:
>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.
SafeNet 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.
|
SafeNet 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 SafeNet ProtectToolkit-C Runtime and an appropriate Access Provider are installed. |
|||
|
The SafeNet ProtectToolkit-C Runtime package is needed to perform Cryptoki (PKCS#11) processing. The SafeNet 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 SafeNet ProtectToolkit-C Software Development Kit (SDK) is provided to develop applications using PKCS#11 processing. Refer to the SafeNet ProtectToolkit-C Administration Guide for instructions on how to install this SDK. The SafeNet ProtectToolkit-C SDK includes the SafeNet ProtectToolkit-C Runtime as well as a Software Emulation that does not require any Access Providers. |
||
|
|
|||
| Hardware
The hardware version of SafeNet ProtectToolkit-C requires a SafeNet ProtectServer HSM. Refer to the Installation Manuals for instructions on how to install the adapter and the SafeNet ProtectToolkit-C Administration Guide for how to install the Runtime or SDK package. |
Software
The software-only version of SafeNet ProtectToolkit-C requires a compatible PC, and would primarily be used in a development or testing environment. Refer to the SafeNet ProtectToolkit-C Administration Guide for instructions on how to install the software-only version of the SDK package. |
Remote Client/Server
This version of SafeNet ProtectToolkit-C requires a TCP/IP network with one or more workstations and a server. SafeNet 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
SafeNet 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 SafeNet 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 SafeNet 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.
