El blog de Félix Brezo

Encontrando conversación sobre servicios de inteligencia y seguridad informática…

En ocasiones se habla de software open source (código abierto) y software libre indistintamente. Sin embargo, pese a que en ambos tipos de proyectos se cuenta con acceso al código fuente, las implicaciones de muchas de las licencias bajo las que se distribuyen los primeros terminan sacrificando el acceso público en pos de reservarse el derecho de poder cerrar el código. En este sentido, es cierto que los que usamos lenguajes interpretados como Python o Perl tenemos otra ventaja: se trata de lenguajes interpretados en los que el código es accesible y puede ser estudiado por el usuario final para adecuarlo a sus necesidades.

Lo cierto es que existen licencias puras que, para proteger la libertad de estudiar, analizar, mejorar y distribuir las aplicaciones derivadas, exigen que todas las obras derivadas de esta sean distribuidas con la misma licencia. De este modo, un proyecto con licencia GPLv3 nunca podrá pasar a tener otro tipo de licencia y siempre tendrá que ser distribuido su código fuente junto con los binarios que lo componen, lo que garantizará que, si un tercero nos «copia» la idea e incluso la mejora, todos nosotros tendremos acceso a dichas mejoras y las podremos incorporar en nuestro propio código.

[Large GPLv3 logo]

La utilización de una licencia tan restrictiva como GPLv3 es un medio para la solución de un problema ideológico de base: contemplar el derecho de los usuarios a tener acceso al código que ejecutan en sus máquinas para estudiarlo si lo consideran, mejorarlo si son capaces y distribuirlo en la forma que crean conveniente y a su discreción.

Es aquí donde licencias como Apache, MIT o BSD se muestran demasiado flexibles. ¿Por qué? Porque, entre otras cosas, algunas de estas licencias no son tan rigurosas como la GPL a la hora de exigir que se distribuya el código fuente junto con las obras derivadas y mantener la publicidad de las obras derivadas. Esta flexibilidad es la que permite que terceros hagan uso de librerías escritas por comunidades de programadores con la ventaja de que, encima, pueden cerrar a discreción sus proyectos.

Pero entonces, ¿por qué no es una ventaja esta flexibilidad si nos permite basarnos en el trabajo de otros para desarrollar nuestras propias aplicaciones y distribuirlas por nuestra cuenta? No es cuestión de que sea mejor o peor para las empresas usar estas licencias. De hecho, muchas estarán encantadas de ahorrar costes de programación con la ventaja de que pueden cerrar su desarrollo sin la obligación de hacer públicos sus avances. Estamos abordando un problema de carácter puramente ideológico que requiere que sea atendido desde otro prisma: los programadores que desarrollan software distribuido bajo estas licencias menos restrictivas se conforman con explotar las (innumerables) ventajas de los desarrollos colaborativos contemplando la posibilidad de que la comunidad de la que ellos se beneficiaron, no pueda hacerlo a posteriori y, como consecuencia, permaneciendo ajenos a las implicaciones que tiene para el usuario la pérdida de la libertad de poder estudiar siquiera qué está haciendo en realidad su máquina cuando ejecuta un programa. Es ahí donde, para mí, la GPLv3 gana la partida.

Bookmark and Share

Que los partidos políticos se emborrachen hablando de software libre es un fenómeno (va una frase hecha) que no es ni nuevo ni tampoco necesariamente reciente. Encontramos ejemplos rápidamente en el PP, en el PSOE, en IU o en el PNV con búsquedas del tipo:

(site:pp.es OR site:psoe.es OR site:izquierda-unida.es) “software libre”

Por cierto, notable mayor presencia de menciones en algunos partidos con respecto a otros, lo cual dice mucho de cómo se han tomado algunos este tipo de iniciativas habiendo tenido en su mano la posibilidad de motivarlas y aún menos de los que ni tan siquiera las recogen en sus programas. Pero allá cada cual con lo que vota.

La cuestión: el programa de Renta2013 es para Windows

