Gastro-MIS GmbH

TxNr:30: Signatur ist nicht valide. Formatierung stimmt aber. QrScan 15:16:37 16.09.2020.39

Validierungsinfo: Logmessage in Hex: 02-01-02-06-09-04-00-7F-00-07-03-07-01-01-80-11-46-69-6E-69-73-68-54-72-61-6E-73-61-63-74-69-6F-6E-81-08-70-63-2D-6B-61-73-73-65-82-29-42-65-6C-65-67-5E-31-30-2E-31-30-5F-30-2E-30-30-5F-30-2E-30-30-5F-30-2E-30-30-5F-30-2E-30-30-5E-31-30-2E-31-30-3A-42-61-72-83-0E-4B-61-73-73-65-6E-62-65-6C-65-67-2D-56-31-85-01-1E-04-20-20-1D-F4-BA-1B-A1-D5-E2-7B-17-19-4E-88-23-6B-C2-EC-BA-DD-4A-C3-EF-D1-4C-BD-B3-66-1E-B6-FD-E7-F9-30-0C-06-0A-04-00-7F-00-07-01-01-04-01-04-02-02-01-BB-02-04-5F-61-97-99        QrScan    15:16:37 16.09.2020.39

Habe das selbe Problem,  sonst ist alles "GRÜN" in Amadeus. Nur diese Fehler bei den Transaktionen. Fahre noch auf dem Entwickler-Modul.

Das ist eine meiner Signaturen:

TAif+dCIwHd/KcBsJabPOXMLiQHHfGNWzjWqoNcS9hklZiiDTCQNWjeb+ITaLYK8AChT5x7j/QwE2+nX+yvu2sZmxul3pxPHJfFvKdubMT2nsCfzoaPZdGxY2JfSNYTU

Das Zertifikat und der Public Key, die ich auslese, scheinen zu stimmen (wormui.exe bringt das selbe Zertifikat, ein Profitool extrahiert daraus den selben Public Key den ich auch auslese)

Kann das sein, dass das am Entwickler-Modul liegt?

Ich arbeite mit Delphi 10.3

Hans

Ach ja, noch dieses:

Ich übergebe an die DSFinVK die Zertifikate zwischen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE-----, also

1. Zertifikat:

MIIBkTCCATegAwIBAgIGAW3ZtMDvMAoGCCqGSM49BAMCMBYxFDASBgNVBAMMC1N3aXNzYml0IENBMB4XDTE5MTAxNzEyMzE1NFoXDTIwMDEzMDIzMDAwMFowEzERMA8GA1UEAwwIU3dpc3NiaXQwejAUBgcqhkjOPQIBBgkrJAMDAggBAQsDYgAEDQqCpxYo6AjSQLG8pkptlmeheayQ+j5JWFZNBgGtIFU4TszBwrwb8qV/txXQSylyCkt2JHnZ8zcgk3zOWc7t0AvIPFakcRPnU36dU8q0XDrg4N5tetoQt5rr3kDOD9ubo1MwUTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAZBgNVHREEEjAQgQ50ZXN0QHRlc3QudGVzdDAKBggqhkjOPQQDAgNIADBFAiEAis5WKCGD5bm8w8PgOg8W4vA1SNMUG5BCd5jbbHsZhCYCICnp82TKwMRw1mFyOn25NWEstYGPGPJPbZi0566iz33R

2. Zertifikat:

MIIBFzCBvwIGAW3ZtMD2MAoGCCqGSM49BAMCMBYxFDASBgNVBAMMC1N3aXNzYml0IENBMB4XDTE5MTAxNzEyMzE1NFoXDTIwMDEzMDIzMDAwMFowFjEUMBIGA1UEAwwLU3dpc3NiaXQgQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAS5sidpYfxFQfXwK/WQztoUhW2azT08pe/UIRMYXz5e2KbKWBuIi2UycvIb0eZgBKMC9r5UA+aI9UjrXqcOOilmMAoGCCqGSM49BAMCA0cAMEQCIBf+T2b7cKa0H33tlsvkivC2lVSB47UXZLJ1B0KiAkmtAiBP0/Yg7RLjUbsS3OOCLfwg4/6JHsZ1329c6f1amWuVrg==

