Hace tiempo nos propusimos la idea de enviar un post a SBD que hablase
de la herramienta de software libre para redes sociales llamada,
AnonTwi.
Sin embargo, pensamos que aún no se encontraba la suficientemente
"aceptable" como para ser presentada así que esperamos un poco más. Tras
varios meses de desarrollo intenso y divertido, pensamos que ha llegado
el momento de tan grato asunto, de hecho, hace poco se ha liberado la
versión 1.0
La herramienta, cuyo desarrollo comenzó a principios de 2012 parte de una necesidad; "Tratar de evitar actos de censura en redes sociales".
Dicha censura proviene, generalmente, de la parte de los propios
proveedores de servicios que, en ocasiones, se ven presionados por algún
gobierno del mundo a retirar contenido o incluso, a facilitar el origen
del mismo. Es decir, el paradero del informante (NWO). Así, cada vez
resultan más evidentes ciertas praxis especulativas en lo que ya se
denomina como el "Mercado de la Información". Aquel por el cual,
grandes corporaciones del mundo de los datos se encuentran en los
puestos más altos en la bolsa del mercado de "valores" global.
Si bien dejar nuestros datos en servicios de terceros no es la mejor
estrategia para su gestión, sea en el presente o en el futuro, si es
verdad que la masificación de ciertas propuestas comerciales (y otras
que no), así como la constante repercusión de su contenido en la
sociedad civil, han puesto en el punto de mira ciertos puntos básicos
relacionados con los Derechos Universales, que debemos de aclarar:
"antes de que sea demasiado tarde". Entre otros, e incluyendo la
censura, están; la privacidad de nuestras conversaciones, localizaciones, nuestro árbol de contactos, nuestros horarios de uso, etc...
Básicamente, debemos asegurar nuestra memoria digital, para en un
futuro no perder el control de ciertos pilares base de la sociedad
informatizada a diversa escala social en la que estaremos viviendo.
Pensamos que, una buena forma de empezar un proyecto que pudiese tratar
de anticiparse a un problema como ese, es partiendo de una base
ideológica y estratégica interesante y caímos en la idea del cifrado
como pieza central. La cultura
CipherPunk
se ha extendido mucho desde sus inicios y cada vez podemos ver más
código libre que nos facilita la implementación de ciertos algoritmos
matemáticos complejos. Y cifrado difícilmente "rompible" con recursos al
alcance de cualquiera. Más adelante, explicaremos que nos llevo a
elegir
AES+HMAC-SHA1 como algoritmos y explicaremos parte de su implementación.
Resumiendo un poco ésta parte, pensamos que la información cifrada
asegura el mensaje, pero también ayuda al mensajero. Y precisamente en
los tiempos que corren, las circunstancias sociales y sus repercusiones a
nivel global, nos exigen cada vez más cuidar a nuestros mensajeros. O
al menos, intentarlo (
Bradley Manning,
Julian Assange) ya que son ejemplos prácticos de lo que nos podría pasar a cualquiera.
Hemos visto actos de censura que se repiten
una y
otra y
otra y
otra
vez. Y pensamos que sino se reacciona pronto, es posible que más
adelante sea complicado hacerlo. Prueba de ello son ciertas conclusiones
que podemos obtener de las diferentes API que el motor puede manejar.
Por ejemplo, la API de Twitter, tiene limitado el número de mensajes a
salvar en el disco, la cantidad de peticiones de líneas, no contempla
las peticiones de amistad y una que nos preocupa más, se reserva el uso
de XAuth a enviarles un correo y explicarles para que lo quieres. Algo
muy
curioso.
AnonTwi utiliza
OAuth2, por tanto, soporta
Identi.ca, es decir
statusnet, así como
Twitter.
Un compañero presentó el siguiente esquema que explica bastante bien el
escenario que recorren nuestros datos si se conectan todas las API
seguidas.
Decir que la
versión 1.0 contiene un
bot de IRC que permite ampliar un poco más la imagen. El esquema sería algo como:
Tor -> IRC -> Anontwi -> Identi.ca -> Twitter -> Facebook
¿Por qué nos parece importante resaltarlo?. Por temas de evasión de tracking de orígenes.
Es decir, AnonTwi es una herramienta que permite cifrar nuestros mensajes públicos y privados en ciertas redes sociales, así como, evitar que se pueda saber la IP de origen que los envía (entre otros trucos más)
Se encuentra desarrollada en Python y utiliza una licencia GPLv3. Ello
nos permite, no solamente utilizarla en diferentes plataformas (*Unix,
Win32, OSX...) sino que podemos revisar el
código
para investigar o mejorar su funcionamiento. Otro punto importante, ya
que hablamos de cifrado, es que una de las estrategias a seguir
precisamente, es la
transparencia. Si, si, parece una paradoja,
pero es la mejor forma para que los algoritmos de cifrado sean robustos y
actuales, el método de compartir. ;-)
En un principio se optó por utilizar
AES128 y
Blowfish.
La combinación partía de la base de generar un código que nos
permitiera enviar mensajes cifrados, con un mínimo de robustez, de unos
140 caracteres de máximo. Es decir, buscar la forma de
acotar al máximo el rendimiento entre:
calidad del cifrado y cantidad de caracteres permitidos.
Por si queréis la respuesta ya, actualmente podemos enviar 69
caracteres en texto plano en bloques de 140 cifrados. Como comentamos,
los algoritmos de las versiones más arcaicas se modificaron por otros.
Concretamente usamos
AES256 y
HMAC-SHA1 como método para generar bloques.
 |