La cuestión es que los vizcaínos que tenemos que hacer la declaración de la Renta en Bizkaia nos enfrentamos a algunos problemas si no utilizamos sistemas Windows. Adjunto los detalles que la Diputación Foral de Bizkaia (con mayoría del PNV, aquí hay para todos) nos facilita en su web:

Programa

  • Versión: 1.0
  • Fecha: 14/04/2014
  • Instalación: 78,52 MB
  • Descarga Única: Renta13.exe (14,49 MB)

Requisitos Mínimos

  • Pc o compatible Pentium III 950 MHz o superior.
  • Espacio disponible en el disco duro de al menos 100 MB.
  • Memoria RAM 512 MB.
  • Entorno gráfico Windows 2000.
  • Impresora láser o de inyección.

Entorno gráfico Windows 2000… Bueno, bueno… No hay que perderse tampoco las instrucciones de descarga. Pido que el lector preste una especial atención al algoritmo de verificación de integridad del fichero Renta2013.exe. No es una broma.

Descarga

  • Descargue en un directorio nuevo y vacío el fichero.
  • Descomprima el fichero descargado. Para ello, desde el explorador de Windows pulsar dos veces sobre el fichero Renta13.exe.

Importante: compruebe que el tamaño del fichero .exe una vez descargado coincide con el indicado en esta página, en caso contrario proceda a descargar de nuevo el fichero.

La instalación es sencilla:

Instalación

  • Cierre todos los programas activos.
  • Desde el explorador de Windows pulsar dos veces en el fichero “Instalar.exe” dentro del directorio donde se ha efectuado la descompresión.
  • Pulsar en Aceptar.
  • El programa se instala por defecto en C:\BFA\Renta\2013.

Y por supuesto, si has tenido problemas, siempre puedes reiniciar el equipo, verificar que los cables están conectados y probar a arrancar en modo a prueba de fallos en Windows 2000, XP o Vista. Con Windows 7 o Windows 8 ya debe ser un jaleo del copón.

Problemas de Instalación

Si al intentar arrancar el programa de instalación aparece un mensaje indicando que el mismo ha entrado en conflicto con otras aplicaciones, reinicie el equipo e inténtelo de nuevo. De persistir el problema ejecute la reinicialización a prueba de fallos (o modo Seguro en Windows 2000), pulsando F8 en Windows 2000, XP o Vista cuando se está reiniciando el equipo y vuelva a intentar la instalación.

Salir del paso arrancándolo en Linux

Instalar el troglodítico programa de la Renta en un entorno Linux es tan fácil como ejecutarlo con Wine y seguir las instrucciones de instalación:

wine Renta2013.exe

Después bastará también con seguir los pasos estándar del manual para Windows y, si tienes todo bien configurado, imprimir el documento final. Otro cantar es si estás redactando el borrador en un equipo que no es el equipo en el que lo quieres imprimir, ya que, si quieres exportar  el fichero (Declaración –> Exportar), la aplicación te creará un fichero renta13_df_XXXXXXXX.idf en una ruta de Windows. Para acceder a este fichero dentro de Wine desde el resto del equipo es necesario acceder a la carpeta /home/<usuario_del_sistema>/.wine/drive_c/<ruta_virtual_hasta_el_fichero> o /home/<usuario_del_sistema>/.wine/dosdevices/c:/<ruta_virtual_hasta_el_fichero>.

En cualquier caso, esta tarea no es en absoluto trivial y, además de estar muy lejos de ser documentada, choca con las buenas intenciones programáticas de los partidos políticos.

Soluciones

Para solucionar esta problemática es necesario:

  1. En el corto plazo (inmediato), documentar el proceso para todas las plataformas de modo que cualquier ciudadano cualquiera que sea la plataforma que utilice pueda hacerlo.
  2. En el medio plazo, desarrollar una aplicación que permita una gestión telemática multiplataforma, preferiblemente a través del navegador como ya se hace en otras latitudes.

