在很多安全系统里，“隔离”常常只是一个软件概念。

比如：

权限隔离。

进程隔离。

容器隔离。

网络隔离。

账户隔离。

这些隔离方式当然有价值，但它们大多仍然运行在同一个软件世界里。

只要操作系统被攻陷。

只要管理员权限被滥用。

只要运行环境被控制。

只要接口路径被绕过。

所谓隔离就可能变成一种“逻辑上的隔离”，而不是“执行路径上的硬边界”。

Havenlon 的三域隔离模型，想解决的正是这个问题。

---

一、为什么需要三域隔离

Havenlon 面对的不是普通登录系统。

它面对的是资金操作、链上交易、企业权限、自动化执行和 AI agent 请求。

这些场景有一个共同特点：

一旦执行发生，后果往往不可逆。

所以 Havenlon 不能只问：

“请求是否合法？”

还必须问：

“这个请求从哪里来？”

“它经过了哪些边界？”

“哪个系统有权处理它？”

“哪个系统只能转发它？”

“哪个系统可以最终执行它？”

如果所有能力都放在一个软件系统里，风险会非常集中。

一个 Linux 系统既负责联网，又负责解析请求，又负责保存敏感状态，又负责签名执行。

一个云端系统既做审批，又能直接触发执行。

一个应用模块既能展示交易，又能修改参数，又能调用签名。

这些设计都会让执行路径变得过于脆弱。

Havenlon 的做法是：

把不同风险等级的能力拆到不同域里。

连接归连接。

仲裁归仲裁。

执行归执行。

这就是三域隔离模型。

---

二、三域分别是什么

Havenlon 的三域隔离模型包括：

REE  →  Security Arbiter  →  SEE

也就是：

开放连接域 → 仲裁与网关域 → 核心执行域

三个域的信任等级不同，职责不同，边界也不同。

1. REE：开放连接域

REE 是 Rich Execution Environment，也就是开放连接域。

它通常由 Linux SoC 或类似应用处理器承担。

它负责：

• 网络通信；

• TCP/IP、TLS 等连接能力；

• 数据编解码；

• 用户交互；

• 上层应用逻辑；

• 与 SaaS 或外部系统通信。

但 REE 的安全等级是：

不可信环境。

文档中明确把 REE 定义为 Untrusted Zone，并要求它不得存储任何私钥明文，也不得执行任何签名操作。

这点非常关键。

Havenlon 不是因为 REE 很强大，所以信任它。

恰恰相反，Havenlon 默认 REE 可能被攻陷。

REE 可以联网。

REE 可以交互。

REE 可以处理复杂数据。

但 REE 不能拥有最终执行权。

---

2. Security Arbiter：仲裁与网关域

第二个域是 Security Arbiter Domain。

这是 Havenlon 的信任边界。

它通常由 MCU + Secure Element 组成。

它的职责不是简单转发，而是：

• 对所有外部请求进行合法性校验；

• 建立并维护加密通信通道；

• 对进入核心域的数据进行预处理；

• 过滤不合法、不完整、不可信的请求；

• 把外部复杂环境和核心执行域隔开。

文档中明确要求：未通过校验的请求不得进入核心执行域。

这就是 Arbiter 的价值。

它不是普通网关。

也不是普通 MCU 控制板。

它是执行链路中的“仲裁层”。

它决定一个请求是否有资格继续向核心执行域靠近。

在 Havenlon 里，REE 可以被看作外部世界的入口。

但 Arbiter 才是真正的边界门。

---

3. SEE：核心执行域

第三个域是 SEE，Secure Execution Environment，也就是核心执行域。

这是 Havenlon 最受保护的区域。

它负责：

• 执行签名操作；

• 执行密钥派生；

• 处理敏感数据；

• 承载核心执行能力；

• 保证内部状态不直接暴露。

文档中要求 SEE 仅接受来自仲裁域的指令，并且不得直接暴露内部状态。

也就是说，SEE 不直接面对网络。

不直接面对云端。

不直接面对用户应用。

不直接面对开放操作系统。

它只接受经过 Arbiter 验证后的受控指令。

这就是 Havenlon 的核心隔离思路：

真正能执行的地方，不应该直接暴露在复杂软件世界里。

---

三、REE 可以强，但不能被信任

很多系统的问题，是把“功能强大”和“可信”混在一起。

Linux 很强。

云端很强。

浏览器很强。

移动 App 很强。

AI agent 很强。

但强大不等于可信。

REE 作为开放连接域，天然要处理复杂输入：

• 网络包；

• TLS 连接；

• SaaS 指令；

• 用户界面；

• JSON / CBOR / Protobuf；

• 外部 API；

• 自动化请求；

• 日志和状态展示。

这些东西越复杂，攻击面越大。

所以 Havenlon 不要求 REE 永远安全。

Havenlon 只要求：

即使 REE 出问题，核心执行能力也不能被直接拿走。

这就是三域隔离的第一层意义。

REE 可以失败。

但 REE 的失败，不应该等于执行权泄露。

---

四、Arbiter 是物理边界上的裁判

Arbiter 这个名字很重要。

它不是 Router。

不是 Proxy。

不是 Bridge。

而是 Arbiter。

