DE102015001817B4

DE102015001817B4 - Verfahren, Vorrichtungen und System zur Online-Datensicherung

Info

Publication number: DE102015001817B4
Application number: DE102015001817.5A
Authority: DE
Inventors: Volker Stöhr; Jens Hohmann; Josef Bauer; Frank-Michael Kamm
Original assignee: Giesecke Devrient Mobile Security Germany GmbH; Giesecke and Devrient Mobile Security GmbH
Current assignee: Giesecke+devrient Mobile Security Germany De GmbH
Priority date: 2015-02-13
Filing date: 2015-02-13
Publication date: 2024-03-21
Anticipated expiration: 2035-02-14
Also published as: DE102015001817A1

Abstract

Verfahren zum Zugreifen von einem Endgerät (UD-B-k) eines zweiten Unternehmens (B) auf ein elektronisches Dokument, das von einem Endgerät (UD-A-i) eines ersten Unternehmens (A) in einem Dokumentencontainer auf einem Cloudspeicherdienst (50) gespeichert worden ist, wobei der Dokumentencontainer das mit einem Dokumentenschlüssel Ksecverschlüsselte Dokument und den mit einem öffentlichen Schlüssel Kssa_pubeiner Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssel Ksecenthält; umfassend die Schritte:das Übertragen des Dokumentencontainers an das Endgerät (UD-B-k) des zweiten Unternehmens (B),das Weiterleiten des mit dem öffentlichen Schlüssel Kssa_pubder Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssels Ksecan die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A); indem entwedera) das Endgerät (UD-B-k) des zweiten Unternehmens (B) den mit dem öffentlichen Schlüssel Kssa_pubder Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssel Ksecdirekt an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) weiterleitet; undeine Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) den Status des Endgeräts (UD-B-k) des zweiten Unternehmens (B) und den öffentlichen Schlüssel Kusr_bk_pubdes Endgeräts (UD-B-k) des zweiten Unternehmens (B) an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) überträgt, oderb) das Endgerät (UD-B-k) des zweiten Unternehmens (B) den mit dem öffentlichen Schlüssel Kssa_pubder Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssel Ksecan eine Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) weiterleitet;die Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) den Status des Endgeräts (UD-B-k) des zweiten Unternehmens (B) prüft und im Fall einer erfolgreichen Prüfung den öffentlichen Schlüssel Kusr_bk_pubdes Endgeräts (UD-B-k) des zweiten Unternehmens (B) an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) überträgt;das Übertragen eines öffentlichen Schlüssels Kusr_bk_pubdes Endgeräts (UD-B-k) des zweiten Unternehmens (B) an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A);das Entschlüsseln des mit dem öffentlichen Schlüssel Kssa_pubder Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssels Ksecdurch die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A);das Verschlüsseln des Dokumentenschlüssels Ksecmit dem öffentlichen Schlüssel Kusr_bk_pubdes Endgeräts (UD-B-k) des zweiten Unternehmens (B);das Übertragen des mit dem öffentlichen Schlüssel Kusr_bk_pubdes Endgeräts (UD-B-k) des zweiten Unternehmens (B) verschlüsselten Dokumentenschlüssel Ksecan das Endgerät (UD-B-k) des zweiten Unternehmens (B);das Entschlüsseln des mit dem öffentlichen Schlüssel Kusr_bk_pubdes Endgeräts (UD-B-k) des zweiten Unternehmens (B) verschlüsselten Dokumentenschlüssels Ksecmit einem privaten Schlüssel Kusr_bk_prvdes Endgeräts (UD-B-k) des zweiten Unternehmens (B); unddas Entschlüsseln des im Dokumentencontainer enthaltenen verschlüsselten Dokuments mit dem entschlüsselten Dokumentenschlüssel Ksec.

Description

