Ottobre 2014 SPECIFICHE. Titoli di viaggio e requisiti per garantire la sicurezza informativa (documento in consultazione pubblica)

Transcript

1 Ottobre 2014 SPECIFICHE Titoli di viaggio e requisiti per garantire la sicurezza informativa (documento in consultazione pubblica)

2 Sommario 1 BIGLIETTI ELETTRONICI Introduzione e scopo del documento Normativa e documenti di riferimento Requisiti tecnici delle smartcard a microprocessore Introduzione Requisiti fisici e meccanici Requisiti elettrici Protocolli di comunicazione Struttura del file system Circuito di appartenenza Startup Information Chiavi di sicurezza presenti sulla carta Accesso al file system Calypso Condizioni di accesso ai files Dati contenuti sulla carta (card data model) Byte Order Codice seriale carta Codifica della data Codifica dati cliente Codici ID Azienda Codifica EF Environment Codifica campo ID Formato Codice profilo cliente Durata profilo Codice stato carta Codifica codice fiscale Codifica circuito carta EF Contract list EF Contracts Descrizione TAG estensione contratto Estensione numero passeggeri Estensione titoli aziendali Operatore generico Pagina 2 di

3 Estensione O/D Record aggiuntivi EF special events Tipo apparecchio Codificatore EF Events Log Utilizzo del credito trasporti Introduzione Logica applicativa di utilizzo del Credito Trasporti Check-in/check-out con il credito trasporti CARTE A MEMORIA (Chip on Paper) Introduzione Funzionamento delle carte Mifare Ultra Light Requisiti fisici e meccanici Durata della smart card Codice seriale carta (serial number) Lock byte OTP byte Firme di sicurezza Data model - Codifica dati Organizzazione logica dei dati Mappatura logica dei dati Uso dei dati e convenzioni Codifica degli OTP bit Convenzione d'uso degli OTP bit RFU byte Codice/ ID Azienda Seriale SAM Codifica della data Dati Dati del titolo non modificabili Dati del titolo modificabili in fase di vendita/ricarica Dati di validazione e bit di flip/flop LA GESTIONE DELLA SICUREZZA DEI TITOLI ELETTRONICI Pagina 3 di

4 4 BIGLIETTI MAGNETICI Caratteristiche tecniche generali Materiali per il supporto Caratteristiche dei materiali Dimensioni del supporto Caratteristiche di stampa del supporto Materiali e caratteristiche dello strip magnetico Dimensioni dello strip magnetico Caratteristiche magnetiche Codifica magnetica Anticontraffazione Numerazione dei titoli di viaggio Pagina 4 di

5 1 BIGLIETTI ELETTRONICI 1.1 Introduzione e scopo del documento Il progetto ITS Campania, Biglietto Integrato della Regione Campania, prevede l'utilizzo di smart card a microprocessore compatibili con le normative ISO 7816 e di oggetti denominati Smart Object, in generale dispositivi dotati di capacità elaborative, che emulano le funzionalità di una smart card. Solitamente uno smart object è uno Smartphone dotato di tecnologie NFC od altri oggetti simili. Il progetto prevede anche l'utilizzo di carte a basso costo denominate chip on paper. La carta a microprocessore e tutti gli smart object, in emulazione di smart card, verranno utilizzati principalmente per la gestione dei Titoli di Viaggio Elettronici (TDVE) e del Credito Trasporti. Le carte a memoria, a basso costo, saranno utilizzate per la gestione di titoli di trasporto semplici quali corse singole, carnet di biglietti ed altri titoli impersonali ed, in generale, per un utilizzo occasionale. Il presente documento intende dare indicazioni dettagliate sulle tecnologie che dovranno essere utilizzate per sviluppare i nuovi sistemi SBE sul territorio regionale. Ci si pone l'obiettivo di definire le linee guida tecniche e tecnologiche in modo da rispettare i più moderni standard relativi alla bigliettazione elettronica e garantire lo stato dell'arte per quanto concerne i requisiti di interoperabilità e sicurezza. Lo scopo ultimo della specifica è quello di uniformare le modalità di utilizzo della carta su tutto il territorio, rendendo semplici, chiare ed inequivocabili le modalità di gestione operativa dei TDVE. o Nel seguente documento verranno trattate le problematiche inerenti all'utilizzo delle smart card a microprocessore e degli smart object in emulazione di smart card. o Esso fornisce le specifiche tecniche della Carta Regionale dei Trasporti del progetto ITS della Regione Campania e descrive le sue modalità di utilizzo, con particolare riferimento a: o la componente di File System; il modello dati che gli operatori dovranno adottare per codificare in maniera univoca i titoli di viaggio; o Vengono anche definite le componenti di sicurezza che consentono di: o effettuare le operazioni di obliterazione (validazione) di titoli di viaggio; o effettuare le operazioni di vendita e rinnovo e ricarica dei titoli di viaggio; o attivare/emettere/aggiornare i titoli di viaggio; o incrementare e decrementare il Credito Trasporti; o utilizzare la seconda area di memoria trasporti in emulazione delle carte Unico Campania; o utilizzare le ulteriori aree di memoria in autonomia da parte di terzi autorizzati. 1.2 Normativa e documenti di riferimento È richiesta la conformità a quanto definito nelle norme e nei documenti di seguito elencati: 1. Specifiche del sistema operativo Calypso revision 3.1/3.2 - reperibile sul sito del Calypso Network Association; 2. Norme ISO parti da 1 a 4; 3. Norme ISO 7816 parti da 1 a 4 e successive in conformità con quanto definito al punto 2 ; 4. Norme EN 1545 per la definizione del modello dati (per quanto applicabile). 5. Tabella Operatori TPL della Regione Campania redatta da ACAM Pagina 5 di

