GG18/GG20 協定安全漏洞分析

9 個月前生態安全

對安全保持敬畏之心，開放與協作推進行業安全

作者：Safeheron team

封面：Photo by Nicolas Arnold on Unsplash

背景

近期，Fireblocks 團隊披露了 GG18、GG20 、Lindel 17 MPC 協定中的 0-day 漏洞，該漏洞允許攻擊者提取一組 MPC 私鑰分片背後的真實密鑰。

在披露該問題前，Fireblocks 團隊與 Safeheron 取得聯繫並展開積極溝通。 Safeheron 開源的 GG18/GG20 MPC 協定嚴格按照論文內容實現，如果使用此版本的開源演算法則可能受到類似攻擊。 在漏洞披露前，Safeheron 已經修復了開源專案中存在的漏洞，Fireblocks 團隊也協助確認了補丁的生效。

Fireblocks 團隊採用 Safeheron 的基於 C++ 實現的開源 GG18/GG20 協定構造了 POC，以演示並幫助社區理解該漏洞。

Safeheron 商業版服務中的 GG18/GG20 MPC 協定額外引入了 CMP20/CGGMP21 中的相關零知識證明，因此不受該漏洞影響。

漏洞影響範圍

本文重點關注漏洞針對 GG18 和 GG20 的影響。針對 GG18/GG20 協定，攻擊方通過構造特殊的 Paillier 金鑰，從而在 MPC 簽名階段完成攻擊，通過有限次的簽名，攻擊方可以解析出其它各參與方的私鑰分片。

此次漏洞的影響範圍比較廣泛，由於影響到了 MPC 協定的安全假設，因此幾乎所有主流的開源 GG18/GG20 協定實現都受到該漏洞的影響。

漏洞原理

如何攻擊 MPC 協定呢？常見的 MPC 協定在安全假設前提下是可證明安全的，因此針對 MPC 協議的攻擊常常聚焦於協議依賴的安全假設。 安全假設就好比是 MPC 協定大廈的地基，如果安全假設不成立了，那麼整個 MPC 的協定都將會受到影響。

以 GG18/GG20 為例，該 MPC 協定依賴於 Paillier 同態加密演算法的安全性。 Paillier 同態加密演算法基於復合剩餘類的困難問題設計，是一種廣泛使用的且滿足加法運算的同態加密演算法。

整個攻擊的核心邏輯如下：

攻擊方法

本節我們詳細介紹攻擊的細節。在通用的 MPC 門限多簽場景中存在多個參與方，這些參與方兩兩之間可以發起攻擊，而且攻擊方式完全相同。

準備階段：構造不安全的同態密鑰

首次攻擊發生在 KeyGen 子協定的執行過程中，我們可以稱其為攻擊準備階段。 在攻擊準備階段，攻擊方 Party A 成功構造了不安全的 Paillier 同態密鑰。

正常建構同態金鑰的過程如下：

攻擊階段：Sign 子協定

接下來介紹其具體操作方式。

GG18/GG20 協定中的零知識證協定描述如下：

收尾階段：計算被攻擊方的私鑰分片

在運行 16 次成功的 MPC Sign 子協議以後，得到

攻擊效果

GG18 論文有兩個實現版本，修正版和老版，針對不同版本的攻擊效果有所區別。

在 GG18 修正版論文中作者提供了很多安全修改建議，因此在實現該 MPC 協定時應基於修正版實現。

真實應用場景攻擊方式

上述章節描述了該漏洞的原理和演算法層面的攻擊方式，那麼針對真實的基於 MPC 的自託管錢包應用場景，如果使用的 MPC 協定存在該漏洞，應該如何完成攻擊呢？

該漏洞影響 t/n 門限，為方便理解，我們假設 MPC Wallet 的參與方為 2 方 Party A 和 Party B，簽名的門限為 2/2，其中 Party A 對應的私鑰分片由使用者持有，通過錢包提供方提供的手機 App 管理和使用; Party B 對應的私鑰分片由錢包提供方持有，並且在雲端存儲和使用。

如果要完成攻擊，攻擊者必須具備以下能力：

（1）掌握錢包提供方創建錢包和發起交易的實現邏輯和機制

（2）能夠類比錢包提供者 App 使用 MPC 協定完成創建錢包以及簽名交易

那麼攻擊者便可以發起攻擊：