使用 MPC 錢包連接 dYdX 的安全隱患分析

數字資產安全是第一要務

作者： Safeheron Team

封面： Photo by Shubham’s Web3 on Unsplash

Safeheron  近期上線了 Web3 產品套件，在 MPC 和 TEE 技術的保護下，客戶可以安全地通過 Safeheron 瀏覽器插件與 dApp 交互，解決客戶多人安全管理資產的需求。由於 dApp 種類繁多，在安全層面的設計各有不同，因此 Safeheron 安全團隊定期審查用戶交互的 dApp，以排除用戶使用過程中的潛在安全問題。

在近期的安全審查中，Safeheron 安全團隊發現一些 dApp 的授權設計，在特定的場景下存在潛在的安全問題：

1. dApp 授權連接時可以繞過硬件錢包（冷錢包）對私鑰的安全防護，理論上無需在硬件錢包中完成授權，即可獲取 dApp 的核心操作權限。
2. 使用 MPC 構建的自託管錢包平台，原則上無法控制用戶資產，僅在用戶授權同意參與 MPC 計算時才可以轉移用戶資產。但是使用 MPC 錢包連接特定的 dApp 時，可以打破自託管錢包平台無法控制用戶資產的原則，平台方可以未經用戶授權，掌握用戶 dApp 中資金的控制權限；而且對於客戶而言，可能會繞過預設交易策略，或者員工離開該組織後依然有權限操作 dApp。

Safeheron 安全團隊發現問題後，第一時間聯合慢霧安全團隊共同驗證和協商解決方案， SharkTeam 也參與到問題驗證中，並向可能受到影響的各方進行披露。經驗證，該問題不影響 MPC 錢包進行資金管理的安全性，僅在和特定 dApp 交互時才存在潛在安全問題。

Safeheron 把類似機製造成的問題稱為基於簽名派生密鑰風險（Signature-derived Key Risk），本文以 dYdX 為例，分析此類 dApp 在特定場景下的潛在安全問題。

背景知識

ECDSA 中使用確定性隨機算法

ECDSA 中存在臨時密鑰 k，臨時密鑰的取值方式不僅決定簽名算法的安全性，而且還影響使用「相同的私鑰」針對「相同的待簽署數據」簽名時「簽名結果」是否確定。

如果在簽名過程中臨時密鑰 k 使用隨機數生成器生成，那麼使用私鑰 sk1，對 hash1 第一次簽名得到 sig1，第二次簽名得到 sig2，此時 sig1 不等於 sig2。

如果根據 RFC6979 協議中的確定性隨機算法實現簽名算法，在簽名過程中使用確定性臨時密鑰 k，那麼使用私鑰 sk1，對 hash1 第一次簽名得到 sig1，第二次簽名得到 sig2，此時 sig1 等於 sig2。

常見的 HD 軟件/硬件錢包中通常採用 RFC6979 協議實現 ECDSA 算法。dYdX 等 dApp 正是基於 RFC6979 協議特性，用戶每次授權對固定內容進行簽名總可以得到相同的簽名，使用此簽名作為密鑰派生的源頭，可設計出一種基於 L1 錢包派生可恢復的 L2 密鑰機制。

ECDSA 簽名算法 MPC 協議中的分佈式簽名協議

在 MPC 的場景下，分佈式簽名協議有兩個重要的不同於單私鑰簽名算法的特性：

1. 基於安全性考慮，簽名協議中使用的臨時密鑰 k 使用隨機數生成器生成，因此使用相同的私鑰分片對同一個 hash 進行多次簽名，每次得到的簽名結果不同
2. GG18、GG20、MPC-CMP 等常見的 t/n 簽名協議中，參與簽名協議的 t 方均可以得到簽名結果。 

dYdX 的 STARK Key 和 API Key 派生邏輯

dYdX 中的認證方式

dYdX 中的私有 API 存在 3 種認證方式：

1. Ethereum Key Authentication：可用於註冊用戶，註冊 STARK Key，管理 API Key，強制交易或者強制取款等。
2. STARK Key Authentication：L2 系統中的獨立密鑰對，可用於下單，轉賬，取款等敏感操作。採用 ECDSA 算法，使用 STARK curve，與 SECP256K1 curve 不同。
3. API Key Authentication：與 dYdX 交互的 API Key，所有私有操作都需要該認證方式。

從以上 3 種認證方式可知，下單或者轉移 dYdX 中的資產等敏感操作，只需 STARK Key Authentication 和 API Key Authentication，無需 Ethereum Key Authentication。

dYdX 中的密鑰派生方式

