Black Hat USA 2025 | Decoding Signal: Understanding the Real Privacy Guarantees of E2EE
三句話摘要
資深安全工程師對 Signal 端對端加密訊息應用進行深度安全審查，揭露三個零點擊漏洞。 Signal 在密碼學設計與程式碼品質上已屬業界頂尖，真正的風險藏在跨客戶端的邏輯一致性驗證中——封包類型白名單與訊息來源身份驗證是端對端加密應用最容易被忽略、也最致命的防線。 Signal 的隱私設計遠超一般應用：profile 資料全以客戶端生成的 profile key 加密，伺服器只存加密 blob；Sealed Sender 更進一步隱藏發送方，讓伺服器無法知道誰在和誰通訊，這些功能在同類應用中極為罕見。
重點整理
重點- 1
Signal 的隱私設計遠超一般應用：profile 資料全以客戶端生成的 profile key 加密，伺服器只存加密 blob；Sealed Sender 更進一步隱藏發送方，讓伺服器無法知道誰在和誰通訊，這些功能在同類應用中極為罕見。
- 2
雙棘輪協議解決前後向保密問題：每則訊息使用獨立金鑰加密後立即丟棄（解決後向保密），並定期更換棘輪（解決前向保密），即使攻擊者取得裝置上的金鑰，也無法解密過去或持續監控未來訊息。
- 3
明文封包驗證缺失導致訊息注入：Signal 協議允許明文封包僅用於解密錯誤回報，但 iOS 完全未做類型驗證，Android 漏掉 data message 的檢查，惡意伺服器可借此將任意訊息注入任何對話中。
- 4
Android sync message 缺少身份驗證構成零點擊漏洞：連結裝置間透過加密的 sync message 同步狀態，但 Android 未驗證發送方必須是自己，任何用戶皆可發送 sync message 竄改對方配置或注入訊息，無需惡意伺服器介入。
實用技巧與重點
乾貨- Signal 伺服器端程式碼：Java + Rust，約 300K 行；各客戶端 300–500K 行
- 跨平台核心函式庫：Rust（記憶體安全，memory corruption 攻擊面極小）
- Android：Kotlin/Java；iOS：Swift/Objective-C；Desktop：Electron
- Signal 程式碼量比同類應用少 40–60%
- profile key 加密算法：AES-256-GCM，金鑰僅在對話建立後分享
- profile key 輪換時機：封鎖某用戶時
- 雙棘輪協議（Double Ratchet Protocol）：每則訊息獨立金鑰 → KDF 輸出 message key + chain key
- Sealed Sender 功能上線時間：2018 年
- 同步訊息類型（sync message）：共 22 種，含 sent、read、configuration、edit、contacts 等
- 漏洞一（iOS）：接受任意明文封包內容，可注入 data message、edit message 等 11 種類型
- 漏洞二（Android）：明文封包驗證遺漏 data message 檢查
- 漏洞三（Android）：sync message 缺少 sender identity 驗證，零點擊，無需惡意伺服器
- 漏洞三修補時間：2024 年 9 月，當天立即修補
- 下游客戶端 Whisperfish 同受漏洞三影響，CVE 評分 8.5
- Signal 強制更新週期：3 個月，舊版本屆時停止運作
- 靜態分析工具：審查者曾在 Meta 建構主要安全靜態分析系統，可偵測約 50% 的 Meta 內部漏洞
結論
結論“Signal 在密碼學設計與程式碼品質上已屬業界頂尖，真正的風險藏在跨客戶端的邏輯一致性驗證中——封包類型白名單與訊息來源身份驗證是端對端加密應用最容易被忽略、也最致命的防線。”
完整解析
詳細本次演講由擁有 15 年資歷的安全工程師 Ibrahim 主講，內容來自他與 Signal 工程團隊密切合作完成的安全審查。審查範圍聚焦於一對一訊息的零點擊攻擊面，不涉及群組、通話及密碼學協議本身的分析。
Ibrahim 首先介紹 Signal 的整體架構與隱私設計。Signal 的跨平台核心庫以 Rust 撰寫，大幅降低記憶體損壞的攻擊面；伺服器端以 Java 與 Rust 為主，幾乎不含 C/C++。在隱私保護上，Signal 將使用者 profile 資料（名稱、頭貼、狀態）以客戶端生成的 profile key 加密（AES-256-GCM），伺服器只存加密 blob，金鑰從不上傳。訊息加密採用橢圓曲線 Diffie-Hellman 建立共享密鑰，再配合雙棘輪協議（Double Ratchet）為每則訊息產生獨立金鑰，用後即棄，既防止攻擊者取得舊金鑰後解密歷史訊息（後向保密），也透過定期更換棘輪防止長期監控（前向保密）。此外，2018 年推出的 Sealed Sender 功能將發送方身份也加密進封包，讓伺服器只能知道收件人，無從得知誰與誰正在通訊。
進入實作審查後，Ibrahim 發現了三個漏洞，均屬邏輯層或應用特定類別，而非記憶體損壞。Signal 協議允許一種特殊的「明文封包」，僅用於解密失敗時的錯誤回報。問題在於各客戶端對此的驗證力度不一：iOS 完全未檢查明文封包的內容類型，惡意伺服器可發送包含任意訊息（data message、edit message 等 11 種）的明文封包，直接注入任何對話；Android 雖有部分驗證，但遺漏了對 data message 的檢查，執行順序導致惡意 data message 仍可被處理；Desktop 雖也有類似邏輯缺口，但因執行順序不同（先處理 decryption error 且各分支均有 return），實際上並不受影響。
第三個漏洞影響較為深遠。Signal 的多裝置同步機制透過裝置間以標準端對端加密傳送 sync message 來同步狀態，共有 22 種類型。Android 客戶端在處理 sync message 時，未驗證發送方是否為自己的其他裝置，導致任意用戶都能端對端加密發送 sync message 給 Android 裝置，竄改配置（如關閉已讀回執）或注入訊息，整個過程對伺服器而言看起來完全正常，構成零點擊漏洞。此漏洞在 2024 年 9 月當天被發現、當天修補，下游客戶端 Whisperfish 亦受影響並獲 CVE 評分 8.5。Ibrahim 強調，Signal 的強制更新週期為三個月，因此目前應無在野的易受攻擊客戶端。
整體而言，Ibrahim 在全面審查 SQL 注入、記憶體安全、JavaScript prototype 污染等常見問題後均無發現，僅有上述邏輯層漏洞。這符合他的預期：隨著應用日趨成熟，漏洞類型會從語言層面轉移至邏輯與產品設計層面。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
