Skip to content

Commit

Permalink
Merge pull request #1181 from Max-zs/main
Browse files Browse the repository at this point in the history
Write a comparison between NHP and SPA
  • Loading branch information
windcbf authored Sep 12, 2024
2 parents feebcfc + d077f90 commit 0d1c2b1
Show file tree
Hide file tree
Showing 9 changed files with 342 additions and 3 deletions.
184 changes: 182 additions & 2 deletions docs/comparison.md

Large diffs are not rendered by default.

Binary file added docs/images/CPU_comparison.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/Compatibility_comparison.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/DNS_integration.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/Deployment_diagram.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/FIDO_integration.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/High-availability.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/Load_diagram.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
161 changes: 160 additions & 1 deletion docs/zh-cn/comparison.zh-cn.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,167 @@ nav_order: 3
permalink: /zh-cn/comparison/
---

- {: .fs-9 }

<small>*&nbsp; &nbsp; &nbsp; &nbsp;( 注:以下内容摘自《Applied Sciences》杂志2024年第14卷第13期的期刊论文《AHAC: Advanced Network-Hiding Access Control Framework》论文,值得特别指出的是,AHAC框架是NHP(OpenNHP)技术体系中的一个关键组成部分。本文详细介绍和比较 NHP(Next-Generation Host Protocol)与 SPA(Secure Protocol Architecture)在不同方面的表现。)*</small>

# NHP与SPA的对比
{: .fs-9 }

