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.
Entradas
No hay comentarios:
Publicar un comentario