XCA – удостоверяющий центр уровня предприятия или сага о русских и немецких программистах

    I think noone ever looked at the code as deeply as you did.
    Christian Hohnstädt, Programming, Translation and Testing XCA
    Перевод:
    Я думаю, что еще никто так глубоко не заглядывал в мой код, как вы.
    Christian Hohnstädt, разработчик XCA

    imageУдостоверяющий Центр (УЦ, Certification authority — CA) – это достаточно сложный организм, который включает в свой состав не только программно-аппаратный комплекс, состоящий из множества компонент, но и требующий наличия целого штата высококвалифицированных специалистов для обеспечения его работоспособности и т.д. Можно спросить, а зачем вообще нужен удостоверяющий центр, какую продукцию он производит и где она применяется?

    Что общего между сертификатом x509 и паспортом гражданина?
    Что общего между паспортным столом и Удостоверяющим центром?


    Главная функция УЦ центра – изготовление и сопровождение сертификатов ключей проверки электронной подписи (СКПЭП), включая создание ключевой пары по обращению владельца сертификата. Сразу оговорюсь, по моему глубокому убеждению, последняя услуга УЦ центра вредна и опасна.
    Тот, кто получил сертификат и ключевую пару (закрытый и публичный ключ или как его еще называют ключ проверки электронной подписи), в любой момент может отказаться от своей электронной подписи (ЭП) под документом и заявить, что у него ключ могли украсть в УЦ в момент его генерации. Поэтому ключевую пару правильно генерировать самому и хранить как зеница око, а если и генерировать его в УЦ, то только на токене/смарткарте PKCS#11 с неизвлекаемым ключом.

    Отметим, что УЦ выпускают сертификаты в соответствии со стандартом X.509 v.3 (RFC 5280 ).
    Вообще функции УЦ во многом совпадают с функциями паспортного стола, которые находятся в ведении МВД России.
    Сертификат, также как и паспорт, выдается на основании заявления и предоставления ряда документов. Перечень документов для получения сертификата есть на любом удостоверяющем центре, имеющим аккредитацию Минкомсвязи.
    imageЧто является главным в паспорте, получаемым гражданином? Это серия и номер, кем и когда выдан, фотография и собственноручная подпись гражданина в паспорте, заверенные подписью сотрудника ОВД и скрепленные печатью.
    А что является главным в сертификате? У него также есть серийный номер, кем выдан, сведения о гражданине, включая и СНИЛС и ИНН, и аналог фотографии и собственноручной подписи гражданина – это публичный ключ или ключ проверки электронной подписи. И вот это все заверяется электронной подписью УЦ. И полученный документ (файл) и называется сертификатом. Вы спросите, а где же закрытый ключ, с помощью которого собственно и ставится электронная подпись под документами? А закрытый ключ, как мы говорили выше, должен храниться у гражданина на электронном носителе (флэшка, токен/смарткарта), аналогично тому, как умением ставить личную подпись, образец которой он и оставил в своем паспорте, владеет он и только он. Поэтому всегда можно абсолютно уверенно сказать действительная подпись гражданина под документом или нет. Как ни странно аналогичная ситуация и с электронной подписью. Имея закрытый ключ, гражданин может однозначно получить открытый ключ и по нему проверить его сертификатом подписан документ или нет!
    imageА что делать гражданину, если у него украли или он потерял паспорт? Срочно необходимо заявить в паспортный стол, ОВД. После этого паспорт считается недействительным и он попадает в список недействительных российских паспортов. С этого момента любые юридические действия со ссылкой на утраченный паспорт недействительные. Аналогичная ситуация и с отзывом сертификата. Если был утерян закрытый ключ (а он как правило хранится на отторгаемом носителе – флэшка, токен, смаорткарта и т.п) или есть подозрение, что его скопировали, то надо срочно обращаться на УЦ, чтобы сертификат отозвали (признали недействительным). Он в этом случае попадает в САС – список аннулированных сертификатов. Хочу обратить внимание, что сертификат отзывается не тогда, когда пропал сертификат, а именно закрытый ключ. Сам сертификат вещь публичная и дубликат его всегда можно подучить на УЦ.

    Зачем нужен сертификат x509?


    imageИ так зачем нужен сертификат гражданину РФ и юридическим лицам? Самое узнаваемое – это доступ на портал Госуслуг. Не менее значимое – доступ на портал ФНС. Далее — электронные торги и многое другое. Как правило, этот список есть на каждом УЦ, зарегистрированном в Минкомсвязи.
    С юридическими лицами и гражданами РФ все ясно. А зачем сертификат проверки электронной подписи может понадобиться сотруднику некоего предприятия? Оказывается для многого. Личный сертификат (сертификат и ключевая пара), хранящийся на токене или смарткарте с интерфейсом PKCS#11, может служить и пропуском на территорию предприятия и обеспечивать доступ к компьютеру, дает возможность подписывать и шифровать документы, иметь доступ в личный кабинет на портале предприятия, пользоваться услугами корпоративной VPN, иметь доступ к порталу предприятия по авторизованному HTTPS. И для этого совсем не обязательно получать для внутрикорпоративных целей сертификат вне предприятия на аккредитованном Минкомсвязью УЦ и платить за это деньги. С другой стороны, развертывание полномасштабного УЦ на малых и средних предприятий не только не по силам, но и аналогично стрельбе из пушки по воробьям. Малому и среднему бизнесу не нужна большая часть функциональности подобных комплексов: ни к чему им маcштабируемость, горячее резервирование, разделение полномочий и т.д.

    Предпосылки появления XCA (X Window System Certification authority)


    Для выпуска для издания сертификатов x509v.3 можно было бы воспользоваться широко используемой командной утилитой OpenSSL, в частности, она позволяет выполнять следующие функции:
    • генерация ключей (например, openssl genrsa… );
    • формирование запроса в формате PKCS#10 на получение сертификата x509 v.3;
    • издание сертификата x509 v.3;
    • формирование списка аннулированных сертификатов (САС/CRL);
    • и т.д.

    Если внимательно посмотреть, то оказывается, что все это функции УЦ, более того одна из команд утилиты OpenSSL, а именно команда CA представляет собой УЦ с минимально-необходимой функциональностью:
    $openssl ca -md <hash> -in <req_file> -out <cert_file>

    где:
    • ca – команда, для работы с УЦ
    • md — опция, указывающая на то какую хэш-функцию (например, sha1, sha512, gosthash ) использовать для выдачи сертификата ключа проверки электронной подписи (ЭП)
    • in — опция, указывающая на то, что запрос на сертификат ключа проверки ЭП надо взять из файла <req_file>
    • out — опция, указывающая на то, что сгенерированный сертификат ключа проверки ЭП надо записать в файл <cert_file>
    Недостатки использования командной утилиты OpenSSL очевидны:
    • большое количество команд и еще большее число параметров команд, в частности, только для выпуска сертификата требуется не менее 5 команд;
    • достаточно сложный конфигурационный файл openssl.cnf;
    • но самое главное – отсутствие единого хранилища (базы данных) сертификатов, что очень и очень затрудняет процесс управления сертификатами

    Именно последний пункт отличает в лучшее сторону аналогичный по сути проекту OpenSSL проект NSS (Network Security System), который широко используется для работы с сертификатами в проектах от Mozilla, браузерах Chrome от Google (ССЫЛКА — ) и т.д. А если говорить еще и об удобстве работы, то хотелось бы иметь единый графический интерфейс на базе X Windows System для издания и управления сертификатами (Certification authority). X Window System — оконная система, обеспечивающая стандартные инструменты и протоколы для построения графического интерфейса пользователя.

    Функционал XCA


    imageИ вот исходя из этих предпосылок и родился проект с открытым кодом (Copyright) XCA, в котором для криптографических преобразований используется библиотека OpenSSL, для графического интерфейса используется библиотека Qt, а в качестве языка программирования язык C++. Для проектирования графического интерфейса использован Qt Designer (утилита designer), что делает весьма простым доработку графического интерфейса с учетом специфических требований российского законодательства и нормативных актов регуляторов, например, форму графического интерфейса для нового сертификата (файл ~/src/ui/NewX509.ui):

    image

    Для хранения объектов УЦ в XCA создается база данных, доступ к которой защищен паролем.
    Графический итерфейс XCA как удостоверяющего центра реализован в виде пяти функциональных вкладок и двух выпадающих меню:
    — функции управления базой данных, предназначенной для хранения информации о ключах, сертификатов и других объектов XCA;

    — функции создания и управления ключами;

    — функции управления запросами на сертификаты (PKCS#10);


    — функции управления сертификатами x509 v3;


    — функции управления шаблонами для запрсов;


    — функции управления списками аннулированных сертификатов (САС/CRL);


    — функции управления токенами/смарткартами PKCS#11;

    Можно смело утверждать, что графическое приложение XCA является Центром выдачи и управления Сертификатами (далее ЦС XCA).

    О поддержке российских криптоалгоритмов в XCA


    Теперь нас будет интересует поддержка российских криптоалгоритмов в ЦС XCA. И если бы это происходило до 2012 года, все было бы хорошо: к тому времени в проекте OpenSSL уже появилась поддержка и ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94 и ГОСТ 28147-89. Но в 2012 году были утверждены новые криптографические алгоритмы ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012, а в 2015 году были утверждены новые аггоритмы для шифрования «кузнечик» и «магма», а именно ГОСТ Р 34.12-2015 и ГОСТ Р 34.13-2015.
    К сожалению, в настоящее время OpenSSL не поддерживает новые российские алгоритмы. В этом случае имеется два пути решения проблемы. Первый связан с разработкой нового engine, на подобие имеющегося libgost, с поддержкой новых российских алгоритмов. Второй путь – это непосредственное встраивание российских алгоритмов в OpenSSL. Второй путь представляется более предпочтительным, так как и в первом случае необойтись без модернизации OpenSSL, хотя с точки зрения реализации новых требований ТК-26 хотя бы к контейнеру PKCS#12. Встаивание новых алгоритмов предполагает прежде всего включение российских OID-ов, рекомендуемых ТК-26, в проект OpenSSL (obj_mac.h):
    #define SN_cryptopro            "cryptopro"
    #define NID_cryptopro           805
    #define OBJ_cryptopro           OBJ_member_body,643L,2L,2L
    #define SN_cryptocom            "cryptocom"
    #define NID_cryptocom           806
    #define OBJ_cryptocom           OBJ_member_body,643L,2L,9L
    #define SN_id_tc26              "id-tc26"
    #define NID_id_tc26             958
    #define OBJ_id_tc26             OBJ_member_body,643L,7L,1L
    	…

    Для удобства встраивания ГОСТ-алгоритмов в XCA и идентичности с OpenSSL отметим также введенные константы, определяющие тип ключа для ГОСТ:
    #define EVP_PKEY_GOST3410			NID_id_GostR3410_2001
    #define EVP_PKEY_GOST3410_2012_256	NID_id_GostR3410_2012_256
    #define EVP_PKEY_GOST3410_2012_512	NID_id_GostR3410_2012_512

    Вот как теперь могла бы выглядеть структура struct typelist typelist[] в файле NewKey.cpp:
    static const struct typelist typeList[] = {
    	{ "RSA", EVP_PKEY_RSA },
    	{ "DSA", EVP_PKEY_DSA },
    #ifndef OPENSSL_NO_EC
    	{ "EC",  EVP_PKEY_EC  },
    #endif
    /*ГОСТ Р 34.10-2001 */
    	{ "GOSTR3410-2001", EVP_PKEY_GOST3410},
    /*ГОСТ Р 34.10-2012 с длиной ключа 256 бит*/
    	{ "GOSTR3410-2012-256", EVP_PKEY_GOST3410_2012_256},
    /*ГОСТ Р 34.10-2012 с длиной ключа 512 бит*/
    	{ "GOSTR3410-2012-512", EVP_PKEY_GOST3410_2012_512},
    };

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

    image

    выпуском сертификатов и кончая выпуском списков аннулированных сертификатов(CRL/САС):

    image

    Выше мы говорили, что приватный ключ и сертификат сотрудники предприятия должны получать на отторгаемом носителе. В качестве такого носителя в ЦС «XCA» используются токены/смаркарты (token/smartcard), имеющие интерфейс PKCS#11. Если говорить о поддержке российской криптографии, то необходима доработка проекта для поддержки токенов PKCS#11 с соответствии с рекомендациями ТК-26 (pkcs11_gost.h):
    	…
    #define NSSCK_VENDOR_PKCS11_RU_TEAM 0xd4321000 //0x80000000|0x54321000
    #define NSSCK_VENDOR_PKSC11_RU_TEAM NSSCK_VENDOR_PKCS11_RU_TEAM
    #define CK_VENDOR_PKCS11_RU_TEAM_TC26 NSSCK_VENDOR_PKCS11_RU_TEAM
    	…

    Размещение ЦС «XCA» на предприятии


    И так, в итоге мы будем иметь полнофункциональный УЦ масштаба предприятия, полностью поддерживающий российскую криптографию.
    Где размещать ЦС «XCA»? Самое разумное – это отдел кадров или служба безопасности. Приходя при приеме на работу в одну из этих служб сотрудник получает здесь помимо все прочего токен, на котором сгенерирован неизвлекаемый ключ:

    image

    и установлен его сертификат:

    image

    В итоге в БД ЦС «XCA» будут храниться как корневой самоподписанный сертификат центра, так и сертификаты сотрудников предприятия:

    image

    В БД также находится информация о том, где хранятся приватные ключи:

    image

    Новогодние хлопоты


    И вот, после кропотливого изучения проекта, его автору Christian Hohnstädt в предверии Нового Года было отправлено следующее письмо:
    Hello, Christian!
    We monitor your product XCA. Exploring it, we raise our professional
    level. We adapt it to use Russian cryptographic algorithms. In gratitude
    for your work we want to send you a gift (a bottle of Russian vodka),
    but, unfortunately, do not know your post address. Please let us know
    it,so we can send you a gift.

    В переводе это выглядит так:
    Здравствуйте, Christian!
    Мы следим за вашим продуктом XCA. Исследуя его, мы повышаем свой профессиональный уровень. Мы адаптировали его под Российские криптографическин алгоритмы. В благодарность за вашу работу мы хотим выслать вам подарок (бутылку русской водки), но, к сожалению, не знаем вашего почтового адреса. Пожалуйста, сообщите нам его.

    И автор откликнулся:
    Thanks, please send it to me at my company address.
    I'm usually not at home when parcel services deliver packets.

    Innominate Security Technologies
    Christian Hohnstaedt
    Rudower Chaussee 13
    12489 Berlin
    Germany

    Что примечательного в ответе автора:
    Спасибо, пришлите, пожалуйста, его на адрес моей компании. Обычно я не дома, когда служба доставки доставляет посылки.

    imageОказалось, что немецкие программисты как и русские да и все программисты мира основное время проводят на работе!
    И конечно, наш традиционно русский презент бутылка водки и коробка конфет, но с добавлением мягкой игрушки Лисенка, был доставлен Автору!!!

    Но перед этим было письмо, выдержка из которого вынесена в начало статьи:
    If your programmers found issues or bugs in my code,
    I ask you to tell me about them so I can fix them, too.
    I think noone ever looked at the code as deeply as you did.

    И вот перевод:
    Если ваши программисты нашли ошибки в моем коде, я прошу вас сообщить мне о них, чтобы я мог их исправить.
    Я думаю, что еще никто так глубоко не заглядывал в мой код, как вы.

    Такая оценка дорогого стоит.
    Что тут можно добавить? Только то, что ЦС «XCA» функционирует под управлением ОС Linux, Mac OS X, других форков Unix и MS Windows.
    P.S. Можно только мечтать о таком сотрудничестве и понимании программистов двух великих стран – Российской Федерации и Федеративной Республики Германии.
    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 5
    • 0
      Так и хочется сказать «Наши русские, смекалистые программисты добавили несколько строчек в выпадающий список! А трудолюбивые немецкие программисты протестировали наши изменения и поразились нашей русской смекалости. Ура товарищи! Пролетарии всех стран объединяйтесь!»

      Мимо хабра промахнулись?
      • 0
        тоже подумал, что статья больше для хабра
        • 0
          Куда, добавили? В XCA? Так он и так хорошо написан.
          А вот добавить поддержку ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012 в OpenSSL или в поддержку токенов PKCS#11- да тут нужна смекалка и несколькими строчками не обойдешься.
          А когда это сделано, то и не зазорно добавить и несколько строк.
        • 0
          Что русскому хорошо, то немцу и отправим.
          Я правильно понимаю, что это прежде всего интересно для компаний-бизнесов, а не для государственных контор? Вроде своего карманного корпоративного УЦ?
          • 0
            И да и нет. Госконторы точно также могут использовать для своих нужд — никто не мешает.
            А вот для Госуслуг или ФНС скажем — то снпчпло надо зарегистрировать в Минкомсвязи.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.