5. Sicurezza del Sistema

Anche se la maggior parte dei servizi forniti tramite la TV digitale terrestre si presentano in chiaro, ve ne sono alcuni, e molti se ne prospettano in un prossimo futuro, che richiedono l'esistenza di un sistema di controllo e, più in generale, di una gestione della sicurezza. La prima cosa che viene in mente parlando di sicurezza di un broadcasting televisivo è sicuramente la Pay-TV, ma le potenzialità dell'intero sistema sono più ampie e variegate. Nel progetto italiano, ad esempio, grande rilievo hanno le attività della Pubblica Amministrazione che ha ora la possibilità, normativa e tecnologica, di sviluppare servizi televisivi interattivi locali e regionali, nei settori di pubblica utilità. In preparazione ci sono anche servizi per transazioni bancarie e finanziarie, acquisti on-line, attività ricreative etc.

La maggior parte di questi servizi richiede un alto livello di sicurezza. Nel caso, ad esempio, di un servizio che tratti informazioni sanitarie, si dovrebbe far transitare, via etere o altro mezzo trasmissivo, quelli che la normativa sulla tutela dei dati personali indica come dati “sensibili”, la categoria più a rischio, anche sotto il profilo sanzionatorio. Per questo tipo di servizio, come si chiarirà meglio in seguito, l'idea di fondo è quella di utilizzare delle smart card per l'autenticazione dell'utente e la memorizzazione delle informazioni riservate: la carta nazionale/locale dei servizi, quella del servizio sanitario e altre concettualmente simili.

Risulta evidente, poste queste premesse, che la sicurezza di un sistema di broadcasting televisivo digitale debba considerare, oltre al sistema delle Pay-TV, anche le applicazioni ospitate dal Set Top Box e la gestione dell'interattività attraverso il canale di ritorno.

In questo capitolo, saranno presentati i principali elementi che concor­rono alla sicurezza dell'intero sistema, escludendo le comunicazioni tra un Interactive Service Provider ed il Broadcaster o tra quest'ultimo ed un Content Authoring Provider remoto, che rientrano comunque nella problematica classica di network security.

Il principale elemento del sistema è quello che controlla la visione dei programmi e, più in generale, l'accesso ai servizi: il Conditional Access System (CAS). A partire dalla procedura standard di oscuramento del segnale, il Common Scrambling Algorithm, affronteremo le problematiche della gestione delle chiavi crittografiche ed il loro legame con la personalizzazione dei servizi broadcast, le tecnologie utilizzate per l'impiego di PC Card di accesso condizionato al servizio televisivo e quelle proposte per le smart card dedicate a servizi di altro tipo. Verrà poi approfondito l'aspetto applicativo della sicurezza e la comunicazione attraverso il canale di ritorno per ottenere un'interattività avanzata.

5.1 Sistemi di Accesso Condizionato

Un Sistema di Accesso Condizionato (CAS) ha come scopo primario quello di verificare il diritto dell'utente ad usufruire di un servizio ad accesso riservato. Tipicamente si tratta di servizi soggetti ad un canone fisso, o di eventi particolari acquistabili singolarmente o a pacchetto. A volte l'accesso condizionato viene impropriamente inteso come il controllo da parte dell'utente sulla visibilità di questo o quel programma in un ambito tipicamente familiare (Parental Control). In realtà, l'unica intersezione tra questi due insiemi funzionali è l'impiego delle tabelle DVB-SI, dato che il controllo domestico si basa su un unico descrittore della tabella Event Information Table (EIT), il Parental Rating Descriptor ed il filtro sui Transport Streams viene eseguito nel STB, mentre l'accesso condizionato, come vedremo ora, ha origine presso l'HeadEnd del sistema di broadcasting.

5.1.1 Oscuramento della Trasmissione

Per rendere indecifrabile il segnale trasmesso, viene adottato un metodo detto Scrambling, in grado di produrne una rappresentazione incomprensi­bile. Il termine scrambling, rimescolamento, ricorda la sua derivazione dal campo analogico, in cui il sistema di protezione è realizzato attraverso un rimescolamento delle componenti di visualizzazione, come ad esempio il Line Translation, Line Rotation e Line Shuffling. L'uso di tale termine è utile inoltre per distinguere le operazioni di cifratura della trasmissione di­gitale e quella delle chiavi di decodifica. Alla ricezione sul Set Top Box, il segnale viene riportato nella sua versione in chiaro e rappresentato sul te­levisore. In figura (5.1) viene disegnata l'architettura di un sistema elemen­tare di scrambling e descrambling.

Nell'indicare i flussi funzionali viene qui utilizzato uno schema basato sulla codifica a livello di Transport Stream, ma l'inversione della sequenza scrambler-multiplexer non modifica la coerenza del discorso.

5.1.2 Common Scrambling Algorithm

La procedura di scrambling, denominata Common Scrambling Algorithm (CSA), è l'unica componente del sistema di accesso condizionato sviluppata congiuntamente dai membri del consorzio DVB. A causa della sua natura riservata, il sistema non è stato reso pubblico in modo dettagliato, ma le specifiche tecniche possono essere ottenute da ETSI, attraverso un processo descritto nel DVB Blue Book A011.

