Vorschlag für eine Produktinnovation 

Hauke Laging, Peter-Vischer-Straße 29, 12157 Berlin, Tel.: 030/32603660, mobil: 0172/7630883, E-Mail: hauke@laging.de, WWW: http://www.hauke-laging.de/

Nationale Positivliste für Zertifikate phishinggefährdeter Organisationen

Version 1.1/2.3, 02.06.2008

Inhalt

Zusammenfassung — Übersicht

Die praktische Bedrohung durch Phishing soll dadurch reduziert werden, dass den Internetnutzern der Umgang (Verifikation) mit Zertifikaten erleichtert wird (Automatisierung).

Ausgangslage – das Problem des Kunden — Übersicht

Wenn man Leute, die sich viel mit Computersicherheit befassen, fragt, wie das Problem Phishing nachhaltig zu lösen sei, dann bekommt man meist zu hören: mit Zertifikaten für Webseiten und E-Mails. Leider ignoriert diese Einstellung völlig, dass Zertifikate einen eng begrenzten Zweck haben, diesen zwar gut erfüllen, aber das Phänomen Phishing aus mehr als nur dem Problem der sicheren Domainzuordnung besteht.

Phishing ist ganz allgemein die Täuschung des Opfers, und zwar (in der Regel) die über die organisationale Zugehörigkeit des Absenders – nicht die technische! Die XY-Bank könnte unter einigen Webadressen präsent sein und auch von unterschiedlichen E-Mail-Adressen aus mit ihren Kunden kommunizieren, wobei alles seine rechtliche und technische Ordnung hätte. Da ein Phisher sich prinzipiell problemlos ein Zertifikat für seine Domain holen kann (bei dem sogar irgendwie XY-Bank im Organisationsfeld auftauchen könnte), ist die Feststellung, dass eine Webseite/E-Mail mit einem gültigen Zertifikat geschützt ist, erst mal nichts wert. Die Lücke des praktischen Schutzes liegt eben darin, dass der Empfänger typischerweise eben keine verlässliche Prüfung der zugehörigen Domain durchführt und erst recht keine gründliche Prüfung des Zertifikats.

Dass man vom Kunden verlangt, misstrauisch zu werden, nur weil sich die Domain geändert hat, ist deshalb mehr ein Notnagel als eine saubere technische Argumentation.

Problembewusstsein

Die Problematik ist allen gefährdeten Organisationen und den meisten ihrer Kunden klar.

Und selbst diejenigen, die sich auf Grund ihres Wissens vor Phising-Angriffen sicher fühlen, haben gegen eine bequemere Lösung sicher nichts einzuwenden.

Ziel — Übersicht

Das Ziel dieses Vorschlags ist die Einrichtung einer zweiten Beglaubigungsebene für Zertifikate. Das heutige System bestätigt die Bindung des Absenders an eine Domain. Was der Internetnutzer aber eigentlich will, ist ein Zertifikat, das die Seriösität des Absenders bestätigt. Das können klassische CAs nicht leisten, jedenfalls nicht innerhalb der technischen Möglichkeiten des bestehenden Systems. Es erscheint auch nicht sinnvoll, weil dann eine Vermischung stattfände.

Ein wirklich verlässlicher Schutz soll dadurch gewährleistet werden, dass eine geeignete Instanz (typischerweise nur für ihren Staat) die Zertifikate der phishinggefährdeten Organisationen (Banken, Auktionsplattformen usw.) mit einem eigenen Schlüssel unterschreibt und auf diese Weise deutlich macht, dass man bei einem Kontakt, der mit diesem Zertifikat geschützt ist, auf der sicheren Seite ist. Da die Zahl der gefährdeten Organisationen recht beschränkt ist, erscheint eine Positivliste als der sinnvollste Weg. Damit läuft man nie Gefahr, den Phishern einen Schritt hinterher zu sein.

Dieses Verfahren hätte nicht den Ausschließlichkeitscharakter der üblichen Signierung von Zertifikaten (nur eine CA pro Zertifikat). Es könnten sich beliebig viele Organisationen damit befassen, solche Positivlisten zu erstellen, wobei (mangels Sinn) wenig wahrscheinlich ist, dass es viele (für dasselbe Gebiet) werden. Wem er dann vertraut, das bliebe – wie bei PGP – ganz dem Nutzer überlassen.

technische Umsetzung — Übersicht

Anforderungen

