JP2019003309A

JP2019003309A - 検査装置

Info

Publication number: JP2019003309A
Application number: JP2017115753A
Authority: JP
Inventors: 照博田篭; Teruhiro Tagome
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2017-06-13
Filing date: 2017-06-13
Publication date: 2019-01-10
Anticipated expiration: 2037-06-13
Also published as: JP6952506B2

Abstract

【課題】ブロックチェーンに関連するプログラムの脆弱性を検出する精度を向上する。【解決手段】検査装置１０は、ＳＣ取得部１６と解析部１８を備える。ＳＣ取得部１６は、ブロックチェーンを共有する複数の機器により実行可能なプログラムであって、実行結果が上記ブロックチェーンに記録されるプログラムであるコントラクトのソースコードを取得する。解析部１８は、上記ブロックチェーンの仕様に基づき予め定められた評価項目にしたがって、ＳＣ取得部１６により取得されたコントラクトのソースコードの脆弱性を検出する。【選択図】図１

Description

本発明はデータ処理技術に関し、特にコンピュータプログラムを検査する技術に関する。

コンピュータプログラムのソースコードを静的解析する装置が提案されている（例えば、特許文献１参照）。

また、近年、ブロックと呼ばれるデータの単位を一定時間ごとに生成し、複数のブロックを鎖のように連結していくことによりデータを保管する分散型のデータベースであるブロックチェーンの利用が進みつつある。

特開２００５−２０２４９４号公報

従来より、ウェブアプリケーションやスマートフォンアプリケーションに対してセキュリティを検査するツールは提案されているが、ブロックチェーンを利用したシステムでは、従来とは異なる観点での検査が必要であると本発明者は考えた。

本発明は、発明者の上記着想に基づいてなされてものであり、１つの目的は、ブロックチェーンに関連するプログラムの脆弱性を検査する技術を提供することにある。

上記課題を解決するために、本発明のある態様の検査装置は、ブロックチェーンを共有する複数の機器により実行可能なプログラムであって、実行結果がブロックチェーンに記録されるプログラムであるコントラクトのソースコードを取得する取得部と、ブロックチェーンの仕様に基づき予め定められた評価項目にしたがって、取得部により取得されたコントラクトのソースコードの脆弱性を検出する検出部と、を備える。

なお、以上の構成要素の任意の組合せ、本発明の表現を、方法、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、ブロックチェーンに関連するプログラムの脆弱性を検出する精度を向上することができる。

実施例の検査装置の機能構成を示すブロック図である。図２（ａ）は、検査対象となるプログラムの例を示す図であり、図２（ｂ）は、攻撃者プログラムの例を示す図である。検査対象となるプログラムの例を示す図である。検査対象となるプログラムの例を示す図である。検査装置の動作を示すフローチャートである。

実施例の検査装置は、分散型のデータベース（台帳データとも言える）であるブロックチェーン上で実行可能なプログラムであるコントラクト（スマートコントラクト（Smart Contract）とも呼ばれる。以下「ＳＣ」と呼ぶ。）の脆弱性を検査する。ＳＣは、デジタル化された約束事とも言え、Ｐ２Ｐ（Peer to Peer）ネットワークを介してブロックチェーンを共有する複数の機器により実行可能なコンピュータプログラムである。ＳＣは、典型的には、フィールド（ステートともいえ、Ｊａｖａ（登録商標）のインスタンス変数に相当）と、関数とを有する。また、上記複数の機器のそれぞれによるＳＣの実行結果は、ブロックチェーン上に記録され、具体的には、ブロックチェーンにおけるいずれかのブロックに記録される。

実施例のブロックチェーンは、「イーサリアム（Ethereum）」により実現される。イーサリアムは、パブリックなブロックチェーンのプラットフォームであり、イーサリアム・ネットワークと呼ばれるＰ２Ｐネットワーク上でＳＣの履行履歴（実行履歴とも言える）をブロックチェーンに記録していく。ＳＣの履行履歴は、ＳＣのインスタンスのデータ、そのインスタンスに対するアクション（関数呼び出し等）、アクションの結果を示すデータを含んでもよい。