dYdX 官方網站 UI 和 TypeScript SDK、Python SDK 中設計了一種依賴 EVM L1 錢包生態的密鑰管理方式，核心目的在於防止 STARK Key 和 API Key 丟失。只要 L1 錢包私鑰不丟失，按照固定的派生算法就可以重複派生出相同的 STARK Key 和 API Key。

dYdX 中的密鑰派生流程

如圖所示，dYdX 中 STARK Key 與 API Key 的核心派生邏輯如下：

1. 使用 L1 ECDSA Signer 的 eth_signTypedData_v4 簽名方式對消息 dYdX STARK Key 簽名得到 stark_key_signature。本步驟需要用戶在使用的錢包中進行簽名授權。
2. 使用 L1 ECDSA Signer 的 eth_signTypedData_v4 簽名方式對消息 dYdX Onboarding 簽名得到 api_key_signature。本步驟需要用戶在使用的錢包中進行簽名授權。
3. 通過 stark_key_signature  派生得到 STARK Key 公私鑰對。本步驟在本地計算，因為大部分錢包採用 RFC6979 協議實現簽名算法，因此每次簽名得到的 stark_key_signature  固定，所以 STARK Key 公私鑰固定。
4. 通過 api_key_signature  派生得到 API Key 密鑰信息。本步驟在本地計算，因為大部分錢包採用 RFC6979 協議實現簽名算法，因此每次簽名得到的 api_key_signature  固定，所以 API Key 密鑰公私鑰固定。
5. 如果用戶首次使用 dYdX，調用接口/v3/onboarding 進行註冊，註冊時提交 STARK Key 公鑰信息、api_key_signature、用戶 L1 address 等信息。

如果用戶按照官方網站 UI 或者 SDK 方式使用 dYdX 註冊後，後續通過 1～4 步驟經過錢包授權後，便可恢復 STARK Key 和 API Key ，即可獲得 dYdX 的操作權限。

POC

由於上文流程中步驟 1 和 2 每次簽名後得到的簽名固定，因此獲得某次授權後的 stark_key_signature  和 api_key_signature  即可進行步驟 3 和 4 得到 STARK Key 和 API Key。

慢霧安全團隊已經驗證，如果獲得某錢包賬戶授權的 stark_key_signature  與 api_key_signature  兩個簽名，便可以操作該錢包賬戶在 dYdX 資產，如下單、L2 轉賬等。攻擊者可以將 dYdX 中資產首先通過 L2 轉移到攻擊者賬戶，然後提取到攻擊者賬戶的 L1 錢包賬中。

潛在的安全問題

繞過硬件（冷）錢包的私鑰管理機制

一般對於區塊鏈錢包而言，簽名後的簽名結果並非敏感信息，因為每筆區塊鏈交易中均包含該交易的簽名，且該簽名是公開信息。因此錢包軟件/硬件無法針對簽名結果增加更加針對性的安全管理措施。

由於 STARK Key 與 API Key 使用 stark_key_signature 與 api_key_signature 派生得到，經過首次連接 dYdX 後， stark_key_signature 與 api_key_signature 已經脫離錢包應用的密鑰管理範圍。如使用硬件錢包場景，一旦使用硬件錢包操作過 dYdX，stark_key_signature 與 api_key_signature 便不再受硬件錢包安全管理。因此，攻擊者一旦掌握了 stark_key_signature 與 api_key_signature 後，後續與 dYdX 操作完全可繞過硬件錢包授權。其他使用類似機制的 dApp 存在同樣的問題。

打破 MPC 錢包自託管原則

基於 MPC 技術構建的自託管錢包平台一般通過去中心化管理私鑰分片的形式實現自託管，即錢包平台無法未經用戶授權的情況下獨自掌握用戶資產的控制權。基於 MPC 的自託管錢包平台一般使用 GG18、GG20、MPC-CMP 等協議。而 GG18、GG20、MPC-CMP 等 t/n 協議中，參與簽名協議的 t 方均可以得到授權之後的簽名結果。

針對基於 MPC 的自託管錢包平台而言，一旦用戶使用過 dYdX 等類似 dApp，MPC 錢包平台方作為私鑰分片管理的參與方，自然也可以獲取 stark_key_signature 與 api_key_signature。此時 MPC 錢包平台方有能力在不經過用戶授權的情況下控制用戶 dYdX 中的資產。

因此使用 MPC 錢包與 dYdX 或者類似使用簽名結果派生密鑰的 dApp 交互，對於 MPC 錢包平台而言，打破了自託管原則，平台方可繞過用戶授權、繞過 MPC 計算控制用戶在此類 dApp 中的資產。針對客戶而言，可能會繞過預設交易策略，或者員工離開該組織後依然有權限操作 dApp。

使用隨機臨時密鑰 k 錢包的用戶潛在丟失資產問題

