UNIVERSITÀ POLITECNICA DELLE MARCHE

Transcript

1 UNIVERSITÀ POLITECNICA DELLE MARCHE FACOLTÀ DI INGEGNERIA TESI DI LAUREA IN INGEGNERIA INFORMATICA E DELL AUTOMAZIONE Scambio di informazioni sensibili tramite canale di ritorno del digitale terrestre utilizzando Smartcard RELATORE : Prof. Aldo Franco Dragoni CANDIDATO: Jonathan Filippini Anno Accademico

2 INTRODUZIONE...4 CAPITOLO 1 LO STANDARD MHP LA PIATTAFORMA MHP ARCHITETTURA DELLA PIATTAFORMA MHP APPLICAZIONI SOFTWARE DI SISTEMA RISORSE DI SISTEMA PROFILI IL SET-TOP BOX (STB) IL CANALE DI RITORNO LE XLET L AMBIENTE JAVA DELLE XLET CICLO DI VITA DI UNA XLET CONTESTO DI UNA XLET INTERFACCIA GRAFICA DELLE XLET DIFFUSIONE NEL MERCATO ODIERNO...18 CAPITOLO 2 - LA CRITTOGRAFIA LA CRITTOGRAFIA DEI DATI LA CRITTOGRAFIA A CHIAVE PUBBLICA (ASIMMETRICA) CENNI SULLA FIRMA DIGITALE LA PKI (PUBLIC KEY INFRASTRUCTURE)...21 CAPITOLO 3 - LE SMART CARD LA SMART CARD A SUPPORTO DELLA CRITTOGRAFIA LA CNS & CIE GESTIONE DEL PROTOCOLLO DI COMUNICAZIONE GESTIONE DEL PROTOCOLLO LOGICO (APDU) LE APDU PANORAMICA SUI PRINCIPALI COMANDI UTILIZZATI GESTIONE DELLO SMARTCARD FILE SYSTEM SICUREZZA CONDIZIONI D ACCESSO E STATO DI SICUREZZA

3 BASE SECURITY OBJECT (BSO) CSE/SEO IL COPROCESSORE CRITTOGRAFICO...34 CAPITOLO 4 - OPENSC PKCS # I COMANDI DI OPENSC INTERFACCIAMENTO CON MOZILLA FIREFOX IL DEBUG DI OPENSC...39 CAPITOLO 5 - MHP SMART CARD READER PLUS IL FRONT-END GRAFICO CODICE...43 CLASSE: MHPSMARTCARDREADERPLUS...43 CLASSE: APDU...53 CLASSE: PARSERUSERSCDATA...62 CLASSE: SATSASCMANAGER...66 INTERFACCIA: SATSASCMANAGERLISTENER...68 CLASSE: SATSASCREADER...68 CLASSE: SATSASCSLOTLISTENER...74 CAPITOLO 6 - MHP HTTP COMMAND CODICE...77 CLASSE: MAIN...77 CLASSE: CONNECTION...82 CLASSE: PARSER...90 PROSPETTIVE PER IL FUTURO...92 BIBLIOGRAFIA

4 INTRODUZIONE Nella realtà odierna, siamo continuamente supportati nel vivere la vita di tutti i giorni da un uso sempre crescente della tecnologia moderna, infatti essa ci aiuta a portare avanti azioni in maniera sempre più semplificata e veloce, escludendo in modo graduale l'onere alla persona che ne fruisce. Questo treno di "benefici" però si lascia dietro una fetta, seppur minore e che tenderà a scomparire, di utenze che, data la loro caratteristica, sono per così dire escluse dal giovamento che queste tecnologie regalano all'utente medio; ci riferiamo in particolar modo alle classi più escluse che per certi versi vanno di pari passo con l'età anagrafica dell'individuo, questa tematica è propriamente riassunta nel termine Digital-Divide. Possiamo anzi puntualizzare che il termine appena menzionato fa riferimento ad una classe di apparecchi ben definita quali i televisori e la loro distribuzione del segnale che da qualche periodo si è fatta notare col termine Digitale Terrestre, esso infatti consiste nella svolta definitiva dall'analogico al digitale appunto. Per usufruire del broadcast televisivo e di tutti i servizi aggiunti, come si sa, bisogna utilizzare un decoder apposito che recentemente è direttamente implementato nelle moderne TV LCD/Plasma seppur penalizzate dall'asportazione, a seconda del produttore, dell'interfaccia a schede removibili attraverso la quale l'utente poteva "interagire". Obiettivo del tirocinio svolto, e quindi di questa tesi, è lo sviluppo di un'applicazione eseguibile sul decoder digitale terrestre (una Xlet) che permette ad un utente comune d'interagire con esso e tramite una SmartCard governativa quale è la CNS, che contiene le informazioni necessarie all'autentificazione di un utente nel mondo del World Wide Web, nonché la possibilità di instaurare una trasmissione di dati certificati e crittati, tale da poter usufruire, anche ai meno esperti, di servizi direttamente da casa; che avrebbero altrimenti richiesto la necessità di spostarsi presso gli uffici fisici presenti sul territorio. Sostanzialmente abbiamo già nominato tutti gli ingredienti che permettono lo sviluppo di un'applicazione di questo tipo, verranno esaminati nei vari capitoli tutte le specifiche tecniche a cui si è andati incontro, alcune delle quali hanno reso non facile lo sviluppo dell'applicazione, le possibilità evolutive di questo apparato e le metodologie intraprese nell'affrontare il progetto. 4

5 1.CAPITOLO LO STANDARD MHP 1.1. La piattaforma MHP I due concetti fondamentali della TV digitale sono la multimedialità e l interattività. Il DVB si è, dunque, preso il compito di definire le specifiche per un servizio televisivo multimediale che consenta l interattività con l utente tramite il canale di ritorno. Il consorzio, ha perciò definito uno standard denominato MHP (Multimedia Home Platform), al quale devono conformarsi sia i centri di emissione sia i decoder degli utenti. MHP definisce una generica interfaccia tra le applicazioni digitali interattive ed i terminali sui quali le applicazioni vengono eseguite. Un decoder compatibile MHP è una macchina capace di eseguire le primitive previste nelle API (Application Programming Interface) specificate nello standard, nascondendo alle applicazioni i dettagli sulle specifiche risorse hardware e software dello stesso decoder. Così, è possibile realizzare e modificare con molta flessibilità programmi televisivi digitali che diventano eseguibili su tutti i decoder compatibili MHP. Esistono diverse tipologie di API (librerie nelle quali sono raccolte un insieme di primitive informatiche) per MHP: - generiche: Java 1.1, che sono le seguenti: javax.tv.service e javax.service.navigation per l interazione con il servizio; javax.service.guide per la gestione dell EPG (Electronic Program Guide); javax.service.transport per la gestione dello strema MPEG-2; javax.tv.xlet che fornisce le interfacce usate dalle applicazioni (Xlet) e permette loro la comunicazione con l application manager (vedi par ); javax.media, javax.tv per il media control; - per l accesso a MPEG a basso livello: org.davic.mpeg; - per la gestione delle risorse: org.davic.resources; - per l application lifecycle: org.dvb.application; - per le comunicazioni: org.dvb.dsmcc, java.io; - per la grafica: org.havi.ui; - per la sicurezza: dvb.signature, dvb.certificate; 5