また実施例では、ＳＣのソースコードは、コントラクト指向言語である「Solidity」により記述される。変形例として、ブロックチェーンネットワークは、イーサリアム以外の他のプラットフォームにより実現されてもよい。また、ＳＣのソースコードは、Solidity以外の公知のプログラミング言語により記述されてもよい。

図１は、実施例の検査装置１０の機能構成を示すブロック図である。検査装置１０は、一般的なＰＣ、タブレット端末、スマートフォンであってもよい。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵ・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

検査装置１０は、ＳＣ記憶部１２、検査結果記憶部１４、ＳＣ取得部１６、解析部１８、検査結果出力部２０、キーワード記憶部２２を備える。これらの機能ブロックに対応する複数のモジュールを含むコンピュータプログラムは、所定の記録媒体に格納され、その記録媒体を介して、検査装置１０のストレージにインストールされてもよい。また、上記コンピュータプログラムは、通信網を介してダウンロードされ、検査装置１０のストレージにインストールされてもよい。検査装置１０のＣＰＵは、ローカルのストレージにインストールされた上記コンピュータプログラムをメインメモリへ読み出して実行することにより、図１の各ブロックの機能を発揮してもよい。

ＳＣ記憶部１２は、所定のブロックチェーンを共有する複数の機器により実行され得る１つ以上のＳＣのソースコードが格納される記憶領域である。検査結果記憶部１４は、ＳＣのソースコードに対する検査結果を示すデータが格納される記憶領域である。キーワード記憶部２２は、ＳＣのソースコードの脆弱性を検出するための複数のキーワードもしくはキーフレーズが格納される記憶領域である。

ＳＣ取得部１６は、検査の担当者により指定されたＳＣ（以下「検査対象ＳＣ」とも呼ぶ。）のソースコードをＳＣ記憶部１２から読み込む。以下、単に「検査対象ＳＣ」と呼ぶ場合、ソースコードを意味する。解析部１８は、ブロックチェーン（実施例ではイーサリアム）の仕様に基づいて予め定められた複数の評価項目にしたがって、ＳＣ取得部１６により取得された検査対象ＳＣの脆弱性を検出する。解析部１８は、脆弱性検出部とも言える。解析部１８は、検査対象ＳＣの脆弱性を、ソースコードを静的解析することにより検出する。

検査結果出力部２０は、解析部１８による脆弱性の検出結果を示す検査結果データを検査結果記憶部１４に保存する。検査結果データは、検査対象ＳＣの識別データと、複数の評価項目のそれぞれについての脆弱性の有無を示すデータとを含んでもよい。なお、検査結果出力部２０は、所定のディスプレイに検査結果データを表示させてもよい。また、検査結果出力部２０は、所定の外部装置へ検査結果データを送信して、その外部装置に検査結果データを記憶させ、また表示させてもよい。

解析部１８による複数の評価項目を詳細に説明する。実施例では、７つの評価項目により検査対象ＳＣの脆弱性を検出する。なお、解析部１８は、公知の字句解析および構文解析の技術を使用して検査対象ＳＣをパースし、検査対象ＳＣに記述された字句（例えば、関数名、変数名、引数等に該当する文字列）を抽出してもよい。

評価項目１．外部関数呼び出し（External Call）
ＳＣでは、「他のＳＣのアドレス（アカウントとも言える）．関数名」の形で、他のＳＣの関数を呼び出すことができる（外部関数呼び出しと呼ぶ）。しかし、信頼できないコントラクトの関数を呼び出すことは予期しない結果をもたらす可能性がある。例えば、外部のＳＣに実装された悪意のあるコードを意図せず呼び出してしまう可能性がある。

解析部１８は、検査対象ＳＣに外部関数呼び出しのコードが記述されている場合、そのことを検出し、検査対象ＳＣに脆弱性があることを検出する。また、解析部１８は、評価項目「再入可能性」における脆弱性の有無を示す検査結果データを検査結果出力部２０へ渡す。

具体的には、解析部１８は、検査対象ＳＣのコードの中から、Solidity言語において予め定められた外部関数呼び出しの形式に合致する文字列を検索してもよい。例えば、解析部１８は、検査対象ＳＣのコードの中から、「他のＳＣのアドレス（例えばaddress型の変数）．関数名」の形式の文字列を検索し、該当する文字列が存在すれば、検査対象ＳＣに脆弱性があると判定してもよい。

評価項目１を設けることにより、ＳＣの開発者、例えば、ブロックチェーンの利用ユーザやシステムインテグレータ等に対して、外部関数呼び出しによるリスクの存在を報知し、対処を促すことができる。

評価項目２．再入可能性（Ｒｅ−ｅｎｔｒａｎｃｙ）
残高等のフィールド（言い換えればステート）を更新する前に送金等の処理（「特定処理」と呼ぶ。）を実行するようにＳＣが記述された場合、外部の不正プログラムにより、フィールドの更新前に特定処理を複数回実行するように制御されてしまう可能性がある。この結果、ユーザの残高を超える金銭が引き出されてしまう等、不正な結果が生じうる。なお、実施例における特定処理は、外部関数呼び出しの一種と言え、ＳＣを呼び出した元のプログラムの関数（例えばフォールバック関数）を呼び出すものである。

図２（ａ）は、検査対象となるプログラムの例を示す。同図の検査対象ＳＣ３０は、複数のユーザそれぞれの残高（言い換えれば預り金額）を保持するマップと、「withdrawBalance」関数を含む。この関数は、コード３２とコード３４を含み、実行順序はコード３２→コード３４である。コード３２は、当該ＳＣを呼び出した呼び出し元（例えば、ユーザまたはユーザのプログラムであり、コード内では「msg.sender」）の残高を引き出す処理である。具体的には、コード３２は、呼び出し元の残高の全額を呼び出し元へ送金する処理である。また、コード３４は、呼び出し元の残高を「０」に更新する処理である。

図２（ｂ）は、攻撃者プログラムの例を示す。攻撃者プログラム４０は、検査対象ＳＣ３０における再入可能性の脆弱性をついて不正な送金処理を実行させるプログラムである。具体的には、（１）攻撃者は、検査対象ＳＣ３０（すなわち攻撃対象のＳＣ）のアドレスを引数に指定して攻撃者プログラム４０の「withdraw」関数を呼び出す。（２）「withdraw」関数内のコード４２は、検査対象ＳＣ３０のアドレス（to）を用いて、検査対象ＳＣ３０の「withdrawBalance」関数を呼び出す。

（３）検査対象ＳＣ３０における「withdrawBalance」関数内のコード３２は、上記の特定処理に該当し、攻撃者の残高分の金銭を攻撃者へ送金する。このとき、イーサリアムの仕様により、攻撃者プログラム４０のフォールバック関数４４（言い換えれば無名関数）が自動的に呼び出される。（４）攻撃者プログラム４０のフォールバック関数４４のコード４６では、検査対象ＳＣ３０のアドレス（msg.sender）を用いて、検査対象ＳＣ３０の「withdrawBalance」関数を再度呼び出す。

このように、検査対象ＳＣ３０のコード３４（攻撃者の残高を０にする処理）が実行されないまま（３）と（４）が繰り返されるため、攻撃者の残高より多い金銭が引き出されてしまう。この攻撃を防止するために、検査対象ＳＣ３０では、ユーザの残高を更新するコード３４が、送金処理を行うコード３２により前に実行されるように記述される必要がある。より一般的に言えば、ＳＣは、呼び出し元のプログラムの関数を呼び出す特定処理を実行する前に、フィールドの更新処理を実行するように記述される必要がある。

そこで解析部１８は、検査対象ＳＣに、当該ＳＣの関数を呼び出した呼び出し元（上記の攻撃者プログラム４０）の関数を呼び出す第１処理（上記の特定処理）と、検査対象ＳＣのフィールドのデータを更新する第２処理とが記述されており、かつ、第２処理が第１処理より後に実行されるように記述されている場合に検査対象ＳＣの脆弱性を検出する。解析部１８は、評価項目「再入可能性」について、脆弱性の有無を示す検査結果データを検査結果出力部２０へ渡してもよい。なお、上記フィールドのデータは、呼び出し元に関するデータ（例えば預り金額等）であり、呼び出し元のユーザまたはプログラムのアカウント（またはアドレス）に対応付けられたデータであってもよい。

