Matter协议解析记录

目录

目录

1、Matter 协议发展

1.1、什么是Matter

1.2、Matter能做什么

2、整体介绍

3、架构介绍

3.1、Matter网络拓扑结构

3.2、功能解析

3.2.1、Fabric引用和Fabric标识符

3.2.2、供应商标识符（Vendor ID，VID）

3.2.3、产品标识符（Product ID，PID）

3.2.4、组标识符（GID）

3.2.5、节点标识符

3.2.6、IPV6地址

3.2.6、设备标识符

3.2.7、安全

3.2.8、设备入网

3.2.9、休眠终端设备（SED）

3.2.10、根数据模型

3.2.11、网络参数限制约束

3.2.12、一些临时的条目

4、加密基元介绍

5、安全通道介绍

1、整体介绍

2、IPv6 可达性

3、设备广播和发现监测（discovery）

6、Matter入网介绍：

第一步：发现设备

第二步：会话建立

第三步：合规性验证

第四步：操作证书签名及生成

第五步：网络配置

整体调试流程：

7、Matter OTA 介绍

1、Matter OTA工作流程

树莓派测试流程：

软件更新工作流程如下图：

2、Querying the OTA Provider（查询OTA固件）

3、Access Control Requirements（访问控制要求ACL）

Some special situations（特殊情况）

Regional roll-out of Software Images（标椎版）

Roll-out of non-standard Software Images（非标准版）

状态字段

更新操作字段

下载协议字段

查询图像命令

查询图像响应命令：

发布原因

更新状态枚举

更改原因枚举

状态转换事件

状态转换事件

OTA请求命令：

下载错误事件

DeviceSoftwareVersionModel Schema（11.22.6.DCL概要）

8、Matter认证

1、Matter认证类型

2、Matter认证方式

3、认证流程

4、Matter认证的产品要求

附录：

---

1、Matter 协议发展

1.1、什么是Matter

matter是 CSA连接标准联盟(原Zigbee 联盟)新推出的一个应用层协议。是一种新的、基于IP的连接标准，Matter的商标所有权是隶属于CSA联盟的。

matter原来叫Connected Home over IP (CHIP)项目，2021年5月12日正式更名为matter，同一时间Zigbee联盟更名为CSA连接标准联盟(CSA联盟)。推广matter项目。matter的目标是简化制造商的开发并提高消费者的兼容性。该项目建立在一个共同的信念之上，即智能家居设备应该是安全、可靠和无缝使用的。该项目以网际互联协议 (IP) 为基础，并为设备定义一组基于 IP 的网络技术。2022年10月4日CSA正式发布了V1.0协议

https://github.com/project-chip/connectedhomeip

1.2、Matter能做什么

Matter的愿景是在四个方面给消费者、开发者和零售商带来更好的体验。

简洁性：让用户能够更容易地选择购买和使用智能家居产品。

互通性：让不同厂家的设备能够互联互通，并且生态系统之间也能够兼容。打破目前无法与其他生态设备互联的壁垒。对于消费者来说，Matter提供的多管理员（Multi-Admin）的特性，可以让用户的设备同时连接到多个生态系统，用户也可以自由选择自己喜欢的生态系统，并且自由地切换。

可靠性：保持本地连接的稳定性，不论是睡眠设备还是非睡眠设备，都能够及时响应用户的控制指令。

安全性：Matter增加了很多的安全特性，在简化用户控制的同时，依然维持很高的安全性，保障用户的信息不被泄露。

2、整体介绍

Matter规范定义了基于Internet协议的智能家居设备的可互操作应用层解决方案的基本需求。本质上就是一个应用层协议。本章像大多数spec一样，里面定义了一些约束，基本的名称解释，缩写。如果你熟悉其它的一些协议规范，这里还列举了一些和HomeKit，Wave，Thread，ZigBee相关的概念映射关系。以及参考和引用的一些外部的文档和标准说明和一些文档使用的约束规则，如bit顺序，数字的表示形式等。这章基本大体浏览下就好了，重点可以看看基本的概念的定义，如Administrator，Advertising Data ，Attribute ，Binding，Binding等等。

这里分享一下一些关键词的翻译方便理解：

