90、覆盖网络中节点完整性的语义认证-优快云博客

本文链接：https://blog.youkuaiyun.com/android/article/details/149535200

覆盖网络中节点完整性的语义认证

1. 系统组件

为实现节点完整性的语义认证，系统包含以下组件：
- 可应用测量值的数据库。
- vTPM 模块接口。
- 底层内省功能接口。
- 用于将节点连接到 VPN 的 OpenVPN 插件。
- Gnutella 代码的扩展。

认证协议用 Java 实现，认证库由约 1500 行代码的 4 个 Java 类组成，监控则需要 1000 行 Java 代码，包括一个与内省功能交互的小包装器。Gnutella 代码更新以支持认证约需 1500 行代码。

2. 实验场景

进行了两个实验：
- VPN 实验 ：覆盖网络实现一个 VPN，Mon - VM 运行 VPN 客户端加入远程 Intranet，远程认证模块在 Nove 上充当 VPN 服务器。为保护 VPN 客户端的完整性，持续监控评估静态工具返回的断言。VPN 服务器经过修改以处理远程认证协议，使用 Java SSL 库和 TPM/J 访问 TPM 值并创建 VPN 连接，OpenVPN 通过插件扩展以实现远程认证。
- Gnutella 网络实验 ：对 Gnutella 网络进行扩展以支持认证。

3. 远程认证模块

远程认证模块是认证协议的核心，它初始化协议并实现覆盖节点 Nove 与尝试连接到覆盖网络的节点上的 A - VMreq 之间的通信。
- 触发条件 ：每次 Mon - VMreq 打开与 Nove 的连接以加入覆盖网络时，协议触发。A - VMove 上的远程认证模块作为守护服务等待连接并启动握手阶段。
- 不同场景下的形式 ：在 VPN 覆盖网络中，它是 OpenVPN 插件；在 P2P 测试场景中，它是 A - VM 上的一个模块，与 Gnutella 代码中的新线程协作管理 A - VM 之间的控制通道。
- 握手过程 ：A - VMove 上的远程认证模块与 A - VMreq 之间的握手包括相互认证和初始参数交换。握手结束后，A - VMreq 对 Mon - VMreq 应用初始测量集，并将结果和 TrustedBoot 计算的哈希链传输到 A - VMove 上的远程认证模块。A - VMove 比较哈希值以认证 A - VMreq 的完整性并发现 Mon - VMreq 的当前配置，然后定义一个保证级别并传达给 A - VMreq，A - VMreq 将该级别存储在其数据库中并进行持续监控。
- 测量策略 ：远程认证模块可应用额外测量，基于 XML 编码策略，有按需和频率两种策略。按需策略用于检测针对节点的攻击；频率策略要求 A - VM 以给定频率计算某些内存区域的哈希值并返回给模块。

以下是 A - VMreq 与 A - VMove 上的远程认证模块之间协议的步骤：
1. Mon - VMreq 打开与 A - VMove 上的远程认证模块的连接。
2. A - VMove 上的远程认证模块检查用户凭证。
3. 如果 Mon - VMreq 已认证，A - VMove 上的远程认证模块调用函数查询数据库。
4. A - VMove 上的远程认证模块通过函数或映射 Mon - VMreq 地址获取 A - VMreq 的 IP 地址。
5. A - VMove 上的远程认证模块与 A - VMreq 建立控制通道。
6. A - VMove 上的远程认证模块发送带有一些参数的握手消息。
7. A - VMreq 计算 OvApp 的哈希值，并将其与 TPM 计算的底层系统哈希链一起发送到 A - VMove 上的远程认证模块。
8. A - VMove 上的远程认证模块将 A - VMreq 的值与预期值进行比较。
9. A - VMove 上的远程认证模块向 A - VMreq 发送包含应应用测量的 XML 配置文件。
10. 在频率策略中，A - VMove 上的远程认证模块发送会话超时值，A - VMreq 在超时后计算测量并将结果发送到 A - VMove 上的远程认证模块。
11. 从此时起，A - VMreq 测量实现 OvApp 的进程和内核的完整性，并将测量结果返回给 A - VMove 上的远程认证模块。

mermaid 流程图如下：

graph LR
    A[Mon - VMreq 打开连接] --> B[检查用户凭证]
    B --> C{已认证?}
    C -- 是 --> D[查询数据库]
    C -- 否 --> END[结束]
    D --> E[获取 A - VMreq IP 地址]
    E --> F[建立控制通道]
    F --> G[发送握手消息]
    G --> H[A - VMreq 计算并发送哈希值]
    H --> I[比较哈希值]
    I --> J[发送 XML 配置文件]
    J --> K{频率策略?}
    K -- 是 --> L[发送超时值]
    K -- 否 --> M[持续监控]
    L --> M[持续监控]

4. P2P 覆盖网络中的完整性测量

