Nym 对 Cure53 安全审计的官方回应（2024 年 7 月）

更新于 2025 年 11 月 18 日

背景

NymVPN 旨在为您的网络通信提供私密、安全且可靠的防护。 在 Nym，透明度与用户信任至关重要。因此，Nym 始终坚持代码开源，并定期接受独立的第三方安全审计，以确保达到安全与隐私的最高标准。

2024 年 7 月，Nym 接受了 Cure53 的独立审计。Cure53 是一家总部位于柏林的网络安全公司，在软件测试和代码审计领域拥有超过 15 年的丰富经验。 Cure53 对 Nym 的核心基础设施进行了深入审查，范围覆盖移动与桌面客户端、VPN 系统、密码学算法实现以及整体系统架构。

所有已识别的严重和高危漏洞均已得到修复。 在 Cure53 对我们实施的修复方案进行复核后，所有严重及高危漏洞均被确认已得到解决。

Cure53 的完整报告已在此处发布：点击此处查看。 您还可以观看 Nadim Kobeissi 博士为 OSTIF 所做的演讲；他在演讲中探讨了 Nym 的审计情况，并对审计过程中发现的部分问题进行了深入的技术解析。

Cure53 关于 Nym 的安全审计摘要

Cure53 对 Nym 生态系统进行了全面的安全评估，涵盖渗透测试、源码审计和代码审查。 审查重点在于评估 Nym 的总体安全姿态，具体包含移动及桌面应用程序、后端 API 接口、VPN 软件与基础设施，以及密码学实现方式。 在整个审计期间，Nym 团队始终与 Cure53 团队保持密切配合，确保了高效顺畅的协作与公开透明的流程。

Cure53 实施了基于“水晶盒”模式的测试策略，全面对接了源代码、构建产物、技术文档、测试环境及相关学术论文等全套支撑材料。 本次审计历时 56 个工作日，由一支由六位高级网络安全专家组成的团队协同完成。 审计评估划分为五个独立的工作包（WP）：

• WP1：Nym 移动端应用程序
• WP2：Nym 桌面端应用程序
• WP3：Nym 后端 API 接口
• WP4：Nym VPN 软件与基础架构
• WP5：Nym 底层密码学实现

本次审计对既定目标实施了深度且全面的安全覆盖，共识别出 43 项分析项。具体包括 7 项安全漏洞（含严重与高风险级别）及 24 项通用缺陷；后者被归类为中低度可利用风险，构成了系统架构深层强化的提升契机。

NymVPN 软件系统及其基础设施展示出卓越的安全防护水平，本次安全审计未发现任何已知缺陷。 Cure53 总结认为，所有接受评估的组件均具备坚实的安全基础，整体呈现出强劲的安全防护态势。 评估认为，桌面端应用在安全层面处于良好状态，未发现任何重大安全漏洞。 审计团队特别指出，整体代码实现与架构非常扎实。 同样，从安全角度评估，Nym 后端及 API 服务处于中等水平。 值得注意的是，报告特别肯定了数个严重漏洞已得到有效缓解与预防，这凸显出我们在安全防护上的主动性以及严谨的代码实现。

核心评估发现 / 关键审计结论

工作包 1（WP1）：对 Nym 移动端应用进行“水晶盒”渗透测试与源代码审计

在工作包 1（WP1）中，Cure53 对适用于 Android 和 iOS 的 NymVPN 移动应用程序开展了静态与动态分析，并结合了白盒测试。 评估目标旨在识别应用中存在的任何漏洞缺陷、配置错误或安全风险。 总体而言，所发现问题的严重程度较低，未识别出任何严重或高风险漏洞。 所识别出的问题主要属于中危、低危或信息性级别，可在后续全面巩固与强化应用的专项工作中得到有效解决。 静态分析旨在找出应用中可能导致安全弱点的次优配置或错误设置。 然而，分析结果显示未发现任何高风险隐患。

此外，Cure53 还深入调查了 Android 系统常见的攻击向量，包括对未导出组件的潜在访问、身份验证绕过、广播接收器故障以及 Intent 附加数据校验不足等问题。 在所有上述领域中均未发现任何安全漏洞，这充分体现了该平台安全防护措施的强硬实力。

Cure53 还确认，Android 和 iOS 应用程序均未包含任何硬编码的敏感信息或密钥/机密数据，而这是安全防护中的一项核心考量。

总体而言，移动端应用程序展现出良好的安全姿态，攻击面已被降至极低。 除了少数有待改进的次要领域（例如 iOS 应用原生的安全存储使用不当，编号 NYM-01-024）之外，应用中未识别出任何重大安全缺陷。

工作包 2（WP2）：对 Nym 桌面端应用进行“水晶盒”渗透测试与源代码审计

