Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR DIGITAL RIGHTS MANAGEMENT IN A COMPUTER NETWORK HAVING A PLURALITY OF SUBSCRIBER COMPUTERS
Document Type and Number:
WIPO Patent Application WO/2011/029678
Kind Code:
A1
Abstract:
The invention relates to a method for digital rights management in a computer network having a plurality of subscriber computers (C1, C2). In the method according to the invention, a first subscriber computer (C1) provides a data object (CO) and a rights object (RO) to a second subscriber computer (C2), wherein the rights object (RO) establishes the access of the second subscriber computer (C2) to the data object (CO) and is encrypted using a first cryptographic key (puk) of a pair of the first and a second cryptographic keys (puk, prk). According to the invention, the rights object (RO) is decrypted based on secure communication between a program module (SM) running on the second subscriber computer (C2) and a security token (ST) connected to the second subscriber computer (C2), wherein the decryption is carried out using the second cryptographic key (prk), which is saved on the security token (ST). Finally, access by the second subscriber computer (C2) to the data object (CO) is carried out based on the decrypted rights object (RO).

Inventors:
MAIDL MONIKA (DE)
SCHAFHEUTLE MARCUS (DE)
SELTZSAM STEFAN (DE)
Application Number:
PCT/EP2010/061581
Publication Date:
March 17, 2011
Filing Date:
August 10, 2010
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SIEMENS AG (DE)
MAIDL MONIKA (DE)
SCHAFHEUTLE MARCUS (DE)
SELTZSAM STEFAN (DE)
International Classes:
G06F21/10
Domestic Patent References:
WO2008008244A22008-01-17
WO2003005174A12003-01-16
Foreign References:
US20060116969A12006-06-01
US6898708B22005-05-24
Other References:
None
Attorney, Agent or Firm:
SIEMENS AKTIENGESELLSCHAFT (DE)
Download PDF:
Claims:
Patentansprüche

1. Verfahren zur digitalen Rechteverwaltung in einem Computernetz mit einer Vielzahl von Teilnehmerrechnern (Cl, C2), bei dem:

ein erster Teilnehmerrechner (Cl) einem zweiten Teilnehmerrechner (C2) ein Datenobjekt (CO) und ein Rechteob¬ jekt (RO) bereitstellt, wobei das Rechteobjekt (RO) den Zugriff des zweiten Teilnehmerrechners (C2) auf das Da- tenobjekt (CO) festlegt und mit einem ersten kryp- tographischen Schlüssel (puk) eines Paars aus dem ersten und einem zweiten kryptographischen Schlüssel (puk, prk) verschlüsselt ist;

basierend auf einer gesicherten Kommunikation zwischen einem auf dem zweiten Teilnehmerrechner (C2) laufenden

Programm-Modul (SM) und einem mit dem zweiten Teilnehmerrechner (C2) verbundenen Sicherheits-Token (ST) das Rechteobjekt (RO) entschlüsselt wird, wobei die Ent¬ schlüsselung mit dem zweiten kryptographischen Schlüssel (prk) erfolgt, der auf dem Sicherheits-Token (ST) gespeichert ist;

basierend auf dem entschlüsselten Rechteobjekt (RO) der Zugriff des zweiten Teilnehmerrechners (C2) auf das Da¬ tenobjekt (CO) erfolgt.

2. Verfahren nach Anspruch 1, bei dem die Entschlüsselung des Rechteobjekts (RO) derart erfolgt, dass das Programm-Modul (SM) das verschlüsselte Rechteobjekt (RO) basierend auf der gesicherten Kommunikation an den Sicherheits-Token (ST) sen- det, der anschließend das Rechteobjekt (RO) mit dem zweiten kryptographischen Schlüssel (prk) entschlüsselt und über die gesicherte Kommunikation an das Programm-Modul (SM) übermit¬ telt . 3. Verfahren nach Anspruch 1 oder 2, bei dem der erste kryp- tographische Schlüssel (puk) der öffentliche Schlüssel (puk) und der zweite kryptographische Schlüssel (prk) der private Schlüssel eines asymmetrischen Schlüsselpaars ist.

4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Programm-Modul (SM) ein gegen Angriffe geschütztes Pro¬ gramm-Modul ist.

5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Sicherheits-Token (ST) gegen Verwendung durch einen Benutzer, der unberechtigt im Besitz des Sicherheits-Tokens (ST) ist, geschützt ist, insbesondere durch ein Kennwort und/oder biometrische Daten.

6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der erste Teilnehmerrechner (Cl) das Rechteobjekt (RO) und/oder das Datenobjekt (CO) direkt bereitstellt, indem er das Rechteobjekt (RO) und/oder das Datenobjekt (CO) an den zweiten Teilnehmerrechner (C2) übermittelt.

7. Verfahren nach Anspruch 6, bei dem der erste Teilnehmerrechner (Cl) das Rechteobjekt (RO) als separate Datei und/oder als Bestandteil des Datenobjekts (CO) an den zweiten Teilnehmerrechner (C2) übermittelt.

8. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der erste Teilnehmerrechner (Cl) das Rechteobjekt (RO) und/oder das Datenobjekt über einen zwischengeschalteten Rechte-Verwaltungs-Server bereitstellt .

9. Verfahren nach Anspruch 8, bei dem sich der zweite Teilnehmerrechner (C2) zum Empfang des Rechteobjekts (RO) und/oder des Datenobjekts (CO) am Rechte-Verwaltungs-Server authentisieren muss.

10. Verfahren nach Anspruch 9, bei dem die Authentisierung mit Hilfe des auf dem Sicherheits-Token (ST) gespeicherten zweiten kryptographischen Schlüssels (prk) und/oder mit einem Passwort erfolgt.

11. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das durch den ersten Teilnehmerrechner (Cl) bereitgestellte Datenobjekt (CO) mit einem dritten kryptographischen Schlüssel (cek) verschlüsselt ist, der in dem Rechteobjekt (RO) enthalten ist, wobei nach der Entschlüsselung des Rechteobjekts (RO) das Datenobjekt (CO) mit dem dritten kryp¬ tographischen Schlüssel (cek) durch das Programm-Modul (SM) entschlüsselt wird. 12. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der zweite Teilnehmerrechner (C2) auf das Datenobjekt (CO) mittels einer auf dem zweiten Teilnehmerrechner (C2) laufenden Applikation (AP) zugreift, wobei die Applikation vorzugsweise gegen Angriffe geschützt ist.

13. Verfahren nach Anspruch 12, bei dem die Applikation (AP) eine separat vom Programm-Modul (SM) laufende Applikation (AP) ist oder das Programm-Modul (SM) Teil der Applikation (AP) ist

14. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Programm-Modul (SM) und/oder die Applikation (AP) ohne Installation auf dem zweiten Teilnehmerrechner (C2) laufen .

15. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Gültigkeit des Rechteobjekts (RO) zeitlich begrenzt ist . 16. Verfahren nach Anspruch 15, bei dem die zeitliche Gültig¬ keit des Rechteobjekts (RO) mit einer Uhr überprüft wird, welche auf dem Sicherheits-Token (ST) läuft.

17. Verfahren nach Anspruch 15 oder 16 in Kombination mit ei- nem der Ansprüche 8 bis 10, bei dem die Gültigkeit des Rech¬ teobjekts (RO) mit einer Uhr überprüft wird, welche auf dem Rechte-Verwaltungs-Server läuft.

18. System zur digitalen Rechteverwaltung in einem Computernetz mit einer Vielzahl von Teilnehmerrechnern (Cl, C2), wobei das System einen ersten Teilnehmerrechner (Cl) und einen zweiten Teilnehmerrechner (C2) sowie einen Sicherheits-Token (ST) umfasst, welche im Betrieb derart wechselwirken, dass: der erste Teilnehmerrechner (Cl) dem zweiten Teilnehmerrechner (C2) ein Datenobjekt (CO) und ein Rechteobjekt (RO) bereitstellt, wobei das Rechteobjekt (RO) den

Zugriff des zweiten Teilnehmerrechners (C2) auf das Da¬ tenobjekt (CO) festlegt und mit einem ersten kryp- tographischen Schlüssel (puk) eines Paars aus dem ersten und einem zweiten kryptographischen Schlüssel (puk, prk) verschlüsselt ist;

basierend auf einer gesicherten Kommunikation zwischen einem auf dem zweiten Teilnehmerrechner (C2) laufenden Programm-Modul (SM) und dem mit dem zweiten Teilnehmerrechner (C2) verbundenen Sicherheits-Token (ST) das Rechteobjekt (RO) entschlüsselt wird, wobei die Ent¬ schlüsselung mit dem zweiten kryptographischen Schlüssel (prk) erfolgt, der auf dem Sicherheits-Token (ST) gespeichert ist;

basierend auf dem entschlüsselten Rechteobjekt (RO) der Zugriff des zweiten Teilnehmerrechners (C2) auf das Da¬ tenobjekt (CO) erfolgt.

19. System nach Anspruch 18, welches derart ausgestaltet ist, mit dem System ein Verfahren nach einem der Ansprüche 1 bis 17 Durchführbar ist.

20. Rechner zur Verwendung in einem System nach Anspruch 18 oder 19, wobei der Rechner derart ausgestaltet ist, dass er im Betrieb des Systems als zweiter Teilnehmerrechner (C2) fungiert, wobei basierend auf einer gesicherten Kommunikation zwischen einem auf dem Rechner (C2) laufenden Programm-Modul

(SM) und einem mit dem Rechner (C2) verbundenen Sicherheits- Token (ST) ein Rechteobjekt (RO) , welches einem Datenobjekt

(CO) zugeordnet ist, mit einem auf dem Sicherheits-Token (ST) gespeicherten kryptographischen Schlüssel (prk) entschlüsselt wird und wobei basierend auf dem entschlüsselten Rechteobjekt (RO) der Zugriff des Rechners (C2) auf das Datenobjekt (CO) erfolgt .

Description:
Beschreibung

Verfahren zur digitalen Rechteverwaltung in einem Computernetz mit einer Vielzahl von Teilnehmerrechnern

Die Erfindung betrifft ein Verfahren und ein System zur digitalen Rechteverwaltung in einem Computernetz mit einer Vielzahl von Teilnehmerrechner. Heutzutage werden in Computernetzen mit einer Vielzahl von

Teilnehmerrechnern oftmals gleichzeitig die gleichen Datenob ¬ jekte von mehreren Benutzern der verschiedenen Teilnehmerrechner bearbeitet. Um den Zugriff auf Datenobjekte durch mehrere Teilnehmerrechner geeignet festzulegen, sind aus dem Stand der Technik sog. DRM- bzw. ERM-Systeme zur digitalen Rechteverwaltung bekannt (DRM = Digital Rights Management; ERM = Enterprise Rights Management) . Bei diesen Systemen sind auf den einzelnen Teilnehmerrechnern entsprechende Clients installiert, welche mit einem zentralen Rechte-Verwaltungs- Server kommunizieren. Dabei können die einzelnen Clients Datenobjekte sowie entsprechende Rechteobjekte bereitstellen, wobei die Rechteobjekte festlegen, wie andere Clients in dem Datennetz die Datenobjekte nutzen dürfen. Die Rechte sind auf dem zentralen Rechte-Verwaltungs-Server hinterlegt, und mit Hilfe von kryptographischen Schlüsseln werden den entsprechenden Teilnehmerrechnern sowohl die Datenobjekte als auch die entsprechenden Rechteobjekte bereitgestellt. Die auf den Teilnehmerrechnern laufenden Clients ermöglichen dabei eine Entschlüsselung der Datenobjekte und der Rechteobjekte und stellen sicher, dass auf das Datenobjekt die für den entspre ¬ chenden Teilnehmerrechner spezifizierten Zugriffsrechte angewandt werden. Diese Zugriffsrechte betreffen insbesondere den Lese- und Schreibzugriff und auch beliebige andere Zugriffs ¬ möglichkeiten, beispielsweise das Recht, ein entsprechendes Dokument zu drucken.

Herkömmliche digitale Rechteverwaltungs-Verfahren weisen den Nachteil auf, dass sie eine Installation entsprechender Client-Software auf den einzelnen Teilnehmerrechnern im Computernetz erfordern und dass ferner ein zentraler Server zum Verwalten der Rechte bereitgestellt werden muss. Somit ist es insbesondere schwierig, neu hinzukommenden Teilnehmerrech- nern, welche beispielsweise nur temporär Zugriff auf Datenob ¬ jekte haben sollen, entsprechende Zugriffsmöglichkeiten zu erteilen bzw. deren Zugriffsmöglichkeiten zu regulieren, denn hierzu ist eine Installation eines Clients auf dem entspre ¬ chenden Teilnehmerrechner zur Kommunikation mit dem Rechte- Verwaltungs-Server erforderlich.

Aus dem Stand der Technik sind neben digitalen Rechte-Verwaltungs-Systemen auch andere Technologien zum Schutz von digitalen Dateninhalten bekannt. Insbesondere gibt es sog. Si- cherheits-Token, welche oft auch als Security-Token bzw.

