Special Specifications
Concurrency Constraints
The cryptographic module TA supports a maximum of 100 sessions, which are shared by all CAs. If the number of sessions exceeds the upper limit, an error is reported when calling a cryptographic module API. The following describes API-specific cryptographic module TA session usage.
- One session is occupied when SDF_OpenDevice is called, and the session is released only when SDF_CloseDevice is called.
- One session is occupied when SDF_OpenSession, SDF_CloseSession, ECM_OpenSession, or ECM_FactoryReset is called, and the session is released immediately after the call ends.
- SDF_CloseDevice closes the session occupied by SDF_OpenDevice.
- A TA session in a thread can be reused when other APIs except the above ones are called. Specifically, in a single thread, each API call occupies a TA session, and the session is not released immediately the call ends. If a new API call is made within 1s, the session is reused.
Otherwise, the session is reclaimed, and a new TA session is required for the next API call. In practice, the actual interval may be slightly longer than 1s (1.5s to 2s) due to scheduling or other factors. In multi-process scenarios, wait for 20s to ensure that the TA session is reclaimed.
Internal Key Usage and Attack Defense
- The ECM provides internal keys generated by using the management tool or management APIs. When an asymmetric key or a master key is generated, you need to configure a password.
- The cryptographic module complies with GM/T 0018-2012. The SDF APIs are called by the cryptographic device service layer instead of users. The cryptographic device service layer calls the management tool to generate internal keys. Normally, the service layer calling SDF_GetPrivateKeyAccessRight or SDF_GetKEKAccessRight does not lead to errors related to incorrect passwords.
- If an attacker in an isolated environment performs brute-force password cracking by repeatedly calling SDF_GetPrivateKeyAccessRight or SDF_GetKEKAccessRight, the cryptographic module records the number of consecutive incorrect password inputs. When the number exceeds 500, the key file at the corresponding index in the cryptographic module becomes unavailable, and the error code SDR_COMMFAIL is returned when the corresponding API is called. If an error is reported when SDF_GetPrivateKeyAccessRight or SDF_GetKEKAccessRight is called, check whether the API parameters are correct and verify the correctness of the password with the administrator.
Cryptographic Module Initialization
During device initialization, call the management tool to generate internal keys and configure the application paths that can access the keys. After the configuration is complete, applications can enter the key password to obtain the key usage permission and then use the capabilities provided by the cryptographic module. File operations can be performed only on hosts. File operation APIs cannot be used in containers.
Encryption Key Usage
The access permission of asymmetric private keys needs to be obtained through the SDF_GetPrivateKeyAccessRight API, and that of KEKs needs to be obtained through the SDF_GetKEKAccessRight API.
Asymmetric Key Password Requirements
The password of asymmetric keys must meet the following requirements:
- The password must contain at least two types of the following characters:
- Lowercase letters
- Uppercase letters
- Digits
- Special characters: `~!@#$%^&*()-_=+\|[{}];:'",<.>/? and spaces
- The length ranges from 8 bytes to 128 bytes.