Emulação de título de transporte seguro em telemóvel Android · HCE do Android, que permite a...
-
Upload
phungtuong -
Category
Documents
-
view
226 -
download
0
Transcript of Emulação de título de transporte seguro em telemóvel Android · HCE do Android, que permite a...
Emulação de título de transporte seguro em telemóvelAndroid
Ricardo Emanuel Maia Paradela
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Orientador: Prof. Alberto Manuel Ramos da Cunha
Júri
Presidente: Prof. Miguel Nuno Dias Alves Pupo CorreiaOrientador: Prof. Alberto Manuel Ramos da Cunha
Vogal: Prof. Miguel Filipe Leitão Pardal
Novembro 2015
Abstract
Today’s urban transport systems are part everyday life for millions of people in the world. A lot of
electronic ticketing systems have been developed to facilitate ticket acquisition, and automatic ticket
validation. One of the most used technologies to store acquired electronic tickets are the contactless
smart cards. These have three major advantages: great portability, easy to use, and great security levels,
yet they still require the user to buy their tickets in a automatic ticketing machine, or a box office. In an
attempt to simplify ticket acquisition, smartphones powered with Near Field Communication (NFC), have
been proposed to substitute smart cards. In this scenario smartphones are used to acquire transport
contracts, store them, and access transport services. Due to commercial reasons the access to the
secure hardware existent in every smartphone, the SIM card, is limited to the mobile network operator.
This lack of secure alternatives led to the search of other ways to securely use a smartphone without
having a Secure Element (SE) available. In this work a solution based on Android’s Host-based Card
Emulation (HCE) technology is presented. This technology allows an Android application to emulate a
smart card, leaving all the security details to the application. This solution relies on a remote server to
acquire new transport contracts and improve client card security.
Keywords
NFC, HCE, smart cards, smartphones, urban transport, ticketing, security
i
Resumo
Atualmente os transportes públicos fazem parte do quotidiano de milhões de pessoas em todo o
mundo. Vários sistemas de bilhética eletrónica foram desenvolvidos de forma facilitar grandes fluxos de
passageiros, com o objetivo de facilitar a compra e a validação de bilhetes. Uma das tecnologias mais
utilizadas nos transportes públicos para guardar os bilhetes eletrónicos adquiridos, são os cartões sem
contacto. Estes cartões apresentam três principais vantagens: a portabilidade, facilidade de utilização,
e um nível de segurança elevado, contudo estes requerem que os bilhetes sejam comprados em bi-
lheteiras automáticas, ou postos de venda. Assim, numa tentativa de simplificar o processo de venda,
os smartphones com NFC são proposto para substituir os cartões de proximidade. Neste cenário os
smartphones são utilizados para adquirir bilhetes através de uma aplicação, guardar o bilhete, e aceder
aos serviços de transporte. Por motivos comerciais o acesso ao hardware seguro existente em todos
os smartphones, o cartão SIM, está limitado ao operador de rede móvel. A falta de alternativas de
Elemento Seguro (ES) por hardware disponíveis, leva à procura de novas formas de garantir a segu-
rança dos bilhetes. Neste trabalho será estudada e apresentada uma solução baseada na tecnologia
HCE do Android, que permite a uma aplicação a emulação de um cartão de proximidade sem um ES
presente. Desta forma todos os aspetos de segurança são da responsabilidade da aplicação. A solução
apresentada dependerá num servidor remoto para adquirir novos bilhetes e garantir a segurança dos
mesmos.
Palavras Chave
NFC, HCE, cartões de proximidade, smartphones, transportes públicos, bilhética, segurança
iii
Conteúdo
1 Introdução 1
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Estado da Arte 7
2.1 Bilhetes Eletrónicos codificados em imagens . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Cartões de Proximidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Cartões de proximidade com memória . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Cartões com microprocessador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.4 Duração de uma Transação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 NFC - Emulação de Cartões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Elemento Seguro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 HCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 BLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Arquitetura e Protocolos da Solução Proposta 23
3.1 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Requisitos de Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Protocolos de Interação dos Elementos da Arquitetura . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Inicialização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2 Registo de Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.3 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.4 Carregamento de Cartão Virtual (CV)’s . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Validação Offline Sem Alteração dos Validadores . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Carregamento de tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2 Validação de token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.3 Protocolo de saída/fiscalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
v
3.4.4 Reconciliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Validação Online Sem Alteração dos Validadores . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.1 Protocolo de Validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.2 Protocolo de saída/fiscalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6 Validação Offline Com Alteração dos Validadores . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.1 Carregamento de tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.2 Protocolo de Validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6.3 Protocolo de saída/fiscalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6.4 Reconciliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4 Implementação 43
4.1 Solução Implementada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Comunicação Segura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.2 Canal Seguro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.3 Autenticação dos Dispositivo Móvel (DM)’s . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Cartão Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.1 Instanciação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Registo de Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5 Carregamento de Saldo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6 Servidor de Bilhética . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.1 Leitor de CV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6.2 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6.2.A Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6.2.B Servidor Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6.2.C Comunicação Entre Processos . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6.2.D Tolerância a Faltas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7 Carregamento de CV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7.1 Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7.2 Leitura de Saldo do CV na cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.8 Reconciliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.9 Cálculo de Round Trip Time (RTT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.10 Cliente Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.10.1 Biblioteca Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.10.1.A Registo e Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.10.1.B Carregamento de Saldo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.10.1.C Carregamento de CV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.10.1.D Emulação de Cartão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
vi
4.11 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5 Avaliação 59
5.1 Medições dos tempos de Transação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.1 Ambiente utilizado nas medições . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.2 CV Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.3 CV como Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Análise de Ameaças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Satisfação de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6 Conclusão e Trabalho Futuro 73
Bibliography 79
Apêndice A RESTful API A-1
Apêndice B Interface Biblioteca Android B-1
Apêndice C Diagrama de Classes C-1
Apêndice D Risk Assessment D-1
Apêndice E Tempos Medidos em Transações de Validação E-1
vii
Lista de Figuras
2.1 Representação dos módulos de um cartão de proximidade com dupla interface. Em (a)
é representada a interface de contacto, usada para alimentar o cartão e comunicar com
o mesmo através de conectores metálicos. Em (b) está representada a antena usada na
comunicação por frequências rádio, e também responsável pela alimentação do cartão
através de indução eletromagnética. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Diagrama de interação entre componentes de um smartphone com NFC [16]. . . . . . . 15
3.1 Diferentes componentes do sistema, e interações entre os mesmos. . . . . . . . . . . . . 26
3.2 Arquitetura da solução proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Protocolo usado para um cliente proceder ao registo no sistema. . . . . . . . . . . . . . . 29
3.4 Protocolo usado para autenticar um cliente perante o Serviço Cloud (SC). . . . . . . . . . 30
3.5 Protocolo usado para efetuar um carregamento no CV. . . . . . . . . . . . . . . . . . . . 31
3.6 Protocolo usado para carregar um token no DM. . . . . . . . . . . . . . . . . . . . . . . . 32
3.7 Protocolo usado para validar um token junto de um validador automático. . . . . . . . . . 33
3.8 Protocolo usado no processo de reconciliação entre os validadores e o SC. . . . . . . . . 34
3.9 Protocolo de validação online. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.10 Protocolo de carregamento de token. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.11 Protocolo de validação de token. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1 Diagrama de classes da virtualização do cartão CTS512B. . . . . . . . . . . . . . . . . . 48
4.2 Protocolo de carregamento de produtos em CV através de Ticketing Kernel (TK). . . . . . 52
4.3 Protocolo de leitura de saldo de um CV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1 Comparação dos tempos de transação medidos com um cartão CTS512B e um CV on-
line. No eixo vertical estão identificados os tempos de transação registados em milisse-
gundos. No eixo horizontal está identificada a amostra utilizada. . . . . . . . . . . . . . . 61
5.2 Estatísticas dos tempos de transação medidos com um cartão CTS512B e um CV online.
No eixo vertical estão identificados os tempos de transação em milissegundos, e no eixo
horizontal as estatísticas calculadas: média, moda, mediana e desvio padrão. . . . . . . 62
5.3 Comparação dos tempos de transação medidos com um cartão CTS512B e um CV como
token. No eixo vertical estão identificados os tempos de transação registados em milis-
segundos. No eixo horizontal está identificada a amostra utilizada. . . . . . . . . . . . . . 63
ix
5.4 Estatísticas dos tempos de transação medidos com um cartão CTS512B e um CV como
token. No eixo vertical estão identificados os tempos de transação em milissegundos, e
no eixo horizontal as estatísticas calculadas: média, moda, mediana e desvio padrão. . . 64
x
Lista de Tabelas
2.1 Tempos medidos nos diferentes testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Comparação das diferentes tecnologias estudadas em relação às características de se-
gurança, vantagens e desvantagens de cada uma. . . . . . . . . . . . . . . . . . . . . . . 21
5.1 Dados indicativos das ligações de rede utilizadas. . . . . . . . . . . . . . . . . . . . . . . 60
5.2 Exemplo de Application Protocol Data Unit (APDU)’s emitidas durante uma validação. . . 62
5.3 Principais assets do sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 Relação entre assets e os principais componentes da solução. . . . . . . . . . . . . . . . 65
5.5 Principais ameaças identificadas no sistema. . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.6 Documentação da ameaça T1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.7 Documentação da ameaça T2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.8 Documentação da ameaça T3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.9 Documentação da ameaça T4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.10 Documentação da ameaça T5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.11 Classificação de ameaças segundo modelo DREAD. . . . . . . . . . . . . . . . . . . . . 68
5.12 Classificação da ameaça T1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.13 Classificação da ameaça T2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.14 Classificação da ameaça T3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.15 Classificação da ameaça T4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.16 Classificação da ameaça T5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
xi
Abbreviations
AID Application IDentifier
APDU Application Protocol Data Unit
BLE Bluetooth Low Energy
CPU Central Processor Unity
CV Cartão Virtual
DM Dispositivo Móvel
EEPROM Electrical Erasable Programmable Read-Only Memory
ES Elemento Seguro
GSM Global System for Mobile Communications
HCE Host-based Card Emulation
HTTP HyperText Transfer Protocol
IP Internet Protocol
JWT JSON Web Token
MAC Message Authentication Code
MMS Multimedia Messaging Service
NFC Near Field Communication
PBKDF2 Password-based Key Derivation Function 2
PCSC Personal Computer/Smart Card
RAM Random Access Memory
RF Radio Frequency
ROM Read-Only Memory
RTT Round Trip Time
xiii
SAM Secure Application Module
SC Serviço Cloud
SE Secure Element
SO Sistema Operativo
TCP Transmition Control Protocol
TEE Trusted Execution Environment
TK Ticketing Kernel
TLS Transport Layer Security
UICC Universal Integrated Circuit Card
URL Uniform Resource Locator
USB Universal Serial Bus
xiv
1Introdução
Contents1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1
1.1 Motivação
O número de pessoas que diariamente utiliza os transportes públicos como o seu principal meio de
transporte tem aumentado constantemente. Segundo a International Association of Public Transport
- UITP, atualmente 64% das viagens realizadas em todo o mundo acontecem em ambiente urbano.
Espera-se que até 2050 o número de pessoas a movimentarem-se por quilometro em meio urbano,
passe para o triplo[1].
Com este aumento de fluxo de passageiros, naturalmente os operadores de transportes terão de
adaptar o serviço prestado. Os seus serviços de bilhética, consequentemente, terão de ser atualizados
de modo a agilizar os processos de aquisição e validação, diminuindo as filas de espera e poupando
tempo aos passageiros.
Os sistemas de bilhética dos serviços de transportes, tendo começado com os típicos bilhetes em
papel, têm, nos últimos vinte anos, evoluído para sistemas com suporte eletrónico. Estes começaram
por ser utilizados nos transportes aéreos, e foram propostos por J. R. Goheen[2]. Apesar de os bi-
lhetes eletrónicos implicarem maiores custos de implementação, quando comparados com um sistema
de bilhetes de papel, uma vez que precisam de muito mais equipamento especializado, para a venda,
validação, etc., permitem a prestação de um serviço com melhor qualidade para o utilizador. A utili-
zação deste tipo de bilhetes tem a vantagem de agilizar a aquisição de bilhetes através de máquinas
automáticas, páginas web, etc. Em termos de segurança estes são também vantajosos pois dificultam
a falsificação.
Nos tradicionais bilhetes de papel o conceito de bilhete define o conjunto da folha de papel, com
todos os dados nela impressos relativos ao contrato que este representa. Estes podem conter desde
o identificador do bilhete, aos dados da viagem (origem, destino, data e hora, etc.), entre outros. Na
bilhética eletrónica, ao contrário dos bilhetes de papel, o suporte físico e o contrato devem ser vistos
como entidades separadas. Dado que o mesmo tipo de bilhete eletrónico pode ser guardado em supor-
tes físicos diferentes, cada uma das entidades deve ser analisada independentemente para se poder
concluir sobre as vantagens e desvantagens do todo.
O uso de cartões de proximidade como suporte para guardar os bilhetes eletrónicos adquiridos
pelos clientes tem ganho bastante relevância devido às garantias de segurança que estes oferecem,
tanto para operadores como clientes, e, comodidade, uma vez que os utilizadores podem adquirir vários
títulos de viagem e guardar no mesmo cartão. Os cartões de proximidade têm também a vantagem
para os utilizadores, relativamente a outros cartões (por exemplo, cartões de banda magnética), de não
necessitarem de ser introduzidos num leitor, permitindo até a sua utilização estando dentro de uma
carteira.
O Near Field Communication (NFC) é uma tecnologia de comunicações por proximidade, que pos-
sibilita a transferência de dados entre dispositivos a distâncias na ordem dos 10 cm. Segundo a IHS
Technology [3], prevê-se que no ano de 2015, 756 Milhões dos telemóveis vendidos mundialmente te-
rão disponível um chip NFC, sendo que no ano de 2014 foram vendidos 444 Milhões.
As previsões apresentadas anteriormente são promissoras, contudo a utilização de smartphones
2
com NFC tem ainda algumas condicionantes relativamente à segurança dos bilhetes em smartphones.
Como será demonstrado neste trabalho, a maior parte das soluções de bilhética existentes, baseadas
em smartphones, necessitam de um ambiente de execução seguro, conhecido como Elemento Se-
guro (ES). O cartão SIM presente em todos os smartphones, é um ES que é utilizado em algumas
soluções de bilhética com smartphone. O cartão SIM é gerido pelo operador de telecomunicações, e a
utilização deste ES por parte de terceiros é geralmente bloqueada. As implementações de sistemas de
bilhética com smartphone que utilizam este modelo têm normalmente como parceiro um operador de
telecomunicações. Esta opção não é viável para os operadores pois implica a participação de outras
entidades no seu modelo de negócio, e consequente perda de receitas.
Tendo em conta a falta de alternativas disponíveis em hardware, o sistema de ficheiros dos smartpho-
nes é a melhor alternativa para guardar os bilhetes eletrónicos localmente. Contudo, apesar de os
sistemas operativos utilizados nos smartphones implementarem mecanismos de permissões ao nível
do sistema de ficheiros, que protegem o acesso indesejado a ficheiros por parte de outras aplicações,
quem gere o sistema operativo do smartphone é o utilizador, e este pode alterá-lo de modo a remover
as proteções existentes. Assim não é viável guardar dados críticos, como por exemplo um título de
viagem, no sistema de ficheiros de um smartphone dependendo simplesmente destes mecanismos de
segurança. Dada a falta de garantias de segurança para dados e aplicações, outras abordagens devem
ser estudadas, a fim de desenvolver uma solução que permita o mesmo nível de confiança tanto para
os clientes como para operadores.
Neste trabalho foi utilizado um smartphone NFC como suporte físico para bilhetes eletrónicos geral-
mente guardados em cartões sem contacto. Recorre-se à tecnologia Host-based Card Emulation (HCE)
do Sistema Operativo (SO) Android KitKat (v4.4), uma tecnologia de emulação de cartões sem contacto
sem utilização de hardware seguro. Foram utilizadas duas técnicas que através da virtualização de um
cartão de proximidade permitem dispensar um ES local: ‘tokenização’, e ES online. A ‘tokenização’
consiste na criação de um novo cartão, ou token, através de um cartão existente, de forma que o novo
cartão seja limitado em termos de valor e validade temporal, e através do qual não seja possível obter
o cartão original. O ES online consiste em guardar um cartão virtualizado na base de dados de um
servidor, de forma que para aceder aos dados o smartphone tenha necessariamente de estar ligado
a este. Consequentemente foi desenvolvido o servidor no qual serão disponibilizados serviços que o
smartphone poderá utilizar para comprar de títulos de viagem, descarregar novos tokens, entre outros.
Como mais à frente será demonstrado, a utilização da técnica de ‘tokenização’, permite obter bons
resultados nos tempos de transação, e um nível de segurança aceitável.
1.2 Objetivos
Este trabalho foi desenvolvido na empresa Card4B Systems, S.A., durante o ano letivo de 2014/2015,
no âmbito de um projeto que pretende estudar qual o enquadramento dos smartphones nas soluções
sem-contacto atualmente implementadas.
O principal objetivo no desenvolvimento deste trabalho foi a utilização de um smartphone, com o
3
sistema operativo Android KitKat e NFC, como suporte físico para bilhetes eletrónicos de transportes,
garantindo o mesmo grau de segurança oferecido pelos cartões de proximidade. Desta forma, o prin-
cipal foco estará nos principais aspetos de segurança da solução desenhada, não sendo, contudo,
desprezados os aspetos de usabilidade, pelo que se deverão centrar no smartphone funcionalidades
como o carregamento, que atualmente necessitam de um posto de carregamento. Como demonstração
do conceito, a aquisição, carregamento, validação e fiscalização de bilhetes eletrónicos são totalmente
suportados nesta solução.
1.3 Requisitos
Com base nos objetivos definidos na secção anterior, podemos assim definir os requisitos deste
trabalho, começando por apresentar os requisitos funcionais de seguida:
• A utilização de um smartphone de forma idêntica aos cartões de proximidade usados atualmente,
permitindo a validação de um título de viagem apenas aproximando o smartphone do validador.
• A aquisição de títulos de viagem através de uma aplicação instalada no smartphone, assim como
a consulta de títulos de viagem ainda disponíveis para validar.
De seguida são enumerados os requisitos não-funcionais:
• A autenticidade e integridade dos títulos de viagem adquiridos através do smartphone deve ser
garantida.
• A validação de um título de viagem deve ser executada num tempo de ordem equivalente aos
atuais sistemas de bilhética com cartões de proximidade.
1.4 Estrutura do Documento
Neste documento será descrito o processo de desenvolvimento de uma solução de bilhética segura
com base num smartphone.
De seguida é apresentada a estrutura do documento e o conteúdo dos principais capítulos.
Capítulo 2
Este capítulo apresenta algumas das tecnologias utilizadas nos sistemas de bilhética eletrónica, tais
como sistemas com códigos de barras, ou cartões de proximidade. Serão também enumerados alguns
sistemas de bilhética com smartphone, e as principais tecnologias utilizadas nas comunicações por
proximidade.
Capítulo 3
Neste capítulo será apresentada a arquitetura da solução proposta. Serão descritos todos os com-
ponentes da mesma, e de que forma se procede a orquestração entre componentes, para cada um dos
casos de uso identificados.
4
Capítulo 4
Aqui será descrito o processo de desenvolvimento da solução proposta. Serão enumeradas as
tecnologias utilizadas assim como as alterações efetuadas a cada componente, de forma a que o com-
portamento destes se adaptasse a eventuais limitações impostas pelas tecnologias.
Capítulo 5
No capítulo 5 será descrito o processo de avaliação da solução. Este terá como base a compara-
ção de tempos de transação entre as diferentes soluções implementadas, e uma solução tradicional de
bilhética com cartões de proximidade. Neste capítulo serão também revistos os objetivos e requisitos
definidos inicialmente, constatando quais deles foram atingidos e cumpridos. Adicionalmente será tam-
bém apresentada uma análise às principais falhas de segurança, assim como cada uma se classifica
relativamente ao risco que lhes está associado.
Capítulo 6
Este capítulo conclui o documento. Neste será resumido o trabalho desenvolvido, e por fim indicará
quais os próximos passos na continuação do desenvolvimento deste trabalho.
5
6
2Estado da Arte
Contents2.1 Bilhetes Eletrónicos codificados em imagens . . . . . . . . . . . . . . . . . . . . . . . 82.2 Cartões de Proximidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 NFC - Emulação de Cartões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 BLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7
Várias soluções de bilhetes eletrónicos foram desenvolvidas ao longo dos últimos anos. Nesta
secção é apresentado o estado da arte dos bilhetes eletrónicos, fazendo uma análise sistemas de
bilhética e tecnologias usadas para a sua disponibilização no mercado.
A secção 2.1 começa por apresentar bilhetes eletrónicos através de códigos de barras, dando es-
pecial foco aos sistemas através de smartphones. De seguida, na secção 2.2, serão apresentados os
cartões que suportam os sistemas de transportes da cidade de Lisboa. Na secção 2.3 são apresenta-
das as soluções usadas para a emulação de cartões em smartphones. No final desta, será apresentado
também o Host-based Card Emulation (HCE), uma tecnologia de emulação de cartões de proximidade
que está atualmente a ser aplicada na área dos pagamentos através de smartphones. Por último,
na secção 2.4, é apresentado o Bluetooth Low Energy (BLE), uma nova tecnologia que está a ser
introduzida na área dos pagamentos. Embora não existam ainda implementações concretas, serão
introduzidos alguns casos de uso apresentados em artigos.
2.1 Bilhetes Eletrónicos codificados em imagens
Atualmente existem várias empresas que utilizam bilhetes eletrónicos codificados em imagens, em
que o cliente pode comprar os seus bilhetes a partir de casa através, por exemplo, de uma página Web.
Após a compra, o cliente tem a opção de receber o seu bilhete por email, telefone (desde que o seu
dispositivo cumpra alguns requisitos), correio, etc. As companhias aéreas, por exemplo, permitem a
compra de bilhetes eletrónicos online, contudo, em alguns casos, requerem que os clientes imprimam
os bilhetes e no dia do voo se apresentem com o mesmo impresso. Outras empresas enviam apenas
ao cliente um voucher que permite ao cliente o levantamento do bilhete numa bilheteira.
O código de barras é uma tecnologia bastante usada neste tipo de bilhetes eletrónicos, que permite
codificar informação em imagens. O uso destas tecnologias permite o uso de validadores automáticos,
que recorrem a leitores óticos ou câmaras para ler os códigos de barras e interpretar os dados originais.
Os códigos de barras permitem guardar informação em vários formatos (como texto, ou binário), sendo
possível guardar dados cifrados e incluir assinaturas digitais.
Os códigos de barras lineares, ou unidimensionais, são usados em grande escala nos supermerca-
dos para identificar os produtos. São também aplicados na área da bilhética, para identificar bilhetes de
papel. No entanto, os código de barras matriciais, ou de duas dimensões, permitem guardar dados em
vários formatos distintos, por exemplo, identificadores numéricos e alfa-numéricos, Uniform Resource
Locator (URL) e dados binários (bits/bytes). Na bilhética, estes tanto são usados como identificado-
res (tal como no caso dos lineares), como representações eletrónicas, permitindo guardar os dados
necessários para ser validado.
Dong Li[4] descreve um sistema de compra de bilhetes online proposto para os transportes ferroviá-
rios chineses onde são utilizados os códigos de barras. Os transportes ferroviários chineses, devido à
elevada densidade populacional da China, tinham frequentemente grandes filas nas bilheteiras. Antes
da introdução do novo sistema, apesar de disporem de várias formas de adquirir bilhetes, tanto por
telefone como através da Internet, ainda era necessário que os utilizadores levantassem os seus bilhe-
8
tes numa bilheteira, mantendo-se a espera em filas. O sistema apresentado foi criado com base nos
códigos de barras matriciais, e tenta resolver os problemas de usabilidade que os utilizadores tinham
em adquirir bilhetes eletrónicos. Outro problema no sistema implementado anteriormente, é que ape-
nas eram autenticados os bilhetes, e nunca os clientes, o que levava a que criminosos aproveitassem
a falha para vender bilhetes previamente adquiridos por preços bastante inflacionados.
O sistema apresentado pelos autores permite a compra de bilhetes através de uma aplicação para
smartphones Android1. Segundo o autor os smartphones Android são bastante comuns nos cidadãos
chineses, e fáceis de transportar, tornando conveniente a sua utilização nos sistemas de bilhética.
Através desta aplicação, os utilizadores são capazes de consultar os horários disponíveis dos vários
percursos, e comprar bilhetes para os percursos que pretenderem. A aplicação disponibilizará, após
confirmação do pagamento, um recibo no formato de um código de barras matricial, com o qual o
passageiro deve, momentos antes, dirigir-se a uma máquina automática onde, após apresentação do
recibo emitido, esta irá validar o recibo e imprimir o bilhete de embarque. A validação do recibo é
feita num modelo online, ou seja, cada máquina de validação necessita de estar ligada às bases de
dados, onde estão guardados os bilhetes adquiridos. No momento em que o recibo é apresentado ao
leitor, o identificador do recibo é lido e procurado na base de dados. Caso o recibo ainda não tenha
sido validado nenhuma vez, os dados do bilhete serão então descarregados para o validador, que irá
imprimir o bilhete.
Apesar das claras melhorias que o sistema proposto apresenta em relação aos sistema em uso no
momento, este ainda requer a impressão de um bilhete em papel que o passageiro deve ter consigo
durante a viagem. Tem também a desvantagem de requerer que os sistemas de venda e os sistemas
de validação estejam conectados a todo o momento, não sendo assim possível a colocação de vali-
dadores em ambientes onde não exista uma ligação estável à rede. Uma solução para o problema
que é a necessidade de os equipamentos de venda e validação estarem conectados, é sugerida por
D. Škarica, H. Belani, e S. Illeš em [5]. Aqui os autores apresentam dois casos de estudo de sistemas
de bilhetes eletrónicos em que os bilhetes adquiridos são descarregados para um telemóvel, com ecrã
capaz de mostrar um código de barras matricial, através de uma Multimedia Messaging Service (MMS).
No primeiro caso de estudo, a validação dos bilhetes é feita online tal como no sistema descrito ante-
riormente. Contudo, em vez de ser enviado para o utilizador um recibo para posteriormente proceder
ao levantamento do bilhete, o utilizador recebe o bilhete eletrónico no telemóvel com o identificador do
seu bilhete codificado, e deve apresentar o telemóvel sempre que for requerida a validação do bilhete.
Quando o telemóvel é apresentado, o leitor lê o identificador e envia para os servidores de bilhetes,
onde é validada a autenticidade do bilhete, assim como se este ainda pode ser usado.
No segundo caso de estudo, o sistema apresentado resolve o problema da validação offline, per-
mitindo aos validadores não estarem constantemente ligados aos servidores centrais. Para tal ser
possível, os bilhetes, também codificados num código de barras matricial, passam a conter não só
o identificador do bilhete, mas também a informação da viagem que está associada, por exemplo:
origem, destino, data e hora, número de viagens, identificação do cliente, etc. Com estes dados o
1Sistema operativo de fonte aberta, usado maioritariamente em smartphones e tablets, desenvolvido pela Google.
9
validador consegue garantir que o bilhete deve realmente ser usado no serviço que lhe estiver associ-
ado. Para garantir a integridade e autenticidade dos dados dos bilhetes, uma vez que neste modelo os
validadores não têm acesso às bases de dados de bilhetes, foram adicionados mecanismos baseados
em cifra assimétrica. Assim os serviços de venda de bilhetes, que criam os bilhetes enviados para
os utilizadores, usam a chave privada para cifrar os dados do bilhete, e os validadores usam a chave
pública para decifrar os mesmos, garantindo a sua autenticidade e integridade. Os validadores, após
a validação com sucesso, registam numa base de dados local a utilização daquele bilhete, de forma
a evitar que este seja utilizado mais vezes do que o número de viagens que lhe está associado. Este
sistema tem melhorias relativamente aos modelos estritamente online, contudo em certos casos, como
por exemplo os autocarros urbanos cujos bilhetes não são emitidos para um veículo específico, uma
vez que os validadores requerem uma ligação a uma base de dados local onde guardam os bilhetes já
utilizados, não seria possível garantir que o mesmo bilhete não seria utilizado num autocarro diferente
para efetuar o mesmo percurso.
2.2 Cartões de Proximidade
Nesta secção serão apresentados os cartões de proximidade como tecnologia de suporte físico
para contratos de transportes públicos. Estes cartões são aqui apresentados, pois atualmente são
referência, em termos de usabilidade e padrões de segurança, para qualquer solução de bilhética com
smartphone e Near Field Communication (NFC).
Os cartões de proximidade são dispositivos eletrónicos embebidos em cartões de papel ou plástico.
Estes têm memórias que permitem guardar bilhetes eletrónicos, assim como outros dados, e alterar o
seu estado depois de estes serem apresentados a um validador. No caso dos bilhetes de transportes,
estes, podem guardar informação da validação, como a data e hora. Permitem também que o mesmo
bilhete possa incluir mais do que um título de viagem, descontando os títulos disponíveis após cada
validação.
Na secção seguinte, são apresentados os vários tipos de cartões usados atualmente nos serviços
de transportes de Lisboa, compatíveis com o ISO/IEC 14443-B[6].
2.2.1 Cartões de proximidade com memória
Os cartões de proximidade com memória, são cartões sem contacto com um mapa de memória
persistente que permitem através de Radio Frequency (RF) a leitura e escrita de dados. Estes são
os cartões usados nos casos dos “Viva Viagem” e “7 Colinas” 2. Estes cartões são geralmente usa-
dos por utilizadores ocasionais, e permitem carregar títulos de transporte do mesmo tipo, ou efetuar
carregamentos de dinheiro.
2https://www.portalviva.pt/lx/pt/homepage/cart%C3%B5es/transportes/viva-viagem-7-colinas.aspx
10
Arquitetura
Estes cartões são compostos por dois módulos principais: interface de RF, e um chip de memória.
A interface de RF, é responsável não só pela comunicação do cartão com o leitor, mas também pelo
fornecimento de energia elétrica gerada através de indução eletromagnética, ao módulo de memória [7,
p. 45]. O módulo de memória é composto uma Electrical Erasable Programmable Read-Only Memory
(EEPROM) onde podem ser guardados os dados de forma não-volátil [8, p. 21]. A comunicação entre o
leitor e o cartão é feita de forma assíncrona. O leitor emite o comando para o cartão, este irá processar o
comando, e retornar para o leitor a resposta gerada. Estes cartões contêm também um módulo que liga
a interface RF e a memória, e que é responsável por descodificar e executar os comandos recebidos, e
produzir a resposta a devolver ao leitor.
Segurança
Estes cartões não têm qualquer mecanismo que permita ao cartão autenticar um leitor. Assim
sendo, qualquer leitor compatível pode ler e escrever nestes cartões. Para garantir a segurança dos
dados escritos no cartão é necessário proteger os próprios dados através de cifras e assinaturas gera-
dos pela aplicação do leitor. Nos sistemas de bilhética, geralmente, os leitores possuem instalado um
smartcard com microprocessador, chamado de Secure Application Module (SAM), que permite exe-
cutar operações criptográficas sem expor as chaves utilizadas. Os SAM’s são então utilizados para
cifrar dados, ou criar um Message Authentication Code (MAC)[9], aqui chamado de certificado, dos
dados contidos no cartão. Assim são garantidas, respetivamente, a confidencialidade, autenticidade e
integridade dos dados.
Estes cartões apresentam um nível de segurança reduzido e por esta razão, em Lisboa, estes
cartões não são usados para guardar passes mensais, mas sim apenas títulos de utilização pontual.
Esta é uma limitação imposta pela entidade gestora dos operadores de transportes, que devido ao valor
dos passes mensais, que à data atual podem custar entre e30,65 e os e105,053, requer que sejam
utilizados cartões com um nível de segurança superior, como os apresentados de seguida.
2.2.2 Cartões com microprocessador
Os cartões com microprocessador são cartões de proximidade programáveis que permitem a exe-
cução de protocolos de comunicação mais completos do que apenas leituras e escritas. Estes são
os cartões usados no cartão Lisboa Viva 4. Este cartão é geralmente usado para carregar contratos
mensais para uma ou mais operadoras de transporte, embora possa também ser carregado com títulos
de viagem singulares, ou dinheiro. Para um cliente obter um cartão destes, terá primeiro de efetuar re-
gisto, e o cartão ser-lhe-á entregue posteriormente, personalizado com o nome e fotografia do utilizador,
sendo este intransmissível.
Os cartões com microprocessador ilustrados na Figura 2.1, estão disponíveis nas vertentes com
3Tarifários Carris [27-02-2015] http://www.carris.pt/fotos/editor2/tarifario_site_2014.pdf4https://www.portalviva.pt/lx/pt/homepage/cart%C3%B5es/transportes/lisboa-viva.aspx
11
Figura 2.1: Representação dos módulos de um cartão de proximidade com dupla interface. Em (a) é representadaa interface de contacto, usada para alimentar o cartão e comunicar com o mesmo através de conectores metálicos.Em (b) está representada a antena usada na comunicação por frequências rádio, e também responsável pelaalimentação do cartão através de indução eletromagnética.
contacto, proximidade, e dupla-interface. Os cartões Lisboa Viva usam o sistema Calypso 5, que é
composto por SAM, instalado nos leitores, e cartão Calypso. O SAM é um cartão com contacto, en-
quanto que o cartão Calypso é de dupla-interface, e permite comunicação com os leitores através da
sua interface de contacto ou simplesmente aproximando de um leitor compatível com o ISO/IEC 14443.
Este cartões são “tamper-proof ", e não permitem que os dados neles guardados sejam alterados sem
existir autenticação da entidade que pretende fazer as alterações. As chaves criptográficas que estes
usam, são guardadas em partes da sua memória, ou ficheiros, privados, pelo que apenas as aplicações
que estes executam as podem utilizar, não sendo possível para um atacante ou mesmo para um leitor
com um SAM válido, obter estas chaves através das interfaces disponíveis.
Arquitetura
A arquitetura dos cartões Calypso (SAM e cartão) pode dividir-se em dois módulos principais:
módulo de comunicação, responsável pela comunicação por RF (disponível apenas no cartão) e in-
terface de contactos (disponível em ambos), e o micro-controlador que contém o Central Processor
Unity (CPU), memória Random Access Memory (RAM), memória Read-Only Memory (ROM), e uma
EEPROM que é usada para guardar dados de forma persistente [8, p. 24].
Segurança
A segurança do sistema Calypso assenta no uso de chaves secretas, guardadas em cartões com
microprocessadores (cartão Calypso e SAM)[10]. O conhecimento destas chaves permite autenticar os
cartões, e efetuar alterações nos mesmos. Os terminais que comuniquem com um cartão têm de estar
equipados com um SAM, o que lhes permitirá descentralizar a segurança das operações de validação
e venda de títulos de viagem, que inclusive pode ser efetuada sem ligação a um servidor.
O sistema Calypso usa algoritmos de criptografia simétrica (como o AES, Triple-DES ou DESX),
para autenticar cartões ou terminais, assim como todos os dados trocados entre estes. É importante
referir que os dados cifrados pelas chaves de longo prazo guardadas nos cartões, nunca são expostos.5http://www.calypsonet-asso.org/
12
Os dados usados na comunicação com o terminal, são sempre cifrados com chaves de sessão.
A comunicação entre um cartão e leitor é encapsulada numa sessão segura. Esta assegura a au-
tenticidade da aplicação, do cartão, do terminal e dos dados trocados durante a mesma. O mecanismo
de sessões garante que ou as modificações efetuadas durante a sessão são completadas totalmente e
corretamente, ou nenhuma é feita. Isto é possível devido ao sistema de roll-back que é executado no
caso de interrupções durante uma transação. Uma sessão segura é iniciada quando o cartão recebe
o comando de início de sessão (Open Secure Session), e termina com a receção do comando de fim
de sessão(Close Secure Session). Durante a sessão é possível ler e escrever dados do cartão, sendo
contudo possível que o acesso a alguns ficheiros seja restringido caso, por exemplo, não tenha sido
inserido um código PIN. Depois de uma sessão ter sido terminada, é criado um MAC pelo cartão e pelo
SAM presente no terminal, de forma a garantir a autenticidade do cartão ao terminal e vice-versa, assim
como para garantir que os dados trocados são genuínos, e que o cartão foi corretamente atualizado.
Só após esta última validação, o terminal permite a entrada no utilizador serviço.
Existe ainda um mecanismo associado às sessões seguras, que pretende resolver o caso em que a
comunicação é interrompida no momento a seguir ao cartão ter escrito os dados relativos à transação,
mas antes de o terminal ter recebido a confirmação. Este mecanismo é chamado de Ratification, e
permite que no caso de o cartão ser novamente apresentado este não seja novamente descontado.
2.2.3 Casos de Uso
Nesta secção serão apresentados os casos de uso dos sistemas de bilhética com cartões de pro-
ximidade, de acordo com a implementação usada na cidade de Lisboa. Os casos de uso são os
seguintes:
1. Aquisição - Processo que permite aos clientes adquirir um cartão para usar nos serviços de
transportes. Este processo distingue-se da seguinte forma para os diferentes cartões:
• Viva Viagem/Sete Colinas (Cartões de memória): Estes cartões podem ser adquiridos em
qualquer bilheteira, ou máquina de venda automática. Cada cartão tem o custo de e0,50, e
não existe qualquer limite de quantos cartões cada cliente pode adquirir. Estes cartões têm
uma validade, ao fim da qual ficam inutilizáveis.
• Lisboa Viva (Cartões com microprocessador): Os cartões Lisboa Viva, ao contrário dos ante-
riores, requerem um registo para que possam ser emitidos. Para efetuar o registo os clientes
podem optar por se dirigir a um posto de venda, ou através da aplicação web Portal Viva6,
e terá em ambos os casos um custo aproximado de e10. Estes cartões serão personaliza-
dos graficamente com o nome e fotografia do assinante. Serão também escritos numa área
dedicada do cartão alguns dados pessoais do cliente.
2. Carregamento - Neste processo um cliente poderá utilizar as máquinas de venda automática ou
bilheteiras para carregar os seus cartões. Caso o cliente possua um cartão Lisboa Viva, este
6Portal Viva - https://www.portalviva.pt/
13
pode também efetuar o seu carregamento através do Portal Viva (através de um leitor de cartões
ligado ao computador do cliente), ou também na rede Multibanco7.
3. Validação - A validação é o processo em que o cliente, após ter carregado um passe ou títulos
ocasionais num cartão, terá de apresentar o seu cartão num validador automático para poder
aceder ao serviço de transporte. Neste processo será registada no cartão a entrada do cliente na
paragem ou estação respetiva, assim como descontada a viagem do cartão no caso dos ocasi-
onais. No caso das redes de transportes fechadas o processo de validação efetua-se também à
saída. Nesta fase é validado se o utilizador tinha um título de viagem válido para o percurso que
efetuou.
4. Fiscalização - A fiscalização é o processo em que um fiscalizador do serviço de transportes
verifica se os passageiros possuem um título válido para o percurso que estão a efetuar, e se no
inicio da viagem efetuaram a validação do mesmo. No caso de um passageiro não cumprir as
condições anteriores, pode-lhe ser aplicada uma coima.
2.2.4 Duração de uma Transação
Num sistema de bilhética a duração da execução de uma transação, é uma métrica importante
e a ter em conta. Cada transação, dependendo do caso de uso que lhe está associado, poderá ter
diferentes requisitos temporais. Por exemplo, no caso do carregamento de novos títulos é esperado
que o processo seja mais lento, pois este depende da interação entre o cliente e a bilheteira para
escolher os produtos que quer carregar, e também só depois de o cliente efetuar o pagamento é que
os produtos são efetivamente carregados. Neste caso é pouco relevante o tempo das operações de
escrita no cartão, pois comparado com o tempo gasto na escolha do produto e pagamento, deverá ser
insignificante.
No caso de uso da validação de um título de viagem, processo executado por validadores automá-
ticos, espera-se que estes consigam executar a transação de validação num tempo compatível com
o fluxo de passagem das pessoas pelas portas de acesso. Tempos elevados podem congestionar o
acesso aos serviços de transportes, e consequentemente provocar atrasos no serviço. A duração de
uma transação de validação espera-se que seja na ordem das centenas de milissegundos. Os car-
tões de proximidade descritos acima, cartões de memória e de microprocessador, permitem tempos de
transação inferiores a 100ms e 200ms, respetivamente [11][12]. Estes tempos contudo variam nas dife-
rentes implementações, uma vez que estes tempos dependem do modelo de dados usado no cartão.
O número de ficheiros ou contadores que é necessário ler e escrever na transação, influência o tempo
final da transação. Como referência de uma implementação real, a especificação ITSO usada no Reino
Unido define que para o seu modelo de dados aplicado num cartão com microprocessador Calypso,
300ms é o tempo máximo aceitável para uma transação [13].7Carregar Lisboa Viva no Multibanco - http://www.carris.pt/pt/carregar-multibanco
14
Figura 2.2: Diagrama de interação entre componentes de um smartphone com NFC [16].
2.3 NFC - Emulação de Cartões
A tecnologia NFC é definida por um conjunto de standards, mantida pelo NFC-Forum, que visa pro-
videnciar a smartphones e outros dispositivos similares, a capacidade de estabelecer comunicação via
RF, simplesmente aproximando dois dispositivos. Esta tecnologia baseia-se no acoplamento indutivo,
e permite que acoplamento de circuitos indutivos partilhem energia elétrica e dados, a uma distância
de alguns centímetros [14].
O NFC permite-nos três modos de funcionamento [15]:
• Modo Leitor/Escritor - O dispositivo NFC é capaz de ler as tags especificadas pelo NFC-Forum.
Este modo na interface de FR! (FR!) é compatível com o ISO/IEC 14443;
• Modo Peer-to-Peer - Dois dispositivos com NFC, são capazes de trocar dados entre si. Este
modo é definido no standard ISO/IEC 18092;
• Modo de Emulação de Cartões - Neste modo um dispositivo NFC, comporta-se para um leitor
externo, exatamente como um cartão de proximidade. Desta forma os dispositivos NFC podem
ser utilizados para pagamentos e bilhética, entre outros, sem efetuar alterações na infraestrutura
atual.
O modo de emulação de cartões, permite-nos assim substituir os cartões de proximidade pelos
smartphones com NFC, como dispositivos para guardar bilhetes eletrónicos. Esta substituição tem a
vantagem de o utilizador poder dispor de mais um serviço no seu smartphone, sendo capaz de fazer
toda a gestão do mesmo através do seu dispositivo em qualquer lado, evitando filas nas máquinas de
vendas automáticas e bilheteiras. Permite também reduzir o número de dispositivos de que o utilizador
tem que se fazer acompanhar, evitando perdas e esquecimentos.
Na figura 2.2 estão ilustrados os principais componentes de um smartphone com NFC. Neste
podemos ver que o controlador NFC está diretamente ligado ao Elemento Seguro (ES), permitindo
a comunicação com este de forma independente do processador do smartphone. No controlador NFC
é guardada uma tabela de encaminhamento, que dependendo do modo de operação do controlador,
15
fará com que as conexões sejam direcionadas para o ES ou para o CPU. Quando no modo de operação
de emulação de cartões, é sempre direcionada para o ES.
2.3.1 Elemento Seguro
O ES é usado para guardar de forma segura os dados que seriam guardados nos cartões de proxi-
midade. Existem várias opções que podem ser usadas como ES [16, 17]:
• Universal Integrated Circuit Card (UICC) - é um smartcard, geralmente com CPU integrado
que oferece os mesmos mecanismos de segurança apresentados em 2.2.2. Geralmente este é o
cartão SIM da operadora de telecomunicações móveis;
• Smart microSD - é um cartão microSD de armazenamento de dados, que possui embebido um
smartcard onde são guardados os dados das aplicações NFC;
• Elemento Seguro Embebido - é um circuito embebido na motherboard do dispositivo colocado
pelo fabricante durante o fabrico deste;
• Trusted Execution Environment (TEE) - é um ambiente de execução existente em alguns dis-
positivos, que corre paralelamente com o Sistema Operativo (SO), e que disponibiliza serviços de
segurança a esse ambiente. O TEE isola o seu hardware e software, desabilitando o acesso a
este por parte do SO do smartphone e suas aplicações, garantido a correta execução dos siste-
mas que dele dependem, mesmo quando o SO está comprometido. A especificação do standard
do TEE ainda não está concluída.
Sistemas de bilhética com smartphone NFC e ES
Existem vários sistemas que utilizam smartphones com NFC para guardar bilhetes eletrónicos, tais
como [18][19][20]. Ghìron [18] apresenta um sistema de bilhética para smartphones com NFC e ES.
Este sistema foi desenhado para utilização nos transportes públicos. Este permite carregar novos títulos
passando o telemóvel por um smart poster com uma tag NFC, que disponibiliza informação acerca de
uma paragem de autocarro, por exemplo. A aplicação no telemóvel, usa depois a informação recolhida
na tag para se ligar a um servidor e descarregar um bilhete eletrónico para o transporte que o utilizador
vai usar. O utilizador pode depois usar o seu telefone para validar o seu título de viagem, ou mesmo
para apresentar o titulo caso exista uma fiscalização.
W. Wu descreve também um sistema de bilhetes eletrónicos[19], em que a segurança dos dados
se baseia também na utilização de um ES. Este sistema foi desenhado para suportar vários tipos de
serviços de bilhética (por exemplo, cinema, transportes, espetáculos, etc) em apenas uma plataforma.
Desta forma as empresas provedoras de serviços podem assim disponibilizar a aquisição de bilhetes
eletrónicos para os seus serviços através desta plataforma. Os utilizadores podem então através de
uma aplicação para smartphones, pesquisar os vários serviços disponíveis, comprar os seus bilhetes e
usar o telemóvel para validar o acesso aos serviços.
16
Estes sistemas têm evidentes vantagens a nível de segurança, uma vez que se baseiam no uso de
hardware seguro para guardar os dados e executar transações. Desta forma, evita-se o acesso aos
dados por parte de malware, ou atacantes. O uso de um ES permite também a operação em modo de
baixa energia [21]. Uma vez que no modo de emulação de cartões, todas as operações se centram no
controlador NFC e no ES, quando o dispositivo é aproximado um leitor NFC, a energia transmitida do
leitor para o telemóvel é suficiente para alimentar o controlador e o ES. Assim o CPU do telemóvel não
precisa de estar em funcionamento para que este possa ser usado como cartão, funcionando mesmo
quando a bateria do mesmo se encontra descarregada. O uso de ES nos dois sistemas apresentados,
permite também que os dispositivos apenas tenham de ter uma conexão aos servidores durante o
momento da aquisição dos serviços, sendo que nos momentos seguintes, o processo de validação
dos bilhetes é feito num modelo completamente offline sendo possível a sua utilização mesmo em
ambientes sem ligação a uma rede sem-fios.
2.3.2 HCE
O HCE8 é um novo paradigma que permite aos programadores de aplicações para smartphones
Android, a criação de aplicações de pagamentos ou bilhética, que usem a interface NFC, sem terem
que depender da existência de um ES no dispositivo.
Este paradigma vem assim remover o custo de distribuir e instalar um ES em cada dispositivo dos
utilizadores que queiram poder usar o seu smartphone para efetuar transações seguras. Apesar de
todos os dispositivos usados como telemóvel requererem a instalação de um ES para poderem aceder
à rede Global System for Mobile Communications (GSM), a falta de acordos com os operadores, não
torna viável o uso do cartão SIM como ES das restantes aplicações NFC.
O HCE permite assim a representação de um cartão de proximidade apenas por software. Assim, o
modo de emulação de cartões da especificação do NFC, passa também a permitir o redirecionamento
da conexões para o CPU, em vez de redirecionar exclusivamente para o ES como vimos anteriormente.
As aplicações que antes recorriam ao ES para executar transações e guardar dados sensíveis, necessi-
tam agora de encontrar um substituto que consiga garantir todas as características a nível de segurança
de um ES. O principal candidato é a utilização de servidores externos, aos quais os dispositivos se li-
gam no momento em que as transações são executadas. Assim os servidores, podem ser usados para
guardar dados críticos e executar transações. Este modelo tem o custo de ser requerida uma conexão
à Internet.
Na área dos pagamentos, existem alguns serviços que usam HCE nas suas aplicações. Apesar
da desvantagem de os utilizadores necessitarem de uma ligação à Internet, o “time to market” destas
soluções é muito pequeno, permitindo uma rápida entrada e uma maior abrangência de utilizadores.
Um exemplo destes sistemas, é o SimplyTapp9. Este é uma plataforma aberta que permite a integração
de um sistema de pagamentos em aplicações Android. Este recorre ao HCE em conjunto com o NFC
para emular cartões crédito ou débito. O SimplyTapp não requer um ES em hardware, usando assim8Android - Host-based Card Emulation: https://developer.android.com/guide/topics/connectivity/nfc/hce.html9SimplyTapp - How it works: https://www.simplytapp.com/howitworks.html
17
o conceito de “ES remoto". Quando um utilizador faz uma compra com esta plataforma, os dados são
assim descarregados do servidor, e apresentados através do smartphone ao terminal de pagamentos.
A Cuscal10, uma provedora de serviços financeiros Australiana tem também uma solução baseada
em HCE para efetuar pagamentos com NFC. O projeto piloto destes tem o nome de “redi2Pay", e
permite aos clientes efetuar pagamentos através de um smartphone Android com suporte para HCE. O
sistema da Cuscal requer também uma ligação à Internet a fim de aceder aos dados do ES guardados
nos seus servidores. Neste projeto a Cuscal estima que através de uma rede de dados 4G, a latência
na transação aumente apenas na ordem dos 400ms.
A BellID apoia também o HCE no mercado dos pagamentos com smartphone com ES remoto. Na
referência [22], estes descrevem a sua solução totalmente compatível com os standards da EMV11. O
“Secure Element in the Cloud"disponibiliza uma API possível de integrar em aplicações para Android
com HCE, que se conecta aos servidores na cloud onde os ES’s estão alojados. Os servidores por sua
vez são responsáveis pela importação dos dados do cartão do utilizador.
Nesta solução de ES remoto, a BellID permite ainda algumas otimizações que permitem reduzir
substancialmente o tempo da transação. Para tornar tal possível estes recorrem a métodos como pré-
carregamento (mecanismo de cache) de dados não sensíveis no smartphone, de forma a reduzir o
número de mensagens enviadas para o servidor. Este sistema permite também a utilização da técnica
de “tokenization". Esta técnica consiste na criação de um novo cartão através do cartão original do
cliente. Este novo cartão será então denominado de token. Um token pode ser descrito como um
cartão de valor reduzido, utilizável num número limitado de transações e com montantes possivelmente
limitados também. Os tokens são criados de forma a que se consiga ligar os mesmos ao cartão que
estes representam, contudo através destes um atacante não consegue obter os dados do cartão ori-
ginal. Com estes mecanismos a BellID consegue otimizar os tempos de uma transação. É importante
referir que no caso dos pagamentos, apenas uma parte da transação é efetuada entre o terminal e
cartão. Nesta fase o terminal recolhe informação que identifica e autentica o cliente. Esta informação
é depois enviada para o banco do cliente onde é validada a transação. No caso dos transportes, geral-
mente, a transação é executada totalmente entre o terminal e o cartão. Assim os tempos relativos aqui
apresentados podem não se refletir nas aplicações de bilhética.
Pascal Urien propõe um sistema de ES’s remotos[23]. O sistema tem três componentes funda-
mentais: um cartão NFC com suporte para estabelecer canais Transport Layer Security (TLS)[24], um
smartphone/tablet Android com NFC e HCE, e um servidor de ES’s.
O servidor de ES’s tem instaladas várias grelhas com UICC. Este servidor permite a abertura de
canais seguros TLS, para as aplicações comunicarem com o ES respetivo. O smartphone com Android,
usado para emular cartões no modo HCE, necessita das chaves guardadas no smartcard NFC para
poder abrir um canal com o servidor. Após a criação do canal seguro com o ES, o smartphone pode
então ser apresentado a um terminal para efetuar um pagamento, que irá funcionar com uma ponte
entre o terminal e o ES.10Cuscal - Mobile Payments: https://www.cuscal.com.au/mobile-payments11EMV - é um standard global que define a interoperabilidade entre cartões de circuito integrado, e os terminais que com estes
interagem.
18
Os tempos medidos pelo autor relativamente à criação do canal seguro através do smartcard, são
de 10.7 s para uma sessão TLS completa e de 2.6 s para uma sessão abreviada. O autor comparou
também os tempos do sistema implementado a responder ao comando “Select(AID)", com as seguintes
soluções: (A) um ES no modo de contacto com um leitor, (B) um smartphone Android no modo HCE
sem ES, (C) um ES num leitor acedido pelo Android através de uma rede local e (D) um ES colocado
num servidor na Alemanha, enquanto o dispositivo Android se encontra na França separados por mais
de 1000 km e com Round Trip Time (RTT) de 50ms. Os resultados obtidos estão descritos na tabela 2.1.
Solução A B C DTempo (ms) 4 40 50 130
Tabela 2.1: Tempos medidos nos diferentes testes.
2.4 BLE
Com o lançamento do Bluetooth 4.0, a especificação de baixo consumo energético BLE, foi incluída.
O BLE foca-se na transferência de dados entre dispositivos com consumos energéticos bastante redu-
zidos. O baixo consumo energético tem como consequência menores taxas de transferência de dados,
quando comparado com o Bluetooth Clássico.
Na referência [25] o BLE é comparado com o NFC como seu possível substituto nos pagamentos.
O primeiro aspeto em que estes são comparados é a distância de operação. Enquanto que o NFC é
uma tecnologia de proximidade, os dispositivos têm de estar a uma distância não superior a aproxima-
damente 10 cm, o BLE permite distâncias de operação de dezenas de metros. As taxas de transferência
de dados no NFC, cerca de 424 kbps, são também superiores às do BLE que teoricamente consegue
apenas 300 kbps aproximadamente. O NFC e o BLE são ambos de baixo consumo energético. O pico
de uso de corrente é de aproximadamente 15mA, e de 1µA quando em standby. Relativamente à
segurança, ambos permitem cifrar dados com AES-128 bit.
O autor apresenta ainda três cenários de pagamentos através de um smartphone com BLE:
• Substituir NFC por BLE - Neste cenário os dados do cartão, são guardados num ES no smart-
phone do cliente. Assim o dispositivo liga-se através de BLE ao terminal de pagamentos, que
está diretamente ligado a uma rede de pagamentos. Este cenário é uma cópia do sistema de
pagamentos por proximidade da EMV, uma vez que o cartão onde se executa a transação está
presente, a única diferença é que a comunicação é feita sob uma conexão BLE em vez de NFC.
• “PayPal Beacon Hands Free" - Este cenário é baseado no modelo que a PayPal apresentou em
201312. Neste modelo o smartphone não necessita de um ES, em vez disso, os dados do cartão
são guardados de forma segura na cloud. No momento de efetuar um pagamento, o dispositivo
conecta-se ao terminal de pagamentos por BLE. O terminal está ligado à cloud, onde este vai
executar toda a transação, usando um token descarregado por BLE do dispositivo do cliente.
12PayPal Beacon: Hands-Free Payments https://www.youtube.com/watch?v=g8h_i8qv1FY
19
• “Take and Shake" - Nesta versão o smartphone necessita de um ES, onde são guardados os
dados do cartão, e são efetuadas as transações. Neste modelo o cliente não interage com o ven-
dedor, sendo ele próprio que faz a conta dos produtos que pretende adquirir, e automaticamente
faz o pagamento antes de sair da loja. No momento do pagamento, o dispositivo do cliente liga-se
ao terminal de pagamentos, a partir de qualquer ponto na loja e efetua o pagamento, sem ser
necessária a interação com o vendedor.
2.5 Conclusões
Durante esta secção foram apresentadas as tecnologias atualmente usadas nos sistemas de bi-
lhética, como os códigos de barras, os smartcards NFC, e os telemóveis com NFC. Das soluções
estudadas pode-se concluir que os bilhetes em códigos de barras são bastante usados, e na maior
parte dos casos conseguem cumprir todos os requisitos, sendo principalmente aplicados em sistemas
nos caminhos de ferro e transportes de longo curso, que têm paragens e horários bem definidos, que
permitem facilmente invalidar um bilhete com base nestas variáveis. Também a múltipla validação in-
devida, de um título, tende a ser fácil de detetar devido ao reduzido número de validadores, e que
geralmente podem partilhar uma base-de-dados com os bilhetes bilhetes já utilizados. Já para os sis-
temas urbanos em que geralmente os bilhetes não são exclusivos para um determinado local e hora,
torna-se mais difícil utilizar bilhetes em códigos de barras. Nestes casos os sistemas com cartões de
proximidade são uma melhor escolha, uma vez que os mecanismos de segurança que estes disponibili-
zam, permitem a validadores independentes descontar os títulos de viagens disponíveis num cartão, de
forma que o utilizador não utilize mais do que uma vez o título adquirido. Da mesma forma se aplicam
os smartphones com NFC e ES, uma vez que beneficiam das mesmas vantagens.
Adicionalmente foram apresentadas duas tecnologias recentes, o HCE e o BLE, que apesar de já
estarem a ser aplicadas, ou em fase de desenvolvimento no caso do BLE, na área do pagamentos
eletrónicos, ainda não existem documentados sistemas de bilhética que os usem, mas que permitem
criar sistemas mais simples e práticos tanto para os operadores como para os clientes.
Na tabela 2.2 estão resumidas as diferentes tecnologias estudadas. Nesta são comparadas as
principais características de segurança de cada uma, assim como as suas vantagens e desvantagens.
20
Segurança Vantagens Desvantagens
Códigos deBarras
Dados guardados no tele-móvel, podendo estar ex-postos a ataques. De-pende da cifra e assina-tura dos dados por partedas bilheteiras e valida-dores.
Elevado número de dis-positivos com capacidadede armazenar e apresen-tar os códigos de barras.
Não suporta escritas,necessitando de servalidado num servidor(ou validador) centralpara evitar validaçõesduplicadas. Difícil evitarcópias dos bilhetes.
Smartcards
Cartões de memória:Não têm mecanismospróprios de segurança.Segurança depende dacifra dos dados e criaçãode certificados. Cartõescom microprocessador:Garantem a segurançados dados com um ele-vado nível de confiança,através de mecanismospróprios e chaves decifra simétrica por siguardadas.
Permite guardar váriosbilhetes eletrónicos ad-quiridos através de má-quinas de venda auto-mática. Processo devenda/validação comple-tamente Offline.
Utilizador necessita de re-correr às máquinas devenda automática paraverificar o número de vi-agens disponível. Car-tões têm um custo adici-onal para os clientes.
Smartphonesc/ ES
Garantias de segurançaidêntica à dos cartõescom microprocessador.
Clientes podem utilizar ossmartphones para adqui-rir novos títulos de via-gem e consultar os aindadisponíveis. Funcionamesmo com o smartpho-nes desligado (sem bate-ria).
Poucos smartphones têmdisponíveis ES disponí-veis a aplicações de ter-ceiros. Por razões desegurança e comerciais,os operadores de tele-comunicações não permi-tem a utilização dos car-tões SIM nestas aplica-ções. Custos adicionaisna distribuição de ES’spelos utilizadores.
Smartphonesc/ HCE
Dados guardados no tele-móvel, podendo estar ex-postos a ataques. De-pende da cifra e assina-tura dos dados por partedas bilheteiras e valida-dores.
Reduzidos custos deprodução e distribuiçãode aplicações. “Time-to-market” inferior asoluções baseadas emES. Elevado númerode dispositivos compa-tíveis, com tendência aaumentar.
As principais soluçõesbaseadas nesta tec-nologia são total ouparcialmente dependen-tes da interação com umserviço de Cloud Online.
Tabela 2.2: Comparação das diferentes tecnologias estudadas em relação às características de segurança, vanta-gens e desvantagens de cada uma.
21
22
3Arquitetura e Protocolos da Solução
Proposta
Contents3.1 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3 Protocolos de Interação dos Elementos da Arquitetura . . . . . . . . . . . . . . . . . 283.4 Validação Offline Sem Alteração dos Validadores . . . . . . . . . . . . . . . . . . . . 313.5 Validação Online Sem Alteração dos Validadores . . . . . . . . . . . . . . . . . . . . 353.6 Validação Offline Com Alteração dos Validadores . . . . . . . . . . . . . . . . . . . . 373.7 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
23
A criação de sistemas de bilhética para smartphone encontram as maiores barreiras nos aspetos
de segurança. As soluções baseadas no uso de um Elemento Seguro (ES) colocado no dispositivo do
utilizador, são as que mais garantias de segurança oferecem quer aos utilizadores, quer aos provedores
de serviços. Contudo estas soluções têm tido dificuldade em entrar em grande escala no mercado: quer
por falta de opções nos dispositivos atuais para adicionar um ES, quer pelas barreiras impostas pelos
operadores de redes móveis que não permitem a utilização, como ES para outros serviços, dos cartões
SIM presentes nos telemóveis.
Na secção anterior foram apresentadas algumas das soluções utilizadas atualmente na área dos
bilhetes eletrónicos, assim como algumas soluções usadas nos pagamentos bancários cujas arquite-
turas podem ser adaptadas à bilhética. Nesta secção, é apresentada uma solução baseada na adição
de uma componente na cloud responsável por substituir o ES. Esta componente será responsável por
guardar ES virtuais (daqui em diante referido como Cartão Virtual (CV)), efetuar carregamentos e até
detetar possíveis fraudes.
3.1 Casos de Uso
Antes de especificar a arquitetura proposta para a solução serão descritos os casos de uso para
os quais a solução foi desenhada. Os casos de uso apresentados são baseados nos apresentados
na secção 2.2.3, onde são apresentados os casos de uso de um sistema de bilhética com cartões
de proximidade. Estes serão devidamente adaptados para a solução com smartphone aqui proposta.
Em todos os casos de uso é pressuposto que o utilizador possua um smartphone com as caracterís-
ticas apresentadas na secção 3.2.1, e tenha uma aplicação de bilhética instalada com a solução aqui
descrita. Os casos de uso são os seguintes:
• Registo - Este caso de uso é equivalente à aquisição de um cartão de proximidade, sendo que
nestes pode haver ou não um registo de cliente. Neste caso o cliente utiliza a aplicação de
bilhética no seu smartphone para iniciar o processo de registo. O utilizador deve fornecer algumas
informações pessoais, e definir as credenciais de acesso que lhe permitem autenticar-se perante
o sistema nos cenários restantes. Após este processo o utilizador deve estar apto para começar
a adquirir bilhetes e iniciar viagem. Este processo é feito totalmente online pelo que o utilizador
deve ter uma ligação à Internet durante todo o processo.
• Carregamento - O cliente utiliza a aplicação de bilhética no seu smartphone para adquirir títulos
de viagem. O cliente deve fornecer detalhes sobre as viagens que pretende realizar. Através de
um serviço de pagamento online o cliente deverá efetuar o pagamento das viagens adquiridas.
No caso de uso em que a validação (especificado de seguida) é executada offline, será também
descarregados para o smartphone do utilizador um CV com os bilhetes adquiridos.
• Validação:
– Validação Offline: Neste caso a transação é executada totalmente offline, pelo que o CV
usado tem de ser guardado no Dispositivo Móvel (DM). No momento da validação, o dispo-
24
sitivo, não necessita de ter uma ligação à Internet, contudo o dispositivo necessita de estar
ligado. Os pressupostos tomados são, para além dos já definidos anteriormente, que o cli-
ente tenha concluído os cenários anteriores, e que no momento da validação o cliente tenho
um CV guardado no seu smarthpone.
– Validação Online: Neste caso a transação é completamente executada online. Quando o
cliente apresenta o DM ao validador, as mensagens recebidas pelo primeiro são encaminha-
das para a cloud onde o CV de cada utilizador é guardado. Neste cenário os pressupostos
são, para além dos já definidos anteriormente, que o cliente tenha concluído os cenários
anteriores, e no momento da validação tenha uma ligação à Internet.
Após a validação estar concluída com sucesso, o cliente tem acesso aos serviços de transporte
e pode iniciar a sua viagem. No final da viagem pode ser necessário validar a sua saída. Neste
caso os cenários de validação repetem-se.
• Fiscalização - O caso de uso de fiscalização (situação em que um fiscal pertencente ao operador
de transporte, requisita o título de viagem de um passageiro) processa-se de forma idêntica à
validação.
3.2 Arquitetura
Nesta secção será apresentada a arquitetura da solução aqui proposta, na qual o smartphone,
ou DM, é o principal elemento. É através deste que o utilizador pode executar as funcionalidades
que, nos equivalentes sistemas com cartões de proximidade, obrigam à utilização de equipamentos
específicos adicionais, como por exemplo as bilheteiras. Consequentemente será apresentado um
novo componente, o Serviço Cloud (SC), onde serão disponibilizadas as respetivas funcionalidades
para o smartphone. Com a adição deste servidor permite-se que o smartphone possa em qualquer
lugar, com uma ligação à internet disponível, usar funcionalidades que até então estavam limitadas a
bilheteiras às quais os clientes se teriam de deslocar. Outras componentes serão também utilizadas
nesta arquitetura, contudo estas já existem nos sistemas atuais com cartões de proximidade, e devem
ser integradas sem sofrer alterações, o que permitirá reduzir o impacto desta solução nas soluções
atuais.
Desta forma é então possível especificar os componentes do sistema. Na figura 3.1 estão represen-
tadas num diagrama os cinco principais componentes, da solução, e os dados trocados entre cada. Os
componentes do sistema são os seguintes:
• SAM Mestre: O Secure Application Module (SAM) Mestre é a componente que possui todas as
chaves de SAM, e cuja geração tem de ser feita através de uma chave mestra. Este componente
é responsável pela distribuição de chaves pelos restantes componentes, o que deve acontecer
apenas uma vez no arranque do sistema. Esta componente será utilizada tal como já existe nos
sistemas com cartões de proximidade atuais.
25
Figura 3.1: Diferentes componentes do sistema, e interações entre os mesmos.
• Dispositivo de Fiscalização: O dispositivo de fiscalização é um componente utilizado por fiscais,
durante uma viagem, que permite verificar se um determinado cliente utilizou um título de viagem
válido para aquele percurso. Esta componente não deverá sofrer qualquer alteração, desde que
seja capaz de comunicar com o DM.
• SC: O SC é a componente central do sistema, dado que interage diretamente com os restantes
componentes. Neste serão implementadas as funcionalidades de registo de novos clientes e o
carregamento de cartões.
Este deverá difundir periodicamente um catálogo de produtos para os validadores e fiscalizadores,
de forma que estes reconheçam todos os produtos carregados nos cartões. Juntamente com o
catálogo será também enviada uma lista “negra” onde constarão os identificadores de cartões
que estejam permanente ou temporariamente impedidos de utilizar os serviços de transporte.
Dos validadores este receberá o conjunto das transações efetuadas durante o serviço. Estas
transações serão utilizadas, num protocolo explicado mais à frente neste capítulo, que permitirá
calcular receitas, e até detetar casos de fraude caso o número de validações de um determinado
cartão não corresponda com o que lhe foi carregado pelo sistema. Neste caso o cartão seria então
adicionado à lista “negra”. Estas funcionalidades existem atualmente nos sistemas de bilhética,
contudo por simplicidade não serão integrados neste trabalho.
• Validador: O validador é o componente responsável pela verificação da validade de um título de
viagem para um determinado serviço ou percurso. A validação é executada no momento em que
o cliente acede aos serviço de transporte e registará a entrada do passageiro e, caso se aplique,
efetuará o respetivo desconto da viagem efetuada. Para tal este deverá interagir com o DM do
cliente para aceder aos dados do seus títulos carregados. Esta componente não deverá sofrer
26
Figura 3.2: Arquitetura da solução proposta.
qualquer alteração, desde que seja capaz de comunicar com o DM.
• Dispositivo Móvel: O DM é o smartphone do cliente. Este será utilizado para executar todos os
casos de uso, pelo que terá de interagir especificamente com o SC, validadores e fiscalizadores.
As interações com o SC podem ser no momento do registo, que acontecerá apenas uma vez para
cada cliente, no carregamento, e durante a validação online.
Na figura 3.2 estão representados os três componentes da arquitetura, cujas interações serão efeti-
vamente implementadas neste trabalho, onde se representa as comunicações entre estes. O SC, que
na figura é identificado como servidor, deverá expor uma camada de serviços web, que permitirão o
acesso à camada da lógica de negócio, e base-de-dados. Esta camada de serviços web será ace-
dida através de canais Transmition Control Protocol (TCP)/Internet Protocol (IP) pelos validadores e
smartphone. A ligação entre os validadores e o servidor, identificada na figura por uma linha tracejada,
está limitada a um determinado período ou local, no qual o validador consegue uma ligação o serviço
para receber as devidas atualizações e comunicar as transações. Normalmente o validador tem acesso
ao servidor no final do dia de operações, ou, por exemplo, quando um autocarro regressa à garagem.
Nesta arquitetura considera-se que a ligação entre o smartphone e o servidor deverá existir sempre
que o cliente pretenda utilizar alguma das funcionalidades executadas no servidor. Esta ligação pode
ser estabelecida através de qualquer rede móvel 3G ou 4G, ou outra qualquer rede sem fios.
A comunicação entre o validador e o smartphone é estabelecida através de Near Field Communica-
tion (NFC), e acontecerá sempre que o smartphone seja aproximado do validador.
3.2.1 Requisitos de Sistema
Apesar de todos os componentes do sistema terem requisitos que devem ser definidos, nesta fase
ainda não existem dados que permitam especificar os requisitos de hardware e software de todos os
27
componentes, à excepção do DM e dos Validadores.
DM
De acordo com os objetivos e requisitos definidos no capítulo 1, os DM’s com sistema operativo
Android precisam de ter suporte para comunicações por NFC, e ter instalada a versão de Android 4.4
ou posterior, com suporte para Host-based Card Emulation (HCE). Estes deverão também ter acesso
à internet para a execução de alguns protocolos.
Validador
Os validadores devem sofrer as menores alterações possíveis, contudo face à limitação de alguns
DM’s Android que não emulam cartões que implementem o ISO/IEC 14443-4 Type B1, os validadores
que não tenham suporte para ISO/IEC 14443-3 Type A deverão ser atualizados.
3.3 Protocolos de Interação dos Elementos da Arquitetura
Nesta secção serão explicados os vários protocolos da integração dos componentes do sistema. O
nível de detalhe com que estes são apresentados deve-se à necessidade de ter sistematizado à partida
a comunicação entre estes, de forma a identificar o fluxo de dados e de que formas estes devem ser
protegidos.
3.3.1 Inicialização
O protocolo de inicialização é onde todo o sistema é configurado. Este processo tem início no SAM
Mestre, e este dá início à geração das chaves de SAM que serão usadas em todo o sistema. Estas
chaves devem depois ser distribuídas pelas restantes componentes do sistema (Validadores, Serviço
cloud e dispositivos de fiscalização). Terminada a fase de configuração do sistema, este deve ficar
pronto a operar.
3.3.2 Registo de Clientes
Após a configuração do sistema estar terminada, um cliente pode então começar o protocolo de
registo. Este protocolo é essencial para um cliente poder ter acesso a todo o sistema e ser capaz de
utilizar o seu dispositivo para aceder aos serviços de transportes. Este protocolo acontece entre o DM
do cliente e o SC. Para tal o dispositivo deve estar ligado a uma rede com acesso à Internet.
Na figura 3.3 está ilustrado o protocolo de registo descrito de seguida:
1. O protocolo de registo começa com a abertura de um canal seguro TLS, entre o DM do cliente, e
o SC. Para simplificar, as restantes mensagens do protocolo de abertura do canal foram omitidas.
2. De seguida o DM do cliente pede à cloud para iniciar um novo processo de registo.
1Host-based Card Emulation - Supported NFC Cards and Protocols: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
28
Figura 3.3: Protocolo usado para um cliente proceder ao registo no sistema.
3. São pedidos alguns dados pessoais ao cliente, assim como para definir uma password para ace-
der à sua conta.
4. Juntamente com a password e os dados pessoais, é também enviado o identificador do DM. Caso
o cliente troque de DM é necessário que este associe o novo dispositivo à conta já existente.
5. De seguida o serviço executa três tarefas: atribui um identificador, de um conjunto de identifica-
dores pré-alocado; transforma a password do cliente usando um algoritmo Password-based Key
Derivation Function 2 (PBKDF2)[26]; o identificador gerado, assim como o identificador do DM e
a transformação da password são guardados na base de dados de clientes.
6. O SC mede o valor de Round Trip Time (RTT) entre si e o DM do cliente. Este valor será usado
mais tarde em outros protocolos.
7. O SC inicia o processo de criação do CV personalizado para o cliente.
8. O serviço guarda numa base de dados o valor de RTT lido anteriormente, assim como CV gerado.
9. Por fim é retornada ao cliente a confirmação de registo, juntamente com o identificador que o
utilizador terá de utilizar para se autenticar.
3.3.3 Autenticação
Após o registo, cada vez que o cliente pretenda aceder ao SC terá que se autenticar perante este. A
autenticação faz parte de alguns dos protocolos que serão apresentados de seguida, assim, o protocolo
a ser usado será descrito de forma independente dos restantes. Durante a execução deste protocolo
será aberto um canal Transport Layer Security (TLS), que deverá ser utilizado nos protocolos que
dependam deste protocolo de autenticação.
29
Figura 3.4: Protocolo usado para autenticar um cliente perante o SC.
Neste protocolo o cliente tem de inserir uma password que o identifica perante o sistema, juntamente
com outros dados recolhidos no DM e também informação do cliente. Os passos do protocolo, ilustrados
na figura 3.4, são os seguintes:
1. O protocolo começa com o estabelecimento de um canal seguro TLS, entre o DM do cliente e o
SC. Este canal será depois usado pelos restantes protocolos que necessitem de autenticação do
cliente, pelo que deverá ser mantido aberto enquanto existam outros protocolos para executar.
2. Após a abertura do canal, o cliente insere a password previamente definida durante o registo, e
submete para a cloud. Esta mensagem para além da password, tem de incluir o identificador do
DM e o identificador do cliente.
3. Do lado da cloud, a password recebida é transformada com o mesmo algoritmo usado no registo.
4. De seguida, o sistema procura na base de dados de clientes, um registo com o mesmo identifica-
dor de DM e cliente, e que a transformação da password seja igual.
5. Se todos os dados enviados pelo cliente coincidirem com os dados guardados na base de dados,
o processo de autenticação é concluído com sucesso, e o cliente é informado.
3.3.4 Carregamento de CV’s
Concluído o processo de registo, um cliente pode começar a usar o sistema de CV’s. Contudo, dado
que inicialmente o CV não tem nenhum valor carregado, para que cartão possa ser usado, o cliente tem
que proceder ao seu carregamento. Para simplificar este processo, é admitido que o serviço suporta
apenas o carregamento de dinheiro no CV, que será descontado cada vez que o serviço seja utilizado.
Os pagamentos serão garantidos por um serviço externo (como PayPal ou Visa), para o qual os clientes
serão encaminhados para efetuar o pagamento.
O protocolo de carregamento, ilustrado na figura 3.5, é o seguinte:
1. O protocolo de carregamento começa com o processo de autenticação entre o DM do cliente e a
cloud, descrito na secção 3.3.3.
30
Figura 3.5: Protocolo usado para efetuar um carregamento no CV.
2. Após a conclusão do protocolo de autenticação, é perguntado ao cliente a quantia que quer car-
regar no seu CV. O cliente insere o montante, e uma mensagem é enviada para o SC, para dar
início ao processo de carregamento do montante indicado pelo cliente.
3. O SC mede o RTT com o DM do cliente. Este valor será usado mais tarde em outros protocolos.
4. De seguida, o SC inicia a interação com o serviço externo de pagamentos, estabelecendo uma
ligação autenticada entre ambos.
5. O SC começa o processo de pagamento, informando o serviço de pagamentos do montante a ser
pago pelo cliente.
6. O SC reencaminha de seguida a ligação do serviço de pagamentos para o DM, a fim de o cliente
efetuar o pagamento.
7. O cliente efetua o pagamento, inserindo por exemplo os dados do seu cartão de crédito.
8. Após terminado o processo de pagamento, o serviço de pagamentos envia a confirmação do
pagamento por parte do cliente para o SC.
9. O SC dá início ao processo de carregamento, adicionando ao CV o montante pago pelo cliente.
É também guardado o valor de RTT medido anteriormente.
10. Por fim, o cliente é notificado da conclusão da operação de carregamento.
3.4 Validação Offline Sem Alteração dos Validadores
O primeiro protocolo de validação apresentado, assenta no cenário em que no momento da valida-
ção ambos os intervenientes não necessitam de estar ligados a um rede com acesso à Internet. De
31
Figura 3.6: Protocolo usado para carregar um token no DM.
forma a aumentar a segurança da solução, são usados tokens. Como já dito anteriormente, um token é
um CV de baixo valor, e com validade temporal limitada. Desta forma, mesmo que um atacante ganhe
acesso a um token, só terá acesso ao serviço de transportes, durante um período limitado de tempo,
caso não tenham ainda expirado.
Nesta solução, são apresentados três sub-protocolos distintos: carregamento de tokens, validação
de tokens, e o protocolo de saída/fiscalização. Adicionalmente é também definido o protocolo de recon-
ciliação.
3.4.1 Carregamento de tokens
O protocolo de carregamento de tokens é ilustrado na figura 3.6. Este protocolo pode ser executado
até Tload horas antes da execução do sub-protocolo de validação. A variável Tload, deve ser definida
junto do operador, e deve ter em conta tanto a funcionalidade do sistema, e o risco para o negócio que
este representa. O sub-protocolo de carregamento de tokens, é o seguinte:
1. O cliente executa, no seu DM, o protocolo de autenticação descrito na secção 3.3.3.
2. O DM envia um pedido ao SC para carregar um token.
3. O SC, antes de carregar o token, valida se o cliente tem saldo suficiente para executar a operação.
O SC valida também neste passo se o cliente não se encontra em lista negra.
4. Caso se verifiquem as condições anteriores, um token para uma utilização, e com validade tem-
poral consoante a variável Tload, é gerado. Este token é depois cifrado com a transformação da
password do cliente.
5. O SC guarda o token no base de dados dos clientes.
6. O token cifrado é enviado para o DM do cliente.
3.4.2 Validação de token
Após o carregamento de um token no DM do cliente, este encontra-se em condições de utilizar
o serviço de transportes. Neste cenário, a solução apresentada tem também como objetivo, não ser
32
Figura 3.7: Protocolo usado para validar um token junto de um validador automático.
necessário modificar o software dos validadores instalados atualmente. Desta forma, o sub-protocolo
está dependente dos protocolos específicos da tecnologia.
O passos do protocolo, ilustrados na figura 3.7, são os seguintes:
1. Antes da interação entre o DM e o validador começar, o cliente tem de inserir a sua password.
Este processo terá de acontecer até X minutos antes, do momento em que o cliente pretende
utilizar o token. Depois de inserida a password, o DM aplica o algoritmo PBKDF2 à password
a fim de obter a mesma transformação guardada no SC. A restrição temporal imposta, para a
digitação da password, tem como objetivo reduzir a janela temporal que um atacante tem para
roubar um token.
2. O DM usa então a transformação da password produzida, para decifrar o token recebido durante
o sub-protocolo de carregamento. A partir deste momento, o token está decifrado e pronto a ser
usado em qualquer sub-protocolo que o requeira.
3. O cliente aproxima o seu DM do validador, para começar o protocolo de validação específico da
tecnologia.
4. Neste passo, é executado o protocolo específico da tecnologia usada.
5. O validador notifica o cliente, através de uma mensagem, sinal luminoso ou sonoro, ou no caso
de uma rede de transportes fechada, a porta é aberta.
3.4.3 Protocolo de saída/fiscalização
O protocolo de saída, usado geralmente em redes de transportes fechadas, é usado para dar como
concluída a viagem e abrir a porta de saída. Este protocolo segue o protocolo descrito para a validação
na secção 3.4.2, e usa o token já decifrado anteriormente.
33
Figura 3.8: Protocolo usado no processo de reconciliação entre os validadores e o SC.
3.4.4 Reconciliação
A fase de reconciliação, existente nos sistemas atuais, faz parte de um protocolo em que os valida-
dores e um sistema central se sincronizam. Assim o sistema central fica com conhecimento de todas
as transações efetuadas durante o dia. O sistema central usa então os dados recolhidos para detetar
fraudes, e possíveis vítimas de ataques. No caso de deteção de problemas com um determinado cli-
ente, o cartão que lhe está associado, é colocado numa lista negra, que é depois distribuída por todos
os validadores, impossibilitando a sua utilização enquanto estiver listado.
Uma vez que processo de validação da solução apresentada, é efetuado offline, este protocolo
tem de ser expandido para o SC, e será utilizado para detetar tokens que foram emitidos e não foram
utilizados, ou tokens que foram indevidamente utilizados por um atacante.
O protocolo de reconciliação está ilustrado na figura 3.8, e tem os seguintes passos:
1. O protocolo de reconciliação, é iniciado pelos validadores quando estes, periodicamente (geral-
mente no final de cada dia), enviam para o SC os dados das transações efetuadas durante o
dia.
2. De seguida o SC analisa os dados recebidos e verifica a existência de anomalias. Caso alguma
anomalia seja detetada e, usando regras de negócio específicas, for classificada como fraudu-
lenta, o cliente correspondente é adicionado à lista negra.
3. Caso algum cliente tenha que ser reembolsado, o sistema atualiza o saldo do CV correspondente.
4. No final da reconciliação, o sistema atualiza o registo de eventos, com todas as operações efetu-
adas.
5. Após todas as transações enviadas pelos validadores serem analisadas, e a lista negra atualizada,
o SC envia para todos os validadores a lista negra atualizada.
34
3.5 Validação Online Sem Alteração dos Validadores
Como alternativa à solução anterior, e na tentativa de eliminar os riscos provenientes de guardar o
token decifrado durante um curto período antes da sua utilização, é apresentada uma solução em que o
protocolo de validação é executado online. No SC são emulados os cartões, executando as operações
da transação num ambiente seguro e controlado.
Nesta solução a ideia principal, é ligar o validador e o SC onde se encontram os CV’s. Para tal o DM
do cliente, é usado para possibilitar a comunicação entre eles. Esta solução enquadra-se no cenário
online, descrito anteriormente.
Dado que não existe transferência de tokens para os DM’s, os sub-protocolos de carregamento de
tokens, e de reconciliação não se aplicam.
3.5.1 Protocolo de Validação
O protocolo de validação para este cenário, detalhado na figura 3.9, tem os seguintes passos:
1. A validação começa com a execução do protocolo de autenticação descrito na secção 3.3.3.
2. Após a autenticação ser concluída com sucesso, o SC carrega os dados do cliente.
3. O cliente aproxima o seu DM do validador, para começar o protocolo de validação específico da
tecnologia.
4. Este passo representa o início do envio de cada mensagem, do validador para o SC, do protocolo
de validação específico da tecnologia. Neste passo, é também verificado se o temporizador de
comunicação com o validador está ativo, e em caso afirmativo este é parado.
5. As mensagens do validador são recebidas pelo DM do cliente, e são encaminhadas para o SC.
O SC executa o pedido no CV associado ao cliente. Se no passo anterior, tiver sido gerado um
valor no temporizador de comunicação com o validador, o valor deste é também enviado para o
SC. Do lado do validador, é verificado se o temporizador que contabiliza o tempo entre pedidos
do validador está ativo, e em caso afirmativo este é parado, e o valor guardado, juntamente com
o valor incluído na mensagem (caso este exista).
6. A resposta produzida no CV é enviada de volta para o DM. Neste passo é iniciado o temporizador
que contabiliza o tempo entre pedidos do validador.
7. Depois de enviada a resposta para o DM, o SC inicia o processo de comparação dos tempos
recolhidos conforme determinadas métricas. Neste processo, caso sejam detetados tempos dís-
pares dos guardados no histórico de transações, a transação é abortada pois pode significar que
o DM do cliente está a ser vítima de um ataque. As métricas usadas, são as seguintes:
• A primeira métrica usa o tempo passado entre uma resposta enviada pelo SC para o DM e a
receção de uma nova mensagem.
35
T1 = representa o tempo passado entre o envio de uma resposta, e a receção de um novo
comando
T’1 = média dos tempos guardados no histórico de transações
ξ(T1) = margem de erro do T1
if T1 > T’1 + ξ(T1), transação é abortada
• A segunda métrica usa o tempo de comunicação entre o DM e o validador, e é medido entre
uma resposta entregue ao validador, e a receção do próximo comando.
T2 = representa o tempo que um validador demora a emitir um novo comando depois de
recebida uma resposta
T’2 = média dos tempos guardados no histórico de transações
ξ(T2) = margem de erro do T2
if T2 > T’2 + ξ(T2), transação é abortada
• A última métrica usa os valores das últimas métricas, para calcular o RTT e comparar com
os valores de RTT guardados nos protocolos definidos anteriormente.
RTT = T1 - T2 RTT’ = média dos tempos guardados no histórico de transações
ξ(RTT) = margem de erro do RTT
if RTT > RTT’ + ξ(RTT), transação é abortada
8. O DM, depois de receber a resposta do SC, encaminha a resposta para o validador. Neste passo
é iniciado o temporizador de comunicação com o validador. Os passos 4 a 8 são repetidos até a
validação estar concluída.
9. No final da validação, o validador notifica o cliente, através de uma mensagem, sinal luminoso ou
sonoro, e no caso de uma rede de transportes fechada, a porta é aberta.
10. Quando o validador dá por terminada a transação junto do DM do cliente, este notifica o SC do
final da transação, e este guarda o estado atual do CV na base de dados, dando como concluída
a validação. É nesta fase que o SC dá inicio ao protocolo de reconciliação para a transação
efetuada.
Este protocolo de validação tem a evidente desvantagem do tempo que uma mensagem do validador
demora a ser executada no CV, uma vez que tem de ser enviada para o SC através da Internet. Uma
possível forma de otimizar este protocolo, pode ser através de uma cache, onde seriam guardadas
partes do CV suficientes para responder a algumas mensagens do validador. Os dados guardados na
cache seriam apenas aqueles tivessem a garantia que, mesmo que um atacante lhes tivesse acesso,
não comprometeriam o utilizador ou o sistema.
36
Figura 3.9: Protocolo de validação online.
3.5.2 Protocolo de saída/fiscalização
Os protocolos de saída e de fiscalização são executados da mesma forma que o protocolo de vali-
dação descrito na secção anterior.
3.6 Validação Offline Com Alteração dos Validadores
Com a alteração dos validadores automáticos, expandem-se as possibilidades de diferentes arqui-
teturas, com melhorias tanto a nível de utilização como de segurança do sistema.
Tal como na solução apresentada anteriormente na secção 3.4, a solução ideal reside na opção em
que o utilizador não necessita de ter ligação à Internet para utilizar o serviço. De forma a mitigar os
riscos que uma solução offline esta secção apresenta uma alternativa ao protocolo anterior, em que um
validador é capaz de autenticar o cliente.
Esta solução divide-se em três sub-protocolos, compostos pelo protocolo de carregamento de to-
kens, o protocolo de validação e o protocolo de saída/fiscalização.
3.6.1 Carregamento de tokens
O protocolo de carregamento de tokens é ilustrado na figura 3.10. Este protocolo pode ser executado
até Tload horas antes da execução do sub-protocolo de validação. Tal como dito anteriormente, variável
Tload deve ser definida junto do operador, e deve ter em conta tanto a funcionalidade do sistema, e o
risco para o negócio que este representa. O sub-protocolo de carregamento de tokens, é o seguinte:
1. O cliente executa, no seu DM, o protocolo de autenticação descrito na secção 3.3.3.
37
2. Após o autenticação e estabelecimento do canal seguro, o cliente interage com a aplicação, a fim
de escolher o serviço de transportes que este pretende utilizar. Se o serviço for de rede fechada,
a aplicação pede para o utilizador introduzir também informação sobre a estação ou zona em que
este vai dar entrada.
3. O DM do cliente envia de seguida um pedido de token, juntamente com a informação introduzida
pelo cliente.
4. Do lado do SC, o serviço acede ao CV do cliente criado no processo de registo. O SC verifica se
o CV tem saldo suficiente para gerar o token, e caso tenha saldo suficiente, autoriza a criação do
token. O SC verifica também neste passo se o cliente se encontra em lista negra.
5. O token é então criado com informação sobre a rede de transportes onde deve ser utilizado, assim
como a estação caso tenha sido definida, e a validade do token.
6. Neste passo é gerada uma mensagem A. Esta mensagem é composta por um número aleatório
R, e a transformação da password do utilizador Tpwd. Esta mensagem é cifrada com uma chave
Kv, de forma que A = R + Tpwd Kv . A chave Kv, faz parte de um conjunto de chaves gerado na
fase de inicialização, em que cada chave pode ser específica de um conjunto de validadores de
uma estação, trajeto, ou operadora. Permitindo, por exemplo, que a mensagem seja cifrada com
uma chave, que apenas os validadores correspondentes à estação ou trajeto especificado pelo
cliente anteriomente, têm acesso.
7. De seguida o SC cria a mensagem B. Esta mensagem é composta por TokenKv , e é cifrada
com o valor R, produzido no passo anterior, e a transformação da password do utilizador, Tpwd, de
forma que B = TokenKvR⊕Tpwd . O objetivo é, durante a validação, enviar o TokenKv na totalidade
para o validador.
O token cifrado, é depois cifrado com R⊕Tpwd de forma a garantir que só o utilizador para o qual
o token foi emitido, e na presença de um validador com a chave Kv, o consegue decifrar.
8. Após a geração do token, e a criação das mensagens A e B, o SC regista o token gerado no
registo de eventos do cliente.
9. O protocolo termina com o envio das mensagens A e B para o DM do cliente. O cliente recebe
portanto: A + B = R + Tpwd Kv + TokenKvR⊕Tpwd .
3.6.2 Protocolo de Validação
Depois de terminado o protocolo de carregamento de tokens, o utilizador pode começar o protocolo
de validação ilustrado na figura 3.11:
1. Antes da interação entre o DM e o validador começar, o cliente tem de inserir a sua password.
Este processo terá de acontecer até X minutos antes, do momento em que o cliente pretende
utilizar o token. O DM, tem de aplicar à password a mesma transformação aplicada pelo SC
durante o protocolo de registo.
38
Figura 3.10: Protocolo de carregamento de token.
2. O cliente aproxima o seu DM do validador, para começar o protocolo de validação.
3. Na primeira interação entre o DM e o validador, o DM envia a mensagem A, gerada no protocolo
de carregamento de tokens.
4. O validador decifra a mensagem A, com a chave Kv, obtendo o valor aleatório R e a transformação
da password do utilizador, Tpwd.
5. O validador gera um número aleatório, Chal, que vai usar para autenticar o cliente que está a
efetuar a validação, e garantir que este é o cliente para o qual o token foi gerado. O validador tem
esta garantia, enviando para o DM, o Chal cifrado com Tpwd que recebeu na mensagem A. Se o
cliente for legítimo, este conseguirá decifrar o Chal, e devolver mais tarde ao validador.
6. Neste passo, o validador combina um temporizador com tempos do histórico de transações do cli-
ente. Antes de enviar para o DM a próxima mensagem, o validador começa a contar o tempo que
leva até receber a resposta. Mais tarde, no passo 10, quando o temporizador parar, o validador
compara os tempos com os valores do histórico do cliente, e aborta a transação caso encontre
alguma anomalia.
Estes valores do histórico são carregados no validador através do token gerado no SC. O histórico
de tempos é atualizados no SC, através do protocolo de reconciliação.
Assim, considerando que os tempos de comunicação com o validador através de NFC, são mais
rápidos que através da Internet, se existir um atacante no meio da comunicação, o validador será
capaz de o identificar.
7. Este passo começa com a criação da mensagem E, que contém o valor aleatório R (recebido na
mensagem A), e o Chal gerado num dos passos anteriores. Ambos os números aleatórios são
39
Figura 3.11: Protocolo de validação de token.
40
cifrados com Tpwd. E = R+ChalTpwd .
Depois de o DM do cliente receber a mensagem E, este decifra-a. Assim, este fica com dados
suficientes para poder decifrar o token contido em B.
8. Neste passo a mensagem D é criada. Esta mensagem é composta pelo valor aleatório Chal
cifrado com Tpwd. D = ChalTpwd. Com a mensagem D, o validador consegue garantir que o token
está a ser usado pelo cliente para o qual foi emitido, uma vez que o Chal foi gerado para aquela
validação específica e o cliente consegue provar que sabe Tpwd.
9. O DM do cliente envia o token cifrado juntamente com a mensagem D para o validador: TokenKv
+ ChalTpwd . Na receção desta mensagem, o validador decifra o token com a chave Kv. Decifra
também o Chal, e compara o valor Chal gerado anteriomente. Se os valores coincidirem, o
protocolo procede.
10. O temporizador iniciado num passo anterior, é parado. Este valor é guardado para ser usado
nesta transação, e mais tarde durante o protocolo de reconciliação ser enviado para o SC.
11. O validador analisa o token para verificar que este se encontra no período de validade, se o CV
está em lista negra, etc. É também validado se o tempo medido no temporizado está dentro dos
valores estatísticos:
tempoValidação > avg(tempoValidaçãoHist) + ξ(tempoValidaçãoHist).
Se o tempo da validação da autenticidade do cliente for maior que a média dos valores do histórico
com uma margem de erro, a transação é abortada, devido à possível existência de um atacante
entre o cliente e o validador.
12. Se o último passo concluir com sucesso, a validação é terminada com sucesso, o cliente é notifi-
cado e é-lhe garantido acesso ao serviço de transportes.
3.6.3 Protocolo de saída/fiscalização
Tal como nas restantes soluções, o protocolo de saída/fiscalização é idêntico ao protocolo de vali-
dação, uma vez que o token é enviado para os validadores de saída ou dispositivos fiscalizadores para
ser validado. Desta forma, este protocolo é suportado pelo sub-protocolo de validação apresentado na
secção anterior.
3.6.4 Reconciliação
O protocolo usado na fase de reconciliação é o mesmo descrito na secção 3.4.4.
3.7 Conclusões
As soluções aqui apresentadas, vêm assim resolver os problemas associados à inexistência de
ES’s nos smartphones. Para tal foram adicionados diferentes modos de validação que permitem atingir
diferentes níveis de confiança no serviço. A solução apresentada em 3.5, em que a validação é efetuada
41
completamente online, representa a solução mais segura, uma vez que não são guardados dados que
possam ser forjados na memória do smartphone. O CV de um cliente é guardado num ambiente seguro
no SC, e toda a transação é executada entre o validador e este ambiente controlado e seguro. Contudo
é também a que levará mais tempo a concluir a validação, pois necessita de comunicar com um servidor
remoto. Esta solução apesar de já implementada em outros sistemas, não poderia ser deixada de fora
pois permite complementar as restantes implementações, oferecendo uma alternativa para situações
em que o utilizador não tenha descarregado previamente um token.
As duas soluções restantes, descritas em 3.4 e 3.6 resolvem, através do uso de tokens, o problema
da comunicação com servidores remotos uma vez que os tokens contêm toda a informação necessária
à conclusão da validação. Esta é uma aproximação à técnica de tokens utilizada nos sistemas de
pagamentos. Nestes, os tokens são validados num serviço central, o que permite cada token só seja
utilizado uma única vez. Na solução apresentada não se passa o mesmo, a validação acontece apenas
entre token, e validador, o que faz com que os limites temporais válidos para a sua utilização sejam
mais reduzidos, a fim de limitar a múltiplas utilizações do mesmo token.
Uma vez que o problema dos tokens poderem ser utilizados mais do que uma vez contínua a existir,
mesmo com os limites temporais e de autenticação do utilizador, uma fase muito importante para o
funcionamento do serviço, é a de reconciliação. Nesta fase é possível encontrar possíveis casos de
fraude, e bloquear a um utilizador, o acesso aos serviços de transporte.
42
4Implementação
Contents4.1 Solução Implementada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2 Comunicação Segura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3 Cartão Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.4 Registo de Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5 Carregamento de Saldo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.6 Servidor de Bilhética . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.7 Carregamento de Cartão Virtual (CV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.8 Reconciliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.9 Cálculo de Round Trip Time (RTT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.10 Cliente Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.11 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
43
Neste capítulo será descrita a implementação da solução cuja arquitetura foi apresentada no capí-
tulo anterior. Começará na secção 4.1 por explicar decisões tomadas relativamente aos métodos de
validação a implementar neste trabalho, e justificar as escolhas tomadas. De seguida na secção 4.2
serão apresentadas as tecnologias escolhidas para a comunicação entre componentes do sistema. Na
secção 4.3 será descrita a virtualização de um cartão de proximidade. Nas secções 4.4 e 4.5 serão
descritos os protocolos de registo de clientes, e o carregamento de saldo nas suas contas. Será de se-
guida apresentada a integração com uma solução de bilhética da Card4B Systems, na secção 4.6. Na
secção 4.7 será apresentado o carregamento de produtos nos CV, e consequentemente o protocolo de
reconciliação na secção 3.4.4. Na secção 4.9 será descrita de que forma foram medidas as latência das
comunicações entre smartphone e Serviço Cloud (SC). Será de seguida descrito o desenvolvimento
do componente Dispositivo Móvel (DM) na secção 4.10, e terminará na secção 4.11 com a conclusão
do capítulo.
4.1 Solução Implementada
No capítulo 3 foi apresentado um conjunto de soluções, com o objetivo de comparar cada uma delas
entre si, e com as soluções existentes atualmente no mercado. A solução apresentada na secção 3.6
propõe uma solução baseada em tokens, na qual o token é totalmente transferido para o validador onde
vai ser validado, não sendo escrito qualquer registo da validação no DM do cliente. Esta característica
elimina a possibilidade de durante a viagem do cliente, um fiscalizador determinar se o cliente acedeu
ao serviço legitimamente (e.g. validando o seu título de viagem), ou se este está a utilizar o serviço de
forma ilegítima. Esta falha na fiscalização, segundo os gestores do projeto da Card4B Systems, faz com
que esta solução falhe comercialmente, não sendo facilmente aceite pelos operadores de transportes.
Desta forma, juntamente com os elementos da Card4B Systems responsáveis pelo projeto, foi decidido
que esta solução necessitava de ser adaptada de forma a permitir executar corretamente os casos de
uso da secção 2.2.3, implementando neste trabalho apenas as soluções propostas nas secções 3.4 e
3.5, validação offline e online sem alteração dos validadores, respetivamente.
4.2 Comunicação Segura
No capítulo 3 é apresentado como principal componente da solução o SC. Neste componente são
delegadas as funções de garantir a segurança dos CV dos clientes, substituindo assim o tradicional
Elemento Seguro (ES).
Nesta secção serão descritas as tecnologias utilizadas para manter a confidencialidade, integridade
e autenticidade das mensagens trocadas entre o DM e SC. De seguida será descrita a implementação
do protocolo de autenticação descrito na secção 3.3.3 e quais as principais alterações de forma a
adaptar às tecnologias utilizadas.
44
4.2.1 Web Services
O desenvolvimento do SC começou com a escolha da tecnologia utilizada para garantir a comu-
nicação entre componentes do sistema. Um ponto considerado importante na escolha da tecnologia
era que esta fosse facilmente adaptada para diferentes plataformas. Os Web Services cumprem este
requisito uma vez que estão disponíveis para vários sistemas operativos e linguagens, inclusive em
aplicações Web (aplicações executadas parcial ou totalmente em navegadores Web). Esta tecnologia
permite, através de um servidor de HyperText Transfer Protocol (HTTP), expor um conjunto de funcio-
nalidades implementadas no servidor, utilizadas através de clientes HTTP para implementar aplicações
que usem esse conjunto de funcionalidades expostas.
No anexo A está listado o conjunto de Web Services disponíveis, assim como uma pequena ex-
plicação da funcionalidade de cada um, assim como os dados de entrada e o resultado esperado de
cada um. Os Web Services foram divididos em dois conjuntos principais: gestão de utilizadores e de
gestão de cartões virtuais. Os Web Services do primeiro conjunto disponibilizam métodos para criar e
alterar as contas de utilizador, enquanto o do segundo permitem efetuar pagamentos, e carregamentos
de cartões virtuais.
4.2.2 Canal Seguro
Um dos principais requisitos estabelecidos nos protocolos apresentados anteriormente no capítulo
3, é a necessidade de toda a comunicação entre DM’s e SC ser estabelecida através de um canal
seguro usando o protocolo Transport Layer Security (TLS). Este protocolo é usado entre o cliente e
o servidor para entre si, estabelecerem uma chave de sessão utilizada na segurança das mensagens
trocadas posteriormente.
Na implementação do SC, para cumprir o requisito acima mencionado, foi usado o protocolo HTTP/TLS.
Este protocolo combina os protocolos HTTP e TLS, garantindo autenticação do servidor, assim como a
confidencialidade e integridade de todas as mensagens trocadas durante o protocolo HTTP[27]. Atra-
vés da utilização do protocolo HTTP/TLS garantimos que as propriedades: autenticidade, integridade e
confidencialidade, são também asseguradas na execução dos protocolos definidos no capitulo 3.
De forma a poder executar o protocolo TLS, o cliente deve ter um certificado com a chave pública
do servidor. Este para além de ser essencial para a execução do protocolo, irá garantir que a comu-
nicação foi estabelecida com um servidor autêntico. Neste trabalho, para efeitos de demonstração, foi
utilizado um certificado self-signed. Este certificado é distribuído pelos clientes através da aplicação a
instalar nos DM. Numa situação de produção este certificado deveria ser substituído por um certificado
devidamente assinado por uma autoridade certificadora.
Geralmente os servidores Web seguros disponibilizam ambos os protocolos (HTTP e HTTP/TLS)
em portos diferentes. Para garantir que todos os clientes utilizam a versão segura do protocolo, forçam
o redirecionamento da ligação do cliente (funcionalidade específica do protocolo HTTP), para um porto
diferente. Outra solução passa por configurar a aplicação do servidor para não utilizar o protocolo
HTTP, ou, caso esta opção não esteja disponível, bloquear na firewall as ligações através do exterior
45
para o porto do protocolo HTTP. Por simplicidade, na implementação do SC, recorreu-se à firewall para
forçar a utilização de HTTP/TLS.
4.2.3 Autenticação dos DM’s
Na secção 4.2.2 é descrito de que forma o SC se autentica perante DM’s que com este comuniquem.
Contudo neste processo, qualquer entidade com a chave pública do servidor poderá comunicar de forma
segura com o mesmo. Desta forma é necessário autenticar também o DM perante o SC.
Na secção 3.3.3 é descrito um protocolo de autenticação, que recorre a dados conhecidos pelo uti-
lizador e DM para autenticar ambos. Conceptualmente esse protocolo deveria ser executado no início
de cada protocolo, o que requereria que o utilizador digitasse o seu nome de utilizador e palavra-passe
a cada protocolo. Alternativamente para agilizar o processo de autenticação, recorreu-se a um meca-
nismo de tokens de autenticação. Um token de autenticação é um conjunto de dados que permitam
identificar inequivocamente um utilizador perante um servidor. O servidor deve também ter a capa-
cidade de validar se um determinado token foi gerado por si. Um token depois de gerado, deve ser
enviado para o cliente que o deve guardar e enviar para o servidor juntamente com cada mensagem.
Na implementação deste trabalho foi utilizada a especificação de tokens para a Web: JSON Web
Token (JWT)[28]. Esta especificação garante todos os requisitos, acima enumerados, de um token de
autenticação. Neste trabalho foi utilizada uma implementação1 de JWT open source, uma vez que a
sua implementação não era um requisito para este trabalho.
Um token de autenticação é enviado para o servidor a cada pedido do cliente, o que faz com que
este token seja um dado constante nas mensagens trocadas na rede. Apesar de as comunicações
serem confidenciais, existem alguns ataques conhecidos ao protocolo TLS[29]. Através de um destes
ataques, um atacante poderá obter token que lhe permitiria aceder à conta do utilizador e utilizar o
seu serviço indevidamente. De forma a evitar estas situações, os tokens de autenticação são gerados
com uma validade embebida (neste caso de uma hora), o que faz com que passado o tempo dessa
validade, o token deixe de ser aceite e a autenticação falhe. Procura-se assim diminuir a janela temporal
que um atacante tem para aplicar um ataque e descobrir um token de autenticação. No momento
da autenticação do utilizador perante o servidor (momento em que o utilizador insere os deus dados
de autenticação), é também gerado um segundo token chamado de token de refrescamento. Este,
gerado com uma validade temporal de algumas semanas, permite em qualquer momento durante a sua
validade, e enquanto um novo não for gerado, emitir junto do servidor um novo par de tokens.
Um token JWT permite a quem tenha a chave simétrica utilizada para o gerar, validar a sua integri-
dade e autenticidade. Desta forma um token é sempre válido desde que esteja dentro da sua validade
temporal. Esta validade implícita leva a que outras verificações tenham de ser adicionadas para garantir
que um token não foi revogado (e.g. quando durante a validade do token de refrescamento um novo é
gerado). Assim para garantir que a revogação de tokens era garantida, cada par de tokens passou a ser
guardado na base de dados dos utilizadores. Assim a validação de um token passou a ser executada
em duas fases: na primeira fase são validadas as assinaturas token a fim de verificar a integridade e
1JWT (JSON Web Token) implementation for .NET 3.5 https://github.com/johnsheehan/jwt
46
autenticidade deste; na segunda fase é verificado na base de dados se o token não foi revogado.
Com este mecanismo de autenticação não era possível cada utilizador ter mais do que um DM
autenticado a cada momento. Mais à frente neste capítulo este problema voltará a ser endereçado, e
será explicado como foi resolvido.
4.3 Cartão Virtual
Nesta secção será apresentada a implementação do CV, começando por explicar qual o cartão físico
virtualizado e quais os motivos para esta escolha. Será também explicado como foi implementada a
instanciação dos CV’s.
Neste trabalho foram estudados dois tipos de cartões de proximidade, cartões apenas com um mapa
de memória (secção 2.2.1), e cartões com micro-processador que permitem a execução de protocolos
de comunicação, que não se limitem à leitura e escrita de dados no cartão. Desta forma, dado que no-
meadamente os equipamentos disponíveis para testes com cartões correspondia aos cartões utilizados
em Lisboa, existiam dois cartões que poderiam ser virtualizados de forma a manter a compatibilidade
com os validadores e fiscalizadores: um cartão de memória ASK CTS512B, ou um cartão Calypso.
O cartão virtualizado neste trabalho foi o CTS512B. Este cartão foi escolhido por dois motivos:
• Sendo este um cartão de memória, tal como vimos na secção 2.2.1, este cartão suporta apenas
comandos de leitura e escrita. Já o cartão Calypso tem um protocolo de comunicação propri-
etário, definido ao nível da camada de aplicação. Desta forma considerou-se que o tempo de
desenvolvimento de todo o protocolo, caso se tivesse acesso ao mesmo, seria demasiado, dado
o período disponível para a realização do trabalho.
• Por definição, partes do modelo de dados de Lisboa quando aplicado num CTS512B, são cifra-
das, e inclusive são guardadas no cartão assinaturas dos dados nele escritos. Assim, o CV estará
também protegido contra adulterações indevidas, e a confidencialidade de alguns dos dados ga-
rantida, com o mesmo nível de segurança de um CTS512B.
Antes de continuar com a descrição da implementação, é ainda necessário fazer referência a outro
ponto importante. Os cartões CTS512B não implementam o ISO-14443 na sua totalidade. Este ISO é
composto por quatro camadas numeradas de 1 a 4, em que as duas últimas (camadas ISO 14443-3 e
ISO 14443-4), são responsáveis pela comunicação entre cartões/leitores. A camada 4, não disponível
no CTS512B, define um protocolo de comunicação de alto nível através de Application Protocol Data
Unit (APDU)’s. Simplificando, o CTS512B apenas recebe comandos de leitura e escrita não suportando
qualquer APDU. A não existência desta camada é um problema para o CV, pois o Sistema Operativo
(SO) Android apenas suporta emulação de cartões que implementem o ISO 14443-4.
Na figura 4.1 está ilustrado um diagrama de classes onde está descrita a virtualização deste cartão.
Este cartão foi criado com uma memória de 64 Bytes, e com apenas duas operações: leitura e escrita.
De forma a suportar o ISO 14443-4, foi adicionada uma camada que encapsula o cartão, e que lhe adi-
ciona suporte para executar APDU’s. As APDU’s implementadas são definidas no ISO/IEC 7816-4[30],
47
Figura 4.1: Diagrama de classes da virtualização do cartão CTS512B.
e mapeiam as operações de leitura e escrita do cartão original nas duas APDU’s equivalentes defini-
das no ISO: Read Binary e Update Binary,respetivamente. Adicionalmente foi também implementado
o comando, definido no mesmo ISO, Select Application IDentifier (AID). Este comando é utilizado para
escolher a aplicação Near Field Communication (NFC) com o identificador enviado pelo leitor. Este será
o primeiro comando a ser executado, e permitirá escolher a aplicação corresponde ao CV.
As soluções com validação offline e online, secções 3.4 e 3.5 respetivamente, foram desenhadas
para não ser necessário necessário alterar os validadores atuais. Este ponto continuará a ser verdade,
com a única exceção de que os validadores terão de reconhecer um novo tipo de cartão.
4.3.1 Instanciação
A instanciação de um CV ocorre no momento da criação das contas de utilizador (descrito mais à
frente neste capítulo). Num cartão CTS512B os primeiros dez bytes são escritos pelo fabricante e estão
protegidos contras escritas, sendo que os quatro últimos bytes correspondem ao número de série do
cartão. Na implementação do CV os primeiros seis bytes foram copiados de um cartão físico utilizado
em Lisboa, enquanto que o número de série escrito corresponde ao identificador único atribuído au-
tomaticamente pela base de dados ao novo CV. Tal como no CTS512B, este conjunto de bytes está
protegido contra escritas, pelo que uma APDU que tente escrever num endereço inferior a dez não será
executada.
4.4 Registo de Clientes
Nesta secção será descrita a implementação do protocolo de registo de utilizador descrito na secção
3.3.2. No registo de um novo cliente, o utilizar tem de inserir os seus dados pessoais tais como nome,
endereço eletrónico, palavra-passe, um código Pin numérico de quatro dígitos e um identificador do DM.
O endereço eletrónico e palavra-passe serão posteriormente necessários para o utilizador se autenticar
no serviço. O código Pin (não previsto originalmente na solução proposta) será utilizado para derivar
uma chave de cifra simétrica, que será utilizada no protocolo de carregamento de tokens da secção
3.4.1. Ao utilizar o código Pin em vez da palavra-passe para derivar a chave de encriptação, evita-
se que o utilizador tenha que inserir a palavra-passe de cada vez que utilize um novo token, e assim
melhora-se assim a sua experiência de utilização.
A derivação da chave de encriptação é efetuada utilizando o algoritmo Password-based Key Deri-
vation Function 2 (PBKDF2). Esta chave é calculada no momento da criação da conta de utilizador
e guardada na base de dados. Esta chave só é alterada no caso de o utilizador decidir alterar o seu
48
código Pin. Nesse caso todo o processo é repetido e a chave recalculada.
Na base de dados é também guardado um digest da palavra-passe do utilizador. A palavra-passe
não é guardada na sua forma original com o objetivo de prevenir a divulgação dos dados dos utilizadores
no caso de um ataque à base de dados.
Juntamente com os dados do utilizador são criados na base de dados um CV tal como descrito
anteriormente, e é inicializado o saldo do cliente. Ao contrário do descrito na solução proposta, e de
forma a permitir suportar facilmente as soluções online e offline de forma conjunta, foi criado um saldo
independente do CV. Este saldo corresponde a um pagamento efetuado pelo cliente e cujo valor é
guardado na sua conta de cliente. Este saldo permitirá posteriormente ao cliente carregar produtos no
seu CV ou carregar tokens no seu DM. Cada vez que uma destas operações for efetuada o preço do
produto a ser carregado será descontado do saldo do cliente.
O identificador do DM recebido neste protocolo (e de igual forma no protocolo de autenticação), é
utilizado para criar uma entidade na base de dados que corresponde ao dispositivo em que o utilizador
está a utilizar o serviço. Desta forma os tokens de autenticação descritos na secção 4.2.3, são associ-
ados ao dispositivo e não ao utilizador. No anexo C é possível ver o diagrama de classes onde estão
descritas as relações das entidades descritas acima.
4.5 Carregamento de Saldo
Na secção anterior descrevemos o registo de um novo cliente, onde é criado um saldo que permitirá
ao cliente o carregamento do CV na cloud e em tokens. Assim o carregamento de saldo foi desaco-
plado do carregamento do CV, e criado um protocolo independente. A lógica descrita na secção 3.3.4
referente ao carregamento de CV continua a ser válida, com a única diferença de não serem efetuadas
quaisquer alterações no CV, e ser apenas registado o novo valor na base de dados.
Neste trabalho como serviço externo de pagamentos, foi utilizado o PayPal. Os pagamentos com
PayPal são executados entre o cliente e o seu serviço online, não sendo dado ao “vendedor” qualquer
informação privada do cliente, tal como números de cartões de crédito. Após o cliente aprovar o paga-
mento, este é de novo reencaminhado para o SC, que concluirá o processo de pagamento e depositará
no saldo do cliente a quantia paga.
4.6 Servidor de Bilhética
Na secção 4.3 foi referido o facto de já existir um modelo de dados específico da cidade de Lisboa
e que este iria ser respeitado no desenvolvimento deste trabalho. Como tal, o CV desenvolvido teria de
suportar esse modelo de dados, pelo que o cartão virtualizado deveria ser um dos dois para os quais o
modelo de dados está desenhado.
Neste trabalho foi utilizada a framework de bilhética Ticketing Kernel (TK), desenvolvida na Card4B
Systems e que a disponibilizou para este trabalho. O TK é utilizado em validadores, postos de vendas,
terminais de fiscalização e back-office. Este tem implementados vários modelos de dados utilizados
pelos operadores de transportes em Portugal, o que inclui o de Lisboa.
49
O objetivo de utilizar oTK neste trabalho, era que o carregamento de produtos no CV na cloud e em
tokens segundo o modelo de dados de Lisboa, não tivesse que ser novamente implementado. Contudo
o TK está desenhado para interagir com leitores físicos de cartões sem contacto, e não com “cartões
virtuais”. Outro problema é a necessidade de ter acesso a um Secure Application Module (SAM),
que geralmente é acessível através dos leitores de cartões. Desta forma foi necessário fazer algumas
alterações no TK de forma a que este se adaptasse a este trabalho.
4.6.1 Leitor de CV
O desenvolvimento do leitor de CV teve duas fazes: a primeira coincide com a implementação dos
mecanismos para efetuar leituras e escritas num CV, e a segunda é a implementação de um leitor de
SAM’s físico ligado por Universal Serial Bus (USB). Assim para adicionar capacidade de leitura de
CV, foi adicionado um mecanismo de callback ao TK, que delega para a aplicação que o integra a
tratamento dos pedidos de leitura e escrita do CV. Quanto ao leitor de SAM, uma vez que o leitor físico
utilizado era do tipo Personal Computer/Smart Card (PCSC), foi reutilizada a implementação de outro
tipo de leitor já existente no TK que era compatível. Desta forma foi possível executar comandos num
CV e num SAM sem adicionar alterações significativas ao TK.
4.6.2 Servidor
Algo que também era conhecido à partida e considerado um problema neste trabalho, foi o facto de
o TK não suportar concorrência. Assim tornou-se necessário solucionar este problema, uma vez que
poderia por em causa a escalabilidade de todo o sistema. O facto de o TK necessitar de um leitor de
SAM ligado numa porta USB, tem também grande impacto na escalabilidade do sistema.
Assim com vista a resolver os problemas de escalabilidade inerentes ao TK, foi decidido que as
funcionalidades de bilhética deveriam ser implementadas à parte, num segundo servidor. Este servidor
contém assim um conjunto de processos que irão distribuir os pedidos do SC entre si. O servidor terá
também, por cada processo de TK, um leitor de SAM associado que irá utilizar exclusivamente.
4.6.2.A Processos
No desenvolvimento deste trabalho, foram criados dois tipos de processos: Master e Worker. O
Master é o primeiro processo a ser lançado, e.g. quando se inicia o servidor. Este carrega um ficheiro de
configuração, onde está detalhado cada processo que deve ser lançado, juntamente com os endereços
onde cada um deve publicar os seus serviços Web, e o nome do leitor de SAM que este deve utilizar.
Depois de carregado o ficheiro de configuração, o Master irá lançar os restantes processos, passando
a cada um os dados correspondentes carregados no ficheiro.
4.6.2.B Servidor Web
Após o lançamento, cada processo TK disponibiliza um Web Service REST. Este será o ponto de
entrada de novos pedidos do SC. Contudo apenas o Master aceitará novos pedidos. Este atuará como
escalonador, atribuindo tarefas aos restantes processos.
50
O protocolo de atribuição de uma nova tarefa a um processo é o seguinte:
1. O cliente faz um pedido num endereço bem conhecido, requerendo um processo que o possa
atender.
2. O Master escolhe um Worker de entre os que estiverem livres, e atribui-lhe o identificador de uma
tarefa a executar.
3. O Master retorna de seguida ao cliente o endereço do Worker que atenderá o seu pedido, junta-
mente com o identificador da tarefa que lhe foi atribuído.
4. O cliente deve utilizar o endereço e o identificador recebido para executar então o seu pedido
junto do Worker atribuído.
5. Se no prazo de dez segundos, o cliente não tiver mandado executar a tarefa no Worker, este
cancela a tarefa e está novamente pronto a receber trabalho.
Depois de um Worker ter sido atribuído ao cliente, juntamente com o pedido a executar, e o identifi-
cador da tarefa o cliente envia para o Worker também a imagem do CV. Esta imagem vai ser utilizada
pela callback mencionada anteriormente do leitor. Toda a transação será executada segundo esta ima-
gem, sendo que apenas as escritas serão guardadas, e posteriormente devolvidas ao cliente, que deve
aplicar essas alterações no seu CV correspondente.
4.6.2.C Comunicação Entre Processos
Para possibilitar a comunicação entre o Master e os Workers, foi utilizada a tecnologia de Remoting
da .Net Framework. Cada Worker disponibiliza uma interface que permitia ao Master atribuir-lhe uma
nova tarefa. O Master disponibiliza também uma interface que permite aos Workers notificarem quando
terminam uma tarefa, cancelar uma tarefa por timeout, e também notificarem o Master periodicamente
de que estão ativos e prontos a receber tarefas.
4.6.2.D Tolerância a Faltas
Tendo em conta que apenas o Master tem a capacidade de escalonar tarefas pelos diferentes Wor-
kers, no caso de falha do Master os Workers devem ser capazes de reagir e tomar o lugar de Master.
Assim foram atribuídas prioridades entre zero e cem a cada Worker. Os Workers ao detetarem a falha
do Master devem esperar um número de segundos igual à sua prioridade até voltarem a verificar se o
Master ainda está em baixo, e consequentemente caso não exista ainda um Master assumir o papel.
4.7 Carregamento de CV
Depois de um utilizador ter concluído o registo no sistema, e ter adicionado saldo à sua conta,
este necessita ainda de carregar o seu CV, uma vez que só após o carregamento de um produto um
CV poderá ser utilizado para aceder aos serviços de transportes. Neste trabalho foi utilizado exclu-
sivamente um produto, conhecido na cidade de Lisboa como “Zapping”. Este produto corresponde
51
Figura 4.2: Protocolo de carregamento de produtos em CV através de TK.
ao carregamento de um determinado saldo no cartão, que o utilizador poderá utilizar até o esgotar
completamente.
O “Zapping” foi utilizado na sua forma integra quando carregado num CV na cloud. Quando car-
regado num token, sofreu duas alterações: o valor a carregar é fixo, não podendo ser emitido um CV
com um valor diferente do definido pelo operador; e foram adicionadas datas de início e de fim de vali-
dade do produto, não podendo este ser utilizado fora desse período. Todas as alterações efetuadas ao
produto, são suportadas pelo modelo de dados de Lisboa.
O protocolo de carregamento de produtos num CV está ilustrado na figura 4.2 e é o seguinte:
1. O protocolo de autenticação entre DM e SC é executado.
2. O cliente escolhe se quer carregar o CV na cloud, ou criar um novo token. Assim deve inserir,
respetivamente, o montante a carregar ou a hora de início de validade do token.
3. O SC mede o valor de RTT entre si e o DM do cliente.
4. No caso de o cliente pretender criar um novo token, é necessário criar primeiro um novo CV. Este
é clonado através do CV da conta do utilizador, e de seguida é apagado qualquer contrato que
possa ter gravado.
5. O SC inicia o protocolo de utilização do servidor de TK, requerendo um nó para atender o seu
pedido.
52
Figura 4.3: Protocolo de leitura de saldo de um CV.
6. O servidor de TK vai criar uma tarefa, atribuir a tarefa a um nó, e devolve o endereço do Worker
juntamente com o identificador da tarefa.
7. O SC envia a informação do produto a carregar para o nó que lhe foi atribuído, juntamente com o
identificador anteriormente recebido.
8. O nó de TK executa a pedido, e produz uma mensagem de confirmação com os dados do produto
carregado, e o conjunto de APDU’s a executar no CV.
9. O SC analisa a resposta do servidor de TK. Se o carregamento foi executado com sucesso, este
aplica as alterações no CV executando o conjunto de APDU’s recebido.
10. O SC notifica o DM do cliente da conclusão da tarefa, e no caso de criação de um novo token
envia-o para o DM.
4.7.1 Tokens
No caso da criação de um novo token, este é descarregado para o DM segundo o protocolo descrito
na secção 3.4.1. Parte deste protocolo foi descrito na secção anterior, onde o token é criado e lhe é
adicionado valor. Após a criação do token, antes deste ser transferido para um DM, é ainda necessário
cifrar o token de forma a que este esteja protegido caso um atacante fique em posse deste.
Para cifrar os tokens foi utilizada uma chave derivada através de um código Pin inserido pelo uti-
lizador no momento do registo. Esta chave foi utilizada com o algoritmo de cifra simétrica AES/CBC/
PKCS5Padding.
53
4.7.2 Leitura de Saldo do CV na cloud
Apesar de não estar previsto na solução original, um protocolo que permitisse a consulta de saldo
(ou qualquer outro produto carregado num CV), durante o desenvolvimento deste trabalho, era um
objetivo deste trabalho suportar a funcionalidade, uma vez que de outra forma seria necessário recorrer
a um leitor externo para identificar os produtos carregados.
Para concretizar este objetivo foi criado um novo protocolo, em que é enviado um pedido de leitura
do CV para o SC, e este através de uma chamada para o servidor de TK devolve a lista de produtos
carregados no cartão. Nesta implementação a lista de produtos nunca terá mais do que um produto, e
este corresponderá sempre ao saldo carregado no CV.
Na imagem 4.3 está ilustrado o protocolo de leitura de saldo descrito de seguida:
1. O protocolo de autenticação entre DM e SC é executado.
2. É invocado o método de leitura do saldo carregado no CV do cliente.
3. O SC mede o valor de RTT entre si e o DM do cliente.
4. O SC inicia o protocolo de utilização do servidor de TK, requerendo um nó para atender o seu
pedido.
5. O servidor de TK vai criar uma tarefa, atribuir a tarefa a um nó, e devolve o endereço do Worker
juntamente com o identificador da tarefa.
6. O SC envia a imagem do se CV para o nó que lhe foi atribuído, juntamente com o identificador
anteriormente recebido.
7. O nó de TK executa a pedido, e produz uma mensagem de confirmação com os produtos lidos no
CV.
8. O SC notifica o DM do cliente da conclusão da tarefa, enviando juntamente o saldo atual do seu
CV
4.8 Reconciliação
O protocolo de reconciliação descrito na secção 3.4.4, e tem o objetivo de conjugar as transações
resultantes das validações diárias com os tokens emitidos, e desta forma verificar se os todos foram
utilizados devidamente. Este protocolo já é utilizado atualmente nos sistemas utilizados, sendo que
aqui foi apenas implementado de forma a evitar a integração com o atual sistema.
O TK utilizado nos validadores produz um registo de transações com todas as operações efetuadas
quando um cartão é apresentado. No caso de uma validação fica neste registo a data e hora da
validação, o número de série do cartão, o produto que foi validado, entre outros. Com estes dados o
SC é capaz de detetar se um CV foi utilizado, mais precisamente os tokens. O registo de transações é
produzido cifrado pelo TK, pelo que para aceder aos dados da transação, o SC deverá primeiro utilizar
o TK para decifrar a transação.
54
Para possibilitar a comunicação das transações dos validadores ao SC, foi adicionado um serviço
Web que estes utilizaram através de uma conta criada para o efeito. Depois de recebidas, as transações
são decifradas e os dados das transações correspondentes a tokens são cruzados com todos os tokens
emitidos. Nesta fase deve existir uma correspondência de um para um entre transações e tokens
emitidos, e neste caso o token deve ser marcado como utilizado. Se para um dado cartão existirem
mais transações correspondentes a tokens do que os que foram emitidos, podemos estar perante uma
situação de fraude e a conta deve ser portanto bloqueada. Caso não existam transações relativas a
um determinado token isto pode significar que este não foi utilizado. Desta forma para evitar problemas
como o atraso de comunicação de transações por parte dos validadores, o SC deve esperar um número
de dias definido anteriormente (neste caso foi usado trinta dias), para então proceder à reposição de
saldo na conta do cliente.
4.9 Cálculo de RTT
Em alguns dos protocolos especificados no capítulo 3, nomeadamente o protocolo de registo de
novo cliente na secção 3.3.2, e o protocolo de carregamento de saldo na conta da secção 3.3.4, e
também no capítulo 4 o protocolo de carregamento de produtos da secção 4.7, são medidos os tempos
de RTT entre o SC e o DM. Neste trabalho uma vez que a comunicação entre DM e o SC é mantida
através do protocolo HTTP, não é possível ao SC, através deste protocolo, iniciar um pedido dirigido ao
DM a fim de fazer estas medições.
Para resolver estes problemas, os protocolos acima enumerados foram alterados. Desta forma
quando o SC recebe um novo pedido a fim de executar qualquer um destes protocolos, este cria uma
entrada na base de dados com os dados enviados pelo DM juntamente com um timestamp, e atribui um
identificador único a este pedido. O SC responde imediatamente ao DM com o identificador do pedido
registado. O DM deve então iniciar um novo pedido ao SC no qual inclui o identificador que recebeu. O
SC ao receber o identificador, usa o timestamp guardado na base de dados anteriormente para medir
o RTT. De seguida este utiliza os restantes dados do pedido original, e executa-o.
4.10 Cliente Android
Esta secção descreve a implementação do componente DM, na qual foi utilizada a plataforma An-
droid. Tal como referido anteriormente no capítulo 2, esta plataforma, a partir da versão 4.4, oferece
suporte para emulação de cartões de proximidade. Assim, descreveremos de seguida alguns dos pro-
tocolos implementados nesta plataforma, que permitirão um utilizador registar-se no sistema e efetuar
todos os passos necessários até estar pronto a utilizar o seu CV.
4.10.1 Biblioteca Android
Para facilitar a integração dos serviços web disponibilizados pelo SC, foi criada uma biblioteca para
a plataforma Android que implementa todos os protocolos do sistema apresentado. Esta biblioteca
disponibiliza uma interface que permite a invocação dos protocolos do sistema de forma assíncrona.
55
Esta biblioteca é responsável pela execução dos protocolos definidos. Esta, após a chamada de
qualquer dos métodos da biblioteca, cria tarefas em background e notifica a aplicação de forma assín-
crona. A interface desta biblioteca está definida no anexo B.
De seguida é explicado de que forma a biblioteca gere alguns dos principais protocolos, tais como
registo e autenticação, carregamento de saldo, carregamento do CV e tokens, e também validação.
4.10.1.A Registo e Autenticação
Nos protocolos de registo de novo cliente e autenticação, métodos CreateUserAsync e LoginAsync
respetivamente, em caso de sucesso é retornado um par de tokens de autenticação a utilizar nas
chamadas seguintes que requerem autenticação. Esta parte do protocolo é abstraída da aplicação,
sendo esta informada apenas do sucesso ou insucesso da chamada ao SC. A biblioteca fica então
responsável por gerir os tokens de autenticação. Estes são guardados num ficheiro privado à aplicação,
e nos protocolos seguintes serão recuperados e utilizados na autenticação dos pedidos.
Quando um token de autenticação expira, a chamada ao SC falha e retorna o erro HTTP 401 -
Unauthorized (todos os códigos de erro utilizados estão descritos no anexo A). Neste caso é automa-
ticamente utilizado o token de refrescamento para junto do SC gerar um novo par de tokens. Em caso
de sucesso, os novos tokens de autenticação são guardados, e é repetido o pedido original ao SC.
4.10.1.B Carregamento de Saldo
Para o utilizador estar pronto a carregar produtos em CV, este tem primeiro de adicionar saldo à
sua conta. Desta forma a biblioteca disponibiliza o método PaymentBeginAsync para dar início a um
carregamento onde é apenas necessário informar o montante a carregar. A aplicação vai receber como
resposta a este método um Uniform Resource Locator (URL) do PayPal, para o qual deve reenca-
minhar o utilizador a fim de este autorizar o pagamento. Estando o pagamento autorizado o PayPal
reencaminha o utilizador para um endereço que a aplicação deve tratar (o Android disponibiliza meios
que permitem que determinados URL declarados pelas aplicações, sejam abertos pelas aplicações e
não pelo Web Browser ). Neste momento, caso o utilizador tenha aprovado o pagamento, a aplicação
recebeu através do URL que abriu dois identificadores que permitirão o SC concluir o pagamento junto
do PayPal (só depois deste passo o montante a pagar pelo cliente será efetivamente descontado). As-
sim a aplicação deve chamar o método PaymentEndAsync que recebe os identificadores gerados pelo
PayPal, e que conclui o pagamento. No final a aplicação será notificada da conclusão do carregamento,
e do saldo atual carregado.
4.10.1.C Carregamento de CV
Tal como já foi dito anteriormente, o utilizador pode, com o saldo carregado na sua conta, carregar
o CV na cloud ou alternativamente carregar um CV num token e descarrega-lo para o seu DM.
Caso o cliente pretenda carregar o CV na cloud, a aplicação deve chamar o método LoadCardAsync.
Este recebe o montante a carregar no CV, e caso o utilizador tenha este montante na conta, será
56
efetuado o carregamento, e de forma assíncrona a aplicação será informada do montante carregado e
do saldo total do cartão.
Alternativamente o cliente pode optar por carregar um CV através de um token. Neste caso a
aplicação deve chamar o método da biblioteca CreateCardTokenAsync. Este método recebe apenas
uma data e hora que devem corresponder ao corrente dia. Assim, caso o cliente tenha saldo suficiente
para cobrir o custo do carregamento, um novo token será recebido pela biblioteca. Este token será
guardado pela biblioteca numa base de dados local usada para esse efeito. A aplicação será notificada
do sucesso do carregamento do token, sendo-lhe enviada a data de início e fim da validade do token.
O token fica guardado cifrado na base dados. O utilizador pode abrir o token até dez minutos antes
da hora de início de validade. Para decifrar um token a aplicação deve chamar o método OpenToken,
que recebe o identificador do token na base de dados e o código Pin utilizado para decifrar o token. A
partir do momento em que a aplicação chama este método, se existir outro token aberto de momento,
este ficará indisponível.
4.10.1.D Emulação de Cartão
Na secção 2.3.2 é apresentado o Host-based Card Emulation (HCE), uma tecnologia da plataforma
Android, que permite a emulação de um cartão de proximidade sem recorrer a um ES. A biblioteca
desenvolvida disponibiliza um serviço Android responsável por tratar todos os APDU’s enviados pelo
leitor. Este serviço declara um AID que o Android vai utilizar para identificar o serviço a lançar quando
o DM é aproximado de um leitor que procura um cartão com esse AID.
Este serviço suporta interações com os dois tipos de CV: na cloud e em token. Desta forma é
necessário desambiguar qual dos CV’s deve ser utilizado. Dessa forma existem dois métodos, UseOn-
lineVCard e UseOfflineVCard, que a aplicação deve chamar sempre que o utilizador indique que o CV
a usar é o da cloud ou um token, respetivamente.
No caso de o utilizador escolher utilizar o CV na cloud, o serviço tem disponível o método privado da
biblioteca ExecuteVCardApduAsync, que executará a APDU no SC. Caso contrário todas as APDU’s
serão executadas localmente, acedendo ao token aberto na base de dados.
4.11 Conclusão
Neste capítulo abordamos a implementação a solução proposta neste capítulo. As tecnologias
utilizadas permitiram implementar todos os detalhes da solução cumprindo os padrões de segurança
descrito.
Esta solução, uma vez que não utiliza qualquer hardware seguro, parte do princípio que qualquer
DM pode ser comprometido, mantendo assim os CV de alto valor fora do DM. Com a virtualização
do CTS512B, foi possível garantir a integridade, e autenticidade dos tokens guardados no DM. Esta
característica não estava prevista originalmente na proposta, mas é sem dúvida imprescindível para
garantir a segurança de toda a solução.
Relativamente aos tokens de autenticação, utilizados para autenticar o utilizador perante o SC, têm
57
a vantagem de serem uma solução que não compromete os dados de privados de autenticação do
utilizador. Contudo se um atacante obtiver token de refrescamento guardado num DM, pode utilizar o
sistema, fazendo-se passar por este. Havendo noção deste ponto, acredita-se que a vantagem de o
utilizador ter de inserir a sua palavra-passe uma única vez por DM, prevalece sobre a falha mencionada.
Foi também adicionado um servidor não especificado originalmente, que permite agilizar o carrega-
mento de produtos nos CV’s, permitindo abstrair todo o modelo de dados dos cartões utilizados.
Relativamente ao DM, os esforços concentraram-se no desenvolvimento de uma biblioteca que
permita integrar estes serviços com as diferentes aplicações de transportes e bilhética, sem que estas
tenham de ter conhecimento dos protocolos da solução, e dos detalhes da implementação do CV.
Contudo, para efeitos de teste e demonstração, foi também criada uma simples aplicação que mostra
as principais funcionalidades do sistema.
58
5Avaliação
Contents5.1 Medições dos tempos de Transação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.2 Análise de Ameaças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.3 Satisfação de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
59
Neste capítulo serão apresentados os resultados da avaliação do presente trabalho. Esta começará
por na secção 5.1 comparar o desempenho da solução apresentada, com um sistema de bilhética sem
contacto tradicional. De seguida será apresentada na secção 5.2 uma análise às vulnerabilidades do
sistema. Com os resultados obtidos nas secções 5.1 e 5.2 será apresentada a satisfação dos requisitos
do trabalho. Este capítulo terminará na secção 5.4 com uma breve conclusão.
5.1 Medições dos tempos de Transação
Nesta secção será analisada o desempenho das transações de validação da solução implementada.
Os tempos medidos em ambos os modelos, online e com tokens, estão listados no anexo E e serão
comparados com medidos em iguais condições com um cartão de proximidade igual ao virtualizado
neste trabalho, o CTS512B. De seguida será apresentado o ambiente utilizado para efetuar estas me-
dições, assim como o hardware utilizado. Posteriormente serão apresentados os resultados obtidos,
assim como as devidas conclusões.
5.1.1 Ambiente utilizado nas medições
As medições foram realizadas nos escritórios da Card4B. Aqui foi instalado um computador pessoal
com os servidores desenvolvidos (Serviço Cloud (SC), e servidor de Ticketing Kernel (TK)), ligado à
rede sem fios local, e com acesso ao mesmo através de um endereço de Internet Protocol (IP) público.
Num segundo computador pessoal foi instalado um simulador de um validador que, utilizando a
framework TK irá efetuar múltiplas operações de validação seguidas e registar os tempos de cada tran-
sação com sucesso. A este computador foi ligado um leitor de cartões de proximidade ASK 518-U, onde
estava instalado um Secure Application Module (SAM) de recarregamento do sistema de transportes
da cidade de Lisboa. Considera-se que uma transação engloba o tempo de deteção de um cartão no
leitor, e o tempo de leitura e escrita de dados no cartão, e a verificação de todas as regras de negócio.
Como já foi dito foi utilizado um cartão CTS512B, e também um smartphone LG Nexus 5 2013.
Neste smartphone foi instalada a aplicação de teste desenvolvida que permite a utilização dos serviços
desenvolvidos. Quer o cartão, quer o Cartão Virtual (CV) utilizado foram previamente carregados com
bilhetes iguais.
5.1.2 CV Online
Rede WiFi Local Rede WiFi c/ 3GRound Trip Time (RTT) (ms) 12 57
Download (Mbps) 126.18 2.64Upload (Mbps) 8.64 1.24
Tabela 5.1: Dados indicativos das ligações de rede utilizadas.
A solução com o CV alojado no SC, foi a primeira testada, e para tal foi carregado num CTS512B
um contrato igual ao carregado no CV. Foram efetuadas três medições: a primeira com o CTS512B, a
segunda com o Dispositivo Móvel (DM) ligado à mesma rede sem fios que o SC, e a terceira com o DM
60
Figura 5.1: Comparação dos tempos de transação medidos com um cartão CTS512B e um CV online. No eixo ver-tical estão identificados os tempos de transação registados em milissegundos. No eixo horizontal está identificadaa amostra utilizada.
ligado a uma rede sem fios criada num router com ligação à internet através de uma ligação de dados
móveis com suporte para 3G e 4G. Este router é uma solução oferecida pela Card4B para instalar em
autocarros, de forma que os passageiros possam ter acesso à internet através desta rede sem fios. Na
tabela 5.1 estão alguns dados relativos à qualidade das ligações de rede utilizadas. Estes dados foram
medidos através da ferramenta online SPEEDTEST1.
Nestas medições o produto carregado nos cartões foi o produto conhecido em Lisboa como Zapping,
e que corresponde ao carregamento de um saldo do qual é descontado o valor correspondente ao preço
da viagem a cada validação. Este produto foi utilizado sem qualquer alteração.
Na figura 5.1 está representado um gráfico, em que o eixo vertical corresponde ao tempo em milis-
segundos da duração das transações, enquanto que no eixo horizontal está identificada uma amostra
recolhida aleatoriamente do conjunto de mil validações realizadas. Neste gráfico podemos verificar que
os tempos relativos às validações com CV online, têm um desempenho bastante inferior ao método
tradicional com cartão de proximidade. Estes apresentam no geral uma maior variação nos tempos
medidos, ao contrário do cartão que apresenta ligeiras alterações. Esta verificação é suportada pelo
gráfico da figura 5.2 onde são apresentadas algumas estatísticas dos dados recolhidos. Neste gráfico
no eixo vertical está igualmente representado o tempo de transação em milissegundos, e no eixo ho-
rizontal estão representadas a média, moda, mediana e desvio padrão dos resultados obtidos. Este
gráfico mostra que o desvio padrão do CTS512B é insignificante quando comparado com as outras
soluções, em que o pior caso é ligeiramente inferior a 500ms.
Com a análise de ambos os gráficos podemos concluir algo que era já esperado: esta solução é
bastante dependente da qualidade da ligação existente para o servidor. Este é um fator que é prati-
camente impossível de controlar, uma vez que depende de diferentes variáveis. Uma possível solução
para o presente problema, seria otimizar a troca de mensagens entre o DM e o SC. A tabela 5.2 contém1SPEEDTEST by Ookla – http://www.speedtest.net
61
Figura 5.2: Estatísticas dos tempos de transação medidos com um cartão CTS512B e um CV online. No eixo ver-tical estão identificados os tempos de transação em milissegundos, e no eixo horizontal as estatísticas calculadas:média, moda, mediana e desvio padrão.
Ordem APDU (hexadecimal) Comando ISO 7816-41o 00A404000A43344243545335313242 SELECT-AID2o 00B0000406 READ3o 00B0000040 READ4o 00D600360800001A5040484EE5 UPDATE BINARY5o 00D60024120000001A6A72822820421EF000000008FD22 UPDATE BINARY
Tabela 5.2: Exemplo de APDU’s emitidas durante uma validação.
uma sequência de Application Protocol Data Unit (APDU)’s capturadas durante a medição de tempos.
Estas APDU’s são emitidas pelo validador, e posteriormente enviadas pelo DM para o SC.
Nesta implementação todas as APDU’s presentes na tabela são reencaminhadas para o SC, o que
faz com que sejam enviadas no total cinco mensagens independentes. Contudo, pela análise da ta-
bela, há mensagens que podem ser truncadas. Por exemplo a primeira mensagem, correspondente ao
SELECT-AID (comando que seleciona a aplicação com que validador irá interagir), pode ser totalmente
tratada no cartão. De resto, existem duas fases: uma de leitura, seguida de uma fase de escrita. Neste
cartão as mensagens de leitura seguem sempre esta ordem. A primeira delas, lê uma parte do cartão
que é imutável, pelo que se pode considerar seguro guardar uma cache desta parte do cartão no DM
sem que a segurança do CV seja comprometida. A segunda APDU de leitura lê o cartão todo, e não
poderá de qualquer forma ser guardada no DM. Desta forma seria possível, após uma primeira leitura
ou validação do cartão, reduzir o número de APDU’s de leitura de duas para apenas uma.
Na segunda fase da validação existem apenas operações de escrita. Nesta fase o validador poderia
otimizar enviando ambas as APDU’s de uma única vez. Isto é possível pois no momento da primeira
escrita já é possível enviar também a segunda, uma vez que os dados já estão disponíveis no validador.
Assim seria possível reduzir as operações de escrita de duas para uma.
Com a aplicação das melhorias mencionadas seria possível reduzir o número de mensagens en-
62
Figura 5.3: Comparação dos tempos de transação medidos com um cartão CTS512B e um CV como token. Noeixo vertical estão identificados os tempos de transação registados em milissegundos. No eixo horizontal estáidentificada a amostra utilizada.
viadas para o servidor para duas. A primeira com a 3a APDU, e a segunda com a 4a e 5a. Através
da medição de tempos de transação no modelo offline, obtemos um tempo médio de 363ms. Assim
podemos estimar que o tempo médio gasto no envio de mensagens para servidor, no pior caso medido,
é de cerca de 2885ms. Desta forma o tempo gasto no envio de duas mensagens é aproximadamente
de 1154ms. Juntando a este valor o tempo de transação offline, verificamos que o tempo de transa-
ção seria aproximadamente 1517ms, o que corresponde a cerca de 46% do tempo médio do pior caso
medido.
5.1.3 CV como Token
Neste cenário repetiu-se o procedimento descrito anteriormente: um cartão de proximidade CTS512B
carregado com o mesmo produto que o CV num token. Neste caso o produto é um Zapping com uma
validade temporal adicionada, ou seja o bilhete não poderá ser utilizado fora da data de início e fim
especificadas.
Na figura 5.3 está ilustrado um gráfico, onde no eixo vertical estão marcados os tempos de transação
medidos em milissegundos, e no eixo horizontal está identificada uma parte da amostra obtida através
da escolha aleatória entre as mil transações efetuadas.
Analisando as linhas podemos verificar que os tempos de transação no CV são inferiores aos tem-
pos do CTS512B. Decompondo a transação podemos identificar as seguintes fases: deteção do cartão,
comunicação por Near Field Communication (NFC), leituras e escritas no cartão e execução das regras
de negócio. A deteção é um dos pontos onde o tempo pode evidentemente ser diferente, uma vez que
o validador irá procurar os diferentes cartões iterativamente, e caso procure primeiro pelo smartphone
do que pelo CTS512B, o tempo de deteção do smartphone será inferior. O tempo de comunicação por
NFC pode-se assumir que seja maior com smartphone, porque apesar de ser o leitor quem estabelece a
63
Figura 5.4: Estatísticas dos tempos de transação medidos com um cartão CTS512B e um CV como token. Noeixo vertical estão identificados os tempos de transação em milissegundos, e no eixo horizontal as estatísticascalculadas: média, moda, mediana e desvio padrão.
frequência de comunicação, neste é executado mais um comando, o Select Application IDentifier (AID).
As leituras e escritas podem ser mais rápidas no smartphone, dado que este tem uma capacidade
de processamento muito elevada comparada com o CTS512B. O tempo de execução das regras de
negócio é igual em ambos os casos, uma vez que o validador executará precisamente as mesmas
regras. Assim podemos concluir que o principal fator que leva a que o smartphone tenha tempos de
transação inferiores ao CTS512B esteja principalmente relacionado com a maior capacidade de pro-
cessamento do primeiro. Adicionalmente a fase de deteção também pode influenciar estar a influenciar
este resultado.
Na figura 5.4 são apresentadas algumas estatísticas dos dados recolhidos. Neste gráfico no eixo
vertical está igualmente representado o tempo de transação em milissegundos, e no eixo horizontal
estão representadas a média, moda, mediana e desvio padrão dos resultados obtidos. De notar nesta
figura o desvio padrão do CV é bastante superior ao do CTS512B, o que permite concluir que há
outros fatores desconhecidos que neste caso influenciam os tempos da transação, estes podem estar
relacionados com o sistema operativo Android, e a forma como este atribui tempo de processador aos
diferentes processos.
5.2 Análise de Ameaças
Nesta secção será feita uma análise de ameaças sobre o trabalho realizado. Com esta análise
pretende-se verificar a segurança geral da solução, e identificar os pontos onde é necessário continuar
a desenvolver este trabalho.
Esta análise começará por identificar os principais elementos da solução a proteger, e.g. o saldo
do cliente. De seguida serão identificados os principais componentes da solução pelos quais estes
elementos são manipulados, e qual o fluxo destes elementos na solução. Através do modelo STRIDE
64
serão identificadas as principais ameaças, e de seguida calculado o risco de cada uma através do
modelo DREAD.
Assets
Os assets de um sistema como o apresentado, são os elementos com valor para o sistema e/ou
utilizador. Desta forma sempre que um deles esteja exposto indevidamente, devido à ação de um
atacante, considera-se que existe uma ameaça no sistema. Na seguinte tabela estão identificados os
principais assets do sistema desenvolvido:
ID AssetA1 Cartão Virtual (cloud)A2 Cartão Virtual (token)A3 SaldoA4 Token de autenticação
Tabela 5.3: Principais assets do sistema.
Interação entre Componentes e Assets
Ao identificar os principais componentes do sistema que direta ou indiretamente interagem com os
assets identificados anteriormente, podemos limitar as áreas de exposição a ataques. Nesta secção
assume-se que o único ponto de entrada do SC é através dos serviços Web, e que os servidores de
TK e base de dados estão devidamente isolados não sendo possível um atacante fora da rede destes
servidores lhes aceder remotamente, assim como os validadores estão devidamente protegidos contra
ataques ao seu software ou chaves. Assume-se também que a aplicação que corre no DM pode não
ser fidedigna embora execute os protocolos da solução corretamente.
Os principais componentes da solução são o SC, o DM e os validadores. Na tabela seguinte estão
identificados os principais componentes, e como interagem com assets identificados anteriormente.
Componente/Asset A1 A2 A3 A4SC
√ √ √ √
DM√ √
–√
Validador√ √
– –
Tabela 5.4: Relação entre assets e os principais componentes da solução.
Analisando a tabela 5.4, é possível quais os componentes que interagem diretamente com os assets
identificados. Pela análise das colunas, podemos também concluir se existe um fluxo de dados entre
os diferentes componentes, relativamente a um dado asset :
• A1 – Este asset, pela análise da primeira coluna, está exposto nas diferentes componentes, o que
permite concluir que existe um fluxo de dados deste asset entre as diferentes componentes. Neste
caso sendo um CV guardado no SC, o fluxo de dados corresponde a APDU’s que possivelmente
alterarão o estado deste. As APDU’s são emitidas pelo validador, e enviadas para o SC através
do DM.
65
• A2 – Este asset, um token, está igualmente exposto nas diferentes componentes, contudo neste
caso o token é numa primeira fase transferido do SC para o DM, e posteriormente executadas
APDU ’s que podem alterar o seu estado. Este tem a particularidade de até um tempo definido em
minutos antes do início da sua validade se encontrar cifrado.
• A3 – Este asset é exclusivamente gerido pelo SC sendo que só alterado por este. Para este ser
incrementado um utilizador tem de através um serviço externo efetuar um pagamento, confirmado
posteriormente entre o SC e o serviço de pagamentos. Para ser descontado será na sequência
de um carregamento do CV.
• A4 – Este asset é gerado pelo SC como resultado da autenticação de um utilizador, e enviado
para o DM para este utilizar na autenticação dos seus pedidos.
Identificação de Ameaças
Com base nos fluxos de dados entre componentes, e conhecidas as fragilidades de cada com-
ponente, serão agora apresentadas as principais ameaças identificadas. Estas foram identificadas
segundo o modelo STRIDE e estão resumidas na seguinte tabela:
ID Categoria Descrição
T1 Information DisclosureUm CV no formato de token depois de decifrado, fica vulnerávela cópia, podendo o atacante utilizar este token para aceder aosserviços de transporte durante a validade deste.
T2 Information DisclosureDurante uma validação ou uma leitura do CV guardado no SC, todoo conteúdo do cartão é lido. Desta forma uma cópia integral docartão é transportada movida até ao DM onde este fica vulnerável.
T3 Information DisclosureSe um atacante conhecer as APDU’s de leitura utilizadas pelos va-lidadores para aceder ao CV, pode atacar um DM através da inter-face NFC, conseguindo clonar o conteúdo de um CV na totalidade.
T4 Denial of ServiceSe um atacante conhecer as APDU’s de escrita utilizadas pelos va-lidadores para escrever num CV, pode atacar um DM através dainterface NFC, poder apagar todos os contratos do mesmo.
T5 Spoofing IdentityUm atacante que consiga aceder aos tokens de autenticação guar-dados localmente no DM, pode utilizar o sistema fazendo-se passarpela vítima.
Tabela 5.5: Principais ameaças identificadas no sistema.
Documentação de Ameaças
De seguida será apresentada uma descrição formal para cada ameaça identificada anteriormente.
Esta descrição incluíra o principal alvo do ataque, a técnica utilizada para o ataque, e as medidas a
tomar para combater o ataque. A linha relativa ao risco de cada ameaça, foi intencionalmente deixada
em branco, uma vez que este só mais à frente é que será calculado.
66
Descrição Atacante acede ao token de um CV elevando as suas permissões no DMAlvo Token de Cartão Virtual
Risco
Técnica de Ataque Instalação do pacote de super-utilizador dos sistemas Unix, para elevaçãode permissões
Contramedidas Detetar a presença do pacote, e interromper o normal funcionamento daaplicação
Tabela 5.6: Documentação da ameaça T1
Descrição Atacante modifica a aplicação para intercetar as mensagensAlvo Cartão Virtual online
RiscoTécnica de Ataque Acesso físico ou remoto ao dispositivo, e reprogramação da aplicação
Contramedidas Virtualizar um cartão que implemente um protocolo de comunicação se-guro.
Tabela 5.7: Documentação da ameaça T2
Descrição Atacante obtém um Cartão Virtual através de replicação de APDU’sAlvo Cartão Virtual
Risco
Técnica de Ataque Identificação das APDU’s de leitura através da análise do protocolo devalidação, e consequente replicação de APDU’s através da interface NFC
Contramedidas Virtualizar um cartão que implemente um protocolo de comunicação se-guro.
Tabela 5.8: Documentação da ameaça T3
67
Descrição Atacante apaga um Cartão Virtual através de replicação de APDU’sAlvo Cartão Virtual
Risco
Técnica de AtaqueIdentificação das APDU’s de escrita através da análise do protocolo de va-lidação, adulteração de APDU’s, e consequente envio de APDU’s atravésda interface NFC
Contramedidas Virtualizar um cartão que implemente um protocolo de comunicação se-guro.
Tabela 5.9: Documentação da ameaça T4
Descrição Atacante obtém credenciais de acesso ao sistemaAlvo Sistema de autenticação
Risco
Técnica de Ataque Instalação do pacote de super-utilizador dos sistemas Unix, para elevaçãode permissões
Contramedidas Detetar a presença do pacote, e interromper o normal funcionamento daaplicação
Tabela 5.10: Documentação da ameaça T5
Classificação de ameaças
O risco das ameaças anteriormente apresentadas será calculado de acordo com o modelo DREAD.
Para calcular o risco foi utilizada como auxiliar a tabela do anexo D. As classificações das ameaças
podem ter resultados entre 5 e 15. Desta forma considera-se que para valores entre 5 e 7 o risco é
considerado Baixo, entre 8 e 11 Médio, e entre 12 e 15 Alto.
ID D R E A D Total ClassificaçãoT1 2 2 3 2 2 11 MédioT2 2 3 2 3 2 12 AltoT3 2 3 2 3 2 12 AltoT4 3 3 2 3 2 13 AltoT5 3 3 3 3 2 14 Alto
Tabela 5.11: Classificação de ameaças segundo modelo DREAD.
Documentação de Ameaças Após Cálculo de Riscos
Com base nos riscos calculados anteriormente, as ameaças são agora apresentadas com o risco
que cada uma apresenta para o sistema.
Descrição Atacante acede ao token de um CV elevando as suas permissões no DMAlvo Token de Cartão Virtual
Risco Médio
Técnica de Ataque Instalação do pacote de super-utilizador dos sistemas Unix, para elevaçãode permissões
Contramedidas Detetar a presença do pacote, e interromper o normal funcionamento daaplicação
Tabela 5.12: Classificação da ameaça T1
68
Descrição Atacante modifica a aplicação para intercetar as mensagensAlvo Cartão Virtual online
Risco AltoTécnica de Ataque Acesso físico ou remoto ao dispositivo, e reprogramação da aplicação
Contramedidas Virtualizar um cartão que implemente um protocolo de comunicação se-guro.
Tabela 5.13: Classificação da ameaça T2
Descrição Atacante obtém um Cartão Virtual através de replicação de APDU’sAlvo Cartão Virtual
Risco Alto
Técnica de Ataque Identificação das APDU’s de leitura através da análise do protocolo devalidação, e consequente replicação de APDU’s através da interface NFC
Contramedidas Virtualizar um cartão que implemente um protocolo de comunicação se-guro.
Tabela 5.14: Classificação da ameaça T3
Descrição Atacante apaga um Cartão Virtual através de replicação de APDU’sAlvo Cartão Virtual
Risco Alto
Técnica de AtaqueIdentificação das APDU’s de escrita através da análise do protocolo de va-lidação, adulteração de APDU’s, e consequente envio de APDU’s atravésda interface NFC
Contramedidas Virtualizar um cartão que implemente um protocolo de comunicação se-guro.
Tabela 5.15: Classificação da ameaça T4
Descrição Atacante obtém credenciais de acesso ao sistemaAlvo Sistema de autenticação
Risco Alto
Técnica de Ataque Instalação do pacote de super-utilizador dos sistemas Unix, para elevaçãode permissões
Contramedidas Detetar a presença do pacote, e interromper o normal funcionamento daaplicação
Tabela 5.16: Classificação da ameaça T5
5.3 Satisfação de Requisitos
Na presente secção, e face aos resultados apresentados neste capítulo, será apresentado de que
forma os requisitos do trabalho apresentados no capítulo 1 foram atingidos.
5.3.1 Requisitos
• A utilização de um smartphone de forma idêntica aos cartões de proximidade usados atu-
almente, permitindo a validação de um título de viagem apenas aproximando o smartphone
do validador.
69
Requisito verificado. Na secção 4.7 é descrito como é feito o carregamento de um produto num
CV de forma a poder ser utilizado na validação.
• A aquisição de títulos de viagem através de uma aplicação instalada no smartphone, assim
como a consulta de títulos de viagem ainda disponíveis para validar.
Requisito verificado. Na secção 4.7 é descrito como é feito o carregamento de um produto num
CV, e na secção 4.10.1.C é explicado de que forma este pode ser executado através de um
smartphone Android.
• A autenticidade e integridade dos títulos de viagem adquiridos através do smartphone deve
ser garantida.
Requisito verificado. Tal como explicado na secção 4.3, o modelo de dados utilizado no cartão
virtualizado, o CTS512B, requer que sejam gerados certificados, ou códigos Message Authenti-
cation Code (MAC), que são guardados no cartão e utilizados para verificar estas propriedades.
Adicionalmente existem também campos cifrados, o que adiciona também a propriedade de con-
fidencialidade a estes campos.
• A validação de um título de viagem deve ser executada num tempo de ordem equivalente
aos atuais sistemas de bilhética com cartões de proximidade.
Requisito não verificado. Como mostrado na secção 5.1.2, os tempos de transação do modelo
online vão além dos tempos medidos com o cartão de referência CTS512B. Contudo no caso
do modelo offline foram verificados tempos de ordem equivalente, sendo as médias medidas
inferiores.
5.4 Conclusão
Neste capítulo foi feita uma avaliação em termos de desempenho e segurança do sistema. Este
capítulo permitiu efetuar uma análise crítica ao sistema e identificar não só os seus pontos fortes,
como as principais fraquezas que devem ser tratadas de forma a permitir criar uma melhor solução de
bilhética.
Os principais problemas de desempenho identificados no modelo online, presumivelmente, também
se verificarão em qualquer outro protocolo seguro que se possa implementar para colmatar as falhas
de segurança identificadas na análise de ameaças. As diferentes redes utilizadas permitiram verificar
situações com grandes atrasos na rede, o que levou a que o protocolo de validação online, definido na
secção 3.5, fosse constantemente bloqueado devido aos elevados tempos de RTT. Estes são casos de
falsos positivos, em que foi acionado um mecanismo de defesa para um ataque que efetivamente não
existia. Este mecanismo terá de ser revisto para evitar situações destas.
A nível da análise de segurança, as vulnerabilidades encontradas, com a exceção de uma, corres-
pondem em às vulnerabilidades do CTS512B. Desta forma considera-se que o sistema tem um nível
de segurança aceitável.
70
Assim os problemas aqui encontrados devem ser referenciados para análise futura na continuação
deste trabalho.
71
72
6Conclusão e Trabalho Futuro
73
Este trabalho centrou-se na utilização de um smartphone, com o Sistema Operativo (SO) Android
KitKat e Near Field Communication (NFC), como suporte físico para contratos de transportes públicos,
com o mesmo grau de segurança associado aos cartões de proximidade. Para tal foi estudado o nível
de segurança que se pode obter com um smartphone, quando não está disponível qualquer tipo de
hardware seguro, o chamado Elemento Seguro (ES). Desta forma foi utilizada a tecnologia Host-based
Card Emulation (HCE) do Android KitKat, que permite a emulação de um cartão de proximidade sem
ES.
A solução implementada baseia-se num sistema composto por um back-office, neste trabalho cha-
mado de Serviço Cloud (SC), e uma aplicação de smartphone. O sistema é também composto por
validadores, e dispositivos de fiscalização. Estes foram utilizados tal como já existiam implementados,
de forma a minimizar o impacto da adoção desta solução, nos sistemas já existentes. Nos validadores
utilizados foi apenas necessário configurar os mesmos de forma a reconhecerem o smartphone como
um cartão de proximidade.
Neste trabalho foi proposto o conceito de Cartão Virtual (CV), prototipada a sua realização. Um CV
é um ES guardado na base de dados do SC. No CV é virtualizado um cartão de proximidade, onde são
guardados os contratos adquiridos pelo utilizador. O processo de carregamento é totalmente executado
no SC não sendo necessário a interação com uma bilheteira, e permitindo ao utilizador efetuar estas
operações totalmente através do seu smartphone. Para a validação, situação em que o validador terá
que interagir com CV, foram criados dois cenários: online e offline. No cenário online o smartphone terá
que estar ligado ao SC, para onde deverá reencaminhar todas as mensagens recebidas do validador.
Desta forma a validação será executada entre o validador e o SC, atuando o smartphone apenas como
intermediário. No modelo offline o utilizador terá que descarregar previamente para o smartphone, um
token que irá utilizar posteriormente durante a validação. Um token é uma versão do CV, em que o
contrato nele escrito é limitado em termos de valor, e validade temporal. Desta forma caso um atacante
consiga aceder ao token de um utilizador, terá uma janela temporal reduzida para poder utilizar o
serviço de transportes, e também só o poderá utilizar uma vez, dado que o contrato carregado no token
só permite ser validado uma vez. De forma a aumentar a segurança do token descarregado, este é
cifrado com uma chave obtida através de um código numérico de quatro dígitos. Este código terá que
ser inserido pelo utilizador antes de validar o seu título de viagem.
Os resultados obtidos mostram que a solução pode ser facilmente adotada nos transportes públicos,
uma vez que cumpre os requisitos impostos. Esta permite ao utilizador adquirir os seus títulos de
viagem em qualquer local, desde que tenha acesso à internet no seu smartphone, e sem necessitar
de qualquer dispositivo adicional que não o próprio smartphone. No entanto a nível de segurança
existem dois principais ataques aos quais o cliente está vulnerável: o primeiro através da interface NFC
do smartphone em que o atacante pode copiar ou invalidar o CV do cliente (seja no modelo online
ou offline); o segundo acontece no caso em que o utilizador alterou o SO do seu smartphone para
permitir elevação de permissões a uma dada aplicação, e um atacante pode igualmente aceder ao
conteúdo do CV em ambos os cenários online e offline. Contudo o SC é capaz de identificar situações
anormais, como um ataque, através da fase de reconciliação e agir perante o utilizador ao qual o
74
ataque está relacionado, bloqueando a sua conta, e impedindo a utilização dos serviços através de
uma lista “negra”. A fase de reconciliação acontece sempre que um validador comunica as transações
de validação efetuadas durante um dia ao SC. Estas transações são relacionadas com os registos de
venda e permitem calcular receitas, fazer devoluções de títulos de viagem expirados e não utilizados, e
também deteção de fraude como já foi dito.
Neste trabalho pode-se também concluir que a solução que melhor se aplica aos serviços de trans-
portes atualmente, é a solução baseada em tokens. Esta solução permite um bom nível de segurança,
aliada a tempos de transação equivalentes à correspondente solução com cartões de proximidade. Adi-
cionalmente o modelo online pode ser utilizado como complementar do anterior, sendo utilizado numa
situação em que o utilizador se esqueceu de descarregar o token, ou em casos como os autocarros de
longo curso, em que são feitas poucas paragens para entrada e saída de passageiros. Esta solução
pode também ser utilizada noutros serviços como estacionamentos, ou salas de espetáculos, que te-
nham requisitos temporais mais flexíveis. Com os constantes avanços na largura de banda das redes
móveis, acredita-se que esta solução pode vir a ser a principal utilizada neste tipo de sistemas.
Trabalho Futuro
O trabalho desenvolvido cumpre os objetivos estabelecidos como visto anteriormente, contudo exis-
tem pontos onde podem ser desenvolvidas alterações que melhorem a segurança de todo o sistema, e
também a usabilidade deste.
Alterações Importantes
De seguida serão apresentadas as alterações que se considera que são espectáveis de ser imple-
mentadas.
Virtualizar um cartão de proximidade com protocolo de comunicação seguro
Como explicado anteriormente nas conclusões, neste trabalho foi criado um CV no qual é virtua-
lizado um cartão de proximidade existente atualmente nos serviços de transporte. Esta virtualização
apenas recebe dois tipos de comandos, leituras e escritas. Desta forma esta virtualização permitirá
leituras e escritas de qualquer dispositivo que conheça o protocolo de comunicação deste cartão. Este
problema pode ser resolvido através da virtualização de um cartão com um protocolo de comunicação
que permita autenticar o dispositivo que está a efetuar a operação de escrita.
De acordo com o descrito no parágrafo anterior, o problema poderia ser resolvido através da virtu-
alização de um cartão de proximidade Calypso. Estes cartões requerem que exista uma chave crip-
tográfica partilhada entre si e o validador. A estrutura de ficheiros em que estes estão organizados,
permite a definição de ficheiros privados, os quais podem ser utilizados para guardar estas chaves. A
partir da chave existente no cartão e validador, é possível executar um protocolo de autenticação mútua,
de forma a que o cartão não execute certas operações comandadas por um dispositivo devidamente
autenticado.
75
Redução do número de mensagens trocadas entre smartphone e servidor
Um dos problemas identificados na modelo online está relacionado com o número de mensagens
trocadas durante a validação entre smartphone e servidor. Devido aos atrasos provenientes da ligação
ao servidor, o número de mensagens trocadas entre ambos, atrasa consequentemente o processo de
validação. Estas mensagens correspondem aos comandos de leitura e escrita do cartão.
O problema apresentado pode ser atenuado através de mecanismos de caching, e divisão da vali-
dação em duas fases: leituras e escritas. Desta forma na primeira fase seria lido o cartão por inteiro.
Na segunda fase seriam escritas numa só operação todas as alterações efetuadas no cartão. Desta
forma seria possível reduzir as mensagens trocadas e aumentar o desempenho da validação significa-
tivamente.
Deteção de smartphones que permitam elevação de permissões
Algumas das vulnerabilidades identificadas neste trabalho, acontecem no sistema Android, e são
possíveis devido à instalação de um pacote no sistema, que permite a elevação de permissões, que
consequentemente leva a que um atacante possa aceder a ficheiros que até então eram exclusivos
das aplicações que os criaram. Uma das formas de prevenir este ataque passa por detetar quando a
elevação de permissões é possível, e bloquear certas funcionalidades da aplicação de forma a evitar
possíveis ataques.
Outras Alterações
Os seguintes pontos são possíveis futuras alterações que poderão ser interessantes no sistema,
contudo não são urgentes para o bom funcionamento da solução.
Criação de tokens a partir de um determinado contrato
Tal como referido no ponto anterior, neste trabalho foi utilizado apenas um tipos de produto. Desta
forma no modo offline, na criação de um token, é sempre carregado um novo produto num novo cartão
independentemente do contrato que estiver carregado no CV. Assim uma possível alteração neste
trabalho é a adaptação para todos os tipos de produtos utilizados pelos operadores (passes, viagens
singulares, saldo, etc), e estes serem carregados no CV guardado no servidor. Sempre que o utilizador
desejar criar um novo token para utilizar no modo offline, um processo transformaria qualquer tipo de
contrato guardado no CV num token, e no caso de o contrato original se tratar de um contrato dedutível
(viagens singulares ou saldo), fazer o respetivo desconto. O token gerado deve continuar a respeitar as
regras impostas a estes: validade temporal e valor reduzidos.
Validação offline com alteração dos validadores
Na apresentação da solução, capítulo 3, foi apresentada uma solução (secção 3.6) que definia um
método alternativo de criação de tokens. Neste método os tokens são cifrados com chaves do validador
e do utilizador, pelo que só depois de o utilizador inserir o seu código secreto (a partir do qual é calculada
76
a chave), pode iniciar a validação. No início da validação é executado um processo de autenticação
mútua, entre o validador e o smartphone. Após uma autenticação correta é enviado na totalidade o
token para o validador, onde este será decifrado e validado. Portanto, após o processo de autenticação
e envio do token, não existe qualquer interação entre smartphone e validador, o que leva a que não
fique registado no smartphone qualquer prova da utilização daquele título de viagem. Nesta adaptação
é criado um registo auxiliar enviado para o smartphone após a validação. Neste são escritas todas as
alterações a efetuar no token original, de forma a que através da junção de ambos se consiga perceber
se o token já foi utilizado.
Pelos motivos apresentados, e dado que a solução poderá enriquecer o modo offline graças ao me-
canismo de autenticação mútua adicionado, foi desenhada uma nova adaptação, que será aqui descrita.
De notar que esta adaptação não foi implementada devido às restrições temporais de implementação
do projeto.
Para suportar o registo das operações de validação no Dispositivo Móvel (DM), é necessário adi-
cionar um novo conceito, os recibos. Um recibo é o resultado da validação de um token, e contém o
conjunto de operações que quando aplicadas ao token, permitem obter a imagem do CV resultante da
validação. No final do protocolo de validação, o recibo resultante deve ser enviado para o DM. No caso
de várias validações do mesmo token (e.g. transbordo) ou fiscalização, o recibo produzido na primeira
validação deve ser enviado juntamente com o token.
Notas Finais do Autor
A realização deste trabalho foi uma experiência bastante desafiante e acima de tudo enriquecedora.
As tecnologias de comunicação por proximidade sempre me fascinaram, e neste trabalho consegui
desenvolver bons conhecimentos sobre o assunto. No restante trabalho realizado, nomeadamente
os diferentes servidores e aplicações, frequentemente me deparei com casos estudados durante o
mestrado, e foi sem dúvida interessante poder aplicar os conhecimentos adquiridos ao longo do curso.
Posso assim dizer que termino este trabalho e consequentemente esta fase da minha vida com um
sentimento de realização.
77
78
Bibliografia
[1] UITP, “The global public transport awards 2015,” 2015.
[2] J. R. Goheen, “U.S. Patent 5724520A, Electronic ticketing and reservation system and method,”
Março 1998.
[3] I. Technology, “NFC-enabled Handset Shipments to Reach Three-Quarters of a Billion in 2015,”
IHS Technology, Junho 2015.
[4] D. Li, Y. Wang, L. Hu, J. Li, X. Guo, J. Lin, and J. Liu, “Client/server framework-based passenger line
ticket system using 2-D barcode on mobile phone,” Proceedings of the International Conference on
E-Business and E-Government, ICEE 2010, pp. 97–100, 2010.
[5] D. Skarica, H. Belani, and S. Illes, “Implementation and evaluation of mobile ticket validation sys-
tems for value-added services,” SoftCOM 2009 - 17th International Conference on Software, Tele-
communications & Computer Networks, 2009.
[6] ISO/IEC, “Identification cards - contactless integrated circuit cards - proximity cards,” International
Organization for Standardization, ISO 14443, 2008.
[7] J. Ferrari, R. Mackinnon, S. Poh, and L. Yatawara, “Smart Cards: A Case Study, International
Technical Support Organization,” Outubro 1998.
[8] E. Wolfgang, Rankl, Wolfgang, “RFID Handbook Fourth Edition,” p. 1043, 2010.
[9] ISO/IEC, “Information technology – security techniques – message authentication codes (macs)
– part 1: Mechanisms using a block cipher,” International Organization for Standardization, ISO
9797-1, 2011.
[10] INOV, “SAM Study,” 2014.
[11] ASK, “C.ticket Product Sheet,” Fevereiro 2015.
[12] C. N. Association, “Calypso General Overview,” Outubro 2014.
[13] ITSO, “Interoperable public transport ticketing using contactless smart customer media – Part 10:
Customer Media Definitions, Issue Number 2.1.4,” Fevereiro 2010.
[14] E. Desai and M. Shajan, “A Review on the Operating Modes of Near Field Communication,”
International Journal of Engineering and Advanced Technology, vol. 2, no. 2, pp. 322–325, 2012.
[Online]. Available: http://www.doaj.org/doaj?func=fulltext&aId=1217836
79
[15] INOV, “Virtual Card Study,” 2014.
[16] SIMalliance, “NFC Secure Element Stepping Stones,” no. July, pp. 1–75, 2013.
[17] T. Janssen, “HCE security implications, analyzing the security aspects of HCE,” p. 9, 2013.
[18] S. L. Ghiron, S. Sposato, C. M. Medaglia, and A. Moroni, “NFC Ticketing: A Prototype
and Usability Test of an NFC-Based Virtual Ticketing Application,” 2009 First International
Workshop on Near Field Communication, pp. 45–50, 2009. [Online]. Available: http:
//ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5190416
[19] W. J. Wu and W. H. Lee, “An NFC E-ticket system with offline authentication,” pp. 1–5, 2013.
[20] S. M. Nasution, E. M. Husni, and A. I. Wuryandari, “Prototype of train ticketing application using
Near Field Communication (NFC) technology on Android device,” Proceedings of the 2012 Interna-
tional Conference on System Engineering and Technology, ICSET 2012, 2012.
[21] SimAlliance, “Secure Element Deployment & Host Card Emulation,” pp. 1–13, 2014.
[22] BellID, “Secure Element in the Cloud,” 2013. [Online]. Available: http://www.bellid.com/resources/
brochures/secure-element-in-the-cloud/,vistoem21-11-2015
[23] P. Urien, “Cloud of secure elements: An infrastructure for the trust of mobile NFC
services,” 2014 IEEE 10th International Conference on Wireless and Mobile Computing,
Networking and Communications (WiMob), pp. 213–218, 2014. [Online]. Available: http:
//www.scopus.com/inward/record.url?eid=2-s2.0-84917675078&partnerID=tZOtx3y1
[24] T. Dierks and E. Rescorla, “The transport layer security (tls) protocol version 1.2,” Internet Requests
for Comments, RFC Editor, RFC 5246, August 2008, http://www.rfc-editor.org/rfc/rfc5246.txt.
[Online]. Available: http://www.rfc-editor.org/rfc/rfc5246.txt
[25] S. van Klaarbergen, “Mobile Payment Transactions : BLE and/or NFC?” 2013.
[26] S. Josefsson, “Pkcs 5: Password-based key derivation function 2 (pbkdf2) test vectors,” Internet
Requests for Comments, RFC Editor, RFC 6070, January 2011.
[27] E. Rescorla, “Http over tls,” Internet Requests for Comments, RFC Editor, RFC 2818, May 2000,
http://www.rfc-editor.org/rfc/rfc2818.txt. [Online]. Available: http://www.rfc-editor.org/rfc/rfc2818.txt
[28] M. Jones, J. Bradley, and N. Sakimura, “Json web token (jwt),” Internet Requests for Comments,
RFC Editor, RFC 7519, May 2015, http://www.rfc-editor.org/rfc/rfc7519.txt. [Online]. Available:
http://www.rfc-editor.org/rfc/rfc7519.txt
[29] Y. Sheffer, R. Holz, and Saint-Andre, “Summarizing known attacks on transport layer security (tls)
and datagram tls (dtls),” Internet Requests for Comments, RFC Editor, RFC 7457, February 2015,
http://www.rfc-editor.org/rfc/rfc7457.txt. [Online]. Available: http://www.rfc-editor.org/rfc/rfc7457.txt
[30] ISO/IEC, “Identification cards - integrated circuit cards – part 4: Organization, security, and com-
mands for interchange,” International Organization for Standardization, ISO 7816-4:2013, 2013.
80
ARESTful API
A-1
BInterface Biblioteca Android
B-1
public interface VCardClient public void CreateUserAsync(String Name, String Email, String Password, String PinCode, AsyncResponseCallback<Boolean> callback); public void LoginAsync(String Email, String Password, AsyncResponseCallback<Boolean> callback); public void UpdateUserAsync(String Name, String Email, String Password, String PinCode, AsyncResponseCallback<JsonElement> callback); public void GetUserAsync(AsyncResponseCallback<JsonElement> callback); public void UserDevicesAsync(AsyncResponseCallback<JsonElement> callback); public void DeleteDeviceAsync(String DeviceId, AsyncResponseCallback<Boolean> callback); public void GetPaymentMethodsAsync(AsyncResponseCallback<JsonElement> callback); public void PaymentBeginAsync(String Method, String Amount, AsyncResponseCallback<JsonElement> callback); public void PaymentEndAsync(String Method, String PayerId, String PaymentId, AsyncResponseCallback<JsonElement> callback); public void PaymentCancelAsync(String Method, String PaymentId, AsyncResponseCallback<Boolean> callback); public void GetAccountBalanceAsync(AsyncResponseCallback<JsonElement> callback); public void CreateCardTokenAsync(Long DateInitial, AsyncResponseCallback<CardToken> callback); public void LoadCardAsync(Integer Amount, AsyncResponseCallback<JsonElement> callback); public void GetCardBalanceAsync(AsyncResponseCallback<JsonElement> callback); public List<CardToken> ListCreatedCardTokens(); public boolean OpenToken(long id, char[] pin) throws VCardException; public CardToken GetOpenToken(); public void UseOnlineVCard(); public void UseOfflineVCard(); public VCardMode GetVCardMode(); public boolean LoggedIn();
CDiagrama de Classes
C-1
User
PropertiesIdNameEmailPassword
Navigation PropertiesDevicesAccountPBKey
Account
PropertiesIdBalance
Navigation PropertiesVCardVCardTokenPaymentRequest
Device
PropertiesIdUserIdNameDeviceId
Navigation PropertiesOwnerAccessTokens
VCard
PropertiesIdDataAccountId
Navigation PropertiesLoadRequest
VCardToken
PropertiesIdDataAccountIdDateInitialDateFinalAmountUsed
Navigation PropertiesLoadRequest
PaymentRequ…
PropertiesIdPaymentIdStateProductIdPriceCurrencyPaymentMethodRedirectURLPaymentDataPayerIdAccountId
Navigation PropertiesLoadRequest
PropertiesIdProdIdPriceSaleDateStateLoadResultResultantBalanceDateInitialDateFinalVCardId
Navigation PropertiesVCardVCardToken
AccessTokens
PropertiesIdAuthTokenRefreshToken
Navigation Properties
PBKey
PropertiesIdAlgoHashSizeCiclesB64SaltB64Key
Navigation Properties
1 *1
0..1
10..1
1
*
1
*
0..1
*
0..1
1
1 1
1 1
DRisk Assessment
D-1
Fonte: https://msdn.microsoft.com/en-us/library/ff648644.aspx#c03618429_011 DREAD The problem with a simplistic rating system is that team members usually will not agree on ratings. To help solve this, add new dimensions that help determine what the impact of a security threat really means. At Microsoft, the DREAD model is used to help calculate risk. By using the DREAD model, you arrive at the risk rating for a given threat by asking the following questions:
Damage potential: How great is the damage if the vulnerability is exploited? Reproducibility: How easy is it to reproduce the attack? Exploitability: How easy is it to launch an attack? Affected users: As a rough percentage, how many users are affected? Discoverability: How easy is it to find the vulnerability?
You can use above items to rate each threat. You can also extend the above questions to meet your needs. For example, you could add a question about potential reputation damage: Reputation: How high are the stakes? Is there a risk to reputation, which could lead to the loss of customer trust? Ratings do not have to use a large scale because this makes it difficult to rate threats consistently alongside one another. You can use a simple scheme such as High (1), Medium (2), and Low (3). When you clearly define what each value represents for your rating system, it helps avoids confusion. Table 3.6 shows a typical example of a rating table that can be used by team members when prioritizing threats. Table 3.6 Thread Rating Table
Rating High (3) Medium (2) Low (1)
D Damage potential
The attacker can subvert the security system; get full trust authorization; run as administrator; upload content.
Leaking sensitive information
Leaking trivial information
R Reproducibility The attack can be reproduced every time and does not require a timing window.
The attack can be reproduced, but only with a timing window and a particular race situation.
The attack is very difficult to reproduce, even with knowledge of the security hole.
E Exploitability A novice programmer could make the attack in a short time.
A skilled programmer could make the attack, then repeat the steps.
The attack requires an extremely skilled person and in-depth knowledge every time to exploit.
A Affected users All users, default configuration, key customers
Some users, non-default configuration
Very small percentage of users, obscure feature; affects anonymous users
D Discoverability Published information explains the attack. The vulnerability is found in the most commonly used feature and is very noticeable.
The vulnerability is in a seldom-used part of the product, and only a few users should come across it. It would take some thinking to see malicious use.
The bug is obscure, and it is unlikely that users will work out damage potential.
After you ask the above questions, count the values (1-3) for a given threat. The result can fall in the range of 5-15. Then you can treat threats with overall ratings of 12-15 as High risk, 8-11 as Medium risk, and 5-7 as Low risk.
ETempos Medidos em Transações de
Validação
E-1
Online Offline CTS512B (ms) VC Online Local Network (ms) VC Online 3G Network (ms) CTS512 B (ms) VC Token (ms)
426 944 3045 434 491 424 848 2992 432 343 425 753 2970 431 334 425 741 3205 432 353 425 657 3050 422 343 425 684 2946 423 367 425 758 3200 423 356 427 714 2821 424 347 425 660 2900 424 402 428 888 3118 424 339 426 744 2895 424 347 428 697 2929 424 383 426 736 3250 424 328 429 768 2801 425 350 428 841 2822 424 356 432 1038 3016 425 361 432 833 3068 426 350 432 737 3122 425 355 433 718 2849 427 356 433 730 3728 426 358 423 733 3004 427 351 422 713 3191 427 406 423 804 3135 427 388 422 780 3196 428 349 424 824 2908 428 361 424 735 2909 428 384 425 756 2747 427 329 426 739 2835 429 368 426 731 3136 430 332 426 730 3038 428 352 427 765 3160 430 345 426 742 3523 430 384 426 811 3085 430 375 426 644 2883 431 348 428 574 2831 431 354 427 808 2949 431 341 428 755 2810 432 347 427 700 2933 431 477 430 714 2939 423 342 429 750 3037 424 433 429 815 3181 423 282 428 763 3001 422 302
430 753 3305 424 393 430 777 2973 424 378 430 667 3327 423 344 430 701 3153 424 383 431 740 2834 424 353 431 755 3136 424 349 431 767 3456 425 436 432 760 3158 426 342 432 779 3254 425 375 431 669 3837 425 361 433 799 3659 426 353 432 755 3944 425 356 423 788 3357 427 353 423 760 3549 426 429 424 840 3289 428 394 424 699 3019 428 339 424 723 3173 428 381 423 769 3266 430 368 424 762 3332 428 387 424 800 2883 429 337 425 709 3081 429 366 426 711 2453 429 387 426 726 2739 430 337 426 726 2704 436 341 428 636 3035 431 355 426 713 3100 429 352 428 788 3108 431 339 428 732 3169 431 388 428 761 3225 431 337 428 757 3315 432 336 429 717 3785 422 341 430 639 3837 423 375 430 894 3204 422 304 429 939 3019 424 373 429 903 2986 424 355 430 916 2916 423 422 430 833 3005 424 343 429 1065 3224 425 352 431 902 2938 423 374 429 804 3131 425 375 524 777 3090 424 391 432 837 2956 425 321 432 975 3046 426 354 433 630 2893 426 390 433 693 3036 426 453
423 723 2740 427 346 425 693 3114 428 358 423 688 3118 426 424 424 785 3043 426 343 423 756 3107 427 464 424 725 3071 428 344 424 818 2978 427 442 426 774 3112 428 338 426 786 3141 429 379 426 725 2835 429 329 427 642 2833 430 309 427 687 2853 430 351 427 755 2862 431 333 427 819 3487 430 439 428 677 3328 430 341 428 1017 3136 430 379 428 743 3389 431 383 426 719 3204 433 333 429 655 3046 431 364 428 680 3133 421 361 428 710 2855 423 371 429 761 3094 422 349 431 802 3061 422 439 429 763 3527 423 423 431 771 3254 425 428 430 746 3264 423 399 435 752 3492 425 323 429 663 3352 424 347 432 627 2792 423 347 432 781 2816 426 346 432 710 2809 426 369 432 729 2882 426 372 432 871 2836 426 370 431 796 2854 426 337 423 739 3373 427 357 423 779 3120 427 368 426 736 4315 427 397 424 727 2794 427 372 425 761 2959 426 336 425 725 3025 427 332 424 737 3423 429 340 424 792 4103 429 340 425 747 4137 429 406 425 825 3571 428 332 425 645 3054 430 351
426 710 2976 430 350 428 765 2978 430 383 425 763 2898 430 416 427 701 2835 431 375 427 723 2724 430 341 427 815 3929 431 348 429 742 3645 431 389 429 759 3122 431 353 429 773 3025 423 362 428 763 3270 422 351 427 801 3330 423 357 430 817 3130 424 383 429 792 3106 422 342 428 725 3101 424 340 430 717 3146 424 379 430 764 3109 425 320 430 826 3000 425 342 432 638 3334 425 337 431 715 3200 425 368 432 711 2903 426 382 432 734 2841 425 419 431 762 2819 429 349 432 845 3622 523 278 422 723 3147 427 342 423 809 3202 426 324 423 762 3306 428 347 423 804 4215 428 352 422 758 3183 428 349 424 736 3246 428 351 424 654 3734 428 411 426 725 3450 429 442 424 722 3484 429 391 425 782 3165 429 334 426 779 3127 429 363 426 974 3172 430 358 427 1004 3217 428 411 428 753 2924 430 355 427 787 2723 432 346 428 749 2812 432 346 426 1021 2659 431 342 427 828 3427 433 366 428 1202 2830 432 378 427 698 2347 422 363 429 961 2281 422 373 430 886 2662 423 366
428 1088 2730 424 506 429 771 2678 424 360 430 755 2824 423 325 429 768 2716 424 346 430 707 3226 423 337 432 731 3120 424 330 431 718 2812 424 277 432 702 3415 426 396 431 776 3157 425 339 432 774 3064 426 337 431 738 2813 426 384 431 763 2784 427 380 423 934 2919 427 315 423 747 4009 427 351 424 781 2819 430 352 423 778 2994 427 347 426 754 3040 428 346 424 722 2714 427 350 423 719 2807 427 364 424 754 3063 428 359 426 754 3060 429 371 426 751 2943 429 343 424 759 3379 430 382 426 737 3468 430 408 426 915 2835 429 471 426 710 2868 429 318 427 713 2788 431 370 428 738 2825 430 360 429 775 3117 431 424 427 855 3163 431 347 429 714 3325 432 336 428 723 3194 422 384 428 797 3199 422 320 428 714 3006 422 421 428 787 2921 423 317 429 894 2908 425 386 429 783 2923 424 392 431 691 2727 424 334 430 735 2781 423 458 431 815 2962 424 336 430 753 2747 424 339 431 822 2735 425 380 431 702 3108 425 343 433 772 3151 426 455 432 777 3043 425 329
433 723 2727 427 347 423 746 2988 427 411 422 843 3562 427 336 423 604 3132 426 353 424 877 2948 426 396 424 791 3149 427 351 423 739 3144 428 385 424 737 3365 427 344 425 848 3070 429 345 426 816 4318 429 390 425 680 3139 429 326 426 614 3062 430 375 424 758 3136 430 387 427 774 3228 429 356 426 641 3430 430 346 425 825 3148 430 357 426 745 3097 432 354 427 773 3720 431 361 428 724 2996 431 351 427 813 2819 432 307 427 671 2961 422 334 429 735 2886 422 345 428 787 2829 423 383 429 744 2831 422 337 428 772 2867 424 337 428 759 3430 423 380 431 872 3489 424 326 431 871 3084 424 498 430 976 2877 424 338 430 848 2898 424 353 431 836 2714 425 354 432 943 2940 426 444 431 690 2741 426 322 433 751 3009 425 378 432 765 2899 427 338 422 754 2537 426 358 423 900 2841 428 374 423 653 2936 427 353 422 714 3003 428 357 424 765 2782 428 354 423 866 2896 427 382 424 761 2942 430 459 424 728 2861 428 435 424 752 2850 429 326 424 774 2891 430 329
427 1127 2954 430 379 424 892 2877 430 463 427 789 2826 430 380 426 864 2941 431 335 427 1113 2995 430 384 426 876 2885 430 329 428 824 3086 431 354 428 739 3302 431 347 427 764 3006 431 352 429 878 2968 423 348 429 706 3019 422 377 429 716 2903 423 334 428 744 3064 423 341 430 795 2998 423 338 430 754 2780 424 393 431 751 3199 423 343 430 774 2933 425 354 430 792 2948 424 348 430 813 2960 424 351 432 768 2848 425 387 432 899 2986 426 335 433 672 2818 427 339 430 628 2965 426 339 433 774 2994 427 345 422 690 3553 427 382 422 740 3296 426 339 423 910 3280 428 382 422 691 3185 427 335 425 798 3081 427 364 426 761 3152 428 362 423 696 4478 428 349 425 871 3344 429 405 424 759 3177 429 364 424 753 2966 429 389 425 746 3238 430 349 427 721 3245 430 409 425 783 2605 430 374 427 766 2958 430 372 428 1005 3164 431 348 428 736 3119 431 361 429 750 4703 432 368 427 776 3385 431 381 429 787 3191 431 299 428 708 3005 421 283 428 967 3588 422 299
430 730 3355 423 316 429 757 2931 423 428 430 745 3256 424 332 429 768 3177 423 353 430 753 2868 424 343 430 734 2917 424 352 431 699 2999 425 356 431 737 2982 425 384 431 775 2941 426 343 431 728 3127 426 385 432 926 3244 426 351 430 755 3538 425 362 432 776 3199 427 365 422 781 3512 427 318 424 801 3314 426 380 422 762 3789 428 340 425 839 3189 427 377 425 748 3115 427 325 425 761 3247 428 348 423 856 4104 429 384 427 794 4805 428 384 425 919 6021 429 335 425 853 3157 429 365 427 896 4552 430 410 424 825 4271 431 372 425 762 3203 429 325 427 731 3239 430 439 427 755 3164 431 319 427 842 3265 431 340 427 577 3716 431 353 429 674 2909 432 347 428 739 2923 432 356 427 738 3015 422 346 428 858 3151 423 345 429 769 3023 430 354 429 759 3186 422 345 431 698 3504 424 383 428 757 3220 423 349 429 705 3412 423 342 429 756 3293 425 347 430 778 3245 425 458 430 797 3829 425 358 431 739 4204 426 346 432 731 4255 424 359 432 739 4114 426 354
432 734 2933 426 356 431 715 2989 427 351 422 763 3198 426 391 421 751 2745 426 351 423 761 3500 427 371 423 724 3206 426 366 424 1052 3264 426 425 424 834 3678 427 348 424 905 3213 429 353 423 834 3149 429 393 425 837 3466 429 367 426 901 3093 430 324 426 756 3100 430 423 425 808 3092 430 325 426 763 3267 430 335 426 760 3206 430 346 428 758 2697 431 376 425 910 2876 431 346 428 624 3078 431 371 427 733 2888 432 348 426 719 2985 432 341 429 778 2919 423 351 429 804 2943 422 348 429 901 2847 422 433 430 653 2926 423 334 430 713 3022 424 353 429 781 2901 424 349 430 744 2775 423 345 429 876 2931 424 347 430 751 2712 424 334 431 795 3291 425 321 431 745 3434 425 383 431 707 3333 426 340 431 780 3113 426 380 432 709 3182 426 341 433 857 3177 427 352 423 738 3605 426 346 421 794 3069 427 362 423 738 3038 427 358 424 778 3158 428 377 422 828 3039 428 355 422 835 2955 428 364 424 759 3337 427 389 424 764 3221 429 445 426 837 3199 429 405
425 757 3445 429 374 425 701 3242 430 337 426 708 3136 430 354 426 800 3030 430 364 428 742 3163 430 399 425 798 3697 431 352 426 799 3166 431 377 428 868 3377 430 304 427 594 4061 432 308 428 868 3427 431 426 427 712 3444 422 341 428 772 3118 422 382 429 762 3250 423 290 428 917 3050 422 316 429 729 3258 423 385 428 858 3187 423 394 429 844 3102 423 344 430 839 3083 424 345 431 879 2814 424 352 432 769 2853 424 375 430 741 2869 425 335 432 699 3023 425 335 431 739 2851 426 403 433 714 3411 426 338 432 786 3154 426 354 423 857 2988 427 351 422 788 3274 427 356 423 786 3174 428 337 424 698 3727 428 378 424 766 3100 427 372 423 958 3245 428 357 425 759 3295 428 356 424 724 3370 427 378 424 766 3111 429 375 425 742 3122 429 313 427 772 3201 430 357 425 701 3357 430 353 425 711 2921 430 350 426 722 3178 430 339 428 756 3236 431 396 427 699 3190 431 473 426 753 3115 431 351 428 849 3287 432 379 429 584 3614 431 344 429 900 3159 421 389
429 789 2900 422 340 430 772 2903 423 356 429 773 2918 422 363 430 844 3079 422 374 428 724 2811 423 308 429 693 2990 425 387 431 777 2983 424 343 430 773 2956 425 345 432 782 3026 433 344 432 798 3225 425 366 430 786 3679 425 334 431 758 2962 425 347 432 831 2959 425 337 432 985 3057 427 345 424 1040 3280 427 430 423 761 3160 427 333 424 887 3187 428 343 424 1186 3690 427 420 425 773 3523 427 339 425 760 3342 428 357 425 951 3024 427 367 425 834 2947 429 351 425 732 3176 428 353 424 745 3292 429 355 424 787 3208 430 462 427 690 3028 430 381 427 758 4179 430 345 425 707 3026 430 376 425 782 3119 431 343 427 743 3002 430 379 428 688 2989 431 332 427 775 3186 431 360 427 884 4163 431 413 429 619 3206 422 382 428 901 3374 423 346 431 803 3328 423 363 430 753 3221 423 303 431 722 3195 422 288 432 866 3146 423 282 429 688 3428 424 311 430 750 3144 425 436 431 789 3441 424 394 429 861 3258 425 350 431 781 3322 425 332 432 768 3284 426 336
432 780 2932 426 336 433 851 3058 425 331 432 808 2966 427 345 422 783 2975 426 335 423 1201 3423 426 336 423 893 3228 427 379 422 952 3071 427 339 424 863 3273 426 379 423 812 3184 428 373 424 856 3115 427 350 424 939 2986 428 344 424 825 3501 428 342 425 741 4588 428 347 424 788 4325 429 360 424 790 4073 429 384 426 784 3393 430 381 426 814 3380 430 337 427 778 3923 432 383 426 917 3510 431 380 428 796 4023 432 425 427 866 5140 431 323 427 766 4443 431 345 427 873 3911 421 348 429 782 3319 422 367 429 811 3285 422 367 428 782 3841 423 393 430 765 4414 424 387 430 959 3499 424 423 431 809 3664 424 338 430 786 6365 425 343 430 754 3663 424 373 430 1412 3264 426 419 430 821 3258 426 284 430 742 3093 425 409 431 801 3329 425 334 432 839 3216 426 361 423 817 2961 427 364 423 891 3150 426 348 425 818 2948 427 356 424 756 3150 426 361 423 735 3049 426 349 424 777 3238 428 363 424 848 2956 427 343 426 914 3702 427 378 426 787 3283 429 344
425 891 3354 429 347 424 704 3590 429 354 424 742 3379 429 350 426 767 3351 430 335 426 742 3223 430 338 428 802 3312 430 348 426 782 3171 431 348 427 829 3244 431 361 428 765 4100 431 457 427 850 2955 431 332 427 787 3760 432 405 428 978 3957 422 345 428 770 3468 422 373 428 841 3779 423 340 429 932 3241 422 350 430 825 3681 423 383 429 1185 3314 424 404 430 1355 3345 423 338 430 814 3174 423 361 429 792 4252 424 352 432 794 3300 425 352 432 732 3949 425 348 432 770 3576 426 345 431 745 3751 426 377 431 801 3206 426 425 422 813 3193 427 341 422 872 3672 426 383 423 729 3132 427 354 423 887 4043 427 344 423 936 3248 428 389 424 775 3462 428 327 423 745 3337 427 339 424 871 3234 427 347 425 747 3561 428 355 425 860 3196 429 352 425 926 3296 429 341 427 795 2796 430 356 427 877 2955 430 360 427 920 2996 430 376 425 850 3027 430 390 426 814 2976 431 338 427 884 3056 431 351 428 906 2985 431 349 428 743 2989 431 348 427 804 2974 432 433
428 759 3020 421 340 428 951 2840 422 330 428 788 2877 423 341 430 778 2838 423 337 430 825 2994 423 367 431 804 3036 424 344 431 807 2933 423 334 431 927 3048 424 340 431 781 3015 425 356 430 785 2912 424 392 432 788 3050 425 341 432 769 3048 425 336 431 810 2840 426 345 433 927 2936 427 339 423 853 3157 426 373 422 803 3188 427 327 423 811 3153 427 356 422 847 3143 427 360 424 778 3179 427 353 423 948 3122 428 349 424 815 3198 428 339 425 842 2767 428 356 424 749 2998 429 332 425 824 3797 429 377 424 1175 3201 429 428 427 717 3145 430 337 426 841 3336 430 351 425 769 3237 428 354 426 802 3358 431 390 435 835 3398 431 336 427 794 2984 431 343 427 853 2851 431 366 429 743 2953 431 315 427 833 2975 432 357 429 765 3284 422 436 430 797 3167 423 385 427 912 3224 423 424 428 683 3233 424 336 428 717 3362 423 379 430 817 3067 424 315 431 862 4086 425 371 431 854 3131 425 404 431 817 3550 425 381 430 734 3176 424 334 431 757 3290 425 352
431 831 3106 426 387 431 775 3593 425 346 432 821 3145 426 368 423 760 3209 427 320 422 741 2937 427 360 423 806 2973 426 352 422 797 2889 427 356 424 804 2914 428 352 424 788 2949 428 277 423 1005 2927 428 282 425 790 2901 430 361 425 838 2879 428 338 426 769 3138 429 334 425 912 3177 429 327 425 1040 2935 431 401 427 910 2792 429 333 425 1018 3118 430 376 426 924 3150 430 348 427 1001 3574 431 356 426 913 3148 431 377 427 772 3149 431 362 428 801 3283 432 401 428 792 3109 432 335 429 781 2936 422 384 428 763 2900 422 375 430 783 2956 422 335 430 1178 3018 424 349 430 904 3131 423 425 430 911 3023 423 334 429 982 4226 423 361 431 789 3276 424 367 431 865 3012 425 356 431 1048 3098 424 349 432 780 3144 425 414 433 808 3089 424 330 433 812 3206 426 339 433 802 3345 426 356 421 801 2968 425 354 422 752 2905 427 386 422 787 3259 427 335 423 848 3324 427 356 424 806 2949 427 423 425 805 2846 428 334 422 888 2919 428 337 424 684 2869 428 339
424 792 3606 427 338 425 753 3160 429 338 425 879 3330 430 370 428 821 3161 429 335 425 938 3074 430 353 426 867 3290 430 347 427 741 2984 432 423 427 827 2905 431 333 428 860 3037 431 356 429 792 3261 431 347 426 795 3186 433 343 427 807 3353 432 376 429 843 3507 422 437 430 846 3235 423 370 431 743 3473 423 348 429 846 3153 422 346 430 944 3277 423 350 430 848 3429 424 345 430 820 2869 423 350 430 779 3282 425 373 430 768 2971 425 351 431 965 3033 424 372 432 827 2749 425 352 431 742 2972 425 371 431 804 2949 425 358 434 843 3504 425 352 420 772 3118 426 361 422 763 3126 427 369 423 763 3129 426 339 424 815 3578 427 300 424 722 3274 428 342 423 838 3242 428 307 425 743 3135 428 342 424 1042 3084 428 356 425 739 3233 427 386 424 840 3435 429 418 424 824 3565 429 344 426 776 2932 430 345 425 756 2913 430 356 426 1037 2861 430 351 427 741 3168 430 376 427 808 2997 431 334 426 781 3049 431 358 428 828 3031 431 357 429 724 3107 431 389
428 763 2968 431 350 428 769 3232 422 346 429 836 3128 423 345 429 939 2985 423 336 429 798 2928 422 349 430 954 3035 423 384 431 799 3179 423 372 431 834 3125 424 337 431 758 3163 426 355 430 788 3276 424 353 432 826 3281 424 345 432 924 2984 424 349 432 836 3028 426 349 433 847 3486 426 356 433 922 3313 425 383 421 919 3350 426 360 423 966 3245 427 358 422 1007 3162 426 472 424 1611 3216 426 382 423 826 3282 428 361 423 801 3554 428 352 425 789 3570 429 353 423 810 3789 428 413 424 939 4474 429 343 424 901 4065 429 360 425 812 3278 430 361 425 809 3199 429 339 425 818 3241 430 377 425 786 3160 430 361 426 998 3421 430 462 426 764 3414 430 382 428 805 2856 431 468 426 751 4175 431 347 428 884 5530 432 347 429 767 5555 432 371 427 757 5636 422 341 429 773 5368 423 338 430 829 4086 422 340 429 803 3165 424 344 429 799 4577 423 363 430 945 6265 424 342 431 680 3795 423 391 431 819 3331 423 383 430 783 3686 425 348 430 820 3183 425 363
432 761 2950 425 349 431 1475 3036 425 357 431 1157 2799 426 354 433 806 3810 426 405 425 808 3371 428 351 422 799 3148 426 388 423 823 3232 427 357 422 784 4304 427 340 424 741 3616 428 357 423 791 3209 427 348 424 805 3368 427 382 426 810 3460 428 345 424 809 3131 429 374 426 851 3226 430 359 424 836 3146 429 371 426 792 3359 429 365 426 855 3141 430 369 426 776 3178 430 415 427 975 2769 430 354 426 812 3706 430 344 428 783 3331 431 346 427 769 4003 431 348 429 828 3215 432 379 429 831 3415 433 346 429 808 3244 422 358 428 791 3316 423 504 428 858 3115 424 338 430 779 2901 423 351 430 787 2952 424 387 431 777 3207 424 346 431 797 3189 423 349 430 757 3512 423 352 431 785 3468 425 347 430 799 3230 424 345 432 793 3244 424 364 433 809 3142 426 355 433 967 3472 424 388 431 777 3157 426 387 422 739 3253 426 425 423 834 3208 427 401 422 812 3351 426 333 424 797 3316 428 374 425 878 3278 428 370 424 781 3973 428 345 425 766 3423 428 353
423 745 3066 429 350 424 833 3020 429 352 428 1048 2954 429 368 425 839 2898 429 351 425 915 2917 428 355 426 861 3390 430 370 425 810 3206 430 407 427 797 3631 430 344 427 970 3321 431 340 427 736 3813 431 366 428 817 4096 432 355 426 838 3093 432 362 428 892 3288 432 366 430 881 3172 422 353 428 1005 3646 423 416 429 850 3555 423 346 428 778 3301 422 346 429 837 3422 423 357 429 997 3415 423 378 431 886 3575 424 336 431 916 3831 425 369 432 704 3229 424 394 431 820 3200 424 361 432 925 3158 425 365 431 808 3689 426 357 431 822 3269 425 378 433 982 3258 426 330 423 729 2879 427 347 423 799 2933 427 349 425 805 2834 427 349 423 850 3043 427 346 426 751 2921 426 462 425 790 3027 428 374 425 840 2962 427 336 423 848 3540 429 355 426 729 3469 429 380 425 739 3186 429 463 425 974 3363 429 354 425 697 3616 429 373 427 781 3056 430 376 425 825 3437 430 361 426 804 3571 430 350 428 766 4192 430 346 426 922 3387 431 353 427 727 2930 431 356
426 783 3032 431 400 427 773 3535 431 474 429 779 3603 421 365 428 1852 3147 422 453 429 821 3164 424 352 429 789 3147 423 402 429 773 3325 424 330 428 790 3108 423 353 430 807 3177 424 358 430 830 3129 424 370 429 955 2914 425 397 430 830 3087 424 356 432 766 3111 424 364 430 776 2877 424 475 431 784 2972 425 337 432 1006 3571 425 364 421 706 3350 426 340 423 738 3569 426 355 423 853 3012 427 383 423 792 3007 427 347 425 916 2991 428 373 423 802 3102 428 367 426 871 3150 427 346 423 771 3059 430 415 426 812 2904 428 373 425 830 2932 429 316 424 839 3508 429 369 425 904 3160 429 372 427 743 3005 430 381 425 784 3006 430 380 425 785 2933 430 353 426 770 2899 430 293 427 794 3554 431 360 427 1005 3829 431 354 427 881 4304 433 352 429 893 4179 432 366 427 994 3299 424 371 431 926 4278 422 358 429 903 3612 423 363 429 848 4758 422 388 428 767 3290 424 475 429 727 6429 424 385 430 791 3684 425 310 429 784 3924 425 352 430 1062 3569 424 368
432 895 3475 425 362 432 777 5854 424 429 431 767 3630 425 353 432 814 3549 425 435 431 798 3116 425 338 422 932 3058 426 444 422 724 2941 427 341 422 791 3087 426 362 423 782 4204 428 346 423 843 3290 427 406 424 752 3243 427 375 424 860 3261 427 319 423 1149 3656 427 366 426 950 6120 428 387 425 1191 3713 429 348 425 916 3825 429 418 428 1145 3827 429 348 426 891 3924 429 349 425 813 4846 432 344 428 804 3795 431 350 427 796 4232 429 362 426 761 3443 431 344 427 755 3772 431 360 430 971 3238 432 395 427 815 3095 431 346 428 1868 3969 423 345 429 799 3317 423 345 430 740 2817 422 366 429 801 3465 423 365 428 801 3224 424 364 431 809 3677 423 359 431 813 3625 424 364 439 807 3277 425 407 434 754 3704 425 345 430 1046 4635 425 390 432 776 2999 425 350 432 809 3107 424 367 432 743 3545 425 354 432 903 3055 426 389 423 839 3537 427 333 422 915 3331 427 351 422 730 3115 427 417 422 784 3269 427 337 425 874 3575 428 380 423 769 3271 428 341