1# Security Overview
2
3
4The OpenHarmony security subsystem provides security capabilities that allow for trustworthy applications and devices and permission management. This subsystem has the following modules:
5
6
7- Application signature verification
8
9  The system uses the application signature and profile to ensure that all applications come from a known and approved source and have not been tampered with. For a debug application, APIs are provided to verify whether the Unique Device Identifier (UDID) of the application matches that of the device. The application can be installed on the device only when the UDIDs match.
10
11- Application permission management
12
13  Application permissions determine what system resources and capabilities an application can access. During application development, you need to declare the permissions required by your application in the application configuration file. Permissions include system_grant permissions (which need to be registered during the application installation) and user_grant permissions (which involve sensitive information and must be granted by the user).
14
15- Inter-process communication (IPC) authentication
16
17  The caller that attempts to invoke the APIs provided by system services through IPC must be authenticated. The system ability (SA) registered with the System Ability Manager (Samgr) can expose APIs to other processes through IPC, with access policies configured. When other processes attempt to call these APIs, the IPC authentication will be triggered. If the processes do not have the required permission, the access request will be rejected.
18
19- DSLM
20
21  The Device Security Level Management (DSLM) module is introduced to manage the security levels of OpenHarmony devices. When different types of user data are transferred or processed in OpenHarmony distributed services, the DSLM APIs can be called to obtain the security levels of related devices for subsequent processing.
22
23- HUKS
24
25  OpenHarmony Universal Keystore (HUKS) provides system-level key management capabilities, ensuring secure management and use of keys throughout their entire lifecycle (generation, storage, use, and destruction). Applications can call the APIs provided by the HUKS module to perform operations on keys. In addition, the keys in plaintext must be used in a trusted execution environment (TEE).
26
27- OpenHarmony SELinux
28
29  OpenHarmony Security-Enhanced Linux (SELinux) provides mandatory access control (MAC) capabilities for system resources such as files, parameters, SAs, and the HDF based on the system architecture characteristics and SELinux.
30
31
32## Basic Concepts
33
34Before you get started, it is helpful to understand the following basic concepts:
35
36- Samgr
37
38  Samgr manages SAs. For details, see the SA Framework development guidelines.
39
40- BMS
41
42  Bundle Manager Service (BMS) manages application installation, uninstallation, and data on the system.
43
44- Profile
45
46  The profile in this document refers to HarmonyAppProvision, which is in JSON format.
47
48- Debug application
49
50  A debug application is a Harmony Ability Package (HAP) that is signed with a debug certificate and profile obtained from AppGallery.
51
52- Release application
53
54  A release application is a HAP that is signed with a release certificate and profile obtained from AppGallery, and formally released on AppGallery.
55
56- OpenHarmony self-signed application
57
58  A self-signed application is an application that is signed with the signing certificate and profile issued based on the open-source root CA certificate and a key provided by OpenHarmony.
59
60
61## Constraints
62
63- Only the signatures of the AppGallery debug and release applications and OpenHarmony self-signed applications can be verified.
64
65- The signature verification of a debug application is successful only when the device UDID matches the one in the application UDID list contained in the profile.
66