6 Per le sue peculiarità, MHP si prefigura come un elemento in grado di consentire la convergenza delle tecnologie di radiodiffusione con quelle Internet Architettura della piattaforma MHP Figura 1: Architettura della piattaforma MHP L architettura della piattaforma MHP, come mostrato in Figura 3, è definita in tre livelli: - Risorse o periferiche - Software di sistema - Applicazioni Applicazioni Un applicazione è la realizzazione di un servizio interattivo formato da moduli programmabili che richiedono funzionalità specifiche residenti nell hardware o nel software del terminale. Esse sono la parte fondamentale nella filosofia MHP. Lo standard MHP supporta diverse tipologie di applicazioni, come: - EPG (Electronic Program Guide) che si presenta come una pagina Web interattiva dedicata alla guida multimediale, alla sintonia dei programmi ed all illustrazione del loro contenuto; 6

7 - servizi di teletext avanzato, che consiste in un aumento di contenuti anche sotto forma di immagini, grafici, ipertesti, clip audio e video, giochi, rendendo questo servizio informativo del tutto analogo a pagine di siti web; - applicazioni collegate al contenuto dei programmi o sincronizzate con il contenuto televisivo, come banner pubblicitari, giochi interattivi ed altro; - servizi di e-commerce, servizi bancari, che permettono di effettuare e controllare gli acquisti da remoto, o gestire ordinarie operazioni su conti correnti, compravendita di azioni ed altro; - servizi transattivi, quali quelli forniti già su Internet da vari enti, come Poste Italiane, INPS, Ferrovie dello Stato, ASL, ecc. Questi servizi non riguardano quelli propriamente televisivi, dato che utilizzano il terminale solo come alternativa al computer; essi, però, costituiscono un esempio di convergenza tecnologica che potrà avere importanti sviluppi in futuro, specie se si potesse allacciare il decoder televisivo a canali a larga banda (ADSL e simili); - giochi. Le applicazioni possono essere di tre tipi: Residenti: forniscono servizi diversi a seconda del decoder considerato; Installabili: contengono funzionalità aggiuntive che possono integrare il funzionamento delle applicazioni residenti; Scaricabili: vengono, di solito, offerte dagli operatori di servizi televisivi per arricchire l offerta al cliente. Devono essere conformi allo standard. Figura 2: Esempi di applicazioni MHP 7

8 Software di sistema Il software di sistema comprende diversi moduli che devono essere costruiti sulle risorse informatiche del singolo decoder: - insieme di programmi (sistema operativo, programmi di gestione delle periferiche, ecc.) che usano le risorse disponibili per nasconderle alle applicazioni, fornendo ad esse una rappresentazione logica in termini di primitive software; - piattaforma nota come DVB-Java (DVB-J) che si interfaccia con le applicazioni attraverso le API MHP; essa include, a sua volta: una macchina virtuale Java JVM (Java Virtual Machine), secondo le specifiche della Sun Microsystem; pacchetti software con funzionalità generali (API Java della Sun) e specifiche (API Java per la TV, per DAVIC e per HAVI). - gestore di applicazioni (application manager), noto anche come navigatore, che gestisce la piattaforma MHP e le applicazioni che girano su di essa Risorse e periferiche Le risorse e le periferiche del terminale MHP sono standardizzate solo in parte. La dotazione standard prevede le seguenti risorse: - demodulatore hardware MPEG; - moduli di accesso condizionato; - processore; - memorie Ram e Flash, hard disk. Le interfacce, invece, sono le seguenti: - modem; - lettore smart-card; - lettore DVD. 8

9 1.3. Profili MHP Il sistema MHP ha fornito il concetto di profilo per dare una mano nell implementazione dello standard. Ogni profilo si riferisce ad una specifica area di applicazioni e conseguentemente definisce i requisiti dei Set Top Box necessari a supportarlo. Attualmente esistono tre profili MHP, definiti in due set di specifiche. Infatti dato che i primi due sono molto simili tra loro, il consorzio ha deciso di includerli nella stessa release di specifiche. I tre profili (vedi figura 5) attorno ai quali ruota tutta la piattaforma sono: Enhanced Broadcast Profile: definito nelle specifiche MHP 1.0,è designato a rispecchiare i vari modi e le funzionalità dei sistemi middleware esistenti e le applicazioni che girano su di essi. Questo profilo richiede un Set Top Box con nessuna o limitate capacità di gestione del canale di ritorno; è il profilo base e permette solamente l arricchimento del contenuto audio-video con informazioni e immagini visualizzabili e navigabili sullo schermo. Per questo motivo non sono richieste performance particolari da parte dei Set Top Box. Interactive TV Profile: definito nelle specifiche MHP 1.0, è il profilo intermedio che permette di utilizzare il canale di ritorno (di tipo PSTN, ADSL, GPRS, Ethernet, ecc.) per fornire servizi con interattività superiore rispetto al profilo base. Questo profilo, infatti, supporta anche il caricamento di applicazioni MHP tramite il canale di ritorno (ma solo dalla versione 1.1), caratteristica che nel profile Enhanced è possibile solo attraverso il canale broadcast; Internet Access Profile: definito nelle specifiche MHP 1.1, richiede un Set Top Box molto più sofisticato, con potenza di calcolo e memoria interni maggiori che nei primi due profili; permette, tramite il canale di ritorno, un interattività totale e un completo accesso ai contenuti di Internet. Il profilo Internet Access contiene un elemento HTML opzionale chiamato DVB-HTML, permettendo il supporto di HTML, CSS, DOM, EMCA Script. Questo profilo necessita di performance di alto livello essendo obbligatoria l adozione di un browser internet e di un cliente embedded nel Set Top Box. 9

