ATTIVITA’ DI PRELIMINARE SPERIMENTAZIONE · Esistono attualmente in Piemonte diverse realtà he adottano una smartard per l’a esso e la gestione di servizi : i ittadini piemontesi

1 / 20 PUBBLICO

Manifestazione di interesse all’affidamento tramite procedura negoziata senza previa

pubblicazione di bando di gara ex artt. 36, comma 2 lett. b), e 63 D. Lgs. 50/2016 del “Servizio di

Host Card Emulation di tipo Calypso nell’ambito progetto Biglietto Integrato Piemonte

ATTIVITA’ DI PRELIMINARE

SPERIMENTAZIONE

Linee guida per lo sviluppo

Allegato A

Versione 1

ATTIVITA’ DI PRELIMINARE SPERIMENTAZIONE

Linee guida per lo sviluppo – Allegato A

2 / 20 PUBBLICO

Indice

1 INTRODUZIONE .................................................................................................................... 4

2 ARCHITETTURA .................................................................................................................... 6

2.1 Normative e documenti di riferimento .................................................................................. 7

2.2 Protocolli di comunicazione ................................................................................................... 7

2.3 File System ............................................................................................................................. 8

2.3.1 Liste dei file presenti sotto Master File .............................................................................. 8

2.4 Liste dei File presenti sotto DF utilizzata dal sistema BIP ...................................................... 9

2.4.1 Lista dei File utilizzati per la gestione del Credito Trasporti .............................................. 9

2.4.2 Lista dei File utilizzati per contratti di Servizi Aggiuntivi (partizione sempre presente) .. 10

2.4.3 Tabella nomi DF ............................................................................................................... 10

2.5 Circuito di appartenenza ...................................................................................................... 11

2.5.1 Introduzione ..................................................................................................................... 11

2.5.2 Startup Information ......................................................................................................... 11

2.5.3 Codifica circuito appartenenza ........................................................................................ 12

2.6 Chiavi di sicurezza da prevedere lato client ......................................................................... 12

2.7 Utilizzo del Credito Trasporti (SV) ........................................................................................ 12

2.8 Condizioni di accesso ai file .................................................................................................. 13

2.9 Codice seriale applet Calypso .............................................................................................. 16

3 INTERFACCIAMENTO CON L’HSM ........................................................................................ 17

4 MODALITÀ DI ESECUZIONE DELLA SPERIMENTAZIONE ......................................................... 18

5 COLLAUDO TECNICO-FUNZIONALE ...................................................................................... 19

5.1 Prove di funzionamento con l’HSM ..................................................................................... 19

5.2 Prove di funzionamento con i validatori installati ............................................................... 19

Versione 1



3 / 20 PUBBLICO

5.3 Prove di funzionamento con i terminali di controllo ........................................................... 19

5.4 Esito delle prove................................................................................................................... 19

6 DOCUMENTI CONCLUSIVI ................................................................................................... 20

6.1 La Specifica Tecnico/Descrittiva ........................................................................................... 20

6.2 Rilascio di attestato di conformità ....................................................................................... 20

Versione 1



4 / 20 PUBBLICO

1 Introduzione

Definizioni ed Acronimi

Acronimo Definizione

APDU Application Protocol Data Unit

BIP Biglietto Integrato Piemonte

CNA Calypso Network Association

CSR Centro Servizi Regionale

HCE Host Card Emulation

NDA Non-Disclosure Agreement

PO Portable Object

SIM Subscriber Identity Module

TDV Titoli di viaggio

TPL Trasporto Pubblico Locale

Con la Delibera n. 34-7051 dell’8/10/07 la Regione Piemonte ha avviato il progetto “Biglietto

Integrato Piemonte” (BIP) che si prefigge di rilanciare il sistema del TPL del Piemonte migliorandone

l’accessibilità, assicurandone la conoscenza, la gestione e la promozione del TPL, realizzando azioni di

infomobilità e certificando quantità e qualità del servizio reso.

