ASN.1

Abstract Syntax Notation One ( ASN.1 ) est un langage de description d'interface (IDL) standard permettant de définir des structures de données pouvant être sérialisées et désérialisées de manière multiplateforme. Il est largement utilisé dans les télécommunications et les réseaux informatiques , et notamment dans la cryptographie .

Les développeurs de protocoles définissent les structures de données dans des modules ASN.1, qui sont généralement une section d'un document de normes plus vaste écrit dans le langage ASN.1. L'avantage est que la description ASN.1 du codage des données est indépendante d'un ordinateur ou d'un langage de programmation particulier. Comme ASN.1 est à la fois lisible par l'homme et par la machine , un compilateur ASN.1 peut compiler des modules dans des bibliothèques de code, des codecs , qui décodent ou codent les structures de données. Certains compilateurs ASN.1 peuvent produire du code pour coder ou décoder plusieurs codages, par exemple compressés, BER ou XML .

ASN.1 est une norme commune du Secteur de la normalisation des télécommunications de l'Union internationale des télécommunications (UIT-T) au sein du Groupe d'études 17 de l'UIT-T et de l'Organisation internationale de normalisation / Commission électrotechnique internationale (ISO/CEI), initialement définie en 1984 dans le cadre de la norme CCITT X.409:1984. En 1988, ASN.1 a évolué vers sa propre norme, X.208 , en raison de sa large applicabilité. La version 1995, considérablement révisée, est couverte par la série X.680 . La dernière révision de la série de recommandations X.680 est l'édition 6.0, publiée en 2021.

ASN.1 est une notation de déclaration de type de données. Elle ne définit pas comment manipuler une variable d'un tel type. La manipulation des variables est définie dans d'autres langages tels que SDL (Specification and Description Language) pour la modélisation exécutable ou TTCN-3 (Testing and Test Control Notation) pour les tests de conformité. Ces deux langages prennent en charge nativement les déclarations ASN.1. Il est possible d'importer un module ASN.1 et de déclarer une variable de n'importe quel type ASN.1 déclaré dans le module.

ASN.1 est utilisé pour définir un grand nombre de protocoles. Ses utilisations les plus répandues restent les télécommunications, la cryptographie et la biométrie.

ASN.1 est étroitement associé à un ensemble de règles de codage qui spécifient comment représenter une structure de données sous la forme d'une série d'octets. Les règles de codage ASN.1 standard incluent :

Les recommandations ASN.1 fournissent un certain nombre de règles de codage prédéfinies. Si aucune des règles de codage existantes ne convient, la notation de contrôle de codage (ECN) permet à l'utilisateur de définir ses propres règles de codage personnalisées.

Le codage Privacy-Enhanced Mail (PEM) n'a aucun rapport avec ASN.1 et ses codecs, mais les données ASN.1 codées, qui sont souvent binaires, sont souvent codées PEM afin de pouvoir être transmises sous forme de données textuelles, par exemple via des relais SMTP ou via des tampons copier/coller.

Il s'agit d'un exemple de module ASN.1 définissant les messages (structures de données) d'un protocole Foo fictif :

FooProtocol DÉFINITIONS ::= BEGIN
FooQuestion ::= SEQUENCE { trackingNumber INTEGER , question IA5String }
FooAnswer ::= SEQUENCE { questionNumber ENTIER , réponse BOOLÉEN }
FIN

Il pourrait s'agir d'une spécification publiée par les créateurs du protocole Foo. Les flux de conversation, les échanges de transactions et les états ne sont pas définis dans ASN.1, mais sont laissés à d'autres notations et à la description textuelle du protocole.

En supposant un message conforme au protocole Foo et qui sera envoyé au destinataire, ce message particulier ( unité de données de protocole (PDU)) est :

maQuestion FooQuestion ::= { trackingNumber 5 , question "Quelqu'un là-bas ?" }