10 Figura 3: MHP - Profili implementativi Lo standard di base è costituito dalla specifica MHP 1.0, questa contiene (1.0.X): - l'architettura base di MHP; - informazioni dettagliate sui profili Enhanced Broadcasting ed Interactive TV ; - diversi formati contenuti in MHP, che includono JPEG, MPEG-2 video e audio; - protocolli di trasporto, che includono DSM-CC per la trasmissione broadcast e IP per il canale di ritorno; - modelli di applicazione DVB-J; - modelli di applicazione DVB-HTML; - allegati al profilo DSM-CC, una presentazione testuale e varie API; MHP 1.0.X specifica l'ambiente dove si possono eseguire le applicazioni per la tv interattiva digitale, indipendentemente dall'hardware e dal software sottostante, che sono specifici del produttore di STB. La specifica MHP 1.0 fornisce un insieme di caratteristiche e funzioni richieste dai profili enhanced broadcasting' ed interactive broadcasting'. In seguito è stata emanata la specifica MHP 1.1 per implementare il profilo Internet Access. MHP 1.1.X contiene: - informazioni dettagliate sui profili Interactive TV ed Internet Access ; - la disponibilità per l'immagazzinamento delle applicazioni nella memoria persistente; 10

11 - download delle applicazioni mediante i canali broadcast o di interazione; - estensioni al DVB-J per supportare meglio le applicazioni e l'accesso a lettori di SmartCard non certificati; - specifiche di DVB-HTML; - supporta la gestione di plug-in interoperabili (per il supporto di formati di applicazioni non conformi); - supporto per i riferimenti bidirezionali tra il contenuto di MHP ed il contenuto internet; MHP 1.1 è stata sviluppata basandosi sulla specifica MHP 1.0 con lo scopo di supportare meglio l'uso del canale di interazione e per specificare gli elementi che promuovono l'interoperabilità con il contenuto internet. Infatti MHP 1.1 è semplicemente un'altra versione della specifica MHP 1.0, basata sugli stessi file sorgente. Perciò in gran parte il contenuto di MHP 1.0 è ripetuto in MHP 1.1. Con MHP 1.1, grazie al profilo Internet Access, le applicazioni possono controllare le operazioni basilari dei client residenti su internet (web browser, ). Per aggiungere queste funzionalità ed integrare il formato applicativo DVB-J, MHP 1.1 ha definito un nuovo tipo di applicazione opzionale: DVB-HTML, che è un linguaggio di mark-up basato su HTML; permette ad un ricevitore di presentare le applicazioni della tv interattiva digitale in HTML. Le specifiche DVB-HTML presentano le stesse estensioni e restrizioni delle specifiche del linguaggio W3C esistente Il Set-Top Box (STB) Il decoder interattivo (Set-Top Box) è l'apparecchio indispensabile per ricevere i canali digitali e utilizzare i software interattivi. Questo dispositivo permette innanzitutto la decodifica del segnale da digitale ad analogico per gli apparecchi televisivi analogici che attualmente nel nostro paese rappresentano la totalità del mercato. Infine consente di eseguire applicazioni Java grazie alla presenza di una Personal JVM embedded. Come mostra la figura seguente un decoder è formato da una parte hardware (CPU, memoria, modem, ecc.), da un sistema operativo real time e da un middleware MHP. 11

12 Figura 4: Schema hardware/software di un STB Un attore importante che troviamo all'interno del decoder è il cosiddetto navigatore (o application manager). Il suo compito è fondamentale, infatti esso si occupa di segnalare all'utente la lista delle applicazioni MHP disponibili sul canale televisivo. Inoltre se l'utente effettua una selezione da tale lista, il navigatore inizia la fase di download in memoria dei moduli relativi all'applicazione scelta. Importante sottolineare che non tutti i moduli che compongono l'applicazione verranno scaricati, infatti il download sarà relativo solo a quelli necessari alla partenza della Xlet. Successivamente e solo se realmente necessari verranno scaricati anche quelli rimanenti. Tale meccanismo ricorda il modello di caricamento delle pagine del televideo ed è pensato allo scopo di ridurre i tempi di attesa del telespettatore Il Canale di Ritorno Costituisce il supporto all'interattività e alla multimedialità. Infatti per gestire un'applicazione interattiva, il Set Top Box deve essere collegato ad un canale di ritorno. Esso è un canale bidirezionale che realizza un'interazione tra il telespettatore (colui che fruisce del servizio) ed una parte server (colui che lo concede). Un dispositivo tecnologico presente sul decoder che rende operativo il concetto di canale di ritorno definito nello standard è il modem nei decoder di fascia bassa e l'adsl, Gprs, Ethernet, etc. sui decoder di fascia alta. Nel caso di modem V90 i tempi di connessione e recupero dati sono abbastanza lunghi (30-40 sec solo per la chiamata telefonica e l'autenticazione presso un ISP), ma nel caso di connessioni "always on" come con ADSL allora gli scenari possibili sono molto più interessanti, come la possibilità di scaricare musica e video su richiesta dell'utente. 12

13 1.6. Le XLET L ambiente Java delle Xlet Le applicazioni sviluppate per MHP vengono chiamate applicazioni DVB-J. Sono scritte in Java e consistono in un insieme di classi trasmesse in broadcast. Spesso si fa riferimento a tali applicazioni con il nome di Xlet. In pratica, un applicazione Java convenzionale non si adatta bene all ambiente televisivo digitale. Questo modello presuppone l esecuzione di una sola applicazione in una data macchina virtuale, e che l applicazione stessa abbia il controllo completo del proprio ciclo di vita. In un ricevitore televisivo digitale, invece, è frequente che più applicazioni vengano eseguite nello stesso momento. A tal proposito viene considerato il funzionamento delle applet che, a differenza delle normali applicazioni, possono essere avviate da una sorgente esterna, il web browser, ed alcune di esse possono essere eseguite sulla stessa pagina web nello stesso momento. Ovviamente il sistema televisivo digitale è diverso dal Web, perciò devono essere adottati alcuni cambiamenti affinché questi concetti si adattino al ricevitore digitale. Una Xlet quindi non è un applicazione Java standard: è una particolare applicazione concepita per essere scaricata ed eseguita sui decoder interattivi; esse sono state introdotte da Sun nella specifica JavaTV, ed adottate come formato applicativo Java per MHP. Sono molto simili ad applet: come nelle applet, l interfaccia Xlet permette ad un software specifico esterno, l application manager nel caso del ricevitore MHP, di controllarne il ciclo di vita, avviando o fermando l applicazione. L interfaccia Xlet si trova nel package javax.tv.xlet. Come le classi applet, l interfaccia Xlet contiene i metodi che permettono all application manager di inizializzare, avviare, mettere in pausa e distruggere una applicazione. Poiché potrebbero esserci più Xlet che vengono eseguite nello stesso momento, esse non possono effettuare alcuni compiti che potrebbero influenzare la Java Virtual Machine; in particolare, una Xlet non deve mai richiamare il metodo System.exit() per terminare l applicazione. La differenza più importante tra applet e Xlet è che una Xlet può essere messa in pausa ed essere riavviata in un secondo momento. La ragione è semplice: nel caso di un ricevitore digitale, diverse applicazioni potrebbero essere eseguite nello stesso momento, mentre le capacità dell hardware permettono ad una sola applicazione di essere visibile; quelle non visibili perciò devono essere messe in pausa con lo scopo di mantenere le risorse libere per l unica applicazione mostrata Ciclo di vita di una Xlet Le interfacce javax.tv.xlet.xlet e javax.tv.xlet.xletcontext servono per interagire con l application manager in merito al ciclo di vita e al contesto in cui la Xlet viene eseguita. Una Xlet di fatto implementa i quattro metodi presenti nell interfaccia javax.tv.xlet.xlet: initxlet: questo metodo viene invocato dall application manager per inizializzare l Xlet; startxlet: è la funzione che serve per eseguire l Xlet; 13

