JaCarta PKI равно как и eToken Pro никакой встроенной криптографией не обладают, а являются простыми пассивными ключевыми носителями (обычные ISO7816-совместимые). Если хочется использовать их через PKCS#11, есть пакет cprocsp-rdr-pkcs11, который реализует указанный интерфейс.
Добрый день.
Хотелось бы некоторые вещи уточнить.
1) Для работы с таким токеном не нужен ни пакет pkcs11, ни emv. Пакет emv предназначен для банковских карт Gemalto (в основном это семейство Optelio), а не токенов.
2) Для работы с JaCarta достаточно поставить пакет cprocsp-rdr-jacarta из состава провайдера.
3) Действительно, существуют некоторые токены компании Аладдин, которые бинарно повторяют токены компании SafeNet и отличить их невозможно. Иногда они работают через софт SafeNet, иногда нет.
4) Официальной поддержки токенов SafeNet на Linux в КриптоПро CSP нет и пока не планируется.
Очень здорово, спасибо!
А можете, все же, когда-нибудь подробнее рассказать про наследование и флаги DACL-ов? Очень тяжело в этом разбираться, учитывая почти полное отсутствие внятной документации и примеров.
То есть, я правильно понимаю, что вопрос в том, что есть некоторая тестовая удаленная система с документированным интерфейсом, которая принимает только запросы, подписанные ключом с квалифицированным сертификатом?
Тогда не очень понятно следующее:
1) Автор предлагает выгрузить закрытый ключ, подпись которым обладает юридической значимостью, на десятки (сотни) машин? Если только на одну «эталонную» для тестирования, то опять же разницы между покупкой КриптоПро CSP и этой хакерской тулзы нет никакой. А если на огромное количество, как будет контролироваться то, что ключ никто не использует для «неподходящих» действий. Если бы для тестовой системы, которую разрабатывает моя компания, потребовалось положить на десятки машин мой ключ с квалифицированным сертификатом для Госуслуг, я бы, мягко говоря, остерёгся.
2) Почему нельзя приобрести ключ со встроенной в сертификат лицензией на CSP? Тогда не нужны кучи лицензий на машины.
3) Почему нельзя вести разработку с тестовым окружением (сделанный на коленке стенд, эмулирующий сервер), а затем уже доводить напильником на машине с легальным CSP?
Я не эксперт, но ведь в статье на которую вы ссылаетесь явно сказано «Поэтому все нижеописанное относится девелоперскому или тестовому окружению, где мы сами себе хозяева.». А что мешает взять для тестового окружения ключ сгенерированный самостоятельно на коленке с самоподписанным сертификатом?
Не только в распродажах. Месяц назад заказывал три доставки в два разных Ozon-box'а в Москве. У одного была просрочка два дня, у одного — три, и только один пришел в срок. Раньше никогда таких проблем не замечал. Просто что-то капитально поломалось в последние полгода.
поставили своей целью разработать легковесный алгоритм блочного шифрования, который не уступал бы по стойкости упомянутым алгоритмам АНБ, но позволял бы несколько сократить количество раундов, что делает его еще более быстрым
1) Если вы модифицируете шифр и говорите, что получилась стойкость не ниже, чем у исходного, то нужно хорошее математическое доказательство. Речь не о том, чтобы давать шифр десяткам «зубров», чтобы они его потрогали. Пусть пробуют исходный алгоритм. А вы тогда сразу сможете на это опираться.
Вообще, конечно, уже писали, но повторю. Каждый день люди придумывают десятки, а может, и сотни разных алгоритмов. Конечно же, никто не будет тратить свое время на поиск слабостей в каждом из них, если нет мотивации. Она может быть двух вариантов:
— вы объявляете хороший денежный приз;
— вы делаете алгоритм, который потенциально лучше существующих, широко распространенных, по каким-то критериям и выкладываете, например, на eprint.iacr.org.
Причем, второй еще ничего не гарантирует, но является, как минимум, обязательным условием.
2) Легковесность. Вы уверены, что она получилась? Сколько логических вентилей потребуется на реализацию? А сколько у конкурентов?
3) Скорость. Тоже не увидел. Как по сравнению, хотя бы, с ГОСТ 28147-89?
У нас по университету, когда я учился, байка ходила. Пришла девочка защищать диплом.
— Я разработала свой новый шифр.
— Он стойкий?
— Конечно!
— А с чего вы взяли?
— Ну я зашифровала сообщение. Посмотрела на него — ничего не понятно. Значит, стойкий.
Вот ваша задача теперь состоит в том, чтобы убедить общественность, на суд которой представляете алгоритм, что вы чем-то отличаетесь от этой девочки :)
Но речь-то не о просмотре сертификатов, а о подписи. Действительно, в Windows есть простые WinAPI-вызовы для отображения списка сертификатов. Более того, есть даже кнопочка в Панели управления CSP, которая позволяет посмотреть свойства контейнера. Но это всё еще не прикладная функциональность, а достаточно тестовая: «Проверить контейнер», «Просмотреть сертификат» и т.п. Тем более, реализация которой не требует никаких трудозатрат помимо одного WinAPI-вызова.
Про openssl я имел в виду, не «дополнить», а заменить. Сейчас статья выглядит как: «Есть три приложения, в которых можно подписать, используя наш токен. Есть неудобное с широкой функциональностью, удобное с урезанной функциональностью и удобное с широкой функциональностью, но платное». Причем, под первым приложением всюду по тексту подразумевается «КриптоПро CSP».
Хотелось бы еще раз уточнить: «КриптоПро CSP» — это не пользовательское приложение, а набор системных библиотек, реализующих криптографию, которые можно встроить в пользовательские приложения. И ни на Windows, ни на Linux в составе «КриптоПро CSP» не идёт полноценного графического пользовательского приложения для управления ключами/сертификатами/документами.
То, что много кто использует csptest для настоящих задач, а не тестовых, честно говоря, является открытием. Если это действительно так, то странно, что по этому поводу его использования практически отсутствуют обращения в техподдержку.
"«КриптоПро CSP» не умеет графического интерфейса под Linux.".
Во-первых, имеет. Нужно доставить пакет с нужным набором окон (gtk или motif). Но то, что вы называете графическим интерфейсом, — это набор кнопочек для решения задач, которыми занимается пользовательское ПО, встраивающее в себя криптографию. У CSP на Linux, действительно, кнопочек «вычислить подпись» или «зашифровать» нет. Но, собственно, на Windows тоже ничего подобного нет.
Во-вторых, криптопровайдер — это просто набор библиотек. Кажется странным требовать от него функциональности АРМа, которыми и являются Rosa Crypto tool и Trusted esign. Если вы хотите сравнивать графические интерфейсы библиотек, то сравнение с openssl будет более уместным.
Ну и наконец. csptestf — это не «консольный интерфейс CSP», а утилита, которая в большинстве случаев используется пользователями исключительно для тестовых целей, чтобы понять, на каком этапе работы возникает ошибка: при встраивании или при работе провайдера.
Основной интерфейс криптопровайдера (любого, не только КриптоПро) — программный MS CryptoAPI. Его подробное описание есть как в документации разработчика, так и на MSDN.
Вряд ли люди, которые работают в НИИ, сильно заморачиваются с тем, куда ключи спрятать. 99% хранятся в %userprofile% или корне C:/, а дальше уже дело за поиском расширения.
А еще есть такая вещь как доверие к удостоверяющему центру. Если он ВНЕЗАПНО начнет выпускать левые сертификаты, это, конечно же, очень быстро обнаружится. Один такой громкий случай и все — доверие утрачено. Можно смело сносить этот корневой руками из хранилища. Вообще говоря, почитайте статьи о том, что у вас прямо сейчас стоит в "доверенных" в браузерах и операционках. В конце концов, есть более простые способы узнать что-то о вашем трафике в чем угодно, чем поднимать волну о создании какого-то мастер-УЦ.
Интересно, о каком MitM вообще речь идет в комментариях?
Общую-то архитектуру предлагается оставить прежней, только заменить ключевую пару с западными алгоритмами на аналогичную с российскими. К тому же, когда дело касается государственных сайтов (например, gosuslugi.ru), то почему сейчас не боитесь, что администраторы поделились ключами с какими-то абстрактными органами?
Даже более простой вопрос: если, допустим, поделились, то что они красть собираются? Данные, которые вы и так передаете в данный момент государству? Попахивает предельно необоснованной паранойей.
В данном конкретном случае наличием системы разграничения доступа. Потеря дискеты влечет компрометацию ключа, а для получения ключа с токена нужно еще подобрать пароль, на что даётся ограниченное число попыток.
> совершенно вам не видно
Для этого есть средства визуализации подписи (см. Rutoken PinPad или SafeTouch). Не нужно городить огороды. Да, в конце концов, если уж так хочется, можно поставить отладчик APDU-инструкций, ловить хэш, отправляющийся на подпись в токен, и его печатать пользователю.
> Совершенно верно. Идея в том, чтобы это реверснуть. Это не так сложно, как может показаться на первый взгляд.
Ого, ну, что называется, будет очень здорово, если получится. Но когда застрянете где-то, вспомните мои слова :)
> Для меня, как для конечного пользователя, доверие к себе многократно выше, чем доверие к конторе, которая сертифицировала что-то кому-то.
Конечно, выше. И это типичная проблема подавляющего большинства тех, кто пытается самостоятельно лезть в разработку криптографии. Не забывайте, пожалуйста, про закон Шнайера.
> Западные токены, к сожалению, не дают мне возможности использовать криптографию для нужд юридически значимых внутри России.
Осуществить юридически значимые нужды с ГОСТ-криптографией, но несертифицированной, да еще и на коленке сделанной, тоже весьма затруднительно. Приведу пример: для понимания базовых принципов криптоалгоритмов и прокачки навыка разрабоки я иногда даю своим студентам задания в духе «реализуй ГОСТ хххх-хх» или «встрой туда-то реализацию OpenSSL».
Хотите сказать, что их поделки, имеющие в коде функции типа gost_encrypt_megasecure, тоже применимы в юридически значимом документообороте?
cryptopro.ru/products/fkc/info
cryptopro.ru/blog/2014/12/04/semnye-nositeli-i-bezopasnoe-khranenie-klyuchei
www.youtube.com/watch?v=Kj8krL2NICc
Хотелось бы некоторые вещи уточнить.
1) Для работы с таким токеном не нужен ни пакет pkcs11, ни emv. Пакет emv предназначен для банковских карт Gemalto (в основном это семейство Optelio), а не токенов.
2) Для работы с JaCarta достаточно поставить пакет cprocsp-rdr-jacarta из состава провайдера.
3) Действительно, существуют некоторые токены компании Аладдин, которые бинарно повторяют токены компании SafeNet и отличить их невозможно. Иногда они работают через софт SafeNet, иногда нет.
4) Официальной поддержки токенов SafeNet на Linux в КриптоПро CSP нет и пока не планируется.
А можете, все же, когда-нибудь подробнее рассказать про наследование и флаги DACL-ов? Очень тяжело в этом разбираться, учитывая почти полное отсутствие внятной документации и примеров.
Тогда не очень понятно следующее:
1) Автор предлагает выгрузить закрытый ключ, подпись которым обладает юридической значимостью, на десятки (сотни) машин? Если только на одну «эталонную» для тестирования, то опять же разницы между покупкой КриптоПро CSP и этой хакерской тулзы нет никакой. А если на огромное количество, как будет контролироваться то, что ключ никто не использует для «неподходящих» действий. Если бы для тестовой системы, которую разрабатывает моя компания, потребовалось положить на десятки машин мой ключ с квалифицированным сертификатом для Госуслуг, я бы, мягко говоря, остерёгся.
2) Почему нельзя приобрести ключ со встроенной в сертификат лицензией на CSP? Тогда не нужны кучи лицензий на машины.
3) Почему нельзя вести разработку с тестовым окружением (сделанный на коленке стенд, эмулирующий сервер), а затем уже доводить напильником на машине с легальным CSP?
Использовать ключ от чужого СКЗИ в отрыве от этого СКЗИ довольно странно: кто обеспечит контроль корректности его использования?
На вопрос «да что там использовать, берешь описание алгоритма да реализуешь» можете обратиться к простым материалам:
cryptopro.ru/blog/2014/08/25/nemnogo-ob-atakakh-po-pobochnym-kanalam
cryptopro.ru/blog/2017/05/17/o-nagruzke-na-klyuch-chast-1
cryptopro.ru/blog/2017/05/29/o-nagruzke-na-klyuch-chast-2
1) Если вы модифицируете шифр и говорите, что получилась стойкость не ниже, чем у исходного, то нужно хорошее математическое доказательство. Речь не о том, чтобы давать шифр десяткам «зубров», чтобы они его потрогали. Пусть пробуют исходный алгоритм. А вы тогда сразу сможете на это опираться.
Вообще, конечно, уже писали, но повторю. Каждый день люди придумывают десятки, а может, и сотни разных алгоритмов. Конечно же, никто не будет тратить свое время на поиск слабостей в каждом из них, если нет мотивации. Она может быть двух вариантов:
— вы объявляете хороший денежный приз;
— вы делаете алгоритм, который потенциально лучше существующих, широко распространенных, по каким-то критериям и выкладываете, например, на eprint.iacr.org.
Причем, второй еще ничего не гарантирует, но является, как минимум, обязательным условием.
2) Легковесность. Вы уверены, что она получилась? Сколько логических вентилей потребуется на реализацию? А сколько у конкурентов?
3) Скорость. Тоже не увидел. Как по сравнению, хотя бы, с ГОСТ 28147-89?
У нас по университету, когда я учился, байка ходила. Пришла девочка защищать диплом.
— Я разработала свой новый шифр.
— Он стойкий?
— Конечно!
— А с чего вы взяли?
— Ну я зашифровала сообщение. Посмотрела на него — ничего не понятно. Значит, стойкий.
Вот ваша задача теперь состоит в том, чтобы убедить общественность, на суд которой представляете алгоритм, что вы чем-то отличаетесь от этой девочки :)
Про openssl я имел в виду, не «дополнить», а заменить. Сейчас статья выглядит как: «Есть три приложения, в которых можно подписать, используя наш токен. Есть неудобное с широкой функциональностью, удобное с урезанной функциональностью и удобное с широкой функциональностью, но платное». Причем, под первым приложением всюду по тексту подразумевается «КриптоПро CSP».
Хотелось бы еще раз уточнить: «КриптоПро CSP» — это не пользовательское приложение, а набор системных библиотек, реализующих криптографию, которые можно встроить в пользовательские приложения. И ни на Windows, ни на Linux в составе «КриптоПро CSP» не идёт полноценного графического пользовательского приложения для управления ключами/сертификатами/документами.
То, что много кто использует csptest для настоящих задач, а не тестовых, честно говоря, является открытием. Если это действительно так, то странно, что по этому поводу его использования практически отсутствуют обращения в техподдержку.
Во-первых, имеет. Нужно доставить пакет с нужным набором окон (gtk или motif). Но то, что вы называете графическим интерфейсом, — это набор кнопочек для решения задач, которыми занимается пользовательское ПО, встраивающее в себя криптографию. У CSP на Linux, действительно, кнопочек «вычислить подпись» или «зашифровать» нет. Но, собственно, на Windows тоже ничего подобного нет.
Во-вторых, криптопровайдер — это просто набор библиотек. Кажется странным требовать от него функциональности АРМа, которыми и являются Rosa Crypto tool и Trusted esign. Если вы хотите сравнивать графические интерфейсы библиотек, то сравнение с openssl будет более уместным.
Ну и наконец. csptestf — это не «консольный интерфейс CSP», а утилита, которая в большинстве случаев используется пользователями исключительно для тестовых целей, чтобы понять, на каком этапе работы возникает ошибка: при встраивании или при работе провайдера.
Основной интерфейс криптопровайдера (любого, не только КриптоПро) — программный MS CryptoAPI. Его подробное описание есть как в документации разработчика, так и на MSDN.
Общую-то архитектуру предлагается оставить прежней, только заменить ключевую пару с западными алгоритмами на аналогичную с российскими. К тому же, когда дело касается государственных сайтов (например, gosuslugi.ru), то почему сейчас не боитесь, что администраторы поделились ключами с какими-то абстрактными органами?
Даже более простой вопрос: если, допустим, поделились, то что они красть собираются? Данные, которые вы и так передаете в данный момент государству? Попахивает предельно необоснованной паранойей.
А если речь о промышленных разработках, то хотелось бы услышать более адекватные доводы, чем «всем хорошо известно».
Вполне поддержаны. Насчет поддержки УЭК рутокен — точно нет, а для SafeTouch не вижу проблемы. Какой носитель у вас, я не знаю.
> А что собственно даст пользователю значения хэша?
Ну, если хотите, получайте это значение, считайте хэш от тех данных, что подписываете и сравнивайте: примерно так вся эта визуализация и работает.
> средний пользователь мог её безопасно использовать
С чего вы взяли, что к полученной системе будет применимо слово «безопасно»?
Для этого есть средства визуализации подписи (см. Rutoken PinPad или SafeTouch). Не нужно городить огороды. Да, в конце концов, если уж так хочется, можно поставить отладчик APDU-инструкций, ловить хэш, отправляющийся на подпись в токен, и его печатать пользователю.
Ого, ну, что называется, будет очень здорово, если получится. Но когда застрянете где-то, вспомните мои слова :)
> Для меня, как для конечного пользователя, доверие к себе многократно выше, чем доверие к конторе, которая сертифицировала что-то кому-то.
Конечно, выше. И это типичная проблема подавляющего большинства тех, кто пытается самостоятельно лезть в разработку криптографии. Не забывайте, пожалуйста, про закон Шнайера.
> Западные токены, к сожалению, не дают мне возможности использовать криптографию для нужд юридически значимых внутри России.
Осуществить юридически значимые нужды с ГОСТ-криптографией, но несертифицированной, да еще и на коленке сделанной, тоже весьма затруднительно. Приведу пример: для понимания базовых принципов криптоалгоритмов и прокачки навыка разрабоки я иногда даю своим студентам задания в духе «реализуй ГОСТ хххх-хх» или «встрой туда-то реализацию OpenSSL».
Хотите сказать, что их поделки, имеющие в коде функции типа gost_encrypt_megasecure, тоже применимы в юридически значимом документообороте?