本規範定義了一種新的架構層:執行控制層(Execution Control Layer)。
在該模型中,執行不再由軟件系統決定,
而是由基於硬件信任根的物理信任邊界進行強制約束與裁決。
1 規範性說明(Normative Conventions)
1.1 規範性語言(Normative Language)
本規範中的關鍵詞采用如下定義:
· 必須(MUST):表示絕對要求,不可違反
· 不得(MUST NOT):表示絕對禁止
· 應(SHOULD):表示推薦要求,在合理情況下應遵循
· 可以(MAY):表示可選行爲
除非另有說明,所有安全相關約束均爲“必須(MUST)”。
本文件採用 RFC 2119 中定義的規範性術語。
1.2 術語定義(Terminology)
本規範中使用如下術語:
· 執行(Execution):指鏈上交易或敏感操作的最終生效過程
· 執行權(Execution Authority):指允許操作被執行的最終決策權
· 請求(Request, R):指一筆待處理的操作指令
· 交易上下文(Transaction Context, τ):包含交易參數、簽名、設備狀態等信息
· 硬件信任根(Hardware Root of Trust):系統信任的最底層硬件基礎
1.3 符號說明(Notation)
本規範採用如下符號:
· ∧:邏輯與(AND)
· ∈:屬於(Membership)
· Δ:變化量(Delta)
· ⊗:正交組合(Orthogonal Composition)
1.4 縮略語(Abbreviations)
· REE:Rich Execution Environment
· SEE:Secure Execution Environment
· SE:Secure Element
· RBAC:Role-Based Access Control
· ABAC:Attribute-Based Access Control
2 執行控制體系總覽(Execution Control Architecture Overview)
2.1 系統定義(System Definition)
Havenlon 定義了一種以硬件爲信任根的執行控制體系。
系統不依賴軟件環境的可信性,而通過多層約束機制,將執行權限制在物理可控邊界內。
執行權僅在所有安全條件同時滿足時成立。
2.2 分層模型(Layered Architecture)
本系統由四個層級構成:
2.2.1 安全模型層(Security Model Layer)
定義系統安全性與執行准入條件:
· 系統安全函數:
· 請求准入函數:
2.2.2 隔離與信任層(Isolation & Trust Layer)
定義執行邊界與密鑰保護機制:
· 硬件信任根(RoT)
· 三域隔離架構(REE / Arbiter / SEE)
· 密鑰生命週期與物理綁定
2.2.3 決策層(Decision Layer)
定義執行是否成立:
· 執行決策函數:(τ)
· 多策略風控模型(Cloud / Edge / Physical)
· 熔斷機制(Veto Principle)
2.2.4 執行層(Execution Layer)
定義執行路徑與不可繞過機制:
· 標準執行流程(SOP)
· 多方審批與多籤機制
· 硬件最終執行裁決
2.3 執行控制原理(Execution Control Principle)
系統執行權由多因子聯合決定:
該公式定義系統最終執行權的成立條件。僅當請求通過准入驗證()、執行決策成立()且滿足標準執行流程()時, 才爲真。
任一條件不滿足,執行必須被拒絕,且不得進入後續執行路徑。
2.4 約束
系統必須保證:
· 未通過准入驗證的請求不得進入決策層
· 未通過決策函數的請求不得進入執行層
· 未滿足執行流程的請求不得被執行
2.5 不可繞過性(Non-Bypassability)
系統必須滿足:
· 執行路徑不可被跳過
· 決策結果不可被僞造
· 軟件層不得繞過硬件執行
2.6 安全邊界定義(Security Boundary)
系統安全邊界由以下組件共同構成:
· 硬件信任根(Hardware RoT)
· 策略決策模型()
· 執行流程約束(SOP)
2.7 設計目標(Design Objectives)
系統必須實現以下目標:
· 執行權分散:不存在單點控制
· 策略正交:不同安全因子相互獨立
· 硬件約束:執行必須經過物理驗證
· 可審計性:所有決策與執行均可驗證
3 分佈式硬件可信架構
3.1 概述 (Abstract)
本系統將零信任架構從“訪問控制”擴展至“執行控制”,並在硬件層建立執行權的不可繞過約束。
系統不依賴網絡邊界的安全性。所有執行請求必須在不可信環境下被驗證,並僅在滿足硬件約束條件時被允許執行。
本架構通過以下機制構建可信執行體系:
· 硬件信任根(Hardware Root of Trust)
· 密碼學正交機制(Cryptographic Orthogonality)
· 端雲雙重審計(Dual-Layer Edge-Cloud Audit)
系統必須保證:
· 抗物理克隆
· 抗中間人攻擊(MITM)
· 執行結果具備不可否認性(Non-repudiation)
3.2 核心安全範式 (The Core Security Paradigm)
系統安全性定義爲一組級聯約束的組合函數:
其中:
· Physical:硬件信任因子(Hardware Trust Factor)
· Contract:意圖綁定因子(Intent Binding Factor)
· Audit:審計驗證因子(Audit Factor)
· :由不可信執行環境引入的安全熵損耗(Security Entropy Loss)
3.2.1 安全約束定義
系統必須滿足以下條件:
· 任意單一組件的失效不得導致執行權泄露
· 安全性不得依賴軟件環境可信性
· 執行權必須由硬件約束
3.3 符號與機制定義(Nomenclature & Mechanisms)
3.3.1 物理信任約束(Physical Constraint ⊗)
物理信任由以下組件構成:
· 安全控制核心(Secure MCU)
· 邊緣網關(Gateway Hub)
系統必須滿足:
· 任一組件被攻破,不得導出完整密鑰能力
· 兩者之間必須構成正交安全關係,而非線性疊加
3.3.2 契約驗證機制(Contract Verification)
系統採用基於 Passkey / FIDO2 的驗證機制。
系統必須保證:
· 所有操作必須綁定用戶顯式意圖
· 簽名必須與交易內容一致
· 不允許盲籤
3.3.3 審計機制(Audit Mechanism)
系統採用雙層審計結構:
· 邊緣審計()
· 雲端審計()
3.3.3.1 邊緣審計必須
· 驗證本地通信鏈路完整性
· 檢測物理連接異常
· 過濾高頻異常行爲
3.3.3.2 雲端審計必須
· 執行全局風控策略
· 分析跨設備行爲
· 管理設備生命週期
3.3.4 環境風險項()
系統必須假設以下風險始終存在:
· 操作系統漏洞
· 側信道攻擊
· 網絡監聽
系統安全性不得依賴這些風險的消失。
3.4 密鑰派生與存儲機制 (Key Derivation & Storage)
3.4.1 密鑰保護模型
系統必須採用 UID 綁定的密鑰封裝機制。
3.4.1.1 密鑰派生
派生密鑰定義爲:
系統必須滿足:
· :派生密鑰(Derived Key),用於後續解密或簽名操作的中間密鑰
· :用戶輸入的認證因子(User Secret),作爲口令熵來源
· :由硬件真隨機數生成器(TRNG)產生的隨機鹽值,用於增強口令抗暴力破解能力
· :PBKDF2 迭代次數,必須滿足抗暴力破解的安全強度要求(Iter ge 200000)
· :安全芯片的唯一物理標識(Unique Identifier),用於綁定設備物理身份
· :基於口令的密鑰派生函數,用於從低熵輸入(PIN)中生成抗暴力破解的中間密鑰
· :密鑰擴展函數,用於融合多個輸入因子並生成最終派生密鑰
· 派生密鑰 必須同時依賴用戶口令因子與設備物理身份,任何單一因子均不得獨立構成有效密鑰。
3.4.1.2 密鑰解密
· :會話密鑰(Session Key),用於後續加密通信或簽名操作
· :派生密鑰(Derived Key),由口令與設備身份共同生成
· :由安全芯片封裝的密文(Encrypted Payload)
· :基於 AES-GCM 的認證解密函數(Authenticated Decryption)
系統必須滿足:
· 解密必須帶認證標籤(Auth Tag)
· PIN 錯誤必須導致解密失敗
· 解密失敗不得產生任何有效狀態
3.5 抗克隆約束
系統必須保證:
· 密鑰與設備物理 UID 綁定
· Flash 數據複製不得恢復密鑰
· 不同設備之間密鑰不可遷移
3.6 動態證明與審計拓撲 (Dynamic Attestation)
3.6.1 訪問控制函數
定義請求的准入條件。僅當設備證書受信任()、請求籤名有效()且狀態未回滾()時, = 1;否則 = 0。
任一條件不滿足,請求必須被拒絕,且不得進入執行路徑。
3.6.2 系統約束
系統必須滿足:
· 所有設備必須具備可信證書鏈
· 所有請求必須帶簽名
· 單調計數器不得回滾
3.6.3 防攻擊能力
系統必須能夠檢測並拒絕:
· 重放攻擊
· 克隆設備
· 僞造設備
3.7 傳輸層雙模安全架構 (Dual-Mode Transport Layer Security)
3.7.1 模式定義
系統支持兩種模式:
3.7.1.1 模式 A:雲端仲裁模式(Cloud-Centric)
· SaaS 爲信任錨點
· Hub 僅作爲加密通道
3.7.1.2 模式 B:本地執行模式(Edge-Centric)
· Hub 作爲信任錨點
· 本地直接完成驗證
3.7.2 安全約束
系統必須滿足:
· 任一模式下執行路徑不可繞過
· 任一模式下密鑰不可暴露
3.7.3 安全差異
表示雲端模式與本地模式之間的安全差異,其中 爲雲端仲裁模式的安全係數, 爲本地執行模式的安全係數。
在非受控環境下,雲端模式具有更高安全性;在受控環境下,兩者安全性趨於等價。
系統必須滿足:
· 非受控環境優先使用雲端模式
· 受控環境允許使用本地模式
3.8 結論(Conclusion)
本系統在不可信執行環境下,通過以下機制建立安全邊界:
· 硬件信任根
· 動態遠程證明
· 密鑰物理綁定
系統必須保證:
· 攻擊成本從軟件級提升至物理級
· 執行路徑不可被繞過
· 密鑰不可被複制或導出
4 核心安全哲學(Security Philosophy)
本系統基於“零信任(Zero Trust)”與“縱深防禦(Defense-in-Depth)”構建。
系統不依賴網絡邊界的安全性,必須假設:
· 外部網絡環境爲不可信
· 操作系統可能被完全攻陷
系統通過硬件信任根(Hardware Root of Trust)與多域物理隔離機制,確保核心資產在上述條件下仍保持機密性與完整性。
4.1 核心約束
系統必須滿足:
· 核心資產(私鑰與簽名邏輯)不得暴露於非可信環境
· 即便操作系統獲得 Root 權限,攻擊者不得訪問、提取或篡改核心資產
4.2 威脅模型與防禦邊界(Threat Model)
4.2.1 攻擊向量假設
系統必須假設以下攻擊能力存在:
· 邏輯層攻擊:操作系統提權(Root Exploit)、遠程代碼執行(RCE)、中間人攻擊(MITM)
· 物理層攻擊:調試接口入侵(JTAG/UART)、總線監聽、Flash 提取
· 側信道攻擊:功耗分析(DPA/SPA)、電磁分析、故障注入(Glitching)
4.2.2 防禦目標
系統必須實現:
計算環境(Computation Environment)與密鑰環境(Key Environment)的物理隔離與邏輯解耦。
4.3 三域隔離架構(Tri-Domain Isolation Architecture)
系統採用三域物理隔離架構,各域之間僅允許通過受控通道通信。
4.3.1 開放連接域(REE, Rich Execution Environment)
· 硬件載體:Application Processor(Linux SoC)
· 安全級別:不可信環境(Untrusted Zone)
職責:
· 網絡通信(TCP/IP, TLS)
· 數據編解碼
· 用戶交互
約束:
· 不得存儲任何私鑰明文
· 不得執行任何簽名操作
4.3.2 仲裁與網關域(Security Arbiter Domain)
· 硬件載體:MCU + Secure Element
· 安全級別:信任邊界(Trust Boundary)
職責:
· 對所有外部請求進行合法性校驗
· 建立並維護加密通信通道
· 對進入核心域的數據進行預處理
約束:
· 未通過校驗的請求不得進入核心執行域
4.3.3 核心執行域(SEE, Secure Execution Environment)
· 硬件載體:隔離安全核心(Isolated Security Core)
· 安全級別:受保護執行區(Protected Zone)
職責:
· 執行簽名操作
· 執行密鑰派生
· 處理敏感數據
約束:
· 僅接受來自仲裁域的指令
· 不得直接暴露內部狀態
4.4 信任鏈與密鑰生命週期(Key Lifecycle)
4.4.1 密鑰生成
系統必須滿足:
· 私鑰必須由硬件隨機數源(TRNG)生成
· 私鑰必須在安全芯片內部生成
· 私鑰不得以明文形式出現在外部總線或內存
4.4.2 密鑰使用與存儲
系統必須滿足:
· 所有密鑰操作必須在安全芯片內部完成
· 私鑰必須具備不可導出屬性
· 外部系統不得訪問私鑰
4.4.3 狀態保護
系統必須實現:
· 單調計數器防止狀態回滾
· 會話密鑰機制防止重放攻擊
4.5 執行路徑與數據流安全(Secure Pipeline)
系統定義如下執行路徑:
1. 雲端對請求進行加密封裝
2. REE 進行透明轉發
3. 仲裁域執行驗證與解密
4. 核心域執行操作
5. 結果以密文形式返回
5 安全約束
系統必須保證:
· 數據在傳輸過程中始終保持加密狀態
· 非授權節點不得解析明文數據
· 總線監聽不得獲取有效信息
5.1 物理與供應鏈安全
5.1.1 主動物理防禦
系統應具備:
· 電壓、溫度、頻率異常檢測能力
· 異常檢測觸發數據擦除機制(Zeroization)
5.1.2 供應鏈可信
系統必須滿足:
· 每臺設備具備唯一證書鏈
· 系統支持安全啓動(Secure Boot)
· 未簽名固件不得執行
5.2 結論
本架構通過硬件信任根與多域隔離機制,實現對執行環境的物理約束。
系統必須保證:
· 核心資產不暴露於不可信環境
· 執行路徑不可被繞過
· 攻擊成本由軟件級提升至物理級
6 動態風控與策略引擎(Dynamic Policy & Risk Control)
6.1 概述(Overview)
本系統定義一類基於多策略源的執行控制模型。
系統安全不依賴單一策略節點,而由多個獨立安全因子共同決定。
執行權僅在所有必要條件同時滿足時成立。
6.2 核心原則
系統必須滿足:
· 執行決策由多個獨立策略源共同決定
· 任一策略失敗必須導致執行失敗
· 策略驗證必須覆蓋身份、意圖與環境
6.3 通信與決策分離(Separation of Communication and Decision)
系統必須區分通信層與決策層:
6.3.1 通信層(Communication Layer)
職責:
· 保證請求能夠被完整傳輸
· 不參與執行決策
6.3.2 決策層(Decision Layer)
職責:
· 判斷請求是否具備執行條件
· 輸出最終執行許可
6.3.3 約束
系統必須保證:
· 通信成功不得直接導致執行
· 執行必須依賴決策層輸出
6.4 執行決策模型(Execution Decision Model)
系統將執行權定義爲如下函數:
其中:
· τ 表示交易上下文(Transaction Context)
· 所有因子取值爲 {0,1}
6.4.1 用戶意圖完整性(Intent Integrity)
系統必須驗證:
· 用戶簽名與交易內容一致
· 不允許盲籤
6.4.2 雲端策略(Cloud Policy)
系統必須驗證:
· 賬戶權限合法
· 目標未命中黑名單
· 滿足全局額度限制
6.4.3 邊緣策略(Edge Policy)
系統必須驗證:
· 地址在本地白名單中
· 滿足私有額度策略
· 滿足位置約束
6.4.4 物理約束(Physical Constraints)
系統必須驗證:
· 設備未被物理篡改
· 電源與時鐘狀態正常
· 生命週期狀態合法
6.5 熔斷原則(Veto Principle)
系統採用乘積邏輯(邏輯與):
6.6 約束
系統必須保證:
· 任一因子失敗必須終止執行
· 不得存在單點放行路徑
6.7 策略風控模型(Policy Model)
系統採用基於屬性的訪問控制(ABAC)模型。
6.7.1 資產維度(Asset Constraints)
系統必須支持:
· 單筆額度限制
· 累計額度限制(Velocity)
· 多籤審批機制
6.7.2 路由與目標約束
系統必須支持:
· 限制鏈類型與資產類型
· 限制目標合約地址
· 地址白名單機制
6.7.3 環境維度(Context Constraints)
系統必須支持:
· 時間窗口控制
· 網絡與地理圍欄
6.7.4 權限維度(Role & Quorum)
系統必須支持:
· 角色權限控制(RBAC)
· 多籤授權(M-of-N)
6.8 雙策略引擎(Dual Policy Engine)
系統採用雲端與邊緣雙策略架構。
6.8.1 雲端策略引擎(Cloud Engine)
職責:
· 執行全局風控
· 管理審批流程
· 提供黑名單與行爲分析
6.8.2 邊緣策略引擎(Edge Engine)
職責:
· 執行本地私有策略
· 支持離線運行
· 保證策略不可繞過
6.9 約束
系統必須保證:
· 本地策略在離線情況下仍生效
· 雲端策略無法繞過本地策略
· 任一策略失敗必須阻斷執行
6.10 決策流程(Decision Workflow)
執行流程如下:
1. 用戶發起請求
2. 雲端執行一級風控
3. 邊緣執行二級風控
4. 匯聚決策結果
5. 核心執行域執行操作
6.11 約束
系統必須保證:
· 所有策略在執行前完成驗證
· 未通過策略驗證的請求不得執行
6.12 結論
系統通過多策略因子組合,實現對執行權的嚴格約束。
系統必須保證:
· 執行權由多因子共同決定
· 任一因子失效即阻斷執行
· 執行路徑不可被繞過
7 企業級資金安全執行標準 (SOP)
7.1 概述(Overview)
本系統通過流程治理(Process Governance)對資金操作進行約束。
所有關鍵操作(包括資金劃轉、白名單變更、策略調整)必須經過如下單向執行鏈:
發起 → 風控 → 審批 → 硬件執行
7.2 核心約束
系統必須滿足:
· 所有關鍵操作必須通過完整執行鏈
· 任一階段缺失,操作不得執行
· 執行鏈不得被跳過或回溯
7.3 權限原則
系統必須保證:
不存在任何單一角色、單一系統或單一管理員擁有資產的最終處置權。
7.4 PIN 驗證機制(Local Verification)
系統採用基於硬件的本地驗證機制。
7.5 約束
系統必須滿足:
· PIN 驗證僅在安全芯片內部完成
· PIN 不得上傳至雲端
· PIN 不得存儲於操作系統或緩存
7.6 安全屬性
系統必須保證:
· 網絡中僅傳輸驗證結果,不傳輸 PIN 本身
· 網絡數據不得用於反推出原始 PIN
7.7 四階段執行流程(4-Stage Execution Flow)
7.7.1 階段一:發起(Initiation)
角色:經辦人(Operator)
系統必須保證:
· 請求必須由綁定設備發起
· 請求參數在發起時鎖定
· 後續流程中參數不得被修改
7.7.2 階段二:雲端風控(Cloud Audit)
角色:SaaS 系統
系統必須執行:
· 黑名單校驗
· 風控規則校驗(時間、額度等)
· 審批流程路由
7.7.3 階段三:協同審批(Authorization)
角色:審批人(Approver)
系統必須保證:
· 審批必須基於獨立設備完成
· 審批必須顯示完整交易內容
· 不允許盲籤
7.7.3.1 多簽約束
系統必須支持:
· M-of-N 多籤機制
· 高風險操作必須滿足多籤條件
7.7.4 階段四:硬件執行(Execution)
角色:安全執行域(Hardware Root of Trust)
系統必須保證:
· 執行前驗證全部簽名完整性
· 校驗執行鏈完整性
7.7.4.1 執行約束
系統必須滿足:
· 任一校驗失敗必須拒絕執行
· 硬件必須具備最終裁決權
· 軟件不得繞過硬件執行
7.8 熔斷機制(Execution Veto)
系統必須保證:
· 任一環節異常必須觸發執行中止
· 中止操作不得產生部分執行結果
· 不得存在降級執行路徑
7.9 異常場景安全性(Resilience)
7.9.1 場景一:雲端賬戶被攻陷
系統必須保證:
· 無物理設備無法完成簽名
· 單一雲端指令不得觸發執行
7.9.2 場景二:內部人員濫用權限
系統必須保證:
· 發起與審批職責分離
· 單人無法完成完整執行鏈
· 多籤機制覆蓋高風險操作
7.9.3 場景三:網絡攻擊(MITM)
系統必須保證:
· 通信鏈路加密(mTLS)
· 所有請求具備端到端簽名
· 數據篡改必須被檢測並拒絕
7.10 結論
系統通過流程約束與硬件執行機制,實現對資金操作的強制控制。
系統必須保證:
· 執行鏈完整性不可被繞過
· 權限分散,不存在單點控制
· 所有操作具備可審計性與可驗證性
8 執行控制體系總結(Execution Control Summary)
8.1 執行權定義
系統執行權由多層安全機制聯合決定:
8.2 分層收斂關系
系統執行控制體系由以下層級構成:
· Access(R):定義請求准入條件
· 隔離與信任層:提供執行邊界與密鑰保護
· E_final(τ):定義執行決策條件
· SOP:定義執行路徑
8.3 收斂約束
系統必須保證:
· 所有執行必須通過准入驗證
· 所有執行必須滿足決策模型
· 所有執行必須遵循標準流程
8.4 執行控制閉環
系統形成如下閉環:
8.5 系統約束
系統必須保證:
· 任一階段失敗必須終止執行
· 不得存在繞過路徑
· 執行必須可驗證、可審計
8.6 安全屬性總結
系統必須具備以下屬性:
· 不可繞過性(Non-Bypassability)
· 多因子決策(Multi-Factor Execution)
· 權限分散(No Single Point Control)
· 硬件約束執行(Hardware-Enforced Execution)
8.7 體系總結
本系統通過多層安全約束,實現對執行權的嚴格控制。
執行權不屬於任何單一組件,而由:
· 身份驗證
· 策略決策
· 流程約束
· 硬件執行
共同決定。