14 pausexlet: usata per mettere in pausa l Xlet; destroyxlet: invocata quando l application manager termina l Xlet. Il ciclo di vita di una Xlet è dunque caratterizzato da quattro stati: Loaded: la Xlet viene creata ma non ancora inizializzata. Se durante questa fase viene rilevata un eccezione, si passa direttamente allo stato Destroyed. Una Xlet può trovarsi in questo stato solo una volta durante tutto il suo ciclo di vita. Paused: la Xlet viene inizializzata, e può trovarsi in questo stato sia dopo che il metodo initxlet ritorna con successo dallo stato Loaded, oppure dopo che il metodo pausexlet ritorna con successo dallo stato Active. In questo stato, la Xlet deve 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 applicazione abilitata a ricevere gli eventi dal telecomando. Destroyed: in questo stato la Xlet deve rilasciare tutte le risorse in uso per predisporsi alla terminazione. Figura 5: Ciclo di vita di una Xlet Una sequenza tipica del ciclo di vita può essere la seguente: 1. L application manager carica la classe principale della Xlet, su segnalazione del broadcaster, e ne crea un istanza: l applicazione si trova nello stato Loaded. 2. Quando l utente sceglie di avviare l Xlet, o un altra applicazione segnala che l Xlet deve partire automaticamente, l application manager invoca il metodo initxlet. L Xlet usa il context per inizializzarsi, ed eventualmente per richiedere alcune risorse, come le immagini. Quando l inizializzazione è completata, l Xlet si trova nello stato Paused, ed è pronta per essere avviata. 14

15 3. Una volta che il metodo initxlet ritorna con successo, l application manager richiama il metodo startxlet. Questo comporta il passaggio dallo stato Paused allo stato Active, così l Xlet sarà capace di interagire con l utente ed utilizzare le risorse necessarie per fornire i servizi per cui è stata creata. 4. Durante l esecuzione, l application manager può invocare il metodo pausexlet; questo comporta il passaggio dell applicazione dallo stato Active allo stato Paused. L applicazione potrà tornare nello stato Active richiamando il metodo startxlet: questa situazione può accadere svariate volte in tutta la vita di una Xlet. 5. Alla fine del ciclo di vita, l application manager invoca il metodo destroyxlet, che comporta il passaggio allo stato Destroyed, liberando tutte le risorse. A seguito di questa operazione, l istanza di questa Xlet non può essere più richiamata. Il costruttore della classe principale di ogni Xlet deve essere lasciato vuoto: quando il middleware avvia un applicazione, all inizio crea un istanza della classe principale. In questo modo invoca il costruttore di default, se esiste, ed esegue il codice contenuto. In realtà una Xlet possiede un altro metodo che deve essere usato per questo tipo di setup: il metodo initxlet(), che permette un controllo migliore delle operazioni. Tutte le inizializzazioni devono essere fatte nell implementazione di questo metodo. Durante l inizializzazione, se qualcosa fallisse verrebbe lanciata un eccezione, passando direttamente allo stato Destroyed Contesto di una Xlet Ogni Xlet ha a disposizione un contesto di applicazione, l XletContext, che è un istanza della classe javax.tv.xlet.xletcontext. Questo context è simile alla classe AppletContext associata ad una applet: in entrambi i casi il contesto viene usato dall applicazione per accedere alle proprietà dell ambiente circostante e per comunicare i cambiamenti di stato all application manager. L interfaccia javax.tv.xlet.xletcontext prevede i seguenti metodi: - notifydestroyed; - notifypaused; - getxletproperty; - resumerequest. I metodi notifydestroyed e notifypaused permettono ad una Xlet di notificare al decoder che l applicazione sta per terminare o per mettersi in pausa; in questo modo, il ricevitore conosce lo stato di ogni applicazione e può effettuare le azioni appropriate. Questi metodi devono essere richiamati immediatamente prima che l Xlet entri negli stati Paused o Destroyed, a causa del fatto che il ricevitore potrebbe effettuare alcune operazioni per le quali l applicazione non è detto che sia pronta. 15

16 Una Xlet può richiedere di passare dallo stato Paused allo stato Active usando il metodo resumerequest. Questo può accadere quando si verifica un certo evento, rilevato ad esempio nello stream MPEG. Questo metodo richiede che un applicazione venga fatta partire nuovamente, anche se il software del ricevitore potrebbe scegliere di ignorare questa richiesta a causa di limiti nelle risorse. Il metodo getxletproperty permette alla Xlet di accedere alle proprietà segnalate dal broadcaster. Attualmente è stata definita una sola proprietà da JavaTV e da MHP, XletContext.ARGS, che permette ad un applicazione di accedere agli argomenti che le vengono segnalati tramite AIT. Di seguito viene mostrato cosa succede quando una Xlet chiede di cambiare il proprio stato tramite l Xlet context. Si consideri una Xlet che vuole mettersi in pausa e successivamente richiede di riavviarsi. 1. Per prima cosa, l Xlet notifica al suo Xlet context che si è messa in pausa, invocando il metodo XletContext.notifyPaused(). 2. L Xlet context inoltra questa informazione all application manager presente nel middleware. 3. L application manager aggiorna il suo stato interno per notificare che l applicazione si è messa in pausa, quindi l Xlet si ferma. 4. Quando un applicazione vuole riavviare le operazioni, ad esempio perché è passato un certo tempo prefissato oppure perché l utente ha premuto un tasto, viene richiamato dalla Xlet il metodo XletContext.requestResume(). 5. Come prima, l Xlet context passa tale richiesta all application manager. 6. L application manager può quindi decidere se riavviare l applicazione oppure no. Se la riavvia, aggiorna il proprio stato interno per notificare il cambiamento, quindi chiama il metodo startxlet() sulla Xlet: come tutte le altre operazioni che controllano il ciclo di vita della Xlet, questo metodo viene richiamato direttamente dall application manager e non attraverso l Xlet context. 7. Infine l Xlet riavvierà le proprie operazioni Interfaccia grafica delle Xlet Ogni Xlet deve implementare l interfaccia Xlet, presente nel package javax.tv.xlet delle API JavaTV di Sun. Per costruire l interfaccia grafica devono essere importati altri package: - java.awt.*; - java.awt.event.*; - org.havi.ui.*; - org.havi.ui.event.*; 16

