Progettazione e realizzazione di un sistema DRM utilizzando SSL e GStreamer

UNIVERSITÀ DEGLI STUDI DELL’AQUILA Facoltà di Scienze MM.FF.NN. Corso di Laurea di I Livello in Informatica TESI DI LAUREA Progettazione e realizzazione di un sistema DRM utilizzando SSL e GStreamer Laureando Relatore Lorenzo Sfarra Prof. Vincenzo Fazio Anno Accademico 2008-2009

2 Indice 1. Introduzione ...........................................................................................................................2 2. Architettura DRM..................................................................................................................5 2.1 Tecnologie utilizzate..............................................................................................................6 2.2 I componenti del sistema........................................................................................................7 2.2.1 Account Server....................................................................................................................8 2.2.2 DRM Server........................................................................................................................9 2.2.3 Client...................................................................................................................................9 2.3 Casi d'uso.............................................................................................................................11 2.3.1 Ricerca e Download..........................................................................................................11 2.3.2 Esempio.............................................................................................................................12 3. GStreamer, codificatore e player multimediale.................................................................14 3.1 GStreamer............................................................................................................................14 3.2 Il plugin per criptare/decriptare file multimediali................................................................16 3.3 Integrazione di GStreamer nel player e nel codificatore......................................................19 4. Sistema realizzato.................................................................................................................24 4.1 Account Server.....................................................................................................................24 4.1.1 Gestione utenti: registrazione e autenticazione, LDAP....................................................24 4.1.2 Dialogo con client e DRM Server....................................................................................26 4.1.3 Registrazione/Eliminazione di un utente dal sistema.......................................................26 4.2 DRM Server.........................................................................................................................27 4.2.1 Aggiunta di un nuovo elemento multimediale..................................................................27 4.2.2 Ricerca di file multimediali...............................................................................................28 4.2.3 Download di un file multimediale....................................................................................29 4.3 Client....................................................................................................................................29 5.Conclusioni............................................................................................................................30 6.Bibliografia............................................................................................................................33 7.Ringraziamenti......................................................................................................................34

3 1. Introduzione « Before I speak, I have something important to say». – Groucho Marx Viviamo in un'epoca in cui l'accesso a informazioni, notizie, file multimediali e qualsiasi altro genere di dati ha raggiunto, parallelamente alla diffusione di forme di telecomunicazione sempre più evolute e veloci, livelli di divulgazione importanti, che garantiscono una copertura mondiale quasi totale in tempi molto rapidi, spesso in real-time. Questo scambio di una quantità imponente di dati tra un numero molto elevato di utenti è supportato al meglio dal modello di rete peer-to-peer (P2P): una rete informatica che non possiede nodi gerarchizzati come client o server fissi (clienti e serventi), ma un numero di nodi equivalenti (in inglese peer) che fungono sia da cliente che da servente verso altri nodi della rete. Questo comporta numerosi vantaggi: prima di tutto viene evidenziato quello che è uno dei pilastri della diffusione di Internet, ovvero lo scambio di informazioni nella massima libertà. Inoltre la velocità di trasmissione risulta superiore rispetto a una rete client-server in quanto l'informazione richiesta può essere reperita in più peer invece che in un'unica fonte: in contrasto con il sistema client-server, in cui più utenti connessi al server producono una riduzione della velocità, il sistema P2P è tanto più efficace tanti più sono gli utenti connessi, senza inoltre dover acquistare macchinari con potenzialità elevate con costi altrettanto elevati per sostenere tutti gli accessi. La validità di quanto appena affermato è confermata, ad esempio, da alcune idee che sfruttano il P2P per i vantaggi appena elencati: ci si riferisce per esempio alle P2P TV, che permettono la diffusione in tempo reale di contenuti quali film o programmi televisivi, sfruttando la banda di trasmissione dei singoli utenti che viene riutilizzata per trasmettere anche agli altri fruitori.

4 Questo efficiente modello di scambio dati introduce però un problema molto attuale, il problema dei diritti di proprietà intellettuale. Tra i file maggiormente condivisi troviamo i file multimediali, ed è questo il motivo per cui le etichette discografiche e i media hanno valutato, e valutano tuttora, il P2P come una minaccia per il loro modello industriale, a tal punto che alcune di esse (come MPAA, RIAA) hanno portato avanti delle battaglie legali contro dei sistemi P2P, a volte con successo (caso Napster). Le maggiori imprese titolari dei diritti di proprietà intellettuale sulle opere digitali, hanno cercato diverse soluzioni al problema: in collaborazione con alcune imprese produttrici di hardware e software, stanno costruendo e diffondendo tecnologie di gestione e protezione dell’informazione. Queste tecnologie sono attualmente conosciute con la locuzione “Digital Rights Management” (DRM). I sistemi DRM proteggono il materiale da distribuire criptandolo con delle chiavi di cifratura, predisponendo un attento meccanismo di distribuzione delle stesse agli utenti, con lo scopo di certificare che chi effettivamente usufruisce di un determinato file sia autorizzato a farlo, avendolo acquisito legalmente. Un altro obiettivo di questi sistemi, di cui si fornisce un prototipo in questa tesi, è quello di non rinunciare al peer-to-peer pur garantendo i diritti di proprietà intellettuale. Un esempio importante di download legale di file musicali è rappresentato da iTunes sviluppato da Apple Inc., che tramite il sistema ClickAndBuy1 permette di scaricare attraverso Internet dall'iTunes Store, il cui accesso è completamente integrato nel client iTunes: quasi tutti i file multimediali scaricati sono protetti attraverso una tecnologia Apple chiamata FairPlay, che implementa appunto la gestione dei diritti digitali secondo questo processo: 1. i file protetti sono contenitori MP4 con flusso audio cifrato AAC: per la cifratura è utilizzato l'agoritmo AES in combinazione con la funzione hash MD5; 2. c'è una master key che è necessaria per cifrare e decifrare il flusso audio e che è memorizzata anch'essa, in forma cifrata, nel file MP4; 1 Sistema di pagamento online: http://www.clickandbuy.com/

