Uma chamada segura tem mais de um percurso de dados. A sinalização coordena quem está a ligar e como os pontos terminais se ligam; o percurso multimédia transporta áudio e vídeo. Proteger um percurso não protege automaticamente o outro, e nenhum deles, isoladamente, oculta todos os padrões de comunicação.
O WebRTC fornece mecanismos de segurança importantes, mas as verificações de identidade da aplicação, as funções dos servidores e o modo de gravação continuam a determinar todos os limites de privacidade.
Sinalização e multimédia têm funções diferentes
| Camada | Finalidade habitual | Questão de segurança |
|---|---|---|
| Sinalização | Convites, descrições de sessão e candidatos de ligação | Quem pode ler ou alterar as informações de estabelecimento e como é autenticado o interlocutor pretendido? |
| Multimédia | Áudio, vídeo e fluxos relacionados em tempo real | Onde termina a encriptação e que pontos terminais podem aceder ao conteúdo multimédia? |
| Registos operacionais | Encaminhamento, tempos de ligação e estado de entrega | Que metadados pode o serviço ou a rede observar? |
| Gravação | Produzir uma cópia que será conservada | Quem recebe texto em claro ou chaves de gravação utilizáveis e onde é guardada a cópia? |
Um protocolo de mensagens pode transportar sinalização encriptada, mas o WebRTC não exige universalmente o formato de envelope de um serviço de mensagens específico. São possíveis outras conceções autenticadas.
O que o DTLS-SRTP fornece
A Arquitetura de Segurança do WebRTC, RFC 8827, exige proteção dos canais multimédia e descreve o estabelecimento de chaves DTLS-SRTP. Simplificando, o DTLS ajuda a estabelecer o contexto criptográfico e o SRTP protege os pacotes multimédia em tempo real.
Os pontos terminais dessa proteção importam. Uma ligação encriptada direta entre participantes é diferente de uma ligação que termina num servidor de processamento multimédia. Alguns sistemas multiparticipante acrescentam uma camada ponta a ponta separada sobre a encriptação de transporte voltada para o servidor. A palavra «WebRTC», por si só, não indica que arquitetura um produto usa.
Por que importa autenticar a sinalização
O estabelecimento de uma chamada pode conter informações usadas para associar a ligação multimédia à pessoa pretendida. Se um atacante puder substituir essas informações sem ser detetado, a encriptação pode estabelecer uma ligação protegida ao ponto terminal errado.
O RFC 8827 discute esta relação entre sinalização, identidades e impressões digitais DTLS. O HTTPS protege uma ligação ao serviço de sinalização; por si só, não elimina a necessidade de considerar um serviço malicioso ou comprometido. Sinalização autenticada ponta a ponta ou um mecanismo adequado de verificação independente do interlocutor podem reforçar esse limite.
A confidencialidade da sinalização é um objetivo relacionado, mas diferente: limita quem pode ler os detalhes de estabelecimento. Uma conceção deve explicar tanto a confidencialidade como a autenticação, em vez de tratar um bloco encriptado como prova suficiente de ambas.
Sinalização encriptada não torna uma chamada invisível
O retransmissor pode continuar a saber entre que contas ou dispositivos encaminha dados. Observadores da rede podem ver os tempos de ligação, o volume de tráfego e os endereços dos servidores. Os interlocutores ou a infraestrutura de retransmissão também podem conhecer informações de rede, dependendo da conceção da ligação.
Assim, encriptar um convite de chamada não prova que o serviço não possa inferir uma chamada, mapear relações ou conservar registos relacionados com chamadas. Ocultar conteúdo e ocultar padrões de tráfego são problemas distintos.
Os limites publicados pelo Livara
A página de segurança do Livara descreve chamadas diretas e de grupo como encriptadas ponta a ponta, mas estabelece uma exceção explícita para a gravação opcional no servidor: enquanto o estado visível REC está ativo, a chamada usa encriptação de transporte em vez de E2EE.
O seu modelo de ameaças também rejeita alegações de anonimato dos metadados e de proteção contra um dispositivo comprometido. São declarações do produto, não uma verificação independente de cada percurso de chamada. Este guia não afirma um limite de participantes não verificado, um formato de sinalização ou uma implementação multimédia pós-quântica.
Em particular, uma troca de chaves pós-quântica do serviço de mensagens não atualiza automaticamente um estabelecimento de ligação multimédia WebRTC separado. Os algoritmos e a vinculação das chaves no percurso multimédia têm de ser avaliados de forma independente.
Antes de uma chamada sensível
- Confirme os participantes e analise alterações inesperadas de identidade.
- Verifique se a gravação está ativada e o que a aplicação diz que isso altera.
- Perceba se o serviço processa conteúdo multimédia ou apenas encaminha pacotes protegidos.
- Considere os dispositivos e as salas dos participantes: malware, captura de ecrã ou alguém por perto a ouvir podem expor o conteúdo após a desencriptação.
- Peça arquitetura e provas de testes para o modo exato que usa, em vez de confiar num selo genérico de «chamadas encriptadas».
Uma alegação de segurança útil identifica separadamente quem pode aceder à sinalização, ao conteúdo multimédia, aos metadados e às gravações.
