Security, Privacy and Interoperability in Payment- Channel Networks

Transcription

1 FAKULTÄT FÜR!NFORMATIK Faculty of Informatics & PRIVACY SECURITY GROUP Security, Privacy and Interoperability in Payment- Channel Networks Pedro Moreno-Sanchez Joint work with Giulio Malavolta, Clara Schneidewind, Aniket Kate,

2 Permissionless Blockchains Scalability Issue Low transaction rate (~10 transactions per second) Fast growth of the Bitcoin transactions Scalability approaches: On-chain (layer 1) sharding Off-chain (layer 2) payment channels [The focus of our work] 2

3 Payment Channels 3

4 Payment Channels: Open Blockchain : 5 ALICE (, ): 5 : 5 4

5 Payment Channels: Pay (, ): 5 ALICE?? BOB : 4 : 1 Blockchain : 5 ALICE (, ): 5 : 5 5

6 Payment Channels: Pay (, ): 5 ALICE?? BOB : 3 : 2 Blockchain : 5 ALICE (, ): 5 : 5 6

7 Payment Channels: Close Blockchain : 5 ALICE (, ): 5 : 5 (, ): 5 ALICE : 3 : 2 BOB 7

8 Payment-Channel Networks (PCN) Each payment channel requires to lock coins in the deposit Impractical to open a channel with each other Open a few channels Rely on other channels to reach the intended receiver 8

9 Payment-Channel Networks (PCN) Each payment channel requires to lock coins in the deposit Impractical to open a channel with each other Open a few channels Rely on other channels to reach the intended receiver 1 BTC to 1 BTC to Cat 9

10 Current PCN (Proposals) Bitcoin and Altcoins: Lightning network, c-lighntning, Eclair Ethereum: Raiden Network Eventually, every blockchain might need a scalability solution 10

11 What is our group s research about in PCN?

12 Our Research Formally describe notions of interest for PCNs in the Universal Composability framework: Security, privacy, concurrency Analyze whether current PCNs achieve them e.g., we showed an inherent tradeoff privacy vs concurrency Provide cryptographic constructions with formal security and privacy guarantees 12

13 Security in PCNs

14 Security Notion Balance security: Honest users do not lose coins in a multi-hop payment = 10 Cat Pr < negl < 10 Cat 14

15 Security and HTLC Balance security: Honest users do not lose coins in a payment Security tool: Hash-Time Lock Contract (HTLC): Payment conditioned on revealing the pre-image of a hash function 15

16 Security and HTLC Balance security: Honest users do not lose coins in a payment Security tool: Hash-Time Lock Contract (HTLC): Payment conditioned on revealing the pre-image of a hash function HTLC(,, 1, y, t) : 4 (, ): 5 ALICE : 1 y = H(??)?? BOB 16

17 The Lightning Network: Setup Multiple chained HTLC allow multi-hop payments in the presence of malicious intermediaries x : H(x) = y Cat y 17

18 The Lightning Network: Lock Multiple chained HTLC allow multi-hop payments in the presence of malicious intermediaries HTLC(,, 1.1, y, t) HTLC(, Cat, 1, y, t ) Cat 18

19 The Lightning Network: Lock Multiple chained HTLC allow multi-hop payments in the presence of malicious intermediaries HTLC(,, 1.1, y, t) HTLC(, Cat, 1, y, t ) Cat Transaction fee 19

20 The Lightning Network: Release Multiple chained HTLC allow multi-hop payments in the presence of malicious intermediaries X X Cat 20

21 A Novel Wormhole Attack Idea: Exclude intermediate honest users from successful completion. Consequence: Adversary steals fees from honest users. HTLC(Adv,, 1.2, y, t2) HTLC(Adv, Cat, 1, y, t4) HTLC(, Adv, 1.3, y, t1) Adversary HTLC(, Adv, 1.1, y, t3) Adversary Cat 21

22 A Novel Wormhole Attack Idea: Exclude intermediate honest users from successful completion. Consequence: Adversary steals fees from honest users. HTLC(Adv,, 1.2, y, t2) HTLC(Adv, Cat, 1, y, t4) HTLC(, Adv, 1.3, y, t1) Adversary HTLC(, Adv, 1.1, y, t3) Adversary Cat X 22

23 A Novel Wormhole Attack Idea: Exclude intermediate honest users from successful completion. Consequence: Adversary steals fees from honest users. HTLC(Adv,, 1.2, y, t2) HTLC(Adv, Cat, 1, y, t4) HTLC(, Adv, 1.3, y, t1) Adversary HTLC(, Adv, 1.1, y, t3) Adversary Payment Failed X Cat X 23

24 A Novel Wormhole Attack Idea: Exclude intermediate honest users from successful completion. Consequence: Adversary steals fees from honest users. HTLC(Adv,, 1.2, y, t2) HTLC(Adv, Cat, 1, y, t4) HTLC(, Adv, 1.3, y, t1) Adversary HTLC(, Adv, 1.1, y, t3) Adversary Payment Failed X Cat X Adversary gains 0.3 coins (0.2 fees + s fee) 24

25 The Wormhole Attack: Discussion Same condition along the path enables this attack More intermediaries, more benefit Fees are the base of PCNs. Thus, attack on fees is important Intermediary () believes payment is unsuccessful HTLC(Adv,, 1.2, y, t2) HTLC(Adv, Cat, 1, y, t4) HTLC(, Adv, 1.3, y, t1) HTLC(, Adv, 1.1, y, t3) Adversary X Adversary Payment Failed Cat X 25

26 What about privacy?

