Go to file
openharmony_ci 2ee81dec35
!310 feat:improve mini link
Merge pull request !310 from zhuofan/master
2024-09-30 08:46:01 +00:00
baselib feat: cancel connect laptop 2024-09-19 15:38:27 +08:00
common feat: split dslm_service 2023-12-05 14:37:02 +08:00
figures update docs 2022-04-11 15:33:11 +08:00
interfaces/inner_api feat: add remote judgment 2024-09-23 15:45:32 +08:00
oem_property feat: Fix alarm 2024-09-05 09:30:45 +08:00
param feat: add interface for querying level to softbus 2024-02-29 16:01:29 +08:00
profile feat: add dslm_service cfg permission 2023-12-08 12:41:52 +08:00
services feat: improve mini link 2024-09-30 12:04:14 +08:00
test feat: Independent compile 2024-08-09 14:10:14 +08:00
.gitignore update .gitignore 2022-01-22 12:00:43 +08:00
bundle.json feat: Independent compile 2024-08-09 14:10:14 +08:00
cfi_blocklist.txt feat: change the cfi_block_list 2023-11-02 11:39:18 +08:00
CODEOWNERS fix: standardize ipc code 2023-06-19 22:00:51 +08:00
hisysevent.yaml fix: change hisys domain name 2022-08-16 20:32:53 +08:00
LICENSE fix: license file fix 2022-03-21 19:03:12 +08:00
OAT.xml fix: time modify liuwenkai@huawei.com 2022-03-23 09:42:52 +08:00
README_ZH.md fix: 设备认证仓名修改 2022-06-14 10:47:07 +08:00
README.md fix: 设备认证仓名修改 2022-06-14 10:47:07 +08:00

Device Security Level Management

Introduction

The OpenHarmony distributed technology can converge resources from different devices to form a Super Device. Poor security capabilities of any device may threaten the security of the Super Device. The Device Security Level Management (DSLM) module is introduced to manage the security levels of OpenHarmony devices.

The security level of an OpenHarmony device depends on the system security capabilities of the device. The OpenHarmony system security capabilities are based on the root of trust (RoT) for boot, RoT for storage, and RoT for compute on the hardware. Security technologies and capabilities focus on device integrity protection, data confidentiality protection, and vulnerability defense.

The figure below shows the OpenHarmony security architecture.

OpenHarmony system security architecture

The above figure shows the typical security architecture for a single device. The architecture may vary depending on the risk level as well as the software and hardware resources of the device. The security capabilities of OpenHarmony devices are classified into five levels from SL1 to SL5, based on the industry standard security classification model and actual OpenHarmony service scenarios and device types. In the OpenHarmony ecosystem, higher security levels include all the capabilities of lower security levels by default. The figure below shows the security levels of OpenHarmony devices.

OpenHarmony device security levels

  • SL1: SL1 is the lowest security level of OpenHarmony devices. Usually equipped with a lightweight operating system and low-end microprocessors, such devices implement simple services and do not need to process sensitive data. SL1 devices are required to support software integrity protection and eliminate common errors. Devices that cannot meet the requirements of SL1 can only be controlled by OpenHarmony devices. They cannot control OpenHarmony devices for more complex service collaboration.

  • SL2: OpenHarmony devices of SL2 can label their own data and define access control rules to implement discretionary access control (DAC). These devices must have basic anti-penetration capabilities. Devices of this level support a lightweight, secure, and isolated environment for deploying a small number of necessary security services.

  • OpenHarmony devices of SL3 have comprehensive security protection capabilities, and their operating systems have relatively complete security semantics and support mandatory access control (MAC). The system data can be structured as critical elements and non-critical elements. The critical elements are protected by a well-defined security policy model. Devices of this level must have certain anti-penetration capabilities to defend against common vulnerability exploits.

  • SL4: OpenHarmony devices of SL4 must have simplified trusted computing base (TCB) and come with anti-tampering capabilities. The implementation of SL4 should be concise and secure enough. Adequate authentication and arbitration are required for any access to critical elements. Devices of this level have considerable anti-penetration capabilities and can defend against most software attacks.

  • SL5: SL5 indicates the highest security protection capabilities for OpenHarmony devices. The system core software modules must have passed formal verification. Key hardware modules, such as the RoT and cryptographic computing engine, must be able to defend against physical attacks and attacks simulated in labs. Devices at this level must have high-security units, such as dedicated security chips, to enhance the boot, storage, and running of the root of trust (RoT).

The security level of each device in a Super Device provides the decision-making criteria for processing or hopping various user data.

