## 1. Project Overview & Quickstart (OpenNHP/opennhp)

## File: README.md

[](https://github.com/OpenNHP/opennhp/blob/master/README.md)
[](https://github.com/OpenNHP/opennhp/blob/master/README.zh-cn.md)
[](https://github.com/OpenNHP/opennhp/blob/master/README.zh-tw.md)
[](https://github.com/OpenNHP/opennhp/blob/master/README.de.md)
[](https://github.com/OpenNHP/opennhp/blob/master/README.ja.md)
[](https://github.com/OpenNHP/opennhp/blob/master/README.fr.md)
[](https://github.com/OpenNHP/opennhp/blob/master/README.es.md)



# OpenNHP: Open Source Zero Trust Security Toolkit

[](https://github.com/OpenNHP/opennhp/actions/workflows/ubuntu-build.yml)
[](https://github.com/OpenNHP/opennhp/tags)

[](https://codecov.io/gh/OpenNHP/opennhp)
[](https://deepwiki.com/OpenNHP/opennhp)

**OpenNHP** is a lightweight, cryptography-powered, open-source toolkit implementing Zero Trust security for infrastructure, applications, and data. It is the reference implementation of the [**Cloud Security Alliance (CSA)**](https://cloudsecurityalliance.org/) *[Network-infrastructure Hiding Protocol (NHP) specification](https://cloudsecurityalliance.org/artifacts/stealth-mode-sdp-for-zero-trust-network-infrastructure)*, and features two core protocols:

- **Network-infrastructure Hiding Protocol (NHP):** Conceals server ports, IP addresses, and domain names to protect applications and infrastructure from unauthorized access.
- **Data-content Hiding Protocol (DHP):** Ensures data security and privacy via encryption and confidential computing, making data *"usable but not visible."*

**[Website](https://opennhp.org) · [Vision](https://opennhp.org/vision/) · [Live Demo](https://opennhp.org/demo/) · [Documentation](https://docs.opennhp.org) · [Discord](https://discord.gg/CpyVmspx5x)**

---

## Why OpenNHP

The modern internet is a [dark forest](https://en.wikipedia.org/wiki/Dark_forest_hypothesis). Attackers — increasingly backed by LLMs that scan, fingerprint, and exploit at machine speed via [Autonomous Vulnerability Exploitation](https://arxiv.org/abs/2404.08144) — treat every reachable service as a target. [Gartner projects](https://www.gartner.com/en/newsroom/press-releases/2024-08-28-gartner-forecasts-global-information-security-spending-to-grow-15-percent-in-2025) AI-driven cyberattacks will rise rapidly. Traditional defenses authenticate users *after* the network lets them in, leaving exposed ports, IPs, and domains as a permanent attack surface.

> **In the AI era, VISIBILITY = VULNERABILITY.**

OpenNHP inverts that model: **invisible until trusted.** Every port, IP, and hostname sits behind a default-deny gate. Access is granted only after a cryptographically signed knock is authenticated and authorized out-of-band. Attackers can't exploit what they can't discover.

### The third-generation network hiding protocol

NHP is the next step in a line of "hide the service first" designs:

| Generation | Protocol | Limitations |
|---|---|---|
| 1 | Port Knocking | Plaintext, replay-prone |
| 2 | Single Packet Authorization (SPA) | Shared secrets, one-way, typically hides ports only, typically C/C++ |
| **3** | **NHP** | Modern crypto, bi-directional with status, hides domain + IP + ports, stateless and horizontally scalable, memory-safe Go |

NHP slots in alongside existing IAM, DNS, FIDO, and Zero Trust policy engines rather than replacing them — it extends your stack instead of forking it.

---

## Architecture

OpenNHP follows a modular design with three core components, inspired by the [NIST Zero Trust Architecture](https://www.nist.gov/publications/zero-trust-architecture):



| Core Component | Role |
|-----------|------|
| **NHP-Agent** | Client that sends encrypted knock requests to gain access |
| **NHP-Server** | Authenticates and authorizes requests; runs separately and is architecturally decoupled from the protected host |
| **NHP-AC** | Access controller that manages firewall rules on the protected server |

| Addon Component | Role |
|-----------|------|
| **NHP-Relay** | HTTP-to-UDP bridge enabling browser-based agents to send NHP knocks via HTTPS |
| **NHP-KGC** | Key Generation Center for Identity-Based Cryptography (IBC) |

### Protocol flow

1. Agent sends an encrypted knock (`NHP_KNK`) to the Server.
2. Server validates the knock and sends an operation request (`NHP_AOP`) to the AC.
3. AC opens the firewall and replies (`NHP_ART`) to the Server.
4. Server returns an acknowledgment (`NHP_ACK`) with access info to the Agent.
5. Agent reaches the protected resource through the AC.

### Cryptography

OpenNHP ships with two interchangeable cipher suites:

- **`CIPHER_SCHEME_CURVE`** — Curve25519 + AES-256-GCM + BLAKE2s
- **`CIPHER_SCHEME_GMSM`** — SM2 + SM4-GCM + SM3

Both are driven by the [Noise Protocol Framework](https://noiseprotocol.org/). An Identity-Based Cryptography (IBC) mode is available via the Key Generation Center (KGC).

> For protocol details, deployment models, and cryptographic design, see the [documentation](https://docs.opennhp.org).

---

## Repository Structure

```
opennhp/
├── nhp/              # Core protocol library (Go module)
│   ├── core/         # Packet handling, cryptography, Noise Protocol, device management
│   ├── common/       # Shared types and message definitions
│   ├── utils/        # Utility functions
│   ├── plugins/      # Plugin handler interfaces
│   ├── log/          # Logging infrastructure
│   └── etcd/         # Distributed configuration support
└── endpoints/        # Daemon implementations (Go module, depends on nhp)
    ├── agent/        # NHP-Agent daemon
    ├── server/       # NHP-Server daemon
    ├── ac/           # NHP-AC (access controller) daemon
    ├── db/           # NHP-DB (Data Broker for DHP)
    ├── kgc/          # NHP-KGC (Key Generation Center)
    └── relay/        # NHP-Relay daemon
```

---

## Quick Start

### Prerequisites

- Go 1.26+
- `make`
- Docker and Docker Compose (for the full-stack demo)

### Build

```bash
# Build all components
make

# Build individual daemons
make agentd    # NHP-Agent
make serverd   # NHP-Server
make acd       # NHP-AC
make db        # NHP-DB
make relayd    # NHP-Relay
make kgc       # NHP-KGC

```

### Test

```bash
cd nhp && go test ./...
cd endpoints && go test ./...
```

### Run with Docker

```bash
cd docker && docker-compose up --build
```

Follow the [Quick Start tutorial](https://docs.opennhp.org/nhp_quick_start/) to simulate the full authentication workflow in a Docker environment.

---

## Contributing

We welcome contributions! Please read [CONTRIBUTING.md](CONTRIBUTING.md) before submitting pull requests.

**Note:** All commits must be signed with a verified GPG or SSH key.

```bash
git commit -S -m "your message"
```

---

## Security

Found a vulnerability? Please follow the responsible-disclosure process in [SECURITY.md](SECURITY.md) rather than opening a public issue.

---

## Sponsors

<a href="https://layerv.ai">
  
</a>
&nbsp;&nbsp;
<a href="https://www.atlascloud.ai/">
  
</a>
&nbsp;&nbsp;
<a href="https://cloud.tencent.com/">
  
</a>

---

## License

Released under the [Apache 2.0 License](LICENSE).

## Contact

- Email: [support@opennhp.org](mailto:support@opennhp.org)
- Discord: [Join our Discord](https://discord.gg/CpyVmspx5x)
- Website: [https://opennhp.org](https://opennhp.org)

---

## File: docs/zh-cn/build.zh-cn.md

---
layout: page
title: 编译源代码
nav_order: 7
permalink: /zh-cn/build/
---

# 编译OpenNHP
{: .fs-9 }


---

## 1. WSL环境准备

**提示：** Windows 10/11下可以通过`WSL`子系统来运行Linux，详细请见WSL官方文档：<https://learn.microsoft.com/zh-cn/windows/wsl/install>

- **【开启WSL功能】** 在Win10上，需要首先开启WSL才能使用WSL安装Linux，设置界面请见下图。
   
- **【WSL上安装Linux】** 推荐在WSL上安装Ubuntu Linux，通过PowerShell运行以下命令安装：

   ```bat
   wsl --update
   wsl --install -d Ubuntu
   ```

   如果遇到以下问题，参考：<https://blog.csdn.net/weixin_44293949/article/details/121863559>

   ```text
   无法从 'https://raw.githubusercontent.com/microsoft/WSL/master/distributions/DistributionInfo.json’提取列表分发。无法解析服务器的名称或地址
   Error code: Wsl/WININET_E_NAME_NOT_RESOLVED
   ```

- **【WSL环境的IP地址】** 在WSL的Linux环境中，运行以下命令获取IP地址：

|        主机        |                    查看IP地址的命令                     |
| :----------------: | :-----------------------------------------------------: |
|   WSL中Linux主机   |            `hostname -I \| awk '{print $1}'`            |
| WSL宿主Windows主机 | `ip route show \| grep -i default \| awk '{ print $3}'` |

## 2. 系统需求

- 2.1 `Go语言`环境：**Go 1.26** 。安装包下载地址: <https://go.dev/dl/>
  - **Windows与macOS**环境下，通过下载的安装程序来安装Go。
  - **Linux**环境下可以直接通过管理工具安装： `sudo apt install golang `
  - 安装成功后，运行命令`go version` 来查看Go版本号。
  - **Windows与macOS**环境下，通过下载的安装程序来安装Go。
  - **Linux**环境下可以直接通过管理工具安装：`sudo apt install golang` 或者通过以下命令手动安装：

   ```bash
      1. sudo apt-get update
      2. wget https://go.dev/dl/go1.21.0.linux-amd64.tar.gz
      3. sudo tar -xvf go1.21.0.linux-amd64.tar.gz
      4. sudo mv go /usr/local
      5. export GOROOT=/usr/local/go
      6. export GOPATH=$HOME/go
      7. export PATH=$GOPATH/bin:$GOROOT/bin:$PATH
      8. source ~/.profile
   ```

  - 安装成功后，运行命令`go version` 来查看Go版本号。
- 2.2 `GCC`环境：
  - **Linux与macOS**：**GCC 8.0**或以上。
    - 查看GCC版本的命令：`gcc -v`
    - 安装GCC： `sudo apt install build-essential`
  - **Windows**:
    1. 第一步：**安装mingw64**。mingw64可以通过msys2的包管理工具进行下载。安装msys2系统要求、下载与安装教程见：<https://www.msys2.org/>。
    

    2. 第二步：**安装GCC**。在msys2的控制台输入命令：

       ```bash
       pacman -S mingw-w64-ucrt-x86_64-gcc
       ```

    3. 第三步：**配置GCC**。将GCC工具路径加入Windows的 *%PATH%* 环境变量。例如：mingw-w64-gcc的安装路径为`C:\Program Files\MSYS2\`， 则需要运行命令

       ```bat
       setx PATH "%PATH%;C:\Program Files\MSYS2\ucrt64\bin
       ```
       执行成功之后，打开新的命令行窗口，检查*gcc*的版本号
       ```bat
       gcc --version
       ```

  - **提示：** Windows下可以通过`WSL`子系统来运行Linux，详细请见WSL官方文档：<https://learn.microsoft.com/zh-cn/windows/wsl/install>
    - 推荐在WSL上运行Ubuntu最新版v22，在Windows上的PowerShell运行以下命令安装：
      ```bat
      wsl --install --distribution Ubuntu-22.04
      ```

<small>*注：如果 2.1 和 2.2 已完成，直接在项目目录下执行编译命令 `.\build.bat` 时，通常会遇到 `系统找不到指定的路径`或 ` 'lib' 不是内部或外部命令，也不是可运行的程序或批处理文件。` 的错误。2.3 提供了解决该问题的方法，供参考使用。*</small>

- 2.3 `lib`环境：


  - 在编译运行的命令中使用了 lib 工具，这是用于生成 .lib 文件的工具，通常用于链接静态库或导出符号表（在 Windows 中生成 .lib 文件以便与 .dll 文件配合使用）。遇到的错误提示 lib 不是内部或外部命令，表示系统找不到 lib 工具。

  - **解决（'lib' 不是内部或外部命令，也不是可运行的程序或批处理文件）问题 ：** 安装 Visual Studio 和 Visual Studio tools。

    - lib 工具是微软的库管理工具，通常随 Visual Studio 的 Microsoft Build Tools 安装。确保你已安装 Visual Studio，并且选择了 C++ 生成工具（C++ Build Tools）组件，其中包括 lib.exe。

    - 如果还没有安装 Visual Studio，可以从 Visual Studio 官方网站下载安装：https://visualstudiomicrosoft.com/zh-hans/ 安装时，选择“桌面开发(C++)”工作负载，它包含 lib.exe 及其他必要的工具。

    - 安装 Visual Studio 后，确保使用 Visual Studio 开发者命令行（Developer Command Prompt） 来运行包含 lib 命令的 `build.bat `文件。这个命令行工具会自动加载构建工具的环境变量，如 lib.exe

   - **解决（系统找不到指定路径的错误）问题 ：** 更改`bulid.bat`文件中的路径

     - 打开 `build.bat` 文件，找到
     ```bat
     call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" x64
     ```

     - 修改为你自己的 visual studio目录下安装路径。比如：
     ```bat
     call "F:\develop\visualstu\VC\Auxiliary\Build\vcvarsall.bat" x64
     ```

- 2.4 `clang`编译环境(可选):

  - **提示：**
    - 关于clang编译工具，clang 只支持Linux，不支持windows，windows下无需安装clang。
    - 关于eBPF模块编译，eBPF不支持windows，eBPF只支持Linux及内核5.6版本以上。
  - 查看clang版本的命令：`clang --version`
  - **Linux Ubuntu**:
    - 安装clang llvm libbpf-dev：`sudo apt install clang llvm libbpf-dev`
  - **Linux Centos**:
    - 安装clang llvm libbpf-dev：`sudo yum install clang llvm libbpf-dev -y`


## 3. 编译

1. 拉取代码仓库

   ```bash
   git clone https://github.com/OpenNHP/opennhp.git
   ```

2. Go环境

   ```bash
   go env -w GOPROXY="https://goproxy.cn,direct"
   ```

3. 编译构建
   - **Linux与macOS**：运行代码根目录下脚本
   `make`
   - **Windows**：运行代码根目录下*BAT*文件
   `build.bat`
   <small>*（注：如果在windows下编译过程中出现错误，请尝试此编译方法：在Visual Studio的developer command prompt for VS命令窗口中，切换到项目目录，执行`./build.bat`命令）*</small>
   - **Linux下编译eBPF**: 运行代码根目录下脚本
   `make ebpf`
   <small>*（注：命令 `make ebpf`，会连带编译ebpf模块）*</small>

## 4. 结果

编译出来的二进制文件都在代码目录下的`release`子目录下。

- **NHP-Server**的可执行文件和配置文件： `release\nhp-server` 子目录下
- **NHP-AC**的可执行文件和配置文件： `release\nhp-ac` 子目录下
- **NHP-Agent**的可执行文件和配置文件： `release\nhp-agent` 子目录下
- **NHP-DB**的可执行文件和配置文件： `release\nhp-db` 子目录下
- **NHP-KGC**的可执行文件和配置文件： `release\nhp-kgc` 子目录下
- 所有二进制文件打包成一个`tar`文件:  `release\archive` 子目录下

---

---

## File: docs/zh-cn/code.zh-cn.md

---
layout: page
title: 源代码解读
nav_order: 8
permalink: /zh-cn/code/
---

# OpeNHP代码解读
{: .fs-9 }


---

## 1. 层级架构

1. 上层逻辑组件层负责UDP的连接建立、维护与断开
2. Device层负责：1.将上层的消息明文转为NHP报文并发送到连接；2.将从连接收到的NHP报文转化为消息明文并提供上层处理
3. 上层逻辑组件提供


## 2. 连接管理

1. 上层逻辑组件可以建立并维护多个连接UdpConn，根据实际需求创建所需对象成员。每一个UdpConn起一个线程进行收发包操作。
2. 每一个UdpConn需要建立一个Device层的ConnData，并向Device ConnData传递实际连接中的远端地址，报文收发通道，cookie等。
3. 每一个UdpConn允许进行多次双向的transaction或单向发包。（agent除外，原则上agent每次请求都创建一个新的连接）
4. 每一个transaction都建立一个自身的线程和通道用于维持交互操作，超时后自行销毁。Local transaction（本地创建的交互）由device统一管理，Remote transaction（远端创建的交互）由远端连接管理，transaction的回应在收发包时需要找出相应的transaction线程进行后续操作。

## 3. 对象命名

1. 上层逻辑组件在收发方向上可能具有多重身份，Device层中使用initiator和responder表示发起方和接收方。

## 4. 报文缓冲区的创建与销毁（回收）

1. 为了提高吞吐率，报文缓冲区不采用自动垃圾回收机制而采用waitpool分配回收机制。
2. 接收：device创建报文缓冲区接收网络数据，根据NHP包头对报文进行解析与校验。解析结果存储在ResponderSessionParams结构中（名称不好理解，可能会改变）。明文消息仍然会使用报文缓冲区。缓冲区的销毁分两种情况，单向通信的结构体在上层应用获取明文消息后销毁。transaction接收缓冲区在transaction结束后销毁。
3. 发送：device创建报文缓冲区，填充包头并对消息进行加密后存储在InitiatorSessionParams结构中并发送。transaction发送在未收到对端回应时会重试发送。缓冲区的销毁分两种情况，单向通信的结构体在发送后销毁。transaction发送的缓冲区在transaction结束后销毁。

**消息的加密与解密：**
连接中接收到的UDP原始数据会被device解析并放入device的MsgToPacketQueue队列中，等待后端处理。
发送消息到连接时，需构建initiatorsessionstarter结构传入消息信息与连接信息，放入device的MsgToPacketQueue队列中，device会将消息进行加密发出。

## 5. NHP-Device 架构设计

1. Device负责NHP报文与消息的转换。Device初始化时需要指定类型和私钥。Device视自身类型只对相应的包进行处理。

2. 用于承载发送和接收报文的buffer比较大，所以由Device的内存Pool统一发放并回收（如果依赖于Go后台垃圾回收，高并发时会造成大量内存开销）。所以在开发时一定要注意buffer的分配**Device.AllocatePoolPacket\(\)** 和回收**Device.ReleasePoolPacket\(\)**。

   - 报文buffer回收点位于
     - 发送报文被发送后（本地transaction除外）
     - 接收报文解析完毕时（远程transaction除外）
     - 本地或远程transaction线程停止时

3. 上层逻辑调用接口**SendMsgToPacket**将消息转换成加密报文并发送到连接。

4. 上层逻辑调用接口**RecvPacketToMsg**将加密报文解析成消息后放入**DecryptedMsgQueue**队列并等待处理（通常情况）。

   - 特殊情况：如果请求发起方已指定接收通道，解析后的消息会被送到请求方指定的消息通道**ResponseMsgCh**，而不放进常规消息队列进行排队。

5. 交互（**transaction**）：一次请求需要等待一次回复的操作称为交互。一次由Device发起的交互请求为本地交互（**LocalTransaction**），一次由Device接收到的交互请求为远程交互（**RemoteTransaction**）。由于回应报文需要继承请求报文生成的**ChainKey**，所以所有的交互分发由Device进行管理。

6. 连接上下文（**ConnectionData**）：由上层逻辑传入的与连接相关的所有信息，Device在加密消息后将报文发送到连接。一个连接可以进行多个**transaction**。

7. 在建立发送请求时，需要创建**MsgAssembler**结构体。

   - Agent和AC必须填写消息类型**HeaderType**、对端**RemoteAddr**、对端公钥**PeerPk**和消息明文**Message**（如无特殊情况都采用消息压缩）。将填写好的**MsgAssembler**发给各自的**sendMessageRoutine\(\)** 即可进行新连接的建立或寻找已存在连接并进行转换后报文的发送。

   - Server必须填写消息类型**HeaderType**、连接上下文**ConnData**、对端公钥**PeerPk**和消息明文**Message**（如无特殊情况都采用消息压缩）。将填写好的**MsgAssembler**发给**Device.SendMsgToPacket\(\)** 即可进行转换后报文的发送。

   - 如果存在交互，可以直接使用上一条获得的 **\*PacketParserData**填入**MsgAssembler**结构体的**PrevParserData**字段，从而可以省略填写**RemoteAddr**、**ConnData**、**PeerPk**。

   - 如果请求期待回复数据，需要创建一个接收**PacketParserData**的通道，并对**MsgAssembler**结构体的**ResponseMsgCh**字段赋值。

## 6. NHP-Server

### 6.1 NHP-Server 架构设计


1. Server启动时监听特定端口，等待Agent和AC进行连接。并由Agent或AC主动触发向Server的通信。不存在Server向Agent或AC主动建立连接的情况，通常情况下这种连接会跨防火墙或NAT导致不能建立。
   - 特殊情况：Server在收到Agent发起的敲门处理时，鉴权后需要主动向AC发起开门请求，并等待回应。

2. 发送消息时，向**sendMsgCh**发送创建好的**MsgAssembler**（必须从已有连接中指定**ConnData**）。**MsgAssembler**经过加密后会从此连接发出

3. 接收到报文时，会将报文进行解密获取明文消息。由**msghandler**分别进行处理。

### 6.2 NHP-Server 配置文件

`etc/config.json`

```
/* Detailed source-code truncated for AI context efficiency. */
```

## 7. NHP-AC

### 7.1 NHP-AC 架构设计

1. AC支持与多台Server互相进行通信。所有连接均为AC主动向Server发起。AC通过发送心跳包和NHP-AOL包维持与Server的连接。

2. AC与Server通信失效后，将尝试重新建立连接，如果一直无法与任何一台Server建立连接，则进入失效状态。

3. AC在启动后即开始与预设的服务器周期性建立连接并保持连接（AC很有可能在内网，所以不能由服务器先发连接）。连接时发送NHP_DOL消息，在收到服务器的回应后确认连接。连接期间视情况进行发送NHP_KPL消息保持连接。由**maintainServerConnectionRoutine**实现。

4. AC处理服务器发送过来的NHP_DOP消息，判断请求方的serviceId, appId是否匹配并进行IPSET操作，完成后返回NHP_DRT消息。

5. 发送消息时，向**sendMsgCh**发送创建好的**MsgAssembler**（必须指定**RemoteAddr**）。如果连接没有建立，AC会尝试建立并记录该连接。同时对此连接开启接收线程。**MsgAssembler**经过加密后会从此连接发出

6. 接收到报文时，会将报文进行解密获取明文消息。由**msghandler**分别进行处理。

### 7.2 NHP-AC IP放行模式

IP放行模式分为两种：

1. ipPassMode为0（默认）时为立即放行模式，门禁开门时将以敲门来源IP地址为准。

2. ipPassMode为1时为预访问模式，门禁开门前将先开启对应协议的临时端口并返回server临时端口和临时访问token，在短时间内需由agent携带临时访问token进行临时连接，如果临时连接有效，则开门时放行将以此次临时连接的来源IP为准。

### 7.3 NHP-AC 配置文件

`etc/config.toml`

```toml
[AC]
  # (optional) assign an unique id for this ac
  ACId = "abc_group_ac_001"
  # (mandatory) specify the private key in base64 format
  ACPrivateKey = "+B0RLGbe+nknJBZ0Fjt7kCBWfSTUttbUqkGteLfIp30="
  # 0: default, passing the knock source IP
  # 1: use pre-access procedure to determine the passing source IP
  IpPassMode = 0
  # (optional) ID of authorization service provider this ac belongs to
  AuthServiceId = "abc_group" 
  # (optional) ID of resources controlled by this ac
  ResourceIds = ["abc_group_web_server", "abc_group_api_server"]
  # (optional) ID of organization
  OrganizationId = "5f3e36149fa95c0414408ad4"

# server peers list
[[Servers]]
  # (optional) the server's hostname. Its resolved address overrides the "Ip" field
  Host = ""
  # IP address of the server peer
  Ip = "192.168.80.35"
  # listening port for the server peer
  Port = 62206
  # type: NHP-Server
  Type = 2
  # specify the server peer's public key in base64 format
  PublicKey = "WqJxe+Z4+wLen3VRgZx6YnbjvJFmptz99zkONCt/7gc="
  # expire timestamp of the public key (seconds from epoch)
  ExpireTime = 1716345064

# another server
#[[Servers]]
#  Ip = "192.168.135.1"
#  Port = 7776
#  Type = 2
#  PublicKey = "dstv1KlD2oVXiwgOxWtgZd+YmrOhU46W3emTGrHRADk="
#  ExpireTime = 1716345064

```

## 8. NHP-Agent

### 8.1 NHP-Agent 架构设计

1. Agent只与Server之间进行通信。Agent主动向Server发起短连接。不存在Agent在未建立连接时被动接收Server消息的情况。

2. 发送消息时，向**sendMsgCh**发送创建好的**MsgAssembler**（必须指定**RemoteAddr**）。如果连接没有建立，agent会尝试建立并记录该连接。同时对此连接开启接收线程。**MsgAssembler**经过加密后会从此连接发出

3. 接收到报文时，会将报文进行解密获取明文消息。由**msghandler**分别进行处理。

### 8.2 NHP-Agent 配置文件

`etc/config.json`

```json
{
  // (mandatory) specify the private key in base64 format
  "privateKey": "+Jnee2lP6Kn47qzSaqwSmWxORsBkkCV6YHsRqXCegVo=",
  // (optional) ID of authorization service provider this agent belongs to
  "aspId": "abc_group",
  // (mandatory) an user object is necessary to carry out knock requests
  "user": {
    "userId": "zengl",
    "devId": "0123456789abcdef",
    "orgId": "abc.com.cn"
  },
  // preset resources to begin knock after start
  "knockRess": [
    {
      "aspId": "abc_group",
      "resId": "app_resource_group_001",
      "serverKey": "WqJxe+Z4+wLen3VRgZx6YnbjvJFmptz99zkONCt/7gc="
    }
  ],
  // list of preset allowed server peers to send knock request. It has the same effect as AddServer()
  "servers": [
    {
      // (optional) the server's hostname. Its resolved address overrides the "Ip" field
      "host": "",
      // IP address of the server peer
      "ip": "192.168.80.35",
      // listening port for the server peer
      "port": 62206,
      // type: NHP-Server
      "type": 2,
      // public key in base64 format
      "pubKeyBase64": "WqJxe+Z4+wLen3VRgZx6YnbjvJFmptz99zkONCt/7gc=",
      /// expire time for the public key (seconds from epoch)
      "expireTime": 1716345064
    }
  ]
}
```

## 9. Log 设计

日志log设计为异步写入，相比同步日志写入，在调用时不会立即进行写入日志文件的I/O操作而影响正常业务逻辑，在高并发时可以聚合多条日志并合并为一次文件写入，大幅减少文件I/O操作次数。

Logger对象可以单独创建使用（**NewLogger()**），也可以在应用程序启动时指定Package全局变量**glbLogger**，供整个工程使用。

注意：应用程序结束前，需调用Logger.Close()，确保最后缓存的日志能够写入文件。

---

## File: docs/zh-cn/comparison.zh-cn.md

---
layout: page
title: 对比NHP与SPA
nav_order: 5
permalink: /zh-cn/comparison/
---

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

注: 以下内容摘自《Applied Sciences》杂志2024年第14卷第13期的期刊论文《AHAC: Advanced Network-Hiding Access Control Framework》论文，值得特别指出的是，AHAC框架是NHP（OpenNHP）技术体系中的一个关键组成部分。


---

- [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. 优势对比

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 加密算法开销

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                  |            |


我们通过实验测量了 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 性能开销

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




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

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



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

## 3. 高可用性对比

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



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




## 4. 扩展性对比

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

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

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

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

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

### 4.1 与DNS集成

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



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

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

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

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

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

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

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

### 4.2 与FIDO集成

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



- (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. 兼容性对比

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




---

---

## File: docs/zh-cn/cryptography.zh-cn.md

---
layout: page
title: 加密算法
nav_order: 4
permalink: /zh-cn/cryptography/
---

# 加密算法
{: .fs-9 }

加密是 OpenNHP 的核心，通过利用尖端的加密算法提供强大的安全性、卓越的性能和可扩展性。
{: .fs-6 .fw-300 }


---

本文解释了 OpenNHP 如何在多个关键领域中利用现代加密算法的优势：

1. [公私钥加密算法](#1-%E5%85%AC%E7%A7%81%E9%92%A5%E5%8A%A0%E5%AF%86%E7%AE%97%E6%B3%95)
2. [密钥交换、数据加密和身份认证](#2%E5%AF%86%E9%92%A5%E4%BA%A4%E6%8D%A2%E6%95%B0%E6%8D%AE%E5%8A%A0%E5%AF%86%E5%92%8C%E8%BA%AB%E4%BB%BD%E8%AE%A4%E8%AF%81)
3. [密钥分发和管理](#3-%E5%AF%86%E9%92%A5%E7%AE%A1%E7%90%86%E4%B8%8E%E5%88%86%E5%8F%91)


## 1) 公私钥加密算法
### 1.1 简介
在不断变化的网络安全环境中，保护通信和网络资源至关重要，特别是在网络威胁日益复杂的情况下。网络基础设施隐藏协议（NHP），作为一种零信任安全机制，致力于通过隐藏网络基础设施细节来防止攻击者入侵，并确保只有受信任的实体能够与网络资源交互。NHP 安全模型的关键组件是椭圆曲线加密（ECC）用于公钥加密。在本文中，我们将探讨 ECC 如何集成到 NHP 零信任协议中，以提供强大且高效的安全性。

椭圆曲线加密（ECC）是一种现代公钥加密方法，相较于传统方法如 RSA，它能在显著更小的密钥尺寸下提供相同级别的安全性。ECC 依赖于有限域上椭圆曲线的数学特性，提供了安全性与性能之间的良好平衡。由于其降低了计算开销，ECC 特别适用于资源受限的环境，如嵌入式系统或移动设备。公钥加密是基于非对称密钥对的加密方法，通常包括一个公开的公钥和一个私密的私钥。通过公钥加密，可以实现安全的数据传输、身份验证和数字签名等功能，从而确保通信双方的数据安全性和身份真实性。

### 1.2 什么是椭圆曲线加密？

椭圆曲线加密（ECC）是一种基于椭圆曲线数学理论的公钥加密技术。它通过椭圆曲线方程上的点运算，提供与传统方法（如 RSA）相同的安全性，但密钥尺寸更小，计算效率更高。ECC 的安全性源于椭圆曲线离散对数问题，其计算复杂度使得破解难度极大。

在 ECC 中，参与方通过生成公私钥对，利用椭圆曲线 Diffie-Hellman（ECDH）协议来交换密钥。ECC 的数学基础是使用有限域上的椭圆曲线方程：

y^2 = x^3 + ax + b

其中 a 和 b 是定义曲线特性的常数，曲线上的点集具有特定的加法运算规则。

ECC 的主要优势包括：
- **更小的密钥尺寸**：ECC 能在更小的密钥长度下实现相同的安全性，从而降低了存储和计算的负担。
- **增强的安全性**：ECC 基于椭圆曲线离散对数问题，其数学复杂性使其非常难以破解。
- **高效性**：相比传统加密方法如 RSA，ECC 的加密和解密操作速度更快，适用于资源受限的设备（如嵌入式系统和移动设备）。

NHP 使用 ECC 进行密钥交换、数据加密和身份验证，以及通过无证书公钥加密（CL-PKC）进行密钥分发和管理。

### 1.3 安全通信中的 ECC

#### 1.3.1 密钥交换机制

加密密钥的安全交换是任何安全通信协议的核心。NHP 使用椭圆曲线 Diffie-Hellman（ECDH）作为其密钥交换机制。在 ECDH 密钥交换中，通信双方使用椭圆曲线生成公私密钥对，然后交换公钥，以便双方计算出共享密钥，而无需直接在网络上传递。

使用 ECDH 的好处有两个方面：首先，它提供了前向安全性，即使在未来某一方的私钥被泄露，先前建立的会话密钥仍然是安全的。其次，由于 ECC 的高效性，密钥交换过程计算负担较轻，确保密钥建立过程快速完成且计算成本低。

#### 1.3.2 数字签名身份验证

在零信任环境中，身份验证至关重要。NHP 使用椭圆曲线数字签名算法（ECDSA）来验证试图访问网络资源的实体的身份。ECDSA 是一种基于 ECC 的数字签名方案，它允许设备在不暴露敏感私钥的情况下证明其身份。

在 NHP 协议中，当某个实体希望与网络通信时，它必须使用其私钥生成数字签名，接收方可以使用相应的公钥来验证签名的有效性。这确保了只有合法的实体可以参与网络，从而有效地实施零信任模型的 "永不信任，始终验证" 原则。

#### 1.3.3 数据保密加密

NHP 在通信过程中使用对称加密来确保数据的保密性，但对称密钥必须在实体之间安全地分发和共享。ECC 通过 ECDH 提供安全的对称密钥分发渠道，确保对称密钥可以安全地交换。

一旦这些密钥交换完成，NHP 就会切换到对称加密进行数据传输，从中受益于对称加密算法的速度和效率。ECC 确保对称密钥交换既安全又高效。

#### 1.3.4 无证书公钥加密中的密钥管理与分发

NHP 还通过无证书公钥加密（CL-PKC）使用 ECC 进行密钥管理和分发。在传统的公钥基础设施中，证书被用来验证公钥，这在证书管理方面引入了复杂性。CL-PKC 通过允许实体与受信任的中心合作生成部分私钥，同时独立生成自己的密钥对，从而消除了证书的需要。

这种方法简化了密钥管理，确保公钥可以在没有证书颁发和验证的情况下安全使用。通过在 CL-PKC 中使用 ECC，NHP 提供了一种轻量级且安全的密钥分发方式，通过消除对集中式证书机构的依赖，进一步增强了零信任模型。

### 1.4 使用 ECC 的优势

NHP 零信任协议中使用 ECC 提供了众多符合其安全目标的优势：

- **可扩展安全性**：ECC 较小的密钥尺寸提供了强大的安全性，能很好地适应对抗对手计算能力不断增强的情况。随着 NHP 致力于为多样化的网络部署提供零信任环境，ECC 的可扩展性是一项关键资产。
- **资源效率**：相比传统公钥加密，ECC 减少了网络设备的计算负担。在网络资源可能受限的环境中——如边缘设备或物联网组件——这种高效性对于在不牺牲安全性的情况下保持高性能至关重要。
- **性能提升**：结合 ECDH 的密钥交换、ECDSA 的身份验证以及高效的对称加密提供了一个平衡的安全通信解决方案。这种平衡的方法使得 NHP 能够实现零信任的目标，同时保持较低的延迟，这对时间敏感的网络应用尤为关键。

### 1.5 结论

将椭圆曲线加密集成到 NHP 零信任协议中，提供了一种在最小性能影响下保护网络通信的强大手段。通过利用 ECDH 进行安全的密钥交换、ECDSA 进行可靠的身份验证，以及高效的对称加密进行数据传输，ECC 支持零信任模型的目标，即隐藏网络基础设施，确保只有受信任的实体可以访问资源，并以低开销保持安全性。

随着网络威胁变得越来越复杂，像 ECC 这样的先进加密技术在 NHP 协议中的应用对于保持对攻击者的优势至关重要。ECC 和 NHP 之间的协同作用不仅有助于保护关键的网络基础设施，还确保安全措施既强大又高效——这是任何现代网络安全项目成功的关键组合。

网络基础设施隐藏协议（NHP）基于零信任安全模型构建，确保即使在潜在攻击者的存在下也能实现安全通信。为此，NHP 集成了 Noise 协议框架，这是一个用于安全且灵活的密钥交换、数据加密和身份验证的加密框架。该组合以最小的计算开销提供了强大的安全性。

## 2）密钥交换、数据加密和身份认证

### 2.1 简介

#### 2.1.1. 密钥交换机制

NHP 利用 Noise 协议的密钥交换机制来确保通信双方之间的安全认证通道。密钥交换从握手阶段开始，双方交换 Diffie-Hellman (DH) 公钥。在 Noise 中，每一方生成一个临时密钥对，并使用交换的公钥派生出共享密钥，该共享密钥随后用于加密后续通信。

Noise 允许 NHP 支持长期静态密钥和临时密钥以增强安全性。Noise 框架的握手模式的灵活性使得 NHP 能够根据特定使用场景定制握手过程，提供相互认证、匿名发起者或初始握手本身加密的选项。通过利用 Noise 的基于令牌的握手系统，NHP 可以精确控制密钥交换消息的顺序，同时保持身份信息的机密性。

#### 2.1.2 数据加密

共享密钥在握手期间派生出来后，Noise 框架使用对称加密来保护数据。NHP 利用 Noise 的 CipherState 和 SymmetricState 对象，这些是 Noise 状态机的核心组件，用于管理通信会话的加密和解密密钥。

特别地，握手期间派生的共享密钥用于初始化对称加密密钥（k）和随机数（n），用于数据加密。Noise 支持高级加密方案，如 ChaCha20-Poly1305 或 AES-GCM，提供带有附加数据认证加密（AEAD），以维护数据的保密性和完整性。链式密钥（ck）和握手散列（h）用于在会话过程中不断派生新的密钥，增强前向安全性，确保一个密钥的泄露不会危及通信的其他部分。

NHP 通过这些加密属性提供网络数据的加密通道，确保任何被拦截的数据在没有派生密钥的情况下无法被解密。

#### 2.1.3 身份验证

Noise 通过将静态密钥的交换与 Diffie-Hellman 操作相结合来实现身份验证。在 NHP 中，身份验证发生在握手期间，其中静态密钥被加密并通过共享的 DH 操作进行验证，有效地将双方的公钥绑定到派生的会话密钥上。

在握手过程中，Noise 使用诸如 "s"（静态）和 "e"（临时）等令牌来指示正在交换和验证哪些密钥。这种基于令牌的方法使得 NHP 能够根据具体的使用场景选择性地认证单方或双方。例如，Noise 中的 "XX" 模式提供相互认证，而 "NK" 模式允许单方认证的握手，赋予 NHP 在身份验证严格性方面的灵活性。

为了进一步保护身份信息，Noise 可以在握手期间加密静态密钥。NHP 利用这一特性来防止窃听者发现参与者的身份，从而支持零信任模型，确保参与者的身份只对预期的对方可见，而不对第三方泄露。

### 2.2 算法和公式

#### 2.2.1 Diffie-Hellman 密钥交换

Diffie-Hellman（DH）密钥交换用于在两方之间派生共享密钥，每一方生成一个私钥（a 对于 A，b 对于 B）并计算公共密钥：

- A 计算其公钥：A_pub = g^a mod p
- B 计算其公钥：B_pub = g^b mod p

共享密钥 s 通过以下方式计算：

- A 计算：s = B_pub^a mod p
- B 计算：s = A_pub^b mod p

该共享密钥 s 对于双方是相同的，用于派生加密密钥。

#### 2.2.2 对称加密

NHP 使用对称加密确保数据机密性。密钥（k）和随机数（n）用于加密函数。对于带有附加数据认证加密（AEAD），通常使用 ChaCha20-Poly1305 算法，该算法结合了流密码（ChaCha20）和消息验证码（Poly1305）。

- 加密：c = ChaCha20(k, n, plaintext)
- 认证：tag = Poly1305(k, associated data || c)

密文（c）和标签一起传输，确保数据的机密性和完整性。

#### 2.2.3 密钥派生和散列

Noise 使用基于 HMAC 的密钥派生函数（KDF）来派生密钥。HKDF（基于 HMAC 的密钥派生函数）用于从共享密钥（s）生成多个密钥。

HKDF 步骤：

- temp_key = HMAC(chaining_key, input_key_material)
- output1 = HMAC(temp_key, 0x01)
- output2 = HMAC(temp_key, output1 || 0x02)

派生的密钥用于加密和维护链式密钥（ck），以确保前向安全性。

#### 2.2.4 身份认证

身份验证在 NHP 中涉及静态和临时密钥的交换，以验证参与方。静态（s）和临时（e）密钥之间的 Diffie-Hellman 操作产生唯一的共享值，用于验证参与方的身份。

身份验证操作包括：

- ss = DH(s_A, s_B)
- es = DH(e_A, s_B) 或 DH(s_A, e_B)
- ee = DH(e_A, e_B)

这些值通过散列结合起来派生最终的会话密钥，有效地将身份绑定到密钥交换过程中，确保只有预期的参与方能够派生出正确的会话密钥。

### 2.3 结论

Noise 协议框架为 NHP 提供了灵活且强大的加密机制，确保了通信的安全性和参与方身份的验证。通过支持多种握手模式和加密方案，Noise 框架增强了网络的前向安全性和身份保护能力，有效支持了零信任环境下的安全通信需求。结合 Diffie-Hellman 密钥交换、对称加密和基于令牌的身份验证，Noise 框架为 NHP 提供了实现其零信任目标的强大工具。

## 3) 密钥管理与分发

### 3.1 简介

无证书公钥加密（Certificateless Public Key Cryptography，CL-PKC），最初由 Al-Riyami 和 Paterson 在 2003 年提出，提供了一种混合解决方案，在不依赖传统证书机构（CA）的情况下确保强加密保证。本文探讨了 NHP 如何利用 CL-PKC 在不依赖证书的情况下实现高效且安全的密钥管理。

在传统的公钥基础设施（PKI）中，证书机构（CAs）作为可信的第三方，负责签发和管理公钥证书以验证用户密钥的真实性。虽然这种模型有效，但它引入了复杂性和风险，例如对 CA 的依赖以及 CA 受到攻击时的风险。无证书公钥加密旨在通过消除证书的使用来缓解这些问题，同时确保公钥的真实性。

在 CL-PKC 系统中，一个称为密钥生成中心（KGC）的可信第三方负责为用户生成部分私钥。然而，与 CA 不同的是，KGC 无法访问完整的私钥，因此不可能冒充用户。每个用户将 KGC 提供的部分私钥与他们自己的秘密值结合起来，生成完整的私钥和公钥。这种方法减少了对任何单一实体的信任，并提供了额外的安全层。

NHP 零信任协议集成了 CL-PKC 来管理其安全通信框架的密钥分发和验证。下面，我们解释 CL-PKC 的各种机制如何为 NHP 的密钥管理过程做出贡献。

#### 3.1.1. 部分密钥生成

KGC 负责创建系统范围的参数，包括主公私钥对。主私钥由 KGC 保密，而主公钥则分发给所有参与者。当新用户希望加入网络时，KGC 执行以下步骤：

- 生成用户的部分私钥，使用他们的唯一标识符（例如电子邮件或其他身份信息）。这确保每个用户的部分密钥与其身份绑定，提供基于身份的安全性。

##### 3.1.2 用户特定密钥对生成

用户随后选择自己的秘密值，并将其与 KGC 提供的部分私钥结合起来，生成完整的私钥。具体步骤如下：

- 用户选择一个秘密值 (d'\_A)，并使用它来生成一个点 U\_A：

  U\_A = [d'\_A]G

- 用户将 KGC 提供的部分私钥 (t\_A) 与自己的秘密值 (d'\_A) 相结合，计算出完整的私钥 (d\_A)：

  d\_A = (t\_A + d'\_A) mod n

- 用户使用完整的私钥生成相应的公钥 (P\_A)：

  P\_A = W\_A + [l]P\_pub

用户随后选择自己的秘密值，并将其与 KGC 提供的部分私钥结合起来，生成完整的私钥。用户的公钥也相应生成。

这种密钥分发方法确保 KGC 无法单方面确定用户的私钥，从而降低了密钥生成中心被攻破的风险。此外，不需要传统证书意味着用户无需依赖外部证书机构来验证密钥，从而减少了中间人（MITM）攻击的攻击面。

在像 NHP 实施的这种无证书系统中，公钥的真实性通过隐式的方法而不是依赖 CA 签发的证书来验证。具体来说，用户的公钥是使用系统参数、用户标识符和 KGC 的主公钥计算出来的。该计算是确定性的，允许任何一方在无需信任 CA 或存储大量证书数据库的情况下验证公钥的真实性。

通过消除传统证书的需要，NHP 能够简化密钥验证过程，消除证书吊销列表（CRLs）和其他 PKI 复杂性。这种方法不仅减少了通信开销，还通过消除对可信第三方的依赖增强了安全性，因为这些第三方可能成为攻击者的目标。


### 3.2 算法和公式

#### 3.2.1 系统参数生成

密钥生成中心（KGC）负责生成系统参数，这些参数包括椭圆曲线 (E) 定义在有限域 (ℚ_q) 上，基点 (G) 的素数阶 (n)，以及主私钥 (ms)。KGC 计算主公钥 (P_pub) 如下：

P_pub = [ms]G

其中 [ms]G 表示基点 G 与主私钥 ms 的标量乘法。

#### 3.2.2 部分私钥生成

对于每个用户（标识符为 ID_A），KGC 生成部分私钥。首先，KGC 根据用户的标识符和系统参数计算哈希值 (H_A)：

H_A = H(ENTL_A || ID_A || a || b || x_G || y_G || x_P_pub || y_P_pub)

其中 (ENTL_A) 是由标识符派生的长度值，(x_G, y_G) 和 (x_P_pub, y_P_pub) 分别是点 G 和 P_pub 的坐标。

KGC 选择一个随机值 (w ∈ [1, n-1]) 并计算：

W_A = [w]G + U_A

其中 (U_A = [d'_A]G) 是用户使用其自身的秘密值 (d'_A) 生成的点。

部分私钥 (t_A) 计算如下：

t_A = (w + l · ms) mod n

其中 (l) 是根据点 (W_A) 和哈希 (H_A) 计算的值。

#### 3.2.3 用户完整私钥生成

用户通过将部分私钥 (t_A) 与其秘密值 (d'_A) 结合生成完整的私钥：

d_A = (t_A + d'_A) mod n

这确保只有用户自己知道其完整的私钥。

#### 3.2.4 公钥计算

用户的公钥 (P_A) 计算如下：

P_A = W_A + [l]P_pub

任何人可以使用系统参数、用户标识符和 KGC 的公钥验证该公钥。

#### 3.2.5 签名生成与验证

用户对消息 (M) 生成数字签名时，计算哈希 (e) 如下：

e = H(H_A || x_W_A || y_W_A || M)

签名 (r, s) 使用用户私钥 (d_A) 和一个随机值 (k) 生成：

[r]G = (x_1, y_1)
r = x_1 mod n
s = (k^{-1}(e + d_A · r)) mod n

验证签名时，验证者计算 (P_A)，然后检查是否满足：

[r]G = [s]G + [e + r]P_A

如果等式成立，签名即为有效。


### 3.3 结论

NHP 实施的无证书公钥加密为零信任环境中的密钥管理提供了一种强大且高效的方法。通过利用 CL-PKC，NHP 能够缓解传统 PKI 相关的风险，减少对集中可信机构的依赖，并简化密钥分发过程。结果是一个更安全且可扩展的系统，适合在面对不断发展的网络威胁时保护关键网络基础设施。

将无证书加密与 NHP 的零信任原则相结合，使其成为在最小化集中机构引入的风险的同时保护网络资源的理想解决方案。

Copyright © 2024 OpenNHP Open Source Project.

---

## File: docs/zh-cn/deploy.zh-cn.md

---
layout: page
title: 部署OpenNHP
nav_order: 6
permalink: /zh-cn/deploy/
---

# 部署OpenNHP
{: .fs-9 }


---

## 1. OpenNHP组件说明

根据上一章中的构建步骤，构建结果将输出到 *release* 目录下，该目录下的三个子目录分别包含OpenNHP的三大核心组件：*nhp-agent*、*nhp-server*和*nhp-ac*。

- **nhp-agent代理：** 发起敲门请求的模块，敲门请求中带有数据访问者的身份和设备信息，通常安装在用户终端的设备上。
- **nhp-server服务器:** 处理并验证敲门请求的模块，通常是服务器程序。其功能包括验证敲门请求并与外部授权服务提供商进行交互实现鉴权操作，以及控制NHP门禁进行开门动作。
- **nhp-ac门禁：** 访问控制的执行模块，通常是服务器程序。该模块执行默认“拒绝一切”（deny all）的安全策略并确保被保护资源的网络隐身状态，通常位于被保护资源所在的同一主机上。负责向已授权的NHP代理开放访问权限或向已失去授权的NHP代理关闭访问权限，并根据NHP服务器返回参数执行针对NHP代理的放行动作。

## 2. OpenNHP开发测试环境搭建

### 2.1 开发测试环境：Windows/MacOS开发主机 + Linux虚拟机

假设开发主机为Windows或者macOS，可通过安装虚拟机环境（如VirualBox）并创建两台Linux虚拟机来搭建简单的OpenNHP测试环境。在创建虚拟机时，请将网卡选项设置为`"Host-only Adapter"`（如下图），可使虚拟机的IP与开发主机IP在同一个网段。

 

 **提示：** 如需该虚拟机同时具备访问互联网能力，可以另外增加一个`"NAT"`网卡：
 

至此，NHP三大组件的环境搭建如下：

- 【nhp-server】 运行在Linux虚拟主机上，IP地址为*192.168.56.101*
- 【nhp-ac】 运行在Linux虚拟主机上，IP地址为*192.168.56.102*
- 【nhp-agent】 运行在Windows/macOS开发主机上，IP地址为*192.168.56.1*

### 2.2 开发测试环境的网络拓扑与基础信息

 

| 服务器名称 | IP地址 | 基础配置信息  |
|:--:|:--:|:--:|
| NHP-Server | 192.168.56.101  | **公钥:** WqJxe+Z4+wLen3VRgZx6YnbjvJFmptz99zkONCt/7gc=**私钥:** eHdyRHKJy/YZJsResCt5XTAZgtcwvLpSXAiZ8DBc0V4=  **Hostname:** localhost  **ListenPort:** 62206  **aspId:** example |
| NHP-AC | 192.168.56.102  | **公钥:** Fr5jzZDVpNh5m9AcBDMtHGmbCAczHyPegT8IxQ3XAzE=**私钥:** +B0RLGbe+nknJBZ0Fjt7kCBWfSTUttbUqkGteLfIp30=**ACId:** testAC-1  被保护资源的 **resId:** test |
| NHP-Agent | 192.168.56.1  | **公钥:** WnJAolo88/q0x2VdLQYdmZNtKjwG2ocBd1Ozj41AKlo=**私钥:** +Jnee2lP6Kn47qzSaqwSmWxORsBkkCV6YHsRqXCegVo=  **UserId:** agent-0 |

**【注意】** 每个组件都有对应的配置文件，需要配置正确才能成功启动。关于配置文件的格式，请见下文中各个组件的“配置文件”相关信息。

**【提示】** 从0.3.3版本起，各组件配置文件中的大多数字段都支持动态更新，详见各配置文件注释说明。

### 2.3 NHP-Server的配置与运行

#### 2.3.1 NHP-Server系统要求

- Linux服务器或者Windows

#### 2.3.2 NHP-Server运行

将*release*目录下*nhp-server*目录复制到目标机器上。配置好*etc*目录下 `toml`文件(详细参数见下一节)，运行`nhp-serverd run`。

- Linux环境：

   ```bash
   nohup ./nhp-serverd run 2>&1 &
   ```

- Windows环境：

   ```bat
   nhp-serverd.exe run
   ```

*【可选项】* 禁止UDP端口暴露：运行`iptables_default.sh`

#### 2.3.3 NHP-Server服务器的配置文件

- 基础配置：[config.toml](https://github.com/OpenNHP/opennhp/tree/main/server/main/etc/config.toml)  
- 门禁peer列表配置：[ac.toml](https://github.com/OpenNHP/opennhp/tree/main/server/main/etc/ac.toml)  
- 客户端peer列表配置：[agent.toml](https://github.com/OpenNHP/opennhp/tree/main/server/main/etc/agent.toml)  
- http服务配置：[http.toml](https://github.com/OpenNHP/opennhp/tree/main/server/main/etc/http.toml)  
- 服务器插件读取配置：[resource.toml](https://github.com/OpenNHP/opennhp/tree/main/server/main/etc/resource.toml)  
- 源地址关联列表：[srcip.toml](https://github.com/OpenNHP/opennhp/tree/main/server/main/etc/srcip.toml)  
- 服务器插件资源配置：[resource.toml](https://github.com/OpenNHP/opennhp/tree/main/server/main/etc/resource.toml)  

### 2.4 NHP-AC的配置与运行

#### 2.4.1 NHP-AC系统要求

- Linux服务器，内核需支持**ipset**。可通过以下命令查看ipset支持情况

   ```bash
   lsmod | grep ip_set 
   ```

#### 2.4.2 NHP-AC运行

将*release*目录下*nhp-ac*目录复制到目标机器上。配置好*etc*目录下 `toml`文件(详细参数见下一章)，运行`iptables_default.sh`，添加防火墙规则，此时外部连接将无法建立。再运行`nhp-acd run`。

**【注意】** `nhp-acd` 以及 `iptables_default.sh` 需要在**root**权限下运行。

- Linux环境：

   ```bash
   su
   ./iptables_default.sh
   nohup ./nhp-acd run 2>&1 &
   ```

如果想恢复`iptables_default.sh`对iptables的改动，可以运行以下命令来清除：

   ```bash
   iptables -F
   ```

#### 2.4.3 NHP-AC门禁配置文件

- 基础配置：[config.toml](https://github.com/OpenNHP/opennhp/tree/main/ac/main/etc/config.toml)  
- 服务器peer列表：[server.toml](https://github.com/OpenNHP/opennhp/tree/main/ac/main/etc/server.toml)  

### 2.5 NHP-Agent的配置与运行

#### 2.5.1 NHP-Agent系统要求

- 所有平台：Windows、Linux、macOS、Android、iOS

#### 2.5.2 NHP-Agent运行

将*release*目录下*nhp-agent*目录复制到目标机器上。配置好*etc*目录下 `toml`文件(详细参数见下一章)，运行`nhp-agentd run`。

- Linux环境：

   ```bash
   nohup ./nhp-agentd run 2>&1 &
   ```

- Windows环境：

   ```bat
   nhp-agentd.exe run
   ```

#### 2.5.3 NHP-Agent的配置文件

- 基础配置：[config.toml](https://github.com/OpenNHP/opennhp/tree/main/agent/main/etc/config.toml)  
- 敲门目标配置：[resource.toml](https://github.com/OpenNHP/opennhp/tree/main/agent/main/etc/resource.toml)  
- 服务器peer列表：[server.toml](https://github.com/OpenNHP/opennhp/tree/main/agent/main/etc/server.toml)  

### 2.6 测试NHP网络隐身效果

验证NHP网络隐身效果，可以通过nhp-agent主机 *（IP：192.168.56.1）*进行`nmap扫描（以80端口为例）` nhp-ac主机 *（IP：192.168.56.102）*来测试。此外，可以在另外一台虚拟机（模拟黑客扫描攻击），扫描nhp-ac 主机查看效果。

| 测试用例 | 测试命令 | 测试目的  | 预期结果  |
|:--:|:--:|:--:|:--:|
| nhp-agent未运行 |`nmap -sS -p 80 192.168.56.102` | 测试AC对Agent隐身 | 80/tcp filtered  |
| nhp-agent已运行 |`nmap -sS -p 80 192.168.56.102` | 测试AC对Agent开放 | 80/tcp open  |
| nhp-agent已运行 |`nmap -sS -p 80 192.168.56.102` | 测试AC对黑客隐身 | 80/tcp filtered  |

## 3. 日志说明

### 3.1 日志文件位置

日志文件生成于每个组件各自的*logs*目录下，以日期作为文件名，可通过`tail`命令查看。

- 查看nhp-server的日志

   ```bash
   tail -f release/nhp-server/logs/server-2024-03-10.log
   ```

- 查看nhp-ac的日志

   ```bash
   tail -f release/nhp-ac/logs/ac-2024-03-10.log
   ```

- 查看nhp-agent的日志

   ```bash
   tail -f release/nhp-agent/logs/agent-2024-03-10.log
   ```

### 3.2 日志文件格式

日志的格式如下：

   ```text
   时间戳 代码位置 NHP组件名 [日志权重] 日志消息
   ```

日志权重分成以下几个级别：

- Error
- Critical
- Warning
- Info
- Debug

## 4. 附录A：常见问题FAQ

- **Q：** Windows平台上编译错误：`running gcc failed: exec: "gcc": executable file not found in %PATH%` 
  **A：** 原因是没有安装`gcc`编译工具。请按照上文中3.1.3中步骤安装GCC。

- 日志中显示错误：`NHP-AC [Critical] received stale packet from 192.168.56.101:62206, drop packet` 。 
   【原因】接收方对包的接收时间有要求，数据包发送时间不能早于接收方10分钟以上。
   【修复】两台机器的时间同步

- 怎么调整一次认证后开通的时间？  怎么限制只开放指定的端口？
   【方法】在nhp-server/plugins/下对应的插件模块中，找到etc/resource.toml文件，里面能配置资源的端口、时长、id等信息；如果用的是nhp-agent敲门，则默认是example插件。如果是微信扫码敲门，用的是wxweb插件。

- 如何检查配置是否生效？
   【方法】server和ac的日志里有记录。也可以在ac的系统里输入ipset -L命令查看授权的源ip目的端口和时长。

- nhp-agent 敲门成功，但访问不通可能的原因。

   问题原因：***可能原因是 nhp-server 下发到 nhp-ac 进行 ipset，所添加记录中的 resource 目标没和请求中对应的 resource 目标的 IP 对上***，这种情况可能出现在 resource 与 nhp-ac 在同一台服务器上的情况。可以先手动配置 ipset 规则：
   ``` shell
   sudo ipset add defaultset [SourceIP],tcp:80,[ResourceIP]
   ```
   ***SourceIP 来源IP，即 Agent 的公有 IP，可通过 tcpdump 或 ipset list 确认***
   ***ResourceIP 请求资源的 IP*** 该IP 对应 nhp-server 中 ./plugins/example/etc/resource.toml，如果与请求对应不上，则会出现敲门成功但无法请求问题。

   抓包调试：在 ```nhp-ac``` 侧 ```tcpdump -i any port 80```(根据具体情况调整)

   解决方案：将可用的 IP 配置在 nhp-server 的 ```./plugins/example/etc/resource.toml``` 配置中的 ```Addr.Ip = ""```

---

## File: docs/zh-cn/features.zh-cn.md

---
layout: page
title: 功能列表
nav_order: 3
permalink: /zh-cn/features/
---

# OpenNHP功能列表
{: .fs-9 }


---

---

## File: docs/zh-cn/overview.zh-cn.md

---
layout: page
title: OpenNHP简介
nav_order: 1
permalink: /zh-cn/overview/
---

# OpenNHP：零信任网络隐身协议
{: .fs-9 }


---

## 第一章：导读

**NHP**是由中国计算机学会CCF发布的零信任网络隐身协议，对比零信任SDP（软件定义边界）中的**单包授权协议SPA**，具有更好的隐身性、更强的性能和可靠性、更灵活的扩展性、以及良好的信创兼容性。

**OpenNHP**是基于NHP标准的开发的开源软件项目。在上手OpenNHP项目前，建议阅读以下文章：

关于OpenNHP的代码结构与技术详解，请阅读：

- [《OpenNHP代码解读文档》](../code/)

## 第二章：OpenNHP的兼容性

OpenNHP具备良好的兼容性，尤其是对信创生态的支持，以下是OpenNHP兼容的密码算法和软硬件。

### 2.1 密码算法

| 国产密码算法 |  *SM2、SM3、SM4*  |  
|---|---|
| **国际密码算法**   |  ***Curve25519、AES、SHA256***  |

### 2.2 操作系统

| 操作系统 |  兼容性  |
|---|:---:|
| Windows   |  ✅ |
| 苹果MacOS   |  ✅ |
| 统信UOS   |  ✅ |
| 麒麟KylinOS   |  ✅ |
| 中电科普华OS   |  ✅ |  
| 苹果iOS   |  ✅ |
| 安卓Android   |  ✅ |

### 2.3 CPU指令集

| CPU类型 |  兼容性  |
|---|:---:|
| x86   |  ✅ |
| ARM华为鲲鹏   |  ✅ |
|  LoongArch龙芯   |  ✅ |
|  SW申威   |  ✅ |

## 2. Official Technical Reference & Guides (OpenNHP/website)

# OpenNHP

> OpenNHP is an open-source, cryptography-powered Zero Trust network hiding protocol for the AI era. It makes infrastructure invisible by default — no exposed IPs, no open ports, no DNS discoverability before authentication. Backed by the Cloud Security Alliance and being standardised at the IETF.

## Core Pages

- [Vision](https://opennhp.org/vision.html): Why the Internet is becoming a Dark Forest and how Zero Visibility addresses AI-era threats. Covers the shift from Zero Trust to Zero Visibility.
- [Specification](https://opennhp.org/specification.html): Technical specification of the NHP protocol — architecture, components, cryptographic design, and packet format.
- [Open Source](https://opennhp.org/opensource.html): The OpenNHP open-source project, GitHub repository, contributors, and how to get involved.
- [Research](https://opennhp.org/research.html): Academic papers and standards documents — CSA specification and IETF Internet-Draft.
- [Demo](https://opennhp.org/demo.html): Live demonstration of OpenNHP's Zero Visibility capabilities.
- [Community](https://opennhp.org/community.html): Discord, GitHub Discussions, and community resources.
- [Documentation](https://docs.opennhp.org): Full developer and operator documentation.

## Blog

- [The Internet Is Becoming a Dark Forest — And AI Is the Hunter](https://opennhp.org/blog/the-internet-is-becoming-a-dark-forest.html): How AI is transforming network threats, why visibility equals vulnerability, and how Zero Visibility architecture (OpenNHP) addresses the AI-era attack surface. References PentAGI (autonomous AI pentesting) and Claude Code Security (500+ vulnerabilities found in production codebases).

## Key Concepts

- **Zero Visibility**: Infrastructure is invisible until cryptographic identity is proven. No exposed IPs, no open ports, no DNS discoverability before authentication.
- **Zero Trust vs Zero Visibility**: Zero Trust verifies identity after contact. Zero Visibility eliminates the attack surface before contact is possible.
- **NHP (Network Hiding Protocol)**: The underlying protocol that enforces cryptographic identity-first connectivity.
- **Dark Forest Theory**: From Liu Cixin's sci-fi novel — any entity that reveals its location will be targeted. Applied to AI-era network security: visibility equals vulnerability.

## Standards & Recognition

- IETF Internet-Draft: https://datatracker.ietf.org/doc/html/draft-opennhp-ztcpp-nhp
- Cloud Security Alliance Specification: https://cloudsecurityalliance.org/artifacts/stealth-mode-sdp-for-zero-trust-network-infrastructure
- GitHub: https://github.com/OpenNHP/opennhp