7 Security Features That Make Up LINE Blockchain

Mariko Shozawa (LINE / Blockchain Engineering Team / Software Engineer)

https://tech-verse.me/ja/sessions/85
https://tech-verse.me/en/sessions/85
https://tech-verse.me/ko/sessions/85

Transcript

2. Agenda - What is LINE Blockchain? - Blockchain Vulnerabilities - 7 Security Features 1. Random Selection Proposer 2. Two Stage Voting and Locking Mechanism 3. Key Management For Block Vote 4. Ensuring Validity of Transaction 5. Half Curve Order 6. Detect Malicious Node and Report 7. Peer Trust Metric - Summary
3. LINE Blockchain The scope of what we will discuss today -*/&
   #MPDLDIBJO
   .BJOOFU 11 /FUXPSL $POTFOTVT $SZQUPHSBQIZ LINE Blockchain Developers LINE BITMAX Wallet User Blockchain Service
4. LINE Blockchain Mainnet State Machine Replication Node a b c Node a b c Node a b c Node a b c Same data on every node P2P Network & Consensus - P2P Network: There is no distinction between client and server - Consensus: Majority voting determines output for input For a given input, all machines produce the same output
5. Vulnerability P2P Network Cryptography Consensus Selfish Mining Attack Long Range Attack ECDSA Malleability Eclipse Attack Side Channel Attack
6. 3. Key Management for Block Vote 4. Ensuring Validity of Transaction 5. Half Curve Order 6. Detect Malicious Node and Report 7. Peer Trust Metric 2. Two Stage Voting and Locking Mechanism 1. Random Selection Proposer 7 Security Features Consensus P2P Network Cryptography Selfish Mining Attack Long Range Attack ECDSA Malleability Eclipse Attack Side Channel Attack
7. Consensus Algorithm
8. Overview of Transaction Flow Block Z TX 1 Node Node Node Node Block X Block Y Block Z Blockchain network TX 2 TX n TX 1 TX 2
9. Proof of Work #MPDL
   *OUFSWBM Propose Propose Propose Propose Propose Vote Vote Vote Vote Vote Vote Vote Vote Vote() Vote Propose Propose Propose Propose Propose Timeout Vote
   /PEFT
   IBWF
   WPUJOH
   QPXFS
   BDDPSEJOH
   UP
   DPNQVUJOH
   QPXFS #MPDL
   *OUFSWBM Timeout Vote Votes are not collected Votes are not collected No Leader and Probabilistic Finality node A node B node C node D node E
10. Proof of Stake #MPDL
    *OUFSWBM 7PUF
    /PEFT
    IBWF
    WPUJOH
    QPXFS
    BDDPSEJOH
    UP
    DPNQVUJOH
    QPXFS
    /PEFT
    IBWF
    WPUJOH
    SJHIUT
    BDDPSEJOH
    UP
    UIF
    BNPVOU
    PG
    UPLFOT
    UIFZ
    IPME #MPDL
    *OUFSWBM coin= voting power 30 coin= voting power 25 coin= voting power 20 coin= voting power 15 coin= voting power 10 Propose 30 Propose 25 Propose 20 Propose 15 Propose 10 Vote 25 Propose 30 Propose 25 Propose 10 Propose 20 Vote 30 Vote 10 Vote 30 Propose 15 node A node C node D node E node B No Leader and Probabilistic Finality
11. #MPDL
    *OUFSWBM 7PUF
    /PEFT
    IBWF
    WPUJOH
    QPXFS
    BDDPSEJOH
    UP
    DPNQVUJOH
    QPXFS #MPDL
    *OUFSWBM coin= voting power 30 coin= voting power 25 coin= voting power 20 coin= voting power 15 coin= voting power 10 Propose 30 Vote 25 Propose 25 Vote 20 Vote 25 Vote 10 Vote 15 LINE Blockchain Mainnet node A node B node C node D node E Leader and Fast Finality Vote 15
