Danilo Souza Lima
Proposta para controle de acesso físico seguro
baseada em Near Field Communication (NFC)
e Android
São Carlos
2013
Danilo Souza Lima
Proposta para controle de acesso físico seguro baseada
em Near Field Communication (NFC) e Android
Trabalho de Conclusão de Curso apresentado
ao departamento de Engenharia elétrica da
Escola de Engenharia de São Carlos - USP
Universidade de São Paulo – USP
Escola de Engenharia de São Carlos – EESC
Orientador: Evandro L. L. Rodrigues
São Carlos
2013
AUTORIZO A REPRODUÇÃO TOTAL OU PARCIAL DESTE TRABALHO,
POR QUALQUER MEIO CONVENCIONAL OU ELETRÔNICO, PARA FINS
DE ESTUDO E PESQUISA, DESDE QUE CITADA A FONTE.
L732p
Lima, Danilo Souza
Proposta para controle de acesso físico seguro
baseada em Near Field Communication (NFC) e Android /
Danilo Souza Lima; orientador Evandro L. L. Rodrigues.
São Carlos, 2013.
Monografia (Graduação em Engenharia Elétrica com
ênfase em Eletrônica) -- Escola de Engenharia de São
Carlos da Universidade de São Paulo, 2013.
1. NFC. 2. Arduino. 3. Android. 4. Criptografia. 5.
Autenticação. I. Título.
-
FOLHA DE APROVAÇAO
Nome: Danilo Souza Lima
Título: "Segurança e controle de acesso de pessoas com utilização
de dispositivo móvel com NFC"
Trabalho de Conclusão de Curso defendido e aprovado
em 21 I_li 120.1d ,
com NOTA
Q3
C--~Ullte,
s
-fct
l, pela
Comissão Julgadora:
Prot. Associado Evandro Luís Linhari Rodrigues - (Orientador SEUEESC/USP)
Prof. Associado Adilson Gonzaga - (SEUEESC/USP)
Prot. Dr. Marcelo Andrade da Costa Vieira - (SEUEESC/USP)
Coordenador da CoC-Engenharia Elétrica - EESC/USP:
Prof. Associado Homero Schiabel
,
Agradecimentos
Agradeço aos meus pais, pelo incentivo durante o curso,
Ao tio "Jota", pela ajuda com técnicas de segurança e servidor Web,
Ao Bruno "Tintim", pela presteza em compartilhar seus recursos de trabalho,
Ao André Carmona, pelos comentários sempre valiosos,
Ao Bruno Kim e à Luzia pela ajuda com C++ e LATEX,
Ao Rodrigo, pelas excelentes dicas de Hardware,
E ao professor Evandro, pelas ótimas orientações e ricas discussões durante nossas
"Walking Meetings".
“A common mistake people make when trying
to design something completely foolproof is to
underestimate the ingenuity of complete fools.”
(Douglas Adams, Mostly Harmless)
Resumo
O trabalho de conclusão de curso apresentado elabora uma proposta para
controle de acesso físico segura e intuitiva com a utilização de um aparelho celular.
Para garantir a segurança e intuitividade do processo utilizou-se o Near Field Communication, que é uma comunicação via rádio-frequência com área de ação limitada
em no máximo 10cm. O objetivo final do projeto foi propor um método completo
para elaboração do sistema de controle de acesso, que deve servir como prova de
conceito e não como um produto comercial. Ele envolve a elaboração de um terminal
de acesso baseado em Arduino com Shield NFC além da criação de um aplicativo
móvel para Android e um website para gerenciamento. As principais dificuldades
do projeto foram a implementação dos protocolos de comunicação peer-to-peer NFC
em baixo nível e a implementação da segurança do sistema baseada em algoritmos
de criptografia. Foram utilizadas as linguagens de programação C++, JAVA e PHP
e os softwares envolvidos foram elaborados utilizando o modelo de prototipagem. O
trabalho foi testado utilizando-se um celular Galaxy SIII da Samsung, e o tempo de
comunicação com o terminal foi medido em torno de 5,5s. O NFC se mostrou uma
maneira prática e intuitiva para o projeto proposto. Com os resultados alcançados
foi possível identificar caminhos para a evolução do projeto conforme podem ser
observados no capítulo de conclusão.
Palavras-chaves: NFC, Arduino, Android, Criptografia, Autenticação
Abstract
The work presented here intend to propose a tool for physical access control that is safe and intuitive. For that end, the process makes use of Near Field
Communication, that is a Radio Frequency communication with a limited range of
no more than 10cm. The main goal of the project is to propose a method to be
used as a proof of concept and not as a stand alone comercial solution. It envolves
the elaboration of a physical access terminal based on the Arduino board with NFC
capability and the creation of an Android app and a website for administration.
The dificulties associated with the work were the implementation of low level protocols of NFC peer-to-peer comunication and the implementation of the security of
the system based on well-known public criptographic algorithms The programing
languages that were used on the elaboration of the softwares were C++, JAVA and
PHP and they were made by using the process of prototyping. The comunication
was testes by using a Samsung Galaxy SIII mobile phone and time needed for the
comunication was measured in about 5.5s. The NFC was a proved to be a effective
tool for a praticity and intuitivity in the project. It was possible to indetify ways
for improvenement of the work that can be seen in the conclusion chapter.
Key-words: NFC, Android, Arduino, Criptography, Autentication.
Lista de ilustrações
Figura 1 – Google Wallet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 2 – Comunicações Envolvidas . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 3 – OSI vs NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 4 – Funcionamento do NFC. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 5 – Modulação Digital OOK. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 6 – Arquitetura LLCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 7 – Representação de um PDU
. . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 8 – Representação do SNEP . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 9 – Mensagem NDEF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 10 – Tela de confirmação de envio de dados do Android Beam . . . . . . . . 41
Figura 11 – O modelo de criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 12 – Estágios intermediários do DES . . . . . . . . . . . . . . . . . . . . . . 44
Figura 13 – Troca de chave de Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . 45
Figura 14 – Ataque Man In The Middle . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 15 – Autenticação baseada em chave compartilhada . . . . . . . . . . . . . . 48
Figura 16 – Diagrama esquemático . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 17 – Arduino R3 UNO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 18 – Arduino MEGA 2560 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 19 – Arduino DUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 20 – Shield NFC para o Arduino . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 21 – Shield de prototipação para Arduino . . . . . . . . . . . . . . . . . . . 57
Figura 22 – Relay 5V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 23 – Primeiro Protótipo do Terminal . . . . . . . . . . . . . . . . . . . . . . 57
Figura 24 – Blocos do sistema desmontado . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 25 – Placa Montada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 26 – Sistema em funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 27 – IDE para o Arduino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 28 – IDE do Code::Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 29 – Esquema de geração de chave para criptografia . . . . . . . . . . . . . 66
Figura 30 – IDE Eclipse para programação em Android. . . . . . . . . . . . . . . . 70
Figura 31 – IDE - NETBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figura 32 – Diagrama Entidade-Relacionamento
. . . . . . . . . . . . . . . . . . . 76
Figura 33 – Primeira tela do aplicativo WEB . . . . . . . . . . . . . . . . . . . . . 76
Figura 34 – Administração das Fechaduras . . . . . . . . . . . . . . . . . . . . . . . 76
Figura 35 – Modificar Status de usuários . . . . . . . . . . . . . . . . . . . . . . . . 77
Figura 36 – Histograma dos dados da tabela 19 . . . . . . . . . . . . . . . . . . . . 84
Lista de tabelas
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
1 – Formato para um PDU tipo PAX . . . . . . . . . .
2 – Formato para um PDU tipo CONNECT . . . . . .
3 – Formato para um PDU tipo DISC . . . . . . . . .
4 – Formato para um PDU tipo I . . . . . . . . . . . .
5 – Formato para um PDU tipo I . . . . . . . . . . . .
6 – Formato de uma solicitação SNEP . . . . . . . . .
7 – Formato de uma resposta SNEP . . . . . . . . . .
8 – Comandos de solicitação . . . . . . . . . . . . . . .
9 – Comandos de Resposta . . . . . . . . . . . . . . . .
10 – Formato do Identificador de uma Gravação NDEF
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
34
34
35
35
35
37
37
38
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
11
12
13
14
15
16
17
18
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
61
62
62
62
62
69
69
– Características dos três Arduinos trabalhados
– Sintaxe do Comando InitAsTarget . . . . . .
– Sintaxe para o comando GetData . . . . . . .
– Sintaxe para a resposta do comando GetData
– Sintaxe para o comando SetData . . . . . . .
– Sintaxe para a resposta do comando SetData
– Sintaxe do protocolo criado . . . . . . . . . .
– Sintaxe autorização do servidor . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Tabela 19 – Testes de comunicação NFC . . . . . . . . . . . . . . . . . . . . . . . . 83
Tabela 20 – Média de tempo de comunicação com o aplicativo WEB . . . . . . . . 84
Lista de Algoritmos
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
Algoritmo de Conexão como Cliente SNEP . . . . . .
Algoritmo de Conexão como Servidor SNEP . . . . .
Algoritmo de recepção de dados . . . . . . . . . . . .
Algoritmo de Envio de dados . . . . . . . . . . . . .
Algoritmo de PUSH . . . . . . . . . . . . . . . . . .
Algoritmo de PULL . . . . . . . . . . . . . . . . . . .
Uso da Biblioteca AES . . . . . . . . . . . . . . . . .
Uso da Biblioteca HASH MD5 . . . . . . . . . . . . .
Algoritmo de Envio de dados . . . . . . . . . . . . .
Algoritmo Para uso do Beam𝑇 𝑀 no Android . . . . .
Segundo algoritmo Para uso do Beam𝑇 𝑀 no Android
Recebimento de mensagens NDEF com Android . . .
Recebimento de mensagens NDEF com Android . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
63
64
64
64
65
66
67
68
71
72
72
73
Lista de abreviaturas e siglas
NFC
Near Field Communication.
RFID
Radio Frequency IDentification.
NDEF
NFC Data Exchange Format.
DES
Data Encryption Standard.
RSA
Rivest, Shamir e Adleman. (Criadores desse método de criptografia)
P2P
peer-to-peer.
AES
Advanced Encription Standard.
MD5
Message Digest 5.
OOK
On-Off key.
LLCP
Link Layer Control Protocol.
SHA
Secure Hash Algorithm.
PHP
PHP: Hypertext Preprocessor.
HTML
HyperText Markup Language.
SNEP
Simple NDEF Exchange Protocol.
OSI
Open Systems Interconnection.
Lista de símbolos
⊕
OU EXCLUSIVO.
𝐸𝑘
Método de criptografia com a chave 𝑘.
𝐷𝑘
Método de decriptografia com a chave 𝑘.
Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2 Embasamento Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1
2.2
2.3
Near Field Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1
Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.2
Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.2.1
Camada Física (Hardware) . . . . . . . . . . . . . . . . . 30
2.1.2.2
Camada de enlace de Dados . . . . . . . . . . . . . . . . . 32
2.1.2.3
Camada de Aplicação . . . . . . . . . . . . . . . . . . . . 35
O sistema operacional Android
. . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.1
Aplicativos Android
. . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.2
Android e NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2.2.1
Android Beam𝑇 𝑀 . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.2.2
Dispositivos com chip NFC . . . . . . . . . . . . . . . . . 40
Segurança e criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.1
2.3.2
Métodos de criptografia . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.1.1
Método DES . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3.1.2
Método de compartilhamento de Chave de Diffie-Hellman
2.3.1.3
Métodos de chave pública . . . . . . . . . . . . . . . . . . 45
2.3.1.4
Algorítmos de HASH criptográficos . . . . . . . . . . . . . 47
44
Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3.2.1
Autenticação baseada em chave compartilhada . . . . . . . 48
2.3.2.2
Autenticador de uma mensagem . . . . . . . . . . . . . . . 49
3 Metodologia e Implementação . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.1
Descrição do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.1.1
3.2
3.3
Especificação de Requisitos do Projeto . . . . . . . . . . . . . . . . 52
3.1.1.1
Requisitos Não-funcionais . . . . . . . . . . . . . . . . . . 52
3.1.1.2
Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . 53
Hardware para a fechadura . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.1
O Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.2
O PN532
3.2.3
Primeiro Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.4
O protótipo Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Software para o Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.1
Implementação da Biblioteca para comunicação peer-to-peer NFC . 60
3.4
3.5
3.6
3.7
3.3.1.1 Comunicação com o PN532 . . . . . .
3.3.1.2 LLCP . . . . . . . . . . . . . . . . . .
3.3.1.3 SNEP . . . . . . . . . . . . . . . . . .
3.3.1.4 NDEF . . . . . . . . . . . . . . . . . .
3.3.2 Implementação da Criptografia . . . . . . . . .
3.3.2.1 Implementação da Biblioteca AES . .
3.3.2.2 Implementação da biblioteca MD5 . .
Algoritmo do Sistema Completo . . . . . . . . . . . . .
Protocolo criado para comunicação e autenticação . . .
3.5.1 Mensagem e assinatura do servidor . . . . . . .
3.5.2 Assinatura do Aplicativo . . . . . . . . . . . . .
Aplicativo para Android . . . . . . . . . . . . . . . . .
3.6.1 Envio de uma mensagem NDEF com o Beam𝑇 𝑀
3.6.2 Recebimento de uma mensagem NDEF . . . . .
3.6.3 Comunicação com o Servidor . . . . . . . . . .
Aplicativo web . . . . . . . . . . . . . . . . . . . . . .
3.7.1 Banco de Dados . . . . . . . . . . . . . . . . . .
3.7.2 A interface . . . . . . . . . . . . . . . . . . . . .
4 Resultados e Testes . . . . . .
4.1 Comunicação NFC . . . . .
4.2 Testes da comunicação NFC
4.3 Comunicação com o servidor
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
60
62
64
65
65
66
67
68
69
69
70
70
71
72
73
75
75
76
. . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
79
82
84
5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Apêndices
93
APÊNDICE A Esquemático do Primeiro Protótipo do Terminal . . . . . . . . 95
APÊNDICE B Esquemático do Protótipo Final do Terminal . . . . . . . . . . 97
25
1 Introdução
Desde que surgiram os primeiros aparelhos celulares, uma forte tendência foi observada no mercado, a substituição de outros aparelhos que eram comuns ao nosso dia à dia.
Calculadoras, agendas telefônicas, calendários e câmeras fotográficas, por exemplo, hoje
são encontrados mais facilmente em sua forma digital, reunidos em um único aparelho.
O telefone móvel já é utilizados para muito mais funções que quando foi proposto
comercialmente em 1983.
Essa tendência do uso de apenas uma estrutura para prover diversos serviços é
chamada Convergência Tecnológica, e um exemplo atual são os novos métodos de pagamento de mercadorias, como o Google Wallet (GOOGLE. . . , 2013) que pode ser vista na
figura 1. Dessa forma, o dispositivo móvel pode substituir, também, um cartão de crédito,
ou uma carteira.
Figura 1: Google Wallet: Pagamento via celular
Fonte: http://www.extremetech.com/
A motivação deste trabalho é incluir no celular uma nova função além destas
muitas que já foram citadas, a de dispositivo de controle de acesso.
É claro que não há objetivo de implementar um produto comercial, mas de servir
como uma prova de conceito e abrir um leque de possibilidades para futuras implementações.
Dois elementos básicos utilizados nesse trabalho são o celular, utilizado como dispositivo de controle de acesso, e o terminal de controle de acesso. Para confecção deste,
foi decidido por utilizar uma placa baseada no Arduino, pela facilidade de encontrar
periféricos e pela quantidade de bibliotecas disponíveis.
26
Capítulo 1. Introdução
A comunicação entre o terminal e o celular deve ser feita de forma segura e intuitiva. A ideia central é ter seu acesso garantido apenas aproximando o celular do terminal,
isso é possível graças a comunicação NFC (KUMAR, 2011), acrônimo para Near Field
Communication, que será discutido nas próximas seções.
O NFC já é utilizado em celulares para várias funções, a principal delas é a leitura
de cartões baseados nesta tecnologia, que podem funcionar como cartões de visita ou de
informações de murais eletrônicos.
Para implementação de um sistema mais completo, deve-se incluir, também, a
possibilidade de gerenciamento das autorizações através da internet. A figura 2 mostra
um diagrama de todas as comunicações envolvidas no projeto.
Figura 2: Comunicações Envolvidas
Para que todos os elementos do projeto funcionem corretamente, é necessário que
exista um protocolo de comunicação seguro e unificado. Este protocolo deve envolver
algoritmos criptográficos para garantir segurança do sistema.
Ao decorrer desse trabalho serão apresentadas todas as etapas de elaboração do
projeto, que inclui:
∙ Projeto e montagem do hardware para ser utilizado no terminal.
∙ Criação do software para comunicação via NFC.
∙ Criação de bibliotecas para criptografia e segurança das informações.
∙ Confecção de um aplicativo móvel para o sistema operacional Android, que deve
funcionar como interface entre o usuário e a fechadura.
∙ Elaboração de um aplicativo web, onde o administrador do sistema possa gerenciar
acessos individuais ao terminal.
27
∙ Elaboração de um protocolo de segurança para comunicação entre todas as partes
que formam o sistema.
29
2 Embasamento Teórico
2.1 Near Field Communication
O NFC, acrônimo para Near Field Communication, é um conjunto de padrões de
comunicação de rádio entre dois dispositivos a uma curta distancia, geralmente não mais
que alguns centímetros, o que o torna muito recomendado em transações que exigem certo
nível de segurança. (KUMAR, 2011; HASELSTEINER; BREITFUSS, 2006).
Esses padrões foram criados baseados no já existente RFID, acrônimo para Radio
Frequency IDentification. Eles incluem protocolos de comunicação e formatos de dados
definidos pelo Fórum NFC, criado em 2004 por Nokia, Sony e Philips, e hoje já possui mais
de 160 membros, incluindo Samsung, Google, RIM, Microsoft, Intel, Visa, MasterCard e
outros. (NFC - FORUM, 2013a)
2.1.1 Histórico
A história do NFC começa em 1983, em suas raízes, com o surgimento do RFID1 .
O NFC pode ser visto como uma aplicação restrita do RFID, com padrões e especificações
bem definidos e com o alcance diminuído, por motívos de segurança.
Já em 2004, vista a necessidade da criação e atualização desses padrões e especificações, foi criado o Fórum NFC. Depois disso logo começaram a surgir os primeiros
celulares possuidores dessa tecnologia, começando com o Nokia 6131.
Em 2009 foi criada uma nova forma de comunicação baseada nessa tecnologia,
o ‘peer-to-peer’, e logo em seguida surgiu o primeiro Android com capacidade NFC, O
Galaxy Nexus2 . O uso do NFC só aumentou desde então com o surgimento de Smart
Tags e dos métodos de pagamento utilizando celular.
Nesse ano, Samsung e VISA anunciaram uma parceria para desenvolvimento de
métodos de pagamento via celular (MAJOR. . . , 2013), o que promete aumentar o número
de dispositivos com chip NFC embutido.
2.1.2 Funcionamento
Existem basicamente três formas de comunicação NFC: (KUMAR, 2011)
1
2
Radio-Frequency Identification, permite que ondas de rádio sejam emitidas para um dispositivo passivo
para identificação e autenticação.
Surgido de uma parceria entre Samsung e Google (desenvolvedora do sistema operacional de código
aberto Android).
30
Capítulo 2. Embasamento Teórico
∙ Emulação de cartão: Onde um dispositivo se passa por uma tag ou cartão NFC
passivo para responder a um pedido de um iniciador ativo.
∙ Leitura e Gravação de cartão: Onde um iniciador pode ler ou gravar alguma informação em um dispositivo passivo.
∙ Peer to peer: Onde dois dispositivos NFC ativos se comunicam entre si.
Neste trabalho focou-se no uso da comunicação peer-to-peer uma vez que alguns
dos sistemas operacionais móveis que suportam NFC (incluindo o Android) não permitem
o modo de Emulação de Cartão.
Para explicar seu funcionamento, as seguintes sessões fazem um paralelo entre as
camadas do NFC e as do Modelo OSI. Apenas 3 camadas do modelo OSI são relevantes,
a camada física, a camada de enlace de dados e a camada de aplicação. Como é mostrado
na figura 3.
Figura 3: Comparação entre o Modelo OSI e o NFC
2.1.2.1 Camada Física (Hardware)
O NFC funciona usando a indução magnética. O iniciador emite uma pequena
corrente elétrica em sua antena, esta, cria um campo magnético que ocupa o espaço entre
o iniciador e o alvo. Esse campo é recebido por uma bobina na antena do dispositivo,
onde é convertido novamente para sinais elétricos para que seja possível a comunicação
de dados. O esquema dessa comunicação pode ser visto na figura 4.
2.1. Near Field Communication
31
Caso o alvo seja um dispositivo passivo3 ele usa a própria corrente que foi induzida
pelo iniciador para se alimentar, responder e enviar alguma informação. Casa seja ativo,
ele utiliza sua própria alimentação para responder ao iniciador.
Figura 4: Funcionamento do NFC.
Fonte: http://www.antenna-theory.com
Modulação e transferência de Dados
A modulação consiste em modificar as características de uma onda para transferir
informação. Essa onda é chamada de portadora.
Um exemplo de modulação pode ser visto na figura 5. A modulação OOK (on-off
key) consiste em um período de duração fixa onde o sinal está em 1 (HIGH) ou 0 (LOW).
Utilizando uma modulação digital como essa, a demodulação pode ser feita facilmente com o uso de um diodo e um capacitor. Também é implementado um extrator de
clock do sinal, para ser utilizado nos blocos lógicos do circuito. (NFC - FORUM, 2013b).
Figura 5: Representação da modulação Digital OOK.
Fonte: http://www.eetimes.com/
No NFC, o sinal é enviado modulando-se digitalmente uma portadora de 13.56MHz,
mas como ele pode ser aplicado em comunicações passivas, o sinal enviado é usado para
3
São chamados dispositivos passivos aqueles que não possuem uma própria fonte de alimentação, pode
ser um cartão ou Tag NFC.
32
Capítulo 2. Embasamento Teórico
alimentar o dispositivo, dessa forma a modulação OOK se torna inviável para uma mensagem com muitos ’zeros’ em sequência, então outros modelos mais complexos são utilizados
(NFC - FORUM, 2013b).
2.1.2.2 Camada de enlace de Dados
A camada de enlace de dados (segunda camada do modelo OSI) do NFC para
comunicações peer to peer é definida pelo NFC Fórum através da especificação técnica do
LLCP (Logical Link Control Protocol). Podemos citar como principais aspectos do LLCP:
(NFC - FORUM, 2011)
∙ Define como dois dispositivos dentro do alcance podem reconhecer implementações
compatíveis de LLCP, estabelecer a conexão e desativar quando for necessário.
∙ Define o MAC (Media Access Control) com o objetivo de evitar colisão de dados.
Tipicamente, dois dispositivos NFC em modo peer to peer, operam de forma que
um deles seja o mestre, chamado Initiator, que é capaz de enviar e requisitar dados
para o escravo, chamado target.
∙ O LLCP não provê nenhum tipo de segurança entre os dois pontos, a segurança
deve ser implementada nas outras camadas.
∙ É capaz de acomodar inúmeros protocolos de nível maior ao mesmo tempo.
Sua arquitetura pode ser vista na figura 6.
A LLCP define, como unidade básica, a structure PDU (Payload Data Unit), além
de seus tipos e usos. A próxima seção fala um pouco sobre os PDUs.
PDU
O formato de um PDU é constituído de um cabeçalho, que pode conter dois ou
três bytes, e do payload. O formato é mostrado na figura 7.
Os elementos que constituem um PDU são:
∙ Dois campos de endereço (cada um com 6 bits), DSAP (Destination Service Access
Point) e SSAP (Source Service Access Point). O DSAP deve informar o serviço do
ponto de acesso para qual a informação foi transmitida. O SSAP deve informar o
Serviço do ponto de acesso onde essa informação foi originada.
∙ Um campo de Tipo do PDU com tamanho de 4 bits. Esse campo deve identificar a
sintaxe e a semântica utilizada nos outros campos do PDU e deve ter um dos valores
2.1. Near Field Communication
33
Figura 6: Representação da arquitetura da LLCP.
Fonte: http://www.nfc-forum.org/
Figura 7: Representação de um PDU.
Fonte: http://www.nfc-forum.org/
especificados pelo NFC-Fórum. Para contexto desse trabalho, apenas comentaremos
sobre alguns desses tipos.
∙ Um capo de sequência formado por 0 ou 1 bytes, está presente apenas em alguns
tipos de PDU. O campo de sequência, quando presente, está dividido em 4 bits
para sequência de envio (nos bits mais significantes), e 4 bits para a sequência de
recepção (nos 4 bits menos significantes).
∙ Um campo de informação formado por 0 ou N bytes, o tamanho desse campo depende do tipo de PDU e o máximo valor de N depende do serviço que receberá a
informação.
34
Capítulo 2. Embasamento Teórico
Tipos de PDU
Serão comentados apenas alguns tipos de PDU’s, os mais relevantes para o contexto
deste trabalho.
∙ PDU tipo PAX
O PDU tipo PAX é usado para trocas de parâmetros no que diz respeito à configuração do enlace LLCP. O parâmetro de sequência não é usado para esse tipo de PDU
e o campo de informação deve conter os parâmetros de configuração. O formato
para os parâmetros de configuração se encontram fora do contexto desse trabalho.
Para um PDU tipo PAX, os dois campos de endereço devem ser 0, o formato de um
PDU tipo PAX é visto na tabela 1.
Tabela 1: Formato para um PDU tipo PAX
DSAP
PTYPE
SSAP
INFORMAÇÂO
000000
0001
000000
Lista de parâmetros
∙ PDU tipo CONNECT
O PDU tipo Connect é usado para solicitação de uma conexão. Ele deve conter
ambos os campos de endereço e pode conter o campo de informações para parâmetros
de conexão. O formato para esses não se encontram no contexto deste trabalho. O
formato para um PDU do tipo connect pode ser visto na tabela 2:
Tabela 2: Formato para um PDU tipo CONNECT
DSAP
PTYPE
SSAP
INFORMAÇÃO
DDDDDD
0100
SSSSSS
Lista de parâmetros (opcional)
∙ PDU tipo DISC
O PDU tipo DISC (Disconnect) Serve para terminar uma conexão, ele não deve
possuir o octeto de sequencia nem os bytes de informação. O formato é mostrado
na tabela 3.
Tabela 3: Formato para um PDU tipo DISC
DSAP
PTYPE
SSAP
DDDDDD
0101
SSSSSS
∙ PDU tipo I
O PDU do tipo I (Information) é usado para transferir dados pelo enlace LLCP.
Ele deve possuir os bits de sequência e os bytes de informação. O formato pode ser
visto na tabela 4.
2.1. Near Field Communication
35
Tabela 4: Formato para um PDU tipo I
DSAP
PTYPE
SSAP
DDDDDD
1100
SSSSSS
Sequência
Seq. envio
INFORMAÇÃO
Seq. recebimento
Dados
∙ PDU tipo SYMM
O PDU do tipo SYMM (Symmetry) esse tipo de PDU é usado pela LLCP para
quando nenhum outro PDU está disponível para ser mandado, apenas para garantir
a simetria do protocolo. Pode-se ver o formato na tabela 5.
Tabela 5: Formato para um PDU tipo I
DSAP
PTYPE
SSAP
DDDDDD
1100
SSSSSS
Sequência
Seq. envio
INFORMAÇÃO
Seq. recebimento
Dados
2.1.2.3 Camada de Aplicação
No nível da aplicação, um dos protocolos utilizados para troca de unidades de
dado pelo NFC é o SNEP (Simple NDEF Data Exchange). Esses dados são enviados
no formato de menssagens NDEF (NFC Data Exchange Format). Esses tópicos serão
discutidos com mais profundidades nas subseções seguintes.
Outros protocolos utilizados para comunicação via NFC peer-to-peer não serão
abordados nem mencionados no contexto desse trabalho.
Protocolo SNEP
O SNEP (NFC - FORUM, 2013c) é um protocolo de solicitação e resposta (request/response) onde o cliente faz uma solicitação ao servidor e espera uma resposta. Caso
o tamanho de uma solicitação ou uma resposta seja maior que o máximo possível para o
protocolo inferior, no caso, o LLCP mencionado na seção anterior, ela deve ser dividida
em fragmentos. A figura 8 mostra um exemplo de comunicação baseado no protocolo
SNEP.
Uma solicitação SNEP tem o formato mostrado na tabela 6 e a resposta possui o
formato especificado na tabela 7.
Tabela 6: Formato de uma solicitação SNEP
Cabeçalho SNEP
Versão Solicitação Tamanho
1 byte
1 byte
4 bytes
Carga útil
Tamanho especificado
O significado dos campos vistos nas tabelas 6 e 7 é:
36
Capítulo 2. Embasamento Teórico
Figura 8: Representação de uma comunicação utilizando o protocolo SNEP.
Fonte: http://www.nfc-forum.org/
Tabela 7: Formato de uma resposta SNEP
Cabeçalho SNEP
Versão Resposta Tamanho
1 byte
1 byte
4 bytes
Carga útil
Tamanho especificado
∙ Versão indica o formato da mensagem que está sendo enviada e a capacidade do
dispositivo que a enviou de entender comunicações futuras. É formado 2 números
inteiros de 4 bits, o primeiro para a maior versão e o segundo para menor versão
aceita.
∙ Solicitação indica a ação que deve ser executada no servidor, a tabela 8 mostra os
tipos de comandos aceitos.
∙ Resposta indica o resultado da ação solicitada ao servidor. A tabela 9 mostra os
comandos utilizados como resposta.
∙ Tamanho são 4 bytes que indicam o tamanho da carga útil, são utilizados 4 bytes,
o que indica que o máximo tamanho de uma mensagem NDEF é FFFFFFFFh isso
é, 232 − 1 bytes.
2.1. Near Field Communication
37
∙ Carga útil é a parte da mensagem onde vai a mensagem NDEF, a ser discutida um
pouco mais a frente
Tabela 8: Comandos de solicitação
Código
00h
Comando
Continue
01h
Get
02h
Put
7Fh
Reject
Descrição
Continuar enviando os próximos fragmentos da mensagem (esse comando não
será importante no contexto deste trabalho).
Requisita do servidor uma
mensagem NDEF de resposta deve conter na carga
útil o tamanho máximo da
mensagem a ser recebida e
uma mensagem NDEF que
identifica o tipo de mensagem a ser recebida.
Solicita que o servidor
aceite uma mensagem
NDEF que é enviada na
carga útil.
Solicita que o servidor não
envie os próximos fragmentos da mensagem.
Formato NDEF
O NDEF (NFC - FORUM, 2006) é o formato que define a forma como uma mensagem será encapsulada para transferência, ele pode ser usado tanto para tags passivas
quanto para dispositivos ativos4 . Para explicar como funciona uma mensagem NDEF
serão usadas as seguintes definições:
∙ Mensagem NDEF: Composta por uma ou mais gravações NFC.
∙ Gravação NDEF: Mensagem a ser transmitida, formada basicamente por um
cabeçalho e uma ‘carga útil’.
∙ Cabeçalho: Composto de um identificador, o tamanho da carga útil e o tipo da
carga útil.
∙ Carga Útil: Dados que se deseja transmitir.
4
Existem vários outros formatos de dados ultilizados. Como o NDEF é largamente utilizado pela
maioria dos sistemas operacionais móveis graças a escolha do protocolo SNEP para a grande parte
das aplicações NFC, esse trabalho se limitará a esse formato
38
Capítulo 2. Embasamento Teórico
Tabela 9: Comandos de Resposta
Código
80h
Comando
Continue
81h
Success
C0h - C2h
Erro
E0h - E1h
Não Suportado
Descrição
Continuar enviando os próximos fragmentos da mensagem (esse comando não
será importante no contexto desse trabalho).
Requisita do servidor uma
mensagem NDEF de resposta deve conter na carga
útil o tamanho máximo da
mensagem a ser recebida e
uma mensagem NDEF que
identifica o tipo de mensagem a ser recebida.
Códigos para alguns tipos
de erro, como mensagem
mal formulada ou excesso
de dados
Indica que a versão ou o
tipo de solicitação não é
suportado.
A figura 9 mostra o encapsulamento de uma mensagem NDEF.
Figura 9: Mensagem NDEF.
Fonte: http://www.developer.nokia.com
O identificador de uma mensagem NDEF tem seu formato mostrado na tabela 10
∙ MB (Message Begining): Se for 1 indica que essa é a primeira gravação na
mensagem.
2.2. O sistema operacional Android
39
Tabela 10: Formato do Identificador de uma Gravação NDEF
MB
ME
CF
SR
IL
TNF
∙ ME (Message End): Se for 1 indica que essa é a ultima gravação da mensagem.
∙ CF (Chunck Record): Indica que essa é uma gravação incompleta e apenas parte
da carga útil está presente.
∙ SR (Short Record): Caso esteja em 1, indica que essa é uma gravação pequena
e o campo Tamanho possui apenas um byte.
∙ IL (ID Length:) Indica que existe um octeto para o tamanho do ID e um campo
para o ID da gravação do tamanho indicado.
∙ TNF (Type Name Format): Indica o formato do campo tipo.
2.2 O sistema operacional Android
O Android (ANDROID. . . , 2013) é um sistema operacional baseado em Linux
e desenvolvido primariamente para dispositivos móveis com touchscreen, como tablets e
celulares. Ele foi desenvolvido primeiramente pela Android Inc., que em 2005 foi comprada
pela Google. O Android é open-source e o código é disponibilizado pela Google sob a
licença Apache. (ANDROID. . . , 2013).
O fato de ter código aberto o tornou muito popular entre os desenvolvedores e,
segundo o site visionmobile (DEVELOPER. . . , 2013), é utilizado por 71% dos desenvolvedores de aplicativos móveis.
Esses fatores contribuíram bastante para tornar o Android a plataforma móvel
mais utilizada no mundo. Segundo o site IDC (IDC. . . , 2013), no segundo trimestre de
2013, o android possuía 79,3 % de Market Share.
2.2.1 Aplicativos Android
Os aplicativos desenvolvidos para Android são escritos em linguagem JAVA utilizando o Android SDK, que inclui uma ferramenta de Debug, bibliotecas e um emulador.
A maior parte dos aplicativos desenvolvidos são lançados na Google Play, a loja
de aplicativos da Google, mas o sistema permite que um usuário baixe, instale e utilize
aplicativos por outros meios. (ANDROID. . . , 2013)
40
Capítulo 2. Embasamento Teórico
2.2.2 Android e NFC
O sistema operacional Android possui sua própria biblioteca para que desenvolvedores consigam usar os recursos NFC do celular. Por motivos de segurança, não é
permitido operá-lo em baixo nível.
As primeiras versões do Android apenas suportavam o modo de leitura e escrita
para NFC, o modo de emulação de cartão ainda não foi disponibilizado para o público e o
modo peer-to-peer é disponibilizado apenas através do Android Beam𝑇 𝑀 (ANDROID. . . ,
2013) que será discutido na próxima subseção.
2.2.2.1 Android Beam𝑇 𝑀
Essa é uma maneira simples para transmitir mensagens através do NFC entre dois
dispositivos. O Beam𝑇 𝑀 foi criado para fazer troca de pequenas informações entre dois
dispositivos Android apenas tocando um no outro, e isso acarreta algumas limitações que
são tratadas como restrições de projeto: (ANDROID. . . , 2013)
∙ A aplicação que está enviando uma mensagem deve estar em foreground, aberta e
visível para o usuário.
∙ Os dados enviados devem ser encapsulados em uma mensagem NDEF. O Beam𝑇 𝑀
apenas suporta SNEP sobre LLCP.
∙ Uma mensagem só pode ser enviada com a autorização do usuário. Isso é feito
através de uma tela com a mensagem: "Toque para transferir". Ela pode ser vista
na figura 10. No momento não é possível enviar dados via NFC sem que o usuário
toque a tela em confirmação.
2.2.2.2 Dispositivos com chip NFC
Com o crescimento do NFC, muitos celulares android possuem chip NFC embutidos. A google anunciou durante o evento "Google I/O"desse ano, que cerca de 1 milhão de
dispositivos Android com essa funcionalidade são ativados a cada semana. Esses números
tendem apenas a crescer, segundo a STRATEGY ANALITICS, no final de 2013 serão em
torno de 400 milhões de smartphones com NFC (cerca de um terço).
2.3. Segurança e criptografia
41
Figura 10: Tela de confirmação de envio de dados do Android Beam
2.3 Segurança e criptografia
Um ponto importante para um projeto que envolve o gerenciamento de dados de
um cliente, é assegurar de que esses dados não possam ser lidos ou usados por intrusos.
Um programa deve garantir que a informação seja armazenada, transmitida e
recebida de forma segura. Nessa sessão foi feito um apanhado de informações sobre
inúmeros métodos de segurança no armazenamento e na comunicação.
2.3.1 Métodos de criptografia
A criptografia tradicional consiste em um método de transmissão de dados em que
as mensagens a serem enviadas, aqui será chamado de texto simples, são transformadas
em uma mensagem ilegível, aqui chamada de texto criptografado.
Durante o processo de comunicação a mensagem criptografada é enviada para o
destinatário, este, conhecendo o método de decriptografia pode transformá-la em texto
simples novamente. (SCHNEIER, 1996).
A figura 11 mostra como funciona o modelo clássico de criptografia. Para que este
funcione, deve-se supor que o destinatário conhece o método de decriptografia. Dessa
forma, porem, ele deve ser mudado sempre que for comprometido, uma vez que um intruso
42
Capítulo 2. Embasamento Teórico
Figura 11: O modelo de criptografia
também possa conhecê-lo. Para evitar tal esforço, usa-se uma chave de criptografia, que
nada mais é que uma string usada para parametrizar o método. Dessa forma, precisa-se
de uma chave sigilosa e um método público.
Visto que os métodos de criptografia e decriptografia são apenas funções matemáticas onde a chave e o texto são parâmetros, será usada uma notação similar àquelas
sugeridas por Tanenbaum (1997) e Schneier (1996), onde:
∙ 𝐶: Texto cifrado.
∙ 𝑆: Texto simples.
∙ 𝐸𝑘 : Método de criptografia usando a chave k.
∙ 𝐷𝑘 : Método de decriptografia usando a chave k.
Dessa forma pode-se escrever:
𝐶 = 𝐸𝑘 (𝑆)
(2.1)
𝑆 = 𝐷𝑘 (𝐶)
(2.2)
e
O que significa que a encriptação da mensagem 𝑆, usando a chave 𝑘 tem como
resultado 𝐶 e, da mesma forma, 𝐶 decriptado com utilização da chave 𝑘 resulta em 𝑆.
As equações também sugerem:
𝑆 = 𝐷𝑘 (𝐸𝑘 (𝑆))
(2.3)
2.3. Segurança e criptografia
43
É claro que esse método depende de um meio seguro por onde a chave encriptação
possa ser transmitida. Uma maneira de evitar isso é utilizar um método de chave pública
ou um método seguro de de compartilhamento de chaves secretas.
2.3.1.1 Método DES
O método de encriptação Data Encryption Format (DES) é usado largamente em
informática. Segundo Wayner (1995), ele já não é mais segura quando usada da mesma
forma que foi criada, porém, modificado, ainda é bastante útil.
Segundo Tanenbaum (1997), o DES funciona dividindo o texto simples em blocos
de 64 bits que passam por 19 estágios distintos parametrizados por uma chave de 56 bits.
O primeiro estágio é uma transposição de chave independente5 no texto simples
𝑆. No último estágio é feita a mesma transposição de forma invertida. No penúltimo
estágio é feito um SWAP de 32 bits6 . Nos estágios intermediários divide-se o bloco de 64
bits em dois blocos de 32 bits, que serviram como entrada. Será utilizado 𝐷𝑖𝑛 e 𝐸𝑖𝑛 para
denotar as entradas e 𝐷𝑜𝑢𝑡 e 𝐸𝑜𝑢𝑡 para denotar as saídas. Esse método foi criado para que
a mesma chave de criptografia possa ser usada para decriptografia.
As equações de cada método intermediário são:
𝐸𝑜𝑢𝑡 = 𝐷𝑖𝑛
(2.4)
𝐷𝑜𝑢𝑡 = 𝐸𝑖𝑛 ⊕ 𝐹𝑘𝑖 (𝐷𝑖𝑛 )
(2.5)
e
A figura 12 mostra como funciona cada estágio intermediário.
A complexidade do algoritmo consiste na complexidade da função 𝐹 , que não será
explicada com detalhes, mas consiste em uma expansão de 𝐷𝑖𝑛 para 48 bits, uma operação
OU EXCLUSIVO bit a bit com 𝑘𝑖 e um processo complexo transforma a saída em 32 bits
novamente.
Em cada um desses estágios, uma chave diferente é utilizada. Antes do início do
algoritmo uma transposição é aplicada a chave e logo depois esta é particionada em duas
unidade de 28 bits. Essas unidade são roteadas para esquerda ou direita um certo número
de bits de acordo com o estágio. Em cada estágio é usado um subconjunto de 48 bits para
𝑘𝑖 .
5
6
Método onde os bits da mensagem são colocados em ordem diferente segundo imposto pela chave
Método onde se troca os 32 bits da esquerda com os 32 bits da direita
44
Capítulo 2. Embasamento Teórico
Figura 12: Estágios intermediários do DES
O método DES é mais utilizado hoje em dia em suas variações, uma delas é o
processo de tripla criptografia com duas chaves, onde:
𝐶 = 𝐸𝑘1 (𝐷𝑘2 (𝐸𝑘1 (𝑆)))
(2.6)
𝑆 = 𝐷𝑘1 (𝐸𝑘2 (𝐷𝑘1 (𝐶)))
(2.7)
e
(TANENBAUM, 1997)
Pode-se observar que apesar da tripla criptografia apenas duas chaves são utilizadas, o uso de uma terceira chave seria um grande exagero uma vez que os 112 bits das
duas chaves são suficientes para garantir a segurança.
Alem disso, pode ser visto que o processo de criptografia envolve uma decriptografia com uma segunda chave7 , um bom motivo para isso a retrocompatibilidade (Schneier,
1996). Apenas definindo 𝑘1 = 𝑘2 um computador que usa criptografia tripla pode se
comunicar com um que usa a simples, uma vez que:
𝐸𝑘1 (𝑆) = 𝐸𝑘1 (𝐷𝑘1 (𝐸𝑘1 (𝑆)))
(2.8)
2.3.1.2 Método de compartilhamento de Chave de Diffie-Hellman
Um problema dos métodos de chave única é como estabelecê-la de forma segura
entre remetente e destinatário. O método de troca de Chave de Diffie-Hellman (DIFFIE;
HELLMAN, 1976) resolve esse problema.
7
Chama-se: DES no modo EDE.
2.3. Segurança e criptografia
45
Considere que 𝐴 e 𝐵 precisem estabelecer uma chave secreta para uma comunicação segura. Primeiro escolhe-se 2 números primos extensos, 𝑛 e 𝑔, de forma que (𝑛 − 1)/2
e (𝑔 − 1)/2 também sejam primos. Esses números são públicos e podem ser informados
abertamente sem comprometimento da segurança. 𝐴 deve selecionar um número extenso,
𝑎, que deve ser mantido em segredo. B seleciona um segundo número, 𝑏, da mesma forma.
𝐴 envia uma mensagem para 𝐵 contendo (𝑔 𝑎 mod 𝑛) e 𝐵 envia uma mensagem
contendo (𝑔 𝑏 mod 𝑛). 𝐴 pode calcular: (𝑔 𝑏 mod 𝑛)𝑎 e b pode calcular: (𝑔 𝑎 mod 𝑛)𝑏 .
Como:
(𝑔 𝑎 mod 𝑛)𝑏 = 𝑔 𝑎𝑏 mod 𝑛 = (𝑔 𝑏 mod 𝑛)𝑎
Dessa forma 𝐴 e 𝐵 possuem uma chave secreta compartilhada (𝑔 𝑎𝑏 mod 𝑛). Mesmo
que uma intrusa intercepte todas as mensagens, ela consegue os valores de: 𝑔, 𝑛, (𝑔 𝑏 mod 𝑛),
(𝑔 𝑎 mod 𝑛). Mas mesmo com esses dados, não é possível calcular os valores de 𝑎, 𝑏 ou
(𝑔 𝑎𝑏 mod 𝑛). A figura 13 mostra a comunicação entre 𝐴 e 𝐵
Figura 13: Método de troca de chave de Diffie-Hellman
Um problema desse método é um tipo de ataque chamado man in the middle, que
envolve um intruso ativo. Considerando que um intruso 𝐼 pode interceptar a comunicação
entre 𝐴 e 𝐵, ele pode se passar por um dos dois e enviar mensagens falsas, escolhendo
um número próprio, 𝑖. A figura 14 mostra como funciona esse ataque. Dessa forma 𝐼
pode calcular: (𝑔 𝑎𝑖 mod 𝑛) e (𝑔 𝑏𝑖 mod 𝑛), as mesmas chaves que 𝐴 e 𝐵, respectivamente,
calcularam.
2.3.1.3 Métodos de chave pública
Um dos grandes problemas dos métodos de criptografia mencionados anteriormente
está na distribuição de chaves. Caso um intruso consiga roubar a chave, o sistema se torna
inútil. Diffie e Hellman (1976) propuseram um novo sistema de criptografia onde a chave
usada para criptografar é diferente da chave usada para decriptografar. Nesse sistema
46
Capítulo 2. Embasamento Teórico
Figura 14: Ataque Man In The Middle
deve-se garantir que é extremamente difícil de deduzir uma das chaves conhecendo a
segunda.
Esse método funciona da seguinte maneira. Considerando a comunicação entre
𝐴 e 𝐵, 𝐴 cria uma chave de criptografia e uma de decriptografia, 𝑘𝑒 e 𝑘𝑑 respectivamente. A chave 𝑘𝑑 se torna pública (chave pública) enquanto 𝑘𝑒 é mantida em segredo
(chave privada), os métodos de criptografia e decriptografia, 𝐸 e 𝐷, também são tornados
públicos.
Qualquer um interessado em se comunicar seguramente com 𝐴, 𝐵, por exemplo,
usa a chave pública e o método de encriptação para gerar uma mensagem cifrada:
𝐶 = 𝐸𝑘𝑒 (𝑇 )
(2.9)
Assim qualquer um que interceptar a comunicação saberá 𝐶 e 𝑘𝑒 , mas a partir
disso é impossível determinar 𝑇 . Uma vez que apenas 𝐴 possui a chave para decriptar.
Quando a mensagem chega até 𝐴, precisa-se fazer:
𝑇 = 𝐷𝑘𝑑 (𝐶)
(2.10)
Algoritmo RSA
O algoritmo RSA foi proposto por um grupo de pesquisadores do MIT e é baseado
na teoria dos números. Seu nome é dado pela inicial dos três matemáticos que o criaram,
Rivest, Shamir e Adleman.
A forma resumida do funcionamento do método é, segundo Rivest e Adleman
(1978):
∙ Escolhe-se dois números primos bastante extensos (em geral maior que 10100 ), 𝑝 e 𝑞
por exemplo.
2.3. Segurança e criptografia
47
∙ Calcula-se 𝑛 = 𝑝 × 𝑞 e 𝑧 = (𝑝 − 1) × (𝑞 − 1).
∙ Escolhe-se um número 𝑑 onde 𝑑 e 𝑧 são primos entre si8 .
∙ Calcula-se 𝑒 onde 𝑒 × 𝑑 = 1 mod 𝑧
∙ Divide-se o texto simples em blocos de modo que cada mensagem, 𝑆, fique no
intervalo: 0 ≤ 𝑆 ≤ 𝑛.
∙ Para criptografar a mensagem calcula-se 𝐶 = 𝑃 𝑒 ( mod 𝑛).
∙ Para decriptografar a mensagem calcula-se 𝑃 = 𝐶 𝑑 ( mod 𝑛).
Pelo método pode-se perceber que para criptografia precisa-se do par (𝑒, 𝑛) (chave
pública) e para decriptografia do par (𝑑, 𝑛) (chave privada).
A segurança do método está baseda na dificuldade de se fatorar números bastante extensos. Caso consiga-se fatorar o número publicamente conhecido 𝑛, poderia-se
descobrir os valores de 𝑝, 𝑞, 𝑧 e consequentemente 𝑑.
Porém, considerando um tempo de 1𝜇𝑠 por instrução, o melhor dos algoritmos
levaria 4 bilhões de anos para fatorar um número de 200 dígitos e 1025 anos para um de
500 dígitos. (RIVEST; ADLEMAN, 1978)
O RSA é muito utilizado para distribuir chaves de sessões únicas, dados muito
grandes são geralmente encriptados com o DES, uma vez que o RSA é muito lento para
essa função.
2.3.1.4 Algorítmos de HASH criptográficos
Uma função de hash deve receber um vetor de bytes de tamanho arbitrário e
retornar um segundo vetor de tamanho fixo de forma que qualquer mudança nos dados
vai, com grande probabilidade, modificar o valor de saida, chamado de hash ou digest.
Segundo Tanenbaum (1997), uma função de hash criptográfico ideal, deve possuir
as seguintes propriedades:
∙ É computacionalmente fácil computar o valor de hash de qualquer mensagem.
∙ É computacionalmente intratável gerar uma mensagem sabendo seu valor de hash.
∙ É computacionalmente intratável encontrar duas mensagens com o mesmo hash.
Essa propriedade é chamada de resistência a colisão.
8
chama-se primos entre si dois números que não possuem um divisor comum além de 1
48
Capítulo 2. Embasamento Teórico
Algoritmos de hash são utilizados tanto para verificação de senhas do usuário
quanto para assinaturas digitais e MACs (Message Autentication Code).(BELLARE; KILIAN; ROGAWAY, 2000)
Os métodos de hash criptográficos mais utilizados são o MD5 (RIVEST et al.,
1992) e o SHA (STANDARD, 1993).
2.3.2 Autenticação
A autenticação é o processo de verificar a veracidade de um dado ou informação.
Isso, em geral, envolve confirmar a identidade de uma pessoa ou software. Em muitas
aplicações, garantir que uma informação é autentica é mais importante que o próprio
sigilo da informação. (TANENBAUM, 1997).
Não se deve confundir autenticação e autorização, apesar de estarem relacionados,
o primeiro consiste no processo de verificar a identidade de uma pessoa enquanto o segundo
verifica permissões que uma identidade tem de executar uma ação.
Sistemas que envolvem controle de acesso são exemplos de sistemas que necessitam
de mecanismos com ambas as funções.
Nesta seção, será mostrado dois métodos que podem ser utilizados para garantir
a autenticação de um dispositivo ou mensagem digital.
2.3.2.1 Autenticação baseada em chave compartilhada
Considerando que A e B já possuem uma chave compartilhada (𝑘𝐴𝐵 ), uma forma
de garantir a autenticidade em uma comunicação é através do método de desafio/resposta,
que funciona da seguinte forma: A gera uma sequencia de números (𝑅𝐴 ) aleatórios e envia
para B, B usa a chave compartilhada e gera 𝐸𝑘𝐴𝐵 (𝑅𝐴 ). B envia o resultado da encriptação
para A, que compara com a sua própria encriptação. A sabe que um invasor não poderia
ter encriptado corretamente 𝑅𝐴 pois apenas B conhece a chave secreta 𝑘𝐴𝐵 . Esse método
pode ser visto na figura 15. (TANENBAUM, 1997)
2.3.2.2 Autenticador de uma mensagem
Uma segunda maneira de garantir autenticação é através de um autenticador, que é
conhecido como MAC (Message Autentication Code) (BELLARE; KILIAN; ROGAWAY,
2000).
O MAC é uma pequeno pedaço de informação que é utilizado para autenticar uma
mensagem. Ele recebe como entrada uma chave e a mensagem, que deve ser autenticada,
e retorna o MAC, que nada mais é que uma encriptação de uma função HASH.
2.3. Segurança e criptografia
49
Figura 15: Método de autenticação baseado em chave compartilhada
Ele se diferencia dos outros métodos de assinaturas digitais uma vez que utiliza
encriptação simétrica, e não de chave privada.
O MAC parte da hipótese de que as duas partes que necessitam da autenticação
já compartilham uma chave secreta. Caso essa chave seja comprometida, todo o processo
de autenticação pode se tornar inválido. (TANENBAUM, 1997)
51
3 Metodologia e Implementação
3.1 Descrição do Projeto
O projeto consiste em um terminal desenvolvido com utilização da plataforma
Arduino, com capacidade NFC adicionada, que controla uma fechadura elétrica. Esse
terminal deve ser capaz de se comunicar com um celular, que também deve ter capacidades
NFC, rodando um aplicativo desenvolvido para o sistema operacional Android.
O projeto também prevê a utilização de um aplicativo web para gerenciamento e
administração de acesso.
Um diagrama esquemático das interações entre os componentes do sistema pode
ser visto na figura 16. Uma explicação mais detalhada do processo envolvido será incluída
nas próximas seções.
Figura 16: Diagrama esquemático
O desenvolvimento e implementação do sistema possuiu 4 etapas:
∙ Desenvolvimento e montagem do hardware.
∙ Desenvolvimento do software para a fechadura.
∙ Desenvolvimento do aplicativo para android.
∙ Desenvolvimento da aplicação Web.
52
Capítulo 3. Metodologia e Implementação
Cada uma dessas etapas será abordada de forma mais detalhada nas seções seguintes.
3.1.1 Especificação de Requisitos do Projeto
Serão utilizadas as seguintes definições para os STAKEHOLDERS:
Desenvolvedor Responsável pela elaboração da solução técnica.
Cliente Pessoa ou empresa que contrata o serviço para ser usado em um cofre ou portas.
Usuário Aquele que utiliza o serviço, usando seu celular para abrir uma fechadura.
Também serão usadas as seguintes definições:
Terminal Hardware encontrado na fechadura.
Aplicativo móvel Software desenvolvido para Android.
Aplicativo WEB ou Servidor Site desenvolvido na para acesso WEB.
Sistema Conjunto de todo sistema composto por terminal aplicativo móvel e aplicativo
WEB.
3.1.1.1 Requisitos Não-funcionais
∙ A comunicação entre o Aplicativo móvel e o Terminal deve ser feita de forma
segura com criptografia RSA, DES ou AES(FIPS, 2001) e autenticação.
∙ O Desenvolvedor deve prever atualizações periódicas para suprir a necessidade de
segurança do sistema.
∙ Todos os dados dos Usuários e do Cliente devem ser gravados de forma criptografada e segura, através de uma função Hashing.
∙ O tempo entre o envio da mensagem pelo Aplicativo móvel e a abertura da porta
dever ser o menor possível (< 5𝑠).
∙ O usuário deve conseguir acesso com o mínimo de configuração possível e o mínimo
de toques na tela.
∙ Apenas uma mensagem deve ser enviada pelo Aplicativo móvel para o Terminal
a fim de cumprir os requisitos dos dois itens anteriores.
∙ O sistema deve gravar um LOG de acesso à fechadura, relatando quais Usuários a
utilizaram.
3.2. Hardware para a fechadura
53
∙ O Cliente deve ser capaz de, a qualquer momento, verificar o LOG de acesso.
∙ A interface do aplicativo deve ser limpa e desenvolvida utilizando o método KISS
Keep It Symple, Stupid.
∙ O aplicativo móvel deve rodar em Android versão 4.0 (Ice Cream Sandwish) e
mais novas.
∙ O aplicativo móvel deve ser atualizado automaticamente quando necessário, seja
via Google Play ou por um sistema customizado do Desenvolvedor (sem necessidade de intervenção do Usuário ou Cliente).
∙ O aplicativo web deve ser implementado com utilização do HTTPs.
∙ O sistema deve implementar um time-out para a autorização de um usuário.
Obs. A segurança do meio físico não faz parte deste projeto de TCC.
3.1.1.2 Requisitos Funcionais
∙ O terminal deve controlar um Relê para acionar uma fechadura elétrica alimentada
com 12V.
∙ O terminal deve ser capaz de se comunicar através do NFC utilizando o modo de
comunicação peer-to-peer.
∙ O Terminal deve ser capaz receber e enviar mensagens por NFC no formato NDEF
com utilização do protocolo SNEP sobre LLCP.
∙ O Cliente deve ser capaz de autorizar ou revogar a autorização de qualquer usuário
para acesso de qualquer terminal a qualquer momento através do Aplicativo WEB.
3.2 Hardware para a fechadura
Para cumprimento dos requisitos funcionais do projeto, precisou-se escolher:
∙ Que tipo de micro-controlador será usado.
∙ Que tipo de relê será utilizado.
∙ Qual hardware será utilizado para incluir a funcionalidade NFC.
As seções seguintes discorrem sobre essas escolhas.
54
Capítulo 3. Metodologia e Implementação
3.2.1 O Arduino
O Arduino é uma plataforma de prototipagem eletrônica baseada em processadores
da ATMEL, que podem variar desde um AVR de 8-bits à um ARM de 32-bits. O Arduino
foi escolhido tanto pela vasta gama de acessórios disponíveis quanto pela quantidade de
informação e bibliotecas disponíveis na internet, já que é um projeto de hardware-livre e
código-aberto.
Durante o desenvolvimento do sistema, foram feitos vários testes de desempenho
das bibliotecas implementadas, por isso utilizou-se 3 Arduinos diferentes, o UNO (figura
17), o MEGA (figura 18) e o DUE 19. Pode-se ver um comparativo de algumas características importantes dos 3 Arduinos na tabela 11.
(a) Arduino R3 UNO (Frente)
(b) Arduino R3 UNO (Costas)
Figura 17: Arduino R3 UNO
Fonte: http://www.arduino.cc/
Figura 18: Arduino MEGA 2560
Fonte: http://www.arduino.cc/
Pode-se ver que o Arduino UNO não possui alto poder de processamento, não
só por possuir clock de apenas 16MHz mas principalmente pela memória RAM limitada,
apenas 2kB. Para um programa que envolve grandes matrizes ou faz uso de muitos objetos
Strings isso se torna um grande problema, uma vez que pode-se facilmente chegar a 2048
caracteres.
3.2. Hardware para a fechadura
55
Figura 19: Arduino DUE
Fonte: http://www.arduino.cc/
Tabela 11: Características dos três Arduinos trabalhados
Microcontrolador
Tensão de Operação
Tensão de entrada
Pinos Digitais (I/O)
Pinos Analógico (I)
Memória Flash
SRAM
EEPROM
Frequência de Clock
Arduino UNO
ATmega328
5V
7-12V
14
6
32 KB
2 KB
1 KB
16 MHz
Arduino DUE
AT91SAM3X8E
3.3V
7-12V
54
12
512 KB
96 KB
84 MHz
Arduino MEGA
ATmega2560
5V
7-12V
54
16
256 KB
8 KB
4 KB
16 MHz
3.2.2 O PN532
O PN532 é um modulo de transmissão para comunicação via RF a 13.56MHz. Ele
inclui a funcionalidade de um microcontrolador com núcleo baseado em um 80C51. Ele
pode se comunicar via UART, I2 C ou SPI.
Esse chip foi escolhido por:
∙ Estar facilmente disponível para o Arduino em forma de Shield 1 . O shield
utilizado para o projeto pode ser visto na figura 20.
∙ Ser largamente utilizado. Vários dos celulares com capacidade NFC possuem
um PN532 imbutido.
∙ Ser capaz de realizar comunicação peer-to-peer. Muitos do chips disponíveis
possuem apenas capacidade de ler e gravar tags NFC passívas. (NXP - PHILIPS,
2007)
1
Periféricos feitos especialmente para o Arduino são chamados de Shields
56
Capítulo 3. Metodologia e Implementação
Figura 20: Shield NFC para o Arduino
3.2.3 Primeiro Protótipo
Para montagem do primeiro protótipo, foi utilizado:
∙ Arduino UNO R3, mostrado na figura 17.
∙ Um Shield NFC PN532 para Arduino, mostrado na figura 20.
∙ Um Shield de prototipação para Arduino, mostrado na figura 21.
∙ Um Relay 5V, mostrado na figura 22.
∙ Um sensor magnético (Reed Switch).
∙ Um auto-falante de placa mãe (Buzzer).
A montagem do primeiro protótipo incluía um Reed Switch para leitura do estado
da porta e um buzzer para envio de mensagens de erro ou sucesso. Tais elementos foram
excluídos do projeto na implementação final.
Projetou-se o primeiro protótipo do terminal segundo o esquemático mostrado no
apêndice A, o resultado da montagem pode ser visto na figura 23.
Para o primeiro protótipo utilizou-se um software que fazia a comunicação via
NFC sem utilização de criptografia. Quando foram inclusos testes com criptografia o
arduino UNO se mostrou muito limitado. Por esse motivo buscou-se a utilização de
microcontroladores com maior capacidade como o Arduino DUE e MEGA.
3.2.4 O protótipo Final
Para montagem do protótipo final, algumas mudanças foram requisitadas:
3.2. Hardware para a fechadura
57
Figura 21: Shield de prototipação para Arduino
Figura 22: Relay 5V
Figura 23: Primeiro Protótipo do Terminal
∙ O hardware deve ser conectorizado de forma a ser compatível com o Arduino MEGA,
DUE e UNO (o MEGA é usado preferencialmente, por ser mais barato que o DUE
58
Capítulo 3. Metodologia e Implementação
e ter a quantidade de RAM necessária, além da compatibilidade de software com o
UNO, já que possuem a mesma arquitetura AVR).
∙ Não será utilizado um shield de prototipação com protoboard, os elementos utilizados devem ser soldados a fim de evitar mal contatos.
∙ Não será incluído o Relay na placa de prototipação. Deve-se utilizar um Relay
de estado sólido. Uma segunda plca deverá ser confeccionada para ele quando for
testado com uma fechadura elétrica real.
∙ Não será incluído, por enquanto, o sensor magnético (Reed Switch). Apenas por
motivo de praticidade uma vez que ele não é uma parte importante do sistema.
∙ Em lugar do buzzer para pequenas comunicações ao usuário, deve-se fazer a utilização de dois LEDs acionados através de transistores.
∙ Para cumprir alguns requisitos de segurança do projeto, deverá ser incluso, na placa
confeccionada, um RTC (Real Time Clock).
Seguindo os requisitos propostos para o protótipo final montou-se uma placa de
prototipação com o proposito de conter o RTC, os leds e acoplar facilmente o shield NFC.
Com o intuito de que ele seja facilmente utilizado em qualquer Arduino2 .
A figura 24 mostra a placa confeccionada, o Shield NFC e o Arduino Mega. Mostra
também os cabos confeccionados para fazer a conexão. A figura 25 mostra a placa já
montada e a figura 26 mostra todo o sistema em estado de funcionamento (aguardando a
aproximação de um celular).
3.3 Software para o Arduino
A implementação do software para o Arduino envolveu duas grande etapas. A
primeira delas foi a criação de uma biblioteca que servisse de interface com o PN532
e implementasse a comunicação peer-to-peer. As bibliotecas disponíveis até o momento
apenas faziam leitura e gravação de tags passivas.
A segunda etapa envolveu a implementação da segurança do sistema. Algumas
bibliotecas deveriam ser desenvolvidas para garantir a segurança.
Como não se tinha certeza da eficiência de qualquer algoritmo que pudesse ser
utilizado, ou como se comportariam nos 3 Arduinos, ou durante a transmissão NFC, a
abordagem utilizada para implementação desses softwares foi a prototipação.
2
Os três Arduinos possuem os pinos da SPI em lugares diferentes, o DUE não possui pinos da SPI
ligados aos conectores que são utilizados pelo shield, a placa possibilita a ligação do shield em qualquer
Arduino
3.3. Software para o Arduino
59
Figura 24: Shield NFC, Placa confeccionada, Arduino MEGA e cabos confeccionados
Figura 25: Placa confeccionada montada
Todos os softwares elaborados para o Arduino foi desenvolvido em C++ e foram
utilizadas duas IDE’s. A primeira, foi a IDE do Arduino, mostrada na figura 27. Por ser
uma IDE bem simples, foi utilizada principalmente para fazer compilação e transferência
do código.
Para criação das bibliotecas, foi utilizada uma IDE muito mais completa, com
muito mais recursos. Uma plataforma de código aberto chamada Code::Blocks (figura
28).
60
Capítulo 3. Metodologia e Implementação
Figura 26: Todo sistema em funcionamento
Figura 27: IDE para o Arduino.
3.3.1 Implementação da Biblioteca para comunicação peer-to-peer NFC
Para implementar a comunicação peer-to-peer a biblioteca criada deveria implementar os protocolos LLCP e SNEP, o formato NDEF e a comunicação com o PN532.
Para isso, foram utilizadas a biblioteca já implementada para o PN532 (biblioteca de
código livre desenvolvida pela ADAFRUIT) e a LIBNFC (biblioteca de código livre desenvolvida pelo NFC-Fórum), utilizada como referência para implementação de alguns
tipos.
3.3.1.1 Comunicação com o PN532
A comunicação com o PN532 é feita através da SPI (NXP - PHILIPS, 2007).
Alguns parâmetros de configuração ainda não ficaram muito claro, mesmo lendo a do-
3.3. Software para o Arduino
61
Figura 28: IDE do Code::Blocks
cumentação do PN532 e da configuração esperada pelo Android. Dessa forma, várias
tentativas precisaram ser feitas.
Nas seções subsequentes, pode-se ver os principais comandos do PN532 que foram
utilizados.
Comando InitAsTarget
O comando Init as Target serve para configurar o PN532 como target. Ao enviar
esse comando, o PN532 apenas responde quando recebe um Atribute Request do Initiator.
O comando InitAsTarget tem a sintaxe mostrada na tabela 12.
Tabela 12: Sintaxe do Comando InitAsTarget
D4
8C
Mode (1byte) MifareParams (6 bytes) FeliCaParams (18 bytes)
NFCID3t (10 bytes) LEN Gt Gt Len Tk Tk
A resposta do comando indica parâmetros para as próximas comunicações, principalmente para os protocolos de anticolisão e outros baseados no NFCIP3 (NFC - FORUM,
2013b), que estão fora do contexto deste trabalho.
Para o contexto deste trabalho, o fator mais importante são os parâmetros FeliCa,
já que o Android sempre envia uma requisição para o padrão FeliCa (SONY. . . , 2013) a
424kbps.
Comando GetData
62
Capítulo 3. Metodologia e Implementação
Esse comando possibilita que o controlador (Arduino) receba os dados que foram
recebidos pelo PN532 do Initiator. Ele funciona apenas se o PN532 estiver configurado
em modo de Target.
A sintaxe desse comando pode ser vista na tabela 13. A sintaxe da resposta pode
ser vista na tabela 13.
Tabela 13: Sintaxe para o comando GetData
D4
86
Tabela 14: Sintaxe para a resposta do comando GetData
D5
87
Status
DATA IN
O byte de Status indica se a comunicação foi sucedida ou falha.
Em uma tipica comunicação DEP (Data Exchange Protocol), o Initiator pode
demorar um pouco para enviar os dados. O PN532 envia uma resposta para pedir mais
tempo ao controlador, que deve repetir o comando para receber os dados.
Comando SetData
Esse comando permite que o controlador forneça dados para que o PN532, mais
tarde, os envie para o Initiator. A sintaxe do comando pode ser vista na tabela 15. A
sintaxe para a resposta desse comando é bem simples, apresenta apenas um byte de Status
que deve informar se a informação foi bem sucedida e pode ser vista na tabela 16.
Tabela 15: Sintaxe para o comando SetData
D4
8E
DATA IN
Tabela 16: Sintaxe para a resposta do comando SetData
D5
8F
STATUS
3.3.1.2 LLCP
Foi desenvolvida uma classe para fazer a abstração da camada de enlace de dados
baseando-se no protocolo já comentado na seção 2.1.2.2. Alguns algoritmos utilizados
para algumas funções da classe serão explicados nessa seção.
Pode-se ver, nessa parte do código, que as camadas de rede se misturam. Algumas
das especificações do protocolo SNEP já são atribuídas a abstração da camada de enlace
de dados que foi implementada.
3.3. Software para o Arduino
63
Isso não é um problema uma vez que a aplicação tem interesse apenas em implementar o protocolo SNEP.
Quando o Android deseja enviar uma mensagem (Beam𝑇 𝑀 ), ele faz uma requisição
para se conectar como cliente, caso contrário, como servidor. Dessa forma, nessa classe,
foram elaborados:
∙ O algoritmo 3.1. Com função de fazer conexão como um client SNEP.
∙ O algoritmo 3.2. Com função de fazer conexão como um servidor SNEP.
∙ O algoritmo 3.3. Com função de receber dados do cliente.
∙ O algoritmo 3.4. Com função de enviar dados para o servidor.
Essa abstração da camada de dados também possui função de colocar os SSAP e
DSAP da comunicação nos PDUs necessários, determinar o byte de sequência3 e determinar os parâmetros que devem ser enviados nos bytes de informação em alguns casos.
configuraPN532comoTarget ( ) ;
s e r e s u l t a d o != OK
r e t o r n e ERRO;
recebePDU_PN532 ( ) ;
enviaPDU_PN532 (CONNECT) ;
recebePDU_PN532 ( ) ;
enquanto Tipo_PDU_Recebido = SYMM { // e s p e r a conexao bem s u c e d i d a
enviaPDU_PN532 (SYMM) ;
s e TIME_OUT
r e t o r n e ERRO;
recebePDU_PN532 ( ) ;
}
s e Tipo_PDU_Recebido = CONN_SUCCESS
r e t o r n e OK;
1
3
5
7
9
11
13
Algoritmo 3.1: Algoritmo de Conexão como Cliente SNEP
configuraPN532comoTarget ( ) ;
s e r e s u l t a d o != OK
r e t o r n e ERRO;
recebePDU_PN532 ( ) ;
enviaPDU_PN532 (SYMMM) ;
recebePDU_PN532 ( ) ;
enquanto Tipo_PDU_Recebido != CONN{ // e s p e r a conexao
enviaPDU_PN532 (SYMMM) ;
s e TIME_OUT
2
4
6
8
3
Para essa aplicação, ele nunca será maior que zero, uma vez que apenas uma mensagem é enviada ou
recebida por conexão devido as limitações já discutidas do Android
64
10
12
14
Capítulo 3. Metodologia e Implementação
r e t o r n e ERRO;
recebePDU_PN532 ( ) ;
}
enviaPDU_PN532 (CONN_SUCCESS) ;
r e t o r n e OK;
Algoritmo 3.2: Algoritmo de Conexão como Servidor SNEP
2
4
6
8
recebePDU_PN532 ( ) ;
enquanto Tipo_PDU_recebido != INFORMATION {
s e PDU_recebido != OK
r e t o r n e ERRO;
s e Tipo_PDU_recebido == SYMM
enviaPDU_SYMM_PN53 ;
s e TIME_OUT
r e t o r n a ERRO;
}
10
12
enviaPDU_PN532 (RECEIVE_READY) ; // Envia c o n f i r m a c a o LLCP
PN535_recebe_PDU ( ) ;
14
enviaPDU_PN532 ( I ) ; // e n v i a r e s p o s t a SNEP ( r e c e b i d o c o r r e t a m e n t e )
Algoritmo 3.3: Algoritmo de recepção de dados
2
enviaPDU_PN532 (SYMM) ;
recebePDU_PN532 ( ) ; // e s p e r a −s e um PDU de s i m e t r i a
enviaPDU_PN532 ( I ) ; // e n v i a o s dados para o s e r v i d o r SNEP
4
recebePDU_PN532 ( ) ; // e s p e r a −s e um PDU RECEIVE_READY
6
PN535_enviaPDU (SYMM) ;
8
PN535_recebe_PDU ( ) ; // e s p e r a −s e c o n f i r m a c a o SNEP (PDU t i p o I )
Algoritmo 3.4: Algoritmo de Envio de dados
3.3.1.3 SNEP
Como grande parte do protocolo SNEP já foi implementado, a função dessa abstração é basicamente gerar os cabeçalhos SNEP. Dois algoritmos simples foram implementados para fazer o PUSH (algoritmo 3.5) e o PULL (algoritmo 3.6) implementados
pelo android.
2
LLCP_conectaComoServidor ( ) ;
geraCabecalhoSnep ( ) ;
4
s e LLCP_enviaDados ( ) != OK
3.3. Software para o Arduino
65
r e t o r n a ERRO;
6
r e t o r n a OK;
Algoritmo 3.5: Algoritmo de PUSH
LLCP_conectaComoClient ( ) ;
2
4
s e LLCP_recebeDados ( ) != OK
r e t o r n a ERRO;
6
verificaCabecalhoSNEP ( dados_recebidos ) ;
8
r e t o r n a menssagem_NDEF ; // r e t i r a o c a b e c a l h o SNEP e r e t o r n a
// apenas o NDEF
Algoritmo 3.6: Algoritmo de PULL
3.3.1.4 NDEF
A função dessa abstração do formato NDEF é basicamente gerar os cabeçalhos da
mensagem NDEF, juntar as Gravações NDEF (NDEF Records), colocar corretamente os
tipos de cada gravação NDEF e os bits de começo e fim. Para contexto desse trabalho,
cada mensagem NDEF possui apenas uma gravação NDEF.
3.3.2 Implementação da Criptografia
Para satisfazer os requisitos não funcionais relacionados a segurança do sistema,
foi necessária a implementação de algumas bibliotecas de Segurança para o Arduino.
A primeira tentativa foi de fazer uma biblioteca de chave pública, a RSA. Essa
primeira tentativa foi feita no Arduino UNO, que se mostrou insuficiente para suportar
tal algoritmo. O RSA envolve apenas operações de exponenciação e MOD, porém, com
números muito grandes (pelo menos 1024 bits).
Dessa forma, usou-se apenas o AES, um método de criptografia de blocos com
chave simétrica (FIPS, 2001).
O protocolo de Diffie-Hellman, para gerar uma chave de 16 bytes, também necessitava de operações de exponenciação com números muito grandes e de geração de números
primos imensos, com mais de 300 dígitos (DIFFIE; HELLMAN, 1976). O uso do protocolo
Diffie-Hellman foi substituido, então, por o uso de uma chave de criptografia baseada em
um hash de uma mensagem que deveria ser enviada pelo Arduino e uma senha padrão,
que é usada como forma de autenticação. O funcionamento pode ser visto no diagrama
da figura 29.
66
Capítulo 3. Metodologia e Implementação
Figura 29: Esquema de geração de chave para criptografia
3.3.2.1 Implementação da Biblioteca AES
Foi implementada uma biblioteca para o Arduino para realizar criptografia AES.
Ela tem capacidade para criptografar mensagens no modo CBC e ECB, sem utilização de
padding.
Essa biblioteca foi gerada de acordo com o padrão definido em (FIPS, 2001) padrão
oficial da AES. Um exemplo da utilização da biblioteca pode ser vista no código C do
algoritmo 3.7.
i n c l u d e "DAES. h "
2
d e f i n e KEY_SIZE 16
4
6
byte_t key [ 1 6 ] = { . . . } ;
byte_t i v [ 1 6 ] = { . . . } ;
char * plain_text = " . . . " ;
8
DAES a e s ;
10
// . . .
12
14
16
void i n i t ( ) {
byte_t cryptData [ s t r l e n ( p l a i n _ t e x t ) ] ;
byte_t decryptData [ s t r l e n ( p l a i n _ t e x t ) ] ;
DAES. setKey ( key , KEY_SIZE) ;
DAES. encrypt_ECB ( cryptData , p l a i n _ t e x t , s t r l e n ( p l a i n _ t e x t ) ) ;
18
20
// c a s o modo CBC
DAES. encrypt_CBC ( cryptData , p l a i n _ t e x t , s t r l e n ( p l a i n _ t e x t ) , i v ) ;
22
// D e c r i p t
3.3. Software para o Arduino
67
DAES. decrypt_ECB ( decryptData , cryptData , s t r l e n ( p l a i n _ t e x t ) ) ;
24
DAES. decrypt_CBC ( decryptData , cryptData , s t r l e n ( p l a i n _ t e x t ) , i v ) ;
26
// t o d a s e s s a s f u n c o e s j a c o n s i d e r a m que o tamanho do p l a i n t e x t
// eh um m u l t i p l o de 1 6 , j a que nao e usado nenhum t i p o de padding
28
while (1) ;
30
}
32
34
void loop ( ) {
}
Algoritmo 3.7: Uso da Biblioteca AES
3.3.2.2 Implementação da biblioteca MD5
Foi criada uma biblioteca para geração de um HASH MD5, baseada no RFC1321
(RIVEST et al., 1992). Essa biblioteca é bastante simples e de fácil utilização. Um
exemplo de uso pode ser visto no algoritmo 3.8.
O MD5 foi utilizado pela facilidade de implementação, mas sabe-se de algumas de
suas fragilidades para utilizações que exigem certo nível de segurança. A biblioteca foi
feita para incluir novas formas de HASH e, caso necessário, uma possibilidade é incluir
SHA1 (STANDARD, 1993).
i n c l u d e "DASH. h "
2
4
c h a r * word1 = " . . . " ;
c h a r * word2 = " . . . " ;
char * s a l t = " . . . " ;
6
DASH d i g e s t ;
8
// . . .
10
12
14
16
void i n i t ( ) {
byte_t d i g e s t _ o u t [ 1 6 ] ;
digest . zerate () ;
d i g e s t . update ( word1 , s t r l e n ( word1 ) ) ;
d i g e s t . update ( word2 , s t r l e n ( word2 ) ) ;
d i g e s t . update ( s a l t , s t r l e n ( s a l t ) ) ;
18
d i g e s t . md5( d i g e s t _ o u t ) ;
20
while (1) ;
}
68
Capítulo 3. Metodologia e Implementação
22
24
void loop ( ) {
}
Algoritmo 3.8: Uso da Biblioteca HASH MD5
3.4 Algoritmo do Sistema Completo
loop {
2
esperaCelular () ;
4
envia_mensagem_NFC ( ID , GeradordeSenha ) ;
6
enquanto ! TIME_OUT {
recebe_mensagem_NFC ( ) ;
8
10
}
12
s e TIME_OUT
loop () ;
14
d e c r i p t o g r a f a ( mensagem_recebida ) ;
16
verificaComando ( ) ;
18
se ! verificaAuteticacao ()
loop () ;
20
se ! verificaAutorizacao ()
loop () ;
22
24
executaComando ( ) ;
26
}
Algoritmo 3.9: Algoritmo de Envio de dados
Pode-se ver um algoritmo bem simples apenas com a função de ilustrar o funcionamento do terminal em seu mais alto nível. Pode-se ver que a mensagem recebida passa
por uma fase de decriptografia, uma fase de verificação da autenticação e uma terceira
fase de verificação da autorização.
A fase de verificação de autenticação envolve autenticar o Servidor, o celular, e o
usuário (através de sua senha).
3.5. Protocolo criado para comunicação e autenticação
69
3.5 Protocolo criado para comunicação e autenticação
Para a comunicação entre o sistema, foi criado um protocolo. Esse protocolo
mostra como cada mensagem deve ser enviada, assinada e criptografada. Para uso desse
protocolo na comunicação NFC, foi criado um novo tipo de gravação NDEF, o tipo "D".
O aplicativo e o terminal devem reconhecer o NDEF desse tipo e tratá-lo como
será especificado.
O protocolo consiste em uma autorização do servidor, a senha do usuário e a
assinatura do aplicativo, como mostra a tabela 17.
Tabela 17: Sintaxe do protocolo criado
Autorização do Servidor
(32 bytes)
Senha do usuário
(16 bytes)
Assinatura do aplicativo
(16 bytes)
Para que a autenticação funcione, os seguintes requisitos devem ser cumpridos:
∙ O terminal e o servidor devem compartilhar uma chave de 16 bytes(𝑘𝑆𝑇 ) e uma
palavra para autenticação utilizada como salt de 16 bytes (𝐴𝑢𝑡𝑆𝑎𝑙𝑡𝑆𝑇 ).
∙ O terminal e o celular devem compartilhar uma chave de 16 bytes(𝑘𝐴𝑇 ), uma palavra
para autenticação utilizada como salt de 16 bytes (𝐴𝑢𝑡𝑆𝑎𝑙𝑡𝐴𝑇 ) e um segundo salt
para geração da senha (𝐾𝑒𝑦𝐺𝑒𝑛𝑆𝑎𝑙𝑡𝐴𝑇 ).
3.5.1 Mensagem e assinatura do servidor
A mensagem de autorização do servidor tem a sintaxe mostrada na tabela 18.
Tabela 18: Sintaxe autorização do servidor
Comando
(4 bytes)
ID Terminal
(4 bytes)
ID Aplicativo
(4 bytes)
Data expiração
(4 bytes)
Assinatura do servidor
(16 bytes)
∙ Comando indica qual o comando está sendo autorizado a ser executado.
∙ ID Terminal indica qual terminal esse comando está sendo autorizado a ser executado.
∙ ID Aplicativo indica qual aplicativo (Celular) tem autorização de executar esse
comando.
∙ Data de expiração indica até quando essa autorização é válida.
70
Capítulo 3. Metodologia e Implementação
∙ A assinatura do servidor consiste em uma criptografia AES com a chave 𝑘𝑆𝑇 de
um hash MD5 de todos os primeiros 16 bytesda mensagem de autorização mais o
𝐴𝑢𝑡𝑆𝑎𝑙𝑡𝑆𝑇 para melhorar a segurança.
AssinServer = 𝐸𝑘𝐴𝐸𝑆
(MD5(Cmd||IDTerm||IDApp||DTExp||AutSalt𝑆𝑇 ))
𝑆𝑇
Onde || indica concatenação.
3.5.2 Assinatura do Aplicativo
A assinatura do celular consiste em uma criptografia AES com a chave 𝑘𝐴𝑇 de um
hash MD5 da autorização do servidor mais a senha do usuário mais um salt 𝐴𝑢𝑡𝑆𝑎𝑙𝑡𝐴𝑇 .
AssinApp = 𝐸𝑘𝐴𝐸𝑆
(MD5(AssinServer||UserPass||AutSalt𝐴𝑇 ))
𝐴𝑇
3.6 Aplicativo para Android
Foi desenvolvido um aplicativo para o Sistema Operacional Android. O desenvolvimento foi feito com utilização da IDE Eclipse, que é recomendada para o Android
e pode ser vista na figura 30. A linguagem de programação utilizada foi o JAVA. Não
se precisou de nenhuma biblioteca externa para o desenvolvimento do software, usou-se
apenas as bibliotecas já inclusas no Android 4.0.
Figura 30: IDE Eclipse para programação em Android.
O aplicativo foi feito de forma bem simples, a pessoa deve escrever a senha em seu
celular, aproximar seu celular da antena e quando for requisitada, tocar na tela.
3.6. Aplicativo para Android
71
O aplicativo, além de ter função de fazer comunicação via NFC, deve também se
comunicar com a WEB para buscar sua autenticação com o Servidor.
3.6.1 Envio de uma mensagem NDEF com o Beam𝑇 𝑀
A utilização do Beam𝑇 𝑀 para envio de uma mensagem NDEF é feita implementandose as interfaces CreateNdefMessageCallback e OnNdefPushCompleteCallback. Um exemplo pode ser visto no algoritmo 3.10.
1
3
5
7
p u b l i c c l a s s P a s s A c t i v i t y e x t e n d s A c t i v i t y implements
CreateNdefMessageCallback , OnNdefPushCompleteCallback {
@Override
p u b l i c NdefMessage c r e a t e N d e f M e s s a g e ( NfcEvent e v e n t ) {
Log . d (TAG, " Push S t a r t " ) ;
byte [ ] s e r v e r = NFCLockerCrypt . hexStringToByteArray ( c f a . g e t A u t o r i z a t i o n
() ) ;
byte [ ] password = g e t I n t e n t ( ) . g e t S t r i n g E x t r a ( BeamActivity .
INTENT_TAG_PASS) . g e t B y t e s ( C h a r s e t . forName ( "US−ASCII " ) ) ;
ByteArrayOutputStream payload = new ByteArrayOutputStream ( ) ;
9
try {
payload . w r i t e ( s e r v e r ) ;
i f ( password . l e n g t h < 1 6 ) {
f o r ( i n t i = 0 ; i < 16 − password . l e n g t h ; i ++)
payload . w r i t e ( ( byte ) 0 ) ;
}
payload . w r i t e ( password ) ;
payload . w r i t e ( NFCLockerCrypt . md5( payload . toByteArray ( ) ) ) ;
} c a t c h ( IOException e ) {
e . printStackTrace () ;
}
11
13
15
17
19
21
NdefMessage msg = new NdefMessage (
new NdefRecord [ ] { new NdefRecord (
NdefRecord .TNF_EXTERNAL_TYPE ,
" mobi . a2d :D" . g e t B y t e s ( C h a r s e t . forName ( "US−ASCII " ) ) ,
new byte [ 0 ] , NFCLockerCrypt . a e s E n c r y p t ( payload .
toByteArray ( ) , key , i v ) )
}) ;
hand . p o s t D e l a y e d ( f i n i s h T h i s , DELAY) ;
r e t u r n msg ;
23
25
27
29
}
31
33
@Override
p u b l i c v o i d onNdefPushComplete ( NfcEvent e v e n t ) {
Log . d (TAG, "NDEF PUSH Completo " ) ;
72
Capítulo 3. Metodologia e Implementação
this . finish () ;
35
}
37
}
Algoritmo 3.10: Algoritmo Para uso do Beam𝑇 𝑀 no Android
Sobrescreveu-se dois métodos das interfaces que foram utilizadas. O método createNdefMessage, implementado na linha 4 é utilizado para geração da mensagem MDEF
nos padrões já mencionados. Pode-se ver que é especificado o tipo de gravação NDEF na
linha 25.
Na linha 28 pode-se ver a implementação de um timeout. A atividade deve ser
fechada caso fique aberta por muito tempo sem conseguir enviar uma mensagem NFC.
Para que esses métodos sejam chamados corretamente, deve-se utilizar a classe
NfcAdapter, que faz interface com o chip NFC presente no celular.
5
// . . .
NfcAdapter n f c A d a p t e r ;
@Override
p r o t e c t e d v o i d onCreate ( Bundle s a v e d I n s t a n c e S t a t e ) {
// . . .
7
n f c A d a p t e r = NfcAdapter . g e t D e f a u l t A d a p t e r ( t h i s ) ;
9
n f c A d a p t e r . setOnNdefPushCompleteCallback ( t h i s , t h i s ) ;
1
3
11
nfcAdapter . setNdefPushMessageCallback ( t h i s , t h i s ) ;
13
// . . .
}
Algoritmo 3.11: Segundo algoritmo Para uso do Beam𝑇 𝑀 no Android
3.6.2 Recebimento de uma mensagem NDEF
Para recebimento de uma mensagem NDEF, usa-se o Android Dispatch System.
Como não é permitido a utilização do chip NFC a baixo nível, faz-se um pedido ao sistema
operacional que dispare um intent 4 .
Quando esse intent é disparado, filtra-se para saber se é um tipo que a aplicação
deve utilizar. O código
// . . .
1
4
Classe do Android que consiste em uma descrição abstrata de uma operação que deve ser executada
ou de um evento acontecido
3.6. Aplicativo para Android
7
NfcAdapter n f c A d a p t e r ;
IntentFilter [ ] intentFiltersArray ;
String [ ] [ ] techListsArray ;
PendingIntent pendingIntent ;
// . . .
n f c A d a p t e r = NfcAdapter . g e t D e f a u l t A d a p t e r ( t h i s ) ;
9
nfcAdapter . setNdefPushMessageCallback ( null , t h i s ) ;
3
5
11
73
pendingIntent = PendingIntent . getActivity (
t h i s , 0 , new I n t e n t ( t h i s , g e t C l a s s ( ) ) . addFlags ( I n t e n t .
FLAG_ACTIVITY_SINGLE_TOP) , 0 ) ;
13
15
17
19
21
I n t e n t F i l t e r n d e f = new I n t e n t F i l t e r ( NfcAdapter .
ACTION_TAG_DISCOVERED) ;
try {
n d e f . addDataType ( " e x t " ) ;
n d e f . addDataAthority ( " mobi . a2d " ) ;
}
c a t c h ( MalformedMimeTypeException e ) {
throw new RuntimeException ( " f a l h a " , e ) ;
}
i n t e n t F i l t e r s A r r a y = new I n t e n t F i l t e r [ ] { ndef , } ;
23
25
t e c h L i s t s A r r a y = new S t r i n g [ ] [ ] { new S t r i n g [ ] { NfcF . c l a s s . getName
( ) } , new S t r i n g [ ] { NdefFormatable . c l a s s . getName ( ) } } ;
27
nfcAdapter . enableForegroundDispatch ( t h i s , pendingIntent ,
intentFiltersArray , techListsArray ) ;
Algoritmo 3.12: Recebimento de mensagens NDEF com Android
3.6.3 Comunicação com o Servidor
Para comunicação com o servidor, utiliza-se um segundo thread em background.
A cada vez que uma autorização é baixada, verifica-se o tempo de validade da mesma.
Uma autorização é considerada como "antiga"assim que se chega a 20% de seu prazo de
expiração. Nesse momento, o aplicativo tentará buscar uma nova autorização a cada 10
minutos se houver conexão disponível.
O aplicativo também tenta atualizar as autorizações sempre que a aplicação for
aberta.
O algoritmo 3.13 mostra como é feita a conexão com o servidor em backgorund.
c l a s s A u t o r i z a t i o n s T a s k e x t e n d s AsyncTask<Void , Void , S t r i n g > {
74
2
4
6
8
10
12
14
16
18
20
Capítulo 3. Metodologia e Implementação
// . . .
@Override
p r o t e c t e d S t r i n g doInBackground ( Void . . . params ) {
try {
URL u r l = new URL(URL_GET_AUTORIZATION) ;
HttpURLConnection conn = ( HttpURLConnection ) u r l
. openConnection ( ) ;
conn . setDoOutput ( t r u e ) ;
conn . setRequestMethod ( "POST" ) ;
S t r i n g postParams = " I d C e l l="
+ URLEncoder . encode ( i d _ c e l l , "UTF−8" ) + "&I d L o c k e r="
+ URLEncoder . encode ( id_lock , "UTF−8" ) ;
Log . d (TAG, postParams ) ;
conn . setFixedLengthStreamingMode ( postParams . g e t B y t e s ( ) . l e n g t h ) ;
conn . s e t R e q u e s t P r o p e r t y ( " Content−Type " ,
" a p p l i c a t i o n /x−www−form−u r l e n c o d e d " ) ;
conn . s e t R e q u e s t P r o p e r t y ( " Accept−C h a r s e t " , "UTF−8" ) ;
conn . s e t R e q u e s t P r o p e r t y ( " Content−Length " ,
S t r i n g . v a l u e O f ( postParams . g e t B y t e s ( ) . l e n g t h ) ) ;
conn . setFixedLengthStreamingMode ( postParams . g e t B y t e s ( ) . l e n g t h ) ;
22
OutputStream out = conn . getOutputStream ( ) ;
out . w r i t e ( postParams . g e t B y t e s ( "UTF−8" ) ) ;
out . f l u s h ( ) ;
out . c l o s e ( ) ;
conn . c o n n e c t ( ) ;
InputStream i s = conn . g e t I n p u t S t r e a m ( ) ;
String resposta = " " ;
Scanner inStream = new Scanner ( conn . g e t I n p u t S t r e a m ( ) ) ;
w h i l e ( inStream . hasNextLine ( ) )
r e s p o s t a += inStream . n e x t L i n e ( ) + " \n " ;
Log . d (TAG, r e s p o s t a ) ;
conn . d i s c o n n e c t ( ) ;
return resposta ;
} catch ( Exception e ) {
Log . d (TAG, e . t o S t r i n g ( ) ) ;
return null ;
}
24
26
28
30
32
34
36
38
40
}
42
p r o t e c t e d v o i d onPostExecute ( S t r i n g param ) {
i f ( param . s t a r t s W i t h ( "OK" ) ) {
S t r i n g [ ] r e s p = param . s p l i t ( " \n " ) ;
setAut ( r e s p [ 1 ] ) ;
Log . d (TAG, " PostEx aut : "+r e s p [ 1 ] ) ;
Log . d (TAG, " PostEx aut : "+g e t A u t o r i z a t i o n ( ) ) ;
}
44
46
48
3.7. Aplicativo web
}
50
52
75
}
Algoritmo 3.13: Recebimento de mensagens NDEF com Android
3.7 Aplicativo web
O aplicativo web foi escrito em PHP (WELLING; THOMSON, 2003) e HTML e,
em sua maior parte, consiste em um Banco de Dados MySQL(WELLING; THOMSON,
2003) implementado utilizando-se a linguagem SQL.
A interface é feita de forma bem simples e pode ser acessada facilmente pelo
browser por qualquer um que tiver uma senha de administrador.
A IDE utilizada foi o NETBeans, que pode ser vista na figura 31.
Figura 31: IDE - NETBeans
3.7.1 Banco de Dados
O banco de dados do servidor deve gravar os dados dos usuários e de cada fechadura, para isso foram necessárias a criação de 4 tabelas, uma para as fechaduras, outra
para os administradores, uma terceira para usuários e uma quarta tabela para guardar
relacionamentos. A figura 32 mostra o diagrama Entidade Relacionamento do banco de
dados.
76
Capítulo 3. Metodologia e Implementação
Figura 32: Diagrama Entidade-Relacionamento
3.7.2 A interface
O site que implementa a interface WEB foi hospedado em http://a2d.mobi/5 .
E pode ser acessado diretamente pelo endereço http://a2d.mobi/AppNfc/. A primeira
tela, é a tela de Login, como mostrada na figura 33.
Após autenticação do usuário através de seu login e senha, na segunda tela ele pode
gerenciar todas as suas fechaduras cadastradas (figura 34). Clicando em "Ver Usuários",
o administrador pode modificar o status de cada usuário individualmente (figura 35).
Figura 33: Primeira tela do aplicativo WEB
Figura 34: Administração das Fechaduras
5
A2d é empresa que seria criada como responsável pela implementação e instalação do sistema.
3.7. Aplicativo web
77
Figura 35: Modificar Status de usuários
79
4 Resultados e Testes
Neste capitulo se discorrerá sobre os resultados, testando-se a comunicação NFC,
a velocidade e eficiência da criptografia, a comunicação com a internet.
A primeira seção mostra todos os protocolos já vistos anteriormente funcionando
corretamente. As próximas mostram testes de qualidade do software, mostrando as velocidades de execução das operações realizadas pelo sistema.
4.1 Comunicação NFC
Para demonstração do funcionamento da comunicação NFC, foi feito, em um uso
típico, utilizando a serial do computador, um log de todos os dados que se passam pela
comunicação SPI entre o Arduino e o PN532. Dessa forma será possível ver todos os
protocolos sendo utilizados.
Não será comentado sobre todo o log, apenas sobre as partes importantes para
este trabalho.
A primeira mensagem que se pode ver, é:
envio: 0 0
resposta: 0 FF
FF 5
2 FE
FB
D5
D4
15
14
1
14
1
0x2
0x0
Ela apenas envolve configuração do SAM (Security Access Manager), sua sintaxe
pode ser vista na seção sobre o PN532.
Logo depois:
envio:
resposta:
0
40
0
89
0
1D
6D
0 FF
1 FE
0
0
0
0
FF 21
5E 12
1
1
2D D3
F BB
0
FF
6
46
DF D5
68 EF
11
3
D4
BA
FF
66
8D
1E
2
8C 0
A6 C9
1 FE
6D 1
25 1E
C1 0
0
13
0
89
F
1
D4
0
4
0
0
BB
10
0
0
1
0
0
0
0
BA A6
0 0x3B
18
1E
32
46
96
0
0
C9
0x0
12
66
Esse comando, mostra o InitAsTarget. A resposta só é recebida quando o Initiator
está próximo.
80
Capítulo 4. Resultados e Testes
Esses primeiros comandos não envolvem os protocolos de comunicação NFC de
forma direta, apenas configurações essenciais para que o PN532 se comunique corretamente.
No terceiro log pode-se ver:
envio 0 0 FF 2
resposta 0 FF 5 FB
FE
D5
D4
87
86
0
0xA6
0
0x0
0
Agora pode-se ver um comando GetData. A resposta mostrada é um PDU do tipo SYMM.
O PN532 está se comunicando corretamente com o initiator.
Alguns logs adiante, pode-se ver o PDU do tipo Connect:
envio: 0 0 FF 4
resposta: 0 FF 3 FD
FC
D5
D4
8F
8E
0
11
20
0x6D
0x0
Pode-se ver o envio da mensagem NFC finalmente em:
envio:
resposta:
0 0
0 0
0 FF
FF
8
3
13 ED
D1
1
FD D5
D4
4
8F
8E
44
0
13
0
20 0
0 0
preambulo PN532:
0
0
Tamanho e CS do tamanho:
13
ED
Comando para o PN532:
D4
8E
10
2
1 0x36
0
0x0
Nessa mensagem pode-se distinguir:
FF
Agora pode-se ver no PDU
DSAP, Tipo PDU e SSAP:
13
Byte de sequencia
0
20
Pode-se ver que: DSAP = 000100b, Tipo = 1100b (I), SSAP = 100000b
Então tem-se o cabeçalho do SNEP:
Versão e request:
10
2 (PUT)
Bytes de tamanho
0
0
Agora tem-se o cabeçalho NDEF
0
8
4.1. Comunicação NFC
81
Flag, tamanho do tipo
D1
Tamanho do payload
4
Tipo
44
1
Então pode-se ver, finalmente, a carga útil da mensagem, que nesse caso é apenas
o ID do terminal (0x00000001).
Depois da mensagem enviada, pode ser visto o PDU tipo DISCONNECT.
Envia: 0 0 FF 4
Resposta: 0 FF 3 FD
FC
D5
D4
8F
8E
25
11
60
0x2D
0x0
Agora o objetivo é conectar para receber uma mensagem NDEF, dessa forma o
terminal deve ser iniciado como servidor, o Android deve pedir a conexão. Isso pode ser
visto em um comando getData mais adiante.
Envia: 0 0 FF 2
Resposta: 0 FF 5 FB
FE
D5
D4
87
86
0
0xA6
11
0x0
20
Pode-se ver o PDU tipo Connect sendo recebido e logo depois a mensagem NDEF
sendo recebida:
Envia:
Resposta:
00
00
00
6F
DE
AE
6F
DC
00 FF 02
FF 50 B0
00 00 44
01 B0 9F
D9 B6 09
51 AE 31
39 36 E4
14 2E 4C
FE D4 86
D5 87 00
D1 01 40
20 2D 60
72 6F 8C
BD C8 2F
7E A9 D3
1A F0 66
A6 00
13 20
44 B5
48 94
7A DC
D6 F3
EF A9
EF 2B
00 10 02
ED CB E0
AF 1B A6
64 08 18
0B AC 5F
26 15 2B
F0 25 06
Na resposta do comando getData pode-se ver o PDU após os bytes de preâmbulo,
tamanho, checksum do tamanho e comando. Então percebe-se:
O cabeçalho do PDU:
DSAP, Tipo PDU e SSAP:
13
Byte de sequencia
0
20
O cabeçalho do SNEP:
Versão e request:
10
2 (PUT)
Bytes de tamanho
0
0
0
44
82
Capítulo 4. Resultados e Testes
O cabeçalho do NDEF:
Flag, tamanho do tipo
D1
Tamanho do payload
40
Tipo
44
1
e finalmente a carga útil:
B5 ED CB E0 6F 01 B0 9F 20 2D 60 48 94 AF 1B A6 DE D9 B6 09 72 6F 8C 7A DC 64
08 18 AE 51 AE 31 BD C8 2F D6 F3 0B AC 5F 6F 39 36 E4 7E A9 D3 EF A9 26 15 2B
DC 14 2E 4C 1A F0 66 EF 2B F0 25 06
que após ser descriptografada é:
00 00 00 01 00 00 00 01 00 00 00 01 52 65 92 17 FD 20 4F 21 10 A0 22 3A 7E 12 5B 30
92 14 FA 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 99 47 FA 7C 97 C3 0A 1D
84 84 EE F5 53 51 7A AE
pode-se ver, então, o protocolo criado:
Comando
0
0
0
Id do Terminal
1
0
0
0
1
Id do Aplicativo
0
0
Expiração
0
1
52
65
92
17
12
5B
30
92
14
FA
7
0
0
0
0
0
0
0
EE
F5
53
51
7A
AE
Assinatura do servidor
FD
20
4F
21
10
A0
22
3A
7E
Senha
0
0
0
0
0
0
0
0
0
Assinatura do celular
99
47
FA
7C
97
C3
0A
1D
84
84
4.2 Testes da comunicação NFC
Para teste da velocidade de comunicação via NFC, implementou-se uma rotina no
Android para calcular o tempo que cada parte da comunicação levava. Não foi feito um
teste criterioso com muitas medições e métodos estatísticos, apenas coletou-se a timestamp
de cada evento, calculou-se a diferença e tirou-se uma média. O resultado dessas medidas
podem ser vistas na tabela 19.
Todos esses testes foram feitos com utilização do Arduino MEGA. O celular utilizado foi o Sansung Galaxy SIII rodando o sistema operacional Android Jelly Beam v4.1.2.
Deve-se definir:
4.2. Testes da comunicação NFC
83
Tabela 19: Testes de comunicação NFC
N
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Média Total
Evento 1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Evento 2
36
4
3
3
4
3
3
2
3
3
2
2
2
2
3
5,0
Evento 3
164
93
73
200
89
79
76
85
84
82
73
69
118
78
87
96,7
Evento 4 Evento 5 Evento 6
1239
1248
2256
5073
5074
6095
5222
5223
6215
5747
5747
6745
5755
5756
6637
6183
6183
7040
1971
1972
2964
5107
5107
6084
3793
3794
4576
3821
3822
4190
1943
1943
2757
4856
4857
5786
4229
4229
5055
6553
6553
7500
3789
3789
4596
4352,0
4353,1
5233,1
*Valores em ms (mili segundos)
∙ Evento 1: Mensagem NDEF Recebida do terminal. Esse é o referencial utilizado,
considerado o tempo zero.
∙ Evento 2: Mensagem decodificada e chaves geradas. Após esse evento, as chaves
que devem ser utilizadas para criptografia já foram geradas.
∙ Evento 3: Atividade de Envio Iniciada. O tempo para isso acontecer pode variar
de acordo com a quantidade de memória disponível no celular.
∙ Evento 4: Preparado para envio. O Android já recebeu requisição do Servidor
SNEP para envio da mensagem e o usuário já autorizou com um toque na tela.
∙ Evento 5: Mensagem criptografada e codificada. Em geral os processos de criptografia acontecem de forma bem rápida no Android, principalmente para um método
rápido como o AES.
∙ Evento 6: Mensagem enviada. Foi recebida confirmação do Servidor SNEP que os
dados foram enviados corretamente.
Pode-se perceber que em nenhum dos 15 testes houve falha na comunicação, o que
indica estabilidade do sistema. Apesar disso, foram detectadas algumas falhas em outros
testes feitos e não documentados. Dessa forma, é sabido que o sistema pode apresentar
instabilidades eventuais em algumas situações, o motivo destas ainda é desconhecido.
Vê-se que o evento mais custoso em todo o processo é o 4. Isso se deve ao fato de
que entre os eventos 1 e 4, o Arduino deve requisitar desconexão como cliente SNEP (o
84
Capítulo 4. Resultados e Testes
Figura 36: Histograma dos dados da tabela 19
Android funciona como Servidor nessa fase) e requisitar conexão novamente, mas dessa vez
como Servidor (após o evento 3, o Android deve funcionar como cliente SNEP). Apesar do
baixo número de amostras, o histograma apresentado na figura 36 mostra a alta variação
no tempo de comunicação.
4.3 Comunicação com o servidor
Repetiu-se o mesmo processo de gerar timestamps para se fazer testes em relação
conexão com a internet. Dessa vez agendou-se uma grande quantidade de conexões com
o objetivo de testar as velocidades de conexão utilizando WiFi e Dados móveis. Os
resultados medidos podem ser vistos na tabela 20.
Para esse teste também foi utilizado o celular Sansung Galaxy SIII rodando o
sistema operacional Android Jelly Beam v4.1.2.
Tabela 20: Média de tempo de comunicação com o aplicativo WEB
Conexão
WiFi
Dados móveis
N
103
82
Evento 1
0
0
Evento 2
1
1
Evento 3 Evento 4 Evento 5
428
511
527
3296
3545
3553
*Valores em ms (mili segundos)
∙ Evento 1: Inicio da tentativa de conexão. Esse é o referencial utilizado, considerado
o tempo zero.
4.3. Comunicação com o servidor
85
∙ Evento 2: Parâmetros prontos para serem enviados. O request HTTP foi criado
com todas as variáveis que devem ser enviadas em POST.
∙ Evento 3: Conexão estabelecida. O servidor já respondeu com as informações
desejadas.
∙ Evento 4: Desconectado. O socket de conexão foi finalizado.
∙ Evento 5: Dados gravados. Os dados recebidos foram descriptografados e guardados no banco de dados do celular,
Vemos uma grande diferença no tempo de conexão para os diferentes tipos. O
teste mostra que pode ser utilizado o modelo alternativo de sempre buscar uma nova
autenticação no servidor quando o dispositivo detectar proximidade com a fechadura. O
tempo médio para uma conexão, mesmo da forma mais lenta, ainda é menor que o tempo
desde a detecção da fechadura até o momento que os dados são codificados para enviar.
Como nem sempre uma conexão está disponível, utiliza-se um modelo em que a
validade de uma autorização é maior que 1 dia.
87
5 Conclusão
Neste trabalho fez-se uso da tecnologia NFC para comunicação entre um celular
e uma plataforma para controle de acesso (fechadura elétrica). O objetivo foi a criação de uma ferramenta de controle de acesso intuitiva e de fácil instalação e utilização,
demonstrando a tecnologia e como ela pode ser usada em dispositivos de segurança.
Para confecção dessa ferramenta, fez-se uso de um periférico baseado no chip NFC
PN532, que foi testado em três plataformas diferentes, todas baseadas na plataforma
de prototipagem Arduino. Para que isso fosse viável, implementou-se uma biblioteca
de aplicação dos protocolos NFC conhecidos e já utilizados pelos smartphones com essa
tecnologia.
Além disso, criou-se bibliotecas de criptografia e segurança para o Arduino, que
até então não estavam disponíveis, elaborou-se um aplicativo para o sistema operacional Android e produziu-se um aplicativo Web para ser utilizado para administração de
diferentes fechaduras.
Na elaboração da solução técnica para o projeto, duas grandes dificuldades foram
encontradas.
A primeira delas interfere nos requisitos funcionais do sistema e envolve a elaboração do software para comunicação NFC entre o celular e o Arduino.
Um grande número de parâmetros deve ser utilizado para definir como será a comunicação. A frequência de modulação, a velocidade de transmissão de dados e os tipos
de protocolos de baixo nível são exemplos disso. Foram utilizados os códigos fontes do sistema operacional Android além dos documentos técnicos para que todos esses parâmetros
pudessem ser determinados de forma correta.
A implementação dos protocolos de mais alto nível foi possível graças a grande
quantidade de informação disponível na internet e a documentação bem detalhada de
cada um deles presente no Fórum NFC.
A segunda grande dificuldade envolveu um requisito não funcional muito importante para o sistema: a criptografia. A maioria dos protocolos de autenticação utiliza
criptografia com chave pública e privada para geração de assinaturas, isso não foi possível
em função da complexidade do algoritmo implementado e a capacidade de processamento
e memória RAM do hardware utilizado (Arduíno).
Apesar de todas as dificuldades, conseguiu-se atender os requisitos do sistema
para a finalidade do trabalho. O NFC se mostrou uma maneira prática e intuitiva para o
projeto proposto.
88
Capítulo 5. Conclusão
Os testes que se referem a comunicação NFC mostram algumas falhas e perda de
sincronia. Elas se devem ao modo como as bibliotecas que implementam essa tecnologia
no Android funcionam, uma vez que foram feitas apenas para comunicação de uma via
entre dois celulares.
A segurança do sistema foi elaborada baseada em ferramentas criptográficas já
existentes e comprovadamente eficazes, uma vez que é conhecido o perigo em se criar
algoritmos próprios para essa finalidade.
Apesar dos protocolos de segurança serem bem definidos e atenderem aos requisitos, o sistema falha quanto ao modelo de armazenamento das chaves de segurança. Caso
um invasor consiga fazer um acesso direto a EEPROM do arduino, ele poderá facilmente
encontrar as senhas.
Aplicar engenharia reversa no código executável também pode se apresentar extremamente eficiente para descoberta de chaves de segurança do sistema.
Caso o trabalho seja continuado, algumas sugestões para melhoria do sistema,
podem ser:
∙ Utilização do Android no modo emulação de cartão. Essa aplicabilidade
ainda não é disponível mas deve estar presente como funcionalidade adicional nas
próximas atualizações da API.
∙ Utilização de métodos de HASH mais seguros que o MD5. Apesar de
ter sido considerado seguro para o contexto deste trabalho, alguns métodos, como
SHA1 (STANDARD, 1993), possuem uma resistência a colisão comprovadamente
muito maior que o utilizado.
∙ Implementação de criptografia assimétrica apenas para autenticação. Para
essa aplicação a autenticação é mais importante que o próprio sigilo. A implementação de uma biblioteca RSA para finalidade especifica de verificação da assinatura
é bem mais simples que a que tentou-se desenvolver, uma vez que envolvia geração
de chaves públicas e privadas.
∙ Reimplementação do método de gravação das chaves na EEPROM. As
chaves se tornam facilmente identificadas na EEPROM devido a sua aleatoriedade.
A ATMEL desenvolveu uma cryptomemory, uma EEPROM com a única finalidade
de gravar chaves, que pode ser utilizada adicionalmente. Poderia-se também adicionar uma segunda criptografia para gravação dos dados, como por exemplo.
∙ Implementação da segurança do meio físico. Definir como os módulos do
hardware devem ser posicionados para garantir a segurança. Caso uma pequena
89
parte do fio que aciona a fechadura fique aparente, toda a segurança dos sistema é
comprometida.
91
Referências
ANDROID Developers. 2013. Disponível em: http://developer.android.com. Acesso
em: outubro de 2013. Citado 2 vezes nas páginas 39 e 40.
BELLARE, M.; KILIAN, J.; ROGAWAY, P. The security of the cipher block chaining
message authentication code. Journal of Computer and System Sciences, Elsevier, v. 61,
n. 3, p. 362–399, 2000. Citado 2 vezes nas páginas 47 e 49.
DEVELOPER Economics Q3 2013 analyst report. 2013. Disponível em: http:
//www.visionmobile.com/DevEcon3Q13. Acesso em: outubro de 2013. Citado na
página 39.
DIFFIE, W.; HELLMAN, M. New directions in cryptography. Information Theory,
IEEE Transactions on, IEEE, v. 22, n. 6, p. 644–654, 1976. Citado 2 vezes nas páginas
44 e 65.
FIPS, P. 197, advanced encryption standard (aes). National Institute of Standards and
Technology, 2001. Citado 3 vezes nas páginas 52, 65 e 66.
GOOGLE Wallet. 2013. Disponível em: http://www.google.com/wallet/. Acesso em:
outubro de 2013. Citado na página 25.
HASELSTEINER, E.; BREITFUSS, K. Security in near field communication (nfc). In:
Workshop on RFID Security RFIDSec. [S.l.: s.n.], 2006. Citado na página 29.
IDC - World Wide Mobile Phone Tracker. 2013. Disponível em: http://www.idc.com/
getdoc.jsp?containerId=prUS24257413. Acesso em: outubro de 2013. Citado na
página 39.
KUMAR, A. Near field communication. 2011. Citado 2 vezes nas páginas 26 e 29.
MAJOR Samsung Visa partnership announced at the MWC 2013.
2013. Disponível em: http://investincotedazur.com/en/newsletter/
nfc-major-samsung-visa-partnership-announced-at-the-mwc-2013&artid=
act11035. Acesso em: outubro de 2013. Citado na página 29.
NFC - FORUM. NFC Data Exchange Format (NDEF) Technical Specification. 2006.
Também disponível em: http://www.nfc-forum.org/specs/spec_license/document_
form/custom_layout?1383275628106. Acesso em: outubro de 2013. Citado na página
38.
NFC - FORUM. Logical Link Control Protocol Technical Specification. 2011. Disponível
em: http://www.nfc-forum.org/specs/spec_license/document_form/custom_
layout?1382382479760. Acesso em: outubro de 2013. Citado na página 32.
NFC - FORUM. NFC - Forum. 2013. Disponível em: http://www.nfc-forum.org/.
Acesso em: outubro de 2013. Citado na página 29.
92
Referências
NFC - FORUM. NFC Digital Protocol Technical Specification. 2013. Disponível em:
http://www.nfc-forum.org/specs/spec_license/document_form/custom_layout?
1383288838060. Acesso em: outubro de 2013. Citado 3 vezes nas páginas 31, 32 e 61.
NFC - FORUM. Simple NDEF Exchange Protocol Technical Specication. 2013. Disponível
em: http://www.nfc-forum.org/specs/spec_license/document_form/custom_
layout?1383260113926. Acesso em: outubro de 2013. Citado na página 35.
NXP - PHILIPS. UM0701-02 PN532 - User Manual. [S.l.], 2007. V1.6. Citado 2 vezes
nas páginas 55 e 60.
RIVEST, A. S. R.; ADLEMAN, L. A method for obtaining digital signatures and
public-key cryptosystems. Communications of the ACM, v. 21, p. 120–126, 1978. Citado
2 vezes nas páginas 46 e 47.
RIVEST, R. L. et al. RFC 1321: The MD5 message-digest algorithm. [S.l.]: April, 1992.
Citado 2 vezes nas páginas 48 e 67.
SCHNEIER, B. Applied Criptography. New York: John Wiley, 1996. Citado 2 vezes nas
páginas 41 e 42.
SONY Products - FeliCa. 2013. Disponível em: http://www.sony.net/Products/
felica/. Acesso em: outubro de 2013. Citado na página 61.
STANDARD, S. H. Federal information processing standard publication# 180. US
Department of Commerce, National Institute of Standards and Technology, v. 56, p.
57–71, 1993. Citado 3 vezes nas páginas 48, 67 e 88.
TANENBAUM, A. S. Redes de Computadores. Rio de Janeiro: Editora Campus, 1997.
Citado 6 vezes nas páginas 42, 43, 44, 47, 48 e 49.
WELLING, L.; THOMSON, L. PHP and MySQL Web development. [S.l.]: Sams
Publishing, 2003. Citado na página 75.
Apêndices
95
APÊNDICE A – Esquemático do Primeiro
Protótipo do Terminal
97
APÊNDICE B – Esquemático do Protótipo
Final do Terminal