Designing Secure Ethereum Smart Contracts: A Finite State Machine - - PowerPoint PPT Presentation

designing secure ethereum smart contracts a finite state
SMART_READER_LITE
LIVE PREVIEW

Designing Secure Ethereum Smart Contracts: A Finite State Machine - - PowerPoint PPT Presentation

Designing Secure Ethereum Smart Contracts: A Finite State Machine Based Approach Anastasia Mavridou 1 and Aron Laszka 2 1 Vanderbilt University 2 University of Houston 2 Smart Contract Insecurity Smart contracts are riddled with bugs and


slide-1
SLIDE 1

Designing Secure Ethereum Smart Contracts: A Finite State Machine Based Approach

Anastasia Mavridou1 and Aron Laszka2

1 Vanderbilt University 2 University of Houston

slide-2
SLIDE 2

2

slide-3
SLIDE 3

Smart Contract Insecurity

  • Smart contracts are riddled with bugs and security vulnerabilities
  • A recent automated analysis of 19,336 Ethereum contracts
  • 8,333 contracts suffer from at least one security issue

3

Luu, Loi, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. "Making smart contracts smarter." ACM CCS, 2016.

slide-4
SLIDE 4

Ethereum Smart Contracts

  • Smart contracts are riddled with bugs and security vulnerabilities
  • A recent automated analysis of 19,336 Ethereum contracts
  • 8,333 contracts suffer from at least one security issue

Luu, Loi, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. "Making smart contracts smarter." In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 254-269. ACM, 2016.

Nikolic, Ivica, Aashish KolluriChu, Ilya Sergey, Prateek Saxena, and Aquinas Hobor. “Finding the Greedy, Prodigal, and Suicidal Contracts at Scale.”arXiv:1802.06038, 2018.

4

slide-5
SLIDE 5

Security Vulnerabilities are a Serious Issue

  • Smart contracts handle financial assets of significant value
  • Value held by Ethereum contracts is 12,205,706 ETH or $10B
  • Smart contract bugs cannot be patched
  • Once a contract is deployed, its code cannot be changed
  • Blockchain transactions cannot be rolled back
  • Once a malicious transaction is recorded it cannot be removed
  • Well… actually…
  • It can be rolled back with a hard fork of the blockchain

5

slide-6
SLIDE 6

Common Vulnerabilities

  • Examples of common vulnerabilities [1]
  • Reentrancy
  • Transaction-Ordering Dependency

6

[1] Luu, Loi, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. "Making smart contracts smarter." ACM CCS, 2016.

slide-7
SLIDE 7

Reentrancy

  • In Ethereum, when there is a function call
  • The caller has to wait for the call to finish
  • A malicious callee might take advantage of this

Bank

function withdraw(uint amount) { if (credit[msg.sender]>= amount) { msg.sender.call.value(amount)(); credit[msg.sender]-=amount; }}}

7

slide-8
SLIDE 8

Reentrancy

  • In Ethereum, when there is a function call
  • The caller has to wait for the call to finish
  • A malicious callee might take advantage of this

Bank Mallory

withdraw call

T

function withdraw(uint amount) { if (credit[msg.sender]>= amount) { msg.sender.call.value(amount)(); credit[msg.sender]-=amount; }}}

8

slide-9
SLIDE 9

Reentrancy

  • In Ethereum, when there is a function call
  • The caller has to wait for the call to finish
  • A malicious callee might take advantage of this

Bank Mallory

withdraw call withdraw

T

function withdraw(uint amount) { if (credit[msg.sender]>= amount) { msg.sender.call.value(amount)(); credit[msg.sender]-=amount; }}}

function() {

dao.withdraw(dao.queryCredit(this)); } }

9

bank

bank

slide-10
SLIDE 10

Transaction Ordering Dependency

  • Also known as unpredictable state vulnerability
  • The order of execution of function calls cannot be predicted
  • No prior knowledge of a contract’s state during call execution

Buyer Seller

T

acceptOffer Market createOffer (sell 10 tokens for 1 ether)

10

slide-11
SLIDE 11

Transaction Ordering Dependency

  • Also known as unpredictable state vulnerability
  • The order of execution of function calls cannot be predicted
  • No prior knowledge of a contract’s state during call execution