und den PublicKey:

BA0KgqcWKOgI0kCxvKZKbZZnoXmskPo+SVhWTQYBrSBVOE7MwcK8G/Klf7cV0EspcgpLdiR52fM3IJN8zlnO7dALyDxWpHET51N+nVPKtFw64ODebXraELea695Azg/bmw==

Hallo,

die Prüfung der Signaturen selbst ist ein simpler kryptographischer Prozess (umgekehrte asymmetrische Verschlüsselung) und hat genaugenommen weder mit der TSE noch mit dem Export etwas zu tun.

In der TSE wird über die Message ein Hash gebildet und dieser Hash wird mit dem PrivateKey "entschlüsselt". Das ergibt die Signatur, welche die TSE speichert und zurückmeldet.

Damit man die Signatur prüfen kann, muß man zuerst die originale Message "nachbauen" (hier liegt ggf. das Problem).
Bei der Signaturprüfung wird die Signatur mit dem PublicKey der TSE "verschlüsselt" und muß den Hash der nachgebauten Message ergeben.

Da der orginale Hash der Message (leider) nicht gespeichert wird, kann man beim Verifizieren nicht feststellen, an welcher Stelle der Fehler liegt.
Entweder die nachgebaute Message ist falsch (es reicht hier ein Bit) oder der PublicKey (aus dem Zertifikat) paßt nicht oder das Prüf-Verfahren selbst hat einen Fehler oder die Signatur paßt schlicht und einfach nicht zur TSE.

Viele Grüße
U. Kleinert

Hallo Ulrich,

könntest du mir Auskunft darüber geben, wie sich die originale Message zusammenbaut?

Gruß,

Sven

Hallo Sven Hecht,

der Aufbau der Log- und der Transaktions-Messages ist in der TR-03151 sehr genau beschrieben (s. Pkt. 2 und Appendix A).

Man muß mit den originalen Message-Daten diese TLV-Struktur "nachbauen". Alle dazu notwendigen Angaben erhält man vom Bon bzw. aus dem QR-Code.

Man kann auch über das SDK die Messages exportieren, auch im Tar-Export stehen diese Daten. Allerdings in beiden Fällen bereits TLV-codiert, so daß man sie zur Visualisierung decodieren muß.

Viele Grüße

U. Kleinert

Hallo Ulrich Kleinert,

vielen Dank für die rasche Antwort. Ich werde versuchen die TLV-Struktur nachzubauen. 

Grüße

S. Hecht

Hallo zusammen,

wir hatten nun Kontakt zum Gastro-MIS-Support. Dieser war sehr hilfsbereit! Nach analyse unserer Log-Daten hat sich herausgestellt, dass wir in der transactions_tse.csv im Feld TSE_TA_ENDE die Zeit nicht als UTC sondern die lokale Zeit übergeben haben.

Dadurch kam es bei der AmadeusVerify-Berechnung des unixTimeStamp zu einem Unterschied von 2 Stunden und damit natürlich auch zu einer nicht validen Signatur.

Grüße,

S. Hecht

Hallo Sven Hecht,

normal werden bei den Zeiten ja UnixTimestamps angegeben, die natürlich immer UTC sind.

So ein kleiner Fehler reicht vollkommen aus, daß sich die Signaturen nicht validieren lassen.

Prima, daß es jetzt geklappt hat.

Das zeigt aber auch, daß die Erzeugung der Daten ohne Validierung reiner "Blindflug" ist.

Deshalb finde ich es um so schlimmer, daß das BSI immer nur von der Erzeugung der Signaturen spricht, aber nirgends Angaben zu deren Validierung macht...