Security Subsystem

• Overview
• Directory Structure
• Constraints
• Secure Boot
• Application Permission Management
• IPC Authentication
• HUKS
• HiChain
• Application Integrity Verification
• Repositories Involved

Overview

This document provides samples about how to use existing security mechanisms to improve system security features, including secure boot, application permission management, inter-process communication (IPC) authentication, Huawei Universal Keystore Service (HUKS), HiChain, and application signature verification.

Directory Structure

base/security
├── appverify
│   └── interfaces
│       └── innerkits
│           └── appverify_lite  # Application signature verification APIs
├── deviceauth
│   ├── frameworks
│   │   └── deviceauth_lite  # Device authentication implementation
│   └── interfaces
│       └── innerkits
│           └── deviceauth_lite # Device authentication APIs
├── huks
│   ├── frameworks
│   │   ├── crypto_lite  # Encryption and decryption implementation
│   │   └── huks_lite  # Key management implementation
│   └── interfaces
│       └── innerkits
│           └── huks_lite  # Key management APIs
└── permission
    ├── interfaces
    │   ├── innerkits
    │   │   └── permission_lite  # Internal APIs for permission management
    │   └── kits
    │       └── permission_lite  # External APIs for permission management
    └── services
        └── permission_lite  # Permission management service

Constraints

C programming language is used. The preceding security features are mainly used on Cortex-A or devices with equivalent processing capabilities. On Cortex-M or devices with equivalent processing capabilities, only HUKS and HiChain are available.

Secure Boot

To generate a x509 image package, perform compilation to generate the required binary images, including kernel images kernel.bin (liteos/OHOS_Image) and rootfs.img. If the Hi3516DV300 chip is used, the generated images are stored in the out\ipcamera_hi3516dv300_liteos_a directory. Copy the binary images and the secure uboot private keys (in the vendor\hisi\hi35xx\hi3516dv300\uboot\secureboot_release directory) to the secureboot_ohos directory (in the vendor\hisi\hi35xx\hi3516dv300\uboot directory). Go to the x509_creater directory, run the ./creater.sh command, and generate the x509 certificate as prompted. Return to the secureboot_ohos directory and run ./sec_os.sh to generate the x509 image package.

Application Permission Management

Application permissions are used to control access to system resources and features related to personal privacy, for example, accessing hardware features of personal devices such as cameras and microphones, and reading and writing media files. The OS protects such data and features through application permission management.

The following table describes fields in a permission.

Table 1 Descriptions of fields in a permission

IPC Authentication

• If system services registered with Samgr provide APIs for other processes to access the services through IPC, access control policies must be configured; otherwise, access to the system services will be denied.

• You can configure access control policies in base/security/services/iam_lite/ipc_auth/include/policy_preset.h.

  1. Define the policies for each feature.

  2. Add the feature policies to the global policy.

For example, to configure an access policy for the BMS service, whose service registered with Samgr is bundlems and whose registered feature is BmsFeature, perform the following operations:

1. Define feature policies. You can configure multiple features and configure multiple access policies for each feature.

Figure 1 Example feature policy

There are three types of access policies:

Figure 2 Access policy structure

• RANGE: Processes with a UID within a specified range are allowed to access BmsFeature. uidMin and uidMax need to be specified.
• FIXED: Processes with specified UIDs are allowed to access BmsFeature. fixedUid needs to be specified. A maximum number of eight UIDs can be configured.
• BUNDLENAME: Only a specified application is allowed to access BmsFeature. bundleName needs to be specified.

2. Add the defined feature policies to the global policy. You need to configure the number of features.

Figure 3 Registering a feature policy

UID allocation rules:

1. Init process: 0

appspawn process: 1

Shell process: 2

4. Other built-in system services: less than or equal to 99

5. System applications (such as settings, home screen, and camera): 100–999

6. Preset applications: 1000–9999

7. Common third-party applications: 10000 to INT_MAX

HUKS

In distributed scenarios, trust relationships need to be established between devices with varied hardware capabilities and system environments. A typical application is HiChain for trusted interconnection between devices. In this case, a unified key management service is required to ensure consistent APIs and key data formats, and provide industry-standard encryption/decryption algorithms. HUKS is such a service that provides unified key management and encryption/decryption.

HUKS consists of native APIs, the hardware abstraction layer (HAL), and Core Module.

1. Native APIs are implemented using the C language to ensure consistency among all devices, and include the APIs for key generation, encryption, and decryption.
2. Core Module depends on the HAL and provides core functions such as encryption and decryption, signature verification, and key storage.
3. HAL shields differences between hardware and OSs and defines the unified APIs for HUKS. It contains platform algorithm libraries, file systems, and logs.

HiChain

Device Interconnection Security

To transmit user data securely between devices, ensure that the devices are trusted by each other. A trust relationship and a secure data transmission channel must be established between the devices. This section describes how an IoT controller and IoT device establish a trust relationship.

• IoT device interconnection security

A trust relationship can be established between an IoT device that runs OpenHarmony (such as the AI speaker, smart home device, and wearable device) and an IoT controller (such as the smartphone and tablet). Encrypted user data can be transmitted between the IoT device and IoT controller through a secure connection.

• IoT service identifier of the IoT controller

An IoT controller generates different identifiers for different IoT device management services to isolate these services. The identifier can be used for authentication and communication between an IoT controller and an IoT device. It is an Ed25519 public/private key pair generated using the elliptic curve cryptography.

• IoT device identifier

An IoT device can generate its own device identifier for communicating with the IoT controller. It is also an Ed25519 public/private key pair generated using elliptic curve cryptography, with the private key stored on the IoT device. Each time the device is restored to factory settings, the public/private key pair will be reset.

The identifier can be used for secure communication between the IoT controller and IoT device. After the devices exchange the service identifier or device identifier, they can negotiate the key and establish a secure communication channel.

• P2P trusted binding between devices

When an IoT controller and an IOT device establish a trust relationship, they exchange identifiers.

During this process, the user needs to enter or scan the PIN provided by the IoT device on the IoT controller. PIN is either dynamically generated if the IoT device has a screen, or preset by the manufacturer if it does not have a screen. A PIN can be a number or a QR code. Then the IoT controller and IoT device perform authentication and session key exchange based on password authenticated key exchange (PAKE), and use the session key to encrypt the channel for exchanging identity public keys.

Secure communication between the IoT controller and IoT device

When an IoT controller and an IoT device communicate with each other after establishing a trust relationship, they authenticate each other by using the locally stored identity public key of the peer. Bidirectional identity authentication and session key exchange are performed using the Station-to-Station (STS) protocol during each communication. The session key is used to encrypt the data transmission channel between the devices.

Application Integrity Verification

To ensure the integrity and trustworthiness of the applications to be installed in OpenHarmony, the applications must be signed and their signatures must be verified.

In application development: After developing an application, you need to sign its installation package to ensure that the installation package is not tampered with when it is released on devices. To sign the application package, you can use the signature tools and the public key certificates and follow the signing certificate generation specifications provided by the application integrity verification module. For your convenience, a public key certificate and a corresponding private key are preset in OpenHarmony. You need to replace the public key certificate and private key in your commercial version of OpenHarmony.

In application installation: The application framework subsystem of OpenHarmony installs applications. Upon receiving an application installation package, the Application Framework subsystem parses the signature of the installation package, and verifies the signature using the application integrity verification APIs. The application can be installed only after the verification succeeds. During the verification, the application integrity verification module uses the preset public key certificate to verify the signature.

Repositories Involved

security_permission

security_appverify

security_deviceauth

security_huks