ログイン/ 登録

a16z: 秘密鍵は繰り返し侵害されましたか? Web3 セキュリティはウォレットから始める必要があります

2022/10/19 18:07

従う

個人は自分の秘密鍵 (および暗号資産) を直接かつ単独で管理 (および所有権) します。この哲学に従う暗号ウォレットは「非保管」ウォレットとして知られており、部外者が鍵にアクセスできないことを意味します。

一連の「非保管」ウォレットハッキング事件が起こるまで - 9月 Wintermute秘密鍵が「総当たり」で1億6000万ドル損失、8月 Slopeウォレットハッカーが8,000以上のアカウントに侵入、2020年 Trinityで200万ドル以上のIOTAウォレットハッキング、2017年に15万ETHを盗んだパリティウォレットのハッキング、およびさまざまなハードウェアウォレットの脆弱性により、保管ウォレットと非保管ウォレットの間のセキュリティの境界があいまいになっています。このような場合、被害者は非保管ウォレットを使用していると信じ込んでしまい、その後秘密鍵が盗まれていたことに気づきます。

実際、ウォレットは通常、他人のハードウェアとソフトウェアによって作成および実行されるため、非保管ウォレットではユーザーが自分のキーを完全に制御できるわけではありません。ユーザーはサードパーティ製品をますます信頼しています。これらの製品は、ブロックチェーンコマンドラインインターフェイス、ウォレットソフトウェアとデバイス、集中プラットフォーム、スマートコントラクトコード、分散アプリケーションを統合または使用しており、各タッチポイントがリスクを高めます。これらすべての結合ポイントは、人々が「管理されていない」という概念について抱いているバラ色の幻想を粉砕することになります。

「非管理対象」とは、実際には多くの管理対象要素を指す場合があります。

一般に、キー管理 (ウォレットのセキュリティの基礎) は 3 つの方向に分けることができます。

キーの生成 (暗号化キーの作成)。
キーの保管 (保管中のキーを保護);
キーの使用法 (キー認証を使用)。

各方向には固有のリスクポイントがあります。

この記事では、暗号化されたウォレットのセキュリティとカストディプラットフォームの特徴と欠点を紹介し、今後最も注意と開発が必要な領域について取り上げ、Web3 ユーザーが非カストディの方法で暗号化資産を保護する複雑さをよりよく理解できるようにすることを目的としています。。さらに、エンジニアがウォレット開発における一般的な障害点を特定して回避できるように支援し、Docker、Anchorage、Facebook、および a16z 暗号化システムにおける長年にわたる包括的な経験を活用して、ユーザーとプロジェクト関係者がセキュリティインシデントを回避できるようにしたいと考えています。

鍵の生成

鍵生成ステップのセキュリティは非常に重要です。この段階では、信頼性の高いコードを使用すること、コードを正しく実装すること、出力を安全に処理することという 3 つの重要な問題に留意する必要があります。

一部のウォレットプロバイダーが公式 Web サイトまたは Github リポジトリで公開している監査レポート。独自の調査を行って、ウォレットの背後に評判の良い会社があるかどうかを判断してください。情報が不足している場合は、ユーザーと開発者の重要なアクティビティが有用な指標となる可能性があります。

リスクを軽減するには、次のガイドラインに従ってください。あなたの財布が次のチェックに失敗した場合は、逃げてください。

十分な期間テストされていないウォレットは使用しないでください

ウォレットを構成するコードは評判が良い必要があります。不適切に作成されたソフトウェアを選択したり、独自の代替ソフトウェアを開発しようとすると、キーの漏洩や権限のない者への機密情報の開示などの「壊滅的な事態」につながる可能性があります。

複数の保険を備えたウォレットを使用する

コードで評判の良い暗号ライブラリを使用している場合でも、それを適切に統合する必要があります。監査対象のソフトウェアは多くの場合、デフォルトで正しいパラメータを設定しますが、実行中にバグが発生する可能性があります。多くのマルチパーティ計算（MPC）アルゴリズムなどの特定のキー生成プロセスでは、多くの個別のキー（またはキーのフラグメント、キーのフラグメント）を生成および調整する必要があり、ウォレットはアルゴリズムで指定されたプロトコルに従う必要があります。また、アルゴリズムでは複数回の計算とキーの更新が必要になる場合があり、資金の安全性を維持するためにウォレットによって適切に統合される必要があります。

「秘密を守る」ウォレットを使用する

キー生成プロセスの最終段階には、ソフトウェアの実際の操作と出力が含まれます。キーがどこでどのような形式で生成されるかに注意してください。理想的には、キーは独立したハードウェアで生成され、情報は信頼できるアルゴリズムを使用して暗号化される必要があります。

