VoIP, Vulnerabilidade e Segurança do Protocolo SIP

V SRST –SEMINÁRIO DE REDES E SISTEMAS DE TELECOMUNICAÇÕES

INSTITUTO NACIONAL DE TELECOMUNICAÇÕES –INATEL ISSN2358-1913

SETEMBRO DE 2016

Abstract—The growth of VoIP communication over packet switched networks without security measures for SIP exposes the users to the typical IP Networks vulnerabilities. This article´s purpose is to address two security protocols for VoIP communications: SIPS and SRTP.

Index Terms—Security, SIPS, SRTP, VoIP.

Resumo—O crescimento da comunicação VoIP através das redes de pacotes sem as devidas preocupações com a segurança da comunicação SIP expõe os usuários desta tecnologia às vulnerabilidades típicas das redes IP. Este artigo aborda dois protocolos que oferecem segurança para as comunicações VoIP:

SIPS e SRTP.

Palavras chave—Segurança, SIPS, SRTP, VoIP.

I. INTRODUÇÃO

As redes de telecomunicações recebem cada vez mais tráfego de Voz sobre IP (VoIP) a cada ano, fato este demonstra que o Brasil é o 7º país no ranking com 5,3 milhões de assinantes VoIP [1]. Este estudo também apresenta o volume global de tráfego VoIP mensal, medido em PB (Petabytes) sendo este o valor esperado em 2016 de 158 PB [2]. A tecnologia VoIP utiliza o protocolo Session Initiation Protocol (SIP) como um dos mais difundidos para permitir o tráfego de voz e vem sendo empregado em operadoras de telefonia e Internet Service Providers (ISPs) com foco neste serviço que utilizam redes de pacote para tráfego de voz, permitindo o aumento da capacidade e redução dos custos. Os benefícios se estendem ao usuário final como forma de economia para ligações de longa distância e internacionais.

A quantidade de assinantes VoIP ao redor do globo crescem a cada ano e as preocupações com segurança para inibir ataques às redes coorporativas e aos seus usuários também tiveram que aumentar nos últimos anos. Dentre as preocupações com qualidade dos links de internet é importante citar algumas métricas que devem ser levadas em consideração: atraso fim a fim, porcentagem de perda de pacotes e jitter médio.

O SIP é um protocolo de início, término e controle de sessões de mídia, não sendo responsável pelo tráfego de mídia

Trabalho de Conclusão de Curso apresentado ao Instituto Nacional de Telecomunicações, como parte dos requisitos para a obtenção do Certificado de Pós-Graduação em Engenharia de Redes e Sistemas de Telecomunicações.

Orientador: Prof. (Mário Ferreira). Trabalho aprovado em 07/2016.

de voz ou vídeo, sendo esta, tarefa do protocolo Real Time Transport Protocol (RTP) na camada de aplicação. Os fluxos RTP estabelecidos utilizam do protocolo User Datagram Protocol (UDP) para transporte de mídia. Estes são periodicamente monitorados pelo Real Time Control Protocol (RTCP) que encaminha pacotes aos participantes das sessões contendo estatísticas qualitativas e quantitativas da mídia, como jitter, quantidade de pacotes enviados/recebidos, perda de pacotes, etc. Diferentemente do Transmission Control Protocol (TCP), largamente utilizado para transporte de dados na internet, o UDP é um protocolo que não implementa confiabilidade de entrega dos dados. Vale relembrar que ambos os protocolos da camada de transporte utilizam o Internet Protocol versão 4 ou 6 (IPv4 ou IPv6) na camada de Rede. O protocolo SIP, por sua vez, pode ser encapsulado tanto pelos protocolos Stream Control Transmission Protocol (SCTP), TCP ou UDP, sendo este último à implantação mais comum.

Por ser um modelo de transação baseado em solicitação e resposta semelhante ao Hypertext Transfer Protocol (HTTP), o SIP emprega algumas medidas de segurança para proteger a comunicação entre os usuários. Uma destas medidas é chamada de Autenticação Digest que é um mecanismo simples de autenticação entre usuário e proxy que protege contra ataques de acesso e violação de senhas. Este mecanismo permite que as credenciais trocadas entre usuário e proxy não estejam em texto claro. Entretanto esta técnica é empregada somente entre usuário e proxy, não se aplicando à troca de mensagens entre servidores. A Autenticação Digest também não implementa confiabilidade nem garante a integridade dos cabeçalhos SIP.

As vulnerabilidades SIP são exploradas em casos como:

