UNIVERSITÀ DEGLI STUDI DELL’AQUILAFacoltà 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

Indice1. Introduzione ...........................................................................................................................2

2. Architettura DRM..................................................................................................................52.1 Tecnologie utilizzate..............................................................................................................62.2 I componenti del sistema........................................................................................................72.2.1 Account Server....................................................................................................................82.2.2 DRM Server........................................................................................................................92.2.3 Client...................................................................................................................................92.3 Casi d'uso.............................................................................................................................112.3.1 Ricerca e Download..........................................................................................................112.3.2 Esempio.............................................................................................................................12

3. GStreamer, codificatore e player multimediale.................................................................143.1 GStreamer............................................................................................................................143.2 Il plugin per criptare/decriptare file multimediali................................................................163.3 Integrazione di GStreamer nel player e nel codificatore......................................................19

4. Sistema realizzato.................................................................................................................244.1 Account Server.....................................................................................................................244.1.1 Gestione utenti: registrazione e autenticazione, LDAP....................................................244.1.2 Dialogo con client e DRM Server....................................................................................264.1.3 Registrazione/Eliminazione di un utente dal sistema.......................................................264.2 DRM Server.........................................................................................................................274.2.1 Aggiunta di un nuovo elemento multimediale..................................................................274.2.2 Ricerca di file multimediali...............................................................................................284.2.3 Download di un file multimediale....................................................................................294.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 utilizzate2.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.22.2 I componenti del sistemaI 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.txt3 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'uso2.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 GStreamer3.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 file3.2 Il plugin per criptare/decriptare file

multimedialimultimediali

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.33.3 Integrazione di GStreamer nel player e nelIntegrazione di GStreamer nel player e nel

codificatorecodificatore

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.14.1 Account ServerAccount 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 Server4.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 Client4.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.