martes, 27 de diciembre de 2011

Dan Kaminsky se la toma con bitcoin pero vuelve a sus orígenes


Dan Kaminsky se la toma con bitcoin pero vuelve a sus orígenes.
En una charla apasionante, como todas las suyas, este año Dan ha empezado metiéndose levemente con bitcoin (a fin de cuentas, 2011 ha sido el año de la madurez de Bitcoin, y eso se ve reflejado en las diferentes charlas al respecto – más información en la descripción de la charla de Bitcoin).
La tesis de Dan es apasionante: Bitcoin tiene bugs, pero son de diseño, no de ejecución. De hecho, confiesa que Bitcoin ha sido revisado a fondo por un experto en seguridad, porque después de mirarlo por arriba y por abajo, no ha encontrado (y sus colegas tampoco) ninguna vulnerabilidad de seguridad.
Si no fuese, por supuesto, por dos pequeñas elecciones de diseño: que no escala y no es anónima. El que no escala es conocido, porque todos los nodos de bitcoin se supone que tienen que almacenar todas las transacciones del mundo realizadas desde su creación en 2009, ¡Para siempre! Dan calcula que para que los nodos procesasen, p.e., el mismo número de transacciones que VISA, tendrían que usar 3 TB cada 21 días, tener un ancho de banda de 8 Gb/s y 50 núcleos de CPU.
Es decir, que habría que pasar a un modelo centralizado con supernodos, que serían muy parecidos a los que usan ahora los bancos… aunque claro, no serían realmente bancos y no queda muy claro de qué se financiarían.
Como anécdota graciosa de la conferencia, ha contado cómo han incluido (por el módico precio de 1 BTC, que se ha perdido para siempre) un homenaje ascii a su fallecido amigo Len, que ahora está incluido en todos los clientes bitcoin y se puede ver con el comando (a estas alturas no han faltado imitadores con todo tipo de comentarios, incluso un rickrolling).
Y respecto a no ser anónimos, además de los métodos triviales en los cuales las personas se ven asociadas a sus direcciones IP en los “bitgrifos”, el muestra un método más ocurrente, de fuerza bruta: si un nodo se conecta a todos los demás nodos a la vez, el primero que indique una determinada transacción, es el autor de esa transacción. ¿Difícil? No tanto, puesto que por ahora “sólo” hay que conectarse a 30k nodos, y la propia red tiene mecanismos para obtener direcciones de los demás nodos.
Y esto sirve para dar paso al siguiente tema de su charla, UPnP. Para todos aquellos nodos bitcoin que están detrás de firewalls, no sería fácil conectarse a ellos por el NAT, salvo por el hecho de que muchos router tienen el UPnP activado para ser usado tanto dentro de la LAN (donde debería) como desde Internet. Este descubrimiento, confiesa, no es original, aunque todavía dista mucho de estar arregrado.
Algo más o menos parecido sucede con la siguiente vulnerabilidad, que miembros de la audiencia argumentaron que era conocida pero que sin embargo sigue sin arreglarse: la posibilidad de crear conexiones TCP asimétricas, en las que no se reciben los paquetes de vuelta porque van con direcciones IP de origen falsas (“IP spoofing”). Y no está arreglado porque la solución que se encontró en su momento asumía que “harían falta millones de paquetes para acertar aleatoriamente una conexión”, y hoy con conexiones de fibra de 10 y 100 Mb/s, son escasamente de uno a diez minutos.
La conexión con su siguiente tema no ha sido tan fluida como la anterior, pero haciendo similaridades con los syn cookies, y aunque sigue insistiendo que “los password son malos”, propone un nuevo enfoque para su uso: el cliente utiliza un password, del que genera un par de claves público/privado, y le proporciona al servidor sólo la clave pública. De ese modo, si algún servidor pierde tus claves, no se pueden usar en otro sitio. Todo esto lo hace a base de una librería llamada Phidelius, una herramienta que intercepta el uso de las fuentes habituales de entropía de modo que un determinado password siempre de origen al mismo par de clave pública / privada. Eso sí, para estar totalmente seguro habría que encontrar una manera de generar una clave pública diferente para cada usuario aunque tengan el mismo password, a base de una semilla que se incluya en la clave pública… un “código mágico” que no llegó a explicar cómo se haría.
La charla terminó explicando su nueva herramienta, N00ter, que permite detectar políticas de no neutralidad de red, a base de comparar el mismo tráfico hacia un servidor final cuando pasa por un determinado proveedor de Internet en claro (y por tanto puede ser manipulado por la política de ese proveedor) y cuando pasa cifrado. La herramienta está por ahora limitada a dos escenarios parciales: uno en la que el proveedor nunca ve el tráfico ascendente y se comparan los casos de cifrar o no el tráfico descendente y otra en la que el proveedor siempre ve el tráfico descendente pero ve o no el tráfico ascendente.
 La solución mejor aún no la tiene implementada: sería la que es compara el flujo cifrado con un flujo que no pareciendo cifrado al proveedor sigue pasando por N00ter en los dos sentidos. Aquí la cuestión es que para que el proveedor vea el tráfico no cifrado ascendente, lo tiene que ver también el servidor, y el servidor al ver el tráfico asimétrico puede tirar la conexión.
 Así se tiene un tráfico en abierto hacia el servidor que en realidad se descarta y es sólo para desencadenar la política y un tráfico cifrado ascendente que el proveedor no ve, y que es usado por N00ter para recibir y reenviar el tráfico en abierto descendente y asegurarse que pasa por el mismo camino que el cifrado. El proveedor ve los dos tráficos, y por tanto si lo necesita aplicará la política, mientras que N00ter garantiza que el tráfico de verdad sigue el mismo camino que cuando está cifrado. No es totalmente perfecto, pero es a lo que se puede llegar.
Y tras volver a sus raíces explotando el tráfico TCP/IP de siempre, Dan nos dejó para ir trabajando en los ataques del próximo año, no sin antes recomendar la charla de las claves soberanas.

No hay comentarios:

Publicar un comentario