12. 1. Random Selection Proposer
13. 3. Key Management for Block Vote 4. Ensuring Validity of Transaction 5. Half Curve Order 6. Detect Malicious Node and Report 7. Peer Trust Metric 2. Two Stage Voting and Locking Mechanism 1. Random Selection Proposer Security 1 Consensus P2P Network Cryptography Selfish Mining Attack Long Range Attack ECDSA Malleability Eclipse Attack Side Channel Attack
14. 1. Random Selection Proposer Requirement Only one proposer of a block is elected from the set of voters. Issue With the round robin method, the next proposer is predictable and the attack target is easily narrowed down. Solution Weighted election and verification by random number generation using "verifiable random functions”
15. Random Selection Proposer D C B A generate random number A gets the winning ticket ! A B C D 0 1 0 1 Min-Max Normalization Verifiable random function: message = sha256(height || round || previous hash) (message, private key) → hash, proof - A hash is used as random number - A proof can prove that you are the creator of the hash Ref: https://github.com/line/ostracon/blob/v1.0.7/docs/ja/02-consensus.md
16. 2. Two Stage Voting and Locking Mechanism
17. 3. Key Management for Block Vote 4. Ensuring Validity of Transaction 5. Half Curve Order 6. Detect Malicious Node and Report 7. Peer Trust Metric 2. Two Stage Voting and Locking Mechanism 1. Random Selection Proposer Security 2 Consensus P2P Network Cryptography Selfish Mining Attack Long Range Attack ECDSA Malleability Eclipse Attack Side Channel Attack
18. 2. Two Stage Voting and Locking Mechanism Requirement Ensures that multi- nodes are not allowed to vote on multiple blocks when voting asynchronously Issue A single stage voting causes a state transition where multiple blocks are approved as the round progresses Solution Two stage voting with prevote and precommit
19. Two Stage Voting and Locking Mechanism Voting workflow If +2/3 precommits are found, commit the block and propose a new height block. If not, propose another block of the same height in the next round +2/3 prevote for block +2/3 precommit for block Commit New height Propose block Prevote block Precommit block New round
20. Two Stage Voting and Locking Mechanism Why two stage voting A, B, C → Round R+1, propose Block X’ D → Commit Block X Block V Block W Block X' Block V Block W Block X A, B, C D fork !!! # % " $ Block X = { nil, vote B, vote_C} < 2/3* 4 members A, B, C Block X = { nil, vote_B, vote_C, vote_D} > 2/3* 4 members D Gossip Protocol D only gossip fail! vote = Precommit Round R " Block X nil # $ % vote vote vote
21. Two Stage Voting and Locking Mechanism Why two stage voting A, B, C → Round R+1, propose Block X’ D → Commit Block X Block V Block W Block X' Block V Block W Block X A, B, C D fork !!! # % " $ Block X = { nil, vote B, vote_C} < 2/3* 4 members A, B, C Block X = { nil, vote_B, vote_C, vote_D} > 2/3* 4 members D Gossip Protocol D only gossip fail! vote = Precommit Round R " Block X nil # $ % vote vote vote
22. Two Stage Voting and Locking Mechanism Why two stage voting A, B, C → Round R+1, propose Block X’ D → Commit Block X Block V Block W Block X' Block V Block W Block X A, B, C D fork !!! # % " $ Block X = { nil, vote B, vote_C} < 2/3* 4 members A, B, C Block X = { nil, vote_B, vote_C, vote_D} > 2/3* 4 members D Gossip Protocol D only gossip fail! vote = Precommit Round R " Block X nil # $ % vote vote vote
23. Two Stage Voting and Locking Mechanism Lock & Unlock Rule - Voters can cancel their vote for a block at previous round if they see +2/3 votes for a different block at later round - Voters can vote for a different block at prevote or precommit when unlocked Unlock Rule Lock Rule - Voters are locked into the block where they voted at prevote or precommit - Voters cannot vote for a different block at prevote or precommit when locked
24. Two Stage Voting and Locking Mechanism vote = Precommit Round R " Block X nil # $ % nil vote nil vote = Prevote Round R+1 " Block Y vote # $ % vote nil vote Block V Block W Block Y vote B Block Y vote C vote D A, B, C, D vote = Precommit Round R+1 vote A vote B vote C vote D Can vote vote A
25. Two Stage Voting and Locking Mechanism vote = Precommit Round R " Block X nil # $ % nil vote nil vote = Prevote Round R+1 " Block Y vote # $ % vote nil vote Block V Block W Block Y vote B Block Y vote C vote D A, B, C, D vote = Precommit Round R+1 vote A vote B vote C vote D Can vote vote A
26. Two Stage Voting and Locking Mechanism vote = Precommit Round R " Block X nil # $ % nil vote nil vote = Prevote Round R+1 " Block Y vote # $ % vote nil vote Unlock +2/3 Block V Block W Block Y vote B Block Y vote C vote D A, B, C, D vote = Precommit Round R+1 vote A vote B vote C vote D Can vote vote A
27. Two Stage Voting and Locking Mechanism Byzantine Fault Tolerance Consensus works even if up to 1/3 Byzantine If byzantine node is less than 1/3, agreement can be made among nodes Node Node OK OK OK Node NG OK Node OK OK NG TrustGuard: countering vulnerabilities in reputation management for decentralized overlay networks “The Byzantine Generals Problem” Ref:https://www.microsoft.com/en-us/research/uploads/ prod/2016/12/The-Byzantine-Generals-Problem.pdf
28. Two Stage Voting and Locking Mechanism " Block Z NG # $ % OK OK OK byzantine! Rule violation! Then, B,C, D. Precommit Block Z Block V Block W Block Z A, B, C, D LINE Blockchain Mainnet with BFT
29. 3. Key Management For Block Vote
30. 3. Key Management for Block Vote 4. Ensuring Validity of Transaction 5. Half Curve Order 6. Detect Malicious Node and Report 7. Peer Trust Metric 2. Two Stage Voting and Locking Mechanism 1. Random Selection Proposer Security 3 Consensus P2P Network Cryptography Selfish Mining Attack Long Range Attack ECDSA Malleability Eclipse Attack Side Channel Attack
31. 3. Key Management for Block Vote Requirement The key used to vote for a block must always be online (the key is loaded into memory and used) Issue If the key is stolen from memory, the vote can be forged Solution Intel SGX for key loading in safe memory space
32. Key Management for Block Vote Vote for Block and Signature Approval Forgery Flow: 1. loading a key from a json file 2. Stealing keys in memory 3. Using stolen keys, authorize 4. Adding blocks by forging approvals Solved by encrypting read into a secure memory space. More details in the session: “Secure Key Management System Using Intel SGX Technology" URL:https://tech-verse.me/sessions/82 “Vd2NqqPhV1J k” A Block is added illegally! vote: precommit vote:nil Stolen key Steal the key Malicious node ̍ 2 3 4
33. 4. Ensuring Validity of Transaction
34. 3. Key Management for Block Vote 4. Ensuring Validity of Transaction 5. Half Curve Order 6. Detect Malicious Node and Report 7. Peer Trust Metric 2. Two Stage Voting and Locking Mechanism 1. Random Selection Proposer Security 4 Consensus P2P Network Cryptography Selfish Mining Attack Long Range Attack ECDSA Malleability Eclipse Attack Side Channel Attack
35. 4. Ensuring Validity of Transaction Requirement Processing only valid transactions Issue Checking Tx and Block tampering one by one is inefficient Solution Proof generation and verification using IAVL Merkle Tree
36. Ensuring Validity of Transaction Sender ( Prover ) and Receiver ( Verifier ) Verification tx sender: Alice tx receiver: Bob When Bob receives a tx, he verifies that it is an approved transaction. Verification method: Check using the Proof in the header of the block "MJDF #PC Is the tx in the list? From:Alice to:Bob 5SBOTBDUJPO" UY #MPDL
    ) Height Proof )FBEFS Tx_A Tx_B Tx_C Tx_D #PEZ ʜ ʜ
