🔒 深入了解 MemCloud 的安全对等身份验证：设备如何在局域网安全共享 RAM
Source: Dev.to
当我发布 MemCloud（一个面向 macOS & Linux 的分布式 RAM 引擎）时，收到的最大疑问是：
“让其他设备存储你的 RAM 不会很危险吗？它是怎么保证安全的？”
下面是一篇针对 MemCloud 背后的身份验证、加密和信任模型的深度剖析——专为热爱协议、威胁模型和密码学设计的工程师而写。本文只关注安全 & 身份验证层。
（如果你对 MemCloud 还不熟悉，请先阅读介绍博客——本文假设你已经了解基本概念。）
威胁模型
| 威胁 | 示例 |
|---|---|
| 冒充 | 恶意设备假装是受信任的对等节点 |
| 中间人攻击（MITM） | 攻击者拦截或篡改握手流量 |
| 重放攻击 | 重复使用旧的握手消息 |
| 未授权内存访问 | 设备悄悄加入集群 |
| 会话劫持 | 窃取或预测流量密钥 |
MemCloud 的协议针对上述所有威胁提供了解决方案。
身份密钥
每台设备都有一对长期身份密钥，存放在：
~/.memcloud/identity_key- 算法： Ed25519（快速 + 安全）
- 用途： 仅用于对握手记录进行签名——从不用于加密。
这相当于一种设备证书，却不需要 PKI 的复杂性。
身份验证流程（Noise XX）
MemCloud 使用受 Noise Protocol Framework 启发的身份验证流程，具体为 Noise_XX 模式，选择它的原因是：
- 双方均从未认证状态开始
- 支持首次使用信任（TOFU）
- 提供相互认证
- 确保前向保密性
简化握手
A → B : eA, nonceA
B → A : eB, nonceB
A → B : identity proof (encrypted)
B → A : identity proof (encrypted)eA 与 eB 为临时 X25519 公钥。
每条握手消息都会被哈希进一个记录：
H = Hash(H || message)这可以防止重放、降级以及跨会话攻击，随后该记录会被用于密钥派生。
密钥派生 & 身份证明
-
计算共享密钥：
shared_secret = DH(eA, eB) -
派生会话密钥：
session_key = HKDF(shared_secret + transcript_hash) -
每台设备使用其长期身份密钥对记录哈希进行签名：
signature = Sign(TranscriptHash, IdentityKey)- 签名会被加密、绑定到记录，且不能被重放。
- 若验证失败，连接会立即关闭。
流量加密
最终的流量密钥如上所述派生，并使用 ChaCha20‑Poly1305 AEAD，这对于高速 LAN 通信来说是理想选择。
受信任的对等节点
受信任的对等节点信息存放在：
~/.memcloud/trusted_devices.json对已知节点的后续连接：
- 仍然进行密码学认证
- 跳过交互式批准
- 不能被悄悄伪装或替换
身份验证失败会怎样？
如果出现以下任意情况，MemCloud 会拒绝会话：
- 身份签名失败
- 记录哈希不匹配
- 握手格式错误
- 设备不在受信任列表中
- 同意层阻止授权
被拒绝的节点将无法：
- 读取你的 RAM
- 接收块数据
- 加入集群
- 冒充之前的节点
为什么不使用 TLS？
TLS 功能强大，但并非 P2P LAN 内存引擎的最佳选择：
- MemCloud 追求 零配置；Noise 开箱即用。
- 目标延迟是 10 ms 以下；Noise 的轻量二进制协议更快。
- 相互认证、身份隐藏、前向保密和 TOFU 等需求天然由 Noise 模式满足。
测试结果
| 攻击尝试 | 结果 |
|---|---|
| 重放 | 通过记录不匹配被阻止 |
| MITM | 通过身份证明不匹配被阻止 |
| 冒充 | 通过签名无效被阻止 |
| 降级尝试 | 不可能实现 |
| 有效负载篡改 | 通过 MAC 失败被阻止 |
迄今为止，该协议在真实 LAN 环境中表现极佳。
计划中的改进
- 🔄 信任撤销广播
- 🖥 GUI 信任管理器
- 🛡 可选硬件支持的身份密钥
- 🔁 会话恢复
- 📦 跨节点加密复制
欢迎贡献代码。
资源
- 身份验证代码：
memnode/src/net/auth - 主仓库：
- 文档：
- CLI 信任管理器：
memcli trust
MemCloud 表面看起来很简单——“设备在 LAN 上共享 RAM”——但其底层是一套精心设计的安全协议，确保这种共享真正安全。
如果你想进一步了解 P2P 二进制协议、内存隔离模型、配额强制或零拷贝流设计，随时告诉我！