• Access Control List：访问控制列表，类似一个白名单，可以用来方控制访问簇元素
• Administrator：管理员，对另一个节点的访问控制列表具有管理权限的节点
• Advertising Data：广播包数据，主要指的是通过ble的节点收集的数据
• Attribute：属性，一种表示物理量或状态的数据实体。这些数据通过命令与其他节点通信
• Binding：绑定，一个节点上的实例与另一个(或相同)节点上的一个或多个对应实例之间的持久连接，其实就是做一个关联
• Border Router：边界路由，一种路由器，也称为边界路由器，在两个IP子网(通常是集线器网络和外围网络之间)之间提供路由服务
• Bridge：网桥，在一个matter的网络里的非matter设备
• Bridged Device ：桥接设备，在一个matter的网络里，可以供node节点使用的非matter设备
• Broadcast：广播，将消息传输到特定广播域中的每个节点，可以是以太网或Wi-Fi链路上的所有节点，也可以是Thread 的mesh节点
• Certificate Authority (CA)：认证中心，颁发数字证书的实体，如DAC或NOC
• Certification Declaration：一种数字签名令牌，用于传递供应商认证设备的物质认证状态
• Client：客户端，Cluster接口，它通常发送操作相应服务器集群上的属性的命令。客户端集群使用相同的集群标识符与相应的远程服务器集群通信
• Cluster：簇，定义一个或多个属性、命令、行为和依赖关系的规范，支持独立的实用程序或应用程序功能。该术语也可用于端点上此类规范的实现或实例
• Command：命令，对值的操作请求，该值具有预期的响应(可能具有参数)和具有状态和参数的响应
• Commission：入网，将一个节点加入一个网络，matter的网络叫Fabric
• Commissionable Node：可入网节点，一个能够被入网的节点。为了使可入网点允许入网，可能需要一些特定的操作，如按下按钮，以将可入网点放入待入网模式
• Commissionable Node Discovery：可入网节点的监测，发现一个节点，该节点可以被委托，但不一定在入网模式，用于执行入网的节点可能是全新的，在工厂重置后，或者它可能已经是委托
• Commissioner：入网管理者（与之对应的是被入网者），一个节点的角色，用来控制或者执行入网
• Commissioner Discovery：入网管理者的监测，发现一个入网管理者
• Commissionee：被入网者，一个实体，被入网后成为一个节点（node）
• Commissioning：入网过程，将一个节点加入网络的一些列过程，流程，这个过程叫做入网
• Commissioning Channel：入网通道，一个用来入网的安全信道
• Commissioning Mode：入网模式，一个节点运行入网的模式
• Controller：控制者（与之对应的是被控制者），一个节点的角色，可用用来控制一个或者多个节点的权限
• Controlee：被控制者，一个节点的角色，可用用来定义或者使能被一个或多个节点控制的权限
• Device：设备，包含一个或多个节点的设备
• Device Attestation Certificate：设备认证证书，一个符合RFC 5280的X.509 v3文档，具有可认证的属性
• Discriminator：辨别者，一种12位的值，用于区分多个可委托的物质设备广播。看到Discriminator值
• Endpoint：端点，节点内可单独寻址的特定组件
• Endpoint Address：端点地址，一个端点的地址
• Fabric：matter 网络，通信节点的逻辑集合，共享公共信任根和公共分布式配置状态
• Information Element：信息元素，一种Wi-Fi (IEEE 802.11-2020)数据容器，用于传递有关特定Wi-Fi网络的功能和操作的各种信息
• Key Center：密钥中心，一个系统组件，它从入网管理者那里获得NOCSR，并分配一个Fabric唯一的操作节点ID，将该操作节点ID作为DN插入到NOC中，并签署NOC
• Manual Pairing Code：手动配对的密钥，一种11位或21位的数字代码，可以手动输入/输入，而不是扫描二维码，其中包含使用Matter设备所需的信息
• Network：网络，一组通过互联网协议具有可寻址性、连通性和可达性的节点
• Node：节点，一个可寻址的实体，它支持Matter协议栈和(入网后)有自己的操作节点ID和节点操作凭证。一个设备可以承载多个节点
• Operational Discovery：可操作检测，发现以前入网的节点，以便对该节点执行操作
• Onboarding Payload：设备本身的信息，启动设备入网过程所需的信息
• OTA Provider：无线升级的提供者，一个实现OTA软件升级的节点
• OTA Requestor：无线升级者，一个请求无线升级的节点
• Product Attestation Authority：产品认证机构，操作根级证书颁发机构的实体，其目的是设备认证
• Product Attestation Intermediate：产品中间认证机构，为设备认证的目的而运行中间证书颁发机构的实体
• Product ID (PID)：产品ID，在给定供应商生产的产品类型中唯一标识Device类型的16位数字
• QR Code：二维码，一种机器可读的光学标签，包含其所附物品的信息
• Role：角色，节点的一组(相关的)行为。每个节点可以有多个角色
• Router：路由器，一种在其网络中与其他路由器合作提供路由服务的设备
• Soft-AP：软热点，一种利用Wi-Fi (IEEE 802.11-2020)接入点(AP)功能来宣传其存在并允许ip连接但不提供的设备网络连接
• Secure Channel，安全信道，对消息进行加密和身份验证的通道。单播安全通道还提供每个对等体的身份验证
• Server，服务器，类的所有或大部分属性的群集接口集群。服务器集群与相应的远程客户机通信具有相同群集标识符的群集
• Service Discovery：服务发现，节点定位感兴趣的服务的能力
• Software Image：软件固件或者镜像，一个数据团，相当于一个文件，由节点用来更新它的软件。就OTA软件更新而言，这进一步指的是符合OTA软件镜像文件格式的文件
• Thread：一种协议，就叫Thread，一种基于IEEE 802.15.4的低功耗IPv6网状网络技术规范)
• Vendor：供应商
• Vendor ID (VID)：供应商编号，唯一标识设备供应商的16位数字
• 下表是不同协议之间的概念的映射关系，供参考

3、架构介绍

该体系结构被划分为层，以帮助分离不同的职责，并在协议栈的各个部分之间引入良好的封装级别。包括网络拓扑结构介绍：单Thread网络，单WIFI网络和星型混合网络.

Matter是基于传输层之上的应用层协议，它依赖于以太网、Wi-Fi、Thread等底层协议。Zigbee和蓝牙都是不适配IPv6的底层协议，例如ZigBee，它规定了要求的底层协议、专用的网络层 /传输层和专用的应用层。Matter与Wi-Fi属于依赖关系，与Zigbee、蓝牙是互斥关系.

3.1、Matter网络拓扑结构

原则上，只要支持少数核心IPv6标准，任何承载IPv6的网络都适用于Matter部署。在这个版本的规范中，我们关注三种链路层技术:以太网、Wi-Fi和Thread。我们将规范限制在上述范围内，以便规范能够适当地涵盖这些链接层的提供，并适当地限制认证中的测试量。

Matter将网络视为共享资源:它不规定独占网络所有权或访问权。因此，可以在同一组组成IP网络上覆盖多个物质网络。

该协议可以在缺乏全局路由IPv6基础设施的情况下运行。这一要求允许在与全球因特网断开连接或设置防火墙的网络中进行操作。它还支持在以下情况下进行部署:互联网服务提供商不支持消费者场所的IPv6，或者这种支持被证明有其他限制，例如，如果委托的前缀不能容纳场所中的所有网络和设备。

该协议支持跨一个或多个IPv6子网的本地通信。支持网络结构的规范网络可能包括一个Wi-Fi/以太网子网，或一个或多个低功耗和有损网络(LLN)子网。在这个版本的规范中，Thread是支持的LLN标准。

3.2、功能解析

3.2.1、Fabric引用和Fabric标识符

如上所述，Fabric ID是一个64位的数字，唯一标识特定根CA范围内的Fabric。从概念上讲，完全限定的Fabric引用由包含根证书颁发机构公钥的元组和Fabric ID组成。由于完全限定的fabric引用使用起来很麻烦，因此定义了许多压缩引用的机制。压缩形式的Fabric引用在操作发现期间用于提供操作命名分离，这是在不相关的设备集合之间的一种命名空间形式。

特别的，Fabric ID 0在所有Fabric根公钥范围内保留。此Fabric ID不能用作Fabric的标识符。

fabric在数据模型中定义为一组节点，这些节点通过访问交互模型中定义的数据模型元素进行交互。

数据模型以下的层，将数据模型交互作为消息传递，必须始终指示与消息相关的结构，或者指示没有与消息相关的结构。例如:通过使用保留的fabric ID“0”的消息通道传输的数据模型消息没有与之关联的fabric。

3.2.2、供应商标识符（Vendor ID，VID）

供应商标识符(供应商ID或VID)是一个16位数字，唯一标识特定的产品制造商、供应商或其组。每个供应商ID都是由连接标准联盟静态分配的。

所有供应商ID的其他分配都在CSA制造商代码数据库中指定。

特别说明：测试供应商id是为设备制造商或爱好者的测试和开发保留的。专员不应将使用这些VIDs之一的设备调到正常运行的运行Fabric上，除非用户充分意识到为未经认证的设备提供运行和网络凭证的安全风险。

3.2.3、产品标识符（Product ID，PID）

产品标识符(Product ID或PID)是一个16位数字，唯一标识供应商的产品。产品ID由供应商分配，对于供应商ID中的每个产品应是唯一的。一旦一个产品ID被使用，它不应该被相同供应商ID下的不同产品类型重用。这些产品id不应该特定于唯一的物理设备;相反，它们描述产品类型，这可能有许多制造实例(例如，同一产品类型的多种颜色)。

不能将0x0000值分配给产品，因为product ID = 0x0000用于以下特定情况:

宣布一个匿名的产品ID作为设备发现的一部分。

表示一个OTA软件更新文件同样适用于多个产品id。

在呈现带有多个节点的ECM的机载有效载荷时，避免混淆。

