Hoy me gustaría hablar sobre los resultados de mi investigación de siete años en el campo de la transmisión de voz a través de la red Tor. En general, se acepta que la comunicación de voz a través de Tor es casi imposible:
- los protocolos de transporte existentes para telefonía funcionan sobre UDP, y Tor solo proporciona conexiones TCP;
- Tor enruta paquetes a través de múltiples nodos, encriptando los datos, lo que causa una latencia significativa y hace que la telefonía dúplex sea imposible o extremadamente incómoda.
¿Pero es realmente así?
En 2012, pensé por primera vez en la posibilidad fundamental de implementar comunicaciones telefónicas anónimas utilizando anonimizadores Tor e i2p. La reacción de la comunidad fue claramente negativa, incluido el propio Phil Zimmermann, autor del famoso PGPFone, en base al cual trabajó el primer Torfon. Pero era terco, probé nuevas ideas, probé y mejoré los trucos encontrados, principalmente destinados a reducir la latencia a un nivel aceptable. Otros investigadores también trabajaron en esta dirección, y sus publicaciones me dieron nuevas ideas y la base para seguir trabajando. Los aspectos positivos fueron la aceleración significativa de la red global de Internet y la red Tor en particular, así como el destete gradual de los usuarios de PSTN a favor de la comunicación GSM con su latencia significativa inherente. Finalmente, se desarrolló un concepto adecuado, y fue el turno de implementar el plan.
En 2013, Roger Dingledine, en correspondencia personal, criticó severamente el proyecto por la falta de multiplataforma (en ese momento, PGPFone se utilizó como base en una plataforma de Windows) y por su arquitectura no modular. En el contexto de esta crítica, se sentaron las bases para la implementación moderna de Torfon, teniendo en cuenta muchas pruebas y errores, así como las tendencias modernas en criptografía.
Hoy, Torfon consta de cuatro módulos de software que interactúan entre sí mediante paquetes de 36 bytes con campos estrictamente fijos. Este es un módulo de transporte que proporciona trabajo con sockets, un módulo de criptografía y sonido, un módulo de almacenamiento (realiza operaciones con una clave privada y contiene una libreta de direcciones encriptada) y un módulo de interfaz de usuario. Se pueden ejecutar en la misma plataforma de hardware (en una o en diferentes transmisiones) o en varias plataformas aisladas utilizando un protocolo serie estándar (UART de hardware, USB CSD o Bluetooth SPP) como interfaz. Esta arquitectura permite al desarrollador determinar un compromiso entre la seguridad y la facilidad de implementación. Las opciones están disponibles desde una aplicación de Windows independiente hasta la implementación de hardware en forma de una sola placa con Linux para Tor y un módulo de transporte junto con un microcontrolador Cortex M4 aislado, que encripta, procesa y reproduce completamente el audio, almacena la clave privada y los contactos, y se implementa una interfaz gráfica de usuario.
El código fuente de los módulos está escrito en C y es completamente multiplataforma, con la excepción del trabajo de bajo nivel con audio, que se transfiere a archivos separados específicos para Windows (Wave), Linux (Alsa), Android (OpenSL) y bare metal (ADC / DAC + DMA para el microcontrolador )
Al elegir un códec y una cola de audio, se tuvieron en cuenta las características de la red Tor: retrasos espontáneos frecuentes y periódicos, una ligera disminución de la latencia para paquetes en un cierto rango de longitud, la capacidad de crear cadenas duplicadas con diferentes rutas de enrutamiento durante una llamada, etc. El proyecto intermedio OnionPhone incluyó 17 de los códecs de audio de baja tasa de bits más comunes. Después de una cuidadosa prueba, se seleccionó la opción más adecuada: AMR con una tasa de bits mínima de 4750 bps y un VAD de alta velocidad. Por lo tanto, teniendo en cuenta las pausas naturales entre las palabras y la naturaleza dúplex de la comunicación, la tasa de bits promedio total en cada dirección es de aproximadamente 2000-3000 bps., Lo que hace posible utilizar GPRS incluso en condiciones de cobertura GSM deficiente y pérdida masiva de paquetes GSM.
Se desarrolló un algoritmo NPP7 eficaz como supresor de ruido, desarrollado para combatir el ruido de audio intenso y forma parte del códec MELPe, el estándar actual de comunicaciones militares STANAG-4591. El algoritmo de cancelación de eco se seleccionó del proyecto WebRTC como la solución abierta más efectiva disponible.
La funcionalidad general de Torfon se desarrolló teniendo en cuenta los posibles casos de uso y los modelos de amenazas existentes que ya se usaban contra los mensajeros instantáneos populares.
Modos de funcionamiento básicos:
- Llamadas de voz anónimas al servicio oculto Tor (en la dirección de la cebolla). Estas llamadas están protegidas tanto como sea posible, pero hay algún retraso, lo que puede causar cierta incomodidad a los usuarios no acostumbrados.
- Cambiar a una conexión UDP directa (con paso NAT) después de configurar una conexión Tor. Las claves de cifrado de sesión negociadas dentro de Tor brindan una gran privacidad, pero se pierde el anonimato (los usuarios revelan su dirección IP entre sí).
- Llamadas directas a la dirección IP especificada (o nombre de dominio) y número de puerto TCP. Para recibir tales llamadas, necesita una dirección IP "blanca" (enrutable) en el dispositivo (muchos operadores móviles lo ofrecen como un servicio pago) o un reenvío del puerto TCP utilizado en un enrutador local (por ejemplo, en una red WiFi doméstica). Las llamadas directas pueden realizarse en una red de área local aislada (por ejemplo, una red WiFi local creada utilizando un potente punto de acceso instalado en el centro del área de servicio). En este caso, Torfon no requiere interacción con Internet: el proyecto no tiene su propio servidor, lo cual es un punto de posible falla, ataque y recopilación de metadatos. Por lo tanto, Torfon puede funcionar con éxito incluso con el aislamiento completo del segmento de red o de todo el Runet a nivel de estado.
Hoy, con frecuencia, la cuestión de la confianza en Tor se plantea tanto en términos de mantener el anonimato como en términos de confidencialidad de los datos transmitidos. El conocido mensajero TorChat no utilizó su encriptación y autenticación, confiando completamente en los servicios provistos por Tor. Personalmente, confío en Tor, al menos en términos de privacidad y perfecto secreto hacia atrás. Pero, desafortunadamente, esta posición se ve ensombrecida por el descubrimiento de vulnerabilidades globales SPECTER / MELTDOWN, así como una gran cantidad de vulnerabilidades de día cero para todos los sistemas operativos conocidos que se utilizan prácticamente como herramientas de trabajo en el arsenal de cualquier servicio especial. Por lo tanto, no pude seguir el camino de TorChat y agregué a Torfon mi propia capa de encriptación y autenticación, usando los protocolos más modernos y primitivas criptográficas demostrablemente fuertes.
El concepto se basa en la capacidad de realizar llamadas entre suscriptores desconocidos y luego intercambiar automáticamente sus claves públicas para la autenticación mutua en las sesiones de comunicación posteriores. Este enfoque proporciona una cierta negación en la cuestión de la presencia de una clave comprometedora en la lista de sus contactos: cualquier suscriptor, conociendo su dirección de cebolla, puede hacer una llamada anónima e inmediatamente reenviarle cualquier contacto de su libreta de direcciones. Este contacto se agregará automáticamente a su libreta de direcciones. Sin embargo, esta función se puede deshabilitar en la configuración, pero ¿quién sabe si la había activado antes?
Se presta especial atención a la protección de los identificadores de suscriptor. Entonces, la persona que llama sabe a quién llama y debe decirle su identificación (clave). ¡Pero solo él y nadie más! Además, si la conexión es interceptada, incluso por un atacante activo, y luego se revelan todas las claves privadas de los participantes, no hay forma de establecer (o seleccionar de la lista de conocidos) los identificadores de los participantes en cada muestra o sesión interceptada en el pasado. En otras palabras, la protección de la ID de los suscriptores llamantes y llamados con un secreto inverso perfecto (PFS). Esto se logró modificando el protocolo Triple-DH (triple Diffie-Hellman, también utilizado en Signal) agregando un protocolo HABLA paralelo, que proporciona cero divulgación con respecto a los autenticadores explícitos intercambiados entre las partes durante el intercambio inicial de claves.
El protocolo utilizado en Torfon tiene la propiedad de Negabilidad, cuando después de una sesión de comunicación completa, la parte maliciosa no puede convencer al juez de que el contacto realmente tuvo lugar. La negación directa también se proporciona cuando la parte maliciosa acuerda de antemano con el juez que llevará a cabo la sesión y, después de que se complete la sesión, intenta probar que se llevó a cabo. Negación total (Negación total, cuando la parte maliciosa contacta al juez durante una sesión de comunicación), compite con una propiedad tan importante como KCI: la estabilidad (la incapacidad de presentarse a otro suscriptor cuya clave privada se conoce). Basado en realidades prácticas, la preferencia estaba a favor de la estabilidad de KCI, como una propiedad más práctica, especialmente en condiciones de relaciones no legales.
De las capacidades adicionales para autenticarse mutuamente en el primer contacto (para garantizar la autenticidad del intercambio de claves), se implementan dos protocolos:
- Comparación de una huella digital corta de un secreto compartido (SAS, similar al protocolo ZRTP). Para bloquear el ataque corto de huellas digitales durante el proceso MitM, se utiliza la confirmación en el procedimiento Diffie-Hellman. Además, la huella digital del secreto compartido se incluye automáticamente en el nombre del contacto aceptado en esta sesión. Por lo tanto, al intercambiar contactos durante una sesión, el comienzo del nombre del nuevo contacto debe ser el mismo para ambos participantes, lo que puede verificarse más tarde, por ejemplo, en persona. Y, por cierto, el contacto recibido debe renombrarse para permitir que Torfon se represente a sí mismo (su ID) en este contacto.
- Comparación de un secreto previamente acordado (palabras, frases). En OTR, el protocolo socialista-millonario realiza una función similar. Peat usa el mismo protocolo SPEKE en términos de propiedades (con cero divulgación).
En caso de que ambos participantes de la sesión tengan contactos (claves públicas) entre sí, si la autenticación es exitosa y se utiliza Tor (llamar a la dirección de la cebolla), la parte receptora realiza una contra llamada utilizando la dirección de la cebolla de la parte que llama de su libreta de direcciones. Una vez establecida la conexión, se realiza la autenticación mutua en el segundo canal, confirmando la dirección de la cebolla de la persona que llama. TorChat utiliza un procedimiento similar para autenticar chats, utilizando la dirección de cebolla del contacto como ID.
La conexión paralela de Tor consiste en otras cadenas, que se usan ventajosamente para compensar los retrasos espontáneos: los paquetes de voz se envían a ambos canales a la vez, se usa el paquete recibido anteriormente. Además, se mantienen estadísticas sobre retrasos en ambos canales, y si uno de los canales es mucho más lento, se vuelve a conectar periódicamente durante una conversación. Esto reduce la latencia general de la llamada autenticada en comparación con una llamada de un suscriptor desconocido.
Como muestra una práctica triste, hoy es muy importante enseñar a la aplicación a defenderse de posibles bloqueos. Afortunadamente, Torfon no tiene su propio servidor o nube, sino que utiliza Tor. Por lo tanto, bloquear Torfon solo es posible bloqueando Tor. Pero hoy también es una realidad, y en este caso solo habrá la posibilidad de hacer llamadas directamente a la dirección IP y al puerto TCP. En el escenario más pesimista, el hermano mayor intentará enseñar a los sistemas DPI (análisis profundo de paquetes) para detectar el tráfico entre dos Torfons en una red p2p controlada. Por lo tanto, se tomaron medidas adicionales para maximizar la ocultación de dicho tráfico. Primero, el puerto de escucha TCP se puede seleccionar manualmente y en realidad es parte de la dirección del suscriptor. En segundo lugar, absolutamente todos los paquetes (incluido el audio) durante una sesión de comunicación (sesión TCP) no tienen características distintivas (campos constantes o incrementales, longitudes, etc.) y parecen datos aleatorios de longitud aleatoria para un observador externo . En tercer lugar, para realizar una muestra activa del protocolo, se requiere una "Prueba de trabajo" como protección contra el escaneo masivo de direcciones y puertos para la detección de Turba.
De hecho, la conexión se realiza mediante dos conexiones TCP consecutivas. Durante la primera conexión, las partes intercambian claves de sesión principal en forma de puntos en la curva elíptica X25519, realizando el protocolo habitual de Diffie-Hellman. Dado que el formato Montgomery de la representación de puntos no es un número aleatorio, se utiliza la representación Elligator2, complementada por bytes aleatorios. Después de eliminar el secreto compartido, la primera sesión se interrumpe, y después de un período de tiempo aleatorio (varios segundos), se establece la segunda sesión, todos los datos en los que se cifra con una clave derivada del secreto compartido. Se generan nuevas claves de sesión, y el protocolo Diffie-Hellman se ejecuta nuevamente, ahora con un comentario. Las claves simétricas para el cifrado y descifrado se derivan del secreto obtenido. El protocolo triple Diffie-Hellman se ejecuta en paralelo con el protocolo SPEKE para proteger la identificación de la persona que llama y la autenticación. En ausencia de claves en la libreta de direcciones (contacto desconocido) o cualquier discrepancia, todos los mensajes se reemplazan con bytes aleatorios. El protocolo no se interrumpe para evitar fugas de información de identidad de los participantes.
Para la implementación de estos protocolos, se utilizan códigos fuente C cuidadosamente verificados de primitivas criptográficas, tomadas de bibliotecas criptográficas conocidas. Para la verificación en la etapa de desarrollo, se utilizaron vectores de prueba bien conocidos y, después de cada lanzamiento de la aplicación, se realiza una verificación adicional de una implementación específica del código ejecutable (resultado de la compilación).
Para la capa de ofuscación, se seleccionó el algoritmo simétrico Serpent-128, que opera en el modo de cifrado OCB autenticado. Para la capa básica de cifrado simétrico, se utiliza la transformación Keccak-800 como una función Shake-128 y un contador de paquetes CTR unidireccional. Se usa la misma primitiva que Hash, MAC y PKDF. El algoritmo ChaCha20 se usa para cifrar la libreta de direcciones y el generador de números pseudoaleatorios. El generador reside al comienzo de cada sesión, para la acumulación de entropía en sistemas operativos multitarea, se utiliza el algoritmo Havege y, en el microcontrolador, el bit de orden inferior del resultado ADC que mide el ruido del divisor resistivo. La entropía se acumula a la cantidad requerida, estimada mediante la prueba de frecuencia grupal.
Las primitivas criptográficas principales (matemáticas elementales para X25519, Keccak800, ChaCha20) utilizan implementaciones de ensamblador optimizadas para compiladores para plataformas de microcontroladores (Cortex M1 y M4), cuidadosamente probadas para el tiempo de ejecución constante y con fugas minimizadas a través de canales laterales de radiación electromagnética y fluctuaciones de consumo de corriente. Debo decir de inmediato: estos códigos de ensamblador fueron recibidos de profesionales de fama mundial, simplemente los porté de GNU ASM al entorno Keil, que es más familiar para construir proyectos integrados.
Bueno, que al final?
Si lees hasta este lugar y no mueres de aburrimiento, significa que este proyecto puede ser realmente útil para ti. Si es así, entonces, a pedido por correo, me complace proporcionar ensambles de prueba (archivos ejecutables vinculados estáticamente, no requiere instalación), así como el código fuente de la interfaz gráfica para Windows, Linux y Android en los respectivos entornos de desarrollo. El núcleo del proyecto se basa en la biblioteca torfone multiplataforma, disponible en la búsqueda de github. Allí también puede encontrar enlaces directos a la versión alfa de la aplicación de Android y una breve guía para su instalación y uso, que ayudará a todos a evaluar la latencia de la telefonía en la red Tor.
La interfaz gráfica se implementa por separado para cada plataforma y no es una opción (hasta ahora, esto es solo una prueba alfa). La aplicación de prueba para todas las versiones de Windows (a partir de Windows 98 antiguo) se ejecutó en el antiguo pero poderoso Borland C ++ Builder 6. Para Linux, la aplicación GUI se desarrolló utilizando los gráficos olvidados Wide Studio para X11 por separado para las arquitecturas i386 y ARM. El primero debería funcionar tanto en computadoras de escritorio de 32 bits como de 64 bits, el segundo, en computadoras económicas de una sola placa: RPi, Orange, Nano, etc. Para Android, se compila un archivo apk en Embarcadero RAD Studio 10.2. Esto está lejos de ser la mejor opción y aún no sabe cómo crear un servicio en primer plano, pero, sin embargo, funciona de manera estable en segundo plano con la optimización del uso de la batería desactivada. Además, el entorno Android admite la copia de seguridad automática de los archivos de configuración, las claves y la libreta de direcciones (en forma cifrada) en el almacenamiento externo y la recuperación al reinstalar Torfon o transferirlo a otro dispositivo. En el momento de la redacción, se está trabajando en un proyecto en el entorno Keil uVision, que incluye transporte, módulos de cifrado, una interfaz gráfica y de audio basada en Arduino, una pantalla táctil TFT + táctil 320 * 240 compatible. El NanoPi Neo con el servidor Debian instalado y la placa Nucleo STM32F446RE conectada a través de un UART físico se utilizará como una plataforma de hardware abierta.
En los planes a largo plazo, portar a iOS, aunque apenas entiendo cómo esto se puede combinar con garantías básicas de seguridad.Y en conclusión.A menudo me hacen las mismas preguntas: ¿cómo puedo administrar usuarios sin un servidor central? ¿Cómo lanzar actualizaciones, anuncios? Y, lo más importante, ¿por qué necesito todo esto si no hay valor comercial en esto?De hecho, el mundo no es tan gris y arruinado. Y hay muchos valores que no se pueden medir con dinero. Pero la respuesta a las dos primeras preguntas, de ninguna manera. Bueno, no puedes detener a Turfon. No puedes obtener "llaves" de él, no puedes fusionar las acciones de los usuarios, incluso aquellos que han sido notados en terrorismo o pedofilia, no puedes prohibir a las personas indeseables. No puede forzar actualizaciones. No se puede controlar desde el exterior. No hay fugas, compuestos secundarios en Torfon, excepto según lo dispuesto por el protocolo. Esto se puede verificar fácilmente tanto en el código (casi todas las líneas están comentadas y no hay tantos archivos en el proyecto), así como analizadores de red. Por lo tanto, nadie podrá administrar usuarios de Torfon. Pero recuerde: Turfon es solo una herramienta, y todas sus acciones dependen de su conciencia, y usted es responsable de ellas, no del autor del proyecto.