自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(36)
  • 收藏
  • 关注

原创 OpenHarmony分布式软总线与设备认证模块总结

此次OpenHarmony1.x源码分析涉及了分布式软总线(Lite版本)、设备认证(Lite版本)两个较大模块。

2022-05-31 21:12:53 5793 1

原创 OpenHarmony解读之设备认证:sts协议-客户端接收end响应

本文重点介绍客户端收到end响应消息之后的处理过程。这一模块的源码位于:/base/security/deviceauth。

2022-05-31 20:52:28 473

原创 OpenHarmony解读之设备认证:sts协议-服务端响应sts end请求

在上文中说到,客户端根据服务端的start响应消息发起了end请求,本文将重点介绍服务端是如何处理和响应end请求的。这一模块的源码位于:/base/security/deviceauth。

2022-05-31 20:50:57 465

原创 OpenHarmony解读之设备认证:sts协议-客户端发起sts end请求

客户端收到来自服务端的响应消息之后,针对消息内容进行相关处理并再次发起sts end请求,目的在于发送可信认证数据,使得服务端可以验证客户端的身份。本文将对这个过程进行详细介绍。这一模块的源码位于:/base/security/deviceauth。

2022-05-31 20:49:26 425

原创 OpenHarmony解读之设备认证:sts协议-服务端响应sts start请求

上文讲到,客户端设备向服务端设备发起认证start请求,本文将介绍服务端接收到请求消息后的处理过程以及如何响应客户端。这一模块的源码位于:/base/security/deviceauth。

2022-05-31 20:47:05 574

原创 OpenHarmony解读之设备认证:sts协议-客户端发起start请求

一、概述为实现用户个人数据在多个终端设备间的安全传输,设备认证模块提供将多个设备安全连接起来的能力,通过设备间信任关系建立和设备通信时信任关系验证保证安全性。主控设备和配件设备基于PAKE协议完成认证会话密钥协商,并基于该会话密钥,安全的交换各自身份公钥。当建立过信任关系的主控设备与配件设备间进行通信时,双方将相互交换身份公钥,并通过检查本地是否存储对端身份信息的方式确认对端与本设备的信任关系。进一步地,基于双方的身份公私钥对,通信对端设备可以基于STS协议进行密钥协商并建立安全通信通道,支撑设备间通信

2022-05-31 20:43:56 1354 1

原创 OpenHarmony解读之设备认证:pake协议-客户端接收end响应

