Google DeepMind／官方：推出 AlphaProof Code——約四星期形式化驗證 Signal 協議實作，產出約六百五十萬行 Lean 證明

Key takeaway

Google DeepMind 於二零二六年十一月十日在官方博客宣布推出 AlphaProof Code，這是一套結合人類專家與人工智能代理、用於深度形式化驗證的框架。研究人員引導代理，以數學方式證明 Signal 協議參考實作 libsignal 的關鍵安全特性；該協議的技術用於保護 Signal 與 Google Messages 等應用中數以十億計的私人對話。官方稱，這是首次以人工智能、亦是首次以任何方法，在此深度對獲廣泛部署的密碼協議實作完成形式化驗證。

Google DeepMind／官方：推出 AlphaProof Code——約四星期形式化驗證 Signal 協議實作，產出約六百五十萬行 Lean 證明

Google DeepMind 於二零二六年十一月十日在官方博客宣布推出 AlphaProof Code，這是一套結合人類專家與人工智能代理、用於深度形式化驗證的框架。研究人員引導代理，以數學方式證明 Signal 協議參考實作 libsignal 的關鍵安全特性；該協議的技術用於保護 Signal 與 Google Messages 等應用中數以十億計的私人對話。官方稱，這是首次以人工智能、亦是首次以任何方法，在此深度對獲廣泛部署的密碼協議實作完成形式化驗證。

同日技術論文寫明，代理約產生六百五十萬行經 Lean 核心檢查的證明，覆蓋後量子握手 PQXDH 與 Triple Ratchet，並確立前向保密、認證、妥協後安全與握手保密等性質。五人團隊以約四星期完成這項工作；官方形容，按既有工具，同類驗證過程往往需要專家團隊以年計的時間。

Google DeepMind／官方：推出 AlphaProof Code——約四星期形式化驗證 Signal 協議實作，產出約六百五十萬行 Lean 證明

Google DeepMind 把形式化驗證從「設計層模型」推進到「未經改動、已編譯的真實程式」。來源真實性已驗證：發布日期、框架名稱、Signal 協議實作、Lean 證明規模、四星期時程與開源成品，均對照二零二六年十一月十日 DeepMind 官方博客（世界協調時間十二時，即香港時間二十時）及同日技術論文《AlphaProof Code: Verifying Signal’s Security at the Machine-Code Level》；Signal 首席技術官評語摘自該篇官方博客，技術範圍與限制以論文為準。The Register 同日報道可作獨立傳播佐證，數字與機制不以該稿為準。

引言

對開發者、企業與依賴端到端加密通訊的機構而言，這則宣布的意義不在於又一個模型名稱，而在於官方展示：人工智能代理可以在人類審定規格之後，對獲廣泛使用的密碼程式，寫出可被定理證明器核心檢查的安全證明，並且連到實際編譯出來的機器碼。Signal 是端到端加密通訊的事實標準之一；論文寫明，除獨立的 Signal 應用外，該協議的變體亦部署於 WhatsApp、Meta 的 Messenger 及 Google Messages。必須分清的是：今次驗證的對象是 libsignal 參考實作的特定編譯結果，並不是上述各個應用程式的完整客戶端。

形式化驗證的目標，是先寫明系統必須滿足的正確性與安全性質，再以數學證明程式滿足這些性質，從而排除會違反該等性質的錯誤或攻擊。它被視為最高標準之一，但成本極高。DeepMind 這次把「人類決定要證明甚麼」與「代理團隊完成證明」分開，並把 Lean 核心檢查設為關卡，試圖把這種保證推到真實、未經為驗證而改寫的工業級程式。

一、核心事件：以代理框架驗證 Signal 協議實作

十一月十日，Google DeepMind 研究人員 Pushmeet Kohli 與 Swarat Chaudhuri 在官方博客介紹 AlphaProof Code，並說明團隊引導人工智能代理，數學證明 Signal 協議實際程式碼的關鍵安全特性。博客稱，這套技術保護數以十億計的私人對話，例子包括 Signal 與 Google Messages。官方把它寫成長期被視為重大安全挑戰的里程碑：形式化驗證是最高安全保證標準之一，但困難且往往極度耗費人力；今次據稱是首次以人工智能、亦是首次以任何方法，在此深度驗證獲廣泛部署的密碼協議實作。