Como el criticar por criticar algún día se tiene que acabar, he procedido a remitir el contenido de esta entrada a la Diputación Foral de Bizkaia. En cualquier caso, quién sabe si el camino en el largo (larguísimo) plazo, pasa por integrar completamente el sistema monetario en los organismos recaudadores como ya están de iure, automatizando la inclusión de todas las transacciones y suprimiendo definitivamente el (¿para entonces obsoleto?) dinero en efectivo.

Un saludo y a pagar con gusto señores, que la atención asistencial, la sanidad pública, la educación, las fuerzas de seguridad, los inspectores de Hacienda, los jueces y las carreteras, farolas y aceras no ven crecer el dinero de los árboles.

Bookmark and Share

Gracias

No comments

Bilbao, 7 de febrero de 2014

«Mucha gente piensa que una tesis es la obra de una vida. Recuerdo ahora unas palabras de un profesor del programa de doctorado de la Universidad de Deusto, Mario Piattini, quien, quizás para descargar algo de responsabilidad, nos definía allá por el mes de noviembre de 2012 cómo teníamos que afrontar nuestra tesis doctoral: “Vuestra tesis no es la obra de vuestras vidas, si no la primera obra del resto de vuestras vidas”. Sea como fuere y sea lo que fuere, el proceso se ha visto culminado y aquí estamos redactando unos agradecimientos que se tienen que remontar mucho antes siquiera de la concepción del primer boceto de documento de lo que es el documento que hoy tienes (y perdóname el tuteo anónimo lector) entre manos.

No puedo negar que sería poco coherente que la historia de los agradecimientos de esta tesis empezara con la elaboración del manuscrito final. La historia ha de remontarse algún tiempo atrás, a algún lugar de la Facultad de Ingeniería (entonces aún oficialmente ESIDE) allá por el año 2009. Uno, que entonces era más joven y (aún más) inexperto, de salto en salto por los despachos de la facultad terminaba en el S3lab. Un laboratorio amplio, con un graffiti al fondo (peculiar historia la de la pintada) que lo llenaba de carácter y con unos también más jóvenes ayudantes de investigación. Recuerdo pronunciar unas primeras palabras dubitativas: “Buenas tardes… ¿Dónde puedo encontrar a Pablo?”. Un sonriente y aún desconocido Borja Sanz me señalaba un despacho de tono pistacho que me había pasado a mano derecha. Primera torpeza.

Recuerdo la conversación con Pablo como si hubiera sido hace nada y recuerdo haberle contado con ganas por qué quería hacer seguridad informática. No sé si le habré convencido aún de lo en serio que me tomé aquella conversación, pero el caso es que Pablo se prestó a darme una oportunidad que no me podía permitir el lujo de desaprovechar. Era el comienzo de la aventura. A partir de ahí, todo se sucedió con bastante rapidez. Me presentaron a un tal Igor Santos del que me avisó (también Borja) del que tendría que tener cuidado: tenía unas ideas extrañas que terminaba sacando… Vaya que sí. Lo que sé y lo que aprendí trabajando a su lado, es lo que me ha permitido llegar hasta donde estoy. Aprendí el método, aprendí a pegarme con cantidades ingentes de datos, aprendí a ser riguroso en la redacción y en la corrección de papers, aprendí a presentarlos (con más o menos éxito al principio, pero aprendí), aprendí lo duro que es tener que repetir los experimentos porque se te han escapado pequeños detalles en la construcción de representaciones… Hay pocas palabras que puedan expresar lo que, gratuitamente y quizás sin darse cuenta, me ayudó a crecer en estos años.

Son muchas las personas con las que he tenido el placer de compartir laboratorio. Mencionados Pablo, Borja e Igor, no me puedo olvidar de José (aunque para mí será siempre Sete). Con él he desarrollado gran parte de los últimos trabajos que han dado pie a esta tesis doctoral. Pero si me quedara solo con eso estaría dejando de lado lo más importante de todos esos ratos de cacharreo, horas de botnets para BRIANA (el TFM que compartimos en el Máster de Seguridad) y más horas aún de análisis de tráfico y revisión de papers y artículos. Esas cosas unen lo que unen.

