Teste de performance, criptografando SIP e RTP

Celso Luiz Annes Junior¹, Luiz Augusto Dias Knob²

¹Aluno do Curso de Pós-Graduação em Especialização em Segurança da Informação e Gestão de
Riscos – Faculdade Meridional IMED-PF-RS.
e-mail: contato@celsoannes.com.br
²Professor do Curso de SI – Faculdade Meridional IMED-PF-RS
e-mail: luiz.knob@imed.edu.br

Resumo: Este artigo busca avaliar a desempenho de ligações VoIP com utilização de criptografia
nos protocolos SIP e RTP. Segurança e privacidade são uma constante preocupação, com o passar
do tempo novas tecnologias surgem onde hardware e software recebem melhorias com isso é
possível obter melhor qualidade de voz e segurança com baixo consumo de recursos de
hardware.Durante a análise será observado à qualidade de voz e comparado o hardware exigido
durante ligações normais e criptografadas.
Palavras-chave: VoIP; Asterisk; TLS; SRTP; Criptografia.

Abstract: Thisarticlesearch for evaluatetheperformance os the VoIP callsusingencryptprotocolon

SIP and RTP.Security andprivacythey are a persistentconcern, in thecourseof time new
technologies emerge where hardware and software
receiveimprovementswiththisispossibleacquirebetterqualityofvoiceandsecuritywithlow consume
ofthe hardware resources.
Throughtheanalysiswillbepossibletoseethequalityofvoicecomparingtheloudconsumingonthe
hardware between normal VoIP callsandencrypt VoIP calls.
Keywords: VoIP; Asterisk; TLS; SRTP; Encryption.

1. INTRODUÇÃO
As centrais telefônicas de arquitetura fechada não tiveram grandes avanços. As centrais
telefônicas convencionais podem ter suas chamadas interceptadas, ouvidas e gravadas sem
necessidade que o atacante tenha um conhecimento avançado para fazê-lo, este tipo de ataque pode
ser feito dentro de sua própria estrutura ou nos postes e armários existentes na rua por onde passam
os fios que interligam clientes com operadoras de telefonia, sem que as vítimas de escutas
telefônicas fiquem sabendo desta intrusão.
Ligações VoIP também podem ser vitima de interceptação, porem é necessário um
conhecimento avançado de redes, invadindo servidores que geralmente possuem mecanismos de
segurança que impedem este tipo de ataque e geram alertas aos administradores ou acesso direto a
rede física local.
Como muitas empresas de grande porte possuem suas filiais espalhadas pelo mundo o
melhor custo beneficio de manter a comunicação interligada é a utilização do VoIP, permitindo a
ligação entre unidades de maneira simplificada e sem gerar custos.Muitas destas empresas devem
seu sucesso ao seu segredo que deve ser mantido apenas dentro das empresas e controlado por
poucos e é uma preocupação tratar qualquer assunto por telefone, pela fragilidade existente na
telefonia.
A implantação de mecanismos de segurança para dados de voz pode ser considerada um
desafio, manter a qualidade de voz e garantir a confiabilidade dos pacotes através de criptografia vai
precisar de um bom casamento entre hardware com bom processamento da informação e um
software capaz de proporcionar um método de criptografia eficiente.
Para este artigo será realizado uma analise de desempenho utilizando os protocolos TLS e
SRTP que fornecem criptografia no SIP e RTP. O TLS e SRTP são nativos do Asterisk não sendo
necessários softwares adicionais, outra vantagem é que a utilização dos protocolos em conjunto
fornece uma segurança ponta a ponta onde à criptografia ocorre durante todo o percurso, utilizando
clientes que suportem estes protocolos será possível fazer um comparativo de desempenho entre
ligações criptografadas e não criptografadas.

2. CONTEXTUALIZAÇÃO

2.1. O que é VoIP

O Voice over IP (VoIP), é um serviço que consiste em transmitir a voz através do protocolo
IP (Internet Protocol). Basicamente o que ocorre é que o som da voz é transformada por telefones
ou softphones de analógica para sinais digitais dentro de pacote de dados que podem ser enviadas
pela internet através do mundo que chegando ao seu destinatário esses pacotes de dados são
reordenados e transformados novamente em voz de forma analógica(Colcher, 2005).
A maior vantagem do VoIP sobre a telefonia convencional é o custo e a implementação de
diversas funcionalidades, chamadas VoIP saem mais em conta que operadoras tradicionais,
enquanto uma ligação convencional precisa de uma rede exclusiva para fazer uma chamada, no
VoIP pode-se fazer varias chamadas simultânea utilizando o mesmo canal de acesso.
Os meios mais comuns para fazer ligações VoIP são utilizando telefones convencionais
através de um adaptador para telefones analógicos (ATA), telefones IPs que são telefones digitais

