Danilo Souza Lima. Proposta para controle de acesso físico seguro baseada em Near Field Communication (NFC) e Android

Transcrição

1 Danilo Souza Lima Proposta para controle de acesso físico seguro baseada em Near Field Communication (NFC) e Android São Carlos 2013

2

3 Danilo Souza Lima Proposta para controle de acesso físico seguro baseada em Near Field Communication (NFC) e Android Trabalho de Conclusão de Curso apresentado ao departamento de Engenharia elétrica da Escola de Engenharia de São Carlos - USP Universidade de São Paulo USP Escola de Engenharia de São Carlos EESC Orientador: Evandro L. L. Rodrigues São Carlos 2013

4 AUTORIZO A REPRODUÇÃO TOTAL OU PARCIAL DESTE TRABALHO, POR QUALQUER MEIO CONVENCIONAL OU ELETRÔNICO, PARA FINS DE ESTUDO E PESQUISA, DESDE QUE CITADA A FONTE. L732p Lima, Danilo Souza Proposta para controle de acesso físico seguro baseada em Near Field Communication (NFC) e Android / Danilo Souza Lima; orientador Evandro L. L. Rodrigues. São Carlos, Monografia (Graduação em Engenharia Elétrica com ênfase em Eletrônica) -- Escola de Engenharia de São Carlos da Universidade de São Paulo, NFC. 2. Arduino. 3. Android. 4. Criptografia. 5. Autenticação. I. Título.

5 - FOLHA DE APROVAÇAO Nome: Danilo Souza Lima Título: "Segurança e controle de acesso de pessoas com utilização de dispositivo móvel com NFC" Trabalho de Conclusão de Curso defendido e aprovado em 21 I_li 120.1d, com NOTA Q3 C--~Ullte, -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

6

7 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 L A TEX, Ao Rodrigo, pelas excelentes dicas de Hardware, E ao professor Evandro, pelas ótimas orientações e ricas discussões durante nossas "Walking Meetings".

8

9 A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. (Douglas Adams, Mostly Harmless)

10

11 Resumo O trabalho de conclusão de curso apresentado elabora uma proposta para controle de acesso físico segura e intuitiva com a utilização de um aparelho celular. Para garantir a segurança e intuitividade do processo utilizou-se o Near Field Communication, que é uma comunicação via rádio-frequência com área de ação limitada em no máximo 10cm. O objetivo final do projeto foi propor um método completo para elaboração do sistema de controle de acesso, que deve servir como prova de conceito e não como um produto comercial. Ele envolve a elaboração de um terminal de acesso baseado em Arduino com Shield NFC além da criação de um aplicativo móvel para Android e um website para gerenciamento. As principais dificuldades do projeto foram a implementação dos protocolos de comunicação peer-to-peer NFC em baixo nível e a implementação da segurança do sistema baseada em algoritmos de criptografia. Foram utilizadas as linguagens de programação C++, JAVA e PHP e os softwares envolvidos foram elaborados utilizando o modelo de prototipagem. O trabalho foi testado utilizando-se um celular Galaxy SIII da Samsung, e o tempo de comunicação com o terminal foi medido em torno de 5,5s. O NFC se mostrou uma maneira prática e intuitiva para o projeto proposto. Com os resultados alcançados foi possível identificar caminhos para a evolução do projeto conforme podem ser observados no capítulo de conclusão. Palavras-chaves: NFC, Arduino, Android, Criptografia, Autenticação

12

13 Abstract The work presented here intend to propose a tool for physical access control that is safe and intuitive. For that end, the process makes use of Near Field Communication, that is a Radio Frequency communication with a limited range of no more than 10cm. The main goal of the project is to propose a method to be used as a proof of concept and not as a stand alone comercial solution. It envolves the elaboration of a physical access terminal based on the Arduino board with NFC capability and the creation of an Android app and a website for administration. The dificulties associated with the work were the implementation of low level protocols of NFC peer-to-peer comunication and the implementation of the security of the system based on well-known public criptographic algorithms The programing languages that were used on the elaboration of the softwares were C++, JAVA and PHP and they were made by using the process of prototyping. The comunication was testes by using a Samsung Galaxy SIII mobile phone and time needed for the comunication was measured in about 5.5s. The NFC was a proved to be a effective tool for a praticity and intuitivity in the project. It was possible to indetify ways for improvenement of the work that can be seen in the conclusion chapter. Key-words: NFC, Android, Arduino, Criptography, Autentication.

14

15 Lista de ilustrações Figura 1 Google Wallet Figura 2 Comunicações Envolvidas Figura 3 OSI vs NFC Figura 4 Funcionamento do NFC Figura 5 Modulação Digital OOK Figura 6 Arquitetura LLCP Figura 7 Representação de um PDU Figura 8 Representação do SNEP Figura 9 Mensagem NDEF Figura 10 Tela de confirmação de envio de dados do Android Beam Figura 11 O modelo de criptografia Figura 12 Estágios intermediários do DES Figura 13 Troca de chave de Diffie-Hellman Figura 14 Ataque Man In The Middle Figura 15 Autenticação baseada em chave compartilhada Figura 16 Diagrama esquemático Figura 17 Arduino R3 UNO Figura 18 Arduino MEGA Figura 19 Arduino DUE Figura 20 Shield NFC para o Arduino Figura 21 Shield de prototipação para Arduino Figura 22 Relay 5V Figura 23 Primeiro Protótipo do Terminal Figura 24 Blocos do sistema desmontado Figura 25 Placa Montada Figura 26 Sistema em funcionamento Figura 27 IDE para o Arduino Figura 28 IDE do Code::Blocks Figura 29 Esquema de geração de chave para criptografia Figura 30 IDE Eclipse para programação em Android Figura 31 IDE - NETBeans Figura 32 Diagrama Entidade-Relacionamento Figura 33 Primeira tela do aplicativo WEB Figura 34 Administração das Fechaduras Figura 35 Modificar Status de usuários

16 Figura 36 Histograma dos dados da tabela

17 Lista de tabelas Tabela 1 Formato para um PDU tipo PAX Tabela 2 Formato para um PDU tipo CONNECT Tabela 3 Formato para um PDU tipo DISC Tabela 4 Formato para um PDU tipo I Tabela 5 Formato para um PDU tipo I Tabela 6 Formato de uma solicitação SNEP Tabela 7 Formato de uma resposta SNEP Tabela 8 Comandos de solicitação Tabela 9 Comandos de Resposta Tabela 10 Formato do Identificador de uma Gravação NDEF Tabela 11 Características dos três Arduinos trabalhados Tabela 12 Sintaxe do Comando InitAsTarget Tabela 13 Sintaxe para o comando GetData Tabela 14 Sintaxe para a resposta do comando GetData Tabela 15 Sintaxe para o comando SetData Tabela 16 Sintaxe para a resposta do comando SetData Tabela 17 Sintaxe do protocolo criado Tabela 18 Sintaxe autorização do servidor Tabela 19 Testes de comunicação NFC Tabela 20 Média de tempo de comunicação com o aplicativo WEB

18

19 Lista de Algoritmos 3.1 Algoritmo de Conexão como Cliente SNEP Algoritmo de Conexão como Servidor SNEP Algoritmo de recepção de dados Algoritmo de Envio de dados Algoritmo de PUSH Algoritmo de PULL Uso da Biblioteca AES Uso da Biblioteca HASH MD Algoritmo de Envio de dados Algoritmo Para uso do Beam T M no Android Segundo algoritmo Para uso do Beam T M no Android Recebimento de mensagens NDEF com Android Recebimento de mensagens NDEF com Android

20

21 Lista de abreviaturas e siglas NFC RFID NDEF DES RSA P2P AES Near Field Communication. Radio Frequency IDentification. NFC Data Exchange Format. Data Encryption Standard. Rivest, Shamir e Adleman. (Criadores desse método de criptografia) peer-to-peer. Advanced Encription Standard. MD5 Message Digest 5. OOK LLCP SHA PHP HTML SNEP OSI On-Off key. Link Layer Control Protocol. Secure Hash Algorithm. PHP: Hypertext Preprocessor. HyperText Markup Language. Simple NDEF Exchange Protocol. Open Systems Interconnection.

22

23 Lista de símbolos E k D k OU EXCLUSIVO. Método de criptografia com a chave k. Método de decriptografia com a chave k.

24

25 Sumário 1 Introdução Embasamento Teórico Near Field Communication Histórico Funcionamento Camada Física (Hardware) Camada de enlace de Dados Camada de Aplicação O sistema operacional Android Aplicativos Android Android e NFC Android Beam T M Dispositivos com chip NFC Segurança e criptografia Métodos de criptografia Método DES Método de compartilhamento de Chave de Diffie-Hellman Métodos de chave pública Algorítmos de HASH criptográficos Autenticação Autenticação baseada em chave compartilhada Autenticador de uma mensagem Metodologia e Implementação Descrição do Projeto Especificação de Requisitos do Projeto Requisitos Não-funcionais Requisitos Funcionais Hardware para a fechadura O Arduino O PN Primeiro Protótipo O protótipo Final Software para o Arduino Implementação da Biblioteca para comunicação peer-to-peer NFC. 60

26 Comunicação com o PN LLCP SNEP NDEF Implementação da Criptografia Implementação da Biblioteca AES Implementação da biblioteca MD Algoritmo do Sistema Completo Protocolo criado para comunicação e autenticação Mensagem e assinatura do servidor Assinatura do Aplicativo Aplicativo para Android Envio de uma mensagem NDEF com o Beam T M Recebimento de uma mensagem NDEF Comunicação com o Servidor Aplicativo web Banco de Dados A interface Resultados e Testes Comunicação NFC Testes da comunicação NFC Comunicação com o servidor Conclusão Referências Apêndices 93 APÊNDICE A Esquemático do Primeiro Protótipo do Terminal APÊNDICE B Esquemático do Protótipo Final do Terminal

27 25 1 Introdução Desde que surgiram os primeiros aparelhos celulares, uma forte tendência foi observada no mercado, a substituição de outros aparelhos que eram comuns ao nosso dia à dia. Calculadoras, agendas telefônicas, calendários e câmeras fotográficas, por exemplo, hoje são encontrados mais facilmente em sua forma digital, reunidos em um único aparelho. O telefone móvel já é utilizados para muito mais funções que quando foi proposto comercialmente em Essa tendência do uso de apenas uma estrutura para prover diversos serviços é chamada Convergência Tecnológica, e um exemplo atual são os novos métodos de pagamento de mercadorias, como o Google Wallet (GOOGLE..., 2013) que pode ser vista na figura 1. Dessa forma, o dispositivo móvel pode substituir, também, um cartão de crédito, ou uma carteira. Figura 1: Google Wallet: Pagamento via celular Fonte: A motivação deste trabalho é incluir no celular uma nova função além destas muitas que já foram citadas, a de dispositivo de controle de acesso. É claro que não há objetivo de implementar um produto comercial, mas de servir como uma prova de conceito e abrir um leque de possibilidades para futuras implementações. Dois elementos básicos utilizados nesse trabalho são o celular, utilizado como dispositivo de controle de acesso, e o terminal de controle de acesso. Para confecção deste, foi decidido por utilizar uma placa baseada no Arduino, pela facilidade de encontrar periféricos e pela quantidade de bibliotecas disponíveis.