Anche se le informazioni principali riguardanti l'algoritmo CSA non possono essere divulgate, per garantire l'interoperabilità tra i diversi siste­mi di CA è stato rilasciato un documento [10] con l'intento specifico di definire un insieme minimo di elementi comuni dell'accesso condiziona­to, in aggiunta a quelli già definiti dal sistema MPEG-2 [4]. Lo stesso documento raccomanda che tutti gli elementi di accesso condizionato in esso definiti siano incorporati nei rice­vitori prodotti per la TV digitale.

Il Common Scrambling Algorithm è composto da un sistema di de­scrambling, il Common Descrambling System e da una tecnologia di scrambling, la Scrambling Technology. Le specifiche di ognuno di essi ven­gono distribuite separatamente e dopo la sottoscrizione di un accordo di ri­servatezza con ETSI, che ne è stato incaricato della custodia.

L'algoritmo di scrambling, utilizzato per codificare un flusso di bits nei formati MPEG-2 Transport Stream (TS) o Packetised Elementary Stream (PES), è stato pensato e disegnato in funzione della riduzione della quantità di memoria necessaria al circuito di decodifica del ricevitore, spostando, per questo motivo, la complessità al livello del codificatore, cioè all'origine del sistema di broadcast (Head-end).

Per ottenere un maggior livello di sicurezza del sistema, il Common Scrambling Algorithm è stato strutturato con una cifratura a due livelli:

• il primo livello consiste in una codifica a blocchi di 64 bits, in una modalità di concatenamento inverso

• il secondo livello realizza una codifica a flusso, con generazione pseudo casuale di byte.

Entrambi i cifrari utilizzano la stessa chiave; il cifrario a flusso usa un nonce supplementare a 64-bit, derivato dall'ultimo output della codifica a blocchi.

5.1.2.1 Lo Scrambling di TS e PES

Vediamo ora quali sono i requisiti che devono essere soddisfatti nella preparazione del formato di trasporto delle informazioni. L'algoritmo di scrambling può operare sia sul payload di un pacchetto Transport Stream, sia su una strutturazione di pacchetti PES (Packetised Elementary Streams). Conformemente con lo standard ISO/IEC 13818-1 (MPEG-2 Systems) l'intestazione (header) di un pacchetto PES non può essere codificato ed i pacchetti TS contenenti parti di un pacchetto PES codificato non possono contenere un campo di adattamento (Adaptation Field), con l'eccezione del pacchetto TS che contiene la parte finale del pacchetto PES.

L'intestazione di un pacchetto PES codificato non può essere suddivisa su più pacchetti TS. Il pacchetto TS che trasporta l'inizio di un pacchetto PES codificato è riempito dall'intestazione del PES e dalla prima parte del suo payload. In questo modo, la prima parte del payload del pacchetto PES è codificato esattamente come un pacchetto TS con un payload di ana­loga dimensione. La parte restante del payload del pacchetto PES è scom­posta in super-blocchi di 184 bytes.

Ogni super-blocco è codificato esattamente come payload di un pacchet­to TS di 184 byte. La fine del payload del pacchetto PES è allineata ri­spetto alla fine del pacchetto TS (come richiesto da ISO/IEC 13818-1 [4]) inserendo un campo di adattamento della dimensione necessaria. Se la lunghezza di un pacchetto PES non è un multiplo di 184 byte, l'ultima par­te del payload del pacchetto PES (da 1 a 183 bytes) è codificato esattamen­te come un pacchetto TS con un payload di dimensione simile. Nella figu­ra 5.2 viene presentato uno schema che descrive la mappatura dei pacchetti PES codificati in pacchetti TS.

Figura 5.2: Diagramma dello scrambling a livello PES

• Lo scrambling deve essere realizzato ad un solo livello per volta, TS o PES, ma mai simultaneamente.

• L'intestazione di un pacchetto PES codificato non può superare i 184 bytes.

• I pacchetti TS contenenti parti di un pacchetto PES codificato non pos­sono contenere campi di adattamento, con l'eccezione del pacchetto TS contenente la fine del pacchetto PES. Il pacchetto TS che trasporta la fine di un pacchetto PES codificato, può contenere un campo di adatta­mento per allineare la fine dei due pacchetti.

Questo metodo può generare un certo overhead nella velocità di trasferimento dei dati, nel caso in cui si utilizzino i campi di adattamento. In questo caso sarà necessario inserire un ulteriore pacchetto TS contenente soltanto un campo di adattamento.

Per le applicazioni che codificano Sezioni MPEG-2, si presenta il pro­blema che la sintassi specificata in MPEG-2 non include alcun bit di con­trollo della codifica. Di conseguenza la codifica delle Sezioni dovrà avve­nire al livello di TS e sarà segnalata dai bit del campo di controllo codifi­ca. Poiché le sezioni in chiaro e quelle codificate non possono essere mi­schiate in un singolo pacchetto TS, si può usare il meccanismo di riempi­mento (padding) definito da MPEG-2 per generare pacchetti TS contenenti soltanto sezioni in chiaro o soltanto sezioni codificate. Ciò significa che la fine di un pacchetto TS che trasporta una sezione sarà riempita di byte con valore 0xFF, per tenere separate, in differenti pacchetti TS, le sezioni codificate da quelle in chiaro.

