Re: Online-banking via Inet

[Uwe Brockmann <uwe@netcom.com>]

Am Tue, den 7 Apr 1998 um 15:58:45 +0200 (CEST) schrieb PILCH Hartmut
<phm@a2e.de>:
> neko schrieb ueber die Internet-Kontoverwaltungssoftware der Postbank
> 
> > Leider ist die in irgendso einem komischen proprietaeren PC-System-Format.
> > (Windows95, NT und 3.1 und Macintosh) und die Bedienungsanleitung
> > ebenfalls (WinWord Nummernlos).
> 
> Kennt jemand *eine* Bank, die auch etwas gescheites in einem offenen
> Standard-Format anbietet?  Das einfachste und sicherste waere
> Kontoverwaltung per Email, aber das wage ich ja gar nicht mehr zu hoffen.
> Ohne virtuelles Schlangestehen geht es bei keiner Bank.  Aber kann man
> nicht wenigstens irgendwo mit einem Java-Client Schlange stehen?

"neko" ist Simone Demmel <neko@greenie.muc.de>. Leider habe ich ihre
Originalnachricht schon geloescht und kann deshalb nicht direkt Bezug
darauf nehmen.

Ich bin seit vielen Jahren Kunde bei der Postbank und lebe seit kurzem
in den USA. Fuer mich ist Internet-Banking besonders attraktiv weil 
transatlantische Post laenger dauert als innerdeutsche Post. Man kann
Auftraege an die Postbank per Fax erteilen aber das ist teuer.

Deshalb habe ich mir das Internet Banking der Postbank vor ein paar
Wochen etwas genauer angesehen. Ich bin zu dem Schluss gekommen, dass
es meinen persoenlichen Anforderungen genuegt. Ich benutze es seitdem
mit Freude und Zuversicht.

Ich kann mich nicht mehr an alle Details erinnern, aber ich glaube
dass ich mir folgende Unterlagen angesehen habe:

	(1) Die Dokumentation auf den Postbank-Webseiten.
	(2) Die Dokumentation, die mir die Postbank per Post geschickt
	    hat.
	(3) Die FAQ einer Usenet newsgroup fuer Kryptografie
	    (sci.crypt?)
	(4) Die Dokumentation der SSL-Protokolle auf den Netscape
	    Webseiten.
	(5) Die Dokumentation auf den SSLeay Webseiten in Australien.

Das folgende beruht auf meinem derzeitigen Verstaendnis. Bitte
berichtigt alle Fehler! Ich bin kein Kryptografie-Experte und kann mich
auch nicht mehr an alles erinnern, was ich vor ein paar Wochen gelesen
habe.

SSL ist ein Verschluesselungsprotokoll, das urspruenglich von Netscape
entwickelt wurde. Das Protokoll ist veroeffentlicht und wird nicht mehr
alleine von Netscape entwickelt. Die relevanten Versionen sind 2 (2.0?)
und 3 (3.0?). SSL beinhaltet keine Verschluesselungsalgorithmen. Statt-
dessen ist es extra dafuer konzipiert mit vielen verschiedenen Ver-
schluesselungsverfahren zu arbeiten. Wenn ein neues Verschluesselungs-
verfahren entwickelt wird, braucht SSL dafuer nicht geaendert zu werden.

Netscape hat SSL implementiert und in Navigator eingebaut. Der SSL Code
fehlt ganz oder teilweise in der Version 5.0 von Navigator, die in Form
von Quelltext erhaeltlich ist, weil Netscape sonst gegen Exportkontrol-
len der amerikanischen Regierung verstossen wuerde.

Eric A. Young, vermutlich ein Australier, hat SSL implementiert. Sein
Code heisst SSLeay und ist ueber das Internet frei mit Quelltext ver-
fuegbar.

Bei der Internetkontofuehrung mit der Postbank wird zunaechst mit SSL
ein sicherer biderektionaler Kanal zwischen Benutzerbrowser und
Postbankserver aufgebaut. Die eigentliche Kontofuehrung erfolgt erst
nach dem Aufbau des Kanals durch Austausch von Nachrichten mit einem
symmetrischen Kryptoverfahren, z.B. IDEA.

Zum Aufbau des Kanals generiert der Benutzerbrowser zunaechst den
geheimen Schluessel fuer das symmetrische Kryptoverfahren und ueber-
mittelt ihn dann an den Postbankbrowser under Verwendung eines public-
key Kryptoverfahrens. Wie das funktioniert weiss ich nicht mehr genau.
Jedenfalls ist in Netscape Navigator bereits das Zertifikat einer
Zertifizierungsfirma in Suedafrika (Thawte?) eingebaut und der Postbank-
server ist von dieser Firma zertifiziert. Der Postbankserver muss sich
gegenueber dem Benutzerbrowser authentisieren. Beim Verbindungsaufbau
wird sichergestellt, dass Browser und Server schliesslich beide ueber
den geheimen Schluessel verfuegen und damit verschluesselte Nachrichten
entschluesseln koennen. Der Benutzer(browser) authentisiert sich gegen-
ueber dem Postbankserver nicht.

Nach dem Aufbau eines sicheren Kanals muss sich der Benutzer durch
Uebermittlung einer PIN (persoenliche Identifikationsnummer) gegenueber
dem Postbankserver authentisieren, um Lesezugriff auf seine Kontodaten,
z.B. aktueller Kontostand, zu erhalten. Fuer Schreibzugriff, z.B.
Taetigung einer Ueberweisung, ist eine weitergehende Authentisierung
durch eine TAN (Transaktionsnummer) erforderlich. Die PIN wird immer
wieder verwendet. Eine TAN kann nur einmal verwendet werden und ist
anschliessend verbraucht. Die PIN und eine Liste von TANs werden dem
Benutzer von der Postbank per Post zugeschickt.

