ASN.1

Notación de sintaxis abstracta uno (ASN.1) es un lenguaje de descripción de interfaz estándar para definir estructuras de datos que se pueden serializar y deserializar de forma multiplataforma. Se utiliza ampliamente en telecomunicaciones y redes informáticas, y especialmente en criptografía.

Los desarrolladores de protocolos definen estructuras de datos en módulos ASN.1, que generalmente son una sección de un documento de estándares más amplio escrito en el lenguaje ASN.1. La ventaja es que la descripción ASN.1 de la codificación de datos es independiente de una computadora o lenguaje de programación en particular. Debido a que ASN.1 es legible tanto por humanos como por máquinas, un compilador ASN.1 puede compilar módulos en bibliotecas de código, códecs, que decodifican o codifican las estructuras de datos. Algunos compiladores ASN.1 pueden producir código para codificar o decodificar varias codificaciones, p. empaquetado, BER o XML.

ASN.1 es un estándar conjunto del Sector de Normalización de Telecomunicaciones de la Unión Internacional de Telecomunicaciones (ITU-T) en el Grupo de estudio 17 de ITU-T e ISO/IEC, definido originalmente en 1984 como parte de CCITT X.409:1984. En 1988, ASN.1 pasó a su propio estándar, X.208, debido a su amplia aplicabilidad. La versión sustancialmente revisada de 1995 está cubierta por la serie X.680. La última revisión de la serie de recomendaciones X.680 es la edición 6.0, publicada en 2021.

Soporte de idiomas

ASN.1 es una notación de declaración de tipos de datos. No define cómo manipular una variable de este tipo. La manipulación de variables se define en otros lenguajes como SDL (lenguaje de especificación y descripción) para el modelado ejecutable o TTCN-3 (notación de prueba y control de prueba) para la prueba de conformidad. Ambos lenguajes admiten de forma nativa las declaraciones ASN.1. Es posible importar un módulo ASN.1 y declarar una variable de cualquiera de los tipos ASN.1 declarados en el módulo.

Aplicaciones

ASN.1 se utiliza para definir una gran cantidad de protocolos. Sus usos más extensos siguen siendo las telecomunicaciones, la criptografía y la biometría.

Codificaciones

ASN.1 está estrechamente relacionado con un conjunto de reglas de codificación que especifican cómo representar una estructura de datos como una serie de bytes. Las reglas de codificación ASN.1 estándar incluyen:

Notación de control de codificación

Las recomendaciones de ASN.1 proporcionan una serie de reglas de codificación predefinidas. Si ninguna de las reglas de codificación existentes es adecuada, la notación de control de codificación (ECN) proporciona una forma para que un usuario defina sus propias reglas de codificación personalizadas.

Relación con la codificación de correo con privacidad mejorada (PEM)

La codificación de correo con privacidad mejorada (PEM) no tiene ninguna relación con ASN.1 y sus códecs, pero los datos ASN.1 codificados, que a menudo son binarios, suelen estar codificados con PEM para que puedan transmitirse como datos de texto, p. a través de retransmisiones SMTP o a través de búferes de copiar/pegar.

Ejemplo

Este es un módulo ASN.1 de ejemplo que define los mensajes (estructuras de datos) de un protocolo Foo ficticio:

FooProtocol DEFINICIONES::= BEGIN

FooQuestion::= SEQUENCE {
TrackNumber INTEGER,
cuestión IA5String
}

FooAnswer::= SEQUENCE {
cuestión Número INTEGER,
respuesta BOOLEAN
}

FIN

Esta podría ser una especificación publicada por los creadores de Foo Protocol. Los flujos de conversación, los intercambios de transacciones y los estados no se definen en ASN.1, pero se dejan para otras notaciones y descripciones textuales del protocolo.

Asumiendo un mensaje que cumple con el Protocolo Foo y que será enviado a la parte receptora, este mensaje en particular (unidad de datos de protocolo (PDU)) es:

myQuestion FooQuestion::= {}
trackingNumber 5,
pregunta "¿Hay alguien ahí?"
}

ASN.1 admite restricciones en valores y tamaños, y extensibilidad. La especificación anterior se puede cambiar a

FooProtocol DEFINICIONES::= BEGIN

FooQuestion::= SEQUENCE {
trackingNumber INTEGER(0..199),
cuestión IA5String
}

FooAnswer::= SEQUENCE {
cuestión Número INTEGER(10..20),
respuesta BOOLEAN
}

FooHistory::= SEQUENCE {
preguntas SEQUENCE(SIZE(0..10)) OF FooQuestion,
respuestas SEQUENCE(SIZE(1..10)) DE FooAnswer,
anArray SEQUENCE(SIZE(100)) OF INTEGER(0.1000),
...
}

FIN