| AES Sub-bytes mode |
 |
| SHA-1 HMAC Generation |
Otro punto importante se encuentra en la generación de las llaves
que intercambiaran los usuarios. Recordamos que al tratarse de cifrado
simétrico, la longitud de la clave, influye en la robustez del cifrado.
Aquí surgió un debate, ya que el usuario puede optar por usar claves del
tipo: 1234, qwerty, etc. Al final se ha optado por integrar la generación de claves con un mínimo de longitud de 32 en el proceso de cifrado, como algo obligatorio.
También, se trata de avisar del mismo modo al portador de la clave, de
que el proceso de compartirla es vital para la seguridad de la
información a la que da acceso.
Se lanza el siguiente mensaje:
% ./anontwi --gen
PIN key: 4iGn5BaSDhyfWlHZrKO870l3Fpaw2eITlKG+EABDQ4Y=
Share this key privately with the recipients of your encrypted messages.
Don't send this key over insecure channels such as email, SMS, IM or
Twitter.
Use the sneakernet ;-)
La longitud de la clave que se genera de forma aleatoria es de 44 caracteres.
# Constants for AES256 and HMAC-SHA1
KEY_SIZE = 32
BLOCK_SIZE = 16
MAC_SIZE = 20
Partimos de la base de utilizar claves de como mínimo 32 caracteres, con
un tamaño de bloques de 16 bajo HMAC-SHA1. Aquí vemos como se genera el
pad partiendo de una llave con SHA1.
trans_5C = "".join([chr (x ^ 0x5c) for x in xrange(256)])
trans_36 = "".join([chr (x ^ 0x36) for x in xrange(256)])
def hmac_sha1(key, msg):
if len(key) > 20:
key = sha1(key).digest()
key += chr(0) * (20 - len(key))
o_key_pad = key.translate(trans_5C)
i_key_pad = key.translate(trans_36)
return sha1(o_key_pad + sha1(i_key_pad + msg).digest()).digest()
Las llaves se generan de forma sencilla:
def generate_key():
return b64encode(urandom(KEY_SIZE))
El init de la clase de cifrado, nos muestra además el modo a utilizar. En concreto se utiliza: AES.MODE_CFB
class Cipher(object):
"""
Cipher class
"""
def __init__(self, key="", text=""):
"""
Init
"""
self.block_size = 16
self.mac_size = 20
self.key = self.set_key(key)
self.text = self.set_text(text)
self.mode = AES.MODE_CFB
Cipher FeedBack (CFB). Es un modo similar de al CBC (Cipher-Block
Chaining), donde cada bloque de texto cifrado depende del actual o
anteriores bloques de texto plano. De igual manera requiere un vector de
inicialización (IV). Pero, tiene la peculiaridad de que transforma el
bloque cifrado subyacente en un 'stream' cifrado. De ésta forma, tanto
el texto plano como el cifrado son procesados en segmentos de s bits.
Por eso a veces también se conoce a ésta forma de organizar mediante
bloques como s-bit CFB.
Lo que hace cuando cifra, es que cada segmento de texto cifrado
contribuye al cifrado del siguiente segmento de texto plano. Cosa fina
;-)
El IV es un bloque de datos que se transmite al receptor. El IV puede
hacerse público y se recomienda que sea generado de forma aleatoria y
cada vez. Es decir, apuntad en vuestro bloc de notas personal; NUNCA usar el mismo IV para cifrar con la misma llave. Bueno, apuntad que AnonTwi al menos, no lo permite. ;-)
El proceso de cifrado, siguiendo el uso del código como explicación, sería:
def encrypt(self):
"""
Encrypt text
"""
# The IV, ciphertext and MAC can't be more than 105 bytes
if BLOCK_SIZE + len(self.text) + MAC_SIZE > 105:
self.text = self.text[:105 - BLOCK_SIZE - MAC_SIZE]
# Derive the cipher and MAC keys
(cipher_key, mac_key) = derive_keys(self.key)
# Generate a random IV
iv = urandom(BLOCK_SIZE)
# Encrypt the plaintext
aes = AES.new(cipher_key, self.mode, iv)
ciphertext = aes.encrypt(self.text)
# Calculate the MAC over the IV and the ciphertext
mac = hmac_sha1(mac_key, iv + ciphertext)
# Base64 encode the IV, ciphertext and MAC
return b64encode(iv + ciphertext + mac)
Aquí hubo debate sobre el uso de "urandom" cómo método para generar
procesos de 'verdadera aleatoriedad'. Dejamos ahí eso, por si os apetece
comentarlo.
Vemos que genera perfectamente el cifrado con la combinación deseada y forma un string en base64 listo para ser compartido.
Os recomiendo probarlo directamente sobre el fichero "encrypt.py" que viene en la carpeta "core" del
paquete de AnonTwi.
Contiene un ejemplo que podéis lanzar tal cual desde la propia shell y
que junto con la revisión del código anterior, nos permite ver todo el
proceso de seguido. Al lanzar el fichero de "encrypt" obtenemos una
salida similar a la siguiente:
% python encrypt.py
Key: 2NU2JUYZJ5cozXAysV7H1n/rf9Ez9GiLa0i2Hb5nyhA=
Ciphertext: IIleV4mTLcdMjh4GDNlnsfmcLUvooou86hClRW1IBBWJEXA4dqh/Dh0392SLl9Pg
Length: 64
Plaintext: Hello world!
Ciphertext:
DTWRtPsxPN8lBISCtOe5JNZlsSVKPV96LXIo/SLpKOPrhvWnnbSU49+D/KfCaC+tTSrQnxYC9r0/0OOUlFCVlEGP9Dn94sHp7LliOC05WWhu3TGJ80LwpLTUdMdLNH0GAOLGUZzRNDgz
Length: 140
Plaintext: Gosh this is a long message, far too long to fit in a tweet I
dare sa
Ciphertext: SQL7TiX7Sa4RfQ7MBpP+pUaSG9zONBtDQYgIJ1gYyXAt00jwTR3an40csrpMEI0K
Length: 64
Plaintext: None
Por supuesto os invitamos a mejorarlo.
El reto está en: "Obtener el mejor rendimiento posible entre; robustez del algoritmo de cifrado y tamaño del string en caracteres a enviar"
Terminando con el tema del cifrado. Ha surgido en algunas ocasiones, el
tema de si usar cifrado simétrico o asimétrico para según que cosas. Si
os interesa, se habla y se explica el porque de la decisión de usar el
cifrado simétrico para una herramienta del tipo de AnonTwi, en un hilo
en la lista de
hacktivistas. No puedo linkaros desde aquí porque el
archivo es privado. Pero si os apuntáis a la lista para poder verlo, buscad el hilo:
#AnonTwi v1.0 liberada (creado el: 24/12/2012)
Cambiando de tema, otro de los puntos a destacar de la herramienta, es el de que usa
SSL de forma obligada para interactuar con las diferentes API. Eso
evita posibles casos de eavesdropping por parte de los ISP u otros "entes" que pudiesen tener la intención de obtener nuestras llaves.
Permite utilizar proxy Socks para conectarse remotamente, facilitando el uso de la red
TOR. Al mismo tiempo, envía con cada petición varios parámetros de las cabeceras HTTP falseados (
User-Agent/Referer)
Una vez dentro de las redes sociales, contiene el común de
funcionalidades que permite el código de la API que tenemos implementado
de momento, mas otras opciones resumimos a continuación:
- Enviar mensajes públicos o privados de forma cifrada
- Enviar coordenadas de geolocalización falsa
- Descifra los mensajes automáticamente desde una url o metiendo el texto en raw
- Permite guardar los mensajes de la red social en tu propio disco (los tuyos y los de otra gente)
- Suicidio. En algunas redes no se permite todo el proceso,
pero AnonTwi trata de borrar todo tu contenido y cerrar la cuenta de
forma automática
- Soporta UTF-8, símbolos, así como varios lenguajes iconográficos: Chino, Árabe, etc
- Al tratarse de código generado en python es multiplataforma: Win32, OSx, Unix
- Es posible lanzar una interfaz visual en GTK+ (más una Web que se encuentra en desarrollo)
- Contiene un bot de IRC, que te permite controlar las cuentas desde un canal
- El motor es sencillo de trabajar mediante lenguajes de scripting
En definitiva y para no alargarnos demasiado, pensamos que es una
herramienta que puede ser bastante útil y que quizás, sea de obligada
pertenencia a nuestro kit de herramientas "ninja" mas utilizadas. Eso lo dejamos en vuestras manos. De momento, ya hemos dado un primer paso.
Esperamos que el resultado os sirva para vuestras acciones. Buenas o malas, lo importante es que sean felices ;-)
No hay comentarios:
Publicar un comentario