For details about the relationship between data risk levels and device security levels, see Data Transfer Management.

Directory Structure

The directory structure of the DSLM module is as follows:

base/security/device_security_level
├── baselib        # Base library
├── common         # Common header files
├── interfaces     # Inner APIs
├── oem_property   # OEM adaptation
├── profile        # Component profiles
├── services       # Service framework code
└── test           # Test code

Constraints

  • Only C and C++ are supported.
  • The default security level of OpenHarmony devices is SL1. Device vendors can customize a higher security level as required.

Description

Available APIs

When different types of user data are hopped or processed in OpenHarmony distributed devices, the DSLM APIs can be called to obtain the security levels of related devices for subsequent processing.

API Description
int32_t RequestDeviceSecurityInfo(const DeviceIdentify *identify, const RequestOption *option, DeviceSecurityInfo **info); Requests the security level information of a device synchronously.
int32_t RequestDeviceSecurityInfoAsync(const DeviceIdentify *identify, const RequestOption *option, DeviceSecurityInfoCallback callback); Requests the security level information of a device asynchronously.
void FreeDeviceSecurityInfo(DeviceSecurityInfo *info); Releases the device security level information.
int32_t GetDeviceSecurityLevelValue(const DeviceSecurityInfo *info, int32_t *level); Obtains the device security level from the security level information.

Usage

All the APIs are native C interfaces for implementing underlying capabilities and are not open to apps.

  • Adding Dependencies
  1. Add the dependencies for compilation.

    external_deps += [ "device_security_level:dslm_sdk" ]
    
  2. Add the header files of dependencies.

    #include "device_security_defines.h" // Header file for defining critical data structures.
    #include "device_security_info.h" // Header file for defining APIs.
    
  • Example

The following is an example of synchronously obtaining the device security level:

void CheckDestDeviceSecurityLevel(const DeviceIdentify *device, RequestOption *option)
{
    // Pointer to the device security level information.
    DeviceSecurityInfo *info = NULL;

    // Obtain the security level information of the device.
    int32_t ret = RequestDeviceSecurityInfo(device, option, &info);
    if (ret != SUCCESS) {
        // Failed to obtain the information. You can develop a retry process as required.
        return;
    }
    int32_t level = 0;
    // Obtain the device security level from the security level information.
    ret = GetDeviceSecurityLevelValue(info, &level);
    if (ret != SUCCESS) {
        // Failed to obtain the device security level. You can develop a retry process as required.
        FreeDeviceSecurityInfo(info);
        return;
    }

    // After the device security level is successfully obtained, check the lowest security level required for the current operation.
    // The lowest device security level required for the current operation is 3.
    if (level >= 3) {
        // The security level of the target device meets the requirements. Services are processed properly. 
    } else {
        // The security level of the target device does not meet the requirements. A toast or dialog box is displayed as required.
    }

    // Release the memory before the processing is complete.
    FreeDeviceSecurityInfo(info);
}

The following is an example of asynchronously obtaining the device security level:

// Callback
void DeviceSecurityInfoCallback(const DeviceIdentify *identify, struct DeviceSecurityInfo *info)
{
    int32_t level = 0;
    // Obtain the device security level from the security level information.
    int32_t ret = GetDeviceSecurityLevelValue(info, &level);
    if (ret != SUCCESS) {
        // Failed to obtain the information. You can develop a retry process as required.
        FreeDeviceSecurityInfo(info);
        return;
    }

    // After the device security level is successfully obtained, check the lowest security level required for the current operation.
    // The lowest device security level required for the current operation is 3.
    if (level >= 3) {
        // The security level of the target device meets the requirements. Services are processed properly. 
    } else {
        // The security level of the target device does not meet the requirements. A toast or dialog box is displayed as required.
    }

    // Release the memory before the processing is complete.
    FreeDeviceSecurityInfo(info);
}

void CheckDestDeviceSecurityLevelAsync(const DeviceIdentify *device, RequestOption *option)
{
    // Invoke the asynchronous callback to return the device security level obtained.
    int ret = RequestDeviceSecurityInfoAsync(device, option, DeviceSecurityInfoCallback);
    if (ret != SUCCESS) {
        // Failed to obtain the device security level. You can develop a retry process as required.
        // In this case, the callback will not be invoked.
        return;
    }
    // The callback is invoked. Wait for the callback to return the device security level.
}

Change Log

  • V 1.0

Repositories Involved

Data Transfer Management

Device Security Level Management

HUKS

Application Permission Management

Device Authentication

SELinux