Идентификатор ключа

Расширения сертификата

Расширения, определенные для сертификатов Х.509 v3, предоставляют методы для связывания дополнительных атрибутов с пользователями или открытыми ключами и для управления сертификатами. Формат сертификата Х.509 v3 также допускает определение частных расширений.

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

Каждое расширение должно иметь соответствующий OID и определяться ASN.1-структурой. Когда расширение появляется в сертификате, OID появляется как поле , и соответствующая ASN.1 структура представления является значением строки октетов . Сертификат не должен включать более одного экземпляра конкретного расширения. Например, сертификат может содержать только одно расширение для идентификатора ключа уполномоченного органа. Расширение включает булево значение критичности со значением по умолчанию, равным . Для каждого расширения должны быть определены допустимые значения для поля критичности.

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

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

Могут также распознаваться расширения идентификаторов ключа сертификационного центра и субъекта и расширение отображения политики.

Стандартные расширения

Рассмотрим стандартные расширения сертификата, определенные в стандарте X.509. Каждое расширение имеет определенный OID. Эти OIDs являются элементами id-ce множества, которое определено следующим образом:

Идентификатор ключа сертификационного центра

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

Поле расширения должно быть включено во все сертификаты, выпущенные СА для обеспечения возможности создания . Существует одно исключение: когда СА распространяет свой открытый ключ в форме , идентификатор ключа уполномоченного органа может быть опущен. Подпись для создается закрытым ключом, соответствующим открытому ключу субъекта. Это доказывает, что выпускающий обладает как открытым ключом, так и закрытым. В таком случае идентификаторы субъекта и уполномоченного органа должны быть одинаковыми, и идентификатор ключа может быть указан только для открытого ключа субъекта.

Значение поля должно быть получено из открытого ключа, используемого для проверки подписи сертификата, или методом, который создает уникальные значения. Рассмотрим два метода создания идентификаторов ключей из открытого ключа и один метод создания уникальных значений для . Если идентификатор ключа не был предварительно определен, рекомендуется использовать один из этих методов для создания . Если идентификатор ключа был предварительно определен, СА должен задействовать предварительно определенный идентификатор.

Рекомендуется поддерживать метод идентификации ключа всем пользователям сертификатов.

Данное расширение не должно помечаться как критичное.

Идентификатор ключа субъекта

Расширение идентификатора ключа субъекта предоставляет способ идентификации сертификата, содержащего конкретный открытый ключ.

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

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

Метод создания уникальных значений состоит в использовании последовательности целых чисел.

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

Данное расширение не должно быть помечено как критичное.

Время на прочтение

Перед вами перевод второй части серии материалов, посвящённых защите целостности кода с помощью PGP. В прошлый раз мы разобрали основы PGP, а сегодня поговорим о том, как создавать 4096-битные мастер-ключи RSA, и о том, как их защищать.

Вот какие навыки вы должны освоить после того, как разберётесь с материалами этого раздела:

▍Что такое мастер-ключ (сертифицирующий ключ)

В этом и следующем разделах мы будем говорить о так называемых «мастер-ключах» и «подключах». Рассматривая эти виды ключей, важно понимать следующее:

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

▍Действия, выполняемые перед созданием мастер-ключа

Прежде чем вы создадите свой мастер-ключ, вам нужно выбрать свои основные идентификационные данные и ключевую фразу.

▍Основные идентификационные данные

Идентификационные данные — это строка, использующая тот же формат, что и поле From в электронных письмах:

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

Ключевая фраза (её ещё называют «фраза-пароль») используется исключительно для шифрования закрытого ключа с помощью симметричного алгоритма при сохранении этого ключа на диск. Если содержимое вашей директории .gnupg когда-нибудь попадёт в руки злоумышленника, хорошая ключевая фраза станет последней линией обороны между ним и его возможностью выдавать себя за вас в сети. Именно поэтому важно использовать хорошую ключевую фразу.

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

▍Алгоритм и стойкость ключа

GnuPG уже некоторое время поддерживает шифрование, основанное на эллиптических кривых, но мы пока будем придерживаться использования ключей RSA. Хотя можно применять и ключи ED25519, вероятно, вам встретятся программные инструменты и устройства, которые не смогут с ними нормально работать.

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

Для того чтобы создать мастер-ключ, выполните следующую команду, поместив ваши данные вместо данных условного пользователя Alice Engineer:

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

Посмотрите на то, что выведет команда. Вы увидите примерно следующее:

Обратите внимание на длинную последовательность символов во второй строке. Это — полный отпечаток только что созданного ключа. Идентификаторы ключей могут быть представлены в трёх различных формах:

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

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