Allo stato attuale il BIP è un moderno sistema interoperabile di bigliettazione elettronica regionale

basato su PO di tipo full contactless, aderenti allo standard ISO 14443-B e con un’architettura

afferente alle specifiche Calypso rev.3.x.

Questo documento ha l'obiettivo di descrivere brevemente l’architettura di sistema e la struttura

dati dei PO, e costituisce parte integrante dell’avviso pubblico esplorativo.

I soggetti economici interessati a partecipare alla “Manifestazione di interesse all’affidamento

tramite procedura negoziata senza previa pubblicazione di bando di gara ex artt. 36, comma 2 lett.

b), e 63 D. Lgs. 50/2016 del Servizio di Host Card Emulation di tipo Calypso nell’ambito progetto

Versione 1



5 / 20 PUBBLICO

Biglietto Integrato Piemonte” utilizzeranno questo documento per predisporre e personalizzare i

propri prodotti per gli scopi richiesti.

In questo documento non verrà specificata la descrizione dei comandi APDU (Application Protocol

Data Unit) e delle specifiche tecniche HCE Calypso, per cui si rimanda alla documentazione pubblicata

dal consorzio Calypso (www.calypsonet-asso.org).

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

Versione 1



6 / 20 PUBBLICO

2 Architettura

L’HCE proposto per la sperimentazione si dovrà inserire nell’architettura di sistema BIP, dialogando

con la rete di accettazione (validatori e PDA di controllo) dei PO a bordo mezzo, nelle stazioni della

metropolitana e ferroviarie.

Inoltre dovrà interfacciarsi con l’HSM-BIP già presente ed operativo per lo scambio delle chiavi di

sicurezza e per il calcolo della firma dei TdV.

Lo schema seguente evidenzia in giallo le componenti da descrivere nella relazione tecnica e da

predisporre per la sperimentazione.

Client

DB tariffe

HCE

service manager

HSM

CSR-BIP

Versione 1



7 / 20 PUBBLICO

2.1 Normative e documenti di riferimento

La tipologia di soluzione HCE (soluzione non basata su SIM) oggetto di sperimentazione (lato

smartphone) deve essere conforme a:

1. Sistema Operativo Android vers. 4.4 e successive

2. Specifiche del sistema operativo “Calypso” – revision 3.1;

3. Calypso Specification Rev.3 - Host Card Emulation Application

4. Cryptographic Algorithms for HCE Application Management

5. Calypso HCE Activation Module

6. Norme ISO 14443 parti da 1 a 4.

2.2 Protocolli di comunicazione

Il protocollo contactless dovrà essere conforme alla normativa ISO 14443 parte 3, i PO dovranno

rispondere inviando il loro ATQB a tutti i comandi di REQB o WUPB inviati da un accoppiatore aventi i

seguenti valori del parametro AFI (Application Family Information):

AFI = 00 hex – nessuna preferenza, tutte le carte in campo devono rispondere.

La risposta ATQB che la carta dovrà inviare alla ricezione del comando di REQB o WUPB dovrà

contenere i seguenti parametri relativi al protocollo (Protocol Info):

Protocol Type, indica la tipologia di protocollo, il valore ammesso sarà 01 hex che indica

che il protocollo è pienamente conforme alle normative ISO 14443 compresa la parte 4;

Max_Frame_Size, indica la lunghezza massima ammissibile di ogni pacchetto dati in

trasmissione, saranno ammessi valori 07 hex (frame di lunghezza 128 byte) oppure 08

hex (frame di lunghezza 256 byte);

Bit_Rate_Capability, indica le velocità di protocollo ammesse dalla carta. L’accoppiatore

ha facoltà di scegliere, in base ai valori dichiarati, velocità di bit rate superiori a quella di

default, circa 106Kbps. Le velocità di trasferimento (bit rate) ammesse sono indicate

nella tabella riportata di seguito (tabella 7.9.4.6 della ISO14443-3). I valori massimi

ammissibili del parametro Bit_Rate_Capability saranno:

