X.690

X.690 – один из стандартов ASN.1, разработанных совместно организациями ISO, IEC и ITU-T для удобства представления данных при их передаче в телекоммуникационных сетях. Правила ирования, описанные в X.690, служат для представления структур данных, описанных по правилам ASN.1, в виде последовательностей байт. Такие последовательности удобнее передавать по линиям связи или сохранять в файлы, чем делать те же операции с самими структурами[1].

Стандарт X.690 описывает следующие правила ирования структур данных, созданных в соответствии с ASN.1:

  • BER (Basic Encoding Rules);
  • CER (Canonical Encoding Rules);
  • DER (Distinguished Encoding Rules);

История[ | ]

В 1984 году организация ITU-T создала серию стандартов X.400, в числе которых был и стандарт X.409, который, ввиду активного использования, в 1988 году ITU-T совместно с ISO и IEC выделили в два отдельных стандарта: X.208, описывающий ASN.1, и X.209, в котором описывались правила BER. В 1994 году ASN.1 был переработан и серия стандартов X.208 перешла в серию X.680, а стандарту X.209 на смену пришёл стандарт X.690[2].

Basic Encoding Rules[ | ]

Базовые правила ирования или BER – набор правил, объясняющий как представить любую структуру данных, описанную согласно ASN.1, в виде последовательности восьмибитных октетов[3].

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

  • Идентификатор – один или несколько октетов, в которых содержится информация о типе заированных данных;
  • Часть, содержащая информацию о длине блока – один или несколько октетов, в которых содержится информация о длине заированных данных;
  • Часть, содержащая заированную информацию.

Идентификатор[ | ]

Формат идентификатора строго фиксирован[4].

8 7 6 5 4 3 2 1
Класс Тип Тег

Биты 8 и 7 определяют класс данных

Класс бит 8 бит 7 Описание класса
Универсальный 0 0 типы, которые определены только в X.690 и имеют одинаковый смысл во всех приложениях
Прикладной 0 1 типы, смысл которых меняется в зависимости от приложения [примечание 1]
Контекстно-зависимый 1 0 типы, смысл которых зависит от данного составного типа[примечание 2]
Частный 1 1 типы, смысл которых зависит от конкретной организации

Бит 6 определяет, являются ли данные простыми (как-то INTEGER), или могут содержать в себе другие различные наборы данных (как-то SET). При этом при ировании в первом случае говорят о примитивном ировании, а во втором - о конструктивном;

Тип данных бит 6
Простой 0
Составной 1

Биты 5 - 1 определяют тег данных.

Теги, описанные в ASN.1
Тип данных Тег (десятичный) Тег (шестнадцатеричный)
EOC (End-of-Content) 0 0
BOOLEAN 1 1
INTEGER 2 2
BIT STRING 3 3
OCTET STRING 4 4
NULL 5 5
OBJECT IDENTIFIER 6 6
Object Descriptor 7 7
EXTERNAL 8 8
REAL 9 9
ENUMERATED 10 A
EMBEDDED PDV 11 B
UTF8String 12 C
RELATIVE-OID 13 D
(reserved) 14 E
(reserved) 15 F
SEQUENCE и SEQUENCE OF 16 10
SET и SET OF 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 1A
GeneralString 27 1B
UniversalString 28 1C
CHARACTER STRING 29 1D
BMPString 30 1E
(длинная форма) 31 1F

В случае если класс данных не определен в ASN.1, то тег может быть больше 30. В таком случае используют несколько октетов для представления идентификатора. При этом биты 5-1 первого октета имеют значение 111112, а следующие октеты, ируются следующим образом:

  • Бит 8 во всех октетах, кроме последнего равен 1; в последнем октете бит 8 равен 0;
  • Биты с 1 по 7 этих октетов содержат биты тега в его двоичном представлении.

Октеты длины заированных данных[ | ]

В случае, если длина блока заированных данных заранее известна, октеты длины ируются следующим образом:

Если эта длина не превышает 127 октетов (байт), то она просто записывается в соответствующий октет длины. Такая форма представления октетов длины называется короткой (short form).

