Pull to refresh

Comments 78

> поэтому eToken – не более чем флэшка с паролем и замысловатым интерфейсом.
Меня это тоже удивило в свое время.
При выборе токена задавайте производителю самый первый вопрос — извлекаемое или неизвлекаемое хранение?
И у Аладдина и у Рутокена сейчас есть в прайсе и первого и второго вида, как для RSA так и для ГОСТ-а, в т.ч. нового (2012 года).
Просто необходимо выбирать для нужных целей нужные модели.
С одной стороны да, такие решения есть, с другой — бремя выбора токена лежит на производителе ПО, а я пока что не видел ни одного ПО, в том числе и продвигаемого ЦБ, которое могло бы использовать токены JaCarta.
Райфайзеновский корпоративный КБ сейчас работет с JaCarta нормально
Федеральная служба по регулированию алкогольного рынка РФ — egais.ru работает только с джакартой
Но… Ключи для производителей на eToken и RuToken, подключится к ЕГАИС производителя (или как его называет ФСРАР — «Классический ЕГАИС») с помощью JaCarta нельзя.
Я про egais.ru, а вы про service.fsrar.ru
пришли мы к выводу, что передавать надо с помощью scp

Интересно, почему выбрали scp? Рассматривали ли решения по управляемому файлообмену (MFT)?

Все эти ключи успешно прошли копирование и работали.

А как ключи на этих носителях были сгенерированы? использовали какой-то csp?
Интересно, почему выбрали scp? Рассматривали ли решения по управляемому файлообмену (MFT)?
Ну, тогда стоят вопрос о том, чтобы сделать быстро и из того, что есть и знакомо.
Однако сейчас, после того, как я узнал об отсутствии сложностей на пути чтения с токена для злоумышленника, мы снова в поиске.
Сейчас по запросу «управляемый файлообмен MFT» гуглится в основном OpenTrust MFT, который лично мне показался оверкилом для цели передачи из А в Б.

А как ключи на этих носителях были сгенерированы? использовали какой-то csp?
Крипто-Ком: ключи сгенерированы банком, в дальнейшем при перегенерация идет в ActiveX библиотеке (которую я и рассматривал) и новый ключ кладется на токен (в моем примере — в папку DDDD). Также пробовал программу Admin-PKI.
Message-Pro: аналогично, банком.
Крипто-Про: ключи генерировались на сайте УЦ «Крипто-Про», насколько я понимаю, тоже посредством ActiveX или Java
Сигнатура и Верба: соответствующим ПО.
>ни одно из СКЗИ, одобренных ФСБ для использования на территории РФ (вроде бы) не использует RSA
Если подсунуть libeTPkcs11.so или его виндовый аналог фаерфоксу или java keytool'у, то вроде можно сгенерировать RSA ключ. Он в таком случае будет неизвлекаемым или токен сгенерирует ГОСТ-овский ключ?
И есть ли эта замечательная библиотека под Linux (у меня стоит Safenet client, но такой библиотеки нет).

Также хотелось бы узнать, можно ли загружать свои java card апплеты на токены с поддержкой java. Интересная технология, хочется попробовать.
Для работы с неизвлекаемыми ключами, а также апплетами у производителя, видимо, есть другие API, в то время как рассматриваемое в статье используется только для работы с файловой системой.
Если вы сгенерируете RSA ключ и поместите его в специальную область на токене, то токен сможет этим ключом генерировать подпись для ваших данных, но о ГОСТовских алгоритмах в случае eToken Pro речи не идет.
В своё время брал eToken Java и нет, загружать туда апплеты нельзя. Техподдержка ответила, что ключи для загрузки они меняют на случайные при инициализации токена и нигде не хранят.
Есть наработки по реверсу аппаратного ГОСТ-токена из комплекта CryptoPro Rutoken CSP. В кратце сделано практически всё, кроме того, что надо понять как преобразуется пароль от ключа в тот вид, который передаётся на токен. Если есть кто готов присоединиться, то Welcome. Конечная цель поддержка всякой аппаратной ГОСТ-криптотни под линуксом.
dev.rutoken.ru/pages/viewpage.action?pageId=18055184. Работает под Linux
Во-первых, не хочется пользоваться закрытыми библиотеками. Во-вторых, с помощью openssl не возможно создать сертификат и/или запрос на него, который удовлетворял бы требованиям приказа ФСБ. Проблема в том, что приказ требует наличия доп.полей (таких как СНИЛС, ИНН и т.д.) хитрых типов, а openssl использует дефолтные. В-третьих, Рутокен ЭЦП это совсем не то же самое, что носитель из комплекта CryptoPro Rutoken CSP, второй имеет дополнительную функциональность и защиту каждого отдельного ключа отдельным паролем, а не одним ПИН-кодом на весь брелок. В-третьих, в перспективе планирую поддерждать ещё и УЭК.
Во-вторых, с помощью openssl не возможно создать сертификат и/или запрос на него, который удовлетворял бы требованиям приказа ФСБ. Проблема в том, что приказ требует наличия доп.полей (таких как СНИЛС, ИНН и т.д.) хитрых типов, а openssl использует дефолтные.