Hardware-Dongles bezeichnet werden. Solche Token verhindern z.B. die Verwendung von unlizenzierter Software. Dabei erhält nur der Lizenznehmer der Software den Sicherheits-Token und kann die Software nur in Kombination mit dem Sicherheits- Token ausführen. Der Sicherheits-Token enthält entsprechende geheime Schlüssel, welche zur Ausführung der Software benö ¬ tigt werden.

Aus dem Stand der Technik ist ferner allgemein der Schutz von Daten durch Verschlüsselung auf entsprechenden Datenträgern, wie DVDs oder USB-Sticks bekannt. Ein autorisierter Nutzer kann dabei die Daten in geeigneter Weise entschlüsseln und anschließend ohne Einschränkung verwenden. Zum Schutz von Software sind ferner sog. Verschleierungs- Technologien bekannt, welche auch als Code Obfuscation bezeichnet werden. Dabei wird der Softwarecode durch Verschlei ¬ erung der Semantik des Source-Codes gegen Angreifer geschützt, welche versuchen, aus dem Objektcode der Software den ursprünglichen Source-Code abzuleiten.

Aufgabe der Erfindung ist es, ein Verfahren und System zur digitalen Rechteverwaltung in einem Computernetz mit einer Vielzahl von Teilnehmerrechnern zu schaffen, mit denen einfach und flexibel ein Zugriff auf Datenobjekte unter Berück ¬ sichtigung spezifizierter digitaler Rechte ermöglicht wird. Diese Aufgabe wird durch die unabhängigen Patentansprüche ge ¬ löst. Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen definiert.

In dem erfindungsgemäßen Verfahren stellt ein erster Teilneh- merrechner einem zweiten Teilnehmerrechner ein Datenobjekt und ein Rechteobjekt bereit, wobei das Rechteobjekt den

Zugriff des zweiten Teilnehmerrechners auf das Datenobjekt festlegt und mit einem ersten kryptographischen Schlüssel eines Paars aus dem ersten und einem zweiten kryptographischen Schlüssel verschlüsselt ist. Basierend auf einer gesicherten Kommunikation zwischen einem auf dem zweiten Teilnehmerrechner laufenden Programm-Modul und einem mit dem zweiten Teilnehmerrechner verbundenen Sicherheits-Token wird das Rechteobjekt entschlüsselt, wobei die Entschlüsselung mit dem zwei- ten kryptographischen Schlüssel erfolgt, der auf dem Sicherheits-Token gespeichert ist. Erfindungsgemäß erfolgt schließlich basierend auf dem entschlüsselten Rechteobjekt der Zugriff des zweiten Teilnehmerrechners auf das Datenob ¬ jekt.

Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass eine einfache, gegen Angriffe von Dritten geschützte Rechteverwaltung mit Hilfe eines Sicherheits-Tokens und einer darauf basierenden gesicherten Kommunikation mit einem Pro- gramm-Modul ermöglicht wird. Dabei wird die Rechteverwaltung eines Teilnehmers durch die Bereitstellung des entsprechenden Sicherheits-Tokens erreicht, der an dem Teilnehmerrechner angeschlossen wird und hierdurch Zugriff auf Datenobjekte und die entsprechend vergebenen Zugriffsrechte ermöglicht. Zur Realisierung der Erfindung kann auf bekannte Technologien zurückgegriffen werden, insbesondere kann ein herkömmlicher, aus dem Stand der Technik bekannter Sicherheits-Token mit geeigneten Mechanismen zum Schutz des darauf gespeicherten zweiten kryptographischen Schlüssels verwendet werden. Die kryptographisch gesicherte Kommunikation zwischen dem Programm-Modul und dem Sicherheits-Token kann auch mit bekannten Technologien zur Datenverschlüsselung realisiert werden.

In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens erfolgt die Entschlüsselung des Rechteobjekts der ¬ art, dass das Programm-Modul das verschlüsselte Rechteobjekt basierend auf der gesicherten Kommunikation, d.h. auf einer aufgebauten gesicherten Kommunikationsverbindung, an den Sicherheits-Token sendet, der anschließend das Rechteobjekt mit dem zweiten kryptographischen Schlüssel entschlüsselt und über die gesicherte Kommunikation an das Programm-Modul über ¬ mittelt. Auf diese Weise wird die Entschlüsselung in einer besonders gut gegen Angriffe geschützten Umgebung auf dem Si ¬ cherheits-Token erreicht.

In einer weiteren, besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens erfolgt die Verschlüsselung bzw. Entschlüsselung des Rechteobjekts basierend auf einem asym ¬ metrischen Schlüsselpaar, wobei der erste kryptographische Schlüssel der öffentliche Schlüssel und der zweite kryp ¬ tographische Schlüssel der private Schlüssel des Schlüssel ¬ paars ist. Diese Ausführungsform hat den Vorteil, dass kein besonderer Schutz zur Geheimhaltung des ersten kryptographischen Schlüssels bereitgestellt werden muss.

In einer besonders bevorzugten Ausführungsform ist das im erfindungsgemäßen Verfahren verwendete Programm-Modul gegen An- griffe von Dritten geschützt. Dabei können beliebige, aus dem Stand der Technik bekannte Mechanismen zum Schutz des Programm-Moduls verwendet sein, beispielsweise können die oben beschriebenen Code-Verschleierungs-Technologien eingesetzt werden oder es können beim Ausführen des Programm-Moduls be- stimmte Programmteile auf den Sicherheits-Token ausgelagert werden. Auf diese Weise wird die Sicherheit der digitalen Rechteverwaltung weiter erhöht. In einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens ist der Sicherheits-Token nochmals separat gegen die Verwendung durch einen Benutzer geschützt, der unberechtigt im Besitz des Sicherheits-Tokens ist. Dies geschieht insbesondere durch ein entsprechendes, dem berech ¬ tigten Benutzer bereitgestelltes Kennwort und gegebenenfalls auch durch biometrische Daten des Benutzers, beispielsweise in der Form eines Fingerabdrucks, der zur Authentisierung über ein entsprechendes Lesegerät eingelesen wird. Nur bei Übereinstimmung des Kennworts bzw. der biometrischen Daten mit entsprechenden, auf dem Token hinterlegten Daten wird die Benutzung des Tokens zugelassen.

