DTLS em VoIP: como o DTLS e o DTLS-SRTP protegem as chaves de mídia em WebRTC e SIP

Toda chamada de voz criptografada esbarra no clássico problema do ovo e da galinha: o áudio é protegido pelo SRTP, mas o SRTP precisa de uma chave secreta, e essa chave tem de chegar aos dois endpoints sem que ninguém a intercepte no caminho. A forma como os dois lados chegam a um acordo sobre essa chave é a decisão mais importante da segurança de mídia em tempo real, e é aí que o DTLS conquista seu lugar na pilha de protocolos.

O Datagram Transport Layer Security (DTLS) leva a confidencialidade e a autenticação do TLS para transportes não confiáveis e tolerantes à perda de pacotes, como o UDP, que é justamente onde trafegam a voz e o vídeo em tempo real. Combinado com o SRTP, ele se torna o DTLS-SRTP: o mecanismo de troca de chaves que o WebRTC torna obrigatório e que aparece cada vez mais na fronteira entre a mídia baseada em navegador e as redes SIP tradicionais. Este guia explica o que é o DTLS, como funciona o handshake DTLS sobre UDP, como o DTLS-SRTP negocia as chaves de mídia, em que o DTLS difere do TLS e onde um Controlador de Borda de Sessão (SBC) se encaixa no meio de tudo isso.

O que é DTLS?

O DTLS é o TLS redesenhado para transportes que não garantem nem a entrega nem a ordem dos pacotes. O TLS padrão pressupõe um fluxo de bytes confiável e ordenado, que é o que o TCP oferece. A mídia em tempo real não roda sobre TCP, porque um pacote de voz retransmitido que chega atrasado é pior do que inútil: o instante que ele representa já passou. Voz e vídeo rodam sobre UDP, em que os pacotes podem se perder, chegar duplicados ou fora de ordem, e o TLS, do jeito que foi especificado, não sabe lidar com isso.

O DTLS resolve o problema mantendo intacto o modelo de segurança do TLS e acrescentando os mecanismos que faltam ao UDP. Ele introduz números de sequência explícitos, para que o receptor detecte lacunas e reordenações, um temporizador de retransmissão, para que uma mensagem de handshake perdida seja reenviada em vez de travar a conexão, e uma regra que obriga cada mensagem de handshake a caber nos limites do transporte. A criptografia, os conjuntos de cifras e o modelo de confiança são os mesmos do TLS. O que muda é a embalagem em volta deles.

O protocolo evoluiu junto com o TLS. O DTLS 1.2 (RFC 6347) corresponde ao TLS 1.2, e o DTLS 1.3 (RFC 9147) corresponde ao TLS 1.3, do qual herda o handshake mais rápido e os conjuntos de cifras modernos. Em VoIP, o DTLS importa por um motivo que pesa mais do que todos os outros: é o mecanismo que o WebRTC usa para estabelecer as chaves que protegem a mídia.

Como funciona o handshake DTLS

O handshake DTLS segue a mesma estrutura lógica de um handshake TLS, com adaptações que permitem concluí-lo de forma confiável em um canal de datagramas sujeito a perdas. O objetivo continua o mesmo: dois endpoints se autenticam mutuamente e chegam a um segredo compartilhado antes que qualquer mídia protegida comece a circular.

O fluxo do handshake

1. ClientHello e HelloVerifyRequestO cliente abre com um ClientHello. O servidor responde com um HelloVerifyRequest que carrega um cookie sem estado (stateless), e o cliente reenvia o ClientHello devolvendo esse cookie. Essa ida e volta existe para neutralizar a amplificação típica dos ataques de negação de serviço (DoS): o servidor não guarda nenhum estado enquanto não tiver a prova de que o cliente consegue receber tráfego no endereço que declara.
2. Parâmetros e certificado do servidorO servidor envia o ServerHello com o conjunto de cifras escolhido, seguido do seu certificado e dos parâmetros de troca de chaves. No DTLS-SRTP, o certificado costuma ser autoassinado, porque a confiança vem de um fingerprint transportado na sinalização, e não de uma CA pública.
3. Troca de chaves e certificado do clienteO cliente envia sua própria contribuição para a troca de chaves e, quando há autenticação mútua, também o seu certificado. A partir daí, os dois lados têm o material necessário para derivar um segredo mestre compartilhado.
4. ChangeCipherSpec e FinishedCada lado sinaliza que vai passar a usar as chaves negociadas e, em seguida, envia uma mensagem Finished com um hash de todo o handshake. Se a verificação de qualquer uma das mensagens Finished falhar, o handshake é desfeito.