今夏ハッキングされたSlopeウォレットの鍵は、外部サーバーに平文でログインするために生成されていた。この種のセキュリティホールは、コードの監査やオープンソースの実装で発生する可能性があります。ウォレットの透明性の欠如 – クローズドなソースコードと一般公開されているサードパーティのセキュリティ監査がないことが特徴であり、警戒を呼び起こす必要があります。

キーストレージ

キーが生成された後は、どこかに隠す必要があります (平文ではなく、常に暗号化してください)。ただし、キーを保存するデバイスを単に所有しているだけでは、キーの所有権と管理が必ずしも一致するとは限りません。デバイスのサプライチェーンのセキュリティ、デバイスの接続方法、デバイスが相互作用する他のコンポーネントなど、多くの要素を考慮する必要があります。さらに、各ストレージ方法には、セキュリティ、アクセシビリティ、保守性、可用性の間に独自のトレードオフがあります。

以下に、最も一般的なウォレットのセキュリティカテゴリを、関連する既知のリスクレベルに応じて分類しました。

高リスク: ホットウォレット

他のすべてが同じであれば、コールドウォレットはホットウォレットよりも安全ですが、使用するのも難しくなります。ネットワークに接続されているウォレットは、攻撃者に脆弱性を見つけて悪用する機会が増えるため、ハッキングされる可能性が高くなります。

ホットウォレットネットワーキングには 2 つの形式があります。

接続ソフトウェア: オンラインデータベースまたは Web サーバーアプリケーションメモリ、ブラウザ拡張機能

これらは最も高いリスクです。なぜなら、ウォレットソフトウェアは、ホストされているかどうかに関係なく、キーに直接アクセスでき、キーはすべて外部のインターネットに接続されているからです。理想的には、キーは暗号化され、その暗号化に使用される他のキーのセットは、オペレーティングシステムのキーチェーンやクラウドキー管理システムなど、高度に制限されたアクセス制御を備えた専用のキー管理システム (KMS) に保存される必要があります。

接続されたハードウェア: 専用アプライアンス、モバイルセキュアエンクレーブ、インラインハードウェアセキュリティモジュール (HSM)

一般に、接続されたハードウェアは、接続されたソフトウェアよりもリスクが低いと考えられていますが、それでもコールドストレージほど安全ではありません。接続されたハードウェアでは、キーは専用のハードウェアデバイスでのみ生成されます。これらは内部ネットワークまたはパブリックネットワークに接続できます。このようなデバイスは通常、キーの生成、署名、ストレージのセキュリティなど、キー管理に関連する複数の責任を負います。

TrezorやLedgerなどのハードウェアウォレットもあります。ハードウェアセキュリティモジュール (HSM) もあり、クレジットカード支払いなどの機密データ処理を処理するなど、より従来のビジネス環境でよく使用されます。

デバイスの安全性は、それを製造および構成するサプライチェーンによって決まります。ハードウェアの接続を検討する場合は、信頼できるサプライヤーから機器を直接購入するのが最善です。産地から直接発送されますので、パッケージに損傷がないことを確認してください。使用前にファームウェアのバージョンや構成を確認することも可能です。

もちろん、ハードウェアウォレットが後で盗まれたり、権限のない者によってアクセスされたりする可能性は常にあります。これらの脅威を考慮すると、ハードウェアウォレットにもアクセス制御の安全な層、つまりあらゆるトランザクションに盲目的に署名しないようにするための保護手段が備わっていることを確認することが重要です。コントロールには、パスワード要件、トランザクションの各ステップで明示的な許可を求めるプロンプト、トランザクションの実際の操作を説明する簡単な概要を含めることができます。さらに、ほとんどのハードウェアウォレットは、「キーラッピング」とも呼ばれる秘密キー暗号化をサポートしています。

リスクが少ない: コールドウォレット

他のすべてが同じであれば、コールドウォレットは一般的にホットウォレットよりも安全であると考えられていますが、一般に使いやすさもそれほど簡単ではありません。コールドウォレットは、内部ネットワークやパブリックネットワークには接続されません。

コールドウォレットのオプションをいくつか確認してみましょう。

オフラインソフトウェア: オフラインサーバーアプリケーション

攻撃者はいつでもマシンを盗んだり、オンラインに持ち込むことができるため、コールドウォレットはオンライン中に安全になるように設計する必要があります。 HSM などの専用ハードウェアは、通常、ソフトウェアを接続するよりも多くの制御を提供するため、強くお勧めします。

オフラインハードウェア: オフラインハードウェアウォレット、オフラインハードウェアセキュリティモジュール (HSM)

この解決策は最も安全であると考えられています。前のカテゴリと同様に、ハードウェアはオンラインで盗まれて入手できる可能性があると想定する必要があります。したがって、前述したように、これらのシステムには、適切に実装されたアクセス制御層が含まれている必要があります。多くの HSM ベンダーは、キーアクセスのロックを解除する前に、一定数の物理スマートカードをまとめることを要求しています。デバイスに表示画面がない場合でも、ユーザーが取引の詳細を確認する何らかの方法を提供する必要があります。