現在有很多瀏覽器錢包插件通過覆蓋 MetaMask 相關接口的方式提供錢包接口，或者通過 WalletConnect 方式連接 dApp。dYdX 官方網站 UI 在使用 MetaMask 或者 WalletConnect 連接用戶錢包時，默認接入的錢包均符合 RFC6979 規範，對錢包未進行檢測。如果用戶使用的錢包採用隨機臨時密鑰 k ，可能造成用戶關閉瀏覽器或者更換瀏覽器後，使用相同 L1 錢包，無權限操作 dYdX 從而造成資產丟失。雖然可以通過 Ethereum Key Authentication 方式強制贖回資產，但是贖回方式複雜，普通用戶幾乎沒有能力完成此操作。

解決方案

dYdX 類 dApp 優化密鑰管理機制，與社區共建錢包接口規範

在 dYdX 的場景下，由於 dYdX 基於 StarkEx 構建，StarkEx 基於 STARK proof 機制構建，因此需要在使用的過程中派生 STARK Key 以及使用基於 STARK curve 的簽名算法。為了兼容現有的 EVM 錢包生態，dYdX 採用了基於簽名派生密鑰的方式，而這種方式導緻密鑰管理的範圍脫離了錢包保護私鑰的範圍。

如果想要更好地保護 STARK Key，則需要 STARK Key 的派生過程和使用過程在安全的環境中進行，且每次簽名均需要用戶授權，例如：派生過程和簽名過程均在錢包應用中完成。目前更好的方式是與錢包社區共建基於 STARK Key 的私鑰管理接口規範，錢包層面支持 STARK curve 的 ECDSA 簽名算法，可以在 StarkEx 場景下更好的保護私鑰。

原生支持硬件錢包的 dApp 用戶依然可以使用硬件錢包以更好保護資產，而對於 dYdX 和其他尚未原生支持硬件錢包的 dApp 來說，Safeheron 安全團隊建議此類 dApp 用戶保證自己的操作環境安全，如準備專有的 MacBook 操作 dYdX，並及時更新瀏覽器，電腦中不安裝其他無關的軟件，瀏覽器中不安裝插件，保證操作環境安全。

Safeheron 也在積極地聯繫 StarkWare 和社區以共同構建一個安全模型以滿足與 dYdX 類 dApp 安全交互的需求。在 Safeheron 通知的 MPC 解決方案中，一些解決方案如 ZenGo、Fireblocks、Fordefi 等也正在構建他們的安全模型以解決這個問題。

MPC 自託管錢包平台屏蔽 dYdX 類的 dApp

針對自託管錢包平台，因為現有 dYdX 官方網站 UI 下打破了自託管原則，所以臨時的解決方案可以屏蔽 dYdX 類 dApp，並給客戶進行明顯提示。dApp 在連接錢包時提示客戶，使用 MPC 錢包時可能存在的潛在風險。已經使用 MPC 自託管平台管理 dYdX 的客戶可以使用其他新的賬戶重新連接 dYdX，並將老賬戶中資金轉移到該新賬戶，以確保資產安全。

通過支持 STARK curve 的 MPC ECDSA 協議安全管理 STARK Key

如果客戶有多人共同管理在 dYdX 中資產的需求，那麼可以針對 StarkEx 所使用的 ECDSA 設計出對應的 MPC 協議，在私鑰管理層面實現多人共管。目前 Safeheron 也在積極與社區溝通解決方案，並且啟動 MPC-ECDSA 支持 STARK curve 協議的實現和開源，後續 Safeheron 客戶可以通過該 MPC 協議安全地多人管理 dYdX 中的資產，社區可以基於該開源協議定制不同的解決方案。

dYdX 類應用檢查錢包是否符合 RFC6979 規範

因為使用隨機臨時密鑰 k 錢包的用戶潛在丟失資產問題，所以 dYdX 類應用應該在連接錢包時檢查是否符合 RFC6979 規範，如果不符合該規範，應提示用戶，並拒絕該錢包連接；優化 Ethereum Key Authentication 方式強制贖回資產方式和操作體驗，便於用戶快速找回資產。

總結

Safeheron 本著最高安全行業準則和對用戶負責的態度，立即啟動披露程序，所涉各方均已採取有效措施。dYdX 已經禁止 L2 交易以降低風險；Safeheron 計劃開源支持 STARK curve 的 MPC-ECDSA 協議，同時計劃在產品層面增加對 StarkEx 和 StarkNet 的原生支持，以更好地協助用戶安全地管理資產。

在 Web3 迅速發展的今天，資金暴雷事件頻發，用戶資金安全不容忽視，Safeheron 與社區、協議方和其他安全公司通力合作，提出問題並解決問題，共同維護加密世界的安全。

免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。文章內的信息僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。