Proposta para controle de acesso físico seguro baseada em ...€¦ · baseada em Near Field...

Danilo Souza Lima

Proposta para controle de acesso físico segurobaseada em Near Field Communication (NFC)

e Android

São Carlos2013

Danilo Souza Lima

Proposta para controle de acesso físico seguro baseadaem Near Field Communication (NFC) e Android

Trabalho de Conclusão de Curso apresentadoao departamento de Engenharia elétrica daEscola 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 Carlos2013

AUTORIZO A REPRODUÇÃO TOTAL OU PARCIAL DESTE TRABALHO,POR QUALQUER MEIO CONVENCIONAL OU ELETRÔNICO, PARA FINSDE ESTUDO E PESQUISA, DESDE QUE CITADA A FONTE.

Lima, Danilo Souza L732p 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ãoCarlos 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çãode dispositivo móvel com NFC"

Trabalho de Conclusão de Curso defendido e aprovadoem 21 I_li 120.1d,

com NOTA Q3 C--~Ullte, -fcts 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 tryingto 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 paracontrole 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 Com-munication, que é uma comunicação via rádio-frequência com área de ação limitadaem no máximo 10cm. O objetivo final do projeto foi propor um método completopara elaboração do sistema de controle de acesso, que deve servir como prova deconceito e não como um produto comercial. Ele envolve a elaboração de um terminalde acesso baseado em Arduino com Shield NFC além da criação de um aplicativomóvel para Android e um website para gerenciamento. As principais dificuldadesdo projeto foram a implementação dos protocolos de comunicação peer-to-peer NFCem baixo nível e a implementação da segurança do sistema baseada em algoritmosde criptografia. Foram utilizadas as linguagens de programação C++, JAVA e PHPe os softwares envolvidos foram elaborados utilizando o modelo de prototipagem. Otrabalho foi testado utilizando-se um celular Galaxy SIII da Samsung, e o tempo decomunicação com o terminal foi medido em torno de 5,5s. O NFC se mostrou umamaneira prática e intuitiva para o projeto proposto. Com os resultados alcançadosfoi possível identificar caminhos para a evolução do projeto conforme podem serobservados 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 con-trol that is safe and intuitive. For that end, the process makes use of Near FieldCommunication, that is a Radio Frequency communication with a limited range ofno more than 10cm. The main goal of the project is to propose a method to beused as a proof of concept and not as a stand alone comercial solution. It envolvesthe elaboration of a physical access terminal based on the Arduino board with NFCcapability and the creation of an Android app and a website for administration.The dificulties associated with the work were the implementation of low level pro-tocols of NFC peer-to-peer comunication and the implementation of the security ofthe system based on well-known public criptographic algorithms The programinglanguages that were used on the elaboration of the softwares were C++, JAVA andPHP and they were made by using the process of prototyping. The comunicationwas testes by using a Samsung Galaxy SIII mobile phone and time needed for thecomunication was measured in about 5.5s. The NFC was a proved to be a effectivetool for a praticity and intuitivity in the project. It was possible to indetify waysfor 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figura 2 – Comunicações Envolvidas . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figura 3 – OSI vs NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Figura 4 – Funcionamento do NFC. . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 5 – Modulação Digital OOK. . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 6 – Arquitetura LLCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figura 7 – Representação de um PDU . . . . . . . . . . . . . . . . . . . . . . . . 33Figura 8 – Representação do SNEP . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figura 9 – Mensagem NDEF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figura 10 –Tela de confirmação de envio de dados do Android Beam . . . . . . . . 41Figura 11 –O modelo de criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . 42Figura 12 –Estágios intermediários do DES . . . . . . . . . . . . . . . . . . . . . . 44Figura 13 –Troca de chave de Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . 45Figura 14 –Ataque Man In The Middle . . . . . . . . . . . . . . . . . . . . . . . . 46Figura 15 –Autenticação baseada em chave compartilhada . . . . . . . . . . . . . . 48

Figura 16 –Diagrama esquemático . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Figura 17 –Arduino R3 UNO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Figura 18 –Arduino MEGA 2560 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Figura 19 –Arduino DUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figura 20 –Shield NFC para o Arduino . . . . . . . . . . . . . . . . . . . . . . . . 56Figura 21 –Shield de prototipação para Arduino . . . . . . . . . . . . . . . . . . . 57Figura 22 –Relay 5V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Figura 23 –Primeiro Protótipo do Terminal . . . . . . . . . . . . . . . . . . . . . . 57Figura 24 –Blocos do sistema desmontado . . . . . . . . . . . . . . . . . . . . . . . 59Figura 25 –Placa Montada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figura 26 –Sistema em funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . 60Figura 27 – IDE para o Arduino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Figura 28 – IDE do Code::Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Figura 29 –Esquema de geração de chave para criptografia . . . . . . . . . . . . . 66Figura 30 – IDE Eclipse para programação em Android. . . . . . . . . . . . . . . . 70Figura 31 – IDE - NETBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Figura 32 –Diagrama Entidade-Relacionamento . . . . . . . . . . . . . . . . . . . 76Figura 33 –Primeira tela do aplicativo WEB . . . . . . . . . . . . . . . . . . . . . 76Figura 34 –Administração das Fechaduras . . . . . . . . . . . . . . . . . . . . . . . 76Figura 35 –Modificar Status de usuários . . . . . . . . . . . . . . . . . . . . . . . . 77

Figura 36 –Histograma dos dados da tabela 19 . . . . . . . . . . . . . . . . . . . . 84

Lista de tabelas

Tabela 1 – Formato para um PDU tipo PAX . . . . . . . . . . . . . . . . . . . . . 34Tabela 2 – Formato para um PDU tipo CONNECT . . . . . . . . . . . . . . . . . 34Tabela 3 – Formato para um PDU tipo DISC . . . . . . . . . . . . . . . . . . . . 34Tabela 4 – Formato para um PDU tipo I . . . . . . . . . . . . . . . . . . . . . . . 34Tabela 5 – Formato para um PDU tipo I . . . . . . . . . . . . . . . . . . . . . . . 35Tabela 6 – Formato de uma solicitação SNEP . . . . . . . . . . . . . . . . . . . . 35Tabela 7 – Formato de uma resposta SNEP . . . . . . . . . . . . . . . . . . . . . 35Tabela 8 – Comandos de solicitação . . . . . . . . . . . . . . . . . . . . . . . . . . 37Tabela 9 – Comandos de Resposta . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Tabela 10 –Formato do Identificador de uma Gravação NDEF . . . . . . . . . . . 38

Tabela 11 –Características dos três Arduinos trabalhados . . . . . . . . . . . . . . 55Tabela 12 –Sintaxe do Comando InitAsTarget . . . . . . . . . . . . . . . . . . . . 61Tabela 13 –Sintaxe para o comando GetData . . . . . . . . . . . . . . . . . . . . . 62Tabela 14 –Sintaxe para a resposta do comando GetData . . . . . . . . . . . . . . 62Tabela 15 –Sintaxe para o comando SetData . . . . . . . . . . . . . . . . . . . . . 62Tabela 16 –Sintaxe para a resposta do comando SetData . . . . . . . . . . . . . . 62Tabela 17 –Sintaxe do protocolo criado . . . . . . . . . . . . . . . . . . . . . . . . 69Tabela 18 –Sintaxe autorização do servidor . . . . . . . . . . . . . . . . . . . . . . 69

Tabela 19 –Testes de comunicação NFC . . . . . . . . . . . . . . . . . . . . . . . . 83Tabela 20 –Média de tempo de comunicação com o aplicativo WEB . . . . . . . . 84

Lista de Algoritmos

3.1 Algoritmo de Conexão como Cliente SNEP . . . . . . . . . . . . . . . . . . 633.2 Algoritmo de Conexão como Servidor SNEP . . . . . . . . . . . . . . . . . 633.3 Algoritmo de recepção de dados . . . . . . . . . . . . . . . . . . . . . . . . 643.4 Algoritmo de Envio de dados . . . . . . . . . . . . . . . . . . . . . . . . . 643.5 Algoritmo de PUSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.6 Algoritmo de PULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.7 Uso da Biblioteca AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.8 Uso da Biblioteca HASH MD5 . . . . . . . . . . . . . . . . . . . . . . . . . 673.9 Algoritmo de Envio de dados . . . . . . . . . . . . . . . . . . . . . . . . . 683.10 Algoritmo Para uso do Beam𝑇 𝑀 no Android . . . . . . . . . . . . . . . . . 713.11 Segundo algoritmo Para uso do Beam𝑇 𝑀 no Android . . . . . . . . . . . . 723.12 Recebimento de mensagens NDEF com Android . . . . . . . . . . . . . . . 723.13 Recebimento de mensagens NDEF com Android . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1 Near Field Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.1.1 Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.2 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.1.2.1 Camada Física (Hardware) . . . . . . . . . . . . . . . . . 302.1.2.2 Camada de enlace de Dados . . . . . . . . . . . . . . . . . 322.1.2.3 Camada de Aplicação . . . . . . . . . . . . . . . . . . . . 35

2.2 O sistema operacional Android . . . . . . . . . . . . . . . . . . . . . . . . 392.2.1 Aplicativos Android . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2.2 Android e NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.2.2.1 Android Beam𝑇 𝑀 . . . . . . . . . . . . . . . . . . . . . . . 402.2.2.2 Dispositivos com chip NFC . . . . . . . . . . . . . . . . . 40

