de Rajind Ruparathna

Cum se verifică semnăturile mesajelor AS2 (SMIME) cu OpenSSL

Cum se verifica semnaturile mesajelor AS2 SMIME cu OpenSSL
Imagine de ar130405 pe PixaBay

Eroare MDN-uri care indică o eroare în liniile de “Verificarea semnaturii a eșuat” sau „Decriptarea eșuată” sunt obișnuite pentru utilizatorii care tocmai încep să utilizeze AS2 în orice serviciu AS2. Am văzut multe astfel de cazuri în platforma noastră de mesagerie SaaS B2B AS2 AdroitLogic AS2Gateway. Cu aceste tipuri de erori, uneori, este important ca echipa de asistență și, de asemenea, utilizatorul să poată încercați decriptarea sau verificarea manuală a semnăturii pentru a obține mai multe informații.

În această postare de blog, vom analiza care este semnătura digitală în protocolul AS2, cum se verifică semnătura unui mesaj AS2 și câteva sfaturi despre aflarea cauzei anumitor eșecuri de verificare a semnăturii.

Semnătură în protocolul AS2

Semnătura AS2 este, în esență, o semnătură digitală care oferă autentificare, integritate a datelor și non-respingere a comunicării AS2.

  • Autentificare – Asigură că receptorul tranzacționează cu expeditorul cu care el / ea a fost menit să tranzacționeze (și nu un impostor)
  • Integritatea datelor – Determină dacă fișierul sau datele primite de receptor au fost modificate pe parcurs
  • Non-Repudiere – Împiedică expeditorul să nege că mesajele trimise de ei provin de la ei
1611334747 648 Cum se verifica semnaturile mesajelor AS2 SMIME cu OpenSSL

După cum se arată în figura de mai sus, cheia privată a expeditorului este utilizată la generarea semnăturii și, astfel, pentru verificare este utilizată cheia publică a expeditorului.

Sa trecem la treaba!

În scop demonstrativ, vom folosi un mesaj AS2 de intrare către AS2Gateway. Deoarece ne concentrăm doar pe verificarea semnăturii în această postare de blog, mesajul AS2 primit nu va fi criptat sau comprimat. Dacă doriți să încercați acest lucru cu criptare, vă rugăm să aruncați o privire la articolul meu anterior decriptarea mesajului AS2 cu OpenSSL.

Descărcarea antetelor de mesaje și transport RAW

Odată ce am primit un mesaj AS2, putem vedea mesajul primit în vizualizare inbox în AS2Gateway așa cum se arată mai jos.

Cum se verifica semnaturile mesajelor AS2 SMIME cu OpenSSL

Apoi putem face clic pe subiectul mesajului (în acest caz este „Exemplu de mesaj semnat”) pentru a merge la vedere detaliată din mesajul primit așa cum se arată mai jos.

1611334748 503 Cum se verifica semnaturile mesajelor AS2 SMIME cu OpenSSL

Acum puteți face clic pe „Mesaj brut” butonul și „Descărcați antetele de transport” butonul pentru a descărca încărcarea utilă a mesajului AS2 neprocesat și antetele de transport pe care le-am primit de la partener. Mesajul brut va fi descărcat într-un fișier cu nume mesaj.raw iar antetele de transport vor fi descărcate într-un fișier cu nume anteturi.raw.

Obținerea cheii publice a expeditorului

Acum că avem mesajele brute și anteturile de transport, ceea ce ne trebuie în continuare este cheia publică a expeditorului. Îl putem descărca direct făcând clic pe PEM butonul (violet) din vizualizarea certificatelor (prezentat mai jos) în AS2Gateway.

1611334748 743 Cum se verifica semnaturile mesajelor AS2 SMIME cu OpenSSL

Înainte de a continua cu pașii următori, să ne asigurăm că avem la dispoziție tot ce avem nevoie.

  • Mesaj brut (message.raw)
  • Anteturi de transport (headers.raw)
  • Cheia publică a expeditorului (cert.pem)

Analiza anteturilor de transport HTTP

Mai întâi să aruncăm o privire asupra antetelor de transport înainte de a continua.

După cum puteți vedea, există o grămadă de anteturi. Să ne concentrăm doar pe câteva importante în contextul verificării semnăturii mesajului AS2.

  • tipul de conținut antetul sugerează că avem un semnat în mai multe părți sarcina utilă în cel mai exterior strat și în continuare ne spune că hotar multipartit este notat de șirul „- – = _ Part_1_1702144111.1552838995900” pentru acest mesaj AS2.
  • De asemenea, avem versiune mime a fi 1.0

Dacă sunteți interesat să cunoașteți mai multe detalii, cel mai bun loc pentru a începe ar fi AS2 RFC 4130.

Analiza mesajului Raw

Acum, să ne uităm la mesajul brut (message.raw). Conform antetului de tip de conținut, știm deja că sarcina utilă este una semnată în mai multe părți. O putem vedea mai jos. Acolo vedeți două părți (separate prin șirul de delimitare cu mai multe părți, așa cum se menționează în antetul de tip transport). Una cu sarcina utilă originală (vedem sarcina utilă în text simplu, deoarece nu am criptat sau comprimat sarcina utilă pentru această demonstrație). Celălalt cu semnătura (application / pkcs7-signature).

Adăugarea antetelor obligatorii

Vă amintiți că am vorbit despre câteva anteturi importante de transport atunci când ne uităm la antetele de transport? Acum este momentul să le folosim. Trebuie să adăugăm aceste anteturi în fișierul nostru message.raw, astfel încât rezultatul final să fie după cum urmează. (Să luăm noul fișier ca message_with_headers.raw) Rețineți că spațiul alb dintre antetele de transport HTTP și sarcina utilă semnată în mai multe părți este intenționat.

