Slide 1

Slide 1 text

Bitcoin Transaction Malleability & MtGox [C.Decker, R.Wattenhofer] Sagi Kedmi Advanced Bitcoin Seminar The Selim and Rachel Benin School of Computer Science & Engineering The Hebrew University of Jerusalem

Slide 2

Slide 2 text

agenda • Motivation • Brief overview: Network, Crypto • Deep drill-down Bitcoin focus on transactions • Transaction Malleability attack • Measurements and graphs Lots and lots Of Demos :)

Slide 3

Slide 3 text

terminology Malleability – ת

Slide 4

Slide 4 text

motivation

Slide 5

Slide 5 text

motivation • Jan. 2007, Jed McCaleb, built mtgox.com • MtGox = Magic the Gathering Online eXchance • July 2010 – MtGox was transformed to a bitcoin exchance site. (31/10/2008 Satoshi's paper) • By 2013 MtGox was handling 70% of all Bitcoin transactions. • February 2014 – closed and filed for bankruptcy claiming attackers used malleability attacks to drain its accounts https://en.bitcoin.it/wiki/History

Slide 6

Slide 6 text

motivation • 850,000 BTC were lost, at that time 1BTC=$827, i.e. ~ $700,000,000 were lost. • But...

Slide 7

Slide 7 text

motivation • 850,000 BTC were lost, at that time 1BTC=$827, i.e. ~ $700,000,000 were lost. • But... *A plausible inference from to this research

Slide 8

Slide 8 text

motivation • 850,000 BTC were lost, at that time 1BTC=$827, i.e. ~ $700,000,000 were lost. • But... • This research have shown that barely 386 bitcoins could have been stolen (prior to its bankruptcy) using malleability attacks from MtGox

Slide 9

Slide 9 text

Network

Slide 10

Slide 10 text

p2p_network • 2 p2p networks: mainnet(tcp/8333), testnet(tcp/18333) 2 different blockchains • UPnP is used to dynamically open ports • Peer discovery – DNS seeds (Demo) • Process is susceptible to MitM attacks therefore client shouldn't rely on DNS seeds exclusively • The nodes on the network exchange transactions, blocks, and addresses of other peers with each other

Slide 11

Slide 11 text

Crypto.

Slide 12

Slide 12 text

cryptographic_hash_functions • Deterministic, efficiently computable & fixed output length • Collision resistance; hard to find m1!=m2 such that h(m1)=h(m2) • Appear random & hide info. (1st / 2nd pre-image resistance) • Hence, if two strings have the same digest, one can be very confident that they are identical • Usage: storing password in DB, Linux PRNG, Bitcoin, etc.

Slide 13

Slide 13 text

public_key_cryptography • Requires two separate keys: private key and public key. • Everything encrypted with the public key can only be decrypted using the private key. • Everything 'encrypted' with the private key can only be decrypted using the public key. • RSA → N=p*q, ECC/ECDSA → n*P=Q • Bitcoin uses the secp256k1 curve: • In ECC keys are much smaller: 224 → 2048 (https://www.nsa.gov/business/programs/elliptic_curve.shtml) y2=x3+7

Slide 14

Slide 14 text

digital_signature

Slide 15

Slide 15 text

digital_signature 1. Authentication 2. Non-repudiation 3. Data Integrity

Slide 16

Slide 16 text

Bitcoin

Slide 17

Slide 17 text

Bitcoin meet Dorian Satoshi Nakamoto "Newsweek terrorized Mr. Nakamoto," Kirschner told Ars. "Goodman showed up at his house, scared his elderly mother, obtained his e-mail address by deception, and misquoted or invented quotes from both him and his brothers. They published his health, financial, and employment history recklessly. They need to account for what they did." Bitcoin community raised about $23,000 to help Dorian

Slide 18

Slide 18 text

bitcoin_keys Android SecureRandom Vulnerability - https:/bitcoin.org/en/alert/2013-08-11-android They moved to /dev/urandom (paper: Attacking the Linux PRNG on Android) https://en.bitcoin.it/wiki/WIF

Slide 19

Slide 19 text

bitcoin_address • Base64={a-z,A-Z,0-9,+,/} • Base58=Base64\{0,O,I, l,+,/} • Base64 demo

Slide 20

Slide 20 text

bitcoin_address • Important: The public key is not revealed until a transaction is signed, unlike most systems where the public key is made public.

Slide 21

Slide 21 text

bitcoin_address • Important: The public key is not revealed until a transaction is signed, unlike most systems where the public key is made public. • provides security against unanticipated problems which might allow reconstruction of private keys from public key data at some later point. • Example: Paper - Mining your Ps and Qs – Heninger et al. https://factorable.net/weakkeys12.extended.pdf • * d ≡ e−1 (mod φ(n)), φ(n) = φ(p)φ(q) = (p − 1)(q − 1)

Slide 22

Slide 22 text

brainwallet • Storing Bitcoins in one's own mind by memorization of a passphrase • e.g. Private key = SHA256("The Times 03/Jan/2009 Chancellor on brink of second bailout for banks")

Slide 23

Slide 23 text

brainwallet • Storing Bitcoins in one's own mind by memorization of a passphrase • e.g. Private key = SHA256("The Times 03/Jan/2009 Chancellor on brink of second bailout for banks") • Demo time

Slide 24

Slide 24 text

brainwallet • Storing Bitcoins in one's own mind by memorization of a passphrase • e.g. Private key = SHA256("The Times 03/Jan/2009 Chancellor on brink of second bailout for banks") • Demo time, Cool eh?

Slide 25

Slide 25 text

brainwallet • Storing Bitcoins in one's own mind by memorization of a passphrase • e.g. Private key = SHA256("The Times 03/Jan/2009 Chancellor on brink of second bailout for banks") • Demo time, Cool eh? NOT!! (Another demo)

Slide 26

Slide 26 text

brainwallet • Storing Bitcoins in one's own mind by memorization of a passphrase • e.g. Private key = SHA256("The Times 03/Jan/2009 Chancellor on brink of second bailout for banks") • Demo time, Cool eh? NOT!! (Another demo) • The first rule of Security is: You do not trust user input. • The second rule of Security is: You DO NOT trust user input. *Rainbow-table *Space-time t.o *Bots *A5.1-kraken

Slide 27

Slide 27 text

P2PKH_transaction • 1 BTC = 108 Satoshis → 1 Satoshi = 10-8BTC • Moves bitcoins between one or more inputs and outputs (each tx has at least one i/o) • Each output then waits as an Unspent Transaction Output (UTXO) until a later input spends it • Each input used must be entirely spent in a transaction.

Slide 28

Slide 28 text

P2PKH_transaction • Say Alice wants to send Bob BTC. Alice knows Bob's bitcoin address • She creates a standard P2PKH transaction output containing instructions which allow anyone to spend that output if they can prove they control the private key corresponding to Bob’s hashed public key. These instructions are called scriptPubKey. • Alice broadcasts the transaction and it is added to the block chain. The network categorizes it as an Unspent Transaction Output (UTXO), and Bob's wallet software displays it as a spendable balance.

Slide 29

Slide 29 text

P2PKH_transaction • Bob decides to spend the UTXO • Creates an input which references the transaction Alice created by its hash – txid, and the specific output she used by its index number (output index). • He must then create a signature script— called scriptSig – which contains his own public key and a signature of the transaction with its private key. • Bob's input scriptSig must satisfy the conditions of Alice's scriptPubKey .

Slide 30

Slide 30 text

P2PKH_transaction Demo [Transaction on testnet3]

Slide 31

Slide 31 text

blockchain_treasures Demo

Slide 32

Slide 32 text

blockchain_treasures Nelson Mandela (1918-2013) "I am fundamentally an optimist. Whether that comes from nature or nurture, I cannot say. Part of being optimistic is keeping one’s head pointed toward the sun, one’s feet moving forward. There were many dark moments when my faith in humanity was sorely tested, but I would not and could not give myself up to despair. That way lays defeat and death." "I learned that courage was not the absence of fear, but the triumph over it. The brave man is not he who does not feel afraid, but he who conquers that fear." "Difficulties break some men but make others. No axe is sharp enough to cut the soul of a sinner who keeps on trying, one armed with the hope that he will rise even in the end." "It always seems impossible until it’s done." "When a man has done what he considers to be his duty to his people and his country, he can rest in peace." "Real leaders must be ready to sacrifice all for the freedom of their "Everyone can rise above their circumstances and achieve success if they are dedicated to and passionate about what they do." "Education is the most powerful weapon which you can use to change the world." "For to be free is not merely to cast off one’s chains, but to live in a way that respects and enhances the freedom of others." "There is no passion to be found playing small – in settling for a life that is less than the one you are capable of living." “There is nothing like returning to a place that remains unchanged to find the ways in which you yourself have altered.” -Nelson Mandela

Slide 33

Slide 33 text

blockchain_treasures • XSS Payload! (Demo) [*SQLinjection] https://blockchain.info/tx/59bd7b2cff5d a929581fc9fef31a2fba14508f1477e366befb1 eb42a8810a000 • Prayers from miners • Tribute to cryptographer Len Sassaman • by Dan Kaminsky and Travis Goodspeed(Demo) • Prayers from miners (Demo) • The original bitcoin paper, Wikileaks data Firmware private keys Oh shit," he mumbled. "I just broke the Internet."

Slide 34

Slide 34 text

blockchain_treasures LETS MAKE OUR OWN BLOCKCHAIN GRAFITIY (DEMO)

Slide 35

Slide 35 text

P2PKH_transaction_verification

Slide 36

Slide 36 text

P2PKH_transaction_verification

Slide 37

Slide 37 text

P2PKH_transaction_verification

Slide 38

Slide 38 text

P2PKH_transaction_id

Slide 39

Slide 39 text

P2PKH_transaction_signing SIGHASH_ALL - "sign all of the outputs." - Default behaviour

Slide 40

Slide 40 text

P2PKH_transaction_signing "sign none of the outputs-- I don't care where the bitcoins go."

Slide 41

Slide 41 text

P2PKH_transaction_signing "sign one of the outputs-- I don't care where the other outputs go"

Slide 42

Slide 42 text

P2PKH_transaction_signing "Let other people add inputs to this transaction.”

Slide 43

Slide 43 text

P2PKH_transaction_signing Ouroboros Nietzsche's Eternal Recurrence A signature may not sign a data structure containing itself → circular dependency

Slide 44

Slide 44 text

P2PKH_transaction_signing Ouroboros Nietzsche's Eternal Recurrence A signature may not sign a data structure containing itself → circular dependency SOURCE OF TX MALLEABILITY

Slide 45

Slide 45 text

4830450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 41046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 4d480030450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 4d4100046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 Lets say that a valid transaction has the following scriptSig: A copy of the transaction with the following scriptSig What do the transactions share? transaction_malleability_OP_PUSHDATA2

Slide 46

Slide 46 text

transaction_malleability_OP_PUSHDATA2 4830450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 41046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 4d480030450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 4d4100046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 Lets say that a valid transaction has the following scriptSig: A copy of the transaction with the following scriptSig What do the transactions share? Same SIGNATURE! [bcz as we've seen the scriptSig isn't signed]

Slide 47

Slide 47 text

4830450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 41046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 4d480030450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 4d4100046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 Lets say that a valid transaction has the following scriptSig: A copy of the transaction with the following scriptSig What do the transactions share? Same SIGNATURE! [bcz as we've seen the scriptSig isn't signed] What don't the transactions share? transaction_malleability_OP_PUSHDATA2

Slide 48

Slide 48 text

4830450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 41046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 4d480030450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 4d4100046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 Lets say that a valid transaction has the following scriptSig: A copy of the transaction with the following scriptSig What do the transactions share? Same SIGNATURE! [bcz as we've seen the scriptSig isn't signed] What don't the transactions share? Different txid ! transaction_malleability_OP_PUSHDATA2

Slide 49

Slide 49 text

4830450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 41046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 4d480030450220539901ea7d6840eea8826c1f3d0d1fca7827e491deabcf17889e7a2e5a39f5a10221 00fe745667e444978c51fdba6981505f0a68619f0289e5ff2352acbd31b3d23d8701 4d4100046c4ea0005563c20336d170e35ae2f168e890da34e63da7fff1cc8f2a54 f60dc402b47574d6ce5c6c5d66db0845c7dabcb5d90d0d6ca9b703dc4d02f4501b6e44 Lets say that a valid transaction has the following scriptSig: A copy of the transaction with the following scriptSig: What do the transactions share? Same SIGNATURE! [bcz as we've seen the scriptSig isn't signed] What don't the transactions share? Different txid ! [bcz we change data in the transaction] transaction_malleability_OP_PUSHDATA2

Slide 50

Slide 50 text

classical_double_spending_attack Payer Payee#2 Payee#1 • Attacker creates two transactions • A tx that transfers some of its funds to Payee#1 {say Amazon} • A tx that transfers the same funds back to himself • Goal: convince Payee#1 that it received the funds, triggering a transfer of goods from Payee#1 to the Attacker. • Bitcoin 'solves' it with its confirmation system [6 confirmations = pretty good security] https://en.bitcoin.it/wiki/Weaknesses - haven't read; no time Sends a laptop

Slide 51

Slide 51 text

transaction_malleability_attack Payer Payee#1 • Attacker(Payee) causes victim(Payer) to send to send him funds • Attacker waits for tx1 to be broadcast in the network • Attacker received tx1, broadcasts tx2=f(tx1) – tx1 with modified scriptSig • Either tx1 or tx2 may be confirmed, if tx2 is confirmed mal. Atk. is successful • If the Payer's client rely solely on the txid to track and verify its balance, it will see tx1 as unconf., and send tx3 tx2=f(tx1) tx1 tx3 Payer thinks that the funds Didnt reach payee bcz the tx1_id was unconfirmed (he thinks it was unconfirmed)

Slide 52

Slide 52 text

transaction_malleability_attack Payer Payee#1 • Note: the reference client (BitcoinCore) is not susceptible to this attack – it tracks the UTXO and verifies it tx2=f(tx1) tx1 tx3 Payer thinks that the funds Didnt reach payee bcz the tx1_id was unconfirmed

Slide 53

Slide 53 text

mtgox_incident_timeline Period3 Period1 Period2 January 2013 1st Press Release Suspension of Bitcoin Withdrawals February 7 2014 February 8 2014 February 9 2014 February 28 2014 February 10 2013 2nd Press Release Blamed tx malleability For unconf. tx ??th Press Release Filing for bankruptcy in Japan and USA February 23 2014 Collection of Transaction Begins Collection of Transaction Stops Mtgox.com returned blank page; trading halt Period1: Over a year of measurements until the closure of withdrawals from MtGox Period2: Withdrawals are stopped but no details about the attack known to public Period3: time following the press release blaming tx malleability as the root cause of missing bitcoins until MtGox filed for bankruptcy

Slide 54

Slide 54 text

have_a_snack_buy_with_bitcoins_bamert_et_al

Slide 55

Slide 55 text

have_a_snack_buy_with_bitcoin_bamert_et_al

Slide 56

Slide 56 text

measurements_gear • Def: if an output is claimed by two or more transactions, these transactions are said to conflict • As soon of one of the two conflicting transactions(d.spend, m.atk) is considered to be confirmed the nodes will drop all other conflicting transactions. • They created specialized nodes that would trace and dump all transactions from the Bitcoin network (mainnet) • Each node was connected to 992 on average (recall Balmert et al.) [w.p. ~1 the node see every tx on the net]

Slide 57

Slide 57 text

measurements_data • Getting malleable'd txs: remove the scriptSig/scriptSigLength from all the txs, [?and hash it?] will result in a unique key • The unique key group txs together into conflict sets • During the measurement period a total of 35,002 conflict sets were identified. • Out of these conflict setts 29,139 contained a transaction that would later be confirmed by a block. Remaining 6,603 were invalid bcz they claimed non-existent output, had an incorrect signature ...

Slide 58

Slide 58 text

measurements_data • Def: conflict set value = sum of out values of one of the tx in the conflict set (each tx in the conflict is identical minus the scriptSig ). • Summing the value of all the conflict sets result in a total of 302,700 BTC that were involved in malleability attacks • There exists other tx mal. Atks other than OP_PUSHDATA2 [in the signature of the e.g. Inherent ECDSA signature malleability – more at BIP-0062] • 28,595 out of the 29,139 confirmed attacks had the OP_PUSHDATA2 modification • For the remaining 544 they were unable to identify the original transaction. All of them had original opcodes. ???? ...

Slide 59

Slide 59 text

measurements_data • Def: conflict set value = sum of out values of one of the tx in the conflict set (each tx in the conflict is identical minus the scriptSig ). • Summing the value of all the conflict sets result in a total of 302,700 BTC that were involved in malleability attacks • There exists other tx mal. Atks other than OP_PUSHDATA2 [in the signature of the e.g. Inherent ECDSA signature malleability – more at BIP-0062] • 28,595 out of the 29,139 confirmed attacks had the OP_PUSHDATA2 modification • For the remaining 544 they were unable to identify the original transaction. All of them had original opcodes. ???? ... “DEMO”

Slide 60

Slide 60 text

measurements_data • For tx mal. Atk. We need two things: ● 1. the modified tx has to be confirmed ● 2. the system issuing the tx must rely solely on the txid to track its confirmation ● • 1. can be easily reconstructed from the blockchain • 2. “can't”. “It is not possible to determine if two payments with the same value to the same address were intended as two separate payments or an automated system issued the second one believing the first to be invalid.” ?? • Out of the 28,595 tx mal. Atk.s only 5,670 were sucessful. i.e. 19.46%. ...

Slide 61

Slide 61 text

measurements_data • Out of the 28,595 tx mal. Atk.s only 5,670 were sucessful. i.e. 19.46%. • [ Val{28,595}/Val{5,760} ]*100 = 21.36% • This reducess the total profit of the successful attacks from 302,700 to 64,564 • Strong bias towards the original tx. Why ? ...

Slide 62

Slide 62 text

the_mtgox_incident ● The loss was later detailed as amounting to over 850,000 BTC out of which 750,000 BTC are customer-owned. ● At the time of the first press release bitcoins were trading at $827 i.e. ~ $700,000,000 were lost. ● But... As we've seen the total conflict set value of our dataset is 302,700 BTC. {lie?} ● More than that

Slide 63

Slide 63 text

mtgox_incident_timeline Period3 Period1 Period2 January 2013 1st Press Release Suspension of Bitcoin Withdrawals February 7 2014 February 8 2014 February 9 2014 February 28 2014 February 10 2013 2nd Press Release Blamed tx malleability For unconf. tx ??th Press Release Filing for bankruptcy in Japan and USA February 23 2014 Collection of Transaction Begins Collection of Transaction Stops Mtgox.com returned blank page; trading halt Period1: Over a year of measurements until the closure of withdrawals from MtGox Period2: Withdrawals are stopped but no details about the attack known to public Period3: time following the press release blaming tx malleability as the root cause of missing bitcoins until MtGox filed for bankruptcy Malleability attacks in period 2 and 3 could not Contribute to the losses declared by MtGox since They happened after withdrawals have been stopped

Slide 64

Slide 64 text

the_mtgox_incident ● During period 1 – a total of 421 conflict sets were identified for a total value of 1,811.53 BTC ● In combination with the ~20% success rate we conclude that malleability attacks did not have any substantial influence in the loss of bitcoins incurred by MtGox. (around 380 BTC could have been stolen from MtGox or from other businesses)

Slide 65

Slide 65 text

the_mtgox_incident ● During period 2, they gathered 1,062 conflict sets, totalling 5,470 BTC ● A noticeable increase of attacks at 17:00 UTC on February 9, from 0.15 attacks per hour to 132 attacks per hour ● The sudden increase suggests that immediately following the second press release other attackers started imitating the attack. ● During period 3 – After the second press release between Feb. 10 and 11 they identified 25,752 individual attacks totalling 286,076 BTC.

Slide 66

Slide 66 text

the_mtgox_incident

Slide 67

Slide 67 text

what_really_happend ? ● Aside from MtGox, No one really knows. [Maybe the courts handling the bankruptcy ?] ● A speculation: it was an inside job/hackers at MtGox {using bots named by the community Willy and Markus}. ● More information: http://willyreport.wordpress.com/

Slide 68

Slide 68 text

what_really_happend ? ● Aside from MtGox, No one really knows..[Maybe the courts handling the bankruptcy ?] ● A speculation: it was an inside job/hackers at MtGox {using bots named by the community Willy and Markus}. ● More information: http://willyreport.wordpress.com/ PLEASE FIND A WAY TO HARNESS BITCOIN “PROOF-OF-WORK” TO SOLVE SOME OF HUMANITIES PROBLEMS. E.G: EBOLA.

Slide 69

Slide 69 text

? Thank you Thanks Nadja Kahan for the illustrations ! http://www.nadjakahan.com If you're interested in the “Attacking the Linux PRNG on Android” talk We're presenting it again at DC9723 on 18/11 At Checkpoint offices

Slide 70

Slide 70 text

? Thank you Thanks Nadja Kahan for the illustrations ! http://www.nadjakahan.com PROOF OF WORK