28 26 Capítulo 1. Introdução A comunicação entre o terminal e o celular deve ser feita de forma segura e intuitiva. A ideia central é ter seu acesso garantido apenas aproximando o celular do terminal, isso é possível graças a comunicação NFC (KUMAR, 2011), acrônimo para Near Field Communication, que será discutido nas próximas seções. O NFC já é utilizado em celulares para várias funções, a principal delas é a leitura de cartões baseados nesta tecnologia, que podem funcionar como cartões de visita ou de informações de murais eletrônicos. Para implementação de um sistema mais completo, deve-se incluir, também, a possibilidade de gerenciamento das autorizações através da internet. A figura 2 mostra um diagrama de todas as comunicações envolvidas no projeto. Figura 2: Comunicações Envolvidas Para que todos os elementos do projeto funcionem corretamente, é necessário que exista um protocolo de comunicação seguro e unificado. Este protocolo deve envolver algoritmos criptográficos para garantir segurança do sistema. Ao decorrer desse trabalho serão apresentadas todas as etapas de elaboração do projeto, que inclui: Projeto e montagem do hardware para ser utilizado no terminal. Criação do software para comunicação via NFC. Criação de bibliotecas para criptografia e segurança das informações. Confecção de um aplicativo móvel para o sistema operacional Android, que deve funcionar como interface entre o usuário e a fechadura. Elaboração de um aplicativo web, onde o administrador do sistema possa gerenciar acessos individuais ao terminal.

29 27 Elaboração de um protocolo de segurança para comunicação entre todas as partes que formam o sistema.

30

31 29 2 Embasamento Teórico 2.1 Near Field Communication O NFC, acrônimo para Near Field Communication, é um conjunto de padrões de comunicação de rádio entre dois dispositivos a uma curta distancia, geralmente não mais que alguns centímetros, o que o torna muito recomendado em transações que exigem certo nível de segurança. (KUMAR, 2011; HASELSTEINER; BREITFUSS, 2006). Esses padrões foram criados baseados no já existente RFID, acrônimo para Radio Frequency IDentification. Eles incluem protocolos de comunicação e formatos de dados definidos pelo Fórum NFC, criado em 2004 por Nokia, Sony e Philips, e hoje já possui mais de 160 membros, incluindo Samsung, Google, RIM, Microsoft, Intel, Visa, MasterCard e outros. (NFC - FORUM, 2013a) Histórico A história do NFC começa em 1983, em suas raízes, com o surgimento do RFID 1. O NFC pode ser visto como uma aplicação restrita do RFID, com padrões e especificações bem definidos e com o alcance diminuído, por motívos de segurança. Já em 2004, vista a necessidade da criação e atualização desses padrões e especificações, foi criado o Fórum NFC. Depois disso logo começaram a surgir os primeiros celulares possuidores dessa tecnologia, começando com o Nokia Em 2009 foi criada uma nova forma de comunicação baseada nessa tecnologia, o peer-to-peer, e logo em seguida surgiu o primeiro Android com capacidade NFC, O Galaxy Nexus 2. O uso do NFC só aumentou desde então com o surgimento de Smart Tags e dos métodos de pagamento utilizando celular. Nesse ano, Samsung e VISA anunciaram uma parceria para desenvolvimento de métodos de pagamento via celular (MAJOR..., 2013), o que promete aumentar o número de dispositivos com chip NFC embutido 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 passivo para identificação e autenticação. 2 Surgido de uma parceria entre Samsung e Google (desenvolvedora do sistema operacional de código aberto Android).

32 30 Capítulo 2. Embasamento Teórico Emulação de cartão: Onde um dispositivo se passa por uma tag ou cartão NFC passivo para responder a um pedido de um iniciador ativo. Leitura e Gravação de cartão: Onde um iniciador pode ler ou gravar alguma informação em um dispositivo passivo. Peer to peer: Onde dois dispositivos NFC ativos se comunicam entre si. Neste trabalho focou-se no uso da comunicação peer-to-peer uma vez que alguns dos sistemas operacionais móveis que suportam NFC (incluindo o Android) não permitem o modo de Emulação de Cartão. Para explicar seu funcionamento, as seguintes sessões fazem um paralelo entre as camadas do NFC e as do Modelo OSI. Apenas 3 camadas do modelo OSI são relevantes, a camada física, a camada de enlace de dados e a camada de aplicação. Como é mostrado na figura 3. Figura 3: Comparação entre o Modelo OSI e o NFC Camada Física (Hardware) O NFC funciona usando a indução magnética. O iniciador emite uma pequena corrente elétrica em sua antena, esta, cria um campo magnético que ocupa o espaço entre o iniciador e o alvo. Esse campo é recebido por uma bobina na antena do dispositivo, onde é convertido novamente para sinais elétricos para que seja possível a comunicação de dados. O esquema dessa comunicação pode ser visto na figura 4.

33 2.1. Near Field Communication 31 Caso o alvo seja um dispositivo passivo 3 ele usa a própria corrente que foi induzida pelo iniciador para se alimentar, responder e enviar alguma informação. Casa seja ativo, ele utiliza sua própria alimentação para responder ao iniciador. Figura 4: Funcionamento do NFC. Fonte: Modulação e transferência de Dados A modulação consiste em modificar as características de uma onda para transferir informação. Essa onda é chamada de portadora. Um exemplo de modulação pode ser visto na figura 5. A modulação OOK (on-off key) consiste em um período de duração fixa onde o sinal está em 1 (HIGH) ou 0 (LOW). Utilizando uma modulação digital como essa, a demodulação pode ser feita facilmente com o uso de um diodo e um capacitor. Também é implementado um extrator de clock do sinal, para ser utilizado nos blocos lógicos do circuito. (NFC - FORUM, 2013b). Figura 5: Representação da modulação Digital OOK. Fonte: No NFC, o sinal é enviado modulando-se digitalmente uma portadora de 13.56MHz, mas como ele pode ser aplicado em comunicações passivas, o sinal enviado é usado para 3 São chamados dispositivos passivos aqueles que não possuem uma própria fonte de alimentação, pode ser um cartão ou Tag NFC.

34 32 Capítulo 2. Embasamento Teórico alimentar o dispositivo, dessa forma a modulação OOK se torna inviável para uma mensagem com muitos zeros em sequência, então outros modelos mais complexos são utilizados (NFC - FORUM, 2013b) Camada de enlace de Dados A camada de enlace de dados (segunda camada do modelo OSI) do NFC para comunicações peer to peer é definida pelo NFC Fórum através da especificação técnica do LLCP (Logical Link Control Protocol). Podemos citar como principais aspectos do LLCP: (NFC - FORUM, 2011) Define como dois dispositivos dentro do alcance podem reconhecer implementações compatíveis de LLCP, estabelecer a conexão e desativar quando for necessário. Define o MAC (Media Access Control) com o objetivo de evitar colisão de dados. Tipicamente, dois dispositivos NFC em modo peer to peer, operam de forma que um deles seja o mestre, chamado Initiator, que é capaz de enviar e requisitar dados para o escravo, chamado target. O LLCP não provê nenhum tipo de segurança entre os dois pontos, a segurança deve ser implementada nas outras camadas. É capaz de acomodar inúmeros protocolos de nível maior ao mesmo tempo. Sua arquitetura pode ser vista na figura 6. A LLCP define, como unidade básica, a structure PDU (Payload Data Unit), além de seus tipos e usos. A próxima seção fala um pouco sobre os PDUs. PDU O formato de um PDU é constituído de um cabeçalho, que pode conter dois ou três bytes, e do payload. O formato é mostrado na figura 7. Os elementos que constituem um PDU são: Dois campos de endereço (cada um com 6 bits), DSAP (Destination Service Access Point) e SSAP (Source Service Access Point). O DSAP deve informar o serviço do ponto de acesso para qual a informação foi transmitida. O SSAP deve informar o Serviço do ponto de acesso onde essa informação foi originada. Um campo de Tipo do PDU com tamanho de 4 bits. Esse campo deve identificar a sintaxe e a semântica utilizada nos outros campos do PDU e deve ter um dos valores

35 2.1. Near Field Communication 33 Figura 6: Representação da arquitetura da LLCP. Fonte: Figura 7: Representação de um PDU. Fonte: especificados pelo NFC-Fórum. Para contexto desse trabalho, apenas comentaremos sobre alguns desses tipos. Um capo de sequência formado por 0 ou 1 bytes, está presente apenas em alguns tipos de PDU. O campo de sequência, quando presente, está dividido em 4 bits para sequência de envio (nos bits mais significantes), e 4 bits para a sequência de recepção (nos 4 bits menos significantes). Um campo de informação formado por 0 ou N bytes, o tamanho desse campo depende do tipo de PDU e o máximo valor de N depende do serviço que receberá a informação.

36 34 Capítulo 2. Embasamento Teórico Tipos de PDU Serão comentados apenas alguns tipos de PDU s, os mais relevantes para o contexto deste trabalho. PDU tipo PAX O PDU tipo PAX é usado para trocas de parâmetros no que diz respeito à configuração do enlace LLCP. O parâmetro de sequência não é usado para esse tipo de PDU e o campo de informação deve conter os parâmetros de configuração. O formato para os parâmetros de configuração se encontram fora do contexto desse trabalho. Para um PDU tipo PAX, os dois campos de endereço devem ser 0, o formato de um PDU tipo PAX é visto na tabela 1. Tabela 1: Formato para um PDU tipo PAX DSAP PTYPE SSAP INFORMAÇÂO Lista de parâmetros PDU tipo CONNECT O PDU tipo Connect é usado para solicitação de uma conexão. Ele deve conter ambos os campos de endereço e pode conter o campo de informações para parâmetros de conexão. O formato para esses não se encontram no contexto deste trabalho. O formato para um PDU do tipo connect pode ser visto na tabela 2: Tabela 2: Formato para um PDU tipo CONNECT DSAP PTYPE SSAP INFORMAÇÃO DDDDDD 0100 SSSSSS Lista de parâmetros (opcional) PDU tipo DISC O PDU tipo DISC (Disconnect) Serve para terminar uma conexão, ele não deve possuir o octeto de sequencia nem os bytes de informação. O formato é mostrado na tabela 3. Tabela 3: Formato para um PDU tipo DISC DSAP PTYPE SSAP DDDDDD 0101 SSSSSS PDU tipo I O PDU do tipo I (Information) é usado para transferir dados pelo enlace LLCP. Ele deve possuir os bits de sequência e os bytes de informação. O formato pode ser visto na tabela 4.