Die Bereitstellung des Rechteobjekts bzw. des Datenobjekts erfolgt in einer Variante der Erfindung direkt, indem der erste Teilnehmerrechner das Rechteobjekt und/oder Datenobjekt an den zweiten Teilnehmerrechner übermittelt. Dabei kann der erste Teilnehmerrechner das Rechteobjekt als separate Datei und/oder als Bestandteil des Datenobjekts an den zweiten Teilnehmerrechner übermitteln. Gegebenenfalls besteht auch die Möglichkeit, dass der erste Teilnehmerrechner das Rechte ¬ objekt und/oder das Datenobjekt über einen zwischengeschalte ¬ ten Rechte-Verwaltungs-Server bereitstellt, so dass eine zentrale Daten- und/oder Rechteverwaltung ermöglicht wird. Gegebenenfalls ist ein entsprechender Mechanismus vorgesehen, mit dem sich der zweite Teilnehmerrechner zum Empfang des Rechteobjekts bzw. des Datenobjekts am Rechte-Verwaltungs- Server authentisieren muss. Diese Authentisierung kann beispielsweise mit Hilfe des auf dem Sicherheits-Token gespei- cherten zweiten kryptographischen Schlüssels und/oder mit einem Passwort erfolgen.

In einer besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens ist das durch den ersten Teilnehmer- rechner bereitgestellte Datenobjekt mit einem dritten kryp ¬ tographischen Schlüssel verschlüsselt, der in dem Rechteob ¬ jekt enthalten ist, wobei nach der Entschlüsselung des Rechteobjekts das Datenobjekt mit dem dritten kryptographischen Schlüssel durch das Programm-Modul entschlüsselt wird. Auf diese Weise wird die Sicherheit des Verfahrens bezüglich ei ¬ nes unbefugten Zugriffs auf die Datenobjekte erhöht. In einer weiteren Variante des erfindungsgemäßen Verfahrens greift der zweite Teilnehmerrechner auf das Datenobjekt mit ¬ tels einer auf dem zweiten Teilnehmerrechner laufenden Applikation zu, wobei die Applikation vorzugsweise gegen Angriffe von unbefugten Dritten in geeigneter Weise geschützt ist, insbesondere wiederum mit Verfahren, welche auch zu dem

Schutz des Programm-Moduls eingesetzt werden können. Die Ap ¬ plikation kann dabei eine separat vom Programm laufende Applikation sein. Es ist jedoch auch möglich, dass das Programm-Modul ein Teil der Applikation ist.

In einer besonders bevorzugten Ausführungsform ist das Programm-Modul und/oder die Applikation derart ausgestaltet, dass sie ohne Installation auf dem zweiten Teilnehmerrechner laufen können, beispielsweise indem die Applikation bzw. das Programm-Modul direkt von einem tragbaren Datenträger, wie z.B. einer CD, DVD oder einem USB-Stick, durch den zweiten Teilnehmerrechner gestartet werden. Auf diese Weise wird eine besonders einfache Umsetzung des erfindungsgemäßen Verfahrens erreicht, bei der noch nicht einmal Software auf dem zweiten Teilnehmerrechner installiert werden muss.

In einer weiteren Variante des erfindungsgemäßen Verfahrens ist die Gültigkeit des Rechteobjekts zeitlich begrenzt, wobei diese Information in dem Rechteobjekt hinterlegt ist. Die zeitliche Gültigkeit des Rechteobjekts wird dabei vorzugswei ¬ se durch eine Uhr überprüft, welche auf dem Sicherheits-Token läuft. Hierdurch kann auf einfache Weise eine fälschungssi ¬ chere Uhr realisiert werden, so dass ein guter Schutz gegen Manipulationen der Zugriffsrechte in Bezug auf deren Gültig- keit sichergestellt ist. In der Variante der Erfindung, in der ein Rechte-Verwaltungs-Server verwendet wird, kann ein Schutz gegen Manipulationen bezüglich der zeitlichen Begrenzung von Zugriffsrechten auch dadurch erreicht werden, dass eine Uhr verwendet wird, welche auf dem Rechte-Verwaltungs- Server läuft. Eine solche Uhr ist schwieriger zu manipulieren als eine Uhr auf dem zweiten Teilnehmerrechner, auf den ein Benutzer leichter Zugriff hat.

Neben dem oben beschriebenen Verfahren betrifft die Erfindung ferner ein System zur digitalen Rechteverwaltung in einem Computernetz mit einer Vielzahl von Teilnehmerrechnern, wobei das System einen ersten Teilnehmerrechner, einen zweiten Teilnehmerrechner sowie einen Sicherheits-Token umfasst, welche derart miteinander wechselwirken, dass sie im Betrieb das erfindungsgemäße Verfahren ausführen können.

Darüber hinaus umfasst die Erfindung einen Rechner zur Ver- wendung in dem erfindungsgemäßen System, wobei der Rechner derart ausgestaltet ist, dass er im Betrieb des Systems als zweiter Teilnehmerrechner fungiert. Dabei wird basierend auf einer gesicherten Kommunikation zwischen einem auf dem Rechner laufenden Programm-Modul und einem mit dem Rechner ver- bundenen Sicherheits-Token ein Rechteobjekt, welches einem Datenobjekt zugeordnet ist, mit einem auf dem Sicherheits- Token gespeicherten kryptographischen Schlüssel entschlüsselt, und der Zugriff des zweiten Rechners auf das Datenob ¬ jekt erfolgt basierend auf dem entschlüsselten Rechteobjekt.

Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Figuren detailliert beschrieben.

Es zeigen:

Fig. 1 eine schematische Darstellung einer digitalen Rechteverwaltung gemäß dem Stand der Technik; und

Fig. 2 eine schematische Darstellung einer digitalen Rech- teverwaltung basierend auf einer Ausführungsform des erfindungsgemäßen Verfahrens. Fig. 1 zeigt in schematischer Darstellung eine digitale Rechteverwaltung basierend auf der bereits eingangs erwähnten ERM-Infrastruktur gemäß dem Stand der Technik. Diese Struktur ist in einem Computernetzwerk mit einer Vielzahl von ERM- Clients integriert, welche mit einem digitalen Rechte- Verwaltungs-Server in der Form eines ERM-Servers S kommunizieren. Gemäß Fig. 1 ist dabei neben dem ERM-Server ein erster ERM-Client Cl vorgesehen, der ein Datenobjekt CO anderen Clients unter Berücksichtigung vorbestimmter Zugriffsrechte für spezifische Benutzer bzw. Benutzergruppen bereitstellen möchte. Um einen solchen benutzerspezifischen Zugriff auf das Datenobjekt CO zu ermöglichen, verschlüsselt der Client Cl das Datenobjekt mit einem kryptographischen Schlüssel cek und spezifiziert die entsprechenden Zugriffsrechte RI für dieses Datenobjekt in einem Rechteobjekt RO, welches auch den