工作包 2（WP2）重点针对适用于 Windows、Linux 和 macOS 的 NymVPN 桌面端应用程序展开评估。 测试团队对客户端前端组件（排查客户端潜在问题）以及 Rust 后端通信层均开展了全面深入的审查。 总体而言，桌面端应用程序展现出出色的安全实践规范。

主要的积极发现包括前端组件采用了 React 框架，这显著缩小了攻击面。 测试团队未识别出任何重大客户端漏洞；唯一的例外是一种极特殊的场景：在特定条件下点击恶意存储库 URL，可能触发任意 JavaScript 代码执行（XSS）。 该问题被归类为低风险级别，未识别出任何敏感数据泄露或严重漏洞。 针对后端系统，经全面评估其在 Linux（通过 Unix 套接字）及 Windows（通过管程文件）环境下与守护进程（Daemon）的通信机制，均未发现重大漏洞或安全隐患。

尽管评估中提出了若干优化建议，但相关发现均旨在进一步巩固安全防护，并非涉及任何关键漏洞。

工作包 3（WP3）：针对 Nym 后端 API 的水晶盒渗透测试与源代码审计

WP3 聚焦于 Nym 后端组件的 API（涵盖网关及混合节点），验证节点则排除在本次评估范围之外。 本次评估深入测试了系统的序列化与反序列化逻辑、SQL 注入风险、身份鉴权与权限控制机制、SSRF 漏洞、时序侧信道攻击以及高危代码执行接口。 值得肯定的是，Nym 后端表现出了中等偏上的安全水平，未发现直接的代码执行漏洞、SQL 注入风险或可被利用的高危 SSRF 问题。 本网络采用符合安全标准的身份鉴权与访问控制机制，切实降低了权限绕过的潜在隐患。 虽然后端架构总体具备良好的安全防护能力，但评估中仍指出了若干值得重点关注的隐患。 其中，有三项发现被归类为高危或严重级别（NYM-01-027、NYM-01-030 和 NYM-01-032），我们将在下文逐一说明。

NYM-01-027 工作包 3（WP3）：Nym 网关中 AES-CTR 模式的随机数-密钥重用漏洞（致命）

在对 Nym 代码库进行源代码审查期间，发现网关与客户端之间的通信存在严重的密码学缺陷。 具体而言，审查发现 Nym 网关与客户端在握手之后，后续通信的数据加密采用了 AES-CTR 模式，并使用了唯一的、不进行轮换的密钥以及固定的全零随机数（Nonce）。 这带来了极高的安全隐患：攻击者只要获取到任意一段明文，就能利用密文与已知明文进行简单的 XOR 异或比对，从而彻底破解后续的所有加密通信。

尽管只有在明文泄露的情况下，客户端与网关之间传输数据的保密性才会受到威胁，但我们充分意识到该问题的严重性。 Nym 团队迅速作出响应，采用推荐的 AES-GCM-SIV 方案替换了 AES-CTR 加密，并在 2024.12-aero 发行版中大幅提升了通信安全性。

NYM-01-030 工作包 3（WP3）：Nym 网关忽略凭证序列号检查漏洞（致命）

虽然网关层未校验凭证序列号，但这并不会构成为安全隐患。原因在于 zk-nyms 协议 采用了离线电子现金模型，其内在机制原生支持对二次套现/双重支付（Double-Spending）行为的精准识别与有效拦截。 在线电子现金（e-cash）方案中，服务提供方与中央机构（例如银行或区块链）保持实时连接，并在接受支付前即时核对序列号。 若将此模式引入 NymVPN，则意味着每当发生交易时，网关均需即时对凭证序列号进行主动核验。 反之，离线电子现金架构摆脱了对实时联网的依赖——服务商可先接纳支付并在后续统一结算，其底层的密码学保障机制能确保任何试图重复套现（双花）的行为均会在后续的交易核验环节被精准识别。 Zk-nyms 协议正是基于此离线电子现金模型构建。因此，即便网关未进行本地凭证序列号的校验，nym-API 验证节点在对通行凭证（tickets）进行终审核销时，依然能够准确检测并拦截任何双重套现（双花）行为。 由此可见，从系统整体安全性的角度来看，在网关侧强制实施序列号校验并非必要。 不过，若在网关侧引入本地校验，可作为一层补充性的前置防御手段，有助于在单一网关范围内更迅速地发现并拦截重复套现行为。 尽管这类校验能够提升处理效率，但它们并非该协议核心安全机制的必要组成部分。 Zk-nyms 协议内置的密码学机制保障，足以确保双重支付（双花）行为在后续的核验阶段被可靠识别，从而能够精准追溯并黑名单化任何恶意的攻击者。 因此，网关侧的双重支付（双花）校验应被视为一种可选的效率优化手段，而非核心的安全刚性需求。

