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

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

Что такое:
1. Закрытый Ключ
2. Открытый Ключ
3. Запрос На Сертификацию
4. Сертификат Открытого Ключа

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

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

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

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

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

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

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

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

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

В простейшем случае можно сказать, что для генерации ключа длиной 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

Собственно, то что мы видим выше, можно назвать Закрытым Ключом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В файле 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=

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

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

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

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