これはLINE Advent Calendar2018の23日目の記事です。

皆さんこんにちは！　LINE Security室の関水です！　この記事は私と、同じくSecurity室の愛甲で書いています。

LINE Developer Day 2018（全セッション動画）などのイベントでも既にお伝えてしている通り、LINEではブロックチェーンを利用したサービス群の開発にも力を入れており、日米除くグローバルで取引が可能な仮想通貨交換所「BITBOX」も提供しています。特に仮想通貨は世の中にある金融サービスの中でも比較的新しいジャンルのサービスであり、セキュリティの領域でも非常に注目が集まりやすいものとなっています。そこで、この記事では仮想通貨交換所（取引所）を運営する上で必要となるセキュリティ技術について解説したいと思います。

はじめに

はじめに代表的な仮想通貨であるBitcoinについて簡単に触れさせてもらいます。

オンラインの決済においては物理的なお金（硬貨やお札）を直接送ることはできませんから、代わりにそれと同価値のデジタルデータを送る必要があるわけですが、デジタルデータは当然複製（コピー）が容易です。簡単に複製できるものをお金として扱うことはできないため、一般的にはお金を管理する中央機関（銀行など）を利用してオンライン決済を実現します。信頼できる中央機関を用意すれば、"中央機関が不正をしないこと"を前提としてオンライン上における決済が可能になるわけです。では、そのような中央機関を一切必要とせずにオンライン決済を実現することは可能でしょうか？　この疑問に対する答えが、かの有名なSatoshi Nakamoto氏の論文Bitcoin: A Peer-to-Peer Electronic Cash Systemであり、Bitcoinそのものです。Bitcoinに関する解説はすでに多くあるためこの記事では詳細は触れませんが、分かりやすい技術資料としてBitcoinを技術的に理解するをご紹介させていただきます。

Bitcoinはいわゆるビザンチン将軍問題（Byzantine Generals Problem）に対するひとつの解であり、また興味深い発明ですが、いくつかの問題（リスク）も抱えています。

• 51% attack / Selfish mining
• アルゴリズムの仕様/バグを利用した攻撃
• 暗号アルゴリズムの危殆化（きたいか）
• ソフト/ハードフォーク

これらは（Bitcoinを含む）仮想通貨そのものが抱えるリスクであり交換所側で行える対策は少ないのですが、仮想通貨における問題はそのまま交換所にも影響を与えるため、セキュアに運営するためにはやはり無視できません。よって、まずは前半で仮想通貨に関連するリスクについて簡単に解説し、それから後半部分で仮想通貨交換所を運用する上で守るべきセキュリティにフォーカスしていきたいと思います。

51% attack / Selfish mining

まずは51% attackとSelfish miningについて解説します。これらはどちらも交換所に対して被害を与えうる攻撃手法です。PoW（Proof of Work）を採用している仮想通貨では計算量の過半数（51%）以上を占めることで任意のTransactionの承認/非承認を決定できるため、二重支払い（double-spending attack）が可能になります。実際にこのような攻撃が行われた例はあり、例えば2018年5月にBitcoin Goldで51% attackが行われました。これにより交換所は数億円の被害を被っています（bitcoingold.org:double-spend-attacks-on-exchanges）。Bitcoin Hashrate Distributionを見ると分かりますが、上位4,5つほどのマイニングプールを合わせると51%を超えます。なので仮に"上位のマイニングプールが結託したら"Bitcoinにおいても51% attackは可能です。51% attackを成功させるために必要なコストをざっくり調べられるサイトCrypto51もありますから、それなりの計算リソースがあるならば（成功しそうな仮想通貨を選べば）それほど難しくないのかもしれません。

また同じように二重支払いにつながる攻撃手法としてSelfish miningがあります。Selfish miningは自身のマイニング結果をブロードキャストせずにチェーンを（秘密裏に）成長させ、パブリックチェーンより長くなったタイミングでブロードキャストします。これによりパブリックチェーンを上書きでき（51% attackと同様に）二重支払いを行えます。Selfish miningは51% attackと同じくそれなりの計算量が必要ですが、Sapirshtein氏の論文によると25%でも可能とのこと。ちなみにこちらも実例があります（Japanese Cryptocurrency Monacoin Hit by Selfish Mining Attack、モナコインへのセルフィッシュマイニング）。

これらは交換所としても被害を被る立場であるため注視しておきたい事柄です。しかしこのような攻撃には根本的な対策法がなく、決済確定と判断するチェーンの長さをある程度長く設定することくらいしか現実的な対応策がありません。仮想通貨におけるもっとも大きなリスクのひとつと言えるでしょう。

