Re: Online-banking via Inet

[Uwe Brockmann <uwe@netcom.com>]

Am Thu, den 9 Apr 1998 um 21:41:50 +0200 schrieb Hanno Wagner
<wagner@fitug.de>:

> Uwe Brockmann schrieb am 09. April 1998:
> 
> Nur einige Sachen, die auch fuer pgp sprechen:
> 
> > SSL bietet besseres Schluesselmanagement als PGP. Dazu verwendet es
> > Mechanismen, die in PGP fehlen, insbesondere
> > 
> > 	- in den Webbrowser vom Hersteller vorgeladene Zertifikate von
> > 	  kommerziellen Zertifizierungsfirmen
> 
> Trustcenter in Hamburg macht sowas auch fuer pgp-keys.
> 
> > 	- professionelle Schluesselverwaltung durch kommerzielle Zertifizie-
> > 	  rungsfirmen wie z.B. VeriSign und Thawte Consulting, die von den
> > 	  Betreibern von Webservern wie z.B. der Postbank bezahlt werden
> 
> Auch Trustcenter Hamburg.

Die Firma TC TrustCenter in Hamburg stellt kommerziell PGP-Zertifikate
aus (fuer Privatbenutzer umsonst) und ist damit vergleichbar zu Firmen
wie VeriSign und Thawte Consulting, die kommerziell die von SSL verwen-
deten X.509-Zertifikate ausstellen.

Der Unterschied liegt in der Struktur der aus allen weltweit existie-
renden PGP-Zertifikaten bzw. X.509-Zertifikaten gebildeten Graphen.
Nur die X.509-Zertifikate bilden eine Hierarchie.

Der Vorteil der nicht-hierarchischen Struktur des PGP-Zertifikatsgraphen
("web of trust") besteht darin, dass er ohne kommerzielle Zertifikats-
aussteller wie TC TrustCenter auskommen und deshalb umsonst sein kann.
(Kommerzielle Aussteller stoeren jedoch nicht.)

Der Vorteil der hierarchischen Struktur des X.509-Zertifikatsgraphen
besteht darin, dass die Spitze der Hierarchie per Definition universelle
Akzeptanz geniesst, die ueber die Hierarchie nach unten weitergeleitet
werden kann.

Eine X.509-Zertifizierungsinstanz wie z.B. VeriSign oder Thawte
Consulting kann universelle Akzeptanz von oben einkaufen und nach unten
weiterverkaufen. Eine PGP-Zertifizierungsinstanz wie TC TrustCenter kann
prinzipiell keine universelle Akzeptanz verkaufen, da im PGP "web of
trust" mangels Hierarchie normalerweise niemand universelle Akzeptanz
besitzt.

Ich, Uwe Brockmann, hatte geschrieben:
> > Es ist wichtig, den oeffentlichen RSA Schluessel einer Bank sicher an
> > die Bankkunden zu uebermitteln.

Darauf antwortete Hanno Wagner:
> Was ist da bei PGP das Problem? Man kann doch wunderbar
> einen grossen Schluessel generieren, diesen
> veroeffentlichen, genuegend Signiert (sich selbst,
> Trustcenter, Verisign, ne Konkurrenzbank oder so), diesen
> veroeffentlichen, Fingerprints bereitstellen - das sollte
> doch reichen?

Die Verwendung eines Zwischenmannes wie TrustCenter, VeriSign etc. ver-
lagert das Problem nur. Um die Unterschrift des Zwischenmannes zu ueber-
pruefen benoetigt der PGP-Anwender den oeffentlichen RSA Schluessel des
Zwischenmannes. Dieser Schluessel ist genausoschwierig sicher zu ueber-
tragen wie der oeffentliche RSA Schluessel der Bank selbst.

Die Verwendung von Fingerprints ist eine gute Idee, die das Problem ver-
einfacht ohne die Sicherheit nennenswert zu verringern. Bei korrekter
Verwendung von Fingerprints braucht man anstelle eines oeffentlichen RSA
Schluessels nur den viel kuerzeren zugehoerigen Fingerprint sicher zu
uebertragen.