Se verifică semnătura …

Este timpul să rulați comanda de decriptare. Aici folosim „smime” instrument de OpenSSL.

openssl smime -verify -noverify -in message_with_headers.raw -signer cert.pem -out verified_payload.txt

După ce executați comanda, ar trebui să primiți un mesaj care să spună „Verificarea a reușit”. Sarcina utilă verificată va fi în fișierulverified_payload.txt. Rețineți că, în acest caz, vom obține partea mime a sarcinii utile ca ieșire, care ar arăta ceva după cum urmează.

Doar pentru finalizare, permiteți-mi să adaug o notă despre o eroare pe care am primit-o în timp ce încercam asta. Pentru mine, cauza acestei erori a fost o nepotrivire în șirul de delimitare cu mai multe părți din antetul de tip conținut cu șirul de delimitare cu mai multe părți. Rețineți că există două ‘-s precedente când limita cu mai multe părți este utilizată într-o sarcină utilă SMIME cu mai multe părți.

Error reading S/MIME message 4719224428:error:0DFFF0D2:asn1 encoding routines:CRYPTO_internal:no multipart body failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.240.1/libressl-2.6/crypto/asn1/asn_mime.c:464:

Rețineți că am folosit parametrul „-noverify” în comanda de verificare a semnăturii. Acest lucru se datorează faptului că certificatele pe care le-am folosit în această demonstrație sunt certificate auto-semnate. Dacă parametrul „noverify” nu este utilizat, OpenSSL va încerca să verifice mai întâi certificatul și nu va da o eroare similară cu următoarea.

Verification failure 4567594604:error:21FFF075:PKCS7 routines:func(4095):certificate verify error:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.240.1/libressl-2.6/crypto/pkcs7/pk7_smime.c:340:Verify error:self signed certificate

Misto. Verificarea semnăturii se face și se spală. Chiar dacă ne-am uitat să facem verificarea semnăturii în întregime folosind instrumentele pentru linia de comandă din acest articol, acest lucru se poate face folosind și câteva linii pe codul Java. Sper să o acoperi într-un articol viitor.

Pachet bonus

Înainte de a vă deconecta, aș dori să vă împărtășesc câteva detalii bonus care vă vor ajuta să identificați cauza anumitor scenarii de eșec al verificării semnăturii. Primul este despre cum să aflați algoritmul de semnătură utilizat.

Aflarea algoritmului de semnătură utilizat

Pentru a găsi algoritmul de semnătură utilizat, putem folosi asn1parse instrument de OpenSSL. În primul rând, trebuie să separăm partea de semnătură fără antetele MIME într-un fișier separat, după cum urmează. Să numim acest fișier semnătură.raw

Acum, putem rula următoarea comandă pentru a obține ieșirea asn1parse.

openssl asn1parse -i -in signature.raw

Rezultatul ar fi după cum urmează. Dacă puteți vedea mai jos, partea cea mai exterioară are tip pkcs7-signedData, iar după patru sau cinci rânduri vedem sha1 care este algoritmul de semnătură utilizat.

Mai multe detalii din rezultatul asn1parse

Mai sunt câteva detalii pe care le putem vedea și înțelege din rezultatul asn1parse. Opțional la semnare, certificatele de semnare sunt atașate la semnătura însăși. Aceasta este ceea ce vedeți începând de la pkcs7-data secțiune. „INTEGER: 438EFDF3” este numărul de serie al certificatului de semnare. De asemenea, puteți vedea perioada de validare a certificatului așa cum se arată mai jos.

258: d = 7 hl = 2 l = 13 prim: UTCTIME: 051201134315Z
273: d = 7 hl = 2 l = 13 prim: UTCTIME: 190810134315Z

Agenții expeditori TREBUIE să codifice timpul de semnare până în anul 2049 ca UTCTime. Timpurile de semnare în 2050 sau mai târziu TREBUIE să fie codificate ca GeneralizedTime. Agenții TREBUIE să interpreteze câmpul anului (YY) după cum urmează: dacă YY este mai mare sau egal cu 50, anul este interpretat ca 19YY; dacă YY este mai mic de 50, anul este interpretat ca 20YY.

În ceea ce privește UTCTime din RFC 2311 – https://tools.ietf.org/html/rfc2311

În acest caz, perioada în care certificatul este valabil este de la UTC 2005/12/01 13:43:15 până la 2019/08/10 13:43:15.

Avem și ora semnării la Timpul semnării atribut ca 190317161000Z care este UTC 2019/03/17 16:10:00. Rețineți că în timpul validării semnăturii, pe lângă potrivirea hashului de conținut, se va face o altă verificare pentru a vedea dacă semnătura a fost când certificatul era actual. Practic, la momentul semnării, certificatul ar trebui să fie valid.

Cu mai multe cunoștințe în structura ASN.1, ar trebui să putem obține mai multe informații din acest lucru. Este timpul să mă semnez. Noroc! ?

Apel la acțiune

  • Bate. Apreciază și lasă alții să găsească acest articol.
  • Cometariu. Împărtășiți-vă opiniile despre acest articol.
  • Urmați-mă. Rajind Ruparathna pentru a primi actualizări la articole de genul acesta.
  • Păstrăm legătura. LinkedIn, Stare de nervozitate

Publicat inițial la notebookbft.wordpress.com pe 19 martie 2019.