5.1.2.2 L'algoritmo di Scrambling in ambiente MPEG-2

La specifica dei Sistemi MPEG-2 definisce un campo di controllo della codifica di due bits, sia nell'intestazione dei pacchetti TS che di quelli PES. La semantica dei due bit non è interamente definita, come si può verificare nella tabella 5.1. Il primo bit di controllo indica se il payload è codificato. Il secondo segnala l'utilizzo di una chiave Pari o una Dispari.

Tabella 5.1: Valori assumibili da transport_scrambling_control

La tabella successiva, 5.2, rappresenta i valori che possono assumere i bit di controllo della codifica nell'intestazione di un pacchetto PES, simili a quelli del livello TS.

Tabella 5.2: Valori assumibili da PES_scrambling_control

Per distinguere i diversi produttori dei Sistemi di CA, devono essere inserite nel campo CA_System_ID del descrittore CA alcune informazioni aggiuntive, affinché un ricevitore possa filtrare agevolmente quelle rilevanti per l'accesso condizionato. Il documento ETR 162 [37] specifica una gamma di 256 valori (8-bit) per ciascuno dei produttori dei sistemi di CA. ETSI, in qualità di custode, coordina l'allocazione dei nuovi produttori di sistemi di CA in modo che acquisiscano un interval­lo univoco e riservato di valori di CA_System_ID. Il tipico impiego degli otto bit privati assegnati ad ogni produttore è quello di indicare la versione del sistema o, anche, di differenziarsi dagli altri fornitori di Subscriber Management Sy­stems che utilizzano lo stesso sistema di CA.

5.1.2.3 Trasporto delle Informazioni di Accesso Condizionato

MPEG-2 definisce un meccanismo “a sezioni” per il trasporto delle informazioni riguardanti i diritti di accesso degli utenti contenute nei messaggi di controllo delle abilitazioni EMM (Entitlement Management Message) ed ECM (Entitlement Control Message). Questa struttura offre anche la possibilità di aggiungere nuovi dati relativi alle autorizzazioni. La sintassi di costruzione della tabella per i messaggi di CA, può essere osservata nella tabella 5.3.

Tabella 5.3: Sintassi della Tabella di Messaggio CA (CMT)

L'intestazione di CA_message_section() può essere usata per attivare un processo di selezione e filtro delle informazioni. Lo standard ISO/IEC 13818-1 [4] descrive come le sezioni debbano essere trasportate dentro i pacchetti TS. Le CA_message_sections sono trattate come le private_sec­tions di ISO/IEC 13818-1 [4], quando le si inserisce nei TS. Le sezioni del messaggio di accesso condizionato specificate in tabella 5.3 avranno una lunghezza massima di 256 bytes.

Tabella 5.4: Assegnazione degli Identificatori di Tabella (caso ECM)

La semantica dei termini della tabella CMT (CA Message Table) è la se­guente:

• table_id: valori definiti in tabella 5.4

• section_syntax_indicator: indicatore di 1 bit, sempre posto a "0"

• DVB_reserved: riservato alle applicazioni DVB per usi futuri e quindi non utilizzabile per applicazioni private

• ISO_reserved: riservato alle estensioni definite da ISO per usi futuri e quindi non specificato da DVB

• CA_section_length: campo da 12 bit che specifica il numero di byte che seguono il campo section_length fino alla fine della sezione

• CA_data_byte: campo da 8 bit che contiene informazioni riservate di accesso condizionato. Per i primi 17 bytes può essere usato per filtrare l'indirizzo.

Per CA_message_sections che trasportano tipi differenti di informazioni di accesso condizionato, è disponibile un intervallo di 16 valori del table_id. Due valori del campo table_id (0x80 e 0x81) sono riservati per la trasmis­sione dei dati di ECM. Un cambiamento di questi due valori di table_id segnala che qualcosa è cambiato nel contenuto di ECM: questa condizione di variazione può essere quindi usata nel processo di filtro delle informa­zioni di accesso condizionato [10].

5.1.2.4 Il Sistema di Descrambling

Il sistema che si occupa di eseguire l'operazione inversa sul lato della ricezione, è denominato Common Descrambling System. L'apparato dedi­cato al descrambling deve essere in grado di:

• processare in parallelo almeno sei diversi flussi di bit, codificati con differenti sistemi di accesso condizionato

• decodificare in modo selettivo i pacchetti contenuti in un Transport Stream o in un Packetised Elementary Stream (a seconda della configu­razione adottata nella codifica)

• utilizzare, per fare ciò, i valori delle Control Words inviate periodica­mente dal microprocessore.

Quando il descrambler si trova nella condizione di dover decodificare con­temporaneamente parecchi servizi, memorizza una lista di Control Words abbinate ai PID dei pacchetti di cui è richiesta la decodifica. Per ottimizzare i processi di decodifica, il descrambler non interviene su tutti quei pacchetti TS e PES i cui flag, transport_scrambling_control e PES_scrambling_control, siano impostati a “00”; quanto detto vale anche nel caso in cui il PID risulti abbinato ad una Control Word all'interno della lista [40].

