CAMPUS QUIXADÁ
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
CAIO VINÍCIUS GOMES BALTHAZAR
UMA PROVA DE CONCEITO EM IDENTIDADE ORGANIZACIONAL MÓVEL
UMA PROVA DE CONCEITO EM IDENTIDADE ORGANIZACIONAL MÓVEL
Trabalho de Conclusão de Curso
submetido à Coordenação do Curso Bacharelado em Sistemas de Informação da Universidade Federal do Ceará como requisito parcial para obtenção do grau de Bacharel.
Área de concentração: computação
Orientador Prof. MSc. Marcos Dantas Ortiz
Dados Internacionais de Catalogação na Publicação Universidade Federal do Ceará
Biblioteca do Campus de Quixadá
B158p Balthazar, Caio Vinícius Gomes
Uma prova de conceito em identidade organizacional móvel / Caio Vinícius Gomes Balthazar. – 2013.
87f. : il. color., enc. ; 30 cm.
Monografia (graduação) – Universidade Federal do Ceará, Campus de Quixadá, Curso de Sistemas de Informação, Quixadá, 2013.
Orientação: Prof. MSc Marcos Dantas Ortiz Área de concentração: Computação
1.Computação móvel 2. Android (recurso eletrônico) 3. Criptografia de dados (computação) I. Título.
UMA PROVA DE CONCEITO EM IDENTIDADE ORGANIZACIONAL MÓVEL
Trabalho de Conclusão de Curso
submetido à Coordenação do Curso Bacharelado em Sistemas de Informação da Universidade Federal do Ceará como requisito parcial para obtenção do grau de Bacharel.
Área de concentração: computação
Aprovado em: _____ / janeiro / 2014.
BANCA EXAMINADORA
_____________________________________ Prof. MSc. Marcos Dantas Ortiz (Orientador)
Universidade Federal do Ceará-UFC
_________________________________________ Prof. Dr. David Sena Oliveira
Universidade Federal do Ceará-UFC
_________________________________________ Prof. MSc. Marcio Espíndola Freire Maia
Aos meus pais, Tarciso e Bernadete, que
sempre me motivaram a ir mais longe e me
deram forças para enfrentar quaisquer
Agradeço à comunidade de software aberto pelas incontáveis horas de esforço e
dedicação contribuídas ao ensino e à propagação do conhecimento, sem as quais este trabalho
simplesmente não seria possível. Àqueles que alimentam a comunidade com suas dúvidas,
experiências e contribuições nos clareiam a mente quando os livros não são capazes.
Agradeço aos coordenadores do curso de Sistemas de Informação, Tânia Pinheiro,
Francisco Aragão e Davi Romero, que pacientemente guiaram um estudante inexperiente e
um a um foram essenciais na minha jornada. Em nome de Shriram Mohan, Wladimir Tavares,
Ricardo Reis, Michael Wollowski, Camilo Almendra, Alex Lo, Críston Souza, Marcos
Dantas, Cary Laxer, Carla Moreira, Nadine Shillingford, Andreia Sampaio e Jeandro Bezerra
agradeço a todos os brilhantes professores que me apontaram caminhos e serviram de
profunda inspiração ao longo desses anos.
Agradeço àqueles que sempre me ouviram, acolheram e aconselharam, me
conduzindo pelos caminhos da vida: Eliseuda, Tarciso e Mirtes. Agradeço aos meus pais por
todos os sacrifícios feitos ao longo dos anos. Aos meus irmãos, tios e primos. A todos estes, o meu “muito obrigado” pelo apoio incondicional, alegria, exemplo e estímulo.
Em nome de Luana Dias, Rafael Vieira, Caleb Drake, Eduardo Bonet, Geovanny
Filho, Samuel Torres, Marcelo Arraes, Franklin Barroso, Thaís Melo, Romário Cabó, Jessica
Souza Alves, Regis Melo, Marcelo Barros, André Campos, Rodrigo Matihara, Samuel
Freitas, Luís Covatti, Allan Vitor, Daniel de Araújo, Tim Curley, Ricardo Sindeaux e Hector
Escobar agradeço a todos os meus amigos, essenciais em todas as etapas da minha vida.
Finalmente, à banca avaliadora, por prontamente aceitar fazer parte desse
momento tão especial. Aos companheiros de trabalho, funcionários e desconhecidos que
"Tudo parece impossível até que seja feito."
Dentre as formas de identificação organizacional comuns, destacam-se o uso de senhas, crachás e dispositivos de acesso especializados. Embora bastante difundidas, elas apresentam algumas ineficiências discutidas no trabalho. Paralelamente, sistemas de segurança modernos caminham para um novo cenário de autenticação conhecido como autenticação de dois fatores. Entretanto, mesmo soluções organizacionais recentes para autenticação de dois fatores frequentemente requerem hardware especializado. Este trabalho implementa uma solução para identificação organizacional com autenticação de dois fatores, sem hardware especializado, através de uma ferramenta quase ubíqua: smartphones. Smartphones já são considerados dispositivos multi-propósito devido aos seus recursos e portabilidade. Porém, a facilidade de manipulação desses dispositivos deixa organizações ainda temerosas, mantendo-os potencialmente subutilizadmantendo-os. Um segundo desafio para smartphones vem de sua moderada capacidade computacional se comparada aos requerimentos da criptografia assimétrica moderna. Esse desafio se torna ainda mais evidente com a demanda exigente de desempenho por parte dos usuários. O modelo implementado neste trabalho aborda esses e ainda outros desafios. Enquanto trabalhos relacionados utilizam criptografia simétrica, outros canais de comunicação, requerem hardware ou plataformas especiais, impõem fortes requisitos de implantação, ou simplesmente se orientam a outros cenários, a solução apresentada se destaca ao utilizar avanços computacionais recentes para operar uma infraestrutura de chave pública simples porém completa, orientada especialmente ao ambiente organizacional e à mobilidade. O sistema é implementado seguindo as recomendações do National Institute of Standards and Technology e do Internet Engineering Task Force, sem com isso abdicar da simplicidade de uso. Tendo como objetivo principal implementar a identificação organizacional móvel com dois fatores através de smartphones, a arquitetura é projetada para suportar dois modos de implantação, dois modos de operação e janelas de operação off-line, adaptando-se às necessidades organizacionais de forma transparente. A solução busca ainda ser extensível a outras aplicações, almejando promover a autenticação de dois fatores por diversos setores organizacionais. O processo metodológico foi composto de macrociclos e microciclos de desenvolvimento. Cada macrociclo inclui atividades de análise de requisitos, prototipagem, modelagem, validação, planejamento, implementação e feedback. Utilizando técnicas de processamento móvel paralelo, criptografia assimétrica, comunicação visual com códigos QR e a plataforma Android a arquitetura foi implementada em um protótipo funcional apresentado no trabalho. É feita uma comparação entre as implementações da arquitetura com RSA e com Curvas Elípticas, com a criptografia elíptica obtendo melhor desempenho mesmo com nível de segurança superior. Independentemente do algoritmo assimétrico utilizado, a arquitetura se mostra resistente a ataques como homem no meio e repetição, trazendo consigo estratégias para o tratamento do caso em que dispositivos são comprometidos.
Among the most common forms of organizational identification, the use of passwords, ids and specialized access devices stand out. Although quite widespread, they present some inefficiencies discussed is this paper. Simultaneously, modern security systems reach for a new authentication model known as two-factor authentication. Nevertheless, even recent organizational solutions for two-factor authentication often require specialized hardware. This work offers a solution for organizational identification with two-factor authentication without specialized hardware, through an almost ubiquitous tool: smartphones. Smartphones are already considered multi-purpose devices because of their resourcefulness and portability. However, the ease of manipulation of such devices concerns organizations, keeping them potentially underused. A second challenge for smartphones relates to their moderate computational power when compared to the requirements of modern asymmetric cryptography. This challenge becomes even more evident with the high demands of performance from users. The architecture implemented in this paper addresses these challenges and few others. While related works use symmetric cryptography, other communication channels, require special hardware platforms, enforce strong deployment requirements, or simply target other scenarios, the solution presented here stands out by using the latest technology to operate a simple and complete public key infrastructure, specifically designed for the organizational environment and for mobility. The system is implemented following the recommendations of the National Institute of Standards and Technology and the Internet Engineering Task Force, without thereby giving up the simplicity of use. Its main goal is to implement mobile organizational identification with two-factor authentication through smartphones. The architecture is designed to support two deployment modes, two modes of operation of off-line time windows, adapting to organizational needs in a transparent manner. The solution aims to be further extended by other applications, striving to bring two-factor authentication to many organizational sectors. The methodological process was composed of macrocycles and microcycles of development. Each macrocycle includes requirement analysis, prototyping, modeling, validation, planning, implementation and feedback activities. Using mobile parallel processing techniques, asymmetric encryption, visual communication with QR codes and the latest advancements of the Android platform, the architecture was successfully implemented into a working prototype. A comparison between the architecture implementations using RSA and Elliptic Curves is performed, with elliptic encryption getting better performance even with higher security levels. Regardless of the asymmetric algorithm used, the architecture is resistant to attacks such as man in the middle and replay, carrying strategies for dealing with the case in which devices are compromised.
Figura 1 - Comparação entre tamanho de chaves em esquemas criptográficos ... 23
Figura 2 - Recomendações do NIST para tamanhos de chave e algoritmos de acordo com a época ... 24
Figura 3 – Trecho introdutório sobre Cryptographic Message Syntax (CMS) publicada na RFC5652 pela IETF ... 25
Figura 4 - Visão geral sobre a especificação do formato de requisição de certificado PKCS#10 encontrado na RFC2986, uma republicação IETF do PKCS#10 v1.7 da RSAS ... 25
Figura 5 - Distribuições Android em dezembro de 2013 ... 27
Figura 6 - Exemplos das telas para uso do keystore nativo no Android antes da API 18 ... 29
Figura 7 - Exemplos de códigos QR e Data Matrix, ressaltando suas áreas de controle ... 31
Figura 8 – Exemplo de esboço primitivo criado durante o projeto ... 33
Figura 9 – Exemplo simplório de divisão e ordenação através da ferramenta Trello (FOG CREEK SOFTWARE INC, 2013) ... 35
Figura 10 - Exemplo de análise de código fonte durante o processo de controle de qualidade com a ferramenta SonarQube ... 36
Figura 11 - Diagrama de um macrociclo metodológico de desenvolvimento ... 37
Figura 12 - Ilustração do modelo básico de autenticação ... 40
Figura 13 - Ilustração das fontes alternativas de sincronia temporal ... 41
Figura 14 - Ausência de fontes temporais ... 43
Figura 15 – Exemplo de solicitação de certificado seguida de autenticação, sob perspectiva do aplicativo provedor ... 45
Figura 16 - Exemplo de comunicação na arquitetura multi-organizacional, sob perspectiva do aplicativo provedor ... 46
Figura 17 - Diagrama do modo de implantação uni-organizacional ... 48
Figura 18 - Diagrama do modo de implantação comercial ... 49
Figura 19 - Inicialização do keystore pelo Android ... 54
Figura 20 – Tela de cadastro do PIN ... 55
Figura 21 - Diagrama de sequência da instalação de identidade ... 57
Figura 22 - Fluxo de telas da instalação de identidade ... 58
Figura 23 - Acesso às opções de ... 58
Figura 26 - Exemplo do fluxo de telas de uso direto do módulo verificador pelo usuário ... 61
Figura 27 - Acesso às opções de gerenciamento ... 61
Figura 28 - Fluxo de acesso a tela de identidade para autenticação ... 63
Figura 29 - Consulta ao usuário sobre ... 64
Figura 30 - Alguns exemplos dos possíveis erros de verificação detectados pelo módulo verificador (lista não exaustiva) ... 65
Figura 31 - Exemplo de verificação bem sucedida com recebimento de informações adicionais ... 66
Figura 32 - Navegabilidade do módulo verificador ... 67
Figura 33 - Ilustração do recebimento de resultados pelo aplicativo externo consumidor ... 68
Figura 34 - Bloqueio preventivo do aplicativo provedor ... 71
AES Advanced Encryption Standard
API Application Programming Interface
CMS Cryptographic Message Syntax
CRL Certificate Revocation List
DSA Digital Signature Algorithm
ECC Elliptic Curve Cryptography
ECDSA Elliptic Curve Digital Signature Algorithm
GPS Global Positioning System
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ICP Infraestrutura de Chave Pública
IP Internet Protocol
IETF Internet Engineering Task Force
JSON JavaScript Object Notation
MITM Man In The Middle
NIST National Institute of Standards and Technology
OTP One Time Password
PBE Password-Based Encryption
PBKDF2 Password-Based Key Derivation Function 2
PIN Personal Identification Number
PKCS Public-Key Cryptography Standards
PRNG Pseudo-Random Number Generator
QA Quality Assurance
SSL/TLS Secure Sockets Layer / Transport Layer Security
TFA Two-Factor Authentication
1 INTRODUÇÃO ... 15
1.1 Objetivos ... 17
1.1.1 Objetivo Geral ... 17
1.1.2 Objetivos Específicos ... 18
1.2 Organização do texto ... 18
2 REVISÃO BIBLIOGRÁFICA ... 20
2.1 Trabalhos relacionados ... 20
2.2 Criptografia ... 21
2.2.1 Qualidades de segurança necessárias ... 21
2.2.2 Infraestrutura de chave pública ... 21
2.2.3 RSA ... 22
2.2.4 Criptografia de Curvas Elípticas ... 23
2.2.5 Recomendações de instituições ... 24
2.2.6 Ataques à segurança ... 25
2.2.7 HTTPS e SSL/TLS ... 26
2.3 Android ... 26
2.3.1 Keystore nativo ... 27
2.3.2 Provedor de criptografia ... 29
2.4 Códigos QR ... 30
3 PROCEDIMENTOS METODOLÓGICOS DE DESENVOLVIMENTO ... 32
3.1 Cadeia de dependência ... 32
3.1.1 F ase 1: Visualização do problema ... 33
3.1.2 F ase 2: Projeto e modelagem ... 34
3.1.3 F ase 3: Validação do modelo ... 34
3.1.4 F ase 4: Planejamento ... 34
3.2 Microciclo de desenvolvimento... 35
4 IDENTIFICAÇÃO ORGANIZACIONAL MÓVEL ... 38
4.2.2 Sincronia temporal ... 40
4.2.3 Autenticidade criptográfica ... 43
4.2.4 Entidades da arquitetura ... 44
4.2.5 Modo de implantação uni-organizacional ... 47
4.2.6 Modo de implantação comercial ou multi-organizacional ... 48
4.2.7 Modo de operação com revogação ... 49
4.2.8 Modo de operação com certificados curtos ... 50
4.3 Fluxos de comunicação e procedimentos ... 51
4.3.1 Confiança transitiva ... 52
4.3.2 Inicialização ... 53
4.3.3 Instalação de identidade no provedor ... 56
4.3.4 Posicionamento organizacional do verificador ... 59
4.3.5 Verificação de identidade... 61
4.3.6 Revogação ... 69
4.4 Implementação da arquitetura ... 69
4.4.1 Android PRNG ... 69
4.4.2 Android PBKDF 2 ... 70
4.4.3 Apache HTTP client 3 ... 70
4.4.4 Medidas de segurança extra ... 70
4.4.5 Armazenamento de segredos no Android ... 72
4.4.6 F erramentas utilizadas nos módulos móveis ... 72
4.4.7 F erramentas utilizadas nos módulos servidores ... 73
4.4.8 Interface do módulo organizacional ... 74
4.4.9 Interface do módulo central ... 74
5 APLICAÇÃO E ESTUDO DE DESEMPENHO ... 76
5.1 Desempenho: RSA e ECC ... 76
5.1.1 Tempo de instalação ... 77
5.1.2 Tempo de geração de código ... 77
5.1.3 Tempo de reconhecimento ... 77
5.1.4 Tamanho da CMS gerada ... 77
6 CONSIDERAÇÕES FINAIS ... 82
1 INTRODUÇÃO
Identificação organizacional, referindo-se ao método pelo qual um indivíduo alega
e comprova sua identidade vinculada a uma organização, é um passo de grande importância
em contextos organizacionais seguros. Em algumas instituições, é a base para o consumo de
uma diversidade de serviços. Quando se mostra necessária, tem sido implementada de
diversas formas diferentes. Dentre as mais difundidas, encontram-se o uso de senhas, crachás
e dispositivos de acesso especializados. Embora essas as formas de identificação tenham
tradicionalmente cumprido seu papel, elas apresentam algumas ineficiências discutidas a
seguir.
O uso isolado de senhas, por exemplo, embora muito adequado ao meio virtual, se
apresenta consideravelmente inapto ao cenário da identificação organizacional. Essa forma de
autenticação demandaria a presença de terminais de verificação espalhados por toda a
organização, constantemente conectados. Esses terminais, sejam eles computadores comuns
ou dispositivos especializados, apresentam custos de implantação e de manutenção para serem
mantidos em rede constante com bancos de dados. Adicionalmente, senhas utilizadas dessa
forma se mostram vulneráveis ao mau gerenciamento e a ataques como phishing e malware,
como apontam Hallsteinsen, Jorstad e Thanh (2007), Thanh et al. (2009), Alzomai e Jøsang
(2010), Choi et al. (2011), Tanvi, Sonal e Kumar (2011).
O uso de crachás, apesar de não exigir hardware custoso, pode não ser adequado
ao nível de segurança necessário a um contexto em particular, por depender exclusivamente
do reconhecimento humano e da incapacidade alheia de forjar um apetrecho similar. Além
disso, não é incomum que sua conferência deixe de ser precisa com o passar do tempo e com
o envelhecimento desses acessórios.
Dispositivos especializados de acesso, por outro lado, guardam as credenciais de
usuários em seu hardware, como em Busold et al. (2013). Geralmente são fabricados em
formato de cartão, sendo magnéticos ou não. O fluxo de uso desses dispositivos envolve sua
apresentação junto a sensores capazes de extrair essas informações e verificar sua
autenticidade. No entanto, o uso de hardware específico impõe maior custo de implantação e
Paralelamente, sistemas de segurança modernos caminham para um novo método
de identificação, buscando fortalecer os métodos tradicionais através do requerimento de um
duplo fator de autenticação. Esse novo modelo é conhecido como autenticação de dois fatores,
comumente abreviado para TFA. Nesse modelo, é necessário utilizar conjuntamente ‘algo que você sabe’ e ‘algo que você possui’, explica DeFigueiredo (2011).
Em âmbito organizacional, já existem iniciativas recentes que buscam substituir
as formas tradicionais de identificação por autenticação de dois fatores. A exemplo, em US
Deparment Of Defense (2006), governos emitem smartcards contendo chips eletrônicos que
guardam as credenciais do usuário e requerem um código de acesso para descriptografar essas
credenciais, durante cada tentativa de autenticação. Dessa forma, o cartão só tem valor se for
utilizado em conjunto com uma senha.
Em um outro exemplo frequente, a autenticação por dois fatores é implantada
através da utilização de tokens expiráveis gerados por dispositivos conhecidos por One Time
Password ou OTP, como explica Lee et al. (2010). Um fluxo comum, como em Cheng (2011)
e Choi et al. (2011), exige que um usuário confirme o conteúdo de um token exibido no seu
dispositivo no exato momento da autenticação que, em conjunto com a sua senha, irá
satisfazer a dois fatores.
Apesar dos benefícios sobre as formas tradicionais, essas formas de autenticação
apresentam dificuldades em sua implantação, como indicam Cheng (2011) e Abe, Itoh e
Takahashi (2007). Algumas das mais impactantes surgem da necessidade de hardware
específico, impondo custos, baixa escalabilidade e menor praticidade quando se tem mais de
um vínculo organizacional. Implementar uma forma de autenticação organizacional prática e
sem hardware especializado não é um problema facilmente solucionável. Consequentemente,
ainda é comum a utilização das formas mais simples de autenticação, sendo geralmente
desassociadas, abrindo caminho para o mau gerenciamento de credenciais, ataques e
desperdícios de tempo, recursos e esforços.
Aqui, será explorada uma oportunidade de solucionar o problema de autenticação
organizacional sem hardware especializado e ainda implementar autenticação de dois fatores
na identificação organizacional. Mobilidade e extensibilidade serão adicionadas ao conjunto
de qualidades desejadas. Para tanto, faz-se uso de uma ferramenta cada vez mais ubíqua:
Smartphones já são considerados dispositivos multi-propósito devido ao seu
relativo baixo custo aliado a sua portabilidade e recursos, como explicam Bhutta, Ghafoor e
Sultan (2012). O uso de smartphones tem crescido e se integrado a diversas atividades
pessoais e organizacionais. Simultaneamente, a qualidade das plataformas móveis de
desenvolvimento tem melhorado.
Dessa forma, smartphones poderiam ser utilizados como dispositivos
autenticadores no controle de acesso a serviços organizacionais. Já existem aplicações que
oferecem parcialmente essa capacidade, a exemplo de algumas aplicações bancárias e o
Google Authenticator (GOOGLE INC., 2013).
No entanto, ainda existem desafios relacionados ao uso de smartphones para
identificação organizacional. Devido à facilidade de manipulação desses dispositivos,
organizações se encontram temerosas quanto à segurança de credenciais confiadas a
smartphones, impedindo que eles sejam usados como provedores de identidade e
mantendo-os como um acessório de segurança potencialmente subutilizado.
Um segundo desafio para os smartphones vem de sua moderada capacidade
computacional se comparada aos requerimentos da criptografia assimétrica moderna. Esse
desafio se torna ainda mais evidente com a demanda de desempenho cada vez mais exigente
por parte dos usuários.
Por fim, há ainda o desafio do equilíbrio entre segurança e simplicidade. Uma
solução para identificação organizacional precisa ser capaz de operar de maneira ágil e
simples buscando alcançar uma integração bem sucedida nos processos organizacionais e
aceitação dos usuários. Entretanto, frequentemente procedimentos de segurança contribuem
para o aumento da complexidade de processos internos e diminuição de sua agilidade, o que,
segundo Gutmann (2013) acaba resultando na má utilização das ferramentas ou sua total
inutilização. Esses e outros desafios são explorados neste trabalho, cujo objetivos são
definidos a seguir.
1.1 Objetivos
1.1.1 Objetivo Geral
Desenvolver uma solução extensível de software para identificação organizacional
1.1.2 Objetivos Específicos
a) Projetar uma arquitetura de sistema para identificação organizacional
sustentada por apenas smartphones e servidores;
b) Projetar uma infraestrutura de segurança baseada em criptografia assimétrica
sob as recomendações NIST e IETF para a arquitetura;
c) Projetar um modelo de autenticação com dois fatores resistente a ataques
Man-In-The-Middle (MITM) e repetição capaz de suportar janelas de operação sem
conexão com internet;
d) Projetar um modelo componentizado de software capaz de suportar extensão de
funcionalidade e reuso do módulo de verificação;
e) Implementar um módulo de armazenamento de segredos integrado às
estratégias de segurança da plataforma Android;
f) Implementar um protótipo funcional da arquitetura e suas entidades.
1.2 Organização do texto
O documento está divido em seis seções. Na primeira seção apresentou-se uma
introdução ao tema, fazendo uma contextualização e apresentando a problemática
vislumbrada, assim como os objetivos geral e específicos.
Na segunda seção é realizada uma revisão sobre os principais componentes do
projeto, incluindo alguns trabalhos relacionados, conceitos de criptografia utilizados, detalhes
sobre a plataforma de desenvolvimento móvel e elucidações sobre códigos bidimensionais
que serão uma característica notável do sistema.
A terceira seção apresenta os procedimentos metodológicos utilizados no
desenvolvimento do trabalho, detalhando a metodologia iterativa empregada e os passos que
foram necessários para a obtenção da solução aqui apresentada.
A quarta seção traz o detalhamento dos principais elementos e contribuições do
projeto. Esta seção se divide em quatro partes, sendo: (a) uma apresentação dos requisitos
considerados; (b) uma descrição da arquitetura e sua infraestrutura de segurança; (c) uma
descrição dos fluxos de comunicação e procedimentos e (d) um detalhamento da
A quinta seção apresenta avaliações de desempenho e discute resultados obtidos
com a implementação da arquitetura utilizando os sistemas criptográficos RSA e de Curvas
Elípticas. Há ainda uma comparação com trabalhos relacionados
2 REVISÃO BIBLIOGRÁFICA
As subseções a seguir oferecem uma revisão de quatro componentes fundamentais
do projeto: trabalhos relacionados, criptografia, Android e códigos QR. Na primeira seção, há
um breve resgate histórico dos trabalhos mais influentes a esta contribuição. Na subseção de
criptografia, são feitas introduções aos conceitos criptográficos utilizados, seguidas de
contextualizações do papel de cada conceito na solução implementada. Na segunda subseção,
são detalhados alguns elementos da plataforma de desenvolvimento Android relevantes ao
trabalho. A subseção de códigos QR faz uma breve caracterização desse tipo de código e de
suas qualidades.
2.1 Trabalhos relacionados
Em 2005, McCune et al propõe um modelo de identificação demonstrativa e
negociação genérica de chaves dentre dispositivos através de um duplo canal de comunicação:
wireless e visual. O trabalho de McCune et al permite a autenticação entre partes que não
compartilham um contexto confiável prévio, em uma abordagem quase oposta à deste
trabalho. Embora o trabalho de McCune et al não tenha orientação organizacional almejada
aqui, seu modelo foi inspirador em diversos aspectos, principalmente em sua utilização do
canal visual como meio confiável de comunicação.
Ainda em 2005, Hassinen e Hypponen propõem um modelo de autenticação
móvel baseado em ICPs governamentais e no uso de SMS. Embora o modelo não tenha
desfrutado das capacidades dos smartphones modernos devido à época em que foi proposto,
os princípios de ICP integrados no seu modelo influenciaram a maneira com que esse trabalho
confia a ICP características de autenticidade, integridade e não repúdio.
Em 2011, Tanvi, Sonarl e Kumar apresentam um modelo de autenticação OTP
baseado em senhas geradas por smartphones. Embora o modelo aqui apresentado siga a
filosofia ICP, o modelo proposto por eles influenciou este trabalho à medida que apresenta
assiduamente smartphones como substituição para tokens de hardware.
Em 2012, Bhutta e Ghafoor estendem o protocolo PACS e demonstram a
capacidade que smartphones têm de serem meios confiáveis para determinar controle de
Em 2013, Busold et al constrói um modelo chaves inteligentes para automóveis
baseando-se em smartphones, NFC e ICP. Desconsiderando suas necessidades de hardware
especializado, Busold et al tem uma abordagem muito mais próxima à deste trabalho do que
os outros trabalhos mencionados anteriormente. O modelo construído por ele implementa um
protocolo de delegação de acesso, utilizando ICP em conjunto com seu próprio protocolo. O
modelo de Busold et al teve influência considerável nesse trabalho ao despertar a
sensibilidade para as vantagens de ICP dentro de uma hierarquia organizacional.
2.2 Criptografia
Neste trabalho, devido à utilização de hardware comum, criptografia é a principal
barreira entre um atacante e as informações privadas. Segundo Laureano (2005), criptografia
representa um conjunto de técnicas para manter uma informação segura, sendo a maneira
mais segura de se enviar informações através de um canal de comunicação.
2.2.1 Qualidades de segurança necessárias
Dentre as qualidades de segurança promovidas pela criptografia, as consideradas
essenciais para o funcionamento da solução aqui desenvolvida são:
a) confidencialidade - propriedade que limita o acesso à informação tão somente
às entidades autorizadas pelo proprietário da informação.
b) integridade - propriedade que garante que a informação manipulada mantenha
todas as características originais estabelecidas pelo proprietário da informação.
c) autenticidade - propriedade que garante que a informação é proveniente da
fonte anunciada e que não foi alvo de mutações ao longo de um processo.
d) não repúdio - propriedade que garante a impossibilidade de negar a autoria em
relação a uma transação anteriormente feita
Essas qualidades são inseridas na arquitetura proposta através de procedimentos e
protocolos dependentes de uma infraestrutura de segurança baseada em chave pública.
2.2.2 Infraestrutura de chave pública
Laureano (2005) ressalta que a infraestrutura de chave pública ou ICP consegue
de ser fraudada e que se apresenta de forma transparente para o usuário. Estes dois pontos,
transparência aliada à forte base técnica de seus mecanismos, denotam o aspecto forte desta
tecnologia.
Infraestrutura de chave pública é uma iniciativa para utilização de criptografia que
tem como base a emissão de chaves por uma organização tida como confiável pelas partes
envolvidas. A natureza característica dessa infraestrutura vem do pareamento crítico, mútuo e
único entre uma chave pública e sua chave privada. Diversos algoritmos criptográficos podem
ser utilizados para implementar essa infraestrutura, sendo conhecidos como algoritmos de
criptografia assimétrica.
Essas emissões são realizadas através de certificados digitais, documentos
eletrônicos que ligam uma entidade a sua chave publicamente e são assinados pela
organização confiável. Ainda segundo Laureano (2005), uma assinatura digital é o processo
pelo qual uma entidade gera uma assinatura de uma mensagem criptografada com sua chave
privada, que apenas pode ser descriptografada através do uso de sua chave pública, atestada
pelo seu certificado digital. Dessa forma, se o reconhecimento da assinatura com a chave
pública for bem sucedido, fica comprovado que o assinante tem domínio da chave privada
correspondente e verifica-se sua identidade junto à autenticidade da assinatura.
Em ICP, existe ainda um procedimento chamado revogação. Ele se refere ao ato
de retirar ou anular a validade de um certificado digital, indicando publicamente que esse
certificado não é mais confiável. Dentre as diversas razões que podem levar uma autoridade a
revogar um certificado, destaca-se a situação em que a privacidade da chave privada de uma
entidade foi comprometida ou sabidamente posta em risco.
A arquitetura proposta neste trabalho é fortemente baseada em ICP. A cadeia de
confiança restrita, a habilidade de gerar e reconhecer assinaturas digitais, o controle do ciclo
de vida de certificados e a capacidade de revogação dos mesmos são elementos essenciais
para a solução implementada aqui. O RSA foi o primeiro algoritmo a implementar assinatura
digital, sendo ainda hoje um dos mais utilizados.
2.2.3 RSA
RSA é um dos primeiros e mais utilizados sistemas criptográficos de chave
pública, desenvolvido por Ronald Rivest, Adi Shamir e Leonard Adleman em 1977. O
computacional de se fatorar o produto de dois grandes números primos. Embora pequenos
avanços tenham sido feitos no ataque ao problema, como apontam Magalhães e Queiroz
(2011), grandes tamanhos de chave para o algoritmo são estipulados de forma a garantir a
dificuldade computacional de um ataque. O RSA é um dos sistemas criptográficos avaliados
como implementação para a infraestrutura de segurança deste trabalho, o outro envolve
criptografia de curvas elípticas.
2.2.4 Criptografia de Curvas Elípticas
Criptografia de curvas elípticas, ou ECC, é um sistema criptográfico de chave
pública relativamente novo desenvolvido independentemente por Victor Miller e Neal Koblitz
em 1985. Sua adoção comercial, no entanto, não se popularizou antes de 2004. ECC tem sua
segurança baseada na dificuldade computacional de se resolver o problema do logaritmo
discreto em curvas elípticas.
ECC tem ganhado recente popularidade sobre o RSA devido a sua capacidade de
apresentar segurança equiparável utilizando chaves significativamente menores e velocidade
de processamento na ordem de 10 vezes mais rápido que o RSA (MAGALHÃES; QUEIROZ,
2011). A adoção de ECC nas suítes criptográficas e infraestruturas de segurança em todo o
mundo tem crescido a medida que órgãos regulamentadores padronizam especificações para
sua implementação e resultados acadêmicos atestam sua segurança teórica no atual estado da
arte matemática (BARBOSA, 2003). A figura 1 traz uma comparação entre tamanhos de
chave de criptografia simétrica, elíptica e RSA.
Figura 1 - Comparação entre tamanho de chaves em esquemas criptográficos
Fonte: Magalhães e Queiroz (2011)
Essas qualidades de segurança, tamanho e desempenho se mostram
dispositivos tem poder computacional e largura de banda mais limitados. Isso faz de ECC o
segundo sistema criptográfico avaliado como implementação para a infraestrutura de
segurança deste trabalho.
2.2.5 Recomendações de instituições
Por todo o mundo, existem órgãos regulamentadores e empresas de segurança
influentes que especificam padrões e protocolos a serem utilizados por sistemas
criptográficos. Algumas dessas organizações incluem o National Institute of Standards and
Technology (NIST), a Internet Engineering Task Force (IETF) e a RSA Security (RSAS para
diferenciar do algoritmo).
A seguir, algumas das recomendações dessas instituições que serão referenciadas
ao longo do texto, incluindo tamanhos de chave, algoritmos criptográficos, encapsulamento
de mensagens criptográficas e formatos de requisição de certificado:
Figura 2 - Recomendações do NIST para tamanhos de chave e algoritmos de acordo com a época
Figura 3 – Trecho introdutório sobre Cryptographic Message Syntax (CMS) publicada na RFC5652 pela IETF
Fonte: (IETF, 2013)
Figura 4 - Visão geral sobre a especificação do formato de requisição de certificado PKCS#10 encontrado na RFC2986, uma republicação IETF do PKCS#10 v1.7 da RSAS
Fonte: (IETF, 2013)
2.2.6 Ataques à segurança
Existe uma vasta e crescente diversidade de ataques à segurança de sistemas
computacionais. Enquanto uma significativa porção desses ataques pode ser mitigada
simplesmente pelo uso correto dos procedimentos de criptografia, outros ataques precisam ser
contornados por medidas externas dependentes de cada contexto e análise de riscos. Dois
tipos de ataques receberam atenção especial durante o desenvolvimento da arquitetura aqui
apresentada: homem no meio, ou MITM, e repetição.
Um ataque do tipo homem no meio, como traduzido por Laureano (2005), é uma
forma de ataque em que dados trocados entre duas partes são interceptados e potencialmente
manipulados por um atacante sem alertar essas partes. Esse tipo de ataque depende da
capacidade do atacante de assumir satisfatoriamente a identidade de pelo menos uma das
partes. Já um ataque de repetição se caracteriza quando uma transmissão válida de informação
entre duas partes é interceptada e retransmitida por um atacante para fins mal-intencionados.
Esses ataques são levados em especial consideração durante o desenvolvimento
códigos bidimensionais. A principal ferramenta para proteção da comunicação via rede é o
protocolo Hypertext Transfer Protocol Secure (HTTPS).
2.2.7 HTTPS e SSL/TLS
O protocolo Transport Layer Security (TLS), especificado pela IETF baseando-se
no seu precedente Secure Sockets Layer (SSL), fornece segurança criptográfica a
comunicações realizadas através da Internet. O protocolo permite que aplicações
cliente/servidor se comuniquem de uma maneira projetada para evitar a espionagem,
adulteração ou falsificação de mensagens (IETF, 2013). O protocolo SSL/TLS é um
componente essencial do protocolo de comunicação HTTPS.
Dado que uma parte ‘S’ ofereça capacidades HTTPS para comunicação com a parte ‘C’, apresente um certificado digital reconhecido por ‘C’ e tenha a posse das chaves privadas correspondentes, então ‘C’ tem a oportunidade de utilizar HTTPS para autenticar ‘S’ e trocar informações criptografadas, sem estar vulnerável aos ataques MITM e repetição descritos na seção anterior. Adicionalmente, caso ‘S’ necessite autenticar a parte ‘C’ através do mesmo protocolo, ‘C’ precisa ter posse de um certificado digital reconhecido por ‘S’ e
posse das chaves privadas correspondentes (IETF, 2013).
O HTTPS com SSL/TLS é o único protocolo de comunicação via rede aceito no
sistema aqui implementado. Para assegurar que esse protocolo seja sempre utilizado, todas as
entidades tiveram suas capacidades de se comunicar por HTTP comum desabilitadas.
2.3 Android
Smartphones atuais dispõem de diferentes plataformas de desenvolvimento. Elas
são impulsionadas por múltiplas empresas dos ramos de telecomunicações, software,
entretenimento e eletrônicos. A partir do final de 2010, a plataforma de desenvolvimento
móvel mais popular passou a ser o Android, como atesta Canalys (2011). O Android é um
sistema operacional e plataforma de desenvolvimento de código aberto, atualmente mantido
pela Google (GOOGLE INC., 2013).
Essa plataforma apresenta características importantes ao contexto desse trabalho
que não são encontradas, simultaneamente, nas outras plataformas: sua dominante
suporte a uma grande variedade de dispositivos, sua API interna para comunicação entre
aplicações e seu suporte integrado ao NFC.
Em 2014, mais de 55% dos dispositivos com Android operam sobre a versão Jelly
Bean ou superior, internamente conhecida como as APIs 16 a 18 (GOOGLE INC, 2013). A
figura 5 traz um detalhamento das distribuições Android em dezembro de 2013.
Figura 5 - Distribuições Android em dezembro de 2013
Fonte: (GOOGLE INC, 2013)
Na versão Jelly Bean, foi introduzido um conjunto significativo de melhorias de
segurança na plataforma, incluindo encriptação de aplicativos e o suporte à proteção de
chaves criptográficas através de hardware. Um elemento seguro embutido nos aparelhos mais
modernos confere essa capacidade. No entanto, a utilização de segurança protegida por
hardware depende da presença desse elemento físico no aparelho, sendo transparentemente
substituída pela tradicional segurança através de software caso o aparelho não seja fabricado
com um elemento seguro internamente. A segurança através de software se baseia no uso do
keystore do sistema.
2.3.1 Keystore nativo
Assim como demonstra Elenkov (2012), o keystore nativo do sistema Android é
um componente para armazenamento de chaves e certificados, sendo criptografado com o
Advanced Encryption Standard, ou AES. A senha que protege essa criptografia é derivada do
método de desbloqueio do smartphone utilizando Password-Based Key Derivation Function 2
(PBKDF2) com mais de oito mil iterações. Para utilizar o keystore, o usuário precisa cadastrar
inicializado, protegido e acessado exclusivamente sob permissão do usuário. Uma vez
inicializado, o keystore só pode ser utilizado por aplicações após o usuário ter desbloqueado o
smartphone.
Tentativas de remover forçadamente o PIN ou padrão de desbloqueio do
dispositivo tornarão o sistema incapaz de derivar a senha do keystore, inevitavelmente
inutilizando os dados armazenados anteriormente. Adicionalmente, mesmo após o keystore ter
sido desbloqueado pelo usuário, as chaves contidas nele só podem ser acessadas pela mesma
aplicação que as criou, nem mesmo processos do tipo root podem ler seus valores em texto
plano. Entretanto, embora também não possam acessar os valores em texto plano, processos
do tipo system podem apagar os textos cifrados do keystore para trazê-lo de volta ao estado de
fábrica (ELENKOV, 2012). Em smartphones com Jelly Bean ou superior, que contenham um
elemento seguro de hardware, o keystore do sistema fará uso de proteção de hardware
transparentemente, operando de maneira ainda mais segura.
Na prática, isso significa que o keystore nativo do Android é surpreendentemente
seguro para uma solução de software: mesmo que um atacante tivesse acesso a um dispositivo
como root e conseguisse ter acesso ao texto cifrado, ele ainda precisaria da senha do usuário
para derivar a chave AES utilizada na encriptação do keystore. Experimentar senhas
diferentes na tentativa de derivar a chave correta exigiria pelo menos 8.192 iterações de
PKBF2 por cada chave tentada, o que é normalmente proibitivamente caro. Além disso, a
função de derivação utiliza como “sal” um número aleatório de 128 bits, de modo que tabelas
de hash previamente-calculadas não podem ser utilizadas.
Apesar de suas qualidades, até a versão 4.3 do Android (API 18), o keystore do
sistema só estava diretamente acessível às aplicações nativas da plataforma, como as de VPN
eWiFi. Antes dessa versão, não havia uma API pública de interação direta com keystore, mas
apenas através de intents. Aplicações eram forçadas a saírem de seu contexto, chamar uma
tela do sistema, esperar por interação do usuário e só então receber o resultado dessa interação
para dar continuidade às suas tarefas. Esse procedimento, além de ser significativamente lento
e intrusivo, abria oportunidade para erros de usuário. A figura 6 traz exemplos dessas telas de
Figura 6 - Exemplos das telas para uso do keystore nativo no Android antes da API 18
Fonte: (ELENKOV, 2011)
2.3.2 Provedor de criptografia
O sistema operacional Android executa sobre uma versão modificada da máquina
virtual Java chamada Dalvik. O Java Android mantém alta familiaridade com a plataforma
Java tradicional, hoje mantida pela Oracle. Não surpreendentemente, a versão Android
também delega todas as operações criptográficas a provedores de criptografia através da Java
Cryptography Extension.
Porém, diferentemente da versão Oracle, a versão Android já inclui uma
implementação de criptografia da renomada organização BouncyCastle (LEGION OF THE
BOUNCY CASTLE INC, 2013). A implementação criptográfica BouncyCastle é a mais
utilizada no mundo Java, tanto por ser aberta quanto por ser australiana, não estando,
portanto, submetida às restrições legais americanas de exportação de criptografia.
No entanto, a versão incluída no Android não corresponde integralmente à
implementação da original biblioteca, sendo na verdade uma versão diminuída que contém
claras à comunidade, a maioria dos desenvolvedores acredita que esteja relacionada ao
tamanho da biblioteca e à intenção de integrar nativamente apenas o essencial.
Essa integração nativa se torna um problema à medida que a biblioteca original
recebe atualizações mais frequentemente do que o Android é capaz de acompanhar.
Desenvolvedores que desejam utilizar versões mais completas da implementação, ou
simplesmente mais atuais, não podem utilizar a versão original devido a conflitos com os
pacotes já incluídos nativamente. O resultado é que, por algum tempo, desenvolvedores foram
forçados a copiar o código da biblioteca em suas aplicações, o que aumentava o risco de erros
e o esforço de implementação. Se possível, a alternativa seria utilizar a versão limitada e
desatualizada da mesma biblioteca.
Para resolver esse problema, a comunidade aberta criou o projeto SpongyCastle
(TYLEY, 2013), que nada mais é do que um empacotamento da implementação original
BouncyCastle sob um nome identificador diferente, possibilitando que a biblioteca original
seja usada sem conflitar com os pacotes nativos limitados. No protótipo funcional da
arquitetura deste trabalho, o empacotamento SpongyCastle foi utilizado como provedor de
criptográfico no Android.
2.4 Códigos QR
Ao contrário de códigos unidimensionais, como códigos de barra, onde todas as
informações podem ser encontradas em um único corte através do código, códigos
bidimensionais utilizam uma segunda dimensão, contendo muitas "linhas" de dados. Eles são
comumente utilizados para comunicação visual extremamente rápida no mundo móvel,
incluindo, por exemplo, campanhas publicitárias, distribuição de conteúdo e utilizações
técnicas.
Entre os códigos bidimensionais mais populares estão o QR e o Data Matrix.
Ambos contêm áreas de dados e áreas que ajudam a detectar o código. Adicionalmente,
ambos utilizam o sistema de Reed Solomon para recuperação de partes danificadas do código.
Figura 7 - Exemplos de códigos QR e Data Matrix, ressaltando suas áreas de controle
Fonte: (OREILLY, 2011)
Mesmo sendo mais novo que o Data Matrix, o QR ganhou maior popularidade no
contexto móvel devido a sua leitura rápida, estética de personalização e capacidade nativa de
suportar caracteres japoneses. O código QR também apresenta algumas vantagens técnicas
sobre os códigos Data Matrix que são úteis no contexto deste trabalho, sendo ela maior
3 PROCEDIMENTOS METODOLÓGICOS DE DESENVOLVIMENTO
A metodologia de desenvolvimento do trabalho foi derivada pelo autor a partir do
modelo tradicional em cascata em conjunto com metodologias ágeis iterativas. Ela emprega
uma abordagem algorítmica para a perseguição dos objetivos listados. Os resultados obtidos
durante os ciclos de desenvolvimento serão apresentados na próxima seção do trabalho,
reservando esta seção para uma descrição da metodologia.
A metodologia é composta de um macrociclo de desenvolvimento que se divide
em duas etapas bastante distintas: a cadeia de dependência e o microciclo de
desenvolvimento. Essas etapas se alternam constantemente. A figura 11 traz um diagrama de
um macrociclo, detalhado no texto a seguir.
3.1 Cadeia de dependência
A cadeia de dependência é a etapa inicial do macrociclo. Seu objetivo principal é
criar um modelo minimamente sólido de parte do sistema antes do início da próxima etapa.
Sua estrutura busca detectar os problemas conceituais mais básicos. As características
marcantes dessa etapa são:
a) é composta por um conjunto ordenado de atividades;
b) ao término de uma atividade, a próxima atividade na sequência deve ser
executada, não se permitindo saltos;
c) se, durante a execução de uma atividade, for necessário fazer alterações
relacionadas a uma atividade anterior, o fluxo deve ser retornado a essa
atividade anterior, com atenção ao item ‘c’. O sequenciamento da cadeia deve
ser mantido;
d) ao fim da cadeia, inicia-se a etapa de ciclo de desenvolvimento.
Visivelmente, a etapa de cadeia de dependência se assemelha a uma cascata.
Porém, ela é indefinidamente retornável. Mudanças percebidas ao longo da cadeia causam um
retorno a uma atividade anterior, seguido de uma conferência de todo o trecho retornado,
atividades foi estipulada para que mudanças mais fundamentais ressaltassem a necessidade de
revisão das atividades seguintes. As atividades desenvolvidas na etapa são agrupadas em fases
apenas por mérito de categorização. As fases não têm influência no fluxo da etapa. Ao todo,
são 10 atividades dividas em 4 fases.
3.1.1 Fase 1: Visualização do problema
Contém 3 atividades. Em ordem:
1. análise dos objetivos:
verifica-se se algo precisa ser acrescentado à lista de objetivos. Em seguida, seleciona-se um subgrupo de objetivos a ser trabalhado nesta
iteração.
2. esboço parcial da solução (figura 8):
faz-se ou incrementa-se um esboço parcial da solução, em sua forma ideal, detalhando as aspirações dos objetivos selecionados.
Figura 8 – Exemplo de esboço primitivo criado durante o projeto
Fonte: elaborado pelo autor
3. especificação dos requisitos:
baseando-se no esboço e também nos objetivos, incrementa-se os requisitos formais que devem ser atendidos pela solução após a
3.1.2 Fase 2: Projeto e modelagem
Contém 4 atividades. Ordenadas:
1. identificação de entidades e definição da arquitetura:
identifica-se as entidades envolvidas nos requisitos e suas responsabilidades principais, incrementando a arquitetura se
necessário.
2. definição da sequência de comunicação e autenticação:
sequencia-se os passos principais do fluxo de comunicação. Procura-se mapear de onde a informação se origina e a quem se destina.
3. planejamento de armazenamento:
de acordo com os fluxos de comunicação, determina-se aonde, quando e como informações devem ser armazenadas. Ajuda a garantir que os
fluxos estejam coerentes.
4. verificação da segurança:
assegura-se que seja possível proteger as comunicações e os armazenamentos anteriores.
3.1.3 Fase 3: Validação do modelo
Contém apenas uma atividade de verificação: assegurar que os objetivos sejam
alcançados pela arquitetura, assegurar que as comunicações e armazenamentos estejam
protegidos e assegurar que o modelo de autenticação construído é utilizável.
3.1.4 Fase 4: Planejamento
Contém 2 atividades. Em ordem:
1. divisão em funcionalidades:
quebra-se o modelo validado em múltiplas e pequenas funcionalidades, preparando-o para o planejamento de implementação.
ordena-se as funcionalidades e faz-se o agendamento das mesmas de acordo com estimativas e tempo de projeto.
Figura 9 – Exemplo simplório de divisão e ordenação através da ferramenta Trello (FOG CREEK SOFTWARE INC, 2013)
Fonte: elaborado pelo autor
3.2 Microciclo de desenvolvimento
Essa etapa é iniciada sempre que a etapa anterior termina. O microciclo de
desenvolvimento tem como objetivo implementar o que foi modelado na cadeia, uma
funcionalidade por vez. Sua estrutura é simples e eficaz. Ela se assemelha ao ciclo de
desenvolvimento iterativo e incremental. Aqui, funcionalidades planejadas são escolhidas
para serem implementadas. O processe segue o fluxo:
1. seleção de funcionalidade;
2. componentização da funcionalidade;
3. implementação, testes e controle de qualidade (figura 10);
4. feedback e redirecionamento.
Não raro, essa etapa requer alguma mudança relacionada à etapa anterior. Nesse
redirecionamento: no pior caso, algo precisa ser mudado e o fluxo será retornado à cadeia de
dependência; no caso médio, tudo correu bem e outra funcionalidade pode ser implementada;
no melhor caso, todas as funcionalidades foram implementadas e o macrociclo pode reiniciar,
selecionando um outro grupo de objetivos. Mesmo no caso de redirecionamento à cadeia de
dependência, a mesma eventualmente retornará ao microciclo de desenvolvimento.
Figura 10 - Exemplo de análise de código fonte durante o processo de controle de qualidade com a ferramenta SonarQube
Figura 11 - Diagrama de um macrociclo metodológico de desenvolvimento
4 IDENTIFICAÇÃO ORGANIZACIONAL MÓVEL
A solução para identificação organizacional móvel será apresentada nas seções a
seguir. Suas características são detalhadas ao longo de cinco subseções: requisitos; arquitetura
e infraestrutura de segurança; fluxos de comunicação e procedimentos e implementação da
arquitetura.
4.1 Requisitos
Os requisitos identificados são derivados dos objetivos específicos na tentativa de
se obter um equilíbrio entre usabilidade, desempenho e segurança. Consequentemente, os
requisitos principais representam a necessidade de se realizar identificação organizacional
através de smartphones, abstendo-se de hardware especializado, e de integrar autenticação de
dois fatores ao processo de identificação.
Para tanto, acrescentam-se requisitos não funcionais de segurança, exigindo que o
processo de autenticação apresente qualidades de autenticidade, não repúdio e integridade.
Adicionalmente, a confidencialidade dos dados privados das entidades precisa ser assegurada
ao armazenar e transferir informações. Ataques do tipo MITM e repetição devem ser
mitigados pela solução.
Buscando maior aceitação dentro de processos organizacionais e sempre tentando
reduzir a quantidade de pré-requisitos impostos pelo sistema, dois requisitos são ainda
considerados no trabalho: a não exigência de cadastros adicionais de usuário e a capacidade
de operação durante janelas de tempo off-line.
Por fim, há o requisito de extensibilidade, que demanda que a solução seja
reusável por outras aplicações de maneira compatível com o padrão de intercomunicação da
plataforma Android.
4.2 Arquitetura e infraestrutura de segurança
A geral arquitetura da solução foi em grande parte construída pela integração
entre o modelo de autenticação desejado e a infraestrutura de segurança baseada em
processo de sincronia temporal desenvolvido, a autenticidade criptográfica dos códigos
gerados, as entidades da arquitetura, os seus modos de implantação e os modos de operação.
4.2.1 Modelo de autenticação
Uma das características marcantes da solução desenvolvida é sua mobilidade em
ambos os lados identificador e identificado. Essas qualidades de mobilidade se somam à
abstenção de hardware especializado e rapidamente convergem para um modelo de
autenticação baseado na interação entre dois smartphones.
Um modelo de autenticação baseado em smartphones dispõe de poder
computacional considerável assim como da oportunidade de implementar a autenticação de
dois fatores envolvendo sua posse. Nesse modelo, o smartphone em posse do identificado
assume o papel de provedor de identidade e o outro smartphone, em posse do identificador,
assume o papel de verificador. Essas duas partes passarão a ser comumente referenciadas no
trabalho como respectivamente provedor e verificador.
O canal de comunicação escolhido para o modelo foi o canal visual. Frente aos
canais de comunicação via rede, como Wi-Fi, Bluetooth e redes de telefonia, o canal visual se
destaca por apresentar as seguintes características, adaptadas de McCune et al (2005):
a) rapidez de reconhecimento (através de códigos QR) e consequente agilidade
da interação;
b) eliminação de problemas de conectividade e de identidade em rede através do
apontamento ativo e direto das câmeras dos dispositivos;
c) dificuldade de ataque ao canal visual devido aos recursos e esforços
necessários serem consideravelmente maiores que em ataques à comunicação
via rede;
d) não requer pareamento.
Assim, o modelo de autenticação da solução é construído pela interação visual
entre os dispositivos provedor e verificador. Particularmente, o princípio básico do modelo é
que o dispositivo provedor deve ser capaz de emitir um código visual de tamanha unicidade
que o dispositivo verificador será capaz de extrair sua identidade a partir da interpretação do
Figura 12 - Ilustração do modelo básico de autenticação
Fonte: elaborado pelo autor
O uso do canal visual no modelo de autenticação já representa um grande
obstáculo a ataques do tipo MITM, como aponta McCune et al (2005). Adicionalmente, dado
que a informação transmitida pelo código não é confidencial, mas sim única, um ataque do
tipo MITM não oferece grandes benefícios a um atacante. Por outro lado, um ataque de
repetição poderia ser extremamente danoso ao modelo em sua forma primitiva. Supondo que
um atacante fosse capaz de interceptar um código válido, ele poderia repeti-lo e assumir a
identidade da vítima indiscriminadamente.
Nesse cenário, a arquitetura é incrementada de forma a mitigar ataques de
repetição. Para isso, dois conceitos são introduzidos no modelo de autenticação: sincronia
temporal e sessão de autenticação. O princípio de sincronia temporal busca diminuir
drasticamente a janela de oportunidade de atacantes ao introduzir uma consciência temporal
no código gerado, limitando sua validade a apenas alguns segundos. O princípio de sessão de
autenticação estipula que uma identidade só pode ser recebida uma vez por sessão, rejeitando
repetições posteriores. Esses dois conceitos, aliados a resiliência do canal visual, reduzem a
viabilidade de ataques de repetição a níveis proibitivos.
4.2.2 Sincronia temporal
Para que o código assinado possa conter informações temporais, é necessário que
haja uma mínima sincronia de relógios entre os dispositivos verificador e provedor. Do
contrário, os códigos seriam potencialmente rejeitados como expirados ou adiantados.
Embora a sincronia de relógios seja comumente realizada via Internet, seu uso como única
fonte de sincronia aumentaria as necessidades de conectividade dos dispositivos, limitando a
Adicionalmente, visando dificultar a ação de um atacante que obtenha posse
temporária de um dispositivo, o tempo utilizado na aplicação deve ser independente do tempo
manipulável dos aparelhos. Embora smartphones Android disponham de um relógio interno
independente do relógio de usuário ele não é suficiente para resolver o problema. Utilizado
pelo controle interno de threads do sistema, esse relógio conta a quantidade de nanosegundos
desde o momento que o aparelho foi iniciado. Enquanto esse relógio é útil para o cálculo de
tempo relativo e por não ser manipulável, ele não representa uma informação temporal que
possa ser comparada a outro dispositivo. Ele será referenciado a partir de então como relógio
elapsed real time (ERT).
Com essas necessidades explicitadas, um algoritmo de sincronia temporal foi
desenvolvido para os módulos móveis da solução. Esse algoritmo foi inspirado em uma
versão simplificada do Network Time Protocol (ECE/CIS, 2012), ou NTP, e seu
funcionamento é descrito a seguir.
O primeiro aspecto relevante do algoritmo são suas fontes de tempo alternativas.
Oportunamente, smartphones modernos são capazes de obter tempo a partir de fontes que não
dependem de conexão com a internet: redes telefônicas e GPS. O algoritmo desenvolvido
utiliza essas fontes transparentemente quando não há conexão disponível, possibilitando a
sincronia de tempo mesmo estando “off-line”. O algoritmo escolhe a fonte mais adequada
dentre as opções dependendo do contexto atual do dispositivo.
Figura 13 - Ilustração das fontes alternativas de sincronia temporal
O princípio básico do algoritmo é: tendo sido obtida alguma informação real de
tempo, mesmo que seja uma única vez durante a inicialização atual do sistema, é possível
calcular o tempo real atual utilizando essa informação obtida e o relógio ERT. Para tanto, no
momento do recebimento, cria-se uma estrutura de dados contendo a informação temporal
recebida (T) e o estado do relógio ERT (E). A qualquer o momento, o tempo real atual (TR)
pode ser calculado a partir do estado do novo estado do relógio ERT (A), seguindo a fórmula:
TR = (A - E) + T (1)
No entanto, como T é oriundo de uma fonte externa ao sistema como a Internet, é
necessário compensar os eventuais atrasos na comunicação para mitigar os desvios temporais.
O protocolo NTP faz a correção desses desvios utilizando uma complexa estrutura de dados e
comunicação hierárquica contendo informações capturadas dos dois lados comunicantes.
Dado que na solução implementada aqui se utiliza o mesmo algoritmo para todas as fontes,
isto é, Internet, GPS e rede de telefonia, o algoritmo NTP original foi simplificado para operar
sem as informações que seriam geradas pelo lado servidor.
Assim, seguindo a estratégia de compensação de atraso simétrico do NTP, a
fórmula (1) anterior é incrementada da seguinte maneira: registra-se o estado (R1) do relógio
ERT ao iniciar a requisição de tempo e registra-se novamente o estado (R2) ao receber a
resposta. A qualquer momento futuro, o tempo real aproximado (TRA) será:
TRA = ((R2 – R1) / 2) + (A - E) + T (2)
Com essa estrutura de dados, tudo que o algoritmo de sincronia precisa fazer é
escolher a fonte apropriada de tempo e decidir quando coletar novas amostras. Na
implementação da solução, o algoritmo escolhe a fonte de tempo de acordo com
conectividade atual do dispositivo:
a) caso haja conexão com a Internet disponível, via pacote de dados ou WiFi,
essa será a fonte utilizada;
b) caso não haja conexão com a Internet disponível, a fonte de tempo será a rede
de telefonia;
c) caso a rede de telefonia também não esteja disponível, a fonte de tempo
utilizada será o GPS;
d) caso não seja possível contatar a Internet, a rede de telefonia, nem mesmo o
usuário é alertado de que o módulo se encontra sem fontes confiáveis de
tempo, sendo solicitado a ativar alguma fonte por um breve período.
Figura 14 - Ausência de fontes temporais
Fonte: elaborado pelo autor
Exceto no caso em que todas as fontes estão inacessíveis desde o momento em
que a aplicação foi iniciada, a sincronia temporal é automática e transparente ao usuário.
Imediatamente ao iniciar a aplicação, enquanto o usuário reage à abertura da primeira tela, o
gerenciador de tempo é disparado e age em segundo plano mantendo a sincronia temporal
sempre que necessário. Adicionalmente, nenhuma informação temporal é descartada
prematuramente ou atualizada sem necessidade, permitindo que trocas de contexto frequentes
não exijam novas sincronias em um período de tempo muito curto.
4.2.3 Autenticidade criptográfica
Para garantir a autenticidade do código provido na autenticação, assim como sua
integridade e não repúdio, faz-se uso de criptografia assimétrica. Um código com essas
qualidades é precisamente o que é representado pela assinatura digital em uma ICP.
No contexto da solução, a criptografia assimétrica traz benefícios sobre
criptografia simétrica, como a capacidade de autenticar o código provido sem armazenar
nenhuma informação crítica no dispositivo verificador. No caso alternativo em que
criptografia simétrica fosse utilizada, ambos os dispositivos precisariam conter uma chave
compartilhada para realizar a verificação, duplicando o fator de risco no caso de furto ou
perda de um dos dispositivos. Além disso, um esquema de atualização de chaves precisaria
ser desenvolvido para manter o dispositivo verificador a par de todas as chaves que ele precisa
