七周后:新西兰关键基础设施后量子密码学——2026年6月进展更新

2026年6月2日,我们对同一批118家新西兰关键基础设施实体重新运行了后量子密码学(PQC)就绪性扫描器,此前我们于2026年4月14日完成了首次评估。七周对于密码学迁移而言是一个较短的时间间隔——总体数字也印证了这一点:整体PQC率从52.6%微降至52.2%,基本持平。

但深层数字发生了显著变化。源站侧PQC——即机构本身不经过CDN、直接协商X25519MLKEM768的端点——几乎翻番,从13家增至25家。原因并非大批机构主动启用后量子TLS,而是CDN基础设施的变化:Imperva不再出现于4月时由其代理的13家实体前端。其中11家(医疗卫生领域实体)的源站服务器此前已在运行后量子TLS。另有一家(KiwiRail)的源站尚未支持——CDN层消失后,其后量子防护也随之丧失。

6月扫描的主要发现:

  • 115次成功扫描中有60次(52.2%)协商了X25519MLKEM768——与4月持平。
  • 源站侧PQC:13家→25家——但主要原因是CDN层变化,而非新增启用。
  • Southern Cross Cables(国际海底电缆运营商)是唯一真正的新增启用:4月未经CDN代理,6月同样未经CDN代理,现已在源站协商X25519MLKEM768
  • KiwiRail失去了后量子防护。4月时其PQC仅通过Imperva CDN提供。Imperva已撤离;源站现协商经典X25519。
  • 医疗卫生领域:源站侧PQC从0家增至11家——揭示出新西兰公立医院网络的源站服务器具备真实的PQC能力,此前被CDN层掩盖。
  • Fastly仍为0%。位于Fastly后方的4家新西兰关键基础设施实体在边缘节点依然没有后量子TLS——与4月相比毫无变化。
  • 新增错误:Taranaki Base Hospital现在返回SNI不匹配错误。Wellington Electricity和Dunedin Hospital的错误自4月起持续存在。

为何再次扫描

后量子密码学的采用并非一次性过渡事件,而是随TLS库版本推出、CDN配置更新、合同变更以及(偶尔)机构主动启用而持续演变的基础设施状态。一次性快照回答的是”当前状态如何”。而周期性扫描则回答更有价值的问题:”实际发生了哪些变化,原因是什么?”

数据概览

图1 — 4月与6月对比:变化情况
指标2026年4月2026年6月变化
目标数量118118
成功扫描116115−1
错误数23+1
TLS 1.3107 (92.2%)106 (92.2%)持平
PQC已协商61 (52.6%)60 (52.2%)−1
位于CDN后方54 (46.6%)41 (35.7%)−13
通过CDN的PQC4835−13
通过源站的PQC13 (11.2%)25 (21.7%)+12
无PQC,CDN代理660
无PQC,直连源站49490

该表格的结构已基本呈现了全貌。PQC总量几乎不变。CDN数量减少13家。源站PQC增加12家(另有一家实体Taranaki Base Hospital现在返回错误而非有效结果)。4月时通过Imperva代理、6月状态发生变化的实体,均来自医疗卫生领域或为KiwiRail。Cloudflare、AWS CloudFront和Fastly的数量均无变化。

真正发生了什么:Imperva的变局

图5 – Imperva CDN变动及KiwiRail的教训

4月时,Imperva和Imperva/Incapsula出现于17家新西兰关键基础设施实体的前端。其中16家属于医疗卫生领域,通过Health NZ / Te Whatu Ora的集中式WAF接入。1家(KiwiRail)属于交通运输领域。全部17家均协商了PQC——Imperva已默认启用PQC一段时间,因此这是边缘节点交付,而非源站交付。

6月时,Imperva/Incapsula仅出现于4家实体前端:国防部、NCSC、基督城市议会(供水)和NZTA。其余13家已不再显示Imperva标头。

我们不知道原因。我们观察到的是结果:12家医疗卫生实体和KiwiRail不再位于Imperva边缘后方,其源站服务器现已直接暴露于我们的扫描器。

