Signal (anteriormente RedPhone) proporciona cifrado de extremo a extremo para sus llamadas, asegurando sus conversaciones para que nadie pueda escucharlas.
Pero, en realidad, ¿cuál es la probabilidad de que una conversación de voz sea interconectada?
¿Y los detalles de contacto (como phone-nr) también están ocultos al proveedor? ¿O puede el proveedor construir una base de datos de quién sabe quién?
Navegando a través de la fuente en GitHub , uno aprende que usa ZRTP.
De ¿Cuáles son las vulnerabilidades específicas de VOIP? ¿protocolos de seguridad? :
Prateek Gupta, Vitaly Shmatikov (2006) Análisis de seguridad de los protocolos de voz sobre IP
También demostramos un ataque de hombre en el medio en ZRTP que deshabilita la autenticación y permite al atacante hacerse pasar por un usuario de ZRTP y establecer una clave compartida con otro usuario.
Para el cifrado, se basa en Spongy Castle v.1.46.99.3-ROBERTO-LIBERACIÓN NO OFICIAL
La corriente ascendente de Spongy Castle, Bouncy Castle, tiene el siguiente CVE contra su cabeza:
CVE-2013-1624
Resumen: la implementación de TLS en la biblioteca de Java de Bouncy Castle antes de 1.48 y la biblioteca de C # antes de la 1.8 no considera correctamente la sincronización de ataques de canal lateral en una operación de verificación de MAC que no cumple las normas durante el procesamiento del relleno de CBC con formato incorrecto, que permite a los atacantes remotos realizar ataques distintivos y ataques de recuperación de texto sin formato mediante el análisis estadístico de los datos de temporización de los paquetes creados, un problema relacionado con CVE-2013-0169.
Publicado: 08/02/2013 Gravedad CVSS: 4.0 ( MEDIO )
El software utiliza Speex y G.711 codecs según la fuente. Dependiendo del códec, no solo se pueden inferir los metadatos, sino también el idioma y el contenido del diálogo porque el códec Speex utiliza la codificación de velocidad de bits variable (VBR) (combinada con Cualquier detección de actividad y generación de ruido de confort, para ser más precisos) (consulte las preguntas y respuestas vinculadas A para obtener más detalles).
Sin embargo, recomiendo buscar en la fuente, en lugar de confiar en extraños ...
Voy a estar en desacuerdo con la respuesta de AJ. Cuando realice una llamada de RedPhone primero lo autenticarán uno de los servidores de autenticación y luego un servidor de retransmisión que maneja la conexión Usted al destinatario de la llamada. Todas estas comunicaciones están encriptadas.
Debido a que la persona que llama no está conectada directamente al destinatario (la mayoría necesita redireccionamiento de NAT en redes de datos móviles), su proveedor no puede saber con quién está hablando. Ellos pudieron averiguar cuánto duró la conversación, pero no pueden saber el destinatario o el contenido. Solo los RedPhone mismos pueden saber a quién llamas.
En el raro caso de que el destinatario tuviera su puerto RedPhone abierto y pudiera recibir una conexión directamente, entonces su proveedor solo conoce su dirección IP, lo que podría ser útil para averiguar su número de teléfono.
Redphone no está diseñado para evitar la captura de metainformación. Todavía es posible que alguien que realiza el monitoreo averigüe con quién está hablando y cuánto tiempo ha hablado, ya que no implementa el enrutamiento de cebolla o un sistema similar. Sin embargo, debería proteger la seguridad de los contenidos de su comunicación, ya que las personas que escuchan desconocen las claves de cifrado y no se conocen vulnerabilidades que permitan descifrar el cifrado.
Lea otras preguntas en las etiquetas encryption voip