Sebastien Rousseau
聯絡我 ›

後量子支付基礎建設:銀行為何可能替換而非改造傳統管道

ML-KEM 與 ML-DSA 無法乾淨地塞進承載 SWIFT MT 與 ISO 20022 的管道內。誠實的工程答案是:改造是有短保存期限的受控遷移計畫,替換才是唯一穩定的終點。

3 min read

後量子支付基礎建設:銀行為何可能替換而非改造傳統管道

今天在生產中對每一筆批發支付進行身分驗證的密碼原語——RSA、ECDSA、ECDH——都有到期日。美國 Quantum Computing Cybersecurity Preparedness Act ⧉ 在 2022 年底把這個到期日寫進聯邦採購法。BIS Working Paper No. 1208 ⧉ 把同一個到期日寫進中央銀行的監管框架。NIST FIPS 203 ⧉ 與 FIPS 204 ⧉ 在 2024 年 8 月公布了替代品。

支付基礎建設還沒消化這代表什麼。

本文是替換優於改造的工程論述。讀者鎖定已經理解演算法、需要決定如何處理 SWIFT MT、ISO 20022 pacs 與 pain 訊息、RTGS 介接、HSM 機群,以及所有這些之下的憑證階層的架構師。

執行摘要 / 關鍵要點

  • **現收割後解密 (HNDL) 是作業層面的威脅。**對手在 2026 年錄下加密支付流量,等具備密碼分析能力的量子電腦 (CRQC) 一出現就解開。被擷取的流量包含結算指令、受款人資料,以及具有長期敏感性的驗證素材。
  • **NIST 已經把替代品標準化。**金鑰封裝用 ML-KEM (FIPS 203),數位簽章用 ML-DSA (FIPS 204),這是預設。SLH-DSA (FIPS 205) 則覆蓋無狀態雜湊型備援。
  • **尺寸差距打破了傳統假設。**公鑰與簽章比 RSA-2048 大 5 到 20 倍。這會撞上支付網路的 MTU、MT 訊息處理器中的固定緩衝假設,以及在地 HSM 機群的密碼吞吐量。
  • **混合 (傳統 + PQC) 是遷移載具,不是終點。**混合 TLS 與混合 X.509 在替換生產管道期間,可以爭取兩到三年的互通性。它們無法解決底層的容量問題。
  • **PKI 是承重牆。**一旦憑證機構的簽章演算法可被偽造,其下所有憑證瞬間失效。銀行的制度性曝險是整條鏈,而不是任一個端點。
  • **密碼敏捷性是要工程化的架構屬性。**演算法識別碼、金鑰格式、簽章信封與 HSM 分區都必須可參數化。任何在編譯時就鎖死 RSA 的東西,都是會同時到期的技術債。

現收割後解密:讓「再等等」這個選項消失的威脅模型 #

HNDL 把一般的密碼學時間軸反轉過來。傳統風險評估問的是威脅何時實現。HNDL 問的是今天擷取的資料何時會對對手有用。對支付訊息——受款人身分、帳號、結構化匯款資料、制裁篩查酬載、行內結算指令——而言,敏感性的時間窗是以年甚至數十年計。其中絕大多數流量,現在某個地方就正在被錄下來。

NSA 的 CNSA 2.0 時程 ⧉ 給國家安全系統 2035 年之前完成轉換。金融監理機關走得更快——PRA 對營運韌性的要求 ⧉ 把密碼敏捷性視為第三方集中風險。2026 年的期待是:重要支付管道要把自己的 PQC 遷移計畫寫進韌性自證明文件。

HNDL 對手今天不需要 CRQC。對手需要的是:

  1. **網路位置。**海底電纜攔截、ISP 層級擷取、被攻陷的中間設備都在範圍內。批發支付流量集中在少數網路路徑上。
  2. **儲存。**在 2026 年,1 PB 結構化支付資料是可以管理的封存。
  3. **耐心。**每筆攔截到的訊息擷取成本是零。回報後到。

因此遷移論述不是「量子電腦可能 2035 年到」,而是「今晚以 RSA-2048 金鑰交換完成的任何 TLS 工作階段,只要其內部資料還具敏感性,就一直暴露在外。」

尺寸問題就是工程問題 #

關於 PQC 遷移的公開討論,通常聚焦在演算法選擇。更難的問題是維度層面的。

原語 公鑰 簽章 / 密文
RSA-2048 256 位元組 256 位元組 (簽章)
ECDSA P-256 64 位元組 64 位元組 (簽章)
ML-KEM-768 1,184 位元組 1,088 位元組 (密文)
ML-DSA-65 1,952 位元組 3,309 位元組 (簽章)
SLH-DSA-128f 32 位元組 17,088 位元組 (簽章)