5.1.3 Sottosistemi di Accesso Condizionato

Il processo di scrambling dei flussi di bits contenenti audio, video e dati, è una delle due componenti principali di un sistema di accesso condi­zionato. L'altra, è il processo di cifratura delle chiavi di descrambling, fi­nalizzato a renderne sicura la distribuzione. Un sistema end to end più complesso di accesso condizionato è però composto anche da altri sotto­sistemi:

• Subscriber Management System (SMS): è il sistema preposto a tratta­re l'Amministrazione di tutti i dati del cliente, ad esempio il numero di serie del decoder, i servizi cui l'utente ha accesso ed i termini di fattura­zione.

• Subscriber Authorization System (SAS): è il sistema di gestione dei criteri di Autorizzazione riguardanti l'abbonato, con i quali compone, sotto la guida del Subscriber Management System, i messaggi ECM ed EMM, che forniscono al sistema di accesso condizionato del ricevitore le informazioni necessarie a rendere nuovamente fruibili i servizi.

• Un sistema di controllo dell'Accesso Condizionato collocato nel ricevi­tore, che, dopo la verifica delle necessarie autorizzazioni di cui sopra, avvia il processo di descrambling e riporta in chiaro i contenuti.

Il gruppo DVB Project ha fatto la scelta ben precisa di non standardizzare i due sistemi, SMS e SAS, affinché rimanesse ai produttori la massima libertà nello sviluppo delle proprie soluzioni.

5.1.4 Architetture di Accesso Condizionato

Per codificare un flusso di bits che si presenta in formato TS o PES, l’algoritmo utilizza una Control Word, ricevuta da un apposito generatore che alterna valori pari e dispari ad intervalli di circa 2 secondi.

La Control Word viene inserita, con i criteri di accesso, in un messaggio denominato Entitlement Control Message (ECM) (fig. 5.3). Il messaggio viene cifrato ed inviato al multiplexer, il quale si occupa di inviarlo ripetutamente, in anticipo sui flussi di dati cui fa riferimento.

L'altro tipo di messaggio concernente i diritti di accesso di un utente, è l'Entitlement Management Message (EMM), ed è generato e gestito dal Subscriber Authorization System (SAS) (fig. 5.4).

Figura 5.4: Sistema di scrambling con ECMs ed EMMs

Questo tipo di messaggio autorizza un singolo utente, o anche gruppi di utenti, ad usufruire di un particolare servizio. Anche questo messaggio viene cifrato ed inviato al multiplexer. Il ricevitore utilizza i messaggi ECM ed EMM per filtrare i pacchetti autorizzati, decodificarli e riportarli ad una condizione “in chiaro”.

Completa il modello di riferimento fin qui impiegato, il Subscriber Management System (SMS) (fig. 5.5), il sottosistema che, curando gli aspetti amministrativi e le comunicazioni con il sistema di autorizzazione (SAS), è in grado di gestire l'intero processo autorizzazione/fatturazione.

5.1.5 Ciclo di Codifica e Decodifica

I passaggi più significativi di una comune sequenza di codifica possono essere così riepilogati:

• per ogni Transport Stream viene generata una Control Word

• per ogni Servizio appartenente al Transport Stream, esiste una Service Key con cui viene codificata la Control Word producendo un ECM

• se i servizi sono n, vengono prodotti n messaggi del tipo ECM

• per ogni Utente abilitato ad un Servizio, esiste una User Service Key con cui viene codificata la Service Key producendo un EMM

• se gli utenti abilitati ad un Servizio sono m, vengono prodotti m messaggi del tipo EMM e questo procedimento viene ripetuto per ogni Servizio appartenente al Transport Stream

• il Transport Stream viene codificato usando la Control Word

• i messaggi EMM ed ECM vengono inviati ripetutamente ed in anticipo rispetto al Transport Stream a cui fanno riferimento.

Per il ciclo di decodifica:

• per ogni Servizio a cui un Utente è abilitato, il relativo messaggio EMM viene decodificato grazie alla Service User Key memorizzata nel Modu­lo di Accesso Condizionato

• con la Service Key ottenuta, viene decodificato il relativo messaggio ECM, estraendo la Control Word necessaria al descrambling

• il descrambler utilizza la Control Word per decodificare il Transport Stream.

5.1.6 Coesistenza di Sistemi CA: Simulcrypt e Multicrypt

Per garantire la coesistenza tra diversi sistemi di accesso condizionato, sono stati delineati due diversi approcci possibili: Simulcrypt e Multicrypt. Il primo, inserendo in un singolo Transport Stream più di un sistema di accesso condizionato, consente a ricevitori con differenti sistemi di CA di decodificare lo stesso flusso audio e video. Il secondo, adottando un'ulteriore specifica DVB come interfaccia comune (Common Interface), consente all'utente di decodificare in sequenza trasmissioni protette da diversi sistemi di CA, semplicemente sostituendo una card di accesso.