也就是仲裁者。

它的存在意味着：

外部请求不能直接进入核心执行域。

所有请求都必须经过一个独立的安全裁决层。

这个裁决层要回答：

• 请求来源是否可信；

• 请求签名是否有效；

• 请求状态是否回滚；

• 通信链路是否完整；

• 数据是否被篡改；

• 请求是否符合进入核心域的条件；

• 是否存在异常行为或风险信号。

如果答案不成立，请求就停在 Arbiter 之外。

这也是 Havenlon 和普通硬件钱包的重要区别之一。

普通钱包的核心问题通常是：

“用户确认后能否签名？”

Havenlon 的问题是：

“这个请求有没有资格穿过 Arbiter，抵达真正的执行域？”

---

五、SEE 不应该知道太多外部世界

一个安全执行域不应该承担太多复杂逻辑。

它不应该直接处理复杂网络协议。

不应该直接面对不可信输入。

不应该参与 UI 展示。

不应该直接连接云端。

不应该解析大量业务上下文。

因为复杂性越高，攻击面越大。

SEE 应该保持窄接口、强约束、少暴露。

它只处理经过前面域过滤、裁剪、验证后的执行材料。

这也是为什么 Havenlon 要把系统拆成三域，而不是把所有东西都堆到一个安全芯片里。

不是所有逻辑都应该进核心执行域。

真正重要的是：

让核心执行域足够小、足够封闭、足够难绕过。

---

六、三域隔离不是为了复杂，而是为了降低信任假设

从产品表面看，三域架构会增加复杂度。

多一个域，就多一层通信。

多一个边界，就多一套协议。

多一个安全组件，就多一些工程成本。

但从安全架构上看，这是必要的。

因为它减少了系统必须相信的东西。

Havenlon 不需要相信 Linux 一定安全。

不需要相信云端账户一定安全。

不需要相信前端展示一定没被篡改。

不需要相信网络环境一定可信。

不需要相信所有管理员都不会犯错。

不需要相信 AI agent 一定理解正确。

系统只需要保证：

执行必须穿过受控边界，最终进入受保护的核心执行域。

这就是三域隔离模型的意义。

它不是增加复杂性。

它是减少盲目信任。

---

七、三域隔离如何对应执行路径

Havenlon 的安全执行路径可以简化为：

外部请求
  ↓
REE：接收、连接、编解码、展示
  ↓
Arbiter：校验、解密、仲裁、过滤
  ↓
SEE：签名、密钥派生、敏感执行
  ↓
加密结果返回

文档中也定义了类似的安全数据流：云端对请求进行加密封装，REE 透明转发，仲裁域执行验证与解密，核心域执行操作，结果以密文形式返回。

注意这里的关键点：

REE 不是决策者。

REE 是连接者。

Arbiter 不是普通中继。

Arbiter 是边界裁判。

SEE 不是业务系统。

SEE 是核心执行域。

这三个角色不能混在一起。

一旦混在一起，执行边界就会变软。

---

八、三域模型如何抵御常见风险

1. 如果操作系统被攻陷

攻击者控制 REE，也不应该直接拿到私钥或签名能力。

因为 REE 不存储私钥明文，也不执行签名操作。

2. 如果网络请求被篡改

请求需要经过 Arbiter 校验。

未通过校验的请求不得进入核心执行域。

3. 如果云端账户被控制

云端指令不能直接等于硬件执行。

请求仍然必须穿过本地边界、策略验证和核心执行条件。

4. 如果内部人员试图绕流程

执行不只取决于某个人的权限，还取决于完整执行链、策略约束和硬件边界。

5. 如果 AI agent 生成错误请求

AI 可以提出请求，但请求必须被 Arbiter 和后续策略判断约束，不能直接进入执行。

这就是三域隔离带来的防线。

它不是防止某个单点永远不出问题。

它是假设单点可能出问题，但错误不能直接变成执行权。

---

九、Havenlon 的三域不是概念图，而是执行边界

很多安全架构图看起来都很漂亮。

但真正的问题是：

这些边界是否真实存在？

是否能阻断请求？

是否能拒绝执行？

是否能防止软件绕过？

是否能让核心执行能力不暴露？

Havenlon 的三域隔离模型不是为了画架构图。

它是为了让执行路径产生真实边界。

REE 负责连接，但不能执行。

Arbiter 负责仲裁，阻断不合格请求。

SEE 负责核心执行，但不直接暴露。

这三个域共同构成 Havenlon 的硬件强制执行基础。

---

结语

Havenlon 的三域隔离模型，本质上是在回答一个问题：

如何让执行能力不被开放软件环境直接触达？

答案是：

把连接、仲裁、执行拆开。

让 REE 处理复杂世界。

让 Arbiter 承担信任边界。

让 SEE 保持封闭执行。

这样，即使外部环境不可信，执行路径仍然需要经过受控边界。

这就是 Havenlon 的三域隔离模型。

它不是为了证明某个软件永远安全。

而是为了确保：

软件即使出问题，也不能直接拥有最终执行权。

延伸阅读

本文基于 Havenlon 官方执行架构规范整理。

完整技术规范可参考：

Havenlon Execution Architecture Specification