O que é SRTP? Protocolo de Transporte Seguro em Tempo Real explicado

SRTP (Protocolo de Transporte Seguro em Tempo Real) é um perfil de segurança definido na RFC 3711 que adiciona criptografia AES-128, autenticação de mensagem HMAC-SHA1 e proteção contra replay a fluxos de voz e vídeo RTP. Ele utiliza as mesmas portas UDP do RTP padrão (não existe uma porta SRTP separada) e adiciona aproximadamente 2% de overhead de largura de banda com impacto de latência insignificante, tornando-o adequado para comunicações em tempo real.
Por padrão, os pacotes RTP transmitem voz e vídeo sem criptografia. Qualquer pessoa com acesso ao caminho de rede pode capturar esses pacotes e reconstruir a conversa inteira. O SRTP impede isso criptografando cada pacote de forma independente usando AES Counter Mode e autenticando-o com uma tag HMAC antes da transmissão.
Para operadores de infraestrutura VoIP, o SRTP não é mais opcional: o Microsoft Teams Direct Routing o exige, o WebRTC o torna obrigatório, e frameworks de conformidade como HIPAA e PCI DSS o exigem para tráfego de voz que transporta dados sensíveis. Este guia explica o que o SRTP faz, como ele funciona internamente e qual papel um Controlador de Borda de Sessão (SBC) desempenha na sua implantação em redes do mundo real.

Por que a criptografia de mídia VoIP é importante

O RTP padrão foi projetado para eficiência, não para segurança. Ele não possui criptografia, verificação de integridade nem proteção contra ataques de replay. Na prática, isso significa:
Escuta clandestina é o risco mais direto. Um invasor que captura pacotes RTP em uma rede compartilhada, segmento Wi-Fi ou link de infraestrutura em nuvem pode decodificar o áudio usando ferramentas disponíveis gratuitamente como o Wireshark. Os dados de voz estão diretamente na carga útil do pacote.
Injeção de pacotes torna-se possível porque o RTP não possui autenticação. Um invasor pode injetar pacotes fabricados em um fluxo RTP ativo, e o terminal receptor não tem como distinguir pacotes legítimos dos forjados.
Ataques de replay acontecem quando um invasor grava pacotes RTP e os retransmite posteriormente, potencialmente interrompendo chamadas ativas ou reproduzindo fragmentos de conversas sensíveis.
Ataques man-in-the-middle (MitM) permitem que um invasor posicionado entre dois terminais intercepte, modifique ou redirecione fluxos RTP sem que nenhuma das partes saiba. Sem criptografia e autenticação, não existe mecanismo para os terminais verificarem que os pacotes estão chegando inalterados da fonte esperada.
Esses não são riscos teóricos. O tráfego VoIP atravessa regularmente a internet pública entre provedores de troncos SIP, plataformas em nuvem e terminais remotos. Qualquer salto ao longo desse caminho é um ponto de exposição. E à medida que as organizações migram para modelos de trabalho híbrido e remoto, o tráfego de voz cada vez mais atravessa redes que a organização não controla.
Além da higiene de segurança, diversos requisitos de conformidade e de plataforma agora exigem criptografia de mídia:

• Microsoft Teams Direct Routing exige SRTP para toda a mídia. Um SBC que não consegue negociar SRTP não passará na certificação do Teams.
• WebRTC torna DTLS-SRTP obrigatório. Nenhuma plataforma de comunicação baseada em navegador funciona sem ele.
• HIPAA exige criptografia de informações eletrônicas protegidas de saúde (ePHI) em trânsito, o que inclui comunicações de voz que transportam dados de pacientes.
• PCI DSS exige criptografia para dados de cartões de pagamento, incluindo números de cartão falados por VoIP.
• Orientações da FCC referenciam cada vez mais a criptografia na camada de mídia como parte das melhores práticas de segurança de redes VoIP.

Como o SRTP funciona

O SRTP fica sobre o RTP. Ele pega um pacote RTP padrão, criptografa a carga útil, anexa uma tag de autenticação e o envia pelo mesmo transporte UDP que o RTP utiliza. O lado receptor verifica a tag de autenticação, descriptografa a carga útil e passa a mídia para a aplicação. O processo adiciona latência mínima porque o SRTP usa modos de cifra de fluxo projetados para tolerância em tempo real.

Criptografia: AES em Counter Mode

