@@ -37,7 +37,7 @@ This environment combines chip security and system security features with upper-
Since some dedicated hardware resources are used for data encryption/decryption, the CPU can concurrently execute other computing tasks, which greatly improves performance and reduces the CPU load. In addition, a well-designed hardware key engine protects keys from leak even if the software is cracked and even defends against electromagnetic and radiation attacks from physical channels.
OpenHarmony devices support the hardware key engine, which allows OpenHarmony to perform computing tasks such as data encryption and decryption, certificate signature verification, and hash value calculation. The hardware key engine supports popular algorithms such as Advanced Encryption Standard (AES) and Rivest-Shamir-Adleman (RSA).
OpenHarmony devices support the hardware key engine, which allows OpenHarmony to perform computing tasks such as data encryption and decryption, certificate signature verification, and hash value calculation. The hardware key engine supports popular algorithms such as Advanced Encryption Standard (AES) and Rivest-Shamir-Adleman (RSA).
### Recommended Practices
...
...
@@ -101,7 +101,7 @@ For device with 128 KB to 128 MB of memory, the OpenHarmony lite kernel is recom
OpenHarmony Universal KeyStore (HUKS) provides key and certificate management. For OpenHarmony, it mainly provides key management for HiChain (device identity authentication platform). The figure below shows the HUKS functions.
**Figure 3** HUKS functions
**Figure 3** HUKS functions
...
...
@@ -141,7 +141,7 @@ To use the device certification function, it is recommended that you use HiChain
## Device Interconnection Security
To ensure secure transmit of user data between devices, a trust relationship and a secure data transmission channel must be established between the devices. The figure below illustrates how an IoT controller and an IoT device establish a trust relationship.
To ensure secure transmit of user data between devices, a trust relationship and a secure data transmission channel must be established between the devices. The following figure shows how an IoT controller and an IoT device establish a trust relationship.
**Figure 4** Process of establishing a trust relationship between devices
...
...
@@ -169,7 +169,7 @@ To ensure secure transmit of user data between devices, a trust relationship and
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.
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
...
...
@@ -186,13 +186,16 @@ To ensure secure transmit of user data between devices, a trust relationship and
After developing and debugging an OpenHarmony application, sign the application installation package using a private key, which matches a public key. Generally, the OEM generates a public/private key pair, presets the public key in the device, and stores the private key on a local server that is not connected to the Internet to prevent private key leakage. After you finish developing an application, you can use an external device (such as a USB flash drive) to upload the installation package to the server where the private key is stored, calculate the signature, and download the signature to the external device. During application installation, the hash value of the bundle is calculated using the SHA-256 algorithm. The hash value, together with the signature and preset public key, is used for authentication. The application can be installed only after the authentication is successful.
In addition, the application source must be verified to ensure that the application is from a valid developer. As a developer, you must apply for a development certificate and use it to sign the application you have developed. During application installation, the upper-level certificate stored on the device is used to verify the signature to ensure validity of the developer.
In addition, the application source must be verified to ensure that the application is from a valid developer. As a developer, you must apply for a development certificate and use it to sign the application you have developed. During application installation, the upper-level certificate stored on the device is used to verify the signature to ensure validity of the developer.
- Application permission control
OpenHarmony allows users to install third-party applications and controls calls made by third-party applications to sensitive permissions. When developing an application, you need to declare the sensitive permissions that the application may require in the **profile.json** file. The permissions can be static or dynamic. Static permissions need to be registered during application installation, and dynamic permissions can be obtained only upon user authorization. Authorization modes include system settings, manual authorization by applications, and others. In addition, application signature control is used to ensure that the application installation package has been confirmed by the device vendor.
OpenHarmony allows users to install third-party applications and controls calls made by third-party applications to sensitive permissions. When developing an application, you need to declare the sensitive permissions that the application may require in the application configuration file. The permissions can be static or dynamic. Static permissions need to be registered during application installation, and dynamic permissions can be obtained only upon user authorization. Authorization modes include system settings, manual authorization by applications, and others. In addition, application signature control is used to ensure that the application installation package has been confirmed by the device vendor.
@@ -207,7 +210,11 @@ To ensure secure transmit of user data between devices, a trust relationship and
| ohos.permission.DISTRIBUTED_DATASYNC | user_grant (dynamic permission)| Allows an application to manage distributed data transmission.|
| ohos.permission.DISTRIBUTED_VIRTUALDEVICE | user_grant (dynamic permission)| Allows an application to use distributed virtualization features.|
### Recommended Practices
When developing an application, determine the permissions required by your application and register the permissions in the **profile.json** file. Sign the application to ensure that the devices on which the application will be installed can verify its integrity and source.
When developing an application, determine the permissions required by your application and register the permissions in the application configuration file. Sign the application to ensure that the devices on which the application will be installed can verify its integrity and source.
> **NOTE**
>
> The application configuration file varies depending on the application model. It is **config.json** for the application based on the FA model and **module.json5** for the application based on the stage mode. For details about the application models, see [Interpretation of the Application Model](../../application-dev/application-models/application-model-description.md).
@@ -10,7 +10,7 @@ The OpenHarmony security subsystem provides security capabilities that make your
- Application permission management
Application permissions determine what system resources and capabilities an application can access. During application development, you need to declare the permissions that the application may require in the profile.json file. Static permissions need to be registered during application installation, while dynamic permissions usually involve sensitive information and need users' dynamic authorization.
Application permissions determine what system resources and capabilities an application can access. During application development, you need to declare the permissions required by the application in the application configuration file. Static permissions need to be registered during application installation, while dynamic permissions usually involve sensitive information and need users' dynamic authorization.
- Inter-process communication (IPC) authentication
OpenHarmony allows users to install third-party applications and controls calls made by third-party applications to sensitive permissions. When developing an app, you need to declare the sensitive permissions that the app requires in the **profile.json** file. The permissions can be static or dynamic. Static permissions are registered during app installation, and dynamic permissions must be authorized by users. Authorization modes include system settings, manual authorization, and others. In addition, app signatures are used to ensure that the app installation packages have been confirmed by device vendors.
OpenHarmony allows users to install third-party applications and controls calls made by third-party applications to sensitive permissions. When developing an application, you need to declare the sensitive permissions required by the application in the application configuration file. The permissions can be static or dynamic. Static permissions are registered during application installation, and dynamic permissions must be authorized by users. Authorization modes include system settings, manual authorization, and others. In addition, application signatures are used to ensure that the application installation packages have been confirmed by device vendors.
| ohos.permission.LISTEN_BUNDLE_CHANGE | system_grant (static permission)| Allows an app to listen for app changes.|
| ohos.permission.GET_BUNDLE_INFO | system_grant (static permission)| Allows an app to obtain information about other apps.|
| ohos.permission.INSTALL_BUNDLE | system_grant (static permission)| Allows an app to install other apps.|
| ohos.permission.CAMERA | user_grant (dynamic permission)| Allows an app to use the camera to take photos and record videos at any time.|
| ohos.permission.MODIFY_AUDIO_SETTINGS | system_grant (static permission)| Allows an app to modify global audio settings, such as the volume and speaker.|
| ohos.permission.READ_MEDIA | user_grant (dynamic permission)| Allows an app to read users' favorite videos.|
| ohos.permission.MICROPHONE | user_grant (dynamic permission)| Allows an app to use the microphone for audio recording at any time.|
| ohos.permission.WRITE_MEDIA | user_grant (dynamic permission)| Allows an app to write users' favorite music.|
| ohos.permission.DISTRIBUTED_DATASYNC | user_grant (dynamic permission)| Allows an app to manage distributed data transmission.|
| ohos.permission.DISTRIBUTED_VIRTUALDEVICE | user_grant (dynamic permission)| Allows an app to use distributed virtualization features.|
| ohos.permission.LISTEN_BUNDLE_CHANGE | system_grant (static permission)| Allows an application to listen for application changes.|
| ohos.permission.GET_BUNDLE_INFO | system_grant (static permission)| Allows an application to obtain information about other applications.|
| ohos.permission.INSTALL_BUNDLE | system_grant (static permission)| Allows an application to install other applications.|
| ohos.permission.CAMERA | user_grant (dynamic permission)| Allows an application to use the camera to take photos and record videos at any time.|
| ohos.permission.MODIFY_AUDIO_SETTINGS | system_grant (static permission)| Allows an application to modify global audio settings, such as the volume and speaker.|
| ohos.permission.READ_MEDIA | user_grant (dynamic permission)| Allows an application to read users' favorite videos.|
| ohos.permission.MICROPHONE | user_grant (dynamic permission)| Allows an application to use the microphone for audio recording at any time.|
| ohos.permission.WRITE_MEDIA | user_grant (dynamic permission)| Allows an application to write users' favorite music.|
| ohos.permission.DISTRIBUTED_DATASYNC | user_grant (dynamic permission)| Allows an application to manage distributed data transmission.|
| ohos.permission.DISTRIBUTED_VIRTUALDEVICE | user_grant (dynamic permission)| Allows an application to use distributed virtualization features.|
> Static permission: a permission granted by the system during app installation. The sensitivity level of this type of permission is **system_grant**.
>
> Dynamic permission: a permission granted by users during app running. The sensitivity level of this type of permission is **user_grant**.
> 1. Static permission is a permission granted by the system during application installation. The sensitivity level of this type of permission is **system_grant**. Dynamic permission is a permission granted by users during application running. The sensitivity level of this type of permission is **user_grant**.
>
> 2. The application configuration file varies depending on the application model. It is **config.json** for the application based on the FA model and **module.json5** for the application based on the stage mode. For details about the application models, see [Interpretation of the Application Model](../../application-dev/application-models/application-model-description.md).
## When to Use
App permissions are required for software to access system resources and use system capabilities. When the functions and data related to user privacy are used, for example, when personal devices, such as cameras and microphones, are used or media files are read or written, OpenHarmony uses the app permission management component to protect the data and capabilities.
App permissions are required for software to access system resources and use system capabilities. When the functions and data related to user privacy are used, for example, when personal devices, such as cameras and microphones, are used or media files are read or written, OpenHarmony uses the application permission management component to protect the data and capabilities.
When developing a system application that requires a sensitive permission, you can call the corresponding API of the app permission management component to check whether the required permission is granted. If the permission is not granted, the app cannot use it.
When developing a system application that requires a sensitive permission, you can call the corresponding API of the application permission management component to check whether the required permission is granted. If the permission is not granted, the application cannot use it.
## Available APIs
The table below lists the APIs available for app permission management. These APIs can be called only by system applications and services.
The table below lists the APIs available for application permission management. These APIs can be called only by system applications and services.
**Table 2** App permission management APIs
| API| Description|
| -------- | -------- |
| int CheckPermission(int uid, const char \*permissionName) | Checks whether the app with the specified UID has the permission to access system service APIs.|
| int CheckSelfPermission(const char \*permissionName) | Checks whether the caller has the permission to access system service APIs.|
| int QueryPermission(const char \*identifier, PermissionSaved \*\*permissions, int \*permNum) | Queries all permissions requested by the app and checks whether the requested permissions have been granted.|
| int GrantPermission(const char \*identifier, const char \*permName) | Grants a permission to the app.|
| int RevokePermission(const char \*identifier, const char \*permName) | Revokes a permission from the app.|
| int GrantRuntimePermission(int uid, const char \*permissionName) | Grants a runtime permission to the app.|
| int RevokeRuntimePermission(int uid, const char \*permissionName) | Revokes a runtime permission from the app.|
| int CheckPermission(int uid, const char \*permissionName) | Checks whether the application with the specified UID has the permission to access system service APIs.|
| int CheckSelfPermission(const char \*permissionName) | Checks whether the caller has the permission to access system service APIs.|
| int QueryPermission(const char \*identifier, PermissionSaved \*\*permissions, int \*permNum) | Queries all permissions requested by the application and checks whether the requested permissions have been granted.|
| int GrantPermission(const char \*identifier, const char \*permName) | Grants a permission to the app.|
| int RevokePermission(const char \*identifier, const char \*permName) | Revokes a permission from the app.|
| int GrantRuntimePermission(int uid, const char \*permissionName) | Grants a runtime permission to the app.|
| int RevokeRuntimePermission(int uid, const char \*permissionName) | Revokes a runtime permission from the app.|
## How to Develop
The following uses the BMS as an example to describe the app permission development. Before you start, declare the required sensitive permissions in the **config.json** file. During app installation, the BMS calls APIs of the app permission management component to check whether the required permissions are available. If yes, the installation proceeds; otherwise, the installation fails.
The following uses the BMS as an example to describe the application permission development. Before you start, declare the required sensitive permissions in the **config.json** file. During application installation, the BMS calls APIs of the application permission management component to check whether the required permissions are available. If yes, the installation proceeds; otherwise, the installation fails.
1. Declare the required permission (**ohos.permission.INSTALL_BUNDLE**) in the **config.json** file.
If the FA model is used, declare the permission in the **config.json** file. The following is an example:
...
...
@@ -135,7 +135,7 @@ The following uses the BMS as an example to describe the app permission developm
}
```
2. When an app is to be installed, the BMS checks whether it has the permission to install the app. For example, the BMS calls **CheckPermission** with **ohos.permission.INSTALL_BUNDLE** as an input parameter. If it has the permission, the installation proceeds; otherwise, the installation fails.
2. When an application is to be installed, the BMS checks whether it has the permission to install the app. For example, the BMS calls **CheckPermission** with **ohos.permission.INSTALL_BUNDLE** as an input parameter. If it has the permission, the installation proceeds; otherwise, the installation fails.