6 1.3 Requisiti tecnici delle smartcard a microprocessore Introduzione Nel seguente paragrafo vengono trattate le tipologie di smart card dotate di microprocessore o dispositivi equivalenti, anche detti "smart object", quali telefonini NFC, token o tag RFID compatibili. Le smartcard gestite saranno di compatibili con la revisione Calypso 3.1 e Requisiti fisici e meccanici Le dimensioni fisiche delle carte dovranno essere conformi alle specifiche ISO 7816 Parte 1 in particolare il formato indicato con la sigla ID1 di dimensioni LxHxP 85,60mmx53,98mmx0,76mm. Il materiale costruttivo della carta dovrà essere di tipo plastico (PVC, PET o equivalenti), nel caso venga utilizzato un differente supporto fisico dovrà essere fornita opportuna garanzia sulla qualità e sulla sua durata temporale. La rigidità meccanica dovrà essere conforme a quanto indicato nella stessa normativa. Le carte dovranno essere conformi alle normative di resistenza allo stress meccanico (torsione, flessione) indicate dalle ISO Requisiti elettrici Si utilizzeranno preferibilmente smart card cless only oppure, quando richiesto, le "dual interface". Le caratteristiche elettriche riguardanti la parte a contatti delle DI dovranno rispettare la normativa ISO 7816 parte 2. Per quanto riguarda le caratteristiche in radiofrequenza si fa riferimento alle normative ISO parte 1 e 2. Le carte dovranno essere conformi per quanto concerne il protocollo RFID alla normativa ISO parte Protocolli di comunicazione Il protocollo a contatti delle carte Dual Interface dovrà essere conforme alle normative ISO 7816 parte 3, protocollo T=0. Per quanto concerne il protocollo contactless, secondo quanto indicato dalla specifica ISO parte 3, le carte dovranno rispondere inviando il loro ATQB a tutti i comandi di REQB o WUPB inviati da un accoppiatore aventi il seguente valore del parametro AFI: AFI=00hex 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): o o o Protocol Type e TR2, indica la tipologia di protocollo, il valori ammessi sono 1, 3, 5 e 7 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 07hex (frame di lunghezza 128byte) oppure 08hex (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 delle ISO ). I valori massimi ammissibili del parametro Bit_Rate_Capability saranno: Bit_Rate_Capability=B3hex, fino a 424Kbps in entrambe le direzioni. Pagina 6 di

7 1.3.5 Struttura del file system Il file system minimo richiesto sarà formato dai file indicati di seguito. I DF e il MF dovranno essere di tipo Calypso rev3.1/3.2 (anche se non completamente aderente alla specifica, vedi requisito R28). Nella seguente lista dei file sono indicati soltanto i file dall applicazione e non i file di sistema che contengono oggetti di sicurezza (chiavi e pin) e altri file necessari alla funzionalità dell applicazione Calypso. La dimensione della memoria (EEPROM) deve essere adeguata all applicazione nel seguito richiesta. MF / DF / EF File type LID SFI Num Rec. Rec size DF Name MF MF 3F00h - n na Vedi tabella nomi DF EF ICC Linear 0002h 02h a 1 29 n.a. EF ID Linear 0003h 03h 1 29 n.a. Lista dei File presenti sotto Master File Da notare che, anche se indicato nella presente tabella, per alcune tecnologie (p.e. Java card) il Master File potrebbe non essere presente. MF / DF / EF File type LID SFI Num Rec. Rec size DF Name DF : Transport 1 DF 2100h Vedi tabella nomi DF EF Environment Linear 2101h 07h 2 29 n.a. EF Events Log Cyclic 2110h 08h 3 29 n.a. EF Contract List Linear 2150h 1Eh 1 TBD n.a. EF Contracts Linear 2120h 09h 8 TBD n.a. EF Special Events Linear 2140h 1Dh 8 29 n.a. All Counters Counter 2169h 19h 1 29 n.a. Supplementary Counters Counter 216Ah 13h 1 29 n.a. Pagina 7 di

8 MF / DF / EF File type LID SFI Num Rec. Rec size DF Name Free file Linear 21F0h 01h 4 29 n.a. EF Environment Client DF2 Linear 211Fh 14h 1 29 n.a. EF Events Log Client DF2 Cyclic 211Dh 13h 3 29 n.a. EF All Counters Client DF2 Counters 211Ch 1Ch 1 29 n.a. EF Contracts Client DF2 Linear 2123h 15h 4 29 n.a. Application Subtype byte at Startup Information 0608h Session Modifications at Startup Information 06h Lista dei File presenti sotto DF Trasporti ACAM Campania Profilo CD 97 MF / DF / EF File type LID SFI Num Rec. Rec size DF Name DF : Transport 2 DF 2000h Vedi tabella EF Environment (shared file) Linear 2001h 07h 1 29 n.a. EF Events Log (shared file) Cyclic 2010h 08h 3 29 n.a. EF Contract List Linear 2050h 1Eh 1 29 n.a. EF Contracts (shared file) Linear 2020h 09h 4 29 n.a. EF Special Events Linear 2040h 1Dh 1 29 n.a. EF All Counters (shared file) Counters 2069h 19h 1 29 n.a. Simulated Counter #1 to file All Counters ind. count. 202Ah 0Ah - - n.a. Simulated Counter #2 to file All Counters ind. count. 202Bh 0Bh - - n.a. Simulated Counter #3 to file All Counters ind. count. 202Ch 0Ch - - n.a. Simulated Counter #4 to file All Counters ind. count. 202Dh 0Dh - - n.a. Simulated Counter #5 to file All Counters ind. count. 202Eh 0Eh - - n.a. Simulated Counter #6 to file All Counters ind. count. 202Fh 0Fh - - n.a. Simulated Counter #7 to file All Counters ind. count. 2060h 10h - - n.a. Simulated Counter #8 to file All Counters ind. count. 2061h 11h - - n.a. Simulated Counter #9 to file All Counters ind. count. 2062h 12h - - n.a. Application Subtype byte at Startup Information 0608h Session Modifications at Startup Information 06h Lista dei File presenti sotto DF Unico Campania MF / DF / EF File type LID SFI Num Rec. Rec size DF Name 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. Lista dei File utilizzati per la gestione del Credito Trasporti Pagina 8 di

