Upgrade to Pro — share decks privately, control downloads, hide ads and more …

暗号資産取引所のアーキテクチャとセキュリティ

coincheck
February 15, 2023

 暗号資産取引所のアーキテクチャとセキュリティ

皆さんは暗号資産取引所のアーキテクチャにご興味がありますか?
いろいろな方とお話しさせていただくと、暗号資産取引所で働くにはブロックチェーンの知識が必須そう、という印象を持たれているが多くいらっしゃいます。
そこで、「当社のCoincheckサービスを例に暗号資産取引所がどういったアーキテクチャをしているのか」、「どういったポイントでブロックチェーンの技術が求められるのか」、「暗号資産取引所のセキュリティ対策としてどういったことが求められるのか」をご紹介したいと思います。

※Developers Summit2023 9-C-7「喜屋武 慶大」の登壇資料です。

coincheck

February 15, 2023
Tweet

More Decks by coincheck

Other Decks in Technology

Transcript

  1. ©2023 Coincheck Inc. 2 自己紹介 喜屋武 慶大 名前 趣味 経歴 ドライブ

    / 温泉 / カメラ / 美味しいもの巡り 2015 ~ セキュリティベンダの SOC でセキュ リティアナリストとして勤務 2018 ~ コインチェッ 株式会社入社、セキュ リティの監視の構築や運用及びアーキテ ト、インシデント対応等に従事
  2. ©2023 Coincheck Inc. 5 会社紹介 Coinceckの強み 顧客基盤 使いやすいUI/UX 18通貨 取り扱い通貨数

    エンジニア数60人 システムの内製化 540万 アプリダウンロード数 4年連続国内No1* 178万 本人確認済み口座数** 2,689 億円 預かり資産** *対象:国内の暗号資産取引アプリ、期間:2019年〜2022年、データ協力:AppTweak **2023年1月末時点
  3. ©2023 Coincheck Inc. 10 一定の条件に従ってひとつまたは複数の取引をまとめたものをブロッ と呼称し、連続した次のブロッ に前 のブロッ のハッシュ値が記録されることによって複数のブロッ がひとつのデータベースとなる技術

    ブロックチェーン概要 ブロックチェーンとは Block1 Header Block2 Header Block3 Header 前のブロッ のハッ シュ値 前のブロッ のハッ シュ値 前のブロッ のハッ シュ値
  4. ©2023 Coincheck Inc. 11 一言で「ブロッ チェーン」と言っても、実際にはいくつものブロッ を生成する仕組みと異なるチェーンと がある ブロッ を生成・承認する仕組み(コンセンサスアルゴリズム)としては代表的なものとして、Proof

    of Work と Proof of Stake があり、どちらを採用しているかは、各チェーンによって異なる ブロックチェーン概要 具体的な実装・採用している暗号技術はチェーンによってさまざま Proof of Work Proof of Stake
  5. ©2023 Coincheck Inc. 12 ブロックチェーン概要 コンセンサスアルゴリズムの種類 • Proof of Work

    ◦ マイニン によって追加されるブロッ が特定の条件を満たすことで新しいブロッ が承認される • Proof of Stake ◦ 一定量以上の暗号資産をステー する(賭ける)ことによってステー した人の中からランダムにブ ロッ を生成することができる人が選ばれる • Proof of Consensus ◦ あらかじめ選ばれた一部の者のみがブロッ の承認ができる その他にも Proof of Importance や Delegated Proof of Stake など様々なコンセンサスアルゴリズムがある
  6. ©2023 Coincheck Inc. 18 暗号資産取引所のアーキテクチャ 何故オフチェーンなのか • ビットコインを例にすると、約10分で1ブロッ が生成され、理論上は1秒間に7トランザ ションが処理できる

    ◦ これはCoincheck単独ではなくビットコインネットワー の全て取引が対象 • 一方Coincheckサービス内だけでも取引量(約定)は秒間で60件以上ある • 全ての取引をブロッ チェーン上に書き込むのは間に合わないため、アドレス間の暗号資産の移 転のみブロッ チェーン上に書き込み、サービス内での取引はDBに書き込む
  7. ©2023 Coincheck Inc. • ノードとは各チェーンで他人が運用しているノードと同期して最新のブロッ チェーンのブロッ データを取得したり、自社の発行したトランザ ションを他のノードにブロードキャストする ソフトウェア •

    他の取引所等のアドレスから自社のアドレスへの入金を検知してユーザの残高に反映させたりす る ブロッ チェーンの同期 トランザ ションのブロードキャスト 20 暗号資産取引所のアーキテクチャ ノードの運用と暗号資産の署名周りは各チェーン特有の知識を求められる
  8. ©2023 Coincheck Inc. 21 暗号資産取引所のアーキテクチャ ノードの運用と暗号資産の署名周りは各チェーン特有の知識を求められる • ブロッ チェーンと言ってもトランザ ションやブロッ

    のデータ構造は各チェーンによって異 なる • 暗号資産の署名やブロッ チェーン上の入出金を検知してユーザの残高に反映させるには、各 チェーンのブロッ やトランザ ションのデータ構造を理解してどのユーザ宛の入金なのかを正 しく判定すると共に、自社から他のアドレスへ送金する際も正確なトランザ ションを構築しな ければならない
  9. ©2023 Coincheck Inc. 26 暗号資産取引所のセキュリティ 筆者の理解 「耐改ざん性」という一面においては強い ブロッ チェーンのデータを過去に遡って改ざんするには、Proof of

    Work においては当該チェーン全体の 51%以上の計算能力が必要になり、Proof of Stake では ステー された量の51%以上のトー ンを攻撃者が ステー しなければならない
  10. ©2023 Coincheck Inc. 27 暗号資産取引所のセキュリティ チェーン・トークンのセキュリティ ブロッ チェーンもソフトウェアなので、ソフトウェアとしてのバ や脆弱性は潜在する 実際、ブロッ

    チェーン上に実装されたアプリ ーションにバ があったため秘密鍵がなくても暗号資産が流 出してしまった例はあり、こうした ースは取引所がいくらセキュリティ対策をしても意味がない 出典: https://xtech.nikkei.com/it/atcl/column/14/377135/062000008/
  11. ©2023 Coincheck Inc. 29 暗号資産取引所のセキュリティ コーポレートセキュリティ ブロッ チェーン特有のセキュリティ対策をやる前に通常のコーポレートITのセキュリティ対策もやる必要が ある •

    端末へのAV/EDR製品の導入によるマルウェア感染の検知 • CASB製品を用いた通信内容のモニタリン • MDMを用いた端末のセキュリティポリシーの適用 • IDaaSを用いた認証/認可のポリシーの適用 • 社内システムの管理者権限の運用ルールの策定
  12. ©2023 Coincheck Inc. 30 暗号資産取引所のセキュリティ 暗号資産取引所への攻撃に関する多数のレポートで、攻撃者がシステムへ侵入する糸口としてソーシャル ハッキン やスピアフィッシン を用いた手法が多い 出典:

    https://www.npa.go.jp/cyber/pdf/R041014_cyber_alert.pdf 出典: https://www.sentinelone.com/blog/lazarus-operation-interception-targets-m acos-users-dreaming-of-jobs-in-crypto/ コーポレートセキュリティ
  13. ©2023 Coincheck Inc. 31 暗号資産取引所のセキュリティ ブロックチェーン全体のセキュリティのレイヤ • チェーン・トー ンのセキュリティ •

    暗号資産取引所のコーポレートセキュリティ • 暗号資産取引所のサービスのセキュリティ
  14. ©2023 Coincheck Inc. 32 暗号資産取引所のセキュリティ サービスのセキュリティ 一般的なWebサービス同様、Webアプリ ーションやモバイルアプリ ーションの脆弱性対策も必要である •

    IAMの権限管理 • Web Application Firewall • DDoS対策 • 依存パッ ージの脆弱性管理 • 脆弱性診断 • 送金/出金時の認証 • フィッシン サイトのテイ ダウン
  15. ©2023 Coincheck Inc. 33 暗号資産取引所のセキュリティ 秘密鍵が守れていれば安全か? • 暗号資産取引所のセキュリティの話になるとトランザ ションの署名に使用する秘密鍵の管理に関する話 が多数である

    • では、本当に秘密鍵さえ守れていれば安全なのか? • 秘密鍵を盗まなくても暗号資産を盗むことが可能な攻撃シナリオを想定し、脆弱性の対策や管理、アーキ テ チャレベルでセキュリティ対策を考える必要があることを紹介する ここからは、Coincheckのシステム構成を前提とせずに、暗号資産取引所で攻撃シナリ オを考えた場合の話になる
  16. ©2023 Coincheck Inc. 35 暗号資産取引所のセキュリティ 署名システムがアプリ ーションサーバが発行したトランザ ションをそのまま署名してブロードキャストす るような仕組みだった場合、アプリ ーションサーバを乗っ取ることができれば不正なトランザ

    ションを発 行して署名リ エストを送ることが可能 署名システムで署名する際やブロードキャストする前に署名リ エストの内容が不正なものでないかチェッ する機能が必要 Exploit 不正なトランザ ションの発行 ブロードキャスト 署名システム 秘密鍵が守れていれば安全か?
  17. ©2023 Coincheck Inc. 36 暗号資産取引所のセキュリティ 攻撃者がサービスのネットワー 内に侵入し、不正なProxyサーバを建てて通信内容を中継可能かつ通信内容 が平文だった場合は、署名リ エストやトランザ ションデータの内容を改ざんして送金先アドレスや送金す

    る量を改ざんできるので通信の暗号化や前述と同様に署名する前やブロードキャストする前に不正なものでな いかチェッ する機能が重要 トランザ ションデータ・署名リ エストの改ざん ブロードキャスト 署名システム 不正なProxyサーバ 秘密鍵が守れていれば安全か?
  18. ©2023 Coincheck Inc. 署名ネットワー DMZ 37 暗号資産取引所のセキュリティ アプリ ーションサーバと署名システムが同一ネットワー 上にある場合、攻撃者はアプリ

    ーションサーバ を経由して署名システムへ攻撃が可能なのでアプリ ーションサーバと署名システムはネットワー を分ける ことも重要 そうした場合はどうやってユーザの送金リ エストを署名サーバに伝えるか考える必要がある Exploit 署名システム 秘密鍵が守れていれば安全か? ブロードキャスト
  19. ©2023 Coincheck Inc. 40 暗号資産取引所のセキュリティ マルチシグネチャにしていれば安全か? 複数サーバに分散したとしても同一ネットワー 、同一構成なら同じ攻撃手法で乗っ取ることができるので難 易度は変わらない Exploit

    • どちらか一台を乗っ取ることができれば、同じ攻撃手法 でもう一台も乗っ取ることができる Exploit • 同一構成 ◦ 同じOS ◦ 同じアプリ ーション
  20. ©2023 Coincheck Inc. 41 暗号資産取引所のセキュリティ マルチシグネチャにしていれば安全か? 異なるOS、異なるアプリ ーションにすればいいかと言われると運用コストが・・・ • 異なるOS

    • 異なるアプリ ーション • 異なるソースコード • 構成管理 • パッチ適用 • EOL • メンテナンス 正解はなく、各社のソフトウェアエンジニアの数や質によって自分達にとって最適な解を考えなければならない
  21. ©2023 Coincheck Inc. 43 暗号資産取引所のセキュリティ ColdWalletから暗号資産を移転する場合の運用も考えなければならない CGTF(Cryptoassets Governance Task Force)のモデルをベースとして考えた場合に

    • 誰(部署、役職)が移転指示を出したり実際の署名作業を行うのか。その際に移転する暗号資産やその数量、送金先のアドレス の正しさはどのようにして担保されているのか • 署名する際に生の秘密鍵に触れる、もしくは閲覧できてしまうのか • 署名されたトランザ ションが移転指示の内容と一致するものであることをどのタイミン で検証して、その正しさを担保する のか • etc… 出典:https://cgtf.github.io/publications/20220323/custodiandocument_ver3.pdf
  22. ©2023 Coincheck Inc. 48 まとめ • ブロッ チェーン、と一言で言っても実際の仕様や実装は各チェーンで異なる • オンチェーン、オフチェーンといった仕組みがありほとんどの取引所がオフチェーンの仕組みを採用して

    いる • 秘密鍵の奪取だけが暗号資産の流出リス ではない、それ以外のセキュリティ対策もしっかり考える必要 がある • コールドウォレットも移転のプロセス、オペレーションまでの全体を考えなければならない • システム的なセキュリティだけでなくフィッシン 対策やDDoS攻撃対策などユーザーの保護や安定稼働に も取り組む必要がある