Key Generation Introduction and Algorithm Specifications
Note:
Currently in the beta phase.
Key Generation Introduction
When a service requires HUKS to generate random keys and securely store them, it can invoke HUKS interfaces for key generation.
Note:
Key aliases must not contain sensitive information such as personal data.
- Random Generation: Refers to HUKS using cryptographically secure pseudo-random numbers during key generation to enhance the randomness, unpredictability, and irreproducibility of keys, ensuring generated keys are difficult to infer.
- Secure Storage: Means that keys generated by HUKS (except for public keys in asymmetric key pairs) can only be used by HUKS in secure storage areas throughout their entire lifecycle (from generation to destruction). The generated key files cannot be directly accessed by any service other than HUKS. Even the service that generated the keys can only perform key operations through HUKS-provided interfaces to obtain operation results.
- Key Usage: A key can only have one type of usage. For example, the same key cannot be used for both encryption/decryption and signature/verification. Additionally, the usage specified during key generation must match the usage method during application; otherwise, exceptions may occur.
Key Storage Security Levels
Developers can specify storage security levels, with the default being CE. The available options are shown in the table below.
| Name | Value | Description |
|---|---|---|
| HUKS_AUTH_STORAGE_LEVEL_DE | 0 | Indicates the key is accessible only after boot. |
| HUKS_AUTH_STORAGE_LEVEL_CE | 1 | Indicates the key is accessible only after the first unlock. |
| HUKS_AUTH_STORAGE_LEVEL_ECE | 2 | Indicates the key is accessible only when the device is unlocked. |
Supported Algorithms
The following are the specifications supported for key generation.
For OpenHarmony, vendor-adapted key management service specifications are divided into mandatory and optional specifications. Mandatory specifications are supported by all vendors, while optional specifications are implemented based on vendor-specific conditions. If optional specifications are needed, consult the vendor's documentation to ensure compatibility before use.
Developers are advised to use mandatory specifications for application development to ensure full platform compatibility.
Standard Device Specifications
| Algorithm | Supported Key Lengths | API Level | Mandatory Specification |
|---|---|---|---|
| AES | 128, 192, 256 | 15+ | Yes |
| RSA | 512, 768, 1024 | 15+ | No |
| RSA | 2048, 3072, 4096 | 15+ | Yes |
| RSA | 1024-2048 (inclusive), must be multiples of 8 | 15+ | Yes |
| HMAC | 8-1024 (inclusive), must be multiples of 8 | 15+ | Yes |
| ECC | 224 | 15+ | No |
| ECC | 256, 384, 521 | 15+ | Yes |
| ED25519 | 256 | 15+ | Yes |
| X25519 | 256 | 15+ | Yes |
| DSA | 512-1024 (inclusive), multiples of 8 | 15+ | No |
| DH | 2048 | 15+ | Yes |
| DH | 3072, 4096 | 15+ | No |
| SM2 | 256 | 15+ | Yes |
| SM4 | 128 | 15+ | Yes |
| DES | 64 | 15+ | Yes |
| 3DES | 128, 192 | 15+ | Yes |
Note:
The DH algorithm uses FFDHE well-known secure prime groups. DES and 3DES algorithms are provided only for specific scenarios and are not recommended for other use cases.
Lightweight Device Specifications
For lightweight devices, OEM vendors will decide whether to implement the listed specifications based on their specific conditions. If these specifications are needed, consult the vendor's documentation to ensure compatibility before use.
| Algorithm | Supported Key Lengths | API Level |
|---|---|---|
| AES | 128, 192, 256 | 15+ |
| DES | 64 | 15+ |
| 3DES | 128, 192 | 15+ |
| RSA | 1024-2048 (inclusive), must be multiples of 8 | 15+ |
| HMAC | 8-1024 (inclusive), must be multiples of 8 | 15+ |
| CMAC | 128 (algorithm supports only 3DES) | 15+ |