Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica e dell Automazione

Transcript

1 UNIVERSITÀ POLITECNICA DELLE MARCHE Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica e dell Automazione Tesi di Laurea: Progetto e sviluppo della gestione delle smart card governative (CIE\CNS\Carta Raffaello) attraverso le API Java S.A.T.S.A. per l erogazione di servizi sociosanitari sulla piattaforma MHP della TV digitale terrestre. Candidato: Moreno Paolini Relatore: Prof. Aldo Franco Dragoni Anno Accademico 2007/2008

2

3 [ ] Mio padre non ha fatto l università perciò era importantissimo che io facessi l università. Dopo l università l ho chiamato in interurbana e gli ho chiesto, e adesso?[ ] Tyler Durden Fight Club di Chuck Palahniuk

4

5 INDICE Indice 1 Introduzione 5 Capitolo 1 - Introduzione alla Televisione Digitale Terrestre e la situazione Italiana Introduzione alla Televisione Digitale Terrestre Scenario Dei componenti dello Standard DVB-MHP Program Content Playout MHP Application Authoring & Production Tools Content Management System (CMS) Download Server & Firmware Upgrade MHP PKI (Public Key Infrastructure) PSI/SI DSM-CC Conditonal Access System (CAS) Network Equipment MHP Terminal Return Channel Application Specific Backend Server Scenario degli Attori dello Standard DVB-MHP MHP Authoring Tool Vendor MHP Application Developer MHP Service Provider 19 1

6 INDICE Broadcaster Network Operator MHP Playout Vendor CAS Provider ISP MHP Backend Opeartor MHP Terminal Vendor DVB Services SARL MHP Certification Autority End User MHP SW Stack Provider Architettura Base delle applicazioni MHP DVB-J Le Xlet DVB-HTML Il Digitale Terrestre in Italia IL DGTVi ed i Bollini 31 Capitolo 2 - Le smart Card, le Smart Card Governtive e le java API SATSA Le Smart Card Classificazione delle Smart Card Lo Standard ISO\EIC ISO/IEC , caratteristiche fisiche ed elettriche ATR Answer To Reset Il Protocollo T= Il protocollo T= Lo standard ISO/EIC , il File System Lo standard ISO/IEC , le APDU Lo standard ISO/IEC , Secure Messaging (SM) Le Smart Card Governative 53 2

7 INDICE La Carta di Identità Elettronica La Carta Nazionale dei Servizi La Carta Raffaello Specifiche tecniche comuni Il File System I comandi APDU Le API Java SATSA Architettura delle applicazioni SATSA Utilizzo dei Thread SATSA negli Standard per la TV Digitale Terrestre Le Specifiche del Packages SATSA-APDU Aprire una connessione con le SATSA-APDU Scambio dei messaggi APDU Chiusura di una connessione Esempio di applicazione con le SATSA-APDU 73 Capitolo 3 - L A.S.U.R. Marche n 7, il laboratorio per il DTT, l Applicazione e le Problematiche L ASUR n 7 e il progetto per la TV DTT Il Digital Divide e l applicazione dell ASUR n 7 sul Digitale Terrestre Le Problematiche dell applicazione dell ASUR n 7 sul Digitale Terrestre Il Laboratorio presente all ASUR n 7 e le Pro blematiche Le Problematiche del Laboratorio Possibili Laboratori per lo Sviluppo Applicazioni MHP e La Soluzione Adottata La prima soluzione La seconda soluzione La terza soluzione La quarta soluzione La soluzione adottata 97 3

8 INDICE Capitolo 4 - Lavoro svolto: gestione delle smart card con le API Java SATSA Sviluppo della gestione delle Smart Card con le Java API SATSA Progetto MHPSmartCard Descrizione delle Classi e del loro Funzionamento Refactoring della gestione Smart card nella applicazione dell ASUR n Capitolo 5 - Conclusioni e Sviluppi Futuri 115 Ringraziamenti 117 Appendici 119 Appendice A - Progetto MHPSmartCard 119 A.1 - MHPSmartCardReader.java 119 A.2 - SatsaSCManager.java 128 A.3 - SatsaSCManagerListaner.java 130 A.4 - SatsaSCSlotListener.java 131 A.5 - SatsaSCReader.java 132 A.6 - ParserUserSCDate.java 138 Appendice B Refactoring applicazione ASUR B.1 - PaginaSatsaCard.java 142 B.2 - SatsaSCSoltListener.java 149 B.3 - SatsaSCRader.java 149 B.4 - ParserUserSCData.java 149 Glossario 150 Bibliografia 151 Webografia 153 4

9 INTRODUZIONE INTRODUZIONE E PRESENTAZIONE DELLA TESI La tesi che vado a presentare è frutto del lavoro svolto nel tirocinio presso il centro di elaborazione dati (CED) dell A.S.U.R. zona territoriale 7 di Ancona. Lo scopo del lavoro è quello di aggiornare la gestione delle smart card governative (Carta di Identità Elettronica, Carta Nazionale dei Servizi o Carta Raffaello) dell applicazione, precedentemente svolta dall Ing. Nardini per l ASUR, che offre servizi on-line sulla televisione digitale terrestre e che era stata progettata con degli standard ormai non più supportati. Il grosso ostacolo che ho cercato di superare è stato quello della ricerca di alcune soluzioni, della scelta e della realizzazione di un nuovo laboratorio di sviluppo, essendo quello presente all ASUR ormai inadeguato per i nuovi scopi. La tesi si suddivide in quattro capitoli fondamentali, più conclusioni e sviluppi futuri. Nel primo capitolo ho introdotto il mondo della televisione digitale terrestre e descritto lo standard DVB-MHP per la TV interattiva, in particolare sono rappresentati e messi in relazione componenti e gli attori dello scenario DVB-MHP. Successivamente ho illustrato la situazione italiana per quanto riguarda la televisione e l associazione DGTVi. Nel secondo capitolo descrivo la smart card e lo standard di riferimento ISO\IEC 7816, le smart card governative utilizzate 5

10 INTRODUZIONE (CIE\CNS\Carta Raffaello) ed in fine, la parte più importante, lo studio delle API Java S.A.T.S.A. in ambiente DVB-MHP. Nel terzo capitolo presento l ASUR come azienda, i servizi che offre on-line e l attuale applicazione per la televisione digitale terrestre. Poi si espongono le problematiche dell applicazione e le soluzioni per un nuovo laboratorio di sviluppo delle applicazioni MHP per l A.S.U.R.. Il quarto capitolo è quello dove illustro il lavoro concreto svolto, cioè la creazione di una applicazione MHP utilizzando la API Java S.A.T.S.A. per la gestione delle smart card governative e il refactoring dell'applicazione sviluppata da Nardini nella parte della gestione delle smart card governative, in modo da avere la nuova gestione secondo i recenti standard MHP utilizzando le API Java S.A.T.S.A.. Nelle appendici ci sono i codici sorgenti delle applicazioni svolte in modo che con appositi simulatori o set top box da sviluppo si riesce a testare il lavoro. Buona Lettura. 6

11 CAPITOLO 1 INTRODUZIONE ALLA TELEVISIONE DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA 1.1 INTRODUZIONE ALLA TELEVISIONE DIGITALE TERRESTRE La TV digitale terrestre è la naturale evoluzione della diffusione del segnale televisivo da analogico a digitale utilizzando la normale antenna televisiva. La sigla che identifica questa nuova tecnologia di trasmissione è DVB-T (Digital Video Broadcasting - Terrestrial). Questo è lo standard europeo DVB per la trasmissione televisiva terrestre. Il sistema prevede la trasmissione di un flusso audio e video digitale della famiglia MPEG-2, utilizzando un sistema di modulazione OFDM con codifica concatenata. Figura 1 - Schema funzionamante trasmissione DVB-T 7

12 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA In Italia inoltre è presente anche lo standard DVB-MHP (Digital Video Broadcasting - Multimedia Home Platform) il quale è lo standard europeo della famiglia DVB per la televisione interattiva, pubblicato inoltre anche come standard Open dall ETSI (European Telecommunications Standards Institute). L MHP (abbreviazione di DVB-MHP) racchiude un set di specifiche middleware Open e Java compatibili. È stato progettato per funzionare su tutte le tecnologie di trasmissione DVB ed la sua caratteristica principale è quella dell'utilizzo di un unico middleware standard per la televisione interattiva in modo da avere una situazione dove i costruttori di STB o TV possano competere su più mercati, piuttosto che essere legati a prodotti proprietari di una particolare emittente o operatore. Ci sono per ora 3 versioni, l una evoluzione dell altra, descritto dalla Figura 2. Figura 2 - Versioni dello Standard DVB-MHP Attualmente la maggior parte dei ricevitori MHP in Italia hanno la certificazione per la versione MHP 1.0 ma si stanno sviluppando e immettendo nel commercio nuovi ricevitori che rispecchiano alcune delle specifiche MHP

13 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA La tre versioni possono essere descritte, per quanto riguarda le caratteristiche tecniche, con i tre profili dell architettura MHP(Figura 3). Figura 3 - Profili Standard DVB-MHP Enanched Broadcaster: permette servizi di radio diffusione avanzata per arricchire e completare i servizi televisivi di base per mezzo di contenuti multimediali. Inoltre tale profilo permette la trasmissione di servizi EPG ( Elettronic Program Guide guida elettronica dei programmi), teletext avanzato e giochi, memorizzandoli nella memoria del ricevitore MHP. La conformità a questo profilo prevede che i ricevitori abbiano l accesso al canale di trasmissione broadcast ma il canale di ritorno è opzionale. E possibile allestire servizi che combinino le trasmissioni digitali ordinarie con software scaricabili, lasciando ai broadcaster ed ai costruttori una discreta libertà di progetto. Interactive Broadcaster: questo profilo richiede obbligatoriamente il canale di ritorno, permettendo di aggiungere 9

14 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA ai servizi del profili Enanched Broadcasting servizi di tipo interattivo con la possibilità per l utente di interagire con un centro servizi attraverso il canale di ritorno. Sarà possibile offrire servizi di tipo pay, pubblicità interattiva, transizioni (home banking, T-commerce), T-Government oppure T-Health. In tale profilo la navigazione Internet è implicita, cioè codificata all interno delle applicazioni e trasparente per l utente. Le caratteristiche del profilo devono essere compatibili con l impiego dei protocolli di comunicazione previsti dallo standard MHP, e non devono comportare per l utente la necessità di ripetere più volte l inserimento di informazioni personali, testi o sequenze numeriche. Nella realizzazione delle applicazioni per fornire questo tipo di servizi è possibile aver bisogno della gestione e dell accesso alle smart card connesse direttamente ai ricevitori MHP tramite il lettore integrato, ovvero inserito in un modulo CAM (Conditional Access Module) connesso allo slot di interfaccia comune. Internet Access: tale profilo offre la possibilità di accedere a servizi di tipo Internet come la navigazione su siti Web, di effettuare transizioni commerciali sfruttando i protocolli di sicurezza già presenti. La presenza di questo profilo rende lo standard MHP tecnicamente molto più potente delle piattaforme esistenti, poiché contempla le caratteristiche di entrambi i profili precedenti e rappresenta quindi il vero punto di convergenza tra tecnologie informatiche e televisive. Nel caso di connessioni always-on ci sono problemi di sicurezza e le specifiche MHP prescrivono l utilizzo del protocollo TLS (Transport Layer Security), permettendo un livello minimo di autenticazione RSA della firma digitale. Sono previsti meccanismi, procedure e dotazioni minime per la gestione dei certificati x509 che consentono l implementazione dell infrastruttura a chiave pubblica PKI, necessaria anche per l autenticazione del server all atto di aprire una sessione sicura sul canale interattivo. Il profilo Internet Access resta comunque ancora lontano dalla realizzazione pratica e sarà completato nelle evoluzioni della versioni superiori dello standard. 10

15 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA 1.2 SCENARIO DEI COMPONENTI DELLO STANDARD DVB-MHP Questa sezione illustra la tipica architettura e l'infrastruttura dei componenti del sistema dello standard DVB-MHP. Attraverso questo elenco di componenti vengono descritti le caratteristiche e i loro ruoli nella catena mettendoli poi in relazione agli attori che operano per il funzionamento del sistema MHP. Le relazioni dei componenti che ci sono possono essere raffigurati dalla Figura 4. Figura 4 - Scenario Componenti dello Standard DVB-MHP 11

16 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA PROGRAM CONTENT PLAYOUT Questa funzione non fa parte dello standard MHP ma riguarda le reti dei broadcaster. In sostanza i programmi televisivi che vengono prodotti devono essere mandati in onda attraverso il sistema di trasmissione e quindi vanno immessi nel Program Content Playout, che è collegato direttamente con il Network Equipment. L effettiva implementazione dipende dal formato del particolare sistema. Tipicamente il Program Content Playout è costituito da un server video, che memorizza e riproduce i flussi delle trasmissioni TV, o da un encoder che converte il materiale non compresso in un formato DVB compatibile. Il problema principale di questi processi sta nell estrarre il tempo di riferimento dei contenuti dei programmi per il sincronismo con il resto del sistema MHP APPLICATION AUTHORING & PRODUCTION TOOLS Questa parte consiste nella progettazione, nello sviluppo e nella messa in onda di una applicazione MHP interattiva tramite i broadcaster che la associano ai programmi televisivi e gestendo poi le informazioni inviate e ottenute tramite dei Content Managemet System (CMS) CONTENT MANAGEMENT SYSTEM (CMS) Un CMS è un sistema che separa il contenuto delle informazione e dei dati dalla rappresentazione (layout, progettazione e logica). E un sistema che permette in modo combinato la creazione, la gestione, la pubblicazione e la distribuzione delle informazioni. Un CMS garantisce la possibilità di creare o pre-elaborare delle informazioni già esistenti in modo adeguato e organizzato. All interno del sistema MHP i CMS sono responsabili della generazione e della pubblicazione dei contenuti delle applicazioni. 12

17 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA DOWNLOAD SERVER & FIRMWARE UPGRADE Questi componenti non fanno parte della specifiche del sistema MHP. Il server fornisce un sistema indispensabile per preparare le immagini binarie del software per ogni ricevitore MHP (es. Set-Top-Box, TV etc). I costruttori dei ricevitori che vorranno aggiornare il firmware dovranno fornirlo in formato binario alle emittenti televisive o operatori di rete i quali assegneranno delle larghezze di banda sufficienti per mandarlo in onda e quindi poter essere ricevuto dai dispositivi interessati. Ogni volta che un nuovo aggiornamento del firmware è in onda, il terminale MHP andrà in una speciale modalità di aggiornamento al fine di ricevere e installare il nuovo firmware MHP PKI (PUBLIC KEY INFRASTRUCTURE) L MHP-PKI si basa sulla integrità dei certificati che verificano l identità del soggetto che firma un applicazione nella struttura dei file. In principio esiste un certificato ad alto livello chiamato root certificate incorporato in qualsiasi ricevitore MHP dal costruttore. Questo viene utilizzato per autenticare un certificato al livello successivo nella gerarchia. Questo processo di autenticazione viene ripetuto in modo ricorsivo attraverso ogni livello della gerarchia, fino al certificato ultimo. In questo modo gli utenti sono sicuri che l applicazione non è stata modificata e che usi le risorse adeguate PSI/SI Le PSI/SI sono delle tabelle che non fanno parte dello standard MHP. Ad esse però va aggiunta la tabella AIT che, al contrario, è definita nelle specifiche MHP. Il video, l audio ed i dati sono tutti interlacciati (multiplexati) quando sono trasmessi in un singolo Transport Stream (TS). All interno degli standard di distribuzione DVB le informazioni vengono incapsulate in un unico pacchetto identificativo (PID). L insieme di tabelle PSI/SI sono usate come un indice dei contenuti interni al PID. A causa della natura della diffusione del TS, le tabelle sono ripetuti ad intervalli minimi predefiniti durante la trasmissione per garantire un tempo massimo di accesso. 13

