FAKULTÄT FÜR !NFORMATIK
Faculty of Informatics
S&P SECURITY & PRIVACY GROUP
Security and Privacy for Payment Channel Networks
Pedro Moreno-Sanchez
Blockchain Summer School BDLT’19 Vienna, Sep 2nd 2019
2
Blockchain Research Lab: Highlights• CoinShuffle: privacy-preserving protocol for
blockchain payments implemented in several cryptocurrencies wallets
• AMHL: first solution for security, privacy and interoperability issues with blockchain scalability protocols. Implemented in LND (current Bitcoin scalability protocol), KZen Network and COMIT Network
• DLSAG: first scalability protocol with formal guarantees for the Monero cryptocurrency. Under discussion in the Monero community for adoption.
• Lots of work on:
• Security verification and safe design of smart contracts
• Privacy-preserving routing mechanisms
• Constant collateral for Bitcoin-compatible PCNs
3
Blockchain Research Lab: Collaborations
C.Schneidewind E.Tairi I.Grischchenko M.Maffei
3
Blockchain Research Lab: Collaborations
C.Schneidewind E.Tairi I.Grischchenko M.Maffei
3
Blockchain Research Lab: Collaborations
C.Schneidewind E.Tairi I.Grischchenko M.Maffei
A.Kate
G.Malavolta C.Egger
S.Roos
I.Goldberg
A.Gervais
‣ Decentralized data structure recording each transaction in order to provide public verifiability
‣ Global consensus: everyone checks the whole blockchain
4
Scalability Issues
Bitcoin’s transaction rate: ~10 tx/sec
Visa’s transaction rate: ~10K tx/sec
‣ On-chain (tweak consensus) e.g., DAG Blockchain, sharding, ...
‣ Off-chain (use blockchain only for disputes) e.g., Payment Channel Networks
Many other research projects (Bolt, Z-Channels, Perun, Liquidity Network ...)
Lightning Network (Bitcoin)
Raiden Network (Ethereum)
5
Scalability Solutions?
‣ On-chain (tweak consensus) e.g., DAG Blockchain, sharding, ...
‣ Off-chain (use blockchain only for disputes) e.g., Payment Channel Networks
Many other research projects (Bolt, Z-Channels, Perun, Liquidity Network ...)
Lightning Network (Bitcoin)
Raiden Network (Ethereum)
5
Scalability Solutions?
6
Background on Payment Channel Networks
7
Payment Channels: Open
Alice Bob
Blockchain
5 1
7
Payment Channels: Open
Alice Bob
Blockchain
Multisig Contract
Can be spent only with the signatures of both Alice and Bob
5 1
5 (Alice)
5 (Alice,Bob)
Alice
‣ Alice creates multisig contract to deposit money on the channel
7
Payment Channels: Open
Alice Bob
Blockchain
Multisig Contract
Can be spent only with the signatures of both Alice and Bob
5 1
5 (Alice)
5 (Alice,Bob)
Alice
5 (Alice,Bob)
5 (Alice)
Alice,Bob
‣ Alice creates multisig contract to deposit money on the channel
‣ Alice lets Bob sign a refund transaction to unlock the money
8
Payment Channels: Open
Alice Bob
Blockchain
5 1
5 (Alice)
5 (Alice,Bob)
Alice
5 (Alice,Bob)
5 (Alice)
Alice,Bob
‣ Alice creates multisig contract to deposit money on the channel
‣ Alice lets Bob sign a refund transaction to unlock the money
‣ Alice places the multisig contract onchain
9
Payment Channels: Transactions
Blockchain
5 (Alice, Bob)4 (Alice)
1 (Bob)
Alice ?? Bob
4 1
Alice Bob
5 (Alice)
5 (Alice,Bob)
Alice
10
Payment Channels: Transactions
Blockchain
5 (Alice, Bob)
3 (Alice)
2 (Bob)
Alice ?? Bob
3 2
Alice Bob5 (Alice, Bob)
3 (Alice)
2 (Bob)
Alice ?? Bob
5 (Alice)
5 (Alice,Bob)
Alice
Under the hood
Mechanisms for bidirectional payments and for revocation of old states
5 (Alice, Bob)3 (Alice)
2 (Bob)
Alice,Bob
Payment Channels: Close
Blockchain
Alice Bob
5 (Alice)
5 (Alice,Bob)
Alice
12
Payment Channel Networks (PCNs)
4 1 2 3
Alice Bob CarolSend
1 BTC to Carol
One cannot open channels with everyone...exploit channel paths!⇒
12
Payment Channel Networks (PCNs)
4 1 2 3
Alice Bob Carol
Bob
2 33 2
CarolAlice
1. Send 1 BTC
Send 1 BTC to Carol
12
Payment Channel Networks (PCNs)
4 1 2 3
Alice Bob Carol
Bob
2 33 2
CarolAlice
1. Send 1 BTC
Send 1 BTC to Carol
3 2 1 4
Alice Bob Carol2. Forward 1 BTC to
Carol
Should happen atomically
12
Payment Channel Networks (PCNs)
4 1 2 3
Alice Bob Carol
Bob
2 33 2
CarolAlice
1. Send 1 BTC
Send 1 BTC to Carol
3 2 1 4
Alice Bob Carol2. Forward 1 BTC to
Carol
Should happen atomically
12
Payment Channel Networks (PCNs)
4 1 2 3
Alice Bob Carol
Bob
2 33 2
CarolAlice
1. Send 1 BTC
Send 1 BTC to Carol
Fee acts as an incentive for Bob to participate in the
payment
3 2 1 4
Alice Bob Carol2. Forward 1 BTC to
Carol
3-fee 2fee
3-fee 2fee
1. Send 1 BTC + fee to Bob
13
The Lightning Network (LN)
5
14
Hashtime Lock Contract (HTLC)
5 (Alice, Bob)
4 (Alice)
1 (Bob)
Alice ?? Bob
4 1
Alice Boby
5 (Alice, Bob)4 (Alice)
1 (Bob)
Alice ?? Bob
5
14
Hashtime Lock Contract (HTLC)
5 (Alice, Bob)
4 (Alice)
1 (Bob)
Alice ?? Bob
4 14 1
Alice Boby
x
5 (Alice, Bob)4 (Alice)
1 (Bob)
Alice ?? Bob
y
With knowledge of x, Bob can “open” + publish the
transaction on the blockchain
for enforcing the payment
5
14
Hashtime Lock Contract (HTLC)
5 (Alice, Bob)
4 (Alice)
1 (Bob)
Alice ?? Bob
4 14 1
Alice Boby
x After time the transaction cannot be published anymore on
the blockchain
5 (Alice, Bob)4 (Alice)
1 (Bob)
Alice ?? Bob
y
With knowledge of x, Bob can “open” + publish the
transaction on the blockchain
for enforcing the payment
5
14
Hashtime Lock Contract (HTLC)
5 (Alice, Bob)
4 (Alice)
1 (Bob)
Alice ?? Bob
4 14 1
Alice Boby
x
HTLC (Alice, Bob, 1, y, ): Alice pays Bob 1 BTC iff Bob shows some
x such that H(x) = y before
After time the transaction cannot be published anymore on
the blockchain
5 (Alice, Bob)4 (Alice)
1 (Bob)
Alice ?? Bob
y
With knowledge of x, Bob can “open” + publish the
transaction on the blockchain
for enforcing the payment
3 2
15
HTLC for Multi-hop Payments
Alice Bob Carol
y:= H(x)
x
2 3
3 2
15
HTLC for Multi-hop Payments
Alice Bob Carol
y:= H(x)
x
y
2 3
3 2
15
HTLC for Multi-hop Payments
Alice Bob Carol
HTLC(Alice, Bob, 1.1, y, t)
y:= H(x)
x
y
2 31.10.9 3
1
3 2
15
HTLC for Multi-hop Payments
Alice Bob Carol
HTLC(Alice, Bob, 1.1, y, t) HTLC(Bob, Carol, 1, y, t’)
2 21
y:= H(x)
x
y
2 31.10.9 3
1
3 2
15
HTLC for Multi-hop Payments
Alice Bob Carol
HTLC(Alice, Bob, 1.1, y, t) HTLC(Bob, Carol, 1, y, t’)
2 21
y:= H(x)
x
y
x
2 32 31.10.9 3
1
3 2
15
HTLC for Multi-hop Payments
Alice Bob Carol
HTLC(Alice, Bob, 1.1, y, t) HTLC(Bob, Carol, 1, y, t’)
2 21
y:= H(x)
x
y
x x
2 32 31.10.9 3
1
0.9 4.1
3 2
15
HTLC for Multi-hop Payments
Alice Bob Carol
HTLC(Alice, Bob, 1.1, y, t) HTLC(Bob, Carol, 1, y, t’)
2 21
y:= H(x)
x
yRequirement: t > t’
(after Carol revealed x to Bob, there must still be time for Bob to reveal x
to Alice)
x x
2 32 31.10.9 3
1
0.9 4.1
‣ Lightning Network & Co work allow us to perform payments offchain
• fast, no confirmation delay
• little fees
• minimal information stored on the blockchain
• secure and privacy-preserving (at a first glance...)
‣ The blockchain is used only to mediate disputes...cool!
16
Take home...
HTLC (Alice, Bob, 1.1, y, t): Alice pays Bob 1.1 BTC iff Bob shows some
x such that H(x) = y before t days 3 2Alice Bob Carol
HTLC(Alice, Bob, 1.1, y, t) HTLC(Bob, Carol, 1, y, t’)
2 21
y:= H(x)
x
y
x x
2 32 310. 3
1
0.9 4.1
17
Security + Privacy in PCNs
Are off-chain payments in PCNs privacy-preserving by default?
(individual payments are not recorded on the blockchain)
Are off-chain payments in PCNs secure? (No honest participant looses money)
17
Security + Privacy in PCNs
Are off-chain payments in PCNs privacy-preserving by default?
(individual payments are not recorded on the blockchain)
Are off-chain payments in PCNs secure? (No honest participant looses money)
NO!
NO!
18
Security and Privacy Issues in Existing PCNs
ACM CCS 2017
NDSS 2019
19
Security Issue: The Wormhole Attack
A CE1 E2
HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)
y:= H(x)x
B
19
Security Issue: The Wormhole Attack
A CE1 E2
HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)
y:= H(x)x
xB
19
Security Issue: The Wormhole Attack
A CE1 E2
HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)
y:= H(x)x
x
x
B
19
Security Issue: The Wormhole Attack
A CE1 E2
HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)
y:= H(x)x
x
x
xB
19
Security Issue: The Wormhole Attack
A CE1 E2
HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)
y:= H(x)x
x
x
x
B considers the payment to be failed and unlocks his funds after the timeout
B
19
Security Issue: The Wormhole Attack
A CE1 E2
HTLC(A, E1,1.3,y, t1) HTLC(E1, B,1.2,y, t2) HTLC(B, E2,1.1,y, t3) HTLC(E2, C,1,y, t4)
y:= H(x)x
x
x
x
B considers the payment to be failed and unlocks his funds after the timeout
B
gets 1.3 (no payment to B)
pays 1 (no payment from B)
Attacker earns 0.3 BTC (own fees + B’s fee)
20
Privacy Issues in HTLC Payments
A C
E1 E2
HTLC(A,E1,v1,y,t1)
HTLC(E1,B,v2,y,t2) HTLC(B,E2,v3,y,t3)
HTLC(E2,C,v4,y,t4)
B
A’C’
Relationship Anonymity: On-path adversaries do not learn who pays to whom
HTLC(A,E1,v1,y’,t1)
HTLC(E1,B,v2,y’,t2) HTLC(B,E2,v3,y’,t3)
HTLC(E2,C,v4,y’,t4)
20
Privacy Issues in HTLC Payments
A C
E1 E2
HTLC(A,E1,v1,y,t1)
HTLC(E1,B,v2,y,t2) HTLC(B,E2,v3,y,t3)
HTLC(E2,C,v4,y,t4)
B
A’C’
pays to
pays to≈ pays to
pays to
Relationship Anonymity: On-path adversaries do not learn who pays to whom
HTLC(A,E1,v1,y’,t1)
HTLC(E1,B,v2,y’,t2) HTLC(B,E2,v3,y’,t3)
HTLC(E2,C,v4,y’,t4)
20
Privacy Issues in HTLC Payments
A C
E1 E2
HTLC(A,E1,v1,y,t1)
HTLC(E1,B,v2,y,t2) HTLC(B,E2,v3,y,t3)
HTLC(E2,C,v4,y,t4)
B
A’C’
pays to
pays to≈ pays to
pays to
Relationship Anonymity: On-path adversaries do not learn who pays to whom
HTLC(A,E1,v1,y’,t1)
HTLC(E1,B,v2,y’,t2) HTLC(B,E2,v3,y’,t3)
HTLC(E2,C,v4,y’,t4)
20
Privacy Issues in HTLC Payments
A C
E1 E2
HTLC(A,E1,v1,y,t1)
HTLC(E1,B,v2,y,t2) HTLC(B,E2,v3,y,t3)
HTLC(E2,C,v4,y,t4)
B
A’C’
pays to
pays to≈ pays to
pays to
Relationship Anonymity: On-path adversaries do not learn who pays to whom
HTLC(A,E1,v1,y’,t1)
HTLC(E1,B,v2,y’,t2) HTLC(B,E2,v3,y’,t3)
HTLC(E2,C,v4,y’,t4)
21
Solving Security and Privacy Issues in Payment Channel Networks
22
Solving Security + Privacy Issues
Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)
Randomised conditions at each hop that can only be released by (exactly) the
right neighbour’s key
22
Solving Security + Privacy Issues
Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)
k3k1 k2 k4
Setup phase for the distribution of individual
“randomisation factors” for users at each hop
Randomised conditions at each hop that can only be released by (exactly) the
right neighbour’s key
22
Solving Security + Privacy Issues
Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)
k3k1 k2 k4
Setup phase for the distribution of individual
“randomisation factors” for users at each hop
Desired Properties
No coin loss
1.Atomicity: If a user’s right lock gets opened, he can open his left lock
2.Consistency: A user can open his left lock only if his right lock was released
3.Relationship Anonymity:A user learns about no other participant of the payment path than his direct neighbours
No Wormhole Attacks Privacy
Randomised conditions at each hop that can only be released by (exactly) the
right neighbour’s key
ECDSA-based construction
23
Anonymous Multi-hop-Locks (AMHL)
Ideal functionality (capturing atomicity,
consistency + relationship anonymity)
Construction from homographic one-
way functions
Schnorr-based construction
provably realise in the UC framework
ECDSA-based construction
23
Anonymous Multi-hop-Locks (AMHL)
Ideal functionality (capturing atomicity,
consistency + relationship anonymity)
Construction from homographic one-
way functions
Schnorr-based construction
ECDSA-based construction
provably realise in the UC framework
compatible with Bitcoin, Ethereum,
etc.
24
ECDSA-based Secure PCNs
25
Scriptless Scripts
yy
5
25
Scriptless Scripts
Alice (skA)
Bob(skB)yy
AB
hypothetical “shared identity”
skAB = skA * skBBlockchain
5
25
Scriptless Scripts
4 1
Alice (skA)
Bob(skB)yy
AB
hypothetical “shared identity”
skAB = skA * skBBlockchain
5 (AB)4 (Alice)
1 (Bob)
yAB ??k
5 (Alice)
5 (AB)
Alice
5
25
Scriptless Scripts
4 1
Alice (skA)
Bob(skB)yy
Alice can retrieve secret k from full signature
Bob gets sufficient information for checking that the “half signature” produced by Alice and Bob can be
completed to a valid signature given k
AB
hypothetical “shared identity”
skAB = skA * skBBlockchain
5 (AB)4 (Alice)
1 (Bob)
yAB ??k
5 (Alice)
5 (AB)
Alice
26
Extension to Multi-hop Locks
Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)
(k4, C4)(k2, C2) (k3, C3) (k1 + k2 + k3 + k4)
k1*G (k1 + k2)*G (k1 + k2 + k3)*G
A CE1 E2B
(k1 + k2 + k3 + k4)*G
26
Extension to Multi-hop Locks
Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)
(k4, C4)(k2, C2) (k3, C3) (k1 + k2 + k3 + k4)
k1*G (k1 + k2)*G (k1 + k2 + k3)*G
A CE1 E2
(k1 + k2 + k3 + k4)
B
(k1 + k2 + k3 + k4)*G
26
Extension to Multi-hop Locks
Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)
(k4, C4)(k2, C2) (k3, C3) (k1 + k2 + k3 + k4)
k1*G (k1 + k2)*G (k1 + k2 + k3)*G
A CE1 E2
(k1 + k2 + k3 + k4)
B
(k1 + k2 + k3 + k4)*G
(k1 + k2 + k3)
- k4
26
Extension to Multi-hop Locks
Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)
(k4, C4)(k2, C2) (k3, C3) (k1 + k2 + k3 + k4)
k1*G (k1 + k2)*G (k1 + k2 + k3)*G
A CE1 E2
(k1 + k2 + k3 + k4)
B
(k1 + k2 + k3 + k4)*G
(k1 + k2 + k3)(k1 + k2)
- k3 - k4
26
Extension to Multi-hop Locks
Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)
(k4, C4)(k2, C2) (k3, C3) (k1 + k2 + k3 + k4)
k1*G (k1 + k2)*G (k1 + k2 + k3)*G
A CE1 E2
(k1 + k2 + k3 + k4)
B
(k1 + k2 + k3 + k4)*G
(k1 + k2 + k3)(k1 + k2)k1
- k2 - k3 - k4
26
Extension to Multi-hop Locks
Lock(A, E1,1.3,C1,t1) Lock(E1,B,1.2,C2,t2) Lock(B,E2,1.1,C3,t3) Lock(E2,C,1,C4, t4)
(k4, C4)(k2, C2) (k3, C3) (k1 + k2 + k3 + k4)
k1*G (k1 + k2)*G (k1 + k2 + k3)*G
A CE1 E2
(k1 + k2 + k3 + k4)
B
(k1 + k2 + k3 + k4)*G
(k1 + k2 + k3)(k1 + k2)k1
A valid key can only be extracted from a valid key for the right lock
- k2 - k3 - k4
Conditions look random (as they differ by a secret
random factor)
27
ECDSA-based Scriptless Lock
xR = r * G
σR = sign(r, sk, transaction)
secret key messagesecret randomness
Signature w.r.t. a (public)
random elliptic curve point R
27
ECDSA-based Scriptless Lock
xR = r * G
σR = sign(r, sk, transaction)
secret key messagesecret randomness
shared signature using a shared key and a shared randomnessrA*rBrA*rB*G skA*skBAB
Signature w.r.t. a (public)
random elliptic curve point R
27
ECDSA-based Scriptless Lock
xR = r * G
σR = sign(r, sk, transaction)
secret key messagesecret randomness
shared signature using a shared key and a shared randomnessrA*rBrA*rB*G skA*skBAB
embedding of random share (condition) krA*rB*k*G rA*rB*k skA*skBAB
Signature w.r.t. a (public)
random elliptic curve point R
27
ECDSA-based Scriptless Lock
xR = r * G
σR = sign(r, sk, transaction)
secret key messagesecret randomness
shared signature using a shared key and a shared randomnessrA*rBrA*rB*G skA*skBAB
embedding of random share (condition) krA*rB*k*G rA*rB*k skA*skBAB
Signature w.r.t. a (public)
random elliptic curve point R
rA*rBrA*rB*k*G skA*skBAB“half signature” without k but still with respect to
rA*rB*k*G
27
ECDSA-based Scriptless Lock
xR = r * G
σR = sign(r, sk, transaction)
secret key messagesecret randomness
shared signature using a shared key and a shared randomnessrA*rBrA*rB*G skA*skBAB
embedding of random share (condition) krA*rB*k*G rA*rB*k skA*skBAB
Signature w.r.t. a (public)
random elliptic curve point R
rA*rBrA*rB*k*G skA*skBAB“half signature” without k but still with respect to
rA*rB*k*G
Lock
Pro
toco
l
AB AB
(skA, rA) (skB, rB)C=k*G, transaction
“1/3” signature σR,B
“1/3” signature σR,A
…
27
ECDSA-based Scriptless Lock
xR = r * G
σR = sign(r, sk, transaction)
secret key messagesecret randomness
shared signature using a shared key and a shared randomnessrA*rBrA*rB*G skA*skBAB
embedding of random share (condition) krA*rB*k*G rA*rB*k skA*skBAB
Signature w.r.t. a (public)
random elliptic curve point R
rA*rBrA*rB*k*G skA*skBAB“half signature” without k but still with respect to
rA*rB*k*G
Lock
Pro
toco
l
AB AB
(skA, rA) (skB, rB)C=k*G, transaction
“1/3” signature σR,B
“1/3” signature σR,A
…
Hard for ECDSA as σR
has a non-linear structure
28
Properties/Evaluation
‣ Security and Privacy proven formally (in the UC Framework)
‣ Compatible with Bitcoin and current PCNs
✓ Implemented in
✓Lightning Network (https://github.com/cfromknecht/tpec)
✓Kzen Network (https://github.com/KZen-networks/multi-hop-locks)
✓COMIT Network (https://github.com/coblox/ss-ecdsa-poc)
‣ Reduces transaction size for conditional payments
✓Encoding of condition within signature
‣ Makes settlement transactions indistinguishable from regular ones
(Fungibility)
‣ Little overhead:
✓ < 500 bytes communication
✓ few ms computation
Alice,Bob ?? AB⤳
AB ?k⤳
‣ AMHLs are suitable for cross-currency usage - even with different primitive instantiations
✓ Inter-currency payment channels
✓ Atomic swaps
29
Interoperability
ECDSA
DLOG
30
Summary
The Wormhole Attack: A novel attack on Payment Channel
Network Security
Concrete constructions of AMHLs that
… got implemented in Bitcoin’s Lightning Network
… enable inter-blockchain Payment Channels
… are efficient
AMHLs: A new primitive for secure + anonymous Payment Channel
Networks