3.2.4、组标识符（GID）

组标识符(组ID或GID)是一个16位的数字，在消息层标识Fabric中的一组节点(参见第4.15节“组密钥管理”)。在交互层，组ID可以进一步绑定到组中每个节点中的一个或多个端点。

通用组ID

通用组ID (UGID)位于组ID的16位子域中，为跨该标准的通用组保留。这些特殊的多播、组播或任意播目的地是恒定的，并且为任何Fabric上的所有节点所熟知。

专员应在Fabric内的所有节点上为这些组配置一个或多个共享密钥。因为密钥和IPv6组播前缀在fabric、Universal中是不同的组只支持特定Fabric内的通信。

All Nodes Group：该组用于给Fabric中的所有节点发送消息

All non-sleepy Nodes Group：该组用于向Fabric中所有具有电源能力的节点发送消息。休眠节点不应订阅此组

All Proxies Group：此组用于发现代理节点

3.2.5、节点标识符

节点标识符(Node ID)是一个64位的数字，唯一标识Fabric上的单个节点或节点组。节点id用于核心消息传递，在内部api中，在数据模型中，并用于解析节点的操作IPv6地址。节点id从 0xFFFF_FFF0_0000_00000xFFFF_FFFF_FFFF_FFFF的范围，以及值0x0000_0000_0000_0000都是为特殊用途保留的。

Operational Node ID：操作节点ID是一个64位的数字，唯一标识Fabric上的单个节点。所有消息必须有一个操作节点ID作为源地址。所有单播消息必须有一个操作节点ID作为目的地址。虽然源地址或目的地址可以从消息中省略，但它必须从会话ID中明确派生。

Group Node ID：组节点ID是一个64位的节点ID，它在控件的下半部分包含一个特定的组ID 节点ID。

Temporary Local Node ID：临时本地节点ID是一个64位的节点ID，在其低32位中包含与实现相关的值。这允许实现在操作节点ID不可用的上下文中跟踪连接或传输层链接和类似的内务管理内部使用目的。

PAKE key identifiers：节点ID的这个子串用于将访问控制主题分配给特定的PAKE密钥，如“PASE和组主题”中所述。一个示例用法是创建ACL条目，为通过使用特定pin - code建立的PASE会话进行通信的任何专员提供管理访问。

CASE Authenticated Tag：节点ID的这个子串用于为一组共享单个CASE会话的对等节点分配访问控制主题，如通过CASE Authenticated Tag识别的主题”中所述。

Unspecified Node ID：未指定的节点ID (0x0000_0000_0000_0000)是一个保留值，它永远不会出现在消息或协议使用中。它的存在是为了标记或检测未初始化、缺失或无效的存在节点id。

3.2.6、IPV6地址

该协议使用IPv6寻址进行操作通信。节点id和Fabric id解析为各种类型的IPv6地址[RFC 4291]。

IPv6 Unicast Address：IPv6单播地址是指在IPv6网络中唯一标识和定位单个节点的地址。该标准的一个主要设计目标是允许节点利用本地IPv6技术。因此，一个可运行的IPv6单播地址，提供节点应使用之间的连通性和可路由性。这包括全局单播地址(GUA)、链接本地地址(LLA)或唯一本地地址(ULA)。

IPv6 Multicast Address：IPv6组播地址由基于单播前缀的IPv6组播地址组成[RFC 3306]:

前12位由[RFC 3306]定义，为0xFF3。

接下来的4位是“scope”(范围)，根据[RFC 7346]章节2设置为:

Site-Local (0x5) -跨越Fabric中的所有网络，包括线程，以太网和Wi-Fi。

接下来的8位被保留(0x00)。

接下来的8位是“plen”，设置为0x40表示64位长的网络前缀字段。

多播地址的网络前缀部分是一个64位的位串，由以下连接组成:

0xFD根据[RFC 4193] 3.1节指定本地分配的ULA前缀

以大端序排列的网络Fabric ID的上56位

组播地址的32位组标识符部分是由:

Fabric ID的下8位

0x00

接下来的16位是组的组标识符，在组标识符中按双排位顺序指定

给定和的站点本地范围组播地址示例:

组播地址的形式确保了一个节点收到它不感兴趣的组播消息的低概率。如果在组播地址上确实发生了冲突(它需要两个相同的64位Fabric id和两个相同的16位Group id)，消息的处理通过检查哪个操作组键指向消息的关键字来消除相关的Fabric和组的歧义64位的MIC。

IPv6 Multicast Port Number:IANA分配的端口号是5540。

IPv4 Coexistence:Matter设备应该容忍IPv4地址，并且可以为了Matter操作的目的而忽略这些地址。

3.2.6、设备标识符

每个Matter设备都拥有许多证书链，DAC (Device atstation Certificate)是设备认证证书，用来证明制造商的真实性和设备硬件和软件的认证状态。设备认证证书在调试过程中由专员使用，以确保只有可信的设备才能被允许进入Fabric。设备认证过程的细节在“设备认证”中获得。

每个Matter设备都颁发一个操作节点ID和该操作节点ID的节点操作证书(NOC)。NOC允许节点通过加密方式将唯一的节点操作密钥对绑定到其主体的操作身份，通过受信任的证书颁发机构(CA)的签名进行验证，从而在Fabric中标识自己。操作节点id将在工厂重置或fabric移除时移除。NOC是在设备进入Fabric的调试过程中发出的。这些步骤有助于保护终端用户的隐私，并适应不同的信任模型。

节点操作凭证的格式和生成这些凭证的协议在“节点操作凭证规范”和“操作证书编码”小节中详细介绍。

3.2.7、安全

Matter部署现代安全措施来保护Fabric。Matter指定了一组核心安全原语，详细内容见“密码原语”，以提供全面的保护。基于NIST P-256曲线(secp256r1)的椭圆曲线密码学是公钥密码学和数字签名的基础。已选择常用的AES操作模式来提供共享密钥加密操作。在涉及基于带外密码的身份验证的场景中，Matter使用SPAKE2+，这是一种高效的增强PAKE算法。

核心加密原语构成了许多在Matter中使用的互补安全协议的基础。所有节点到节点的单播消息都是安全的、经过身份验证的，并提供重放保护。建立在IPv6组播的基础上，Matter还提供了组消息设施，对于在LLN上高效寻址非常有用。组消息特性优先考虑包处理得低延迟。

3.2.8、设备入网

设备入网是将设备连接到Fabric的过程。正在进行入网的设备被称为被入网者，进行入网管理的设备被称为入网管理者。设备入网包括以下步骤:

设备发现(参见设备发现”和机载有效载荷”):专员在网络接口(如蓝牙低能耗、Wi-Fi或其他连接的IP网络)上发现可入网设备。专员可通过被委托设备的二维码、手动配对码、近场通讯标签或其他方式获取带外秘密(密码)。这个秘密被密码验证会话建立(PASE)用来建立一个安全的入网会话。发现可入网设备和从可入网设备获取带外秘密的顺序并不重要。