O SRTP usa o Advanced Encryption Standard (AES) como sua cifra padrão. Especificamente, ele opera o AES em Counter Mode (AES-CM), que transforma a cifra de bloco em uma cifra de fluxo. Essa é uma escolha de design deliberada para mídia em tempo real.
O Counter Mode gera um keystream criptografando uma sequência de valores de contador. O keystream é então combinado com a carga útil em texto em claro bit a bit para produzir texto cifrado. Como cada valor de contador é independente, o receptor pode descriptografar qualquer pacote sem precisar ter recebido todos os pacotes anteriores primeiro. Isso é fundamental para VoIP, onde pacotes rotineiramente chegam fora de ordem ou são perdidos por completo. Um modo de cifra que exigisse descriptografia sequencial falharia sob condições normais de rede.
Os dois conjuntos criptográficos padrão definidos para SRTP são:

• AES_CM_128_HMAC_SHA1_80 (chave AES de 128 bits, tag de autenticação de 80 bits)
• AES_CM_128_HMAC_SHA1_32 (chave AES de 128 bits, tag de autenticação de 32 bits)

A variante de 80 bits oferece autenticação mais forte e é a padrão para a maioria das implantações.

Autenticação de mensagem: HMAC-SHA1

A criptografia sozinha não impede adulteração. Um invasor poderia inverter bits na carga útil criptografada, e o receptor descriptografaria em áudio corrompido sem saber que os dados foram modificados.
O SRTP resolve isso com HMAC-SHA1 (Código de Autenticação de Mensagem baseado em Hash usando SHA-1). Para cada pacote, o SRTP calcula um HMAC sobre o cabeçalho RTP e a carga útil criptografada, e então trunca o resultado para 80 bits ou 32 bits. Essa tag de autenticação é anexada ao pacote. O receptor recalcula o HMAC de forma independente e compara. Se as tags não coincidirem, o pacote é descartado.
Isso protege contra modificação de pacotes e injeção de pacotes. Um invasor não pode forjar uma tag de autenticação válida sem a chave secreta.

Proteção contra replay

O SRTP mantém uma lista de replay (uma janela deslizante de números de sequência de pacotes recentemente recebidos). Se um pacote chega com um número de sequência que já foi visto, ou que está fora da janela aceitável, o pacote é descartado. Isso impede que um invasor grave pacotes criptografados e os retransmita para interromper ou confundir uma chamada.

Derivação de chaves e troca de chaves

O SRTP usa uma função de derivação de chaves (KDF) para gerar múltiplas chaves de sessão a partir de uma única chave mestra. A chave mestra produz chaves de criptografia, chaves de autenticação e chaves de salting separadas tanto para o fluxo SRTP quanto para seu fluxo companheiro SRTCP (Secure RTCP). Isso significa que o protocolo de gerenciamento de chaves precisa entregar apenas uma chave mestra por sessão.
A chave mestra em si é trocada durante a configuração da chamada, por meio da camada de sinalização SIP. Dois mecanismos são comuns:
SDES (Session Description Protocol Security Descriptions) incorpora a chave mestra diretamente no corpo SDP das mensagens SIP INVITE e 200 OK, dentro de um atributo crypto. Essa é a abordagem mais simples e é amplamente usada quando a sinalização SIP em si é criptografada com TLS. Sem TLS, o SDES expõe a chave mestra em sinalização de texto em claro, o que anula o propósito.
DTLS-SRTP (Datagram Transport Layer Security para SRTP) realiza um handshake DTLS diretamente no caminho de mídia para estabelecer chaves. Isso é mais robusto porque a troca de chaves não depende da criptografia na camada de sinalização. O DTLS-SRTP é obrigatório para WebRTC e está sendo cada vez mais adotado em VoIP empresarial.

SRTP vs. RTP: o que muda?

O overhead de largura de banda de ~2% vem da tag de autenticação anexada a cada pacote (4-10 bytes dependendo da configuração) e do campo opcional Master Key Identifier (MKI). Para uma chamada G.711 usando pacotização de 20ms, isso se traduz em aproximadamente 1,6 kbps de largura de banda adicional por direção. Na prática, isso é imperceptível.
O SRTP foi projetado especificamente para adicionar segurança sem degradar o desempenho em tempo real. Ele reutiliza o mesmo transporte UDP, as mesmas alocações de portas e a mesma estrutura de cabeçalho RTP. Infraestrutura de rede que roteia tráfego RTP roteará tráfego SRTP de forma idêntica.

TLS + SRTP: segurança VoIP completa