2
com tecnologia embarcada necessária para se comunicar com servidores VoIP e já disponibilizam
interface para conexão a rede e Softphones, programas disponíveis para computadores, smartphones
e tablets, independente do dispositivo utilizado, todos podem se comunicar entre eles.
A qualidade da ligação esta ligada a dois fatores, um ligado ao meio de transmissão e outro a
tradução entre codecs. O VoIPcomumente é utilizado sobre UDP e RTP.
O UDP(UserDatagramProtocol) é o protocolo irmão do TCP
(TransmissionControlProtocol). A diferença básica entre os dois é que o TCP é um protocolo
orientado à conexão, que inclui vários mecanismos para iniciar e encerrar a conexão, negociar
tamanhos de pacotes e permitir a retransmissão de pacotes corrompidos.No UDP não existe
checagem de nada, nem confirmação alguma. Os dados são transmitidos apenas uma vez, incluindo
apenas um frágil sistema de CRC. Os pacotes que cheguem corrompidos são simplesmente
descartados, sem que o emissor sequer saiba do problema (Carlos E. Morimoto, 2005).
O RTP(Real-time TransportProtocol) determina um formato de pacote padrãopara o
transporte de rede adequado para aplicações de transmissão de dados em tempo real fim-a-fim como
áudio, vídeo e dados pela Internet. O RTP não aborda reserva de recursos e não garante a qualidade
de serviço para serviços em tempo real (RFC1889, 1996).
Caso uma rede esteja congestionada alguns pacotes podem ser perdidos, apesar de existirem
algoritmos de compensação e correção, a ligação pode apresentar picotes e falhas. Onde o hardware
não tenha sido bem dimensionado ou o número de traduções entre codecs diferentes seja muito
grande pode gerar uma sobrecarga no processador e as ligações podem acabar gerando atraso
(delay) deixando as ligaçõesconfusas e cansativas.

2.2. Protocolos de Segurança

Durante as pesquisas feitas em artigo e monografias publicadas foram encontrados
diferentes soluções para criptografar e aumentar a segurança de uma ligação VoIP, cada uma delas
com seu nível de segurança, finalidade e aplicação diferente, podendo solucionar o problema em
diferentes cenários.
SIP Digest é um mecanismo de autenticação básico, trazido do HTTP, que deve ser
suportado por qualquer user agent SIP. É uma forma simples de servidor e cliente verificarem se
efetivamente tem um segredo compartilhado sem que a senha trafegue abertamente (RFC Draft,
2009).

3
 Transport Layer Security (TLS) prove criptografia para sinalização de chamada. É um meio
pratico de prevenir que intermediários modifiquem tenham acesso ou falsifiquem os pacotes de voz
que estão sendo transmitidos (RFC 2246, 1999).
IP Security (IPSec) fornece criptografia no nível de rede para proteger um canal de
comunicação entre dois sistemas finais diretamente conectados ou entre dois sistemas
intermediários. O IPSec funciona autenticando e criptografando os pacotes IP e precisa de um
protocolo adicional para troca de chaves (RFC 6071, 2011).
Secure Real-time Transport Protocol (SRTP) e o Real-time Control Protocol (SRTCP)
oferecem integridade, autenticidade e proteção contra replays (retransmissão fraudulenta) dos
pacotes RTP e RTCP prevenindo ataques como escuta do RTP, manipulações do SSRC,
manipulações do CODEC e inserções RTCP (RFC 3711, 2004).
Network Asserted Identity é um mecanismo bastante específico para a troca de identidade
entre elementos de rede que já possuam relacionamento confiável utilizando algum outro
mecanismo ou política de segurança inicialmente obtido por um SIP (RFC 3324, 2002).
Authenticated Identity Body (AIB) é um mecanismo que utiliza corpos de mensagens e
certificados S/MIME para assinar parte do cabeçalho das mensagens de forma a autenticar o user
agent, dessa forma evitando ataques do tipo spoofing (RFC 3893, 2004).
Identity Header Field é outro mecanismo que também permite assinar parte dos cabeçalhos
da mensagem. A diferença é que este mecanismo utiliza cabeçalhos padrão específicos para a
assinatura e para o acesso ao certificado, o que resolve alguns dos problemas associados à utilização
do padrão S/MIME (RFC 3325, 2002).
Mesmo com esta grande variedade de mecanismos de segurança, cada um deles apresentam
uma fraqueza, sendo deixando pontos desprotegidos ou expostos, alguns apresentando
incompatibilidade quando a rede possui NAT (Network Address Translation), outros precisam de
uma rede composta de equipamentos que suportem o encaminhamento de sinalização entre outros
problemas conhecidos.
Considerando a documentação existente, trabalhos já publicados e necessidade de segurança
ponto a ponto foramescolhidos o TLS e SRTP estes protocolos trabalham nas camadas de aplicação
e transporte, sendo suportados pelo servidor e clientes e não possuem a necessidade de aplicação de
segurança na camada de rede, podendo os pacotes de voz ser transmitidos tanto na rede local quanto
na rede publica sem preocupações.