Durante todo o processo, cada leva de mensagens (flight) fica sob um temporizador de retransmissão. Se a resposta esperada não chega, o remetente reenvia em vez de presumir uma falha, e é isso que permite concluir o handshake em um caminho que descarta pacotes sem avisar.

Por que a troca de cookie é importante

O cookie do HelloVerifyRequest é um detalhe pequeno com um papel de segurança desproporcional. Como o DTLS roda sobre UDP, um atacante consegue forjar com facilidade o endereço de origem de um ClientHello e direcionar a custosa resposta criptográfica do servidor para uma vítima. Ao exigir que o cliente devolva um cookie emitido pelo servidor, o DTLS o obriga a provar que de fato recebe tráfego no endereço declarado, o que fecha esse vetor de amplificação antes que qualquer trabalho real comece.

Como o DTLS-SRTP negocia as chaves de mídia

O DTLS-SRTP não é uma forma de criptografar a mídia. A mídia continua sendo transportada pelo SRTP, exatamente como aconteceria com qualquer outro método de troca de chaves. O que o DTLS-SRTP faz é resolver o problema mais difícil: fazer as chaves SRTP chegarem aos dois endpoints com segurança. Para isso, ele executa um handshake DTLS completo diretamente no caminho de mídia e depois deriva as chaves SRTP do segredo que esse handshake produz.

A parte engenhosa está na forma como a confiança é ancorada. Os dois endpoints trocam certificados autoassinados durante o handshake DTLS, mas um certificado autoassinado, sozinho, não prova nada. O vínculo vem da sinalização: cada endpoint publica um hash do seu certificado como atributo a=fingerprint no SDP da oferta e da resposta, seja em SIP ou em WebRTC. Quando o handshake DTLS termina, cada lado compara o certificado que de fato recebeu com o fingerprint que lhe foi prometido na sinalização. Se os dois coincidem, fica confirmado que o handshake foi feito com o par esperado, e não com um interceptador.

Esse desenho dá ao DTLS-SRTP uma propriedade que o SDES não tem. Com o SDES, a própria chave mestra SRTP fica no corpo SDP, então qualquer pessoa capaz de ler a sinalização consegue descriptografar a mídia; por isso o SDES só é seguro quando a sinalização SIP também está protegida por TLS. Com o DTLS-SRTP, a sinalização carrega apenas um fingerprint, que não serve para nada a um atacante: o material real das chaves nunca sai do caminho de mídia e é negociado de novo a cada sessão. É essa separação que faz o WebRTC exigir o DTLS-SRTP e proibir totalmente o SDES.

De onde vêm as chaves

Concluído o handshake DTLS, os dois endpoints aplicam a mesma função de derivação de chaves, definida na RFC 5764, sobre o segredo mestre compartilhado para gerar as chaves mestras e os salts do SRTP. A associação DTLS pode então ser mantida apenas como contexto de chaves, enquanto o SRTP assume o transporte do áudio e do vídeo. Nenhum dos lados chegou a transmitir uma chave SRTP às claras, e nenhum confiou em uma mensagem que não pudesse conferir com o fingerprint da sinalização.

DTLS vs TLS: qual é a diferença?