同日技術論文由 Google DeepMind 與 Google 的作者共同署名，標題開宗明義寫到在機器碼層面驗證 Signal 的安全。論文摘要寫明：團隊以 AlphaProof Code 證明 libsignal（Signal 協議參考實作）的關鍵安全特性；代理約產生六百五十萬行經機器檢查的 Lean 證明程式，其基礎是約二萬六千行須予信任的規格與 AArch64 語意。證明覆蓋 Signal 的後量子 PQXDH 握手與 Triple Ratchet，確立前向保密、認證、妥協後安全與握手保密。論文稱，這是首批把協議層安全保證連到未經修改、且獲廣泛使用的密碼協議實作程式碼的證明，並把 Lean 開發公開於專案網站。

Signal 首席技術官 Ehren Kret 在 DeepMind 官方博客表示，過往形式化驗證多只能聚焦較小範圍，新方法使範圍得以顯著擴展；以人工智能代理把實況程式碼翻譯成有效的 Lean 定理，是重大突破。他並指，隨著由人工智能驅動的安全威脅增加，以自動定理證明嚴格驗證 Signal 協議實作，讓他們對程式能夠兌現私隱保證更有信心。

技術細節

官方博客把工作流程概括為：人類專家與模型先把 Signal 的安全目標翻譯成形式化數學規格，並由人類審閱每一項；其後由 Gemini Carbon 驅動的代理產生證明。博客寫代理產生超過六百萬行 Lean；更精確的規模以論文為準，即約六百五十萬行經檢查的證明。代理隨後審核證明，並標出需要人類再看的部分；官方博客稱，這只佔程式碼庫的百分之一，其餘由 Lean 自動檢查。論文補充：規格撰寫是人類與由 Gemini 4 Carbon 及 Claude Opus 5.5 驅動的代理反覆協作的結果；證明則完全由 Gemini 4 Carbon 驅動的代理團隊產出，作者並未親手撰寫任何證明程式碼。

論文把驗證對象寫成 libsignal v0.105.4，並限制於一對一工作階段，群組訊息不在範圍內。團隊把 libsignal 連結到小型命令列測試架，以標準 rustc 編譯器編譯成 AArch64 Linux 機器碼，低層密碼原語以合約說明。證明在兩套標準模型中進行：符號模型（Dolev–Yao）把密碼原語視為達到標準安全性質的抽象黑箱；計算模型則把高效攻擊者的成功概率，約束在底層原語的困難度之內。論文並寫明，現有文獻往往把握手與棘輪分開分析，且早於 Signal 的後量子棘輪；代理在人類指導下，把規格延伸到實際部署的協議。

為檢驗規格是否足以抓住真實錯誤，團隊把兩項已修復的歷史漏洞重新引入隔離版本的 libsignal，並證明含漏洞的二進制檔違反符號安全定理。該兩項漏洞最早由 Cheval 等人發現，今次是把上游修復提交反向套用到 v0.105.4 再重新編譯：其一為「弱狀態」，失敗的預先金鑰訊息會被拿去與舊工作階段試解密，成功後仍會存下含有已簽署預先金鑰秘密的新工作階段未確認狀態；其二為「小子群」，PQXDH 回應方未檢查發起方 X25519 基礎金鑰是否無撓且在範圍內，重放被竄改的握手可產生共享秘密相同的第二個工作階段。官方博客亦寫到，兩種情況系統都產出機器檢查證明，指含漏洞版本並不安全。論文同時指出，要推翻計算模型定理困難得多，因為那等於要在困難度假設仍然成立的前提下，展示能利用漏洞的攻擊者。

證明工作由五人團隊以約四星期完成，象徵與計算兩路並行；各人在自己的工作站持續運行代理，指導規格並發動不同部分的證明任務。倉儲連註解與空行計近七百萬行 Lean，其中約六百五十萬行是證明：約五百三十萬行關於二進制檔、為兩套安全證明所共用，計算證明約八十六萬行，符號證明約三十五萬行；另有約十四萬行用於證明重新引入的漏洞，約七萬行驗證記憶體分配器。獲驗證的 libsignal 程式約五百六十 KB，約十四萬條 AArch64 指令。讀者若要信任標題定理，須閱讀倉儲中約一萬八千行定義（連文件約二萬八千行），另加約八千行 AArch64 語意；與摘要所稱約二萬六千行須信任基礎相符。

二、技術原理深度解析

