ASN.1 tipo BITSTRING incapsulato in openSSL

3

Attualmente sto costruendo un parser ASN.1 che dovrebbe decodificare i certificati X.509v3 ed i file epoch in formato DER ASN.1. Il parser funziona bene a parte un problema che non riesco a ottenere. Se decodifico il formato DER, vedo che per la chiave pubblica viene utilizzata la seguente forma di BITSTRING:

 BIT STRING, **encapsulates** {

 SEQUENCE {

 INTEGER

     // public key hex string

ma quando guardo la firma vedo che è rappresentato con BITSTRING senza il tag encapsulates e contiene solo il buffer esadecimale della firma:

 SEQUENCE {

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

 NULL

 } 

 BIT STRING 

 // RAW signature hex buffer }

È importante che il mio parser sappia se il BITSTRING conterrà solo un buffer (come nel caso della firma) o incapsulerà altri tipi (come nel caso della chiave pubblica). Nella codifica DER di entrambi non ho trovato alcuna differenza che possa implicare l'uso dell'incapsulamento.

La mia domanda è: come posso distinguere questi due scenari nel codice parser?

    
posta Dima Shifrin 14.06.2017 - 18:12
fonte

3 risposte

3

Non puoi davvero saperlo senza sapere quale tipo di dati stai analizzando.

Se si conosce il tipo di dati che si sta decodificando, è necessario utilizzare i moduli ASN e la relativa documentazione per regolare il parser. Inoltre, potrebbe essere necessario fare del lavoro intellettuale.

the BITSTRING will only contain a buffer (like in case of the signature)

non è un buffer raw, può essere anche un tipo annidato. Ad esempio, se guardi le firme ECDSA, troverai che la firma codificata è un tipo complesso nidificato:

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

ed ecco come appare:

orwillencapsulatesomeothertypes(likeinthepublickeycase)

Ancora,nonsempre.LachiaveRSAutilizzalastrutturanidificatainBIT_STRING,lachiaveCEnon:

questisonosoloesempiincuiletuesupposizionifalliscono.Lafirmapotrebbeavereunastrutturanidificata,lachiavepubblicapotrebbenonaverla.Dipendedauncontestoesenzadocumentazioneèdifficiledirecosaaspettarsi.Quindisuggerireidiusareladocumentazione.Adesempio, RFC5912 che contiene la maggior parte dei moduli PKIX ASN.

se non sai quali dati stai analizzando, devi fare un duro lavoro per verificare in modo proattivo se il tipo corrente è primitivo o costruito (senza CONSTRUCTED bit set). Questo è il tentativo di srotolare il tipo annidato se possibile.

Ho un parser generico per decodificare i dati binari ASN su strutture discrete scritte in C #: Asn1DerParser.NET e parser class: Asn1Reader

    
risposta data 14.06.2017 - 19:55
fonte
1

Un BIT STRING è un tipo di base che dice "valore è una sequenza di bit", senza assolutamente nessuna informazione aggiuntiva su come questi bit devono essere interpretati. Non vi è alcuna differenza nella codifica a seconda che i bit di valore debbano essere essi stessi la codifica DER di qualche struttura nidificata, o siano "solo bit".

La risposta "normale" è quella data da @ Crypt32: quando decodifichi una struttura (ad esempio un certificato X.509), dovresti sapere quale tipo di struttura stai decodificando e agire di conseguenza. Questo può essere abbastanza complesso nella pratica; ad esempio, la struttura SubjectPublicKeyInfo contiene un AlgorithmIdentifier che identifica il tipo di chiave pubblica e un BIT STRING che contiene il valore della chiave pubblica. Se la chiave pubblica è una chiave RSA, si suppone che il valore di BIT STRING sia una struttura con codifica DER (un SEQUENCE di due valori INTEGER ); tuttavia, se questa è una chiave pubblica CE, il contenuto di BIT STRING sarà il punto pubblico codificato non elaborato, senza ASN.1 o DER.

Se il tuo strumento è per la diagnostica , puoi utilizzare l'euristica. Potresti dare un'occhiata a DDer , che è un parser ASN.1 / DER generico (in realtà, supporta BER). Quando si incontra un "valore binario" ( BIT STRING o OCTET STRING ), prova a vedere se quel valore potrebbe essere decodificato come un oggetto ASN.1. Dato che la codifica BER / DER è abbastanza ridondante, capita molto raramente che un valore casuale arbitrario come una firma corrisponda alla codifica DER senza errori (in pratica 1 su 10000 volte o giù di lì).

(DDer ha anche uno strumento complementare chiamato MDer che esegue l'operazione inversa: da una rappresentazione basata su testo alla codifica DER. Questo può essere utile per creare oggetti di prova.)

    
risposta data 14.06.2017 - 21:26
fonte
0

Le stringhe di bit e le stringhe di ottetto possono contenere sia dati che ASN.1 incorporati. Anche se aiuta a sapere quale formato dovrebbe essere preso prima di analizzare, non è del tutto necessario. (Quei decodificatori ASN.1 non sanno cosa decodificano prima di analizzare completamente.) Quando si analizza una stringa di ottetto, si può semplicemente guardare il contenuto e vederlo che si adatta al formato di una primitiva ASN.1 (intestazione da 1 byte, seguito da informazioni sulla dimensione, seguite dalla quantità di dati indicata dalla dimensione).

Le stringhe di bit sono un po 'più complesse da sezionare. Le stringhe di bit hanno un byte che indica il numero di bit di offset - la stringa di bit viene mantenuta in byte, ma il numero effettivo di bit memorizzati nell'oggetto potrebbe essere ovunque da 1 a 7 su un multiplo di 8. Solo se il l'offset è 0 puoi guardare i byte contenuti e valutare se i dati contenuti sono o meno primitivi ASN.1.

    
risposta data 15.06.2017 - 15:43
fonte

Leggi altre domande sui tag