此外，在我们的系统中，每个 zk-nym 凭证都设有固定的有效期限，目前设定为一周。 超过该期限后，过期的凭证将不再被网络的入口节点（Entry Nodes）所接受。 这种过期机制进一步削弱了任何潜在双重支付（双花）企图的影响力，从而确保即使在缺少网关侧序列号校验的情况下，整体系统依然能够稳如磐石。

NYM-01-032 工作包 3（WP3）：布隆过滤器参数设置不当引发误报漏洞（高危级别）

需指出的是，这部分代码当时正处于开发阶段，且在审计期间尚未在 NymVPN 应用中投入使用。 所提供的参数仅用于内部测试目的。 如前文针对 NYM-01-030 工作包 3（WP3）所作的阐述，引入布隆过滤器（Bloom filters）旨在为拦截双重支付（双花）行为提供一层额外的辅助校验。 然而，鉴于我们的协议在设计层面采用了不同的方式来处理双重支付（双花），且布隆过滤器会带来过高的资源开销（需要在网关与 nym-api 之间同步相关数据），我们最终决定将其彻底移除。

除上述高优先级问题外，本次审计还指出了多项中危级别的安全漏洞，这些漏洞主要与潜在拒绝服务（DoS）攻击向量相关。 这些审计结果进一步凸显了 NymVPN 后端在增强自身抗干扰能力、规避服务中断方面仍具提升空间。 我们计划将这些问题的修复工作纳入 2025 年的路线图中。

总体而言，API 及后端组件展现出了值得认可的安全性，漏洞主要局限于个别特定场景或仍有强化提升的空间。

工作包 4（WP4）：针对 Nym VPN 软件及基础设施的“水晶盒”（白盒）渗透测试与源代码审计

WP4 涵盖了对 NymVPN 软件的全方位安全性评估，重点关注以下几个方面：

• 核心功能：协议处理、加密技术、网络管理、DNS 解析，以及 IP 路由、隧道传输和整体网络协议栈集成的实现。
• 前端集成：对基于 Tauri 的用户界面进行了评估，涵盖设计、易用性，以及通过 FFI（外部函数接口）与 Rust 核心的高效集成；同时也评估了在 Windows、macOS 和 Linux 上的跨平台性能表现。
• 关键安全措施：凭据的安全存储、防止泄漏、密钥管理，以及对已知 VPN 漏洞的缓解与防范。

基于 Rust 实现的协议处理、加密技术、IP 路由、隧道传输以及网络协议栈集成被证实是可靠的，并且未发现任何漏洞。 凭据存储、防止泄漏以及加密密钥管理等关键安全特性被判定符合高安全标准，并能有效降低风险。

桌面端前端被认定成功兼顾了易用性与对 Rust 核心的高效集成。 错误处理和日志记录机制被认为是全面且经过精心设计的，能够提供有价值的排查信息，同时不会泄露任何敏感数据。

在 WP4 分析期间未发现任何漏洞，NymVPN 软件也被证实展示出了出色的安全姿态。

WP5：针对 Nym 密码学实现的“水晶盒”（白盒）渗透测试与源代码审计

WP5 重点专注于对 Nym 平台所采用的密码学进行全面彻底的评估。 这涵盖了核心组件，例如 Coconut 代码包、zk-nyms （匿名电子现金/ecash）代码包、Sphinx 协议、Outfox 协议以及其他常用的密码学原语。 所有密码学方案的源代码均完全由 Rust 编写，其出色的代码组织结构赢得了赞赏，使审计人员能够快速熟悉具体实现细节。

审计团队对 Coconut（椰子）协议与电子现金（ecash）协议进行了广泛审查，证实其有效地利用致盲机制（blinding mechanisms）保护了敏感信息，未发现任何无意的信息泄露。 协议中所使用的两种非交互式零知识证明（NIZKP）均未展现出任何可利用的漏洞，攻击者无法绕过或欺骗验证者。 此外，底层密码学库的选择（特别是 bls12_381）确保了严格的群成员资格检查，从而有效防止了利用无效曲线点或错误子群发起的攻击。 同时审计也证实，系统在生成加密密钥和一次性随机数（nonce）时，使用的是高强度的密码级安全随机源，确保了全平台密钥生成的绝对安全和可靠。

不过在看到这些亮点的同时，审计团队也指出了一些隐患，其中有几个问题被评估为高危甚至严重风险级别。 下文将对上述每个问题逐一进行详细阐述。

NYM-01-009 工作包 5（WP5）：Coconut 库中的 BLS12-381 椭圆曲线签名绕过漏洞（严重）