医疗卫生领域:隐藏能力得以显现

在上述12家医疗卫生实体中,有11家的源站服务器协商了X25519MLKEM768。Health NZ / Te Whatu Ora、Waikato Hospital、Tauranga Hospital、Wellington Regional Hospital、Christchurch Hospital、Palmerston North Hospital、Hutt Hospital、Nelson Hospital、Hawke’s Bay Hospital、Rotorua Hospital和Southland Hospital,均已出现在源站PQC荣誉榜上。

这是一项有意义的积极发现。新西兰公立医院网络在其源站基础设施上似乎原生运行后量子TLS——这一能力在4月时已存在,但由于所有扫描流量均在Imperva WAF处终止,我们无法观察到。

需要注意的是:这些医院进入荣誉榜,并非因为它们在4月至6月间作出了新的密码学决策,而是因为其前端层发生了变化,揭示了一个已然存在的状态。这一底层变化的性质——失去CDN保护是否引入了其他风险——是一个我们无法通过TLS握手扫描来回答的独立问题。

三家医疗卫生实体(Auckland City Hospital、Middlemore Hospital、North Shore Hospital)在6月未检测到CDN,也无源站PQC。这与4月时三家均无PQC的状况相同。

另有一家——Taranaki Base Hospital——现在返回TLS错误(UnrecognisedName,即SNI不匹配)。这是一个配置问题,而非政策决定,无论后量子状态如何,都应予以修复。

KiwiRail:CDN依赖风险的现实案例

KiwiRail在4月拥有后量子TLS,那是因为Imperva提供了它。如今Imperva已不再被检测到,源站协商的是经典X25519。

这是CDN依赖风险的具体体现:如果您的后量子TLS完全依赖于某份CDN合同,那么您的后量子TLS就与该CDN合同一样脆弱。这家具有全国重要意义的铁路与渡轮运营商,其对外公开端点如今正运行经典密钥交换。

解决方案很直接——X25519MLKEM768受所有主流TLS库支持,包括OpenSSL(3.x)、Go、BoringSSL和Rust的rustls栈。启用它通常只是一次配置变更,而非重新构建。但您必须在CDN撤离之前完成,而不是之后。

各行业对比:6月与4月

图2 – 2026年6月各行业PQC状况
行业已扫描PQC总计通过CDN的PQC源站PQC4月源站PQC变化
通信与数据1810 (55.6%)821+1
国防65 (83.3%)2330
饮用水与污水处理93 (33.3%)3000
能源3014 (46.7%)9550
金融147 (50.0%)3440
医疗卫生1611 (68.8%)0110+11
交通运输2510 (40.0%)10000

国防——无变化,仍领先。GCSB、NZSIS和DIA继续在源站运行X25519MLKEM768,这一状况没有改变,我们也不预期会有变化。

金融——无变化。ANZ、SBS Bank、The Co-operative Bank和Vero Insurance仍是金融领域的源站PQC成员。BNZ、ASB、Westpac、Kiwibank和NZX的经典加密姿态未变。Reserve Bank和Payments NZ通过CDN(Cloudflare)提供PQC。

能源——无变化。Meridian、Firstgas、Manawa、Pioneer和Marlborough Lines保持源站PQC。主要电网运营商(Transpower、Vector、Mercury、Genesis)仍无源站PQC。

通信与数据:+1。Southern Cross Cables——负责运营SCCN和NEXT海底电缆系统、为新西兰提供主要国际互联网连接的运营商——现已在其源站协商X25519MLKEM768。4月时其源站为经典加密,6月已升级为源站PQC。这是本次扫描中我们可以确信在两次测量节点之间真正启用了后量子TLS的唯一实体。Southern Cross与Tuatahi First Fibre并列成为通信与数据领域的两大源站英雄。

医疗卫生:+11(CDN变化,非新增启用)。如上所述。这一数字变化是真实的——11家公立医院现在可见为源站PQC——但这是基础设施变化的结果,而非主动迁移的体现。