4
 2.2.1. O Protocolo TLS
Os objetivos deste protocolo são a segurança por meio de criptografia, a interoperabilidade, a
extensibilidade e a eficiência (RFC 2246, 1999).Ele é capaz de estabelecer uma conexão segura
entre as duas pontas e garantir que os dois aplicativos consigam se comunicar e trocar parâmetros
independente da forma que foram construídos. Ele é capaz de abarcar futuras extensões, diminuindo
a necessidade de se criar um novo protocolo e uma nova biblioteca de segurança. Estes últimos dois
pontos são muito importantes, já que a criação de um protocolo ou de métodos de segurança podem
trazer novas falhas.

A eficiência do protocolo vem do número reduzido de conexões necessárias, uma vez que é
utilizado cache para guardar certas informações, poupando também tempo de processamento.
O TLS prove essencialmente três serviços criptografia, autenticação e integridade de dados.
A criptografia ofusca os dados, autenticação provê um mecanismo para verificar a identidade dos
membros do grupo e a integridade prove um mecanismo que detecta se a mensagem sofreu alguma
alteração.
O TLS pode ser unilateral ou bilateral, sendo quando apenas um dos lados é autenticado e o
outro permanece anônimo ou os dois lados cliente e servidor possuem um certificado de
autenticidade.
Ao estabelecer uma conexão TLS, cliente e servidor trocam chaves, desta forma ambos os
lados sabem como criptografar ou descriptografar as mensagens. Podem ser usadas chaves
simétricas ou chaves assimétricas no processo de autenticação dos participantes.
O protocolo TLS se situa entre as camadas de aplicação e transporte. Ele encapsula os
protocolos de aplicação como o HTTP (Hypertext Transfer Protocol) e o FTP (File Transfer
Protocol) e trabalha em cima de um protocolo de transporte como o TCP (Transmission Control
Protocol) e UDP (User Datagram Protocol). Para que a transmissão seja confiável, deve ser
utilizado o protocolo TCP uma vez que o UDP esta sujeito a perdas por não garantir a entrega dos
pacotes.

Aplicação (HTTP,FTP, etc)

Sessão (TLS)
Transporte (TCP, UDP)
Rede
Figura 1 - Posicionamento do TLS, em meio às demais camadas.

O protocolo TLS é composto também de duas camadas, formadas por dois tipos de
protocolos: os protocolos de Handshaking e o protocolo de registro (RFC 2246, 1999).

5
 Handshake Protocol ChangeCipcherSpec Alert Protocol
Application Protocol
Protocol
Record Protocol
Figura 2 - Protocolo TLS e seus subprotocolos.

2.2.2. O Protocolo SRTP

O RTP (Real-time Transport Protocol) foi projetado para transmitir dados entre aplicações
através da camada de transporte de maneira organizada, para que o receptor da mensagem consiga
reproduzir na sequencia e tempo adequado, desta maneira é possível fazer uma comunicação de
áudio ou vídeo em tempo real.
O SRTP é uma extensão de segurança para o RTP que oferece confidencialidade,
integridade e autenticação para chamadas de áudio e vídeo. O perfil de segurança foi projetado para
existir entre a aplicação do RTP e por baixo das camadas de transporte.
Durante o processo de autenticação o remetente anexa sua identificação ao pacote. O
receptor SRTP recebe e verifica a mensagem/identidade de autenticação gerando uma nova
identidade de autenticação usando os algoritmos e chaves selecionados, depois disso compara a
identificação gerada com a recebida na mensagem. Caso as duas chaves sejam iguais então à
mensagem/identidade de autenticação é valida.

2.2.3. Qualidade das ligações

O maior problema do VoIP é como garantir que o trafego dos pacotes de voz ou outra
conexão de mídia não sofra atrasos ou seja descartada durante seu caminho, para determinar a
qualidade de uma ligação devem ser considerados os seguintes fatores:

 Latência –atraso na entrega dos pacotes irá causar eco nas ligações.
 Jitter – variações no atraso da entrega dos pacotes.
 Pacotes perdidos – muito trafego na rede pode causar a perda e o descarte de pacotes.