使用PASE的安全设置(参见密码验证会话建立(PASE)”):使用PASE在专员和被专员之间建立加密密钥。专员和被专员之间交换的所有消息都使用这些pase派生的密钥进行加密。该流程还建立了设备认证过程中使用的认证挑战。

设备认证验证(见“设备认证”):专员建立被认证者作为认证设备的真实性，如果设备未被认证，则通知用户。

信息配置(参见节点运行凭证规范”、通用调测集群”和“节点运行凭证集群”):入网管理者向被入网者提供监管域、UTC时间、运行证书和网络接口配置等信息。

加入网络(参见“网络调测集群”和业务发现”):入网管理者触发被入网者连接到业务网络，除非被入网者已经在业务网络中。节点/被入网者的IPv6地址随后被专员或管理员使用(如果已经知道)或发现(如果不知道)

使用CASE的安全设置(参见“证书认证会话建立(CASE)”):派生用于在入网管理者或管理员与使用CASE的节点之间建立安全通信的加密密钥。入网管理者或管理员与节点之间的所有单播消息都使用这些case派生的密钥进行加密。

调测完整消息交换(参见“通用调测集群”):在运行网络上使用case派生的加密密钥加密的消息交换，表示调测过程成功完成。

入网完成后，入网管理者可以在业务网络上或调测通道上建立pase衍生加密密钥后，对被入网者进行多次重新配置。调试流程在“调试流程”中描述。

3.2.9、休眠终端设备（SED）

该标准的一个目标是为使用有限电源(如电池或有限能量清除)运行的低能耗节点提供支持。休眠终端设备(SED)工作模式的定义是为了帮助延长和优化此类节点的电池寿命。SED操作模式反映并与线程SED行为一致，但可能在其他受支持的IP接口(包括Wi-Fi)上加以利用。SED节点的稳态行为是禁用其IP接口(以及底层无线电或链路技术)。然后，SED定期唤醒以与某些基础设施设备通信，以便参与到网络中。在Thread网络的情况下(参见[Thread]])，基础设施设备是一个父Thread路由器。对于Wi-Fi，接入点提供所需的基础设施支持。定义了两个区间:

空闲模式：又慢轮询，设置SED在轮询前休眠的最大时间。该参数同时影响最小功耗和最大延迟。SLEEPY_IDLE_INTERVAL参数表示空闲模式下节点的最大休眠时间间隔。

活动模式：将SED设置为快速轮询间隔，以便在节点正在进行通信时(例如活动的Exchange)获得最大响应能力。SLEEPY_ACTIVE_INTERVAL参数表示处于活动模式的节点的最大休眠时间间隔。

SED应该通过将其SLEEPY_IDLE_INTERVAL设置为一个大于默认值的值，并在[Discovery_SII]中通告该值，从而向对等节点表明它是一个休眠设备。因为父基础设施设备有有限的缓冲空间来代表休眠设备缓存消息，所以SED通信模式应该设计成SED主要是发起者。

一个节点根据它在消息层中是否有任何未完成的交换来确定它是处于活动模式还是空闲模式。当exchange处于活动状态时，节点将保持活动模式，如果它是SED，则以快速轮询间隔轮询。一旦所有的exchange都关闭，一个节点应该转换到Idle模式，如果它是SED，并且节点没有其他突出的原因需要保持清醒，那么它应该以慢轮询的间隔轮询。

3.2.10、根数据模型

端点0(0)应该是根节点端点。

端点0(0)应支持根节点设备类型。

3.2.11、网络参数限制约束

10.1、访问控制（ACL）限制

一个节点应保证其支持的每个fabric至少有三个访问控制项可用。

例如:一个支持6个fabric的节点必须支持至少18个ACL条目，如果它支持N个条目，则必须强制任何K个fabric一起使用的条目不超过N - 3*(6-K)。

设备类型可能会对需要支持的ACL表项的数量施加额外的限制。

10.2、组限制

一个节点应该支持每个fabric至少一个组键来管理IPK。

如果节点实现了一种或多种设备类型，并支持Groups集群，则节点应另外支持由所有指定的所需组的最大数量这些实现了设备类型。

一个节点应该为它的每个操作组支持一个IPv6多播组成员支持。

对GroupKeySetStruct中的GroupKeyMulticastPolicy字段的支持是临时的。

10.3、交互模型限制

读交互限制：

服务器应确保节点的每一种织物都能处理单一的从客户端读取包含多达9条路径的fabric上的交互。

服务器可以允许读交互，即使没有访问的fabric，取决于可用的资源(例如PASE)。

订阅交互限制

发布者应确保节点所使用的每个织物至少能支持三次与发布者的订阅交互，并且每次订阅至少应支持3属性/事件路径。

服务器可以允许订阅交互，即使没有访问的fabric，受可用资源(例如通过PASE)。

设备类型规格可能需要更多地支持订阅或路径。

SUBSCRIPTION_MAX_INTERVAL_PUBLISHER_LIMIT定义所选发布者的上限任何订阅的最大间隔。这个时间应该设置为60分钟。

受上述最小约束的最小支持能力报告在“基本信息”集群的“CapabilityMinima”属性。

激活交互限制

调用请求动作应限于单个具体的命令路径。

3.2.12、一些临时的条目

以下是临时项目清单：

调用多个路径：对具有多个路径或通配符路径的调用交互的支持是临时的

EventList全局属性：EventList全局属性是临时的

代理服务：代理架构、代理配置和代理发现集群都是临时的

时间同步：时间同步特性是临时的

参数和常量：下表“参数术语表”是本章使用的参数术语表，并对每个参数进行了简要描述。节点应使用每个参数的缺省值，除非消息接收节点通过Operational发布参数的备用值发现

4、加密基元介绍

• 确定性随机比特发生器(DRBG)

该协议依赖随机数来实现许多安全目的。例如，随机数用于生成密钥、计数器、密码签名生成随机数每个部分都一般性地定义了加密原语，以及消息格式1.0  版的这些加密原语的特定实例的具体映射。本章规格。例如，  Crypto_TRNG()原语不得在Crypto_之外调用。

 ‧  CTR  DRBG（使用  AES‑CTR）

‧  HMAC  DRBG（使用  SHA‑256）

‧  HMAC  DRBG（使用  SHA‑512）

‧  哈希  DRBG（使用  SHA‑256）

‧  哈希  DRBG（使用  SHA‑512）Crypto_TRNG()可以根据NIST  800‑90B实施指南来实施，但可以使用替代实施。

Crypto_DRBG()应使用具有至少  256  位熵的Crypto_TRNG()进行播种（请参阅NIST  800‑90A  的第  4  章和第  8.4  节等）。

• 真随机数发生器

需要  TRNG（又名熵源）来提供熵种子作为  DRBG  算法的输入。

• 哈希函数
• 键希消息认证码(HMAC)

Crypto_HMAC()计算消息的加密密钥哈希消息验证代码。

• 公钥密码学

Crypto_Sign()用于对消息进行签名，  Crypto_Verify()用于验证消息上的签名

Crypto_VerifyChain()用于验证Matter  证书。成功，否则FALSE 。