Um equívoco comum é que TLS na sinalização SIP, por si só, protege o VoIP. Não protege. Uma chamada VoIP possui dois fluxos de dados distintos, cada um exigindo sua própria proteção:
Sinalização (SIP) abrange as mensagens SIP que configuram, modificam e encerram chamadas. Essas contêm números chamados/chamadores, endereços IP, SDP com informações de codec e chaves, e metadados de roteamento. A sinalização SIP é criptografada com TLS (Transport Layer Security), normalmente na porta 5061.
Mídia (RTP/SRTP) consiste nos pacotes reais de voz ou vídeo. Esses são criptografados com SRTP em portas UDP negociadas dinamicamente.
Se você criptografa a sinalização com TLS mas deixa a mídia como RTP simples, um invasor não pode ver quem ligou para quem, mas ainda pode capturar e ouvir a conversa. Por outro lado, se você criptografa a mídia com SRTP mas envia SIP em texto aberto, um invasor pode ver a troca de chaves SDES e descriptografar a mídia de qualquer forma.
Ambas as camadas devem ser criptografadas juntas. O TLS protege a sinalização. O SRTP protege a mídia. E o dispositivo que aplica ambas na fronteira da rede é o Controlador de Borda de Sessão.

O papel do SBC no SRTP

Na maioria das implantações VoIP do mundo real, o SBC fica na borda da rede entre sua infraestrutura de voz interna e redes externas: provedores de troncos SIP, Microsoft Teams, usuários remotos ou parceiros de peering. O SBC é onde a política de criptografia é aplicada.
Um SBC operando como um Agente de Usuário Back-to-Back (B2BUA) encerra e re-origina completamente tanto a sinalização quanto a mídia em cada lado da conexão. Essa arquitetura lhe dá três capacidades críticas para a implantação de SRTP:

Relay SRTP

Quando ambos os lados de uma chamada suportam SRTP, o SBC retransmite mídia criptografada entre eles. O SBC negocia os parâmetros criptográficos (conjunto de cifras, chaves) de forma independente em cada perna, descriptografa o SRTP de entrada e o re-criptografa para a perna de saída. Isso mantém a criptografia enquanto ainda permite que o SBC aplique políticas de mídia, realize normalização SIP e gere registros detalhados de chamadas.

Conversão RTP-para-SRTP

Aqui é onde o SBC se torna essencial para ambientes mistos. Muitos IP-PBXs legados, telefones SIP mais antigos e alguns provedores de troncos SIP suportam apenas RTP simples. Plataformas modernas como Microsoft Teams e aplicações WebRTC exigem SRTP.
O SBC faz a ponte aceitando RTP simples do lado legado, criptografando-o em SRTP e encaminhando-o para o destino que exige SRTP. No caminho de retorno, o SBC descriptografa o SRTP de volta para RTP simples para o terminal legado. O equipamento legado nunca precisa ser alterado.
Essa conversão RTP-para-SRTP é o que permite que organizações conectem infraestrutura de voz existente ao Teams Direct Routing, centrais de atendimento na nuvem e outras plataformas que exigem criptografia, sem substituir hardware ou retreinar equipes.

Ocultação de topologia com contexto de criptografia

O SBC oculta endereços IP da rede interna de partes externas. Combinado com SRTP, isso significa que entidades externas não veem nem a topologia da rede interna nem o conteúdo de mídia. O SBC apresenta seus próprios endereços IP para o mundo externo e gerencia contextos criptográficos SRTP separados para cada perna da chamada.

Quando você precisa de SRTP?

A resposta curta: sempre, quando viável. A criptografia de mídia tem custo de desempenho insignificante e benefício de segurança significativo. Porém, certos cenários a tornam obrigatória, não apenas recomendada.
Microsoft Teams Direct Routing exige SRTP para toda a mídia. Se o seu SBC não suporta negociação SRTP e conversão RTP-para-SRTP, as chamadas do Teams falharão.
Aplicações WebRTC usam DTLS-SRTP. Se você está integrando comunicação baseada em navegador com sua rede de voz, o SRTP não é opcional.
Saúde (HIPAA) trata chamadas de voz que transportam informações de pacientes como ePHI em trânsito. O SRTP fornece a camada de criptografia necessária para atender aos requisitos de segurança de transmissão da Regra de Segurança do HIPAA.
Serviços financeiros (PCI DSS) exige criptografia para dados de cartões de pagamento, incluindo números de cartão falados por VoIP. O SRTP protege a perna de mídia.
Trabalhadores remotos e híbridos representam um ponto de exposição crescente. Quando o tráfego VoIP sai da rede corporativa e atravessa a internet pública para alcançar funcionários remotos, a criptografia previne interceptação em segmentos de rede não controlados. SBCs com suporte a SIP/TLS e SRTP protegem essas conexões na borda de acesso.
Qualquer tráfego que cruza a internet pública deve ser criptografado. Se pacotes de voz atravessam qualquer segmento de rede que você não controla fisicamente, a criptografia é uma medida de segurança básica.

