Meta 後量子密碼學遷移框架：ML-KEM768、HQC 備援、六階段成熟度模型
Engineering at Meta · 2026-04-16
Meta 發表大規模後量子密碼學（PQC）遷移框架，記錄從制定策略到開始部署的完整過程，涵蓋演算法選擇、六步驟執行框架，以及五階段成熟度模型。
演算法選擇
Meta 優先採用 NIST 標準化演算法：金鑰封裝使用 ML-KEM768（CRYSTALS-Kyber，NIST Security Level 3）；數位簽章使用 ML-DSA65（CRYSTALS-Dilithium）。備援多樣性方面，Meta 選擇 HQC 作為備援——HQC 是 NIST 近期新增的標準候選，基於糾錯碼而非格密碼學，可對沖格密碼學被攻破的系統性風險。Meta 密碼學家共同撰寫了 HQC 規範，顯示其在標準制定層面的深度參與。
六步驟遷移框架
- 優先級定義：以量子威脅緊迫性分類應用程式（即時通訊 > 短期資料 > 長期存儲資料）。
- 密碼學清單：透過自動探索工具與開發者申報，建立全公司密碼學使用的完整地圖。
- 解決外部依賴：等待並參與 NIST 標準發布、硬體 TEE 廠商支援、第三方 SDK 更新。
- 設計 PQC 安全元件：以混合方案（Hybrid）部署，同時使用傳統算法與 PQC 算法，維持向下相容性。
- 實施 PQC 防護欄：更新開發指南，限制創建使用脆弱演算法的新 API 或金鑰。
- 整合 PQC 元件：以混合方式部署至生產流量。
五階段成熟度模型
PQ-Unaware → PQ-Aware（了解量子威脅但未行動）→ PQ-Ready（清單完成，計畫就緒）→ PQ-Hardened（部分部署，防禦「現在收集未來解密」攻擊）→ PQ-Enabled（完整部署，抵禦有量子電腦的攻擊者）。
Hybrid 部署的必要性
Meta 強調 Hybrid 方案不是過渡期的妥協，而是成熟度考量：在 PQC 演算法的密碼分析史尚短的情況下，混合方案確保即使某一方向被攻破，另一方仍提供保護。在 10–15 年的量子電腦威脅時間線上，「現在收集未來解密」攻擊已是現實威脅，因此立即啟動遷移有充分理由。
原始來源：Engineering at Meta — Post-Quantum Cryptography Migration
Cloudflare Dynamic Workflows：多租戶持久執行架構，一個 Worker 路由數百萬獨立租戶工作流程
Cloudflare Blog · 2026-05-01
Cloudflare 發布 Dynamic Workflows 函式庫，讓平台開發者可以在單一 Worker 中路由不同租戶提供的持久工作流程程式碼，解決多租戶 SaaS 場景下工作流程引擎與租戶程式碼的耦合問題。
問題背景
Cloudflare Workflows 是一個持久執行引擎，允許開發者寫一個 WorkflowEntrypoint 子類別，引擎在工作流程暫停、等待外部事件後可精確重啟執行。問題在於：在多租戶平台中，引擎需要知道要路由哪個租戶的程式碼，但引擎啟動時不知道是哪個租戶發起的工作流程。
技術架構
Dynamic Workflows 以三層架構解決此問題：
- Workflows Engine（平台層）：持久執行的核心引擎。
- Worker Loader（中介路由層）：接收請求後識別租戶身分，動態載入租戶程式碼。
- Tenant Code（動態 Worker 實例）：租戶提供的工作流程實作。
工作流程為：請求進入 Worker Loader → 識別租戶 → 租戶程式碼呼叫 env.WORKFLOWS.create() → Worker Loader 將呼叫攔截並重寫 payload 加入租戶元資料 → 引擎持久化此元資料 → 引擎後續執行時以元資料路由回正確的租戶程式碼。整個封裝邏輯約 300 行 TypeScript。
核心 API
createDynamicWorkflowEntrypoint()
wrapWorkflowBinding({ tenantId })
DynamicWorkflowBinding成本模型
利用 Cloudflare 的 isolate 層多租戶特性，數百萬個獨立租戶工作流程以「近零閒置成本」執行——隔離環境（isolate）在無工作流程執行時不佔用計算資源，與傳統常駐程序的多租戶架構形成對比。
Meta Messenger E2E 加密備份強化：動態 Fleet 金鑰分發與 HSM 透明部署機制
Engineering at Meta · 2026-05-01
Meta 發表 Messenger E2E 加密備份架構的最新強化措施，重點在於 Fleet 金鑰的動態空中分發（OTA），以及新 HSM 部署的可驗證透明機制。
HSM Backup Key Vault 架構
Meta 的備份恢復碼儲存在地理分散的 HSM（硬體安全模組）叢集中，採用多數決共識複製。HSM 的設計使恢復碼對 Meta、雲端提供商及第三方均不可存取，僅用戶自身可取回。
動態 Fleet 金鑰分發
原始架構將 Fleet 公鑰靜態嵌入應用程式二進位，新 HSM 艦隊部署時需等待應用程式更新才能被用戶端信任。新設計改為透過空中分發：Fleet 公鑰以「驗證捆包」（validation bundle）形式分發，由 Cloudflare 簽署後再由 Meta 反簽署，提供獨立的密碼學來源驗證（兩方合謀才能偽造）。這讓新 HSM 艦隊可立即投入服務，無需等待應用程式版本更新。
透明 Fleet 部署承諾
Meta 承諾對每個新 HSM Fleet 的部署公開發布可驗證的部署證明（attestation evidence），用戶可依據白皮書《Security of End-To-End Encrypted Backups》中的稽核程序自行驗證部署的安全性。
原始來源：Engineering at Meta — Strengthening E2E Encrypted Backups