Realisierung

Die technische Basis wäre ein Browser-Add-on (auch für E-Mail-Clients denkbar). Dieses Add-on würde bei jedem Zugriff auf eine SSL-Seite die Datenbank(en) abfragen, die der Anwender konfiguriert hat, ob sie für dieses Zertifikat eine Beglaubigung haben. Wenn ja, würde es sie herunterladen und mit dem bei der Aktivierung dieser Datenbank hinterlegten Schlüssel prüfen. Für weitere Zugriffe würde diese Signatur dann gecacht (aber man hätte dann einen CRL-Check; aus Performancegründen sinnigerweise nur einen pro z.B. Tag, mit dem geprüft wird, ob sich auf der CRL überhaupt irgendwas getan hat, was ja fast nie vorkommen sollte).

Wenn eine Signatur gefunden wird, wird dies durch eine auffällige optische Signalisierung kundgetan. Der Anwender muss sich also nur noch merken, dass bei Zugriffen auf die Webseite der XY-Bank immer dieses Symbol erscheint (erscheinen muss).

Wird keine Signatur gefunden, hat das natürlich zunächst einmal nichts zu bedeuten – denn das gilt für die meisten aufgerufenen Webseiten. Es bietet sich allerdings an, nach Ähnlichkeiten zwischen dem aufgerufenen Domainnamen und den Domainnamen (und Organisationsnamen) in den beglaubigten Zertifikaten zu suchen. Wenn also xy-bank.de beglaubigt ist und der Zugriff auf xy-bank.ru erfolgt, dann wird einerseits die Unbedenklichkeit nicht signalisiert, und andererseits sollte dann gewarnt werden, dass da vermutlich gerade jemand Unanständiges im Schilde führt. Das schützt nicht davor, dass jemand die Seite xy-bank.de optisch auf foo.ru nachbaut, aber der Anwender soll sich ja nur noch auf die Unbedenklichkeitssignalisierung verlassen. Wenn er nicht mal da hinkriegt, sollte er nicht auf Kulanz seiner Bank hoffen.

Hilfreich ist, dass für die Umsetzung dieser Maßnahme die Kooperation der geschützten Organisationen nicht erforderlich ist.

Auf jeden Fall sollte die beglaubigende Organisation in kurzen Abständen die Zertifikate auf den jeweiligen Webservern prüfen, um Abweichungen festzustellen.

Alternative zu Zertifikaten

Wie schon geschildert bieten die klassischen Zertifikate eine sichere Zuordnung des Absenders zu einer Domain. Darauf kann man natürlich aufsetzen und statt Zertifikaten Domains in die Liste aufnehmen. Der Browser würde dann die Unbedenklichkeit signalisieren, wenn sowohl die aufgerufene Domain beglaubigt ist als auch der Zertifikatcheck für diese Domain erfolgreich ist.

Auf den Erhalt von Domains ist andererseits wesentlich weniger Verlass als auf den von Zertifikaten. Bei den betroffenen Unternehmen muss man sich darum wohl keine Sorgen machen.

mögliche Probleme

Welche Organisationen eignen sich für die Umsetzung?

Für die Umsetzung dieser Maßnahme eignen sich Organisationen, die aus Sicht der Anwender sowohl über die nötige technische Kompetenz verfügen als auch insgesamt sehr vertrauenswürdig sind.

Der Verfasser hat sich mit diesem Konzept an das BSI gewandt, das fraglos beide Anforderungen bestens erfüllt (eingeschränkt um den Umstand, dass es aus der Zielgruppe kaum jemand kennt). Das BSI bewertet dieses Konzept grundsätzlich positiv, sieht sich aber durch seinen Behördenstatus in einer ungünstigen Situation bezüglich der Frage, wer alles in dieser Weise beglaubigt werden soll und wer versuchen könnte einen vermeintlichen Anspruch auf Beglaubigung durchzusetzen.

Als nächstes wäre an Verbraucherschutzorganisationen zu denken. Die gelten allerdings in der öffentlichen Wahrnehmung nicht als Hort der Computersicherheit und haben vermutlich auch insgesamt nicht die finanziellen und medialen Möglichkeiten, so ein Angebot dann auch in den Markt zu drücken.

