[Gfoss] DRM: avevamo ragione noi

Giovanni Mascellani g.mascellani a gmail.com
Dom 11 Gen 2009 19:16:03 CET


Il giorno dom, 11/01/2009 alle 18.40 +0100, Andrea Peri ha scritto:
> La mia prec. email era volutamente incompleta perche' mi sono dovuto assentare.
> 
> Vedo ora di terminare il concetto.
> ------------
> >> E poi quanti ce ne saranno di "esperti" che scardinano il DRM.
> >> Non credo proprio che ce ne siano cosi' "tanti".
> 
> >Non ne ho idea, ma ne basterebbe uno solo: una volta scoperto come
> >aggirare il DRM puoi tranquillamente convertire i dati in un formato
> >senza DRM ed far cadere il DRM stesso nell'eterno oblio. Nel caso della
> >musica, la stragrande maggioranza dei file musica che possono
> >interessare la persona media può essere scaricare tranquillamente senza
> >DRM.
> 
> >> Ps: so' benisio che basta una virtual machine per ingannarlo, ma il
> >> punto resta valido.
> >> Il DRM si lascia ingannare perche' parte dal presupposto di potersi
> >> fidare dell'utente originale.
> 
> >In quali situazioni questo presupposto è valido?
> 
> Ad esempio (vedi GeoRM) in ambienti ove la conoscenza del dato riveste
> interesse strategico e cose del genere.
> 
> Ad esempio mi viene in mente le comunicazione satellitari o certe
> conversazioni telefoniche.
> Tutta roba ove insomma l'importanza della conoscenza del dato si
> sviluppi nell'arco delle poche ore o di pochi minuti.
> 
> Ovvero in situazioni dove la conocenza del dato con 24 ore di ritardo
> rende tale conoscenza irrilevante.

Queste non sono situazioni nel quale ti puoi fidare del pubblico a cui
dai il dato, perché non dai il dato al pubblico. Te lo tieni tu, ed è
ovvio che di te stesso ti puoi fidare. Ma lo puoi fare anche senza DRM.
Scrivere su un file che solo tu lo puoi leggere non ti aiuta a farlo, e
non impedisce a che dovesse accidentalmente rubarti il dato di farlo.

> Tornando all'uso originale di cui si parlava...
> Il DRM, almeno nei metodi piu' ovvi si basa sull'abbinamento tra PC e archivio.
> 
> Quando cambi PC l'abbinamento non torna piu' e l'archivio diviene illeggibile.
> 
> Per cui una tecnica che banalmente lo mette in crisi e' se
> l'abbinamento viene fatto basandosi su una virtual machine.
> Questo costringe a leggere i dati all'interno di una vm ma rende
> l'archivio trasportabile.
> 
> Ora qui il punto di vista tra il tuo discorso e il mio diverge.
> 
> Per te' e' rilevante il riuscire a scardinare il DRM e rendere i dati
> in chiaro, ovverosia rimuovere il vincolo.
> Per me , invece, questo e' irrilevante, per il solo motivo che la
> trasportabilita' si puo' avere facilmente tramite l'ausilio di una VM,
> ovverosia rendere il vincolo ininfluente.
> 
> Quando dicevo che alla base il DRM si basa sull'assunto di fidarsi
> dell'operatore, intendevo distinguere,
> tra il caso in cui i dati sono utilizzati legittimamente da un operatore,
> su una macchina, e il DRM li lascia usare perche' torna l'abbinamento
> tra macchine e dati.
> 
> Se poi questi dati sono asportati illegalmente e portati in un'altra
> macchina ecco che il DRM si attiva e li blocca.

Aspetta, questo non è esatto. Il DRM non si può attivare, è solo una
manciata di byte, ed i byte non si attivano. Il DRM può agire solamente
quando c'è un programma che gli dà ascolto. Questo, tra le altre cose,
porta al paradosso che un programma che non sa cosa siano i DRM (quindi
ha _meno_ features di uno che sa cosa sono), ma sa ovviamente leggere il
resto del file che contiene i dati in questione, è in realtà capace di
leggere un maggior numero di file rispetto al programma che legge e
rispetta il DRM, autocensurandosi un file quando questo lo richiede.

> Che poi esso sia scardinabile, alla stregua di una cassaforte che
> portata in aperta campagna puo' resistere per qualche ora, ma alla
> fine cede ha poca rilevanza.
> 
> Se invece l'operatore stesso agisce per rendere tali dati
> trasportabili fecendoli abbinare a un VM, allora e' l'operatore stesso
> che agisce contro l'assunto originale, e rende tali dati
> indifendibili.
> 
> Ora io dicevo che mentre e' logico usare il DRM per difendere dei dati
> in un ambito ove anche chi li adopra e' dalla parte di chi li difende
> (il DRM).
> 
> E' assurdo usarlo per vendere dai dati ( i brani musicali ) dove chi
> li acquista e' dalla parte opposta, e li vorrebbe invece liberare
> dalla morsa del DRM.
> Perche' basta che li compra e li scarica, operi in una VM, che sono
> automaticamente trasportabili senza problemi.