這些數字直接對應到傳統支付基礎建設根本沒設計過的故障模式:

改造路徑是逐項處理這些限制——這裡加大緩衝、那裡換更快的 HSM、在中間設備加上分片容忍。這是六個月內站得住腳的橋段。它不是架構。

改造對替換:定義整個專案的決定 #

誠實的框架是:改造是有短保存期限的受控遷移計畫,替換才是唯一穩定的終點。要決定的是銀行先撥預算給哪一個,以及改造窗口要留多久才不會變成永久湊合方案。

改造意味著:

這些工作可以做完。它不解決底層問題:SWIFT MT 與許多 ISO 20022 實作把密碼信封編碼在會鎖死演算法的訊息格式裡。下一次演算法轉換——一定會有,當 ML-KEM 最終出現弱點或新標準取代它時——同樣的遷移會在同樣的管道上再跑一次。

替換意味著接受:密碼層不是訊息格式的屬性,而是訊息格式所呼叫的可分離信封服務的屬性。具體來說:

替換式設計能撐過下一次演算法變更,而不必再去動管道。

密碼敏捷架構,逐層拆解 #

PQC 遷移要看的基礎建設層,不是適合一般銀行敘事的「資料、控制、經濟」業務層。要看的層是密碼學的。

層 做什麼 PQC 問題 架構指令
HSM / 金鑰管理 在硬體隔離下產生、儲存與操作金鑰素材 在地 HSM 韌體是否支援 ML-KEM、ML-DSA,以及混合金鑰封裝 API?在同一硬體上,簽章吞吐量相對 ECDSA 的差距多少? 按演算法支援與每秒容量盤點每一個 HSM 分區。淘汰任何沒有韌體升級路徑、又鎖死 RSA 的設備。在生產切換前先建好專屬 PQC 分區。
PKI / 憑證機構 透過 X.509 憑證發行、撤銷與串接信任 CA 今天能否以 ML-DSA 簽章?是否有經過測試的根輪替與重發鏈程序?CRL 與 OCSP 回應器是否照 ML-DSA 簽章重量設計尺寸? 把 CA 堆疊當作承重牆來對待。現在就建立具備 PQC 能力的下級。根輪替時機要對齊存活期最長的憑證依賴,而不是對齊方便性。
傳輸 / 網路 在支付端點之間終結 TLS、IPsec 與 MACsec 負載平衡器、WAF 與中間設備路徑能否容忍超過傳統 MTU 的混合握手?工作階段恢復票證是否照 PQC 金鑰設計尺寸? 把 TLS 終結移到密碼敏捷邊界 (sidecar 或網格)。提高支付 VPN 的 MTU 政策。在刻意誘發分片的情況下測試整條路徑。
應用 / 訊息酬載 承載 SWIFT MT、ISO 20022 pacs / pain / camt 訊息及其密碼信封 管道的訊息處理器能否容忍 ML-DSA 尺寸的簽章信封?中介解析器是否能感知演算法,還是會因長度而截斷? 把信封與酬載分開。在服務邊界簽章,而不是在訊息格式處理器裡。把演算法識別碼當作資料對待,不要當成綱要的一部分。
稽核 / 證據 產生主管機關與客戶仰賴的密碼保管鏈 簽章演算法被棄用之後,歷史簽章紀錄仍可驗證嗎?是否有長期封存簽章計畫? 以雜湊型原語 (SLH-DSA) 對封存反簽章,讓保證能撐過任何單一演算法被攻破。把稽核鏈視為受監管的成品,而不是組建過程的副產品。

紀律在於:讓每一層的每一個演算法選擇都是組態值。把 RSA-2048 在任一層寫死的機構,當該演算法倒下時,會繼承一場協調好的同步退場事件。

對不同銀行類型的意涵 #

曝險樣貌因機構而異。指令也因此不同。

全球銀行 #

全球銀行擁有最大的在地 HSM 機群、最長的憑證鏈,以及對手方之間最複雜的網路路徑。主要風險不是演算法選擇,而是同時在數百個內部服務與數十家外部對手方之間更換演算法的協調成本。

指令是:把具備 PQC 能力的 CA、密碼敏捷的傳輸邊界,以及演算法可參數化的簽章服務,視為 2026 年的工作,在任何一條管道被改造之前完成。一旦框架到位,管道改造就會變成已知框架內的例行生產變更。沒有框架,每一次管道改造都會把同樣的架構決定再吵一次。

區域銀行 #

區域銀行的密碼學表面積較小,但專業人手按比例也更少。主要風險是 HSM 供應商在演算法支援上的綁定——尤其是供應商尚未承諾支援的演算法。

