schlüsselkonvertierung

 
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 2
Dabei seit: 02 / 2017
Betreff:

schlüsselkonvertierung

 · 
Gepostet: 22.02.2017 - 11:26 Uhr  ·  #1
Hallo,

ich würde gern die mit Genocash erstellten Keys exportieren um sie mit einem anderen Programm / Script zu nutzen, dazu benötige ich die Schlüssel im DER oder PEM format.

Kann mir jemand sagen in welchem Format GenoCash die Schlüssel ablegt, sodass ich diese konvertieren kann, oder wie ich die Schlüssel im entsprechenden Format aus GenoCash gesondert exportieren kann?

Vielen Dank

Michael
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 8112
Dabei seit: 08 / 2002
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 23.02.2017 - 08:12 Uhr  ·  #2
Hallo Michael,
meinst du die RDH-Schlüssel aus EBICS oder HBCI?
Das hat nichts mit den üblichen SSL-Verschlüsselungen zu tun, was immer du vor hast, es wird nicht funktionieren.
Schau dir besser aqbanking oder Hibiscus an oder auch die Dokus zur ddbac für Entwickler.
Gruß
Raimund
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 61
Beiträge: 7128
Dabei seit: 03 / 2007
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 23.02.2017 - 11:01 Uhr  ·  #3
Um es etwas zu präzisieren: HBCI- und EBICS-Schlüssel werden von den einzelnen Kundenprodukten nicht in "einem Format" abgelegt, sondern jeder Hersteller hat da sein eigenes Format. Natürlich völlig inkompatibel zu anderen Herstellern. Vielfach auch nicht so dukumentiert, dass jemand anderes etwas damit anfangen könnte. Es gibt manche Produkte, die können bestimmte Fremdschlüsseldateien lesen, wenn dies explizit vom Hersteller genannt ist - aber schon das ist der Ausnahmefall.

Wenn man also das Produkt wechselt, bleit einem in den meisten Fällen nichts übrig, als den Zugang bankseitig zurücksetzen zu lassen und mit dem neuen Produkt neue Schlüssel zu generieren. Wenn man mehrere Produkte gleichzeitig einsetzen möchte, dann muß man bankseitig mehrere Zugänge beantragen, von denen dann jeder mit seinem eigenen Schlüssel läuft (sofern die Bank das macht, die Commerzbank z.B. gibt nur einen Zugang raus, damit kann eine Person zwangsweise nur eine Software einsetzen). Weiterhin ist es auch schon deswegen nicht möglich, einen Schlüssel in mehreren Umgebungen gleichzeitig einzusetzen, da sowohl bank- als auch kundenproduktseitig Signaturzähler mitgeführt werden, die synchron geführt werden müssen. Somit würde nach einer Transaktion mit einer Software der Schlüssel bei der anderen Software Probleme machen, weil da der Zähler ja nicht fortgeschrieben wurde...
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Nürnberg
Beiträge: 679
Dabei seit: 12 / 2005
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 23.02.2017 - 17:37 Uhr  ·  #4
Zitat geschrieben von msa

Weiterhin ist es auch schon deswegen nicht möglich, einen Schlüssel in mehreren Umgebungen gleichzeitig einzusetzen, da sowohl bank- als auch kundenproduktseitig Signaturzähler mitgeführt werden, die synchron geführt werden müssen. Somit würde nach einer Transaktion mit einer Software der Schlüssel bei der anderen Software Probleme machen, weil da der Zähler ja nicht fortgeschrieben wurde...


Das ist so nicht richtig. Man kann bei allen mir bekannten Banken ein und denselben Schlüssel auf verschiedenen Umgebungen einsetzen. Vorausgesetzt man verwendet eine Client-Software, die Kundensystem-ID und Signatur-ID getrennt vom Schlüssel verwalten kann. In dem Fall geht das ohne Probleme!
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 8112
Dabei seit: 08 / 2002
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 23.02.2017 - 20:16 Uhr  ·  #5
man könnte das so verstehen, als wäre der Zähler unabhängig und würde jew. separat vom Client in einer separaten Datei verwaltet.
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: München
Homepage: subsembly.com/
Beiträge: 4446
Dabei seit: 11 / 2004
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 24.02.2017 - 15:41 Uhr  ·  #6
Hallo,