Gebiet der Erfindung
Die Erfindung betrifft Verfahren, Vorrichtungen und ein System zur Online-Datensicherung über ein Kommunikationsnetzwerk. Insbesondere betrifft die Erfindung Verfahren, Vorrichtungen und ein System zur Online-Datensicherung über das Internet.
Hintergrund der Erfindung
Im Internet bzw. World Wide Web gibt es eine Vielzahl von Webdiensten, welche die Online-Datensicherung sowie die Synchronisation von Daten zwischen verschiedenen Computern und Personen ermöglichen. Der Zugriff auf derartige sogenannte Cloudspeicherdienste, wie beispielsweise Dropbox, SkyDrive, Google Drive, erfolgt in der Regel mittels eines Webbrowsers oder einer Applikation auf einem Computer.
Bei herkömmlichen Cloudspeicherdiensten können jedoch verschiedene Sicherheitsprobleme auftreten. Falls die Daten unverschlüsselt gespeichert werden, sind diese für manche Anwendungsfälle gegen ein unbefugtes Auslesen nicht ausreichend geschützt. Verschlüsselt ein Benutzer eines Cloudspeicherdienstes seine Daten mit einem persönlichen Schlüssel, dann kann er diese Daten nicht mit anderen Benutzern teilen, was dieses Vorgehen für Unternehmenszwecke ausschließt. Dies gilt ebenso für Zero-Knowledge-Protokolle, bei denen aus einem Benutzerpasswort ein Schlüssel abgeleitet wird. Die Verteilung eines solchen Benutzerpassworts an eine größere Gruppe von Benutzern würde zu erheblichen Sicherheitsrisiken führen. Werden die bei einem Cloudspeicherdienst hinterlegten Daten mit einem gemeinsamen Schlüssel verschlüsselt, d.h. mit einem Schlüssel, den mehrere Benutzer kennen, dann ist es nicht möglich, bestimmten Benutzern flexibel den Zugriff auf bestimmte Daten zu gewähren oder zu verwehren. Werden die Daten mit mehreren persönlichen Schlüsseln verschlüsselt und dann bei einem Cloudspeicherdienst abgelegt, dann ist es zwar möglich, bestimmten Benutzern flexibel den Zugriff auf bestimmte Daten zu gewähren. Soll allerdings nachträglich einzelnen Benutzern der Zugriff erteilt oder entzogen werden, so erfordert dies eine Änderung der Daten im Cloudspeicherdienst. Insbesondere wenn bestimmten Benutzern der Zugriff sicher entzogen werden soll, ist dazu ein sicheres Löschen von im Cloudspeicherdienst gespeicherten Daten (incl. aller Kopien) notwendig, was sich in der Praxis kaum realisieren lässt.
Bei den vorstehend genannten Varianten, bei denen die Daten auf einem Server des Cloudspeicherdienstes verschlüsselt gespeichert werden, befinden sich die Schlüssel bei den Benutzern. Damit bei Verlust eines Schlüssels nicht der Zugriff auf die verschlüsselten Daten unmöglich wird, müssen Sicherungskopien dieser Schlüssel angelegt werden, was wiederum ein Sicherheitsrisiko darstellt.
Bei Cloudspeicherdiensten, die von sich aus eine Verschlüsselung der Daten anbieten, besteht in der Regel das Problem, dass auch der Cloudspeicherdienst Zugriff auf die entsprechenden Schlüssel und damit die verschlüsselten Daten hat.
Zur Behebung der vorstehend beschriebenen Nachteile schlägt die Anmeldung PCT/ EP2014/003035 ein Verfahren und Vorrichtungen sowie ein System zur Online-Datensicherung über ein Kommunikationsnetzwerk vor, die es ermöglichen, herkömmliche Cloudspeicherdienste zur Online-Datensicherung sicher nutzen zu können, indem die Kontrolle der Schlüssel zur Verschlüsselung der Daten vollständig durch den Benutzer in Verbindung mit einer vertrauenswürdigen Instanz erfolgt.
Das von der Anmeldung PCT/ EP2014/ 003035 vorgeschlagene Cloud Key Management (CKM) System und die zugehörigen Verfahren sind allerdings für den Einsatz durch eine geschlossene Benutzergruppe konzipiert. Insbesondere kann es sich bei dem CKM System um ein durch ein Unternehmen betriebenes System handeln, die Anwender sind in diesem Fall die Mitarbeiter dieses Unternehmens. Mehrere Unternehmen können jeweils ihre eigenen CKM Systeme betreiben. Diese sind dann allerdings voneinander unabhängig.
Wenn zwei oder mehr Unternehmen zusammenarbeiten, beispielsweise als Auftragnehmer und Kunde oder als Technologiepartner, müssen in der Regel auch vertrauliche Daten ausgetauscht werden, wie etwa Projektpläne, technische Dokumentationen oder dergleichen. Hat jedes der beteiligten Unternehmen ein eigenes CKM System, so müssen die unternehmensübergreifenden Daten in allen CKM Systemen parallel gespeichert werden. Da die CKM Systeme der PCT/ EP2014/003035 aber keinen Datenabgleich zwischen verschiedenen Systemen zulassen, muss der Datentransfer mit anderen Mitteln in Verantwortung der Mitarbeiter erfolgen. Somit haben die CKM Systeme keine Kontrolle, dass der Datentransfer mit sicheren Verfahren durchgeführt wird. Darüber hinaus ist der Datentransfer wegen des Medienbruchs für die Mitarbeiter umständlich, und es besteht die Gefahr inkonsistenter Datenstände auf den unterschiedlichen CKM Systemen.
Alternativ müssen die betroffenen Mitarbeiter des einen Unternehmens auf dem CKM System eines anderen Unternehmens als Benutzer angelegt werden. Dies verursacht einen nicht unerheblichen Verwaltungsaufwand, da insbesondere eine sichere Identifikation und ein sicherer Austausch von Schlüsseln oder Zertifikaten erfolgen muss. Auch muss sichergestellt werden, dass ein Mitarbeiter, der ein Unternehmen verlässt, auf allen CKM Systemen als Benutzer wieder ausgetragen wird. Da sich Kooperationsstrukturen zwischen den Unternehmen häufig ändern können und teilweise überlappen, entstünde eine Komplexität, die in der Praxis nicht mehr handhabbar ist.
Gemäß einer weiteren Möglichkeit können die beteiligten Unternehmen ihre Daten auf einem gemeinsamen CKM System verwalten, welches von einem unabhängigen vertrauenswürdigen Dienstleister betrieben wird. Da ein Unternehmen üblicherweise Beziehungen zu vielen anderen Unternehmen unterhält, oft auch international, läuft dies letztendlich auf einen weltweit einzigen Betreiber für ein CKM System hinaus, dem alle vertrauen. Die Unternehmen würden somit die Kontrolle über ihre Daten vollständig abgeben, so dass dieser Ansatz in der Praxis nicht realistisch ist.
Vor diesem Hintergrund stellt sich der vorliegenden Erfindung die Aufgabe, verbesserte Verfahren und Vorrichtungen sowie ein verbessertes System zur Online-Datensicherung über ein Kommunikationsnetzwerk bereitzustellen, mit denen die vorstehend beschriebenen Nachteile behoben werden. Insbesondere soll es die vorliegende Erfindung ermöglichen, herkömmliche Cloudspeicherdienste zur Online-Datensicherung in einer Weise sicher nutzen zu können, dass mehrere unterschiedliche Unternehmen jeweils eigene CKM System betreiben, an denen jeweils nur die eigenen Mitarbeiter als Benutzer registriert sind und dass zwei oder mehr solcher CKM Systeme so gekoppelt werden, dass Benutzer eines CKM Systems Zugriff auf bestimmte Dokumente erhalten können, die auf einem anderen CKM System verwaltet werden.
Das Dokument DE602004012019T2 aus dem Stand der Technik offenbart ein Verfahren, das von einer vertrauenswürdigen Partei durchgeführt wird, um das sichere Übergeben von Daten von einem Urheber zu einem Empfänger zu erleichtern. Die Daten sind mit einem ersten Schlüssel verschlüsselt. Ein Entschlüsselungsschlüssel wird an den Empfänger geliefert, um es dem Empfänger zu ermöglichen, die verschlüsselten Daten zu entschlüsseln. Von dem Urheber wird eine durch den Urheber ausgewählte Bedingung empfangen, die der Empfänger erfüllen muss. der Empfänger empfängt einen Nachweis, dass die Bedingung erfüllt wurde. Der Nachweises wird mit der Bedingung verglichen, um zu bestätigen, dass der Empfänger die Bedingung erfüllt. Der Entschlüsselungsschlüssel wird an den Empfänger nur dann geliefert, wenn der Empfänger die Bedingung erfüllt. Der erste Schlüssel wird dabei ohne Bezug zu der Bedingung erzeugt.
Das Dokument Fugkeaw, S., Achieving Privacy and Security in Multi-Owner Data Outsourcing. Seventh International Conference on Digital Information Management (ICDIM), 22.-24.08.2012, IEEE 2012, Seiten 239-244, aus dem Stand der Technik offenbart ein Verfahren, bei dem sich in einem Datenumfeld, in dem mehrere Eigentümer von Daten beteiligt sind, Schutz und Sicherheit erzielbar sind.
Zusammenfassung der Erfindung
Die vorstehende Aufgabe wird gemäß der vorliegenden Erfindung durch den jeweiligen Gegenstand der unabhängigen Ansprüche gelöst. Bevorzugte Ausgestaltungen der Erfindung werden in den abhängigen Ansprüchen definiert.
Zunächst sei kurz das Verfahren zur Speicherung eines elektronischen Dokuments, das auf einem Endgerät eines ersten Unternehmens A vorliegt, auf einem Cloudspeicherdienst beschrieben. Ein derartiges Verfahren umfasst die folgenden Schritte: das Erzeugen eines Dokumentenschlüssels K_sec auf dem Endgerät des ersten Unternehmens A; das Verschlüsseln des elektronischen Dokuments mit dem Dokumentenschlüssel K_sec und das Verschlüsseln des Dokumentenschlüssels K_sec mit einem öffentlichen Schlüssel K_{ssa_pub} einer Sicherheitsinstanz des ersten Unternehmens A; das Übertragen eines Dokumentencontainers an den Cloudspeicherdienst, wobei der Dokumentencontainer das mit dem Dokumentenschlüssel K_sec verschlüsselte Dokument und den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssel K_sec enthält; und das Abspeichern des Dokumentencontainers im Cloudspeicherdienst. Das verschlüsselte Dokument kann dabei wahlweise mit einer Signatur abgesichert sein (Details siehe weiter unten).
Der Begriff „Unternehmen“ umfasst im Rahmen der vorliegenden Beschreibung auch Behörden und andere Organisationen, denen jeweils eine geschlossene Benutzergruppe, beispielsweise die Mitarbeiter des Unternehmens, angehört. Es versteht sich, dass die beteiligten Unternehmen, insbesondere das erste und zweite Unternehmen unterschiedliche Unternehmen mit unterschiedlichen geschlossenen Benutzergruppen sind.
Gemäß eines ersten Aspekts der Erfindung wird ein Verfahren zum Zugreifen von einem Endgerät eines zweiten Unternehmens B auf ein elektronisches Dokument, das von einem Endgerät eines ersten Unternehmens A in einem Dokumentencontainer auf einem Cloudspeicherdienst gespeichert worden ist, bereitgestellt, wobei der Dokumentencontainer das mit einem Dokumentenschlüssel K_sec verschlüsselte Dokument und den mit einem öffentlichen Schlüssel K_{ssa_pub} einer Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssel K_sec enthält. Dabei umfasst das Verfahren die folgenden Schritte: das Übertragen des Dokumentencontainers an das Endgerät des zweiten Unternehmens B, das Weiterleiten des mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssels K_sec an die Sicherheitsinstanz des ersten Unternehmens A; das Übertragen eines öffentlichen Schlüssels K_{usr_bk_pub} des Endgeräts des zweiten Unternehmens B an die Sicherheitsinstanz des ersten Unternehmens A; das Entschlüsseln des mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssels K_sec durch die Sicherheitsinstanz des ersten Unternehmens A mit dem privaten Schlüssel K_{ssa_prv}; das Verschlüsseln des Dokumentenschlüssels K_sec mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts des zweiten Unternehmens B; das Übertragen des mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts des zweiten Unternehmens B verschlüsselten Dokumentenschlüssel K_sec an das Endgerät des zweiten Unternehmens B; das Entschlüsseln des mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts des zweiten Unternehmens B verschlüsselten Dokumentenschlüssels K_sec mit einem privaten Schlüssel K_{usr_bk_prv} des Endgeräts des zweiten Unternehmens B; und das Entschlüsseln des im Dokumentencontainer enthaltenen verschlüsselten Dokuments mit dem entschlüsselten Dokumentenschlüssel K_sec.
Vorzugsweise enthält der Dokumentencontainer ferner eine mit einem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz des ersten Unternehmens A erzeugte Signatur des verschlüsselten Dokumentenschlüssels K_sec, und das Verfahren umfasst die folgenden weiteren Schritte: das Übertragen des öffentlichen Schlüssels K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A an das Endgerät des zweiten Unternehmens B; und das Verifizieren der Signatur des verschlüsselten Dokumentenschlüssels K_sec mit dem öffentlichen Schlüssels K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A durch das Endgerät des zweiten Unternehmens B.
In einer vorteilhaften Verfahrensvariante, die nachfolgend auch als „direkte Variante“ bezeichnet wird, ist vorgesehen, dass das Endgerät des zweiten Unternehmens B den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssel K_sec direkt an die Sicherheitsinstanz des ersten Unternehmens A weiterleitet; dass die Sicherheitsinstanz des ersten Unternehmens A bei einer Sicherheitsinstanz des zweiten Unternehmens B den Status des Endgeräts des zweiten Unternehmens B anfordert; und dass die Sicherheitsinstanz des zweiten Unternehmens B den angeforderten Status des Endgeräts des zweiten Unternehmens B und den öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts des zweiten Unternehmens B an die Sicherheitsinstanz des ersten Unternehmens A überträgt.
Der Status des Endgeräts besteht dabei insbesondere in der Information, dass dieses Endgerät nicht gesperrt ist, d.h. dass das Endgerät beispielsweise nicht als gestohlen oder verloren gemeldet wurde.
In einer anderen, ebenfalls vorteilhaften Verfahrensvariante, die nachfolgend auch als „indirekte Variante“ bezeichnet wird, ist vorgesehen, dass das Endgerät des zweiten Unternehmens B den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssels K_sec an eine Sicherheitsinstanz des zweiten Unternehmens B weiterleitet; und dass die Sicherheitsinstanz des zweiten Unternehmens B den Status des Endgeräts des zweiten Unternehmens B prüft und im Fall einer erfolgreichen Prüfung den öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts des zweiten Unternehmens B zusammen mit dem verschlüsselten Dokumentenschlüssel K_sec an die Sicherheitsinstanz des ersten Unternehmens A überträgt.
Gemäß einem anderen Aspekt der Erfindung wird ein Verfahren zum Abspeichern eines auf einem Endgerät eines zweiten Unternehmens B modifizierten elektronischen Dokuments, das von einem Endgerät eines ersten Unternehmens A in einem Dokumentencontainer auf einem Cloudspeicherdienst gespeichert worden ist, bereitgestellt, wobei der Dokumentencontainer das mit einem Dokumentenschlüssel K_sec verschlüsselte Dokument und den mit einem öffentlichen Schlüssel K_{ssa_pub} einer Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssel K_sec enthält. Dabei umfasst das Verfahren die folgenden Schritte: das Erzeugen eines neuen Dokumentenschlüssels K_sec auf dem Endgerät des zweiten Unternehmens B; das Verschlüsseln des modifizierten elektronischen Dokuments mit dem neuen Dokumentenschlüssel K_sec und das Verschlüsseln des neuen Dokumentenschlüssels K_sec mit einem öffentlichen Schlüssel K_{ssa_pub} einer Sicherheitsinstanz des ersten Unternehmens A; das Weiterleiten des mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssels K_sec an die Sicherheitsinstanz des ersten Unternehmens A; optional, erfolgt zudem bedarfsweise das Entschlüsseln des mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssels K_sec durch die Sicherheitsinstanz des ersten Unternehmens A (die Entschlüsselung wird ggf. für die Überprüfung eines ggf. mitverschlüsselten Hashwerts über die Dokumentenkennung gebraucht.); das Erzeugen einer Signatur des verschlüsselten Dokumentenschlüssels K_sec mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz des ersten Unternehmens A; das Übertragen der mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz des ersten Unternehmens A erzeugten Signatur an das Endgerät des zweiten Unternehmens B; und das Übertragen eines neuen Dokumentencontainers an den Cloudspeicherdienst, wobei der neue Dokumentencontainer das mit dem neuen Dokumentenschlüssel K_sec verschlüsselte modifizierte Dokument, den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten neuen Dokumentenschlüssel K_sec und die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz des ersten Unternehmens A erzeugten Signatur enthält; und das Abspeichern des neuen Dokumentencontainers im Cloudspeicherdienst.
In einer vorteilhaften Verfahrensvariante, die nachfolgend auch als „direkte Variante“ bezeichnet wird, ist dabei vorgesehen, dass das Endgerät des zweiten Unternehmens B den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssels K_sec direkt an die Sicherheitsinstanz des ersten Unternehmens A weiterleitet; dass die Sicherheitsinstanz des ersten Unternehmens A bei einer Sicherheitsinstanz des zweiten Unternehmens B den Status des Endgeräts des zweiten Unternehmens B anfordert; dass die Sicherheitsinstanz des zweiten Unternehmens B den angeforderten Status des Endgeräts des zweiten Unternehmens B an die Sicherheitsinstanz des ersten Unternehmens A überträgt; und dass die Sicherheitsinstanz des ersten Unternehmens A im Fall eines aktiven Status des Endgeräts des zweiten Unternehmens B die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz des ersten Unternehmens A erzeugte Signatur direkt an das Endgerät des zweiten Unternehmens B weiterleitet.
Besonders bevorzugt ist dabei insbesondere vorgesehen, dass das Endgerät des zweiten Unternehmens B den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssels K_sec zusammen mit einer mit dem privaten Schlüssel K_{usr_bk_prv} des Endgeräts des zweiten Unternehmens B erstellten Signatur des verschlüsselten Dokumentenschlüssels K_sec direkt an die Sicherheitsinstanz des ersten Unternehmens A weiterleitet; dass eine Sicherheitsinstanz des zweiten Unternehmens B den Status des Endgeräts des zweiten Unternehmens B und den öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts des zweiten Unternehmens B an die Sicherheitsinstanz des ersten Unternehmens A überträgt; dass die Sicherheitsinstanz des ersten Unternehmens A die von dem Endgerät des zweiten Unternehmens B übermittelte Signatur des verschlüsselten Dokumentenschlüssels K_sec mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts des zweiten Unternehmens B verifiziert; und dass die Sicherheitsinstanz des ersten Unternehmens A im Fall einer erfolgreichen Verifikation die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz des ersten Unternehmens A erzeugte Signatur direkt an das Endgerät des zweiten Unternehmens B weiterleitet.
In einer anderen, ebenfalls vorteilhaften Verfahrensvariante, die nachfolgend auch als „indirekte Variante“ bezeichnet wird, ist vorgesehen, dass das Endgerät des zweiten Unternehmens B den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssel K_sec an eine Sicherheitsinstanz des zweiten Unternehmens B weiterleitet; dass die Sicherheitsinstanz des zweiten Unternehmens B den Status des Endgeräts des zweiten Unternehmens B prüft und im Fall einer erfolgreichen Prüfung den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssel K_sec an die Sicherheitsinstanz des ersten Unternehmens A überträgt; dass die Sicherheitsinstanz des ersten Unternehmens A die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz des ersten Unternehmens A erzeugte Signatur an die Sicherheitsinstanz des zweiten Unternehmens B überträgt; und dass die Sicherheitsinstanz des zweiten Unternehmens B die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz des ersten Unternehmens A erzeugte Signatur an das Endgerät des zweiten Unternehmens B weiterleitet.
Besonders bevorzugt ist dabei insbesondere vorgesehen, dass das Endgerät des zweiten Unternehmens B den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssel K_sec zusammen mit einer mit dem privaten Schlüssel K_{usr_bk_prv} des Endgeräts des zweiten Unternehmens B erstellten Signatur des verschlüsselten Dokumentenschlüssels K_sec an die Sicherheitsinstanz des zweiten Unternehmens B weiterleitet; dass die Sicherheitsinstanz des zweiten Unternehmens B den Status des Endgeräts des zweiten Unternehmens B prüft und im Fall einer erfolgreichen Prüfung den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssel K_sec zusammen mit der mit dem privaten Schlüssel K_{usr_bk_prv} des Endgeräts des zweiten Unternehmens B erstellten Signatur des verschlüsselten Dokumentenschlüssels K_sec und dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts des zweiten Unternehmens B an die Sicherheitsinstanz des ersten Unternehmens A überträgt; dass die Sicherheitsinstanz des ersten Unternehmens A die übermittelte Signatur des verschlüsselten Dokumentenschlüssels K_sec mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts des zweiten Unternehmens B verifiziert; dass die Sicherheitsinstanz des ersten Unternehmens A im Fall einer erfolgreichen Verifikation die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz des ersten Unternehmens A erzeugte Signatur an die Sicherheitsinstanz des zweiten Unternehmens B überträgt; und dass die Sicherheitsinstanz des zweiten Unternehmens B die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz des ersten Unternehmens A erzeugte Signatur an das Endgerät des zweiten Unternehmens B weiterleitet.
In beiden Verfahrensvarianten ist dabei mit Vorteil vorgesehen, dass das Endgerät bzw. die Sicherheitsinstanz des zweiten Unternehmens B die von der Sicherheitsinstanz des ersten Unternehmens A erzeugte Signatur des verschlüsselten Dokumentenschlüssels K_sec überprüft, bevor der Dokumentencontainer an den Cloudspeicherdienst übertragen wird.
Bevorzugt umfassen die Sicherheitsinstanzen des ersten und/oder zweiten Unternehmens jeweils einen Sicherheitsserver und der Cloudspeicherdienst einen Cloudserver.
Gemäß eines weiteren Aspekts der Erfindung wird ein Verfahren zum Verleihen von Zugriffsrechten auf ein elektronisches Dokument, das von einem Endgerät eines ersten Unternehmens A in einem Dokumentencontainer auf einem Cloudspeicherdienst gespeichert worden ist, an ein Endgerät eines zweiten Unternehmens B bereitgestellt, wobei der Dokumentencontainer das mit einem Dokumentenschlüssel K_sec verschlüsselte Dokument und den mit einem öffentlichen Schlüssel K_{ssa_pub} einer Sicherheitsinstanz des ersten Unternehmens A verschlüsselten Dokumentenschlüssel K_sec enthält. Dabei umfasst das Verfahren die folgenden Schritte: das Definieren der Zugriffsrechte auf das elektronische Dokument in Form einer Datenstruktur USRS_acls auf dem Endgerät des ersten Unternehmens A; das Übertragen der Datenstruktur USRS_acls an die Sicherheitsinstanz des ersten Unternehmens A; das Übertragen des Status des Endgeräts des zweiten Unternehmens B an die Sicherheitsinstanz des ersten Unternehmens A; und das Ändern der Zugriffsrechte auf das auf dem Cloudspeicherdienst gespeicherte elektronische Dokument gemäß der Datenstruktur USRS_acls und gemäß dem Status des Endgeräts des zweiten Unternehmens B auf der Sicherheitsinstanz des ersten Unternehmens A.
Dabei werden dem Endgerät des zweiten Unternehmens B insbesondere nur dann Zugriffsrechte verliehen, wenn der Status des Endgeräts auf aktiv gesetzt ist, d.h. das Endgerät z.B. nicht als gestohlen oder verloren gemeldet wurde. Es versteht sich, dass natürlich auch einem Endgerät des ersten Unternehmens A Zugriffsrechte auf das elektronisches Dokument verliehen werden können, dies kann jedoch, da die Sicherheitsinstanz des ersten Unternehmens A die Benutzer bzw. Endgeräte des ersten Unternehmens kennt, in der bereits in der Anmeldung PCT/ EP2014/003035 beschriebenen Art erfolgen.
Gemäß einem weiteren Aspekt der Erfindung wird ein Endgerät bereitgestellt, das dazu ausgestaltet ist, im Rahmen eines der vorstehenden Verfahren eingesetzt zu werden.
Gemäß einem weiteren Aspekt der Erfindung wird eine Sicherheitsinstanz, vorzugsweise in Form eines Sicherheitsservers, bereitgestellt, die dazu ausgestaltet ist, im Rahmen eines der vorstehenden Verfahren eingesetzt zu werden.
Gemäß einem weiteren Aspekt der Erfindung wird ein System mit wenigstens einem solchen Endgerät eines ersten Unternehmens A, wenigstens einem solchen Endgerät eines zweiten Unternehmens B, einer solchen Sicherheitsinstanz des ersten Unternehmens A, einer solchen Sicherheitsinstanz des zweiten Unternehmens B und wenigstens einem Cloudspeicherdienst bereitgestellt. Das System kann eine Mehrzahl von Endgeräten einer Mehrzahl von Unternehmen A, B, C, D, ... umfassen, die jeweils die Rolle des Unternehmens A bzw. B einnehmen.
Die vorliegende Erfindung bietet insbesondere die folgenden Vorteile. Die vollständige Kontrolle der kryptographischen Schlüssel erfolgt auf Seiten des Benutzers, und zwar innerhalb einer durch den Benutzer kontrollierten sicheren Umgebung. Der Cloudserver benötigt keine besonderen Sicherheitsmaßnahmen, kann also ein beliebig angemieteter Server sein, und kann insbesondere von allen beteiligten Unternehmen gleichermaßen genutzt werden. Bestehende Cloudserver müssen nicht speziell modifiziert werden, so dass bekannte Cloudspeicherdienste genutzt werden können.
Der Sicherheitsserver eines Unternehmens kann einzelne Endgeräte vom Zugriff nachträglich ausschließen, um die Sicherheit der Dokumente bei Verlust oder Diebstahl eines Endgeräts zu wahren. Bei jedem Zugriff oder Modifikation durch ein Endgerät eines anderen Unternehmens wird bevorzugt zunächst der Status dieses Endgeräts beim zuständigen Sicherheitsserver des anderen Unternehmens erfragt. Der Sicherheitsserver besitzt Zugriff auf alle von ihm verwalteten Dokumente, so dass beispielsweise ein Unternehmen noch auf Dokumente der Mitarbeiter zugreifen kann, die nicht mehr für das Unternehmen arbeiten. Ein Sicherheitsserver kann den Dokumentenzugriff für beliebig viele Cloudserver und beliebig viele Benutzer bzw. Endgeräte verwalten. Der Sicherheitsserver benötigt bis auf das Ver- und Entschlüsseln des geheimen Dokumentenschlüssels K_sec und das Signieren kleiner Datenpakete im Vergleich zum Cloudserver keine große Rechenleistung, außerdem nur überschaubaren Speicherplatz und eine Internetverbindung mit relativ geringer Bandbreite.
Mitarbeiter mehrerer Unternehmen, die jeweils ihre eigenen CKM Systeme betreiben können auf sichere und flexible Weise auf dieselben, von dem Cloudserver gespeicherten Dokumente zugreifen. Dabei ist der unternehmensübergreifende Zugriff vollständig in das Verfahren bzw. in die das Verfahren implementierenden Systeme und Komponenten integriert. Die Mitarbeiter sind nicht gezwungen, für den Dokumentenaustausch mit anderen Unternehmen auf alternative Methoden zurückzugreifen, die unter Umständen umständlich und/ oder unsicher sind.
Auch für den unternehmensübergreifenden Fall kann genau kontrolliert werden, wer der Eigentümer eines Dokuments ist und wer welche Zugriffsrechte auf das Dokument erhält.
Die Kontrolle über ein Dokument bleibt bei dem Unternehmen bzw. dem Mitarbeiter, dem dieses Dokument gehört, auch wenn Mitarbeiter von anderen Unternehmen darauf Zugriff bekommen.
Es ist eindeutig nachvollziehbar und gegebenenfalls auch nicht abstreitbar, dass ein Mitarbeiter aus einem anderen Unternehmen auf Daten des Cloudservers zugegriffen hat.
Aufgrund der zentralen Verwaltung eines bestimmten Dokuments auf einem bestimmten Sicherheitsserver wird der Überblick über die Versionsstände gewahrt.
Weitere Ausführungsbeispiele sowie Vorteile der Erfindung werden nachfolgend anhand der Figuren erläutert, bei deren Darstellung auf eine maßstabs- und proportionsgetreue Wiedergabe verzichtet wurde, um die Anschaulichkeit zu erhöhen.
Es zeigen:

1 eine schematische Darstellung eines Systems mit einem Cloudserver zur Speicherung von Daten und, für zwei Unternehmen A und B, jeweils mit einem Sicherheitsserver und einer Mehrzahl von Endgeräten,
2 eine Darstellung eines Ablaufs bei der Speicherung eines von einem Mitarbeiter des Unternehmens A neu erstellten Dokuments auf dem Cloudserver von 1,
3 eine Darstellung eines erfindungsgemäß bevorzugten Ablaufs bei der Einräumung von Nutzerrechten an einem von einem Mitarbeiter des Unternehmens A erstellten Dokument an einen Mitarbeiter des Unternehmens B,
4 eine Darstellung eines erfindungsgemäß bevorzugten Ablaufs beim Zugreifen auf ein von einem Mitarbeiter des Unternehmens A erstelltes Dokument durch einen Mitarbeiter des Unternehmens B in der direkten Variante,
5 eine Darstellung eines erfindungsgemäß bevorzugten Ablaufs bei der Modifizierung und nachfolgender Abspeicherung eines von einem Mitarbeiter des Unternehmens A erstellten Dokuments durch einen Mitarbeiter des Unternehmens B in der direkten Variante,
6 eine Darstellung eines erfindungsgemäß bevorzugten Ablaufs beim Zugreifen auf ein von einem Mitarbeiter des Unternehmens A erstelltes Dokument durch einen Mitarbeiter des Unternehmens B in der indirekten Variante, und
7 eine Darstellung eines erfindungsgemäß bevorzugten Ablaufs bei der Modifizierung und nachfolgender Abspeicherung eines von einem Mitarbeiter des Unternehmens A erstellten Dokuments durch einen Mitarbeiter des Unternehmens B in der indirekten Variante.

