Utilização de Near-Field Communication em Dispositivos Móveis

UNIVERSIDADE PRESBITERIANA MACKENZIE
ROGER TADEU DOS SANTOS
UTILIZAO DE NEAR-FIELD COMMUNICATION

EM DISPOSITIVOS MVEIS
So Paulo
2012
UTILIZAO DE NEAR-FIELD COMMUNICATION EM

DISPOSITIVOS MVEIS
Trabalho de Concluso de Curso de Ps

Graduao
apresentado
Presbiteriana
Mackenzie
parcial
para
Especialista
obteno
em
Universidade
como
do
requisito
ttulo
Projeto
Desenvolvimento de Sistemas
ORIENTADOR: Prof. Dr. Ismar Frango Silveira
So Paulo
2012
de
e
UTILIZAO DE NEAR-FIELD COMMUNICATION EM

DISPOSITIVOS MVEIS
Trabalho de Concluso de Curso de Ps

Graduao
apresentado
Presbiteriana
Mackenzie
parcial
para
Especialista
obteno
em
Universidade
como
do
requisito
ttulo
Projeto
Desenvolvimento de Sistemas
Aprovada em 01 de novembro de 2012.
BANCA EXAMINADORA
_____________________________________________
Prof. Dr. Ismar Frango Silveira
Universidade Presbiteriana Mackenzie
_____________________________________________
Profa. Ms. Ana Cludia Rossi
Universidade Presbiteriana Mackenzie
de
e
minha famlia, pelo constante incentivo e

apoio; a meus amigos, pela confiana na
realizao deste trabalho.
AGRADECIMENTOS
Ao Dr. Ismar Frango Silveira, minha eterna gratido, por ter sido professor e orientador
que, com sua competncia, me fez concluir esta empreitada.
Ms. Ana Cludia Rossi, pelo constante acompanhamento do desenvolvimento deste
trabalho.
Ao Adrian Stabiszewski, pelo suporte prestado na utilizao de suas bibliotecas e apoio
no desenvolvimento deste trabalho.
Ao Michael Rafael Ruiz, pelo suporte ao desenvolvimento de software para leitores
NFC da ACS.
Ao Luiz Carlos Cotrim Guimares Junior, pelo apoio ao desenvolvimento do framework
para o SQLite da plataforma Android.
Ao Paulo Henrique Martins, grande amigo, pelo incentivo realizao deste trabalho.
RESUMO
O objetivo deste trabalho o estudo da tecnologia Near-Field Communication para

construo de uma aplicao para dispositivos mveis com funcionalidades relativas a
pagamentos de tarifas de sistemas de transportes. Um sistema ser desenvolvido para
dar suporte utilizao de dispositivos mveis, tags e um leitor NFC. Este sistema ser
construdo com uma arquitetura de integrao entre os dispositivos NFC utilizados e
utilizar os modos de operao peer-to-peer e leitura/escrita da tecnologia NFC. A
aplicao ser apoiada por um dispositivo mvel com a plataforma Android, atravs da
utilizao de sua API para NFC, por um leitor NFC conectado a um computador e por
tags NFC. Ao final deste estudo ser feita uma anlise de implantao da soluo
fornecida e das vantagens e desvantagens do emprego desta tecnologia.
Palavras-chave: Near-Field Communication, NFC, contactless, dispositivos mveis,
Android
ABSTRACT
The goal of this work is the study of Near-Field Communication technology to build an
application for mobile devices supporting payments of transport systems tariffs. A
system will be developed to support the use of mobile devices, tags and a NFC reader.
This system will be built with an integration architecture between the devices used and
will use peer-to-peer and read/write operating modes of NFC. The application will be
supported by a mobile device based on the Android platform by using its API for NFC,
a NFC reader connected to a computer and NFC tags. By the end of this study an
analysis will be in order to evaluate the deployment of the solution provided and the
advantages and disadvantages of the use of this technology.
Keywords: Near-Field Communication, NFC, contactless, mobile devices, Android
LISTA DE ILUSTRAES
Figura 1 - O smbolo da tecnologia NFC, conhecido como N-mark .............................. 17

Figura 2 - Google Wallet: um servio de pagamento eletrnico com NFC .................... 19
Figura 3 - Comparao de distncia e taxa de transferncia das tecnologias wireless 29
Figura 4 - Arquitetura de um dispositivo mvel com NFC ............................................. 34
Figura 5 - Diferena entre a arquitetura NFC de dispositivos mveis seguros e no
seguros ......................................................................................................................... 35
Figura 6 - Dispositivos com arquiteturas NFC seguras ................................................. 36
Figura 7 - Pilha de protocolos do modo leitura/escrita .................................................. 41
Figura 8 - Representao de uma mensagem NDEF ................................................... 43
Figura 9 - Representao de um registro NDEF ........................................................... 45
Figura 10 - Pilha de protocolos do modo peer-to-peer .................................................. 49
Figura 11 - Pilha de protocolos do modo emulao de cartes .................................... 54
Figura 12 - Arquitetura da plataforma Android .............................................................. 65
Figura 13 - Ciclo de vida de uma atividade do Android ................................................. 70
Figura 14 - Funcionamento do mecanismo de despacho de mensagens ..................... 80
Figura 15 - Dispositivos NFC utilizados para o desenvolvimento.................................. 81
Figura 16 - Estrutura de um comando APDU ................................................................ 83
Figura 17 - Estrutura de uma resposta para um comando APDU ................................. 84
Figura 18 - Diagrama de casos de uso do sistema ....................................................... 88
Figura 19 - Diagrama de implantao do sistema ......................................................... 90
Figura 20 - Diagrama de atividades do caso de uso Solicitar Pagamento .................. 91
Figura 21 - Tela gerada pelo Android para permitir o envio da mensagem NDEF ........ 94
Figura 22 - Abas da tela principal da aplicao............................................................. 95
Figura 23 - Tela de configurao de conta de usurio .................................................. 96
Figura 24 - Tela de compra de crditos......................................................................... 97
Figura 25 - Tela de configurao da aplicao ............................................................. 98
Figura 26 - Tela gerada a partir dos dados fornecidos pelo GPS do dispositivo ........... 99
Figura 27 - Log de estabelecimento de conexo SNEP para envio de mensagem NDEF

.................................................................................................................................... 101
Figura 28 - Diagrama de componentes do sistema ..................................................... 104
Figura 29 - Pilha de protocolos para o modo peer-to-peer do sistema de pagamentos
.................................................................................................................................... 105
Figura 30 - Formato de uma mensagem de pagamento ............................................. 106
Figura 31 - Diagrama de classes do pacote org.mackenzie.protocol .......................... 108
Figura 32 - Diagrama de clases do pacote org.mackenzie.crypto ............................... 111
Figura 33 - Diagrama de classes do pacote org.nfc.mackenzie.context ..................... 112
Figura 34 - Diagrama de classes do pacote org.nfc.mackenzie.backend ................... 114
Figura 35 - Diagrama de classes da camada de acesso aos dados ........................... 116
Figura 36 - Diagrama de classes da camada de regras de negcio ........................... 117
Figura 37 - Diagrama de classes da camada de apresentao .................................. 118
LISTA DE ABREVIATURAS
AES
ARR
APDU
ABM
CSMA
ECDH
ECMA
ETSI
XML
GPS
GSM
HDLC
HC
HCI
HCP
IEC
ISO
IP
JIS
JCE
LLCP
NDK
NPP
NFC
NFCIP
NFC
NFC CLF
NDEF
NFC HAL
NFC-WI
ORM
OHA
OTA
PC/SC
PCD
PICC
QR Code
RFID
RF
Advanced Encryption Standard

Android Application Record
Application Protocol Data Unit
Asynchronous Balanced Mode
Carrier Sense Multiple Access
Elliptic Curve Diffie-Hellman
European Computer Manufacturers Association
European Telecommunications Standards Institute
eXtensible Markup Language
Global Positioning System
Global System for Mobile Communications
High-Level Data Link Control
Host Controller
Host Controller Interface
Host Controller Protocol
International Electrotechnical Comission
International Organization of Standardization
Internet Protocol
Japanese Industrial Standards
Java Criptography Extension
Logical Link Layer Protocol
Native Development Kit
NDEF Push Protocol
Near Field Communication
Near Field Communication Interface and Protocol
Near-Field Communication
NFC Contactless Front-end
NFC Data Exchange Format
NFC Hardware Abstraction Layer
NFC Wired Interface
Object Relational Mapping
Open Handset Alliance
Over The Air
Personal Computer/Smart Card
Proximity Coupling Device
Proximity Integrated Circuit Card
Quick Response Code
Radio Frequency Identification
Radiofrequncia
RTD
SMC
SE
SDP
SNEP
SWP
SIM
TNF
UICC
VCD
VPN
Record Type Definition

Secure Memory Card
Security Element
Service Discovery Protocol
Simple NDEF Exchange Protocol
Single Wire Protocol
Subscriber Identity Module
Type Name Format
Universal Integrated Circuit Card
Vicinity Coupling Device
Virtual Private Network
SUMRIO
1.
INTRODUO ............................................................................................. 15
2.
NFC .............................................................................................................. 17
2.1.
HISTRICO ................................................................................................. 20
2.2.
PADRONIZAO ........................................................................................ 22
2.2.1.
NFCIP-1 ....................................................................................................... 24
2.2.2.
NFCIP-2 ....................................................................................................... 25
2.2.3.
NFC-SEC ..................................................................................................... 26
2.2.4.
ISO/IEC 14443 ............................................................................................. 26
2.3.
COMPARAO COM OUTRAS TECNOLOGIAS ...................................... 28
2.4.
TIPOS DE DISPOSITIVOS .......................................................................... 30
2.4.1.
Classificao dos dispositivos ...................................................................... 31
2.5.
ARQUITETURA ........................................................................................... 33
2.5.1.
Security Element .......................................................................................... 34
2.5.2.
Interface NFC ............................................................................................... 37
2.5.3.
Interface entre SE e NFC Controller ............................................................. 37
2.5.4.
Host Controller e HCI ................................................................................... 39
2.6.
MODOS DE OPERAO ............................................................................ 39
2.6.1.
Leitura/Escrita .............................................................................................. 40
2.6.1.1.
Tags Suportadas .......................................................................................... 41
2.6.1.2.
NDEF............................................................................................................ 42
2.6.2.
Peer-to-peer ................................................................................................. 48
2.6.2.1.
Logical Link Control Protocol ........................................................................ 49
2.6.2.2.
Simple NDEF Exchange Protocol................................................................. 51
2.6.2.3.
NDEF Push Protocol .................................................................................... 52
2.6.3.
Emulao de cartes .................................................................................... 53
2.7.
SEGURANA .............................................................................................. 55
2.8.
FRAMEWORKS NFC................................................................................... 57
2.8.1.
Open NFC .................................................................................................... 58
2.8.2.
LibNFC ......................................................................................................... 59
3.
DESENVOLVIMENTO PARA DISPOSITIVOS MVEIS ............................. 60
3.1.
PLATAFORMA ANDROID........................................................................... 62
3.1.1.
Open Handset Alliance ................................................................................. 63
3.1.2.
Arquitetura .................................................................................................... 64
3.1.2.1.
Linux Kernel ................................................................................................. 65
3.1.2.2.
Bibliotecas nativas ........................................................................................ 66
3.1.2.3.
Android Runtime........................................................................................... 67
3.1.2.4.
Framework de aplicao .............................................................................. 68
3.1.2.5.
Aplicaes e widgets .................................................................................... 68
3.1.3.
Ciclo de vida da aplicao ............................................................................ 69
3.1.4.
Blocos de Construo .................................................................................. 74
3.1.5.
Recursos ...................................................................................................... 75
3.1.6.
Segurana .................................................................................................... 75
3.1.7.
Suporte ao NFC ........................................................................................... 76
3.1.7.1.
Sistema de despacho de mensagens .......................................................... 78
4.
DESENVOLVIMENTO DA APLICAO ..................................................... 81
4.1.
AMBIENTE................................................................................................... 81
4.1.1.
Leitor NFC .................................................................................................... 82
4.1.1.1.
Comunicao ............................................................................................... 83
4.1.2.
Dispositivo mvel ......................................................................................... 84
4.1.3.
Tags ............................................................................................................. 85
4.1.4.
Bibliotecas .................................................................................................... 86
4.2.
O SISTEMA.................................................................................................. 88
4.2.1.
A aplicao do dispositivo mvel.................................................................. 92
4.2.2.
A aplicao do leitor NFC ............................................................................. 99
4.3.
DESENVOLVIMENTO ............................................................................... 101
4.3.1.
O protocolo de comunicao ...................................................................... 104
4.3.2.
Apresentao dos pacotes ......................................................................... 108
4.3.2.1.
Pacote org.mackenzie.protocol .................................................................. 108
4.3.2.2.
Pacote org.mackenzie.crypto ..................................................................... 110
4.3.2.3.
Pacote org.nfc.mackenzie.context .............................................................. 112
4.3.2.4.
Pacote org.nfc.mackenzie.backend............................................................ 113
4.3.2.5.
Pacote org.nfc.mackenzie .......................................................................... 115
5.
CONCLUSO E TRABALHOS FUTUROS ............................................... 120
6.
REFERNCIAS .......................................................................................... 122
15
1.
INTRODUO
Os dispositivos mveis esto cada vez mais presentes e com maior poder de
processamento. Os mais avanados j possuem um poder de processamento
semelhante ao de alguns computadores modernos, utilizam processadores de vrios
ncleos, processadores grficos dedicados e tambm possuem um grande espao de
armazenamento. Grande parte destes dispositivos possui sensores e outros elementos
para controle do aparelho que tambm podem ser utilizados para melhor interao do
usurio com o dispositivo, como por exemplo, sensor de proximidade, luminosidade,
acelermetro,
giroscpio,
Global
Positioning
System
(GPS)
Near-Field
Communication (NFC). Existem aplicativos desenvolvidos para tais plataformas que

baseiam suas funcionalidades em um ou mais destes recursos para fornecer uma
experincia ainda melhor para o usurio.
Dentre todos estes recursos disponveis em dispositivos mveis, o NFC tem grande
destaque e est ganhando importncia nos ltimos anos, no s entre pesquisadores,
mas no mercado de fabricantes de dispositivos mveis tambm, pois empresas que
so referncias na rea de tecnologia, como o Google, possuem dispositivos ou
sistemas com suporte a este recurso. No final de 2010, o Google lanou seu primeiro
aparelho com suporte a NFC, o Galaxy Nexus. Alm disso, o Google j lanou
aplicativos que utilizam este recurso.
NFC uma tecnologia de comunicao sem fio de curto alcance que possibilita a troca
de informaes entre dois dispositivos de maneira simples e intuitiva. Os usurios de
dispositivos com NFC precisam apenas aproximar seus aparelhos de outros
dispositivos com o mesmo recurso para que seja iniciada a comunicao. Esta
praticidade proporciona a criao de diversas aplicaes. Atravs da tecnologia NFC
possvel substituir algumas tarefas do cotidiano de um usurio pela utilizao de
dispositivos mveis com a tecnologia NFC. Por exemplo, o ato de realizar o pagamento
da tarifa de um transporte coletivo atravs de um smartcard contactless pode ser
substitudo com a utilizao de um dispositivo mvel atravs do mesmo gesto de
aproximao de dispositivo.
16
Baseada no recurso NFC, uma aplicao para dispositivos mveis ser desenvolvida e
permitir pagamentos de tarifas associadas utilizao de meios de transporte
coletivos, como nibus ou trens. De maneira complementar, para comunicao com o
dispositivo mvel, ser desenvolvida outra aplicao com a utilizao de um leitor NFC
que representar uma catraca do meio de transporte. Um sistema com suporte
tecnologia NFC para realizao de pagamentos consequentemente utilizar mais de
um tipo de dispositivo em sua arquitetura, at porque o NFC compatvel com algumas
tecnologias de smartcards contactless. Esta caracterstica proporciona suporte s
infraestruturas de sistemas baseados em pagamentos com smartcards contactless ao
mesmo tempo em que a tecnologia NFC introduzida. Portanto, este ambiente
abrigar um sistema com uma arquitetura heterognea por parte dos dispositivos
utilizados, mas homognea quanto ao meio de comunicao.
Este trabalho resultar em um sistema com uma arquitetura de integrao entre
dispositivos com suporte a tecnologia NFC. Uma aplicao ser construda com base
na plataforma Android para dispositivos mveis, atravs da utilizao de sua API para
NFC. O leitor NFC estar conectado a um computador pessoal e tambm ter uma
aplicao de apoio utilizao do dispositivo mvel como forma de pagamento. Apesar
de integrar elementos como internet, servios de autenticao e tags NFC, este
trabalho no tem como objetivo estud-los especificamente. Estes elementos sero
utilizados apenas para analisar a viabilidade de sua utilizao na aplicao e seu
impacto na arquitetura do sistema.
Parte do desafio em desenvolver um sistema com base na tecnologia NFC est na
escassez de livros sobre o assunto. Como a especificao da tecnologia NFC est em
constante evoluo e o aumento de sua popularidade algo relativamente recente,
existem poucas publicaes sobre o assunto. Entretanto, h interesse de diversas
empresas do setor e uma ampla quantidade de estudos sobre o assunto.
Ao final deste estudo ser feita uma anlise de implantao da soluo desenvolvida
em transportes coletivos e das vantagens e desvantagens do emprego desta
tecnologia.
17
2.
NFC
O NFC, tambm chamado de comunicao por campo de proximidade, uma

tecnologia de comunicao sem fio e sem contato de curto alcance, que possibilita a
troca de informaes entre dois dispositivos. Basta que haja uma aproximao de dois
dispositivos NFC para que seja iniciada a comunicao.
Figura 1 - O smbolo da tecnologia NFC, conhecido como N-mark
A comunicao NFC envolve sempre dois dispositivos e a transferncia de dados entre

eles bidirecional, em uma distncia que vai de 0 cm at 10 cm, dependendo dos
dispositivos utilizados (COSKUN, 2012). Atua na faixa dos 13.56 MHz, frequncia que
livre de restries na maior parte do mundo, com taxas de transferncias que variam
de 106 a 424 kbit/s (COSKUN, 2012). Suas principais utilidades so a transmisso de
uma pequena quantidade de dados e a iniciao de uma conexo secundria. Essas
caractersticas podem ser utilizadas como ponto de partida para uma srie de outras
aplicaes, o que torna o uso da tecnologia NFC muito diversificado.
A tecnologia NFC funciona de maneira intuitiva: dois dispositivos NFC iniciam uma
comunicao imediatamente aps terem sido aproximados, sem a necessidade de um
toque fsico ocorrer. Essa aproximao o ponto de partida para qualquer
comunicao NFC e a caracterstica mais importante da tecnologia. A ideia principal
de uso de NFC, embora existam diferentes modos de operao, consiste em ter uma
aplicao em um dispositivo mvel, que ao ser aproximado de outro dispositivo NFC
que tenha a informao necessria para o processamento da aplicao, a mesma seja
automaticamente inicializada e realize o processamento automtico da informao
18
recebida sem que haja interao do usurio com o dispositivo mvel. O usurio pode
aproximar o dispositivo mvel a outros dispositivos como tags NFC, leitores NFC ou at
mesmo outros dispositivos mveis NFC, e com base apenas nesta ao, obter o
resultado esperado, como realizar um pagamento por exemplo.
Esta praticidade proporciona a criao de diversas aplicaes, pois atravs do NFC,
uma interao especial entre o ser humano e o computador estabelecida. Esta
interao recebe o nome de computao ubqua. Segundo (COSKUN, 2012), o NFC
um dos caminhos para se atingir a computao ubqua.
Como esta tecnologia proporciona uma comunicao em pequenas distncias, o risco
de uma interceptao dos dados sendo transferidos, apesar de existir, relativamente
pequeno porque o dispositivo interceptador precisaria estar posicionado dentro do
alcance do outro dispositivo. Seu principal uso tende a ser em aplicaes que utilizem
informaes confidenciais, como pagamento atravs de dispositivos mveis, porm,
medida que novas aplicaes so desenvolvidas, novas interaes com esta tecnologia
podem ser estabelecidas. J possvel encontrar jogos que a utilizem, como o Angry
Birds produzido pela Rovio. De fato, o uso de um dispositivo NFC em um ambiente
habilitado para esta tecnologia pode facilitar vrias tarefas do cotidiano do usurio,
como por exemplo:
Baixar contedo multimdia de um cartaz ou pster;
Trocar contatos entre telefones;
Efetuar pagamento em meios de transporte, bilheterias, entre outros;
Imprimir um documento em uma impressora compatvel;
Parear dispositivos Bluetooth;
19
Figura 2 - Google Wallet: um servio de pagamento eletrnico com NFC
Do ponto de vista tcnico, o NFC pode ser visto como extenso da tecnologia Radio
Frequency Identification (RFID). O RFID tambm uma tecnologia de comunicao
sem contato, que combina um pequeno chip de identificao com um leitor em um
nico dispositivo e pode ter um alcance de muitos metros de distncia, desde que se
tenha uma fonte de energia externa, o que torna seu uso bastante diferenciado.
O NFC utiliza o conceito fsico de campo de induo magntica para fazer com que
dois dispositivos se comuniquem. Um dos principais objetivos desta tecnologia fazer
com que os benefcios da comunicao sem fio do RFID sejam estendidos s tarefas
do cotidiano do usurio, substituindo e buscando simplificar diversas interaes com o
meio fsico. Mesmo com o RFID sendo amplamente utilizado, principalmente em
tarefas como deteco ou rastreio de produtos, a introduo do NFC prope diversas
maneiras diferentes de utilizao por causa da distncia menor e pela possibilidade de
haver inteligncia e poder de processamento nos dois lados da comunicao.
Dispositivos NFC tambm podem substituir alguns tipos de smartcards que so
amplamente utilizados por sistemas de transporte, por exemplo. Alm disso, capaz
de prover segurana quanto transmisso e armazenamento de dados, conforme
especificao da tecnologia.
20
O NFC tambm pode ser utilizado em conjunto com outros protocolos para selecionar
dispositivos e automatizar os processos de configurao. Por exemplo, os parmetros
para estabelecimento de conexo com uma rede wireless podem ser transmitidos
atravs da comunicao com outro dispositivo NFC, como uma tag NFC. A
configurao de uma rede wireless normalmente exige uma interao razovel do
usurio, como busca de rede adequada e configurao de usurio e senha, e o uso da
tecnologia NFC permite que essa interao seja simplificada para uma simples
aproximao de dispositivos. Outro fator importante que o tempo gasto para
estabelecimento de conexo menor que 0,1s, ou seja, extremamente baixo em
comparao com o protocolo de comunicao Bluetooth, que pode atingir at 6s
(ATOJI, 2010).
2.1. HISTRICO
O NFC pode ser compreendido como uma extenso da tecnologia RFID que tambm
capaz de interagir com interfaces baseadas em smartcards. Em resumo, o NFC herda
um pouco do conceito de cada uma destas tecnologias, que sero brevemente
apresentadas a seguir. Quanto ao RFID, pode-se entender que o cdigo de barras foi
seu precursor enquanto o carto magntico foi o precursor dos smartcards (COSKUN,
2012).
O cdigo de barras nada mais do que uma representao visual de dados relativos
ao objeto em que ele est associado. Esta informao interpretada por leitores de
cdigos de barras e transferida para computadores, que a processam ou enviam para
outros dispositivos e sistemas. Inicialmente os cdigos de barras possuam apenas
uma dimenso, e eram representados por listras verticais paralelas que variaram sua
largura e espaamento. Em seguida, evoluiu para cdigos de barras bidimensionais,
como o Quick Response Code (QR Code), e passou a ter a capacidade de armazenar
mais informaes.
O RFID por sua vez, uma tecnologia que usa comunicao atravs de ondas de rdio
para trocar dados entre um leitor e uma tag RFID. A transmisso de dados resultado
das ondas eletromagnticas, cuja distncia varia de acordo com a frequncia e o
campo magntico. Suas tags so pequenos circuitos que podem conter aplicaes ou
21
dados. Nesta tecnologia existem tags passivas e ativas. As passivas tm um circuito
integrado e uma antena, mas no tem fonte prpria de energia e podem se comunicar
apenas atravs de um campo eletromagntico, em uma distncia que pode chegar at
alguns metros. As ativas tem sua prpria fonte de energia e podem atingir distncias
maiores. So consideradas mais confiveis pelo fato de poderem manter uma sesso
de comunicao com energia prpria. O uso da tecnologia RFID est mais relacionado
s aplicaes de controle de estoque, pedgios, transporte e at mesmo rastreio de
animais.
O carto magntico um carto que contm um espao para armazenamento de
informao em pequenas partculas magnticas ligadas a uma resina. Os dados so
lidos quando o carto deslizado pela interface de um dispositivo de leitura magntica.
A informao presente no carto gravada no momento de sua confeco e nunca
mais sobrescrita. Cartes bancrios so os maiores exemplos de uso desta
tecnologia.
J os smartcards contm um circuito integrado com memria embutida, e geralmente
possuem um micro controlador para segurana. Podem ser divididos em trs grupos:
de contato, contactless (sem contato) e hbrido. Um smartcard de contato se comunica
com um leitor de cartes atravs de contato fsico direto e o leitor que prov a energia
necessria para o funcionamento do carto. No caso dos smartcards contactless, a
comunicao ocorre quando o carto aproximado do dispositivo de leitura. Este leitor
emite um campo eletromagntico que serve como fonte de energia para o
funcionamento do carto. J um smartcard hbrido suporta os dois modos de
funcionamento anteriores, podendo variar o nvel de segurana requerido para algum
deles.
Com um breve conhecimento destas tecnologias possvel identificar diversas
caractersticas que foram aproveitadas no NFC. Dispositivos NFC tambm podem ter
fonte prpria de energia, assim como as tags RFID, e podem ter um chip dedicado para
segurana em sua arquitetura, como nos smartcards. Tanto na tecnologia RFID quanto
em smartcards contactless, existe o conceito de comunicao por proximidade,
presente em NFC. O NFC utiliza a mesma frequncia do RFID, que de 13.56MHz
22
com uma taxa de transferncia de dados de 106, 212 ou 424 kbit/s, que limita seu uso
para transferncia de informaes pequenas. Existem diferentes modos de
funcionamento para comunicao entre dispositivos mveis, tags e leitores compatveis
com NFC. Entretanto, as aplicaes desenvolvidas para NFC tendem a ter propsitos
diferentes por causa da caracterstica da distncia, que curta e principalmente, por
causa do suporte comunicao peer-to-peer.
2.2. PADRONIZAO
A tecnologia NFC foi desenvolvida pela Philips em conjunto com a Sony, no final de
2002, com a finalidade de estabelecer um padro para a comunicao do tipo
contactless. O termo contactless utilizado para designar a comunicao que ocorre
pela proximidade de dois dispositivos sem que haja algum toque fsico.
O final de 2002 representa o incio da padronizao da tecnologia, pois foi nesta data
que a European Computer Manufacturers Association (ECMA) adotou a tecnologia
como um padro. Ao final do ano seguinte, em dezembro de 2003, foi a vez da
International Organization of Standardization (ISO) e da International Electrotechnical
Comission (IEC) adotarem a tecnologia como um padro. Alm destas, a European
Telecommunications Standards Institute (ETSI) tambm reconhece o NFC. Para
promover a tecnologia, as empresas Nokia, Philips e Sony fundaram o NFC Forum em
2004.
O NFC o resultado da juno de vrias outras tecnologias (COSKUN, 2012).
Smartcards, dispositivos mveis, leitores de carto, comunicao de curto alcance,
segurana de comunicao, transaes e sistemas de pagamento esto entre as
motivaes para o surgimento do NFC. De fato, a tecnologia NFC depende de muitas
destas tecnologias para existir e por este motivo que diversas organizaes
diferentes esto envolvidas direta ou indiretamente na padronizao e na evoluo do
NFC.
Estas organizaes so responsveis por estabelecerem os padres de suas
respectivas tecnologias e o resultado da juno de todas essas tecnologias serve para
definir uma viso comum para o uso do NFC, de maneira segura e funcional. Estes
23
diversos padres devem ser interoperveis para que se estabelea um ecossistema
NFC com sucesso. Dentre estas organizaes, podemos destacar:
NFC Forum: a principal aliana utilizada para especificar os padres NFC.

