Tesi di Lorenzo Sfarra per la laurea in Informatica alla facoltà di Scienze MM. FF. NN. dell'Aquila

1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.