Simulcrypt è un processo disegnato per facilitare l'utilizzo contempora­neo di differenti sistemi di accesso condizionato che non richiede un ac­cordo fra operatori, bensì un accordo di licenza fra i fornitori dei sistemi di CA coinvolti ed il broadcaster. Lo standard delinea in modo specifico quei requisiti di interoperabilità, fra due o più sistemi di accesso condizio­nato, che devono essere realizzati all'origine del sistema di trasmissione (Head-end) [42].

Da un punto di vista strettamente tecnico, il sistema realizza una sincronizzazione tra i diversi ECMs, creati con una stessa Control Word dai fornitori dei sistemi di CA, ed il medesimo Transport Stream. In fase di ricezione, questi ECMs consentono agli utenti di tutti i provider facenti parte dell'accordo, di accedere allo stesso servizio.

Multicrypt è invece una soluzione tecnologica volta a risolvere la que­stione della coesistenza tra diversi sistemi di CA presso il ricevente. Il Set Top Box, in questo caso, è dotato di un modulo estraibile, contenente il sistema di CA, che utilizza per comunicare un'interfaccia standard, la Common Interface. La sostituzione del modulo estraibile consente di cam­biare il sistema di accesso condizionato in uso ed è inoltre possibile, anche se più costoso da realizzare, averne più di uno per ogni STB.

5.1.7 Common Interface

La Common Interface, introdotta nella definizione di Multicrypt, è un'interfaccia tra un modulo estraibile contenente un sistema di accesso condizionato (CAM – Conditional Access Module) ed il ricevitore, specificata dettagliatamente dallo standard EN 50221[21]. La tecnologia adottata per il modulo di accesso condizionato fa riferimento alle specifiche dello standard PCMCIA. In particolare, viene considerato un requisito indispensabile per il Set Top Box, che accetti le carte di Tipo 1 e Tipo 2, mentre il Tipo 3 rimane opzionale, dimensionalmente diverse [21][23].

Il modulo CAM è dotato sia dei meccanismi di crittografia che di quelli di descrambling e può contenere altre informazioni, tra cui sicuramente i dati identificativi dell'utenza. In origine, il modulo di accesso condizionato era stato concepito per condividere con altri moduli analoghi lo stesso sistema di descrambling situato nel decoder ma, in seguito a valutazioni critiche sulla sicurezza di un sistema così concepito, in particolare sui flussi I/O tra STB e CAM, anche il meccanismo di descrambling è stato trasferito all'interno del modulo stesso.

In questo modo l'intero flusso dei Transport Streams MPEG 2 arriva sul modulo, su cui vengono riportate in chiaro le informazioni crittografate. Ne consegue, che tutta l'operazione di de-oscuramento avviene senza che informazioni riservate, come le parole chiave necessarie al descrambling, siano fatte circolare attraverso l'interfaccia. Questa modifica ha procurato allo stesso tempo un altro vantaggio non secondario: la Common Interface è diventata a tutti gli effetti una porta I/O attraverso cui transitano flussi di bits in formato MPEG-2, ed i moduli, risultando completamente indipendenti, diventano utilizzabili per scopi diversi e nuove applicazioni [23].

Nella realizzazione dell'interfaccia fisica della Common Interface sono individuabili due interfacce logiche:

• la prima è il Transport Stream MPEG-2 per cui sono definiti i primi due livelli, Fisico e Data Link, del modello di riferimento ISO/OSI, mentre i livelli superiori sono lasciati allo standard MPEG-2

• la seconda interfaccia è la Command Interface, che trasporta i comandi tra il decoder ed il modulo di CA e per la quale sono definiti i primi sei livelli dello stack.

Sono state successivamente introdotte [22] alcune estensioni ai protocolli della Command Interface che consentono di trasferire ai STB alcune funzionalità aggiuntive dai moduli collegati alla Common Interface. Tra queste estensioni, un esempio significativo è fornito dalla risorsa CA pipeline, che consente di realizzare una comunicazione riservata tra le applicazioni residenti sul STB ed il sistema di CA del modulo, tramite un sottoinsieme delle API standard DAVIC 1.4.1 (Parte 9) [45] integrato nella piattaforma applicativa MHP.

5.2 Sicurezza MHP

Il sistema di sicurezza DVB definito per la piattaforma MHP investe l'Autenticazione delle applicazioni e le relative Policies di sicurezza, la gestione dei Certificati e l'autenticazione e riservatezza delle comunicazioni sul canale di ritorno.

5.2.1 Autenticazione delle applicazioni

Il STB può ricevere delle nuove applicazioni dal fornitore dei servizi e deve trovarsi nelle condizioni di accertarne la validità. Il sistema di sicurezza definito per la piattaforma MHP si occupa di consentire al STB di autenticare la fonte di provenienza delle applicazioni e di tutti i files in generale. La procedura di autenticazione comunicherà al STB di quali diritti sulle risorse sensibili dovrebbe disporre l'applicazione per una sua corretta esecuzione.

Il sistema adotta tre diversi messaggi di autenticazione:

• codici crittografici Hash, per la verifica di integrità dei contenuti di files e directories,

• un codice hash master calcolato su tutti i dati, creato con chiave pubblica e firmato da un'autorità di certificazione,

• i Certificati di autenticazione.