9 MF / DF / EF File LID SFI Num Rec. Rec size DF Name DF : Services application 1 type DF 3100h Vedi tabella nomi DF EF Parameters Linear 3102h 17h 1 29 EF Contracts Linear 3120h 18h 8 29 EF Counters Counter 3169h 1Ah 1 29 EF Miscellaneous Linear 3150h 1Bh 8 29 Lista dei File utilizzati per contratti di Servizi Aggiuntivi (partizione sempre presente) DF Name DF ID Application ID Hex Master File (MF) 3F00 A D Calypso DF Transport application 1 (DF1) 2100 A D Calypso DF Transport application 2 (DF2) E4943h Calypso DF Services application 1 (DF3) 3100 A D Stored value application (EP) 1000 A D Tabella nomi DF Circuito di appartenenza Ai fini di riconoscere a quale circuito originale appartiene la smartcard nella fase iniziale di comunicazione tra coupler e il Portable Object, si è scelto di sfruttare il byte Application Subtype nelle Startup Information inviato nella risposta al comando di Select Application Startup Information Le applicazioni Calypso, nella risposta al comando di Select Application, devono restituire anche le Startup Information come previsto dalle specifiche Calypso rev. 3.1 (par. 5.6 e 9.2.1). Tali dati sono preceduti dal TAG 53h. All interno delle Startup Information (7 byte) si trova il byte Application Subtype che verrà valorizzato in fase di produzione in modo da indicare il circuito di appartenenza della carta (vedi par. Codifica circuito carta), i restanti byte sono da valorizzare come previsto dalla specifica Calypso Rev. 3.1/3.2 Il borsellino elettronico (SV) dovrà mantenere il byte Application Subtype al valore 20hex così previsto dalle specifiche Calypso rev. 3.1 (requisito R157.1) Chiavi di sicurezza presenti sulla carta Sulla carta saranno presenti differenti gruppi di chiavi uno per ogni singola ADF presente nella struttura del file system. Ogni ADF avrà piena autonomia nella gestione dei criteri di sicurezza di accesso ai dati. Pagina 9 di

10 Nel Master File (la cui presenza è non obbligatoria) sarà presente un gruppo di chiavi indipendente con tre chiavi ed un PIN di almeno 4 byte di lunghezza. Il PIN potrà essere utilizzato in tutta la struttura del file system. Le chiavi saranno di tipo DES_X oppure di tipo 3DES. Ulteriori dettagli sull utilizzo dei moduli SAM, la cui fornitura verrà effettuata a cura della Regione Campania, saranno forniti ai costruttori delle smartcard in sede di aggiudicazione delle gare Accesso al file system Calypso Categorie di chiavi segrete Chiave Scopo Funzione Key N 1 Issuer key Chiave di personalizzazione e prepersonalizzazione 1. Key N 2 Load key Key N 3 Debit key Chiave di ricarica. Chiave di validazione. Usata tipicamente per inserire dati generici o dati dell'utente. Usata tipicamente per rinnovi o ricariche di TDVE. Puo essere usata all interno di una sessione sicura. Usata tipicamente per validare/decrementare TDVE. Puo essere usata all interno di una sessione sicura. 1 Per i prodotti Revision 2 che necessitano della key N 0 per la pre-personalizzazione questa chiave deve assumere gli stessi valori della key N 1 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 Decrease 2 (rfu) Write Record Write Record Decrease Multiple Increase 3 (rfu) (rfu) Append Record Increase Multiple Esistono quattro metodi di accesso per ogni gruppo: 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 puo essere applicato solo ai comandi di modifica (non al read). Pagina 10 di

11 Condizioni di accesso ai files Condizioni di accesso dei File presenti sotto Master File MF / DF / EF File type Group 0 read/rehabilitate 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 ACAM 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. 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 Counter always Session 2 Session 3 Session 2 Counters Free file Linear always always always n.a. 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: SV 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 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 Counter always Session 2 Session 3 Session 2 EF Miscellaneous Linear always Session 3 never n.a. Da notare che prima di accedere ad un file di una applicazione è obbligatorio inviare un comando di SelectApplication. Pagina 11 di

12 1.4 Dati contenuti sulla carta (card data model) Nel seguente paragrafo vengono indicate le modalità di codifica e di interpretazione dei dati sulle smartcard. I vari dispositivi che devono leggere e/o aggiornare i dati sulle carte dovranno seguire le modalità di seguito descritte Byte Order Il byte order scelto è il big-endian, quindi per campi di grandezza maggiore di un byte avremo all indirizzo più basso il byte più significativo. Quando un campo si estende in un nibble del byte seguente dovranno essere utilizzati i suoi 4 bit più significativi. Con lo stesso ragionamento quando un campo che occupa anche una frazione di byte comincia a metà di un byte stesso dovrà occupare il nibble meno significativo. Esempi Campo da 2 byte. Il valore 0x0123 dovrà essere memorizzato come segue: Byte 0 Byte 1 0x01 0x b b Campo da 1,5 byte. Valore 0x123 che si estende al nibble successivo: Nibble high Byte 0 Byte 1 Byte 2 Byte 3 Nibble low Nibble high Nibble low Nibble high Nibble low Nibble high Nibble low Campo da 1,5 byte. Valore 0xABC che comincia dal nibble precedente: Byte 0 Byte 1 Byte 2 Byte 3 Nibble Nibble Nibble Nibble Nibble Nibble Nibble Nibble high low high low high low high low --- A B C Codice seriale carta Il codice seriale della carta è definito secondo le specifiche della Calypso Network Association nel Technical Note 014. Esso è formato da 8 byte ed identifica la carta (o lo smart object) a livello universale. L'emissione dei codici carta viene regolamentata dalla Calypso Network Association che ne definisce le modalità di emissione e di utilizzo. Anche per il progetto di bigliettazione elettronica della regione Campania sono stati riservati dei codici seriali univoci presso il CNA. La gestione di tali codici è regolamentata da ACAM la quale li distribuisce ai fornitori, previa opportuna richiesta da effettuarsi prima della fase di produzione delle smart card. L'identificativo della carta è contenuto nel file ICC così come da specifiche Calypso. Pagina 12 di

