Openssl

О какой медали идет речь в заголовке? Речь идет об инфраструктуре открытых ключей (Public Key Infrastructure PKI/ИОК) на базе стандартов криптографии с открытым ключом (Public Key Cryptography Standards PKCS). Инфраструктура открытых ключей включает в себя множество различных объектов и механизмов работы с ними, а также протоколы взаимодействия объектов друг с другом (например, протоколы TLS, OCSP). В число объектов ИОК/PKI входят сертификаты x509 и ключевые пары (приватные и публичные ключи), подписанные и зашифрованные документы (pkcs#7, CMS). защищенные контейнеры для хранения приватных ключей (pkcs#8) и личных сертификатов с ключами (pkcs#12) и т.д. В число механизмов входят не только криптографические функции, которые позволяют шифровать и подписывать документы по различным алгоритмам, но и функции формирующие конечные объекты ИОК в соответствии со стандартами (сертификаты, запросы, подписанные/зашифрованные документы, пакеты протоколов и т.д. и т.п.). Да, и как не вспомнить центральный объект ИОК/PKI Удостоверяющий Центр (УЦ).
Рядовой пользователь интернет использует различные механизмы и объекты ИОК/PKI, не подозревая того, когда использует протокол HTTPS при доступе к различным сайтам, когда подписывает и/или шифрует свои электронные письма или использует электронную подпись в документообороте.
Наиболее продвинутыми средствами для создания инфраструктуры открытых ключей, программных средств, работающих в составе PKI/ИОК, являются OpenSSL и Network Security Services (NSS).
OpenSSL набор полноценных криптографических библиотек и утилиты с открытым исходным кодом, которые поддерживает почти все низкоуровневые алгоритмы хеширования, шифрования и электронной подписи, а также реализует большинство популярных криптографических стандартов, в том числе: позволяет создавать ключи RSA, DH, DSA, EC, выпускать сертификаты X.509, шифровать и подписывать данные и создавать SSL/TLS соединения.
Следует отметить, что объекты, с которыми работает утилита OpenSSL, хранятся в файлах (сертификаты, ключи).
Таким же набором полноценных криптографических библиотек и утилит с открытым исходным кодом является и Network Security Services (NSS).
Основное отличие OpenSSL от NSS заключается в том, что OpenSSL, предполагает, что сертификаты и ключи хранятся в файлах, а NSS для хранения сертификатов и ключей использует базы данных и токены PKCS#11.
Самым существенным является то, что оба проекта (OpenSSL и NSS) строго придерживаются стандартов и поэтому не возникает проблем при их совместном использовании в различных проектах. Таким хорошим примером их содружества может служить, например, применение протокола HTTPS, когда сайты/порталы строятся на базе Apache с mod_ssl на базе OpenSSL, а доступ к ним ведется, например, посредством Firefox, в котором поддержка TLS 1.0/TLS 1.2 и TLS 1.3 осуществляется с помощью библиотек NSS.
Ниже будет показано как утилиты OpenSSL и NSS могут использоваться для решения одних и тех же задач. В дальнейшем каждый может использовать утилиты по своему вкусу. Познакомиться с библиотечными функциями каждый может просмотрев исходный код той или иной утилиты.

Просмотр сертификатов и других сущностей, хранящихся в файлах

В пакете OpenSSL присутствует одна утилита openssl, первым параметром в которой задается собственно команда (Standard commands), которую необходимо выполнить:

Как можно заметить, при выполнении команды openssl help, помимо собственно перечня команд, выводится список поддерживаемых хэш-алгоритмов и алгоритмов шифрования (в их перечень включены и функции сжатия и работы с base64).
Для просмотра сертификата (x509), запроса (req) или списка отозванных сертификатов (crl) достаточно выполнить команду следующего вида:
openssl x509[|req|crl] [-nameopt utf8] -inform PEM|DER -noout -in <имя файла>.
Например, команда:

$openssl x509 -text -nameopt utf8 -inform PEM -noout -in cert.pem

отобразит на экране компьютера содержимое сертификата в техтовом виде (x509 -text), хранящегося в файле cert.pem ( -in cert.pem) в кодировке PEM (base64) (-inform PEM) и содержащего символы в кодировке utf-8 (-nameopt utf8). При этом сам сертификат в кодировке PEM на экран выводиться не будет (-noout).
В пакете NSS аналогичные действия выполняет утилита pp.
Утилита pp это утилита элегантной печати (Pretty Print) файла, содержащего ASN.1 структуру в DER или PEM-кодировки:

Usage:  pp [-t type] [-a] [-i input] [-o output] [-w] [-u],  

где type:

• с сертификат;
• cr запрос на сертификат;
• pk публичный ключ;
• pk файл с открытым ключом;
• crl списоk отозванных сертификатов.

Отметим еще один тип, который применяется к сертификатам, ci (certificate-identity). Этот тип позволяет получить из сертификата идентифицирующую его информацию, такую как subject (владелец), issuer (издатель), serial number (серийный номер), fingerprint (отпечатки по SHA-1 и SHA-256). Аналогичные параметры есть и в утилиты openssl для x509.
По умолчанию предполагается, что все объекты находятся в DER-кодировке. Если же объекты находятся в PEM-кодировке то необходимо задать параметр "-a" (аналог параметра "-inform PEM" для утилиты openssl). И еще один параметр "-u" задается, если в объекте содержатся символы в кодировке UTF-8. Напомним, что аналогичный параметр есть и у утилиты openssl "-nameopt utf8".

В пакете NSS есть и утилита для просмотра ASN.1-структыры объекта, аналог утилиты openssl asn1.parse. Это утилита derdump:

$derdump -i <просматриваемый файл> [-o <выходной файл>]

Из самого названия утилиты следует, что она работает с файлами в DER-кодировке. Но это не страшно. В состав пакета входит две утилиты, которые конвертируют файлы из PEM/BASE64-кодировки в DER-кодировку и обратно. Это утилиты atob и btoa.
Например, для конвертации сертификата из PEM-формата в DER-формат, в OpenSSL надо выполнить следующую команду:

$openssl x509 -inform der -in CERT.der -out CERT.pem 

В NSS это будет выглядеть так:

$btoa -in CERT.der -out CERT.pem -w "CERTIFICATE"

Параметр "-w" указывает какой текст включить в начало выходного файла и конец. В данном случае "-w CERTIFICATE" приведет к появлению стандартного для PEM-формата в OpenSSL заголовка и концевика:

-----BEGIN CERTIFICATE-----<тело сертификата в кодировке BASE64>-----END CERTIFICATE----- 

И OpenSSL и NSS могут работать с контейнерами pkcs#12. И они оба позволяют не толькл создавать, но и просмотреть содержимое контейнера pkcs12. Но, при использовании утилиты openssl, требуется сначала разобрать контейнер и сохранить сертификаты из контейнера в отдельных файлах. После этого их можно спокойно просмотреть. В NSS просмотр содержимого контейнера можно выполнить за один проход. Для этого используется утилиты pk12util следующего вида:

pk12util -l <файл с контейнером pkcs12> [-W <пароль к контейнеру pkcs12>] [-d <каталог хранилища NSS>] [-h <токен>]

Например:

Утилита удобная, но без ложки дегтя не обошлось. Ложка дегтя состоит в том, что русские буквы, вернее, UTF-8 кодировка отображается в виде точек (.....). И если у утилиты pp есть параметр -u (присутствует кодировка utf-8), то здесь про нее забыли (мы еще раз сталкнемся с этим при рассмотрении утилиты certutil). Исправить это не составляет труда: достаточно в функцию P12U_ListPKCS12File, находящуюся в файла pk12util.c, добавить одну строку:

PRIntnP12U_ListPKCS12File(char *in_file, PK11SlotInfo *slot,                    secuPWData *slotPw, secuPWData *p12FilePw){    SEC_PKCS12DecoderContext *p12dcx = NULL;    SECItem uniPwitem = { 0 };    SECStatus rv = SECFailure;    const SEC_PKCS12DecoderItem *dip;/*Вызов функции для отображения UTF-8*/    SECU_EnableUtf8Display(PR_TRUE);.   .   .   .   .}

Говоря о создании контейнера PKCS#12 утилитой openssl, то мы воспользовались графической оболочной CAFL63:



Теперь самое время поговорить о хранилище NSS.

Хранилище NSS

Хранилищем NSS является каталог, в котором хранится три базы данных.
В базе данных (БД) cert8.db/cert9.db хранятся сертификаты. В БД key3.db/key4.db хранятся закрытые ключи. И, наконец, в БД secmod.db/pkcs11.txt хранится информация (прежде всего путь к библиотеки), позволяющая работать со сторонними токенами/смарткартами/облаками с интерфейсом PKCS#11.
Для создания хранилища NSS предназначена утилита modutil следующего формата:

modutil -create -force [-dbdir <хранилище NSS>] , где<хранилище NSS> := [<тип базы данных>:]<каталог хранилища NSS><тип базы данных> := dbm|sql , например:$modutil -create -force -dbdir "sql:/~/TEST_NSS"

Тип базы данных dbm предполагает создание баз данных Berkeley (cert8.db, key3.db и secmod.db). Тип sql предполагает создание баз данных SQLite3 (cert9.db, key9.db и текстовый файл pkcs11.txt). По умолчанию создаются базы данных SQLite3. Каталог хранилища NSS должен быть создан заранее. По умолчанию (если не задан параметр -dbdir или -d) используется хранилище ".netscape" в домашней папке пользователя. Именно это хранилище использует, например, броузер google-chrome.
Также просто из хранилища сертификатов старого формата (DBM) (cert8.db, key3.db и secmod.db) создается и хранилище в новом формате (SQLite3) (cert9.db, key4.db и pkcs11.txt). Для этого достаточно выполнить утилиту работы с сертификатами certutil в режиме просмотра ключей (-K) или сертификатов (-L) с параметром X, например:

$certutil -K -X -d ~/TEST_NSS

или

$certutil -L -X -d ~/TEST_NSS

Отметим, что такие хранилища есть во всех проектах, построенных на NSS, включая Firefox, Thunderbird, Seamonkey, GoogleChrome, LibreOffice.
После создания хранилиша NSS автоматически становится доступным встроенный модуль NSS Internal PKCS #11 Module с двумя встроенными токенами:

$modutil -list -dbdir ~/TEST_NSSListing of PKCS #11 Modules-----------------------------------------------------------  1. NSS Internal PKCS #11 Module           uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.52         slots: 2 slots attached        status: loaded         slot: NSS Internal Cryptographic Services        token: NSS Generic Crypto Services          uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203         slot: NSS User Private Key and Certificate Services        token: NSS Certificate DB          uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203-----------------------------------------------------------$

Токен NSS Generic Crypto Services реализует криптографические функции и механизмы, а токен NSS Certificate DB предназначен для хранения сертификатов и ключей и другой дополнительной информации (например, о доверии корневым сертификатам). Токен NSS Certificate DB (внутренний токен NSS) для хранения сертификатов использует базу данных cert8.db/cert9.db, а закрытые ключи хранит в базе данных key3.db/key4.db.
Получить информацию о встроенных токенах внутреннего модуля NSS Internal PKCS #11 Module, включая поддерживаемые по умолчанию криптографические механизмы, можно путем выполнения следующей команды:

Подключение дополнительного модуля для работы с внешними устройствами PKCS#11 делается все той же утилитой modutil:

$modutil -add <имя модуля> -libfile <путь к библиотеке> [-dbdir <хранилище NSS>]

Например, для работы с токенами РУТокен, поддерживающими российскую криптографии, достаточно выполнить следующую команду:

$modutil -add "ruTokenECP" -libfile /usr/lib64/librtpkcs11ecp_2.0.so -dbdir $HOME/.netscape 

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

$modutil -list [-dbdir <хранилище NSS>]

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

$modutil -list <имя модуля> [-dbdir <хранилище NSS>]

Мы ее уже прльзовались, когда получали информацию о встроенных (внутренних) токенах NSS.
И, если можно добавить модуль, то можно и удалить модуль из базы данных:

$modutil -delete <имя модуля> [-dbdir <хранилище NSS>] 

Доступ к внешним токенам, как правило, защищен PIN-кодом. А вот доступ к встроенному токену NSS Certificate DB по умолчанию не защищен паролем (PIN-кодом). Но установить не составляет труда, например:

$modutil -dbdir $HOME/.netscape -changepw "NSS Certificate DB"  

Аналогичным образом можно поменять PIN-код и у внешнего токена.
Теперь самое время перейти к работе с токенами, его мехамизмами и объектами.

Доступ к объектам токена PKCS#11

Для доступа к объектам (ключи, сертификаты) токенов PKCS#11 служит утилита certutil. Отметим, что своей функциональности утилита certutil не уступает утилите openssl. Для просмотра функциональности утилиты certutil достаточно выполнить команду:

$certutil -H

Но нас сейчас интересует только доступ с сертификатам и ключам. Напомним, что при хранении на токене PKCS#11 и тем и другим, как правило, приписываются атрибуты CKA_ID и CKA_LABEL. Для просмотра списка сертификатов на том или ином токене необходимо выполнить следующую команду:

$certutil -L [-d <хранилище NSS>] [-h <метка токена>]

В качестве метки токена может быть указана реальная метка токена, или одно из ключевых слов all или internal. В первом случае (метка токена all) перебираются все токены, подключенные к хранилищу NSS, а во втором случае (internal или NSS Certificate DB) будет просматриваться внутренний токен хранилища NSS Certificate DB.
Например, для получения списка сертификатов, находящихся на токене с меткой LS11SW2016, модуль доступа к которому зареегистрирован в хранилище NSS "/home/a513/tmp/TEST_NSS" необходимо выполнить следующую команду:

$ certutil -L -d /home/a513/tmp/TEST_NSS -h "LS11SW2016"Enter Password or Pin for "LS11SW2016":Certificate Nickname                                  Trust Attributes                                                      SSL,S/MIME,JAR/XPILS11SW2016:TestCA_P11                                 u,u,uLS11SW2016:clientnss from CryptoArmPKCS               u,u,uLS11SW2016:ТестШифр                                   u,u,uLS11SW2016:Thenderbird-60.3.0 from 32                 u,u,uLS11SW2016:Всесильный Хабр from УЦ 12_512             u,u,uLS11SW2016:Text4Key                                   u,u,uLS11SW2016:KmailKleopatra от GnuPG-2001               u,u,uLS11SW2016:setvernss from CryptoArmPKCS               u,u,uLS11SW2016:Ф И О from УЦ 12_512                       u,u,uLS11SW2016:Test 12 512                                u,u,uLS11SW2016:Kleopatra от GnuPG-2001                    ,,   $

Список сертификатов, находящихся на токене, выводится в две колонки. В первой колонке дается nicknamе сертификата, а во второй атрибуты доверия этого сертификата.
При чем, если сертификат имеет закрытый ключ на токене, где он находится, то в этой колонке
будет значение u,u,u.
Если атрибуты не устанавливались, то в колонке будет значение ",,".
Сертификаты с аттрибутами доверия u,u,u (у них есть закрытый ключ) могут быть использованы для аутентификации или формирования электронной подписи.
Другие значения атрибутов доверия могут быть установлены для сертификатов, находящихся на встроенном токене. NSS Certificate DB. Но об этом позже.
Что же такое nickname сертификата в NSS?

<nickname> := [<метка токена>:]<CKA_LABEL>

Для внутреннего токена (NSS Certificate DB) метка токена в nickname может отсутствовать.
Если рассматривать мехамизмы токенов PKCS#11, то мы увидим, что операции генерации ключей, импорта сертификатов и ключей сами по себе не предусматривают установку значений аттрибутов CKA_ID и CKA_LABEL. Это все перекладывается на разработчика прикладного ПО. Но, если вы используете, утилиты NSS для работы с токенами, то оказывается, что они берут на себя эти хлопоты.
Для просмотра списка закрытых ключей используется следующая команда:

$certutil -K [-d <хранилиже NSS>] [-h <метка токена>]

При этом распечатывается тип ключа, CKA_ID и CKA_LABEL ключа.
Но вернемся к сертификатам. Для просмотра сертификата, находящегося на токене, в текстовом виде достаточно выполнить команду:

$certutil -L [-d <хранилище NSS>] -n <nickname сертификата>

Например:

Если у просматриваемого сертификата на этом же токене имеется закрытый ключ, то флаги доверия сертификата (Certificate Trust Flags) будут иметь значение User:

Certificate Trust Flags:
SSL Flags:
User
Email Flags:
User
Object Signing Flags:
User

Для экспорта сертификата с токена в стандартный вывод достаточно добавить дополнительный параметр "-a" или "-r". Параметр "-a" предписывает выводить сертификат в формате PEM:

Для вывода в DER-формате используется параметр "-r".

Установить сертификат на токен

Предположим у вас есть контейнер PKCS#12 с личным сертификатом и закрытым ключои, который вы сформировали средствами OpenSSL. Для экспорта личного сертификата в хранилище NSS используется команда pk12util следующего вида:

$pk12util -i <контейнер pkcs12> [-d <хранилище NSS>] [-h <метка токена>]

Если вы хотите импортировать сертификат на конкретный токен, то необходимо задать его метку. Отметим еще одну особенность. Если контейнер содержит в своем составе корневые сертификаты, то они будут сохранены на внутреннем токене NSS Certificate DB. При этом атрибуты доверия по умолчанию не устанавливаются. Если по каким либо причинам требуется установка атрибутов доверия к тем или иным сертификатам центров регистрации (корневым сертификатам) или SSL-сертификатам Для установки аттрибутов доверия используется утилита certutil следующего вида:

$certutil -M -n <nickname-сертификата> -t <аттрибуты доверия> [-d <хранилище NSS>]

Для каждого сертификата есть три доступные категории доверия, выраженные в следующем порядке: SSL, S/MIME, подпись кода для каждого параметра доверия:

<аттрибуты доверия> := x,y,z , где

• x аттрибуты для SSL,
• y атрибуты для S/MIME,
• z атрибуты для подписи кода.

Каждая позиция x, y и z может быть пустой (используйте ,, без явного доверия) или содержать один или несколько атрибутов:

• p Действительный узел (Valid peer);
• P доверенный узел (подразумевается и p)
• c Действительный сертификат центра регистриции (Valid CA)
• T доверенный CA для выдачи клиентских сертификатов (подразумевается и c)
• C Доверенный CA для выдачи сертификатов сервера (только SSL) (подразумевается c)

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

$certutil -A -n <метка сертификата> -t <аттрибуты доверия> [-d <хранилище NSS>] [-h <метка токена>] [-a] [-i <файл с сертификатом>]

К сожалению, в данном контексте <метка сертификата> не эквивалентна nickname сертификата, рассмотренному выше. Здесь метка сертификата соответствует просто CKA_LABEL, просто метки без указания метки токена. Какой-то разнобой.
По умолчанию предполагается, что сертификат находится в файле в DER-кодировке. Если сертификат в PEM-кодировке, то необходимо задавать параметр "-a". Параметр "-i" не задан, то сертификат будет браться из стандартного ввода (stdin). По умолчанию сертификаты устанавливаются в токен NSS Certificate DB, но можно установить сертификат и на внешний токен (параметр "-h"). При установке сертификата на внешний токен, сертификат будет установлен как на внутренний токен (NSS Certificate DB), так и внешний токен. При этом аттрибуты довермя для внешнего токена будут проигнорированы, будет выдано предупреждение: could not change trust on certificate.
Дубликат сертификата на внутреннем токене при желании можно удалить.
Для удаления сертификата с любого токена используется следующая команда:

$certutil -D [-d <хранилище NSS>] -n <nickname-сертификата>

Например, для удаления с токена RuTokenECP20 сертификата с меткой (CKA_LABEL) Пользователь1 достаточно выполнить следующую команду:

$certutil -D -d /home/a513/tmp/TEST_NSS -n "RuTokenECP20:Пользователь1"

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

$certutil -F [-k <тип ключа>] [-d <хранилище NSS>] -n <nickname-сертификата>, где<тип ключа> := rsa|dsa|ec

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

Формирование и проверка электронной подписи

Для работы с электронной подписью в пакете NSS есть три утилиты.
Для формирования электронной подписи используется утилита p7sign:

$pksign -k <nickname закрытого ключа> [-d <хранилище NSS>] [-e] [-i <подписываемый файл >] [-o <файл для электронной подписи>], где<nickname закрытого ключа> := [<метка токена>:]<CKA_LABEL>

К сожалению, утилита формирует подпись без привязки ко времени ее формирования. Но это легко исправляется. Достаточно в функцию SignFile в утилите p7sign.c добавть струку с вызовом функции добавления времени формирования подписи:

SignFile(FILE *outFile, PRFileDesc *inFile, CERTCertificate *cert,         PRBool encapsulated){  . . .     /* XXX Need a better way to handle that usage stuff! */    cinfo = SEC_PKCS7CreateSignedData(cert, certUsageEmailSigner, NULL,                                      SEC_OID_SHA1,                                      encapsulated ? NULL : &digest,                                      NULL, NULL);    if (cinfo == NULL)        return -1;/*Добавляем время формирования подписи*/    SEC_PKCS7AddSigningTime(cinfo);    if (encapsulated) {        SEC_PKCS7SetContent(cinfo, (char *)data2sign.data, data2sign.len);    } . . . }

Теперь будет формироваться электронная подпись в формате CAdes-BES.
В NSS принято, что сертификат и его закрытый ключ хранятся на одном токене и их метки (CKA_LABEL), также как и CKA_ID, совпадают. Соответственно совпадают и nickname закрытого ключа и nickname самого сертификата. Напомним, что о наличии закрытого ключа у сертификата можно узнать по значению u,u,u атрибутов доверия у просматриваемого сертификата (команда certutil -L).
По умолчанию утилита p7sign формирует отсоединенную подпись. Если нужна присоединенная подпись, то необходимо указать параметр "-e". Надо иметь ввиду, что подпись не будет сформирована, если в хранилище NSS, на его внутреннем токене, отсутствует цепочка корневых сертификатов для сертификата подписанта или не выставлены атрибуты доверия для них.
Для проверки электронной подписи используется утилита p7verify:

$p7verify -c <подписанный файл> -s <файл с ЭП> [-d <хранилище NSS>] [-u <использование сертификата>] 

Интерес представляет параметр "-u". Он предписывает проверить тип сертификата подписанта и если он не соответствует заданному типу, то подпись признать недействительной.
Значение <использование сертификата> может принимать следующие значения:

0 certUsageSSLClient
1 certUsageSSLServer
2 certUsageSSLServerWithStepUp
3 certUsageSSLCA
4 certUsageEmailSigner
5 certUsageEmailRecipient
6 certUsageObjectSigner
7 certUsageUserCertImport
8 certUsageVerifyCA
9 certUsageProtectedObjectSigner
10 certUsageStatusResponder
11 certUsageAnyCA
12 certUsageIPsec

По умолчанию, используется certUsageEmailSigner (4).
Утилита p7content позволяет получить информацию о времени подписания документа, кем он был подписан и адрес электронной почты подписата. В случае, если подпись была присоединенной, то и извлекается и сам контент, который был подписан.
Утилита p7content имеет следующий формат:

$p7content [-d <хранилище NSS>] [-i <файл с ЭП>] [-o <выходной файл>]

Например:

$ p7content -d "sql:/home/a513/tmp/TEST_NSS" -i "/home/a513/DATE_NSS.txt.p7s"Content printed between bars (newline added before second bar):#Подписанный контент находится между двумя строками, состоящими из символа "-" (тире)#Перед второй строкой добавлен перевод строки---------------------------------------------Тестирование пакета NSS---------------------------------------------Content was not encrypted.Signature is valid.The signer's common name is Пользователь 1The signer's email address is user1@mail.ruSigning time: Fri Jul 17 10:00:45 2020There were certs or crls included.$

Это только часть утилит, входящих в состав пакета NSS. Естественно, как и в openssl, так есть утилиты (или команды), которые позволяют создать запросы на сертификаты и выпускать сертификаты, т.е. можно развернуть полнофункциональный удостоверящий центр, как это делается с использованием openssl. Можно поднять tls-сервер утилитой selfserv(аналог openssl s_server) и воспользоваться tls-клиентом tstclnt (аналог openssl s-client) и многое, многое другое.
Кстати, список шифрсьютов (ciphersuite) в NSS можно получить утилитой listsuites. В OpenSSL для этих целей служит команда openssl ciphers. Соответствие имен набора шифров OpenSSL в имена IANA шифрсьютов можно найти здесь.
Действительно, openssl и NSS две стороны (два типа интерфейсов для одних и тех же протоколов и стандартов) одной медали Инфраструктуры Открытых ключей.
И, если будут востребованность, повествование будет продолжено.
В завершении, хотелось бы еще остановиться на графической оболочке для NSS. Для OpenSSL существуют различные графические оболочки. Отметим только две из них XCA и CAFL63.

Графическая оболочка guinsspy для пакета NSS

Первых вопрос, на чем разрабатывать? Было решено на Python-е.
Второй вопрос, на чем писать графический интерфейс? Ответ Tkinter.
Первоначально gui разрабатывалось на PAGE. Но потом от него отошли. Но контекст остался.
Функционал утилиты базируется на рассмотренных выше утилитах и командах. Помимо них была добавлена еще одна функция Создать запрос на сертификат, которая базируется на команде certutil -R:



В качестве темы оформления виджетов решено было использовать тему Breeze для python3 и тему Arc для python2, поскольку для последнего отсутствует тема Breeze. Для этого надо установить пакет с темами для pythona:

$pip install ttkthemes

Еще нам потребуется пакет fsb795 для работы с сертификатами:

$pip install fsb795

Утилиты NSS, на базе которых строится графическая оболочка guinsspy, очень часто запрашавают пароли или PIN-оды через консоль. Единственным способом взаимодействия с ними через графический интерфейс является использование пакета pexpect:

$pip install pexpect

В качестве примере использования пакета pexpect приведем код процедуры импорта контейнера PKCS#12:

Бесконечный цикл (while(True):) в процедуре ждет наступления одного из четырех событий:

ret = id.expect(["Enter Password or Pin", "Enter password for PKCS12 file",pexpect.EOF, pexpect.TIMEOUT])

Первое событие связано с приглашением на ввод пароля или PIN-кода (Enter Password or Pin).
При его наступлении на экране будет отбражаться окно для ввода PIN-кода(левое окно на скриншоте):



Второе событие связано с вводом пароля к контейнеру PKCS#12 (Enter password for PKCS12 file). При его наступлении на экране будет отбражаться окно для ввода пароля к файлу с контейнером PKCS#12 (правое окно на скриншоте).
Третье событие связано с завершением работы утилиты pk12util (pexpect.EOF), и четвертое событие связано с завершением работы утилиты по таймауту (pexpect.TIMEOUT).
Исходный код утилиты guinsspy можно найти здесь. Дистрибутив пакета NSS для работы с токена PKCS#11 с российской криптографией для платформы Linux x86_64 можно найти там же.
Для тестирования токенов с российской криптографией скопируйте папку NSS_GOST_3.52.1_Linux_x86_64 в свой домашний каталог. Создайте скрипт guinsspy_gost.sh:

export LD_LIBRARY_PATH=~/NSS_GOST_3.52.1_Linux_x86_64:$LD_LIBRARY_PATHexport PATH=~/NSS_GOST_3.52.1_Linux_x86_64:$PATHpython3 guinsspy.py

Теперь запустите этот скрипт и работайте с российскими токенами, например, с облачным токеном.

И напоследок, скриншоты создания запроса на сертификат:



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

Disclaimer. Я не настоящий сварщик, но, в связи с поиском интересной работы в сфере информационной безопасности, в последнее время регулярно решаю разные CTF и машинки на HackTheBox. Поэтому, когда мне прислали ссылку на одно из тестовых заданий в стиле CTF, я не смог пройти мимо



Смысл тестового задания достаточно простой. Дан дамп трафика, в котором спрятан ключ шифрования, некий мусор и зашифрованный флаг. Нужно их извлечь и расшифровать флаг. Также приведена команда OpenSSL, с помощью которой был зашифрован данный флаг. Трафик достаточно интересный, но уже через 10 строк кода на питоне передо мной лежал ключ шифрования, мусор и зашифрованный флаг. Казалось бы, что может пойти не так?

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

echo "FLAG_xxxxxxxxxx" | openssl enc -e -base64 -aes-256-cbc -nosalt -k $password 

Я вставил полученные из трафика параметры в команду, запустил и получил мусор! Попробовал еще раз. Снова мусор. Попробовал пересобрать трафик разными способами. Нет, судя по всему, трафик собрать можно только однозначно. Но на выходе шифрования снова мусор!!! При этом OpenSSL честно предупреждает, что получать так ключ из пароля в 1 проход плохая идея

echo "ENCRYPTED_FLAG" | openssl enc -d -base64 -aes-256-cbc -nosalt -k $key *** WARNING : deprecated key derivation used.Using -iter or -pbkdf2 would be better.

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

Как мы знаем, для работы AES нужен ключ шифрования и IV (вектор инициализации). Параметр -k дает нам возможность использовать текстовую фразу, из которой уже сам OpenSSL получает нужный ключ и IV. Увидеть их можно с помощью параметра -p.

echo "FLAG_123" | openssl enc -e -base64 -aes-256-cbc -nosalt -p -k "password"*** WARNING : deprecated key derivation used.Using -iter or -pbkdf2 would be better.key=5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8iv =3B02902846FFD32E92FF168B3F5D16B0C11kA+GcqkU4ocOvZAVr3g==

Это знание тоже ничего мне не дало. Тогда я всё же решил вернуться к самой безумной идее, которая возникала у меня. А именно: проблема не во мне, а что-то поменялось в OpenSSL
Трафик датировался 2016 годом, поэтому я взял Ubuntu 14.04 и, без особой надежды на успех, просто вставил в неё первоначальные данные. И внезапно вместо мусора получил ФЛАГ! Вечер переставал быть томным Более того, одна и та же команда с тем же паролем и параметром -p выдавала совершенно разные ключи шифрования и IV!

НОВАЯ СИСТЕМА (openssl 1.1.1h)

echo "FLAG_123" | openssl enc -e -base64 -aes-256-cbc -nosalt -p -k "password"*** WARNING : deprecated key derivation used.Using -iter or -pbkdf2 would be better.key=5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8iv =3B02902846FFD32E92FF168B3F5D16B0C11kA+GcqkU4ocOvZAVr3g==

СТАРАЯ СИСТЕМА (openssl 1.0.1f)

echo "FLAG_123" | openssl enc -e -base64 -aes-256-cbc -nosalt -p -k "password"key=5F4DCC3B5AA765D61D8327DEB882CF992B95990A9151374ABD8FF8C5A7A0FE08iv =B7B4372CDFBCB3D16A2631B59B509E94R3N+5v3zOz9QcNt08cwqcA==

Стало понятно, что опасения подтвердились. Изменился алгоритм генерации Key и IV из парольной фразы, что полностью сломало возможность в лоб решить CTF на современных версиях OpenSSL. В процессе поиска нюансов реализации я наткнулся на очень интересную работу Password-based OpenSSL Encryption Analysis of Key Derivation Protocol и всё стало на свои места. Вкратце, в версии 1.1.0 был добавлен новый протокол генерации ключей из пароля PBKDF2, но, что более важно в старом алгоритме PBKDF1 изменен алгоритм хеширования по умолчанию с MD5 на SHA-256! Таким образом, один и тот же пароль выдает разные Key и IV. Для того, чтобы расшифровать зашифрованное ранее, в новых версиях нужно использовать параметр -md md5

-md messagedigest: specify the message digest used for key derivation from md2, md5, sha, or sha1

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

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

В начале 2019 года мы провели ребрендинг и поменяли название с RealtimeBoard на Miro. Следовательно, изменился домен сайта с realtimeboard.com на miro.com.

При смене домена пользователям пришлось бы выполнять авторизацию на новом домене, потерялись бы локальные настройки приложения, пользователи SSO не могли бы авторизоваться без дополнительных настроек со своей стороны всё это было не User friendly, возросла бы частота восстановления паролей, а часть пользователей вообще не смогли бы воспользоваться приложением сразу же.

Чтобы минимизировать потерю трафика после смены домена, нужно было провести миграцию авторизованных пользователей со старого домена на новый:

• Поддержать пользователей, которые выполняли авторизацию с помощью SSO провайдеров через старый домен.
• Передать токен авторизации пользователя со старого домена на новый.
• Передать LocalStorage с пользовательскими настройками приложения.

Передача данных и шифрование

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

Однако полученный хэш всё равно можно было перехватить и использовать снова. Для того, чтобы токен нельзя было переиспользовать, мы добавили параметр дата шифрования, тем самым хэш был действителен в течении 10 секунд этого времени хватало с запасом для выполнения всех операций. Также мы добавили замену ключа шифрования раз в 12 часов, ключ хранился в Vault и был синхронизирован между сайтами.

Получившийся хэш передавался в виде get-параметра и был дополнительно обработан с помощью url_encode для безопасной передачи через URL, так как символы могли экранироваться или испортить структуру адреса.

Структура хэша:

url_encode(OpenSSL({  'token': 'токен',  'date': 'Дата шифрования',  'additional_values': ['param', 'param']}))

LocalStorage доступен только через JavaScript. Для решения этой задачи был выбран интерфейс postMessage и iframe, что позволяло безопасно отправлять кроссдоменные запросы. Данные в LocalStorage были сконвертированы в строки с помощью JSON.stringify() и переданы на домен miro.com, где они конвертировались обратно и записывались в LocalStorage домена miro.com.

Схема работы с описанием всех шагов

Схема в удобном для просмотра виде.

Пользователи могли попасть в сервис двумя путями: через старый домен realtimeboard.com (например, из закладок) или через новый miro.com (например, через рекламу).

Если пользователь заходил на старый домен:

1. После открытия любой страницы realtimeboard.com выполняется шифрование токена пользователя, даты создания и дополнительной служебной информации.
2. После шифрования происходит редирект на miro.com/migration/?data={hash} с передачей hash как Get параметр. Сам токен и служебная информация удаляются на старом домене, т.к они больше были не нужны.
3. На новом домене miro.com выполняется расшифровка хэша, проверка на то, что он не просрочен, и установка токена пользователя, если он был передан.
4. Проставляется флаг migrationToken, чтобы не выполнять миграцию снова.
5. Для миграции LocalStorage мы проверяли наличие куки migrationLocalstorage. Если куки не существовало, выполнялся рендеринг страницы с JS-скриптом, который открывал в iFrame страницу relatimeboard.com/localstorage/ и принимал сообщения от неё с помощью postmessage После окончания миграции пользователя редиректило на страницу, которую он пытался открыть первый раз.

Если пользователь заходил сразу на новый домен miro.com, выполнялась проверка на прохождение пользователем миграции токена и LocalStorage. Если пользователь уже выполнил миграцию, то он оставался на домене miro.com. Если не выполнил происходил редирект на realtimeboard.com для получения токена (для этого мы хранили в куках два флага: migrationToken и migrationLocalstorage).

Эта схема так же хорошо работала для пользователей с SSO, которые выполнили авторизацию на старом домене realtimeboard.com. Был добавлен список маршрутов, которые работали без миграции токена на новый домен. В них входил маршрут для SSO, который выполнялся как обычно и выполнял редирект на /app/ или /login/ в зависимости от состояния своей работы, после чего снова подключался механизм миграции токена.

Вывод

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