è ragionevole proteggere il lato client di contenuti drm

https://stackoverflow.com/questions/1822309

10-07-2019
|

Domanda

Aggiornamento: questa domanda riguarda in particolare la protezione (codifica / offuscamento) del lato client del contenuto rispetto a farlo prima della trasmissione dal server. Quali sono i pro / contro su un approccio come quello di iTunes - in cui i file non sono cifrati / offuscati prima della trasmissione.

Come ho aggiunto nella mia nota nella domanda originale, ci sono contratti in essere che dobbiamo rispettare (come nel caso della maggior parte dei servizi che implementano drm). Facciamo pressioni per ottenere drm free, e la maggior parte delle offerte dei fornitori di contenuti sono su di esso, ma ciò non ci libera dagli obblighi già in essere.

Di recente ho letto alcune informazioni su come itunes / fairplay si avvicinano a drm e non si aspettavano di vedere che il server serve effettivamente i file senza alcuna protezione.

La citazione in questa risposta sembra catturare lo spirito del problema.

L'obiettivo dovrebbe essere semplicemente quello di "mantenere"   gente onesta onesta " ;. Se andiamo   oltre a ciò, solo due cose   accadere:


Combattiamo una battaglia che non possiamo vincere. Coloro che vogliono imbrogliare avranno successo.

Abbiamo danneggiato gli utenti onesti del nostro prodotto rendendolo più difficile da usare.

Non vedo alcun impatto sugli utenti onesti qui, i file sarebbero collegati all'utente, indipendentemente dal fatto che ciò accada sul lato client o server. Questo dà un'altra possibilità a quelli in 1.

Un po 'di informazioni in più: l'ambiente client è Adobe Air, più tipi di contenuto coinvolti (musica, video, app flash, immagini).

Quindi, è ragionevole fare come il fairplay di itune e proteggere il lato client multimediale.

Nota: penso che il DRM indistruttibile sia un problema irrisolvibile e dato che la maggior parte cerca una risposta a questo, la necessità si riferisce al fatto che è già in un contratto con i fornitori di contenuti ... come un ragionevole sforzo migliore.

Soluzione

Per rispondere alla domanda "è ragionevole", devi essere chiaro quando usi la parola "proteggi" cosa stai cercando di proteggere da ...

Ad esempio, stai provando a:

utenti autorizzati dall'utilizzo dei contenuti scaricati tramite la tua app in determinate circostanze (ad esempio scadenza del periodo di noleggio, copia su un altro computer, ecc.)?
utenti autorizzati dall'utilizzo dei contenuti scaricati tramite qualsiasi app in determinate circostanze (ad esempio scadenza del periodo di noleggio, copia su un altro computer, ecc.)?
utenti non autorizzati dall'utilizzo di contenuti ricevuti da utenti autorizzati tramite la tua app ?
utenti non autorizzati dall'utilizzo di contenuti ricevuti da utenti autorizzati tramite qualsiasi app ?
utenti noti che accedono a contenuti non acquistati / non autorizzati dalla libreria multimediale sul server tramite la tua app ?
utenti noti dall'accesso a contenuti non acquistati / non autorizzati dalla libreria multimediale sul server tramite qualsiasi app ?
utenti sconosciuti che accedono alla libreria multimediale sul tuo server tramite la tua app ?
utenti sconosciuti che accedono alla libreria multimediale sul server tramite qualsiasi app ?

ecc ...

" Qualsiasi app " in quanto sopra può includere cose come:

programmi per altri giocatori progettati per interagire / cooperare con il tuo sito (ad es. per flickr )
programmi progettati per convertire il contenuto in altri formati, possibilmente formati non DRM
programmi ostili progettati per

Dall'articolo che hai collegato, puoi iniziare a vedere alcune delle possibili limitazioni dell'applicazione del lato client DRM ...

Il terzo, originariamente utilizzato in PyMusique, un client Linux per iTunes Store, finge di essere iTunes . Ha richiesto brani dai server Apple e quindi scaricato i brani acquistati senza bloccarli , come farebbe iTunes.



Il quarto, usato in FairKeys, anche finge di essere iTunes ; richiede le chiavi di un utente dai server di Apple e quindi utilizza queste chiavi per sbloccare i brani acquistati esistenti .

Nessuno di questi approcci richiedeva la rottura del DRM applicato o addirittura la pirateria informatica di nessuno dei prodotti coinvolti; potevano essere fatti semplicemente osservando passivamente i protocolli coinvolti e quindi imitandoli.

Quindi la domanda diventa: stai cercando di proteggere da questo tipo di attacco?

In caso affermativo, il DRM applicato dal client è non ragionevole .
Se no (ad esempio, sei preoccupato solo per le persone che usano la tua app, come fa Apple / iTunes), allora potrebbe essere.