5 3. ad ogni download su iTunes da parte di un utente corrisponde la creazione di una user key generata in modo casuale che viene usata per cifrare la master key, e viene poi memorizzata insieme alle informazioni dell'account utente sui server Apple, e inviata al client iTunes, che la memorizza in un archivio cifrato; 4. grazie a questo archivio il client iTunes può recuperare la user key, decifrare con essa la master key, e decifrare con la master key ottenuta il file multimediale per riprodurlo. La soluzione proposta in questa tesi è ispirata proprio allo schema di iTunes appena descritto, in quanto anch'essa sfrutta due chiavi di cifratura, la master key per cifrare il file multimediale e la user key per cifrare la master key; tuttavia presenta delle varianti che verranno spiegate nel corso del documento. Il modello proposto prevede inoltre l'integrazione del servizio DRM in un sistema peer-to- peer pur se non implementato nell'attuale release del sistema. Per quanto riguarda la riproduzione del file multimediale, è stato creato un lettore multimediale apposito (player) che utilizza GStreamer con un plugin sviluppato in una tesi precedente e modificato in alcune sue componenti. Il plugin è utilizzato anche per il processo inverso, ovvero criptare un file multimediale con una determinata chiave. Questo processo viene svolto su quello che verrà indicato come DRM server nel seguito, che è il processo che detiene tutti i file multimediali criptati e tiene traccia dell'associazione file multimediale ← → master key. L'architettura si completa con l'Account Server che gestisce gli utenti del sistema, dalla registrazione all'autenticazione e alla fase di accesso al servizio.

6 2. Architettura DRM « Do what you can, with what you have, where you are.» – Theodore Roosevelt Abbiamo analizzato nell'introduzione il funzionamento del sistema DRM proposto da Apple, FairPlay, in quanto costituisce il modello di riferimento per il lavoro svolto in questa tesi, anche se in alcune parti ci si distacca dal modello per gestire i sistemi peer-to-peer. In questa sezione verrà analizzata l'architettura DRM scelta e verranno spiegati alcuni dettagli di implementazione, approfonditi nei capitoli successivi di questo documento. 2.1 Tecnologie utilizzate Le tecnologie utilizzate per la parte relativa al server DRM, di cui ora parleremo, sono: • un database MySQL che si occuperà di tenere traccia dell'associazione file multimediale ← → master key, dove master key è la chiave usata per criptare file multimediale; • la libreria C libmysqlclient che viene utilizzata nel codice per effettuare tutte le query necessarie sul database, inserendo nuove voci e recuperando i dati che stiamo cercando; • la libreria OpenSSL (libssl), che è utilizzata in tutte le comunicazioni del progetto per cifrare il traffico, in modo che nessun dato possa essere sniffato dall'esterno; • GStreamer (libgstreamer-0.10), libreria utilizzata per la riproduzione e la manipolazione di flussi dati multimediali;

7 • GObject (glib-object fornito con la libreria libglib2.0) utilizzato sia per le parti relative a GStreamer, sia per le parti che riguardano l'interfacciamento verso il database e la comunicazione in rete tramite il formato di scambio dati JSON2. La serializzazione di un oggetto GObject nel formato JSON e il processo inverso sono eseguiti tramite la libreria json-glib3. 2.2 I componenti del sistema Il sistema può essere schematicamente suddiviso in tre componenti principali, analizzati in questo capitolo e rappresentati nella seguente figura: 2 JavaScript Object Notation: http://www.json.org/ e RFC 4627: http://www.ietf.org/rfc/rfc4627.txt 3 http://live.gnome.org/JsonGlib

8 L'Account Server e il DRM Server potrebbero risiedere sulla stessa macchina, ma sono rappresentati come due entità separate e in esecuzione su due macchine distinte per una questione di leggibilità dello schema. 2.2.1 Account Server L'Account Server svolge diversi compiti: il primo è la gestione degli utenti, fornendo i servizi di registrazione, eliminazione e autenticazione. È il punto d'entrata del sistema per un nuovo utente che, tramite il client analizzato in seguito, prima di accedere ai servizi di ricerca e download comunica all'Account Server la sua volontà di registrarsi, fornendo le credenziali che lo identificheranno univocamente. A processo di registrazione terminato con esito positivo l'utente potrà procedere con l'autenticazione e conseguentemente con la fruizione di tutti i servizi offerti. È ovviamente responsabile anche del logout degli utenti e della loro eliminazione dal sistema. Un'altra funzione svolta è relativa allo smistamento delle richieste tra il client e il DRM Server, introdotto nella prossima sezione, e delle risposte elaborate dal DRM Server verso il client: un esempio importante da questo punto di vista è l'invio della user key ricevuta in precedenza dal DRM Server, al client.

9 2.2.2 DRM Server Il DRM Server è il processo che si occupa di gestire i file multimediali e la loro distribuzione nel sistema. Uno dei compiti svolti è quello di criptare un nuovo file che si vuole aggiungere alla rete (introdotto teoricamente dalle case discografiche, aziende software, e così via), creando una nuova chiave definita master key, che verrà associata al file: le informazioni verranno quindi salvate su un database MySQL, precisamente in una tabella rappresentata nella figura che segue: Il campo media conterrà i metadati del file in questione, il cui percorso reale sul filesystem è indicato nel campo real_path. A questo punto il DRM Server è in grado di rispondere alla richiesta di ricerca da parte del client cercando proprio nel campo media, ed alla richiesta di download creando in maniera casuale una user key che verrà associata alla transazione corrente e con cui criptare la master key da inviare. 2.2.3 Client Gli utenti che vogliono accedere al sistema utilizzano il client appositamente progettato, i cui compiti vanno dalla registrazione e autenticazione nel sistema, alla ricerca e il download dei file multimediali, fino alla loro riproduzione. Il funzionamento e lo schema rappresentativo delle operazioni relative alla gestione degli utenti sono riportati nel paragrafo 2.2.1: l'utente procede alla registrazione e all'autenticazione tramite l'Account Server per poter usufruire dei servizi offerti dal sistema, come effettuare il download di un file multimediale a seguito di una ricerca. Per questo scopo effettuerà :

