HUKS Access Control Overview

HUKS provides comprehensive access control capabilities to ensure authorized access to the keys in HUKS.

  • Services can access only their own keys, that is, the keys generated or imported through HUKS.

  • For security-critical service keys, user identity authentication is required. The service keys can be used only after the authentication (PIN or biometric authentication) is successful.

  • The usage of keys is strictly restricted. For example, the AES keys can be used only for encryption and decryption, and the RSA keys can be used only for signing and signature verification.

Application Scenarios and Development Process

The access control via user identity authentication involves multiple phases, which are described as below.

User Identity Authentication

During the key generation or import process, user identity authentication can be enabled to allow the use of the key only after the authentication is successful. A subset of credentials (lock screen password, fingerprint, and facial) can be specified for user identity authentication.

After a key is generated or imported, unauthorized key access can be prevented even if the application process is attacked. The key access control via user authentication applies to security-sensitive scenarios, such as password-free login, password-free payment, and automatic password filling.

Authorized Access Type

In addition to user identity authentication, HUKS provides the following modes to control key validity:

  • The key will be invalidated when the screen lock password is cleared.
    After a key is generated or imported, the key becomes invalid permanently once the lock screen password is cleared. This mode takes effect only when a lock screen password has been set. The key will not be invalidated if the screen lock password is modified.

    This mode applies to user-related data protection or access based on the lock screen password.

  • The key will be invalidated when new biometric enrollments are added.
    After a key is generated or imported, the key becomes invalid permanently once a new biometric feature is enrolled. This mode takes effect only when at least one biometric feature (such as fingerprint) has been enrolled. The key will not be invalidated if the biometric feature is deleted.

    This mode applies to scenarios, such as password-free login or payment.

  • The key is always valid.
    In this mode, the key is permanently valid until it is deleted by the user.

    When this mode is specified for a key in generation, the key is bound with a foreground user ID. Only the foreground user ID is verified.

Challenge Verification

HUKS also provides the verification of the challenge value to ensure the validity of the user authentication result (non-replay).

Before user identity authentication, the challenge obtained from HUKS is passed to the user authentication method. The challenge of the authentication token is then verified during key operations.

Refined Key Access Control

HUKS provides refined access control, which includes the following modes:

  • AuthToken-based access control

    ![] (figures/access_control.png)

    The preceding figure illustrates the user identity authentication and access control process.

    The AT KEY (symmetric key) is derived from the secure root key of the device each time a HUKS TA is started. The interaction between UserIAM and HUKS is in a TEE.

  • One-time authentication for multiple authorization requests

    HUKS allows the authorization of multiple keys to be completed through one authentication.

    This feature applies to phone clone, in which all the data can be exported if the lock screen password is successfully verified once.

    The challenge generated by HUKS each time is of 8 bytes, and the challenge passed to UserIAM can be extended to 32 bytes. This allows one-time authorization of the access requests for a maximum of four keys. The service calls HUKS to generate an 8-byte challenge for each key, combines multiple challenges into one challenge, and sends the challenge to UserIAM for authentication.

  • Timestamp-based access control

    HUKS supports timestamp-based challenge-free access control for performance-critical scenarios. A timeout period is set when a key is generated. When a service needs to access the key, the service directly requests UserIAM to initiate authentication and sends AuthTocken containing the timestamp to HUKS. After verifying AuthTocken, HUKS checks whether the difference between the current time and the timestamp is greater than the specified timeout period. If not, the service can access the key.