• Empresas que possuem firewalls antigos e muitas vezes desatualizados que não dispõem de ferramenta para realizar a função SIP Aware Firewall. A função do SIP Aware Firewall é um recurso que permite ao equipamento analisar as regras de segurança de forma dinâmica quando houver chamadas entrantes e realizar o tratamento dos pacotes VoIP diferentemente dos outros pacotes que passam pela rede em tempo real. Esta tarefa consume muitos recursos de hardware e por esta razão, geralmente, o SIP Aware Firewall é um serviço instalado individualmente em servidores dedicados.

VoIP, Vulnerabilidade e Segurança do Protocolo SIP

Ricardo Aparecido Nogueira de Jesus¹, Mario Ferreira Silva Junior²

• Usuários que possuem smartphones da primeira geração, rodando versões obsoletas ou descontinuadas de sistemas operacionais (Symbian, Palm OS, Windows CE, primeiras versões do Android, etc) que possuem aplicativos Softphone, os quais não implementam técnicas de segurança atuais.

• Usuários que configuram seus softphones sem empregar nenhum mecanismo de segurança para fornecer confiabilidade e integridade da informação ao estabelecer qualquer comunicação SIP.Administradores de redes que não se atentam às portas TCP/UDP desnecessariamente abertas nas regras de firewall, que sem monitoramento, poderão facilitar ataques de Denial of Service (DoS) ou Distributed Denial of Service (DDoS). Os ataques de negação de serviço são pensados para tirar do ar os servidores enviando vários pacotes ao mesmo tempo para um único servidor tentando sobrecarrega lo. A principal diferença é como ele são realizados, o ataque DDoS é distribuído entre várias máquinas, enquanto o ataque DoS é realizado apenas por um equipamento.

Serão abordadas neste artigo alternativas para permitir confiabilidade das mensagens e segurança da mídia através dos protocolos SIP Secure (SIPS) que trata da implementação do SIP sobre Transport Layer Security (TLS) e Secure RTP (SRTP) para encriptação da mídia.

II. PROTOCOLO SIP

O protocolo SIP [3], de acordo com a arquitetura TCP/IP é um protocolo de controle da camada de aplicação que pode estabelecer, modificar e terminar uma sessão de multimídia tal como chamadas de telefone por internet. Caracterizado como um protocolo cliente/servidor baseado em texto suporta mapeamento de nome transparente e serviços de redirecionamento que permite que o usuário seja encontrado através de um identificador global SIP URI:

sip:usuario@dominio.com.br e possibilita ao usuário iniciar ou receber chamadas a partir de qualquer rede, permitindo a qualquer usuário SIP ter mobilidade pessoal. Contudo, permite ser integrado às aplicações de internet por ser um protocolo baseado em requisição e resposta semelhante ao HTTP e ao Simple Mail Transfer Protocol (SMTP).

Os requisitos para estabelecimento, controle e término da chamada são apresentados a seguir:

• User location: Utilizado para localização do usuário.

Desta forma o protocolo SIP pode encaminhar solicitação de uma nova sessão ao usuário destinado.

• User availability: O protocolo precisa definir o status do usuário, se está disponível ou se está participando de alguma sessão.

• User capabilities: Determina os recursos e parâmetros suportados pelo usuário.

• Session setup: Nesta etapa ocorre o estabelecimento dos parâmetros da sessão entre as partes: a que está chamando (pedindo o início de sessão) e a que está sendo chamada (respondendo ao pedido de início de sessão).

• Session management: Permite ao SIP modificar os parâmetros da sessão como invocar serviços adicionais ou encerrar a sessão.

A arquitetura SIP especifica diferentes elementos, sendo eles: User Agent, Proxy Server, Redirect Server e Registrar Server.

• UA (User Agent) é elemento de rede (físico ou lógico) que funciona como um cliente quando realiza uma requisição ou como um servidor quando a responde.

• O Proxy é o elemento responsável por encaminhar as requisições e respostas para os usuários envolvidos na sessão.

Além disso, o SIP Proxy trata de questões de Autenticação, Autorização e localização dos usuários.

• O Redirect Server é um elemento opcional na arquitetura SIP. Ele é responsável por manter uma base de dados de elementos de rede (clientes) que mudaram de domínio, informando ao elemento chamador uma nova localização do usuário de destino.

• Registrar Server: armazena as informações de registro do usuário que são utilizadas para sua localização. Estas informações contêm, por exemplo, o endereço IP do usuário e o seu identificador único.sip:usuário@dominio.com.br

A figura 1 mostra um exemplo de comunicação utilizando o protocolo SIP. Neste exemplo, Alice deseja chamar Bob e ambos utilizam um aplicativo SIP para fazer e receber chamadas. Alice inicia a solicitação enviando uma mensagem INVITE ao identificador único de Bob (sip:bob@biloxi.com).

