Gastro-MIS GmbH

Hallo,

nachdem ich mit der Programmierung der TSE-Anbindung incl. Tar-Export in groben Zügen fertig war

(https://support.gastro-mis.de/support/discussions/topics/36000016988),

habe ich mich den nächsten beiden Problemen angenommen:

• Visualisierung der Log-Messages und der Tar-Exporte
• Verifizierung der von der TSE erzeugten Signaturen

Vorab: Es ist mir inzwischen gelungen, Signaturen erfolgreich zu verifizieren. Allerdings war das schon etwas mühevoll.

Der Support kann und/oder will hierbei übrigens nicht helfen...

Ich mußte mir zuerst einen TLV-Parser (ASN.1) schreiben, um die Log-Messages überhaupt verstehen zu können. Damit konnte ich auch sehen, daß der in Base64 exportierte PublicKey nicht die wirkliche PKCS#8-Pem-Datei ist, sondern nur der innere BitString. Das ist verwirrend und man kann den Key so nicht an openssl verfüttern.
Auch die Signatur wird ja nur als 96 Byte langer Octet-String ausgegeben und man muß diese erst teilen und in eine Sequence einfügen, damit openssl sie akzeptiert.

-> Wie macht ihr das?

-> Wer hat bereits einen "Signatur-Verifizierer" (außer AmadeusVerify) programmiert?

Die Audit-Messages enthalten eine Struktur "seAuditData", die leider nirgends beschrieben ist. Mir ist es deshalb noch nicht gelungen, aus dem Hexcode etwas Sinnvolles zu extrahieren.
-> Hat hier schonmal jemand diesbezüglich etwas erreicht?

Signatuen zu erstellen ohne diese auch zu verifizieren ist m.E. wie ein Backup ohne jemals ein Restore gemacht zu haben...

Viele Grüße
U. Kleinert

Hallo,

ich antworte hier mal selbst...

Nachdem ich mich näher mit den verwendeten Kryptografie-Algorithmen und -formaten der TSE beschäftigt habe, ist es mir gelungen, sowohl die Tar-Datei, als auch die einzelnen Msg-Dateien, die ja quasi dem "WormEntry" entsprechen, zu analysieren und zu verifizieren.

• um die Signaturen zu verifizieren, kann man openssl nutzen
• da openssl den PublicKey im PEM-Format erwartet, muß man diesen zuerst aus dem (ersten) Zertifikat der Datei "*_X509.pem" in der Tar-Datei erzeugen
• die Daten von "readLogMessage" bzw. aus den Logfiles des Tar-Exports müssen in den Message-Anteil und die Signatur aufgeteilt werden
• die Signatur selbst (96 Byte) muß ebenfalls zuerst ins DER- und danach ins PEM-Format überführt werden, damit man sie mit openssl prüfen kann
• um die S/N der TSE zu prüfen, muß man den SHA-2-Hash des PublicKey erzeugen, dazu darf aber nur der wirkliche PublicKey verwendet werden, den man vorher aus dem DER-Format extrahieren muß (AlgorithmIdentifier entfernen)
  

Das Ergebnis ist ein fertiger Analyzer, der die Log-Messages bzw. das Tar-File visualisiert und die Signaturen verifiziert. Ansonsten schreibt man jahrelang Daten in die TSE und exportiert diese brav als Tar, ohne überhaupt zu wissen, ob die Signaturen jemals korrekt sind. Das funktioniert unabhängig von irgendeiner DSFinV-K, hierbei werden nur die kryptografischen Daten geprüft.

Hallo,

das wäre eine gute Sache, wenn ich die Signaturen verifizieren könnte.  Muss ich mal forschen. Momentan bin ich noch etwas verunsichert: siehe

https://support.gastro-mis.de/support/discussions/topics/36000017639

Ich sehe/finde noch keinen Fehler meinerseits

Hans

Hallo,

ich habe in dem anderen Thema bereits eine Antwort geschrieben:
https://support.gastro-mis.de/support/discussions/topics/36000017639

Meine Vermututung wäre, daß beim "Nachbau" der Message ein Fehler passiert, z.B. weil die Zeit oder ein anderes Element aus dem QR-Code falsch ermittelt oder falsch ausgegeben wurde.

Damit wird ein anderer Hash produziert, der dann nicht paßt.
Die "Verschlüsselung" der Signatur ergibt ja ebenso nur einen Hash, aus dem sich kein Rückschluß auf die orginale Message ergibt.

Viele Grüße
U. Kleinert