Me quiero acordar también de Jorge. Además de un gran socio del Athletic y de ser un mediocre jugador de squash (aunque, desde luego, mejor que yo), me ha ayudado a darle un último empujón a esta tesis. Nos quedan proyectos por ahí pendientes.

No puedo dejar de acordarme también del resto de compañeros: de Juan y los partidos de pádel, de Javi y esos momentos compartidos programando bots en C a la carrera o escuchando grupos que jamás se me habría ocurrido poner a mí, de Iker y de su apoyo con la documentación y experimentos, de Carlos y los piques con su Baskonia (sé que eras tú el de los hackeos), de Mikel y las conversaciones sobre interfaces de usuario, de Patxi y su intercambio de links por las redes sociales, de los comentarios a la investigación del tío con más talento que conozco, Xabi Ugarte, de Xabi Cantero y su manejo indescriptible de las hojas de cálculo, Linux y Dvorak (buena herencia, Xabi), de Sendoa y una licencia de radioaficionado, de Aitor y su bielsismo, de Agustín y esos debates sobre el estado del mundo… Ha sido mucha gente la que me ha apoyado y con la que me he encontrado a gusto durante muchos años en esta época universitaria… Pero también desde fuera. Es el momento de acordarme de mis padres y mi hermana que han apoyado cada idea que he tenido en estos 26 años, por loca, idealista o retorcida que pareciera. Me enseñaron a ser curioso, a cuestionarme las cosas y a tratar de ser lo más noble posible. Las palabras que de vez en cuando me repito delante del espejo tratan de recoger esa filosofía: “Nobleza. Discreción. Esfuerzo.”. No dudéis de que lo seguiré a rajatabla…

Recuerdo también que, por una casualidad de esas que tiene la vida (mi hermana Olga lo saber mejor que nadie), terminé haciendo un Máster de Análisis de Inteligencia. Y ahí Yaiza fue un descubrimiento postrero. Es de esas personas con las que da gusto pensar, hablar, trabajar y mejorar porque compartes con ellas inquietudes y pensamientos sin a veces siquiera llegar a expresarlos: conexión N-to-N. Casualidad o destino, me considero muy afortunado.

En ese listado de personas que a uno le quedan para siempre después de tanto tiempo hay unas cuantas a las que debo una o varias disculpas por no haber conseguido sacar tiempo para ellas. Desde Nacho o Tomás, hasta Miquel, José María, Dani, Marta, Beñat, Jon, Diego o Imanol. Todos ellos han tenido que soportar fines de semana en los que uno se encuentra desganado y los pone a la cola de sus tareas a sabiendas de que hay que cuidar las amistades, y más aún, las mejores. Seguro que me dejo alguno importante pero, como ya dijo alguien por ahí: “Son todos los que están, aunque no están todos los que son”.

Amigos… Este es mi techo en cuanto a formación universitaria. Con aciertos pero también con muchos errores de los que tocaba aprender. Para mí es la culminación de un ciclo desde el que comienzo una etapa nueva de mi vida que no queda en este documento, si no que llevaré conmigo allá donde termine. Muchas gracias. De veras.»

Dr. Félix Brezo

Bookmark and Share

This content is password protected. To view it please enter your password below:

Bookmark and Share

Por si alguien lo anda buscando, os dejo un snippet de código en Python para visualizar una sencilla (pero ligeramente personalizable) barra de progreso en la consola. Como veis, es una clase muy simplona pero que ayuda a clarificar el estado de laaargos procesos por lotes.  Feel free to add new features! 

Bookmark and Share