具体的には、解析部１８は、検査対象ＳＣのコードの中から、solidity言語で予め定められた外部関数呼び出しの形式に合致する第１文字列を検索してもよい。また、解析部１８は、図２（ａ）で示したように、自動的（暗黙的）に呼び出し元のフォールバック関数を呼び出すコマンド（送金処理等）に合致する文字列を上記第１文字列として検索してもよい。上記第１文字列が存在する場合、解析部１８は、同じ関数内で第１文字列の後に、呼び出し元に関するフィールドのデータを更新する処理を示す第２文字列が存在するかを検索する。そして、第１文字列の後に第２文字列が存在する場合、解析部１８は、検査対象ＳＣに脆弱性があると判定してもよい。

評価項目２を設けることにより、ＳＣの開発者に対して、ＳＣに再入可能性のリスクが存在することを報知し、対処を促すことができる。

評価項目３．トランザクションの順序への依存性（Transaction-Ordering Dependence（TOD））
ブロックチェーンにおいて、複数のトランザクション（具体的にはＳＣの関数を呼び出す処理等）がブロックに取り込まれる順序は、ブロックチェーンの維持管理作業への参加者（以下「マイナー」と呼ぶ。）に依存する。また、ブロックチェーンでは、複数のマイナーの合意形成を経て新たなブロックが確定したタイミングで、その新たなブロックに取り込まれた複数のトランザクションが、当該ブロックへ取り込まれた順序で実行される。したがって、ユーザが意図した順序でトランザクションが実行されないケースがある。

例えば、注文と取消の２つのトランザクションを、注文→取消の順序でユーザが発生させた場合でも、新たなブロックの確定タイミングでは、これらのトランザクションが取消→注文の順序で実行されてしまうかもしれない。このことは、コンストラクタ以外の第１の関数がフィールドの値（ステート）を変更し、第１の関数とは異なる第２の関数がそのフィールドの値を参照または更新する場合に問題となりうる。

図３は、検査対象となるプログラムの例を示す。検査対象ＳＣ５０は、マーケットプレイスを抽象化したスマートコントラクトである。「price」フィールドは商品価格を示す。オーナーは、「updatePrice」関数を呼び出して商品価格を変更できる。また、購入者は、「buy」関数を呼び出して商品を購入できる。ここで、購入者が「price」フィールドの値を参照した上で「buy」関数を実行し、直後に、オーナーが「updatePrice」関数を実行して「price」フィールドの値を変更したとする。この場合、ブロックチェーン上では、マイナーに依存して、「updatePrice」関数が「buy」関数より先に実行されることがある。この結果、購入者は、商品購入の操作時に参照した価格とは異なる価格で商品を購入することになってしまう。例えば、図３のコードでは、条件分岐処理「if (msg.value < quantity * price || quantity > stockQuantity)」が、ユーザが想定する価格とは異なる価格を用いて実行されてしまう。

そこで解析部１８は、検査対象ＳＣに複数の関数が記述され、複数の関数のうち第１の関数に、検査対象ＳＣに保持された特定のフィールドのデータを更新する処理が記述され、複数の関数のうち第２の関数に上記特定のフィールドのデータを参照または更新する処理が記述されている場合に、検査対象ＳＣ５０の脆弱性を検出する。

例えば、解析部１８は、検査対象ＳＣに含まれる１つ以上の関数を抽出してもよい。解析部１８は、検査対象ＳＣにおける同じフィールドの値を参照または更新する複数の関数が存在し、それら複数の関数のうち少なくとも１つが上記同じフィールドの値を更新するものである場合に脆弱性有りと判定してもよい。解析部１８は、評価項目「トランザクションの順序への依存性」について、脆弱性の有無を示す検査結果データを検査結果出力部２０へ渡してもよい。

評価項目３を設けることにより、ブロックチェーンにおけるトランザクション実行順序に依存する問題の発生リスクをＳＣの開発者に報知し、対処を促すことができる。

評価項目４．権限確認の有無
パブリックなブロックチェーンといえど、ユーザ端末で直接ＳＣを実行させるのではなく、ブロックチェーンを共有するＰ２Ｐネットワークに接続されるシステム（アプリケーションサーバ等）をユーザ端末とは別に設ける構成が考えられる。この場合、ユーザは、上記システムを経由してＳＣの関数等を実行させる。