auch in der Subsembly FinTS API (und alle darauf basierenden Produkte) werden Kundensystem-ID und Signaturzähler NICHT in der Schlüsseldatei sondern auf dem Kundensystem verwaltet. So kann der gleiche Schlüssel problemlos auf mehreren Systemen verwendet werden. IMHO war das ja der eigentliche Sinn der Kundensystem-ID. Sonst würde man sie ja auch Sicherheitsmediums-ID nennen.
Benutzer
Avatar
Geschlecht:
Herkunft: Korschenbroich
Alter: 52
Beiträge: 6108
Dabei seit: 02 / 2003
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 24.02.2017 - 15:59 Uhr  ·  #7
Zitat geschrieben von subsembly

So kann der gleiche Schlüssel problemlos auf mehreren Systemen verwendet werden. IMHO war das ja der eigentliche Sinn der Kundensystem-ID. Sonst würde man sie ja auch Sicherheitsmediums-ID nennen.

Genau das sollte verhindert werden, bzw. transparent gemacht werden. Denn so kann jeder eine Schlüsseldatei kopieren und in einer beliebigen Umgebung weiter verwenden ohne das es jemand merkt. DeuBa und DreBa haben damals Dialoge hart abgelehnt, wenn die Id nicht passte. Die Kopierbarkeit des Sicherheitsmediums Schlüsseldatei erweist sich derzeit bei der PSD2 und der Anforderung an einer Strong Authentifikation als Problem!

Viele Grüße

Holger
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 2
Dabei seit: 02 / 2017
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 24.02.2017 - 17:08 Uhr  ·  #8
Vielen Dank allesamt für die Informationen, das die SChlüssel in einem eigenen Format gespeichert werden ist schade.

Ich habe jetzt mit meiner Bank gesprochen und diese erstellt mir eine neue UserID mit den entsprechenden Rechten, damit ich das migrieren und gleichzeitig testen kann.

Viele Grüße und nochmals Vielen Dank!
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 8112
Dabei seit: 08 / 2002
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 25.02.2017 - 17:44 Uhr  ·  #9
Ich versteh die Prozesse um den Signaturzähler herum wohl nicht ganz, eventuell kann mich jemand aufklären.
Dieser Zähler soll doch dazu dienen, indem er mit dem Bankrechner synchron läuft, dass alte "Zustände", also eine Kopie der Datei nicht zum Unterschreiben neuer Aufträge genutzt werden können.
Wenn der Zähler aber ausschließlich in der Datenbank der Anwendung und nicht auf dem Sicherheitsmedium verwaltet würde, könnte man auch nicht fehlerfrei mit einer Kopie der Schlüsseldatei arbeiten, oder? Die Zählerstände müssten gerade dann doch auseinanderlaufen.
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 61
Beiträge: 7128
Dabei seit: 03 / 2007
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 25.02.2017 - 21:40 Uhr  ·  #10
So wie ich das jetzt verstanden habe, ist die Kombination aus Kundensystem-ID+Signaturzähler das, was nicht auseinanderlaufen darf.

Wenn man also zwei unterschiedliche Systeme mit zwei unterschiedlichen Kundensyste-IDs hat, dann kann man den gleichen Schlüssel (also die Kopie de Datei) auf diesen beiden Systemen parallel verwenden, da für jede davon ein eigener Signaturzähler verwendet wird... zumal offenbar inzwischen manche Kundenprodukte zu Beginn JEDER Kommunikation frisch synchronisieren und dabei eine neue Kundensystem-ID erhalten, so daß der Signaturzähler immer bei 0 beginnt. Und dieser "Kopierschutz" des Schlüssels über Signaturzähler konnte ja noch nie funktionieren, da er ja immer über eine Synchronisierung aushebelbar war. Ich gehe vielmehr davon aus, daß er dazu dient, Doppeleinreichungen (vom selben System) zu unterbinden, wenn bei einem Dialog vorher etwas nicht geklappt hatte.
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Nürnberg
Beiträge: 679
Dabei seit: 12 / 2005
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 26.02.2017 - 00:39 Uhr  ·  #11
Signatur-IDs dienen tatsächlich dazu Doppeleinreichungen zu verhindern. Serverseitig wird geprüft, ob die aktuelle Signatur-ID größer ist wie die Signatur-ID der letzten Nachricht. Dies wird jeweils pro Kundensystem-ID überprüft. Bei kartenbasierten Sicherheitsprofilen wird die Signatur-ID direkt von der Karte aus einem Bedienzähler (Anzahl der berechneten Signaturen) ermittelt. Bei Datei-basierten Profilen obliegt die Verwaltung der Signatur-ID dem Kunden-Produkt. Ein Sicherheitsmerkmal ist das nicht, sondern soll einfach versehentliche Doppeleinreichungen, z.B. aufgrund eines Bugs in der Klient-Software, vermeiden.