Crypto_VerifyChainDER()用于验证X.509  v3  DER格式的公钥X.509  v3证书。

• 数据保密性和完整性

需要通过数据源身份验证来保护机密性和完整性的节点之间的所有单播和多播消息应使用关联数据的身份验证加密（AEAD）作为保护这些消息的原语。数据机密性和完整性应使用NIST  800‑38C中定义的  AES‑CCM  模式。

• 信息隐私

消息隐私应使用NIST  800‑38A中定义的  AES‑CTR  模式，

byte[lengthInBytes(M)]

Crypto_Privacy_Encrypt(

  SymmetricKey K,

  byte[lengthInBytes(M)] M,

  byte[CRYPTO_PRIVACY_NONCE_LENGTH_BYTES] N)

使用密钥K和随机数N对消息M进行加密；输出包含加密的数据M。

• 密钥派生函数(KDF)

KDM() SHALL be the HMAC-based KDF function with Crypto_HMAC(key := salt, message := x) as the auxiliary function H as defined in Section 4.1 Option 2 of NIST 800-56C; it returns a bit array of len bits.KDM()应该是基于hmac的KDF函数，以Crypto_HMAC(key:= salt, message:= x)作为辅助函数H，定义在NIST 800-56C Section 4.1 Option 2中;它返回由len位组成的位数组。

• 基于密码的密钥推导函数(PBKDF)

Matter  指定基于密码的密钥派生函数来计算派生密钥来加密弱密码。

• 密码认证密钥交换(PAKE)

该协议使用Passcode-Authenticated Session Establishment (PASE)协议的密码验证密钥交换  (PAKE) 。

使用共享密码和增强的密码认证密钥交换(PAKE)建立会话，其中只有一方知道之前的密码Hand，生成共享密钥。此协议仅在调试Node(即Commissionee)时使用。

5、安全通道介绍

安全通道和消息层提供了一致的网络服务节点之间进行安全通信。

在调测和单播通信过程中，提供了发现机制来确定对端IPv6地址和运行参数。使用证书(CASE)或共享密码(PASE)提供安全会话建立机制。

1、整体介绍

安全通道和消息层提供一致的网络服务基板，以允许节点之间安全地通信。在调测和单播通信过程中，提供了发现机制来确定对端IPv6地址和运行参数。使用证书(CASE)或共享密码(PASE)提供安全会话建立机制。

1.1、消息

通信是通过消息进行的。消息要么是安全的，要么是不安全的。每条消息都有一个会话类型和会话ID，以便确定它是否安全，以及如果安全，如何解密和身份验证。每条消息都有一个message Counter字段，以便为安全和重复检测目的惟一标识消息。操作通信被定义为通过IP传输在委托节点之间使用安全的Matter消息格式的通信。所有操作通信都启用了消息安全性。节点之间的操作通信可以是单播或多播。

不安全通信严格限于:

Discovery：它不使用Matter消息格式。

用户定向调试(UDC)：使用不安全的消息启动调试过程。

会话建立：使用不安全的消息建立CASE或PASE会话。

1.1.1、消息类型

消息被定义为控制消息或数据消息。大多数消息都是数据消息。控制消息为MCSP等内部协议保留，以初始化安全性。这两种消息类型在格式上是相同的，但是使用单独的消息计数器域，因此它们可以在相同的安全密钥上安全地操作。

1.1.2、消息传输

消息的大小是有限的，并通过支持的传输以单个数据包的形式发送:

UDP将每个消息作为单独的数据报传输。消息支持一个称为MRP的基本可靠性protocol，当底层传输(在本例中是UDP)不提供这种可靠性时，可以使用它特性。

TCP传输每条预先设置长度的消息，根据需要执行分段和重新扫描bly。

BTP将每条消息作为单独的SDU在BLE上传输，执行分段和根据需要重组。

BTP作为调试的传输协议提供。TCP和MRP(增加了可靠性的UDP)作为操作消息传递的传输协议提供。

1.1.3、消息交互

消息提供了一个交换层来跟踪组成小型、离散事务的相关消息。交换层向上面的交互模型层提供了这种事务跟踪工具，提供了在给定的底层会话上复用多个这样的并发事务的方法。交换层还将消息可靠性协议(MRP)集成为一种服务，用于UDP传输。此消息层体系结构如图“消息层堆栈”所示:

2、IPv6 可达性

为使节点间IPv6网络可达，需要配置IPv6网络。如之前“网络拓扑”所述，一个Matter网络可以由一个或多个IPv6网络组成。

在单一的网络配置中，所有的物质节点都附加到相同的IPv6链路上。单个网络配置可能包含单个桥接Wi-Fi /以太网网络，其中连接到该网络的所有节点都是同一广播域的一部分。当所有的物质节点都连接到同一个Wi-Fi /以太网网络时，链路本地IPv6寻址就足够了——不需要额外的IPv6网络基础设施。

在多网络配置中，一个Matter网络由(通常是一个)基础设施网络和一个或多个存根网络组成。与基础设施网络不同，存根网络不充当交通网络。通常情况下，基础架构网络是桥接的Wi-Fi /以太网网络，Thread网络是存根网络。stub路由器连接stub网络和基础架构网络，提供两个网络之间的IPv6可达性。

2.1、Stub（存根）路由器行为

stub路由器应该实现[draft-lemon-stub-networks]。在多网络配置中，基础设施网络和存根网络都需要可路由的IPv6地址进行跨网络通信。可路由的IPv6地址应具有全局作用域(如GUA或ULA) [RFC 4007]，并应由发布为在线链接的前缀构造而成。如果在给定的网络中没有可路由的前缀，存根路由器必须提供它自己的可路由前缀。注意，Thread的“on-mesh前缀”相当于Wi-Fi / Ethernet的“on-link前缀”。

Stub路由器应向相邻网络上的所有可路由前缀通告可达性。连接线程网络的存根路由器应使用路由器通告[RFC 4861]中所载的路由信息选项[RFC 4191]，向邻近的基础设施网络通告所有线程网络的可路由前缀的可达性。同一存根路由器还应在线程网络数据[Thread规范]中公布基础设施网络的所有可路由前缀到相邻Thread网络的可达性。

2.2、matter节点的行为

节点必须配置链路本地IPv6地址。此外，节点应支持至少三个可路由IPv6地址的配置(除了链路本地地址和(在Thread情况下)网格本地地址)。在Wi-Fi /以太网接口上，ICMPv6路由器通告(RA)消息发布用于在链路上使用的前缀[RFC 4861]。在Thread接口上，Thread网络数据包含用于链接的前缀[Thread规范]。如果一个节点收到一个允许在给定接口上自主配置的在线前缀，并且该节点配置的可路由IPv6地址少于三个，则该节点必须从该前缀自主配置一个IPv6地址。

