要点总结

• 如果您已在使用 JDK 24，则可以通过标准的 Java 加密扩展 (JCE) API 开始使用基于模块格的密钥封装机制 (ML-KEM) 和基于模块格的数字签名算法 (ML-DSA)，无需额外的库。您可能已经计划的 JDK 升级（JDK 24）也将使您的整个后量子密码 (PQC) 迁移过程畅通无阻。
• 目前有人正在存储您的 RSA 加密 TLS 会话，以便稍后解密，因此，您服务之间传输的任何客户社保号码、交易记录和客户身份验证 (KYC) 文件都已面临风险。等待云服务提供商推出 PQC TLS 并非有效的迁移方案。
• 使用 Kyber 密钥加密数据库字段并不难；难点在于确保该密钥不存在于 JVM 堆中，因为服务器重启或堆转储都会撤销数据库中所有加密行的加密。Key Management Services (KMS) 或 HashiCorp Vault 的集成必须在任何内容部署到生产环境之前完成。
• 核心银行、欺诈检测和监管报告管道使用的 OAuth2 令牌和服务帐户凭证通常会持续数月甚至数年，因此与生命周期较短的客户会话令牌相比，它们在 PQC 迁移中具有更高的优先级。
• PQC 迁移应该从保存时间最长的数据开始，而不是从你最熟悉的授权层开始，因为今天用 RSA 签署的贷款协议和 KYC 记录到 2035 年左右签名将变得可以伪造。因此，事后你无法重新签署已存档的文件。

背景

当美国国家标准与技术研究院（NIST）于 2024 年 8 月最终确定 FIPS 203（基于模块格的密钥封装机制标准，即 ML-KEM，源自 Kyber 算法）和 FIPS 204（基于模块格的数字签名算法标准，即 ML-DSA，源自 Dilithium 算法）规范时，受监管行业（如金融、医疗、政府机构）的大多数工程团队开始问同一个问题：“我们究竟该从哪里开始？” 显而易见的答案是“切换到 PQC TLS”，但这仍在云提供商（如 AWS、Azure、Google Cloud）的长期路线图中推广，且目前大多数团队还无法在生产环境中启用这一功能，因为主流云服务商的负载均衡器和 API 网关尚未完成对 PQC 密码套件的全面支持。

与此同时，真正的风险——“先采集后解密”（Harvest Now, Decrypt Later，简称 HNDL）攻击——已经悄然开始。攻击者现在就在存储你加密的服务间流量（包括通过 TLS 1.2/1.3 传输的敏感数据），以便在量子硬件发展成熟后对其进行解密。这种威胁不再是科幻小说中的情节，而是被国际网络安全机构（如 NSA、CISA）反复警告的现实风险。

现在，让我们考虑一个基于 Spring Boot 构建的标准零售银行微服务平台。该平台包含一个交易服务（Transaction Service），该服务将支付指令发布到核心银行服务（Core Banking Service），以及一个存储客户个人身份信息 (PII) 和 KYC 数据的 PostgreSQL 数据库。该平台还会将贷款协议、账户开立文件存档在亚马逊 S3（简单存储服务）中，并将 OAuth2 服务账户令牌接入 SWIFT（环球银行金融电信协会）和 ACH（自动清算所）连接器的监管报告管道。这种架构对于中大型银行来说非常典型。问题在于，对于这些组件而言，“量子安全”究竟意味着什么？答案因组件而异：传输中的数据需要加密，静态数据需要字段级保护，长期文档需要抗量子签名，而服务凭证需要防重放攻击。

本文使用名为 PqcStarterLib 的 Spring Boot PQC 库，通过四种具体的模式来介绍这种拓扑结构。该库将 Bouncy Castle PQC 提供程序封装在三个自动配置的 Spring bean 之后。这些模式涵盖了内部银行服务之间的有效载荷加密、Jakarta Persistence 写入数据库之前的 PII 和 KYC 字段级加密、使用 Dilithium 对贷款协议和审计记录进行长期文档签名，以及用于核心银行和监管流程中服务帐户的量子安全 OAuth2 令牌签名。每个模式都附带可运行的 Spring Boot 代码，并坦诚地说明了阻碍其直接部署到生产环境的原因。

零售银行之所以成为 HNDL 攻击的理想目标，是因为其数据保存期极长。今天被盗的客户社保号码（SSN）在 2035 年仍然有效（可能伴随客户终身）。贷款协议的 RSA 签名在十年后可能变得可以伪造，而这种法律责任无法追溯解决。本文中的攻击模式正是基于这一现实而设计的，旨在帮助安全架构师和开发人员在风险成为灾难前采取行动。

威胁的明示

RSA 和 ECDSA（椭圆曲线数字签名算法）之所以有效，是因为分解大整数和求解离散对数对于经典计算机来说都是计算上不可行的难题。然而，运行 Shor 算法的量子计算机可以在多项式时间内解决这两个问题，从而彻底瓦解当前公钥密码体系的根基。IBM、谷歌和一些国家实验室目前都拥有可用的量子处理器（如 IBM 的 Osprey 芯片拥有 433 量子比特），但还没有哪家公司的量子处理器能够达到破解 RSA-2048 所需的规模（估计需要数百万量子比特）。大多数专家认为，这一突破将在 2030 年至 2035 年之间到来，这就是所谓的 Y2Q 时刻（Quantum Apocalypse）。

刻不容缓的是 HNDL 攻击。攻击者目前正在拦截并存储加密的 TLS 流量。建立 TLS 会话的 RSA 密钥交换过程（如使用 RSA 进行密钥传输或 ECDHE 进行密钥协商）与密文一同被记录下来。一旦出现功能强大的量子计算机，他们就会回溯并解密这些数据。对于零售银行而言，受影响的范围包括客户 KYC 数据在不同服务之间流动、交易记录、银行间结算信息，以及任何需要长期保密的通过网络传输的文件。

另一项刻不容缓的是长期有效的已签署文件。如果今天用 RSA 签署的贷款协议需要在 2036 年才能生效（例如 30 年期抵押贷款），那么届时法律纠纷将无法通过密码学证据解决，因为事后就无法弥补了。银行会将贷款协议、开户合同和审计记录存档，具体保存期限根据监管管辖区的不同而有所差异，从 7 年（如美国的《公平信用报告法》）到 30 年不等。您无法追溯性地重新签署已存档的文件。

短期数据风险较低。例如，即使使用 RSA 签名密钥，15 分钟后过期的客户会话令牌也基本安全，因为在被破解之前它就毫无价值。但用于核心银行集成、欺诈检测管道和 SWIFT 连接器的 OAuth2 服务帐户令牌，其有效期长达数月（甚至数年），情况就截然不同了。这些正是 HNDL 攻击的主要目标，因为一旦解密，攻击者可以长期冒充合法服务进行欺诈交易。

PqcStarterLib 为 Spring Boot 添加了什么

PqcStarterLib 基于 Bouncy Castle 对 FIPS 203 和 FIPS 204 的实现（版本 1.78 及以上）。它公开了三个 Spring bean，这些 bean 会在启动时自动配置：

• PqcEncryptionService：该服务提供混合加密，首先使用 Kyber KEM（密钥封装机制）建立一次性共享密钥，然后使用 AES-256-GCM（Galois/Counter 模式）对实际有效载荷进行加密。此服务适用于任何需要保密的跨服务消息体或数据库字段。混合加密模式结合了量子抗性的密钥交换和经典高效的对称加密，是目前业界公认的标准做法。
• PqcSignatureService：提供基于 CRYSTALS-Dilithium 的签名和验证服务（在 FIPS 204 中标准为 ML-DSA）。此服务适用于贷款协议、KYC 文件、审计记录、构建工件和 OAuth2 令牌等需要证明内容未被篡改的场合。Dilithium 的安全强度基于模块格上的 SIS（短整数解） 和 LWE（容错学习） 问题的困难性，这些问题被认为对量子计算机具有抵抗力。
• PqcKeyPairGenerator：生成 Kyber 和 Dilithium 密钥对作为自动配置的 Spring bean，支持多种安全强度级别（如 Kyber-512、Kyber-768、Kyber-1024，对应 NIST 安全等级 1、3、5）。

集成曲面由三行代码构成（实际上只需注入服务 bean 即可使用）：

@Autowired PqcEncryptionService pqc;
@Autowired PqcSignatureService  pqcSig;
byte[] ciphertext = pqc.encrypt(data, recipientPublicKey).toBytes();
byte[] signature  = pqcSig.sign(document, myPrivateKey);
boolean ok        = pqcSig.verify(document, signature, myPublicKey);

关于依赖关系的说明

Bouncy Castle 的 bcprov-jdk18on 向下兼容 JDK 11，这涵盖了大多数 LTS（长期支持）周期的银行系统，包括 JDK 11、JDK 17。如果您使用的是 JDK 24 或更高版本，该提供程序现在已分别通过 JEP 496（量子抗性密钥封装机制 API）和 JEP 497（量子抗性数字签名 API）使 SunJCE 提供者原生支持 ML-KEM 和 ML-DSA。这意味着您无需引入任何外部库即可使用标准化的后量子算法。

// JDK 24+ only, no Bouncy Castle required
KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-KEM-768");
KeyPair kyberPair = kpg.generateKeyPair();
Signature signer = Signature.getInstance("ML-DSA-65");
signer.initSign(dilithiumPrivateKey);
signer.update(message);
byte[] sig = signer.sign();

Bouncy Castle 提供更灵活的参数设置，并兼容 JDK 11 和 JDK 17。其原生提供程序没有任何依赖项，并且是 NIST 标准 Java 工具集正在逐步采用的方向。如果您的银行计划在 2026 年内升级到 JDK 24，那么选择原生方案是值得的，因为这将减少外部依赖并提高性能。然而，对于大型遗留系统，Bouncy Castle 仍然是一个经过充分验证且稳定的选择。

用例 1：服务间有效载荷加密

情况

交易服务通过 HTTP 将客户支付指令发送到核心银行服务。TLS 可以保护传输过程，但无法抵御 HNDL 攻击。即使攻击者今天记录了 RSA 密钥交换过程，之后也可以使用量子计算机解密整个会话。在典型的银行基础设施中，TLS 连接也会在 API 网关（如 Kong、Spring Cloud Gateway）、服务网格（如 Istio）和内部负载均衡器处终止，因此交易服务和核心银行服务之间的实际微服务跳转通常在内部边界内都是未加密的明文传输。这为内部威胁和网络嗅探提供了可乘之机。

模式

在发送 HTTP 请求体之前，使用 Kyber + AES-256-GCM 对其进行加密，此过程独立于 TLS。核心银行服务接收到 PqcEncryptedPayload 记录（包含公钥封装的共享密钥和密文）后，使用其 Kyber 私钥对其进行解密。即使完全移除 TLS，支付指令仍然受到量子抗性保护。这种方式类似于 JWE（JSON Web Encryption）的加密思路，但使用的是后量子算法。

// Transaction Service: sender
@Autowired PqcEncryptionService pqc;
PaymentInstruction instruction = buildInstruction(transfer);
byte[] payload = objectMapper.writeValueAsBytes(instruction);
PqcEncryptedPayload encrypted = pqc.encrypt(
   payload,
   coreBankingPublicKey   // Kyber-768 public key
);
restTemplate.postForObject("/core-banking/process", encrypted, Void.class);
// Core Banking Service: receiver
@PostMapping("/core-banking/process")
public ResponseEntity process(@RequestBody PqcEncryptedPayload body) {
   byte[] plaintext = pqc.decrypt(body, coreBankingPrivateKey);
   PaymentInstruction instruction =
       objectMapper.readValue(plaintext, PaymentInstruction.class);
   // post to ledger...
   return ResponseEntity.ok().build();
}

这就是 NIST 在其迁移指南中描述的双层模式：TLS 应对传统攻击者，Kyber 应对量子攻击者。两者必须独立破解。您无需修改 TLS 设置、API 网关配置或服务网格，只需在业务代码的序列化层添加加密逻辑即可，实现成本相对可控。

专家建议与注意事项

• 性能影响：Kyber-768 公钥大约 1184 字节，私钥 2400 字节，密文 1088 字节。这个大小放在 HTTP 请求体（JSON/XML）中完全没问题，但建议不要放在 HTTP 请求头中（因为某些负载均衡器会限制头部大小）。Dilithium-3 签名大约 3300 字节，如果您要将其序列化为 JWT 声明或 ISO 20022 消息信封（金融行业标准报文格式），则需要考虑其大小是否会超出报文长度限制。
• 密钥轮换策略：建议为每个服务实例生成唯一的 Kyber 密钥对，并通过服务注册中心（如 Eureka、Consul）进行公钥分发。定期轮换密钥对（如每 30 天）可以降低密钥泄露风险。
• 混合加密的安全性：AES-256-GCM 的 nonce（一次性随机数）必须确保唯一性，建议使用 96 位随机数或计数器，防止 nonce 重用导致的认证密钥泄露。

用例 2：PII 和 KYC 字段级加密

情况

客户的社会安全号码 (SSN)、税务识别号码 (TIN)、出生日期、护照号码以及 KYC 文件信息（如地址证明、收入证明）通常存储在 PostgreSQL 或 Oracle 数据库中。这些数据在静态存储时可能采用 AES 加密（如 TDE，透明数据加密），但密钥通常存储在环境变量中，或在启动时从配置服务器获取。这导致通过 SQL 注入、备份配置错误或内部人员泄露数据库信息时，所有数据都会暴露。在零售银行业，即使仅泄露一次 SSN 信息，也构成违反 GDPR（欧盟通用数据保护条例）、CCPA（加州消费者隐私法案）、GLBA（格雷姆-里奇-比利雷法案）以及各州金融数据保护法的违规行为，罚款可能高达数千万美元。

模式

在通过 Jakarta Persistence（原 JPA）持久化实体之前，使用 PqcEncryptionService 类对每个敏感字段进行加密。该列存储的是 base64 编码的密文（包含 Kyber 封装的密钥和 AES-GCM 密文）。明文值用 @Transient 注解标记，并且永远不会写入数据库，只在内存中短暂存在用于业务逻辑处理。

// Save
public CustomerProfile saveProfile(CustomerDto dto) {
   CustomerProfile profile = new CustomerProfile();
   profile.setFullName(dto.getFullName());
   byte[] ssnCipher = pqc.encryptToBytes(
       dto.getSsn().getBytes(UTF_8),
       masterKeyPair.getPublic()
   );
   profile.setEncryptedSsn(
       Base64.getEncoder().encodeToString(ssnCipher)
   );
   return repo.save(profile);
}
// Retrieve
public String getSsn(Long customerId) {
   CustomerProfile p = repo.findById(customerId).orElseThrow();
   byte[] blob = Base64.getDecoder().decode(p.getEncryptedSsn());
   return new String(pqc.decrypt(blob, masterKeyPair.getPrivate()), UTF_8);
}

阻碍字段级加密投入生产的密钥管理问题

上述代码在开发环境中运行良好，但 masterKeyPair.getPrivate() 会将 Kyber 私钥存储在 JVM 堆中。在银行业务环境中，这种方法会引发三个问题，导致任何安全审计都无法通过：

1. 持久化问题：如果没有持久密钥库（如 Java KeyStore 或 PKCS#12 文件），服务器重启后所有加密的客户记录将永久无法读取，导致重大生产事故。
2. 堆转储泄露：从任何运行实例中生成的堆转储文件都会暴露数据库中每个社会保障号码和税务识别号的主私钥。JVM 堆转储是故障排查的常规操作，这构成了巨大的安全隐患。
3. 密钥轮换缺失：没有密钥轮换机制，而 GLBA、PCI-DSS（支付卡行业数据安全标准）和 SOC 2（服务组织控制 2 审计标准）都明确要求定期轮换加密密钥。

解决方案是将所有 Kyber 密钥操作路由到 AWS KMS（密钥管理服务）或 HashiCorp Vault。应用程序永远不会持有原始私钥，而是通过 REST API 或 gRPC 将密文发送到 KMS，由 KMS 在硬件安全模块（HSM）内完成解密并返回明文。每次解密都是一次可记录、可审计的 KMS 调用，并按计划进行密钥轮换。这种模式已广为人知，但它与加密本身是两个独立的工程流程，必须在任何加密字段投入生产环境之前完成部署。否则，你得到的只是一个可运行的概念验证（PoC），而不是一个可部署的生产系统。

未来趋势：按记录加密

未来趋势是每个数据库记录使用独立的 Kyber 密钥（由 KMS 派生），这样即使某个记录的密钥泄露，也不会波及其他记录。这种 每记录密钥（Per-Record Key） 模式已经在 AWS 的 DynamoDB 加密客户端等产品中得到应用，未来将更广泛地推广到关系型数据库中。

用例 3：贷款协议的文档签署和审计跟踪

情况

零售银行每天都要签署贷款协议、开户合同和监管审计记录。这些文件会被存档七到三十年（美国抵押贷款记录通常保留 10 年以上，欧洲部分国家要求 30 年）。今天与 RSA 签署的贷款协议，到 2035 年左右其签名可能就可以伪造。如果一家银行在 2034 年发现这一风险，它将无法追溯性地重新签署十年前的存档文件。根据欧盟的 DORA（数字运营韧性法案） 和美国的 OCC（货币监理署） 指南等框架，这既是一个法律风险，也是一个监管合规问题。

模式

所有长期有效的文档在创建时都应使用 Dilithium 进行签名（ML-DSA-44、-65、-87，对应不同的安全等级）。Dilithium 是一种基于格的算法，其安全假设不受 Shor 算法的影响。今天创建的签名在 2045 年仍然具有密码学上的有效性。建议采用 “先哈希后签名” 的模式：先对文档内容计算 SHA-384 哈希值，然后对哈希值进行 Dilithium 签名，这样可以处理大文件而无需将整个文件加载到内存。

@Entity
public class CustomerProfile {
   private String fullName;
   private String accountNumber;
   @Column(name = "ssn_encrypted")
   private String encryptedSsn;
   @Column(name = "tax_id_encrypted")
   private String encryptedTaxId;
   @Transient   // never persisted
   private String ssn;
   @Transient   // never persisted
   private String taxId;
}
// At document creation
public SignedDocument signLoanAgreement(
       byte[] agreementPdf,
       PrivateKey signerKey,
       String officerId) {
   byte[] signature = pqcSig.sign(agreementPdf, signerKey);
   return SignedDocument.builder()
       .document(agreementPdf)
       .signature(Base64.getEncoder().encodeToString(signature))
       .algorithm("DILITHIUM3")
       .signedAt(Instant.now())
       .signerId(officerId)
       .documentType("LOAN_AGREEMENT")
       .build();
}
// Verification: same code works in 2026, 2031, or 2045
public VerificationResult verify(SignedDocument doc) {
   byte[] sig = Base64.getDecoder().decode(doc.getSignature());
   PublicKey pub = keyRegistry.getPublicKey(doc.getSignerId());
   boolean valid = pqcSig.verify(doc.getDocument(), sig, pub);
   return VerificationResult.builder()
       .valid(valid)
       .signerId(doc.getSignerId())
       .signedAt(doc.getSignedAt())
       .quantumSafe(true)
       .build();
}

同样的模式也适用于 CI/CD（持续集成和持续交付）工件签名。部署到银行基础设施中的每个 JAR 文件都应由构建流水线（如 Jenkins、GitLab CI）使用 Dilithium 进行签名。部署门（Deployment Gate）会在执行任何 kubectl apply 或 terraform apply 命令之前验证签名。如果签名不匹配，部署将中止并返回错误 SecurityException。此解决方案可捕获工件注册表（如 Artifactory、Docker Hub）和生产环境之间的供应链注入攻击（如依赖混淆攻击、镜像篡改），而标准 TLS 无法检测到此类注入，因为它发生在注册表边界内部。

本文介绍的四种模式中，文档和工件签名是最接近生产就绪的模式。该模式不依赖于 KMS 的复杂部署（签名密钥只需存储在现有密钥基础设施中，如 PKI），而且其紧迫性（长期法律责任）足以获得法务和合规团队的批准，可作为 首批试点项目 快速推进。

注意：时间戳服务

为确保长期验证有效性，建议在签名时附加 RFC 3161 时间戳服务的响应，由可信第三方（如 DigiCert、GlobalSign）证明签名在文档创建时确实有效，防止事后伪造签名时间。

用例 4：用于核心银行服务的量子安全 OAuth2 令牌

在零售银行业务中，授权层比在典型的微服务架构中更需要优先考虑。原因如下：

有效期较短的客户会话令牌（RS256，15分钟过期）优先级确实很低。在任何人破解之前，这种令牌就已经毫无价值。但在银行业环境中，有两种令牌类型的情况则截然不同：用于核心银行系统集成、欺诈检测引擎、SWIFT网关连接器和ACH报告管道的 OAuth2 服务帐户令牌。这些令牌通常有效期长达数月甚至数年，并存储在 CI/CD 库和基础设施自动化工具（如 Ansible、Terraform）中。任何长期承载具有监管意义的声明（如交易权限、账户管理权限）的令牌都属于此类高风险令牌。

这些正是 HNDL 攻击所收集的令牌。例如，如果今天窃取并存储了您 SWIFT 连接器的服务帐户令牌，而该令牌要到 2031 年才能解密，那么攻击者未来就可以通过身份验证访问您的核心银行 API，并利用该令牌进行重放攻击（Replay Attack），窃取资金或伪造交易指令。

模式

将 RS256（RSA 签名）替换为 DILITHIUM3（即 ML-DSA-65）用于服务帐户令牌签名。JWT 结构相同，仅 alg 标头和签名调用有所不同。Spring Security 的 JwtDecoder 和 JwtEncoder 可以扩展以支持自定义签名算法。

// Auth Server: service account token issuance
public String issueServiceToken(ServiceAccount account) {
   String header = base64url(
       "{\"alg\":\"DILITHIUM3\",\"typ\":\"JWT\"}"
   );
   String payload = base64url(String.format(
       "{\"sub\":\"%s\",\"scope\":\"%s\",\"iat\":%d,\"exp\":%d}",
       account.getClientId(),
       account.getScopes(),
       now(),
       now() + 86400
   ));
   String signingInput = header + "." + payload;
   byte[] sig = pqcSig.sign(
       signingInput.getBytes(UTF_8),
       authServerPrivateKey
   );
   return signingInput + "." + base64url(sig);
}
// API Gateway: token validation
public Claims validateServiceToken(String jwt) {
   String[] parts = jwt.split("\\.");
   String signingInput = parts[0] + "." + parts[1];
   byte[] signature = base64urlDecode(parts[2]);
   boolean valid = pqcSig.verify(
       signingInput.getBytes(UTF_8),
       signature,
       authServerPublicKey
   );
   if (!valid) throw new InvalidTokenException(
       "Dilithium token verification failed"
   );
   return parsePayload(parts[1]);
}

需要计划些什么

• 负载大小限制：Dilithium-3 签名的大小约为 3300 字节，而 RS256 签名仅为 256 字节。包含 Dilithium-3 签名的 JWT 体积明显更大（可能达到 4-5 KB）。如果您的 API 网关（如 Kong、AWS API Gateway）强制执行请求大小限制（如 8KB），或者您的 SWIFT 连接器对消息信封大小有严格要求（如 MT/MX 报文限制），请在部署此修复程序之前仔细检查并调整这些限制。
• Spring Security 集成：开源生态系统中 OAuth2 流程的完整 Spring Security 集成仍在进行中（Spring Security 6.4+ 开始提供初步支持）。因此请将此用例视为近期计划的工作，而不是您可以立即发布的功能。可以考虑贡献代码或与 Spring 社区合作推进标准化。
• 性能基准测试：Dilithium 签名验证速度比 RSA 慢约 2-3 倍，建议在生产部署前进行充分的性能基准测试，确保不会影响核心银行交易的响应时间（通常要求 < 200ms）。

如何安排工作顺序

大多数团队不应该试图一次性完成所有这些工作。在银行业背景下，图 1 描述了风险排序，建议按照 数据有效期 和 法律影响 双维度进行优先级划分：

图 1. Spring Boot 微服务的风险优先级 PQC 迁移顺序。（来源：作者创建）

立即做出以下更改（0-3 个月）：

1. 部署密钥管理系统：请部署 AWS KMS 或 HashiCorp Vault 来进行 Kyber 密钥管理。否则，任何方案都无法保证生产环境的安全。这是所有其他 PQC 方案的基础设施前提。
2. 关键流有效载荷加密：对承载最敏感数据的两到三个服务间流添加 Kyber + AES-256-GCM 有效载荷加密：任何涉及客户 PII、KYC 记录或支付指令的数据。可以先从非核心的批处理流程开始试点，逐步推广到实时交易。
3. 长期文档签名切换：将贷款协议和监管文件的签署流程切换至 Dilithium。此项变更时间紧迫，因为已存档的文件无法追溯修改，且无需事先部署 KMS（签名密钥可通过现有 PKI 管理），可作为 零日项目 快速启动。

在接下来的六到十八个月内做出以下改变：

4. 全网格加密：在其余内部服务网格中滚动有效载荷加密，逐步覆盖所有符合 HNDL 风险的数据流。
5. 字段级加密增强：Jakarta Persistence/Hibernate ORM 字段加密辅助函数，支持从 KMS 派生每个记录的密钥，实现按记录级别的细粒度加密和审计。
6. CI/CD 签名：Dilithium 签名用于跨内部银行基础设施的 CI/CD 工件，防止供应链攻击，保护从源代码到生产环境的完整性。
7. PQC TLS 就绪：一旦 JEP 527（在即将发布的 JDK 27 中提供 TLS 1.3 对 PQC 密码套件的支持）得到应用，并且您的云提供商（如 AWS、Azure、GCP）支持新的密码套件，TLS 1.3 中的 PQC（如混合密钥交换 X25519+Kyber）即可使用。届时可以减少应用层加密的负担。

长期规划（18 个月以上）：

8. OAuth2 令牌签名：密钥管理稳定后，为服务帐户添加 Spring Security 集成，以实现 Dilithium OAuth2 令牌签名。接下来，为核心银行和监管管道端点在 API 网关层添加 PQC 感知令牌验证。
9. 全栈审计与合规：建立完整的 PQC 迁移审计框架，确保所有加密、签名、密钥管理操作均可追溯，满足未来的合规审查要求。

需要避免的常见陷阱

• 起点错误：将有效期短暂的客户会话令牌作为起点，因为它们是最常见的授权模式，但也是风险最低的。应该从有效期最长、监管风险最大的方案入手（如文档签名和字段加密）。
• 依赖外部供应商：不要单纯等待云服务商推出 PQC TLS 而无所作为，内部服务间的加密和签名迁移可以立即开始。
• 忽略密钥管理：将加密逻辑与密钥管理视为一体，导致 PoC 无法上生产。密钥管理必须作为独立轨道并行推进。

概括

零售银行 Spring Boot 应用集群的 PQC 迁移不必一次性完成。NIST 标准已最终定稿，JDK 24 已原生支持，而 Bouncy Castle 也适用于仍在使用 JDK 11 或 JDK 17 的团队。目前最紧迫的工作，例如内部服务流量的有效载荷加密、长期文档的 Dilithium 签名以及 PII 的字段级加密，都可以通过库集成和集中精力进行迭代开发来实现。

难点不在于加密技术本身，而在于底层的密钥管理。如果没有 KMS 或 HashiCorp Vault 等安全解决方案，字段级加密只能算是一个可行的概念验证，无法通过银行安全审查。必须先打好基础，其他部分才能逐步完善。量子时代已经来临，与其被动应对，不如主动布局——从今天开始，从保存时间最长的数据开始，逐步构建抗量子攻击的坚固防线。

下一步行动建议：
1. 评估当前系统中数据保存期限超过 5 年的业务场景，列出高风险清单。
2. 选择 1-2 个低风险试点项目（如文档签名或批处理数据加密），快速验证技术方案。
3. 同步启动密钥管理基础设施（KMS/Vault）的部署，为后续大规模迁移铺平道路。
4. 关注 JDK 版本升级计划，将 JDK 24+ 纳入技术路线图，以利用原生 PQC 支持。