未验证 提交 bde21502 编写于 作者: O openharmony_ci 提交者: Gitee

!9225 [翻译完成】#I5MF8C

Merge pull request !9225 from Annie_wang/PR8066
上级 4771f9f8 f9ee3783
master OpenHarmony-3.2-Beta3 OpenHarmony-3.2-Beta4 OpenHarmony-3.2-Beta5 OpenHarmony-3.2-Release OpenHarmony-4.0-Beta1 OpenHarmony-4.0-Beta2 bak_OpenHarmony-4.0-Beta1_20230529 docs-modify monthly_20221018 monthly_20230815 revert-merge-17651-master revert-merge-19334-OpenHarmony-4.0-Beta1 revert-merge-19586-master revert-merge-20613-master revert-merge-21757-OpenHarmony-4.0-Beta2 revert-merge-21765-OpenHarmony-4.0-Beta2 revert-merge-23766-master weekly_20220913 weekly_20220920 weekly_20220927 weekly_20221004 weekly_20221011 weekly_20221018 weekly_20221025 weekly_20221101 weekly_20221108 weekly_20221115 weekly_20221122 weekly_20221129 weekly_20221206 weekly_20221213 weekly_20221220 weekly_20221227 weekly_20230103 weekly_20230110 weekly_20230117 weekly_20230124 weekly_20230131 weekly_20230207 weekly_20230214 weekly_20230221 weekly_20230228 weekly_20230307 weekly_20230314 weekly_20230321 weekly_20230328 weekly_20230404 weekly_20230411 weekly_20230418 weekly_20230425 weekly_20230502 weekly_20230509 weekly_20230516 weekly_20230523 weekly_20230530 weekly_20230606 weekly_20230613 weekly_20230619 weekly_20230626 weekly_20230627 weekly_20230704 weekly_20230712 weekly_20230725 weekly_20230801 weekly_20230808 weekly_20230815 weekly_20230822 weekly_20230829 weekly_20230905 OpenHarmony-v4.0-Beta2 OpenHarmony-v4.0-Beta1 OpenHarmony-v3.2.3-Release OpenHarmony-v3.2.2-Release OpenHarmony-v3.2.1-Release OpenHarmony-v3.2-Release OpenHarmony-v3.2-Beta5 OpenHarmony-v3.2-Beta4 OpenHarmony-v3.2-Beta3
无相关合并请求
......@@ -18,7 +18,7 @@ The Device Security Level Management (DSLM) module is introduced to manage the s
![OpenHarmony system security architecture](figure/ohos_system_security_architecture.png)
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 an 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.
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](figure/ohos_device_security_level.png)
......@@ -44,6 +44,8 @@ The security level of each device in a Super Device provides the decision-making
The default security level of OpenHarmony devices is SL1. Device manufacturers can customize a higher security level based on service requirements. For details, see [Customizing Device Security Levels](#customizing-device-security-levels).
If data processing or hopping fails because the device security level is low during debugging of distributed services, you can temporarily increase the security level of related devices. For details, see [Tool](#tool).
## Development Guidelines
### When to Use
......@@ -53,7 +55,7 @@ When processing or hopping various user data, a subsystem can invoke the APIs pr
### Available APIs
All the APIs are native C interfaces for implementing underlying capabilities and are not open to apps. The APIs are described as follows:
| API| Description|
| 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.|
......@@ -80,21 +82,21 @@ All the APIs are native C interfaces for implementing underlying capabilities an
```cpp
// Obtain the unique device identifier (UDID) of the device of which the security level is to be queried.
const DeviceIdentify *device = GetDestDeviceUdid();
// Obtain the RequestOption.
const RequestOption *option = DEFAULT_OPTION;
// Define a pointer to the device security level obtained.
DeviceSecurityInfo *info = NULL;
// Call RequestDeviceSecurityInfo to obtain the device security level information of the peer device.
int32_t ret = RequestDeviceSecurityInfo(device, DEFAULT_OPTION, &info);
int32_t level = 0;
// Obtain the device security level from the device security level information.
ret = GetDeviceSecurityLevelValue(info, &level);
if (ret == SUCCESS) {
//The level is successfully queried.
// The device security level is obtained.
FreeDeviceSecurityInfo(info);
return;
}
......@@ -241,18 +243,18 @@ eyJ0eXBlIjogImRlYnVnIiwgIm1hbnVmYWN0dXJlIjogIm9ob3MiLCAiYnJhbmQiOiAicmszNTY4Iiwg
The fields in the `payload` are described as follows:
| Field| Description| Mandatory| Value Range|
| :-------------- | :----------------- | :----------- | :-------------------- |
| type | Credential type.| Yes| [debug release] |
| manufacture | Device manufacturer information.| Yes| string [0..128] |
| brand | Device brand.| Yes| string [0..128] |
| model | Device model.| Yes| string [0..128] |
| softwareVersion | Device software version.| Yes| string [0..128] |
| securityLevel | Device security level.| Yes| [SL1 SL2 SL3 SL4 SL5] |
| signTime | Time when the credential was signed.| Yes| string [0..128] |
| version | Credential version.| Yes| string [0..32] |
| sn | Device SN.| No| string [0..128] |
| udid | Device UDID.| No| string [0..128] |
| Field | Description | Mandatory| Value Range |
| :-------------: | :----------------: | :----------: | :-------------------: |
| type | Credential type. | Yes | [debug release] |
| manufacture | Device manufacturer information. | Yes | string [0..128] |
| brand | Device brand. | Yes | string [0..128] |
| model | Device model. | Yes | string [0..128] |
| softwareVersion | Device software version.| Yes | string [0..128] |
| securityLevel | Device security level. | Yes | [SL1 SL2 SL3 SL4 SL5] |
| signTime | Time when the credential was signed. | Yes | string [0..128] |
| version | Credential version. | Yes | string [0..32] |
| sn | Device SN. | No | string [0..128] |
| udid | Device UDID. | No | string [0..128] |
#### 3. Construct the `signature`.
......@@ -267,13 +269,13 @@ Example:
eyJ0eXAiOiAiRFNMIn0=.eyJ0eXBlIjogImRlYnVnIiwgIm1hbnVmYWN0dXJlIjogIm9ob3MiLCAiYnJhbmQiOiAicmszNTY4IiwgIm1vZGVsIjogInJrMzU2OCIsICJzb2Z0d2FyZVZlcnNpb24iOiAiMy4yLjIiLCAic2VjdXJpdHlMZXZlbCI6ICJTTDEiLCAic2lnblRpbWUiOiAiMjAyMjAyMDkxNTAyNTkiLCAidmVyc2lvbiI6ICIxLjAuMSJ9
```
##### 3.2 Generate a private key for signature.
##### 3.2 Generate a private key for signing data.
The Elliptic Curve Digital Signature algorithm (ECDSA) is used to sign the raw data in the credential file. Generate an ECDSA key pair `<ecc-l3-pk>` and `<ecc-l3-sk>` first.
> ![notice](../public_sys-resources/icon-notice.gif)**NOTICE**
>
> This step must be performed in a secure and reliable environment, for example, a cryptographic machine that meets related security requirements, to ensure that the key used for signature is not disclosed.
> This step must be performed in a secure and reliable environment, for example, a cryptographic machine that meets related security requirements, to ensure that the key generated is not disclosed.
##### 3.3 Sign the raw data.
......@@ -385,8 +387,8 @@ The packet for requesting the credential is in the following format:
The fields in the request message are described as follows:
| Field| Description|
| :-------- | :------------------------------------ |
| Field | Description |
| :-------: | :-----------------------------------: |
| message | Message header. The value **1** indicates a request for the device security level credential.|
| payload | Message payload, which is the specific request information.|
| version | Version of the protocol used by the requester.|
......@@ -408,8 +410,8 @@ After receiving the request, the peer device returns a response in the following
```
The fields in the response message are described as follows:
| Field| Description|
| :-------- | :--------------------------------------------------------- |
| Field | Description |
| :-------: | :--------------------------------------------------------: |
| message | Message header. The value **2** indicates a response to the request for the device security level credential.|
| payload | Message payload, which is the specific response information.|
| version | Version of the protocol used by the responder. |
......@@ -430,7 +432,7 @@ You can use the tool as follows:
2. Generate a credential.
For example, to generate a credential file **cred.txt** with the device model of **rk3568**, device version of **3.0.0**, and device security level of **SL3**, run the following command:
For example, to generate a credential file **cred.txt** with the device model of **rk3568**, device version of **3.0.0**, and device security level of **SL3**, run the following command:
``` undefined
./dslm_cred_tool.py create --field-manufacture OHOS --field-brand rk3568 --field-model rk3568 --field-software-version 3.0.0 --field-security-level SL3 --cred-file cred.txt
......@@ -470,6 +472,24 @@ You can use the tool as follows:
verify success!
```
4. Send the generated credential file to the target device and make it take effect.
Temporarily disable write protection.
``` undefined
hdc_std target mount
hdc_std shell "setenforce 0"
```
Send the generated credential file to the device.
``` undefined
hdc_std file send cred.txt /system/etc/dslm_finger.cfg
```
Restart the device to make the new credential file take effect.
``` undefined
hdc_std reboot
```
## FAQs
- Q: How can I use the credential tool in a production environment?
......@@ -480,6 +500,6 @@ You can use the tool as follows:
A: You are advised to use a properly kept private key to sign the credential and use more severe signature verification process instead of the default verification process provided by the DSLM module. For example, allow only the credentials issued by trusted certification authorities (CAs), and bind the credential and device ID to enhance the security.
## References
- Q: The default security level of OpenHarmony devices is SL1. How do I do if the distributed service (distributed file system) fails to process sensitive data due to insufficient permission?
None
A: You can solve the problem by temporarily increasing the security level of the related devices. For details, see [Tool](#tool).
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册
反馈
建议
客服 返回
顶部