28 Февраля, 2017

Мнение по поводу истории с продажами eToken в России

Алексей Комаров

К посту « Кто производит eToken? » читатели блога написали уже немало комментариев (и дискуссия всё ещё продолжается), обсуждения были также и в Facebook. Напомню, что суть моего поста был в том, что у ключей (и смарт-карт) eToken есть вполне конкретный производитель (SafeNet/Gemalto), который публично объявил , что не имеет никаких торговых отношений с российской компанией Аладдин Р.Д. При этом для собственных ключей Аладдин Р.Д. (JaCarta), работающих в режиме (эмуляции) совместимости с eToken, требуется установка ПО (драйвера) как раз производства SafeNet/Gemalto: eToken PKI Client или SafeNet Authentication Client.

В комментариях есть немало обвинений в адрес компании Аладдин Р.Д., в том числе и в нарушении законодательства. Не склонен их разделять и попробую изложить свою точку зрения на происходящие события.

Прежде всего нужно напомнить, что именно компания Аладдин Р.Д. оказала существенное влияние на становление в России рынка решений по строгой аутентификации. Мне довелось когда-то работать в Аладдин Р.Д. и как раз в направлении, продающем eToken. Могу сказать, что сил и руководством компании и сотрудниками для продвижения продуктов Aladdin Knowledge Systems  (тогда независимой израильской компании) на российском рынке прикладывалось немало и это принесло свои плоды: eToken на долгие годы стал у нас стандартом де-факто.

Однако, в бизнесе, как и в жизни, всегда найдётся место неприятным сюрпризам. Aladdin Knowledge Systems была куплена SafeNet , а та в свою очередь — Gemalto . Есть в этой истории и ещё один важный игрок — Athena SmartCard Solutions  (Athena SCS). Это производитель и поставщик чипов для eToken (ну и софта также), который тоже был куплен — компанией NXP .

В таких условиях череды подряд идущих слияний и поглощений российской компании Аладдин Р.Д. пришлось что-то делать, как-то выкручиваться. Была выбрана стратегия перехода на собственный бренд — JaCarta. По иронии судьбы, анонс появления JaCarta был написан именно мной  пять лет назад в блоге ещё до официального объявления самой компании. Официального анонса бренда JaCarta, к слову, так и не состоялось.

Называю JaCarta брендом, а не продуктом, так как под этим зонтичным названием на рынке продавались и продаются самые разные продукты от самых разных производителей. Никто, в общем-то, и не ожидал, что можно просто так взять и быстро повторить успех, например, той же компании Актив с её Рутокенами. Всё же дистрибуция, пусть и успешная, чужого отличного продукта — это одно, а запуск производства собственного аппаратного решения — совсем другое. Вот и собрали под бренд JaCarta микс из решений различных компаний.

Как показали дальнейшие события, за последующие 5 лет у Аладдин Р.Д. так и не получилось полностью отказаться от продаж eToken и окончательно переключиться на JaCarta. Вплоть до сегодняшнего дня Аладдин Р.Д. продаёт и те и другие ключи, правда об окончании продаж и поддержки eToken всё же объявила .

Тут нужно сделать краткое отступление: Аладдин Р.Д. имеет полное право сообщать о своих планах по прекращению своих продаж (тем более, что Gemalto публично объявила, что никаких торговых отношений с ней не имеет с 01 января 2017 года), но оформлять информационное сообщение и сам документ с извещением так, как будто eToken совсем уходит с Российского рынка и снимается с поддержки — это не корректно. Вообще, в этом документе хватает крайне спорных тезисов, но, судя по версии документа 5.1 — это не ошибки, а умышленное преподнесение информации именно в таком свете.

Для тех, кто планирует приобретение именно ключей eToken — вот краткая памятка:

Где официально купить eToken?

Где официально купить eToken?

Вообще, во всей этой истории перехода на новый бренд, самое неудачное решение Аладдин Р.Д., на мой взгляд, заключается в том, что решили для JaCarta городить огород с эмуляцией eToken. Все нюансы мне доподлинно не известны, поэтому могу лишь предположить, что не хотелось терять проделанную многолетнюю работу по интеграции eToken с самыми разными сторонними решениями, а продавать JaCarta своим клиентам вместо eToken наоборот хотелось очень. А может, просто не вышло сделать нормальный JaCarta SDK для разработчиков и у тех плохо получалось поддерживать JaCarta.