Promove o uso da tecnologia NFC atravs da definio de especificaes que
garantem a interoperabilidade entre dispositivos e servios. Atravs deste frum
j foram especificados os modos de operao peer-to-peer e leitura/escrita. Para
o modo leitura/escrita, definiram as especificaes Record Type Definition (RTD)
e NFC Data Exchange Format (NDEF) enquanto para o modo peer-to-peer
definiram a especificao Logical Link Control Protocol (LLCP). Tambm
definiram o smbolo da tecnologia NFC, para que seja imediatamente
reconhecida pelas pessoas;
GlobalPlatform: uma associao sem fins lucrativos que identifica, desenvolve

e publica especificaes que facilitam o desenvolvimento de aplicaes
interoperveis e seguras e o gerenciamento de mltiplas aplicaes embutidas
em smartcards seguros;
GSM Association: uma associao de operadoras de celular e empresas

relativas ao ramo que oferecem suporte padronizao, desenvolvimento e
promoo da tecnologia Global System for Mobile Communications (GSM).
Representa os interesses destas empresas e tem o objetivo de direcionar o
crescimento da indstria de comunicao mvel;
ISO/IEC: ISO a maior organizao para definio de padres no mundo. Como

uma organizao no governamental, estabelece a ponte entre os interesses
pblicos e privados. Em conjunto com a IEC, que prepara as especificaes
relativas eletrnicos, fornecem as especificaes do NFC;
ECMA International: uma organizao sem fins lucrativos para padronizao

de sistemas de informaes e comunicaes. Publica relatrios tcnicos e
realiza estudos sobre dispositivos mveis e NFC;
ETSI e ETSI Smart Card Platform: uma organizao sem fins lucrativos que
produz padres para tecnologias de informaes e comunicaes, incluindo
telefonia mvel e fixa, rdio e internet. Gerencia a especificao do carto
24
Subscriber Identity Module (SIM) e poderia permitir que cartes SIM
contivessem aplicaes NFC;
Java Community Process (JCP): responsvel pelo desenvolvimento da

tecnologia Java, que por sua vez, forte candidata para as aplicaes NFC;
Open Mobile Alliance (OMA): desenvolve padres abertos para a indstria de

telefonia mvel;
3rd Generation Partnership Project (3GPP): uma colaborao entre grupos de

telecomunicaes para criar uma nova gerao da especificao para
dispositivos mveis. Suas especificaes so baseadas nos avanos da
tecnologia GSM;
EMVCo: seu objetivo prover interoperabilidade entre smartcards e terminais de

leitura em nvel global, independentemente do fabricante, instituio financeira
ou emissor do carto.
Vrios padres j foram definidos para a comunicao entre dois dispositivos NFC,
dentre eles o Near Field Communication Interface and Protocol (NFCIP), que contm
as especificaes mais importantes da tecnologia. Estes padres definem, na camada
fsica da arquitetura NFC, os modos de comunicao do campo eletromagntico e
outras questes tcnicas associadas.
O NFCIP subdividido em dois padres: o NFCIP-1 e o NFCIP-2. Os dispositivos NFC
precisam atender essas especificaes para serem compatveis com o padro
internacional para interoperabilidade com smartcards, cartes de proximidade (ISO/IEC
14443), cartes de vizinhana (ISO/IEC 15693) e tambm para os cartes contacless
Sony FeliCa (JIS X 6319). Sendo assim, com esta combinao de diferentes
tecnologias baseadas em comunicao contactless e smartcards, o NFC compatvel
com as tecnologias mais utilizadas no mercado, oferecendo compatibilidade com
infraestruturas e sistemas j em funcionamento (KORTVEDT, 2009).
2.2.1. NFCIP-1
Em NFCIP-1 esto definidos os modos de comunicao ativo e passivo, o campo
eletromagntico, os sinais de comunicao da interface do campo eletromagntico e o
fluxo geral do protocolo. Alm disso, define um protocolo de transporte que inclui
25
ativao do protocolo, troca de dados, deteco de erros e desativao do protocolo. O
NFCIP-1 est padronizado em ISO/IEC 18092, ECMA 340 e ETSI TS 102 190.
A pilha de protocolos presente nesta especificao baseada na ISO/IEC 14443 e a
diferena principal est nos protocolos de comando. Isto permite que os dispositivos
NFCIP-1 sejam capazes de se comunicar com algumas tags e smartcards, alm de
outros dispositivos em modo peer-to-peer.
Dentre as caractersticas da comunicao que esto especificadas neste padro,
podemos destacar os esquemas de modulao, a taxa de transferncia, a codificao
dos bits, a inicializao e a finalizao da comunicao, a representao dos bits, o
enquadramento dos dados, a deteco de erros, seleo de protocolos, seleo dos
parmetros e troca de dados.
As taxas de transferncia de dados tambm esto definidas neste padro. Durante
uma comunicao, a taxa de transferncia pode ser alterada pelos dispositivos
envolvidos, porm a classificao do modo de comunicao no pode ser alterada
durante uma comunicao, j que o ponto de partida para o incio da mesma.
2.2.2. NFCIP-2
Em NFCIP-2 est definido o mecanismo de seleo de modo de comunicao. Este
mecanismo foi projetado para no interromper alguma comunicao j existente na
frequncia de 13.56MHz para dispositivos que implementem o NFCIP-1, o Proximity
Coupling Device (PCD) e o Vicinity Coupling Device (VCD). O NFCIP-2 est
padronizado em ISO/IEC 21481, ECMA 352 e ETSI TS 102 312, enquanto o PCD est
padronizado em ISO/IEC 14443 e o VCD est padronizado em ISO/IEC 15693.
Dispositivos que seguem as especificaes de NFCIP-2 precisam implementar
algumas caractersticas de ISO/IEC 14443, ISO/IEC 15693 e tambm as funes de
iniciador e alvo definidas em ECMA 340. Isto faz com que este dispositivo seja
compatvel com aplicaes que utilizam tecnologia Sony FeliCa ou MIFARE.
Apesar de todos os padres com os quais o NFCIP-2 compatvel utilizarem a mesma
frequncia de comunicao, os modos de comunicao so diferentes. Portanto, esta
especificao utiliza o protocolo Carrier Sense Multiple Access (CSMA) para garantir
26
que um campo eletromagntico no seja iniciado se o dispositivo detectar uma
comunicao em andamento.
A comunicao segue um princpio de escutar antes de falar. Se um dispositivo
pretende se comunicar, ele deve se certificar que no existe nenhum campo
eletromagntico ao seu redor, para que no haja interferncia em outra comunicao
que esteja em andamento. O dispositivo permanecer parado enquanto detectar outro
campo eletromagntico e aguardar o trmino da comunicao. Se outros dois
dispositivos responderem a solicitao de comunicao enviada, o dispositivo iniciador
da comunicao detectar que houve uma coliso e no continuar a comunicao at
que haja apenas uma resposta em um perodo de tempo determinado com preciso.
2.2.3. NFC-SEC
O protocolo NFC-SEC foi desenvolvido para fornecer segurana em comunicaes
peer-to-peer. Como o NFCIP-1 no prov segurana, o protocolo NFC-SEC serve para
complementar este aspecto. Este padro define uma pilha de protocolos que
possibilitam o uso de funes de criptografia, definidas pela aplicao, na camada de
enlace.
O NFC-SEC constitudo por dois protocolos: NFC-SEC e NFC-SEC-01. O NFC-SEC
define os servios de segurana como proteo contra espionagem e alterao de
dados e est padronizado em ECMA 385. O NFC-SEC-01 est padronizado em ECMA
386 e define os servios de criptografia utilizando algoritmos como Elliptic Curve DiffieHellman (ECDH) e Advanced Encryption Standard (AES). Este protocolo define os
mecanismos de criptografia que definem o uso de protocolo ECDH para troca de
chaves e o algoritmo AES para criptografia de dados e integridade. O protocolo
tambm prev o uso de outros algoritmos de criptografia no futuro atravs de um
campo identificador.
2.2.4. ISO/IEC 14443
Este
padro
internacional
foi
desenvolvido
para
suportar
comunicao
por
radiofrequncia (RF) na frequncia 13.56MHz. Essa comunicao baseada em

acoplamento eletromagntico entre um carto de proximidade e um leitor, que utiliza
27
um micro controlador e uma antena que opera na frequncia especificada. Desta
forma, este padro permite que a troca de informaes ocorra sem que haja contato
entre os dispositivos. Neste padro, as transaes acontecem entre um carto e um
leitor, que so representados como Proximity Integrated Circuit Card (PICC) e PCD,
respectivamente.
Esta especificao composta pelas quatro partes seguintes:
Parte 1 Caractersticas Fsicas de Smartcards Contactless: define as

caractersticas fsicas dos smartcards, alm de requerimentos e testes que
precisam ser executados durante a fabricao dos cartes;
Parte 2 Interface de Energia e Sinal RF: determina como o carto recebe

energia do campo eletromagntico, define a interface de RF e os tipos de
sinalizao A e B. Estes tipos classificam os cartes em dois grupos distintos:
tipo A e tipo B;
Parte 3 Inicializao e Anti-Coliso: define os protocolos de inicializao e

tratamento anti-coliso pra os tipos A e B;
Parte 4 Protocolo de Transmisso: define os protocolos de alto nvel para

transmisso de dados para os tipos A e B. Estes protocolos so opcionais e os
cartes podem ou no oferecer suporte a esta parte da especificao.
Tecnologias diferentes surgiram para atender as especificaes dos smartcards, mas

apenas algumas so compatveis com a especificao do padro ISO/IEC 14443.
Algumas das principais so MIFARE e FeliCa.
MIFARE um tipo de smartcard contactless, que foi criado e continua sendo
desenvolvido pela NXP Semiconductors, que uma empresa ligada a Philips. MIFARE
obedece especificao ISO/IEC 14443 Tipo A. Contm uma famlia de cartes de
diferentes tipos e propsitos, como o Ultralight, Standard, DESFire, Classic, Plus e
SmartMX. Cartes baseados em MIFARE esto sendo utilizados principalmente em
solues para transporte, bilheterias, controle de acesso, pagamento virtual, pedgios
e programas de fidelidade.
FeliCa tambm um carto de proximidade que trabalha na frequncia 13.56MHz e
possui alta velocidade para operaes de leitura e escrita. desenvolvido pela Sony e
28
usado principalmente como cartes de dinheiro eletrnico. A Sony tentou lanar este
carto como ISO/IEC 14443 Tipo C, mas no obteve aprovao. Portanto, no se
tornou um padro ISO/IEC e apenas obedece ao padro japons X 6319, definido pela
entidade Japanese Industrial Standard (JIS), que especifica cartes de proximidade de
alta velocidade (COSKUN, 2012).
2.3. COMPARAO COM OUTRAS TECNOLOGIAS
Devido variedade de tecnologias baseadas em RF para estabelecer comunicao e
trocar informaes, foram criadas aplicaes para diversas funcionalidades, como
rastreio de animais e objetos, pagamento, identificao segura de pessoas, entre
outras. Entretanto, apesar de todas estas aplicaes utilizarem tecnologias que
dependam de ondas de rdio para transferncia de dados, a maneira como estas
ondas so utilizadas depende dos requisitos da aplicao. Isto significa que ainda que
existam vrias tecnologias baseadas em RF para troca de dados, cada uma tem sua
particularidade e por conta disso acabam sendo mais teis para um determinado tipo
de aplicao.
O RFID tem como elemento principal a tag RFID, que conhecida por ser simples, de
baixo custo e descartvel. Esta tag contm um circuito integrado com dados e uma
antena para enviar estes dados a um leitor. Assim que a tag entra no raio de ao de
um leitor, os dados armazenados so enviados para este leitor. No existe um
mecanismo de segurana ou autenticao nesta tecnologia, portanto qualquer leitor
compatvel capaz de obter o contedo presente na tag RFID.
Os smartcards do tipo contactless, por sua vez, tambm interagem com algum
dispositivo externo utilizando tecnologia RF. Porm, os smartcards tem um micro
controlador para segurana e uma memria interna, que so utilizados para gerenciar,
armazenar e fornecer acesso aos dados no carto. Alm disso, so capazes de realizar
tarefas computacionais mais complexas, como criptografia. A distncia para que o leitor
seja capaz de estabelecer uma comunicao com o carto de aproximadamente 10
cm, mas pode variar de acordo com o tipo de smartcard utilizado. Por causa disso,
estes smartcards costumam ser utilizados em aplicaes que exigem um alto nvel de
segurana, como documentos e solues de pagamento. O uso de smartcards
29
contactless em aplicaes implica em alta integridade e confidencialidade com relao
informao armazenada e transferida.
J o NFC tem como caractersticas mais importantes o pareamento automtico e a
segurana implcita devido pequena distncia com a qual se consegue comunicar
com outro dispositivo, que no precisa ser necessariamente um leitor. O NFC possui
baixas taxas de transferncia de dados na comunicao e atua sob distncias
pequenas. A comparao na imagem a seguir deixa mais clara o posicionamento da
tecnologia NFC perante outras tecnologias wireless (COSKUN, 2012):
Figura 3 - Comparao de distncia e taxa de transferncia das tecnologias wireless
Entretanto, o NFC possui um modo de comunicao peer-to-peer, onde dois

dispositivos ativos podem se comunicar. J nas tecnologias RFID e smartcards
contactless, a comunicao sempre ocorre atravs de um dispositivo passivo e um
leitor. Em outras palavras isto significa que no NFC, dois dispositivos com poderes
computacionais elevados podem estabelecer uma comunicao. Alm disso, leitores
NFC tambm so compatveis com tags RFID e smartcards contactless.
O recurso de pareamento automtico do NFC muito til para utilizao em aplicaes
para dispositivos mveis. Estas aplicaes podem ser executadas automaticamente,
assim que uma tag lida. Por exemplo, o browser de um celular pode ser
automaticamente executado assim que uma tag contendo um URL lida. Todo esse
processamento pode ocorrer sem a interao do usurio com o dispositivo e isto
possvel porque no NFC o pareamento automtico a partir do momento em que dois
dispositivos NFC so aproximados entre si. Com a tecnologia Bluetooth, por exemplo,
30
este tipo de interao seria mais complexo, pois implicaria em busca de dispositivos,
pedido de pareamento e autorizao.
Enquanto o NFC estabelece apenas redes ponto-a-ponto, o Bluetooth capaz de
estabelecer redes ponto-a-multiponto, possui o maior alcance e maior taxa de
transferncia. Por isto, o NFC no pode ser considerado um substituto do Bluetooth,
pois ambos tm finalidades distintas. Ao utilizar Bluetooth, geralmente necessrio
estabelecer um pareamento entre os dispositivos envolvidos, o que no ocorre no NFC,
pois a curta distncia j significa que houve a inteno de realizar a comunicao. Alm
disso, o Bluetooth no capaz de oferecer um modo de operao passivo assim como
o NFC, e tambm no a melhor escolha para aplicaes que exigem um elevado
nvel de segurana.
2.4. TIPOS DE DISPOSITIVOS
As partes envolvidas na comunicao NFC so chamadas de dispositivos NFC, e so
divididas em trs grupos distintos, descritos a seguir:
Dispositivos mveis NFC: so celulares ou smartphones que possuem a

tecnologia NFC integrada e podem ser considerados os principais dispositivos
do NFC. Atualmente estes dispositivos so responsveis por promover a
tecnologia e despertar interesse em fabricantes e usurios, pois celulares so
dispositivos com maior facilidade de utilizao e alcance;
Leitores NFC: um leitor NFC um dispositivo capaz de estabelecer

comunicao e realizar transferncia de dados com outro dispositivo NFC.
Geralmente est conectado a um computador e faz parte de um sistema,
atuando no papel de entrada e sada de dados. Exemplos comuns do uso destes
dispositivos so terminais de venda, onde o leitor utilizado para estabelecer a
ligao entre um sistema de pagamentos e um dispositivo mvel NFC para a
realizao de pagamentos;
Tags NFC: a tag NFC um dispositivo semelhante a uma tag RFID, onde no
h fonte de energia prpria, mas existe a capacidade de armazenamento
atravs de um pequeno circuito ativado por meio de campos eletromagnticos.
31
2.4.1. CLASSIFICAO DOS DISPOSITIVOS
Cada sesso de comunicao NFC composta por duas partes. Estas partes podem
ser classificadas sob duas perspectivas: uma delas baseada na capacidade de um
dispositivo NFC ter sua prpria fonte de energia e gerar seu prprio campo
eletromagntico e a outra baseada em um ponto de visto algortmico, ou seja, de
acordo com o papel que a parte exerce no contexto da comunicao.
De acordo com a classificao sob a perspectiva algortmica, a parte que realiza a
primeira etapa de comunicao, ou seja, a parte que inicia a comunicao chamada
de iniciadora. Esta parte tem a responsabilidade de gerenciar a comunicao e a troca
de dados. Em contrapartida, a parte que responde s requisies do iniciador
chamada de alvo. A configurao desta comunicao NFC semelhante arquitetura
cliente-servidor, onde a comunicao tambm iniciada com uma requisio do cliente
que respondida pelo servidor (COSKUN, 2012). Em um cenrio onde um dispositivo
participa ativamente da sesso de comunicao, realizando requisies sobre nmeros
de cartes de crdito, bilhetes, entre outros, ou enviando informaes com base em
clculos efetuados, este dispositivo considerado iniciador, enquanto o outro
dispositivo que recebe as requisies, processa as informaes e envia respostas
considerado o alvo.
De acordo com a classificao sob a perspectiva de fonte de energia, uma parte
considerada ativa se seu componente NFC tem sua prpria fonte de energia e gera o
seu prprio campo eletromagntico, podendo assim iniciar e gerenciar a comunicao.
Enquanto isso, a parte que no tem nenhuma fonte de energia e depende do campo
eletromagntico gerado pelo dispositivo ativo chamada de passiva e possui apenas a
capacidade de responder as requisies recebidas.
O relacionamento entre as classificaes pode ser visualizado na tabela a seguir:
Papel do Dispositivo
Dispositivo Ativo
Dispositivo Passivo
Iniciador
Possvel
No possvel
Alvo
Possvel
Possvel
Tabela 1: classificao de um dispositivo NFC
32
Desta forma, possvel observar que o dispositivo iniciador sempre ser um dispositivo
ativo, pois ele precisa ter sua prpria fonte de energia para gerar o campo
eletromagntico necessrio para o incio da comunicao NFC. Por sua vez, o
dispositivo alvo pode ser tanto ativo quanto passivo na comunicao. O alvo pode ser
ativo, quando utilizar sua prpria fonte de energia para responder s requisies ou
pode ser passivo, quando depender do campo eletromagntico gerado pelo iniciador
para obter a energia necessria para a comunicao.
Uma tag NFC, por exemplo, como foi concebida para ser um dispositivo de baixo custo
e baixa capacidade de armazenamento, no contm nenhuma fonte de energia e
depende de uma fonte de energia externa para exercer sua funo. Portanto, uma tag
ser sempre um dispositivo alvo e passivo na comunicao, j que no capaz de
gerar seu prprio campo eletromagntico. Em outras palavras, ela foi concebida para
ser manipulada por um dispositivo ativo. Quando um dispositivo ativo aproximado de
uma tag, imediatamente a energia proveniente do seu campo eletromagntico
consumida pela tag NFC, que inicializada. Duas tags no podem se comunicar entre
si, pois no h energia para realizar essa inicializao.
Os leitores NFC so dispositivos que sempre participaro como dispositivos ativos na
comunicao, e so capazes de realizar transferncia de dados de forma bidirecional
com outro dispositivo NFC. J um dispositivo mvel NFC, tem a capacidade de
participar na comunicao NFC em qualquer configurao possvel apresentada na
tabela anterior. Ele pode ser um dispositivo iniciador e ativo ao ler o contedo de uma
tag NFC, por exemplo. Pode ser considerado um dispositivo alvo e ativo ao responder
uma requisio de outro dispositivo mvel NFC que seja iniciador da comunicao e,
alm disso, pode ser considerado alvo e passivo, no caso de emular o funcionamento
de um smartcard. Estas funcionalidades sero vistas com mais detalhes na abordagem
dos modos de operao.
Quando um dispositivo tem fonte de energia prpria, naturalmente ele ser utilizado
para iniciar e gerenciar a comunicao NFC, enquanto um dispositivo que no tem s
poder responder s requisies de um dispositivo ativo. Estes pontos de vista devem
33
ser considerados complementares e so muito importantes para o entendimento da
dinmica da tecnologia NFC e da comunicao entre os dispositivos.
2.5. ARQUITETURA
Um dispositivo mvel que contm tecnologia NFC composto por circuitos integrados,
Security Elements (SEs) e uma interface NFC. Esta interface NFC possui um
componente chamado de NFC Contactless Front-end (NFC CLF) que representa a
porta de entrada para comunicao. Alm disso, a interface possui uma antena NFC e
um chip denominado NFC Controller, que serve para gerenciar uma sesso de
comunicao. Em um dispositivo mvel sempre haver pelo menos um SE, que estar
ligado diretamente ao NFC Controller e poder ser utilizado para manter a segurana
em sesses de comunicao. Mais de um SE pode estar ligado ao mesmo NFC
Controller para oferecer ainda mais segurana comunicao.
Para o NFC Controller se comunicar com o SE, necessrio que uma interface comum
entre eles seja utilizada. Atualmente, as interfaces suportadas para estabelecer esta
ligao so Single Wire Protocol (SWP) e NFC Wired Interface (NFC-WI). Alm do NFC
Controller, o SE tambm pode ser acessado internamente pelo Host Controller (HC) ou
por outro dispositivo NFC presente no campo eletromagntico. Atravs dessas
interfaces o SE capaz de fornecer um ambiente seguro para dados e aplicativos, que
possibilitam o uso e armazenamento de informaes confidenciais.
O HC a parte principal de qualquer dispositivo mvel. Atravs da Host Controller
Interface (HCI) possvel estabelecer uma interface de comunicao entre o NFC
Controller e o HC. Adicionalmente, atravs do ISO/IEC 7816 estabelecida uma
interface entre os SEs e o HC. Assim, o HC tem a capacidade de configurar o modo de
operao do NFC Controller usando a interface HCI, processar os dados que so
enviados e recebidos e estabelecer uma conexo entre o NFC Controller e o SE. Alm
disso, o HC mantm todas as outras funes do dispositivo mvel. Uma ilustrao
desta arquitetura demonstrada na figura a seguir (COSKUN, 2012):
34
Figura 4 - Arquitetura de um dispositivo mvel com NFC
2.5.1. SECURITY ELEMENT

A tecnologia NFC considerada segura pela caracterstica da curta distncia para
realizar a comunicao, mas s isso no o suficiente para que haja segurana
(BREITFU, 2006). A distncia prov uma pequena segurana quanto ao meio fsico,
mas quanto ao meio lgico necessrio que haja um elemento de segurana na
arquitetura do hardware, denominado SE.
O SE serve para garantir aos usurios e provedores de servio que a comunicao
NFC acontecer sob um ambiente seguro e protegido para diversos modelos de
negcio que precisem de tais recursos. Alm disso, prov recursos para autenticao
segura. O SE uma combinao de hardware, software, interfaces e protocolos
embutidos em um dispositivo mvel que, juntos, disponibilizam um meio seguro de
armazenar e trocar informaes (COSKUN, 2012).
Um SE necessita de um sistema operacional para funcionar, como MULTOS, JavaCard
OS, entre outros. Este sistema operacional deve suportar a execuo segura de
35
aplicaes, o carregamento seguro de aplicaes e o armazenamento seguro de dados
destas aplicaes.
Aplicaes NFC armazenadas e executadas na memria do HC de um dispositivo
mvel no esto protegidas contra manipulao dos dados salvos na memria, seja
intencional ou no. Aplicaes armazenadas desta maneira provavelmente tem seu
uso voltado para tarefas que no necessitam de segurana, como leitura de psteres,
por exemplo. J em solues de pagamento, a segurana imprescindvel, pois estas
aplicaes costumam trocar ou armazenar informaes confidenciais. Sendo assim,
para garantir a segurana, aplicaes crticas devem ser armazenadas e executadas
na memria do SE de um dispositivo mvel NFC. Uma variedade de componentes
pode ser utilizada como SEs, como Universal Integrated Circuit Cards (UICCs), cartes
de memria ou outro tipo de hardware integrado. A figura a seguir mostra a diferena
entre uma arquitetura NFC segura e no segura (COSKUN, 2012):
Figura 5 - Diferena entre a arquitetura NFC de dispositivos mveis seguros e no seguros
Pode-se notar que no h segurana se no houver um canal de comunicao direto

entre o NFC Controller e o SE, pois neste caso a troca de informaes deve ocorrer
atravs do HC do dispositivo mvel. Sendo assim, a informao trafega por elementos
externos ao ambiente NFC e est vulnervel interceptao. A figura a seguir
exemplifica as arquiteturas que podem ser criadas com a funcionalidade necessria
para prover um ambiente seguro (COSKUN, 2012):
36
Figura 6 - Dispositivos com arquiteturas NFC seguras
A primeira arquitetura apresentada possui um componente de hardware embutido

