Sergio Demian Lerner, Crypto and Privacy enthusiast Independent Security Researcher CEO at Founder of

1 Sergio Demian Lerner, Crypto and Privacy enthusiast Ind...
Author: Javier Pinto Ortiz de Zárate
0 downloads 2 Views

1 Sergio Demian Lerner, Crypto and Privacy enthusiast Independent Security Researcher CEO at http://www.Certimix.comhttp://www.Certimix.com Founder of http:/www.Pentatek.com @SDLerner 500K lines of code written in, security applications: 0 vulnerabilities surgical monitoring systems: 0 humans Killed Bitcoin, MavePay and the future of cryptocurrencies Ekoparty 2012

2 Millonario en 365 días...

3 Burbuja especulativa inicial Incremento de 400X

4 Precio y volumen en USD 2.8M USD traded

5 Que es Bitcoin? ● Nueva forma de dinero digital ● No centralizada, peer-to-peer ● No controlada ni controlable por gobiernos ● Deflacionaria por diseño ● Tolerante a fallas de los nodos ● Con pagos tecnicamente irreversibles ● Sin fronteras ● Con bajo costo actual de transferencias

6 Como funciona?

7

8 “Contabilidad” (simplificado) Outpoint no gastado

9 Transacciónes

10 Propagación de transacción

11 Mineria

12 Encadenamiento de bloques

13 Propagación de bloque

14 Juntando todo...

15 Problemas de Bitcoin ● Vulnerabilidad ● Escalabilidad ● Anonimato ● Eficiencia Dan Kaminsky words... BitCoin is absolutely not anonymous BitCoin clearly does not scale–In the long term Looks really bad up front–Scratch the surface,it’sactually surprisingly good

16 Problemas de Bitcoin ● Vulnerabilidad ● Escalabilidad ● Anonimato ● Eficiencia → PPCoin / Proof-of- stake Dan Kaminsky words... BitCoin is absolutely not anonymous BitCoin clearly does not scale–In the long term Looks really bad up front–Scratch the surface,it’sactually surprisingly good Mavepay APPeCoin Avalanche Vuln

17 Vunerabilidades

18 Ataques al ecosistema Bitcoin (usuarios y servicios)

19 Allinvain Theft

20 Bitcoin DoS attacks +3 +1 CPU +1 Bandwidth, CPU, RAM & HD +1 (*) RAM CVE-2012- ? 2012-02 WxBitcoin and bitcoind DoSEasyUlimited orphan txs82% (*) http://bitcoin.stackexchange.com/q uestions/2901/is-there-a-limit-on- the-number-of-orphan- transactions-a-node-can-cache +2 CPU & RAM Avalanche !

21 CVE-2012-? ● Los nodos ofrecen el servicio “gratuito”de almacenar temporariamente las transacciones huerfanas (cuyos previns son desconocidos) ● Este servicio puede ser abusado hasta llenar la RAM, ocasionar transhing y colgando al nodo. ● El patch no arregla el problema y genera una nueva vulnerabilidad! ● Como arreglar mal una vulnerabilidad? Excluir al investigador del workflow de desarrollo de una solución.

22 CVE-2012-? fix: new CPU exhaustion vuln 0.5.3

23 CVE-2012-3789 ● Los nodos ofrecen el servicio “gratuito”de verificación de transacciones. ● El atacante puede abusar del servicio y forzando el uso máximo de CPU.

24 CVE-2012-3789

25 CVE-2012-4683 ● a.k.a. AVANANCHE vulnerability. ● Los nodos ofrecen el servicio “gratuito”de hacer forwarding de mensajes de gran tamaño. ● El atacante puede abusar del servicio y forzar a los nodos a reenviar en forma inmediata mensajes que tienen un costo nulo de creación. ● Un problema semejante había sido detectado antes y fué desestimado por no poder explotarse, y no se le dió solución.

26 Escalabilidad (CPU, Bandwidth, Storage) ● CPU: Cada verificación ECDSA require 3 msec aprox. y cada transacción requiere en promedio 2 verificaciones. Esto da un máximo de 160 tps. ● Storage: Si se destina a Bitcoin un disco de 500 GB y se lo reemplaza cada 2 años se logra almacenar 15 tps. ● Bandwidth: Una conexión de 64 Kbytes/sec permite hasta un máximo de 70 tps. ● A modo de comparación, VISA procesa 2000 tps