2.3 Segurança e criptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.3.1 Métodos de criptografia . . . . . . . . . . . . . . . . . . . . . . . . 41

2.3.1.1 Método DES . . . . . . . . . . . . . . . . . . . . . . . . . 432.3.1.2 Método de compartilhamento de Chave de Diffie-Hellman 442.3.1.3 Métodos de chave pública . . . . . . . . . . . . . . . . . . 452.3.1.4 Algorítmos de HASH criptográficos . . . . . . . . . . . . . 47

2.3.2 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.3.2.1 Autenticação baseada em chave compartilhada . . . . . . . 482.3.2.2 Autenticador de uma mensagem . . . . . . . . . . . . . . . 49

3 Metodologia e Implementação . . . . . . . . . . . . . . . . . . . . . . . . . 513.1 Descrição do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.1.1 Especificação de Requisitos do Projeto . . . . . . . . . . . . . . . . 523.1.1.1 Requisitos Não-funcionais . . . . . . . . . . . . . . . . . . 523.1.1.2 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . 53

3.2 Hardware para a fechadura . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.2.1 O Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.2.2 O PN532 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.2.3 Primeiro Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.2.4 O protótipo Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.3 Software para o Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.3.1 Implementação da Biblioteca para comunicação peer-to-peer NFC . 60

3.3.1.1 Comunicação com o PN532 . . . . . . . . . . . . . . . . . 603.3.1.2 LLCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.3.1.3 SNEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.3.1.4 NDEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.3.2 Implementação da Criptografia . . . . . . . . . . . . . . . . . . . . 653.3.2.1 Implementação da Biblioteca AES . . . . . . . . . . . . . 663.3.2.2 Implementação da biblioteca MD5 . . . . . . . . . . . . . 67

3.4 Algoritmo do Sistema Completo . . . . . . . . . . . . . . . . . . . . . . . . 683.5 Protocolo criado para comunicação e autenticação . . . . . . . . . . . . . . 69

3.5.1 Mensagem e assinatura do servidor . . . . . . . . . . . . . . . . . . 693.5.2 Assinatura do Aplicativo . . . . . . . . . . . . . . . . . . . . . . . . 70

3.6 Aplicativo para Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.6.1 Envio de uma mensagem NDEF com o Beam𝑇 𝑀 . . . . . . . . . . . 713.6.2 Recebimento de uma mensagem NDEF . . . . . . . . . . . . . . . . 723.6.3 Comunicação com o Servidor . . . . . . . . . . . . . . . . . . . . . 73

3.7 Aplicativo web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.7.1 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.7.2 A interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4 Resultados e Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.1 Comunicação NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.2 Testes da comunicação NFC . . . . . . . . . . . . . . . . . . . . . . . . . . 824.3 Comunicação com o servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 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 obser-vada 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, hojesã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 propostocomercialmente 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 paga-mento de mercadorias, como o Google Wallet (GOOGLE. . . , 2013) que pode ser vista nafigura 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 celularFonte: http://www.extremetech.com/

A motivação deste trabalho é incluir no celular uma nova função além destasmuitas que já foram citadas, a de dispositivo de controle de acesso.

É claro que não há objetivo de implementar um produto comercial, mas de servircomo 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 dis-positivo 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 encontrarperifé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 intui-tiva. 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 FieldCommunication, que será discutido nas próximas seções.

O NFC já é utilizado em celulares para várias funções, a principal delas é a leiturade cartões baseados nesta tecnologia, que podem funcionar como cartões de visita ou deinformações de murais eletrônicos.

Para implementação de um sistema mais completo, deve-se incluir, também, apossibilidade de gerenciamento das autorizações através da internet. A figura 2 mostraum 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 queexista um protocolo de comunicação seguro e unificado. Este protocolo deve envolveralgoritmos criptográficos para garantir segurança do sistema.

Ao decorrer desse trabalho serão apresentadas todas as etapas de elaboração doprojeto, 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 devefuncionar como interface entre o usuário e a fechadura.

∙ Elaboração de um aplicativo web, onde o administrador do sistema possa gerenciaracessos individuais ao terminal.

27

∙ Elaboração de um protocolo de segurança para comunicação entre todas as partesque 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 decomunicação de rádio entre dois dispositivos a uma curta distancia, geralmente não maisque alguns centímetros, o que o torna muito recomendado em transações que exigem certonível de segurança. (KUMAR, 2011; HASELSTEINER; BREITFUSS, 2006).

Esses padrões foram criados baseados no já existente RFID, acrônimo para RadioFrequency IDentification. Eles incluem protocolos de comunicação e formatos de dadosdefinidos pelo Fórum NFC, criado em 2004 por Nokia, Sony e Philips, e hoje já possui maisde 160 membros, incluindo Samsung, Google, RIM, Microsoft, Intel, Visa, MasterCard eoutros. (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çõesbem 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 espe-cificações, foi criado o Fórum NFC. Depois disso logo começaram a surgir os primeiroscelulares 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, OGalaxy Nexus2. O uso do NFC só aumentou desde então com o surgimento de SmartTags e dos métodos de pagamento utilizando celular.

Nesse ano, Samsung e VISA anunciaram uma parceria para desenvolvimento demétodos de pagamento via celular (MAJOR. . . , 2013), o que promete aumentar o númerode dispositivos com chip NFC embutido.

2.1.2 Funcionamento

Existem basicamente três formas de comunicação NFC: (KUMAR, 2011)

1 Radio-Frequency Identification, permite que ondas de rádio sejam emitidas para um dispositivo passivopara identificação e autenticação.

2 Surgido de uma parceria entre Samsung e Google (desenvolvedora do sistema operacional de códigoaberto Android).

30 Capítulo 2. Embasamento Teórico

∙ Emulação de cartão: Onde um dispositivo se passa por uma tag ou cartão NFCpassivo para responder a um pedido de um iniciador ativo.

∙ Leitura e Gravação de cartão: Onde um iniciador pode ler ou gravar alguma infor-maçã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 algunsdos sistemas operacionais móveis que suportam NFC (incluindo o Android) não permitemo modo de Emulação de Cartão.

Para explicar seu funcionamento, as seguintes sessões fazem um paralelo entre ascamadas 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 é mostradona 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 pequenacorrente elétrica em sua antena, esta, cria um campo magnético que ocupa o espaço entreo 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çãode 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 induzidapelo 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 transferirinformação. Essa onda é chamada de portadora.

Um exemplo de modulação pode ser visto na figura 5. A modulação OOK (on-offkey) 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 facil-mente com o uso de um diodo e um capacitor. Também é implementado um extrator declock 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 para3 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.

http://www.antenna-theory.com

http://www.eetimes.com/


alimentar o dispositivo, dessa forma a modulação OOK se torna inviável para uma mensa-gem 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 paracomunicações peer to peer é definida pelo NFC Fórum através da especificação técnica doLLCP (Logical Link Control Protocol). Podemos citar como principais aspectos do LLCP:(NFC - FORUM, 2011)

∙ Define como dois dispositivos dentro do alcance podem reconhecer implementaçõescompatí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 queum deles seja o mestre, chamado Initiator, que é capaz de enviar e requisitar dadospara o escravo, chamado target.

∙ O LLCP não provê nenhum tipo de segurança entre os dois pontos, a segurançadeve 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émde 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 outrê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 AccessPoint) e SSAP (Source Service Access Point). O DSAP deve informar o serviço doponto de acesso para qual a informação foi transmitida. O SSAP deve informar oServiç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 asintaxe e a semântica utilizada nos outros campos do PDU e deve ter um dos valores


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 comentaremossobre alguns desses tipos.

∙ Um capo de sequência formado por 0 ou 1 bytes, está presente apenas em algunstipos de PDU. O campo de sequência, quando presente, está dividido em 4 bitspara sequência de envio (nos bits mais significantes), e 4 bits para a sequência derecepção (nos 4 bits menos significantes).

∙ Um campo de informação formado por 0 ou N bytes, o tamanho desse campo de-pende do tipo de PDU e o máximo valor de N depende do serviço que receberá ainformação.

http://www.nfc-forum.org/



Tipos de PDU

Serão comentados apenas alguns tipos de PDU’s, os mais relevantes para o contextodeste trabalho.

∙ PDU tipo PAXO 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 PDUe o campo de informação deve conter os parâmetros de configuração. O formatopara 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 umPDU tipo PAX é visto na tabela 1.

Tabela 1: Formato para um PDU tipo PAXDSAP PTYPE SSAP INFORMAÇÂO000000 0001 000000 Lista de parâmetros

∙ PDU tipo CONNECTO PDU tipo Connect é usado para solicitação de uma conexão. Ele deve conterambos os campos de endereço e pode conter o campo de informações para parâmetrosde conexão. O formato para esses não se encontram no contexto deste trabalho. Oformato para um PDU do tipo connect pode ser visto na tabela 2:

Tabela 2: Formato para um PDU tipo CONNECTDSAP PTYPE SSAP INFORMAÇÃO

DDDDDD 0100 SSSSSS Lista de parâmetros (opcional)

∙ PDU tipo DISCO PDU tipo DISC (Disconnect) Serve para terminar uma conexão, ele não devepossuir o octeto de sequencia nem os bytes de informação. O formato é mostradona tabela 3.