Der Sicherheitsgrad der ueblichen symmetrischen und public-key Krypto-
verfahren ist abhaengig von der Laenge der verwendeten Schluessel.
Aus Sicherheitsgruenden laesst der Postbankserver nur relativ lange
Schluessel zu. Die amerikanische Regierung verbietet den Export von
Browsern, die die Faehigkeit zur Verwendung langer Schluessel haben.
Netscape exportiert deshalb nur "verkrueppelte" Versionen seines
Browsers, die nur mit kurzen Schluesseln umgehen koennen, die zu kurz
fuer den Postbankserver sind.

Um Postbankkunden den sicheren Zugang zum Postbankserver auch mit ver-
krueppelten Browsern zu ermoeglichen, hat sich die Postbank Zusatz-
software fuer einschlaegige Browser schreiben lassen, die die Faehig-
keit zur Verwendung von langen Schluesseln wiederherstellt. Die
Software heisst "SafeConnect" und ist von der Postbank per Internet
umsonst erhaeltlich wenn auch nicht mit Quelltext. Laut mitgelieferter
Dokumentation verwendet SafeConnect Code von SSLeay.

Ich habe SafeConnect in Verbindung mit Netscape Navigator 4.0? aus-
probiert. Das funktioniert gut. SafeConnect verwendet den symmetrischen
IDEA Kryptoalgorithmus zum Datenaustausch mit dem Postbankserver.

Ich habe auch den Zugang zum Postbankserver mit einer unverkrueppelten
Version von Netscape Navigator 4, die nicht legal exportiert werden
kann, ohne Verwendung von SafeConnect unter Windows 95 ausprobiert. Das
funktioniert noch besser. Erstens ist es einfacher, weil man nur eines
anstatt von zwei Programmen laufen lassen muss. Zweitens hat man eine
Wahl zwischen verschiedenen symmetrischen Kryptoalgorithmen, ist also
nicht auf IDEA festgelegt. (Ich wuesste allerdings nichts was gegen
IDEA spricht.)

Die Postbank bietet meines Wissens SafeConnect nicht fuer Linux an.
Postbankbanking muesste unter Linux aber mit unverkrueppelten Versionen
von Netscape Navigator laufen. Ich habe das nicht ausprobiert, da ich
Linux nicht verwende.

Hartmut Pilch sucht nach einer Bank, die etwas "gescheites in einem
offenen Standard-Format" anbietet. Nach meiner Einschaetzung erfuellt
die Postbank durch Verwendung von SSL diese Forderung.

Hartmut schrieb:
> Das einfachste und sicherste waere Kontoverwaltung per Email, aber das
> wage ich ja gar nicht mehr zu hoffen.

Es mag moeglich sein auf der Basis von e-mail ein System zur Kontover-
waltung aufzubauen, das einfacher und sicherer als das SSL-basierte Ver-
fahren der Postbank ist. Ich weiss aber nicht wie das gehen sollte und
bezweifele, dass es einfach waere ein solches System zu bauen, auch wenn
man auf PGP aufbauen wuerde. Ich muss aber zugeben, dass ich bisher nur
wenig ueber PGP gelesen habe und bin gerne bereit mich eines besseren
belehren zu lassen.

Verwendet PGP nicht das Konzept eines "webs of trust" anstelle von Zer-
tifizierungsinstanzen? Ist das sicher genug, wenn viel Geld auf dem
Spiel steht (Kontofuehrung)? Muesste ein PGP-basiertes Verfahren nicht
auch PINs und TANs oder vergleichbar komplizierte Elemente zur Benutzer-
authentisierung gegenueber dem Bankserver verwenden, um vergleichbare
Sicherheit zu erzielen? Waere es dann noch einfacher als das von der
Postbank verwendete Verfahren?
	
Hartmut schreibt weiter:
> Ohne virtuelles Schlangestehen geht es bei keiner Bank.  Aber kann man
> nicht wenigstens irgendwo mit einem Java-Client Schlange stehen?

Ich glaube mit "virtuellem Schlangestehen" bezieht sich Hartmut auf
Verfahren, die man nicht im Batchbetrieb verwenden kann. Das Verfahren
der Postbank laesst sich nicht ohne weiteres im Batchbetrieb verwenden.

Evtl. koennte man es fuer den Batchbetrieb mit einem Programm wie
WinRunner automatisieren. Aber das waere vermutlich teuer, ineffizient,
unelegant und unzuverlaessig und deshalb keine gute Idee. Ich habe
WinRunner bisher weder verwendet noch auch nur gesehen.

Vielversprechender waere es evtl. auf Basis von SSLeay ein Client-
programm zu schreiben, das ein Batchfile mit Kontofuehrungsanweisungen
liest, sich die zuvor eingetippten PIN und TANs aus einer anderen Datei
saugt und sich dann per SSL mit dem Bankserver unterhaelt.

Aber warum sollte man sich die Muehe machen? Das Postbank-Banking geht
derzeit schon ganz gut. Ich braeuchte ein Batchverfahren erst, wenn
ich sehr viele Transaktionen eingeben muesste.

Was mir an der Postbank nicht gefaellt ist, dass sie gerade ihre Konto-
fuehrungsgebuehren drastisch erhoeht hat :-(. Das von ihr angebotene
Internetbanking ist fuer mich ein Grund, trotzdem bei ihr zu bleiben.

Uwe Brockmann, uwe@netcom.com