gost assly и gost part что это значит
Настройка двусторонней RSA и GOST аутентификации в приложении на JBoss EAP 7
Безопасности в современной деловой информационной среде отводится одна из первостепенных ролей. Нужно ли говорить, что в Банке, где большая часть продуктов строится на Digital-технологиях, а на кону доверие, спокойствие и благосостояние клиентов, информационная безопасность ставится в авангард.
В этой статье расскажу, как мы в своей деятельности применяем один из инструментов обеспечения информационной безопасности.
Аутентификация – это процесс установления подлинности субъекта по его уникальному идентификатору и проверка права на доступ к информационной системе.
Двусторонняя аутентификация – это обоюдная проверка и установление подлинности, при которой информационная система также обязана подтвердить свою аутентичность перед пользователем.
Сервер Red Hat JBoss Enterprise Application Platform является одной из распространенных и популярных платформ для построения корпоративных приложений на Java.
Для настройки возьмем финальный релиз JBoss EAP 7.0.0 от 10.05.2016 из свободного источника: Red Hat JBoss Enterprise Application Platform
При наличии регистрации Red Hat можно скачать дополнительные патчи: Red Hat Customer Portal и установить через консоль своего экземпляра JBoss EAP (http://localhost:9990/console/App.html#patching)
Постановка задачи
Для корпоративного приложения с тонким клиентом в веб-браузере, middle или backend servlet-а, которые запускаются на JBoss EAP, необходимо настроить двустороннюю аутентификацию по протоколу TLSv1.2 с применением зарубежных криптографических алгоритмов.
Задача усложняется тем, что приложение на сервере JBoss в свою очередь взаимодействует, например, с Программно-аппаратным комплексом «ПАК Удостоверяющий центр КриптоПро», где требуется процедура двусторонней аутентификации по протоколу Transport Layer Security (TLSv1.0) c использованием российских криптографических алгоритмов.
Получается, что в одном приложении на сервере JBoss нужно подружить отечественную и зарубежную криптографию.
Аутентификация должна выполняться комбинированным методом инструментами Инфраструктуры открытых ключей (PKI), т.е. с помощью сертификатов клиента и сервера.
Подготовка RSA-ключей аутентификации
Для аутентификации клиента и подтверждения клиенту подлинности самого сервера обеим сторонам необходимо иметь свои пары ключей с сертификатами открытого ключа. А также хранилище корневых доверенных сертификатов, куда должны быть установлены корневые сертификаты удостоверяющих центров, выпустивших конечные сертификаты аутентификации.
Удостоверяющие центры для сервера и клиента могут быть разные.
Пользователь должен доверять удостоверяющему центру, выпустившему сертификат для сервера.
Сервер должен доверять удостоверяющему центру, выпустившему сертификат для клиента.
Существует много утилит и инструментов с хорошим описанием и примерами, которые позволяют работать с хранилищами и выполнять генерацию ключей и запросов на сертификат (keytool, openSSL, Portecle, XCA). Поэтому процесс подготовки хранилищ и выпуск сертификатов здесь пропустим.
Вот, например, хорошая статья и пошаговая инструкция по настройке Two-way SSL with TLS1.2 для Oracle SOA Suite с использованием openSSL и keytool. Но, правда, она частично потеряла актуальность и перестала отражать всю картину. Выпущенные по ней сертификаты не будут корректно восприниматься в веб-браузерах. Так, например, для браузера Google Chrome версии 58 и далее для проверки доменного имени в TLS-сертификате будет использоваться атрибут subjectAlternativeName блока Extensions, а не commonName, как раньше. Теперь браузер выдаст ошибку:
Error: «Subject Alternative Name Missing» or NET::ERR_CERT_COMMON_NAME_INVALID or «Your connection is not private»
если получит с сервера SSL-сертификат без домена в альтернативном имени субъекта сертификации.
Как с помощью openSSL добавить в сертификат subjectAlternativeName — можно посмотреть здесь и здесь
Разумеется, такой способ получения TLS-сертификатов годится только для внутрикорпоративных приложений.
Для взаимодействия с внешними клиентами нужно обращаться в доверенные центры сертификации, корневые сертификаты которых предустановлены в браузеры, JRE, операционные системы и устройства клиентов. Обзор удостоверяющих центров sslshopper.com
В результате созданы два хранилища. Файл ssl-keystore.jks с ключами и сертификатом сервера JBoss EAP для аутентификации перед клиентом. И ssl-truststore.jks – с доверенным корневым сертификатом УЦ, выпустившим клиентский сертификат аутентификации.
Подготовка GOST-ключей аутентификации
Процесс обоюдной аутентификации сервера JBoss и КриптоПро УЦ сервера в сущности такой же. Единственное отличие в криптографических алгоритмах.
Серверы обмениваются сертификатами с алгоритмами подписи ГОСТ Р 34.11/34.10-2001 и хэширования подписи ГОСТ Р 34.11-94 вместо применяемых в RSA TLSv1.2 sha256RSA и sha256 соответственно. В качестве корневого сертификата здесь выступает ROOT-сертификат самого ПАК КриптоПро УЦ.
Для генерации пары ключей и выпуска ГОСТ-сертификата можно воспользоваться тестовым удостоверяющим центром КриптоПро cryptopro.ru/solutions/test-ca
Или, если есть, развернутым корпоративным УЦ. При этом на рабочей станции должен быть установлен криптографический провайдер КриптоПро CSP.
После регистрации на персональной странице можно будет создавать запросы, управлять своими сертификатами.
При генерации ключевой пары КриптоПро CSP просит выбрать хранилище. Это может быть реестр MS Windows, eToken или JaCarta, если установлены драйверы и соответствующее окружение eToken PKI Client 5.1 SP1 aladdin-rd.ru/support
Сервер JBoss через Java-интерфейсы, реализованные в КриптоПро JCP и КриптоПро JCSP, может работать со следующими типами хранилищ:
В контрольной панели КриптоПро JCP появится вкладка OCF и возможность обращаться к eToken через OCFStore.
В данном примере JBoss EAP будет настраиваться на работу с хранилищем KeyStore – HDImageStore. Это значит, что если ключи и сертификат были сгенерированы в реестре ОС Windows, eToken или JaCarta, то нужно решить задачу по их переносу в формат HDImageStore.
Если ключи находятся в реестре или JaCarta, то используем КриптоПро CSP. Вкладка Сервис «Скопировать»
Выбираем контейнер и выполняем его копирование на eToken.
Далее в контрольной панели КриптоПро JCP появляется возможность в OCFStore просмотреть и скопировать этот контейнер из eToken в нужный формат HDImageStore.
Путь к HDImageStore в КриптоПро JCP настраивается на вкладке Hardware
Физически контейнеры с ключами в формате HDImageStore представляют из себя каталоги, в каждом из которых хранится шесть файлов с расширением *.key
В качестве доверенного корневого хранилища с root-сертификатом ПАК КриптоПро УЦ сервер JBoss будет использовать truststore.cpks, подключаемый в КриптоПро JCP на вкладке Keys and certificates stores.
Настройка сервера JBoss
Для настройки сервера JBoss EAP 7.0.0 все изменения нужно внести в конфигурационный файл jboss-EAP-7.0.0\standalone\configuration\standalone.xml
В раздел добавляются настройки, указывающие серверу, каких провайдера и хранилища использовать для двусторонней ГОСТ-аутентификации:
Для настройки RSA TLSv1.2 аутентификации пользователя и сервера JBoss в раздел
нужно добавить область безопасности:
Таким образом, для JBoss указаны все необходимые хранилища ключей и сертификатов.
к уже существующему http-слушателю
нужно добавить https:
Атрибут verify-client=«REQUESTED» указывает серверу, что необходимо запросить сертификат пользователя в браузере при обращении к серверу по https-протоколу.
В раздел #
# user=role1,role2.
#
C\=RU,\ L\=Moscow,\ O\=Alfabank,\ OU\=ORRPP,\ CN\=Vasiliy\ Burmistrov=admin
C\=RU,\ L\=Moscow,\ O\=Alfabank,\ OU\=ORRPP,\ CN\=Ivan\ Petrov=user
В составе поставки КриптоПро JCP есть инструкция по настройке сервера JBoss jcp-2.0.39014\Doc\WebServerIntegration\JBoss\ Howto_set_gost_tls_jboss.docx
ИНТЕГРАЦИЯ JBOSS 6.1.0 Final (“Neo”) и JTLS 2.0. В этом документе речь идет об устаревшей версии JBoss и процессе аутентификации пользователя по протоколу Gost TLS непосредственно на сервере. Это может быть полезно, если стоит цель поднять защищенный по ГОСТ канал между браузером пользователя или иным фронтом и сервером приложений.
Настройка приложения
Для того чтобы при установке deployment-приложение интегрировалось с настройками на сервере, необходимо внести ряд параметров в его конфигурационные файлы.
Домен безопасности и виртуальный хост приложения указываются в /WEB-INF/jboss-web.xml
В файле /WEB-INF/web.xml настраиваются ограничения безопасности:
и способ аутентификации:
В результате этих настроек в приложении на сервере JBoss в Runtime можно получать из запроса веб-браузера или иной фронт-системы сертификат прошедшего аутентификацию пользователя:
Взаимодействуя с ПАК КриптоПро УЦ, приложение использует SOAP API, описание которого приведено в документации ЖТЯИ.00067-02 20 01-ЛУ (ЖТЯИ.00067-02 90 16) «КриптоПро УЦ программно-аппаратный комплекс удостоверяющий центр Руководство программиста»
Веб-сервис вызывается с помощью каркаса Apache Axis 1.4 – реализации интерфейса JAX-WS.
Если в хранилище HDImageStore, кроме ключей аутентификации непосредственно в КриптоПро УЦ, хранятся еще ключи для других приложений и иных целей, то возникает проблема. Apache Axis при вызове сервиса КриптоПро УЦ хватает из хранилища первый попавшийся и, соответственно, аутентификацию не проходит.
Чтобы решить данную проблему, потребовалось сделать свою реализацию SocketFactoryImpl.
Для этого нужно наследоваться от org.apache.axis.components.net.JSSESocketFactory
И реализовать интерфейс org.apache.axis.components.net.SecureSocketFactory
Код собственной фабрики SocketFactoryImpl
Чтобы заставить Apache Axis использовать собственную фабрику, в @Stateless бине,
где конструируем вызов сервиса КриптоПро УЦ, переопределяем системное свойство:
Настройка JRE
Казалось бы, все настроено, и должно работать. Но нет. Остается еще один важный штрих.
Чтобы из приложения на JBoss аутентифицироваться в КриптоПро УЦ по протоколу Gost TLS, сервер JBoss нужно запускать в JRE с установленным КриптоПро JCP провайдером.
При установке JCP в настройки JRE вносятся изменения. В частности, в jre1.8.0_144\lib\security\ java.security алгоритмы KeyManagerFactory и TrustManagerFactory меняются на Gost. Если так оставить, то в JBoss при старте будет возникать ошибка:
2017-10-12 17:44:13,376 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.security.security-domain.myApp: org.jboss.msc.service.StartException in service jboss.security.security-domain.myApp: WFLYSEC0012: Unable to start the SecurityDomainService service
at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:105)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.KeyStoreException: Default store provider (keyStore) is SUN but default config provider (cpSSL) is JCP. Check settings on the tab ‘Algorithms’ of JCP Pane.
at ru.CryptoPro.ssl.r.(Unknown Source)
at ru.CryptoPro.ssl.KeyManagerFactoryImpl.engineInit(Unknown Source)
at javax.net.ssl.KeyManagerFactory.init(Unknown Source)
at org.jboss.security.JBossJSSESecurityDomain.loadKeyAndTrustStore(JBossJSSESecurityDomain.java:488)
at org.jboss.security.JBossJSSESecurityDomain.reloadKeyAndTrustStore(JBossJSSESecurityDomain.java:335)
at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:102)
. 5 more
Для исправления комментируем в файле java.security GostX509
#ssl.KeyManagerFactory.algorithm=GostX509
#ssl.TrustManagerFactory.algorithm=GostX509
и возвращаем настройки по умолчанию SunX509
ssl.KeyManagerFactory.algorithm=SunX509
ssl.TrustManagerFactory.algorithm=PKIX
Результаты
Приложение и среда исполнения с двусторонней аутентификацией настроены, каналы передачи данных зашифрованы, между участниками системы установлены надежные соединения.
Docker-образы с поддержкой ГОСТ-сертификатов в openssl, curl, php, nginx
В этой статье я расскажу о том, как я решал задачу об интеграции в тестовом режиме с сервисами, которые работают с использованием алгоритмов, определенных ГОСТ Р 34.10-2001 (устарел) и ГОСТ Р 34.10-2012. Приведу примеры некоторых проблем, с которыми столкнулся при решении задачи, дам ссылки на готовое решение и покажу несколько примеров их использования.
Причины
Рабочим решением оказалась сборка OpenSSL 1.1.0g + вынесенный в отдельно подключаемый динамический движок GOST-engine. В интернете часто встречается упоминание, что некая российская компания приложила усилия по его разработке, но в самом репозитории нет сведений об авторах продукта. Пользуясь случаем, выражаю авторам благодарность за движок в open source. На этой странице сказано, что до OpenSSL 1.1.0 использовался встроенный движок GOST, сейчас для GOST используется сторонний от OpenSSL продукт. Судя по конфигурации, скорее всего, это одна и та же библиотека.
Сборка OpenSSL, GOST-engine, cURL
Сборка стороннего продукта для тех, кто делает это редко, может быть нетривиальной задачей. Для сборки OpenSSL, GOST-engine и cURL пришлось разобраться с кучей опций и перепробовать несколько комбинаций версий. Если в Dockerfile вы заметите странное, то, скорее всего, это осталось от таких экспериментов.
Я зафиксировал все версии проектов для сборки, чтобы исключить ситуацию, что из-за обновления что-то перестанет работать. Например, я собирал OpenSSL 1.1.0h + GOST-engine и команда openssl ciphers не содержала GOST-алгоритмов, хотя openssl engine показывала GOST-engine в списке. Указав предыдущую версию OpenSSL 1.1.0g, все работало, как ожидалось. Это было очень странно, я повторил это еще раз, потом пытался выяснить причины, но в итоге решил остаться на 1.1.0g.
Собирая сам GOST-engine, я не сразу обратил внимание на наличие файла INSTALL.md в master-ветке, потому что собирал из ветки openssl_1_1_0 по неизвестно откуда взятой документации. Та версия собиралась с кастомной сборкой OpenSSL командой
Но master-ветка так собираться перестала, появились ошибки об отсутствии DOPENSSL_ROOT_DIR и подобное. В итоге решение было найдено и зафиксировано.
Для сборки cURL с кастомной сборкой OpenSSL гораздо больше документации, тем не менее, документация успевала устаревать, и с опциями пришлось много экспериментировать.
Результат работы выложен здесь.
Образ запушен в Docker Hub.
Примеры использования OpenSSL + GOST-engine
Не буду сильно вдаваться в подробности работы с докер-образами, лишь приведу одну команду для начала работы внутри образа:
Для начала можно убедиться, что алгоритмы GOST2012-GOST8912-GOST8912 и GOST2001-GOST89-GOST89 есть в списке поддерживаемых:
Если вам известен хост, который работает по HTTPS на основе ГОСТ-алгоритмов, то посмотреть его сертификат и попробовать подключиться можно командой:
Создать закрытый ключ и сертификат по ГОСТ Р 34.10-2012:
Подписать файл ранее созданными сертификатами:
Извлечь содержимое подписанного файла, сертификатом, который был подписан самим собой:
С подписями самих сертификатов все немного сложнее. Пока мне не попался сервис, у которого сертификат выдан доверенным центром сертификации. Обычно, требуется дополнительно указывать сертификат удостоверяющего центра при работе с выданными им сертификатами. Это можно сделать глобально для системы (в образе), либо явно указывать в каждой команде.
Программа cURL в использовании не изменилась, просто поддерживает хосты с ГОСТ-сертификатами.
Использование образа в работе с языками программирования
Если язык программирования позволяет исполнять установленные в системе программы, то задача использования ГОСТ-алгоритмов проще всего решается копированием бинарников собранных openssl и curl в конце Dockerfile языка программирования с использованием multi-stage build. Например:
Поддержка ГОСТ-алгоритмов в PHP
Поддержка ГОСТ-сертификатов в nginx
Возможность работать из языков программирования это уже много, но хотелось еще две возможности:
Заключение
Мной изучена проблема работы с ГОСТ-алгоритмами в системах Linux, предоставлено решение в виде docker-образов, все это сопровождено документацией и примерами. Решение оформлено в виде репозитория на GitHub.
Собирая образ самостоятельно, вы можете убедиться, что в код не попали злонамеренные правки, потому что сборка происходит только из открытого кода, который доступен для просмотра всем желающим. Тем не менее, это не гарантирует, что в нем нет ошибок и уязвимостей. Использование проприетарных сертифицированных средств так же не гарантирует отсутствие ошибок и уязвимостей, но к тому же их код от вас закрыт.
Все типы шрифтов GOST — Скачать бесплатно
Шрифты для чертежей, соответствующие ГОСТ 2.304-81 «Единой системы конструкторской документации» (ЕСКД), часто бывают нужны на РС для разных приложений, будь то Photoshop, Word или AutoCAD. Шрифтов стиле ГОСТа много, все они различаются гарнитурой, общим начертанием. Но для разных целей необходимы все они.
Мы подобрали для вас несколько шрифтов gost разных по написанию и общему стилю.
Архив для загрузки – один, общий, поэтому вы сможете пополнить свою коллекцию сразу всеми нужными шрифтами!
GOST Type AU
Тонкий, строгий, угловатый шрифт для оформления чертежей. Разработан компанией Аскон (Российский разработчик инженерного ПО для проектирования (Компас).
Количество: 1
GOST Type BU
Чуть более жирный шрифт, крупный, чем предыдущий. Он также был создан компанией Компас.
Количество: 1
GOST Type A прямой
Почти похож на GOST Type AU, но стоит обратить внимание на начертание таких букв как как «И», «Ё», «Ж», «Ю», «Х» и «М». Различия такие мизерные, что мало кому удается отличить эти два шрифта друг от друга.
Количество: 1
GOST Type В прямой
Аналогично с вариантом «А» шрифты серии «В» тоже имеют небольшие различия. Но в большинстве случаев на них мало кто обращает внимание.
Количество: 1
GOST Type А Наклонный
Отдельный вариант GOST Type A в виде курсивного шрифта.
Количество: 1
GOST Type В Наклонный
Отдельный вариант GOST Type В в виде курсивного шрифта.
Количество: 1
Чертежный шрифт не зря получил название «гостовский». Он спроектирован в соответствии с требованиями единой системы конструкторской документации, описанными в межгосударственном стандарте от 1982 года. Гост 2.304-81 устанавливает стандарт на чертежные шрифты, которые наносятся на чертежи и иные виды технической документации.
Если вы нашли ошибку/опечатку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Как настроить Linux для входа в домен с использованием алгоритмов ГОСТ
Введение
Протокол Kerberos 5 сейчас активно используется для аутентификации. Особенностью данного протокола является то, что он осуществляет аутентификацию, базируясь на четырех китах:
Начиная с пятой версии появилась возможность использовать еще асимметричное шифрование (для электронной подписи). Более подробно на работе протокола Kerberos останавливаться не имеет смысла, ибо описание алгоритма можно посмотреть тут.
К сожалению, количество алгоритмов шифрования, хеширования и ЭЦП, которые использует данный протокол, не настолько велико, насколько хотелось бы, поэтому в данной статье я хочу показать, как добавить легко и просто собственные алгоритмы в реализацию данного протокола MIT’ом. Добавлять же мы будем наши отечественные алгоритмы: ГОСТ 28147-89 (aka Магма), ГОСТ Р 34.11-2012 (aka Стрибог) и ГОСТ Р 34.10-2012 (хотелось бы тоже иметь для него aka, но я не знаю:(). Готовое решение для данных алгоритмов можно его найти в моем репозитории. На стороне клиента мы будем использовать аппаратные реализации алгоритмов ГОСТ в Рутокене ЭЦП 2.0 и их программные реализации в engine GOST для openssl. Но самый безопасный вариант хранения ключей – когда они генерируются непосредственно на Рутокене и никогда не покидают его память во время криптографических операций. Для такого варианта работы потребуется rtengine.
Перед тем, как приступить к внедрению алгоритмов, опишем основные места, где будут производится изменения. Внутри директории src/lib/crypto/ находятся реализации всех алгоритмов, отвечающих за симметричную криптографию и хеширование. В ней имеются 2 реализации этих криптографических алгоритмов: встроенная(builtin) и openssl. Дабы сэкономить время и место, мы, естественно, будем добавлять реализации алгоритмов с помощью openssl, в котором они уже есть (ну или почти есть, но об этом чуть позже). Для добавления же асимметричных алгоритмов, нужно будет подправить плагин src/plugins/preauth/pkinit
Если у вас еще не настроен Kerberos, то инструкцию по его первичной настройки и эксплуатации можно взять тут. В дальнейшем автор полагает, что вы работаете с доменом AKTIV-TEST.RU
Добавление алгоритмов хеширования и симметричного шифрования
Как уже было ранее озвучено, мы не будем писать алгоритмы шифрования и хеширования с нуля, а воспользуемся готовой реализацией данных алгоритмов в openssl. Напрямую openssl не поддерживает в себе реализацию отечественных алгоритмов, но обладает мобильностью в данном вопросе и позволяет добавлять новые алгоритмы, используя механизм engine GOST для работы с ключами в файловой системе и, хранящие на токене — rtengine.
Небольшое введение в механизм engine openssl и подключение engine GOST
Engine в openssl – это небольшая динамическая библиотека, которую openssl подгружает в runtime по требованию. Каждая такая библиотека, должна содержать в себе определенные символы (функции) для загрузки необходимых алгоритмов. В данной работе мы воспользуемся engine gost, который содержит в себе все необходимые отечественные криптографические алгоритмы.
Установка дичайше проста, например, и происходит следующим образом:
Выкачиваете из репозитория реализацию данного энджина.
собираете библиотеку с ним (mkdir build && cd build && cmake… && make):
В директории bin (КОТОРАЯ ПОЯВИТСЯ В КОРНЕВОМ КАТАЛОГЕ ПРОЕКТА. ) будет лежать динамическая библиотека gost.so – это и есть наш энджин. Его нужно будет перенести в директорию, где хранятся энджины openssl. Узнать месторасположение данной директории можно с помощью:
Дело за последним – нужно сказать openssl, где находится данный энджин и как он называется. Сделать можно это с помощью изменения файла конфигурации openssl.cnf. Месторасположение которого можно узнать с помощью:
В конец данного файла нужно будет внести следующее содержимое:
После этого данный энджин должен появится в openssl. Проверить его работоспособность можно заставив, например, сгенерировать приватный ключ в файле по ГОСТ Р 34.10-2012:
Реализация алгоритма хеширования
Начнем с самого простого – с реализации алгоритма Стрибог. Kerberos обладает жесткой связью алгоритма хеширования и шифрования, то есть вы не можете просто так взять и выбрать для шифрования один алгоритм, а для хеширования другой – вам нужно будет встроить связку алгоритма хеширования и шифрования. Причина этого мне не известна, но раз там бытуют такие правила – давайте попробуем создать связку алгоритма Стрибог и AES.
Т.к. нам понадобится уверенность в подключении в разных местах нашей программы, давайте создадим сначала небольшую библиотеку gost_helper, которая будет содержать в себе функцию инициализации энджина в openssl, а так же для удобства несколько функций, возвращающих контексты некоторых алгоритмов хеширования – нам это поможет в дальнейшем. Назовем эту библиотеку gost_helper и создадим для нее соответствующий заголовочник и исходный файл в директории src/lib/crypto/openssl/:
После добавления вспомогательной библиотеки необходимо будет объявить о ее существовании в Makefile и выписать ее зависимости от файлов. Для этого добавим следующее:
Стоит заметить, что в дальнейшем при подключении данной библиотеки, нам надо будет добавлять зависимости некоторых файлов от заголовочника данной библиотеки. Делается это очень просто – отыскивается цель, куда надо добавить зависимость в deps файле и записывается зависимость от rel/path/to/gost_helper.h. Например, в src/lib/crypto/openssl/hash_provider/deps нужно будет добавить следующее:
В целях экономии места в статье и чтобы размять ваши мозги, я больше не буду обращать на это внимание: будьте внимательны и осторожны!
Добавим теперь реализации функций хеширования, все их реализации у нас лежат в src/lib/crypto/openssl/hash_provider/hash_evp.c. Туда нужно будет дописать следующее:
Теперь надо объявить эти контексты во всей библиотеке. Для этого нужно создать их описание в файле src/lib/crypto/krb/crypto_int.h.
Объявим идентификатор связки Стрибог и AES, внедря макросы, которые мы назовем CKSUMTYPE_STRIBOG_256_AES256, CKSUMTYPE_STRIBOG_512_AES256, ENCTYPE_AES256_CTS_STRIBOG_256, ENCTYPE_AES256_CTS_STRIBOG_512. Их надо объявить в шаблоне заголовочного файла src/include/krb5/krb5.hin. Выглядеть это будет примерно так:
Теперь необходимо добавить две связки функции хеширования и шифрования и функции шифрования и хеширования. Зачем две, если они эквиваленты, спросите вы? Ответ: не знаю, или это исторический костыль или способ оптимизации. Тем не менее, давайте добавим в необходимые файлы новые структуры:
Казалось бы уже все, а вот и нет! Далее наступают проблемы, которые будут видны только в процессе отладки, некоторых из них можно было бы избежать, указав, например, другие указатели на функции в вышеуказанных структурах, но мы пойдем более сложным путем, чтобы показать, что еще возможно придется исправить по дороге. Обо всех этих проблемах я узнал только пользуясь отладчиком:
После всех этих изменений можно проверить работу алгоритма. Соберем все, что мы наделали.
Теперь приступим к проверке. Для этого давайте выставим принудительное использование внедренных нами алгоритмов в файлы конфигурации Kerberos. Выполните следующее:
Подправим файл конфигурации kdc.conf (у меня это /usr/local/var/krb5kdc/kdc.conf). Выставим принудительное хеширование с помощью нововведенного алгоритма:
Аналогичные изменения в файле конфигурации всего протокола krb5.conf (у меня он находится по адресу /etc/krb5.conf):
Далее запустим krb5kdc т.к. изменился master_key, то возможно придется создать базу данных principals заново с помощью krb5_newrealm.
После этого создаем всех необходимых принципалов и можно начать работу. Попробуйте аутентифицироваться с помощью kinit.
Если сервис не запускается, то его можно запустить из-под рута с помощью src/kdc/krb5kdc. Если все запустилось, прошло гладко – поздравляю вас! Иначе – увы, панацею от всех проблем я не предлагаю, а лишь предлагаю «небольшую» инструкцию, содержащую основные шаги, которые вам придется совершить, дабы внедрить новый алгоритм в Kerberos. И если у вас ничего не вышло – берите в руки gdb и смотрите, где что выходит не так. Вам лишь могу дать несколько советов:
По идее этого набора советов вам должно хватить для того чтобы избавить себя от лишней траты времени в поисках «неизведанного».
Реализация алгоритма шифрования
В этом разделе я покажу, как можно добавить свой алгоритм шифрования данных в Kerberos, и мы попробуем создать связку Магмы и Стрибога, добавленного в прошлом разделе. Тут я уже предполагаю, что небольшая библиотека gost_helper уже была добавлена в прошлом разделе. Ну что же, разминаем пальцы и приступаем:
Сначала опишем алгоритм в нашей библиотеке libk5crypto описав их в заголовочном файле src/lib/crypto/krb/crypto_int.h.
В директории src/lib/crypto/openssl/enc_provider добавим исходник gost.c, содержащий в себе реализацию всех необходимых алгоритмов (за основу я взял исходник алгоритма des). Важно заметить, что мы реализуем только режим шифрования cbc, так что для самопроверки вы можете взять любой другой режим шифрования и добавить его:
В шаблоне src/lib/crypto/openssl/enc_provider/Makefile.in укажем, что появился новый исходник:
Не забываем про указание зависимостей в src/lib/crypto/openssl/enc_provider/deps:
Добавим идентификаторы связок к src/include/krb5/krb5.hin:
Опишем структуру связок функции хеширования и шифрования, как в прошлом разделе:
Добавим в список режимов шифрования по умолчанию в файле src/lib/krb5/krb/init_ctx.c:
После этих манипуляций можно попробовать протестировать нововведенный алгоритм. Тестирование происходит аналогичным образом, что и в прошлом разделе. Имя связки можно взять в виде алиаса (например, gost89-stribog512) или с помощью имени самого алгоритма (например, gost89-cbc-stribog-512). Надеюсь, что все заработает, иначе не забывайте о том, что я сказал ранее.
Добавление алгоритма цифровой подписи
Ура! Мы приступаем к финальному разделу данной статьи и попробуем добавить собственный алгоритм электронной подписи. Не стоит пугаться, его добавить проще чем что-либо еще, так что давайте поскорее приступим… Хотя нет, подождите, для начала небольшая ремарка.
Асимметричное шифрование, достаточно, тяжеловесная штука. Одна из его главных особенностей – возможность аутентификации: все это построено на удостоверяющих центрах, сертификатах и всякой-всякой сложной лабуде. Как говорится.
Ребята, не стоит вскрывать эту тему. Вы молодые, шутливые, вам все легко. Это не то. Это не Чикатило и даже не архивы спецслужб. Сюда лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте тему и забудьте, что тут писалось. Я вполне понимаю, что данным сообщением вызову дополнительный интерес, но хочу сразу предостеречь пытливых — стоп. Остальные просто не найдут.
Как-то так. Ну что же, если у вас хватило смелости приступить к этому, то давайте начнем. В данной статье я покажу вам два способа получения и хранения приватных ключей и сертификатов: в файловой системе и на токене. В сущности, для обоих применима Аксиома Эскобара, но для второго способа потребуется дополнительный энджин, так что если вы решитесь пойти путем шиноби, то милости просим в данный раздел, остальные могут его пропустить.
Настройка openssl для работы с токенами (на примере Рутокен)
Для работы с Рутокенами, аппаратно поддерживающими ГОСТ-криптографию, для openssl существует rtengine. Его установка достаточно проста и не сильно отличается от GOST, нужно только знать, что и где брать.
Скачиваете отсюда SDK rutoken разработчика и достаете из папки sdk/openssl/rtengine/bin/ собранную под вашу платформу библиотеку с энжином и помещаете в папку с engine.
Скачать и установить модуль librtpkcs11ecp.so. отсюда
Собирать утилиту из ветки master OpenSC взяв коммит 8cf1e6f
После того как мы все это сделали, осталось настроить конфигурационный файл openssl.cnf:
Работоспособность engine мы проверим на деле.
Создание приватного ключа и сертификата для принципала, KDC и УЦ
За основу данной инструкции была взята инструкция по настройке kerberos. Я лишь адаптировал ее для работы с русскими алгоритмами, так что частично заглядывайте туда.
Создадим приватный ключ и сертификат удостоверяющего центра, а также приватный ключ, запрос на сертификат и сам сертификат, подписанный УЦ для KDC:
Изменим конфигурационный файл kdc, чтобы он знал, откуда брать ключи и сертификаты:
[libdefaults]
spake_preauth_groups = edwards25519
Создадим приватный ключ и заявку на сертификат для нашего принципала. Тут будет развилка, и надо выполнить разные действия в зависимости от того, где мы будем хранить приватный ключ: на токене или в ФС:
Для создания ключа и заявки в ФС все делаем почти аналогично, как для KDC:
Для создания ключа на токене и подписания сертификата для него нужно выполнить следующее:
Теперь подпишем нашу заявку:
Теперь дело за малым: в первом случае загружаем сертификат в специальную директорию, во втором – на токен:
Настраиваем файл конфигурации клиента (у меня это /etc/krb5.conf):
Надеюсь, что на данном этапе проблем не возникнет. Мы совсем близко! Добавим реализацию новых алгоритмов.
Добавление нового алгоритма цифровой подписи
Алгоритмы ЭЦП добавить куда проще чем те, что рассматривались ранее – придется заменить всего-то 2 файли! src/plugins/preauth/pkinit/pkcs11.h и src/plugins/preauth/pkinit/pkinit_crypto_openssl.c
Начнем с добавления идентификаторов новых механизмов и ключей в заголовочник pkcs11.h. Идентификатор механизма – это название алгоритма, который подается токену для того, чтобы он его совершил. Все эти идентификаторы стандартизированы и их можно найти в интернете (хоть и с большим трудом). Наши я нашел здесь в sdk/pkcs11/include/rtpkcs11t.h. Добавим в заголовочник следующие идентификаторы ключей и механизмов:
Всеми ими мы не воспользуемся, но на будущее можно добавить.
В файле pkinit_crypto_openssl.c, в первую очередь, нужно добавить подгрузку энджинов перед началом работы. Вызов этой функции также нужно вставить перед get_key, т.к. эта функция почему-то вызывается перед подгрузкой энджинов:
После инициализации энджинов можно приступить к замене механизмов и электронной подписи. В данный момент жестко зашит только один алгоритм – RSA с хешом, полученным из sha1. Мы же встроим выбор между возможными режимами в зависимости от типа ключа, хранящегося на токене или в ФС. Для этого введем несколько функций, которые будут на вход получать контексты шифрования, а на выходе выдавать необходимые идентификаторы алгоритмов и механизмов. Также будет необходимо немного подправить функцию получения хендла приватного ключа с токена, т.к. она возвращает только RSA ключи:
Теперь лишь осталось в функциях создания цифровой подписи cms_signeddata_create и create_signature заменить жесткую установку алгоритма на выбор алгоритма в зависимости от контекста:
После всех этих манипуляций вы можете попробовать зайти, используя токен или сертификат в файловой системе (во втором случае, вероятно, потребуются права рута):
Если после запроса пароля токена не потребовалось вводить пароль user, значит, все отработало правильно.
Все замечания и вопросы вы можете писать в комментариях, а я постараюсь на них оперативно ответить.