13 1.4.3 Codifica della data Le date verranno codificate utilizzando campi lunghi tre byte ad aventi valori binari. Il valore binario indicherà i minuti trascorsi a partire dalla data del 1 gennaio dell anno 2005, ore L ora legale non influisce sul calcolo della data. Per tutti i Titoli Di Viaggio Elettronici (di seguito TDVE) in EF Contract (estensioni escluse) le date di inizio e fine validità verranno scritte in complemento a 1 in modo da aumentare il livello di sicurezza del sistema. Tale meccanismo non deve essere implementato per altri EF contenenti campi data. Il massimo valore possibile corrisponde al valore esadecimale FFFFFFh, in decimale Essendoci 60x24=1440 minuti al giorno, utilizzando tre byte possono essere rappresentati circa giorni che corrispondono a circa 31 anni Codifica dati cliente I dati relativi al possessore della carta saranno codificati nel file EF Environment tramite l iscrizione del Codice Fiscale Codici ID Azienda La seguente tabella riporta la codifica univoca a livello regionale nel sistema delle aziende TPL, tale codice numerico deve essere utilizzato per valorizzare il campo ID/Codice azienda nella fase di emissione del titolo di viaggio e ovunque previsto tale dato. Codice Azienda Nome Azienda Codifica EF Environment Nel file EF Environment saranno contenuti dati relativi all azienda TPL che ha curato la fase di emissione della carta e al suo possessore. La scrittura di questo file è consentita solamente tramite la modalità update durante la sessione di personalizzazione con SAMCP e chiave 1 La lettura è libera. Nome campo Lunghezza Offset Descrizione Valori ammissibili Pagina 13 di

14 ID Formato 1 byte 00h Codice Azienda 1 byte 01h Codice Cliente 4 byte 02h Profilo Cliente 1,5 byte 06h Identifica il formato utilizzato per codificare dati Identifica l azienda emettitrice della carta Identifica univocamente il Cliente della singola Azienda TPL Identifica l appartenenza dell utilizzatore ad una particolare profilo tariffario Vedi Codice Azienda Emettitrice Vedi Codice Profilo Utente Durata profilo 1 byte 07h Indica la durata del profilo cliente 00h = nessuna scadenza 01h - FFh = numero mesi di validita dalla data di emissione Stato Carta 1 nibble 08h Stato della carta Vedi Codice Stato Carta Data della prima emissione Data emissione 3 byte 09h della carta Vedi Codifica Data Codice Fiscale 16 byte 0Ch Codice fiscale dell utilizzatore Circuito Carta 1 byte 1Ch Circuito di emissione della carta Vedi Codifica Codice Fiscale Vedi Codifica Circuito Carta Codifica campo ID Formato La seguente tabella definisce i valori ammissibili per il campo ID Formato. Tale campo rappresenta la versione della mascheratura dati e viene richiamato in diversi EF. Valore sull EF Revisione/Circuito Note 00h ACAM Fase preliminare di test Codice profilo cliente I clienti verranno profilati utilizzando la seguente codifica: o 1 nibble per indicare il CCA di appartenenza (CSR per i profili regionali) e 1 byte il codice del profilo Durata profilo Indica l eventuale scadenza del profilo utente. Il valore 0 indica nessuna scadenza, un valore >0 indica il numero di mesi di validità del profilo dalla data di emissione. La data di emissione non deve essere modificata Codice stato carta Durante l'utilizzo le smartcard si possono trovare in differenti stati logici. Distinguiamo gli stati logici della carta descrivendo il ciclo delle fasi di utilizzo che sono state previste. Pagina 14 di

15 Le carte arrivano dalla fabbrica nello stato di pre-personalizzate. Questo stato corrisponde a carte che hanno già subito il processo di pre personalizzazione che consiste nell'inserimento del numero seriale e nel caricamento delle chiavi di sicurezza tramite l'utilizzo delle SAM CPP. La carta viene successivamente emessa dalla singola azienda effettuando la personalizzazione dei dati, con l'inserimento del profilo relativo all'utente, in questo stato diremo che la carta è Personalizzata, pronta quindi per essere utilizzata. In seguito la tabella dei valori associati ai codici di stato carta: Valore 0h/1h 2h RFU Stato carta associato Carta pre-personalizzata (vergine) Carta Personalizzata Durante l'utilizzo da parte dell'utente la carta può essere posta nello stato di Black Listed, quindi bloccata, se essa risulta presente nella relativa lista. Per portare lo stato logico della carta in Black Listed il validatore oppure lo strumento di lettura/scrittura dovrà utilizzare il comando di Invalidate presente nel sistema operativo. Il comando dovrà operare sulla ADF Trasporti sospendendone temporaneamente le funzionalità della carta fino allo sblocco della carta effettuabile presso le biglietterie aziendali autorizzate dotate di appositi terminali di lettura/scrittura Codifica codice fiscale Il codice fiscale del possessore della smart card verrà codificato nel formato indicato dal decreto ministeriale del 23 dicembre 1976 in formato ASCII ISO 646. Di seguito viene illustrato un esempio di codifica. Gennaro Esposito, nato il 9 novembre 1974 a Napoli: SPS GNR 74S09 F839 C Esempio di codifica codice fiscale in formato ASCII ISO646 S P S G N R 7 4 S 0 9 F C 53h 50h 53h 47h 4Eh 52h 37h 34h 53h 30h 39h 46h 32h 33h 39h 43h Codifica circuito carta Questo campo identifica il circuito di provenienza della smart card. Di seguito sono riportati i possibili valori di tale campo: Valore C0h Descrizione ACAM RFU EF Contract list Il file EF Contract List conterrà l'indicazione dei contratti presenti sulla carta e dei relativi contatori ad essi associati. Esso sarà utile per velocizzare le attività di lettura dei contratti durante le fasi di verifica e controllo. La scrittura di questo file è consentita tramite la modalità update durante la sessione di validazione, rinnovo o ricarica (a partire dalla SAM-CV) con la chiave n 3. Pagina 15 di