37 2.1. Near Field Communication 35 Tabela 4: Formato para um PDU tipo I DSAP PTYPE SSAP Sequência INFORMAÇÃO DDDDDD 1100 SSSSSS Seq. envio Seq. recebimento Dados PDU tipo SYMM O PDU do tipo SYMM (Symmetry) esse tipo de PDU é usado pela LLCP para quando nenhum outro PDU está disponível para ser mandado, apenas para garantir a simetria do protocolo. Pode-se ver o formato na tabela 5. Tabela 5: Formato para um PDU tipo I DSAP PTYPE SSAP Sequência INFORMAÇÃO DDDDDD 1100 SSSSSS Seq. envio Seq. recebimento Dados Camada de Aplicação No nível da aplicação, um dos protocolos utilizados para troca de unidades de dado pelo NFC é o SNEP (Simple NDEF Data Exchange). Esses dados são enviados no formato de menssagens NDEF (NFC Data Exchange Format). Esses tópicos serão discutidos com mais profundidades nas subseções seguintes. Outros protocolos utilizados para comunicação via NFC peer-to-peer não serão abordados nem mencionados no contexto desse trabalho. Protocolo SNEP O SNEP (NFC - FORUM, 2013c) é um protocolo de solicitação e resposta (request/response) onde o cliente faz uma solicitação ao servidor e espera uma resposta. Caso o tamanho de uma solicitação ou uma resposta seja maior que o máximo possível para o protocolo inferior, no caso, o LLCP mencionado na seção anterior, ela deve ser dividida em fragmentos. A figura 8 mostra um exemplo de comunicação baseado no protocolo SNEP. Uma solicitação SNEP tem o formato mostrado na tabela 6 e a resposta possui o formato especificado na tabela 7. Tabela 6: Formato de uma solicitação SNEP Cabeçalho SNEP Versão Solicitação Tamanho Carga útil 1 byte 1 byte 4 bytes Tamanho especificado O significado dos campos vistos nas tabelas 6 e 7 é:

38 36 Capítulo 2. Embasamento Teórico Figura 8: Representação de uma comunicação utilizando o protocolo SNEP. Fonte: Tabela 7: Formato de uma resposta SNEP Cabeçalho SNEP Versão Resposta Tamanho Carga útil 1 byte 1 byte 4 bytes Tamanho especificado Versão indica o formato da mensagem que está sendo enviada e a capacidade do dispositivo que a enviou de entender comunicações futuras. É formado 2 números inteiros de 4 bits, o primeiro para a maior versão e o segundo para menor versão aceita. Solicitação indica a ação que deve ser executada no servidor, a tabela 8 mostra os tipos de comandos aceitos. Resposta indica o resultado da ação solicitada ao servidor. A tabela 9 mostra os comandos utilizados como resposta. Tamanho são 4 bytes que indicam o tamanho da carga útil, são utilizados 4 bytes, o que indica que o máximo tamanho de uma mensagem NDEF é FFFFFFFFh isso é, bytes.

39 2.1. Near Field Communication 37 Carga útil é a parte da mensagem onde vai a mensagem NDEF, a ser discutida um pouco mais a frente Tabela 8: Comandos de solicitação Código Comando Descrição 00h Continue Continuar enviando os próximos fragmentos da mensagem (esse comando não será importante no contexto deste trabalho). 01h Get Requisita do servidor uma mensagem NDEF de resposta deve conter na carga útil o tamanho máximo da mensagem a ser recebida e uma mensagem NDEF que identifica o tipo de mensagem a ser recebida. 02h Put Solicita que o servidor aceite uma mensagem NDEF que é enviada na carga útil. 7Fh Reject Solicita que o servidor não envie os próximos fragmentos da mensagem. Formato NDEF O NDEF (NFC - FORUM, 2006) é o formato que define a forma como uma mensagem será encapsulada para transferência, ele pode ser usado tanto para tags passivas quanto para dispositivos ativos 4. Para explicar como funciona uma mensagem NDEF serão usadas as seguintes definições: Mensagem NDEF: Composta por uma ou mais gravações NFC. Gravação NDEF: Mensagem a ser transmitida, formada basicamente por um cabeçalho e uma carga útil. Cabeçalho: Composto de um identificador, o tamanho da carga útil e o tipo da carga útil. Carga Útil: Dados que se deseja transmitir. 4 Existem vários outros formatos de dados ultilizados. Como o NDEF é largamente utilizado pela maioria dos sistemas operacionais móveis graças a escolha do protocolo SNEP para a grande parte das aplicações NFC, esse trabalho se limitará a esse formato

40 38 Capítulo 2. Embasamento Teórico Tabela 9: Comandos de Resposta Código Comando Descrição 80h Continue Continuar enviando os próximos fragmentos da mensagem (esse comando não será importante no contexto desse trabalho). 81h Success Requisita do servidor uma mensagem NDEF de resposta deve conter na carga útil o tamanho máximo da mensagem a ser recebida e uma mensagem NDEF que identifica o tipo de mensagem a ser recebida. C0h - C2h Erro Códigos para alguns tipos de erro, como mensagem mal formulada ou excesso de dados E0h - E1h Não Suportado Indica que a versão ou o tipo de solicitação não é suportado. A figura 9 mostra o encapsulamento de uma mensagem NDEF. Figura 9: Mensagem NDEF. Fonte: O identificador de uma mensagem NDEF tem seu formato mostrado na tabela 10 MB (Message Begining): Se for 1 indica que essa é a primeira gravação na mensagem.

41 2.2. O sistema operacional Android 39 Tabela 10: Formato do Identificador de uma Gravação NDEF MB ME CF SR IL TNF ME (Message End): Se for 1 indica que essa é a ultima gravação da mensagem. CF (Chunck Record): Indica que essa é uma gravação incompleta e apenas parte da carga útil está presente. SR (Short Record): Caso esteja em 1, indica que essa é uma gravação pequena e o campo Tamanho possui apenas um byte. IL (ID Length:) Indica que existe um octeto para o tamanho do ID e um campo para o ID da gravação do tamanho indicado. TNF (Type Name Format): Indica o formato do campo tipo. 2.2 O sistema operacional Android O Android (ANDROID..., 2013) é um sistema operacional baseado em Linux e desenvolvido primariamente para dispositivos móveis com touchscreen, como tablets e celulares. Ele foi desenvolvido primeiramente pela Android Inc., que em 2005 foi comprada pela Google. O Android é open-source e o código é disponibilizado pela Google sob a licença Apache. (ANDROID..., 2013). O fato de ter código aberto o tornou muito popular entre os desenvolvedores e, segundo o site visionmobile (DEVELOPER..., 2013), é utilizado por 71% dos desenvolvedores de aplicativos móveis. Esses fatores contribuíram bastante para tornar o Android a plataforma móvel mais utilizada no mundo. Segundo o site IDC (IDC..., 2013), no segundo trimestre de 2013, o android possuía 79,3 % de Market Share Aplicativos Android Os aplicativos desenvolvidos para Android são escritos em linguagem JAVA utilizando o Android SDK, que inclui uma ferramenta de Debug, bibliotecas e um emulador. A maior parte dos aplicativos desenvolvidos são lançados na Google Play, a loja de aplicativos da Google, mas o sistema permite que um usuário baixe, instale e utilize aplicativos por outros meios. (ANDROID..., 2013)

42 40 Capítulo 2. Embasamento Teórico Android e NFC O sistema operacional Android possui sua própria biblioteca para que desenvolvedores consigam usar os recursos NFC do celular. Por motivos de segurança, não é permitido operá-lo em baixo nível. As primeiras versões do Android apenas suportavam o modo de leitura e escrita para NFC, o modo de emulação de cartão ainda não foi disponibilizado para o público e o modo peer-to-peer é disponibilizado apenas através do Android Beam T M (ANDROID..., 2013) que será discutido na próxima subseção. T M Android Beam Essa é uma maneira simples para transmitir mensagens através do NFC entre dois dispositivos. O Beam T M foi criado para fazer troca de pequenas informações entre dois dispositivos Android apenas tocando um no outro, e isso acarreta algumas limitações que são tratadas como restrições de projeto: (ANDROID..., 2013) A aplicação que está enviando uma mensagem deve estar em foreground, aberta e visível para o usuário. T M Os dados enviados devem ser encapsulados em uma mensagem NDEF. O Beam apenas suporta SNEP sobre LLCP. Uma mensagem só pode ser enviada com a autorização do usuário. Isso é feito através de uma tela com a mensagem: "Toque para transferir". Ela pode ser vista na figura 10. No momento não é possível enviar dados via NFC sem que o usuário toque a tela em confirmação Dispositivos com chip NFC Com o crescimento do NFC, muitos celulares android possuem chip NFC embutidos. A google anunciou durante o evento "Google I/O"desse ano, que cerca de 1 milhão de dispositivos Android com essa funcionalidade são ativados a cada semana. Esses números tendem apenas a crescer, segundo a STRATEGY ANALITICS, no final de 2013 serão em torno de 400 milhões de smartphones com NFC (cerca de um terço).

43 2.3. Segurança e criptografia 41 Figura 10: Tela de confirmação de envio de dados do Android Beam 2.3 Segurança e criptografia Um ponto importante para um projeto que envolve o gerenciamento de dados de um cliente, é assegurar de que esses dados não possam ser lidos ou usados por intrusos. Um programa deve garantir que a informação seja armazenada, transmitida e recebida de forma segura. Nessa sessão foi feito um apanhado de informações sobre inúmeros métodos de segurança no armazenamento e na comunicação Métodos de criptografia A criptografia tradicional consiste em um método de transmissão de dados em que as mensagens a serem enviadas, aqui será chamado de texto simples, são transformadas em uma mensagem ilegível, aqui chamada de texto criptografado. Durante o processo de comunicação a mensagem criptografada é enviada para o destinatário, este, conhecendo o método de decriptografia pode transformá-la em texto simples novamente. (SCHNEIER, 1996). A figura 11 mostra como funciona o modelo clássico de criptografia. Para que este funcione, deve-se supor que o destinatário conhece o método de decriptografia. Dessa forma, porem, ele deve ser mudado sempre que for comprometido, uma vez que um intruso

