17.5.13

Jaibreak or not jailbreak?

Я не буду подробно говорить о СКЗИ для iOS, которая для своей установки требует jailbreak. Это, на мой взгляд, не вина разработчика. У него простой выбор - сделать продукт, востребованный рынком, или не делать его. Очевидно, что потребность в сертифицированной криптографии для смартфонов и планшетников компании Apple достаточно высока и было бы неправильным не воспользоваться такой возможностью увеличить свои доходы. Дальше разработчик начинает анализировать возможность реализации продукта с учетом требований будущей сертификации и понимает, что для успешного прохождения 8-го Центра и ЦЛСЗ ФСБ и получения заветной бумажки необходимо обойти ограничения, установленный компанией Apple (т.е. произвести jailbreak). И он, взвесив все "за" и "против" выпускает такой продукт и сертифицирует его в ФСБ. При этом сам разработчик, как бы и не нарушает ничего, т.к. jailbreak должен делать не он, а потребитель, купивший сертифицированную систему криптографической защиты. 

Потребитель тоже стоит перед выбором и взвешивает, какие риски выше? Применения несертифицированной СКЗИ на легальной iOS (например, Cisco AnyConnect или множества иных VPN-клиентов) или сертифицированной СКЗИ на "взломанной" iOS? При этом варианты использование специализированного прикладного ПО с встроенной сертифицированной СКЗИ я не рассматриваю - спектр их применения не очень велик ввиду их заточенности под конкретные применения.

Но дело не в рисках потребителя (а вопрос применения в этом случае 146-й статьи УК РФ вполне может стоять на повестке дня - нашелся бы тот, кто подаст в суд на нарушителя). И не в рисках производителя. Я бы хотел посмотреть на ситуацию в контексте поведения регулятора, вынуждающего разработчиков и потребителей нарушать законодательство об интеллектуальной собственности. При этом сам регулятор в лице 8-го Центра открещивает от таких обвинений. Они говорят: "А мы тут ни причем. Никто никого не заставляет нарушать авторские права. Просто у нас есть требования по сертификации, а уж как их выполнить, это не наша проблема".

ФСБ - не единственный регулятор, который "не смотрит" на интеллектуальную собственность разработчиков средств защиты. ФСТЭК в своей системе сертификации средств защиты по требованиям безопасности тоже не сильно "напрягается" на эту тему. Иначе как еще можно объяснить возможность подачи заявки на сертификацию средств защиты, минуя разработчика? Вообще это нонсенс - компания-разработчик узнает о проведенной сертификации либо задним числом, либо вообще может не знать о том, что кто-то взял ее продукт, "распотрошил" его с целью оценки защитных свойств и выдал на результат потрошения сертификат соответствия! А ведь именно так и обстоит дело с большинством продуктов иностранного происхождения, присутствующих на российском рынке. В массе своей заявителями сертификации по линии ФСТЭК являются либо продавцы средств защиты, либо покупатели. Не буду говорить за других вендоров, но по Cisco, в реестре сертифицированных средств защиты присутствует около 30-40 сертификатов на маршрутизаторы Cisco ISR и столько же примерно на межсетевые экраны Cisco ASA 5500. При этом большая часть сертификатов выдана на схожие версии продуктов, но в сертификатах указаны разные заявители, разные классы защищенности МСЭ, разные классы АС/ИСПДн, в которых возможно применение средств защиты, разные ограничения на эксплуатацию... И при этом Cisco про эти сертификации никто не уведомлял. Все бы ничего, если бы такие сертификационные исследования не были бы запрещены партнерскими договорами и лицензионными соглашениями. Но при приеме средства защиты на сертификацию этот вопрос обходится вниманием. Допускаю, что по незнанию, но проблема от этого менее острой не становится.

Аналогичная ситуация с описанными вчера недекларированными возможностями. Средство защиты американского происхождения подают на сертификацию на отсутствие НДВ. Замечательно. Очень важно и нужно! А кто-нибудь побеспокоился узнать, выдана ли Минпромторгом США лицензия на проведения таких работ? Точнее на передачу конфиденциальной информации, подпадающей под экспортные ограничения, для проведения таких работ?

Да и фиг с ним, с правом на интеллектуальную собственность. Это все буржуйские заморочки и нарушение прав потребителей, которые могут делать с купленным товаром все, что угодно. Распространенная точка зрения. Именно ею мотивируют jailbreak'и многие его сторонники. Я не буду говорить, что с точки зрения безопасности тот же jailbreak это хорошо. Он не дает запускаться приложениям с административными привилегиями. Он не дает осуществлять некоторые системные вызовы и обращаться к некоторым областям памяти. Он создает для приложений некий аналог "песочницы". Он не дает копировать/красть установленные приложения. И вообще он не дает устанавливать "левые", непроверенные приложения.