matter节点还应配置到相邻网络的路由。在Wi-Fi /以太网网络中，节点必须处理路由信息选项[RFC 4191]，并通过stub路由器配置分配给stub网络的IPv6前缀路由。Wi-Fi /以太网接口应支持维护至少16种使用路由信息选项配置的不同路由。在Thread网络中，节点应根据Thread网络数据[Thread规范]中提供的路由信息进行路由。Thread设备应支持在Thread网络数据中编码的尽可能多的路由。

matter节点应支持的IPv6邻居缓存项数量至少等于所支持的CASE会话数量加上所支持的路由数量。

3、设备广播和发现监测（discovery）

本节描述广播和matter的发现监测。广播和matter的发现监测现在以下上下文中使用：

可入网的节点发现监测

可操作性发现

入网管理者发现

用户直连入网

服务发布和发现使用IETF标准的基于DNS的服务发现(DNS - SD) [RFC 6763]。Matter不需要修改IETF标准DNS - SD。使用DNS - SD意味着所提供服务的单播IPv6地址和端口都被发现，从而使Matter不再需要一个预先分配的固定端口。这也使得在单个设备上运行Matter软件的多个实例成为可能，因为每个实例都有自己的动态分配端口，而不是试图使用相同的预分配固定端口而发生冲突。在目前的Wi - Fi和以太网网络上，DNS - SD [RFC 6763]使用组播DNS [RFC 6762]进行零配置操作。

因此，在基础服务发现API中可行的情况下，发布服务可用性的Matter软件应该表明该服务的公告和应答只需要包括IPv6地址记录，而不需要包括IPv4地址记录。在同时支持IPv4和IPv6的通用双栈主机上，可以通过让与matter相关的SRV记录引用只附加IPv6地址记录的特定于matter的目标主机名来实现这一点。这允许通用双栈主机为仍然需要IPv4的遗留客户端软件提供可发现的IPv4地址，同时为Matter目的提供优化的仅ipv6地址发现。

同样，由于Matter不使用IPv4，发现其他Matter实例的Matter软件不应期望响应中包含任何IPv4地址。这两项处理服务发现消息的内容。当使用多播DNS时，与这些服务发现消息(通过IPv4、IPv6或两者发送)的传递相关的效率问题也会出现。

在底层服务发现API支持的地方，使用组播DNS发布服务可用性的Matter软件应该表明，该服务的公告和应答只需要在IPv6上执行。类似地，在底层服务发现API支持的地方，使用多播DNS发出服务发现查询的Matter应用软件应该表明，这些查询只需要在IPv6上执行。这些优化减少了组播包的大小和数量，这在Wi - Fi网络上尤其有益。一个只支持IPv6的Matter设备会自动得到这些优化，仅仅是因为它根本不支持IPv4。

对于Thread网状网络，过多使用组播将是有害的[RFC 7558]， DNS - SD使用单播DNS代替，利用Thread边界路由器上的线程服务注册中心的功能[draft-lemon-stub-networks]。

从概念上讲，正在通信的DNS - SD [RFC 6763]信息与正在使用的Multi - number cast DNS [RFC 6762]是相同的，除了信息以单播报文的形式来往于指定的服务注册中心，而不是以组播报文的形式来往于同一广播域中的每个其他节点。

使用服务注册协议[SRP]和在Thread上运行的广播代理[AdProx]边界路由器，Thread网格上的事项节点可以被Thread网格上的其他事项节点发现相邻的以太网或Wi - Fi链路，不需要在Thread网格上使用组播。所有Thread和连接事项节点必须执行服务注册协议。

Thread边界路由器在Thread网络数据[Thread规范]中发布可用的SRP服务器。Thread设备应使用可用的SRP服务器注册其服务[Thread规范]。

当Matter节点向其他Matter节点发出短时间请求时，响应会返回到请求的源IPv6地址和端口。当matter节点向其他matter节点发出长时间的请求时，在响应生成时，请求者可能已经更改了IPv6地址或端口，因此响应者可能必须发现发起者的当前IPv6地址和端口，以便发送响应。

Thread边界路由器必须实现DNS - SD发现代理[RFC 8766]，以使Thread网格(如其他节点)上的客户端能够发现使用相邻以太网或Wi - Fi链路上的组播DNS发布的服务(如事务节点)，同时也不需要在Thread网格[draft-lemon-stub-networks]上使用组播的成本。对于短时间的瞬时查询，这些查询可以使用UDP单播DNS到DNS - SD发现代理执行。对于长期存在的、带有持续更改通知的查询，使用DNS Push Notifications [RFC 8765]和DNS Stateful Operations [RFC 8490]允许Thread网格上的客户端收到已发现服务集的更改通知，而不需要昂贵的轮询。

原则上，Thread网格服务注册表可以在Thread网格内部(甚至外部)的任何有能力的节点上运行，尽管实际上Thread边界路由器是提供服务注册表的一个有吸引力的候选者。Thread边界路由器设备通常是交流供电的，通常具有更强大的cpu和更大的闪存存储和RAM，而不是更受限制的电池供电的Thread节点。Thread上的物质设备依赖于线程为Thread网格上的Thread设备提供可靠的服务。这类似于Wi - Fi上的物质设备依赖于Wi - Fi接入点(AP)，为使用该Wi - Fi接入点的Wi - Fi设备提供可靠的服务。

6、Matter入网介绍：

第一步：发现设备

获取matter设备广播私有信息（加密证书中的设备信息）采用蓝牙传输协议（BTP)。蓝牙传输协议提供一个类似TCP的可靠数据传输。说白了就是一个带协议的GATT透传，将上层的消息分包透传。如图

GATT层用的指令是write request和indication

BTP封包的定义：

H：1表示handshake，用于建立会话，0表示普通数据包

M：表示Management Opcode是否存在

A：表示ACK Number是否存在

B:表示是否是分包的头包，如果是则message Length存在

E：表示是否是分包的尾包

控制包目前只有0x6C（Handshake）一个，用于会话窗口建立，封包格式如下：

window size：指可以接收窗最多支持多少个分包。

蓝牙服务定义：

BTP GATT服务由具有c1、C2和C3三个特征的服务组成(见表32，“BTP GATT服务”)。客户端SHALL独占C1通过发送BTP握手请求发起BTP会话，并通过GATT ATT_WRITE_CMD pdu向服务器发送数据。当客户端订阅允许通过C2指示时，服务器SHALL专门使用C2响应BTP握手请求，并通过GATT ATT_HANDLE_VALUE_IND pdu向客户端发送数据。

第二步：会话建立

支持BLE，WiFi-SoftAP，WiFi (DNS-SD)三种方式，配网一般采用BLE方式，已连接WiFi后使用DNS-SD方式。控制器接收到广播时，会尝试基于配对码与设备建立加密会话。这个过程被称为 Matter 的密码认证会话建立 (Password Authenticated Session Establishment, PASE)。

第三步：合规性验证

设备认证，首先，Commissioner获取Commissionee的DAC，Device Attestation Certificate；DAC是兼容X509的设备证书，包括了Vendor ID和Product ID号

第四步：操作证书签名及生成