16 Nel caso di aggiunta di nuovi contratti oppure di cancellazione di contratti preesistenti, il terminale di vendita dovrà obbligatoriamente aggiornare il relativo campo valore nel presente file. Nel caso di TDVE scaduti, il relativo campo nel presente file potrà essere aggiornato dai terminali di validazione. La lettura è libera. Nome campo Lunghezza Offset Descrizione Valori ammissibili ID Formato 1 byte 00h Codifica contratto sul record numero 1 3 byte 01h Identifica il formato utilizzato per codificare dati Vedi tabella successiva Vedi tabella successiva Codifica contratto sul record numero 8 3 byte 16h RFU 4 byte 19h Vedi tabella successiva Vedi tabella successiva Codifica contratto sul record numero n 3 Byte 1 Byte Codice azienda che ha emesso il contratto 1 Nibble H Tipo di contratto 1 Nibble L Validita del contratto 2 Nibble Contatori associati al contratto Vedi tabella codici aziende Fh = estensione del contratto. La codifica delle tipologie di contratto e lasciata alla singola azienda. Valori da 0h 00h non valido/scaduto 01h valido Nibble H contatore X, X:=1,,9 Nibble L contatore Y, Y:=1,,9 Y X Valore 0h-> nessun contatore associato EF Contracts Nel file EF Contratti saranno contenuti dati relativi ai contratti venduti. La scrittura di questo file è consentita: o tramite la modalità update durante sessione personalizzazione vendita con chiave 2 o tramite la modalità write durante la sessione di validazione con chiave 3. La lettura è libera. Per i TDVE che lo prevedono le date di inizio e fine validità dovranno essere impostate dal validatore al primo utilizzo del titolo (prima validazione). Per tutti i TDVE il calcolo della firma (MAC contratto) dovrà essere effettuato considerando le date di inizio e fine validità a 0. Pagina 16 di

17 Per tutti i TDVE le date di inizio e fine validità sono da scrivere in complemento a 1 in modo da aumentare il livello di sicurezza del sistema ACAM Campania. Così facendo un eventuale azione fraudolenta per mezzo di SAM-CV potrebbe solamente retrodatare la validità del TDVE. Ogni azienda che emette titoli potrà scrivere o aggiornare il proprio contratto in questo file. La struttura dei contratti è formata da una parte a campi fissi, sempre presenti in qualsiasi tipologia di contratto, localizzati a offset definiti. Altre informazioni supplementari che caratterizzano il singolo contratto verranno inserite in aggiunta ai campi fissi in modalità TAG-VALUE. Le informazioni aggiuntive non avranno un ordine fisso ma potranno essere individuate tramite i loro tag. Un TDVE non potrà occupare più di 3 record. La struttura del contratto si compone dei seguenti gruppi di valori: o o o o o o informazioni relative all'azienda emettitrice informazioni relative alla tipologia di contratto validità temporale zone di competenza descrizione O/D firma Operatore TPL Nome campo Lunghezza Offset Descrizione Valori ammissibili Codice Azienda Emettitrice del contratto 1 byte 00h Identifica l'azienda emettitrice del contratto Vedi Codice Azienda Emettitrice Identifica il formato ID Formato 1 byte 01h utilizzato per codificare RFU 2 byte 02h RFU dati RFU Codice Tariffa 2 byte 04h Seriale di emissione del contratto Periodo di validita - start 3 byte 06h 3 byte 09h Periodo di validita -end 3 byte 0Ch Giorni di validita del contratto 1 byte 0Fh SAM serial number 4 byte 10h SAM counter 3 byte 14h Codice listino vendita titoli della singola Numero azienda in formato binario Data di inizio validita del contratto oppure inizio validita dalla prima timbratura Data validazione di fine validita del contratto oppure fine validita dalla prima validazione Giorni settimanali di validita, validita festivi Serial number del SAM che ha emesso il TDVE Valore del counter del SAM che ha emesso il TDVE Codice in formato numerico Seriale univoco a livello aziendale del contratto Codifica Data Codifica Data BITMAP: b1= 1 valido il lunedì b2= 1 valido il martedì b3= 1 valido il mercoledì b4= 1 valido il giovedì b5= 1 valido il venerdì b6= 1 valido il sabato b7= 1 valido la domenica b8= 1 valido tutti i giorni festivi Pagina 17 di

18 Nome campo Lunghezza Offset Descrizione Valori ammissibili TAG estensione contratto 2 byte 17h TAG per l estensione ad Vedi descrizione campo opzionale altri record della codifica estensione contratto del TDVE MAC contratto 4 byte 19h Vedi nota tecnica: TBD All'offset 17h se il valore è diverso da A000h è presente un TAG di estensione contratto Descrizione TAG estensione contratto Il campo supplementare di estensione contratto indica la presenza di ulteriori record associati al presente che contengono indicazioni descrittive del contratto. I record del file contratti sono in numero di 8, enumerati da 1 a 8. Un contratto può essere codificato su più record, in questo caso il seguente campo descrittivo supplementare indica la concatenazione esistente tra i record associati al contratto. Pagina 18 di

19 Campo Lunghezza Descrizione Valori ammissibili TAG 1 byte TAG A0h per il record originale, per le estensioni vedi tabelle successive Numero del record associato 1 byte Vi sono due nibble, NH e NL con codifica in BCD. NH indica l'identificativo del record che precede NL indica l'identificativo del record che segue 00h indica che non e puntato alcun record. 02h significa che segue al record numero 2. 10h significa che non segue alcun record ma il presente e la continuazione del record numero Estensione numero passeggeri Nome campo Lunghezza Descrizione Valori ammissibili TAG Numero del record associato Numero passeggeri trasportabili 1 byte 1 byte Vi sono due nibble, NH e NL con codifica in BCD. NH indica l'identificativo del record che precede NL indica l'identificativo del record che segue A1h - numero di passeggeri trasportabili segue 1 byte 00h indica che non e puntato alcun record. 02h significa che segue al record numero 2. 10h significa che non segue alcun record ma il presente e la continuazione del record numero 1. 1 byte Valore binario da 1 a 255 MAC estensione Ultimi 4 byte Vedi nota tecnica:tbd I byte non utilizzati devono essere impostati a 0 (zero) Estensione titoli aziendali Operatore generico Nome campo Lunghezza Descrizione Valori ammissibili TAG 1 byte A7h - informazioni titoli dell'operatore seguono 3 byte Numero del record associato Classe Titolo 1 byte 1 nibble (H) Vi sono due nibble, NH e NL con codifica in BCD. NH indica l'identificativo del record che precede NL indica l'identificativo del record che segue Prima, seconda classe altre tipologie da definire 00h indica che non e puntato alcun record. 02h significa che segue al record numero 2. 10h significa che non segue alcun record ma il presente e la continuazione del record numero 1. Valore binario da 1 a 15 Pagina 19 di