Sábado, 18 de mayo de 2013. 01am aproximadamente. El Atlético de Madrid se acaba de proclamar campeón de Copa en la prórroga mientras, en Bilbao, los operarios (y con el soporte de la policía municipal) se afanan por terminar de habilitar las nuevas entradas a Bilbao a través de Zunzunegui tras haber cerrado tres horas antes el acceso de Sabino Arana.
Es aproximadamente a esa hora cuando se puede ver a una persona que desde el centro de la calle maneja un helicóptero que revela su presencia por medio de luces de color verde y rojo. Os dejo un vídeo de dos minutos y juzgáis.



Añado que, en el momento de grabar el vídeo aún no tengo la certeza de si es alguien relacionado con las obras a pesar de que controla el aparato sin recibir ningún reproche por parte de los presentes. De todas formas, con posterioridad se puede ver hablando a esta persona (que no lleva chaleco) con al menos una pareja de policías municipales y otros trabajadores que supervisaban las obras.

PD: quedo a la espera de la respuesta a una consulta por parte del Ayto. de Bilbao de si forma parte del despliegue. Mera curiosidad.

Bookmark and Share

En una de las primeras búsquedas que puede hacer un usuario novel sobre Bitcoin dará con el término criptoanarquismo. La peculiaridad del término y un malentendido romanticismo antiestatal (me cuesta no ver en la situación económica actual un catalizador) se convierten en el disfraz perfecto para una moneda de filosofía estrictamente anarcocapitalista que pregona la libertad de un mercado desprotegido y extremadamente sensible. La permeabilidad de las filtraciones, la diferencia de información que existe entre quienes toman parte en esta economía en auge hace menos por defender el libre mercado de lo que podría parecer a priori.

No hay que perder de vista que aquellas grandes fortunas tienen una gran capacidad para influir en el mercado. Si en un momento dado, personas físicas o jurídicas pusieran a la venta una cantidad de Bitcoins suficientemente grande podrían terminar por disparar a la baja el precio de intercambio ejecutando solamente transacciones legítimas. Una situación más artificial se ponía de manifiesto la semana pasada con la caída fortuita/accidental del principal mercado de intercambio de bitcoins [1]: Mt. Gox. La imposibilidad de cambiar bitcoins disparó a la baja su precio de intercambio.

La pregunta es: ¿existen motivaciones para haber podido provocar todo esto? La respuesta con la que se tiene que quedar el lector es un rotundo sí. De hecho, podemos contemplar dos posibles escenarios que podrían poner en jaque la estabilidad del sistema:

  1. Por un lado, una caída programada pero no notificada de la disponibilidad del servicio. La monitorización del tráfico que generen estos sitios y la estimación de la capacidad de los servidores que lo gestionan es información a considerar para estimar su capacidad de respuesta, pero no es menos cierto que aquellos que lo controlan tienen un poder mucho mayor del que parecen tener simples intermediarios.
  2. Por otro, la provocación intencionada de la caída del sistema mediante, por ejemplo, ataques de denegación de servicio que terminaran por bloquear la plataforma.

La realidad nos han puesto sobre aviso acerca de cuál podría ser el resultado. Bien por un motivo o bien por otro, individuos que conocieran de antemano la caída de estas plataformas podrían hacer un negocio sencillo pero tremendamente efectivo: vender Bitcoins en la cresta de la ola antes de la caída y volver a comprar a toda costa tan pronto como toque fondo su valor. ¿Es descartable? Es una posibilidad real que (intencionada o fortuitamente) esta misma semana pasada pudo tener lugar cuando el Bitcoin tocó techo a $237 y que, tras la caída de MTGox, cayó hasta los $83, pasando en apenas unas horas a estar valorado en una tercera parte del precio anterior como se ve en la figura.

Fuente: Blockchain.info

Así, la provocación de futuras caídas de los principales mercados de intercambio mediante ataques de denegación de servicio para generar una histeria de venta que lance a la baja el precio del Bitcoin es una posibilidad a considerar. Más aún, si tenemos en cuenta que el alquiler de redes de ordenadores zombies o botnets para la ejecución de estos ataques no es ni caro ni complejo [2].

