Conceptual description

Authentication Suite Server SDK facilitates the validation of passwords and signatures from Digipass authenticators that are programmed with the Digipass Sequencer or Digipass Programmer. For this purpose, Authentication Suite Server SDK has to store a copy of the parameters and secrets that were programmed in the Digipass authenticator. Authentication Suite Server SDK stores this information in the authenticator application BLOB, which is a flat data structure stored in a database that is accessible from the computer where Authentication Suite Server SDK is running.

To prevent unauthorized access and fraud, the authenticator application BLOB is protected (privacy and integrity) through a 3DES-based encryption. The standard version of Authentication Suite Server SDK is a full software product; the 3DES keys, named Authentication Suite Server SDK Software Storage Keys, that are used for this encryption are based upon secret codes stored in the software and secret codes passed during runtime.

In case a higher level of security is required, it is possible to migrate to the Authentication Suite Server SDK for ICSF solution. ICSF, or Integrated Cryptographic Service Facility, is the z/OS solution to the HSM paradigm. A hardware security module (HSM) is a tamper-proof hardware module that is connected to, or inserted into, the host computer. The HSM contains a secure storage for HSM Storage Keys in combination with cryptographic processing capabilities. The Authentication Suite Server SDK for ICSF solution uses 3DES or AES HSM keys to encrypt the authenticator application BLOBs.

HSM access architecture

Figure: Architecture of Authentication Suite Server SDK for ICSF API

The Authentication Suite Server SDK for ICSF API is different from the API of the Authentication Suite Server SDK standard version. In the standard version, the sensitive data contained inside the BLOB is encrypted with a software storage key. With Authentication Suite Server SDK for ICSF, the sensitive data is encrypted by an HSM storage key.

The HSM storage key has to be a data encryption key. OneSpan advises to use a double-length 3DES, a triple length 3DES, an AES-128bit, or an AES-256bit key, and to store it in the CKDS.

When you use AES-128 or AES-256 HSM storage keys, the following authenticator applications are no longer supported:

• authenticator applications using DES or 3DES
• authenticator applications using the UnlockV1 unlocking mechanism (UnlockV1 is based on a DES key)

For Digipass authenticators using DES, 3DES, and/or UnlockV1, the hardware encryption with HSM storage keys must continue to use 3DES HSM keys.

The HSM storage key is the customer's responsibility; this includes generating the key and managing the key life cycle.

BLOB encryption

The Authentication Suite Server SDK BLOBs (that contain the Digipass profile and keys) remain in the host computer database under control of the customer application, but they are now encrypted in a different way:

The sensitive information inside the BLOB (e.g. Digipass keys and secret codes, redundancy bit) is CBC-3DES-or AES-encrypted by the HSM, using an HSM storage key. This prevents this sensitive information from being reconstructed or changed outside the HSM. To make the encryption unique per BLOB, it is possible to specify an 8-byte initial vector that will be used during the encryption. The redundancy bit is used to guarantee the integrity of the sensitive information. Hence, this bit guarantees that you are using the right HSM storage key and initial vector for the decryption as the one used to perform the encryption.

A hash is then calculated on the full BLOB. This hash allows checking the BLOB integrity prior to any operation on it.

Maintenance operations, such as reset or resynchronize token time drift, can still be done without putting extra load on the HSM as sensitive information is not required to be decrypted.

Multiple HSMs with the same HSM storage key can be used in parallel to increase performance.

HSM storage key migration process

If the customer would like to update the HSM storage key that is used to encrypt the authenticator application BLOBs, there is the facility to do this, using the AAL2MigrateBlobICSF function.

With this function you pass the old and new HSM storage key names. The authenticator application BLOB will then have HSM-level encryption using the new HSM storage key. And from that point on, you must pass the new HSM storage key to the verification process and other Authentication Suite Server SDK functions.

Import process

The DPX import process remains the same for the Authentication Suite Server SDK standard version and Authentication Suite Server SDK for ICSF. An additional function is available to move the BLOB encryption from the Authentication Suite Server SDK software encryption key to the HSM storage key.

The following sequence of operations will be performed by the Authentication Server:

1. Decryptions of the DPX file using the appropriate software transport keys. This involves DPX-to-BLOB conversion - the Authentication Suite Server SDK library offers the AAL2DPXInit, AAL2DPXGetTokenBlobsEx2, and AAL2DPXClose functions. The resulting BLOB is encrypted with the Authentication Suite Server SDK software storage key.
2. Migration of the BLOB encryption from the Authentication Suite Server SDK software storage key to the HSM storage key by calling the Authentication Suite Server SDK AAL2MigrateBlobICSF function.
3. Storage of each BLOB in the database for use in future OTP validations.

Optional DPX double encryption

The DPX file generation process can be modified so that the Digipass keys are first encrypted by an HSM transport key. Then these encrypted keys are embedded in the DPX file and encrypted in the normal way with the software transport keys.

Therefore, the Digipass keys in the DPX are double encrypted and the remaining data single encrypted.

The benefit of this is to preclude the Digipass keys ever being on the application host without HSM-level encryption - the Digipass keys will never be exposed during this process.

When importing the DPX file, the DPX to authenticator application BLOB conversion will be carried out in the normal way, in software. The (software-decrypted) authenticator application BLOB would then contain token keys encrypted under an HSM transport key.

The AAL2MigrateBlobICSFEx function is used to decrypt the Digipass keys using the HSM transport key and re-encrypt them under the HSM storage key.

Modified import process

For the Authentication Suite Server SDK integrator, the DPX import process is slightly modified. It is now necessary to call the AALDPXInitHSM instead of the AALDPXInit function and to add an extra Authentication Suite Server SDK API call after retrieving a authenticator application BLOB – AAL2MigrateBlobICSFEx. Sample pseudo-code follows:

AAL2DPXInitHSM()
For each token in DPX file
  AAL2DPXGetTokenBlobsEx2()
  AAL2MigrateBlobICSFEx()
  Store DIGIPASS application BLOB in Application Database
EndFor
AAL2DPXClose()

Before any OTP or digital signature can be validated you need to migrate the authenticator application BLOB encryption in this way. The Authentication Suite Server SDK API Authentication and Management functions will reject any authenticator application BLOB that is encrypted with an HSM transport key.

HSM transport key import

The HSM transport key resides on the customer’s HSM. Despite this, it must be sent to OneSpan before any DPX double encryption process can commence. A standard procedure is to be followed for this key transfer - the customer must fill out a Request for import of HSM-level DPX Transport Key for Double DPX Encryption form.

The HSM transport key is also a data encryption key double length 3DES, triple length 3DES, AES-128bit, or AES-256bit.

When using HSM transport keys ofthe type AES-128 or AES-256, the following authenticator applications are not supported:

• Authenticator applications using DES or 3DES
• Authenticator applications using the UnlockV1 mechanism (UnlockV1 is based on a DES key)

For Digipass using DES, the 3DES algorithm, and/or UnlockV1 unlocking, the hardware encryption with an HSM transport key must use 3DES HSM keys.

The actual transfer involves use of a Key Encrypting Key (KEK) - this KEK has previously been created and shared by the customer and OneSpan. The KEK is used to encrypt the HSM transport key so as to provide a secure means of transferring it.