ASN.1 prend en charge les contraintes sur les valeurs et les tailles, ainsi que l'extensibilité. La spécification ci-dessus peut être modifiée pour

FooProtocol DÉFINITIONS ::= BEGIN
FooQuestion ::= SEQUENCE { trackingNumber INTEGER ( 0. . 199 ), question IA5String }
FooAnswer ::= SEQUENCE { questionNumber ENTIER ( 10. . 20 ), réponse BOOLÉEN }
FooHistory ::= SEQUENCE { questions SEQUENCE ( TAILLE ( 0. . 10 )) DE FooQuestion , réponses SEQUENCE ( TAILLE ( 1. . 10 )) DE FooAnswer , anArray SEQUENCE ( TAILLE ( 100 )) DE INTEGER ( 0. . 1000 ), ... }
FIN

Cette modification contraint trackingNumbers à avoir une valeur comprise entre 0 et 199 inclus, et questionNumbers à avoir une valeur comprise entre 10 et 20 inclus. La taille du tableau questions peut être comprise entre 0 et 10 éléments, avec le tableau answers entre 1 et 10 éléments. Le champ anArray est un tableau de 100 éléments de longueur fixe d'entiers qui doivent être compris entre 0 et 1000. Le marqueur d'extensibilité '...' signifie que la spécification du message FooHistory peut avoir des champs supplémentaires dans les futures versions de la spécification ; les systèmes conformes à une version devraient pouvoir recevoir et transmettre des transactions d'une version ultérieure, bien qu'ils ne puissent traiter que les champs spécifiés dans la version antérieure. Les bons compilateurs ASN.1 généreront (en C, C++, Java, etc.) un code source qui vérifiera automatiquement que les transactions respectent ces contraintes. Les transactions qui enfreignent les contraintes ne doivent pas être acceptées par l'application ni présentées à celle-ci. La gestion des contraintes dans cette couche simplifie considérablement la spécification du protocole car les applications seront protégées contre les violations de contraintes, réduisant ainsi les risques et les coûts.

Pour envoyer le message myQuestion via le réseau, le message est sérialisé (codé) sous forme d'une série d' octets à l'aide de l'une des règles de codage . La spécification du protocole Foo doit nommer explicitement un ensemble de règles de codage à utiliser, afin que les utilisateurs du protocole Foo sachent lesquelles utiliser et attendre.

Vous trouverez ci-dessous la structure de données présentée ci-dessus sous la forme myQuestion codée au format DER (tous les nombres sont en hexadécimal) :

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

DER est un codage type–longueur–valeur , donc la séquence ci-dessus peut être interprétée, en référence aux types standard SEQUENCE, INTEGER et IA5String, comme suit :

30 — balise de type indiquant la SÉQUENCE 13 — longueur en octets de la valeur qui suit 02 — balise de type indiquant INTEGER 01 — longueur en octets de la valeur qui suit 05 — valeur (5) 16 — balise de type indiquant IA5String (IA5 signifie l'ensemble complet ISO 646 7 bits, y compris les variantes, mais est généralement US-ASCII) 0e — longueur en octets de la valeur qui suit 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f — valeur (« Quelqu'un là-bas ? ») 

Il est également possible de coder la même structure de données ASN.1 avec les règles de codage XML (XER) pour obtenir une meilleure lisibilité humaine « sur le réseau ». Elle apparaîtrait alors sous la forme des 108 octets suivants (le nombre d'espaces inclut les espaces utilisés pour l'indentation) :

<FooQuestion> 
<trackingNumber> 5 </trackingNumber> <question> Quelqu'un est là ? </question> </FooQuestion>

Alternativement, si des règles de codage compressées sont utilisées, les 122 bits suivants (16 octets équivalent à 128 bits, mais ici, seuls 122 bits transportent des informations et les 6 derniers bits ne sont que du remplissage) seront produits :

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