27 Privacy Notion Relationship Anonymity: The adversary cannot tell who is paying to whom Cat Cat pays to pays to pays to pays to 27

28 Privacy in PCNs Relationship Anonymity: The adversary cannot tell who is paying to whom HTLC(, Adv, 1.3, y) HTLC(Adv, Cat, 1, y) HTLC(Adv,, 1.2, y) HTLC(, Adv, 1.1, y) Cat Cat HTLC(Adv,, 1.2, y ) HTLC(, Adv, 1.3, y ) HTLC(, Adv, 1.1, y ) HTLC(Adv, Cat, 1, y ) Problem: The same condition is used in the complete path! 28

29 Other Practical Considerations Scalability issues: Two keys to define the deposit Payment condition + signatures required Privacy issues: Users sharing a channel revealed Interoperability Support for specific hash function required : 4 (, ): 5 ALICE : 1 y = H(??)?? BOB 29

30 Summary Current PCN Current PCN Security Wormhole Attack Privacy Who pays to whom Interoperability / Compatibility Specific hash function Reduced Tx Size Two keys; HTLC script 30

31 What can we do with the signatures?

32 2-party ECDSA Signing [Lindell17] (pk A, sk A ) (pk B, sk B ) Jointly compute a signature σ on a transaction It requires the knowledge of both ska and skb It can be publicly verified using PKAB := (ska * skb) * G 32

33 ECDSA: 2-party channel Current Open Channel pk A : 5 ALICE (pk A, pk B ): 5 pk A : 5 pk A : 5 ALICE SS-ECDSA pk AB : 5 pk A : 5 Off-chain Payment (pk A, pk B ): 5 ALICE pk A : 3 pk B : 2 pk AB : 5 ALICE pk A : 3 pk B : 2 33

34 What if we encode the conditions in the signatures themselves?

35 Scriptless Scripts (Schnorr) Original idea proposed by Andrew Poelstra Encode payment condition within the Schnorr signatures In our work: formal description and analysis Unfortunately, Schnorr is not used in many cryptocurrencies today 35

36 Scriptless Scripts (SS-ECDSA) Was an open problem before our work Main challenge is the signature structure: No longer a linear combination Schnorr signature: (r1 + r2) + (k1 + k2) m ECDSA signature: (r -1 * r -2 ) Rx (k1 * k2) + (r -1 * r -2 ) m Requires inverse, x coordinate of an elliptic curve point and multiplicative shares of the key k = k1 * k2 In our work: formal description and analysis 36

37 2-party ECDSA Conditional Signing Goals: (pk A, sk A ) Condition: (pkc) (pk B, sk B ) can create a half-signature that can finish only with skc If creates a signature, learns skc 37

38 2-party ECDSA Conditional Signing (pk A, sk A ) Condition: (pkc) (pk B, sk B ) Create pkab and combine randomness R := (pkc, ra, rb) Send 1/3-signature σb Send 1/3-signature σa Send whole signature: σ := σa * σb * σc Learn skc Compute σc := σ * (σb) -1 * (σc) -1 Retrieve skc from σc 38

39 2-party ECDSA Conditional Signing (pka, ska) Condition: (pkc) (pkb, skb) LOCK Create pkab and combine randomness R := (pkc, ra, rb) Send 1/3-signature σb Send 1/3-signature σa Send whole signature: σ := σa * σb * σc Compute σc := σ * (σb)-1 * (σc)-1 Retrieve skc from σc Learn skc RELEASE 39

40 ECDSA-based PCN: Setup Multiple chained ECDSA conditional payments allow multi-hop payments in the presence of malicious intermediaries (skd, pkd := skd * G) (ske, pke := ske * G) pkde := pkd + pke pkd, pkde,ske Cat 40

41 ECDSA-based PCN: Setup Multiple chained ECDSA conditional payments allow multi-hop payments in the presence of malicious intermediaries (skd, pkd := skd * G) (ske, pke := ske * G) pkde := pkd + pke pkde, skde pkd, pkde,ske Cat 41

42 ECDSA-based PCN: Lock Multiple chained ECDSA conditional payments allow multi-hop payments in the presence of malicious intermediaries LOCK(,, 1.1, pkd, t) LOCK(, Cat, 1, pkde, t ) Cat ske skde 42

43 ECDSA-based PCN: Lock Multiple chained ECDSA conditional payments allow multi-hop payments in the presence of malicious intermediaries LOCK(,, 1.1, pkd, t) LOCK(, Cat, 1, pkde, t ) Cat ske skde Randomized conditions in the path: Security and Privacy 43

44 ECDSA-based PCN: Release Multiple chained ECDSA conditional payments allow multi-hop payments in the presence of malicious intermediaries skd skde Cat ske skde 44

45 ECDSA-based PCN: Discussion It can be extended to arbitrary number of hops It reduces transaction size for conditional payments pk AB : 5 ALICE pk A : 4 pk ABC : 1 Evaluation: <500 bytes communication. Few ms computation Improve interoperability. Useful for other applications (e.g., atomic swaps and cross-chain payments) Compatible with Bitcoin 45

46 Summary Current ECDSA Current PCN ECDSA-based PCN Security One secret per user Privacy Randomized conditions Interoperabili ty / Compatibility Only ECDSA required Reduced Tx Size Condition in one key 46

47 Summary More in the paper: One-way homomorphic functions suffice for multihop locks in full script setting Possible to combine OWH-Schnorr-ECDSA locks in the same path Security and privacy modelled and proven in the Universal Composability Framework > Composability guarantees Multi-hop locks implemented in the Lightning Network It enables a plethora of applications (e.g., atomic swaps and cross-chain payments) 47