КриптоПро | Цифровой сертификат

КриптоПро | Цифровой сертификат Электронная цифровая подпись

Что же такое pkcs#11?

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

Мы рекомендуем использовать программу КриптоАРМ Стандарт Плюс, которая с версии 5 поддерживает этот протокол. 

Стандарты, основанные на иок

Большинство стандартов, использующих криптографию, разработано с учетом использования ИОК.

Что такое криптография с открытыми ключами

Криптографическое преобразование (шифрование)- взаимно-однозначное математическое преобразование, зависящее от ключа (секретный параметр преобразования), которое ставит в соответствие блоку открытой информации (представленной в некоторой цифровой кодировке) блок шифрованной информации, также представленной в цифровой кодировке. Термин шифрование объединяет в себе два процесса: зашифрование и расшифрование информации.

Криптография делится на два класса: с симметричными ключами и открытыми ключами.

В криптографии с симметричными ключами отправитель и получатель используют один и тот же (общий) ключ, как для шифрования, так и для расшифрования.

Преимущества криптографии с симметричными ключами:

Недостатки криптографии с симметричными ключами:

В криптографии с открытыми ключами используется пара ключей: открытый ключ и секретный (личный) ключ, известный только его владельцу. В отличие от секретного ключа, который должен сохраняться в тайне, открытый ключ может распространяться по сети. Секретный ключ в криптографии с открытыми ключами используется для формирования электронной подписи и расшифрования данных.

Криптография с открытыми ключами обеспечивает все требования, предъявляемые к криптографическим системам. Но реализация алгоритмов требует больших затрат процессорного времени. Поэтому в чистом виде криптография с открытыми ключами в мировой практике обычно не применяется.

Криптография с открытыми ключами требует наличия Инфраструктуры Открытых Ключей (PKI – Public Key Infrastructure) – неотъемлемого сервиса для управления электронными сертификатами и ключами пользователей, прикладного обеспечения и систем.

Верификация открытого ключа

Непосредственное использование открытых ключей требует дополнительной их защиты и идентификации для определения связи с секретным ключом. Без такой дополнительной защиты злоумышленник может представить себя как отправителем подписанных данных, так и получателем зашифрованных данных, заменив значение открытого ключа или нарушив его идентификацию.

Электронный сертификат представляет собой цифровой документ, который связывает открытый ключ с определенным пользователем или приложением. Для заверения электронного сертификата используется электронная цифровая подпись доверенного центра – Центра Сертификации (ЦС).

Исходя из функций, которые выполняет ЦС, он является основной компонентой всей Инфраструктуры Открытых Ключей. Используя открытый ключ ЦС, каждый пользователь может проверить достоверность электронного сертификата, выпущенного ЦС, и воспользоваться его содержимым.

Верификация цепочки сертификатов

Как описывалось ранее, доверие любому сертификату пользователя определяется на основе цепочки сертификатов. Причем начальным элементом цепочки является сертификат центра сертификации, хранящийся в защищенном персональном справочнике пользователя.

Процедура верификации цепочки сертификатов описана в рекомендациях X.509 и RFC 2459 и проверяет связанность между именем Владельца сертификата и его открытым ключом. Процедура верификации цепочки подразумевает, что все “правильные” цепочки начинаются с сертификатов, изданных одним доверенным центром сертификации.

Под доверенным центром понимается главный ЦС, открытый ключ которого содержится в самоподписанном сертификате. Такое ограничение упрощает процедуру верификации, хотя наличие самоподписанного сертификата и его криптографическая проверка не обеспечивают безопасности.

Алгоритм верификации цепочек использует следующие данные:

Цепочка сертификатов представляет собой последовательность из n сертификатов, в которой:

Одновременно с цепочкой сертификатов используется цепочка СОС, представляющая собой последовательность из n СОС, в которой:

После построения двух цепочек (сертификатов и СОС) выполняется:

Ipsec

Протокол IPSEC (Internet Protocol Security Protocol) разработан IETF как протокол для шифрования IP и является одним из основных протоколов, используемых для построения VPN. ИОК в протоколе IPSEC используется для аутентификации и шифрования. В настоящее время протокол еще широко не распространен, но повсеместное развитие ИОК приводит к возрастания количества реализаций IPSEC.

