В "Об утверждении Положения о лицензировании... шифровальных... средств..." сказано, что под него не попадает деятельность с использованием

оборудования, криптографические возможности которого недоступны пользователю, специально разработанного и ограниченного для осуществления следующих функций:

• исполнение программного обеспечения в защищенном от копирования виде;
  ...
  
• контроль копирования аудио- и видеоинформации, защищенной авторскими правами;

DRM ("Digital Rights Management" или "Технические средства защиты авторских прав") в контенте, распространяемом онлайн, под эти исключения попадает или нет? Т.е.:

• Программы, которые защищают свой двоичный код, шифруя его (от shareware до компьютерных игр);
  
• Проигрыватели от онлайн-кинотеатров, которые скачивают аудио/видео в шифрованном виде;

или под "оборудованием" здесь понимается исключительно физический товар — скажем, видеопроигрыватели, телевизоры, процессоры (микрокод)?

Конечно, под "оборудованием" обычно понимаются устройства, станки, приборы, но это юридический документ — где-то может быть постановление/закон/разъяснение ВС, расширяющие терминологию или соответствующее разъяснение от правительства. По этому поводу нашлось только старые темы где-то 2011 года — до принятия текущего варианта.

---

Ну и чтобы дважды не спрашивать:

л) шифровальных (криптографических) средств, используемых для защиты технологических каналов информационно-телекоммуникационных систем и сетей связи, не относящихся к критически важным объектам;

— это HTTPS/TLS/SSL и прочие?

Здравствуйте, Alexey F, Вы писали:

По первой части вопроса -- а Вы спрашиваете как пользователь системы DRM или как производитель? Если как производитель, то Вы используете свою собственную криптографию, или чужую — например, криптопровайдер, встроенный в Windows? Насколько я знаю под лицензирование подпадает из всего перечисленного мной только вариант, когда вы самостоятельно разрабатываете реализацию криптоалгоритмов, или когда перепродаете DRM, а не используете как пользователь исключительно для собственных нужд.

По второй части:
AF>

л) шифровальных (криптографических) средств, используемых для защиты технологических каналов информационно-телекоммуникационных систем и сетей связи, не относящихся к критически важным объектам;

Насколько я знаю, этот пункт относится к технологической канальной аппаратуре операторов связи (то есть например высокоскоростные шифраторы в каналах сотовой связи).

Здравствуйте, AShirmanov, Вы писали:

AS>По первой части вопроса -- а Вы спрашиваете как пользователь системы DRM или как производитель? Если как производитель, то Вы используете свою собственную криптографию, или чужую — например, криптопровайдер, встроенный в Windows? Насколько я знаю под лицензирование подпадает из всего перечисленного мной только вариант, когда вы самостоятельно разрабатываете реализацию криптоалгоритмов, или когда перепродаете DRM, а не используете как пользователь исключительно для собственных нужд.

Один open source игровой движок, который я собираюсь использовать, шифрует байткод пользовательких скриптов с помощью AES-256 (в будущем, может быть, собираются распространить шифрование на все пользовательские ресурсы). Ключ по-умолчанию забит нулями, но при желании можно перекомпилировать движок на произвольный 256-битный ключ. Как я полагаю, это сделано для реализации простенькой DRM или нечто схожее по назначению.

Проблема в том, что для распространения игр на этом движке нужно брать с собой их бинарники, в которых AES-256 используется (+ будет, возможно, использоваться) примерно для:

• исполнение программного обеспечения в защищенном от копирования виде;
  
• контроль копирования аудио- и видеоинформации, защищенной авторскими правами;

(хотя тут скорее защита от реверс-инженеринга и от модификации — защита от копирования в некотором виде (копирование байт-кода программы)).

Сижу и думаю — выбросить всё это дело из своей сборки и сделать ticket о замене схемы шифрования на 56-битную или всё это попадает под исключения.

AS>Насколько я знаю, этот пункт относится к технологической канальной аппаратуре операторов связи (то есть например высокоскоростные шифраторы в каналах сотовой связи).
Ой, а они ещё там работу с HTTPS/SSL-сертификатами прикрутили. Лучше тоже выбросить, да? Или пару приседаний сделать, чтобы добиться

