ATTIVITA DI PRELIMINARE SPERIMENTAZIONE

Transcript

1 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 1 / 20

2 Indice 1 INTRODUZIONE ARCHITETTURA Normative e documenti di riferimento Protocolli di comunicazione File System Liste dei file presenti sotto Master File Liste dei File presenti sotto DF utilizzata dal sistema BIP Lista dei File utilizzati per la gestione del Credito Trasporti Lista dei File utilizzati per contratti di Servizi Aggiuntivi (partizione sempre presente) Tabella nomi DF Circuito di appartenenza Introduzione Startup Information Codifica circuito appartenenza Chiavi di sicurezza da prevedere lato client Utilizzo del Credito Trasporti (SV) Condizioni di accesso ai file Codice seriale applet Calypso INTERFACCIAMENTO CON L HSM MODALITÀ DI ESECUZIONE DELLA SPERIMENTAZIONE COLLAUDO TECNICO-FUNZIONALE Prove di funzionamento con l HSM Prove di funzionamento con i validatori installati / 20

3 5.3 Prove di funzionamento con i terminali di controllo Esito delle prove DOCUMENTI CONCLUSIVI La Specifica Tecnico/Descrittiva Rilascio di attestato di conformità / 20

4 1 Introduzione Definizioni ed Acronimi Acronimo APDU BIP CNA CSR HCE NDA PO SIM TDV TPL Definizione Application Protocol Data Unit Biglietto Integrato Piemonte Calypso Network Association Centro Servizi Regionale Host Card Emulation Non-Disclosure Agreement Portable Object Subscriber Identity Module Titoli di viaggio Trasporto Pubblico Locale Con la Delibera n 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 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 4 / 20

5 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 ( 5 / 20

6 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. CSR-BIP HSM DB tariffe Client HCE service manager 6 / 20

7 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 parti da 1 a Protocolli di comunicazione Il protocollo contactless dovrà essere conforme alla normativa ISO 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 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 della ISO ). I valori massimi ammissibili del parametro Bit_Rate_Capability saranno: o Bit_Rate_Capability=B3hex, fino a 424Kbps in entrambe le direzioni. 7 / 20

8 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 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. 8 / 20

9 2.4 Liste dei File presenti sotto DF utilizzata dal sistema BIP MF / DF / EF File type LID SFI Num Rec. Rec size DF Name 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 Lista dei File utilizzati per la gestione del Credito Trasporti MF / DF / EF File type LID SFI Num Rec. Rec size DF Name DF: EP Stored value application DF 1000 h Vedi tabella nomi DF EF Load Log Cyclic 1014 h EF Purchase Log Cyclic 1015 h 14h 1 29 n.a. 15h 3 29 n.a. 9 / 20

10 2.4.2 Lista dei File utilizzati per contratti di Servizi Aggiuntivi (partizione sempre presente) MF / DF / EF File type LID SFI Num Rec. Rec size DF Name 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 Tabella nomi DF DF Name DF ID Mixed Ascii Hex Application ID Hex Master File (MF) 3F00 3MTR.ICA D D54522E494341D Calypso DF Transport application 1 (DF1) TIC.ICA D E494341D Calypso DF Services application 1 (DF2) TIC.ICA D E494341D Stored value application (EP aka SV) ETP.ICA D E494341D / 20

11 2.5 Circuito di appartenenza 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 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). 11 / 20

12 2.5.3 Codifica circuito appartenenza Valore C0h C1h C2h C3h Descrizione Circuito BIP Circuito PYOU Circuito EDISU TBD 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 0x cioè 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. 12 / 20

13 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 Key N 2 Load key Key N 3 Debit key Chiave di personalizzazione e prepersonalizzazione. Usata tipicamente per inserire dati generici. Può essere usata all interno di una sessione sicura. Chiave di ricarica. Usata tipicamente per rinnovi o ricariche di TdV. Può essere usata all interno di una sessione sicura. Chiave di validazione. Usata tipicamente per validare/decrementare TdV. Può essere usata all interno di una sessione sicura. 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 3 (rfu) (rfu) Append Record Decrease Decrease Multiple Increase Increase Multiple Esistono quattro metodi di accesso per ogni gruppo: 13 / 20

14 Access Mode Always Never Pin Session Descrizione Accesso libero: diritti di accesso sempre garantiti Accesso vietato: diritti d accesso sempre negati Accesso consentito solo se la carta ha preventivamente verificato con successo il codice PIN 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. 14 / 20

15 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 MF / DF / EF File type Group 0 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 15 / 20

16 Condizioni di accesso ai File utilizzati per contratti di Servizi Aggiuntivi (partizione sempre presente) MF / DF / EF File type Group 0 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. 16 / 20

17 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. 17 / 20

18 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. 18 / 20

19 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 soluzione di continuità. 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 soluzione di continuità. 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 / 20

20 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. 20 / 20