É quase impossível ter uma conversação quando existem grandes atrasos, durante a conversa
um acaba interrompendo o outro. Jitter causa sons e ruídos estranhos durante a ligação, mas que
podem ser corrigidos dependendo da tolerância de cada codec utilizado.
Perda de pacotes causa interrupções durante a ligação e esta perda de pacotes pode acabar
passando despercebido dependendo da quantidade de pacotes perdidos. Porem, se uma grande
quantidade for perdida haverá cortes na ligação.

6
3. DESENVOLVIMENTO
Para este artigo foi utilizado o Sistema Operacional Debian 7.8 e para servidor VoIP o
Asterisk 11, apesar de existir versões mais atuais tanto do Sistema Operacional quanto do Asterisk,
estes foram escolhidos por serem versões maduras e estáveis.
Os protocolos de segurança escolhidos foram o TLS e SRTP, pois são suportados
nativamente pelo Debian e Asterisk, sem a necessidade de adição de softwares de terceiros ou
suporte de hardware para que estes funcionem.
Tanto o TLS quando o SRTP podem ser utilizados separadamente para prover segurança nas
ligações, porem se utilizados separadamente cada umcorre um risco diferente devido as suas
vulnerabilidades conforme será demonstrado nas sessões3.5.1 e 3.5.2.
O SIP pode funcionar sobre três tipos de protocolo de transporte UDP por padrão, TCP ou
TLS que é a melhor opção. O protocolo UDP a pesar de um protocolo leve e rápido, ele não requer
handshake nem garante a entrega dos pacotes. O TLS possui todas as virtudes do TCP porem ele
possui criptografia.
A utilização do TLS permite que a sinalização fique segura, ninguém fica sabendo para que
número foidiscado, mas o áudio/vídeo não possui segurança, desta forma qualquer um pode
interceptar os pacotes RTP através da rede.
O SRTP é responsável apenas por criptografar o RTP, porem o RTP continuará sendo
transportado através do UDP, mas ambos os lados terão trocado chaves no SIP para habilitar a
criptografia. É possível utilizar SRTP independente do transporte usado no SIP, pois eles são
independente.
Apesar de existir segurança no SRTP, ele pode ser considerado uma segurança fraca já que
as chaves trocadas são trocadas em texto puro, qualquer um que estiver interceptando os pacotes
SIP terá a chave para descriptografar o SRTP. Portanto o SRTP realmente deve ser utilizado em
conjunto com o TLS.
Ativar o TLS e SRTP no Asterisk é relativamente simples, abaixo estarei exibindo os
comandos executados para a instalação e explicando qual a utilidade de cada um deles, deixando o
servidor pronto para os testes. Todos os comandos foram executados como super usuário.

3.1. Instalando o Asterisk

Para os testes foi definido o parâmetrodirectmedia igual àno, isso faz com que os pacotes de
mídia RTP (áudio/vídeo), passem obrigatoriamente pelo servidor, por padrão o Asterisk tenta
reenviar o convite de chamada entre as pontas, desta maneira o Asterisk fica fora do caminho e os

7
pacotes de mídia são trocados diretamente entre origem e destino desta
esta maneira o processamento
processam e
a rede do Servidor Asterisk são
ão poupados.

Figura 3 - Trafego dos pacotes RTP com o directmedia desativado..

Quando directmedia estiver como yes, o seu padrão,, o Asterisk só irá fazer o intermédio
caso os as pontas estejam utilizando codecs diferentes sendo necessária a conversão de um codec
para o outro, no caso do SRTP mesmo que ambos estejam utilizando os mesmos codecs a mídia
passará pelo Asterisk, pois ele que fará a criptografia dos pacotes para ambos os lados.

Figura 4 - Trafego dos pacotes RTP com o directmedia ativado.

3.2. Ativação do TLS e SRTP no SoftphonePhonerLite

Durante os testes foram utilizados os softphonesBlink,
softphonesBlink,PhonerLite e o SIP TRUNK. O SIP
TRUNK trata-se
se de uma interconexão entre servidores Asterisk, para este caso a sua aplicação visa
poder criar um ambiente em laboratório onde é possível manipular a quantidade de ligações feitas
simultaneamente.
Abaixo pode ser vista uma ligação utilizando TLS e SRTP onde o cadeado representa a
criptografia da mídia e a chave representa a criptografia da sinalização
sinalização,, tanto a imagem da chave
quanto a do cadeado só irão aparecer se os protocolos estiverem ativados.

8
 Figura 5 - SoftphonePhonerLite em uma ligação criptografada.

