@@ -18,7 +18,7 @@ The Device Security Level Management (DSLM) module is introduced to manage the s
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.
@@ -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:
| 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.
##### 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.
> 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:
| 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:
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).