o Bit_Rate_Capability=B3hex, fino a 424Kbps in entrambe le direzioni.

Versione 1



8 / 20 PUBBLICO

2.3 File System

l file system richiesto sarà formato dai file indicati di seguito.

I DF e il MF dovranno essere di tipo Calypso rev3.1 (anche se non completamente aderente alla

specifica, vedi requisito R28).

Nella lista saranno indicati soltanto i file utilizzati dall’applicazione BIP e non i file di sistema che

contengono oggetti di sicurezza (chiavi e pin) e altri file necessari alla funzionalità dell’applicazione

Calypso.

2.3.1 Liste dei file presenti sotto Master File

MF / DF / EF File type LID SFI Num Rec. Rec size DF Name

MF MF 3F00h - na na Vedi tabella nomi DF

EF ICC Linear 0002h 02h 1 29 n.a.

EF ID Linear 0003h 03h 1 29 n.a.

EF ITP-ID Linear 3F04h 04h 1 29 n.a.

EF ITP-TDV Linear 3F05h 05h 1 29 n.a.

Versione 1



9 / 20 PUBBLICO

2.4 Liste dei File presenti sotto DF utilizzata dal sistema BIP


DF: Transport 1 DF 2000h - - - Vedi tabella nomi DF

EF Environment Linear 2001h 07h 2 29 n.a.

EF Events Log Cyclic 2010h 08h 3 29 n.a.

EF Contract List Linear 2050h 1Eh 1 29 n.a.

EF Contracts Linear 2020h 09h 8 29 n.a.

EF Special Events Linear 2040h 1Dh 8 29 n.a.

All Counters Counter 2069h 19h 1 29 n.a.

Supplementary Counters

Counter 206Ah 13h 1 29 n.a.

Free file Linear 20F0h 01h 4 29 n.a.

2.4.1 Lista dei File utilizzati per la gestione del Credito Trasporti


DF: EP Stored value application

DF 1000h

- - - Vedi tabella nomi DF

EF Load Log Cyclic 1014h

14h 1 29 n.a.

EF Purchase Log Cyclic 1015h

15h 3 29 n.a.

Versione 1



10 / 20 PUBBLICO

2.4.2 Lista dei File utilizzati per contratti di Servizi Aggiuntivi (partizione sempre presente)


DF:Services application 1 DF 3100h - - - Vedi tabella nomi DF

EF Parameters Linear 3102h 17h 1 29 n.a

EF Contracts Linear 3120h 18h 8 29 n.a.

EF Counters Counter 3169h 1Ah 1 29 n.a.

EF Miscellaneous Linear 3150h 1Bh 8 29 n.a.

2.4.3 Tabella nomi DF

DF Name DF ID Mixed Ascii – Hex Application ID Hex

Master File (MF) 3F00 “3MTR.ICA” D380 1200 9001 334D54522E494341D38012009001

Calypso DF Transport application 1 (DF1)

2000 “1TIC.ICA” D380 1200 9101 315449432E494341D38012009101

Calypso DF Services application 1 (DF2)

3100 “1TIC.ICA” D380 1200 9301 315449432E494341D38012009301

Stored value application (EP aka SV)

1000 “0ETP.ICA” D380 1200 9201 304554502E494341D38012009201

Versione 1



11 / 20 PUBBLICO

2.5 Circuito di appartenenza

2.5.1 Introduzione

Esistono attualmente in Piemonte diverse realtà che adottano una smartcard per l’accesso e la

gestione di servizi :

i cittadini piemontesi per l’accesso ai servizi di mobilità regionale utilizzano una smartcard

denominata BIP;

i giovani tra i 15 ed i 29 anni per l’accesso ai servizi dello sport, tempo libero e mobilità

regionale utilizzano una smartcard denominata PYOU;

gli studenti universitari per l’accesso ai servizi degli atenei e mobilità regionale utilizzano una

smartcard denominata EDISU.

Ai fini di riconoscere a quale circuito originale appartiene la smartcard si è scelto di sfruttare il byte