O mesmo pode ser observado no Blink, durante uma ligação o cadeado em azul representa a
criptografia do TLS e o cadeado em cinza a criptografia do SRTP, a imagem dos cadeados só irão
aparecer caso os protocolos estejam ativados.

Figura 6 - SoftphoneBlink em uma ligação criptografada.

9
3.3. Métricas utilizadas
Para os testes foram utilizados três servid
servidores
ores com Linux/Asterisk e dois desktops com
softphone, visando ter um real parâmetro de comparação foi definido que todo o trafego deveria
passar pelo servidor VoIP, somente desta maneira seria possível capturar os pacotes RTP para as
chamadas sem criptografia,
afia, assim podendo criar um referencialentre chamadas criptografadas e não
criptografadas.
Como todo o trafego de dados passará pelo servidor VoIP também é possível fazer uma
medida precisa para comparar como cada protocolo se comporta e o quanto ele irá exigir do
processamento e rede do servidor.Para os testes foram criados dois cenários, um onde são utilizados
dois desktops e cada um com um softph
softphone conforme que se conecta ao servidor Ateriskpodendo
gerar apenas uma chamada por vez conforme descrito na Figura 3.
O outro cenário utiliza três servidores Asterisk, duas plataformas Asterisk atuando como
ramais (5000 e 5001) e um como servidor VoIP conforme Figura 7,desta
,desta forma é possível gerar
várias chamadas simultâneas assim criando um cenário mais próximo da realidade de uma central
telefônica VoIP.

Figura 7 - SIP TRUNK.

No servidor foram utilizadas as seguintes ferramentas para capturar os dados:

 tcpdump – utilizado para capturar os dados enviados e recebidos trafegados na

interface de rede do servidor VoIP
VoIP.
 ifstat – utilizado para capturar o uso da interface de rede em tempo real.
 top – utilizado para capturar a porcentagem do processamento utilizado pelo
asterisk.

Para analisar os dados de gerados pelo tcpdump foi utilizado o W

WireShark
ireShark com ele é possível
observar o que esta ocorrendo durante a ligação, podendo determinar o fluxo das ligações, IPs,

10
protocolos utilizados, pacotes perdidos, jitter, latência, atraso, ordem dos pacotes e até mesmo
reproduzir o áudio da ligação se necessário.

3.4. Estabelecendo um referencial

Devido à dificuldade de recriar um cenário VoIP com um servidor Asterisk e vários clientes
fazendo ligações através de softphone ou telefones IPs, foram utilizados dois servidores Asterisk
que se comportam como ramais.
Buscando validar que ligações feitas entre softphones (Figura 3) e ligações feitas entre
Asterisks(Figura 7) consomem os mesmos recursos, foi executada uma ligação por vez usando os
cenários já descritos, este e todos os demais testes executados seguem os seguintes passos.
É iniciada a captura de pacotes na interface do servidor, é feita uma ou mais ligações, após a
ligação estabelecida e decorrido dez segundos da ligação atendida é iniciado o processo de registro
do processamento e trafego de rede por exatos um minuto, a ligação continua por mais 20 segundos
até ser encerrada, quando a ligação se encerra o processo de captura dos pacotes na interface é
interrompido.

8
Processamento (%)

6
4
Softphone (4000-4001)
2
Asterisk (5000-5001)
0
1 10 40
Tempo em segundos

Gráfico 1 – Processamento do servidor VoIP sem criptografia.

8
Processamento (%)

6
4
Softphone (4000-4001)
2
Asterisk (5000-5001)
0
1 10 40
Tempo em segundos

Gráfico 2 - Processamento do servidor VoIP utilizando TLS e SRTP.

11
 22,5

22
KB/s

21,5 Sem criptografia

21 TLS+SRTP

20,5
4000
4000-4001 Asterisk (5000-5001)

Gráfico 3 – Trafego médio na interface do servidor VoIP.

Com os dados coletados é possível gerar os (Gráfico 1, Gráfico 2 e Gráfico 3) onde é

possível visualizaro processamento e o trafego médio da rede ao decorrer de uma ligação,
ligação com e
sem o uso dos protocolos TLS e SRTP
SRTP,podemos
podemos seguir com os testes entre ramais Asterisk com um
número maior de chamadas simultâneas afirmando que os resultados gerados seriam os mesmos se
feitos entre softphones.

3.5. Criptografia
3.5.1. Risco de utilizar apenas TLS