Equívocos comuns sobre SRTP

SRTP substitui TLS é uma suposição comum, mas incorreta. O SRTP criptografa a mídia. O TLS criptografa a sinalização. Eles protegem fluxos de dados diferentes e ambos são necessários para segurança VoIP completa. Sem TLS, a troca de chaves SDES na sinalização SIP expõe a chave mestra SRTP em texto em claro.
SRTP adiciona latência significativa é outro equívoco. O AES Counter Mode é uma cifra de fluxo que processa cada pacote de forma independente, sem exigir feedback de pacotes anteriores. Pesquisas mostram aproximadamente 2% de overhead de largura de banda com impacto de latência insignificante. Não há degradação perceptível de qualidade.
Todos os equipamentos VoIP suportam SRTP não é o caso. Muitos IP-PBXs legados, adaptadores de telefone analógico e telefones SIP mais antigos suportam apenas RTP simples. Um SBC com capacidade de conversão RTP-para-SRTP faz a ponte sem exigir substituição de equipamentos.
SRTP fornece criptografia de ponta a ponta é tecnicamente possível, mas incomum. Na maioria das implantações empresariais, o SRTP opera hop-a-hop. O SBC descriptografa e re-criptografa a mídia na fronteira da rede. Isso permite que o SBC aplique políticas de segurança, gere CDRs e realize operações de mídia. A criptografia verdadeiramente de ponta a ponta (onde apenas os dois terminais possuem as chaves) é rara em VoIP de produção porque impede todo processamento intermediário.

Começando com SRTP

Implantar SRTP em toda a sua rede VoIP é um processo de quatro etapas:

1. Audite seu status atual de criptografiaIdentifique quais troncos, terminais e plataformas usam atualmente RTP versus SRTP. Observe quais conexões cruzam a internet pública e quais permanecem dentro da sua rede controlada. Priorize conexões voltadas para a internet e sensíveis a conformidade.
2. Ative TLS na sinalização SIPA troca de chaves SRTP via SDES depende de TLS para proteger a chave mestra em trânsito. Configure TLS no seu SBC para todas as conexões SIP, começando pelos troncos voltados para a internet. Use a porta 5061 (a porta padrão SIP-sobre-TLS).
3. Configure SRTP no seu SBCAtive SRTP para cada grupo de troncos ou Ponto de Acesso de Rede. Para ambientes mistos, configure o SBC para realizar conversão RTP-para-SRTP para que terminais legados possam se conectar a plataformas que exigem SRTP sem modificação.
4. Verifique com captura de pacotesUse o Wireshark ou as ferramentas de captura integradas do seu SBC para confirmar que os pacotes de mídia em troncos com SRTP habilitado estão criptografados. Verifique se a conversão RTP-para-SRTP está funcionando corretamente em pernas mistas. Confirme que o SRTCP também está criptografado junto com o SRTP.

SRTP no contexto mais amplo da segurança VoIP

O SRTP é uma camada em uma abordagem de defesa em profundidade para segurança VoIP. Uma rede de voz reforçada combina:

• SRTP para criptografia de mídia
• TLS para criptografia de sinalização
• SBC com arquitetura B2BUA para ocultação de topologia, controle de acesso e aplicação de criptografia
• Proteção DoS/DDoS no SBC para mitigar ataques de inundação SIP
• Lista negra dinâmica e listas de controle de acesso de chamadas para bloquear tráfego malicioso
• STIR/SHAKEN para autenticação de identidade do chamador

Cada camada aborda um vetor de ameaça diferente. O SRTP aborda especificamente a confidencialidade e integridade de mídia de voz e vídeo em trânsito. Combinado com as outras camadas, ele faz parte de uma postura de segurança VoIP abrangente.

Perguntas frequentes

Conclusão

O SRTP estende o RTP com criptografia AES, autenticação HMAC-SHA1 e proteção contra replay. Ele adiciona aproximadamente 2% de overhead de largura de banda com impacto de latência insignificante. TLS e SRTP juntos fornecem segurança VoIP completa: TLS para sinalização, SRTP para mídia.
O SBC é o ponto de aplicação. Ele negocia parâmetros SRTP, converte RTP para SRTP para terminais legados e mantém contextos de criptografia separados em cada perna da chamada. Para organizações que se conectam ao Microsoft Teams, plataformas WebRTC ou qualquer serviço que exija SRTP, um SBC com capacidade de conversão RTP-para-SRTP é a ponte entre a infraestrutura existente e os requisitos modernos de segurança.