17 - org.dvb.ui.*; - org.dvb.event; Questi package servono per fornire le necessarie funzionalità grafiche ed i rispettivi eventi per implementare l interfaccia utente. In pratica, il modello grafico definito dallo standard MHP viene supportato dai package sopra citati, tra i quali spicca quello Havi. La classe fondamentale per gestire il layout su schermo è la HScene, presente nei pacchetti forniti da Havi. HSceneFactory è la classe che permette di richiamare l unica istanza HScene. Il modello grafico definito dallo standard MHP è basato su tre differenti layer. Al livello più basso si trova il Background layer, che può contenere un colore o una immagine statica (rappresentata da un particolare frame MPEG-2). Nel secondo livello è situato il Video layer, rappresentato dal flusso A/V del canale TV o da una qualsiasi altra fonte in formato MPEG- 2. Al livello più alto infine si trova il Graphic layer, che contiene la grafica creata nella Xlet, e può essere strutturato su più livelli sovrapposti. Figura 6: I layer grafici dell'mhp Questo modello grafico è supportato dai package messi a disposizione dallo standard, tra i quali quello più importante viene fornito da Havi. In tale package, il container di più alto livello nella Xlet è rappresentato dalla classe org.havi.ui.hscene, che possiede caratteristiche specifiche per i decoder digitali. La classe che ci permette di richiedere l'unica istanza della HScene è fornita dallo stesso package e si chiama org.havi.ui.hscenefactory. 17

18 Oltre ad Havi e AWT è possibile utilizzare un package specifico DVB, org.dvb.ui, dove è possibile trovare classi di utilità come la DvbColor, che permette di gestire anche le trasparenze tramite il parametro alpha, non presente nella classe java.awt.color. Il font di sistema supportato in MHP è il Tiresias. I formati grafici supportati sono: png, jpg, gif e mpg(i-frame). Gli eventi associati al telecomando definiti in MHP sono i tasti numerici, le frecce di navigazione, il tasto OK ed i 4 tasti colorati: rosso, verde, giallo e blu. Lo standard non definisce l evento per il tasto EXIT, anche se è presente sulla quasi totalità dei decoder, quindi genera degli eventi non-standard e non sempre coerenti sui vari decoder. MHP fornisce due possibilità per la gestione degli eventi nelle Xlet: il classico meccanismo java, fornito in AWT, che si realizza implementando l'interfaccia java.awt.event.keylistener.; le classi del package org.dvb.event. Le classi principali del package org.dvb.event sono la EventManager e la UserEventRepository, che gestiscono rispettivamente la registrazione degli eventi ed il repository degli eventi a cui si è realmente interessati. Questo approccio ha il vantaggio di non imporre ad una Xlet di richiedere il focus tramite la HScene, come invece prevede il modello AWT Diffusione nel mercato odierno Al giorno d oggi, la diffusione del segmento del digitale terrestre è in continua espansione, questo dimostrano i dati raccolti dalla società italiana DGTVI che è incaricata di eseguire studi di settore ufficiali. Dall ultimo bollettino emesso in data 20 giugno 2008, si evince la quota di ascolto più elevata di sempre, il 4,8%; 5,8 milioni di famiglie, ad aprile 2008, possiedono un decoder su almeno uno dei televisori presenti in casa; ed infine, la vendita di apparati riceventi, decoder e televisori integrati, ha raggiunto gli 8,3 milioni di apparecchi ad aprile Ovviamente parlando di media nazionale, si incontrano su tutto il territorio casi primeggianti come la Sardegna e la Valle D Aosta supportati dal già avvenuto Switch-off con valori come: 42,4 % e 24,3%, seguite poi dalla maggioranza delle regioni italiane, dove questo avverrà entro il Altro punto di forza della diffusione del Digitale terrestre è stata la recente inserzioni di canali, sia a pagamento che non, nel non cospicuo pacchetto disponibile tra i quali: Rai4, Raisport e Mya, Joy, Steel. Altro punto cardine che sta sempre più sostenendo il settore è l offerta di contenuti in HD, per lo più di carattere sportivo, associato alla vendita dei televisori di nuova generazione (lcd e plasma) che integrano già al loro interno il decoder. Punto a sfavore risulta essere una recente direttiva ministeriale che non obbliga i produttori a integrare anche il lettore di Smart Card, di valido utilizzo per la fruizione di servizi a pagamento, o anche di servizi T-Governament che fanno uso di tessere particolari (di cui tratteremo in seguito) per l autentificazione dell utente. 18

19 2 CAPITOLO LA CRITTOGRAFIA 2.1. LA CRITTOGRAFIA DEI DATI Crittografia vuol dire scrittura segreta. La necessità di comunicare informazioni in modo riservato si è ampliata notevolmente negli ultimi decenni grazie all avvento di internet e, alla sempre più espansione del mercato globale, includendo in questo, il notevole sviluppo di siti e-commerce. Difatti al giorno d oggi molte persone fanno uso di tecniche crittografiche spesso senza rendersene conto. La crittografia moderna deve soddisfare tre requisiti: Segretezza dei dati. Integrità dei dati. Autenticità della provenienza. Non ripudio. Essa trasforma un documento da testo leggibile ad una sequenza alfanumerica interpretabile solo con l'apposita chiave di decodifica tramite la quale è possibile eseguire l'operazione inversa e ottenere nuovamente il messaggio in chiaro; inoltre deve assicurare anche che il contenuto del dato non sia stato manomesso e che la provenienza del messaggio sia trusted (ovvero il messaggio deve contenere una firma incontrovertibile che ne attesti la provenienza), deve infine rendere impossibile che il destinatario o il mittente possa negare l avvenuta ricezione o spedizione dei dati. Un tempo, nei sistemi a chiave semplice (simmetrica), entrambi i capi della trasmissione impiegavano la stessa chiave; nei sistemi moderni, a chiave pubblica (asimmetrica), l'utente di origine e l'utente di destinazione impiegano chiavi differenti La crittografia a chiave pubblica (asimmetrica) Per cifratura si intende l operazione mediante la quale un messaggio M (messaggio in chiaro) viene trasformato in un messaggio cifrato C (crittogramma); M = f (C) La decifratura consiste nell operazione inversa, con la quale dal crittogramma si risale al messaggio in chiaro originale; C = f -1 (M) Un cifrario è un sistema di qualsiasi natura in grado di eseguire le due operazioni. Per eseguire le due operazioni è necessaria la conoscenza di un informazione supplementare, chiamata chiave. Le due funzioni precedenti quindi diventano: M = f (C,K) 19