Tabela 3: Formato para um PDU tipo DISCDSAP PTYPE SSAP

DDDDDD 0101 SSSSSS

∙ PDU tipo IO 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 servisto na tabela 4.


Tabela 4: Formato para um PDU tipo IDSAP PTYPE SSAP Sequência INFORMAÇÃO

DDDDDD 1100 SSSSSS Seq. envio Seq. recebimento Dados

∙ PDU tipo SYMMO PDU do tipo SYMM (Symmetry) esse tipo de PDU é usado pela LLCP paraquando nenhum outro PDU está disponível para ser mandado, apenas para garantira simetria do protocolo. Pode-se ver o formato na tabela 5.

Tabela 5: Formato para um PDU tipo IDSAP PTYPE SSAP Sequência INFORMAÇÃO

DDDDDD 1100 SSSSSS Seq. envio 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 dedado pelo NFC é o SNEP (Simple NDEF Data Exchange). Esses dados são enviadosno formato de menssagens NDEF (NFC Data Exchange Format). Esses tópicos serãodiscutidos com mais profundidades nas subseções seguintes.

Outros protocolos utilizados para comunicação via NFC peer-to-peer não serãoabordados nem mencionados no contexto desse trabalho.

Protocolo SNEP

O SNEP (NFC - FORUM, 2013c) é um protocolo de solicitação e resposta (re-quest/response) onde o cliente faz uma solicitação ao servidor e espera uma resposta. Casoo tamanho de uma solicitação ou uma resposta seja maior que o máximo possível para oprotocolo inferior, no caso, o LLCP mencionado na seção anterior, ela deve ser divididaem fragmentos. A figura 8 mostra um exemplo de comunicação baseado no protocoloSNEP.

Uma solicitação SNEP tem o formato mostrado na tabela 6 e a resposta possui oformato especificado na tabela 7.

Tabela 6: Formato de uma solicitação SNEP

Cabeçalho SNEPVersão Solicitação Tamanho Carga útil1 byte 1 byte 4 bytes Tamanho especificado

O significado dos campos vistos nas tabelas 6 e 7 é:


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 SNEPVersão Resposta Tamanho Carga útil1 byte 1 byte 4 bytes Tamanho especificado

∙ Versão indica o formato da mensagem que está sendo enviada e a capacidade dodispositivo que a enviou de entender comunicações futuras. É formado 2 númerosinteiros de 4 bits, o primeiro para a maior versão e o segundo para menor versãoaceita.

∙ Solicitação indica a ação que deve ser executada no servidor, a tabela 8 mostra ostipos de comandos aceitos.

∙ Resposta indica o resultado da ação solicitada ao servidor. A tabela 9 mostra oscomandos 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.



∙ Carga útil é a parte da mensagem onde vai a mensagem NDEF, a ser discutida umpouco mais a frente

Tabela 8: Comandos de solicitação

Código Comando Descrição00h Continue Continuar enviando os pró-

ximos fragmentos da men-sagem (esse comando nãoserá importante no con-texto deste trabalho).

01h Get Requisita do servidor umamensagem NDEF de res-posta deve conter na cargaútil o tamanho máximo damensagem a ser recebida euma mensagem NDEF queidentifica o tipo de mensa-gem a ser recebida.

02h Put Solicita que o servidoraceite uma mensagemNDEF que é enviada nacarga útil.

7Fh Reject Solicita que o servidor nãoenvie os próximos fragmen-tos da mensagem.

Formato NDEF

O NDEF (NFC - FORUM, 2006) é o formato que define a forma como uma men-sagem será encapsulada para transferência, ele pode ser usado tanto para tags passivasquanto para dispositivos ativos4. Para explicar como funciona uma mensagem NDEFserã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 umcabeçalho e uma ‘carga útil’.

∙ Cabeçalho: Composto de um identificador, o tamanho da carga útil e o tipo dacarga ú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 partedas aplicações NFC, esse trabalho se limitará a esse formato


Tabela 9: Comandos de Resposta

Código Comando Descrição80h Continue Continuar enviando os pró-

ximos fragmentos da men-sagem (esse comando nãoserá importante no con-texto desse trabalho).

81h Success Requisita do servidor umamensagem NDEF de res-posta deve conter na cargaútil o tamanho máximo damensagem a ser recebida euma mensagem NDEF queidentifica o tipo de mensa-gem a ser recebida.

C0h - C2h Erro Códigos para alguns tiposde erro, como mensagemmal formulada ou excessode dados

E0h - E1h Não Suportado Indica que a versão ou otipo 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 namensagem.

http://www.developer.nokia.com

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 parteda carga útil está presente.

∙ SR (Short Record): Caso esteja em 1, indica que essa é uma gravação pequenae o campo Tamanho possui apenas um byte.

∙ IL (ID Length:) Indica que existe um octeto para o tamanho do ID e um campopara 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 Linuxe desenvolvido primariamente para dispositivos móveis com touchscreen, como tablets ecelulares. Ele foi desenvolvido primeiramente pela Android Inc., que em 2005 foi compradapela Google. O Android é open-source e o código é disponibilizado pela Google sob alicenç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 desenvol-vedores de aplicativos móveis.

Esses fatores contribuíram bastante para tornar o Android a plataforma móvelmais utilizada no mundo. Segundo o site IDC (IDC. . . , 2013), no segundo trimestre de2013, 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 utili-zando 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 lojade aplicativos da Google, mas o sistema permite que um usuário baixe, instale e utilizeaplicativos por outros meios. (ANDROID. . . , 2013)


2.2.2 Android e NFC

O sistema operacional Android possui sua própria biblioteca para que desenvol-vedores 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 escritapara NFC, o modo de emulação de cartão ainda não foi disponibilizado para o público e omodo 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 doisdispositivos. O Beam𝑇 𝑀 foi criado para fazer troca de pequenas informações entre doisdispositivos Android apenas tocando um no outro, e isso acarreta algumas limitações quesão tratadas como restrições de projeto: (ANDROID. . . , 2013)

∙ A aplicação que está enviando uma mensagem deve estar em foreground, aberta evisí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 é feitoatravés de uma tela com a mensagem: "Toque para transferir". Ela pode ser vistana figura 10. No momento não é possível enviar dados via NFC sem que o usuáriotoque a tela em confirmação.

2.2.2.2 Dispositivos com chip NFC

Com o crescimento do NFC, muitos celulares android possuem chip NFC embuti-dos. A google anunciou durante o evento "Google I/O"desse ano, que cerca de 1 milhão dedispositivos Android com essa funcionalidade são ativados a cada semana. Esses númerostendem apenas a crescer, segundo a STRATEGY ANALITICS, no final de 2013 serão emtorno 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 criptografiaUm 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 erecebida de forma segura. Nessa sessão foi feito um apanhado de informações sobreinú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 queas mensagens a serem enviadas, aqui será chamado de texto simples, são transformadasem uma mensagem ilegível, aqui chamada de texto criptografado.

Durante o processo de comunicação a mensagem criptografada é enviada para odestinatário, este, conhecendo o método de decriptografia pode transformá-la em textosimples novamente. (SCHNEIER, 1996).

A figura 11 mostra como funciona o modelo clássico de criptografia. Para que estefuncione, deve-se supor que o destinatário conhece o método de decriptografia. Dessaforma, porem, ele deve ser mudado sempre que for comprometido, uma vez que um intruso


Figura 11: O modelo de criptografia

também possa conhecê-lo. Para evitar tal esforço, usa-se uma chave de criptografia, quenada mais é que uma string usada para parametrizar o método. Dessa forma, precisa-sede uma chave sigilosa e um método público.

Visto que os métodos de criptografia e decriptografia são apenas funções mate-máticas onde a chave e o texto são parâmetros, será usada uma notação similar àquelassugeridas 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)

e

𝑆 = 𝐷𝑘(𝐶) (2.2)

O que significa que a encriptação da mensagem 𝑆, usando a chave 𝑘 tem comoresultado 𝐶 e, da mesma forma, 𝐶 decriptado com utilização da chave 𝑘 resulta em 𝑆.As equações também sugerem:

𝑆 = 𝐷𝑘(𝐸𝑘(𝑆)) (2.3)


É claro que esse método depende de um meio seguro por onde a chave encriptaçãopossa ser transmitida. Uma maneira de evitar isso é utilizar um método de chave públicaou 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 eminformática. Segundo Wayner (1995), ele já não é mais segura quando usada da mesmaforma que foi criada, porém, modificado, ainda é bastante útil.

Segundo Tanenbaum (1997), o DES funciona dividindo o texto simples em blocosde 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últimoestágio é feito um SWAP de 32 bits6. Nos estágios intermediários divide-se o bloco de 64bits em dois blocos de 32 bits, que serviram como entrada. Será utilizado 𝐷𝑖𝑛 e 𝐸𝑖𝑛 paradenotar as entradas e 𝐷𝑜𝑢𝑡 e 𝐸𝑜𝑢𝑡 para denotar as saídas. Esse método foi criado para quea mesma chave de criptografia possa ser usada para decriptografia.

As equações de cada método intermediário são:

𝐸𝑜𝑢𝑡 = 𝐷𝑖𝑛 (2.4)

e