Cure53 注意到，用于在签发阶段验证部分致盲签名的 verify_partial_blind_signature 函数未对传入的签名实施所有必要的检查，这可能允许攻击者利用椭圆曲线上的无穷远点（infinity points）绕过签名验证。 不过需要补充说明的是，Coconut 协议中真正负责校验凭证使用的函数其实包含了完整的安全校验，可以稳定拦截并拒绝任何无效凭证。 因此，鉴于该协议的机制设计，任何攻击企图均无法得逞，因为伪造的凭证会在后续阶段被识别并拒绝。 这保障了整个系统在真实使用环境下，其安全性和可靠性完全不会受到影响。

话虽如此，我们承认，如果将这些函数应用于 Coconut 协议特定的上下文之外，Cure53 所建议的附加检查措施将有助于增强其健壮性。 鉴于我们的代码开源且旨在为更广泛的社区提供可复用的组件，我们已作为一项额外的预防措施，在 2024.13-magura 版本 中实现了针对无穷远点的推荐签名校验。 这确保了相关函数能够在其他应用场景中得到可靠使用，同时始终维持最高水平的安全标准。

NYM-01-014 工作包 5（WP5）：离线电子现金（eCash）中的部分签名绕过漏洞（严重）

该问题与上述缺陷类似，但适用于电子现金（e-cash）方案，而非 Coconut 协议。 与 Coconut 协议的实现过程类似，所有必要的检查均已在协议的支出阶段（spending phase）落实，从而确保任何尝试发起的攻击都无法成功。 这也就意味着在实际操作中，尽管该问题被列为致命（Critical）级别，但系统的安全性和完整性从未受到威胁。

尽管如此，与 Coconut 的处理方式类似，我们已经在 2024.13-magura 版本 的所有相关函数中，主动实施了 Cure53 所建议的附加签名检查。 尽管为了确保现有协议流程的安全性并不需要这些检查，但它们增强了代码的鲁棒性，并确保了这些函数可以在其他语境中被可靠地复用。 这种做法体现了我们对维持高标准安全性的承诺——不仅是对我们自身的系统，也是为了更广泛的开源社区。

NYM-01-033 WP5：Pointcheval-Sanders 方案的签名伪造漏洞（致命）

Cure53 在我们实现的 Pointcheval-Sanders 签名方案的签名函数中发现了一个漏洞。 具体而言，该漏洞源于在我们现有的实现中，签名元组 (h, s) 中的随机值 h 并未被随机选取。 因此，如果我们仅对公有属性进行签名，该签名将面临被伪造的风险。

然而，必须强调的是，在 Coconut 或电子现金（e-cash）协议的语境下，这种签名伪造漏洞并不会带来任何风险。 这两个协议在设计上都依赖于私有属性，因此在进行签名计算时使用的是盲发行（blind issuance）流程。 在盲发行协议中，将消息的承诺（commitment）作为哈希函数的输入，可确保不同的消息元组生成唯一的 h 值。 因此，只有在 Coconut 或电子现金（e-cash）协议仅结合公有属性使用的前提下，该漏洞才会显现——而在 Nym 网络中并非如此。 因此，鉴于当前使用的协议本身就规避了这一问题，Cure53 所指出的风险并不适用于我们的系统。

NYM-01-042 WP5：聚合逻辑错误导致无效离线电子现金（eCash）签名漏洞（致命）

该问题与 NYM-01-009 及 NYM-01-014 类似：如果攻击者能够操纵部分签名（partial signatures）并使其组合结果为无穷远点（infinity point），则独立的签名聚合函数可能会生成一个无效的签名。 然而，无论是在 Coconut 还是电子现金协议中，验证流程都会显式地拒绝任何结果为无穷远点的签名，因此该问题并不会危及任何一个协议的安全性或完整性。 尽管如此，为了与处理 NYM-01-009 和 NYM-01-014 问题的举措保持一致，我们已在聚合函数中实施了附加检查，以进一步巩固我们的代码库，并防止在其他语境下可能出现的任何潜在滥用(https://github.com/nymtech/nym/blob/nym-binaries-v2024.13-magura/CHANGELOG.md)。

NYM-01-005 WP5：缺少无穷远点检查导致 ElGamal 明文泄露（高危）

Coconut 和电子现金（e-cash）的当前实现中并未采用 ElGamal 加密算法（在审计期间也未曾使用）。 取而代之的是，我们采用了效率更高的 Pedersen 承诺（Pedersen commitments），该机制并不存在相同的安全风险。 因此，与 ElGamal 相关的漏洞不会对我们现有的系统造成任何安全风险。 我们同时也移除了 Coconut 模块（crate），因此也一并清除了 ElGamal 加密方案。

致谢

我们谨向 Cure53 团队在整个审计过程中展现出的专业素养与奉献精神表示感谢。 我们对贵方在本次审计的筹备规划与具体实施阶段所展现出的高度协同与卓越专业性表示由衷赞赏。 保障系统安全是我们贯穿始终的重中之重。展望未来，我们将继续深化与业内顶尖安全团队的合作，共同为生态系统的稳健发展夯实最高标准的安全防线。