Sono state definite tre strutture dati, corrispondenti alle tipologie dei messaggi, denominate HashFile, SignatureFile e CertificateFile, che vengono memorizzate in files all'interno al file system ed inviate al STB insieme all'applicazione.

5.2.1.1 HashFile

Un HashFile contiene un'informazione riepilogativa e codificata del contenuto di una directory, tranne sé stesso, il cui scopo è garantire l'integrità dell'informazione al momento della ricezione. Per ogni file, viene prima calcolato uno specifico codice Hash sulla base del suo contenuto e dei suoi attributi. Alla fine, il valore hash della directory viene calcolato sui valori hash del suo contenuto, ottenendo in questo modo che il suo valore sia autenticato dal contenuto stesso dell'albero sottostante.

Oltre a questo tipo di HashFile, vi è un HashFile principale, contenuto nella root directory ed ottenuto calcolando il codice Hash di tutti gli HashFiles contenuti nelle sub-directories e quello dei files della stessa root directory.

5.2.1.2 SignatureFile

La firma digitale si ottiene calcolando, con l’algoritmo indicato nel certificato della chiave privata, il codice Hash del HashFile posizionato nella root directory del file system e crittografando il risultato con la chiave privata del fornitore del servizio. Nel caso si abbiano più chiavi, è possibile creare più firme usando lo stesso codice Hash.

La firma viene quindi memorizzata in un file chiamato "dvb.signaturefile.x", in cui la “x” identifica una specifica firma, nel caso se ne possiedano più di una. Il file "dvb.signaturefile.x" è strutturato secondo lo standard Abstract Syntax Notation One (ASN.1), nella versione Distinguished Encoding Rules (DER), linguaggio dedicato alla produzione di standard ed orientato all'interoperabilità tra componenti.

5.2.1.3 CertificateFile

Il CertificateFile contiene, oltre al certificato della chiave pubblica che ha firmato il file system, una struttura gerarchica dei certificati delle chiavi pubbliche in cui un certificato sia autenticato da quello di ordine superiore fino all'ultimo, che deve essere un certificato di una root CA riconosciuto dal STB. Ad ogni certificato utilizzato durante la firma va associata la corrispondente catena di certificati, in cui la numerazione identificativa, indicata con "x" nel nome del SignatureFile, deve corrispondere a quella del nome del file dei certificati ("dvb.certificates.x").

Figura 5.7: Esempio di struttura di files ad albero autenticata

5.2.2 Policy di sicurezza per le applicazioni

La gestione dei diritti di accesso alle risorse di un STB dipendono principalmente da due fattori: i diritti richiesti dal broadcaster ed i diritti concessi dall’utente. I diritti di accesso che vengono richiesti da un broadcaster devono essere firmati insieme all’applicazione stessa. Le applicazioni non firmate godono di diritti di accesso alle risorse della piattaforma limitati. Per quanto riguarda le applicazioni firmate lo standard MHP prevede che anch’esse abbiano di default gli stessi diritti delle applicazioni non firmate. Il broadcaster può poi decidere di modificare questi permessi inserendo nello stream un file, chiamato "Permission Request File", che consente la definizione di tutti i parametri, relativi ai diritti, più significativi.

5.2.3 Gestione dei certificati

I certificati potrebbero dover essere revocati prima della data di scadenza (ad esempio se la chiave privata di un broadcaster è compromessa). A questo scopo viene creata una lista contenente i numeri seriali dei certificati revocati che, trasmessa in broadcast e opportunamente firmata, avverte i ricevitori di quali sono i certificati da ignorare. Ogni terminale che supporta MHP deve contenere un set di certificati root X509 nella memoria persistente che vengono inseriti durante il montaggio del set top box stesso. Occorre quindi avere la possibilità di modificarli. Questo viene fatto tramite un opportuno file inviato in broadcast contenente i nuovi certificati, le firme di almeno due Root CA e la lista dei certificati da eliminare. Se uno dei certificati viene compromesso, possono essere utilizzati due sistemi: la lista di certificati revocati (CRL - certificate revocation list) oppure un messaggio di modifica dei certificati (RCMM - Root Certificate Management Message).

5.2.4 Sicurezza del canale di ritorno

Le applicazioni interattive che necessitino di trasmettere dati riservati, richiedono l'impiego di un canale di comunicazione sicuro. Ad oggi, le specificazioni MHP 1.1.2 riguardanti il canale di ritorno mutuano lo standard del mondo Internet, impiegando una parte del protocollo Transport Layer Security (TLS) [41].

Le raccomandazioni in proposito coinvolgono la suite crittografica, RSA, MD5, SHA-1, DES e AES ma non le funzionalità server e la compatibilità con RSS 3.0. Con la versione 1.1.2, MHP introduce anche la parte del protocollo riguardante l'autenticazione del client, a condizione che sia fornita l'origine delle chiavi alla classe delle API Java javax.net.ssl.SSLContext attraverso un javax.net.ssl.KeyManager.

La connessione TLS richiede, per poter essere stabilita, che almeno un certificato inviato dal server faccia parte di quelli autenticati del STB. Per evitare di subire attività fraudolente, il STB non può collegarsi ad un numero diverso da quello dell'Interactive Service Provider stabilito, a meno di un esplicito consenso da parte dell'utente a fronte di una obbligatoria richiesta da parte dell'applicazione. Tale richiesta dovrà fornire all'utente almeno i dati dell'Organizzazione e del Certificato utilizzato per autenticare l'applicazione.