44 42 Capítulo 2. Embasamento Teórico Figura 11: O modelo de criptografia também possa conhecê-lo. Para evitar tal esforço, usa-se uma chave de criptografia, que nada mais é que uma string usada para parametrizar o método. Dessa forma, precisa-se de uma chave sigilosa e um método público. Visto que os métodos de criptografia e decriptografia são apenas funções matemáticas onde a chave e o texto são parâmetros, será usada uma notação similar àquelas sugeridas por Tanenbaum (1997) e Schneier (1996), onde: C: Texto cifrado. S: Texto simples. E k : Método de criptografia usando a chave k. D k : Método de decriptografia usando a chave k. Dessa forma pode-se escrever: e C = E k (S) (2.1) S = D k (C) (2.2) O que significa que a encriptação da mensagem S, usando a chave k tem como resultado C e, da mesma forma, C decriptado com utilização da chave k resulta em S. As equações também sugerem: S = D k (E k (S)) (2.3)

45 2.3. Segurança e criptografia 43 É claro que esse método depende de um meio seguro por onde a chave encriptação possa ser transmitida. Uma maneira de evitar isso é utilizar um método de chave pública ou um método seguro de de compartilhamento de chaves secretas Método DES O método de encriptação Data Encryption Format (DES) é usado largamente em informática. Segundo Wayner (1995), ele já não é mais segura quando usada da mesma forma que foi criada, porém, modificado, ainda é bastante útil. Segundo Tanenbaum (1997), o DES funciona dividindo o texto simples em blocos de 64 bits que passam por 19 estágios distintos parametrizados por uma chave de 56 bits. O primeiro estágio é uma transposição de chave independente 5 no texto simples S. No último estágio é feita a mesma transposição de forma invertida. No penúltimo estágio é feito um SWAP de 32 bits 6. Nos estágios intermediários divide-se o bloco de 64 bits em dois blocos de 32 bits, que serviram como entrada. Será utilizado D in e E in para denotar as entradas e D out e E out para denotar as saídas. Esse método foi criado para que a mesma chave de criptografia possa ser usada para decriptografia. As equações de cada método intermediário são: E out = D in (2.4) e D out = E in F ki (D in ) (2.5) A figura 12 mostra como funciona cada estágio intermediário. A complexidade do algoritmo consiste na complexidade da função F, que não será explicada com detalhes, mas consiste em uma expansão de D in para 48 bits, uma operação OU EXCLUSIVO bit a bit com k i e um processo complexo transforma a saída em 32 bits novamente. Em cada um desses estágios, uma chave diferente é utilizada. Antes do início do algoritmo uma transposição é aplicada a chave e logo depois esta é particionada em duas unidade de 28 bits. Essas unidade são roteadas para esquerda ou direita um certo número de bits de acordo com o estágio. Em cada estágio é usado um subconjunto de 48 bits para k i. 5 Método onde os bits da mensagem são colocados em ordem diferente segundo imposto pela chave 6 Método onde se troca os 32 bits da esquerda com os 32 bits da direita

46 44 Capítulo 2. Embasamento Teórico Figura 12: Estágios intermediários do DES O método DES é mais utilizado hoje em dia em suas variações, uma delas é o processo de tripla criptografia com duas chaves, onde: e C = E k1 (D k2 (E k1 (S))) (2.6) S = D k1 (E k2 (D k1 (C))) (2.7) (TANENBAUM, 1997) Pode-se observar que apesar da tripla criptografia apenas duas chaves são utilizadas, o uso de uma terceira chave seria um grande exagero uma vez que os 112 bits das duas chaves são suficientes para garantir a segurança. Alem disso, pode ser visto que o processo de criptografia envolve uma decriptografia com uma segunda chave 7, um bom motivo para isso a retrocompatibilidade (Schneier, 1996). Apenas definindo k 1 = k 2 um computador que usa criptografia tripla pode se comunicar com um que usa a simples, uma vez que: E k1 (S) = E k1 (D k1 (E k1 (S))) (2.8) Método de compartilhamento de Chave de Diffie-Hellman Um problema dos métodos de chave única é como estabelecê-la de forma segura entre remetente e destinatário. O método de troca de Chave de Diffie-Hellman (DIFFIE; HELLMAN, 1976) resolve esse problema. 7 Chama-se: DES no modo EDE.

47 2.3. Segurança e criptografia 45 Considere que A e B precisem estabelecer uma chave secreta para uma comunicação segura. Primeiro escolhe-se 2 números primos extensos, n e g, de forma que (n 1)/2 e (g 1)/2 também sejam primos. Esses números são públicos e podem ser informados abertamente sem comprometimento da segurança. A deve selecionar um número extenso, a, que deve ser mantido em segredo. B seleciona um segundo número, b, da mesma forma. A envia uma mensagem para B contendo (g a mod n) e B envia uma mensagem contendo (g b mod n). A pode calcular: (g b mod n) a e b pode calcular: (g a mod n) b. Como: (g a mod n) b = g ab mod n = (g b mod n) a Dessa forma A e B possuem uma chave secreta compartilhada (g ab mod n). Mesmo que uma intrusa intercepte todas as mensagens, ela consegue os valores de: g, n, (g b mod n), (g a mod n). Mas mesmo com esses dados, não é possível calcular os valores de a, b ou (g ab mod n). A figura 13 mostra a comunicação entre A e B Figura 13: Método de troca de chave de Diffie-Hellman Um problema desse método é um tipo de ataque chamado man in the middle, que envolve um intruso ativo. Considerando que um intruso I pode interceptar a comunicação entre A e B, ele pode se passar por um dos dois e enviar mensagens falsas, escolhendo um número próprio, i. A figura 14 mostra como funciona esse ataque. Dessa forma I pode calcular: (g ai mod n) e (g bi mod n), as mesmas chaves que A e B, respectivamente, calcularam Métodos de chave pública Um dos grandes problemas dos métodos de criptografia mencionados anteriormente está na distribuição de chaves. Caso um intruso consiga roubar a chave, o sistema se torna inútil. Diffie e Hellman (1976) propuseram um novo sistema de criptografia onde a chave usada para criptografar é diferente da chave usada para decriptografar. Nesse sistema

48 46 Capítulo 2. Embasamento Teórico Figura 14: Ataque Man In The Middle deve-se garantir que é extremamente difícil de deduzir uma das chaves conhecendo a segunda. Esse método funciona da seguinte maneira. Considerando a comunicação entre A e B, A cria uma chave de criptografia e uma de decriptografia, k e e k d respectivamente. A chave k d se torna pública (chave pública) enquanto k e é mantida em segredo (chave privada), os métodos de criptografia e decriptografia, E e D, também são tornados públicos. Qualquer um interessado em se comunicar seguramente com A, B, por exemplo, usa a chave pública e o método de encriptação para gerar uma mensagem cifrada: C = E ke (T ) (2.9) Assim qualquer um que interceptar a comunicação saberá C e k e, mas a partir disso é impossível determinar T. Uma vez que apenas A possui a chave para decriptar. Quando a mensagem chega até A, precisa-se fazer: Algoritmo RSA T = D kd (C) (2.10) O algoritmo RSA foi proposto por um grupo de pesquisadores do MIT e é baseado na teoria dos números. Seu nome é dado pela inicial dos três matemáticos que o criaram, Rivest, Shamir e Adleman. A forma resumida do funcionamento do método é, segundo Rivest e Adleman (1978): Escolhe-se dois números primos bastante extensos (em geral maior que ), p e q por exemplo.

49 2.3. Segurança e criptografia 47 Calcula-se n = p q e z = (p 1) (q 1). Escolhe-se um número d onde d e z são primos entre si 8. Calcula-se e onde e d = 1 mod z Divide-se o texto simples em blocos de modo que cada mensagem, S, fique no intervalo: 0 S n. Para criptografar a mensagem calcula-se C = P e ( mod n). Para decriptografar a mensagem calcula-se P = C d ( mod n). Pelo método pode-se perceber que para criptografia precisa-se do par (e, n) (chave pública) e para decriptografia do par (d, n) (chave privada). A segurança do método está baseda na dificuldade de se fatorar números bastante extensos. Caso consiga-se fatorar o número publicamente conhecido n, poderia-se descobrir os valores de p, q, z e consequentemente d. Porém, considerando um tempo de 1μs por instrução, o melhor dos algoritmos levaria 4 bilhões de anos para fatorar um número de 200 dígitos e anos para um de 500 dígitos. (RIVEST; ADLEMAN, 1978) O RSA é muito utilizado para distribuir chaves de sessões únicas, dados muito grandes são geralmente encriptados com o DES, uma vez que o RSA é muito lento para essa função Algorítmos de HASH criptográficos Uma função de hash deve receber um vetor de bytes de tamanho arbitrário e retornar um segundo vetor de tamanho fixo de forma que qualquer mudança nos dados vai, com grande probabilidade, modificar o valor de saida, chamado de hash ou digest. Segundo Tanenbaum (1997), uma função de hash criptográfico ideal, deve possuir as seguintes propriedades: É computacionalmente fácil computar o valor de hash de qualquer mensagem. É computacionalmente intratável gerar uma mensagem sabendo seu valor de hash. É computacionalmente intratável encontrar duas mensagens com o mesmo hash. Essa propriedade é chamada de resistência a colisão. 8 chama-se primos entre si dois números que não possuem um divisor comum além de 1

50 48 Capítulo 2. Embasamento Teórico Algoritmos de hash são utilizados tanto para verificação de senhas do usuário quanto para assinaturas digitais e MACs (Message Autentication Code).(BELLARE; 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) Autenticação A autenticação é o processo de verificar a veracidade de um dado ou informação. Isso, em geral, envolve confirmar a identidade de uma pessoa ou software. Em muitas aplicações, garantir que uma informação é autentica é mais importante que o próprio sigilo da informação. (TANENBAUM, 1997). Não se deve confundir autenticação e autorização, apesar de estarem relacionados, o primeiro consiste no processo de verificar a identidade de uma pessoa enquanto o segundo verifica permissões que uma identidade tem de executar uma ação. Sistemas que envolvem controle de acesso são exemplos de sistemas que necessitam de mecanismos com ambas as funções. Nesta seção, será mostrado dois métodos que podem ser utilizados para garantir a autenticação de um dispositivo ou mensagem digital Autenticação baseada em chave compartilhada Considerando que A e B já possuem uma chave compartilhada (k AB ), uma forma de garantir a autenticidade em uma comunicação é através do método de desafio/resposta, que funciona da seguinte forma: A gera uma sequencia de números (R A ) aleatórios e envia para B, B usa a chave compartilhada e gera E kab (R A ). B envia o resultado da encriptação para A, que compara com a sua própria encriptação. A sabe que um invasor não poderia ter encriptado corretamente R A pois apenas B conhece a chave secreta k AB. Esse método pode ser visto na figura 15. (TANENBAUM, 1997) Autenticador de uma mensagem Uma segunda maneira de garantir autenticação é através de um autenticador, que é conhecido como MAC (Message Autentication Code) (BELLARE; KILIAN; ROGAWAY, 2000). O MAC é uma pequeno pedaço de informação que é utilizado para autenticar uma mensagem. Ele recebe como entrada uma chave e a mensagem, que deve ser autenticada, e retorna o MAC, que nada mais é que uma encriptação de uma função HASH.

