est-il raisonnable de protéger le contenu du client drm'd

Question

Mise à jour: cette question concerne spécifiquement la protection (chiffrement / obscurcissement) du côté client du contenu par rapport à sa réalisation avant la transmission à partir du serveur. Quels sont les avantages / inconvénients d’une approche comme celle d’itune - dans laquelle les fichiers ne sont pas chiffrés / obscurcis avant leur transmission?

Comme je l'ai ajouté dans ma note à la question initiale, il existe des contrats en vigueur auxquels nous devons nous conformer (comme c'est le cas pour la plupart des services qui implémentent la gestion des droits). Nous insistons pour que cela soit gratuit, et la plupart des offres des fournisseurs de contenu sont sur le marché, mais cela ne nous libère pas des obligations déjà en place.

J'ai récemment lu certaines informations sur la manière dont itunes / fairplay s’applique à drm et ne s’attendaient pas à voir le serveur servir les fichiers sans aucune protection.

La citation de cette answer semble capturer l'esprit du problème.

  

L’objectif devrait simplement être de "conserver   des gens honnêtes honnêtes " ;. Si nous y allons   plus loin que cela, seulement deux choses   arriver:

     

  
1. Nous livrons une bataille que nous ne pouvons pas gagner. Ceux qui veulent tricher vont réussir.
  
2. Nous nuisons aux utilisateurs honnêtes de notre produit en le rendant plus difficile à utiliser.
  

Je ne vois aucun impact sur les utilisateurs honnêtes ici, les fichiers seraient liés à l'utilisateur, que cela se produise côté client ou côté serveur. Cela donne une autre chance à ceux de 1.

Une information supplémentaire: l'environnement client est Adobe Adobe Air, plusieurs types de contenu sont impliqués (musique, vidéo, applications Flash, images).

Alors, est-il raisonnable de faire comme le fairplay d'itune et de protéger le côté client multimédia.

Remarque: Un DRM indestructible est un problème insoluble et la plupart des personnes à la recherche d'une réponse à ce problème sont liées au fait qu'il est déjà passé un contrat avec des fournisseurs de contenu ... dans des efforts raisonnables.

Answer 1

Pour répondre à la question "est-ce raisonnable", vous devez être clair lorsque vous utilisez le mot "protéger" ce que vous essayez de protéger contre ...

Par exemple, essayez-vous de:

1. a autorisé les utilisateurs à utiliser le contenu téléchargé via votre application dans certaines circonstances (par exemple, l'expiration de la période de location, la copie sur un autre ordinateur, etc.)?
2. a autorisé les utilisateurs à utiliser le contenu téléchargé via toutes les applications dans certaines circonstances (par exemple, l'expiration de la période de location, la copie sur un autre ordinateur, etc.)?
3. les utilisateurs non autorisés à utiliser le contenu reçu d'utilisateurs autorisés via votre application ?
4. les utilisateurs non autorisés à utiliser le contenu reçu d'utilisateurs autorisés via une application ?
5. des utilisateurs connus ayant accédé à un contenu non acheté / non autorisé à partir de la médiathèque de votre serveur via votre application ?
6. des utilisateurs connus ayant accédé à un contenu non acheté / non autorisé à partir de la bibliothèque multimédia de votre serveur via une application ?
7. utilisateurs inconnus ayant accès à la médiathèque sur votre serveur via votre application ?
8. utilisateurs inconnus ayant accès à la médiathèque sur votre serveur via une application ?

etc ...

"Toutes les applications" dans ce qui précède peut inclure des choses comme:

• autres programmes de lecteur conçus pour interagir / coopérer avec votre site (par exemple, pour flickr )
• programmes conçus pour convertir le contenu vers d'autres formats, éventuellement non DRM
• programmes hostiles conçus pour

À partir de l'article que vous avez lié, vous pouvez voir certaines des limitations possibles de l'application du côté client DRM ...

  

  

• Le troisième, initialement utilisé dans PyMusique, un client Linux pour iTunes Store, prétend être iTunes . Il a demandé des chansons aux serveurs d'Apple, puis a téléchargé les chansons achetées sans les verrouiller , comme le ferait iTunes.

  

• Le quatrième, utilisé dans FairKeys, prétend également être iTunes ; il demande les clés d'un utilisateur aux serveurs d'Apple, puis utilise ces clés pour déverrouiller les chansons achetées existantes .

  

Aucune de ces approches n’a nécessité d’interrompre le DRM, ni même de pirater l’un des produits en cause; ils pourraient être faits simplement en observant passivement les protocoles impliqués, puis en les imitant.

La question est donc la suivante: essayez-vous de vous protéger contre ce type d’attaque?

• Si la réponse est oui, le DRM appliqué par le client n'est pas raisonnable .
• Si non (par exemple, si vous êtes concerné uniquement par les utilisateurs de votre application, comme le fait Apple / iTunes), il se peut que ce soit le cas.

(Répétez cette procédure pour chaque situation à laquelle vous pouvez penser. Si le paramètre est toujours "le DRM appliqué par le client me protégera" ou "je n'essaie pas de protéger contre cette situation", puis utiliser un DRM appliqué au client est une solution envisageable .)

_{Notez que pour les quatre derniers de mes exemples, alors que DRM protégeait contre ces situations en tant qu'effet secondaire, ce n'est pas le meilleur endroit pour appliquer ces restrictions. Ces types de restrictions s’appliquent mieux au serveur lors du processus de connexion / autorisation.}

Answer 2

Je pense que vous ratez peut-être quelque chose ici. Les utilisateurs détestent, détestent , détestent , HATE . C’est la raison pour laquelle aucune entreprise de médias n’obtient la moindre traction quand elle essaie de l’utiliser.

Answer 3

Le contrat dit que le contrat dit "effort raisonnable raisonnable", et je n'ai pas la moindre idée de ce que cela signifiera pour un tribunal.

Vous voulez que votre client soit satisfait du DRM que vous avez mis. Je ne sais pas ce que votre client pense de la gestion des droits numériques, peut faire, des coûts en ressources, ou si votre client est réellement conscient que la gestion des droits numériques peut être vraiment ennuyeuse. Vous devrez répondre à cela. Vous pouvez essayer d’éduquer le client, mais cela peut être perçu comme une tentative d’expliquer un travail insatisfaisant.

Si le client n'est pas satisfait, la prochaine solution de repli consiste à être payé sans litige. Pour que cela se produise, le contrat doit être raisonnablement clair. Malheureusement, " meilleur effort raisonnable " n'est pas clair, alors vous pourriez vous retrouver devant un tribunal. Vous pourrez peut-être renégocier des parties du contrat en faveur du client, ou pas.

Si tout échoue, vous espérez gagner le procès.

Je ne suis pas avocat, et ce n’est pas un conseil juridique. Je vois cela davantage comme une question d’attente et d’interprétation juridique possible que comme une question technique. Je ne pense pas que nous puissions vous aider ici. Vous devriez consulter un avocat spécialisé dans ce genre de choses et je ne sais même pas quelle spécialité recommander. Si vous résidez aux États-Unis, appelez l’association du barreau de votre région et demandez une référence.

Answer 4

  

Je ne vois aucun impact sur les utilisateurs honnêtes ici, les fichiers seraient liés à l'utilisateur, que cela se produise côté client ou côté serveur. Cela donne une autre chance à ceux de 1.

Les fichiers liés à l'utilisateur nécessitent une méthode de vérification de la présence d'un utilisateur. Que se passe-t-il lorsque votre serveur de vérification tombe en panne (ou est arrêté, comme Wal-Mart l'a fait)?

Il n'y a pas de niveau de DRM n'affectant pas au moins certains "utilisateurs honnêtes".

Answer 5

Les données peuvent être copiées . Tant que le matériel client, seul, ne peut pas faire la distinction entre un "bon" et le "bon" et un " mauvais " copie, vous finirez par limiter toutes les copies générales et copiez les mécanismes . La plupart des entreprises de DRM gèrent ce fait en me disant à quel point cette technologie me rend libre. Presque comme si les gens commençaient à croire quand ils entendent assez souvent la même chose ...

Le code ne peut pas être protégé sur le client. La protection du code sur le serveur est un problème en grande partie résolu. Protéger le code sur le client n'est pas. Toutes les approches actuelles viennent avec des restrictions radines.

Impact fonctionne de manière subtile. Au minimum, vous avez le coût supplémentaire de la mise en œuvre de la GDN côté client (ainsi que tous les coûts de suivi, y compris la horde de "DMCA" - en criant les avocats des gorilles) Il est difficile de prouver que vous compenserez ce coût par l’augmentation des revenus.

Il ne s'agit pas uniquement de code et de crypto. Une fois que vous avez implémenté la GDN côté client, vous déclenchez une chaîne d'événements dans les domaines du marketing, des relations publiques et du droit. Tant qu'ils ne cessent pas d'aliéner les utilisateurs, vous n'avez pas besoin de vous embêter.

Answer 6

Si le serveur sert le contenu sans protection, c'est parce que le cryptage est effectué par client.

Cela étant dit, Wirehark déjouera vos meilleurs plans.

Answer 7

Le cryptage seul est généralement aussi efficace que d'envoyer un booléen vous indiquant si vous êtes autorisé à utiliser le contenu, car le contournement consiste généralement à modifier l'entrée / la sortie en un seul appel d'API de cryptage ...

Vous souhaitez utiliser une obfuscation binaire lourde du côté client si vous souhaitez que la protection soit maintenue pendant plus de 5 minutes. En utilisant le déchiffrement côté client, assurez-vous que les données ne peuvent pas être réexécutées et que le seul moyen de contourner le système consiste à effectuer un reverse engineering du schéma de protection binaire complet. Correctement fait, cela arrêtera tous les enfants.

Par ailleurs, s’il s’agit d’un produit devant être exécuté sur un système d’exploitation, n’utilisez pas d’anomalies spécifiques au processeur ou au système d’exploitation telles que les PEB / TEB / syscalls Windows et les bogues du processeur, cela ne fera que rendre le programme encore moins portable que DRM est déjà.

Oh, et pour répondre au titre de la question: non. C'est une perte de temps et d'argent, et votre produit ne fonctionnera pas sur mon système Linux renforcé.