交通运输:−1(KiwiRail失去PQC)。交通运输领域PQC净减从11家降至10家,全因KiwiRail的失去。无任何交通运输实体拥有源站侧PQC。Air New Zealand、Auckland Transport、Wellington Airport、Cook Strait各港口及大部分港口网络,仍运行经典TLS。

饮用水与污水处理:无变化。源站PQC仍为0。Auckland(Watercare)、Tauranga和Christchurch拥有CDN交付的PQC,其余六家则毫无保护。水务事业机构在自托管密码学姿态方面仍是最薄弱的行业。

6月CDN概况

图3 – 各CDN提供商PQC覆盖率,4月与6月对比
CDN提供商代理实体数PQC覆盖率与4月对比
Cloudflare292897%无变化
AWS CloudFront4375%无变化
Imperva(含Incapsula)44100%原为17家
Fastly400%无变化

Cloudflare和AWS:稳定。Imperva:17家→4家。Fastly:依旧为零。

关于Fastly:截至2026年6月,Napier Port、Hawke’s Bay Airport、RNZ和NZ Defence Force均位于Fastly后方,边缘节点没有任何后量子TLS。Fastly已公开声明有意启用PQC,但截至本次扫描尚未默认开启。这四家机构需要与Fastly就其时间表以及当前是否可选择加入进行专项沟通。

更新后的源站荣誉榜:25家实体

图4 – 25家源站PQC实体

自4月延续(13家):GCSB、NZSIS、DIA——Meridian Energy、Firstgas、Manawa Energy、Pioneer Energy、Marlborough Lines——ANZ New Zealand、SBS Bank、The Co-operative Bank、Vero Insurance——Tuatahi First Fibre。

6月新增(12家):

  • Southern Cross Cables(通信与数据)——真正的新增启用。
  • Health NZ / Te Whatu Ora、Waikato Hospital、Tauranga Hospital、Wellington Regional Hospital、Christchurch Hospital、Palmerston North Hospital、Hutt Hospital、Nelson Hospital、Hawke’s Bay Hospital、Rotorua Hospital、Southland Hospital——因CDN变化而显现的源站PQC。

我们在荣誉榜中区分这两个类别,因为变化的来源至关重要。Southern Cross Cables作出了密码学决策。医疗卫生实体的源站配置在4月时已存在,我们现在只是得以观察到而已。两者均属积极信号,但只有前者是新部署活动的证据。

未发生变化的事项

4月时我们指出的一些情况值得再次强调,因为七周后它们依然如故。

49个经典加密源站仍是经典加密。没有CDN到来,没有启用。Air New Zealand、KiwiRail(现已失去边缘PQC)、Auckland交通网络、Wellington Airport、除三家由Cloudflare代理之外的所有海港——4月时为经典加密源站的实体,6月仍是经典加密,距2029年的截止日期又少了一周的准备时间。

金融业四大行的分化格局未变。ANZ运行源站PQC,ASB、BNZ、Westpac和Kiwibank则否。对于依法需要保留客户金融记录的机构而言,这是一个不容忽视的差距。

无新的TLS 1.2退出。4月时有九个端点仅支持TLS 1.2,6月仍是九个。这些端点无论如何配置都无法协商X25519MLKEM768——TLS 1.3是前提条件。TLS 1.2的弃用是启用PQC的先决步骤。

NZISM第2.4节义务仍缺乏公开执行机制。DPMC征询意见期已于4月19日结束。我们尚未获悉最终框架是否会增加明确的密码学清单或PQC迁移要求。缺乏外部问责机制,是那49家经典加密源站实体没有特定期限压力的原因之一。

关于方法论及本次扫描的局限性

本次扫描仅测量一件事:可公开访问的TLS端点是否会与现代客户端协商X25519MLKEM768。它不测量:

  • 内部东西向流量(VPN、数据库复制、服务网格、SSH、电子邮件)
  • 证书签名算法——公共PKI上的ML-DSA采用是独立的、更靠后的迁移阶段
  • CDN到源站后端链路的PQC
  • 密钥管理质量或HSM安全态势
  • 未检测到Imperva是否真实反映CDN已撤离、Imperva响应头发生变化致我们的指纹识别失效,抑或其他原因