# 目录:
- [NHP与SPA的对比](#nhp与spa的对比)
- [目录:](#目录)
- [1. 优势对比](#1-优势对比)
- [2. 性能对比](#2-性能对比)
- [2.1 加密算法开销](#21-加密算法开销)
- [2.2 性能开销](#22-性能开销)
- [3. 高可用性对比](#3-高可用性对比)
- [4. 扩展性对比](#4-扩展性对比)
- [4.1 与DNS集成](#41-与dns集成)
- [4.2 与FIDO集成](#42-与fido集成)
- [5. 兼容性对比](#5-兼容性对比)


## 1. 优势对比

&nbsp; &nbsp; &nbsp; &nbsp;NHP通过结合噪声协议、密钥对和ECDH算法,提供强大的双向认证机制。与传统方法相比,NHP在性能、可扩展性和安全性上有显著优势。它支持多种编程语言(如C/C++、Python、Java和Go),并提供高度可扩展的架构,增强设备验证能力,防御重放攻击,彻底解决IP放大问题。NHP特别适合企业IAM系统和安全资源访问等需要强认证和加密的场景,优化了性能并提升了高可用性,确保在复杂环境中的无缝兼容性和高安全性。相比之下,SPA虽然具有一定优势,但在安全性、性能和可扩展性方面仍无法与NHP媲美。
| | SPA | NHP |
| ------------ | ------------------------------ | ------------------------------ |
| 开发语言 | C , C++ | C/C++ , Python , Java , Go |
| 通信 | 单包授权 | 噪声协议 , ECDH |
| 体系架构 | 复杂性 , 加密的数据包 , 防火墙 | 先进性 , 可扩展性 , 噪声协议 |
| 认证 | UDP 敲门 ,IP 放大问题 | 设备指纹,UDP 和 TCP 敲门 |
| 密码框架 | RSA , AES | 噪声协议 , ECDH |
| 性能 | 中等开销 ,高效 | 优化 ,最小化开销 |
| 隐藏网络能力 | 仅服务/应用的端口 | 域名 、IP和端口 |
| 可用性 | 高负载 | 高可用性 ,可扩展集群 |
| 可扩展性 | 复杂实现 | FIDO+NHP,高度可扩展,易于集成 |
| 兼容性 | 各种系统,可能需要集成 | 较高,跨平台,面向未来 |
| 安全性 | 强加密,密钥管理风险 | 地址隐藏,相互认证 |
| 应用场景 | 高安全性场景 | 可扩展的,高安全环境 |

## 2. 性能对比

### 2.1 加密算法开销

&nbsp; &nbsp; &nbsp; &nbsp;SPA 采用的是 RSA 加密算法,而 NHP 采用的是 ECC 加密算法。我们根据安全强度和密钥长度比较了 RSA 和 ECC 的性价比,如下表所示。在相同的安全标准下,ECC 算法的密钥长度显著短于 RSA 算法。此外,RSA 消息签名生成的密文大小大致等于密钥长度。因此,在验证网络消息身份时,NHP 使用更短的 ECC 随机密钥(32 字节或 64 字节)进行 ECDH 交换,而不是传输较大的 RSA2048 消息签名(256 字节)进行验证,不仅降低了计算开销,还更加高效地节省了宝贵的带宽资源。这一策略表明,NHP 在提高系统效率和资源利用率方面相较于 SPA 具有显著优势。
| 安全
| 强度(比特) | SPA (最小值公钥长度(位)) | NHP(最小值公钥长度(位)) | NHP vs SPA(密钥长度比) | 有效期 |
| ------------ | -------------------------- | ------------------------- | ---------------------- | ---------- |
| 80 | 1024 | 160-223 | 1:6 | 直到2010年 |
| 112 | 2048 | 224-255 | 1:9 | 直到2010年 |
| 128 | 3072 | 256-383 | 1:12 | 2031年以后 |
| 192 | 7680 | 384-511 | 1:20 | |
| 256 | 15360 | 512+ | 1:30 | |

&nbsp; &nbsp; &nbsp; &nbsp;我们通过实验测量了 RSA 和 ECC 的加解密时间,具体结果见下表。实验增加了加密和解密的循环次数,测试两种算法在不同情况下的性能。结果显示,尽管 RSA 和 ECC 的加解密时间随着循环次数的增加而上升,但 ECC 的时间开销始终远低于 RSA。尤其在循环次数增多时,ECC 的优势更加明显,RSA 的时间开销最高达到 ECC 的约 800 倍。这一显著差距表明,NHP 在加解密效率上明显优于 SPA,为实际应用中选择更高效的加密算法提供了有力的依据。
| 循环次数(次) | SPA | NHP |
| -------------- | -------- | ------ |
| 1 | 0.34s | 687us |
| 10 | 2.48s | 3.60ms |
| 100 | 27.54s | 0.03s |
| 200 | 61.18s | 0.06s |
| 500 | 136.23s | 0.16s |
| 1000 | 287.61s | 0.32s |
| 10000 | 2832.42s | 3.81s |


### 2.2 性能开销

&nbsp; &nbsp; &nbsp; &nbsp;为了全面评估 NHP 的性能表现,我们搭建了一个下图所示的实验环境,针对 NHP 和 SPA 进行了负载性能测试。该环境由两个主要区域组成:Agent 部署区域和网络隐身部署区域。

![部署图](/docs/images/Deployment_diagram.png)

&nbsp; &nbsp; &nbsp; &nbsp;在网络隐身部署区域,我们集成了网络隐身服务器和应用服务器作为关键组件。为了确保测试环境的稳定性和一致性,我们选用了三台配置相同的机器,每台配备 4 核 CPU 和 8G 内存。在 agent 部署区域,我们启动了 n 个 agent 服务,这些服务以每秒发送一次敲门请求的频率与网络隐身服务器通信。同时,在网络隐身服务器上部署了 JMeter 组件,用于模拟和监控其性能表现。应用服务器端同样部署了 JMeter 服务,实时跟踪网络隐身服务器的性能资源消耗情况。通过这种设置,我们能够全面监控和比较 NHP 与 SPA 的性能表现。

&nbsp; &nbsp; &nbsp; &nbsp;在保持实验环境一致性的前提下,我们按照部署方案分别选取了1、10、20、30、40、50个agent,对NHP和SPA进行了性能测试。测试结果如表4所示,其中横轴表示参与实验的agent数量,纵轴则显示测试期间的CPU占用率变化。通过这种设置,我们能够直观地观察到随着agent数量的增加,NHP和SPA在CPU资源消耗方面的不同表现。

![CPU对比](/docs/images/CPU_comparison.png)

&nbsp; &nbsp; &nbsp; &nbsp;实验结果显示,随着 Agent 数量的增加,NHP 和 SPA 的 CPU 负载均呈现上升趋势。然而,随着 Agent 数量的进一步增加,NHP 的性能优势逐渐凸显,其 CPU 负载大约维持在 SPA 的一半左右,展现出显著的效率提升。<br>
<small>*&nbsp; &nbsp; &nbsp; &nbsp;( 注:尽管理论上 NHP 的性能应较 SPA 提升约 1000 倍,但实际测试中仅提升约 1 倍。分析原因,主要因素包括网络开销对性能的显著影响、垃圾回收机制导致的性能损失,以及硬件环境差异。此外,尽管出于代码安全性和加密算法实现的考虑,我们选择了内存安全的 Go 语言开发,但其垃圾回收机制也对性能产生了一定影响。)*</small>
##

## 3. 高可用性对比

&nbsp; &nbsp; &nbsp; &nbsp;NHP 通过分布式架构实现零信任服务的高可用性,确保敲门模块和门禁模块在不同主机上部署,以避免资源占用和提升弹性扩展。即使发生故障,也能无缝切换服务,维持系统功能和响应速度。这种设计增强了系统的稳健性和稳定性,降低了服务故障对整体系统的影响,如下图所示。

![高可用架构](/docs/images/High-availability.png)

&nbsp; &nbsp; &nbsp; &nbsp;NHP 支持敲门验证服务的横向弹性扩展,能够根据实时负载动态调整服务实例数。这一功能提供了极高的弹性和可扩展性,确保在高负载下服务依然快速响应且稳定。每个服务实例均能处理敲门请求并维持业务会话,这种设计不仅提升了处理能力,还增强了容错性,保证了业务连续性和稳定性。从测试结果来看,NHP 在高可用性方面相较于 SPA 显著提升

![负载图](/docs/images/Load_diagram.png)



## 4. 扩展性对比

&nbsp; &nbsp; &nbsp; &nbsp;尽管NHP设计为数据通信提供了可信、可控、可靠和可证的基础保障,但考虑到通信场景和环境的多样性和复杂性,NHP还需具备良好的扩展性以适应不同的定制需求。NHP的扩展性体现在几个方面:

- 其双向通信机制相比SPA的单向敲门机制,提供了更丰富的扩展能力,可以隐藏资源的真实IP地址并支持数据通信前后的密钥交换,增强隐私计算和数据流通场景的安全性。

- 通过授权服务提供商(ASP)接口,NHP能够将资源请求方的请求内容透传给ASP,实现更严格的身份认证与权限控制。

- NHP的资源标识支持任意字符串形式,包括中英文及符号,为数据资源提供更强的描述性,并具备DNS解析功能,提供更安全、加密和隐私的域名解析服务。

&nbsp; &nbsp; &nbsp; &nbsp;因此,NHP的扩展性架构涵盖了与DNS和FIDO的集成等典型应用场景。

### 4.1 与DNS集成

&nbsp; &nbsp; &nbsp; &nbsp;DNS作为互联网基础服务在网站运行中至关重要,但其安全性长期未被重视,且因使用不可靠的UDP协议,存在诸多安全漏洞,如DNS劫持和拒绝服务攻击。因此,加强DNS安全至关重要。通过集成网络隐身技术,DNS解析通过双向加密通道进行,确保了保密性和防篡改能力,同时只有经过身份认证的用户才能解析,从而有效防御DDoS攻击和劫持。具体实现方案如下图所示,我们的方法能够显著提升了DNS的安全性,为用户提供了更可靠的DNS服务。

![DNS集成方案](/docs/images/DNS_integration.png)

- 步骤1:网络隐身代理(如客户端、浏览器等)通过域名与网络隐身服务器发起请求。

- 步骤2:一旦网络隐身服务器接收到来自网络隐身代理的域名数据包请求,它会随即向应用认证服务器发起查询认证请求,以验证该请求的合法性和权限。

- 步骤3:认证服务器在接收到网络隐身服务器发出的认证请求消息后,经过严格的验证流程,一旦确认其身份真实有效,便会授予其访问权限。随后,认证服务器会迅速向网络隐身服务器回复一份包含目标资源真实IP地址、端口号等关键信息的授权访问凭据。

- 步骤4:在成功通过授权查询之后,网络隐身服务器会迅速向目标资源所在的门禁系统发起开门请求。这一请求旨在确保网络隐身代理能够畅通无阻地访问到所需的目标资源,从而顺利完成后续操作。

- 步骤5:门禁系统在接收到网络隐身服务器发出的开门请求后,会立即执行严格的验证程序。这一验证过程旨在确保所请求的目标资源与被保护资源完全吻合,以确保系统的安全性和可靠性。一旦验证通过,门禁系统将迅速开通从网络隐身代理到被保护资源的连接通道,从而允许其进行无障碍的访问。

- 步骤6:一旦门禁系统成功为网络隐身代理开启了访问权限,网络隐身服务器会迅速确认这一操作,并返回目标资源的IP地址和端口信息。随后,这些信息将被迅速传递给网络隐身代理,以便其能够准确地定位并访问目标资源。

- 步骤7:网络隐身代理在接收到被保护资源的IP地址和端口信息后,随即启动对目标资源的正常业务访问权限,确保访问过程顺畅无阻,实现高效且安全的资源交互。

### 4.2 与FIDO集成

&nbsp; &nbsp; &nbsp; &nbsp;尽管FIDO在Web身份认证方面表现出色,但服务器的潜在漏洞仍可能被黑客利用,从而绕过FIDO的认证,直接入侵服务器进行数据盗窃或破坏。将FIDO与NHP集成,可以有效弥补FIDO在漏洞防护方面的不足,为互联网暴露面提供更全面的防御方案。具体实现方案如下图所示,详细实现步骤如下。

![FIDO集成方案](/docs/images/FIDO_integration.png)

- (1) 用户代理(即代理)向网络隐身服务器(即服务器)发送一个端口敲门数据包,旨在尝试访问会话中已认证但保证水平相对较低的敏感资源。

- (2) 服务器在接收到端口敲门数据包后,将资源访问请求转发给应用提供商。

- (3) 应用提供商响应并将回复消息发送给服务器,同时将端口敲门消息重定向到可信的认证机构请求更高保证级别的基于FIDO的认证。

- (4) 服务器在收到应用提供商的响应后,将重定向指示器传递给代理。

- (5) 代理在收到重定向消息后,直接打开FIDO认证页面。

- (6) 服务器在接收到代理的FIDO认证页面后,迅速向认证机构发起FIDO认证请求。

- (7) FIDO服务器在收到请求消息后完成FIDO请求并响应。

- (8) 认证机构在经过严格的FIDO验证过程后,向服务器返回基于FIDO的认证响应。

- (9) 一旦FIDO身份确认真实有效且认证成功,服务器请求访问控制(即AC)系统打开应用提供商的端口以接受代理的连接。

- (10) 服务器通知代理认证成功,并提供资源访问的IP/端口。

- (11) AC系统成功授予代理访问权限。

- (12) 代理与应用提供商建立连接以访问资源。

## 5. 兼容性对比

&nbsp; &nbsp; &nbsp; &nbsp;与SPA协议相比,NHP的一个关键目标是对信创环境以及国内零信任标准体系的良好兼容性。在加密算法方面,NHP支持国际密码算法(如RSA、SHA256、AES)和国密算法(如SM2、SM3、SM4),并能根据数据包头的长度调整加密时间。在软硬件兼容性方面,NHP适配了国内外主流的CPU硬件和操作系统,包括鲲鹏、x86、龙芯、申威等。此外,NHP符合即将颁布的国家标准《信息安全技术零信任参考体系架构》的规范要求,确保了与该标准的兼容性,如下图所示。

![兼容性对比](/docs/images/Compatibility_comparison.png)

- [英文版](/docs/comparison.md){: .label .fs-4 }

---

0 comments on commit 0d1c2b1

Please sign in to comment.