messaggio PKCS # 7 costruito dal nostro codice, eventuali punti deboli nell'output?

Question

messaggio PKCS # 7 costruito dal nostro codice, eventuali punti deboli nell'output?

#1 da (3 voti)

1

Abbiamo questo come messaggio crittografato PKCS # 7. Vorremmo aprirlo qui per la revisione e l'analisi qui, affinché le persone facciano buchi. Questo esempio viene generato tramite certificati di prova e chiavi. La preoccupazione non riguarda le informazioni sui certificati, ma la crittografia e le firme vanno bene. Non mi aspetto di crackare la crittografia (!) - semplicemente assicurandomi che non ci siano perdite di dati dalla privacy e dall'autenticità del messaggio incapsulato.

In altre parole, quali informazioni sei in grado di estrarre dal messaggio sottostante?

Sto inserendo il formato PEM non elaborato del messaggio e l'output openssl asn1parse -in test.pem -i .

Output parsing OpenSSL ASN1:

    0:d=0  hl=4 l=1963 cons: SEQUENCE          
    4:d=1  hl=2 l=   9 prim:  OBJECT            :pkcs7-envelopedData
   15:d=1  hl=4 l=1948 cons:  cont [ 0 ]        
   19:d=2  hl=4 l=1944 cons:   SEQUENCE          
   23:d=3  hl=2 l=   1 prim:    INTEGER           :00
   26:d=3  hl=4 l= 415 cons:    SET               
   30:d=4  hl=4 l= 411 cons:     SEQUENCE          
   34:d=5  hl=2 l=   1 prim:      INTEGER           :00
   37:d=5  hl=3 l= 130 cons:      SEQUENCE          
   40:d=6  hl=2 l= 125 cons:       SEQUENCE          
   42:d=7  hl=2 l=  11 cons:        SET               
   44:d=8  hl=2 l=   9 cons:         SEQUENCE          
   46:d=9  hl=2 l=   3 prim:          OBJECT            :countryName
   51:d=9  hl=2 l=   2 prim:          PRINTABLESTRING   :US
   55:d=7  hl=2 l=  11 cons:        SET               
   57:d=8  hl=2 l=   9 cons:         SEQUENCE          
   59:d=9  hl=2 l=   3 prim:          OBJECT            :stateOrProvinceName
   64:d=9  hl=2 l=   2 prim:          UTF8STRING        :CA
   68:d=7  hl=2 l=  20 cons:        SET               
   70:d=8  hl=2 l=  18 cons:         SEQUENCE          
   72:d=9  hl=2 l=   3 prim:          OBJECT            :localityName
   77:d=9  hl=2 l=  11 prim:          UTF8STRING        :Los Angeles
   90:d=7  hl=2 l=  26 cons:        SET               
   92:d=8  hl=2 l=  24 cons:         SEQUENCE          
   94:d=9  hl=2 l=   3 prim:          OBJECT            :organizationName
   99:d=9  hl=2 l=  17 prim:          UTF8STRING        :Test Organization
  118:d=7  hl=2 l=  11 cons:        SET               
  120:d=8  hl=2 l=   9 cons:         SEQUENCE          
  122:d=9  hl=2 l=   3 prim:          OBJECT            :organizationalUnitName
  127:d=9  hl=2 l=   2 prim:          UTF8STRING        :HQ
  131:d=7  hl=2 l=  34 cons:        SET               
  133:d=8  hl=2 l=  32 cons:         SEQUENCE          
  135:d=9  hl=2 l=   3 prim:          OBJECT            :commonName
  140:d=9  hl=2 l=  25 prim:          UTF8STRING        :Test Organization Root CA
  167:d=6  hl=2 l=   1 prim:       INTEGER           :02
  170:d=5  hl=2 l=  13 cons:      SEQUENCE          
  172:d=6  hl=2 l=   9 prim:       OBJECT            :rsaesOaep
  183:d=6  hl=2 l=   0 cons:       SEQUENCE          
  185:d=5  hl=4 l= 256 prim:      OCTET STRING      [HEX DUMP]:5491C648547365483F156D114992B1E2729B94BBCC1D8ACB80163B09C367DD263B98FBD9FD22CBC3323AE4109F7B8688D077E4627769970611A72C06EEC5033984BE7664C9006700D2F6774AEEA475B13562B584253F34B12A38C2D1F0CDB90BA1EDD6FADDB18253B559C31AB6D64AD7B714D1085B7493054D2F6A5DE04EA4CF27FA8E9ADF99CFBF6A7391164959142ADB3CF7CF4FD70445BDA5A9FB2439C337D96069387579F3FADA89A187023ABFD8290939A7E34C4733E04C8A72460B720B63CE80FD6B44A9D45650662493BE79AA7337AEBEB1C4543B93F12FF2D56EE79E32E735033F3D82459E8C731DA83C592C72B93BB5665139018255EB94DCE5A4D7
  445:d=3  hl=4 l=1518 cons:    SEQUENCE          
  449:d=4  hl=2 l=   9 prim:     OBJECT            :pkcs7-data
  460:d=4  hl=2 l=  29 cons:     SEQUENCE          
  462:d=5  hl=2 l=   9 prim:      OBJECT            :aes-256-cbc
  473:d=5  hl=2 l=  16 prim:      OCTET STRING      [HEX DUMP]:6A537AC9FE14255BFFEF3F88C779F2A1
  491:d=4  hl=4 l=1472 prim:     cont [ 0 ]

encryption digital-signature smime

posta user21289 27.02.2013 - 23:32

fonte

1 risposta

Leggi altre domande sui tag encryption digital-signature smime

autenticazione di rete basata su certificato Utilizza l'autenticazione utilizzando 2 stringhe crittografate

score 3 · Answer 1

Non si può sapere se un'implementazione del CMS (aka "PKCS # 7)" sia sicura guardando il file prodotto al massimo, si potrebbero individuare problemi di interoperabilità .

Non ho individuato alcun problema di interoperabilità subito; si utilizza il padding OAEP con RSA, che può essere considerato grassetto (il supporto OAEP non è completamente diffuso in questo momento), ma è comunque conforme agli standard pertinenti (ad esempio PKCS # 1 ).

La sicurezza dipenderà molto dalle implementazioni degli algoritmi crittografici, in particolare il PRNG usato per produrre gli elementi padding casuali nella crittografia RSA / OAEP e la chiave per la crittografia AES. Ci sono dei cattivi bug in agguato, e nessuno potrebbe dirlo guardando solo un esempio di PKCS # 7.

Ho notato che questo oggetto "Enveloped Data" non include i dati stessi, il che va bene ma richiede che i dati crittografati vengano trasmessi o archiviati indipendentemente. Inoltre, tieni presente che la crittografia non implica integrità ; non ci sono molti modelli di attacco in cui è necessaria la crittografia, ma l'integrità è irrilevante (nella maggior parte dei casi, quando l'utente malintenzionato può osservare dati, può anche modificare dati). Per aggiungere l'integrità controllata a questo oggetto, è necessario avvolgerlo in un oggetto "Dati firmati" (e le cose diventano più complesse perché ora i mittenti hanno anche una coppia di chiavi pubblica / privata).