Authentication Suite Server SDK originally used software-based encryption mechanisms based on the algorithm 3DES-112 to protect DPX files and authenticator application BLOBs. As of version 4.0.1, Authentication Suite Server SDK supports software-based encryption of DPX files as well authenticator application BLOBs with AES-256.
This section explains why it is recommended to use AES-256 for software-based encryption of both DPX-files and authenticator application BLOBs, and describes how to migrate authenticator application BLOBs from 3DES-112 to AES-256.
Reasons for using AES-256
We strongly recommend to use software-based encryption of DPX files authenticator application BLOBs based on AES-256 for the following reasons:
The potential advent of cryptographically-relevant quantum computers (CRQC) enables novel attacks against sensitive data which are not possible with traditional, non-quantum computers. Cryptographically-relevant quantum computers are quantum computers that can run algorithms to break or weaken existing, classical cryptographic algorithms.
An example of such a novel attack is the 'harvest now, decrypt later' attack, where adversaries collect today’s encrypted data and keep it until they acquire a quantum computer that can decrypt it in the future. To protect data that needs to remain confidential well into the future against such novel attacks, today’s data should already be encrypted with quantum-resistant cryptographic algorithms, such as AES-256.
Standards related to key management recommend the usage of AES to protect data that requires long-term protection, and recommend using keys with a length of at least 128 bits.
NIST Special Publication (SP) 800-57 Part 1, "Recommendation for Key Management", advises to use AES to encrypt data that needs to remain secure beyond 2030.
Available at (last accessed in November 2024): https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
ANSSI’s Guide about Cryptographic Mechanisms, referred to as ANSSI-PG-083, recommends to use AES keys with at least 128 bits as from 2026.
Available at (last accessed in November 2024): https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf
The Technical Guideline TR-02102-1, "Cryptographic Mechanisms: Recommendations and Key Lengths", published by the German Federal Office for Information Security (BSI), advises to use AES with a key length of 256 bits, especially for applications with high or long-term protection requirements or long-living systems.
Available at (last accessed in November 2024): https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html
- The usage of AES-256 does not introduce performance overhead compared to using 3DES-112.
Notwithstanding these recommendations, you should perform your own risk and compliance analysis to determine the most appropriate key length in your specific context.
Migrating authenticator application BLOBs from 3DES-112 to AES-256
You can ensure authenticator application BLOBs are encrypted using AES-256 instead of 3DES-112 based on the following steps. These steps assume you are using Authentication Suite Server SDK 4.0.1 or later.
- Specifying the database protection key
- Import of new DPX files
- Implicit migration of existing authenticator application BLOBs
- Explicit migration of existing authenticator application BLOBs
Specifying the database protection key
As described in Explicit migration of existing authenticator application BLOBs, the database protection key, which is used to protect authenticator application BLOBs, can be specified via the following two kernel runtime parameters:
- The DeriveVector kernel runtime parameter, which has a length of 4 bytes, or
- eight StorageDeriveKey kernel runtime parameters that each have a length of 4 bytes, resulting in a total length of 32 bytes.
We recommend using the StorageDeriveKey kernel runtime parameters because they allow specifying a 256-bit (32-byte) database protection key. The DeriveVector kernel runtime parameter has a length of 4 bytes (32 bits) and can therefore not be used to specify a 256-bit key.
If you are already using StorageDeriveKey 1-4 kernel runtime parameters to protect your existing authenticator application BLOBs, we recommend not to change the values of these parameters, and only define values for the StorageDeriveKey 5-8 kernel runtime parameters.
Import of new DPX files
When importing new DPX files Authentication Suite Server SDK protects the resulting authenticator application BLOBs using AES-256, irrespective of whether the DPX files are protected with 3DES-112 or AES-256.
The functions of Authentication Suite Server SDK used during the import process, such as AAL2DPXGetToken() and AAL2DPXGetTokenBlobs(), must use the correct database protection key as input parameter. The key must be specified via the StorageDeriveKey 1-8 kernel runtime parameters, present in the TKernelParms* CallParms data structure.
Implicit migration of existing authenticator application BLOBs
Authentication Suite Server SDK automatically migrates existingauthenticator application BLOBs from 3DES-112 to AES-256 when they are used, for example to validate a one-time password (OTP). In this scenario, authenticator application BLOBs are migrated one by one.
The functions of Authentication Suite Server SDK used during this process must use the correct database protection keys as input parameter. More specifically, the kernel runtime parameters must contain both the current database protection key and the new database protection key. Table: Implicit BLOB migration scenarios depicts possible scenarios for the old and new database protection keys, and indicates which parameters should be used to specify these keys.
In scenario 1 above, the new database protection key has an effective key length of 128 bits rather than 256 bits. Therefore, if BLOBs were originally protected using a database protection key based on empty DeriveVector or StorageDeriveKey parameters, we recommend using explicit migration, as described below, to ensure that these BLOBs are migrated to 256-bit keys. Explicit migration allows specifying a 256-bit value for the new database protection key.
Explicit migration of existing authenticator application BLOBs
You can explicitly migrate existing authenticator application BLOBs, instead of waiting until these BLOBs are used by Authentication Suite Server SDK. You can explicitly migrate these BLOBs with the AAL2MigrateBlobEx() function of Authentication Suite Server SDK. This function must receive both the current database protection key and the new database protection key as input parameters. Table: Explicit BLOB migration scenarios depicts possible scenarios for the old and new database protection keys, and indicates which parameters should be used to specify these keys.
Rotating database protection keys
According to sound security practices, encryption keys should be rotated on a regular basis. Authentication Suite Server SDK supports rotating database protection keys via the AAL2MigrateBlobEx() function.
Assuming that the BLOBs are protected with AES-256, the BLOBs can be migrated from the current 256-bit key to a new 256-bit key via the following parameters:
- The current database protection key should be specified via the StorageDeriveKey 1-8 parameters in TKernelParms* CallParms
- The new database protection key should be specified via the StorageDeriveKey 1-8 function parameters (not in TKernelParms* CallParms).