Пример:  длина блока данных L:
         L = 34 будет заирована в виде 0010 0010

Если длина блока заированных данных больше 127 байт, то:

  • в биты второго и последующих октетов записывается значение длины блока заированной информации в её (длины) двоичном представлении;
  • в первый октет записывается количество дополнительных блоков длины, считая со второго; бит 8 первого октета устанавливается в 1.

Такая форма представления октетов длины называется длинной (long form)

Пример:  длина блока данных L:
         L = 2614 (0000 1010 0011 0110 в двоичном формате)
         будет заирована в виде:
         82 0A 36 (10000010 00001010 00110110 в двоичном формате)

Если же длина блока заированных данных на момент ирования длины неизвестна, то в октет длины записывается значение 0х80, что указывает на ирование с неопределенной длиной (indefinite form). В этом случае в конце блока заированных данных должны стоять октеты 00 00, явно указывающие на его завершение. ирование с неопределённой длиной разрешено только для конструктивных типов данных; два нулевых октета в конце соответствуют ASN.1-типу данных с тегом 0 (End-of-contents) и длиной 0.

ирование структур различных типов[ | ]

ирование различных типов данных детально описано в тексте стандарта (англ.).

Неоднозначность ирования[ | ]

В зависимости от структуры и преследуемых при ировании целей, ирование одних и тех же данных может существенно различаться[5][6].

Так, BER-ирование значения TRUE типа BOOLEAN может иметь как вид:

01 01 01 

так и вид:

01 01 0F

Результат ирования типа SET может быть различным в зависимости от того, в каком порядке мы ируем "вложенные" типы данных:

если

set::= SET { int, float}
int::= INTEGER
float::= REAL 

то для

set{-128, 0.15625}

результат ирования по правилам BER может быть таким:

31 08 02 01 80 09 03 80 FB 05;

и таким:

31 08 09 03 80 FB 05 02 01 80.

В зависимости от того, примитивное или конструктивное ирование используется, его результат может также различаться. Так для значения "Test User 1" типа STRING при примитивном ировании результат будет иметь вид:

13 0B 54 65 73 74 20 55 73 65 72 20 31

при конструктивном:

33 0F 13 05 54 65 73 74 20 13 06 55 73 65 72 20 31

DER и CER[ | ]

Для однозначного ирования данных используются правила ирования DER и CER.

Distinguished Encoding Rules[ | ]

Особые правила ирования или DER совпадают с BER с учётом выполнения следующих ограничений:

  1. Для ирования данных с известной длиной количество октетов длины должно быть наименьшим;
  2. ирование простых типов данных (в том числе STRING, OCTET STRING и BIT ARRAY) всегда примитивное;
  3. Для типа SET ирование вложенных типов должно происходить в порядке следования их тегов (согласно ASN.1).

Canonical Encoding Rules[ | ]

Канонические правила ирования или CER совпадают с BER с учётом выполнения следующих ограничений:

  1. Для составных типов данных должно применяться ирование с неизвестной длиной;
  2. Для примитивного ирования количество октетов длины должно быть наименьшим;
  3. Для типа SET ирование вложенных типов должно происходить в порядке следования их тегов (согласно ASN.1).

Сравнение BER, DER и CER[ | ]

BER предлагает пользователю различные пути для ирования одних и тех же данных, причём предполагается, что система, которая поддерживает стандарты ASN.1, может корректно их деировать вне зависимости от представления, в то время как DER и CER поддерживают только конкретный вариант ирования для каждого типа[6]. Это отличие проявляется в быстродействии ирования данных: согласно исследованиям, если при ировании используется строго определенный формат данных, то системе требуется для этого намного меньше операций. Проще говоря, DER и CER обеспечивают много большее быстродействие, чем BER[7].

Основное же отличие DER от CER заключается в том, что в DER используется ирование данных с известной длиной, а в CER в некоторых случаях (например, при ировании данных типа STRING длиной более 1000 символов) используется ирование с неизвестной заранее длиной. Это отличие выражается в количестве блоков, необходимых для ирования длины зашифрованных данных. Так, для определения длины блока заированных данных при ировании с неизвестной длиной требуется всего 3 октета, в то время как для больших сообщений при DER ировании их количество может достигать 32 октетов. То есть целесообразно использовать DER при ировании небольших по размеру данных, а CER - для больших[8].