Este cambio restringe trackingNumbers para tener un valor entre 0 y 199 inclusive, y questionNumbers para tener un valor entre 10 y 20 inclusive. El tamaño de la matriz de preguntas puede estar entre 0 y 10 elementos, con la matriz de respuestas entre 1 y 10 elementos. El campo anArray es una matriz de enteros de 100 elementos de longitud fija que debe estar en el rango de 0 a 1000. El campo '...' el marcador de extensibilidad significa que la especificación del mensaje FooHistory puede tener campos adicionales en futuras versiones de la especificación; los sistemas que cumplen con una versión deben poder recibir y transmitir transacciones de una versión posterior, aunque pueden procesar solo los campos especificados en la versión anterior. Los buenos compiladores ASN.1 generarán (en C, C++, Java, etc.) un código fuente que verificará automáticamente que las transacciones cumplan con estas restricciones. Las transacciones que violen las restricciones no deben aceptarse ni presentarse en la aplicación. La gestión de restricciones en esta capa simplifica significativamente la especificación de protocolos porque las aplicaciones estarán protegidas contra violaciones de restricciones, lo que reduce el riesgo y el costo.

Para enviar el mensaje myQuestion a través de la red, el mensaje se serializa (codifica) como una serie de bytes usando una de las reglas de codificación. La especificación del protocolo Foo debe nombrar explícitamente un conjunto de reglas de codificación para usar, de modo que los usuarios del protocolo Foo sepan cuál deben usar y esperar.

Ejemplo codificado en DER

A continuación se muestra la estructura de datos que se muestra arriba como myQuestion codificada en formato DER (todos los números están en hexadecimal):

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

DER es una codificación de tipo-longitud-valor, por lo que la secuencia anterior se puede interpretar, con referencia a los tipos estándar SEQUENCE, INTEGER e IA5String, de la siguiente manera:

30 — tipo de etiqueta indicando SEQUENCE
13 — longitud en octets de valor que sigue
02 — tipo de etiqueta que indica INTEGER
01 — longitud en octets de valor que sigue
05 - valor (5)
16 — tipo de etiqueta que indica IA5String
(IA5 significa el conjunto completo de 7 bits ISO 646, incluyendo variantes,
pero es generalmente US-ASCII)
0e - longitud en octets de valor que sigue
41 6e 79 62 6f 64 79 20 74 68 65 72 65 65 3f — valor ("Hay alguien allí?")

Ejemplo codificado en XER

Como alternativa, es posible codificar la misma estructura de datos ASN.1 con reglas de codificación XML (XER) para lograr una mayor legibilidad humana "por cable". Entonces aparecería como los siguientes 108 octetos (el recuento de espacios incluye los espacios utilizados para la sangría):

" FooQuestion " IdentificandoNúmero5■/trackingNumber - No.¿Hay alguien ahí?■/pregunta relativa" FooQuestion "

Ejemplo codificado en PER (no alineado)

Alternativamente, si se emplean reglas de codificación empaquetada, se producirán los siguientes 122 bits (16 octetos equivalen a 128 bits, pero aquí solo 122 bits contienen información y los últimos 6 bits son simplemente relleno):

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

En este formato, las etiquetas de tipo para los elementos requeridos no están codificadas, por lo que no se pueden analizar sin conocer los esquemas esperados utilizados para codificar. Además, los bytes para el valor de IA5String se empaquetan utilizando unidades de 7 bits en lugar de unidades de 8 bits, porque el codificador sabe que codificar un valor de byte de IA5String requiere solo 7 bits. Sin embargo, los bytes de longitud todavía están codificados aquí, incluso para la primera etiqueta de entero 01 (pero un empacador PER también podría omitirlo si sabe que el rango de valores permitido se ajusta a 8 bits, e incluso podría compactar el byte de valor único 05 con menos de 8 bits, si sabe que los valores permitidos solo pueden caber en un rango más pequeño).

Los últimos 6 bits del PER codificado se rellenan con bits nulos en los 6 bits menos significativos del último byte c0: estos bits adicionales no se pueden transmitir ni utilizar para codificar otra cosa si esta secuencia se inserta como parte de una secuencia PER no alineada más larga.

Esto significa que los datos PER no alineados son esencialmente un flujo ordenado de bits, y no un flujo ordenado de bytes como con el PER alineado, y que será un poco más complejo de descifrar por software en los procesadores habituales porque requerirá más cambio de bits contextual y enmascaramiento y no direccionamiento directo de bytes (pero la misma observación sería cierta con los procesadores modernos y las unidades de memoria/almacenamiento cuya unidad mínima direccionable es mayor que 1 octeto). Sin embargo, los procesadores modernos y los procesadores de señales incluyen soporte de hardware para una decodificación interna rápida de flujos de bits con manejo automático de unidades informáticas que cruzan los límites de las unidades de almacenamiento direccionables (esto es necesario para un procesamiento eficiente en códecs de datos para compresión/descompresión o con algo de cifrado/ algoritmos de descifrado).

Si se requiriera alineación en los límites de octetos, un codificador PER alineado produciría:

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

(en este caso, cada octeto se rellena individualmente con bits nulos en sus bits más significativos no utilizados).

Herramientas

La mayoría de las herramientas compatibles con ASN.1 hacen lo siguiente:

• parse los archivos ASN.1,
• genera la declaración equivalente en un lenguaje de programación (como C o C++),
• genera las funciones de codificación y decodificación basadas en las declaraciones anteriores.