DTLS e TLS compartilham o mesmo núcleo criptográfico, os mesmos conjuntos de cifras e o mesmo modelo de confiança. A diferença está no transporte para o qual cada um foi feito e, nas redes de voz, na função que cada um acaba exercendo. O TLS roda sobre TCP, confiável e orientado a conexão, e protege a sinalização SIP. O DTLS roda sobre UDP, não confiável e sem conexão, e, na forma DTLS-SRTP, protege a troca das chaves de mídia.

Característica	TLS	DTLS
Transporte	TCP (confiável, ordenado)	UDP (não confiável, sem ordenação)
Lida com perda de pacotes	Depende do TCP	Retransmissão integrada
Papel típico em VoIP	Criptografia da sinalização SIP (porta 5061)	Troca de chaves de mídia DTLS-SRTP
Mecanismo anti-DoS	Handshake do TCP	Troca de cookie sem estado
Sensibilidade à latência	Bloqueio head-of-line quando há perda	Sem bloqueio head-of-line

Na prática, os dois protocolos se complementam em vez de competir. Uma chamada WebRTC-SIP segura costuma usar os dois ao mesmo tempo: o TLS protege a sinalização SIP no lado da rede, enquanto o DTLS-SRTP faz o handshake das chaves de mídia no lado do navegador. Um não substitui o outro, e muitas vezes o SBC precisa falar os dois simultaneamente, em pernas opostas da mesma chamada.

DTLS-SRTP na fronteira entre WebRTC e SIP

O DTLS-SRTP é obrigatório no WebRTC e praticamente universal nas comunicações baseadas em navegador, mas a maioria das operadoras SIP e dos PBXs legados nunca o adotou. Esses ambientes dependem do SDES sobre TLS, ou de RTP simples quando nenhuma criptografia é negociada. Quando um navegador precisa alcançar um número de telefone em um tronco de operadora, algum elemento tem de ficar entre os dois mundos e traduzir a troca de chaves. Esse elemento é o SBC.

Como o SBC opera como agente de usuário back-to-back (B2BUA), ele termina completamente a mídia em cada perna e a reorigina de forma independente. Na perna voltada para o navegador, pode executar o handshake DTLS, verificar o fingerprint e derivar as chaves SRTP como manda o WebRTC. Na perna voltada para a operadora, pode negociar SDES sobre TLS, converter para RTP simples ou aplicar o que o outro lado suportar. As duas pernas têm contextos criptográficos totalmente separados, então o navegador recebe o DTLS-SRTP obrigatório sem que a operadora precise mudar nada. É a mesma fronteira de criptografia por perna descrita na arquitetura de gateway WebRTC-SIP, em que a transição da criptografia de mídia entre os dois lados é um dos cinco subsistemas de tradução que o gateway executa.

A fronteira envolve mais do que criptografia. O mesmo SBC trata o conjunto mais amplo de diferenças entre WebRTC e SIP: a terminação do ICE, para que os candidatos de travessia de NAT do navegador resultem em um endereço estável, a mediação de codecs quando o navegador oferece Opus e a operadora quer G.711, e a normalização de cabeçalhos SIP, para que a chamada pareça nativa em cada lado. A tradução do DTLS-SRTP é só uma das tarefas do gateway, mas é ela que mantém a mídia confidencial de ponta a ponta.

Perguntas frequentes

Conclusão

O DTLS existe porque a mídia em tempo real não pode esperar pela latência das idas e vindas do TCP, e a mídia segura não pode depender de chaves que trafegam às claras na sinalização. Ao levar o modelo de segurança do TLS para o UDP e combiná-lo com o SRTP, o DTLS-SRTP resolve o problema da troca de chaves de um jeito que sobrevive à perda de pacotes, resiste à falsificação de endereço e nunca expõe uma chave de mídia a quem lê a sinalização. Essa combinação explica por que ele se tornou a base obrigatória da segurança de mídia no WebRTC.

A complicação nas redes em produção é que os navegadores falam DTLS-SRTP, enquanto a maioria das operadoras e dos PBXs não fala. Unir esses dois mundos sem enfraquecer nenhum deles é um problema de criptografia por perna, e é exatamente o tipo de tradução que um SBC existe para fazer na borda da rede.