Matter分析與安全驗證
上一篇文章簡單的介紹了Matter的架構、實現、以及部分安全驗證過程；這里繼續補充一下Matter的其他安全驗證流程，以更好的實現Matter安全。
Matter提供的安全實現流程大概總結起來是這個流程
硬件信任根→安全啟動→動態證書→加密通信→ACL權限控制→DCL全局驗證
上一篇介紹了前面的部分，這里再根據這個流程來匯總一下；
Matter安全實現流程
🔒 1. 硬件信任根（Hardware Root of Trust）
- 實現機制：
- 安全芯片固化密鑰：設備出廠時在安全芯片（如Silicon Labs的Secure Vault）中預燒唯一密鑰對和廠商證書（DAC），私鑰不可讀取僅用于簽名運算。
- 物理防篡改設計：采用防物理探測的存儲區域（Secure Enclave），確保密鑰不被提取（如Nordic nRF54系列芯片）。
- 作用：為后續安全啟動和證書鏈提供不可篡改的信任起點，防止設備克隆和固件偽造。
🚀 2. 安全啟動（Secure Boot）
- 啟動驗證流程：
- Bootloader使用硬件信任根的公鑰驗證首層固件簽名（ECDSA算法）。
- 逐級驗證：每個固件模塊驗證下一級簽名，形成信任鏈（Chain of Trust）。
- 失敗處理：簽名無效則終止啟動或回滾至安全版本（雙鏡像設計）。
- 關鍵配置：芯片OTP存儲器鎖定啟動策略（如禁用調試接口、強制加密OTA）。
- 防攻擊設計：
- 前面兩部分需要硬件安全支持，在安全芯片的支持下實現，但是大部分低成本的芯片都不具有安全能力，但是我們給方案的時候也需要考慮類似的方案，硬件信任根還是需要落地，但是沒有了安全芯片的支持，就需要放到不可讀取區域來防止復制和偽造。
📜 3. 動態證書（Dynamic Certificates）
- 證書體系結構：
- DAC（設備認證證書）：出廠預置，包含設備唯一ID（VID/PID）和公鑰，用于身份證明。
- NOC（節點操作證書）：配網時由控制器動態簽發，綁定設備與特定Fabric網絡。
- 證書生命周期：
- 簽發：配網階段控制器通過CSR請求生成設備唯一NOC，私鑰在設備安全區域生成。
- 吊銷：控制器可推送證書吊銷列表（CRL），阻斷惡意設備。
- 防攻擊設計：
- 設備配網認證階段使用，這里的DAC證書的頒發者是產品認證中間證書，一般是設備廠商持有，所以設備認證階段要通過DAC進行，而不是跟常規的設備認證通過某個設備序列號或者MAC信息來判斷設備身份；那么這里就要防止設備唯一NOC偽造的情況出現，防止客戶端自簽NOC證書的設計出現，要讓設備廠商來簽發NOC證書，并做好身份驗證以及權限控制。
📡 4. 加密通信（Encrypted Communication）
- 分層加密協議：
- PASE（配網階段）：基于配網密碼（QR碼/PIN）生成臨時會話密鑰（AES-128），保護初始配置數據傳輸。
- CASE（運行階段）：基于NOC證書交換，通過ECDH協商長期會話密鑰，所有通信使用AES-128-CCM加密并附加消息認證碼（MAC）。
- 防攻擊設計：
- 消息計數器：每個報文攜帶遞增計數器，防重放攻擊。
- 密鑰輪換：會話密鑰定期更新（默認24小時），降低密鑰泄露風險。
🛡? 5. ACL權限控制（Access Control Lists）
- 規則實現：
- 動態策略：ACL規則以JSON格式存儲于控制器，定義設備/用戶的操作權限（如
Operate開關權限、Manage規則修改權限）。 - 執行邏輯：設備處理命令前，通過安全會話向控制器請求授權，驗證節點ID和操作權限。
- 動態策略：ACL規則以JSON格式存儲于控制器，定義設備/用戶的操作權限（如
- 示例場景：門鎖設備僅允許管理員角色執行
Unlock命令，傳感器僅可Read狀態。 - 詳細分析見后文
🌐 6. DCL全局驗證（Distributed Compliance Ledger）
- 驗證流程：
- 設備入網時向控制器提交DAC證書鏈（DAC→PAI→PAA）。
- 設備認證證書 (DAC)
- 產品認證中間證書 (PAI)
- 產品認證根證書 (PAA)
- 控制器訪問DCL節點，驗證：
- 證書有效性：PAA根證書是否在DCL信任列表。
- 設備合規性：VID/PID是否通過CSA認證，固件哈希是否匹配。
- 吊銷狀態：查詢DCL中的證書吊銷列表（CRL）。
- 動態攔截：若DCL返回未認證或已吊銷，控制器拒絕設備入網。
- 設備入網時向控制器提交DAC證書鏈（DAC→PAI→PAA）。
- 去中心化優勢：DCL由CSA成員節點共識維護，防單點篡改（如偽造證書需攻破多數節點）
看完整個Matter的安全實現流程，可以看出對于安全驗證這塊基本上都設計的非常的全面，但是開發者按照Matter的設計文檔來實現時，卻是會漏洞百出，為什么會出現這種情況呢？這里列舉幾種可能性，以及對應的坑點；
- 成本
- 拿硬件信任根和安全啟動來說，這里是需要硬件成本的，在芯片選型這塊就需要決策，如果一開始因為成本原因采用不具有安全能力的芯片的話就無從談起；
- 有些情況是選擇了具有安全能力的芯片，但是開發者卻沒有使用安全芯片的能力去設計實現，調用相關安全能力也是挺無奈的，當然這塊是偷懶行為；
- 當然了，還有一種是芯片廠商的鍋，對外宣傳具有安全能力，宣發文檔寫的該有都有，實際對接的接口文檔卻沒有辦法使用；
- 開發者理解錯誤
- 這塊屬于常見問題，類似于云端驗證和實現的部分放到客戶端去實現了；比如說動態證書部分NOC證書的生成，如果放到客戶端生成，那么攻擊者就可以自己偽造自簽NOC證書；
- 業務實現設計錯誤（偷懶）
- 當開發者已經按照所有的驗證流程來完成Matter的安全實現了，包括前面的安全芯片、設備認證、加密通信以及Matter的證書鏈；但是ACL權限卻是懶得去配置，或者說依舊是客戶端自己維護默認的，這種情況就會導致設備權限混亂的問題；
- 那么ACL規則要如何配置？
ACL規則參數解析
1. ACL 核心參數詳解
(1) Subject（主體）
-
含義：被授權操作的設備標識，即執行操作的設備 Node ID。
-
配置選項：
- 單一設備：
0x123（16 進制 Node ID） - 設備組：
Group:LightSwitches（需提前定義設備組） - 生態域（Fabric）內所有設備：
Fabric:All
- 單一設備：
-
案例模板：
Subject:Type: SingleDevice# 單一設備Value: 0x123# 開關的 Node ID
(2) Target（目標）
-
含義：被操作的資源，支持三級粒度控制。
-
配置選項：
類型 示例 作用范圍 Endpoint Endpoint: 1指定設備的單個端點（如燈泡） Cluster Cluster: OnOffServer端點內的功能模塊（如開關控制） DeviceType DeviceType: DimmableLight同一類型的所有設備（如所有調光燈） -
案例模板：
Target:Type: Cluster# 目標類型為 ClusterValue: OnOffServer# 操作 OnOff 功能Scope: Endpoint:1# 限制在端點 1 生效
(3) Permission（權限）
-
含義：定義操作級別，分三級權限。
-
配置選項：
權限 操作范圍 示例 View讀取屬性（如狀態查詢） 讀取燈泡開關狀態 Operate觸發命令（如開關控制） 發送 Toggle命令Manage管理 ACL（如增刪規則） 允許添加新控制設備 -
案例模板：
Permission: Operate# 允許觸發命令（如開關燈泡）
(4) AuthMode（認證模式）
-
含義：設備間通信的安全認證方式。
-
配置選項：
模式 適用場景 安全性 PASE配網階段臨時認證（如掃碼配對） 中低 CASE運行時長期認證（如設備間控制） 高 -
案例模板：
AuthMode: CASE# 高安全場景（如門鎖控制）
2. 特殊配置注意事項
(1) 橋接設備配置
非 Matter 設備（如 Zigbee 傳感器）需通過橋接接入：
-
橋接端點映射：將 Zigbee 設備映射為 Matter 端點和 Cluster。
-
案例片段：效果：Zigbee 傳感器可觸發 Matter 燈泡 。
Bridge:Endpoint: 2DescriptorCluster:DeviceType: MotionSensor# 映射為運動傳感器ServerList: OccupancySensing# 支持占用感知 Cluster
(2) 權限沖突解決
當多條規則沖突時，精確匹配優先：
# 規則 1：允許所有設備查看燈泡狀態ACE1:Subject: Fabric:AllTarget: Endpoint:1Permission: View# 規則 2：禁止特定開關操作燈泡ACE2:Subject: 0x999# 優先級高于 ACE1Target: Endpoint:1Permission: Deny# 顯式拒絕
3. 調試技巧
-
ACL 驗證工具：使用
chip-tool發送測試命令：./chip-tool onoff toggle 0x123 1 --paakeyt 123456 -
日志分析：檢查設備日志中的
Access Control模塊，確認規則匹配結果 。
chip-tool是Matter測試條件中的一個工具，另一篇文章中介紹該工具的具體使用。
Matter 測試套件chip-tool
4. 安全實現
Matter ACL 通過 主體-目標-權限-認證 四元組實現精細控制，開發者需注意：
- 最小權限原則：避免濫用
Manage權限。 - 認證分級：門鎖等設備強制使用
CASE。 - 橋接兼容：非 Matter 設備需完整映射端點和 Cluster
在實際開發場景中，業務和開發為了偷懶會直接所有設備端點都設置為"endpoint": 0，也就是控制網絡中所有設備都是根端點，就會導致所有設備都是管理員權限；
下面給一個完整Matter網絡ACL權限控制列表：
{"acl": {// ACL元數據"version": "Matter-1.3", // 遵循的規范版本"fabric": "0xABCD1234", // 所屬生態域標識符"description": "智能家居設備控制策略","accessControlEntries": [{// 規則1：手機App管理員權限"label": "Admin-FullAccess","subject": "0x789", // 管理員設備Node ID"target": {"endpoint": 0, // 設備根端點"cluster": "ACLServer" // 管理ACL的集群},"permission": "Manage", // 允許修改ACL規則"authMode": "CASE" // 強制證書認證[1](@ref)},{// 規則2：運動傳感器聯動所有調光燈"label": "Sensor-LightControl","subject": "0x456", // 傳感器Node ID"target": {"deviceType": "DimmableLight", // 目標設備類型"cluster": "LevelControlServer" // 亮度控制集群},"permission": "Operate", // 允許調整亮度"authMode": "CASE" // 高安全認證[2](@ref)},{// 規則3：開關控制特定燈泡"label": "Switch-Bulb1","subject": "0x123", // 開關Node ID"target": {"endpoint": 1, // 燈泡端點"cluster": "OnOffServer" // 開關集群},"permission": "Operate", // 允許開關命令"authMode": "CASE" // 標準認證[1](@ref)},{// 規則4：橋接Zigbee傳感器只讀權限"label": "Bridge-Sensor-Read","subject": "0x555", // 橋接設備Node ID"target": {"endpoint": 2, // 映射端點"cluster": "OccupancySensing" // 占用感知集群},"permission": "View", // 僅允許讀取狀態"authMode": "PASE" // 配網階段臨時認證[1](@ref)},{// 規則5：顯式拒絕未知設備"label": "Deny-Unknown","subject": "Fabric:All", // 所有設備"target": {"deviceType": "DoorLock" // 門鎖設備},"permission": "Deny", // 顯式拒絕訪問"authMode": "CASE" // 強制生效}],// 特殊配置區"securityParameters": {"certificateMode": "PAA-TRUST", // 使用根證書信任鏈[1](@ref)"groupKeyRotation": 3600 // 組密鑰輪換周期(秒)}
}
參考
IOT知識-通信協議之Matter（1）
matter的Commissioning（入網過程）整體流程、加密方式、通信信息結構_wx618b454ed38ca的技術博客_51CTO博客
)