𝐷𝑜𝑢𝑡 = 𝐸𝑖𝑛 ⊕ 𝐹𝑘𝑖(𝐷𝑖𝑛) (2.5)

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çãoOU EXCLUSIVO bit a bit com 𝑘𝑖 e um processo complexo transforma a saída em 32 bitsnovamente.

Em cada um desses estágios, uma chave diferente é utilizada. Antes do início doalgoritmo uma transposição é aplicada a chave e logo depois esta é particionada em duasunidade de 28 bits. Essas unidade são roteadas para esquerda ou direita um certo númerode bits de acordo com o estágio. Em cada estágio é usado um subconjunto de 48 bits para𝑘𝑖.

5 Método onde os bits da mensagem são colocados em ordem diferente segundo imposto pela chave6 Método onde se troca os 32 bits da esquerda com os 32 bits da direita


Figura 12: Estágios intermediários do DES

O método DES é mais utilizado hoje em dia em suas variações, uma delas é oprocesso de tripla criptografia com duas chaves, onde:

𝐶 = 𝐸𝑘1(𝐷𝑘2(𝐸𝑘1(𝑆))) (2.6)

e

𝑆 = 𝐷𝑘1(𝐸𝑘2(𝐷𝑘1(𝐶))) (2.7)

(TANENBAUM, 1997)

Pode-se observar que apesar da tripla criptografia apenas duas chaves são utiliza-das, o uso de uma terceira chave seria um grande exagero uma vez que os 112 bits dasduas chaves são suficientes para garantir a segurança.

Alem disso, pode ser visto que o processo de criptografia envolve uma decriptogra-fia com uma segunda chave7, um bom motivo para isso a retrocompatibilidade (Schneier,1996). Apenas definindo 𝑘1 = 𝑘2 um computador que usa criptografia tripla pode secomunicar 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 seguraentre 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.


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)/2e (𝑔 − 1)/2 também sejam primos. Esses números são públicos e podem ser informadosabertamente 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 mensagemcontendo (𝑔𝑏 mod 𝑛). 𝐴 pode calcular: (𝑔𝑏 mod 𝑛)𝑎 e b pode calcular: (𝑔𝑎 mod 𝑛)𝑏.Como:

(𝑔𝑎 mod 𝑛)𝑏 = 𝑔𝑎𝑏 mod 𝑛 = (𝑔𝑏 mod 𝑛)𝑎

Dessa forma 𝐴 e 𝐵 possuem uma chave secreta compartilhada (𝑔𝑎𝑏 mod 𝑛). Mesmoque 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, queenvolve um intruso ativo. Considerando que um intruso 𝐼 pode interceptar a comunicaçãoentre 𝐴 e 𝐵, ele pode se passar por um dos dois e enviar mensagens falsas, escolhendoum 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 anteriormenteestá na distribuição de chaves. Caso um intruso consiga roubar a chave, o sistema se tornainútil. Diffie e Hellman (1976) propuseram um novo sistema de criptografia onde a chaveusada para criptografar é diferente da chave usada para decriptografar. Nesse sistema


Figura 14: Ataque Man In The Middle

deve-se garantir que é extremamente difícil de deduzir uma das chaves conhecendo asegunda.

Esse método funciona da seguinte maneira. Considerando a comunicação entre𝐴 e 𝐵, 𝐴 cria uma chave de criptografia e uma de decriptografia, 𝑘𝑒 e 𝑘𝑑 respectiva-mente. 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 tornadospú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 partirdisso é 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 é baseadona 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.


∙ 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 nointervalo: 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 (𝑒, 𝑛) (chavepública) e para decriptografia do par (𝑑, 𝑛) (chave privada).

A segurança do método está baseda na dificuldade de se fatorar números bas-tante extensos. Caso consiga-se fatorar o número publicamente conhecido 𝑛, poderia-sedescobrir os valores de 𝑝, 𝑞, 𝑧 e consequentemente 𝑑.

Porém, considerando um tempo de 1𝜇𝑠 por instrução, o melhor dos algoritmoslevaria 4 bilhões de anos para fatorar um número de 200 dígitos e 1025 anos para um de500 dígitos. (RIVEST; ADLEMAN, 1978)

O RSA é muito utilizado para distribuir chaves de sessões únicas, dados muitograndes são geralmente encriptados com o DES, uma vez que o RSA é muito lento paraessa 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 eretornar um segundo vetor de tamanho fixo de forma que qualquer mudança nos dadosvai, 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 possuiras 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


Algoritmos de hash são utilizados tanto para verificação de senhas do usuárioquanto para assinaturas digitais e MACs (Message Autentication Code).(BELLARE; KI-LIAN; 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 muitasaplicações, garantir que uma informação é autentica é mais importante que o própriosigilo 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 segundoverifica permissões que uma identidade tem de executar uma ação.

Sistemas que envolvem controle de acesso são exemplos de sistemas que necessitamde mecanismos com ambas as funções.

Nesta seção, será mostrado dois métodos que podem ser utilizados para garantira 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 formade 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 enviapara B, B usa a chave compartilhada e gera 𝐸𝑘𝐴𝐵

(𝑅𝐴). B envia o resultado da encriptaçãopara A, que compara com a sua própria encriptação. A sabe que um invasor não poderiater encriptado corretamente 𝑅𝐴 pois apenas B conhece a chave secreta 𝑘𝐴𝐵. Esse métodopode 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 umamensagem. 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.


Figura 15: Método de autenticação baseado em chave compartilhada

Ele se diferencia dos outros métodos de assinaturas digitais uma vez que utilizaencriptação simétrica, e não de chave privada.

O MAC parte da hipótese de que as duas partes que necessitam da autenticaçãojá compartilham uma chave secreta. Caso essa chave seja comprometida, todo o processode autenticação pode se tornar inválido. (TANENBAUM, 1997)

51

3 Metodologia e Implementação

3.1 Descrição do ProjetoO projeto consiste em um terminal desenvolvido com utilização da plataforma

Arduino, com capacidade NFC adicionada, que controla uma fechadura elétrica. Esseterminal deve ser capaz de se comunicar com um celular, que também deve ter capacidadesNFC, rodando um aplicativo desenvolvido para o sistema operacional Android.

O projeto também prevê a utilização de um aplicativo web para gerenciamento eadministração de acesso.

Um diagrama esquemático das interações entre os componentes do sistema podeser visto na figura 16. Uma explicação mais detalhada do processo envolvido será incluídanas 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 se-guintes.

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 aplicativoWEB.

3.1.1.1 Requisitos Não-funcionais

∙ A comunicação entre o Aplicativo móvel e o Terminal deve ser feita de formasegura com criptografia RSA, DES ou AES(FIPS, 2001) e autenticação.

∙ O Desenvolvedor deve prever atualizações periódicas para suprir a necessidade desegurança do sistema.

∙ Todos os dados dos Usuários e do Cliente devem ser gravados de forma cripto-grafada e segura, através de uma função Hashing.

∙ O tempo entre o envio da mensagem pelo Aplicativo móvel e a abertura da portadever ser o menor possível (< 5𝑠).

∙ O usuário deve conseguir acesso com o mínimo de configuração possível e o mínimode toques na tela.

∙ Apenas uma mensagem deve ser enviada pelo Aplicativo móvel para o Terminala fim de cumprir os requisitos dos dois itens anteriores.

∙ O sistema deve gravar um LOG de acesso à fechadura, relatando quais Usuários autilizaram.

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 KISSKeep It Symple, Stupid.

∙ O aplicativo móvel deve rodar em Android versão 4.0 (Ice Cream Sandwish) emais novas.

∙ O aplicativo móvel deve ser atualizado automaticamente quando necessário, sejavia Google Play ou por um sistema customizado do Desenvolvedor (sem necessi-dade 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 alimentadacom 12V.

∙ O terminal deve ser capaz de se comunicar através do NFC utilizando o modo decomunicação peer-to-peer.

∙ O Terminal deve ser capaz receber e enviar mensagens por NFC no formato NDEFcom utilização do protocolo SNEP sobre LLCP.

∙ O Cliente deve ser capaz de autorizar ou revogar a autorização de qualquer usuáriopara acesso de qualquer terminal a qualquer momento através do Aplicativo WEB.

3.2 Hardware para a fechaduraPara 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.


3.2.1 O Arduino

O Arduino é uma plataforma de prototipagem eletrônica baseada em processadoresda ATMEL, que podem variar desde um AVR de 8-bits à um ARM de 32-bits. O Arduinofoi escolhido tanto pela vasta gama de acessórios disponíveis quanto pela quantidade deinformação e bibliotecas disponíveis na internet, já que é um projeto de hardware-livre ecódigo-aberto.

Durante o desenvolvimento do sistema, foram feitos vários testes de desempenhodas bibliotecas implementadas, por isso utilizou-se 3 Arduinos diferentes, o UNO (figura17), o MEGA (figura 18) e o DUE 19. Pode-se ver um comparativo de algumas caracte-rísticas importantes dos 3 Arduinos na tabela 11.

(a) Arduino R3 UNO (Frente) (b) Arduino R3 UNO (Costas)

Figura 17: Arduino R3 UNOFonte: http://www.arduino.cc/

Figura 18: Arduino MEGA 2560Fonte: http://www.arduino.cc/

Pode-se ver que o Arduino UNO não possui alto poder de processamento, nãosó 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 objetosStrings isso se torna um grande problema, uma vez que pode-se facilmente chegar a 2048caracteres.

http://www.arduino.cc/



Figura 19: Arduino DUEFonte: http://www.arduino.cc/

Tabela 11: Características dos três Arduinos trabalhados

Arduino UNO Arduino DUE Arduino MEGAMicrocontrolador ATmega328 AT91SAM3X8E ATmega2560Tensão de Operação 5V 3.3V 5VTensão de entrada 7-12V 7-12V 7-12VPinos Digitais (I/O) 14 54 54Pinos Analógico (I) 6 12 16Memória Flash 32 KB 512 KB 256 KBSRAM 2 KB 96 KB 8 KBEEPROM 1 KB 4 KBFrequência de Clock 16 MHz 84 MHz 16 MHz

3.2.2 O PN532

O PN532 é um modulo de transmissão para comunicação via RF a 13.56MHz. Eleinclui a funcionalidade de um microcontrolador com núcleo baseado em um 80C51. Elepode se comunicar via UART, I2C ou SPI.

Esse chip foi escolhido por:

∙ Estar facilmente disponível para o Arduino em forma de Shield1. O shieldutilizado para o projeto pode ser visto na figura 20.

∙ Ser largamente utilizado. Vários dos celulares com capacidade NFC possuemum PN532 imbutido.

∙ Ser capaz de realizar comunicação peer-to-peer. Muitos do chips disponíveispossuem 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



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 estadoda porta e um buzzer para envio de mensagens de erro ou sucesso. Tais elementos foramexcluídos do projeto na implementação final.

Projetou-se o primeiro protótipo do terminal segundo o esquemático mostrado noapê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 viaNFC sem utilização de criptografia. Quando foram inclusos testes com criptografia oarduino UNO se mostrou muito limitado. Por esse motivo buscou-se a utilização demicrocontroladores 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:


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


e ter a quantidade de RAM necessária, além da compatibilidade de software com oUNO, já que possuem a mesma arquitetura AVR).

∙ Não será utilizado um shield de prototipação com protoboard, os elementos utili-zados 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 Relayde estado sólido. Uma segunda plca deverá ser confeccionada para ele quando fortestado com uma fechadura elétrica real.

∙ Não será incluído, por enquanto, o sensor magnético (Reed Switch). Apenas pormotivo 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 utili-zação de dois LEDs acionados através de transistores.

∙ Para cumprir alguns requisitos de segurança do projeto, deverá ser incluso, na placaconfeccionada, um RTC (Real Time Clock).

Seguindo os requisitos propostos para o protótipo final montou-se uma placa deprototipaçã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. Mostratambé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 aaproximação de um celular).

