DE60100317T2

DE60100317T2 - Verfahren zum Bereitstellen von Kundenzugriff auf einen inhaltanbietenden Server unter Kontrolle eines resoursenlokalisierenden Servers

Info

Publication number: DE60100317T2
Application number: DE60100317T
Authority: DE
Inventors: Arnaud Legout; Jakob Humme
Original assignee: Castify Networks SA
Current assignee: Aspera France SAS
Priority date: 2001-07-12
Filing date: 2001-07-12
Publication date: 2004-04-29
Anticipated expiration: 2021-07-13
Also published as: EP1278112B1; EP1278112A1; US20030014503A1; JP2003122724A; ATE241820T1; DE60100317D1

Description

Die Erfindung betrifft das Gebiet der Kommunikation über Netzwerke und insbesondere das Authentifizieren und Autorisieren des Zugriffs eines Nutzers oder eines Clients auf einen Content-Provider-Server über ein Netzwerk, wie beispielsweise das World Wide Web. Beim World Wide Web (Web) wird ein zustandsloses Hypertext Transfer Protocol (HTTP) verwendet, um einem Client zu ermöglichen, Inhalt über ein Netzwerk von einem Server anzufordern. Das HTTP-Protokoll ermöglicht die transparente Navigation von Web-Servern zu Web-Servern mittels Hypertext-Verknüpfungen. Eine Hypertext-Verknüpfung realisiert eine Zuordnung eines Teils eines Textes zu einem URL (einheitlichen Ressourcen-Lokalisierer). Ein Web-Browser, der auf dem Computer des Clients läuft, sendet eine HTTP-GET-Nachricht zu einem Web-Server, der auf dem Computer des Servers läuft. Die Adresse des Servers ist mittels eines einheitlichen Ressourcen-Lokalisierers (URL) in der Form "<Protokoll>://<Server-Adresse>/<Pfad>/<Inhalt>" bestimmt. Das Protokoll HTTP ist ein Client-Server-Protokoll, das eine TCP-Netzwerkverbindung nutzt. Wie die Daten vom Browser interpretiert werden, hängt vom MIME-Typ der zurückgegebenen Daten ab. 1 stellt die Basis-Anordnung dar, die vom Client-Server-Protokoll benötigt werden: Ein Client (100) und ein Server (104) sind über ein Netzwerk (102) gekoppelt; dieses Netzwerk kann auch mehrere verkoppelte Netzwerke bilden, wie beispielsweise das Internet. In 1 könnten auf dem Client-Computer (100) ein Web-Browser und auf dem Server-Computer ein Web-Server laufen.
Bei diesem einfachen Szenario, wie in 1 dargestellt, wo der ganze Inhalt vom selben Server bereitgestellt wird, kann ein Client beispielsweise mittels eines einfachen Login- und Passwort-Schemas über eine sichere Verbindung (beispielsweise SSL oder HTTPS) authentifiziert werden. Ist der Client einmal authentifiziert, entscheidet der Server, ob der Client autorisiert ist, auf den Inhalt des Servers zuzugreifen. Jedoch gibt es Fälle, in denen sich der von einem Client angeforderte Inhalt auf einem Server befindet, der von dem Server getrennt ist, der den Client authentifiziert hat.
Solch eine Konfiguration ist in 2 dargestellt, bei der zwei separate Server 204 und 206 zusätzlich zum Client-Computer-System 200 dargestellt sind. Der Client kann über das Netzwerk auf einen der beiden Server zugreifen. Ein Problem ergibt sich, wenn der Client auf Inhalt zugreift, der von einem der Server – sagen wir Server B – unter der Steuerung eines anderen Servers – sagen wir Server A -bereitgestellt wird. In diesem Fall kann das oben erläuterte Authentifizierungsschema nicht angewendet werden.
US-A-5 870 546 ist auf das Problem ausgerichtet, die Effizienz des Bekanntmachens zu ermitteln, was einem Client über ein Netzwerk angezeigt wird; die Effizienz wird als Anzahl der Takte gemessen, in denen ein Client dem auf einem Server angezeigten URL nachgeht. Ein Web-Server-System, das die Bekanntmachung anzeigt, stellt einem Client-System eine URL-Referenz zu dem bekanntgemachten Server bereit. Die URL-Referenz wird mit vorbestimmten Umleit- und Kontodaten kodiert. Auf den Empfang durch den bekanntgemachten Server hin wird die URL-Referenz dekodiert, und die Kontodaten werden gespeichert. Dies macht es dem bekanntgemachten Server möglich, die Nummer des im Web-Server-System angezeigten URLs zu identifizieren, der die Bekanntmachung anzeigt, die vom Client effektiv verfolgt wird. Dieses Dokument stellt nicht auf irgendeine andere Benutzung ab als das Ermitteln der Effizienz des Bekanntmachens, und verhindert insbesondere nicht, dass Verknüpfungen vom Client für das Zugreifen auf den bekanntgemachten Server kopiert werden, ohne zunächst auf das Web-Server-System zuzugreifen, das die Bekanntmachung anzeigt. Solch ein Kopieren der Verknüpfung wird im Rest dieser Beschreibung "Verknüpfungs-Hijacking" bezeichnet.
US-A-5 963 915 erläutert ein Verfahren zum Durchführen von Trans-Internet-Kauf-Transaktionen. In diesem Dokument ist das Problem des "Versuchs eines Dritten, eine Identität zu attacktieren", diskutiert. Das Problem ist, dass ein Dritter in der Lage sein kann, eine sichere Sitzung, die von einem anderen Client-Browser gestartet worden ist, fortzusetzen, wenn die Client-Authentifizierung nur bei Initiierung einer sicheren Sitzung erfolgt. Dieses Dokument erläutert nur die Sicherheit von Kauf-Transaktionen.
US-A-5 708 780 beschreibt ein Verfahren zum Durchführen einer Zugriffssteuerung, bei der der Client auf den Content-Server zugreift und auf einen Authentifizierungs-Server umgeleitet wird, wenn der URL, auf den zugegriffen werden soll, nicht den erforderlichen Sitzungs-Kennzeichner aufweist. Der Authentifizierungs-Server ist daher für den Client versteckt. Das Ändern des vom Content-Provider angebotenen Inhalts erfordert, dass der Satz von Informationsdateien, auf die der gegenwärtige SID den Zugriff autorisiert, aktualisiert wird.
Eine Anzahl von Kryptographie-Algorithmen ist im Stand der Technik offenbart. Einige mögen erwähnt werden:

– Bellare, Mihir; Canetti, Ran; Kawczyk, Hugo: „Keying Hash Functions for Message Authentication; in Advances in Cryptology" – Crypto 96 Proceedings, Skript in Computer Science, Vol. 1109, N. Koblitz ed., Springer Verlag, 1996
– Rivest R., „The MD5 Message-Digest Algorithm", RFC-1321, MIT LCS und RSA Data Security, Inc., April 1992
– Touch, J.: „Performance Analysis of MD5", in Proceedings Sigcomm 95, Boston, Seiten 77–86
– „SECURE HASH STANDARD", National Institute of Standards and Technology, FIBS PUB 180-1, 17. April 1995
– P. Gutmann, „Software Generation of Random Numbers for Cryptographic Purposes", in Proceedings 1998er Usenix Security Symposium, USENIX – Association, 1998, Seiten 243–257

Daher gibt es ein Bedürfnis für einen Prozess zum Bereitstellen eines Zugriffs eines Clients auf einen Content-Provider-Server unter Steuerung eines Ressourcen-Lokalisierungs-Servers, welcher Prozess ein Verknüpfungs-Hijacking nicht erlaubt oder es zumindest sehr stark erschwert, dass solch ein Verknüpfungs-Hijacking vom Client durchgeführt wird.
Bei einem Ausführungsbeispiel weist der Prozess zum Bereitstellen eines Zugriffs eines Clients auf einen Content- Provider-Server unter Steuerung eines Ressourcen-Lokalisierungs-Servers auf:

– den Client, der sich mit einem Netzwerk mittels eines Computersystems verbindet, und der auf den Ressourcen-Lokalisierungs-Server zugreift;
– den Ressourcen-Lokalisierungs-Server, der dem Computersystem einen Ressourcen-Lokalisierer zum Zugreifen auf den Content-Provider-Server bereitstellt, wobei der Ressourcen-Lokalisierer eine digitale Signatur enthält, die repräsentativ für ein Recht ist, das dem Client von dem Ressourcen-Lokalisierungs-Server zum Zugreifen auf den Content-Provider-Server gewährt wird, wobei die digitale Signatur basierend auf zumindest einer eindeutigen Kenngröße des Computersystems oder der Verbindung des Computersystems zu dem Netzwerk und basierend auf einem Kennzeichner des Inhalts, auf den zugegriffen werden soll, berechnet wird;
– das Client-Computersystem, das auf den Content-Provider-Server unter Verwenden des Ressourcen-Lokalisierers zugreift;
– den Content-Provider-Server, der die digitale Signatur, die in dem Ressourcen-Lokalisierer für die Verbindung des Clients zu dem Netzwerk enthalten ist, prüft und dem Client den Zugriff auf den Inhalt gemäß dem Ergebnis dieses Prüfschrittes ermöglicht.

Die digitale Signatur kann als eine Funktion von einem oder mehreren Parametern berechnet werden: einer Adresse des Client-Computersystems im Netzwerk, einer eindeutigen Kenngröße des Client-Computersystems, des Inhalts, auf den vom Client zugegriffen werden soll, einer Client-Identifikation, der Zeit.
Man kann auch dem Ressourcen-Lokalisierungs-Server und dem Content-Provider-Server einen geheimen Schlüssel bereitstellen und die digitale Signatur als eine Funktion des geheimen Schlüssels berechnen. Dieser geheime Schlüssel kann unter Verwenden eines Kryptographie-Zahlengenerators erzeugt werden.
In diesem Fall weist der Schritt des Prüfens der digitalen Signatur durch den Content-Provider vorzugsweise das Berechnen einer anderen digitalen Signatur unter Verwenden des geheimen Schlüssels und das Vergleichen der anderen digitalen Signatur mit der im Ressourcen-Lokalisierer enthaltenen digitalen Signatur auf.
Für die Berechnung ist es vorteilhaft, eine kryptographische Hash-Funktion zu verwenden, ausgewählt aus MDS, SHA-1, MD2, MD4, RIPEMD-128 und RIPEMD-160. Man kann ebenso eine kryptographische Hash-Funktion von einer Zeichenkette nutzen, die mindestens eines von der Adresse des Client-Computersystems im Netzwerk, einer eindeutigen Kenngröße des Client-Computersystems, einer Funktion des Inhalts, auf den vom Client zugegriffen werden soll, einer Client-Identifikation und der Zeit aufweist. Ist dem Ressourcen-Lokalisierungs-Server und dem Content-Provider-Server ein geheimer Schlüssel bereitgestellt, kann die Zeichenkette den geheimen Schlüssel aufweisen.
Bei einem Ausführungsbeispiel der Erfindung ist der Content-Provider-Server ein Content-Delivery-Netzwerk, aufweisend zumindest zwei Server. Dem Ressourcen-Lokalisierungs-Server und einem der Server kann ein geheimer Schlüssel bereitgestellt sein, und dem Ressourcen-Lokalisierungs-Server und dem anderen der mindestens zwei Server kann ein anderer geheimer Schlüssel bereitgestellt sein. Es ist vorteilhaft, dass der geheime Schlüssel für einen der beiden Server unter Verwenden einer kryptographischen Hash-Funktion von einem geheimen Hauptschlüssel und einer Adresse des einen Servers im Netzwerk berechnet wird.
Durch die Erfindung wird ferner auf einem mit einem Netzwerk gekoppelten Ressourcen-Lokalisierungs-Server ein Prozess zum Bereitstellen eines Ressourcen-Lokalisierers einem Client bereitgestellt, aufweisend:

– Empfangen einer Zugriffs-Anforderung von dem Netzwerk für einen der angezeigten Ressourcen-Lokalisierer, die von einem Computersystem erzeugt worden ist, das den Client mit dem Netzwerk koppelt;
– Bereitstellen eines Ressourcen-Lokalisierers dem Netzwerk in Richtung des Computersystems, wobei der Ressourcen-Lokalisierer eine digitale Signatur aufweist, die repräsentativ für ein Recht ist, das dem Client von dem Ressourcen-Lokalisierungs-Server zum Zugreifen auf eine Ressource gewährt wird, die mittels des Ressourcen-Lokalisierers lokalisiert wird, wobei die digitale Signatur basierend auf zumindest einer eindeutigen Kenngröße des Computersystems oder der Verbindung des Computersystems zu dem Netzwerk und basierend auf einem Kennzeichner des Inhalts, auf den zugegriffen werden soll, berechnet wird.

Die Berechnung kann ausgeführt werden, wie oben angegeben.
Durch die Erfindung wird ferner ein Verfahren zum Bereitstellen eines Zugriffs eines Clients auf einen Inhalt auf einem mit einem Netzwerk gekoppelten Content-Provider-Server geschaffen, aufweisend:
Empfangen einer Zugriffs-Anforderung von dem Netzwerk, die von einem Computersystem erzeugt worden ist, das den Client mit dem Netzwerk koppelt, und die eine digitale Signatur enthält;
Prüfen der digitalen Signatur, die in dem Ressourcen-Lokalisierer enthalten ist, gemäß zumindest einer eindeutigen Kenngröße des Computersystems oder der Verbindung des Computersystems zu dem Netzwerk, welche Kenngröße in der Anforderung empfangen worden ist; und
Ermöglichen dem Client, auf den Inhalt gemäß dem Ergebnis dieses Prüfschrittes zuzugreifen.
Der Schritt des Prüfens der digitalen Signatur kann das Berechnen einer anderen digitalen Signatur und das Vergleichen der anderen digitalen Signatur mit der im Ressourcen-Lokalisierer enthaltenen digitalen Signatur aufweisen.
Weist die Zugriffs-Anforderung eine Adresse des Client-Computersystems im Netzwerk auf, kann die andere digitale Signatur als eine Funktion der Adresse berechnet werden. Die Zugriffs-Anforderung kann ferner eine eindeutige Kenngröße des Client-Computer-Systems aufweisen, und die andere digitale Signatur wird dann als eine Funktion von der eindeutigen Kenngröße berechnet. Man kann auch die andere digitale Signatur als eine Funktion des Inhalts, auf den vom Client zuzugreifen ist, als eine Funktion einer Client-Identifikation, als eine Funktion der Zeit oder als eine Funktion eines dem Server bereitgestellten geheimen Schlüssels berechnen.
Zum Berechnen der anderen digitalen Signatur kann man so fortfahren, wie oben erläutert.
Durch die Erfindung wird ferner ein Ressourcen-Lokalisierungs-Server geschaffen, aufweisend:

– eine Verbindung zu einem Netzwerk,
– ein Programm, das das oben angegebene Verfahren durchführt.

Es ist ferner ein Provider-Server vorgesehen, aufweisend:

– eine Verbindung zu einem Netzwerk;
– ein Programm, das das oben angegebene Verfahren ausführt.

In diesem Fall kann der Content-Provider-Server ein Content-Delivery-Netzwerk sein, aufweisend zumindest zwei Server und möglicherweise eine Umleit-Einheit. Im Fall, dass eine Umleit-Einheit vorgesehen ist, würde diese ein Programm aufweisen, das einen der Server des Content-Delivery-Netzwerks auswählt und diesen Prozess durchführt.
Durch die Erfindung wird ferner ein Computerprogrammprodukt bereitgestellt, das in einem computerlesbaren Medium zum Bereitstellen eines Ressourcen-Lokalisierers einem Client auf einem mit einem Netzwerk gekoppelten Lokalisierungs-Server ausgeführt ist, wobei das Computerprogrammprodukt aufweist:

– ein computerlesbares Programmcode-Mittel zum Empfangen einer Zugriffs-Anforderung für einen der angezeigten Ressourcen-Lokalisierer von dem Netzwerk, welche Anforderung von einem Computersystem erzeugt worden ist, das den Client mit dem Netzwerk koppelt;
– ein computerlesbares Programmcode-Mittel zum Bereitstellen eines Ressourcen-Lokalisierers dem Netzwerk in Richtung des Computersystems,

Zuletzt wird durch die Erfindung ferner ein Computerprogrammprodukt bereitgestellt, das in einem computerlesbaren Medium zum Bereitstellen eines Zugriffs eines Clients auf einen Inhalt in einem mit einem Netzwerk gekoppelten Content-Provider-Server ausgeführt ist, wobei das Computerprogrammprodukt aufweist:

– ein computerlesbares Programmcode-Mittel zum Empfangen einer Zugriffs-Anforderung von dem Netzwerk, die von einem Computersystem erzeugt worden ist, das den Client mit dem Netzwerk koppelt, und die eine digitale Signatur enthält;
– ein computerlesbares Programmcode-Mittel zum Prüfen der digitalen Signatur, die in einem Ressourcen-Lokalisierer enthalten ist, gemäß zumindest einer eindeutigen Kenngröße des Computersystems oder der Verbindung des Computersystems zu dem Netzwerk, welche Kenngröße in der Anforderung empfangen worden ist; und
– ein computerlesbares Programmcode-Mittel zum Ermöglichen dem Client, auf den Inhalt gemäß dem Ergebnis dieses Prüfschrittes zuzugreifen.