como SE. Esta alternativa consiste em um pequeno chip soldado diretamente na placa
do dispositivo mvel e que no pode ser removido sem perda de funcionalidade. O
nvel de segurana oferecido nesta soluo equivalente ao nvel de segurana de um
smartcard. Este chip precisa ser personalizado toda vez que um usurio novo utilize o
dispositivo mvel e por enquanto no h padro estabelecido para comunicao entre
o dispositivo mvel e o SE para esta configurao.
A segunda arquitetura possui um carto de memria seguro como SE, denominado
Secure Memory Card (SMC). Este carto um pouco diferente de um carto de
memria convencional: composto de memria, um smartcard embutido e um
controlador para este smartcard. Em resumo, este carto uma mistura de carto de
memria e um smartcard. Possui a segurana equivalente a um smartcard e
compatvel com vrios padres e interfaces j definidos para smartcards. Este carto
possui uma grande capacidade de armazenamento e, por ser removvel, pode ser
reaproveitado se o usurio decidir trocar de dispositivo mvel sem que seja necessria
uma personalizao;
A terceira arquitetura apresenta um componente UICC como SE. UICC um tipo de
smartcard em que implementada a tecnologia SIM, e por isso popularmente
conhecido como SIM. Esta tecnologia compatvel com todos os padres de
smartcards, capaz de armazenar diversas aplicaes de diferentes origens e garante
37
integridade e segurana para os dados destas aplicaes. Assim, estes cartes podem
armazenar aplicaes relacionadas telefonia ao mesmo tempo em que armazenam
aplicaes de pagamentos, por exemplo. Atualmente, este o cenrio considerado
ideal para a utilizao do SE em dispositivos mveis, pois so pessoais, seguros,
portveis e podem ser facilmente gerenciados atravs da tecnologia Over The Air
(OTA), por onde as operadoras de celular so capazes de manipular as aplicaes e os
dados das aplicaes presentes no SIM atravs dos prprios meios de comunicao.
2.5.2. INTERFACE NFC
A interface NFC composta por um front-end contactless chamado NFC CLF, uma
antena NFC e um NFC Controller. O NFC Controller torna possvel a comunicao NFC
em um dispositivo mvel. Funciona como um modulador e demodulador entre o sinal
analgico do campo eletromagntico e a antena NFC, que por sua vez, conectada ao
NFC Controller atravs de alguns componentes passivos, como capacitores, resistores
e indutores.
O NFC CLF o front-end analgico do NFC Controller. Possui uma interface lgica
com um protocolo definido acima da camada de enlace, que por onde as mensagens
so trocadas entre o SE e o NFC CLF.
Em toda arquitetura NFC que seja segura, h uma interface entre o SE e o NFC
Controller, alm de uma interface entre o HC e o NFC Controller. Assim, os dados que
so transmitidos atravs da interface contactless podem ser encaminhados diretamente
pelo NFC Controller at o SE, e vice-versa. Desta forma, o HC no envolvido na
comunicao.
2.5.3. INTERFACE ENTRE SE E NFC CONTROLLER
Existem vrias solues para estabelecer uma interface entre o SE e o NFC Controller,
porm as mais importantes so a NFC-WI e a SWP (COSKUN, 2012).
O NFC-WI uma interface digital de ligao padronizada por ECM 373, ISO/IEC 28361
e ETSI TS 102 541. Neste padro, o SE definido como um transceiver e o NFC
Controller como um front-end. O SE est conectado ao NFC Controller atravs de dois
fios. Estes fios so denominados Signal-In (SIGIN) e Signal-Out (SIGOUT),
38
respectivamente. Cada fio estabelece uma interface digital e carrega dois sinais
binrios que so definidos como HIGH e LOW. Os sinais transmitidos entre o NFC
Controller e o SE so modulados e digitalmente recebidos ou enviados pelo campo
eletromagntico. Neste padro, o transceiver a entidade que envia mensagens pelo
SIGIN e recebe pelo SIGOUT, enquanto o front-end a entidade que envia pelo
SIGOUT e recebe pelo SIGIN. O NFC-WI totalmente compatvel com todos os modos
de operao e todas as taxas de transferncia de dados definidas ISO/IEC 18092 e
ISO/IEC 14443.
J o SWP define uma conexo entre o SE e o NFC Controller com apenas um fio,
diferentemente do NFC-WI, e est padronizado em ETSI TS 102 613. O SWP um
protocolo full duplex e possui uma taxa de transferncia de 212 kbit/s at 1.6 Mbit/s
para distncias de at 10 cm. A interface SWP um protocolo ponto-a-ponto orientado
a bit que possui um princpio de funcionamento similar ao princpio de mestre e escravo
da computao. Neste caso o NFC Controller o mestre e o SE o escravo. O SWP foi
concebido com o propsito de ser utilizado por cartes UICC para dispositivos mveis,
pois apenas um contato est disponvel para ligao. Porm, h uma exceo onde a
energia do carto UICC fornecida pela interface NFC, ao invs do prprio dispositivo
mvel. Neste caso, mais contatos so utilizados pela interface NFC. Esta opo
possibilita que o dispositivo seja utilizado de maneira passiva quando a bateria est
descarregada.
Os dados transmitidos neste protocolo so representados por estados binrios de
voltagem e corrente no fio. A transmisso de dados entre a interface NFC e o SE
ocorre pela modulao do sinal da voltagem, e na direo oposta os dados so
transmitidos pela modulao do sinal da corrente. No topo da camada fsica, o
protocolo High-Level Data Link control (HDLC) utilizado para controlar a transmisso
de dados entre a interface NFC e o SE. Este protocolo padronizado em ISO/IEC
13239 e prov deteco e correo de erros, sincronizao de sinal e controle de fluxo.
O SWP carrega pacotes pequenos para a camada de aplicao e permite o roteamento
de mensagens para diferentes componentes dentro do dispositivo mvel.
39
2.5.4. HOST CONTROLLER E HCI
HCI uma interface lgica que permite a comunicao entre a interface NFC e um
processador e mltiplos SEs. O HCI utilizado em vrios dispositivos eletrnicos, como
dispositivos mveis, perifricos, entre outros, e est padronizado em ETSI TS 102 622.
Define uma interface entre entidades lgicas chamadas hosts que operam um ou mais
servios. Uma rede de dois ou mais hosts chamada de host network, e um dos hosts
desta rede tambm responsvel por gerenci-la. Este host chamado de host
controller.
Esta interface possui trs componentes: um conjunto de gates por onde so trocados
comandos, respostas e eventos, um mecanismo de mensagens Host Controller
Protocol (HCP) e um mecanismo de roteamento HCP que capaz de fracionar
mensagens quando necessrio.
2.6. MODOS DE OPERAO
Existem trs modos de operao especificados pelo NFC Forum e cada um deles foi
concebido com um propsito diferente. Nestes modos de operao, os dispositivos so
utilizados de maneiras diferentes e resultam em cenrios distintos. Cada um destes
modos possui suas prprias caractersticas, arquiteturas, protocolos e benefcios
associados. No entanto, no nvel fsico todos se baseiam nas mesmas especificaes,
e isto o que permite que todos os modos sejam associados tecnologia NFC.
A arquitetura padro dos protocolos utilizados nestes modos composta por uma
camada de protocolos analgicos e uma camada logo acima, associada a protocolos
digitais. Em outras palavras, na camada analgica encontra-se a especificao para a
parte fsica da tecnologia enquanto na camada digital encontra-se a especificao para
a parte lgica da tecnologia.
O protocolo analgico est relacionado com as caractersticas de RF dos dispositivos
NFC e, entre outras caractersticas, determina a distncia de comunicao dos
dispositivos. J o digital est relacionado ao ISO/IEC 18092 e ao ISO/IEC 14443 e
contm
diretrizes
para
comunicao,
como
atividades
responsveis
pelo
estabelecimento de uma conexo, ciclos de pooling, deteco de colises, entre outros.
40
2.6.1. LEITURA/ESCRITA
Este modo de comunicao define o cenrio onde um dispositivo mvel NFC inicia a
comunicao com uma tag NFC com a finalidade de ler ou escrever dados nesta tag.
Internamente, subdividido em modo de leitura e modo de escrita.
No modo de leitura, o iniciador comunica-se com a tag NFC a fim de obter os dados
armazenados na tag. Nesta tag est armazenada a informao requisitada pelo
iniciador e o programa responsvel por retornar estes dados para o iniciador. J no
modo de escrita, o iniciador grava informaes na tag NFC. No caso de a tag NFC j
possuir dados armazenados, estes sero sobrescritos durante o processo de gravao.
Um dispositivo mvel ou um leitor NFC deve ser capaz de ler todos os tipos de tags
suportadas pelo NFC Forum para realizar operaes de leitura e escrita.
Quando o dispositivo mvel l uma tag NFC, diferentes aes podem ocorrer de acordo
com o contedo da tag. Uma tag NFC pode armazenar, por exemplo, um endereo de
um site. Neste caso, ao ler a tag, o dispositivo mvel pode abrir o navegador
automaticamente para acessar o site. Tambm podem existir tags com uma instruo
de execuo de aplicao armazenada, que ao ser lida faz com que uma aplicao
seja executada no dispositivo mvel.
As caractersticas de dispositivos mveis como poder de
processamento, reproduo de udio e vdeo e acesso internet,
quando utilizadas com este modo de operao NFC proporcionam
muitas possibilidades de aplicaes interessantes tanto para usurios
quanto para desenvolvedores. Um bom exemplo disso uma aplicao
onde possvel comprar bilhetes de cinema ao aproximar o dispositivo
mvel de um cartaz. Aplicaes com este modo de operao so
numerosas e podem ser muito inovadoras. (COSKUN, 2012)
Neste modo de operao, as interfaces da camada de RF so compatveis com as

especificaes ISO/IEC 14443 Tipo A, ISO/IEC 14443 Tipo B e Sony FeliCa. O SE do
dispositivo mvel no necessrio na comunicao, j que a comunicao consiste
basicamente na manipulao dos dados da tag NFC. A tag NFC um dispositivo
passivo nesta comunicao e sua manipulao envolve alguns protocolos especficos,
que so representados na figura a seguir:
41
Aplicaes NDEF
Aplicaes sem
NDEF
Operaes com tags
Protocolo Digital
Analgico
Figura 7 - Pilha de protocolos do modo leitura/escrita
As camadas mais inferiores, comuns a todos os modos de operao, definem os

protocolos analgicos e digitais da tecnologia NFC. Acima delas, possvel observar
duas vertentes de utilizao. Uma delas com aplicaes baseadas em mensagens
NDEF e regulamentadas pelo NFC Forum, enquanto a outra pode ser completamente
proprietria, utilizando somente as especificaes mais bsicas da tecnologia NFC.
As operaes de tags representam os comandos e instrues utilizados pelos
dispositivos NFC para manipular as tags definidas pelo NFC Forum. As operaes de
leitura e escrita so realizadas atravs da utilizao da especificao NDEF.
Aplicaes NDEF so softwares cuja funcionalidade baseada na utilizao da
especificao NDEF. Geralmente esto associados a tarefas de leitura de informaes,
como psteres, estabelecimento de conexo Wi-Fi, entre outras.
Aplicaes que no so baseadas em NDEF encaixam-se tambm neste modo de
operao, porm, so aplicaes especficas de um determinado desenvolvedor. Estas
aplicaes podem servir para leitura de bilhetes, por exemplo, onde geralmente h
tecnologia proprietria envolvida.
2.6.1.1.
TAGS SUPORTADAS
O NFC Forum definiu quatro tipos de tags para utilizao neste modo, numerando-as
de 1 a 4. Cada tipo de tag tem um formato e uma capacidade diferente, e so
baseados nas especificaes suportadas pela tecnologia NFC, ISO/IEC 14443 Tipo A,
ISO/IEC 14443 Tipo B e Sony FeliCa. Segundo (COSKUN, 2012), as caractersticas
mais comuns destes tipos de tags so:
42
Tipo 1: estas tags so baseadas na especificao ISO/IEC 14443 Tipo A.

Podem ser lidas e gravadas, porm, sua gravao pode ser inibida atravs de
configurao,
caso
seja
necessrio.
Possui
kb
de
espao
para
armazenamento de dados, que o suficiente para armazenar um endereo de

um site ou qualquer outra pequena quantidade de informaes. A taxa de
transferncia desta tag de 106 kbit/s;
Tipo 2: estas tags tambm so baseadas na especificao ISO/IEC 14443 Tipo

A. Assim como na tag Tipo 1, tambm podem ser lidas e gravadas, e possuem a
configurao para desabilitar a gravao. O espao de armazenamento de at
2 kb e a taxa de transferncia de 106 kbit/s;
Tipo 3: so tags baseadas no padro Sony FeliCa. Atualmente tem um espao

de armazenamento de 2 kb e a taxa de transferncia de 212 kbit/s. Porm, a
memria pode ser expansvel at 1 mb. Este tipo de tag recomendado para
aplicaes mais complexas e possui um custo elevado se comparado s outras
tags;
Tipo 4: so tags compatveis com os padres ISO/IEC 14443 Tipo A e ISO/IEC

14443 Tipo B. Estas tags so pr-configuradas durante sua fabricao e podem
ser gravveis ou no. Alm disso, o tipo da tag tambm definido em uma etapa
de fabricao. O espao para armazenamento de at 32 kb e a velocidade de
comunicao varia entre 106 e 424 kbit/s.
2.6.1.2.
NDEF
NDEF um formato especificado pelo NFC Forum para as mensagens trocadas entre
dois dispositivos durante uma comunicao NFC. Esse formato consiste em uma
mensagem leve em formato binrio, concebida para encapsular um ou mais payloads
em uma nica mensagem. Um payload, tambm chamado de carga til, definido pela
aplicao e contm informaes relevantes para o processamento da mesma.
Uma mensagem NDEF pode conter um ou mais registros NDEF, cada um carregando
um payload de um determinado tipo e com tamanho de at 232-1 octetos. Octetos so
bytes onde cada um dos 8 bits modifica seu significado dentro de um determinado
contexto. Estes registros podem ser encadeados para que um tamanho maior de
43
payload seja suportado (NDEF, 2006). Em uma mensgem NDEF, o primeiro registro
sempre ser marcado com uma flag Message Begin (MB) e o ltimo ser marcado com
uma flag Message End (ME), como na representao de uma mensagem NDEF a
seguir:
Figura 8 - Representao de uma mensagem NDEF
Um registro NDEF carrega trs parmetros para descrever seu payload:
Tamanho do Payload: este parmetro indica o nmero de octetos no payload.

Se o tamanho pode ser representado nos 8 primeiros octetos de um registro, a
deteco dos limites de cada registro podem ser realizada de maneira mais
eficiente;
Tipo do Payload: um identificador para representar o tipo do payload.

Mensagens NDEF suportam URIs, alguns tipos de mdia ou outro formato
especfico do NFC. Com a utilizao desta informao possvel direcionar o
payload para a aplicao mais apropriada;
Identificador do Payload: um parmetro opcional que pode ser utilizado para

atribuir ao payload um identificador no formato URI. O uso de um identificador
permite que um payload faa referncia a outros payloads, desde que suportem
tecnologias necessrias para estabelecer esta ligao atravs de URI;
O NFC Forum define vrios tipos de registros NDEF com diferentes propsitos atravs
da especificao RTD. Os principais tipos definidos em RTDs so:
URI RTD: define um registro que representa um URI e que pode ser
armazenado em uma tag ou compartilhado entre dispositivos mveis, por
exemplo;
Smart Poster RTD: define um tipo capaz de armazenar URLs, SMSs e nmeros
de telefone em uma tag e tambm seu compartilhamento entre os dispositivos.
Foi especificado especialmente para utilizao em objetos como psteres e
cartazes, para armazenar dados relativos propaganda e aes de marketing.
44
O payload de uma mensagem desse tipo consiste em outra mensagem NDEF
com o seguinte formato: um registro NDEF para o ttulo, um registro para
armazenar um URI, um registro de ao que define como a mensagem deve ser
tratada, um registro para armazenar um cone, um registro para informar o
tamanho dos dados referenciados pelo URI e um registro para informar o tipo
destes dados;
Signature RTD: um registro desse tipo contm uma assinatura digital

relacionada a um ou mais registros dentro da mensagem NDEF. Esta assinatura
pode ser utilizada para verificar a integridade e autenticidade de toda a
mensagem NDEF. A assinatura digital de uma mensagem NDEF um mtodo
confivel para fornecer informaes sobre a origem das mesmas (COSKUN,
2012).
Text RTD: este tipo de registro contm texto puro. Geralmente utilizado em um
registro dentro de uma mensagem com vrios outros registros, para fornecer
descries, por exemplo. Quando aparece em uma mensagem de um nico
registro no possvel determinar um comportamento padro para esta
mensagem dentro da aplicao.
Um registro NDEF tem tamanho varivel e pode ser analisado mais detalhadamente no
modelo a seguir, conforme definido em sua especificao (NDEF, 2006).
45
Figura 9 - Representao de um registro NDEF
Neste modelo, cada linha representada por pelo menos um byte e os traos verticais
so utilizados para demarcao dos bits, conforme indicado acima do modelo com a
utilizao da numerao dos bits de 7 a 0. Os campos apresentados tem a seguinte
funcionalidade:
MB: uma flag de um bit que indica o comeo de uma mensagem NDEF;
ME: uma flag de um bit que indica o fim de uma mensagem NDEF;
Chunk Flag (CF): uma flag de um bit que indica se este registro o primeiro de
um payload segmentado ou no;
Short Record (SR): uma flag de um bit, que se for ativada indica que o campo
PAYLOAD_LENGTH pode ser representado por um nico octeto. Isto serve para
que os registros se tornem mais compactos e permite que pequenos payloads
sejam utilizados com tamanho entre 0 e 255 bytes. Uma mensagem NDEF pode
conter registros normais e pequenos, e qualquer interpretador deve suportar
ambos os formatos;
46
ID Length (IL): uma flag de um bit, que se for ativada indica que o campo
ID_LENGTH est presente no cabealho e pode ser representado por um nico
octeto. Caso contrrio, o campo ID_LENGTH e o ID so omitidos do registro;
Type Name Format (TNF): o valor deste campo de 3 bits indica a estrutura
utilizada para a representao do campo TYPE. No h valor padro para este
campo e valores no especificados esto reservados para tipos que sero
criados no futuro. Qualquer interpretador que receber um valor no presente na
especificao deve trat-lo como desconhecido;
TYPE_LENGTH: este campo representado por um inteiro de 8 bits e define o

tamanho do campo TYPE em bytes. Para certos valores de TNF, este campo
ser sempre 0;
ID_LENGTH: este campo representado por um inteiro de 8 bits que especifica

o tamanho do campo ID em bytes. Se o valor for 0, o campo ID ser omitido do
registro;
PAYLOAD_LENGTH: este campo representado por um inteiro que especifica o

tamanho do campo PAYLOAD em bytes. Se a flag SR estiver ativada, este
campo ter 8 bits, caso contrrio ter 32 bits. Se o valor for 0, o campo
PAYLOAD ser omitido do registro;
TYPE: um identificar que descreve o tipo do payload. Este tipo deve seguir a
estrutura definida pelo campo TNF e muito importante para a semntica da
mensagem;
ID: um identificador na forma de uma referncia URI. Este identificador deve

ser nico e essa propriedade deve ser garantida pelo responsvel por sua
gerao. O identificador pode ser relativo ou absoluto. Se for relativo, a
aplicao deve especificar uma raiz para a referncia URI. Com exceo do
primeiro registro, todos os outros registros de um payload segmentado no
devem ter o campo ID;
PAYLOAD: este campo carrega os dados utilizados pela aplicao do usurio. O

dado carregado neste campo indiferente para a especificao NDEF, e,
portanto, qualquer tipo de dado permitido;
47
Atualmente a especificao NDEF prov os seguintes valores para utilizao no campo
TNF:
Registro Vazio (0x00): indica que no haver valores para TYPE, ID ou

PAYLOAD associados com este registro NDEF. Este tipo de registro til para
cartes e tags recm-formatados, pois toda tag precisa ter pelo menos um
registro NDEF;
Well-Known Record (0x01): indica que o campo TYPE utiliza o formato RTD.
Este tipo de registro utilizado para armazenar qualquer registro definido na
especificao RTD, como texto, URIs, entre outros;
MIME Media Record (0x02): indica que o campo TYPE contm um valor que
segue a formatao media-type BNF definida por RFC 2046;
Absolute URI Record (0x03): indica que o campo TYPE contm um valor que
segue a formatao absolute-URI BNF definida por RFC 3986;
External Record (0x04): indica que o campo TYPE contm um valor que segue a
especificao definida em RTD para nomes de tipos externos;
Unknown Record (0x05): indica que o tipo do PAYLOAD desconhecido.

semelhante ao uso de "application/octet-stream" em tipos MIME;
Unchanged Record (0x06): indica que o PAYLOAD faz parte de um registro

intermedirio ou final de um registro segmentado;
O NDEF oferece a possibilidade de uma aplicao enviar muitos dados de diferentes

tipos em uma nica mensagem. Uma aplicao pode, por exemplo, criar uma nica
mensagem contendo registros com endereos de sites, nmeros de telefone, textos
descritivos, entre outros. Nestes casos, o primeiro registro o que ser utilizado para
definir o significado da mensagem.
O interpretador de mensagens NDEF desmonta as mensagens e decide o que fazer
com cada tipo de payload detectado. ele que decide se a mensagem vai ser enviada
diretamente para outra aplicao do usurio ou processada internamente pela
aplicao com suporte NFC. Cada mensagem NDEF deve ser recebida ou enviada
em sua totalidade.
48
Tambm importante notar que apesar de entidades MIME serem suportadas, no h
pressuposies de que um payload de um registro NDEF do tipo MIME, pois o NDEF
no pressupe nada referente aos tipos de payload carregados em uma mensagem.
Em outras palavras, um interpretador NDEF no precisa inspecionar o tipo do registro
NDEF tampouco inspecionar o contedo dentro do registro para processar a
mensagem NDEF.
2.6.2. PEER-TO-PEER
No modo peer-to-peer, dois dispositivos podem estabelecer uma conexo entre si para
troca de dados de forma bidirecional. Este modo de operao s pode ser utilizado
entre dispositivos mveis e leitores NFC e serve para trocar qualquer tipo de dado,
como contatos, fotos e mensagens de texto.
Foram definidas duas especificaes para este modo de operao, o NFCIP-1 e o
LLCP. O LLCP foi construdo em uma camada acima do NFCIP-1 na pilha de
protocolos e depende dele para funcionar. Enquanto no NFCIP-1, o iniciador e o alvo
so definidos antes da comunicao comear, no LLCP podem ser definidos pela
aplicao, que est uma camada acima na pilha de protocolos. Este recurso concede
maior flexibilidade no s para o desenvolvimento, mas tambm para a interao do
usurio com os dispositivos.
Neste modo, ambos os dispositivos possuem fonte de energia prpria e so
considerados ativos. A comunicao utiliza um canal bidirecional half duplex, pois
quando um dispositivo est transmitindo informao, o outro precisa esperar a
transmisso terminar para que possa, em seguida, transmitir dados tambm. A
interface de comunicao por RF est padronizada em ISO/IEC 18092 para este modo
de operao e a taxa de transferncia mxima de 424bkps.
O modo de operao peer-to-peer apresenta a seguinte pilha de protocolos:
49
Aplicaes
Protocolos do NFC Forum
Ligaes de protocolos
NDEF Exchange Protocol e

outros protocolos
Logical Link Control Protocol (LLCP)

Protocolo Digital
Analgico
Figura 10 - Pilha de protocolos do modo peer-to-peer
Os protocolos analgicos e digitais nas camadas mais baixas, assim como no modo de
operao leitura/escrita, esto especificados em NFCIP-1. Na camada acima existe o
protocolo LLCP, que viabiliza a transferncia de unidades de informao para as
camadas superiores presentes nos dois dispositivos da comunicao. As ligaes de
protocolos provm bindings para os protocolos do NFC Forum e permitem uso de
protocolos registrados. Os protocolos do NFC Forum so aqueles utilizados para
estabelecer um vnculo com o LLCP, como Internet Protocol (IP), por exemplo. De
outro lado, existe o Simple NDEF Exchange Protocol (SNEP) que permite a troca de
mensagens NDEF entre os dispositivos, mas tambm possvel utilizar outros
protocolos sobre a camada de enlace fornecida pelo LLCP. Acima da pilha esto as
aplicaes, que podem funcionar com base no protocolo SNEP, protocolos do NFC
Forum ou outros protocolos.
2.6.2.1.
LOGICAL LINK CONTROL PROTOCOL
O LLCP define uma camada de enlace para oferecer suporte comunicao peer-topeer entre dois dispositivos NFC e essencial para qualquer aplicao NFC que
envolve comunicao bidirecional.
O LLCP uma base slida, segundo (LLCP, 2011), para quaisquer aplicaes NFC
que funcionem no modo peer-to-peer. O LLCP baseado em funcionalidades bsicas
especificadas pelo protocolo NFCIP-1. No protocolo NFCIP-1 existe a capacidade
segmentao e montagem de dados de servio, assim como controle do fluxo de
50
dados, comum em protocolos half duplex. Alm disso, o protocolo NFCIP-1 estabelece
um fluxo de dados ordenado e permite o gerenciamento de erros. Em outras palavras,
fornece uma camada de enlace que pode ser considerada confivel e livre de erros.
No LLCP esto definidos servios para transporte sem conexo ou no orientado
conexo, transporte orientado conexo, ativao, superviso e desativao de
enlace, comunicao balanceada assncrona e protocolo para multiplexao.
O transporte sem conexo ou no orientado conexo prov um servio de
transmisso de dados sem reconhecimento. Este modo de transporte pode ser utilizado
se os protocolos de camadas superiores implementarem seus prprios mecanismos de
controle de fluxo. Desta forma, estas camadas no dependem do controle de fluxo
fornecido pela camada de enlace.
O transporte orientado conexo prov um servio de transmisso de dados de
maneira sequencial e com garantia de entrega de unidades de dados de servio. A
transmisso dos dados gerenciada atravs de um protocolo do tipo sliding window.
Os servios de ativao, superviso e desativao do enlace definem como dois
dispositivos NFC que estejam dentro de um campo eletromagntico reconhecem a
compatibilidade do protocolo LLCP, estabelecem uma ligao, supervisionam a
conexo com o dispositivo remoto e desativam a ligao, quando solicitado.
Dispositivos NFC possuem MACs que podem operar em modo de respostas normal,
onde existe apenas um iniciador, que possui a habilidade de enviar dados para o alvo
ou podem solicitar dados de uma tag. No LLCP, o servio de comunicao balanceada
assncrona habilita o Asynchronous Balanced Mode (ABM) em ambos dispositivos
atravs do uso de um mecanismo de simetria. Usando o ABM, os pontos de acesso de
servios LLCP podem inicializar, supervisionar, recuperar erros e mandar informaes
a qualquer momento.
J o servio de multiplexao permite que o LLCP suporte diversas instncias de
outros protocolos em camadas superiores da aplicao. Em outras palavras, todos os
dados de camadas superiores da aplicao, como dados do protocolo SNEP, so
convertidos em unidades de servio LLCP antes de serem enviados.
51
2.6.2.2.
SIMPLE NDEF EXCHANGE PROTOCOL
O SNEP um protocolo baseado em requisies e respostas e tem como principal

objetivo realizar a troca de mensagens do tipo NDEF entre dispositivos. Neste
protocolo um dispositivo cliente envia uma requisio para um dispositivo servidor, que
ao receb-la, realiza o processamento solicitado de acordo com as informaes
fornecidas e responde com outra mensagem indicando o trmino do processamento.
A mensagem de requisio SNEP enviada pelo cliente possui dados de verso do
protocolo, mtodo de requisio, tamanho da informao em octetos e a informao
em si. Enquanto isso, a mensagem de resposta possui dados de verso do protocolo,
cdigo de status indicando sucesso ou falha do mtodo de requisio, tamanho da
informao, tambm em octetos, e a informao em si.
Com base na informao do campo de verso do protocolo, os participantes da
comunicao definiro se poder ocorrer a troca de dados com sucesso. A verso do
protocolo indicada por um campo de verso no primeiro octeto de cada mensagem
SNEP e possibilita que o iniciador indique sua capacidade para entender uma posterior
comunicao.
No campo de informaes de uma mensagem SNEP, tanto de requisio como de
resposta, so transmitidas mensagens NDEF. Entretanto, o tamanho mximo de
qualquer mensagem NDEF a ser transmitida 232-1, que o maior nmero inteiro que
pode ser representado pelo campo de tamanho da informao em uma mensagem
SNEP. Se o tamanho total de uma mensagem SNEP exceder a capacidade de uma
unidade de dados de servio referente ao protocolo de transporte, esta mensagem
dever ser fragmentada. Opcionalmente, a mensagem tambm pode ser fragmentada
mesmo que o protocolo de transporte oferea suporte ao tamanho necessrio para
encapsular a mensagem.
Estes fragmentos devem ser construdos atravs da remoo de parte do contedo da
mensagem SNEP e sua transmisso, at que todos os octetos tenham sido enviados.
Porm, para que esta mensagem seja recebida e interpretada corretamente pelo
destino, necessrio que o primeiro fragmento possua o cabealho completo da
mensagem, indicando, alm de outras informaes, o tamanho da mensagem que est
52
sendo recebida. Desta forma, o receptor capaz de avaliar, ao receber o primeiro
fragmento, se a mensagem estar fragmentada. Aps o recebimento do primeiro
fragmento, o receptor deve indicar origem que pode receber mensagens
fragmentadas e s ento a mensagem transmitida at o final.
A troca de mensagens SNEP precisa de um protocolo de transporte que seja seguro e
capaz de aceitar unidades de dados de servio de 6 octetos ou mais, para que seja
possvel adicionar, pelo menos, todas as informaes do cabealho de uma
mensagem. O protocolo tambm precisa suportar conexes simultneas, separadas
logicamente, pois mais de um canal de comunicao pode ser aberto entre o cliente e o
servidor.
Na arquitetura proposta pelo NFC Forum, SNEP um protocolo construdo em uma
camada acima do protocolo LLCP. Mensagens SNEP devem ser transmitidas com o
uso de conexes de enlace de dados do protocolo LLCP. Um servidor SNEP ativo deve
aguardar requisies de conexo em um servio de ponto de acesso LLCP. O
endereo desse servio de ponto de acesso especificado na requisio de conexo
enviada pelo cliente. Tambm possvel estabelecer uma conexo de enlace
especificando o nome do servio em uma requisio, que deve ser enviada para um
componente de descoberta de servios. O NFC Forum reserva o endereo 4 para o
servio de ponto de acesso e o nome de servio urn:nfc:sn:snep para o servidor
SNEP padro.
Uma vez que a conexo de enlace de dados estabelecida, o cliente deve enviar
apenas mensagens de requisies e o servidor deve apenas responder mensagens de
respostas. Ao final, o cliente finaliza a conexo de enlace de dados quando a
comunicao encerrada. O servidor SNEP padro prov uma espcie de caixa de
entrada lgica, onde um cliente que est conectado pode inserir mensagens NDEF
atravs de requisies do tipo put. Requisies do tipo get no so aceitas.
2.6.2.3.
NDEF PUSH PROTOCOL
O protocolo NDEF Push Protocol (NPP) foi desenvolvido pelo Google para utilizao no
sistema Android e utilizado para trocar mensagens NDEF entre dispositivos mveis.
53
um protocolo simples que funciona com base no protocolo LLCP. As mensagens
NDEF neste protocolo so enviadas em um nico sentido, ou seja, sempre so
enviadas por um dispositivo cliente e tem um dispositivo servidor como destino. Um
dispositivo que suporta NPP deve sempre manter um servidor NPP em execuo e
deve executar um cliente NPP caso existam mensagens para envio.
Neste protocolo o servidor deve registrar um servio com o nome de com.android.npp
e deve ser disponibilizado para descoberta atravs do protocolo Service Discovery
Protocol (SDP). Assim que uma mensagem recebida de outro dispositivo, o servidor
deve processar todas as mensagens NDEF de acordo com seu cdigo de ao, na
ordem em que foram recebidas. Quando a ltima mensagem for recebida e a conexo
foi fechada, o servidor tem a transao completada.
O cliente, por sua vez, deve enviar as mensagens NDEF disponveis assim que uma
conexo com o servidor for estabelecida. A conexo estabelecida atravs do
protocolo LLCP para que mensagens NDEF sejam enviadas, encapsuladas em um
pacote NPP. O cliente deve ser capaz de reconhecer uma falha em qualquer etapa da
comunicao para indicar que houve erro, pois no h mecanismos para deteco de
erros ou novas tentativas neste protocolo.
Um pacote NPP composto por um cabealho que contm a verso do protocolo e o
nmero de entradas NDEF, seguido pelas entradas NDEF. Cada entrada NDEF
contm um cdigo de ao, o tamanho da mensagem NDEF e a mensagem NDEF.
Atualmente s existe um cdigo de ao definido na especificao, que indica que a
mensagem NDEF deve ser processada como se fosse recebida de uma tag passiva.
2.6.3. EMULAO DE CARTES
O modo de emulao de cartes permite que um dispositivo mvel NFC funcione como
um smartcard contactless. Uma vantagem da utilizao do dispositivo mvel como um
smartcard a possibilidade de armazenamento de diversas aplicaes de smartcards
simultaneamente. Desta forma, possvel utilizar o dispositivo mvel para substituir
cartes de crdito e dbito, por exemplo. Aplicaes de pagamento, bilheteria, cartes
54
de fidelidade, controle de acesso e servios de identificao so exemplos em que este
modo de operao pode ser utilizado.
Neste modo de operao, o dispositivo mvel NFC no responsvel por gerar seu
prprio campo eletromagntico, e por isso, deixa de atuar como um dispositivo ativo. O
leitor NFC ser responsvel pela criao deste campo e por isso, possvel que o
dispositivo mvel NFC se comunique mesmo sem bateria. Este leitor pode estar
conectado internet, servindo como um proxy para o dispositivo mvel. Desta forma, a
aplicao elimina a dependncia de acesso internet por parte do dispositivo mvel e
abstrai a complexidade envolvida no processamento, podendo consumir servios
terceiros totalmente isolados do dispositivo.
As interfaces de comunicao RF suportadas por este modo so ISO/IEC 14443 Tipo
A, ISO/IEC 14443 Tipo B e Sony FeliCa. A emulao pode ocorrer de duas formas: um
dispositivo mvel pode emular um smartcard ISO/IEC 14443 atravs do hardware NFC
ou um chip de smartcard integrado ao dispositivo mvel e conectado diretamente na
antena do hardware NFC. Neste modo, o dispositivo mvel, apesar de ter fonte de
energia prpria, atua apenas como alvo na comunicao com um leitor NFC. Este
modo de operao importante, pois oferece compatibilidade com infraestruturas
existentes de algumas tecnologias de smartcards.
Um dispositivo NFC que est operando neste modo usa protocolos analgicos e
digitais similares aos smartcards e so totalmente compatveis com sua especificao.
Aplicaes
Protocolo Digital
Analgico
Figura 11 - Pilha de protocolos do modo emulao de cartes
Quanto um dispositivo mvel se comunica com um leitor NFC, seu comportamento ser
idntico ao de um smartcard. Desta maneira, o leitor pode interagir com aplicaes
presentes no SE, como aplicaes proprietrias para pagamento, por exemplo.
Portanto, este o modo de comunicao em que o SE utilizado de maneira mais
55
segura e eficiente, j que no envolve processamento de alguma aplicao no
dispositivo mvel, mas sim no SE.
2.7. SEGURANA
O uso de um dispositivo mvel geralmente implica em um risco de segurana, se
comparado a um computador pessoal. Apesar de um dispositivo mvel muitas vezes
apresentar as mesmas capacidades computacionais de um PC, ele difere quanto ao
uso. O celular um dispositivo mvel que foi concebido para ser sempre carregado
pelo usurio no seu dia-a-dia, e exatamente por isto que ele est mais exposto a
ataques fsicos, como roubo e ataques wireless atravs de tecnologias de comunicao
como o Bluetooth. Quando a funcionalidade NFC adicionada a um dispositivo mvel,
mais uma porta de entrada para possveis ataques criada.
Como na tecnologia NFC cada modo de operao possui uma arquitetura diferente, a
estratgia de ataque e o mecanismo de defesa esto associados s forma de uso da
tecnologia, ou seja, so cenrios completamente diferentes. Assim, a segurana na
tecnologia NFC deve ser analisada separadamente para as tags, leitores, smartcards,
comunicao e sistemas.
O uso de tags est associado ao modo de operao leitura/escrita, onde um dispositivo
NFC interage com uma tag escrevendo ou lendo dados. Nesta configurao, os dados
trafegados na comunicao e armazenados na tag precisam ser protegidos para que
se satisfaa o requisito de segurana da tecnologia. Os principais ataques so:
Clonagem de tags: neste cenrio algum pode tentar criar uma cpia idntica e
vlida da tag. Criar um mecanismo de preveno no sistema quase invivel,
pois
implica
em
uma
alta
capacidade
de
processamento,
que
consequentemente aumentaria o custo das tags;
Mudana de contedo das tags: neste caso, algum pode modificar o contedo
da tag para prover informaes falsas ou simplesmente tornar a tag inoperante;
Troca de tag ou tag escondida: uma tag pode ter simplesmente trocada por
outra, com contedo malicioso. Tambm possvel posicionar uma tag por cima
da outra, escondendo-a.
56
Como um dispositivo mvel pode ser utilizado para emular um smartcard, a segurana
do leitor tambm uma preocupao. Os leitores NFC esto sujeitos aos seguintes
tipos de ataques:
Remoo ou destruio de leitores NFC: leitores NFC esto sujeitos remoo

ou destruio, pois geralmente esto localizados em lugares com grande
circulao de pessoas. Um leitor pode conter informaes importantes como
chaves de criptografia e atravs deles, ataques podem ser realizados contra
dispositivos mveis e at mesmo sistemas de back-end;
Personificao: quando a comunicao NFC no autenticada, possvel fazer

com que um leitor NFC falso assuma a identidade de outro leitor NFC, ganhando
acesso informaes e possivelmente modificando contedo de tags.
Os smartcards, alm de possurem vrias especificaes compatveis com a tecnologia

NFC, tambm podem ser utilizados como SE em dispositivos mveis. Portanto, os
dispositivos mveis tambm herdam as vulnerabilidades dos smartcards. Estes
ataques requerem equipamento especializado e um alto nvel de conhecimento. So
divididos em dois grupos:
Invasivos: os ataques invasivos so realizados a travs da remoo ou

manipulao do microprocessador do smartcards;
Canal Lateral: consiste em observar um canal lateral enquanto a informao

processada. O objetivo obter informaes observando como um smartcard se
comporta enquanto processa a informao. O canal lateral pode ser uma anlise
de tempo de processamento de informaes, de consumo de energia, reao a
erros induzidos, entre outros.
A comunicao atravs de RF tambm est sujeita a ataques, mesmo considerando a

curta distncia de comunicao empregada no NFC. O ataque pode ser realizado
atravs de dispositivos de RF de longo alcance, que podem se comunicar com
smartcards contactless a metros de distncia. Os tipos de ataques associados
comunicao so:
57
Espionagem: um indivduo pode usar uma antena para gravar a comunicao

entre dois dispositivos;
Corrupo de dados: um indivduo pode modificar os dados transmitidos atravs

de espionagem;
Alterao de dados: um indivduo pode interceptar a comunicao e modificar ou

apagar informaes;
Insero de dados: dados podem ser inseridos na troca de mensagens entre

dois dispositivos, porm, isto precisa acontecer antes do dispositivo correto
responder a mensagem, caso contrrio, haver corrupo de dados;
Man-in-the-middle: onde um dispositivo posicionado entre os dois dispositivos

da comunicao e passa a intermediar a troca de mensagens;
Retransmisso: est relacionado ao Man-in-the-middle e consiste em interceptar

e retransmitir uma mensagem para o destino, alterando-a ou fazendo uso das
informaes;
Replay: uma mensagem vlida interceptada e gravada. Posteriormente

transmitida ao seu destino, podendo fazer com que pagamentos sejam
efetuados em duplicidade caso no haja tratamento adequado.
Sistemas baseados em tecnologia NFC so compostos por diversos dispositivos e

geralmente envolvem servidores para gerenciar e armazenar informaes. Por isso, um
sistema NFC no est totalmente seguro enquanto todos os elementos que compe o
sistema esto seguros. Tambm muito importante que o dispositivo NFC que faa a
comunicao com estes servidores esteja preparado para estabelecer uma
comunicao segura.
2.8. FRAMEWORKS NFC
Uma das principais utilizaes para a tecnologia NFC a criao de aplicaes para
dispositivos mveis. Para que tal aplicao seja desenvolvida, basta que a plataforma
do dispositivo mvel tenha suporte tecnologia NFC em sua API. Porm, existem
casos em que estas aplicaes dependem de um back-end desenvolvido com base em
um leitor NFC, que o dispositivo que deve se comunicar com o dispositivo mvel.
Estes dispositivos, geralmente possuem interface USB ou serial para conexo com
58
computadores e cada fabricante prov uma biblioteca de desenvolvimento para seus
dispositivos. Em outras palavras, isto significa que cada fabricante possui uma
biblioteca diferente e o desenvolvimento do back-end acaba sendo voltado para a API
especfica do leitor.
Procurando resolver estes problemas, algumas bibliotecas NFC foram criadas, como o
Open NFC e o LibNFC. Estes frameworks destacam-se por ter cdigo aberto, o que
tem um papel muito importante para a propagao da tecnologia NFC.
2.8.1. OPEN NFC
Open NFC um pacote de software que implementa as funcionalidades da tecnologia
NFC para um hardware dedicado. um software de cdigo aberto, que patrocinado
pela empresa Inside Secure. Este pacote, tambm chamado de pilha, fornece uma API
de alto nvel para controle do circuito integrado e dos componentes NFC deste
hardware (OPENNFC, 2012). A pilha Open NFC composta por um mdulo central,
por um componente de ligao entre as chamadas nativas da plataforma e a API, alm
de um componente para abstrao do hardware.
O componente de ligao utilizado em edies especficas do Open NFC, como a
verso para Android. A verso para Android baseada em Java e possui classes que
implementam chamadas nativas da API da plataforma em questo e que precisam ser
convertidas a partir de chamadas da API Open NFC.
O mdulo central da pilha Open NFC portvel, independente de hardware e
desenvolvido na linguagem C. Este modulo contm a lgica necessria para manipular
os diferentes protocolos e modos de operao presentes na tecnologia NFC. Este
mdulo independente do hardware NFC utilizado (OPENNFC, 2012).
O mdulo de abstrao de hardware, tambm conhecido como NFC Hardware
Abstraction Layer (NFC HAL), estabelece uma ponte de comunicao entre a API Open
NFC e o hardware NFC. Representa uma camada de software do mais baixo nvel na
pilha Open NFC, responsvel por gerenciar o hardware especfico da plataforma em
questo. Todos os componentes envolvidos na comunicao NFC so gerenciados por
59
esta camada. Oferece a possibilidade de extenso atravs da API NFC HAL, que pode
ser utilizada adicionar suporte a novos hardwares NFC.
O Open NFC tambm disponibiliza uma ferramenta para auxiliar o desenvolvimento,
denominada Connection Center Tool. Esta ferramenta capaz de simular o
funcionamento de um hardware NFC e prov uma interface grfica onde possvel
configurar seu funcionamento e executar tarefas associadas tecnologia, como a
aproximao entre uma tag e um leitor. Para isto, existe uma camada de abstrao de
hardware especfica, que faz com que a API Open NFC se comunique com o simulador
da mesma forma com que se comunica com dispositivos NFC. Existe tambm a opo
de manipular um dispositivo NFC remotamente atravs de uma conexo TCP/IP.
2.8.2. LIBNFC
LibNFC uma biblioteca de cdigo livre que oferece suporte tecnologia NFC para
alguns leitores NFC. A biblioteca foi desenvolvida em C e mantida por uma
comunidade ativa de desenvolvedores independentes (LIBNFC, 2012). Esta biblioteca
oferece a possibilidade de desenvolvimento de aplicaes NFC para computadores
atravs da utilizao de leitores compatveis. Alm disso, oferece suporte a todos os
modos de operao suportados pela tecnologia NFC, apesar de no implementar todos
os protocolos presentes na especificao.
Segundo (LIBNFC, 2012), foi a primeira biblioteca para desenvolvimento de aplicaes
NFC lanada sob o modelo de licena GNU. Atravs do uso desta biblioteca, possvel
minimizar as dificuldades de desenvolvimento para dispositivos NFC, pois elimina a
necessidade de desenvolvimento em baixo nvel. Diversas especificaes de tags so
suportadas, como ISO/IEC 14443 Tipo A, ISO/IEC 14443 Tipo B e Sony FeliCa. Alm
disso, esta biblioteca tambm oferece suporte tecnologia RFID.
60
3.
DESENVOLVIMENTO PARA DISPOSITIVOS MVEIS
Dispositivos mveis so todos os computadores portteis de pequeno porte, como

smartphones, tablets, entre outros. Esta lista de dispositivos mveis muda conforme
novas tecnologias so introduzidas, como o caso dos tablets que ficaram mais
conhecidos com o lanamento do iPad em 2010 (BURNETTE, 2009). Estes dispositivos
esto em constante evoluo e seus recursos so frequentemente ampliados enquanto
seus componentes ficam cada vez menores.
Os dispositivos mveis tm como forte caracterstica a conectividade. Smartphones por
exemplo, so capazes de utilizar a rede de telefonia mvel e geralmente possuem
suporte diversas tecnologias, como bluetooth, Wi-Fi e USB. Isto proporciona
inmeras funes a estes dispositivos, que podem ser utilizados a qualquer momento
em qualquer lugar, tanto para uso pessoal como profissional.
A evoluo destes dispositivos permite que se tornem cada vez mais poderosos quanto
sua capacidade de processamento, armazenamento, comunicao e interao com o
usurio. Alm disso, diversas plataformas j foram criadas e at mesmo
descontinuadas para dar lugar a plataformas mais modernas e robustas. Algumas das
principais plataformas que existem atualmente so o iOS da Apple, o Windows Phone
da Microsoft, o BlackBerry da RIM e o Android desenvolvido pela Open Handset
Alliance (OHA).
Cada uma destas plataformas possui caractersticas prprias e configura um ambiente
diferente para desenvolvimento, com linguagens de programao e APIs totalmente
diferentes. A plataforma iOS por exemplo, utiliza a linguagem de programao
Objective C, enquanto a plataforma Android utiliza a linguagem Java e a plataforma
Windows Phone utiliza a linguagem C#. Porm, a linguagem de programao no a
nica diferena entre elas. Existem diferenas considerveis na arquitetura de cada
uma, como gerenciamento de permisses, processos, threads e memria.
Portanto, ao desenvolver para uma plataforma especfica importante levar em
considerao as especificidades de cada arquitetura e analisar o que cada API oferece.
At mesmo entre dispositivos mveis diferentes que utilizam a mesma plataforma
existem caractersticas importantes que devem ser levadas em considerao no
61
desenvolvimento, como capacidade de processamento, consumo de bateria ou at
mesmo recursos disponveis em um dispositivo que podem no estar presentes em
outro. A tecnologia NFC um exemplo de recurso que no est presente na maioria
dos dispositivos e plataformas at o momento (GSMARENA, 2012).
Existem frameworks de desenvolvimento multi-plataforma, que visam facilitar a
construo de aplicaes para as principais plataformas de dispositivos mveis com a
utilizao do mesmo cdigo-fonte. Um exemplo desse tipo de framework o PhoneGap
da Adobe, que utiliza HTML, CSS e Javascript para gerar aplicaes para as principais
plataformas. Outra opo o Monocross desenvolvido pela ITR Mobility que prope o
uso da linguagem C# com o framework Mono para o desenvolvimento sobre as
plataformas Android, iOS e Windows Phone.
Entretanto, tais frameworks solucionam apenas uma parte dos problemas, pois existem
algumas aplicaes que no podem ser construdas com a utilizao de uma API
genrica, como aplicaes que utilizam chamadas de baixo nvel dentro do sistema
operacional, aplicaes que precisam de alto desempenho ou que necessitem de
partes muito especficas do SDK nativo da plataforma, como utilizao de componentes
ou perifricos proprietrios.
Dentre as principais plataformas para dispositivos mveis, apenas as plataformas
Android e BlackBerry possuem suporte tecnologia NFC. As outras plataformas, iOS e
Windows Phone, ainda no possuem suporte oficial esta tecnologia at a data de
concluso deste trabalho. A presena da tecnologia NFC em algumas das principais
plataformas refora sua importncia.
Dentre as plataformas que j suportam a tecnologia NFC, o Android alm de ter o
cdigo-fonte aberto, tem um nmero de dispositivos mveis compatveis maior se
comparado ao Blackberry. Isto se deve pela prpria concepo da plataforma, que no
provm de uma nica empresa, mas sim de vrias. Por causa destas caractersticas, a
plataforma Android ser abordada com mais detalhes neste trabalho.
62
3.1. PLATAFORMA ANDROID
Android uma plataforma de cdigo aberto para dispositivos mveis que foi criada pelo
Google e pela OHA. Seu sistema operacional baseado em uma verso modificada do
Linux e inicialmente foi desenvolvido por uma empresa de mesmo nome, chamada
Android Inc (LEE, 2011). Posteriormente, em 2005, foi comprada pelo Google, que
continuou o seu desenvolvimento em conjunto com a OHA.
O objetivo do Google que o Android tivesse cdigo aberto e livre de custos (LEE,
2011). Por isso a maior parte do cdigo do Android foi lanada sob o modelo de licena
Apache para cdigo aberto. Isto significa que qualquer um pode baixar seu cdigo fonte
e reproduz-lo. Desta maneira, fabricantes de dispositivos mveis podem adicionar
suas prprias customizaes na plataforma para diferenciar seus produtos. Algumas
empresas como Sony Ericsson e Motorola, que por muitos anos desenvolveram seus
dispositivos com seus prprios sistemas operacionais, passaram a utilizar o sistema
operacional Android para operar o hardware de seus dispositivos.
Parte do sucesso dos dispositivos mveis se deve s aplicaes que so oferecidas
para a plataforma e que complementam sua funcionalidade. A plataforma Android
oferece uma abordagem unificada para desenvolvimento de aplicaes, que possibilita
que uma aplicao desenvolvida para a plataforma Android seja compatvel com
inmeros dispositivos mveis diferentes.
Segundo (BURNETTE, 2009), apesar de j existirem muitas plataformas para
dispositivos mveis, o Android a primeira plataforma a combinar as seguintes
caractersticas:
Uma plataforma de desenvolvimento livre baseada em Linux: por ter o cdigo

fonte aberto, os fabricantes podem customizar a plataforma sem a necessidade
de pagamento de royalties. Para os desenvolvedores tambm importante, pois
no tem sua evoluo limitada ou condicionada a apenas um fabricante;
Uma arquitetura baseada em componentes que podem ser substitudos para

customizao do sistema;
Diversos servios embutidos: servios de localizao, por exemplo, utilizam o

GPS ou o mtodo de triangulao das torres de celular para oferecer contedo
63
baseado na localizao do dispositivo. Alm disso, possui banco de dados SQL
para facilitar o armazenamento de informaes, componentes para visualizao
de mapas e sites, entre outros. Todos estes servios podem ser utilizados
diretamente pelas aplicaes e ajudam a aumentar suas funcionalidades e
diminuir o esforo necessrio para desenvolvimento;
Gerenciamento automtico do ciclo de vida de uma aplicao: programas so

isolados uns dos outros, atravs de mltiplas camadas de segurana que
fornecem um elevado nvel de integridade e estabilidade. O usurio no precisa
se preocupar se as aplicaes esto ativas ou at mesmo em fechar aplicaes
para que outras possam executar, pois o Android otimizado para dispositivos
com recursos limitados de energia e memria;
Grficos e sons de alta qualidade: o sistema possui suporte a diversos padres

de udio e vdeo como H.264, MP3 e AAC. Alm disso, oferece suporte a
grficos 3D com OpenGL para o desenvolvimento de jogos e aplicaes mais
avanadas;
Portabilidade: todas as aplicaes so desenvolvidas com a linguagem Java e

executadas pela mquina virtual especfica do Android, denominada Dalvik.
Desta forma, o cdigo escrito torna-se portvel entre arquiteturas ARM, x86, e
quaisquer outras que possurem uma mquina virtual compatvel. Tambm
oferece suporte a diversos mecanismos de entrada, como teclados, mouses,
toques de tela e diversas resolues de tela. Desta forma, o sistema operacional
oferece suporte a diversos dispositivos diferentes.
3.1.1. OPEN HANDSET ALLIANCE

A Open Handset Alliance um grupo de 84 empresas de tecnologia ou dispositivos
mveis que se uniram para acelerar o progresso no desenvolvimento das tecnologias
relacionadas a dispositivos mveis a fim de oferecer aos usurios uma melhor
experincia com estes dispositivos (OHA, 2012). As empresas que fazem parte desta
aliana exercem um papel importante nos mais variados segmentos de um
ecossistema para dispositivos mveis, e so, por exemplo, operadoras de celular,
fabricantes de dispositivos, semicondutores, software e at mesmo empresas de
64
comercializao. Alguns exemplos de empresas envolvidas nesta aliana so HTC,
Motorola, T-Mobile, Sony Ericsson e Qualcomm.
Esta aliana responsvel pelo desenvolvimento da plataforma Android, que foi a
primeira plataforma livre e de cdigo aberto para dispositivos mveis. Tambm so
responsveis por fazer com que a plataforma obtenha sucesso atravs do lanamento
de solues comerciais baseadas nesta plataforma. Para fornecer sempre uma melhor
experincia com o software, a aliana se compromete a continuar desenvolvendo a
plataforma, oferecendo inovao rpida e de qualidade sem que desenvolvedores e
fabricantes tenham custos com licenciamento (OHA, 2012).
Um comprometimento com a abertura da plataforma, uma viso compartilhada para o
futuro e planos concretos para fazer com que esta viso se torne uma realidade.
(MEIER, 2011)
Uma plataforma aberta como o Android, permite que componentes de software sejam
integrados mais facilmente e minimiza o custo de aquisio da plataforma,
possibilitando que os fabricantes invistam mais em outros componentes.
O sucesso da plataforma Android depende do sucesso dos membros desta aliana em
lanar solues baseadas nesta plataforma. Sendo assim, estas empresas visam
facilitar o trabalho dos desenvolvedores, permitindo que a comercializao de
aplicativos seja fcil e tenha baixo custo (OHA, 2012). O fato de a plataforma possuir
cdigo fonte aberto permite que os desenvolvedores tenham uma melhor compreenso
do sistema e possam aperfeioar suas aplicaes. Alm disso, as empresas tem o
compromisso de disponibilizar uma API compreensiva para as funcionalidades dos
dispositivos.
3.1.2. ARQUITETURA
A arquitetura da plataforma Android est dividida em cinco partes, que so organizadas
em quatro camadas. Estas camadas compem a pilha de software do Android.
Algumas partes so mais comuns por fazerem parte de outras arquiteturas, como o
kernel Linux, o OpenGL e o banco de dados SQL. Entretanto, algumas partes so bem
diferentes e envolvem conceitos especficos do Android, como o ciclo de vida de uma
65
aplicao. Para construir uma aplicao Android necessrio conhecer estes aspectos
bsicos da plataforma.
O modelo de arquitetura na figura a seguir (LEE, 2011) representa a plataforma
Android e deve ser compreendido da seguinte maneira: cada camada da arquitetura
utiliza os servios fornecidos pelas camadas abaixo dela. Em seguida, sero
apresentadas as principais caractersticas de cada camada, comeando da mais baixa
at a mais alta.
Figura 12 - Arquitetura da plataforma Android
3.1.2.1.
LINUX KERNEL
No nvel mais baixo da arquitetura est o kernel Linux. O Android construdo com
base neste kernel, que foi criado por Linux Torvalds em 1991. O kernel Linux
atualmente pode ser encontrado em qualquer tipo de dispositivo eletrnico, desde
relgios de pulso a supercomputadores. O Linux prov todos os drivers de baixo nvel
necessrios para manipular os componentes de hardware do dispositivo Android.
Esta camada tem a capacidade de abstrair a complexidade da manipulao do
hardware para as camadas superiores do Android, permitindo que o sistema seja
portvel para uma variedade de plataformas. Internamente, o Android utiliza o kernel
66
Linux para o gerenciamento de memria, gerenciamento de processos, comunicao
de rede e outros servios do sistema. Em um dispositivo Android convencional as
aplicaes no so capazes de fazer chamadas diretas ao kernel.
Entretanto, o kit de desenvolvimento fornece algumas ferramentas que so capazes de
interagir diretamente com o kernel. A ferramenta abd shell command, por exemplo,
fornece um terminal de linha de comando onde possvel enviar comandos
diretamente ao kernel Linux do dispositivo.
3.1.2.2.
BIBLIOTECAS NATIVAS
A camada logo acima do kernel Linux contm as bibliotecas nativas do sistema Android
que oferecem as principais funcionalidades do dispositivo. Essas bibliotecas so
desenvolvidas com a linguagem C ou C++ e compiladas para o hardware especfico da
arquitetura utilizada pelo dispositivo. Estas bibliotecas so instaladas pelo fabricante e
compartilhadas com as camadas acima na arquitetura.
importante ressaltar que estas bibliotecas no so aplicaes. Elas so apenas
disponibilizadas para chamadas em nveis mais altos da arquitetura da plataforma.
Tambm possvel criar novas bibliotecas nativas atravs do Native Development Kit
(NDK). Algumas das bibliotecas nativas mais importantes so:
Gerenciador de superfcie: o Android usa um gerenciador de janelas de

composio similar aos sistemas operacionais mais modernos. Em vez de
desenhar os grficos diretamente no buffer de tela, os grficos so
transformados em bitmaps, que em seguida so combinados com outros
bitmaps para formar a imagem que enviada para a tela. Isto facilita a criao
de efeitos de tela, como janelas transparentes e transies animadas;
Grficos 2D e 3D: elementos de duas ou trs dimenses podem ser combinados

em uma nica interface do sistema. A biblioteca capaz de usar um hardware
de acelerao 3D dedicado caso exista, caso contrrio realiza a renderizao
atravs de software;
67
Decodificadores de mdia: atravs de bibliotecas dedicadas o Android pode

gravar e reproduzir vrios formatos de vdeo e udio, como AAC, H.263, H.264,
MP3 e MPEG-4;
Banco de dados SQL: esta biblioteca fornece o mecanismo necessrio para a

manipulao de bancos de dados SQLite. Atravs da utilizao do SQLite o
Android oferece uma opo para persistncia de dados para as aplicaes;
Motor de navegao: o Android possui um navegador moderno para a exibio

de sites que utiliza o motor de navegao WebKit. Esta biblioteca a mesma
utilizada em alguns dos principais navegadores utilizados em computadores
pessoais, como o Google Chrome e o Apple Safari.
3.1.2.3.
ANDROID RUNTIME
Logo acima da camada do kernel Linux e na mesma camada das bibliotecas nativas,
est o Android Runtime. Nele esto uma srie de bibliotecas importantes que permitem
aos desenvolvedores a utilizao da linguagem de programao Java. Aqui tambm
esto as principais bibliotecas Java e a mquina virtual Dalvik.
A mquina virtual Dalvik uma implementao do Java criada pelo Google e otimizada
para dispositivos mveis. Toda aplicao para Android desenvolvida em Java e
executada por esta mquina virtual. O cdigo da aplicao compilado para se tornar
um conjunto de instrues independentes de hardware, que so chamadas bytecodes,
e em seguida so executados pela mquina virtual do dispositivo. Esta mquina virtual
otimizada para dispositivos que precisam de baixo consumo de energia e possuem
pouca memria ou poder de processamento. Alm disso, vrias instncias dessa
mquina virtual podem ser executadas para isolar aplicaes ao mesmo tempo em que
utiliza recursos do kernel para garantir a segurana e o isolamento dos processos.
As principais diferenas da mquina virtual Dalvik com relao a uma mquina virtual
Java tradicional so:
Utilizao de arquivos .dex ao invs de .class ou .jar. Estes arquivos .dex so

convertidos em tempo de compilao a partir de arquivos .class e .jar padres.
68
So arquivos mais compactos e eficientes, ou seja, mais adequados para
utilizao em dispositivos mveis;
As principais bibliotecas Java que so fornecidas com o sistema Android so

implementaes diferentes das encontradas no Java Standard Edition e no Java
Mobile Edition.
3.1.2.4.
FRAMEWORK DE APLICAO
Acima das bibliotecas nativas e do Android Runtime est a camada de framework de

aplicao. Esta camada expe as funcionalidades do sistema Android para
desenvolvedores de aplicaes atravs de blocos de construo de alto nvel. Este
framework instalado no sistema Android por padro, mas tambm pode ser estendido
com componentes proprietrios. As partes mais importantes deste framework so:
Gerenciador de atividades: responsvel pelo gerenciamento do ciclo de vida

das aplicaes e mantm um histrico de navegao entre atividades;
Provedores de contedo: estes elementos encapsulam dados que precisam ser

compartilhados entre as aplicaes, como por exemplo, contatos;
Gerenciador de recursos: responsvel por gerenciar todos os recursos das

aplicaes, que so quaisquer elementos diferentes de cdigo;
Gerenciador de localizao: um dispositivo mvel Android tem a capacidade de

calcular sua localizao atravs do uso de satlites GPS ou torres de
operadoras de celular;
Gerenciador de notificaes: responsvel por controlar avisos exibidos aos

usurios, relativos a eventos do sistema, como chegada de mensagens,
compromissos de agenda, entre outros.
3.1.2.5.
APLICAES E WIDGETS
Esta a camada mais alta na arquitetura da plataforma Android. a nica camada em

que o usurio final tem controle, pois nela que esto os aplicativos e os widgets de
tela. Atravs desta camada, todo o resto da arquitetura abstrado.
As aplicaes so programas que fornecem funcionalidades para o usurio e ocupam
toda a tela do dispositivo, enquanto widgets ocupam pequenas pores da tela e so
69
posicionados na tela principal do sistema Android, denominada home. Geralmente os
dispositivos mveis tm aplicaes pr-instaladas com recursos bsicos, como
discadores, leitores de e-mail, gerenciadores de contatos, navegadores, entre outros.
No sistema Android, a maioria das funcionalidades fornecida atravs de algum
aplicativo especfico. Todas as aplicaes, at mesmo aplicaes de sistema, so
desenvolvidas com a utilizao da API do sistema. Desta forma, possvel que
qualquer aplicao seja substituda por outra que realize as mesmas funes. Por
exemplo, possvel trocar o gerenciador de janelas do sistema ou at mesmo o
discador, por aplicaes proprietrias. Esta qualidade do sistema permite que o mesmo
seja altamente personalizvel.
3.1.3. CICLO DE VIDA DA APLICAO
As aplicaes Android funcionam de maneira diferente de aplicaes para
computadores pessoais, e por isso tem seu ciclo de vida diferente tambm. Em
computadores pessoais, possvel ter vrias aplicaes rodando e visveis ao mesmo
tempo, em diferentes janelas. Apenas uma aplicao ter o foco dos dispositivos de
entrada e responsabilidade do usurio controlar as aplicaes que esto abertas e
fechar as aplicaes que no esto mais sendo utilizadas (BURNETTE, 2009).
Enquanto isso, nos sistemas Android, existe apenas uma aplicao visvel por vez, que
geralmente ocupa todo o espao da tela abaixo da barra de notificao, apesar de
tambm ser possvel ocultar essa barra e deixar a aplicao ocupar a tela inteira. Ao
ligar o dispositivo, a primeira aplicao visvel para o usurio a home. Esta aplicao
geralmente exibe uma imagem como fundo de tela, alguns widgets e atalhos para
outras aplicaes que possam ser abertas. Quando uma destas outras aplicaes
aberta pelo usurio, o sistema executa-a e exibe sua janela na frente de todas as
outras. A partir dessa aplicao, vrias outras aes podem ser realizadas, como
abertura de outras aplicaes ou visualizaes de outras telas da mesma aplicao.
Todas essas aes so armazenadas em uma pilha que possibilita que ao pressionar o
boto voltar de um dispositivo mvel, a tela anterior da pilha seja exibida novamente.
70
Cada tela do sistema Android representada por uma atividade. Portanto, uma
aplicao Android composta por uma ou mais atividades agrupadas dentro de um
processo. Neste sistema operacional, uma aplicao pode continuar viva mesmo que
seu processo tenha sido finalizado. Isto acontece porque cada atividade possui seu
prprio ciclo de vida, e este ciclo no est relacionado com o ciclo de vida do processo,
j que no Android, processos so apenas contineres para atividades. O diagrama a
seguir mostra o ciclo de vida de uma atividade, onde cada retngulo representa um
evento gerado para transio entre os estados (ACTIVITY, 2012):
Figura 13 - Ciclo de vida de uma atividade do Android
71
As atividades do sistema so gerenciadas atravs de uma pilha de atividades do
Gerenciador de atividades. Quando uma nova atividade iniciada, ela colocada no
topo da pilha e se torna a atividade corrente. Qualquer outra atividade da pilha no se
tornar a atividade corrente at que todas as atividades acima dela na pilha sejam
finalizadas e desempilhadas. Uma atividade pode ter os seguintes estados:
Ativa ou corrente: se a atividade est sendo exibida na tela, ou seja, est no

topo da pilha;
Pausada: se a atividade perdeu o foco, mas ainda est visvel. Isto acontece se
outra atividade que no ocupe toda a tela est posicionada logo acima desta, e
detm o foco. Uma atividade neste estado ainda est completamente viva, mas
pode ser finalizada se o sistema enfrentar problemas de memria baixa;
Parada: se uma atividade sobrepe completamente outra. Neste caso a

atividade ainda mantm suas informaes, porm, como sua janela no est
mais visvel, pode ser finalizada a qualquer momento caso o sistema precise de
memria;
Finalizada: se o sistema decidiu remov-la da memria. O sistema pode fazer

isso de duas formas, solicitando sua finalizao ou simplesmente finalizando seu
processo. Ao retornar para esta atividade, a mesma deve ser completamente
reconstruda.
As aplicaes no Android no podem controlar a troca de estados diretamente, pois

isso uma tarefa do sistema. Entretanto, elas podem monitorar a troca de estados
atravs dos eventos que so disparados pelo sistema. Em um ciclo de vida comum de
uma atividade, os seguintes eventos so disparados (ACTIVITY, 2012):
onCreate(Bundle): ocorre quando a atividade iniciada pela primeira vez. Este

o momento em que a aplicao deve inicializar dados estticos, como criao de
visualizaes e ligao de dados componentes de tela. Este mtodo tambm
prov um parmetro que fornece os dados salvos de um estado anterior pelo
mtodo onSaveInstanceState(), caso existam. Em um ciclo natural da aplicao,
o prximo evento lanado pelo sistema o onStart();
72
onRestart(): ocorre aps uma atividade ter sido parada e iniciada novamente. O
prximo evento o onStart();
onStart(): ocorre quando a atividade vai se tornar visvel para o usurio. O

prximo evento o onResume() caso a atividade seja exibida na tela ou
onStop(), caso contrario;
onResume(): ocorre quando a atividade comea a interagir com o usurio. Neste

ponto a atividade est no topo da pilha e possui o foco para entrada de dados. O
prximo evento o onPause();
onPause(): ocorre quando o sistema est prestes a continuar a execuo de

uma atividade anterior ou a atividade atual simplesmente dar lugar para outra
atividade. Neste momento pode ser importante salvar alteraes de dados, parar
animaes e qualquer outra tarefa que esteja consumindo o uso da CPU do
dispositivo. O prximo evento onResume() caso a atividade volte para o topo
da pilha ou onStop() caso no seja mais visvel para o usurio;
onStop(): ocorre quando a atividade no est mais visvel para o usurio. Pode
acontecer por causa da inicializao de uma nova atividade, por causa da
continuao de uma atividade anterior ou porque a atividade est sendo
finalizada. O prximo evento onRestart() caso a atividade volte para execuo
ou onDestroy() caso seja realmente destruda;
onDestroy(): o ltimo evento que ocorre antes da atividade ser finalizada. Pode
acontecer por uma chamada proposital da aplicao ou porque o sistema est
temporariamente finalizando a instncia da atividade para economizar memria;
onSaveInstanceState(Bundle): ocorre quando a atividade est saindo do topo da

pilha e se tornando invisvel, e permite que dados sejam armazenados dentro do
Bundle, para que possam ser restaurados depois caso a atividade necessite ser
recriada;
onRestoreIntanceState(Bundle): ocorre quando a atividade est sendo recriada

a partir de um estado anterior. A implementao padro deste mtodo recupera
os dados relativos aos componentes da interface.
Assim como as atividades, os processos que as contm tambm tem seu prprio ciclo
de vida. O Android se preocupa em manter os processos das aplicaes pela maior
73
quantidade de tempo possvel, porm quando o sistema fica com pouca memria
disponvel, os processos mais antigos so removidos. O sistema finaliza os processos
menos importantes primeiro, e caso no seja o suficiente, finaliza processos mais
importantes at que recupere a estabilidade. Existem quatro estados em que os
processos podem estar, baseados nas atividades que existam dentro deles. Estes
processos, em ordem de importncia, so:
Atividade de primeiro plano: quando a atividade est no sendo exibida na tela.

Esta atividade s pode ser finalizada como uma ltima tentativa, caso ela utilize
mais memria do que est disponvel no dispositivo. Geralmente, neste ponto o
dispositivo atingiu um ponto em que necessria a finalizao da atividade para
que a interface do dispositivo continue respondendo aos comandos de entrada;
Atividade visvel: quando a atividade est visvel para o usurio, mas no est
em primeiro plano. Ocorre por exemplo, quando uma caixa de dilogo est
visvel na tela. Esta atividade no ser finalizada at que seja extremamente
necessrio para continuar a execuo da atividade em primeiro plano;
Atividade de segundo plano: quando a atividade no est visvel ao usurio e foi

pausada. Neste caso, o sistema pode finalizar com segurana o processo para
obter mais memria para a atividade em primeiro plano. Quando o usurio volta
para esta atividade, ela pode ser facilmente recriada e ter seu estado
recuperado;
Processo vazio: quando o processo no tem atividades ou quaisquer outros

componentes de aplicao. So os primeiros processos a serem finalizados pelo
sistema quando a memria est baixa.
No caso da atividade necessitar de uma operao que exija um tempo longo de

execuo e seja independente do ciclo de vida da atividade controlado pelo sistema,
deve-se iniciar um servio. Desta forma, o sistema deve priorizar o processo que a
contm, considerando-a mais importante do que outras atividades que no esto
visveis, independentemente da atividade original estar pausada, parada ou finalizada.
Um upload de arquivo um bom exemplo disso, pois deve continuar mesmo que o
usurio saia da atividade original.
74
3.1.4. BLOCOS DE CONSTRUO
Os blocos de construo so elementos definidos no SDK do Android que devem ser
utilizados para a composio de uma aplicao. Existem quatro blocos de construo
bsicos, mas nem todas as aplicaes utilizam todos os blocos de construo
disponveis. Estes blocos so representados pelas atividades, pelas intenes, servios
e provedores de contedo.
Uma atividade uma tela de interface com o usurio. As aplicaes podem usar uma
ou mais atividades para controlar diferentes partes da mesma. Cada aplicao
responsvel por salvar seu prprio estado, para que possa ser reiniciada
posteriormente, conforme demonstrao do ciclo de vida da aplicao no item anterior.
Em verses mais recentes do Android, atividades podem ser segmentadas em blocos
menores denominados fragmentos. Cada fragmento tambm possui seu prprio ciclo
de vida dentro de uma atividade e responsvel por gerenciar uma parte da interface.
Uma inteno um mecanismo para descrever uma ao especfica do sistema. No
Android a maioria das aes executada com a utilizao de intenes. Desta forma,
possvel substituir ou reutilizar componentes. Selecionar uma foto, abrir o discador,
informar inicializao do sistema e enviar um e-mail so exemplos de aes
especificadas com intenes. possvel criar aplicaes que escutem por
determinadas aes, a fim de substituir o mecanismo padro do dispositivo para aquela
ao, por exemplo. Tambm possvel fazer com que uma aplicao execute a ao
de selecionar uma foto atravs de uma inteno, fazendo com que o programa
responsvel por selecionar uma foto seja aberto, independentemente de qual seja.
Servios so tarefas que executam em segundo plano e no possuem interao direta
com o usurio. Por exemplo, uma msica pode ser executada atravs de uma atividade
do tocador de msica, porm, para que ela continue tocando mesmo aps o usurio
trocar de tela ou at mesmo abrir outra aplicao, necessrio que um servio seja
utilizado. Desta forma, o cdigo responsvel por gerar a sada de udio deve ser
inserido no servio. Com esta estrutura possvel fazer com que outras atividades se
conectem ao servio e enviem comandos de troca de msica ou alterao de volume,
75
por exemplo. O Android possui diversos servios embutidos, que podem ser acessados
atravs da API, para funcionalidades mais comuns.
Um provedor de contedo um conjunto de dados reunidos em uma API customizada
para leitura e escrita destes dados. Esta a melhor maneira que o sistema prov para
troca de dados entre as aplicaes. Por exemplo, o Google oferece um provedor de
contedo para contatos. Ento, toda a informao dos contatos pode ser compartilhada
com qualquer outra aplicao que necessite.
3.1.5. RECURSOS
Um recurso um elemento localizvel, como um texto, um bitmap ou qualquer outro
elemento que no seja cdigo e que seja necessrio para a aplicao. A plataforma
Android prov um mecanismo para localizao de recursos atravs de nomenclatura de
pastas. Durante a compilao estes recursos so embutidos na aplicao. Para que
isso acontea, todos os recursos devem ser armazenados dentro da pasta res de um
projeto Android.
Durante a compilao, um compilador de recursos tambm executado, e processa os
recursos de acordo com o tipo de arquivo e subpasta em que esto. Por exemplo,
arquivos bitmap devem ser armazenados na subpasta drawable enquanto arquivos
XML que descrevem os layouts devem ser armazenados na subpasta layout. O
compilador ento comprime e armazena todos os recursos, gerando uma classe
chamada R, que contm identificadores estticos que referenciam os recursos da
aplicao.
Para
utilizao
dos
recursos
estes
identificadores
precisam
ser
referenciados, e desta maneira possvel garantir que todos os recursos so vlidos.

3.1.6. SEGURANA
No sistema Android, cada aplicao roda em seu prprio processo e o hardware fica
responsvel por proibir aplicaes de acessarem a memria que est sendo utilizada
por outras aplicaes (BURNETTE, 2009). Alm disso, toda aplicao possui seu
prprio usurio para execuo dentro do kernel Linux. Isto significa que qualquer
arquivo criado por uma aplicao no pode ser lido por outra aplicao, pois os
usurios so diferentes.
76
Outro fator importante da segurana no ambiente Android que operaes crticas
necessitam de permisso do usurio para serem utilizadas pela aplicao. Para isto, a
aplicao deve conter em seu arquivo de manifesto, denominado Android-Manifest.xml,
a lista de permisses necessrias para sua execuo. Assim, quando a aplicao for
instalada pelo usurio, o gerenciador de pacotes do sistema operacional se
encarregar de perguntar se o usurio concede ou no o acesso s funcionalidades
requisitadas pela aplicao. Alguns exemplos de permisses mais comuns so:
INTERNET: permisso de acesso internet;
READ_CONTACTS: permisso apenas para leitura dos contatos do usurio;
ACCESS_FINE_LOCATION: permisso para obter uma localizao precisa do

dispositivo, atravs de um GPS, por exemplo.
O Android tambm oferece a opo de restringir o acesso determinadas partes do

sistema. Atravs do arquivo de manifesto possvel restringir quem pode iniciar uma
atividade, iniciar um servio, disseminar uma inteno ou acessar dados em um
provedor de contedo.
3.1.7. SUPORTE AO NFC
A plataforma Android suporta a tecnologia NFC desde o nvel 9 de sua API, que foi
evoluindo ao longo das verses para, entre outras melhorias, fornecer maior suporte
tecnologia. Atualmente a API est no nvel 16 e possui suporte apenas dois modos
de operao da tecnologia: leitura/escrita e peer-to-peer. O modo de emulao de
cartes ainda no est disponvel (GRUNTZ, 2011).
A API do Android utiliza o formato NDEF para representar as mensagens. A leitura de
uma tag NFC com uma mensagem NDEF gerenciada pelo sistema de despacho de
tags presente no sistema, que analisa as tags, identifica e categoriza seus dados e
inicia a aplicao responsvel associada a esse tipo de dado. Uma aplicao que
pretende se associar a um determinado tipo de tag deve declarar uma inteno no seu
arquivo de manifesto e solicitar o gerenciamento dos dados, para que possa enfim
obter os dados da tag.
77
O sistema disponibiliza ainda uma funcionalidade denominada Android Beam que
permite que um dispositivo envie uma mensagem NDEF para outro dispositivo atravs
do gesto de aproximao dos dispositivos. possvel utilizar o Android Beam para
compartilhar contatos, sites e vdeos com outros dispositivos. A aplicao que pretende
enviar os dados para outro dispositivo atravs do modo peer-to-peer do NFC deve
estar em primeiro plano e o dispositivo alvo no deve estar travado. Ento, quando os
dispositivos so aproximados, o dispositivo iniciador exibe a interface do Android Beam
onde o usurio deve escolher se vai enviar a mensagem para o dispositivo alvo ou no.
Este recurso deve ser habilitado na aplicao atravs dos seguintes mtodos:
setNdefPushMessage(): recebe uma mensagem NDEF que configurada como

mensagem a ser enviada e automaticamente envia a mensagem quando os
dispositivos esto prximos o suficiente;
setNdefPushMessageCallback():
recebe
um
callback
que
contm
um
createNdefMessage(). Este mtodo, por sua vez, chamado quando outro

dispositivo est no raio de alcance para envio de mensagens.
Uma atividade pode enviar apenas uma mensagem NDEF por vez, portanto o mtodo
setNdefPushMessageCallback()
tem
precedncia
sobre
mtodo
setNdefPushMessage() se os dois esto sendo chamados. Alm disso, para usar o

Android Beam, os dispositivos devem respeitar as seguintes regras: a atividade do
dispositivo iniciador deve estar em primeiro plano, os dois dispositivos devem estar
desbloqueados, os dados a serem enviados devem estar encapsulados em uma
mensagem NDEF e o dispositivo alvo deve suportar o protocolo NDEF Push Protocol
ou SNEP, dependendo do nvel da API de sua plataforma.
A partir do nvel 14 da API, foi introduzido um novo tipo de registro para mensagens
NDEF, denominado Android Application Record (ARR). Este tipo visa garantir de forma
mais confivel que uma determinada aplicao iniciada quando uma mensagem
desse tipo recebida. Um registro ARR tem o nome do pacote de uma aplicao
embutido dentro de um registro NDEF. Se ao ler a mensagem NDEF, o sistema
identificar um registro ARR, a aplicao baseada no nome do pacote fornecido
iniciada e, caso a aplicao no seja encontrada, a loja de aplicativos iniciada para
78
que possa ser realizado o download da mesma. Estes registros so teis para prevenir
que outras aplicaes utilizem as mesmas intenes e manipulem mensagens
especificas da aplicao original. Se uma mensagem contm um registro ARR, o envio
funciona da seguinte maneira (NFCAPI, 2012):
Tenta executar uma atividade atravs do filtro de intenes, de maneira usual.

Se a atividade que est vinculada a inteno tambm for compatvel com o
registro ARR, inicia a atividade;
Se a atividade que est vinculada a inteno no for compatvel com o registro

ARR, verifica se existem outras atividades vinculadas. Se existirem mltiplas
atividades que esto vinculadas inteno ou se nenhuma atividade est
vinculada, inicia a aplicao especificada dentro do registro;
Se nenhuma aplicao pode ser iniciada com o registro, inicia a loja de

aplicativos para realizar o download do aplicativo de acordo com o nome do
pacote especificado no registro.
3.1.7.1.
SISTEMA DE DESPACHO DE MENSAGENS
A mensagem NDEF representada pela classe NdefMessage que contm um ou mais

registros, representados pela classe NdefRecord. Alm disso, o sistema Android
suporta alguns tipos de tags que no contm mensagens NDEF, e que podem ser
manipulados atravs de classes presentes no pacote android.nfc.tech. Utilizar estes
tipos de tags envolve a elaborao de um protocolo de comunicao proprietrio, e por
isso tendem a ter um uso mais restrito. Quando um dispositivo Android l uma tag NFC
contendo dados representados por mensagens NDEF, ele interpreta a mensagem e
tenta descobrir qual o tipo de dado que a mensagem carrega. Para isso, o sistema l o
primeiro registro dentro da mensagem NDEF e determina como deve interpretar toda a
mensagem NDEF (NFCAPI, 2012).
O sistema de despacho de mensagens utiliza o campo TNF e TYPE para identificar o
tipo MIME ou URI da mensagem. Caso obtenha sucesso, encapsula essa informao
em uma inteno denominada ACTION_NDEF_DISCOVERED, que contm o payload
da mensagem. Porm, quando este sistema no consegue determinar o tipo de dado
baseado no primeiro registro, um objeto Tag, que contm informaes a respeito do
79
tipo de tag, e o payload da mensagem so encapsulados em uma inteno
denominada ACTION_TECH_DISCOVERED.
Aps a identificao e o encapsulamento da tag NFC, o sistema envia a inteno para
a aplicao vinculada ao tipo de inteno determinado. Caso mais de uma aplicao
esteja vinculada, um seletor de aplicao oferecido ao usurio, para que ele escolha
com qual deseja prosseguir. O sistema de despacho de mensagens define trs tipos de
intenes, que sero descritas por ordem de prioridade:
ACTION_NDEF_DISCOVERED: esta inteno utilizada para iniciar uma

