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

©2023 Coincheck Inc.
暗号資産取引所のアーキテクチャとセキュリティ
Developers Summit 2023
コインチェック株式会社
サイバーセキュリティ推進部　喜屋武慶大

View Slide

2
自己紹介
喜屋武　慶大
名前
趣味
経歴
ドライブ / 温泉 / カメラ / 美味しいもの巡り
2015 ~ セキュリティベンダの SOC でセキュ
リティアナリストとして勤務
2018 ~ コインチェッ株式会社入社、セキュ
リティの監視の構築や運用及びアーキテ
ト、インシデント対応等に従事

View Slide

3
会社紹介
ミッション

View Slide

4
会社紹介
主要サービス

View Slide

5
会社紹介
Coinceckの強み顧客基盤
使いやすいUI/UX
18通貨取り扱い通貨数
エンジニア数60人システムの内製化
540万
アプリダウンロード数
4年連続国内No1*
178万本人確認済み口座数**
2,689
億円
預かり資産**
*対象：国内の暗号資産取引アプリ、期間：2019年〜2022年、データ協力：AppTweak
**2023年1月末時点

View Slide

6
会社紹介
新規事業として、B2B SaaSであるバーチャル株主総会支援事業を開始
Sharely（シェアリー）導入企業例
2021年9月より提供を開始

View Slide

7
本日のテーマ
暗号資産取引所のアーキテクチャとセキュリティについていい感じに解説する

View Slide

ブロックチェーン概要暗号資産取引所のアーキテクチャ
暗号資産取引所とセキュリティまとめ
AGENDA
01 02
04
03

View Slide

9
ブロックチェーン概要

View Slide

10
一定の条件に従ってひとつまたは複数の取引をまとめたものをブロッと呼称し、連続した次のブロッに前
のブロッのハッシュ値が記録されることによって複数のブロッがひとつのデータベースとなる技術
ブロックチェーンとは
Block1 Header Block2 Header Block3 Header
前のブロッのハッ
シュ値
シュ値
シュ値

View Slide

11
一言で「ブロッチェーン」と言っても、実際にはいくつものブロッを生成する仕組みと異なるチェーンと
がある
ブロッを生成・承認する仕組み（コンセンサスアルゴリズム）としては代表的なものとして、Proof of
Work と Proof of Stake があり、どちらを採用しているかは、各チェーンによって異なる
具体的な実装・採用している暗号技術はチェーンによってさまざま
Proof of Work Proof of Stake

View Slide

12
コンセンサスアルゴリズムの種類
● Proof of Work
○ マイニンによって追加されるブロッが特定の条件を満たすことで新しいブロッが承認される
● Proof of Stake
○ 一定量以上の暗号資産をステーする（賭ける）ことによってステーした人の中からランダムにブ
ロッを生成することができる人が選ばれる
● Proof of Consensus
○ あらかじめ選ばれた一部の者のみがブロッの承認ができる
その他にも Proof of Importance や Delegated Proof of Stake など様々なコンセンサスアルゴリズムがある

View Slide

15
暗号資産取引所のアーキテクチャ

View Slide

16
暗号資産取引所のアーキテチャとして大別するとオフチェーンとオンチェーンの２パターンがある。
オフチェーンはユーザーの暗号資産の取引はDB上に記録されており、ブロッチェーンに直接記録される訳で
はない。
オフチェーン
ユーザーの取引はDB上に記録
される
オンチェーン
ユーザーの取引はブロッ
チェーン上に記録される

View Slide

17
Coincheckはオフチェーンの仕組みを採用している
● Coinchekサービス内での取引は全てデータベース上に記録される
● ユーザがCoincheckから他の取引所や自身の管理するアドレス等に暗号資
産を移転する際にCoinchekのアドレスから当該アドレスへ送金するトラン
ザションを生成している

View Slide

18
何故オフチェーンなのか
● ビットコインを例にすると、約10分で1ブロッが生成され、理論上は1秒間に7トランザ
ションが処理できる
○ これはCoincheck単独ではなくビットコインネットワーの全て取引が対象
● 一方Coincheckサービス内だけでも取引量（約定）は秒間で60件以上ある
● 全ての取引をブロッチェーン上に書き込むのは間に合わないため、アドレス間の暗号資産の移
転のみブロッチェーン上に書き込み、サービス内での取引はDBに書き込む

View Slide

19
基本的な技術スタックは一般的なWebサービスと変わらない
バッエンドフロントエンドインフラ

View Slide

● ノードとは各チェーンで他人が運用しているノードと同期して最新のブロッチェーンのブロッ
データを取得したり、自社の発行したトランザションを他のノードにブロードキャストする
ソフトウェア
● 他の取引所等のアドレスから自社のアドレスへの入金を検知してユーザの残高に反映させたりす
る
ブロッチェーンの同期
トランザションのブロードキャスト
20
ノードの運用と暗号資産の署名周りは各チェーン特有の知識を求められる