Puede encontrar una lista de herramientas compatibles con ASN.1 en la página web de la herramienta ITU-T.

Herramientas en línea

• ASN1 Web Tool (muy limitada)
• ASN1 Playground (sandbox)

Comparación con esquemas similares

ASN.1 es similar en propósito y uso a los búferes de protocolo y Apache Thrift, que también son lenguajes de descripción de interfaz para la serialización de datos multiplataforma. Al igual que esos lenguajes, tiene un esquema (en ASN.1, llamado "módulo") y un conjunto de codificaciones, generalmente codificaciones de tipo-longitud-valor. A diferencia de ellos, ASN.1 no proporciona una implementación de código abierto única y fácil de usar, y se publica como una especificación para ser implementada por proveedores externos. Sin embargo, ASN.1, definido en 1984, los precede en muchos años. También incluye una variedad más amplia de tipos de datos básicos, algunos de los cuales están obsoletos, y tiene más opciones de extensibilidad. Un solo mensaje ASN.1 puede incluir datos de múltiples módulos definidos en múltiples estándares, incluso estándares definidos con años de diferencia.

ASN.1 también incluye soporte integrado para restricciones de valores y tamaños. Por ejemplo, un módulo puede especificar un campo entero que debe estar en el rango de 0 a 100. También se puede especificar la longitud de una secuencia de valores (una matriz), ya sea como una longitud fija o un rango de longitudes permitidas. Las restricciones también se pueden especificar como combinaciones lógicas de conjuntos de restricciones básicas.

Los valores utilizados como restricciones pueden ser literales utilizados en la especificación de PDU o valores ASN.1 especificados en otra parte del archivo de esquema. Algunas herramientas ASN.1 pondrán estos valores ASN.1 a disposición de los programadores en el código fuente generado. Usados como constantes para el protocolo que se está definiendo, los desarrolladores pueden usarlos en la implementación lógica del protocolo. Por lo tanto, todas las PDU y las constantes de protocolo se pueden definir en el esquema, y todas las implementaciones del protocolo en cualquier idioma admitido se basan en esos valores. Esto evita la necesidad de que los desarrolladores entreguen constantes de protocolo de código en el código fuente de su implementación. Esto ayuda significativamente al desarrollo del protocolo; las constantes del protocolo se pueden modificar en el esquema ASN.1 y todas las implementaciones se actualizan simplemente recompilando, lo que promueve un ciclo de desarrollo rápido y de bajo riesgo.

Si las herramientas ASN.1 implementan correctamente la verificación de restricciones en el código fuente generado, esto actúa para validar automáticamente los datos del protocolo durante la operación del programa. Por lo general, las herramientas ASN.1 incluirán restricciones para verificar las rutinas de serialización/deserialización generadas, generando errores o excepciones si se encuentran datos fuera de los límites. Es complejo implementar todos los aspectos de las restricciones ASN.1 en un compilador ASN.1. No todas las herramientas admiten la gama completa de posibles expresiones de restricciones. El esquema XML y el esquema JSON admiten conceptos de restricciones similares. El soporte de herramientas para restricciones varía. El compilador xsd.exe de Microsoft los ignora.

ASN.1 es visualmente similar al formulario de Backus-Naur aumentado (ABNF), que se utiliza para definir muchos protocolos de Internet como HTTP y SMTP. Sin embargo, en la práctica son bastante diferentes: ASN.1 define una estructura de datos, que se puede codificar de varias formas (p. ej., JSON, XML, binario). ABNF, por otro lado, define la codificación ("sintaxis") al mismo tiempo que define la estructura de datos ("semántica"). ABNF tiende a usarse con más frecuencia para definir protocolos textuales legibles por humanos y, en general, no se usa para definir codificaciones de tipo-longitud-valor.

Muchos lenguajes de programación definen formatos de serialización específicos del lenguaje. Por ejemplo, Python's "pickle" módulo y Ruby's "Marshal" módulo. Estos formatos son generalmente específicos del idioma. Tampoco requieren un esquema, lo que los hace más fáciles de usar en escenarios de almacenamiento ad hoc, pero inapropiados para los protocolos de comunicaciones.

JSON y XML tampoco requieren un esquema, lo que los hace fáciles de usar. Ambos son también estándares multiplataforma que son muy populares para los protocolos de comunicaciones, especialmente cuando se combinan con un esquema JSON o un esquema XML.

Algunas herramientas ASN.1 pueden traducir entre ASN.1 y el esquema XML (XSD). La traducción está estandarizada por la UIT. Esto hace posible que se defina un protocolo en ASN.1, y también automáticamente en XSD. Por lo tanto, es posible (aunque tal vez desaconsejable) tener en un proyecto un esquema XSD compilado por herramientas ASN.1 que producen código fuente que serializa objetos a/desde formato de cable JSON. Un uso más práctico es permitir que otros subproyectos consuman un esquema XSD en lugar de un esquema ASN.1, tal vez adaptándose a la disponibilidad de herramientas para el idioma de elección de los subproyectos, con XER utilizado como formato de cable de protocolo.

Para obtener más detalles, consulte Comparación de formatos de serialización de datos.