diff --git a/en/device-dev/driver/driver-peripherals-face_auth-des.md b/en/device-dev/driver/driver-peripherals-face_auth-des.md index 5a5cb49ae11f9b76a1c42ed8d0116e05b3b5ffc6..24bfeb387734b384f628919ad9ee473be6ab522f 100644 --- a/en/device-dev/driver/driver-peripherals-face_auth-des.md +++ b/en/device-dev/driver/driver-peripherals-face_auth-des.md @@ -6,7 +6,7 @@ Facial authentication provides user authentication capabilities in identity authentication scenarios, such as device unlocking, payment, and app logins. It uses biometric recognition technologies to identify individuals based on facial characteristics. A camera is used to collect images or video streams that contain human faces, and automatically detect, track, and recognize human faces. Facial authentication is also called facial recognition. The figure below shows the architecture of facial authentication. -The face authentication (Face_auth) driver is developed based on the Hardware Driver Foundation (HDF). It shields hardware differences and provides stable facial authentication capabilities for the user authentication framework (User_auth) and Face_auth service. The facial authentication capabilities include obtaining facial recognition executor list, executor information, and template information by template ID, comparing face image template information of the executor and that of User_auth, enrolling or deleting face image templates, and performing facial authentication. +The face authentication (Face_auth) driver is developed based on the Hardware Driver Foundation (HDF). It shields hardware differences and provides stable facial authentication capabilities for the user authentication framework (User_auth) and Face_auth service. The facial authentication capabilities include obtaining facial recognition executor list, executor information, and template information by template ID, comparing face image template information of the executor and that of User_auth, enrolling or deleting face images, and performing facial authentication. **Figure 1** Facial authentication architecture @@ -21,7 +21,7 @@ The identity authentication consists of User_auth and basic authentication servi - Executor security level - Security level required for the execution environment of an executor. + Security level of the runtime environment when an executor provides capabilities. - Executor role @@ -39,9 +39,9 @@ The identity authentication consists of User_auth and basic authentication servi To ensure user data security and authentication result accuracy, measures must be taken to protect the integrity of the key information exchanged between User_auth and basic authentication services. Public keys must be exchanged when the executor provided by a basic authentication service interworks with User_auth. - The executor uses the User_auth public key to verify scheduling instructions. + The executor uses the User_auth public key to verify scheduling instructions. - User_auth uses the executor public key to verify the authentication result accuracy and the integrity of the information exchanged with the executor. + User_auth uses the executor public key to verify the authentication result accuracy and the integrity of the information exchanged with the executor. - Authentication credential template @@ -51,6 +51,22 @@ The identity authentication consists of User_auth and basic authentication servi User_auth manages the mappings between user identities and credential IDs in a unified manner. When connecting to User_auth, the executor obtains the template ID list from User_auth and updates its template ID list based on the template ID list obtained. +- HAPs + + In a broad sense, OpenHarmony Ability Packages (HAPs) are application packages that can be installed on OpenHarmony. In this document, the HAPs only refer to the upper-layer applications of the Face_auth driver. + +- IDL interface + + An Interface Definition Language (IDL) is a language that lets a program or object written in one language communicate with another program written in an unknown language. An IDL compiler generates client stub files and server framework files. This document describes how to use the client and server generated by the IDL interface to implement communication between the Face_auth service and driver. For details, see [IDL](https://gitee.com/openharmony/ability_idl_tool/blob/master/README.md). + +- IPC + + Inter-Process Communication (IPC) is a mechanism that allows processes to communicate with each other. For details, see [IPC](https://gitee.com/openharmony/communication_ipc/blob/master/README.md). + +- HDI + + The hardware device interface (HDI) is located between the basic system service layer and the device driver layer. It provides APIs for abstracting hardware device functions, which shields underlying hardware device differences for system services. For details, see [HDI Specifications](../../design/hdi-design-specifications.md). + ### Working Principles The Face_auth driver provides basic facial authentication capabilities for the User_auth and Face_auth service to ensure successful facial authentication. @@ -74,19 +90,23 @@ The Face_auth driver provides basic facial authentication capabilities for the U ### Available APIs +The following table describes the C++ APIs generated from the Interface Definition Language (IDL) interface description. For details about the interface declaration, see the .idl file in **/drivers/interface/face_auth/v1_0/**. + +**Table 1** describes the HDI APIs for face credential enrollment, authentication, recognition, and deletion. **Table 2** describes the callbacks used to return the executor operation result to the framework or return the authentication tip information to upper-layer applications. + **Table 1** Available APIs -| API | Description | -| ------------------------------------------------------------ | ------------------------------------------------------------ | -| GetExecutorList(std::vector>& executorList) | Obtains the executor list. | -| GetExecutorInfo(ExecutorInfo& info) | Obtains the executor information, including the executor type, executor role, authentication type, security level, and executor public key.| -| GetTemplateInfo(uint64_t templateId, TemplateInfo& info) | Obtains information about a face image template based on the specified template ID. | +| API | Description | +| ----------------------------------- | ---------------------------------- | +| GetExecutorList(std::vector>& executorList) | Obtains the executor list. | +| GetExecutorInfo(ExecutorInfo& info) | Obtains the executor information, including the executor type, executor role, authentication type, security level, and executor public key.| +| GetTemplateInfo(uint64_t templateId, TemplateInfo& info) | Obtains information about a face image template based on the specified template ID. | | OnRegisterFinish(const std::vector& templateIdList,
const std::vector& frameworkPublicKey, const std::vector& extraInfo) | Obtains the public key and template ID list from User_auth after the executor is registered successfully.| -| Enroll(uint64_t scheduleId, const std::vector& extraInfo,
const sptr& callbackObj) | Enrolls a face image template. | -| Authenticate(uint64_t scheduleId, const std::vector& templateIdList,
const std::vector& extraInfo, const sptr& callbackObj) | Performs facial authentication. | +| Enroll(uint64_t scheduleId, const std::vector& extraInfo,
const sptr& callbackObj) | Enrolls a face image. | +| Authenticate(uint64_t scheduleId, const std::vector& templateIdList,
const std::vector& extraInfo, const sptr& callbackObj) | Performs facial authentication. | | Identify(uint64_t scheduleId, const std::vector& extraInfo,
const sptr& callbackObj) | Performs facial identification. | -| Delete(const std::vector& templateIdList) | Deletes a face image template. | -| Cancel(uint64_t scheduleId) | Cancels a face enrolling, authentication, or identification operation based on the **scheduleId**. | +| Delete(const std::vector& templateIdList) | Deletes a face image. | +| Cancel(uint64_t scheduleId) | Cancels a face enrollment, authentication, or identification operation based on the **scheduleId**. | | SendCommand(int32_t commandId, const std::vector& extraInfo,
const sptr& callbackObj) | Sends commands to the Face_auth service. | **Table 2** Callbacks @@ -102,15 +122,15 @@ The following uses the Hi3516D V300 development board as an example to demonstra ```undefined // drivers/peripheral/face_auth -├── BUILD.gn # Build script -├── bundle.json # Module description file -└── hdi_service # Face_auth driver implementation - ├── BUILD.gn # Build script - ├── include # Header files - └── src - ├── executor_impl.cpp # Implementation of authentication and enrollment APIs - ├── face_auth_interface_driver.cpp # Face_auth driver entry - └── face_auth_interface_service.cpp # Implementation of the APIs for obtaining the executor list +├── BUILD.gn # Build script +├── bundle.json # Component description file +└── hdi_service # Face_auth driver implementation + ├── BUILD.gn # Build script + ├── include # Header files + └── src # Source files + ├── executor_impl.cpp # Implementation of authentication and enrollment APIs + ├── face_auth_interface_driver.cpp # Face_auth driver entry + └── face_auth_interface_service.cpp # Implementation of the APIs for obtaining the executor list ``` The development procedure is as follows: @@ -214,7 +234,7 @@ The development procedure is as follows: HDF_INIT(g_faceAuthInterfaceDriverEntry); ``` -2. Implement the API for obtaining the executor list. For details about the code, see [face_auth_interface_service.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/face_auth/hdi_service/src/face_auth_interface_service.cpp). +2. Implement the APIs for obtaining the executor list. For details about the code, see [face_auth_interface_service.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/face_auth/hdi_service/src/face_auth_interface_service.cpp). ```c++ // Executor implementation class @@ -267,7 +287,7 @@ The development procedure is as follows: } ``` -3. Implement each function of the executor. For details about the code, see [executor_impl.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/face_auth/hdi_service/src/executor_impl.cpp). +3. Implement the functions of the executor. For details about the code, see [executor_impl.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/face_auth/hdi_service/src/executor_impl.cpp). ```c++ // Obtain the executor information. @@ -423,65 +443,59 @@ The development procedure is as follows: Use the [User Authentication APIs](../../application-dev/reference/apis/js-apis-useriam-userauth.md) to develop a JavaScript application and verify the application on the Hi3516D V300 development board. The sample code for verifying and canceling the authentication is as follows: -```js -// API version 8 -import userIAM_userAuth from '@ohos.userIAM.userAuth'; -let auth = new userIAM_userAuth.UserAuth(); - -export default { - getVersion() { - console.info("start to get version"); - let version = this.auth.getVersion(); - console.info("auth version = " + version); - }, - - startAuth() { - console.info("start auth"); - this.auth.auth(null, userIAM_userAuth.UserAuthType.FACE, userIAM_userAuth.AuthTrustLevel.ATL1, { - onResult: (result, extraInfo) => { - try { - console.info("auth onResult result = " + result); - console.info("auth onResult extraInfo = " + JSON.stringify(extraInfo)); - if (result == userIAM_userAuth.ResultCode.SUCCESS) { - // Add the logic to be executed when the authentication is successful. - } else { - // Add the logic to be executed when the authentication fails. - } - } catch (e) { - console.info("auth onResult error = " + e); - } - }, - - onAcquireInfo: (module, acquire, extraInfo) => { - try { - console.info("auth onAcquireInfo module = " + module); - console.info("auth onAcquireInfo acquire = " + acquire); - console.info("auth onAcquireInfo extraInfo = " + JSON.stringify(extraInfo)); - } catch (e) { - console.info("auth onAcquireInfo error = " + e); - } - } - }); - }, - - cancelAuth() { - console.info("start cancel auth"); - // Obtain contextId using auth(). - let contextId = auth.auth(null, userIAM_userAuth.UserAuthType.FACE, userIAM_userAuth.AuthTrustLevel.ATL1, { - onResult: (result, extraInfo) => { - console.info("auth onResult result = " + result); - }, - - onAcquireInfo: (module, acquire, extraInfo) => { - console.info("auth onAcquireInfo module = " + module); + ```js + // API version 9 + import userIAM_userAuth from '@ohos.userIAM.userAuth'; + + let challenge = new Uint8Array([1, 2, 3, 4, 5, 6, 7, 8]); + let authType = userIAM_userAuth.UserAuthType.FACE; + let authTrustLevel = userIAM_userAuth.AuthTrustLevel.ATL1; + + // Obtain an authentication object. + let auth; + try { + auth = userIAM_userAuth.getAuthInstance(challenge, authType, authTrustLevel); + console.log("get auth instance success"); + } catch (error) { + console.log("get auth instance failed" + error); + } + + // Subscribe to the authentication result. + try { + auth.on("result", { + callback: (result: userIAM_userAuth.AuthResultInfo) => { + console.log("authV9 result " + result.result); + console.log("authV9 token " + result.token); + console.log("authV9 remainAttempts " + result.remainAttempts); + console.log("authV9 lockoutDuration " + result.lockoutDuration); } }); - let cancelCode = this.auth.cancel(contextId); - if (cancelCode == userIAM_userAuth.ResultCode.SUCCESS) { - console.info("Authentication canceled successfully"); - } else { - console.error("failed to cancel authentication"); - } + console.log("subscribe authentication event success"); + } catch (error) { + console.log("subscribe authentication event failed " + error); } -} -``` + + // Start user authentication. + try { + auth.start(); + console.info("authV9 start auth success"); + } catch (error) { + console.info("authV9 start auth failed, error = " + error); + } + + // Cancel the authentication. + try { + auth.cancel(); + console.info("Authentication canceled successfully"); + } catch (error) { + console.info("cancel auth failed, error = " + error); + } + + // Unsubscribe from the authentication result. + try { + auth.off("result"); + console.info("cancel subscribe authentication event success"); + } catch (error) { + console.info("cancel subscribe authentication event failed, error = " + error); + } + ``` diff --git a/en/device-dev/driver/driver-peripherals-fingerprint_auth-des.md b/en/device-dev/driver/driver-peripherals-fingerprint_auth-des.md index 7c4584ce78b4a0cd6f864de75971663d6e244a37..4c9edd59dcd6c549cfa97b8e38daa8f8dee98ab3 100644 --- a/en/device-dev/driver/driver-peripherals-fingerprint_auth-des.md +++ b/en/device-dev/driver/driver-peripherals-fingerprint_auth-des.md @@ -21,7 +21,7 @@ The identity authentication consists of the User_auth framework and basic authen - Executor security level - Security level required for the execution environment of an executor. + Security level of the runtime environment when an executor provides capabilities. - Executor role @@ -39,9 +39,9 @@ The identity authentication consists of the User_auth framework and basic authen To ensure user data security and authentication result accuracy, measures must be taken to protect the integrity of the key information exchanged between User_auth and basic authentication services. Public keys must be exchanged when the executor provided by a basic authentication service interworks with User_auth. - The executor uses the User_auth public key to verify scheduling instructions. + The executor uses the User_auth public key to verify scheduling instructions. - User_auth uses the executor public key to verify the authentication result accuracy and the integrity of the information exchanged with the executor. + User_auth uses the executor public key to verify the authentication result accuracy and the integrity of the information exchanged with the executor. - Authentication credential @@ -53,23 +53,23 @@ The identity authentication consists of the User_auth framework and basic authen - HAPs - OpenHarmony Ability Packages (HAPs) represent the upper-layer applications of the Fingerprint_auth driver in this document. + In a broad sense, OpenHarmony Ability Packages (HAPs) are application packages that can be installed on OpenHarmony. In this document, the HAPs only refer to the upper-layer applications of the Face_auth driver. - IDL interface - An Interface Definition Language (IDL) is a language that lets a program or object written in one language communicate with another program written in an unknown language. An IDL compiler generates client stub files and server framework files. In this document, the IDL interface implements communication between the Fingerprint_auth service and the driver. + An Interface Definition Language (IDL) is a language that lets a program or object written in one language communicate with another program written in an unknown language. An IDL compiler generates client stub files and server framework files. This document describes how to use the client and server generated by the IDL interface to implement communication between the Fingerprint_auth service and driver. For details, see [IDL](https://gitee.com/openharmony/ability_idl_tool/blob/master/README.md). - IPC - Inter-Process Communication (IPC) is a mechanism that allows processes to communicate with each other. + Inter-Process Communication (IPC) is a mechanism that allows processes to communicate with each other. For details, see [IPC](https://gitee.com/openharmony/communication_ipc/blob/master/README.md). -### Working Principles +- HDI -The fingerprint_auth driver provides stable basic fingerprint authentication capabilities for the upper-layer User_auth framework and Fingerprint_auth service to ensure successful fingerprint authentication on devices. + The hardware device interface (HDI) is located between the basic system service layer and the device driver layer. It provides APIs for abstracting hardware device functions, which shields underlying hardware device differences for system services. For details, see [HDI Specifications](../../design/hdi-design-specifications.md). -The figure below shows the interaction between the Fingerprint_auth service and the Fingerprint_auth driver. +### Working Principles -The Fingerprint_auth service obtains the executor information by using **GetExecutorInfo()** and registers the executor with the User_auth framework. The Fingerprint_auth service exchanges information with the Fingerprint_auth driver for authentication, identification, and query through the executor APIs. +The fingerprint_auth driver provides stable basic fingerprint authentication capabilities for the upper-layer User_auth framework and Fingerprint_auth service to ensure successful fingerprint authentication on devices. The figure below shows the interaction between the Fingerprint_auth service and the Fingerprint_auth driver. The Fingerprint_auth service obtains executor information by using **GetExecutorInfo()** and registers the executor with the User_auth framework. The Fingerprint_auth service exchanges information with the Fingerprint_auth driver for authentication, identification, and query through the executor APIs. You can develop drivers to call Hardware Device Interface (HDI) APIs based on the HDF and the chip you use. **Figure 2** Interaction between the Fingerprint_auth service and Fingerprint_auth driver @@ -88,19 +88,22 @@ The fingerprint_auth driver provides stable basic fingerprint authentication cap ### Available APIs +The following table describes the C++ APIs generated from the Interface Definition Language (IDL) interface description. For details about the interface declaration, see the .idl file in **/drivers/interface/fingerprint_auth/v1_0/**. +**Table 1** describes the HDI APIs for fingerprint credential enrollment, authentication, recognition, and deletion. **Table 2** describes the callbacks used to return the executor operation result to the framework or return the authentication tip information to upper-layer applications. + **Table 1** Available APIs -| API | Description | -| ------------------------------------------------------------ | ------------------------------------------------------------ | -| GetExecutorList(std::vector>& executorList) | Obtains the executor list. | +| API | Description | +| -------------------------------- | ----------------------------------- | +| GetExecutorList(std::vector>& executorList) | Obtains the executor list. | | GetExecutorInfo(ExecutorInfo& info) | Obtains the executor information, including the executor type, executor role, authentication type, security level, and executor public key.| -| GetTemplateInfo(uint64_t templateId, TemplateInfo& info) | Obtains information about the template based on the specified ID. | +| GetTemplateInfo(uint64_t templateId, TemplateInfo& info) | Obtains information about the template based on the specified ID. | | OnRegisterFinish(const std::vector& templateIdList,
const std::vector& frameworkPublicKey, const std::vector& extraInfo) | Obtains the public key and template ID list from User_auth after the executor is registered successfully.| -| Enroll(uint64_t scheduleId, const std::vector& extraInfo,
const sptr& callbackObj) | Enrolls a fingerprint template. | -| Authenticate(uint64_t scheduleId, const std::vector& templateIdList,
const std::vector& extraInfo, const sptr& callbackObj) | Authenticates a fingerprint template. | -| Identify(uint64_t scheduleId, const std::vector& extraInfo,
const sptr& callbackObj) | Identifies a fingerprint template. | -| Delete(const std::vector& templateIdList) | Deletes a fingerprint template. | -| Cancel(uint64_t scheduleId) | Cancels a fingerprint enrolling, authentication, or identification operation based on the **scheduleId**. | +| Enroll(uint64_t scheduleId, const std::vector& extraInfo,
const sptr& callbackObj) | Enrolls a fingerprint. | +| Authenticate(uint64_t scheduleId, const std::vector& templateIdList,
const std::vector& extraInfo, const sptr& callbackObj) | Authenticates a fingerprint. | +| Identify(uint64_t scheduleId, const std::vector& extraInfo,
const sptr& callbackObj) | Identifies a fingerprint. | +| Delete(const std::vector& templateIdList) | Deletes a fingerprint. | +| Cancel(uint64_t scheduleId) | Cancels a fingerprint enrollment, authentication, or identification operation based on the **scheduleId**. | | SendCommand(int32_t commandId, const std::vector& extraInfo,
const sptr& callbackObj) | Sends commands to the Fingerprint_auth driver. | **Table 2** Callbacks @@ -116,12 +119,12 @@ The following uses the Hi3516D V300 development board as an example to demonstra ```undefined // drivers/peripheral/fingerprint_auth -├── BUILD.gn # Build script -├── bundle.json # Module description file -└── hdi_service # Fingerprint_auth driver implementation - ├── BUILD.gn # Build script - ├── include # Header files - └── src +├── BUILD.gn # Build script +├── bundle.json # Component description file +└── hdi_service # Fingerprint_auth driver implementation + ├── BUILD.gn # Build script + ├── include # Header files + └── src # Source files ├── executor_impl.cpp # Implementation of authentication and enrollment APIs ├── fingerprint_auth_interface_driver.cpp # Fingerprint_auth driver entry └── fingerprint_auth_interface_service.cpp # Implementation of the API for obtaining the executor list @@ -281,7 +284,7 @@ The development procedure is as follows: } ``` -3. Implement each function of the executor. For details about the code, see [executor_impl.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/fingerprint_auth/hdi_service/src/executor_impl.cpp).
The sample code is as follows: +3. Implement functions of the executor. For details about the code, see [executor_impl.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/fingerprint_auth/hdi_service/src/executor_impl.cpp).
The sample code is as follows: ```c++ // Obtain the executor information. @@ -364,7 +367,7 @@ The development procedure is as follows: return HDF_SUCCESS; } - // Delete a fingerprint template. + // Delete fingerprints. int32_t Delete(const std::vector& templateIdList) { IAM_LOGI("interface mock start"); @@ -435,50 +438,61 @@ The development procedure is as follows: ### Verification -Use the [User Authentication APIs](../../application-dev/reference/apis/js-apis-useriam-userauth.md) to develop a JavaScript application and verify the application on the Hi3516D V300 development board. The JavaScript application invokes the Fingerprint_auth driver via the Fingerprint_auth service. - -The sample code is as follows: - -```js -// API version 8 -import userIAM_userAuth from '@ohos.userIAM.userAuth'; -let auth = new userIAM_userAuth.UserAuth(); - -export default { - getVersion() { - console.info("start to get version"); - let version = this.auth.getVersion(); - console.info("auth version = " + version); - }, - - startAuth() { - console.info("start auth"); - // auth is an API that can be called. You can set the authentication type to FINGERPRINT to check whether the driver is successfully registered with the framework and whether the authentication APIs are implemented as expected. result holds the authentication result. - this.auth.auth(null, userIAM_userAuth.UserAuthType.FINGERPRINT, userIAM_userAuth.AuthTrustLevel.ATL1, { - onResult: (result, extraInfo) => { - try { - console.info("auth onResult result = " + result); - console.info("auth onResult extraInfo = " + JSON.stringify(extraInfo)); - if (result == userIAM_userAuth.ResultCode.SUCCESS) { - // Add the logic to be executed when the authentication is successful. - } else { - // Add the logic to be executed when the authentication fails. - } - } catch (e) { - console.info("auth onResult error = " + e); - } - }, - - onAcquireInfo: (module, acquire, extraInfo) => { - try { - console.info("auth onAcquireInfo module = " + module); - console.info("auth onAcquireInfo acquire = " + acquire); - console.info("auth onAcquireInfo extraInfo = " + JSON.stringify(extraInfo)); - } catch (e) { - console.info("auth onAcquireInfo error = " + e); - } +Use the [User Authentication APIs](../../application-dev/reference/apis/js-apis-useriam-userauth.md) to develop a JavaScript application and verify the application on the Hi3516D V300 development board. The JavaScript application invokes the Fingerprint_auth driver via the Fingerprint_auth service. The sample code is as follows: + + ```js + // API version 9 + import userIAM_userAuth from '@ohos.userIAM.userAuth'; + + let challenge = new Uint8Array([1, 2, 3, 4, 5, 6, 7, 8]); + let authType = userIAM_userAuth.UserAuthType.FINGERPRINT; + let authTrustLevel = userIAM_userAuth.AuthTrustLevel.ATL1; + + // Obtain an authentication object. + let auth; + try { + auth = userIAM_userAuth.getAuthInstance(challenge, authType, authTrustLevel); + console.log("get auth instance success"); + } catch (error) { + console.log("get auth instance failed" + error); + } + + // Subscribe to the authentication result. + try { + auth.on("result", { + callback: (result: userIAM_userAuth.AuthResultInfo) => { + console.log("authV9 result " + result.result); + console.log("authV9 token " + result.token); + console.log("authV9 remainAttempts " + result.remainAttempts); + console.log("authV9 lockoutDuration " + result.lockoutDuration); } }); + console.log("subscribe authentication event success"); + } catch (error) { + console.log("subscribe authentication event failed " + error); } -} -``` + + // Start user authentication. + try { + auth.start(); + console.info("authV9 start auth success"); + } catch (error) { + console.info("authV9 start auth failed, error = " + error); + } + + // Cancel the authentication. + try { + auth.cancel(); + console.info("cancel auth success"); + } catch (error) { + console.info("cancel auth failed, error = " + error); + } + + // Unsubscribe from the authentication result. + try { + auth.off("result"); + console.info("cancel subscribe authentication event success"); + } catch (error) { + console.info("cancel subscribe authentication event failed, error = " + error); + } + ``` diff --git a/en/device-dev/driver/driver-peripherals-pinauth-des.md b/en/device-dev/driver/driver-peripherals-pinauth-des.md index be9d7cfecc7a6381a97a3e85041994d7eca6a480..455633e413003a2bc829ca9a27e2812349149dc7 100644 --- a/en/device-dev/driver/driver-peripherals-pinauth-des.md +++ b/en/device-dev/driver/driver-peripherals-pinauth-des.md @@ -21,7 +21,7 @@ The identity authentication consists of User_auth and basic authentication servi - Executor security level - Security level required for the execution environment of an executor. + Security level of the runtime environment when an executor provides capabilities. - Executor role @@ -52,6 +52,18 @@ The identity authentication consists of User_auth and basic authentication servi User_auth manages the mappings between user identities and credential IDs in a unified manner. When connecting to User_auth, the executor obtains the template ID list from User_auth and updates its template ID list based on the template ID list obtained. +- IDL interface + + An Interface Definition Language (IDL) is a language that lets a program or object written in one language communicate with another program written in an unknown language. An IDL compiler generates client stub files and server framework files. This document describes how to use the client and server generated by the IDL interface to implement communication between the Pin_auth service and driver. For details, see [IDL](https://gitee.com/openharmony/ability_idl_tool/blob/master/README.md). + +- IPC + + Inter-Process Communication (IPC) is a mechanism that allows processes to communicate with each other. For details, see [IPC](https://gitee.com/openharmony/communication_ipc/blob/master/README.md). + +- HDI + + The hardware device interface (HDI) is located between the basic system service layer and the device driver layer. It provides APIs for abstracting hardware device functions, which shields underlying hardware device differences for system services. For details, see [HDI Specifications](../../design/hdi-design-specifications.md). + ### Working Principles The Pin_auth driver provides basic PIN authentication capabilities for the upper-layer User_auth and Pin_auth service to ensure successful PIN authentication. You can develop drivers to call Hardware Device Interface (HDI) APIs based on the HDF and the chip you use. @@ -61,7 +73,8 @@ The Pin_auth driver provides basic PIN authentication capabilities for the upper ![image](figures/pin_auth_service_and_driver_interaction.png "interaction between the pin_auth service and driver") ### Constraints -PIN authentication must be implemented in a Trusted Execution Environment (TEE), and the confidential information, such as PINs and credentials, must be stored in a TEE. +PIN authentication must be implemented in a Trusted Execution Environment (TEE), and the confidential information, such as PINs and credentials, must be encrypted and stored in a TEE. + ## Development Guidelines ### When to Use @@ -69,20 +82,23 @@ The Pin_auth driver provides basic PIN authentication capabilities for the User_ ### Available APIs +The following table describes the C++ APIs generated from the Interface Definition Language (IDL) interface description. For details about the interface declaration, see the .idl file in **/drivers/interface/pin_auth/v1_0/**. +**Table 1** describes the HDI APIs for PIN credential enrollment, authentication, and deletion. **Table 2** describes the callbacks used to return the executor operation result to the framework or return the PIN entered by the user. + **Table 1** Available APIs -| API | Description | -| ------------------------------------------------------------ | ------------------------------------------------------------ | -| GetExecutorList(std::vector>& executorList) | Obtains the executor list. | -| GetExecutorInfo(ExecutorInfo& info) | Obtains information about an executor. | -| GetTemplateInfo(uint64_t templateId, TemplateInfo& info) | Obtains information about a template. | +| API | Description | +| ------------------------------- | ------------------------------------------- | +| GetExecutorList(std::vector>& executorList) | Obtains the executor list.| +| GetExecutorInfo(ExecutorInfo& info) | Obtains information about an executor. | +| GetTemplateInfo(uint64_t templateId, TemplateInfo& info) | Obtains information about a template. | | OnRegisterFinish(const std::vector& templateIdList,
const std::vector& frameworkPublicKey,
const std::vector& extraInfo) | Obtains the public key and template ID list from User_auth after the executor is registered successfully.| -| OnSetData(uint64_t scheduleId, uint64_t authSubType,
const std::vector &data) | Called to return the subtype and anonymized data of PIN authentication. | -| Enroll(uint64_t scheduleId, const std::vector& extraInfo,
const sptr& callbackObj) | Enrolls a PIN. | -| Authenticate(uint64_t scheduleId, uint64_t templateId, const std::vector& extraInfo, const sptr& callbackObj) | Starts PIN authentication. | -| Delete(uint64_t templateId) | Deletes a PIN template. | -| Cancel(uint64_t scheduleId) | Cancels an operation. | -| SendCommand(int32_t commandId, const std::vector& extraInfo,
const sptr& callbackObj) | Reserved. | +| OnSetData(uint64_t scheduleId, uint64_t authSubType,
const std::vector &data) | Called to return the subtype of the PIN enrolled by the user and the anonymization PIN data. | +| Enroll(uint64_t scheduleId, const std::vector& extraInfo,
const sptr& callbackObj) | Enrolls a PIN. | +| Authenticate(uint64_t scheduleId, uint64_t templateId, const std::vector& extraInfo, const sptr& callbackObj) | Starts PIN authentication. | +| Delete(uint64_t templateId) | Deletes a PIN template. | +| Cancel(uint64_t scheduleId) | Cancels an operation. | +| SendCommand(int32_t commandId, const std::vector& extraInfo,
const sptr& callbackObj) | Reserved. | **Table 2** Callbacks @@ -93,27 +109,25 @@ The Pin_auth driver provides basic PIN authentication capabilities for the User_ ### How to Develop -The following uses the RK3568 platform as an example to demonstrate how to develop the Pin_auth driver. - -The directory structure is as follows: +The following uses the RK3568 platform as an example to demonstrate how to develop the Pin_auth driver.
The directory structure is as follows: ```text // drivers/peripheral/pin_auth -├── BUILD.gn # Build script -├── bundle.json # Module description file -├── test # Test cases -└── hdi_service # Pin_auth driver implementation - ├── BUILD.gn # Build script - ├── adaptor # Implementation of related algorithms - ├── common # Implementation of common interfaces - ├── database # Database implementation - ├── main # Entry for implementing PIN-related functions - └── service # Entry for implementing the Pin_auth driver - ├── inc # Header files - └── src - ├── executor_impl.cpp # Implementation of authentication and enrollment APIs - ├── pin_auth_interface_driver.cpp # Pin_auth driver entry - └── pin_auth_interface_service.cpp # Implementation of the APIs for obtaining the executor list +├── BUILD.gn # Build script +├── bundle.json # Component description file +├── test # Test cases +└── hdi_service # Pin_auth driver implementation + ├── BUILD.gn # Build script + ├── adaptor # Implementation of related algorithms + ├── common # Implementation of common interfaces + ├── database # Database implementation + ├── main # Entry for implementing PIN-related functions + └── service # Entry for implementing the Pin_auth driver + ├── inc # Header files + └── src # Source files + ├── executor_impl.cpp # Implementation of authentication and enrollment APIs + ├── pin_auth_interface_driver.cpp # Pin_auth driver entry + └── pin_auth_interface_service.cpp # Implementation of the APIs for obtaining the executor list ``` The development procedure is as follows: @@ -293,7 +307,7 @@ The development procedure is as follows: -1. Implement each function of the executor. For details about the code, see [executor_impl.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/pin_auth/hdi_service/service/src/executor_impl.cpp). +1. Implement functions of the executor. For details about the code, see [executor_impl.cpp](https://gitee.com/openharmony/drivers_peripheral/blob/master/pin_auth/hdi_service/service/src/executor_impl.cpp). ```c++ // Obtain executor information (example only). @@ -535,7 +549,7 @@ The development procedure is as follows: Verify whether PIN authentication can be successfully performed on the RK3568 platform as follows: 1. Set a PIN. - + Touch **Settings** > **Biometrics & passwords** > **Password**, and enter your password. 2. Verify PIN authentication. diff --git a/en/device-dev/driver/driver-peripherals-user-auth-des.md b/en/device-dev/driver/driver-peripherals-user-auth-des.md index 757e98ede25199d9486e5f7bfaf3eb67f48bee3a..160d121393b3ec6c57b0ae2981dba873b222df0b 100644 --- a/en/device-dev/driver/driver-peripherals-user-auth-des.md +++ b/en/device-dev/driver/driver-peripherals-user-auth-des.md @@ -21,7 +21,7 @@ The identity authentication consists of the User_auth framework and basic authen - Authentication credential template - The authentication credential template is generated and stored by the authentication service when a user sets the authentication credential. The template information needs to be compared with the authentication data generated during authentication to complete identity authentication. Each template has an ID to index a set of template information files. + The authentication credential template is generated and stored by the authentication service when a user sets the authentication credential. Each template has an ID to index a set of template information files. The template information needs to be compared with the authentication data generated during authentication to complete identity authentication. - Executor @@ -29,11 +29,11 @@ The identity authentication consists of the User_auth framework and basic authen - Executor role - - ​ Executor: independently completes the entire process of credential registration and identity authentication. The executor can collect, process, store, and compare data to complete the authentication. + - Executor: independently completes the entire process of credential registration and identity authentication. The executor can collect, process, store, and compare data to complete the authentication. - - ​ Collector: only collects data during user authentication. It needs to work with the authenticator to complete user authentication. + - Collector: only collects data during user authentication. It needs to work with the authenticator to complete user authentication. - - ​ Authenticator: processes data, obtains the stored credential template, and compares it with the authentication information generated. + - Authenticator: processes data, obtains the stored credential template, and compares it with the authentication information generated. - Executor type @@ -41,7 +41,7 @@ The identity authentication consists of the User_auth framework and basic authen - Executor security level - Security level required for the execution environment of an executor. + Security level of the runtime environment when an executor provides capabilities. - User_auth public key & executor public key @@ -76,6 +76,18 @@ The identity authentication consists of the User_auth framework and basic authen Inner API is an API provided by OpenHarmony for system applications. +- IDL interface + + An Interface Definition Language (IDL) is a language that lets a program or object written in one language communicate with another program written in an unknown language. An IDL compiler generates client stub files and server framework files. This document describes how to use the client and server generated by the IDL interface to implement communication between the User_auth service and driver. For details, see [IDL](https://gitee.com/openharmony/ability_idl_tool/blob/master/README.md). + +- IPC + + Inter-Process Communication (IPC) is a mechanism that allows processes to communicate with each other. For details, see [IPC](https://gitee.com/openharmony/communication_ipc/blob/master/README.md). + +- HDI + + The hardware device interface (HDI) is located between the basic system service layer and the device driver layer. It provides APIs for abstracting hardware device functions, which shields underlying hardware device differences for system services. For details, see [HDI Specifications](../../design/hdi-design-specifications.md). + ### Working Principles The User_auth driver shields the differences of security devices and environments. It provides unified interfaces for the User_auth service to implement management of executors and credentials as well as authentication scheme generation. @@ -97,30 +109,33 @@ The User_auth driver provides stable user credential management, authentication ### Available APIs +The following table describes the C++ APIs generated from the Interface Definition Language (IDL) interface description. For details about the interface declaration, see the .idl file in **/drivers/interface/user_auth/v1_0/**. +**Table 1** describes the HDI APIs for executor registration, credential enrollment and deletion, user authentication, and user identification. + **Table 1** Available APIs -| API | Description | -| ------------------------------------------------------------ | ------------------------------------------------------------ | -| Init() | Initializes cached information. | -| AddExecutor(const ExecutorRegisterInfo& info, uint64_t& index, std::vector& publicKey,
std::vector& templateIds) | Adds an executor to obtain the authentication capability. | -| DeleteExecutor(uint64_t index) | Deletes an executor. | -| OpenSession(int32_t userId, std::vector& challenge) | Opens a session for authentication credential management. | -| CloseSession(int32_t userId) | Closes a session for authentication credential management. | +| API | Description | +| --------------------------- | --------------------------- | +| Init() | Initializes cached information. | +| AddExecutor(const ExecutorRegisterInfo& info, uint64_t& index, std::vector& publicKey,
std::vector& templateIds) | Adds an executor to obtain the authentication capability. | +| DeleteExecutor(uint64_t index) | Deletes an executor. | +| OpenSession(int32_t userId, std::vector& challenge) | Opens a session for authentication credential management. | +| CloseSession(int32_t userId) | Closes a session for authentication credential management. | | BeginEnrollment(int32_t userId, const std::vector& authToken, const EnrollParam& param,
ScheduleInfo& info) | Enrolls the user authentication credential. If a user has enrolled a PIN, the old PIN will be overwritten.| -| UpdateEnrollmentResult(int32_t userId, const std::vector& scheduleResult, uint64_t& credentialId,
CredentialInfo& oldInfo) | Updates the data to complete this enrollment. | -| CancelEnrollment(int32_t userId) | Cancels an enrollment operation. | +| UpdateEnrollmentResult(int32_t userId, const std::vector& scheduleResult, uint64_t& credentialId,
CredentialInfo& oldInfo) | Updates the data to complete this enrollment. | +| CancelEnrollment(int32_t userId) | Cancels an enrollment operation. | | DeleteCredential(int32_t userId, uint64_t credentialId, const std::vector& authToken,
CredentialInfo& info) | Deletes credential information based on the specified **credentialId**. | | DeleteUser(int32_t userId, const std::vector& authToken,
std::vector& deletedInfos) | Deletes a user PIN from User_auth. | | EnforceDeleteUser(int32_t userId, std::vector& deletedInfos) | Forcibly deletes a user. This API will be called when a user is deleted from the system. | -| GetCredential(int32_t userId, AuthType authType, std::vector& infos) | Obtains user credential information by authentication type. | +| GetCredential(int32_t userId, AuthType authType, std::vector& infos) | Obtains user credential information by authentication type. | | GetSecureInfo(int32_t userId, uint64_t& secureUid, std::vector& infos) | Obtains the secure user ID and the enrolled tag ID of each authentication type. | | BeginAuthentication(uint64_t contextId, const AuthSolution& param,
std::vector& scheduleInfos) | Starts an authentication to generate the authentication scheme and scheduling information. | | UpdateAuthenticationResult(uint64_t contextId, const std::vector& scheduleResult,
AuthResultInfo& info) | Updates the authentication result to evaluate the authentication scheme. | -| CancelAuthentication(uint64_t contextId) | Cancels an authentication. | +| CancelAuthentication(uint64_t contextId) | Cancels an authentication. | | BeginIdentification(uint64_t contextId, AuthType authType, const std::vector& challenge,
uint32_t executorId, ScheduleInfo& scheduleInfo) | Starts an identification to generate the identification scheme and scheduling information. | | UpdateIdentificationResult(uint64_t contextId, const std::vector& scheduleResult,
IdentifyResultInfo& info) | Updates the identification result to evaluate the identification scheme. | -| CancelIdentification(uint64_t contextId) | Cancels an identification. | -| GetAuthTrustLevel(int32_t userId, AuthType authType, uint32_t& authTrustLevel) | Obtains the authentication trust level of the specified authentication type. | +| CancelIdentification(uint64_t contextId) | Cancels an identification. | +| GetAuthTrustLevel(int32_t userId, AuthType authType, uint32_t& authTrustLevel) | Obtains the authentication trust level of the specified authentication type. | | GetValidSolution(int32_t userId, const std::vector& authTypes, uint32_t authTrustLevel,
std::vector& validTypes) | Obtains the valid authentication scheme based on the authentication trust level for a user. | ### How to Develop @@ -129,13 +144,13 @@ The following uses the Hi3516D V300 development board as an example to demonstra ```undefined // drivers/peripheral/user_auth -├── BUILD.gn # Build script -├── bundle.json # Module description file -└── hdi_service # User_auth driver implementation - ├── BUILD.gn # Build script - ├── module # Implementation of functionalities +├── BUILD.gn # Build script +├── bundle.json # Component description file +└── hdi_service # User_auth driver implementation + ├── BUILD.gn # Build script + ├── module # Implementation of functionalities └── service - ├── user_auth_interface_driver.cpp # User_auth driver entry + ├── user_auth_interface_driver.cpp # User_auth driver entry └── user_auth_interface_service.cpp # Implementation of the APIs for obtaining the executor list ``` @@ -397,7 +412,7 @@ The development procedure is as follows: { IAM_LOGI("start"); if (param.challenge.size() != sizeof(uint64_t)) { - IAM_LOGE("challenge copy failed"); + IAM_LOGE("Failed to copy the challenge"); return RESULT_BAD_PARAM; } GlobalLock(); @@ -410,7 +425,7 @@ The development procedure is as follows: solutionIn.authTrustLevel = param.authTrustLevel; if (memcpy_s(&solutionIn.challenge, sizeof(uint64_t), ¶m.challenge[0], param.challenge.size()) != EOK) { - IAM_LOGE("challenge copy failed"); + IAM_LOGE("Failed to copy the challenge"); GlobalUnLock(); return RESULT_BAD_COPY; } @@ -494,65 +509,59 @@ The development procedure is as follows: Use the [User Authentication APIs](../../application-dev/reference/apis/js-apis-useriam-userauth.md) to develop a JavaScript application and verify the application on the Hi3516D V300 development board. The sample code for verifying and canceling the authentication is as follows: -```js -// API version 8 -import userIAM_userAuth from '@ohos.userIAM.userAuth'; -let auth = new userIAM_userAuth.UserAuth(); - -export default { - getVersion() { - console.info("start get version"); - let version = this.auth.getVersion(); - console.info("auth version = " + version); - }, - - startAuth() { - console.info("start auth"); - this.auth.auth(null, userIAM_userAuth.UserAuthType.FACE, userIAM_userAuth.AuthTrustLevel.ATL1, { - onResult: (result, extraInfo) => { - try { - console.info("auth onResult result = " + result); - console.info("auth onResult extraInfo = " + JSON.stringify(extraInfo)); - if (result == 'SUCCESS') { - // Add the logic to be executed when the authentication is successful. - } else { - // Add the logic to be executed when the authentication fails. - } - } catch (e) { - console.info("auth onResult error = " + e); - } - }, - - onAcquireInfo: (module, acquire, extraInfo) => { - try { - console.info("auth onAcquireInfo module = " + module); - console.info("auth onAcquireInfo acquire = " + acquire); - console.info("auth onAcquireInfo extraInfo = " + JSON.stringify(extraInfo)); - } catch (e) { - console.info("auth onAcquireInfo error = " + e); - } - } - }); - }, - - cancelAuth() { - console.info("start cancel auth"); - // Obtain contextId using auth(). - let contextId = auth.auth(null, userIAM_userAuth.UserAuthType.FACE, userIAM_userAuth.AuthTrustLevel.ATL1, { - onResult: (result, extraInfo) => { - console.info("auth onResult result = " + result); - }, - - onAcquireInfo: (module, acquire, extraInfo) => { - console.info("auth onAcquireInfo module = " + module); + ```js + // API version 9 + import userIAM_userAuth from '@ohos.userIAM.userAuth'; + + let challenge = new Uint8Array([1, 2, 3, 4, 5, 6, 7, 8]); + let authType = userIAM_userAuth.UserAuthType.FACE; + let authTrustLevel = userIAM_userAuth.AuthTrustLevel.ATL1; + + // Obtain an authentication object. + let auth; + try { + auth = userIAM_userAuth.getAuthInstance(challenge, authType, authTrustLevel); + console.log("get auth instance success"); + } catch (error) { + console.log("get auth instance failed" + error); + } + + // Subscribe to the authentication result. + try { + auth.on("result", { + callback: (result: userIAM_userAuth.AuthResultInfo) => { + console.log("authV9 result " + result.result); + console.log("authV9 token " + result.token); + console.log("authV9 remainAttempts " + result.remainAttempts); + console.log("authV9 lockoutDuration " + result.lockoutDuration); } }); - let cancelCode = this.auth.cancel(contextId); - if (cancelCode == userIAM_userAuth.Result.SUCCESS) { - console.info("Authentication canceled successfully"); - } else { - console.error("Failed to cancel authentication"); - } + console.log("subscribe authentication event success"); + } catch (error) { + console.log("subscribe authentication event failed " + error); } -} -``` + + // Start user authentication. + try { + auth.start(); + console.info("authV9 start auth success"); + } catch (error) { + console.info("authV9 start auth failed, error = " + error); + } + + // Cancel the authentication. + try { + auth.cancel(); + console.info("Authentication canceled successfully"); + } catch (error) { + console.info("cancel auth failed, error = " + error); + } + + // Unsubscribe from the authentication result. + try { + auth.off("result"); + console.info("cancel subscribe authentication event success"); + } catch (error) { + console.info("cancel subscribe authentication event failed, error = " + error); + } + ``` diff --git a/en/readme/user-iam.md b/en/readme/user-iam.md index 9c80ac7226ed8feca8e116cc5ff1943a641e5fda..7aea5f4d803f0781c1fcc637a1c6e50555be2e86 100644 --- a/en/readme/user-iam.md +++ b/en/readme/user-iam.md @@ -4,45 +4,45 @@ The user identity and access management (IAM) subsystem provides a unified framework for user credential management and user identity authentication in OpenHarmony. It allows multiple users to set their own authentication credential information and authenticates their identities based on the information set. -This subsystem is widely used in security-sensitive scenarios such as screen lock. It also provides APIs for developers to call the identity authentication capabilities to control user access. +This subsystem is widely used in security-sensitive scenarios such as screen lock and payment. In addition, the user IAM subsystem provides APIs for third-party applications to control user access. -**Figure 1** Subsystem architecture +**Figure 1** Architecture ![](figures/User-IAM-subsystem-architecture.png) -The user IAM subsystem consists of the unified user authentication framework and authentication executor. The unified user authentication framework consists of the following parts: -- Unified user authentication: provides unified user identity authentication externally and provides open biometric authentication capabilities for third-party applications to invoke. -- User credential management: provides a unified user credential information management interface for the upper layer and invokes authentication resources in the system through the authentication executor management part to implement lifecycle management and secure storage of user credentials. +The user IAM subsystem consists of the unified user authentication framework and authentication executor. The unified user authentication framework consists of the following: + +- Unified user authentication: provides unified user identity authentication externally and open biometric authentication capabilities for third-party applications to invoke. +- User credential management: provides a unified user credential information management interface for the upper layer and invokes authentication resources in the system through the authentication executor to implement lifecycle management and secure storage of user credentials. - Authentication executor management: provides authentication resource management and authentication session management, and supports unified management, scheduling, and connection of various authentication executors in the system. -Based on the unified user authentication framework, the system can be extended to support multiple authentication capabilities. Currently, the authentication executors supported by OpenHarmony are password and facial authentication. To implement a new authentication executor, you only need to implement authentication capabilities in a new part and connect the new part to the unified user authentication framework based on the interfaces defined by the authentication executor management part. +Based on the unified user authentication framework, the system supports multiple authentication capabilities. Currently, OpenHarmony supports PIN and facial authentication executors. To implement a new authentication executor, you only need to implement authentication capabilities in a new component and connect the new component to the unified user authentication framework based on the APIs defined by the authentication executor management component. > **NOTE** > ->In the user IAM subsystem, an authentication executor is the minimum execution unit of a user identity authentication operation. For example, a password authentication module is responsible for password collection, password processing and comparison, and secure storage, and therefore it can be abstracted as a password authentication executor. +>In the user IAM subsystem, an authentication executor is the minimum execution unit of a user identity authentication operation. For example, a PIN authentication module is responsible for PIN collection, processing, comparison, and secure storage, and therefore it can be abstracted as a PIN authentication executor. ## Directory Structure - ```undefined -//base/user_iam -├── user_auth_framework # User authentication framework, including user authentication, credential management, and executor management -├── face_auth # Facial authentication module, which connects to the authentication executor management part and supports facial information recording, deletion, and verification -├── pin_auth # Password authentication module, which connects to the authentication executor management part and supports password recording, deletion, and verification +//base/useriam +├── user_auth_framework # User authentication framework, including user authentication, credential management, and executor management. +├── face_auth # Facial authentication component, which interacts with the authentication executor to implement facial information enrollment, deletion, and authentication. +├── pin_auth # PIN authentication component, which interacts with the authentication executor to implement PIN enrollment, deletion, and authentication. ``` ## Constraints -- User credential management is a key operation in the system, and the interfaces used for user credential management can be invoked only by basic system applications. -- The authentication executors process user authentication credentials, and their capabilities can only be implemented by system services for interconnection with the authentication executor management part. +- User credential management involves critical operations in the system, and the related APIs can be called only by basic system applications. +- The authentication executors process user authentication credentials. Therefore, only system services can interact with the authentication executor management module to implement the executor functions. ## Usage ### How to Use -1. The unified user authentication framework must work with an authentication executor. -2. The first default authentication executor in the system must be a password authentication executor. +- The unified user authentication framework must work with an authentication executor. +- By default, the first authentication executor in the system is the PIN authentication executor. ## Repositories Involved @@ -54,4 +54,4 @@ Based on the unified user authentication framework, the system can be extended t [drivers_interface](https://gitee.com/openharmony/drivers_interface) -[drivers_peripheral](https://gitee.com/openharmony/drivers_peripheral) \ No newline at end of file +[drivers_peripheral](https://gitee.com/openharmony/drivers_peripheral)