Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bullet" - Codemotion Amsterdam 2019

13 visualizaciones

Publicado el

Blockchain (and Cryptocurrency) is an evolution of 20-year old research from scientists like Chaum, Lamport, and Castro & Liskov. Due to the current hype, it's hard to distinguish beneficial aspects of the technology from a desire for a "silver bullet" for device security, verifiable logistics, or "saving democracy". The problem: blockchain introduces new security challenges - and blind adoption without understanding reduces overall security. In this talk, Melanie Rieback and Klaus Kursawe explain the pitfalls and limits of blockchain, so you can avoid making your applications LESS secure.

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Melanie Rieback, Klaus Kursawe - Blockchain Security: Melting the "Silver Bullet" - Codemotion Amsterdam 2019

  1. 1. Blockchain Security: Melting the "Silver Bullet" Dr. Melanie Rieback and Dr. Klaus Kursawe Amsterdam | April 2-3, 2019
  2. 2. Apr 2, 2019 About Us Dr. Melanie Rieback Dr. Klaus Kursawe
  3. 3. Apr 2, 2019 Blockchain vs. Santa ● “Everybody knows Smart Meters are insecure. By using blockchain, we don’t need to secure them anymore” ● “Blockchain solves all our privacy problems” ● “Thanks to blockchain, we don’t need public key cryptography anymore” ● “We are a blockchain startup, and we need someone to explain to us how digital signatures work” ● Secure elections because.. blockchain!
  4. 4. Apr 2, 2019 Blockchain is old technology David Chaum Leslie Lamport Ralph Merkle Barbara Liskov Miguel Castro
  5. 5. Apr 2, 2019 Application Security Issues ● Complex code + protocols + APIs ● Digital vs. Physical coupling
  6. 6. Apr 2, 2019 Application Security Issues (2) ● Immutability makes application AND security updates difficult ● Forking issues
  7. 7. Apr 2, 2019 The Downside of Data Immutability ● It’s hard to get unintended things OUT of a blockchain ● Embedded in the Bitcoin blockchain ● Len Sassaman tribute ● XSS demo ● Rickrolls ● Wikileaks Cablegate data ● etc..
  8. 8. Apr 2, 2019 Smart Contracts ● Smart contracts = Remote Code Execution (RCE) ● Examples: ● Etherdelta code injection ● Mythril = Ethereum contract bytecode analyzer (HitB 2018) ● Smart contracts are immutable. Therefore bugs in the code are impossible to fix. ● Used to attack Decentralized Autonomous Organisations (DAOs)
  9. 9. Apr 2, 2019 Mining Pools ● Large centralized mining pools bring control into the hands of a small number of parties ● 51% attacks ● Double spending: Etherium Classic, Vertcoin, Monacoin, Bitcoin Gold, etc..) ● “Hashrate marketplaces” ● These transactions are impossible to undo ● (Only a complete fork can fix it) ● The whole trust model isn’t valid anymore
  10. 10. Apr 2, 2019 End-User OpSec ● Operational security of endpoint devices is difficult - most users can’t handle it ● Cryptocurrency exchanges also aren’t trustworthy
  11. 11. Apr 2, 2019 Privacy Issues ● You're *less* anonymous than with other forms of ledgers/payment ● How do you make blockchain GDPR compliant?
  12. 12. Apr 2, 2019 Crypto/Protocol Issues
  13. 13. What a blockchain is (scientific view) Byzantine Fault tolerant total ordering protocol Also atomic broadcast, virtual synchrony, … agree on an ordered set of transactions (i.e, what happened and in which order) even if some participants are byzantine (corrupted) Good for • Digital Currencies • Distributed State machines • Can also be used as a distributed database, but that’s overkill
  14. 14. The core of it all: Byzantine Agreement Pronunciation:/ˈbizənˌtēn, bəˈzan-, -ˌtīn/  (also byzantine) (of a system or situation) excessively complicated, typically involving a great deal of administrative detail: “Byzantine insurance regulations” characterized by deviousness or underhanded procedure:Byzantine intrigues“he has the most Byzantine mind in politics”
 Term coined by Leslie Lamport (1982), A. C. Koestler (1937), F.M.A. Voltaire ( ca. 1750), Greek Mythology Given n processors P1,P2,…,Pn , which are connected by an asynchronous point-to-point network. All parties have a (binary) input value vi. A protocol solves Byzantine Agreement if the following conditions are satisfied: Validity If all honest processes start with input value x, then the decision value must be x. Agreement If one honest party decides 0, then no honest party decides 1. Termination All honest parties eventually decide.
  15. 15. Life ain’t fair. In all blockchain related trading platforms, there is a possibility of a race attack. Most current implementations make the attack particularly efficient (e.g., through a limited DoS) For small scale systems, this can be resolved(ish) using threshold encryption. Unless you worry about metadata or scale. Annoying Impossibility results (1) “If all honest parties see event A happen before event B , then A should be scheduled before B.” This is impossible in the presence of a single a corrupted participant
  16. 16. Annoying Impossibility results (2) Evil prevails even with inferior numbers. In an asynchronous system, agreement is only possible if less than 1/3 of all participants are corrupt. “When I introduced Byzantine failures, it was meant to model arbitrary but independent failures, not coordinated malicious ones. The assumption that a dedicated attacker is bound by attacking only one third of all parties is ridiculous.” Leslie Lamport, 2001 “Do you have any better argument why not more than 1/3 of the servers get corrupted than your inability to do better ?” My bosses boss, 2000
  17. 17. Annoying Impossibility results (2) It is an illusion that the scale of major blockchains overcomes the 1/3 threshold automatically. Ethereum: One third of all assets (for PoS) is about 100 wallets if everybody else participates. Assuming there are a lot of passive assets, it is even worse Bitcoin: 
 Due to mining pools and rigs, this assumption is long gone. It doesn’t even need malice to cause issues. https://arxiv.org/pdf/ 1810.02466.pdf Malicious attacks are not independent. How many miners have different • Operating Systems • Implementations • Libraries • Legal authorities • Influenceability by countries controlling the lead currency • … ? This was addressed 1978 with resynchronization and 1997 with General Adversary Structures.
  18. 18. Annoying impossibility results (3) Things don’t scale. The communication complexity is quadratic(ish) in the number of participants Reality check: There never where millions of participants, anyhow • The number of parties that run the show is more 100-1000 • That was worrisome on the previous slide, but here it’s helpful Hybrid models at least can handle absentee participants. Re- synchronisation protocols can be qa base for sharding.
  19. 19. Annoying impossibility results (4) We can’t agree. In an asynchronous system, there is always an action the adversary can perform to prevent termination with an agreement, even if she is only allowed to crash one party (FLP85). So we gave the authors an award and have been trying to cheat around it ever since
  20. 20. Cryptography is like taxes: It is possible to cheat, but you’d better really know what you’re doing. * ** * Or at least hire someone who does. ** Also, you’d better have a very good memory.
  21. 21. Cheating the Byzantine Agreement Impossibilities Proof of Work: Terminating is overrated, anyhow • If I never definitively decide, the proof doesn’t apply Proof of Stake (BFT): We never knew how to model timing assumptions on the Internet, but we do it anyhow • No adversary should have that much network control. No one managed to find a good model for what they can do though (and many tried) • DoS, router hacking, Nation states rerouting half the internet, …,… • The more careful the assumption, the bigger the performance loss Proof of Stake (Randomisation): Terminate with probability • The attacker still can always prevent termination. What she needs to do to achieve that is determined at random after her action.
  22. 22. Proof of Work in a nutshell • Take a new, valid, block of transactions and the end of the longest chain you know of • Find a nonce so that the hash of these three elements ends with a lot of zeros • Publish the new block • If, at any point, you see a longer chain, drop everything and use that one
  23. 23. Cheating like Bitcoin does (PoW) No transaction is ever final • In theory, every transaction can be undone is someone finds a longer chain • Decisions are final by policy, not protocol As no one actually decides in a formal way, the impossibility proofs don’t hold. Price to pay: • Performance • Occasionally, one underestimates (Ether Classic) • Code is not law; policy decides when a transaction is valid • If the network partitions, re-synchronization uses the ‘Sucks-to-be-you’ principle • Censorship/race attacks are possible • Fun legal question: Where is the ₿₿₿ during validation ? • Can I make all my Bitcoin disappear during the tax deadline ? Source: www.kraken.com
  24. 24. Cheating like BFT does (Proof of Stake) “If we keep doubling the timeout, eventually we hit something realistic” Even if we’re wrong, the worst thing that can happen is lack of progress. Price to pay: Easy to derail the protocol with a very limited DoS Easy to massively violate fairness (Use a DoS to kick out every leader until it’s me) This even works without participating (Use a DoS to kick out every leader about to make a decision I don’t like) Optimistic phase of PBFT. A leader orders client requests; the rest of the protocol prevents it from creating an inconsistent order. If it tries, or omits requests, the replicas complain and chose a new leader. This is where it gets complicated.
  25. 25. Cheating with Randomization (Proof of Stake) Terminate with probability 1 Adversary can stall the protocol forever in theory, but not very long in reality Completely asynchronous *, adapts to real network speed Price: We need a good source of common randomness, which is hard to do at scale. * Apart from implementation requirements, such as TCP/IP
  26. 26. Quantum Computing vs Blockchains • PoW will get faster (for some) • Can test n hashes in time √n • It will get faster for everybody, so that’s ok • Everybody with a quantum computer, that is. This might cause trouble in the transition and push for institutional mining • Hash collisions of older transactions might be an issue • It might be possible to replace an old transaction in the chain • Digital Signatures are in trouble • If that’s not fixed, we have a bigger problem • It needs an active transition of all keys to a quantum safe setting • All our Privacy tools need to be revisited • Might be able to de-anonymize old transactions
  27. 27. Apr 2, 2019 What Blockchain IS Good For ● Trustworthy agreement on an order of events ● Modest applications: validating certificates in web browsers ● The high-level concept of decentralized contracts is powerful - separate from the crypto implementation ● (M)any services where one trusted entity is to be replaced by many semi trusted (with care)
  28. 28. Apr 2, 2019 Future Work ● Blockchains w/ updatable application SW ● Privacy preserving blockchain ● Quantum resistance ● Scale up (sharding, partial synchrony, property based) ● Robustness, esp. against timing attacks (mix randomized and timed approach) ● Throughput
  29. 29. Apr 2, 2019 melanie@radical.sexy Questions?

×