Application Subtype nelle Startup Information inviato nella risposta al comando di Select Application.

2.5.2 Startup Information

L’applicazione Calypso, nella risposta al comando di Select Application, deve restituire anche le

Startup information come previsto dalle specifiche Calypso Rev. 3.

All’interno delle Startup Information si trova il byte Application Subtype che verrà valorizzato in fase

di produzione per indicare il circuito di appartenenza della carta, i restanti byte sono da valorizzare

come previsto dalla specifica Calypso Rev. 3.

Il borsellino elettronico (SV) dovrà mantenere il byte Application Subtype al valore previsto dalle

specifiche Calypso rev. 3.1 (requisito R157.1).

Versione 1



12 / 20 PUBBLICO

2.5.3 Codifica circuito appartenenza

Valore Descrizione

C0h Circuito BIP

C1h Circuito PYOU

C2h Circuito EDISU

C3h TBD

... ...

2.6 Chiavi di sicurezza da prevedere lato client

Sull’applicazione lato smartphone dovranno essere presenti differenti set di chiavi, ad ogni singola

ADF dovrà essere associato/gestito almeno un set di 3 chiavi in completa autonomia.

Sotto Master File dovrà essere presente un set di chiavi indipendente con tre chiavi distinte e un PIN,

con lunghezza di almeno 4 byte, che potrà essere utilizzato in tutta la struttura del file system. Il PIN

dovrà essere inizializzato al valore 0x30303030 cioè ‘0000’.

Per le funzionalità del Credito Trasporti dovranno essere previste almeno due chiavi indipendenti.

Le chiavi saranno di tipo T_DES.

Ulteriori dettagli sull’utilizzo dei moduli SAM-BIP verranno forniti da 5T ai soggetti economici nel

corso della predisposizione della sperimentazione, a fronte di sottoscrizione di apposito NDA.

2.7 Utilizzo del Credito Trasporti (SV)

Il progetto BIP prevede un titolo di viaggio a deconto contenente un monte unità di viaggio

prepagate denominato "Credito Trasporti".

L’applicazione oggetto di sperimentazione deve consentire la gestione (lettura, scrittura,

aggiornamento) di un valore memorizzato come previsto dalla Calypso revision 3.1.

Le funzionalità richieste all’EP (Electronic Purse) sono le seguenti:

Leggere lo stato dell’EP ovvero il valore memorizzato nell’EP.

Versione 1



13 / 20 PUBBLICO

Incrementare una quantità al valore corrente dell’EP.

Decrementare una quantità al valore corrente dell’EP.

Annullare, in parte o completamente, l’ultimo decremento effettuato.

La lettura dello stato EP è libera.

Per decrementare, annullare parzialmente o totalmente l’ultimo decremento è richiesto che

l’operazione venga effettuata in una sessione sicura Calypso tramite l’utilizzo della SAM CV.

2.8 Condizioni di accesso ai file

Tipi di chiavi segrete:

Key N°1

Issuer key

Chiave di personalizzazione e prepersonalizzazione.

Usata tipicamente per inserire dati generici.

Può essere usata all’interno di una sessione sicura.

Key N°2

Load key

Chiave di ricarica.

Usata tipicamente per rinnovi o ricariche di TdV.


Key N°3

Debit key

Chiave di validazione.

Usata tipicamente per validare/decrementare TdV.


I comandi di accesso ai file sono divisi in quattro gruppi:

Gruppo DF EF lineare EF ciclico EF contatore

0 Rehabilitate Read Record Read Record Read Record

1 Invalidate Update Record Update Record Update Record

2 (rfu) Write Record Write Record Decrease

Decrease Multiple

3 (rfu) (rfu) Append Record Increase

Increase Multiple

Esistono quattro metodi di accesso per ogni gruppo:

Versione 1



14 / 20 PUBBLICO

Access Mode Descrizione

Always Accesso libero: diritti di accesso sempre garantiti

Never Accesso vietato: diritti d’accesso sempre negati