Возможно. Через API openssl. Через тулзу openssl возможно, начиная с версии openssl 1.1.0.
Мы сейчас готовим совместимую с этой версией сборку engine pkcs11_gost. Заодно в ней будет и поддержка новых криптографических ГОСТ-ов.
В-третьих, Рутокен ЭЦП это совсем не то же самое, что носитель из комплекта CryptoPro Rutoken CSP, второй имеет дополнительную функциональность и защиту каждого отдельного ключа отдельным паролем, а не одним ПИН-кодом на весь брелок.

Вообще говоря, в Рутокен ЭЦП есть поддержка Secure Messaging-протокола, обеспечивающего защиту канала между Рутокен ЭЦП и библиотекой pkcs11. Если интересны нюансы, то в личку.

> Через API openssl.

Это да.

> Secure Messaging-протокола, обеспечивающего защиту канала между Рутокен ЭЦП и библиотекой pkcs11. Если интересны нюансы, то в личку.

А разве API PKCS #11 позволяет указывать что-то кроме ПИН-кода токена (административного и пользовательского)? Просто не очень понятно, как это заюзать. Либо тут уже библиотека должна через какой-то другой интерфейс запрашивать у пользователя пароль ключа, когда к нему идет обращение.
А что плохого в закрытых библиотеках, если ключ в любом случае не извлекается? Какой смысл в подмене своей библиотекой одной из частей программно-аппаратного комплекса? Конечно, дело благородное, но с чего вы внезапно взяли, что написанная вами открытая библиотека будет корректно работать с токеном с точки зрения безопасности? Желательно, не с точки зрения интуиции.
В частности, упомянутый ранее CryptoPro Rutoken CSP является полноценным ПАК, где токен и программные библиотеки — равнозначно важные сущности.
Про УЭК, кстати, интересно. Что значит, «поддержать»? Он ведь проводит ряд защищенных процедур на неопубликованных протоколах (это не значит, что они плохие/кривые/проприетарные), а затем включает шифрованный канал.
Совсем забыл небольшой вопрос: если вы «отцепляете» токен от СКЗИ, то зачем вообще будут использоваться ГОСТ-алгоритмы? Купите обычные западные токены и работайте спокойно с виндовыми провайдерами.
> Он ведь проводит ряд защищенных процедур на неопубликованных протоколах

Совершенно верно. Идея в том, чтобы это реверснуть. Это не так сложно, как может показаться на первый взгляд.

> Совсем забыл небольшой вопрос: если вы «отцепляете» токен от СКЗИ, то зачем вообще будут использоваться ГОСТ-алгоритмы?

Послушайте, требование использовать сертифицированные ФСБ СКЗИ — это больше требования для институциональных учреждений (банков, ведомств, мед.учреждений и т.д.) Для меня, как для конечного пользователя, доверие к себе многократно выше, чем доверие к конторе, которая сертифицировала что-то кому-то. Поэтому я вполне могу использовать любую реализацию ГОСТа, и это никак не обнаружит ни один мой контрагент.

> Купите обычные западные токены и работайте спокойно с виндовыми провайдерами.
Западные токены, к сожалению, не дают мне возможности использовать криптографию для нужд юридически значимых внутри России.
> Совершенно верно. Идея в том, чтобы это реверснуть. Это не так сложно, как может показаться на первый взгляд.

Ого, ну, что называется, будет очень здорово, если получится. Но когда застрянете где-то, вспомните мои слова :)

> Для меня, как для конечного пользователя, доверие к себе многократно выше, чем доверие к конторе, которая сертифицировала что-то кому-то.

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

> Западные токены, к сожалению, не дают мне возможности использовать криптографию для нужд юридически значимых внутри России.

Осуществить юридически значимые нужды с ГОСТ-криптографией, но несертифицированной, да еще и на коленке сделанной, тоже весьма затруднительно. Приведу пример: для понимания базовых принципов криптоалгоритмов и прокачки навыка разрабоки я иногда даю своим студентам задания в духе «реализуй ГОСТ хххх-хх» или «встрой туда-то реализацию OpenSSL».
Хотите сказать, что их поделки, имеющие в коде функции типа gost_encrypt_megasecure, тоже применимы в юридически значимом документообороте?
Хотите сказать, что их поделки, имеющие в коде функции типа gost_encrypt_megasecure, тоже применимы в юридически значимом документообороте?


Вы так говорите, будто подобные поделки не имеют сертификатов ФСТЭК и ФСБ.
Я, конечно, не уверен, но не думаю, что мои студенты сразу после сдачи лаб отправляют их в органы :)

А если речь о промышленных разработках, то хотелось бы услышать более адекватные доводы, чем «всем хорошо известно».
> что мои студенты сразу после сдачи лаб отправляют их в органы :)

Разумеется, потому что у них нет ни лицензии на разработку СКЗИ, ни денег на их сертификацию ) А вот мой друг, будучи студентом, сидел и пилил openssl на поддержку ГОСТ, только не увас на лабах, а в лицензированной конторе в Питере. И сертифицировали же потом )
> А что плохого в закрытых библиотеках, если ключ в любом случае не извлекается? Какой смысл в подмене своей библиотекой одной из частей программно-аппаратного комплекса?

Ещё один нюанс забыл. Смотрите, если вы пользовались хоть раз какими-то ГосУслугами или системой электронного ДО, где имеется авторизация или подпись документа по ключем, то должны были обратить внимание, что то, что плагин браузера посылает на подпись в токен, совершенно вам не видно. То есть вы вслепую подписываете что-то, надеясь на то, что это то же, что и на странице браузера. Это очень неправильно. Я хочу это ликвидировать, добавив возможность просмотреть подписываемое сторонним приложением, встроившись между плагином и библиотекой токена.
> совершенно вам не видно
Для этого есть средства визуализации подписи (см. Rutoken PinPad или SafeTouch). Не нужно городить огороды. Да, в конце концов, если уж так хочется, можно поставить отладчик APDU-инструкций, ловить хэш, отправляющийся на подпись в токен, и его печатать пользователю.
> Для этого есть средства визуализации подписи (см. Rutoken PinPad или SafeTouch).

Они поддержаны в Linux? Что делать тем, у кого УЭК или такой носитель как у меня? Повесится от несовершенства мира?

> Да, в конце концов, если уж так хочется, можно поставить отладчик APDU-инструкций, ловить хэш, отправляющийся на подпись в токен, и его печатать пользователю.

А что собственно даст пользователю значения хэша? Да и какое-то решение из области заката солнца вручную. Неудобство использования инструментов защиты информации играет против их корректного применения. Описанная схема слишком сложна, чтобы средний пользователь мог её безопасно использовать.
> Они поддержаны в Linux? Что делать тем, у кого УЭК или такой носитель как у меня? Повесится от несовершенства мира?

Вполне поддержаны. Насчет поддержки УЭК рутокен — точно нет, а для SafeTouch не вижу проблемы. Какой носитель у вас, я не знаю.

> А что собственно даст пользователю значения хэша?

Ну, если хотите, получайте это значение, считайте хэш от тех данных, что подписываете и сравнивайте: примерно так вся эта визуализация и работает.

> средний пользователь мог её безопасно использовать

С чего вы взяли, что к полученной системе будет применимо слово «безопасно»?
> Ну, если хотите, получайте это значение, считайте хэш от тех данных, что подписываете и сравнивайте: примерно так вся эта визуализация и работает.

Очень удобно, не правда ли? )

> С чего вы взяли, что к полученной системе будет применимо слово «безопасно»?

Я буду стремиться к тому, что к ней будет применимо слово «безопасней» по сравнению подписью чего-то вслепую. Кроме того, заставлять кого-либо пользоваться этим я не собираюсь.