20 C = f -1 (M,K) In una comunicazione sicura il mittente calcola il crittogramma C, applicando la funzione di cifratura al messaggio M con la chiave K. Il crittogramma può quindi essere comunicato attraverso un canale insicuro al destinatario che procederà all operazione inversa, utilizzando a sua volta la chiave K. Si capisce subito che la chiave non deve essere spedita insieme al crittogramma e in ogni caso non è consigliabile utilizzare lo stesso canale. Un sistema di crittografia a chiave pubblica richiede due chiavi complementari. Una chiave, pubblica, può essere liberamente distribuita nella rete; la seconda, privata, deve essere conservata in un luogo sicuro e mai divulgata in alcun modo. Si supponga che l'utente A voglia scambiare messaggi criptati con l'utente B. L'utente A scrive il messaggio, lo codifica con la chiave pubblica dell'utente B e lo spedisce; l'utente B decodifica il messaggio con la propria chiave privata. In questo modo viene garantita la segretezza dei dati ma viene meno l'autenticità della sua provenienza visto che un utente malintenzionato può facilmente reperire la chiave pubblica dell'utente B. Quindi bisogna aggiungere un passo nel procedimento: l'utente A prima di codificare il messaggio con la chiave pubblica di B, lo codifica con la propria chiave privata. In questo modo l'utente B che riceve il messaggio decodificherà lo stesso prima con la propria chiave privata e poi con la chiave pubblica di A. Ciò consente di verificare univocamente la provenienza del documento, ma rimane pesante dal punto di vista computazionale soprattutto per documenti di grandi dimensioni. I più noti algoritmi asimmetrici sono: RSA (Ron Rivest, Adi Shamir e Len Adleman, gli ideatori). Inventato nel 1977, si basa sulla difficoltà nello scomporre in fattori primi numeri interi di grandi dimensioni (oltre le 300 cifre). DSA (Digital Segnature Algorithm). Proposto nel 1992, è basato sulla difficoltà di risoluzione del logaritmo discreto. Un altro aspetto critico in questo sistema è l attribuzione di una chiave pubblica ad un utente con un grado sufficiente di autorevolezza. La natura stessa del problema prefigura un tipo di soluzione basata su di una struttura gerarchica di autorità di certificazione: l elemento costitutivo dell albero di certificazione è il certificato a chiave pubblica (di cui parleremo più avanti) Cenni sulla firma digitale Una firma digitale è una delle applicazioni più comuni della crittografia asimmetrica, essa consiste in un valore univoco che un particolare software crea applicando una funzione matematica e una chiave di codifica al messaggio. Recentemente, sotto opportune ipotesi, questo tipo di firma ha assunto anche un valore legale pari a quello della firma autografa. Essa conferma sia l'identità dell'autore sia il fatto che nessuno abbia manipolato il documento durante la trasmissione. Sebbene la sua denominazione può trarre in inganno, essa non è legata all entità che l appone, bensì ai dati. Innanzitutto si sceglie una funzione matematica, detta di hash, computazionalmente semplice (al fine di abbassare la complessità del calcolo) e non invertibile (in modo tale da non poter ricavare il documento originale), tramite la quale viene creata un'impronta univoca del documento, detto digest. Quest'ultimo viene cifrato con la chiave privata del mittente al fine di ottenere la firma digitale. Come accennato in precedenza, è cruciale poter attribuire ad un determinato utente una chiave pubblica, con un grado sufficiente di autorevolezza. Per risolvere questo problema si ricorre ad un infrastruttura detta PKI (Public Key Infrastructure) che garantisce l autenticità delle chiavi e ne regola la distribuzione, gestione e revoca. 20

21 La PKI (Public Key Infrastructure) Una PKI è un insieme di hardware, software, protocolli e regole che sono necessarie per fornire supporto all utilizzo su larga scala dei sistemi di crittografia a chiave pubblica. La standardizzazione a livello internazionale delle linee guida per la realizzazione di una PKI è frutto del coordinamento tra ISO (International Standard Organization) e ITU (International Telecommunication Unit). L elemento fondamentale di questa struttura è il certificato digitale, ovvero l'oggetto che associa un utente alla propria chiave pubblica. Responsabile del rilascio di questi certificati è la Certification Authority (previa autorizzazione della Registration Authority), una struttura organizzata in maniera gerarchica e basata sul concetto di certificati auto-firmati: un certificato auto-firmato è costituito dall'insieme dei dati presenti nel certificato digitale, dalla loro firma digitale e dalla chiave pubblica dell'utente; esso non ha validità legale ma viene utilizzato dalle varie certification authorities per validare le authorities di livello gerarchico inferiore creando così una catena di certificati. Il vertice della piramide è generalmente costituito da un ente fidato quale un governo o un'azienda. La generazione dei certificati non avviene mai online ma viene effettuata solo dopo la richiesta esplicita dell'utente. La Registration Authority crea le chiavi dei client, distribuisce i certificati e ne mantiene un archivio consistente; anch esse sono fornite di un certificato emesso da una qualche CA. 21

22 3 CAPITOLO SMART CARD La Smart Card è un dispositivo hardware delle dimensioni di una carta di credito che possiede potenzialità di elaborazione e memorizzazione dati ad alta sicurezza. Più in generale, il termine Smart Card sottintende un insieme di tecnologie, comprendenti circuiti integrati, microprocessori, memorie RAM, ROM, EEPROM, antenne, ecc., integrate nello stesso circuito elettrico per formare un microchip che è il "cuore" della Smart Card. Figura 7-1: struttura fisica esterna La Smart Card è costituita da un supporto di plastica nel quale è incastonato un microchip connesso ad un'interfaccia di collegamento che può essere una contattiera o un antenna. Il microchip fornisce funzionalità di calcolo e memorizzazione dati; la contattiera o l'antenna consentono al microchip di dialogare con uno speciale terminale di lettura collegato solitamente ad un computer mediante porta seriale, parallela o USB. Figura 7-2: struttura fisica interna Le caratteristiche fondamentali della Smart Card quali le dimensioni, le caratteristiche elettriche, il formato dei dati e funzionalità implementative sono standardizzate dalla normativa ISO/IEC 7816, articolata nelle seguenti sezioni: 1. Caratteristiche fisiche; 22