このような構成で特に好適であるが、一般的に言っても、ＳＣの関数は、当該ＳＣのインスタンスを生成したオーナー（システムオーナーとも言える）のアカウント（アドレスとも言える）からのみ実行可能なように限定する方が安全である。このような限定がない場合、ＳＣ（厳密にはＳＣインスタンス）のパブリック属性の関数を、そのＳＣインスタンスを生成したオーナーとは異なる第三者に直接実行されてしまうからである。

図４は、検査対象となるプログラムの例を示す。検査対象ＳＣ６０では、コンストラクタにて検査対象ＳＣ６０をインスタンス化したオーナーのアカウントをフィールドへ記録する。関数６２は、悪い例であり、権限確認の処理を含まない。関数６２では、オーナー以外の第三者が、本来オーナーのみが実施すべき処理を実行できてしまう。

一方、関数６４は、良い例であり、呼び出し元の権限を確認する処理を含む。具体的には、関数６４は、呼び出し元のアカウントが予めフィールドに保持されたオーナーのアカウントに一致するか否かを確認する処理を含む。また、関数６６も、良い例であり、「doSomethingWithPermissionByModifier」関数の実行前に呼び出される処理である「onlyowner」が、呼び出し元の権限を確認する処理を含む。

解析部１８は、検査対象ＳＣにパブリック属性の関数が記述され、かつ、そのパブリック属性の関数に、当該関数の呼び出し元のアカウントを確認する処理が記述されているか否かを確認する。この確認処理は、パブリック属性の関数に、当該関数の呼び出し元のアカウントを確認する処理を含むmodifierが設定されているか否かを確認する処理を含む。

具体的には、解析部１８は、（１）コンストラクタが、オーナーアカウント（例えば「msg.sender」）をフィールドへ設定する処理、（２）パブリック関数が、実行者（例えば「msg.sender」）と、フィールドに設定されたオーナーアカウントとの同一性を判定する処理（例えば比較演算子または等価演算子により両者を比較すること）を含むか否かを判定してもよい。解析部１８は、上記（１）（２）の少なくとも一方の処理が検査対象ＳＣに記述されていない場合、検査対象ＳＣの脆弱性を検出してもよい。解析部１８は、評価項目「権限確認の有無」について、脆弱性の有無を示す検査結果データを検査結果出力部２０へ渡してもよい。

評価項目４を設けることにより、ＳＣのセキュリティリスクをＳＣの開発者に報知し、対処を促すことができる。

評価項目５．重要情報の有無
イーサリアム等のパブリックなブロックチェーンでは、通常、ＳＣのトランザクションは暗号化されない。例えば、ＳＣのフィールドに設定するデータは、たとえそのフィールドがプライベート属性であっても、第三者により閲覧可能である。そこで、第三者に対して秘匿すべき重要な情報（以下「重要情報」とも呼ぶ。）は、ＳＣに保持させるべきではない。重要情報は、第三者に対して非公開にすべき各種秘密情報を含み、例えば、ユーザの個人情報や資産情報、営業秘密等を含む。

キーワード記憶部２２は、重要情報に対して使用される可能性が高いと想定されるフィールド名候補の文字列を記憶する。フィールド名候補は、検査装置１０の開発者やＳＣの検査担当者等の知見や経験により予め定められてよい。フィールド名候補は、例えば、「password」「name」「phonenumber」「ID」を含んでもよい。

解析部１８は、検査対象ＳＣに記述されたすべてのフィールド名を抽出する。解析部１８は、検査対象ＳＣに記述された少なくとも１つのフィールド名が、キーワード記憶部２２に予め記憶されたフィールド名候補に一致する場合、検査対象ＳＣの脆弱性を検出する。なお、解析部１８は、完全一致に限らず、少なくとも部分一致の場合、例えば、検査対象ＳＣに記述された少なくとも１つのフィールド名が、キーワード記憶部２２に記憶されたフィールド名候補の文字列を含む場合、検査対象ＳＣの脆弱性を検出してもよい。解析部１８は、評価項目「重要情報の有無」について、脆弱性の有無を示す検査結果データを検査結果出力部２０へ渡してもよい。