Para demostrar a vulnerabilidade de uma chamada utilizando apenas TLS foram capturados
pacotes durante uma chamada. Ao analisar é possível identificar que existe a sinalização através do
TLS, desta maneira não é possível identificar os ramais de origem e ddestino,
estino, porem a mídia fica
exposta podendo ser reproduzida sem muita dificuldade.
Quando utilizado TLS o WireShark não consegue identificar os pacotes RTP, isso ocorre
porque por padrão o WireShark interpreta apenas SIP na porta 5060 e o TLS utiliza 5061. Para
corrigir isto basta identificar onde ocorre o primeiro HandShake e procurar pela sequencia de
pacotes UDP, selecionado o frame 132 ((Figura 8)) foi utilizado a sequencia de menus, Analyze,
Decode As..., na aba transporte
porte foi selecionado RTP e aplicado, feito isso foi possível ver o trafego
RTP (Figura 9) e reproduzir o áudio da ligação (Figura 10). Outra maneira de fazer isso é indo até
Edit, Preferencias, Protocols, RTP e marcar a opção, Trytodecode RTP outsideofconversations.

Figura 8 - Chamada utilizando transport TLS.

12
 Figura 9 – Pacotes RTP decodificados.

Figura 10–Reprodução de chamada utilizando TLS.

3.5.2. Risco de utilizar apenas SRTP

A análise
lise feita a seguir expõe a fragilidade do SRTP quando utilizado sem o TLS, para isso
será analisado os pacotes capturados durante uma ligação. Ao analisar os pacotes capturados é
possível identificar o uso do protocolo SRTP (Figura 11) e informações como de ramal de origem e
destino(Figura 12).

Figura 11 - Chamada utilizando protocolo SRTP.

Figura 12–Informações da chamada.

Como pode ser observado na ((Figura 13)) ao tentar reproduzir o RTP é possível ver que não
existe uma onda de áudio convencional, ao tentar reproduzir só será ouvido chiado.

13
 Figura 13 - Mídia RTP criptografada.

As chaves usadas para criptografar o RTP podem ser encontradas no SDP

S na parte do pacote
SIP. As chaves da origem da chamada podem ser encontradas na mensagem SIP INVITE, e as
chaves do destino da chamada podem ser encontradas na mensagem SIP 200 OK(Figura
OK 14).

Figura 14 - Parte SDP do pacote SIP.

Para encontrar a chave da chamada de destino basta expandir a parte SDP da mensagem 200
OK, que neste caso é o frame de nume
numero 115. Abaixo (Figura 15) podemos ver que a
AES_CM_128_HMAC_SHA1_80 é a ferramenta de criptografia usada e a chave pode ser vista em
texto puro com o valor de “jceipaLR+P5MgUFU9wQXvX8qwWp7D7I10OsODVND
jceipaLR+P5MgUFU9wQXvX8qwWp7D7I10OsODVND Após usar a
jceipaLR+P5MgUFU9wQXvX8qwWp7D7I10OsODVND”.
chave para quebrar a criptografia é possível ouvir o áudio sem problemas (Figura
Figura 16).

Figura 15 - Chave criptográfica em texto puro.

14
 Figura 16 – Mídia RTP após criptografia ser quebrada.

3.5.3. Segurança com TLS e SRTP

Ao analisar uma ligação
igação utilizando TLS e SRTP é possível identificar transito dos frames
TLS e não é possível recuperar informações das chamadas como ramais de origem ou destino, após
decodificar os pacotes de UDP para RTP não foi possível reproduzir os áudios, pois não foi
encontrada a chave para quebrar a criptografia, isso ocorre devido
vido ao TLS proteger as chaves
durante a sinalização.

3.6. Teste de desempenho e qualidade

O objetivo neste ponto é gerar varias chamadas simultâneas e fazer um comparativo entre
elas, para poder determinar se existe um carga adicional de processamento(Gráfico
processamento 4) e
rede(Gráfico 5) ao utilizar TLS e SRTP. Os testes foram feitos aumentando o numero de chamadas
simultâneas gradativamente, comparando codecs e protocolos SIP.
90
80
Processamento (%)

70
60
50
40
30
20
10
0
1 2 3 4 5 10 20 30 40 50 90
G.729 2 6 11 12 12 10 14 20 25 32 53
G.729 (TLS+SRTP) 3 8 13 15 14 11 18 25 34 44 74
G.711 3 7 12 12 13 9 15 20 25 34 52
G.711 (TLS+SRTP) 3 8 13 16 17 11 19 26 34 45 80
Chamadas Simultâneas.

G.729 G.729 (TLS+SRTP) G.711 G.711 (TLS+SRTP)

Gráfico 4 - Process
Processamento
amento médio conforme número de chamadas simultâneas.

15
 2500
2000
1500
KB/s