м) товаров, у которых криптографическая функция гарантированно заблокирована производителем.

?

Здравствуйте, Alexey F, Вы писали:

AF>Сижу и думаю — выбросить всё это дело из своей сборки и сделать ticket о замене схемы шифрования на 56-битную или всё это попадает под исключения.

Насколько я знаю, в российских законах нигде нет пункта по 56 бит. Формально да хоть один бит, если алгоритм попадает под определение, то уже "средство..." Неформально же, вообще-то на рынке таки немало разных DRM и около DRM-продуктов предлагается и как-то не слышно, чтобы к примеру, Microsoft получала российскую лицензию на разработку (или специальное разрешение на ввоз), несмотря на наличие не то, что DRM, а вообще битлокера и EFS. Или Adobe за защищенный PDF и прочие вещи и многие другие фирмы.

Здравствуйте, Michael7, Вы писали:

M>Насколько я знаю, в российских законах нигде нет пункта по 56 бит. Формально да хоть один бит, если алгоритм попадает под определение, то уже "средство..."
А это?

Настоящее Положение не распространяется на деятельность с использованием:
...
б) шифровальных (криптографических) средств, а также товаров, содержащих шифровальные (криптографические) средства, реализующих либо симметричный криптографический алгоритм, использующий криптографический ключ длиной, не превышающей 56 бит, либо асиметричный криптографический алгоритм, основанный либо на методе разложения на множители целых чисел, размер которых не превышает 512 бит, либо на методе вычисления дискретных логарифмов в мультипликативной группе конечного поля размера, не превышающего 512 бит, либо на методе вычисления дискретных логарифмов в иной группе размера, не превышающего 112 бит;

(по ссылке). Или я как-то неправильно интерпретирую?

M>Неформально же
Неформально это да Формально, Вассенаарские договорённости не должны распространяться на свободно распространяемые среди публики программы ((PDF) если я правильно читаю "General software note"), но на эту деталь забили

Но вот здесь, к примеру, тот же Касперский предлагает AES-256 шифрование с эффективной длиной ключа в 56 бит.

Здравствуйте, Alexey F, Вы писали:

AF>Здравствуйте, Michael7, Вы писали:

M>>Насколько я знаю, в российских законах нигде нет пункта по 56 бит. Формально да хоть один бит, если алгоритм попадает под определение, то уже "средство..."
AF>А это?

Спасибо! То ли не было раньше, то ли я как-то очень невнимательно читал получается. Извиняюсь, что чуть было не дезинформировал.

M>>Неформально же
AF>Неформально это да Формально, Вассенаарские договорённости не должны распространяться на свободно распространяемые среди публики программы ((PDF) если я правильно читаю "General software note"), но на эту деталь забили

По-моему, ограничения такого рода на криптографию у нас вводились без связи с этими соглашениями. Они, если я правильно понимаю, не запрещают иметь более жесткие нормы внутри страны.

AF>Но вот здесь, к примеру, тот же Касперский предлагает AES-256 шифрование с эффективной длиной ключа в 56 бит.

Любопытно. То есть, они сами честно признались, что у их продукта по современным меркам можно сказать, что почти никакая криптостойкость. Хотя конечно свести к перебору 10^16 ключей может быть не так просто, но тем не менее. И однако все же непонятно с Microsoft и Adobe получается. И огромной кучей других от браузеров (ssl) до архиваторов с паролем. То ли у них реальная эффективность такая же низкая, то ли что.

Что до обычных чьих-то программ, не исключено, что еще и принцип "неуловимого Джо" работает, особенно если не позиционировать ее для защиты информации и не использовать определенные термины. И если речь идет про игровой движок, который пользовательские скрипты шифрует, то это вообще реально нужно вам (хоть с 56-бит, хоть нет) или может быть проще выкинуть этот участок.

Как вариант, что если сделать чтобы все преобразования, работали с отдельной стандартной либой (openssl например), которая легко может быть заменена. Смысл в том, чтобы распространять без всякого шифрования, с заглушкой вместо него, и не иметь никаких проблем с тем, чего нет, но его пользователю можно было бы при желании легко прикрутить, скачав стороннюю библиотеку (если ее еще нет) и поправив пару строчек в конфиге, чтобы подключить вместо заглушки openssl или еще что.