Óscar Delgado | Hacking the blockchain for fun and profit | Codemotion Madrid 2018
0 recomendaciones155 vistas
El documento explora la blockchain desde su concepción, abordando sus vulnerabilidades y ataques, como el ataque del 51% y el minado egoísta. Se discuten las limitaciones en escalabilidad y las comparaciones con sistemas de pago tradicionales, así como soluciones como sharding y canales de estado para mejorar la eficiencia. También se presenta un análisis del uso de blockchain en contextos negativos, como el ransomware y mercados oscuros.
![• Resultado presentado en 2015 por Eyal
[2]
• Esencialmente, un ataque basado en el
minado egoísta aplicado a pools.
• Spoiler: el actual sistema de pools no
forma un equilibrio de Nash:
“Si solo uno de los pools ataca, éste puede
incrementar su beneficio”
Ataques entre pools de minado](https://image.slidesharecdn.com/codemotion2018delgado-190122152348/85/Oscar-Delgado-Hacking-the-blockchain-for-fun-and-profit-Codemotion-Madrid-2018-39-320.jpg)
![Dilema del minero: dilema del prisionero
Fuente: Eyal [2]
La situación es inestable porque
el ataque puede ser anónimo](https://image.slidesharecdn.com/codemotion2018delgado-190122152348/85/Oscar-Delgado-Hacking-the-blockchain-for-fun-and-profit-Codemotion-Madrid-2018-40-320.jpg)
![Posibles contramedidas a la centralización
• Debida al coste energético:
• Memory-hard proof of work: pruebas de trabajo que requieren mucha
memoria RAM, luego los ASICs no dan ventaja adicional.
• Algunas propuestas o sistemas que las usen:
• Ethereum (Ethash).
• Equihash (propuesta académica) [4]
• Debida al control de los desarrolladores core:
• Futarquía: modelo descentralizado de gobernanza [5]
• Propuestas en sistemas relacionados:
• Gobernanza de DAOs.
• Blockchains autorregulables (Tezos) [6]](https://image.slidesharecdn.com/codemotion2018delgado-190122152348/85/Oscar-Delgado-Hacking-the-blockchain-for-fun-and-profit-Codemotion-Madrid-2018-42-320.jpg)
![Referencias
[1] Bitcoin: A Peer-to-Peer Electronic Cash System. Nakamoto. 2008
[2] The Miner’s Dilemma. Ittay Eyal. 2015
[3] A Longitudinal Study of Bitcoin Transaction Fees. Möser and
Böhme. 2015
[4] Equihash: Asymmetric Proof-of-Work Based on
the Generalized Birthday Problem. Biryukov, Khovratovich. 2015
[5] An Introduction to Futarchy. Buterin. 2014
[6] Tezos: A Self-Amending Crypto-Ledger Position Paper. Goodman.
2014](https://image.slidesharecdn.com/codemotion2018delgado-190122152348/85/Oscar-Delgado-Hacking-the-blockchain-for-fun-and-profit-Codemotion-Madrid-2018-81-320.jpg)
Óscar Delgado | Hacking the blockchain for fun and profit | Codemotion Madrid 2018
- 1. Hacking the blockchain for fun and profit Oscar Delgado oscar@immune.institute
- 4. Bitcoin Protocolo Direcciones Cadena de bloques Pruebas de trabajo (PoW) “Registro distribuido e inmutable de datos”
- 5. No autoridad central No fallo, no corrupción, no prohibición = Primer algoritmo de consenso distribuido ¿Qué hace esta idea diferente?
- 6. Blockchains públicas, semi-públicas y privadas Tipo de cadena Permiso Usos Plataformas Lectura Escritura Pública ✓ ✓ Notaría digital, IoT Bitcoin, Ethereum Semi- pública ✓ Certificación cadenas productivas Hyperledger, Quorum (!) ✓ Auditoría Privada Sistema de pagos interbancarios
- 10. Bugs software En general, OK, pero: • CVE-2010-5141, Junio 2010: vulnerabilidad más peligrosa de la historia de Bitcoin, permitía gastar el dinero de otros
- 11. Bugs software • Bloque 74638 (Agosto 2010) contiene una transacción con una salida de 184 billones de BTC: • Interger overflow en el código • Se solucionó con un patch y un fork manual • Se observó un doble gasto de 10.000$
- 12. Bugs software • Un fork en el bloque 225430 (Marzo 2013) debido a un error en la actualización del cliente: • Duró 6 horas • Se solucionó volviendo a una versión anterior del cliente
- 13. 13 Bugs software
- 14. Bugs software • Mucha gente auditando el código con interés económico (el mejor incentivo) • Poco probable que existan grandes bugs, pero sí ataques DoS
- 16. Junio 2014 51%
- 17. ¿Sistema descentralizado? ¿De verdad? Peter Wuille Gavin Andresen Wladimir J. van der Laan Cory Fields Matt Corallo
- 19. Seguridad termodinámica • El problema del doble gasto puede ser visto como un problema termodinámico: reescribir la cadena de bloques implica gastar una considerable cantidad de energía. • ¿Cuánta, exactamente?
- 20. Hagamos algunos cálculos Fuente: bitcoin.sipa.be
- 21. Hagamos algunos cálculos Fuente: bitcoin.sipa.be • Necesitaríamos unos 1027 hashes para regenerar la cadena completa • El Bitfury Tardis B9 es actualmente el dispositivo más eficiente del mercado
- 22. Fuente: bitcoin.sipa.be Bitfury Tardis B8 1. Hash Rate: 80 TH/s ± 5% 2. Consumo energético: 6300W 3. Eficiencia energética: 0.07875 J/GH Coste por GH/s $ 0.1500
- 23. Hagamos algunos cálculos Fuente: bitcoin.sipa.be 1027 hashes · 0,07875 J / 109 hashes = 7,7875 · 1016 J 7,7875 · 1016 J = 2.777.777.778 kWh · 0,05$/kWh = 1000 M € 1 J 2,777777778 · 10-7 kWh
- 24. 24
- 25. Coste producción 𝐶 𝐵𝑇𝐶 = 𝑇𝑏𝑙𝑜𝑐𝑘 𝑃𝐾 𝑅 ≈ 𝐷232 𝑃𝐾 𝑅𝐻𝑟 = 𝐷232 𝐾 𝑅𝐸106 D – dificultad K – coste energético (céntimos dólar/kWh) R – recompensa por bloque (12.5 BTC) E – eficiencia del dispositivo de minado (Mhash/J)
- 26. Se ha expulsado a muchos mineros del sistema → ¡más centralización!
- 28. • Presentado en 2013 por Eyal & Sirer de la Universidad de Cornell • Idea: cuando mines un bloque, no lo publiques • Con sólo un 25% del hashrate, la estrategia permite ganar más de lo que correspondería Ataque del minado egoísta
- 29. Ataque del minado egoísta 0 0’ 1 2 n x 1-x g=2 (1-x)z g=1 x 1-x x (1-x)(1-z) g=0 1-x g=2 … x prob. atacante encuentre un bloque z prob. de que se mine en la cadena del atacante (a igual de longitud) g ganancia del atacante (en recompensa por bloque)
- 30. Transición 0 → 1: Atacantes minan un bloque Bloque n-1 Bloque n Bloque n+1 x 1-x Cadena pública Cadena privada 0 0’ 1 2 x 1-x g=2 (1-x)z g=1 x 1-x x (1-x)(1-z) g=0 1-x g=2 1 0
- 31. Transición 1 → 0’ : Red encuentra un bloque Bloque n-1 Bloque n Bloque n+1 Bloque n+1 Bloque n+1 Publica bloque Cadena pública Cadena privada 0 0’ 1 2 x 1-x g=2 (1-x)z g=1 x 1-x x (1-x)(1-z) g=0 1-x g=2 0’ x 1-x
- 32. Transición 0’ → 0 : La cadena pública se recupera Bloque n-1 Bloque n Bloque n+1 Bloque n+1 Bloque n+2 Bloque n+1 Publica bloque Cadena pública Cadena privada Atacantes no ganan nada 0 0’ 1 2 x 1-x g=2 (1-x)z g=1 x 1-x x (1-x)(1-z) g=0 1-x g=2 0
- 33. Transición 0’ → 0 : Ambas partes ganan Bloque n-1 Bloque n Bloque n+1 Bloque n+1 Bloque n+2 Bloque n+1 Publica bloque Cadena pública Cadena privada Atacantes y honestos ganan su bloque 0 0’ 1 2 x 1-x g=2 (1-x)z g=1 x 1-x x (1-x)(1-z) g=0 1-x g=2 0
- 34. Transición 0’ → 0 : Los atacantes ganan Bloque n-1 Bloque n Bloque n+1 Bloque n+1 Bloque n+1 Publica bloque Cadena pública Cadena privada Los atacantes ganan dos bloques Bloque n+2 0 0’ 1 2 x 1-x g=2 (1-x)z g=1 x 1-x x (1-x)(1-z) g=0 1-x g=2 0
- 35. Revisitando el ataque del 51% Fuente: Bitcoin’s Security Model Revisited. Sompolinsky and Zohar Número de confirmaciones %delhashrateglobal
- 36. • Inicialmente el ataque haría la red más lenta y vulnerable al doble gasto • Si ganara adeptos, la ventaja del pool egoísta podría ser definitiva Ataque del minado egoísta
- 37. • ¿Desconocimiento por parte de los mineros? • ¿Demasiado riesgo y/o capital necesario? • ¿Dificultad de beneficiarse del doble gasto? • ¿Honor entre mineros? ¿Por qué no vemos estos ataques?
- 38. 40 ¿Ataco o no ataco?
- 39. • Resultado presentado en 2015 por Eyal [2] • Esencialmente, un ataque basado en el minado egoísta aplicado a pools. • Spoiler: el actual sistema de pools no forma un equilibrio de Nash: “Si solo uno de los pools ataca, éste puede incrementar su beneficio” Ataques entre pools de minado
- 40. Dilema del minero: dilema del prisionero Fuente: Eyal [2] La situación es inestable porque el ataque puede ser anónimo
- 41. Evolución futura de los costes por transacciónBTCencirculación Actualmente, la recompensa por bloque produce más del 99% beneficio de un minero
- 42. Posibles contramedidas a la centralización • Debida al coste energético: • Memory-hard proof of work: pruebas de trabajo que requieren mucha memoria RAM, luego los ASICs no dan ventaja adicional. • Algunas propuestas o sistemas que las usen: • Ethereum (Ethash). • Equihash (propuesta académica) [4] • Debida al control de los desarrolladores core: • Futarquía: modelo descentralizado de gobernanza [5] • Propuestas en sistemas relacionados: • Gobernanza de DAOs. • Blockchains autorregulables (Tezos) [6]
- 43. NO existe un buen modelo formal de la seguridad • La cadena de bloques funciona en la práctica, pero no en teoría • Es muy difícil analizar el impacto de las cuestiones abiertas: • Minado egoísta, ataques entre pools • Evolución futura de las fees • Modelo de gobernanza • Otras pruebas de trabajo
- 45. Las cadenas de bloques no escalan bien BTC ≈ 6 -7 tps ETH ≈ 20 tps PayPal ≈ 450 tps VISA ≈ 56000 tps
- 46. Evolución del tamaño de bloque (BTC)
- 47. El principal problema es que todas las transacciones tienen que ser procesadas por todos los nodos Fuente: https://docs.switzernet.com/people/emin-gabrielyan/060724-netcod-flooding/
- 48. ¿Y si cada nodo no tuviera que procesar todas las transacciones? ¿Y si pudiéramos incluir más operaciones sin cambiar la infraestructura base? Soluciones de capa 1 (on-chain) Aumenta la capacidad base de la red Nos llevamos ciertas operaciones fuera de la cadena Soluciones de capa 2 (off-chain) Posibles soluciones Blockchain (Almacenamiento, comunicaciones, consenso) DAPPS (Smart contracts) Capa 2 Capa 1
- 50. El trilema de las cadenas de bloques Descentralización EscalabilidadSeguridad
- 52. Sharding Fuente: Dzone Concepto habitual en bases de datos
- 53. Sharding en Ethereum El estado se divide en subconjuntos, shards Cada cuenta única reside en un shard Cada nodo valida ahora solo las transacciones de su shard Shard 1 Shard 2 Shard 3
- 54. Sharding en Ethereum - Rendimiento En la fase 1, se comenzará con 100 shards, lo que implica una mejora 100x 100 shards → 15 * 100 = 1.500 tps En el futuro, se combinará con Plasma (capa 2, 100x) 10.000x → 15 * 10.000 = 150.000 tps
- 55. Sharding en Ethereum - Retos Es necesitario implementar primero proof-of-stake (PoS) Necesario mecanismo para decidir qué nodo pertenece a qué shard, de forma eficiente y segura → protocolo de generación de entropía seguro Comunicación inter-shard
- 57. Soluciones capa 2 Trabajan normalmente off- chain y la utilizan como un “ancla” de confianza Utilizan la cadena principal en caso de discrepancias Se construyen “encima” de la capa 1 como smart contracts
- 58. State channels Abrir un canal, que incluye un mecanismo multi-firma o smart contract Se transacciona fuera de la cadena, utilizando firmas digitales Se cierra el canal enviando un último estado acordado: • Si hay discrepancias, las partes pueden enviar sus últimos estados y el mecanismo decide
- 59. ¡Jugemos! 1. Se crea un Smart contract “Juez” que entienda las reglas y custodia el premio. 2. P1 crea y firma una transacción con un movimiento, que manda a P2. Éste lo firma también y lo devuelve a P1. 3. Ahora P2 genera una nueva transacción con el movimiento 2. 4. Cada transacción tiene un número de serie incremental y son transacciones válidas (podrían mandarse tal cual al contrato)
- 60. ¡Jugemos! 5. Hasta el momento, todos los movimientos han sido off-chain -> no hay coste, rápidez 6. ¡P2 gana el juego! Envía el estado final al contrato 7. El juez verifica que el estado está firmado por ambos jugadores, y espera un periodo de tiempo antes de pagar el premio. 8. ¿Por qué esperar? Porque P1 podría adelantarse y enviar un estado no final. P2 siempre puede demostrar que su estado es posterior (por el número de secuencia)
- 61. State channels - Beneficios Escalabilidad Decenas (centenas) de miles de transacciones por Segundo Reducción de comisiones Reducción drástica de costes, del tamaño y volumen de transacciones Tiempo de confirmación La confirmación instantánea es posible
- 62. State channels - Aplicaciones Micropagos (de verdad) Fuente: slock.it
- 63. State channels - Futuro Existen tecnologías que permitirán incrementos de varios órdenes de magnitud en la capacidad de proceso
- 64. Las cadenas de bloques no escalan actualmente, ¡pero lo harán!
- 66. Blockchain for evil!! Darkleaks Peter Todd (2014) Marketplace “seguro” para la compra/venta de información · Basado en Bitcoin · Sin operador central · Sin identidad · Sin interacción con el filtrador
- 67. Darkleaks Hollywood movies Trade secrets Government secrets Proprietary source code Industrial designs like medicine or defence Zero day exploits Stolen databases Proof of tax evasion Military intelligence Celebrity sex pictures Corruption
- 68. Blockchain-based ransomware Esquema típico ransomware • Las víctimas no tienen garantías de recuperar las claves de descifrado • ¿Y si un atacante utiliza un smart-contract para dársela?
- 69. Blockchain-based ransomware Intercambio de bienes • ¿Hay una forma de vender un bien de forma que ninguna de las partes pueda engañar a la otra? • Este problema no tiene solución sin el uso de una TTP
- 70. Blockchain-based ransomware Zero Knowledge Contingent Payment (ZKCP) • Demostrado en vivo por primera vez en 2015 para intercambiar la solución (válida) de un sudoku por 0.1 BTC Vendedor Comprador 1. enck(s) = c 2. SHA256(k) = y 3. ZKP(s,c) 4. Verifica ZKP 5. Genera transacción que libera el pago si Vendedor proporciona k válido 6. Libera k 7. Descifra c y obtiene s
- 71. Blockchain-based ransomware ¿Puede aplicarse esto a un esquema ransomware? • No directamente. No se puede codificar un programa (ni ZKP) que pueda determinar si un fichero pertenece semánticamente a un usuario. • Una fotografía de tu abuelita podría haber sido sustituida por otra de Bob Esponja
- 72. Blockchain-based ransomware Nuevos esquemas Pay- and- pray Sin garantías especiales Pay- per- decrypt Víctima puede pagar por ficheros individuales Proof- of-life Garantía (débil) de devolución
- 73. Blockchain-based ransomware Ventajas para víctimas y atacantes Víctimas • Garantía de fair- exchange (débil): devolución del pago • Nuevos esquemas (pay- per-decrypt) Atacantes • Resilencia de la infraestructura • Ransomware-as- a-service (!)
- 74. Blockchain-based ransomware Proof-of-life 1. Inicialización Para cada víctima v, el atacante: 1. Genera un identificador aleatorio, idv, y una clave simétrica maestra, mskv
- 75. Blockchain-based ransomware Proof-of-life 2. Infección El malware cifra cada fichero f de la víctima: 1. Genera un identificador aleatorio, idf, y una clave simétrica de cifrado, skf = HMAC(mskv, idv||idf) 2. Genera un commitment c0 = h(mskv), y lo envía al smart-contract 3. Se borra mskv de disco y memoria
- 76. Blockchain-based ransomware Proof-of-life 3. Reto/respuesta Se realiza un procedimiento de “prueba de vida”: 1. El Smart-contract (o la propia) víctima eligen una serie (limitada) de ficheros a ser descifrados gratis. 2. El atacante publica las claves de descifrado correspondientes. 3. La víctima comprueba que los ficheros se descifran correctamente, y paga al smart-contract, enviando su idv
- 77. Blockchain-based ransomware Proof-of-life 4. Revelado de clave maestra 1. El atacante revela mskv al Smart-contract, que comprueba que el conjunto de claves de descifrado anterior se deriva correctamente de ella. Si es así, envía el pago de la víctima al atacante. 2. Si no es así, o transcurre un tiempo determinado sin que las claves sean reveladas, el smart-contract devuelve el dinero a la víctima.
- 78. Blockchain-based ransomware Proof-of-life Smart contract Atacante Víctima 1. init() 2. Infección y cifrado de ficheros 3. Reto al atacante3’. Respuesta del atacante 4. Pago 4. Pago
- 79. El FUTURO
- 81. Referencias [1] Bitcoin: A Peer-to-Peer Electronic Cash System. Nakamoto. 2008 [2] The Miner’s Dilemma. Ittay Eyal. 2015 [3] A Longitudinal Study of Bitcoin Transaction Fees. Möser and Böhme. 2015 [4] Equihash: Asymmetric Proof-of-Work Based on the Generalized Birthday Problem. Biryukov, Khovratovich. 2015 [5] An Introduction to Futarchy. Buterin. 2014 [6] Tezos: A Self-Amending Crypto-Ledger Position Paper. Goodman. 2014