Best practice guidelines

The purpose of this section is to outline some of the best practices application developers can use when developing their ProtectToolkit-J based applications.

The following guidelines do not attempt to replace the vast body of literature regarding building secure systems or implementing cryptography for security. Rather it focuses on some of the specific aspects of the ProtectToolkit-J product that are particularly relevant to building applications in a timely and reliable way.

ProtectToolkit-J provider

The ProtectToolkit-J JCA/JCE Provider provides access to the many cryptographic features of the ProtectServer range of hardware.

As the provider is hardware-based, there are a number of differences between it and other software-based implementations. Mostly, these stem from the different methods used to protect the key store, where hardware can effectively provide some level of physical protection.

Key protection

Usage

Each key has an associated set of usage flags that indicate which cryptographic operations can be performed with the key. For example, specific flags can be set to enable encryption or signature generation. Keys in the ProtectToolkit-J provider will adhere to these rules.

Value

Normally, keys protected by the hardware will not allow their values to be revealed outside the adapter. Thus, the Key.getEncoded() interface will generally return a null value.

General ProtectToolkit-J usage guidelines

• Create persistent keys with the Key Management Utility (KMU) and specify their key usage attributes appropriately.

  • secret and private keys should always be sensitive

  • each key should be usable for only one purpose

  • use the KMU for key backups with the exportable attribute

• Persistent key instances from the ProtectToolkit-J KeyStore implementation are shareable. This means a key lookup only needs to be performed once, rather than every time a key is required.

• Initialize the token correctly. Different applications should use different tokens.

• Install the ProtectToolkit-J provider as the highest priority, or use Security.insertProvider(SAFENETProvider() early on in your application. This will ensure that the SAFENET hardware SecureRandom will become the system default, providing improved quality random data and avoiding the startup performance penalty of the Sun implementation.

• Fully specify Cipher transformations. For example, use "DES/ECB/NoPadding" instead of "DES".