18 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA Le PSI (Program Specific Information) sono parte dello standard MPEG-2 e definiscono 4 differenti tabelle che, escludendo la tabella privata, sono: PAT (Program Allocation Table), che può essere considerata come la radice della struttura gerarchica dei programmi televisivi contenuti nel TS; PMT (Program Map Table), definisce i singoli componenti dei programmi che costituiscono i servizi televisivi trasmessi nel TS, viene trasmessa una PMT per ogni servizio ed è indispensabile per la visualizzazione dell audio e del video; CAT (Conditional Acces Table), che indicano le proprietà dei programmi televisivi ad accesso condizionato (CA - Conditional Acces) interni al TS. All interno del TS le tabelle PAT e CAT sono in posizioni fisse mentre tutte le PMT sono in riferimento alla PAT. Le SI (Service Information) sono a supporto delle specifiche PSI e vengono definite dallo standard DVB-SI. Le SI sono costituite da una serie di tabelle, che possono essere obbligatorie o facoltative e che forniscono informazione aggiuntive sul TS, sui dati esterni e sulle proprietà del TS. La tabelle obbligatorie sono: NIT (Network Information Table), che contengono i parametri tecnici della frequenza del TS oltre al nome del broadcaster e ai dati identificativi del TS; SDT (Service Description Table), che danno delle informazioni extra sui servizi DVB paragonabili ai programmi MPEG-2 e altri parametri utili al ricevitore; EIT (Event Information Table), che segnala una lunga serie di altre informazioni che descrivono i programmi televisivi interni al TS; BAT (Bouquet Association Table), che elenca un raggruppamento logico dei servizi DVB; TOT (Time Offset Table), che danno il riferimento orario ai ricevitori; ST (Stuffing Table). 14

19 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA La parte delle specifiche MHP che si aggiunge alle tabelle PSI/SI è l AIT (Application Information Table). Essa segnala la presenza di un applicazione interattiva MHP all interno del TS e contiene le informazioni necessarie ai ricevitori per eseguirla ed avvisare gli utenti della sua presenza. I componenti principali di una AIT sono : Appication Name Application id Transport Stream id Original Network Service id Component tag Control code Service bound flag Visibility Main class Root directory Parameters # Comments must start with '#' sign # Empty lines are ignored # Parameter names must start at column 0. #The beggining of xlet description #app <Application ID> <Organisation ID> - MANDATORY app 0x10 0x29 #Name of application preceded by language code name ita "itv - ASUR7 MARCHE" #Parameter of service on which the application should be visible to application manager #tsid 0x7 #onid 0x46 #svid 0x2bd #Application control flag: 1=autostart 2=present 3=destroy 4=kill MANDATORY serve a dire alla xlet come deve essere caricata control 2 #service bound flag (0 or 1) MANDATORY bound 0 #other flags priority 137 visibility 3 #Basedir of application (must be relative to /home directory) MANDATORY basedir "/home" #Classpath extension classpath "" #Initial class name MANDATORY è importante scrivere la classe principale class "Main" Figura 5 - Esempio AIT 15

20 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA DSM-CC DSM-CC è l acronimo di Digitale Storage Media Command and Control ed è il formato di trasmissione delle applicazioni, dei dati e degli eventi nel TS. Il DSM-CC supporta due tipi diversi di carousel: Data Carousel, che permette al broadcaster di inserire ciclicamente dei dati digitali nel flusso MPEG-2 senza specificare di quali contenuti si tratti. Di solito viene utilizzato per semplici applicazioni ad esempio il Teletext. Object Carousel, questo estende le funzionalità del Data Carousel per consentire utilizzi di tipo avanzato, nei quali il ricevitore ha necessità di ottenere informazioni che descrivono i dati che riceve il flusso MPEG-2. Il tipico utilizzo è l inserimento delle applicazioni MHP-Java (Xlet) che consentono di avere l interattività durante la visione dei programmi televisivi, ad esempio i Quiz Show, permettendo ad un utente davanti alla TV di rispondere alle domande in modo concorde alla trasmissione CONDITONAL ACCESS SYSTEM (CAS) CAS non fa parte della specifiche del sistema MHP ed è opzionale se le trasmissioni televisive sono in chiaro. Il CAS è utilizzato per controllare l accesso al contenuto dei programmi televisivi, può essere presente anche su più piattaforme, tipico della Pay TV. Il CAS è genericamente uno standard proprietario ma l architettura di base è stessa NETWORK EQUIPMENT Network Equipment sono le apparecchiature di rete. Non appartengono agli standard MHP ma sono indispensabili per la messa in onda. Le apparecchiature sono principalmente costituite da un multiplexer e da degli adattatori per le diverse particolari reti ( terrestri, satellitari o cavo ). 16

21 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA MHP TERMINAL I ricevitori MHP ( o terminali MHP) sono quei dispositivi che durante la ricezione del segnale televisivo possono eseguire le applicazioni MHP visualizzandola all utente in modo adeguato e permettendogli di interagire con essa. I ricevitori MHP possono interagire con altri dispositivi, di solito le smart card attraverso gli slot di lettura, oppure con modem o schede di rete. È possibile utilizzare il ricevitore con il canale di ritorno per interagire con sistemi remoti, oppure interagire con sistemi di memorizzazione di massa, come gli Hard Disk, per memorizzare i programmi televisivi. Infine c è l OSD (On Scren Display) che di solito è un componente di base per ogni ricevitore MHP, cioè il foglio trasparente immaginario posto sulla parte superiore del video dove viene visualizzata la grafica delle applicazioni MHP, dove è possibile mescolare le immagini video per creare un sistema integrato usabile dall utente RETURN CHANNEL Il canale di ritorno è una componente importante dell architettura MHP perché permette la vera interattività dell intero sistema. Il canale di ritorno può essere classificato a seconda della tecnologia disponibile e come le applicazioni lo usano. La applicazioni usano in genere un canale di ritorno per avere flussi IP bidirezionali tra il ricevitore MHP e un server delle applicazioni remoto. Questi server hanno software specifiche per gli applicativi MHP di specifici operatori. Dal punto di vista tecnico i canali di ritorno possono essere suddivisi in canali via cavo e canali mobili e per ogni categoria ci sono connessioni alwayson o connessioni temporanee APPLICATION SPECIFIC BACKEND SERVER I server remoti per la applicazioni sono quelli meno standardizzati nella architettura. Questo perché sono utilizzati per scopi specifici da ogni operatore. I server quindi sono collegati con i ricevitori tramite il canale di ritorno o tramite il flusso di trasmissione. Siccome di solito i server hanno più potenza di calcolo, nella progettazione delle applicazioni si 17

22 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA cerca di effettuare le elaborazioni più complesse proprio del lato server. 1.3 SCENARIO DEGLI ATTORI DELLO STANDARD MHP La catena dei componenti MHP si può mettere in relazione con la catena degli attori dello scenario della Tv Digitale Terrestre con standard DVB-MHP secondo la Tabella1. Identificativo Componente Attore Coinvolto 1 Program Ceontent Playout Service Provider Broadcaster 2 MHP Application Authorin& Production Tools Application Developer Authoring Tool Vandor 3 Content Managemet System (CMS) Application Developer Service Provider 4 Download Server Broadcaster MHP Terminal Vendor 5 Piblic Key Inftrastructure MHP-PKI Application Developer Broadcaster MHP Terminal Vendor DVB Service SARL 6 PSI/SI Service Provider Broadcaster 7 DSM-CC Broadcaster MHP Palyout Vendor 8 Stream Events Broadcaster Service Provider Application Developer 9 Conditional Aces System (CAS) CAS Provider Broadcaster MHP Terminal Vendor 10 Network Equipment Broadcaster Network Operator 11 MHP Terminal MHP Terminal Vendor End-User 12 Return Channell ISP Backend Opeartor MHP Terminal Vandor 13 Application Specific Backend Server Application Developer Broadcaster Backend Operator 14 Billing System Application Developer Broadcaster Backend Operator Tabella 1 - Relazione Componenti-Attori Standard DVB-MHP 18

23 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA MHP AUTHORING TOOL VENDOR Sono le case di software e harware che forniscono gli strumenti per gli sviluppatori delle applicazioni MHP in modo da agevolare la crezione e lo sviluppo. Alcuni strumenti consentono l analisi e la sperimentazione della applicazioni e addirittura di firmarle per l autenticazione delle stesse MHP APPLICATION DEVELOPER Sono coloro che creano e forniscono il codice della applicazioni MHP interattive. Gli sviluppatori possono utilizzare Authoring System o possono scrivere direttamente il codice in Java attraverso i classici strumenti di sviluppo Java MHP SERVICE PROVIDER Attualmente è complicato definire il ruolo del fornitore di servizi MHP interattivi nella catena di produzione. Al momento sono le emittenti che sono spesso anche i fornitori di servizi. La descrizione più appropriata è probabilmente quella che vede i fornitori di servizi MHP manutentori dei servizi interattivi MHP. Essi possono programmare fare manutenzione dei servizi e offrire servizi di server remoti, oppure avere un sistema completo comprendente anche la fatturazione BROADCASTER La definizione di broadcaster non è semplice sopratutto perché il termine viene usato per identificare entità che coprono diversi ruoli nella catena. Alcuni, per esempio, sono al tempo stesso fornitore di contenuti, sviluppatore delle applicazioni, e fornitore dei programmi televisivi. In sostanza la parola broadcaster è usata come una metonimia per tutti questi ruoli ma spesso la definizione più comune è quella del responsabile dell atto di trasmissione del media, inclusa la gestione e la manutenzione del DSM-CC e del multiplexaggio. 19

24 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA NETWORK OPERATOR Il Network Operator si definisce come il gestore della rete e si occupa del multiplexer, del sistema per i diritti di accesso CAS, della modulazione del TS e invio del segnala RF (Radio Frequenza) in onda in una rete digitale terrestre. In alcuni casi anche l operatore di rete può offrire un sistema di piattaforme multiutente, dove le emittenti, gli operatori di T-commerce, i fornitori di informazioni o scommesse possono caricare le loro applicazioni nella rete MHP PLAYOUT VENDOR Sono coloro che forniscono i server di applicazioni, i generatori di PSI/SI, i DSM-CC Object Carousel ed anche gli strumenti di authoring e produzione delle applicazioni CAS Provider I CAS (Conditional Access System) Provider non sono specifici del sistema MHP ma forniscono il sistema di accesso condizionato (CAS) che viene utilizzato da parte di fornitori di servizi e broadcaster per la sicurezza nella Pay-TV e la tutela dei contenuti TV con tecnologie sicure, molto spesso utilizzando le smart card ISP Il ruolo degli Internet Service Provider (ISP) all interno della catena del sistema MHP è limitata solamente a fornire la connettività IP tra i ricevitori MHP e la rete IP. Esistono molti modelli di canali di ritorno che si differenziano per la tipologia di connessione (ponte, PPPoX, ecc.). Per alcuni sistemi, i ricevitori MHP necessitano di implementare un protocollo di corrispondenza per stabilire una connessione IP presente. L utilizzo di NAT (Network Access Traslation) e firewall potrebbe creare problemi nell utilizzo del canale di ritorno. 20

25 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA MHP BACKEND OPEARTOR E l operatore dei servizi remoti e si occupa di diversi aspetti del sistema. Esso ha bisogno di una connessione alla rete IP, essendo questo anche l unico modo, per ricevere le informazioni dai ricevitori. Di conseguenza ha si ha bisogno di interfacce con la rete IP che garantiscano la sicurezza e la scalabilità del sistema, specialmente per applicazioni che riguardano i servizi bancari o la trasmissione di dati personali. La corretta funzionalità dei server remoti è strettamente legata alle applicazioni e si può assumere che ci sia per ogni applicazione in rete un server che la interfaccia. A seconda delle funzionalità si ha il bisogno di avere un sistema di gestione dei contenuti (CMS) per avere un aggiornamento dinamico sul sistema di trasmissione. I server remoti potrebbero avere anche un sistema di fatturazione, di solito sistemi proprietari di chi offre il servizio, e quindi avere la necessità di sicurezza dei dati e corretti trasferimenti MHP TERMINAL VENDOR Sono i produttori e i fornitori dei ricevitori MHP cioè televisori, Set Top Box o PC compatibili con le specifiche DVB-MHP e che hanno superato i test per apportare il marchio MHP. I produttori possono usare il proprio stack software MHP o integrare gli stack software forniti da altri produttori DVB SERVICES SARL DVB Service SARL è una società a responsabilità limitata, disciplinata dal codice civile svizzero e dal suo statuto, e ha come scopo l obiettivo di fornire le certificazioni e tutti gli altri servizi connessi per le emittenti, i produttori e altri enti. La sede del DVB Services SARL è nell European Broadcasting Union, a Ginevra in Svizzera.Questa società ha un ruolo fondamentale nella sicurezza della applicazioni MHP interattive. 21

26 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA MHP CERTIFICATION AUTORITY Fornisce l infrastruttura a chiave pubblica per l MHP chiamata MHP- PKI. Questa infrastruttura è fondamentale per l autenticazione delle applicazioni e dei file che vengono trasmessi da un ricevitore. Questo processo di autenticazione è stato progettato per garantire che il codice dell applicazione non sia stato modificato da quello originariamente sviluppato e permette poi solo alle applicazioni autentiche di accedere ai dispositivi per il collegamento al canale di ritorno oppure solo ad un insieme di risorse limitate END USER L utente finale è il proprietario del ricevitore MHP installato nella propria abitazione, di solito in soggiorno. Occorre tener conto che i potenziali utenti della TV interattiva, non hanno necessariamente conoscenza del PC e che l interazione con il ricevitore è limitata dai pulsanti del telecomando e della bassa risoluzione delle TV. Il canale di ritorno può essere utilizzato solo se il ricevitore MHP è collegato alla rete. Dato che questo deve essere fatto dall utente finale non è garantito che venga eseguito e pertanto il corretto funzionamento del canale di ritorno non è certo. Occorre dire che l utente finale,quando utilizza i ricevitori MHP, si preoccupa della facilità d uso, del tempo di attesa, della reattività e della velocità del sistema, della qualità della grafica, dell audio e del video delle applicazioni interattive MHP SW STACK PROVIDER E il fornitore dello Stack software MHP con licenza DVB-MHP e può essere installato nei ricevitori dai produttori. 22

27 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA 1.4 ARCHITETTURA BASE DELLE APPLICAZIONI MHP Le applicazioni MHP possono essere classificate in due tipologie: DVB-J, cioè DVB-Java, che identificano le applicazioni scritte in Java usando le API MHP. DVB-HTML, applicazioni che dipendono da una implementazione di un browser conforme DVB-J Le applicazioni DVB-J sono scritte in Java utilizzando il set di API MHP e sono costituite da un insieme di classi che sono mandate in onda insieme alle trasmissioni televisive. Le applicazioni DVB-J sono chiamate Xlet ed hanno una struttura simile a quelle di un applet che si trova nelle pagine web. Come per le applet, le Xlet hanno bisogno di un Application Manager componente fondamentale del middleware dei ricevitori MHP che permette di avviare e fermare le Xlet. L approccio dello sviluppo delle applicazioni da parte dei programmatori è quello classico Java con JSDK (Java Software Development Kit) e l uso di strumenti come IDE. Per la compilazione delle classi delle applicazioni MHP occorrono della API Sutbs che sono delle classi vuote dalle vere istruzioni ma sufficienti per la compilazione. E importante rimuovere le API Java standard per evitare che gli oggetti che non fanno parte delle specifiche MHP non siano referenziate e quindi facciano bloccare l applicazione durante l esecuzione nell ambiante MHP LE XLET Come detto precedentemente una Xlet è una particolare applicazione Java concepita per essere scaricata ed eseguita su ricevitori MHP. Per sviluppare una Xlet occorre fondamentalmente conoscere due interfacce indispensabili : javax.tv.xlet.xlet che definisce i seguenti metodi: o public void initxlet(xletcontext ctx); 23

