ASN.1

Абстрактная синтаксическая нотация One(ASN.1) - это стандартный язык описания интерфейса для определения структур данных, которые можно сериализовать и десериализовать кроссплатформенным способом. Он широко используется в телекоммуникациях и компьютерных сетях, и особенно в криптографии.

Разработчики протоколов определяют структуры данных в модулях ASN.1, которые обычно являются разделом документ более широкого стандарта, написанный на языке ASN.1. Преимущество состоит в том, что описание кодировки данных ASN.1 не зависит от конкретного компьютера или языка программирования (кроме ASN.1). Поскольку ASN.1 является как человеком, так и машиночитаемым, компилятор ASN.1 может компилировать модули в библиотеки кода, кодеки, которые декодируют или кодируют структуры данных. Некоторые компиляторы ASN.1 могут создавать код для кодирования или декодирования нескольких кодировок, например упакованный, BER или XML.

ASN.1 является объединенным стандартом Международного союза электросвязи Сектора стандартизации электросвязи (ITU-T ) в и ISO / IEC, первоначально определенный в 1984 году как часть CCITT X.409: 1984. В 1988 году ASN.1 перешла на собственный стандарт X.208 из-за широкой применимости. Существенно переработанная версия 1995 года входит в серию X.680. Последней версией серии рекомендаций X.680 является версия 5.0, опубликованная в 2015 году.

• 1 Поддержка языка
• 2 Приложения
• 3 Кодировки
  • 3.1 Нотация управления кодированием
  • 3.2 Связь с кодированием почты с улучшенной конфиденциальностью (PEM)
• 4 Пример
  • 4.1 Пример, закодированный в DER
  • 4.2 Пример, закодированный в XER
  • 4.3 Пример, закодированный в PER (невыровненный)
• 5 Инструменты
• 6 Сравнение с аналогичными схемами
• 7 Ссылки
• 8 См. Также
• 9 Внешние ссылки

ASN.1 - это обозначение объявления типа данных. Он не определяет, как управлять переменной такого типа. Управление переменными определяется на других языках, таких как SDL (язык спецификации и описания) для исполняемого моделирования или TTCN-3 (нотация тестирования и управления тестированием) для тестирования на соответствие. Оба этих языка изначально поддерживают объявления ASN.1. Можно импортировать модуль ASN.1 и объявить переменную любого из типов ASN.1, объявленных в модуле.

ASN.1 используется для определения большого количества протоколов. Его наиболее распространенными областями применения по-прежнему являются телекоммуникации, криптография и биометрия.

ASN.1 тесно связан с набор правил кодирования, которые определяют, как представить структуру данных в виде серии байтов. Стандартные правила кодирования ASN.1 включают:

Нотация управления кодированием

Рекомендации ASN.1 предоставляют ряд предопределенных правил кодирования. Если ни одно из существующих правил кодирования не подходит, нотация управления кодированием (ECN) предоставляет пользователю возможность определить свои собственные настраиваемые правила кодирования.

Связь с кодировкой почты с улучшенной конфиденциальностью (PEM)

Кодировка почты с расширенной конфиденциальностью (PEM) полностью не связана с ASN.1 и его кодеками, однако, кодированные данные ASN.1 (которые часто является двоичным) часто кодируется PEM. Это может помочь с транспортировкой по носителям, чувствительным к текстовому кодированию, таким как реле SMTP, а также копированию и вставке.

Это пример модуля ASN.1, определяющего сообщения (структуры данных) фиктивного протокола Foo :

FooProtocol ОПРЕДЕЛЕНИЯ :: = BEGIN FooQuestion :: = SEQUENCE {trackingNumber INTEGER, вопрос IA5String} FooAnswer :: = SEQUENCE {questionNumber INTEGER, answer BOOLEAN} END

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

Предполагая, что сообщение соответствует протоколу Foo и будет отправлено принимающей стороне, это конкретное сообщение (блок данных протокола (PDU)):

myQuestion FooQuestion :: = {trackingNumber 5, вопрос "Есть кто-нибудь?" }

ASN.1 поддерживает ограничения значений и размеров, а также расширяемость. Вышеуказанная спецификация может быть изменена на

FooProtocol DEFINITIONS :: = BEGIN FooQuestion :: = SEQUENCE {trackingNumber INTEGER (0..199), question IA5String} FooAnswer :: = SEQUENCE {questionNumber INTEGER (10..20 ), answer BOOLEAN} FooHistory :: = SEQUENCE {вопросы SEQUENCE (SIZE (0..10)) OF FooQuestion, ответы SEQUENCE (SIZE (1..10)) OF FooAnswer, anArray SEQUENCE (SIZE (100)) INTEGER ( 0..1000),...} END

Это изменение ограничивает значение trackingNumbers от 0 до 199 включительно, а questionNumbers - значение от 10 до 20 включительно. Размер массива вопросов может составлять от 0 до 10 элементов, а массива ответов от 1 до 10 элементов. Поле anArray представляет собой массив целых чисел фиксированной длины из 100 элементов, который должен находиться в диапазоне от 0 до 1000. Маркер расширяемости '...' означает, что спецификация сообщения FooHistory может иметь дополнительные поля в будущих версиях спецификации; системы, совместимые с одной версией, должны иметь возможность получать и передавать транзакции из более поздней версии, хотя и способны обрабатывать только поля, указанные в более ранней версии. Хорошие компиляторы ASN.1 сгенерируют (на C, C ++, Java и т. Д.) Исходный код, который автоматически проверяет соответствие транзакций этим ограничениям. Транзакции, которые нарушают ограничения, не должны приниматься из приложения или передаваться в него. Управление ограничениями на этом уровне значительно упрощает спецификацию протокола, поскольку приложения будут защищены от нарушения ограничений, что снизит риск и стоимость.

Чтобы отправить сообщение myQuestion по сети, сообщение сериализуется (кодируется) как последовательность байтов с использованием одного из правил кодирования. Спецификация протокола Foo должна явно указывать один набор правил кодирования для использования, чтобы пользователи протокола Foo знали, какое из них им следует использовать и ожидать.

Пример, закодированный в DER

Ниже приведена структура данных, показанная выше, закодированная в формате DER (все числа в шестнадцатеричном формате):

30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

DER - это кодирование тип-длина-значение, поэтому приведенная выше последовательность может быть интерпретирована со ссылкой на стандартную ПОСЛЕДОВАТЕЛЬНОСТЬ, ЦЕЛОЕ , и IA5String, как показано ниже:

30 - тип тега, указывающий SEQUENCE 13 - длина в октетах значения, следующего за 02 - тег типа, указывающий INTEGER 01 - длина в октетах значения, следующего за 05 - значение (5) 16 - тег типа, указывающий IA5String (IA5 означает полный 7-битный набор ISO 646, включая варианты, но обычно это US-ASCII) 0e - длина в октетах значения, следующего за 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f - значение ("Есть кто-нибудь?")

Пример, закодированный в XER

В качестве альтернативы, можно закодировать ту же структуру данных ASN.1 с помощью Правила кодирования XML (XER) для повышения удобства чтения человеком » r проволока ". Тогда он будет выглядеть как следующие 108 октетов (количество пробелов включает пробелы, используемые для отступов):

5Есть кто-нибудь?

Пример, закодированный в PER (без выравнивания)

В качестве альтернативы, если Упаковано Если используются правила кодирования, будут созданы следующие 122 бита (16 октетов составляют 128 бит, но здесь только 122 бита несут информацию, а последние 6 бит являются просто заполнением):

01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 2f 2c af c0

В этом формате теги типов для требуемых элементов не кодируются, поэтому его нельзя проанализировать, не зная ожидаемых схем, используемых для кодирования. Кроме того, байты для значения IA5String упаковываются с использованием 7-битных единиц вместо 8-битных единиц, поскольку кодировщик знает, что для кодирования байтового значения IA5String требуется только 7 бит. Однако байты длины здесь по-прежнему закодированы, даже для первого целочисленного тега 01 (но упаковщик PER также может пропустить его, если он знает, что допустимый диапазон значений умещается на 8 битах, и он может даже сжать один байт значения 05 с меньшим чем 8 бит, если он знает, что допустимые значения могут соответствовать только меньшему диапазону).

Последние 6 бит в закодированном PER дополняются нулевыми битами в 6 младших значащих битах последнего байта c0: эти дополнительные биты не могут быть переданы или использованы для кодирования чего-либо еще, если эта последовательность вставлена ​​как часть более длинной невыровненной последовательности PER.

Это означает, что невыровненные данные PER по сути являются упорядоченным потоком битов, а не упорядоченным потоком байтов, как при выровненном PER, и что их будет немного сложнее декодировать программным обеспечением на обычных процессорах, потому что это потребует дополнительного контекстного битового сдвига и маскирования, а не прямой байтовой адресации (но то же самое замечание будет справедливо для современных процессоров и модулей памяти / хранения, минимальная адресуемая единица которых превышает 1 октет). Однако современные процессоры и сигнальные процессоры включают аппаратную поддержку быстрого внутреннего декодирования битовых потоков с автоматической обработкой вычислительных блоков, которые пересекают границы адресных блоков хранения (это необходимо для эффективной обработки данных в кодеках для сжатия / распаковки или с некоторым шифрованием / алгоритмы дешифрования).

Если требуется выравнивание границ октетов, выровненный кодер PER выдаст:

01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

(в этом случае каждый октет отдельно заполняется нулевыми битами на неиспользуемых наиболее значимых битах).