27 Soluciones propuestas (Thin Clients) ● Simplified payment verification mode (SPV) ● Unused Output Tree in the Blockchain (UOT) ● Server-Trusting Clients ● → Delegation of trust ● Si la mayoria de los cientes adoptan estas soluciones, se mantienen las propiedades de decentralización, tolerancia y seguridad?

28 Storage ● La práctica muestra que un sistema que almacena cada “billete” no utilizado por separado require 100 veces mas almacenamiento que un sistema que unifica un balance por usuario. ● El anonimato no empeora, es de todas formas inexistente. ● 1528499 unredeemed outputs left ● 15000 active nodes

29 CPU: Firmas digitales para verificación masiva (300 tps) ● Firmas de corta longitud (< 150 bytes) ● Claves públicas de corta longitud (< 150 bytes) ● Tiempo de verificación ultra-rápido o permitir bacth-verification (< 1 msec/verificación) ● Decentralización: no se aceptan soluciones con terceras partes de confianza (TTP) ● Seguridad escalable práctica: costo de ataque prohibitivo (no es necesaria seguridad teórica) para los activos protegidos.

30 No es relevante en Bitcoin/MAVE ● Tiempo de firmado (< 1 segundo) ● Tiempo de creación de la clave privada (< 1 minuto) ● Resitencia a colisiones en la función de hashing para las firmas digitales.

31 Idea Mave/Mavepay ● La firma de una transacción se logra mediante el envío de al menos dos comandos: ● El primer comando (en el instante t) es un commitment del segundo. ● El segundo comando (en el instante t+e) contiene la transacción propiamente dicha y una preimagen x de una cadena de hashs asociada a la cuenta. ● Esto da evidencia que el autor de la transacción conocía x en el instante t. ● Para cuando la red obtiene x, ya es tarde.

32 Problemas con la implementación “naive”de MAVE ● Delay attack: puede el atacante obtener un beneficio de demorar uno o varios comandos? ● O(c 2 ) attack: puede el atacante hacer un ataque DoS al sistema de apareo de compromisos. ● 51% attack: puede el atacante sopesar el costo de adquirir el 51% del poder de computo de la red para obtener una ganacia mayor? El botín aumenta con el número de transacciones → aumenta el riesgo.

33 Solucion: MavePay-W (híbrido) ● 2 comandos: el primero es un commitment. ● El segundo posee: ● Firma Winternitz pequeña (~10 bits) del hash el bloque donde apareció el primer comando. ● Firma Winternitz reducible de 5 bits de una cota superior al exponente del valor transferido (para limitar la posible perdida desde $ 1 hasta $ 4294967296) ● De esta forma puede forzarse a que el costo del ataque sea siempre mayor que el botín.

34 Ejemplo ● Asumpción: cada cuenta adopta un margen de seguridad (p) acorde a la cantidad de dinero que suele transferir. ● Ganancia de mining por bloque: 50 BTC ● Supongamos que deseo transferir no mas de 1000 USD (100 BTC) por transacción. ● Supongamos que el volumen promedio de transferencias de 100 BTC o menos es 10K BTC/bloque ● Aumento la dificultad 1024x con p=10 bits. ● Un atacante super-poderoso con el 100% del hashrate (20 TeraHash/s) podría obtener legalmente 51K BTC (50*1024) en el mismo tiempo en el cual robando podría hacerse de solo un bloque de 10K BTC (y su botín posiblemente se devanecería!)

35 Firmas digitales Winternitz

36

37

38 Mavepay-W

39 Digital signatures for Massive Verification

40 Bitcoin vs. Mavepay-W (*) Se puede lograr haciendo mas complejo el protocolo. (*2) Obtenido extrapolando datos actuales de Bitcoin, sin considerar servicios de e-Wallets. Para MavePay se consideran 4 cuentas por usuario para mantener un grado de anonimato Uso: 1 GB RAM, 64 Kbyte/Sec link, 500 GB HD/4 years

41 Bitcon & Mavepay-W GRACIAS PREGUNTAS?

42 Mavepay: Key chain

43 Mave y la cadena de claves Nextke y N+a bytes N bytes (N ~=10) M bytes N bytes

44 Mave/MavePay commands