atividade quando uma tag que contm um payload NDEF detectada e tem um
tipo reconhecido;
ACTION_TECH_DISCOVERED: caso no haja atividades vinculadas inteno

anterior, o sistema tenta encontrar uma atividade vinculada a esta inteno. Se a
tag contm dados que no podem ser mapeados por um tipo MIME ou URI, ou
ento no contm dados NDEF mas possui uma tecnologia conhecida, esta
inteno acionada diretamente e o sistema tenta encontrar uma atividade
vinculada para inici-la;
ACTION_TAG_DISCOVERED: esta inteno acionada caso nenhuma das

anteriores possua atividades vinculadas.
O modelo a seguir, demonstra o funcionamento bsico do sistema de despacho de

mensagens (NFCAPI, 2012):
80
Figura 14 - Funcionamento do mecanismo de despacho de mensagens
O seguinte fluxo executado:
O sistema tenta iniciar uma atividade com a inteno que foi criada pelo sistema
de despacho de mensagens quando interpretou a tag NFC, que pode ser
ACTION_NDEF_DISCOVERED ou ACTION_TECH_DISCOVERED;
Se nenhuma atividade est vinculada a esta inteno, tenta executar uma

atividade que esteja vinculada a uma inteno de prioridade inferior at que seja
encontrada uma atividade ou at que todas as intenes tenham sido
verificadas;
Se nenhuma atividade for encontrada, nada mais feito.
81
4.
DESENVOLVIMENTO DA APLICAO
O sistema desenvolvido neste trabalho tem como principal funcionalidade o pagamento

de tarifas relacionadas a um sistema de transporte com a utilizao da tecnologia NFC
no modo peer-to-peer. Isto significa que os dois dispositivos envolvidos nesta
comunicao so ativos. Para este sistema, foram desenvolvidas duas aplicaes para
controle das funcionalidades de cada dispositivo no contexto do pagamento de tarifas.
Uma das aplicaes foi desenvolvida para dispositivos mveis com o sistema
operacional Android e a outra foi desenvolvida para utilizao de um dispositivo leitor
em computadores pessoais que suportem a tecnologia Java e possuam driver para tal
dispositivo.
4.1. AMBIENTE
Neste sistema foram utilizados equipamentos com suporte tecnologia NFC, que
incluem um leitor, um dispositivo mvel e algumas tags NFC. Todos estes elementos
so fundamentais para garantir a funcionalidade do sistema. A seguir sero descritos
os papeis de cada um dos dispositivos envolvidos sistema e os detalhes do
desenvolvimento de cada aplicao, incluindo o funcionamento do protocolo de
comunicao, os frameworks que foram utilizados e a arquitetura proposta.
Figura 15 - Dispositivos NFC utilizados para o desenvolvimento
82
4.1.1. LEITOR NFC
O leitor NFC utilizado neste trabalho o ACR122U, fabricado pela Advanced Card
Systems, empresa especializada em tecnologias relacionadas a smartcards e
dispositivos leitores para tais tecnologias. Este leitor possui interface USB para
conexo com um computador e prov comunicao para tecnologias contactless
baseadas na frequncia 13.56 MHz, dentre elas o NFC e alguns tipos de tags RFID.
Alm de leitura, este dispositivo tambm capaz de realizar operaes de escrita em
tags e smartcards.
O dispositivo compatvel com a especificao ISO/IEC 18092 da tecnologia NFC e
suporta cartes ISO/IEC 14443 Tipo A, ISO/IEC 14443 Tipo B e tambm os quatro
tipos de tags especificadas pelo NFC Forum. Para a comunicao com um
computador, o dispositivo utiliza a especificao Personal Computer/Smart Card
(PC/SC), que serve para padronizar a comunicao de leitores e smartcards em
ambientes com computadores. Este leitor possui suporte a taxas de comunicao de
at 424 kbps e sua antena interna capaz de se comunicar com smartcards a uma
distncia de at 5 cm, dependendo da tecnologia utilizada. Alm disso, possui recurso
anti-coliso que garante que apenas uma tag acessada por vez, LED para
monitorao do seu estado e alertas sonoros.
O kit de desenvolvimento deste leitor fornece um SDK que contm ferramentas de
apoio para comunicao com o dispositivo e exemplos de utilizao em linguagens
como Java, C# e C++. Porm, estes exemplos apresentam cdigo de baixo nvel, com
instrues que so montadas e enviadas diretamente para o leitor, ou seja, no h
nenhuma camada de software que fornea abstrao da complexidade dessa
comunicao para camadas mais altas da arquitetura de um software.
O leitor capaz de se comunicar com outros dispositivos contactless, porm, para que
uma aplicao NFC seja construda necessrio que haja uma camada de software
que fornea suporte s suas especificaes e seus principais protocolos, como o
NFCIP e o LLCP, entre outros. O SDK fornecido pela empresa no fornece tais
bibliotecas e, portanto, a construo de um framework prprio ou o uso de bibliotecas
83
de terceiros imprescindvel. Para o desenvolvimento com este leitor foi utilizada a
biblioteca NFCTools, que ser descrita neste captulo.
4.1.1.1.
COMUNICAO
A comunicao entre o leitor e outros dispositivos contactless realizada atravs de

unidades de comunicao denominadas Application Protocol Data Unit (APDU), que
so especificadas em ISO/IEC 7816-4 e definem um conjunto de requisio e resposta
com uma estrutura pr-definida. Portanto, para utilizar esse dispositivo na comunicao
com outros dispositivos se torna necessrio o uso de comandos APDU, que so
montados e enviados para o leitor atravs da interface PC/SC disponibilizada pelo seu
driver. O leitor por sua vez, se encarrega de transmitir estas informaes atravs do
meio fsico e receber uma resposta, que direcionada para a origem do comando
(ORTIZ, 2003).
A estrutura de um comando APDU, na maior parte dos casos, possui um cabealho e
um corpo, conforme modelo a seguir:
Figura 16 - Estrutura de um comando APDU
Neste modelo, os campos do cabealho definem a instruo para requisio ao outro

dispositivo, enquanto o corpo, que possui campos opcionais, carrega informaes
relevantes para a execuo desta instruo. O campo CLA define a classificao da
instruo, o campo INS define a instruo em si e os campos P1 e P2 definem
parmetros para a instruo. J no corpo do comando, o campo Lc define o nmero de
bytes presentes no campo Data Field, enquanto o Le define o nmero de bytes que
esperado na resposta deste comando. Com exceo do campo Data Field, todos os
outros possuem apenas 1 byte. O comando representado em hexadecimal para obter a
identificao de um dispositivo NFC, por exemplo, possui o seguinte formato: 0xFF
84
0xCA 0x00 0x00 0x00. Neste exemplo, o ltimo nmero representa o byte do tamanho
do corpo e os campos restantes so omitidos.
J a resposta esperada tambm possui campos opcionais e obrigatrios, assim como
acontece no comando. O modelo de uma resposta representado na figura a seguir:
Figura 17 - Estrutura de uma resposta para um comando APDU
No modelo da resposta possvel observar que o corpo, cujo tamanho pode ou no ter
sido especificado no comando, opcional e os campos subsequentes so obrigatrios.
Os campos SW1 e SW2 possuem 1 byte cada e representam um cdigo de status
relativo ao comando enviado. Uma resposta com os valores hexadecimais 0x90 0x00,
por exemplo, representa sucesso na execuo do comando.
Para a construo dos comandos e interpretao de respostas relativas comunicao
entre o leitor e outro dispositivo, o fabricante disponibiliza um documento que descreve
sua API e fornece alguns exemplos de utilizao. Atravs de uma ferramenta utilitria
fornecida no SDK possvel testar o envio de comandos e recepo de respostas.
4.1.2. DISPOSITIVO MVEL
O dispositivo mvel utilizado neste trabalho o Galaxy SIII, fabricado pela Samsung e
lanado no primeiro semestre de 2012. Os motivos pelos quais este dispositivo foi
escolhido para utilizao neste trabalho foram o seu sistema operacional Android e a
presena da tecnologia NFC. A verso mais recente do Android para este dispositivo,
at a realizao deste trabalho, a 4.0.4. Este sistema possui suporte comunicao
com tags NFC para operaes de leitura e escrita, alm de suporte comunicao
peer-to-peer atravs dos protocolos NPP e SNEP. O protocolo SNEP foi introduzido a
85
partir da verso 4.0 do sistema e o NPP foi criado junto com o incio do suporte
tecnologia NFC no Android, em sua verso 2.3.3.
O chip NFC utilizado por este dispositivo um PN65, produzido pela NXP
Semiconductors. Este chip possui suporte a todos os modos de operao da tecnologia
NFC, alm de possuir um SE. Este SE proporciona um ambiente seguro para execuo
de aplicaes onde um alto nvel de segurana necessrio.
O suporte NFC em dispositivos que utilizam o Android, apesar de existir desde a
verso 2.3.3 do sistema, ainda est amadurecendo. Isto se deve, em partes,
utilizao do servio Android Beam para comunicao no modo peer-to-peer da
tecnologia NFC. Alm disso, no h suporte para uso do SE e nem mesmo ao modo de
emulao de cartes previsto na especificao NFC. Entretanto, possvel enviar
comandos APDU diretamente para o controlador NFC desde que se tenha acesso total
ao sistema operacional do dispositivo. A interao direta com o chip NFC do dispositivo
no foi explorada neste trabalho por se tratar de algo semelhante com a interao que
j acontece entre o leitor e o computador, alm de ser bastante intrusiva para o
dispositivo. Portanto, a prpria API NFC fornecida pelo Android foi utilizada.
O fato de o Android possuir cdigo aberto tambm importante na escolha do
dispositivo, independentemente das customizaes do fabricante que so introduzidas
na plataforma e que no possuem cdigo aberto. As modificaes do sistema esto,
em sua maior parte, concentradas na parte visual e na incluso de funcionalidades. O
cdigo aberto do sistema original auxilia no entendimento de certos recursos. Neste
trabalho foi possvel verificar o funcionamento dos servios que monitoram a presena
de dispositivos NFC e despacham notificaes para outras aplicaes atravs da
anlise do cdigo fonte.
4.1.3. TAGS
Algumas tags NFC foram utilizadas neste trabalho, com o propsito de construir uma
arquitetura que seja funcional tanto com dispositivos ativos quanto com dispositivos
passivos. As tags NFC so dispositivos passivos que possuem custo baixo e tambm
inferior aos dispositivos mveis que suportam NFC e, por isso, possuem um papel
86
importante no sistema, pois podem fornecer retro compatibilidade com sistemas j
existentes para a realizao de pagamentos ou simplesmente serem utilizadas por
usurios que no possuam dispositivos mveis habilitados com a tecnologia NFC.
A principal tag utilizada possui a tecnologia Mifare Ultralight C com capacidade para
144 bytes de informao, uma tag NFC de tipo 2, compatvel com a especificao
ISO/IEC 14443 Tipo A. Esta tag fornecida em dois formatos diferentes, um chaveiro e
um adesivo. Em ambos os formatos as tags possuem as mesmas caractersticas de
funcionamento, mas tem finalidades diferentes. Estas caractersticas garantem a
versatilidade da tecnologia NFC.
Alm das tags, um carto de tecnologia contactless Mifare Classic 1K foi utilizado. Este
carto tambm opera a 13.56 MHz e compatvel com a especificao ISO/IEC 14443
Tipo A e possui 756 bytes de capacidade de armazenamento.
4.1.4. BIBLIOTECAS
Para o desenvolvimento do sistema foi utilizada uma biblioteca denominada NFCTools,
que possui cdigo fonte aberto e mantida pela empresa alem GrundID GmbH, que a
disponibiliza sob o licenciamento Apache e habilita sua utilizao para criao de
software livre ou proprietrio. Esta biblioteca foi desenvolvida sob a plataforma Java e
seu propsito estabelecer uma comunicao entre o dispositivo leitor e outro
dispositivo NFC, como um dispositivo mvel ou at mesmo uma tag. Dentre os leitores
suportados por esta biblioteca, est o ACR122U. Bibliotecas como Open NFC e
LibNFC foram descartadas neste projeto pois a Open NFC no oferece suporte ao
leitor utilizado e a LibNFC no implementa todas as especificaes necessrias para o
modo peer-to-peer da tecnologia NFC.
A biblioteca NFCTools tem carter experimental e foi testada apenas em tags e
smartcards com tecnologia Mifare Classic 1k, Mifare Classic 4k e Mifare Ultralight C,
alm de um dispositivo mvel Nexus S, produzido em uma parceria entre Google e
Samsung. Alm disso, a biblioteca foi desenvolvida com a utilizao do Android 4.0 no
dispositivo. Em verses mais recentes do Android uma pequena instabilidade
87
apresentada pela biblioteca, segundo relatos em seu frum de discusso (NFCTOOLS,
2012).
Para a comunicao com o leitor, esta biblioteca faz uso da API Java Smart Card I/O
especificada por JSR 268. Esta API define a comunicao com smartcards atravs de
APDUs enviados pelo leitor e, portanto, utilizada para abstrair o acesso ao leitor NFC.
O pacote definido por esta API o javax.smartcardio e est disponvel na instalao
padro do JDK.
A biblioteca NFCTools est divida em 4 pacotes:
nfctools-api: este pacote expe uma interface comum utilizada por todos os
outros pacotes. Possui as implementaes bsicas dos padres relacionados
tecnologia NFC e comunicao com leitores;
nfctools-core: possui as especializaes relacionadas tecnologia NFC e

comunicao com leitores e tags. Este pacote d suporte s tecnologias de tags
Mifare, comunicao com leitores de portas seriais, alm de tratar das
diferenas de comandos e respostas entre os leitores suportados;
nfctools-ndef: possui a implementao da especificao NDEF. Este pacote d

suporte representao, codificao e decodificao de mensagens NDEF;
nfctools-p2p: adiciona suporte ao modo peer-to-peer da tecnologia NFC. Neste

pacote esto as implementaes dos protocolos para comunicao entre
dispositivos ativos, como NFCIP, LLCP, NPP e SNEP;
Para que a biblioteca funcionasse da maneira desejada com a configurao deste

ambiente, algumas alteraes em seu cdigo-fonte foram necessrias. Uma delas foi
necessria para o reconhecimento do chip NFC presente no dispositivo mvel, pois
este chip tem a mesma identificao de uma tag Sony FeliCa. Por causa disso, a
biblioteca considerava que a tecnologia presente no campo eletromagntico do leitor
era uma tag passiva e ento no era capaz de estabelecer uma conexo peer-to-peer.
As outras alteraes realizadas adicionam a funcionalidade de fechamento de uma
conexo peer-to-peer, cuja utilizao ser explicada neste captulo.
Alm das bibliotecas para suporte tecnologia NFC, foram utilizadas outras bibliotecas
como o log4j e a Action Bar Sherlock no desenvolvimento do sistema. O log4j
88
utilizado como mecanismo de log na biblioteca NFCTools e tambm no sistema para
monitorao e identificao de problemas de maneira prtica e flexvel, j que permite
diferentes configuraes de log para pacotes e at mesmo classes atravs de um nico
arquivo de configurao. J o Action Bar Sherlock uma biblioteca que fornece
componentes de tela para verses do Android superiores a 2.0. Esta biblioteca tem
como objetivo padronizar o visual e a interao com o usurio de aplicaes Android,
levando em considerao os conceitos de interface estabelecidos na ltima verso do
sistema.
4.2. O SISTEMA
O sistema desenvolvido neste trabalho apresenta uma soluo para aplicao da
tecnologia NFC para o transporte coletivo, como por exemplo, nibus, trens, entre
outros. Para que isto seja possvel, elementos do sistema esto presentes em mais de
um tipo de dispositivo. Nesta arquitetura, um leitor NFC representa uma catraca e tem
a funo de intermediar o pagamento da tarifa relacionada ao transporte enquanto o
dispositivo mvel ou uma tag tem a funo de identificar o usurio. As funcionalidades
do sistema esto representadas atravs do diagrama de casos de uso a seguir:
Figura 18 - Diagrama de casos de uso do sistema
89
O principal caso de uso estudado ser o Solicitar Pagamento, pois nele que a
tecnologia NFC est diretamente envolvida. Os demais so complementares para
viabilizar a utilizao do sistema. Este caso de uso iniciado com o gesto de aproximar
o dispositivo mvel ou a tag ao leitor. Este gesto indica que o usurio deseja se
identificar e realizar o pagamento. Esta interao pode ser caracterizada como
computao ubqua, j que o ato de realizar o pagamento com o dispositivo mvel no
difere do mesmo ato quando realizado com a utilizao de uma tag, que um
procedimento mais natural. Ambos consistem na aproximao do dispositivo em
direo ao leitor. Quando a distncia mnima para estabelecimento de comunicao
NFC atingida, a comunicao iniciada.
Os elementos presentes neste sistema compem a arquitetura de um sistema
distribudo, onde cada um responsvel por uma funcionalidade ou uma etapa do
processamento. Neste trabalho o foco foi dado ao desenvolvimento da comunicao
entre o leitor e o dispositivo mvel atravs do modo peer-to-peer da tecnologia NFC.
Entretanto,
modo
leitura/escrita
tambm
foi
desenvolvido
para
avaliar
heterogeneidade da arquitetura e a retro compatibilidade do sistema com arquiteturas

j existentes.
A pr-condio para o funcionamento deste sistema a criao de uma conta de
usurio em um site especfico para manuteno de contas, que ficaria disponvel
atravs da internet. A criao deste site no faz parte do escopo do sistema, pois se
trata de uma aplicao web, mas essencial para armazenamento de informaes de
usurio e garantia de integridade de informaes tanto de usurios quanto de
pagamentos.
O diagrama de implantao d uma viso mais detalhada dos elementos utilizados na
arquitetura deste sistema e os artefatos que foram utilizados ou criados para cada um
deles. Este diagrama pode ser visualizado na figura a seguir:
90
Figura 19 - Diagrama de implantao do sistema
Para utilizao do sistema com um dispositivo mvel, o usurio tambm precisaria

instalar a aplicao correspondente em seu dispositivo, alm de configur-la com uma
conta previamente cadastrada pelo site descrito acima. Alm disso, necessrio que o
91
usurio possua crditos em sua conta, que podem ser adquiridos atravs do prprio
aplicativo. Para as funcionalidades de configurao de conta e compra de crditos, o
dispositivo mvel precisaria estar conectado internet. A configurao da conta feita
uma nica vez enquanto a compra de crditos realizada de maneira mais frequente.
No entanto, a utilizao de tags no teria pr-condies, pois obrigatoriamente j
seriam entregues pr-configuradas aos usurios do transporte e precisariam ser
recarregadas em postos de recarga compatveis com o sistema.
A utilizao do dispositivo mvel para realizar o pagamento desencadeia um processo
que passa por diversos elementos da arquitetura, at que o acesso ao transporte seja
liberado por uma catraca. O diagrama de atividades a seguir demonstra a comunicao
realizada para o caso de uso Solicitar Pagamento:
Figura 20 - Diagrama de atividades do caso de uso Solicitar Pagamento
Outros elementos tambm existem para dar suporte ao funcionamento do sistema,

porm tem importncia secundria para este trabalho. Classificados como elementos
92
secundrios esto o servio de gerenciamento de contas de usurio e o servio de
pagamentos.
O servio de gerenciamento de contas de usurio ficaria disponvel para interao com
a aplicao dos dispositivos mveis atravs da internet, e realizaria a validao de
contas de usurios e intermediao da compra de crditos. A validao das contas de
usurios seria realizada com a utilizao de um protocolo como o OAuth, que
possibilita que a aplicao do dispositivo interaja com outros elementos da arquitetura
em nome do usurio, sem que seja necessrio o armazenamento da senha do mesmo.
O protocolo OAuth fornece um token de acesso que utilizado em aes posteriores
da aplicao, como compra de crditos e solicitaes de pagamentos. Este mtodo
mais vantajoso do que a utilizao da senha do usurio nas operaes, pois desta
forma seria possvel bloquear a utilizao do dispositivo a qualquer momento apenas
invalidando o token de acesso a partir do site de manuteno de contas. J a compra
de crditos dependeria de configuraes de pagamentos associadas conta e que
tambm seriam cadastradas atravs do site.
O servio de pagamentos seria disponibilizado atravs da internet, possivelmente com
a utilizao de alguma tecnologia para segurana de redes, como Virtual Private
Network (VPN) e Firewalls, por exemplo. O computador com o leitor NFC seria o
elemento
responsvel
por
estabelecer
uma
conexo
com
este
servio
consequentemente validar e efetivar o pagamento solicitado pelo outro dispositivo.

responsabilidade deste servio tambm, realizar o dbito no saldo da conta do usurio
corretamente.
4.2.1. A APLICAO DO DISPOSITIVO MVEL
A aplicao desenvolvida para o dispositivo mvel tem como principal funcionalidade
auxiliar o usurio no pagamento das tarifas atravs da tecnologia NFC, com o mnimo
de interao possvel. A aplicao foi desenvolvida com base no SDK de nmero 15 da
plataforma, que no fornece suporte ao desenvolvimento de aplicaes para o SE do
hardware NFC presente no dispositivo. A aplicao utiliza o layout padro da
plataforma e possui todas as literais em um arquivo de recursos, possibilitando a
localizao dos mesmos.
93
No arquivo de manifesto, que descreve os recursos necessrios e a estrutura da
aplicao, esto definidas as permisses, bibliotecas e atividades necessrias para sua
execuo. Para o uso da tecnologia NFC necessrio que a aplicao tenha uma
permisso para acessar o hardware NFC do dispositivo, que deve ser requisitada
atravs da incluso da seguinte entrada no arquivo de manifesto:
<uses-permission android:name="android.permission.NFC" />
Alm desta permisso, o aplicativo tambm necessita das seguintes permisses:
READ_PHONE_STATE: permite que a aplicao obtenha dados de identificao

do celular, que podem ajudar na preveno de fraudes;
INTERNET: permite o acesso internet para validao de contas de usurio e

compra de crditos;
ACCESS_FINE_LOCATION: permite o acesso localizao do usurio atravs

do sensor GPS;
VIBRATE: permite alertas vibratrios durante a realizao de tarefas no

aplicativo;
Alm da permisso, o aplicativo precisa ter alguma atividade que tenha a capacidade
de processar informaes relativas ao NFC. No caso desta aplicao, a tela principal
uma atividade capaz de processar estas informaes. Esta capacidade adicionada
atravs da utilizao de intenes NFC presentes na plataforma, que so configuradas
com as seguintes entradas no arquivo de manifesto:
<intent-filter>
<action android:name=android.nfc.action.NDEF_DISCOVERED />
<data android:mimeType=application/org.nfc.mackenzie />
<category android:name=android.intent.category.DEFAULT />
</intent-filter>
Desta forma, a tela principal da aplicao capaz de processar mensagens NDEF

recebidas pelo sistema, desde que elas sejam mensagens do tipo MIME especificado
como application/org.nfc.mackenzie. Isto acontece por causa de um mecanismo do
sistema operacional, que mantm um servio monitorando a presena de dispositivos
NFC em tempo real. Este servio, ao receber mensagens NDEF do tipo especificado,
as despachar para a aplicao registrada com esta inteno. No caso de a aplicao
94
no estar em execuo, o sistema automaticamente se encarregar de inici-la para
despachar a mensagem.
Alm de receber mensagens NDEF, a aplicao tambm capaz de enviar uma
mensagem NDEF para outro dispositivo atravs de uma conexo estabelecida no
modo peer-to-peer pelo protocolo SNEP. Porm, o Android, utiliza o servio Android
Beam para realizar o envio e esta caracterstica limita a aplicao a enviar apenas uma
mensagem por vez. Alm disso, a comunicao NFC s ocorre se o dispositivo mvel
estiver com a tela destravada no momento de sua utilizao. Assim que o outro
dispositivo NFC detectado, o Android automaticamente exibe uma tela de
confirmao de envio para o usurio, conforme a figura a seguir:
Figura 21 - Tela gerada pelo Android para permitir o envio da mensagem NDEF
A partir deste momento a conexo peer-to-peer estabelecida e a mensagem

enviada quando o usurio tocar na tela. O envio ser cancelado se o usurio no tocar
na tela aps alguns segundos ou a qualquer momento mediante o afastamento do
95
dispositivo mvel do outro dispositivo NFC. Este recurso do Android limita a ubiquidade
da tecnologia NFC, que no mais to intuitiva quanto a utilizao de uma tag.
Alm de ser o ponto de partida para a comunicao NFC, a tela principal apresenta as
informaes da conta que est sendo utilizada para os pagamentos, como saldo,
identificao e histrico de utilizao. A tela est dividida em duas abas, que
possibilitam uma consulta rpida a estas informaes e podem ser alternadas por um
toque no ttulo da aba ou um gesto de deslizar os dedos horizontalmente na tela. As
duas abas da tela principal so demonstradas na figura a seguir:
Figura 22 - Abas da tela principal da aplicao
Na primeira vez em que a aplicao iniciada, automaticamente a tela para

configurao de conta de usurio exibida. Esta tela permite que o usurio digite o
nome de sua conta configurada previamente no site destinado ao cadastro. Ao tocar no
boto Adicionar, a aplicao redirecionaria o usurio para uma pgina responsvel
por autenticar o mesmo e fornecer um token de acesso para a aplicao, atravs do
protocolo de autenticaao OAuth, por exemplo. Para esta aplicao, a interao com o
site de autenticao foi omitida e um token fixo atribudo ao usurio automaticamente.
96
Figura 23 - Tela de configurao de conta de usurio
Aps a configurao da conta possvel utilizar a aplicao para pagamentos, desde

