Embed Size (px)
Citation preview
Afonso Satoshi Akiba, GRR20020046Alessandro Kuniyoshi Tachibana, GRR20024753
TELEFONE CELULAR COMO ELEMENTO DE AUTENTICAÇÃO PARA ACESSO VIA INTERNET
Curitiba2008
Monografia apresentada a Universidade Federal do Paraná, como requisito para a conclusão do curso de Engenharia Elétrica, orientada pelo professor Dr. Eduardo Parente Ribeiro.
1 INTRODUÇÃO ........................................................................................................... 5 2 FUNDAMENTAÇÃO TEÓRICA ............................................................................... 12
2.1 O QUE É AUTENTICAÇÃO ............................................................................... 12 2.1.1 Algo que o usuário possui ....................................................................... 12 2.1.2 Algo que o usuário é ................................................................................. 13 2.1.3 Algo que o usuário conhece .................................................................... 13
2.2 O PROTOCOLO SSH ........................................................................................ 13 2.3 O PROTOCOLO SSL/TLS ................................................................................. 14
3 MONTAGEM DO PROJETO ................................................................................... 18 3.1 SERVIDOR ........................................................................................................ 18
3.1.1 Apache ....................................................................................................... 19 3.1.2 MySQL ........................................................................................................ 19 3.1.3 PHPBB ........................................................................................................ 21 3.1.4 O Software Proposto ................................................................................ 22
3.1.4.1 O primeiro estado ................................................................................. 23 3.1.4.2 O segundo estado ................................................................................ 24 3.1.4.3 O terceiro estado .................................................................................. 24 3.1.4.4 A geração da senha do lado servidor .................................................. 25 3.1.4.5 O software no celular ........................................................................... 27 3.1.4.6- Funcionamento do software no celular ............................................... 27
4 CONCLUSÕES ........................................................................................................ 28
2
Lista de Figuras:
Figura 1: Mapa da Europa com as proporções de telefone móveis em relação à população. Fonte: Wikipedia. 2008c.........................................................................8Figura 2: Localização no SSL entre as camadas de rede. Fonte: SUN Reference Guide, 2006................................................................................................................16Figura 3: Diagrama demonstrando a troca de mensagens no protocolo SSL Fonte: SUN Reference Guide, 2006.........................................................................16Figura 4: Diagrama demonstrando a troca de mensagens no protocolo SSL...18Figura 5: Diagrama temporal representando as fases de execução do sistema......................................................................................................................................26Figura 6: Diagrama ilustrando possível tentativa de comprometimento do sistema.......................................................................................................................28Figura 7: Diagrama ilustrando tentativa de comprometimento do sistema.......29
Lista de Tabelas:
Tabela 1: Dados de vendas e participação de mercado de fabricantes de celular. Fonte: Gartner Group, 2008..........................................................................8Tabela 2: Vendas por região e variação em relação ao ano anterior. Fonte: Gartner Group, 2008....................................................................................................9Tabela 3: Funcionalidades criprográficas do pacote Java. Fonte: SUN Reference Guide, 2006..............................................................................................15Tabela 4: Tabela com as colunas do banco de dados PHPDB............................20Tabela 5: Tabela com as colunas do banco de dados JAVADB..........................20
3
1 INTRODUÇÃO
As comunicações de dados digitais por redes de computadores trazem
problemas para a confidência das informações transmitidas, pois mesmo que não
seja destinatário das mensagens enviadas, uma pessoa pode ter acesso aos dados.
Há também a dificuldade de se garantir a identidade das partes comunicantes.
O primeiro problema, o de acesso indevido por terceiros, deriva-se da infra-
estrutura da Internet, que depende de equipamentos roteadores em todos os locais
do planeta onde se necessita acesso. Por isso, qualquer entidade pode colocar um
equipamento na rede, desde que seguindo as regras básicas para permitir
conectividade entre a rede e o novo equipamento. Basta instalar um equipamento
chamado switch – ou outro chamado hub – em um ponto qualquer da Internet, que
se pode observar todo o tráfego que se passa naquela região da rede. Para se
analisar o tráfego capturado, utiliza-se um software, normalmente chamado
analisador de tráfego, que é capaz de abrir os pacotes transmitidos e decodificar o
conteúdo. Para reduzir esse problema, pode ser utilizada uma codificação extra na
carga de dados em cada pacote, chamada criptografia. A criptografia é um método
para cifrar uma mensagem de forma que somente o destinatário tenha capacidade
de decifrá-la.
O segundo problema, o de assegurar a identidade das partes comunicantes,
pode ser tratado utilizando-se de métodos de autenticação. Um método de
autenticação baseia-se em uma ou mais informações que unicamente identificam
uma pessoa ou entidade. No caso de uma pessoa, pode ser um aspecto físico,
como a impressão digital; ou algo que somente ela saiba, como uma senha. Pode
também ser um objeto único que esteja em sua posse, como uma carteira de
4
habilitação para dirigir. Em situações de comunicações digitais, outros
identificadores são endereços IP, nomes de domínio, certificados e assinaturas
digitais.
Normalmente, são feitas verificações de autenticidade do servidor que está
sendo acessado usando checagens de DNS (Domain Name System), observando
certificados digitais e, mais recentemente, com ferramentas anti-phishing,
específicas dos navegadores, que buscam em um grupo de repositórios centrais as
informações quanto à autenticidade de um site. Por isso, é relativamente garantido
que se esteja realmente visitando determinado endereço eletrônico na Internet, salvo
casos em que o usuário é infectado por algum vírus de computador que executa
instruções à sua revelia.
É por esse motivo que é na parte do usuário que se encontram os maiores
problemas quanto à identidade, pois os métodos simples – usar senhas para
autenticar acesso – não oferecem um nível adequado de segurança, enquanto um
método mais seguro, como usar assinaturas digitais nas comunicações não é
facilmente utilizável e nem viável para a maioria dos usuários na Internet.
Se a identidade de um usuário é comprometida, o indivíduo que a
comprometeu pode se passar por outra pessoa e obter acesso a recursos ao quais
não deveria. Pode também enviar mensagens eletrônicas falsas como se fosse o
próprio usuário.
Uma forma de se reduzir esses problemas está em devidamente autenticar o
usuário ao servidor. Se confirmada sua identidade, a confiança gerada permite
trocas de informações confidenciais e também que tais informações sejam de
responsabilidade de que a enviou.
5
Para autenticar uma pessoa deve-se poder unicamente identificá-la dentre
todas as outras que potencialmente acessam o serviço usando-se de informações
inerentes somente àquela pessoa como, por exemplo, senhas e carteiras de
identidade. Pode-se também utilizar objetos pessoais que sejam unicamente
identificáveis uns dos outros.
A telefonia celular está grandemente difundida em praticamente todo o
mundo. Alguns lugares como, por exemplo, Hong Kong (OFTA, 2008) e países
europeus como Áustria (RTR, 2008) já possuem índices de posse de aparelhos
celulares superiores a população total do país. Outros países atingem índices que se
aproximam da totalidade, enquanto na África, por causa da baixa penetração de tais
aparelhos, a taxa de crescimento é aproximadamente o dobro da taxa mundial
(BBC, 2005) e, em poucos anos atingirá patamares de densidade de acessos
elevados. Mesmo dentro do Brasil, no Distrito Federal a quantidade de aparelhos
celulares já é superior à população. Na média, a densidade de acessos móveis já é
superior a 65% no Brasil (ANATEL, 2008).
6
Figura 1: Mapa da Europa com as proporções de telefone móveis em relação à população. Fonte: Wikipedia. 2008c.
De acordo com uma pesquisa por nós realizada no catálogo de produtos dos
maiores fabricantes de aparelhos celulares do mundo, estas ofertam mais de 80%
(Nokia - catálogo, 2008; Motorola – catálogo, 2008; LG - catálogo, 2008; Samsung -
catálogo, 2008; Sony-Ericsson - catálogo, 2008) de seus produtos com suporte Java
móvel, o que nos possibilita desenvolver um software capaz de carregar o
identificador do usuário que abranja um grande número de potenciais usuários,
Companhia1Q08 Vendas (x1000)
1Q08 Participação de Mercado (%)
1Q07 Vendas (x1000)
1Q07 Participação de Mercado (%)
Nokia 115.191,8 38,1 92.048,1 35,5Samsung 42.396,5 14,4 32.099,8 12,4Motorola 29.884,7 10,2 47.620,7 18,4LG 23.645,8 8 16.009,3 6,2Sony-Ericsson 22.061 7,5 21.771,5 8,4Outros 61.103,2 20,8 49.489,8 19,1Total 294.283 100 259.039,2 100Tabela 1: Dados de vendas e participação de mercado de fabricantes de celular. Fonte: Gartner
Group, 2008
7
1Q08 Vendas (Milhões)
Variação em rela-ção à 1Q07 (%)
Ásia/Pacífico 114,4 26,6Europa Oriental, Oriente Médio, África 56,4 25,8Japão 13,2 -10,1América Latina 32,5 28,4América do Norte 41,9 2,4Europa Ocidental 35,9 -16,4
Tabela 2: Vendas por região e variação em relação ao ano anterior. Fonte: Gartner Group, 2008
Na tabela 2 se pode verificar que as regiões com menor crescimento ou que
até apresentam decrescimento no número de aparelhos vendidos são aquelas onde
o mercado já está em estado mais avançado de consolidação. Nesses mercados os
telefones celulares já estão bastante difundidos, não havendo mais espaço para
crescimento vegetativo da base instalada. Também não ocorreram grandes
inovações em termos de funcionalidade adicional nos aparelhos.
Regiões com menor saturação da base instalada contam com taxas maiores
de crescimento e, com a oferta de modelos de telefone celular atual, já se pode
considerar um grande aumento na base instalada de telefones com suporte Java, o
que eleva a abrangência de nossa proposta de software também a esses países,
Brasil incluído.
Por causa desses fatores, uma das condições básicas para implantação do
sistema é facilmente satisfeita, que é o custo zero ou próximo de zero para o usuário
obter o hardware necessário. Evidentemente o custo do aparelho celular não é zero,
mas pode ser considerado amortizado, pois fator motivador da compra do celular é
outro, na maioria dos casos; usar o celular para conversar.
O objetivo de nosso projeto é contornar o problema de autenticação segura
dos usuários para utilização de serviços na Internet, onde o simples uso de senhas
já não é suficiente para garantir a identidade do usuário, oferecendo um método de
8
autenticação mais segura. Para isso, utilizaremos, além de senhas de acesso,
identificação por posse de um identificador instalado no aparelho de telefonia celular
do cliente.
Nossa solução baseia-se no conceito de autenticação em múltiplas etapas,
utilizando mais de um tipo delas para tornar o método mais resistente contra ataques
à privacidade do usuário. O Mecanismo proposto prevê a utilização de uma semente
de identificação, que é uma seqüência aleatória de 64 bytes de tamanho, além da
senha. Para acessar um serviço da Internet que requeira autenticação, bastaria que
o usuário possuísse um aparelho de telefone celular e tivesse previamente efetuado
cadastro no serviço de autenticação para poder dispor de um nível maior de
segurança no acesso.
Possíveis usuários para o serviço seriam correntistas de instituições
financeiras, listas de discussão (fóruns de Internet) e comunidades que dependem
de contribuição pública com segurança quanto à identidade dos participantes
(Wikipedia, por exemplo).
Em nosso projeto, colocaremos no ar um fórum de discussões eletrônico
utilizando este mecanismo. Este tipo de serviço permite que os usuários discutam
sobre determinado assunto através de postagens visíveis aos membros do fórum ou
a qualquer pessoa se assim o administrador do fórum decidir. Mesmo que as
discussões sejam tornadas públicas, normalmente é requerido um cadastro para
garantir a identidade das pessoas participantes e para que seja possível tomar
medidas para moderar o seu comportamento.
O objetivo será que um usuário tenha possibilidade de acessar as áreas
restritas utilizando para isso seu celular para obter a semente de identificação e
9
assim prevenir que outro usuário com intenções maliciosas consiga personificá-lo e
pôr em risco sua identidade.
No capítulo seguinte apresentaremos a fundamentação teórica, com as
ferramentas utilizadas no projeto, além de alternativas consideradas e tecnologias já
existentes. Depois, há uma explicação detalhada dos processos realizados e das
configurações executadas, além de casos de possíveis falhas de segurança e as
medidas cabíveis para proteger o usuário.
Por fim, discutimos as conclusões obtidas, os problemas encontrados e as
decisões tomadas, e também possibilidades de desenvolvimento futuro da
tecnologia.
10
2 FUNDAMENTAÇÃO TEÓRICA
2.1 O QUE É AUTENTICAÇÃO
Autenticação é a confirmação da autenticidade da identidade digital do
usuário, a confirmação é efetuada pelo fator de autenticação e podem ser
classificados em três casos:
• Algo que o usuário possui;
• Algo que o usuário conhece;
• Algo que o usuário é;
Um ou mais fatores podem ser usados para confirmar a identidade, os casos
em que é utilizado dois ou mais fatores podem ser classificados como uma
autenticação em duas etapas.
O uso de múltiplos fatores de autenticação implica em um nível maior de
segurança, pois não é exclusivamente dependente de uma única informação,
dificultando acessos por pessoas não autorizadas, pois são duas informações a
serem comprometidas (Authentication World, 2008).
2.1.1 Algo que o usuário possui
As formas mais comuns de posse são os smart cards e os USB tokens.
Ambos contêm informações únicas para realizar a autenticação do usuário.
(Authentication World, 2008)
11
2.1.2 Algo que o usuário é
São utilizadas características físicas únicas de um usuário. Como a
impressão digital, a imagem da íris do olho ou até mesmo a face da pessoa.
Geralmente a implementação de uma característica física como forma de
autenticação tem um custo elevado e um dos problemas é que uma vez quebrada a
segurança, os dados de autenticação não podem mais ser mudados, pois dependem
das características físicas do usuário. (Authentication World, 2008)
2.1.3 Algo que o usuário conhece
São as senhas e os PINs. O uso da senha vem desde tempos antigos onde
uma sentinela apenas permitia a passagem de alguém caso respondesse a pergunta
com a resposta certa. O nível de segurança geralmente é baixo. O motivo é que
normalmente as senhas utilizadas são facilmente quebradas por alguém que tenha a
intenção de fazê-lo, pois são utilizados dados como datas de nascimento, dados de
endereço ou palavras contidas no dicionário. (Authentication World, 2008)
2.2 O PROTOCOLO SSH
O protocolo SSH (Secure Shell) é um protocolo de rede que permite que a
comunicação por terminal remoto através de um canal seguro entre dois
computadores.
O SSH faz conexões entre computadores e assegura a autenticação, a
criptografia e a integridade dos dados de uma transmissão.
12
Na autenticação, por exemplo: para se efetuar o logon em um computador
remoto, será necessário que o SSH aceite a assinatura digital que lhe é enviada,
caso contrário a conexão é rejeitada. Na criptografia o SSH codifica os dados para
que não sejam lidos por terceiros protegendo os dados.
Caso algum terceiro intercepte os dados e os modifique, o SSH também tem
a função de detectar alterações nos dados transmitidos.
Porém o SSH não é uma solução de segurança completa, pois não protege
os computadores contra ataques massivos de hackers, e também não elimina vírus
e cavalos de tróia.
A primeira versão do SSH, o SSH-1, foi desenvolvida para adicionar
segurança a serviços de TELNET (Telecommunication Network), RSH (Remote
Shell) e rlogin.
Uma nova iteração do protocolo foi desenvolvida para melhorar o nível de
segurança e apresenta melhorias como o protocolo de derivação de chaves Diffie-
Hellman (IETF, 1999), mas não apresenta compatibilidade com a versão anterior, o
que impede a adoção do protocolo sem uma migração total da base instalada de
SSH1 para SSH2 (O’Reilly, 2003).
2.3 O PROTOCOLO SSL/TLS
O protocolo SSL, desenvolvido em 1994 pela Netscape, é o mais
amplamente utilizado para efetuar comunicações seguras de dados pela Internet.
Ele usa uma combinação de processos criptográficos para garantir a confidência e
integridade dos dados transmitidos. Com contribuições advindas da comunidade da
Internet, tornou-se um padrão e agora é mantido pela IETF (Internet Engineering
13
Task Force), que mudou seu nome para TLS (Transport Security Layer). Apesar da
mudança de nome, ainda é muito utilizado o nome SSL, pois as mudanças
implantadas desde a versão 3 do SSL até a primeira versão do TLS são mínimas.
Funcionalidades criptográficas disponíveis no JSSE
Algoritmo de Criptografia
Processo de Criptografia Comprimento das Chaves
(Bits)
RSA Authentication and key exchange
512 and larger
RC4 Bulk encryption 128128 (40 effective)
DES Bulk encryption 64 (56 effective)64 (40 effective)
Triple DES Bulk encryption 192 (112 effective)
AES Bulk encryption 256128
Diffie-Hellman Key agreement 1024512
DSA Authentication 1024
Tabela 3: Funcionalidades criprográficas do pacote Java. Fonte: SUN Reference Guide, 2006O protocolo SSL é inserido entre as camadas de transporte e de aplicação,
ou seja, sobre a camada TCP e antes dos protocolos de aplicação como, por
exemplo, HTTP (hypertext transfer protocol) ou IMAP (interactive message access
protocol).
14
Figura 2: Localização no SSL entre as camadas de rede. Fonte: SUN Reference Guide, 2006
SSL tem três funções; garantir a identidade das partes que efetuam a
comunicação, garantir a privacidade das comunicações, impedindo que terceiros
tenham acesso ao conteúdo das mensagens, e garantir a integridade dos dados
recebidos, através da utilização de checksums, as funções de hash seguras.
A primeira função é de uso opcional, e garante a identidade das partes
comunicantes através da utilização de certificados digitais. Cada parte apresenta à
outra seu certificado digital que, se aceito, permitirá às duas partes continuar o
processo de negociação da sessão.
Figura 3: Diagrama demonstrando a troca de mensagens no protocolo SSL Fonte: SUN Reference Guide, 2006.
15
Após realizar a troca de certificados, ocorre o processo de negociação do
melhor conjunto de chaves criptográficas para as duas partes. As chaves secretas
acordadas são transmitidas à outra parte criptografadas com a chave pública obtida
do certificado digital. Após essa troca, as comunicações subseqüentes já passam a
utilizar o algoritmo de criptografia selecionado.
A proteção da integridade dos dados é feita através da utilização de hashs
criptográficos, que detectam se houve algum tipo de alteração dos dados no caso de
os dados terem sido interceptados. A implementação no protocolo SSL é através do
HMAC, o hash do message authentication code, que são hashes criptográficos
baseados em uma chave criptográfica secreta, conhecida apenas pelas partes
comunicantes. (SUN Reference Guide, 2006)
16
3 MONTAGEM DO PROJETO
O sistema é uma combinação de banco de dados, servidor web e aplicativos
Java e é instalado em dois lugares: um servidor, que abriga o serviço que precisa da
autenticação e o sistema de autenticação; e o telefone celular, que abriga a semente
de identificação – que é uma seqüência numérica gerada aleatoriamente com 64
bytes – e o software gerador de senhas de acesso.
Figura 4: Diagrama demonstrando a troca de mensagens no protocolo SSL
3.1 SERVIDOR
No lado do servidor fica instalado um servidor web Apache, cuja função é
disponibilizar documentos para acesso por um computador externo através de um
navegador Internet (browser). Fica instalado também um software de fórum, escrito
em PHP, o PHPBB na terceira versão, um banco de dados MySQL e o software
proposto, que faz a interface entre banco de dados e a página web do fórum, e
também a autenticação dos usuários. Em conjunto com os scripts do fórum, foi
17
acoplado um aplicativo Java que, depois de carregado na máquina do usuário,
executa conexão com o programa no lado do servidor.
3.1.1 Apache
O servidor Apache está configurado para servir seus documentos no
servidor escutando na porta TCP 8253. O diretório-base foi alterado para apontar
para a base de documentos do diretório de instalação do PHPBB, além disso,
Apache foi configurado para permitir acesso somente a esse local.
Como o endereço IP da máquina não tem um domínio registrado, para
acessar o site é necessário digitar o endereço IP e a porta na barra de endereços do
navegador. Exceto por essas alterações, a configuração do Apache foi deixada
muito próxima daquela que é o padrão de fábrica.
3.1.2 MySQL
O banco de dados é utilizado para armazenar todas as informações sobre
usuários e suas postagens no fórum e também para armazenar as configurações e
permissões de acesso para o fórum.
A instalação do banco de dados foi realizada de forma a conter duas bases
de dados. A primeira base, a partir daqui chamada PHPDB, foi criada junto com um
usuário específico para o fórum realizar a conexão e efetuar transações com o
banco de dados. Esse usuário é também utilizado pelo aplicativo no momento no
qual o usuário tenta a autenticação.
Depois de criado o banco de dados para o fórum, PHPDB, o próprio
programa do fórum se encarrega de criar as tabelas necessárias. No total, foram
18
criadas sessenta e duas tabelas para as configurações, conteúdo das mensagens e
opções de usuários. Os campos principais do PHPDB no sistema de autenticação
estão descritos a seguir:
Nome da Coluna Tipo de Dado
username VARCHAR
user_password VARCHAR
user_last_access INTEGER
Tabela 4: Tabela com as colunas do banco de dados PHPDB
Na tabela de usuários foi adicionada uma coluna para o propósito de
autenticar o usuário pelo nosso sistema. É uma coluna que armazena dados do tipo
INTEGER, que guarda um timestamp, em formato UNIX para marcar o instante de
tempo no qual o usuário efetuou a geração de senha e evitar acessos duplicados ou
que a senha se mantenha a mesma por um período de tempo excessivo. O nome
dessa coluna adicional é “user_last_access”. Além disso, são usados os campos de
nome de usuário para identificação e é alterado o campo de senha a cada vez que é
gerada uma nova senha.
A segunda base de dados, chamada JAVADB, serve ao aplicativo Java e é
acessada através de um programa criado especificamente para essa função, para
recuperar a semente para o usuário e para gerar a senha de acesso e armazena-la
na base de dados do fórum. Essa base é formada por apenas uma tabela e possui
os seguintes cinco campos:
Nome da Coluna Tipo de Dado
Username VARCHAR
Password VARBINARY
User_ID INTEGER
Token (semente) VARBINARY
FLAG TINYINT
Tabela 5: Tabela com as colunas do banco de dados JAVADB
19
A primeira coluna indica o nome com o qual o usuário irá se autenticar no
fórum. O dado é armazenado como texto banco de dados. A segunda coluna é o
campo de senha para acessar o gerador das senhas da semente. Essa senha é
armazenada como um hash em valor binário e não varia com o tempo, mas não dá
acesso a nenhuma parte do fórum. O terceiro campo é o índice da entrada no banco
de dados, em formato de numeral inteiro. O quarto campo armazena o token, ou
semente, de identificação do usuário em valor binário e a quinta coluna armazena
um marcador para indicar a retirada da semente do banco de dados. O formato de
armazenamento de FLAG não é boolean porque não é suportada pela versão do
MySQL utilizada (MySQL5.0 Reference Manual, 2008).
3.1.3 PHPBB
O PHPBB (PHPBB, 2008) é o software responsável por fornecer a interface
gráfica para o usuário acessar a página do fórum. Como ele é escrito em PHP, é
necessário instalar o interpretador da linguagem no servidor. A instalação do PHP
(PHP Hypertext Preprocessor) não necessita nenhuma configuração adicional.
Para adaptar o fórum às características do nosso sistema, foram executadas
modificações na função de autenticação. Originalmente o processo de autenticação
fazia a comparação das credenciais providas pelo usuário na tela de login e permitia
ou não a entrada baseado no resultado dessa comparação. Após a modificação, o
fórum executa uma comparação adicional, buscando o valor da coluna
“user_last_access” e comparando com a função “now()” do PHP. Se o resultado for
menor que 600 segundos (10 minutos), em conjunto com a identificação positiva da
outra comparação, ao usuário é garantido o acesso.
20
Toda vez que o usuário conseguir obter acesso ao fórum, a coluna de último
acesso é automaticamente zerada, para evitar conexões concomitantes.
A outra modificação foi alterar a forma como a senha é armazenada no
banco de dados. A forma original transformava a senha em um hash em formato
específico do PHP. Para garantir maior interoperabilidade entre o fórum e o
aplicativo Java, alteramos o formato de armazenamento para um hash SHA-1,
comum às duas linguagens.
3.1.4 O Software Proposto
O software proposto foi programado em Java, versão 6, funciona como um
intermediário entre o usuário em um PC remoto e o servidor. O software fica
continuamente rodando, esperando por conexões na porta 8254. O tipo de socket
utilizado é o seguro (SSL – Secure Sockets Layer) e recebe conexões feitas a partir
dos computadores dos usuários, que ativam em seus browsers o aplicativo Java
responsável pela geração do número de desafio. O software também possui uma
conexão com o banco de dados, a qual utiliza para acessar e atualizar os dados
cadastrais dos usuários.
O programa tem três modos de operação: um para registrar o usuário nas
bases de dados, o segundo para realizar a autenticação do usuário, e o terceiro para
recuperar a semente de identificação para posterior instalação no aparelho celular
do usuário.
O primeiro estágio de funcionamento é a espera por uma conexão. O
aplicativo se mantém em estado dormente até a recepção da primeira conexão.
Quando isso acontece, é gerado um processo que passará a rodar em segundo
21
plano enquanto o processo principal retorna à dormência para esperar pela próxima
conexão.
Após o início de cada processo é realizado o procedimento de
estabelecimento de conexão SSL e o processo entra na fase da seleção do modo de
operação (“STATE”). Nesse estado o programa volta a aguardar comunicação por
parte do PC cliente de uma mensagem prefixada com “STATE“. Os valores válidos
são 1, 2 e 3.
3.1.4.1 O primeiro estado
Este é o modo de registro de usuário no sistema. Após a mensagem de
seleção de modo de operação, o usuário deve enviar o nome com o qual deseja se
identificar e uma senha para garantir privacidade e assegurar o primeiro nível de
autorização. Essas mensagens são prefixadas com “NAME:” e “PASS:”.
Depois de certificar que as mensagens foram recebidas com a devida
formatação, o servidor realizará a geração da semente. O processo consiste em
combinar os caracteres do nome e da senha fornecidos pelo usuário, adicionar o
valor do horário de registro no site e passar essa seqüência por um algoritmo de
hash SHA-512. Os valores de nome, senha e semente serão então armazenados
em seus respectivos campos no JAVADB.
Ao terminar o processo de cadastro, o servidor enviará uma mensagem ao
cliente confirmando o sucesso da operação e fechará a conexão, pois não são mais
necessárias trocas de mensagens até que o usuário realize a instalação da semente
e do gerador de senhas em seu celular.
22
3.1.4.2 O segundo estado
O segundo estado é a geração do arquivo de texto com o valor da semente
para o usuário. O aplicativo recebe as credenciais de nome e senha e realiza a
busca no JAVADB. O critério da busca é que nome e senha sejam iguais às
entradas e que a coluna “FLAG” seja igual a zero. Essa última condição serve para
impedir que o arquivo de semente seja gerado mais de uma vez, pois a retirada da
semente pela primeira vez aciona o método que atualiza “FLAG” para o valor “1”.
O arquivo da semente deve ser transferido, juntamente com o programa
gerador de senhas, diretamente para o aparelho de telefone celular através de uma
conexão USB.
3.1.4.3 O terceiro estado
Esse é o modo de acesso propriamente dito. Assume-se que o usuário já
tenha realizado o cadastro corretamente e já instalou a semente em seu celular.
Como no modo de operação anterior, o usuário inicia o modo fornecendo suas
credenciais (as mesmas que ele forneceu no momento do cadastro). O aplicativo
fará conexão com o JAVADB, para executar uma busca pelos campos de nome e
senha.
O sucesso da busca recuperará o valor da semente do usuário, que será
utilizado no processo de geração da senha de acesso pelo lado do servidor. O
sucesso da busca também dispara o início da rotina de geração de um número
aleatório para combinação com a semente. Esse valor aleatório é obtido usando-se
a função “RAND()” do MySQL em conjunção com a função “MD5()”. O resultado é
truncado para oito dígitos para evitar um número muito longo para o usuário.
23
O número aleatório é enviado ao usuário pelo soquete seguro através do
programa conector localizado no cliente e também é armazenado em um buffer para
a geração da senha pelo lado do servidor. Vale ressaltar que o valor da semente é
armazenado localmente do lado do servidor e fica atrelado à identidade do seu
respectivo usuário, não sendo necessária a transmissão desse dado, pois já é de
posse do usuário em seu celular.
3.1.4.4 A geração da senha do lado servidor
O número aleatório é combinado com o valor da semente, ambos
convertidos para formato string, e aplicados o algoritmo SHA-1. Divide-se o valor
resultante em pares de dígitos e se pega o primeiro dígito dos oito primeiros pares.
O resultado disso é a senha de acesso, que deve ter sido gerada identicamente no
lado do celular. Esse valor é então atualizado no PHPDB no campo “password”
juntamente com o campo “user_last_access” para o horário atual do acesso pelo
software do lado do servidor.
24
Figura 5: Diagrama temporal representando as fases de execução do sistema.
A partir daí, o usuário retornará à página inicial do fórum e digitará seu nome
de usuário e a senha gerada no celular. O fórum realizará o processo de
autenticação e autorizará o acesso se todas as condições forem satisfeitas.
25
3.1.4.5 O software no celular
O software, depois de compilado, é armazenado em um arquivo com
extensão “JAD” e outro com extensão “JAR”. Para instalá-lo, basta copiá-lo para o
celular e confirmar a instalação do aplicativo. O funcionamento do programa é
idêntico ao explicitado anteriormente.
As funções do programa são: carregar a semente em sua memória,
criptografar e descriptografar o seu conteúdo no armazenamento seguro e executar
o algoritmo de criação de senha.
3.1.4.6- Funcionamento do software no celular
O software do celular carrega a semente de um arquivo de texto
“TOKEN.TXT”, que foi gerado pelo servidor e foi depois copiado para o telefone
através da interface USB. O arquivo é então criptografado através da biblioteca
Icecrypt (Icecrypt, 2008) e então é armazenado no RMS (Record Management
Store), (SUN Developer Network, 2004).
O usuário deve digitar a seqüência numérica obtida na tela do computador
que acessa o fórum diretamente no celular. Após a realização das computações, a
senha é gerada e depois mostrada no visor do celular. A senha é gerada também
pelo servidor para servir de comparação com o valor obtido do usuário.
O usuário deve então digitar a nova seqüência numérica no campo
“Password” da tela inicial do fórum para obter autorização de acesso às áreas
restritas.
26
4 CONCLUSÕES
Foi implementado e testado o sistema de autenticação usando o celular
como forma de armazenamento e gerador de senha de acesso para controlar o
acesso de um usuário a um fórum de Internet.
O sistema resultou em uma forma mais segura de autenticação de usuários,
pois foi introduzida uma camada extra de segurança para autenticação. E como os
dois passos, senha e senha gerada pela semente, são necessários ao processo
completo de autenticação, mesmo que o usuário tenha sua senha copiada por um
terceiro, este não conseguirá acesso sem a posse do celular onde se encontra
armazenado a semente de identificação do usuário.
Na figura 6 é apresentado um exemplo no qual o computador utilizado pelo
usuário está infectado por um keylogger, um programa captura todos os dados
digitados pelo usuário e também os apresentados ao usuário. Não haverá quebra de
segurança se ocorrer como demonstra o diagrama, pois quando o invasor for utilizar
a senha temporária, ela já não terá mais validade.
Figura 6: Diagrama ilustrando possível tentativa de comprometimento do sistema.
27
Além disso, a semente é armazenada no celular em forma criptografada
para que, no caso de roubo ou extravio do aparelho, a semente permaneça
suficientemente segura até o usuário requisitar a anulação de sua validade e uma
nova semente precise ser gerada e emitida. O uso do celular para armazenar a
semente foi considerado mais seguro, pois além de ser um sistema pessoal do
usuário onde tem controle do que acontece, a quantidade de vírus e outras
ferramentas maliciosas existentes para os dispositivos móveis é bem menor do que
se comparado ao sistema operacional Windows.
Figura 7: Diagrama ilustrando tentativa de comprometimento do sistema.
Pode existir a possibilidade de o invasor tentar capturar os dados em tempo
real e tentar comprometer o sistema antes de o usuário efetuar o acesso, como
ilustrado na figura 7. Neste caso existe uma possibilidade real de o invasor
comprometer a segurança , ao utilizar a senha temporária antes mesmo do usuário.
Para evitar esse tipo de quebra de segurança, o serviço que for
implementado deverá verificar o endereço IP do computador que fez a requisição de
28
geração da senha e o endereço IP do computador que tentou utilizar a senha e,
caso sejam eles diferentes, o servidor deverá negar o acesso.
Inicialmente foi planejado que o programa instalado no celular pudesse
contatar o servidor e obter o retorno da seqüência aleatória para a geração da
senha. Após testes iniciais não foi obtido sucesso em conectar-se ao servidor
usando os serviços da operadora VIVO. Para tornar o projeto mais abrangente,
evitando possíveis bloqueios por parte das operadoras nas portas, foi retirada essa
funcionalidade e introduzida a funcionalidade de obtenção do número aleatório
através de um programa Java localizado no mesmo servidor do fórum, com o celular
funcionando somente para armazenar a semente e gerar a senha de acesso.
A escolha do algoritmo Icecrypt foi devida à simplicidade e melhor
desempenho em comparação a outras bibliotecas como o BouncyCastle para J2ME.
No caso do armazenamento seguro no celular foi utilizado um modo que prioriza o
desempenho para tornar o processo rápido e não depender de um modelo com um
processador muito avançado. Eventualmente, com o advento de maior capacidade
de processamento dos chips dos celulares e poderão ser facilmente implementados
algoritmos de criptografia mais sofisticados.
29
Glossário
Diffie-Hellman – protocolo que permite o estabelecimento de uma chave secreta entre dois usuários, sem qualquer tipo de conhecimento anterior de um pelo outro.
MySQL – programa utilizado para criar e gerenciar bancos de dados e que tem a sua licença open-source.
PHPDB – nome dado ao banco de dados usado pelo fórum.
RSA – algoritmo para criptografias para ser usado em chaves publicas, sigla criada partir dos sobrenomes dos criadores, Ron Rivest, Adi Shamir e Leonard Adleman.
Acrônimos:
AES - Advanced Encryption Standard, Padrão Avançado de Criptografia.
ANATEL – Agência Nacional de Telecomunicações.
BBC - British Broadcasting Corporation.
DES - Data Encryption Standard, Padrão de Criptografia de Dados.
DSA - Digital Signature Algorithm, Algoritmo de Assinatura Digital.
FTP - File Transfer Protocol, Protocolo de Transferência de Arquivos.
HMAC - Hash Message Authentication Code, Código de Autenticação de Hash de Mensagem.
HTTP - Hypertext Transfer Protocol, Protocolo de Transferência de Hipertexto.
IETF - Internet Engineering Task Force, Força Tarefa de Engenharia da Internet.
IMAP - Interactive Message Access Protocol, Protocolo de Acesso de Mensagens Interativas.
J2ME – Java 2 Micro Edition, Edição Micro do Java 2.
J2SE – Java 2 Stantard Edition, Edição Padrão do Java 2.
JSSE - Java Secure Socket Extension, Extensão de Soquete Seguro para Java.
JAD - Java Application Descriptor, Descritor de Aplicativos Java.
JAR - Java Archive, Arquivo Java
MD5 – Message-Digest algorithm 5, Algoritmo Digestor de Mensagens 5.
30
OFTA – Office of the Telecommunications Authority, Escritório da autoridade de telecomunicações (Honk Kong).
PIN - Personal Identification Number, Número de Identificação Pessoal.
PHP - Hypertext Preprocessor, Pré-processador de Hipertextos.
RC4 - Rivest Cipher 4.
RSH – Remote Shell,
RTR – Rundfunk und Telekom Regulierungs, Agência reguladora de telecomunicações e radiodifusão (Áustria).
SFTP - Secure File Transfer Protocol, Protocolo Seguro de Transferência de Arquivos.
SQL - Structured Query Language, Linguagem de Requisição Estruturada.
SHA – Secure Hash Algorithm, Algoritmo Seguro de Hash.
SSL – Secure Socket Layer, Camada de Soquete Segura.
TCP - Transmission Control Protocol, Protocolo de Controle de Transmissão.
TELNET - Telecommunication Network, Rede de Telecomunicação.
TLS – Transport Secure Layer, Camada Segura de Transporte.
USB - Universal Serial Bus, Barramento em Série Universal.
31
REFERÊNCIAS
ANATEL, 2008. Dados de Acessos Móveis. Disponivel em: <http://www.anatel.gov.br/Portal/exibirPortalRedireciona.do?codigoDocumento=213049&caminhoRel=Cidadao-Telefonia M óvel-Dados%20do %20SMP>.
Authentication World, 2008, Disponível em: <http://www.authenticationworld.com/>
BBC, 2005. Disponível em: <http://news.bbc.co.uk/2/hi/business/4331863.stm>.
Cay S. Horstmann, Gary Cornell, 2004, Core Java 2 Volume I & II, Seventh Edition, Editora: Prentice Hall PTR.
Icecrypt, 2008. Biblioteca de criptografia Icecrypt. Disponível em: http://www.darkside.com.au/ice/index.html, acessado em 2008-06-22.
IETF, 1999. Diffie-Hellman Key Agreement Method. Disponível em: http://tools.ietf.org/html/rfc2631, acessado em 2008-06-14.
LG, 2008. Modelos de telefones celulares. Disponível em: http://br.lge.com/md/product/prodcategorylist.do?actType=list&categoryId=1000000396&parentCategoryId=0000000006&categoryLevel=3, acessado em 2008-06-20.
Motorola, 2008. Modelos de telefones celulares. Disponível em: http://www.motorola.com/consumer/v/index.jsp?vgnextoid=f5f36dc0c580b010VgnVCM1000008206b00aRCRD&show=showallproduct&showSectionPage=All%20Phones, acessado em 2008-06-20.
Nokia, 2008. Modelos de telefones celulares. Disponível em: http://www.nokia.com.br/A4523227. Acessado em 2008-06-20.
OFTA. 2008 . Disponível em: <http://www.ofta.gov.hk/en/DATASTAT/eng_wireless.pdf>.
PHPBB, 2008, PHP Hypertext Preprocessor Bulletin Board. Disponível para download em: <http://www.phpbb.com/downloads/olympus.php?sid=b6f35bebe0434cc037e9320251b884b1>, acessado em 2008-06-22.
MySQL5.0 Reference Manual, 2008, Disponível em: <http://dev.mysql.com/doc/refman/5.0/en/other-vendor-data-types.html>
RTR, 2008, mobile penetration in austria, page 18 chapter 3. Disponível em: <http://www.rtr.at/en/tk/TKMonitorQ12008>.
32
Samsung, 2008. Modelos de telefones celulares. Disponível em: http://br.samsungmobile.com/mobile_phone/comparison.jsp, acessado em 2008-06-20.BARRET, Daniel J., SILVERMAN, Richard E., 2003. Secure Shell: The Definitive Guide. Editora: O’Reilly.
Sony-Ericsson, 2008. Modelos de telefones celulares.Disponível em: http://www.sonyericsson.com/cws/products/mobilephones?cc=br&lc=pt, acessado em 2008-06-20.
SUN Developer Network, 2004. Disponível em: http://developers.sun.com/mobility/midp/articles/databaserms/, acessado em 2008-06-22.
SUN Reference Guide. 2006. Disponível em: <http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html>.
Wikipedia, 2008a, Secure Shell. Disponível em: <http://en.wikipedia.org/wiki/Secure_Shell >.
Wikipedia, 2008b, Two-factor authentication, Disponível em: <http://en.wikipedia.org/wiki/Two-factor_authentication>.
Wikipedia, 2008c, Disponível em: <http://en.wikipedia.org/wiki/Image:Europe_mobile_phone_penetration_map.png, em 2008-06-14>
33