Только не пытайтесь меня убедить, что сертификаторы ФСБ неимоверно крутые спецы, которые глазами анализируют исходники и ищут в них уязвимости и их сертификция — это клеймо безупречного качества. Я знаю как это делается. По крайней мере делалось некоторое время назад. Это очень формальный и практически бесполезный процесс, который стоит весьма хороших денег.

Ну и наконец, что конкретно вы предлагаете в условиях, когда производителю в основном пофиг на Linux. Тупо сидеть и ничего не делать? Прекрасный план!
> вы вслепую подписываете что-то, надеясь на то, что это то же, что и на странице браузера

Так это еще не самое смешное. Самое, как мне кажется, состоит в том, что владелец ЭЦП в том виде, в каком ее нынче выдает большинство (если не все) УЦ, совершенно не причастен к генерации секретного ключа, поскольку получает от УЦ уже готовый криптоноситель.

То есть, по сути, это не «подпись», а некий аналог печати. И нет никакого способа проверить, сколько было изготовлено экземпляров этой печати, и где они находятся — все упирается в абсолютное доверие к УЦ и его сотрудникам.

Не упирается ничего в доверие. Все упирается в тупость этих людей, которые так делают. Позвоните в ллюбой УЦ, только не тупыми продажникам, а сразу в саппорт, и спросите как сделать сертификат через запрос. Процентов 75 УЦ уже так умеют делать. Просто встаньте на их место. Вот приходит к вам председатель ТСЖ 65 лет отряду (ТСЖ обязаны иметь ЭП) и говорит: сынок, мне бы подпись эту диавольскую заиметь. А ты такой: придерживайтесь отец, смотрите вот Алиса, вот Боб, она пишет ему письмо, а на почте их читает Ева… )))

Ну вот я не далее, как вчера, покупал ЭЦП в новосибирском ООО «РУЦ», который аккредитован аж с 2013-го, в отличие от большинства новоявленных. И спросил их специалиста, который непосредственно занимался изготовлением сертификата, каким образом обеспечивается защита секретных ключей, если их генерирует сам УЦ, и почему они не делают, как это принято у серьезных организаций, сертификатов по запросу. Получил ответ, что это прямое требование какого-то там ФЗ, а иначе, мол, невозможно обеспечить защиту и бла-бла-бла. В дискуссию я вдаваться не стал. :)

Из других аккредитованных «не вчера» хотел сперва ткнуться в Департамент информационного развития и отделение Пенсионного фонда, но они выпускают ЭЦП исключительно для госконтор и организаций самоуправления, вроде тех ТСЖ.

Вообще, грустно наблюдать, как под эгидой «информатизации» и «безопасности» тупо пилят бабло, пользуясь дремучестью большинства юзеров.
Я знаю только один кейс, когда выработка ключа в УЦ обязательна. Для таможни и чего-то там ещё требуют сертификат, в котором УЦ должен вставить OID, что закрытый ключ к этому сертификату выработан на аппаратном носителе (типа Рутокен ЭЦП 2.0). В этом случае УЦ вырабатывает его сам на этом носителе и генерирует сертификат, но в этом случае как бы есть «гарантия», что закрытый ключ не покинет носитель даже в УЦ.

А не могу коментировать ваш пересказ чьих-то слов, не зная полного диалога. Если вы в Новосибирске, то прибегните к услугам Такском. Они совершенно точно умеют через запрос.
Спасибо, в следующий раз попробую. Я искал по списку УЦ, аккредитованных Минсвязи, и по Новосибирску наиболее серьезным показался РУЦ, а посмотреть местные отделения федеральных УЦ я не догадался.

Сейчас уже нет смысла обращаться куда-то еще — сертификат изготовлен, использовать я его буду для отправки отчетности по ИП в ФНС, так что явной опасности компрометации ключей нет.

Кстати, Вы не в курсе, что за странная ситуация с драйверами eToken? Gemalto их свободно не раздает, а УЦ, выдающие сертификаты для подписи кода (DigiCert, GlobalSign и т.п.) почему-то раздают собственные лицензированные версии SafeNet Authentication Client'ов. Чем объясняется такая политика? Или эта область настолько хлебная, что даже драйверы в свободный доступ выложить жалко?
И на сколько вас раздел этот самый РУЦ за подпись для ИП, если не секрет?