Gut geeignet erscheint ein Verlag, der qualitativ hochwertige Computerzeitschriften verlegt. Damit erreicht er zwar die Zielgruppe kaum, aber er ist auf jeden Fall in einer besseren Position als die Verbraucherschutzorganisationen (und verfügt im Zweifelsfall über geeignete Kontakte zur auflagenstarken Allgemeinpresse). Im Gegensatz zu den Vorgenannten hätte er auch wirtschaftlich etwas davon (die Verbesserung der Welt darf sich ja auch lohnen).

Wer soll alles eine Beglaubigung erhalten?

Grundsätzlich spricht nichts dagegen, beliebig viele Zertifikate zu beglaubigen, sofern man immer in geeigneter Weise prüft. Natürlich wird der Grenznutzen immer kleiner. Sinn der Maßnahme ist ja nicht, dass die fraglichen Organisationen sich mit einem "Siegel" brüsten können, sondern dass gefährdete Seiten geschützt werden. Wer nicht gefährdet ist, weil sein Angebot sich nicht missbrauchen lässt, der hat auch keinen (ethischen) Anspruch auf so eine Beglaubigung.

Rein praktisch könnte man es so handhaben, dass die durchführende Organisation sich selber um die Aufnahme der vielleicht 50 wirklich gefährdeten Angebote kümmert und jeder, der darüber hinaus aufgenommen werden will, für den dadurch entstehenden Aufwand mit 50 € in Anspruch genommen wird.

abgelaufene Zertifikate

Richtig unerfreulich wäre es, wenn eine der beglaubigten Organisationen unerwartet ihr Zertifikat wechselt. Dann würden nämlich Anwender mit dem Ausbleiben der erwarteten Meldung konfrontiert – und dann hagelt es E-Mails und Anrufe. Allerdings auch bei der jeweiligen Organisation, was diese motivieren könnte, solchen Unfug zu unterlassen.

Es sollte möglich sein, sich mit diesen Organisationen dahingehend zu einigen, dass die den Beglaubigungsinstanzen neue Zertifikate mit dem nötigen zeitlichen Vorlauf mitteilen.

Anzeige des Status der beglaubigten Webseite

Es mag – auch für die Frage, wen man denn nun alles beglaubigen will – sinnvoll sein, nicht unterschiedslos einfach nur die Unbedenklichkeit zu signalisieren. Jedem Signaturschlüssel der beglaubigenden Organisation könnte ein entsprechender Status mitgegeben werden, der sinnvollerweise in ein bei der Entwicklung des Systems entworfenes Schema fällt, so dass sich weltweit alle an dieselben Konventionen halten.

Mögliche Klassen sind:

Angriffe auf die hinterlegten Beglaubigungsschlüssel oder das Add-on

Immer wieder werden Sicherheitslücken in den Browsern entdeckt. Da denjenigen, die sich ihrer bedienen, alle Möglichkeiten des Browsers offenstehen, erscheint es prinzipiell möglich, zuerst über einen Exploit die installierten Beglaubigungsschlüssel zu überschreiben und dann einen Phishingangriff zu starten. Oder das Add-on zu kompromittieren.

Da es kaum möglich sein wird, nur noch "fehlerfreie" Browser einzusetzen, stellt sich die Frage nach anderen Möglichkeiten. Eine könnte sein, diese Schlüssel (und das Add-on) so auf dem Rechner abzulegen, dass der Account des Benutzers keine Schreibrechte (inklusive löschen und neu anlegen) auf sie hat. Bei den Schlüsseln erscheint das noch praktikabel, bei dem Add-on wird es mit Updates dann natürlich schwierig. Die sollte es also nur selten geben. Diese Vorgehensweise erforderte (angesichts der Zielgruppe...) wohl die Bereitstellung eines kleinen Programms, dass die Rechtebearbeitung (bzw. das Verschieben der Dateien an eine geschützte Stelle) übernimmt.

Wie erreicht man die Ahnungslosen?

Eine technische Lösung, die am Ende überwiegend von denjenigen eingesetzt wird, die sie am wenigsten nötig haben, bringt wenig. Es ist allerdings damit zu rechnen, dass zumindest manche der gefährdeten Organisationen ihre Kunden auf diese Möglichkeit hinweisen werden und ihr so zu mehr Aufmerksamkeit verhelfen.

In der Computerpresse wird dies sicher ein größeres Echo finden, so dass zu hoffen ist, dass die versierteren Nutzer diejenigen aus ihrem Bekanntenkreis, die dieser Gruppe nicht angehören, motivieren, dieses System zu nutzen.

