ZenGo は、マルチパーティ コンピューテーション (MPC) テクノロジーを使用した安全な Web 3 ウォレットです。
最近、CertiK の SkyFall チームは多数のモバイル ウォレットの徹底的な監査と調査を実施し、ZenGo の MPC ソリューションが通常のモバイル ウォレットよりも強力なセキュリティ防御を提供していることを発見しました。ZenGo ウォレット ユーザー、特に価値の高いウォレットを使用しているユーザーは、高度な攻撃者からの直接攻撃から保護されています。たとえば、ゼロデイ脆弱性や高度なマルウェアを悪用して、ユーザーのデバイス上で root アクセスを取得します。
この脅威は最新のものであり、CertiK チームによってのみ発見されたため、MPC ウォレット開発者は攻撃の詳細に注意を払う必要があります。
特権を持つ攻撃者から防御することは困難です。レポート結果では、ZenGo における MPC 手法に対する新しい攻撃手法と攻撃ベクトルを提案します。そこで、このセキュリティ問題を直ちに ZenGo に報告したところ、ZenGo はすぐに対応し、問題を修正しました。
この記事では、発見の技術的な詳細を掘り下げ、MPC ウォレット全体のセキュリティを向上させるために ZenGo とどのように協力しているかを共有します。
ZenGo のセキュリティ設計と問題に対する専門的な対応を徹底的にレビューした結果、CertiK は、ZenGo が現在市場で最も安全なウォレット ソリューションと言えると考えています。
MPCとは何ですか？
マルチパーティ コンピューテーション (MPC) は、安全なマルチパーティ コンピューテーション (SMPC) とも呼ばれる、暗号化の分野です。これにより、各当事者のキーが漏洩しないようにしながら、複数の当事者が共同でトランザクションに署名できるようになります。
MPC テクノロジーは複数の関係者にキーを配布できるため、単一障害点を排除できるため、ユーザーは Web 3 秘密キーをより適切に保護できます。この方法は一般に「しきい値署名」とも呼ばれ、現在多くの Web 3 で使用されています。管理者とウォレット開発者は Web 3 資産を保護します。その中でも、ZenGo は最も有名で最もよく使用されている MPC ウォレット開発者の 1 つです。
以下の図に示すように、ウォレットはトランザクションの署名を制御するために従来の秘密キーを使用しません。代わりに、複数の秘密キーがシャーディングされてトランザクション署名プロセスに参加し、検証用の最終署名を生成します。
署名を生成する一般的な MPC 設計
この調査を通じて、私たちは MPC アプローチに関連する課題と潜在的なセキュリティ リスク、および Web 3 資産保護の重要性を認識しました。したがって、私たちはこれらの課題を調査して解決することで、Web3 ユーザーをより適切に保護したいと考えています。
そこで、次の質問について考えることができます。なぜ MPC ウォレットは、従来の暗号通貨ウォレットと比較してより高いセキュリティを提供できるのでしょうか?どのように行われるのでしょうか？
ZenGo MPC の設計と安全性の保証
この調査を通じて、私たちは MPC アプローチに関連する課題と潜在的なセキュリティ リスク、および Web 3 資産保護の重要性を認識しました。したがって、私たちはこれらの課題を調査して解決することで、Web3 ユーザーをより適切に保護したいと考えています。
そこで、次の質問について考えることができます。なぜ MPC ウォレットは、従来の暗号通貨ウォレットと比較してより高いセキュリティを提供できるのでしょうか?どのように行われるのでしょうか？
さまざまな Web 3 ウォレットの設計を評価した後、私たちは MPC の Web 3 ウォレットを検討しました。市場で最も評価されている MPC ウォレットの 1 つと、セルフホスト型 MPC ウォレットをリードする ZenGo を評価しました。
この評価では、以前の調査で概説したのと同じ脅威モデルを使用しました。「デバイスがマルウェアに感染しても、このウォレットは依然として資産を保護しますか?」
ZenGo セキュリティ アーキテクチャの概要
上の図に示すように、ZenGo ウォレットは独自のセキュリティ設計を採用しており、セキュリティ アーキテクチャと回復プロセスは従来のウォレットよりも多層化されています。 ZenGo が提供するセキュリティ機能には次のものが含まれますが、これらに限定されません。
二者署名スキーム: ZenGo の MPC 設計は二者署名スキームを実装しています。各ユーザーは、トランザクション署名を生成するときに 2 つのキー シャードを必要とします。1 つは ZenGo のサーバーに保存され (マスター キー ①)、もう 1 つはユーザーのデバイスに保存されます (マスター キー ②)。 ZenGo もユーザーも、相手がどのようなキーを保持しているのか知りません。
TEE ベースの保護: さらに、「中間者」攻撃や「APP ハイジャック」攻撃を防ぐために、ZenGo アプリケーションは TEE (信頼された実行環境) ソリューションを使用し、TEE 秘密キーを使用して HTTPS に署名します。関連する API をリクエストするための通信コンテンツ。この TEE ベースのデバイス キーは、ユーザーがデバイスをセットアップするときに TEE 内で生成され、オペレーティング システム自体によっても抽出することはできません。
これらのセキュリティ機能を導入すると、攻撃者はメモリやストレージ ファイルからユーザーの秘密キーを盗み、ZenGo ユーザーの資産を制御することができなくなります。また、ZenGo は TEE を使用して、サーバーとクライアント間の対話が改ざんされないように保護します。これは、「中間者」攻撃や「APP ハイジャック」攻撃が効果的にブロックされ、防御されることも意味します。
私たちの監査では、ZenGo がこれらの攻撃に対抗できる安全な設計と実装を備えていることが確認されました。これは、私たちが接触した監査済みのウォレットの中で最高レベルのセキュリティ設計です。
ZenGo のセキュリティ設計と実装は、特権や上記の攻撃を含む攻撃を適切に防御します。ただし、特に攻撃者が任意のメモリを読み取る (場合によっては書き込む) 可能性があることを考慮すると、あらゆる種類の特権攻撃に対処するのは簡単ではありません。
ウォレット全体を監査することで、ZenGo の実装上の問題を発見することができました。この問題により、特権を持つ攻撃者として動作し、特定の保護を回避できるようになりました。
ただし、詳細について説明する前に、ZenGo ウォレットのセキュリティ メカニズムを確認してみましょう。
ZenGo ウォレットの安全な実践
この調査を通じて、私たちは MPC アプローチに関連する課題と潜在的なセキュリティ リスク、および Web 3 資産保護の重要性を認識しました。したがって、私たちはこれらの課題を調査して解決することで、Web3 ユーザーをより適切に保護したいと考えています。
そこで、次の質問について考えることができます。なぜ MPC ウォレットは、従来の暗号通貨ウォレットと比較してより高いセキュリティを提供できるのでしょうか?どのように行われるのでしょうか？
従来の Web 3 ウォレットには秘密キーのみが必要です。ただし、ユーザーが秘密キーやニーモニック フレーズを公開する可能性は常にあります。そのため、秘密鍵を失い、攻撃者が資産を取得するのを目撃する可能性があります。
MPC ウォレットの動作は異なります。ウォレットには単一の秘密キーがありません。ユーザーは 1 つの秘密キー シャードのみを保持し、残りの秘密キー シャードについては何も知りません。この観点から、攻撃者がユーザーの個人キーを取得したとしても、資金を直接送金することはできません。ユーザーをさらに保護するために、ZenGo はさまざまな手段を使用してセキュリティ設計を強化しています。これには、前述の二者署名スキームと TEE ベースのデバイス保護だけでなく、顔スキャンベースの生体認証と追加のキー暗号化も含まれます。
ユーザー登録時およびユーザーアカウント回復時の保護措置
ZenGoは、ユーザー登録およびアカウント回復プロセス中に、ユーザー資産を保護するために次の保護措置を採用します。
ユーザー識別保護: 二者間の署名スキームでは、ユーザーは他の当事者 (ZenGo の設定ではサーバー側) と対話する場合にのみ資金を使用できることが要求されます。ユーザーと、サーバーに保存されている関連するキーシェアを識別できるようにするために、ZenGo はアカウントを登録するためにユーザーの電子メールを必要とします。
電子メールのハッキングを回避するために、ZenGo は顔スキャン技術 (FaceTec の Zoom) を使用して生体認証情報をユーザー アカウントに関連付けます。登録と電子メール認証後のアカウント回復プロセス中に、ユーザーは認証のために「顔をスワイプ」する必要があります。
アプリケーションサーバー通信の保護: ZenGo サーバーが正規ユーザーのデバイスと確実に通信できるようにするため、ZenGo は登録およびアカウント回復プロセス中に TEE 環境に非対称キーを生成して登録します。 ZenGo アプリケーションとサーバー間のすべてのやり取りは、この特定のキーで署名される必要があります。このキーはハードウェア ベースのセキュリティ ソリューションによって保護されているため、攻撃者が直接読み取ることはできず、キーの悪用は困難です。
ZenGo ユーザー登録とアカウント回復プロセス
ユーザー キー共有保護: ユーザーにキー シャードの保存とバックアップを許可することは、ZenGo が提供するすべてのセキュリティ手段を侵害する可能性があるため、危険です。このセキュリティ問題を解決するために、ZenGo は登録プロセス中に暗号化キーを生成します。暗号化キーはユーザーのキー共有を暗号化し、暗号文をサーバーに保存します。
ただし、暗号化キーは ZenGo と共有されず、代わりにユーザーの Google ドライブまたは iCloud との同期が強制されます。暗号化されたキーは、ユーザーが電子メール検証とサーバーベースの生体認証に合格した後にのみ共有し、さらに復号化できます。その中でも、サーバーベースの生体認証（FaceTec顔認識）は、従来の2D/3D顔再構成では「だまされる」ことがほとんど不可能です。
トランザクション署名の生成 ZenGo トランザクション プロセス
トランザクションに署名するために、ZenGo アプリケーションは ZenGo サーバーとの一連の対話を実行します。対話中、ZenGo はオープンソースの 2 者署名ソリューションとユーザー キー シャーディングを使用して 2 者署名を生成します。その後、ZenGo サーバーはさらに一歩進んで、トランザクションに署名してブロードキャストします。このプロセスのすべてのリクエストにはタイムスタンプが付けられ、TEE で署名され、情報の整合性と再生不可能性が維持されます。
ZenGo MPC 設計における問題の発見
以前に説明したように、ZenGo のセキュリティ設計には多くの暗号化キーが含まれており、それぞれに異なる責任があります。以下の表に、ZenGo で使用されるキーとその保護方法を示します。
この表から、クライアント側ではマスターキー②、デバイスキー、暗号化キーの 3 つのキーが使用されていることがわかります。攻撃者が ZenGo サーバーと通信してユーザーの資金を盗むには、マスター キー②とデバイス キーの両方を取得する必要があります。
前のトランザクションの詳細セクションで紹介したように、マスター キー ② は双方の署名の生成に参加するテキストとしてメモリ内に存在するため、攻撃者がプロセス メモリを読み取ってマスター キー ② を抽出することができます。部分的な解決策として、ZenGo サーバーへのすべてのトランザクション リクエストは、読み取りや抽出ができないデバイス キーで署名される必要があります。このプロセスは TEE で実行され、攻撃者は制御できません。
しかし、ZenGo のセキュリティ設計には多くの側面があるにもかかわらず、CertiK の SkyFall チームは依然としてその脆弱性を発見しました。 ZenGo アプリケーションのすべての API の詳細な監査を実施した結果、特定の API を使用すると、攻撃者が ZenGo サーバーになりすまして、他のデバイスで使用するための新しいデバイス キーを簡単に生成できることがわかりました。
このデバイス キー登録 API には、必要なセキュリティ保護が欠如しています。攻撃者は、別のデバイスで新しい NIST P-256 楕円曲線キーを生成し、その後、デバイス キー登録 API を利用して、新しいキー ペアの生成を登録することができます。 、新しいユーザーデバイスになりすましてトランザクションを要求します。
この攻撃デバイスをフォーク攻撃と名付けます。
ZenGo ウォレットに対するデバイス フォーク攻撃
前述したように、攻撃者が資産を盗むには、ZenGo ユーザーのマスター キー②と有効なデバイス キーが必要です。
マスターキー②: マスターキー②は、双方の署名プロセスに参加するためにメモリ内の平文として使用される固定キーです。双方の署名アルゴリズムの複雑さと独自性により、このプロセスを TEE で完了することはできません。したがって、特権を持つ攻撃者は、単純にプロセス メモリをダンプしたり、特定のシステム API をハイジャックしてマスター キーを抽出する可能性があります。以下のスクリーンショットは、iOS プラットフォームで抽出できるマスター キーを示しています②。
デバイス キー: 登録またはアカウント回復プロセス中に、前述の平文抽出の脅威に対する解決策として、TEE 内のユーザーのデバイス上で有効なデバイス キーが生成されます。特権を持つ攻撃者はデバイス キーを読み取ることはできませんが、攻撃者は同じデバイス キー登録 API を使用して別のキーのペアを登録し、それを使用する可能性があります。
デバイス キー登録 API には、非常に基本的な認証メカニズムしかありません。攻撃者は、ローカルに保存された共通の平文 JWT トークンと抽出されたマスター キー ② を API 認証に使用できます。設計上、この API に関与するサーバー コードも Face tec 生体認証される必要があります。ただし、実際には、論理的な欠陥により、コードはこのステップを実行できません。
模擬攻撃では、特権を持つ攻撃者を模擬し、被害者のデバイスを継続的に監視しました。 ZenGo アプリケーションが起動するとすぐに、メモリからマスター キーを抽出し、ローカル データベースから API トークンを読み取ります。この情報は、攻撃者がユーザーの資金をすべて盗むのに十分です。
API トークンを取得したら、新しいデバイス キーを生成し、デバイス キー登録 API を呼び出してデバイス キーを ZenGo サーバーに登録します。次に、ZenGo サーバーと対話してトランザクションを開始するためのすべての API リクエストを構築しました。 MPC ウォレットの場合、双方からの署名の生成は非常に独特で複雑なプロセスです。幸いなことに、ZenGo の開発プロセスは常にオープンソースの精神を遵守してきたため、公式 ZenGo アプリケーションで使用される 2 者署名ライブラリをコンパイルし、ローカルで実行することができました。
上の画像は、被害者に代わってマスターキー②を抽出し、新しいデバイスキーを登録する方法を示しています。次に、これら 2 つのキーを使用して、0.00222 ETH を「攻撃者のアカウント」に送信しました。プロセス全体にかかる時間はわずか数秒で、被害者はまったく気づきません。
この問題を解決するために、ZenGo はデバイス登録のためにサーバー側に FaceTec 生体認証を実装しました。サーバー API レベルの回避策により、この攻撃の可能性が排除され、クライアント コードを更新する必要がありません。
要約する
CertiK による ZenGo の評価では、ユーザー資産を保護するために導入されているすべてのセキュリティ対策を徹底的に調査および監査しました。これらには、相互署名スキーム、TEE ベースのデバイス保護、アカウントの登録と回復のための生体認証が含まれます。
ZenGo はセキュリティ意識が高く、セキュリティを向上させるために多くの対策を講じてきましたが、CertiK は、ZenGo の実装に悪用可能な API アクセス認証の重要なリスクを発見しました。この脆弱性により、デバイスが侵害された場合、特権を持つ攻撃者が既存のセキュリティ対策を回避し、ユーザーの資金を盗む可能性があります。
ZenGo は直ちに問題を解決し、パッチを展開しました。その後、CeritK は徹底的なさらなる監査を実施し、レポートで言及されているリスクがパッチによって修正されたと判断しました。
パッチの展開により、ZenGo は将来、特権ユーザーがユーザーの資金に不正にアクセスすることを効果的に防止できると考えています。特権を持つ攻撃者から防御することは困難な作業ですが、ZenGo のセキュリティ実践は、ユーザーを保護するための包括的なアプローチを示しています。このウォレットは、現在市場に出ているほとんどの従来のウォレットよりも多くの機能を備えています。
私たちは ZenGo と提携できることを誇りに思っており、Web 3 ユーザーのセキュリティを保護し、セキュリティ上の課題を解決するために ZenGo と協力できることを誇りに思っています。また、私たちが発見した脆弱性に対するタイムリーな対応と効率的なパッチ適用アクションを行ってくれた ZenGo にも感謝したいと思います。
セキュリティ業界の実務家として、Web 3 ウォレットのトップ企業がセキュリティをこれほど真剣に受け止め、ユーザーとユーザーの資金に対してこれほど高い責任感を持っていることを非常にうれしく思います。私たちは、将来的には安全への道において、より多くのプロジェクトの安全性を向上させ、ユーザーに「安心」を提供できることを願っています。