Касательно гемальты — никогда не пользовался их продуктами и не собираюсь. Там судя по всему полные штаны security by obscurity, от того и поведение такое. Как они сделали электронные паспорта с уязвимостями для, кажется, эстонцев и испанцев, хватает, чтобы всю мощь этой конторы осознать.
Не секрет — 2500. :) Полный комплект из подписи, токена и бессрочной лицензии КриптоПро они продают за 4300, вполне по-божески.

Я бы тоже не пользовался, но DigiCert и GlobalSign дают EV-сертификаты для подписи кода только на eToken. Российскую ЭЦП тоже решил записать на eToken, наивно полагая, что драйверы с Authentication Client от GlobalSign уже стоят, останется лишь поставить КриптоПро или VipNet. Однако ж, Authentication Client вообще не видит на этом токене ничего, полагая его чистым, только по паролю авторизуется. Контейнер становится виден только в КриптоПро CSP.

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

Оно все такое, или есть вменяемые решения? Как-то интуитивно казалось, что любой аппаратный ключ должен иметь некую универсальную ФС, универсальный же менеджер для нее, а уже поверх этого должны работать надстройки.
Эм… тут вопрос очень многоуровневый. Вся эта хрень, в том числе с плагинами к браузеру для подписи, и вообще кастомных браузеров для SSL по ГОСТу (CryptoFox, Яндекс.Браузер) — это не от хорошей жизни. Чуваки из libnss и разрабы Хрома стоят горой перед любыми попытками включить алгоритмы ГОСТ и соответствующие ciphersuite'ы в библиотеку. Сам многократно вступал с ними в дискуссию. Причем у меня было полное ощущение, что я попал на Russia Today, точнее на USA Today.

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

Далее, касательно содержания токена. Если мы говорим о тупом токене, который хранит в извлекаемом виде ключи, то действительно там есть более-менее стандартная «файловая» система. Но вот содержание файлов не стандартизировано. Каждое СКЗИ может туда писать в своём формате. Очевидно, что тогда другое СКЗИ не будет видеть эту инфу.

А вот если токен претендует на умность — например, аппаратная ЭП или блочное шифрование, то тут уже мыши впляс — каждый вендор во что горазд. Тот же еТокен (если это не узконишевая версия), если я правильно помню умеет все эти RSA/DSA аппаратно делать неизвлекаемым ключем. А ключи ГОСТ он умеет хранить только в тупом виде.
А как могла сложиться ситуация, в которой каждое СКЗИ использует свой формат? Насколько я понимаю, на токене хранятся только сертификаты и ключи, форматы которых стандартизированы и устаканены десятки лет назад, одновременно с расширениями соответствующих файлов. По-моему, когда УЦ инициализирует токен с помощью того же КриптоПро, и после этого никто, кроме КриптоПро, не может с этим токеном работать — безусловный и законченный идиотизм. Но такая схема почему-то считается не только допустимой, но еще и «высокопрофессиональной». :)
Нет, там ещё хранится метаинформация. Как то: имя контейнера, его флаги. Например, флаг того, что ключ «некопируемый» — тогда софтина, уважающая этот флаг, откажется копировать ключ ) Ну всякое такое околомаркетойдное добро. Расширений файлов там нет. «Имена» файлов на файловых системах смарт-карт (а именно так прикидывается обычный токен) числовые. Конкретным числам присваивают конкретную семантику. Это так обычно работает.

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

И политика распространения софта тоже изумляет: можно купить токен в магазине, но софт к нему придется добывать извилистыми путями — или через поставщика сертификата, или через переговоры с производителем, или из левых источников.
Слушайте, я использую для этих целей Рутокен. Там такой проблемы нет, всё выложено у них на сайте.
То есть, eToken можно считать неудачным исключением, где все через задницу, или он таки не исключение?
Я за всю Одессу не готов говорить. Я не занимаюсь этим профессионально. Просто мне не безразличны кое-какие моменты во всей этой околоГОСТовой движухи, и я слежу за темой.