Commissioner发起 Op-CSR，获取Commissionee的operational Certificate Signing Request，完成验证后，给设备颁发NoC，Node Operational Certificate，即NOC；这里需要注意，NOC和DAC不一样，DAC是出厂预置的，NOC是设备配网过程颁发的。此外，控制器还会告知设备需要加入的是Wi-Fi 或 Thread 网络。设备配网完成后，PASE 会话将被关闭。此后，所有通信都将受到证书的保护。这种新的会话也被称为 Matter 的证书认证会话建立 (Certificate Authenticated Session Establishment, CASE)。

第五步：网络配置

配置设备的Access Control List，WiFi网络信息，并触发设备加入网络，分配MDNS和IPV6地址，完成CASE，Certificate Authenticated Session Establishment，获取后续的通信加密密钥。在 CASE 会话中，设备之间将交换加盐后的证书信息，从而相互验证并协商一个用于对称加密的密钥。所有控制命令均由这个密钥进行加密。

下图概括了 Matter 设备开箱后的典型配对流程，展示了 PKI 在 Matter 安全模型中的重要作用。

整体调试流程：

7、Matter OTA 介绍

“OTA请求者”是实现OTA请求者设备类型（0x0012）的任何节点，其履行OTA软件更新提供者集群的客户端角色和OTA软件更新请求者集群的服务器角色。“OTA 提供商”是实现OTA  提供商设备类型(0x0014)的任何节点，它履行OTA软件更新提供商集群的服务器角色和OTA  软件更新请求者集群的客户端角色。

OTA请求者应定期查询OTA提供商以确定新的可用性 ，允许OTA请求者获取有关可用OTA软件信息的机制，OTA提供商可以向Fabric上的OTA 请求者宣布其存在，以协助发现该服务，查询新版本可用性的流程是使用OTA命令完成的，下载协议与集群命令是分开的。所有OTA 提供商均应支持BDX协议允许休眠终端设备等下载OTA映像。

1、Matter OTA工作流程

树莓派测试流程：

将升级固件通过ssh传输到树莓派测试工具中若要更新其他版本需要进行替换

1、运行provider服务

cd  ~/esp/esp-matter/connectedhomeip/connectedhomeip/out/host

// 若之前有对同一服务进行配网则需要删除对应的存储文件负责不会重复进行 rm /tmp/chip_*

./chip-ota-provider-app -f /home/ubuntu/GS368M_S1_V10.01.01-ota.bin

2、重新开启一个终端对provide服务进行配网（保证在同一个局域网中）

cd  /home/ubuntu/matter/connectedhomeip/examples/chip-tool/out

./chip-tool pairing onnetwork 0x2345 20202021

3、设置访问权限

./chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, {"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": null, "targets": [{"cluster": 41, "endpoint": null, "deviceType": null}]}]' 0x2345 0x0

4、再次开启一个终端对设备进行Matter配网（同第四步）

cd  /home/ubuntu/matter/connectedhomeip/examples/chip-tool/out

./chip-tool pairing ble-wifi 1234 ssid password pincode discriminator --paa-trust-store-path /var/paa-root-certs/

5、在此窗口进行Matter本地OTA升级（测试Matter传输数据时间较长一般在五分钟左右）

./chip-tool otasoftwareupdaterequestor announce-otaprovider 0x2345 0 0 0 1234 0

软件更新工作流程如下图：

[10] OTA提供商可选择向节点宣布其存在

[11] OTA请求者确定要查询的OTA提供商。

[11] OTA请求者向OTA提供商查询更新的软件映像版本的可用性

[30..34] OTA提供商获得用户的同意以应用OTA更新。

[40..41] OTA 提供商实时或以延迟方式获取新软件映像的副本，以通过BDX 协议或 OTA 提供商双方都支持的备用协议提供给OTA请求者和OTA请求者支持。如果软件映像碰巧已在OTA提供商的缓存中可用，则可以跳过此步骤。

[52] OTA 请求者通过BDX协议从OTA提供商处下载更新作为代理，或通过OTA 提供商和OTA请求者都支持的替代协议。OTA请求者通知OTA提供商下载已完成并且已准备就绪

[61]  OTA提供商在可选的延迟后以应用更新的授权进行响应

[62]  OTA请求程序应用更新并开始执行更新的软件。

[63]  OTA请求者通知OTA提供商已成功应用更新。

[10..21]  确定OTA  软件更新的可用性。

[22]  OTA提供商延迟下载并响应“忙”条件，同时获得用户同意并根据中的信息从供应商服 务器获取软件映像

[30..31]  通过某些外部提供的用户界面（例如由授权用户操作的移动设备终端）进行带外通知，并以某种方式连接到OTA提供商的逻辑。

[34]  重用先前的用户同意，可能来自持续但可撤销的授权，由OTA软件更新逻辑发送回OTA提供商。通过OTA提供商委托给OTA请求者节点（请参阅第11.19.3.4.1节“用户 同意委托给节点”）。请注意，这 种情况未在序列图中说明。

[40..41]  OTA提供商通过公共互联网从供应商的服务器下载并临时存储软件映像，以便OTA请求者最终进行代理本地下载。

[51] 积极响应OTA请求者的后续查询OTA请求者使用BDX协议针对OTA提供商的临时存储从OTA提供商下载软件映像。

[60..63]  OTA请求者执行更新（在获得OTA提供商许可后）

2、Querying the OTA Provider（查询OTA固件）

OTA  提供商的查询应使用  QueryImage  命令完成。该命令的参数提供了足够的信息，以允许  OTA  提供商确定查询  OTA  请求者的新映像的可用性。

3、Access Control Requirements（访问控制要求ACL）

专员或管理员应在调试时或稍后安装必要的ACL条目，以便能够在其Fabric上处理来自  OTA请求者的QueryImage命令，否则OTA提供商将无法被OTA请求者使用。  QueryImage  命令处理的节点的示例：

{

  FabricIndex: ,

  Privilege: Operate,

  AuthMode: CASE,

  Subjects: [ ],

  Targets: [ ]

}

1. Handling UpdateAvailable value in Status field（处理状态更新的值）

UpdateAvailable状态表示OTA提供商有可用更新，QueryImageResponse命令中的其余字段应包含允许OTA请求者获取更新的软件映像所需的信息。

ImageURI字段应设置为可以下载图像的位置。提供的URI应适用于请求中提供的支持协议列表中的协议（请参见第11.19.6.5.1.4节“协议支持字段”）。 URI的选择基于OTA 提供商的软件映像数据集中的可用信息。

UpdateToken字段应由OTA提供商填充其选择的值，以便在给定OTA请求者发送进一步请求时跟踪来自给定OTA请求者的流量。

SoftwareVersion字段应设置为与新软件映像匹配的版本号。

Some special situations（特殊情况）

Regional roll-out of Software Images（标椎版）

制造商以提供全球范围内的发布时间表差异，以及逐步测试推出，以及其他原因。这些区域推广可能只有在此集群中描述的公共流程外，使用特定于制造商的方案才可行。常见的推荐行为（参见第11.19.3.3.2节，“匹配适用于查询的OTA软件映像的概念算法”）不支持区域推出，因为在分布式合规分类帐（DCL）中不存在位置标记属性。