Например, жил-был некий банк, для доступа к Интернет-банку которого прекрасно можно было использовать eToken. Банк потратился на разработку своего ПО, отладил софт, обучил сотрудников поддержки решению проблем у клиентов. И вот ему предлагают перейти на JaCarta. Нужно ли это банку? Сложно ли это сделать? Предполагаю, ответы: «не очень» и «достаточно». А вот если банку предложить JaCarta, которая будет работать точно так же как eToken, и переписывать в своём софте банку ничего не надо будет, то получаем совсем иной расклад.

В любом случае, факт остаётся фактом. В официальном руководстве администратора Единого клиента JaCarta чётко указано:

Для использования электронных ключей eToken, а так же для использования полной функциональности электронных ключей JaCarta PKI и JaCarta PKI/ГОСТ с функцией обратной совместимости с продуктами компании Aladdin необходимо, чтобы на компьютере был установлен eToken PKI Client 5.1 SP1/SafeNet Authentication Client версии 8.0 SP2 и выше.

Вот эту медленно тикающую бомбу Аладдин Р.Д. сама себе и подложила. Если твоё аппаратное решение для корректной работы у заказчиков требует стороннее ПО, которое ты не разрабатываешь и каналы распространения которого не контролируешь, то проблемы — это лишь вопрос времени.

Возникает, кстати, резонный вопрос — как вообще можно эмулировать eToken? Судя по комментариям в блоге и в Facebook, просто в чипах JaCarta (является одним из примеров реализации  Java Card ), которые Athena SCS поставляла для Аладдин Р.Д., заливался апплет  eToken. Да-да, напомню , что по нотификациям на ввоз от 2012 и 2014 годов производителем JaCarta значится Athena Smartcard Solutions, Inc. и никакой это не российский импортозамещающий продукт (подробнее тут ):

Нотификации JaCarta

Нотификации JaCarta

Именно этот апплет (есть предположение, что конкретно речь идёт о eToken Java Applet 1.0.37) обеспечивал в JaCarta необходимый функционал от eToken и именно из-за него требуется наличие драйверов eToken PKI Client или SafeNet Authentication Client.

Уверен, что операция по заливке этого апплета на JaCarta была согласована и вряд ли тут есть какие-то нарушения, да вот только из-за постоянных поглощений, видимо, все имеющиеся договорённости с завидной регулярностью отправлялись в тартарары. По опыту тех поглощений вендров, которые доводилось видеть (если так можно выразиться) близко, первое время — год или даже больше — новый владелец старается ничего не менять и даже возникает ощущение, что всё будет как раньше, но потом практически внезапно может поменять ключевых партнёров, правила лицензирования или даже полностью продуктовую линейку.

Скорее всего и по вопросу распространения компанией Аладдин Р.Д. eToken PKI Client и SafeNet Authentication Client были какие-то договорённости. В конце концов, нелицензионное использование — этот действительно нарушение законодательства (и не только российского). Вот, например, что ответил мне Промсвязьбанк на вопрос, почему они через свой сайт распространяют чужое ПО, которое им предоставил не производитель (SafeNet/Gemalto), а компания, с которой производитель не имеет торговых отношений:

По Вашему вопросу сообщаем, что использование программного обеспечения SAC (SafeNet Authentication Client) осуществляется Банком правомерно на основании заключенных договоров. Каких-либо претензий относительно незаконного использования программного обеспечения SAC (SafeNet Authentication Client) в Банк не поступало.

Сама Аладдин Р.Д. после моей публикации тоже поменяла текст на странице для скачивания SAC:

Заявка для скачивания SafeNet Authentication Client - Было

Заявка для скачивания SafeNet Authentication Client — Было

Заявка для скачивания SafeNet Authentication Client - Стало

Заявка для скачивания SafeNet Authentication Client — Стало

Раз Gemalto не идёт в суд — значит имеет для этого причины и не нам обвинять Аладдин Р.Д. в нарушении законодательства. Ну, по крайней мере, не мне — так как вообще не являюсь клиентом ни Аладдин Р.Д., ни Промсвязьбанка.

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