37. Ensuring Validity of Transaction IAVL Merkle Tree Transactions are recorded as indexed data in a tree structure hash tree. Sender: Transactions are recorded as indexed data in a tree structure hash tree. 3 transactions are {Tx: a=1, Tx: b=2, Tx: c=3} Receiver: Received associated hash values from full node using a=1, b=2, c=3. Check RootHash = Proof using hash=d6f56d E D F C D C B F E E D C IBTI
    EGE D
    IBTI  C
    IBTI  B
    IBTI  D C B UY UY UY "MJDF
    4FOEFS
    
    QSPWFS #PC
    3FDFJWFS
    
    7FSJpFS SPPU
    IBTI 1SPPG
    
38. Ensuring Validity of Transaction IAVL Merkle Tree Transactions are recorded as indexed data in a tree structure hash tree. Sender: Transactions are recorded as indexed data in a tree structure hash tree. 3 transactions are {Tx: a=1, Tx: b=2, Tx: c=3} Receiver: Received associated hash values from full node using a=1, b=2, c=3. Check RootHash = Proof using hash=d6f56d E D F C D C B F E E D C IBTI
    EGE D
    IBTI  C
    IBTI  B
    IBTI  D C B UY UY UY "MJDF
    4FOEFS
    
    QSPWFS #PC
    3FDFJWFS
    
    7FSJpFS SPPU
    IBTI 1SPPG
    