Como Alice não conhece a localização de Bob, ela envia a mensagem ao seu proxy (Atlanta) este por sua vez encaminha a mensagem INVITE, em nome de Alice, para o domínio de Bob (biloxi.com). O proxy de Bob encaminha a resposta “100 Trying” gerada por Bob à Alice, informando que este recebeu sua solicitação e irá processá-la.

Ao processar o método INVITE e verificar que Bob está disponível para participar da sessão, o telefone/softphone de Bob retorna a resposta “180 Ringing”, informando à Alice que Bob está sendo notificado do pedido de nova sessão, podendo então disparar um tom de chamada.

Como neste exemplo a chamada foi aceita, o SIP Phone de Bob envia a resposta “200 OK” ao proxy Biloxi, que por sua vez, encaminha a resposta ao SIP Phone de Alice após passar pelo proxy Atlanta.

Ao receber a mensagem Alice envia a resposta ACK confirmando o recebimento da resposta de Bob.

Uma vez estabelecida à sessão entre Alice e Bob, o fluxo de mídia ocorre entre eles.

Quando uma das partes resolve terminar a chamada, uma mensagem BYE é enviada a outra. A parte que recebe a mensagem BYE confirma o encerramento da chamada retornando a mensagem “200 OK”.

Fig. 1. Exemplo de uma sessão estabelecida e terminada pelo protocolo SIP

III. SIPS

SIPS é classificado como um mecanismo que fornece proteção fim-a-fim a uma sessão. Isto significa garantir a confidencialidade dos dados de usuários através de autenticação e encriptação do corpo da mensagem, campos estes que não precisam ser lidos por proxies intermediários. O corpo da mensagem é criptografado pelo mecanismo Secure/Multipurpose Internet Mail Extension (S/MIME). O SIPS também pode oferecer proteção salto-a-salto que assegura a comunicação entre entidades SIP além das especificações de proteção de segurança que confiam na camada de nível de rede IP Security Procotol (IPSec) ou camada de transporte TLS.

É preciso garantir que o conteúdo da mensagem não seja alterado fim-a-fim e prevenir que invasores não tenham acesso à informação modificando ou substituindo as solicitações ou respostas SIP, os mecanismos que são utilizados para essa finalidade são: autenticação e encriptação dos dados.

Autenticação é o mecanismo utilizado para validar as credenciais do usuário originador da mensagem no início da sessão a fim de garantir que o interlocutor é realmente quem diz ser, e pode ser requerida por servidores proxy para redirecionar a chamada para o usuário receptor. Além disso, assegurar que a informação não será alterada em transito. Por outro lado, a autenticação salto-a-salto pode ser desempenhada por IPSec ou TLS. Desta forma, tem-se:

• IPSec - fornece segurança entre os nós da rede, fornecendo privacidade ao usuário, integridade aos dados e autenticidade das informações e provê criptografia a nível de rede que pode ser utilizado para garantir a confidencialidade da informação fim-a-fim ou salto-a-salto.

TLS – fornece segurança no transporte da informação baseada em TCP. Também usado para tráfego HTTP e e- mails, pode criptografar as mensagens de sinalização SIP. É adequado às arquiteturas em que se requer segurança salto-a- salto entre os hosts facilitando a associação de segurança mais dinâmica. Normalmente a URI (Uniform Resource Identifier), uma cadeia de caracteres compacta usada para identificar

unicamente um UA quando definida como SIPS, (exemplo sips:bob@biloxi.com) significa que está protegida por TLS.

Ainda que o UA faça uso de um dos mecanismos de segurança descritos acima para enviar mensagens em protocolo SIP ao seu servidor proxy, isto não garante que o transporte seguro da informação será usado no restante do percurso até o destino final, pois não necessariamente outros proxies que por ventura as mensagens SIP passarão, suportam ou implementam SIPS.

A figura 2 apresenta um exemplo de implementação SIP em um domínio de confiança para assegurar a confidencialidade da informação salto-a-salto através do protocolo TLS [4].

Fig. 2. Domínio Confiável SIP

A. Modelo de Operação TLS

TLS é o método padrão de uso do SIP para garantir confidencialidade da informação, além de iniciar uma comunicação autenticada entre o servidor e o cliente permitindo negociar o algoritmo de criptografia e chaves antes do envio os dados. Abaixo são descritos dois mecanismos distintos:

• Handshake: permite que a negociação entre as partes ocorra durante uma sessão TLS presente no modelo

“Certificado fornecido pelo Servidor” descrito na RFC 5630.

Neste modelo os certificados são fornecidos pelo servidor durante o handshake e compartilhados entre o UA e o proxy.