コールドウォレットまたはオフラインウォレットは最も安全なカテゴリであるため、Coinbase、Gemini、Kraken など、および Anchorage などの大企業によって管理されるほとんどの資金はこの方法で保存されます。これらのプレイヤーの多くは、アクセスを失ったり、マシンが損傷、盗難、破壊された場合に備えて、バックアップとリカバリという別の防御線も選択します。

バックアップと復元

署名キーは暗号化後にバックアップする必要があります。暗号署名キーとキーラッピングキーを繰り返すことが重要です。署名キーをバックアップする方法はさまざまですが、常にハードウェアネイティブのソリューションを選択する必要があります。

ハードウェアウォレットの場合、バックアップには通常、秘密キーの派生元となるプレーンテキストシードが含まれます。標準の暗号化キーには、デフォルトでアクセス制御を使用して暗号化されたキーを導出できるメカニズムが備わっています。アクセス制御が満たされている場合は、キーを他の HSM にインポートできます。多数の HSM は、スマートカードのクォーラムから派生した共通の暗号化キーを提供することもできます。この方法でハードウェアを重要なマテリアルから分離すると、単一点障害を回避できます。

最後に、考慮すべき人的要因があります。回復メカニズムは、アカウント管理業務に関与する個人が一時的または永続的に利用できなくなった場合に耐えることができる必要があります。各個人は、停電やその他の緊急事態が発生した場合に鍵を取得できる方法を確保する必要があります。同時に、グループ活動では、緊急時に活動を継続できる人数を決定する必要があります。

キーの使用法

キーが生成され、保存された後、それらのキーを使用して、トランザクションを承認するデジタル署名を作成できます。ソフトウェアとハードウェアの組み合わせが増えるほど、リスクも大きくなります。リスクを軽減するために、ウォレットは次の認可と認証のガイドラインに従う必要があります。

信頼するだけでなく、検証もする

ウォレットには検証が必要です。言い換えれば、ユーザーの身元が確認され、許可された当事者のみがウォレットの内容にアクセスできる必要があります。ここでの最も一般的なセキュリティ対策は、PIN コードまたはパスフレーズです。より高度な認証形式には、他の複数のセキュリティデバイスからの暗号署名など、公開キー暗号化に基づく生体認証や承認が含まれる場合があります。

十分な期間テストされていないウォレットは使用しないでください

ウォレットは健全な暗号化ライブラリを使用する必要があります。キーマテリアルの漏洩や秘密キーの完全な損失を避けるために、キーマテリアルが監査され、安全であることを確認するために調査を行ってください。問題をさらに悪化させるのは、最近の Ed25519 ライブラリの場合のように、信頼できるライブラリであっても安全でないインターフェイスを持つ可能性があることです。

ナンスの再利用

よく研究されているキー使用の落とし穴は、特定の暗号化署名パラメータの意図しない再利用です。一部の署名スキームでは、システム内で 1 回のみ使用されることを意図した 1 回限りの意味、つまり「1 回だけ使用される番号」(任意の番号) が必要な場合があります。したがって、サウンド暗号化ライブラリを使用していることを確認してください。しかし、この攻撃ベクトルは、2010 年の Sony PlayStation 3 ハッキングなど、Web3 以外の注目度の高いハッキングでも悪用されています。

1 つのキーで 1 回の使用

もう 1 つのベストプラクティスは、同じキーを複数の目的で再利用しないようにすることです。たとえば、暗号化と署名用に別のキーを保持する必要があります。これは、侵害された状況における「最小特権」の原則に従います。つまり、資産、情報、または操作へのアクセスは、システムが動作するために絶対に必要な関係者またはコードのみに制限される必要があります。使用法に応じて、キーごとにバックアップとアクセス管理の要件が異なります。 Web3 エコシステムでは、1 つのアカウントの侵害が他のアカウントに影響を与えないように、アセットとウォレットの間でキーとシードフレーズを分離することがベストプラクティスです。

要約する

キーの管理は、生成から保管、使用までの多くの相互作用する部分と段階を伴う厄介な問題です。キーの所有権の保管性または非保管性は、一般通念のように白か黒かが分かれるものではありません。鍵の生成から保管、使用まで、鍵管理には多くの変動部分が関与するため、状況は複雑になります。チェーン上のハードウェアやソフトウェアのすべてがリスクをもたらし、本来は保管ウォレットの一部ではないオプションも保管リスクにさらされます。

将来的には、ウォレットを攻撃から保護し、上記のリスクを軽減するために、さらに開発作業を行っていきたいと考えています。改善の余地がある領域は次のとおりです。