View Slide

21
ノードの運用と暗号資産の署名周りは各チェーン特有の知識を求められる
● ブロッチェーンと言ってもトランザションやブロッのデータ構造は各チェーンによって異
なる
● 暗号資産の署名やブロッチェーン上の入出金を検知してユーザの残高に反映させるには、各
チェーンのブロッやトランザションのデータ構造を理解してどのユーザ宛の入金なのかを正
しく判定すると共に、自社から他のアドレスへ送金する際も正確なトランザションを構築しな
ければならない

View Slide

22
全体像
売買、入出金をDB上に記録する
ブロッチェーン上の入金の検知
署名されたトランザションの
ブロードキャスト
ユーザ宛の入金を判定する
署名リエスト

View Slide

23
暗号資産取引所のセキュリティ

View Slide

24
暗号資産取引所として全体のセキュリティのレイヤ
● チェーン・トーンのセキュリティ
● 暗号資産取引所のコーポレートセキュリティ
● 暗号資産取引所のサービスセキュリティ

View Slide

25
「ブロックチェーンはセキュリティが高い」は本当か？

View Slide

26
筆者の理解
「耐改ざん性」という一面においては強い
ブロッチェーンのデータを過去に遡って改ざんするには、Proof of Work においては当該チェーン全体の
51%以上の計算能力が必要になり、Proof of Stake ではステーされた量の51%以上のトーンを攻撃者が
ステーしなければならない

View Slide

27
チェーン・トークンのセキュリティ
ブロッチェーンもソフトウェアなので、ソフトウェアとしてのバや脆弱性は潜在する
実際、ブロッチェーン上に実装されたアプリーションにバがあったため秘密鍵がなくても暗号資産が流
出してしまった例はあり、こうしたースは取引所がいくらセキュリティ対策をしても意味がない
出典: https://xtech.nikkei.com/it/atcl/column/14/377135/062000008/

View Slide

28
ブロックチェーン全体のセキュリティのレイヤ
● 暗号資産取引所のサービスセキュリティ

View Slide

29
コーポレートセキュリティ
ブロッチェーン特有のセキュリティ対策をやる前に通常のコーポレートITのセキュリティ対策もやる必要が
ある
● 端末へのAV/EDR製品の導入によるマルウェア感染の検知
● CASB製品を用いた通信内容のモニタリン
● MDMを用いた端末のセキュリティポリシーの適用
● IDaaSを用いた認証/認可のポリシーの適用
● 社内システムの管理者権限の運用ルールの策定

View Slide

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/
コーポレートセキュリティ

View Slide

31
ブロックチェーン全体のセキュリティのレイヤ
● 暗号資産取引所のサービスのセキュリティ

View Slide

32
サービスのセキュリティ
一般的なWebサービス同様、Webアプリーションやモバイルアプリーションの脆弱性対策も必要である
● IAMの権限管理
● Web Application Firewall
● DDoS対策
● 依存パッージの脆弱性管理
● 脆弱性診断
● 送金/出金時の認証
● フィッシンサイトのテイダウン

View Slide

33
秘密鍵が守れていれば安全か？
● 暗号資産取引所のセキュリティの話になるとトランザションの署名に使用する秘密鍵の管理に関する話
が多数である
● では、本当に秘密鍵さえ守れていれば安全なのか？
● 秘密鍵を盗まなくても暗号資産を盗むことが可能な攻撃シナリオを想定し、脆弱性の対策や管理、アーキ
テチャレベルでセキュリティ対策を考える必要があることを紹介する
ここからは、Coincheckのシステム構成を前提とせずに、暗号資産取引所で攻撃シナリ
オを考えた場合の話になる

View Slide

34
オフチェーンの場合はユーザーの残高はDBで管理しているのでDBを改ざんすれば大量の暗号資産を引き出す
ことも可能なので脆弱性の管理や対策も重要
Exploit
DB改ざん
UserA 10BTC
UserB（攻撃者のアカウント） 99999999BTC
大量引き出し
ビットコインの総発行枚数は2100万枚だけど・・・

View Slide

35
署名システムがアプリーションサーバが発行したトランザションをそのまま署名してブロードキャストす
るような仕組みだった場合、アプリーションサーバを乗っ取ることができれば不正なトランザションを発
行して署名リエストを送ることが可能
署名システムで署名する際やブロードキャストする前に署名リエストの内容が不正なものでないかチェッ
する機能が必要
Exploit
不正なトランザションの発行
署名システム

View Slide

