Comments 78
Меня это тоже удивило в свое время.
И у Аладдина и у Рутокена сейчас есть в прайсе и первого и второго вида, как для RSA так и для ГОСТ-а, в т.ч. нового (2012 года).
Просто необходимо выбирать для нужных целей нужные модели.
пришли мы к выводу, что передавать надо с помощью scp
Интересно, почему выбрали scp? Рассматривали ли решения по управляемому файлообмену (MFT)?
Все эти ключи успешно прошли копирование и работали.
А как ключи на этих носителях были сгенерированы? использовали какой-то csp?
Интересно, почему выбрали scp? Рассматривали ли решения по управляемому файлообмену (MFT)?Ну, тогда стоят вопрос о том, чтобы сделать быстро и из того, что есть и знакомо.
Однако сейчас, после того, как я узнал об отсутствии сложностей на пути чтения с токена для злоумышленника, мы снова в поиске.
Сейчас по запросу «управляемый файлообмен MFT» гуглится в основном OpenTrust MFT, который лично мне показался оверкилом для цели передачи из А в Б.
А как ключи на этих носителях были сгенерированы? использовали какой-то csp?Крипто-Ком: ключи сгенерированы банком, в дальнейшем при перегенерация идет в ActiveX библиотеке (которую я и рассматривал) и новый ключ кладется на токен (в моем примере — в папку DDDD). Также пробовал программу Admin-PKI.
Message-Pro: аналогично, банком.
Крипто-Про: ключи генерировались на сайте УЦ «Крипто-Про», насколько я понимаю, тоже посредством ActiveX или Java
Сигнатура и Верба: соответствующим ПО.
Если подсунуть libeTPkcs11.so или его виндовый аналог фаерфоксу или java keytool'у, то вроде можно сгенерировать RSA ключ. Он в таком случае будет неизвлекаемым или токен сгенерирует ГОСТ-овский ключ?
И есть ли эта замечательная библиотека под Linux (у меня стоит Safenet client, но такой библиотеки нет).
Также хотелось бы узнать, можно ли загружать свои java card апплеты на токены с поддержкой java. Интересная технология, хочется попробовать.
Если вы сгенерируете RSA ключ и поместите его в специальную область на токене, то токен сможет этим ключом генерировать подпись для ваших данных, но о ГОСТовских алгоритмах в случае eToken Pro речи не идет.
Во-вторых, с помощью openssl не возможно создать сертификат и/или запрос на него, который удовлетворял бы требованиям приказа ФСБ. Проблема в том, что приказ требует наличия доп.полей (таких как СНИЛС, ИНН и т.д.) хитрых типов, а openssl использует дефолтные.
Возможно. Через API openssl. Через тулзу openssl возможно, начиная с версии openssl 1.1.0.
Мы сейчас готовим совместимую с этой версией сборку engine pkcs11_gost. Заодно в ней будет и поддержка новых криптографических ГОСТ-ов.
В-третьих, Рутокен ЭЦП это совсем не то же самое, что носитель из комплекта CryptoPro Rutoken CSP, второй имеет дополнительную функциональность и защиту каждого отдельного ключа отдельным паролем, а не одним ПИН-кодом на весь брелок.
Вообще говоря, в Рутокен ЭЦП есть поддержка Secure Messaging-протокола, обеспечивающего защиту канала между Рутокен ЭЦП и библиотекой pkcs11. Если интересны нюансы, то в личку.
Это да.
> Secure Messaging-протокола, обеспечивающего защиту канала между Рутокен ЭЦП и библиотекой pkcs11. Если интересны нюансы, то в личку.
А разве API PKCS #11 позволяет указывать что-то кроме ПИН-кода токена (административного и пользовательского)? Просто не очень понятно, как это заюзать. Либо тут уже библиотека должна через какой-то другой интерфейс запрашивать у пользователя пароль ключа, когда к нему идет обращение.
В частности, упомянутый ранее CryptoPro Rutoken CSP является полноценным ПАК, где токен и программные библиотеки — равнозначно важные сущности.
Про УЭК, кстати, интересно. Что значит, «поддержать»? Он ведь проводит ряд защищенных процедур на неопубликованных протоколах (это не значит, что они плохие/кривые/проприетарные), а затем включает шифрованный канал.
Совсем забыл небольшой вопрос: если вы «отцепляете» токен от СКЗИ, то зачем вообще будут использоваться ГОСТ-алгоритмы? Купите обычные западные токены и работайте спокойно с виндовыми провайдерами.
Совершенно верно. Идея в том, чтобы это реверснуть. Это не так сложно, как может показаться на первый взгляд.
> Совсем забыл небольшой вопрос: если вы «отцепляете» токен от СКЗИ, то зачем вообще будут использоваться ГОСТ-алгоритмы?
Послушайте, требование использовать сертифицированные ФСБ СКЗИ — это больше требования для институциональных учреждений (банков, ведомств, мед.учреждений и т.д.) Для меня, как для конечного пользователя, доверие к себе многократно выше, чем доверие к конторе, которая сертифицировала что-то кому-то. Поэтому я вполне могу использовать любую реализацию ГОСТа, и это никак не обнаружит ни один мой контрагент.
> Купите обычные западные токены и работайте спокойно с виндовыми провайдерами.
Западные токены, к сожалению, не дают мне возможности использовать криптографию для нужд юридически значимых внутри России.
Ого, ну, что называется, будет очень здорово, если получится. Но когда застрянете где-то, вспомните мои слова :)
> Для меня, как для конечного пользователя, доверие к себе многократно выше, чем доверие к конторе, которая сертифицировала что-то кому-то.
Конечно, выше. И это типичная проблема подавляющего большинства тех, кто пытается самостоятельно лезть в разработку криптографии. Не забывайте, пожалуйста, про закон Шнайера.
> Западные токены, к сожалению, не дают мне возможности использовать криптографию для нужд юридически значимых внутри России.
Осуществить юридически значимые нужды с ГОСТ-криптографией, но несертифицированной, да еще и на коленке сделанной, тоже весьма затруднительно. Приведу пример: для понимания базовых принципов криптоалгоритмов и прокачки навыка разрабоки я иногда даю своим студентам задания в духе «реализуй ГОСТ хххх-хх» или «встрой туда-то реализацию OpenSSL».
Хотите сказать, что их поделки, имеющие в коде функции типа gost_encrypt_megasecure, тоже применимы в юридически значимом документообороте?
Хотите сказать, что их поделки, имеющие в коде функции типа gost_encrypt_megasecure, тоже применимы в юридически значимом документообороте?
Вы так говорите, будто подобные поделки не имеют сертификатов ФСТЭК и ФСБ.
А если речь о промышленных разработках, то хотелось бы услышать более адекватные доводы, чем «всем хорошо известно».
Разумеется, потому что у них нет ни лицензии на разработку СКЗИ, ни денег на их сертификацию ) А вот мой друг, будучи студентом, сидел и пилил openssl на поддержку ГОСТ, только не увас на лабах, а в лицензированной конторе в Питере. И сертифицировали же потом )
Ещё один нюанс забыл. Смотрите, если вы пользовались хоть раз какими-то ГосУслугами или системой электронного ДО, где имеется авторизация или подпись документа по ключем, то должны были обратить внимание, что то, что плагин браузера посылает на подпись в токен, совершенно вам не видно. То есть вы вслепую подписываете что-то, надеясь на то, что это то же, что и на странице браузера. Это очень неправильно. Я хочу это ликвидировать, добавив возможность просмотреть подписываемое сторонним приложением, встроившись между плагином и библиотекой токена.
Для этого есть средства визуализации подписи (см. Rutoken PinPad или SafeTouch). Не нужно городить огороды. Да, в конце концов, если уж так хочется, можно поставить отладчик APDU-инструкций, ловить хэш, отправляющийся на подпись в токен, и его печатать пользователю.
Они поддержаны в Linux? Что делать тем, у кого УЭК или такой носитель как у меня? Повесится от несовершенства мира?
> Да, в конце концов, если уж так хочется, можно поставить отладчик APDU-инструкций, ловить хэш, отправляющийся на подпись в токен, и его печатать пользователю.
А что собственно даст пользователю значения хэша? Да и какое-то решение из области заката солнца вручную. Неудобство использования инструментов защиты информации играет против их корректного применения. Описанная схема слишком сложна, чтобы средний пользователь мог её безопасно использовать.
Вполне поддержаны. Насчет поддержки УЭК рутокен — точно нет, а для SafeTouch не вижу проблемы. Какой носитель у вас, я не знаю.
> А что собственно даст пользователю значения хэша?
Ну, если хотите, получайте это значение, считайте хэш от тех данных, что подписываете и сравнивайте: примерно так вся эта визуализация и работает.
> средний пользователь мог её безопасно использовать
С чего вы взяли, что к полученной системе будет применимо слово «безопасно»?
Очень удобно, не правда ли? )
> С чего вы взяли, что к полученной системе будет применимо слово «безопасно»?
Я буду стремиться к тому, что к ней будет применимо слово «безопасней» по сравнению подписью чего-то вслепую. Кроме того, заставлять кого-либо пользоваться этим я не собираюсь.
Только не пытайтесь меня убедить, что сертификаторы ФСБ неимоверно крутые спецы, которые глазами анализируют исходники и ищут в них уязвимости и их сертификция — это клеймо безупречного качества. Я знаю как это делается. По крайней мере делалось некоторое время назад. Это очень формальный и практически бесполезный процесс, который стоит весьма хороших денег.
Ну и наконец, что конкретно вы предлагаете в условиях, когда производителю в основном пофиг на Linux. Тупо сидеть и ничего не делать? Прекрасный план!
Так это еще не самое смешное. Самое, как мне кажется, состоит в том, что владелец ЭЦП в том виде, в каком ее нынче выдает большинство (если не все) УЦ, совершенно не причастен к генерации секретного ключа, поскольку получает от УЦ уже готовый криптоноситель.
То есть, по сути, это не «подпись», а некий аналог печати. И нет никакого способа проверить, сколько было изготовлено экземпляров этой печати, и где они находятся — все упирается в абсолютное доверие к УЦ и его сотрудникам.
Не упирается ничего в доверие. Все упирается в тупость этих людей, которые так делают. Позвоните в ллюбой УЦ, только не тупыми продажникам, а сразу в саппорт, и спросите как сделать сертификат через запрос. Процентов 75 УЦ уже так умеют делать. Просто встаньте на их место. Вот приходит к вам председатель ТСЖ 65 лет отряду (ТСЖ обязаны иметь ЭП) и говорит: сынок, мне бы подпись эту диавольскую заиметь. А ты такой: придерживайтесь отец, смотрите вот Алиса, вот Боб, она пишет ему письмо, а на почте их читает Ева… )))
Из других аккредитованных «не вчера» хотел сперва ткнуться в Департамент информационного развития и отделение Пенсионного фонда, но они выпускают ЭЦП исключительно для госконтор и организаций самоуправления, вроде тех ТСЖ.
Вообще, грустно наблюдать, как под эгидой «информатизации» и «безопасности» тупо пилят бабло, пользуясь дремучестью большинства юзеров.
А не могу коментировать ваш пересказ чьих-то слов, не зная полного диалога. Если вы в Новосибирске, то прибегните к услугам Такском. Они совершенно точно умеют через запрос.
Сейчас уже нет смысла обращаться куда-то еще — сертификат изготовлен, использовать я его буду для отправки отчетности по ИП в ФНС, так что явной опасности компрометации ключей нет.
Кстати, Вы не в курсе, что за странная ситуация с драйверами eToken? Gemalto их свободно не раздает, а УЦ, выдающие сертификаты для подписи кода (DigiCert, GlobalSign и т.п.) почему-то раздают собственные лицензированные версии SafeNet Authentication Client'ов. Чем объясняется такая политика? Или эта область настолько хлебная, что даже драйверы в свободный доступ выложить жалко?
Касательно гемальты — никогда не пользовался их продуктами и не собираюсь. Там судя по всему полные штаны security by obscurity, от того и поведение такое. Как они сделали электронные паспорта с уязвимостями для, кажется, эстонцев и испанцев, хватает, чтобы всю мощь этой конторы осознать.
Я бы тоже не пользовался, но DigiCert и GlobalSign дают EV-сертификаты для подписи кода только на eToken. Российскую ЭЦП тоже решил записать на eToken, наивно полагая, что драйверы с Authentication Client от GlobalSign уже стоят, останется лишь поставить КриптоПро или VipNet. Однако ж, Authentication Client вообще не видит на этом токене ничего, полагая его чистым, только по паролю авторизуется. Контейнер становится виден только в КриптоПро CSP.
Вообще, создается впечатление, что вся эта пирамида слеплена на коленке, как попало, требует установки многоуровневого софта заведомо чрезмерных объемов, и работает нормально, только если повезет. От чтения инструкций по установке и увязке всей этой машинерии становится плохо уже в середине.
Оно все такое, или есть вменяемые решения? Как-то интуитивно казалось, что любой аппаратный ключ должен иметь некую универсальную ФС, универсальный же менеджер для нее, а уже поверх этого должны работать надстройки.
Если бы всё это было поддержано популярными библиотеками, то нужды бы в этом не было. Но мы попали в изоляцию. Причем ещё задолго до известных политических событий. Хотя я не сторонник нашего режима, но блин — получатся, что мы окружены )
Далее, касательно содержания токена. Если мы говорим о тупом токене, который хранит в извлекаемом виде ключи, то действительно там есть более-менее стандартная «файловая» система. Но вот содержание файлов не стандартизировано. Каждое СКЗИ может туда писать в своём формате. Очевидно, что тогда другое СКЗИ не будет видеть эту инфу.
А вот если токен претендует на умность — например, аппаратная ЭП или блочное шифрование, то тут уже мыши впляс — каждый вендор во что горазд. Тот же еТокен (если это не узконишевая версия), если я правильно помню умеет все эти RSA/DSA аппаратно делать неизвлекаемым ключем. А ключи ГОСТ он умеет хранить только в тупом виде.
Как так сложилось, что у всех разное — это вопрос не ко мне, это вам сюда. По-моему, я даже видел где-то утилиты для конвертации форматов контейнеров. Но зачем это всё существует не знаю. Возможно, так реализуется право на труд )
И политика распространения софта тоже изумляет: можно купить токен в магазине, но софт к нему придется добывать извилистыми путями — или через поставщика сертификата, или через переговоры с производителем, или из левых источников.
На сколько мне известно, ключевые носители делают Рутокен, Аладин (теперь Гемальто) и ещё джакарта. Вот про последнюю я вообще ничего не знаю. Остальные два кейса нами с вами покрыты )
Любил я им вымораживать поддержку разных УЦ ) К сожалению, неудачно повернулся в кресле и снёс этот брелок, когда он был вставлен в системник. Покупать новый нету смысла, т.к. с нового года старые ГОСТы превращаются в тыкву, а новых он не умел.
Зато теперь покупаю только «микро» варианты токенов — которые не торчат на 5 сантиметров, будучи вставленными в порт ) И вам советую )
Я, честно говоря, вообще не пользовался бы токенами — абсолютной защиты они не дают (есть трояны, умеющие прикидываться пользователем), но пришлось — тот же GlobalSign принципиально не желает выпускать сертификат в файле. Подозреваю, что есть возможность его как-то обмануть, подменив модули CSP или ссылки на них, но это уже хлопотно, проще смириться.
«Приватный ключ, доступ к которому имеют более одного человека, называется публичным ключом» (с) )))
Возможно не прошел Bind, а возможно, сопоставление Id. Попробуйте повыводить значение разных переменных в консоль с помощью ConsoleWrite($Var&@CRLF)
Но спотыкнулось об ETDirEnumNext — ошибку здесь выдаёт. Не знаю правда какую.
И на ETFilesEnumNext тоже.
Я прогнал в цикле по всем возможным RootDir — такое ощущение что они все пустые.
Хотя безусловно, можно избежать концепции файлов полностью, используя полность проприетарный APDU-субпротокол.
В коде часто встречалась строка «AKS ifdh» — так обозначаются смарт-карты, которые не брелки?
С другой стороны, возможность выковырять ключ открывает волшебные возможности к написанию софтового эмулятора, позволяющего засунуть всё в виртуалку и не париться.
Смарт-карты (так же как и 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 стояли у Вас?
«Почему всем можно, а мне нельзя?» или реверсим API и получаем данные с eToken