From bb066d00e322cd95ef448603352bdd7d4a481555 Mon Sep 17 00:00:00 2001 From: Annie_wang Date: Fri, 2 Sep 2022 17:30:45 +0800 Subject: [PATCH] update docs Signed-off-by: Annie_wang --- .../security/accesstoken-guidelines.md | 152 ++++++++---------- .../security/accesstoken-overview.md | 4 +- .../security/hapsigntool-guidelines.md | 51 +++--- .../security/hapsigntool-overview.md | 6 +- en/readme/Security.md | 106 ------------ 5 files changed, 98 insertions(+), 221 deletions(-) delete mode 100644 en/readme/Security.md diff --git a/en/application-dev/security/accesstoken-guidelines.md b/en/application-dev/security/accesstoken-guidelines.md index f6ef8fc8ba..34cb80a01e 100644 --- a/en/application-dev/security/accesstoken-guidelines.md +++ b/en/application-dev/security/accesstoken-guidelines.md @@ -1,4 +1,4 @@ -# Access Control Development +# Access Control (Permission) Development ## When to Use @@ -8,7 +8,7 @@ In this example, the app requires the **ohos.permission.PERMISSION1** and **ohos - The level of **ohos.permission.PERMISSION1** is **normal**, and the authorization mode is **system_grant**. - The level of **ohos.permission.PERMISSION2** is **system_basic**, and the authorization mode is **user_grant**. -> **NOTICE** +> **CAUTION** > > In this scenario, the required permissions include a **user_grant** permission. You can check whether the caller has the required permission through permission verification. > @@ -28,48 +28,49 @@ Declare the permissions required by the app one by one in the project configurat Note that the app bundle structure and configuration file vary with the ability framework model. -### FA Model - -For the apps based on the FA model, declare the required permissions in the **config.json** file. - -**Description of config.json** +The following table describes the tags in the configuration file. | Field | Description | | --------- | ------------------------------------------------------------ | | name | Name of the permission. | | reason | Reason for requesting the permission. This field is mandatory for a user_grant permission.| | usedScene | Scenario of the permission. This field is mandatory for a user_grant permission.| -| abilities | Abilities that use the permission. The value is an array.| +| ability | Abilities that use the permission. The value is an array.
**Applicable model**: FA | +| abilities | Abilities that use the permission. The value is an array.
**Applicable model**: stage | | when | Time when the permission is used. The value can be **inuse** (the permission can be used only in the foreground) or **always** (the permission can be used in foreground and background).| +### FA Model + +For the apps based on the FA model, declare the required permissions in the **config.json** file. + **Example** ```json { - "module" : { - "reqPermissions":[ - { - "name" : "ohos.permission.PERMISSION1", - "reason": "$string:reason", - "usedScene": { - "abilities": [ - "FormAbility" - ], - "when":"inuse" - } - }, - { - "name" : "ohos.permission.PERMISSION2", - "reason": "$string:reason", - "usedScene": { - "abilities": [ - "FormAbility" - ], - "when":"always" - } - } - ], - } + "module" : { + "reqPermissions":[ + { + "name" : "ohos.permission.PERMISSION1", + "reason": "$string:reason", + "usedScene": { + "ability": [ + "FormAbility" + ], + "when":"inuse" + } + }, + { + "name" : "ohos.permission.PERMISSION2", + "reason": "$string:reason", + "usedScene": { + "ability": [ + "FormAbility" + ], + "when":"always" + } + } + ] + } } ``` @@ -81,30 +82,30 @@ For the apps based on the stage model, declare the required permissions in the * ```json { - "module" : { - "requestPermissions":[ - { - "name" : "ohos.permission.PERMISSION1", - "reason": "$string:reason", - "usedScene": { + "module" : { + "requestPermissions":[ + { + "name" : "ohos.permission.PERMISSION1", + "reason": "$string:reason", + "usedScene": { "abilities": [ "FormAbility" ], "when":"inuse" - } - }, - { - "name" : "ohos.permission.PERMISSION2", - "reason": "$string:reason", - "usedScene": { - "abilities": [ - "FormAbility" - ], - "when":"always" - } - } - ], - } + } + }, + { + "name" : "ohos.permission.PERMISSION2", + "reason": "$string:reason", + "usedScene": { + "abilities": [ + "FormAbility" + ], + "when":"always" + } + } + ] + } } ``` @@ -112,34 +113,17 @@ For the apps based on the stage model, declare the required permissions in the * The permission level of **ohos.permission.PERMISSION2** is **system_basic**, which is higher than the app's APL. In this case, use the ACL. -In addition to declaring all the permissions in the configuration file, you must declare the permissions whose levels are higher than the app's APL in the app's [profile](../quick-start/app-provision-structure.md). In this example, declare the permission under the **acls** field: +In addition to declaring all the permissions in the configuration file, you must declare the permissions whose levels are higher that the app's APL in the app's profile. For details about the fields in the profile, see [HarmonyAppProvision Configuration File](../quick-start/app-provision-structure.md). + +In this example, declare the permission under the **acls** field: + ```json { - "version-name": "1.0.0", - "version-code": 1, - "app-distribution-type": "os_integration", - "uuid": "5027b99e-5f9e-465d-9508-a9e0134ffe18", - "validity": { - "not-before": 1594865258, - "not-after": 1689473258 - }, - "type": "release", - "bundle-info": { - "developer-id": "OpenHarmony", - "distribution-certificate": "-----BEGIN CERTIFICATE-----\nMIICMzCCAbegAwIBAgIEaOC/zDAMBggqhkjOPQQDAwUAMGMxCzAJBgNVBAYTAkNO\nMRQwEgYDVQQKEwtPcGVuSGFybW9ueTEZMBcGA1UECxMQT3Blbkhhcm1vbnkgVGVh\nbTEjMCEGA1UEAxMaT3Blbkhhcm1vbnkgQXBwbGljYXRpb24gQ0EwHhcNMjEwMjAy\nMTIxOTMxWhcNNDkxMjMxMTIxOTMxWjBoMQswCQYDVQQGEwJDTjEUMBIGA1UEChML\nT3Blbkhhcm1vbnkxGTAXBgNVBAsTEE9wZW5IYXJtb255IFRlYW0xKDAmBgNVBAMT\nH09wZW5IYXJtb255IEFwcGxpY2F0aW9uIFJlbGVhc2UwWTATBgcqhkjOPQIBBggq\nhkjOPQMBBwNCAATbYOCQQpW5fdkYHN45v0X3AHax12jPBdEDosFRIZ1eXmxOYzSG\nJwMfsHhUU90E8lI0TXYZnNmgM1sovubeQqATo1IwUDAfBgNVHSMEGDAWgBTbhrci\nFtULoUu33SV7ufEFfaItRzAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0OBBYEFPtxruhl\ncRBQsJdwcZqLu9oNUVgaMAwGCCqGSM49BAMDBQADaAAwZQIxAJta0PQ2p4DIu/ps\nLMdLCDgQ5UH1l0B4PGhBlMgdi2zf8nk9spazEQI/0XNwpft8QAIwHSuA2WelVi/o\nzAlF08DnbJrOOtOnQq5wHOPlDYB4OtUzOYJk9scotrEnJxJzGsh/\n-----END CERTIFICATE-----\n", - "bundle-name": "com.ohos.permissionmanager", - "apl": "system_core", - "app-feature": "hos_system_app" - }, - "acls": { - "allowed-acls": [ - "ohos.permission.PERMISSION2" - ] - }, - "permissions": { - "restricted-permissions": [] - }, - "issuer": "pki_internal" + "acls": { + "allowed-acls": [ + "ohos.permission.PERMISSION2" + ] + }, } ``` @@ -151,7 +135,7 @@ Therefore, before allowing the app to call the API protected by the **ohos.permi If the verification result indicates that the app has the permission, the app can access the target API. Otherwise, the app needs to request user authorization and then proceeds based on the authorization result. For details, see [Access Control Overview](accesstoken-overview.md). -> **Precautions** +> **CAUTION** > > The permissions authorized by user are not permanent, because the user may revoke the authorization at any time. Therefore, even if the user has granted the requested permission to an app, the app's permission must be verified before the app calls an API protected by the permission. @@ -170,12 +154,12 @@ The procedure is as follows: let array:Array = ["ohos.permission.PERMISSION2"]; // requestPermissionsFromUser determines whether to invoke a pop-up window based on the permission authorization status. context.requestPermissionsFromUser(array).then(function(data) { - console.log("data type:" + typeof(data)); - console.log("data:" + data); - console.log("data permissions:" + data.permissions); - console.log("data result:" + data.authResults); + console.log("data type:" + typeof(data)); + console.log("data:" + data); + console.log("data permissions:" + data.permissions); + console.log("data result:" + data.authResults); }, (err) => { - console.error('Failed to start ability', err.code); + console.error('Failed to start ability', err.code); }); } diff --git a/en/application-dev/security/accesstoken-overview.md b/en/application-dev/security/accesstoken-overview.md index c09791fdd2..e6e764eb45 100644 --- a/en/application-dev/security/accesstoken-overview.md +++ b/en/application-dev/security/accesstoken-overview.md @@ -1,4 +1,4 @@ -# Access Control Overview +# Access Control (Permission) Overview AccessTokenManager (ATM) implements unified app permission management based on access tokens on OpenHarmony. @@ -108,7 +108,7 @@ The permissions open to apps vary with the permission level. The permission leve The system_core permission allows access to core resources of the operating system. These resources are the underlying core services of the system. If these resources are corrupted, the OS cannot run properly. - The permissions of this type are not open to any app currently. + The permissions of this type are not open to third-party apps currently. ## Permission Authorization Modes diff --git a/en/application-dev/security/hapsigntool-guidelines.md b/en/application-dev/security/hapsigntool-guidelines.md index f161b4fc72..26f93af275 100644 --- a/en/application-dev/security/hapsigntool-guidelines.md +++ b/en/application-dev/security/hapsigntool-guidelines.md @@ -65,7 +65,7 @@ The usage of hapsigner varies depending on whether an application signing certif ├── -keyAlias # Key alias. It is mandatory. ├── -keyPwd # Key password. It is optional. ├── -subject # Certificate subject. It is mandatory. - ├── -signAlg # Signature algorithm, which can be SHA256withRSA, SHA384withRSA, SHA256withECDSA, or SHA384withECDSA. It is mandatory. + ├── -signAlg # Signing algorithm, which can be SHA256withRSA, SHA384withRSA, SHA256withECDSA, or SHA384withECDSA. It is mandatory. ├── -keystoreFile # KS file, in JKS or P12 format. It is mandatory. ├── -keystorePwd # KS password. It is optional. ├── -outFile # CSR to generate. It is optional. If you do not specify this parameter, the CSR is output to the console. @@ -84,7 +84,7 @@ The usage of hapsigner varies depending on whether an application signing certif ├── -issuerKeyPwd # Key password of the issuer. It is optional. ├── -subject # Certificate subject. It is mandatory. ├── -validity # Validity period of the certificate. It is optional. The default value is 3650 days. - ├── -signAlg # Signature algorithm, which can be SHA256withRSA, SHA384withRSA, SHA256withECDSA, or SHA384withECDSA. It is mandatory. + ├── -signAlg # Signing algorithm, which can be SHA256withRSA, SHA384withRSA, SHA256withECDSA, or SHA384withECDSA. It is mandatory. ├── -basicConstraintsPathLen # Path length. It is optional. The default value is 0. ├── -keystoreFile # KS file, in JKS or P12 format. It is mandatory. ├── -keystorePwd # KS password. It is optional. @@ -104,7 +104,7 @@ The usage of hapsigner varies depending on whether an application signing certif ├── -issuerKeyPwd # Key password of the issuer. It is optional. ├── -subject # Certificate subject. It is mandatory. ├── -validity # Validity period of the certificate. It is optional. The default value is 3650 days. - ├── -signAlg # Signature algorithm, which can be SHA256withECDSA or SHA384withECDSA. + ├── -signAlg # Signing algorithm, which can be SHA256withECDSA or SHA384withECDSA. ├── -issuerKeystoreFile # KS file of the issuer, in JKS or P12 format. It is optional. ├── -issuerKeystorePwd # KS password of the issuer. It is optional. ├── -keystoreFile # KS file, in JKS or P12 format. It is mandatory. @@ -126,7 +126,7 @@ The usage of hapsigner varies depending on whether an application signing certif ├── -issuerKeyPwd # Key password of the issuer. It is optional. ├── -subject # Certificate subject. It is mandatory. ├── -validity # Validity period of the certificate. It is optional. The default value is 3650 days. - ├── -signAlg # Signature algorithm, which can be SHA256withECDSA or SHA384withECDSA. + ├── -signAlg # Signing algorithm, which can be SHA256withECDSA or SHA384withECDSA. ├── -issuerKeystoreFile # KS file of the issuer, in JKS or P12 format. It is optional. ├── -issuerKeystorePwd # KS password of the issuer. It is optional. ├── -keystoreFile # KS file, in JKS or P12 format. It is mandatory. @@ -145,9 +145,9 @@ The usage of hapsigner varies depending on whether an application signing certif ├── -keyPwd # Key password. It is optional. ├── -issuer # Issuer of the certificate. It is mandatory. ├── -issuerKeyAlias # Key alias of the issuer. It is mandatory. - ├── -issuerKeyPwd # Key password of the issuer. It is optional. - ├── -subject # Certificate subject. It is mandatory. - ├── -validity # Validity period of the certificate. It is optional. The default value is 1095 days. + ├── -issuerKeyPwd # Key password of the issuer. It is optional. + ├── -subject # Certificate subject. It is mandatory. + ├── -validity # Validity period of the certificate. It is optional. The default value is 1095 days. ├── -keyUsage # Usages of the key. It is mandatory. The key usages include digitalSignature, nonRepudiation, keyEncipherment, ├ dataEncipherment, keyAgreement, certificateSignature, crlSignature, ├ encipherOnly, and decipherOnly. Use a comma (,) to separate multiple values. @@ -155,15 +155,15 @@ The usage of hapsigner varies depending on whether an application signing certif ├── -extKeyUsage # Extended key usages. It is optional. The extended key usages include clientAuthentication, serverAuthentication, ├ codeSignature, emailProtection, smartCardLogin, timestamp, and ocspSignature. ├── -extKeyUsageCritical # Whether extKeyUsage is a critical option. It is optional. The default value is false. - ├── -signAlg # Signature algorithm, which can be SHA256withRSA, SHA384withRSA, SHA256withECDSA, or SHA384withECDSA. It is mandatory. + ├── -signAlg # Signing algorithm, which can be SHA256withRSA, SHA384withRSA, SHA256withECDSA, or SHA384withECDSA. It is mandatory. ├── -basicConstraints # Whether basicConstraints is contained. It is optional. The default value is false. ├── -basicConstraintsCritical # Whether basicConstraints is a critical option. It is optional. The default value is false. ├── -basicConstraintsCa # Whether it is CA. It is optional. The default value is false. - ├── -basicConstraintsPathLen # Path length. It is optional. The default value is 0. - ├── -issuerKeystoreFile # KS file of the issuer, in JKS or P12 format. It is optional. - ├── -issuerKeystorePwd # KS password of the issuer. It is optional. - ├── -keystoreFile # KS file, in JKS or P12 format. It is mandatory. - ├── -keystorePwd # KS password. It is optional. + ├── -basicConstraintsPathLen # Path length. It is optional. The default value is 0. + ├── -issuerKeystoreFile # KS file of the issuer, in JKS or P12 format. It is optional. + ├── -issuerKeystorePwd # KS password of the issuer. It is optional. + ├── -keystoreFile # KS file, in JKS or P12 format. It is mandatory. + ├── -keystorePwd # KS password. It is optional. ├── -outFile # Certificate file to generate. It is optional. The file is output to the console if this parameter is not specified. ``` @@ -176,8 +176,8 @@ The usage of hapsigner varies depending on whether an application signing certif ├── -keyPwd # Key password. It is optional. ├── -profileCertFile # Profile signing certificate (certificate chain, in the end-entity certificate, intermediate CA certificate, and root certificate order). It is mandatory. ├── -inFile # Raw profile template in JSON format (developtools_hapsigner/autosign/UnsgnedReleasedProfileTemplate.json). It is mandatory. - ├── -signAlg # Signature algorithm, which can be SHA256withECDSA or SHA384withECDSA. It is mandatory. - ├── -keystoreFile # KS file, in JKS or P12 format. It is mandatory if the signing mode is localSign. + ├── -signAlg # Signing algorithm, which can be SHA256withECDSA or SHA384withECDSA. It is mandatory. + ├── -keystoreFile # KS file, in JKS or P12 format. It is mandatory if the signing mode is localSign. ├── -keystorePwd # KS password. It is optional. ├── -outFile # Signed profile to generate, in p7b format. This parameter is mandatory. ``` @@ -187,23 +187,22 @@ The usage of hapsigner varies depending on whether an application signing certif ``` verify-profile: Verify the profile signature. ├── -inFile # Signed profile in p7b format. This parameter is mandatory. - ├── -outFile # Verification result file (including the verification result and profile content), in json format. It is optional. The file is output to the console if this parameter is not specified. + ├── -outFile # Verification result file (including the verification result and profile content), in json format. It is optional. The file is output to the console if this parameter is not specified. ``` 11. Sign a HAP. - ``` sign-app: Sign a HAP. ├── -mode # Signing mode, which can be localSign, remoteSign, or remoteResign. It is mandatory. ├── -keyAlias # Key alias. It is mandatory. - ├── -keyPwd # Key password. It is optional. + ├── -keyPwd # Key password. It is optional. ├── -appCertFile # Application signing certificate (certificate chain, in the end-entity certificate, intermediate CA certificate, and root certificate order). It is mandatory. ├── -profileFile # Name of the signed profile in p7b format. This parameter is mandatory. ├── -profileSigned # Whether the profile is signed. The value 1 means signed, and value 0 means unsigned. The default value is 1. This parameter is optional. - ├── -inForm # Raw file, in .zip (default) or .bin format. It is optional. + ├── -inForm # Raw file, in .zip (default) or .bin format. It is optional. ├── -inFile # Raw application package, in HAP or .bin format. It is mandatory. - ├── -signAlg # Signature algorithm, which can be SHA256withECDSA or SHA384withECDSA. It is mandatory. + ├── -signAlg # Signing algorithm, which can be SHA256withECDSA or SHA384withECDSA. It is mandatory. ├── -keystoreFile # KS file, in JKS or P12 format. It is mandatory if the signing mode is localSign. ├── -keystorePwd # KS password. It is optional. ├── -outFile # Signed HAP file to generate. It is mandatory. @@ -277,7 +276,7 @@ The process of signing a HAP is as follows: ``` generate-app-cert: Generate an application signing certificate. ├── -keyAlias # Key alias, which must be the same as that in the previous step. - ├── -signAlg # Signature algorithm, which can be SHA256withECDSA or SHA384withECDSA. It is mandatory. + ├── -signAlg # Signing algorithm, which can be SHA256withECDSA or SHA384withECDSA. It is mandatory. ├── -issuer # Issuer of the certificate. Enter the issuer of the intermediate CA certificate. It is mandatory and cannot be changed. ├── -issuerKeyAlias # Key alias of the issuer. Enter the key alias of the intermediate CA certificate. This parameter is mandatory and cannot be changed. ├── -subject # Subject of the certificate. Enter the subject in the same sequence specified in the command. This parameter is mandatory. @@ -307,12 +306,12 @@ The process of signing a HAP is as follows: ``` sign-profile: Sign a profile. ├── -keyAlias # Alias of the key for generating the profile certificate. It is mandatory and cannot be changed. - ├── -signAlg # Signature algorithm, which can be SHA256withECDSA or SHA384withECDSA. It is mandatory. + ├── -signAlg # Signing algorithm, which can be SHA256withECDSA or SHA384withECDSA. It is mandatory. ├── -mode # Signing mode, which must be localSign. It is mandatory. ├── -profileCertFile # Profile signing certificate. Use the certificate provided. It is mandatory and cannot be changed. ├── -inFile # Raw profile template in JSON format (developtools_hapsigner/autosign/UnsgnedReleasedProfileTemplate.json). It is mandatory. ├── -keystoreFile # KS file. Use OpenHarmony.p12. It is mandatory and cannot be changed. - ├── -outFile # Signed profile to generate, in p7b format. This parameter is mandatory. + ├── -outFile # Signed profile to generate, in p7b format. This parameter is mandatory. ├── -keyPwd # Key password. The default key password in OpenHarmony.p12 is 123456. ├── -keystorePwd # KS password. The default key password in OpenHarmony.p12 is 123456. ``` @@ -334,12 +333,12 @@ The process of signing a HAP is as follows: > - **keyPwd**: Enter the key password in the KS file. > - **keystorePwd**: Enter the KS password in the KS file. -The command parameters are described as follows: + The command parameters are described as follows: ``` sign-app: Sign a HAP. ├──-keyAlias # Key alias, which must be the same as the alias of the key pair generated. This parameter is mandatory. - ├── -signAlg # Signature algorithm, which can be SHA256withECDSA or SHA384withECDSA. It is mandatory. + ├── -signAlg # Signing algorithm, which can be SHA256withECDSA or SHA384withECDSA. It is mandatory. ├── -mode # Signing mode, which must be localSign. It is mandatory. ├── -appCertFile # Application signing certificate (certificate chain, in the end-entity certificate, intermediate CA certificate, and root certificate order). Enter the application signing certificate generated in step 2. This parameter is mandatory. ├── -profileFile # Signed profile in p7b format. Enter the profile generated. This parameter is mandatory. @@ -403,7 +402,7 @@ The command parameters are described as follows: - **Possible Causes** - The signature algorithm is not supported. Check the value of **signAlg**. + The signing algorithm is not supported. Check the value of **signAlg**. - **Solution** diff --git a/en/application-dev/security/hapsigntool-overview.md b/en/application-dev/security/hapsigntool-overview.md index a2775eab93..bb91ed70b2 100644 --- a/en/application-dev/security/hapsigntool-overview.md +++ b/en/application-dev/security/hapsigntool-overview.md @@ -1,9 +1,9 @@ # hapsigner Overview -## Introduction - To ensure the integrity and secure source of OpenHarmony applications, the applications must be signed during the build process. Only signed applications can be installed, run, and debugged on real devices. [developtools_hapsigner](https://gitee.com/openharmony/developtools_hapsigner) provides the source code of the OpenHarmony Ability Package (HAP) signing tool - hapsigner. This tool can be used to generate key pairs, certificate signing requests (CSRs), certificates, profile signatures, and HAP signatures. +> **NOTE**
For applications that do not need to apply for permissions using the ACL, DevEco Studio provides an auto signing solution to implement one-click signing of applications or services. For details, see [Having Your App Automatically Signed](https://developer.harmonyos.com/en/docs/documentation/doc-guides/ohos-auto-configuring-signature-information-0000001271659465). + ## Basic Concepts The hapsigner tool is implemented based on the Public Key Infrastructure (PKI). Before using this tool, you should understand the following concepts: @@ -26,7 +26,7 @@ The hapsigner tool is implemented based on the Public Key Infrastructure (PKI). - Profile - HarmonyAppProvision configuration file in a HAP contains information such as the authorized application permissions and device ID. + [HarmonyAppProvision configuration file](../quick-start/app-provision-structure.md) provides information such as the authorized application permissions and device ID. ## Constraints diff --git a/en/readme/Security.md b/en/readme/Security.md deleted file mode 100644 index 64360e70df..0000000000 --- a/en/readme/Security.md +++ /dev/null @@ -1,106 +0,0 @@ -# Security - - -## Introduction - -The security subsystem provides system, data, and application security capabilities to protect system and user data of OpenHarmony. - -It implements application integrity verification, application permission management, device authentication, OpenHarmony Universal KeyStore (HUKS) key management, and data transfer management. - -## Architecture - -**Figure 1** Security subsystem architecture - -![](figures/security_subsustem_architecture.png) - -The security subsystem consists of the following functional modules: - -- Interface layer: provides APIs to developers, some of which are only available for system applications - -- Application permission management: implements permission management for the application framework subsystem and provides APIs for applications to request permissions and query the permission granting status. - -- Application integrity verification: verifies application integrity during application signing and installation. -- Device authentication: provides key agreement and trusted device management capabilities for interconnections between devices in a distributed network. - -- HUKS key management: provides the key management service for basic device authentication. - -- Data transfer management: provides API definitions related to data transfer management and control. - -## Directory Structure - -``` -/base/security -├── appverify # Application integrity verification -├── dataclassification # Data transfer management -├── device_auth # Device authentication -├── huks # HUKS key management -└── permission # Permission management -``` - -## Constraints - -- In the current version, application permission management is available only for local applications. (The stub mode is used for joint commissioning of upper-layer distributed services.) -- Device authentication includes authentication for devices with the same account and peer-to-peer device authentication. Currently, only the latter is available. (The stub mode is used for joint commissioning of upper-layer distributed services.) -- OpenHarmony-specific certificates are used for application integrity verification. The corresponding public key certificates and private keys are preset in the open-source code repositories of OpenHarmony to provide offline signing and verification capabilities for the open-source community. The public key certificates and the corresponding private keys need to be replaced in commercial versions that are based on OpenHarmony. - -## Usage - -#### Application Permission Management - -In OpenHarmony, applications and system services run in independent sandboxes. Both processes and data are isolated from each other to protect the security of application data. However, services or applications running in the sandboxes provide some APIs to implement specific functionalities. To access these APIs across processes, applications in other sandboxes need the required permissions, which are granted and managed based on a permission management mechanism. - -Application permission management provides a mechanism for defining permissions, allowing system services and applications to define new permissions for their sensitive APIs. To access these APIs, other applications need the required permissions. - -Application permission management also allows applications to request permissions that are defined by the system or other applications. Upon obtaining the permissions, applications can access the sensitive APIs provided by the system or other applications. - -In addition, application permission management allows users to view and manage the permission granting status. - -#### Application Integrity Verification - -OpenHarmony allows installation of applications. 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. - -After developing an application and generating the installation package during the application development process, you must sign the installation package to prevent it from being tampered with when released on devices. The OpenHarmony application integrity verification module provides the signature tool, specifications for generating the signing certificate, and required public key certificate for you to sign the application packages. A public key certificate and a corresponding private key are preset in OpenHarmony to easy your operation. You need to replace the public key certificate and private key in your commercial version of OpenHarmony. - -In the application installation process, the OpenHarmony application framework subsystem 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 is successful. During the verification, the application integrity verification module uses the preset public key certificate to verify the signature. - -#### Device Authentication and HUKS - -A unified device binding and authentication solution that covers 1+8+N devices is available. Generally, device authentication provides support for cross-device communication implemented by DSoftBus, rather than directly interacting with applications. Device authentication provides the following functionalities: - -- Building and maintaining unified trust relationship for a group of devices using different accounts - - Devices with different accounts can set up a local trust group after a trust relationship is built by certain means such as scanning a QR code. Services can call APIs to query the group information. - -- Implementing unified device authentication - - A unified authentication solution is provided to discover devices and perform connection authentication and key agreement for encrypted, end-to-end sessions through DSoftBus for the devices in a trust group. - -HUKS provides credentials for device authentication and algorithms for key agreement protocols. - -#### Data Transfer Management - -In OpenHarmony, the data transfer management module provides cross-device data transfer management and control policies for distributed services. The data transfer management module defines a sef of APIs to provide management and control policies for cross-device data transfer and obtain the highest risk level of data to be sent to the peer device. - -## Repositories Involved - -Security subsystem - -[security_dataclassification](https://gitee.com/openharmony/security_dataclassification) - -[security_access_token](https://gitee.com/openharmony/security_access_token) - -[security_huks](https://gitee.com/openharmony/security_huks) - -[security_selinux](https://gitee.com/openharmony/security_selinux) - -[security](https://gitee.com/openharmony/security) - -[security_device_auth](https://gitee.com/openharmony/security_device_auth) - -[security_permission](https://gitee.com/openharmony/security_permission) - -[security_device_security_level](https://gitee.com/openharmony/security_device_security_level) - -[security_appverify](https://gitee.com/openharmony/security_appverify) - -[security_itrustee_ree_lite](https://gitee.com/openharmony/security_itrustee_ree_lite) -- GitLab