1 zeigt eine schematische Darstellung der Komponenten eines erfindungsgemäßen Gesamtsystems 10 sowie einige der Kommunikationsverbindungen zwischen diesen Komponenten, die unterschiedliche Aspekte der vorliegenden Erfindung illustriert.
Die vorliegende Erfindung geht davon aus, dass mehrere Unternehmen jeweils eigene Cloud Key Management (CKM) Systeme betrieben, wie sie beispielsweise in der Anmeldung PCT/ EP2014/003035 im Detail beschrieben sind. Wie oben ausgeführt umfasst der Begriff „Unternehmen“ dabei auch Behörden und andere Organisationen, denen jeweils eine geschlossene Benutzergruppe, beispielsweise die Mitarbeiter des Unternehmens, angehört. An dem CKM System eines Unternehmens sind jeweils die eigenen Mitarbeiter als Benutzer registriert. Die grundlegende Funktionsweise eines solchen CKM Systems innerhalb eines einzigen Unternehmens, insbesondere die Speicherung eines elektronischen Dokuments, das auf einem Endgerät vorliegt, auf einem Cloudspeicherdienst, das Zugreifen von einem Endgerät desselben Unternehmens auf ein so auf dem Cloudspeicherdienst gespeichertes elektronisches Dokument, das Abspeichern eines auf einem Endgerät desselben Unternehmens modifizierten elektronischen Dokuments, das zuvor auf dem Cloudspeicherdienst gespeichert wurde und das Ändern der Zugriffsrechte auf ein auf dem Cloudspeicherdienst gespeichertes elektronisches Dokument für Endgeräte desselben Unternehmens, wurden bereits in der Anmeldung PCT/ EP2014/003035 , deren Offenbarung insoweit in die vorliegende Beschreibung aufgenommen wird, ausführlich beschrieben.
Die vorliegende Erfindung betrifft insbesondere die Kopplung mehrerer CKM Systeme unterschiedlicher Unternehmen, um zu erreichen, dass Benutzer des einen CKM Systems in sicherer Weise Zugriff auf bestimmte Dokumente erhalten können, die auf einem anderen CKM System verwaltet werden. Dabei bleibt das Unternehmen, auf dessen CKM System ein Dokument verwaltet wird, bzw. der entsprechende Mitarbeiter dieses Unternehmens Eigentümer des Dokuments und kontrolliert die Zugriffsrechte.
Mit Bezug auf die Darstellung der 1 enthält das Gesamtsystem 10 mehrere CKM-Systeme unterschiedlicher Unternehmen. Zur Illustration wird nachfolgenden von zwei Unternehmen A und B ausgegangen, wobei das elektronische Dokument von einem Mitarbeiter des Unternehmens A erstellt wurde und ein Mitarbeiter des Unternehmens B Zugriff auf das Dokument erhalten möchte. Es versteht sich, dass die beschriebenen Prinzipien in gleicher Weise für eine beliebige Anzahl von Unternehmen gelten.
Die Unternehmen A und B betreiben jeweils ihre eigenen CKM Systeme. Deren Mittelpunkt bilden jeweils die Sicherheitsinstanzen SS-A bzw. SS-B, die vorzugsweise jeweils in Form eines Sicherheitsservers ausgebildet sind. Die Mitarbeiter des Unternehmens A besitzen die Endgeräte UD-A-i, mit i = 1, 2, 3, ..., NA, die Mitarbeiter des Unternehmens B besitzen die Endgeräte UD-B-k, mit k = 1, 2, 3, ..., NB. Von den Endgeräten der Unternehmen A und B ist in 1 jeweils eines exemplarisch dargestellt, die weiteren Endgeräte sind nur durch Punkte angedeutet. Die Mitarbeiter des Unternehmens A sind mit ihren Endgeräten beim Sicherheitsserver SS-A als Benutzer registriert und verwalten darüber ihre Dokumente. Entsprechendes gilt für die Mitarbeiter des Unternehmens B.
Ein Sicherheitsserver SS-A bzw. SS-B und die zugehörigen Endgeräte UD-A-i bzw. UD-B-k stehen in einer direkten gegenseitigen Vertrauensbeziehung: der Sicherheitsserver kennt die öffentlichen Schlüssel der bei ihm registrierten Endgeräte und die Endgeräte kennen den öffentlichen Schlüssel des Sicherheitsservers des eigenen Unternehmens. Dadurch können ein Endgerät und der Sicherheitsserver desselben Unternehmens jeweils die Authentizität des anderen verifizieren. Wie diese Vertrauensbeziehungen zustande kamen, wie also die öffentlichen Schlüssel sicher ausgetauscht wurden, ist nicht Gegenstand dieser Anmeldung.
Es besteht dagegen keine Notwendigkeit, dass ein Endgerät den öffentlichen Schlüssel eines anderen Endgeräts kennt, da der gemeinsame Zugriff auf ein Dokument immer über den Sicherheitsserver geregelt wird. Ein Endgerät UD-A-i benötigt innerhalb des eigenen Unternehmens nur die ID eines anderen Benutzers bzw. seines Endgeräts UD-A-j zur Verwaltung der Zugriffsrechte auf ein Dokument. Diese ID wird ihm durch den Sicherheitsserver SS-A sicher zur Verfügung gestellt.
Im Fall der hier beschriebenen Kopplung von zwei CKM Systemen, die von zwei Unternehmen betrieben werden, müssen die Sicherheitsserver der beiden Unternehmen sicher miteinander kommunizieren können. Dazu wird eine direkte Vertrauensbeziehung benötigt, der Sicherheitsserver SS-A des Unternehmens A muss den öffentlichen Schlüssel des Sicherheitsserver SS-B kennen und umgekehrt. Die direkte Vertrauensbeziehung kann durch einen authentischen Schlüsselaustausch eingerichtet werden, bei dem jede Partei der jeweils anderen Partei ihren öffentlichen Schlüssel in Form eines selbstsignierten Zertifikats übermittelt und über einen zweiten unabhängigen Kanal die Fingerprints der öffentlichen Schlüssel verifiziert werden. Dies muss nur einmalig zu Beginn der Zusammenarbeit der beiden Unternehmen A und B durchgeführt werden. Üblicherweise werden solche Schlüssel aus Sicherheitsgründen in regelmäßigen Abständen ersetzt, was einen erneuten Schlüsselaustausch zwischen den Sicherheitsservern erfordert, aber auch dies sind selten durchzuführende Aktionen.
Auch im Fall der Kopplung mehrerer CKM Systeme vertraut ein Endgerät nur dem Sicherheitsserver des eigenen Unternehmens direkt. Wie im Folgenden genauer beschrieben, wird in manchen Verfahren eine indirekte Vertrauensbeziehung zwischen einem Endgerät eines Unternehmens und dem Sicherheitsserver eines anderen Unternehmens vorübergehend hergestellt, indem der Sicherheitsservver des eigenen Unternehmens den öffentlichen Schlüssel des Sicherheitsservers des anderen Unternehmens zertifiziert und das Zertifikat dem Endgerät zur Verfügung stellt. Auch zertifiziert der Sicherheitsserver eines Unternehmens den öffentlichen Schlüssel des jeweiligen Endgeräts des eigenen Unternehmens und stellt dieses Zertifikat dem Sicherheitsserver des anderen Unternehmens zur Verfügung.
Die Endgeräte sind insbesondere in Form einer Computereinheit 30, vorzugsweise eines Personal Computer (PC), eines Tablet Computer, ein Notebook, ein Netbook, oder dergleichen ausgebildet, oder auch in Form eines mobilen Endgeräts, vorzugsweise ein Smartphone oder dergleichen. Die Endgeräte sind dabei dazu ausgestaltet, über ein Kommunikationsnetzwerk 40 auf einen Cloudspeicherdienst, vorzugsweise in Form eines Cloudservers 50 zuzugreifen, um auf diesem Cloudserver 50 elektronische Daten zu speichern (beispielsweise auf einer Datenbank 52 des Cloudservers 50) und von dort wieder abzurufen. Vorzugsweise handelt es sich bei dem Kommunikationsnetzwerk 40 um das Internet. Insbesondere kann als Endgerät im Sinn der Erfindung auch eine in einem Endgerät betriebene Smartcard in Zusammenwirken mit dem Endgerät vorgesehen sein.
Auf derartige Cloudserver 50, wie diese dem Fachmann unter den Namen Dropbox, Skydrive, Google Drive, Amazon Cloud Services und dergleichen bekannt sind, kann in der Regel mittels eines auf der Computereinheit 30 laufenden Webbrowsers, wie beispielsweise Internet Explorer, Firefox, Google Chrome, Safari oder dergleichen, oder einer entsprechenden Applikation mit einer auf einem Display der Computereinheit 30 dargestellten graphischen Benutzeroberfläche zugegriffen werden.
Der Cloudserver 50 ist öffentlich und kann gleichermaßen von allen beteiligten Unternehmen A, B benutzt werden.
Vorzugsweise verfügen die Endgeräte jeweils über einen besonders gesicherten Bereich, insbesondere zur Speicherung und Verarbeitung von sicherheitskritischen Daten. Bei der Computereinheit 30 ist dieser gesicherte Bereich vorzugsweise in Form eines dem Fachmann bekannten Trusted Execution Environments (TEE) mit einem gesicherten Speicherbereich ausgebildet, in dem insbesondere eine eindeutige Benutzer- oder Endgerätkennung USR_id sowie ein privater Schlüssel K_{usr_prv} des Benutzers der Computereinheit 30 hinterlegt ist. Bei dem mobilen Endgerät ist dieser gesicherte Bereich vorzugsweise durch ein Sicherheitselement, vorzugsweise in Form einer SIM-Karte, einer eUICC oder dergleichen, mit einem gesicherten Speicherbereich ausgebildet, in dem insbesondere eine eindeutige Benutzer- oder Endgerätkennung USRid sowie ein privater Schlüssel K_{usr_prv} des Benutzers des mobilen Endgeräts hinterlegt ist.
Bei der Kopplung mehrerer CKM Systeme müssen alle Benutzer bzw. ihre Endgeräte, alle Dokumente und auch alle Sicherheitsinstanzen durch IDs gekennzeichnet sein, die über das Gesamtsystem 10, d.h. über alle CKM Systeme hinweg eindeutig sind. Es muss auch aus den IDs ersichtlich sein, zu welchen CKM Systemen Benutzer bzw. die Endgeräte und Dokumente gehören, also auf welchen Sicherheitsinstanzen sie verwaltet werden.
Am einfachsten lassen sich diese Forderungen erfüllen, indem jedem CKM System eine eindeutige ID zugeordnet wird. Da im nachfolgend beschriebenen Ausführungsbeispiel jedes CKM System genau einen Sicherheitsserver betreibt, kann ein Sicherheitsserver durch eine SecServerlD gekennzeichnet sein, die mit der ID des CKM Systems identisch ist. Ein Cluster aus mehreren Servern zwecks Lastverteilung und Ausfallsicherheit wird hier als ein einziger Sicherheitsserver behandelt. IDs von Benutzern bzw. Endgeräten und von Dokumenten werden dann aus der ID des CKM Systems und eindeutigen Nummern innerhalb des jeweiligen CKM Systems gebildet. Dieses Vorgehen ermöglicht eine einfache Vergabe von über das Gesamtsystem hinweg eindeutigen IDs. Es versteht sich allerdings, dass im Rahmen der Erfindung auch andere Verfahren zur Kennzeichnung von CKM Systemen, Sicherheitsserver, Benutzern, Endgeräten und Dokumenten möglich sind.
Die Sicherheitsserver SS-A, SS-B stehen über das Kommunikationsnetzwerk 40 in Kommunikation mit den anderen Komponenten des Gesamtsystems 10. Vorzugsweise verfügt jeder Sicherheitsserver SS-A, SS-B über einen besonders gesicherten Bereich, insbesondere zur Speicherung und Verarbeitung von sicherheitskritschen Daten. Bei den Sicherheitsservern SS-A, SS-B ist dieser gesicherte Bereich vorzugsweise in Form eines Hardware-Sicherheitsmoduls (HSM; hardware security module) mit einem gesicherten Speicherbereich ausgebildet, in dem insbesondere ein privater Schlüssel K_{ssa_prv} bzw. K_{ssb_prv} des Sicherheitsservers sicher hinterlegt ist.
Bei den auf dem Cloudserver 50 hinterlegten Daten kann es sich um jede Art von elektronischen bzw. digitalen Daten handeln, wie beispielsweise eine Word- oder Excel-Datei, ein PDF-Dokument, ein Foto, eine MP3-Datei und dergleichen. In der nachstehenden Beschreibung werden diese Daten der Einfachheit halber als ein (elektronisches) Dokument DOC bezeichnet. Wie dies nachstehend im Detail beschrieben wird, wird erfindungsgemäß ein Dokument DOC innerhalb eines Dokumentencontainers DOC_con auf dem Cloudserver 50 bzw. einer Datenbank 52 des Cloudservers 50 abgelegt, der beispielsweise bei einem von einem Mitarbeiter des Unternehmens A erstellten Dokuments vorzugsweise die folgenden Elemente enthält: DOC_id, DOC_ver, ENC(DOC, K_sec), ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), SIG(DOC_id∥DOC_ver∥ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), K_{ssa_prv}), die nachstehend im Detail beschrieben werden. Das Dokument DOC liegt in diesem Dokumentencontainer DOC_con in verschlüsselter Form vor, und zwar aufgrund einer Verschlüsselung mit einem geheimen Dokumentenschlüssel K_sec, der für jedes neue Dokument DOC und jede neue Version eines Dokuments DOC neu erzeugt wird, vorzugsweise mittels eines Zufallszahlengenerators.
Unter weiterer Bezugnahme auf 2 wird nachstehend zunächst das Abspeichern eines von einem Mitarbeiter des Unternehmens A neu erstellten Dokuments auf dem Cloudserver 50 im Detail beschrieben.
In Schritt S201 von 2 wird auf dem Endgerät UD-A-i eines Mitarbeiters des Unternehmens A ein neues Dokument DOC erzeugt, das auf dem Cloudserver 50 gespeichert werden soll. Hierzu fragt das Endgerät UD-A-i beim Sicherheitsserver SS-A des Unternehmens A nach einer Dokumentenkennung, die sich vorzugsweise aus einer eindeutigen Dokumentenidentifikationsnummer DOC_id und einer Dokumentenversionsnummer DOC_verzusammensetzt. Die Dokumentenversionsnummer DOC_verdient dazu, unterschiedliche Versionen des durch die Dokumentenidentifikationsnummer DOC_id eindeutig identifizierten Dokuments DOC voneinander zu unterscheiden. Obwohl diese Ausgestaltung der Dokumentenkennung erfindungsgemäß bevorzugt ist, wird der Fachmann erkennen, dass die Erfindung auch dann vorteilhaft eingesetzt werden kann, wenn die Dokumentenkennung nur aus einer eindeutigen Dokumentenidentifikationsnummer besteht.
Der Sicherheitsserver SS-A erzeugt im Schritt S202 die gewünschte Dokumentenkennung, d.h. die eindeutige Dokumentenidentifikationsnummer DOC_id und die Dokumentenversionsnummer DOC_ver, und sendet diese im Schritt S203 an das Endgerät UD-A-i. Dabei kann der Sicherheitsserver SS-A die Dokumentenkennung erzeugen, indem die Dokumentenidentifikationsnummer DOC_id und die Dokumentenversionsnummer DOC_vermiteinander konkateniert werden, was in diese Beschreibung durch das Symbol" “∥“ bezeichnet ist. Obgleich die Dokumentenidentifikationsnummer DOC_id und/oder die Dokumentenversionsnummer DOC_verprinzipiell auch von dem Endgerät UD-A-i erstellt werden könnten, ist es vorteilhaft, dass diese Aufgabe vom Sicherheitsserver SS-A übernommen wird, da dadurch verhindert werden kann, dass zwei Endgeräte, auf denen parallel Dokumente zur Speicherung auf dem Cloudserver 50 erstellt werden, dieselbe Dokumentenidentifikationsnummer erzeugen.
In Schritt S204 von 2 wird von dem Endgerät UD-A-i ein geheimer Dokumentenschlüssel K_sec erzeugt, beispielsweise mittels eines Zufallszahlengenerators. Mit Hilfe dieses geheimen Dokumentenschlüssels K_sec werden die folgenden Teile eines Dokumentencontainers DOC_con zur sicheren Speicherung des Dokuments DOC auf dem Cloudserver 50 erstellt: das Dokument DOC wird mit dem geheimen Dokumentenschlüssel K_sec verschlüsselt, d.h. ENC(DOC, K_sec), beispielsweise mittels des AES-Verschlüsselungsalgorithmus; und zur Sicherstellung der Authentizität und Integrität werden durch Anwendung einer Einwegfunktion vorzugsweise in Form einer Hashfunktion H die Hashwerte über das Dokument DOC und die Dokumentenkennung DOC_id ∥DOC_verberechnet und zusammen mit dem geheimem Dokumentenschlüssel K_sec mit einem öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A verschlüsselt, d.h. ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), wobei H(X) den Hashwert des Datenelements X bezeichnet.
Wie der Fachmann erkennt, wird in der vorliegenden Anmeldung für die Verschlüsselung eines Datenelements X mit dem Schlüssel K die Notation ENC(X, K) verwendet. Dabei kann es sich bei den mit ENC bezeichneten Verschlüsselungsalgorithmen um symmetrische Verschlüsselungsverfahren, wie beispielsweise DES, AES oder dergleichen, oder um asymmetrische Verschlüsselungsverfahren, wie beispielsweise RSA oder dergleichen, handeln. Im Einzelnen kann der Fachmann aus dem Zusammenhang erkennen, ob erfindungsgemäß ein symmetrisches und/oder ein asymmetrisches Verschlüsselungsverfahren eingesetzt werden kann.
Vorzugsweise enthält der Dokumentencontainer DOC_con ferner eine Signatur des Sicherheitsservers SS-A des Unternehmens A, die über die im Datencontainer DOC_con enthaltenen Datenelemente gebildet wird. Um gegenüber dem Sicherheitsserver SS-A die Korrektheit der zu signierenden Datenelemente nachzuweisen, signiert das Endgerät UD-A-i diese Datenelemente mit seinem privaten Schlüssel K_{usr_ai_prv}, bevor diese an den Sicherheitsserver SS-A geschickt werden, d.h. von dem Endgerät UD-A-i wird die folgende Signatur erzeugt: SIG(DOC_id∥DOC_ver∥ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), K_{usr_ai_prv}), wobei SIG(X, K) für die elektronische Signatur des Datenelements X mit dem Schlüssel K steht.
In Schritt S205 sendet das Endgerät UD-A-i eine eindeutige Benutzer- oder Endgerätkennung USR_id, die Dokumentenkennung (DOC_id∥DOC_ver), den verschlüsselten Dokumentenschlüssel K_sec und die über diese Datenelemente berechnete Signatur an den Sicherheitsserver SS-A. Dabei werden diese Datenelemente vorzugsweise miteinander konkateniert, wodurch sich folgendes Datenelement ergibt: DAT = USR_id ∥DOC_id ∥DOC_ver∥ ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}) ∥ SIG(DOC_id∥DOC_ver∥ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), Kusr_ai_prv) .
Nachdem der Sicherheitsserver SS-A das Datenelement DAT von dem Endgerät UD-A-i erhalten hat, führt der Sicherheitsserver SS-A in Schritt S206 von 2 vorzugsweise die folgenden Überprüfungen durch. Zunächst überprüft der Sicherheitsserver SS-A anhand der Benutzer- oder Endgerätkennung USR_id und der Dokumentenkennung (DOC_id∥DOC_ver), dass der Benutzer bzw. dessen Endgerät bekannt sind, dass es sich um ein neues Dokument handelt, und dass dieser Benutzer dazu berechtigt ist, ein neues Dokument DOC anzulegen und auf dem Cloudserver 50 abzulegen. Ferner verifiziert der Sicherheitsserver SS-A in Schritt S206 die im Datenelement DAT enthaltene Signatur und stellt damit sicher, dass das Datenelement DAT tatsächlich von dem Endgerät UD-A-i stammt. Mit seinem privaten Schlüssel K_{ssa_prv} entschlüsselt der Sicherheitsserver SS-A den Dokumentenschlüssel K_sec und die Hashwerte über das Dokument DOC und die Dokumentenkennung DOC_id ∥DOC_ver. Die Prüfung des Hashwerts über die Dokumentenkennung DOC_id ∥DOC_verist für die Sicherheit des Systems wichtig, da sich ansonsten ein Endgerät unberechtigt Zugang zu einem fremden Dokument verschaffen könnte.
Falls die vorstehend beschriebenen Prüfungen durch den Sicherheitsserver SS-A in Schritt S206 erfolgreich waren, speichert der Sicherheitsserver SS-A, beispielsweise in einer Datenbank, die Dokumentenkennung (DOC_id∥DOC_ver) zusammen mit der Benutzer- oder Endgerätekennung US-R_id und erstellt mit seinem privaten Schlüssel K_{ssa_prv} die für den Dokumentencontainer benötigte Signatur:

SIG(DOC_id∥DOC_ver∥ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), K_{ssa_prv}). Diese Signatur schickt der Sicherheitsserver SS-A in Schritt S207 zurück an das Endgerät UD-A-i, das sich durch Überprüfung dieser Signatur mittels des öffentlichen Schlüssels K_{ssa_pub} des Sicherheitsservers SS-A von der Korrektheit der mit der Signatur erfassten Datenelemente überzeugen kann.

Neben der Überprüfung der vom Sicherheitsserver SS-A in Schritt S207 übermittelten Signatur komplettiert das Endgerät UD-A-i in Schritt S208 von 2 den Dokumentencontainer DOC_con mit dieser Signatur, so dass der vollständige, in Schritt S209 an den Cloudserver 50 zu übertragene Dokumentencontainer DOC_con vorzugsweise in der folgenden Form vorliegt: $\begin{matrix} {DOC}_{con} = {DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (DOC, K_{sec}) ‖ \\ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), K_{ssa_pub}) ‖ \\ SIG ({DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), \\ K_{ssa_pub}), K_{ssa_prv}) \end{matrix}$
Der Cloudserver 50 speichert den in Schritt S209 übermittelten Dokumentencontainer DOC_con und bestätigt dies dem Endgerät UD-A-i in Schritt S210 mittels einer Bestätigungsmeldung. Der von dem Endgerät UD-A-i erzeugte Dokumentenschlüssel K_sec sollte, nachdem dieser zur Verschlüsselung des Dokuments DOC verwendet worden ist und in den Dokumentencontainer DOC_con eingeflossen, auf dem Endgerät UD-A-i gelöscht werden, beispielsweise nach Schritt S205 von 2.
Ein vorteilhafter Ablauf beim Abrufen des auf dem Cloudserver 50 als Teil des Dokumentencontainers DOC_con hinterlegten Dokuments DOC durch ein Endgerät desselben Unternehmens, hier des Unternehmens A, wurde bereits in der Anmeldung PCT/ EP2014/003035 im Zusammenhang mit der dortigen 3 beschrieben.
Gemäß der in dieser Anmeldung beschriebenen Weiterbildung ist es jedoch auch möglich, dass ein Mitarbeiter eines anderen Unternehmens, hier des Unternehmens B, welcher nicht bei der Sicherheitsinstanz SS-A des Unternehmens A als Benutzer registriert ist, auf das hinterlegte Dokument DOC zugreift, dieses modifiziert und das modifizierte Dokument wieder auf dem Cloudserver 50 abspeichert.
Hierzu muss der Mitarbeiter des Unternehmens B zunächst von einem berechtigten Mitarbeiter des Unternehmens A die notwendigen Zugriffsrechte auf das Dokument erhalten, wobei für die nachfolgende Beschreibung konkret angenommen wird, dass ein Mitarbeiter des Unternehmens A mit dem Endgerät UD-A-i einem Mitarbeiter des Unternehmens B mit dem Endgerät UD-B-k Zugriffsrechte auf das Dokument DOC erteilt.
Damit der Eigentümer eines Dokuments einem anderen Benutzer die Zugriffsrechte auf dieses Dokument mit einem bestimmten Endgerät erteilen kann, benötigt er dessen Identität in Form einer USR_id. Innerhalb eines einzigen CKM Systems lässt sich ein Zugriff auf die Identitäten recht komfortabel gestalten, da es innerhalb von Unternehmen typischerweise Verzeichnisse der Mitarbeiter mit zugehörigen Daten wie Telefonnummer, Mailadresse und weiteren Informationen gibt. Für die einfache Verwendung einer CKM Client Applikation auf dem Endgerät hat diese idealerweise einen direkten Zugriff auf ein solches Verzeichnis, das dann auch die USR_id bereitstellt, und zwar in sicherer Form, d.h. insbesondere signiert mit dem privaten Schlüssel des Sicherheitsservers. Der Eigentümer eines Dokuments kann dann direkt mit seiner CKM Client Applikation für die Rechtevergabe in diesem Verzeichnis suchen und andere Benutzer bzw. deren Endgeräte auswählen.
Sind wie hier, mehrere CKM Systeme gekoppelt, wird eine andere Lösung benötigt, da aus Datenschutzgründen das Unternehmen B dem Unternehmen A keinen Zugriff auf sein gesamtes Verzeichnis gewähren wird. Stattdessen stellt ein Benutzer aus Unternehmen B, der Zugriff auf ein Dokument benötigt, dem Eigentümer aus Unternehmen A seine USR_id in geeigneter Weise zur Verfügung, beispielsweise durch Übermittlung über die Ferne z.B. per Mail oder durch eine direkte Übertragung von einem Endgerät auf das andere z.B. per Bluetooth oder Abfotografieren eines QR-Codes. Damit der Eigentümer des Dokuments verifizieren kann, dass es sich um die richtige USR_id handelt, wird diese in Form einer Datenstruktur UserInfo bereitgestellt, die zumindest noch den Namen des Benutzers enthält, eventuell auch noch weitere Datenelemente. Idealerweise ist die UserInfo zur Begrenzung der Gültigkeitsdauer mit einem Verfallsdatum versehen. Zur Sicherstellung der Authentizität und Integrität ist die UserInfo vom Sicherheitsserver SS-B signiert.
Alternativ kann der Benutzer aus Unternehmen B dem Eigentümer aus Unternehmen A auch andere Angaben liefern, die ihn hinreichend genau identifizieren, z.B. seinen Namen und seine Organisationseinheit oder seine Email-Adresse. In dieser Variante kann dann der Eigentümer des Dokuments die USR_id des anderen Benutzers unter Angabe von dessen Identifikationsdaten beim Sicherheitsserver SS-B ermitteln. Alternativ akzeptiert der Sicherheitsserver SS-A eine entsprechende Nachricht auch mit den Identifikationsdaten des Benutzers des Unternehmens B und ermittelt selbständig dessen USR_id beim Sicherheitsserver SS-B.
In einer vorteilhaften möglichen Variante läuft die genannte Einräumung von Nutzerrechten im Einzelnen folgendermaßen ab: In Schritt S301 der 3 sendet das Endgerät UD-B-k eines Mitarbeiters des Unternehmens Beine Anfrage an den Sicherheitsserver SS-B des Unternehmens B, die die USR_id des Mitarbeiters bzw. des Endgeräts UD-B-k enthält. Wenn es sich um eine ihm bekannte gültige USR_id handelt, erstellt der Sicherheitsserver SS-B aus ihm vorliegenden Daten, insbesondere der USR_id und dem Namen des Benutzers, eine Datenstruktur UserInfo und signiert diese mit seinem privaten Schlüssel. Diese UserInfo schickt der Sicherheitsserver SS-B in Schritt S302 an das Endgerät UD-B-k zurück.
In Schritt S303 überprüft das Endgerät UD-B-k mit dem ihm bekannten öffentlichen Schlüssel K_{ssb_pub} des Sicherheitsservers SS-B die Korrektheit der UserInfo. Da es sich bei der UserInfo um einen Datensatz mit einer längeren Gültigkeitsdauer handelt, kann sie alternativ auch einmalig erstellt und dann auf dem Sicherheitsserver SS-B oder dem Endgerät UD-B-k zwischengespeichert werden. Dies erspart dann eine weitere Erstellung und gegebenenfalls auch einen weiteren Nachrichtenwechsel mit den Schritten S301 und S302.
Der Benutzer mit dem Endgerät UD-B-k übermittelt in Schritt S304 seine UserInfo an den Eigentümer des Dokuments mit dem Endgerät UD-A-i. Dies kann beispielsweise bei einer Besprechung zu einem gemeinsamen Projekt der beiden Unternehmen A und B erfolgen.
Zur Prüfung der in der UserInfo enthaltenen Signatur benötigt das Endgerät UD-A-i den öffentlichen Schlüssel K_{ssb_pub} des Sicherheitsservers SS-B. Diesen erfragt es beim Sicherheitsserver SS-A in einem Schritt S305 unter Angabe der SecServerID des Sicherheitsservers SS-B. Diese SecServerID hat das Endgerät UD-A-i aus der USR_id des Endgeräts UD-B-k ermittelt, da, wie oben allgemein erläutert, die USR_id des Endgeräts UD-B-k auch die ID des Sicherheitsservers SS-B enthält, an dem dieses Endgerät registriert ist. Der Sicherheitsserver SS-A kennt den öffentlichen Schlüssel K_{ssb_pub} des Sicherheitsservers SS-B und stellt ihn dem Endgerät UD-A-i in Schritt S306 zur Verfügung, signiert mit seinem eigenen privaten Schlüssel K_{ssa_prv}. Das Endgerät UD-A-i kennt den öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A und kann sich somit in Schritt S307 von der Korrektheit des öffentlichen Schlüssels K_{ssb_pub} des Sicherheitsservers SS-B überzeugen. Das Endgerät UD-A-i prüft dann noch in Schritt S307 die in der UserInfo enthaltene Signatur. Damit überzeugt es sich von der Authentizität und Integrität der in der UserInfo enthaltenen Daten, insbesondere der USR_id des Endgeräts UD-B-k und des Namens des Benutzers. Die UserInfo kann auf dem Endgerät UD-A-i bis zum Ablauf der Gültigkeitsdauer gespeichert bleiben und für die Rechteverwaltung genutzt werden.
Beim Erzeugen des Dokuments DOC und initialen Speichern hat der Autor (Eigentümer) selbst implizit die Zugriffsrechte für sein Dokument in der Datenbank des Sicherheitsservers SS-A eingetragen bekommen. Zu diesen Rechten gehört im einfachsten Fall auch das Recht, anderen Usern bzw. Endgeräten Zugriffsrechte auf dieses Dokument einzuräumen. Der Eigentümer wählt nun auf seinem Endgerät UD-A-i andere Endgeräte aus, denen er Zugriff auf sein Dokument gewähren will. Dabei kann es sich sowohl um Endgeräte innerhalb des eigenen CKM Systems (Unternehmen A) als auch in anderen CKM Systemen (Unternehmen B) handeln, wie vorliegend um das Endgerät UD-B-k. Die Endgeräte und die jeweiligen Zugriffsrechte werden in einer geeigneten Struktur UserDevIDsAndAccessRights kodiert. Das Endgerät UD-A-i baut nun in Schritt S308 aus der eigenen USR_id, der DOC_id, der Struktur UserDevIDsAndAccessRights und einer Signatur über diese Daten ein Datenobjekt zusammen und sendet dieses in Schritt 309 an den Sicherheitsserver SS-A.
Der Sicherheitsserver SS-A prüft in Schritt S310 anhand von USR_id und DOC_id, dass ihm sowohl der Benutzer bzw. sein Endgerät UD-A-i als auch das Dokument bekannt sind, und dass dieser Benutzer berechtigt ist, die Zugriffsrechte auf dieses Dokument zu verwalten. Der Sicherheitsserver SS-A prüft auch die anderen USR_ids, die Zugriffsrechte erhalten sollen. Der Sicherheitsserver SS-A verifiziert die Signatur und stellt damit sicher, dass die Anfrage tatsächlich von dem Endgerät UD-A-i stammt.
Bei der Prüfung der anderen USR_ids muss unterschieden werden, ob es sich um Endgeräte des eigenen oder eines fremden Unternehmens handelt. Die USR_ids des eigenen Unternehmens A kann der Sicherheitsserver SS-A über Einträge in der eigenen Datenbank überprüfen. Die Prüfung einer USR_id eines fremden Unternehmens B muss durch deren Sicherheitsserver SS-B erfolgen. In dem hier beschriebenen Fall sendet der Sicherheitsserver SS-A in Schritt S311 eine Anfrage mit der USR_id des Endgeräts UD-B-k als Parameter zum Sicherheitsserver SS-B. Den zuständigen Sicherheitsserver SS-B kann der Sicherheitsserver SS-A wie oben beschrieben aus der USR_id ermitteln. Der Sicherheitsserver SS-B prüft nach Erhalt der Anfrage in Schritt S312, dass der Benutzer bzw. das Endgerät UD-B-k bei ihm registriert sind, und dass der Zustand des Endgeräts UD-B-k auf aktiv gesetzt ist, d.h. dass das Endgerät z.B. nicht als gestohlen oder verloren gemeldet wurde.
Schlägt eine dieser Prüfungen fehl, antwortet der Sicherheitsserver SS-B mit einer Fehlermeldung. Sind alle Prüfungen erfolgreich, stellt der Sicherheitsserver SS-B dem Sicherheitsserver SS-A in Schritt S313 die UserInfo des Endgeräts UD-B-k zur Verfügung, signiert mit dem privaten Schlüssel K_{ssb_prv} des Sicherheitsservers SS-B. Anders als bei Schritt S302 handelt es sich hier um eine UserInfo mit kurzer Gültigkeitsdauer, die den momentanen Zustand des Endgeräts UD-B-k repräsentiert. Der Sicherheitsserver SS-A kennt den öffentlichen Schlüssel K_{ssb_pub} des Sicherheitsservers SS-B und kann sich somit in Schritt S314 von der Korrektheit der UserInfo des Endgeräts UD-B-k überzeugen.
Im Fall einer negativen Prüfung wird die Zugriffsberechtigungsanfrage vom Sicherheitsserver SS-A mit einer Fehlermeldung an das Endgerät UD-A-i abgewiesen. Waren die Prüfungen erfolgreich, trägt der Sicherheitsserver SS-A in Schritt S315 die Zugriffsrechte in seine Datenbank ein und teilt dem Endgerät UD-A-i in Schritt S316 die erfolgreiche Ausführung mit.
Hat der Mitarbeiter des Unternehmens B mit dem Endgerät UD-B-k Zugriffsrechte auf das Dokument DOC erhalten, kann er das Dokument vom Cloudserver 50 abrufen und schließlich entschlüsseln. Im Zusammenhang mit 4 wird nachstehend ein erfindungsgemäß bevorzugter Ablauf beim Abrufen des auf dem Cloudserver 50 als Teil des Dokumentencontainers DOC_con hinterlegten Dokuments DOC durch das Endgerät UD-B-k beschrieben.
In Schritt S401 sendet das Endgerät UD-B-k an den Cloudserver 50 eine Anfrage, die die Dokumentenkennung DOC_id und DOC_verenthält. Der Cloudserver überträgt den zugehörigen Dokumentencontainer DOC_con in Schritt S402 an das Endgerät UD-B-k. Gegebenenfalls erfordert der Cloudserver 50 dazu eine Authentisierung, diese ist jedoch für die Sicherheit des Systems nicht notwendig.
Zur Prüfung der im Dokumentencontainer DOC_con enthaltenen Signatur benötigt das Endgerät UD-B-k den öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A. Diesen erfragt es in Schritt S403 beim Sicherheitsserver SS-B unter Angabe der SecServerID des Sicherheitsservers SS-A. Diese SecServerID hat das Endgerät UD-B-k dem Dokumentencontainer DOC_con entnommen. Der Sicherheitsserver SS-B kennt den öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A und stellt ihn dem Endgerät UD-B-k in Schritt S404 zur Verfügung, signiert mit seinem eigenen privaten Schlüssel K_{ssb_prv}. Das Endgerät UD-B-k kennt den öffentlichen Schlüssel K_{ssb_pub} des Sicherheitsservers SS-B und kann sich somit in Schritt S405 von der Korrektheit des öffentlichen Schlüssels K_{ssa_pub} des Sicherheitsservers SS-A überzeugen. Das Endgerät UD-B-k prüft noch im Schritt S405 die im Dokumentencontainer DOC_con enthaltene Signatur. Damit überzeugt es sich von der Authentizität und Integrität der im Dokumentencontainer enthaltenen Daten außer dem eigentlichen noch verschlüsselten Dokument. Die vollständige Überprüfung erfolgt zu einem späteren Zeitpunkt.
Im Dokumentencontainer DOC_con ist der geheime Dokumentenschlüssel K_sec mit dem öffentlichen Schlüssel des Sicherheitsservers SS-A verschlüsselt. Dies bedeutet, dass nur dieser Sicherheitsserver den Dokumentenschlüssel K_sec wieder entschlüsseln kann. Somit ist für jeden Zugriff auf dieses Dokument aus dem Cloudserver 50 eine Anfrage beim Sicherheitsserver SS-A notwendig. Das Endgerät UD-B-k schickt dazu in Schritt S406 eine Anfrage zur Übermittlung des geheimen Dokumentenschlüssels K_sec an den Sicherheitsserver SS-A, welche neben der USR_id die Kennung des Dokuments (DOC_idund DOC_ver), den verschlüsselten Dokumentenschlüssel K_sec und die Signatur enthält, welche den verschlüsselten Dokumentenschlüssel K_sec an die Kennung des Dokuments bindet.
Der Sicherheitsserver SS-A muss nun die Anfrage des Endgeräts UD-B-k prüfen und gegebenenfalls einen von diesem Endgerät entschlüsselbaren Dokumentenschlüssel K_sec bereitstellen. Dazu benötigt der Sicherheitsserver den aktuellen Status des Endgeräts UD-B-k, d.h. die Information, dass dieses Endgerät nicht gesperrt ist, und den öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts. Um diese Informationen zu erhalten, stellt der Sicherheitsserver SS-A in Schritt S407 eine entsprechende Anfrage beim Sicherheitsserver SS-B unter Angabe der USR_id des Endgeräts UD-B-k. Den zuständigen Sicherheitsserver SS-B kann der Sicherheitsserver SS-A dabei aus der USR_id ermitteln, wie oben erläutert.
Nach Erhalt der Anfrage prüft der Sicherheitsserver SS-B in Schritt S408, dass der Benutzer bzw. das Endgerät UD-B-k bei ihm registriert sind, und dass der Zustand des Endgeräts auf aktiv gesetzt ist, d.h. dass das Endgerät z.B. nicht als gestohlen oder verloren gemeldet wurde. Schlägt eine dieser Prüfungen fehl, antwortet der Sicherheitsserver SS-B mit einer Fehlermeldung. Sind alle Prüfungen erfolgreich, stellt der Sicherheitsserver SS-B dem Sicherheitsserver SS-A in Schritt S409 den öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts UD-B-k zur Verfügung, signiert mit dem privaten Schlüssel des Sicherheitsservers SS-B. Der Sicherheitsservers SS-A kennt den öffentlichen Schlüssel K_{ssb_pub} des Sicherheitsservers SS-B und kann sich somit in Schritt S410 von der Korrektheit des öffentlichen Schlüssels K_{usr_bk_pub} des Endgeräts UD-B-k überzeugen.
Noch in Schritt S410 von 4 werden vom Sicherheitsserver SS-A anhand der von dem Endgerät UD-B-k in Schritt S406 übertragenen Daten mehrere Überprüfungen durchgeführt. Zunächst prüft der Sicherheitsserver SS-A anhand der Benutzer- oder Endgerätkennung USR_id des Endgeräts UD-B-k und der Dokumentenkennung (DOC_id und DOC_ver), dass dem Sicherheitsserver SS-A das Dokument DOC bekannt ist, und dass dieser Benutzer dazu berechtigt ist, mit seinem Endgerät UD-B-k auf das Dokument DOC zuzugreifen. Der Sicherheitsserver SS-A verifiziert weiter die Signatur SIG(DOC_id∥DOC_ver∥ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), K_{ssa_prv}) und stellt damit sicher, dass der verschlüsselte Dokumentenschlüssel K_sec auch tatsächlich zu diesem Dokument DOC gehört.
Für den Fall, dass die vorstehend beschriebenen Prüfungen durch den Sicherheitsserver SS-A erfolgreich sind, entschlüsselt der Sicherheitsserver SS-A den mit dem öffentlichen Schlüssel des Sicherheitsservers SS-A verschlüsselten Teil der von dem Endgerät UD-B-k in Schritt S406 übertragenen Daten, d.h ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), um den geheimen Dokumentenschlüssel K_sec und die Hashwerte H(DOC) und H(DOC_id∥DOC_ver) zu erhalten.
Nach der Überprüfung der Korrektheit des Hashwertes über die Dokumentenkennung DOC_id ∥DOC_verwerden diese Datenelemente vom Sicherheitsserver SS-A, vorzugsweise so schnell wie möglich, wieder verschlüsselt, und zwar mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts UD-B-k, also ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{usr_bk_pub}) erzeugt. Dies hat zur Folge, dass nunmehr nur das Endgerät UD-B-k den erneut verschlüsselten Dokumentenschlüssel K_sec wieder entschlüsseln kann.
Zusätzlich signiert der Sicherheitsserver SS-A diese Datenelemente mittels seines privaten Schlüssels K_{ssa_prv}, damit sich der Benutzer des Endgeräts UD-B-k von der Unversehrtheit dieser Datenelemente überzeugen kann, d.h. der Sicherheitsserver SS-A erzeugt die folgende Signatur:

SIG(DOC_id∥DOC_ver∥ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{usr_bk_pub}), K_{ssa_prv}). Der Sicherheitsserver SS-A schickt die erneut verschlüsselten Datenelemente und die Signatur in Schritt S411 an das Endgerät UD-B-k.

Insbesondere der Schritt der Entschlüsselung mit dem privaten Schlüssel K_{ssa_prv} des Sicherheitsservers SS-A wird vorzugsweise im Hardware-Sicherheitsmodul (HSM) des Sicherheitsservers SS-A durchgeführt. Dies ist insofern vorteilhaft, als der private Schlüssel K_{ssa_prv} des Sicherheitsservers SS-A dadurch vor potentiellen Angriffen geschützt ist.
Wie bereits vorstehend erwähnt, findet die Verschlüsselung, insbesondere des geheimen Dokumentenschlüssels K_sec, durch den Sicherheitsserver SS-A mit dem öffentlichen Schlüssel des Benutzers K_{usr_bk_pub} vorzugsweise urunittelbar im Anschluss ebenfalls im HSM statt, ohne dass der geheime Dokumentenschlüssel K_sec das sichere HSM unverschlüsselt verlässt. Dies erhöht die Sicherheit für den Fall, dass ein Angriff auf den Sicherheitsserver SS-A erfolgreich ist, da der Angreifer nicht auf den geheimen Dokumentenschlüssel K_sec zugreifen kann, der im sicheren HSM nur kurzzeitig unverschlüsselt vorliegt. Ebenfalls erfolgt die Berechnung der Signatur in Schritt S410 vorzugsweise im HSM, um auch in diesem Fall den privaten Schlüssel K_{ssa_prv} des Sicherheitsservers SS-A keinen Angriffen auszusetzen.
In Schritt S412 von 4 verifiziert das Endgerät UD-B-k die Signatur SIG(DOC_id∥DOC_ver∥ENC(Ksec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{usr_bk_pub}), K_{ssa_prv}) mit dem öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A, um sich von der Authentizität und Integrität der vom Sicherheitsserver SS-A übermittelten Datenelemente zu überzeugen. Ferner verwendet das Endgerät UD-B-k seinen privaten Schlüssel K_{usr_bk_prv}, um den geheimen Dokumentenschlüssel K_sec und die mit diesem zusammen verschlüsselten Hashwerte im Klartext zu erhalten. Anschließend überprüft das Endgerät UD-B-k den Hashwert der Dokumentenkennung DOC_id ∥DOC_verund entschlüsselt mit dem geheimen Dokumentenschlüssel K_sec den Teil ENC(DOC, K_sec) des Dokumentencontainers DOC_con, der das verschlüsselte Dokument DOC enthält. Zum Nachweis der Authentizität und Integrität des entschlüsselten Dokuments DOC wird noch dessen Hashwert H(DOC) überprüft. Das nun im Klartext vorliegende Dokument DOC kann nun in dem Endgerät UD-B-k verwendet werden, beispielsweise bearbeitet und modifiziert werden.
Im Zusammenhang mit 5 wird nun ein erfindungsgemäß bevorzugter Ablauf bei der Modifizierung und nachfolgender Abspeicherung eines auf dem Cloudserver 50 gespeicherten und von dem Sicherheitsserver des Unternehmens A verwalteten Dokuments DOC durch einen Mitarbeiter des Unternehmens B beschrieben.
Das Endgerät UD-B-k eines Mitarbeiters des Unternehmens B hatte das Dokument DOC mit dem in Zusammenhang mit 4 beschriebenen Ablauf vom Cloudserver 50 heruntergeladen. Zusammen mit dem Dokument hat es sich die Dokumentenkennung DOC_id ∥DOC_vergemerkt. Aufgrund dieser Daten weiß das Endgerät UD-B-k auch, dass das Dokument auf dem Sicherheitsserver SS-A verwaltet wird.
Um eine modifizierte Version des Dokuments DOC auf dem Cloudserver 50 abspeichern zu können, benötigt das Endgerät UD-B-k den öffentlichen Schlüssel des Sicherheitsservers SS-A. Diesen erfragt es zunächst in Schritt S501 beim Sicherheitsserver SS-B unter Angabe der SecServerID des Sicherheitsservers SS-A. Diese SecServerID hat das Endgerät UD-B-k dem alten Dokumentencontainer DOC_con entnommen. Der Sicherheitsserver SS-B kennt den öffentlichen Schlüssel des Sicherheitsservers SS-A und stellt ihn dem Endgerät UD-B-k in Schritt S502 zur Verfügung, signiert mit seinem eigenen privaten Schlüssel. Das Endgerät UD-B-k kennt den öffentlichen Schlüssel des Sicherheitsservers SS-B und kann sich somit in Schritt S503 von der Korrektheit des öffentlichen Schlüssel des Sicherheitsservers SS-A überzeugen.
Für die Erstellung eines neuen Dokumentencontainers DOC_con wird eine neue Dokumentenkennung benötigt. Bei der in 5 dargestellten bevorzugten Ausführungsform wird die Dokumentenkennung dadurch geändert, dass die DOC_id beibehalten wird und eine neue Versionsnummer DOC_ver erstellt wird. Vorzugsweise wird die neue Versionsnummer DOC_vervon dem Sicherheitsserver SS-A erstellt, da dadurch verhindert werden kann, dass zwei Endgeräte, auf denen parallel an demselben Dokument DOC gearbeitet wird, dieselbe Versionsnummer DOC_verfür unterschiedliche Versionen von ein und demselben Dokument DOC erstellen.
Das Endgerät UD-B-k überträgt nun in Schritt S504 im Rahmen einer entsprechenden Anfrage die Dokumentenidentifikationsnummer DOC_id des Dokuments DOC an den Sicherheitsserver SS-A, der in Schritt S505 zunächst überprüft, ob diese Dokumentenidentifikationsnummer DOC_id ihm bekannt ist, d.h. beispielsweise ein entsprechender Eintrag in seiner Datenbank vorliegt. Ist dies der Fall, erstellt der Sicherheitsserver SS-A eine neue Versionsnummer DOC_ver, vorzugsweise indem er die bisherige Versionsnummer inkrementiert, und sendet die geänderte Versionsnummer DOC_verin Schritt S506 an das Endgerät UD-B-k zurück.
In Schritt S507 von 5 erzeugt das Endgerät UD-B-k einen neuen geheimen Dokumentenschlüssel K_sec, mit dem Teile des neuen Dokumentencontainers DOC_con erzeugt werden. Hierzu wird das bearbeitete Dokument DOC mit dem neuen geheimen Dokumentenschlüssel K_sec verschlüsselt, also ENC(DOC, K_sec) erzeugt. Zur späteren Sicherstellung der Authentizität und Integrität werden durch Anwendung einer Einwegfunktion, vorzugsweise einer Hashfunktion H die Hashwerte über das modifizierte Dokument DOC und die neue Dokumentenkennung berechnet und zusammen mit dem neuen geheimem Dokumentenschlüssel K_sec mit dem öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A verschlüsselt, d.h. $ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), K_{ssa_pub})$
Zur Vervollständigung des Dokumentencontainer DOC_con wird als weiteres Datenelement noch eine Signatur des Sicherheitsservers SS-A benötigt. Um gegenüber dem Sicherheitsserver SS-A die Korrektheit der zu signierenden Datenelemente nachzuweisen, signiert das Endgerät UD-B-k diese Datenelemente selbst mit seinem privaten Schlüssel K_{usr_bk_prv}, bevor diese an den Sicherheitsserver SS-A geschickt werden, d.h. von dem Endgerät UD-B-k wird die folgende Signatur erzeugt: $\begin{array}{l} SIG ({DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), K_{ssa_pub}), \\ K_{usr_bk_prv}) . \end{array}$
Noch in Schritt S507 erstellt das Endgerät UD-B-k aus seiner Kennung USR_id, der neue Dokumentenkennung (DOC_id∥DOC_ver), dem verschlüsselten neuen Dokumentenschlüssel K_sec und der darüber berechnete Signatur ein Datenelement $\begin{array}{l} DUP = {USR}_{id} ‖ {DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), \\ K_{ssa_pub}) ‖ SIG ({DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), \\ K_{ssa_pub}), K_{usr_bk_prv}) \end{array}$
und sendet dieses in Schritt S508 an den Sicherheitsserver SS-A.
Um die von dem Endgerät UD-B-k erhaltenen Daten signieren zu können, benötigt der Sicherheitsserver SS-A den aktuellen Status des Endgeräts UD-B-k, d.h. die Information, dass dieses Endgerät nicht gesperrt ist, und den öffentlichen Schlüssel des Endgeräts. Diese beiden Informationen erfragt er in Schritt S509 beim Sicherheitsserver SS-B unter Angabe der USR_id des Endgeräts UD-B-k. Den zuständigen Sicherheitsserver SS-B kann der Sicherheitsserver SS-A aus der USR_id ermitteln. Der Sicherheitsserver SS-B prüft in Schritt S510 nach Erhalt der Anfrage, dass der Benutzer bzw. das Endgerät UD-B-k bei ihm registriert sind, und dass der Zustand des Endgeräts auf aktiv gesetzt ist, d.h. dass das Endgerät nicht als gestohlen oder verloren gemeldet wurde.
Schlägt eine dieser Prüfungen fehl, antwortet der Sicherheitsserver SS-B mit einer Fehlermeldung. Sind alle Prüfungen erfolgreich, stellt der Sicherheitsserver SS-B dem Sicherheitsserver SS-A in Schritt S511 den öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts UD-B-k zur Verfügung, signiert mit dem privaten Schlüssel des Sicherheitsservers SS-B.
Der Sicherheitsserver SS-A kennt den öffentlichen Schlüssel des Sicherheitsservers SS-B und kann sich somit in Schritt S512 von der Korrektheit des öffentlichen Schlüssels K_{usr_bk_pub} des Endgeräts UD-B-k überzeugen.
Weiter führt der Sicherheitsserver SS-A mit dem in Schritt S508 von dem Endgerät UD-B-k erhaltenem Datenelement DUP vorzugsweise die folgenden Überprüfungen durch. Zunächst überprüft der Sicherheitsserver SS-A anhand der Benutzer- oder Endgerätkennung USR_id und der neuen Dokumentenkennung (DOC_id∥DOC_ver), dass ihm das Dokument bekannt ist und es sich um eine neue Version handelt, und dass der Benutzer bzw. dessen Endgerät dazu berechtigt ist, das geänderte Dokument DOC auf dem Cloudserver 50 abzulegen. Ferner verifiziert der Sicherheitsserver SS-A die im Datenelement DUP enthaltene Signatur und stellt damit sicher, dass das Datenelement tatsächlich von dem Endgerät UD-B-k stammt. Mit seinem privaten Schlüssel K_{ssa_prv} entschlüsselt der Sicherheitsserver SS-A den neuen Dokumentenschlüssel K_sec und die Hashwerte über das geänderte Dokument DOC und die geänderte Dokumentenkennung DOC_id∥DOC_ver. Die Prüfung des Hashwerts über die geänderte Dokumentenkennung DOC_id∥DOC_verist gemäß bevorzugter Ausführungsformen der Erfindung für die Sicherheit des Systems vorteilhaft, da sich ansonsten ein Endgerät unberechtigt Zugang zu einem fremden Dokument verschaffen könnte.
Falls die vorstehend beschriebenen Prüfungen erfolgreich waren, ersetzt der Sicherheitsserver SS-A in seinem Datenbankeintrag zu der Dokumentenidentifikationsnummer DOC_id die bisherige Versionsnummer DOC_verdurch die neue Versionsnummer DOC_verund erstellt mit seinem privaten Schlüssel K_{ssa_prv} die für den Dokumentencontainer benötigte Signatur:

SIG(DOC_id∥DOC_ver∥ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), K_{ssa_prv}). Diese Signatur schickt der Sicherheitsserver SS-A in Schritt S513 zurück an das Endgerät UD-B-k, das sich in Schritt S514 durch Überprüfung dieser Signatur mittels des öffentlichen Schlüssels K_{ssa_pub} des Sicherheitsservers SS-A von der Korrektheit der mit der Signatur erfassten Datenelemente überzeugen kann. Den dazu benötigten öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A hat das Endgerät UD-B-k in Schritt S502 von dem Sicherheitsserver SS-B erhalten. Statt die bisherige Versionsnummer DOC_ver durch die neue Versionsnummer DOC_verzu ersetzen, kann der Sicherheitsserver SS-A auch die neue Versionsnummer DOC_verzusammen mit der bisherigen Versionsnummer DOC_verspeichern, damit es möglich ist, dass auf alte Versionen weiterhin zugegriffen wird.

Neben der Überprüfung der vom Sicherheitsserver SS-A übermittelten Signatur kombiniert das Endgerät UD-B-k in Schritt S514 die Signatur mit den bereits vorliegenden Datenelementen zum neuen Dokumentencontainer DOC_con, so dass der vollständige an den Cloudserver 50 zu übertragene neue Dokumentencontainer DOC_con vorzugsweise in der folgenden Form vorliegt: $\begin{matrix} {DOC}_{con} = {DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (DOC {,K}_{sec}) ‖ \\ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), K_{ssa_pub}) ‖ \\ SIG ({DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), \\ K_{ssa_pub}), K_{ssa_prv}) \end{matrix}$
Bei dem neuen Dokumentencontainer sind gegenüber dem im Zusammenhang mit den 3 und 4 beschriebenen bisherigen Dokumentencontainer die Versionsnummer DOC_ver, das Dokument DOC und der Dokumentschlüssel K_sec sowie die daraus abgeleiteten Datenelemente geändert.
In Schritt S515 von 5 sendet das Endgerät UD-B-k den neuen Dokumentencontainer DOC_con an den Cloudserver 50. Dieser speichert den Dokumentencontainer DOC_con und bestätigt dies dem Endgerät UD-B-k mittels einer Bestätigungsmeldung in Schritt S516. Dabei kann der neue Dokumentencontainer den bisher auf dem Cloudserver 50 hinterlegten Dokumentencontainer ersetzen oder alternativ neben dem bisherigen Dokumentencontainer auf dem Cloudserver 50 hinterlegt werden, so dass auf beide Versionen des Dokuments zugegriffen werden kann.
Bei der in Zusammenhang mit 4 und 5 beschriebenen Vorgehensweise kommuniziert ein Endgerät eines Unternehmens, hier des Unternehmens B, direkt mit dem Sicherheitsserver eines anderen Unternehmens, hier des Unternehmens A. Diese Verfahrensvariante wird daher im Rahmen dieser Beschreibung als direkte Variante bezeichnet.
Die Kopplung mehrerer CKM Systeme unterschiedlicher Unternehmen kann allerdings auch in einer Weise umgesetzt werden, bei der die Endgeräte eines Unternehmens nur mit dem Sicherheitsserver des eigenen Unternehmens kommunizieren. Für den Zugriff auf ein Dokument eines anderen Unternehmens kommuniziert dann der eigene Sicherheitsserver mit dem Sicherheitsserver des anderen Unternehmens. Diese Verfahrensvariante wird im Rahmen dieser Beschreibung als indirekte Variante bezeichnet. Sie hat gegenüber der oben beschriebenen direkten Variante Vorteile, wenn einzelne CKM Systeme, jeweils bestehend aus einem Sicherheitsserver und den zugehörigen Endgeräten, an ihren Außengrenzen durch Sicherheitsmaßnahmen wie Firewalls geschützt werden. In der indirekten Variante muss dann nur die Kommunikation zwischen den Sicherheitsservern durch die Firewalls freigeschaltet werden. In der direkten Variante muss dagegen auch fremden Endgeräten die Kommunikation durch die Firewalls gestattet werden.
Nachfolgend wird die Vorgehensweise bei der indirekten Variante genauer beschrieben. Wie aus der Darstellung der 2 und 3 und der zugehörigen Beschreibung ergibt, ist beim Erzeugen und initialen Abspeichern eines neuen Dokuments auf dem Cloudserver 50 und beim Zuweisen oder Entziehen von Zugriffsrechten auf ein Dokument an andere Benutzer ohnehin keine Kommunikation eines Endgerät eines Unternehmens mit dem Sicherheitsserver eines anderen Unternehmens erforderlich. Diese Verfahren sind in der indirekten Variante daher identisch mit der direkten Variante.
Im Zusammenhang mit 6 wird nachstehend ein erfindungsgemäß bevorzugter Ablauf beim Abrufen eines auf dem Cloudserver 50 als Teil des Dokumentencontainers DOC_con hinterlegten und von einem Mitarbeiter des Unternehmens A erstellten Dokuments DOC durch das Endgerät UD-B-k in der indirekten Variante beschrieben.
Wie bei 4 wird davon ausgegangen, dass der Mitarbeiter des Unternehmens B mit dem Endgerät UD-B-k Zugriffsrechte auf das von einem Mitarbeiter des Unternehmens A erstellte Dokument DOC erhalten hat, beispielsweise durch das in Zusammenhang mit 3 beschriebene Verfahren.
In Schritt S601 sendet das Endgerät UD-B-k an den Cloudserver 50 eine Anfrage, die die Dokumentenkennung DOC_id und DOC_verenthält. Der Cloudserver überträgt den zugehörigen Dokumentencontainer DOC_con in Schritt S602 an das Endgerät UD-B-k. Gegebenenfalls erfordert der Cloudserver 50 dazu eine Authentisierung, diese ist jedoch für die Sicherheit des Systems nicht notwendig.
Zur Prüfung der im Dokumentencontainer DOC_con enthaltenen Signatur benötigt das Endgerät UD-B-k den öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A. Diesen erfragt es in Schritt S603 beim Sicherheitsserver SS-B unter Angabe der SecServerID des Sicherheitsservers SS-A. Diese SecServerID hat das Endgerät UD-B-k dem Dokumentencontainer DOC_con entnommen. Der Sicherheitsserver SS-B kennt den öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A und stellt ihn dem Endgerät UD-B-k in Schritt S604 zur Verfügung, signiert mit seinem eigenen privaten Schlüssel K_{ssb_prv}. Das Endgerät UD-B-k kennt den öffentlichen Schlüssel K_{ssb_pub} des Sicherheitsservers SS-B und kann sich somit in Schritt S605 von der Korrektheit des öffentlichen Schlüssels K_{ssa_pub} des Sicherheitsservers SS-A überzeugen. Das Endgerät UD-B-k prüft noch im Schritt S605 die im Dokumentencontainer DOC_con enthaltene Signatur. Damit überzeugt es sich von der Authentizität und Integrität der im Dokumentencontainer enthaltenen Daten außer dem eigentlichen noch verschlüsselten Dokument. Die vollständige Überprüfung erfolgt zu einem späteren Zeitpunkt.
Im Dokumentencontainer DOC_con ist der geheime Dokumentenschlüssel K_sec mit dem öffentlichen Schlüssel des Sicherheitsservers SS-A verschlüsselt. Dies bedeutet, dass nur dieser Sicherheitsserver den Dokumentenschlüssel K_sec wieder entschlüsseln kann. Somit ist für jeden Zugriff auf dieses Dokument aus dem Cloudserver 50 eine zumindest indirekte Anfrage beim Sicherheitsserver SS-A notwendig.
Das Endgerät UD-B-k schickt dazu in Schritt S606 zunächst eine entsprechende Anfrage zur Übermittlung des geheimen Dokumentenschlüssels K_sec an den Sicherheitsserver SS-B des eigenen Unternehmens, welche neben der USR_id die Kennung des Dokuments (DOC_id und DOC_ver), den verschlüsselten Dokumentenschlüssel K_sec und die Signatur enthält, welche den verschlüsselten Dokumentenschlüssel K_sec an die Kennung des Dokuments bindet.
Nach dem Empfang führt der Sicherheitsserver SS-B in Schritt S607 folgende Prüfungen durch. Anhand der DOC_id erkennt der Sicherheitsserver SS-B, dass es sich um ein Dokument handelt, welches auf dem Sicherheitsserver SS-A verwaltet wird. Der Sicherheitsserver SS-B kennt den öffentlichen Schlüssel des Sicherheitsservers SS-A und kann somit die in der Anfrage enthaltene Signatur verifizieren. Der Sicherheitsserver SS-B prüft außerdem, dass der Benutzer bzw. das Endgerät UD-B-k bei ihm registriert sind, und dass der Zustand des Endgeräts auf aktiv gesetzt ist, d.h. dass das Endgerät z.B. nicht als gestohlen oder verloren gemeldet wurde.
Schlägt eine dieser Prüfungen fehl, antwortet der Sicherheitsserver SS-B mit einer Fehlermeldung an das Endgerät UD-B-k. Sind alle Prüfungen erfolgreich, leitet der Sicherheitsserver SS-B die Anfrage zur Übermittlung des geheimen Dokumentenschlüssels K_sec in Schritt S608 an den Sicherheitsserver SS-A weiter. Zusätzlich enthält diese Nachricht auch den öffentlichen Schlüssel des Endgeräts UD-B-k, signiert mit dem privaten Schlüssel des Sicherheitsservers SS-B. Diesen öffentlichen Schlüssel des Endgeräts UD-B-k hat der Sicherheitsserver SS-B in seiner Datenbank gespeichert.
Der Sicherheitsserver SS-A muss nun die Anfrage des Sicherheitsservers SS-B prüfen und gegebenenfalls einen von dem Endgerät UD-B-k entschlüsselbaren Dokumentenschlüssel Ksec bereitstellen. Dazu benötigt der Sicherheitsserver den aktuellen Status des Endgeräts UD-B-k, d.h. die Information, dass dieses Endgerät nicht gesperrt ist, und den öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts. Den öffentlichen Schlüssel K_{usr_bk_pub} hat der Sicherheitsserver SS-A vom Sicherheitsserver SS-B mit der Nachricht in Schritt S608 erhalten, signiert mit dem privaten Schlüssel des Sicherheitsservers SS-B. Der Sicherheitsserver SS-A kennt den öffentlichen Schlüssel des Sicherheitsservers SS-B und kann sich somit in Schritt S609 von der Korrektheit des öffentlichen Schlüssels des Endgeräts UD-B-k überzeugen. Der aktive Status des Endgeräts UD-B-k ist Voraussetzung dafür, dass der Sicherheitsservers SS-B den öffentlichen Schlüssel des Endgeräts UD-B-k signiert zur Verfügung stellt und somit in dieser Nachricht implizit enthalten.
Noch in Schritt S609 von 6 werden vom Sicherheitsserver SS-A anhand der vom Sicherheitsserver SS-B in Schritt S608 weitergeleiteten Daten mehrere Überprüfungen durchgeführt. Zunächst prüft der Sicherheitsserver SS-A anhand der Benutzer- oder Endgerätkennung USR_id des Endgeräts UD-B-k und der Dokumentenkennung (DOC_id und DOC_ver), dass dem Sicherheitsserver SS-A das Dokument DOC bekannt ist, und dass dieser Benutzer dazu berechtigt ist, mit seinem Endgerät UD-B-k auf das Dokument DOC zuzugreifen. Der Sicherheitsserver SS-A verifiziert weiter die Signatur SIG(DOC_id∥DOC_ver∥ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), K_{ssa_prv}) und stellt damit sicher, dass der verschlüsselte Dokumentenschlüssel K_sec auch tatsächlich zu diesem Dokument DOC gehört.
Für den Fall, dass die vorstehend beschriebenen Prüfungen durch den Sicherheitsserver SS-A erfolgreich sind, entschlüsselt der Sicherheitsserver SS-A den mit dem öffentlichen Schlüssel des Sicherheitsservers SS-A verschlüsselten Teil der vom Sicherheitsserver SS-B in Schritt S608 weitergeleiteten Daten, d.h ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), um den geheimen Dokumentenschlüssel K_sec und die Hashwerte H(DOC) und H(DOC_id∥DOC_ver) zu erhalten.
Nach der Überprüfung der Korrektheit des Hashwertes über die Dokumentenkennung DOC_id ∥DOC_verwerden diese Datenelemente vom Sicherheitsserver SS-A, vorzugsweise so schnell wie möglich, wieder verschlüsselt, und zwar mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts UD-B-k, also ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{usr_bk_pub}) erzeugt. Dies hat zur Folge, dass nunmehr nur das Endgerät UD-B-k den erneut verschlüsselten Dokumentenschlüssel K_sec wieder entschlüsseln kann.
Zusätzlich signiert der Sicherheitsserver SS-A diese Datenelemente mittels seines privaten Schlüssels K_{ssa_prv}, damit sich der Benutzer des Endgeräts UD-B-k von der Unversehrtheit dieser Datenelemente überzeugen kann, d.h. der Sicherheitsserver SS-A erzeugt die folgende Signatur:

SIG(DOC_id∥DOC_ver∥ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{usr_bk_pub}), K_{ssa_prv}). Der Sicherheitsserver SS-A schickt die erneut verschlüsselten Datenelemente und die Signatur in Schritt S610 an den Sicherheitsserver SS-B. Der Sicherheitsserver SS-B überprüft diese Nachricht in Schritt S611 und leitet sie in Schritt S612 an das Endgerät UD-B-k weiter.