que haja saldo suficiente. Tambm possvel comprar novos crditos para a conta
atravs da tela de compra de crditos, que acessada atravs de um cone de
localizado na barra superior da tela principal. A compra de crditos, para os fins deste
trabalho, tambm foi simplificada e permite que crditos sejam adicionados de forma
irrestrita, sem qualquer validao do meio de pagamento. Entretanto, esta aplicao
considera que o site para cadastro tambm seja responsvel por gerenciar o mtodo
de pagamento associado a cada conta.
97
Figura 24 - Tela de compra de crditos
Tambm foi criada uma tela de configuraes para a aplicao, que possibilita a
configurao de opes relacionadas s contas e notificaes da aplicao. Atravs
desta tela possvel gerenciar as contas, escolher uma conta padro a ser utilizada
para pagamentos, habilitar a opo de troca automtica de contas e habilitar alertas
vibratrios no dispositivo. A aplicao permite que vrias contas sejam adicionadas
pois desta forma contempla cenrios onde existam mais de um provedor de servios de
pagamentos deste tipo, ou at mesmo diferentes tarifas de utilizao de transporte. J
a opo de troca automtica de contas, permite que a conta padro seja trocada
automaticamente assim que seja detectado o saldo do usurio insuficiente para
realizar pagamentos, desde que existam mais contas cadastradas. Neste caso, a conta
com maior saldo selecionada. Enquanto isso, o alerta vibratrio serve para avisar o
usurio de que o pagamento foi efetuado com sucesso.
98
Figura 25 - Tela de configurao da aplicao
Alm disso, tambm foi criada uma tela para visualizao do mapa da localizao atual
do dispositivo. Esta tela pode ser acessada atravs da barra superior da tela principal e
tem o intuito de auxiliar o usurio a identificar mais rapidamente sua localizao atual e
acompanhar seu percurso. Para o funcionamento desta tela, foi utilizado um tipo
especfico de atividade presenta na API Google Maps do SDK. Para utilizao desta
API, necessrio que as seguintes entradas sejam adicionadas no arquivo de
manifesto:
<uses-library
android:name="com.google.android.maps"
android:required="true">
</uses-library>
Esta tela utiliza, alm do GPS do dispositivo, o acesso internet. Isso acontece porque
os mapas fornecidos pelo Google esto disponveis apenas atravs da internet. Porm,
existem alternativas para esta soluo que incluem utilizao de cache de mapas e
utilizao de solues de mapas off-line de outras fontes para dispositivos com acesso
restrito Internet. Tambm possvel que as coordenadas da localizao atual sejam
99
recebidas atravs de um registro de geolocalizao dentro de uma mensagem NDEF
recebida de outro dispositivo. Esta alternativa interessante pois elimina o tempo de
estabelecimento de sinal GPS e possibilita a visualizao imediata do mapa da regio.
Neste caso, o dispositivo que enviar a mensagem para esta aplicao deve manter
conhecimento de sua localizao atual, e enviar as coordenadas como um registro
secundrio dentro da mensagem NDEF. Para esta aplicao, apenas a localizao
atual detectada pelo GPS do dispositivo utilizada. A figura a seguir mostra a tela de
localizao e o ponto azul marca a localizao atual do dispositivo:
Figura 26 - Tela gerada a partir dos dados fornecidos pelo GPS do dispositivo
4.2.2. A APLICAO DO LEITOR NFC

A aplicao desenvolvida para controlar o leitor NFC executada a partir de um
computador que possui o leitor conectado atravs de uma porta USB. Em um cenrio
real de utilizao, os equipamentos necessrios para execuo desta aplicao
estariam instalados em catracas dentro de nibus, trens ou outros meios de transporte.
O intuito desta aplicao possibilitar que outros dispositivos possam realizar
operaes de pagamento atravs da conectividade NFC oferecida pelo leitor. Possui a
responsabilidade de gerenciar a troca de mensagens entre o leitor e o dispositivo mvel
e de operar as tags NFC, j que nesta parte da arquitetura do sistema esto os
100
elementos mais flexveis com relao aos frameworks utilizados. Alm disso, como
esta parte se comunica diretamente com os servios relacionados ao pagamento,
mais seguro que no haja influncia externa que modifique seu comportamento. Para
que isto acontea, esta aplicao deve estar permanentemente conectada Internet.
Assim que um dispositivo aproximado do leitor NFC, a comunicao iniciada. O
primeiro passo executado por esta aplicao identificar o tipo de dispositivo que est
no campo eletromagntico de seu leitor. De acordo com o tipo de dispositivo, uma
estratgia de comunicao diferente adotada. Em ambos os casos as informaes do
usurio so recebidas e repassadas para o servio de pagamento, que responsvel
por validar essas informaes e efetivar o pagamento. A comunicao com estes dois
tipos de dispositivos s possvel quando a aplicao executada com o leitor NFC
ativado no modo iniciador.
No caso de um dispositivo mvel, uma conexo peer-to-peer estabelecida e so
trocadas mensagens NDEF atravs do protocolo SNEP da especificao NFC.
Primeiramente a aplicao envia uma mensagem NDEF do tipo AAR para o dispositivo
mvel. Este tipo de mensagem tem apenas a funcionalidade de abrir a aplicao
necessria para comunicao no dispositivo mvel. Caso a aplicao j esteja aberta,
a mensagem automaticamente descartada pelo Android. Se a aplicao ainda no
estiver instalada, o Android se encarrega de abrir a pgina para download da aplicao
dentro do seu respectivo mercado de aplicaes. Aps o envio desta mensagem, esta
aplicao reestabelece a conexo e espera por mensagens do dispositivo mvel. A
mensagem recebida pelo dispositivo mvel funcionar como uma solicitao de
pagamento por parte do usurio. A solicitao ser processada e uma resposta ser
enviada para o dispositivo mvel, para confirmar ou informar se aconteceu um erro
durante o processamento do pagamento.
Caso o dispositivo seja uma tag NFC, a comunicao ocorre atravs de operaes de
leitura e escrita. A aplicao se encarregar apenas de ler os dados do usurio
presentes no carto e processar o pagamento. Caso o pagamento seja efetivado, o
carto ter suas informaes de saldo atualizadas.
101
Tanto dispositivos mveis quanto tags carregam em sua memria informaes relativas
ao saldo, que servem apenas para consulta e so sincronizadas toda vez que o
dispositivo utilizado para pagamento. Os valores reais que so utilizados durante a
efetivao do pagamento so armazenados em um servidor externo a estas aplicaes
e consultados pelo servio de pagamento durante a transao, para garantir a
integridade dos dados e prevenir fraudes. O servio de pagamento tambm
responsvel por decidir o valor da tarifa que ser deduzida do saldo da conta do
usurio, tornando esta aplicao apenas uma intermediadora de pagamentos.
Esta aplicao no possui interface grfica e para monitorar seu funcionamento foi
utilizada a biblioteca log4j para gerao de logs. Como a biblioteca NFCTools j utiliza
essa ferramenta, tambm possvel monitorar os comandos APDUs e suas respostas
atravs do mesmo log. Portanto, o log gerado composto por chamadas da aplicao,
mensagens NDEF, mensagens de inicializao de protocolos e APDUs que esto
representados por cadeias de valores hexadecimais, como podemos visualizar na
figura a seguir:
Figura 27 - Log de estabelecimento de conexo SNEP para envio de mensagem NDEF
4.3. DESENVOLVIMENTO
O desenvolvimento do sistema foi feito com a utilizao linguagem Java em todos as
partes da sua arquitetura. Entretanto, como a comunicao NFC realizada atravs de
protocolos definidos em sua prpria especificao, possvel utilizar qualquer
102
linguagem nas partes envolvidas. Portanto, em termos de linguagem de programao
possvel ter uma arquitetura heterognea.
Primeiramente foi desenvolvida a troca de mensagens NDEF entre o leitor e o
dispositivo mvel. Apesar de a biblioteca NFCTools j possuir suporte operaes
deste tipo, alguns problemas foram encontrados dado que seu estado ainda
experimental. Entre estes problemas podemos citar o reconhecimento errneo do
dispositivo mvel, que possui o mesmo cdigo de identificao de uma tag, e que foi
corrigido atravs da desativao do suporte tags Sony FeliCa. Outro problema
encontrado foi a decodificao de mensagens NDEF do tipo MIME quando o leitor NFC
inicializado no modo alvo. Neste problema, a mensagem descartada e um novo
ciclo de comunicao iniciado. Este problema foi evitado com a utilizao do modo
iniciador, que funciona de maneira satisfatria, pois o modo iniciador o nico que
permite a comunicao com tags e dispositivos mveis se maneira alternada. No modo
alvo, apenas o tipo do primeiro dispositivo a iniciar uma comunicao suportado em
comunicaes posteriores.
A comunicao NFC com o dispositivo mvel tambm apresentou alguns problemas,
desta vez conceituais, durante sua utilizao e precisou ser contornada. O problema
acontece porque o Android realiza a comunicao peer-to-peer da tecnologia NFC
atravs do servio Android Beam. O Android Beam possibilita que apenas uma
mensagem seja enviada ao outro dispositivo em cada conexo estabelecida, desde
que o dispositivo mvel seja o primeiro a enviar uma mensagem. Isto acontece pois a
API do sistema proporciona apenas um callback para criao de uma mensagem
NDEF para uma atividade. Este callback acionado pelo sistema assim que uma
conexo NFC for estabelecida, e, portanto, este o nico momento em que a aplicao
do dispositivo mvel tem a oportunidade de enviar uma mensagem NDEF. Alm disso
se o dispositivo mvel receber uma mensagem NDEF primeiro, ele no ser capaz de
respond-la na mesma conexo, pois a atividade j foi iniciada e o momento de
chamada deste callback de criao de mensagem ignorado.
A inteno inicial do sistema era que a aplicao do leitor NFC enviasse uma
mensagem para iniciar a aplicao no dispositivo mvel, que por sua vez responde-se
103
com uma solicitao de pagamento e recebesse uma resposta do leitor. Porm, com as
limitaes do Android para comunicao NFC isto no possvel. A soluo
encontrada foi finalizar a conexo assim que a primeira mensagem enviada pelo
leitor. Desta forma, automaticamente uma nova conexo estabelecida, pois os
dispositivos permanecem no mesmo campo eletromagntico, e desta vez o dispositivo
mvel capaz de enviar a solicitao ao leitor e receber uma resposta. Esta
necessidade gerou mais alteraes na biblioteca NFCTools para criao de um
mecanismo de fechamento de conexo e s foi possvel pois a biblioteca possui cdigo
aberto. Se a comunicao fosse entre dois dispositivos mveis com sistema Android
esta alterao precisaria ser feita diretamente no cdigo fonte do sistema operacional.
Este problema tambm poderia ser contornado com a utilizao de mais de um gesto
de aproximao entre os dispositivos. Neste caso dois gestos seriam necessrios e
seria mais interessante eliminar a abertura automtica da aplicao e substitu-la por
uma ao do usurio diretamente no dispositivo. Em qualquer uma destas solues o
tempo para realizar um pagamento atravs da comunicao NFC acaba sendo maior
do que se o prprio sistema tivesse um suporte mais completo ao modo peer-to-peer
em sua API.
Com o ncleo desenvolvido, o resto do sistema foi construdo e envolveu a criao de
pacotes para abstrao da comunicao NFC na aplicao do leitor, pacotes para
facilitar a persistncia de dados no Android, interfaces grficas da plataforma Android,
um protocolo de comunicao para representao das operaes de pagamento e
outros elementos.
Os principais elementos desenvolvidos para este sistema esto representados no
diagrama de componentes a seguir:
104
Figura 28 - Diagrama de componentes do sistema
4.3.1. O PROTOCOLO DE COMUNICAO

Um protocolo de comunicao foi criado para troca de mensagens entre os dispositivos
NFC do sistema. Este protocolo, chamado de protocolo de pagamentos dentro do
escopo deste sistema, define alguns tipos de mensagens, mecanismos de codificao
e decodificao, alm de utilizao de algoritmos de criptografia. Esta biblioteca est
presente na aplicao do dispositivo mvel e na aplicao do leitor NFC.
O protocolo de pagamentos funciona em uma camada acima do protocolo NDEF na
pilha de protocolos e independente do processo de estabelecimento de conexo e do
105
protocolo de transmisso de mensagens. Para comunicao com tags, apenas o
protocolo NDEF utilizado. J para a comunicao com dispositivos mveis, o
protocolo LLCP utilizado para estabelecimento de conexo enquanto o protocolo
SNEP utilizado para transmisso de mensagens NDEF.
Para um modelo de
comunicao peer-to-peer, a seguinte pilha de protocolos utilizada:
Protocolo de Pagamentos
NDEF
SNEP
LLCP
Protocolo Digital
Analgico
Figura 29 - Pilha de protocolos para o modo peer-to-peer do sistema de pagamentos
Todos os dispositivos NFC envolvidos trocam mensagens NDEF do tipo MIME entre si,
que contm mensagens de pagamento armazenadas em formato binrio. Isto significa
que as mensagens do protocolo de pagamento so armazenadas no payload da
mensagem NDEF do tipo MIME. Como o protocolo NDEF um padro estabelecido
para troca de mensagens da tecnologia NFC, qualquer dispositivo com suporte NFC
ser capaz de receber a mensagem, porm s ser capaz de interpret-la caso possua
suporte a este protocolo de pagamentos.
Uma mensagem de pagamento composta por um ou mais registros de pagamento.
Cada registro de pagamento carrega, entre outras informaes, a identificao do
usurio que necessria para validao de um pagamento. O mecanismo para
codificao destas mensagens similar ao mecanismo j utilizado para codificao de
mensagens NDEF, onde todos os valores de tipos primitivos so convertidos para
vetores de bytes, que so organizados de maneira posicional em um nico vetor
resultante da codificao. Este vetor ento armazenado no payload da mensagem
NDEF, que transmitida ao seu destino. A mensagem de pagamento codificada
desta maneira para evitar que se atinja um tamanho em bytes muito grande, como
106
aconteceria em um processo de serializao binrio ou principalmente por uso de
XMLs. A comunicao NFC possui taxas de transferncia baixas e, portanto, quanto
menor o contedo trafegado, mais rapidamente acontecer a comunicao e mais
eficaz ela ser. Um modelo de mensagem solicitao de pagamento representado na
figura a seguir:
Payload
Verso
Tipo
1 byte
1 byte
Tamanho do
Tamanho do Tamanho
ID
Token
ID
Payload
do Token
4 bytes
4 bytes
4 bytes
Figura 30 - Formato de uma mensagem de pagamento
Saldo
8 bytes
Para manter informaes seguras durante a transmisso de dados as mensagens de

pagamento so criptografadas atravs do algoritmo AES. O processo de criptografia
acontece antes do armazenamento do vetor de bytes no payload da mensagem NDEF
do tipo MIME, e consiste em criptografar os valores presentes no payload da
mensagem do protocolo de pagamentos. A escolha do algoritmo de criptografia se
deve ao suporte nativo oferecido pelo SDK do Android e tambm pelo SDK do Java.
Esta criptografia utilizada pois a biblioteca NFCTools e o SDK do Android no
possuem suporte ao protocolo NFC-SEC, que prov criptografia automtica nos canais
de transmisso. Caso a criptografia no seja utilizada, as informaes de identificao
do usurio podem ser interceptadas no campo eletromagntico e facilmente
identificadas. Porm, a mensagem criptografada tem um tamanho maior que a
mensagem original, o que configura outro motivo pelo qual a mensagem deve ter a
menor quantidade de informaes possveis.
Para a implementao da criptografia, a codificao Base64 foi utilizada em seu
processo. Porm, a implementao desta codificao no sistema Android difere da
implementao padro do Java e para solucionar este problema, a implementao do
Android foi obtida no cdigo fonte do Android e embutida no pacote do protocolo.
No protocolo de pagamento, trs tipos de mensagens so definidas para troca de
informaes entre os diferentes dispositivos envolvidos no processo. Estas mensagens
so:
107
Mensagem de requisio: a mensagem enviada pelo dispositivo mvel ao

leitor NFC, que contm as informaes do usurio necessrias para solicitao
do pagamento. Esta mensagem carrega um cdigo de identificao opcional, o
token de acesso conta do usurio e o saldo atual presente no dispositivo
mvel;
Mensagem de resposta: a mensagem enviada pelo leitor NFC ao dispositivo

mvel como resposta ao que lhe foi solicitado, contendo informaes sobre o
resultado do processamento. Esta mensagem carrega um cdigo de
identificao opcional, o token de acesso conta do usurio, uma mensagem de
descrio da operao, o balano atual da conta do usurio fornecido pelo
servidor de pagamentos, o valor debitado da conta do usurio e um cdigo de
status da operao;
Mensagem de bilhete: a mensagem armazenada dentro de um bilhete,

contendo informaes do usurio. Esta mensagem carrega um cdigo de
identificao opcional, o token de acesso conta do usurio e o saldo atual
presente no bilhete;
Aps a codificao das mensagens NDEF do tipo MIME que armazenam as

mensagens de pagamento, o tamanho em bytes deve ser pequeno o suficiente para
ser transmitido rapidamente pelo campo eletromagntico e tambm para ser
armazenado em um tag, caso seja necessrio. No caso de mensagens sem utilizao
de criptografia como mecanismo de segurana, as mensagens de requisio e de
bilhete possuem aproximadamente 67 bytes, enquanto a mensagem de resposta
possui 69 bytes. Quando a criptografia habilita, o tamanho das mensagens de
requisio e de bilhete passa para 111 bytes, enquanto o tamanho da mensagem de
resposta passa para 155. um aumento significativo e pode inviabilizar o uso de
algumas tags com baixa capacidade de armazenamento j que o tamanho pode variar
de acordo com a utilizao do token ou do campo de identificao opcional. Nestes
exemplos, o token de acesso utilizado possui apenas 5 bytes.
108
4.3.2. APRESENTAO DOS PACOTES
Os pacotes desenvolvidos para este sistema esto organizados em trs bibliotecas
distintas: uma para a aplicao do dispositivo mvel, uma para a aplicao do servidor
e outra para o protocolo de pagamento, que utilizada pelas duas aplicaes.
4.3.2.1.
PACOTE ORG.MACKENZIE.PROTOCOL
O pacote org.mackenzie.protocol contm as classes que representam as mensagens

de pagamento, alm das classes responsveis pela codificao e decodificao das
mesmas.
Figura 31 - Diagrama de classes do pacote org.mackenzie.protocol
Assim como nas mensagens NDEF, as mensagens de pagamentos contm um ou

mais registros internamente. Esta caracterstica torna as mensagens de pagamento
flexveis e possibilita que diversos registros de pagamento sejam transmitidos em uma
109
nica mensagem. Internamente, os registros e as mensagens de pagamento so
representados pelas classes PaymentMessage e PaymentRecord. Estas classes so
utilizadas para mapear a estrutura de bytes em que a mensagem codificada e
decodificada e possuem classes respectivas para estas tarefas: no caso da mensagem
so as classes PaymentMessageEncoder e PaymentMessageDecoder, enquanto no
caso do registro so as classes PaymentRecordEncoder e PaymentRecordDecoder.
A classe utilizada para representar o registro de pagamento agnstica operao de
pagamento que realizada e contm apenas um payload que representa esta
informao. Para representar a informao da operao, foi criada a classe abstrata
Record, interfaces e outras classes abstratas que definem como deve ser o
comportamento da codificao e decodificao dos registros. Esta estrutura est no
pacote org.mackenzie.protocol.message.
So definidas as interfaces RecordEncoder e RecordDecoder para codificao e
decodificao dos registros e tambm uma implementao bsica destas interfaces
atravs
das
classes
AbstractRecordEncoder
AbstractRecordDecoder.
Estas
implementaes possuem suporte criptografia do payload do registro atravs das da

implementao das interfaces RecordPayloadEncoder e RecordPayloadDecoder, que
fazem com que o payload seja sempre tratado pelos mtodos destas interfaces. No
caso desta biblioteca, apenas um tipo de criptografia est implementado atravs das
classes CryptoRecordPayloadDecoder e CryptoRecordPayloadEncoder que fazem uso
do pacote de criptografia para tratar os dados do payload.
Os
tipos
de
registro
utilizados
ResponsePaymentRecord,
pelo
protocolo
so
RequestPaymentRecord,
TicketPaymentRecord e UnknownPaymentRecord. Cada
um contm suas respectivas informaes e tem seu prprio significado dentro do

protocolo de pagamentos. A classe RequestPaymentRecord representa uma
mensagem de requisio, a classe ResponsePaymentRecord representa uma
mensagem de resposta e a classe TicketPaymentRecord representa uma mensagem
de bilhete . O tipo UnknownPaymentRecord utilizado apenas quando uma mensagem
no tem seu registros decodificados com sucesso. Alm disso, estes registros possuem
110
suas respectivas classes para codificao e decodificao de suas informaes, que
em geral estendem AbstractRecordEncoder e AbstractRecordDecoder.
Como a classe PaymentRecordEncoder tem a responsabilidade transformar o
contedo do registro em um vetor de bytes e ao mesmo tempo agnstica este
contedo, foi utilizado um mecanismo onde a primeira classe capaz de processar a
informao da mensagem utilizada. possvel identificar o tipo de mensagem para
tomar esta deciso atravs do campo que define o tipo da mensagem e no
criptografado. Portanto, esta classe conhece todas as implementaes possveis para
codificao de registro e atravs do mtodo canDecode() destas classes, verifica se
responsabilidade da mesma realizar esta tarefa. O mesmo processo vlido para
decodificao de registros.
4.3.2.2.
PACOTE ORG.MACKENZIE.CRYPTO
O pacote org.mackenzie.crypto contm as classes relativas ao processo de criptografia

adotado pelo protocolo de pagamentos. A classe CryptoProvider encapsula o acesso
s classes nativas do sistema para criptografia. Como o SDK do Android implementa a
Java Cryptography Extension (JCE), todos os dispositivos mveis com Android
suportam algoritmos de criptografia como o AES. Segundo (ELENKOV, 2012), o
algoritmo AES o nico algoritmo de criptografia simtrica que suportado por todos
os dispositivos Android, e por isso este foi o algoritmo adotado para o protocolo de
pagamentos. A classe EncryptorFactory, por sua vez, responsvel pela criao de
objetos do tipo Encryptor. Atravs de seu uso, possvel diversificar a estratgia de
criptografia utilizada.
111
Figura 32 - Diagrama de clases do pacote org.mackenzie.crypto
A estratgia padro de criptografia do protocolo a implementao PaddingEncryptor,

que utiliza o mtodo de padding de chaves de criptografia descrito em (ELENKOV,
2012) para atingir o tamanho mnimo da chave utilizada pelo AES, que neste caso de
256 bits. Tambm possvel codificar mensagens sem a utilizao de criptografia
atravs da classe NoEncyptor, que apenas repassa o contedo do payload sem
realizar nem tratamento.
O Android no fornece um mecanismo integrado para armazenamento das chaves de
criptografia utilizadas pela aplicao, o que enfraquece o poder de segurana da
aplicao nesta plataforma, porm mantm a segurana dos dados transmitidos pelo
campo eletromagntico do NFC. Esta segurana relativa somente a ataques atravs
de interceptao de mensagens no campo eletromagntico, pois a prpria biblioteca
armazena a chave de criptografia na memria do dispositivo. O estudo de (ELENKOV,
2012) aponta que as melhores maneiras para maximizar a segurana do sistema
seriam o armazenamento das chaves pelo prprio sistema operacional ou a utilizao
de uma senha digitada pelo usurio como chave de criptografia toda vez que a
aplicao utilizada. A soluo atravs de senha digitada pelo usurio no foi utilizada
112
por interferir na funcionalidade da aplicao, pois adicionaria mais uma etapa para a
realizao do pagamento e a proposta desta aplicao ser minimalista o suficiente
para atingir a computao ubqua, intimamente relacionada com NFC.
4.3.2.3.
PACOTE ORG.NFC.MACKENZIE.CONTEXT
O pacote org.nfc.mackenzie.context est presente apenas na aplicao do leitor e tem

o papel de abstrair a complexidade da utilizao do leitor NFC para outras camadas da
aplicao. Sua estrutura de classes segue a API fornecida pela biblioteca NFCTools
para controle do leitor e suas funcionalidades. A classe NfcGateway centraliza o
acesso esta API e tem a responsabilidade de configurar os parmetros de utilizao
da mesma.
Figura 33 - Diagrama de classes do pacote org.nfc.mackenzie.context
113
O protocolo SNEP foi utilizado para comunicao peer-to-peer e a biblioteca NFCTools
prov classes para criao de um servio e um cliente SNEP, como definidos na
especificao. Neste pacote, essas classes foram estendidas para customizao do
tratamento de alguns eventos da comunicao NFC. Para isto, as classes
NfcSnepServer e NfcSnepClient foram criadas. A classe NfcSnepServer estabelece um
mecanismo para monitoramento de mensagens atravs da interface MessageListener
enquanto a classe NfcSnepClient estabelece um mecanismo semelhante para o
monitoramento
de
conexes
com
outros
dispositivos
atravs
da
interface
DeviceListener.
A classe NfcSnepServer utiliza a classe NfcSneplet para recepcionar mensagens, de
acordo com a interface Sneplet definida pela biblioteca NFCTools. Enquanto isso, a
classe NfcSnepClient utiliza a classe NfcAgent para enviar mensagens, de acordo com
a interface SnepAgentListener da biblioteca. A classe NfcAgent bastante importante
na comunicao, pois interfere diretamente no ciclo de vida da conexo SNEP. Assim
que todas as mensagens so enviadas, a biblioteca NFCTools se encarrega de fechar
a conexo do cliente e descartar a instncia de NfcAgent, mas mantm a conexo
LLCP aberta. Toda vez que novas mensagens forem enviadas pela aplicao, uma
nova instncia de NfcAgent ser criada para esta tarefa.
A classe NfcGateway, por sua vez, utiliza as classes designadas para servio e cliente
SNEP, e tambm as classes nativas da biblioteca NFCTools para manipulao de tags.
Esta classe tambm expe para outras camadas um mecanismo de monitoramento
atravs da interface ConnectionListener, que permite que as decises relativas s
regras de negcio sejam definidas em camadas superiores.
4.3.2.4.
PACOTE ORG.NFC.MACKENZIE.BACKEND
A classe MackenzieContext utiliza o mecanismo de monitoramento estabelecido pela

classe NfcGateway e organiza as regras de negcio relativas comunicao atravs
de um mecanismo de estados. Essa comunicao, do ponto de vista das regras de
negcio, tem sempre um estado que a rege e deve estender a classe
CommunicationState. De acordo com as informaes de conexo e mensageria
fornecidas pela classe NfcGateway, o estado definido e as regras so estabelecidas.
114
Figura 34 - Diagrama de classes do pacote org.nfc.mackenzie.backend
As
classes
DeviceCommunicationState,
TicketCommunicationState
IdleCommunicationState definem respectivamente, as regras de comunicao com

dispositivos mveis, com tags e quando a comunicao est inativa, que acontece
quando no h dispositivos no alcance do campo eletromagntico. Essas classes que
representam os estados da comunicao tambm so responsveis pelo envio e
recepo
de
mensagens
de
pagamento
com
auxlio
da
classe
PaymentMessageHelper, que utiliza os codificadores e decodificadores da biblioteca

relativa ao protocolo de pagamentos.
A recepo destas mensagens desencadeia operaes do servio de pagamentos,
representado pela interface PaymentService, e as respostas deste servio resultam em
um retorno ao dispositivo que originou a comunicao. Uma implementao padro
desta interface definida pela classe PaymentServiceStub, que basicamente consiste
em debitar um valor fixo do saldo do usurio durante a operao de pagamento.
115
4.3.2.5.
PACOTE ORG.NFC.MACKENZIE
O pacote org.nfc.mackenzie est presente na aplicao do dispositivo mvel e contm