Buyer Seller

T

acceptOffer updateOffer (sell1 token for 1 ether) Market createOffer (sell 10 tokens for 1 ether)

11

slide-12
SLIDE 12

Our Motivation

  • Vulnerabilities often arise due to the semantic gap
  • The assumptions developers make about execution semantics
  • The actual semantics
  • Prior work:
  • Tools for identifying existing vulnerabilities
  • Tools for static analysis
  • Design patterns, e.g., Checks-Effects-Interactions
  • We explore a different avenue
  • We want to help developers to create secure smart contracts
  • Correctness-by-design

12

slide-13
SLIDE 13

Our Approach - Model Based Design

  • We introduce a formal, transition-based language for smart contracts
  • A Smart Contract is a tuple
  • is a finite set of states
  • is the initial state
  • and are finite sets of contract, input, and output variables
  • Is a transition relation
  • Is a set of guards and is a set of action sets

label, [guard], action

  • A contract can be naturally represented by a transition system

9/22/2017 demo / BIP_test https://editor.webgme.org/?project=demo%2BBIP_test&branch=master&node=%2Ff%2F1%2FD&visualizer=BIPEditor&tab=1&layout=DefaultLayout&selection= 1/1

cancelABB withdraw bid reveal [values.length == secret.length] cancelRB close [now > creationTime + 5 days] unbid finish [now >= creationTime + 10 days]

C F RB ABB

le (S, s0, C, I, O, →),

9/22/2017 demo / BIP_test https://editor.webgme.org/?project=demo%2BBIP_test&branch=master&node=%2Ff%2F1%2FD&visualizer=BIPEditor&tab=1&layout=DefaultLayout&selection= 1/1

cancelABB withdraw bid reveal [values.length == secret.length] cancelRB close [now > creationTime + 5 days] unbid finish [now >= creationTime + 10 days]

C F RB ABB

– S

9/22/2017 demo / BIP_test https://editor.webgme.org/?project=demo%2BBIP_test&branch=master&node=%2Ff%2F1%2FD&visualizer=BIPEditor&tab=1&layout=DefaultLayout&selection= 1/1

cancelABB withdraw bid reveal [values.length == secret.length] cancelRB close [now > creationTime + 5 days] unbid finish [now >= creationTime + 10 days]

C F RB ABB

– s0 ∈ S

9/22/2017 demo / BIP_test https://editor.webgme.org/?project=demo%2BBIP_test&branch=master&node=%2Ff%2F1%2FD&visualizer=BIPEditor&tab=1&layout=DefaultLayout&selection= 1/1

cancelABB withdraw bid reveal [values.length == secret.length] cancelRB close [now > creationTime + 5 days] unbid finish [now >= creationTime + 10 days]

C F RB ABB

∈ – C, I, a

9/22/2017 demo / BIP_test https://editor.webgme.org/?project=demo%2BBIP_test&branch=master&node=%2Ff%2F1%2FD&visualizer=BIPEditor&tab=1&layout=DefaultLayout&selection= 1/1

cancelABB withdraw bid reveal [values.length == secret.length] cancelRB close [now > creationTime + 5 days] unbid finish [now >= creationTime + 10 days]

C F RB ABB

d O

9/22/2017 demo / BIP_test https://editor.webgme.org/?project=demo%2BBIP_test&branch=master&node=%2Ff%2F1%2FD&visualizer=BIPEditor&tab=1&layout=DefaultLayout&selection= 1/1

cancelABB withdraw bid reveal [values.length == secret.length] cancelRB close [now > creationTime + 5 days] unbid finish [now >= creationTime + 10 days]

C F RB ABB

– → ⊆ S × G × F × S B

9/22/2017 demo / BIP_test https://editor.webgme.org/?project=demo%2BBIP_test&branch=master&node=%2Ff%2F1%2FD&visualizer=BIPEditor&tab=1&layout=DefaultLayout&selection= 1/1

cancelABB withdraw bid reveal [values.length == secret.length] cancelRB close [now > creationTime + 5 days] unbid finish [now >= creationTime + 10 days]

C F RB ABB