Roll-out of non-standard Software Images（非标准版）

制造商进行现场试验来测试不同版本的软件（例如a/b测试，beta测试），或为节点子集提供专用的软件图像来影响特定的诊断任务，等等。此集群中描述的机制并不特别适合这种细粒度的部署（除非OTA提供程序是由制造商提供的或与制造商相关联的）。

为了实现更有针对性的推出，供应商可以在与需要特殊规则的设备相同的结构上委托一个节点，以便提供该集群核心互操作方面之外的OTA提供商能力。更细粒度的选择可以在给定的OTA提供程序中通过特殊的OTA软件图像选择逻辑来应用，使用查询图像命令的元数据提供程序字段和元数据请求程序字段。此外，这种特殊的OTA提供程序可以通过在给定的公告/OTA提供程序命令中包含元节点字段来标识自己。

如果这种特殊的软件映像在OTA请求者上运行，OTA请求者可能会拒绝由OTA提供商在织物上提供给其的软件映像，以防止非标准软件的丢失。

1. OTA Software Update Provider Cluster

Cluster数据类型：

状态字段

更新操作字段

下载协议字段

查询图像命令

供应商ID字段

产品ID字段

软件版本字段

协议支持字段

硬件版本字段

位置字段

RequestorCanConsent字段 ，该字段应由能够凭借内置用户界面功能获得OTA应用程序用户同意的OTA请求者设置为true

提供商元数据字段：该可选字段（如果存在）应包含顶级匿名列表；每个列表元素应具有以完全限定形式编码的特定于配置文件的标签。每个列表元素应包含一个制造商特定的有效负载，调用此命令的OTA请求者希望将其公开给制造商接收OTA提供商。该有效负载可用于任何目的。

该字段的使用应仅限于供应商特定的用途，并且不得用作选择器需要匹配生产环境中软件映像的选择。

该字段的用法示例是 OTA请求者提供有关分组的特定数据或现场试验环境中的身份验证，OTA提供商可能会理解并且能够对其采取行动，无论是对图像进行特殊选择，还是对活动进行记录。

查询图像响应命令：

状态字段

DelayedActionTime字段 :该字段应传达在发送另一个QueryImage命令或开始从OTA  提供商下载之前等待的最短时间

图像URI字段

软件版本字段

SoftwareVersionString字段:当状态为UpdateAvailable时，此字段提供OTA提供商向  OTA  请求者提供的图像的字符串版本。

更新令牌字段

用户同意所需字段

请求者元数据字段 :该可选字段（如果存在）应包含顶级匿名列表；每个列表元素应具有以完全限定形式编码的特定于配置文件的标签。每个列表元素应包含制造商特定的有效负载，OTA提供商希望将其公开给接收OTA请求者。

1. OTA Software Update Requestor Cluster

发布原因

简单公告值：OTA  提供商正在宣布其存在

更新可用值 ：OTA  提供商向单个节点或一组节点宣布一个新软件

紧急更新可用值 ：OTA  提供商向单个节点或一组节点宣布一个新软件，其中包含需要紧急应用的更新

更新状态枚举

未知值

闲置值

查询值

查询延迟值

下载价值：该值应指示当前正在下载软件更新的节点

应用价值

延迟应用值

回滚值：该值应指示节点正在从新版本恢复到以前的版本

延迟同意值

更改原因枚举

未知值

成功价值 ：该值应指示状态更改的原因是先前操作的成功。

失败值

超时值

按提供商延迟值 ：该值应表明状态更改的原因是  OTA  提供商请求等待延迟。

状态转换事件

状态转换信息

版本应用信息

下载错误信息

状态转换事件

当由于OTA导致UpdateState属性发生更改时，应生成此事件请求者在查询更新所需的状态之间移动。

该事件的数据应包含以下信息：

上一页状态字段:该字段应设置为导致生成该事件的转换之前的状态

新状态:该字段应通过导致生成该事件的转换设置为当前有效的状态。

原因字段

目标软件版本字段

OTA请求命令：

软件版本字段

产品ID字段

下载错误事件

软件版本字段

下载字节数字段

进度百分比字段

平台代码字段:该字段应该设置为一些内部产品特定的错误代码，在时间/功能上最接近导致生成该事件的故障。否则，它应该为空。

DeviceSoftwareVersionModel Schema（11.22.6.DCL概要）

供应商提供特定产品的特定软件版本信息的记录模式如下。

供应商ID

产品ID

软件版本

软件版本字符串 ：该字段应与基本信息簇中的软件版本字符串字段匹配

CD版本号：CDVersionNumber应标识适用于此的认证的CD版本号

固件信息

软件版本有效 ：该字段应指示该软件版本是否有效

OtaUrl应标识获取OTA映像的URL

OTA文件大小

OtaChecksum校验和应包含OtaUrl字段下关联OTA软件更新映像的全部内容的摘要，以Base64字符串表示形式编码

Ota校验和类型

最低适用软件版本

最大适用软件版本

发行说明网址：ReleaseNotesUrl  应标识产品特定网页，其中包含该产品的发行说明

8、Matter认证

1、Matter认证类型

硬件设备认证：

Matter硬件设备是一个可以提供Matter设备类型能力的硬件，成品和模块均可看作成品申请认证，如传感器、开关、门锁、空调、灯。

软件设备认证：

Matter软件组件是在CSA联盟所支持的操作系统（如手机、TV、树莓派等）下运行的一个软件，如APP、TV控制终端。

一个Matter设备同时支持集成以上两种设备类型，该设备可以同时申请硬件和软件两种认证。如TV，中控。

2、Matter认证方式

1. 新认证：产品通过联盟授权实验室测试后取得认证

2. 相似认证：从以获得认证的产品衍生出来的产品，根据其与先前产品的相似性而授予认证

3. 系列认证：同系列产品中，若每个子产品都是一个单一的父产品的直接变体，则子产品可授予认证，前提是产品名称一致

4. 转让认证：将已获得认证的产品嵌入其他成员公司的新产品外壳中（除了新的产品外壳外，没有任何软硬件变化）

5. 重新认证：硬件、软件产品都适用，面向SDK更新、修复bug/Security等，厂家经过UL培训或参与SVE以获得测试能力，接受自测，测试数据需送UL审核。

3、认证流程

成为CSA会员（CSA会员有4个等级，具体可点击“阅读原文”前往CSA官网查看会员权益）

从CSA申请VID（Vendor ID）

选择产品网络类型

从相关标准组织获得传输层认证

选择授权的测试提供商（必须经过Matter测试的验证）并提交产品进行测试

通过认证Web工具向CSA提交认证申请

通过认证后可以从CSA下载认证

DCL上更新信息

4、Matter认证的产品要求

产品如有内置无线模块，例如蓝牙、Wi-Fi、ZigBee，那么在Matter认证时，需提供无线模块的认证证书，例如BQB、WIFI Alliance、ZigBee Alliance等。

附录：

//基于Ubuntu的esp_Matter环境搭建

https://note.youdao.com/s/7sH0hRcy