Schlüssel cek enthält, mit dem das Datenobjekt CO verschlüs ¬ selt ist. Auch dieses Rechteobjekt RO ist verschlüsselt, und zwar mit einem dem Server S zugeordneten öffentlichen Schlüssel pus . Das Rechteobjekt kann dabei mit einem entsprechen- den, im Server hinterlegten privaten Schlüssel prs entschlüsselt werden. Es wird somit ein verschlüsseltes Datenobjekt CO:cek sowie ein verschlüsseltes Rechteobjekt RO:pus=[RI, cek] :pus erzeugt. Das Rechteobjekt RO wird häufig auch als Herausgeber-Lizenz IL (IL = Issuance Licence) bezeichnet und enthält die Rechte der entsprechenden Empfänger (d.h. der individuellen Benutzer bzw. Benutzergruppen). Die Rechte können sich beispielsweise darauf beziehen, ob ein Benutzer dazu berechtigt ist, die Da- tei abzuspeichern bzw. auszudrucken. Wie bereits erwähnt, ist in diesem Rechteobjekt neben den Rechten RI auch der Schlüssel cek enthalten, mit dem das verschlüsselte Datenobjekt CO entschlüsselbar ist. Der Schlüssel cek ist dabei ein symmet ¬ rischer Schlüssel und somit eine geheime Information, weshalb die Herausgeber-Lizenz IL auch mit dem Schlüssel pus des ERM- Servers S verschlüsselt ist. Ferner wird die Herausgeber- Lizenz auch durch den Herausgeber signiert. Der Client Cl sendet das verschlüsselte Datenobjekt CO: cek sowie das ver- schlüsselte Rechenobjekt RO:pus an den ERM-Server S, über den diese Objekte dann anderen Clients bereitgestellt werden. Durch die zentrale Speicherung der Rechteobjekte auf dem ERM- Server wird es ermöglicht, dass diese Rechte zu jedem belie- bigen Zeitpunkt geändert werden können, z.B. wenn ein Benutzer ein Projekt verlässt oder wenn Dokumente durch neuere Versionen ersetzt werden. In dem ERM-Server wird dabei jeder Zugriff auf ERM-geschützte Dokumente und jede Aktion proto ¬ kolliert. Der ERM-Server ermöglicht somit eine feingranulare Zugangskontrolle zu digitalen Inhalten.

In dem Szenario der Fig. 1 ist der weitere ERM-Client C2 ein Empfänger für das Datenobjekt CO, d.h. der Client hat vorbe ¬ stimmte Zugriffsrechte auf das Datenobjekt CO, welche in dem Rechteobjekt RO festgelegt sind. Zum Zugriff auf das Datenob ¬ jekt CO kommuniziert der ERM-Client C2 mit dem ERM-Server S. Zunächst empfängt der ERM-Client C2 das mit dem Schlüssel cek verschlüsselte Datenobjekt CO:cek. Der Client C2 kann dieses Objekt zunächst nicht entschlüsseln, da ihm der Schlüssel cek nicht zur Verfügung steht. Hierfür benötigt er das Rechteob ¬ jekt RO, welches häufig auch als Endbenutzer-Lizenz EUL (EUL = End User Licence) bezeichnet wird. Zum Empfang dieser End ¬ nutzer-Lizenz muss sich der entsprechende Benutzer über den Client C2 zunächst am ERM-Server S authentisieren, was in Fig. 1 durch den Schritt AUT angedeutet ist. Anschließend ge ¬ neriert der ERM-Server die Endnutzer-Lizenz. Hierfür wird das verschlüsselte, vom Client Cl empfangene Rechteobjekt RO:pus zunächst mit dem privaten Schlüssel prs des ERM-Servers S entschlüsselt und anschließend wiederum verschlüsselt, und zwar diesmal mit einem öffentlichen Schüssel puk, wobei mit diesem öffentlichen Schlüssel verschlüsselte Objekte mit ei ¬ nem entsprechenden privaten Schlüssel prk des ERM-Clients C2 entschlüsselt werden können. Die derart generierte Endnutzer- Lizenz RO:puk=[RI, cek]:puk wird nach erfolgreicher Authenti- sierung an den ERM-Client C2 übermittelt. Nach Empfang der

Lizenz kann diese schließlich vom Client C2 mit dessen privatem Schlüssel prk entschlüsselt werden, so dass der Client C2 dann Zugriff auf die spezifizierten Rechte RI sowie den Schlüssel cek hat, mit dem das Datenobjekt CO verschlüsselt ist .

Der ERM-Client C2 wechselwirkt mit einer entsprechenden Ap- plikation, welche den digitalen Dateninhalt des Datenobjekts CO verarbeiten kann. Insbesondere erhält die Applikation das verschlüsselte Datenobjekt CO, welches es mit dem Schlüssel cek entschlüsselt. Darüber hinaus werden durch die Applikati ¬ on die für den Client C2 spezifizierten Rechte berücksich- tigt, so dass über die Applikation nur der gemäß den Rechten spezifizierte Zugriff auf das Datenobjekt ermöglicht wird. Der ERM-Client C2 muss dabei selbst vor Angriffen durch sei ¬ nen Benutzer geschützt werden, der unter Umständen versuchen möchte, den Client zu modifizieren, um ungeschützten Zugriff auf das digitale Datenobjekt zu erhalten. Im Besonderen muss der ERM-Client den privaten Schlüssel prk, mit dem das Rechteobjekt entschlüsselt werden kann, vor dem Benutzer geheim halten . Die digitale Rechteverwaltung gemäß der ERM-Struktur der Fig. 1 weist einige Nachteile auf. Insbesondere müssen auf jeden Rechner, der an der digitalen Rechteverwaltung beteiligt ist, entsprechende ERM-Clients installiert werden, welche dann an den speziellen Rechner bzw. einen speziellen Nutzer gekoppelt sind. Darüber hinaus ist für die ERM-Struktur eine Identi ¬ täts-Verwaltung auf Seiten des Servers erforderlich, so dass sich alle potentiellen Empfänger von digitalen Dateninhalten am ERM-Server authentisieren können. Es müssen somit Benutzerkonten für alle potentiellen Benutzer verwaltet werden. Häufig erfolgt die Verwaltung dieser Konten über ein bestimmtes Verzeichnis, insbesondere eine sog. Active Directory, wo ¬ bei sich die Benutzer mit entsprechenden Passwörtern authentisieren müssen. Die Verwaltung dieser Benutzerkonten und der entsprechenden Passwörter ist komplex und zeitaufwändig . Dar- über hinaus ist es erforderlich, dass immer ein Online-Zugang zu dem ERM-Server sichergestellt ist, damit sich ein Benutzer bei diesem authentisieren kann. Das ERM-System gemäß Fig. 1 ist somit aufwändig und erfordert die Installation eines ERM- Clients auf jedem Rechner, der an der digitalen Rechte-Verwaltung beteiligt ist. Darüber hinaus wird eine entsprechende Infrastruktur zur Verwaltung von Benutzerkonten und Passwörtern benötigt. Dies ist insbesondere von Nachteil, wenn in einem Unternehmen mit einer internen ERM-Struktur auch externen Nutzern aus einem anderen Unternehmen, wie z.B. Zulieferern oder potentiellen Kunden oder Beratern, Zugriff auf digitale Dateninhalte im Rahmen entsprechender Projekte gegeben werden soll. Dies erfordert nämlich die aufwändige Integrati- on des externen Nutzers in die ERM-Infrastruktur des Unternehmens, d.h. es muss ein entsprechender ERM-Client beim ex ¬ ternen Nutzer sowie ein entsprechendes Benutzerkonto beim ERM-Server installiert werden. Dieser Aufwand ist bei externen Nutzern oftmals nicht gerechtfertigt, insbesondere wenn solchen Nutzern nur temporär Zugriff auf digitale Dateninhalte gegeben werden soll.

