Entenda o que é SRTP, como protege RTP e RTCP, sua relação com TLS e RTSPS e como o suporte a SRTP aparece nas especificações ONVIF atuais.

Confira!

O SRTP — Secure Real-time Transport Protocol é um perfil de segurança para RTP criado para proteger mídia em tempo real. Ele adiciona mecanismos de confidencialidade, autenticação de mensagens e proteção contra replay aos fluxos RTP e também define a proteção correspondente para RTCP, conhecida como SRTCP.

O que é o protocolo SRTP

O SRTP foi definido no RFC 3711 como um perfil do RTP. Isso significa que ele preserva a arquitetura e grande parte da estrutura operacional do RTP, mas acrescenta processamento criptográfico para proteger a mídia e o tráfego de controle associado.

Essa distinção é fundamental em sistemas de vídeo IP. RTP organiza a entrega temporal da mídia; SRTP protege essa entrega contra leitura não autorizada, adulteração e repetição maliciosa de pacotes.

O que o SRTP protege

O SRTP foi projetado para oferecer confidencialidade, autenticação de mensagem e proteção contra replay. A confidencialidade impede que um observador leia diretamente a carga útil protegida. A autenticação permite verificar se os pacotes foram alterados ou forjados. A proteção contra replay ajuda a rejeitar pacotes antigos capturados e reenviados por um atacante.

Essas propriedades são aplicadas com baixo overhead para preservar características necessárias a aplicações de tempo real.

SRTP e SRTCP

O ecossistema definido pelo RFC 3711 não protege apenas RTP. O tráfego RTCP associado pode ser protegido por SRTCP — Secure RTCP.

Isso é importante porque RTCP carrega informações de controle, identificação e qualidade da sessão. Proteger apenas a carga de vídeo e deixar o canal de controle exposto pode preservar confidencialidade da mídia, mas ainda revelar ou permitir manipulação de informações operacionais relevantes.

Como o SRTP funciona

Cada contexto SRTP mantém informações criptográficas associadas à fonte e à sequência dos pacotes. O protocolo utiliza números de sequência RTP combinados com um contador de rollover para formar um índice de pacote ampliado, usado na derivação e aplicação dos mecanismos de segurança.

A carga útil RTP pode ser cifrada, enquanto campos necessários ao encaminhamento e processamento básico permanecem disponíveis conforme definido pelo perfil. Tags de autenticação e mecanismos de replay permitem ao receptor validar cada pacote recebido.

A proteção precisa ser compatível com a natureza de tempo real do tráfego: o protocolo não pode introduzir a mesma lógica de retransmissão e ordenação obrigatória de um transporte confiável como TCP.

O SRTP negocia as chaves?

Não. SRTP não define sozinho um mecanismo completo de troca de chaves. O RFC 3711 pressupõe que os endpoints obtenham os parâmetros criptográficos por algum mecanismo externo apropriado.

Essa é uma das diferenças mais importantes entre “usar SRTP” e “ter uma arquitetura segura”. O sistema também precisa estabelecer como chaves, perfis criptográficos e parâmetros de sessão serão autenticados e distribuídos.

Dependendo da aplicação, diferentes mecanismos podem cumprir essa função. Em um ambiente ONVIF, a forma de configuração e negociação depende da versão das especificações e capabilities suportadas.

SRTP versus RTP

CaracterísticaRTPSRTP
Transporte de mídia em tempo realSimSim
ConfidencialidadeNãoSim
Autenticação de mensagemNãoSim
Proteção contra replayNãoSim
Proteção de RTCPRTCP sem criptografia inerenteSRTCP
RFC-baseRFC 3550RFC 3711

SRTP não substitui RTP por uma arquitetura totalmente distinta; ele acrescenta segurança à comunicação RTP/RTCP.

SRTP versus TLS

TLS e SRTP resolvem problemas de segurança em camadas e fluxos diferentes. TLS cria um canal seguro para uma comunicação orientada a sessão, como HTTPS ou RTSPS. SRTP foi desenhado especificamente para proteger pacotes de mídia RTP e controle RTCP em tempo real.

Por isso, habilitar HTTPS em uma câmera não significa automaticamente que o vídeo RTP está cifrado. Da mesma forma, utilizar SRTP não significa que a interface web ou os serviços de gerenciamento estejam protegidos por HTTPS.