3.3 Software para o ArduinoA 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 PN532e implementasse a comunicação peer-to-peer. As bibliotecas disponíveis até o momentoapenas faziam leitura e gravação de tags passivas.

A segunda etapa envolveu a implementação da segurança do sistema. Algumasbibliotecas deveriam ser desenvolvidas para garantir a segurança.

Como não se tinha certeza da eficiência de qualquer algoritmo que pudesse serutilizado, ou como se comportariam nos 3 Arduinos, ou durante a transmissão NFC, aabordagem 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 qualquerArduino

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 foramutilizadas duas IDE’s. A primeira, foi a IDE do Arduino, mostrada na figura 27. Por seruma IDE bem simples, foi utilizada principalmente para fazer compilação e transferênciado código.

Para criação das bibliotecas, foi utilizada uma IDE muito mais completa, commuito mais recursos. Uma plataforma de código aberto chamada Code::Blocks (figura28).


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 imple-mentar 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 decódigo livre desenvolvida pela ADAFRUIT) e a LIBNFC (biblioteca de código livre de-senvolvida pelo NFC-Fórum), utilizada como referência para implementação de algunstipos.

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-


Figura 28: IDE do Code::Blocks

cumentação do PN532 e da configuração esperada pelo Android. Dessa forma, váriastentativas precisaram ser feitas.

Nas seções subsequentes, pode-se ver os principais comandos do PN532 que foramutilizados.

Comando InitAsTarget

O comando Init as Target serve para configurar o PN532 como target. Ao enviaresse 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, princi-palmente 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) a424kbps.

Comando GetData


Esse comando possibilita que o controlador (Arduino) receba os dados que foramrecebidos pelo PN532 do Initiator. Ele funciona apenas se o PN532 estiver configuradoem modo de Target.

A sintaxe desse comando pode ser vista na tabela 13. A sintaxe da resposta podeser 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 podedemorar um pouco para enviar os dados. O PN532 envia uma resposta para pedir maistempo 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, maistarde, os envie para o Initiator. A sintaxe do comando pode ser vista na tabela 15. Asintaxe para a resposta desse comando é bem simples, apresenta apenas um byte de Statusque 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 dadosbaseando-se no protocolo já comentado na seção 2.1.2.2. Alguns algoritmos utilizadospara 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. Algumasdas especificações do protocolo SNEP já são atribuídas a abstração da camada de enlacede dados que foi implementada.


Isso não é um problema uma vez que a aplicação tem interesse apenas em imple-mentar o protocolo SNEP.

Quando o Android deseja enviar uma mensagem (Beam𝑇 𝑀), ele faz uma requisiçãopara 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 eDSAP da comunicação nos PDUs necessários, determinar o byte de sequência3 e determi-nar os parâmetros que devem ser enviados nos bytes de informação em alguns casos.

1 configuraPN532comoTarget ( ) ;se r e su l t ado != OK

3 r e to rne ERRO;recebePDU_PN532 ( ) ;

5 enviaPDU_PN532(CONNECT) ;recebePDU_PN532 ( ) ;

7 enquanto Tipo_PDU_Recebido = SYMM {// espera conexao bem suced idaenviaPDU_PN532(SYMM) ;

9 se TIME_OUTre to rne ERRO;

11 recebePDU_PN532 ( ) ;}

13 se Tipo_PDU_Recebido = CONN_SUCCESSre to rne OK;

Algoritmo 3.1: Algoritmo de Conexão como Cliente SNEP

configuraPN532comoTarget ( ) ;2 se r e su l t ado != OK

re to rne ERRO;4 recebePDU_PN532 ( ) ;

enviaPDU_PN532(SYMMM) ;6 recebePDU_PN532 ( ) ;

enquanto Tipo_PDU_Recebido != CONN{ // espera conexao8 enviaPDU_PN532(SYMMM) ;

se TIME_OUT

3 Para essa aplicação, ele nunca será maior que zero, uma vez que apenas uma mensagem é enviada ourecebida por conexão devido as limitações já discutidas do Android


10 r e to rne ERRO;recebePDU_PN532 ( ) ;

12 }enviaPDU_PN532(CONN_SUCCESS) ;

14 r e to rne OK;

Algoritmo 3.2: Algoritmo de Conexão como Servidor SNEP

recebePDU_PN532 ( ) ;2 enquanto Tipo_PDU_recebido != INFORMATION {

se PDU_recebido != OK4 r e to rne ERRO;

se Tipo_PDU_recebido == SYMM6 enviaPDU_SYMM_PN53;

se TIME_OUT8 r e to rna ERRO;

}10

enviaPDU_PN532(RECEIVE_READY) ; // Envia conf i rmacao LLCP12 PN535_recebe_PDU ( ) ;

14 enviaPDU_PN532( I ) ; // envia r e spo s ta SNEP ( receb ido corretamente )

Algoritmo 3.3: Algoritmo de recepção de dados

enviaPDU_PN532(SYMM) ;2 recebePDU_PN532 ( ) ; // espera−se um PDU de s i m e t r i a

enviaPDU_PN532( I ) ; // envia os dados para o s e r v i d o r SNEP4

recebePDU_PN532 ( ) ; // espera−se um PDU RECEIVE_READY6

PN535_enviaPDU(SYMM) ;8

PN535_recebe_PDU ( ) ; // espera−se conf i rmacao SNEP (PDU t ipo 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 abs-tração é basicamente gerar os cabeçalhos SNEP. Dois algoritmos simples foram imple-mentados para fazer o PUSH (algoritmo 3.5) e o PULL (algoritmo 3.6) implementadospelo android.

LLCP_conectaComoServidor ( ) ;2 geraCabecalhoSnep ( ) ;

4 se LLCP_enviaDados ( ) != OK


re to rna ERRO;6

r e to rna OK;

Algoritmo 3.5: Algoritmo de PUSH

LLCP_conectaComoClient ( ) ;2

se LLCP_recebeDados ( ) != OK4 r e to rna ERRO;

6 veri f icaCabecalhoSNEP ( dados_recebidos ) ;

8 r e to rna menssagem_NDEF ; // r e t i r a o cabeca lho SNEP e re torna// 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 damensagem NDEF, juntar as Gravações NDEF (NDEF Records), colocar corretamente ostipos 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. Essaprimeira tentativa foi feita no Arduino UNO, que se mostrou insuficiente para suportartal algoritmo. O RSA envolve apenas operações de exponenciação e MOD, porém, comnúmeros muito grandes (pelo menos 1024 bits).

Dessa forma, usou-se apenas o AES, um método de criptografia de blocos comchave simétrica (FIPS, 2001).

