Re: Online-banking via Inet

[Uwe Brockmann <uwe@netcom.com>]

Am Sat, den 11 Apr 1998 um 16:42:39 +0200 (CEST) schrieb PILCH Hartmut
<phm@a2e.de>:
> Es sollte einer Bank auch moeglich sein, die oeffentlichen Schluessel
> ihrer Kunden so zu zertifizieren, wie z.B. FITUG dies tut.  Wozu muessen
> da ueberhaupt Mittelmaenner eingeschaltet werden?

Mittelmaenner sind nicht erforderlich. Umso weniger Mittelmaenner ver-
wendet werden, desto sicherer ist das Verfahren. Mittelmaenner koennen
aber nuetzlich sein, da sie quasi fuer die Vertrauenswuerdigkeit anderer
buergen koennen. Deshalb haben Mittelmaenner sowohl bei SSL als auch bei
PGP eine grosse Bedeutung.

Ich, Uwe Brockmann, hatte geschrieben:
> > Um die potentielle Sicherheit von PGP voll auszunutzen, muss der
> > Benutzer sicherstellen, dass er eine korrekt arbeitende Version von PGP
> > verwendet. Ausserdem darf er nur Schluessel laden, die er entweder auf
> > einem sicheren Weg erhalten oder mit auf sicherem Wege erhaltenen Fin-
> > gerprints ueberprueft hat.

Darauf antwortete PILCH Hartmut <phm@a2e.de>:
> Das gleiche Prinzip wie bei den TANs, die er im Fensterumschlag erhalten
> hat.  Warum nicht stattdessen gedruckte PGP-Verifizierdaten im Umschlag?

Ich habe sicherheitstechnisch nichts gegen gedruckte PGP-Verifizierdaten
im Briefumschlag einzuwenden.
  
Ich, Uwe Brockmann, hatte geschrieben:
> > Das groesste Problem bei der Verwendung von PGP fuer Banktransaktionen
> > sind moeglicherweise Fehlbedienungen. Ein offensichtliches Beispiel fuer
> > eine Fehlbedienung von PGP, die bei SSL ausgeschlossen ist, waere ein
> > Benutzer, der die Verschluesselung seines Auftrages an die Bank aus Ver-
> > sehen ganz auslaesst und ihn im Klartext abschickt. Wenn alle Leute die
> > heute Netscape Navigator oder Microsoft Internet Explorer verwenden
> > morgen PGP verwenden wuerden, dann wuerde diese Art der Fehlbedienung
> > sicherlich vorkommen.

Darauf antwortete PILCH Hartmut <phm@a2e.de>:
> Diesen Fehlern koennte ein Mailserver sehr leicht vorbeugen, indem er
> nur korrekt verschluesselte Auftraege annimmt.

Das geht nicht. Fuer die Uebertragung von e-mail im Internet wird ein
standartisiertes Protokoll namens SMTP verwendet. SMTP zwingt alle
Mail Server dazu, ueber Annahme bzw. Ablehnung einer e-mail zu entschei-
den, bevor sie den Inhalt gesehen haben.

> Eine ordentliche Kontoverwaltung per Email wuerde einschliessen, dass
> die Bank bei jeder Veraenderung des Kontostandes eine Email sendet.

Dies wuerde den Implementierungs- und Verwaltungsaufwand erhoehen. Um
von sich aus e-mail an einen Bankkunden schicken zu koennen, muss der
Bankserver die e-mail Adresse des Bankkunden kennen und langfristig
speichern. Dies ist bei einem SSL-basierten Verfahren nicht erforder-
lich.

Wenn die e-mail vertrauliche Daten enthalten soll, muss sie verschlues-
selt werden. Dazu muss der Bankserver den oeffentlichen Schluessel des
Bankkunden kennen. Hierzu ist folgendes erforderlich:

	(1) Der Bankkunde muss manuell (durch Aufruf eines zum Liefer-
	    umfang von PGP gehoerenden Programmes) ein RSA-Schluessel-
	    paar erzeugen.

	(2) Der Bankkunde muss den erzeugten oeffentlichen Schluessel
	    auf sicherem Weg an die Bank uebermitteln.

	(3) Der Bankkunde muss den erzeugten geheimen Schluessel lang-
	    fristig auf einem Geraet (Computer, Diskette, etc.)
	    speichern und gegen Verlust und Veroeffentlichung schuetzen.

	(4) Der Bankserver muss den erhaltenen oeffentlichen Schluessel
	    des Bankkunden auf einem Geraet langfristig speichern und
	    gegen Verlust und Manipulation schuetzen. 