Das Problem liegt letztenendes darin, wie man den ersten oeffentlichen
RSA-Schluessel oder den ersten Fingerprint der Bank oder eines aus-
reichend vertrauenswuerdigen Zwischenmannes in die vom Bankkunden ver-
wendete Verschluesselungssoftware bekommt. Soweit ich weiss laesst sich
dies auf rein elektronischem Wege prinzipiell nicht voellig sicher
machen, d.h. auch nicht mit PGP oder SSL.

SSL-Implementationen gehen das Problem an, indem sie mehrere "erste"
oeffentliche RSA Schluessel mit auslieferen. PGP ueberlaesst das Laden
der ersten Schluessel dahingegen dem Benutzer. Der Sicherheitsgrad von
SSL und PGP haengt hauptsaechlich von der Sorgfalt des Benutzers ab. Bei
korrekter Bedienung duerften beide Systeme extrem sicher sein.

Um die potentielle Sicherheit von SSL-Implementationen voll auszunutzen
muss der Benutzer sicherstellen, dass er korrekt arbeitende Software
verwendet und muss die Fingerprints der mitgelieferten Schluessel
manuell mit Fingerprints vergleichen, die er auf einem sicheren Weg
erhalten hat. 

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.

Man koennte argumentieren, dass Netscape Navigator leichter zu bedienen
ist als PGP, da mit der Installation der Software auch gleich das Laden
der ersten oeffentlichen RSA-Schluessel abgedeckt ist waehrend dies in
PGP ein separater zweiter Schritt ist, der manuell durchgefuehrt werden
muss. Um den zweiten separaten Schritt moeglichst vielen PGP-Anwendern
zu ersparen koennte eine Bank ihren oeffentlichen Schluessel wie von Dir
(Hanno Wagner) vorgeschlagen von moeglichst vielen Zwischenmaennern
unterschreiben lassen. Die Bank muesste dann aber die Zuverlaessigkeit
aller dieser Zwischenmaenner ueberpruefen und alle Zwischenmaenner be-
zahlen. Bei Verwendung von SSL reicht es fuer die Bank aus, sich einen
einzigen Zwischenmann, dessen oeffentlicher RSA-Schluessel zum Lieferum-
fang gaengiger SSL-Implementationen gehoert, auszusuchen und nur diesen
zu bezahlen und auf Zuverlaessigkeit zu ueberpruefen.

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.

Ein Kunde, der aufgrund einer solchen Fehlbedienung Geld verliert,
koennte versuchen, der Bank eine Mitschuld (wissentliche Bereitstellung
eines unsicheren Systemes) nachzuweisen und sie haftbar zu machen. Der
Kunde koennte auch irrtuemlich davon ueberzeugt sein, die Verschluesse-
lung seines Auftrages nicht ausgelassen zu haben. Selbst wenn der Kunde
vor Gericht verliert, koennte die Bank oder Internet-Banking insgesamt
ueber die Presse in Verruf geraten.

Ich war zunaechst darueber enttaeuscht, dass ich auf den Webseiten der
Postbank keine e-mail Adresse fuer die Postbank finden konnte. Jetzt
frage ich mich, ob das Fehlen einer e-mail Adresse vielleicht eine
Sicherheitsmassnahme ist, die es Postbankkunden verwehren soll, ihre
PIN und TANs im Klartext an die Postbank zu versenden.

> Mir ist es ehrlich gesagt lieber wenn ich offline meine
> Mails fertigmachen kann und diese in einem Rutsch
> rueberschieben kann - das geht auch ohne dass ich
> graphisch arbeitebn muss und/oder Java laden muss. Da geht
> mein Rechner regelmaessig in die Knie :-)

Fuer Deinen Wunsch nach off-line Vorbereitung von e-mail Nachrichten
habe ich Verstaendnis. Bedenke aber, dass es beim Internet-Banking oft
wuenschenswert ist, interaktiv zu arbeiten, z.B. wenn man erst den
Kontostand ueberpruefen, dann abhaengig davon eine Ueberweisung taetigen
und dann eine Bestaetigung der Ueberweisung erhalten will. Wenn man
off-line arbeitet, kann das dreimaliges on-line-gehen erfordern.

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.

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.

Uwe Brockmann, uwe@netcom.com