20 Nome campo Lunghezza Descrizione Valori ammissibili Tipologia 1 nibble (L) Standard /ridotto o altro Fasce chilometriche 2 byte Numero chilometri MAC estensione Ultimi 4 byte Vedi nota tecnica:tbd I byte non utilizzati devono essere impostati a 0 (zero) Estensione O/D Nel campo O/D sono codificate le fermate/zone ammesse per l'effettuazione della corsa. Vengono definite innanzitutto le fermate di origine e di destinazione. A seguire vengono indicate tutte le fermate/zone intermedie ordinate in maniera sequenziale. Nome campo Lunghezza Descrizione Valori ammissibili TAG Numero del record associato Codice Fermata/Zona Origine 1 byte 1 byte Vi sono due nibble, NH e NL con codifica in BCD. NH indica l'identificativo del record che precede NL indica l'identificativo del record che segue C0h contratti con Origine- Destinazione descrizione codice fermata origine, destinazione e zone intermedie 00h indica che non e puntato alcun record. 02h significa che segue al record numero 2. 10h significa che non segue alcun record ma il presente e la continuazione del record numero 1. 3 byte Codice fermata/zona Origine Codice Fermata/Zona destinazione Numero zone Codice fermata/zona intermedia 3 byte Codice fermata/zona Destinazione 1 byte Segue una successione ordinata di x codici zone XXh con XX da 1h a FFh, per i contratti con Origine-Destinazione indica il numero totale di fermate/zone intermedie 3 byte Codice zona/area intermedia MAC estensione Ultimi 4 byte Vedi nota tecnica:tbd I byte non utilizzati devono essere impostati a 0 (zero). Se fossero necessari più record negli ultimi 4 byte di ognuno di essi va apposto il MAC Record aggiuntivi Eventuali record aggiuntivi non necessiteranno piu dell intestazione dell estensione e avranno Pagina 20 di

21 quindi la seguente struttura (i primi due byte saranno sempre l estensione contratto così come descritto nel paragrafo): Nome campo Lunghezza Descrizione Valori ammissibili Cyh con y da 1h a Fh che indica il TAG 1 byte numero di zone intermedie nel record Vi sono due nibble, NH e NL 00h indica che non e puntato alcun record. con codifica in BCD. 02h significa che segue al record Numero del record NH indica l'identificativo del 1 byte numero 2. associato record che precede 10h significa che non segue alcun NL indica l'identificativo del record ma il presente e la record che segue continuazione del record numero 1. Codice zona/area intermedia Segue una successione ordinata di y codici zone 3 byte Codice zona/area intermedia MAC estensione Ultimi 4 byte Vedi nota tecnica:tbd EF special events Il file EF Special Events e utilizzato per tenere traccia delle scritture in differita dei TDVE o delle ricariche EP precedentemente acquistati online. A ogni CCA viene quindi riservato un record per tale scopo (se necessario) e non potra utilizzare gli altri record riservati ad altri bacini (vedi tabella seguente), questo allo scopo di regolamentare l accesso a tale EF in modo da non creare problemi di interoperabilità delle SC a livello Regionale. Il file e lineare ed e composto da 8 record. Record CCA assegnato 1 EAV 2 RFU 3 RFU... RFU 8 RFU Nome campo Lunghezza Offset Descrizione Valori ammissibili ID Formato 1 byte 00h Identifica il formato utilizzato per codificare dati Codice Azienda Emettitrice del contratto 1 byte 01h RFU 2 byte 02h Codice Tariffa 2 byte 04h Codice listino vendita titoli della singola azienda Data di vendita 3 byte 06h Codifica temporale Seriale di emissione del contratto Tipo dell'apparato utilizzato Codice in formato numerico 3 byte 09h Numero in formato binario Seriale univoco a livello aziendale del contratto 1 byte 0Ch Vedi tabella in seguito Pagina 21 di

22 Nome campo Lunghezza Offset Descrizione Valori ammissibili Codice seriale apparato di vendita/rinnovo ID SAM di vendita 4 byte 0Fh RFU 8 byte 13h 2 byte 0Dh Identificatore seriale MAC special events 2 byte 1Bh Vedi nota tecnica:tbd Tipo apparecchio Codificatore Codice Descrizione 0 Riservato 1 Codificato in biglietteria o Super-rivendita 2 POS rete vendita 3 PDA terminale di verifica 4 TVM 5 Terminali self service 6 Vendita tramite E-commerce 7 Vendita a bordo 8 Centro massivo 9 RFU EF Events Log Il seguente file e di tipo circolare. Esso contiene 3 record di 29 byte che vengono utilizzati in maniera sequenziale per mantenere traccia delle ultime attivita di check e/o verifica effettuate. Nome campo Lunghezza Descrizione Valori ammissibili ID Formato Codice Azienda Emettitrice del contratto Seriale del contratto Tipo operazione 1 byte 1 byte 3 byte 1 nibble H Identifica il formato utilizzato per codificare dati Definisce l'ultima operazione effettuata 00h check-in SV 01h check-out SV 02h check-in TDVE 03h check-out TDVE 04h verifica RFU 1 nibble L Data di convalida Fermata / area operazione Codifica linea 3 byte 3 byte 3 byte Indica la data in cui e stata eseguita l'operazione Formato data Codifica corsa 3 byte Pagina 22 di

