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.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.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.11 Classificação de ameaças segundo modelo DREAD. . . . . . . . . . . . . . . . . . . . . 68

5.12 Classificação da ameaça T1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68





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

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

https://www.portalviva.pt/lx/pt/homepage/cart%C3%B5es/transportes/viva-viagem-7-colinas.aspx

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

http://www.carris.pt/fotos/editor2/tarifario_site_2014.pdf

https://www.portalviva.pt/lx/pt/homepage/cart%C3%B5es/transportes/lisboa-viva.aspx

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

http://www.calypsonet-asso.org/

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

https://www.portalviva.pt/

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

http://www.carris.pt/pt/carregar-multibanco

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

https://developer.android.com/guide/topics/connectivity/nfc/hce.html

https://www.simplytapp.com/howitworks.html

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

https://www.cuscal.com.au/mobile-payments

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

https://www.youtube.com/watch?v=g8h_i8qv1FY

• “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

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

http://developer.android.com/guide/topics/connectivity/nfc/hce.html

http://developer.android.com/guide/topics/connectivity/nfc/hce.html

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.


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.


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

https://github.com/johnsheehan/jwt

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

http://www.speedtest.net

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.


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



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



Descrição Atacante obtém credenciais de acesso ao sistemaAlvo Sistema de autenticação

Risco




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



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



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



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



Descrição Atacante obtém credenciais de acesso ao sistemaAlvo Sistema de autenticação

Risco Alto




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

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

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

http://www.doaj.org/doaj?func=fulltext&aId=1217836

[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

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5190416

http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5190416

http://www.bellid.com/resources/brochures/secure-element-in-the-cloud/, visto em 21-11-2015

http://www.bellid.com/resources/brochures/secure-element-in-the-cloud/, visto em 21-11-2015

http://www.scopus.com/inward/record.url?eid=2-s2.0-84917675078&partnerID=tZOtx3y1

http://www.scopus.com/inward/record.url?eid=2-s2.0-84917675078&partnerID=tZOtx3y1









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


PaymentRequ…

PropertiesIdPaymentIdStateProductIdPriceCurrencyPaymentMethodRedirectURLPaymentDataPayerIdAccountId


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

emulação de título de transporte seguro em telemóvel android · hce do android, que permite a...

Documents