Tipo de BITSTRING encapsulado ASN.1 en openSSL

3

Actualmente estoy creando un analizador ASN.1 que se supone que decodifica los certificados X.509v3 y los archivos de época en formato ASN.1 DER. El analizador está funcionando bien, aparte de un problema que parece que no pude entender. Si descifro el formato DER, veo que para la clave pública se usa la siguiente forma de BITSTRING:

 BIT STRING, **encapsulates** {

 SEQUENCE {

 INTEGER

     // public key hex string

pero cuando miro la firma, veo que está representada con BITSTRING sin la etiqueta encapsulates y contiene solo el búfer hexadecimal de la firma:

 SEQUENCE {

 OBJECT IDENTIFIER sha256WithRSAEncryption (1 2 840 113549 1 1 11)   

 NULL

 } 

 BIT STRING 

 // RAW signature hex buffer }

Es importante que mi analizador sepa si BITSTRING solo contendrá un búfer (como, en el caso de la firma) o si encapsulará algunos otros tipos (como en el caso de la clave pública). En la codificación DER de ambos no encontré ninguna diferencia que pueda implicar el uso de la encapsulación.

Mi pregunta es: ¿cómo puedo distinguir esos 2 escenarios en el código del analizador?

    
pregunta Dima Shifrin 14.06.2017 - 18:12
fuente

3 respuestas

3

Realmente no puede saberlo sin saber qué tipo de datos está analizando.

Si sabe qué tipo de datos está descodificando, debe usar los módulos ASN y la documentación relacionada para ajustar su analizador. Además, es posible que necesites hacer un poco de trabajo intelectual.

  

BITSTRING solo contendrá un búfer (como en el caso de la firma)

no es un búfer sin formato, también puede ser un tipo anidado. Por ejemplo, si observa las firmas de ECDSA, encontrará que la firma codificada es un tipo complejo anidado:

ECDSA-Sig-Value ::= SEQUENCE {
    r  INTEGER,
    s  INTEGER
   }

y aquí es cómo se ve:

  

oencapsularáalgunosotrostipos(comoenelcasodeclavepública)

Denuevo,nosiempre.LaclaveRSAusaunaestructuraanidadaenBIT_STRING,laclaveECno:

estossonsoloejemplosenlosquetussuposicionesfallan.Lafirmapuedetenerestructuraanidada,laclavepúblicapuedenotenerla.Dependedeuncontextoysindocumentaciónesdifícildecirquéesperar.Asíquesugieroutilizarladocumentación.Porejemplo, RFC5912 que contiene la mayoría de los módulos ASN de PKIX.

Si no sabe qué datos está analizando, entonces tiene que hacer un gran esfuerzo para verificar de forma proactiva si el tipo actual es primitivo o está construido (sin el conjunto de CONSTRUCTED bit). Es un intento de desenrollar el tipo anidado si es posible.

Tengo un analizador en bruto de propósito general para decodificar datos binarios de ASN a estructuras discretas escritas en C #: Asn1DerParser.NET y clase de analizador: Asn1Reader

    
respondido por el Crypt32 14.06.2017 - 19:55
fuente
1

Un BIT STRING es un tipo básico que dice "el valor es una secuencia de bits", sin absolutamente ninguna información adicional sobre cómo deben interpretarse estos bits. No hay diferencia en la codificación dependiendo de si se supone que los bits de valor son en sí mismos la codificación DER de alguna estructura anidada, o si son "solo bits".

La respuesta "normal" es la que da @ Crypt32: cuando descodifica una estructura (por ejemplo, un certificado X.509), se supone que debe saber qué tipo de estructura está descodificando y actúa en consecuencia. Esto puede ser bastante complejo en la práctica; por ejemplo, la estructura SubjectPublicKeyInfo contiene un AlgorithmIdentifier que identifica el tipo de clave pública y un BIT STRING que contiene el valor de la clave pública. Si la clave pública es una clave RSA, se supone que el valor de BIT STRING es una estructura con codificación DER (un SEQUENCE de dos valores de INTEGER ); sin embargo, si esta es una clave pública de EC, entonces el contenido de BIT STRING será el punto público sin codificación, sin ASN.1 o DER.

Si su herramienta es para diagnósticos , puede utilizar la heurística. Es posible que desee consultar DDer , que es un analizador ASN.1 / DER genérico (en realidad, es compatible con BER). Cuando encuentra un "valor binario" ( BIT STRING o OCTET STRING ), intenta ver si ese valor podría decodificarse como un objeto ASN.1. Dado que la codificación BER / DER es bastante redundante, ocurre muy raramente que un valor aleatorio arbitrario como una firma coincidiría con la codificación DER sin error (básicamente 1 en 10000 veces o menos).

(DDer también viene con una herramienta complementaria llamada MDer que realiza la operación inversa: desde una representación basada en texto hasta la codificación DER. Esto puede ser conveniente para hacer objetos de prueba).

    
respondido por el Thomas Pornin 14.06.2017 - 21:26
fuente
0

Las cadenas de bits y las cadenas de octetos pueden contener datos o ASN.1 incrustados. Aunque es útil saber qué formato debe tomar algo antes de analizar, no es del todo necesario. (Esos decodificadores ASN.1 no saben lo que están decodificando antes de analizarlos por completo). Al analizar una cadena de octetos, simplemente puede mirar el contenido y ver si encaja en el formato de una primitiva ASN.1 (encabezado de 1 byte, seguido por la información del tamaño, seguido por la cantidad de datos indicados por el tamaño).

Las cadenas de bits son un poco más complejas de diseccionar. Las cadenas de bits tienen un byte que indica el número de bits de desplazamiento: la cadena de bits se mantiene en bytes, pero el número real de bits que se almacenan en el objeto puede ser de 1 a 7 de un múltiplo de 8. Solo si el desplazamiento es 0 puede mirar los bytes contenidos y evaluar si los datos contenidos son una primitiva ASN.1 o no.

    
respondido por el Lampshade 15.06.2017 - 15:43
fuente

Lea otras preguntas en las etiquetas