A autenticação é sempre iniciada pelo UA enquanto o proxy se vale do SIP Digest para autenticar o UA e assegurar que somente este possa estabelecer conexões através do protocolo TLS, além de controlar o keep alive para as demais conexões ou respostas. A técnica de keepalive permite que a sessão permaneça ativa, mesmo utilizando protocolos não confiáveis na camada de transporte, que por definição, não estabelecem e mantém conexão .

• Autenticação mútua: neste modelo o certificado é fornecido tanto pelo UA como pelo proxy na fase de handshake. O certificado apenas é enviado pelo UA que assume o papel de cliente TLS quando estabelece novas conexões ou quando o servidor receber novas solicitações.

Entretanto este modelo apresenta limitações visto que muitos elementos estão atrás de firewalls e NAT o que geralmente permite estabelecer a conexão somente de dentro da rede corporativa em direção à rede pública e não o inverso. Por esta razão, a ausência de um ponto central para troca do certificado diminui a viabilidade de implantação deste modelo.

Uma abordagem do modelo de funcionamento do TLS handshake é apresentada na Figura 3, o que inclui troca de chaves de criptografia e Message Digest:

Fig. 3 Handshake TLS

• O cliente TLS envia uma mensagem “client hello” que lista as informações criptográficas, um conjunto de codificação suportado pelo cliente e também inclui a compressão de dados suportada pelo cliente. A mensagem contém uma string de byte aleatória que é usada para cálculos subsequentes.

• O servidor responde a solicitação com uma mensagem

“server hello” que contém o conjunto de codificação escolhida pelo servidor na lista fornecida pelo cliente, a identificação da sessão, e outra string de byte aleatória. O servidor também manda o certificado digital que inclui uma lista de tipos de certificados suportados.

• O cliente TLS verifica o certificado digital do servidor.

• O cliente TLS envia a string de byte aleatória que permite que ambos, cliente e servidor computem a chave secreta para ser usada para criptografar os dados de mensagem subsequente. A string de byte aleatória em si é criptografada com a chave pública do servidor.

• Se o servidor TLS enviar uma “solicitação do certificado do cliente”, o cliente envia uma string de byte criptografado com a chave pública do cliente juntamente com o certificado digital.

• O servidor TLS verifica o certificado do cliente.

• O cliente TLS envia uma mensagem “finished” ao servidor, a qual é criptografada com a chave secreta, indicando que a parte do processo de handshake do cliente está completa.

• O servidor TLS envia uma mensagem “finished”ao cliente, a qual é criptografada com a chave secreta, indicando que a parte do processo de handshake do servidor está completo.

• Para continuação da sessão TLS, o servidor e o cliente trocam mensagens que são simetricamente criptografadas com a chava pública.

• O handshake é então finalizado [16].

IV. SEGURANÇA RTP

O SRTP oferece autenticação, integridade e confidencialidade para o transporte da mídia através do protocolo RTP.

O SRTP atua entre a camada de aplicação RTP e a camada de transporte interceptando os pacotes RTP que chegam e encaminham ao destino. Na chegada ao destino o pacote é novamente interceptado pelo SRTP em seguida encaminhado a aplicação da camada RTP. A figura 4 apresenta o modelo para implantação do SRTP.

Fig. 4. Modelo De Implantação SRTP

A. Visão Geral

O advento da segurança de sinalização e mídia reforçada permite às empresas reduzirem custos com links dedicados ou redes Multiprotocol Label Switching (MPLS) para comunicação SIP de modo que a comunicação pode ser realizada de forma segura através do link de acesso disponível e compartilhada.

O SRTP foi desenhado para minimizar a latência e oferecer melhor eficiência de largura de banda tanto para redes cabeadas quanto para redes sem fio. Este ainda conta com as vantagens do uso da criptografia Advanced Encryption Standard (AES) para encriptação do fluxo de mídia garantindo maior segurança, porém sem aumento considerável do tamanho do pacote devido à carga criptográfica. Todavia, a transformação de criptografia definida no SRTP mapeia o índice e a chave secreta do pacote SRTP em um segmento keystream pseudoaleatório. Um keystream é definido como um fluxo de caracteres aleatórios que quando combinados com um texto, resulta no texto cifrado [5]. Outros protocolos de segurança de internet geralmente se valem de blocos

criptográficos, o que faz com que estes impactem no tamanho do pacote, consequentemente, no aumento de consumo de banda.

Conforme podemos observar na figura 5, somente o payload do RTP é criptografado.

Fig. 5 Formato Pacote SRTP, RFC 3711

B. Mecanismo Criptográfico - SRTP