Im Folgenden wird eine Ausführungsform des erfindungsgemäßen Verfahrens beschrieben, mit dem die oben genannten Nachteile einer ERM-Struktur im Wesentlichen beseitigt werden. Diese Ausführungsform ist schematisch in Fig. 2 dargestellt. Zur Implementierung einer digitalen Rechteverwaltung wird dabei keine aufwändige ERM-Infrastruktur in der Form eines ERM- Servers mit Identitäts-Verwaltung sowie entsprechenden ERM- Clients benötigt. Stattdessen wird eine Kombination aus einem Sicherheits-Token und einer Applikation verwendet. Im Folgenden wird der Sicherheits-Token auch mit dem gängigen englischen Begriff Security-Token bezeichnet und kann beispielsweise als USB-Token ausgestaltet sein. Die Umsetzung der Er- findung wird wiederum basierend auf der Kommunikation zwischen zwei Clients Cl und C2 beschrieben, wobei die Clients nunmehr nicht mehr Clients im eigentlichen Sinne sind, denn sie müssen nicht zwangsläufig mit einem Server kommunizieren. Vielmehr stellen die Clients allgemein Teilnehmerrechner im Sinne von Anspruch 1 dar. Der Begriff „Client" ist somit im Folgenden weit auszulegen und gleichzusetzen mit einem entsprechenden Teilnehmerrechner. In dem Verfahren gemäß Fig. 2 wird durch den Client Cl analog zum Verfahren der Fig. 1 ein Datenobjekt CO basierend auf ei ¬ ner entsprechenden Rechteverwaltung einem anderen Client C2 bereitgestellt, der den Empfänger des Datenobjekts darstellt. Zur Realisierung einer digitalen Rechteverwaltung wird auf dem Empfänger C2 ein Softwarepaket SP hinterlegt, welches ei ¬ ne entsprechende Applikation AP sowie ein Sicherheits-Modul SM enthält, welches eine Ausführungsform eines Programm- Moduls im Sinne von Patentanspruch 1 darstellt. Die Applika- tion AP ist dabei notwendig, um das digitale Datenobjekt CO zu verarbeiten und kann beispielsweise eine Betrachtungssoft ¬ ware für ein spezielles Datenformat umfassen. In einer bevorzugten Variante ist die Software der Applikation und des Si ¬ cherheits-Moduls dabei derart ausgestaltet, dass sie ohne In- stallation auf dem Teilnehmerrechner C2 laufen kann, beispielsweise kann es sich um Software handeln, die auf USB- Sticks gemäß dem an sich bekannten U3-Standard läuft.

Die Applikation AP ist derart angepasst, dass sie mit dem Si- cherheits-Modul SM kommunizieren kann. Das Sicherheits-Modul SM verarbeitet die entsprechenden, dem Empfänger C2 zugeordneten Rechte für das bereitgestellte digitale Datenobjekt CO. Dabei sind das Sicherheits-Modul und die Applikation sowie deren Kommunikation untereinander in geeigneter Weise gegen unautorisierten Zugriff geschützt. Zum Schutz können aus dem Stand der Technik bekannte Mechanismen verwendet werden. Insbesondere kann die Applikation, das Sicherheits-Modul und de ¬ ren Kommunikation gegen eine Modifikation geschützt werden, beispielsweise mittels der eingangs erwähnten Code Obfuscati- on . Das auf dem Teilnehmerrechner C2 hinterlegte Softwarepa ¬ ket SP kann dem Nutzer auf CD bzw. DVD, über einen entsprechenden Download aus dem Internet oder auf beliebige andere Weise bereitgestellt werden. Ein weiteres, wesentliches Element des erfindungsgemäßen Ver ¬ fahrens ist der Einsatz des Security-Tokens ST, der den ent ¬ sprechenden privaten Schlüssel prk enthält, mit dem ein verschlüsseltes Rechteobjekt RO entschlüsselt werden kann, wie weiter unten noch näher erläutert wird. Durch die Verwendung des Security-Tokens , der beispielsweise als USB-Stick ausge ¬ staltet sein kann, werden effiziente Mechanismen bereitge ¬ stellt, mit denen der private Schlüssel prk vor Angreifern geschützt wird. Security-Tokens zum Schutz von darauf gespei ¬ cherten Daten sind hinlänglich aus dem Stand der Technik bekannt. Im erfindungsgemäßen Verfahren wird ein solcher an sich bekannter Security-Token über eine entsprechende

Schnittstelle (z.B. USB) mit dem Teilnehmerrechner C2 verbun- den und kommuniziert über eine geeignet geschützte kryp- tographische Kommunikation mit dem Sicherheits-Modul SM, wo ¬ bei eine entsprechende kryptographische Sicherung der Kommu ¬ nikation zwischen einem Security-Token und einem entsprechenden Programm-Modul auch an sich bekannt ist. Erfindungsgemäß wird die gesicherte Kommunikation zusammen mit einer entspre ¬ chenden Entschlüsselungs-Software auf dem Security-Token zur sicheren Entschlüsselung eines Rechteobjekts RO eingesetzt.