En la cuarta parte, analizaremos hasta qué punto los ciudadanos pueden convertirse en objetivo directo para el robo de carteras y cuáles son las principales herramientas a utilizar para protegerse. Para mañana: Cosas que deberías saber sobre Bitcoin (IV): técnic1as maliciosas que te afectan aunque no sepas de criptodivisas.

Referencias:

[1] MUTTON, Paul (2012). Mt.Gox “victim of own success” as Bitcoins fall in value. [Internet] Netcraft, on 11th April, 2013.  Disponible en: http://kcy.me/inu3 [fecha de consulta: 16 de abril de 2013]

[2] ZAMORANO, Esteban (2012). En Rusia se puede alquilar un ataque DDoS por 10 US$ la hora. [Internet] en FayerWayer a 5 de noviembre de 2012. Disponible en: http://kcy.me/iy3u [fecha de consulta: 16 de abril de 2013]

Bookmark and Share

Como ya hemos dicho, las transacciones de Bitcoin son públicas ya que es precisamente su publicación la única herramienta existente para verificar la propiedad de las monedas.  Como dijimos ayer, existe un concepto, la cadena de bloques, que hace referencia a la totalidad de las transacciones que se han realizado en la historia de Bitcoin. Por este motivo, en el caso de que se pudiera asociar inequívocamente una persona (o una dirección IP) con una cuenta, se podría monitorizar el movimiento de todas las transacciones realizadas a través de ella y, potencialmente, establecer relaciones comerciales.

En este punto, la utilización de herramientas como Tor juegan un papel clave. Tor permite la realización de conexiones y sesiones de navegación a través de una red que oculta el origen de las mismas mediante la creación de unas conexiones. En la práctica, esto implica una capa adicional de anonimato en la navegación y, por tanto, también es aplicable en la ejecución de transacciones. En la actualidad, existen servicios que funcionan como mercados online a través de Tor y que la única moneda que aceptan es el Bitcoin. El anonimato que claman para sí no viene tanto por el uso de Bitcoin como moneda de pago, sino por el hecho de que las conexiones son realizadas a través de este servicio con la ventaja de que no eluden los controles de la legislación internacional en materia de blanqueo de capitales o dinero electrónico a la que se ven sometidas las transacciones tradicionales a través de plataformas como Paypal o Skrill.

Sin embargo, lo habitual es contar con varias cuentas de Bitcoin creadas al efecto. bitcoin-qt, el cliente para Windows con interfaz gráfica más extendido, permite la creación de nuevas cuentas asociadas a un mismo monedero, entendiendo como tal una colección de cuentas de Bitcoin. La utilización de un gran número de cuentas es precisamente la mayor fortaleza a la hora de preservar el anonimato de la red ya que un usuario puede crearse tantas cuentas como crea. Esto es posible porque el número máximo de cuentas de Bitcoin existentes es enorme: 2^160 = 1,461… · 10^48 (o 1 461 000 … y 42 ceros más detrás).

Mientras en el mundo real, los grandes defraudadores han aprovechado históricamente la creación de cuentas asentadas en entidades financieras de los cinco continentes para ocultar ingresos de dudosa de reputación amparados en la complejidad intrínseca de las leyes internacionales, esta nueva realidad ofrece muchas oportunidades al acercar esta posibilidad incluso para los inversores más pequeños. Bitcoin ofrece herramientas para difuminar el rastro dejado por los movimientos monetarios de la misma forma que ocurre en el mundo real: atomizando las transacciones sospechosas en el seno de bosques de transacciones legítimas. Todo ello, con la ventaja de que la complejidad de que crear , bien a golpe de clic, bien programáticamente, miles (o millones de cuentas) de Bitcoin es completamente trivial. Aunque existen investigaciones que intentan dar una respuesta a esta realidad considerando el problema como un problema de redes egocéntricas [1] (el estudio apenas profundizaba en redes de una separación de hasta 3 saltos), lo cierto es que la complejidad de dicho análisis por la cantidad de información manejada y la facilidad con la que se podría introducir más complejidad al sistema podría terminar haciendo baldíos los esfuerzos por escalar el problema.