Diese vier Schritte sind bei einem SSL-basierten Verfahren nicht erfor-
derlich. Bei SSL wird das Schluesselpaar des Bankkunden gewissermassen
bei jedem Verbindungsaufbau automatisch neu generiert und beim Verbin-
dungsabbruch geloescht. Weder der oeffentliche noch der geheime Schlues-
sel braucht laenger gespeichert zu werden als die Verbindung besteht.
	
Ich, Uwe Brockmann, hatte geschrieben:
> > Das Postbank Internet-Banking kommt ohne Java aus. Ohne Grafik geht es
> > derzeit nicht. Im Prinzip liesse sich aber z.B. auf Basis von SSLeay
> > rein textbasierte Software zum Internet-Banking entwickeln ohne dass die
> > Kooperation z.B. der Postbank erforderlich waere. Diese Software koennte
> > beim on-line-gehen nebenbei auch e-mail abholen und abschicken.

Darauf antwortete PILCH Hartmut <phm@a2e.de>:
> D.h. nur mit HTML, Javascript und SSL?  Jedes Programm, das diese drei
> spezifikationsgetreu anwendet koennte die Arbeit leisten? 

Ja. JavaScript ist allerdings nicht erforderlich. Lynx mit SSL-Erwei-
terung wuerde z.B. schon ausreichen. Da man SSL in Form von SSLeay
umsonst mit Quelltext erhalten kann, duerfte der Entwicklungsaufwand
nicht allzu hoch sein. Es hat sich bisher nur niemand die Muehe gemacht.
 
Ich, Uwe Brockmann, hatte geschrieben:
> > E-mail Nachrichten koennen verlorengehen. Bei SSL wird in alle nach Auf-
> > bau eines sicheren Kanals ausgetauschten Nachrichten eine Sequenznummer
> > mit hineinkodiert. Korrekte SSL-Implementationen koennen verlorengegan-
> > gene oder absichtlich abgefangene Nachrichten deshalb spaetestens bei
> > Erhalt der naechsten Nachricht sowohl auf Server- als auch auf Client-
> > Seite entdecken und entsprechend reagieren. Bei einem e-mail/PGP-ba-
> > sierten System muesste man das manuell machen, z.B. wenn man einen Tag
> > nach Erteilung eines Auftrages noch keine bestaetigende e-mail erhalten
> > hat.
 
Darauf antwortete PILCH Hartmut <phm@a2e.de>:
> Warum einen Tag danach?  Genuegt nicht eine Minute?  

Den Zeitraum von einem Tag hatte ich willkuerlich als Beispiel gewaehlt.
Ich behaupte nicht, dass ein Tag eine besonders gute Wahl ist.

Die Uebertragung einer einzigen kurzen e-mail Nachricht im Internet von
A nach B wird oft wesentlich laenger dauern als eine lange SSL-Inter-
aktion ueber die gleiche Distanz von A nach B. Dies liegt daran, dass
sich SMTP Server oft wegen Ueberlastung weigern, eine e-mail Nachricht
anzunehmen. Der Versuch der Uebermittlung der Nachricht an den wider-
spenstigen SMTP Server wird dann mehrfach in grossen (z.B. mehrstuen-
digen) Abstaenden wiederholt. Der Versuch wird normalerweise erst nach
mehreren Tagen aufgegeben. Erst dann erhaelt der Absender eine Fehler-
meldung per e-mail. Eine Minute Wartezeit genuegt deshalb oft nicht. Ein
Tag Wartezeit koennte auch zu kurz sein.

Uwe Brockmann, uwe@netcom.com