O SRTP garante a confidencialidade do payload através de criptografia e a integridade das mensagens através de autenticação. O SRTP adiciona os dois seguintes campos ao pacote: Master Key Identifier (MKI), que é um campo opcional de comprimento configurável utilizado para indicar a chave mestre, a partir da qual as chaves das sessões individuais são derivadas para codificação e/ou autenticação.

Authentication Tag é o campo de comprimento variável recomendado para armazenar os dados de autenticação da mensagem para o cabeçalho RTP e payload [6].

A chave de sessão é válida apenas para cada contexto, ou seja, não se repete entre outras sessões e são descartadas ao término de cada uma delas.

A figura 6 apresenta as principais características e requisitos do contexto criptográfico.

Fig. 6. Contexto Criptográfico

• Contador Rollover (ROC), conta quantas vezes o número de sequência RTP de 16 bits foi zerado após atingir 65535.

• Negociação de chaves e cifras simétricas durante a troca de mensagens da mídia definidas pelo formato Session Description Protocol SDP Offer/Invite, RFC 2327.

• Criptografia avançada AES-Counter Mode padrão de 128 bits permite ao receptor processar os pacotes de forma aleatória, a qual é uma característica desejável para aplicações em tempo real.

• Master Key, chave única para uso em ambas as direções do fluxo da mídia.

• Master Key e Master Salt são geradas para encriptar as sessões.

• Master Key Index (MKI) são geradas para comunicação das sessões, o uso é opcional.