De cualquier manera, si a estas facilidades técnicas le sumamos las posibilidades que ofrecen los casinos online que funcionan con Bitcoins, los mercados de compra-venta o las plataformas de gestión distribuida de carteras (que emulan el funcionamiento de las entidades bancarias tradicionales con la única garantía de su reputación), tenemos un ecosistema propicio para la realización de transacciones monetarias a nivel internacional fuera de control… Con todo lo que ello implica.

En la tercera parte, ahondaremos en las características de un mercado potencialmente deflacionario y en la facilidad con la que podría manipularse artificialmente la percepción de una moneda especialmente sensible al fenómeno especulativo. Para mañana: Cosas que deberías saber sobre Bitcoin (III): la sensibilidad de un mercado dudosamente libre.

Referencias:

[1] REID, F. and Harrigan, M. (2011). An analysis of anonymity in the bitcoin system, in Privacy, Security, Risk and Trust (PASSAT), 2011 IEEE Third International Conference on and 2011 IEEE Third International Confernece on Social Computing (SocialCom), pp. 1318–1326, IEEE, 2011.

Bookmark and Share

La gran inestabilidad que ha experimentado la divisa virtual por excelencia en los últimos días ha acaparado titulares en una gran cantidad de medios convencionales [1,2]. A lo largo de esta semana, daremos cuenta de las características que hacen de Bitcoin una divisa diferente y dando cuenta de algunos de los mitos más extendidos sobre ella.

El fenómeno especulativo en Bitcoin no es nuevo ni necesariamente reciente. En mayo de 2010 ya presenciamos una burbuja que lanzó el precio del Bitcoin hasta los $35 para luego retraerlo de vuelta hasta poco más de los $2 [3]. La sensibilidad de una moneda cuyo valor queda regido hasta el extremo por la percepción subjetiva de sus usuarios da lugar a un escenario novedoso en el que se presenta un campo idóneo para la especulación.

Pero la concepción de una moneda de carácter distribuido cuyas transacciones estuvieran protegidas por algoritmos de cifrado robustos tiene sus orígenes ya en los noventa [4]. Para resolver el problema de la no reutilización de una misma moneda para varias transacciones al mismo tiempo, se requiere que estas, por protocolo, sean públicas. Y sí: cierto es que asociar estas a una persona en concreto es un problema a tener en cuenta, pero las transacciones son, de por sí, públicas (en http://blockexplorer.com/ se pueden buscar las transacciones por número de cuenta) y no anónimas como algunos pregonan.

Explicar lo que es Bitcoin puede ser complejo para aquel que no esté familiarizado con la criptografía de clave pública, pero son precisamente estos algoritmos de cifrado, que dividen la clave (o el par de claves) en dos pedacitos complementarios (uno privado y otro público), los que hacen posible la magia que sostiene Bitcoin.

En todo caso, intentaremos hacerlo en pocas palabras: cuando efectuamos una transacción desde una cuenta A a una cuenta B, lo que en verdad estamos haciendo es desbloquear la moneda que nos pertenece con la clave privada que se nos ha asignado para dicha cuenta y cifrar la moneda con la clave pública de la cuenta B a la que queremos transferirla. De esta manera, la única persona capaz de aplicar dicha transformación legítimamente será aquella que posea la clave privada complementaria a la clave pública ya generada garantizando que dos personas no se pueden atribuir la misma moneda al unísono. La forma en que se da respuesta a esta peculiaridad es notificando a la red (al resto de usuarios que procesan las transacciones) que hemos intentado efectuar la transacción. Este fenómeno es el que define tres aspectos a tener en cuenta:

  1. La necesidad de estar conectado a la red para efectuar transacciones y verificar la legitimidad de estas (de ahí la definición de esta como una divisa distribuida).
  2. El retardo de entre 5 y 30 minutos que necesariamente introduce esta validación hasta que se producen suficientes confirmaciones de la transaferencia y la irreversibilidad de las transacciones una vez confirmadas.
  3. (Como consecuencia de lo anterior) La necesidad de proteger debidamente las carteras de Bitcoins y las claves privadas autogeneradas.

Este último punto se torna fundamental si se tiene en cuenta que un monedero es en la práctica poco más que un fichero .dat. La no protección de estos con una frase de paso (y digo frase y no palabra de paso) da lugar a que cualquier software o individuo con acceso al equipo pueda copiar, pegar y reclamar para sí la propiedad de la clave privada de los bitcoins de una cuenta y, por tanto, efectuar transferencias impunemente. Así, de igual forma que existe malware que sustrae información bancaria tradicional, existe (y existirá con una frecuencia tanto mayor cuanto mayor sea el éxito de Bitcoin) malware que sustrae carteras de Bitcoin [5].

En la segunda parte, explicaremos por qué está tan extendido que el fenómeno Bitcoin está asociado en transacciones anónimas y veremos por qué si no se toman las precauciones necesarias esto no tiene por qué ser así. Para mañana: Cosas que deberías saber sobre Bitcoin (II): la democratización de las herramientas para el blanqueo de capitales.

Referencias:

[1] MARTÍN, Javier (2013). La fiebre del oro se llama Bitcoin[Internet] En elpais.com, domingo 14 de abril de 2013. Disponible en: http://goo.gl/LSeoL [fecha de consulta: 15 de abril de 2013]

[2] ROCA, Ramón (2013). Bitcoin, el penúltimo juguete de los especuladores[Internet] En Economía Digital, domingo 14 de abril de 2013. Disponible en: http://goo.gl/Tgu8H [fecha de consulta: 15 de abril de 2013]

[3] BREZO, Félix y G. BRINGAS, Pablo (2012). Issues and Risks of Cryptocurrencies such as Bitcoin. In Proceedings of The Second International Conference on Social Eco-Informatics (SOTICS 2012), Venice (Italy), October 21-26, 2012.

[4] BAROK, D. (2011). Bitcoin: censorship–resistant currency and domain system for the people, in Networked Media, Piet Zwart Institute, 2011.

[5] Cyber Intelligence Section and Criminal Intelligence Section, Directorate of Intelligence (2012). Bitcoin Virtual Currency: Unique Features Present Distinct Challenges for Deterring Illicit Activity, in FBI Intellligence Assesment.

Bookmark and Share

Aunque algunos ya estáis de vacaciones, para otros estas fechas son días de recogida de resultados. Y lo cierto es que en el equipo de investigación últimamente estamos teniendo un feedback bastante positivo en lo que a salida de artículos. Pues bien, con tanto trajín se me había pasado dar cuenta de la aceptación en la CISIS 2012 de otro artículo: en este caso el firmado por Igor Santos, Jaime Devesa, Félix Brezo, Javier Nieves y Pablo García Bringas y titulado OPEM: A Static-Dynamic Approach for Machine-learning-based Malware Detection.

El artículo trata sobre la utilización complementaria de técnicas de análisis estático y análisis dinámico para la detección de malware. Básicamente, se trata de un modelo diseñado para combinar, por un lado, las capacidades ya demostradas de los modelos de detección basados en la modelización de ejecutables empleando sus códigos operacionales (u opcodes) como parámetros estáticos y, por otro, el uso de técnicas de análisis dinámico que lanzan en un sandbox o entorno controlado dichas muestras, para monitorizar el comportamiento del ejecutable en tiempo de ejecución.

En principio hoy 15 de julio es la fecha en que se notifica la aceptación de los papers enviados a la CLEI, que este año tendrá lugar en Medellín (Colombia) del 1 al 5 de octubre. En el equipo de investigación estamos a la espera de la notificación del artículo titulado Clasificación supervisada de paquetes procedentes de una botnet HTTP así que a ver si podemos dar otra buena noticia pronto para seguir teniendo motivos para estar satisfechos.

Bookmark and Share