网络运营者长期面临加密流量与策略执行的矛盾：TLS 1.3 等加密协议阻断了传统中间箱对明文的检查，导致恶意软件扫描、域名过滤等基于 DNS 的策略失效。USENIX Security 2022 论文提出零知识中间件（ZKMB），利用 zk-SNARK 让客户端在加密前自行扫描流量，并生成零知识证明向中间箱证明“扫描过程符合策略”且“流量合规”，无需解密、无需可信硬件、不改动现有协议，实现了加密与合规的共存。
核心机制：客户端自扫描与零知识证明
传统中间箱依赖全流量明文可见性，加密使其失效。ZKMB 将扫描逻辑下沉到客户端：客户端在加密前按运营者指定的策略（如域名黑名单）检查自身流量，随后用 zk-SNARK 生成证明，向中间箱证明两点——执行的扫描代码与运营者预期一致，扫描结果为“通过”。中间箱仅验证证明，无法看到查询内容。证明系统基于通用电路，策略变更只需更新电路与验证密钥，不改动客户端二进制。论文原型在 DNS 过滤场景下，客户端证明生成耗时原文未给出具体数据，验证端延迟原文未给出具体数据，证明大小原文未给出具体数据。
DNS 过滤案例与性能现状
以 DNS 查询过滤为例：客户端在发起 DoH/DoT 请求前，在本地对域名运行黑名单匹配，生成证明随加密流量一同通过中间箱。中间箱验证证明通过即放行，否则丢弃。实验显示，该方案在不修改 TLS 1.3、不引入可信执行环境（TEE）的前提下完成了端到端演示。但论文明确指出 ZKMB 尚未完全实用：证明生成的计算开销、客户端资源占用、电路更新分发机制仍需优化，作者对近期 zk-SNARK 算法与硬件加速的进展持乐观态度。
协议兼容性与部署取舍
ZKMB 的关键取舍在于：保持与 TLS 1.3、QUIC 等标准协议完全兼容，避免中间箱部署门槛；以客户端计算换取运营侧零明文可见性，适配企业网、ISP 等受管网络。代价是客户端必须运行证明生成代码，要求操作系统或浏览器集成，且策略变更需协调客户端更新电路。若策略极其复杂（如深度包检测），电路规模可能超出当前 zk-SNARK 承受范围。论文未给出大规模部署的带宽、CPU 量化基准，原文未给出具体数据。
对运维与网络工程师的意义：ZKMB 提供了一条“无解密、改协议、用可信硬件”即可在加密流量上落地合规策略的技术路线。当前可在实验环境验证 DNS 过滤等轻量策略，关注 zk-SNARK 库（如 libsnark、arkworks）与硬件加速（GPU/FPGA）的进展，评估客户端侧证明生成延迟对业务的影响，为未来零信任网络架构预留零知识合规接口。
原文: APNIC Blog（2022-07-08）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog