Spring Boot 中的后量子密码学：一个冲刺周期内即可交付的四种模式

背景 当美国国家标准与技术研究院（NIST）于 2024 年 8 月最终敲定 FIPS 203 " 和 FIPS 204 " 规范时，受监管行业中的大多数工程团队都开始提出同一个问题：“我们到底该从哪里入手？”显而易见，答案是“切换到PQC TLS”，但各云服务提供商仍在部署这项技术，目前大多数团队尚无法立即启用该技术。 与此同时，实际的风险——攻击者当前正在存储加密的服务间流量，以便在量子硬件技术成熟后对其进行解密——已经开始显现。 本文以一个基于 Spring Boot 构建的标准零售银行微服务平台为例。该平台包含一个交易服务，不仅会将支付指令发送至 Core Banking Service，还会将客户的个人身份信息（PII）和 KYC 数据存储在 PostgreSQL 中。 此外，该平台将把贷款协议、开户文件存档在 Amazon S3 中，并将 OAuth2 服务账户令牌集成到 SWIFT 和 ACH 连接器的监管报告管道中。对于中大型银行而言，这种拓扑结构是非常典型的。问题在于，“量子安全”对于上述各个组件而言究竟意味着什么。组件不同，答案不同。 本文使用一个名为 PqcStarterLib " 的 Spring Boot PQC 库——该库将 Bouncy Castle PQC 提供程序封装在三个自动配置的 Bean 中，针对上述拓扑结构探讨了四种具体的模式。 这些模式涵盖：银行内部服务之间的有效载荷加密；Jakarta Persistence 将数据写入数据库前对个人身份信息（PII）和客户尽职调查（KYC）进行字段级的加密；使用 Dilithium " 对贷款协议和审计记录进行长期文档签名；以及针对 Core Banking 和监管报告管道中服务账户的量子安全 OAuth2 令牌进行签名。每种模式都配有可运行的 Spring Boot 代码，并附有关于其无法直接投入生产环境的诚实说明。 零售银行是“先收割，后解密”（HNDL）策略中尤为诱人的目标，因为相关数据的保质期极长。今天被盗的客户社会安全号码（SSN），到了 2035 年依然有用。一份贷款协议，其 RSA 签名十年后便可能被伪造，这将构成无法追溯补救的法律责任。本文所描述的攻击模式正是围绕这一现实情况来设计的。 威胁浅析 RSA 和 ECDSA 之所以有效，是因为对经典计算机而言，大数因式分解和离散对数问题都是难以解决的难题。而运行 肖尔算法 "的量子计算机可以在多项式时间内解决这两个问题。目前，IBM、谷歌以及多家国家实验室都已经拥有可运行的量子处理器，尽管其中尚无任何一台达到破解 RSA-2048 所需的规模。大多数专家认为，这一临界点将在 2030 年至 2035 年之间出现。 最迫在眉睫的问题是 HNDL。目前，攻击者正在拦截并存储加密的 TLS 流量。建立 TLS 会话的 RSA 密钥交换过程会与密文一同被记录下来。一旦具备相应能力的量子计算机问世，攻击者便会回溯并对其进行解密。对于零售银行而言，受影响的范围包括在各服务之间流转的客户 KYC 数据、交易记录、银行间结算信息，以及任何需要长期保密的、通过网络传输的文件。 另一个不容拖延的方面是长期有效的签名文件。如果今天使用 RSA 签署了一份贷款协议，而该协议在 2036 年仍然需具备法律效力，那么你将面临一个事后无法解决的问题。根据监管管辖区的不同，银行会将贷款协议、开户合同及审计记录存档，保存七年到三十年不等。你无法对已存档的文件进行追溯性重新签名。 短期有效的数据风险较低。一个 15 分钟后过期的客户会话令牌，即使使用 RSA 签名密钥，通常问题也不大，因为在有人破解它之前，它就已经毫无价值了。但用于 Core Banking 系统集成、欺诈检测管道和 SWIFT 连接器的 OAuth2 服务账户令牌，其有效期往往长达数月，这样的情况就大不相同了。这些正是 HNDL 攻击的目标。 PqcStarterLib 向 Spring Boot 添加了什么 PqcStarterLib 基于 FIPS 203 和 FIPS 204 的 Bouncy Castle 实现构建。它提供了三个在启动时自动配置的 Spring Bean： PqcEncryptionService " 提供混合加密功能：首先使用 Kyber KEM 建立一次性共享密钥，随后采用 AES-256-GCM 对实际有效载荷进行加密。如果服务间消息正文或数据库字段需要保持机密性，请使用此服务。 PqcSignatureService " 通过 CRYSTALS-Dilithium 提供签名和验证功能。对于需要证明内容未被篡改的贷款协议、KYC 文件、审计记录、构建工件和 OAuth2 令牌，请使用此服务。 PqcKeyPairGenerator " 作为自动配置的 Spring Bean，用于生成 Kyber 和 Dilithium 密钥对。 集成仅需三行代码： @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 24 及以上版本， SunJCE " 提供程序现在已经分别通过 JEP 496 " 和 JEP 497 " 原生支持 ML-KEM 和 ML-DSA，不需要依赖任何外部库： // 仅支持 JDK 24+ 版本，不需要 Bouncy Castle 2 KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-KEM-768"); 3 KeyPair kyberPair = kpg.generateKeyPair(); 4 5 Signature signer = Signature.getInstance("ML-DSA-65"); 6 signer.initSign(dilithiumPrivateKey); 7 signer.update(message); 8 byte[] sig = signer.sign(); Bouncy Castle 提供了更灵活的参数设置，并且支持 JDK 11 和 JDK 17。原生提供程序没有任何依赖，也是 NIST 标准 Java 工具集当前的发展方向。如果一家银行原本就计划升级到 JDK 24，那么选择原生方案是值得的。 用例 1：服务间有效载荷加密 情况说明 交易服务通过 HTTP 将客户的支付指令发送至 Core Banking Service。虽然 TL