O protocolo de Diffie-Hellman, para gerar uma chave de 16 bytes, também necessi-tava de operações de exponenciação com números muito grandes e de geração de númerosprimos imensos, com mais de 300 dígitos (DIFFIE; HELLMAN, 1976). O uso do protocoloDiffie-Hellman foi substituido, então, por o uso de uma chave de criptografia baseada emum 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 diagramada figura 29.


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 depadding.

Essa biblioteca foi gerada de acordo com o padrão definido em (FIPS, 2001) padrãooficial da AES. Um exemplo da utilização da biblioteca pode ser vista no código C doalgoritmo 3.7.

i n c lude "DAES. h "2

d e f i n e KEY_SIZE 164

byte_t key [ 1 6 ] = { . . . } ;6 byte_t iv [ 1 6 ] = { . . . } ;

char * pla in_text = " . . . " ;8

DAES aes ;10

// . . .12

void i n i t ( ) {14 byte_t cryptData [ s t r l e n ( p la in_text ) ] ;

byte_t decryptData [ s t r l e n ( p la in_text ) ] ;16 DAES. setKey ( key , KEY_SIZE) ;

DAES. encrypt_ECB ( cryptData , pla in_text , s t r l e n ( p la in_text ) ) ;18

// caso modo CBC20 DAES. encrypt_CBC( cryptData , pla in_text , s t r l e n ( p la in_text ) , i v ) ;

22 // Decr ipt


DAES. decrypt_ECB ( decryptData , cryptData , s t r l e n ( p la in_text ) ) ;24

DAES. decrypt_CBC( decryptData , cryptData , s t r l e n ( p la in_text ) , i v ) ;26

// todas e s s a s funcoes j a consideram que o tamanho do p l a i n text28 //eh um mult ip lo de 16 , j a que nao e usado nenhum t ipo de padding

30 whi le (1 ) ;}

32

void loop ( ) {34 }

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. Umexemplo de uso pode ser visto no algoritmo 3.8.

O MD5 foi utilizado pela facilidade de implementação, mas sabe-se de algumas desuas fragilidades para utilizações que exigem certo nível de segurança. A biblioteca foifeita para incluir novas formas de HASH e, caso necessário, uma possibilidade é incluirSHA1 (STANDARD, 1993).

i n c lude "DASH. h "2

char * word1 = " . . . " ;4 char * word2 = " . . . " ;

char * s a l t = " . . . " ;6

DASH d i g e s t ;8

// . . .10

void i n i t ( ) {12 byte_t digest_out [ 1 6 ] ;

d i g e s t . z e r a t e ( ) ;14 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 ) ) ;16 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( digest_out ) ;

20 whi le (1 ) ;}


22

void loop ( ) {24 }

Algoritmo 3.8: Uso da Biblioteca HASH MD5

3.4 Algoritmo do Sistema Completo