評価項目５を設けることにより、ＳＣのトランザクションがそのトランザクションに関与しない第三者に閲覧され、重要情報が漏洩してしまうことを防止しやすくなる。

評価項目６．時刻への依存性
イーサリアムのSolidityには「now」という予約後が存在する。「now」には、トランザクション実行時（すなわちブロックチェーンにおけるブロック確定時）の現在時刻が設定される。一部記述したように、ブロックチェーンにおけるブロック確定タイミングはマイナーに依存する。そのため、ＳＣの関数が「now」の値に依存したロジックの場合、「now」が予期せぬ値となって問題が生じることがある。このような問題は、「now」に限らず、ＳＣの関数が、現在時刻等の何らかの時刻値に基づく処理を実行する場合に発生しうる。

キーワード記憶部２２は、時刻に関連する予約語（「now」等）、コマンド名、関数名（これらを総称して「時刻関連語」と呼ぶ。）を１つ以上記憶する。解析部１８は、キーワード記憶部２２に記憶された１つ以上の時刻関連語のうち少なくとも１つが検査対象ＳＣに記述されている場合、検査対象ＳＣの脆弱性を検出する。例えば、解析部１８は、検査対象ＳＣから、１つ以上の時刻関連語のそれぞれを検索し、少なくとも１つの時刻関連語が検査対象ＳＣに存在する場合、検査対象ＳＣの脆弱性を検出してもよい。解析部１８は、評価項目「時刻への依存性」について、脆弱性の有無を示す検査結果データを検査結果出力部２０へ渡してもよい。

評価項目６を設けることにより、ＳＣの関数が、予期せぬ時刻値のために予期せぬ動作となることを防止しやすくなる。

評価項目７．原子性
イーサリアムのSolidityでは、ＳＣの関数内で何らかのエラー、例外、または問題が発生した場合、「return false」で処理を終了させることが考えられる。しかし、「return」コマンドでは、「return」前までの処理は実行される。その結果、処理の原子性が損なわれる可能性がある。その一方、「throw」を使用すると、「throw」前までの処理がロールバックされるため安全である。そのため、ＳＣの関数内でエラー、例外、または問題が発生した場合は「throw」が使用されるべきである。

キーワード記憶部２２は、トランザクションがロールバックされないコマンド（「return false」等）の文字列を記憶する。解析部１８は、検査対象ＳＣが含む１つ以上の関数の中に、トランザクションがロールバックされない上記コマンドにより終了する関数が少なくとも１つ存在する場合、検査対象ＳＣの脆弱性を検出する。実施例では、解析部１８は、検査対象ＳＣの中の少なくとも１つの関数が「return false」を含む場合、検査対象ＳＣの脆弱性を検出する。解析部１８は、評価項目「原子性」について、脆弱性の有無を示す検査結果データを検査結果出力部２０へ渡してもよい。

評価項目７を設けることにより、ＳＣの関数における処理の原子性を維持しやすくなる。

以上の構成による検査装置１０の動作を説明する。
図５は、検査装置１０の動作を示すフローチャートである。ＳＣ記憶部１２に予め記憶されたＳＣの中から特定の検査対象ＳＣを指定した検査開始指示が検査者により入力されると（Ｓ１０のＹ）、ＳＣ取得部１６は、検査対象ＳＣのソースコードをＳＣ記憶部１２から読み込む（Ｓ１２）。解析部１８は、予め定められた７つの評価項目のそれぞれについて検査対象ＳＣのソースコードを検査し、検査対象ＳＣにおける脆弱性の有無を検査する（Ｓ１４）。検査結果出力部２０は、検査対象ＳＣにおける脆弱性の有無を示す検査結果データを検査結果記憶部１４へ保存する（Ｓ１６）。検査開始指示が未入力であれば（Ｓ１０のＮ）、Ｓ１２以降の処理をスキップして本図のフローを終了する。

実施例の検査装置１０によると、ブロックチェーンを共有する複数の機器のそれぞれで実行されるスマートコントラクトの脆弱性を静的解析により精度よく検出することができる。これにより、スマートコントラクト実行時の不具合の発生、言い換えれば、スマートコントラクトのトランザクションにおける不具合の発生を抑制し、また、セキュリティのリスクを低減することができる。

