De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda

Abstract Syntax Notation One ( ASN.1 ) es un lenguaje de descripción de interfaz estándar para definir estructuras de datos que se pueden serializar y deserializar de manera multiplataforma. Se utiliza ampliamente en telecomunicaciones y redes informáticas , y especialmente en criptografía . [1]

Los desarrolladores de protocolos definen las estructuras de datos en los 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 por humanos y por máquina, un compilador de ASN.1 puede compilar módulos en bibliotecas de código, códecs , que decodifican o codifican las estructuras de datos. Algunos compiladores de ASN.1 pueden producir código para codificar o decodificar varias codificaciones, por ejemplo, empaquetado, BER o XML .

ASN.1 es una norma conjunta del Sector de Normalización de Telecomunicaciones de la Unión Internacional de Telecomunicaciones ( UIT-T ) en la Comisión de Estudio 17 del UIT-T e ISO / IEC , originalmente definida en 1984 como parte de CCITT X.409: 1984. [2] En 1988, ASN.1 pasó a su propio estándar, X.208 , debido a su amplia aplicabilidad. La versión de 1995 sustancialmente revisada está cubierta por la serie X.680 . [3] La última revisión de la serie de recomendaciones X.680 es la Edición 5.0, publicada en 2015.

Soporte de idiomas [ editar ]

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

Aplicaciones [ editar ]

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

Codificaciones [ editar ]

ASN.1 está estrechamente asociado 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 estándar ASN.1 incluyen:

Notación de control de codificación [ editar ]

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 el usuario defina sus propias reglas de codificación personalizadas.

Relación con la codificación del correo con privacidad mejorada (PEM) [ editar ]

La codificación del correo con privacidad mejorada (PEM) no está relacionada en absoluto con ASN.1 y sus códecs, sin embargo, los datos ASN.1 codificados (que a menudo son binarios) suelen estar codificados con PEM. Esto puede ayudar con el transporte a través de medios sensibles a la codificación textual, como retransmisiones SMTP, así como con la copia y el pegado.

Ejemplo [ editar ]

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 :: = SECUENCIA { trackingNumber INTEGER, pregunta IA5String } FooAnswer :: = SECUENCIA { questionNumber INTEGER, responder BOOLEAN }FINAL

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.

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

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

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

FooProtocol DEFINICIONES :: = BEGIN FooQuestion :: = SECUENCIA { trackingNumber INTEGER (0..199), pregunta IA5String } FooAnswer :: = SECUENCIA { questionNumber INTEGER (10..20), responder BOOLEAN } FooHistory :: = SECUENCIA { preguntas SECUENCIA (TAMAÑO (0..10)) DE FooQuestion, responde SECUENCIA (TAMAÑO (1..10)) DE FooAnswer, anArray SECUENCIA (TAMAÑO (100)) DE INTEGER (0..1000), ... }FINAL

Este cambio obliga a trackingNumbers a tener un valor entre 0 y 199 inclusive, y questionNumbers a 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 marcador de extensibilidad '...' significa que la especificación del mensaje FooHistory puede tener campos adicionales en versiones futuras de la especificación; Los sistemas compatibles con una versión deberían poder recibir y transmitir transacciones desde una versión posterior, aunque solo pueden procesar los campos especificados en la versión anterior. Los buenos compiladores de ASN.1 generarán (en C, C ++, Java, etc.) código fuente que verificará automáticamente que las transacciones se encuentren dentro de 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 del protocolo porque las aplicaciones estarán protegidas de 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 utilizando 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 [ editar ]

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

30 13 02 01 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 - etiqueta de tipo que indica SECUENCIA13 - longitud en octetos del valor que sigue 02 - etiqueta de tipo que indica INTEGER 01 - longitud en octetos del valor que sigue 05 - valor (5) 16 - tipo de etiqueta que indica IA5String  (IA5 significa el conjunto completo de ISO 646 de 7 bits, incluidas las variantes,  pero generalmente es US-ASCII) 0e - longitud en octetos del valor que sigue 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f - valor ("¿Hay alguien ahí?")

Ejemplo codificado en XER [ editar ]

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

<FooQuestion>  <trackingNumber> 5 </trackingNumber>  <question> ¿Hay alguien ahí? </question> </FooQuestion>

Ejemplo codificado en PER (no alineado) [ editar ]