39. Ensuring Validity of Transaction E D F C D C B F E IBTI
    EGE IBTI  IBTI  IBTI  IBTI ʜ IBTI 
    cc
     IBTI ʜ
    *"7-
    .FSLMF
    5SFF .FSLMF
    5SFF
40. 5. Half curve order
41. 3. Key Management for Block Vote 4. Ensuring Validity of Transaction 5. Half Curve Order 6. Detect Malicious Node and Report 7. Peer Trust Metric 2. Two Stage Voting and Locking Mechanism 1. Random Selection Proposer Security 5 Consensus P2P Network Cryptography Selfish Mining Attack Long Range Attack ECDSA Malleability Eclipse Attack Side Channel Attack
42. 5. Half Curve Order Requirement Only one valid signature for a transaction Issue Generating a signature using secp256k1 results in two valid signatures Solution Check if the value is in the range of half of the order
43. Half Curve Order Two valid signatures are created How Alice’s transaction is signed 1. Convert tx data to hash curve 2. Create one signature on an elliptic curve using one private key 3. Elliptic curves are X-axis symmetric, so two valid signatures are created! 2 "MJDF UY
    EBUB
    )BTI
    GVOD )BTI 1SJWBUF
    LFZ 4JHO
    UY 4JHOBUVSF "MJDF
    
    TJHO  TJH TJH Z Y TJH TJH "MJDF
    
    TJHO ̍ 3