アルゴリズムの仕様/バグを利用した攻撃

次に実装上のバグ/脆弱性による攻撃についても紹介しましょう。

CVE-2018-10299はBEC（Beauty Ecosystem Coin）のスマートコントラクト実装のbatchTransfer関数内にあったInteger Overflowにより、異常な量のコインを得ることができた脆弱性です。詳細はA disastrous vulnerability found in smart contracts of BeautyChain (BEC)やALERT: New batchOverflow Bug in Multiple ERC20 Smart Contracts (CVE-2018-10299)に書かれてありますので、興味がある方は参照してください。

uint256 amount = uint256(cnt) * _value;

基本的にはただのInteger Overflowであり、uint256である2つの値cntと_valueを乗算したものを、同じくuint256の値であるamountに代入するコードに問題がありました。cntと_valueは任意に指定できるため、cnt=2, _value=0x800000...00のような値にすると乗算の結果overflowし、amount=0となります。本来amountにはcntと_valueの乗算の結果が入るはずが、overflowにより0となり以降のエラーチェックをパスして_valueの値（送金額）が宛先に送信されました（攻撃のTransaction）。

同じような"実装の脆弱性"が原因で起きた有名な事件に「The DAO事件」があります。一時期話題になったため知っている方も多いと思いますが、この事件は脆弱性自体にはそれほど特筆すべき点はないのですが、事件前後の議論やその対応はとても興味深いものです。脆弱性が存在することをあらかじめ指摘されていたり、攻撃者が盗んだ数十億円相当のETHを取り戻すためにハードフォークを発表したり、それに伴ってネットワークが分裂したりと（EthereumとEthereum Classicの分裂）、様々な議論が巻き起こりました。このように仮想通貨の実装上のバグ/脆弱性による攻撃は金銭的、社会的な側面においても極めて大きな問題となります。

最後にMt.Goxの事件で使われたといわれているトランザクション展性（Transaction Malleability）にも触れておきます（Bitcoin Transaction Malleability and MtGox）。トランザクション展性はどちらかというと交換所システムの脆弱性であり、仮想通貨実装の問題ではないため交換所のセキュリティとして扱うべきなのですが、バグ/仕様を利用した攻撃だったということでついでにここで説明したいと思います。

トランザクション展性は、トランザクション内のscript_signatureの意味を維持したままコードを変えることで、トランザクションIDは異なるが"同じ意味を持つ"トランザクションを生成できる問題です。script_signatureは秘密鍵による署名対象になってないが、トランザクションIDの生成には使われる点がポイントです。このとき交換所システムが、出金の管理をトランザクションIDのみで行っていた場合、ユーザーは交換所に対して出金の申請をし、そのトランザクションを交換所がブロックチェーンに追加する前に（もしくはそれを妨害して）IDが異なるトランザクションを先にブロックチェーンに追加することで、交換所にトランザクションが失敗したと認識させることができます。ブロックチェーン上では異なるトランザクションIDで取引が完了しているため交換所はそれを認識できず、再度出金申請を受け付けてしまいます。

このように、システムに単純なバグがあっただけで結果的に交換所から多大な（数百億単位の）被害が出てしまったという実例はいくつかあります。ちなみにMt.Goxの件はこれが真実ですというように明確に原因を語られたわけではないため、本当のところは分かりません。しかし交換所を運営する上での教訓は十分すぎるほど得られます。

これらは51% attackやSelfish miningとは異なり実装におけるバグ（脆弱性）であるため、コードを修正すれば再発はしません。しかし仮想通貨もソフトウェアである以上バグはつきものです。発見されるされないに関わらず、開発が進められていく上で多くのバグが生み出されては修正されていきます。これはソフトウェアエンジニアリングにおいては当たり前のことなのですが、こと仮想通貨に関してはそれが金銭問題に直結するため、交換所の運営においても常にセキュリティ情報をチェックしておかなければなりません。

ここまでに挙げた例はほんの一部であり、実際に起こった事件は他にも多くありますので興味があれば調べてみてください。また事件になったわけではありませんが、他にも暗号/ハッシュアルゴリズムの危殆化やハードフォークによる仕様変更などセキュリティ的に考えておくべきリスクは多々あります。このような仮想通貨のリスクに注意しつつ、交換所そのもののセキュリティについても考える必要があります。

交換所のセキュリティ

本稿は仮想通貨交換所のセキュリティ入門記事ですので、ここからは対策を中心に交換所を運営するにあたり必要となるセキュリティ対策について書いていきたいと思います。