Pin Accesso consentito solo se la carta ha

preventivamente verificato con successo il codice PIN

Session

Accesso consentito solo all’interno di una sessione sicura usando la chiave corrispondente. Questo metodo di acesso può essere applicato solo ai

comandi di modifica (non al read).

Le condizioni di accesso ai file sono definite nelle seguenti tabelle:

Condizioni di accesso dei File presenti sotto Master File:

MF / DF / EF File type

Group 0

read/rehabilitat

e

Group 1

update/invalidate

Group 2

write/decrease

Group 3

append/increase

MF : MF Session 1 Session 3 n.a. n.a.

EF ICC Linear always never/Session 1 never n.a

EF ID Linear PIN Session 2 never n.a.

EF ITP-ID Linear always Session 1 never n.a.

EF ITP-TDV Linear always Session 2 Session 3 n.a.

Condizioni di accesso dei File presenti sotto DF utilizzata dal sistema BIP

MF / DF / EF File type Group 0

read/rehabilitate

Group 1

update/invalidate

Group 2

write/decrease

Group 3

append/increase

DF : Transport 1 DF Session 1 Session 3 n.a. n.a.

Versione 1



15 / 20 PUBBLICO

EF Environment Linear always Session 1 never n.a.

EF Events Log Cyclic always Session 3 Session 3 Session 3

EF Contract List Linear always Session 3 never n.a.

EF Contracts Linear always Session 2 Session 3 n.a.

EF Special Events Linear always Session 3 never n.a.

All Counters Counter always Session 2 Session 3 Session 2

Supplementary

Counters

Counter always Session 2 Session 3 Session 2

Free file Linear always always always always

Condizioni di accesso dei File utilizzati per la gestione del Credito Trasporti


read/rehabilitate

Group 1

update/invalidate

Group 2

write/decrease

Group 3

append/increase

DF :EP DF Session 1 Session 3 n.a. n.a.

EF Load Log Cyclic always never never never

EF Purchase Log Cyclic always never never never

Versione 1



16 / 20 PUBBLICO

Condizioni di accesso ai File utilizzati per contratti di Servizi Aggiuntivi (partizione sempre presente)


read/rehabilitate

Group 1

update/invalidate

Group 2

write/decrease

Group 3

append/increase

DF :Transport 2 DF Session 1 Session 3 n.a. n.a.

EF Parameters Linear always Session 1 never n.a.

EF Contracts Linear always Session 2 Session 3 n.a.

EF Counters Counters always Session 2 Session 3 Session 2

EF Miscellaneous Linear always Session 3 never n.a.

2.9 Codice seriale applet Calypso

Il codice seriale è formato da 8 byte. Esso identifica univocamente il PO a livello universale.

L'emissione dei codici seriali viene regolamentata dalla Calypso Network Association che ne definisce

le modalità di emissione e di utilizzo.

Eventuali adempimenti formali con la CNA sono a carico dei soggetti interessati alla sperimentazione.

Versione 1



17 / 20 PUBBLICO

3 Interfacciamento con l’HSM

Il CSR-BIP, così come previsto dall’architettura del progetto di bigliettazione elettronica regionale, si è

dotato di un HSM (Hardware Security Model), per la gestione della vendita e ricarica dei TdV sui

Portable Object BIP.

L’HSM permette di gestire diverse sessioni sicure remote per aggiornare i Portable Object BIP,

attraverso una varietà di terminali, quali ad esempio parcometri, totem, smartphone dotati di

tecnologia HCE.

La connessione proposta tra il server HCE e l’HSM consiste nell’instaurazione di uno scambio di

messaggi JSON opportunamente formattati tramite il protocollo HTTPS.

Ogni scambio JSON viene inizializzato dall'applicazione client del CCA, che raccoglie tutte le

informazioni necessarie e costruisce le richieste in formato JSON.

Ogni richiesta JSON viene inviata dal client, tramite il metodo POST, ad un URL univoco.