Die Kopie einer Datei nützt einem ja nix, wenn man davon ausgeht, dass diese verschlüsselt vorliegt und das Passwort nicht bekannt ist. Genauso gut kann ich eine HBCI-Karte mopsen. Ohne PIN ist das wertlos.
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 61
Beiträge: 7128
Dabei seit: 03 / 2007
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 26.02.2017 - 01:30 Uhr  ·  #12
Naja, bei den Angriffen gegen Schlüsseldateien geht man natürlich davon aus, dass das Passwort durch Trojander- ode sonstigen Angriff bekannt ist. Dann noch die Datei kopiert und Tür und Tor sind offen - ohne dass es der Bestohlene merkt. Bei Karten merkt der Beklaute wenigstens, daß die Karte nicht mehr da ist... Und trotzdem sind mir Dateien lieber als Karten, da das Handling gerade bei vielen Bankverbindungen einfach besser ist, das ist mit Karten(wechsel) einfach nicht sinnvoll darstellbar. Solange man nicht Institutsübergreifend EINE Karte mit EINER PIN verwenden kann (wie bei EBICS) bleibt das in meinen Augen eine Lösung für Lieschen Müller, die damit ihr eines einziges Bankkoto bedient und damit wenigstens nicht auf Phishing reinfallen kann.
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 8112
Dabei seit: 08 / 2002
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 26.02.2017 - 11:45 Uhr  ·  #13
Du bist ja eine Ausnahme, das Buchhalter mehr als drei Banken parallel bedienen müssen, ist schon ziemlich selten. Bei RDH und RAH Karten könntest du dann auch die PIN ändern und bei allen die gleiche nutzen. Den Kartenwechsel empfinden die meisten Menschen als zumutbar und der Sicherheitsgewinn ist immens.

Zurück zum Thema:
Dass das Konstrukt ausschließlich zur Verhinderung irrtümlicher Doppelbuchungen gedacht ist, hätte ich nicht gedacht.
Ich hatte bisher vermutet, dass sich die Kombination von ID und Zähler zusätzlich auch zur Absicherung eignet - dies aber aktuell noch nicht zum Einsatz kommt, weil keine Angriffe vorkommen.

Wenn das System flexibler wäre, könnte sogar die ID z.B. mit Hard- und Softwaremerkmale verbinden, ähnlich, wie dies Microsoft mit den Lizenzen macht. Einen Rechnerwechsel oder ein Softwareupdate würde man dann z.B. mit einer TAN oder Freischaltcode zusätzlich bestätigen müssen.
Gruß
Raimund
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 61
Beiträge: 7128
Dabei seit: 03 / 2007
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 26.02.2017 - 15:02 Uhr  ·  #14
Zitat geschrieben von Raimund Sichmann
Wenn das System flexibler wäre, könnte sogar die ID z.B. mit Hard- und Softwaremerkmale verbinden, ähnlich, wie dies Microsoft mit den Lizenzen macht. Einen Rechnerwechsel oder ein Softwareupdate würde man dann z.B. mit einer TAN oder Freischaltcode zusätzlich bestätigen müssen.

Diese Verheiratung von irgendwelchen Zugängen mit Hardware sehe ich immer kritisch. Musterbeispiel früher war Premiere. Die haben eine Chipkarte ausgeteilt, die man in früheren Jahren problemlos z.B. zuhause und in der Ferienwohnung in den Receiver stecken konnte. Später wurde diese Karte dann bei der ersten Benutzung "mit dem Receiver verheiratet". Folge war, dass man fürderhin immer den Receiver komplett mit ins Wochenende nehmen mußte (hat ein Freund von mir so gemacht). Damit stellt sich dann die Frage, wozu überhaupt die Chipkarte.. :-)

In unserem Fall ist gerade heutzutage auch davon auszugehen, dass das Banking nicht IMMER auf dem GLEICHEN Gerät stattfindet. Selbst bei Privatpersonen kann das heutzutage eine Kombination aus Schreibtischrechner, Notebook, Tablet und Smartphone sein, in der pofessionellen Umgebung eine Kombi aus Bürorechner und Heimbürorechner und Notebook usw. Klar man könnte noch eine Verwaltung einbauen, bei denen Bankseitig für einen Schlüssel mehrere Rechner freigegeben werden können, gern auch mit einer TAN oder Ähnlichem. Nur gehe ich davon aus, daß das den Banken (und sicher auch vielen Nutzern) schon wieder zu kompliziert ist.