交換所は各ユーザーに紐付けられた財布（Wallet）を取り扱います。交換所にとってはこの"ユーザーのWallet"が最優先で守らなければならない"情報資産"になります。Walletは（運用方法にもよりますが）1つ以上の署名鍵の集合なので、Walletを保護することは署名鍵を守ることとほぼ同じです。そして署名鍵を紛失することは仮想通貨で管理しているお金を紛失することとイコールですし、署名鍵が盗難に遭うということはお金を盗まれることとイコールです。よって、仮想通貨交換所のサービスを構築する上で最初に考えるべきは"署名鍵を安全に管理する方法"です。

仮想通貨に限りませんが、鍵管理において重要な要件は以下になります。

• 厳格なアクセス制限
• アクセス頻度の最小化
• 意図しない消失、盗難への対応策

鍵にはアクセス制限をかけ、かつ、アクセス頻度は最小にすべきというのは確かに至極当たり前のことなのですが、仮想通貨における署名鍵は（利便性のために）なるべくオンラインに置きたいのもまた事実です。絶対に保護しなければならない一方で、Transaction生成のために頻繁に利用したいものでもあるのです。よって、まずは交換所における鍵の保護技術について、主に以下の3つについて書いていきたいと思います。

• Online wallet / Offline wallet
• HSM（Hardware Security Module）
• マルチシグ（Multisig）

これらは"鍵を保護/管理する"という点において共通の目的を持った技術です。ひとつずつ説明していきます。

Online wallet / Offline wallet

署名鍵と署名を行うアプリケーションがNW上に存在する形をOnline wallet、署名鍵を完全にNWから切り離した形をOffline walletと呼びます。別の言い方としてOnline walletはHot wallet、Offline walletはCold walletと呼称されることもあります。Oniline walletはNWに接続されたアプリケーションである性質上、取引したい際にすぐにTransactionを作成、ブロックチェーンに追加できますが、その分署名鍵やアプリケーションに対するハッキングの危険性があります。実際、昨今の仮想通貨盗難事件のいくつかはOnline walletに必要以上の通貨が置かれており、それらがリモートから盗まれたことによる被害です。

一方、Offline walletは署名作業をオフラインのアプリケーションで実行しなければならないため、即座に取引ができないかわりに署名鍵そのものに対するハッキングの危険性はOnline walletに比べて下がります。このため多くの交換所ではユーザーの利便性と安全性のバランスを勘案した上で、Online walletとOffline walletのバランスが適切になるように運用されています。

上記の画像はOffline walletの一例ですが、LINEのサービスにおいてもほぼ同様の仕様で管理されます。

署名鍵の管理

交換所の規模がある程度大きくなると、Online walletに保管される鍵（通貨）の量もそれなりの規模になります。よって鍵の管理についても考える必要があります。

そこで決定性ウォレットという技術があります。決定性ウォレットとは、あるデータ列（マスターシード）から複数の署名用鍵ペアを生成する仕組みです。これを階層化し、マスターシードから親となる鍵ペアAを作成し、Aから子となる鍵ペアBを作成、さらにBから孫となる鍵ペアCを作成できます。いわゆる階層構造に連鎖した鍵ペアを作れるため、例えば鍵ペアCを特定のユーザーXに紐づけておけば、ユーザーXの取引はすべて鍵ペアCから生成できる"新しい鍵"で行えます。もちろんマスターシードが盗難されると、そこから作られたすべての鍵も盗まれたことになるため、マスターシードは厳重に保管しなければなりません。

署名鍵の保存方法についても言及しましょう。

サーバ・ストレージに格納された署名鍵は生成過程においてどうしても作業者あるいは作業環境であるマシンに鍵情報が露出、残存してしまいます。極論ですが、メモリ上のどこかには鍵の生成や署名に関するデータが（一時的にであれ）展開されるわけですから、100%安全に鍵を生成、管理することはまず無理です。そこで生成と署名に特化したHardwareを利用することで対応します。HSM（Hardware Security Module）という暗号専用のプロセッサを用いることで、生成と署名をそのHardware Module内で完結させ、実行結果だけを受け取ります。HSMを利用することでOnline walletで利用される署名鍵をより安全に保護することができるわけです。

Key Management ServiceのSolutionには様々なものがありますが、仮想通貨交換所の規模に応じて署名鍵の保護に最適なものを選択する必要があります。

マルチシグ（Multisig）

