An app calls the checkSysIntegrity API of Device Security Kit to obtain the system integrity check result and determine whether the device environment is secure, for example, whether the device environment has been jailbroken or the device is a non-real device.
An app can warn users of security risks, prompt users to exercise caution when performing service operations, or block operations as needed based on check results.
The system integrity check capability is supported on phones, tablets, and PCs/2-in-1 devices. Starting from version 5.1.0(18), it's also supported on wearables.
Each app can call the API for up to 10,000 times per day and five times per minute on each device. A maximum of five concurrent calls are supported on each device.

Process description:
Your app obtains the nonce value.
When calling the checkSysIntegrity API, you must pass a randomly generated nonce value. which will be contained in the check result. You can check the nonce value to verify that the returned result corresponds to your request and does not encounter replay attacks.
A nonce value must contain 16 to 66 bytes and be encoded using Base64.
It is recommended that a new nonce value be randomly generated by the server for each request.
Your app calls the checkSysIntegrity API to send a system integrity check request.
After receiving the request, Device Security Kit collects the system integrity data, sends the data and nonce to the Device Security server for verification, and then returns the verification result to your app through the checkSysIntegrity API.
When your app initiates a service request, your app server verifies the check result of the checkSysIntegrity API.
If the check result is false, you need to check the risk type in detail and determine whether to notify the user based on the risk type and your app's security requirements.
The current solution has combined the server and client to mitigate security risks. However, the checkSysIntegrity API cannot mitigate all security risks.
The system integrity check result can be used as one of the system security proofs. You should consider relevant risks caused by possibly incorrect check results and the impacts to users. You are advised not to use the check result as the only proof to determine whether the current device is secure. It's better to take extra measures to further reduce risks.
To improve user experience when notifying users within the app, consider using friendly messages like:
Your device might be at risk or running in an insecure environment. Please exercise caution when using the XXX feature.
The following table lists the system integrity check API, which is an ArkTS API. For more information about the API, please refer to API Reference.
| API | Description |
|---|---|
| checkSysIntegrity(req: SysIntegrityRequest): Promise<SysIntegrityResponse> | Checks system integrity. |
Import the Device Security Kit module and related public modules.
import { safetyDetect } from '@kit.DeviceSecurityKit';
import { BusinessError } from '@kit.BasicServicesKit';
import { hilog } from '@kit.PerformanceAnalysisKit'; Call the checkSysIntegrity API to obtain the system integrity check result.
This API involves device-cloud synergy and time-consuming operations such as network connection. Therefore, do not execute this API in the UI thread, in order to avoid UI thread blocking.
const TAG = 'SafetyDetectJsTest';
// Request system integrity check and process the result.
let req : safetyDetect.SysIntegrityRequest = {
nonce : 'imEe1PCRcjGkBCAhOCh6ImADztOZ8ygxlWRs' // Random nonce value generated by the server.
};
try {
hilog.info(0x0000, TAG, 'CheckSysIntegrity begin.');
const data: safetyDetect.SysIntegrityResponse = await safetyDetect.checkSysIntegrity(req);
hilog.info(0x0000, TAG, 'Succeeded in checkSysIntegrity: %{public}s', data.result);
// ...
} catch (err) {
let e: BusinessError = err as BusinessError;
hilog.error(0x0000, TAG, 'CheckSysIntegrity failed: %{public}d %{public}s', e.code, e.message);
// ...
} Verify the check result on your app server.
The check result is a JSON Web Signature (JWS) string, which consists of the following parts:
The three parts are encoded using Base64URL and concatenated through dots (.). You can obtain the signature by concatenating the header and payload and then signing the concatenated string using the algorithm specified in the header.
Example
eyAgICAiYW**.**.*Jxse eyAgICAiYW**.**.*JodHxx
For more information about JWS, see JSON Web Signature.
Fields in JWS-format Header are as follows:
{
"alg": "ES256",
"typ":"JWS",
"x5c": ["","",""]
}
alg: signature algorithm name. The value ES256 indicates that ECDSA is used for signature.
typ: The value is always JWS.
x5c: certificate chain used by the Device Security server for JWS signing. The certificate chain contains three levels of certificates: x5c[0] indicates the certificate for JWS signing, x5c[1] indicates the level-2 CA certificate of a Huawei device, and x5c[2] indicates the root CA certificate of a Huawei device.
Fields in JWS-format Payload are as follows:
{
"hapCertificateSha256": "xxx",
"hapBundleName": "xxx",
"appId": "xxx",
"basicIntegrity": false,
"detail": [
"attack",
"jailbreak",
"emulator"
],
"nonce": "xxx",
"timestamp": 1604098577327
}
nonce: nonce string passed when the checkSysIntegrity API is called.
timestamp: timestamp generated by the server.
hapBundleName: your app package name.
hapCertificateSha256: SHA-256 digest of your app's signing certificate.
basicIntegrity: system integrity check result. The value true indicates that the system is integral, and the value false indicates there are risks.
appId: ID of your app.
detail: optional field. When the value of basicIntegrity is false, this field provides the cause of the risk. You can make decisions accordingly based on the risk. The options are as follows:
jailbreak: indicates that the device is jailbroken.
emulator: indicates that the device is a non-real device.
attack: indicates that the device is attacked.
To verify the check result, perform the following steps:
We provide Java sample code for verifying and signing the system integrity check results, which is for app server reference only.
Verify the certificates and signature as instructed in the preceding steps to ensure the integrity of the check result and prevent tampering.