-
BEREICH DER ERFINDUNG
-
Die
vorliegende Erfindung betrifft die Akkreditierung einer Internet-Website,
d. h. die Verifizierung, ob eine Site auf dem World Wide Web (www)
bona fide ist.
-
HINTERGRUND
DER ERFINDUNG
-
In
den letzten Jahren hat e-Commerce, d. h. Handelsgeschäfte über das
Internet, sehr rasch zugenommen, und den Vorhersagen zur Folge wird
diese Wachstumsrate auch in der Zukunft so bleiben. Dieses Wachstum
hat Probleme im Hinblick auf Sicherheit und Authentizität mit sich
gebracht. Es existieren zahlreiche Websites, die zwar vorgeben,
echte Warenquellen zu sein, aber tatsächlich schwindlerisch sind
und entweder gefälschte
Waren verkaufen oder eine unautorisierte Quelle für echte
Waren sind.
-
Es
ist derzeit sehr leicht für
eine schwindlerische Fremdpartei, einen Internet-Domänennamen
zu registrieren, der mit einer bekannten Marke identisch oder einer
solchen sehr ähnlich
ist. Internet-Suchmaschinen finden solche ähnlichen IP-Adressen und führen den
Sucher zu einer beliebigen Site, die im Hinblick auf Namen oder
Seiteninhalt sehr ähnlich
ist. Ein Beispiel: bei der korrekten, legitimen Adresse bloggsandbloke.com.
wird man üblicherweise
unverwandte Adressen wie bloggs+bloke.com, bloggs-bloke.com, bloggsandbloke.co.uk
usw. finden.
-
Es
ist ebenso leicht, die Frontseite der echten Website von bloggsandbloke.com
zu nehmen und sie auf die Rogue-Site zu importieren. Infolgedessen
denken Browser und ihre Benutzer, dass sie auf der echten Site von
Bloggs and Bloke PLC sind, obwohl sie tatsächlich gerade eine Rogue-Site besuchen.
-
In
der Vergangenheit wurden Versuche unternommen, Websites zu authentifizieren,
um Kunden ein gewisses Maß an
Sicherheit zu geben. Alle Authentifizierungssysteme waren jedoch
statisch; eine bestimmte Website wird im Voraus authentifiziert
und kann ein Authentifikationssymbol, z. B. ein Authentifikationslogo, typischerweise
auf ihrer Homepage anzeigen. Das Authentifikationssymbol wird dann
automatisch jedes Mal angezeigt, wenn auf diese Site zugegriffen
wird. Solche Systeme bieten zwar ein gewisses Maß an Verbraucherschutz, aber
sie sind bei weitem nicht unfehlbar. Zum einen können die Authentifikationssymbole
kopiert werden und zum andern berücksichtigt die Akkreditierung
möglicherweise
keine Änderungen
am Website-Inhalt
oder beim Site-Provider. Wenn die Frontseite kopiert wurde, dann
enthalten auch die unrechtmäßigen Kopien
die Authentifikation.
-
Es
existieren bereits Sicherheitsmaßnahmen, um einen sicheren
(verschlüsselten)
Transfer von Informationen wie z. B. Kreditkartennummern zu ermöglichen
usw. Diese Systeme bieten jedoch lediglich einen Verschlüsselungsmechanismus
und geben keine Garantie für
die Authentizität
der Site.
-
Die
US 6,018,801 offenbart eine
Meldung zum Verifizieren des Ursprungs eines elektronischen Dokuments,
das sich auf einem Computernetz befindet, wobei das ursprüngliche
Dokument durch einen Dokument-Viewer betrachtet wird. Das Dokument
enthält
eine Dokumentenkennung, die Identifikationsinformationen über das
elektronische Dokument enthält.
Ein diese Identifikationsinformationen sowie Informationen über den
Ort des elektronischen Dokumentes auf dem Computernetz enthaltendes
Verifikationssignal wird mit dem Document-Viewer erzeugt und zu einem Verifizierungscomputer
gesendet. Dieser greift auf die Datenquelle zu, um einen Identifikationsdatensatz
und einen Ortsdatensatz für
das elektronische Dokument abzurufen. Diese Datensätze werden
dann mit einem Verifikationssignal verglichen, und auf der Basis
dieses Vergleichs wird ein Antwortsignal erzeugt und zurück zum Document-Viewer
gesandt. Wenn die Informationen im Verifikationssignal nicht mit
den Informationen in den Informationsort-Datensätzen übereinstimmen, dann kann auch
eine Fehlermeldung erzeugt werden. Diese wird dann als Fehleravisierung
zu einem designierten Empfänger
gesendet.
-
Es
besteht somit Bedarf an einem verbesserten System zur Akkreditierung
und Authentifizierung von Internet-Websites. Es ist Ziel der Erfindung,
diesen Bedarf zu decken, und die Erfindung stellt in ihrer breitesten Form
ein Verfahren zum dynamischen Authentifizieren bereit, wobei die
Authentifikation jedes Mal stattfindet, wenn ein ortsferner Benutzer
auf die Site zugreift.
-
In
ihrer breitesten Form stellt die Erfindung ein Verfahren, eine Vorrichtung
und ein Programm bereit, die gewährleisten,
dass die Website bei jedem Zugriff darauf von einem Verifizierungsserver
verifiziert wird. Es wird insbesondere ein Verfahren zum Verifizieren
der Authentizität
einer Internet-Website bereitgestellt, das die folgenden Schritte
umfasst: Senden einer Seitenanforderung von einem Benutzer zu der
zu authentifizierenden Site; an der zu verifizierenden Site, Erzeugen
einer Webseite, die eine Siteidentifikation enthält, und Senden der erzeugten
Seite zu dem Benutzer; beim Benutzer, Extrahieren der Siteidentifikation
und Senden derselben zu einem Verifizierungsserver; beim Verifizierungsserver,
Vergleichen der Siteidentifikation mit einer vorgespeicherten Identifikation;
und auf der Basis des Vergleichs, Senden einer Anzeige zu dem Benutzer,
ob die Site authentisch ist oder nicht; dadurch gekennzeichnet,
dass eine vorbestimmte Benutzerkennung beim Verifizierungsserver
gespeichert wird, wenn sich der Benutzer zum ersten Mal beim Server
anmeldet oder subskribiert, und in der Anzeige an den Benutzer enthalten
ist.
-
Die
Erfindung stellt ferner ein System zum Verifizieren der Authentizität einer
Internet-Website bereit, das Folgendes umfasst: bei der zu verifizierenden
Site, Mittel zum Erzeugen einer Webseite nach dem Empfang einer
Seitenanforderung von einem Benutzer-Browser, wobei das Erzeugungsmittel
Mittel zum Einbetten einer Siteidentifikation in die Seite beinhaltet;
und Mittel zum Senden der erzeugten Seite zu dem Benutzer-Browser;
beim Benutzer, Mittel zum Extrahieren der Siteidentifikation; und
Mittel zum Senden derselben zu einem Verifizierungsserver; beim
Verifizierungsserver, Mittel zum Vergleichen der Siteidentifikation
mit einer vorgespeicherten Identifikation; und Mittel, um dem Benutzer
auf der Basis des Vergleichs anzuzeigen, ob die Site authentisch
ist oder nicht; gekennzeichnet durch Mittel zum Speichern einer
vorbestimmten, vom Benutzer stammenden Kennung beim Verifizierungsserver,
wenn sich der Benutzer zum ersten Mal beim Server anmeldet oder
subskribiert, und, wenn die Site authentisch ist, Einbeziehen der
Kennung in die Anzeige an den Benutzer.
-
Die
Erfindung stellt ferner ein Computerprogramm bereit, umfassend Programmcodemittel,
um, wenn das Programm auf einem Computer oder einem Computernetz
abläuft,
die folgenden Schritte durchzuführen: nach
dem Empfang einer Seitenanforderung von einem Fernort, Erzeugen
einer Webseite, die eine Siteidentifikation enthält, und Senden der erzeugten
Seite zu dem fernen Ort; an dem fernen Ort, Extrahieren der Siteidentifikation
und Senden derselben zu einem Verifizierungsserver; Empfangen einer
Anzeige, ob die Site authentisch ist oder nicht, auf der Basis eines
Vergleichs an dem Verifizierungsserver zwischen der Siteidentifikation
und der vorgespeicherten Identifikation von dem Verifizierungsserver
an dem fernen Ort; Anzeigen einer von dem fernen Ort stammenden
Kennung an dem fernen Ort, wenn die Site authentisch ist; und Anzeigen
der von dem Verifizierungsserver empfangenen Anzeige an dem fernen
Ort; dadurch gekennzeichnet, dass eine vorbestimmte, vom Benutzer
stammende Kennung am Verifizierungsserver gespeichert ist, wenn
sich der Benutzer zum ersten Mal beim Server anmeldet oder subskribiert,
und in die Anzeige an den Benutzer einbezogen ist.
-
Die
Erfindung stellt ferner ein Computerprogramm gemäß Anspruch 16 bereit, wobei
die Siteidentifikation eine Seriennummer und die Adresse beinhaltet,
von der die erzeugte Webseite gesendet wurde.
-
Ausgestaltungen
der Erfindung haben den Vorteil, dass die Frontseite einer Website
nicht auf eine solche Weise herausgehoben werden kann, dass sie
die Verifikation beinhaltet, da die Verifikation jedes Mal erzeugt
wird, wenn auf die Website zugegriffen wird, und der Benutzer eine
vom Benutzer stammende Kennung erhält, die gewährleistet, dass das Verifikationssignal
von dem Authentifizierungsserver stammt.
-
Die
von der zu verifizierenden Site erzeugte Webseite ist vorzugsweise
als einmalige Identifikationsnummer eingebettet, so dass die Webseite
einmalig ist. Dies hat den Vorteil, dass die Seite von einem Internet Service
Provider nicht gecacht werden kann. Internet Service Provider cachen
im Allgemeinen nur die am häufigsten
besuchten Sites, um Antwortzeiten zu reduzieren. Da die Seite dann
nicht gecacht wird, kann der Authentifizierungsvorgang nicht umgangen
werden, indem Seiten aus dem Cache geholt werden.
-
Die
Anzeige zum Benutzer, ob die Site authentisch ist oder nicht, umfasst
vorzugsweise eine grafische Anzeige im Browser oder wenigstens einem
Teil des Browsers. Vorzugsweise wird wenigstens ein Teil dieser Graphik
animiert. Animation eines Teils der Graphik erschwert das Kopieren
der Graphik.
-
Die
von der zu authentifizierenden Site erzeugte Webseite kann ein Applet
oder ein Cookie oder eine Link zum Verifizierungsserver enthalten,
der sich auf dem Browser dieses Benutzers befinden kann. Der Applet-
oder Cookie- oder
Link-Mechanismus führt
die Funktionen des Extrahierens einer Siteidentifikation von der erzeugten
Webseite aus, wenn diese vom Browser des Benutzers empfangen wurde,
er kommuniziert mit dem Verifizierungsserver, sendet einen Code
oder eine vom Benutzer kreierte Challenge-Phrase an den Verifizierungsserver
und erzeugt die Graphikanzeige mit der Challenge-Phrase, die zum
Benutzer zurückgesendet wird.
-
Das
Applet handhabt vorzugsweise jeden der drei oben erwähnten Vorgänge als
separate parallele Threads.
-
KURZE BESCHREIBUNG DER
ZEICHNUNGEN
-
Eine
Ausgestaltung der Erfindung wird nachfolgend beispielhaft unter
Bezugnahme auf die Begleitzeichnungen beschrieben: Dabei zeigt:
-
1 eine
schematische Ansicht eines die Erfindung ausgestaltenden Systems;
-
2a und 2b ein
Ablaufdiagramm, das den die Erfindung ausgestaltenden Prozess illustriert;
-
3 ein
Blockdiagramm, das die Funktionalität des Client-Applet oder -Cookie
illustriert; und
-
4 ein
Ablaufdiagramm, das die vom Applet oder Cookie ausgeführte Prozedur
illustriert.
-
Das
in 1 illustrierte System (10) umfasst einen
Benutzer-Browser (12), bei dem es sich um einen konventionellen
Internet-Browser wie den Microsoft Internet Explorer oder Netscape
Navigator handeln kann, der so modifiziert werden kann, dass er
ein kundenspezifisches Java-Applet oder -Cookie hat, das nachfolgend
beschrieben wird. Der Browser kann auf einer beliebigen geeigneten
Plattform wie einem PC oder Macintosh laufen. Der Browser kommuniziert über eine
konventionelle Internet-Link mit einem Firmenserver 14 über einen
Internet Service Provider (ISP) (nicht dargestellt). Um auf den
Firmenserver zuzugreifen, der die Website der Firma hostet, sendet
der Browser die konventionelle Hypertext Transfer Protocol (HTTP)
Adresse für
den Server und sendet eine Seitenanforderung. Das nachfolgend beschriebene
Authentifizierungssystem basiert auf dem Konzept, dass der Firmenserver
eine frische Webseite mit einer darin eingebetteten einmaligen Seriennummer
und einem Java-Applet oder -Cookie erzeugt. Diese Webseite wird
am Benutzer-Browser empfangen
und das Applet oder Cookie bewirkt, dass eine Verifikationsanforderung
zum Authentifizierungsserver 16 gesendet wird, der sich
ortsfern vom Firmenserver befindet und der die URL-Adresse verifiziert
und dem Benutzer-Browser ein Signal zurücksendet, dass die Site entweder
verifiziert wurde oder dass die Verifikation fehlgeschlagen ist.
Das Applet oder Cookie kann sich auf dem Browser befinden oder kann
jedes Mal von dem in der eindeutig identifizierten Webseite eingebetteten
Firmenserver heruntergeladen werden.
-
Das
beschriebene System ermöglicht
eine Verifizierung, dass von einer Website empfangene Daten von
einer akkreditierten Quelle kommen. Somit werden die gelieferten
Daten einem zertifizierten Datenprovider zur Verfügung gestellt,
und der Akkreditierungsstatus wird jedes Mal verifiziert, wenn auf
die Website zugegriffen wird. Nach dem Verifizieren der Site werden
die Ergebnisse des Verifikationsprozesses dem Internet-Browser in
einem dynamischen Format, vorzugsweise einem dynamischen Multilayer-Format,
bekannt gemacht, um Logodiebstahl zu erschweren. Ferner sendet der
Benutzer, wenn er mit dem verifizierenden Server kommuniziert, einen
Code oder eine Challenge-Phrase, die dann das Verifikationslogo,
Zeichen oder Signal begleitet, wenn es zum Benutzer zurückgesendet
wird.
-
In
jeder Phase des Prozesses sind Maßnahmen enthalten, um zu verhindern,
dass der ISP Mechanismen cacht. Dadurch wird gewährleistet, dass die Authentifizierung
jedes Mal erfolgt, wenn auf die Site zugegriffen wird. Aus diesem
Grund, und als zusätzliche
Sicherheitsmaßnahme,
stellt der Firmenserver eine einmalige Seriennummer bereit, d. h.
einen Wert, der einmalig ist und der jedes Mal erzeugt wird, wenn
eine Seitenanforderung empfangen wird.
-
Das
System wird nun ausführlicher
beschrieben. Der Internet-Browser (12) verwendet vorzugsweise ein
oder zwei übliche
Protokolle für
den Informationsaustausch: HTTP oder CGI. Es können auch andere Protokolle
verwendet werden. HTTP (Hypertext Transfer Protocol) ist ein einfach
zu benutzendes Protokoll, in dem Anforderungen zu einem Server im
Standardtextformat gesendet werden, und auch die ersten Antworten
sind im Nur-Text-Format. Das Protokoll lässt sich einfach implementieren
und debuggen.
-
Die
Common Gateway Interface (CGI) ist ein hinlänglich bekanntes Protokoll,
das zum Erzeugen von zusammengesetzten Dokumenten verwendet wird.
HTTP ist ein Protokoll zum Liefern von Dokumenten, die keine echten
Verarbeitungsfähigkeiten
haben. Um die Benutzbarkeit des World Wide Web zu erhöhen, werden serverseitige
Programme abgearbeitet, die bei Bedarf Seiteninhalt erzeugen. Diese
werden häufig
in einfachen Scriptingsprachen geschrieben. Daten werden zu diesen
Server-Skripts über
HTTP durch die CGI geleitet. Die Server-Skripts konvertieren eingehende
Informationen aus dem CGI-Standardtextformat mit hinlänglich bekannten
Prozeduren in eine benutzbarere Form.
-
Es
ist übliche
Praxis, dass ISPs eine lokale Kopie von beliebten Websites überprüfen. Der
ISP reagiert dann auf Seitenanforderungen so, als wenn sie vom ursprünglichen
Provider stammten. Dieser Caching-Prozess beschleunigt den Zugriff
auf die Informationen dieser Sites. Man wird verstehen, dass Caching
von authentifizierten Sites in der bevorzugten Ausgestaltung der
Erfindung nicht möglich
ist, da das Verfahren verlangt, dass der eigentliche Firmenserver
bei jedem Zugriff auf die Site einen eindeutigen Code erzeugt. So
entsteht eine dynamische Seite, die das Authentifizierungsapplet
enthält,
wobei jede Seite einmalig ist. Der ISP kann die HTTP-Seitenanforderung
nicht cachen und das Applet wird daher vom Herausgeber, dem Firmenserver,
anstatt vom ISP geliefert. Es erfolgt kein Caching, da die Webseite
einmalig ist und daher vom ISP nicht als eine erkannt wird, auf
die häufig
zugegriffen wird. Dies ist auch dann der Fall, wenn sich das Applet
auf dem Browser befindet.
-
Um
die Sicherheit noch weiter zu erhöhen, können Metatags auf der Firmenseite
vorgesehen werden, um Cache-Versuche
durch den ISP zu verhüten.
-
Das
oben umrissene System kann auch ein System für die Neuautorisierung von
vorautorisierten Websites bei jedem Zugriff auf die Site beinhalten.
Der Vorautorisierungsschritt ist häufig ein Offline-Prozess, der
von der Verifizierungsbehörde
durchgeführt
wird. Wenn der Eigentümer
des Firmenservers, der Herausgeber, die Verifizierungsbehörde überzeugt
hat, dass er ein rechtmäßiger Waren-
oder Dienstleistungsanbieter im Rahmen der von der Verifizierungsbehörde aufgestellten
Kriterien ist, dann wird der Herausgeber registriert und erhält eine
einmalige Seriennummer und ein Skript zum Erzeugen der übrigen Daten,
die, zusammen mit der Seriennummer, in die Webseite eingebettet
werden, die erzeugt wird, wenn auf den Firmenserver zugegriffen
wird. Diese beiden Elemente der Seitenseriennummer für eine einmalige
Anforderungsnummer, die dem Applet als Routineparameter zugeführt wird
[sic].
-
Nach
der Herstellung wird die einmalige Seriennummer in der zum Benutzer-Browser
gesendeten Seite als Parameter zu dem Applet eingebettet. Die einmalige
Seriennummer kann die folgende Form haben:
<gelieferte Seriennummer> – <ganze Zahl auf UTC-Basis> – [<CGI-Prozess-ID
oder Iterationszahl>]
-
Es
folgt ein Beispiel für
einen einmaligen Identifikationscode:
Gelieferte Seriennummer
(Registriernummer): PDQ4567X
Aktueller UTC-Zeitwert bei Seitenanforderung:
949424629
Aktuelle CGI-Prozess-ID (oder Iterationszahl): 6541
Die
generierte einmalige Nummer lautet: PDQ4567X-949424629-6541
-
Mit
dieser Nummer erhält
die Verifizierungsbehörde
zwei Verifizierungsdatenelemente. Das erste ist die registrierte
Herausgeberseriennummer, die dem Herausgeber von der Verifizierungsbehörde gegeben
und dann bei der Site-Verifizierung als Primary-Key verwendet wird.
Wenn die Verifikation fehlschlägt,
dann kann der Verifikationsserver die Quelle des fehlerhaften Applets
identifizieren.
-
Das
optionale zweite Verifikationsdatenelement ist der Zeitpunkt, gemäß Herausgeber,
zu dem das Applet geliefert wurde. Dieses Element wird im Cache
des Verifizierungsservers als die letzte Zeit gespeichert, zu der
das Applet benutzt wurde. Wenn eine Anforderung mit einer erheblich älteren Zeitmarke
gemacht wurde, dann wird eine Security-Exception ausgelöst und die
Anforderung als veraltet angesehen. Wenn eine Zeitmarke nur geringfügig älter ist,
dann wird sie weiterhin akzeptiert, da es sein kann, dass der Routingpfad
komplexer war und eine legitime Anforderung verzögert hat. Die Zeit wird als
Universal Time Code ausgedrückt.
-
Die
Iterationszahl ist eine Nummer, die bei jedem Empfang einer Seitenanforderung
automatisch inkrementiert wird und die nach dem Erreichen der von
der Systemarchitektur des Herausgebers unterstützten Höchstzahl von parallelen Prozessen
wieder von vorne anfangen kann. Einige Systeme können keine Iterationszahl unterstützen, und
eine CGI-Prozess-ID kann anstatt jede Prozess-ID-Nummer ist einmalig
verwendet werden [sic]. Dies kann beispielsweise in Systemen auf
UNIX-Basis verwendet werden.
-
Wenn
eine Anforderung veraltet ist, dann bewirkt das Applet eine Seitenneuladung
vom ursprünglichen
Herausgeber, um Probleme mit dem lokalen Browser-Cache oder mit
der Anwenderverbindung zu überwinden.
-
Das
Verfahren wird nunmehr ausführlicher
mit Bezug auf 2 beschrieben. In der
folgenden Beschreibung wird davon ausgegangen, dass der Site, auf
die zugegriffen werden soll, von der Verifizierungsbehörde bereits
eine Seriennummer zugewiesen wurde.
-
In
Schritt 100 sendet der Internet-Browser (12) ein
Seitenlieferungsskript in CGI Script zum Firmenwebserver (14).
-
Der
Webserver empfängt
die Seitenlieferungsanforderung und führt die Schritte aus, die zum
Erzeugen und Senden einer einmaligen Webseite zurück zum Browser
erforderlich sind. In Schritt 102 empfängt der Webserver die Seitenanforderung.
In Schritt 104 wird die einmalige Seriennummer erzeugt,
die die gegebene Seriennummer, UTC-Datum und -Uhrzeit sowie die Iterationszahl
oder Prozess-ID umfasst, wie oben beschrieben wurde.
-
In
Schritt 106 legt der Firmenwebserver eine Codebase für die Lieferung
des Java-Applets oder -Cookies. Applets oder Cookies können in
dieser Ausgestaltung der Erfindung austauschbar verwendet werden.
Da das Applet komplexer ist, wird es ausführlich beschrieben. Die Art
und Weise, in der die Erfindung mit Cookies implementiert wird,
wird später
beschrieben. Die Codebase ist der absolute Netzwerkort, von dem
das Applet oder Cookie geliefert wird, und bildet, im Falle des
Applet, einen Teil des Applet-Programms. Dadurch wird gewährleistet,
dass eine sichere Verbindung zum Verifizierungsserver hergestellt
werden kann.
-
In
Schritt 108 erzeugt der Firmenwebserver eine Webseite,
in der das Applet und die einmalige Seriennummer eingebettet sind.
Das Applet wird später
ausführlicher
beschrieben.
-
In
Schritt 110 wird die neu erzeugte Webseite zum Internet-Browser
des Benutzers gesendet.
-
Somit
hat der Benutzer in dieser Phase eine Seitenanforderung zum Firmenwebserver
gesendet, der auf diese Anforderung mit einer einmaligen Webseite
geantwortet hat.
-
In
der Praxis klickt der Benutzer einfach auf eine Hypertext-Link für die Firma,
die Eigentümer
des Firmenwebservers ist, oder hat die URL-Adresse der Site in das
Adressfeld des Browsers eingegeben. Der Benutzer-Browser zeigt noch nichts von dem Firmenwebserver
an.
-
In
Schritt 112 empfängt
der Browser die Webseite vom Firmenwebserver und instanziiert in
Schritt 114 das in der Seite eingebettete Applet. Das Applet
läuft dann
innerhalb der Java- (oder ähnlichen)
Umgebung ab.
-
In
Schritt 116 extrahiert das Java-Applet die Documentbase
für die
aktuelle Seite. Dies ist der absolute Ort, d. h. die Netzwerkadresse
und die Seitenposition des über
das World Wide Web gelieferten Dokumentes. Die (optionale) eingebettete
Codebase wird dann von der gelieferten Seite zurückgewonnen und die aktuelle Benutzerumgebung
wird notiert. Bei diesem letzteren Vorgang wird die Benutzernetzwerkadresse
für das
Reporting aufgezeichnet.
-
Java
(oder ähnliche
Mechanismen) unterstützen
gleichzeitig Vorgänge
mit einer Reihe von Tasks, die gleichzeitig innerhalb ihrer eigenen
Umgebung ablaufen. Jede dieser Tasks hat einen Ausführungsthread.
In Schritt 118 erzeugt das Applet zwei neue parallele Ausführungsthreads.
Der neue Thread 1 handhabt Grafikoperationen, der neue Thread 2
Kommunikationen mit dem Verifikationsserver.
-
In
Schritt 120 zeichnet Thread 1 des Applets einen Background-Grafikframe.
In Schritt 122 öffnet Thread
2 des Applets eine sichere Verbindung zum Verifikationsserver 16.
In Schritt 124 sendet Thread 2 die Datenelemente Seitenseriennummer,
Netzwerklieferung, Seitenadressen sowie aktuelle Umgebung zum Verifizierungsserver.
Diese Daten können
in verschlüsselter
Form gesendet werden. In Schritt 126 erzeugt Thread 1 des
Applets Pending- und Clipping-Frames.
Beim Letzteren handelt es sich um einen Frame, der einen Bereich
eines Bildes definiert, das zu aktualisieren ist. Außerhalb
dieses definierten Bereiches fallende Zeichnungsanforderungen werden
ignoriert.
-
In
Schritt 128 überlagert
Thread 1 des Applets die Hintergrund-, Pending- und Clipping-Frames
und zeigt in Schritt 130 den zusammengesetzten Frame (Verbund)
an und startet die Animation. Der Benutzer sieht jetzt den zusammengesetzten
Frame in seinem Browser angezeigt. Während Thread 1 des Applets
abläuft, empfängt der
Verifikationsserver bei 132 die Anforderung für eine sichere
Verbindung und akzeptiert sie. In Schritt 134 wird die
Anforderung analysiert und ein Serverlet instanziiert, um mehrere
gleichzeitige Verifizierungstransaktionen zu ermöglichen. Man wird verstehen,
dass das beschriebene System nur einen Benutzer und einen Firmenserver
berücksichtigt.
In der Praxis handhabt der Verifikationsserver Anforderungen von
vielen Benutzern für
viele Firmenserver. Das Serverlet ist ein kleines Programm auf Java-Basis,
das im Verifizierungsnetzserver läuft.
-
In
Schritt 136 decodiert das Serverlet die empfangenen Daten
und speichert sie für
eine spätere
Analyse und Security-Exception-Reports. In Schritt 138 führt das
Serverlet ein Java Data Base Connectivity (JDBC) Lookup zum Validieren
der Daten durch. Je nach den Ergebnissen des Lookup erzeugt das
Serverlet einen Zugelassen-Status mit einer eingebetteten Seriennummer
in Schritt 140 oder einen Nichtzugelassen-Status. Im letzteren
Fall wird ein Nichtzugelassen-Status erzeugt, wenn der Unternehmensserver
eine unbekannte Adresse hat oder wenn (optional) die Seriennummer
nicht zur Verfügung
steht oder wenn die Seriennummer veraltet ist. Wo das System nicht
zugelassen ist, da wird eine Security-Exception ausgelöst. In Schritt 142 gibt das
Serverlet den Zugelassen-Status zum Internet-Browser des Benutzers zurück. In Schritt 140 wird
das Serverlet geschlossen und in Schritt 142 wird die Verbindung
zum Verifizierungswebserver geschlossen.
-
In
Schritt 144 empfängt
der Internet-Browser des Benutzers den Zugelassen-Status und in
Schritt 146 erzeugt Thread 2 des Applets ein Grafikfenster
,pass' oder ,fail'. Wenn ein ,pass' angezeigt wird,
dann wird auch die (optionale) Seriennummer angezeigt. Dieses Fenster
vermeidet, dass der Pending-Frame zur mittleren Layer des animierten
Logos wird. In Schritt 148 schließt Thread 2 eventuelle aktive
Terminals, gibt Ressourcen frei und endet. In Schritt 146 tritt
Thread 1 in eine Animationsschleife ein, bis der Browser zu einer anderen
Seite geht oder schließt.
Die Animation wird in dem vom Clipping-Frame definierten Bereich
angezeigt und kann ein Logo sein, das anzeigt, dass die Firmensite
als authentisch verifiziert ist. In Schritt 152 gibt das Applet
alle Ressourcen frei, wenn der Browser zu einer anderen Seite geht
oder schließt.
Die Threads werden gestoppt und evtl. belegte Speicherkapazität wird freigegeben.
Dann endet das Applet.
-
Das
Java-Applet ist in 3 ausführlicher dargestellt. Wie oben
erörtert,
umfasst das Applet drei Threads: Thread 0, Thread 1 und Thread 2.
Beim ersten Instanziieren des Applets wird Thread 0 automatisch auf
der Java Virtual Machine erzeugt, die sich auf allen Web-Browsern in der Browser-Umgebung
befindet. Er instanziiert die beiden anderen Ausführungsthreads
und erzeugt die notwendigen Manipulationskomponenten für die anderen
Threads. Der Thread läuft
schließlich
durch eine Grafikauffrischungsanforderung und eine kleine 100 ms
Pause und wird zum Animationscontroller.
-
Wenn
das Applet eine Terminierungsanforderung erhält, dann stoppt Thread 0 alle
anderen Threads, gibt alle Ressourcen frei und endet dann (Schritt 152, 2).
-
In
Schritt 202 fordert Thread 0 eine Logo-Komponente vom Verifizierungsserver
an, und in Schritt 204 wird das Logo auf den Clipping-Frame
gezeichnet. Das Logo wird natürlich
nur dann gezeichnet, wenn die Site verifiziert wurde.
-
Thread
1 erzeugt in Schritt 300 drei Grafikframes. Der Thread
ist für
das Erzeugen oder Aktualisieren des Systemgraphik-Doppelpuffers
verantwortlich, so dass das Applet sich selbst animiert. Das Grafiksubsystem
hat drei Layers: einen Baseframe, der eine Form wie z. B. ein Hintergrundrechteck,
einen Hintergrund oder ein statisches Bild enthält; einen mittleren Frame,
der evtl. bewegte Bilder enthält;
und oben einen Clipping-Frame, der den Zeichnungsbereich auf einen
definierten Bereich wie zuvor erörtert
begrenzt. Die drei Layers werden wieder zusammengesetzt und als
ein Grafikbild neu gezeichnet, das zur Bildquelle für Thread
0 wird. Somit werden in 3 die drei Layers in Schritt 302 gezeichnet
und in Schritt 304 auf die Basisgrafik gelegt. Die mittlere
Layer wird in Schritt 304 aktualisiert, z. B. um eine rotierende
Grafik und den aktuellen Verifikationsstatus zu zeigen. Die letzten
beiden Schritte werden zykliert, bis der Browser geschlossen wird
oder zu einer neuen Seite geht.
-
Der
dritte Thread, Thread 2, handhabt Client-Server-Kommunikationen und holt die Informationen,
die zum Validieren einer Seite erforderlich sind. Der Thread ersetzt
den mittleren Frame, der von Thread 1 verwendet wird, durch eine
aktualisierte Grafik, wenn der Hauptverifizierungsserver seine Antwort
zurück
zum Applet gesendet hat. So öffnet
gemäß 3 Thread
2 in Schritt 400 eine Verbindung zum Verifizierungsserver.
In Schritt 402 werden die einmalige Seitennummer, die Lieferadresse
und die Browser-Daten zum Verifizierungsserver gesendet, und in
Schritt 404 wird die Antwort decodiert und es wird je nach
der Antwort ein neuer mittlerer Frame erzeugt. In Schritt 406 wird
der von Thread 1 erzeugte mittlere Frame durch die neue Grafik ersetzt.
-
Der
Verifizierungsserver führt
ein Datenbank-Lookup mit JDBC durch, um zu prüfen, ob die vom Firmenserver
gegebenen Details übereinstimmen.
Da UTC und Iterationszahl/Prozess-ID einmalig sind, werden lediglich
die gegebene Seriennummer zusammen mit der Codebase verglichen.
Wenn Uneinheitlichkeiten gefunden werden, dann sendet der Server
einen Fail-Status zurück
zum Applet. Werden keine gefunden, dann wird ein Erfolg-Status zurückgesandt.
-
Kommunikationen
mit dem Server erfolgen über
einen sicheren Kommunikationsservice, der hinlänglich bekannt ist. Wenn eine
neue Verbindung hergestellt wird, dann spawnt der Server eine neue
Task zum Bearbeiten der eingehenden Anforderung, wodurch gewährleistet
wird, dass keine Task eine andere Task stören kann, und wodurch ein Mechanismus
bereitgestellt wird, um die Serverbelastung über mehrere Back-End-Maschinen
auszugleichen.
-
Im
Falle von Datenuneinheitlichkeiten oder Verarbeitungsschwierigkeiten
wird automatisch eine Security-Exception ausgelöst. Diese werden am Verifikationsserver
analysiert. Mittels Musterabstimmungstechniken können Hacking-Aktivitäten identifiziert
werden. Da jedes Applet eine individuelle Signatur hat, kann ein Missbrauch
eines Applets erkannt und eine schwindlerische Web- oder Hacking-Site
verfolgt werden.
-
Um
den Applet-Prozess besser zu verstehen, folgt nunmehr der Pseudocode
für den
auf dem Browser laufenden Prozess, wobei die Bezugsziffern sich
auf 4 beziehen.
-
-
-
Wie
oben erwähnt,
können
anstelle von Applets Cookies und Link-Mechanismen verwendet werden. Cookies
und Link-Mechanismen
führen
den beschriebenen Prozess auf ähnliche
Weise durch, mit der Ausnahme, dass der größte Teil der Verarbeitung auf
dem Verifikationsserver erfolgt. So wird in Schritt 108 (2) der Link-Mechanismus in die Webseite
eingebettet, die zum Browser des Benutzers gesendet wird, und in
den Schritten 114, 116, 118 läuft der
Webbrowser, extrahiert die Documentbase und erzeugt jeweils die
parallelen Ausführungsthreads.
Die Erzeugung des Verifikationszeichens oder -logos und der begleitenden
Challenge-Phrase werden anders gehandhabt. Beide werden vom Verifizierungsserver
als ein Bild empfangen, ohne von einem Applet generiert werden zu
brauchen.
-
Die
Art und Weise, in der Challenge-Phrases in den beschriebenen Ausgestaltungen
verwendet werden, wird nunmehr ausführlicher beschrieben. Man wird
angesichts der Diskussion des Browser-Pseudocodes und aus 4 verstehen,
dass eine Challenge-Phrase vom Benutzer bei der erstmaligen Benutzung
des Systems mit dem Verifizierungsserver registriert wird. Dies
erfolgt dann, wenn sich der Benutzer beim Verifizierungssystem subskribiert.
Der Benutzer muss eine Challenge-Phrase geben, einen Code, der als
eine vom Benutzer stammende, von diesem ausgewählte, Kennung betrachtet werden
kann. Diese wird zum Verifizierungsserver gesendet und gespeichert
und der Benutzer ist registriert.
-
Wenn
eine Authentifizierung durchgeführt
wird, dann beinhaltet die vom Händler
heruntergeladene einmalige Webseite ein Image-Tag, z. B. in HTML-Form.
Dies kann die folgende Form haben:
<img src="http://www.trdesafely.com/image.gif">
-
Der
Browser des Benutzers lädt
die Bild-Tags des Händlers
herunter. Der Benutzer-Browser erzeugt dann eine Link zum Verifizierungsserver,
der Verifizierungsserver fordert einen Erstbenutzer auf, sich unter
Angabe seines Namens und der von ihm definierten Challenge-Phrase
oder Kennung zu identifizieren. Der Verifizierungsserver speichert
die Benutzerdaten und sendet ein eine einmalige ID enthaltendes
Cookie zum Benutzer-Browser.
-
Wenn
ein Benutzer bereits beim Verifizierungsserver registriert ist,
dann lädt
der Browser des Benutzers die Image-Tags des Händlers herunter. Der Benutzer-Browser
erzeugt dann eine Link zum Verifizierungsserver, der Verifizierungsserver
prüft die
Adresse (URL) des Händlers
oder die Siteidentifikation und vergleicht dies mit zuvor gespeicherten
Daten. Wenn der Verifizierungsserver die Adresse (URL) und/oder
Siteidentifikation erkennt, dann sendet er ein Authentifikationssignal
zum Benutzer. Der Verifizierungsserver prüft auch die Benutzer-ID, die
von dem auf dem Benutzer-Browser gespeicherten Cookie extrahiert
wird, und hängt
die vom Benutzer definierte Kennung oder Challenge-Phrase an das
Authentifikationssignal an. So kann der Benutzer sicher sein, dass
eine Verifizierung vom richtigen Verifizierungsserver ordnungsgemäß durchgeführt wurde.
-
Am
Verifizierungsserver wird die URL der referenzierenden Seite extrahiert,
dann wird das Cookie mit der eindeutigen ID des Benutzes extrahiert.
Der Verifizierungsserver vergleicht die referenzierende URL-Adresse mit einer
Datenbank von zugelassenen URL-Adressen und durchsucht eine Datenbank
mit registrierten Benutzern nach der extrahierten Benutzer-ID-Nummer
und extrahiert die damit assoziierte Challenge-Phrase. Der Verifizierungsserver
sendet dann, vorzugsweise als Bild, eine Antwort zum Benutzer, die
die Challenge-Phrase enthält.