Большинство инструментов, поддерживающих ASN.1, делают следующее:

• анализируют файлы ASN.1,
• генерируют эквивалентное объявление на языке программирования ( как C или C ++),
• генерирует функции кодирования и декодирования на основе предыдущих объявлений.

Список инструментов, поддерживающих ASN.1, можно найти на веб-странице ITU-T Tool.

ASN.1 аналогичен по назначению и использованию с буферами протокола и Apache Thrift, которые также являются языками описания интерфейсов для кросс-платформенных сериализация данных. Подобно этим языкам, он имеет схему (в ASN.1, называемую «модулем») и набор кодировок, обычно кодировок типа-длины-значения. Однако ASN.1, определенный в 1984 году, на много лет предшествует им. Он также включает более широкий спектр основных типов данных, некоторые из которых устарели, и имеет больше возможностей для расширения. Одно сообщение ASN.1 может включать данные из нескольких модулей, определенных в нескольких стандартах, даже стандартах, определенных с разницей в годы.

ASN.1 также включает встроенную поддержку ограничений на значения и размеры. Например, модуль может указывать целочисленное поле, которое должно находиться в диапазоне от 0 до 100. Длина последовательности значений (массива) также может быть указана либо как фиксированная длина, либо как диапазон разрешенных длин. Ограничения также могут быть указаны как логические комбинации наборов основных ограничений.

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

Если инструменты ASN.1 правильно реализуют проверку ограничений в сгенерированном исходном коде, это действует для автоматической проверки данных протокола во время работы программы. Как правило, инструменты ASN.1 включают проверку ограничений в сгенерированных процедурах сериализации / десериализации, вызывая ошибки или исключения, если встречаются данные, выходящие за границы. Сложно реализовать все аспекты ограничений ASN.1 в компиляторе ASN.1. Не все инструменты поддерживают полный набор возможных выражений ограничений. Схема XML и схема JSON поддерживают аналогичные концепции ограничений. Инструментальная поддержка ограничений в них различается. Компилятор Microsoft xsd.exe игнорирует их.

ASN.1 визуально похож на расширенную форму Бэкуса-Наура (ABNF), которая используется для определения многих интернет-протоколов, таких как HTTP и SMTP. Однако на практике они совершенно разные: ASN.1 определяет структуру данных, которая может быть закодирована различными способами (например, JSON, XML, двоичный). ABNF, с другой стороны, определяет кодировку («синтаксис»), в то же время он определяет структуру данных («семантику»). ABNF, как правило, чаще используется для определения текстовых, удобочитаемых протоколов и обычно не используется для определения кодировок типа длина-значение.

Многие языки программирования определяют специфичные для языка форматы сериализации. Например, модуль Python «pickle» и модуль Ruby «Marshal». Эти форматы обычно зависят от языка. Им также не требуется схема, что упрощает их использование в сценариях специального хранения, но не подходит для протоколов связи.

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

. Некоторые инструменты ASN.1 могут выполнять перевод между Схема ASN.1 и XML (XSD). Перевод стандартизирован ITU. Это позволяет определять протокол в ASN.1, а также автоматически в XSD. Таким образом, возможно (хотя, возможно, и не рекомендуется) иметь в проекте схему XSD, компилируемую инструментами ASN.1, производящими исходный код, который сериализует объекты в / из формата JSON. Более практическое использование состоит в том, чтобы разрешить другим подпроектам использовать схему XSD вместо схемы ASN.1, возможно, с учетом доступности инструментов для выбранного языка подпроектов, с XER, используемым в качестве формата передачи протокола.

Подробнее см. Сравнение форматов сериализации данных.

• X.690
• Класс информационных объектов (ASN.1)

• Руководство для неспециалистов по подмножеству ASN.1, BER и DER Хорошее введение для новичков
• Веб-сайт ITU-T - Введение в ASN.1
• Видео-введение в ASN.1
• Учебник по ASN.1 Учебник по основным концепциям ASN.1
• Учебник по ASN.1 Учебник по ASN.1
• Компилятор ASN.1->C ++ с открытым исходным кодом; Включает некоторые спецификации ASN.1., Онлайн-компилятор ASN.1->C ++
• Декодер ASN.1 Позволяет декодировать сообщения, закодированные в ASN.1, в вывод XML.
• ASN.1 средство проверки синтаксиса и кодировщик / декодер Проверяет синтаксис схемы ASN.1 и кодирует / декодирует сообщения.
• Кодер / декодер ASN.1 сообщений 3GPP Кодирует / декодирует сообщения ASN.1 3GPP и позволяет легко редактировать эти сообщения.
• Бесплатные книги по ASN.1
• Список инструментов ASN.1 в проекте IvmaiAsn
• Обзор правил кодирования октетов (OER)
• Обзор правил кодирования JSON ( JER)