CDN检测的局限性在本次更新中值得明确说明。我们的指纹识别基于HTTP响应头。部分我们现在归类为”非CDN源站”的实体,可能仍由Imperva代理,只是Imperva的响应头发生了变化,导致我们的检测器无法识别。在这种情况下,看似”源站PQC”的实际上仍是”CDN PQC”。我们无法从TLS握手中判断CDN是否对响应头进行了标准化处理。如果您是上述医疗卫生实体之一,且您的Imperva合同未变,请告知我们。

CDN依赖的教训

KiwiRail的案例是一种更广泛模式的有益说明。那些拥有CDN交付PQC并认为后量子TLS已”大功告成”的机构,实际上在押注一个需要同时满足两个条件的赌注:

  1. CDN合同持续有效。
  2. CDN继续默认启用PQC。

条件2在Cloudflare和Imperva上表现良好,且没有改变迹象。条件1是商业决策,而非安全决策。

更持久的做法是CDN交付PQC源站PQC并存——如此一来,CDN的变动只是CDN的变动,而非安全退步。对大多数Web基础设施而言,在源站启用X25519MLKEM768并非大型项目:升级到最新TLS库,配置密钥共享组,部署即可。这是一个下午的配置工作,而非一个项目计划。对于目前仅有CDN侧PQC的每家机构而言,这都应列入待办事项。

2026年下半年的形势展望

另一侧的里程碑压力来自Google的2029年迁移目标,Cloudflare在2026年3月同日宣布了与其一致的目标。”2029年”在2026年6月听来似乎遥远,但实际上只有三年半。对于一个需要盘点密码系统、评估哪些面暴露于HNDL相关数据、跨多个环境更新库、让供应商认证新版本、测试并部署的机构而言,三年半并不宽裕。

源站荣誉榜上的机构至少已解决了一个可见面。本次扫描中49家经典加密源站实体连最简单的那个都尚未着手。

量子硬件侧的时间线在4月至6月间并未放缓。Google的2029年承诺基于他们对Gidney 2025年论文(百万量子比特以下的RSA分解)的解读以及其内部量子项目的进展。过去七周内没有任何事件使这一判断变得不那么可信。

我们将继续定期运行此扫描器并在开放仓库中公布结果。如果您已作出变更并希望我们知晓——无论是因为您已启用后量子TLS希望留存记录,还是因为您认为我们的扫描对您的CDN归属有误——请通过simon [at] spinsphere.xyz联系我们。


6月扫描错误

实体行业错误与4月对比
Wellington Electricity能源HandshakeFailure持续存在
Dunedin Hospital医疗卫生Timeout持续存在
Taranaki Base Hospital医疗卫生UnrecognisedName(SNI不匹配)新增

Wellington Electricity和Dunedin Hospital自2026年3月首次扫描起便持续报错。Taranaki Base Hospital是新增错误——UnrecognisedName告警意味着服务器拒绝了TLS握手,因为SNI扩展中的主机名与其持有的任何证书均不匹配。这通常是TLS配置或DNS路由问题,而非刻意拒绝。Taranaki Base Hospital应独立于任何PQC讨论,单独审查其TLS配置。

数据与方法论

所有代码、目标列表和扫描结果均为开源且公开可访问:

扫描器方法论:针对每个目标,向host:443发起TLS 1.3握手,提供包含X25519MLKEM768在内的密钥共享组,记录协商的密钥组和TLS版本。CDN检测通过HTTP响应头指纹识别完成。pqc_supported: true意味着服务器协商了X25519MLKEM768。实体结果仅在行业汇总层级公布;单个实体仅在源站PQC为正时具名列出。


Kaysec是Spinsphere(新西兰量子技术公司)旗下的后量子安全业务部门。我们运行此扫描器,以维护新西兰关键基础设施PQC态势的公开、持续基准线。如果您的机构持有长期保存的敏感数据且尚无密码系统清单,欢迎与我们联系。

订阅:kaysec.spinsphere.xyz  ·  源码:github.com/spinsphere/nzism-pqc-audit