23 Nome campo Lunghezza Descrizione Valori ammissibili Checkin Importo scalato Checkout - Importo riaccreditato Data di convalida del primo check in in regime di integrazione Credito totale scalato a partire dalla prima validazione in regime di integrazione Num. Record contratto Km percorsi al momento checkout 2 byte 3 byte 2 byte 1 Nibble H 1,5 byte Per agevolare il calcolo delle tariffe in integrazione. Valore >= 0 che esprime gli cent. Da 1 a 8 indica record di EF Contracts Fh per utilizzo EP MAC event log 2 byte Vedi nota tecnica:tbd Utilizzo del credito trasporti Introduzione Il progetto ACAM prevede un titolo di viaggio a deconto contenente un monte unita di viaggio prepagato denominato "Credito Trasporti". L'ammontare del Credito sara gestito tramite le funzionalita dello Stored Value previsto dalle specifiche Calypso revision 3.1/3.2. Le funzionalita richieste allo SV (Stored Value) sono le seguenti : o Leggere lo stato dello SV ovvero il valore memorizzato. o Incrementare una quantita al valore corrente dello SV. o Decrementare una quantita al valore corrente dello SV. o Annullare, in parte o completamente, l ultimo decremento effettuato. La lettura dello stato dello SV e libera. Per incrementarne il valore, in fase di ricarica e richiesto che l operazione possa essere effettuata in una sessione sicura Calypso tramite l utilizzo della SAM CL o superiori. Per stornare parzialmente o totalmente l ultimo addebito e richiesto che l operazione possa essere effettuata in una sessione sicura Calypso tramite l utilizzo di moduli SAM CV. Il modulo SAM che effettua lo storno può differire da quello che ha effettuato il decremento Logica applicativa di utilizzo del Credito Trasporti Per Credito Trasporti si intende un titolo a consumo prepagato. La tipologia di Titolo di Viaggio acquistata tramite il Credito Trasporti e sempre la Corsa Semplice in ambito urbano ed un Origine/Destinazione in ambito extraurbano. Pagina 23 di

24 Il sistema di bordo (validatore) deve essere in grado di calcolare la tariffa corretta per ogni viaggio e di decrementarla dal contratto Credito Trasporti aggiornando l importo residuo. L'importo verra calcolato secondo il Tariffario Regionale vigente Check-in/check-out con il credito trasporti La funzione di Check-in/check-out" si applica soltanto al servizio extraurbano ed alle linee extraurbane abilitate al servizio urbano. Il cliente deve convalidare sia in salita che in discesa. In salita, il validatore calcola l'importo corrispondente tra l'origine (fermata di salita) ed il capolinea (destinazione). Tale importo e decrementato dal valore del C.T. con l'esecuzione del comando di SV Debit e, contemporaneamente, vengono memorizzati in un campo temporaneo sulla smart card (file di Log) le informazioni relative alla fermata di salita ed all'ammontare addebitato. Se l'importo residuo del C.T. non e sufficiente, il saldo sulla smart card assumera valori al di sotto del minimo credito consentito. In discesa (check-out), il validatore ricalcola l'importo corrispondente relativo alla corsa realmente effettuata e, nel caso che l'importo dovuto fosse minore del valore gia decrementato, procedera automaticamente al riaccredito della differenza operando un comando di SV Undebit. Nel caso in cui il cliente non effettui il check-out il C.T. rimarra al valore decrementato, l'importo pagato sara quindi equivalente all'intera corsa (origine-capolinea). L applicazione SV a bordo della smartcard utilizza 3 byte per memorizzare e gestire l ammontare del CT. Tale valore e un numero con segno ed ha il seguente range: da a L applicazione di SV non prevede l utilizzo di valori negativi limitando così il range: da 0 a Per potere gestire valori di credito negativi (così come richiesto dagli operatori in sede Regionale) si e deciso di realizzare una logica applicativa che interpreta il contenuto dello SV seguendo alcune direttive: Range effettivo dell EP (valore numerico nell EP) Valore interpretato dal SW ( cent) Limite inferiore Zero logico Limite superiore Valore in -.943, ,03 Quindi uno SV che contiene il valore (0x400000) esprime in realta una cifra, per il circuito ACAM Campania, pari a 0 (zero). Si tratta quindi di effettuare una semplice conversione sottraendo al valore letto dalla smartcard la costante Il valore letto dall EP e convertito come appena descritto e espresso in cent e va quindi ancora diviso per 100 (cento) per ottenere la cifra in. Esempio 1 Credito del cliente: +10,50 Valore dell EP Pagina 24 di

25 Valore interpretato dal SW ( cent) Valore in +10,50 Esempio 2 Credito del cliente: -7,20 Valore dell EP Valore interpretato dal SW ( cent) -720 Valore in -7,20 Il CT puo essere ricaricato presso i punti vendita dell'azienda che ha emesso la smart card oppure presso la rete di vendita degli altri operatori di trasporto aderenti al ACAM Campania. Il CT puo essere utilizzato per effettuare l'acquisto/pagamento dei singoli Titoli di Viaggio del ACAM Campania e di altri servizi di mobilita quali parcheggi di struttura, sosta, car sharing, bike sharing. Pagina 25 di

26 2 CARTE A MEMORIA (Chip on Paper) 2.1 Introduzione Il progetto ITS Campania, Biglietto Integrato della Regione Campania, prevede oltre l'utilizzo di smart card, anche la possibilita di utilizzare delle carte a basso costo per la vendita di Titoli di Viaggio impersonali da utilizzarsi occasionalmente, quali ad esempio la corsa semplice, il carnet di biglietti e le carte valore. Resta inteso che i dati di BE raccolti da questo tipo di supporto devono comunque essere gestiti ed inviati al CCA di pertinenza e conseguentemente al CSR per le applicazioni regionali di BI (e di clearing se necessario). Questo capitolo fornisce le specifiche tecniche dei supporti leggeri (chip-on-paper) nell ambito del progetto ITS Campania per quanto concerne le funzionalita contactless e le strutture dati, in particolare il supporto leggero scelto e Mifare UL. 2.2 Funzionamento delle carte Mifare Ultra Light Nel sistema di bigliettazione verranno utilizzate delle carte a memoria a basso costo per la vendita di Titoli di Viaggio. Saranno utilizzate carte a memoria, impropriamente chiamate Chip on Paper per il fatto che sono costruite utilizzando un supporto cartaceo di spessore 0,4mm. I Chip on Paper hanno una capacita di memoria di almeno 512 bit organizzata in 16 pagine di 4 byte ciascuna Requisiti fisici e meccanici Lo standard che definisce il ticket e l'en Lo standard di comunicazione utilizzato dalle carte Mifare UL e ISO A e 26permette una trasmissione dati fino a 106 kbit/s. Caratteristiche fisiche: dimensioni: 85,6x54mm (ISO standard), con angoli arrotondati spessore: minimo 0,180 gr/m2, massimo 0,250 gr/m2 finitura: carta adatta per personalizzazione con stampanti a trasferimento termico fan-fold da 10 unita, piega ogni unita ; forza di separazione compresa tra 40 e gli 80 N Durata della smart card I processi produttivi delle carte devono garantire una durata di almeno 4 anni e pertanto devono essere particolarmente curate le seguenti attivita : l embedding, soprattutto in relazione al collegamento dell antenna al microprocessore, la stampa in laser engraving e tutte le attivita produttive che possono causare stress meccanici ed elettrici. A tale proposito si rammenta la conformita alle norme citate nel paragrafo 2.2 per quanto Pagina 26 di

27 riguarda le caratteristiche fisiche ed in particolare ISO/IEC paragrafo 4 e le relative norme collegate (ISO/IEC 10373) Codice seriale carta (serial number) Il codice seriale della carta e formato da una stringa lunga 7 byte. Alla pagina di memoria di indice 0 vi sono i primi tre byte del serial number S0, S1 ed S2 seguiti da 1 byte di controllo. La pagina con indice 1 contiene la seconda ed ultima parte del serial number con i byte S3, S4, S5 ed S6. Il byte di controllo relativo alla seconda parte del serial number si trova alla pagina di indice 2 seguito di byte Internal ed i Lock Bytes. ll byte SN0 rappresenta un codice legato al produttore del chip. UID/Serial number Lock byte La pagina 2 contiene anche due byte di lock suddivisi: un bit di lock per ogni pagina dalla 3 alla 15, se tale bit viene posto a 1 la relativa pagina di memoria diventa read-only (totale 12 bit) block-locking bit uno per la pagina 3, uno per le pagine da 4 a 9 e uno per le pagine da 10 a 15. Una volta posti ad 1 tali bit impediscono di cambiare lo stato dei lock bit delle relative pagine di memoria (freeze della configurazione read/write delle zone di memoria). Pagina 27 di

28 Lock byte OTP byte La pagina 3 contiene 32 OTP bit. In fase di produzione tali bit sono disposti a 0 e una volta settati a 1 non possono piu essere cambiati (funzione utile come contatore per i carnet e per incrementare al sicurezza). OTP Byte Firme di sicurezza Per garantire l autenticita di un contratto presente sul CoP, la sua validita, l'autenticita dell'azienda emettitrice e che esso non sia stato modificato da terzi, e stata introdotta la firma del contratto, ovvero un valore numerico che rappresenta la firma univoca di una sequenza di byte di lunghezza generica. Pagina 28 di

29 Si prevede l utilizzo dei SAM Calypso per apporre le firme dei dati. I SAM Calypso sono stati progettati anche per i supporti leggeri come le carte memoria. Le firme per i CoP saranno apposte con la modalita busy mode attivata, siccome Calypso offre diverse modalita di calcolo della firma digitale che ne rafforzano la sicurezza: Busy mode (sempre attiva): Questa modalita scongiura il pericolo di attacchi di brute force per forzare il sistema di crittografia, infatti dopo un tentativo fallito di verifica della firma il SAM rimane busy per qualche secondo (max.10) nei quali quindi e impossibile eseguire altri tentativi. Traceability mode (attiva solo per la firma di emissione): Questa modalita inserisce automaticamente, all offset specificato nel comando di calcolo o verifica della firma, SAM ID (4byte) e SAM Counter (3byte). Tali dati sono univoci a livello planetario e permettono di individuare chi e quando e stata effettuata la firma digitale. Per ogni tipologia di mascheratura dei CoP sono previste due firme: la prima viene apposta all atto di emissione da un modulo SAM-CL con modalita di traceability, e di 4 byte e per la sua computazione viene usata la chiave di firma relativa all operatore che emette il biglietto; la seconda e relativa alle informazioni di validazione e viene generata da un modulo SAM- CV, e di 2 byte e viene usata una chiave che e uguale per tutti gli operatori. Questa firma non ha lo scopo di certificare chi ha emesso/validato il titolo, ma piuttosto quello di evitare la clonazione dei ticket soprattutto per quei TdV che prevedono piu utilizzi (carnet multi corse). Sono esclusi dal calcolo della firma i byte dove la firma verra scritta. 2.3 Data model - Codifica dati Di seguito viene descritto un data model che introduce la tecnica del flip flop e che ottimizza il numero di scritture necessarie. Le firme di autenticita dei dati sono valutate utilizzando i SAM di ACAM Organizzazione logica dei dati I dati che vengono scritti in memoria vengono divisi in 4 gruppi: la OTP: e l'area che viene utilizzata per mantenere il conteggio dei titoli validi disponibili; dati fissi statici: sono dati inseriti all emissione del titolo e non piu modificabili; dati fissi variabili:sono dati inseriti all emissione del titolo e che possono essere modificati all'atto delle ricariche da parte dei dispositivi di ricarica; parte variabile di validazione: tale parte contiene i dati utili alla convalida ed e aggiornata ogni qual volta viene convalidato un nuovo titolo. Una riga della parte variabile e stata duplicata, la riga 13 verra chiamata per convenzione la riga flip e la riga 14 riga flop Mappatura logica dei dati Di seguito viene indicata la leggenda dei valori contenuti all'interno del data model proposto. Pagina 29 di