一、概述在上一篇博客中提到,服务端针对客户端发起的end请求,作出了end响应,因此,本文将介绍客户端接收到end响应之后的处理过程。二、源码分析这一模块的源码位于:/base/security/deviceauth。1. 首先执行parse_pake_server_confirm函数解析响应消息。/*函数功能:解析服务端confirm消息负载函数参数: payload:消息负载 data_type:数据类型函数返回值: 返回pake_end_response_dat

2022-05-29 20:16:21 608

原创 OpenHarmony解读之设备认证:pake协议-服务端响应pake end请求

一、概述针对客户端发起的end请求,服务端应作出对应的响应,本文重点介绍服务端解析end请求的过程及构造响应消息的过程。二、源码分析这一模块的源码位于:/base/security/deviceauth。1. 首先解析收到的消息数据:parse_pake_client_confirm函数。/*函数功能:解析pake客户端confirm消息函数参数: payload:消息负载部分 data_type:数据类型函数返回值: 返回pake_end_request_data结

2022-05-29 20:14:55 406

原创 OpenHarmony解读之设备认证:pake协议-客户端发起end请求

一、概述在前面的文中,客户端首先发起start请求,然后服务端进行响应,本文将介绍客户端收到来自服务端的响应(response)消息的处理过程以及客户端针对该响应发起end请求的过程。二、源码分析这一模块的源码位于:/base/security/deviceauth。1. 首先解析该response消息,调用parse_pake_response函数实现:/*函数功能:解析pake服务端响应消息函数参数: payload:消息负载 data_type:数据类型函数返回值:

2022-05-29 20:12:46 430

原创 OpenHarmony解读之设备认证:pake协议-服务端响应pake start请求(2)

一、概述本文将继续介绍服务端响应pake协议的start请求的过程,承接上文:OpenHarmony解读之设备认证:pake协议-服务端响应pake start请求(1)。二、源码分析这一模块的源码位于:/base/security/deviceauth。1. 在上文中创建完pake服务端对象之后,开始进入消息处理阶段,根据协议模块字段在全局分布式消息表中查询对应的消息处理函数,此处应该是proc_pake_request_message函数。/*函数功能:处理pake请求消息函数参数:

2022-05-29 20:11:01 513

原创 OpenHarmony解读之设备认证:pake协议-服务端响应pake start请求(1)

一、概述在上一篇博客OpenHarmony解读之设备认证:pake协议-客户端发起start请求中讲到,客户端设备向服务端设备发起请求,本文将介绍服务端设备是如何响应客户端设备的请求并作出具体回复的。接收消息数据的过程在前面的博客中已经有所介绍,这里不再赘述。二、源码分析这一模块的源码位于:/base/security/deviceauth。1. 首先执行函数parse_pake_request解析pake请求消息。/*函数功能:解析pake协议请求消息函数参数: payload:消息

2022-05-29 20:07:25 482

原创 OpenHarmony解读之设备认证:pake协议-客户端发起start请求

一、概述在设备认证过程中,pake协议用于认证会话密钥协商,基于该会话密钥,双方可以安全地交换各自的身份公钥。从本文开始,将对pake协议的详细过程进行介绍,本博客主要介绍客户端发起start请求的过程,协议状态从PROTOCOL_INIT转换为START_REQUEST。二、源码分析这一模块的源码位于:/base/security/deviceauth。1. start_pake函数,启动pake模块。/*函数功能:启动pake模块函数参数: handle:hichain实例

2022-05-29 20:04:23 1421

原创 OpenHarmony解读之设备认证:数据接收管理-通知对端

一、概述在HiChain本端接收数据的处理过程中:(1)在正确解析并处理完接收的数据之后,应构造相应的通知消息回复给对端。(2)在消息处理过程中会有出现错误的情况,在发现错误之后,应针对相应的错误情况通知对端,否则对端会一直处于未知状态。本文将介绍回复通知的相应过程。二、源码分析这一模块的源码位于:/base/security/deviceauth。在receive_data函数中,出现错误会跳转到inform处,在inform阶段,首先调用函数encap_inform_message为通知消息申

2022-05-29 20:02:12 590

原创 OpenHarmony解读之设备认证:数据接收管理-消息处理(2)

一、概述本文将继续介绍HiChain本端接收数据的处理过程中的消息处理阶段的剩余内容。二、源码分析这一模块的源码位于:/base/security/deviceauth。检查消息为系统可支持并合法之后,调用build_object函数构建HiChain子对象,具体分析如下:/*函数功能:构建HiChain子对象函数参数: hichain:HiChain实例 modular:消息模块类型 is_client:是否是client params:构建参数函数返回

2022-05-29 20:01:08 484

原创 OpenHarmony解读之设备认证:数据接收管理-消息处理(1)

一、概述本文将承接上一篇博客OpenHarmony解读之设备认证:数据接收管理-消息解析的内容,主要介绍HiChain本端接收数据的处理过程中的消息处理阶段。二、源码分析这一模块的源码位于:/base/security/deviceauth。在receive_data函数中,首先执行deserialize_message函数将消息解析完毕保存在struct message结构中,然后调用navigate_message函数,根据消息码得到消息类型msg_type和消息模块modular,具体分析如

2022-05-29 09:36:20 482

原创 OpenHarmony源码分析之分布式软总线:trans_service模块(4)/TCP会话管理

一、概述trans_service模块基于系统内核提供的socket通信,向authmanager模块提供设备认证通道管理和设备认证数据的传输;向业务模块提供session管理和基于session的数据收发功能,并且通过GCM模块的加密功能提供收发报文的加解密保护。在上一篇博客 OpenHarmony源码分析之分布式软总线:trans_service模块(2)/会话管理之新会话中已经介绍了在分布式软总线中TCP会话管理的部分内容,如TCP新会话的管理。本文将继续介绍会话管理的相关内容,重点在于TCP会话

2022-05-29 09:35:58 662

原创 OpenHarmony解读之设备认证:数据接收管理-消息解析

一、概述从本文开始,将介绍在HiChain机制中如何处理本端接收到的数据及其响应对端的过程。这个过程的入口函数为receive_data,在receive_data函数中,主要分为三个阶段:消息解析阶段、消息处理阶段和通知对端阶段,本文的重点是总体分析receive_data函数,然后对消息解析阶段的部分内容进行分析。二、源码分析这一模块的源码位于:/base/security/deviceauth。receive_data函数的整体分析:/*函数功能:HiChain处理接收到的消息数据函

2022-05-28 21:21:19 756

原创 OpenHarmony解读之设备认证:数据接收管理-获取HiChain实例(4)

一、概述上一篇博客 OpenHarmony解读之设备认证:数据接收管理-获取HiChain实例(3)重点介绍了在生成本端长期存储的密钥对的过程中服务id的生成,本文将介绍后续两个阶段:密钥别名的生成过程以及密钥对的生成过程。二、源码分析这一模块的源码位于:/base/security/deviceauth。密钥别名的生成过程主要是在函数generate_key_alias中实现的,对该函数以及相关数据结构的详细分析如下:/*函数功能:通过服务id和认证id生成密钥别名函数参数: s

2022-05-28 21:16:18 841

原创 OpenHarmony解读之设备认证:数据接收管理-获取HiChain实例(3)

一、概述上一篇博客 OpenHarmony解读之设备认证:数据接收管理-获取HiChain实例(2)介绍的主要内容是构建本端的长期保存的密钥对,即重点是对函数build_self_lt_key_pair的总体分析,在上文中讲到该函数通过回调函数的方式调用位于分布式软总线模块的AuthGetProtocolParams函数进行协议参数的获取,主要是获取密钥长度、对端认证id和本端认证id。本文将继续分析build_self_lt_key_pair函数的其余内容。二、源码分析这一模块的源码位于:/base

2022-05-28 21:13:09 518

原创 OpenHarmony解读之设备认证:数据接收管理-获取HiChain实例(2)

一、概述上一篇博客 OpenHarmony解读之设备认证:数据接收管理-获取HiChain实例(1)介绍了hichain实例获取的部分内容,本文将继续进行分析。在上一篇博客介绍的get_instance函数中,在进行完密钥等信息的初始化之后,调用build_self_lt_key_pair函数创建属于本端的长期保存的密钥对,这个密钥对初步分析是用于设备之间的身份可信认证。创建密钥对部分可分为四个阶段:1、获取协议参数。2、生成服务id。3、生成密钥别名。4、生成长期保存的密钥对。下面将对build_se

2022-05-28 21:11:52 859

原创 OpenHarmony解读之设备认证:数据接收管理-获取HiChain实例(1)

一、概述在OpenHarmony中,设备认证模块作为安全子系统的子模块,负责设备间可信关系的建立、维护、使用、撤销等全生命周期的管理,实现可信设备间的互信认证和安全会话密钥协商,是搭载OpenHarmony的设备进行可信互联的基础平台能力。在上一篇博客OpenHarmony深度解读之分布式软总线:HiChain机制部分源码解析中提到,HiChain机制是OpenHarmony实现设备互联安全的一种协议机制,接下来的博客将沿着之前的逻辑接着往下分析,重点针对本端接收到的数据包进行更进一步的解析,即进入到真

2022-05-28 21:10:10 1221

原创 OpenHarmony深度解读之设备认证:HiChain机制部分源码解析1

一、概述HiChain机制是OpenHarmony实现设备互联安全的一种协议机制,本文将对软总线模块涉及到的相关HiChain的接口进行一个简单的分析。处理逻辑是承接上文 OpenHarmony深度解读之分布式软总线:authmanager模块(3)/设备身份认证过程。二、源码分析在之前的文章的源码分析中,首先判断了数据包的module字段如果是MODULE_AUTH_SDK,就调用AuthProcessReceivedData函数继续处理,该函数如下:/*函数功能:处理身份认证过程中接收到的

2022-05-28 21:07:31 2027

原创 OpenHarmony深度解读之分布式软总线:设备认证机制浅析

一、概述为保证设备互联安全性,即保证用户数据在多个终端设备间的安全流转,OpenHarmony提供了可靠的设备认证机制,主要分为设备间信任关系的建立和设备通信时信任关系验证两个阶段。设备认证提供了IoT主控设备(手机、平板等)与IoT配件设备(如智能家居、智能穿戴等)间建立并验证帐号无关点对点信任关系的能力。具备这种信任关系的设备在通信连接时可搭建安全的连接通道,实现用户数据的端到端加密传输。二、设备认证机制的实现IoT主控设备的身份标识IoT主控设备在与配件设备建立点对点信任关系时,会生成椭

2022-05-28 21:04:19 2932

原创 OpenHarmony源码分析之分布式软总线:os_adapter模块解析

一、概述os_adapter模块是操作系统适配层。HarmonyOS的操作系统底层可以是:HarmonyOS micro kernel,Linux kernel,且 Lite OS将成为一个完整的鸿蒙微内核架构。鸿蒙系统内部各个模块内部使用的函数需要支持针对不同版本平台的适配,体现各部分解耦的模块化设计思想,针对不同的硬件设备,组合成最适合该设备的OS。当前版本的鸿蒙系统的os_adapter模块针对Lite OS内核和Linux内核实现了互斥锁和消息队列的适配。下面分别对两种内核的适配源码进行分析。二

2022-05-28 20:58:17 1042

原创 OpenHarmony源码分析之分布式软总线:trans_service模块(6)/TCP会话管理

一、概述trans_service模块基于系统内核提供的socket通信,向authmanager模块提供设备认证通道管理和设备认证数据的传输;向业务模块提供session管理和基于session的数据收发功能,并且通过GCM模块的加密功能提供收发报文的加解密保护。本文是分布式软总线的会话管理机制的结尾部分,在前文中介绍了新会话中客户端请求数据的处理过程,本文重点介绍普通会话中的新数据处理。衔接OpenHarmony源码分析之分布式软总线:trans_service模块(5)/TCP会话管理。二、源码

2022-05-28 20:56:46 524

原创 OpenHarmony源码分析之分布式软总线:trans_service模块(5)/TCP会话管理

一、概述trans_service模块基于系统内核提供的socket通信,向authmanager模块提供设备认证通道管理和设备认证数据的传输;向业务模块提供session管理和基于session的数据收发功能,并且通过GCM模块的加密功能提供收发报文的加解密保护。本文将继续介绍鸿蒙系统的会话机制的管理,承接上文OpenHarmony源码分析之分布式软总线:trans_service模块(4)/TCP会话管理的内容,本文将介绍鸿蒙系统如何处理客户端发起的请求消息。二、源码分析在上文提到的OnPro

2022-05-28 20:54:49 736

原创 OpenHarmony源码分析之分布式软总线:mbed TLS库的应用

一、概述Mbed TLS 库旨在与现有(嵌入式)应用程序集成,并为安全通信、加密和密钥管理提供构建块。Mbed TLS 设计为尽可能松散耦合,允许您只集成您需要的部分,而无需其他部分的开销。这也导致 Mbed TLS 库的内存占用和构建占用非常低。通过消除系统中不需要的部件,您可以获得从低至 45 kB 到更典型的 300 kB 的构建大小,以实现功能更齐全的设置。Mbed TLS 是用可移植的 C 语言设计的,以嵌入式环境为主要目标,可在从 ARM 和 AVR 等嵌入式平台到 PC 和 iPad、iPh

2022-04-18 21:54:23 1240

原创 OpenHarmony深度解读之分布式软总线:authmanager模块(6)/设备身份认证过程

一、概述本文将继续分析设备之间的身份认证过程的相关细节,主要是针对数据包类型为MODULE_CONNECTION的处理过程。主要源代码在wifi_auth_manager.c文件的函数OnModuleMessageReceived()中。二、源码分析如果数据包类型为MODULE_CONNECTION,首先调用OnMessageReceived() 函数。处理接收到的消息,解析并按规则回复给对端。/*函数功能:处理接收到的消息,解析并按规则回复给对端函数参数: conn:设备连接信息

2022-04-18 21:51:25 595

原创 OpenHarmony深度解读之分布式软总线:authmanager模块(5)/设备身份认证过程

一、概述本文将继续介绍设备之间的身份认证过程的相关细节,关于加密数据包的不同类型的处理。本文主要分析数据包类型为MODULE_TRUST_ENGINE的处理过程。源代码主要位于wifi_auth_manager.c文件的函数OnModuleMessageReceived()中。二、源码分析如果数据包类型为MODULE_TRUST_ENGINE且数据包头部flags字段为FLAG_REPLY,则调用函数 OnMsgOpenChannelReq() 进行处理。/*函数功能:处理对端设备发来的请求消

2022-04-18 21:48:35 587

原创 OpenHarmony深度解读之分布式软总线:authmanager模块(4)/设备身份认证过程

一、概述authmanager模块是鸿蒙为设备提供认证机制的模块。模块内的主要处理过程包括报文的接收、解密、再次封装、加密、发送的步骤。本文将继续介绍设备身份认证过程的细节。二、源码分析本文源代码主要是位于wifi_auth_manager.c文件中。在函数 OnDataReceived() 中处理认证协议数据包负载部分。/*函数功能:处理接收到的认证协议数据包数据负载部分函数参数: conn:认证设备连接信息结构体 pkt:认证协议数据包头部结构体的地址 data

2022-04-18 21:45:22 726

原创 OpenHarmony深度解读之分布式软总线:authmanager模块(3)/设备身份认证过程

一、概述设备之间互联是基于系统的IoT设备(如AI音箱、智能家居、智能穿戴等设备)与IoT主控设备(手机、平板等)间建立点对点的信任关系,并在具备信任关系的设备间,搭建安全的连接通道,实现用户数据端到端加密传输。IoT主控设备和IoT设备建立点对点信任关系的过程,实际上是相互交换IoT设备的身份标识的过程。authmanager是openharmony为设备提供认证机制的模块。上一篇文章OpenHarmony源码分析之分布式软总线:authmanager模块(2)/设备认证通信管理已经对设备间的身份认证

2022-04-18 21:39:05 1186

原创 OpenHarmony源码分析之分布式软总线:authmanager模块(2)/设备认证通信管理

一、 概述authmanager模块是鸿蒙为设备提供认证机制的模块。模块内的主要处理过程包括报文的接收、解密、再次封装、加密、发送的步骤。备注:该版本的鸿蒙仅实现了基于WiFi即局域网的设备身份认证机制。本文重点介绍在设备间建立起socket连接之后,系统是如何处理接收到的新数据。处理过程主要集中在wifi_auth_manager.c文件中。二、 源码分析当有设备发起连接请求时,首先在trans_service模块建立socket连接,建立连接之后,若有设备发送认证请求的数据,将在函数 Proc

2022-04-18 21:28:56 711

原创 OpenHarmony源码分析之分布式软总线:authmanager模块(1)/设备认证连接管理

一、 概述authmanager模块是鸿蒙为设备提供认证机制的模块。模块内的主要处理过程包括报文的接收、解密、再次封装、加密、发送的步骤。本文重点介绍当有设备发起身份认证连接请求时,系统是如何管理的。处理过程主要集中在wifi_auth_manager.c文件中。二、 源码分析当有设备发起连接请求时,首先在trans_service模块建立socket连接,主要在函数 ProcessAuthData() 中实现:/*函数功能: 处理listenFd的事件调用accept建立连接生成通信描述符g

2022-04-18 21:22:33 1588 1

原创 OpenHarmony源码分析之分布式软总线:trans_service模块(3)/线程同步锁管理

一、 概述在分布式软总线提供的数据传输服务中,为了提高处理效率,使用了多线程并发处理的机制,因此就会引入线程同步的问题,所谓线程同步,即当有一个线程在对内存进行操作时,其他线程都不可以对这个内存地址进行操作,直到该线程完成操作, 其他线程才能对该内存地址进行操作,而其他线程又处于等待状态,实现线程同步的方法有很多,临界区对象就是其中一种。trans_service模块的线程同步管理是基于互斥锁实现的,而对于不同的底层内核设备,互斥锁的调用库有所不同。如果是基于Linux内核的设备,调用的是Posix标准的

2022-04-18 21:18:01 585 1

原创 OpenHarmony源码分析之分布式软总线:trans_service模块(2)/会话管理之新会话

一、 概述trans_service模块基于系统内核提供的socket通信,向authmanager模块提供设备认证通道管理和设备认证数据的传输;向业务模块提供session管理和基于session的数据收发功能,并且通过GCM模块的加密功能提供收发报文的加解密保护。在之前的博客OpenHarmony源码分析之分布式软总线:trans_service模块/认证通道管理中已经对认证通道管理的相关源码进行了详细的分析,因此本文重点介绍trans_service模块提供的第二个功能——会话管理。在OpenHa

2022-04-18 20:50:04 1221 1

原创 OpenHarmony源码分析之分布式软总线:trans_service模块(1)/认证通道管理

一、 概述trans_service模块基于系统内核提供的socket通信,向authmanager模块提供设备认证通道管理和设备认证数据的传输;向业务模块提供session管理和基于session的数据收发功能,并且通过GCM模块的加密功能提供收发报文的加解密保护。二、 源码分析入口函数为StartListener(),主要是针对Linux系统内核,其它系统之后会有补充,解析如下/*函数功能: 启动监听其他设备的连接请求或者新数据响应函数参数:callback 回调函数的地址;ip 需

2022-04-18 20:42:11 1817

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除