Для рядового пользователя (физлица) это все не так и критично. А для корпоративного? Тут картина меняется. Да, последние внесенные изменения в закон DMCA сделали процедуру jailbreak легальной, а точнее ненаказуемой. Аналогичная ситуация и в России и в ряде других стран, но... гарантия производителя на телефон в этом случае теряется и гарантийному ремонту он уже не подлежит. При этом Apple сообщает о том, что пользователи, осуществившие jailbreak столкнулись с рядом серьезных проблем:
  • снижение уровня защищенности, кража конфиденциальной информации, проникновение вредоносных программ
  • нестабильная работа
  • снижение времени автономной работы
  • неработающие службы
  • невозможность обновления и т.д.
Не знаю насколько это информация верна, но это официальная позиция производителя, который открыто заявляет, что поддерживать такие устройства не намерен. Возникает закономерный вопрос - готова ли компания внедрить у себя сертифицированную в ФСБ СКЗИ, если условием ее установки станет полная потеря гарантии производителя на планшетник или смартфон и потенциальные проблемы с работой служб и приложений на устройстве? Где проходит грань?

Аналогичная ситуация с подменой стандартной библиотеки MS GINA, которую часто подменяют для реализации расширенных процедур входа в систему на базе Windows. На сайте Microsoft четко написано, что да, третьи лица часто подменяют MS GINA для своих целей (например, подключение аутентификации по токену или расширение стандартной парольной аутентификации биометрией), но это несет за собой риски некорректной загрузки системы или даже невозможности такой загрузки. Безусловно гарантия, которая по лицензионному соглашению Microsoft и так не сильно велика, в этом случае может быть утеряна. Схожая ситуация с встраиванием отечественной сертифицированной криптографию в продукцию Microsoft. Как прямо заявляют разработчики "MS не предоставил способа "честно" встраивать локализованную криптографию".

И вновь вопрос - кто виноват больше, разработчик, вынужденный нарушать авторское право другого разработчика, или регулятор, который своими требованиями (или отсутствие требований) вынуждает разработчика так поступать? Вопрос, конечно, риторический, но учитывая активное движение России в сторону признания международных норм по защите интеллектуальной собственности (у нас даже специальная Федеральная служба создана) может быть пора и задуматься и поменять требования как к средствам защиты, так и к оценке их соответствия.

19 коммент.:

-)гоист комментирует...

По MSGINA DLL всё-таки думается несколько не так. Производитель разрешает использование сторонней библиотеки, тогда ответственность за нее должен нести разработчик этой библиотеки. Ну а MS сами должны позаботиться о корректности работы с входными данными, получаемыми от сторонней DLL.

Анонимный комментирует...

Да, Алексей, изучи вопрос и расскажи Михаилу! А то он про требования по контролю встраивания СКЗИ не в теме как обычно ;)

2 mike:
Пример нужен? Microsoft устроит?

Анонимный комментирует...

Наши разработчики прикладных систем, которые задумываются об использовании сертифицированных СКЗИ в первую очередь стараются занять ту же позицию: мы сделаем поделку, а вопрос защищенности среды пусть решает потребитель...

Unknown комментирует...

BTW, начиная c Windows Vista реализация сторонних механизмов аутентификации стала абсолютно легальной процедурой в Windows с использованием т.н. "Credential Providers". http://msdn.microsoft.com/en-us/magazine/cc163489.aspx

doom комментирует...

> Иначе как еще можно объяснить возможность подачи заявки на сертификацию средств защиты, минуя разработчика?

Любой потребитель вправе проверить качество приобретаемого товара. Согласие производителя здесь не требуется - никакой разницы, собрался я проверить качество колбасы из магазина или качество СрЗИ именитого производителя.
В том же строительстве, если строй. материалы не были сертифицированы, то их сертифицирует сам строитель в рамках процедуры входного контроля - опять же, никакого участия производителя не требуется. Собственно, для производителя имеет смысл только сертификация производства, а все остальные схемы больше походят потребителю.

doom комментирует...

2 Alexey Goldbergs

SSPI в Windows был даже в XP, а скорее всего, и раньше - надо поискать по конкретным функциям с какой версии Windows они доступны, так что этот механизм был абсолютно легален даже до Vista.

Анонимный комментирует...