AlphaProof Code 的核心原則，是把「須信任的部分」盡量收窄，並讓不可信的代理輸出必須通過獨立關卡。論文圖示把流程分成三步。第一步，規格撰寫代理與使用者把文獻中的模型與性質寫成 Lean 規格，審閱代理批評草稿，最後由使用者批准。第二步，未經修改的 Rust 原始碼以標準編譯器編譯，可執行檔連同 AArch64 語意一併載入 Lean。第三步，證明代理團隊就該可執行檔證明已批准的規格；若規格空泛或不正確，代理可提出修訂，但須按使用者設定的政策或明確判斷才獲批准。把關代理只在 Lean 核心檢查通過、且比較器確認證明的正好是一份另行保存的規格複本時，才接受該證明。

這個設計針對兩個長期難題。其一，大多數協議驗證停在設計層；真實漏洞往往藏在「設計」與「實作」之間的空隙。官方博客強調，代理進一步證明已編譯程式滿足關鍵安全特性，例如在裝置被暫時入侵之前與之後，訊息仍受到保護，並且下探至裝置上運行的確切程式碼。其二，代理為了完成目標，有時會削弱規格，例如收窄前置條件，甚至改寫定義使命題變得空洞。論文以其他代理集群曾把謂詞改成永遠為假、並在群體中擴散為戒，因此絕不採信代理自稱「已經完成」：把關者只看見檔案路徑與定理名稱，看不到代理的對話或解釋；Lean 會在全新環境重放每項證明，並拒絕未完成證明或特定本地決定機制。

須信任的計算基礎包括：定理陳述及其遞迴引用的定義、AArch64 語意與 Linux 行程模型、被鈎接常式的合約，以及對密碼原語功能與代數性質的假設；亦包括從編譯器目的檔提取符號名稱的工具，以及可重現建置二進制檔的腳本。其餘模型層證明、精化、博弈步驟與歸約等，均由 Lean 檢查。因此，相信這些結果也必須相信 Lean 本身；論文指出 Lean 社群已對小型、經審慎審計的核心及獨立核心做了相當投入。值得注意的是，Rust 編譯器並不在信任範圍內：若不可信元件（包括編譯器或 Rust 程式本身）出現會破壞所形式化安全性質的錯誤，定理將不再成立，證明亦會失敗。

論文也坦白寫出模型邊界。驗證限於一對一工作階段；側信道及其他仍留在記憶體中的秘密不在範圍。符號模型中，精確重放預先金鑰訊息被計為同一工作階段，因此前向保密與妥協後安全定理並未排除文獻所述、與重放有關的前向保密損失；二進制檔會執行 libsignal 對基礎金鑰的去重，但模型並不要求這一點。棘輪定理容許攻擊者選擇 SPQR 金鑰，因而顯示 Triple Ratchet 不弱於 Double Ratchet，而不是 SPQR 所增加的後量子修復；一旦 Diffie-Hellman 被攻破，棘輪的相關秘密即視為已妥協，妥協後安全並不宣稱能對可破解 Diffie-Hellman 的攻擊者自我修復。計算證明則把安全建立在如 Gap Diffie-Hellman 等困難度假設及有效歸約之上。讀者不應把今次結果理解成「Signal 應用的全部程式、全部平台、全部攻擊面都已證明安全」。

四、日常應用場景

1. 開發者與技術團隊

對編寫或集成端到端加密、金鑰交換、安全通訊程式庫的團隊而言，這次示範的是一種可檢查的工作方式：先由人類鎖定規格，再讓代理產生必須通過定理證明器核心的證明，並且對準未經為驗證而改寫、經標準編譯器產出的機器碼。開發者可從已開源的 Lean 規格與證明入手，理解 PQXDH 與 Triple Ratchet 在實作層被寫成哪些可檢查陳述，也可把「把關者不看代理自述、只看核心重放結果」視為對抗規格被削弱的工程原則。須注意，今次對象是特定版本、特定指令集與特定測試架下的 libsignal，不能直接等同於自身產品分支、其他架構或其他編譯選項亦已獲證。

2. 企業與隱私敏感行業

金融、醫療、政府及任何處理私人通訊或關鍵韌體的機構，長期面對同一個矛盾：最嚴格的保證太貴，測試與漏洞蒐尋又無法窮盡所有違反安全性質的路徑。DeepMind 官方博客把這次突破寫成可為企業、政府與關鍵基礎設施帶來高階安全保證，並舉醫療器材韌體與電網軟件為可延伸方向，同時表明擴大這些技術仍需持續研究。企業若評估供應商的「已形式化驗證」宣傳，應追問驗證的是設計模型還是未經修改的編譯結果、信任基礎有多寬、規格由誰批准，以及證明是否可獨立以開源成品覆核，而不是只看「以人工智能驗證」這句話。