На сколько мне известно, ключевые носители делают Рутокен, Аладин (теперь Гемальто) и ещё джакарта. Вот про последнюю я вообще ничего не знаю. Остальные два кейса нами с вами покрыты )
Спасибо, попробую следующую подпись взять на рутокене, авось не так будет раздражать. :)
Вообще было бы весело прийти к этому кренделю в УЦ со своим носителем, который ими не поддерживается и посмотреть, как они будут выпускать на нём сертификат ) У меня такой нестандартный носитель был (Функциональный ключевой носитель из комплекта КриптоПро Рутокен CSP).

Любил я им вымораживать поддержку разных УЦ ) К сожалению, неудачно повернулся в кресле и снёс этот брелок, когда он был вставлен в системник. Покупать новый нету смысла, т.к. с нового года старые ГОСТы превращаются в тыкву, а новых он не умел.

Зато теперь покупаю только «микро» варианты токенов — которые не торчат на 5 сантиметров, будучи вставленными в порт ) И вам советую )
Подозреваю, что они сразу бы и заявили, что данный тип не поддерживается, а такое-то положение устава/регламента не обязывает их записывать сертификат в неподдерживаемый носитель. :)

Я, честно говоря, вообще не пользовался бы токенами — абсолютной защиты они не дают (есть трояны, умеющие прикидываться пользователем), но пришлось — тот же GlobalSign принципиально не желает выпускать сертификат в файле. Подозреваю, что есть возможность его как-то обмануть, подменив модули CSP или ссылки на них, но это уже хлопотно, проще смириться.
Когда речь про тупой токен, то я тоже не вижу разницы с обычной флэшкой. Когда речь про смарт-токен (с неизвлекаемым ключом), то максимум, что может сделать троян — это подписать моей подписью что-то своё. Ключ выкрасть не получится. Конечно, теоретически может быть такой троян, который получает какой-то документ на подпись через бэкдор и подписывает его. Но, обычно, хакеру требуется больше времени на то, чтобы придумать что делать с информацией, чем на том, чтобы её получить. Так что получив удалённый доступ к смарт-токену — совершенно не факт, что найдётся что-то что нужно будет ей подписать )
Недавно где-то видел рассказ о том, как троян подписал за юзера банковскую платежку — разумеется, со своими реквизитами. :)
Это ещё что! У нас дело уже дошло до хранения закрытых ключей в облаке )
Если те ключи надежно зашифрованы, и расшифровываются только на стороне клиента — это ничем не хуже хранения на сменном носителе или в реестре, как это умеет сертифицированный со всех сторон КриптоПро. :)
Нет, вы не поняли. Как они там хранятся — хз. Но там не только хранение, там же в облаке и криптопровайдер, который, например, через вэб-интерфейс может подписывать загружаемые в облако документы. То есть доступ к ключам там есть не только у владельца ключа, но и у владельца облака как минимум.

«Приватный ключ, доступ к которому имеют более одного человека, называется публичным ключом» (с) )))
У-у-у, это жесть, согласен. :)

Прошло 3 года...

Теперь это - тренд!

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

Такие дела, тёзка ;)

Спасибо. Стоит SafeNet client, с ним не завелось, говорит об ошибке авторизации на токене — пин код даже не запрашивается. Возможно, оно с ним несовместимо… Вот только параллельно PKI Client не ставится.
Как я говорил, в скрипте нет уймы проверок, которые могли бы сказать подробнее.
Возможно не прошел Bind, а возможно, сопоставление Id. Попробуйте повыводить значение разных переменных в консоль с помощью ConsoleWrite($Var&@CRLF)
После установки PKI Client завелось.

Но спотыкнулось об ETDirEnumNext — ошибку здесь выдаёт. Не знаю правда какую.

И на ETFilesEnumNext тоже.
Токен от какой СКЗИ пытаетесь копировать?
Это не от СКЗИ, я пытаюсь считать данные корпоративного токена.

Я прогнал в цикле по всем возможным RootDir — такое ощущение что они все пустые.
Возможно, он у вас использует тот самый неизвлекаемый RSA-ключ?
На токенах с неизвлекаемым ключем всё равно RootDir обычно не пустой. Там как правило хранится сертификат, открытый ключ и какая-нибудь мета-информация типа имени контейнера или его ID. И файл, в который «записывают» подписываемый хэш, например.