In der in Fig. 2 gezeigten Ausführungsform des erfindungsge- mäßen Verfahrens verschlüsselt der Teilnehmer Cl zunächst das dem Teilnehmer C2 bereitzustellende Datenobjekt CO mit dem symmetrischen Schlüssel cek. Ferner wird ein entsprechendes Rechteobjekt RO generiert, welches analog zum Verfahren der Fig. 1 die für das Datenobjekt CO spezifizierten Zugriffs- rechte RI sowie den Schlüssel cek enthält. Dieses Rechteob ¬ jekt wird mit dem öffentlichen Schlüssel puk verschlüsselt, wobei dieser öffentliche Schlüssel dem auf dem Security-Token ST gespeicherten privaten Schlüssel zugeordnet ist. Das heißt, mit Hilfe des privaten Schlüssels prk kann das mit dem Schlüssel puk verschlüsselte Rechteobjekt RO entschlüsselt werden. Das Rechteobjekt RO ist dabei zum Schutz gegen Modi ¬ fikationen ferner signiert. Im Client Cl ist somit sowohl der Schlüssel cek zum Verschlüsseln des Datenobjekts CO als auch der Schlüssel puk zum Verschlüsseln des Rechteobjekts RO hin- terlegt. Das verschlüsselte Datenobjekt CO:cek sowie das ver ¬ schlüsselte Rechteobjekt RO:puk werden in der Ausführungsform der Fig. 2 von dem Client Cl an das Sicherheits-Modul SM des Clients C2 übermittelt, was durch den Pfeil PI angedeutet ist. Es besteht dabei die Möglichkeit, dass das Rechteobjekt als Teil des Datenobjekts übersendet wird oder als separate Datei an das Sicherheits-Modul SM übergeben wird. Das Sicherheits-Modul SM entschlüsselt dann zunächst das ver ¬ schlüsselte Rechteobjekt basierend auf einer gesicherten Kom ¬ munikation mit dem Security-Token ST. Diese gesicherte Kommunikation wird in Fig. 2 durch die Pfeile P2 und P3 angedeu ¬ tet. Dabei wird das verschlüsselte Rechteobjekt RO:puk an den Security-Token ST übermittelt, auf dem dann durch entsprechende Software mit Hilfe des Schlüssels prk die Entschlüsse ¬ lung des Rechteobjekts erfolgt. Über die gesicherte Kommuni ¬ kationsverbindung wird anschließend das entschlüsselte Rech ¬ teobjekt RO an das Sicherheits-Modul SM zurückgegeben.

Schließlich wird im Sicherheits-Modul SM das Datenobjekt CO mit Hilfe des Schlüssels cek entschlüsselt, der nunmehr dem Sicherheits-Modul vorliegt, da dieses Modul das unverschlüs ¬ selte Rechteobjekt RO erhalten hat. Das Datenobjekt CO wird dann der Applikation AP übergeben, was durch den Pfeil P4 an- gedeutet ist. Ferner werden durch die Applikation die entsprechend spezifizierten Zugriffsrechte RI des Rechteobjekts verarbeitet, wie durch den Pfeil P5 in Fig. 2 angedeutet ist. Basierend auf der Applikation kann dann ein Zugriff auf das Datenobjekt in Abhängigkeit von den festgelegten Rechten RI erfolgen.

Das soeben beschriebene Verfahren zur digitalen Rechteverwaltung kann gegebenenfalls auch derart abgewandelt werden, dass der Client Cl das Rechteobjekt RO nicht direkt bereit- stellt, sondern unter Zwischenschaltung eines ERM-Servers, auf dem das Rechteobjekt RO verschlüsselt hinterlegt ist. Dieser ERM-Server wird dabei durch eine eindeutige Identifi ¬ kation des an das Sicherheits-Modul SM übermittelten Datenob ¬ jekts CO, insbesondere durch den Namen des Datenobjekts, re- ferenziert. Gemäß dieser Lösung holt sich der Client C2 bei jeder neuen Sitzung zur Verarbeitung des entsprechenden Datenobjekts CO das Rechteobjekt RO vom ERM-Server. Auf diese Weise wird es ermöglicht, dass die Zugriffsrechte jederzeit im ERM-Server geeignet verändert bzw. angepasst werden kön ¬ nen. Dies ist bei der Lösung, bei der das Rechteobjekt direkt von dem Client Cl an den Client C2 übermittelt wird, nicht gegeben. Die Lösung unter Zwischenschaltung des ERM-Servers hat jedoch den Nachteil, dass sie aufwändiger ist, da sie wiederum die Bereitstellung eines entsprechenden Servers erfordert .

Im Folgenden werden nochmals die wesentlichen Eigenschaften der im Verfahren der Fig. 2 verwendeten Komponenten zusammen- gefasst. Die Applikation AP wird zur Verarbeitung der digitalen Datenobjekte, wie z.B. Textformate, graphische Formate, 3D-Inhalte und dergleichen, verwendet und hat die Aufgabe, die entsprechenden Rechte-Restriktionen, welche von dem be- reitstellenden Client Cl festgelegt sind, durchzusetzen. Bei ¬ spielsweise kann der Empfänger C2 nicht das Recht haben, das empfangene Datenobjekt auszudrucken bzw. zu verändern. Um das Rechteobjekt RO mit den darin spezifizierten Rechten RI zu erhalten und das Datenobjekt CO zu verarbeiten, muss die Ap- plikation AP mit dem Sicherheits-Modul SM wechselwirken. Die Applikation AP kann dabei eine separate Applikation sein, gegebenenfalls kann sie jedoch auch in einer bereits instal ¬ lierten Anwendung integriert sein, beispielsweise in ein herkömmliches, auf dem Client C2 laufendes Textverarbeitungspro- gramm. Die Applikation AP braucht ferner nicht unbedingt auf dem Client C2 installiert sein, sondern sie kann gegebenenfalls auch von einem externen Datenträger aus, beispielweise von einer DVD oder einem USB-Stick, laufen. Um einen hohen Schutz gegen unbefugten Zugriff auf das Datenobjekt CO bzw. das Rechteobjekt RO zu erreichen, wird zwischen dem Si ¬ cherheits-Modul SM und dem Security-Token ST eine geeignet geschützte kryptographische Kommunikation aufgebaut, über welche die Entschlüsselung des Rechteobjekts erfolgt. Ferner sind die Applikation AP und das Sicherheits-Modul SM und de- ren Kommunikation untereinander auch gegen Modifikation geschützt . Der Security-Token ST zeichnet sich dadurch aus, dass er entsprechende Schutzmechanismen für den darauf gespeicherten privaten Schlüssel prk bereitstellt, so dass ein Angreifer keinen Zugriff auf diesen Schlüssel hat. Insbesondere gibt es dabei keine Schnittstellenfunktion, um den privaten Schlüssel aus dem Security-Token ST auszulesen. Der Security-Token ist ferner fälschungssicher, d.h. er ist mit geeigneten, an sich bekannten Verfahren gegen Side-Channel-Angriffe bzw. physika ¬ lische Angriffe geschützt. Es können dabei an sich bekannte Security-Token aus dem Stand der Technik verwendet werden. Diese enthalten in der Regel einen entsprechenden Sicherheits-Chip, der die oben beschriebenen Schutzmechanismen bereitstellt. Insbesondere muss der digitale Speicher des Secu- rity-Tokens ST auch gegen ein unbefugtes Kopieren geschützt sein und gegen eine Emulation des Verhaltens des Security-