10 1. il download del file criptato con la master key dal DRM Server; 2. il download della master key criptata con la user key dal DRM Server; 3. il download della user key dall'Account Server, il quale ha parallelamente richiesto quest'ultima al DRM Server; 4. il processo per decriptare la master key criptata con la user key; 5. il processo per decriptare il file multimediale con la master key ottenuta al punto 4 e riproduce il file multimediale. La figura che segue analizza quanto riportato, omettendo le richieste dal client verso i due server:

11 2.3 Casi d'uso 2.3.1 Ricerca e Download La ricerca e il download sono le operazioni che chiamano in causa tutte le componenti del sistema. I passi che contraddistinguono il download di un file sono i seguenti: 1. Il client effettua l'accesso e una volta autenticato (sezione 4.2) sceglie nel menù di effettuare una ricerca; 2. l'Account Server riceve la richiesta del client e invia i criteri della ricerca al DRM Server; 3. il DRM Server effettua una query sul database e invia i risultati della ricerca all'Account Server, il quale a sua volta li inoltra al client; 4. il client indica il file che vuole scaricare, invia la richiesta all'Account Server e apre una nuova connessione direttamente con il DRM Server; 5. l'Account Server riceve la richiesta del file da scaricare, e lo comunica al DRM Server; 6. il DRM Server crea casualmente una chiave, la user key, cripta la master key associata al file prescelto dall'utente con la user key e infine invia la user key all'Account Server; 7. il DRM Server risponde inoltre alla richiesta di connessione da parte del client e gli invia il file multimediale criptato con la master key, e la master key criptata con la user key; 8. il client, dopo la ricezione dei dati dal DRM Server, richiede e scarica la user key dall'Account Server;

12 9. a questo punto il client decripta la master key cifrata dalla user key ed esegue il riproduttore multimediale che decripterà il flusso dati del file multimediale con la master key, e verrà quindi riprodotto. 2.3.2 Esempio Analizziamo il caso in cui un client richieda un file multimediale, e prendiamo l'esempio di una entry nel database definita come segue: id: 5, media: artista5 canzone5 album5, masterkey: thiskeyisverybad, real_path: /percorso/file.mp3 Il client, una volta autenticato, sceglie di effettuare una ricerca e indica come termini, ad esempio, “canzone 5”. La sua richiesta arriva all'Account Server che la inoltra al DRM server, il quale effettua una ricerca sul database e trova la entry del database corrispondente. A questo punto invia all'Account Server il risultato, che viene inoltrato nuovamente al client. Se il client decide di scaricare il file, avvisa sia l'Account Server che il DRM server: l'Account Server si collegherà nuovamente al DRM Server e chiederà la generazione di una user key da associare all'utente in questione e al file multimediale richiesto (utilizza per questo una lista linkata che rappresenta una coda di download), e riceve questa chiave. A questo punto il DRM Server “aspetta” la connessione del client che scaricherà direttamente dal DRM Server sia il file multimediale criptato tramite la master key, che la master key stessa criptata tramite la user key. A questo punto l'utente scarica la user key dall'Account Server, decripta la master key con la user key, e può utilizzare il suo player multimediale per riprodurre il file appena scaricato, passando al player il file e la master key. Un fattore importante è che in questo sistema il client non salva mai né la user key, né tantomeno la master key. Questo vuol dire che, nel caso in cui l'utente sia già in possesso del file in questione, l'unica cosa che deve scaricare è la user key dall'Account Server e la master key criptata con la user key dal DRM Server, il che richiede un traffico di dati dell'ordine di pochi bytes, quasi irrilevante, e una scelta condivisibile considerando che al giorno d'oggi moltissimi dispositivi dispongono di una connessione anche se si è sempre in movimento.

13 Quale sviluppo futuro del sistema, potrebbe essere una buona idea la creazione di un client DRM che si connetta al server DRM per inviare il file multimediale, che teoricamente permetterebbe alle case discografiche autorizzate di effettuare l'upload in modo del tutto autosufficiente. L'aggiunta di questo meccanismo nel sistema potrebbe appoggiarsi al sistema di autenticazione già esistente che è stato introdotto precedentemente: essendo basato su LDAP una modifica allo schema iniziale potrebbe creare un gruppo di utenti speciali dedicato proprio all'upload dei file nel sistema.

14 3. GStreamer, codificatore e player multimediale «La musica esprime ciò che non può essere detto e su cui è impossibile rimanere in silenzio.» – Victor Hugo 3.1 GStreamer In breve, l'idea principale sulla quale si basa GStreamer è il concetto di pipeline, ovvero una sequenza di elementi collegati tra di loro: un elemento source viene utilizzato per ricevere l'input da fonti esterne (da un file, dalla rete, e così via), e attraverso un source pad (canale di output) si connette ad altri elementi. La rappresentazione grafica di un source element è la seguente: 4 Il source element si connette ad altri elementi chiamati elementi filter che hanno lo scopo di lavorare sui dati che ricevono sul loro sink pad (canale di input, può essere più di uno) e inviarli al loro source pad (può essere più di uno). 4 Immagini prese dalla documentazione ufficiale di GStreamer, sul sito http://gstreamer.freedesktop.org/

15 Un filter element viene rappresentato nel seguente modo (prima immagine con un solo source pad, seconda con due source pad): Ogni elemento filter è collegato con altri elementi filter oppure con un elemento sink, che si occupa di inviare i dati provenienti dall'elemento che lo precede nella pipeline su fonti esterne (su un file, sulla scheda audio, in rete, e così via) e rappresenta l'elemento finale della pipeline stessa. La rappresentazione di un sink element è la seguente: Il collegamento di un elemento source, uno o più elementi filter e un elemento sink costituiscono quindi la pipeline. GStreamer è scritto interamente in C per diversi motivi: portabilità, velocità, e la possibilità di utilizzare GObject, un framework per la programmazione orientata agli oggetti in C fornito da Glib. Questo ultimo punto è particolarmente rilevante dato che tale framework è stato utilizzato in molti ambiti nel codice del sistema implementato per questa tesi, non solo nella parte relativa all'uso di GStreamer stessa. GStreamer fornisce tutti gli strumenti necessari per costruire ed eseguire una pipeline da linea di comando, come lo strumento gst-launch. Un esempio pratico di riproduzione di un file MP3 è il seguente:

16 $ gst-launch filesrc location=music.mp3 ! mad ! audioconvert ! audioresample ! osssink che riproduce il file “music.mp3” usando un plugin basato su libmad (decoder audio MPEG), collegandolo all'elemento audioconvert e all'elemento audioresample che si occupano di convertire l'audio in una forma compatibile con l'audiosink specificato, in questo caso osssink che sfrutta un dispositivo OSS5. 3.2 Il plugin per criptare/decriptare file multimediali Il plugin “lamedrm” creato per criptare/decriptare i file multimediali utilizza l'algoritmo AES (standard del Governo degli Stati Uniti), e farà quindi parte di quella catena di elementi appartenenti alla pipeline per processare il flusso di dati. Possiamo analizzare l'esempio in cui vogliamo utilizzarlo per criptare un file multimediale con una data chiave. Il comando gst- launch: $ gst-launch filesrc location=music_in.mp3 ! lamedrmenc sslkey=thiskeyisverybad ! filesink location=music_out.mp3 prende in input un file MP3 (music_in.mp3), invia il flusso di dati al plugin “lamedrmenc” che si occupa di criptarlo con la master key che impostiamo con il parametro “sslkey”, e infine invia il flusso di dati criptato all'elemento finale che si occupa di scriverlo in un file (music_out.mp3). Possiamo quindi vedere la rappresentazione grafica della pipeline descritta dal comando appena visto: 5 Open Sound System, interfaccia per piattaforme Unix per modificare e catturare suoni.

17 Questo è esattamente lo schema della pipeline che viene utilizzata dal DRM server del progetto della tesi corrente per criptare i file multimediali. La parte di codice nel plugin che si occupa di criptare il flusso di dati è la seguente: #include "gstlamedrmaes.h" // NOTA: include <openssl/aes.h> e <gst/gst.h> [..] GstBuffer * gst_lame_drm_aes_process_buffer (GstLameDRMAES * drm, GstBuffer * in, gboolean encrypt) { int size = GST_BUFFER_SIZE (in); int num = 0; GstBuffer *out = gst_buffer_new_and_alloc (size); AES_cfb128_encrypt (GST_BUFFER_DATA (in), GST_BUFFER_DATA (out), size, &drm->aes_key, drm->iv, &num, encrypt); return out; }

18 che, dato un buffer in di dimensione size, crea un nuovo elemento di tipo GstBuffer chiamato out della stessa dimensione del buffer di input e chiama la funzione della libreria aes.h AES_cfb128_encrypt (const unsigned char *in, unsigned char *out, const unsigned long length, const AES_KEY *key, unsigned char *ivec, int *num, const int enc) che cripta il buffer in entrata della data lunghezza, passando la chiave di cifratura e l'initialization vector, e l'ultimo parametro che indica se stiamo criptando o decriptando, rispettivamente con i valori AES_ENCRYPT e AES_DECRYPT. Per quanto riguarda invece il processo di decriptazione del file multimediale, la pipeline e il comando che ne risulta sono leggermente più complessi, dato che gli elementi necessari sono in numero maggiore. Vediamo il comando che riproduce il file music_out.mp3 appena criptato, per mezzo di una pipeline contenente il plugin. Il comando con gst-launch risulta: $ gst-launch-0.10 filesrc location=music_out.mp3 ! lamedrmdec sslkey=thiskeyisverybad ! decodebin2 ! audioconvert ! audioresample ! osssink Il plugin “lamedrmdec” riceve sul suo canale di input il flusso criptato contenuto nel file music_out.mp3 e una chiave tramite il parametro sslkey, decripta il flusso dati con questa chiave e invia il flusso di dati risultante tramite il canale di output all'elemento decodebin2, che dall'input ricevuto in ingresso tramite il suo sink pad prova a individuare automaticamente i tipi di contenuto multimediale contenuti nel flusso, costruendo e inizializzando il decoder per ognuno di essi. Da notare che l'elemento decodebin2 risparmia una buona quantità di lavoro, in quanto il lavoro di individuazione del tipo di dato e la predisposizione degli elementi necessari nella pipeline dovrebbero essere eseguito completamente dall'utente finale o dal programmatore. Alla fine di questo processo invia il flusso di dati agli elementi audioconvert, audioresample e osssink che abbiamo visto nella sezione 3.1.

19 3.3 Integrazione di GStreamer nel player e nel codificatore Per integrare GStreamer nel codice del progetto, interamente scritto in C, si include gst/gst.h per accedere alle funzioni della libreria. Le funzioni principali per costruire in C una pipeline come quella vista nelle sezioni precedenti sono: • void gst_init (int argc, char **argv[]): si occupa di tutte le inizializzazioni necessarie e analizza tutte le opzioni passate specifiche per GStreamer; • GstElement* gst_pipeline_new (const gchar *name): crea una nuova pipeline con il nome specificato dal parametro name; • GstElement* gst_element_factory_make (const gchar *factoryname, const gchar *name): crea un nuovo elemento GStreamer del tipo specificato dal parametro factoryname con il nome specificato dal parametro name che deve essere univoco nel programma (se name è NULL il nome univoco verrà scelto automaticamente); • gboolean gst_bin_add (GstBin *bin, GstElement *element): aggiungi l'elemento element al Bin bin. Il Bin non è altro che un contenitore di elementi, e la pipeline è un sottotipo speciale di un Bin; • gboolean gst_element_link (GstElement* src, GstElement* dest): collega l'elemento src all'elemento dest. Quando gli elementi sono creati e collegati tra di loro, non effettuano alcuna operazione fino a che non viene cambiato lo stato degli elementi stessi. In GStreamer esistono quattro stati possibili: 1. GST_STATE_NULL: stato predefinito, libera tutte le risorse possedute da un elemento;