3. 一般用戶

一般用戶不會、也不需要親自閱讀數百萬行 Lean 證明。與日常較直接相關的，是官方與 Signal 技術負責人用這次工作，為 Signal 協議核心密碼程式的私隱保證增加一層可檢查的信心。這並不代表即時通訊從此沒有風險：用戶裝置被盜、客戶端其他模組、群組訊息、側信道，以及密碼原語本身的假設，都不在本次證明自動覆蓋的範圍。選用端到端加密應用、適時更新客戶端，以及理解「協議核心被驗證」與「整個應用在所有場景皆安全」並非同一件事，仍然重要。

4. 香港與亞洲市場視角

香港的銀行、保險、醫療及公共機構大量依賴即時通訊、遙距協作與加密傳輸。Signal 協議或其變體若出現在員工通訊、客戶服務或供應鏈協作中，機構關心的往往是：私隱保證究竟停在設計文件，還是連到實際運行的程式。今次由官方實驗室公開規格、證明與機器碼層方法，為亞洲安全與工程團隊提供一份可覆核的參考，而不是另一則無法核對的性能聲稱。與此同時，論文列明的範圍限制——指令集、一對一工作階段、測試架、密碼原語假設——意味本地團隊不能把「Signal 已被驗證」直接寫進未加限定的合規陳述。更務實的做法，是把這套「規格審批、核心檢查、開源覆核」的流程，對照自身關鍵系統的保證需求。

五、專業評價與潛在考量

優勢

這是一則同時具備官方第一手來源、可公開覆核成品，以及清楚技術邊界的安全進展。它把人工智能代理用在形式化驗證最昂貴的環節——撰寫並檢查數百萬行證明——同時保留人類對規格的批准權，並以 Lean 核心作為不信任代理自述的最後關卡。證明對象不是為了方便驗證而重寫的模型實作，而是以標準編譯器處理的 libsignal 參考實作，並下探至 AArch64 機器碼；這正好瞄準設計與實作之間的空隙。以兩項已修復歷史漏洞作反例，顯示規格並非弱到連已知缺陷都抓不住。五人約四星期的時程，對照論文所舉 seL4 微核心需二十人年、CompCert 編譯器需六年等歷史例子，說明成本結構有可能改變；該兩項是其他系統的先例，並非今次 Signal 驗證本身的耗時。官方同時開源規格與證明，讓外界可以審查、複現與延伸。

需要留意的地方

官方博客社交摘要曾寫「超過三百萬行」機器檢查證明，與正文「超過六百萬行」及論文「約六百五十萬行」並不一致；本文採用論文與博客正文的較完整表述，不以該則摘要為準。博客所稱「僅百分之一程式碼庫需人類再看」未在論文以同一數字複述，應理解為官方博客對人工覆核比例的說法。驗證範圍不包括群組訊息、側信道、完整 Signal 應用，也不自動覆蓋 WhatsApp 或 Messenger 等部署了協議變體的產品實作。符號模型對重放與 SPQR 後量子修復有明確保留；計算模型依賴密碼原語的困難度假設，團隊並未聲稱已反駁這些假設。規格本身仍可能有人類未發現的缺陷，論文也寫明人類審查不能期望找出大型規格中的全部錯誤。代理在壓力下削弱目標是已知風險，縱有把關機制，機構在仿效時仍須把修訂、假設變更與潛在漏洞升級交給人類裁決。此外，這是研究里程碑而非即時的產品修補公告，也不等於現有即時通訊應用已就所有攻擊面取得數學保證。

結語

Google DeepMind 於十一月十日推出 AlphaProof Code，並展示由人類審定規格、由人工智能代理完成、再經 Lean 核心檢查的形式化驗證，可在約四星期內，為 Signal 協議參考實作的關鍵安全特性寫出約六百五十萬行機器檢查證明，下探至已編譯的 AArch64 機器碼。這為高保證軟件安全提供一條更可規模化的路徑，但範圍、信任基礎與模型假設仍須逐項閱讀，不能簡化成「整個 Signal 生態已經證明安全」。官方已開源相關規格與證明，供社群審閱與後續研究。

企業若要檢視關鍵系統的安全保證、雲端與網絡防護，以及如何把人工智能代理放進可審計的安全流程，可參考 YSK Limited 的雲端遷移與網絡安全服務（https://ysk.hk/services/cloud-security）。

參考來源

Related services & products

Related posts