51 2.3. Segurança e criptografia 49 Figura 15: Método de autenticação baseado em chave compartilhada Ele se diferencia dos outros métodos de assinaturas digitais uma vez que utiliza encriptação simétrica, e não de chave privada. O MAC parte da hipótese de que as duas partes que necessitam da autenticação já compartilham uma chave secreta. Caso essa chave seja comprometida, todo o processo de autenticação pode se tornar inválido. (TANENBAUM, 1997)

52

53 51 3 Metodologia e Implementação 3.1 Descrição do Projeto O projeto consiste em um terminal desenvolvido com utilização da plataforma Arduino, com capacidade NFC adicionada, que controla uma fechadura elétrica. Esse terminal deve ser capaz de se comunicar com um celular, que também deve ter capacidades NFC, rodando um aplicativo desenvolvido para o sistema operacional Android. O projeto também prevê a utilização de um aplicativo web para gerenciamento e administração de acesso. Um diagrama esquemático das interações entre os componentes do sistema pode ser visto na figura 16. Uma explicação mais detalhada do processo envolvido será incluída nas próximas seções. Figura 16: Diagrama esquemático O desenvolvimento e implementação do sistema possuiu 4 etapas: Desenvolvimento e montagem do hardware. Desenvolvimento do software para a fechadura. Desenvolvimento do aplicativo para android. Desenvolvimento da aplicação Web.

54 52 Capítulo 3. Metodologia e Implementação Cada uma dessas etapas será abordada de forma mais detalhada nas seções seguintes Especificação de Requisitos do Projeto Serão utilizadas as seguintes definições para os STAKEHOLDERS: Desenvolvedor Responsável pela elaboração da solução técnica. Cliente Pessoa ou empresa que contrata o serviço para ser usado em um cofre ou portas. Usuário Aquele que utiliza o serviço, usando seu celular para abrir uma fechadura. Também serão usadas as seguintes definições: Terminal Hardware encontrado na fechadura. Aplicativo móvel Software desenvolvido para Android. Aplicativo WEB ou Servidor Site desenvolvido na para acesso WEB. Sistema Conjunto de todo sistema composto por terminal aplicativo móvel e aplicativo WEB Requisitos Não-funcionais A comunicação entre o Aplicativo móvel e o Terminal deve ser feita de forma segura com criptografia RSA, DES ou AES(FIPS, 2001) e autenticação. O Desenvolvedor deve prever atualizações periódicas para suprir a necessidade de segurança do sistema. Todos os dados dos Usuários e do Cliente devem ser gravados de forma criptografada e segura, através de uma função Hashing. O tempo entre o envio da mensagem pelo Aplicativo móvel e a abertura da porta dever ser o menor possível (< 5s). O usuário deve conseguir acesso com o mínimo de configuração possível e o mínimo de toques na tela. Apenas uma mensagem deve ser enviada pelo Aplicativo móvel para o Terminal a fim de cumprir os requisitos dos dois itens anteriores. O sistema deve gravar um LOG de acesso à fechadura, relatando quais Usuários a utilizaram.

55 3.2. Hardware para a fechadura 53 O Cliente deve ser capaz de, a qualquer momento, verificar o LOG de acesso. A interface do aplicativo deve ser limpa e desenvolvida utilizando o método KISS Keep It Symple, Stupid. O aplicativo móvel deve rodar em Android versão 4.0 (Ice Cream Sandwish) e mais novas. O aplicativo móvel deve ser atualizado automaticamente quando necessário, seja via Google Play ou por um sistema customizado do Desenvolvedor (sem necessidade de intervenção do Usuário ou Cliente). O aplicativo web deve ser implementado com utilização do HTTPs. O sistema deve implementar um time-out para a autorização de um usuário. Obs. A segurança do meio físico não faz parte deste projeto de TCC Requisitos Funcionais O terminal deve controlar um Relê para acionar uma fechadura elétrica alimentada com 12V. O terminal deve ser capaz de se comunicar através do NFC utilizando o modo de comunicação peer-to-peer. O Terminal deve ser capaz receber e enviar mensagens por NFC no formato NDEF com utilização do protocolo SNEP sobre LLCP. O Cliente deve ser capaz de autorizar ou revogar a autorização de qualquer usuário para acesso de qualquer terminal a qualquer momento através do Aplicativo WEB. 3.2 Hardware para a fechadura Para cumprimento dos requisitos funcionais do projeto, precisou-se escolher: Que tipo de micro-controlador será usado. Que tipo de relê será utilizado. Qual hardware será utilizado para incluir a funcionalidade NFC. As seções seguintes discorrem sobre essas escolhas.

56 54 Capítulo 3. Metodologia e Implementação O Arduino O Arduino é uma plataforma de prototipagem eletrônica baseada em processadores da ATMEL, que podem variar desde um AVR de 8-bits à um ARM de 32-bits. O Arduino foi escolhido tanto pela vasta gama de acessórios disponíveis quanto pela quantidade de informação e bibliotecas disponíveis na internet, já que é um projeto de hardware-livre e código-aberto. Durante o desenvolvimento do sistema, foram feitos vários testes de desempenho das bibliotecas implementadas, por isso utilizou-se 3 Arduinos diferentes, o UNO (figura 17), o MEGA (figura 18) e o DUE 19. Pode-se ver um comparativo de algumas características importantes dos 3 Arduinos na tabela 11. (a) Arduino R3 UNO (Frente) (b) Arduino R3 UNO (Costas) Figura 17: Arduino R3 UNO Fonte: Figura 18: Arduino MEGA 2560 Fonte: Pode-se ver que o Arduino UNO não possui alto poder de processamento, não só por possuir clock de apenas 16MHz mas principalmente pela memória RAM limitada, apenas 2kB. Para um programa que envolve grandes matrizes ou faz uso de muitos objetos Strings isso se torna um grande problema, uma vez que pode-se facilmente chegar a 2048 caracteres.

57 3.2. Hardware para a fechadura 55 Figura 19: Arduino DUE Fonte: Tabela 11: Características dos três Arduinos trabalhados Arduino UNO Arduino DUE Arduino MEGA Microcontrolador ATmega328 AT91SAM3X8E ATmega2560 Tensão de Operação 5V 3.3V 5V Tensão de entrada 7-12V 7-12V 7-12V Pinos Digitais (I/O) Pinos Analógico (I) Memória Flash 32 KB 512 KB 256 KB SRAM 2 KB 96 KB 8 KB EEPROM 1 KB 4 KB Frequência de Clock 16 MHz 84 MHz 16 MHz O PN532 O PN532 é um modulo de transmissão para comunicação via RF a 13.56MHz. Ele inclui a funcionalidade de um microcontrolador com núcleo baseado em um 80C51. Ele pode se comunicar via UART, I 2 C ou SPI. Esse chip foi escolhido por: Estar facilmente disponível para o Arduino em forma de Shield 1. O shield utilizado para o projeto pode ser visto na figura 20. Ser largamente utilizado. Vários dos celulares com capacidade NFC possuem um PN532 imbutido. Ser capaz de realizar comunicação peer-to-peer. Muitos do chips disponíveis possuem apenas capacidade de ler e gravar tags NFC passívas. (NXP - PHILIPS, 2007) 1 Periféricos feitos especialmente para o Arduino são chamados de Shields

58 56 Capítulo 3. Metodologia e Implementação Figura 20: Shield NFC para o Arduino Primeiro Protótipo Para montagem do primeiro protótipo, foi utilizado: Arduino UNO R3, mostrado na figura 17. Um Shield NFC PN532 para Arduino, mostrado na figura 20. Um Shield de prototipação para Arduino, mostrado na figura 21. Um Relay 5V, mostrado na figura 22. Um sensor magnético (Reed Switch). Um auto-falante de placa mãe (Buzzer). A montagem do primeiro protótipo incluía um Reed Switch para leitura do estado da porta e um buzzer para envio de mensagens de erro ou sucesso. Tais elementos foram excluídos do projeto na implementação final. Projetou-se o primeiro protótipo do terminal segundo o esquemático mostrado no apêndice A, o resultado da montagem pode ser visto na figura 23. Para o primeiro protótipo utilizou-se um software que fazia a comunicação via NFC sem utilização de criptografia. Quando foram inclusos testes com criptografia o arduino UNO se mostrou muito limitado. Por esse motivo buscou-se a utilização de microcontroladores com maior capacidade como o Arduino DUE e MEGA O protótipo Final Para montagem do protótipo final, algumas mudanças foram requisitadas:

59 3.2. Hardware para a fechadura 57 Figura 21: Shield de prototipação para Arduino Figura 22: Relay 5V Figura 23: Primeiro Protótipo do Terminal O hardware deve ser conectorizado de forma a ser compatível com o Arduino MEGA, DUE e UNO (o MEGA é usado preferencialmente, por ser mais barato que o DUE

60 58 Capítulo 3. Metodologia e Implementação e ter a quantidade de RAM necessária, além da compatibilidade de software com o UNO, já que possuem a mesma arquitetura AVR). Não será utilizado um shield de prototipação com protoboard, os elementos utilizados devem ser soldados a fim de evitar mal contatos. Não será incluído o Relay na placa de prototipação. Deve-se utilizar um Relay de estado sólido. Uma segunda plca deverá ser confeccionada para ele quando for testado com uma fechadura elétrica real. Não será incluído, por enquanto, o sensor magnético (Reed Switch). Apenas por motivo de praticidade uma vez que ele não é uma parte importante do sistema. Em lugar do buzzer para pequenas comunicações ao usuário, deve-se fazer a utilização de dois LEDs acionados através de transistores. Para cumprir alguns requisitos de segurança do projeto, deverá ser incluso, na placa confeccionada, um RTC (Real Time Clock). Seguindo os requisitos propostos para o protótipo final montou-se uma placa de prototipação com o proposito de conter o RTC, os leds e acoplar facilmente o shield NFC. Com o intuito de que ele seja facilmente utilizado em qualquer Arduino 2. A figura 24 mostra a placa confeccionada, o Shield NFC e o Arduino Mega. Mostra também os cabos confeccionados para fazer a conexão. A figura 25 mostra a placa já montada e a figura 26 mostra todo o sistema em estado de funcionamento (aguardando a aproximação de um celular). 3.3 Software para o Arduino A implementação do software para o Arduino envolveu duas grande etapas. A primeira delas foi a criação de uma biblioteca que servisse de interface com o PN532 e implementasse a comunicação peer-to-peer. As bibliotecas disponíveis até o momento apenas faziam leitura e gravação de tags passivas. A segunda etapa envolveu a implementação da segurança do sistema. Algumas bibliotecas deveriam ser desenvolvidas para garantir a segurança. Como não se tinha certeza da eficiência de qualquer algoritmo que pudesse ser utilizado, ou como se comportariam nos 3 Arduinos, ou durante a transmissão NFC, a abordagem utilizada para implementação desses softwares foi a prototipação. 2 Os três Arduinos possuem os pinos da SPI em lugares diferentes, o DUE não possui pinos da SPI ligados aos conectores que são utilizados pelo shield, a placa possibilita a ligação do shield em qualquer Arduino