Alternativamente, si se emplean reglas de codificación empaquetadas , se producirán los siguientes 122 bits (16 octetos equivalen a 128 bits, pero aquí solo 122 bits transportan 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 usando unidades de 7 bits en lugar de unidades de 8 bits, porque el codificador sabe que codificar un valor de byte IA5String requiere solo 7 bits. Sin embargo, los bytes de longitud todavía están codificados aquí, incluso para la primera etiqueta de número entero 01 (pero un empaquetador PER también podría omitirlo si sabe que el rango de valor 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 pueden no transmitirse ni usarse para codificar otra cosa si esta secuencia se inserta como parte de una secuencia no alineada más larga. POR secuencia.

Esto significa que los datos PER no alineados son esencialmente un flujo ordenado de bits, y no un flujo ordenado de bytes como con PER alineado, y que será un poco más complejo de decodificar por software en procesadores habituales porque requerirá bits contextuales adicionales. desplazamiento y enmascaramiento y no direccionamiento de bytes directo (pero la misma observación sería cierta con procesadores modernos y unidades de memoria / almacenamiento cuya unidad mínima direccionable es mayor que 1 octeto). Sin embargo, los procesadores de señal y procesadores modernos incluyen soporte de hardware para 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 algún cifrado / algoritmos de descifrado).

Si se requiriera la alineación en los límites de los 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 [ editar ]

La mayoría de las herramientas que admiten ASN.1 hacen lo siguiente:

  • analizar 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 en base a 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 [ editar ]

  • Herramienta web ASN1 (muy limitada)
  • Zona de juegos ASN1 (caja de arena)

Comparación con esquemas similares [ editar ]

ASN.1 tiene un propósito y uso similar 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, normalmente codificaciones de tipo, longitud y valor.. A diferencia de ellos, ASN.1 no proporciona una implementación de código abierto única y fácilmente utilizable, y se publica como una especificación para ser implementada por terceros. 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. La longitud de una secuencia de valores (una matriz) también se puede especificar, ya sea como una longitud fija o como 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 la PDU o valores ASN.1 especificados en otra parte del archivo de esquema. Algunas herramientas ASN.1 harán que estos valores ASN.1 estén disponibles para 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 lenguaje admitido se basan en esos valores. Esto evita la necesidad de que los desarrolladores utilicen 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 alterar en el esquema ASN.1 y todas las implementaciones se actualizan simplemente volviendo a compilar, 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. Generalmente, las herramientas ASN.1 incluirán la verificación de restricciones en las rutinas de serialización / deserialización generadas, generando errores o excepciones si se encuentran datos fuera de 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 las limitaciones en estos varía. El compilador xsd.exe de Microsoft los ignora.

ASN.1 es visualmente similar al formulario Augmented Backus-Naur (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 (por ejemplo, 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 generalmente 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, el módulo "pickle" de Python y el módulo "Marshal" de Ruby. Por lo general, estos formatos son 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. Sin embargo, ambos son estándares multiplataforma y son muy populares para los protocolos de comunicación, especialmente cuando se combinan con un esquema XML o un esquema JSON .

Algunas herramientas ASN.1 pueden traducir entre ASN.1 y el esquema XML (XSD). La traducción está estandarizada por la UIT. Esto permite definir un protocolo en ASN.1 y también automáticamente en XSD. Por lo tanto, es posible (aunque quizás desaconsejado) tener en un proyecto un esquema XSD compilado por herramientas ASN.1 que produzcan código fuente que serialice objetos hacia / desde formato JSON. Un uso más práctico es permitir que otros subproyectos consuman un esquema XSD en lugar de un esquema ASN.1, quizás adaptando la disponibilidad de herramientas para el lenguaje de subproyectos elegido, con XER utilizado como protocolo de formato de cable.

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

Ver también [ editar ]

  • X.690
  • Clase de objeto de información (ASN.1)
  • Capa de presentación

Referencias [ editar ]

  1. ^ "Introducción a ASN.1" . ITU . Archivado desde el original el 9 de abril de 2021 . Consultado el 9 de abril de 2021 .
  2. ^ "Base de datos de la Recomendación UIT-T" . ITU . Consultado el 6 de marzo de 2017 .
  3. ^ UIT-T X.680 - Especificación de notación básica
  4. ^ UIT-T X.690 - Reglas de codificación básicas (BER)
  5. ^ UIT-T X.690 - Reglas de codificación distinguidas (DER)
  6. ^ UIT-T X.690 - Reglas de codificación canónica (CER)
  7. ^ a b c d ITU-T X.691 - Reglas de codificación empaquetadas (PER)
  8. ^ a b c UIT-T X.693 - Reglas de codificación XML (XER)
  9. ^ a b UIT-T X.696 - Reglas de codificación de octetos (REA)
  10. ^ UIT-T X.697 - Reglas de codificación de notación de objetos JavaScript (JER)
  11. ^ RFC 3641 - Reglas de codificación de cadenas genéricas (GSER) 

Enlaces externos [ editar ]

  • Una guía básica para un subconjunto de ASN.1, BER y DER Una buena introducción para principiantes
  • Sitio web del UIT-T - Introducción a ASN.1
  • Una introducción en video a ASN.1
  • Tutorial de ASN.1 Tutorial sobre conceptos básicos de ASN.1
  • Tutorial Tutorial de ASN.1 en ASN.1
  • Un compilador ASN.1-> C ++ de código abierto; Incluye algunas especificaciones ASN.1. , Un compilador ASN.1-> C ++ en línea
  • Decodificador ASN.1 Permite decodificar mensajes codificados en ASN.1 en salida XML.
  • Comprobador de sintaxis ASN.1 y codificador / decodificador Comprueba la sintaxis de un esquema ASN.1 y codifica / decodifica mensajes.
  • Codificador / decodificador ASN.1 de mensajes 3GPP Codifica / decodifica mensajes ASN.1 3GPP y permite una fácil edición de estos mensajes.
  • Libros gratuitos sobre ASN.1
  • Lista de herramientas ASN.1 en el proyecto IvmaiAsn
  • Descripción general de las reglas de codificación de octetos (REA)
  • Descripción general de las reglas de codificación JSON (JER)
  • Una utilidad de nodo de TypeScript para analizar y validar mensajes ASN.1