23 2. Dimensioni e localizzazione dei contatti; 3. Caratteristiche elettriche e protocolli di trasmissione; 4. Organizzazione, sicurezza e comandi per interscambio; 5. Registrazione dei fornitori di applicazioni; 6. Elementi di dati interindustria per l interscambio; 7. Comandi interindustria per lo Structured Card Query Language; 8. Comandi per le operazioni di sicurezza; 9. Comandi per la gestione delle carte; 10. Segnali elettronici e risposte al reset per le carte sincrone; 11. Metodi di verifica personale attraverso metodi biometrici; 15. Applicazioni per la crittografia. A supporto dell hardware viene implementato anche il lato software, ovvero un sistema operativo che implementa funzioni di base e non della Smart Card. Questo SO è proprietario dell azienda che produce le tessere e solitamente varia a seconda della tipologia e dell uso per cui è stata implementata La Smart Card a supporto della crittografia La Smart Card a microprocessore, grazie alle caratteristiche di protezione dei dati intrinseche del microchip e alla presenza di un coprocessore crittografico che gli consente di eseguire le principali funzioni crittografiche on-board, si propone come il mezzo adeguato a proteggere le chiavi private rilanciando la crittografia come supporto tecnologico di base per lo sviluppo di sistemi informatici sicuri e riproponendo in maniera decisa la firma digitale come un sicuro e insostituibile strumento per l'autenticazione e l'identificazione degli individui, per la verifica dell'integrità di insiemi di dati e per il non ripudio delle transazioni La CNS & CIE Nell ambito del territorio italiano è possibile, da qualche anno a questa parte, il rilascio da parte di organi istituzionali, quali le regioni, di una Smart Card governativa; essa è emessa come supporto sicuro per l identificazione certificata del cittadino e consente, grazie ai possibili usi citati precedentemente, l autentificazione della persona fisica su canali di trasmissione come è il web, l ecc. 23

24 Stiamo parlando della Carta Nazionale dei Servizi (CNS) e della Carta d Identità Elettronica (CIE); esse sono simili e interoperabili tra di loro. Per quanto riguarda il Sistema operativo implementato sulla Carta Nazionale dei Servizi, esso si fa carico di svolgere le seguenti funzioni Gestione del protocollo di comunicazione; Gestione del protocollo logico (APDU); Gestione dello SmartCard File System; Sicurezza: Sicurezza fisica (protezione degli oggetti di sicurezza contenuti nella SmartCard); Sicurezza logica (criteri di accesso ai file ed agli oggetti di sicurezza) Gestione del protocollo di comunicazione Il protocollo di comunicazione della Smart Card fa riferimento alla norma ISO la quale stabilisce due implementazioni possibili: modalità T=0 modalità T=1 sono tecniche asincrone, la prima sta ad indicare una modalità trasmissiva dove le informazioni scambiate sono costituite da caratteri, mentre la seconda è basata su uno scambio a blocchi di byte Gestione del protocollo logico (APDU) Il sistema operativo della carta si deve far carico di eseguire comandi che rendono la carta utilizzabile dall esterno, questo è reso possibile dai comandi APDU (Application Protocol Data Unit) e regolato dalla specifica ISO Questo protocollo è costituito da comandi di basso livello, infatti sono strutturati nella forma di sequenza di caratteri esadecimali ed hanno la sintassi come quella riassunta nell immagine x. Come riassunto nella tabella, abbiamo: Figura 8: struttura comandi APDU 24

25 il command header che riunisce la parte comando della stringa di caratteri, costituito da: (CLAss) 1 byte per la classe di comando a cui fa riferimento; (INStruction) 1 byte per il tipo di istruzione; (Parametro1, Parametro2) 2 byte costituiscono i parametri per il comando. Le field che rappresenta la lunghezza del campo data che intendiamo passare insieme al comando: (Nc) lunghezza variabile in byte. Data field che costituisce il campo dati su cui l operazione verrà effettuata: La lunghezza di questo campo fa riferimento al parametro Nc, se questo è 0, allora questo campo è nullo. Le field che rappresenta la lunghezza della risposta che si vuole ottenere in accordo con le specifiche sui comandi (Ne) lunghezza variabile in byte, può essere nullo se il comando eseguito non genera risposta Inoltre sono presenti 2 byte di risposta: status word 1 & 2 (SW1, SW2) che vengono generati dal sistema operativo della carta che ci danno indicazione sull eventuale successo o insuccesso dell operazione svolta o specificando il tipo di errore incontrato durante il processo. Questi codici sono mostrati sotto, quello posto in risalto segnala la buona riuscita del comando. Figura 9: status word SW1 SW2 Description SW1 SW2 Description Authentication Failed 16 6A 81 Function not supported Memory Error 17 6A 82 File not found Invalid Lc value 18 6A 83 Record not found Logical Channel not supported 19 6A 84 Not enough memory Chaining Error 20 6A 85 Lc inconsistent with TLV structure File type inconsistent with command 21 6A 86 Incorrect P1-P Security status not satisfied 22 6A 87 Lc inconsistent with P1-P Authentication method blocked BSO blocked 23 6C 00 Le inconsistent with expected data Referenced BSO is invalid 24 6D 00 INS is invalid Condition of use not satisfied 25 6E 00 CLA is invalid No current EF selected or Command not allowed 26 6F 00 General Error Expected SM data object missing 27 6F 86 Key object not found Invalid SM data object 28 6F 87 Chaining Error Logical Channel not supported 29 6F FF Internal Error 15 6A 80 Incorrect parameters in data field Command successful Figura 10: tabella Status Word 25

26 3.2.3 Le APDU Se volessimo vedere più nel dettaglio questi comandi, notiamo subito una classificazione di questi in base alla tipologia di operazioni che effettuano sulla carta: Comandi di tipo amministrativo Create File, Invalidate File, Delete File.. Put Data (per settare gli attributi dei file e degli oggetti di sicurezza) Change Reference Data (amministrazione del PIN) Comandi di utilizzo del File System Select File Read, Update,Append Comandi di identificazione ed autenticazione Verify PIN, Get Challenge, External Auth., Internal Auth... Comandi crittografici MSE (Manage Security Environment) PSO (Perform Security Operation) PSO_CDS (Compute Digital Signature) PSO_Encrypt/Decrypt Panoramica sui principali comandi utilizzati a) SELECT figura 11: campi P1 e Data del comando SELECT 26

27 b) READ BINARY Figura 12: comando Read Binary P1 e P2 rappresentano l offset di lettura da intendersi all interno del Trasparent File, mentre Le il numero di byte da leggere; si possono leggere solamente 256 bytes alla volta, nel caso di file più bisogna effettuare più cicli consecutivi di lettura cambiando ogni volta l offset. c) READ RECORD Figura 13: comando Read Record I parametri identificano il metodo d accesso ai records e lo spostamento del puntatore di riferimento. d) VERIFY Figura 14: comando Verify Si fa carico di verificare i dati spediti alla carta con quelli salvati su di essa (es. PIN) ed eventualmente impostare il stato di sicurezza relativo al risultato ottenuto. e) MANAGE SECURITY ENVIROMENT MODALITA RESTORE: Figura 15: comando MSE 27