20 2. GST_STATE_READY: in questo stato un elemento ha tutte le risorse allocate, ma lo stream non è ancora aperto; 3. GST_STATE_PAUSED: in questo stato l'elemento ha lo stream aperto ma non lo sta processando attivamente, anche se l'elemento è autorizzato a modificare la posizione dello stream, leggere e processare dati per prepararsi al cambio di stato, ma non può riprodurre il flusso dati; 4. GST_STATE_PLAYING: è lo stato in cui viene riprodotto il flusso dati, e questo è ciò che lo distingue dallo stato PAUSED. Per cambiare lo stato si utilizza la funzione gst_element_set_state (GstElement *element, GstState *state). Con queste premesse vediamo per esempio, nel caso del codificatore, le chiamate per creare l'elemento source, l'elemento rappresentante il nostro plugin e l'elemento sink, e come vengono collegati insieme prima di impostare lo stato PLAYING nella pipeline che li contiene: GstElement *src, *aesfilter, *sink; GstElement *pipeline; [….] pipeline = gst_pipeline_new ("pipeline"); […] /* create source gstreamer element */ src = gst_element_factory_make ("filesrc", "File Source"); g_object_set (G_OBJECT (src), "location", filetoencode, NULL); […] /* Create gstreamer element related to the lamedrm plugin */ aesfilter = gst_element_factory_make ("lamedrmenc", "aes encoder"); /* DRM AES encoder, set the key */ g_object_set (G_OBJECT (aesfilter), "sslkey", &value); [..]

21 sink = gst_element_factory_make ("filesink", "file-output"); g_object_set (G_OBJECT (sink), "location", outputfile, NULL); [..] gst_bin_add_many (GST_BIN (pipeline), src, aesfilter, sink, NULL); gst_element_link_many (src, aesfilter, sink, NULL); /* Set the pipeline to "playing" state */ gst_element_set_state (pipeline, GST_STATE_PLAYING); Possiamo analizzare le funzioni non spiegate in precedenza. Innanzitutto gst_bin_add_many e gst_element_link_many hanno lo stesso scopo delle già spiegate gst_bin_add e gst_element_link ma si applicano su una lista (terminata da NULL) di elementi. Per quanto riguarda invece la funzione g_object_set (gpointer object, const gchar *first_property_name, …) è la funzione che serve per impostare la proprietà first_property_name del GObject rappresentato da object. Quindi per impostare la proprietà sslkey a un determinato valore per l'oggetto aesfilter di tipo lamedrmenc, la line di codice è la seguente: g_object_set (G_OBJECT (aesfilter), "sslkey", &value); L'ultima linea di codice riportata, gst_element_set_state (pipeline, GST_STATE_PLAYING), imposta lo stato della pipeline su PLAYING che permette quindi l'inizio del flusso di dati tra gli elementi della pipeline. Per quanto riguarda invece il player multimediale è stato necessario creare ulteriori elementi, sia per quanto riguarda la riproduzione audio, sia per quanto riguarda la costruzione e l'inizializzazione dei decoder necessari per riprodurre il tipo di file multimediale ricevuto. Come abbiamo visto in precedenza, per questo scopo è possibile utilizzare l'elemento decodebin2, per cui: /* Decodebin */ decoder = gst_element_factory_make ("decodebin2", "Decodebin"); g_signal_connect (decoder, "new-decoded-pad",

22 G_CALLBACK (on_pad_added), NULL); gst_bin_add_many (GST_BIN (pipeline), aesfilter, decoder, NULL); gst_element_link (aesfilter, decoder); [..] /* Aautodetect the best audio sink */ sink = gst_element_factory_make ("autoaudiosink", "audio-output"); audio = gst_bin_new ("audiobin"); conv = gst_element_factory_make ("audioconvert", "aconv"); audiopad = gst_element_get_static_pad (conv, "sink"); gst_bin_add_many (GST_BIN (audio), conv, sink, NULL); gst_element_link (conv, sink); gst_element_add_pad (audio, gst_ghost_pad_new ("sink", audiopad)); Questo codice crea l'elemento decoder di tipo decodebin2, lo aggiunge alla pipeline e lo collega con il nostro plugin. g_signal_connect() connette una funzione di callback a un preciso segnale, per un particolare elemento: quando si usa questo processo automatico di rilevamento del tipo di file multimediale, viene creato un ghost pad negli argomenti del segnale, e questo permette alle applicazioni di connettere il pad appena creato e passato come argomento con il segnale new-decoded-pad. L'elemento creato con: sink = gst_element_factory_make ("autoaudiosink", "audio-output"); crea un elemento che automaticamente sceglie il miglior audio sink possibile (che eventualmente potrebbe essere quello che negli esempi precedenti indicavamo manualmente, osssink).

23 Le altre funzioni creano un elemento audiobin e un elemento audioconvert che permettono la riproduzione del flusso dei dati come spiegato nella sezione 3.1.

24 4. Sistema realizzato « Great things are not done by impulse, but by a series of small things brought together.» – Vincent Van Gogh Dopo aver visto le fonti d'ispirazione, una breve descrizione del sistema realizzato e il funzionamento di alcuni suoi componenti, vediamo in questa sezione i componenti introdotti ma non ancora analizzati, e il modo in cui si interfacciano l'uno con l'altro. 4.1 Account Server Uno dei componenti principali del sistema e maggiormente sviluppato è l'Account Server, il cui compito principale è la gestione degli utenti del sistema stesso: registrazione, cancellazione, autenticazione. Ha inoltre il compito di inoltrare alcune richieste del client al server DRM e viceversa, negli ambiti che tra poco analizzeremo. 4.1.1 Gestione utenti: registrazione e autenticazione, LDAP Come accennato in precedenza la gestione degli utenti si basa su un server OpenLDAP6. Per interfacciarsi con il server LDAP (da ora in avanti indicato anche con il nome slapd) è stata utilizzata la libreria ldap.h. In particolare l'Account Server ha sempre attiva una connessione con il server LDAP con accesso come admin, utente che ha tutti i diritti di modifica sullo schema definito. Quando un utente deve effettuare l'autenticazione, invia i dati all'Account Server che effettua l'operazione di bind sul server LDAP con i dati dell'utente, per controllare se quest'ultimo è registrato o meno e se le credenziali che ha fornito sono valide: ovviamente questo dialogo avviene tramite una connessione SSL per evitare che utenti 6 Lightweight Directory Access Protocol. http://www.openldap.org/

