BitGoが情報漏洩を否定、Unocoinは不正なウォレット送金を調査中

BitGoは、インドの暗号資産取引所Unocoinに影響を与えたセキュリティインシデントにおいて、自社システムへの侵入がなかったと述べている。同取引所のサービスは現在も停止中である。このカストディアンは、問題の送金がBitGoではなくUnocoin自身が保有する2つのキーで署名されたと説明した。

11月13日の声明でBitGoは、Unocoinが3つの署名キーのうち2つを必要とするセルフカストディ型ウォレット体制を運用していたと説明した。Unocoinがユーザーキーとバックアップキーを保有し、BitGoが残りの1つを保有していた。BitGoの調査によると、問題の送金はUnocoinが保有する2つのキーで署名され、BitGoの関与なしに直接オンチェーンでブロードキャストされたという。

「BitGoのキーは一切使用されていない」と同社は述べた。また、他の顧客への影響はないと付け加え、顧客資産に関する質問はUnocoinに向けるよう求めた。

問題の送金にBitGoのキーが一切必要とされなかったことから、この事案は、キー共有型カストディが取引所とインフラ提供者との間で責任をどう分担するかを浮き彫りにしており、取引所自身の運用セキュリティが現在、中心的な未解決問題となっている。

バックアップメカニズムが焦点に

Unocoinは11月13日独自のインシデント更新情報の中で、取引がBitGoのプラットフォーム外で署名・ブロードキャストされたことを認めた。同取引所は、BitGoが利用不能になった場合に資産へのアクセスを維持するために設計されたバックアップメカニズムが悪用された可能性があると述べた。同社はこのメカニズムに加え、潜在的な暗号資産損失と情報プライバシーの問題についても調査している。

このようなフォールバック署名経路は、キー共有型カストディ設計の標準的な機能であり、提供者が利用不能になった場合でも顧客が資産に独自にアクセスできる道を確保する。

11月6日の凍結が対象としたもの

Unocoinは11月6日に不審なアクティビティを最初に検知し、日々の取引に使用される残高を保有していたBitGoとFireblocksの法人アカウントの凍結を要請したと述べた。同取引所によると、両提供者は各プラットフォームからこれ以上の取引を開始できないことを確認した。BitGoは11月6日の凍結は「意図したとおり機能した」と述べた。

同取引所は11月12日、BitGoウォレットインフラ内のイーサリアムアドレスからの送金を発見したと述べた。これは発見日であり、送金の実行時刻については両社の声明とも特定していない。

BitGoのウォレット文書によると、通常の取引ではユーザーキーとBitGoキーを使用するが、バックアップキーは残りの2つのキーのいずれかと組み合わせて使用できる。そのリカバリー手順では、BitGoのサービスを使用せずに取引へ署名・ブロードキャストする方法が説明されている。この体制では、BitGoプラットフォームへのアクセスを凍結しても、顧客が自らの2つのキーで署名する能力は失われない。この区別が、BitGoの関与なしに送金が発生しうる仕組みを説明しているが、誰がキーを使用したのか、損失の責任は誰にあるのかは明らかになっていない。

顧客資産は引き続き調査中

Unocoinは11月9日に不正なサーバーアクセスを開示し、顧客のログインを無効化した上で、当時は暗号資産の損失はないと述べた。その後のインシデント告知では、同日にさらなる不正なアクティビティを検知した後に全サービスを停止し、インフラが侵害されたと確認したという。

同取引所は11月13日も「ユーザーの資金が失われたことはなく、資産は安全に保管されています」とユーザーに伝え続けた。しかしインシデント告知では、暗号資産の損失の調査と保有状況の確認がまだ進行中であるとしている。Unocoinは顧客の暗号資産の90%超がオフラインのコールドストレージに保管されており、署名キーがインターネット接続システムから隔離されていると述べた。告知では確定した損失額は示されていない。

オンチェーン分析プラットフォームArkham上のUnocoinエンティティページの11月12日のスナップショットでは、「価格付けされたトークンの保有がない」8万986件の関連アドレスが表示された。このスナップショットだけでは、窃取の発生、残高の変動時期、あるいはそのアドレス群以外にUnocoinが資産を保有しているかどうかは確認できない。また、アドレス数は影響を受けた顧客数を示すものでもない。

11月13日、Unocoinのウェブサイトにはメンテナンス告知が表示された。同取引所はサーバーインフラの再構築に4〜5営業日を要し、サービス再開前にセキュリティチェックが必要であると見込んでいる。サービス復旧後に引き出しを再開し、保留中のリクエストを処理するとしているが、具体的な再開日程は示されていない。それまでの間、開示情報には注視すべき明確なポイントが残されている。確定した損失額、問題の送金の実行時刻と実行者、そしてサービス再開の確定日付である。