S/mime

Стандарт S/MIME определен IETF для обеспечения защищенного обмена сообщениями. S/MIME использует ИОК для формирования ЭЦП и шифрования информации. В группе стандартов S/MIME наиболее важными являются следующие: Cryptographic Message Syntax, Message Specification, Certificate Handling и Certificate Request Syntax.

Читайте также:  Сертификат эцп отпечаток

Secure electronic transactions (set)

Протокол SET был разработан фирмами Visa и MasterCard и предназначен для обеспечения системы электронных банковских расчетов с использованием пластиковых карт. В данном протоколе ИОК является фундаментом, на котором базируется вся система аутентификации участников расчетов.

Ssl и tls

Протокол SSL (разработанный фирмой Netscape) и соответствующий ему стандарт IETF TLS (RFC 2246) являются наиболее используемыми стандартами для обеспечения защищенного доступа к Web. Вместе с этим, SSL и TLS широко используются для создания клиент – серверных приложений, не использующих Web. Оба эти протокола в своей основе используют ИОК.

X.509

Стандарт X.509 ITU-T является фундаментальным стандартом, лежащим в основе всех остальных, используемых в ИОК. Основное его назначение – определение формата электронного сертификата и списков отозванных сертификатов.

Глава вторая: ещё одна эп

Порывшись в почте, я нашел еще один электронный договор. По счастливой случайности, им тоже оказался страховой полис, но на этот раз еОСАГО от АО “Тинькофф Страхование”. Открываем сертификат, смотрим выпустившую сертификат организацию. Ей оказывается АО “Тинькофф банк”.

По отработанному алгоритму идём в поисковую систему с запросом “тинькофф сертификат”, находим официальный сайт УЦ АО Тинькофф Банк. Тут нас встречает изобилие ссылок на корневые сертификаты, списки отозванных сертификатов и даже видеоинструкция по их установке.

Скачиваем “Цепочка корневых сертификатов УЦ АО Тинькофф Банк ГОСТ Р 34.10.2021”, на этот раз ссылка ведёт не на сторонний сервис, а на сайт банка. Формат файла P7B не очень известный, но открывается Windows без установки стороннего софта и показывает находящиеся в нём сертификаты.

Ставим оба, проверяем сертификат в полисе. Но нет, сертификат не является доверенным, т.к. система не может подтвердить поставщика сертификата. На сайте УЦ было 2 ссылки на 2 цепочки сертификатов, один для ГОСТ Р 34.10.2001, другой для ГОСТ Р 34.10.2021.

В новом файле формата P7B оказывается уже 3 файла сертификатов. Можно поставить все 3, однако стоит заметить, что сертификат “Головного удостоверяющего центра” мы поставили в первой главе из RAR архива ООО “ИТК”, они идентичны. А сертификат с не очень говорящим названием “УЦ 1 ИС ГУЦ” поставил КриптоПро CSP, т.к. галочка об установке корневых сертификатов была установлена по-умолчанию в его инсталляторе. Единственным новым является сертификат АО “Тинькофф Банк”, который мы и ставим.

После установки сертификатов из “Цепочка корневых сертификатов УЦ АО Тинькофф Банк ГОСТ Р 34.10.2001” путь в сертификате прорисовался и система радостно сообщила, что он является доверенным. Adobe Acrobat Reader DC также подтвердил, что подпись действительна.

На этом приключения с проверкой ЭП на полисе еОСАГО завершаются. Заметно, что после того, как в системе уже установлен необходимый софт, а пользователь понимает принципы работы и поиска промежуточных сертификатов, то проверка подписи занимает уже меньше времени.

Но проблемные места по-прежнему видны: необходимо искать в интернете официальные сайты удостоверяющих центров, разбираться в инструкциях по установке сертификатов. Даже при установленных корневых сертификатах необходимо искать промежуточный, иначе цепочка доверия будет не полной и система не сможет подтвердить достоверность подписи.

Глава первая: проверка эп

