JP2023545140A - ブロックチェーンネットワークにおいてスマートコントラクトをサポートするための方法およびシステム - Google Patents

ブロックチェーンネットワークにおいてスマートコントラクトをサポートするための方法およびシステム Download PDF

Info

Publication number
JP2023545140A
JP2023545140A JP2023521921A JP2023521921A JP2023545140A JP 2023545140 A JP2023545140 A JP 2023545140A JP 2023521921 A JP2023521921 A JP 2023521921A JP 2023521921 A JP2023521921 A JP 2023521921A JP 2023545140 A JP2023545140 A JP 2023545140A
Authority
JP
Japan
Prior art keywords
vulnerability
property graph
call
code property
code
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023521921A
Other languages
English (en)
Inventor
イェンス－レネ・ギーセン
ミヒャエル・ロードラー
ルーカス・ダヴィ
セバスティアン・アンドレイナ
ガッサン・カラメ
Original Assignee
エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー filed Critical エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー
Publication of JP2023545140A publication Critical patent/JP2023545140A/ja
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/563—Static detection by source code analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

ブロックチェーンネットワークにおいてスマートコントラクトをサポートするためのコンピュータ実施方法は、スマートコントラクトのソースコードを抽象構文ツリーモデルに変換するステップと、抽象構文ツリーモデルに基づいてコードプロパティグラフを生成するステップと、抽象構文ツリーモデルから推測可能な情報を用いてコードプロパティグラフを拡充する拡充過程を実行するステップと、脆弱性検知過程を実行するステップであって、コードプロパティグラフが、1つまたは複数の所定の脆弱性を見つけるために、1つまたは複数の所定の脆弱性パターンがあるかどうか検査される、ステップと、脆弱性パッチング過程を実行するステップであって、脆弱性検知過程において見つかった脆弱性を修正するために1つまたは複数のパッチが適用され、パッチを適用されたコードプロパティグラフが生成されるように、コードプロパティグラフにパッチが挿入される、ステップとを含む。その上、ブロックチェーンネットワークにおいてスマートコントラクトをサポートするための、対応するコンピュータシステムが開示される。

Description