交換所の運営においては"いかに鍵を安全に保管するか"が重要ですが、それに加えて意図しない消失、盗難への対策も考えておくものです。

通常Transactionの生成に必要な署名鍵はひとつですが、この鍵を複数用意し、それらを含めたグループを作成、そしてグループ内の鍵のうち、予め定義されたいくつかの鍵による署名がなければ有効なTransactionとみなさないという仕組み、これがMultisigです。Multisigに必要な鍵は例えば"2 of 3"のように表記され、これは"3つの署名鍵で構成されたグループのうち、2つの署名鍵が集まらなければ有効にしない"ことを意味します。Multisigは多くの仮想通貨でサポートされており基本的なセキュリティ技術となっています。

Multisigのセキュリティ的なメリットは主に2点あります。

• 単独の責任者（企業）による不正を防止できる
• 署名鍵を紛失しても（必要な署名鍵があれば）仮想通貨のやり取りを継続できる

Multisigは有効なセキュリティ対策のひとつで、Bitcoin含め、多くの仮想通貨にはTransactionのためのScriptが実装されており、それによりMultisigを実現しています。ちなみにEtheriumのScriptはチューリング完全であり、Multisigに限らず、実に様々な用途でScriptを利用する目的で開発が進められています。もし興味があれば「スマートコントラクト」で検索してみてください。

認証と不正検知

最後に認証と不正検知についても少しだけ触れることにします。

これは交換所だけでなく一般的なWebサービスにおいても同様の問題ですが、お金を扱うサービスの場合はよりユーザー認証を強化する必要があります。ユーザー名とパスワードを用いた認証は一般的なWebサービスでも当たり前に使われていますが（特にお金を扱うサービスの場合）それだけでは十分とはいえません。LINEでは昨年よりアライアンス加盟して実装を進めているFIDOのようなテクノロジーがありますが、こうした認証のSolutionは仮想通貨交換所サービスへの導入にも適しています。認証の高度化に関しては様々なアイデアがありますが、パスワードに加えて生体や物理デバイスなどの別要素を用いる「追加認証/二段階認証」を重要な操作に導入してもよいでしょう。

また仮想通貨取引のような金融サービスでは不正検知の仕組みも必要です。

• 短期間で複数の取引が発生していないか
• 著しく大きな金額の取引が発生していないか
• 悪性のWallet addressが使われていないか
• これまでの挙動と異なる不自然な取引が発生していないか

このような検知項目を定量的に監視し、異常な取引を発見した場合に速やかに調査、問題を解析できるような仕組みを整備していくことも仮想通貨交換所の運営では検討されなければなりません。不正検知はSecurityの一分野でもあり、これはこれで様々な技術が必要となるのですが、仮想通貨のセキュリティからは離れてしまうため本稿では触れる程度にとどめておきます。

まとめ

仮想通貨交換所の運用に関するセキュリティについて簡単に書かせていただきましたが、いかがだったでしょうか。入門記事ということで代表的な題材をまんべんなく取り上げましたが、基本的には"いかに利便性を担保しつつ鍵を保護するか"と、"いかに認証と不正検知によりユーザーの安全性を保つか"、この2点がポイントだと思います。それらに加えて（前半部分に記述したような）仮想通貨そのもののリスクについても日々調査、チェックし、可能な限りリスクを0に近づけることが重要です。

仮想通貨はセキュリティという観点から見てもとても興味深い題材です。そもそも仮想通貨は51% attackやSelfish miningなど、はじめから仕様としての問題（リスク）をいくつか抱えており、それと引き換えに"中央機関を必要としない"というコンセプトを実現しています。にも関わらず、そのコンセプトとは裏腹に仮想通貨交換所という"信頼すべき中央機関"が存在します。もちろん個人で取引を行うこともできますが、多くの人が交換所を利用していることは事実です。その結果、交換所からの情報漏洩、プログラムの脆弱性、暗号アルゴリズムの危殆化といった様々な問題に目を向けなければなりません。まさに様々な分野の知識が必要という感じですが、セキュリティエンジニアとしてはこれ以上ないやりがいのある仕事だとも言えます。

LINEでは仮想通貨交換所を始めとした金融サービスの安全性確保について様々な取り組みを行っています。このような金融事業におけるセキュリティエンジニア【LINE Financial】も募集していますので、もし興味があればぜひ応募していただきたいと思います。

明日はHattori Keigo(keigohtr)さんによる「Kubernetes上で動作する機械学習モジュール配信管理基盤Rekcurd (ex Drucker) Update (PyPI, LDAP対応, etc…)」です。お楽しみに！