28 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA o public void startxlet(); o public void pausexlet(); o public void destroyxlet(boolean unconditional); javax.tv.xlet.xletcontext che definisce i seguenti metodi: o public void notifydestroyed(); o public void notifypaused(); o public java.lang.object getxletproperty(java.lang.string key); o public void resumerequest(); La classe principale di ogni Xlet deve sempre implementare l interfaccia java.tv.xlet.xlet per poter essere eseguita. Il ciclo di vita di una Xlet si definisce in quattro stati: Loaded, in questo stato la Xlet è stata creata ma non inizializzata, se durante questa fase viene rilevata un eccezione allora si passa direttamente nello stato Destroyed. Da notare che la Xlet si può trovare in questo stato solo una volta durante tutto il suo ciclo di vita. Paused, l Xlet è inizializzata e può trovarsi in questo stato sia dopo che il metodo initxlet(xletcontext) è ritornato con successo dallo stato Loaded oppure dopo che il metodo pausexlet() è ritornato con successo dallo stato Active. In entrambi i casi in questo stato la Xlet dovrebbe limitare al massimo l'utilizzo delle risorse condivise e soprattutto non impegnare la GUI televisiva. Active, in questo stato la Xlet è attiva e utilizza le risorse necessarie per fornire i suoi servizi, se dotata di GUI allora dovrebbe essere l'unica registrata per ricevere gli eventi del telecomando. 24

29 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA Destroyed, in questo stato la Xlet deve rilasciare tutte le risorse in uso per predisporsi alla terminazione. Figura 6 - Ciclo di vita Xlet Il classico esempio di Xlet è dato dalla semplice Xlet che scrive nello standard output Hello TV World!, il codice Figura 8 e il risultato Figura 7. Figura 7 - Output dell'applicazione dell'helloxlet 25