采用 VIMS 保护 P2P 覆盖网络并非完全透明，因为计算完整性测量时，修改了 Gnutella 代码中的三个不同组件，分别实现握手、下载和 Ping 消息交换。Gnutella 代码中的一个新线程实现评估器与 OvApp 之间的消息交换。
- 节点连接过程 ：当节点尝试连接到 Gnutella 覆盖网络时，新线程接收请求并通知其节点上的 A - VM 作为评估器与请求节点上的 A - VM 交互。节点成功认证后可加入覆盖网络，之后执行标准 Gnutella 协议，必要时请求节点也可认证 Gnutella 对等节点。
- 握手组件修改 ：握手组件修改后实现了修订版的 Gnutella 协议，步骤如下：
1. Mon - VMreq 与 Mon - VMove 打开 TCP 连接。
2. Mon - VMreq 向 Mon - VMove 发送字符串 “GNUTELLA CONNECT/0.6”。
3. Mon - VMreq 向 Mon - VMove 发送包含认证新字段的头部。
4. Mon - VMove 联系 A - VMove 告知 Mon - VMreq 想加入 Gnutella 覆盖网络。
5. A - VMove 使用 UDP 联系 A - VMreq 请求 Mon - VMreq 的完整性测量。
6. A - VMreq 应用初始完整性测量（对 Mon - VMreq 进行哈希测量）并将结果发送到 A - VMove。
7. A - VMove 将响应传达给 Mon - VMove。
8. 如果响应为正，Mon - VMove 向 Mon - VMreq 发送字符串 “GNUTELLA/0.6 200 OK”，否则关闭连接。

之后步骤 4 到 8 角色反转，由 Mon - VMreq 要求 A - VMove 认证 Mon - VMove。

以下是两个节点之间握手消息交换的示例：

1)GNUTELLA CONNECT/0.6
Node: 123.123.123.123:1234
Pong - Caching: 0.1
GGEP: 0.5
Ip - Att: 123.123.123.123
Port - Att: 6666
AttEveryXPing: 5
Dom - Name: Mon - VMreq
2)ATTESTATION MESSAGE
Code - Message: ATTESTATION_ON_HANDSHAKE
Ip - Node: 123.123.123.123
Port - Node: 1234
Ip - Att: 123.123.123.123
Port - Att: 6666
AttEveryXPing: 5
Dom - Name: Mon - VMreq
3)ATTESTATION MESSAGE
Code - Message: REQUEST_ATTESTATION
Dom - Name: Mon - VMreq
4 - 5)Integrity measurements on Mon - VMreq
6)ATTESTATION MESSAGE
Code - Message: ATTESTATION_ON_HANDSHAKE
Attestation: OK
7)ATTESTATION MESSAGE
Code - Message: ATTESTATION_ON_HANDSHAKE
Attestation: OK
8)GNUTELLA/0.6 200 OK
User - Agent: gtk - gnutella/0.95
Pong - Caching: 0.1ss
GGEP: 0.5
Ip - Att: 234.234.234.234
Port - Att: 8888
AttEveryXPing: 5
Dom - Name: Bar
Private - Data: 5ef89a

当 Mon - VM 收到 “OK” 字符串后，重复步骤 2 - 8 以认证 Mon - VMove 的完整性。文件下载和 Ping 消息组件也进行了修改以包含完整性测量。例如，文件下载时，涉及的节点的 A - VM 协作认证两个 Mon - VM 的完整性；Ping 消息可触发认证，且包含基于对 OvApp 的测量和哈希断言的完整性结果。当 Mon - VM 收到来自另一个 Mon - VM 的 Ping 消息时，它回复 Pong，若 Ping 消息数量超过阈值，则启动两个 Mon - VM 的相互认证。当对等 Mon - VM 的认证失败时，评估器 A - VM 通知本地 Mon - VM 和所有相邻 A - VM，它们再通知相应 Mon - VM 上的 Gnutella 应用关闭与被踢 Mon - VM 的连接。

覆盖网络中节点完整性的语义认证

5. 评估开销

接下来讨论启动认证和持续监控的开销。运行原型的系统采用 Pentium Centrino Duo T2250 1.7GHz 处理器。在所有测试中，A - VM Linux 内核版本为 2.6.18 - xen，为运行 Linux Debian 发行版的 Mon - VM 分配 128MB 物理内存，为 A - VM 分配 874MB 物理内存。

测试场景	相关参数
VPN 覆盖网络测试	在测试床 VPN 覆盖网络中，当完整性测量每 5 到 60 秒发送一次时，观察 Mon - VM 上 IOzone 基准测试的吞吐量。结果表明，网络延迟掩盖了协议开销，认证导致的开销可忽略不计。
多节点连接测试	当 3 个节点同时尝试连接到 VPN 覆盖网络时，通过 IOzone 计算 Mon - VM 上的认证开销。该图显示了与未执行认证的解决方案相比，作为两次连续认证之间时间间隔（超时）的函数的额外开销（百分比）。在这种情况下，当测量结果每 60 秒发送一次时，开销几乎可以忽略不计。

在 Gnutella 覆盖网络测试中，评估 Mon - VM 内核和 OvApp 认证的开销。节点加入 Gnutella 覆盖网络、下载文件或交换预定义数量的 Ping 消息时都会进行认证。当 Mon - VM 仅运行 Gnutella 应用程序时，执行时间最多增加 10%；如果运行其他应用程序，只要每分钟最多进行一次认证，下载速度的减慢可以忽略不计。就通信开销而言，为实现认证，交换消息的数量从原始协议的 4 条最多增加到 8 条，但其中 2 条消息是在同一节点上的 VMs 之间交换的。

mermaid 流程图展示开销评估流程：

graph LR
    A[启动测试] --> B{VPN 覆盖网络测试?}
    B -- 是 --> C[测量不同间隔完整性测量下的吞吐量]
    C --> D[分析网络延迟与协议开销关系]
    B -- 否 --> E{多节点连接测试?}
    E -- 是 --> F[计算多节点连接时的认证开销]
    F --> G[对比有/无认证的开销差异]
    E -- 否 --> H{Gnutella 覆盖网络测试?}
    H -- 是 --> I[评估内核和 OvApp 认证开销]
    I --> J[分析不同应用场景下的开销情况]
    D --> K[得出开销结论]
    G --> K
    J --> K