25 malintenzionati possano sniffare il traffico che contiene dati sensibili, e quindi sfruttarli per autenticarsi ed entrare nel sistema usando le credenziali ottenute illegalmente. Le funzioni principali della libreria utilizzata per interfacciarsi con OpenLDAP sono le seguenti: • int ldap_initialize (LDAP **ldp, char *uri): inizializza la libraria LDAP e prepara la struttura che verrà utilizzata per connettersi e dialogare con slapd; • int ldap_sasl_bind_s (LDAP *ld, const char *dn, const char *mechanism, struct berval *cred, LDAPControl *sctrls[], LDAPControl *cctrls[], struct berval **servercredp): interfaccia per l'operazione di bind SASL di LDAP. In breve questa funzione autentica l'utente, identificato da precise credenziali (DN: Distinguished Name, e password) tramite la connessione sul server LDAP rappresentata dal parametro ld; • int ldap_unbind_ext_s (LDAP *ld, LDAPControl *sctrls[], LDAPControl *cctrls[]): esegue l'operazione di unbind di LDAP, termina la connessione con il server e libera le risorse contenute nella struttura ld; • int ldap_add_ext_s (LDAP *ld, const char *dn, LDAPMod **attrs, LDAPControl **sctrls, LDAPControl **cctrls): esegue un'operazione di add di LDAP. Viene quindi usata per aggiungere gli utenti al sistema, ognuno di essi identificato dal parametro dn che li identificherà univocamente; • int ldap_delete_ext_s (LDAP *ld, char *dn, LDAPControl **sctrls, LDAPControl **cctrls): esegue un'operazione di delete di LDAP. L'elemento cancellato è identificato dal parametro dn che ovviamente rappresenta il suo Distinguished Name. I dati per l'autenticazione sono inviati tramite il formato dati JSON e riportati in oggetti GObject grazie alla libreria json-glib, come spiegato nelle sezioni precedenti. In particolare è stato creato un oggetto chiamato AesjsonAuthObject definito dalla seguente struttura:

26 typedef struct _AesjsonAuthObject AesjsonAuthObject; struct _AesjsonAuthObject { GObject parent_instance; gchar *username; gchar *password; gchar *email_address; gint action; }; dove il significato dei membri username, password ed email_address sono chiari, mentre action è un intero che prende un valore specificato e noto a tutti gli elementi del sistema, e che rappresenta l'azione che l'utente identificato da quella struttura vuole effettuare: login, logout, registrazione, download, ricerca, e così via. 4.1.2 Dialogo con client e DRM Server Per mezzo della comunicazione che avviene come descritto nella sezione 4.1.1, il client comunica all'Account Server l'azione che vuole effettuare. Le azioni principali sono quindi: login, logout, registrazione, ricerca. L'ultima azione è quella che vedrà coinvolto anche il DRM Server. Il funzionamento effettivo verrà spiegato in seguito, ma in breve quando un client decide di cercare e poi scaricare un determinato file multimediale, il compito dell'Account Server è quello di informare il DRM Server e poi ottenere da quest'ultimo la user key associata a quell'utente e quel file multimediale, per poi inviarla a sua volta all'utente. 4.1.3 Registrazione/Eliminazione di un utente dal sistema Quando un utente avvia per la prima volta il client principale (da adesso in avanti chiamato anche mainclient), viene invitato a registrarsi indicando il nome utente prescelto, la password e l'indirizzo email: questi dati vengono quindi inviati all'Account Server, che registra l'utente

27 (se il nome utente non è già presente) nel server LDAP e risponde al mainclient sull'esito dell'operazione: a questo punto il client si autentica automaticamente ed entra nel sistema. Il mainclient, inoltre, crea una file nascosto nella home directory dell'utente corrente salvando le credenziali, per essere automaticamente autenticato al prossimo avvio del programma. Una volta entrati nel programma c'è il menù delle possibili azioni, tra cui è possibile scegliere ovviamente il logout e la cancellazione, che come la registrazione invia la richiesta all'Account Server, il quale effettua l'operazione richiesta sul server LDAP e ritorna lo stato dell'operazione. 4.2 DRM Server Come introdotto in precedenza il DRM Server è il processo che si occupa di gestire i file multimediali e la loro distribuzione nel sistema. Inoltre si occupa di criptare un nuovo file che si vuole introdurre nella rete. 4.2.1 Aggiunta di un nuovo elemento multimediale Sul server DRM è innanzitutto disponibile un programma che viene utilizzato per criptare il file multimediale con una data chiave: l'implementazione e il funzionamento della parte relativa alla codifica vera e propria vengono descritti nel capitolo 3, dopo l'introduzione a GStreamer. In sostanza, il programma prende un solo parametro in input, che rappresenta il percorso del file di configurazione relativo al database, e che deve contenere le informazioni necessarie nella forma: server:databasename:databaseuser:databasepassword. L'encoder avvierà dunque la connessione con il database MySQL e chiederà i dati relativi al file multimediale da criptare: percorso del file e informazioni quali il nome dell'artista, l'album di riferimento, il nome del contenuto multimediale. A questo punto viene generata in maniera casuale (grazie alla “fonte casuale” /dev/urandom nei sistemi Linux) una chiave che sarà la master key: con questa chiave verrà quindi criptato il file multimediale. A questo punto deve