Was ich in dem Zusammenhang nicht wirklich verstehe ist: Wenn es - zugegebenermaßen - Angriffsszenarien für die Schlüsseldatei gibt, dann müßte man doch EBICS sofort komplett als "total unsicher" sperren? Da hab ich im schlechtesten Falle EINE Schlüssel-Datei für beliebig viele Banken, das Dateipasswort wird über die Rechnertastatur eingegeben oder ist in der Softwae hinterlegt und die dahinterliegenden Konten bieten meist mehr "Potential", als Lieschen Müllers Lohn-Konto. Warum wird da EBICS so betrieben und niemand hat Bauchschmerzen?
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 8112
Dabei seit: 08 / 2002
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 26.02.2017 - 17:29 Uhr  ·  #15
Zitat geschrieben von msa
In unserem Fall ist gerade heutzutage auch davon auszugehen, dass das Banking nicht IMMER auf dem GLEICHEN Gerät stattfindet. Selbst bei Privatpersonen kann das heutzutage eine Kombination aus Schreibtischrechner, Notebook, Tablet und Smartphone sein, in der pofessionellen Umgebung eine Kombi aus Bürorechner und Heimbürorechner und Notebook usw. Klar man könnte noch eine Verwaltung einbauen, bei denen Bankseitig für einen Schlüssel mehrere Rechner freigegeben werden können, gern auch mit einer TAN oder Ähnlichem. Nur gehe ich davon aus, daß das den Banken (und sicher auch vielen Nutzern) schon wieder zu kompliziert ist.
Man wird bei Sicherheitsfragen immer im Kompromissen leben.
Wir haben es hier mit zwei unterschiedlichen Situationen zu tun: Einmal ein Rechnerwechsel - das passiert nur einmal, das kann man abhaken.
Und die parallele Nutzung zweiter Systeme: Was spräche gegen zwei parallele Zugänge? Ich glaube nicht, dass es hier ein Verständnisproblem geben muss und die beiden Dateien könnten auch auf einem Stick gut zusammen leben. Zumindest wenn die Kundensoftware auch "ordentliche" (Datei-)Bezeichnungen zulässt und diese auch vernünftig anzeigt.

Bei EBICS ist man sicherlich der Meinung, dass es sich um Firmenzugänge handelt, bei denen ein professioneller Umgang mit der Sicherheit vorausgesetzt werden kann.
Ich stell mir gerade vor, wie einige Admins jetzt anfangen zu grinsen - oder auch zu weinen beginnen... :devil:
Benutzer
Avatar
Geschlecht:
Beiträge: 6691
Dabei seit: 06 / 2008
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 26.02.2017 - 18:30 Uhr  ·  #16
teilweise gibt es ja das verheiraten "in einer gewissen Art" schon bspw. SMSTAN (Handynummer) oder besser PushTAN (Endgerät bzw. App)
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 61
Beiträge: 7128
Dabei seit: 03 / 2007
Betreff:

Re: schlüsselkonvertierung

 · 
Gepostet: 26.02.2017 - 19:08 Uhr  ·  #17
Zitat geschrieben von infoman
teilweise gibt es ja das verheiraten "in einer gewissen Art" schon bspw. SMSTAN (Handynummer) oder besser PushTAN (Endgerät bzw. App)

Richtig. Und bei pushTAN nervt es prompt gleich wieder. Mein Smartphone hat ein bestimmtes Problem, und der Herstellersupport hätte gerne, daß ich es testweise mal per Werksreset platt mache. Nachdem ich mir aber nahezu 100% sicher bin, dass das nichts bringen wird, weil es sich bestimmt um einen Firmwarefehler handelt, sträube ich mich dagegen - nicht zuletzt weil ich damit dann eine zweistellig Anzahl von entsprechenden Apps (pushTAN, photoTAN, secureapp ect.) neu initialisieren müßte. *grusel*. Oder wo es auch nervt: Die secureGo App von Fiducia ist meines Erachtens nicht zuendegedacht. Bei bestimmten Konstellationen läßt sie sich nicht mehr starten, wenn der zuerst eigerichtete Bankzugang nicht mehr existiert. Diesen kann man aber auch nicht löschen, womit man dann zwangsweise die komplette App zurücksetzen muß - und dann von sämtlichen Banken, die drin waren, wieder Freischalteunterlagen anfordern. Und das persönlich beim Mitabeiter, weil man ja kein funktionierendes TAN-Verfahren mehr hat, um das selber zu tun. Somit ist die Verheiratung auch wiede blöde...
Gewählte Zitate für Mehrfachzitierung:   0