Esatto, ma è proprio questo il punto: il DRM è concepito proprio per far
questo, per proteggere i dati in modo che, quando si trovano in mani
avversarie, siano utilizzabili, ma siano utilizzabili solo a certe
condizioni (di tempo, di autorizzazione, ...).

Mi spiego meglio: il DRM è una pseudo-applicazione che sta tra il
crittografico e lo steganografico: ossia sfrutta un protocollo
sconosciuto e difficile da comprendere oppure una vera e propria
applicazione crittografica (come, se non sbaglio, provavano a fare i
DVD), per fare in modo che, normalmente, un utente non possa leggere
liberamente i dati. L'idea è che in questo modo i dati possono essere
distribuiti al pubblico (inaffidabile), facendo in modo che questo possa
leggerli, ma solo a determinate condizioni. Questo accade perché l'unico
modo che il pubblico ha per fruire di questi dati è utilizzare un
apparecchio che viene prodotto solo da chi conosce il protocollo, e che
quindi è dotato delle protezioni che il produttore ci ha voluto mettere
su. Inutile dire che, quando distribuisci tantissimi file crittati nello
stesso modo e distribuisci anche il modo per decrittarli, ancorché
difficile da capire come funziona, il protocollo resiste poco. Ed io
oggi guardo i DVD crittati dalla mia Debian senza troppi problemi (né
tecnici, né di coscienza). Per fare questo è stato sufficiente attivare
dei repository non ufficiali, ed utilizzare il software che qualcun
altro aveva scritto, una volta capito come funziona il CSS.

L'esempio di cui parli tu non segue lo stesso paradigma: in quel caso
chi produce i dati non ha interesse a diffonderli tra il pubblico,
permettendo al pubblico stesso di vederli, ma solo a determinate
condizioni. Il pubblico non deve vederli proprio, a nessuna condizione.
In tal caso si usa semplicemente un procedimento crittografico, così
anche se me li rubano non possono leggerli. E di sistemi crittografici
considerati sicuri oggi ne esistono. Ma si tratta di un altro modello di
sicurezza.

> Il discorso dello sblocco del dato con la rimozione del DRM, e' un
> altro aspetto ancora.
> Piu' drastico, certamente e piu' definitivo.
> Ma mentre questo secondo caso richiede delle competenze certamente non comuni.

Non credo. Se sei in grado di utilizzare una VM per visualizzare video,
riprodurre musica, aprire dati in generale coperti da DRM e poi
catturare l'audio, il video o qualsiasi cosa siano questi dati. A quel
punto ce li hai. Potrai avere una perdita di qualità dovuta alla
decodifica e ricodifica, ma questo è un problema accessorio. Per poter
essere fruiti da qualche parte i dati decrittati devono esserci, per
esempio nella RAM della VM. E se son lì, nessuno ti può impedire di
prenderli. Scrivere e distribuire un software che faccia questo lavoro
non è molto più difficile, secondo me, che scrivere un software che
sfrutti questi dati quando non sono coperti da DRM. Ed in ogni caso,
basta che lo faccia una sola persona perché lo possano usare tutti (vedi
caso di libdvdcss).

> Pero' non e' che il DRM sia una ciofeca in quanto tale, ma bensi' e'
> una ciofeca l'idea di usarlo per proteggere i brani musicali venduti.

Ma l'idea costitutiva del DRM è proprio quella di proteggere dati, senza
però impedirne completamente l'utilizzo. Si vuole lasciare aperta una
porta, ma solo in alcune condizioni. È ovvio, però, che appena l'utente
scopre come entrare riesce a rifarlo ogni volta che vuole.

Se invece si vogliono semplicemente proteggere dati dalla visione
altrui, a qualsiasi condizione, la risposta non è DRM, ma GPG (o
analoghi).

Ciaociao, Gio.
-- 
Giovanni Mascellani <g.mascellani a gmail.com>
Pisa, Italy

Web: http://giomasce.altervista.org
SIP: g.mascellani a ekiga.net
Jabber: g.mascellani a jabber.org / giovanni a elabor.homelinux.org
GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD  003F FCB0 BB5C 5F1F BF70)
-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        non disponibile
Tipo:        application/pgp-signature
Dimensione:  315 bytes
Descrizione: Questa è una parte del messaggio	firmata digitalmente
URL:         <http://www.faunalia.com/pipermail/gfoss/attachments/20090111/6e0408c4/attachment-0001.pgp>


Maggiori informazioni sulla lista Gfoss