28 essere aggiornata la tabella che tiene traccia dei file criptati e delle relative chiavi di cifratura, chiamata titolo_masterkey e definita come segue: dove il campo media tiene traccia dei metadati del file, utilizzati successivamente per la ricerca, il campo master_key contiene la chiave con la quale è stato criptato il file, real_path contiene il percorso del file nel filesystem (il percorso è relativo, verrà poi associato a un percorso di partenza impostato nelle preferenze del server DRM), e infine il campo id che rappresenta l'identificatore univoco del file in questione. 4.2.2 Ricerca di file multimediali La ricerca avviene effettuando delle query sulla tabella del database descritta nel paragrafo 4.2.1 con i criteri indicati dall'utente. Il funzionamento pratico viene descritto nei paragrafi 2.3.1 e 2.3.2, mentre questo paragrafo introduce gli aspetti tecnici legati al funzionamento della ricerca. La richiesta di ricerca dell'utente è inviata all'Account Server, il quale la inoltra al DRM Server: quest'ultimo effettua delle query sul database ed elabora una risposta strutturata con il formato dati JSON, come la seguente stringa che rappresenta 2 risultati della ricerca: [{ "id" : 1, "mediapath" : "/path/to/encoded_file.mp3", "ip" : "xxx.xxx.xxx.xxx" },{ "id" : 5, "mediapath" : "/path/to/encoded_file_2.mp3",

29 "ip" : "xxx.xxx.xxx.xxx" }] Il risultato è mandato all'Account Server il quale lo inoltra al client che analizza i risultati tramite le funzioni fornite dalla libreria json-glib e può quindi lavorare sugli oggetti derivati dalla stringa ricevuta. 4.2.3 Download di un file multimediale Una volta effettuata la ricerca spiegata nel paragrafo 4.2.2, il client indica il file che vuole scaricare tramite il suo id, e lo comunica all'Account Server. Quest'ultimo invia la richiesta al DRM Server che si occupa di generare una user key in maniera casuale sfruttando il file /dev/urandom per poi inviarla all'Account Server, il quale la archivierà associandola all'utente e al file richiesto. Il DRM Server a questo punto aspetta la connessione diretta dell'utente, cripta la master key con la user key e, dopo aver opportunamente ricostruito il percorso assoluto del file da inviare unendo il valore del campo real_path ottenuto dalla tabella del database con il valore MEDIABASE definito nelle impostazioni del DRM Server, invia il file multimediale criptato e infine la master key criptata. Il client potrà quindi procedere a scaricare la user key dall'Account Server per poter decriptare la master key e con questa decriptare il file multimediale per riprodurlo. 4.3 Client Il client fornisce l'interfaccia necessaria all'utente per interagire con il sistema, permettendogli di effettuare tutte le operazioni descritte precedentemente. Include inoltre il player per riprodurre il file multimediale scaricato, prendendo come parametri il file stesso criptato e la chiave per decriptarlo. Il Capitolo 3 spiega nei dettagli come avviene la riproduzione tramite Gstreamer.

30 5. Conclusioni « Most people take the limits of their vision to be the limits of the world. A few do not. Join them.» – Arthur Schopenhauer L'obiettivo del sistema realizzato è quello di fornire un modello di risoluzione di un problema tuttora aperto. Infatti il tema della protezione dei diritti digitali (DRM) ha dei risvolti sia tecnici sia legali e organizzativi. In Italia il download di un'opera protetta da diritti d'autore e la sua condivisione è un illecito penale (art. 171, lett. a-bis, lda), con pena pecunaria da 51 a 2.065 euro e una sanzione amministrativa pari al doppio del prezzo di mercato dell'opera oggetto della violazione (art. 174-bis lda), ma detta cifra non può essere mai inferiore a 103 euro. La Francia è in prima linea nell'affrontare il problema, rendendo sempre più aspre le sanzioni, definite tra le più repressive del mondo in quanto si spingono fino alla sospensione da parte delle autorità della connessione ad internet: sembra che questo modello non dia i frutti sperati, in quanto una recente ricerca del Times7 mostra che il 42% dei programmi software in Francia sono ottenuti illegalmente, contro il 26% della Gran Bretagna e il 27% della Germania: il dato più alto d'Europa. La domanda allora è: come si garantiscono i diritti d'autore distribuendo le opere in formato digitale in rete? E inoltre, vista la diffusione del modello peer-to-peer, come tutelare gli autori accettando lo scambio degli oggetti multimediali tra nodi della rete non controllati direttamente dai detentori dei diritti? Com'è possibile mantenere la value-chain il più possibile intatta? Per value-chain si intende quel percorso compiuto dal file multimediale durante la sua esistenza attraverso diverse fasi: creazione, produzione, distribuzione e consumo, che vede 7 http://www.timesonline.co.uk/tol/news/world/europe/article7044738.ece