30 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA import javax.tv.xlet.xlet; import javax.tv.xlet.xletcontext; import javax.tv.xlet.xletstatechangeexception; public class HelloXlet implements Xlet{ // L'XletContext è un oggetto usato dalla Xlet per accedere // alle properties del suo environment e per comunicare con // l'application manager che glielo ha passato nella fase // di inizializzazione. private XletContext context; private boolean alreadyactive = false; // Il costruttore tipicamente viene lasciato vuoto visto che tutte le // inizializzazioni dovrebbero stare nel metodo initxlet() public HelloXlet () { // In questo metodo vengono fatte tutte le inizializzazioni, // se in questa fase qualcosa fallisse verrebbe lanciata un // eccezione. public void initxlet(xletcontext context) throws XletStateChangeException{ // si memorizza il context passato dall'application Manager this.context = context; System.out.println(this.getClass().getName()+" : Inizializzazione avvenuta!"); // Con questo metodo la Xlet è avviata e vengono richieste // le risorse necessarie come ad esempio lo schermo TV o // gli eventi del telecomando public void startxlet() throws XletStateChangeException{ // controlliamo se la Xlet era già stata messa in stato Active // precedentemente if (alreadyactive) { System.out.println(this.getClass().getName()+" : Hello Again TV World! "); else { System.out.println(this.getClass().getName()+" : Hello TV World"); alreadyactive = true; // Con questo metodo la Xlet viene messa in pausa e dovrebbe // rilasciare tutte le risorse utilizzate public void pausexlet(){ System.out.println(this.getClass().getName()+" : Xlet in pausa!"); // notifichiamo al Context l'avvenuta pausa della Xlet context.notifypaused(); // Con questo metodo la Xlet viene terminata, tramite il // parametro boolean la Xlet ha la facoltà di accettare // tale richiesta; nel caso non accettasse di // terminare dovrebbe lanciare un eccezione. public void destroyxlet(boolean unconditional) throws XletStateChangeException { if (unconditional) { System.out.println(this.getClass().getName()+" : la Xlet è stata terminata!"); else { System.out.println(this.getClass().getName()+ " : la Xlet ha accettato di essere terminata!"); // notifichiamo al Context l'avvenuta terminazione della Xlet context.notifydestroyed(); Figura 8 Esempio di Xlet - HelloXlet.java 26

31 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA DVB-HTML Il DVB-HTML per ora non è usato, in parte perché le specifiche sono state completate nelle versioni più recenti dello standard MHP, in parte perché molte emittenti, produttori di ricevitori e sviluppatori delle applicazioni lo trovano troppo complesso e di difficile attuazione. Le applicazioni DVB-HTML sono una serie di pagine HTML trasmesse come parte di una trasmissione. Le specifiche tecniche si basano sullo standard XHTML 1.1 includendo CSS 2.0, DOM 2.0 e ECMAScript. 1.5 IL DIGITALE TERRESTRE IN ITALIA Per capire le motivazioni che hanno indotto i legislatori ad introdurre in Italia il digitale terreste, fissando una data per lo switch-off delle trasmissioni televisive analogiche, si deve dare uno sguardo alla situazione che c era in passato. L apertura del mercato televisivo ai privati è avvenuta alla fine degli anni 70. La mancanza di una legge specifica che regolasse tale mercato ha portato di fatto ad avere un duopolio, in pratica due sole aziende si dividevano circa il 90% dell audience e di conseguenza anche degli introiti derivanti dalla pubblicità. Di fatto la prima legge che regolamentava il sistema radio-televisivo fu emanata nel 1990, ed in pratica non era in grado di modificare nell immediato la situazione che si era creata. C è da considerare anche un altro aspetto, non meno importante: la limitatezza delle frequenze disponibili. In queste condizioni sembra ovvio come il passaggio al digitale per le trasmissioni terrestri sia stata l unica strada percorribile. L introduzione del digitale terrestre ha prodotto una maggiore quantità di programmi televisivi, dovuto al fatto che se nell analogico su un certo spazio di frequenze poteva essere trasmesso un solo canale, con il digitale ne possono essere trasmessi almeno cinque eludendo così il limite fisico per l entrata sul mercato di nuovi operatori privati. Il proliferarsi di operatori ha la conseguenza di potenziare il sistema televisivo in termini di quantità e di conseguenza dovrebbe migliorare anche in termini di qualità dei programmi offerti.per impedire inoltre che venga a verificarsi di nuovo una 27

32 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA situazione di duopolio, la legge 66 del 20 marzo 2001 ha stabilito che gli operatori che possiedono più di una concessione televisiva devono mettere a disposizione il 40% della loro capacità trasmissiva a terzi editori. Un altra motivazione che ha spinto i legislatori a introdurre il digitale terrestre è la possibilità di trasmettere insieme ai programmi televisivi contenuti interattivi e multimediali. E possibile così rendere accessibili a tutti i servizi di pubblica utilità, che attualmente sono disponibili su internet (e quindi non accessibili alla totalità della popolazione). Altri vantaggi che possono essere individuati con il passaggio alle trasmissioni in digitale sono la regionalità e, come conseguenza della riduzione dei rumori di fondo e dell aumento della qualità delle immagini e dell audio, il minor inquinamento elettromagnetico, riducibile di circa il 25% rispetto alle trasmissioni analogiche. La qualità della trasmissione è appunto un altro dei punti forti del digitale terrestre, mezzo che rende possibile la realizzazione di servizi di broadcasting ad alta definizione. Tra la fine del 2003 e l inizio del 2004 le grandi aziende quali MEDIASET, RAI, DFREE e Telecom Italia Media, avviano i multiplex nazionali, dando così avvio alle trasmissioni in forma digitale. La situazione che si presenta nel 2005 è incoraggiante, i canali trasmessi in tutta Italia sono 27 di cui 9 in simulcast con l analogico, l avvio dei programmi a pagamento Pay Per View da parte di Mediaset e di Telecom Italia Media, produce un incremento non indifferente della vendita di decoder, predisposti con lettori di smart card e modem interno per l uso del canale di ritorno. Nel Marzo 2005 entrano in fase operativa 29 progetti co-finanziati dal CNIPA e dalla Fondazione Ugo Bordoni per realizzare servizi di T- Government. Il DGTVi firma con le regioni Valle d Aosta e Sardegna e con il ministero delle Comunicazioni un protocollo d intesa, che stabilisce che queste due regioni saranno le prime due aree in cui avverrà lo switch-off. Al termine del 2005 l attuale Ministro delle Comunicazioni sposta la data dello switch-off nazionale al 31 dicembre

33 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA Dopo un periodo di stallo per la Tv digitale alla fine del 2006 la Sardegna, con 4 famiglie su 5, viene definita la prima regione al Mondo per la diffusione TV digitale e, sempre in Sardegna, dal 1 Marzo 2007 alcuni canali televisivi cessano le trasmissioni in analogico e passano definitivamente al digitale. Sempre nel Marzo 2007 l Autorità per la garanzie nelle telecomunicazioni pubblica sulla Gazzetta Ufficiale una delibera che disciplina le modalità di cessione del 40% dalla capacità trasmissiva delle frequenze digitalizzate, regolandola sulla base di una procedura competitiva. Il 30 Novembre e il 1 Dicembre 2007 a Torino è stata svolta la 3 conferenza Nazionale sulla TV Digitale Terrestre dove viene confermato che in Europa tra il 2010 e 2012 si avrà la completa digitalizzazione della TV e che in realtà lo sviluppo di applicazioni interattive non ha portato ai risultati previsti, a fine 2007 gli individui in grado di ricevere la tv digitale terrestre sono più di 10 milioni con quasi 6 milioni di decoder DTT collegati a dei TV. Sempre durante la 3 Conferenza il DGTVi introduce la politica dei Bollini da applicare si ricevitori MHP. Il 9 maggio 2008 è stata pubblicata dal DGTVi una nuova versione del D-Book (DGTVi D-BOOK Ver.1.2 ) che definisce le caratteristiche che i ricevitori DTT integrati (idtv) e stand alone (STB) dovranno presentare per potere legittimamente utilizzare il "bollino DGTVi", la modifica apportata riguarda l abolizione dell obbligatorietà del canale di ritorno per i ricevitori. Il 10 settembre 2008, il Ministro dello Sviluppo Economico ha firmato un decreto che descrive il calendario per il passaggio definitivo dell Italia alla televisione digitale terrestre. Il decreto prevede una transizione al digitale progressiva delle varie regioni italiane divise in 16 aree a partire dal secondo semestre del 2009 fino al secondo semestre del Un programma che già nei prossimi due anni intende coinvolgere oltre il 70% della popolazione italiana (saranno circa 14 i milioni di cittadini coinvolti nel 2009 e 23 nel 2010 per un totale di circa 35 milioni) portando l Italia tra i Paesi più avanzati verso il traguardo europeo del La divisione in aree è descritta dalla tabella presente nell allegato 1 del decreto mentre la programmazione 29

34 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA dello switch off è data dalla tabella presente nell allegato 2 il tutto riassunto dalla Figura 8 e della Tabella 2. Figura 9 - Aree geografiche e numero di famiglie "all-digital" durante lo Switch-Off Italiano 2008 II semestre Area 16 Sardegna 2009 I semestre Area 2 Valle d Aosta II semestre Area 1 Piemonte occidentale Area 4 Trentino e Alto Adige (inclusa la provincia di Belluno) Area 12 Lazio Area 13 Campania 2010 I semestre Area 3 Piemonte Orientale e Lombardia(inclusa Piacenza) II semestre Area 5 Emilia Romagna* Area 6 Veneto*(incluse le province di Mantova e Pordenone) Area 7 Friuli Venezia Giulia Area 8 Liguria 2011 I semestre Area 10 Marche* Area 11 Abruzzo e Molise* (inclusa la provincia di Foggia) Area 14 Basilicata, Puglia (incluse Cosenza e Crotone) 2012 I semstre Area 9 Toscana e Umbria (incluse le La Spezia e Viterbo) II semestre Area 15 Sicilia e Calabria * Le Aree 5 e 6 e quelle 10 e 11 sono da considerarsi, rispettivamente, facenti parte di un processo congiunto. Tabella 2 - Calendario Switch-Off Italiano Il 30 Ottobre 2008 la Sardegna è diventata la più grande area in Europa completamente all-digital con oltre persone, più di famiglie e 59 canali digitali. Il 20 e 21 gennaio 2009 si è svolta a Roma la Quarta Conferenza Nazionale sulla TV digitale terrestre dal titolo Niente è come prima", organizzata da DGTVi. Da questa conferenza si evince il progresso positivo del passaggio al Digitale con l annuncio di sempre più ascoltatori, sempre più ricevitori venduti, l aumento dell offerta di canali digitali e la conferma del superamento del Satellitare come accesso alla tv digitale. E importante notare che nelle relazioni, specialmente 30

35 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA quelle riguardanti i componenti del DGTVi, si è incentivato lo sviluppo della TV interattiva nel senso completo. Alla fine del 2008 la vendite dei ricevitori supera i 12 milioni di pezzi di cui più di 7 milioni Set Top Box e circa 5 milioni ricevitori intergrati in apparecchiature ( es. Televisori), Figura 5. Figura 10 - Mercato Italiano Ricevitori MHP fine IL DGTVI ED I BOLLINI Il DGTVi è un associazione composta da operatori televisivi italiani e industrie di settore che ha come soci : Fondazione Ugo Bordoni RAI Mediaset Telecom Italia Media 31

36 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA FRT DFREE Aeranti-Corallo Maggiori produttori di set top box Figura 11 - Marchio DGTVi Lo scopo della società è quello di cooperare, con il Ministero delle Comunicazioni, l'autorità Garante delle Comunicazioni ed ogni altra autorità competente, alla promozione e agevolare la transizione dal sistema analogico a quello digitale. Alla fine del 2007, durante la 3 conferenza nazionale della TV Digitale Terrestre, il DGTVi, in collaborazione con i costruttori di decoder e televisori, ha introdotto, pubblicizzato in TV ed successivamente applicato alle apparecchiature altre due tipologie di bollini per garantire al consumatore finale delle specifiche caratteristiche tecniche qualitative : Bollino BLU: questo bollino sta ad indicare un decoder che permette di vedere i programmi in chiaro, i programmi a pagamento e soprattutto i servizi interattivi (compreso supporto T-Government). Il DGTVi dichiara che più dell 90% dei produttori dei decoder aderiscono all iniziativa e che anche i produttori di televisori a cavallo tra il 2008 ed il 2009 produrranno TV con bollino BLU. I produttori che hanno modelli di decoder con il Bollino Blu sono: ADB, AURIGA, COBRA, DIGIQUEST, FRACARRO,FUBA,GALAXY,IRRADIO, MEDIA SHOPPING, TELESYSTEM,TECHNOIT, UNITED, ZODIAC, HUMAX. 32

37 CAPITOLO 1 INTRODUZIONE ALLA TV DIGITALE TERRESTRE E LA SITUAZIONE ITALIANA Figura 12 - Bollino Blu DGTVi Bollino BIANCO: questo bollino invece sta a garantire un televisore che permette di vedere programmi digitali terrestri in chiaro e a pagamento, senza aver bisogno di alcun supporto aggiuntivo, ma non abilitato per l interattività remota. Anche in questo caso il DGTVi dichiara che i produttori di TV con bollino Bianco si impegneranno a passare al Bollino BLU a cavallo tra il 2008 e d il 2009.I Produttori di TV con modelli che hanno il Bollino BIANCO sono: Finlux, Imperial, Innohit, Graetz, LG Electronics, Loewe, Panasonic, Philips, Samsung, Sharp, Sony, Telefunken. Figura 13 - Bollino Bianco DGTVi I costruttori TV che presentano il bollino bianco si impegneranno entro il 2009 ad integrare in alcuni modelli anche l interattività, che al momento non è supportata, quindi a passare al bollino BLU. 33

38 CAPITOLO 2 LE SMART CARD, LE SMART CARD GOVERNTIVE E LE JAVA API SATSA 2.1 LE SMART CARD La smart card si può definire come la naturale evoluzione tecnologica delle carte a banda magnetica, ad esempio le classiche schede telefoniche per i telefoni pubblici, risolvendo le carenze che avevano. Una tipica smart card è facilmente riconoscibile perché è una tessera di plastica che con la presenza di 6-8 contatti elettrici ravvicinati a forma rettangolare sul lato superiore e all interno della plastica ci sono dei circuiti integrati come memorie, porte logiche e microprocessori. Figura 14 Una tipica Smart Card I vantaggi delle smart card possono essere vari come ad esempio, che: non vanno incontro al fenomeno della smagnetizzazione; possono memorizzare un maggior numero di informazioni; 34

39 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA si ha una agevolazione di interfacciamento con i dispositivi che ne fanno uso; presentano delle protezioni contro la lettura e scrittura non voluta ( ad esempio tramite PIN Personal Identification Number); possono essere multi applicazione. Al contrario l unico svantaggio che potrebbe essere considerato è il maggiore costo sia delle carte e dei lettori CLASSIFICAZIONE DELLE SMART CARD Figura 15 - Schema riassuntivo della classificazione della Smart Card Una prima classificazione delle smart card può essere definita dalle smart card a contatto (contact-card) e dalle smart card senza contatto (contactless-card). Le smart card a contatto vanno inserite all interno di un apposito dispositivo di lettura che comunica con esse tramite il contatto elettrico dei pin che si trovano su di esse. Naturalmente, le contact-card vanno incontro ad una maggiore usura soprattutto se devono essere inserite/disinserite molte volte all'interno di un lettore. Inoltre sono più scomode da usare poiché l'utente deve impiegare del tempo per inserire e disinserire la carta dal dispositivo. 35

40 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Le contactless-card, invece, hanno un antenna integrata che permette, quando viene avvicinata ad una certa distanza dal dispositivo di lettura, sia l alimentazione dei circuiti integrati interni, sia la comunicazione wireless dei dati. Occorre notare che si possono avere smart card ibride cioè sia contact che contactless in modo da avere entrambe le tecnologie. Oltre alla classificazione per modalità di trasmissione dati è possibile classificare le smart card in smart card a memoria (memory-card) e smart card a microprocessore (chip-card). Le smart card a memoria contengono internamente delle semplici memorie a cui si può accedere in lettura/scrittura mediante i contatti presenti sulla carta. Nelle memory-card, in cui è possibile accedere al contenuto senza protezione, sono chiamate a memoria libera (free memory card) il principale problema delle free-memory-card è che se una tessera di questo tipo viene rubata o persa, può essere usata senza difficoltà da un'altra persona, anche non autorizzata. Esiste poi la memory-card a memoria protetta che integra non solo una zona di memoria (generalmente EEPROM) ma anche della logica aggiuntiva che permette la protezione del contenuto agli utenti non accreditati. lo scopo viene raggiunto memorizzando all'interno della carta, in una zona di memoria diversa da quella utilizzata per i dati, un PIN non leggibile dall'esterno. Per poter leggere e/o scrivere il contenuto della memoria dati sarà necessario presentare correttamente il PIN alla carta che, solo dopo averlo confrontato con quello memorizzato al suo interno, permette il libero accesso al contenuto della memoria. Figura 16 - Smart Card Memoria (memory-card) 36

41 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Infine le smart card a microprocessore, o chip-card, hanno dei sistemi elettronici integrati nella tessera plastificata e possono essere anche molto complessi. Normalmente all'interno si trova una zona di memoria non volatile per la memorizzazione dei dati anche a carta scollegata (EEPROM e/o Flash), una memoria volatile per l'elaborazione dei dati durante l'uso (RAM), un microprocessore più o meno complesso che gestisce sia il protocollo di comunicazione con l'esterno, sia l'elaborazione dei dati. La presenza di una piccola capacità di elaborazione assicura un livello di sicurezza impossibile da raggiungere con le normali smart card a memoria. Spesso vengono implementati degli algoritmi di crittografia complessi, che aumentano il grado di sicurezza di transazioni commerciali, permettendo al sistema di riconoscere un determinato utente con un alto grado di affidabilità. Figura 17 - Smart Card a microprocessore (Chip-Card) LO STANDARD ISO\EIC 7816 Lo standard internazionale relativo alle carte d identificazione e più nello specifico alle smart card è l ISO/IEC 7816 gestito dalla ISO (International Organization for Standardization) e dalla IEC (International Electrotechnical Commission). Lo standard ISO/IEC 7816 è suddiviso nelle seguenti sezioni: : caratteristiche elettrico-fisiche; : dimensione e posizione dei contatti; : segnali elettrici e protocolli di trasmissione; : comandi e intercambiabilità; : procedure di registrazione e sistemi di numerazione per identificativi delle applicazioni; 37

42 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA : definizione dei dati : comandi per le query strutturate : comandi relativi alla sicurezza : comandi addizionali e attributi di sicurezza : segnali elettroni e Answer to Reset metodi di verifica personale attraverso metodi biometrici Di questi standard solo i primi 3/4 vengono in realtà seguiti da tutti i produttori di smart card, per questo motivo non è affatto raro imbattersi in schede che implementano delle funzioni non standard e che quindi creano non pochi problemi di interoperabilità tra le varie smart card ISO/IEC , CARATTERISTICHE FISICHE ED ELETTRICHE Nella parte 1 con sono le specifiche elletrico-fisiche: Dimensioni del supporto di plastica: o ID-1 : 85.6 x 54 x 0,76 mm o ID-00 : 66 x 33 x 0.76 mm o ID-000: 25 x 15 x 0,76 mm con un taglio 3x3 mm Figura 18 - Formati delle Smart Card temperatura di lavoro : 0 C - 50 C; resistenza meccanica, la contattiera deve rimanere inalterata se sottoposta ad una pressione pari a quella esercitata da una sfera 38

43 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA d acciaio di diametro 1mm alla qual è applicata una forza di 1.5 Newton; resistenza elettrica, la resistenza misurata tra due qualsiasi contatti deve essere minore di 0.5 Ω se sottoposta ad una corrente tra 50 µa e 300 µa; resistenza ai raggi X, la carta non deve mostrare malfunzionamenti se esposta da entrambi i lati a una dose pari a 0,1 Gy di radiazione X con energia media compresa tra 70 e 140 KeV. Nella parte 2 ci sono le specifiche che descrivono la posizione e la dimensione della contattiera e le funzioni associate ai contatti (questo si può vedere nella Figura 19 e nella Tabella 3). Figura 19 - Contattiera tipica della Smart Card 39

44 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Contatto Descrizione VCC Alimentazione RST Segnale di Reset CLK Segnale di Clock GND Massa VPP Alimentazione Aggiuntiva I/O Canale di Input/Output AUX1 Contatto Supplementari 1 AUX2 Contatto supplementare 2 Tabella 3 - Descrizione de segnali presenti sulla Contattiera Nella parte 3 si definiscono i segnali elettrici e i protocolli di trasmissione nelle smart card. In particolare vengono date indicazioni sui livelli delle tensioni e sulle correnti riguardanti tutti i segnali già descritti, nonché sui tempi di salita e discesa e sulle capacità parassite. Lo standard ISO/IEC e i suoi aggiornamenti definiscono no tre classi di funzionamento in base al valore che la tensione Vcc assume: classe A, Vcc assume il valore di 5 V ± 10%; classe B, Vcc assume il valore di 3 V ± 10%; classe C, Vcc è di 1.8 V ± 10 %. Il contatto CLK riceve il segnale di clock, i valori ammessi sono da 1 MHz a 5 MHz. Figura 20 - Posizione contattiera sulla Smart Card formato ID-1 40

45 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA ATR ANSWER TO RESET Tutti i byte trasmessi dalla smart card in risposta al reset formano l ATR (Answer To Reset). Esso è descritto dallo standard ISO\IEC ed è formato da un byte di sincronismo TS seguito da non più di 32 byte, come si può osservare schematicamente nella Figura 21. Figura 21 - Formato Answer To Reset (ATR) Il primo byte TS è detto byte di sincronismo ed è fondamentale per una corretta comunicazione tra lettore e smart card. Il byte di sincronismo è seguito dal byte obbligatorio T0, denominato byte di formato. Esso indica la composizione dei successivi byte dell ATR. Il nibble (4 bit) meno significativo di T0 indica il numero K, compreso tra 0 e 15, dei byte storici T1, T2 TK. Ogni bit del nibble più significativo di T0 indica la presenza o meno dei byte di interfaccia TA1, TB1, TC1, TD1, trasmessi subito dopo T0: se un bit è 1, il byte relativo è presente. Il nibble più significativo di TDi indica la presenza o meno del successivo quartetto di byte TAi+1, TBi+1, TCi+1, TDi+1, così come il nibble più significativo di T0 indicava la presenza o meno del quartetto di byte TA1, TB1, TC1 e TD1. Importante è il byte TD1 che indica, oltre alla presenza dei byte TA2, TB2, TC2 e TD2 nel nibble più significativo, il protocollo utilizzato dalla smart card nel nibble meno significativo. Tale numero, indicato comunemente con il simbolo T, può avere diversi valori, di solito 0 o 1. Successivamente ai byte di interfaccia sono trasmessi i byte storici. Il numero dei byte storici è variabile, ma è specificato nel byte T0, come visto precedentemente. Il significato dei byte storici non è indicato nello standard cha lascia completa libertà al costruttore della carta sulla codifica di questi byte. L ultimo byte TCK è utilizzato come controllo di integrità dell intero 41

46 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA ATR. Viene calcolato in modo tale che il risultato dell operazione booleana XOR di tutti i byte dell ATR, compreso il TCK, sia zero PROTOCOLLI DI TRASMISSIONE Per la comunicazione dei comandi tra smart card e terminale di lettura occorre un protocollo di regolamentazione. Lo standard ISO/EIC definisce la possibilità di avere 15 protocolli ma soltanto 2 sono i più utilizzati. Il modello è quello del classico master-slave dove il master viene associato al lettore mentre lo slave alla smart card. In sostanza la comunicazione consiste nel lettore che invia i comandi e la smart card elabora ed invia la risposta al lettore. I protocolli sono chiamati con il semplice nome T = x dove T sta per Transmission e x è il numero ti protocollo. Protocollo Descrizione T=0 asincrono, half-duplex, byte oriented, T=1 asincrono, half-duplex, block oriented T=2 asincrono, full-duplex, block oriented T=3 full duplex, non specificato T=4 asincrono, half-duplex,byte oriented, estensione del protocollo T=0 T=5 T=13 Riservati per sviluppi futuri T=14 per usi specifici nazionali Tabella 4 - Protocolli dello Standard ISO/EIC IL PROTOCOLLO T=0 Il protocollo più semplice e maggiormente utilizzato è quello denominato T=0. È un protocollo half-duplex asincrono orientato al byte molto simile allo standard RS232 utilizzato praticamente su tutti i PC. Esso è orientato al byte poiché il trasmettitore (la smart card oppure il lettore) invia un singolo byte al ricevitore incapsulato in un opportuno frame per il trasporto. Il protocollo T=0 è di tipo half-duplex, cioè a domanda e risposta, poiché il canale di comunicazione è formato da un unico segnale, ovvero il contatto I/O della smart card. Per questo motivo è possibile trasmettere dati dalla smart card verso il lettore oppure viceversa, ma mai contemporaneamente. Naturalmente questo comporta che il pin di I/O sia bidirezionale. Questa 42

47 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA caratteristica differenzia il protocollo T=0 dall RS232 in quanto, in quest ultima, ci sono due fili che possono ospitare contemporaneamente trasferimenti di dati in entrambe le direzioni (fullduplex). Così come l RS232, il protocollo T=0 è asincrono: il trasmettitore può iniziare la trasmissione di un byte in qualsiasi momento senza dover sincronizzare questo evento con un segnale di clock. È per questo che le smart card a microprocessore vengono anche chiamate comunemente smart card asincrone. Per evitare collisioni dovute alla trasmissione contemporanea dei due nodi, come regola generale, è sempre il lettore che inizia la trasmissione di un byte. Quindi la smart card non può mai decidere di trasferire dati al lettore autonomamente. La forma d onda del segnale I/O relativa alla trasmissione di un byte dalla smart card al dispositivo di lettura o viceversa è illustrata dalla Figura 22. Figura 22 - Segnale I/O alla trasmissione di un byte nel protocollo T=0 Normalmente, quando non c è alcuna trasmissione, lo stato della linea di I/O è a livello alto (stato Z). L invio di un byte inizia sempre con un bit di start S generato dal trasmettitore imponendo un livello basso (stato A) per un tempo di bit, definito ETU (Elementary Time Unit, il quale dipende dalla frequenza di clock). Successivamente vengono trasmessi gli 8 bit che formano il byte (ba, bb,bc, bd, be, bf, bg, bh), seguiti dal bit di parità P, ognuno dei quali dura sempre un ETU. Il bit di parità viene calcolato in modo tale che il numero di bit ad 1 sia pari. Dopo il bit di parità, il trasmettitore mette il bit di I/O in ricezione, rilasciando la linea nuovamente nello stato Z. Nessun ulteriore invio di dati può avvenire per un tempo di guardia (guard time) pari almeno a 2 ETU. Il controllo d errore sul bit di parità è obbligatorio per le smart card, mentre il lettore può anche ignorare tale bit. 43

48 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA IL PROTOCOLLO T=1 Il protocollo di trasmissione per la smart card T=1 è un protocollo orientato ai blocchi di byte che implementa un half-duplex asincrono, come il protocollo T=0. Questo significa che il blocco è la più piccola unità di dati che può essere trasmessa tra la carta e il lettore. I blocchi che sono trasmessi sono usati principalmente per due scopi, uno per la trasmissione dei dati, mentre l altro per l invio di informazioni di controllo o per la rivelazione degli errori. Il blocco è formato da tre campi: un campo iniziale; un campo informazioni; un campo finale. Il campo iniziale e finale sono obbligatori mentre quello delle informazioni è opzionale e può contenere di solito un comando APDU o una risposta alla APDU. I blocchi si dividono in tre tipologie differenti: I-Block, usato per lo scambio dei dati; R-Block, sono blocchi si servizio che segnalano la ricezione o non ricezione dei blocchi; S-Block, usati per informazioni di controllo relative al protocollo. campo iniziale NAD PCB LEN APDU campo informazioni campo finale EDC 1 byte 1 byte 1 byte byte 1 2 byte Tabella 5 - Struttuta di un blocco di trasmissione T=1 Più precisamente si possono descrivere le varie componenti del blocco nel seguente modo: NAD (Node Address) contiene gli indirizzi logici di sorgente e destinazione per il blocco, inoltre serve per controllare la tensione Vpp. 44

49 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA PCB (Protocol Control Byte) codifica varie informazioni sulla gestione del protocollo. LEN (Length) contiene le dimensioni in byte del campo informazioni. EDC (Error Detection Code) contiene un codice di correzione degli errori calcolato sui byte dei campi precedenti, il calcolo può impiegare sia un controllo di ridondanza longitudinale (LRC) sia un controllo di ridondanza ciclica (CRC), il metodo utilizzato è specificato nell ATR. APDU (Application Data Unit) contiene i comandi e le risposte della smart card, è presente sempre negli I-Block. Il protocollo T=1 prevede inoltre uno speciale segnale detto WTX (Waiting Time extension) che consente al microchip di richiedere al trasmettitore più tempo per terminare le elaborazioni del comando ricevuto LO STANDARD ISO/EIC , IL FILE SYSTEM Nella quarta parte dello standard vengono definite le strutture logiche e il formato dei dati memorizzati all interno della smart card. Il file system della EEPROM è di tipo gerarchico molto simile a quello che si ha nei comuni hard disk dei PC. La moderna gestione dei file per i sistemi di smart card ha una struttura object-oriented. Ciò significa che tutte le informazioni del file sono memorizzate all interno del file stesso. Ulteriore conseguenza di questo principio è che un file deve essere sempre selezionato prima di poter eseguire ogni azione. Ogni file è quindi diviso in 2 parti. La prima parte chiamata File Header dove vengono memorizzate le informazioni sul layout, la struttura del file e i permessi di accesso. La seconda parte è il File Body dove vengono messe le vere informazioni del file. Le due parti sono legate tramite un puntatore. 45

50 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Figura 23 - Struttura interna di un File I file delle smart card si possono classificare in due macrotipologie : file di Directory file per i Dati, cioè gli EF (Elementary File) I file di Directory si dividono in : MF (Master File), cioè la radice che contiene tutte le directory e i file dell intero file system ed è presente in tutte le smart card. DF ( Dedicated File), sono le directory e possono ono contenere dei file EF o altri DF formando strutture complesse del file system. Gli EF (Elementary File) sono i file che contengono le informazioni per le applicazioni e possono essere sere posti sotto un MF o sotto un DF. L utilizzo degli EF ha il vantaggio di avere le informazioni memorizzate in un una struttura tura ottimizzata e minima, cosa che non n avviene nei file dei PC perché la struttura interna dei file è definita dall applicativo che li gestisce. Una tipica organizzazione del file system è data dalle Figura

51 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Figura 24 - Organizzazione tipica del File System di una Smart Card Esistono stono poi degli oggetti speciali che ogni DF può ospitare : SDO (Security Data Object), attraverso cui è possibile memorizzare oggetti quali PIN, chiavi crittografiche e così via. SEO (Security Environment Object), che sono dei contenitori logici di meccanismi di sicurezza che possono essere usati nei comandi crittografici. Gli EF e i DF possono essere identificati mediante dei FID, cioè due byte che devono essere associati in modo univoco ad ogni file presente sulla smart card. Ci sono dei FID riservati a particolari directory od usi dallo standard, la Tabella 6 ne descrive alcuni. 47

52 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA FID Riservato Per 2F00 l EF DIR che è il file usato per memorizzare le AID e il path name delle applicazioni associate 2F01 l EF ATR che contiene le estensione all ATR 3F00 il Master File 3FFF la selezione dei file usando il path name FFFF usi futuri Tabella 6 - FID Particolari Un altro modo per identificare gli EF è lo short ID, un numero compreso tra 1 e 32, quindi rappresentabile con 5 bit. Lo short ID è opzionale, quindi non necessariamente deve essere assegnato ad un EF. I DF possono essere anche identificati tramite il DF-name della lunghezza variabile da 1 a 16 byte. I DF-name sono normalmente usati insieme agli Application Identifier (AID), come definito nello standard ISO/IEC Ad ogni file presente nella EEPROM della smart card, siano essi EF o DF, è possibile assegnare un insieme di permessi d accesso. Tali condizioni sono chiamate Access Condition. Un Access Condition è legata ad un Security Data Object e può essere vista come un flag, chiamato Access Right che viene abilitato se il comando associato a tale SDO, ad esempio un Pin associato al comando di verifica, viene eseguito con successo. Ciascuna smart card definisce per ciascuna tipologia di oggetto il proprio insieme di Access Condition. A ciascun oggetto creato nella EEPROM della smart card vengono assegnati i valori per le Access Condition fissate, ossia viene associato a ciascuna AC l ID di un SDO la cui verifica positiva abilita all esecuzione dell operazione relativa all AC LO STANDARD ISO/IEC , LE APDU APDU è l acronimo di Applicaiton Protocol Data Unit, in poche parole si riassume le APDU come una sorta di contenitore che incapsula un comando per la smart card o una risposta da essa. Le APDU vengono inviate attraverso i protocolli di comunicazione in modo trasparente, 48

53 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA cioè il protocollo di comunicazione non effettua nessuna elaborazione sulle APDU rendendole cosi indipendenti dal tipo di protocollo. Le APDU si possono suddividere in Comandi e Risposte. Un comando APDU è suddiviso in un intestazione e un corpo ed è descritto dalla Tabella 7. Intestazione Corpo CLA INS P1 P2 Campo Lc Campo DATA Campo Le Tabella 7 - Struttura del comando APDU L intestazione è composta da 4 campi obbligatori lunghi ognuno un byte: CLA (Class), indica il byte di classe di appartenenza del comando; INS (Instruction), il byte di istruzione indica l identificativo dell istruzione all interno della classe di appartenenza; P1 (Parameter 1), byte del primo parametro aggiuntivo dell istruzione; P2 (Parameter 2), byte del secondo parametro aggiuntivo dell istruzione; Il Corpo è composto da 3 campi non obbligatori variabile: di lunghezza Campo Lc, riporta la lunghezza del campo DATA; Campo DATA, contiene i dati da elaborare mediante il comando Campo Le, riporta la lunghezza attesa della risposta inviata dal microchip. 49

54 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Occorre specificare 4 tipologie di comando APDU (Figura 25) che si differenziano per la presenza o meno dei campi del Corpo, essendo questi non obbligatori. Figura 25 - Le 4 tipologie di comando APDU Anche la risposta APDU può essere vista come composta da due parti. La prima è il Corpo che è opzionale e contiene i dati. La sua lunghezza è data dal campo Le come visto in precedenza. La seconda parte è il campo Trailer che è formato da due byte chiamati SW1 e SW2 che corrispondono a e 61 XX se l istruzione è stata eseguita correttamente, oppure ad un codice errore descritto dalla Tabella 9. Corpo Trailer Campo DATA SW1 SW2 Tabella 8 - Struttura della reisposte APDU Anche le riposte APDU sono di 2 tipologie a causa della non obbligatorietà del campo DATA. 50

55 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Figura 26 - Tipologie delle Risposte APDU Codici di warning 0x62 0x00 Warning generico 0x62 0x81 Dati non validi o corrotti 0x62 0x82 EOF raggiunto 0x62 0x83 Il file selezionato è stato invalidato 0x62 0x84 File Control Information (FCI) non valide 0x63 0x00 Errore generico 0x63 0x81 File pieno 0x63 0xCX Il significato dell errore dipende dal comando Errori di esecuzione 0x64 0x00 Errore di esecuzione del comando 0x65 0x00 Errore generico 0x65 0x81 Errore di memorizzazione 0x66 0xXX Riservate per future estensioni Errori di verifica 0x67 0x00 Lunghezza del comando non valida 0x68 0x00 Codice CLA non supportato 0x68 0x81 Canale non supportato 0x68 0x83 Modalità Secure Messaging non supportata 0x69 0x00 Comando non consentito 0x69 0x81 Il comando non è compatibile con la struttura del file 0x69 0x82 Accesso non consentito 0x69 0x83 Security Object bloccato 0x69 0x84 I dati del comando non sono validi 0x69 0x85 Condizioni d uso non soddisfatte 0x69 0x86 Comando non valido, nessun file selezionato 0x69 0x87 Oggetto Secure Messaging non trovato 0x69 0x88 Oggetto Secure Messaging non valido 0x6A 0x00 Campo P1 o P2 non corretto 0x6A 0x80 Parametri nel campo dati non corretti 0x6A 0x81 Funzione non supportata 51

56 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA 0x6A 0x82 File non trovato 0x6A 0x83 Record non trovato 0x6A 0x84 Memoria disponibile non sufficenete 0x6A 0x85 Campo LC inconsistente con la struttura TLV 0x6A 0x86 P1 e P2 non validi 0x6A 0x87 Campo LC inconsistente con i campi P1 e P2 0x6A 0x88 Oggetto non trovato 0x6B 0x00 Campi P1 e P2 non corretti 0x6C 0xXX Campo LE non corretto 0x6D 0x00 Campo INS non valido 0x6E 0x00 Campo CLA non valido 0x6F 0x00 Errore interno Tabella 9 - Codici delle Risposte APDU LO STANDARD ISO/IEC , SECURE MESSAGING (SM) I dati che transitano sul canale di I/O della smart card potrebbero in qualche modo essere intercettati. Per evitare che ciò si verifichi, nel caso di transito di dati sensibili si utilizzano uno o più meccanismi di sicurezza che adottano algoritmi crittografici e chiavi simmetriche che consentono di stabilire un canale cifrato fra applicazione e smartcard. L obiettivo del Secure Messaging è quindi quello di proteggere parte del messaggio da e per la smart card, per accertare l autenticità e garantire la riservatezza dei dati. A questo scopo si può cifrare solo il campo dati (SM_ENC), garantendo così la riservatezza dei dati, oppure si può firmare sia l intestazione che il campo dati dell APDU (SM_SIG) utilizzando un controllo crittografico in modo da garantire sia l autenticità che l integrità dei dati, o, ancora meglio, si può utilizzare una combinazione delle due. Nei messaggi che implicano l utilizzo dei meccanismi di SM basati su crittografia, il campo di dati soddisferà le regole di codifica ASN.1 BER-TLV. Gli oggetti Dato creati secondo questa codifica sono formati da tre campi: il campo Tag formato di 1-2 byte che descrive il la forma dell oggetto; il campo Length di 1-3 byte che descrive la sua lunghezza; il campo Value di n byte che contiene i dati. 52

57 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA I valori possibili per i byte del campo tag per il SM sono indicati dallo standard ISO/IEC e variano da 80 a BF (cioè per il secondo bit più significativo è sempre 0). Per ottenere un comando in SM_SIG partendo da un comando in chiaro, per prima cosa il campo dati deve essere convertito in formato TLV facendo il padding fino ad un multiplo intero di 8 byte. Dopo di che si fa il controllo crittografico del comando che viene aggiunto come ultimo campo. Per ottenere invece un comando in SM_ENC si converte sempre il campo dati in formato TLV facendo il padding ad un multiplo di 8 byte, dopo di che lo si cripta,e si prende il risultato dell operazione come campo dati (sempre in formato TLV) per la APDU. Volendo utilizzare la combinazione delle due si effettua prima l operazione di SM_SIG e poi con la APDU risultante si effettua l operazione di SM_ENC. 2.2 LE SMART CARD GOVERNATIVE La televisione è uno strumento ideale per la trasmissione di informazioni concise e complete. La pubblica amministrazione sta cercando di offrire i suoi servizi anche on-line e un possibile veicolo potrebbe essere l uso della nuova tecnologia digitale per la televisione, al fine di offrire servizi di T-Government o T-Healt, nel caso della sanità. I problemi dei servizi on-line sono le modalità di accesso sicuro, la facilità d uso e il grado di utilizzo nel modo più generale possibile. Gli strumenti di identificazione digitale che si possono utilizzare sono per ora la Carta d Identità Elettronica (CIE), emessa dai Comuni in sostituzione della carta d identità tradizionale, la Carta Nazionale dei Servizi (CNS) e le Carte Ragionali dei Servizi (CRS), che sono delle CNS emanate da enti regionali. La CNS e CRS sono progettate coerentemente alla CIE e al giorno d oggi rappresenta il punto di riferimento per l emissione di carte multiservizi. Mediante la CNS e la CIE è possibile ottenere servizi sanitari, fiscali, usufruire di sistemi di pagamento bancari e postali e utilizzare la firma digitale. Le smart card governative appena elencate possono essere quindi il veicolo ottimale per l autenticazione dell utente e per la comunicazione sicura 53

58 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA attraverso so la tv digitale, soprattutto perché si prevede che i ricevitori, ricevitori sia che essi siano Set Top Box o Televisori, abbiano un lettore di smart card o almeno un interfaccia comune dove inserire inserire delle CAM. I lettori di smart card sono, per specifiche tecniche obbligatorie, in grado di supportare gli standard ISO/EIC L unico ostacolo, ostacolo che l argomento della tesi cerca di risolvere, è dato dagli gli applicativi per la gestione e interfacciamento interfaccia della smart card. Occorre ccorre quindi tenere in considerazione queste problematiche inerenti agli standard L A CARTA DI I DENTITÀ E LETTRONICA La CIE (Carta di Identità Elettronica) è la naturale evoluzione della de carta di identità cartacea in una versione versione elettronica e digitale. Figura 27 - CIE, Carta di Identità Elettronica Essa si basa suoi principi sulla crittografia crittografia asimmetrica in cui occorre una coppia di chiavi una pubblica ed una privata. La chiave privata è di tipo RSA 1024 ed è presente nella nella carta come oggetto di sicurezza, quindi risulta fortemente protetto dalla lettura. La chiave pubblica invece è contenuta in un certificato X.509 che è trattato come un normale file binario nel file system della carta. Il certificato ificato della CIE è emesso emess dal Ministero inistero dell Interno che gestisce anche il server dove vengono pubblicati tutti i certificati pubblici emessi. I certificati emessi sono firmati firmati con la chiave privata del Ministero dell Interno nterno e può essere convalidato usando la sua chiave pubblica,, che naturalmente è pubblicata in forma di certificato. Il 54

59 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA campo soggetto del certificato normalmente specifica i dati del proprietario della carta, quali nome, cognome, codice fiscale ecc. Per la CIE il Ministero ha deciso, per motivi di privacy, che il codice fiscale non debba essere presente nel certificato; al suo posto infatti è stato inserito il numero carta. Il codice fiscale insieme al nome, al cognome, all indirizzo e a tutti gli elementi per l identificazione a vista appaiono stampati sulla parte anteriore della carta, oltre ad essere contenuti nel file Dati_Personali del file system della carta ed anche esso certificato dall ente emettitore LA CARTA NAZIONALE DEI SERVIZI La carta nazionale dei servizi è una smart card che dal punto di vista elettronico, dei comandi APDU (sistema operativo) e del file system, è del tutto simile alla CIE, però mentre questa ultima contiene gli elementi di sicurezza necessari per il riconoscimento a vista del titolare. Figura 28 - CNS, Carta Nazionale dei Servizi emanata da enti diversi La CNS non deve contenere dati utilizzabili in alcun modo per il riconoscimento a vista del titolare, quindi il processo per il rilascio della CNS è più snello e flessibile. La CNS ha l obiettivo di consentire la fruizione dei servizi previsti per la CIE anche agli utenti che ancora non dispongono del nuovo strumento. Essa può essere emessa, da tutte le pubbliche amministrazioni, però solo se l utente che la richiede non è già in possesso di un altra CNS o una CIE. La pubblica amministrazione che emette la CNS viene chiamata ente emettitore ed è responsabile: 55

60 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA della verifica della correttezza del codice fiscale e dei dati identificativi che sono memorizzati nella carta e nel certificato di autenticazione; della sicurezza delle fasi di produzione, inizializzazione, distribuzione ed aggiornamento/ritiro della carta; dell invio dei dati identificativi della persona, del codice numerico identificativo della carta, della data del rilascio e della data di scadenza al Ministero dell interno, Centro Nazionale Servizi Demografici, per l aggiornamento dell Indice nazionale delle anagrafi. Oltre all ente emettitore al processo d emissione della carta nazionale dei servizi partecipano il produttore, cioè l azienda che fornisce le smart card con i requisiti richiesti, e il certificatore che deve garantire la certificazione delle informazioni per l autenticazione e per la verifica delle firme elettroniche. Nel documento Regole tecniche e di sicurezza relative alle tecnologie e ai materiali utilizzati per la produzione della Carta nazionale dei servizi è espressamente richiesto che sulla smart card sia stampata la dicitura Carta Nazionale dei Servizi e inoltre consigliato che siano presenti il nome e logo dell ente pubblico che l ha emessa, ma non è richiesto che l Ente emettitore effettui in proprio le attività necessarie alla personalizzazione, al rilascio ed alla successiva gestione della carta, esso comunque, anche nel caso queste attività vengano delegate ad altre strutture, ne mantiene le responsabilità ed è il referente diretto nei confronti del Ministero dell Interno - Centro Nazionale Servizi Demografici. Le regole tecniche contengono le indicazioni sulle caratteristiche informatiche e sulle modalità di gestione del ciclo di vita della CNS. In particolare la CNS ha tre funzionalità principali : è uno strumento d identificazione in rete; è predisposta per ospitare il servizio di firma digitale; è predisposta per essere utilizzata come carta sanitaria ; le ultime due funzionalità possono non essere attive al momento dell emissione della carta, in aggiunta è possibile installare sulla CNS i 56

61 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA così detti servizi aggiuntivi che possono andare dalla rivelazione presenza aziendale alla raccolta di punti fedeltà. E da chiarire che i dati personali presenti nella carta devono essere utilizzati esclusivamente per la finalità di identificare in rete il titolare della carta nazionale dei servizi e per verificare la sua legittimazione al servizio, quindi non sono consentite applicazioni che leggono i dati personali sulla carta e quindi li trasmettono via rete allorché sono disponibili tecniche che permettono l identificazione e l autorizzazione attraverso il codice di identificazione (codice fiscale) presente nel certificato digitale LA CARTA RAFFAELLO La Carta Raffaello e la carta regionale dei servizi della Regione Marche é una carta a microprocessore che aderisce allo standard CNS (Carta Nazionale dei Servizi), e per quanto concerne la parte elettronica presenta le stesse caratteristiche funzionali della CIE (Carta di Identitá Elettronica). Figura 29 - Carta Raffaello La Carta Raffaello è nata come idea per lo sviluppo della società dell informazione ed è parte dell iniziativa proposta dalle giunta regionale denominate emarche. Le linee fondamentali dello sviluppo del progetto Carta Raffaello sono: egovernment, miglioramento del rapporto tra cittadini-imprese e pubblica amministrazione e semplificazione delle procedure 57

62 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA ehealth, accesso facilitato del cittadino ai servizi per la salute e ammodernamento del sistema sanitario regionale; elearning, organizzazione di un sistema dell apprendimento permanente per la valorizzazione del fattore umano; eeconomy, diffusione dell innovazione presso i sistemi produttivi, ed in particolare nei distretti industriali per una maggiore integrazione con gli attori del mercato e con il sistema dei servizi ; Larga banda, promozione dei progetti di infrastrutture di comunicazione, specie per quanto riguarda la diffusione dei sistemi a larga banda per evitare forme di sperequazione territoriale nell accesso ai servizi telematici. Il circuito di emissione della Carta Raffaello rispetta i requisiti previsti dalle regole tecniche per l emissione della CNS. In particolare, la Regione Marche è l ente emettitore della Carta ed è responsabile: della correttezza dei dati identificativi memorizzati nella carta e nel certificato di autenticazione; della correttezza del codice fiscale memorizzato nella carta e riportato nel certificato di autenticazione; della sicurezza delle fasi di produzione, inizializzazione, distribuzione ed aggiornamento/ritiro della carta; della fase di invio dei dati identificativi al Ministero dell interno, Centro Nazionale Servizi Demografici, per l aggiornamento dell INA (Indice Nazionale delle Anagrafi). La Regione Marche ha istituito un Centro Tecnico Regionale di supporto al sistema di emissione con la finalità di rappresentare un centro di competenza per tutti gli aspetti tecnologici connessi con la produzione e l utilizzo della Carta Raffaello. I compiti del centro sono: consulenza e assistenza tecnica agli enti che fanno parte del circuito di distribuzione; consulenza e assistenza tecnica a coloro che sviluppano o erogano servizi basati sulla Carta Raffaello; definizione dei requisiti funzionali e di sicurezza del sistema informativo di gestione della carta e di supporto all intero 58

63 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA processo di emissione, supervisione alla sua implementazione e successiva gestione e aggiornamento del sistema; adozione delle scelte tecnologiche per l integrazione con il sistema regionale di autenticazione e SSO (Cohesion), con il sistema sanitario, l IRUW e la posta elettronica certificata SPECIFICHE TECNICHE COMUNI Le CIE e CNS per quanto riguarda il supporto fisico è conforme agli standard ISO/IEC , mentre per quanto riguarda le caratteristiche interne della carta viene richiesto che la EEPROM abbia una capacità di almeno 32 KB ed inoltre che il microprocessore interno sia conforme agli standard ISO/IEC 7816 parte 3,4 e 8. Le APDU della carta dovranno rispettare anche le specifiche del sistema operativo oggetto del protocollo d intesa per la realizzazione dei progetti Carta d Identità Elettronica e Carta Nazionale dei Servizi. Visto che la CNS deve poter offrire il servizio di firma digitale, la smart card utilizzata dovrà essere certificata in base alla norma ISO/IEC secondo il Protection Profile riportato nell allegato A dello standard CWA IL FILE SYSTEM La struttura file system della smart card governative sono specificate dal CNIPA (Centro Nazionale per l Informatica nella Pubblica Amministrazione). Il file system della CIE e quella delle CNS sono pressoché uguali, si differenziano in alcune parti che sono dovute alla loro funzione. Nella CIE ci sono degli EF dedicati ai dati personali, alla foto, alle impronte e dati aggiuntivi. Mentre nella CNS ci sono degli EF dedicati al NETLINK per i servizi sanitari. Nella Figura 30 viene raffigurato un file system della CIE mentre nella Figura 31 della CNS. 59

64 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Figura 30 - File System della CIE 60

65 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Figura 31 - File System della CNS Per lo scopo della tesi il file che si è utilizzato per l autenticazione dell utente è il file EF_Dati_Personali. L EF_Dati_Personali è un file di 400 bytes e il percorso all interno del file system è dato da EF:MF/DF1/EF.DatiPersonali, esso contiene i dati dell'utente. I campi per identificazione personale (altezza, atto di nascita,...) non sono utilizzati. Nella Tabella 10 ci sono elencate tutte le informazione che sono presenti nel file. 61

66 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Dato Codifica Dim. Max Descrizione Emettitore ASCII 8 Codici standard Data di emissione del documento ASCII 4 GGMMAAAA Data di scadenza del documento ASCII GGMMAAAA Cognome ASCII 26 Nome ASCII 26 Data di nascita ASCII 8 GGMMAAAA Sasso ASCII 1 M per Maschio, F per Femmina Statura(cm) ASCII Espressa in cm Codice Fiscale ASCII 16 Cittadinanza ASCII Comune di Nascita ASCI 4 Stato estero di Nascita ASCII Estremi Atto di Nascita ASCII Comune di residenza al momento ASCII 4 dell emissione Indirizzo di residenza ASCII 80 Eventuale Annotazione in caso di non validità del documento per l espatrio ASCII Tabella 10 - Definizione dei dati Personali Ogni dato è codificato con un campo lunghezza (Len) ed un campo valore (Value). Il campo Len consiste in una stringa di due caratteri ASCII che codifica in esadecimale la lunghezza in byte del campo Value, allineata a destra, con riempimento di zeri a sinistra. Il campo Value viene codificato con una stringa ASCII. In testa al file è contenuta l'informazione sulla dimensione totale. La dimensione totale consiste in una stringa di sei caratteri ASCII che codifica in esadecimale la lunghezza in byte dello spazio utilizzato, allineata a destra, con riempimento di zeri a sinistra. Nel calcolo della lunghezza si prendono in conto anche i 6 byte della lunghezza stessa. I byte rimanenti nel file rispetto all allocazione massima vengono settati a 00h. 62

67 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA I COMANDI APDU I comandi per le carte CIE-CNS sono conformi allo standard ISO Il set di comandi accettato è quello illustrato nella Tabella11, c è da fare attenzione però, perché ciò non significa che i costruttori non possano implementare anche altri comandi per il sistema operativo, in pratica l implementazione dei seguenti è necessaria. Un accenno alle convenzioni usate, con la x minuscola viene indicata la possibilità che il comando possa essere inviato sia in chiaro (x=0) sia con le tecniche di secure messaging viste precedentemente (x=c). E naturalmente i valori dei campi CLA, INS, P1, P2, LC ed LE sono da intendersi tutti espressi in esadecimale. Comando Byte CLA Byte INS PUT DATA 0x DA CREATE FILE 00 E0 SELECT FILE 00 A4 READ BINARY 0x BO UPDATE BINARY 0x D6 APPEND RECORD 0x E2 READ RECORD 0X B2 UPDATE RECORD 0x DC VERIFY CHANGE REFERENCE DATA EXTERNAL AUTHENTICATE RESET RETRY COUNTER 00 2C GET CHALLENGE MSE GENERATE KEY PAIR PSO_DEC 0x 2A PSO_ENC 0x 2A PSO_CDS 0x 2A GIVE RANDOM Tabella 11 - Comandi APDU 63

68 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA I comandi che si sono utilizzati nel progetto della tesi sono: VERIFY, comando usato per effettuare la verifica del PIN/PUK. Il campo P1 assume sempre il valore 00 mentre il campo P2 contiene l ID del PIN/PUK. Il campo LC contiene la lunghezza del PIN (solitamente lungo 8 cifre, con esperienza di lavoro sulle carte, ho notato che ad esempio per PIN che hanno 5 cifre viene accettato il padding a 8 cifre, altrimenti l APDU di risposta ritorna un codice errore che segnala campo LC errato). Il campo dati contiene il codice PIN da verificare, il campo LE viene lasciato vuoto. SELECT_FILE, il comando che permette la selezione di un DF o di un EF. Per questa APDU il campo P1 e il campo dati possono assumere diversi valori a seconda del tipo di selezione che si va ad effettuare: o P1=00, indipendentemente dal contenuto del campo dati viene selezionato il DF o l EF al di sotto del DF corrente, oppure viene selezionato il master file (se il campo dati viene lasciato vuoto) o P1=03 seleziona il DF padre dell elemento attualmente selezionato, il campo dati viene lasciato vuoto o P1=04 seleziona il DF attraverso il suo nome, il campo dati conterrà il nome del DF o P1=08 seleziona un DF o un EF utilizzando il percorso completo (escluso il FID del master file) o P1=09 seleziona un DF o un EF utilizzando il path completo partendo dal DF selezionato al momento. Il campo P2 assumerà sempre il valore 00, nel campo LC viene indicata la lunghezza del campo dati, mentre nel campo LE viene indicata la lunghezza del campo dati dell APDU di risposta, ponendo LE=00 il campo dati dell APDU di risposta, conterrà tutti i dati FCI che riguardano il file selezionato. READ_BINARY, il comando che serve per leggere i dati da un file binario che è stato selezionato. I campi P1 e P2 indicano l offset per la lettura partendo dall inizio del file. Il campo LE indica il numero di byte da leggere. LC deve essere uguale a 00 infatti il campo dati è vuoto. 64

69 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA 2.3 LE API JAVA SATSA SATSA è l acronimo di Security And Trust Services APIs, sono delle API Java che fornisce una serie di strumenti per l accesso e alla crittografia delle smart card per le applicazioni che dovranno essere installate si piccoli dispositivi. Le specifiche SATSA definiscono quattro distinti gruppi di API: SATSA-APDU, permette alle applicazioni di comunicare con le applicazioni interne delle smart card usando i protocolli a basso livello; SATSA-JCRMI, fornisce una metodo alternativo per comunicare con le applicazioni interne alla smart card usando un protocollo remoto ad oggetti; SATSA-PKI, permette alle applicazioni di usare la smart card come firma digitale dei dati e gestire in certificati dell utente; SATSA-CRIPTO, è una API crittografica general-purpose che supporta i messaggi digest, firma digitali e cifrati. Figura 32 - Struttura API SATSA ARCHITETTURA DELLE APPLICAZIONI SATSA Una tipica applicazione è fondamentalmente costituita da tre tipi di hardware: 65

70 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Un server permanente che contiene le informazione per l applicazioni e svolge la maggior parte delle operazioni di calcolo indispensabile dove girano della applicazioni J2ME. Un dispositivo, di solito posseduto dall utente che deve interagire con il server. Il server e il dispositivo interagiscono tramite una rete di comunicazione. Una smart card collegata, in modo permanente o temporaneo, al dispositivo, la quale può eseguire crittografia o operazioni supplementari. Nella realtà ci sono molti modi per strutturare la applicazioni, e ci sono casi dove non sono necessari tutti i componenti UTILIZZO DEI THREAD L applicazione S.A.T.S.A. può impiegare alcune centinaia di millisecondi nella sua esecuzione, quindi occorre tener presente che si può aver bisogno dell uso dei thread. Un thread è una suddivisione di un programma in due o più task che vengono eseguiti in modo concorrente. L uso dei thread è causato principalmente dal fatto che se un applicazione impiega molto tempo nell esecuzione, di conseguenza l intero sistema si blocca e l utente non capisce cosa sta succedendo causando un esperienza spiacevole di utilizzo. Nella programmazione delle applicazioni ogni volta che si comunica con le smart card attraverso le SATSA-APDU o SATSA-JCRMI occorre sempre considerare sia il tempo di comunicazione che il tempo di elaborazione dei processi interni alla smart card per generare una risposta, oltretutto se si eseguono operazioni di crittografia, le SATSA-PKI e SATSA-CRYPTO si ha un aumento di tempo si esecuzione, specialmente quando se sono eseguite da hardware poco potente. In conclusione è da considerare obbligatorio l utilizzo dei thread durante la progettazione e sviluppo del codice delle applicazioni 66

71 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA SATSA per avere un interfaccia gradevole nonostante le lunghe operazioni con le smart card SATSA NEGLI STANDARD PER LA TV DIGITALE TERRESTRE In Italia le specifiche per la costruzione di apparati per il digitale terrestre che possono essere messi in commercio sono regolate da 2 documenti : D-Book, per apparecchiature con definizione standard HD-Book, per apparecchiature ad alta definizione (HD, High Definition) Sia nell ultima versione D-Book che nell ultima versione HD-Book nella sezione si definiscono i requisiti per le applicazioni che utilizzano le smart card non ad accesso condizionato ( T-Government, T-Healt, T-Banking, carta fedeltà ) ed è supporto delle API SATSA introdotte nello standard DVB-MHP, dalla versione in poi. Le API SATSA sono state introdottre a discapito del precedenti API, il framework OCF (Open Card Framework). Nell adoperare queste specifiche il DGTVi ha riscontrato 2 problemi: 1. le API SATSA non hanno la gestione degli eventi inerenti lo stato fisico della smart card all interno del lettore ( carta inserita\disinserita, carta inserita alla rovescia ecc.) 2. In realtà SATSA non ha un supporto per le smart card non Java Card e soprattutto per le Java Card che non hanno l identificativo di applicazione (AID). D conseguenza essendo la maggior parte della smart card governative Italiane non Java card ed in teoria l applicazione lancia un eccezione. La soluzione del primo problema viene descritta nel D-Book ver.1.2 rev.1 appendice H, stessa cosa HD-Book ver.1.0 appendice H, dove si propone di utilizzare le API MHP CA ed il Java Package it.dtt.ca ver 1.2, che hanno lo scopo di fornire alle applicazioni MHP la conoscenza dello stato del lettore di smart card compatibile con le specifiche ISO Si nota che questa API non andranno ad intaccare la applicazioni per l accesso condizionato. 67

72 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Le classi che sono indispensabili del package it.dtt.ca sono: Package it.dtt.ca : CaManager, questa classe è la classe usata per monitorare lo stato del lettore di smart card. I metodi sono: o getcaprovider, dovrebbe ritornare una stringa SATSA o getclient, ritorna il lettore associato all oggetto o getslots, ritorna un array con il numero Slot associati al lettore di smart card CaManagerFactory, è la classa usata per creare gli oggetti CaManager questo permette di avere sono un CaManager per ogni sessione aperta, i metodi sono: o closesession, solo quando una sessione è stata chiusa se ne può aprire una, se si chiude una sessione che non è stata aperta avviene un accezione NoSessionOpenedException o getinstance, questo metodo consente al processo di verificare lo stato della smart card o opensession, una volta che è stata creata l istanza di CAManagerFactory con questo metodo si può avviare una sessione. CaObject CaSession Slot, questa classe rappresenta il lettore di smart card, i metodi che sono: o Constructors o addslotlistener o getslotid o getsmartcard 68

73 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA o getstatus, questo metodo ritorna lo stato del lettore di smart card, gli stati possibili sono definiti dallo SlotEvent o removeslotlistener Package it.dtt.ca.event ha le seguenti classi: CaEvent SlotEvent, questo definisce gli eventi che si evolvono nel lettore di smart card. I possibili valori sono: o CARD_ERROR o CARD_IN o CARD_MUTED o CARD_OUT o CARD_VERIFING o ERROR_UNKNOWN SlotListener, questa è un interfaccia che deve essere implementata da ogni applicazione che vuole monitorare lo stato del lettore di smart card. SlotEventReceived Un esempio dell ipotetica gestione può essere: public class Example implements SlotListener, ResourceClient; CAManagerFactory factory; CAManager manager; Slot reader; Slot[] slots; /* Inizializzazione delle API try { factory = CAManagerFactory.getInstance( SATSA, ANY ); catch (NoSuchProviderException) { System.out.println( This API does not support ISO 7816 generic smart card reader monitoring ); /* Istanzazzione del Manager try { manager = factory.opensession(this); catch (SessionAlreadyOpenedException) { System.out.println( C è una applicazione che usa le CA API ); 69

74 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA try { /* Ottiene unlettore di smart-card (singolo lettore nel STB) slots = manager.getslots(); reader = slots[0]; /* Controllo dello stato if (slot.getstatus!= SlotEvent.CARD_IN) System.out.println( C e un problema con la smart card ); /* Collego un ascoltatore dello slot del lettore di smart card reader.addslotlistener(this); catch (SessionClosedException) { System.out.println( La session è chiusa ); public void sloteventreceived(slotevent event) { System.out.println( Error number +event.gettype()+ +event.getdescription()); if (event.gettype == SlotEvent.CARD_OUT) System.out.println( La smart card è stata rimossa ); Il secondo problema viene risolto nel D-Book ver.1.2 rev.1 appendice I, stessa cosa nell HD-Book ver.1.0 appendice I. Il problema consisteva nel definire l identificativo AID da utilizzare nelle applicazioni con SASTA perché altrimenti l applicazione darà come risultato un errore. Il problema non era sorto precedentemente perché nello standard MHP 1.0 era utilizzato un diversa tipologia di gestione, OCF (Open Card Framework), il quale fu abbandonato a causa dello scioglimento del consorzio Open Card. La soluzione che propone il DGTVi è quella di utilizzare un nuovo target chiamato CXS da utilizzare nella classe Connector.open e quindi si ha come URL una stinga come questa apdu:0,target="cxs" e la connessione sarà data dall istruzione: Connector.open("apdu:0,target="CXS") Un esempio di possibile connessione è: APDUConnection cxs; cxs = (APDUConnection)Connector.open("apdu:0;target=CXS"); byte[] apdu = { (byte)0x00, (byte)0x20, (byte)0x00, (byte)0x82, (byte)0x04, (byte)0x01, (byte)0x02, (byte)0x03, (byte)0x04, (byte)0x00 ; byte[] response = cxs.exchangeapdu(apdu); cxs.close(); 70

75 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA LE SPECIFICHE DEL PACKAGES SATSA-APDU Le SATSA-APDU consentono di comunicare con la smart card usando i protocolli basati sulle APDU (Application Protocol Data Unit). Queste comunicazioni sono definite negli standard ISO Un APDU come già detto è un breve messaggio di byte che verrà spedito alla smart card attraverso le SATSA-APDU di conseguenza la smart card invierà un messaggio di risposta. Il package SATSA-APDU è composto da una singola interfaccia, la javax.microedition.apdu.apduconnection, che contiene sette metodi più uno ereditato dall interfaccia javax.microedition.io.connection : 1) changepin (int Pin ID) 2) disablepin (int pinid) 3) enablepin (int pinid) 4) enterpin( int pinid) 5) exchengeapdu ( byte[] commandapdu) 6) getatr() 7) unblockpin( int blockedpinid, int unblockingpinid) 8) close() ereditato APRIRE UNA CONNESSIONE CON LE SATSA-APDU Il Package SATSA-APDU è sostanzialmente un estensione del Java GCF ( Generic Connection Framework). Il GCF fornisce un set di API per diverse connessione dati. La classe javax.microedition.io.connector è indispensabile per effettuare le connessioni. Più precisamente la classe javax.microedition.io.connector utilizza il metodo open che ha come parametro un indirizzo URL (Uniform Resource Locator) che identifica dove si deve effettuare la connessione. 71

76 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA Nelle applicazioni SATSA-APDU si passa una stringa che identifica la smart card. La stringa di connessione deve avere la forma descritta dalla Tabella 12. <Stringa_di_connessione_APDU> := "apdu:"<indirizzotarget> <indirizzotarget > := [slot];target <slot> := numero dello slot del lettore smart card <target> := "target="<aid> "SAT", Application ID oppure SAT <AID> := < 5-16 bytes >, deve essere di quella range di lunghezza ad esempio: 0a c Tabella 12 - formato URL per le connessioni SATSA-APDU Ad esempio una tipica connessione con un identificativo della smart card uguale 0a c e come numero di slot 0 sarà: String URL = "apdu:0;target=a c.02.01"; APDUConnection testapduconnection; testapduconnection = (APDUConnection) Connector.open (URL); L eccezioni che le connessioni SATSA- APDU possono lanciare sono : ConnectionNotFoundException, la quale si può verificare nei seguenti casi: se il lo slot di lettura non esiste. se la smart card non è stata inserita o non è alimentata. se l applicazione fallisce la selezione degli identificativi o dello slot o della smart card. SecurityException, si verifica se applicazione non ha i permessi per accedere alle risorse, lettore smart card o smart card. 72

77 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA IOException, si verifica quando ci sono problemi di comunicazione nel canale logico di durante la connessione. InterruptedIOException, si verifica quando viene interrotta bruscamente la comunicazione, ad esempio quando viene tolta la smart card dal lettore improvvisamente SCAMBIO DEI MESSAGGI APDU Attraverso il metodo exchangeapdu() è possibile inviare comandi APDU alla smart card e ricevere le risposte. I comandi e le risposte sono delle stringhe di byte che sono definite dalle specifiche del sistema operativo della smart card. Un esempio di scambio di messaggi è: byte[] apdu ={(byte)0x00,(byte)0x20,(byte)0x00,(byte)0x82,(byte)0x04, (byte)0x01,(byte)0x02,(byte)0x03,(byte)0x04, (byte)0x00; byte[] risposta = testapduconnection.exchangeapdu(apdu); CHIUSURA DI UNA CONNESSIONE La chiusura di una connessione consiste semplicemente nel chiamare il metodo close() come nell esempio: testapduconnection.close() L unica accortezza da prendere è quella di controllare se si sta chiudendo delle connessioni anche in altri thread che stanno usando la stessa connessione in quel caso si avranno delle eccezioni del tipo InterruptedException quando si usa il metodo exchangeapdu() ESEMPIO DI APPLICAZIONE CON LE SATSA-APDU Un esempio di applicazione con le SATSA-APDU è la seguente: APDUConnection testapduconnection = null; try{ //crea un oggetto APDUConnection testapduconnection = (APDUConnection) Connector.open("apdu:0;target=A F.3.2C.3"); //manda un commando APDU e riceve la risposta APDU responseapdu = testapduconnection.exchangeapdu(commandapdu); catch (IOException e) { finally { 73

78 CAPITOLO 2 LE SMART CARD GOVERNATIVE E LE JAVA API SATSA if(testapduconnection!= null) { // Chiusura della Connessione testapduconnection.close(); 74

79 CAPITOLO 3 L A.S.U.R. MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE 3.1 L ASUR N 7 E IL PROGETTO PER LA TV DTT Il lavoro argomento della tesi è stato svolto presso l ASUR Marche zona territoriale 7 ad Ancona e più precisamente presso il CED (Centro di Elaborazione Dati). Figura 33 - Logo ASUR Marche Zona Territoriale 7 L Azienda Sanitaria Unica Regionale (ASUR) è stata istituita con Legge Regionale n.13 del 20 giugno 2003 "Riorganizzazione del Servizio Sanitario regionale" e svolge al livello centralizzato, funzioni di governo unitario ed omogeneo dei processi gestionali, secondo modalità definite dalla Giunta regionale delle Marche. L ASUR ha caratteristiche assolutamente innovative e non ha riferimenti analoghi nel panorama nazionale. Sul piano strategico richiede quindi una continua verifica delle iniziative intraprese per raggiungere la più elevata efficacia gestionale, aderente alla nuova logica organizzativa. Proprio perché l orizzonte istituzionale di riferimento è molto distante dalla tradizionale architettura dei sistemi sanitari, il processo di trasformazione necessario si presenta senza precedenti. Il sistema della regione Marche è stato storicamente caratterizzato dai seguenti elementi: 75

80 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Rilevante ed estesa copertura assistenziale in tutti gli ambiti del comparto socio-sanitario. Necessità di recuperare una dimensione aziendale in grado di ottimizzare i processi produttivi e di integrarli all interno di un sistema a rete. Questo scenario ha prodotto negli ultimi anni una situazione di disequilibrio a cui il governo regionale ha risposto con un riassetto istituzionale complessivo del sistema. Il quadro di frammentazione istituzionale ed operativa delineato, l esigenza di assicurare una transizione veloce e decisa, la necessità di proporre a tutti gli attori esterni ed interni un disegno facilmente intelligibile nel quale collocarsi rapidamente, l opportunità di semplificare i meccanismi attuativi, la necessità di consolidare il ruolo di indirizzo e controllo svolto dagli enti locali, sono tutti elementi che hanno fatto propendere per la soluzione dell azienda unica, basata sulle seguenti scelte: accorpamento delle 13 ASL in un unica azienda sanitaria regionale; istituzione di 13 zone (corrispondenti ai 13 ambiti territoriali delle ex ASL), dirette di un Direttore di zona nominato direttamente dalla Giunta regionale; struttura organizzativa a "rete" nell Azienda Unica: di ambito regionale per alcuni servizi amministrativi/sanitari, di dimensione di area vasta, zonale per altri. L obiettivo è quello di garantire un impianto dove le esigenze ed i contributi della rappresentanza politico-istituzionale, le razionalità aziendali e la razionalità dei processi tecnici possano trovare un contemperamento tale da assicurare alla collettività marchigiana un sistema sanitario equo e sostenibile. La nuova struttura organizzativa è definita più in dettaglio nell atto aziendale. Nell ambito dell autonomia organizzativa aziendale, l Azienda disciplina la propria organizzazione assumendo come riferimento prioritario la centralità del cittadino ed il soddisfacimento dei suoi bisogni di salute. L intera struttura organizzativa è impostata 76

81 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE non solo in un ottica di controllo dei costi, ma di ricerca di un livello di servizio superiore per i clienti interni ed esterni. Le parole-chiave sono: innovazione, efficienza, soddisfazione del cliente, mantenimento e miglioramento della qualità del servizio nel tempo. Sul piano organizzativo-istituzionale, l ASUR è articolata in tredici zone Territoriali che hanno compiti di programmazione e gestione dei servizi sanitari e socio-sanitari nel rispettivo ambito territoriale, autonomia gestionale ed operativa. Le zone territoriali sono responsabili del governo clinico e assicurano alla popolazione residente le prestazioni incluse nei livelli essenziali di assistenza (LEA) e l equo accesso ai servizi e alle funzioni di tipo sanitario, sociale e di elevata integrazione sanitaria, organizzate nel territorio zonale o aziendale. Ogni zona territoriale è diretta da un direttore di zona responsabile delle funzioni di programmazione e coordinamento, nonché della gestione complessiva del relativo ambito territoriale. Figura 34 - Servizi On-Line ASUR 7 I servizi che l ASUR n 7 offre on-line sono dedicat i elle seguenti categorie: Cittadini; 77

82 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Farmacisti; Medici. Alla prima categoria vengono offerti servizi di : Ricerca indirizzi e turni delle farmacie Ricerca di medici e pediatri Elenco delle strutture sanitarie e relativi servizi e disposizione Recapiti ed indirizzi di enti per la tutele del malato Motori di ricerca per trovare la strutture che erogano un servizio sanitari desiderato Informazioni sulle liste d attesa Informazioni generiche come meteo, orati treni ed autobus e altre notizie. Figura 35 - Accesso delle informazioni on-line dell ASUR n 7 I farmacisti hanno accesso mediante password ai referti online dei pazienti. I servizi più avanzati sono destinati ai medici e sono: CUP Metropolitano S.I.S.T.O. ME.RI.TO. 78

83 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Il CUP (Centro Unico di Prenotazione) è un servizio esistente presso gli sportelli dell ASUR. Negli ultimi anni è stata estesa la funzionalità di questo ad internet. Ad oggi ogni medico di base può prenotare una visita medica ad un suo paziente semplicemente attraverso l utilizzo di un PC connesso ad internet. S.I.S.T.O. è il progetto avanzato che permette di sincronizzare il database dell ASUR con quello dell Ospedale. Figura 36 - CUP Metropolitano on-line ASUR 7 Il servizio ME.RI.TO. permette la visualizzazione dei referti di radiologia e laboratorio di analisi delle quattro strutture della zona 7. Il funzionamento è simile a quello dal CUP Metropolitano ad eccezione dal fatto che con questo non è possibile prenotare, ma soltanto consultare referti. 79

84 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Figura 37 - ME.RI.TO. servizio On-Line ASUR IL DIGITAL DIVIDE E L APPLICAZIONE DELL ASUR N 7 SUL DIGITALE TERRESTE I servizi on-line hanno un grande problema di fondo, il Digital Divide. Digital Divide sono le parole inglesi per indicare il divario che c è tra chi può accedere alle nuove tecnologie (internet, web, personal computer, ) e chi no. Il Digital Divide si può ricondurre principalmente a due insiemi di cause: l'assenza di infrastrutture a banda larga; l'analfabetismo informatico degli utenti, riguardo il computer in genere, e le potenzialità di Internet. Per affrontare questo problema l ASUR, mentre aspetta che la televisione digitale terrestre completi il suo processo di affermazione, ha avviato dei progetti di sperimentazione per trasferire i suoi servizi on-line sulla piattaforma DTT. Queste sperimentazioni sono motivate dai vantaggi tecnologici che ha la TV digitale: 80

85 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE altissima tasso di penetrazione della televisione nella popolazione italiana, molto più elevato che per i PC; la televisione è un elettrodomestico e strumento tecnologico con bassa difficoltà di apprendimento e ormai di uso comune; attraverso l utilizzo dei ricevitori MHP e una smart card governativa (CIE, CNS, CRS) si ha una maggiore efficacia per l autenticazione e la sicurezza della comunicazione rispetto ai PC, dovuta all architettura intrinseca del sistema. Figura 38 - Schermata iniziale dell Applicazione per il DTT dell'asur 7 L applicazione che è stata progettata e sviluppata offriva due servizi: 81

86 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Servizi informativi o informazioni utili, che si accede tramite il tasto verde del telecomando. Figura 39 - Schermata Servizi Informativi Servizi interattivi, che si accede attraverso il tasto rosso del telecomando. Figura 40 - Schermata Servizi Interattivi 82

87 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Tra i servizi informativi venivano visualizzati 3 tipologie: Informazioni sulle farmacie. Figura 41 - Schermata Servizi Informativi: Farmacie Informazioni di Medici Generici e Medici Pediatra. Figura 42- Schermata Servizi Informativi : Medici 83

88 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Numeri utili delle molteplici strutture dell ASUR 7 Figura 43- Schermata Servizi Informativi : Numeri Utili Finora le applicazione che si sono presentate sono simili ad superteletext con effetti grafici più gradevoli ma che di innovativo hanno ben poco. La vera innovazione della TV digitale terrestre è l interattiva con le applicazioni in linea o remote o con canale di ritorno. Nella applicazione dell ASUR si è cercato di sperimentare il CUP (Centro Unico di Prenotazione) anche sulla piattaforma digitale terrestre in modo da integrare il servizio già presente nel web cercando così di arrivare con i servizi on-line ad una più ampio pubblico. Il primo passo per entrare nei servizi on-line è quello dell autenticazione dell utente nel server remoto. Le modalità previste sono 2, tramite inserimento nome utente e password oppure utilizzando le smart card governative CIE, CNS o CRS. Per quanto riguarda la prima modalità è stata risolta attraverso un tastiera alfa-numerica visualizzata nello schermo e l utente con i comandi del telecomando doveva scrivere le sue credenziali, USR e PWD. 84

89 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Figura 44 - Schermata di inserimento User e Password per i servizi Interattivi L altra modalità accesso viene fatta attraverso l uso di smart card. Figura 45 - Schermata per l'autenticazione attraverso la Smart Card L utente che è in possesso delle smart card dovrà inserirla nel lettore del ricevitore MHP e di seguito apparirà la richiesta di inserire il codice PIN, codice numerico facile da inserire. 85

90 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Figura 46 - Schermata di inserimento del PIN per i servizi Inerattivi Dopo la verifica del PIN si visualizzeranno i dati personali per confermare l identità e si potrà accedere alle operazioni del CUP. Figura 47 - Schermata di visualizzazione dei Dati Personali dei Servizi Interattivi Una volta autenticato l utente tramite il canale di ritorno è possibile accedere alle operazioni del CUP: Visualizzazione Agenda Appuntamenti Prenotazione Visita Cancellazione Visita 86

91 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Figura 48- Schermata di Accesso alle Operazioni del CUP Figura 49 - Schermata di Visualizzazione, Cancellazione o Prenotazione di visite del CUP 3.3 LE PROBLEMATICHE DELL APPLICAZIONE DELL ASUR N 7 SUL DIGITALE TERRESTRE Fino ad oggi il punto debole della applicazione dell ASUR 7 per il digitale terrestre è la gestione della smart card. Il motivo del problema è il cambio di API che c è stato tra la versione dello standard MHP alla versione MHP e successive. Infatti la versione MHP supportava il framework OCF (Open Card Frame work) mentre dalle versione MHP e stato sostituito OCF con SATSA (Security 87

92 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE And Trust Service API) della Sun. Il cambio di specifiche è stato causato dallo scioglimento del consorzio formato da IBM, Netscape, Sun, Simens, Gemplus, Schlumber, Bull, Visa e altre aziende, che ha lasciato in sospeso l OCF alla versione 1.2. La gestione delle smart card con OCF è strutturata con le seguenti classi: PaginaCard SCs OttieniCodiceFiscale ParseDati SCsApdu SCsFactory Il framework OCF in realtà è molto complesso ma nell ambiente MHP non è necessario sfruttare tutta la sua complessità. Per semplificare si può dividere la gestione delle smart card in due parti: la parte che riguardante il lettore di smart card; la parte che si occupa della stessa smart card e dei servizi che essa offre. La classe CardTerminal rappresenta uno specifico lettore di smart card, che può leggere più di una smart card. Tramite la classe CardTerminal si può scoprire quanti slot sono disponibili, e le notifiche di inserimento o rimozione di una smart card. La seconda parte fondamentale è contenuta nel pacchetto opencard.core.services. Qui viene definita la classe SmartCard che rappresenta la smart card inserita nel lettore. La classe più importante del package è la classe CardService dove ci sono i metodi per comunicare con la smart card attraverso comandi a basso livello, le APDU. 88

93 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE La classe PaginaCard è quella che si occupa di gestire il lettore di smart card implementando l interfaccia opencard.core.event.ctlistener che fornisce i metodi cardinserted() e cardremoved(). Questi metodi in pratica sono implementate le operazioni che devono essere svolte quando l utente inserisce e toglie la smart card. Appena si inserisce vengono eseguite le operazioni che sono all interno del metodo cardinserted() : 1. Viene richiesto l inserimento del PIN, tramite l uso del telecomando. Se il PIN inserito è quello giusto vengono eseguite le operazioni successive; 2. Vengono mandati i comandi APDU, per primo il comando SELECT_FILE per la selezione del file DATI_PERSONALI all interno della smart card. Selezionato il file viene letto il contenuto tramite il comando READ_BINARY. 3. Una volta letti i dati essendo questi in formato esadecimale e formattati secondo le specifiche proprie delle smart card governative, tramite le classi OttieniCodiceFiscale e ParseDati le informazioni vengono trasformati in modo de poterle usare per i servizi. Se uno dei comandi previsti non va a buon fine viene segnalato a schermo un errore e l utente deve riprovare reinserendo la carta nel lettore. Infine se tutte le istruzioni sono eseguite viene creata e disegnata automaticamente una istanza della classe che si occupa di gestire il canale di ritorno. 3.4 IL LABORATORIO PRESENTE ALL ASURN 7 E LE PROBLEMATICHE Il laboratorio dove sono state sviluppato le applicazioni MHP presso l ASUR è costituito dai seguenti componenti: un Personal Computer con installato un ambiente Java per la stesura del codice. 89

94 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE una televisione munita di presa SCART Set Top Box da sviluppo ADB X-75 Figura 50- Laboratorio MHP ASUR 7 Gli apparati insieme funzionano nel seguente modo: il STB viene collegato tramite SCART alla TV, tramite RS232 e alla RJ45 al PC e all antenna tramite il classico cavo coassiale; con il collegamento RJ45, il PC e STB effettua una rete LAN per simulare il canale di ritorno reale quindi si ha la situazione client- STB e server-pc; il collegamento con la seriale RS232 tra il PC e il STB permette di caricare le applicazioni MHP (Xlet) attraverso dei semplici programmi di interfaccia forniti dalla ADB con il STB (stbproxy, stbconfig, stbupload), e di verificare i messaggi di debug che manda il STB. Quindi il processo di sviluppo di un applicazione con questo laboratorio è il seguente: a) progettazione e implementazione dell Xlet, utilizzando IDE Java e le classi Stubs per la compilazione, con il PC. 90

95 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE b) si fa partire il stbproxy indicandogli la porta seriale corretta e la porta del protocollo TCP e il percorso del file di log per il debug; c) tramite stbupload si caricano le classi compilate dell Xlet con l adeguato file dell AIT (Application Identification Table); d) si avvia con telecomando l applicazione MHP nel STB; e) si testa l applicazione e si controlla il file di log per eventuali messaggi di errore LE PROBLEMATICHE DEL LABORATORIO Il processo di sviluppo e di testing della applicazione appena descritto è molto veloce e efficace ma a causa del STB ADB X.75, componente fondamentale, non si riesce a sviluppare la gestione delle smart card con le API SATSA. Infatti non è possibile aggiornare il middleware del STB, fermo alla versione MHP1.0.2, a causa dell hardware ormai diventato obsoleto. Non potendo aggiornare il decoder è impossibile sviluppare la applicazioni utilizzando le API SATSA ma soltanto con il non più supportato OCF POSSIBILI LABORATORI PER LO SVILUPPO APPLICAZIONI MHP E LA SOLUZIONE ADOTTATA Per risolvere il problema del laboratorio si sono studiate quattro tipologie di soluzioni e tra queste si è cercato di prendere la soluzione ottimale in termini di economicità, facilità e velocità di sviluppo delle applicazioni LA PRIMA SOLUZIONE I componenti della prima soluzione sono: PC dotato di IDE Java,Librerie MHP Stubs, Server Web; Software per interfacciamento PC e STB didattico; Lettore di Smart Card; 91

96 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Set Top Box dotato di lettore smart card, supporto SATSA, RS232 e canale di ritorno ; Televisore. Figura 1 Schema Laboratorio MHP Soluzione 1 Il funzionamento del sistema è semplice e si basa sulla fondamentale applicazione di interfacciamento tra PC e STB che permette di fare l'upload di una Xlet memorizzandola direttamente nella memoria del STB ed un collegamento via RS232 che mette in comunicazione il PC con STB. In sostanza tramite un IDE Java e delle librerie MHP stubs, usate per la compilazione, si costruisce l'xlet e si compila ottenendo i file.class. Con il lettore di Smart Card si possono fare test preliminari sulla gestione della Smart Card con il STB. Per eseguire il test dell'xlet ed il debug si devono caricare nel STB le classi, questo passaggio viene effettuato dal il programma PC&STB. Il debug viene effettuato tramite programmi che ascoltano la seriale e l'utilizzo e della istruzione java system.out.println( messaggio di debug ) all interno dell applicazione MHP. Vantaggi: Economico Facile da installare e implementare 92

97 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Produttività del software veloce Svantaggi: Sviluppo delle applicazioni solo su poche tipologie di STB LA SECONDA SOLUZIONE I componenti della seconda soluzione sono: PC dotato di IDE Java, Librerie MHP Stubs, Server Web Lettore di Smart Card Scheda PCI modulatore e upconverter con uscita UHF a basso costo Generatore Software del Transport Stream (Carousel Generator) Set Top Box con lettore Smart Card, supporto SATSA, RS232 e canale di ritorno Televisore Figura 52 - Schema Laboratorio MHP Soluzione 2 Tramite un PC con un IDE Java, le librerie MHP Stubs e il lettore di Smart Card si sviluppano le applicazioni MHP. Finito lo sviluppo si 93

98 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE ottengono tutti i file.class del Xlet che dovrà essere eseguita dal STB. A questo punto la stazione di Trasmissione composta da un Pc, una scheda PCI per generare insegnale televisivo, un generatore di TS, si occupa di far eseguire a qualsiasi STB l'applicazione MHP sviluppata e lo fa nel seguente modo : In Carousel Generator realizza il Transport Stream dove all'interno c è applicazione MHP da caricare nel STB secondo le specifiche MHP. il Transport Stream viene modulato e passato all'up-converter dalla scheda PCI per avere un onda analogica adeguate per la trasmissione che viene inviata al STB il STB riceve l'applicazione messa on-air e la esegue. Una volta caricata l'applicazione nel STB con al connessione RS232 al PC da sviluppo attraverso programmi di ascolto di porta seriali si possono visualizzare i messaggi di debug della applicazione. Vantaggi: Test delle applicazione on-air Possibilità di testare le applicazioni su qualsiasi STB commerciale Svantaggi: Costo elevato Relativa lentezza nello sviluppo delle applicazioni LA TERZA SOLUZIONE I componenti delle terza soluzione sono: PC Kit da sviluppo software commerciali Set Top Box con lettore Smart Card, supporto SATSA, RS232 e canale di ritorno (opzionale) 94

99 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Televisore (Optional) Figura 53 - Schema Laboratorio MHP Soluzione 3 Con il kit da sviluppo commerciali si ha tutto l'occorrente software per lo sviluppo della applicazioni MHP cioè un completo IDE java per la costruzioni e test di applicazioni MHP. Si integra con gli IDE Java ed il test viene effettuato tramite emulatori software MHP che rispecchiano i nuovi standard MHP1.1.2 con conseguente supporto SATSA per la connessione con i lettori di Smart Card e inoltre la possibilità di collegarsi su STB reali per il test reale della applicazioni. Vantaggi: Possibilità di sviluppo senza l'utilizzo di STB che si tramuta in maggiore produttività Svantaggi: Costo elevato Dipendenza da particolari sistemi DTT LA QUARTA SOLUZIONE I componenti della quarta soluzione sono: 95

100 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE PC dotato di IDE Java, Librerie MHP Stubs, Server Web Lettore di smart card MHP Development Carousel commerciale Set Top Box con lettore Smart Card, supporto SATSA, RS232 e canale di ritorno Televisore Figura 54 - Schema Laboratorio DTT Soluzione 4 Tramite un PC con un IDE Java, le librerie MHP Stubs e il lettore di Smart Card si possono sviluppare le applicazioni MHP. Una volta compilate si ottengono tutti i file.class che dovranno essere eseguiti dal STB. Tramite un MHP Development Carousel commericiale si possono far eseguire le soluzioni MHP su STB senza dotarsi della catena di trasmissione, riducendo notevolmente il costo di un installazione di sviluppo o dimostrazione. Un modulatore OFDM integrato consente il collegamento diretto di qualsiasi set top box commerciale, in modo da poter verificare fedelmente il comportamento della propria applicazione prima della trasmissione effettiva in onda. Il segnale modulato potrà anche essere utilizzato in un circuito televisivo interno, in modo da rendere disponibile un applicazione MHP a più utenti locali contemporaneamente per il collaudo e la valutazione. 96

101 CAPITOLO 3 - L ASUR MARCHE N 7, IL LABORATORIO PER IL DTT, L APPLICAZIONE E LE PROBLEMATICHE Vantaggi: Garanzie e assistenza da parte della aziende produttrici dell'intero impianto Test delle applicazione on-air Possibilità di testare le applicazioni su qualsiasi STB commerciale Svantaggi: Costo elevatissimo Sviluppo delle applicazioni relativamente lento LA SOLUZIONE ADOTTATA La soluzione che si è adottata per lo sviluppo della nuova gestione delle smart card con le API SATSA è stata la prima. La motivazioni della scelta sono pressoché dovuta alla forte somiglianza del vecchio laboratorio e inoltre alla economicità. I componenti quindi che differenziano il vecchio laboratorio sono : il software per interfacciare il STB con il PC Set Top Box Per quanto riguarda il Set Top Box è stato utilizzato un Telesystem TS.7.4DT con la versione software 21p1 del produttore, e che implementa il profilo MHP con l aggiunta, in primo luogo le classi SATSA per la gestione delle smart card,il sistema operativo real-time ` e Osmosys, ha un interfaccia RS-232 e un modem integrato V.90. Figura 55 - Set Top Box utilizzato per il progetto della Tesi 97

102 CAPITOLO 4 LAVORO SVOLTO: GESTIONE DELLE SMART CARD CON LE API JAVA S.A.T.S.A. 4.1 SVILUPPO DELLA GESTIONE DELLE SMART CARD CON LE JAVA API SATSA Come da titolo della tesi in questa sezione viene descritta la progettazione e l implementazione di una gestione della smart card per un applicazione MHP utilizzando SATSA. In un primo momento è stato sviluppato un progetto chiamato MHPSmartCard con lo scopo di leggere all interno della smart card i dati personali dopo che l utente ha immesso il codice PIN, e successivamente visualizzarli nello schermo del televisore. In seguito è stato effettuato il refactoring dell applicazione per i servizi on-line sulla piattaforma del digitale terrestre dell ASUR, sostituendo le classi sviluppate con OCF. 4.2 PROGETTO MHPSMARTCARD Il progetto MHPSmartCard è una semplice Xlet che si occupa della management di una smart card di tipo CIE\CNS. Le fasi dell applicazione sono: a) Avviamento dell Xlet nel STB attraverso l Application Manager del STB. 98

103 CAPITOLO 4 - LAVORO SVOLTO : GESTIONE DELLE SMART CARD CON LE API S.A.T.S.A. Figura 56 - Schermata Avviamento Xlet dall'application Manager Figura 57 - Schermata iniziale dell'xlet 99

104 CAPITOLO 4 - LAVORO SVOLTO : GESTIONE DELLE SMART CARD CON LE API S.A.T.S.A. b) Inserimento della smart card nel lettore. Figura 58 - Inserimento Smart Card c) Richiesta ed inserimento del codice PIN. Figura 59 - Schermata Richiesta PIN 100

105 CAPITOLO 4 - LAVORO SVOLTO : GESTIONE DELLE SMART CARD CON LE API S.A.T.S.A. Figura 60 - Schermata Inserimento PIN d) Verifica del PIN. Figura 61 - Schermata di Verifica PIN 101

106 CAPITOLO 4 - LAVORO SVOLTO : GESTIONE DELLE SMART CARD CON LE API S.A.T.S.A. e) Lettura dei dati all interno della smart card. Figura 62 - Schermata di Lettura Dati nella Smart Card f) Visualizzazione dei dati nello schermo. Figura 63 - Schermata di Visualizzazione Dati 102

107 CAPITOLO 4 - LAVORO SVOLTO : GESTIONE DELLE SMART CARD CON LE API S.A.T.S.A. g) nel caso di smart card bloccata si ha un messaggio di errore. Figura 64 - Schermata di Smart Card Bloccata h) nel caso di errori generici si ha un altro messaggio di errore Figura 65 - Schermata di errore generico 103

108 CAPITOLO 4 - LAVORO SVOLTO : GESTIONE DELLE SMART CARD CON LE API S.A.T.S.A DESCRIZIONE DELLE CLASSI E DEL LORO FUNZIONAMENTO Prima di andare a descrivere le classi e il funzionamento dell applicazione occorre prima introdurre 2 concetti fondamentali: il pattern Singleton; il pattern Observer; I pattern, o design pattern sono delle soluzioni progettuali generali a un problema ricorrente. In sostanza sono dei modelli di soluzione ottimali che vengono usate per risolvere dei problemi e situazione che si verificano durante la progettazione del software. I primi che definirono e studiarono dei pattern per il software furono la Gang of Four (oppure GoF, cioè un nomignolo che identifica il gruppo composto da Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides ) con il libro Design Patterns: Elementi per il riuso di software ad oggetti, scritto nel I pattern che sono stati utilizzati nel progetto sono presi proprio da libro della GoF. Il pattern Singleton definisce una classe della quale è possibile la istanziazione di un unico oggetto, tramite l invocazione a un metodo della classe, incaricato della produzione degli oggetti. Le diverse richieste di istanziazione, comportano la restituzione di un riferimento allo stesso oggetto. Figura 66 - Struttura Singleton In sostanza per avere una classe Singleton basta rendere Privato il costruttore e creare un metodo getnewinstance( ) che crea l istanza la prima volta che viene chiamato altrimenti restituisce la referenza all unica istanza di se stesso. 104