loop {2

e spe raCe lu l a r ( ) ;4

envia_mensagem_NFC(ID , GeradordeSenha ) ;6

enquanto ! TIME_OUT {8 recebe_mensagem_NFC () ;

10 }

12 se TIME_OUTloop ( ) ;

14

d e c r i p t o g r a f a ( mensagem_recebida ) ;16

veri f icaComando ( ) ;18

se ! v e r i f i c a A u t e t i c a c a o ( )20 loop ( ) ;

22 se ! v e r i f i c a A u t o r i z a c a o ( )loop ( ) ;

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 funcio-namento do terminal em seu mais alto nível. Pode-se ver que a mensagem recebida passapor uma fase de decriptografia, uma fase de verificação da autenticação e uma terceirafase de verificação da autorização.

A fase de verificação de autenticação envolve autenticar o Servidor, o celular, e ousuá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 protocolomostra como cada mensagem deve ser enviada, assinada e criptografada. Para uso desseprotocolo 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 comoserá especificado.

O protocolo consiste em uma autorização do servidor, a senha do usuário e aassinatura do aplicativo, como mostra a tabela 17.

Tabela 17: Sintaxe do protocolo criado

Autorização do Servidor Senha do usuário Assinatura do aplicativo(32 bytes) (16 bytes) (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 umapalavra para autenticação utilizada como salt de 16 bytes (𝐴𝑢𝑡𝑆𝑎𝑙𝑡𝑆𝑇 ).

∙ O terminal e o celular devem compartilhar uma chave de 16 bytes(𝑘𝐴𝑇 ), uma palavrapara autenticação utilizada como salt de 16 bytes (𝐴𝑢𝑡𝑆𝑎𝑙𝑡𝐴𝑇 ) e um segundo saltpara 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 ID Terminal ID Aplicativo Data expiração Assinatura do servidor(4 bytes) (4 bytes) (4 bytes) (4 bytes) (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 execu-tado.

∙ ID Aplicativo indica qual aplicativo (Celular) tem autorização de executar essecomando.

∙ Data de expiração indica até quando essa autorização é válida.


∙ A assinatura do servidor consiste em uma criptografia AES com a chave 𝑘𝑆𝑇 deum 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 umhash MD5 da autorização do servidor mais a senha do usuário mais um salt 𝐴𝑢𝑡𝑆𝑎𝑙𝑡𝐴𝑇 .

AssinApp = 𝐸𝐴𝐸𝑆𝑘𝐴𝑇

(MD5(AssinServer||UserPass||AutSalt𝐴𝑇 ))

3.6 Aplicativo para AndroidFoi desenvolvido um aplicativo para o Sistema Operacional Android. O desen-

volvimento foi feito com utilização da IDE Eclipse, que é recomendada para o Androide pode ser vista na figura 30. A linguagem de programação utilizada foi o JAVA. Nãose precisou de nenhuma biblioteca externa para o desenvolvimento do software, usou-seapenas 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 seucelular, 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 secomunicar 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 implementando-se as interfaces CreateNdefMessageCallback e OnNdefPushCompleteCallback. Um exem-plo pode ser visto no algoritmo 3.10.

1 pub l i c c l a s s PassAct iv i ty extends Act i v i t y implementsCreateNdefMessageCallback , OnNdefPushCompleteCallback{

3 @Overridepub l i c NdefMessage createNdefMessage ( NfcEvent event ) {

5 Log . d(TAG, " Push Star t " ) ;byte [ ] s e r v e r = NFCLockerCrypt . hexStringToByteArray ( c f a . g e tAuto r i za t i on

( ) ) ;7 byte [ ] password = ge t In t en t ( ) . ge tSt r ingExtra ( BeamActivity .

INTENT_TAG_PASS) . getBytes ( Charset . forName ( "US−ASCII " ) ) ;ByteArrayOutputStream payload = new ByteArrayOutputStream ( ) ;

9

t ry {11 payload . wr i t e ( s e r v e r ) ;

i f ( password . l ength < 16) {13 f o r ( i n t i = 0 ; i< 16 − password . l ength ; i++)

payload . wr i t e ( ( byte ) 0) ;15 }

payload . wr i t e ( password ) ;17 payload . wr i t e ( NFCLockerCrypt .md5( payload . toByteArray ( ) ) ) ;

} catch ( IOException e ) {19 e . pr intStackTrace ( ) ;

}21

NdefMessage msg = new NdefMessage (23 new NdefRecord [ ] { new NdefRecord (

NdefRecord .TNF_EXTERNAL_TYPE ,25 " mobi . a2d :D" . getBytes ( Charset . forName ( "US−ASCII " ) ) ,

new byte [ 0 ] , NFCLockerCrypt . aesEncrypt ( payload .toByteArray ( ) , key , i v ) )

27 }) ;hand . postDelayed ( f i n i s h Th i s , DELAY) ;

29 re turn msg ;}

31

@Override33 pub l i c void onNdefPushComplete ( NfcEvent event ) {

Log . d(TAG, "NDEF PUSH Completo " ) ;


35 t h i s . f i n i s h ( ) ;}

37

}

Algoritmo 3.10: Algoritmo Para uso do Beam𝑇 𝑀 no Android

Sobrescreveu-se dois métodos das interfaces que foram utilizadas. O método cre-ateNdefMessage, implementado na linha 4 é utilizado para geração da mensagem MDEFnos padrões já mencionados. Pode-se ver que é especificado o tipo de gravação NDEF nalinha 25.

Na linha 28 pode-se ver a implementação de um timeout. A atividade deve serfechada caso fique aberta por muito tempo sem conseguir enviar uma mensagem NFC.

Para que esses métodos sejam chamados corretamente, deve-se utilizar a classeNfcAdapter, que faz interface com o chip NFC presente no celular.

1 // . . .NfcAdapter nfcAdapter ;

3 @Overrideprotec t ed void onCreate ( Bundle savedIns tanceState ) {

5 // . . .

7 nfcAdapter = NfcAdapter . getDefaultAdapter ( t h i s ) ;

9 nfcAdapter . setOnNdefPushCompleteCallback ( th i s , t h i s ) ;

11 nfcAdapter . setNdefPushMessageCallback ( th 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 sistemaoperacional que dispare um intent4.

Quando esse intent é disparado, filtra-se para saber se é um tipo que a aplicaçãodeve utilizar. O código

1 // . . .

4 Classe do Android que consiste em uma descrição abstrata de uma operação que deve ser executadaou de um evento acontecido

3.6. Aplicativo para Android 73

NfcAdapter nfcAdapter ;3 I n t e n t F i l t e r [ ] i n t e n t F i l t e r s A r r a y ;

S t r ing [ ] [ ] t e chL i s t sArray ;5 PendingIntent pendingIntent ;

// . . .7 nfcAdapter = NfcAdapter . getDefaultAdapter ( t h i s ) ;

9 nfcAdapter . setNdefPushMessageCallback ( nu l l , t h i s ) ;

11 pendingIntent = PendingIntent . g e tA c t i v i t y (th i s , 0 , new Intent ( th i s , g e tC la s s ( ) ) . addFlags ( Intent .

FLAG_ACTIVITY_SINGLE_TOP) , 0) ;13

I n t e n t F i l t e r ndef = new I n t e n t F i l t e r ( NfcAdapter .ACTION_TAG_DISCOVERED) ;

15 t ry {ndef . addDataType ( " ext " ) ;

17 ndef . addDataAthority ( " mobi . a2d " ) ;}

19 catch ( MalformedMimeTypeException e ) {throw new RuntimeException ( " f a l h a " , e ) ;

21 }

23 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 , } ;

25 t echL i s t sArray = new St r ing [ ] [ ] { new St r ing [ ] { NfcF . c l a s s . getName( ) } , new St r ing [ ] {NdefFormatable . c l a s s . getName ( ) } } ;

27 nfcAdapter . enableForegroundDispatch ( th i s , pendingIntent ,i n t en tF i l t e r sAr ray , t echL i s t sArray ) ;

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 deexpiração. Nesse momento, o aplicativo tentará buscar uma nova autorização a cada 10minutos se houver conexão disponível.

O aplicativo também tenta atualizar as autorizações sempre que a aplicação foraberta.

O algoritmo 3.13 mostra como é feita a conexão com o servidor em backgorund.

c l a s s Autor izat ionsTask extends AsyncTask<Void , Void , Str ing > {


2 // . . .@Override

4 protec ted St r ing doInBackground ( Void . . . params ) {try {

6 URL u r l = new URL(URL_GET_AUTORIZATION) ;HttpURLConnection conn = ( HttpURLConnection ) u r l

8 . openConnection ( ) ;conn . setDoOutput ( t rue ) ;

10 conn . setRequestMethod ( "POST" ) ;S t r ing postParams = " IdCe l l="

12 + URLEncoder . encode ( id_ce l l , "UTF−8" ) + "&IdLocker="+ URLEncoder . encode ( id_lock , "UTF−8" ) ;

14 Log . d(TAG, postParams ) ;conn . setFixedLengthStreamingMode ( postParams . getBytes ( ) . l ength ) ;

16 conn . setRequestProperty ( " Content−Type " ," a p p l i c a t i o n /x−www−form−ur lencoded " ) ;

18 conn . setRequestProperty ( " Accept−Charset " , "UTF−8" ) ;conn . setRequestProperty ( " Content−Length " ,

20 St r ing . valueOf ( postParams . getBytes ( ) . l ength ) ) ;conn . setFixedLengthStreamingMode ( postParams . getBytes ( ) . l ength ) ;

22

OutputStream out = conn . getOutputStream ( ) ;24 out . wr i t e ( postParams . getBytes ( "UTF−8" ) ) ;

out . f l u s h ( ) ;26 out . c l o s e ( ) ;

conn . connect ( ) ;28 InputStream i s = conn . getInputStream ( ) ;

S t r ing r e spo s ta = " " ;30 Scanner inStream = new Scanner ( conn . getInputStream ( ) ) ;

whi l e ( inStream . hasNextLine ( ) )32 r e spo s ta += inStream . nextLine ( ) + " \n " ;

Log . d(TAG, r e spo s ta ) ;34 conn . d i s connec t ( ) ;

r e turn r e spo s ta ;36 } catch ( Exception e ) {

Log . d(TAG, e . t oS t r i ng ( ) ) ;38 re turn n u l l ;

}40 }

42 protec ted void onPostExecute ( S t r ing param ) {i f ( param . startsWith ( "OK" ) ) {

44 St r ing [ ] r e sp = param . s p l i t ( " \n " ) ;setAut ( resp [ 1 ] ) ;

46 Log . d(TAG, " PostEx aut : "+resp [ 1 ] ) ;Log . d(TAG, " PostEx aut : "+ge tAuto r i za t i on ( ) ) ;

48 }

3.7. Aplicativo web 75

50 }

52 }

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 pelobrowser 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 fecha-dura, para isso foram necessárias a criação de 4 tabelas, uma para as fechaduras, outrapara os administradores, uma terceira para usuários e uma quarta tabela para guardarrelacionamentos. A figura 32 mostra o diagrama Entidade Relacionamento do banco dedados.


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 primeiratela, é 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 podegerenciar 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.

http://a2d.mobi/

http://a2d.mobi/AppNfc/

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 funcionandocorretamente. As próximas mostram testes de qualidade do software, mostrando as velo-cidades 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 usotípico, utilizando a serial do computador, um log de todos os dados que se passam pelacomunicação SPI entre o Arduino e o PN532. Dessa forma será possível ver todos osprotocolos sendo utilizados.

Não será comentado sobre todo o log, apenas sobre as partes importantes paraeste trabalho.

A primeira mensagem que se pode ver, é:

envio: 0 0 FF 5 FB D4 14 1 14 1 0x2 0x0resposta: 0 FF 2 FE D5 15

Ela apenas envolve configuração do SAM (Security Access Manager), sua sintaxepode ser vista na seção sobre o PN532.

Logo depois:

envio: 0 0 FF 2D D3 D4 8C 0 0 0 0 0 040 1 FE F BB BA A6 C9 89 0 0 0 00 0 0 0 FF FF 1 FE F BB BA A6 C989 0 0 6 46 66 6D 1 1 10 0 0x3B 0x0

resposta: 0 FF 21 DF D5 8D 25 1E D4 0 18 1E 121D 5E 12 68 EF 1E C1 0 0 0 32 46 666D 1 1 11 3 2 0 13 4 1 96

Esse comando, mostra o InitAsTarget. A resposta só é recebida quando o Initiatorestá próximo.

80 Capítulo 4. Resultados e Testes

Esses primeiros comandos não envolvem os protocolos de comunicação NFC deforma direta, apenas configurações essenciais para que o PN532 se comunique correta-mente.

No terceiro log pode-se ver:

envio 0 0 FF 2 FE D4 86 0xA6 0x0resposta 0 FF 5 FB D5 87 0 0 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 FC D4 8E 11 20 0x6D 0x0resposta: 0 FF 3 FD D5 8F 0

Pode-se ver o envio da mensagem NFC finalmente em:

envio: 0 0 FF 13 ED D4 8E 13 20 0 10 2 00 0 8 D1 1 4 44 0 0 0 1 0x36 0x0

resposta: 0 FF 3 FD D5 8F 0

Nessa mensagem pode-se distinguir:

preambulo PN532: 0 0 FFTamanho e CS do tamanho: 13 ED

Comando para o PN532: D4 8E

Agora pode-se ver no PDU

DSAP, Tipo PDU e SSAP: 13 20Byte de sequencia 0

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 0 8

Agora tem-se o cabeçalho NDEF

4.1. Comunicação NFC 81

Flag, tamanho do tipo D1 1Tamanho do payload 4

Tipo 44

Então pode-se ver, finalmente, a carga útil da mensagem, que nesse caso é apenaso ID do terminal (0x00000001).

Depois da mensagem enviada, pode ser visto o PDU tipo DISCONNECT.

Envia: 0 0 FF 4 FC D4 8E 11 60 0x2D 0x0Resposta: 0 FF 3 FD D5 8F 25

Agora o objetivo é conectar para receber uma mensagem NDEF, dessa forma oterminal deve ser iniciado como servidor, o Android deve pedir a conexão. Isso pode servisto em um comando getData mais adiante.

Envia: 0 0 FF 2 FE D4 86 0xA6 0x0Resposta: 0 FF 5 FB D5 87 0 11 20

Pode-se ver o PDU tipo Connect sendo recebido e logo depois a mensagem NDEFsendo recebida:

Envia: 00 00 FF 02 FE D4 86 A6 00Resposta: 00 FF 50 B0 D5 87 00 13 20 00 10 02

00 00 00 44 D1 01 40 44 B5 ED CB E06F 01 B0 9F 20 2D 60 48 94 AF 1B A6DE D9 B6 09 72 6F 8C 7A DC 64 08 18AE 51 AE 31 BD C8 2F D6 F3 0B AC 5F6F 39 36 E4 7E A9 D3 EF A9 26 15 2BDC 14 2E 4C 1A F0 66 EF 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 20Byte de sequencia 0

O cabeçalho do SNEP:

Versão e request: 10 2 (PUT)Bytes de tamanho 0 0 0 44


O cabeçalho do NDEF:

Flag, tamanho do tipo D1 1Tamanho do payload 40

Tipo 44

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 6408 18 AE 51 AE 31 BD C8 2F D6 F3 0B AC 5F 6F 39 36 E4 7E A9 D3 EF A9 26 15 2BDC 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 3092 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 1D84 84 EE F5 53 51 7A AE

pode-se ver, então, o protocolo criado:

Comando Id do Terminal Id do Aplicativo Expiração0 0 0 1 0 0 0 1 0 0 0 1 52 65 92 17

Assinatura do servidorFD 20 4F 21 10 A0 22 3A 7E 12 5B 30 92 14 FA 7

Senha0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Assinatura do celular99 47 FA 7C 97 C3 0A 1D 84 84 EE F5 53 51 7A AE

4.2 Testes da comunicação NFCPara 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 umteste criterioso com muitas medições e métodos estatísticos, apenas coletou-se a timestampde cada evento, calculou-se a diferença e tirou-se uma média. O resultado dessas medidaspodem ser vistas na tabela 19.

Todos esses testes foram feitos com utilização do Arduino MEGA. O celular utili-zado 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 Evento 1 Evento 2 Evento 3 Evento 4 Evento 5 Evento 61 0 36 164 1239 1248 22562 0 4 93 5073 5074 60953 0 3 73 5222 5223 62154 0 3 200 5747 5747 67455 0 4 89 5755 5756 66376 0 3 79 6183 6183 70407 0 3 76 1971 1972 29648 0 2 85 5107 5107 60849 0 3 84 3793 3794 457610 0 3 82 3821 3822 419011 0 2 73 1943 1943 275712 0 2 69 4856 4857 578613 0 2 118 4229 4229 505514 0 2 78 6553 6553 750015 0 3 87 3789 3789 4596

Média Total 0 5,0 96,7 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 chavesque devem ser utilizadas para criptografia já foram geradas.

∙ Evento 3: Atividade de Envio Iniciada. O tempo para isso acontecer pode variarde acordo com a quantidade de memória disponível no celular.

∙ Evento 4: Preparado para envio. O Android já recebeu requisição do ServidorSNEP 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 cripto-grafia acontecem de forma bem rápida no Android, principalmente para um métodorápido como o AES.

∙ Evento 6: Mensagem enviada. Foi recebida confirmação do Servidor SNEP que osdados foram enviados corretamente.

Pode-se perceber que em nenhum dos 15 testes houve falha na comunicação, o queindica estabilidade do sistema. Apesar disso, foram detectadas algumas falhas em outrostestes feitos e não documentados. Dessa forma, é sabido que o sistema pode apresentarinstabilidades 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 deque entre os eventos 1 e 4, o Arduino deve requisitar desconexão como cliente SNEP (o


Figura 36: Histograma dos dados da tabela 19

Android funciona como Servidor nessa fase) e requisitar conexão novamente, mas dessa vezcomo Servidor (após o evento 3, o Android deve funcionar como cliente SNEP). Apesar dobaixo número de amostras, o histograma apresentado na figura 36 mostra a alta variaçãono 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çãoconexão com a internet. Dessa vez agendou-se uma grande quantidade de conexões como objetivo de testar as velocidades de conexão utilizando WiFi e Dados móveis. Osresultados medidos podem ser vistos na tabela 20.

Para esse teste também foi utilizado o celular Sansung Galaxy SIII rodando osistema operacional Android Jelly Beam v4.1.2.

Tabela 20: Média de tempo de comunicação com o aplicativo WEB

Conexão N Evento 1 Evento 2 Evento 3 Evento 4 Evento 5WiFi 103 0 1 428 511 527

Dados móveis 82 0 1 3296 3545 3553*Valores em ms (mili segundos)

∙ Evento 1: Inicio da tentativa de conexão. Esse é o referencial utilizado, consideradoo tempo zero.

4.3. Comunicação com o servidor 85

∙ Evento 2: Parâmetros prontos para serem enviados. O request HTTP foi criadocom todas as variáveis que devem ser enviadas em POST.

∙ Evento 3: Conexão estabelecida. O servidor já respondeu com as informaçõesdesejadas.

∙ Evento 4: Desconectado. O socket de conexão foi finalizado.

∙ Evento 5: Dados gravados. Os dados recebidos foram descriptografados e guarda-dos no banco de dados do celular,

Vemos uma grande diferença no tempo de conexão para os diferentes tipos. Oteste mostra que pode ser utilizado o modelo alternativo de sempre buscar uma novaautenticação no servidor quando o dispositivo detectar proximidade com a fechadura. Otempo médio para uma conexão, mesmo da forma mais lenta, ainda é menor que o tempodesde 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 avalidade 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 celulare 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 NFCPN532, que foi testado em três plataformas diferentes, todas baseadas na plataformade prototipagem Arduino. Para que isso fosse viável, implementou-se uma bibliotecade aplicação dos protocolos NFC conhecidos e já utilizados pelos smartphones com essatecnologia.

Além disso, criou-se bibliotecas de criptografia e segurança para o Arduino, queaté então não estavam disponíveis, elaborou-se um aplicativo para o sistema operacio-nal Android e produziu-se um aplicativo Web para ser utilizado para administração dediferentes fechaduras.

Na elaboração da solução técnica para o projeto, duas grandes dificuldades foramencontradas.

A primeira delas interfere nos requisitos funcionais do sistema e envolve a elabo-raçã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 co-municação. A frequência de modulação, a velocidade de transmissão de dados e os tiposde protocolos de baixo nível são exemplos disso. Foram utilizados os códigos fontes do sis-tema operacional Android além dos documentos técnicos para que todos esses parâmetrospudessem ser determinados de forma correta.

A implementação dos protocolos de mais alto nível foi possível graças a grandequantidade de informação disponível na internet e a documentação bem detalhada decada um deles presente no Fórum NFC.

A segunda grande dificuldade envolveu um requisito não funcional muito impor-tante para o sistema: a criptografia. A maioria dos protocolos de autenticação utilizacriptografia com chave pública e privada para geração de assinaturas, isso não foi possívelem função da complexidade do algoritmo implementado e a capacidade de processamentoe memória RAM do hardware utilizado (Arduíno).

Apesar de todas as dificuldades, conseguiu-se atender os requisitos do sistemapara a finalidade do trabalho. O NFC se mostrou uma maneira prática e intuitiva para oprojeto proposto.

88 Capítulo 5. Conclusão

Os testes que se referem a comunicação NFC mostram algumas falhas e perda desincronia. Elas se devem ao modo como as bibliotecas que implementam essa tecnologiano Android funcionam, uma vez que foram feitas apenas para comunicação de uma viaentre 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 criaralgoritmos próprios para essa finalidade.

Apesar dos protocolos de segurança serem bem definidos e atenderem aos requisi-tos, o sistema falha quanto ao modelo de armazenamento das chaves de segurança. Casoum invasor consiga fazer um acesso direto a EEPROM do arduino, ele poderá facilmenteencontrar as senhas.

Aplicar engenharia reversa no código executável também pode se apresentar ex-tremamente 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 aplicabilidadeainda não é disponível mas deve estar presente como funcionalidade adicional naspróximas atualizações da API.

∙ Utilização de métodos de HASH mais seguros que o MD5. Apesar deter sido considerado seguro para o contexto deste trabalho, alguns métodos, comoSHA1 (STANDARD, 1993), possuem uma resistência a colisão comprovadamentemuito maior que o utilizado.

∙ Implementação de criptografia assimétrica apenas para autenticação. Paraessa aplicação a autenticação é mais importante que o próprio sigilo. A implemen-taçã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çãode chaves públicas e privadas.

∙ Reimplementação do método de gravação das chaves na EEPROM. Aschaves se tornam facilmente identificadas na EEPROM devido a sua aleatoriedade.A ATMEL desenvolveu uma cryptomemory, uma EEPROM com a única finalidadede gravar chaves, que pode ser utilizada adicionalmente. Poderia-se também adici-onar 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 dohardware 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. Acessoem: outubro de 2013. Citado 2 vezes nas páginas 39 e 40.

BELLARE, M.; KILIAN, J.; ROGAWAY, P. The security of the cipher block chainingmessage 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 napá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áginas44 e 65.

FIPS, P. 197, advanced encryption standard (aes). National Institute of Standards andTechnology, 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 napá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ágina38.

NFC - FORUM. Logical Link Control Protocol Technical Specification. 2011. Disponívelem: 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.

http://developer.android.com

http://www.visionmobile.com/DevEcon3Q13

http://www.visionmobile.com/DevEcon3Q13

http://www.google.com/wallet/

http://www.idc.com/getdoc.jsp?containerId=prUS24257413

http://www.idc.com/getdoc.jsp?containerId=prUS24257413

http://investincotedazur.com/en/newsletter/nfc-major-samsung-visa-partnership-announced-at-the-mwc-2013&artid=act11035



http://www.nfc-forum.org/specs/spec_license/document_form/custom_layout?1383275628106





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ívelem: 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 vezesnas páginas 55 e 60.

RIVEST, A. S. R.; ADLEMAN, L. A method for obtaining digital signatures andpublic-key cryptosystems. Communications of the ACM, v. 21, p. 120–126, 1978. Citado2 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 naspá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. USDepartment 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.]: SamsPublishing, 2003. Citado na página 75.





http://www.sony.net/Products/felica/

http://www.sony.net/Products/felica/

Apêndices

95

APÊNDICE A – Esquemático do PrimeiroProtótipo do Terminal

97

APÊNDICE B – Esquemático do ProtótipoFinal do Terminal

Proposta para controle de acesso físico seguro baseada em ...€¦ · baseada em Near Field...

Documents

Transcript of Proposta para controle de acesso físico seguro baseada em ...€¦ · baseada em Near Field...