In Schritt S613 von 6 verifiziert nun das Endgerät UD-B-k die Signatur SIG(DOC_id∥DOC_ver∥ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{usr_bk_pub}), K_{ssa_prv}) mit dem öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A, um sich von der Authentizität und Integrität der vom Sicherheitsserver SS-A übermittelten Datenelemente zu überzeugen. Den öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A hat das Endgerät UD-B-k im Schritt S604 vom Sicherheitsserver SS-B erhalten.
Ferner verwendet das Endgerät UD-B-k seinen privaten Schlüssel K_{usr_bk_prv}, um den geheimen Dokumentenschlüssel K_sec und die mit diesem zusammen verschlüsselten Hashwerte im Klartext zu erhalten. Anschließend überprüft das Endgerät UD-B-k den Hashwert der Dokumentenkennung DOC_id ∥DOC_verund entschlüsselt mit dem geheimen Dokumentenschlüssel K_sec den Teil ENC(DOC, K_sec) des Dokumentencontainers DOC_con, der das verschlüsselte Dokument DOC enthält. Zum Nachweis der Authentizität und Integrität des entschlüsselten Dokuments DOC wird noch dessen Hashwert H(DOC) überprüft. Das nun im Klartext vorliegende Dokument DOC kann nun in dem Endgerät UD-B-k verwendet werden, beispielsweise bearbeitet und modifiziert werden.
Im Zusammenhang mit 7 wird nun ein erfindungsgemäß bevorzugter Ablauf bei der Modifizierung und nachfolgender Abspeicherung eines auf dem Cloudserver 50 gespeicherten und von dem Sicherheitsserver des Unternehmens A verwalteten Dokuments DOC durch einen Mitarbeiter des Unternehmens B in der indirekten Variante beschrieben.
Das Endgerät UD-B-k eines Mitarbeiters des Unternehmens B hatte das Dokument DOC mit dem in Zusammenhang mit 6 beschriebenen Ablauf vom Cloudserver 50 heruntergeladen. Zusammen mit dem Dokument hat es sich die Dokumentenkennung DOC_id ∥DOC_vergemerkt. Aufgrund dieser Daten weiß das Endgerät UD-B-k auch, dass das Dokument auf dem Sicherheitsserver SS-A verwaltet wird.
Um eine modifizierte Version des Dokuments DOC auf dem Cloudserver 50 abspeichern zu können, benötigt das Endgerät UD-B-k den öffentlichen. Schlüssel des Sicherheitsservers SS-A. Diesen erfragt es zunächst in Schritt S701 beim Sicherheitsserver SS-B unter Angabe der SecServerID des Sicherheitsservers SS-A. Diese SecServerID hat das Endgerät UD-B-k dem alten Dokumentencontainer DOC_con entnommen. Der Sicherheitsserver SS-B kennt den öffentlichen Schlüssel des Sicherheitsservers SS-A und stellt ihn dem Endgerät UD-B-k in Schritt S702 zur Verfügung, signiert mit seinem eigenen privaten Schlüssel. Das Endgerät UD-B-k kennt den öffentlichen Schlüssel des Sicherheitsservers SS-B und kann sich somit in Schritt S703 von der Korrektheit des öffentlichen Schlüssel des Sicherheitsservers SS-A überzeugen.
Für die Erstellung eines neuen Dokumentencontainers DOC_con wird eine neue Dokumentenkennung benötigt. Bei der in 7 dargestellten bevorzugten Ausführungsform wird die Dokumentenkennung dadurch geändert, dass die DOC_id beibehalten wird und eine neue Versionsnummer DOC_ver erstellt wird. Vorzugsweise wird die neue Versionsnummer DOC_vervon dem Sicherheitsserver SS-A erstellt, da dadurch verhindert werden kann, dass zwei Endgeräte, auf denen parallel an demselben Dokument DOC gearbeitet wird, dieselbe Versionsnummer DOC_verfür unterschiedliche Versionen von ein und demselben Dokument DOC erstellen.
Das Endgerät UD-B-k überträgt nun in Schritt S704 im Rahmen einer entsprechenden Anfrage die Dokumentenidentifikationsnummer DOC_id des Dokuments DOC an den Sicherheitsserver SS-B des eigenen Unternehmens, der die Anfrage in Schritt S705 an den Sicherheitsserver SS-A weiterleitet. Der Sicherheitsserver SS-A prüft in Schritt S706 zunächst, ob diese Dokumentenidentifikationsnummer DOC_id ihm bekannt ist, d.h. beispielsweise ein entsprechender Eintrag in seiner Datenbank vorliegt. Ist dies der Fall, erstellt der Sicherheitsserver SS-A eine neue Versionsnummer DOC_ver, vorzugsweise indem er die bisherige Versionsnummer inkrementiert, und sendet die geänderte Versionsnummer DOC_verin Schritt S707 an den Sicherheitsserver SS-B, der diese in Schritt S708 an das Endgerät UD-B-k weiterleitet.
In Schritt S709 von 7 erzeugt das Endgerät UD-B-k einen neuen geheimen Dokumentenschlüssel K_sec, mit dem Teile des neuen Dokumentencontainers DOC_con erzeugt werden. Hierzu wird das bearbeitete Dokument DOC mit dem neuen geheimen Dokumentenschlüssel K_sec verschlüsselt, also ENC(DOC, K_sec) erzeugt. Zur späteren Sicherstellung der Authentizität und Integrität werden durch Anwendung einer Einwegfunktion, vorzugsweise einer Hashfunktion H die Hashwerte über das modifizierte Dokument DOC und die neue Dokumentenkennung berechnet und zusammen mit dem neuen geheimem Dokumentenschlüssel K_sec mit dem öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A verschlüsselt, d.h. $ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), K_{ssa_pub}) erzeugt .$
Zur Vervollständigung des Dokumentencontainer DOC_con wird als weiteres Datenelement noch eine Signatur des Sicherheitsservers SS-A benötigt. Um gegenüber dem Sicherheitsserver SS-A die Korrektheit der zu signierenden Datenelemente nachzuweisen, signiert das Endgerät UD-B-k diese Datenelemente selbst mit seinem privaten Schlüssel K_{usr_bk_prv}, bevor diese an den Sicherheitsserver SS-B des eigenen Unternehmens B geschickt werden, d.h. von dem Endgerät UD-B-k wird die folgende Signatur erzeugt: $\begin{array}{l} SIG ({DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), K_{ssa_pub}), \\ K_{usr_bk_prv}) . \end{array}$
Noch in Schritt S709 erstellt das Endgerät UD-B-k aus seiner Kennung USR_id, der neue Dokumentenkennung (DOC_id ∥ DOC_ver), dem verschlüsselten neuen Dokumentenschlüssel K_sec und der darüber berechnete Signatur ein Datenelement $\begin{array}{l} DUP = {USR}_{id} ‖ {DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), \\ K_{ssa_pub}) ‖ SIG ({DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), \\ K_{ssa_pub}), K_{usr_bk_prv}) \end{array}$
und sendet dieses in Schritt S710 an den Sicherheitsserver SS-B des eigenen Unternehmens B.
Nach dem Empfang führt der Sicherheitsserver SS-B in Schritt S711 folgende Prüfungen durch. Der Sicherheitsserver prüft, dass der Benutzer bzw. das Endgerät UD-B-k bei ihm registriert sind, und dass der Zustand des Endgeräts auf aktiv gesetzt ist, d.h. dass das Endgerät z.B. nicht als gestohlen oder verloren gemeldet wurde. Der Sicherheitsserver SS-B kennt den öffentlichen Schlüssel des Endgeräts UD-B-k und kann somit die im Datenelement DUP enthaltene Signatur verifizieren. Schlägt eine dieser Prüfungen fehl, antwortet der Sicherheitsserver SS-B mit einer Fehlermeldung an das Endgerät UD-B-k. Anhand der DOC_id erkennt der Sicherheitsserver SS-B, dass es sich um ein Dokument handelt, welches auf dem Sicherheitsserver SS-A verwaltet wird. Sind alle Prüfungen erfolgreich, leitet der Sicherheitsserver SS-B die Anfrage mit den in Schritt S710 übermittelten Daten in Schritt S712 an den Sicherheitsserver SS-A weiter. Zusätzlich enthält die in Schritt S712 an den Sicherheitsserver SS-A übermittelte Nachricht auch den öffentlichen Schlüssel des Endgeräts UD-B-k, signiert mit dem privaten Schlüssel des Sicherheitsservers SS-B. Diesen öffentlichen Schlüssel des Endgeräts UD-B-k hat der Sicherheitsserver SS-B in seiner Datenbank gespeichert.
Der Sicherheitsserver SS-A muss nun die Anfrage des Sicherheitsservers SS-B prüfen und gegebenenfalls einen von dem Endgerät UD-B-k entschlüsselbaren Dokumentenschlüssel K_sec bereitstellen. Dazu benötigt der Sicherheitsserver den aktuellen Status des Endgeräts UD-B-k, d.h. die Information, dass dieses Endgerät nicht gesperrt ist, und den öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts. Diesen öffentlichen Schlüssel K_{usr_bk_pub} hat der Sicherheitsserver SS-A vom Sicherheitsserver SS-B mit der Nachricht in Schritt S712 erhalten, signiert mit dem privaten Schlüssel des Sicherheitsservers SS-B. Der Sicherheitsserver SS-A kennt den öffentlichen Schlüssel des Sicherheitsservers SS-B und kann sich somit in Schritt S713 von der Korrektheit des öffentlichen Schlüssels des Endgeräts UD-B-k überzeugen. Der aktive Status des Endgeräts UD-B-k ist Voraussetzung dafür, dass der Sicherheitsserver SS-B den öffentlichen Schlüssel des Endgeräts UD-B-k signiert zur Verfügung stellt und somit in dieser Nachricht implizit enthalten.
Weiter führt der Sicherheitsserver SS-A mit dem in Schritt S712 von dem Sicherheitsserver SS-B erhaltenem Datenelement DUP vorzugsweise die folgenden Überprüfungen durch. Zunächst überprüft der Sicherheitsserver SS-A anhand der Benutzer- oder Endgerätkennung USR_id und der neuen Dokumentenkennung (DOC_id ∥ DOC_ver), dass ihm das Dokument bekannt ist und es sich um eine neue Version handelt, und dass der Benutzer bzw. dessen Endgerät dazu berechtigt ist, das geänderte Dokument DOC auf dem Cloudserver 50 abzulegen. Ferner verifiziert der Sicherheitsserver SS-A die im Datenelement DUP enthaltene Signatur und stellt damit sicher, dass das Datenelement tatsächlich von dem Endgerät UD-B-k stammt. Mit seinem privaten Schlüssel K_{ssa_prv} entschlüsselt der Sicherheitsserver SS-A den neuen Dokumentenschlüssel K_sec und die Hashwerte über das geänderte Dokument DOC und die geänderte Dokumentenkennung DOC_id ∥ DOC_ver. Die Prüfung des Hashwerts über die geänderte Dokumentenkennung DOC_id ∥ DOC_ver ist gemäß bevorzugter Ausführungsformen der Erfindung für die Sicherheit des Systems vorteilhaft, da sich ansonsten ein Endgerät unberechtigt Zugang zu einem fremden Dokument verschaffen könnte.
Falls die vorstehend beschriebenen Prüfungen erfolgreich waren, ersetzt der Sicherheitsserver SS-A in seinem Datenbankeintrag zu der Dokumentenidentifikationsnummer DOC_id die bisherige Versionsnummer DOC_ver durch die neue Versionsnummer DOC_ver und erstellt mit seinem privaten Schlüssel K_{ssa_prv} die für den Dokumentencontainer benötigte Signatur:

SIG(DOC_id∥DOC_ver ∥ENC(K_sec∥H(DOC)∥H(DOC_id∥DOC_ver), K_{ssa_pub}), K_{ssa_prv}). Diese Signatur schickt der Sicherheitsserver SS-A in Schritt S714 zurück an den Sicherheitsserver SS-B, der diese Nachricht in Schritt S715 überprüft und bei erfolgreicher Prüfung in Schritt S716 an das Endgerät UD-B-k weiterleitet. Das Endgerät UD-B-k überzeugt sich in Schritt S717 durch Überprüfung der Signatur mittels des öffentlichen Schlüssels K_{ssa_pub} des Sicherheitsservers SS-A von der Korrektheit der mit der Signatur erfassten Datenelemente. Den dazu benötigten öffentlichen Schlüssel K_{ssa_pub} des Sicherheitsservers SS-A hat das Endgerät UD-B-k in Schritt S702 von dem Sicherheitsserver SS-B erhalten. Statt die bisherige Versionsnummer DOC_ver durch die neue Versionsnummer DOC_ver zu ersetzen, kann der Sicherheitsserver SS-A auch die neue Versionsnummer DOC_ver zusammen mit der bisherigen Versionsnummer DOC_ver speichern, damit es möglich ist, dass auf alte Versionen weiterhin zugegriffen wird.

Neben der Überprüfung der vom Sicherheitsserver SS-A übermittelten Signatur kombiniert das Endgerät UD-B-k in Schritt S717 die Signatur mit den bereits vorliegenden Datenelementen zum neuen Dokumentencontainer DOC_con, so dass der vollständige an den Cloudserver 50 zu übertragene neue Dokumentencontainer DOC_con vorzugsweise in der folgenden Form vorliegt: $\begin{matrix} {DOC}_{con} = {DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (DOC, K_{sec}) ‖ \\ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), K_{ssa_pub}) ‖ \\ SIG ({DOC}_{id} ‖ {DOC}_{ver} ‖ ENC (K_{sec} ‖ H (DOC) ‖ H ({DOC}_{id} ‖ {DOC}_{ver}), \\ K_{ssa_pub}), K_{ssa_prv}) \end{matrix}$
Bei dem neuen Dokumentencontainer sind gegenüber dem im Zusammenhang mit der 6 beschriebenen bisherigen Dokumentencontainer die Versionsnummer DOC_ver, das Dokument DOC und der Dokumentschlüssel K_sec sowie die daraus abgeleiteten Datenelemente geändert.
In Schritt S718 von 7 sendet das Endgerät UD-B-k den neuen Dokumentencontainer DOC_con an den Cloudserver 50. Dieser speichert den Dokumentencontainer DOC_con und bestätigt dies dem Endgerät UD-B-k mittels einer Bestätigungsmeldung in Schritt S719. Dabei kann der neue Dokumentencontainer den bisher auf dem Cloudserver 50 hinterlegten Dokumentencontainer ersetzen oder alternativ neben dem bisherigen Dokumentencontainer auf dem Cloudserver 50 hinterlegt werden, so dass auf beide Versionen des Dokuments zugegriffen werden kann.
Nachstehend werden einige der im Zusammenhang mit den 3 bis 7 beschriebenen unterschiedlichen Aspekte der Erfindung noch einmal näher erläutert sowie einige erfindungsgemäße Varianten beschrieben.
Die Dokumentenidentifikationsnummer DOC_id ist ein eindeutiger Identifier für ein Dokument DOC, das in verschiedenen Versionen vorliegen kann. Alle Versionen dieses Dokuments DOC besitzen die gleiche DOC_id. Die Versionsnummer DOC_ver kennzeichnet eindeutig eine bestimmte Version des Dokuments DOC.
Es ist erfindungsgemäß vorstellbar, dass der Cloudserver 50 unterschiedliche Versionen eines Dokuments DOC als zusammengehörige oder als unabhängige Dokumente betrachtet. Falls der Cloudserver 50 unterschiedliche Versionen eines Dokuments DOC zusammenhängend verwaltet, so sind erfindungsgemäß weitere sinnvolle Funktionen des Cloudservers 50 möglich, wie z.B. die Abfrage einer Liste mit allen vorliegenden Versionsnummern DOC_ver zu einer Dokumentenidentifikationsnummer DOC_id, die Abfrage der neuesten Versionsnummer zu einer DOC_id und das Lesen der neuesten Version eines Dokuments mit einer bestimmten DOC_id.
Der Fachmann wird erkennen, dass die Erfindung bis auf die eindeutige Identifizierung eines bestimmten Dokuments sowie einer bestimmten Version dieses Dokuments keine Bedingungen an die Ausgestaltung der Dokumentenidentifikationsnummer DOC_id und der Versionsnummer DOC_ver stellt. Beispielsweise kann es sich bei der Dokumentenidentifikationsnummer DOC_id und der Versionsnummer DOC_ver statt um Zahlen um beliebige (jedoch) eindeutige Zeichenfolgen handeln. Mögliche Formate für die Dokumentenidentifikationsnummer sind z.B. Dezimalzahlen, Text, Binärzahlen, URLs (Universal Resource Locators), UUIDs (Universal Unique Identifiers).
Ferner stellt die Erfindung keine Bedingungen an die Länge der Dokumentenidentifikationsnummer DOC_id und der Versionsnummer DOC_ver. Gemäß erfindungsgemäßer Varianten ist es vorstellbar, dass eine Maximallänge für die Dokumentenidentifikationsnummer DOC_id und/ oder die Versionsnummer DOC_ver definiert werden. Bei diesen erfindungsgemäßen Varianten kann es vorteilhaft sein, die vorstehend im Zusammenhang mit den 2 bis 7 beschriebenen Verfahren insofern zu vereinfachen, als anstatt des Hashwerts der Dokumentenidentifikationsnummer DOC_id und/ oder der Versionsnummer DOC_ver die Dokumentenidentifikationsnummer DOC_id und/oder die Versionsnummer DOC_ver direkt verwendet werden können.
Weiter sind erfindungsgemäß unterschiedliche Varianten denkbar, wie eindeutige Dokumentenidentifikationsnummern DOC_id und/oder Versionsnummern DOC_ver erzeugt werden können. Die Dokumentenidentifikationsnummern DOCid und/ oder Versionsnummern DOC_ver können beispielsweise von einem Sicherheitsserver SS-A, wie vorstehend beschrieben, dem Cloudserver 50 und/oder einem Endgerät erzeugt werden. Vorzugsweise werden dabei fortlaufenden Nummern verwendet, ggf. in Verbindung mit einer Identifikationsnummer der erzeugenden Stelle. Alternativ können zufällig erzeugte Werte vergeben werden, sofern der Werteraum und der benutzte Zufallsgenerator die Eindeutigkeit der Werte mit einer hinreichenden Wahrscheinlichkeit garantieren können. Bei der Versionsnummer DOC_ver handelt es sich vorzugsweise um einen numerischen Wert, der bei 0 startet und mit jeder neuen Version um 1 erhöht wird.
Wie vorstehend bereits beschrieben, sind vorzugsweise auf dem Sicherheitsserver eines Unternehmens, beispielsweise in Form der Datenstruktur USRS_acls, die Zugriffsrechte der Benutzer auf jeweilige Dokumente hinterlegt, welche ihrerseits in Form von Dokumentencontainern DOC_con auf dem Cloudserver 50 abgelegt sind. Erfindungsgemäß können auf dem Sicherheitsserver eines Unternehmens eine Vielzahl unterschiedlicher Rechte definiert sein. Bespiele für typische Rechte sind das Anlegen eines neuen Dokuments DOC, das Lesen, Verändern und Löschen eines auf dem Cloudserver 50 hinterlegten Dokuments sowie das Verwalten von Zugriffsrechten für andere Benutzer bzw. Endgeräte.
Bei einfachen erfindungsgemäßen Varianten ist es denkbar, dass die Zugriffsrechte auf ein Dokument DOC für alle Versionen dieses Dokuments gleich sind. Erfindungsgemäß sind jedoch auch komplexere Varianten der Zugriffsrechteverwaltung denkbar, bei denen Benutzer für unterschiedliche Versionen eines Dokuments DOC unterschiedliche Zugriffsrechte erhalten können. Bei derartigen Varianten speichert der Sicherheitsserver vorzugsweise Informationen darüber ab, welcher Benutzer (bzw. welches Endgerät) der Ersteller eines geänderten Dokuments DOC und damit einer neuen Versionsnummer DOC_ver ist.
Bei den hier beschriebenen bevorzugten Varianten läuft die Verwaltung von Zugriffsrechten unabhängig vom Cloudserver 50, da diese lediglich das Zusammenwirken von Sicherheitsservern SS-A, SS-B und Endgeräten regeln. Zusätzlich kann aber auch auf dem Cloudserver 50 eine eigene Verwaltung von Zugriffsrechten implementiert sein, über die das Schreiben und Lesen der Dokumentencontainer DOC_con durch ein Endgerät kontrolliert werden kann.
Einer der vielen Vorteile der Erfindung besteht darin, dass ein auf dem Cloudserver 50 hinterlegter Dokumentencontainer DOC_con weder direkte Informationen (z.B. in Form der Benutzer- oder Endgerätkennung USR_id) noch indirekte Informationen (z.B. in Form einer mit dem privaten Schlüssel eines Benutzers erstellten Signatur) über den Autor des Dokuments enthalten. Erfindungsgemäß sind derartige Informationen über den Autor eines Dokuments vorzugsweise auf dem Sicherheitsserver eines Unternehmens hinterlegt, und zwar im Zusammenhang mit der Dokumentenidentifikationsnummer DOC_id und der Versionsnummer DOC_ver eines Dokuments DOC.
Wie bereits vorstehend beschrieben, wird die Authentizität und Integrität eines Dokumentencontainers DOC_con vorzugsweise durch eine vom Sicherheitsserver des Unternehmens mit seinem privaten Schlüssel erstellte Signatur geschützt. Vorzugsweise erstreckt sich diese Signatur jedoch nicht über alle im Dokumentencontainer DOC_con enthaltenen Daten, sondern nur über die Dokumentenkennung (DOC_id und DOC_ver) und die verschlüsselten Datenelemente (Dokumentenschlüssel K_sec und Hashwerte) . Vorzugsweise fließt das mit dem Dokumentenschlüssel K_sec verschlüsselte Dokument DOC selbst nicht direkt in die Signaturberechnung ein, da es auch nicht im Rahmen der Anfrage von einem Endgerät an den Sicherheitsserver zum Ablegen eines neuen bzw. eines modifizierten Dokuments DOC auf dem Cloudserver 50 an den Sicherheitsserver übertragen wird. Die Authentizität und Integrität des Dokuments DOC wird durch die Signatur jedoch indirekt abgesichert, da gemäß der vorstehend beschriebenen bevorzugten Ausführungsformen der Erfindung der Hashwert des Dokuments DOC in dem übermittelten Datenelement enthalten ist. Hierzu sollte jedoch gemäß bevorzugter Ausführungsformen der Erfindung sichergestellt sein, dass zur Erstellung der Signatur der Sicherheitsserver von dem Endgerät den korrekten Hashwert über das Dokument DOC geliefert bekommt.
Wie vorstehend beschrieben, wird der geheime Dokumentenschlüssel K_sec vorzugsweise zusammen mit dem Hashwert über die Dokumentenkennung (DOC_id und DOC_ver) verschlüsselt. Hierdurch kann vorteilhaft verhindert werden, dass sich ein unberechtigter Benutzer (Angreifer) den geheimen Dokumentenschlüssel K_sec eines fremden Dokuments verschafft, indem der Angreifer zuerst diese Daten im Rahmen einer Anfrage eines Endgeräts an den Sicherheitsserver zum Ablegen eines neuen bzw. eines modifizierten Dokuments DOC auf dem Cloudserver 50 an den Sicherheitsserver schickt, um sich diese Daten signieren zu lassen und anschließend im Rahmen einer weiteren Anfrage den geheimen Dokumentenschlüssel K_sec auszuspähen.
Gemäß bevorzugter erfindungsgemäßer Ausführungsformen könnte der Sicherheitsserver SS-A eines Unternehmens A neben dem asymmetrischen Schlüsselpaar (K_{ssa_prv} und K_{ssa_pub}) auch einen symmetrischen Schlüssel K_{ssa_sec} aufweisen, der ausschließlich dem Sicherheitsserver SS-A bekannt ist. Gemäß Varianten der Erfindung kann dieser symmetrische Schlüssel K_{ssa_sec} anstatt des öffentlichen Schlüssels zur Verschlüsselung des geheimen Dokumentenschlüssels K_sec und der im Dokumentencontainer DOC_con enthaltenen Hashwerte verwendet werden. Einzelheiten zu den dadurch erforderlichen Änderungen sind in der PCT/ EP2014/003035 beschrieben, der Offenbarung insoweit in die vorliegende Beschreibung aufgenommen wird.
Gemäß bevorzugter Ausführungsformen der Erfindung könnte der Sicherheitsserver eines Unternehmens dazu ausgestaltet sein, die Zusammenfassung einzelner Benutzer in Benutzergruppen zu ermöglichen. Diese Rechteverwaltung über Benutzergruppen ist insbesondere auch für die unternehmensübergreifende Verwendung interessant. In dem Fall, dass ein Dokument eines ersten Unternehmens A auf dem Sicherheitsserver SS-A verwaltet wird und mehrere Mitarbeiter eines zweiten Unternehmens B darauf Zugriff bekommen sollen, können diese zu einer Benutzergruppe zusammengefasst werden. Auf dem Sicherheitsserver SS-A des ersten Unternehmens werden dann nicht die USR_ids der einzelnen Mitarbeiter eingetragen sondern nur die Gruppen-ID. Die Zuordnung der einzelnen Mitarbeiter zu der Gruppe ist auf dem Sicherheitsserver SS-B des zweiten Unternehmens gespeichert, die Verwaltung der Gruppe erfolgt durch einen Administrator des Unternehmens B. In die Prüfung der Zugriffsrechte bei einem Zugriff auf das Dokument sind dann beide Sicherheitsserver involviert. Die oben beschriebenen Abläufe sind für diesen Fall entsprechend anzupassen.
In den oben beschriebenen Verfahren werden Daten von einem Endgerät direkt mit dem öffentlichen Schlüssel des Sicherheitsserver des anderen Unternehmens verschlüsselt und umgekehrt. Dementsprechend prüft ein Endgerät direkt Unterschriften, die vom Sicherheitsserver des anderen Unternehmens erstellt wurden, mit dessen öffentlichen Schlüssel und umgekehrt. Die dazu benötigten öffentlichen Schlüssel werden von dem dazwischenliegenden Sicherheitsserver jeweils sicher zur Verfügung gestellt. In einer anderen, ebenfalls vorteilhaften und von der Erfindung umfassten Verfahrensvariante kann ein Endgerät eines Unternehmens die Daten mit dem öffentlichen Schlüssel des Sicherheitsservers des eigenen Unternehmens verschlüsseln und an diesen übertragen. Der Sicherheitsserver entschlüsselt dann die Daten mit seinem privaten Schlüssel und verschlüsselt sie dann mit dem öffentlichen Schlüssel des Sicherheitsservers des anderen Unternehmens, um sie dann an diesen zu übertragen. Entsprechend läuft der verschlüsselte Datentransfer in umgekehrter Richtung ab.
Analog kann bei den Signaturen vorgegangen werden. Ein Endgerät signiert Daten mit seinem privaten Schlüssel und überträgt diese an den Sicherheitsserver des eigenen Unternehmens, der diese mit dem zugehörigen öffentlichen Schlüssel des Endgeräts prüft. Bei erfolgreicher Prüfung signiert der Sicherheitsserver die Daten mit seinem privaten Schlüssel und leitet sie an den Sicherheitsserver des anderen Unternehmens weiter, der diese wiederum prüft. Entsprechend läuft der signierte Datentransfer in umgekehrter Richtung ab. Bei dieser Verfahrensvariante muss der dazwischenliegende Sicherheitsserver den anderen Kommunikationspartnern keine öffentlichen Schlüssel mehr zur Verfügung stellen. Die Konfiguration von Firewalls gestaltet sich wie in der oben beschriebenen indirekten Variante recht einfach.
Bei den vorstehend beschriebenen Ausführungsformen ist jedem Benutzer genau ein Endgerät fest zugeordnet. Dabei wird die Kombination aus Benutzer und Endgerät, die über einen privaten Schlüssel K_{usr_prv} verfügt, über eine Benutzer- oder Endgerätkennung USR_id identifiziert. Die Erfindung kann jedoch ebenfalls auf Fälle angewendet werden, bei denen ein Benutzer mehrere Endgeräte verwendet, z.B. einen PC und ein Smartphone. Aber auch der Fall von mehreren Benutzern pro Endgerät wird von der Erfindung erfasst. Hierzu kann entweder jede vorgesehene Kombination aus Benutzer und Endgerät eine eigene USR_id bekommen oder es werden getrennte Benutzerkennungen und Endgerätkennungen vergeben. Dann kann erfindungsgemäß ein Benutzer auf unterschiedlichen Endgeräten unterschiedliche private Schlüssel verwenden. Der Sicherheitsserver des Unternehmens des Benutzers/Mitarbeiters kennt die Zuordnung von Benutzern und Endgeräten und unterstützt Zugriffsrechte auf Dokumente sowohl für bestimmte Benutzer allgemein als auch für bestimmte Benutzer mit bestimmten Endgeräten. Im Normalfall könnte der Sicherheitsserver Zugriffsrechte an Benutzer erteilen, unabhängig vom verwendeten Endgerät. Es ist erfindungsgemäß aber auch möglich, festzulegen, dass auf ein besonders kritisches Dokument DOC nur von einem bestimmten Endgerät, z.B. einem stationären PC zugegriffen werden darf und nicht von einem Smartphone aus, das leichter verloren gehen oder gestohlen werden kann. Ebenso ist es erfindungsgemäß vorstellbar, dass der Sicherheitsserver den Zugriff für ein gestohlenes oder verlorenes Endgerät generell sperren kann, während der Benutzer über andere Endgeräte weiterhin auf die Dokumente zugreifen kann. Außerdem ist sowohl bei mehreren Endgeräten pro Benutzer als auch bei mehreren Benutzern pro Endgerät der Fall erfindungsgemäß denkbar, dass der Benutzer seine Identität und seine Schlüssel auf einem Sicherheitstoken wie z.B. einer Smartcard bereitstellt.
Anstatt der vorstehend beschriebenen Dokumentenkennung in Form einer Kombination aus Dokumentenidentifikationsnummer DOC_id und Versionsnummer DOC_ver zur Identifikation einer bestimmten Version eines bestimmten Dokuments DOC könnte eine einzige Kennung verwendet werden. Dies könnte z.B. dann vorteilhaft sein, wenn diese Kennung durch den Cloudserver 50 vergeben wird. In diesem Fall wäre unter Umständen an den Kennungen jedoch nicht mehr erkennbar, welche Dokumentencontainer DOC_con verschiedene Versionen eines Dokuments DOC beinhalten. Diese Verknüpfungen könnten dann mittels des Sicherheitsservers abgebildet werden.

