-
Verfahren zur Unterscheidung von missbräuchlichen Abfragen von zulässigen Abfragen durch einen Benutzer an einen Serviceprovider in einem Computernetzwerk
-
Die Erfindung betrifft ein Verfahren zur Unterscheidung von missbräuchlichen Abfragen von zulässigen Abfragen durch einen Benutzer an einen Serviceprovider in einem Computernetzwerk.
-
Bei der Kommunikation zwischen verschiedenen Computern in einem Computernetzwerk können Anfragen von einem Benutzercomputer an einen Serviceprovidercomputer übermittelt werden, um anschließend einen Service von dem Serviceprovider in Anspruch nehmen zu können. Dieser Service kann eine Informationsübermittlung beinhalten, wobei Informationen aus einer Datenbank des Serviceproviders an den Benutzercomputer übermittelt werden. Der Service kann auch eine Dienstleistung beinhalten, die der Serviceprovider durchführt, um anschließend nach der Durchführung der beauftragten Dienstleistung dem Benutzercomputer eine Bestätigung oder eine Ergebnisinformation zu übermitteln.
-
Derartige Interaktionen zwischen einem Benutzercomputer und einem Serviceprovidercomputer können oftmals auch automatisiert durchgeführt werden, so dass der Serviceprovider nicht unterscheiden kann, ob die Abfrage der von dem Serviceprovider angebotenen Services von einem Person angefragt wird oder beispielsweise vollständig automatisiert und ohne ein Eingreifen eines Benutzers über einen Benutzercomputer erfolgt.
-
In vielen Fällen versuchen Serviceprovider, ihre Services nur menschlichen Benutzern zur Verfügung zu stellen. Die Unterscheidung zwischen zulässigen Abfragen durch einen menschlichen Benutzer und missbräuchlichen Abfragen, die oftmals automatisiert durchgeführt werden sollen, ist beispielsweise für eine Benutzerauthentifizierung oder bei sogenannten online-polls von besonderer Bedeutung, um zu verhindern, dass die Identität eines Benutzers missbraucht wird. Aus Sicht der Serviceprovider sollen missbräuchliche Abfragen möglichst reduziert werden, um eine missbräuchliche Verwendung der Services bereits vor deren Inanspruchnahme zu reduzieren und um eine übermäßige Auslastung der elektronischen Infrastruktur des Serviceproviders durch beispielsweise eine übermäßig hohe Abfrage einzelner Services innerhalb einer kurzen Zeitdauer oder sogenannte denial-of-service-Attacken zu vermeiden.
-
Um eine missbräuchliche Nutzung der Services durch eine automatisierte Abfrage zu vermeiden müssen die Serviceprovider möglichst zuverlässig unterscheiden, ob die Abfrage eine zulässige Abfrage oder eine missbräuchliche Abfrage darstellt. Dabei muss üblicherweise ein Kompromiss zwischen der Komplexität der Überprüfung einer Abfrage durch den Serviceprovider einerseits und der Zuverlässigkeit des Ergebnisses der Überprüfung durch den Serviceprovider eingegangen werden.
-
Ein einfaches, jedoch oftmals wenig wirkungsvolles Verfahren zur Unterscheidung von missbräuchlichen und zulässigen Abfragen beinhaltet die Überprüfung, ob die Anzahl der Abfragen von einem Benutzercomputer innerhalb einer Überprüfungszeitdauer unterhalb eines Missbrauchsschwellenwerts des Serviceproviders liegt. Dabei wird vorausgesetzt, dass ein menschlicher Benutzer nur eine geringe Anzahl von zulässigen Abfragen innerhalb der Überprüfungszeitdauer an den Serviceprovider richten kann. Der Serviceprovider kann mit diesem Verfahren missbräuchliche Abfragen nur dann identifizieren, wenn diese von demselben Benutzercomputer aus an den Serviceprovidercomputer übermittelt werden.
-
Ein wesentlich wirkungsvolleres, jedoch für einen menschlichen Benutzer bei einer zulässigen Abfrage mit einem Aufwand verbundenes Verfahren verwendet einen üblicherweise als CAPTCHA bezeichneten Aufgabe-Lösungs-Test, der bei einer Anfrage eines Benutzers von dem Serviceprovider an den anfragenden Benutzer übermittelt wird. Der Benutzer muss dabei eine von dem Serviceprovider gestellte Aufgabe lösen und die Lösung zurück an den Serviceprovidercomputer übermitteln, der erst nach einer erfolgreichen Bestätigung der Lösung eine weitere Interaktion zwischen dem Benutzercomputer und dem Serviceprovidercomputer bzw. die Abfrage eines Services von dem Serviceprovider zulässt. Die in den CAPTCHAs enthaltenen Aufgaben sind zweckmäßigerweise derart gestaltet, dass diese Aufgaben von einem Mensch leicht und zuverlässig gelöst werden können, jedoch von einem Automaten nur mit einem erheblichen Aufwand gelöst werden können. Gelingt eine derartige Ausgestaltung von CAPTCHAs, wird ein Mensch bei einer zulässigen Abfrage nur geringfügig aufgehalten, bzw. die Abfrage nur geringfügig erschwert, während eine missbräuchliche Abfrage der Services des Serviceproviders durch automatisierte Anfragen wenig oder nicht mehr interessant erscheint und deshalb dieses Risiko sehr gering wird.
-
Bei den aus der Praxis bekannten CAPTCHAs werden meist bildbasierte Aufgaben verwendet, bei denen von dem Serviceprovider ein Bild an den Benutzercomputer übermittelt wird, wobei das Bild beispielsweise eine verzerrte oder teilweise versteckte Antwort enthält, und die Lösung das Erkennen der in dem Bild enthaltenen Antwort erfordert. Diese bildbasierten CAPTCHAs können von sehbehinderten Benutzern oder bei Verwendung von rein textbasierten Benutzercomputerinterfaces nicht gelöst werden. Auch rein textbasierte oder akustische CAPTCHAs grenzen oftmals einzelne Benutzergruppen aus, die wegen des mit der Lösung der CAPTCHAs verbundenen Aufwands die eigentlich zulässige Abfrage abbrechen oder nicht in Betracht ziehen.
-
Zudem werden ständig Verfahren zum missbräuchlichen Lösen derartiger CAPTCHAs entwickelt. Mit den steigenden Möglichkeiten automatisierter Verfahren und Maschinen können immer mehr Varianten von CAPTCHAs immer erfolgreicher durch automatisierte Verfahren gelöst werden. Werden diese CAPTCHAs schwieriger gestaltet, um die Erfolgswahrscheinlichkeit einer automatisierten Lösung zu verringern, steigt damit einhergehend die Anforderung an einen Benutzer, der in zulässiger Weise eine Abfrage an den Serviceprovider richten will.
-
Es sind auch Anbieter bekannt, die innerhalb einer sehr kurzen Zeit eine Lösung eines CAPTCHAs durch einen Menschen vornehmen lassen und die Lösung an den Übersender des CAPTCHAs zurückübermitteln. Diese Anbieter verfügen oft über eine große Gruppe von Menschen und können diese Dienstleistung großvolumig und zu geringen Kosten anbieten. Ein massenweises menschliches Lösen von CAPTCHAs steht demzufolge für deutlich weniger als 1 Cent je gelöstem CAPTCHA zur Verfügung, so dass eine missbräuchliche Abfrage von Services eines Serviceproviders auch bei vergleichsweise komplexen CAPTCHAs nicht wirkungsvoll verhindert werden kann.
-
Der erhoffte Nutzen derartiger CAPTCHAs ist demzufolge vergleichsweise gering, während der zusätzliche Aufwand für einen Benutzer bei einer zulässigen Abfrage durch den Benutzer auf Grund der zunehmend anspruchsvoller gestalteten CAPTCHAs vergleichsweise groß ist und ständig zunimmt, wodurch die Akzeptanz derartiger CAPTCHAs sinkt.
-
Es wird deshalb als Aufgabe der vorliegenden Erfindung angesehen, ein Verfahren zur Unterscheidung von missbräuchlichen Abfragen von zulässigen Abfragen durch einen Benutzer an einen Serviceprovider in einem Computernetzwerk so auszugestalten, dass der für einen Benutzer bei einer Abfrage anfallende Aufwand möglichst gering ist, und dennoch eine für viele Anwendungsfälle ausreichende Reduzierung von missbräuchlichen Abfragen ermöglicht wird.
-
Diese Aufgabe wird durch ein erfindungsgemäß ausgestaltetes Verfahren gelöst, wobei in einem Generierungsschritt der Benutzer ein Schlüsselpaar mit einem öffentlichen Benutzerschlüssel und einem privaten Benutzerschlüssel erstellt, wobei in einem Zertifizierungsschritt eine Zertifizierungsstelle ein digitales Zertifikat umfassend den öffentlichen Benutzerschlüssel und die Gültigkeitsdauer des Zertifikats erzeugt und mit einem privaten Zertifizierungsstellenschlüssel digital signiert und dabei eine digitale Zertifizierungsstellensignatur erstellt, wobei in einem Abfrageschritt der Benutzer eine Anfrage an einen Serviceprovider übermittelt, der Serviceprovider daraufhin eine individualisierende Anfrageinformation an den Benutzer übermittelt, der Benutzer daraufhin in einem Tokengenerierungsschritt das digitale Zertifikat und die Anfrageinformation mit dem privaten Benutzerschlüssel digital signiert und dabei eine digitale Benutzersignatur erstellt, und anschließend ein Token erstellt, welches das digitale Zertifikat, die Anfrageinformation und die digitale Benutzersignatur enthält, und das Token an den Serviceprovider übermittelt, wobei der Serviceprovider in einem Überprüfungsschritt die Gültigkeitsdauer des digitalen Zertifikats bestätigt und mit Hilfe eines öffentlichen Schlüssels der Zertifizierungsstelle die digitale Zertifizierungsstellensignatur bestätigt, um anschließend mit dem öffentlichen Benutzerschlüssel aus dem digitalen Zertifikat der Zertifizierungsstelle die Echtheit der digitalen Benutzersignatur zu bestätigen.
-
Ein wesentlicher Vorteil des erfindungsgemäßen Verfahren gegenüber den aus der Praxis bekannten CAPTCHAs kann darin gesehen werden, dass der Benutzercomputer in dem Abfrageschritt nach einer Anfrage an den Serviceprovider lediglich mit bereits vorliegenden Informationen und mit der von dem Serviceprovidercomputer übermittelten individuellen Anfrageinformation des Serviceproviders ein Token erstellen und an den Serviceprovidercomputer übermitteln muss. Die Erstellung des Tokens kann vollständig automatisiert und ohne einen Benutzereingriff durchgeführt werden, so dass der Benutzer die Durchführung des erfindungsgemäßen Verfahrens während einer Abfrage bzw. vor der Inanspruchnahme des angefragten Services des Serviceproviders nicht bemerken muss. Es ist jedoch ebenfalls möglich und gegebenenfalls von einem Benutzer oder insbesondere von einem Serviceprovider erwünscht, dass der Benutzer eine explizite Bestätigung oder Zustimmung zur Erstellung und Übermittlung des Tokens bei der Inanspruchnahme des Services des Serviceproviders an den Serviceprovider übermittelt. Diese Bestätigung oder Zustimmung kann beispielsweise durch das Anklicken einer Schaltfläche auf einer Benutzeroberfläche oder durch das Aktivieren eines interaktiven Eingabefeldes, bzw. das Setzen eines Häkchens in einer von dem Serviceprovider zur Verfügung gestellten Eingabemaske in einer auf dem Benutzercomputer erzeugten Benutzeroberfläche erfolgen.
-
Zudem ist es möglich, dass mit demselben digitalen Zertifikat der Zertifizierungsstelle innerhalb der Gültigkeitsdauer des Zertifikats mehrere Tokens erzeugt und für verschiedene Abfragen des Benutzers an denselben oder an verschiedene Serviceprovider verwendet wird. Der für den Benutzer anfallenden Aufwand, der für eine einmalige Registrierung des Benutzers bei der Zertifizierungsstelle und für die Beschaffung eines digitalen Zertifikats der Zertifizierungsstelle anfällt, kann demzufolge größer als bei einem aus der Praxis bekannten CAPTCHA sein, da dieser Aufwand nur einmal für die Beschaffung des Zertifikats anfällt und anschließend mit demselben Zertifikat ohne zusätzlichen Benutzeraufwand mehrere Abfragen an Serviceprovider durchgeführt werden können. Weiterhin ist es ebenfalls möglich, dass für die erneute Beschaffung eines weiteren digitalen Zertifikats eines bereits registrierten Benutzers keine erneute Benutzerinteraktion mit der Zertifizierungsstelle erforderlich wird und jedes weitere digitale Zertifikat durch ein automatisiertes Verfahren bei Bedarf von der Zertifizierungsstelle erzeugt und an den Benutzercomputer übermittelt wird. In diesem Fall fällt nach der erstmaligen Registrierung und Beschaffung eines ersten digitalen Zertifikats kein weiterer nennenswerter Aufwand bei dem Benutzer an. Auch bei einem vergleichsweise hohen Aufwand für die erstmalige Registrierung und Beschaffung eines digitalen Zertifikats ist die Akzeptanz des erfindungsgemäßen Verfahrens bei den Benutzern wesentlich höher als die Verwendung einzelner CAPTCHAs, die bei jeder Abfrage bei einem Serviceprovider bearbeitet und gelöst werden müssen.
-
Einer Ausgestaltung des Erfindungsgedankens zufolge ist vorgesehen, dass der Serviceprovider in einem Einlöseschritt das Token an die Zertifizierungsstelle übermittelt. Die Zertifizierungsstelle kann dann beispielsweise überprüfen, ob der betreffende Benutzer innerhalb einer kurzen Zeit bei verschiedenen Serviceprovidern eine übermäßig große Anzahl von Abfragen durchgeführt hat, was auf eine missbräuchliche Nutzung des für den Benutzer ausgestellten Zertifikats schließen lässt, obwohl der betreffende Benutzer bei jedem einzelnen Serviceprovider keine auffallend hohe Anzahl von Abfragen innerhalb des Überprüfungszeitraums durchgeführt hat.
-
Weiterhin kann die Zertifizierungsstelle in Kenntnis des Abfrageverhaltens des Benutzers das Vertrauen der Zertifizierungsstelle in den Benutzer anpassen, so dass bei einer erneuten Anfrage des Benutzers nach einem digitalen Zertifikat der Zertifizierungsstelle die Gültigkeitsdauer bei einem hohen Vertrauen in den Benutzer länger vorgegeben wird, während die Gültigkeitsdauer bei einem geringen Vertrauen in den Benutzer kürzer vorgegeben wird.
-
In der Praxis kann die von der Zertifizierungsstelle vorgegebene Gültigkeitsdauer eines digitalen Zertifikats zwischen einem sehr kurzen Zeitraum, der im Wesentlichen einer zeitgleich mit der Abfrage bei dem Serviceprovider durchzuführenden Anfrage nach einem digitalen Zertifikat der Zertifizierungsstelle gleichkommt, und einem langen Zeitraum von beispielsweise mehreren Tagen oder Wochen liegen, falls der Benutzer nur gelegentlich Abfragen bei dem Serviceprovider durchführt und demzufolge nur selten ein Token generieren und an den Serviceprovider übermitteln muss.
-
Der Serviceprovider kann das Token eines Benutzers zeitnah an die Zertifizierungsstelle übermitteln, um der Zertifizierungsstelle ein rasches Feedback zu der Abfrage des Benutzers an die Zertifizierungsstelle zu geben. Es ist ebenfalls möglich und in der Praxis für viele Anwendungsfälle zweckmäßig, dass der Serviceprovider nur in zeitlichen Abständen die bis dahin von verschiedenen Abfragen gegebenenfalls von mehreren Benutzern angesammelten Tokens an die Zertifizierungsstelle übermittelt. Der hierfür anfallende Kommunikationsaufwand ist erheblich geringer als bei einer zeitnahen, bzw. sofortigen Übermittlung des von einem Benutzer erhaltenen Tokens an die Zertifizierungsstelle. Sofern dem Serviceprovider keine anderweitigen Hinweise auf eine missbräuchliche Abfrage durch den Benutzer vorliegen, ist es nicht erforderlich, dass der Serviceprovider das von dem Benutzer erhaltene Token umgehend an die Zertifizierungsstelle weiterleitet. Trotz einer im Nachgang möglichen Überprüfung einzelner Tokens durch die Zertifizierungsstelle kann der Kommunikationsaufwand zwischen dem Serviceprovidercomputer und dem Benutzercomputer während einer Abfrage bei dem Serviceprovider durch den Benutzer vergleichbar gering wie bei einem CAPTCHA gehalten werden. Eine zeitgleiche oder zeitnahe Kommunikation zwischen dem Serviceprovidercomputer und dem Zertifizierungsstellencomputer ist nicht erforderlich, um die Abfrage des Benutzers bei dem Serviceprovider zu bearbeiten.
-
Um zu verhindern, dass die Zertifizierungsstelle durch eine Auswertung der von einem Serviceprovider an die Zertifizierungsstelle übermittelten Token Informationen über ein Benutzerverhalten erhalten kann, ist gemäß einer Ausgestaltung des Erfindungsgedankens vorgesehen, dass der Serviceprovider in einem Einlöseschritt das Token an eine Tokensammelstelle übermittelt, die nach einem Erhalt mehrerer Tokens eine Anzahl von Tokens an die Zertifizierungsstelle übermittelt. Das Token enthält lediglich eine individualisierende Anfrageinformation des Serviceproviders und muss darüber hinaus keine näheren Angaben zu dem Serviceprovider oder zu einer Dienstleistung enthalten, die der Benutzer bei dem Serviceprovider in Anspruch genommen hat. Sofern die individualisierende Anfrageinformation keine Rückschlüsse auf den Serviceprovider ermöglicht, was für eine große Anzahl von üblicherweise verwendeten individualisierenden Anfrageinformationen vorgegeben werden kann, kann die Zertifizierungsstelle dem Token nicht entnehmen, bei welchem Serviceprovider welchen Service der Benutzer in Anspruch genommen hat. Da die Zertifizierungsstelle die Tokens nicht direkt von dem Serviceprovider, sondern über eine die Tokens lediglich weiterleitende Tokensammelstelle erhält, kann die Zertifizierungsstelle auch über eine Auswertung des Kommunikationswegs keine näheren Informationen über das Benutzerverhalten einzelner Benutzer ermitteln.
-
Um zu verhindern, dass ein von dem Benutzer an den Serviceprovider übermitteltes Token von dem Serviceprovider in einem einzigen Einlöseschritt oder in mehreren voneinander getrennten Einlöseschritten mehrfach an die Zertifizierungsstelle übermittelt und eingelöst werden kann, ist vorgesehen, dass die Zertifizierungsstelle in einer Speichereinrichtung von dem Serviceprovider übermittelte Tokens speichert und bei Erhalt eines weiteren Tokens von dem Serviceprovider in einem Tokenprüfungsschritt bestätigt, dass das weitere Token nicht mit einem bereits gespeicherten Token übereinstimmt. Mit dem Tokenprüfungsschritt kann die Zertifizierungsstelle überprüfen, dass der Serviceprovider an die Zertifizierungsstelle nur diejenigen Tokens übermittelt, die der Serviceprovider tatsächlich von einem Benutzer für die Abfrage bei diesem Serviceprovider erhalten hat. Ein Missbrauch des Verfahrens durch einen Serviceprovider wird dadurch erschwert.
-
Die Gültigkeitsdauer eines digitalen Zertifikats, mit dem der Benutzer ein Token erstellen kann, wird von der Zertifizierungsstelle vorgegeben, wobei der Serviceprovider nur begrenzt durch dessen Feedback an die Zertifizierungsstelle darauf Einfluss nehmen kann. Insbesondere bei digitalen Zertifikaten mit einer langen Gültigkeitsdauer hat der Serviceprovider während dieser Gültigkeitsdauer keine Möglichkeit, einen eventuell erfolgenden Missbrauch durch einen Benutzer anhand des Tokens festzustellen, welches der Benutzer dem Serviceprovider übermittelt. In vorteilhafter Weise ist deshalb vorgesehen, dass der Serviceprovider in einem Serviceproviderprüfungsschritt die von einem Benutzer innerhalb einer vorgegebenen Überprüfungszeitdauer an den Serviceprovider übermittelten Tokens zählt und bestätigt, dass eine gezählte Anzahl von Tokens des Benutzers geringer als ein Missbrauchsschwellenwert des Serviceproviders ist. Die gezählte Anzahl von Tokens, die ein Benutzer innerhalb der von dem Serviceprovider frei wählbaren Überprüfungszeitdauer an den Serviceprovider übermittelt, ermöglicht dem Serviceprovider eine eigene Kontrolle des Benutzerverhaltens, die unabhängig von den Tokens durchgeführt werden kann, die der Benutzer an den Serviceprovider übermittelt. Das Ergebnis dieser Überprüfung kann von dem Serviceprovider beispielsweise an die Zertifizierungsstelle übermittelt werden, um Einfluss auf die Gültigkeitsdauer von weiteren digitalen Zertifikaten zu nehmen, die von der Zertifizierungsstelle für den betreffenden Benutzer ausgestellt werden. Es ist ebenfalls möglich, dass der Serviceprovider maßgeblich anhand des Ergebnisses seiner Überprüfung der gezählten Anzahl von Tokens eines Benutzers weitere Tokens desselben Benutzers entgegennimmt und akzeptiert, und gegebenenfalls erst nachrangig eine Überprüfung des Tokens durchführt, falls der Benutzer akzeptiert wurde.
-
Die Anzahl von Tokens, die ein Benutzer an den Serviceprovider übermittelt, kann auch beispielsweise anhand einer eindeutigen Identifikation des Benutzercomputers erfolgen, wobei in diesem Fall nicht die tatsächlich von einem Benutzer übermittelten Tokens, sondern die von dem Benutzercomputer übermittelten Tokens gezählt werden, wobei dann unterstellt wird, dass nicht zwei verschiedene Benutzer denselben Benutzercomputer zeitgleich für Abfragen von Services desselben Serviceproviders nutzen.
-
Der Aufwand, ein aus der Praxis bekanntes CAPTCHA zu lösen, kann in einen finanziellen Gegenwert umgerechnet werden, der beispielsweise 0,1 Cent je CAPTCHA beträgt. Andere CAPTCHAs werden beispielsweise dazu verwendet, die automatisierte Texterkennung von Dokumenten durch mehrfache Überprüfung entsprechender Bildausschnitte in bildbasierten CAPTCHAs zu verbessern, worin ebenfalls ein Gegenwert gesehen werden kann. Es ist grundsätzlich möglich, die Erstellung eines digitalen Zertifikats von der Zertifizierungsstelle davon abhängig zu machen, dass der Benutzer einen Gegenwert an die Zertifizierungsstelle übermittelt. Einer Ausgestaltung des Erfindungsgedankens zufolge ist demzufolge vorgesehen, dass der Benutzer in einem Gegenwertregistrierungsschritt der Zertifizierungsstelle einen von der Zertifizierungsstelle akzeptierten Benutzergegenwert übermittelt. Der Benutzergegenwert kann ein finanzieller Betrag sein. Es ist ebenfalls möglich, dass der Benutzer anspruchsvolle Aufgaben bearbeitet und Lösungen an die Zertifizierungsstelle übermittelt, um an Stelle von oder zusätzlich zu einem finanziellen Betrag den Benutzergegenwert zu erbringen. Weiterhin besteht die Möglichkeit, dass der Benutzer seine Kontoinformationen sowie seine Zustimmung zu einer nachträglichen Abbuchung eines Benutzergegenwerts bei der Zertifizierungsstelle hinterlegt, so dass die Zertifizierungsstelle in Abhängigkeit von dem Benutzerverhalten gegebenenfalls eine entsprechende Abbuchung von dem Konto des Benutzers durchführt.
-
Auf diese Weise können auch Bezahlsysteme eingerichtet werden, so dass es dem Benutzer möglich ist, beispielsweise über einen individuellen Abfragegegenwert, den der Benutzer in das Token integriert, Bezahldienste von einem Serviceprovider in Anspruch zu nehmen, der in dem Einlöseschritt das Token des Benutzers mit dem darin enthaltenen Abfragegegenwert an die Zertifizierungsstelle übermittelt und von der Zertifizierungsstelle nach deren Überprüfung des Tokens den Abfragegegenwert erhält. Die Zertifizierungsstelle stellt ihrerseits den Abfragegegenwert dem betreffenden Benutzer in Rechnung, der das Token mit dem Abfragegegenwert erzeugt und an den Serviceprovider übermittelt hat.
-
Mit dem erfindungsgemäßen Verfahren können auch weitgehend anonyme Bezahldienstverfahren realisiert werden, bei denen der Serviceprovider von der Zertifizierungsstelle bezahlt wird und deshalb nicht notwendigerweise die Identität des den Serviceprovider nutzenden Benutzers kennen muss, während die Zertifizierungsstelle üblicherweise die Identität des Benutzers kennt, jedoch bei einer Übermittlung von Tokens über eine Tokensammelstelle nicht die einzelnen Serviceprovider oder die von dem Benutzer in Anspruch genommenen Services kennt.
-
Um einen Missbrauch von Services des Serviceproviders zu reduzieren, die der Serviceprovider nur als Bezahldienste anbietet und von dem Erhalt eines Gegenwerts abhängig macht, ist vorgesehen, dass die Zertifizierungsstelle in Abhängigkeit von einem von dem Benutzer erhaltenen Benutzergegenwert einen Zertifikatgegenwert ermittelt und in dem Zertifizierungsschritt den Zertifikatgegenwert in das digitale Zertifikat integriert. Der Zertifikatgegenwert kann dann einen Gegenwert für den Serviceprovider darstellen, den die Zertifizierungsstelle gegenüber dem Serviceprovider garantiert. Der Zertifikatgegenwert wird üblicherweise in Abhängigkeit von der Gültigkeitsdauer des Zertifikats und von dem Vertrauen der Zertifizierungsstelle in den betreffenden Benutzer vorgegeben werden. Der Benutzer kann auch der Zertifizierungsstelle im Voraus einen großen Benutzergegenwert übermitteln, so dass die Zertifizierungsstelle auch bei vergleichsweise hohen Zertifikatsgegenwerten nur ein geringes Risiko eingeht.
-
Weiterhin kann vorgesehen sein, dass der Serviceprovider zu seinem Schutz in dem Überprüfungsschritt bestätigt, dass der Zertifikatgegenwert größer als ein Gegenwertschwellenwert des Serviceproviders ist. Im Falle einer missbräuchlichen Ausnutzung von Services des Serviceproviders, der beispielsweise maximal einem Gegenwert unterhalb des Gegenwertschwellenwerts entspricht, kann der Serviceprovider dann von der Zertifizierungsstelle einen Gegenwert in Höhe des Zertifikatgegenwerts anfordern und dadurch den durch die missbräuchliche Ausnutzung entstandenen Schaden reduzieren.
-
Es ist ebenfalls möglich, dass der Serviceprovider in dem Einlöseschritt zusammen mit dem Token einen Servicegegenwert übermittelt. Der Serviceprovider muss demzufolge weder den von dem Benutzer vorgebbaren Benutzergegenwert noch den von der Zertifizierungsstelle vorgebbaren Zertifikatgegenwert für die Abrechnung seiner Services verwenden, die von dem Benutzer tatsächlich in Anspruch genommen wurden. Auf diese Weise ist eine präzise Abrechnung der tatsächlich in Anspruch genommenen Dienstleistungen durch den Serviceprovider möglich, wobei gleichzeitig bei dem Benutzer lediglich ein geringer Bearbeitungsaufwand für die Beschaffung eines digitalen Zertifikats von der Zertifizierungsstelle anfällt und der Serviceprovider eine oftmals ausreichende Sicherheit für den Erhalt des Gegenwerts von der Zertifizierungsstelle erhält.
-
Um zu ermöglichen, dass ein einzelner Benutzer völlig anonym gegenüber dem Serviceprovider auftreten kann und der Serviceprovider auch nicht anhand des öffentlichen Benutzerschlüssels nähere Informationen über den Benutzer in Erfahrung bringen kann ist gemäß einer Variante des erfindungsgemäßen Verfahrens vorgesehen, dass der öffentliche Benutzerschlüssel keine Informationen enthält, die es dem Serviceprovider ermöglichen, die Identität oder andere individualisierende Informationen über den Benutzer in Erfahrung zu bringen. Zu diesem Zweck kann vorgesehen sein, dass die Zertifizierungsstelle in einem dem Zertifizierungsschritt vorausgehenden Gruppenbildungsschritt mehrere Benutzer zu einer Gruppe zusammenfasst und jedem Benutzer einen privaten Benutzergruppenschlüssel übermittelt, dass die Zertifizierungsstelle in dem Zertifizierungsschritt für den Benutzer ein digitales Zertifikat erzeugt, welches an Stelle des öffentlichen Benutzerschlüssels einen öffentlichen Benutzergruppenschlüssel umfasst, dass in dem Tokengenerierungsschritt der Benutzer das digitale Zertifikat und die Anfrageinformation mit dem privaten Benutzergruppenschlüssel digital signiert, und dass der Serviceprovider in dem Überprüfungsschritt mit dem öffentlichen Benutzergruppenschlüssel aus dem digitalen Zertifikat der Zertifizierungsstelle die Echtheit der digitalen Benutzergruppensignatur bestätigt.
-
Der Serviceprovider kann anhand des in dem Token enthaltenen öffentlichen Benutzergruppenschlüssels lediglich feststellen, dass das betreffende Token von einem Benutzer erzeugt und an den Serviceprovider übermittelt wurde, der ein Mitglied der Benutzergruppe ist. Nur die Zertifizierungsstelle, welche die privaten und öffentlichen Benutzergruppenschlüssel erzeugt und an die mehreren Benutzer verteilt hat, kann nachvollziehen, von welchem Benutzer mit dessen privaten Benutzergruppenschlüssel das betreffende Token erzeugt wurde, und somit die Identität des betreffenden Benutzers ermitteln.
-
Nachfolgend werden beispielhaft verschiedene Ausgestaltungen des Erfindungsgedankens anhand der Abbildungen näher erläutert. Es zeigt:
-
1 eine schematische Darstellung der einzelnen Verfahrensschritte, die bei dem erfindungsgemäßen Verfahren zwischen dem Benutzer, der Zertifizierungsstelle und dem Serviceprovider durchgeführt werden,
-
2 eine schematische Darstellung eines Tokens, das nach dem Tokengenerierungsschritt von dem Benutzer an den Serviceprovider übermittelt wird,
-
3 eine schematische Darstellung eines Zertifizierungsschritts, in dem die Zertifizierungsstelle auf Anfrage des Benutzers ein digitales Zertifikat erstellt und an den Benutzer übermittelt,
-
4 eine schematische Darstellung eines Tokengenerierungsschritts und einer anschließenden Übermittlung des von dem Benutzer erzeugten Tokens an den Serviceprovider, und
-
5 eine schematische Darstellung eines Einlöseschritts, in dem der Serviceprovider ein von dem Benutzer übermitteltes Token an die Zertifizierungsstelle übermittelt.
-
Ein erfindungsgemäßes Verfahren zur Unterscheidung von missbräuchlichen Abfragen von zulässigen Abfragen durch einen Benutzer U an einen Serviceprovider SP in einem Computernetzwerk ist in einer viele Verfahrensschritte zeigenden Übersicht in 1 dargestellt. In den 3 bis 5 sind einzelne Verfahrensschritte detaillierter dargestellt. In 2 ist schematisch eine Zusammensetzung eines Tokens T dargestellt, das während des erfindungsgemäßen Verfahrens erzeugt und an Stelle von einem gelösten CAPTCHA von dem Benutzer U an den Serviceprovider SP übermittelt wird.
-
Das erfindungsgemäße Verfahren verwendet digitale Signaturen, wie sie beispielsweise mit asymmetrischen Verschlüsselungsverfahren erzeugt werden können, bei denen ein Schlüsselpaar bestehend aus einem privaten Schlüssel und aus einem öffentlichen Schlüssel verwendet wird, um Informationen zu verschlüsseln oder zu entschlüsseln. Wird mit dem privaten Schlüssel eine digitale Signatur erstellt, indem eine digitale Information mit dem privaten Schlüssel verschlüsselt wird, kann jeder mit Hilfe des öffentlichen Schlüssels überprüfen, ob die digitale Signatur mit dem privaten Schlüssel erzeugt wurde, der dem betreffenden öffentlichen Schlüssel zugeordnet ist. Für das erfindungsgemäße Verfahren ist lediglich eine überprüfbare digitale Signatur erforderlich, die gegebenenfalls auch mit anderen kryptografischen oder ganz allgemein digitalen Verfahren erzeugt und überprüft werden kann.
-
Der Benutzer U, der an Stelle der Lösung eines CAPTCHAs das erfindungsgemäße Verfahren zur Umgehung von CAPTCHAs nutzen will, benötigt zunächst ein Benutzerschlüsselpaar mit einem privaten Benutzerschlüssel skU und mit einem öffentlichen Benutzerschlüssel pkU. Dieses Benutzerschlüsselpaar kann von dem Benutzer U in einem Generierungsschritt vorab erstellt werden, oder aber unmittelbar vor dem Beginn eines Zertifizierungsschritts 1, den der Benutzer U bei einer Zertifizierungsstelle Z durch eine Anfrage 2 einleitet. Der Zertifizierungsschritt 1 ist in 3 anschaulich dargestellt.
-
Die Zertifizierungsstelle Z besitzt ein Zertifizierungsschlüsselpaar mit einem privaten Zertifizierungsschlüssel skZ und einem öffentlichen Zertifizierungsschlüssel pkZ. Die Zertifizierungsstelle Z kann von dem Benutzer U nähere Angaben zu der Identität des Benutzers U anfordern. Die Zertifizierungsstelle Z kann weiterhin eine finanzielle Gegenleistung oder die Durchführung komplexer Aufgaben wie beispielsweise die manuelle Texterkennung in Bilddokumenten einfordern, bevor die Zertifizierungsstelle Z ein digitales Zertifikat CU für den Benutzer erstellt. Die von der Zertifizierungsstelle Z von dem Benutzer U angeforderten Informationen oder Gegenleistungen können das Vertrauen der Zertifizierungsstelle Z in den betreffenden Benutzer U erhöhen, so dass dem Benutzer U von der Zertifizierungsstelle Z ein digitales Zertifikat CU mit einer längeren Gültigkeitsdauer t oder gegebenenfalls mit einem Kreditrahmen für die Verwendung des digitalen Zertifikats CU bei Bezahlsystemen eingeräumt wird.
-
Dieses digitale Zertifikat CU setzt sich zusammen aus dem öffentlichen Benutzerschlüssel pkU des Benutzers, aus Informationen über die Gültigkeitsdauer t des digitalen Zertifikats und aus einer digitalen Zertifizierungsstellensignatur σ‘, wobei die Zertifizierungsstellensignatur σ‘ der Zertifizierungsstelle Z die Informationen über die Gültigkeitsdauer t und über den öffentlichen Benutzerschlüssel pkU beinhaltet. Diese digitale Zertifizierungsstellensignatur σ‘ der Zertifizierungsstelle Z wird beispielsweise mit einem aus der Praxis bekannten Signaturerzeugungsverfahren Sign() erstellt, das mit Hilfe des privaten Zertifizierungsschlüssels skZ aus den Informationen über die Gültigkeitsdauer t und aus dem öffentlichen Benutzerschlüssel pkU eine Signaturdatei, bzw. die digitale Zertifizierungsstellensignatur σ‘ = Sign(pkU, t) erstellt. Das von der Zertifizierungsstelle Z zum Abschluss des Zertifizierungsschritts 1 in einem Übermittlungsschritt 3 an den Benutzer U übermittelte digitale Zertifikat CU beinhaltet die Informationen über die Gültigkeitsdauer t, den öffentlichen Benutzerschlüssel pkU und die digitale Zertifizierungsstellensignatur σ‘: CU = (pkU, t, σ‘).
-
Um das digitale Zertifikat CU von der Zertifizierungsstelle Z zu erhalten muss der Benutzer U lediglich einmal mit der Zertifizierungsstelle Z kommunizieren. Obwohl weite Teile des Zertifizierungsschritts 1 automatisiert und ohne eine aktive Interaktion mit dem Benutzer U durchgeführt können, wird die Zertifizierungsstelle Z zumindest bei einer erstmaligen Erzeugung eines digitalen Zertifikats CU für einen Benutzer U mit diesem Benutzer U kommunizieren und nähere Informationen über den Benutzer U erhalten wollen. Dies stellt jedoch keine notwendige Voraussetzung für die Durchführung des erfindungsgemäßen Verfahrens dar.
-
Der Benutzer U kann nach Erhalt des digitalen Zertifikats CU von der Zertifizierungsstelle Z einen Serviceprovider SP kontaktieren und mit einer Anfrage 4 eine Dienstleistung des Serviceproviders anfragen. Mit dieser Anfrage 4 wird ein Abfrageschritt 5 eingeleitet, der auch in 4 mit weiteren Einzelheiten dargestellt ist.
-
Nach Erhalt der Anfrage 4 kann der Serviceprovider SP dem Benutzer U in einem Übermittlungsschritt 6 eine individualisierende Anfrageinformation r an den Benutzer U zurückübermitteln. Diese individualisierende Anfrageinformation r kann beispielsweise alternativ zu einem aus der Praxis bekannten CAPTCHA als eine Zugangsvoraussetzung zu den Dienstleistungen des Serviceproviders SP an den Benutzer U übermittelt werden.
-
Der Benutzer U erzeugt dann ausgehend von dem digitalen Zertifikat CU und der individualisierenden Anfrageinformation r mit Hilfe seines privaten Benutzerschlüssels skU eine digitale Benutzersignatur σ: σ = Sign(CU, r).
-
Der Benutzer U erstellt anschließend in einem Tokengenerierungsschritt 7 ein Token T, in dem das digitale Zertifikat CU, die individualisierende Anfrageinformation r und die digitale Benutzersignatur σ zusammengefasst sind: T = (CU, r, σ).
-
Dieses Token T wird von dem Benutzer U zum Abschluss des Abfrageschritts 5 in einem weiteren Übermittlungsschritt 8 an den Serviceprovider SP übermittelt.
-
Der Serviceprovider SP kann das Token überprüfen und anhand des Tokens T entscheiden, ob eine missbräuchliche Anfrage 4 vorliegt, die vermutlich automatisiert erzeugt und an den Serviceprovider SP übermittelt wurde, oder ob ein zulässige Anfrage 4 vorliegt, die vermutlich von einem Menschen aktiv eingeleitet wurde und berechtigterweise Dienste von dem Serviceprovider SP in Anspruch nehmen will.
-
Zu diesem Zweck überprüft der Serviceprovider SP, ob die von dem Serviceprovider SP in Antwort auf die Anfrage 4 des Benutzers U zurückgesandte individualisierende Information r in dem Token T enthalten ist. Weiterhin überprüft der Serviceprovider SP anhand des digitalen Zertifikats CU, ob dieses digitale Zertifikat CU innerhalb dessen Gültigkeitsdauer t von dem Benutzer U verwendet wurde, und mit Hilfe des öffentlichen Zertifizierungsstellenschlüssels pkZ, ob das digitale Zertifikat CU tatsächlich von der Zertifizierungsstelle Z stammt, also die digitale Zertifizierungsstellensignatur σ‘ zu dem öffentlichen Zertifizierungsstellenschlüssel pkZ passt.
-
Sind alle diese Überprüfungen erfolgreich, kann der Serviceprovider SP der Abfrage des betreffenden Benutzers U vertrauen und diese Abfrage als zulässige Abfrage ansehen und behandeln, wenn der Serviceprovider SP der Zertifizierungsstelle Z vertraut.
-
Um im Nachgang eine Überprüfung der von dem Benutzer U mit dem digitalen Zertifikat CU erzeugten Tokens T zu ermöglichen kann der Serviceprovider SP in einem in 5 näher dargestellten Einlöseschritt 9 die gesammelten Tokens T des Benutzers U oder von mehreren Benutzern in zeitlichen Abständen in einem Tokenübermittlungsschritt 10 an die Zertifizierungsstelle Z übermitteln. Die Zertifizierungsstelle Z kann dem Serviceprovider SP nach einer Überprüfung des Tokens T in einem weiteren Übermittlungsschritt 11 eine Bestätigung oder Informationsnachricht zukommen lassen.
-
Wenn beispielsweise einzelnen Tokens T ein finanzieller Gegenwert beigemessen wird oder eine entsprechende Wertangabe als Bestandteil des Tokens T von dem Benutzer U an den Serviceprovider SP übermittelt wird, kann auf diese Weise kann auch ein Bezahlsystem errichtet und abgewickelt werden. Der Benutzer U kann mit Hilfe des von der Zertifizierungsstelle Z zur Verfügung gestellten digitalen Zertifikats CU von dem Serviceprovider SP Bezahldienste abrufen. Der Benutzer U übermittelt vorab oder im Nachgang zu der Nutzung der Bezahldienste der Zertifizierungsstelle Z einen ausreichenden finanziellen Gegenwert. Die für die Nutzung des Bezahldienstes anfallenden Kosten können in den Tokens T oder von dem Serviceprovider SP in dem Einlöseschritt 9 der Zertifizierungsstelle Z mitgeteilt werden, die dem Serviceprovider SP die angeforderte Gegenleistung überträgt und das Konto des Benutzers U bei der Zertifizierungsstelle Z entsprechend belastet.
-
Das erfindungsgemäße Verfahren, mit welchem das Übermitteln und Lösen von CAPTCHAs ersetzt werden kann und gegebenenfalls auch ein Bezahlsystem für Bezahldienste eines Serviceproviders SP errichtet und durchgeführt werden kann, kann auch weitgehend anonymisiert durchgeführt werden. So kann bei dem Verfahren an Stelle eines individuellen Benutzerschlüssels auch ein von der Zertifizierungsstelle Z oder von einem anderen Dienstleister erzeugtes Benutzergruppenschlüsselpaar eingesetzt werden, so dass der Serviceprovider SP aus dem digitalen Zertifikat CU keine individuellen Informationen über den Benutzer U entnehmen kann. Weiterhin können die Tokens T von dem Serviceprovider SP an eine Tokensammelstelle übermittelt werden, die ihrerseits eine Anzahl von Tokens T von verschiedenen Serviceprovidern SP sammelt und gemeinsam an die Zertifizierungsstelle Z übermittelt, so dass die Zertifizierungsstelle Z anhand der Tokenübermittlung keine Informationen über den einzelnen Serviceprovider SP erhält, der von dem Benutzer U kontaktiert und in Anspruch genommen wurde.