Ulteriori dettagli sull’utilizzo ed interfacciamento del server HSM verranno forniti da 5T ai soggetti

economici nel corso della predisposizione della sperimentazione.

Versione 1



18 / 20 PUBBLICO

4 Modalità di esecuzione della sperimentazione

La sperimentazione avrà luogo prevalentemente nella sede di 5T e presso alcune reti di trasporto

della Aziende TPL afferenti al progetto BIP.

Il personale dell’operatore economico partecipante sarà supportato della struttura tecnica di 5T,

nelle date da concordare tra le parti e per il numero di ore uomo che l’operatore economico

partecipante riterrà necessarie per portare a termine la sperimentazione.

Versione 1



19 / 20 PUBBLICO

5 Collaudo tecnico-funzionale

Il collaudo tecnico funzionale della soluzione proposta verrà effettuato presso la sede di 5T e presso

alcune reti di trasporto della Aziende TPL afferenti al progetto BIP, in contraddittorio con l’operatore

economico partecipante al fine di verificare la corretta interazione tra il PO (smartphone) e gli

apparati di validazione e controllo.

5.1 Prove di funzionamento con l’HSM

Le prove consisteranno nel corretto scambio dati tra il server HCE, l’HSM di 5T ed il PO.

In particolare, verrà verificata la correttezza della ricezione delle firme dei titoli di viaggio e la

scrittura dello stesso all’interno della struttura dati sul PO.

L'esito è considerato favorevole se n. 10 scambi dati consecutivi avranno tutti esito positivo senza

soluzione di continuità.

5.2 Prove di funzionamento con i validatori installati

Le prove consisteranno nella corretta validazione dei titoli di viaggio caricati a bordo del PO

(smartphone).

L'esito è considerato favorevole se n. 10 validazioni consecutive avranno tutte esito positivo senza


5.3 Prove di funzionamento con i terminali di controllo

Le prove consisteranno nel corretto controllo dei titoli di viaggio caricati a bordo del PO

(smartphone).

L'esito è considerato favorevole se n. 10 controlli consecutivi avranno tutti esito positivo senza


5.4 Esito delle prove

Qualora si rilevassero delle funzionalità errate o non conformi l’operatore economico partecipante

avrà facoltà di effettuare le modifiche tecniche ritenute opportune e chiedere a 5T di ripetere il test,

per n. 3 volte e nei limiti temporali di consegna dei documenti conclusivi di cui al seguente capitolo 6.

Versione 1



20 / 20 PUBBLICO

6 Documenti conclusivi

6.1 La Specifica Tecnico/Descrittiva

Al termine della sperimentazione l’operatore economico partecipante dovrà rilasciare a 5T una

Specifica Tecnico/Descrittiva della soluzione proposta, comprendente:

1. la soluzione proposta, costituita da:

l’architettura del sistema;

la descrizione della componente server HCE;

la descrizione della componente App da installare sullo smartphone;

l’elenco degli smartphone compatibili con la soluzione proposta;

2. i tempi di realizzazione;

3. la possibilità di salvaguardare gli investimenti realizzati, costituiti dal server HSM e dagli apparati

di validazione dei supporti BIP già in uso.

6.2 Rilascio di attestato di conformità

Come indicato nell’Avviso Pubblico Esplorativo, di cui questo documento costituisce parte integrante,

a seguito del positivo report di collaudo di cui al precedente capitolo 5 ed il conforme rilascio della

Specifica tecnico-descrittiva di cui al precedente paragrafo 6.1., 5T rilascerà l’attestato di conformità

della soluzione proposta alle esigenze manifestate con questa attività preliminare di

sperimentazione.

Il suddetto attestato costituisce pre-requisito per la partecipazione alla successiva procedura

negoziata, senza tuttavia dare aspettative di buon esito dell’affidamento.

Documents

ATTIVITA’ DI PRELIMINARE SPERIMENTAZIONE · Esistono attualmente in Piemonte diverse realtà he adottano una smartard per l’a esso e la gestione di servizi : i ittadini piemontesi