5.3 Smart Card

Il lettore di Smart Card è una risorsa opzionale del STB, che induce spesso a confusioni terminologiche e concettuali con i moduli di accesso condizionato, anch'essi fruibili tramite card. In realtà, sia gli standard di riferimento che le funzionalità previste risultano differenti. I lettori di smart card dovrebbero dare supporto ad un nuovo insieme di servizi “Home”, T-Government, Home-banking, T-Commerce, etc. Come abbiamo visto in precedenza, i moduli di accesso condizionato gestiscono i servizi a pagamento televisivi e si occupano della decodifica dei bit-streams MPEG-2 per riportare in chiaro il segnale.

La Pubblica Amministrazione ha definito alcuni strumenti di identificazione digitale: la Carta d’Identità Elettronica (CIE), emessa dai Comuni in sostituzione della consueta carta d’identità, e la Carta Nazionale dei Servizi (CNS), attraverso cui è possibile usufruire di servizi sanitari e fiscali, di sistemi di pagamento bancari e postali e, in generale, di quei sistemi che richiedono l'impiego della firma digitale. Il progetto della Carta Nazionale dei Servizi ha però anche tenuto conto dell'esigenza di stabilire uno standard di riferimento per tutte le successive emissioni di carte multi-servizi.

5.3.1 Componenti di una Smart Card

Le Smart card hanno svariati formati e possono appartenere a diverse tipologie: non solo quelle per PayTV, ma anche carte di credito, SIM GSM e così via. In base però ad una classificazione incentrata sulle caratteristiche hardware, le Smart Card possono essere distinte in due macro categorie: quelle dotate di sola memoria e quelle equipaggiate con memoria e microprocessore. I lettori di smart card del Set-Top Box fanno riferimento a quest'ultima.

Nella categoria dotata di CPU, le differenziazioni riguardano le altre componenti hardware, il tipo di microprocessore, la dimensione delle memorie e la possibilità di riscrittura delle stesse. Gli standard ufficiali sono definiti in ISO 7816-1, 7816-2, 7816-3 [44, 45, 24].

Quelle più comuni possiedono un processore programmabile a 8 bit ed una capacità di archiviazione (protetta) dei dati di almeno 4 KB, adatta, ad esempio, a contenere chiavi private e certificati a chiave pubblica. Solitamente, si attivano per contatto all'inserimento nell'apposito slot. Ne esistono però anche di tipo contact-less che funzionano ad onde radio. Una smart card è dotata comunemente di memorie ROM, PROM, EEPROM, RAM e di interfaccia I/O.

5.3.2 File System

Il File System memorizzato su EEPROM è basato su una struttura gerarchica. Gli elementi che lo compongono sono:

• un solo Master File: si tratta della radice del file system, può contenere sia Dedicated Files che Elementary Files

• uno o più Dedicated File: contiene gli Elementary Files, ma può contenere anche altri Dedicated Files

• zero o più Elementary File: contengono i dati veri e propri.

Gli Elementary Files si suddividono in “internal EF” e “working EF”, a seconda che possano essere utilizzati da applicazioni interne o meno alla carta stessa. Un file è identificato da un ID univoco di 2 bytes. Il Master File ha sempre come ID, in forma esadecimale, 3F00. Per indicare un particolare file comprensivo di tutto il path a partire dal Master File, si giustappongono i singoli ID intervallati dal simbolo ':'. Un elementary file potrebbe, ad esempio, essere identificato da: EF00:0001:0001.

5.3.3 API per la comunicazione

Sul versante della sicurezza, le smart card supportano l'autenticazione dell'utente attraverso un PIN (Personal Identification Number), che risulta autorizzato ad operare in base a ciò che è stato registrato sulla carta. Questo consente, ad esempio, di essere chiaramente identificati durante una sessione interattiva che utilizzi il canale di ritorno del Set Top Box, oppure di memorizzarne il profilo utente ed i parametri di configurazione della connessione.

Le applicazioni MHP, per utilizzare le smart card, devono impiegare un set di API; trattandosi di un punto chiave ridefinito solo ultimamente ed ancora, forse, soggetto a sviluppi, bisogna verificare bene la versione della piattaforma standard su cui ci si trova ad operare. Questo è lo scenario, in funzione delle versioni di MHP supportate dal STB:

• MHP 1.0.2 e 1.0.3: non prevedono la gestione di smart card

• MHP 1.1 e 1.1.1: prevedono la gestione dei lettori di smart card per il attività di commercio elettronico attraverso l'Open Card Framework for Embedded Devices Specification 1.2.2 (OCF). Non prevedono invece la gestione dei lettori di smart card per l'accesso condizionato.

• MHP 1.1.2: ha sostituito le OCF, perché non più supportate, con il set di API Java, denominato "Security and Trust Services API for Java 2 Platform, Micro Edition", (SATSA 1.0). Ha sostituito inoltre le API di comunicazione con la smart card con “SATSA-APDU” utilizzato in Java nella telefonia mobile.