31 nell'ultimo punto la sua debolezza in quanto il consumatore, una volta in possesso del prodotto non coperto da meccanismi di DRM, può estrarre materiale dalla value-chain e immetterlo in una rete senza controllo, come quella del file sharing illegale. Nella tesi ci si è occupati solo degli aspetti tecnici, cercando di fornire uno schema adatto anche a reti peer-to-peer. Si è preso spunto dal modello di iTunes adattandolo a reti peer-to- peer. Il sistema realizzato pur essendo aperto alla soluzione completa si limita alla modalità di interazione client/server. Per quanto concerne la vendita diretta o il pagamento forfettario, il modello presentato concede spazio ad entrambi in quanto si tratta di un sistema “chiuso”, mantenendo la value- chain il più possibile intatta . Fornendo un sistema controllato e sicuro per quanto riguarda l'identità dell'utente, essendo tutto il traffico criptato, e mettendo a disposizione un client che permette di usufruire del servizio in maniera molto semplice, le probabilità di veder salire la percentuale dei brani scaricati protetti con DRM è buona, ma la strada per raggiungere cifre importanti è lunga (attualmente la cifra è stimata intorno al 5%!). Quello che invece è certo è che il mercato, soprattutto nel campo musicale, si sta muovendo verso un nuovo modello industriale. Ad aprire la strada verso nuove soluzioni è stata la band Radiohead, che nel Settembre 2007 rendeva disponibile il nuovo album con brani in formato MP3 senza DRM con un prezzo scelto liberamente dal consumatore (anche gratuitamente, quindi). L'album era disponibile in un secondo formato più completo con 8 brani aggiuntivi e altri contenuti. Da quel momento molti gruppi hanno intrapreso strade simili. Ecco che il modello proposto nella tesi, che può prevedere una quota forfettaria per l'ingresso nel sistema, assume un valore importante anche riflettendo sul cambiamento che l'industria musicale sta subendo. Infatti, quelli che erano casi isolati sono ora diventati progetti che coinvolgono un insieme consistente di artisti, con vere e proprie piattaforme create per questo scopo. È il caso di modlife8, sulla quale la stessa Universal9 ha manifestato interesse, una piattaforma web che connette gli utenti che hanno pagato una quota di iscrizione, definiti premium members, con 8 http://www.modlife.com/ 9 una delle quattro più grandi etichette discografiche (major), http://www.umusic.com/

32 gli artisti, fornendo materiale aggiuntivo non solo musicale, messaggi istantantei con gli artisti stessi, e così via. L'obiettivo è creare nuove forme di guadagno oltre alla musica, un nuovo modello di business che sembra aver dato buoni frutti alla prima band che ha sfruttato questa piattaforma, gli Angels & Airwaves, che hanno rilasciato il loro album gratuitamente ma che stanno avendo un rientro grazie a contenuti esclusivi quali prove di registrazione, soundcheck, merchandising: «se rilasci 10 milioni di copie gratuitamente, e 50.000 di questi utenti usufruiscono del pay-per-view su vari contenuti, o comprano una t-shirt, il rientro stimato è di 10 milioni di dollari l'anno»10(cit. Tom DeLonge, leader del gruppo). L'affermazione è plausibile perchè è del tutto eliminato il compenso economico che nel modello corrente dovrebbe essere versato alla casa discografica. Alla luce di quanto detto, il modello proposto può rappresentare un punto d'incontro. La sensazione è che comunque non saranno motivazioni tecniche, legali o dettate dalla ragione a spingere verso una soluzione piuttosto che verso un'altra, ma semplicemente gli interessi economici delle aziende coinvolte. Possibili evoluzioni del lavoro riguardano l'implementazione del peer-to-peer e l'introduzione degli standard di riferimento per la ricerca degli oggetti e per la definizione dei meccanismi di protezione. Ci si riferisce ad esempio a MPEG 7 e a MPEG 21: il primo è uno standard che gestisce i dati multimediali utilizzando la codifica XML per memorizzarli, che tramite il timecode (sequenza di codici numerici per la sincronizzazione di segnali e per la suddivisione del materiale registrato su supporti audio/video) permette di sincronizzare i flussi multimediali con particolari eventi, come ad esempio i sottotitoli per un filmato. Il secondo invece definisce uno standard chiamato Rights Expression Language (REL), un linguaggio usato per il DRM, la maggior parte espresso in XML, con lo scopo di condividere i diritti digitali dal creatore del prodotto al consumatore. Lo scopo è comunicare le informazioni sulla licenza in modo “non ambiguo e sicuro”, aspirando a porre fine al file sharing illegale. 10 http://www.spin.com/articles/qa-blink-182s-tom-delonge

33 6. Bibliografia – Network Security with OpenSSL, Chandra, Messier, Viega (O'Really, Giugno 2002) – GStreamer, Application Development Manual (0.10.24.3): http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/index.ht ml – GObject Reference Manual: http://library.gnome.org/devel/gobject/stable – JSON-GLIB Reference Manual: http://folks.o-hand.com/~ebassi/docs/json-glib/ – OpenLDAP: http://www.openldap.org – Varie informazioni prese da http://en.wikipedia.org/

34 7. Ringraziamenti Servirebbero varie pagine per citare tutte le persone che vorrei ringraziare, ma non è possibile per cui sarò breve. Il primo immenso ringraziamento è rivolto ovviamente a mio padre, mia madre e mia sorella, che mi sono sempre stati vicini tra gli alti e bassi della carriera universitaria e della vita in generale: la sicurezza di poter contare sempre su di voi è un punto di riferimento indispensabile. Un profondissimo grazie a tutti i miei amici, consapevole di essere una persona molto fortunata essendo circondato da persone su cui posso contare in ogni istante e per ogni circostanza della mia vita. Molti di voi mi sono stati vicini in momenti felici e meno felici, con alcuni abbiamo percorso tutte le tappe della crescita insieme. Con alcuni condivido e ho condiviso desideri, progetti, fallimenti e successi, paure e sogni, con altri di voi so e mi auguro che potrò farlo in futuro. Un sentito ringraziamento al prof. Vincenzo Fazio che in questo percorso mi ha dimostrato di essere una persona validissima ben oltre il lato didattico. Un ringraziamento anche a quelle persone che sono entrate nella mia vita seppur per un periodo di tempo relativamente breve, ma che sono riuscite a illuminare e mostrarmi lati di me che non conoscevo. Un ringraziamento anche: a quei parenti che sono stati presenti durante la mia crescita e lo sono tutt'ora, agli artisti che, oltre a fornire un elemento importante di questa tesi, la musica, mi hanno accompagnato nei giorni e nelle notti di lavoro su questo progetto e sono una fonte di ispirazione componendo la colonna sonora della mia vita; .....e a te.

http://lorenzosfarra.blogspot.com	109
http://www.linkedin.com	4
http://www.slideshare.net	1

Progettazione e realizzazione di un sistema DRM utilizzando SSL e GStreamer

by Lorenzo Sfarra

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 114

Statistics

Progettazione e realizzazione di un sistema DRM utilizzando SSL e GStreamer Document Transcript