ZRTP (compuesto por Z y el Protocolo de transporte en tiempo real ) es un protocolo de acuerdo de clave criptográfica 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 Internet Engineering Task Force (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 clave que realiza el intercambio de claves Diffie-Hellman durante el establecimiento de la llamada". dentro de 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 usa para generar claves y sal para un entorno seguro. Sesión RTP (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. Admite cifrado oportunista mediante detección automática si el otro cliente VoIP admite ZRTP.
Este protocolo no requiere secretos compartidos previamente ni depende de una infraestructura de clave pública (PKI) o de autoridades de certificación; de hecho, se generan claves efímeras Diffie-Hellman en cada establecimiento de sesión: esto permite la complejidad de crear y mantener un tercero confiable. para ser omitido.
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 previamente compartidos (si los hay): esto brinda protección contra ataques de intermediario (MiTM) . siempre y cuando el atacante no estuviera 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 producen a través del flujo de medios RTP.
ZRTP/S, una extensión del protocolo ZRTP, puede ejecutarse en cualquier tipo de redes telefónicas heredadas, incluidas GSM, UMTS, ISDN, PSTN, SATCOM , radio UHF / VHF , porque es un protocolo orientado a flujo de bits de banda estrecha y realiza todas las negociaciones clave. dentro del flujo de bits entre dos puntos finales.
Alan Johnston nombró al protocolo ZRTP porque en sus primeros borradores de Internet se basaba en agregar extensiones de encabezado a los paquetes RTP, lo que convirtió a ZRTP en una variante de RTP. En borradores posteriores, el formato del paquete cambió para hacerlo sintácticamente distinguible 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 de cadena de autenticación corta (SAS): las partes que se comunican verifican verbalmente un valor compartido mostrado 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 "pequeño ataque rico", pero no se cree que esta clase de ataque represente 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 de SAS se representa en ambos puntos finales de 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 produzca un ataque de intermediario. El uso del compromiso de hash en el intercambio DH limita al atacante a una sola suposición 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 sólo 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. Lo hace almacenando en caché cierta información de clave hash para usarla en la siguiente llamada, para mezclarla con el secreto compartido DH de la siguiente llamada, dándole propiedades de continuidad clave análogas a SSH . Si el MitM no está presente en la primera llamada, no podrá participar en llamadas posteriores. Por lo tanto, incluso si nunca se utiliza el SAS, 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 empresa fundada por Zimmermann. [15] También existe el Softphone de Acrobits. [16] Draytek admite ZRTP en algunos de sus hardware y software VoIP. [17] [18]
Se ha publicado una lista de proveedores SIP gratuitos con soporte ZRTP. [11]