ZRTP (compuesto por Z y Protocolo de transporte en tiempo real ) es un protocolo de acuerdo de claves criptográficas para negociar las claves de cifrado entre dos puntos finales en una llamada telefónica de voz sobre IP (VoIP) basada en el Protocolo de transporte en tiempo real . Utiliza el intercambio de claves Diffie-Hellman y el Protocolo de transporte seguro en tiempo real (SRTP) para el cifrado. ZRTP fue desarrollado por Phil Zimmermann , con la ayuda de Bryce Wilcox-O'Hearn , Colin Plumb, Jon Callas y Alan Johnston y fue presentado al Grupo de trabajo de ingeniería de Internet (IETF) por Zimmermann, Callas y Johnston el 5 de marzo de 2006 y publicado el 11 de abril de 2011 como RFC 6189.
ZRTP ("Z" es una referencia a su inventor, Zimmermann; "RTP" significa Protocolo de Transporte en Tiempo Real) [1] se describe en el Borrador de Internet como un "protocolo de acuerdo de claves que realiza un intercambio de claves Diffie-Hellman durante el establecimiento de una llamada en banda en el flujo de medios del Protocolo de Transporte en Tiempo Real (RTP) que se ha establecido utilizando algún otro protocolo de señalización como el Protocolo de Inicio de Sesión (SIP). Esto genera un secreto compartido que luego se utiliza para generar claves y sal para una sesión de RTP Seguro (SRTP)". Una de las características de ZRTP es que no depende de la señalización SIP para la gestión de claves, ni de ningún servidor en absoluto. Admite cifrado oportunista mediante la detección automática de si el otro cliente VoIP admite ZRTP.
Este protocolo no requiere secretos compartidos previos ni se basa en una infraestructura de clave pública (PKI) o en autoridades de certificación, de hecho se generan claves Diffie-Hellman efímeras en cada establecimiento de sesión: esto permite evitar la complejidad de crear y mantener un tercero de confianza.
Estas claves contribuyen a la generación del secreto de sesión, del cual se derivan la clave de sesión y los parámetros para las sesiones SRTP, junto con los secretos compartidos previamente (si los hubiera): esto brinda protección contra ataques del tipo "man-in-the-middle" (MiTM) , siempre que el atacante no haya estado presente en la primera sesión entre los dos puntos finales.
ZRTP se puede utilizar con cualquier protocolo de señalización, incluidos SIP, H.323 , Jingle y sistemas de tablas hash distribuidas . ZRTP es independiente de la capa de señalización, porque todas sus negociaciones clave se realizan a través del flujo de medios RTP.
ZRTP/S, una extensión del protocolo ZRTP, puede ejecutarse en cualquier tipo de red de telefonía heredada, incluidas GSM, UMTS, ISDN, PSTN, SATCOM y radio UHF / VHF , porque es un protocolo orientado al flujo de bits de banda estrecha y realiza todas las negociaciones clave dentro del flujo de bits entre dos puntos finales.
Alan Johnston denominó al protocolo ZRTP porque en sus primeros borradores de Internet se basaba en añadir extensiones de encabezado a los paquetes RTP, lo que convertía a ZRTP en una variante de RTP. En borradores posteriores, el formato de los paquetes cambió para que se pudiera distinguir sintácticamente de RTP. En vista de ese cambio, ZRTP es ahora un pseudoacrónimo .
El intercambio de claves Diffie-Hellman por sí solo no proporciona protección contra un ataque de intermediario. Para garantizar que el atacante no esté presente en la primera sesión (cuando no existen secretos compartidos), se utiliza el método Short Authentication String (SAS): las partes que se comunican verifican verbalmente un valor compartido que se muestra en ambos puntos finales. Si los valores no coinciden, se indica un ataque de intermediario. Un ataque específico teorizado contra el protocolo ZRTP implica la creación de una voz sintética de ambas partes para leer un SAS falso, lo que se conoce como " ataque Rich Little ", pero no se cree que esta clase de ataque sea un riesgo grave para la seguridad del protocolo. [2] El SAS se utiliza para autenticar el intercambio de claves, que es esencialmente un hash criptográfico de los dos valores Diffie-Hellman. El valor SAS se muestra en ambos puntos finales ZRTP. Para llevar a cabo la autenticación, este valor SAS se lee en voz alta al interlocutor a través de la conexión de voz. Si los valores en ambos extremos no coinciden, se indica un ataque de intermediario; si coinciden, es muy poco probable que se trate de un ataque de intermediario. El uso de la confirmación de hash en el intercambio DH limita al atacante a una sola conjetura para generar el SAS correcto en el ataque, lo que significa que el SAS puede ser bastante corto. Un SAS de 16 bits, por ejemplo, proporciona al atacante solo una posibilidad entre 65536 de no ser detectado.
ZRTP proporciona una segunda capa de autenticación contra un ataque MitM, basada en una forma de continuidad de clave. Para ello, almacena en caché cierta información de clave en formato hash para su uso en la siguiente llamada, para mezclarla con el secreto compartido DH de la siguiente llamada, lo que le otorga propiedades de continuidad de clave análogas a SSH . Si el MitM no está presente en la primera llamada, queda excluido de las llamadas posteriores. Por lo tanto, incluso si el SAS nunca se utiliza, la mayoría de los ataques MitM se detienen porque el MitM no estaba presente en la primera llamada.
ZRTP se ha implementado como
Las implementaciones comerciales de ZRTP están disponibles en RokaCom de RokaCom, [13] y PrivateWave Professional de PrivateWave [14] y más recientemente en Silent Phone de Silent Circle, una compañía fundada por Zimmermann. [15] También existe Softphone de Acrobits. [16] Draytek admite ZRTP en algunos de sus hardware y software de VoIP. [17] [18]
Se ha publicado una lista de proveedores SIP gratuitos con soporte ZRTP. [11]