28 Usa il backtracking per cercare il SEO fornito in P2 Se è andato a buon fine, imposta il CSE per utilizzare i comandi di crittografia MODALITA SET: valida solo nel caso in cui un CSE sia stato caricato nella RAM da un precedente MSE modalità restore. Figura 16: parametri relativi al comando MSE f) PERFORM SECURITY OPERATION PSO_DEC: si fa carico di decifrare il dato di input con chiave simmetrica o asimmetrica PSO_ENC: esegue la crittazione del dato di input con la chiave selezionata PSO_CDS: calcola la firma digitale (digital signature) del dato d ingresso Figura 16: comandi PSO_XXX Gestione dello Smartcard File System Il File system della Smart Card è strutturato un po come quello di un computer, esso infatti presenta una struttura gerarchica costituita da una cartella radice (MF Master File) a cui si connettono elementi che 28

29 potremmo paragonare a cartelle (DF Directory File) e file (EF Elementary File); ogni elemento presente è identificato univocamente da una stringa di 2 byte ed è grazie al quale che siamo in grado di utilizzarlo. Figura 17: esempio di File Sytem Una sostanziale differenza che incontriamo è la tipologia di struttura che può assumere un Elementary File, infatti esso ha 4 differenti possibilità: Transparent EF: sequenza di byte risulta non formattato, l accesso ai dati è per offset e lunghezza. Linear Fixed EF: consiste in record di lunghezza fissa, l accesso ai dati è per numero di record. Linear Variable EF: consiste in record di lunghezza variabile, l accesso ai dati è per numero di record. Cyclic EF: record di lunghezza fissa, l accesso in lettura è per numero di record, la scrittura è sul record successivo all ultimo record aggiornato. Figura 18: Tipi di Elementary File Oltre alle varie tipologie di strutture che abbiamo già esplicato, questo supporto definito sicuro, contiene al suo interno informazioni di carattere generale e privato, quindi non divulgabile, della persona che ne è in possesso; troviamo infatti al suo interno le generalità, il certificato e la chiave pubblica, la chiave privata, il 29

30 PIN e il PUK, più le informazioni rilegate al supporto vero e proprio come la memoria, il processore ed i servizi installati. M F P I N _ C N S P U K _ C N S D F 0 E F _ D a t i p r o c e s s o r e E F _ I D _ C a r t a P I N _ S O K p r i D F 1 E F _ C _ C a r t a E F _ D a t i p e r s o n a li D F 2 E F _ D a t i p e r s o n a l i a g g i u n t iv i E F _ M e m o r i a r e s id u a E F _ S e r v i z i in s t a l la t i E F _ I N S T _ F I L E I N S T p u b K ia K ic D F _ S e r v i z i o # 1 D F _ S e r v i z i o # 2 D F _ S e r v iz io # N D F F ir m a d ig it a l e D F N e t li n k E F - G D O N e t li n k Figura 19: Fyle sytem CNS Sicurezza Per quanto concerne la sicurezza è la custodia dei dati contenuti nelle Smart Card, questo è un obiettivo di primaria importanza ed è stato perseguito tramite due stadi di approccio: sicurezza fisica sicurezza logica La sicurezza fisica è l insieme delle contromisure messe in atto per proteggere le informazioni da attacchi condotti tramite un utilizzo improprio dell interfaccia elettrica, azioni fisiche volte a guadagnare il controllo diretto del microprocessore, o un analisi dell assorbimento elettrico. Per evitare queste problematiche sono state attuate le dovute contromisure come: Sensori che rilevano la marginatura della tensione di alimentazione, Sensori che rilevano la marginatura del clock, 30

31 Sensori di temperatura di esercizio, Sensori ottici. In particolare l analisi dell assorbimento elettrico consiste nel mettere in relazione le variazioni di consumo di tensione, dovute alla commutazione dei transistor, con i processi svolti dal microprocessore. Una contromisura efficace adottata dai costruttori di Smart Card consiste nel disaccoppiare il clock fornito all interfaccia dal clock del microprocessore e variarne in modo casuale la frequenza durante processi di calcolo interno. La sicurezza logica si fa carico invece di controllare l accesso diretto alle informazioni contenute nella Smart Card, questo controllo viene effettuato tramite: verifica di codici d accesso personali come il PIN, processi di autenticazione realizzati con tecniche crittografiche simmetriche o asimmetriche, funzioni che consentono di rendere non modificabili ed accessibili in sola lettura alcuni dati, funzioni che consentono di rendere non esportabili gli oggetti di sicurezza (chiavi e codici di accesso). Il PIN consente di verificare il possesso della Smart Card, ad esso possono essere associate condizioni di accesso ai file e condizioni di utilizzo degli oggetti di sicurezza; possono inoltre essere definiti più PIN. Le Chiavi crittografiche simmetriche ed asimmetriche consentono di realizzare processi di autenticazione i quali possono essere vincolati da condizioni di accesso ai file; queste possono essere usate anche per produrre crittografia da utilizzare all esterno della Smart Card (p.e. Firma Digitale). L'architettura di sicurezza logica è basata sui seguenti componenti: Current Security Status: registra le Condizioni d accesso (AC) garantite in ogni istante; Access Conditions (AC): informazioni che collegano l oggetto, le operazioni di controllo e le regole da applicare; Base Security Objects (BSO): Contenitori di dati segreti/sensibili, sono usati nelle operazioni di crittografia e per la verifica delle AC alle risorse della Smart Card; Current Security Environment (CSE): set di riferimenti al SO che verranno usati per eseguire comandi Perform Security Operation; Security Environment Object (SEO): il CSE viene inizializzato copiandovi i valori contenuti nel SEO L utilizzo forzato di questi componenti non permette al programma che si interfaccia con la Smart card di bypassare i controlli di autentificazione che la crittografia instaura. 31

32 Figura 20: esempi di condizioni d accesso Condizioni d accesso e stato di sicurezza Ogni comando ha condizioni di sicurezza specifiche da soddisfare per la sua utilizzazione; l informazione che collega l oggetto, l operazione da controllare e le regole da applicare è l Access Condition (AC). Una condizione d accesso relativa ad un oggetto è raggruppata in una stringa di byte attaccata logicamente all oggetto, dove ogni byte è associato ad una operazione o gruppo di operazioni e può assumere i seguenti valori: 00h := ALWAYS 01h 1Fh := ID o BSO FFh := NEVER La carta mantiene uno stato di sicurezza interna (Current Security Status) che registra quale AC è garantita in un dato istante. Lo stato di sicurezza corrente può essere considerato come un set di condizioni booleane, una per ogni test BSO da usare. Per default al reset della carta, tutti i diritti di accesso sono nello stato non garantito ; i comandi VERIFY, EXTERNAL, AUTHENTICATE, RESET RETRY COUNTER possono cambiare lo stato di sicurezza corrente, garantendo alcuni diritti, cambiando il valore di alcune condizioni booleane date. 32