2doom:
Потребитель может быть в праве. Но тут ключевым вопросом кроме правовых является: потребитель хочет проверить соответствие СрЗИ чему? Если колбаса сделана по ГОСТ - проверить есть чему. А ТУ ? Разработчик его прячет... К тому же нужно кучку документов подготовить. Их должен сделать потребитель? Он же не может заставить разработчика! И деятельность лаборатории превращается из процедуры подтверждения в процедуру исследования! И ещё как разработчик должен относиться к тому что появляются дискредитирующие продукт документы?
Ну например, разработчик сделал колбасу по ТУ 01 а потребитель сделал сам ТУ 02 и сертифицирует по нему. А если этих ТУ ходит по стране 20 штук разных?

Алексей Лукацкий комментирует...

Алексей, а до Висты?

doom комментирует...

>Если колбаса сделана по ГОСТ - проверить есть чему.

Предлагаю сойтись на том, что если есть конкретные требования (как для тех же МЭ, IPS и пр.), то потребитель вправе нанять организацию, которая протестирует степень выполнения этих требований.
А вот разработка конструкторской документации силами потребителя/продавца это, конечно, мягко говоря, странно.

Алексей Лукацкий комментирует...

doom: мы бы сошлись, если бы у нас был процесс, связанный именно с ПРОВЕРКОЙ со стороны потребителя. Сейчас все документы ФСТЭК заточены на сертификацию продукта с нуля. Что вы, как потребитель, захотели проверить что-то, вы должны иметь весь набор документов и материалов, который требуется при исходной сертификации. Он есть только у разработчика. Чтобы такой набор появился у потребителя, он это поручает (а иначе сертификацию никто не проведет) лаборатории, которая за счет потребителя эти доки и разрабатывает.

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

Анонимный комментирует...

Ой, забыл на эту тему подписаться...

Михаил, конечно подскажу ;)

"Методические рекомендации ФСБ по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных" п.5

НИУПАЛ :) Остальное в закрытых документах, которые иностранцам вроде бы пока не дают ...

Во... Миша начал подгребать конкурентов... опять "Все так делают" :) Представитель *** начал прятаться за спину CISCO, АМТ...
Списывали чтоли :)

Анонимный комментирует...

И да, Михаил, по другим темам тоже можно, но вы уж блог сделайте, создайте тему интересную а то Эл уже на меня косо смотрит... развел тут понимаешь... стирку и ликбез ;)

Анонимный комментирует...

У Михаила есть форма допуска ?!

Кто дал? Вы что ознакомлены с закрытыми ведомственными документами? Кто вас ознакомил?

И хватит врать! Нету у Stonesoft ни лицензий ни сертификатов! Вы голодранец! Все на подставную контору.

Анонимный комментирует...

Так расскажите какое отношение вы имели к этим документам!

Анонимный комментирует...

Михаил:
"сертификация на корректность встраивания в ПКЗ 2005"

- прекратите нести бред
- и мне пофиг где вы раньше работали. Но если в ведомстве то хотя бы наберитесь совести не дискредитировать коллег, которые служат РФ а не иностранной конторе!

Unknown комментирует...

Михаил:
"а говорили что офицер запаса .... опять наврали чтоли"

Подтверждаю, Евгений офицер запаса.

"сертификация на корректность встраивания в ПКЗ 2005"

Это Вы где увидели такой бред?

Анонимный комментирует...

Олег, при всем уважении...

Михаил давно перевёл диспут в режим идиотизма... В сложившейся ситуации можно было или все поставить на места или довести до этого... Первое невозможно и Михаил конечно поступает грамотно... Кофылек кофылек какой кофылек...

Unknown комментирует...

2Евгений Родыгин:
"Михаил конечно поступает грамотно"
Считаешь? На мой взгляд, полное невежество и невменяемость. Как ты вытерпел все это?

2Алексей Лукацкий:
Не мое дело, конечно... невменяемых можно и блокировать... А то затеял ср...ть в коментах, даже я не выдержал.

Анонимный комментирует...

Капелька вкусного для STONESOFT:
1. Сертификат ФСТЭК 2157 StoneGate Firewall = может использоваться для создания АС до класса 1Г включительно.
2. Че же вы так опрометчиво впариваете партнерам выписку из ТУ в которой написано "может использоваться для организации безопасного межсетевого взаимодействия в АС до класса защищенности 1В" и это при НДВ-4...

Это вы себе класс сами разрешили поднять? Или прописанное в сертификате соответствие ТУ таким соответствием не является?