→ ⊆

  • G =

9/22/2017 demo / BIP_test https://editor.webgme.org/?project=demo%2BBIP_test&branch=master&node=%2Ff%2F1%2FD&visualizer=BIPEditor&tab=1&layout=DefaultLayout&selection= 1/1

cancelABB withdraw bid reveal [values.length == secret.length] cancelRB close [now > creationTime + 5 days] unbid finish [now >= creationTime + 10 days]

C F RB ABB

  • G
  • F

13

slide-14
SLIDE 14

Example: Blind Auction Contract as a Transition System

9/22/2017 demo / BIP_test https://editor.webgme.org/?project=demo%2BBIP_test&branch=master&node=%2Ff%2F1%2FD&visualizer=BIPEditor&tab=1&layout=DefaultLayout&selection= 1/1

cancelABB withdraw bid reveal [values.length == secret.length] cancelRB close [now > creationTime + 5 days] unbid finish [now >= creationTime + 10 days]

C F RB ABB

14

slide-15
SLIDE 15

Our Approach - Model Based Design

  • Advantages
  • High-level model → adequate level of abstraction
  • Rigorous semantics → amenable to formal verification
  • Code generation from transition systems to Solidity code
  • Plugins that implement security features and design patterns

15

slide-16
SLIDE 16

Common Vulnerabilities and Design Patterns

  • Examples of common vulnerabilities [1]
  • Reentrancy
  • Transaction-Ordering Dependency
  • Most common design patterns [2]
  • Authorization
  • Time constraints

[1] Luu, Loi, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. "Making smart contracts smarter." ACM CCS, 2016. [2] Bartoletti, Massimo, and Livio Pompianu. "An empirical analysis of smart contracts: platforms, applications, and design patterns." TSC in FC, 2017.

16

slide-17
SLIDE 17

Examples of FSolidM Plugins

  • Locking

+= bool private locked = false; modifier locking { require(!locked); locked = true; _; locked = false; } += uint private transitionCounter = 0; modifier transitionCounting(uint nextTransitionNumber) { require(nextTransitionNumber == transitionCounter); transitionCounter += 1; _; }

  • Reentrancy
  • Transaction-Ordering Dependency

17

  • Transition counter
slide-18
SLIDE 18

Examples of FSolidM Plugins

  • Locking

+= bool private locked = false; modifier locking { require(!locked); locked = true; _; locked = false; } += uint private transitionCounter = 0; modifier transitionCounting(uint nextTransitionNumber) { require(nextTransitionNumber == transitionCounter); transitionCounter += 1; _; }

  • Reentrancy
  • Transaction-Ordering Dependency

18

  • Transition counter
slide-19
SLIDE 19

Ongoing Work on Verification

  • NuSMV model checker to verify
  • Safety properties
  • e.g., a faulty state should not be reached
  • Deadlock freedom
  • Liveness properties
  • e.g., a state of the system will be eventually reached

19

slide-20
SLIDE 20

9/22/2017 demo / BIP_test https://editor.webgme.org/?project=demo%2BBIP_test&branch=master&node=%2Ff%2F1%2FD&visualizer=BIPEditor&tab=1&layout=DefaultLayout&selection= 1/1

cancelABB withdraw bid reveal [values.length == secret.length] cancelRB close [now > creationTime + 5 days] unbid finish [now >= creationTime + 10 days]

C F RB ABB

Ongoing Work on Verification

  • NuSMV model checker to verify
  • Safety properties
  • e.g., a faulty state should not be reached
  • Deadlock freedom
  • Liveness properties
  • e.g., a state of the system will be eventually reached

20

Deadlock freedom AG (close → AG !bid) AG (withdraw → AX A [!withdraw W subtract])

slide-21
SLIDE 21

Discussion

  • Formal model, clear semantics, easy-to-use graphical editor
  • Decreasing the semantic gap
  • Rigorous semantics
  • Amenable to analysis and verification
  • Code generation + functionality and security plugins
  • Minimal amount of error-prone manual coding
  • FSolidM source code: http://github.com/anmavrid/smart-contracts
  • FSolidM also available at: http://cps-vo.org/group/SmartContracts

Thank yov!

21