разумно ли защищать содержимое drm'd на стороне клиента
https://stackoverflow.com/questions/1822309
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Обновить: этот вопрос конкретно касается защиты (шифрования / обфускации) содержимого на стороне клиента по сравнению сделаю это перед передачей с сервера.Каковы плюсы / минусы использования подхода, подобного подходу itune, при котором файлы не шифруются / запутываются перед передачей.
Как я добавил в своем примечании к первоначальному вопросу, существуют действующие контракты, которые мы должны соблюдать (как и в случае с большинством сервисов, реализующих drm).Мы настаиваем на бесплатности drm, и большинство сделок с контент-провайдерами заключены именно на этом, но это не освобождает нас от уже существующих обязательств.
Недавно я прочитал некоторая информация что касается того, как itunes / fairplay подходит к drm, и не ожидал увидеть, что сервер фактически обслуживает файлы без какой-либо защиты.
Цитата из этого ответ кажется, это улавливает суть вопроса.
Целью должно быть просто "поддерживать честность честных людей".Если мы пойдем дальше этого, произойдут только две вещи:
- Мы ведем битву, которую не можем выиграть.Те, кто хочет обмануть, добьются успеха.
- Мы причиняем вред честным пользователям нашего продукта, усложняя его использование.
Я не вижу здесь никакого влияния на честных пользователей, файлы будут привязаны к пользователю - независимо от того, происходит ли это на стороне клиента или сервера.Это дает еще один шанс тем, кто находится в 1.
Дополнительный кусочек информации:клиентская среда - Adobe Air, в которой задействовано несколько типов контента (музыка, видео, flash-приложения, изображения).
Итак, разумно ли делать как у itune fairplay и защищать сторону медиа-клиента?
Примечание: Я думаю, что unbreakable DRM - это неразрешимая проблема и поскольку большинство ищет ответ на этот вопрос, необходимость в нем связана с тем, что он уже заключен в контракте с контент-провайдерами ...в духе разумных максимальных усилий.
Решение
Чтобы ответить на вопрос "разумно ли это", вам должно быть ясно, когда вы используете слово "защищать", от чего вы пытаетесь защититься...
Например, пытаетесь ли вы:
- авторизованным пользователям запрещено использовать загруженный ими контент через ваше приложение при определенных обстоятельствах (например,истечение срока аренды, копирование на другой компьютер и т.д.)?
- авторизованным пользователям запрещено использовать загруженный ими контент через любое приложение при определенных обстоятельствах (например,истечение срока аренды, копирование на другой компьютер и т.д.)?
- неавторизованным пользователям запрещено использовать контент, полученный от авторизованных пользователей через ваше приложение?
- неавторизованным пользователям запрещено использовать контент, полученный от авторизованных пользователей через любое приложение?
- известных пользователей от доступа к неоплаченному/несанкционированному контенту из медиатеки на вашем сервере через ваше приложение?
- известных пользователей от доступа к неоплаченному/несанкционированному контенту из медиатеки на вашем сервере через любое приложение?
- неизвестным пользователям запрещен доступ к медиатеке на вашем сервере через ваше приложение?
- неизвестным пользователям запрещен доступ к медиатеке на вашем сервере через любое приложение?
и т.д...
"Любое приложение" из приведенного выше списка может включать в себя такие вещи, как:
- другие программы плеера, предназначенные для взаимодействия с вашим сайтом (например для flickr)
- программы, предназначенные для преобразования контента в другие форматы, возможно, не связанные с DRM
- враждебные программы, предназначенные для
Из статьи, на которую вы ссылаетесь, вы можете начать знакомиться с некоторыми возможными ограничениями применения DRM на стороне клиента...
Третий, первоначально использовавшийся в PyMusique, Linux-клиенте для iTunes Store., притворяется iTunes.Он запрашивал песни с серверов Apple, а затем загружал купленные песни, не блокируя их, как это сделал бы iTunes.
Четвертый, используемый в FairKeys, также притворяется iTunes;он запрашивает ключи пользователя с серверов Apple, а затем использует эти ключи для разблокируйте существующие купленные песни.
Ни один из этих подходов не требовал взлома применяемой DRM или даже взлома какого-либо из задействованных продуктов;их можно было бы сделать, просто пассивно наблюдая за соответствующими протоколами, а затем имитируя их.
Таким образом, возникает вопрос:вы пытаетесь защититься от подобных атак?
- Если да, то применяемый клиентом DRM является неразумно.
- Если нет (например, вы беспокоитесь только о том, чтобы люди использовали ваше приложение, как это делает Apple / iTunes), то это может быть так.
(повторите этот процесс для каждой ситуации, о которой вы можете подумать.Если ответ adig всегда либо "применяемый клиентом DRM защитит меня", либо "Я не пытаюсь защититься от этой ситуации", тогда разумно использовать DRM, применяемый клиентом.)
Обратите внимание, что для последних четырех моих примеров, хотя DRM защитит от таких ситуаций в качестве побочного эффекта, это не лучшее место для применения этих ограничений.Такого рода ограничения лучше всего применять на сервере в процессе входа в систему / авторизации.
Другие советы
Я думаю, вы можете что-то здесь упустить. Пользователи ненавидят, ненавидят , ненавидят , ненавидят DRM. Вот почему ни одна медиа-компания не получает никакой поддержки, когда они пытаются ее использовать.
Ключевым моментом здесь является то, что в контракте написано «разумное наилучшее усилие», и я не имею ни малейшего представления о том, что это будет означать в суде.
То, что вы хотите сделать, - это порадовать вашего клиента DRM, который вы надели. Я не знаю, что ваш клиент думает о DRM, что он может делать, затрачивает ресурсы или знает ли ваш клиент о том, что DRM действительно раздражает. Вы должны ответить на это. Вы можете попытаться обучить клиента, но это можно рассматривать как попытку объяснить некачественную работу.
Если клиент недоволен, следующей резервной позицией является оплата без судебных разбирательств, и для этого контракт должен быть достаточно ясным. К сожалению, «разумное наилучшее усилие» не ясно, так что вы можете оказаться в суде. Возможно, вам удастся пересмотреть некоторые части договора в пользу клиента или нет.
Если ничего не помогает, вы надеетесь выиграть судебное дело.
Я не юрист, и это не юридическая консультация. Я считаю это скорее вопросом ожиданий и возможного юридического толкования, чем техническим вопросом. Я не думаю, что мы можем помочь вам здесь. Вы должны проконсультироваться с юристом, который специализируется на подобных вещах, и я даже не знаю, какую специальность рекомендовать. Если вы находитесь в США, позвоните в местную коллегию адвокатов и попросите направление.
Я не вижу здесь никакого влияния на честных пользователей, файлы будут привязаны к пользователю - независимо от того, происходит ли это на стороне клиента или сервера. Это дает еще один шанс для тех, кто в 1.
Для файлов, привязанных к пользователю, требуется какой-то метод проверки наличия пользователя. Что происходит, когда ваш сервер верификации выходит из строя (или прекращает работу, как это сделал Wal-Mart)?
Не существует уровня DRM, который не затрагивал бы, по крайней мере, некоторых "честных пользователей".
Данные можно копировать Пока клиентское оборудование, автономное, не может различить «хорошее» и "плохо" копировать, вы в конечном итоге ограничиваете все общие копии и копируете механизмы . Большинство DRM-компаний имеют дело с этим фактом, говоря мне, насколько эта технология освобождает меня. Почти как если бы люди начинали верить, когда слышали одно и то же достаточно часто ...
Код не может быть защищен на клиенте. Защита кода на сервере - в значительной степени решенная проблема. Защита кода на клиенте - нет. Все современные подходы идут с скупыми ограничениями.
Воздействие работает незаметно. По крайней мере, у вас есть дополнительные затраты на внедрение DRM на стороне клиента (и все последующие расходы, включая орду "DMCA" - кричать адвокату горилл) Трудно доказать, что вы компенсируете эти расходы за счет увеличения доходов. <Ч>
Это не просто код и криптография. После внедрения DRM на стороне клиента вы запускаете цепочку событий в области маркетинга, связей с общественностью и права. Пока они не перестают отталкивать пользователей, вам не нужно об этом беспокоиться.
Если сервер обслуживает контент без защиты, то это потому, что шифрование выполняется для каждого клиента.
При этом, Wireshark помешает вашим лучшим планам.
Шифрование само по себе так же хорошо, как отправка логического значения, сообщающего, разрешено ли вам использовать содержимое, поскольку обход обычно просто изменяет ввод / вывод на один вызов API шифрования ...
Вы хотите использовать сильное двоичное запутывание на стороне клиента, если хотите, чтобы защита буквально удерживалась более 5 минут. Используя расшифровку на стороне клиента, убедитесь, что данные не могут быть воспроизведены, и что единственный способ обойти систему - это восстановить всю схему двоичной защиты. Правильно сделанный, это остановит всех детей.
С другой стороны, если это продукт, предназначенный для работы в операционной системе, не используйте аномалии, характерные для процессора или операционной системы, такие как ошибки Windows PEB / TEB / syscall и ошибки процессора, из-за этого программа только изменит программу. даже менее портативный, чем DRM уже есть.
Да, и ответить на заголовок вопроса: Нет. Это пустая трата времени и денег, и ваш продукт не будет работать в моей усиленной системе Linux.