▍Резервная копия мастер-ключа

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

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

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

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

▍Добавление идентификационных данных

Просмотреть уже добавленные к ключу UID можно следующей командой:

▍Выбор основного набора идентификационных данных

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

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

Уважаемые читатели! Как вы храните резервные копии ваших мастер-ключей?

Дата и время начала действия

Дата и время окончания действия

Ключ (строка битов)

Общее название УЦ

Серийный номер сертификата УЦ

1. Формирование и проверка

3. Шифрование других ключей

4. Шифрование и расшифрова-

ние данных и контроль цело-

стности с использованием

5. Формирование других ключей

(например, по алгоритму

6. Формирование ЭЦП серти-

фикатов. Может использо-

7. Формирование ЭЦП САС.

Может использоваться УЦ

8. Только для шифрования

9. Только для расшифрования

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

Свободный выбор имени.

ресурсов WWW URL

Зарегистрированный ID объекта

Так уж вышло, что несмотря на относительно неплохое понимание инфраструктуры открытых ключей, содержимое *.crt файлов всегда оставалось для меня полнейшей загадкой.
Нет, не поймите неправильно. Я знаю, что x.509 сертификат содержит информацию о владельце, открытый ключ, сведения об удостоверяющем центре и электронную цифровую подпись. Но при установке очередного сертификата меня всегда мучило любопытство.
Чем отличается идентификатор ключа от отпечатка? Какие данные сертификата подписываются, а какие нет? И что за структура данных позволяет хранить всю эту информацию, сводя избыточность к минимуму.
Но вот наконец-то любопытство перебороло лень и в данном посте я постараюсь описать структуру x.509 сертификатов и ответить на эти и другие вопросы.

Часть 1. Самоподписанный сертификат

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

Сделать это можно с помощью библиотеки Bouncy Castle, следующим образом:

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

30 82 01 8F 30 81 F9 A0 03 02 01 02 02 01 01 30
0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 30 0D
31 0B 30 09 06 03 55 04 03 0C 02 43 41 30 20 17
0D 31 33 30 39 31 35 31 35 33 35 30 32 5A 18 0F
32 31 31 33 30 39 32 32 31 35 33 35 30 32 5A 30
0D 31 0B 30 09 06 03 55 04 03 0C 02 43 41 30 81
9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00
03 81 8D 00 30 81 89 02 81 81 00 8D 80 B5 8E 80
8E 94 D1 04 03 6A 45 1A 54 5E 7E EE 6D 0C CB 0B
82 03 F1 7D C9 6F ED 52 02 B2 08 C3 48 D1 24 70
C3 50 C2 1C 40 BC B5 9D F8 E8 A8 41 16 7B 0B 34
1F 27 8D 32 2D 38 BA 18 A5 31 A9 E3 15 20 3D E4
0A DC D8 CD 42 B0 E3 66 53 85 21 7C 90 13 E9 F9
C9 26 5A F3 FF 8C A8 92 25 CD 23 08 69 F4 A2 F8
7B BF CD 45 E8 19 33 F1 AA E0 2B 92 31 22 34 60
27 2E D7 56 04 8B 1B 59 64 77 5F 02 03 01 00 01
30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03
81 81 00 0A 1C ED 77 F4 79 D5 EC 73 51 32 25 09
61 F7 00 C4 64 74 29 86 5B 67 F2 3D A9 39 34 6B
3C A9 92 B8 BF 07 13 0B A0 9B DF 41 E2 8A F6 D3
17 53 E1 BA 7F C0 D0 BC 10 B7 9B 63 4F 06 D0 7B
AC C6 FB CE 95 F7 8A 72 AA 10 EA B0 D1 6D 74 69
5E 20 68 5D 1A 66 28 C5 59 33 43 DB EE DA 00 80
99 5E DD 17 AC 43 36 1E D0 5B 06 0F 8C 6C 82 D3
BB 3E 2B A5 F1 94 FB 53 7B B0 54 22 6F F6 4C 18
1B 72 1C

Тот же самый сертификат, но уже открытый с помощью стандартных средств windows:

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

Прежде всего, нужно отметить, что файл *.crt хранит информацию о сертификате в закодированном виде. Для кодирования применяется особый язык, называемый ASN.1.

ASN.1 — стандарт записи, описывающий структуры данных для представления, кодирования, передачи и декодирования данных. Wikipedia

С помощью языка ASN.1 можно описывать сложные структуры, состоящие из данных различных типов. Типичный пример ASN.1-файла выглядит как-то так:

Однако ASN.1 разрабатывался в те светлые времена, когда «640 КБ должно было хватать каждому» и тратить место на такую громоздкую запись не было никакой возможности. Поэтому, в целях экономии места, а также более удобной обработки хранимой в ASN.1-форме информации, был разработан специальный метод кодирования — DER.

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

К примеру, для кодировки целого числа INTEGER 65537 используется следующая форма:

01 00 01.
Здесь первый байт 02, определяет тип INTEGER (полную таблицу типов вы можете найти например тут), второй байт 03 показывает длину блока. А следующие за этим байты 01 00 01, являются шестнадцатеричной записью нашего числа 65537.

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

Зная как кодируется каждый из этих типов, мы можем попытаться распарсить наш *.crt файл.

82 01 8F 02 01
2A 86 48 86 F7 0D 01 01 05
55 04 03 43 41
31 33 30 39 31 35 31 35 33 35 30 32 5A
32 31 31 33 30 39 32 32 31 35 33 35 30 32 5A
55 04 03 43 41
9F 2A 86 48 86 F7 0D 01 01 01
00 00 8D 80 B5 8E 80
8E 94 D1 04 03 6A 45 1A 54 5E 7E EE 6D 0C CB 0B
82 03 F1 7D C9 6F ED 52 02 B2 08 C3 48 D1 24 70
C3 50 C2 1C 40 BC B5 9D F8 E8 A8 41 16 7B 0B 34
1F 27 8D 32 2D 38 BA 18 A5 31 A9 E3 15 20 3D E4
0A DC D8 CD 42 B0 E3 66 53 85 21 7C 90 13 E9 F9
C9 26 5A F3 FF 8C A8 92 25 CD 23 08 69 F4 A2 F8
7B BF CD 45 E8 19 33 F1 AA E0 2B 92 31 22 34 60
27 2E D7 56 04 8B 1B 59 64 77 5F 01 00 01
2A 86 48 86 F7 0D 01 01 05
00 0A 1C ED 77 F4 79 D5 EC 73 51 32 25 09
61 F7 00 C4 64 74 29 86 5B 67 F2 3D A9 39 34 6B
3C A9 92 B8 BF 07 13 0B A0 9B DF 41 E2 8A F6 D3
17 53 E1 BA 7F C0 D0 BC 10 B7 9B 63 4F 06 D0 7B
AC C6 FB CE 95 F7 8A 72 AA 10 EA B0 D1 6D 74 69
5E 20 68 5D 1A 66 28 C5 59 33 43 DB EE DA 00 80
99 5E DD 17 AC 43 36 1E D0 5B 06 0F 8C 6C 82 D3
BB 3E 2B A5 F1 94 FB 53 7B B0 54 22 6F F6 4C 18
1B 72 1C

Преобразуя байты-идентификаторы типов и убирая байты описывающие длину блоков получим следующую структуру:

Это уже более похоже на то, что мы видим при открытии сертификатов в браузере или Windows. Пробежимся по каждому элементу:

Важным моментом, о котором стоит особенно упомянуть являются данные, для которых вычисляется подпись. Интуитивно может показаться, что подписываются все данные идущие до последнего поля BIT STRING, содержащего подпись. Но на самом деле это не так. В стандарте x.509 подписывается определенная часть сертификата, называемая TBS-сертификат (to be signed). В TSB-сертификат входит последовательность SEQUENCE второго уровня со всеми вложенными данными.

Т.о. если перед вами будет стоять задача проверить ЭЦП x.509 сертификата, то для этого сперва необходимо извлечь TBS-сертификат.

Еще одно замечание относится к отпечатку сертификата. Как видите сам сертификат не содержит никаких сведений об отпечатке. Это объясняется тем, что отпечаток представляет собой обычное хеш-значение SHA-1 от всего файла сертификата, со всеми его полями, включая подпись издателя. Поэтому хранить отпечаток не обязательно, можно просто вычислять хеш при каждом просмотре сертификата.

Часть 2. Сертификат 2-го уровня

Распарсив наш сертификат и преобразовав его к читаемому виду, получим следующую красоту:

Как видите, единственное отличие от самоподписанного сертификата заключается в наличие дополнительного блока:

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

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

Заключение

Тех усидчивых людей, которые продрались сквозь все эти ASN.1 выражения и шестнадцатеричные наборы данных, я хотел бы поблагодарить за прочтение. Надеюсь вам было хоть немного интересно. И стало чуточку понятнее, что же такое на самом деле X.509 сертификат.

Ну и как всегда немного ссылок для тех, кому хочется больше подробностей.