Что такое ключевая пара
Токены PKCS#11: генерация ключевой пары и неизвлекаемость приватного ключа (Продолжение)
Итак, что такое ключевая пара?
Ключевая пара включает в себя два ключа:
Открытый ключ подписи вычисляется, как значение некоторой функции от закрытого ключа, но знание открытого ключа не дает возможности определить закрытый ключ.
И именно оно определяет длину закрытого/открытого ключей и корректность закрытого ключа:
— длина закрытого ключа 256 бит;
— длина закрытого ключа 512 бит.
И так, открытый ключ получается из закрытого ключа.
А откуда берется закрытый ключ?
Для получения закрытого ключа сначала необходимо решить какой длины будет закрытый ключ (256 или 512 бит), затем определиться с криптопараметрами ключевой пары. Теперь берем датчик случайных чисел и получаем случайное число соответствующей длины. Собственно это случайное число и должно стать значением d закрытого ключа (ключом подписи d). Это значение должно удовлетворять следующему правилу:
0 Нас интересуют атрибуты извлекаемости закрытого ключа.
Это прежде атрибут CKA_SENSITIVE, отвечающий за возможность получения значения закрытого ключа. Если значение атрибута CKA_SENSITIVE установлено в CK_TRUE, то закрытый ключ не может быть извлечен из токена в открытом виде. Второй атрибут CKA_EXTRACTABLE позволяет получать закрытый ключ в зашифрованном виде. Для этого его необходимо установить CK_TRUE.
Установка атрибута CKA_SENSITIVE в CK_TRUE, а атрибута CKA_EXTRACTABLE в CK_FALSE при генерации ключевой пары делает закрытый ключ абсолютно неизвлекаемым. Возможность определять является ли ключ экспортабельным имеется в браузере Redfox:
Кто-то скажет, — а что если изменить значения этих атрибутов. Как правило этого сделать нельзя, защиту понизить нельзя, также как «нельзя понижать градус». Точно также можно сделать неизвлекаемым закрытый ключ после его импорта на токен (если конечно токен/смарткарта разрешают импорт). После создания (или во время создания) объекта CKO_PRIVATE_KEY необходимо установить CKA_SENSITIVE=CK_TRUE, а атрибута CKA_EXTRACTABLE=CK_FALSE.
В последнем случае (при импорте) следует иметь в виду, что хотя закрытый ключ и стал неизвлекаемым, он появился со стороны (например, из PKCS#12), и гарантии, что нет еще где-то его дубликата нету.
Убедиться, что на токен/смарткарте находятся полноценные объекты PKCS#11 (CKO_PRIVATE_KEY, CKO_PUBLIC_KEY, CKO_CERTIFICATE), которые участвуют в криптографических операциях на самом токене удобно с помощью доступной для свободного скачивания утилиты p11conf:
Для того, чтобы посмотреть какие объекты находятся на токене достаточно выполнить команду вида:
Если такие объекты отсутствуют на токене, а говорят, что используется токен PKCS#11 с неизвлекаемым ключом, то это скорей всего не так. Скорей всего токен используется просто как флэшка с PIN-кодом, а сертификат и ключи хранятся как объекты CKO_DATA.
И наконец, для того, чтобы посмотреть не только какие типы объектов хранятся на токене, а объекты со всеми атрибутами необходимо использовать дополнительно флаг –d:
Все сказанное здесь справедливо для токена/смарткарты с интерфейсом PKCS#11, включая облачный токен.
В заключение напомним, что токены/смаркарты с интерфейсом PKCS#11 широко используются в проектах Mozilla (браузеры, почтовые клиенты), в браузерах Chrome от Google и других проектах. Если говорить о России, то токены/смаркарты с интерфейсом PKCS#11успешно используются для доступа на портал Госуслуг.
Инфраструктура открытых ключей: утилита генерации запросов на квалифицированный сертификат
По аналогичной схеме происходит и получение сертификата ключа проверки электронной подписи (СКПЭП). Сначала гражданин, желающий получить сертификат, должен приобрести «навык» в проставлении собственноручной подписи. Этот «навык» реализуется через получение заявителем ключевой пары, которая содержит открытый ключ или ключ проверки электронной подписи (КПЭП) и закрытый ключ или ключ электронной подписи, который, собственно, и позволяет генерировать электронную подпись и подписывать электронный документ. Идентификация электронной подписи под документом осуществляется по следующему алгоритму. Из сертификата определяется каким ключом (ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2012 с длиной ключа 64 или 128 байт) был подписан документ. По типу ключа определяется алгоритм хэширования, который использовался при подписании документа. Это может быть ГОСТ Р 34.11-94 или ГОСТ Р 34.11-2012 с длиной хэш 256 или 512 бит. По выбранному алгоритму считается хэш от исходного документа. А по значению посчитанного хэш от исходного документа, публичного ключа (КПЭП) и его параметрам (все это берется из сертификата СКПЭП) и проверяется достоверность электронной подписи под документом.
Для создания ключевой пары используются различные средства криптографической защиты информации (СКЗИ), поддерживающие криптографические алгоритмы ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012. При этом следует помнить, что использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается! СКЗИ, которые реализуют различные криптографические алгоритмы и протоколы могут быть как программными, так и аппаратными. Доступ к СКЗИ осуществляется через криптографические интерфейсы. Абсолютное большинство сертифицированных СКЗИ с российской криптографией поддерживает либо универсальный криптографический интерфейс PKCS#11, который поддерживается на всех платформах, либо интерфейс CSP и CryptoAPI от Микрософт на платформах MS Windows (далее MS CSP). Именно эти два криптографических интерфейса и поддерживаются, например, порталом Госуслуг. Именно эти два типа СКЗИ и будут рассматриваться далее:
Следует иметь ввиду, что если есть желание или необходимость работы с электронной подписью не только на платформе Windows, но и на других платформах (Linux, macOS и т.п.), то следует выбирать токены PKCS#11 с поддержкой российской криптографии.
Помимо основной функции, связанной с генерацией запроса, в утилите предусмотрены функции для работы с токенами и сертификатами:
Комбинированное поле (combobox) «Выберите токен:» на основном окне содержит список доступных СКЗИ для генерации ключевой пары. Если утилита генерации запроса запущена на платформе Windows и на ней установлены криптопровайдеры CSP с поддержкой российской криптографии, то в перечне доступных СКЗИ («Выберите токен:») будет определен и виртуальный токен «MS_CSP». Так что, если есть желание использовать криптопровайдер MS CSP, то он должен быть установлен в системе до запуска утилиты.
Для добавления поддержки нового токена PKCS#11 достаточно выбрать пункт меню «Управление Токенами->Добавить Токен». Добавление поддержки для нового токена состоит в выборе библиотеки PKCS#11 для подключаемого типа токенов/смарткарт и задании удобного имени (никнайма). При добавлении поддержки нового типа токенов (а также при запуске утилиты, если ранее была добавлена поддержка токенов) при подключенном (вставленном) токене будет затребован PIN-код для доступа к нему:
Но это произойдет только в том случае, если токен не только подключен, но и находится в рабочем состоянии, т.е. проинициализирован. Проверить токен и, при необходимости, проинициализировать его, сменить PIN-код для доступа к нему и т.д. удобно утилитой p11conf :
Выбрав пункт «Управление Токенами->Механизмы Токена», можно посмотреть криптографические механизмы того или иного токена, например, есть ли поддержка алгоритма ГОСТ Р 34.10-2012. Для виртуального токена MS_CSP перечисляются все провайдеры CSP с поддержкой ГОСТ-алгоритмов и поддерживаемые ими механизмы:
Если выбранный токен не поддерживает выбранный тип ключевой пары, то будет выдано соответствующее сообщение:
Прежде чем перейти непосредственно к заполнению полей запроса необходимо определиться для каких целей нужен сертификат, т.е. указать «Роль сертификата». Сегодня таких ролей накопилось не один десяток:
И каждая роль связана с множеством различных OID-ов, включаемых в сертификат. Так, например, для доступа на портал Госуслуг необходимы следущие oid-ы:
OID-ы для других ролей (например, «Площадка Газпромбанк», «Потребитель спирта» и т.д.) можно найти в исходном коде утилиты (переменная oid_roles_bad, оператор:
).
Наличие такого количества oid-ов трудно понять. Речь идет о квалифицированных сертификатах, в которых присутствуют oid-ы ИНН, ОГРН, СНИЛС и т.п., которые однозначно идентифицируют и физическое лицо и юридическое лицо и, кажется, этого было бы достаточно для доступа на портал Госуслуг, да и на другие тоже. Но, Dura lex, sed lex — Закон суров, но это закон.
Итак, определившись с СКЗИ и ключевой парой, можно приступать к заполнению электронного заявления/запроса на сертификат ключа проверки электронной подписи (СКПЭП):
Первым заполняется поле «Common Name», в которое заносится полное имя будущего владельца сертификата. Для физического лица это ФИО как в паспорте. Для юридического лица это наименование компании из ЕГРЮЛ. Эта информация для юридического лица автоматически будет продублирована в поле «Наименование организации» («O»):
При заполнении формы проверяется правильность заполнения полей ИНН, ОГРН, СНИЛС (при вводе не цифры поле становится красным, правильно заполненные поля становятся зеленоватыми), адреса электронной почты:
После заполнения всех полей запроса и нажатия кнопки «Finish» в итоге будет получен запрос на сертификат:
В процессе создания запроса будет сгенерирована ключевая пара на выбранном токене. При этом, если в качестве токена выбран виртуальный токен «MS_CSP», который, в свою очередь, поддерживает различные носители для хранения ключевой пары, будет предложено выбрать еще и конкретный носитель:
Напомним, что ключевая пара содержит два ключа: закрытый и открытый. Открытый ключ, который еще называют ключом проверки электронной подписи, отправляется в запрос на сертификат. Для просмотра сгенерированного запроса, который содержит и открытый ключ, используется меню «Сертификаты->Просмотр запроса»:
Закрытый ключ остается у заявителя на его токене, PIN-код (пароль) от которого необходимо хранить как зеницу ока Своего. А поскольку существует однозначное соответствие между открытым и закрытым ключами, то можно всегда проверить кому принадлежит запрос на сертификат, а в дальнейшем и сам сертификат, подпись под документом и т.д.
Теперь со всеми необходимыми документами, со сгенерированным запросом на флэшке можно идти в ближайший удостоверяющий центр и получать сертификат. Итак запрос поступает для выпуска сертификата в один из УЦ, созданных с учетом Федерального закона от 6 апреля 2011г. №63-ФЗ «Об электронной подписи»:
Запрос в УЦ пройдет стадии импорта, рассмотрения, утверждения и выпуска сертификата по данному запросу:
Выпущенный сертификат будет опубликован на одном из сервисов УЦ, откуда его можно будет скачать. А сейчас достаточно, чтобы выпущенный сертификат был экспортирован на флэшку заявителя:
И вот теперь, когда получен сертификат, осталось положить его на СКЗИ (PKCS#11, MS CSP) (Сертификаты->Импорт x509):
Убедиться, что сертификат находится на токене, можно просмотрев содержимое токена/смарткарты (Сертификаты->Просмотр x509 на токене):
Ну и чтобы это была «броня» (Дайте мне такую БУМАЖКУ! Окончательная Бумажка, Броня. (Собачье Сердце к/ф)), подключим токен к браузеру Firefox с поддержкой российской криптографии и найдем выпущенный сертификат в личных сертификатах (в числе таких сертификатах, для которых на токене имеется закрытый ключ):
Утилита CreateCSRCAFL63 разработана на Tcl/Tk. Для доступа к криптографическим функциям MS CSP и токенов PKCS#11 разработан пакет cwapi, реализующий требования к библиотекам C со стороны Tcl. Реализовать эти требования не сложно, но порой отнимает много времени в силу своей рутинности. И тут на помощь приходит общедоступная утилита SWIG., которая позволяет создавать интерфейсные модули между библиотеками C/C++ и другими языками. Это не только Tcl, но и Java и другие. Проект очень хорошо документирован и имеет прекрасные примеры. Воспользоваться им не представляет труда. В нашем случае для получения интерфейсного модуля был написан простой исходный файл cwapi.i для утилиты swig:
В файле cwapi.h находятся описания функций из основного проекта cwapi:
в файле cwapi_wrap.c получим готовый интерфейсный модуль. Добавляем его в проект cwapi, пересобираем его и получаем новый пакет, который и используется в данной утилите.
Для получения дистрибутива очень удобно использовать утилиту freewrap, при этом библиотека cwapi также включается непосредственно в дистрибутив. Исходный код утилиты и дистрибутивы доступны для платформ Windows и Linux.
Хотелось бы упомянуть еще об одной утилите, а именно о tcl2c. Эта утилита «заварачивает» tcl/tk-код в C-код.
Для получения исполняемого кода достаточно выполнить команду:
В состав дистрибутивов для платформы Linux включен и дистрибутив на языке С со статическим подключением пакета cwapi.
Токены PKCS#11: генерация ключевой пары и неизвлекаемость приватного ключа (Продолжение)
Итак, что такое ключевая пара?
Ключевая пара включает в себя два ключа:
Открытый ключ подписи вычисляется, как значение некоторой функции от закрытого ключа, но знание открытого ключа не дает возможности определить закрытый ключ.
И именно оно определяет длину закрытого/открытого ключей и корректность закрытого ключа:
— длина закрытого ключа 256 бит;
— длина закрытого ключа 512 бит.
И так, открытый ключ получается из закрытого ключа.
А откуда берется закрытый ключ?
Для получения закрытого ключа сначала необходимо решить какой длины будет закрытый ключ (256 или 512 бит), затем определиться с криптопараметрами ключевой пары. Теперь берем датчик случайных чисел и получаем случайное число соответствующей длины. Собственно это случайное число и должно стать значением d закрытого ключа (ключом подписи d). Это значение должно удовлетворять следующему правилу:
0 Нас интересуют атрибуты извлекаемости закрытого ключа.
Это прежде атрибут CKA_SENSITIVE, отвечающий за возможность получения значения закрытого ключа. Если значение атрибута CKA_SENSITIVE установлено в CK_TRUE, то закрытый ключ не может быть извлечен из токена в открытом виде. Второй атрибут CKA_EXTRACTABLE позволяет получать закрытый ключ в зашифрованном виде. Для этого его необходимо установить CK_TRUE.
Установка атрибута CKA_SENSITIVE в CK_TRUE, а атрибута CKA_EXTRACTABLE в CK_FALSE при генерации ключевой пары делает закрытый ключ абсолютно неизвлекаемым. Возможность определять является ли ключ экспортабельным имеется в браузере Redfox:
Кто-то скажет, — а что если изменить значения этих атрибутов. Как правило этого сделать нельзя, защиту понизить нельзя, также как «нельзя понижать градус». Точно также можно сделать неизвлекаемым закрытый ключ после его импорта на токен (если конечно токен/смарткарта разрешают импорт). После создания (или во время создания) объекта CKO_PRIVATE_KEY необходимо установить CKA_SENSITIVE=CK_TRUE, а атрибута CKA_EXTRACTABLE=CK_FALSE.
В последнем случае (при импорте) следует иметь в виду, что хотя закрытый ключ и стал неизвлекаемым, он появился со стороны (например, из PKCS#12), и гарантии, что нет еще где-то его дубликата нету.
Убедиться, что на токен/смарткарте находятся полноценные объекты PKCS#11 (CKO_PRIVATE_KEY, CKO_PUBLIC_KEY, CKO_CERTIFICATE), которые участвуют в криптографических операциях на самом токене удобно с помощью доступной для свободного скачивания утилиты p11conf:
Для того, чтобы посмотреть какие объекты находятся на токене достаточно выполнить команду вида:
Если такие объекты отсутствуют на токене, а говорят, что используется токен PKCS#11 с неизвлекаемым ключом, то это скорей всего не так. Скорей всего токен используется просто как флэшка с PIN-кодом, а сертификат и ключи хранятся как объекты CKO_DATA.
И наконец, для того, чтобы посмотреть не только какие типы объектов хранятся на токене, а объекты со всеми атрибутами необходимо использовать дополнительно флаг –d:
Все сказанное здесь справедливо для токена/смарткарты с интерфейсом PKCS#11, включая облачный токен.
В заключение напомним, что токены/смаркарты с интерфейсом PKCS#11 широко используются в проектах Mozilla (браузеры, почтовые клиенты), в браузерах Chrome от Google и других проектах. Если говорить о России, то токены/смаркарты с интерфейсом PKCS#11успешно используются для доступа на портал Госуслуг.
Про PKI «на пальцах» за 10 минут
Предложил коллегам провести внутреннюю мини-лекцию по сабжу — идея зашла. Сел писать план лекции и… чот психанул — в итоге очнулся, дописывая небольшой гайд. Подумал, что будет полезно добавить сюда что-то для быстрого понимания, что такое PKI, зачем она нужна и как работает, так как пока готовился, чтобы освежить память, искал информацию в том числе на полюбившемся «Хабрахабре», но статей в таком формате не нашел.
Пишу на примере наших повседневных задач, которые знакомы многим: беспарольный доступ к серверам OpenVPN и защита доступа к ресурсам с помощью HTTPS.
Без теории не обойтись
PKI (Public Key Infrastructure, инфраструктура открытых ключей) — это про безопасность. Подразумевается, что у каждой сущности в инфраструктуре есть свой ключ, которым она однозначно идентифицируется. То есть, если ключ украден, пострадавшей сущностью может представиться укравший. PKI нужна для того, чтобы оперативно минимизировать последствия такой кражи. Ключ представлен двумя частями: публичной и приватной.
Аналог — это RSA ключи для SSH, но инфраструктурой их назвать сложно, так как отсутствует централизованный механизм управления ими. Также разница в том, что публичная часть ключа в паре ключей для SSH неизменна, а сертификат (публичную часть ключа участника PKI) можно перевыпустить в любой момент.
В PKI существует один (на самом деле, должно быть минимум два) или несколько Certification Authority — центров сертификации (удостоверяющих центров), отдающих публичные части своих ключей клиентам, которым выдают подписанные ими сертификаты. Таким образом, участники инфраструктуры «понимают», кто ими управляет, и действителен ли сертификат, выданный им или их «товарищам», в настоящий момент времени (одним из важнейших атрибутов сертификатов является срок их действия). Либо же сервер, у которого есть публичная часть ключа CA инфраструктуры, в которой он и его клиенты работают, понимает, что к нему пришел клиент с действительным сертификатом, и разрешает ему что-то, или запрещает в противном случае.
OpenVPN: как это бывает
На самом деле во многих компаниях на этот случай уже есть «PKI» и у него есть имя, потому что это кто-то из сотрудников. Назовем такого человека, к примеру, Полуэкт (с) и расскажем, как обычно это работает, а потом я расскажу, как это должно быть в идеале.
При появлении в компании нового сотрудника Полуэкт создает и присылает ему архив, в котором, помимо конфигурации собственно OpenVPN клиента, находятся файлы (на примере сотрудника Иванова А.А.):
В компании Acme все эти файлы генерирует Полуэкт…
А теперь как должно быть
На моем примере, упрощенно:
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
(пароль в конце лучше не указывать, а то придется его вводить каждый раз при подключении, а VPN у нас по сертификатам как раз, чтобы этого не было; тем более у нас в Pixonic есть OTP от Google);
Нужна ли вам эта фишка — вопрос для обсуждения. Соответственно, то, как ее внедрить, пока что выходит за рамки этой статьи.
И про срок действия клиентского сертификата: если предположить, что я устроился в Pixonic по временному контракту на 3 месяца, и мы его не продлили, то в описанной ситуации мой доступ к VPN автоматически отключится через 90 дней с момента выпуска сертификата. Чего не случится с SSH-доступом, если коллеги забудут отключить аккаунт во FreeIPA или удалить строчку из authorized_keys руками. C — сесуриту.
Теперь по Борщеву HTTPS
Предположим, вы хотите «включить SSL» для вашего сайта, чтобы у посетителей появился красивый замочек в браузере. Тут, собственно, все то же самое, но с некоторыми нюансами:
Чем отличаются открытый и закрытый ключи ЭЦП?
При создании электронной цифровой подписи с помощью криптографических алгоритмов формируется ключевая пара — открытый и закрытый ключи. Расскажем подробно о том, что такое ключевая пара, чем отличаются части ЭЦП, какие функции они выполняют.
Открытый ключ ЭЦП
Эта часть ключевой пары представляет собой уникальный набор символов, который формируется криптопровайдером (средством криптографической защиты информации). Открытый ключ находится в сертификате проверки электронной подписи (в электронной и бумажной версии). Он доступен всем, так как используется для расшифровки ЭЦП. То есть с его помощью получатель подписанного электронного документа может идентифицировать и проверить ЭЦП. Удостоверяющие центры хранят выданные открытые ключи в специальном реестре.
Закрытый ключ ЭЦП
Это секретный уникальный набор символов, который также формируется криптопровайдером. Закрытый ключ необходим для формирования ЭЦП на электронном документе и хранится в зашифрованном виде на носителе (токене). Доступ к закрытому ключу имеет только владелец ЭЦП, он защищен PIN-кодом. Теоретически, скопировать закрытый ключ на другой носитель можно, но делать это рекомендуется, так как безопасность использования ЭЦП гарантирована только тогда, когда закрытый ключ существует в единственном экземпляре. Если носитель с закрытым ключом утерян, то в целях безопасности необходимо отозвать ЭЦП, чтобы злоумышленники не могли ей воспользоваться.
В ключевой паре открытая и закрытая части привязаны друг к другу.
Как найти и выгрузить ключи на компьютер?
Чаще всего появляется необходимость выгрузить открытый ключ, например, чтобы предоставить его контрагентам для проверки ЭЦП. На токене сертификат проверки ключа скрыт. Как его открыть? Сделать это можно через свойства браузера или программу КриптоПро CSP. Чтобы экспортировать ключ, в первую очередь необходимо подключить токен к компьютеру.
Через свойства браузера:
В ОС Windows необходимо открыть: «Пуск» — «Панель управления» — «Свойства браузера».
В появившемся окне выбрать вкладку «Содержание», а далее — «Сертификаты».
Появится список сертификатов, в котором следует выбрать нужный, а затем нажать кнопку «Экспорт».
Появится окно «Мастер экспорта сертификатов», где нужно выбрать «Не экспортировать закрытый ключ», если это не требуется.
Выбрать формат файла «Файлы в DER-кодировке X.509 (.CER)».
Выбрать место хранения ключа и сохранить.
Через КриптоПро CSP:
В ОС Windows надо перейти в «Пуск» — «Панель управления» — «КриптоПро CSP».
В открывшемся окне следует выбрать вкладку «Сервис» и нажать «Просмотреть сертификаты в контейнере».
Через кнопку «Обзор» нужно выбрать контейнер.
В окне «Сертификат для просмотра» следует нажать кнопку «Свойства» и на вкладке «Состав» нажать «Копировать в файл».
Далее порядок действий в окне «Мастер экспорта сертификатов» аналогичный: выбрать, нужно ли сохранять закрытый ключ, установить формат и определить место хранения.
Выгрузка закрытого ключа через свойства браузера выполняется по тому же алгоритму, что и в случае с открытым. Только в окне «Мастер экспорта сертификатов» нужно выбрать «Экспортировать закрытый ключ». А порядок действий при выгрузке из КриптоПро CSP следующий:
В ОС Windows нажать «Пуск» перейти на «Панель управления» и выбрать «КриптоПро CSP».
Далее — вкладка «Сервис» и кнопка «Скопировать контейнер».
Через кнопку «Обзор» нужно выбрать контейнер и подтвердить (потребуется ввести PIN-код).
Затем нужно ввести название копии закрытого ключа и нажать «Готово».
Далее нужно выбрать, куда будет записан ключ, установить пароль для обеспечения дополнительной защиты и подтвердить действия.
Ещё раз напомним, что экспортировать закрытый ключ без необходимости, не рекомендуется. Его может использовать любой, кто имеет доступ к компьютеру, на который он скопирован.
Заказав электронную цифровую подпись в СберКорус, вы сможете самостоятельно настроить компьютер для работы с ЭЦП, посмотрев видеоинструкцию. При возникновении сложностей мы поможем настроить компьютер бесплатно. А также в любое время проконсультируем по интересующим вопросам.