mehrere RDH-Schlüssel

ich würde wie du vermuten, dass beim HBCI-Dialog der verwendete Schlüssel ausgehandelt wird, der dazu passende öffentliche Schlüssel wird ja bei der Bank hinterlegt.

Wenn du nun deinen neuen HBCI-Schlüssel der höheren Stufe mit deinem "alten" Schlüssel bei der Bank einreichst, also einen Schlüsselwechsel durchführst, dann wird der alte Schlüssel dadurch ungültig und du hast automatisch die neue Schlüsselstärke.

Wen ich das richtig im Kopf habe und das nicht falsch verstanden habe, ist dieses genau so für Profi cash 8.2. angekündigt und sollte deshalb auch auf der Rechenzentrumsseite unterstützt werden.

Diese Art des Schlüsselwechsels bedeutet auch wesentlich weniger Arbeit für alle Betroffenen.

Gruß
Raimund

Hallo Stefan,

ich schätze, dass hier wieder Institutseigenarten zum Tragen kommen. Eine Änderung des Schlüssels bedeutet afaik immer, dass der alte Schlüssel gesperrt wird, weil er die gleiche HBCI-Kennung hat und eindeutig sein muss. Wenn das Institut es anbietet, dass mehrere HBCI-Kennungen pro Konto vergeben werden können, könnte man natürlich einen zweiten Schlüssel herkömmlich (mit INI-Brief) erzeugen.
Wenn aber, wie bei manchen Instituten, nur eine Kennung pro Konto/Benutzer erlaubt ist, wäre das nicht möglich.

Aber nach meinem Verständnis sind die Schlüssel (RDH1 und 4) identisch, nur stärker verschlüsselt. Wenn das so ist müsste es ja gehen den Schlüssel so verschlüsselt zu übertragen wie es der GVO fordert. Ich hab aber keine Ahnung, ob das Institutsseitig so akzeptiert wird.

Gruß
Marc

Ne mafi, hier verwechselst du was.

Wenn der HBCI Standard von Teilnehmer spricht, ist damit eine Benutzerkennung gemeint. Es ist also die Rede davon ob pro Benutzerkennung mehrere (verschieden starke) Schlüssel parallel existieren können.

Es ist nicht die Rede davon ob pro Bankkunde (Person) -umgangssprachlich auch Teilnehmer- mehrere Benuterkennungen existieren können. Oder pro Konto / Stammnummer oder wie auch immer...

Technisch ist die Geschichte mit mehreren Schlüsseln pro BKN sicher nicht unmöglich - ob das jemand praktisch einsetzt ist ja eine andere Frage.
Nur möchte Stefan wohl eine spezifikationsgereche Software schreiben, die sowas eben auch kann - wenn der Standard es denn so verlangt.

Und ja, ein Schlüssel muss eindeutig sein, das heisst aber im Umkehrschluss nicht das eine Benutzerkennung nur einen Schlüssel haben darf. Es muss nur eindeutig feststellbar sein, welcher Schlüssel dann zu welcher BKN gehört.

Praktisch:

Kunde K hat eine Benutzerkennung B mit zwei Schlüsseln die x und y heissen.
Empfäng das Banksystem nun eine Nachricht mit Schlüssel x weiss man doch genau welche Rechte im zugehörigen HBCI-Vertrag mit BKN B vereinbart sind. Gleiches gilt für Schlüssel y...

Was eben nicht geht ist das Schlüssel x zu zwei BKN gehört.

Das würde also -nach Holgers- Posting bedeuten das mit einer BKN gleichzeitig mit Sicherheitsdatei (RDH1) und Signaturkarte (RDH3/4) gearbeitet werden kann.

Hallo Marc,


Auf das RDH4 Profil bezogen ja. Beim RDH2 oder RDH5 Profil kann man dies so nicht grundsätzlich ausschließen (ohne Bewertung, ob es Sinn macht)


Unter FTAM hat dies beim Schlüsselwechsel von A003 auf A004 funktioniert. So abwegig ist das also nicht.



Ich wage zu behaupten, dass dies mit HBCI/FinTS Bordmitteln möglich wäre. Zumindestens sollte es möglich sein für einen geschlossenen Dialog jeweils einen anderen Schlüssel zu verwenden - wenn das Hintergrundsystem so etwas erlauben würde. Aus Sicherheitsgründen fände ich es problematisch, wenn zu einer Benutzerkennung mehr als ein Schlüssel aktiv sein kann!



Auf keiner mir bekannten Karte kann man Schlüssel unterschiedlicher Länge aufbringen. Bei der Signaturkarte wäre das aufbringen eines zusätzlichen Schlüssels zudem unsinnig. Die Signaturkarte soll die händische Unterschrift ersetzen, wofür sollte der Anwender dann eine weitere Unterschrift benötigen. Die Signaturkarte soll ja mit allen Instituten (die FinTS 3.0) unterstützen funktionieren. Der Anwender muss nur noch seine Benutzerkennung zusätzlich aufbringen.

Gruß

Holger