Uma arquitetura completa pode empregar os dois mecanismos simultaneamente.

SRTP e RTSPS

RTSPS protege a sessão RTSP utilizando TLS. SRTP protege os pacotes RTP/SRTCP que carregam mídia e controle.

Em uma sessão segura moderna, o canal de controle pode utilizar RTSPS enquanto a mídia utiliza SRTP. Essa combinação evidencia por que a expressão genérica “Secure Streaming” é insuficiente para uma especificação técnica: é necessário informar qual parte do fluxo está protegida e por qual mecanismo.

SRTP no ONVIF

O suporte a SRTP tornou-se explicitamente mais relevante nas especificações ONVIF recentes. Na versão de especificações v26.06, publicada em junho de 2026, o ONVIF registrou a inclusão de configuração de SRTP na Core Specification e suporte a SRTP nas especificações de Streaming.

Além disso, serviços de mídia ONVIF modernos distinguem capabilities de streaming RTSP convencional e de Secure RTSP Streaming, associando o modo seguro a RTSPS e SRTP quando suportado.

Isso significa que a simples conformidade ONVIF não basta para presumir SRTP. É necessário verificar o Profile ou Add-on aplicável, a versão da especificação e as capabilities declaradas pelo dispositivo e pelo cliente.

Secure Streaming no ONVIF

A expressão Secure Streaming pode representar mais de um mecanismo dependendo da versão e do contexto da especificação. Um fluxo pode envolver HTTPS para determinados serviços ou túneis, TLS para proteger um canal RTSP e SRTP para proteger a mídia.

Portanto, a pergunta tecnicamente correta não é apenas “o equipamento suporta Secure Streaming?”, mas sim:

  • o controle RTSP utiliza TLS ou RTSPS?
  • a mídia utiliza RTP ou SRTP?
  • o RTCP está protegido por SRTCP?
  • como as chaves e certificados são gerenciados?
  • quais capabilities ONVIF são anunciadas e testadas?

Essa decomposição elimina ambiguidades que o termo comercial ou genérico não resolve.

SRTP e desempenho

A proteção criptográfica acrescenta processamento e algum overhead por pacote, mas o protocolo foi concebido para aplicações de tempo real e para preservar baixa expansão de pacote.

Em projetos com grande número de câmeras, o impacto deve ser avaliado na capacidade criptográfica dos endpoints, servidores, VMS e appliances intermediários. A análise não deve considerar apenas largura de banda, mas também taxa de pacotes, número de streams simultâneos e recursos de hardware para criptografia.

O que verificar em um projeto com SRTP

Além de confirmar o suporte declarado, a engenharia deve verificar interoperabilidade entre câmera e cliente, suites ou transformações criptográficas aceitas, método de provisionamento das chaves, proteção do RTCP, comportamento em unicast e multicast, impacto de NAT e firewall e evidências de que o stream capturado está efetivamente protegido.

Em um teste de aceitação, não basta observar que o vídeo abre. A validação deve comprovar que a sessão negociou o modo seguro esperado e que a mídia não está trafegando como RTP em claro.

Referências técnicas

[1] BAUGHER, M. et al. RFC 3711: The Secure Real-time Transport Protocol (SRTP). RFC Editor, 2004.

[2] IETF. RFC 9335: Completely Encrypting RTP Header Extensions and Contributing Sources. RFC Editor, 2023.

[3] ONVIF. Specification History — June 2026: v26.06.

Perguntas frequentes
O que é SRTP?

SRTP é um perfil de segurança para RTP que acrescenta confidencialidade, autenticação de mensagem e proteção contra replay à mídia em tempo real.

Qual RFC define SRTP?

A especificação-base é o RFC 3711, atualizado por RFCs posteriores.

SRTP e TLS são a mesma coisa?

Não. TLS protege canais de comunicação como HTTPS ou RTSPS; SRTP é específico para proteger mídia RTP e controle RTCP em tempo real.

SRTP negocia suas próprias chaves?

Não. O SRTP pressupõe que parâmetros criptográficos e chaves sejam estabelecidos por um mecanismo externo apropriado.

ONVIF suporta SRTP?

Sim. As especificações ONVIF v26.06, de junho de 2026, adicionaram configuração de SRTP à Core Specification e suporte a SRTP nas especificações de Streaming.

Materiais técnicos complementares

None