1000
500
0
1 2 3 4 5 10 20 30 40 50 90
G.729 7 11 22 29 36 73 142 218 287 360 654
G.729 (TLS+SRTP) 8 16 25 33 41 82 165 244 328 413 743
G.711 21 42 62 83 104 209 418 628 822 1047 1861
G.711 (TLS+SRTP) 22 44 65 88 109 219 438 657 875 1095 1968
Chamadas Simultâneas.

G.729 G.729 (TLS+SRTP) G.711 G.711 (TLS+SRTP)

Gráfico 5 - Trafego médio na interface conforme número de chamadas simultâneas.

Com base nos dados coletados é possível criar gráficos e comparar a utilização do
processamento e trafego da rede quando utilizadosdiferentes codecs e protocolos.O codec G.729 é o
mais recomendado seus algoritmos permite a compressão de voz sem perder qualidade utilizando
baixa quantidade de banda além corrigir os pacotes se necessário e tem uma maior tolerância perda
de pacotes e atraso.
Foi selecionado o codec G.729 para avaliar a qualidade das ligações perante odesempenho
devido à imprecisão da informação gerada pelo G.711, o fator que causou essa imprecisão foi o uso
de um switch domestico durante os testes, que nos momentos de grande volume detroca de dados
acaba atrasando a entrega dos pacotes, prejudicando parte do estudo.
Para determinar a qualidade de uma ligação, não podemos apenas nos basear no que
ouvimos, deve ser considerada a perda de pacotes, falha na sequencia e jitter, todas essas
informações podem ser obtidas analisando os pacotes pelo WireShark, mesmo que o RTP esteja
criptografado a ferramenta fornece essas informações.
A chamada pode ser considerada de qualidade quando o Max Delta esta abaixo de 50 ms e
inaceitável quando acima de 150 ms, MeanJitter acima de 20 ms também é inaceitável, grande
perda de pacotes (Lost RTP packets) ira degradar a chamada. Para o estudo iremos observar apenas
o Max Delta, pois em nenhum dos testes utilizando G.729 a perda chegou a 1% e o MeanJitter
sempre se manteve abaixo de 1 ms.

16
 90
80
70
60
milisegundos

50
40
30
20
10
0
1 2 3 4 5 10 20 30 40 50 90
Variação 1 20 3 2 3 1 18 2 23 19 42
Max Delta 41 23 41 41 40 41 24 40 22 40 40
Chamadas Simultâneas.

Gráfico 6 - Latência durante o trafego de pacotes SIP e RTP.

140
120
100
milisegundos

80
60
40
20
0
1 2 3 4 5 10 20 30 40 50 90
Variação 3 2 2 22 12 19 17 16 4 12 85
Max Delta 40 41 41 40 40 40 41 40 40 40 40
Chamadas Simultâneas.

Gráfico 7 - Latência durante o trafego de pacotes TLS e SRTP.

Devido à quantidade de chamadas a seranalisado ser muito grande, e devido à necessidade

do Max Delta ser analisado caso a caso, foi optado por mostrar a latência mínima e máxima,
destacando a variação ocorrida em cada volume de ligações (Gráfico 6 e Gráfico 7).
abaixo segue um trecho do das transmissões RTP analisadas, nelas é possível observar que
mesmo não tendo uma perda significativa existe uma latência muito alta que é atribuída a grande
quantidade de ligações simultâneas e a utilização switchde baixo desempenho.

17
 Figura 17– Trecho de transmisões RTP.

4. CONCLUSÕES
Este artigo buscou expor as brechas de segurança, entender os mecanismos de segurança e
avaliar o desempenho do TLS em conjunto com o SRTP que oferecem segurança na sinalização e
no transporte dos dados de mídia.
Para chegar aos resultados obtidos foram executadas 18408 chamadas e com isso pode
pode-se
afirmar que a utilização do TLS e SRTP fornece uma segurança completa, ofuscando identificações,
ocultando chaves e tornando a mídia impossível de ser reproduzida sem a posse das chaves
chaves.
Foi possível notar um acréscimo no consumo do processamento e rede conforme o
aumentado o número de chamadas simultâneas, mesmo aumentando o numero de chamadas
simultâneas a qualidade das ligações foram mantidas até que se criasse um gargalo na rede devido
ao switch utilizado.
Este artigo visou à criptografia de chamadas para ambientes corporativos onde a espionagem
industrial é uma realidade e uma preocupação independente do tipo de tecnologia utilizada para
fazer ligações. Pode-se
se afirmar que em um ambi
ambiente
ente de telefonia VoIP o uso do TLS com SRTP
tornarão a chamada segura e irá desestimular este meio como fonte de espionagem devido à
dificuldade de quebrar esta criptografia.
Ainda que o processamento de uma chamada de criptografia TLS com SRTP seja acima do
normal ela é altamente recomendada para os casos onde é desejável manter a privacidade de uma
chamada, é possível manter um ambiente misto de chamadas com e sem criptografia, mantendo
assim um equilíbrio sem a necessidade de investir pesadamente em har
hardware para manter a
segurança.