(ripeti questa procedura per ogni situazione che ti viene in mente. Se la risposta è sempre o "DRM applicato dal client mi proteggerà" o "non sto cercando di proteggere da questa situazione", quindi utilizzando DRM applicato dal client è resonable .)

_{Nota che per gli ultimi quattro dei miei esempi, mentre il DRM protegge da tali situazioni come effetto collaterale, non è il posto migliore per applicare tali restrizioni. Questi tipi di restrizioni vengono applicati al meglio sul server nel processo di accesso / autorizzazione.}

Altri suggerimenti

Penso che potresti perdere qualcosa qui. Gli utenti odiano, odio , odio , ODIO DRM. Questo è il motivo per cui nessuna azienda di media ottiene alcuna trazione quando tenta di utilizzarla.

Il kicker qui è che il contratto dice "ragionevole sforzo migliore", e non ho la più pallida idea di cosa significhi in un tribunale.

Quello che vuoi fare è rendere felice il tuo cliente con il DRM che indossi. Non so che cosa pensa il tuo cliente di DRM, può fare, costi in risorse, o se il tuo cliente è effettivamente consapevole che DRM può essere davvero fastidioso. Dovresti rispondere a questo. Puoi provare a educare il cliente, ma potrebbe essere visto come un tentativo di spiegare il lavoro scadente.

Se il cliente non è soddisfatto, la posizione di fallback successiva deve essere pagata senza contenzioso e, affinché ciò accada, il contratto deve essere ragionevolmente chiaro. Purtroppo, "ragionevole sforzo migliore" non è chiaro, quindi potresti finire in tribunale. Potresti essere in grado di rinegoziare parti del contratto a favore del cliente, oppure no.

Se tutto il resto fallisce, speri di vincere il caso giudiziario.

Non sono un avvocato e questo non è un consiglio legale. Lo considero più una questione di aspettative e una possibile interpretazione legale che una questione tecnica. Non credo che possiamo aiutarti qui. Dovresti consultare un avvocato specializzato in questo genere di cose e non so nemmeno quale specialità raccomandare. Se sei negli Stati Uniti, chiama la tua associazione di avvocati locale e chiedi un rinvio.

Non vedo alcun impatto sugli utenti onesti qui, i file sarebbero collegati all'utente, indipendentemente dal fatto che ciò accada sul lato client o server. Questo dà un'altra possibilità a quelli in 1.

I file associati all'utente richiedono un metodo per verificare l'esistenza di un utente. Cosa succede quando il server di verifica si arresta (o viene interrotto, come ha fatto Wal-Mart)?

Non esiste un livello di DRM che non influisca almeno su alcuni "utenti onesti".

I dati possono essere copiati Finché l'hardware client, autonomo, non è in grado di distinguere tra un "buono" e un "cattivo" copia, finirai per limitare tutte le copie generali e copia i meccanismi . La maggior parte delle aziende DRM affronta questo fatto dicendomi quanto questa tecnologia mi rende libero. Quasi come se le persone iniziassero a credere quando sentono la stessa cosa abbastanza spesso ...

Il codice non può essere protetto sul client. La protezione del codice sul server è un problema ampiamente risolto. Proteggere il codice sul client non lo è. Tutti gli approcci attuali hanno restrizioni avari.

Impact funziona in modo sottile. Come minimo, hai il costo aggiuntivo di implementare il DRM lato client (e tutti i costi di follow-up, inclusa l'orda di " DMCA " - urlando gorilla avvocato) È difficile dimostrare che compenserai questo costo con l'aumento delle entrate.

Non si tratta solo di codice e crittografia. Una volta implementato il DRM lato client, si scatena una catena di eventi in Marketing, Pubbliche Relazioni e Legale. Finché non si fermano per alienare gli utenti, non devi preoccuparti.

Se il server serve il contenuto senza protezione, è perché la crittografia è per client.

Detto questo, WireShark vanificherà i tuoi piani più elaborati.

La crittografia da sola è in genere valida quanto l'invio di un booleano che ti dice se ti è permesso usare il contenuto, poiché il bypass di solito sta cambiando l'input / output in una chiamata API di crittografia ...

Se si desidera utilizzare una pesante offuscamento binario sul lato client se si desidera mantenere la protezione letteralmente per più di 5 minuti. Utilizzando la decrittografia sul lato client, assicurarsi che i dati non possano essere riprodotti e che l'unico modo per bypassare il sistema sia di decodificare l'intero schema di protezione binaria. Fatto correttamente, questo fermerà tutti i bambini.

In un'altra nota, se si tratta di un prodotto da eseguire su un sistema operativo, non utilizzare anomalie specifiche del processore o del sistema operativo come Windows PEB / TEB / syscalls e bug del processore, questi faranno solo il programma ancora meno portatile di quanto non sia già il DRM.

Oh, e per rispondere al titolo della domanda: No. È una perdita di tempo e denaro e farà in modo che il tuo prodotto non funzioni sul mio sistema Linux potenziato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow