ウォレットは、回復用フレーズが作成された瞬間から不安全であっても、外見上はまったく正常に見えることがあります。 これは、CryptoJSの弱いRNG脆弱性が示す理由です。 影響を受けるCryptoJSのバージョンでは、CryptoJS.lib.WordArray.random() は、暗号的に安全なプラットフォームの乱数ソースではなく、JavaScriptのMath.random()からシードされたカスタム疑似乱数構造を使用していました。 これは重要です。暗号的安全性は、ソースにおける予測不可能性に依存しているからです。 Ill Bloomの調査は、この実装上の弱点を実際のウォレット生成コードと結びつけました。脆弱な生成パス下では、128ビットおよび256ビットのウォレットエントロピーの名义的な要求が、それぞれ約2^39および2^47の検索空間に縮小する可能性がありました。 その結果として生成された回復用フレーズは、依然として以下のような特徴を示すことができます： • 有効なBIP39単語を使用する • チェックサム検証を通過する • 標準的なブロックチェーンアカウントを導出する • 有効なトランザクションに署名する • ユーザーにとってまったく普通に見える これが重要な区別です： 有効な回復用フレーズは、必ずしも安全に生成された回復用フレーズとは限りません。 もう一つ重要なニュアンスは、影響を受けるCryptoJSの依存関係を発見したからといって、ウォレットが攻撃可能であることを自動的に証明するわけではないということです。調査者は、脆弱な乱数関数が実際に回復用フレーズ、キー、トークン、ノンス、その他のセキュリティに関わる秘密情報を生成したかどうかを確立する必要があります。 CryptoJS 4.0.0では、Math.randomに基づく生成パスがネイティブな暗号的乱数メソッドに置き換えられました。しかし、ライブラリの更新は将来の生成を修正するだけで、数年前に生成された回復用フレーズに過去遡及してエントロピーを追加することはできません。 影響を受けたシードを他のソフトウェアウォレットやハードウェアウォレットにインポートしても、それ自体は修復されません。同じ基盤となるキーは依然として導出可能です。 より広範なセキュリティの教訓は、CryptoJSにとどまりません。 開発者は、パッケージ名やトップレベルの依存関係スキャンに頼るのではなく、直接的かつ伝搬的な依存関係を含む実際の秘密生成データフローを監査する必要があります。 ブラウザアプリケーションでは、Web Cryptoが暗号的に強力な乱数を提供するcrypto.getRandomValues()を公開しています。Node.jsおよびモバイル環境では、それぞれ独自の安全な暗号的乱数APIを提供しています。 ウォレットユーザーは、12語または24語のフレーズが自動的に安全であると仮定するのではなく、ソフトウェアの出所、メンテナンス履歴、生成履歴、信頼できる乱数、安全なバックアップに注目すべきです。 TokenToolHubの完全な分析をご覧ください： https://t.co/2AjB3PrKIZ