REFERÊNCIAS BIBLIOGRÁFICAS

ENDLER, David de: COLLIER Mark. Hacking Exposed VoIP: Voice Over IP SecuritySecrets &
Solutions.. McGrawHill/Osborne, 2007

18
MEGGELEN, Jim Van de: SMITH,Jared de: MADSEN, Leif. Asterisk O Futuro daTelefonia.
USA: Alta BooksLtda, 2005.

GUEDES, Anderson Danilo Costa de: LAPA, Igor Raphael dos Passos de: MEIRELES,Matheus
Barreto Vianna. IESAM - Instituto De Estudos Superiores da Amazônia.

ALENCAR, Ellen da Silva de: RODRIGUES, Wendell. Instituto Federal de Educação,Ciência e

Tecnologia do Ceará IFCE.2014

EGGER, Christoph de: HIRSCHBICHLER, Michael. Tornando redes VoIP seguras.

LinuxMagazine n51, Fevereiro de 2009

FERREIRA, Rogério da Cunha. Abordagens para escuta legal nas redes de Voz sobre
IP.Universidade Federal Fluminence, Niterói, 2008.

LINHARES, André Linhares. Interceptação Legal de Chamadas VoIP Baseadas em SIP.

Universidade Federal de Pernambuco. Fevereiro 2008.

DOMINGOS, Patrícia de: CHIROLLI, Paulo Vitor de Almeida. Análise de Desempenho

deTransmissão de Mídia com Protocolos de Criptografia, INSTITUTO FEDERAL DE SANTA
CATARINA. Fevereiro 2014.

SUBRAMANIAN, Sureshkumar V. de: DUTTA, Rudra. Comparative Study of Secure vs

NonSecure Transport Protocols on the SIP Proxy Server Performance: An Experimental Approach,
North Carolina State University. 2010

ALEXANDER, Andre L. de: WIJESINHA, Alexander L. de: KARNE, Ramesh. An Evaluation of

Secure Realtime Transport Protocol (SRTP) Performance for VoIP, ThirdInternational Conference
on Network and System Security, 2009.

PASSITO, Alexandre de: MOTA, Edjair de: QUEIROZ, Saulo de: BEZERRA, Eduardo
de:GALVÃO, Leandro. Análise de desempenho de tráfego VoIP utilizando o Protocolo IP Security,
Universidade Federal do Amazonas. 2014.

WITTENBERG, Nicholas. Understandingvoice over IP technology, Cengage Learning INT, 2008.

IEFT. SessionInitiationProtocol (SIP). (2004). https://tools.ietf.org/html/rfc3893. [Online; acesso

em 7 julho. 2015].

IETF. RTP: A TransportProtocol for Real-Time Applications.

(1996).https://tools.ietf.org/html/rfc1889. [Online; acesso em 7 julho. 2015].

IETF. The Secure Real-time TransportProtocol (SRTP). (2004). https://tools.ietf.org/html/rfc3711.

[Online; acesso em7 julho. 2015].

Morimoto, Carlos E. (2005). UDP. http://www.hardware.com.br/termos/udp. [Online; acesso em 7

julho. 2015].

19
IETF. The TLS Protocol. (1999).https://tools.ietf.org/html/rfc2246. [Online; acesso em 29 junho.
2015].

IETF. SIP digestauthentication relay attack. (2009).http://tools.ietf.org/id/draft-state-sip-relay-

attack-00.txt. [Online; acesso em 29 junho. 2015].

IETF. IP Security (IPsec) and Internet Key Exchange (IKE) DocumentRoadmap. (2011).
https://tools.ietf.org/html/rfc6071. [Online; acesso em 29 junho. 2015].

IETF. hortTermRequirements for Network AssertedIdentity. (2002).

https://tools.ietf.org/html/rfc3324. [Online; acesso em 29 junho. 2015].

IEFT. Private ExtensionstotheSessionInitiationProtocol (SIP) for. (2002).

https://www.ietf.org/rfc/rfc3325.txt. [Online; acesso em 29 junho. 2015].

tcpdump.Dumptrafficon a network. (2009). http://www.tcpdump.org. [Online; acesso em 25 agosto.

2015].

ifstat - ReportInterFaceSTATistics. (2003). http://gael.roualland.free.fr/ifstat. [Online; acesso em

em 25 agosto. 2015].

top - Display Linux tasks. (2002). http://www.unixtop.org. [Online; acessoem 25 agosto. 2015].

20