Tendo o objetivo de melhorar a experiˆencia de utiliza¸c˜ao de transportes p´ublicos, ´e ne-cess´ario abordar o tempo gasto em filas de espera para efetuar a compra e valida¸c˜ao de bilhetes. Uma forma de melhorar este aspeto, ´e construir um sistema baseado na tecnologia BLE, que permita a dete¸c˜ao das entradas e sa´ıdas dos passageiros `a distˆancia.
Neste cap´ıtulo ser˜ao analisados sistemas BIBO (Be-in/Be-out) como [7] e [10], e sistemas que necessitam da confirma¸c˜ao manual de check-in, tamb´em conhecidos por CIBO (Check-in/Be-out), como o [9] e [11, 12] onde, apesar de ocheck-in n˜ao ser autom´atico, este poder´a ser efetuado com o smartphone do utilizador depois de este ocupar o seu devido lugar no transporte p´ublico, evitando tamb´em a forma¸c˜ao de filas de espera.
2.1 BIBOLinz
Este projeto [7, 8] desenvolvido na Universidade Johannes Kepler no ˆambito da inici-ativa austr´ıaca IV2Splus, tem o objetivo de melhorar a mobilidade de pessoas fisicamente incapacitadas, crian¸cas e idosos, em autocarros, atrav´es de um sistema BIBO que usa a tec-nologia BLE. N˜ao tendo sido encontrado um nome para este sistema na bibliografia, este ser´a referenciado como BIBOLinz para facilitar a sua referˆencia.
Dentro de cada autocarro, a arquitetura do sistema ´e composta por umbeaconpertencente ao passageiro (1) ou umsmartphone (2), um m´odulo “OBS” (On-Board-System), constitu´ıdo por uma unidade de processamento (Raspberry Pi) (3) com um dongle BLE acoplado (4), o computador de bordo do pr´oprio autocarro (5) e uma base de dados local (6) que guarda a informa¸c˜ao proveniente da unidade de processamento: ID dos clientes associados `as suas localiza¸c˜oes nos momentos de scanning do sistema e timestamps correspondentes. Fora dos autocarros, a arquitetura ´e constitu´ıda por um servidor remoto (backend) que, ao associar a informa¸c˜ao pessoal dos passageiros (7) `a informa¸c˜ao da viagem (8), ´e respons´avel por tax´a-los (9). O OBS comunica com o computador de bordo e funciona como uma unidade central que estabelece a liga¸c˜ao entre o smartphone e obackend, como se verifica na Figura 2.1.
Neste sistema BIBO, o check-in e check-out dos passageiros ´e autom´atico, e o papel de-sempenhado pelos smartphones ´e o de fazer broadcasts ao OBS para anunciar a presen¸ca dos respetivos passageiros no autocarro. Tendo em conta a simplicidade da fun¸c˜ao dos smartpho-nes, n˜ao s˜ao especificados quaisquer detalhes em rela¸c˜ao a aplica¸c˜oes m´oveis.
Figura 2.1: Arquitetura do sistema BIBOLinz.
Durante a viagem, para confirmar a presen¸ca dos passageiros, o OBS faz scansperi´odicos despoletados por eventos do computador de bordo, de forma a realiz´a-los em momentos em que o ve´ıculo n˜ao se encontra perto de paragens, para n˜ao identificar dispositivos BLE que n˜ao perten¸cam a passageiros. Partindo deste princ´ıpio, o OBS pode efetuar um scan 30 segundos ap´os o computador de bordo sinalizar que as portas do autocarro foram fechadas.
Um dispositivo BLE identificado por um determinado n´umero de scans, ´e identificado como um passageiro do autocarro.
Como se pode verificar na Figura 2.2, os beacons/smartphones, para estabelecerem um handshake com o OBS, come¸cam por fazer um broadcast BLE (1), que ´e recebido pelo OBS (2). Ap´os estas primeiras intera¸c˜oes, o OBS envia uma key AES de 128 bits encriptada (3) que, do lado do cliente, ´e desencriptada, concatenada ao ID do cliente (“client ID”) e encriptada novamente (4), que acaba por ser lida e desencriptada pelo OBS (5). Caso akey inicial consiga ser restaurada atrav´es da sua desencripta¸c˜ao, o OBS valida o ID do cliente, guarda-o e envia-lhe a indica¸c˜ao de que pode parar de fazerbroadcasts BLE (6) at´e voltarem a comunicar no pr´oximo scan.
Com base em informa¸c˜ao guardada antes do in´ıcio da viagem - nomes das paragens as-sociados `as suas localiza¸c˜oes GPS ou associados `a sequˆencia de scans peri´odicos realizados pelo OBS - o ID dos clientes fica associado ao nome das paragens por onde passam, com os respetivostimestamps, na base de dados do OBS. Esta informa¸c˜ao ´e transmitida, via Internet, ao servidor remoto (backend) onde ´e calculado o custo da viagem.
Quanto ao m´etodo de pagamento, este tem o banco do cliente como mediador entre o cliente e a empresa de transporte p´ublico, em que o banco fornece uma key ao utilizador, que o mesmo associa ao pagamento das viagens, como demonstra a Figura 2.3. Assim, a empresa de transporte p´ublico n˜ao tem acesso a informa¸c˜ao delicada do utilizador e o banco n˜ao tem a informa¸c˜ao de onde e quando o seu cliente viajou, limitando-se a retirar mensalmente da
Figura 2.2: Dete¸c˜ao dos passageiros no sistema BIBOLinz.
conta do seu cliente a quantia acumulada das viagens efetuadas pelo mesmo.
2.2 CIBOLisboa
Este sistema [9] desenvolvido no Instituto Superior T´ecnico de Lisboa, adaptado `a CAR-RIS1, prop˜oe uma arquitetura que usa funcionalidades dossmartphones dos passageiros como GPS e sensores de movimento, para substituir a instala¸c˜ao de uma unidade central de pro-cessamento no ve´ıculo (ex.: Raspberry Pi) ou liga¸c˜ao ao computador de bordo do mesmo. O sistema ser´a referenciado como CIBOLisboa, para facilitar a sua referˆencia.
Este sistema ´e composto por quatrobeacons por autocarro comum da CARRIS (seis por articulado), umbackend e osmartphone do passageiro. Osbeacons enviam, periodicamente, informa¸c˜ao est´atica aosmartphonepara confirmar a presen¸ca do passageiro no autocarro, e o smartphone reencaminha essa informa¸c˜ao para obackend da empresa de transporte p´ublico, que ´e o respons´avel pela an´alise e processamento de dados. Al´em destes trˆes elementos distintos da arquitetura, h´a ainda um revisor, que a qualquer momento pode confirmar se o
1Empresa de transporte p´ublico de Lisboa.
Figura 2.3: M´etodo de pagamento do sistema BIBOLinz.
passageiro est´a a viajar legalmente. A arquitetura do sistema encontra-se representada na Figura 2.4.
Quanto ao seu funcionamento, o utilizador come¸ca por fazer odownload da aplica¸c˜ao no seu smartphone e registar-se. Ap´os efetuar o login na aplica¸c˜ao, deve confirmar o seu saldo e, caso esteja abaixo da quantia m´ınima estipulada para dar in´ıcio `a viagem, ter´a de efetuar um carregamento. J´a dentro do autocarro, com saldo suficiente, o smartphone identifica os beacons mais pr´oximos e a aplica¸c˜ao deve selecionar automaticamente o autocarro no qual se encontra o utilizador, opera¸c˜ao que, em caso de falha, o utilizador deve confirmar manualmente o devido autocarro. Para dar in´ıcio `a viagem, sucede-se o check-in manual na aplica¸c˜ao, clicando no bot˜ao “Check-in”, e ´e esta a¸c˜ao que vai enviar a localiza¸c˜ao GPS do smartphone aobackend, identificando a esta¸c˜ao/paragem de partida. Nesta fase, o passageiro apenas ter´a de interagir novamente com a aplica¸c˜ao, caso o revisor pe¸ca que este prove que est´a a viajar legalmente, ao que o passageiro deve proceder a um clique num bot˜ao espec´ıfico da sua aplica¸c˜ao para esta situa¸c˜ao, que vai gerar um c´odigo QR e o revisor confirma-o com a cˆamara do seu pr´oprio smartphone. No final da viagem, o smartphone do utilizador, ao sair do autocarro, deixa de identificar o n´umero m´ınimo de beacons definido pelo sistema e a aplica¸c˜ao d´a por terminada a viagem automaticamente (Be-Out), voltando a enviar a localiza¸c˜ao GPS ao backend, que a associa a uma esta¸c˜ao. O backend, ap´os o check-out, calcula o custo da viagem, baseado nas esta¸c˜oes percorridas pelo passageiro e cobra-lhe esse montante. O hist´orico de viagens e o custo das mesmas podem ser consultados a qualquer momento no smartphone do utilizador.
2.3 SEAT
O sistema SEAT [10] desenvolvido na TU Delft, consiste numa nova perspetiva de um sistema BIBO. Este projeto aborda um sistema que difere dos anteriores, por usar diferentes tipos de dispositivos dentro dos ve´ıculos para efetuar check-ins,check-outs e comunicar com o backend.
A sua arquitetura, apresenta um dispositivo para registar ocheck-in (“vehicle check-in”),
Figura 2.4: Arquitetura do sistema CIBOLisboa.
outro para registar o check-out (“vehicle check-out”), um dispositivo central (“vehicle cen-tral”), umbackend (“back-end”) e osmartphonedo passageiro (“passenger”). Os dispositivos de check-in e check-out, tˆem a fun¸c˜ao de receber a informa¸c˜ao do smartphone do passageiro em rela¸c˜ao `a sua permanˆencia no autocarro e comunic´a-la ao dispositivo central que, al´em de comunicar com estes, tamb´em comunica diretamente com o backend.
Al´em destes elementos distintos da arquitetura, este sistema tamb´em recorre a um revisor, que a qualquer momento pode confirmar se um passageiro est´a a viajar legalmente, comu-nicando com o dispositivo central ou diretamente com o smartphone do passageiro. Esta arquitetura encontra-se representada na Figura 2.5.
O dispositivo de check-in, que comunica com o smartphone do passageiro por BLE, identifica-o na sua entrada para o autocarro. Esta identifica¸c˜ao de check-in ´e registada pelo dispositivo central, que comunica a informa¸c˜ao ao dispositivo decheck-out que, por sua vez, envia mensagens encriptadas ao smartphone do passageiro, tamb´em por BLE, para este as desencriptar e confirmar que se mant´em presente no autocarro. A partir do momento em que o smartphone deixa de responder a esta troca de informa¸c˜ao, ´e identificado ocheck-out.
Com base na informa¸c˜ao agregada por estes dois dispositivos, o dispositivo central regista localmente a informa¸c˜ao dos s´ıtios em que o passageiro efetuou ocheck-in e ocheck-out e re-encaminha essa informa¸c˜ao aobackend atrav´es de uma comunica¸c˜ao 3G ou, em modooffline, pode comunic´a-la apenas no final do dia de servi¸co2.
Para o correto funcionamento do sistema, o utilizador necessita de fazer o download da aplica¸c˜ao no seu smartphone e registar-se, enviando o registo para o backend que guarda o perfil do utilizador para efeitos de autentica¸c˜ao. Sendo este um sistema BIBO, ap´os efetuar o login na aplica¸c˜ao, o utilizador n˜ao requer qualquer intera¸c˜ao adicional com o seusmartphone
2O tipo de comunica¸c˜ao n˜ao ´e especificada na bibliografia
Figura 2.5: Arquitetura do sistema SEAT.
Figura 2.6: Processo decheck-ine verifica¸c˜ao de permanˆencia do passageiro no sistema SEAT.
durante a viagem, necessitando apenas de o fazer caso o revisor o requisite. Nesse caso, o passageiro fornece ao revisor um c´odigo dispon´ıvel na sua aplica¸c˜ao, que o revisor valida no seu pr´oprio dispositivo3.
Quanto `a sua seguran¸ca, o sistema recorre a um esquema complexo de distribui¸c˜ao de keys composto por certificados, encripta¸c˜ao assim´etrica, c´odigos para autentica¸c˜ao de men-sagens (MAC)4, assinaturas digitais e encripta¸c˜ao sim´etrica, em que as chaves s˜ao trocadas recorrendo ao m´etodo Diffie-Hellman. Obackend funciona como uma CA (Autoridade de Cer-tifica¸c˜ao)5, onde tem um par de chaves assim´etricas ECC (Criptografia de Curva El´ıtica)6, em que aprivate key ´e usada para assinar os certificados etokens atribu´ıdos aos dispositivos registados no sistema, e a public key ´e distribu´ıda pelos mesmos dispositivos, para estes po-derem verificar a validade dessas assinaturas. Enquanto isso, o dispositivo central e o revisor tamb´em geram os seus pares de chaves ECC, de validade limitada e seguran¸ca inferior, e enviam as public keys desses pares aobackend, para que este lhes atribua um certificado tem-por´ario, permitindo-lhes estabelecer uma comunica¸c˜ao segura com os passageiros atrav´es de
3A bibliografia n˜ao especifica o tipo de dispositivo.
4Message Authentication Code
5Certification Authority
6Elliptic-Curve Cryptography
Figura 2.7: Arquitetura do sistema Anda.
tokens e assinaturas digitais. As comunica¸c˜oes do dispositivo do revisor com os passageiros e dispositivo central, recorrem a “session keys” - chaves sim´etricas de encripta¸c˜ao AES de 128 bits - sistema de encripta¸c˜ao tamb´em usado na comunica¸c˜ao do smartphone do passageiro com o dispositivo de check-in, que usa uma chave tempor´aria, que ser´a referida como “CT”.
A comunica¸c˜ao do smartphone do passageiro com o dispositivo de check-in, segue a ordem de eventos representada na Figura 2.6 (1-4). Inicialmente, o dispositivo de check-in envia um certificado com a sua public key ao passageiro (1), que usa essa chave para encriptar a chave CT, enviada junto da DH-17e um MAC criado com a pr´opria chave CT (2). Segue-se a resposta do dispositivo com a DH-2 e um MAC para esta chave criado tamb´em pela chave CT (3). Assim, fica estabelecida uma liga¸c˜ao segura entre os dois elementos e ´e criada uma chave
“KeyJ”, que ´e usada para osmartphone encriptar o seutoken e envi´a-lo para o dispositivo de check-in (4). Mais tarde, na comunica¸c˜ao do smartphone do passageiro com o dispositivo de check-out (5-6), o dispositivo decheck-out vai enviar mensagens encriptadas pela chave KeyJ ao smartphone (5), que o smartphone desencripta e responde com mensagens de “Ok” (6), confirmando a sua presen¸ca.
Por fim, o respons´avel por calcular e cobrar o custo da viagem do passageiro, com base na sua distˆancia percorrida, ´e o backend. Tendo em conta que, independentemente do modo (online ou offline) a comunica¸c˜ao do dispositivo central com o backend s´o ´e feita no final da viagem do passageiro, pode-se depreender que este sistema ´e p´os-pago.
2.4 Anda
O sistema Anda [11, 12] desenvolvido na FEUP, prop˜oe melhorar o sistema Andante que atualmente comunica por RFID em esta¸c˜oes da ´area metropolitana do Porto, atrav´es da sua transi¸c˜ao para a tecnologia BLE. Para isso, prop˜oe duas arquiteturas diferentes, uma para autocarros e outra para transportes ferrovi´arios.
Para autocarros, o sistema prop˜oe o uso de um ou maisbeacons ligados por cabo ao com-putador de bordo dos ve´ıculos, um servidor remoto (backend) e o smartphone do utilizador.
Os beacons recebem informa¸c˜ao acerca das paragens proveniente do computador de bordo e transmitem-na aosmartphone do passageiro, que a comunica ao backend. Este backend ´e da responsabilidade da empresa de transporte p´ublico e ´e l´a que a informa¸c˜ao ´e analisada e processada.
No caso dos transportes ferrovi´arios, a arquitetura tamb´em ´e constitu´ıda por um servidor remoto, osmartphone do utilizador e beacons, por´em n˜ao necessita do computador de bordo dos ve´ıculos e os beacons s˜ao instalados nos atuais postos de valida¸c˜ao do sistema RFID Andante, situados em paragens/esta¸c˜oes. Estes beacons apresentam um funcionamento mais simples que os beacons para o sistema de autocarros, por apenas necessitarem de enviar informa¸c˜ao para o smartphone acerca da paragem/esta¸c˜ao onde est˜ao instalados. Enquanto que a informa¸c˜ao enviada pelosbeacons no sistema para autocarros ´e dinˆamica, a informa¸c˜ao enviada pelos beacons no sistema para transportes ferrovi´arios ´e est´atica, o que simplifica a complexidade destes segundos, por´em aumenta a complexidade da aplica¸c˜ao m´ovel dos passageiros. Estas duas arquiteturas podem ser consultadas na Figura 2.7.
Do ponto de vista do utilizador, o funcionamento do sistema para autocarros ´e idˆentico ao sistema para transportes ferrovi´arios. O utilizador come¸ca por fazer odownload da aplica¸c˜ao para o seusmartphonee registar-se. Ap´os efetuar ologin na aplica¸c˜ao, osmartphoneidentifica osbeacons detetados nas proximidades e o utilizador necessita de fazer um check-in manual, selecionando a paragem/esta¸c˜ao onde vai dar in´ıcio `a sua viagem (beacon pertencente ao sistema, que est´a mais pr´oximo).
Iniciando a sua viagem, a aplica¸c˜ao recebe informa¸c˜ao proveniente do autocarro ou para-gens/esta¸c˜oes, onde o utilizador pode verificar as paragens por onde j´a passou e as paragens por onde ainda vai passar at´e chegar ao seu destino. Durante a viagem, o revisor pode pe-dir ao utilizador que prove estar a viajar legalmente e este apenas necessita de mostrar um c´odigo alfanum´erico dispon´ıvel na sua aplica¸c˜ao gerado para esta situa¸c˜ao, que o revisor valida introduzindo-o no seu pr´oprio smartphone. Chegando ao destino, o check-out ´e autom´atico.
Osmartphone ao ficar fora do alcance dosbeaconsque fazem parte da rota do ve´ıculo, deteta a quebra da sequˆencia debeacons esperada e a viagem ´e dada por terminada, fazendo com que este seja um sistema CIBO (Check-In/Be-Out). Com a viagem conclu´ıda, obackend analisa o trajeto efetuado e calcula o seu custo, seguindo o m´etodo atual do Andante, com tarifas por zonas. Este sistema acumula o custo das viagens e, no final do mˆes, retira o montante total da conta do utilizador, sujeito a otimiza¸c˜oes de tarifa que beneficiam os passageiros. O hist´orico de viagens e o custo das mesmas tamb´em podem ser consultados, a qualquer momento, no smartphone do utilizador.
BIBOLinz[7] CIBOLisboa[9] SEAT[10] Anda[11, 12]
Complex. Arq elevada moderada elevada elevada/moderada
Adaptabilidade baixa moderada baixa baixa/elevada
Seguran¸ca AM,unlink. - AM,unlink.,PFS
-Tabela 2.1: Compara¸c˜ao dos sistemas BLE.
BIBOLinz[7, 8] CIBOLisboa[9] SEAT[10] Anda[11, 12]
Usabilidade f´acil complexa moderada complexa
M´etodo Paga. banco mediador - -
-Pontualidade Paga. mensal fim da viagem fim da viagem mensal
Custo Inicial Paga. 0 valor de entrada - 0
C´alculo Tarifa n.ºparagens n.ºparagens distˆancia zonas Tabela 2.2: Compara¸c˜ao dos sistemas BLE do ponto de vista do utilizador.
2.5 Compara¸ c˜ ao de sistemas BLE
Para comparar os sistemas analisados anteriormente, foram avaliadas as seguintes ca-racter´ısticas na Tabela 2.1: complexidade das arquiteturas, adaptabilidade aos ve´ıculos e seguran¸ca dos sistemas. Nos casos em que n˜ao foi encontrada informa¸c˜ao suficiente na pre-sente bibliografia, a caracter´ıstica est´a representada por um h´ıfen. De salientar ainda que no sistema Anda, foram avaliadas, separadamente, a arquitetura projetada para autocarros (`a esquerda) e a arquitetura projetada para transportes ferrovi´arios (`a direita).
A complexidade das arquiteturas foi avaliada com base no n´umero de componentes que as integram e a complexidade de cada um dos elementos, fatores que tamb´em definem a adap-tabilidade das mesmas. Come¸cando pelo sistema BIBOLinz, este necessita de uma unidade de processamento por autocarro, com liga¸c˜ao ao computador de bordo do ve´ıculo, tal como na arquitetura projetada para autocarros do sistema Anda, o que eleva a complexidade dos sistemas e dificulta a sua adapta¸c˜ao aos sistemas atuais. J´a o sistema SEAT, apesar de n˜ao usar o computador de bordo do ve´ıculo, ´e complexo dado o n´umero de dispositivos diferentes que envolve e a complexidade dos mesmos, fatores que resultam numa baixa adaptabilidade, tendo em conta o elevado n´umero de novos dispositivos a adicionar aos ve´ıculos e o seu custo total. Quanto `a complexidade da arquitetura do sistema CIBOLisboa, esta ´e moderada tal como a do sistema Anda para transportes ferrovi´arios, por n˜ao necessitarem de uma unidade central de processamento nos ve´ıculos ou liga¸c˜ao ao computador de bordo e usarembeacons que transmitem informa¸c˜ao est´atica, o que faz com que a complexidade seja “transferida”
para as aplica¸c˜oes m´oveis dos utilizadores. Quanto `a adaptabilidade destes sistemas, esta distingue-se pela necessidade que o CIBOLisboa tem de instalar pelo menos doisbeacons por autocarro, enquanto que no sistema Anda para transportes ferrovi´arios, os beacons s˜ao co-locados nos postos de valida¸c˜ao RFID j´a existentes, fazendo com que este seja o sistema de melhor adaptabilidade.
7DH-1 - Primeira parte da chave Diffie-Hellman; DH-2 - Segunda parte
Por fim, no cap´ıtulo da seguran¸ca, o sistema BIBOLinz, atrav´es de umhandshake AES-128 do smartphone dos passageiros com a OBS do ve´ıculo, oferece autentica¸c˜ao m´utua e unlinkability, enquanto que, no caso do sistema SEAT, al´em destes tamb´em h´a PFS (Perfect Forward Secrecy) no seu complexo sistema de distribui¸c˜ao dekeyse protocolos de comunica¸c˜ao entre os elementos da arquitetura.
Na Tabela 2.2 foram analisadas as seguintes caracter´ısticas de cada sistema do ponto de vista do utilizador: usabilidade do sistema, m´etodo de pagamento, pontualidade do paga-mento, custo inicial da viagem (dinheiro que o utilizador precisa de ter dispon´ıvel para dar in´ıcio `a viagem) e c´alculo da tarifa.
Come¸cando pela usabilidade, no sistema BIBOLinz o smartphone tem apenas a fun¸c˜ao de beacon para registar a presen¸ca do passageiro, fazendo com que este seja o sistema com a usabilidade mais simples. No outro sistema BIBO, o SEAT, a usabilidade ´e moderada, tendo em conta que o utilizador necessita de se registar e efetuar ologin na aplica¸c˜ao, para o check-in e check-out serem registados automaticamente, s´o necessitando de interagir com a sua aplica¸c˜ao novamente caso o revisor o requisite. Enquanto isso no caso dos sistemas CIBOLisboa e Anda, estes apresentam uma usabilidade mais complexa, dado que os sistemas requerem que o utilizador se registe, fa¸calogin na aplica¸c˜ao e, antes de cada viagem, efetuem ocheck-in manualmente na aplica¸c˜ao, podendo ainda de ter de fornecer um c´odigo ao revisor, caso este o requisite durante a viagem.
Em rela¸c˜ao ao m´etodo de pagamento dos sistemas, o sistema BIBOLinz apresenta uma
Em rela¸c˜ao ao m´etodo de pagamento dos sistemas, o sistema BIBOLinz apresenta uma