• Taxa de derivação da chave é um algoritmo independente do utilizado para criptografia e autenticação além de ser definido no início da comunicação do SRTP (um número inteiro em {1~2²⁴}.

O payload dos pacotes RTP é tornado seguro através de criptografia, autenticação de todo o pacote e a proteção de ataques conhecidos como replay. Proteção contra replay visa mitigar que as mensagens sejam interceptadas por um invasor e retransmitidas ou atrasadas, através do número de sequência do pacote o receptor tem como função manter os índices das mensagens recebidas, desta forma, somente as mensagens que apresentarem os índices não recebidos anteriormente serão processadas. Esta é a primeira linha de defesa contra pacotes enviados por um invasor [7]. O protocolo é localizado entre a aplicação e a camada de transporte RTP assegurando a confidencialidade do payload e integridade de todo pacote RTP adotando o uso da chave de criptográfica simétrica AES.

O SRTP é usado para proteger a mídia de voz/vídeo de uma possível espionagem ou adulteração, ele protege a confidencialidade do payload RTP e a integridade de todo pacote RTP adotando o algoritmo de criptografia AES como padrão. A forma como a chave secreta é compartilhada pelos nós de comunicação em segredo no uso do SRTP é uma questão sensível, visto que incorporar as chaves manualmente em todos os telefones é muito complicado e propenso a erros e para melhor eficiência o RTP e SRTP podem ser implementados em uma camada, em vez de duas camadas. O TLS e SRTP são componentes chaves que desempenham um papel importante na garantia do serviço VoIP. Entretanto, deve haver protocolos de apoio ou uma infraestrutura que pode autenticar os usuários, validar os certificados dos usuários e trocar as chaves de criptografia. As chaves de criptografia para estes serviços são associadas ao endereço IP, porta UDP e SSRC e são chamados de contexto criptográfico [8].

No contexto criptográfico é gerado um índice implícito a partir do valor de Rollover (o número de sequência do protocolo RTP é de apenas 16 bits de comprimento, o SRTP usa um número de sequência implícito maior que ele chama de índice de pacote. O número de vezes que a sequência RTP foi

zerado após atingir 65.535 é controlado por um campo chamado Rollover Counter (ROC) que é usado para formar o índice de pacotes. O ROC não é explicitamente incluído nos pacotes a fim de economizar largura de banda. [14]), e como resultado do índice uma chave única chamada de chave de sessão é gerada para criptografar e autenticar a mensagem. O índice gerado da chave mestre é anexado ao final do payload reforçando ainda mais a segurança da mensagem. A chave da sessão realiza o procedimento de autenticação ao final do pacote quando calcula os valores de autenticação do cabeçalho RTP e do payload criptografado.

Ao chegar ao seu destino, o SRTP localiza o contexto criptográfico e cria um índice implícito dos valores do contexto criptográfico para recuperar a chave de sessão. Só então os dados gerados podem ser autenticados com a chave de sessão. Caso seja averiguada a autenticidade, o pacote será encaminhado ao RTP, do contrário será descartado [8] [9].

C. Sessão de derivação de chaves

As chaves de sessão são geradas a partir de uma única chave mestre utilizando um bloco de cifra AES no modo contador para gerar o material de chaveamento necessário. A chave mestre pode ter tamanho de 128, 192 ou 256 bits e desempenha o papel de chave de criptografia AES, conforme figura 7.

Se uma taxa de derivação de chave for definida, em seguida, cada vez que um número de pacotes equivalentes à taxa de derivação de chaves for enviado, um novo conjunto de chaves de sessão SRTP ou SRTCP será computado. Se a taxa de derivação de chave for definida como zero, então o mesmo conjunto de chaves é usado para toda a duração da sessão [10].

Fig. 7. Derivação das chaves de sessão

D. Distribuição Da Chave Mestre

Uma abordagem proposta é o uso do Multimedia Internet KEYING (MIKEY) para estabelecer o contexto criptográfico SRTP. MIKEY é um novo protocolo de troca de chave geral semelhante ao IPsec Internet Key Exchange (IKE) mas adaptado às exigências específicas de um ambiente multimídia.

Como solução, o principal parâmetro “k” definido pelo SDP poderia ser usado para transferir a chave Master Key. A figura 8 apresenta uma mensagem típica SIP INVITE com os parâmetros necessários para estabelecer uma sessão

multimídia, incluindo o corpo applicaion/sdp MIME [10]. O corpo da mensagem no protocolo SIP pode conter vários tipos de informações, dentre elas, informações do SDP (application/sdp) que pode ser utilizada para transmitir informações de parâmetros de mídia, QoS ou requisitos de segurança. O formato do corpo da mensagem é indicado pelo cabeçalho Content-Type o qual deve estar presente na mensagem sempre quando houver o corpo da mensagem (message body). Além disso, o corpo da mensagem pode ser composto por múltiplas partes se for codificado com MIME [15].

Fig. 8. Mensagem SIP INVITE

E. Processamento do Pacote

Uma vez que o contexto criptográfico foi inicializado, a codificação é desempenhada de acordo com os seguintes passos [9]:

1. Determinar qual contexto criptográfico deverá ser utilizado;

2. Determinar qual o índice do pacote SRTP;

3. Determinar as chaves Master Key e Master Salt;

4. Determinar as chaves Session Keys e Session Salt;

5. Criptografar o payload RTP com o algoritmo de criptografia indicado no contexto criptográfico através das chaves Session Key e Session Salt;

6. Se o indicador MKI for definido como o valor 1 (um) anexar o MKI ao pacote;

7. Calcular a Tag de autenticação com o Rollover, o algoritmo de autenticação e a chave de autenticação da sessão;

8. Se necessário, atualizar o Rollover usando o índice do pacote determinado no passo 2.

Ao término deste processo o pacote será enviado ao receptor que realiza o processo contrário para decriptografar o payload.

F. Negociação da Mídia

Uma vez realizada a autenticação e criptografia do fluxo RTP através do SRTP, as informações da descrição da mídia são transmitidas pelo protocolo SDP. Ao iniciarmos uma sessão SIP de qualquer natureza, os detalhes da mídia precisam ser negociados, endereçados e transportados entre os participantes. Este processo faz parte da descrição da mídia que é desempenhado pelo protocolo SDP.

O SRTP provê serviço de segurança para mídia RTP por meio do transporte RTP seguro (RTP/SAVP e RTP/SAVPF) definido na linha (m=) do SDP, conforme apresentado na figura 8.

A negociação da mídia é transmitida por meio do modelo SDP Offer/Answer e permite ao destinatário escolher uma das opções diferentes do perfil RTP que pode ser usado em diferentes sessões de mídia. Os quatros perfis AVP, AVPF, SAVP e SAVPF são mutualmente exclusivo para negociação da descrição da mídia. Ao iniciar uma sessão o ofertante é capaz de suportar mais de um destes perfis para uma determinada sessão, as alternativas devem sempre ser listadas na ordem de preferência: perfis seguros SAVP, SAVPF ou perfis não seguros. Por uma questão de segurança na mesma sessão de mídia não devem ser ofertados simultaneamente os métodos seguros SAVP e SAVPF e os métodos não seguros AVP e AVPF. Esta oferta poderia abrir uma brecha para ataques, dado que o receptor poderia optar pela opção não segura. Em casos onde a descrição da mídia ofereça somente opções seguras como SAVP ou SAVPF e o destinatário não suporte estes recursos, a sessão será rejeitada e terminada.

A descrição da mídia é dada através da linha m=, apresentada na figura 8, contida na mensagem SDP e a informação referente à criptografia escolhida estão contida na linha a=crypto.

O Exemplo a seguir exibe o conteúdo do protocolo SDP, explicitando que a negociação da mídia sugere o método seguro SAVPF e a criptografia AES-CM 128 bits. [11], [12], [13].

v=0

o=alice 3203093520 3203093520 IN IP4 host.example.com s=Media with feedback

t=0 0

c=IN IP4 host.example.com m=audio 49170 RTP/SAVPF 0 96 a=rtpmap:0 PCMU/8000

a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16

a=rtcp-fb:96 nack

a=crypto:AES_CM_128_HMAC_SHA1_32

inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGd UJShpX1Zj/2^20/1:32

No exemplo a seguir a negociação da descrição da mídia oferece o método não seguro AVP ou AVPF.

v=0

o=alice 3203093520 3203093520 IN IP4 host.example.com s=Media with feedback

t=0 0

c=IN IP4 host.example.com m=audio 49170 RTP/AVP 0 96 a=rtpmap:0 PCMU/8000

a=rtpmap:96 telephone-event/8000

a=fmtp:96 0-16 a=rtcp-fb:96 nack

a=crypto:AES_CM_128_HMAC_SHA1_32

inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGd UJShpX1Zj/2^20/1:32

V. CONCLUSÕES

O número de usuários que fazem uso da tecnologia VoIP cresce a cada ano no Brasil e no mundo, conforme as estatísticas apresentadas neste artigo. Este fato oferece razões que fortalecem a ideia de que os sistemas de telefonia convencionais possam migrar para sistemas de telefonia VoIP, uma vez que empresas e usuários residenciais dispõem de infraestrutura de rede de dados para originar e receber este tipo de chamada. As vantagens do uso desta tecnologia atingem não apenas as grandes corporações, as quais podem utilizar uma rede privada para facilitar a comunicação entre os seus colaboradores via aplicativo SIP, como também oferecem alternativas para melhorar a competitividade técnica entre Provedores de Serviços. Contudo, com o advento da facilidade da comunicação entre usuários e a melhor relação custo benefício para chamadas de longa distâncias e internacionais, as preocupações com a segurança da chamada VoIP através das redes de pacotes não acompanharam o crescimento na mesma proporção. Como fruto do aumento de tráfego de voz, as vulnerabilidades SIP são exploradas por hackers cada vez mais, sendo algumas destas vulnerabilidades expostas por falta de medidas práticas por administradores de redes ou usuários que ajudariam reduzir possíveis ataques.

Os mecanismos de proteção empregados através de diferentes técnicas envolvem a proteção da sinalização e mídia e o conjunto destes mecanismos garante a preservação da chamada em curso. Entretanto, cada mecanismo de segurança apresentado neste artigo deverá ser avaliado de acordo com cada cenário existente, uma vez que alguns serviços como SIP Aware Firewall e SIP proxy consomem muitos recursos de hardware o que certamente poderá envolver custos para aquisição de hardware.

Todavia, para que possa oferecer confiabilidade durante uma comunicação VoIP aos usuários, é preciso dispor de soluções específicas que exercem tais funções como o uso de SIP Aware, servidores TLS e criptografia da mídia. A adição desses recursos combinados aumentam a proteção das chamadas VoIP em redes compartilhadas, como é o caso da internet.

REFERÊNCIAS

[1] STATISTA, The Statistics Portal. Data volume of global VoIP service traffic from 2011 to 2016 (in petabytes per month). Disponível:

http://www.statista.com/statistics/267183/forecast-for-the-worldwide- voip-traffic/, 2016.

[2] STATISTA, The Statistics Portal. Countries by number of Voice over Internet Protocol (VoIP) subscribers in 1Q 2013 (in millions).

Disponível: http://www.statista.com/statistics/236824/number-of-voip- subscribers-by-leading-countries/, 2016.

[3] Network Working Group. SIP: Session Initiation Protocol. RFC 3261, 2002.

[4] SALSANO, Stefano, VELTRI, Luca, PAPALILO, Donald. SIP Security Issues: The SIP Authentication Procedure and its Processing Load (on-

line). Disponível:

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=932FDA3B74 CFE78EB27B0E7D284C9BE9?doi=10.1.1.416.3363&rep=rep1&type=

pdf, 2002.

[5] HÈRCULES, Luis Antonio Leiva. Impacto no Desempenho em Aplicações de Tempo Real Utilizando Criptografia. Disponível:

https://www.lume.ufrgs.br/bitstream/handle/10183/110746/000952906.

pdf?sequence=1, 2014.

[6] CISCO SYSTEM, Cisco Telepresence Secure Communications and

Signaling (on-line). Disponível:

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Video/telepre sence.html, 2009.

[7] CISCO SYSTEM, Securing Internet Telephony Media with SRTP and

SDP (on-line). Disponível:

http://www.cisco.com/c/en/us/about/security-center/securing-voip.html [8] PORTER, Thomas. Practical VoIP Security (on-line).

Disponível: http://citeseerx.ist.psu.edu/viewdoc/download?doi=

10.1.1.174.4162&rep=rep1&type=pdf, 2002 [pp 413,420].

[9] BIGOT, David. Secure VoIP Security (in-line). Disponível:

http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:voip:tls_sips_

rtps, 2015.

[10] STEFFEN, Andreas, KAUFMANN, Daniel. SIP Security (on-line).

Disponível: http://security.hsr.ch/docs/DFN_SIP.pdf, 2004.

[11] Network Working Group. Session Description Protocol (SDP) Security Descriptions for Media Streams. RFC 4568, 2006.

[12] Network Working Group. Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF).

