Что такое Закрытый Ключ, Открытый Ключ, Запрос На Сертификацию, Сертификат Открытого Ключа

2019-12-19

Кое в чём я несколько плаваю, поэтому пытаюсь разобраться.

Для понимания отношений между этими четырьмя сущностями, я составил краткий список:
1. Закрытый Ключ мы генерируем сами и для его безопасного хранения соблюдаем максимальную секретность.
2. С помощью выбранного криптографического алгоритма, используя наш Закрытый Ключ, мы генерируем соответствующий ему Открытый Ключ, для хранения которого секретность не требуется.
3. Используя наш Открытый Ключ, мы можем сформировать Запрос На Сертификацию, направив его в какую-либо Организацию, доступ к Информационной Системе которой нам требуется.
4. В ответ на наш Запрос, Организация подпишет своим Закрытым Ключом наш Открытый Ключ и оформит результат этой процедуры в виде Сертификата Открытого Ключа, где укажет сроки действия выданного Сертификата, области его применения и прочее. Получив Сертификат Открытого Ключа мы можем предъявлять его на входе в Информационную Систему организации, выдавшей нам Сертификат.

Закрытый Ключ (Private Key, Приватный Ключ)

Предназначение Закрытого Ключа

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

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

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

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

Где хранится Закрытый Ключ

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

Закрытый Ключ изнутри

В простейшем случае можно сказать, что для генерации ключа длиной 256 бит можно набрать на клавиатуре 32 символа (по 8 бит на символ) в "блокноте" и записать их в файл. Правда, в этом случае нельзя говорить об уникальности ключа, а в криптографии важна именно уникальность последовательности битов. То есть качество генерации ключа стоит на первом месте и с помощью набора символов на клавиатуре нельзя добиться качественной уникальности ключа. Если я правильно понимаю, то источником идеального случайного сигнала может служить сама природа. Например Реликтовое излучение, отголоски которого мы могли раньше наблюдать в виде ряби на экранах наших советских телевизоров в моменты отсутвия передач (но это неточно), является таким идеальным источником случайной информации.

На данный момент в компьютеры не встраиваются радиоприёмники для приёма реликтового изучения, но в Linux имеется специальное устройство /dev/urandom, которое собирает тепловой шум из драйверов устройств?. Этот дивайс постоянно выдаёт псевдослучайную последовательность бит, которую побайтно можно записать в файл.

Например, возьмём из /dev/urandom 256 бит (32 байта) случайной информации, сохраним полученное в файл privkey.bin и попытаемся вывести её в сыром виде командой cat:

$ head -c 32 /dev/urandom > ~/privkey.bin
$ cat ~/privkey.bin
�
�9%}Q�o��G'�݆H�Z<�1"V.�

Вывод бинарного файла на экран или принтер будет иметь различный вид на разных системах из-за наличия некоторых 8-битных последовательностей представленных непечатаемыми символами. Поэтому бинарный файл предпочтительней смотреть в, например, шестнадцатиричном виде:

$ hexdump privkey.bin
0000000 0cf0 b70d 2539 517d 16d1 046f b17f 47f2
0000010 2713 dd8b 1686 df48 3c5a 319e 5622 c82e

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

Открытый Ключ (Public Key, Публичный Ключ)

Предназначение Открытого Ключа

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

Открытый Ключ всегда может быть извлечён из Закрытого Ключа. Нельзя сгенерировать Закрытый Ключ из Открытого Ключа.

Где хранится Открытый Ключ

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

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

Стоп. При использовании ssh-ключей без PKI, Открытый Ключ не сертифицируется и хранится в виде записи-строчки, типа ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMk7KDxgW0rEQzoTvnAkiiq7cvXCLyxhzPnZMdNYKMBj [email protected], среди прочих записей в файлах authorized_keys на одном или множестве хостов. А также его можно найти в виде отдельного файла .pub в каталоге ~/.ssh, видимо для удобства передачи на другие системы, без траты времени на повторные его вычисления из Закрытого Ключа.

Форматы хранения бинарных ключей

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

$ head -c 32 /dev/urandom > ~/privkey.bin
$ cat ~/privkey.bin
�
�9%}Q�o��G'�݆H�Z<�1"V.�

По этой причине, одним из способов посмотреть реальное содержимое бинарного файла является просмотр шестнадцатиричного представления этого файла:

$ hexdump key.bin
0000000 0cf0 b70d 2539 517d 16d1 046f b17f 47f2
0000010 2713 dd8b 1686 df48 3c5a 319e 5622 c82e

Для удобства манипуляции бинарной информации, например для встраивания её в текстовый файл, удобно пользоваться различными видами кодирования. Например, BASE32- или BASE64-кодирование, преобразует последовательность бинарных данных в читаемую строку. При кодировке используются 32 символа (A-Z,2-7,=) или 64 символа (a-z,A-Z,0-9,+/) из таблицы печатных знаков ASCII:

$ cat ~/key.bin |base32
RCQJFMBQ4YG6GPIMVEJMVRDBHWQF6I2FIGNHQ5J2GXBZE2TRMUISHIDBEIMQCPFMOKFBWVS3VGF2
YQL7UH7FSBRT4E3YA43XBRXVJBUP6FCS7GLUKAV7R7GUATANLZPPXSZ7OM662LGTY3GLPBRX4B2T
XJB47WCFQRLC5PE7AAOHPBHD5WPBH34UAVWZOJ4GUYE4YUROD2AWS===

$ cat ~/key.bin |base64
iKCSsDDmDeM9DKkSysRhPaBfI0VBmnh1OjXDkmpxZREjoGEiGQE8rHKKG1ZbqYusQX+h/lkGM+E3
gHN3DG9Uho/xRS+ZdFAr+PzUBMDV5e+8s/cz3tLNPGzLeGN+B1O6Q8/YRYRWLryfABx3hOPtnhPv
lAVtlyeGpgnMUi4egWk=

Запрос На Сертификацию

Кроме Открытого Ключа в Запросе присутствует иная информация. Почитать.

Сертификат Открытого Ключа

Сертификат Открытого Ключа представляет собой наш Открытый Ключ с подписью Центра Сертификации интересующей нас организации. Подпись выполняется уникальным секретным Закрытым Ключём Центра Сертификации. В Сертификате также указывается различная информация, чаще всего сроки действия сертификата и другие данные. Например, после даты окончания действия Сертификата, мы не сможем зайти в Информационную Систему Организации.