Das Beste Tutorial das ich gefunden habe
Beim Link oben sind wahrscheinlich die Kapitel 4.1 oder direkt 4.4 dann: 11.1/11.2/11.3 sehr nützlich
Die Version H004“ des EBICS-Protokolls sieht die Verwendung der folgenden Verfahren
vor:
X002 : für die Authentifikationssignatur
A004 : A005 oder A006 für die EU
E002 : für die Verschlüsselung.
Details zu diesen Verfahren sind im Anhang (Kapitel 11.1, Kapitel 11.2, Kapitel 11.3) enthalten.
So sieht ein INI-Brief aus ( EBICS-Initialisierungsbrief (INI) )
Hier noch ein Beispiel:
http://php-scripts.ch/ip/EBICS_2/ini-brief-muster.html
Hier werden die Parameter wie HostId erklärt
standardization/ebics/ebics.pdf
Hier gibt es was über die Schlüssel E001, E002, X001 und X002 und dass man nur jeweils einen braucht also 1 oder 2.
| • INI - Upload ES key |
| • HIA - Upload signing and encryption keys |
| • H3K - Upload signing, encryption, and ES keys |
| • PUB - Update ES key |
| • HCA - Update signing and encryption keys |
| • HCS - Update signing, encryption, and ES keys |
The user transmits the public certificates to the financial institution through two independent communication paths:
INI - Sends the public bank-technical key
HIA - Sends the public identification and authentication key and the public encryption key
E001, E002 : Encryption X001, X002 : Authentication
When the user is first assigned to a partner, the status of the user is New. If the user sends only the INI request to the bank, the status is changed to Partly Initialized (INI). If the user sends only the HIA request to the bank, the status is changed to Partly Initialized (HIA). After the user sends both the INI and HIA requeststo the bank, the status is changed to Initialized in the bank's system.
| 1. Kunde unterschreibt die Vertragsunterlagen des Banks. |
| 2. Bank sendet EBICS-Zugangsdaten mit den Hash-Werten an den Kunden. |
| 3. Kunde führt INI und HIA aus. |
| 4. Kunde sendet den unterschriebenen Initialisierungsbrief per Post an die Bank. |
| 5. Bank vergleicht die Hash-Werte und führt eine Unterschriftenprüfung durch. |
| 6. Bank akzeptiert die Schlüssel und gibt den Vertrag technisch frei. |
| 7. Kunde führt die Auftragsart HPB aus und vergleicht die Hash-Werte der Bank aus der HPB-Antwort mit denen aus dem Brief mit den EBCIS-Zugangsdaten. |
| 8. Kunde akzeptiert die Schlüssel. |
| Es gibt 3 Schlüssel-Paare: |
| 1. key pair for encryption (Das ist E im KeyRing) |
| 2. key pair for identification and authentication signature (Das ist X im KeyRing) |
| 3. key pair for electronic signature (ES) (Das dürfte A sein im KeyRing) |
Hab noch rausgefunden, dass die Erstellung des Briefs von dieser Lib nicht unterstützt wird.
| 1.) Wo muss man die public und private keys die wir von der Bank haben (die auch öffentlich online sind) hin machen? |
| 2.) Und was muss man der Bank im ini-Brief schicken? |
| 3.) Warum verwendet die Software die Antwort von der Bank bei INI und HIA gar nicht? Sondern kontrolliert lediglich die Fehler? Ich dachte INI und HIA sei ein Austausch wir schicken was und bekommen was, offensichtlich nicht… |
| 1.) Aufruf Funktion CryptService::generateKeys($this->keyRing) aufgerufen die generiert public Key und private key. Seltsamerweise bekommt die Funktion zwar den keyring aber benutzt nur das Passwort des keyrings! |
| 2.) Aufruf der Funktion CertificateFactory::generateCertificateAFromKeys(..). Dieser Funktion werden die oben erstellten public und private keys übergeben. |
| 3.) CertificateFactory::generateCertificateAFromKeys(..). erstellt das Zertifikat A das eigentlich nur aus den erstellten public und private keys besteht. (Und zwar nicht die man selber holt bei der Bank, sondern die nur anhand des Passworts erstellt worden sind das wir frei gewählt haben). |
| 4.) Aus dem Zertifikat A wird ein Request erstellt und an die Bank geschickt und zwar: |
| 5.) Erstellung des Requests (in xml Format): |
| a.) Funktion des RequestHandler $this->requestFactory->buildINI($certificateA, $dateTime) wird aufgerufen. (Es ist der RequestHandler, der Name der Klasse täuscht etwas.) |
| b.) Im RequestHandler wird die Funktion this->orderDataHandler->handleINI($orderData, $certificateA, $dateTime) aufgerufen. |
| c.) handlePubKeyValue() wird aufgerufen dort wird das Zertifikat beigefügt dem request-xml. Also der public key im Zertifikat befindet sich dann im xml das an die Bank verschickt wird. |
| d.) Usw. Auf jeden Fall wird der Public key so kodiert, dass man nicht drauskommt wie. Kontrolle ist hier sehr schwierig. Frage: Macht die Software eventuell einmal zu viel base64? |
| 6.) Die Antwort wird lediglich auf Error geprüft und nicht weiter verwendet. |
| 7.) Dann wird das Zertifikat A im keyring gesetzt mit private und public key die per Software oben erstellt wurden. Aber das Feld User::A::Zerificate wird nicht gesetzt. Und zum Setzen wird auch nicht etwa die Antwort von der Bank verwendet wie man es erwarten würde, sondern eben die public und private keys die erstellt wurden. Das ist sehr merkwürdig!? |
| 8.) Interessant ist, dass das Feld im KeyRing: User::A::Zerificate (auch Content genannt in ZertificatFactory) gar nicht gesetzt oder benutzt wird. Wird das vielleicht nur bei Franz. Verwendet? Schweizer Banken sollten eigentlich ähnlich wie die Deutschen funktionieren, nicht wie Franz. Aber vielleicht sollte man das auch ausprobieren? |