RFC 5124, 2008.

[13] BILIEN, Johan, ELIASSON, Erik, ORRBLAD, Joachim, et tal. Secure VoIP: call establishment and media protection (on-line). Disponível:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=

10.1.1.126.247&rep=rep1&type=pdf, 2016.

[14] McGREW, David A. Synchronizing the Rollover Counter in SRTP Multiparty Sessions (on-line). Disponível:

http://www.mindspring.com/~dmcgrew/roc.txt, 2006.

[15] JOHNSTON, Alan B. SIP Understanding the Session Initiaton Protocol,

Thrird Edition. Disponível:

https://books.google.com.br/books?id=AKDgVrDz9mYC&

printsec=frontcover&hl=ptBR&source=gbs_ge_summary_r&cad=0#v=

onepage&q&f=false, 2009 [pp 105].

[16] IBM KNOWLEGDE CENTER. An Overview of the SSL or TLS

Handshake (on-line). Disponível:

https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.1.0/com.ibm .mq.doc/sy10660_.htm , 2016.

REFERÊNCIAS AUXILIARES

[17] Network Working Group. The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP). RFC 5630, 2009.

[18] Network Working Group. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246, 2008.

[19] Network Working Group. The Secure Real-Time Transport Protocol (SRTP). RFC3711, 2004.