以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

上記実施例において検査装置１０は、７つの評価項目のそれぞれについて検査対象ＳＣのソースコードを検査し、検査対象ＳＣにおける脆弱性の有無を検査した。変形例として、全評価項目のうちユーザの指定をうけた評価項目のみについてソースコードを検査し、検査対象ＳＣにおける脆弱性の有無を検査してもよい。また、全評価項目のソースコードを検査し、検査対象ＳＣにおける脆弱性の有無を検査した上で、ユーザの指定を受けた評価項目の検査結果のみをユーザに表示する構成であってもよい。これらにより、ユーザの環境や条件によっては、考慮する必要がない評価項目を検査しなくてよくなり、または、考慮する必要がない評価項目をユーザが確認する必要がなくなる。

上記実施例において検査装置１０は、ブロックチェーンに関連するプログラムの脆弱性を検出するための評価項目について検査した。ところで、周知慣用技術としてソースコードの品質上問題のある部分を検出する品質検査装置やそのソースコードを実行したときのパフォーマンスの観点から問題のある部分を検出するパフォーマンス検査装置がある。このような、ブロックチェーンに関連するプログラムの脆弱性以外の評価項目を検査する機能を検査装置１０に追加してもよい。また、検査装置１０は、入力されるソースコードがブロックチェーンに関連するプログラム（例えばスマートコントラクタ）である場合にのみ、ブロックチェーンに関連するプログラムの脆弱性を検査する動作を行う構成であってもよい。この場合に、検査装置１０は、ソースコードがブロックチェーンに関連するプログラムであるかどうかを、ブロックチェーン特有の内容（変数、関数、ライブラリ名又はコメント）がソースコードに含まれるかどうかで識別してもよい。

上記実施例において検査装置１０が備えた複数の機能ブロックは、複数の装置に分散して配置されてもよい。例えば、ＳＣ記憶部１２、検査結果記憶部１４、キーワード記憶部２２の機能は、検査装置１０の外部のデータベースサーバまたはファイルサーバが有してもよい。また、検査装置１０を含む複数の装置が連携することにより、ＳＣのソースコードの脆弱性を検査する検査システムが実現されてもよい。

上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

１０検査装置、１２ＳＣ記憶部、１４検査結果記憶部、１６ＳＣ取得部、１８解析部、２０検査結果出力部、２２キーワード記憶部。

Claims

ブロックチェーンを共有する複数の機器により実行可能なプログラムであって、実行結果が前記ブロックチェーンに記録されるプログラムであるコントラクトのソースコードを取得する取得部と、
前記ブロックチェーンの仕様に基づき予め定められた評価項目にしたがって、前記取得部により取得されたコントラクトのソースコードの脆弱性を検出する検出部と、
を備えることを特徴とする検査装置。
前記検出部は、前記コントラクトのソースコードに、前記コントラクトの関数を呼び出した呼び出し元の関数を呼び出す第１処理が記述され、前記第１処理の後に、前記コントラクトに保持された前記呼び出し元に関するデータを更新する第２処理が記述されている場合、前記脆弱性を検出することを特徴とする請求項１に記載の検査装置。
前記検出部は、前記コントラクトのソースコードに複数の関数が記述され、前記複数の関数のうち第１の関数に、前記コントラクトに保持されたフィールドのデータを更新する処理が記述され、前記複数の関数のうち第２の関数に、前記フィールドのデータを参照または更新する処理が記述されている場合、前記脆弱性を検出することを特徴とする請求項１または２に記載の検査装置。
前記検出部は、前記コントラクトのソースコードにパブリック属性の関数が記述され、かつ、前記パブリック属性の関数に、当該関数の呼び出し元のアカウントを確認する処理が記述されていない場合、前記脆弱性を検出することを特徴とする請求項１から３のいずれかに記載の検査装置。
前記検出部は、前記コントラクトのソースコードに、前記コントラクトとは別のプログラムの関数を呼び出す処理が記述されている場合、前記脆弱性を検出することを特徴とする請求項１から４のいずれかに記載の検査装置。