44. Half Curve Order Remove half the points from the group On elliptic curves, the module operation Signature is expressed as the remainder divided by n 0 1 2 3 .. 5 .. 4 .. .. 6 7 8 .. 10 9 .. .. .. 6 7 8 .. 10 9 .. .. .. Sig’ Sig Example: n=11 n=11, sig = 4 , sig’ = 7 sig ∈ [0, 11) check valid: sig <= (n-1)/2 This check can exclude sig'. JOWBMJE
45. 6. Detect Malicious Node and Report
46. 3. Key Management for Block Vote 4. Ensuring Validity of Transaction 5. Half Curve Order 6. Detect Malicious Node and Report 7. Peer Trust Metric 2. Two Stage Voting and Locking Mechanism 1. Random Selection Proposer Security 6 Consensus P2P Network Cryptography Selfish Mining Attack Long Range Attack ECDSA Malleability Eclipse Attack Side Channel Attack
47. 6. Detect Malicious Node and Report Requirement Detect malicious nodes Issue Verification with full data is too costly for node storage Solution Light nodes that do not have a transaction list to detect and report
48. Detect Malicious Node and Report Light Node Node A Node C Light Node Node B Monitoring ̍ 2 Send Evidence Block Header #MPDL Block Header #MPDL Block Header Block Header #MPDL
49. Detect Malicious Node and Report 11 (Hash:X) 10 12 (Hash:Z) 11’ (Hash:Y) 12’ (Hash:W) from primary from witness Light Node Detect Attack Light Node receives headers for blocks 11 and 12 from primary node Light Node receives headers for blocks 11’ and 12’ from witness node Compares the two headers and detects discrepancies Attack detection by Light Node
50. Detect Malicious Node and Report Full node checks if “previous block dependent fields” evidence Detecting a discrepancy in one place does not indicate which is correct. Headers are obtained from multiple nodes for monitoring, called witness nodes, to determine which one is incorrect. Light Node Primary Node Witness Node Witness Node Witness Node Attack detection by Light Node with Witness
51. 7. Peer Trust Metric
52. 3. Key Management for Block Vote 4. Ensuring Validity of Transaction 5. Half Curve Order 6. Detect Malicious Node and Report 7. Peer Trust Metric 2. Two Stage Voting and Locking Mechanism 1. Random Selection Proposer Security 7 Consensus P2P Network Cryptography Selfish Mining Attack Long Range Attack ECDSA Malleability Eclipse Attack Side Channel Attack
53. 7. Peer Trust Metric Requirement Gossip with quality peer to avoid performance loss Issue Need to define good quality peers Solution Calculation and ranking of confidence values by proportional (latest value), integral (history), and derivative (behavior variation) factors
54. ɹPeer Trust Metric Connect to better peers node A Dialing B ! Trust Value E B D A C address B address E address book … Criteria for choosing Peers - Peers are ordered by the order of their calculated trust value int the address book - Connect to the peer with the highest trust value - Trust value is calculated based on events - The address book is updated using trust values. ex. good event: good connection bad event: Poor connection, incorrect block transmission
55. Peer Trust Metric Calculate trust value Proportional, Integral and Derivative TrustValue[i] = a * R[i] Propotionalcomponent + b * H[i] Integralcomponent + c(D[i]) * D[i] Derivativecomponent (1) PropotinalValue = a * R[i] (2) IntegralValue = b * H[i] H[i] = maxH ∑ k=1 R[i + k] * [ w k ∑maxH k=1 wk ] (3) DerivativeValue = c(D[i]) * D[i] D[i] = R[i] − H[i] - Proportional Component:Value of the most recent time interval i - Integral Component:History weighted by time interval - Derivative Component:Value representing a sudden change from good peers to bad peers Factors of most recent, previous, and sudden changes are combined and ranked TrustGuard: countering vulnerabilities in reputation management for decentralized overlay networks “TrustGuard: countering vulnerabilities in reputation management for decentralized overlay networks” Ref:https://dl.acm.org/doi/10.1145/1060745.1060808
56. Summary
57. 3. Key Management for Block Vote 4. Ensuring Validity of Transaction 5. Half Curve Order 6. Detect Malicious Node and Report 7. Peer Trust Metric 2. Two Stage Voting and Locking Mechanism 1. Random Selection Proposer Summary Consensus P2P Network Cryptography Selfish Mining Attack Long Range Attack ECDSA Malleability Eclipse Attack Side Channel Attack
58. In The Future - Commitment Scheme (Block proof & verify) - RSA Accumulator - Pointproofs - Digital Signature Algorithm - IASchnorr Signature
59. Thank you