5.4 Criticità del sistema di sicurezza

Dopo aver presentato i principali componenti del sistema di sicurezza di un Set Top Box, analizziamone le eventuali criticità e debolezze.

5.4.1 Sicurezza MHP

Introduciamo prima brevemente i noti criteri di sicurezza: confidenzialità, integrità, disponibilità, autenticazione e non-ripudiabilità.

• Confidenzialità: esprime la necessità che l'accesso alle risorse sia garantito solo a chi ha il diritto di utilizzarle, nelle modalità stabilite dalla propria politica di sicurezza.

• Integrità: esprime la necessità che nessun utente, anche se autorizzato, possa modificare i dati compromettendone la consistenza.

• Disponibilità: esprime la necessità che dati e risorse siano disponibili per l'uso e che non vi sia modo di distruggerli o impedirne un accesso legittimo.

• Autenticazione: consente di accertare la fonte di provenienza dei dati ricevuti.

• Non-ripudiabilità: fornisce la prova che il dato è stato inviato o ricevuto, affinché il mittente (o il destinatario) non possa rinnegarne la paternità.

Come abbiamo visto in precedenza, il modello di sicurezza di MHP divide le applicazioni in firmate e non firmate. Queste ultime hanno limitati diritti di accesso a risorse e servizi. I codici hash in MHP assicurano l'integrità dei dati e la confidenzialità, in quanto sono calcolati partendo dal contenuto e dagli attributi degli oggetti. Un Hashfile indicante gli oggetti che devono essere autenticati sarà messo in ogni elenco contenente tali oggetti. Questo meccanismo assicura che soltanto una applicazione autenticata può modificare i relativi oggetti. Inoltre, una applicazione autenticata non può modificare gli oggetti non elencati nel Hashfile che ha utilizzato per autenticarsi. Sotto autenticazione forte, solo utenti autorizzati possono aver accesso alle risorse MHP.

La non-ripudiabilità viene assicurata attraverso le firme. La firma digitale in MHP è memorizzata nella directory root del sotto albero che autentica. Il valore di firma è calcolato sul certificato in formato ASN.1 DER. Generando questa firma, una Certification Authority (CA) certifica la validità dell'informazione, in particolare il legame fra la chiave pubblica ed il proprietario del certificato. Qualunque utente che abbia firmato per una applicazione non potrebbe negare tale operazione. Questo assicura il non-ripudio. D'altra parte, la non-ripudiabilità esiste anche nella direzione opposta. Il service provider e il broadcaster non possono negare con il cliente una qualunque operazione effettuata, ad esempio nell'eventualità che tale operazione abbia danneggiato il STB del cliente.

La autenticazione delle applicazioni è fornita dalla catena di certificati e dal Root Certificate contenuto nel STB. Ciò consente al STB di accertare la fonte di provenienza delle applicazioni e di tutti i files in generale, assicurando che utenti non autorizzati non facciano uso improprio di informazioni riservate. Inoltre, nel canale di ritorno viene utilizzato il Transport Layer Security (TLS), che richiede, come visto, almeno un certificato riconosciuto dal STB, accertando quindi l'autenticità dell'applicazione e garantendo la confidenzialità delle comunicazioni grazie alla propria suite crittografica.

La condizione di disponibilità si può verificare solo con la collaborazione fra service provider e broadcaster che devono garantire la Qualità del Servizio, mentre entrambi nulla possono sul funzionamento del canale di ritorno.

Poiché Java è la piattaforma di sviluppo di elezione per MHP, può essere utilizzata la caratteristica di sicurezza sandbox, che può limitare l'accesso alle risorse di sistema. Java gioca un ruolo importante in quanto, imponendo tipizzazioni forti, non consente alle applicazioni di eseguire gli attacchi più comuni come ad esempio gli stack overflows.

Concludendo, sotto il profilo tecnico e prescindendo ovviamente dal fattore umano, il modello di sicurezza in MHP, fondamentale per lo standard DVB, fornisce una protezione adeguata ai dati degli utenti ed alle applicazioni.

5.4.2 Accesso Condizionato

Nell'accesso condizionato un ruolo fondamentale è giocato dal Common Scrambling Algorithm, delle cui specifiche il suo custode, ETSI, mantiene la riservatezza. L'algoritmo viene realizzato direttamente in chiave hardware, ma nel 2002 è apparso pubblicamente un programma software (Freedec) che ne realizzava le specifiche, immediatamente sottoposto a reverse-engineering e reso pubblico in Internet. Da quel momento sono in corso studi sulla robustezza del sistema che dimostrano come sia possibile attaccarlo. L'algoritmo si basa però, come abbiamo visto, su control words generate ad intervalli di tempo molto brevi e, finora, la rapidità del cambio delle chiavi ne impedisce un attacco utile ai fini della pirateria.

Per quanto riguarda la smart card, gli attacchi più comuni sono di tipo fisico/elettronico, mentre da un punto di vista applicativo, le comunicazioni verso il STB avvengono con le API SATSA e per il canale di ritorno, il TLS, che insieme ad MHP, rispondono adeguatamente ai criteri richiesti.