本発明は、ブロックチェーンネットワークにおいてスマートコントラクトをサポートするためのコンピュータ実施方法に関する。
その上、本発明は、ブロックチェーンネットワークにおいてスマートコントラクトをサポートするためのコンピュータシステムに関する。
2009年のビットコインの開始および実施から、暗号通貨は広範な受容性に達した。ビットコインは、当初は、実現技術としてブロックチェーンと呼ばれる概念を用いるピアツーピア支払いインフラストラクチャとして設計された。ブロックチェーンは、暗号的に安全な署名を使用することにより、互いを信用しない当事者が互いにトランザクションに関与することを可能にする追加専用の分散型データ構造である。データは、暗号的に安全な分散型のやり方でブロックチェーンに記憶することができ、関与するノードは、ブロックチェーンにデータを追加するために、作業の証拠または出資金の証拠などのコンセンサスプロトコルに従って、データを追加することを決定する。
ブロックチェーン技術の出現によってもたらされた新市場は、今日、2500を超える暗号通貨から成るまでに成長した。これらのいわゆるアルトコインは、ビットコインインフラストラクチャに対して代替ブロックチェーンを使用して実施される。これらのアルトコインのうちいくつかは、支払いインフラストラクチャに加えて、ブロックチェーン上でプログラムを実行するための、通常はスマートコントラクトと称される手段も提供する。スマートコントラクトを特徴とする最も顕著なブロックチェーンネットワークの1つにイーサリアムブロックチェーンがある。イーサリアムブロックチェーンにおいて、スマートコントラクトは、トランザクションがコントラクトのアドレスに送信される場合は常にトリガされる特別なバイトコード形式のプログラムである。次いで、スマートコントラクトは、トランザクションを検証してブロックチェーンに追加するものと同じノードによって、イーサリアム仮想マシン(EVM)において実行される。今日までに、イーサリアムブロックチェーン上には、ほぼ200万のスマートコントラクトが展開されている。
イーサリアムスマートコントラクトは、独自のイーサ暗号通貨を管理したり、たとえば別のアカウントにイーサを転送するかまたは他のスマートコントラクトを呼び出すために他のスマートコントラクトに対するトランザクションを生成することなどのさらなるアクションをトリガしたりすることができるので、ブロックチェーン上で自律エージェントを実施するチューリング完全なプログラムである。しかしながら、スマートコントラクトは、従来のソフトウェアと同様にプログラミングミスの影響を受けやすい。加えて、ブロックチェーンのトランザクションの性質が、スマートコントラクトのプログラミングモデルに関する間違った想定と組み合わされると、意味的ギャップが生じる。そのような間違った想定の1つには、実際のトランザクションは入れ子状のトランザクションを開始することができるのに、トランザクションが順番に実行するというものが時たまあった。これによって、スマートコントラクトにおいて、最終的に多くのバグが生じる。スマートコントラクトは、時には相当な量の暗号通貨を管理するので、直接的な金融利得のためにセキュリティ脆弱性を利用しようと目論んでいる攻撃者にとって貴重な標的である。スマートコントラクト開発に関する最初の悪名高い出来事の1つに、"TheDAO"ハックがあり、イーサは、事件当時、5000万米ドルに匹敵する損害を被った(2016年6月のRob Priceの非特許文献"Digital currency Ethereum is cratering because of a $50 million hack"参照、https://www.businessinsider.com/dao-hacked-ethereum-crashing-in-value-tens-of-millions-allegedly-stolen-2016-6において取得可能)。この点で、攻撃者はいわゆるリエントラント脆弱性を利用した。スマートコントラクトが他のスマートコントラクトにトランザクションを送信することができるので、これは、トランザクションが入れ子状のトランザクションを生成できることを意味する。リエントラント脆弱性の場合には、この事実が、被害スマートコントラクトのコードにおいてある特定のセキュリティ関連の検査を無効にするのに利用されてしまう。このため、"The DAO"ハックの場合には、攻撃者が、リエントラント脆弱性を利用して、特定の量のイーサを繰り返し引き出すことができた。
リエントラント性攻撃とは別に、2～3例を挙げると、たとえば整数オーバフローや整数アンダフローのような整数バグ、アクセス制御および入力検証バグといった他の問題が存在する。近年、スマートコントラクトにおけるセキュリティ脆弱性を防止するための新規の方法を研究するためにいくつかの努力がなされている。これらの努力は、シンボリック実行から形式的検証および静的解析に及ぶいくつかの手法に従うものである。この点に関して、以下の非特許文献が例示的に参照される。
- Christof Ferreira Torres、Julian Schutteら、"Osiris: Hunting for Integer Bugs in Ethereum Smart Contracts"、第34回Annual Computer Security Applications Conference(ACSAC18)、サンファン、プエルトリコ、米国、2018年12月3～7日、2018年、URL: http://orbilu.uni.lu/handle/10993/36757。
- Loi Luuら、"Making Smart Contracts Smarter"、2016 ACM SIGSAC Conference on Computer and Communications Securityの議事録、CCS'16、ウイーン、オーストリア: ACM、2016年、254～269頁。
- Mark Mossbergら、"Manticore: A User-Friendly Symbolic Execution Framework for Binaries and Smart Contracts"、(2019年7月)、arXiv: 1907.03890[cs.SE]。
- Sukrit Kalraら、"ZEUS: Analyzing Safety of Smart Contracts"、2018 Network and Distributed System Security Symposiumの議事録、サンディエゴ、カリフォルニア州、Internet Society、2018年。
- Petar Tsankovら、"Security: Practical security analysis of smart contracts"、2018 ACM SIGSAC Conference on Computer and Communications Securityの議事録、ACM、2018年、67～82頁。
この仕事の大部分は、スマートコントラクトを展開する前の静的解析に的を絞るものである。静的解析および検証はスマートコントラクト開発者にとって最も有用であるが、スマートコントラクトの実行中に脆弱性を識別して防止する、従来のソフトウェアにおける悪用緩和機構に類似のいくつかの動的解析手法が現われた。たとえば、リエントラント性攻撃を検知するばかりでなく、実行時間において強制されるロック機構によってリエントラント性攻撃を緩和するシステムとして、Sereumが提案された。Sereumでは、関与するすべてのノードが解析を実行しなければならず、フラグの付いたトランザクションはブロックチェーンに含まれない。同様にTorresらの非特許文献: "ZEGIS: Smart Shielding of Smart Contracts"、2019 ACM SIGSAC Conference on Computer and Communications Securityの議事録、CCS 2019、ロンドン、英国、2019年11月11～15日、Lorenzo Cavallaroらによる編集、ACM、2019年、2589～2591頁、DOI: 10.1145/3319535.3363263、URL: https://doi.org/10.1145/3319535.3363263には、脆弱性パターンが、ブロックチェーンの内部で管理され、ネットワーク参加者による投票によって可否を決定される解決策が提案されている。しかしながら、そのような動的解析手法は、ソースコードもコントラクトのバイトコードも、動的解析システムによって強制されたセキュリティポリシーを反映しないために、意味的ギャップを増大させるので、より広範囲のブロックチェーンエコシステムの中に効果的に一体化して示されてはいない。イーサリアムブロックチェーンが、展開されたスマートコントラクトのコードに対するいかなる変更も設計によって防止するので、脆弱性の検知は、そのままで特に重要なトピックである。したがって、スマートコントラクトにおいて脆弱性が発見されたとしても、スマートコントラクトをアップグレードすることは容易ではない。しかしながら、コントラクトが、コントラクトをアップグレード可能にするために必要な機能をエミュレートすることを可能にする、ある特定のコードパターンおよびイーサリアムプラットフォームの機能がある。しかしながら、必要に応じてこのパターンを正確に適用することは、コントラクト開発者の責任である。よって、スマートコントラクトにおけるあらゆるバグの危険性を所与として、スマートコントラクトのコードを強化することが重要である。
Rob Price、"Digital currency Ethereum is cratering because of a $50 million hack"、第34回Annual Computer Security Applications Conference(ACSAC18)、サンファン、プエルトリコ、米国、2018年12月3～7日。2018年。URL:http://orbilu.uni.lu/handle/10993/36757。 Christof Ferreira Torres、Julian Schutteら、"Osiris: Hunting for Integer Bugs in Ethereum Smart Contracts"、第34回Annual Computer Security Applications Conference(ACSAC18)、サンファン、プエルトリコ、米国、2018年12月3～7日、2018年、URL: http://orbilu.uni.lu/handle/10993/36757 Loi Luuら、"Making Smart Contracts Smarter"、2016年ACM SIGSAC Conference on Computer and Communications Securityの議事録。CCS'16。ウイーン、オーストリア: ACM、2016年、254～269頁。 Mark Mossbergら、"Manticore: A User-Friendly Symbolic Execution Framework for Binaries and Smart Contracts"、(2019年7月)、arXiv: 1907.03890[cs.SE] Sukrit Kalraら、"ZEUS: Analyzing Safety of Smart Contracts"、2018年Network and Distributed System Security Symposiumの議事録、サンディエゴ、カリフォルニア州、Internet Society、2018年 Petar Tsankovら、"Security: Practical security analysis of smart contracts"、2018 ACM SIGSAC Conference on Computer and Communications Securityの議事録、ACM、2018年、67～82頁。 Torresら、"ZEGIS: Smart Shielding of Smart Contracts"、2019 ACM SIGSAC Conference on Computer and Communications Securityの議事録、CCS 2019、ロンドン、英国、2019年11月11～15日、Lorenzo Cavallaroらによる編集、ACM、2019年、25892591頁、DOI: 10.1145/3319535.3363263、URL:https://doi.org/10.1145/3319535.3363263 Nicola Atzei、Massimo Bartoletti、およびTiziana Cimoli、"A Survey of Attacks on Ethereum Smart Contracts (SoK)"、Lecture Notes in Computer Science、雑誌の略称: Lecture Notes in Computer Science; Springer Berlin Heidelberg、2017年、164～186頁、DOI: 10.1007/978-3-662-54455-6_8、http://dx.doi.org/10.1007/978-3-662-54455-6_8において取得可能
したがって、上記の観点から、本発明の目的は、ブロックチェーンネットワークにおけるスマートコントラクトをサポートするための、初めに説明されたタイプの方法およびコンピュータシステムを、可能性のある脆弱性を特に改善するために、スマートコントラクトを効率的に強化するようなやり方で改善してさらに発展させることである。
本発明によれば、前述の目的は、ブロックチェーンネットワークにおけるスマートコントラクトをサポートするためのコンピュータ実施方法によって達成され、この方法は、
スマートコントラクトのソースコードを抽象構文ツリーモデルに変換するステップと、
抽象構文ツリーモデルに基づいてコードプロパティグラフを生成するステップと、
抽象構文ツリーモデルから推測可能な情報を用いてコードプロパティグラフを拡充する拡充過程を実行するステップと、
脆弱性検知過程を実行するステップであって、コードプロパティグラフが、1つまたは複数の所定の脆弱性を見つけるために、1つまたは複数の所定の脆弱性パターンがあるかどうか検査される、ステップと、
脆弱性パッチング過程を実行するステップであって、脆弱性検知過程において見つかった脆弱性を修正するために1つまたは複数のパッチが適用され、パッチを適用されたコードプロパティグラフが生成されるように、コードプロパティグラフにパッチが挿入される、ステップと
を含む。
その上、前述の目的は、ブロックチェーンネットワークにおいてスマートコントラクトをサポートするためのコンピュータシステムによって達成され、このシステムが備える記憶装置および1つまたは複数のプロセッサは、単独で、または組み合わせて、方法を実行するように構成され、この方法は、
スマートコントラクトのソースコードを抽象構文ツリーモデルに変換するステップと、
抽象構文ツリーモデルに基づいてコードプロパティグラフを生成するステップと、
抽象構文ツリーモデルから推測可能な情報を用いてコードプロパティグラフを拡充する拡充過程を実行するステップと、
脆弱性検知過程を実行するステップであって、コードプロパティグラフが、1つまたは複数の所定の脆弱性を見つけるために、1つまたは複数の所定の脆弱性パターンがあるかどうか検査される、ステップと、
脆弱性パッチング過程を実行するステップであって、脆弱性検知過程において見つかった脆弱性を修正するために1つまたは複数のパッチが適用され、パッチを適用されたコードプロパティグラフが生成されるように、コードプロパティグラフにパッチが挿入される、ステップと
を含む。
本来のC/C++ソフトウェアのための防衛機構を実施するために、大抵の場合、実行時間またはコンパイラ依存のポリシーが使用される。しかしながら、本発明によれば、スマートコントラクトを強化する状況では、スマートコントラクトの開発者は、自分のスマートコントラクトに対して意味変化を検討すること望むことが最初に認識されている。本発明の実施形態は、実行時環境またはバイトコード計測の意味を変更することによって強固にするポリシーを強制するのではなく、スマートコントラクトを効率的なやり方で自動的に強化するための最も平明なやり方として、ソースコードを書き換えることを主張するものである。ソースコードを書き換えることは、スマートコントラクトの検査性を維持し、スマートコントラクトの開発担当者に、変更および同変更の含意を容認し続けさせてもよい。そのために、本発明によれば、スマートコントラクトのソースコードは、特にコンパイラエンティティによって、抽象構文ツリーモデルに訳される/変換される。次いで、抽象構文ツリーモデルがコードプロパティグラフに変換され、これが、検査されるスマートコントラクトを解析するために使用されてもよい。その上、抽象構文ツリーモデルから/抽象構文ツリーモデルによって推測可能な情報を用いて、コードプロパティグラフを拡充する拡充過程が実行される。次いで、脆弱性検知過程を実行することにより、コードプロパティグラフが、1つまたは複数の潜在的な所定の脆弱性を見つけるために、1つまたは複数の所定の脆弱性パターンがあるかどうか検査される。所定の脆弱性パターンが発見されると、脆弱性パッチング過程が実行され、脆弱性検知過程で見つかった1つまたは複数の脆弱性を修正するために、1つまたは複数の所定のパッチが適用される。パッチを適用されたコードプロパティグラフが生成されるように、コードプロパティグラフにパッチが直接挿入される。
したがって、本発明は、ブロックチェーンネットワークにおいてスマートコントラクトをサポートするための方法およびシステムを提供するものであり、スマートコントラクトは、コントラクトにおける潜在的な脆弱性を改善して解消することができるように効率的に強化される。
本発明の実施形態によれば、ブロックチェーンネットワークはノードを有する分散ネットワークでもよく、ブロックチェーンにより、各ノードが、暗号的に安全な署名を使用することによって互いにトランザクションに関与することが可能になる。したがって、ブロックチェーンは、暗号的に安全な署名を使用することにより、互いを信用しない当事者が互いにトランザクションに関与することを可能にする追加専用の分散型データ構造でもよい。データは、ブロックチェーン上に、暗号的に安全なやり方で分散して記憶されてもよく、関与するノードは、ブロックチェーンにデータを追加するために、作業の証拠または出資金の証拠などのコンセンサスプロトコルに従って、追加するデータを決定する。
本発明の実施形態によれば、スマートコントラクトのアドレスにトランザクションが送信される場合は常に、スマートコントラクトがトリガされてもよい。スマートコントラクトは、ブロックチェーンに対してトランザクションを検証して追加するブロックチェーンノードによって、仮想マシンにおいて実行されてもよい。したがって、スマートコントラクトは、トランザクションがコントラクトのアドレスに送信される場合は常にトリガされる特別なバイトコード形式のプログラムでもよい。
本発明の実施形態によれば、コードプロパティグラフは、データフローグラフ、制御フローグラフおよび/またはドミネータツリーを組み合わせた表現を含んでもよい。したがって、コードプロパティグラフは、コードの3つのグラフ表現をジョイントデータ構造に合併させてもよい。よって、コードプロパティグラフ(CPG)は、一般に静的解析によって実現されてもよいプログラム上で種々の見込みを統一するプログラムの表現である。コードプロパティグラフの概念の主な利点は、企画されるグラフが言語依存でないことである。これによって、特定の言語でなくてもグラフ用の解析を書くことができるので、多くのタイプの解析を再利用することが可能になる。
本発明の実施形態によれば、拡充過程を実行するステップは呼出し解析を含んでもよい。呼出し解析は、コードプロパティグラフにおけるすべての関数呼出し式にわたって繰り返すステップと、それぞれの外部関数呼出しに、呼出しラベルを割り当てるステップを含んでもよい。したがって、脆弱性検知過程において効率的に適用され、かつ使用されるための適切な情報を収集することができる。
本発明の実施形態によれば、拡充過程を実行するステップはcontains-call-analysisを含んでもよい。contains-call-analysisは、関数呼出しを見つけるためにコードプロパティグラフにおけるすべてのステートメントのサブ表現を解析するステップと、関数呼出しを有する各ステートメントに呼出しラベルを割り当てるステップとを含んでもよい。したがって、脆弱性検知過程において効率的に適用され、かつ使用されるための適切な情報を収集することが可能である。
本発明の実施形態によれば、拡充過程を実行するステップはwrite-state-analysisを含んでもよい。write-state-analysisは、スマートコントラクトの状態変数を変化させるすべてのステートメントを収集するステップと、収集されたステートメントおよびそれらの環境関数にwrites-state-labelを割り当てるステップとを含んでもよい。write-state-analysisは、状態変数を更新する/書き込む関数を呼び出すすべての内部関数呼出しを収集するステップと、収集された内部関数呼出しおよびそれらの環境関数にwrites-state-labelを割り当てるステップとをさらに含んでもよい。したがって、脆弱性検知過程において効率的に適用され、かつ使用されるための適切な情報を収集することが可能である。
本発明の実施形態によれば、脆弱性パターンが所定の脆弱性に関連付けられてもよい。所定の脆弱性は、リエントラント性、整数オーバフローバグおよび/または整数アンダフローのバグを含んでもよい。したがって、スマートコントラクトにおける重要な潜在的脆弱性を検知するための脆弱性パターンが考慮に入れられる。
本発明の実施形態によれば、脆弱性パターンがCPGサブグラフの形式で表現されてもよい。その上、脆弱性検知過程を実行するステップは、スマートコントラクトのコードプロパティグラフの内部のCPGサブグラフを検索するステップを含んでもよい。したがって、コードプロパティグラフ(CPG)の概念を導入することができ、脆弱性を表す特定のサブグラフの検索として脆弱性を定式化することが可能になる。よって、効率的な脆弱性検知が提供される。一旦、コードプロパティグラフの拡充過程が完了すれば、脆弱性検知過程において脆弱性パターンの検査が実行されてもよい。これらの脆弱性パターンは、コードプロパティグラフの種々のサブグラフの形式で表現されてもよい。コードプロパティグラフにおける特定のサブグラフの存在は、スマートコントラクトが、関連する脆弱性に侵されやすいことを指示する。脆弱性に関連したすべてのパターンが一旦見つかったら、脆弱性発見(すなわち脆弱性検知過程)を終了して脆弱性パッチング過程を開始することができる。
本発明の実施形態によれば、脆弱性検知過程を実行するステップは、状態を書き込むステートメントswおよび環境関数fについてコードプロパティグラフを照会するステップを含んでもよい。次いで、関数fの制御フローを考慮に入れて、コードプロパティグラフにおいて、外部関数呼出しceからswに過渡的に通じるceが検索されてもよい。swによって扱われる状態変数svも取り込まれる。そのようなパターンが見つかったら、スマートコントラクトに属してsvに書き込むすべての関数fcに関する脆弱性検知過程において、コードプロパティグラフも照会されてもよい。したがって、リエントラント脆弱性が効率的に検知されてもよい。そのために、状態変数svと、状態変数svに書き込むステートメントswと、ステートメントswの環境関数fと、fの制御フローを考えると外部関数呼出しceからswに過渡的に通じるceと、svに書き込むクロス関数fcのセットとを含むリエントラント脆弱性パターンが検索されてもよい。
本発明の実施形態によれば、脆弱性検知過程において、状態を書き込むステートメントswおよび環境関数fについてコードプロパティグラフが照会されてもよい。生成ベースのリエントラント性検知は、外部呼出しの代わりに、fの制御フローを考えるとコンストラクタ呼出しccからswに過渡的に通じるccを検索してもよい。CPGベースの解析により、呼び出されているコンストラクタを解析することが可能になる。このようにして、この脆弱性が報告されるのは、コンストラクタが外部呼出しを含有している場合のみであってもよい。外部コールがなければリエントラント性が生じることはないので、これは有効である。コンストラクタが外部関数を呼び出す場合には、同一のコントラクトに属してsvにも書き込むすべての関数について、制御プロパティグラフが再び照会されてもよい。したがって、リエントラント脆弱性を効率的に検知することが可能である。
本発明の実施形態によれば、パッチを適用するために脆弱性パッチング過程を実行するステップは、コードプロパティグラフにおける状態変数としてsv用のロック変数lsvをもたらすステップを含んでもよい。これは、svが既にロック変数を有するかどうかの検査を含んでもよい。ロック変数を有しなければ、ロック変数lsvが生成される。ロック変数lsvのタイプはsv自体のタイプに依拠してもよく、たとえば、svがuint256のような基本タイプを有する場合にはlsvはブールタイプになるが、マッピングタイプについては、値のタイプのみがブールタイプになる。lsvが見つかるかまたは制御プロパティグラフに挿入された後に割当てステートメントが生成され、これがlsvの状態を設定してもよい。そのために、ロックステートメントlock_lsvがlsvの状態の値をトルーに設定してもよく、アンロックステートメントunlock_lsvがこの値をフォールスに設定してもよい。次いで、関数fの制御フローは、ロックステートメント、外部呼出し、およびアンロックステートメントがlock_lsv→ce→unlock_lsvと互いに直接後続するように変更される。制御フローが変更された後に、lsvがアンロックであることを検査して関数fの先頭にlsvを挿入するガードが生成されてもよい。ガードの生成および挿入は、svに書き込むすべての他の関数fcにも生じてもよい。したがって、リエントラント脆弱性が効率的にパッチングされてもよい。
本発明の実施形態によれば、個々の脆弱性パターンに対して所定のパッチが特別に作成されてもよい。したがって、本発明の実施形態は、スマートコントラクトにおける脆弱性を、ソースコードレベルで効率的なやり方で検知して修正するための斬新な手法に関するものである。本発明の実施形態が導入するコードプロパティグラフ(CPG)の概念により、脆弱性を表す特定のサブグラフの検索として脆弱性を定式化することが可能になる。それらの脆弱性に対するソースレベルパッチを自動的に生成するために、コードプロパティグラフが導入されてもよい。
したがって、本発明の実施形態は、ソースコードレベルにおいてスマートコントラクトの脆弱性に自動的にパッチを入れるために、コードプロパティグラフを使用して、ソースコードにおける特定のサブグラフを検索するステップを含んでもよい。本発明の実施形態は、パッチング過程中に、すべての脆弱性を修正するパッチを適用し、それらをCPGに直接挿入する。上記の場合には、本発明の実施形態は、新規のソースコードを生成するために、パッチを入れられたCPGをくまなく調べる。次いで、パッチを入れられたスマートコントラクトは、コントラクトが、良性のトランザクションに対して適切に作用して攻撃を防止することを保証するために、すべての既知のトランザクションに対して検査されてもよい。
本発明の実施形態によれば、1つまたは複数の適用されたパッチを組み込むスマートコントラクト用の新規のソースコードを生成するために、パッチを入れられたコードプロパティグラフがくまなく調べられる。
以下で、さらなる機能、利点およびさらなる実施形態が説明され、明らかになるであろう。
本発明の実施形態は、スマートコントラクトの脆弱性を自動的に見つけてパッチを入れるツールチェーンとして実施される強化コントラクトコンパイラ(HCC)のコンピュータシステムを提供してもよい。パッチはソースコードに適用され、ソースコードの検査性が保たれる。これによって、開発者は、たとえば手作業のコード再検討、正規の検証または他の解析ツールといった、以前に使用したのと同一の方法を使用して、HCCによって導入された変更を検証することができる。従前の静的解析ツールとは対照的に、HCCは、ある特定のクラスのバグに対してスマートコントラクトを十分に強化するようにも努める。本開示では、主に、リエントラント脆弱性ならびに整数オーバフローおよびアンダフローのバグなどの特定の脆弱性の自動検知および防止に的が絞られている。しかしながら、HCCは、モジュール式フレームワークに設計される場合があることにより、最小限の作業で、さらなる脆弱性検知およびパッチングプロシージャを実施することが可能になる。この目的のために、コードプロパティグラフ(CPG)に基づいて静的ソースコード解析手法が実施され、これによって、プログラムを表す一般化グラフ上の照会として脆弱性検知を定式化することが可能になる。スマートコントラクト開発者は、スマートコントラクトを開発して強化パッチを自動的に導入してから展開する間に、HCCを使用することを意図してもよい。しかしながら、HCCシステムは、(たとえばZeppelinOSフレームワークを使用して)アップグレード可能なコントラクトとして開発されている既に展開されたコントラクトの手作業のパッチング作業の流れを促進するためにも利用されてもよい。
コントラクトの変更に関する検査性を維持することが目標であるので、本発明の実施形態によるHCCは、入力としてソースコードを使用し、生成されたソースコードを出力として発行する。このように、開発者は、HCCが良性のトランザクションに影響を与える意味変化を導入しないことを保証することができ、したがって挙動的な一貫性が維持される。中間にいくつかのステップがなされてもよい。最初に、ソースコードが抽象構文ツリー(AST)に変換される。次いで、ASTがコードプロパティグラフ(CPG)に変換される。CPGは、制御フローグラフ(CPG)と、データフローグラフ(DFG)と、ドミネータツリー(DT)との組み合わされた表現である。この表現は、たとえばエイリアス解析といったいくつかの解析を処理するために使用されることが可能である。CPGは、現段階ではASTを表すのみであるため、そのような解析を可能にするためにASTによって推論されることが可能であるすべての情報を用いて拡充されてもよい。その後、ある特定の脆弱性に類似した、CPG内のサブグラフを見つけるために、パターンベースの手法が続く。これらのサブグラフは脆弱性の候補と見なされる。HCCコンピュータシステムは、このサブグラフがパッチを必要とするかどうかを判断するために、特定のこの脆弱性の防止機構の不在を検証してもよい。候補が実際の脆弱性であると判明したら、HCCは、見つかったパターンに基づいてパッチを自動的に適用する。HCCは、それぞれの発見された脆弱性に対してパッチを適用した後に、パッチを組み込んだ新規のソースコードを生成するためにCPGをくまなく調べる。
したがって、本発明の実施形態は、スマートコントラクトにおける脆弱性をソースコードレベルで検知して修正するための斬新な手法を提供してもよい。この手法が導入するコードプロパティグラフ(CPG)の概念により、脆弱性を表す特定のサブグラフの検索として脆弱性を定式化することが可能になる。その上、それらの脆弱性に対するソースレベルパッチを自動的に生成するために、CPGが導入されることが可能である。
本発明の実施形態は、Solidityスマートコントラクトにおけるリエントラント性ならびに整数オーバフローおよびアンダフローの脆弱性を検知してパッチを入れることを可能にしてもよい。
その上、本発明の実施形態は、スマートコントラクト境界にわたって働く解析およびパッチングのツールを提供してもよい。
本発明の教示を有利なやり方で設計してさらに発展させるための、いくつかのやり方がある。この目的のために、一方では請求項1の従属請求項が参照され、他方では、例として図によって示される本発明のさらなる実施形態の以下の説明が参照される。図の助けを借りた本発明のさらなる実施形態の説明に関連して、本教示のさらなる実施形態およびさらなる発展が全体的に説明される。
本発明の一実施形態ためのソースコードの例を例示的なアプリケーションシナリオの概略図とともに示す図である。アプリケーションシナリオは、SimpleDAOコントラクトにおけるリエントラント脆弱性に対する攻撃を表し、第2の検査(2)は、一貫性のない内部状態において実行されるので通り抜ける。 本発明の一実施形態による方法およびシステムを示す概略図である。この実施形態は、リエントラント脆弱性の自動発見およびパッチングためのツールチェーンを備える強化コントラクトコンパイラ(HCC)のアーキテクチャを提供するものである。
イーサリアムスマートコントラクトは、セキュリティ脆弱性に通じてしまういくつかのタイプのバグに苦しめられている。Nicola Atzei、Massimo Bartoletti、およびTiziana Cimoliの非特許文献、"A Survey of Attacks on Ethereum Smart Contracts (SoK)"、Lecture Notes in Computer Science、雑誌の略称:Lecture Notes in Computer Science; Springer Berlin Heidelberg、2017年、164～186頁、DOI: 10.1007/978-3-662-54455-6_8は、http://dx.doi.org/10.1007/978-3-662-54455-6_8において取得可能であり、有名な脆弱性および攻撃に関する調査を提示している。攻撃は、"KotET"コントラクトなどのDoSから、Parity Multi-Sigウォレットの事例であった、イーサを利用できなくなること、そして、攻撃者がイーサを盗むことができるまでに及ぶ。"TheDAO"ハックの悪名高い事例では、攻撃者は、脆弱なコントラクトから莫大な額のイーサを転送することができた。"TheDAO"に対する攻撃が可能であったのは、リエントラント脆弱性として知られているバグのせいである。
コントラクトが外部コントラクトを呼び出すとき、この外部コントラクトが、同一のトランザクションの中で、呼出しコントラクトを再び呼び出すと、リエントラント性が生じる。それゆえ、1つのトランザクションの中でコールグラフA→B→Aが観測される。リエントラント性は、引出しパターンおよび他のいくつかのプログラムパターンに必要不可欠であるが、注意深く実施しないと悪用されてしまう。"TheDAO"に対する悪名高い攻撃は、実施が脆弱であるとイーサのすさまじい損失に結びつく様子を明示したものである。
安全なリエントラント性をサポートするために、Solidityは、別のコントラクトを呼び出すための、transfer、sendおよびcallといった、複数の高レベルの概念をサポートする。上記の3つは、すべてEVMレベルのCALL命令として実施されるが、転送および送信の機能は制限された額のGasしか提供しないという点において異なる。このようにGasの額を制限すれば、呼び出されたコントラクトがさらなる呼出しの実行などの他の高額Gasの命令を実行するのを防止する。しかしながら、間違ったタイプの呼出しを使用するとリエントラント脆弱性に通じてしまう。
コントラクトが、予想外に再入され、いくつかの一貫性のない内部状態に依拠して作用するとき、リエントラント脆弱性が生じる。図1は、http://dx.doi.org/10.1007/978-3-662-54455-6_8において取得可能な非特許文献Nicola Atzei、Massimo Bartoletti、およびTiziana Cimoli、"A Survey of Attacks on Ethereum Smart Contracts (SoK)"による"TheDAO"コントラクトの簡略版であり、元の"TheDAO"コントラクトと同一のリエントラント脆弱性を示す。したがって、図1は、本発明の一実施形態に関する例示的なアプリケーションシナリオを示す概略図であり、このアプリケーションシナリオは、SimpleDAOコントラクトのリエントラント脆弱性に対する攻撃を表すものである。SimpleDAOコントラクトは、出資者がSimpleDAOに出資した額のイーサを記録する内部状態を維持する。出資者は、withdraw関数を使用して引き出すことを許容される。withdraw関数は、(1)その出資者は、要求した額のイーサのwithdrawを許容されるかどうか検査するステップと、(2)その出資者にイーサの額を送信するステップと、(3)内部状態を、その出資者がこの時点でSimpleDAOコントラクトにおいて出資しているイーサが減ったということに更新するステップとの、3つのステップを実行しなければならない(図1参照)。脆弱なSimpleDAOでは、(3)において状態を更新する前にステップ(2)が実行されてしまうことに留意されたい。これは、悪意のある出資者がコントラクトに再入してwithdrawをもう一度呼び出せてしまうことを意味し、これは検査(2)を再び呼び出す。しかしながら、内部状態は、以前のwithdraw呼出しにおける引出しを反映するための更新がなされていないので、攻撃者は、検査を通り抜けて、その額を再び引き出すことを許容されてしまう。内部状態が更新されるのは、最後においてのみである。
攻撃者は、全体のSimpleDAOコントラクトのイーサが流出するまでリエントラント性を繰り返すことができる。図1の例を補正するには、(3)が(2)よりも先に実行されるように、ライン3と4(図1によって表されたソースコードの例参照)が交換される。このように、(1)の第2の呼出しが一貫した状態において動作するので、検査は役に立たないはずである。
図1の例は従来のリエントラント脆弱性を説明するものである。しかしながら、リエントラント性は、以下のように、いくつかの異なる脆弱性パターンに従う可能性がある。
- 図1の例によって説明されるような従来のリエントラント性。
- 被害コントラクトの2つのパブリック関数が、同一の状態に別個に書き込む、クロス関数型リエントラント性。これらの関数は、単独で使用されるときには従来のリエントラント性を許す必要はない。
- 3つのコントラクトが含まれ、そのうち1つが被害コントラクトによってライブラリとして使用される代表型リエントラント性。ライブラリに包含される関数や被害コントラクトが従来のリエントラント性を許さないとしても、それらの関数の組合せがリエントラント性を可能にすることはあり得る。このことは、別々の関数において状態更新および外部呼出しが生じ、1つの関数が被害コントラクトからのものであって、代表がその関数を呼び出すときには常に生じる。
代表型リエントラント性は、以下のように、2つの異なるやり方で生じる可能性がある。(i)代表型呼出しが生じる前に外部呼出しが生じる。代表型呼出しは、呼び出された状況において作動するので、関数の状態変数を変更する可能性がある。本開示では、これは「代表型ケース(i)のリエントラント性」と称される。(ii)状態更新が実行される前に代表型呼出しが生じる。代表型呼出し関数は外部関数を呼び出す可能性があるので、このケースは、上記で説明されたように、従来のリエントラント性またはクロス関数型リエントラント性と同一に扱われることが可能である。本開示では、これは「代表型ケース(ii)のリエントラント性」と称される。
- コントラクトが状態更新を実行する前に新規コントラクトを生成するとき生じる得る生成ベースのリエントラント性。新たに生成されるコントラクトのコンストラクタは、ことによると、悪意のあるコントラクトに対する外部呼出しを実行する可能性がある。
これらの脆弱性パターンには、状態更新が外部呼出しの後に生じるという共通の挙動があり、コントラクトが再入されるとき、一貫性がない状態をもたらす。
本開示は主にリエントラント脆弱性に的を絞るが、本発明の実施形態は他の脆弱性まで拡張できるように設計される。スマートコントラクトにおけるリエントラント脆弱性を検知するための多くの手法が存在する。これらのツールの多くは、パス爆発に通じるシンボリック実行に依拠するものである。しかしながら、多くの既知のツールがEVMレベルにおいて作業するので、不正確という欠点があることが分かった。既に展開されているコントラクトに集中し、EVMレベルで解析することによって不正確になるか、または、既知のツールでは、一般に、特定のリエントラント性パターンを検知できない。
本発明の実施形態によれば、リエントラント脆弱性に対する可能な修正は、状態変数用のロックを使用することによって実施されることが可能である。バイトコードの解析は、EVMレベルには利用可能なタイプ情報がないので、フィールド感度が不足して信頼性が失われるという欠点がある。このように、信頼性が失われると、EVMレベルで必要なものより多くの、記憶域のロックに結びつく可能性がある。信頼性喪失のために必要以上に記憶域がロックされてしまうと、誤検出がより多くなる。代わりにソースコードを解析すれば、タイプ情報が利用可能であり、信頼性喪失を防止することができる。したがって、実施形態によれば、バイトコードレベルで生成されたパッチに関して縮小されたオーバヘッドを有するパッチを提供するために、ソースコードパッチングに的が絞られる。開発者は、ソースコードパッチングにより、スマートコントラクトを展開する前に、本発明の一実施形態によって追加された修正を評価することがさらに可能になる。現在まで、大抵の解決策はバイトコードレベルのパッチングに的を絞ったものであってオーバヘッドが大きくなり、また、バイトコードレベルでのみ実行されるので、パッチによって導入された正確な修正を開発者が調査するのを妨げていた。
既知の防御機構は、そのポリシーを実施するために、大抵の場合コンパイラベースの計測機構を利用する。そのような手法は、もたらされる2進数がソースコードを反映するばかりでなく、(コンパイラ依存の)ポリシーも行うので、不透過性の欠点がある。これは、多くのアプリケーション領域において許容される可能性はあるが、スマートコントラクトの開発者は、さらなる透過性と、コントラクトコードにわたる制御とを必要とする。したがって、計測機構を使用する代わりに、本発明の実施形態に従ってソースコードを書き換えることにより、ソースコードの検査性および変更可能性が維持される。本発明の実施形態によるソースコードパッチのオーバヘッドはまた、大抵の場合かなり小さく、脆弱性を効果的に緩和するのに必要なコードはほんの数行である。したがって、ソースコードを書き換えることにより、開発者は、たとえば、手作業のコード再検討、正規の検証または他の解析ツールといった、以前にできたのと同一の方法を使用して、実施形態による変更を検証することができる。
本発明の実施形態は、開発者がリエントラント性攻撃を受けやすいスマートコントラクトを展開するのを防止するために、ソースコードにおけるリエントラント脆弱性を自動的に見つけて修正する、したがって検査性を維持する、ツールチェーンとしての強化コントラクトコンパイラ(HCC)を表す。本開示は、主にリエントラント脆弱性ならびに整数オーバフローおよびアンダフローの自動検知および防止に的を絞っているが、本発明の実施形態によるCPGベースの手法は、他の種類の脆弱性に対する拡張の余地がある設計が可能である。HCCの主要目的は、スマートコントラクトに関するセキュリティ解析を可能にして、開発者が新規の安全なスマートコントラクトを開発するのを支援することである。しかしながら、実施形態によるコンパイルツールチェーンは、既に展開されているコントラクトに対する手作業のパッチング作業の流れを容易にするためにも利用することができる。
図2は、本発明の一実施形態による方法およびシステムを示す概略図を示し、この実施形態は、リエントラント脆弱性の自動発見およびパッチングためのツールチェーンを備える強化コントラクトコンパイラ(HCC)のアーキテクチャを提供するものである。スマートコントラクトのソースコードの書換えは、複数の過程において自動的に生じ得る。
図2に示されるように、HCCは、入力としてスマートコントラクトのソースコードを採用する。最初に、ソースコードは、解析を容易にするモデルに変換されなければならない。ソースコードは、最初に、コンパイラによって抽象構文ツリー(AST)モデルへと変換され、次いで、コードプロパティグラフ(CPG)の基本形式を構築するために解析される。CPGは、一般に静的解析によって実現される、プログラムに対する種々の観点を統一するプログラムの表現である。次いで、CPGは、ASTから既に推論されている可能性がある情報を用いて拡充される。しかしながら、この状態では、CPGは、基本的にASTの別の表現でしかなく、それゆえ、それ自体に基づいて既に拡張済であり得る。その後、CPGは、たとえばデータの流れに関する情報といった、多くの解析のために必要な基本情報を含む。
自明に、脆弱性は、パッチを入れることが可能となる前に先ず見つけられなければならない。一旦、CPG拡充過程が完了すると、HCCは、脆弱性検知過程において脆弱性パターンを検査する。これらの脆弱性パターンは、CPGの種々のサブグラフの形式で表現することができる。CPGにおける特定のサブグラフの存在は、コントラクトが、関連する脆弱性に侵されやすいことを指示する。一旦、脆弱性に関連したすべてのパターンが見つかると、脆弱性発見が終了して脆弱性パッチング過程が始まる。
脆弱性パッチング過程中に、HCCは、この脆弱性を修正するパッチを適用してCPGに直接挿入する。それらのパッチは、個々の脆弱性パターンに対して特別に作成されたものである。パッチを設計して適用するとき、HCCによって適用される修正が、いかなる望ましい機能性も壊さないことを保証することが重要であり、たとえばコントラクトのビジネスロジックは無傷のままでなければならない。
脆弱性パッチング過程は、以前に見つかったすべての脆弱性に対してパッチング方式を適用した後に終了する。上記の場合には、HCCは、新規のソースコードを生成するために、パッチを入れられたCPGをくまなく調べる。書き換えられたソースコードは、次いで、さらなる検討および検証またはコンパイルが実行可能である。
基本的なCPG構造:図2に示されるように、基本的なCPGの構造はソースコードのASTを導入する。ASTの情報はソースコードのすべての高レベルの詳細を含むが、ASTの個々の構成要素は非常に粒状である。これは、HCCが、部分式レベルでコードを解析することができ、コントラクト境界にわたって解析することもできることを意味する。
CPG拡充:HCCは、CPG拡充過程中に、基本的なCPGが既に含有している情報を利用していくつかの解析を行うことができる。この過程中に、CPGの情報は、より高度な解析が可能になるように拡張される。HCCの場合には、拡充過程は、リエントラント性検知のための関連情報を、さらなる解析のためによりアクセス可能にする複数の解析を含んでもよい。拡充過程は、より高度な脆弱性検知の先行モデルとして役立つ。
以下では、主に、リエントラント脆弱性ならびに整数のオーバフローおよびアンダフローのバグに的を絞る。したがって、HCCにおけるCPG拡充過程は以下の解析を含んでもよい。
Call-Analysis:リエントラント脆弱性を検索するときには、外部関数呼出しがスマートコントラクトコードのどこで生じるかを正確に知っていることが重要である。これを実現するために、HCCは、CPGにおけるすべての関数Call表現を繰り返し、それぞれの呼出しにExternalcallのラベルを付ける。外部呼出しは、別のコントラクトの関数が直接呼び出されるとき、またはタイプaddressに関連したcallおよびdelegatecallの関数を使用する場合に生じるすべての呼出しである。後者は、ExternalcallばかりでなくDelegatecallとしてもラベルを付けられる。これは、上記で導入された、従来のクロス関数型リエントラント脆弱性パターンおよび代表型リエントラント脆弱性パターンを検知するのに十分である。HCCは、生成ベースのリエントラント性も検知するために、生成されているタイプが別のコントラクトによって定義される場合には、CPGにおいてConstructorcallとしてNewExpressionsのラベルを付ける。NewExpresslonを使用して新規のコントラクトを生成するために、スマートコントラクトのコードはCPGにおいて利用可能である必要があり、これによって、コントラクト境界にわたって関数を解析することが可能になる。
HCCは、すべての関数呼出しにラベルを付けた後に、適切な場合には、ContainsDelegateCall、ContainsExternalCallおよびContainsConstructorCallを用いてそれらを含有している関数にラベルを付ける。HCCがCPGにおけるすべての関数呼出しにわたって繰り返すこと、またそれらの関数呼出しの環境関数は別のコントラクトの一部である場合があることに留意されたい。これは、Constructorcallによって呼び出される関数が、この解析の対象であるか、または関数呼出しを含有していないことを意味する。
Contains-Call-Analysis:HCCは、前述の呼出し解析を用いて、表現レベルにおいて関数呼出しを解析した。しかしながら、大抵の表現はステートメントのサブ表現であり、また不必要なことではあるが、これは関数呼出しのケースでもあり得る。ステートメントがCPGにおける関数の極小の(基本ブロックと同等の)制御フローユニットとして扱われるので、脆弱性検知およびパッチングの過程中にステートメントレベルにおいて関数呼出しについて推論するのがより容易である。したがって、HCCは、関数呼出しを見つけるためにCPGにおけるすべてのStatementのサブ表現を解析して、Statementに適切にラベルを付ける。
Write-State-Analysis:被害コントラクトが、一貫性がない状態に放置されると、リエントラント脆弱性が生じる。以前に説明されたように、こうなるのは、外部呼出しの後、状態が更新される前に、コントラクトが予想外に再入される場合である。HCCは、脆弱性検知過程において状態を更新するステートメントを効果的に見つけるために、次の2ステップの手法に従ってもよい。
HCCは、第1の解析ステップにおいて、コントラクトの状態変数を変更するすべてのステートメントを収集する。次いで、収集されたステートメントおよびそれらの環境関数にWritesStateのラベルが付けられ、扱われる状態変数に対してエッジが追加される。このエッジはWRITESのラベルを有する。
書込み状態解析の第2のステップにおいて、HCCは、コントラクト状態を更新する関数を呼び出す、すべての内部の関数呼出しを収集する。それらの呼出しおよびそれらの環境関数は、上記のステートメントに類似のラベルおよびエッジを受け取るが、この第2のステップは、CPGに新規のラベルが追加されなくなるまで繰り返される。
明らかになるように、CPG拡充過程はHCCの使用事例に向けて調整される。他の種類の脆弱性の検知は別の必要性を有する可能性があり、それらの必要性に対してCPG拡充が拡張されてもよい。
脆弱性検知
本発明の実施形態による脆弱性検知過程において、HCCはコードプロパティグラフにおける種々の脆弱性パターンを検索する。脆弱性パターンと一致するサブグラフが見つかったときは常に、包含されるグラフノードが収集され、新規の脆弱性ノードがCPGに挿入される。この脆弱性ノードは、包含されるすべてのグラフノードに対してエッジを有する。エッジの数、ラベルおよび意味は、見つかった脆弱性の種類に依拠する。
リエントラント性の検知:リエントラント脆弱性の検知は次のように実施されてもよい。最初に、HCCは、状態を書き込むステートメントswおよび環境関数fについてCPGを照会する。次いで、HCCは、fの制御フローを考えると外部呼出しceからswに過渡的に通じるceを検索する。HCCは、swによって扱われる状態変数svも取り込む。そのようなパターンが見つかると、HCCは、同一のコントラクトに属してsvにも書き込むすべての関数fcについてCPGを照会する。この手法は、従来のリエントラント性ならびにクロス関数リエントラント性および代表型ケース(ii)のリエントラント性に有効である。
代表型ケース(i)のリエントラント性については、HCCは、制御フローを考えると代表型呼出しcdに過渡的に通じる外部呼出しceについてCPGを照会する。
HCCにおける生成ベースのリエントラント性の検知は、ほぼ前述の基本的な検知のように実施されてもよい。状態を書き込むステートメントswおよび環境関数fについてCPGが照会される。生成ベースのリエントラント性検知は、外部コールの代わりに、fの制御フローを考えるとコンストラクタ呼出しccからswに過渡的に通じるccを検索する。しかしながら、CPGベースの解析により、HCCは、呼び出されているコンストラクタを解析することが可能になる。このようにして、コンストラクタが外部呼出しを含有している場合には、HCCが報告するのはこの脆弱性のみになる。外部コールがなければリエントラント性が生じることはないので、これは有効である。コンストラクタが外部関数を呼び出す場合には、HCCは、同一のコントラクトに属してsvにも書き込むすべての関数について、CPGを再び照会する。
整数バグの検知:整数バグに関する脆弱性検知は以下のように実施されてもよい。HCCは、割当てステートメントの一部である減算、加算または乗算のいずれかを表すすべてのノードについてCPGを照会する。計算の結果が記憶される場合、スマートコントラクトに有害になり得るのは整数バグのみであるため、これは適切である。HCCは、計算、そのあちこちの表現、割当てステートメント、および値が割り当てられた表現を収集する。
アンダフローのパッチングを容易にするために、割当てステートメントに通じるステートメントも収集される。
脆弱性のパッチング
検知された脆弱性にパッチを入れるために、脆弱性検知過程中に挿入された脆弱性ノードのすべてにわたってHCCを繰り返す。自明に、パッチの適用は、パッチを入れられる脆弱性に依拠する。
リエントラント性のパッチング:HCCは、代表型ケース(i)のリエントラント性を除くすべてのリエントラント性方式に、同一のパッチパターンを使用する。以下では、最初に一般的なプロシージャが説明されてから、代表型ケース(i)のリエントラント性用のプロシージャが説明される。
リエントラント性は、状態変数svと、この状態変数に書き込むステートメントswと、外部関数呼出しceと、環境関数fと、これもsvに書き込む、クロス関数fcのセットとから成ることを思い起こされたい。第1のステップとして、HCCは、状態変数としてのsvのロック変数(lsv)を生成する。これは、svが既にロック変数を有するかどうかの検査を含む。変数lsvのタイプはsv自体のタイプに依拠し、たとえば、svがuint256のような基本タイプを有する場合にはlsvはブールタイプになるが、マッピングタイプについては、値のタイプのみがブールタイプになる。
lsvが見つけられた後またはCPGに挿入された後に、HCCは、lsvの状態を設定する割当てステートメントを生成する。ロックステートメントlock_lsvは状態の値をトルーに設定し、アンロックステートメントunlock_lsvは状態の値をフォールスに設定する。次いで、HCCは、ロックステートメント、外部呼出しおよびアンロックステートメントが、lock_lsv→ce→unlock_lsvと、互いに直接後続するように、fの制御フローを変更する。
制御フローが変更された後に、HCCは、lsvがアンロックであることを検査して関数fの先頭にlsvを挿入するガードを生成する。ガードの生成および挿入は、svに書き込むすべての他の関数fcにも生じ得る。
代表型ケース(i)のリエントラント性用のパッチは少し違ったやり方で実施されることがあり、HCCは、代表型呼出しcdにおいてどの状態が書き込まれたのか(または状態が書き込まれたかどうか)検知することができない。したがって、パッチは、状態変数としてメインロックに挿入される。その後、パッチは、このロックについてロックステートメントおよびアンロックステートメントとともに外部呼出しceならびに代表型呼出しcdの周囲にある。次いで、パブリック呼出し可能なすべての関数の先頭にメインロック用のガードが挿入される。
整数バグのパッチング:アサーションを挿入することにより、種々の整数バグがパッチを入れられてもよい。乗算および加算については、アサーションは制御フローにおける動作の後に追加される。減算については、アサーションは制御フローにおける動作の前に追加される。
有効性および関数の正確さの評価に関して、スマートコントラクトが一旦パッチを入れられると、HCCは、パッチを入れられたスマートコントラクトの関数の正確さが維持されていること、および脆弱性が正確にパッチを入れられたことを確認するために、すべての既存のトランザクションを評価してもよい。
HCCによって適用されたパッチがスマートコントラクトの機能性を壊してはならないので、実施形態によるHCCは、以下の態様の後に評価してもよい。
- パッチの有効性:データセットにおいて利用可能な既知の脆弱性に、HCCが効果的にパッチを入れることを検証する。これは修正イーサリアムノード上の利用可能な悪用トランザクションを再生することを含む。
- 関数の正確さ:HCCがスマートコントラクトを壊さないことを確認する。これを検査するために、元のコントラクトのすべてのトランザクションが、パッチを入れられたコントラクトにおいて実行される。このために、修正イーサリアムノードも使用される。
本発明の一実施形態によるHCCの実装形態の検査に関して、HCCのプロトタイプは、JVM上の言語であるKotlinで構築することができる。このプロトタイプは、ソースファイルの抽象構文ツリー(AST)を生成して、それをJSONとして発行するためにSolidityコンパイラ(Solidityプログラム言語参照、https://github.com/ethereum/solidity/において取得可能)に依拠してもよい。HCCはASTを消費してもよく、コードプロパティグラフ(CPG)を構築する。このプロトタイプは、CPGを記憶したり解析したりするためにNeo4j(https://neo4j.com/において取得可能なNeo4jグラフプラットフォーム参照)を使用してもよい。
本明細書で説明された本発明の多くの修正形態および他の実施形態が、前述の説明および関連する図面に示された教示の利益を有する、本発明に関係する技術分野の当業者には思い浮かぶであろう。したがって、本発明は、開示された特定の実施形態に限定されるものではなく、修正形態および他の実施形態は、添付の特許請求の範囲に含まれるように意図されていることを理解されたい。本明細書には特定の用語が採用されているが、それらは一般的かつ説明的な意味のみにおいて使用されており、限定するためのものではない。

Claims (15)

  1. ブロックチェーンネットワークにおいてスマートコントラクトをサポートするためのコンピュータ実施方法であって、
    スマートコントラクトのソースコードを抽象構文ツリーモデルに変換するステップと、
    前記抽象構文ツリーモデルに基づいてコードプロパティグラフを生成するステップと、
    前記抽象構文ツリーモデルから推測可能な情報を用いて前記コードプロパティグラフを拡充する拡充過程を実行するステップと、
    脆弱性検知過程を実行するステップであって、前記コードプロパティグラフが、1つまたは複数の所定の脆弱性を見つけるために、1つまたは複数の所定の脆弱性パターンがあるかどうか検査される、ステップと、
    脆弱性パッチング過程を実行するステップであって、前記脆弱性検知過程において見つかった脆弱性を修正するために1つまたは複数のパッチが適用され、パッチを適用されたコードプロパティグラフが生成されるように、前記コードプロパティグラフに前記パッチが挿入される、ステップと
    を含む、コンピュータ実施方法。
  2. 前記ブロックチェーンネットワークがノードを有する分散ネットワークであり、ブロックチェーンにより、前記ノードが、暗号的に安全な署名を使用することによって互いにトランザクションに関与することが可能になる、請求項1に記載の方法。
  3. 前記スマートコントラクトのアドレスにトランザクションが送信される場合は常に、前記スマートコントラクトがトリガされ、前記スマートコントラクトが、前記ブロックチェーンに対してトランザクションを検証して追加するノードにより、仮想マシンにおいて実行される、請求項1または2に記載の方法。
  4. 前記コードプロパティグラフが、制御フローグラフの組み合わされた表現、データフローグラフおよび/またはドミネータツリーを含む、請求項1から3のいずれか一項に記載の方法。
  5. 前記拡充過程を実行するステップが呼出し解析を含み、前記呼出し解析が、
    前記コードプロパティグラフにおける関数呼出し表現にわたって繰り返すステップと、
    それぞれの外部関数呼出しに対して呼出しラベルを割り当てるステップと、
    を含む、請求項1から4のいずれか一項に記載の方法。
  6. 前記拡充過程を実行するステップが含むcontains-call-analysisが、
    関数呼出しを見つけるために、前記コードプロパティグラフにおけるステートメントのサブ表現を解析するステップと、
    外部関数呼出しを有するそれぞれのステートメントに呼出しラベルを割り当てるステップと
    を含む、請求項1から5のいずれか一項に記載の方法。
  7. 前記拡充過程を実行するステップが含むwrite-state-analysisが、
    スマートコントラクトの状態変数を変更するステートメントを収集するステップと、
    収集されたステートメントおよびそれらの環境関数にwrites-state-labelを割り当てるステップと、
    状態変数を更新する/書き込む内部関数呼出しの呼出し関数を収集するステップと、
    前記収集された内部関数呼出しおよびそれらの環境関数にwrites-state-labelを割り当てるステップと
    を含む、請求項1から6のいずれか一項に記載の方法。
  8. 前記脆弱性パターンが所定の脆弱性に関連付けられ、前記所定の脆弱性が、リエントラント性、整数オーバフローバグおよび/または整数アンダフローバグを含んでもよい、請求項1から7のいずれか一項に記載の方法。
  9. 前記脆弱性パターンがサブグラフの形式で表現され、前記脆弱性検知過程を実行するステップが、前記スマートコントラクトのコードプロパティグラフの内部のサブグラフを検索するステップを含む、請求項1から8のいずれか一項に記載の方法。
  10. 前記脆弱性検知過程を実行するステップが、
    状態を書き込むステートメントswのコードプロパティグラフおよび前記環境関数fを照会するステップと、
    関数fの制御フローを考慮して外部関数呼出しceからswに過渡的に通じるceを検索するステップと、
    swによって扱われる状態変数svを取り込むステップと、
    前記スマートコントラクトに属してsvに書き込むすべての関数fcのコードプロパティグラフを照会するステップと
    を含む、請求項1から9のいずれか一項に記載の方法。
  11. 前記脆弱性検知過程を実行するステップが、
    状態を書き込むステートメントswのコードプロパティグラフおよび前記環境関数fを照会するステップと、
    関数fの前記制御フローを考えるとコンストラクタ呼出しccからswに過渡的に通じ、外部関数呼出しceを呼び出す、コンストラクタ呼出しccを検索するステップと、
    swによって扱われる状態変数svを取り込むステップと、
    前記スマートコントラクトに属してsvに書き込むすべての関数fcのコードプロパティグラフを照会するステップと
    を含む、請求項1から10のいずれか一項に記載の方法。
  12. パッチを適用するために前記脆弱性パッチング過程を実行するステップが、
    状態変数としてsvのロック変数lsvを与えるステップと、
    lsvの前記状態を設定する割当てステートメントを生成するステップであって、ロックステートメントlock_lsvが前記状態の値をトルーに設定し、アンロックステートメントunlock_lsvが前記状態の値をフォールスに設定する、ステップと、
    前記ロックステートメントと前記外部呼出しce、または前記コンストラクタ呼出しccと前記アンロックステートメントが、lock_lsv→ce、またはcc→unlock_lsvと、互いに直接後続するように、関数fの前記制御フローを変更するステップと
    を含む、請求項10または11に記載の方法。
  13. 前記パッチが前記1つまたは複数の脆弱性パターンに対して特別に作成される、請求項1から12のいずれか一項に記載の方法。
  14. 前記1つまたは複数の適用されたパッチを組み込む前記スマートコントラクト用の新規のソースコードを生成するために、前記パッチを入れられたコードプロパティグラフがくまなく調べられる、請求項1から13のいずれか一項に記載の方法。
  15. ブロックチェーンネットワークにおけるスマートコントラクトをサポートするためのコンピュータシステムであって、前記コンピュータシステムには、単独で、または組み合わせて、方法、詳細には請求項1から14のいずれか一項に記載の方法を実行するように構成された記憶装置および1つまたは複数のプロセッサが備わっており、前記方法が、
    スマートコントラクトのソースコードを抽象構文ツリーモデルに変換するステップと、
    前記抽象構文ツリーモデルに基づいてコードプロパティグラフを生成するステップと、
    前記抽象構文ツリーモデルから推測可能な情報を用いて前記コードプロパティグラフを拡充する拡充過程を実行するステップと、
    脆弱性検知過程を実行するステップであって、前記コードプロパティグラフが、1つまたは複数の所定の脆弱性を見つけるために、1つまたは複数の所定の脆弱性パターンがあるかどうか検査される、ステップと、
    脆弱性パッチング過程を実行するステップであって、前記脆弱性検知過程において見つかった脆弱性を修正するために1つまたは複数のパッチが適用され、パッチを適用されたコードプロパティグラフが生成されるように、前記コードプロパティグラフに前記パッチが挿入される、ステップと
    を含む、コンピュータシステム。
JP2023521921A 2020-10-13 2021-02-26 ブロックチェーンネットワークにおいてスマートコントラクトをサポートするための方法およびシステム Pending JP2023545140A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP20201543.4 2020-10-13
EP20201543 2020-10-13
PCT/EP2021/054838 WO2022078632A1 (en) 2020-10-13 2021-02-26 Method and system for supporting smart contracts in a blockchain network

Publications (1)

Publication Number Publication Date
JP2023545140A true JP2023545140A (ja) 2023-10-26

Family

ID=74871349

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023521921A Pending JP2023545140A (ja) 2020-10-13 2021-02-26 ブロックチェーンネットワークにおいてスマートコントラクトをサポートするための方法およびシステム

Country Status (3)

Country Link
US (1) US20240020109A1 (ja)
JP (1) JP2023545140A (ja)
WO (1) WO2022078632A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114996126B (zh) * 2022-05-17 2024-02-23 电子科技大学 一种针对eosio智能合约的漏洞检测方法及系统
CN115033896B (zh) * 2022-08-15 2022-11-08 鹏城实验室 以太坊智能合约漏洞检测方法、装置、系统与介质
CN115310100B (zh) * 2022-10-12 2023-02-03 鹏城实验室 智能合约漏洞修复方法、设备以及介质
CN117614681B (zh) * 2023-11-24 2024-05-24 烟台大学 智能合约的重入漏洞检测方法、系统、设备和存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110807195B (zh) * 2019-09-26 2023-08-25 图灵人工智能研究院（南京）有限公司 一种智能合约的发布方法、发布平台装置及发布系统

Also Published As

Publication number Publication date
US20240020109A1 (en) 2024-01-18
WO2022078632A1 (en) 2022-04-21

Similar Documents

Publication Publication Date Title
Grech et al. Gigahorse: thorough, declarative decompilation of smart contracts
Jiao et al. Semantic understanding of smart contracts: Executable operational semantics of solidity
Li et al. Securing smart contract with runtime validation
Liu et al. S-gram: towards semantic-aware security auditing for ethereum smart contracts
Zhang et al. Precise and accurate patch presence test for binaries
Wang et al. Vultron: catching vulnerable smart contracts once and for all
JP2023545140A (ja) ブロックチェーンネットワークにおいてスマートコントラクトをサポートするための方法およびシステム
Wang et al. Formal specification and verification of smart contracts for azure blockchain
Wang et al. Proving differential privacy with shadow execution
Liao et al. SmartDagger: a bytecode-based static analysis approach for detecting cross-contract vulnerability
Jin et al. Exgen: Cross-platform, automated exploit generation for smart contract vulnerabilities
Sharma et al. Java Ranger: Statically summarizing regions for efficient symbolic execution of Java
Dewey et al. Uncovering use-after-free conditions in compiled code
Giesen et al. Practical mitigation of smart contract bugs
Argañaraz et al. Detection of vulnerabilities in smart contracts specifications in ethereum platforms
Liao et al. Smartstate: Detecting state-reverting vulnerabilities in smart contracts via fine-grained state-dependency analysis
Nassirzadeh et al. Gas gauge: A security analysis tool for smart contract out-of-gas vulnerabilities
Ayub et al. Storage state analysis and extraction of Ethereum blockchain smart contracts
Fang et al. Beyond “Protected” and “Private”: An Empirical Security Analysis of Custom Function Modifiers in Smart Contracts
Liu et al. Automated Invariant Generation for Solidity Smart Contracts
Xi et al. When they go low: automated replacement of low-level functions in ethereum smart contracts
Xu et al. A light-weight and accurate method of static integer-overflow-to-buffer-overflow vulnerability detection
Borodin et al. Searching for Taint Vulnerabilities with Svace Static Analysis Tool
Lounas et al. An approach for formal verification of updated java bytecode programs
Muntean et al. Intrepair: Informed fixing of integer overflows

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240207