T/CCF 0002-2024 零信任网络隐身协议规范

ICS 35.100.50
CCS L70
团体标准
T/CCF 0002—2024
零信任网络隐身协议规范
Zero Trust Network-infrastructure Hiding Protocol Specification
2024 - 09 - 05发布2024 - 09 - 05实施
中国计算机学会 发布

目 次
零信任网络隐身协议规范 .......................................................................................................................................... 1
1 范围 ......................................................................................................................................................................... 1
2 规范性引用文件 ...................................................................................................................................................... 1
3 术语和定义 .............................................................................................................................................................. 1
4 缩略语...................................................................................................................................................................... 2
5 NHP协议技术架构 .................................................................................................................................................. 3
6 NHP协议实现过程 .................................................................................................................................................. 4
6.1 敲门交互流程 .............................................................................................................................................. 4
6.2 敲门申请 ...................................................................................................................................................... 5
6.3 双向身份验证 .............................................................................................................................................. 6
6.4 访问授权 ...................................................................................................................................................... 6
7 NHP协议消息定义 .................................................................................................................................................. 6
7.1 NHP协议包头 ............................................................................................................................................. 6
7.2 NHP协议消息 ............................................................................................................................................. 9
8 日志记录................................................................................................................................................................ 11
8.1 概述 ............................................................................................................................................................ 12
8.2 日志消息格式 ............................................................................................................................................ 12
8.3 运维日志 .................................................................................................................................................... 12
8.4 安全日志 .................................................................................................................................................... 12
8.5 流量日志 .................................................................................................................................................... 13
9 测试验证方法 ........................................................................................................................................................ 13
9.1 隐身能力验证 ............................................................................................................................................ 13
9.2 噪声算法验证 ............................................................................................................................................ 13
9.3 可用性测试验证 ........................................................................................................................................ 13
9.4 扩展性测试 ................................................................................................................................................ 13
9.5 兼容性测试 ................................................................................................................................................ 14
附 录 A （资料性） 与GB/T 43696-2024中定义的零信任参考体系架构的对应关系 .............................. 15
A.1 与GB/T 43696-2024零信任参考体系架构的对应关系 .......................................................................... 15
附 录 B （资料性） NHP协议的主要应用场景与部署 ................................................................................ 16
B.1 NHP协议的应用场景 ............................................................................................................................... 16
B.2 NHP协议部署建议 ................................................................................................................................... 18
B.3 与现有网络隐身协议兼容和平滑升级 ..................................................................................................... 21
B.4 用户身份认证和设备身份认证 ................................................................................................................. 22
附 录 C （资料性） 噪声协议框架及算法 ..................................................................................................... 24
C.1 RSA与ECC的安全强度与开销对比 ...................................................................................................... 24
C.2 NHP协议使用的噪声协议算法及流程 .................................................................................................... 24
附 录 D （规范性） NHP协议消息定义 ........................................................................................................ 27
D.1 NHP协议消息列表 ................................................................................................................................... 27
D.2 敲门与验证 ................................................................................................................................................ 27
D.3 密钥分发 .................................................................................................................................................... 29
D.4 服务发现 .................................................................................................................................................... 32
D.5 DDoS防范与二次敲门 .............................................................................................................................. 34
D.6 NHP报文的中继 ....................................................................................................................................... 35
D.7 保活机制 .................................................................................................................................................... 36
D.8 真实访问的源地址 .................................................................................................................................... 36
D.9 门禁日志上报 ............................................................................................................................................ 37
参 考 文 献 ........................................................................................................................................................ 39
T/CCF 0002—2024
III
前 言
本文件按照GB/T 1.1-2020《标准化工作导则 第1部分：标准化文件的结构和起草规则》的规定起草。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由中国计算机学会抗恶劣环境计算机专业委员会提出并归口。
本文件起草单位：西塞数字安全研究院、中国电子科技集团公司第十五研究所、中电科发展规划研究院有限公司、航天科工706所、中电科太极计算机股份有限公司、中科院空天信息研究院、中科边缘智慧信息科技（苏州）有限公司、中移（苏州）软件技术有限公司、中电科人大金仓信息技术股份有限公司、联通数字科技有限公司、中国电信上海研究院、中国电子科技集团公司第五十四研究所、苏州云至深技术有限公司、北京芯盾时代科技有限公司、北京蔷薇灵动科技有限公司、北京天空卫士网络安全技术有限公司、南昌大学网络空间安全学院、中信云网有限公司、中国铁塔信息研究院、北京大学、中电科普华基础软件股份有限公司、华为技术有限公司、麒麟软件有限公司、统信软件技术有限公司、浪潮电子信息产业股份有限公司、湖州市安全运营中心、北京航空航天大学软件学院、上海交通大学、中国科技大学网络安全学院、中国信息通信研究院、公安部第三研究所、中国电子信息产业发展研究院（赛迪研究院）、北京邮电大学网络安全学院、中国软件评测中心、中广宽带网络有限公司、北京交通大学、北京双湃智安科技有限公司、山东大学、浙江大学、飞诺门阵（北京）科技有限公司、北京东方通网信科技有限公司、国网思极网安科技（北京）有限公司。
本文件主要起草人：陈本峰、陈珊、许木娣、张先国、张冰姿、刘健、艾中良、刘凌旗、何山、袁晓光、赵慧、张雨、陈小鹏、张洪明、王一、郑仰樵、李新明、王志淋、张春生、厉海燕、王浩硕、冯尧、熊嵩、陈栋、齐骥、谢洁意、刘俊杰、宋瑞、赵海蕾、胡一鸣、麻付强、宋桂香、鲁华伟、邹艳鹏、谌鹏、何国锋、司玄、吴巍、贾哲、杨晓鹏、董雁超、曾倞、毕宝刚、赵宇、孙悦、牛立辉、孙敏杰、王世尧、杨明非、刘茜、何明瑶、饶泓、罗铭、张军、杨晓斌、叶臻、张子浪、陈钟、王江涛、余晓光、于继万、王震、万慧星、胡波、马红斌、梅勇、舒俊、张晨栋、李安琪、李颉、俞能海、穆琙博、任卫红、李安伦、杜武恭、陶耀东、李浥东、黄东华、徐书珩、任浩源、崔立真、纪守领、沈寓实、崔婷婷、吴志辉、孙磊。
引 言
在零信任环境中，网络隐身特性是保证数据可信通信的前置条件。零信任安全以“永不信任，持续验证”为核心理念，假设数据通信的所在网络环境是不可信的。因此，在数据通信连接建立前，零信任网络隐身协议（Zero Trust Network-infrastructure Hiding Protocol，简称NHP协议）使数据资源提供方的服务器默认拒绝一切访问，并隐藏其IP地址与端口，使其对未授权对象（如：外部攻击者、内部越权访问者）始终保持不可见，有效收缩了网络暴露面，避免漏洞利用、弱口令破解等网络攻击的前置手段，此特性实现了相对“网络隐身”。数据资源访问主体只有经过身份认证和权限鉴别成功后，才可以与资源提供方建立连接，从而保证了数据通信连接的可信性。在数据通信连接建立之后，NHP协议保持对通信参与方的间隔性持续验证，一旦风险被检测到或者安全策略发生改变，通信可以被及时中断，从而保障数据通信具备持续的可信性与可控性。在数据通信过程中，当数据资源提供方具备高可用架构的前提下，NHP协议可为数据资源访问主体动态指派安全可用的资源提供方服务器地址，并可以返回数据的完整性校验、隐私计算等参数，使数据通信过程不受网络故障以及恶意攻击的影响，从而保证数据通信过程的可靠性。
零信任网络隐身协议作为零信任安全架构中的一个通用基础组件，具有分布式、可扩展等特性，可与目前主流的零信任技术架构（即软件定义边界、微隔离等）融合，可用于南北向流量、东西向流量的安全防护；支持与任意第三方身份认证与访问权限管理相关系统对接，也支持通过下一代防火墙进行逻辑微隔离；支持与第三方日志审计或区块链平台对接，以满足数据流通的监管合规要求。
T/CCF 0002—2024
1
零信任网络隐身协议规范
1 范围
本文件规定了零信任网络隐身协议技术架构、实现过程、消息定义及其测试验证方法。
本文件适用于零信任网络隐身协议信息系统的规划、设计、开发、应用和测试。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T 43696-2024 网络安全技术 零信任参考体系架构
3 术语和定义
下列术语和定义适用于本文件。
3.1
零信任 zero trust
一种以资源保护为核心的网络安全理念。
注：该理念认为对资源的访问，无论主体和资源是否可信，主体和资源之间的信任关系都需要从零开始，通过持续环境感知与动态信任评估进行构建，从而实施访问控制。
[来源：GB/T 43696-2024，3.1]
3.2
零信任网络隐身协议 zero trust network-infrastructure hiding protocol
零信任环境下用于资源访问控制的一种框架协议，简称NHP协议。用来保障被保护资源对未授权访问主体在网络上不可见，只对经过身份认证和权限鉴定后的授权访问主体开放网络访问，确保资源访问符合可信、可控、可靠、可证四大安全原则。该访问控制方法在业内通常称为“网络隐身”。
3.3
资源 resource
系统中可供访问的客体，例如：应用、系统、接口、服务、数据等。
[来源：GB/T 43696-2024，3.4，有修改]
T/CCF 0002—2024
2
3.4
资源访问主体 subject
发起资源访问请求的实体，例如：客户端、浏览器、服务器、应用程序等。
3.5
敲门 port knocking
资源访问主体在建立数据通信连接之前，首先发送带有身份、设备以及目标资源等信息的数据包进行身份与权限合法性验证的通信过程。
3.6
访问控制 access control
用来实现资源在网络上的隐身效果并允许已授权的资源访问主体进行连接访问的控制模块。
3.7
访问授权 access granted
访问控制对于资源访问主体授予连接与资源访问权限的动作。
3.8
噪声协议 noise protocol
一种引入随机数并将其用于通信双方一系列加解密的算法组合。它使通信双方在处理加解密时避免采用固定的计算范式，从而使攻击者难以破解，为每一次数据传输提供安全保障。
4 缩略语
下列缩略语适用于本文件。
AEAD：携带附加数据的认证加密（Authenticated Encryption with Associated Data）
AES：高级加密标准（Advanced Encryption Standard）
ASP：授权服务提供商（Authorization Service Provider）
ECC：椭圆曲线非对称加密算法（Elliptic Curve Cryptography）
ECDH：椭圆曲线DH密钥交换（Elliptic Curve Diffe Hellman Key Exchange）
GCM：伽罗/计数器加密模式（Galois/Counter Mode）
HTTPS：超文本传输安全协议（Hypertext Transfer Protocol Secure）
IBC：基于标识的加密算法（Identity Based Cryptography）
IP：网络连接协议（Internet Protocol）
JSON：Javascript数据对象（JavaScript Object Notation）
MAC：消息验证码（Message Authentication Code）
RSA：Rivest-Shamir-Adleman非对称加密算法（Rivest-Shamir-Adleman）
SDK：软件开发工具包（Software Development Kit）
SHA：安全散列算法（Secure Hashing Algorithm）
T/CCF 0002—2024
3
SM2：SM2椭圆曲线公钥密码算法
SM3：SM3密码杂凑算法
SM4：SM4分组密码算法
SPA：单包授权协议（Single Packet Authorization）
TCP：传输控制协议（Transmission Control Protocol）
UDP：用户数据报文协议（User Datagram Protocol）
XOR：异或运算（exclusive OR）
5 NHP协议技术架构
NHP协议的技术架构由NHP代理、NHP服务器、NHP门禁以及授权服务提供商和被保护资源组成，如图1所示。各组件之间通过交互用户授权信息与被保护资源真实位置与放行策略，实现数据资源所在服务器的在网络上的安全隐藏与访问控制。NHP协议技术架构与GB/T 43696-2024中定义的零信任参考体系架构的对应关系参见附录A。NHP协议的主要应用场景及部署参见附录B。
图
1 NHP协议技术架构图
NHP协议各组件信息如下：
a.
NHP代理（NHP-Agent）
代表资源访问主体发起敲门请求的模块，形式可以是SDK、进程或者是客户端、移动App、浏览器、服务器后台服务等独立程序。
b.
NHP服务器（NHP-Server）
处理并验证敲门请求的模块，通常是服务器程序。其功能包括验证敲门请求并与外部授权服务提供商进行交互实现鉴权操作，以及控制NHP门禁进行访问授权动作。
T/CCF 0002—2024
4
NHP服务器作为NHP协议流程的中心处理单元，负责将整个协议流程中收到的请求与获得的回复按照会话记录下来，可以用将来的安全研究与合规分析。
c.
授权服务提供商（ASP）
由NHP协议的使用方提供的服务接口，以实现身份、设备、策略的验证和授权工作，同时也提供被保护资源的真实访问地址。
授权服务提供商提供的服务包括身份认证服务、设备验证服务、策略权限验证服务等。NHP服务器与NHP授权服务提供商的通信接口可采用HTTPS API或自定义TCP通信协议，以保证验证交互操作的同步性。
d.
NHP门禁（NHP-AC）
NHP门禁是访问控制的执行模块，通常是服务器程序。该模块执行默认“拒绝一切”（deny all）的安全策略并确保被保护资源的网络隐身状态，通常位于被保护资源所在的同一主机上。负责向已授权的NHP代理开放访问权限或向已失去授权的NHP代理关闭访问权限，并根据NHP服务器返回参数执行针对NHP代理的放行动作。
NHP门禁应记录访问授权与访问事件、访问流量等关键信息，并且向NHP服务器进行汇报。
e.
被保护资源（Protected Resource）
资源提供方的所要保护的资源，形式可以是数据API接口、数据应用服务器、网关、路由器、集群服务的负载均衡器等。
6 NHP协议实现过程
6.1 敲门交互流程
NHP协议敲门交互流程如图2所示。
T/CCF 0002—2024
5
图
2 NHP协议敲门交互流程示意图
NHP协议敲门交互流程如下：
a
） 步骤1：NHP代理对被保护资源进行访问之前，对NHP服务器发起敲门请求。
b
） 步骤2：NHP服务器接收到NHP代理的敲门数据包请求后，获取NHP代理的身份、设备、请求访问的授权服务提供商ASP和目标资源信息（下文统称代理信息）。
c
） 步骤3：NHP服务器将代理信息汇总并根据ASP信息找到对应的ASP服务器（如企业身份认证与权限管理系统）发起查询。
d
） 步骤4：ASP服务器根据代理信息进行认证和鉴权，对该NHP代理能够访问的目标资源进行授权，以及回复目标资源的真实IP地址和端口和其他授权信息（如：token）。
e
） 步骤5：NHP服务器在查询授权成功后，再向该目标资源所在的NHP门禁发起访问授权请求。
f
） 步骤6：NHP门禁收到NHP服务器请求后，确认所请求的目标资源与被保护资源是否匹配，放开该NHP代理到被保护资源的连接通道，并回复NHP服务器此次访问授权的时效。
g
） 步骤7：NHP服务器确认门禁访问授权成功后，回复NHP代理被保护资源的真实地址和访问控制时长。
h
） 步骤8：NHP代理对目标资源进行正常的业务访问。在此次敲门授权时效结束之前，NHP代理再次发起敲门请求，重复步骤1-7，以对资源访问进行续期。
i
） 步骤9（可选项）：以上交互过程以及数据通信过程产生的日志，上传到监管方进行合规审计。
6.2 敲门申请
NHP代理访问被保护资源时，事先并不知道被保护资源的真实地址，应进行资源访问的敲门申
T/CCF 0002—2024
6
请。NHP协议假设NHP代理与NHP服务器双方已经互相掌握对方的公钥。NHP代理向NHP服务器发送敲门包请求访问被保护资源。附录C.3给出了一种基于NHP协议框架的公钥分发方法.
为了满足应用场景需要，在NHP协议中的消息定义中除支持UDP敲门方式外，同时也兼顾TCP敲门的可能性，作为UDP敲门的替代或补充方案。
6.3 双向身份验证
NHP协议采用轻量级的噪声协议框架，支持资源访问主体身份与权限验证，实现双向验证与加密通信。NHP协议采用的噪声协议框架及算法见附录C。
6.4 访问授权
6.4.1 放行
NHP代理收到敲门成功的回复后对被保护资源进行访问（有限放行时间），同时将被保护资源真实地址（IP地址或IP地址上的某一个特定端口号）返回给NHP代理。如果敲门包授权失败，NHP服务器可依据具体处理情形对NHP代理保持静默或向NHP代理回复错误信息。
NHP门禁在接收到放行通知时，会结合当前系统的放行状况进行放行规则的创建或续期。每个建立的放行规则应有一个有限的时效。在时效到期后，放行规则失效，当前基于放行地址的连接需要被中断。NHP协议不对具体时效设置做限定，放行时效可以根据具体业务对网络稳定性的敏感度进行灵活制定，比如对于从终端用户到服务器的访问，放行时长设置短一些；而东西向流量中服务器之间的放行时长可以设置长一些。
6.4.2 阻断
NHP门禁在收到阻断通知时，应立即将当前的放行规则清除，并中断当前基于此地址的所有连接。
6.4.3 网络延时与补偿
访问授权时效需要结合当前NHP代理网络通信情况进行延时补偿，以确保NHP代理后续的正常敲门可以在时效到期之前完成放行规则的续期。在制定放行时长时也需要考虑意外丢包重试的时间。所以在具体实现时，需要记录并计算各个交互环节的往返与重试时间，并加入门禁的放行时长中进行补偿。
7 NHP协议消息定义
7.1 NHP协议包头
NHP协议报文由包头与消息两个部分组成。NHP协议包头包含了进行身份认证所需要的数据，用于支持通信双方的互相验证与数据交互。NHP协议消息定义见附录D。常用NHP协议包头的消息类型见附录D.1。
在协议交互流程中可使用UDP协议进行NHP协议数据包的传输，在需要时也可以使用TCP协议（短连接）。
NHP协议包头具有固定的160字节（标准长度，对应国际密码算法）或224字节（扩展长度，对应
T/CCF 0002—2024
7
国产密码算法）。包头后紧跟消息密文。前导混淆使用一个4字节随机数与消息类型和长度进行XOR运算，使其不暴露明文。消息采用伽罗/计数器加密模式（GCM） 携带附加数据的认证加密（AEAD），并将密文消息的大小（明文大小+16字节tag）写入包头的消息长度中以满足TCP协议要求。NHP协议发起、解析、确认与回复时，对包头的验证处理见附录D.2。
注1：伽罗/计数器加密模式（GCM）是一种数据分组加密算法。它采用计数器（Counter）加密模式，使明文与生成的密文长度相同。因其加解密时无需进行补位和拆位，更适用于固定长度的传输协议。同时，相对于块加密模式，伽罗/计数器加密模式在加密的过程中生成的附加消息验证码用于解密时对原始消息进行验证。
注2：携带附加数据的认证加密（AEAD），一种在加解密过程中额外添加附加数据参与认证计算的一种加解密方式。附加数据在加密时并不参与密文的生成，但是会影响最终的消息验证码，在解密时需要同样的附加数据才能够进行正确验证，增强了算法的安全性。
NHP协议的消息作为NHP包头的载荷，与包头一起共同组成NHP协议报文。包头与载荷总长度不能超过UDP报文的长度上限，即65536字节。NHP协议消息由协议包头中的消息类型进行区分，不同类型的消息在不同的逻辑组件中被创建和处理。如无特殊说明，在协议中消息体明文均使用JSON格式，并且使用zlib压缩，并由创建或解析包头时计算出的密钥进行加解密。
NHP协议包头标准长度见图3所示。
图
3 NHP协议包头（标准长度）
NHP协议包头扩展长度见图4所示。
T/CCF 0002—2024
8
图
4 NHP协议包头（扩展长度）
NHP协议包头字段见表1。
表
1 NHP协议包头字段
字段（字节数）
描述
前导混淆（4）
一个随机数，用于混淆消息类型与消息长度。
消息类型（2）
表示携带消息的类型。
消息长度（2）
表示携带消息的字节数。
协议大版本号（1）
NHP协议的major版本号。
协议小版本号（1）
NHP协议的minor版本号。
协议标志（2）
16个NHP协议的标志位。
比特位0：0标志包头大小为标准长度；1标志包头大小为扩展长度。
比特位1：0标志实际载荷消息无压缩；1标志实际载荷消息已被压缩。
其他标志位预留。
预留（4）
预留4个字节，默认置0。
计数器（8）
发起方维护的一个uint64计数器，作为GCM加密的随机数（nonce），使每一次发包都带有不同值。
随机公钥（32或64）
为每一次交互分配一个随机的公钥。算法可选择Curve25519、SM2等支持椭圆曲线DH密钥交换（ECDH）算法。
注1：椭圆曲线DH密钥交换（ECDH）是一种基于椭圆曲线非对称加密算法（Elliptic Curve Cryptography，简称ECC）的密钥交换算法。它能够让陌生的通信双方在不安全的通道上建立一个共同密钥（shared secret），其算法比签名算法更加轻量化。用于ECDH的常见ECC算法有Curve25519、SM2。
T/CCF 0002—2024
9
本机公钥密文（48或80）
由本地主机公钥经过中间密钥进行AEAD加密。
时间戳密文（24）
由当前int64时间戳经过另一组中间密钥进行AEAD加密。
HMAC（32）
基于上述所有字段计算得出。算法可选择SHA256、SM3或其他高效鲁棒的算法，用于验证消息的完整性。HMAC验证在计算上是轻量级的，因此可以用来提供抵御DDoS攻击的弹性能力。任何带有无效HMAC的报文将被立即丢弃。
7.2 NHP协议消息
7.2.1 NHP-KNK（Knock）消息
NHP-KNK消息由NHP代理发起，NHP服务器接收，应使用NHP协议包头，消息类型为1。消息中携带自身的用户、设备、终端运行环境参数等需要验证的信息和需要访问的目标资源信息（可以为自定义域名、ID或其他字符串）。此处的用户、设备等信息应与外部授权服务提供商（ASP）对接。
NHP-KNK消息字段见表2，消息示例见附录D.2.1。
表
2 NHP-KNK消息字段
字段
描述
用户 ID
为每个用户分配一个唯一标识符。该字段用于区分发送报文的用户。
设备 ID
为每个设备分配一个唯一标识符。该字段用于区分发送报文的设备。
授权服务提供商ID
为每个第三方授权服务提供商ASP分配一个唯一标识符。该字段用于对接指定的第三方服务。
资源 ID
为每个被保护资源分配一个唯一标识符。该字段用于查找需要访问的资源信息。
源 IP 地址
当前NHP代理请求的源IP地址。（前提是NHP代理必须能够获得出口处的IP地址，供NHP服务器使用，可选）
源端口号
当前NHP代理请求的源端口号。（前提是NHP代理必须能够获得出口处源端口的信息，供NHP服务器使用，可选）
终端环境参数
上报NHP代理对各条终端环境检测参数的校验结果，可以为["checkID0":result, "checkID1":result, ...]的数组形式。检测参数与checkID由NHP代理与第三方授权服务提供商共同制定。
7.2.2 NHP-ACK（Acknowledge）消息
NHP-ACK此消息由NHP服务器发起，NHP代理接收，应使用NHP协议包头，消息类型为2。授权完成后，NHP服务器回复鉴权和访问授权成功或错误码的NHP-ACK消息，它与NHP-KNK消息组成一次会话。如果敲门成功，则消息中携带被访问服务的真实地址、本次会话创建的ID（8字节uint64类型）、访问授权临时访问端口或者令牌等信息。NHP代理可以利用从 NHP-ACK 消息中获取的信息，建立对被保护资源的访问连接。
NHP-ACK消息字段见表3，消息示例见附录D.2.2。
表
3 NHP-ACK消息字段
字段
描述
T/CCF 0002—2024
10
用户 ID
标识发起请求的用户索引。
设备 ID
标识发起请求的设备索引。
服务提供商 ID
标识回应的服务提供商索引。
资源 ID
标识所请求的目标资源索引。
会话 ID
为每一次发起敲门请求分配一个会话索引。
错误码
用来标识敲门失败的错误原因。敲门成功时为0。
资源地址
待访问目标资源的IP地址和端口。
放行时长
本次会话能够进行资源访问的时长（秒）。
访问授权临时访问端口（可选）
本次访问授权开放的临时端口，与NHP-ACC消息结合使用（见附录D.8.1）。
访问授权临时访问令牌（可选）
本次访问授权生成的临时随机令牌，与NHP-ACC消息结合使用（见附录D.8.1）。
7.2.3 NHP-QRY（Query）消息
NHP-QRY消息为NHP 服务器向第三方授权服务商ASP发送的消息，应使用HTTPS 通信。NHP服务器通过分析NHP-KNK包中的待访问服务信息，确定由哪个服务提供商进行鉴权认证。NHP服务器向第三方鉴权服务发送MHP-QRY消息，携带NHP代理的用户、设备信息。
NHP-QRY消息字段见下表4，均为必选字段。
表
4 NHP-QRY消息字段
字段
描述
时间戳
请求查询时间。
用户 ID
NHP代理用户标识。
设备 ID
NHP代理设备标识。
资源 ID
待访问目标资源标识。
终端环境检测结果
由NHP代理上报的终端环境检测结果
7.2.4 NHP-AUT（Authorization）消息
完成鉴权后，ASP服务向NHP服务器返回验证结果，回复NHP-AUT消息，作为NHP-QRY消息的HTTPS回应。
NHP-AUT消息字段见下表5，均为必选字段。
表
5 NHP-AUT消息字段
字段
描述
时间戳
授权回复的时间。
用户 ID
NHP代理用户标识。
设备 ID
NHP代理设备标识。
资源 ID
待访问目标资源标识。
T/CCF 0002—2024
11
错误码
用来标识用户设备访问失败的错误原因。授权成功时为0。
资源 IP 地址
鉴权成功返回被保护资源的真实IP地址，否则返回空。
7.2.5 NHP-AOP（AC Operations）消息
NHP-AOP消息由NHP服务器发起，NHP门禁接收，应使用NHP协议包头，消息类型为3。NHP服务器通过发送NHP-AOP消息，通知NHP门禁对NHP代理进行放行或阻断操作。消息中携带NHP代理的源IP地址和端口号，被保护资源的地址和端口号。
NHP-AOP消息字段见下表6，消息示例见附录D.2.3。
表
6 NHP-AOP消息字段
字段
描述
会话 ID
标识服务器上此次敲门请求的会话索引（与返给NHP代理的值相同）。
设备 ID
NHP代理的设备唯一标识符。
公钥
NHP代理的公钥。
源 IP 地址
NHP代理的源IP地址。
源端口号
NHP代理的源端口号（可选）。
目的 IP 地址
被保护资源的IP地址。
目的端口号
被保护资源的端口号。
放行时长
需要放行的时长（秒）。阻断时放行时长为0。
7.2.6 NHP-ART（AC Result）消息
NHP-ART消息由NHP门禁发起，NHP服务器接收，应使用NHP协议包头，消息类型为4。NHP门禁访问授权后，通过NHP-ART消息回复NHP服务器，与NHP-AOP消息组成一次会话。消息中携带此次会话ID，实际访问授权时长等信息。NHP门禁放行时，使用创建NHP-ART包头时产生的随机私钥，基于NHP代理的公钥和NHP代理设备ID生成访问授权令牌（token）。访问授权令牌可以用作后端系统应用层的二次验证。但token值不会以明文形式返回给NHP代理。NHP门禁阻断时，不产生令牌，放行时长返回0。
NHP-ART消息字段见下表7，消息示例见附录D.2.4。
表
7 NHP-ART消息字段
字段
描述
会话 ID
对应请求时的会话ID。
放行时长
实际放行的时长（秒）。阻断时放行时长为0。
访问授权临时访问端口（可选）
本次访问授权开放的临时端口，与NHP-ACC消息结合使用（见附录D.8.1）。
访问授权临时访问令牌（可选）
本次访问授权生成的临时随机令牌，与NHP-ACC消息结合使用（见附录D.8.1）。
8 日志记录
T/CCF 0002—2024
12
8.1 概述
日志可分为运维日志与安全日志。运维日志记录程序运行时产生的业务流程、处理逻辑等信息。安全日志记录关键业务流程和潜在攻击信息，可以和安全信息和事件管理系统（SIEM）对接实现威胁感知与防护。
NHP服务器将日志记录汇总之后，可以上传至数据资源监管机构进行安全审计。NHP协议提供了一种可选的门禁日志上报方式，见附录D.9。
8.2 日志消息格式
日志消息字段见表8。
表
8 日志消息字段
字段
描述
时间
当前日志记录的时间。
严重等级
事件的严重等级（info、debug、trace、warning、critical等）。
名称
具备可读性的事件名称。
主机信息
产生该事件的主机信息。
8.3 运维日志
运维日志记录组件的运行逻辑，记录内容见表9。
表
9 运维日志内容
活动
记录的数据或信息
NHP服务器的启动，关闭与重启
启动、关闭或重启的原因。
NHP服务器与NHP代理的连接信息
NHP代理发送的请求、源IP地址和源端口、消息格式验证错误并丢弃敲门请求的原因、NHP服务器回复NHP代理的消息或者不回复的原因。
NHP服务器与外部ASP服务交互的信息
NHP服务器与第三方ASP服务连接信息；查询用户和鉴权的结果。
NHP服务器与NHP门禁之间的连接信息
发起访问授权请求的用户设备会话信息；收到访问授权回复的结果。
NHP门禁的启动，关闭与重启
启动、关闭或重启的原因。
NHP门禁访问授权
是否满足请求约定的放行时间。如果推翻约定，推翻的原因。
8.4 安全日志
安全日志记录组件被外部访问的情况，记录内容见表10。
表
10 安全日志内容
活动
记录的数据或信息
由NHP代理发起的合法敲门请求
NHP代理对应的用户、设备、会话、IP地址和端口等。
NHP服务器上来源不明的不合法请求
记录协议、源IP地址、端口（如果能获取）等。
NHP门禁上来源不明的访问
记录协议、源IP地址、端口（如果能获取）等。
T/CCF 0002—2024
13
8.5 流量日志
流量日志记录组件由外部访问的流量情况，记录内容见表11。
表
11 流量日志内容
活动
记录的数据或信息
NHP服务器上来自不同网络地址的累积流量
记录协议、源IP地址、端口（如果能获取）、总字节数等。
NHP门禁上被拒绝的访问累积流量
记录协议、源IP地址、端口（如果能获取）、总字节数等。
NHP门禁上授权访问的累积流量
记录协议、源IP地址、端口（如果能获取）、总字节数等。
9 测试验证方法
9.1 隐身能力验证
NHP协议的隐身能力验证应同时满足以下两个方面：
1)
资源访问主体未经过身份认证前，被保护的资源的主机IP是否对其已知。
2)
资源访问主体未经过身份认证前，被保护的资源的主机端口是否可以扫描到。
9.2 噪声算法验证
NHP协议的高安全、高性能源于其基于噪声协议的身份认证机制。为验证噪声协议的实现及性能，NHP协议中的噪声算法应同时满足以下三个方面：
1)
发起方对每一次消息进行加密时必须引入随机数（随机公私钥对），并将由此随机数产生的中间衍生数引入算法中所有的加密环节。接收方在获取原始随机数后，能用同样的算法生成相同的中间衍生数进行解密。
2)
发起方与接收方必须使用ECDH算法将其中一方的身份与随机数进行混合计算，生成中间衍生数参与加解密计算。
3)
发起方与接收方必须使用ECDH算法将自身的私钥与对方的公钥进行混合计算，生成中间衍生数参与加解密计算。
9.3 可用性测试验证
NHP协议架构的高可用性验证应同时满足以下三个方面：
1)
敲门验证的NHP服务器与NHP门禁服务不在同一个主机上。
2)
敲门验证服务可以横向弹性扩展成多台主机，选择其中任何一个服务器发送敲门数据包都可以完成同一个业务会话的敲门验证。
3)
门禁与被保护资源的所在主机IP地址由NHP敲门验证服务动态返回给NHP代理，而不是静态的，利于实现多台服务器之间的负载均衡。
9.4 扩展性测试
NHP协议架构的高扩展性验证应同时满足以下三个方面：
NHP代理与NHP服务器的通信是双向的。
T/CCF 0002—2024
14
1)
身份认证与权限鉴定可由外部授权服务提供商ASP来完成，ASP接受来自NHP服务器的NHP代理信息数据之后，对身份认证与权限鉴定做出判别，NHP代理将收到ASP的判别结果。
2)
NHP消息的类型是可扩展的，新的扩展消息可以交由ASP处理之后并把处理结果返回给NHP代理。
3)
数据资源服务器的标识可以是任意字符串，而不是局限于域名形式。NHP服务器可以根据标识字符串返回正确的数据资源服务器IP地址。
9.5 兼容性测试
NHP协议的兼容性验证应同时满足以下两个方面：
1)
NHP协议同时支持国际加密算法与国密加密算法进行验证。使用上述不同算法的时候，数据包头的长度不同，加密的时间也不同。
2)
NHP协议的实现代码必须同时支持至少一种国产化的CPU硬件和操作系统平台。
T/CCF 0002—2024
15
附 录 A （资料性） 与GB/T 43696-2024中定义的零信任参考体系架构的对应关系
A.1 与GB/T 43696-2024零信任参考体系架构的对应关系
NHP协议是零信任安全架构一种轻量化的实现方案，其组件与GB/T 43696-2024中图1定义的零信任参考体系架构对应关系如下：
（
1）NHP服务器与授权服务提供商ASP对应参考体系架构中位于控制层的“策略决定点”单元。
（
2）NHP代理对应参考体系架构中数据层的“主体”实体。
（
3）NHP门禁对应参考体系架构中数据层的“策略执行点”单元。
（
4）被保护资源对应参考体系架构中数据层的“资源”实体。
NHP协议支持与第三方组件集成，第三方输入对应参考体系架构中的支撑组件（“态势感知”、“资源管理”、“设备管理”、“身份管理”与“密码服务和应用”等功能模块）。
图
A.1 零信任参考体系架构图
T/CCF 0002—2024
16
附 录 B （资料性） NHP协议的主要应用场景与部署
B.1 NHP协议的应用场景
GB/T 39204-2022在主动防御方面，明确要求收敛暴露面：应识别和减少互联网和内网资产的互联网协议地址、端口、应用服务等暴露面，压缩互联网出口数量。NHP协议是零信任安全理念的一种轻量级的实现方案，能有效收缩暴露面，可用于各种数据通信交互场景。
NHP协议的应用场景不限于附录B中定义的应用场景，在需要对网络上资源进行隐身的场景都可以使用NHP协议进行资源的保护。
B.1.1 数据要素流通与交易场景
建设安全可信的数据基础设施，让数据要素“流得动”，是发展数字经济发展的必要条件。传统网络安全范式通过建立静态的边界来提供安全隔离，不利于数据的流通共享。NHP协议基于零信任安全“永不信任，持续验证”的核心理念，通过网络隐身技术来保障数据资源提供方的数据API接口只对合法授权的访问者开放，黑客无法通过软件系统漏洞等攻击手段来非法访问数据，并且通过持续的验证以及最小化授权原则，避免合法用户的越权访问，从而保障了数据交互过程中的可信、可控、可靠、可证等四大核心安全原则。此外，NHP协议具备灵活的扩展能力，可以通过与数据交易平台以及监管机构的对接，为数据交易平台提供数据访问的计量计费依据，以及为监管机构提供数据要素流通与交易的合规监管依据。数据要素流通与交易场景见图B.1。
图
B.1 数据要素流通与交易场景
T/CCF 0002—2024
17
B.1.2 远程/移动办公场景
数字化转型的纵深和横向发展，业务发展需要，远程/移动办公成为办公常态，组织不得不将部分业务系统/网络设备开放到公网上来，远程/移动办公/运维人员在公网可以连接业务系统/网络设备，业务系统/网络设备开放到公网，存在很多安全风险，需要有效的手段进行保护。
为平衡业务发展和网络资源安全防护，组织可使用NHP协议对业务资源/网络设备进行隐身，兼顾业务发展，相关人员可远程/移动办公连接企业的业务资源/网络设备，同时组织的业务资源/网络设备无需暴露在公网。
B.1.3 系统上云场景
云计算在国内经过多年的发展和沉淀，各组织对云计算的认知和接受程度都有了很大的变化，逐渐采用云服务或将私有系统上云（私有云/公有云/混合云）以应对组织和业务发展需要。直接采用云服务或将系统上云都会增大业务系统资源暴露面，存在安全隐患。
直接采用云服务或将系统上云场景都可以采用NHP协议进行业务资源的隐身，减少业务资源暴露面，在兼顾业务发展需要，享受云计算技术带来的便利，减少运维成本的同时，保护业务系统资源的安全，减少被攻击和恶意访问的风险。
B.1.4 分支机构互访场景
大型企业、事业单位多拥有多个分支机构（业务扩大，原组织自身发展壮大、衍生出多个分支机构；业务发展需要，收购子组织或合并相关组织），分支机构拥有自己独立的业务系统，为避免重复建设，分支机构保留原来的业务系统，同时还有访问总部或其他分支业务系统资源的需要，总部或分支机构的业务资源需要暴露给其他分支。
总部或分支机构在共享自己的业务资源/网络设备给其他分支时，可以采用NHP协议对需要开放共享的业务资源进行资源隐身，兼顾业务需要的同时，实现总部或分支机构资源的隐身，保护业务系统资源的安全，减少被攻击和恶意访问的风险。
B.1.5 攻击样本研究场景
除了提供安全防御能力， NHP协议框架也可以提供攻击样本捕获的能力，以赋能企业或第三方安全研究机构进行攻击样本的研究。举例来说，当NHP服务器对某个NHP代理进行身份认证时，如果认证失败，可以仍然给该NHP代理返回成功的消息，但同时返回目标资源地址是蜜罐系统所在的主机地址，以将攻击者引流到指定的蜜罐系统，引诱攻击者对蜜罐中的陷阱服务作出攻击行为，从而由进行攻击样本的捕捉与分析。
攻击样本研究场景见图B.2。
T/CCF 0002—2024
18
图
B.2 NHP协议可以向蜜罐系统引流
B.2 NHP协议部署建议
B.2.1 NHP协议应支持的终端类型
NHP协议系统中NHP代理部署在资源访问主体使用的终端设别或者服务器上，其应兼容各种终端环境类型，便于在各种场景进行推广。
B.2.2 NHP协议的部署模式
NHP协议系统采用Client/Server架构模式进行部署，由三大组件组成：NHP代理、NHP服务器、NHP门禁。NHP服务器的部署应支持私有化部署和云化部署。本章节以被保护资源为业务系统为例，列举几个常见的部署模式。
B.2.2.1 私有化部署
NHP协议系统可采用私有化部署模式进行建设，参考合规要求及组织管理要求，NHP协议系统与组织当前的网络架构融合，可部署在组织防火墙后、业务系统资源前，实现安全访问接入组织网络与资源。
（1）独立客户端模式
NHP协议系统在部署时可采用独立客户端模式，即NHP 代理可以是独立的NHP代理程序安装在终端设备中。私有化独立客户端模式架构图如下图所示。客户端服务安装在终端设备，NHP服务器独立部署，NHP门禁与业务系统服务紧耦合。私有化独立客户端模式见图B.3。
T/CCF 0002—2024
19
图
B.3 私有化独立客户端模式
独立客户端模式可实现全局的安全防护，即终端上安装NHP代理后，终端上的所有受控应用（C/S应用、B/S应用、移动应用）的访问都受NHP协议防护。
（2）SDK集成模式
NHP在部署时也可采用以SDK的方式集成进现有业务系统（C/S应用、Web应用、移动APP、小程序等）客户端程序中，NHP服务器独立部署，NHP门禁与业务系统服务紧耦合。私有化SDK集成模式见图B.4。
图
B.4 私有化SDK集成模式
SDK集成方式无需安装单独的客户端，用户使用的便利性提升，也便于IT部门进行推广。但SDK集成模式本身才存在一些缺点，SDK集成方式在NHP代理程序本身需要升级时，需要连带业务系统重新集成并升级，用户升级整个业务系统客户端和NHP的SDK包；在多个业务系统都需要NHP协议防护时，SDK集成模式需要每个业务系统都要单独集成安装包。
（3）服务器-服务器模式
NHP协议也可以用于服务器间东西向数据流量的控制。通过私有部署的NHP服务器实现内网服务器间的隐身与微隔离。服务器上不仅可以运行NHP门禁程序用来为自己后台的业务应用隐身，也可以同时运行NHP代理程序对已经隐身的其它服务器进行授权访问。服务器-服务器模式见图B.5。
T/CCF 0002—2024
20
图
B.5 服务器-服务器模式
B.2.2.2 云化部署
NHP协议系统支持云化部署模式进行建设，结合云计算的特点和优势，更好的为组织挺高轻量化、便捷式的安全服务。同私有化部署模式，NHP代理安装在终端设备上，但NHP的服务器部署在云上，NHP以云服务方式进行推广使用。
云化部署也应该支持独立客户端模式和集成SDK模式。
（1）独立客户端模式
云化部署模式下，独立客户端模式与私有化部署类似，只是将NHP服务器部署在云上，以云服务的方式对外提供服务。被保护的业务系统可以是私有化系统，也可以是公有云服务，NHP门禁下沉至组织内网或公有云业务服务上。独立客户端模式见图B.6。
图
B.6 云化独立客户端模式
（2）集成SDK模式
云化部署模式下，集成SDK模式与私有化部署类似，只是将NHP服务器部署在云上，以云服务的方式对外提供服务。云服务厂商对外提供标准SDK、集成文档、集成接口，供各个组织的进行集成。被保护的业务系统可以是私有化系统，也可以是公有云服务，NHP门禁下沉至组织内网或公有云业务服务上。集成SDk模式见图B.7。
T/CCF 0002—2024
21
图
B.7 云化集成SDK模式
（3）云化服务器-服务器模式
将NHP服务器部署在云上，也可以将NHP协议用于私有或云空间内服务器之间东西向数据流量控制。通过云上的NHP服务器实现服务器间的隐身与微隔离。业务系统的服务器上不仅可以运行NHP门禁程序用来为自己后台的业务应用隐身，也可以同时运行NHP代理程序对已经隐身的其它业务系统服务器进行授权访问。云化服务器-服务器模式见图B.8。
图
B.8 云化服务器-服务器模式
B.3 与现有网络隐身协议兼容和平滑升级
对于已经部署了零信任网络隐身相关产品或服务的组织，根据自身数字化转型规划和当前进展以及安全规划决定是否升级零信任网络隐身服务。如组织当前有规划升级安全服务，则组织选择合适的时间点进行升级或重新部署。
由于NHP协议是SPA协议的升级和完善，有一定的继承性。在升级时如组织或安全厂商对当前网络隐身服务和NHP协议都足够了解，可在当前网络隐身协议的基础上增补NHP协议具备但SPA协议不具备的功能模块，组织安全人员和业务系统人员做好规划，充分测试后升级服务；如组织对当前网络隐身协议或安全厂商更换，则建议重新部署NHP协议相关服务，在新旧服务交替阶段，建议保留原来
T/CCF 0002—2024
22
隐身服务，采用灰度发布的模式，逐步迁移用户到新的服务，直到新服务使用和运行一段时间未发现问题后，再将旧的隐身服务关停。
如组织当前没有规划升级安全服务，则需要等待合适的时机进行升级服务，依旧使用当前的网络隐身服务进行安全接入防护。
B.4 用户身份认证和设备身份认证
身份认证的目的是鉴别通信中另一端的真实身份，防止伪造和假冒等情况发生，保证通信参与方的可信。根据身份认证的对象不同，认证手段也不同，但针对每种身份的认证都有很多种不同的方法。身份认证的对象可以是人，也可以是网络设备，也可以是机器，也可以是物联网中的物。
B.4.1 用户身份认证
如果被认证的对象是自然人，则有三类信息可以用于身份认证，即“知道什么”、“拥有什么”、“是什么”来鉴别身份。常见的身份鉴别的方式见表B.2。
表
B.1 用户身份认证方式
序号
认证方式
所属类型
优缺点
1
账户密码
知道什么
低安全、低便捷性、低成本
2
扫码认证
拥有什么
安全、便捷、低成本
3
USB Key
拥有什么
安全、低便捷性、成本高
4
数字证书
拥有什么
安全、便捷、高成本
5
OTP认证
拥有什么
相对安全、相对便捷、有一定成本
6
短信验证码
拥有什么
相对安全、相对便捷、有一定成本
7
人脸识别
是什么
安全、便捷、高成本
8
指纹识别
是什么
相对安全、便捷、有一定成本
表中列举了几种常见的用户身份认证的方式。组织在使用NHP协议进行安全建设时，不限于使用表中的认证方式进行身份认证。在访问关键业务系统或含有敏感信息的系统时，应采用两种或两种以上组合的认证技术对用户进行身份认证（多因素认证MFA）。
B.4.2 设备身份认证
设备身份认证是指对用户访问业务资源时使用的设备进行身份认证，或终端设备作为访问主体时对主体设备进行身份认证。设备身份认证也存在多种认证方式，如采用设备指纹的方式对设备进行标识和鉴别、采用公钥密码算法、内嵌数字证书的方式进行鉴别等。终端设备类型见表B.1。
（1）设备指纹
设备指纹是指用于唯一标识出该设备的设备特征或者独特的设备标识。设备指纹包括一些固有的、较难篡改的、唯一的设备标识，同时，设备的其他特征集合（设备的名称、型号、形状、颜色、功能等）也可以采用一定的算法来综合计算设备指纹。设备指纹需要做到唯一性，即唯一地标识出该设备，不会与其他设备重复、每次计算不会改变、也难以被仿冒。具备唯一性的设备指纹可以用于设备标识，也可以用户设备身份认证。
（2）数字证书
T/CCF 0002—2024
23
数字证书是一种特殊的文件格式，包含用户/设备身份信息、用户/设备公钥信息和证书认证中心私钥的签名。数字证书可作为数字身份证，在网络世界中进行交互时，证书持有人/设备只需出示数字证书，对方通过判断该证书是否伪造、持证人是否拥有对应的私钥、该证书是否被作废或冻结等内容即可验证该持证人/设备的身份是否合法，从而很方便地实现高强度的身份认证功能。利用数字证书完成设备（尤其是物联网设备）身份认证是目前最为安全有效的一种技术手段。
T/CCF 0002—2024
24
附 录 C （资料性） 噪声协议框架及算法
噪声协议是一种结合随机ECC密钥对和ECDH算法的密钥协商协议。噪声协议框架隐式实现了交互双方身份的验证与最终密钥的生成，并且由于在每一次交互时都引入了随机密钥对，非常适合基于单次会话数据加解密应用。另一方面，由于ECC算法在提供同级别安全强度时所需的密钥长度比RSA算法短得多（例如RSA2048加密需要使用256字节公钥，而实现同级别安全性的ECC公钥只需要32字节），ECDH算法比使用RSA签名在密钥、密文长度和计算开销上都小得多，安全性更高。
设备密钥的来源可以是软件随机生成，也可以从U盾或数字证书中获取。采用噪声协议提供了一种能够简化协议双方维护和发放数字签名证书步骤的可能性。本着安全、简洁、高效的原则，NHP协议采用噪声协议框架进行协议双方的验证与数据加密。同时，在NHP协议包头中也定义了64字节（512比特）公钥的扩展长度，以适用未来加密算法的更新。
NHP中使用的噪声协议框架也支持使用国密算法（SM2、SM3、SM4等）实现双向验证与加密通信。
C.1 RSA与ECC的安全强度与开销对比
由表C.1可以看出，在提供同等安全强度的基础上，ECC算法密钥长度要远小于RSA算法密钥长度。而由RSA消息签名产生的密文尺寸和密钥长度相当。因此在对网络消息进行身份验证时，传输随机ECC密钥（32字节或64字节）进行ECDH交换比传输RSA2048消息签名（256字节）进行验签的计算开销更小，同时更节省带宽资源。
表C.1 RSA与ECC安全强度与密钥长度
安全强度（比特）
最小公钥长度（比特）
密钥长度比
DSA/RSA
ECC
ECC比DSA/RSA
有效性
80
1024
160-223
1:6
到2010年
112
2048
224-255
1:9
到2030年
128
3072
256-383
1:12
2031年以后
192
7680
384-511
1:20
256
15360
512+
1:30
C.2 NHP协议使用的噪声协议算法及流程
NHP协议使用的噪声协议算法及流程见图C.1和C.2。
T/CCF 0002—2024
25
图C.1 发起方A向接受方B发起请求
T/CCF 0002—2024
26
图C.2 接受方B向发起方A发起回应
T/CCF 0002—2024
27
附 录 D （规范性） NHP协议消息定义
D.1 NHP协议消息列表
NHP协议定义了18种常用NHP协议包头的消息类型，定义了两种非NHP包头的参考性消息类型，分别用来实现不同的功能。消息定义、用法与示例见表D.1。
表D.1 NHP协议控制消息列表
名称
类型
描述
NHP-KPL
0
用于支持协议双方保活机制。
NHP-KNK
1
用于NHP代理向服务器发起敲门请求。
NHP-ACK
2
用于NHP服务器向NHP代理回应敲门结果。
NHP-AOP
3
用于NHP服务器向NHP门禁请求开关门操作。
NHP-ART
4
用于NHP门禁向NHP服务器回复开关门结果。
NHP-LST
5
用于NHP代理或NHP门禁向NHP服务器发起服务发现查询。
NHP-LRT
6
用于NHP服务器向NHP代理或NHP门禁回复查询结果。
NHP-COK
7
用于NHP服务器向NHP代理发送cookie。
NHP-RKN
8
用于NHP代理向NHP服务器发起二次敲门请求。
NHP-RLY
9
用于NHP中继向NHP服务器转发敲门或发现请求。
NHP-AOL
10
用于NHP门禁向NHP服务器报告自身在线状态。
NHP-AAK
11
用于NHP服务器向门禁确认连接成功。
NHP-OTP
12
用于NHP代理向服务器申请生成一次性验证码。
NHP-REG
13
用于NHP代理向服务器注册自身的公钥。
NHP-RAK
14
用于NHP服务器确认NHP代理注册成功。
NHP-ACC
15
用于NHP代理访问门禁的随机临时端口。
NHP-LOG
16
用于NHP门禁向NHP服务器上报日志。
NHP-LAK
17
用于NHP服务器向NHP门禁回复日志消息接收成功。
D.2 敲门与验证
D.2.1 NHP-KNK消息
NHP-KNK消息格式见7.2.1，消息示例如下。
{
"usrId": "9eb1e411-b7ab-4b78-b607-55cd51bcec6f",
"devId": "4d53a788-d9ca-11ed-afa1-0242ac120002",
T/CCF 0002—2024
28
"aspId": "d0b0e0bd-7ad9-4b94-b57c-c694e077e77f",
"resId": "267ebdaa-52c3-4330-9d77-f933d35c0a0e",
"srcIp": "123.234.56.78",
"srcPort": "62201",
"devCheck":[{"hasPassword":"1"}, {"hasAntivirus":"0"}, {"adminAccounts":"3"}]
}
D.2.2 NHP-ACK消息
NHP-ACK消息格式见7.2.2，消息示例如下。
{
"usrId": "9eb1e411-b7ab-4b78-b607-55cd51bcec6f",
"devId": "4d53a788-d9ca-11ed-afa1-0242ac120002",
"aspId": "d0b0e0bd-7ad9-4b94-b57c-c694e077e77f",
"resId": "267ebdaa-52c3-4330-9d77-f933d35c0a0e",
"session": "1",
"errCode": "0",
"appAddr": "221.210.54.43:443",
"accessTime": "45",
"accessPort": "36852",
"accessToken": "8c20d1a5-e053-4ee0-a111-5d7e5112c3bb"
}
D.2.3 NHP-AOP消息
NHP-AOP消息格式见7.2.5，消息示例如下。
{
"session": "1",
"devId": "f7a0a672-8c73-4814-9177-bdd69139cfdf",
"agentKey": "9876543210fedcbaabcdef012345678",
"srcIp": "123.234.56.78",
T/CCF 0002—2024
29
"srcPort": "62001",
"dstIp": "221.210.54.43",
"dstPort": "443",
"passTime": "300"
}
D.2.4 NHP-ART消息
NHP-ART消息格式见7.2.6，消息示例如下。
{
"session": "1",
"passTime": "45",
"accessPort": "36852",
"accessToken": "8c20d1a5-e053-4ee0-a111-5d7e5112c3bb"
}
D.3 密钥分发
NHP协议不限定NHP代理和NHP服务器之间的公钥生成和分发方式。具体实现可以采用物理U盾或由软件生成，通过提前录入数据库或安装时写入本地存储等方式使通信双方互相掌握对方公钥。NHP协议提供一种可选项，即NHP-REG消息，用于初次交互时NHP代理向NHP服务器或者密钥生成中心服务器（KGC）注册公钥。如果采用动态密钥管理，在NHP代理每次生成新的密钥后，也可以利用NHP-REG消息通知NHP服务器进行服务端公钥集的更新注册。
D.3.1 NHP-REG（Register）消息
此消息由 NHP代理发起，NHP服务器接收，用作NHP代理向NHP服务器分发（注册）自身密钥。必须使用NHP协议包头，消息类型为13。消息中携带NHP代理自身的用户、设备、一次性验证码（可以是短信、邮箱验证码，或者二维码的形式）信息向NHP服务器发起注册，验证通过后包头中的NHP代理动态公钥会被NHP服务器收录，NHP服务器返回NHP-RAK包通知NHP代理密钥注册成功。
NHP-REG消息字段见表D.2。
表D.2 NHP-REG消息字段
字段
描述
用户 ID
为每个用户分配一个唯一标识符。该字段用于区分发送报文的用户。
设备 ID
为每个设备分配一个唯一标识符。该字段用于区分发送报文的设备。
一次性验证码OTP
NHP代理获得的一次性的验证密码，由NHP服务器校验。用于NHP代理向NHP服务器证明自己
T/CCF 0002—2024
30
为合法终端。
消息示例：
{
"usrId": "9eb1e411-b7ab-4b78-b607-55cd51bcec6f",
"devId": "4d53a788-d9ca-11ed-afa1-0242ac120002",
"otp": "654321"
}
D.3.2 NHP-OTP（One-time Password）消息
NHP协议提供一种可选申请一次性验证码的方法。此消息由NHP代理发起，NHP服务器或者密钥生成中心服务器（KGC）接收，为NHP代理向服务器注册自身密钥的可选前置步骤。必须使用NHP协议包头，消息类型为12。消息中携带NHP代理自身的用户、设备、账户密码等信息向服务器发起验证码请求，经ASP验证通过后，ASP触发下发验证码操作，服务器不对NHP-OTP作出回应。NHP-OTP消息字段见表D.3.
表D.3 NHP-OTP消息字段
字段
描述
用户 ID
为每个用户分配一个唯一标识符。该字段用于区分发送报文的用户。
设备 ID
为每个设备分配一个唯一标识符。该字段用于区分发送报文的设备。
消息示例：
{
"usrId": "9eb1e411-b7ab-4b78-b607-55cd51bcec6f",
"devId": "4d53a788-d9ca-11ed-afa1-0242ac120002",
"passcode": "aBcD@123"
}
D.3.3 NHP-RAK（Register Acknowledge）消息
此消息由NHP服务器或者密钥生成中心（KGC）发起， NHP代理接收，用作服务器向NHP代理确认密钥注册成功。必须使用NHP协议包头，消息类型为14，消息体为空。
D.3.4 基于标识密钥体系IBC的密钥分发
尽管PKI密钥分发体系已经被广泛应用，但是在零信任安全架构场景下，随着用户与设备数量基数日益增多，所以为每一台用户设备提供密钥的分发过程以及后续的管理流程会便变得越来越复杂。因此，传统的基于PKI体系的密钥分发与验证体系已经很可能无法满足零信任安全架构对密钥验证中心的可
T/CCF 0002—2024
31
达性、健壮性与性能的高要求，而使用基于标识的加密算法（IBC）能够很好解决这个问题，有效简化密钥的分发与验证的过程。
IBC算法采用一套公共的公钥矩阵，能够将可读性更高的字符组合作为唯一标识来代替公钥进行传递并参与计算，大幅降低了密钥中心对公钥管理和分发流程上的复杂度。国内常见的IBC算法有国密SM9与CPK，二者都基于椭圆曲线算法ECC，都能够实现加解密、签名验签、密钥交换的操作。NHP协议中的噪声协议采用的就是ECC算法，所以IBC算法也可以用来实现本规范中的噪声协议流程。基于标识密钥体系IBC进行密钥注册以及密钥分发的字段说明见表D.4和D.5。
表D.4 IBC体系标识公钥注册的组成字段
字段
描述
NHP类型标志位
第0位：公钥类型为NHP-Agent
第1位：公钥类型为NHP-AC
第2位：公钥类型为NHP-Server
用户可读标识
用户名、手机号码、电子邮件地址等用户身份ID
设备唯一标识
网卡MAC地址、设备序列号等设备ID
随机数
任意6位随机数，用于加强该标识密钥的安全性，通常为NHP-OTP消息返回的一次性验证码
有效时长
申请注册的密钥的有效时长，以毫秒（ms）为单位
表D.5 KGC分发的用户数字证书的组成字段
字段
描述
版本号
证书格式的版本号
算法标识位
该IBC体系使用的算法组合，如：0代表SM9/SM3、1代表CPK/SM3等
颁发者公钥矩阵
包含公钥矩阵数据DER编码
颁发者标识
包含密钥生成中心颁发者的IBC标识
用户标识公钥
包含用户的IBC标识公钥
证书有效期起始时间
Epoch秒时间戳
证书有效期终止时间
Epoch秒时间戳
用户私钥密文
颁发者使用上述所有字段经KDF生成密钥对用户私钥进行对称加密的密文
数字签名
颁发者使用其私钥对上述所有字段SHA256/SM3哈希后进行的签名
D.3.5 无证书密钥体系CL-PKC（Certificateless Public Key Cryptography）
在基于标识的密钥体系中，私钥矩阵存储在中心KGC。一旦KGC被攻破，攻击者有可能通过KGC中的私钥矩阵算出用户的私钥。针对这一点，密码学界在IBC标识密钥算法的基础上，提出了安全性更高的无证书密钥体系CL-PKC，其算法参见GM/T 0130-2023。在这种体系下，公钥的计算与IBC几乎相同，但私钥并不单独依赖KGC计算生成，而需要由用户侧提供一部分密钥参与计算，最终生成用户的私钥。这样即使KGC的算法被破解，攻击