Сравнение X.690 и X.209[ | ]

Общее[ | ]

Переход от стандартов X.208 и X.209 к X.680 - X.683 и X.690 был обусловлен необходимостью исправления ошибок, выявленных в процессе использования протоколов, работающих с ASN.1[9]. В связи с этим, при переходе от одних стандартов к другим была обеспечена их полная совместимость. В частности, при получении одним пользователем от другого структуры, заированной по правилам BER, зачастую невозможно с определенностью сказать, какой из стандартов тот использовал при ировании[10].

Отличия[ | ]

  • Для новых типов данных (как-то RELATIVE-OID) добавлены правила ирования;
  • Для типов данных, правила описания которых изменились, изменились и правила ирования (но результат ирования одной и той же структуры данных одинаков как при использовании X.209, так и при использовании X.690)[10].

Применение[ | ]

BER, DER и CER активно применяют в различных протоколах передачи данных и в криптографических протоколах, как-то:

  • SNMP и LDAP[11];
  • PKCS #7 (для ирования сообщений)[12];
  • X.509 (для хранения сертификатов)[13];
  • EMV (для ирования данных хранимых на карте).
  • Kerberos

Другие стандарты ирования[ | ]

Несмотря на простоту в ировании данных[14], многие считают BER, DER и CER неэффективными по сравнению с другими правилами ирования, так как, во-первых, размер результата ирования данных при помощи BER зачастую получается больше, чем при использовании его альтернатив, а во-вторых, само ирование занимает несколько больше времени[7].

Такими схемами ирования данных, разработанными для улучшения BER[6], являются Packed Encoding Rules (PER), XML Encoding Rules (XER) и ASN.1 SOAP, описанные соответственно в ITU-T X.691, X.693 и в X.892.

См. также[ | ]

ASN.1

Примечания[ | ]

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

Литература[ | ]

  1. Douglas Steedman, E4. Encoding Rules.
  2. Introduction to ASN.1 (англ.). ASN.1 Project. ITU-T. Дата обращения: 12 декабря 2012.
  3. Семенов Ю.А. 4.4.13.2 Нотация ASN.1. (недоступная ссылка)
  4. Юрий Строжевский, 2012, Глава 1.
  5. Bernett et al, 2001, Appendix B.
  6. 1 2 3 Douglas Steedman, E.1 What is ASN.1?.
  7. 1 2 Lin Huai-An Estimation of the Optimal Performance of ASN.1/BER Transfer Syntax. — ACM Computer Communication Review, July 93, С. 45 - 58.
  8. ITU-T Rec. X.690, ISO/IEC 8825-1, Introduction.
  9. Tony Bradley. Microsoft ASN.1 Vulnerability - What's The Big Deal? (англ.). About.com Guide (February 12, 2004). Дата обращения: 11 декабря 2012. Архивировано 25 января 2013 года.
  10. 1 2 Changing from ASN.1:1988/1990 to ASN.1:2008 (англ.). ASN.1 Project. ITU-T (February 12, 2004). Дата обращения: 11 декабря 2012. Архивировано 25 января 2013 года.
  11. Vijay Mukhi, Sonal Kotecha, Arsalan Zaidi, Vinesh Kurup. Basic Encoding Rules (англ.). Дата обращения: 11 декабря 2012. Архивировано 25 января 2013 года.
  12. B. Kaliski. PKCS #7: Cryptographic Message Syntax - Version 1.5 (англ.) (March 1998). — General overview. Дата обращения: 11 декабря 2012. Архивировано 25 января 2013 года.
  13. Peter Gutmann. X.509 Style Guide (англ.) (October 2000). — Introduction. Дата обращения: 11 декабря 2012. Архивировано 25 января 2013 года.
  14. Douglas Steedman, E.4 Encoding Rules.

Источники[ | ]

Ссылки[ | ]