[20] Network Working Group. Security Mechanism Agreement for the Session Initiation Protocol (SIP). RFC 3329, 2003.

[21] COLLIER, Mark. Basic Vulnerability Issues for SIP Security (on-line).

Disponível:http://download.securelogix.com/library/SIP_Security03010 5.pdf, 2005.

[22] RUCK, Matthew. Top Ten Security Issues Voice over IP (VoIP) (on- line). Disponível: http://www.designdata.com/wp- content/uploads/sites/321/whitepaper/top_ten_voip_security_issue.pdf, 2010.

[23] SHEN, Charles, NAHUM, Erich, SCHULZRINNE, Henning, et tal. The Impact of TLS on SIP Server Performance (on-line). Disponível:

http://www.cs.columbia.edu/~hgs/papers/Shen1008_TLS.pdf, 2010.

[24] KAIJI, Tadashi, HOSHINO, Kazuyoshi, FUJISHINO, Takahiro. TLS handshake method based on SIP (on-line). Disponível:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.698.217

&rep=rep1&type=pdf, 2006

Ricardo Aparecido Nogueira de Jesus nasceu em São Paulo, SP, em 27 de Junho de 1976. Formado em Análise de Sistemas (UNIBAN, 2008).

De 1999 a 2005 atuou como administrador de redes na Editora Páginas Amarelas, realizando configuração e manutenção de switches e roteadores de diversos fabricantes. De 2006 a 2010 atuou como analista de redes de telecomunicações configurando e administrando gateway de voz CISCO série Access Server e realizava troubleshooting em SIP Proxy nas empresas de telecomunicações Telefree e Aerotech. Entre 2010 à 2015 atuou como arquiteto de soluções na empresa Agora Soluções fornecendo soluções de sistemas de telefonia IP, Wireless LAN, enlaces micro-ondas como também ministrou treinamentos de redes, telefonia IP e Wireless LAN.

Mário Ferreira Silva Jr. é engenheiro, formado em julho de 2008 como Engenheiro Eletricista na modalidade Eletrônica com Ênfase em Telecomunicações pelo Instituto Nacional de Telecomunicações e em 2012 recebeu o título de Especialista em Engenharia de Redes e Sistemas de Telecomunicações pelo mesmo instituto. Atualmente é Gerente Adjunto de Educação Continuada do Inatel Competence Center, sendo responsável por cursos de Extensão Presencial, Ensino a Distância, Capacitação Corporativa, Consultoria e Preparatórios para Certificações. É professor do curso de Pós Graduação em Engenharia de Redes e Sistemas de Telecomunicações do Inatel e especialista em Redes de Dados, TCP/IP, NGN, Voz e Vídeo sobre IP, Redes de Acesso, Redes convergente e Cidades Digitais.