Хотя безусловно, можно избежать концепции файлов полностью, используя полность проприетарный APDU-субпротокол.
Честно говоря не знаю. Это eToken Pro 72k (Java)
Для копания в eToken была (может всё ещё есть, но, возможно, только у разработчиков) утилита eToken Editor.
Также с ключами работал OpenSC.
Пробовали такие?



Первая входит в пакет разработчика, поэтому у меня ее не было. Вторую не пробовал.
Кстати, глядя на ваш скриншот:
В коде часто встречалась строка «AKS ifdh» — так обозначаются смарт-карты, которые не брелки?
В данном случае это точно были eToken. Этих идентификаторов могло быть больше, чем реальных устройств. Я для себя понимал это как аналог точки монтирования, чтобы она оставалась после отключения физического устройства и можно было на неё настроить ПО.
А у вас не остался этот eToken Editor?
Даже если и лежит где-то в архивах, он с вероятностью 99% не работает с современными драйверами и устройствами. Оно должно быть в SDK.
Всё же если остался скиньте плз, хочу попробовать. Желательно виндовую версию. Сам етокен достаточно старый, может быть и получится.
К сожалению не сохранилось.
Если вы что-то разрабатываете для организации или занимаетесь интеграцией, запросите у Aladdin SDK, кажется его бесплатно отдают (но не уверен, что всем).
Интересно, после этого компании закроются, или всем всё пофиг и «ключи безопаснее пароля, продолжайте кушать кактус»?

С другой стороны, возможность выковырять ключ открывает волшебные возможности к написанию софтового эмулятора, позволяющего засунуть всё в виртуалку и не париться.
А что такого здесь сенсационного? Те, кто плотно занимается криптографией, знали этот факт с незапамятных времен. Никто никого не обманывает. Сотрудники обеих компаний честно отвечают на правильно поставленные вопросы.
Чем тогда токен отличается от дискетки с файлом и ради чего весь сыр-бор?
В данном конкретном случае наличием системы разграничения доступа. Потеря дискеты влечет компрометацию ключа, а для получения ключа с токена нужно еще подобрать пароль, на что даётся ограниченное число попыток.
Думаю, прежде чем писать подобные «разгромные» статьи, следует разобраться в мат.части, тем более, что она уже неоднократно обсуждалась на этом ресурсе.
Смарт-карты (так же как и USB-ключи) имеют защищённое хранилище, в котором лежат закрытые ключи, сгенерированные непосредственно на смарт-карте, некоторые смарт-карты позволяют импортировать в данное защищённое хранилище ключи, сгенерированные за пределами смарт-карты. При этом, ключи могут быть как RSA, так и ГОСТ (например, Gemalto CryptoPro ФКН, JaCarta ГОСТ, ruToken — не помню точно как называется модель). То есть если ключ сгенерирован на смарт-карте, то он никогда эту смарт-карту не покидает и является неизвлекаемым. И вся работа с закрытым ключом происходит только внутри смарт-карты.
Но исторически сложилось так, что на Российском рынке сначала появились ключи, которые умели только RSA и совсем не умели ГОСТ. При этом, компании — разработчики крипто-провайдеров решили использовать данные ключи как флешку с пин-кодом. То есть, те же Крипто Про, СогналКом, ЛИССИ и другие генерируют криптопару (открытый и закрытый ключи) на компьютере и далее кладут криптоконтейнер на смарт-карту в её файловое хранилище (доступ к которому Вы и получили). При этом, при работе, криптоконтейнер (вместе с закрытым ключом) копируется на компьютер, распаковывается и используется для вычислений. При таком подходе, в момент работы с закрытым ключом, он находится в памяти компьютера в открытом виде.
Таким образом, неизвлекаемость ключа обеспечивается его правильной генерацией.
А если Вы работаете с продуктом, который использует смарт-карту как обычную флешку с пин-кодом, тогда она и будет выполнять роль флешки. И не понимаю чем вызвано подобное удивление.
Как мне всегда говорили старшие коллеги — RTFM!

Попытался использовать Ваши скрипты с SAC 10.6 и etsdk.dll 1.0.0.47. eTokenCopy при любых вставленных токенах (Pro 72k, 5110) отображает "False (False)" в обоих полях. Первый простой скрипт для перечисления обнаруживает ридер, но выдает ошибку 12 из ETTokenBind.

Не помните, какие версии etsdk.dll и софта SafeNet стояли у Вас?

Sign up to leave a comment.

Articles