todas as classes referentes persistncia de dados, regras de negcio, camada de
apresentao e controle do hardware NFC e outros perifricos. Esta aplicao est
organizada em uma arquitetura de trs camadas.
Na camada de acesso aos dados, foi desenvolvido um pequeno framework Objectrelational Mapping (ORM) baseado na classe SQLiteOpenHelper fornecida pelo SDK
do Android. Esta classe utilizada para criao, alterao e comunicao com o banco
de
dados
SQLite
da
aplicao.
extenso
desta
classe,
denominada
SQLiteOpenHelperImpl, utiliza as classes EntityDecoder e EntityEncoder para

mapeamento de tabelas do banco de dados para classes de entidade e vice-versa.
Esse processo de converso feito com base em herana de classes e anotaes de
propriedades que representam as entidades do negcio. As classes AbstractEntity e
AbstractCompositeEntity so estendidas para representar tabelas com chave primria e
tabelas que possuam chave estrangeira com relacionamentos 1-n. A anotao Column
utilizada para representar as colunas da tabela e a anotao Relationship para
representar a chave estrangeira. Este framework atende apenas e necessidades da
aplicao e no cobre todos os recursos do banco de dados SQLite presente no
Android.
116
Figura 35 - Diagrama de classes da camada de acesso aos dados
Ainda na camada de acesso aos dados esto as entidades mapeadas e as classes

utilitrias para manipulao dessas entidades no banco de dados. As entidades
mapeadas esto representadas pelas classes Account, EntryHistory e Entry e
representam respectivamente a conta do usurio, o histrico do usurio e uma entrada
de um histrico. Essas entidades so manipuladas pelas classes utilitrias
AccountHelper e EntryHistoryHelper e fornecem mtodos de consulta, insero,
alterao e excluso das mesmas.
Na camada de regras de negcio, esto as classes que fornecem as principais
funcionalidades da aplicao. A classe ServiceSettings, por exemplo, responsvel por
gerenciar o acesso e a alterao dos parmetros de configurao da aplicao. O
diagrama destas classes est representado na figura a seguir:
117
Figura 36 - Diagrama de classes da camada de regras de negcio
A classe AccountManager responsvel por abstrair a camada de acesso aos dados

referentes conta de usurio. A classe AccountProxy, por sua vez, realiza algumas
consultas da classe AccountManager, porm fornece os resultados para camadas
superiores atravs da classe AccountBO, ao invs da classe Account. A classe
AccountBO contm um pouco de lgica de negcio para utilizao em telas,
118
principalmente relacionadas formatao de valores monetrios, atravs da classe
BalanceFormatter.
A classe TransactionController tem papel crucial na arquitetura desta aplicao e rene
todas as funcionalidades relativas ao pagamento e gesto de contas de usurio. Esta
classe responsvel por gerar mensagens de solicitao de pagamento e por
processar respostas destas mensagens, de acordo com a especificao do protocolo
de pagamento deste sistema. A classe utiliza o padro singleton para garantir apenas
uma instncia de si mesma, j que apenas uma operao de pagamento pode ocorrer
por vez.
Alm disso, a classe TransactionController utiliza o servio de contas de usurio,
representado pela interface AccountService, para funcionalidades como configurao
de conta de usurio e compra de crditos, que demandam informaes de servidores
externos. Para esta aplicao, uma implementao padro deste servio est presente
na classe AccountServiceStub e consiste em aceitar quaisquer alteraes na conta.
Na camada de apresentao esto as classes responsveis pelo controle das
interaes com o usurio que acontecem atravs de toques na tela ou de conectividade
NFC. Estas classes tambm so responsveis pela configurao e exibio dos
elementos visuais da aplicao, como layouts XML, cones e listas.
Figura 37 - Diagrama de classes da camada de apresentao
119
Nesta camada esto definidos alguns tipos bsicos de elementos visuais, como a
classe BaseActivity que estabelece uma base para criao de atividades com suporte a
fragmentos, a classe BaseSectionFragment que oferece suporte aos fragmentos destas
atividades e a classe NfcAtivity que oferece suporte comunicao NFC em uma
atividade. A partir destas classes bsicas esto definidas todas as outras atividades do
sistema.
Algumas telas que exibem listagens, como a atividade de gerenciamento de contas de
usurio e at mesmo o fragmento que exibe o histrico de utilizao da conta, utilizam
extenses da classe ArrayAdapter<T> do Android para a customizao do layout de
cada item da lista. Estas classes so responsveis por configurar o layout e apresentar
as informaes de um determinado item da lista.
Dentre todas as telas desta aplicao, a mais importante a tela inicial, definida pela
classe MainAcitivity, que estende NfcActivity. A classe NfcActivity possui dois mtodos
abstratos chamados sendMessageCallback e receiveMessageCallback que so
chamados toda vez que uma mensagem NDEF precisa ser enviada ou que uma
mensagem NDEF recebida. Esta tela implementa estes mtodos e adiciona suporte
comunicao NFC, utilizando a classe TransactionController para criao das
mensagens de pagamento a serem enviadas e interpretao das respostas recebidas.
A classe NfcManager utilizada pela NfcActivity para a deteco de hardware NFC no
dispositivo mesmo em verses do Android que no possuam suporte tecnologia e
configurao de sua utilizao caso a tecnologia esteja presente. Alm de detectar o
hardware NFC a classe NfcManager tambm detecta se o mesmo est habilitado antes
de configurar a utilizao do NFC na aplicao.
120
5.
CONCLUSO E TRABALHOS FUTUROS
Neste trabalho foi possvel desenvolver a arquitetura proposta para soluo do

problema. possvel que um dispositivo mvel com Android seja utilizado para efetuar
pagamentos relativos s tarifas de meios de transporte atravs da tecnologia NFC e o
seu uso para este tipo de pagamento pode simplificar o cotidiano do usurio. O usurio
no precisaria mais carregar consigo um smartcard que s tem a funcionalidade de
pagamento destas tarifas, poderia recarregar o saldo de sua conta, desde que possua
acesso internet, e ainda poderia se localizar rapidamente atravs da utilizao de
mapas do prprio dispositivo. Desta maneira, diversos elementos que so utilizados
separadamente pelo usurio podem convergir em uma aplicao para seu dispositivo
mvel. Alm disso, usurios que no possussem dispositivos mveis com NFC no
seriam afetados, j que smartcards ainda seriam aceitos devido retro compatibilidade
da tecnologia.
O desenvolvimento deste sistema, porm, se d com ressalvas por causa do fraco
suporte ao desenvolvimento de aplicaes NFC para dispositivos mveis com a
plataforma Android e principalmente para leitores NFC. No caso de ambos dispositivos
houve dificuldades para estabelecer uma comunicao NFC e efetuar a troca de
mensagens. E essas dificuldades foram bastante limitadoras, no s para o
desenvolvimento como tambm para a usabilidade da aplicao.
O Android, apesar de possuir uma API especfica para NFC, no possui suporte
utilizao do SE do hardware NFC presente no dispositivo mvel e no implementa
protocolos de segurana, como o NFC-SEC. Alm disso, limita o suporte troca de
mensagens no modo peer-to-peer. Neste modo o Android permite que apenas uma
mensagem seja enviada por conexo estabelecida, alm de outras limitaes. No
possvel saber o motivo pelo qual o uso do NFC tratado desta maneira na plataforma,
pois de acordo com a especificao NFC a mensageria deve ser bidirecional.
Entretanto, o suporte a NFC na plataforma Android est em constante evoluo.
Recentemente foi adicionado o suporte ao protocolo SNEP como opo ao protocolo
NPP, criado pelo Google e que ainda no foi adotado como padro pelo NFC Forum.
121
A aplicao que controla o leitor NFC tambm bastante prejudicada pela falta de um
SDK de alto nvel com abstrao de todos os comandos do leitor. Alm disso, no
fornecida uma implementao de protocolos relativos especificao NFC e que sem
eles, no possvel realizar uma comunicao peer-to-peer. Para resolver este
problema, a biblioteca NFCTools foi utilizada, mas uma biblioteca que ainda no
estvel o suficiente para utilizao em cenrios reais. At mesmo em cenrios de teste
deste sistema a biblioteca apresentou pequenas falhas, como a perda de conexo com
o dispositivo. Isto no impossibilitou o sucesso da aplicao, j que a biblioteca foi
capaz de se recuperar de estados de erro automaticamente. Para identificar se estas
falhas so provenientes de problemas na biblioteca ou no prprio firmware do leitor
uma anlise bastante detalhada necessria.
A utilizao do dispositivo mvel tambm bastante afetada pelo servio Android
Beam do sistema, que exige o desbloqueio da tela do dispositivo mvel e um toque na
tela para transmisso da mensagem. Este problema pode ser resolvido atravs da
alterao e substituio do servio que monitora o estado do hardware NFC, j que o
Android possui cdigo aberto. Esta alterao, no entanto, mais vivel em laboratrio
do que em um cenrio real de utilizao, pois exige acesso total ao dispositivo, ou seja,
acesso root ao kernel do sistema.
A tecnologia NFC abre um leque de possibilidades muito grande de aplicaes,
principalmente pela influncia da computao ubqua. Apesar do interesse em
pagamentos e segurana, com a tecnologia NFC tambm possvel desenvolver jogos
e outras aplicaes. A tecnologia NFC tambm serve como complemento para diversas
operaes de aplicaes j existentes, como troca de contatos e fotos, por exemplo.
Alm disso, h um bom espao para desenvolvimento de bibliotecas de cdigo aberto
para suporte ao leitor NFC devido escassez de opes. Existem diversas empresas
com solues comerciais baseadas em NFC e pouqussimas disponibilizam suas
bibliotecas, tanto como cdigo aberto ou fechado. Uma possibilidade interessante para
continuidade deste trabalho a utilizao do SE presente no dispositivo mvel para
aumentar a segurana em pagamentos.
122
6.
REFERNCIAS BIBLIOGRFICAS
ACTIVITY:
Android
Activity
API.
2012.
Disponvel
em:
<http://developer.android.com/reference/android/app/Activity.html>. Acesso em: 20 set.
2012.
BARBOSA, Jorge Luis Victria; DA COSTA, Cristiano Andr; ROEHRS, Alex. Uma
Proposta de Modelo de Pagamento Mvel para o Comrcio Ubquo. Simpsio Brasileiro
de Computao Ubqua e Pervasiva, Natal, RN, jul. 2011.
BREITFU, Klemens; HASELSTEINER, Ernst. Security in Near Field Communication:
Strengths and Weaknesses. Gratkorn, ustria: [s.n.], [2006?].
BURNETTE, Ed. Hello, Android: Introducing Googles Mobile Development Platform. 2.
ed. The Pragmatic Programmers, 2009.
COSKUN, Vedat; OK, Kerem; OZDENIZCI, Busra. Near Field Communication: From
Theory to Practice. 1. ed. Wiley, 2012.
ECMA-340: Near Field Communication - Interface and Protocol (NFCIP-1). Geneva,
Sua, 2. ed., 2004.
ECMA-352: Near Field Communication - Interface and Protocol 2 (NFCIP-2). Geneva,
Sua, 2. ed., 2010.
ELENKOV, Nikolay. Using Password-based Encryption on Android: Why passwordbased
encryption
is
needed.
2012.
Disponvel
em:
<http://nelenkov.blogspot.com.br/2012/04/using-password-based-encryption-on.html>.
Acesso em: 1 out. 2012.
GRUNTZ, Dominik. Near Field Communication with Android. International Conference
on the Modern Art of Software, Zurich, Suca, jun. 2011.
HACKETT, Conor. MobiCash: A System for Cashless Payments using Near Field
Communication Enabled Smartphones. Trabalho de Concluso de Curso (Graduao
em Cincia da Computao) - Griffith College Dublin, Dublin, Irlanda, 2012.
ISO/IEC 18092: Near Field Communication - Interface and Protocol (NFCIP-1). 1. ed.,
2004.
ISO/IEC 14443-4: Identification cards - Contactless integrated circuit cards - Proximity
cards - Part 4: Transmission protocol. 2000.
JSR268: Java Smart Card I/O API. Java Community Process , 2006. Disponvel em:
<http://jcp.org/en/jsr/detail?id=268>. Acesso em: 20 ago. 2012.
123
KORTVEDT, Henning Siitonen. Securing Near Field Communication. 2009. Dissertao
(Mestrado em Tecnologia da Comunicao) - Norwegian University of Science and
Technology, Trondheim, Noruega, 2009.
LEE, Wei-Meng. Beginning Android Application Development. Wrox Programmer to
Programmer, 2011.
LIBNFC: Public platform independent Near Field Communication library. Disponvel em:
<http://www.libnfc.org/documentation/introduction>. Acesso em: 10 set. 2012.
LLCP: Logical Link Control Protocol Technical Specification. NFC Forum, v. 1.1., 2011.
LOTITO, Antonio. ISMB-SNEP: open-source library to enable P2P over NFC. The 5th
NFC Congress, Hagenberg, Austria, set. 2012.
LOTITO, Antonio, Mazzocchi, D. OPEN-NPP: An Open Source Library to Enable P2P
over NFC. 4th International Workshop on IEEE Near Field Communication, p. 57-62,
mar. 2012.
LYYTINEN, Kalle; ONDRUS, Jan. Mobile Payments Market: Towards Another Clash of
the Titans? In: International Conference on Mobile Business, 10., 2011, Como. Trabalho
apresentado durante o evento. Itlia, 2011.
MEDNIEKS, Zigurd et al. Programming Android. 2. ed. OReilly, 2012.
MEIER, Reto. Professional Android Application Development. Wrox Programmer to
Programmer, 2011.
NDEF: NFC Data Exchange Format Technical Specification. NFC Forum, v. 1., 2006.
NFCAPI: Android Near Field Communication API. 2012. Disponvel em:
<http://developer.android.com/guide/topics/nfc/index.html>. Acesso em: 26 mai. 2012.
NFCTOOLS.
NFC
Developers
Group.
2012.
Disponvel
em:
<https://groups.google.com/forum/?fromgroups#!forum/nfc-developers>. Acesso em: 30
mai. 2012.
NPP: Android NDEF Push Protocol Specification. Google, v. 1., 2011.
OHA: Open Handset Alliance. Disponvel em: <http://www.openhandsetalliance.com>.
Acesso em: 19 set. 2012.
OPENNFC: The Open NFC Developer Site. Disponvel em: <http://open-nfc.org>.
Acesso em: 10 set. 2012.
124
ORTIZ, Enrique. An Introduction to Java Card Technology. Oracle, 2003. Disponvel
em:
<http://www.oracle.com/technetwork/java/javacard/javacard1-139251.html>.
Acesso em: 10 out. 2012.
RTD: NFC Record Type Definition Protocol Technical Specification. NFC Forum, v. 1.,
2006.
SNEP: Simple NDEF Exchange Protocol Technical Specification. NFC Forum, v. 1.,
2011.
BIBLIOGRAFIA COMPLEMENTAR
AQUINO, Juliana Frana Santos. Plataformas de Desenvolvimento para Dispositivos
Mveis. 2007. Trabalho de Concluso de Curso (Ps Graduao em Informtica) Pontifcia Universidade Catlica do Rio de Janeiro, RJ, 2007.
ATOJI, Rodolpho Iemini. Bluetooth e NFC: estudo de caso. 2010. Trabalho de
Concluso de Curso - Universidade de So Paulo, So Paulo, 2010.
cards - Part 1: Physical characteristics. 1997.
cards - Part 2: Radio frequency power and signal interface. 1999.
cards - Part 3: Initialization and anti-collision. 1999.
KUMAR, Anurag. Near Field Communication. 2010. Trabalho de Concluso de Curso
(Graduao em Cincia da Computao e Engenharia) - Cochin University of Science
& Technology, Kochi, ndia, 2010.
ROVIO: Rovio Entertainment Ltd. Disponvel em: <http://www.rovio.com>. Acesso em:
10 mai. 2012.
125
Apndice A Computao Ubqua

Para entender melhor a tecnologia NFC necessrio conhecer o conceito de
computao ubqua. com base neste conceito que o NFC foi concebido e que, ao
mesmo tempo, considerado uma das formas de se aplicar a computao ubqua. Em
resumo, computao ubqua representa uma nova forma de interao entre pessoas e
computadores, onde os dispositivos computacionais esto completamente integrados
com os objetos disponveis ao redor da pessoa no dia-a-dia.
Este conceito foi sendo desenvolvido ao longo do tempo, na medida em que novas
tecnologias foram surgindo. Assim como nos computadores modernos, clculos
automatizados e programticos fazem parte da essncia da computao ubqua. A
histria da computao moderna teve incio h mais de um sculo atrs, desde as
primeiras invenes, como mquinas mecnicas programveis, passando pela
mquina de Turing, at chegar aos primeiros computadores baseados em eletricidade
na metade do sculo XX (COSKUN, 2012).
Em seguida outro importante passo foi dado com a criao dos computadores de uso
pessoal, mudando a maneira como o usurio interage com a mquina, estabelecendo o
uso de teclados e mouses como mecanismos de entrada. Os mouses foram capazes
de transmitir para a tela do computador o movimento que era realizado pelo usurio,
criando um novo tipo de interao entre usurio e computador.
Outro importante passo foi dado com a inveno das telas touch screen, que
posteriormente seriam o principal mecanismo de interao com dispositivos mveis.
Inicialmente os dispositivos mveis utilizavam apenas teclas fsicas para os nmeros e
outras funes principais. Em seguida, surgiram os dispositivos com teclados mais
parecidos com os de computadores pessoais e enfim os dispositivos com entrada
atravs da tecnologia touch screen. A criao desta tecnologia diminuiu o interesse dos
usurios pelos mtodos de entrada anteriores j que as mos poderiam ser
movimentadas na superfcie da tela para controlar o dispositivo, possibilitando que a
tela fosse utilizada para entrada e para sada de dados (COSKUN, 2012).
Desta forma, computao ubqua pode ser caracterizada como um modelo onde as
pessoas no exercem suas atividades do dia-a-dia de acordo com os dispositivos que
126
elas utilizem, mas sim o contrrio: os dispositivos que mudam suas formas de
operao para se ajustarem s necessidades das pessoas. O objetivo principal de
que as pessoas no precisem mudar seus hbitos para que possam usar dispositivos
computacionais, mas sim que estes se adaptem s necessidades das pessoas.
Neste cenrio, a tecnologia NFC se encaixa perfeitamente como um elemento que
coloca em prtica o conceito de computao ubqua. Um bom exemplo o ato de
realizar um pagamento com um dispositivo mvel NFC atravs de um simples gesto de
aproximar o celular de um dispositivo leitor. Estudos recentes, como o (BARBOSA,
2011), j tratam de assuntos derivados da computao ubqua, como o caso do ucommerce, que um comrcio eletrnico baseado em computao ubqua.
127
Apndice B Transmisso de dados

O modo de operao leitura/escrita permite uma taxa de transferncia de apenas 106
kbit/s e depende de uma interface RF que compatvel com o ISO/IEC 14443 (Tipo A e
B) e Sony FeliCa. No modo peer-to-peer, a interface RF permite taxas de 106, 212 e
424 kbit/s e baseada no ISO/IEC 18092 (NFCIP-1). No modo de emulao de carto,
a interface RF baseada no ISO/IEC 14443 (Tipo A e B) e Sony FeliCa. Para entender
melhor como essa comunicao estre todos estes dispositivos acontece, ou seja, como
a parte lgica do NFC convertida para a fsica, e vice-versa, necessrio entender os
conceitos de modulao e codificao aplicados na tecnologia NFC.
Para modulao, assim como nos padres RFID, o NFC usa acoplamento indutivo. Os
esquemas de modulao usados por NFC so Amplitude Shift Keying (ASK) com
diferentes profundidades de modulao e modulao por carga.
No caso de uma transmisso de dados do iniciador para o alvo, como um dispositivo
mvel em modo de emulao de carto, o dispositivo alvo usa um sinal portador de
13.56 MHz do iniciador como fonte de energia. O esquema de modulao do
dispositivo iniciador o ASK. No modo peer-to-peer, os dois lados so modulados e
codificados como se fossem dispositivos iniciadores. Entretanto, menos energia
requerida, pois cada dispositivo gera seu prprio campo eletromagntico e o sinal
portador desligado no final da transmisso.
No caso de uma transmisso do alvo para o iniciador, o alvo passivo pode interferir no
iniciador ativo por causa do acoplamento das bobinas das antenas. Uma variao na
impedncia do alvo causa mudanas de fase ou amplitude na voltagem da antena do
dispositivo iniciador, que capaz de detectar estas alteraes. Esta tcnica chamada
de modulao de carga e consiste em manter uma portadora auxiliar a 848 kHz, que
modulada pela banda base e varia a impedncia do dispositivo alvo (COSKUN, 2012).
Com relao codificao, o NFC emprega trs diferentes tcnicas para transmisso
de dados: NRZ-L, Manchester e Modified Miller.
128
Figura: Diferena de codificao em diferentes tcnicas
NRZ-L: nesta codificao, um pulso alto durante a durao de um bit representa

o bit 1, enquanto um pulso baixo representa o bit 0;
Manchester: se a primeira metade da durao de um bit um pulso alto e a

segunda metade um pulso baixo, representa o bit 1. Caso contrrio, se a
primeira metade um pulso baixo e a segunda metade um pulso alto,
representa o bit 0;
Modified Miller: representa o bit 1 quando comea com um pulso alto e um pulso
baixo ocorre logo aps a metade da durao de um bit. Representa o bit 0
quando um pulso baixo ocorre no comeo da durao de um bit. E se bit 0 vem
depois do bit 1, nenhum pulso ocorre no bit 0, portanto o sinal permanece alto.
Nos esquemas de codificao Manchester e Modifed Miller, um nico bit enviado em

uma fatia de tempo determinada. Esta fatia de tempo dividida em duas partes,
chamadas de meio-bit.
129
Na codificao Miller, o bit 0 codificado com pausa no primeiro meio-bit e sem pausa
no segundo meio-bit enquanto o bit 1 codificado sem pausa no primeiro meio-bit e
com pausa no segundo meio-bit. O Modified Miller aperfeioou esta codificao criando
algumas regras adicionais para a codificao dos zeros. No Miller, se o bit 1 fosse
seguido de um bit 0, os dois meio-bits subsequentes teriam uma pausa. O Modified
Miller evita isso codificando esse mesmo bit 0 com dois meio-bits sem pausa. Na
codificao Manchester a situao parecida, mas ao invs de ter uma pausa no
primeiro ou no segundo meio-bit, o prprio meio-bit pausado ou modulado.
Alm do esquema de codificao, a intensidade da modulao tambm depende da
taxa de transferncia. Para uma taxa de 106 kbit/s, a modulao de 100%
empregada. Isto significa que em uma pausa, o sinal de RF zero, ou seja, nenhum
sinal enviado. Para taxas acima de 106 kbit/s, uma modulao de 10% utilizada.
Esta variao na intensidade da modulao muito importante para a segurana da
aplicao NFC.
Cartes ISO/IEC 14443 Tipo A usam modulao ASK 100% com codificao Modified
Miller para comunicao do leitor para o carto. Para comunicao do carto para o
leitor utiliza modulao por carga com codificao Manchester. Cartes ISO/IEC 14443
Tipo B usam modulao ASK 10% com codificao NRZ-L para comunicao do leitor
para o carto. Para comunicao do carto para o leitor utiliza modulao por carga
com NRZ-L. O NFCIP-1 no define codificao e modulao para o Tipo A em taxas de
transferncia maiores do que 106 kbit/s. Para velocidades maiores, o Tipo B utilizado.
130
Anexo A Diagrama de Classes
131
Anexo B Diagrama de Classes

Utilização de Near-Field Communication em Dispositivos Móveis

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Utilização de Near-Field Communication em Dispositivos Móveis

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDADE PRESBITERIANA MACKENZIE

ROGER TADEU DOS SANTOS

UTILIZAO DE NEAR-FIELD COMMUNICATION

ROGER TADEU DOS SANTOS

UTILIZAO DE NEAR-FIELD COMMUNICATION EM

Trabalho de Concluso de Curso de Ps

ORIENTADOR: Prof. Dr. Ismar Frango Silveira

ROGER TADEU DOS SANTOS

UTILIZAO DE NEAR-FIELD COMMUNICATION EM

Trabalho de Concluso de Curso de Ps

Aprovada em 01 de novembro de 2012.

minha famlia, pelo constante incentivo e

O objetivo deste trabalho o estudo da tecnologia Near-Field Communication para

Figura 1 - O smbolo da tecnologia NFC, conhecido como N-mark .............................. 17

Figura 27 - Log de estabelecimento de conexo SNEP para envio de mensagem NDEF

Advanced Encryption Standard

Record Type Definition

ISO/IEC 14443 ............................................................................................. 26

COMPARAO COM OUTRAS TECNOLOGIAS ...................................... 28

TIPOS DE DISPOSITIVOS .......................................................................... 30

Classificao dos dispositivos ...................................................................... 31

Security Element .......................................................................................... 34

Interface NFC ............................................................................................... 37

Interface entre SE e NFC Controller ............................................................. 37

Host Controller e HCI ................................................................................... 39

MODOS DE OPERAO ............................................................................ 39

Tags Suportadas .......................................................................................... 41

Logical Link Control Protocol ........................................................................ 49

Simple NDEF Exchange Protocol................................................................. 51

NDEF Push Protocol .................................................................................... 52

Emulao de cartes .................................................................................... 53

Open NFC .................................................................................................... 58

DESENVOLVIMENTO PARA DISPOSITIVOS MVEIS ............................. 60

Open Handset Alliance ................................................................................. 63

Linux Kernel ................................................................................................. 65

Bibliotecas nativas ........................................................................................ 66

Framework de aplicao .............................................................................. 68

Aplicaes e widgets .................................................................................... 68

Ciclo de vida da aplicao ............................................................................ 69

Blocos de Construo .................................................................................. 74

Suporte ao NFC ........................................................................................... 76

Sistema de despacho de mensagens .......................................................... 78

DESENVOLVIMENTO DA APLICAO ..................................................... 81

Leitor NFC .................................................................................................... 82

Dispositivo mvel ......................................................................................... 84

A aplicao do dispositivo mvel.................................................................. 92

A aplicao do leitor NFC ............................................................................. 99

DESENVOLVIMENTO ............................................................................... 101

O protocolo de comunicao ...................................................................... 104

Apresentao dos pacotes ......................................................................... 108

Pacote org.mackenzie.protocol .................................................................. 108

Pacote org.mackenzie.crypto ..................................................................... 110

Pacote org.nfc.mackenzie.context .............................................................. 112

Pacote org.nfc.mackenzie.backend............................................................ 113

Pacote org.nfc.mackenzie .......................................................................... 115

CONCLUSO E TRABALHOS FUTUROS ............................................... 120

REFERNCIAS .......................................................................................... 122

Communication (NFC). Existem aplicativos desenvolvidos para tais plataformas que

O NFC, tambm chamado de comunicao por campo de proximidade, uma

Figura 1 - O smbolo da tecnologia NFC, conhecido como N-mark

A comunicao NFC envolve sempre dois dispositivos e a transferncia de dados entre

Baixar contedo multimdia de um cartaz ou pster;

Trocar contatos entre telefones;