Однако, вовсе не является компания Аладдин Р.Д. и невинной жертвой сговора импортных производителей, стремящейся заботиться исключительно о своих клиентах. Понятно же, что во главе угла коммерческие интересы, и лишь определённые (скорее всего технические) трудности не дали просто так отказаться от eToken, вот и началась петрушка с разными видами JaCarta (PRO, PKI) и с эмуляцией eToken. При этом делалось всё крайне непублично: что-то просто не договаривалось, где-то были и откровенные передёргивания фактов. Особенно весело было наблюдать подтирания компанией Аладдин Р.Д. с сайтов различного рода информации после моих публикаций =)


В заключение, видимо, надо дать какие-то рекомендации по использованию ключей. Попробую рассмотреть различные сценарии.

Если вы уже купили JaCarta и всё работает — ну и прекрасно, пользуйтесь дальше, пока действует гарантия и устройство не выйдет из строя. Вот если вдруг отзовут сертификат ФСТЭК (не знаю, впрочем, есть ли для этого хоть какие-то основания), а у вас версия сертифицированная, тогда, конечно, могут быть трудности, но наш уважаемый регулятор обычно отличается крайне взвешенной позицией и интересы добросовестных заказчиков точно будет учитывать. Что же касается нелегальности использования драйверов в режиме эмуляции — производитель никаких официальных заявлений по этому поводу не делал, и, в любом случае, уверен, не в его интересах преследовать заказчиков, проще подождать естественного процесса перехода от JaCarta обратно на eToken.

Если нужно докупить ещё JaCarta к имеющимся и принципиальна именно эмуляция eToken, то не проще ли купить просто eToken? Мне представляется, что гораздо проще.

Если вы счастливый обладатель eToken, то, судя по отдельным комментариям, есть некая вероятность, что eToken ваш не настоящий. На мой взгляд, такого откровенного мошенничества не было: да, апплет eToken для поддержания эмуляции eToken может быть загружен, но не думаю, что кто-то клепал поддельные eToken и массово их продавал. На всякий случай я задал соответствующий вопрос компании SafeNet через их форму обратной связи — если ответят, дополню посту. В общем, пока я тоже не рекомендовал бы предпринимать каких-то радикальных действий, разве что подумайте о смене поставщика, если вы планируете приобретать дополнительные eToken — официальные партнёры в России есть на картинке-памятке выше.

Наконец, что делать, если вы только планируете приобретать USB-ключ? Что выбрать?

Начну с самого простого — выбор ключевого носителя с поддержкой ГОСТ и с необходимыми сертификатами ФСБ. В ноябре прошлого года делал соответствующее сравнение из которого вывод напрашивается сам собой:

Поддержка ГОСТ алгоритмов и особенности сертификации токенов с действующими сертификатами ФСБ

Поддержка ГОСТ алгоритмов и особенности сертификации токенов с действующими сертификатами ФСБ

Так как Аладдин Р.Д. прекращает продажи изделий с Криптотокен ЭП (с 01 декабря 2017 года), то у них остаётся единственный вариант — JaCarta ГОСТ с сертификатом СФ/124-2963. Вот только в этом сертификате не указано, что Криптотокен 2 соответствует требованиям приказа ФСБ №796 и федеральному закону 63-ФЗ, так что JaCarta с этим сертификатом не может использоваться для реализации функций электронной подписи.

Остаются варианты — MS_KEY K и РУТОКЕН ЭЦП/ЭЦП 2.0, из которых только РУТОКЕН ЭЦП 2.0 поддерживает новые ГОСТ Р 34.10-2012 и Р 34.11-2012. Если же планируется использование ключа не в качестве средства ЭП, да ещё и не нужны новые алгоритмы, то выбор, понятно, шире.

А вот какой USB-ключ выбрать, если поддержка ГОСТ не принципиальна, вопрос более сложный. Особенно, если речь идёт не о двух-трёх штуках (тут хоть по цвету выбирай), а о крупном внедрении, да ещё и, например, с необходимостью внедрения системы централизованного управления ключевыми носителями.

Выбор, пожалуй, сводится к четырём альтернативам:

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


Пожалуй, это основное, что пока хотелось бы сказать по теме. Впрочем, не исключаю, что для прояснения нюансов всё же ещё раз или даже несколько к вопросу вернусь.

Надеюсь, все стороны этой истории продолжат (а кто-то — начнёт) вести себя корректно, не будут умышленно никого вводить в заблуждение и продолжат развивать сегмент решений по строгой аутентификации на российском рынке.

comments powered by Disqus