指令是:從 2026 年起,在每一份 HSM 合約續約裡寫入 PQC 支援——具體是 ML-KEM 與 ML-DSA,並附經過測試的韌體升級路徑。沒有這個條款的銀行,會被迫按供應商的時程,而非自己的時程,更換硬體。

金融科技與 PSP #

支付服務提供者與金融科技通常坐在銀行對手方與商家或終端使用者系統之間。它們的密碼曝險是兩側的 API 邊界。

指令是:在 2026 年的商務談判中,把面向銀行端的混合 TLS 介面——傳統加 ML-KEM——當作基本盤公布出來。已經能展示 PQC 互通能力的金融科技,會在整合循環中贏過尚未動手的金融科技。

企業財資長 #

財資長不直接營運密碼基礎建設,但他們在消費它——每一個銀行 API、每一次安全檔案傳輸、每一份簽章確認,都倚賴銀行的 PKI。

指令是:在 2026 年的每一份銀行 RFP 中加入三個問題——銀行今天在面向客戶的 TLS 中使用哪些 PQC 演算法、銀行對 ML-DSA 簽章支付確認的計畫為何,以及銀行打算如何在 RSA 被棄用後仍維持歷史簽章紀錄的可驗證性。回答不出來的銀行,正在揭露關於其底層工程準備度的訊號。

接下來會發生什麼 #

支付領域第一波 PQC 部署對終端使用者是看不見的。混合 TLS 出現在握手中、憑證鏈長度增加、HSM 簽章延遲悄悄上升幾毫秒,而管道照常運作。這是成功路徑。

看得見的故障會來自改造:某條管道無法在不截斷的情況下接受 ML-DSA 簽章信封、某家 CA 的 CRL 散布點被新的簽章重量塞爆、某個中間設備把混合握手分成順序錯亂的 ClientHello。這些故障會在整個 2027 年陸續落到生產上。

2026 年的架構決定是:撥預算建立讓改造變得無關緊要的替換基礎建設,還是撥預算搞一連串個別看起來更便宜、加總起來卻更長、更貴的管道專屬修補。選第一條路的銀行,在轉換期會跑得安靜很多。選第二條路的銀行,會花十年其餘時間向主管機關說明事故檢討。

PQC 不是穿著基礎建設外衣的密碼學問題。它是一個基礎建設問題,只是恰好由密碼學引發。

常見問答 #

有沒有強制這項工作的截止日期?

具強制力的監管期限因司法管轄區而異。美國 Quantum Computing Cybersecurity Preparedness Act ⧉ 約束聯邦系統。NSA CNSA 2.0 時程 ⧉ 把 2035 年定為國家安全系統目標。BIS Project Leap ⧉ 與 FSB 的工作計畫,正在把系統性支付基礎建設的時程往前拉。HNDL 意味著作業時鐘早在這些名目日期之前就開始跑了。

為什麼建議的金鑰封裝是 ML-KEM,而不是更快的方案?

ML-KEM (CRYSTALS-Kyber 的標準化版本) 在格密碼候選之中,密文與金鑰尺寸的組合最佳,實作成熟、側通道防護完備。NIST 將其公布為 FIPS 203 ⧉。確實有更快的候選,但要嘛尺寸更大,要嘛安全參數的信心區間更弱。

為什麼不全部用 SLH-DSA 取代 ML-DSA?

SLH-DSA (SPHINCS+ 的標準化版本) 是雜湊型,因此只仰賴雜湊函數安全性——這是現有最保守的假設。它的簽章比 ML-DSA 大 5 到 20 倍。這對封存反簽章是可接受的,但對於每則訊息都在乎尺寸的交易型簽章來說行不通。標準模式是生產簽章用 ML-DSA,封存保證用 SLH-DSA。

銀行能不能等到管道公布 PQC 規範?

等的銀行,會繼承管道所公布的遷移時間窗,而那比銀行自己的內部變更週期更短。等到 SWIFT、在地 RTGS 營運商,以及相關 CCP 各自公布 PQC 規範時,遷移窗口會落在十二到二十四個月之間。事先沒有把 CA、傳輸與 HSM 能力建好的銀行,沒有作業上的捷徑可以趕上。

如果只能先撥預算給一件最高槓桿的事,是什麼?

一個整合進現有 PKI、具備 PQC 能力的下級憑證機構——能在不打斷生產信任的情況下,發行雙演算法憑證 (RSA 加 ML-DSA)。這建立了輪替原語。其他一切——傳輸升級、HSM 分區規劃、訊息信封變更——都可以圍繞它排程。

參考資料 #

最近審閱 。

最近審閱 .