Все манипуляции с PDF документом приведены в чистой версии ОС Windows 10, русская домашняя редакция, как наиболее вероятной среде работы простого пользователя. Набор софта, используемый в статье, также является непрофессиональным и доступным для всех.

Для начала я открыл документ в просмотрщике Foxit Reader, который использую как основной:


Это выглядит очень и очень подозрительно — документ модифицирован непонятно кем, сертификат также не является доверенным. Система не может проверить цепочку доверия для данного сертификата и помечает его недействительным.

Кроме имени организации, которой выдан сертификат, видно наименование выдавшей его организации, ООО “ИТК”. Поиск по запросу “ООО ИТК сертификат” вывел меня на страницу Установка корневого сертификата Удостоверяющего центра ООО «ИТК». Это официальный сайт ООО «Интернет Технологии и Коммуникации», который является одним из удостоверяющих центров, выдающих сертификаты ЭП.

Глава третья: немного про корневые и промежуточные сертификаты

Проделав всю эту работу, меня не покидало чувство, что вся система построена не очень безопасно, требует от пользователя кучу дополнительных операций и доверия многим факторам: от поисковой системы, которая может не выдать первой строкой официальный сайт УЦ, до работы самого персонала УЦ, который выкладывает сертификаты без контрольных сумм на сторонние веб сервисы в проприетарных форматах контейнеров.

Для чего нужна криптография

Система криптографической защиты должна обеспечивать:

Доступ к токену pkcs#11

Для доступа к токену и сертификатам, хранящимя на нем, воспользуемся пакетом

. Пакет распространяется как в бинарниках, так и в исходниках. Исходные коды пригодятся позднее, когда мы будем добавлять в пакет поддержку токенов с российской криптографией. Загрузить пакет TclPKCS11 можно двумя способами, либо командой tcl вида:

load  <библиотека tclpkcs11> Tclpkcs11


Либо загрузить просто как пакет pki::pkcs11, предварительно положив библиотеку tclpkcs11 и файл pkgIndex.tcl в удобный вам каталог (в нашем случае это подкаталог pkcs11 текущего каталога) и добавив его в путь auto_path:

#lappend auto_path [file dirname [info scrypt]] 
lappend auto_path pkcs11
package require pki
package require pki::pkcs11

Поскольку нас интересуют токены прежде всего с поддержкой российской криптографии, то из пакета TclPKCS11 мы будем задействовать следующие

Читайте также:  Квалифицированная электронная подпись под macOS / Хабр

::pki::pkcs11::loadmodule <filename>                       -> handle
::pki::pkcs11::unloadmodule <handle>                       -> true/false
::pki::pkcs11::listslots  <handle>                       -> list: slotId label flags
::pki::pkcs11::listcerts  <handle> <slotId>                -> list: keylist
::pki::pkcs11::login <handle> <slotId> <password>          -> true/false
::pki::pkcs11::logout <handle> <slotId>                    -> true/false

Сразу оговоримся, что функции login и logout здесь рассматриваться не будут. Это связано с тем, что в рамках этой статьи мы будем иметь дело только с сертификатами, а они являются публичными объектами токена. Для доступа к публичным объектам нет необходимости авторизовываться через PIN-код на токене.

Первая функция ::pki::pkcs11::loadmodule предназначена для загрузки библиотеки PKCS#11, которая поддерживает токен/смарткарту, на котором находятся сертификаты. Библиотека может быть получена либо при приобретении токена, либо загружена из Интернета или она была предустановлена на компьютере.

set filelib "/usr/local/lib64/librtpkcs11ecp_2.0.so"
set handle [::pki::pkcs11::loadmodule  $filelib]


Соответственно есть функция выгрузки загруженной библиотеки:

::pki::pkcs11::unloadmodule $handle

После того как была загружена библиотека и у нас есть ее handle можно получить список слотов, поддерживаемых этой библиотекой:

Использование иок в приложениях

ИОК используется для управления ключами и электронными сертификатами в приложениях (таких как электронная почта, Web приложения, электронная коммерция), использующих криптографию для установления защищенных сетевых соединений (S/MIME, SSL, IPSEC), или для формирования ЭЦП электронных документов, приложений и т.д. Кроме того, ИОК может быть использована для корпоративных приложений.

Как работают обычные токены?

Многие используют обычные токены, не особенно вдаваясь в детали их работы. Обычно на них размещают сертификаты электронной подписи, и впоследствии при необходимости что-то подписать, вставляют токен в компьютер и набирают выбранный пин-код. 

Преимущество таких токенов перед обычными флешками состоит в том, что сертификат на токене надежно защищен и без знания пин-кода получить к нему доступ практически невозможно. Это значит, что если вы потеряете такой токен, то ничего страшного в принципе не произойдет – злоумышленник не сможет ничего подписать, не зная пин-кода.

Как работают токены эцп/гост?

Токены с аппаратной реализацией электронной подписи, шифрования и хеширования обладают всеми преимуществами обычных токенов. Но самым важным преимуществом таких токенов является возможность подписывать и шифровать документы прямо на токене, не используя установленный на рабочей станции криптопровайдер. Это позволяет:

  • Безопасно подписывать и шифровать: ваша подпись(закрытый ключ) не покидают ваш токен
  • Подписывать и шифровать документы, не покупая криптопровайдер

Если первый пункт говорит о повышение безопасности процесса подписи (закрытый ключ не покидает токен, а значит его значительно сложнее перехватить), то второй пункт позволяет вам сэкономить

Если обычно для подписи требуется приобрести, к примеру Токен КриптоПро CSP КриптоАрм, то с такими токенами вам будет достаточно купить Токен ЭЦП/ГОСТ КриптоАрм

Что же такое pkcs#11?

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

Мы рекомендуем использовать программу КриптоАРМ Стандарт Плюс, которая с версии 5 поддерживает этот протокол. 

Компоненты иок и их функции

В состав компонент ИОК входят следующие компоненты:

Необходимость защиты информации

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

В настоящее время, например, средства электронной почты, используются не только для общения между людьми, а для передачи контрактов и конфиденциальной финансовой информации. Web сервера используются не только для рекламных целей, но и для распространения программного обеспечения и электронной коммерции.

Электронная почта, доступ к Web серверу, электронная коммерция, VPN требуют применения дополнительных средств для обеспечения конфиденциальности, аутентификации, контроля доступа, целостности и идентификации. В настоящее время в качестве таких средств повсеместно используются средства криптографической защиты и Инфраструктура Открытых Ключей (ИОК).

Пользователи

Пользователь, приложение или система, являющиеся Владельцами сертификата и использующие ИОК.

Проверка валидности сертификата по сос/crl

Первым шагом необходимо получить СОС, затем его распарсить и проверить по нему сертификат.

Читайте также:  Как создать и у всех на виду хранить пароли, очень стойкие и очень длинные, не запоминая их / Хабр

Список точек выдачи СОС/CRL находится в расширении сертификата с oid-ом 2.5.29.31 (id-ce-cRLDistributionPoints):

array set extcert $cert_parse(extensions)
 set ::crlfile ""
 if {[info exists extcert(2.5.29.31)]} {
	set ::crlfile [crlpoints [lindex $extcert(2.5.29.31) 1]]
}   else {
	puts "cannot load CRL" 
}


Собственно загрузка файла с СОС/CRL ведется следующим образом:

set filecrl ""
set pointcrl ""
foreach pointcrl $::crlfile {
	    set filecrl [readca $pointcrl $dir]
	    if {$filecrl != ""} {
		set f [file join $dir [file tail $pointcrl]]
		set fd [open $f w]
		chan configure $fd -translation binary
		puts -nonewline $fd $filecrl
		close $fd
		set filecrl $f
		break
	    } 
#Прочитать CRL не удалось. Берем следующую точку с CRL
}
if {$filecrl == ""} {
        puts "Cannot load CRL"
}

Собственно для загрузки СОС/CRL используется процедура readca:

Проверка срока действия сертификата

При разборе сертифмката в переменных ::notbefore и ::notafter хранится дата, с которой сертификат может использоваться в криптографических операциях (подписать, зашифровать и т.д.), и дата окончания срока действия сертификата. Процедура проверки срока действия сертификата имеет вид:

proc cert_valid_date {} {
    # Проверяем валидность сертификата по срокам действия
#Дата начала действия сертификата
    set startdate $::notbefore
#Дата окончания действия сертификата
    set enddate $::notafter
# Получаем текущее время в секундах
    set now [clock seconds]
    set isvalid 1
    set reason "Certificate is valid"
    if {$startdate > $now} {
        set isvalid 0
#Срок действия сертификата еще не наступил
        set reason "Certificate is not yet valid"
    } elseif {$now > $enddate} {
        set isvalid 0
 #Срок действия сертификата истек
     set reason "Certificate has expired"
    }
    return [list $isvalid $reason]
}

Возвращаемый список содержит два элемента. Первый элемент может содержать либо 0 (ноль) либо 1 (один). Значение «1» указывает на то, что сертификат действует, а 0 – на то, что сертификат не действует. Причина по которой не действует сертификат раскрывается во втором элементе. Этот элемент может содержать одно из трех значений:

  • certificate valid (первый элемент списка равен 1):
  • certificate is not yet valid (время действия сертификата еще не наступило)
  • certificate has expired (срок действия сертификата истек).

Валидность сертификата определяется не только периодом его действия. Действие сертификата может быть приостановлено или прекращено удостоверяющим центром, как по его инициативе, так и по заявлению владельца сертификата, например при утрате носителя с закрытым ключом.

В этом случае сертификат включается удостоверяющим центром в список отозванных сертификатов СОС/CRL, которые распространяются УЦ. Как правило, точка распространения CRL включается в сертификат. Именно по списку отозванных сертификатов и проверяется валидность сертификата.

Стандарты pkix

Спецификации PKIX основаны на двух группах стандартов: X.509 ITU-T (Международный комитет по телекоммуникациям) и PKCS (Public Key Cryptography Standards) firmy RSA Data Security. X.509 изначально был предназначен для спецификации аутентификации при использовании в составе сервиса X.

500 директории. Фактически же, синтаксис электронного сертификата, предложенный в X.509 признан стандартом де-факто и получил всеобщее распространение независимо от X.500. Однако X.509 ITU-T не был предназначен для полного определения ИОК. В целях применения стандартов X.

Стандарты в области иок

Стандарты в области ИОК делятся на две группы: часть из них описывает собственно реализацию ИОК, а вторая часть, которая относится к пользовательскому уровню, использует ИОК, не определяя ее. На приведенном рисунке показана связь приложений со стандартами. Стандартизация в области ИОК позволяет различным приложениям взаимодействовать между собой с использованием единой ИОК.

В особенности стандартизация важна в области:

Центр регистрации

Опциональная компонента ИОК, предназначенная для регистрации конечных пользователей. Основная задача ЦР – регистрация пользователей и обеспечение их взаимодействия с ЦС. В задачи ЦР может также входить публикация сертификатов и СОС в сетевом справочнике LDAP.

Центр сертификации

Центр Сертификации (или Удостоверяющий Центр) – основная управляющая компонента ИОК, предназначенная для формирования электронных сертификатов подчиненных Центров и конечных пользователей. Кроме сертификатов, ЦС формирует список отозванных сертификатов X.509 CRL (СОС) с регулярностью, определенной Регламентом системы.

К основным функция ЦС относятся:

Электронная почта и документооборот

Защищенные электронная почта и документооборот используют криптографию для шифрования сообщений или файлов и формирования ЭЦП. Из наиболее известных и распространенных стандартов стоит отметить протокол S/MIME (Secure Multipurpose Internet Mail Extensions), который является расширением стандарта Internet почты MIME (Multipurpose Internet Mail Extensions).

Эцп файлов и приложений

Использование ЭЦП для подписи приложений и файлов позволяет безопасно распространять их по сети Internet. При этом пользователь уверен в корректности полученного приложения от фирмы-разработчика.

Заключение

Криптография с открытыми ключами и электронные сертификаты позволяют реализовать по настоящему защищенные системы и приложения, использующие современные технологии и сети передачи данных. Стандартизация в данной области позволяет различным приложением взаимодействовать между собой, используя единую Инфраструктуру Открытых Ключей.

Оцените статью
ЭЦП Эксперт
Добавить комментарий

Adblock
detector