36
攻撃者がサービスのネットワー内に侵入し、不正なProxyサーバを建てて通信内容を中継可能かつ通信内容
が平文だった場合は、署名リエストやトランザションデータの内容を改ざんして送金先アドレスや送金す
る量を改ざんできるので通信の暗号化や前述と同様に署名する前やブロードキャストする前に不正なものでな
いかチェッする機能が重要
トランザションデータ・署名リ
エストの改ざん
署名システム不正なProxyサーバ

View Slide

署名ネットワー DMZ
37
アプリーションサーバと署名システムが同一ネットワー上にある場合、攻撃者はアプリーションサーバ
を経由して署名システムへ攻撃が可能なのでアプリーションサーバと署名システムはネットワーを分ける
ことも重要
そうした場合はどうやってユーザの送金リエストを署名サーバに伝えるか考える必要がある
Exploit
署名システム

View Slide

38
マルチシグネチャにしていれば安全か？
マルチシネチャはひとつのアドレスから送金するのに複数の秘密鍵が必要な仕組みで、仮にハッキンを受
けても送金に必要な数の秘密鍵が盗まれていなければウォレットの資産は無事になる
● 送金するには複数の秘密鍵が必要
● いくつ必要かは設定できる

View Slide

39
アドレスがマルチシネチャに対応していても同一サーバ上でマルチシネチャに必要な数の鍵を扱っていた
場合、そのサーバ一台を乗っ取ることができれば不正に送金することが可能
Exploit
● サーバ一台を乗っ取れば必要な数の秘密鍵を盗むことが
できる

View Slide

40
複数サーバに分散したとしても同一ネットワー、同一構成なら同じ攻撃手法で乗っ取ることができるので難
易度は変わらない
Exploit
● どちらか一台を乗っ取ることができれば、同じ攻撃手法
でもう一台も乗っ取ることができる
Exploit
● 同一構成
○ 同じOS
○ 同じアプリーション

View Slide

41
異なるOS、異なるアプリーションにすればいいかと言われると運用コストが・・・
● 異なるOS
● 異なるアプリーション
● 異なるソースコード
● 構成管理
● パッチ適用
● EOL
● メンテナンス
正解はなく、各社のソフトウェアエンジニアの数や質によって自分達にとって最適な解を考えなければならない

View Slide

42
コールドウォレット、ホットウォレット
暗号資産交換業者に関する内閣府令　第二十七条3項1号
暗号資産交換業者が自己で管理する場合　暗号資産交換業の利用者の暗号資産を移転するために必要な情報を、常時インターネット
に接続していない電子機器、電磁的記録媒体その他の記録媒体（文書その他の物を含む。）に記録して管理する方法その他これと同
等の技術的安全管理措置を講じて管理する方法
コールドウォレットホットウォレット
出典: https://elaws.e-gov.go.jp/document?lawid=429M60000002007

View Slide

43
ColdWalletから暗号資産を移転する場合の運用も考えなければならない
CGTF（Cryptoassets Governance Task Force）のモデルをベースとして考えた場合に
● 誰（部署、役職）が移転指示を出したり実際の署名作業を行うのか。その際に移転する暗号資産やその数量、送金先のアドレス
の正しさはどのようにして担保されているのか
● 署名する際に生の秘密鍵に触れる、もしくは閲覧できてしまうのか
● 署名されたトランザションが移転指示の内容と一致するものであることをどのタイミンで検証して、その正しさを担保する
のか
● etc…
出典:https://cgtf.github.io/publications/20220323/custodiandocument_ver3.pdf

View Slide

44
フィッシンサイトにユーザーを誘導しユーザーの認証情報を奪取、不正ロインをしてユーザーの暗号資産
を奪取するシナリオもあり、フィッシンサイトの検知やテイダウンも実施する必要がある
サービスとしてのセキュリティ
フィッシンサイトへ誘導
認証情報を奪取

View Slide

45
送金時など資産を外部に持ち出す際には追加の認証を挟むなどの対策も必要

View Slide

46
暗号資産は相場の変動が短期的に大きく動くことが多々あり、そういった際にDDoS攻撃などでサービスが利
用できないと顧客が取引できずに損をしてしまう場合もあるため安定的に稼働させる必要がある

View Slide

47
まとめ

View Slide

48
まとめ
● ブロッチェーン、と一言で言っても実際の仕様や実装は各チェーンで異なる
● オンチェーン、オフチェーンといった仕組みがありほとんどの取引所がオフチェーンの仕組みを採用して
いる
● 秘密鍵の奪取だけが暗号資産の流出リスではない、それ以外のセキュリティ対策もしっかり考える必要
がある
● コールドウォレットも移転のプロセス、オペレーションまでの全体を考えなければならない
● システム的なセキュリティだけでなくフィッシン対策やDDoS攻撃対策などユーザーの保護や安定稼働に
も取り組む必要がある

View Slide

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

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

coincheck

More Decks by coincheck

Other Decks in Technology

Featured

Transcript