61 3.3. Software para o Arduino 59 Figura 24: Shield NFC, Placa confeccionada, Arduino MEGA e cabos confeccionados Figura 25: Placa confeccionada montada Todos os softwares elaborados para o Arduino foi desenvolvido em C++ e foram utilizadas duas IDE s. A primeira, foi a IDE do Arduino, mostrada na figura 27. Por ser uma IDE bem simples, foi utilizada principalmente para fazer compilação e transferência do código. Para criação das bibliotecas, foi utilizada uma IDE muito mais completa, com muito mais recursos. Uma plataforma de código aberto chamada Code::Blocks (figura 28).

62 60 Capítulo 3. Metodologia e Implementação Figura 26: Todo sistema em funcionamento Figura 27: IDE para o Arduino Implementação da Biblioteca para comunicação peer-to-peer NFC Para implementar a comunicação peer-to-peer a biblioteca criada deveria implementar os protocolos LLCP e SNEP, o formato NDEF e a comunicação com o PN532. Para isso, foram utilizadas a biblioteca já implementada para o PN532 (biblioteca de código livre desenvolvida pela ADAFRUIT) e a LIBNFC (biblioteca de código livre desenvolvida pelo NFC-Fórum), utilizada como referência para implementação de alguns tipos 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-

63 3.3. Software para o Arduino 61 Figura 28: IDE do Code::Blocks cumentação do PN532 e da configuração esperada pelo Android. tentativas precisaram ser feitas. Dessa forma, várias utilizados. Nas seções subsequentes, pode-se ver os principais comandos do PN532 que foram Comando InitAsTarget O comando Init as Target serve para configurar o PN532 como target. Ao enviar esse comando, o PN532 apenas responde quando recebe um Atribute Request do Initiator. O comando InitAsTarget tem a sintaxe mostrada na tabela 12. Tabela 12: Sintaxe do Comando InitAsTarget D4 8C Mode (1byte) MifareParams (6 bytes) FeliCaParams (18 bytes) NFCID3t (10 bytes) LEN Gt Gt Len Tk Tk A resposta do comando indica parâmetros para as próximas comunicações, principalmente para os protocolos de anticolisão e outros baseados no NFCIP3 (NFC - FORUM, 2013b), que estão fora do contexto deste trabalho. Para o contexto deste trabalho, o fator mais importante são os parâmetros FeliCa, já que o Android sempre envia uma requisição para o padrão FeliCa (SONY..., 2013) a 424kbps. Comando GetData

64 62 Capítulo 3. Metodologia e Implementação Esse comando possibilita que o controlador (Arduino) receba os dados que foram recebidos pelo PN532 do Initiator. Ele funciona apenas se o PN532 estiver configurado em modo de Target. A sintaxe desse comando pode ser vista na tabela 13. A sintaxe da resposta pode ser vista na tabela 13. Tabela 13: Sintaxe para o comando GetData D4 86 Tabela 14: Sintaxe para a resposta do comando GetData D5 87 Status DATA IN O byte de Status indica se a comunicação foi sucedida ou falha. Em uma tipica comunicação DEP (Data Exchange Protocol), o Initiator pode demorar um pouco para enviar os dados. O PN532 envia uma resposta para pedir mais tempo ao controlador, que deve repetir o comando para receber os dados. Comando SetData Esse comando permite que o controlador forneça dados para que o PN532, mais tarde, os envie para o Initiator. A sintaxe do comando pode ser vista na tabela 15. A sintaxe para a resposta desse comando é bem simples, apresenta apenas um byte de Status que deve informar se a informação foi bem sucedida e pode ser vista na tabela 16. Tabela 15: Sintaxe para o comando SetData D4 8E DATA IN Tabela 16: Sintaxe para a resposta do comando SetData D5 8F STATUS LLCP Foi desenvolvida uma classe para fazer a abstração da camada de enlace de dados baseando-se no protocolo já comentado na seção Alguns algoritmos utilizados para algumas funções da classe serão explicados nessa seção. Pode-se ver, nessa parte do código, que as camadas de rede se misturam. Algumas das especificações do protocolo SNEP já são atribuídas a abstração da camada de enlace de dados que foi implementada.

65 3.3. Software para o Arduino 63 Isso não é um problema uma vez que a aplicação tem interesse apenas em implementar o protocolo SNEP. Quando o Android deseja enviar uma mensagem (Beam T M ), ele faz uma requisição para se conectar como cliente, caso contrário, como servidor. Dessa forma, nessa classe, foram elaborados: O algoritmo 3.1. Com função de fazer conexão como um client SNEP. O algoritmo 3.2. Com função de fazer conexão como um servidor SNEP. O algoritmo 3.3. Com função de receber dados do cliente. O algoritmo 3.4. Com função de enviar dados para o servidor. Essa abstração da camada de dados também possui função de colocar os SSAP e DSAP da comunicação nos PDUs necessários, determinar o byte de sequência 3 e determinar os parâmetros que devem ser enviados nos bytes de informação em alguns casos. 1 configurapn532comotarget ( ) ; se r e s u l t a d o!= OK 3 r e t o r n e ERRO; recebepdu_pn532 ( ) ; 5 enviapdu_pn532(connect) ; recebepdu_pn532 ( ) ; 7 enquanto Tipo_PDU_Recebido = SYMM {// espera conexao bem sucedida enviapdu_pn532(symm) ; 9 s e TIME_OUT r e t o r n e ERRO; 11 recebepdu_pn532 ( ) ; } 13 s e Tipo_PDU_Recebido = CONN_SUCCESS r e t o r n e OK; Algoritmo 3.1: Algoritmo de Conexão como Cliente SNEP configurapn532comotarget ( ) ; 2 se r e s u l t a d o!= OK r e t o r n e ERRO; 4 recebepdu_pn532 ( ) ; enviapdu_pn532(symmm) ; 6 recebepdu_pn532 ( ) ; enquanto Tipo_PDU_Recebido!= CONN{ // e s p e r a conexao 8 enviapdu_pn532(symmm) ; se TIME_OUT 3 Para essa aplicação, ele nunca será maior que zero, uma vez que apenas uma mensagem é enviada ou recebida por conexão devido as limitações já discutidas do Android

66 64 Capítulo 3. Metodologia e Implementação 10 r e t o r n e ERRO; recebepdu_pn532 ( ) ; 12 } enviapdu_pn532(conn_success) ; 14 r e t o r n e OK; Algoritmo 3.2: Algoritmo de Conexão como Servidor SNEP recebepdu_pn532 ( ) ; 2 enquanto Tipo_PDU_recebido!= INFORMATION { s e PDU_recebido!= OK 4 r e t o r n e ERRO; s e Tipo_PDU_recebido == SYMM 6 enviapdu_symm_pn53; se TIME_OUT 8 r e t o r n a ERRO; } 10 enviapdu_pn532(receive_ready) ; // Envia confirmacao LLCP 12 PN535_recebe_PDU ( ) ; 14 enviapdu_pn532( I ) ; // envia r e s p o s t a SNEP ( r e c e b i d o 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 SNEP 4 recebepdu_pn532 ( ) ; // espera se um PDU RECEIVE_READY 6 PN535_enviaPDU(SYMM) ; 8 PN535_recebe_PDU ( ) ; // espera se confirmacao SNEP (PDU t i p o I ) Algoritmo 3.4: Algoritmo de Envio de dados SNEP Como grande parte do protocolo SNEP já foi implementado, a função dessa abstração é basicamente gerar os cabeçalhos SNEP. Dois algoritmos simples foram implementados para fazer o PUSH (algoritmo 3.5) e o PULL (algoritmo 3.6) implementados pelo android. LLCP_conectaComoServidor ( ) ; 2 geracabecalhosnep ( ) ; 4 s e LLCP_enviaDados ( )!= OK

67 3.3. Software para o Arduino 65 r e t o r n a ERRO; 6 r e t o r n a OK; Algoritmo 3.5: Algoritmo de PUSH LLCP_conectaComoClient ( ) ; 2 s e LLCP_recebeDados ( )!= OK 4 r e t o r n a ERRO; 6 verificacabecalhosnep ( dados_recebidos ) ; 8 r e t o r n a menssagem_ndef ; // r e t i r a o cabecalho SNEP e r e t o r n a // apenas o NDEF Algoritmo 3.6: Algoritmo de PULL NDEF A função dessa abstração do formato NDEF é basicamente gerar os cabeçalhos da mensagem NDEF, juntar as Gravações NDEF (NDEF Records), colocar corretamente os tipos de cada gravação NDEF e os bits de começo e fim. Para contexto desse trabalho, cada mensagem NDEF possui apenas uma gravação NDEF Implementação da Criptografia Para satisfazer os requisitos não funcionais relacionados a segurança do sistema, foi necessária a implementação de algumas bibliotecas de Segurança para o Arduino. A primeira tentativa foi de fazer uma biblioteca de chave pública, a RSA. Essa primeira tentativa foi feita no Arduino UNO, que se mostrou insuficiente para suportar tal algoritmo. O RSA envolve apenas operações de exponenciação e MOD, porém, com números muito grandes (pelo menos 1024 bits). Dessa forma, usou-se apenas o AES, um método de criptografia de blocos com chave simétrica (FIPS, 2001). O protocolo de Diffie-Hellman, para gerar uma chave de 16 bytes, também necessitava de operações de exponenciação com números muito grandes e de geração de números primos imensos, com mais de 300 dígitos (DIFFIE; HELLMAN, 1976). O uso do protocolo Diffie-Hellman foi substituido, então, por o uso de uma chave de criptografia baseada em um hash de uma mensagem que deveria ser enviada pelo Arduino e uma senha padrão, que é usada como forma de autenticação. O funcionamento pode ser visto no diagrama da figura 29.