Andere Merkmale der Erfindung werden beim Berücksichtigen der folgenden Beschreibung unter Bezugnahme auf die Zeichnung in ersichtlich, wobei:
1 ein Client-Server-System zeigt, das über ein Netzwerk angeschlossen ist;
2 ein ähnliches System mit zwei Servern zeigt;
3 ein System zeigt, bei dem einer der Server von 2 durch ein Content-Delivery-Netzwerk mit einer Umleit-Einheit ersetzt ist;
4 ein Flussdiagramm eines erfindungsgemäßen Prozesses als von einem Server ausgeführt zeigt, von dem der Nutzer oder Client einen Ressourcen-Lokalisierer erhält;
5 ein Flussdiagramm eines erfindungsgemäßen Verfahrens als von einem Server ausgeführt zeigt, der dazu dient, den angeforderten Inhalt einem Client zu liefern, wenn mittels des Ressourcen-Lokalisierers angefordert.
2 zeigt ein über ein Netzwerk mit zwei Servern gekoppeltes Client-Server-System. Einer der Server – Server B im Rest dieses Beispiels – ist ein Content-Provider-Server. Der andere Server – Server A bei diesem Beispiel – ist ein Ressourcen-Lokalisierungs-Server, der dem Client einen Ressourcen-Lokalisierer zum Zugreifen auf den Server B bereitstellt.
Beispielsweise soll A ein Inhalteverarbeiter (content aggregator) sein (beispielsweise ein Web-Portal), der eine Vertragsbeziehung mit B, einem Content-Provider, hat. A bietet über seine Web-Site Verknüpfungen auf Inhalt-Datenelemente an, die von einem Server (beispielsweise einem Web-Server, FTP-Server oder einem Datenstrom-Medien-Server) bedient werden, der von B betrieben wird. Da A und B eine Vertragsbeziehung haben, möchten sie verhindern, dass irgendein Dritter C ebenfalls Verknüpfungen zum von B bereitgestellten Inhalt anbieten kann. Im heutigen Internet könnte C die Verknüpfungen von den Web-Seiten von A kopieren und in seinen eigenen Web-Seiten verwenden, was eine Form des "Verknüpfungs-Hijacking" darstellt. Die Verknüpfungen können auch von einem Client für einen späteren Zugriff auf den Inhalt, bereitgestellt durch B, oder zum Weiterleiten einem anderen Client kopiert werden. Dies ist eine andere Form des Verknüpfungs-Hijacking.
Erfindungsgemäß wird dieses Verknüpfungs-Hijacking-Problem durch Einführen einer digitalen Signatur in den Ressourcen-Lokalisierer gelöst, der vom Ressourcen-Lokalisierungs-Server A dem Client zum Zugreifen auf den Content-Provider-Server B bereitgestellt wird. Die digitale Signatur stellt ein Recht dar, das vom Ressourcen-Lokalisierungs-Server A dem Client für das Zugreifen auf den Content-Provider-Server B gewährt wird; sie wird basierend auf zumindest einer eindeutigen Kenngröße des Computersystems oder der Verbindung des Computersystems zum Netzwerk berechnet.
Danach greift das Client-Computersystem auf den Content-Provider-Server unter Verwenden der Ressourcen-Lokalisierung zu; der Content-Provider-Server B kann dann die in der Ressourcen-Lokalisierung enthaltene digitale Signatur prüfen und kann dem Client erlauben, auf den Inhalt gemäß dem Ergebnis dieses Prüfschrittes zuzugreifen.
Dies verhindert eine beliebige Form des Verknüpfungs-Hijacking. Es wird angenommen, die Ressourcen-Lokalisierung wird vom Client kopiert und einem Dritten bereitgestellt. Die digitale Signatur wird basierend auf zumindest einer eindeutigen Kenngröße des Computersystems oder der Verbindung des Computersystem zum Netzwerk berechnet. Daher kann der Content-Provider-Server B auf das Empfangen der Ressourcen-Lokalisierung vom Dritten hin identifizieren, dass die Ressourcen-Lokalisierung von jemandem gesendet worden ist, der die erforderliche eindeutige Kenngröße nicht aufweist. Der Content-Provider-Server kann daher ablehnen, die Anforderung des Dritten zu bedienen.
Daher kann A zusammen mit bekannten Web-Server-Sicherheitseinstellungen – SSL, HTTPS oder einem beliebigen anderen Schema zum Erkennen des Clients – einen auf Abonnement basierten Content-Zugriff auf den Inhalt von B oder Pay-Per-View-Modelle anbieten, ohne dass es für B erforderlich ist, ebenfalls eine Ende-Zu-Ende-Sicherung zu verwenden. Dies ist insbesondere nützlich, wenn die Inhalte, die von B bedient werden, große Dateien sind oder Daten sind, die über verbindungslose Protokolle (beispielsweise Audio/Video-Inhalt mittels Datenströmen durch Medien-Server, wie beispielsweise Windows Media Player von Microsoft oder RealServer von RealNetwork übertragen) in Datenströmen übertragen werden. Ferner erfordert bei dem nachstehend erläuterten bevorzugten Ausführungsbeispiel die Erfindung lediglich den Austausch persönlicher Schlüssel zwischen A und B das eine Mal, wenn der Dienst initialisiert wird. Danach ist zwischen den Servern A und B keine direkte Kommunikation erforderlich.
Bei dem bevorzugten Ausführungsbeispiel wird im Rahmen der Erfindung ein Schema basierend auf einer kryptographischen Hash-Funktion und der Verwendung eines geheimen Schlüssels verwendet. Die Stärke dieses Schemas basiert auf der Tatsache, dass es bei einem gegebenen geheimen Schlüssel K und einer kryptographischen Hash-Funktion H mit Berechnungsmethoden praktisch unmöglich ist, ohne K zu kennen, ein m' zu finden, sodass H(K + m + K) = H(m'), und es praktisch unmöglich ist, mit Berechnungsverfahren K basierend auf dem Wissen von m und von H(K + m + K) zu finden; dies ist in Bellare et al. erläutert. Sollte in der Zukunft ein mathematisches Verfahren bekannt sein, dass dieses vorherige Schema durchbricht, ist es jederzeit im Rahmen der Erfindung möglich, die Parameter in der kryptographischen Hash-Funktion zu verändern, um deren Widerstandsfähigkeit gegen Attacken zu erhöhen; ein Beispiel würde die Verwendung von HMAC sein, wie in Bellare et al. beschrieben. Es ist ferner möglich, eine andere, neuere Hash-Funktion mit strengeren Eigenschaften zu verwenden; neue und sichere kryptographische Hash-Funktionen werden regelmäßig veröffentlicht.
Ein bevorzugtes Ausführungsbeispiel der Erfindung wird nun beschrieben.
1. Initialisierung:
Zunächst wird ein geheimer Schlüssel K_Web erzeugt. Der Schlüssel wird bevorzugt durch einen kryptographisch strengen Schlüsselgenerator erzeugt. Dies bedeutet, dass es mit einer beliebigen Folge von Schlüsseln nicht möglich ist, den nächsten Schlüssel in der Reihe zu finden. Implementierungen von kryptographisch strengen Schlüsselgeneratoren sind herkömmlich verfügbar, und eine Beschreibung solch einer Implementierung kann in der Literatur gefunden werden, beispielsweise im Literaturhinweis P. Gutmann. K_Web ist A und B zugeteilt.
2. Authentifizierungs-Prozess:
H sei eine kryptographische Hash-Funktion, beispielsweise MD5 (siehe Rivest-Literaturhinweis), SHA-1 (siehe sicherer Hash-Standard) oder eine beliebig andere. Bei dem bevorzugten Ausführungsbeispiel wählen wir MD5 als Hash-Funktion aus, da sie im Moment der beste Kompromiss zwischen Sicherheit und Geschwindigkeit der Berechnung ist (siehe Touch-Literaturhinweis). Ferner ist MD5 öffentlich verfügbar. Die Ausgabe der MD5-Hash-Funktion ist eine 128 Bit-Zeichenkette, was auch immer die Eingabe ist.
K_Web ist ein geheimer Schlüssel, der vom Web-Server (204) von A und vom Server (206) von B gemeinsam genutzt wird.
Ein Betrachter verbindet sich zunächst mit dem Web-Server von A. Bei einem von der beschriebenen Erfindung unabhängigen Prozess kann der Web-Server diesen Betrachter als autorisiert identifizieren, sich mit dem Web-Server zu verbinden. Beispiele, die diesen gegebenen Prozess implementieren, nutzen SSL, HTTPS oder andere Sicherheitseinstellungen, die an sich bekannt sind.
Alle Web-Seiten, die Verknüpfungen (URLs) zum Inhalt aufweisen, die vom Server von B bedient werden, sind als dynamische Web-Seiten eingesetzt, was bedeutet, dass die Web-Seiten zu dem Zeitpunkt, zu dem der Betrachter auf sie zugreift, ermittelt werden. Zumindest die Ressourcen-Lokalisierung wird dynamisch berechnet, sodass die digitale Signatur basierend auf der eindeutigen Kenngröße des Client-Computersystems oder der Client-Verbindung berechnet wird; der Rest der Seiten kann statisch sein. Zu dem Zeitpunkt, zu dem der Betrachter auf solch ein Web-Seite zugreift, startet das Verfahren dieser Erfindung seinen Authentifizierungs-Prozess.
Bevor die Web-Seite zum Betrachter geliefert wird, ersetzt das im Web-Server von A integrierte Authentifizierungs-Verfahren (beispielsweise unter Verwenden von ASP, JSP oder anderer Techniken, um dynamische Web-Seiten zu erzeugen) jede Verknüpfung zum Inhalt von B durch eine neue Verknüpfung, die die ursprüngliche Verknüpfung plus optionale zusätzliche Daten (beispielsweise einen eindeutigen Nutzer-Kennzeichner und einen Zeitstempel) plus eine digitale Signatur enthält. Die Signatur wird mittels einer kryptographischen Hash-Funktion berechnet, die als Eingabe diese Verknüpfung sowie die zusätzlichen Daten und einen eindeutigen Kennzeichner des Client-Systems oder dessen Verbindung zum Netzwerk sowie den geheimen Schlüssel K_Web nimmt. Bei dieser Beschreibung wird die IP-Adresse der Verbindung des Client-Systems zum Netzwerk als eindeutiger Kennzeichner verwendet. Die IP-Adresse des Betrachters ist aus der TCP-Verbindung zum Web-Server bekannt und ist aus der Implementierung des Authentifizierungsverfahrens heraus zugreifbar. Der Einfachheit halber beschreibt der Rest dieses Abschnitts das Verfahren ohne irgendwelche zusätzliche Daten; die Zweckmäßigkeit zusätzlicher Daten wird dann später beim Beschreiben alternativer Nutzfälle erläutert.
Beispielsweise sei die Authentifizierung als ein Java Bean („urlAuthenticator") implementiert, verwendet von einer Java Server Page (JSP), um eine neue authentifizierte Verknüpfung zu erzeugen.
Der Betrachter sendet eine HTTP-GET-Anforderung an den Web-Server von A, um eine Web-Seite anzuschauen, die die Verknüpfungen zum Inhalt von B (400) enthält. Der folgende JSP-Abschnitt wird dann vom Web-Server von A ausgeführt, um eine neue Verknüpfung für die jeweilige Verknüpfung, die authentifiziert werden soll, zu erzeugen:
was beispielsweise den folgenden HTML-Code erzeugt:
wobei der Teil hinter „?" die digitale Signatur für diesen Inhalt und die IP-Adresse des anfordernden Betrachters ist.
Die Berechnungsschritte des im Web-Server von A implementierten Verfahrens sind im Flussdiagramm von 4 dargestellt. Jede Verknüpfung wird berechnet, sobald die Seite angefordert wird (400). Das Verfahren extrahiert zunächst den URL zum Inhalt von B (402), gegeben im obigen JSP-Beispiel als Parameter der Methodenimplementierung (generateLink()). Die IP-Adresse des Computers des Betrachters wird extrahiert (404) und ferner zur Methode (request.getRemoteHost()) weitergeleitet. Bei diesem Beispiel werden keine zusätzlichen Daten zur Methode weitergeleitet, was Schritt (406) wäre.
Das Verfahren berechnet dann die digitale Signatur (408) wie folgt: S1 = H (KWeb + IPy + contentid + KWeb),wobei H() die kryptographische Hash-Funktion ist, die auf einer Zeichenkette operiert, K_Web ist der geheime Schlüssel, der vom Web-Server von A und vom Server von B gemeinsam verwendet wird, IP_y ist die IP-Adresse des Betrachters, contentid ist der angeforderte Inhalt („1" bei diesem Beispiel), und „+" bezeichnet die Verkettung von Zeichenketten. S₁ muss kodiert werden, um eine gültige Zeichenkette inner halb eines URLs zu sein; bei diesem Beispiel wird der Wert von S₁ als hexadezimale Darstellung in einer Zeichenkette kodiert, was garantiert, dass nur Zeichen von „0–9" und „a–e" verwendet werden, und dass die Gesamtlänge genau 32 Zeichen lang in dem Fall ist, dass MD5 als Hash-Funktion verwendet wird.
Im letzten Schritt werden der ursprüngliche URL und die Signatur aneinander gereiht, sodass ein neuer gültiger URL zum angeforderten Inhalt gebildet ist (410). Dieser URL ist dann die Ausgabe der ausgeführten Methode (412) und wird in die Web-Seite eingefügt, die zurück zum Browser des Betrachters gesendet wird.
An diesem Punkt ist es wichtig zu verstehen, dass die Sicherheit dieses Ausführungsbeispiels der Erfindung auf dem Fakt basiert, dass der geheime Schlüssel K_Web niemals einem unzuverlässigen Dritten gegeben werden darf.
Klickt der Betrachter diese erzeugte Verknüpfung an, verbindet sich die Betrachter-Anwendung (beispielsweise der Web-Browser oder ein Plugin für den spezifizierten Medientyp, wenn der URL ein anderes Protokoll als das HTTP-Protokoll bezeichnet) mit dem Server von B und fordert den URL zusammen mit der Signatur an (500).
Der Server von B leitet den empfangenen URL (der http://www.b.com/1.asx?8978a19bc1c3a98d6467c603e1be299c sein würde, um das vorherige Beispiel fortzusetzen) zusammen mit der IP-Adresse IP_y, (504) von der Verbindung mit dem Betrachter zur Implementierung der Authentifizierungs-Methode bei B weiter. Die Authentifizierungs-Methode extrahiert vom URL die contentid' (502) und S₁ (510).
Schließlich berechnet die Authentifizierungsmethode S₂ = H(K_Web + IP_y + contentid + K_Web) (508) und prüft, ob S₂ gleich S₁ ist (512).
Ist S₂ gleich S₁, wird der angeforderte Inhalt vom Server von B bedient (516), andernfalls wird die Operation ausgeführt, die als die Rechte-Antwort für einen unautorisierten Nutzer betrachtet wird (514), beispielsweise wird ein HTTP-Fehler „Nicht autorisiert" zurückgegeben.
Ist S₂ gleich S₁, ist sichergestellt, dass der Betrachter der Web-Seite von A die gleiche IP-Adresse wie der Betrachter hat, der auf den Server von B zugreift, das bedeutet, dass gilt: IP_y, = IP_y; die Betrachter werden dann betrachtet als seien sie dieselben. Zusätzlich ist gewährleistet, dass dieser Betrachter durch den Web-Server von A autorisiert wurde, sich den angeforderten Inhalt anzuschauen, da contentid und contentid' die Gleichen sind. Da nur die Server von A und B den geheimen Schlüssel IPy gemeinsam verwenden, ist gewährleistet, dass der Betrachter vor dem Zugreifen auf die Web-Seite von A den URL erlangt haben muss und diese Verknüpfung nicht von einer unautorisierten Quelle erlangt haben kann.
Der Prozess hat die folgenden Vorteile. Zwei Provider, A und B, können gewährleisten, dass der Inhalt, den B bedient, nur Clients verfügbar ist, die von A autorisiert wurden. Nur ein initialer geheimer Schlüssel muss zwischen A und B ausgetauscht werden; es ist nicht notwendig, im Voraus alle Nutzer zu kennen, die durch A autorisiert werden; d. h. A kann später mehreren oder anderen Nutzern Zugriff auf den Inhalt von B gewähren.
Das beschriebene Verfahren benötigt keine Echtzeitkommunikation zwischen dem Server, der den Nutzer das erste Mal authentifiziert (A), und dem Server, der den Inhalt für den autorisierten Nutzer bedient (B).
Ferner muss die Verbindung zwischen dem Nutzer und dem Server, der den Inhalt bedient, nicht sicher sein. Dies ist insbesondere wichtig für Datenstrom-Inhalt, der mittels UDP-Paketen bedient wird.
Das beschriebene Verfahren erfordert nicht, dass der Ursprungsserver in Echtzeit mit einem oder mehreren Content-Servern kommuniziert. Dies führt zu einer höheren Leistungsfähigkeit des beschriebenen Verfahrens für den Authentifizierungs-Prozess. Das beschriebene Verfahren ist einfacher zu implementieren und hängt nicht von Netzwerk-Bedingungen zwischen dem Ursprungsserver und den Content-Servern ab.
Das Verfahren weist Vorteile auf, insbesondere wenn verschiedene Content-Server den gleichen Inhalt bedienen können, da der geheime Schlüssel auf jedem Replikations-Server installiert sein kann; beispielsweise, wenn der Inhalt repliziert worden ist, um eine höhere Verfügbarkeit oder schnellere Downloads zu gewährleisten.
Dieses Verfahren arbeitet für alle Formen des Verknüpfungs-Hijacking: es wirkt, wenn ein Dritter Verknüpfungen von A kopiert, aber auch, wenn ein autorisierter Nutzer von A absichtlich die Verknüpfungen auf den Inhalt von B offenlegt.
Das Verfahren wächst ferner mit der Anzahl von Content-Servern. Es kann bei einer Vielzahl von verwandten Produkten verwendet werden. Beispiele sind:

– Content Distribution Netzwerke, die Abonnement-Modelle oder Pay-Per-View-Modelle unterstützen.
– Ermöglichen einem Content-Provider, Inhalt auf dem Netzwerk zu veröffentlichen, und Erlauben Partnern, ihren Kunden, allerdings niemand anderen, Zugriff auf diesen Inhalt anzubieten.

Die Erfindung ist nicht auf das oben erläuterte bevorzugte Ausführungsbeispiel beschränkt. Das Verfahren wurde oben als Beispiel für dynamische Web-Seiten erläutert. Es findet ferner Anwendung auf statische Web-Seiten, vorausgesetzt, dass die digitale Signatur gemäß einer eindeutigen Kenngröße des Client-Computersystems oder der Verbindung berechnet wird. Bei dem Beispiel wird eine kryptographische Hash-Funktion verwendet. Zum Berechnen der digitalen Signatur können andere Mittel verwendet werden – grundsätzlich jede Funktion, bei der es genügend schwierig ist, dass sie vom Client invertiert wird, allerdings muss sie sowohl von dem Ressourcen-Lokalisierungs-Server als auch von dem Content-Provider-Server einfach berechnet werden können. Andere Funktionen als kryptographische Funktionen dürfen es nicht unnötig machen, dem Ressourcen-Lokalisierungs-Server und dem Content-Provider-Server einen geheimen Schlüssel bereitzustellen.
Bei dem Beispiel wird eine eindeutige Kenngröße, die IP-Adresse, genutzt; wie nachstehend erläutert, kann man eine andere eindeutige Kenngröße verwenden; allgemein gesprochen sollte die Kenngröße eindeutig sein, um ein Verknüpfungs-Hijacking zu verhindern, und es sollte vorzugsweise schwierig sein, dass sie vom Client geändert wird.
Bei einem anderen Ausführungsbeispiel der Erfindung können zusätzliche Daten vom Web-Server von A zum Server von B weitergeleitet werden, und es kann gewährleistet werden, dass der Betrachter diese zusätzlichen Daten nicht ändern kann. Als Beispiel kann bei einem Pay-Per-View-System für Datenstrom-Audio/Video-Übertragungen das Folgende nützlich sein: A bietet einen Zugriff auf Datenstrom-Übertragungen an, bedient vom Server von B, allerdings möchte er zusätzlich gewährleisten, dass der Betrachter die von der Web-Seite von A bereitgestellte Verknüpfung nicht mehrere Male benutzt. A hat ferner eine Vereinbarung mit B, dass B A mit den Daten versorgt, so lange ein bestimmter Betrachter auf einen Datenstrom zugreift. Um dies zu tun, nutzt A einen Sicherheits-Web-Server, bei dem sich jeder Betrachter zunächst selbst mittels eines Login- und Passwort-Schemas authentifiziert. Nachdem der Betrachter authentifiziert und autorisiert ist, auf die Web-Seite zuzugreifen, wird diesem Betrachter eine eindeutige Nutzeridentifikation userid zugewiesen. Zusätzlich wird die Zeit erlangt, zu der der Betrachter eine Verknüpfung auf einen Datenstrom ausgewählt hat.
Der mittels des beschriebenen Verfahrens berechnete URL ist aus dem ursprünglichen URL plus der Zeit plus die userid und gefolgt von der Signatur, wie oben beschrieben, zusammengesetzt, aber auch über die zusätzlichen Daten berechnet. Der URL weist daher eine Form ähnlich dem auf: href="http://www.b.com/1.asx?userid_time_S",wobei gilt:S = H (KWeb + IPy + userid + contentid + time + KWeb).
Der Server von B extrahiert aus dem URL time und userid und verweigert den Zugriff auf den Datenstrom, wenn die Differenz zwischen der Zeit im URL und der aktuellen Zeit größer als ein gegebener Schwellenwert ist (beispielsweise 10 Minuten). Dies erfordert, dass die Zeiten zwischen A und Servern schwach synchronisiert sind (weniger als eine Differenz von 10 Minuten), und dass die Zeit im URL in einem übereinstimmenden Zeitzonenformat kodiert ist, der beiden Servern bekannt ist (beispielsweise Universalzeit UTC). B nutzt die erlangte userid, um A zu berichten, wie lang der Betrachter auf den Datenstrom zugegriffen hat. Das Ruthentifizierungsverfahren gewährleistet, dass der Betrachter weder time noch userid ändern kann, um auf den Inhalt von B zuzugreifen.
Bei einem ähnlichen Szenario betreibt B ein Content-Delivery-Netzwerk (CDN), vergleiche 3. In einem CDN ist der Inhalt auf mehreren Servern repliziert. Das beschriebene Verfahren arbeitet wie oben beschrieben, nur dass der geheime Schlüssel IP_y an alle Servern innerhalb des CDN vergeben ist.
Nutzt das CDN in der Anwendungs-Schicht Umleitungen, kann das beschriebene Verfahren verkettet werden. Der geheime Schlüssel K_Web wird unter dem Web-Server von A (304) und der Umleit-Einheit (306) des CDN gemeinsam verwendet. Die Umleit-Einheit des CDN verwendet einen anderen Schlüssel K_CDN, sodass ein neuer URL berechnet wird, der dem Betrachter zurückgegeben wird. Dieser geheime Schlüssel K_CDN wird unter der Umleit-Einheit und all den Content-Servern (308) des CDN gemeinsam verwendet. Sollte der Betrachter dahingehend eingeschränkt sein, dass er lediglich von dem Server Zugriff auf den Datenstrom hat, der von der Umleit-Einheit ausgewählt ist, kann innerhalb des berechneten URLs und der Signatur ein eindeutiger Kennzeichner (beispielsweise die IP-Adresse des ausgewählten Content-Servers) kodiert sein. Bevor ein Content-Server im CDN den Inhalt dem Betrachter liefert, testet der Server mittels Vergleichens der eindeutigen Kennzeichner im URL mit seinem lokal bekannten eindeutigen Kennzeichner, ob er von der Umleit-Einheit ausgewählt ist.
Bei dem Beispiel der kryptographischen Funktion hängt die Sicherheit des Prozesses von der Tatsache ab, dass eine unautorisierte Person den geheimen Schlüssel nicht kennt. Daher ist es bevorzugt, den geheimen Schlüssel auf jedem Server in solcher Weise zu speichern, dass keine unautorisierte Person Zugriff auf ihn hat. Bei einem stark verzweigten System, bestehend aus Hunderten oder Tausenden von Servern (beispielsweise einem großen CDN), kann jedem Server ein anderer geheimer Schlüssel zugeordnet sein, obwohl dies die Initialisierungsphase verkompliziert und die Umleit-Einheit wissen muss, welcher Server den angeforderten Inhalt für eine bestimmte Anforderung bedient. Jedoch erfordert die Berechnung eines kryptographisch strengen geheimen Schlüssels viele CPU-Zyklen, und die geheimen Schlüssel müssen in einer Tabelle von der Umleit-Einheit gespeichert werden. Um diesen Prozess zu fördern, kann das folgende Verfahren verwendet werden:
Die Umleit-Einheit weist einen Haupt-Geheimschlüssel K_RU auf, der durch einen kryptographisch strengen Schlüsselgenerator erzeugt worden ist.
gespeichert. Jedes Mal, wenn die Umleit-Einheit den CDN- Server CS¹ auswählt berechnet die Umleit-Einheit die Signatur S₂ mit dem berechneten Schlüssel
anstelle von K_CDN.
Im Falle, dass ein Schlüssel
gestohlen ist, kann der Dieb auf einen beliebigen Inhalt auf dem CDN-Server CS¹ zugreifen, hat allerdings keinen Zugriff auf die anderen CDN-Server. Ferner ist es mit dem gestohlenen Schlüssel rechentechnisch nicht möglich, den Hauptschlüssel K_RU festzustellen.
Bei der beschriebenen Erfindung wird bei ihrem bevorzugten Ausführungsbeispiel die IP-Adresse des Anfordernden verwendet, da es technisch sehr schwierig ist, seine eigene IP-Adresse zu maskieren und in der Lage zu sein, IP-Pakete von einer Quelle im Internet zu empfangen. Jedoch ist in einigen Fällen die IP-Adresse nicht das beste Authentifizierungs-Verfahren. Firewalls, Web-Proxies und Zwischenspeicher können eine Anforderung abfangen und eine neue Anforderung formulieren, die beim Abfänger erzeugt worden ist. Alternativ kann ein anderer eindeutiger Kennzeichner im Rahmen der beschriebenen Erfindung genommen werden, um die IP-Adresse in der Verfahrensbeschreibung zu ersetzen; Kandidaten für solche eindeutigen Kennzeichner sind u. a.: der globale eindeutige Kennzeichner (GUID), zugeführt durch einige Browser und Medien-Abspielgeräte, oder die CPU-Seriennummer des anfordernden Computers. Das Hauptproblem mit diesen eindeutigen Kennzeichnern ist, dass sie theoretisch einfacher zu maskieren sind als die IP-Adresse. Diese anderen vorgeschlagenen eindeutigen Kennzeichner können ferner zusätzlich zur IP-Adresse genommen werden. Es ist möglich, mehr als einen eindeutigen Kennzeichner zu verwenden.
Die Beschreibung des alternativen Ausführungsbeispiels innerhalb eines CDNs beschreibt, wie eine zentrale Umleit-Einheit einen neuen URL mit einer neuen digitalen Signatur erzeugen kann. Im Rahmen dieser Erfindung ist es ferner möglich, dass die Umleit-Einheit ein Dokument (HTML, XML, ASX, SMILE oder ein anderes Format) mit Verknüpfungen erzeugt, die wie beschrieben für den Ressourcen-Lokalisierungs-Server berechnet werden. Im Allgemeinen kann die Erfindung verkettet werden.
Die Beschreibung des alternativen Ausführungsbeispiels innerhalb eines CDN beschreibt, wie eine zentrale Umleit-Einheit einen neuen URL mit einer neuen digitalen Signatur erzeugen kann. Im Rahmen dieser Erfindung ist es ebenso möglich, dass keine zentrale Umleit-Einheit für ein CDN existiert, aber dass die Umleitung auf dem Netzwerk-Pfad transparent gemacht wird (beispielsweise mittels eines Routers oder ein Schalters der Schicht 4–7). Als Beispiel würde bei solch einem Szenario ein Schicht 4 – Schalter alle HTTP-Anforderungen zu einem HTTP-Zwischenspeicher für alle Endnutzer umleiten, die sich auf diesem Netzwerkpfad befinden. Die Seiten mit den vom Ressourcen-Lokalisierungs-Server erzeugten Verknüpfungen sind als nicht zwischenspeicherbar markiert; wenn der Betrachter den Inhalt vom Content-Server anfordert, nutzt der Zwischenspeicher das gleiche Verfahren wie der Content-Server, um die digitale Signatur zu prüfen, und gewährt den Zugriff auf den Inhalt im Interesse des Content-Servers. Dies impliziert selbstverständlich, dass der Zwischenspeicher die beschriebene Erfindung implementiert. Jedoch verwendet die Umleit-Einheit (bei diesem Beispiel: Schicht 4 – Schalter) nicht das beschriebene Verfahren.
Die oben gegebene Beschreibung zeigt den Prozess als Ganzes. Selbstverständlich kann der Prozess unabhängig auf dem Ressourcen-Lokalisierungs-Server und auf dem Content-Provider-Server, was immer seine Form ist, ausgeführt werden. Es ist möglich, ein Computerprogramm, in dem der Prozess kodiert ist, der auf dem Ressourcen-Lokalisierungs-Server ausgeführt wird, und ein separates Computerprogramm bereitzustellen, in dem der Prozess kodiert ist, der auf dem Content-Provider-Server ausgeführt wird.

Claims

Verfahren zum Bereitstellen eines Client-Zugriffs auf einen Content-Provider-Server unter Kontrolle eines Ressourcen-Lokalisierungs-Servers, aufweisend: den Ressourcen-Lokalisierungs-Server, der Clients Ressourcen-Lokalisierer auf den Inhalt des Content-Provider-Servers anzeigt; den Client, der sich mit einem Netzwerk mittels eines Computersystems verbindet, und der auf den Ressourcen-Lokalisierungs-Server zugreift; den Ressourcen-Lokalisierungs-Server, der dem Computersystem einen Ressourcen-Lokalisierer zum Zugreifen auf den Content-Provider-Server bereitstellt, wobei der Ressourcen-Lokalisierer eine digitale Signatur enthält, die repräsentativ für ein Recht ist, das dem Client von dem Ressourcen-Lokalisierungs-Server zum Zugreifen auf den Content-Provider-Server gewährt wird, wobei die digitale Signatur basierend auf zumindest einer eindeutigen Kenngröße des Computersystems oder der Verbindung des Computersystems zu dem Netzwerk und basierend auf einem Kennzeichner des Inhalts, auf den zugegriffen werden soll, berechnet wird; das Client-Computersystem, das auf den Content-Provider-Server unter Verwenden des Ressourcen-Lokalisierers zugreift; den Content-Provider-Server, der die digitale Signatur, die in dem Ressourcen-Lokalisierer für die Verbindung des Clients zu dem Netzwerk enthalten ist, prüft und dem Client den Zugriff auf den Inhalt gemäß dem Ergebnis dieses Prüfschrittes ermöglicht.
Verfahren gemäß Anspruch 1, wobei der Schritt des Bereitstellens für den Ressourcen-Lokalisierungs-Server das Berechnen der digitalen Signatur als eine Funktion von einer Adresse des Client-Computersystems in dem Netzwerk aufweist.
Verfahren gemäß Anspruch 1, wobei der Schritt des Bereitstellens für den Ressourcen-Lokalisierungs-Server das Berechnen der digitalen Signatur als eine Funktion von einem eindeutigen Kennzeichner des Client-Computersystems aufweist.
Verfahren gemäß Anspruch 1, 2 oder 3, wobei der Schritt des Bereitstellens für den Ressourcen-Lokalisierungs-Server das Berechnen der digitalen Signatur als eine Funktion von einer Client-Identifikation aufweist.
Verfahren gemäß einem der Ansprüche 1 bis 4, wobei der Schritt des Bereitstellens für den Ressourcen-Lokalisierungs-Server das Berechnen der digitalen Signatur als eine Funktion von der Zeit aufweist.
Verfahren gemäß einem der Ansprüche 1 bis 5, ferner aufweisend den Schritt des Bereitstellens eines geheimen Schlüssels dem Ressourcen-Lokalisierungs-Server und dem Content-Provider-Server, und wobei der Schritt des Bereitstellens für den Ressourcen-Lokalisierungs-Server das Berechnen der digitalen Signatur als eine Funktion von dem geheimen Schlüssel aufweist.
Verfahren gemäß Anspruch 6, wobei der Schritt des Bereitstellens eines geheimen Schlüssels das Erzeugen des geheimen Schlüssels unter Verwenden eines Generators für kryptographische Zahlen aufweist.
Verfahren gemäß Anspruch 6 oder 7, wobei der Schritt des Prüfens der digitalen Signatur durch den Content-Provider das Berechnen einer anderen digitalen Signatur unter Verwenden des geheimen Schlüssels sowie das Vergleichen der anderen digitalen Signatur mit der digitalen Signatur aufweist, die in dem Ressourcen-Lokalisierer enthalten ist.
Verfahren gemäß einem der Ansprüche 1 bis 8, wobei der Schritt des Berechnens das Berechnen einer kryptographischen Hash-Funktion aufweist.
Verfahren gemäß einem der Ansprüche 2 bis 9, wobei der Schritt des Berechnens das Berechnen einer kryptographischen Hash-Funktion von einer Zeichenkette aufweist, die zumindest die Adresse des Client-Computersystems in dem Netzwerk, einen eindeutigen Kennzeichner des Client-Computersystems, eine Funktion des Inhalts, auf den von dem Client zugegriffen werden soll, eine Client-Identifikation und/oder einen Zeitwert aufweist.
Verfahren gemäß Anspruch 10, ferner aufweisend den Schritt des Bereitstellens eines geheimen Schlüssels dem Ressourcen-Lokalisierungs-Server und dem Content-Provider-Server, und wobei die Zeichenkette den geheimen Schlüssel aufweist.
Verfahren gemäß Anspruch 11, wobei die kryptographische Hash-Funktion eine schlüsselbasierte kryptographische Hash-Funktion ist.
Verfahren gemäß einem der Ansprüche 9 bis 12, wobei die kryptographische Hash-Funktion aus MD5, SHA-1, MD2, MD4, RIPEMD-128 und RIPEMD-160 ausgewählt ist.
Verfahren gemäß einem der Ansprüche 1 bis 13, wobei der Content-Provider-Server ein Content-Delivery-Netzwerk ist, das zumindest zwei Server aufweist.
Verfahren gemäß Anspruch 14, ferner aufweisend den Schritt des Bereitstellens eines geheimen Schlüssels dem Ressourcen-Lokalisierungs-Server und einem der zumindest zwei Server sowie des Bereitstellens eines anderen geheimen Schlüssels dem Ressourcen-Lokalisierungs-Server und dem anderen der zumindest zwei Server.
Verfahren gemäß Anspruch 15, wobei ein geheimer Schlüssel für einen der zumindest zwei Server unter Verwenden einer kryptographischen Hash-Funktion von einem geheimen Haupt-Schlüssel und einer Adresse des einen Servers in dem Netzwerk berechnet wird.
Verfahren zum Bereitstellen eines Ressourcen-Lokalisierers auf einem Ressourcen-Lokalisierungs-Server, der mit einem Netzwerk gekoppelt ist, einem Client, aufweisend: Anzeigen den Clients Ressourcen-Lokalisierer; Empfangen einer Zugriffs-Anforderung von dem Netzwerk für einen der angezeigten Ressourcen-Lokalisierer, die von einem Computersystem erzeugt worden ist, das den Client mit dem Netzwerk koppelt; Bereitstellen eines Ressourcen-Lokalisierers dem Netzwerk in Richtung des Computersystems, wobei der Ressourcen-Lokalisierer eine digitale Signatur aufweist, die repräsentativ für ein Recht ist, das dem Client von dem Ressourcen-Lokalisierungs-Server zum Zugreifen auf eine Ressource gewährt wird, die mittels des Ressourcen-Lokalisierers lokalisiert wird, wobei die digitale Signatur basierend auf zumindest einer eindeutigen Kenngröße des Computersystems oder der Verbindung des Computersystems zu dem Netzwerk und basierend auf einem Kennzeichner des Inhalts, auf den zugegriffen werden soll, berechnet wird.
Verfahren gemäß Anspruch 17, wobei der Schritt des Bereitstellens das Berechnen der digitalen Signatur als eine Funktion von einer Adresse des Client-Computersystems in dem Netzwerk aufweist.
Verfahren gemäß Anspruch 17, wobei der Schritt des Bereitstellens das Berechnen der digitalen Signatur als eine Funktion von einem eindeutigen Kennzeichner des Client-Computersystems aufweist.
Verfahren gemäß Anspruch 17, 18 oder 19, wobei der Schritt des Bereitstellens das Berechnen der digitalen Signatur als eine Funktion von einer Client-Identifikation aufweist.
Verfahren gemäß einem der Ansprüche 17 bis 20, wobei der Schritt des Bereitstellens das Berechnen der digitalen Signatur als eine Funktion von der Zeit aufweist.
Verfahren gemäß einem der Ansprüche 17 bis 20, wobei der Schritt des Bereitstellens das Berechnen der digitalen Signatur als eine Funktion von einem geheimen Schlüssel aufweist.
Verfahren gemäß einem der Ansprüche 17 bis 20, wobei der Schritt des Berechnens das Berechnen einer kryptographischen Hash-Funktion aufweist.
Verfahren gemäß einem der Ansprüche 17 bis 23, wobei der Schritt des Berechnens das Berechnen einer kryptographischen Hash-Funktion von einer Zeichenkette aufweist, die zumindest die Adresse des Client-Computersystems in dem Netzwerk, einen eindeutigen Kennzeichner des Client-Computersystems, eine Funktion der Ressource, eine Client-Identifikation und/oder einen Zeitwert aufweist.
Verfahren gemäß Anspruch 24, wobei die Zeichenkette ferner einen geheimen Schlüssel aufweist.
Verfahren gemäß Anspruch 25, ferner aufweisend einen Schritt des Erzeugens des geheimen Schlüssels unter Verwenden eines Generators kryptographischer Zahlen.
Verfahren gemäß Anspruch 25 oder 26, wobei die kryptographische Hash-Funktion eine schlüsselbasierte kryptographische Hash-Funktion ist.
Verfahren gemäß einem der Ansprüche 23 bis 27, wobei die kryptographische Hash-Funktion aus MDS, SHA-1, MD2, MD4, RIPEMD-128 und RIPEMD-160 ausgewählt ist.
Verfahren gemäß einem der Ansprüche 22 bis 28, wobei der geheime Schlüssel eine Funktion von einer Server-Adresse ist, die in dem Ressourcen-Lokalisierer enthalten ist.
Verfahren gemäß Anspruch 29, wobei der geheime Schlüssel eine kryptographische Hash-Funktion von einer Server-Adresse ist, die in dem Ressourcen-Lokalisierer enthalten ist.
Verfahren zum Bereitstellen eines Client-Zugriffs auf einen Inhalt auf einem Content-Provider-Server, der mit einem Netzwerk gekoppelt ist, aufweisend: Empfangen einer Zugriffs-Anforderung von dem Netzwerk, die von einem Computersystem erzeugt worden ist, das den Client mit dem Netzwerk koppelt, und die eine digitale Signatur enthält; Prüfen der digitalen Signatur, die in einem Ressourcen-Lokalisierer enthalten ist, gemäß zumindest einer eindeutigen Kenngröße des Computersystems oder der Verbindung des Computersystems zu dem Netzwerk, welche Kenngröße in der Anforderung empfangen worden ist, und gemäß einem Kennzeichner des Inhalts, der von dem Client angefordert wird; und Ermöglichen dem Client, auf den Inhalt gemäß dem Ergebnis dieses Prüfschrittes zuzugreifen.
Verfahren gemäß Anspruch 31, wobei der Schritt des Prüfens der digitalen Signatur das Berechnen einer anderen digitalen Signatur und das Vergleichen der anderen digitalen Signatur mit der digitalen Signatur aufweist, die in dem Ressourcen-Lokalisierer enthalten ist.
Verfahren gemäß Anspruch 32, wobei die Zugriffs-Anforderung eine Adresse des Client-Computersystems in dem Netzwerk aufweist, und wobei die andere digitale Signatur als eine Funktion von der Adresse berechnet wird.
Verfahren gemäß Anspruch 32, wobei die Zugriffs-Anforderung einen eindeutigen Kennzeichner des Client-Computersystems aufweist, und wobei die andere digitale Signatur als eine Funktion von dem eindeutigen Kennzeichner berechnet wird.
Verfahren gemäß einem der Ansprüche 32 bis 34, wobei die Zugriffs-Anforderung eine Client-Identifikation aufweist, und wobei die andere digitale Signatur als eine Funktion von der Client-Identifikation berechnet wird.
Verfahren gemäß einem der Ansprüche 32 bis 35, wobei die andere digitale Signatur als eine Funktion von der Zeit berechnet wird.
Verfahren gemäß einem der Ansprüche 32 bis 36, wobei der Server mit einem geheimen Schlüssel versehen ist, und wobei die andere digitale Signatur als eine Funktion von dem geheimen Schlüssel berechnet wird.
Verfahren gemäß einem der Ansprüche 32 bis 37, wobei der Schritt des Berechnens der anderen digitalen Signatur das Berechnen einer kryptographischen Hash-Funktion aufweist.
Verfahren gemäß einem der Ansprüche 32 bis 38, wobei der Schritt des Berechnens des anderen Schlüssels das Berechnen einer kryptographischen Hash-Funktion von einer Zeichenkette aufweist, die zumindest die Adresse des Client-Computersystems, die in der Anforderung enthalten ist, einen eindeutigen Kennzeichner des Client-Computersystems, der in der Anforderung enthalten ist, eine Funktion des Inhalts, auf den mittels des Clients zugegriffen werden soll, eine Client-Identifikation, die in der Anforderung enthalten ist, und/oder einen Zeitwert aufweist.
Verfahren gemäß Anspruch 38 oder 39, wobei die kryptographische Hash-Funktion aus MDS, SHA-1, MD2, MD4, RIPEMD-128 und RIPEMD-160 ausgewählt ist.
Ressourcen-Lokalisierungs-Server, aufweisend: eine Verbindung zu einem Netzwerk, ein Programm, das das Verfahren gemäß einem der Ansprüche 17 bis 30 durchführt.
Content-Provider-Server, aufweisend: eine Verbindung zu einem Netzwerk; ein Programm, das das Verfahren gemäß einem der Ansprüche 31 bis 40 durchführt.
Server gemäß Anspruch 42, wobei der Content-Provider-Server ein Content-Delivery-Netzwerk ist, das zumindest zwei Server aufweist.
Server gemäß Anspruch 43, wobei das Content-Delivery-Netzwerk eine Umleit-Einheit aufweist, wobei die Umleit-Einheit ein Programm aufweist, das das Verfahren gemäß einem der Ansprüche 17 bis 30 durchführt.
Server gemäß Anspruch 43, wobei das Content-Delivery-Netzwerk eine Umleit-Einheit aufweist, wobei die Umleit-Einheit ein Programm aufweist, das einen der Server des Content-Delivery-Netzwerkes auswählt und das Verfahren gemäß einem der Ansprüche 17 bis 30 durchführt.
Computerprogrammprodukt, das in einem computerlesbaren Medium ausgebildet ist, zum Bereitstellen eines Ressourcen-Lokalisierers auf einem Ressourcen-Lokalisierungs-Server einem Client, der mit einem Netzwerk gekoppelt ist, wobei das Computerprogrammprodukt aufweist: ein computerlesbares Programmcode-Mittel zum Anzeigen den Clients Ressourcen-Lokalisierer; ein computerlesbares Programmcode-Mittel zum Empfangen einer Zugriffs-Anforderung für einen der angezeigten Ressourcen-Lokalisierer von dem Netzwerk, welche Anforderung von einem Computersystem erzeugt worden ist, das den Client mit dem Netzwerk koppelt; ein computerlesbares Programmcode-Mittel zum Bereitstellen eines Ressourcen-Lokalisierers dem Netzwerk in Richtung des Computersystems, wobei der Ressourcen-Lokalisierer eine digitale Signatur aufweist, die repräsentativ für ein Recht ist, das dem Client von dem Ressourcen-Lokalisierungs-Server zum Zugreifen auf eine Ressource gewährt wird, die mittels des Ressourcen-Lokalisierers lokalisiert wird, wobei die digitale Signatur basierend auf zumindest einer eindeutigen Kenngröße des Computersystems oder der Verbindung des Computersystems zu dem Netzwerk und basierend auf einem Kennzeichner der Ressource berechnet wird.
Computerprogrammprodukt, das in einem computerlesbaren Medium ausgebildet ist, zum Bereitstellen eines Zugriffs auf einen Inhalt auf einem Content-Provider-Server, der mit einem Netzwerk gekoppelt ist, einem Client, wobei das Computerprogrammprodukt aufweist: ein computerlesbares Programmcode-Mittel zum Empfangen einer Zugriffs-Anforderung von dem Netzwerk, die von einem Computersystem erzeugt worden ist, das den Client mit dem Netzwerk koppelt, und die eine digitale Signatur enthält; ein computerlesbares Programmcode-Mittel zum Prüfen der digitalen Signatur, die in einem Ressourcen-Lokalisierer enthalten ist, gemäß zumindest einer eindeutigen Kenngröße des Computersystems oder der Verbindung des Computersystems zu dem Netzwerk, welche Kenngröße in der Anforderung empfangen worden ist, und gemäß einem Kennzeichner des Inhalts, der von dem Client angefordert wird; und ein computerlesbares Programmcode-Mittel zum Ermöglichen dem Client, auf den Inhalt gemäß dem Ergebnis dieses Prüfschrittes zuzugreifen.