Escolar Documentos
Profissional Documentos
Cultura Documentos
BLUMENAU, 2005
HUMBERTO MAXCLIOFF CALVACHE
BLUMENAU, 2005
I
PROTÓTIPO DE UM SISTEMA DE TELEFONIA IP CRIPTOGRAFADO BASEADO
NO PADRÃO SIP
ENGENHEIRO DE TELECOMUNICAÇÕES
________________________________________________
Prof. Francisco Adell Péricas, Ms. – Orientador, FURB
________________________________________________
Prof. Fábio Luis Perez – Coordenador do TCC, FURB
BANCA EXAMINADORA
______________________________________________
Prof. Fábio Rafael Segundo
______________________________________________
Prof. Orlando José Tobias
II
DEDICATÓRIA
III
AGRADECIMENTOS
A Deus por estar sempre presente na minha vida através do seu infinito
amor.
Aos meus amados pais Humberto Maxclioff Calvache Chiliquinga e Ionira
Machado Brincas pelo apoio e amor incondicional.
Aos meus queridos irmãos pelo companheirismo e amor que sempre
dispuseram.
À minha namorada pelo incentivo e carinho.
À todos amigos conquistados durante a graduação e que me deram força
para concluir o curso de engenharia.
Ao meu orientador Francisco Adell Pericas que acreditou no meu trabalho e
se dispôs a orientar-me.
IV
RESUMO
V
ABSTRACT
The use of IP Telephony and total convergence of the communications enable the
organizations to reduce drastically the costs at the same time that they make new
ways of business capable. This work presents the development of a prototype of a
system of IP Telephony Cryptographed between two microcomputers based on SIP
standard, developed for voice full-duplex communication at a Windows environment.
VI
SUMÁRIO
1 INTRODUÇÃO .....................................................................................................9
1.1 MOTIVAÇÃO............................................................................................................ 9
1.2 OBJETIVOS DO TRABALHO ............................................................................... 10
1.4 ORGANIZAÇÃO DO TRABALHO ....................................................................... 11
2 TELEFONIA IP ..................................................................................................12
2.1 INTRODUÇÃO........................................................................................................ 12
2.2 AMBIENTES PARA TELEFONIA IP .................................................................... 15
2.3 VOZ.......................................................................................................................... 17
2.4 QUALIDADE DE SERVIÇO .................................................................................. 19
2.5 PROTOCOLOS DE TELEFONIA IP ...................................................................... 21
2.5.1 TCP/IP .................................................................................................21
2.5.2 UDP .....................................................................................................22
2.5.3 RTP......................................................................................................23
2.5.4 RTCP ...................................................................................................26
2.5.5 SIP & H.323 .........................................................................................27
3 SIP .....................................................................................................................29
3.1 INTRODUÇÃO........................................................................................................ 29
3.2 ENDEREÇOS SIP.................................................................................................... 35
3.3 SDP........................................................................................................................... 35
3.4 SEGURANÇA SIP ................................................................................................... 36
4 CONCEITOS DE CRIPTOGRAFIA....................................................................38
4.1 INTRODUÇÃO........................................................................................................ 38
4.2 CRIPTOGRAFIA ..................................................................................................... 39
4.2.1 Sistemas de Chaves Simétricas ..........................................................40
4.2.2 Sistemas de Chaves Assimétricas.......................................................41
5 DESENVOLVIMENTO DO TRABALHO............................................................42
5.1 INTRODUÇÃO........................................................................................................ 42
5.2 REQUISISTOS DO PROTÓTIPO........................................................................... 42
5.3 ESPECIFICAÇÃO ................................................................................................... 43
5.3.1 Diagrama de Caso de Uso...................................................................44
5.3.2 Estrutura de Camadas do Protótipo.....................................................46
5.3.3 Diagrama de Classes...........................................................................47
5.4 IMPLEMENTAÇÃO ............................................................................................... 49
5.4.1 Visual C++ 6 ........................................................................................50
5.4.2 JVOIPLIB .............................................................................................50
5.4.3 Protótipo ..............................................................................................53
6 CONCLUSÃO ....................................................................................................59
6.1 TRABALHOS FUTUROS ....................................................................................... 60
7 REFERÊNCIAS BIBLIOGRÁFICAS..................................................................61
VII
LISTA DE FIGURAS
LISTA DE QUADROS
VIII
1 INTRODUÇÃO
1.1 MOTIVAÇÃO
9
funções de sinalização e gerenciamento de sessão dentro de uma rede. A
sinalização permite que as informações da chamada sejam transmitidas entre os
limites da rede. O gerenciamento de sessão fornece a habilidade de controlar os
atributos de uma chamada fim a fim.
As principais funcionalidades exercidas por esse padrão são:
localização de usuários;
estabelecimento de chamadas;
10
aquisição e análise da biblioteca JVOIPLIB desenvolvida por Liesenborgs
e disponibilizada gratuitamente na Internet;
11
2 TELEFONIA IP
2.1 INTRODUÇÃO
12
multiplexação por divisão do tempo (TDM) e na comutação por circuitos. Nesta, um
assinante (usuário) A, ao se comunicar com outro assinante de destino B, necessita
de um circuito exclusivo para garantir o canal de comunicação. Este circuito, de
largura de banda determinada (limitada), normalmente 64 kbps, é usado para o
transporte de voz entre o assinante A e o assinante B, e multiplexado para
transmissão em um meio físico compartilhado. Vários canais podem ser
multiplexados em um feixe de canais do tipo E1 (32 canais) ou T1 (24 canais) para
ligação entre centrais telefônicas.
A restrição da largura de banda citada anteriormente decorre da
necessidade de compartilhar o canal entre muitos usuários a qualquer momento,
exigindo uma diminuição dessa largura de banda, utilizando apenas a banda de
freqüência essencial (300 a 3400 Hz) para uma transmissão satisfatória da voz
humana.
De acordo com Oliveira (2000) a comutação é dita como baseada em
circuitos porque os elementos do sistema que garantem que a voz chegue ao seu
destino são comutadores que estabelecem circuitos na fase de negociação da
chamada e mantêm estes circuitos até o seu término. Caso não haja comunicação
entre os dois assinantes, como em momentos de silêncio, o canal é desperdiçado.
Conforme Guimarães (1999), nas redes de comutação de pacotes, tais como
a Internet, intranet (redes IP privadas), e outras redes de dados, não há uma reserva
da largura de banda entre os pontos de origem e destino. Esta tecnologia de rede
faz a divisão das mensagens em pequenos pacotes (ou células, dependendo do
tamanho), onde cada pacote pode percorrer uma rota diferente, através da rede, que
é compartilhada com pacotes de mensagens de outros usuários. Desta maneira, a
comutação de pacotes requer que estes tenham um cabeçalho que garanta uma
rota de destino exata, com a reconstrução da mensagem na sua seqüência correta
no terminal de destino.
A vantagem das redes de comutação de circuitos é que elas proporcionam
uma largura de banda dedicada. Fato que pode garantir a qualidade de serviço (QoS
– Quality of Service) no tráfego da voz, que será abordada posteriormente. Como
desvantagem há a utilização ineficiente dos recursos da rede. Conforme descrito
anteriormente, se durante uma ligação telefônica os dois usuários ficam em silêncio,
nenhuma informação estará sendo transmitida, porém a linha (largura de banda)
continua reservada, isto é, outros usuários da rede de telefonia pública (no caso, os
13
seus assinantes) não poderão realizar uma chamada. Na telefonia convencional dois
canais são reservados para cada conversação, independente da existência ou não
de tráfego de voz nos circuitos, ou seja, mesmo nos momentos de silêncio. Esses
pequenos instantes de tempo significam desperdício de recursos, uma vez que hoje
em dia os processadores com algoritmos de supressão de silêncio, utilizados
principalmente em redes de comutação de pacotes, reconhecem uma largura de
banda não utilizada (inexistência de informação), liberando-a para outro usuário.
Isso é conhecido como “multiplexação estatística”, pois se trata de multiplexar várias
conversações em um único canal de comunicação, em vez de ocupar uma largura
de banda durante todo o tempo, esta “largura de banda individual“ pode ser usada
por outro usuário qualquer durante os momentos de silêncio, como pode ser
ilustrado na figura 1.
14
possibilidade de compactação e supressão de silêncio, reduzindo a
largura de banda utilizada;
15
A figura 2 mostra o modelo mais simples de Telefonia IP, no qual está
baseado este trabalho. Nele a comunicação entre os dois usuários é feita através da
rede IP, portanto a rede telefônica convencional não é utilizada. A codificação de voz
é realizada pelas placas multimídia dos computadores. Segundo Oliveira (2000),
existem vários softwares para este tipo de aplicação, podendo utilizar um protocolo
proprietário ou padrão, permitindo, neste caso a interação de softwares de diferentes
fabricantes.
16
Figura 4 – Telefonia IP entre dois telefones convencionais
2.3 VOZ
17
amostragem: trata-se do processo de medir valores instantâneos de um
sinal analógico em intervalos regulares. O intervalo entre as amostras é
determinado por um pulso de relógio e a freqüência desse relógio é
chamada de Taxa de Amostragem. De acordo com o teorema de Nyquist,
para reproduzir fielmente o sinal, a taxa ou freqüência de amostragem
deve ser de, pelo menos, o dobro da maior freqüência contida no sinal a
ser amostrado (OLIVEIRA, 2000). Um sinal analógico é convertido em
um sinal digital através da captura de uma série de amostras da fonte
analógica. A união dessas amostras forma o equivalente digital de uma
onda sonora;
18
parâmetros são transmitidos e usados para sintetizar o padrão de voz. A
forma de onda resultante pode não ser semelhante a original, mas as
diferenças não são percebidas ou, ainda que o sejam, são consideradas
aceitáveis para a aplicação.
19
há garantia de que o serviço será realizado com sucesso, nem mesmo de
desempenho. Entretanto muitas aplicações necessitam de tais garantias e uma
delas é a Telefonia IP, que é dita como uma aplicação intolerante de tempo real.
Isso se justifica porque segundo Nazario (2003) as pessoas não toleram atrasos na
voz de mais de 200ms, ou seja, o retardo fim a fim do tráfego de voz deve estar
dentro de limites que dependem da aplicação, podendo variar:
latência;
largura de banda;
20
esses algoritmos sejam difíceis de implementar na prática, eles podem garantir um
limite superior na latência em alguns fluxos de dados.
Segundo RNP (1999), atualmente existem dois modelos desenvolvidos pelo
IETF para implementar QoS na Internet: serviços integrados (IntServ) e serviços
diferenciados (DiffServ). IntServ é modelo baseado na reserva de recursos,
enquanto que serviços diferenciados é uma proposta onde os pacotes são marcados
de acordo com classes de serviços pré-determinadas.
2.5.1 TCP/IP
21
roteamento, ou seja, conduzindo os dados para os endereços corretos. Na verdade,
os dois protocolos se completam: enquanto o IP identifica os endereços e cuida para
que os dados sejam enviados pelo meio físico, o TCP verifica se estes dados
enviados foram transmitidos corretamente (TUTORIAL, 2004).
Os protocolos do TCP/IP atuam em camadas. A idéia é que cada camada de
software utilize e preste serviços para outras camadas. São 4 as camadas que
formam o TCP/IP:
2.5.2 UDP
22
protocolo TCP. O UDP nada mais é do que uma interface para o protocolo IP. Esse
protocolo substitui o protocolo TCP quando a transferência dos dados não precisa
estar submetida a serviços como controle de fluxo.
A função básica do UDP é servir como multiplexador e demultiplexador para
o tráfego de informações do IP. Assim como o TCP trabalha com portas que
orientam adequadamente o tráfego de informação a cada aplicação de nível
superior. Essas portas são:
2.5.3 RTP
23
multiplexação e soma de verificação do UDP para estabelecer uma comunicação fim
a fim. As informações de áudio e vídeo produzidas pelo aplicativo remetente são
encapsuladas em pacotes RTP que por sua vez são encapsulados em um segmento
UDP. De acordo com Hersent (2002), quando uma transmissão é iniciada, uma
sessão RTP é criada a partir da comunicação entre os usuários da sessão. Cada
participante usa dois endereços de transporte, no caso do IP, por exemplo, são
utilizadas duas portas UDP na máquina local para cada sessão: uma para o fluxo
RTP e a outra para mensagens RTCP. Conforme Medeiros (2004), o RTP permite
basicamente a especificação dos requisitos de tempo e conteúdo pertinentes à
transmissão multimídia, tanto no envio quanto na recepção através de:
24
O protocolo RTP, por não ser orientado à conexão, não monitora a
transmissão e a recepção dos pacotes. Esta tarefa é realizada por outro protocolo, o
RTCP que será abordado posteriormente.
Na figura 9 é demonstrado o formato do pacote RTP.
timestamp (32 bits): reflete o instante em que foi criado o primeiro octeto
de dados do pacote, este tempo deve ser fornecido por um clock preciso
e serve para efetuar a sincronização e o cálculo do jitter do lado do
cliente;
2.5.4 RTCP
27
Através da figura 10 pode-se ter uma idéia da simplicidade do SIP em
relação ao H.323, levando em consideração o número de protocolos utilizado por
cada um.
28
3 SIP
3.1 INTRODUÇÃO
29
hop pode ser outro servidor proxy, um UAS ou um servidor de
redirecionamento;
30
Figura 11 – Mensagem de pedido SIP
Call-ID: a primeira parte deste campo deve ser um padrão único dentro
de cada computador e a última um nome de domínio ou endereço IP
(roteáveis) de uma máquina;
31
Cseq: cada pedido deve possuir este campo, composto por um número
de seqüência sem sinal e pelo nome do método que identifica o pedido
que está sendo enviado. A cada novo pedido um número de seqüência é
incrementado iniciando com um valor aleatório. As únicas exceções são
os pedidos ACK e Cancel, que mantêm o número “Cseq” da resposta
recebida (para ACK) ou do pedido cancelado (para o Cancel). No caso
mensagens do tipo resposta, o servidor deve copiar o valor “Cseq” do
pedido para as respostas correspondentes conforme a figura 13.
32
Segundo Nazario (2003), além dos campos do cabeçalho geral, uma
mensagem de pedido pode transportar campos com informações específicas dos
pedidos. O campo “Accept” é utilizado para indicar os tipos de mídia aceitáveis na
resposta e o campo “Subject” para transportar informações sobre a natureza da
chamada.
Os campos que terminam com CR e LF são utilizados para determinar uma
linha em branco entre os campos.
Todos os pedidos SIP são enviados do terminal cliente para o terminal
servidor e podem ser realizados através de diferentes métodos:
ACK: este pedido é enviado pelo cliente para confirmar que ele recebeu
uma resposta final do servidor, como 200 OK;
Cancel: este pedido pode ser enviado para interromper um pedido que foi
enviado anteriormente enquanto o servidor ainda não tiver enviado uma
resposta final;
33
Figura 13 – Resposta SIP
34
3.2 ENDEREÇOS SIP
3.3 SDP
35
A lista contendo todos os campos do protocolo SDP está descrita no RFC
3264. Os campos utilizados por este trabalho e que foram descritos na área de
dados SDP dos pedidos e respostas SIP são:
36
Caso seja usada uma chave secreta conhecida por ambos (emissor e
receptor), o receptor da mensagem será capaz de decriptografar a mensagem
criptografada pelo remetente.
A figura 15 mostra um exemplo de um pedido SIP criptografado.
37
4 CONCEITOS DE CRIPTOGRAFIA
4.1 INTRODUÇÃO
38
não-repúdio: o emissor da mensagem não poderá negar posteriormente
a autoria da mesma.
4.2 CRIPTOGRAFIA
39
4.2.1 Sistemas de Chaves Simétricas
40
4.2.2 Sistemas de Chaves Assimétricas
41
5 DESENVOLVIMENTO DO TRABALHO
5.1 INTRODUÇÃO
42
5.3 ESPECIFICAÇÃO
43
A segunda chave secreta “q” é uma chave interna pré-definida no protótipo
de Telefonia IP que irá criptografar a chave de sessão “k” escolhida pelo originador
da chamada. Depois de criptografada a chave “k” será enviada através de um
pedido de “INVITE” ao receptor conforme o modelo de mensagem SIP construída
neste protótipo e ilustrada na figura 21.
44
Figura 22 – Diagrama de Caso de Uso
45
Depois do originador da chamada
receber o “200 OK” do receptor e
enviar a resposta “ACK” para
finalizar a negociação a sessão está
praticamente estabelecida.
Enviar Áudio Criptografado Efetuar Ligação Após o estabelecimento da sessão
VoIP o usuário está apto a enviar
áudio capturado, comprimido,
criptografado e enviado via RTP.
Receber Áudio Efetuar Ligação Após o estabelecimento da sessão
Criptografado VoIP o usuário está apto a receber
áudio capturado, comprimido,
criptografado e enviado via RTP.
Desligar Efetuar ligação Após o estabelecimento da sessão
VoIP o tanto o originador da
chamada quanto o receptor podem
enviar um pedido “BYE” para
finalizar a sessão.
Cancelar Ligação Efetuar ligação Antes do estabelecimento da
sessão VoIP o originador da
chamada pode enviar o pedido
“CANCEL” ao receptor antes de
receber a resposta do pedido de
“INVITE” enviado anteriormente.
Desabilitar Criptografia Efetuar ligação Após o estabelecimento da sessão
VoIP o usuário pode desabilitar a
opção de criptografia dos pacotes
de voz enviados via RTP.
Decriptografar Áudio e Receber Áudio O algoritmo AES decriptografa os
Reproduzi-lo Criptografado pacotes de áudio recebidos via RTP
através da chave secreta de sessão
previamente definida e os reproduz
via biblioteca utilizada.
Enviar MensagemSIP Criar Sessão O envio de mensagem ocorre de
VoIP acordo com a mensagem recebida,
ou seja, as mensagens podem ser
enviadas como um pedido ou como
uma resposta a este.
46
Figura 23 – Estrutura de Camadas do Protótipo
Para Furlan, apud Nazario (2003, p.35) “o diagrama de classes é usado para
mostrar a estrutura lógica mostrando elementos tais como: classes, tipos atributos e
métodos”. A figura 24 mostra o diagrama de classes de controle e gerenciamento do
protótipo.
47
Figura 24 – Diagrama de Classes de Controle e Gerenciamento
Abaixo são descritos os papéis desempenhados por cada uma das classes
do diagrama de classes de controle e gerenciamento:
48
Classe SIPClass: implementa o tratamento das mensagens SIP. Utiliza a
classe “UDPClass” para enviar e receber as mensagens sob forma de
pacotes UDP;
5.4 IMPLEMENTAÇÃO
49
5.4.1 Visual C++ 6
5.4.2 JVOIPLIB
O termo JVOIPLIB significa Jori’s VoIP Library. Esta biblioteca foi escrita por
Jori Liesenborgs e fornece recursos para implementação de aplicações de VoIP
50
através de uma interface simples e extensível para criação e gerenciamento de
sessões VoIP (LIESENBORGS, 2004).
Ela possui basicamente a função de criar uma sessão de VoIP, transmitir
voz e destruir a sessão VoIP. Suas sessões altamente configuráveis permitem ainda
que atributos previamente escolhidos pelo usuário como a taxa de amostragem,
intervalo da amostra, tipo de compressão e etc, possam ser alterados durante a
sessão já estabelecida.
De acordo com Liesenborgs (2004) os seguintes módulos descritos contêm
os componentes a serem utilizados em uma aplicação VoIP:
método de localização.
51
Figura 26 – Classes de Criação da Sessão
Depois que a sessão estiver ativa, torna-se necessário definir para onde os
dados VoIP devem ser enviados. As funções membro AddDestination e
DeleteDestination da classe JVoIPSession são responsáveis por essa definição
podendo especificar tanto destinos unicast como multicast. A função
DeleteDestination é utilizada na finalização da sessão.
Após o estabelecimento da sessão, a classe VoiceCall, em conjunto com
outras subclasses, fica responsável pelo tratamento e transmissão da voz sobre o
protocolo IP.
52
Depois de terminada a conversação, para destruir a sessão é chamado o
método Destroy da classe JVoIPSession.
A biblioteca JVOIPLIB utiliza o serviço de outras duas bibliotecas para prover
a sessão VoIP. Uma delas é a JRTPLIB que dá suporte ao RTP no envio e
recebimento de pacotes. A outra JThread, como o próprio nome supõe, facilita o uso
de threads em diferentes plataformas.
Quadro 4 – JThread
5.4.3 Protótipo
53
Após essa primeira etapa o usuário poderá inicializar o protótipo executando
o programa Tcc.exe, onde será lhe apresentada a tela da figura 29.
A tela inicial representa a interface que o usuário possui para realizar suas
chamadas. A partir dela o usuário poderá:
fechar a aplicação.
54
Depois de escolher o usuário de destino e preencher os campos “Assunto” e
“Chave de Sessão”, o originador estará apto a realizar uma chamada pressionando
botão “Ligar” com o mouse para realizar uma chamada com o usuário de destino
escolhido através uma conexão segura conforme ilustra a figura 30.
55
Figura 31 – Pedido INVITE
56
confirmar o recebimento da resposta “200 OK” enviada por Gerson e a sessão VoIP
é então estabelecida como mostra a figura 33.
57
Figura 34 – Finalização de Sessão por “BYE”
58
6 CONCLUSÃO
59
usuários que estão se comunicando e aplique a técnica de sniffing, este intruso vai
poder conhecer a chave de sessão e conseqüentemente a voz que está sendo
trafegada.
Apesar da aplicação desenvolvida possuir essa vulnerabilidade, o principal
objetivo de criar um sistema de Telefonia IP criptografado baseado no padrão SIP foi
atendido, já que o fluxo RTP de dados é criptografado e decriptografado para a
reprodução do áudio no seu receptor depois de estabelecida a sessão de VoIP
através das mensagens SIP.
60
7 REFERÊNCIAS BIBLIOGRÁFICAS
ARAÚJO, Lúcia Goretti Gonçalves de. Apostila de UML. Disponível em: <
http://www.sdsi.uri.br/geoob/>. Acesso em: 15 de mai. 2005.
CRN. A hora e a vez da voz sobre IP. Brasil, [2002]. Disponível em:
<http://www.crn.com.br/recapa/artigo.asp?id=23059>. Acesso em: 24 jul. 2004.
GUIMARÃES, José Liesse Bollos. Voz sobre IP. Brasil, [1999]. Disponível em:
<http://www.gta.ufrj.br/grad/98_2/liesse/relat.html>. Acesso em: 16 de ago. 2004.
61
INTERNET ENGINEERING TASK FORCE. RFC 2327: Session Description Protocol.
New York, 2002. 16p.
62
SOUSA, José Márcio de. Protótipo de um sistema VoIP (Voz sobre IP). Blumenau,
2001. 53f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da
Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de
Blumenau.
63