Entwicklungskosten und -dauer, Unsicherheit des Entwicklungserfolgs

Da es um eine simple Datenbankabfrage handelt, ist die Erstellung so eines Add-ons für jemanden, der davon etwas versteht, wohl nur eine Aufgabe für einen Nachmittag.

Investitionsbedarf und variable Kosten

Dauerhafte Kosten entstehen durch den Betrieb der angefragten Server. Allerdings ließe sich der Traffic durch geeignetes Caching gering halten.

Marktchancen — Übersicht

vorhandene ähnliche Produkte

Microsoft bietet erweiterte Zertifikate an, die das Problem aber ebenfalls nicht abschließend lösen. Außerdem nützen die nur IE-Anwendern etwas und das auch nur dann, wenn die fragliche Organisation sie verwendet.

Vorteile der Innovation und ihr Gewicht, Aufwand-Nutzen-Verhältnis

für den Anwender

Für den technisch wenig kompetenten Anwender ist es der Idealzustand (nach der hypothetischen Situation, dass der rechner ihm das Denken komplett abnimmt), dass er sich nur noch auf einen Aspekt konzentrieren muss.

für die umsetzende Organisation

Die Organisation, die das Add-on entwickeln lässt oder in ihrem Einflussbereich als erste Beglaubigungen ausstellt bzw. dabei den größten "Marktanteil" hat, kann einen gewissen Werbeeffekt für sich verbuchen. Neben dem Unbedenklichkeitshinweis könnte so was wie sponsored by ... stehen und außerdem beglaubigt durch XY-CA (was durchaus einen Sinn hätte, weil der Anwender mehrere Beglaubiger konfiguriert haben kann).

Je nach Art der Organisation könnte das Wohlwollen des BSI sich imagemäßig positiv auswirken.

Nachteile der Innovation

Nachteilig ist, dass diese Maßnahme Änderungen an den Clients erfordert und unerwartete Zertifikatwechsel Probleme mit sich bringen können.

Portfoliobetrachtung

Besonders gut passt diese Maßnahme zu einem Unternehmen, das sich sowieso schon mit konstruktiven Projekten im Bereich IT-Sicherheit engagiert.

Zielgruppen

Zielgruppe dieser Maßnahme sind alle Anwender. Bei den kompetenten spricht man die Bequemlichkeit an, bei den anderen ist es wohl die letzte Rettung.

rechtliche Probleme

Denkbar ist der Fall, dass man jemanden nicht beglaubigen will, der das aber durchsetzen möchte. Bei naiver Betrachtung wirkt die Vorstellung, jemanden gerichtlich zu zwingen, die eigene Seriösitätr zu bezeugen, selbst für die Verhältnisse der deutschen Justiz skurril.

Imitationsrisiko, Barrieren gegenüber (potentiellen) Wettbewerbern

Da der größere Aufwand in der Erstellung des Add-ons und der Festlegung des Abfrageprotokolls liegt, könnte sich ein Unternehmen, das einen deutlich besseren Zugriff auf die Zielgruppe hat, entscheiden, selber als Beglaubiger aufzutreten und seine Kunden/Nutzer dazu zu bringen, (nur oder erstrangig) das eigene Angebot zu konfigurieren, um auf diese Weise den Werbe- und den Imageeffekt abzugreifen.

Dem kann man am besten vorbeugen, indem man die öffentliche Bekanntmachung gut vorbereitet. Man könnte sie auch mit einer (sowieso geplanten) Werbekampagne verbinden und schön darauf hinweisen, wer das System erfunden/aufgebaut hat.

Chancen & Risiken – zusammengefasst

Dem Umsetzungsaufwand entsprechend gering ist das Risiko. Die große Chance liegt darin, irgendwann mal in sehr vielen oder sogar den meisten Browsern präsent zu sein und vielleicht das Problem Phishing endgültig zu den Akten gelegt zu haben. Darauf könnte man sich öffentlich noch lange ausruhen.

Einwände — Übersicht

Naheliegende oder bereits vorgebrachte Einwände:

Erweiterungen — Übersicht

Änderungen am Dokument — Übersicht

Wenn in Ihrem Browser Javascript aktiviert ist, können Sie die Änderungen von Version zu Version farblich markieren lassen, um sie schneller zu finden.

nichts markieren

1.0 (11.12.2005)

1.1 (02.06.2008)