Claims

Verfahren zum Zugreifen von einem Endgerät (UD-B-k) eines zweiten Unternehmens (B) auf ein elektronisches Dokument, das von einem Endgerät (UD-A-i) eines ersten Unternehmens (A) in einem Dokumentencontainer auf einem Cloudspeicherdienst (50) gespeichert worden ist, wobei der Dokumentencontainer das mit einem Dokumentenschlüssel K_sec verschlüsselte Dokument und den mit einem öffentlichen Schlüssel K_{ssa_pub} einer Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssel K_sec enthält; umfassend die Schritte: das Übertragen des Dokumentencontainers an das Endgerät (UD-B-k) des zweiten Unternehmens (B), das Weiterleiten des mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssels K_sec an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A); indem entweder a) das Endgerät (UD-B-k) des zweiten Unternehmens (B) den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssel K_sec direkt an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) weiterleitet; und eine Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) den Status des Endgeräts (UD-B-k) des zweiten Unternehmens (B) und den öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) überträgt, oder b) das Endgerät (UD-B-k) des zweiten Unternehmens (B) den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssel K_sec an eine Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) weiterleitet; die Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) den Status des Endgeräts (UD-B-k) des zweiten Unternehmens (B) prüft und im Fall einer erfolgreichen Prüfung den öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) überträgt; das Übertragen eines öffentlichen Schlüssels K_{usr_bk_pub} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A); das Entschlüsseln des mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssels K_sec durch die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A); das Verschlüsseln des Dokumentenschlüssels K_sec mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts (UD-B-k) des zweiten Unternehmens (B); das Übertragen des mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) verschlüsselten Dokumentenschlüssel K_sec an das Endgerät (UD-B-k) des zweiten Unternehmens (B); das Entschlüsseln des mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) verschlüsselten Dokumentenschlüssels K_sec mit einem privaten Schlüssel K_{usr_bk_prv} des Endgeräts (UD-B-k) des zweiten Unternehmens (B); und das Entschlüsseln des im Dokumentencontainer enthaltenen verschlüsselten Dokuments mit dem entschlüsselten Dokumentenschlüssel K_sec.
Verfahren nach Anspruch 1, wobei der Dokumentencontainer ferner eine mit einem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) erzeugte Signatur des Dokumentenschlüssels K_sec enthält, und das Verfahren die folgenden weiteren Schritte umfasst: das Übertragen des öffentlichen Schlüssels K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) an das Endgerät (UD-B-k) des zweiten Unternehmens (B); und das Verifizieren der Signatur des Dokumentenschlüssels K_sec mit dem öffentlichen Schlüssels K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) durch das Endgerät (UD-B-k) des zweiten Unternehmens (B).
Verfahren zum Abspeichern eines auf einem Endgerät (UD-B-k) eines zweiten Unternehmens (B) modifizierten elektronischen Dokuments, das von einem Endgerät (UD-A-i) eines ersten Unternehmens (A) in einem Dokumentencontainer auf einem Cloudspeicherdienst (50) gespeichert worden ist, wobei der Dokumentencontainer das mit einem Dokumentenschlüssel K_sec verschlüsselte Dokument und den mit einem öffentlichen Schlüssel K_{ssa_pub} einer Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssel K_sec enthält; umfassend die Schritte: das Erzeugen eines neuen Dokumentenschlüssels K_sec auf dem Endgerät (UD-B-k) des zweiten Unternehmens (B); das Verschlüsseln des modifizierten elektronischen Dokuments mit dem neuen Dokumentenschlüssel K_sec und das Verschlüsseln des neuen Dokumentenschlüssels K_sec mit einem öffentlichen Schlüssel K_{ssa_pub} einer Sicherheitsinstanz (SS-A) des ersten Unternehmens (A); das Weiterleiten des mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssels K_sec an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A); indem entweder a) das Endgerät (UD-B-k) des zweiten Unternehmens (B) den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssels K_sec direkt an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) weiterleitet; eine Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) den Status des Endgeräts (UD-B-k) des zweiten Unternehmens (B) an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) überträgt; und die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) im Fall eines aktiven Status des Endgeräts (UD-B-k) des zweiten Unternehmens (B) die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) erzeugte Signatur direkt an das Endgerät (UD-B-k) des zweiten Unternehmens (B) weiterleitet; oder b) das Endgerät (UD-B-k) des zweiten Unternehmens (B) den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssel K_sec an eine Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) weiterleitet; die Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) den Status des Endgeräts (UD-B-k) des zweiten Unternehmens (B) prüft und im Fall einer erfolgreichen Prüfung den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssel K_sec an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) überträgt; die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) erzeugte Signatur an die Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) überträgt; und die Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) erzeugte Signatur an das Endgerät (UD-B-k) des zweiten Unternehmens (B) weiterleitet. das Entschlüsseln des mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssels K_sec durch die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A); das Erzeugen einer Signatur des Dokumentenschlüssels K_sec mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A); das Übertragen der mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) erzeugten Signatur an das Endgerät (UD-B-k) des zweiten Unternehmens (B); und das Übertragen eines neuen Dokumentencontainers an den Cloudspeicherdienst (50), wobei der neue Dokumentencontainer das mit dem neuen Dokumentenschlüssel K_sec verschlüsselte modifizierte Dokument, den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten neuen Dokumentenschlüssel K_sec und die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) erzeugten Signatur enthält; und das Abspeichern des neuen Dokumentencontainers im Cloudspeicherdienst (50).
Verfahren nach Anspruch 3, wobei in Variante a) das Endgerät (UD-B-k) des zweiten Unternehmens (B) den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssels K_sec zusammen mit einer mit dem privaten Schlüssel K_{usr_bk_prv} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) erstellten Signatur des Dokumentenschlüssels K_sec direkt an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) weiterleitet; eine Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) den Status des Endgeräts (UD-B-k) des zweiten Unternehmens (B) und den öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) überträgt; die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) die von dem Endgerät (UD-B-k) des zweiten Unternehmens (B) übermittelte Signatur des Dokumentenschlüssels K_sec mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) verifiziert; und die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) im Fall einer erfolgreichen Verifikation die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) erzeugte Signatur direkt an das Endgerät (UD-B-k) des zweiten Unternehmens (B) weiterleitet.
Verfahren nach Anspruch 3, wobei in Variante b) das Endgerät (UD-B-k) des zweiten Unternehmens (B) den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssel K_sec zusammen mit einer mit dem privaten Schlüssel K_{usr_bk_prv} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) erstellten Signatur des Dokumentenschlüssels K_sec an die Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) weiterleitet; die Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) den Status des Endgeräts (UD-B-k) des zweiten Unternehmens (B) prüft und im Fall einer erfolgreichen Prüfung den mit dem öffentlichen Schlüssel K_{ssa_pub} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) verschlüsselten Dokumentenschlüssel K_sec zusammen mit der mit dem privaten Schlüssel K_{usr_bk_prv} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) erstellten Signatur des Dokumentenschlüssels K_sec und dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) an die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) überträgt; die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) die übermittelte Signatur des Dokumentenschlüssels K_sec mit dem öffentlichen Schlüssel K_{usr_bk_pub} des Endgeräts (UD-B-k) des zweiten Unternehmens (B) verifiziert; die Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) im Fall einer erfolgreichen Verifikation die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) erzeugte Signatur an die Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) überträgt; und die Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) die mit dem privaten Schlüssel K_{ssa_prv} der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) erzeugte Signatur an das Endgerät (UD-B-k) des zweiten Unternehmens (B) weiterleitet.
Verfahren nach einem der Ansprüche 3 bis 5, wobei das Endgerät (UD-B-k) bzw. die Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) die von der Sicherheitsinstanz (SS-A) des ersten Unternehmens (A) erzeugte Signatur des Dokumentenschlüssels K_sec überprüft, bevor der Dokumentencontainer an den Cloudspeicherdienst (50) übertragen wird.
Verfahren nach einen der vorhergehenden Ansprüche, wobei die Sicherheitsinstanzen (SS-A, SS-B) des ersten und/ oder zweiten Unternehmens (A, B) jeweils einen Sicherheitsserver und der Cloudspeicherdienst (50) einen Cloudserver umfasst.
Endgerät (UD-A-i, UD-B-k), das dazu ausgestaltet ist, im Rahmen eines Verfahrens nach einem der Ansprüche 1 bis 7 eingesetzt zu werden.
Sicherheitsinstanz (SS-A, SS-B), vorzugsweise in Form eines Sicherheitsservers, die dazu ausgestaltet ist, im Rahmen eines Verfahren nach einem der Ansprüche 1 bis 7 eingesetzt zu werden.
System mit wenigstens einem Endgerät (UD-A-i) eines ersten Unternehmens (A) nach Anspruch 8, wenigstens einem Endgerät (UD-B-k) eines zweiten Unternehmens (B) nach Anspruch 8, einer Sicherheitsinstanz (SS-A) des ersten Unternehmens (A), einer Sicherheitsinstanz (SS-B) des zweiten Unternehmens (B) und wenigstens einem Cloudspeicherdienst (50).