updata mbedtls 3.6.5 Created-by: haige1234 Commit-by: haige1234 Merged-by: openharmony_ci Description: ### 一、内容说明(相关的Issue) https://gitcode.com/openharmony/third_party_mbedtls/issues/188 ### 二、建议测试周期和提测地址 建议测试完成时间:xxxx.xx.xx 投产上线时间:xxxx.xx.xx 提测地址:CI环境/压测环境 测试账号: ### 三、变更内容 * 3.1 关联PR列表 * 3.2 数据库和部署说明 1. 常规更新 2. 重启unicorn 3. 重启sidekiq 4. 迁移任务:是否有迁移任务,没有写 "无" 5. rake脚本:`bundle exec xxx RAILS_ENV = production`;没有写 "无" * 3.4 其他技术优化内容(做了什么,变更了什么) - 重构了 xxxx 代码 - xxxx 算法优化 * 3.5 废弃通知(什么字段、方法弃用?) * 3.6 后向不兼容变更(是否有无法向后兼容的变更?) ### 四、研发自测点(自测哪些?冒烟用例全部自测?) 自测测试结论: ### 五、测试关注点(需要提醒QA重点关注的、可能会忽略的地方) 检查点: | 需求名称 | 是否影响xx公共模块 | 是否需要xx功能 | 需求升级是否依赖其他子产品 | |------|------------|----------|---------------| | xxx | 否 | 需要 | 不需要 | | | | | | 接口测试: 性能测试: 并发测试: 其他: See merge request: openharmony/xts_device_attest_lite!80
xts_device_attest_lite module
- Introduction
- Directory Structure
- Architecture diagram
- Constraints
- Integration guidance
- Repositories Involved
Introduction
xts_device_attest_lite module:
- The basic function of the xts_device_attest_lite module is to take care of the OpenHarmony ecological device attest results, and achieve the goal of counting the number of OH ecological devices through the cloud of end data. The purpose is to count the number of OH equipment. xts_device_attest_lite module applies to mini system and small system.
Directory Structure
/test/xts
├── device_attest_lite
│ └── build # Compile configuration
│ └── figures
│ └── framework # System capability service framework
│ └── mini # Mini system service framework
│ └── small # Small system service framework
│ └── interfaces # External interface
│ └── services # Service subject and business logic code
│ └── core # Business logic code
│ └── test
│ └── startup # Small system startup example
│ └── unittest # Test case
Architecture diagram
Constraints
The integration dependency library is shown in the following table:
| Library | Version | Function description | Note |
|---|---|---|---|
| mbedtls | 2.16.11 | A lightweight implementation library of TLS protocol for embedded devices. | Library path..\third_party\mbedtls |
| cJSON | 1.7.15 | JSON file resolution library. | Library path..\third_party\cJSON\third_party |
| libsec | 1.1.10 | Security function library. | Library path..\bounds_checking_function |
| parameter | OpenHarmony 1.0+ | System interface for obtaining device information. | Library path ..\base\startup\init\interfaces\innerkits\include\syspara\parameter.h |
Integration guidance
Terminology
table 1
| Term | Explain |
|---|---|
| partners | Enterprises applying for OpenHarmony compatibility evaluation are hereinafter collectively referred to as "partners". It is required to integrate xts_device_attest_lite module. |
| manuKey | The secret key obtained by partners from the official website of the OpenHarmony compatibility platform. It is used to encrypt and protect relevant data in the product. To ensure the compatibility of multiple products, manuKey should remain unchanged during the life cycle of all products. |
| productId | When a partner applies for compatibility evaluation from the official website of the OpenHarmony compatibility platform, the platform assigns a unique product identifier to the evaluation product. The productId must remain unchanged throughout the product life cycle. |
| productKey | When partners apply for compatibility evaluation from the official website of the OpenHarmony compatibility platform, the platform assigns the unique product secret key to the evaluation product. It corresponds to the productId one by one, and is used to encrypt and protect product level data. It is also necessary to ensure that it remains unchanged throughout the product life cycle. |
| token | The partner obtains the device credentials allocated by the platform from the official website of the OpenHarmony compatibility platform, one for each device, to identify the device identity. It needs to be stored in the security partition, and cannot be cleared when the factory settings are restored or the image is upgraded. |
Partner completes information registration
Partners need to register a series of basic information about product equipment on the OpenHarmony compatibility platform, such as 公司简称(英文), 品牌英文名称, 设备型号, etc. In the equipment certification processing process, the equipment certification module reads the equipment information and reports it to the foundation cloud, which verifies it. Therefore, partners are required to complete product information registration on the official website of the OpenHarmony compatibility platform in advance, including the following two steps:
1)Partners complete device information registration on the official website of OpenHarmony compatibility platform.
2)Partners write the device information registered on the official website of the OpenHarmony compatibility platform to the device.
-
Partners complete information registration on the OpenHarmony compatibility platform
Partners need to register relevant equipment certification data on the OpenHarmony compatibility platform, please follow the registration process on the official website.
-
Partners writes the registered OS information to the device
For the information registered by partners on the OpenHarmony compatibility platform, the version package provides relevant interfaces for partners to fill in. When calling the xts_device_attest_lite function, the value filled in by the partner will be reported to the foundation cloud, which will compare and verify the information registered in the previous section with the information reported by the device. xts_device_attest module depends on some device information and needs to be adapted and modified by partners.
Device information is located in the startup subsystem file: base/startup/init/services/etc_lite/param/ohos_const/ohos.para.The device OS information is shown in the following table:
table 2
| Device information | ohos.para configuration parameter | Note |
|---|---|---|
| 发布类型 | const.ohos.releasetype=Beta | Use default |
| api版本 | const.ohos.apiversion=6 | Use default |
| 安全补丁标签 | const.ohos.version.security_patch=2021-09-01 | 2021-09-01 replace with real value |
| 软件版本号 | const.ohos.fullname=OpenHarmony-1.0.1.0 | Use default |
Device product information is located in the vendor subsystem file: vendor/hisilicon/hispark_pegasus/hals/utils/sys_param/vendor.para.The device product information is shown in the following table:
table 3
| Device information | vendor.para configuration parameter | Note |
|---|---|---|
| 企业简称(英文) | const.product.manufacturer=**** | **** replace with real value |
| 品牌英文名 | const.product.brand=**** | **** replace with real value |
| 设备型号 | const.product.model=**** | **** replace with real value |
| 软件版本号 | # const.product.software.version="OpenHarmony 1.0.1" const.product.software.version=OpenHarmony 3.3.3.3 | "OpenHarmony 1.0.1" replace with real value |
| 版本 id | No partner operation is required, and the system automatically generates | |
| 版本 Hash | const.ohos.buildroothash=default | default replace with real value |
Note:版本 id needs to be obtained through equipment, Fill in the OpenHarmony compatibility platform, 版本 id consists of: VersionId = deviceType/manufacture/brand/productSeries/OSFullName/productModel/softwareModel/OHOS_SDK_API_VERSION/incrementalVersion/buildType
Get 版本 id:
1) OS information and product information writing device
2) Release encrypted log(Modify the modification of PrintDevSysInfo in the following figure)
3) Burn
4) View 版本 ID through logs
View 版本 ID through logs
Dependent interface adaptation
In order to shield the differences in the underlying implementations of different modules, vendor defines token related APIs, which are implemented by partners through adaptation. The interface definitions are shown in the following table:
table 4 |
| Function | Interface definition | Parameters definition | Return value | Belong to |
|---|---|---|---|---|
| Read manuKey | int32_t HalGetManufactureKey(char* manuKey, uint32_t len) | acKey:Secret key storage memory len:memory length | 0:success -1:fail | ..\hal_token.h |
| Read ProductId | int32_t HalGetProdId(char* productId, uint32_t len) | productId:Product model identification len:memory length | 0:success 1:fail | ..\hal_token.h |
| Read token | int32_t HalReadToken(char* token, uint32_t len); | token:Token storage memory len:memory length | 0:success 1:fail | ..\hal_token.h |
| Write token | int32_t HalWriteToken(char* token, uint32_t len); | token:Token storage memory len:memory length | 0:success 1:fail | ..\hal_token.h |
| Read ProductKey(Reserved interface) | int32_t HalGetProdKey(char* productKey, uint32_t len) | productKey:Product (Unique) Secret Key len:memory length | 0:success 1:fail | ..\hal_token.h |
1. HalGetManufactureKey
manuKey is a parameter used to generate AES secret key in combination with the token, which is downloaded from the OpenHarmony compatibility platform.
Convert ASCII code to hexadecimal through tools.
Preset in the return value of HalGetManufactureKey interface.
2. HalGetProdId
ProductId is a parameter that is used to generate AES secret key together with the token, which can be viewed on the OpenHarmony platform.
Preset in the return value of HalGetProductId interface
3. HalReadToken 和 HalWriteToken
The manufacturer needs to implement the token read and write interface, write the token in the security partition of the device, and the partition will not be erased when the device is restarted or initialized.
4. HalGetProdKey
Reserved interface, which does not need to be implemented temporarily.
External interface
xts_device_attest_lite module external interface, the following table:
| Interface Name | Description |
|---|---|
| int32_t StartDevAttestTask(void); | Start the main process of xts_device_attest_lite |
| int32_t GetAttestStatus(AttestResultInfo* attestResultInfo); | Get attest result |
After the network connection is successful, the manufacturer needs to actively call the StartDevAttestTask function to enter the process of xts_device_attest_lite. By querying the GetAttestStatus interface, you can get the results of device attest.
Compilation instruction
mini
hb set
hb build --gn-args build_xts=true
small
LiteOS:
hb set
hb build --gn-args build_xts=true
Linux:
hb set
hb build --gn-args build_xts=true
Repositories Involved
xts_device_attest_lite








