Разбираем x.509 сертификат
Привет, %username%!
Так уж вышло, что несмотря на относительно неплохое понимание инфраструктуры открытых ключей, содержимое *.crt файлов всегда оставалось для меня полнейшей загадкой.
Нет, не поймите неправильно. Я знаю, что x.509 сертификат содержит информацию о владельце, открытый ключ, сведения об удостоверяющем центре и электронную цифровую подпись. Но при установке очередного сертификата меня всегда мучило любопытство.
Чем отличается идентификатор ключа от отпечатка? Какие данные сертификата подписываются, а какие нет? И что за структура данных позволяет хранить всю эту информацию, сводя избыточность к минимуму.
Но вот наконец-то любопытство перебороло лень и в данном посте я постараюсь описать структуру x.509 сертификатов и ответить на эти и другие вопросы.
Часть 1. Самоподписанный сертификат
В результате выполнения данной процедуры будет создан стандартный x.509 сертификат, который, будучи открытым с помощью hex-редактора, выглядит вот таким чудесным образом:
Тот же самый сертификат, но уже открытый с помощью стандартных средств windows:
Имея два этих файла, один с двоичными данными, а другой с описанием сертификата, попробуем разобраться что здесь к чему.
Прежде всего, нужно отметить, что файл *.crt хранит информацию о сертификате в закодированном виде. Для кодирования применяется особый язык, называемый ASN.1.
ASN.1 — стандарт записи, описывающий структуры данных для представления, кодирования, передачи и декодирования данных. Wikipedia
Однако ASN.1 разрабатывался в те светлые времена, когда «640 КБ должно было хватать каждому» и тратить место на такую громоздкую запись не было никакой возможности. Поэтому, в целях экономии места, а также более удобной обработки хранимой в ASN.1-форме информации, был разработан специальный метод кодирования — DER.
DER-кодировка описывается следующим правилом. Первым записывается байт, характеризующий тип данных, затем последовательность байтов хранящих сведения о длине данных и затем уже записываются сами данные.
К примеру, для кодировки целого числа INTEGER 65537 используется следующая форма: 02 03 01 00 01.
Здесь первый байт 02, определяет тип INTEGER (полную таблицу типов вы можете найти например тут), второй байт 03 показывает длину блока. А следующие за этим байты 01 00 01, являются шестнадцатеричной записью нашего числа 65537.
В нашем случае, для описание простейшего самоподписаного сертификата, достаточно 9 типов данных. Приведем таблицу кодирования для этих типов:
| Наименование типа | Краткое описание | Представление типа в DER-кодировке |
|---|---|---|
| SEQUENCE | Используется для описания структуры данных, состоящей из различных типов. | 30 |
| INTEGER | Целое число. | 02 |
| OBJECT IDENTIFIER | Последовательность целых чисел. | 06 |
| UTCTime | Временной тип, содержит 2 цифры для определения года | 17 |
| GeneralizedTime | Расширенный временной тип, содержит 4 цифры для обозначения года. | 18 |
| SET | Описывает структуру данных разных типов. | 31 |
| UTF8String | Описывает строковые данные. | 0C |
| NULL | Собственно NULL | 05 |
| BIT STRING | Тип для хранения последовательности бит. | 03 |
Зная как кодируется каждый из этих типов, мы можем попытаться распарсить наш *.crt файл.
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
Преобразуя байты-идентификаторы типов и убирая байты описывающие длину блоков получим следующую структуру:
Важным моментом, о котором стоит особенно упомянуть являются данные, для которых вычисляется подпись. Интуитивно может показаться, что подписываются все данные идущие до последнего поля BIT STRING, содержащего подпись. Но на самом деле это не так. В стандарте x.509 подписывается определенная часть сертификата, называемая TBS-сертификат (to be signed). В TSB-сертификат входит последовательность SEQUENCE второго уровня со всеми вложенными данными.
Т.о. если перед вами будет стоять задача проверить ЭЦП x.509 сертификата, то для этого сперва необходимо извлечь TBS-сертификат.
Еще одно замечание относится к отпечатку сертификата. Как видите сам сертификат не содержит никаких сведений об отпечатке. Это объясняется тем, что отпечаток представляет собой обычное хеш-значение SHA-1 от всего файла сертификата, со всеми его полями, включая подпись издателя. Поэтому хранить отпечаток не обязательно, можно просто вычислять хеш при каждом просмотре сертификата.
Часть 2. Сертификат 2-го уровня
Мы с вами рассмотрели внутренности самоподписанного сертификата, и нам осталось понять чем отличается структура сертификатов более низкого уровня, от сертификата корневого центра.
Для этого, с помощью имеющегося у нас секретного ключа сертификата CA, создадим подчиненный ему сертификат user. И в этом нам снова поможет Bouncy Castle.
Распарсив наш сертификат и преобразовав его к читаемому виду, получим следующую красоту:
Как видите, единственное отличие от самоподписанного сертификата заключается в наличие дополнительного блока:
который содержит сведения об издателе сертификата и его открытом ключе. Вот тут я хотел бы добавить одно замечание. Без этого блока сертификат все равно будет оставаться рабочим, т.к. информация хранящаяся здесь считается не более, чем дополнением, более точно указывающим каким из ключей издателя был подписан текущий сертификат. Рассмотрим каждый элемент блока отдельно.
Заключение
Тех усидчивых людей, которые продрались сквозь все эти ASN.1 выражения и шестнадцатеричные наборы данных, я хотел бы поблагодарить за прочтение. Надеюсь вам было хоть немного интересно. И стало чуточку понятнее, что же такое на самом деле X.509 сертификат.
Руководство. Общие сведения о сертификатах X.509 с открытым ключом
Сертификаты X.509 — это цифровые документы, которые представляют пользователя, компьютер, службу или устройство. Они могут выдаваться корневым или подчиненным центром сертификации (ЦС) либо центром регистрации и содержат открытый ключ субъекта сертификата. Они не содержат закрытый ключ субъекта, который должен храниться безопасно. Сертификаты с открытым ключом определяются в документе RFC 5280. Они имеют цифровую подпись и обычно содержат следующую информацию:
Поля сертификата
Со временем появились три версии сертификата. В каждой из версий добавлялись новые поля. Версия 3, которая действует в настоящий момент, содержит все поля версий 1 и 2, дополненные полями версии 3. Версия 1 определяет следующие поля:
В версии 2 добавлены следующие поля с информацией об издателе сертификата, хотя эти поля редко используются:
В сертификатах версии 3 добавлены следующие расширения:
Форматы сертификатов
Сертификаты можно сохранить в нескольких форматах. Для проверки подлинности в Центре Интернета вещей Azure обычно используются форматы PEM и PFX.
Двоичный сертификат
Содержит двоичный сертификат в необработанном формате в кодировке DER ASN.1.
Формат ASCII PEM
Ключ ASCII (PEM)
Содержит ключ DER в кодировке Base64 с добавлением необязательных метаданных со сведениями об алгоритме, используемом для защиты пароля.
Сертификат PKCS#7
Этот формат предназначен для передачи подписанных или зашифрованных данных. Он определяется стандартом RFC 2315. В нем может содержаться полная цепочка сертификатов.
Ключ PKCS#8
Этот формат предназначен для хранения закрытого ключа и определен в стандарте RFC 5208.
Ключ и сертификат PKCS#12
Дополнительные сведения
Дополнительные сведения см. в следующих разделах:
Дальнейшие действия
Если вы хотите создать тестовые сертификаты, которые можно использовать для проверки подлинности устройств в Центре Интернета вещей, изучите следующие разделы:
Если у вас есть сертификат корневого или подчиненного центра сертификации (ЦС), который вы хотите отправить в центр Интернета вещей и подтвердить права владения, см. руководство Подтверждение принадлежности сертификата ЦС.
DER-шифрованный файл X.509
DER (Distinguished Encoding Rules) для ASN.1, как определено в рекомендации ITU-T Recommendation X.509, — более ограниченный стандарт кодирования, чем альтернативный BER (Basic Encoding Rules) для ASN.1, определенный в рекомендации ITU-T Recommendation X.209, на котором основан DER. И BER, и DER обеспечивают независимый от платформы метод кодирования объектов, таких как сертификаты и сообщения, для трансмиссии между устройствами и приложениями.
При кодировании сертификата большинство приложений используют стандарт DER, т. к. сертификат (сведения о запросе сертификата) должен быть закодирован с помощью DER и подписан.
Base64-шифрованный формат X.509
Этот метод кодирования создан для работы с протоколом S/MIME, который популярен при передаче двоичных файлов через Интернет. Base64 кодирует файлы в текстовый формат ASCII, при этом файлы повреждаются каждый раз при прохождении через шлюз, в то время как S/MIME обладает некоторыми криптографическими службами безопасности для элекронных приложений сообщений, включая целостность происходения и использование цифровых подписей, секретность и безопаспость данных при помощи кодирования, процесса проверки подлинности и невозможности отрицания авторства сообщений.
MIME (Multipurpose Internet Mail Extensions) спецификации (RFC 1341 and successors) определяет механизмы кодирования произвольных двоичных данных для передачи по электронной почте.
Разбираем x.509 сертификат
Для начала рассмотрим вариант самоподписанного сертификата корневого уровня.
Для упрощения задачи сгенерируем сертификат, который будет содержать только необходимые параметры:
Сделать это можно с помощью библиотеки Bouncy Castle, следующим образом:
В результате выполнения данной процедуры будет создан стандартный x.509 сертификат, который, будучи открытым с помощью hex-редактора, выглядит вот таким чудесным образом:
Тот же самый сертификат, но уже открытый с помощью стандартных средств windows:
Имея два этих файла, один с двоичными данными, а другой с описанием сертификата, попробуем разобраться что здесь к чему.
Прежде всего, нужно отметить, что файл *.crt хранит информацию о сертификате в закодированном виде. Для кодирования применяется особый язык, называемый ASN.1.
ASN.1 — стандарт записи, описывающий структуры данных для представления, кодирования, передачи и декодирования данных. Wikipedia
С помощью языка ASN.1 можно описывать сложные структуры, состоящие из данных различных типов. Типичный пример ASN.1-файла выглядит как-то так:
Однако ASN.1 разрабатывался в те светлые времена, когда «640 КБ должно было хватать каждому» и тратить место на такую громоздкую запись не было никакой возможности. Поэтому, в целях экономии места, а также более удобной обработки хранимой в ASN.1-форме информации, был разработан специальный метод кодирования — DER.
DER-кодировка описывается следующим правилом. Первым записывается байт, характеризующий тип данных, затем последовательность байтов хранящих сведения о длине данных и затем уже записываются сами данные.
К примеру, для кодировки целого числа INTEGER 65537 используется следующая форма: 02 03 01 00 01.
Здесь первый байт 02, определяет тип INTEGER (полную таблицу типов вы можете найти например тут ), второй байт 03 показывает длину блока. А следующие за этим байты 01 00 01, являются шестнадцатеричной записью нашего числа 65537.
В нашем случае, для описание простейшего самоподписаного сертификата, достаточно 9 типов данных. Приведем таблицу кодирования для этих типов:
Зная как кодируется каждый из этих типов, мы можем попытаться распарсить наш *.crt файл.
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. Пробежимся по каждому элементу:
Важным моментом, о котором стоит особенно упомянуть являются данные, для которых вычисляется подпись. Интуитивно может показаться, что подписываются все данные идущие до последнего поля BIT STRING, содержащего подпись. Но на самом деле это не так. В стандарте x.509 подписывается определенная часть сертификата, называемая TBS-сертификат (to be signed). В TSB-сертификат входит последовательность SEQUENCE второго уровня со всеми вложенными данными.
Т.о. если перед вами будет стоять задача проверить ЭЦП x.509 сертификата, то для этого сперва необходимо извлечь TBS-сертификат.
Еще одно замечание относится к отпечатку сертификата. Как видите сам сертификат не содержит никаких сведений об отпечатке. Это объясняется тем, что отпечаток представляет собой обычное хеш-значение SHA-1 от всего файла сертификата, со всеми его полями, включая подпись издателя. Поэтому хранить отпечаток не обязательно, можно просто вычислять хеш при каждом просмотре сертификата.
Мы с вами рассмотрели внутренности самоподписанного сертификата, и нам осталось понять чем отличается структура сертификатов более низкого уровня, от сертификата корневого центра.
Для этого, с помощью имеющегося у нас секретного ключа сертификата CA, создадим подчиненный ему сертификат user. И в этом нам снова поможет Bouncy Castle.
Распарсив наш сертификат и преобразовав его к читаемому виду, получим следующую красоту:
Как видите, единственное отличие от самоподписанного сертификата заключается в наличие дополнительного блока:
который содержит сведения об издателе сертификата и его открытом ключе. Вот тут я хотел бы добавить одно замечание. Без этого блока сертификат все равно будет оставаться рабочим, т.к. информация хранящаяся здесь считается не более, чем дополнением, более точно указывающим каким из ключей издателя был подписан текущий сертификат. Рассмотрим каждый элемент блока отдельно.
Напоследок откроем полученный сертификат с помощью стандартных средств и убедимся, что все необходимые данные на месте:
Читайте также
Did you wonder how to eliminate problems with complexity of mapping, whose are always coming back to you?It concerns a…
This page was created on Sat Oct 09 2010 and last changed on Thu Mar 28 2019. This lists similar…
Сетевые драйверыСетевая подсистема Docker является подключаемой с использованием драйверов.Несколько драйверов существуют по умолчанию и предоставляют основные сетевые функции:bridge: сетевой драйвер…
СОДЕРЖАНИЕ
Кодирование BER
Формат для базовых правил кодирования определяет самоописывающий и саморазграничивающий формат для кодирования структур данных ASN.1. Каждый элемент данных кодируется как идентификатор типа, описание длины, фактические элементы данных и, при необходимости, маркер конца содержимого. Эти типы кодирования обычно называются кодированием типа длина-значение или TLV-кодированием. Этот формат позволяет получателю декодировать информацию ASN.1 из неполного потока, не требуя каких-либо предварительных знаний о размере, содержании или семантическом значении данных.
Структура кодирования
Кодирование данных обычно состоит из четырех компонентов, которые появляются в следующем порядке:
| Октеты идентификатора Тип | Длина октеты Длина | Содержание октетов Значение | Октеты конца содержимого |
Октеты конца содержимого являются необязательными и используются только в том случае, если используется форма неопределенной длины. Октет содержимого также может быть опущен, если нет содержимого для кодирования, как в типе NULL.
Октеты идентификатора
Данные (особенно элементы последовательностей, наборов и вариантов выбора) могут быть помечены уникальным номером тега (показанным в ASN.1 в квадратных скобках []), чтобы отличать эти данные от других элементов. Такие теги могут быть неявными (где они кодируются как тег TLV значения вместо использования базового типа в качестве тега TLV) или явными (когда тег используется в построенном TLV, который охватывает TLV базового типа). Стиль тегов по умолчанию является явным, если неявный не установлен на уровне модуля ASN.1. Такие теги имеют класс по умолчанию, зависящий от контекста, но его можно переопределить, используя имя класса перед тегом.
Кодировка значения выбора такая же, как кодировка значения выбранного типа. Кодировка может быть примитивной или построенной, в зависимости от выбранного типа. Тег, используемый в октетах идентификатора, является тегом выбранного типа, как указано в определении выбранного типа ASN.1.
Следующие теги являются родными для ASN.1:
| Имя | Разрешенное строительство | Номер тега | |
|---|---|---|---|
| Десятичный | Шестнадцатеричный | ||
| Конец содержания (EOC) | Примитивный | 0 | 0 |
| BOOLEAN | Примитивный | 1 | 1 |
| ЦЕЛОЕ | Примитивный | 2 | 2 |
| BIT STRING | Оба | 3 | 3 |
| ОКТЕТНАЯ СТРОКА | Оба | 4 | 4 |
| НОЛЬ | Примитивный | 5 | 5 |
| ИДЕНТИФИКАТОР ОБЪЕКТА | Примитивный | 6 | 6 |
| Дескриптор объекта | Оба | 7 | 7 |
| ВНЕШНИЙ | Построено | 8 | 8 |
| НАСТОЯЩИЙ (плавающий) | Примитивный | 9 | 9 |
| ПЕРЕЧИСЛЕННЫЕ | Примитивный | 10 | А |
| ВСТРОЕННЫЙ PDV | Построено | 11 | B |
| UTF8String | Оба | 12 | C |
| ОТНОСИТЕЛЬНЫЙ-OID | Примитивный | 13 | D |
| ВРЕМЯ | Примитивный | 14 | E |
| Зарезервированный | 15 | F | |
| ПОСЛЕДОВАТЕЛЬНОСТЬ И ПОСЛЕДОВАТЕЛЬНОСТЬ | Построено | 16 | 10 |
| НАБОР и НАБОР | Построено | 17 | 11 |
| NumericString | Оба | 18 | 12 |
| PrintableString | Оба | 19 | 13 |
| T61String | Оба | 20 | 14 |
| VideotexString | Оба | 21 год | 15 |
| IA5String | Оба | 22 | 16 |
| UTCTime | Оба | 23 | 17 |
| GeneralizedTime | Оба | 24 | 18 |
| GraphicString | Оба | 25 | 19 |
| VisibleString | Оба | 26 | 1А |
| GeneralString | Оба | 27 | 1B |
| UniversalString | Оба | 28 год | 1С |
| СТРОКА ХАРАКТЕРА | Построено | 29 | 1D |
| BMPString | Оба | 30 | 1E |
| ДАТА | Примитивный | 31 год | 1F |
| ВРЕМЯ ДНЯ | Примитивный | 32 | 20 |
| ДАТА-ВРЕМЯ | Примитивный | 33 | 21 год |
| ПРОДОЛЖИТЕЛЬНОСТЬ | Примитивный | 34 | 22 |
| OID-IRI | Примитивный | 35 год | 23 |
| ОТНОСИТЕЛЬНЫЙ-OID-IRI | Примитивный | 36 | 24 |
Список назначений тегов универсального класса можно найти в Рек. МСЭ-Т X.680, раздел 8, таблица 1.
Кодирование
Октеты идентификатора кодируют тип элемента как тег ASN.1, состоящий из класса и числа, а также того, представляют ли октеты содержимого сконструированное или примитивное значение. Обратите внимание, что некоторые типы могут иметь значения как с примитивными, так и с построенными кодировками. Он кодируется как 1 или несколько октетов.
| Октет 1 | Октет 2 и далее | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
| Класс тега | ПК | Номер тега (0–30) | N / A | ||||||||||||
| 31 год | Более | Номер тега | |||||||||||||
В начальном октете бит 6 кодирует, является ли тип примитивным или составным, биты 7–8 кодируют класс типа, а биты 1–5 кодируют номер тега. Возможны следующие значения:
| Класс | Значение | Описание |
|---|---|---|
| Универсальный | 0 | Тип является родным для ASN.1 |
| Заявление | 1 | Тип действителен только для одного конкретного приложения. |
| Зависит от контекста | 2 | Значение этого типа зависит от контекста (например, в последовательности, наборе или выборе) |
| Частный | 3 | Определяется в частных спецификациях |
| ПК | Значение | Описание |
|---|---|---|
| Примитивный (P) | 0 | Октеты содержимого непосредственно кодируют значение элемента. |
| Построен (C) | 1 | Октеты содержимого содержат 0, 1 или более кодировок элементов. |
Длинная форма
Если номер тега слишком велик для 5-битного поля тега, его необходимо закодировать в следующих октетах.
Начальный октет кодирует класс и примитив / построенный, как и раньше, а биты 1–5 равны 1. Номер тега кодируется в следующих октетах, где бит 8 каждого равен 1, если октетов больше, а биты 1–7 кодируют номер тега. Комбинированные биты номера тега с прямым порядком байтов кодируют номер тега. Должно быть закодировано наименьшее количество следующих октетов; то есть биты 1–7 не должны быть 0 в первом последующем октете.
Октеты длины
Существует две формы октетов длины: определенная форма и неопределенная форма.
| Форма | Биты | |||||||
|---|---|---|---|---|---|---|---|---|
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | |
| Определенный, короткий | 0 | Длина (0–127) | ||||||
| Неопределенный | 1 | 0 | ||||||
| Определенный, длинный | 1 | Количество следующих октетов (1–126) | ||||||
| Зарезервированный | 1 | 127 | ||||||
Определенная форма
Он кодирует количество октетов содержимого и всегда используется, если тип является примитивным или сконструированным и данные доступны немедленно. Есть короткая форма и длинная форма, которые могут кодировать различные диапазоны длин. Числовые данные кодируются как целые числа без знака, причем младший бит всегда идет первым (справа).
| Октет 1 | Октет 2 | Октет 3 | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |
| Длинная форма | 2 октета длины | 435 октетов содержимого | |||||||||||||||||||||
Неопределенная форма
Это вообще не кодирует длину, но октеты содержимого заканчиваются октетами маркера. Это применимо к сконструированным типам и обычно используется, если контент не доступен сразу во время кодирования.
Он состоит из одного октета, в котором бит 8 равен 1, а биты 1–7 равны 0. Затем 2 октета конца содержимого должны завершать октеты содержимого.
Октеты содержания
Октеты содержимого кодируют значение данных элемента.
Обратите внимание, что октетов содержимого может не быть (следовательно, длина элемента равна 0), если необходимо отметить только существование объекта ASN.1 или его пустоту. Например, это случай значения NULL ASN.1.
Кодирование CER
Кодировка DER
Наиболее существенными ограничениями кодирования DER являются:
Сравнение BER, CER и DER
Ключевое различие между форматом BER и форматами CER или DER заключается в гибкости, обеспечиваемой базовыми правилами кодирования. BER, как объяснено выше, является базовым набором правил кодирования, заданным ITU-T X.690 для передачи структур данных ASN.1. Это дает отправителям четкие правила кодирования структур данных, которые они хотят отправить, но также оставляет отправителям некоторые варианты кодирования. Как указано в стандарте X.690, «Альтернативные кодировки разрешены основными правилами кодирования в качестве опции отправителя. Получатели, заявляющие о соответствии основным правилам кодирования, должны поддерживать все альтернативы».
Получатель должен быть готов принять все законные кодировки, чтобы законно заявить о соответствии BER. Напротив, и CER, и DER ограничивают доступные спецификации длины одним параметром. Таким образом, CER и DER являются ограниченными формами BER и служат для устранения неоднозначности стандарта BER.
Чтобы облегчить выбор между правилами кодирования, документ стандартов X.690 предоставляет следующие рекомендации:
Выделенные правила кодирования более подходят, чем канонические правила кодирования, если закодированное значение достаточно мало, чтобы поместиться в доступной памяти, и есть необходимость быстро пропустить некоторые вложенные значения. Канонические правила кодирования более подходят, чем выделенные правила кодирования, если необходимо кодировать значения, которые настолько велики, что они не могут легко поместиться в доступную память, или если необходимо кодировать и передавать часть значения перед всем значением. доступен. Основные правила кодирования более подходят, чем канонические или выделенные правила кодирования, если кодирование содержит заданное значение или набор значений и нет необходимости в ограничениях, которые накладывают канонические и выделенные правила кодирования.
Критика кодирования BER
Применение
Несмотря на кажущиеся проблемы, BER является популярным форматом для передачи данных, особенно в системах с различными собственными кодировками данных.
Смотрите также
Рекомендации
Эта статья основана на материалах, взятых из Free On-line Dictionary of Computing до 1 ноября 2008 г. и включенных в соответствии с условиями «перелицензирования» GFDL версии 1.3 или новее.
