Hallo,

wieder mal eine Frage zu FinTS-3: wenn eine Bank verschiedene RDH-Sicherheitsverfahren unterstützt (z.b. RDH-1 und RDH-4), kann es doch vorkommen, dass einige GVs die Sicherheitsklasse 1 haben (und somit mit dem 768-Bit-RDH-1-Schlüssel unterzeichnet werden können), und einige die Sicherheitsklasse 2 (und somit mit dem >1024-Bit-RDH-4-Schlüssel unterzeichnet werden müssen).

Der Anwender müsste dann also *zwei* verschiedene Schlüsselpaare bei der Bank einreichen. Muss er damit auch zwei INI-Briefe generieren und an die Bank schicken, oder kann das so gelöst werden:

- Anwender erzeugt Schlüssel für RDH-1 und reicht den ein
- Anwender erzeugt INI-Brief für RDH-1-Schlüssel, Bank schaltet RDH-1-Schlüssel frei
- Anwender erzeugt RDH-4-Schlüssel und reicht diese ein - dieses Einreichen wird mit dem RDH-1-Signierschlüssel unterzeichnet (der ja durch den vorhergehenden Schritt schon "gesichert" ist).

Laut Spez. haben alle administrativen Segmente die Sicherheitsklasse 1, können also theoretisch mit dem RDH-1-Schlüssel unterzeichnet werden...

Ist das so gedacht? Oder muss für die erstmalige Schlüsseleinreichung *immer* ein INI-Brief erzeugt werden? Oder wird es bankseitig gar nicht unterstützt, dass ein Benutzer sowohl einen RDH-1 als auch einen RDH-4-Schlüssel haben kann?

Viele Grüße
-Stefan-

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

Die Frage ist halt, ob man auch *mehrere* Schlüssel haben kann, also einen RDH-1-Schlüssel und parallel dazu einen RDH-4-Schlüssel. Den RDH-4-Schlüssel braucht man z.B. nur für die GVs mit Sicherheitsklasse>1, ansonsten kann man immer den RDH-1-Schlüssel verwenden.

Welcher Schlüssel konkret verwendet wird, müsste dann die Client-Applikation (bzw. der derunter liegende Kernel) automatisch anhand der zu versendenden Aufträge erkennen... Und falls ein Klasse-2-Auftrag eingereicht werden soll, der Anwender aber noch keinen Klasse-2-Schlüssel (RDH-4) hat, dann kann der Auftrag halt nicht gesendet werden.

Und wie Du schon richtig sagtest - den jeweils verwendeten Schlüssel kann man aushandeln, aber nicht zwingend auf Dialog-Basis, sondern pro Nachricht (denn der verwendete Schlüssel wird im Signatur-Header definiert).

Wenn nun ProfiCash und die Banken das so implementieren, dass das Einreichen eines "höheren" Schlüssels gleichzeitig eine Sperrung des "schwächeren" Schlüssels bedeutet - wurde dann nur ein Teil der HBCI-Spez. implementiert, oder habe ich die Stelle überlesen, wo steht, dass es nur *einen* Schlüssel pro Benutzer gibt und dass das Einreichen eines höheren Schlüssels gleichzeitig die Sperrung des schwächeren bedeutet?

Grüße
-Stefan-

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

Hallo Marc,

RDH1 und RDH 4 Schlüssel sind mitnichten identisch. Der erste Unterschied liegt in der Schlüssellänge (ein 7,68 mm langer Stab kann schliesslich auch nicht mit einem 10,24 mm kangem Stab identisch sein).

RDH 4 Schlüssel kann der Kunde zudem nicht selber generieren, da die RDH 3 und RDH4 Profile zwingend eine Signaturkarte vorraussetzen!

Gruß

Holger

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.

Ich geb ja zu, dass ich in der Thematik "Verschlüsselungsstärke" nicht sehr bewandert bin. Damit hab ich aber mal wieder die Chance hier etwas zu lernen.



Ok, damit könnte aber Stefan´s Ansatz schon von vornherein nicht funktionieren:




Ein großes Fragezeichen tut sich noch auf.



Im HBCI-Kontext wird doch der Schlüssel nur über seine BKN identifiziert. Ich frage mich wie das Banksystem erkennen soll, in welcher Verschlüsselungsstärke der Schlüssel nun kommt.
Beispiel:
Der Kunde hat eine BKN mit zwei Schlüsseln. Wenn er jetzt eine Umsatzabfrage schickt, wie will sich das Banksystem darauf einstellen, welcher Schlüssel dazu folgt. Hier müssten dann ja beide Schlüssel (stärker oder schwächer) akzeptiert werden.

Damit wäre doch die Eindeutigkeit hin, oder das Banksystem muss dann immer nach GVO auswerten welche Schlüsselstärke folgen muss.
Da ich mir nicht vorstellen kann, dass das schon bei irgendeinem Rechenzentrum implementiert ist, ist es doch ziemlich mutig für Stefan so etwas schon umsetzen zu wollen - oder?

Wenn es dann zusätzlich nicht möglich ist zwei Schlüssel auf einem Medium unterzubringen (kann man auf einer Signaturkarte einen zusätzlichen RDH1-Schlüssel unterbringen? - schätze mal: "nein"), wäre ja u.U. wildes Kartenwechseln angesagt.

Gruß
Marc

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

Hallo Holger,

danke für die interessante Antwort. Jetzt hat sich der Knoten wohl bei mir gelöst. Es geht also darum eine unabhängig von der Bank erhaltene Signaturkarte quasi freizuschalten. Ich war bis jetzt immer davon ausgegangen, dass dieser Schlüssel bankbezogen ist.
Ohne den Beitrag länger aufhalten zu wollen (Stefan hat glaube ich noch nichts, was ihm weiter hilft) hab ich aber doch noch eine Frage.
Signaturkarten enthalten ja einen Schlüssel, der von einer Zertifizierungsstelle ausgestellt ist und von dort jederzeit bestätigt (oder auch nicht bestätigt) werden kann. Müssten nicht die Rechenzentren eine Abfrage an die Zertifizierungsstellen implementieren um das eigentliche Konzept der Signaturkarte zu erhalten. Laut Signaturgesetz haben diese Karten auch eine begrenzte Gültigkeit, eine dauerhafte Gültigkeit bei der Bank dürfte also gar nicht sein.
Dann wäre eine Art Freischaltung auch nicht erforderlich, um diesen Schlüssel für gültig zu befinden, weil bei jedem Auftrag eine Gegenprüfung erfolgen würde..


Gruß
Marc