Dans ce format, les balises de type des éléments requis ne sont pas codées, elles ne peuvent donc pas être analysées sans connaître les schémas attendus utilisés pour le codage. De plus, les octets de la valeur de l'IA5String sont compressés en utilisant des unités de 7 bits au lieu d'unités de 8 bits, car l'encodeur sait que le codage d'une valeur d'octet IA5String ne nécessite que 7 bits. Cependant, les octets de longueur sont toujours codés ici, même pour la première balise d'entier 01 (mais un packer PER pourrait également l'omettre s'il sait que la plage de valeurs autorisée tient sur 8 bits, et il pourrait même compacter l'octet de valeur unique 05 avec moins de 8 bits, s'il sait que les valeurs autorisées ne peuvent tenir que dans une plage plus petite).

Les 6 derniers bits du PER codé sont complétés par des bits nuls dans les 6 bits les moins significatifs du dernier octet c0 : ces bits supplémentaires ne peuvent pas être transmis ou utilisés pour encoder autre chose si cette séquence est insérée dans le cadre d'une séquence PER non alignée plus longue.

Cela signifie que les données PER non alignées sont essentiellement un flux ordonné de bits, et non un flux ordonné d'octets comme avec les données PER alignées, et qu'il sera un peu plus complexe à décoder par logiciel sur les processeurs habituels car cela nécessitera un décalage et un masquage contextuels supplémentaires des bits et non un adressage direct des octets (mais la même remarque serait vraie avec les processeurs modernes et les unités de mémoire/stockage dont l'unité adressable minimale est supérieure à 1 octet). Cependant, les processeurs et processeurs de signal modernes incluent un support matériel pour le décodage interne rapide des flux de bits avec une gestion automatique des unités de calcul qui franchissent les limites des unités de stockage adressables (ceci est nécessaire pour un traitement efficace dans les codecs de données pour la compression/décompression ou avec certains algorithmes de chiffrement/déchiffrement).

Si l'alignement sur les limites d'octets était requis, un encodeur PER aligné produirait :

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

(dans ce cas, chaque octet est complété individuellement avec des bits nuls sur leurs bits les plus significatifs inutilisés).

La plupart des outils prenant en charge ASN.1 effectuent les opérations suivantes :

• analyser les fichiers ASN.1,
• génère la déclaration équivalente dans un langage de programmation (comme C ou C++),
• génère les fonctions d'encodage et de décodage basées sur les déclarations précédentes.

Une liste des outils prenant en charge ASN.1 est disponible sur la page Web des outils de l'UIT-T.

• Jeu ASN1
• Outil Web ASN1 (très limité)
• Aire de jeux ASN1 (bac à sable)
• Décodeur JavaScript ASN.1

ASN.1 est similaire dans son objectif et son utilisation à Google Protocol Buffers et Apache Thrift , qui sont également des langages de description d'interface pour la sérialisation de données multiplateformes. Comme ces langages, il possède un schéma (appelé « module » dans ASN.1) et un ensemble d'encodages, généralement des encodages type-longueur-valeur. Contrairement à eux, ASN.1 ne fournit pas d'implémentation open source unique et facilement utilisable, et est publié sous forme de spécification à implémenter par des fournisseurs tiers. Cependant, ASN.1, défini en 1984, les précède de plusieurs années. Il comprend également une plus grande variété de types de données de base, dont certains sont obsolètes, et offre davantage d'options d'extensibilité. Un seul message ASN.1 peut inclure des données provenant de plusieurs modules définis dans plusieurs normes, même des normes définies à des années d'intervalle.

ASN.1 inclut également une prise en charge intégrée des contraintes sur les valeurs et les tailles. Par exemple, un module peut spécifier un champ entier qui doit être compris entre 0 et 100. La longueur d'une séquence de valeurs (un tableau) peut également être spécifiée, soit sous la forme d'une longueur fixe, soit sous la forme d'une plage de longueurs autorisées. Les contraintes peuvent également être spécifiées sous la forme de combinaisons logiques d'ensembles de contraintes de base.

Les valeurs utilisées comme contraintes peuvent être des littéraux utilisés dans la spécification PDU ou des valeurs ASN.1 spécifiées ailleurs dans le fichier de schéma. Certains outils ASN.1 mettront ces valeurs ASN.1 à la disposition des programmeurs dans le code source généré. Utilisées comme constantes pour le protocole en cours de définition, les développeurs peuvent les utiliser dans l'implémentation logique du protocole. Ainsi, toutes les PDU et les constantes de protocole peuvent être définies dans le schéma, et toutes les implémentations du protocole dans n'importe quel langage pris en charge s'appuient sur ces valeurs. Cela évite aux développeurs d'avoir à coder manuellement les constantes de protocole dans le code source de leur implémentation. Cela facilite considérablement le développement du protocole ; les constantes du protocole peuvent être modifiées dans le schéma ASN.1 et toutes les implémentations sont mises à jour simplement par recompilation, favorisant un cycle de développement rapide et à faible risque.

Si les outils ASN.1 implémentent correctement la vérification des contraintes dans le code source généré, cela permet de valider automatiquement les données du protocole pendant le fonctionnement du programme. En général, les outils ASN.1 incluent la vérification des contraintes dans les routines de sérialisation/désérialisation générées, ce qui génère des erreurs ou des exceptions si des données hors limites sont rencontrées. Il est complexe d'implémenter tous les aspects des contraintes ASN.1 dans un compilateur ASN.1. Tous les outils ne prennent pas en charge l'ensemble des expressions de contraintes possibles. Les schémas XML et JSON prennent tous deux en charge des concepts de contraintes similaires. La prise en charge des contraintes par les outils varie. Le compilateur xsd.exe de Microsoft les ignore.

ASN.1 est visuellement similaire à la forme ABNF (Augmented Backus-Naur form ), qui est utilisée pour définir de nombreux protocoles Internet comme HTTP et SMTP . Cependant, dans la pratique, ils sont assez différents : ASN.1 définit une structure de données, qui peut être codée de diverses manières (par exemple JSON, XML, binaire). ABNF, d'autre part, définit le codage (« syntaxe ») en même temps qu'il définit la structure de données (« sémantique »). ABNF a tendance à être utilisé plus fréquemment pour définir des protocoles textuels lisibles par l'homme, et n'est généralement pas utilisé pour définir des codages type–longueur–valeur.

De nombreux langages de programmation définissent des formats de sérialisation spécifiques au langage. Par exemple, le module « pickle » de Python et le module « Marshal » de Ruby. Ces formats sont généralement spécifiques au langage. Ils ne nécessitent pas non plus de schéma, ce qui les rend plus faciles à utiliser dans les scénarios de stockage ad hoc, mais inappropriés pour les protocoles de communication.

De même, JSON et XML ne nécessitent pas de schéma, ce qui les rend faciles à utiliser. Ce sont également deux normes multiplateformes largement répandues pour les protocoles de communication, en particulier lorsqu'elles sont combinées à un schéma JSON ou XML .

Certains outils ASN.1 sont capables de traduire entre ASN.1 et un schéma XML (XSD). La traduction est normalisée par l'UIT. Cela permet de définir un protocole en ASN.1, et également automatiquement en XSD. Ainsi, il est possible (bien que peut-être peu judicieux) d'avoir dans un projet un schéma XSD compilé par des outils ASN.1 produisant un code source qui sérialise des objets vers/depuis le format de fil JSON. Une utilisation plus pratique consiste à permettre à d'autres sous-projets d'utiliser un schéma XSD au lieu d'un schéma ASN.1, en fonction peut-être de la disponibilité des outils pour le langage choisi par les sous-projets, avec XER utilisé comme format de fil de protocole.

Pour plus de détails, voir Comparaison des formats de sérialisation des données .