68 66 Capítulo 3. Metodologia e Implementação Figura 29: Esquema de geração de chave para criptografia Implementação da Biblioteca AES Foi implementada uma biblioteca para o Arduino para realizar criptografia AES. Ela tem capacidade para criptografar mensagens no modo CBC e ECB, sem utilização de padding. Essa biblioteca foi gerada de acordo com o padrão definido em (FIPS, 2001) padrão oficial da AES. Um exemplo da utilização da biblioteca pode ser vista no código C do algoritmo 3.7. i n c l u d e "DAES. h " d e f i n e KEY_SIZE 16 byte_t key [ 1 6 ] = {... } ; 6 byte_t i v [ 1 6 ] = {... } ; char * plain_text = "... " ; 8 DAES aes ; 10 // void i n i t ( ) { 14 byte_t cryptdata [ s t r l e n ( plain_text ) ] ; byte_t decryptdata [ s t r l e n ( plain_text ) ] ; 16 DAES. setkey ( key, KEY_SIZE) ; DAES. encrypt_ecb ( cryptdata, plain_text, s t r l e n ( plain_text ) ) ; 18 // caso modo CBC 20 DAES. encrypt_cbc ( cryptdata, plain_text, s t r l e n ( plain_text ), i v ) ; 22 // Decript

69 3.3. Software para o Arduino 67 DAES. decrypt_ecb ( decryptdata, cryptdata, s t r l e n ( plain_text ) ) ; 24 DAES. decrypt_cbc ( decryptdata, cryptdata, s t r l e n ( plain_text ), i v ) ; 26 // todas e s s a s f u n c o e s j a consideram que o tamanho do p l a i n t e x t 28 // eh um m u l t i p l o de 16, j a que nao e usado nenhum t i p o de padding 30 while ( 1 ) ; } 32 void loop ( ) { 34 } Algoritmo 3.7: Uso da Biblioteca AES Implementação da biblioteca MD5 Foi criada uma biblioteca para geração de um HASH MD5, baseada no RFC1321 (RIVEST et al., 1992). Essa biblioteca é bastante simples e de fácil utilização. Um exemplo de uso pode ser visto no algoritmo 3.8. O MD5 foi utilizado pela facilidade de implementação, mas sabe-se de algumas de suas fragilidades para utilizações que exigem certo nível de segurança. A biblioteca foi feita para incluir novas formas de HASH e, caso necessário, uma possibilidade é incluir SHA1 (STANDARD, 1993). i n c l u d e "DASH. h " char * word1 = "... " ; 4 char * word2 = "... " ; char * s a l t = "... " ; 6 DASH d i g e s t ; 8 // 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 while ( 1 ) ; }

70 68 Capítulo 3. Metodologia e Implementação } void loop ( ) { Algoritmo 3.8: Uso da Biblioteca HASH MD5 3.4 Algoritmo do Sistema Completo loop { 2 e s p e r a C e l u l a r ( ) ; 4 envia_mensagem_nfc ( ID, GeradordeSenha ) ; 6 enquanto! TIME_OUT { 8 recebe_mensagem_nfc ( ) ; 10 } 12 s e TIME_OUT loop ( ) ; 14 d e c r i p t o g r a f a ( mensagem_recebida ) ; 16 verificacomando ( ) ; 18 se! 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 funcionamento do terminal em seu mais alto nível. Pode-se ver que a mensagem recebida passa por uma fase de decriptografia, uma fase de verificação da autenticação e uma terceira fase de verificação da autorização. A fase de verificação de autenticação envolve autenticar o Servidor, o celular, e o usuário (através de sua senha).

71 3.5. Protocolo criado para comunicação e autenticação Protocolo criado para comunicação e autenticação Para a comunicação entre o sistema, foi criado um protocolo. Esse protocolo mostra como cada mensagem deve ser enviada, assinada e criptografada. Para uso desse protocolo na comunicação NFC, foi criado um novo tipo de gravação NDEF, o tipo "D". O aplicativo e o terminal devem reconhecer o NDEF desse tipo e tratá-lo como será especificado. O protocolo consiste em uma autorização do servidor, a senha do usuário e a assinatura do aplicativo, como mostra a tabela 17. Tabela 17: Sintaxe do protocolo criado Autorização do Servidor 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(k ST ) e uma palavra para autenticação utilizada como salt de 16 bytes (AutSalt ST ). O terminal e o celular devem compartilhar uma chave de 16 bytes(k AT ), uma palavra para autenticação utilizada como salt de 16 bytes (AutSalt AT ) e um segundo salt para geração da senha (KeyGenSalt AT ) 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 executado. ID Aplicativo indica qual aplicativo (Celular) tem autorização de executar esse comando. Data de expiração indica até quando essa autorização é válida.

72 70 Capítulo 3. Metodologia e Implementação A assinatura do servidor consiste em uma criptografia AES com a chave k ST de um hash MD5 de todos os primeiros 16 bytesda mensagem de autorização mais o AutSalt ST para melhorar a segurança. AssinServer = E AES k ST (MD5(Cmd IDTerm IDApp DTExp AutSalt ST )) Onde indica concatenação Assinatura do Aplicativo A assinatura do celular consiste em uma criptografia AES com a chave k AT de um hash MD5 da autorização do servidor mais a senha do usuário mais um salt AutSalt AT. AssinApp = E AES k AT (MD5(AssinServer UserPass AutSalt AT )) 3.6 Aplicativo para Android Foi desenvolvido um aplicativo para o Sistema Operacional Android. O desenvolvimento foi feito com utilização da IDE Eclipse, que é recomendada para o Android e pode ser vista na figura 30. A linguagem de programação utilizada foi o JAVA. Não se precisou de nenhuma biblioteca externa para o desenvolvimento do software, usou-se apenas as bibliotecas já inclusas no Android 4.0. Figura 30: IDE Eclipse para programação em Android. O aplicativo foi feito de forma bem simples, a pessoa deve escrever a senha em seu celular, aproximar seu celular da antena e quando for requisitada, tocar na tela.

73 3.6. Aplicativo para Android 71 O aplicativo, além de ter função de fazer comunicação via NFC, deve também se comunicar com a WEB para buscar sua autenticação com o Servidor. T M Envio de uma mensagem NDEF com o Beam A utilização do Beam T M para envio de uma mensagem NDEF é feita implementandose as interfaces CreateNdefMessageCallback e OnNdefPushCompleteCallback. Um exemplo pode ser visto no algoritmo p u b l i c c l a s s P a s s A c t i v i t y extends A c t i v i t y implements CreateNdefMessageCallback, OnNdefPushCompleteCallback { p u b l i c NdefMessage createndefmessage ( NfcEvent event ) { 5 Log. d (TAG, " Push S t a r t " ) ; byte [ ] s e r v e r = NFCLockerCrypt. hexstringtobytearray ( c f a. g e t A u t o r i z a t i o n ( ) ) ; 7 byte [ ] password = g e t I n t e n t ( ). g e t S t r i n g E x t r a ( BeamActivity. INTENT_TAG_PASS). getbytes ( Charset. forname ( "US ASCII " ) ) ; ByteArrayOutputStream payload = new ByteArrayOutputStream ( ) ; 9 try { 11 payload. w r i t e ( s e r v e r ) ; i f ( password. l e n g t h < 16) { 13 f o r ( i n t i = 0 ; i < 16 password. l ength ; i++) payload. w r i t e ( ( byte ) 0) ; 15 } payload. w r i t e ( password ) ; 17 payload. w r i t e ( NFCLockerCrypt. md5( payload. tobytearray ( ) ) ) ; } catch ( IOException e ) { 19 e. printstacktrace ( ) ; } 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 T h i s, DELAY) ; 29 r eturn msg ; } 33 p u b l i c void onndefpushcomplete ( NfcEvent event ) { Log. d (TAG, "NDEF PUSH Completo " ) ;

74 72 Capítulo 3. Metodologia e Implementação 35 t h i s. f i n i s h ( ) ; } 37 } Algoritmo 3.10: Algoritmo Para uso do Beam T M no Android Sobrescreveu-se dois métodos das interfaces que foram utilizadas. O método createndefmessage, implementado na linha 4 é utilizado para geração da mensagem MDEF nos padrões já mencionados. Pode-se ver que é especificado o tipo de gravação NDEF na linha 25. Na linha 28 pode-se ver a implementação de um timeout. A atividade deve ser fechada caso fique aberta por muito tempo sem conseguir enviar uma mensagem NFC. Para que esses métodos sejam chamados corretamente, deve-se utilizar a classe NfcAdapter, que faz interface com o chip NFC presente no celular. 1 //... NfcAdapter nfcadapter ; p r o t e c t e d void oncreate ( Bundle s a v e d I n s t a n c e S t a t e ) { 5 //... 7 nfcadapter = NfcAdapter. getdefaultadapter ( t h i s ) ; 9 nfcadapter. setonndefpushcompletecallback ( t h i s, t h i s ) ; 11 nfcadapter. setndefpushmessagecallback ( t h i s, t h i s ) ; 13 //... } Algoritmo 3.11: Segundo algoritmo Para uso do Beam T M no Android Recebimento de uma mensagem NDEF Para recebimento de uma mensagem NDEF, usa-se o Android Dispatch System. Como não é permitido a utilização do chip NFC a baixo nível, faz-se um pedido ao sistema operacional que dispare um intent 4. Quando esse intent é disparado, filtra-se para saber se é um tipo que a aplicação deve utilizar. O código 1 //... 4 Classe do Android que consiste em uma descrição abstrata de uma operação que deve ser executada ou de um evento acontecido

75 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 i n g [ ] [ ] t e c h L i s t s A r r a y ; 5 PendingIntent pendingintent ; //... 7 nfcadapter = NfcAdapter. getdefaultadapter ( t h i s ) ; 9 nfcadapter. setndefpushmessagecallback ( null, t h i s ) ; 11 pendingintent = PendingIntent. g e t A c t i v i t y ( t h i s, 0, new I n t e n t ( t h i s, g e t C l a s s ( ) ). addflags ( I n t e n t. FLAG_ACTIVITY_SINGLE_TOP), 0) ; 13 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 try { 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 e c h L i s t s A r r a y = new S t r i n g [ ] [ ] { new S t r i n g [ ] { NfcF. c l a s s. getname ( ) }, new S t r i n g [ ] { NdefFormatable. c l a s s. getname ( ) } } ; 27 nfcadapter. enableforegrounddispatch ( t h i s, pendingintent, i n t e n t F i l t e r s A r r a y, t e c h L i s t s A r r a y ) ; Algoritmo 3.12: Recebimento de mensagens NDEF com Android Comunicação com o Servidor Para comunicação com o servidor, utiliza-se um segundo thread em background. A cada vez que uma autorização é baixada, verifica-se o tempo de validade da mesma. Uma autorização é considerada como "antiga"assim que se chega a 20% de seu prazo de expiração. Nesse momento, o aplicativo tentará buscar uma nova autorização a cada 10 minutos se houver conexão disponível. O aplicativo também tenta atualizar as autorizações sempre que a aplicação for aberta. O algoritmo 3.13 mostra como é feita a conexão com o servidor em backgorund. c l a s s AutorizationsTask extends AsyncTask<Void, Void, String > {

76 74 Capítulo 3. Metodologia e Implementação 2 4 p r o t e c t e d S t r i n g doinbackground ( Void... params ) { try { 6 URL u r l = new URL(URL_GET_AUTORIZATION) ; HttpURLConnection conn = ( HttpURLConnection ) u r l 8. openconnection ( ) ; conn. setdooutput ( true ) ; 10 conn. setrequestmethod ( "POST" ) ; S t r i n g postparams = " I d C e l l=" 12 + URLEncoder. encode ( i d _ c e 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 urlencoded " ) ; 18 conn. setrequestproperty ( " Accept Charset ", "UTF 8" ) ; conn. setrequestproperty ( " Content Length ", 20 S t r i n g. valueof ( postparams. getbytes ( ). l ength ) ) ; conn. setfixedlengthstreamingmode ( postparams. getbytes ( ). l ength ) ; 22 OutputStream out = conn. getoutputstream ( ) ; 24 out. w r 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 i n g r e s p o s t a = " " ; 30 Scanner instream = new Scanner ( conn. getinputstream ( ) ) ; while ( instream. hasnextline ( ) ) 32 r e s p o s t a += instream. nextline ( ) + " \n " ; Log. d (TAG, r e s p o s t a ) ; 34 conn. d i s c o n n e c t ( ) ; return r e s p o s t a ; 36 } catch ( Exception e ) { Log. d (TAG, e. t o S t r i n g ( ) ) ; 38 return n u l l ; } 40 } 42 p r o t e c t e d void onpostexecute ( S t r i n g param ) { i f ( param. startswith ( "OK" ) ) { 44 S t r i n g [ ] resp = param. s p l i t ( " \n " ) ; setaut ( resp [ 1 ] ) ; 46 Log. d (TAG, " PostEx aut : "+resp [ 1 ] ) ; Log. d (TAG, " PostEx aut : "+g e t A u t o r i z a t i o n ( ) ) ; 48 }

77 3.7. Aplicativo web } 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 pelo browser por qualquer um que tiver uma senha de administrador. A IDE utilizada foi o NETBeans, que pode ser vista na figura 31. Figura 31: IDE - NETBeans Banco de Dados O banco de dados do servidor deve gravar os dados dos usuários e de cada fechadura, para isso foram necessárias a criação de 4 tabelas, uma para as fechaduras, outra para os administradores, uma terceira para usuários e uma quarta tabela para guardar relacionamentos. A figura 32 mostra o diagrama Entidade Relacionamento do banco de dados.

78 76 Capítulo 3. Metodologia e Implementação Figura 32: Diagrama Entidade-Relacionamento A interface O site que implementa a interface WEB foi hospedado em 5. E pode ser acessado diretamente pelo endereço A primeira tela, é a tela de Login, como mostrada na figura 33. Após autenticação do usuário através de seu login e senha, na segunda tela ele pode gerenciar todas as suas fechaduras cadastradas (figura 34). Clicando em "Ver Usuários", o administrador pode modificar o status de cada usuário individualmente (figura 35). Figura 33: Primeira tela do aplicativo WEB Figura 34: Administração das Fechaduras 5 A2d é empresa que seria criada como responsável pela implementação e instalação do sistema.

79 3.7. Aplicativo web 77 Figura 35: Modificar Status de usuários

80

81 79 4 Resultados e Testes Neste capitulo se discorrerá sobre os resultados, testando-se a comunicação NFC, a velocidade e eficiência da criptografia, a comunicação com a internet. A primeira seção mostra todos os protocolos já vistos anteriormente funcionando corretamente. As próximas mostram testes de qualidade do software, mostrando as velocidades de execução das operações realizadas pelo sistema. 4.1 Comunicação NFC Para demonstração do funcionamento da comunicação NFC, foi feito, em um uso típico, utilizando a serial do computador, um log de todos os dados que se passam pela comunicação SPI entre o Arduino e o PN532. Dessa forma será possível ver todos os protocolos sendo utilizados. Não será comentado sobre todo o log, apenas sobre as partes importantes para este trabalho. A primeira mensagem que se pode ver, é: envio: 0 0 FF 5 FB D x2 0x0 resposta: 0 FF 2 FE D5 15 Ela apenas envolve configuração do SAM (Security Access Manager), sua sintaxe pode ser vista na seção sobre o PN532. Logo depois: envio: 0 0 FF 2D D3 D4 8C FE F BB BA A6 C FF FF 1 FE F BB BA A6 C D x3B 0x0 resposta: 0 FF 21 DF D5 8D 25 1E D E 12 1D 5E EF 1E C D está próximo. Esse comando, mostra o InitAsTarget. A resposta só é recebida quando o Initiator

82 80 Capítulo 4. Resultados e Testes Esses primeiros comandos não envolvem os protocolos de comunicação NFC de forma direta, apenas configurações essenciais para que o PN532 se comunique corretamente. No terceiro log pode-se ver: envio 0 0 FF 2 FE D4 86 0xA6 0x0 resposta 0 FF 5 FB D 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 x6D 0x0 resposta: 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 D x36 0x0 resposta: 0 FF 3 FD D5 8F 0 Nessa mensagem pode-se distinguir: preambulo PN532: 0 0 FF Tamanho e CS do tamanho: 13 ED Comando para o PN532: D4 8E Agora pode-se ver no PDU DSAP, Tipo PDU e SSAP: Byte de sequencia 0 Pode-se ver que: DSAP = b, Tipo = 1100b (I), SSAP = b Então tem-se o cabeçalho do SNEP: Versão e request: 10 2 (PUT) Bytes de tamanho Agora tem-se o cabeçalho NDEF

83 4.1. Comunicação NFC 81 Flag, tamanho do tipo D1 1 Tamanho do payload 4 Tipo 44 Então pode-se ver, finalmente, a carga útil da mensagem, que nesse caso é apenas o ID do terminal (0x ). Depois da mensagem enviada, pode ser visto o PDU tipo DISCONNECT. Envia: 0 0 FF 4 FC D4 8E x2D 0x0 Resposta: 0 FF 3 FD D5 8F 25 Agora o objetivo é conectar para receber uma mensagem NDEF, dessa forma o terminal deve ser iniciado como servidor, o Android deve pedir a conexão. Isso pode ser visto em um comando getdata mais adiante. Envia: 0 0 FF 2 FE D4 86 0xA6 0x0 Resposta: 0 FF 5 FB D Pode-se ver o PDU tipo Connect sendo recebido e logo depois a mensagem NDEF sendo recebida: Envia: FF 02 FE D4 86 A6 00 Resposta: 00 FF 50 B0 D D B5 ED CB E0 6F 01 B0 9F 20 2D AF 1B A6 DE D9 B F 8C 7A DC AE 51 AE 31 BD C8 2F D6 F3 0B AC 5F 6F E4 7E A9 D3 EF A B DC 14 2E 4C 1A F0 66 EF 2B F 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: O cabeçalho do SNEP: DSAP, Tipo PDU e SSAP: Byte de sequencia 0 Versão e request: 10 2 (PUT) Bytes de tamanho

84 82 Capítulo 4. Resultados e Testes O cabeçalho do NDEF: Flag, tamanho do tipo D1 1 Tamanho do payload 40 Tipo 44 e finalmente a carga útil: B5 ED CB E0 6F 01 B0 9F 20 2D AF 1B A6 DE D9 B F 8C 7A DC AE 51 AE 31 BD C8 2F D6 F3 0B AC 5F 6F E4 7E A9 D3 EF A B DC 14 2E 4C 1A F0 66 EF 2B F que após ser descriptografada é: FD 20 4F A0 22 3A 7E 12 5B FA FA 7C 97 C3 0A 1D EE F A AE pode-se ver, então, o protocolo criado: Comando Id do Terminal Id do Aplicativo Expiração Assinatura do servidor FD 20 4F A0 22 3A 7E 12 5B FA 7 Senha Assinatura do celular FA 7C 97 C3 0A 1D EE F A AE 4.2 Testes da comunicação NFC Para teste da velocidade de comunicação via NFC, implementou-se uma rotina no Android para calcular o tempo que cada parte da comunicação levava. Não foi feito um teste criterioso com muitas medições e métodos estatísticos, apenas coletou-se a timestamp de cada evento, calculou-se a diferença e tirou-se uma média. O resultado dessas medidas podem ser vistas na tabela 19. Todos esses testes foram feitos com utilização do Arduino MEGA. O celular utilizado foi o Sansung Galaxy SIII rodando o sistema operacional Android Jelly Beam v Deve-se definir:

85 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 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 chaves que devem ser utilizadas para criptografia já foram geradas. Evento 3: Atividade de Envio Iniciada. O tempo para isso acontecer pode variar de acordo com a quantidade de memória disponível no celular. Evento 4: Preparado para envio. O Android já recebeu requisição do Servidor SNEP para envio da mensagem e o usuário já autorizou com um toque na tela. Evento 5: Mensagem criptografada e codificada. Em geral os processos de criptografia acontecem de forma bem rápida no Android, principalmente para um método rápido como o AES. Evento 6: Mensagem enviada. Foi recebida confirmação do Servidor SNEP que os dados foram enviados corretamente. Pode-se perceber que em nenhum dos 15 testes houve falha na comunicação, o que indica estabilidade do sistema. Apesar disso, foram detectadas algumas falhas em outros testes feitos e não documentados. Dessa forma, é sabido que o sistema pode apresentar instabilidades eventuais em algumas situações, o motivo destas ainda é desconhecido. Vê-se que o evento mais custoso em todo o processo é o 4. Isso se deve ao fato de que entre os eventos 1 e 4, o Arduino deve requisitar desconexão como cliente SNEP (o

86 84 Capítulo 4. Resultados e Testes Figura 36: Histograma dos dados da tabela 19 Android funciona como Servidor nessa fase) e requisitar conexão novamente, mas dessa vez como Servidor (após o evento 3, o Android deve funcionar como cliente SNEP). Apesar do baixo número de amostras, o histograma apresentado na figura 36 mostra a alta variação no tempo de comunicação. 4.3 Comunicação com o servidor Repetiu-se o mesmo processo de gerar timestamps para se fazer testes em relação conexão com a internet. Dessa vez agendou-se uma grande quantidade de conexões com o objetivo de testar as velocidades de conexão utilizando WiFi e Dados móveis. resultados medidos podem ser vistos na tabela 20. Para esse teste também foi utilizado o celular Sansung Galaxy SIII rodando o sistema operacional Android Jelly Beam v 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 5 WiFi Dados móveis *Valores em ms (mili segundos) Os Evento 1: Inicio da tentativa de conexão. Esse é o referencial utilizado, considerado o tempo zero.