Tokens. Ansonsten hätte ein Angreifer die Möglichkeit, einen funktionalen Klon des Security-Tokens zu generieren und mit dessen Verwendung die Kopier-Restriktion bezüglich des digitalen Inhalts des Security-Tokens ST zu umgehen.

In einer besonders bevorzugten Ausführungsform kann der Security-Token ferner gegen die Verwendung eines Benutzers, der sich den Token unbefugt angeeignet hat, geschützt werden. Dies kann dadurch erfolgen, dass der Security-Token einen Zugriffsschutz durch ein Passwort hat, welches beispielsweise mit dem privaten Schlüssel prk auf dem Security-Token über eine XOR-Verbindung verknüpft ist, so dass bei Eingabe des richtigen Passworts der private Schlüssel prk erhalten werden kann. Gegebenenfalls besteht auch die Möglichkeit, dass der Schutz des Security-Tokens gegen eine unbefugte Verwendung über biometrische Daten erfolgt, welche z.B. durch einen ge ¬ eigneten Fingerabdruck-Leser am Teilnehmerrechner C2 eingelesen werden. In einer Variante der Erfindung besteht die Möglichkeit, die Zugriffsrechte RI zeitlich zu begrenzen. Im Falle, dass die Rechteobjekte unter Zwischenschaltung eines ERM-Servers be ¬ reitgestellt werden, sollte bei der Überprüfung der zeitli- chen Begrenzung der Zugriffsrechte die Zeit gemäß der Uhr des Teilnehmerrechners C2 mit der Zeit gemäß der Uhr des ERM- Servers verglichen werden. Sofern sich die Zeiten unterscheiden, sollte die Uhr des Servers als Grundlage zur Überprüfung der zeitlichen Dauer der Zugriffsrechte verwendet werden, da diese Uhr schwieriger durch einen Angriff zu manipulieren ist als die Uhr eines Clients. Sofern das Rechteobjekt direkt über den Client bereitgestellt wird, sollte nicht die Uhr auf dem Client zur Gültigkeitsprüfung verwendet werden, sondern es ist zu bevorzugen, dass hierzu eine fälschungssichere Echtzeit-Uhr auf dem Security-Token eingesetzt wird.

Mit den im Vorangegangenen beschriebenen Ausführungsformen des erfindungsgemäßen Verfahrens werden wesentliche Funktio- nen eines herkömmlichen ERM-Clients durch einen Security- Token übernommen. Dieser Token stellt Mechanismen zur Sicherung des darauf gespeicherten privaten Schlüssels zur Verfügung. Er hat gegenüber einem ERM-Client den Vorteil, dass er bedarfsweise mit einem entsprechenden Teilnehmerrechner ver- bunden werden kann und hierdurch eine digitale Rechteverwal ¬ tung für den Teilnehmer ermöglicht. Es kann dabei auf eine Installation eines ERM-Clients verzichtet werden, und in spe ¬ ziellen Ausführungsformen des erfindungsgemäßen Verfahrens ist es auch nicht notwendig, einen ERM-Server bereitzustel- len. Durch die Verwendung der Merkmale von Security-Tokens kann somit auf einfache Weise eine sichere ERM-Infrastruktur ohne installierte Clients bzw. Server erreicht werden.

In speziellen Ausführungsformen des erfindungsgemäßen Verfah- rens besteht auch die Möglichkeit, dass ein Rechte-Verwal ¬ tungs-Server in der Form eines ERM-Servers eingesetzt wird. Hierdurch kann beispielsweise die Möglichkeit geschaffen wer ¬ den, dass die am Verfahren beteiligten Teilnehmerrechner bzw. der Security-Token dahingehend überprüft werden, ob sie mög- licherweise auf Blacklists stehen, welche entsprechende Kom ¬ ponenten enthalten, von denen bekannt ist, dass sie gefälscht sind. Ebenso können Daten protokolliert werden und die

Zugriffsrechte können bei Bedarf verändert werden. Bei der Verwendung eines ERM-Servers kann in geeigneter Weise auch eine Authentisierung des Clients gegenüber dem Server erreicht werden. Dies kann beispielsweise durch den geheimen privaten Schlüssel auf dem Security-Token ermöglicht werden, z.B. mit einem Challenge-Response-Verfahren . Gegebenenfalls kann die Authentisierung auch über ein Passwort erfolgen, das dem entsprechenden Benutzer zugewiesen ist und von ihm zur Authentisierung eingegeben werden muss. In diesem Fall werden Benutzerkonten verwaltet und ein Benutzer hat sich vor dem Zugriff auf ein entsprechendes Datenobjekt bei dem ERM-Server mit einem Passwort zu authentisieren . Gegebenenfalls kann auch eine Kombination aus einer Authentisierung mit dem geheimen privaten Schlüssel auf den Security-Token und einem Passwort realisiert sein.

Das erfindungsgemäße Verfahren kann beispielsweise durch die Abwandlung von kommerzieller Software realisiert werden. Beispielsweise kann für die verwendete Applikation, welche mit dem Sicherheits-Modul kommuniziert, ein herkömmlicher ERM- Client geeignet abgewandelt werden, um mit dem Sicherheits- Modul zu kommunizieren. Herkömmliche ERM-Clients sind dabei bereits in geeigneter Weise gegen Angriffe von Dritten, insbesondere durch Hacking und Debugging, geschützt. Ebenso kann ein herkömmlicher Security-Token eingesetzt werden, auf dem entsprechende Schutzmechanismen gegen unautorisierte Modifi ¬ kation vorgesehen sind, z.B. basierend auf zumindest teilwei ¬ se verschlüsseltem Softwarecode oder basierend auf Code Ob- fuscation .