DE112022003983T5

DE112022003983T5 - Berechtigte, sichere datenverschiebung

Info

Publication number: DE112022003983T5
Application number: DE112022003983.3T
Authority: DE
Inventors: John Stewart Best; Guerney D.H. Hunt; Wayne C. Hineman; Steven Robert Hetzler
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2021-08-17
Filing date: 2022-07-07
Publication date: 2024-05-29
Also published as: WO2023020150A1; US20230058965A1; US11991293B2

Abstract

Ein System enthält eine auf ihre Berechtigung geprüfte Verschlüsselungsschicht, die Logik aufweist, die konfiguriert wird, um Daten zu verschlüsseln, die in der auf ihre Berechtigung geprüften Verschlüsselungsschicht von einer berechtigten Anwendung in einem Quellknoten empfangen werden. Die Daten werden unter Verwendung eines ersten Schlüssels verschlüsselt, um erste verschlüsselte Daten zu erhalten. Die Logik wird konfiguriert, um die ersten verschlüsselten Daten unter Verwendung eines zweiten Schlüssels zu verschlüsseln, um zweite verschlüsselte Daten zu erhalten und ein Wasserzeichen für die ersten verschlüsselten Daten und/oder ein Wasserzeichen für die zweiten verschlüsselten Daten zu erzeugen. Die Logik wird konfiguriert, um ein Wasserzeichen-Token für die ersten verschlüsselten Daten und/oder ein Wasserzeichen-Token für die zweiten verschlüsselten Daten zu erzeugen.

Description

HINTERGRUND
Die vorliegende Erfindung bezieht sich auf eine Verschlüsselung, und im Besonderen bezieht sich diese Erfindung auf eine berechtigte, sichere Datenverschiebung in Speichersystemen und Netzwerken wie beispielsweise Speichersystemen auf Cloud-Grundlage.
Es ist wünschenswert, Daten zwischen Computerknoten auf sichere Weise gemeinsam zu nutzen. Eine sichere Datenübertragung ist besonders nützlich, um Rechenfunktionen in der Nähe von gespeicherten Daten bereitzustellen. Zum Beispiel kann jeder Knoten eine bestimmte Rechenfunktion haben (z.B. eine Datenbank, eine Inferenz-Engine usw.). In Ansätzen nach dem Stand der Technik werden herkömmlicherweise Zugriffssteuerungen verwendet, um ein gemeinsames Nutzen von Daten zu begrenzen. Zugriffssteuerungen sind nicht gegen Fehler gefeit und können zu Datenlecks führen. So können Rechte zum Beispiel ausgedehnt werden, die Steuerungen können fehlerhaft konfiguriert werden, usw.
Eine unberechtigte Verschlüsselung von Daten, z.B. durch einen Angreifer, der Daten eines Opfers mit einem Schlüssel verschlüsselt, den das Opfer nicht kennt, stellt ein erhebliches Sicherheitsproblem dar. Solche Ransomware-Angriffe erzeugen eine Verweigerung von Zugriffsrechten für das Opfer, deren Wiederherstellung teuer oder unmöglich sein kann. Solche Angriffe enthalten zum Beispiel Ransomware-Angriffe, bei denen im Austausch gegen den Verschlüsselungsschlüssel, der zum Entsperren der Daten des Opfers benötigt wird, ein Lösegeld gefordert wird.
Bei Angriffen der Exfiltrationsart kann Malware außerdem und/oder alternativ hierzu auch eine unberechtigte Datenübertragung durchführen (wobei Daten z.B. kopiert, übertragen, abgerufen werden, usw.), ohne dass eine Berechtigung vorliegt.
Benötigt wird ein Verfahren, um sicherzustellen, dass verschlüsselte Daten in einem System auf eine berechtigte Art und Weise verschlüsselt wurden, sodass der Dateneigentümer in der Lage ist, die Daten zu entschlüsseln.
KURZDARSTELLUNG
Gemäß einem Aspekt enthält ein System eine auf ihre Berechtigung geprüfte Verschlüsselungsschicht, die Logik aufweist, die konfiguriert wird, um Daten zu verschlüsseln, die in der auf ihre Berechtigung geprüften Verschlüsselungsschicht von einer berechtigten Anwendung in einem Quellknoten empfangen werden. Die Daten werden unter Verwendung eines ersten Schlüssels verschlüsselt, um erste verschlüsselte Daten zu erhalten. Die Logik wird konfiguriert, um die ersten verschlüsselten Daten unter Verwendung eines zweiten Schlüssels zu verschlüsseln, um zweite verschlüsselte Daten zu erhalten und ein Wasserzeichen für die ersten verschlüsselten Daten und/oder ein Wasserzeichen für die zweiten verschlüsselten Daten zu erzeugen. Die Logik wird konfiguriert, um ein Wasserzeichen-Token für die ersten verschlüsselten Daten und/oder ein Wasserzeichen-Token für die zweiten verschlüsselten Daten zu erzeugen. Die Wasserzeichen und/oder Wasserzeichen-Token werden verwendet, um zu überprüfen, dass die Verschlüsselung durch die berechtigte Verschlüsselungsschicht und nicht durch einen unberechtigten Prozess durchgeführt wurde. Angriffe der Ransomware-Art werden hierdurch vorteilhafterweise blockiert.
Gemäß einem optionalen Aspekt weist die auf ihre Berechtigung geprüfte Verschlüsselungsschicht Logik auf, die konfiguriert wird, um zu veranlassen, dass die zweiten verschlüsselten Daten und das bzw. die erzeugten Wasserzeichen in einem Datenspeicher gespeichert werden. Jedes erzeugte Wasserzeichen wird unter Verwendung eines entsprechenden Wasserzeichenschlüssels erzeugt. Die Wasserzeichen und ihre entsprechenden Wasserzeichenschlüssel ermöglichen ein selektives, gleichzeitiges gemeinsames Nutzen verschlüsselter Informationen, wobei berechtigte Benutzer verschiedene Schlüssel haben und der Eigentümer der Daten den Zugriff für die berechtigten Benutzer selektiv zurücknehmen kann.
Gemäß einem weiteren Aspekt enthält ein computerrealisiertes Verfahren ein Empfangen zweiter verschlüsselter Daten, von Wasserzeichen und eines ersten Wasserzeichen-Tokens von einem Datenspeicher als Reaktion auf eine Datenanforderung von einem Zielknoten außerhalb einer berechtigten Verschlüsselungsvertrauenszone. Die zweiten verschlüsselten Daten sind Daten, die mit einem ersten Schlüssel verschlüsselt wurden, um erste verschlüsselte Daten zu erzeugen, die dann mit einem zweiten Schlüssel verschlüsselt werden, um die zweiten verschlüsselten Daten zu erzeugen. Die Wasserzeichen enthalten ein erstes Wasserzeichen, das für die ersten verschlüsselten Daten erzeugt wird, und ein zweites Wasserzeichen, das für die zweiten verschlüsselten Daten erzeugt wird. Das erste Wasserzeichen-Token wird für die ersten verschlüsselten Daten erzeugt. Das Verfahren enthält ein Überprüfen des zweiten Wasserzeichens, das für die zweiten verschlüsselten Daten erzeugt wird, und als Reaktion auf eine Überprüfung des zweiten Wasserzeichens ein Entschlüsseln der zweiten verschlüsselten Daten unter Verwendung des zweiten Schlüssels, um die ersten verschlüsselten Daten zu erhalten. Das Verfahren enthält des Weiteren ein Überprüfen des ersten Wasserzeichens, das für die ersten verschlüsselten Daten erzeugt wird, und als Reaktion auf eine Überprüfung des ersten Wasserzeichens ein Senden der ersten verschlüsselten Daten an einen vertrauenswürdigen Überprüfer. Der vertrauenswürdige Überprüfer wird konfiguriert, um das erste Wasserzeichen-Token, das für die ersten verschlüsselten Daten erzeugt wird, zu überprüfen, und als Reaktion auf ein Empfangen einer Überprüfung des ersten Wasserzeichen-Tokens, das für die ersten verschlüsselten Daten von dem vertrauenswürdigen Überprüfer erzeugt wird, enthält das Verfahren ein Verschlüsseln der ersten verschlüsselten Daten mit einem dritten Schlüssel, um dritte verschlüsselte Daten zu erzeugen. Das Verfahren enthält des Weiteren ein Erzeugen eines dritten Wasserzeichens und/oder eines dritten Wasserzeichen-Tokens für die dritten verschlüsselten Daten und ein Senden der dritten verschlüsselten Daten, der Wasserzeichen und des bzw. der Wasserzeichen-Token, z.B. des dritten Wasserzeichens und/oder des dritten Wasserzeichen-Tokens, an ein berechtigtes Ziel. Ein berechtigtes Ziel wird konfiguriert, um das dritte Wasserzeichen und/oder das dritte Wasserzeichen-Token zu überprüfen, und bei einer erfolgreichen Überprüfung des dritten Wasserzeichens und/oder des dritten Wasserzeichen-Tokens kann das berechtigte Ziel die dritten verschlüsselten Daten unter Verwendung des dritten Schlüssels entschlüsseln, um die ersten verschlüsselten Daten (z.B. die Daten in der Klarform) zu erhalten. Die dritten verschlüsselten Daten stellen eine zusätzliche Schutzschicht gegen einen Angriff bereit.
Gemäß einem optionalen Aspekt enthält der vertrauenswürdige Überprüfer eine Vorfilterfunktion, die konfiguriert wird, um zu überprüfen, dass die Daten nicht verschlüsselt sind. Der vertrauenswürdige Überprüfer sendet die Überprüfung nur als Reaktion auf eine erfolgreiche Überprüfung, dass die Daten nicht verschlüsselt sind. Die Vorfilterfunktion stellt den Vorteil bereit, dass sie in der Lage ist, zu ermitteln, ob die Daten mit einem beliebigen Verschlüsselungsschlüssel verschlüsselt sind, und eine weitere Verarbeitung kontaminierter Daten zu verhindern. Zum Beispiel können die Daten durch einen Angreifer verschlüsselt werden, der Klartext durch verschlüsselten Text ersetzt hat.
Gemäß einem weiteren Aspekt enthält ein computerrealisiertes Verfahren ein Empfangen innerer verschlüsselter Daten durch einen vertrauenswürdigen Überprüfer mindestens teilweise auf Grundlage einer Datenanforderung von einem Zielknoten außerhalb einer berechtigten Verschlüsselungsvertrauenszone. Die inneren verschlüsselten Daten sind Daten, die mit einem inneren Schlüssel verschlüsselt wurden, um die inneren verschlüsselten Daten zu erzeugen. Das Verfahren enthält durch den vertrauenswürdigen Überprüfer ein Überprüfen eines inneren Wasserzeichen-Tokens, das für die inneren verschlüsselten Daten erzeugt wird, wobei das innere Wasserzeichen-Token für die inneren verschlüsselten Daten erzeugt wird. Der vertrauenswürdige Überprüfer ermöglicht eine Überprüfung des Wasserzeichens von berechtigten verschlüsselten Daten, ohne dass der vertrauenswürdige Überprüfer genug Informationen haben muss, um einem gefälschten Wasserzeichen zu ermöglichen, das ursprüngliche Wasserzeichen zu ersetzen.
Gemäß einem allgemeinen Aspekt ist die Datenanforderung eine Datenschreibanforderung, und das Verfahren enthält als Reaktion auf eine erfolgreiche Überprüfung des inneren Wasserzeichen-Tokens ein Entschlüsseln der inneren verschlüsselten Daten durch den vertrauenswürdigen Überprüfer unter Verwendung des inneren Schlüssels, um die Daten zu erhalten, und ein Ermitteln durch den vertrauenswürdigen Überprüfer unter Verwendung einer Vorfilterfunktion, dass die Daten unverschlüsselt sind. Das Verfahren enthält des Weiteren ein Zurückgeben einer ersten Überprüfungsnachricht an einen Transcoder durch den vertrauenswürdigen Überprüfer als Reaktion auf eine erfolgreiche Überprüfung des inneren Wasserzeichen-Tokens und die Ermittlung, dass die Daten unverschlüsselt sind. Die Vorfilterfunktion stellt den Vorteil bereit, dass sie in der Lage ist, zu ermitteln, ob die Daten mit einem beliebigen Verschlüsselungsschlüssel verschlüsselt sind, und eine weitere Verarbeitung kontaminierter Daten zu verhindern.
Andere Aspekte und Ansätze der vorliegenden Erfindung werden aus der folgenden ausführlichen Beschreibung offensichtlich, die in Verbindung mit den Zeichnungen die Grundgedanken der Erfindung beispielhaft veranschaulicht.
KURZBESCHREIBUNG DER ZEICHNUNGEN

1 stellt eine Cloud-Computing-Umgebung gemäß einem Aspekt der vorliegenden Erfindung dar.
2 stellt Abstraktionsmodellschichten gemäß einem Aspekt der vorliegenden Erfindung dar.
3 ist eine Darstellung einer allgemeinen Architektur gemäß einem Aspekt der vorliegenden Erfindung.
4 ist eine Darstellung einer allgemeinen Architektur gemäß einem Aspekt der vorliegenden Erfindung.
5 ist eine Darstellung einer allgemeinen Architektur gemäß einem Aspekt der vorliegenden Erfindung.
6 ist eine Darstellung einer allgemeinen Architektur gemäß einem Aspekt der vorliegenden Erfindung.
7 ist ein Ablaufplan eines Verfahrens gemäß einem Aspekt der vorliegenden Erfindung.
8 ist ein Ablaufplan eines Verfahrens gemäß einem Aspekt der vorliegenden Erfindung.
9 ist eine beispielhafte Realisierung einer Leseanforderung gemäß einem Aspekt der vorliegenden Erfindung.
10 ist eine beispielhafte Realisierung einer Schreibanforderung gemäß einem Aspekt der vorliegenden Erfindung.
11 ist eine beispielhafte Realisierung eines vertrauenswürdigen Überprüfers gemäß einem Aspekt der vorliegenden Erfindung.

AUSFÜHRLICHE BESCHREIBUNG
Die folgende Beschreibung dient zur Veranschaulichung der allgemeinen Grundgedanken der vorliegenden Erfindung und ist nicht als Einschränkung der hier beanspruchten erfinderischen Konzepte gedacht. Darüber hinaus können bestimmte hier beschriebene Merkmale in Verbindung mit anderen beschriebenen Merkmalen in jeder der verschiedenen möglichen Kombinationen und Vertauschungen verwendet werden.
Sofern hier nicht anderweitig ausdrücklich definiert, sind sämtliche Begriffe in ihrer größtmöglichen Auslegung zu verstehen, einschließlich aus der Beschreibung hervorgehende Bedeutungen sowie durch einen Fachmann verstandene und/oder in Wörterbüchern, Abhandlungen usw. definierte Bedeutungen.
Darüber hinaus ist zu beachten, dass die in der Beschreibung und den beigefügten Ansprüchen verwendeten Singularformen „ein/eine/eines“ und „der/die/das“ auch die Pluralformen einschließen, soweit dies nicht anderweitig angegeben wird. Des Weiteren wird darauf verwiesen, dass die Begriffe „weist auf“ und/oder „aufweisend“ in dieser Beschreibung das Vorhandensein der genannten Merkmale, Ganzzahlen, Schritte, Operationen, Elemente und/oder Komponenten angeben, ohne jedoch das Vorhandensein oder die Hinzufügung von einem bzw. einer oder mehreren anderen Merkmalen, Ganzzahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen derselben auszuschließen.
Die folgende Beschreibung offenbart mehrere Aspekte eines Erkennens einer unberechtigten Schlüsselverwendung bei einem sicheren gemeinsamen Nutzen unter Verwendung von berechtigten Überprüfern, denen genug Informationen bereitgestellt werden, um das Wasserzeichen berechtigter verschlüsselter Daten zu überprüfen, jedoch nicht genug Informationen, um einem gefälschten Wasserzeichen zu ermöglichen, das ursprüngliche Wasserzeichen zu ersetzen.
Gemäß einem allgemeinen Aspekt enthält ein System eine auf ihre Berechtigung geprüfte Verschlüsselungsschicht, die Logik aufweist, die konfiguriert wird, um Daten zu verschlüsseln, die in der auf ihre Berechtigung geprüften Verschlüsselungsschicht von einer berechtigten Anwendung in einem Quellknoten empfangen werden. Die Daten werden unter Verwendung eines ersten Schlüssels verschlüsselt, um erste verschlüsselte Daten zu erhalten. Die Logik wird konfiguriert, um die ersten verschlüsselten Daten unter Verwendung eines zweiten Schlüssels zu verschlüsseln, um zweite verschlüsselte Daten zu erhalten und ein Wasserzeichen für die ersten verschlüsselten Daten und/oder ein Wasserzeichen für die zweiten verschlüsselten Daten zu erzeugen. Die Logik wird konfiguriert, um ein Wasserzeichen-Token für die ersten verschlüsselten Daten und/oder ein Wasserzeichen-Token für die zweiten verschlüsselten Daten zu erzeugen.
Gemäß einem weiteren allgemeinen Aspekt enthält ein computerrealisiertes Verfahren ein Empfangen zweiter verschlüsselter Daten, von Wasserzeichen und eines ersten Wasserzeichen-Tokens von einem Datenspeicher als Reaktion auf eine Datenanforderung von einem Zielknoten außerhalb einer berechtigten Verschlüsselungsvertrauenszone. Die zweiten verschlüsselten Daten sind Daten, die mit einem ersten Schlüssel verschlüsselt wurden, um erste verschlüsselte Daten zu erzeugen, die dann mit einem zweiten Schlüssel verschlüsselt werden, um die zweiten verschlüsselten Daten zu erzeugen. Die Wasserzeichen enthalten ein erstes Wasserzeichen, das für die ersten verschlüsselten Daten erzeugt wird, und ein zweites Wasserzeichen, das für die zweiten verschlüsselten Daten erzeugt wird. Das erste Wasserzeichen-Token wird für die ersten verschlüsselten Daten erzeugt. Das Verfahren enthält ein Überprüfen des zweiten Wasserzeichens, das für die zweiten verschlüsselten Daten erzeugt wird, und als Reaktion auf eine Überprüfung des zweiten Wasserzeichens ein Entschlüsseln der zweiten verschlüsselten Daten unter Verwendung des zweiten Schlüssels, um die ersten verschlüsselten Daten zu erhalten. Das Verfahren enthält des Weiteren ein Überprüfen des ersten Wasserzeichens, das für die ersten verschlüsselten Daten erzeugt wird, und als Reaktion auf eine Überprüfung des ersten Wasserzeichens ein Senden der ersten verschlüsselten Daten an einen vertrauenswürdigen Überprüfer. Der vertrauenswürdige Überprüfer wird konfiguriert, um das erste Wasserzeichen-Token, das für die ersten verschlüsselten Daten erzeugt wird, zu überprüfen, und als Reaktion auf ein Empfangen einer Überprüfung des ersten Wasserzeichen-Tokens, das für die ersten verschlüsselten Daten erzeugt wird, von dem vertrauenswürdigen Überprüfer enthält das Verfahren ein Verschlüsseln der ersten verschlüsselten Daten mit einem dritten Schlüssel, um dritte verschlüsselte Daten zu erzeugen. Das Verfahren enthält des Weiteren ein Erzeugen eines dritten Wasserzeichens und/oder eines dritten Wasserzeichen-Tokens für die dritten verschlüsselten Daten und ein Senden der dritten verschlüsselten Daten, der Wasserzeichen und des bzw. der Wasserzeichen-Token, z.B. des dritten Wasserzeichens und/oder des dritten Wasserzeichen-Tokens, an ein berechtigtes Ziel.
Gemäß einem weiteren allgemeinen Aspekt enthält ein computerrealisiertes Verfahren ein Empfangen innerer verschlüsselter Daten durch einen vertrauenswürdigen Überprüfer mindestens teilweise auf Grundlage einer Datenanforderung von einem Zielknoten außerhalb einer berechtigten Verschlüsselungsvertrauenszone. Die inneren verschlüsselten Daten sind Daten, die mit einem inneren Schlüssel verschlüsselt wurden, um die inneren verschlüsselten Daten zu erzeugen. Das Verfahren enthält ein Überprüfen eines inneren Wasserzeichen-Tokens durch den vertrauenswürdigen Überprüfer, das für die inneren verschlüsselten Daten erzeugt wird, wobei das innere Wasserzeichen-Token für die inneren verschlüsselten Daten erzeugt wird.
Es sei klargestellt, dass die Realisierung der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist, obwohl diese Offenbarung eine ausführliche Beschreibung des Cloud Computing enthält. Vielmehr können Aspekte der vorliegenden Erfindung gemeinsam mit jeder beliebigen Art von jetzt bekannter oder später entwickelter Datenverarbeitungsumgebung realisiert werden.
Cloud Computing ist ein Dienstbereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Arbeitsspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Dienstes schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften, mindestens drei Dienstmodelle und mindestens vier Einsatzmodelle enthalten.
Bei den Eigenschaften handelt es sich um die Folgenden:

On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfähigkeiten wie Server-Zeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.
Broad Network Access: Es sind Fähigkeiten über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, die die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
Resource Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
Rapid Elasticity: Fähigkeiten können für eine schnelle horizontale Skalierung (Scale-out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Fähigkeiten häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfähigkeit auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Der Ressourcenverbrauch kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Benutzer des verwendeten Dienstes Transparenz bereitgestellt wird.

Bei den Dienstmodellen handelt es sich um die Folgenden:

Software as a Service (SaaS): Die dem Nutzer bereitgestellte Fähigkeit besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende eMail) von verschiedenen Client-Einheiten her zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfähigkeiten, mit der möglichen Ausnahme von eingeschränkten nutzerspezifischen Anwendungskonfigurationseinstellungen.
Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Fähigkeit besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen für Application Hosting Environment.
Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Fähigkeit besteht darin, Verarbeitung, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).

Bei den Einsatzmodellen handelt es sich um die Folgenden:

Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Zielsetzung, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und sich in den eigenen Räumen oder in fremden Räumen befinden.
Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und gehört einer Cloud-Dienste verkaufenden Organisation.
Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (Private, Community oder Public), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden werden, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).

Eine Cloud-Computing-Umgebung ist dienstorientiert mit einem Fokus auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Mittelpunkt des Cloud Computing steht eine Infrastruktur, die ein Netzwerk aus zusammengeschalteten Knoten enthält.
Unter nunmehriger Bezugnahme auf 1 wird eine veranschaulichende Cloud-Computing-Umgebung 50 dargestellt. Wie gezeigt ist, enthält die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie ein elektronischer Assistent (PDA, Personal Digital Assistant) oder ein Mobiltelefon 54A, ein Desktop Computer 548, ein Laptop Computer 54C und/oder ein Automobil-Computer-System 54N Daten austauschen können. Die Knoten 10 können miteinander Daten austauschen. Sie können physisch oder virtuell in einem oder mehreren Netzwerken wie Private, Community, Public oder Hybrid Clouds zusammengefasst werden (nicht gezeigt), wie vorstehend beschrieben wurde, oder aber in einer Kombination daraus. Dies ermöglicht es der Cloud-Computing-Umgebung 50, Infrastruktur, Plattformen und/oder Software als Dienst anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es sei darauf hingewiesen, dass die Arten von in 1 gezeigten Datenverarbeitungseinheiten 54A bis N lediglich veranschaulichend sein sollen und dass die Datenverarbeitungsknoten 10 und die Cloud-Computing-Umgebung 50 über eine beliebige Art von Netzwerk und/oder über eine beliebige Art von über ein Netzwerk aufrufbarer Verbindung (z.B. unter Verwendung eines Web-Browsers) mit einer beliebigen Art von computergestützter Einheit Daten austauschen können.
Unter nunmehriger Bezugnahme auf 2 wird ein Satz von funktionalen Abstraktionsschichten gezeigt, die durch die Cloud-Computing-Umgebung 50 (1) bereitgestellt werden. Es sollte von vornherein klar sein, dass die in 2 gezeigten Komponenten, Schichten und Funktionen lediglich veranschaulichend sein sollen und Aspekte der Erfindung nicht darauf beschränkt sind. Wie dargestellt, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
Eine Hardware- und Software-Schicht 60 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören: Mainframe Computer 61; auf der RISC-Architektur (Reduced Instruction Set Computer) beruhende Server 62; Server 63; Blade-Server 64; Speichereinheiten 65; und Netzwerke sowie Netzwerkkomponenten 66. Gemäß manchen Aspekten enthalten Software-Komponenten eine Netzwerk-Anwendungsserver-Software 67 und eine Datenbank-Software 68.
Eine Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Einheiten bereitgestellt werden können: virtuelle Server 71, virtueller Speicher 72, virtuelle Netzwerke 73 wie z.B. virtuelle private Netzwerke, virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.
In einem Beispiel kann eine Verwaltungsschicht 80 die nachfolgend beschriebenen Funktionen bereitstellen. Eine Ressourcen-Bereitstellung 81 stellt die dynamische Beschaffung von Datenverarbeitungsressourcen sowie anderen Ressourcen bereit, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Ein Messen und eine Preisfindung 82 stellen die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung oder Rechnungsstellung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Anwendungs-Software-Lizenzen enthalten. Eine Sicherheit stellt die Identitätsüberprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 83 stellt Nutzern und Systemadministratoren einen Zugriff auf die Cloud-Computing-Umgebung bereit. Eine Verwaltung des Dienstumfangs 84 stellt die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, sodass die benötigten Dienstziele erreicht werden. Ein Planen und Erfüllen von Vereinbarungen zum Dienstumfang (Service Level Agreement, SLA) 85 stellt die Vorab-Anordnung und die Beschaffung von Cloud-Computing-Ressourcen, für die eine zukünftige Anforderung vorausgesehen wird, gemäß einer SLA bereit.
Eine Arbeitslastenschicht 90 stellt Beispiele einer Funktionalität bereit, für welche die Cloud-Datenverarbeitungsumgebung genutzt werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 91; Software-Entwicklung und Lebenszyklusverwaltung 92; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 93; Datenanalytikverarbeitung 94; Transaktionsverarbeitung 95; und berechtigte, sichere Datenverschiebung 96.
Eine unberechtigte Verschlüsselung von Daten, z.B. durch einen Angreifer, der Daten eines Opfers mit einem Schlüssel verschlüsselt, den das Opfer nicht kennt, stellt ein erhebliches Sicherheitsproblem dar. Solche Ransomware-Angriffe erzeugen eine Verweigerung von Zugriffsrechten für das Opfer, deren Wiederherstellung teuer oder unmöglich sein kann. Mindestens manche Aspekte der vorliegenden Offenbarung stellen ein Verfahren zum Erkennen einer unberechtigten Schlüsselverwendung bei einem sicheren, gemeinsamen Nutzen unter Verwendung eines berechtigten Überprüfers bereit, dem genug Informationen bereitgestellt werden, um das Wasserzeichen berechtigter verschlüsselter Daten zu überprüfen, jedoch nicht genug Informationen, um einem gefälschten Wasserzeichen zu ermöglichen, das ursprüngliche Wasserzeichen zu ersetzen. Entsprechend stellen mindestens manche Aspekte der vorliegenden Offenbarung ein Verfahren zum Sicherstellen bereit, dass verschlüsselte Daten in einem System auf eine berechtigte Art und Weise verschlüsselt wurden, sodass der Dateneigentümer in der Lage ist, die Daten zu entschlüsseln. Die Verschlüsselung wird auf ihre Berechtigung geprüft, indem „Wasserzeichen“ erzeugt werden, die überprüfen, dass die Verschlüsselung durch die berechtigte Verschlüsselungsschicht und nicht durch einen unberechtigten Prozess durchgeführt wurde. Angriffe der Ransomware-Art werden hierdurch vorteilhafterweise blockiert. Angriffe der Exfiltrationsart werden erheblich eingeschränkt, indem Daten unter Verwendung von auf ihre Berechtigung geprüften und/oder attestierten Anwendungen verschlüsselt werden müssen, denen die Verwendung der berechtigten Verschlüsselung gestattet wird.
Mindestens manche Aspekte der vorliegenden Offenbarung ermöglichen eine sichere Datenverschiebung unter Verwendung einer doppelten Verschlüsselung, um eine sichere gemeinsame Nutzung von Daten zwischen Benutzern zu ermöglichen. Doppelt verschlüsselte Daten, auf die in der vorliegenden Offenbarung Bezug genommen wird, enthalten Daten, die ein erstes Mal mit einem ersten Schlüssel verschlüsselt werden, um „innere verschlüsselte Daten“ zu erzeugen, woraufhin die inneren verschlüsselten Daten mit einem zweiten Schlüssel verschlüsselt werden, um „äußere verschlüsselte Daten“ zu erzeugen. Sofern hierin nicht anderweitig angemerkt, können doppelt verschlüsselte Daten und „äußere verschlüsselte Daten“ in der vorliegenden Offenbarung austauschbar verwendet werden. Entsprechend können „innere verschlüsselte Daten“ und „erste verschlüsselte Daten“ in der vorliegenden Offenbarung austauschbar verwendet werden, sofern hierin nicht anderweitig angemerkt.
Verschiedene Aspekte einer sicheren Datenverschiebung verwenden einen sicheren Transcoder, dem nur äußere Schlüssel bereitgestellt werden (sodass der sichere Transcoder z.B. während des Transcodierungsprozesses die Daten nicht in der Klarform sieht). Das Ziel kann nur dem inneren Schlüssel bereitgestellt werden, wodurch ein direkter Zugriff auf Daten in dem Speichersystem und die Fähigkeit zu deren direktem Lesen und Entschlüsselung verhindert wird. Daten, die durch das Ziel in das Speichersystem geschrieben werden, werden mit einem äußeren Schlüssel, der von dem Transcoder empfangen wird, und einem inneren Schlüssel verschlüsselt, der von der Quelle empfangen wird. Mindestens manche der hierin beschriebenen Aspekte verbessern eine sichere Datenverschiebung unter Verwendung einer berechtigten Verschlüsselung, indem der sichere Transcoder modifiziert und ein sicheres Überprüferelement verwendet wird.
Eine auf ihre Berechtigung geprüfte Verschlüsselung (z.B. „authEncrypt“) und hierin beschriebene authEncrypt-Engines verwenden Schlüssel, die dem System bekannt sind. Registrierte Schlüssel können in Schlüssel-Servern erzeugt und/oder gespeichert werden, und registrierte Schlüssel sind nur für authEncrypt verfügbar. Gemäß bevorzugten Aspekten sind registrierte Schlüssel für Anwendungen nicht verfügbar. Schlüssel, die dem System nicht bekannt sind, können durch authEncrypt nicht verwendet werden (z.B. werden nicht verwendet). AuthEncrypt kann nur durch berechtigte Anwendungen verwendet werden. Gemäß verschiedenen Ansätzen verwaltet ein Richtlinienverwalter auf eine nach dem Stand der Technik bekannte Weise Berechtigungsinformationen für die Anwendungen. Zum Beispiel kann eine Richtlinie in einem XACML-Derivat (eXtensible Access Control Markup Language) mit zugehörigen Richtliniendurchsetzungspunkten, Richtlinienentscheidungspunkten usw. realisiert werden. Entsprechend wird eine unberechtigte Verschlüsselung in einem Speicher blockiert. Gemäß verschiedenen Ansätzen kann sich eine berechtigte Verschlüsselungsfunktion in dem Host befinden, und eine authEncrypt-Überprüfungsfunktion kann sich in dem Speicher und/oder in einem sicheren Transcoder befinden.
Gemäß einem beispielhaften, veranschaulichenden Aspekt enthält ein authEncrypt-System einen Host mit der Fähigkeit zum Schreiben in einen Speicher. Eine berechtigte Anwendung leitet alle zu verschlüsselnden Daten an eine authEncrypt-Engine weiter. Verschlüsselungsschlüssel werden in einem Schlüssel-Server erzeugt und gespeichert. Gemäß manchen Aspekten können Schlüssel durch die Anwendung bereitgestellt werden. Die authEncrypt-Engine überprüft, dass die Daten nicht bereits verschlüsselt sind. Gemäß mindestens manchen hierin beschriebenen Aspekten wird die Anforderung zurückgewiesen, wenn die Daten verschlüsselt sind. Ransomware ist nicht in der Lage, verschlüsselte Daten in einem Speicher abzulegen. Wenn die Ransomware ihren eigenen Verschlüsselungsschlüssel verwendet, werden die mit dem Verschlüsselungsschlüssel der Ransomware verschlüsselten Daten erkannt, und es wird blockiert, dass sie in einen Speicher geschrieben werden. Wenn die Daten nicht verschlüsselt sind, leitet die authEncrypt-Engine die Daten durch eine Verschlüsselungs-Engine, die die Daten mit einem der Anforderung zugehörigen Schlüssel verschlüsselt. Die Verschlüsselungs-Engine (z.B. eine berechtigte Verschlüsselungsfunktion) kann z.B. in Hardware, in einem Beschleuniger, einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) usw. gekapselt werden, was die Sicherheit für die Schlüssel und den Verschlüsselungsprozess im Allgemeinen erhöht. Nach der Verschlüsselung werden die Daten unter Verwendung eines Wasserzeichenschlüssels mit einem Wasserzeichen versehen, bevor die verschlüsselten Daten an das Speichersystem weitergeleitet werden. Das Speichersystem hat Zugriff auf den Wasserzeichenschlüssel-Server und kann überprüfen, dass die Verschlüsselung berechtigt ist (indem es z.B. prüft, ob das Wasserzeichen gültig ist), bevor die Daten in den Speicher geschrieben werden. Wenn das Speichersystem die Daten und das Wasserzeichen empfängt, greift das Speichersystem unabhängig auf den Wasserzeichenschlüssel-Server zu und berechnet das Wasserzeichen, um zu überprüfen, dass die Daten nicht modifiziert wurden. Die Daten werden nur dann in den Speicher geschrieben, wenn die Wasserzeichenüberprüfung erfolgreich ist. Gemäß bevorzugten Aspekten werden alle in den Speicher geschriebenen Daten unter Verwendung einer berechtigten Verschlüsselung gespeichert, und Klartext wird nicht in einem Speicher gespeichert. Verschlüsselung und Entschlüsselung sind vorteilhafterweise auf berechtigte Anwendungen beschränkt. Der Zugriff auf Verschlüsselungsschlüssel ist auf die berechtigte Verschlüsselungsvertrauenszone beschränkt. Versuche, unberechtigte verschlüsselte Daten zu schreiben, werden erkannt und in einem Speicher blockiert (die unberechtigten verschlüsselten Daten werden z.B. nicht gespeichert). Ein Berechtigen einer neuen Anwendung kann eine Attestierung der Anwendung und/oder eine manuelle Mehrparteien-Berechtigung erfordern, wie dies nach dem Stand der Technik bekannt ist. Gemäß bevorzugten Aspekten verschlüsseln nur berechtigte Anwendungen Daten, indem sie eine Doppelverschlüsselungs-Engine verwenden. Gemäß mindestens manchen Aspekten kann die gesamte Verschlüsselung unter Verwendung einer bzw. mehrerer Doppelverschlüsselungs-Engines erfolgen. Mindestens manche Aspekte der vorliegen Offenbarung erweitern die berechtigte Verschlüsselung, indem sie in dem Prozess der Wasserzeichenüberprüfung und Berechtigungsprüfung einen sicheren Transcoder realisieren.
Gemäß verschiedenen Aspekten wird davon ausgegangen, dass die gesamte Datenübertragung zwischen getrennten Komponenten über wechselseitig auf ihre Berechtigung geprüften (z.B. verschlüsselten) Sitzungen erfolgt. Es kann ebenfalls davon ausgegangen werden, dass alle in dem System gespeicherten Daten verschlüsselt werden. Gemäß mindestens manchen Ansätzen kann eine Vorkehrung für unverschlüsselte Daten enthalten sein, wobei unverschlüsselte Daten jedoch nicht gegen eine Exfiltration geschützt sein können.
Mindestens manche der hierin beschriebenen Aspekte sind vorteilhafterweise mit symmetrischen Verschlüsselungsmethoden verwendbar, woraus sich gegenüber Verschlüsselungsverfahren mit einem öffentlichen Schlüssel eine vergleichsweise höhere Leistung beim Übertragen von Daten zwischen Knoten in einem System ergibt.
Gemäß verschiedenen Aspekten der vorliegenden Offenbarung können jeweils die folgenden Begriffe definiert werden. Dabei sollte für den Fachmann klar sein, dass die folgenden Begriffe nicht auf die im Anschluss bereitgestellten Definitionen beschränkt sind. Vielmehr sind diese Definitionen beispielhaft und können einen größeren oder kleineren inhaltlichen Umfang enthalten, wie gemäß verschiedenen Aspekten der vorliegenden Offenbarung dargelegt wird.
Gemäß der Verwendung in der vorliegenden Offenbarung kann sich ein Knoten auf ein System oder eine Komponente beziehen, das bzw. die Anwendungsdaten verarbeitet. Ein Knoten kann einen Computer, einen CPU-Prozessor, einen GPU-Prozessor, eine Instanz einer virtuellen Maschine, einen Container, ein beliebiges anderweitiges Verarbeitungselement usw. oder eine beliebige Kombination hiervon enthalten.
Gemäß der Verwendung in der vorliegenden Offenbarung kann sich ein Wasserzeichen-Token auf einen eindeutigen Bezeichner beziehen, der aus verschlüsselten Daten, einem Wasserzeichenschlüssel, einem weiteren Wasserzeichen-Token usw. berechnet wird. Ein Wasserzeichen-Token kann gemäß mindestens manchen Ansätzen unter Verwendung eines Hash-Werts mit Schlüssel berechnet werden, z.B. eines Nachrichten-Berechtigungsprüfungscodes auf Hash-Grundlage (Hash-based Message Authentication Code, HMAC). Wasserzeichen-Token können auf effiziente Weise unter Verwendung eines Berechtigungsprüfungs-Verschlüsselungsmodus erzeugt werden, z.B. eines Offset-Code-Book-Modus (OCB-Modus), eines integritätssensiblen, parallelisierbaren Modus (Integrity Aware Parallelizable Modus, IAPM) usw. Gemäß mindestens manchen Ansätzen können Wasserzeichen-Token unter Verwendung zusätzlicher Informationen wie z.B. einer logischen Blockadresse (Logical Block Address, LBA), einer Folgenummer usw. erzeugt werden, um Substitutionsangriffe zu vermeiden. Gemäß mindestens einem Ansatz kann das während einer Verschlüsselung durch die obigen Modi erzeugte Berechtigungsprüfungs-Token als das Wasserzeichen-Token für die verschlüsselten Daten verwendet werden. Gemäß dem obigen Ansatz werden die Token bei der Entschlüsselung überprüft. Gemäß bevorzugten Aspekten werden Wasserzeichen-Token verwendet, um Wasserzeichen zu erzeugen. Entsprechend ist eine Entität, die Zugriff auf verschlüsselte Daten und den Wasserzeichenschlüssel hat, nicht in der Lage, ein gültiges Wasserzeichen zu erzeugen, ohne Zugriff auf das gültige Wasserzeichen-Token und/oder den gültigen Wasserzeichen-Token-Schlüssel zu haben.
Gemäß mindestens einem Aspekt kann ein Wasserzeichen-Token ohne Zugriff auf ein gespeichertes Wasserzeichen-Token überprüft werden, wenn ein vertrauenswürdiger Überprüfer Zugriff auf den Wasserzeichen-Token-Schlüssel hat. Eine Überprüfung wird erreicht, indem das Wasserzeichen-Token neu generiert und das neu generierte Wasserzeichen-Token verwendet wird, um das gespeicherte Wasserzeichen zu überprüfen (das z.B. unter Verwendung des Wasserzeichen-Tokens erzeugt wurde). Gemäß einem alternativen Aspekt muss das Wasserzeichen-Token nicht in einen Speicher geschrieben werden. Wenn das Wasserzeichen-Token jedoch nicht in einen Speicher geschrieben wird, kann ein Benutzer außerhalb der Vertrauenszone die Wasserzeichen nicht überprüfen, ohne Zugriff auf den Wasserzeichen-Token-Schlüssel zu haben. Wasserzeichenüberprüfer ohne Zugriff auf den Wasserzeichen-Token-Schlüssel wie z.B. Wasserzeichen-Überprüfer, die sich in einem Speicher befinden, und Wasserzeichen-Überprüfer, die Benutzern außerhalb der Vertrauenszone zugehörig sind, müssen Zugriff auf das Wasserzeichen-Token erhalten. Gemäß einer alternativen Ausführungsform, bei der das Wasserzeichen-Token nicht zum Erzeugen des Wasserzeichens verwendet wird, sind Wasserzeichen und Wasserzeichen-Token voneinander unabhängig und können daher unabhängig voneinander gespeichert und überprüft werden.
Gemäß der Verwendung in der vorliegenden Offenbarung kann ein Wasserzeichen ein eindeutige Bezeichner sein, der aus verschlüsselten Daten, einem Wasserzeichenschlüssel, einem Wasserzeichen-Token usw. berechnet wird. Ein Wasserzeichen kann gemäß mindestens manchen Ansätzen unter Verwendung eines Hash-Werts mit Schlüssel wie z.B. eines Nachrichten-Berechtigungsprüfungscodes (HMAC) auf Hash-Grundlage berechnet werden. Gemäß mindestens manchen Aspekten können sich Wasserzeichen für verschlüsselte Daten auf beliebige Wasserzeichen und/oder Wasserzeichen-Token beziehen, die für verschlüsselte Daten berechnet werden. Wasserzeichen können mit oder ohne Wasserzeichen-Token erzeugt werden. Zum Beispiel können Wasserzeichen und Wasserzeichen-Token getrennt mit unterschiedlichen Schlüsseln (z.B. einem Wasserzeichenschlüssel und einem Wasserzeichen-Token-Schlüssel) erzeugt werden.
Wasserzeichen-Token-Schlüssel können nur mit Modulen gemeinsam genutzt werden, die zum Entschlüsseln der Daten berechtigt sind, für die das Token erzeugt wird. Das endgültige Ziel verschlüsselter Daten (wo die Daten z.B. verwendet werden) überprüft vorzugsweise das Wasserzeichen und das Wasserzeichen-Token auf allen Ebenen (z.B. innere und äußere Wasserzeichen wie beispielsweise Wasserzeichen und Wasserzeichen-Token auf jeder Ebene usw.).
Eine authEncrypt-Vertrauenszone, wie sie in der vorliegenden Offenbarung verwendet wird, weist einen Satz von Systemen und Komponenten auf, die wechselseitig auf ihre Berechtigung für die Erzeugung und Verwendung von Wasserzeichen-Token und Wasserzeichen mit einem berechtigten Zugriff auf einen gemeinsamen Wasserzeichenschlüssel-Verwalter und einen gemeinsamen Verschlüsselungsschlüssel-Verwalter geprüft werden. Die wechselseitige Berechtigungsprüfung ermöglicht Schreibvorgänge in einen Speicher, wobei der Speicher konfiguriert wird, um zu überprüfen, dass keine unberechtigte Verschlüsselung von Daten durchgeführt wird, die in den Speicher geschrieben werden. Gemäß mindestens manchen Aspekten können Knoten außerhalb der authEncrypt-Vertrauenszone ebenfalls authEncrypt verwenden und Wasserzeichenschlüssel mit Zonen gemeinsam nutzen, die Wasserzeichenschlüssel haben, die für eine gemeinsame Nutzung erzeugt werden.
Gemäß manchen Aspekten kann nicht davon ausgegangen werden, dass Knoten außerhalb der authEncrypt-Vertrauenszone alle authEncrypt-Operationen durchführen, und beim Empfangen von Daten von Knoten außerhalb der authEncrypt-Zone wird eine zusätzliche Überprüfung verwendet. Gemäß mindestens manchen Ansätzen sind Wasserzeichen und Wasserzeichenschlüssel, die von außerhalb der authEncrypt-Vertrauenszone stammen, nicht völlig vertrauenswürdig und müssen durch Knoten innerhalb der authEncrypt-Vertrauenszone überprüft werden. Gemäß bevorzugten Aspekten werden diese Wasserzeichen unter Verwendung vertrauenswürdiger Wasserzeichenschlüssel neu generiert, wenn sie durch einen sicheren Transcoder innerhalb der authEncrypt-Vertrauenszone empfangen werden. Daten, die von außerhalb der authEncrypt-Vertrauenszone empfangen werden, können mit einem Wasserzeichen versehen und doppelt verschlüsselt sein. Die Wasserzeichen sollten überprüft werden, wenn die Wasserzeichen und Wasserzeichenschlüssel zwar verfügbar, aber jedoch nicht völlig vertrauenswürdig sind.
Gemäß mindestens manchen der hierin beschriebenen Aspekte ist eine Doppel-authEncrypt-Engine eine berechtigte Verschlüsselungs-Engine, die einen Vorfilter, um zu überprüfen, dass Eingabedaten unverschlüsselt sind, eine erste Verschlüsselungs-Engine, die einen ersten Verschlüsselungsschlüssel verwendet, um erste verschlüsselte Daten zu erzeugen, eine zweite Verschlüsselungs-Engine, die einen zweiten Verschlüsselungsschlüssel verwendet, um zweite verschlüsselte Daten zu erzeugen, und einen Wasserzeichenerzeuger aufweist, um Wasserzeichen für die ersten verschlüsselten Daten und/oder die zweiten verschlüsselten Daten zu erzeugen. Gemäß mindestens manchen Ansätzen können die erste Verschlüsselungs-Engine und die zweite Verschlüsselungs-Engine mit denselben Hardware- und/oder Software-Modulen realisiert werden. Der Vorfilter ermittelt vorzugsweise, ob die Daten, die er empfängt, verschlüsselt wurden. Der Vorfilter kann in Hardware und/oder einem Software-Programm realisiert werden, um eine Analyse der Daten durchzuführen (z.B. zu ermitteln, ob die Daten verschlüsselt sind). Der Vorfilter kann eine statistische Analyse und/oder ein beliebiges anderes Mittel nach dem Stand der Technik verwenden, um auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte, zu ermitteln, ob die Daten verschlüsselt sind. Die Vorfilterfunktion ist vorteilhafterweise in der Lage, zu ermitteln, ob die Daten mit einem beliebigen Verschlüsselungsschlüssel verschlüsselt sind, und eine weitere Verarbeitung kontaminierter Daten zu verhindern. Zum Beispiel können die Daten durch einen Angreifer verschlüsselt werden, der Klartext durch verschlüsselten Text ersetzt hat, usw.
Gemäß einem beispielhaften Aspekt der vorliegenden Offenbarung führt eine Doppel-authEncrypt-Engine ein Verfahren durch, das ein Überprüfen, dass eingehende Daten unverschlüsselt sind, ein Verschlüsseln der eingehenden Daten unter Verwendung eine ersten Schlüssels, um erste verschlüsselte Daten zu erzeugen, ein Verschlüsseln der ersten verschlüsselten Daten unter Verwendung eines zweiten Schlüssels, um zweite verschlüsselte Daten zu erzeugen, und ein Erzeugen von Wasserzeichen für die ersten verschlüsselten Daten und/oder die zweiten verschlüsselten Daten aufweist.
Gemäß mindestens manchen Ansätzen empfängt ein Überprüfer innere verschlüsselte Daten und/oder ermittelt, dass entschlüsselte Daten nicht verschlüsselt sind. In der vorliegenden Offenbarung kann ein Überprüfer auch als ein sicherer Überprüfer, ein berechtigter Überprüfer, ein vertrauenswürdiger Überprüfer usw. bezeichnet werden. Der Überprüfer hat vorzugsweise Zugriff auf den Verschlüsselungsschlüssel, der zum Verschlüsseln der Daten verwendet wird, und verwendet den Verschlüsselungsschlüssel, um die Daten zu entschlüsseln. Gemäß manchen Aspekten können die entschlüsselten Daten von dem Überprüfer durch den Vorfilter des Überprüfers geleitet werden, um zu überprüfen (z.B. zu ermitteln), dass die Daten nicht verschlüsselt sind. Gemäß verschiedenen Aspekten hat der Überprüfer Zugriff auf den Wasserzeichen-Token-Schlüssel und das Wasserzeichen für die verschlüsselten Daten, um eine Überprüfung des Wasserzeichen-Tokens für die verschlüsselten Daten zu ermöglichen. Gemäß manchen Ansätzen kann durch den sicheren Überprüfer ein neues sicheres Wasserzeichen-Token erzeugt werden. Bei einer alternativen Realisierung empfängt der sichere Überprüfer doppelt verschlüsselte Daten zusammen mit den inneren und äußeren Wasserzeichen, Wasserzeichen-Token und Verschlüsselungsschlüsseln. Er überprüft alle Wasserzeichen, entschlüsselt die Daten und überprüft, dass die ursprünglichen Daten nicht verschlüsselt waren.
Gemäß mindestens manchen Aspekten der vorliegenden Offenbarung sind innere verschlüsselte Daten die ersten verschlüsselten Daten, die einmal durch eine Doppelverschlüsselungs-Engine verschlüsselt wurden, und äußere verschlüsselte Daten sind die verschlüsselten Daten, die durch das Verschlüsseln der inneren verschlüsselten Daten entstehen. Äußere verschlüsselte Daten können als die zweiten verschlüsselten Daten bezeichnet werden, die durch eine weitere Doppelverschlüsselungs-Engine erzeugt werden. Wenn äußere verschlüsselte Daten durch einen Transcoder oder durch ein Ziel erzeugt werden, das Daten an einen Transcoder überträgt, können diese Daten gemäß mindestens manchen Aspekten als dritte verschlüsselte Daten bezeichnet werden. Dritte verschlüsselte Daten können durch ein Entschlüsseln äußerer verschlüsselter Daten, woraus sich innere verschlüsselte Daten ergeben, und ein erneutes Verschlüsseln der inneren verschlüsselten Daten mit einem neuen Verschlüsselungsschlüssel erzeugt werden.
Je nach der gewünschten Realisierung kann der sichere Transcoder verschiedene Eigenschaften haben. Zum Beispiel transcodiert der sichere Transcoder in einer beispielhaften Realisierung die inneren Wasserzeichen nicht, während er das äußere Wasserzeichen transcodiert. Bei der obigen Realisierung überprüft der Transcoder das äußere Wasserzeichen und das äußere Wasserzeichen-Token, um davor zu schützen, dass der Speicher Daten und/oder das äußere Wasserzeichen verfälscht. Der Transcoder kann neue äußere Wasserzeichen-Token und neue äußere Wasserzeichen erzeugen. Der Transcoder kann die ursprünglichen inneren Wasserzeichen und die neuen äußeren Wasserzeichen an das Ziel senden. Das Ziel hat vorzugsweise Zugriff auf den ursprünglichen inneren Wasserzeichen-Token-Schlüssel und den inneren Wasserzeichenschlüssel, zusätzlich zu dem transcodierten äußeren Wasserzeichen-Token und den Wasserzeichenschlüsseln. Das Ziel überprüft alle Wasserzeichen und Wasserzeichen-Token auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.
Bei einer weiteren beispielhaften Realisierung überprüft der sichere Transcoder zusätzlich das innere Wasserzeichen, nicht jedoch das innere Wasserzeichen-Token. Das innere Wasserzeichen wird sowohl mit dem sicheren Transcoder als auch dem Ziel gemeinsam genutzt. Das innere Wasserzeichen-Token wird nur mit dem Ziel gemeinsam genutzt. Diese beispielhafte Realisierung stellt eine frühestmögliche Erkennung von Problemen bereit und minimiert zugleich das Vertrauen in den sicheren Transcoder.
Bei einer alternativen beispielhaften Realisierung werden alle Wasserzeichen und Wasserzeichenschlüssel transcodiert (der sichere Transcoder hat z.B. Zugriff auf alle Wasserzeichenschlüssel). Das Ziel kann dann alle Wasserzeichen und Wasserzeichenschlüssel überprüfen (wobei das Ziel z.B. Zugriff auf die Schlüssel hat, die zum Erzeugen der transcodierten Wasserzeichen verwendet werden). Diese alternative Realisierung erfordert ein zusätzliches Vertrauen in den sicheren Transcoder.
Bei verschiedenen Aspekten der vorliegenden Offenbarung sollte für den Fachmann klar sein, dass jede hierin beschriebene Überprüfung als „erfolgreich“ (z.B. gültig) oder „nicht erfolgreich“ (z.B. ungültig) gelten kann. Der Zweck der Überprüfung besteht darin, zu ermitteln, ob ein Wasserzeichen gültig ist. Zum Beispiel kann eine beliebige hierin beschriebene Wasserzeichenüberprüfung als „erfolgreich“ gelten, wenn die Wasserzeichen „übereinstimmen“. Gemäß manchen Ansätzen müssen die Wasserzeichen identisch sein, um als „übereinstimmend“ zu gelten. Gemäß anderen Ansätzen muss ein vordefinierter Teil, Prozentsatz, eine vordefinierte Teilkomponente usw. der Wasserzeichen übereinstimmen. Entsprechend kann eine beliebige hierin beschriebene Wasserzeichen-Token-Überprüfung als „erfolgreich“ gelten, wenn die Wasserzeichen-Token „übereinstimmen“. Als Reaktion auf eine nicht erfolgreiche Überprüfung (wenn die Überprüfung z.B. „fehlschlägt“) kann eine weitere Verarbeitung jeglicher Daten, Wasserzeichen, Wasserzeichen-Token usw. blockiert werden (z.B. kann eine Meldung über die nicht erfolgreiche Überprüfung an den Anforderer gesendet werden, ein Fehler kann ausgegeben werden, eine weitere Verschlüsselung der Daten kann blockiert werden, die Schreib- und/oder Leseanforderung wird verweigert usw.). Gemäß mindestens manchen Ansätzen kann der Fehler protokolliert und/oder eine Warnmeldung an einen Benutzer gesendet werden. Gemäß einem Ansatz können mehrere Überprüfungen versucht werden, bevor eine weitere Verarbeitung blockiert wird. Gemäß einem weiteren Ansatz kann das System einen Mechanismus zum Wiederherstellen fehlgeschlagener Daten haben, z.B. ein Rekonstruieren des Blocks, wenn der Speicher als ein redundantes Array von unabhängigen Festplatten (Redundant Array of Independent Disks, RAID) konfiguriert wird, wie für den Fachmann verständlich sein dürfte.
Jeder Aspekt der vorliegenden Offenbarung kann auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte, auf Daten angewendet werden, die in einem Speicher, einem persistenten Speicher, einem nicht flüchtigen Speicher usw. oder in einer beliebigen Kombination hiervon gespeichert werden.
3 zeigt eine beispielhafte Realisierung einer berechtigten, sicheren Datenverschiebung unter Verwendung doppelter Wasserzeichen (Wasserzeichen-Token und Wasserzeichen werden z.B. sowohl für die ersten (z.B. inneren) als auch für die zweiten (z.B. äußeren) verschlüsselten Daten erzeugt). Zwei Wasserzeichen-Token-Schlüssel und zwei Wasserzeichenschlüssel werden verwendet. Gemäß einem beispielhaften Ansatz überprüft der Speicher bei einem Write-Direct-Befehl von einer Quelle (und/oder von einem Ziel über einen sicheren Transcoder, siehe 4) in einen Speicher das äußere Wasserzeichen auf Grundlage des äußeren Wasserzeichenschlüssels und des äußeren Wasserzeichen-Tokens.
3 ist eine Darstellung einer allgemeinen Architektur gemäß verschiedenen Konfigurationen. Die Architektur 300 kann gemäß der vorliegenden Erfindung in jeder der Umgebungen realisiert werden, die unter anderem in den 1 und 2 sowie 4 bis 11 in verschiedenen Konfigurationen dargestellt werden. Selbstverständlich können mehr oder weniger Elemente als in 3 ausdrücklich beschrieben in der Architektur 300 enthalten sein, wie für den Fachmann beim Lesen der vorliegenden Beschreibungen verständlich sein dürfte.
Die Architektur 300 veranschaulicht ein beispielhaftes Datensystem gemäß einem Aspekt. Die Architektur 300 enthält einen Eigentümer 302 (z.B. ein Hostsystem), der Daten erzeugt und die Daten an einen persistenten Datenspeicher übergibt. Der Eigentümer 302 weist mindestens eine berechtigte Anwendung 304 und eine Doppel-authEncrypt-Engine 306 auf. In der vorliegenden Offenbarung kann die Doppel-authEncrypt-Engine 306 auch als eine berechtigte Verschlüsselungsfunktion oder eine authEncrypt-Engine bezeichnet werden.
Eine beispielhafte Operation zum Verschlüsseln von Daten, die von der berechtigten Anwendung 304 gesendet werden, wird in 3 gezeigt. 3 stellt eine beispielhafte berechtigte Datenübertragung dar, bei der beide Seiten (z.B. ein Host und ein Ziel) Zugriff auf denselben Schlüssel-Server und denselben Wasserzeichenschlüssel-Server haben. Gemäß bevorzugten Aspekten wird die Berechtigung der berechtigten Anwendung 304 geprüft, und eine Erlaubnis der berechtigten Anwendung 304 zum Verwenden der Doppel-authEncrypt-Engine 306 wird geprüft, bevor Daten gesendet werden. Gemäß einem bevorzugten Aspekt fordert die berechtigte Anwendung 304 eine Berechtigung zum Verwenden von authEncrypt von dem Verwalter 308 an, bevor Daten gesendet werden. Der Verwalter 308 kann prüfen, ob eine (nicht gezeigte) Systemrichtlinien-Engine der Anwendung die Erlaubnis erteilt und den passenden Berechtigungsnachweis bereitstellt. Wenn die Anwendung bereits berechtigt ist, werden diese Berechtigungsnachweise gemäß einem alternativen Aspekt dem Verwalter 308 vorgelegt, bevor authEncrypt verwendet wird. Der Fachmann weiß, dass authEncrypt als eine gemeinsam genutzte Systemfunktion oder ein Dienst vor der Anwendung realisiert werden kann. Die Berechtigungsnachweise können für jede Instanz einer Anwendung eindeutig sein und verwendet werden, um sicherzustellen, dass alle Metadaten und Schlüssel angemessen korreliert werden. Die Erlaubnisse können auf jede nach dem Stand der Technik bekannte Weise und mit verschiedenen Sicherheitsniveaus geprüft werden, wie für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Gemäß einem Ansatz kann eine Zulassungsliste verwendet werden. Gemäß einem weiteren Ansatz können sichere Hash-Werte für eine Anwendung geprüft werden. Gemäß noch einem weiteren Ansatz kann eine vollständige Anwendungsattestierung durch eine Aufsichtsstelle durchgeführt werden. Wenn die Anwendung keine Verschlüsselungserlaubnis erhält, wird die Verarbeitung der Daten blockiert, sodass die Daten z.B. nicht über eine berechtigte Verschlüsselung verschlüsselt werden. Gemäß mindestens manchen Ansätzen kann eine Benachrichtigung protokolliert und/oder eine Warnmeldung an einen Administrator gesendet werden, die angibt, dass eine unberechtigte Anwendung versucht hat, auf authEncrypt zuzugreifen.
Sobald die Anwendung berechtigt ist (z.B. die berechtigte Anwendung 304), veranlasst die berechtigte Anwendung 304 durch einen Verwalter 308, dass ein ausgewählter Satz von Verschlüsselungsschlüsseln 314, die sich auf einem Schlüssel-Server 310 befinden, sowie zugehörige Wasserzeichenschlüssel 316, die sich auf einem Wasserzeichenschlüssel-Server 312 befinden, verwendet werden, um Daten, die durch die berechtigte Anwendung 304 erzeugt werden, zu verschlüsseln und mit einem Wasserzeichen zu versehen. Jeder Verschlüsselungsschlüssel kann der berechtigten Anwendung 304 zugehörig sein. Gemäß einem Ansatz kann jedes System einen einzigen Verschlüsselungsschlüssel haben, der für jede der berechtigten Anwendungen des Systems verwendet wird. Gemäß einem weiteren Ansatz kann jeder Verschlüsselungsschlüssel eine Funktion der Anwendung, des Benutzers, des Systemeigentümers, des Datensatzes, eines Satzes von Dateien, eines Satzes von Datenträgern usw. sein. Jede der obigen Informationen kann als eine Zugriffsanforderung durch die berechtigte Anwendung 304 an den Verwalter 308 gesendet werden. Der Verwalter 308 kann einen neuen Schlüssel erzeugen und/oder die Identität eines Verschlüsselungsschlüssels, Wasserzeichenschlüssels usw. ermitteln, der der Anforderung zugehörig ist. Der Verwalter 308 kann diese Informationen (z.B. eine Anforderung für einen neuen Schlüssel oder eine neue Information, die der Identität eines Verschlüsselungsschlüssels und/oder eines Wasserzeichenschlüssels zugehörig ist, der der Anforderung zugehörig ist) an den Schlüssel-Server 310 und/oder den Wasserzeichenschlüssel-Server 312 senden.
Gemäß einem alternativen Ansatz führt der Schlüssel-Server 310 und/oder der Wasserzeichenschlüssel-Server 312 als Reaktion auf eine Anforderung an den Schlüssel-Server 310 und/oder den Wasserzeichenschlüssel-Server 312 von dem Verwalter 308 für eine Erzeugung eines neuen Schlüssels eine Schlüsselerzeugung durch.
Gemäß bevorzugten Aspekten wird der Verwalter 308 in die Doppel-authEncrypt-Engine 306 integriert. Gemäß manchen Ansätzen kann der Verwalter 308 in eine TEE in dem Host integriert werden (z.B. außerhalb der Doppel-authEncrypt-Engine 306). Bei noch weiteren Ansätzen kann der Verwalter 308 in den Schlüssel-Server 310, den Wasserzeichenschlüssel-Server 312, eine getrennte sichere Komponente wie z.B. ein Hardware-Sicherheitsmodul (Hardware Security Module, HSM) oder eine TEE in einem weiteren Host usw. integriert werden. Bei jedem dieser alternativen Ansätze werden alle Verbindungen zwischen dem Verwalter 308 und anderen Komponenten mit einer Berechtigungsprüfung, einer Verschlüsselung, einem Integritätsschutz usw. geschützt, um die Sicherheit der Daten zu gewährleisten.
Gemäß bevorzugten Aspekten enthält der Schlüssel-Server 310 mindestens einen Satz von Verschlüsselungsschlüsseln 314, die die Doppel-authEncrypt-Engine 306 zum Verschlüsseln der Daten verwendet. Gemäß weiteren bevorzugten Ansätzen wird der Satz von Verschlüsselungsschlüsseln 314 in dem Schlüssel-Server 310 gespeichert und ist für die berechtigte Anwendung 304 nicht verfügbar. Entsprechend sind die in dem Wasserzeichenschlüssel-Server 312 gespeicherten Wasserzeichenschlüssel 316 für die berechtigte Anwendung 304 nicht verfügbar. Gemäß manchen Ansätzen kann der Verwalter 308 neue Schüssel erzeugen. Gemäß bevorzugten Ansätzen wird der Verwalter 308 auf eine nach dem Stand der Technik bekannte Weise über ein Hardware-Sicherheitsmodul (HSM), eine vertrauenswürdige Ausführungsumgebung (TEE) usw. sicher von der berechtigten Anwendung 304 isoliert. Gemäß verschiedenen hierin beschriebenen Aspekten kann eine Schlüsselbereitstellung auf eine sichere Weise durchgeführt werden, z.B. über eine verschlüsselte Verbindung oder unter Verwendung eines sicheren Schlüsselaustauschprotokolls.
Durch die berechtigte Anwendung 304 erzeugte Daten werden in einer Operation 318 an einen Vorfilter 320 in der Doppel-authEncrypt-Engine 306 übertragen. Der Vorfilter 320 überprüft, dass die Daten nicht zuvor verschlüsselt wurden. Wenn die Daten nicht verschlüsselt sind (z.B. die Überprüfung erfolgreich ist), werden die Daten in einer Operation 322 an einen inneren Verschlüssler 324 übertragen. Der innere Verschlüssler 324 erhält einen inneren Verschlüsselungsschlüssel 326 aus dem Satz von Verschlüsselungsschlüsseln 314, die sich in dem Schlüssel-Server 310 befinden. Der innere Verschlüsselungsschlüssel 326 kann auf Grundlage von Richtlinien, die durch die berechtigte Anwendung 304 und den Verwalter 308 für den Satz von zu schreibenden Daten festgelegt werden, aus dem Satz von Verschlüsselungsschlüsseln 314 ausgewählt werden. Der innere Verschlüssler 324 verschlüsselt die Daten unter Verwendung des inneren Verschlüsselungsschlüssels 326 und überträgt die verschlüsselten Daten (z.B. die inneren verschlüsselten Daten) in einer Operation 328 an den inneren Wasserzeichenerzeuger 330. Der innere Wasserzeichenerzeuger 330 erhält den inneren Wasserzeichen-Token-Schlüssel 332 und den inneren Wasserzeichenschlüssel 334, die dem inneren Verschlüsselungsschlüssel 326 zugehörig sind, um ein inneres Wasserzeichen-Token und ein inneres Wasserzeichen zu erzeugen. Der innere Wasserzeichenerzeuger 330 erzeugt ein inneres Wasserzeichen-Token und ein inneres Wasserzeichen für die inneren verschlüsselten Daten. Die inneren verschlüsselten Daten werden in einer Operation 336 an den äußeren Verschlüssler 338 übertragen. Der äußere Verschlüssler 338 verschlüsselt die inneren verschlüsselten Daten unter Verwendung des äußeren Verschlüsselungsschlüssels 340, der von dem Schlüssel-Server 310 erhalten wird, um äußere verschlüsselte Daten zu erzeugen. Die äußeren verschlüsselten Daten werden in einer Operation 342 an einen äußeren Wasserzeichenerzeuger 344 übertragen. Der äußere Wasserzeichenerzeuger 344 erhält einen äußeren Wasserzeichen-Token-Schlüssel 346 und einen äußeren Wasserzeichenschlüssel 348, um ein äußeres Wasserzeichen-Token und ein äußeres Wasserzeichen zu erzeugen. Der äußere Wasserzeichenerzeuger erzeugt das äußere Wasserzeichen-Token und das äußere Wasserzeichen für die äußeren verschlüsselten Daten. Die Doppel-authEncrypt-Engine 306 überträgt die äußeren verschlüsselten Daten, das innere Wasserzeichen-Token, das innere Wasserzeichen, das äußere Wasserzeichen-Token und das äußere Wasserzeichen in einer Operation 350 an das Speichersystem 352.
Das Speichersystem 352 kann eine weitere Verschlüsselung der verschlüsselten Daten und der zugehörigen Wasserzeichen und/oder Wasserzeichen-Token enthalten. Eine zusätzliche Verschlüsselung kann sicher realisiert werden, um einen Angreifer davon abzuhalten, die zusätzliche Verschlüsselung als ein Mittel zum Verschlüsseln von Daten zu verwenden, sodass der Eigentümer der Daten nicht in der Lage ist, die Daten zu entschlüsseln (z.B. die an das Speichersystem weitergeleiteten Daten zurückzuerhalten). Eine sichere Realisierung einer zusätzlichen Verschlüsselung kann selbstverschlüsselnde Speichereinheiten enthalten.
Gemäß manchen Aspekten kann das Speichersystem 352 das Speichern unverschlüsselter Daten unterstützen. Zum Speichern unverschlüsselter Daten kann die Vorfilterfunktion (z.B. der Vorfilter 320) zu dem Speichersystem 352 hinzugefügt werden, sodass das Speichersystem 352 zwischen verschlüsselten Daten und Klartextdaten (z.B. Daten in der Klarform, unverschlüsselte Daten usw.) unterscheiden kann, eine unberechtigte Verschlüsselung zurückweisen und somit die Speicherung von Klartextdaten zulassen kann. Dass die Speicherung von Klartext zugelassen wird, verringert den Schutz der Klartextdaten vor Exfiltrationsangriffen und sollte auf Daten beschränkt werden, die gegenüber einer unberechtigten Veröffentlichung weniger sensibel sind, wobei dies auf eine Weise erfolgen würde, die für den Fachmann bestimmbar wäre.
Gemäß verschiedenen Ansätzen kann jeder hierin beschriebene Wasserzeichenerzeuger eine Anzahl von Verfahren zum Erzeugen eines Werts verwenden, der die verschlüsselten Daten eindeutig identifiziert (z.B. ein für die verschlüsselten Daten erzeugtes Wasserzeichen). Gemäß einem bevorzugten Aspekt kann ein Nachrichten-Berechtigungsprüfungscode auf Hash-Grundlage (HMAC) mit Schlüssel auf eine Weise verwendet werden, die für den Fachmann verständlich ist. Die Hash-Funktionen können jede Form von Hash-Wert sein, abhängig von dem gewünschten Sicherheitsniveau, wobei dies durch den Fachmann bestimmbar wäre. Beispielhafte Hash-Funktionen enthalten MDS, SHA 256 usw. Gemäß einem Ansatz kann eine Hash-Funktion ohne einen HMAC verwendet werden, z.B. für eine SHA3-Hash-Funktion.
Das Speichersystem 352 kann jede Art von Speichersystem sein, die nach dem Stand der Technik bekannt ist. Dabei sollte für den Fachmann klar sein, dass das Speichersystem 352 weniger oder mehr Komponenten aufweisen kann, als sie hierin aufgeführt werden.
Gemäß verschiedenen Aspekten weist das Speichersystem 352 einen Speicherüberprüfer 354 auf. Der Speicherüberprüfer 354 erhält den äußeren Wasserzeichenschlüssel 348 für die zu schreibenden Daten von dem Wasserzeichenschlüssel-Server 312. Der Speicherüberprüfer 354 überprüft auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte, das äußere Wasserzeichen, indem er den äußeren Wasserzeichenschlüssel 348 verwendet. Wenn die Überprüfung erfolgreich ist, werden die Daten in einer Operation 358 in den Speicher 356 geschrieben.
Gemäß einer beispielhaften Operation in 3 werden durch den Eigentümer 302 geschriebene Daten aus dem Speichersystem 352 abgerufen, um durch einen Zielbenutzer 360 verarbeitet zu werden. Die äußeren verschlüsselten Daten (z.B. die doppelt verschlüsselten Daten) und das bzw. die zugehörigen Wasserzeichen und/oder das bzw. die Wasserzeichen-Token können über den sicheren Transcoder 362 aus dem Speichersystem 352 gelesen und in einer Operation 364 an einen äußeren authEncrypt-Überprüfer 366 übertragen werden, der sich in dem sicheren Transcoder 362 befindet. Der sichere Transcoder 362 erhält den äußeren Wasserzeichen-Token-Schlüssel 346 von dem Schlüssel-Server 310 und den äußeren Wasserzeichenschlüssel 348 von dem Wasserzeichenschlüssel-Server 312. Der äußere Speicherüberprüfer 366 überprüft auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte, sowohl das äußere Wasserzeichen als auch das äußere Wasserzeichen-Token. Wenn sowohl das äußere Wasserzeichen als auch das äußere Wasserzeichen-Token korrekt überprüft werden, werden die äußeren verschlüsselten Daten in einer Operation 368 an den äußeren Entschlüssler 370 übertragen. Der äußere Entschlüssler 370 erhält den äußeren Verschlüsselungsschlüssel 340 von dem Schlüssel-Server 310. Der äußere Entschlüssler 370 entschlüsselt die äußeren verschlüsselten Daten unter Verwendung des äußeren Verschlüsselungsschlüssels 340, um die inneren verschlüsselten Daten zu erzeugen. Die inneren verschlüsselten Daten werden in einer Operation 372 an den inneren authEncrypt-Überprüfer 374 übertragen. Der innere authEncrypt-Überprüfer 374 erhält den inneren Wasserzeichenschlüssel 334 von dem Wasserzeichenschlüssel-Server 312 und verwendet den inneren Wasserzeichenschlüssel 334, um das innere Wasserzeichen zu überprüfen. Wenn das innere Wasserzeichen erfolgreich überprüft wird, werden die inneren verschlüsselten Daten in einer Operation 376 an den äußeren Verschlüssler 378 des sicheren Transcoders übertragen. Der äußere Verschlüssler 378 des sicheren Transcoders erhält einen äußeren Schlüssel 380 für eine gemeinsame Nutzung von dem Schlüssel-Server 310 und verwendet den äußeren Schlüssel 380 für eine gemeinsame Nutzung, um die inneren verschlüsselten Daten zu verschlüsseln und neue äußere verschlüsselte Daten zu erzeugen. Die neuen äußeren verschlüsselten Daten (z.B. dritte verschlüsselte Daten) werden in einer Operation 381 an den Wasserzeichenerzeuger 382 des sicheren Transcoders übertragen. Der Wasserzeichenerzeuger 382 des sicheren Transcoders erhält einen Wasserzeichen-Token-Schlüssel 384 von dem Schlüssel-Server 310 und den Wasserzeichenschlüssel 383 von dem Wasserzeichenschlüssel-Server 312. Der Wasserzeichenerzeuger 382 des sicheren Transcoders erzeugt ein neues Wasserzeichen-Token und ein neues Wasserzeichen für die neuen äußeren verschlüsselten Daten für eine gemeinsame Nutzung. Die äußeren verschlüsselten Daten für eine gemeinsame Nutzung und die zugehörigen inneren und äußeren Wasserzeichen-Token und Wasserzeichen werden in einer Operation 385 an eine Doppel-authEncrypt-Engine 386 des Zielbenutzers 360 übertragen.
Verschlüsselte Daten, die von der Doppel-authEncrypt-Engine 386 des Zielbenutzers 360 empfangen werden, werden an den äußeren Überprüfer 387 weitergeleitet. Der äußere Überprüfer 387 erhält den Wasserzeichenschlüssel 383 von dem Wasserzeichenschlüssel-Server 312 und den Wasserzeichen-Token-Schlüssel 384 von dem Schlüssel-Server 310. Der äußere Überprüfer 387 überprüft die äußeren Wasserzeichen und Wasserzeichen-Token auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Wenn die Überprüfung erfolgreich ist, werden die äußeren verschlüsselten Daten in einer Operation 388 an den äußeren Entschlüssler 389 übertragen. Der äußere Entschlüssler 389 erhält den äußeren Schlüssel 380 für eine gemeinsame Nutzung von dem Schlüssel-Server 310 und entschlüsselt die äußeren verschlüsselten Daten, um innere verschlüsselte Daten zu erzeugen. Die inneren verschlüsselten Daten werden in einer Operation 390 an den inneren Überprüfer 391 übertragen. Der innere Überprüfer 391 erhält den inneren Wasserzeichen-Token-Schlüssel 332 von dem Schlüssel-Server 310 und den inneren Wasserzeichenschlüssel 334 von dem Wasserzeichenschlüssel-Server 312. Der innere Überprüfer 391 überprüft das Wasserzeichen und das Wasserzeichen-Token für die inneren verschlüsselten Daten auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Wenn die Überprüfung erfolgreich ist, werden innere verschlüsselte Daten in einer Operation 392 an den inneren Entschlüssler 393 übertragen. Der innere Entschlüssler 393 erhält den inneren Verschlüsselungsschlüssel 326 von dem Schlüssel-Server 310. Der innere Entschlüssler 393 verwendet den inneren Verschlüsselungsschlüssel 326, um die inneren verschlüsselten Daten in Klartextdaten zu entschlüsseln. Wenn die Entschlüsselung erfolgreich ist, werden die Daten (z.B. die Klartextdaten) in einer Operation 394 für eine Verarbeitung an die berechtigte Anwendung 395 des Zielbenutzers 360 übertragen. Während eines Datenschreibens durch den Eigentümer 302 wird die Zugehörigkeit der entsprechenden Schlüssel zu bestimmten geschriebenen oder gelesenen Daten durch den Verwalter 308 des Eigentümers 302 verwaltet. Des Weiteren wird auch während eines Datenlesens durch den Zielbenutzer 360 die Zugehörigkeit der passenden Schlüssel zu bestimmten geschriebenen oder gelesenen Daten durch den Verwalter 396 des Zielbenutzers 360 verwaltet.
Gemäß verschiedenen Aspekten kann der Eigentümer 302 bestehende Daten auf eine Weise bezeichnen, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Gemäß der Erörterung in der vorliegenden Offenbarung kann sich „Daten“ auf eine Datei, ein Objekt, einen Datenblock, einen Bereich von Datenblöcken usw. oder eine beliebige Kombination hiervon beziehen. „Bestehende Daten“ kann sich auf jede Datei, jedes Objekt, jeden Datenblock, jeden Bereich bzw. alle Bereiche von Datenblöcken usw. oder auf eine beliebige Kombination hiervon beziehen, die unter Anwendung verschiedener der hierin beschriebenen Richtlinien gespeichert werden bzw. auf die unter Anwendung dieser Richtlinien zugegriffen wird. Zum Beispiel kann der Eigentümer 302 gegenüber dem Verwalter 308 angeben, ob die berechtigte Anwendung 304 neue Daten erzeugt und/oder sich auf bestehende Daten bezieht (z.B. Daten, die mindestens gemäß den oben ausführlich beschriebenen Aspekten gespeichert werden). Gemäß einem weiteren Ansatz kann der Eigentümer 302 Daten bereitstellen, die angeben, ob der Eigentümer 302 und/oder die berechtigte Anwendung 304 einen Nur-Lese- oder Lese/Schreib-Zugriff auf die bestehenden Daten anfordern. Wenn die berechtigte Anwendung 304 nicht mit Berechtigungsnachweisen des Eigentümers ausgeführt wird, kann die berechtigte Anwendung 304 Zugriff auf die Daten haben, wie dies durch die Richtlinie bestimmt wird, die durch den Eigentümer 302 festgelegt wird. Wenn der Eigentümer 302 der Verschlüsselungsschlüssel gespeicherte Daten liest, durchlaufen die gespeicherten Daten gemäß mindestens manchen Aspekten nicht den sicheren Transcoder 362, und der Eigentümer 302 (z.B. die Doppel-authEncrypt-Engine 306 auf der Seite des Eigentümers) kann ein bzw. mehrere Wasserzeichen und/oder Wasserzeichen-Token auf eine Weise überprüfen, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.
Gemäß verschiedenen Ansätzen können beim Durchführen der hierin beschriebenen und in 3 gezeigten Schreiboperation die folgenden Definitionen und Operationen anwendbar sein:
Definitionen:

pi = Eingabe-Klartext i
ci = Ausgabe-Chiffriertext für pi
cci = Ausgabe-Chiffriertext für ci
sei = gemeinsam genutzter Ausgabe-Chiffriertext für ci
twi = inneres Wasserzeichen-Token für ci
txi = äußeres Wasserzeichen-Token für cci
tvi = gemeinsam genutztes äußeres Wasserzeichen-Token für sei
kp, kr, ko = innere, äußere bzw. gemeinsam genutzte Datenschlüssel (z.B. Verschlüsselungsschlüssel von Schlüssel-Server)
h1, h2, j1 = innere, äußere bzw. gemeinsam genutzte Wasserzeichen-Token-Schlüssel
w1, w2, v1 = innere, äußere bzw. gemeinsam genutzte Wasserzeichenschlüssel (z.B. von dem Wasserzeichenschlüssel-Server)
wi, xi, vi = innere, äußere bzw. gemeinsam genutzte Wasserzeichen

Es ist darauf zu verweisen, dass eine fortlaufende Nummerierung (wie z.B. ko1, ko2 usw.) verwendet wird, um Vielfache einer Komponente anzugeben (wie z.B. in den 3 bis 6 gezeigt). Zum Beispiel kann sich sowohl ko1 als auch ko2 auf Verschlüsselungsschlüssel beziehen, wobei eine unterschiedliche Nummerierung, sofern nicht anderweitig angemerkt, für verschiedene Verschlüsselungsschlüssel steht, wie für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.
Erzeugung von Doppel-authEncrypt-Daten in der Quelle:

           get kp, kr, h1, h2 von Schlüssel-Server
           get w1, w2 von Wasserzeichen(ws)-Server
           ci = encrypt(kp, pi)
           twi = HMAC(h1, ci)
           wi = HMAC(w1, ci | | twi)
           cci= encrypt(kr, ci)
           txi = HMAC(h2, cci)
           xi = HMAC(w2, cci | | txi)
           An den Speicher senden: {cci, twi, wi, txi, xi}
           Überprüfung von Doppel-authEncrypt-Daten in Speicher:
           Get w2 von ws-Server
           xi' = HMAC(w2, cci | | txi)
           verify xi == xi'
           Speichern der Daten, falls überprüft
           Vertrauenswürdiges Transcodieren beim Lesen aus Speicher für Ziel: 



           Lesen der Daten:
           Get kr, h2 von Schlüssel-Server
           read(cci, twi, wi, txi, xi) aus Speicher
           get w2 von ws-Server
           xi' = HMAC(w2, cci | | txi)
           verify xi == xi'
           txi' = HMAC(h2, cci)
           verify txi == txi'
           ci = decrypt(kr, cci)
           get w1 von ws-Server
           wi' = HMAC(w1, ci | | twi)
           verify wi == wi'

Transcodieren (äußere Verschlüsselung mit neuem Schlüssel) und Erzeugen von gemeinsam genutztem Wasserzeichen:

           Get v1 von ws-Server
           Get ko, j1 von Schlüssel-Server
           sei = encrypt(ko, ci)
           tvi = HMAC(j1, sci)
           vi = HMAC(v1, sci | | tvi)
           Senden an Ziel: {sci, twi, wi, tvi, vi}

In Ziel (Überprüfung von inneren und äußeren Verschlüsselungen):

           Read {sci, twi, wi, tvi, vi} aus Transcoder
           get kp, ko, h1, j1 von Schlüssel-Server
           get w1, v1 von ws-Server
           vi' = HMAC(v1, sci | | tvi)
           verify vi == vi'
           tvi' = HMAC(j1, sci)
           verify tvi == tvi'
           ci = decrypt(ko, sci)
           wi' = HMAC(w1, ci | | twi)
           verify wi == wi'
           twi' = HMAC(h1, ci)
           verify twi == twi'
           pi = decrypt(kp, ci)

Gemäß mindestens manchen Ansätzen können die Wasserzeichen-Token-Schlüssel gespeichert und von einem Schlüssel-Server erhalten werden, und andere Wasserzeichenschlüssel können gespeichert und von einem getrennten Wasserzeichenschlüssel-Server (z.B. dem Wasserzeichenschlüssel-Server) erhalten werden. Andere Anordnungen zum Erhalten unterschiedlicher Schlüssel von demselben oder verschiedenen Schlüssel-Servern können auf eine Weise realisiert werden, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürften.

Bei verschiedenen Aspekten mit doppelten Wasserzeichen und Wasserzeichen-Token können der Quelleigentümer und das Ziel der Daten alle Wasserzeichen und Wasserzeichen-Token vollständig überprüfen, um zu überprüfen, dass sowohl die innere Verschlüsselung als auch die äußere Verschlüsselung durch authEncrypt-Engines unter Verwendung von berechtigten Schlüsseln durchgeführt wurde. Transcoder können alle Wasserzeichen und Wasserzeichen-Token mit Ausnahme des inneren Wasserzeichen-Tokens überprüfen. Transcoder sind nicht in der Lage, ein falsches inneres Wasserzeichen-Token zu erzeugen, das dem Transcoder erlauben würde, bestimmte Datensubstitutionsangriffe durchzuführen. Der Speicher kann das äußere Wasserzeichen, nicht jedoch das innere Wasserzeichen überprüfen. Der Speicher kann weder das Wasserzeichen-Token für die innere noch für die äußere Verschlüsselung fälschen. In der bevorzugten Umgebung hat der Speicher keinen Zugriff auf den äußeren Verschlüsselungsschlüssel oder den äußeren Wasserzeichen-Token-Schlüssel.

Gemäß manchen Ansätzen können andere Arten von Wasserzeichen ein Bilden eines Hash-Werts der verschlüsselten Daten und ein Verschlüsseln des Hash-Werts mit dem Wasserzeichenschlüssel, ein Bilden eines Hash-Werts der verschlüsselten Daten mit dem Wasserzeichenschlüssel usw. enthalten. Asymmetrische Verschlüsselungsmethoden wie PKI-Signaturen können verwendet werden, wobei ein Hash-Wert von verschlüsselten Daten anschließend mit einem privaten Schlüssel verschlüsselt wird. Der öffentliche Schlüssel kann zum Überprüfen der Signatur verwendet werden, wie für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.

Der Fachmann kann die verschiedenen hierin beschriebenen Operationen modifizieren, um auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte, auf Grundlage der Entwurfsanforderungen und der Auswahl von Operationen, die zum Erzeugen des Wasserzeichens verwendet werden, ein gewünschtes Sicherheitsniveau zu erreichen. Das Wasserzeichen stellt die Fähigkeit bereit, die Gültigkeit der Verschlüsselung zu prüfen, ohne den Verschlüsselungsschlüssel zu kennen. Das Wasserzeichen-Token stellt die Fähigkeit bereit, Veränderungen an dem Wasserzeichen und/oder den verschlüsselten Daten zu erkennen und zugleich eine Widerstandskraft gegenüber Fälschungen bereitzustellen. Aufgrund der höheren erreichbaren Leistung, der Widerstandskraft gegenüber Quantenangriffen, den kleineren Schlüsselgrößen usw. wird die Durchführung dieser Operationen unter Verwendung der symmetrischen Verschlüsselung häufig bevorzugt.

Gemäß verschiedenen Aspekten der vorliegenden Offenbarung können Überprüfer das berechnete Wasserzeichen mit dem Wasserzeichen vergleichen, das mit den verschlüsselten Daten empfangen wurde (und auf ähnliche Weise berechnete Wasserzeichen-Token mit den empfangenen Wasserzeichen-Token). Wenn die Wasserzeichen nicht übereinstimmen, werden die verschlüsselten Daten nicht gespeichert. Gemäß manchen Ansätzen müssen die Wasserzeichen in einem vordefinierten Ausmaß übereinstimmen. Zum Beispiel müssen die Wasserzeichen gemäß manchen Ansätzen identisch sein, um als „übereinstimmend“ zu gelten. Gemäß anderen Ansätzen muss ein vordefinierter Teil, Prozentsatz, eine vordefinierte Teilkomponente usw. der Wasserzeichen übereinstimmen. Gemäß mindestens manchen Aspekten kann als Reaktion auf ein Ermitteln, dass die Wasserzeichen nicht übereinstimmen, eine Benachrichtigung protokolliert und/oder eine Warnmeldung an einen Administrator gesendet werden, die angibt, dass versucht wurde, unberechtigte Daten zu speichern. Die Überprüfung kann durchgeführt werden, ohne dass der Überprüfer Zugriff auf den Klartext des Schlüssels hat, der zum Erzeugen des Chiffriertexts (z.B. der verschlüsselten Daten) verwendet wird. Wenn das Wasserzeichen als ein verschlüsselter Hash-Wert (z.B. als eine PKI-Signatur) erzeugt wird, enthält die Erkennungsoperation des Überprüfers gemäß einem Ansatz ein Entschlüsseln des Wasserzeichens unter Verwendung des Wasserzeichenschlüssels und ein Vergleichen des entschlüsselten Wasserzeichens mit einem für die verschlüsselten Daten berechneten Hash-Wert auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Der Überprüfer kann überprüfen, dass die Daten mit authEncrypt verschlüsselt und zu keinem Zeitpunkt modifiziert werden, wie beispielsweise beim Lesen, während Bereinigungsoperationen (z.B. zum Prüfen der Datenintegrität) usw.

Das Erkennen, dass die Eingabedaten verschlüsselt sind, kann auf eine nach dem Stand der Technik bekannte Weise erfolgen. Zum Beispiel können die Daten von einer berechtigten Anwendung ein Format und/oder eine Eigenschaft haben, die aus den unverschlüsselten Daten ermittelt werden kann, in den verschlüsselten Daten jedoch nicht vorhanden ist. Andere Methoden zum Erkennen einer Verschlüsselung der Eingabedaten enthalten eine Entropiemessung, statistische Tests, die verwendet werden, um einem zu verschlüsselnden Datenelement eine Wahrscheinlichkeit zuzuweisen, usw. Das System kann eine Mehrzahl von Daten-Chunks, Blöcken usw. verwenden, um die Genauigkeit der Erkennungswahrscheinlichkeit zu verbessern. Wenn das Speichersystem einen fortlaufenden Datenschutz, Momentaufnahmen oder ein anderes Mittel zum vorläufigen Speichern von Daten unterstützt (z.B. ein Rollback unterstützt), kann die Erkennung erfolgen, nachdem eine vorgegebene Anzahl von Datenelementen verarbeitet wurde. Ereignisse wie Momentaufnahmen können durch eine hohe Wahrscheinlichkeit ausgelöst werden, dass eine verschlüsselte Eingabe erkannt wird.

Gemäß mindestens manchen Aspekten können die Verschlüsselungsschlüssel, die Wasserzeichenschlüssel, die Wasserzeichen-Token-Schlüssel, die Schlüssel für eine gemeinsame Nutzung usw. in Schlüssel-Servern gespeichert werden. Für eine zusätzliche Widerstandsfähigkeit können die Schlüssel-Server verteilte Schlüssel-Server sein. Jeder Satz von Schlüsseln, die Schlüssel für eine gemeinsame Nutzung, die Wasserzeichen-Token-Schlüssel und/oder die Wasserzeichenschlüssel können in einem eindeutigen Schlüssel-Server gespeichert werden. Gemäß einem weiteren Ansatz kann ein einziger Schlüssel-Server eine beliebige Kombination von Schlüsseln verarbeiten. Gemäß einem bevorzugten Aspekt kann für Elastizität und Fehlertoleranz jeder Satz von Schlüsseln k zwischen m Servern aufgeteilt werden, sodass k < m Server notwendig sind, um einen Schlüssel auf eine dem Fachmann bekannte Weise zu erhalten. Die Schlüssel, die Schlüssel für eine gemeinsame Nutzung, die Wasserzeichen-Token-Schlüssel und/oder Wasserzeichenschlüssel können auf eine andere nach dem Stand der Technik bekannte Weise gespeichert werden. Zum Beispiel können die Schlüssel, die Schlüssel für eine gemeinsame Nutzung, die Wasserzeichen-Token-Schlüssel und/oder Wasserzeichenschlüssel in getrennten Speichereinheiten oder in derselben Speichereinheit gespeichert werden, oder die Schlüssel, die gemeinsam genutzten Schlüssel, die Wasserzeichen-Token-Schlüssel und/oder die Wasserzeichenschlüssel können durch Schlüsselverwalter eines nach dem Stand der Technik bekannten Typs erzeugt und/oder verwaltet werden. Die Schlüssel, die Schlüssel für eine gemeinsame Nutzung, die Wasserzeichen-Token-Schlüssel und/oder die Wasserzeichenschlüssel können in dem Hostsystem, dem Speichersystem oder einer beliebigen Kombination hiervon usw. gespeichert werden. Wie in 3 gezeigt, werden die Schlüssel und die Wasserzeichenschlüssel getrennt gespeichert, um eine Isolierung bereitzustellen. Containerartige Systeme oder TEEs können verwendet werden, um die Schlüssel, die Schlüssel für eine gemeinsame Nutzung, die Wasserzeichen-Token-Schlüssel und/oder die Wasserzeichenschlüssel von Systemadministratoren, anderen Benutzern ohne Root-Berechtigungen usw. zu isolieren.

Mindestens eine beispielhafte Realisierung einer sicheren Datenverschiebung, wie sie hierin bereitgestellt wird, verwendet eine ausschließlich innere Wasserzeichenerstellung, wobei der Speicher nicht auf die inneren verschlüsselten Daten zugreifen kann und dadurch die Wasserzeichenüberprüfung, wie sie weiter oben hierin beschrieben wird, nicht durchführen kann. Bei einer ausschließlich inneren Wasserzeichenerstellung erfolgen alle Schreibvorgänge in den Speicher durch den sicheren Transcoder, der die Wasserzeichenüberprüfung durchführt (z.B. kann es keinen physischen Pfad zum Schreiben in einen Speicher geben, der nicht durch den sicheren Transcoder verläuft). Der Transcoder überprüft das Wasserzeichen beim Schreiben (der Transcoder hat z.B. Zugriff auf den Wasserzeichenschlüssel).

Da der Speicher auf die inneren verschlüsselten Daten nicht zugreifen kann, kann das Speichersystem kein gefälschtes inneres Wasserzeichen erzeugen. Dies verringert die Notwendigkeit eines Wasserzeichen-Tokens. Wenn das Wasserzeichen-Token jedoch entweder eine logische Blockadresse (LBA) oder eine Folgenummer enthält, um gegen andere Angriffe (z.B. veraltete Daten und/oder Ersatzdaten von einer weiteren LBA) zu schützen, stellt das Wasserzeichen-Token außerdem einen Schutz gegen einen Angriff durch den Transcoder bereit. Gemäß bevorzugten Aspekten wird die LBA und/oder eine Folgenummer verwendet, um das Wasserzeichen-Token zu erzeugen und/oder das Wasserzeichen-Token zu überprüfen. Auch wenn die LBA und/oder die Folgenummer zum Erzeugen des Wasserzeichen-Tokens verwendet wird, wird gemäß verschiedenen bevorzugten Aspekten ein Wasserzeichen-Token verwendet, um das Maß an Vertrauen zu verringern, das von dem Transcoder gefordert wird.

Gemäß einem Aspekt der ausschließlich inneren Wasserzeichenerstellung transcodiert der Transcoder das Wasserzeichen nicht. Der Transcoder hat nur Zugriff auf den Wasserzeichenschlüssel, um beim Schreiben eine Überprüfung vorzunehmen, er hat jedoch keinen Zugriff auf den Wasserzeichen-Token-Schlüssel. Das Ziel überprüft das Wasserzeichen und hat Zugriff auf den Wasserzeichenschlüssel. Das Ziel überprüft das Wasserzeichen-Token und hat Zugriff auf den Wasserzeichen-Token-Schlüssel.

Gemäß einem alternativen Aspekt der ausschließlich inneren Wasserzeichenerstellung transcodiert der Transcoder das Wasserzeichen. Der Transcoder prüft das Wasserzeichen beim Lesen aus einem Speicher und hat Zugriff auf den Wasserzeichenschlüssel. Der Transcoder erzeugt ein neues Wasserzeichen mit einem neuen Wasserzeichenschlüssel, der mit dem Ziel gemeinsam genutzt wird. Gemäß mindestens manchen Ansätzen kann der Transcoder das Wasserzeichen-Token überprüfen, wobei der Transcoder Zugriff auf den Wasserzeichen-Token-Schlüssel und etwaige zusätzliche Daten wie z.B. die LBA (z.B. inhärent bekannt) und/oder die Folgenummer hat. Dieser Aspekt erfordert ein zusätzliche Vertrauen in den Transcoder. Der Transcoder kann unter Verwendung eines neuen Wasserzeichen-Tokens, das mit dem Ziel gemeinsam genutzt werden soll (um z.B. das Wasserzeichen-Token zu überprüfen), ein neues Wasserzeichen-Token erzeugen.

Gemäß noch einem weiteren alternativen Aspekt der ausschließlich inneren Wasserzeichenerstellung kann der Transcoder das Wasserzeichen-Token nicht überprüfen, woraufhin der Wasserzeichen-Token-Schlüssel und ergänzende Informationen für eine Überprüfung des Wasserzeichen-Tokens mit dem Ziel gemeinsam genutzt werden.

Gemäß verschiedenen Ansätzen können unter Verwendung der weiter oben ausführlich beschriebenen Definitionen die folgenden Operationen anwendbar sein, um ein Lesen aus einem Speicher für eine gemeinsame Nutzung mit einem Ziel durchzuführen, bei dem sowohl das Wasserzeichen-Token als auch das Wasserzeichen durch den Transcoder transcodiert werden.

Für die ausschließlich inneren Wasserzeichenerstellung führt die Quelle die folgenden Operationen durch:


           get kp, kr von Schlüssel-Server

           get h1, w1 von ws-Server

           ci = encrypt(kp, pi)

           twi = HMAC(h1, ci)



           wi = HMAC(w1, ci | | twi)

           cci = encrypt(kr, ci)

           An den sicheren Transcoder senden: {cci, twi, wi}

Nachdem die berechtigte Verschlüsselung abgeschlossen ist, werden die Daten mit einem zweiten Schlüssel (kr) verschlüsselt, um äußere verschlüsselte Daten zu erzeugen, bevor sie durch den sicheren Transcoder an einen Speicher gesendet werden. Der sichere Transcoder entschlüsselt die äußeren verschlüsselten Daten, um eine Überprüfung des Wasserzeichens für die inneren verschlüsselten Daten zu ermöglichen, bevor die äußeren verschlüsselten Daten und Wasserzeichen wie unten beschrieben an einen Speicher gesendet werden:

           get kr von Schlüssel-Server



           read(cci, twi, wi) aus Quelle


           ci = decrypt(kr, cci)

           get w1 von ws-Server

           wi' = HMAC(w1, ci | | twi)

           verify wi == wi'

Wenn die Überprüfung erfolgreich ist, wird der Block (cci, twi, wi) in einen Speicher geschrieben. Wenn die Überprüfung nicht erfolgreich ist, gibt es ein Problem mit dem Block, und der Block sollte nicht geschrieben werden.

Der sichere Transcoder kann auch einen darin enthaltenen Verwalter haben, der verwendet wird, um die Verbindungen zu Zielen zu verwalten. Wenn eine berechtigte Anwendung eine Anwendung in einem Zielsystem für einen Zugriff auf Daten berechtigt, informiert die berechtigte Anwendung den Verwalter (der z.B. sowohl der berechtigten Verschlüsselung als auch der sicheren Datenübertragung zugehörig ist). Der Verwalter informiert den Schlüssel-Server und den Wasserzeichenschlüssel-Server mit einer Zugriffserlaubnis von der entfernt angeordneten Anwendung. Die Fähigkeiten des Verwalters ermöglichen dem sicheren Transcoder, den äußeren Schlüssel zu erteilen, sodass die entfernt angeordnete Anwendung die Daten lesen kann, und den Schlüssel-Server zu berechtigen, einer authEncrypt-Engine in dem entfernt angeordneten System den Transcodierungsschlüssel und den inneren Schlüssel zu erteilen.

Beim Lesen aus einem Speicher für eine Übertragung an ein Ziel führt der Transcoder die folgenden Operationen durch:

           Lesen der Daten:



           get kr von Schlüssel-Server


           read(cci, twi, wi) aus Speicher

           ci = decrypt(kr, cci)

           Überprüfen der inneren verschlüsselten Daten

           get w1 von ws-Server

           wi' = HMAC(w1, ci | | twi)

           verify wi == wi'

           get h1 von ws-Server

           twi' = HMAC(h1, ci)

           verify twi == twi'

           Erzeugen eines neuen, gemeinsam genutzten Wasserzeichens:


           get v1 von ws-Server

           get ko, j1 von Schlüssel-Server

           tvi = HMAC(j1, ci)

           vi = HMAC(v1, ci | | tvi)

           sei = encrypt(ko, ci)

           An Ziel senden: {sci, tvi, vi}

Um den Klartext aus der Berechnung zu erhalten, führt die Ziel-authEncrypt-Engine in dem Ziel die folgenden Operationen durch:

           Entschlüsseln des äußeren Blocks:

           read {sci, tvi, vi} aus Transcoder

           get ko von Schlüssel-Server

           ci = decrypt(ko, sci)

           Überprüfen der Wasserzeichen:

           get v1 von ws-Server

           vi' = HMAC(v1, ci | | tvi)

           verify vi == vi'

           get j1 von ws-Server

           tvi' = HMAC(j1, ci)

           verify tvi == tvi'

           Erhalten von Zugriff auf den Klartext:

           get kp von Schlüssel-Server

           pi = decrypt(kp, ci)

Ein weiterer beispielhafter Aspekt einer berechtigten, sicheren Datenverschiebung enthält eine ausschließlich äußere Wasserzeichenerstellung, wobei das Wasserzeichen-Token und das Wasserzeichen auf Grundlage der zweiten (z.B. äußeren) verschlüsselten Daten erzeugt werden. Bei einer ausschließlich äußeren Wasserzeichenerstellung prüft der Speicher das Wasserzeichen bei einem Write-Direct-Befehl von der Quelle, wenn der Wasserzeichenschlüssel mit einem Speicher gemeinsam genutzt wird. Das Wasserzeichen kann durch einen Speicher gefälscht werden, weshalb das Wasserzeichen-Token beim Lesen aus einem Speicher geprüft wird. Der Transcoder transcodiert das Wasserzeichen beim Transcodieren der äußeren verschlüsselten Daten. Das ursprüngliche Wasserzeichen stimmt nicht mit den transcodierten äußeren verschlüsselten Daten überein.

Um das Wasserzeichen zu transcodieren, überprüft der Transcoder das Wasserzeichen in den ursprünglichen äußeren verschlüsselten Daten. Der Transcoder hat vorzugsweise Zugriff auf den Wasserzeichenschlüssel. Das Wasserzeichen-Token wird ebenfalls durch den Transcoder transcodiert, wobei der Transcoder auch Zugriff auf den Wasserzeichen-Token-Schlüssel hat. Der Transcoder verwendet das neue Wasserzeichen-Token und die neuen Wasserzeichenschlüssel, um das Wasserzeichen-Token und das Wasserzeichen für die neuen äußeren verschlüsselten Daten zu erzeugen. Die äußeren verschlüsselten Daten, das Wasserzeichen-Token und das Wasserzeichen werden an das Ziel übertragen. Das Ziel ist vorzugsweise berechtigt, sowohl auf das Wasserzeichen-Token als auch auf die Wasserzeichenschlüssel zuzugreifen. Das Ziel überprüft sowohl das Wasserzeichen als auch das Wasserzeichen-Token. Der Transcoder weist vorzugsweise eine Doppel-authEncrypt-Engine auf.

Gemäß dem obigen Aspekt gilt der Transcoder für äußere Verschlüsselungsschlüssel als vertrauenswürdig, während er für innere Verschlüsselungsschlüssel als nicht vertrauenswürdig gilt. Für Wasserzeichenschlüssel und Wasserzeichen-Token-Schlüssel gilt der Transcoder als völlig vertrauenswürdig. Das Ziel gilt für Wasserzeichenschlüssel als vertrauenswürdig (z.B. auf dieselbe Weise, wie das Ziel für äußere Verschlüsselungsschlüssel als vertrauenswürdig gilt). Das Ziel überprüft sowohl das Wasserzeichen als auch das Wasserzeichen-Token.

Die ausschließlich äußere Wasserzeichenerstellung kann nicht überprüfen, dass die innere Verschlüsselung zu einem Zurückschreiben von einem Ziel berechtigt ist. Das Ziel kann womöglich mit einem gefälschten inneren Schlüssel neu verschlüsseln und mit dem äußeren Schlüssel ein gültiges Wasserzeichen erzeugen. In diesem Fall kann ein Ransomware-Angriff in dem Ziel erfolgen, bei dem nur das äußere Wasserzeichen verwendet wird. Der Transcoder muss dahingehend als vertrauenswürdig gelten können, dass er authEncrypt für die inneren verschlüsselten Daten nicht umgeht, und zwar auf ähnliche Weise, wie ein Vertrauen in den Speicher gegeben sein muss, falls keine Wasserzeichen vorhanden sind oder falls die Wasserzeichen-Token nicht verwendet werden.

Die folgenden Operationen veranschaulichen eine beispielhafte Realisierung einer ausschließlich äußeren Wasserzeichenerstellung:

           In Quelle:

           get kp, kr, h1 von Schlüssel-Server 

           ci = encrypt(kp, pi)

           cci = encrypt(kr, ci)

           get w1 von Wasserzeichenschlüssel-Server

           txi = HMAC(h1, cci)

           xi = HMAC(w1, cci | | txi)

           Senden an Speicher: {cci, txi, xi}

           Beim Lesen aus Speicher in vertrauenswürdigem Transcoder:

           Lesen der Daten:

           get kr, h1 von Schlüssel-Server

           read (cci, txi, xi) aus Speicher

           get w1 von ws-Server

           xi' = HMAC(w1, cci | | txi)

           verify xi == xi'

           txi' = HMAC(h1, cci)

           verify txi == txi'

           ci = decrypt(kr, cci)

           Erzeugen eines gemeinsam genutzten Wasserzeichens:

           get ko, j1 von Schlüssel-Server

           get v1 von ws-Server

           sei = encrypt(ko, ci) 

           tvi = HMAC(j1, sci)

           vi = HMAC(v1, sci | | tvi)

           an Ziel senden: {sci, tvi, vi}

           In Ziel:

           read {sci, tvi, vi} aus Transcoder

           get kp, ko, j1 von Schlüssel-Server

           get v1 von ws-Server

           vi' = HMAC(v1, sci | | tvi)

           verify vi == vi'

           tvi' = HMAC(j1, sci)

           verify tvi == tvi'

           ci = decrypt(ko, sci)

           pi = decrypt(kp, ci)

Eine beispielhafte Realisierung einer berechtigten, sicheren Datenverschiebung enthält einen hybriden Ansatz für eine innere/äußere Wasserzeichenerstellung. Bei dem Ansatz für eine innere/äußere Wasserzeichenerstellung wird das Wasserzeichen-Token auf Grundlage der inneren (z.B. ersten) verschlüsselten Daten gebildet. Das Wasserzeichen wird auf Grundlage des Wasserzeichen-Tokens und der äußeren (z.B. zweiten) verschlüsselten Daten erzeugt.

Der Speicher überprüft das Wasserzeichen auf Grundlage des Zugriffs auf das Wasserzeichen, das Wasserzeichen-Token, die äußeren verschlüsselten Daten und den Wasserzeichenschlüssel. Die Daten werden somit auf sichere Weise direkt von der Quelle in den Speicher geschrieben. Ein Speicher muss für Verschlüsselungsschlüssel nicht als vertrauenswürdig gelten, und er muss der Datenquelle nicht vertrauen. Ein Speicher benötigt nur einen vertrauenswürdigen, berechtigten Zugriff auf die Wasserzeichenschlüssel. Beim Abrufen aus einem Speicher überprüft die ursprüngliche Quelle das Wasserzeichen-Token, um nachzuweisen, dass die Daten durch den Speicher nicht manipuliert wurden.

Der Transcoder transcodiert das äußere Wasserzeichen, da es das innere Wasserzeichen-Token und die äußere Verschlüsselung zur Grundlage hat, die durch den Transcoder geändert wird. Da der Transcoder das Wasserzeichen transcodiert, überprüft der Transcoder das Wasserzeichen sowohl bevor die äußere Verschlüsselung transcodiert als auch bevor ein neues Wasserzeichen erzeugt wird. Der Transcoder hat vorzugsweise Zugriff auf den Wasserzeichenschlüssel und das Wasserzeichen-Token. Das Transcoderverhalten funktioniert gemäß mindestens zwei Ansätzen.

Gemäß einem der beispielhaften Ansätze transcodiert der Transcoder das Wasserzeichen-Token nicht. Der Transcoder überprüft das Wasserzeichen-Token beim Lesen aus einem Speicher. Der Speicher kann kompromittierte Daten ersetzen und ein gültiges äußeres Wasserzeichen erzeugen. Der Transcoder hat Zugriff auf den Wasserzeichen-Token-Schlüssel. Wenn der Transcoder das Wasserzeichen-Token nicht überprüft, wird die Erkennung einer möglichen Korruption durch einen Speicher so lange verzögert, bis das Wasserzeichen-Token in dem Ziel überprüft wird. Das transcodierte Wasserzeichen wird mit dem Ziel gemeinsam genutzt. Der Wasserzeichen-Token-Schlüssel wird mit dem Ziel geteilt. Dieser Ansatz erfordert ein zusätzliches Vertrauen in den Transcoder dahingehend, dass dieser korrumpierte innere verschlüsselte Daten nicht ersetzt.

Gemäß einem weiteren beispielhaften Ansatz transcodiert der Transcoder das Wasserzeichen-Token. Das Wasserzeichen-Token wird verwendet, um zu verhindern, dass der Speicher ein gültiges Wasserzeichen erzeugt. Der Speicher hat Zugriff auf das Wasserzeichen-Token und den Wasserzeichenschlüssel. Der Speicher hat keinen Zugriff auf den Wasserzeichen-Token-Schlüssel. Wenn der Speicher ein neues (z.B. falsches) Wasserzeichen erzeugt, wird das falsche Wasserzeichen gemäß bevorzugten Aspekten durch einen Transcoder und/oder die Quelle erkannt, da das durch die Quelle erzeugte Wasserzeichen die verschlüsselten Daten und einen Wasserzeichen-Token-Schlüssel zur Grundlage hat und nicht mit dem falschen Wasserzeichen übereinstimmt, das durch den Speicher erzeugt wird. Der Transcoder hat vorzugsweise Zugriff auf den Wasserzeichen-Token-Schlüssel. Der Transcoder kann unter Verwendung eines neuen Wasserzeichen-Token-Schlüssels ein neues Wasserzeichen-Token erzeugen (z.B. transcodiert er das Wasserzeichen) und das neue Wasserzeichen-Token mit dem Ziel gemeinsam nutzen. Wenn Daten durch ein Ziel gelesen werden, überprüft der Transcoder entsprechend sowohl das äußere Wasserzeichen als auch das innere Wasserzeichen, um sicherzustellen, dass beide gültig sind. Das Ziel kann sowohl das Wasserzeichen als auch das Wasserzeichen-Token überprüfen.

Nachfolgend werden ausführliche, beispielhafte Operationen einer hybriden Wasserzeichenerstellung dargelegt, bei denen der Transcoder das Wasserzeichen-Token nicht transcodiert (und die z.B. ein zusätzliches Vertrauen in den Transcoder erfordern):

           In Quelle:

           get kp, kr, h1 von Schlüssel-Server

           get w1 von ws-Server

           ci = encrypt(kp, pi)

           twi = HMAC(h1, ci)

           cci = encrypt(kr, ci)

           xi = HMAC(w1, cci | | twi)

           an Speicher senden: {cci, twi, xi}

           Vertrauenswürdiges Transcodieren:

           Lesen der Daten:

           Get kr, h1 von Schlüssel-Server

           read (cci, twi, xi) aus Speicher

           get w1 von ws-Server

           xi' = HMAC(w1, cci | | twi)

           verify xi == xi'

           ci = decrypt(kr, cci)

           twi' = HMAC(h1, ci)

           verify twi == twi'

           Erzeugen eines gemeinsam genutzten Wasserzeichens: 

           get ko von Schlüssel-Server

           get v1 von ws-Server

           sei = encrypt(ko, ci)

           vi = HMAC(v1, sei | | twi)

           an Ziel senden: {sci, twi, vi}

           In Ziel:

           Read {sci, twi, vi} aus Transcoder

           get kp, ko, h1 von Schlüssel-Server

           get v1 von ws-Server

           vi' = HMAC(v1, sci | | twi)

           verify vi == vi'

           ci = decrypt(ko, sci)

           twi' = HMAC(h1, ci)

           verify twi == twi'

           pi = decrypt(kp, ci)

Unter erneuter Bezugnahme auf den bevorzugten Aspekt eines doppelten authEncrypt erzeugt die Doppel-authEncrypt-Engine Wasserzeichen-Token und Wasserzeichen sowohl für innere verschlüsselte Daten als auch für äußere verschlüsselte Daten. Ein Speicher ist nur berechtigt, auf den äußeren Wasserzeichenschlüssel zuzugreifen. Der sichere Transcoder hat Zugriff auf den inneren Wasserzeichenschlüssel, den äußeren Wasserzeichen-Token-Schlüssel und den äußeren Wasserzeichenschlüssel. Die Quellen und die Ziele haben Zugriff auf alle Wasserzeichenschlüssel für die verschlüsselten Daten. Ein Speicher überprüft das äußere Wasserzeichen, bevor Daten in den Speicher geschrieben werden. Der Transcoder überprüft vor einem Transcodieren den äußeren Wasserzeichenschlüssel, das äußere Wasserzeichen und das innere Wasserzeichen (nicht jedoch das innere Wasserzeichen-Token). Der Transcoder hat keinen Zugriff auf den inneren Wasserzeichen-Token-Schlüssel. Ein Zugriff auf den inneren Wasserzeichen-Token-Schlüssel würde den Transcoder in die Lage versetzen, die inneren verschlüsselten Daten durch alternative Daten zu ersetzen und ein gültiges Wasserzeichen-Token zu erzeugen.

Gemäß mindestens manchen der weiter oben ausführlich beschriebenen Aspekte werden Daten von dem Nicht-Eigentümer (Ziel) vorzugsweise doppelt verschlüsselt. 4 veranschaulicht den Datenfluss eines Ziels innerhalb der authEncrypt-Vertrauenszone, der ein Zurückschreiben von Daten in einen gemeinsam genutzten Speicher mit doppelten inneren und äußeren Wasserzeichen durchführt.

4 ist eine Darstellung einer allgemeinen Architektur gemäß verschiedenen Konfigurationen. Die Architektur 400 kann gemäß der vorliegenden Erfindung in jeder der Umgebungen realisiert werden, die unter anderem in den 1 bis 3 sowie 5 bis 11 in verschiedenen Konfigurationen dargestellt werden. Selbstverständlich können mehr oder weniger Elemente als in 4 ausdrücklich beschrieben in der Architektur 400 enthalten sein, wie für den Fachmann beim Lesen der vorliegenden Beschreibungen verständlich sein dürfte.

Die Architektur 400 veranschaulicht ein beispielhaftes Datensystem gemäß einem Aspekt. 4 teilt gemeinsame Komponenten mit 3, und dem Fachmann sollte klar sein, dass gemeinsame Merkmale eine gemeinsame Nummerierung und Funktionalität haben.

Der Zielbenutzer 360 innerhalb der authEncrypt-Zone verwendet die Doppel-authEncrypt-Engine 386 für Daten, die in einen Speicher zurückgeschrieben werden, auf die gleiche Weise wie für Daten, die von dem ursprünglichen Eigentümer in einen Speicher geschrieben werden (siehe beispielhafte 3). Gemäß einem beispielhaften Aspekt leitet die berechtigte Anwendung 395 die Daten in einer Operation 404 an den Vorfilter 402 weiter. Der Vorfilter 402 ermittelt auf eine ähnliche Weise wie weiter oben beschrieben, dass die Daten nicht verschlüsselt sind. Wenn die Daten nicht verschlüsselt sind, werden die Daten in einer Operation 406 an den inneren Verschlüssler 408 gesendet, der die Daten mit dem inneren Verschlüsselungsschlüssel 326 verschlüsselt, um innere verschlüsselte Daten zu erzeugen. Die inneren verschlüsselten Daten werden in einer Operation 410 an einen äußeren Wasserzeichenerzeuger 412 gesendet. Der innere Wasserzeichenerzeuger 412 empfängt den inneren Wasserzeichenschlüssel 334 von dem Wasserzeichenschlüssel-Server 312 und den inneren Wasserzeichen-Token-Schlüssel 332 von dem Schlüssel-Server 310. Der innere Wasserzeichenerzeuger 412 erzeugt gemäß mindestens manchen der hierin beschriebenen Aspekte ein inneres Wasserzeichen und ein inneres Wasserzeichen-Token. Die inneren verschlüsselten Daten, das innere Wasserzeichen und das innere Wasserzeichen-Token werden in einer Operation 414 an den äußeren Verschlüssler 416 gesendet, der den äußeren Schlüssel 380 für eine gemeinsame Nutzung verwendet, um äußere verschlüsselte Daten zu erzeugen. Die äußeren verschlüsselten Daten, das innere Wasserzeichen und das innere Wasserzeichen-Token werden in einer Operation 418 an den äußeren Wasserzeichenerzeuger 420 gesendet. Der äußere Wasserzeichenerzeuger 420 empfängt den Wasserzeichenschlüssel 383 von dem Wasserzeichenschlüssel-Server 312 und den Wasserzeichen-Token-Schlüssel 384 von dem Schlüssel-Server 310. Der äußere Wasserzeichenerzeuger 420 erzeugt gemäß mindestens manchen der hierin beschriebenen Aspekte ein äußeres Wasserzeichen und ein äußeres Wasserzeichen-Token für die äußeren verschlüsselten Daten.

Die äußeren verschlüsselten Daten, die inneren Wasserzeichen und die äußeren Wasserzeichen werden in einer Operation 422 an den sicheren Transcoder 362 übertragen. Der äußere Überprüfer 424 des sicheren Transcoders 362 überprüft das äußere Wasserzeichen unter Verwendung des Wasserzeichen-Token-Schlüssels 384, das von dem Wasserzeichenschlüssel-Server 312 erhalten wird, und des Wasserzeichen-Token-Schlüssels 384 von dem Schlüssel-Server 310. Wenn die Überprüfung erfolgreich ist, werden die äußeren verschlüsselten Daten in einer Operation 426 gesendet, um durch den äußeren Entschlüssler 428 unter Verwendung des äußeren Schlüssels 380 für eine gemeinsame Nutzung, der von dem Schlüssel-Server 310 erhalten wird, entschlüsselt zu werden. Die entschlüsselten Daten (z.B. die inneren verschlüsselten Daten) werden in einer Operation 430 an den inneren Überprüfer 432 gesendet. Der innere Überprüfer 432 erhält den inneren Wasserzeichenschlüssel 334 von dem Wasserzeichenschlüssel-Server 312 und überprüft das Wasserzeichen. Wenn die Überprüfung erfolgreich ist, werden die inneren verschlüsselten Daten in einer Operation 434 an den äußeren Entschlüssler 436 übertragen. Der äußere Verschlüssler 436 verschlüsselt die inneren verschlüsselten Daten unter Verwendung des äußeren Verschlüsselungsschlüssels 340, der von dem Schlüssel-Server 310 erhalten wird, um äußere verschlüsselte Daten zu erzeugen. Die äußeren verschlüsselten Daten werden in einer Operation 438 an den äußeren Wasserzeichenerzeuger 440 übertragen. Der äußere Wasserzeichenerzeuger 440 erhält den äußeren Wasserzeichen-Token-Schlüssel 346 von dem Schlüssel-Server 310 und den äußeren Wasserzeichenschlüssel 348 von dem Wasserzeichenschlüssel-Server 312. Der äußere Wasserzeichenerzeuger 440 erzeugt ein neues äußeres Wasserzeichen-Token und ein neues äußeres Wasserzeichen. Die inneren und äußeren Wasserzeichen-Token, die inneren und äußeren Wasserzeichen und die äußeren verschlüsselten Daten werden in einer Operation 442 an den Speicherüberprüfer 354 in dem Speichersystem 352 übertragen. Der Speicherüberprüfer 354 erhält den äußeren Wasserzeichenschlüssel 348 von dem Wasserzeichenschlüssel-Server 312 und überprüft das äußere Wasserzeichen. Wenn die Überprüfung erfolgreich ist, werden die verschlüsselten Daten, Wasserzeichen-Token und Wasserzeichen in einer Operation 444 in den Speicher 356 geschrieben.

Wenn sich das Ziel nicht innerhalb der authEncrypt-Vertrauenszone befindet, ist eine zusätzliche Überprüfung erforderlich. Wenn die Daten mit einem Wasserzeichen versehen sind und Wasserzeichenschlüssel mit dem Transcoder gemeinsam genutzt werden, überprüft der Transcoder zuerst alle Wasserzeichen und Wasserzeichen-Token. Es wird überprüft, ob es sich bei vollständig entschlüsselten Daten um unverschlüsselten Klartext handelt, da es keine Gewissheit gibt, dass vor einer Verschlüsselung außerhalb der authEncrypt-Vertrauenszone eine Vorfilteroperation einwandfrei angewendet wurde.

Gemäß bevorzugten Aspekten eines Datenaustauschs mit Knoten außerhalb der authEncrypt-Vertrauenszone unterstützt ein vertrauenswürdiger Überprüfer (z.B. ein sicherer Überprüfer) den sicheren Transcoder beim Transcodieren doppelt verschlüsselter Daten für einen Austausch mit einem Knoten außerhalb der authEncrypt-Vertrauenszone. Der vertrauenswürdige Überprüfer weist vier Elemente auf: einen Wasserzeichen-Token-Bezeichner, einen Datenentschlüssler, einen Vorfilter, der ermittelt, ob Daten verschlüsselt sind, und einen Wasserzeichen-Token-Erzeuger. Der vertrauenswürdige Überprüfer hat Zugriff auf innere Verschlüsselungsschlüssel und innere Wasserzeichen-Token-Schlüssel. Der vertrauenswürdige Überprüfer empfängt innere verschlüsselte Daten für eine Überprüfung. Gemäß mindestens manchen Aspekten gibt der vertrauenswürdige Überprüfer das Überprüfungsergebnis und neu erzeugte innere Wasserzeichen-Token aus. Der vertrauenswürdige Überprüfer exportiert keine verschlüsselten oder Klartextdaten. Der vertrauenswürdige Überprüfer kann in einer sicheren Enklave oder einer anderen geschützten Umgebung ausgeführt werden, um sicherzustellen, dass unverschlüsselte Daten nicht unberechtigt an andere Elemente des Systems weitergegeben werden.

Beim Austauschen von Daten mit Knoten außerhalb der authEncrypt-Vertrauenszone können die Wasserzeichenschlüssel der Vertrauenszone nicht mit externen Knoten gemeinsam genutzt werden. Daher werden die Wasserzeichen in einem anderen Satz von Wasserzeichenschlüsseln neu generiert, die mit dem externen Knoten gemeinsam genutzt werden. Während einer Transcodierungsoperation überprüft der Transcoder Wasserzeichen für äußere verschlüsselte Daten und generiert sie neu. Der Transcoder hat Zugriff auf den inneren verschlüsselten Wasserzeichenschlüssel. Indem dem Transcoder die gemeinsam genutzten äußeren Wasserzeichenschlüssel und der gemeinsam genutzte innere Wasserzeichenschlüssel bereitgestellt werden, kann der Transcoder beim Transcodieren von Daten, die an eine externe Quelle gesendet werden oder von dieser kommen, äußere Wasserzeichen-Token, äußere Wasserzeichen und innere Wasserzeichen überprüfen und neu generieren. Gemäß bevorzugten Aspekten hat der Transcoder keinen Zugriff auf den inneren Wasserzeichen-Token-Schlüssel oder den inneren Verschlüsselungsschlüssel. Der Transcoder kann nicht vollständig überprüfen, dass von einer externer Quelle stammende Daten nicht mit anderen als bekannten Schlüsseln verschlüsselt wurden, und kann innere Wasserzeichen-Token nicht überprüfen.

Beim Austauschen von Daten mit Knoten außerhalb der authEncrypt-Vertrauenszone leitet der Transcoder die inneren verschlüsselten Daten für eine Überprüfung und Neugenerierung von inneren Wasserzeichen-Token an einen sicheren Überprüfer weiter. Der sichere Überprüfer gilt sowohl für innere Verschlüsselungsschlüssel als auch für innere Wasserzeichen-Token-Schlüssel als vertrauenswürdig (z.B. sowohl für die Wasserzeichen-Token-Schlüssel der authEncrypt-Vertrauenszone als auch für die extern gemeinsam genutzten Wasserzeichen-Token-Schlüssel). Beim Austausch mit einem Knoten außerhalb der authEncrypt-Vertrauenszone werden innere verschlüsselte Daten an den sicheren Überprüfer weitergeleitet. Der sichere Überprüfer überprüft innere Wasserzeichen-Token, entschlüsselt die Daten und überprüft, dass der Klartext (z.B. die gerade entschlüsselten Daten) nicht verschlüsselt sind, wenn Daten von einer externen Quelle empfangen werden, und erzeugt ein neues Wasserzeichen-Token. Der sichere Überprüfer gibt die Überprüfungsbestätigung und das Wasserzeichen-Token an den Transcoder zurück. Der Transcoder hält das Transcodieren an und meldet einen Fehler, wenn der sichere Überprüfer keine erfolgreiche Überprüfung meldet. Ein sicherer Überprüfer führt keine Verschlüsselung durch und gibt verschlüsselte Daten nicht an den Transcoder zurück, sodass der sichere Überprüfer falsche verschlüsselte Daten nicht korrumpieren oder ersetzen kann.

Wenn verschlüsselte Daten transcodiert werden, um an Knoten außerhalb der Vertrauenszone gesendet zu werden, überprüft der sichere Überprüfer das innere Wasserzeichen-Token unter Verwendung eines inneren Wasserzeichen-Token-Schlüssels, der im Besitz der authEncrypt-Vertrauenszone ist, und erzeugt ein neues inneres Wasserzeichen-Token unter Verwendung des inneren Wasserzeichen-Token-Schlüssels, der mit dem externen Knoten gemeinsam genutzt wird. Der sichere Überprüfer gibt die Überprüfungsergebnisse und das neue Wasserzeichen-Token an den Transcoder zurück.

5 ist eine Darstellung einer allgemeinen Architektur gemäß verschiedenen Konfigurationen. Die Architektur 500 kann gemäß der vorliegenden Erfindung in jeder der Umgebungen realisiert werden, die unter anderem in den 1 bis 4 sowie 6 bis 11 in verschiedenen Konfigurationen dargestellt werden. Selbstverständlich können mehr oder weniger Elemente als in 5 ausdrücklich beschrieben in der Architektur 500 enthalten sein, wie für den Fachmann beim Lesen der vorliegenden Beschreibungen verständlich sein dürfte.

Die Architektur 500 veranschaulicht ein beispielhaftes Datensystem gemäß einem Aspekt. 5 teilt gemeinsame Komponenten mit 3 und anderen, und dem Fachmann sollte klar sein, dass gemeinsame Merkmale eine gemeinsame Nummerierung und Funktionalität haben. In 5 wird eine beispielhafte Operation eines Transcoders zum Senden von Daten an einen Knoten außerhalb der authEncrypt-Zone veranschaulicht.

Äußere verschlüsselte Daten und Wasserzeichen werden in einer Operation 364 von dem Speicher 356 an den äußeren authEncrypt-Überprüfer 366 übertragen, der sich in dem sicheren Transcoder 362 befindet. Der äußere authEncrypt-Überprüfer 366 erhält den äußeren Wasserzeichenschlüssel 348 von dem ersten Wasserzeichenschlüssel-Server 502 und den äußeren Wasserzeichen-Token-Schlüssel 346 von dem Schlüssel-Server 310. Bei einer erfolgreichen Überprüfung sendet der äußere authEncrypt-Überprüfer 366 die äußeren verschlüsselten Daten und Wasserzeichen in einer Operation 368 an den äußeren Entschlüssler 370. Der äußere Entschlüssler 370 entschlüsselt die Daten unter Verwendung des äußeren Verschlüsselungsschlüssels 340, um innere verschlüsselte Daten zu erzeugen. Innere verschlüsselte Daten und zugehörige innere Verschlüsselungswasserzeichen werden in einer Operation 504 an den sicheren Überprüfer 506 gesendet. Innere verschlüsselte Daten und das innere Verschlüsselungswasserzeichen werden in einer Operation 372 ebenfalls an den inneren authEncrypt-Überprüfer 374 gesendet. Der sichere Überprüfer 506 weist einen Überprüfer 508 auf, der das innere Wasserzeichen-Token überprüft. Wenn die Überprüfung erfolgreich ist, sendet der Überprüfer 508 die inneren verschlüsselten Daten in einer Operation 510 an einen inneren Wasserzeichen-Token-Erzeuger 512. Wenn die Überprüfung hingegen nicht erfolgreich ist, sendet der Überprüfer 508 eine Meldung über die nicht erfolgreiche Überprüfung in einer Operation 510 an einen inneren Wasserzeichen-Token-Erzeuger 512. Der innere Wasserzeichen-Token-Erzeuger 512 erhält den Wasserzeichen-Token-Schlüssel 384 von dem Schlüssel-Server 310, erzeugt ein neues Wasserzeichen-Token und überträgt das neue Wasserzeichen-Token und eine Überprüfungsnachricht in einer Operation 514 an den inneren Wasserzeichen-Erzeuger 516, der sich in dem sicheren Transcoder 362 befindet. Der innere authEncrypt-Überprüfer 374 erhält den inneren Wasserzeichenschlüssel 334 von dem ersten Wasserzeichenschlüssel-Server 502 und überprüft auf entsprechende Weise das Wasserzeichen. Wenn die Überprüfung sowohl durch den sicheren Überprüfer 506 als auch durch den inneren authEncrypt-Überprüfer 374 erfolgreich ist, werden die inneren verschlüsselten Daten in einer Operation 520 an den inneren Wasserzeichenerzeuger 516 weitergeleitet. Der innere Wasserzeichenerzeuger 516 erzeugt unter Verwendung des Wasserzeichenschlüssels 383, der von dem zweiten Wasserzeichenschlüssel-Server 518 erhalten wird, ein neues inneres Wasserzeichen. Gemäß bevorzugten Aspekten verwendet der innere Wasserzeichenerzeuger 516 zusätzlich zu den inneren verschlüsselten Daten und dem Wasserzeichenschlüssel 383 das tatsächliche Wasserzeichen-Token, das durch den inneren Wasserzeichen-Token-Erzeuger 512 in dem sicheren Überprüfer 506 erzeugt wird, als Eingabe zum Erzeugen des neuen inneren Wasserzeichens. Die inneren verschlüsselten Daten werden in einer Operation 522 an den äußeren Verschlüssler 378 des sicheren Transcoders übertragen. Der äußere Verschlüssler 378 des sicheren Transcoders erhält den äußeren Schlüssel 380 für eine gemeinsame Nutzung von dem Schlüssel-Server 310 und verschlüsselt die inneren verschlüsselten Daten, um äußere verschlüsselte Daten zu erzeugen. Äußere verschlüsselte Daten werden in einer Operation 524 an den äußeren Wasserzeichenerzeuger 526 übertragen. Der äußere Wasserzeichenerzeuger 526 erhält einen gemeinsam genutzten äußeren Wasserzeichenschlüssel 528 von dem zweiten Wasserzeichenschlüssel-Server 518 und den äußeren Wasserzeichen-Token-Schlüssel 530 von dem Schlüssel-Server 310. Der äußere Wasserzeichenerzeuger 526 erzeugt auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte, ein neues äußeres Wasserzeichen-Token und ein äußeres Wasserzeichen. Die äußeren verschlüsselten Daten, das innere Wasserzeichen-Token, das innere Wasserzeichen, das äußere Wasserzeichen-Token und das äußere Wasserzeichen werden in einer Operation 532 an den Zielbenutzer 360 übertragen.

Ein äußerer Überprüfer 534 in dem Zielbenutzer 360 verwendet den gemeinsam genutzten äußeren Wasserzeichenschlüssel 528 von dem zweiten Wasserzeichenschlüssel-Server 518 und den äußeren Wasserzeichen-Token-Schlüssel 530 von dem Schlüssel-Server 310, um das äußere Wasserzeichen zu überprüfen. Wenn die Überprüfung erfolgreich ist, werden äußere verschlüsselte Daten, das innere Wasserzeichen-Token, das innere Wasserzeichen, das äußere Wasserzeichen-Token und das äußere Wasserzeichen in einer Operation 536 an den äußeren Entschlüssler 389 übertragen, der die äußeren verschlüsselten Daten unter Verwendung des äußeren Schlüssels 380 für eine gemeinsame Nutzung von dem Schlüssel-Server 310 entschlüsselt, um innere verschlüsselte Daten zu erzeugen. Die inneren verschlüsselten Daten werden in einer Operation 538 an den inneren Überprüfer 540 gesendet, der den Wasserzeichenschlüssel 383, der von dem zweiten Wasserzeichenschlüssel-Server 518 erhalten wird, und den Wasserzeichen-Token-Schlüssel 384, der von dem Schlüssel-Server 310 erhalten wird, verwendet, um das innere Wasserzeichen und das innere Wasserzeichen-Token zu überprüfen. Wenn die Überprüfung erfolgreich ist, werden die inneren verschlüsselte Daten in einer Operation 542 an den inneren Entschlüssler 393 gesendet. Der innere Entschlüssler 393 erhält den inneren Verschlüsselungsschlüssel 326 von dem Schlüssel-Server 310. Der innere Entschlüssler 393 verwendet den inneren Verschlüsselungsschlüssel 326, um die inneren verschlüsselten Daten in Klartextdaten zu entschlüsseln. Wenn die Entschlüsselung erfolgreich ist, werden die Daten (z.B. die Klartextdaten) in einer Operation 394 für eine Verarbeitung an die berechtigte Anwendung 395 des Zielbenutzers 360 übertragen.

Gemäß bevorzugten Aspekten kann der sichere Transcoder den inneren verschlüsselten Chiffriertext nicht entschlüsseln, da diese Schlüssel nie mit dem Transcoder gemeinsam genutzt werden. Der Transcoder überprüft, dass die Daten durch einen berechtigten Verschlüssler und nicht zuerst durch Malware einwandfrei verschlüsselt wurden. Diese Überprüfung kann nach einem Entschlüsseln der äußeren verschlüsselten Daten und vor einem Transcodieren eines neuen äußeren verschlüsselten Schlüssels durchgeführt werden. Die inneren verschlüsselten Daten werden an einen vertrauenswürdigen Überprüfer weitergeleitet, der Zugriff auf den inneren Verschlüsselungsschlüssel, nicht jedoch auf den äußeren Verschlüsselungsschlüssel hat. Der vertrauenswürdige Überprüfer überprüft das innere Wasserzeichen-Token unter Verwendung des inneren Wasserzeichen-Token-Schlüssels, der mit dem externen Knoten gemeinsam genutzt wird. Wenn die Überprüfung erfolgreich ist, entschlüsselt der vertrauenswürdige Überprüfer die inneren verschlüsselten Daten und überprüft unter Verwendung einer Vorfilterfunktion für eine Verschlüsselungserkennung wie hierin beschrieben, dass die vollständig entschlüsselten Daten nicht verschlüsselt sind. Der Erfolg oder Misserfolg der Überprüfung wird dann an den Transcoder zurückgegeben, und die entschlüsselten Daten werden verworfen. Da die innere Verschlüsselung nicht durch eine authEncrypt-Engine innerhalb der authEncrypt-Vertrauenszone durchgeführt wurde, werden auf Grundlage von Wasserzeichen-Token-Schlüsseln und Wasserzeichenschlüsseln, die durch die Schlüssel-Server in der authEncrypt-Vertrauenszone erkannt und verwaltet werden, ein neues Wasserzeichen-Token und ein neues Wasserzeichen für die inneren verschlüsselten Daten erzeugt. Gemäß bevorzugten Aspekten sind diese Schlüssel dem inneren Verschlüsselungsschlüssel zugehörig, der mit der verschlüsselten Datenquelle gemeinsam genutzt wird, die sich außerhalb der authEncrypt-Vertrauenszone befindet. Der vertrauenswürdige Überprüfer erhält den inneren Wasserzeichen-Token-Schlüssel, erzeugt das Wasserzeichen-Token und leitet das Wasserzeichen-Token an den Transcoder weiter. Der Transcoder kann den neuen inneren Wasserzeichenschlüssel erhalten und das innere Wasserzeichen auf Grundlage der inneren verschlüsselten Daten und des inneren Wasserzeichen-Tokens erzeugen.

6 ist eine Darstellung einer allgemeinen Architektur gemäß verschiedenen Konfigurationen. Die Architektur 600 kann gemäß der vorliegenden Erfindung in jeder der Umgebungen realisiert werden, die unter anderem in den 1 bis 5 sowie 7 bis 11 in verschiedenen Konfigurationen dargestellt werden. Selbstverständlich können mehr oder weniger Elemente als in 6 ausdrücklich beschrieben in der Architektur 600 enthalten sein, wie für den Fachmann beim Lesen der vorliegenden Beschreibungen verständlich sein dürfte.

Die Architektur 600 veranschaulicht ein beispielhaftes Datensystem gemäß einem Aspekt. 6 teilt gemeinsame Komponenten mit 4 und anderen, und dem Fachmann sollte klar sein, dass gemeinsame Merkmale eine gemeinsame Nummerierung und Funktionalität haben. 6 veranschaulicht eine beispielhafte Operation eines Zurückschreibens von einem Ziel außerhalb der authEncrypt-Vertrauenszone unter Verwendung eines vertrauenswürdigen Überprüfers.

Daten, die durch eine berechtigte Anwendung 395 eines Zielbenutzers 360 in einen Speicher zurückgeschrieben werden, werden an die Doppel-authEncrypt-Engine 386 in der vertrauenswürdigen authEncrypt-Zone des Zielbenutzers 360 gesendet, die sich außerhalb der vertrauenswürdigen authEncrypt-Zone des Eigentümers (nicht gezeigt), des sicheren Transcoders 362 und des Speichersystems 352 befindet. Gemäß einem beispielhaften Aspekt leitet die berechtigte Anwendung 395 in einer Operation 404 die Daten an den Vorfilter 402 weiter. Der Vorfilter 402 ermittelt auf eine ähnliche Weise wie weiter oben beschrieben, dass die Daten nicht verschlüsselt sind. Wenn die Daten nicht verschlüsselt sind, werden die Daten in einer Operation 406 an den inneren Verschlüssler 408 gesendet, der die Daten mit dem inneren Verschlüsselungsschlüssel 326 verschlüsselt, um innere verschlüsselte Daten zu erzeugen. Die inneren verschlüsselten Daten werden in einer Operation 602 an einen äußeren Wasserzeichenerzeuger 604 gesendet. Der innere Wasserzeichenerzeuger 604 empfängt den Wasserzeichenschlüssel 383 von dem zweiten Wasserzeichenschlüssel-Server 518 und den Wasserzeichen-Token-Schlüssel 384 von dem Schlüssel-Server 310. Der innere Wasserzeichenerzeuger 604 erzeugt gemäß mindestens manchen der hierin beschriebenen Aspekte ein inneres Wasserzeichen und ein inneres Wasserzeichen-Token. Die inneren verschlüsselten Daten, das innere Wasserzeichen und das innere Wasserzeichen-Token werden in einer Operation 606 an den äußeren Verschlüssler 416 gesendet, der den äußeren Schlüssel 380 für eine gemeinsame Nutzung verwendet, um äußere verschlüsselte Daten zu erzeugen. Die äußeren verschlüsselten Daten, das innere Wasserzeichen und das innere Wasserzeichen-Token werden in einer Operation 608 an den äußeren Wasserzeichenerzeuger 610 gesendet. Der äußere Wasserzeichenerzeuger 610 empfängt den äußeren Wasserzeichenschlüssel 528 von dem zweiten Wasserzeichenschlüssel-Server 518 und den äußeren Wasserzeichen-Token-Schlüssel 530 von dem Schlüssel-Server 310. Gemäß einem weiteren Ansatz empfängt der äußere Wasserzeichenerzeuger 610 den äußeren Wasserzeichen-Token-Schlüssel 530 von dem zweiten Wasserzeichenschlüssel-Server 518 oder von einem weiteren Schlüssel-Server, um die Vertraulichkeit von Informationen aufrechtzuerhalten, die intern aufgezeichneten Daten zugehörig sind (z.B. hat der Zielbenutzer 360 gemäß einem bevorzugten Aspekt keinen Zugriff auf den internen Schlüssel-Server 310). Der äußere Wasserzeichenerzeuger 610 erzeugt gemäß mindestens manchen der hierin beschriebenen Aspekte ein äußeres Wasserzeichen und ein äußeres Wasserzeichen-Token für die äußeren verschlüsselten Daten. Die äußeren verschlüsselten Daten, die inneren Wasserzeichen und die äußeren Wasserzeichen werden in einer Operation 612 an den sicheren Transcoder 362 innerhalb der authEncrypt-Zone des Eigentümers übertragen. Gemäß mindestens manchen Ansätzen werden die Wasserzeichenerstellungsschritte übersprungen, wenn das Ziel authEncrypt nicht unterstützt.

Gemäß mindestens manchen der hierin beschriebenen Ansätze erhält der äußere Überprüfer 614 in dem sicheren Transcoder 362 den gemeinsam genutzten äußeren Wasserzeichenschlüssel 528 von dem zweiten Wasserzeichenschlüssel-Server 518 und den äußeren Wasserzeichen-Token-Schlüssel 530 von dem Schlüssel-Server 310 und überprüft die äußere Verschlüsselung. Wenn die Überprüfung erfolgreich ist, werden die äußeren verschlüsselten Daten in einer Operation 616 unter Verwendung des äußeren Schlüssels 380 für eine gemeinsame Nutzung, der von dem Schlüssel-Server 310 erhalten wird, für eine Entschlüsselung an den äußeren Entschlüssler 428 weitergeleitet. Die entschlüsselten Daten (z.B. die inneren verschlüsselten Daten) werden in einer Operation 618 an den inneren Überprüfer 620 gesendet. Der innere Überprüfer 620 erhält den Wasserzeichenschlüssel 383 von dem zweiten Wasserzeichenschlüssel-Server 518 und überprüft das Wasserzeichen. Wenn die Überprüfung erfolgreich ist, werden die inneren verschlüsselten Daten in einer Operation 622 an den sicheren Überprüfer 506 übertragen. Der sichere Überprüfer 506 enthält einen Überprüfer 624, der den Wasserzeichen-Token-Schlüssel 384 von dem Schlüssel-Server 310 erhält und das innere Wasserzeichen-Token überprüft. Wenn die Überprüfung erfolgreich ist, erhält der sichere Überprüfer 506 den inneren Verschlüsselungsschlüssel 326 (in dem sicheren Überprüfer 506 nicht gezeigt) von dem Schlüssel-Server 310. Der innere Entschlüssler 626 verwendet den inneren Verschlüsselungsschlüssel 326, um die Daten zu entschlüsseln. Die entschlüsselten Daten werden in einer Operation 628 an einen Vorfilter 630 weitergeleitet, der überprüft, dass die entschlüsselten Daten unverschlüsselt sind. Wenn die Überprüfung erfolgreich ist, sendet der Vorfilter 630 in einer Operation 633 eine Überprüfungsnachricht an den Wasserzeichenerzeuger 632 in dem sicheren Überprüfer 506. Der Wasserzeichenerzeuger 632 in dem sicheren Überprüfer 506 erhält den inneren Wasserzeichen-Token-Schlüssel 332 von dem Schlüssel-Server 310 und erzeugt ein neues inneres Wasserzeichen-Token. Das neue innere Wasserzeichen-Token und eine Überprüfungsnachricht werden in einer Operation 634 an den Wasserzeichenerzeuger 636 in dem sicheren Transcoder 362 zurückgegeben. Wenn die Überprüfung erfolgreich ist, erhält der Wasserzeichenerzeuger 636 den inneren Wasserzeichenschlüssel 334 von dem ersten Wasserzeichenschlüssel-Server 502 und verwendet die inneren verschlüsselten Daten, die in einer Operation 638 von dem inneren Überprüfer 620 weitergeleitet werden, das innere Wasserzeichen-Token aus der Operation 634 und den inneren Wasserzeichenschlüssel 334, um ein neues Wasserzeichen zu erzeugen. Die inneren verschlüsselten Daten werden in einer Operation 640 an den äußeren Verschlüssler 436 übertragen. Der äußere Verschlüssler 436 verschlüsselt die inneren verschlüsselten Daten unter Verwendung des äußeren Verschlüsselungsschlüssels 340, der von dem Schlüssel-Server 310 erhalten wird, um äußere verschlüsselte Daten zu erzeugen. Die äußeren verschlüsselten Daten werden in einer Operation 642 an den äußeren Wasserzeichenerzeuger 440 übertragen. Der äußere Wasserzeichenerzeuger 440 erhält den äußeren Wasserzeichen-Token-Schlüssel 346 von dem Schlüssel-Server 310 und den äußeren Wasserzeichenschlüssel 348 von dem ersten Wasserzeichenschlüssel-Server 502. Der äußere Wasserzeichenerzeuger 440 erzeugt ein neues äußeres Wasserzeichen-Token und ein neues äußeres Wasserzeichen. Die inneren und äußeren Wasserzeichen-Token, die inneren und äußeren Wasserzeichen und die äußeren verschlüsselten Daten werden in einer Operation 442 an den Speicherüberprüfer 354 in dem Speichersystem 352 übertragen. Der Speicherüberprüfer 354 erhält den äußeren Wasserzeichenschlüssel 348 von dem ersten Wasserzeichenschlüssel-Server 502 und überprüft das äußere Wasserzeichen. Wenn die Überprüfung erfolgreich ist, werden die verschlüsselten Daten und Wasserzeichen in einer Operation 444 in den Speicher 356 geschrieben.

Wenn Daten von außerhalb der authEncrypt-Vertrauenszone empfangen werden, überprüft gemäß einem alternativen Aspekt eine erste Doppel-authEncrypt-Engine die Daten von außerhalb der Vertrauenszone unter Verwendung von Schlüsseln, die mit der externen Quelle gemeinsam genutzt werden, und entschlüsselt die Daten vollständig. Danach werden die unverschlüsselten Daten durch eine zweite Doppel-authEncrypt-Engine verschlüsselt und mit einem Wasserzeichen versehen, indem Schlüssel aus der vertrauenswürdigen authEncrypt-Zone verwendet werden. Dieser Verschlüsselungsprozess führt die unverschlüsselte Filterüberprüfung vor der Verschlüsselung durch, sodass die verschlüsselten Daten an diesem Punkt bereits validiert wurden. Daten, die auf diese Weise importiert werden, benötigen keine Überprüfung durch einen sicheren Überprüfer, der mit dem Transcoder verbunden wird.

Unter nunmehriger Bezugnahme auf 7 wird ein Ablaufplan eines Verfahrens 700 gemäß einem Aspekt gezeigt. Das Verfahren 700 kann gemäß der vorliegenden Erfindung in jeder der Umgebungen realisiert werden, die unter anderem in den 1 bis 6 sowie 8 bis 11 gemäß verschiedenen Aspekten dargestellt werden. Selbstverständlich können mehr oder weniger Operationen als in 7 ausdrücklich beschrieben in dem Verfahren 700 enthalten sein, wie für den Fachmann beim Lesen der vorliegenden Beschreibungen verständlich sein dürfte.

Jeder der Schritte des Verfahrens 700 kann durch jede geeignete Komponente der Betriebsumgebung durchgeführt werden. So kann das Verfahren 700 gemäß verschiedenen Aspekten zum Beispiel teilweise oder vollständig durch Computer oder durch eine andere Einheit mit einem oder mehreren darin enthaltenen Prozessoren durchgeführt werden. Der Prozessor, z.B. eine bzw. mehrere Verarbeitungsschaltungen, ein bzw. mehrere Chips und/oder ein bzw. mehrere Module, die in Hardware und/oder Software realisiert werden und vorzugsweise mindestens eine Hardware-Komponente enthalten, kann in jeder Einheit genutzt werden, um einen oder mehrere Schritte des Verfahrens 700 durchzuführen. Ohne darauf beschränkt zu sein, enthalten veranschaulichende Prozessoren eine anwendungsspezifische integrierte Schaltung (Application-Specific Integrated Circuit, ASIC), ein im Feld programmierbares Logik-Array (Field-Pogrammable Gate Array, FPGA) usw., Kombinationen hiervon oder jede andere geeignete Datenverarbeitungseinheit nach dem Stand der Technik.

Wie in 7 gezeigt, enthält das Verfahren 700 eine Operation 702. Gemäß einem weiteren Aspekt enthält die Operation 702 ein Empfangen zweiter verschlüsselter Daten, Wasserzeichen und eines ersten Wasserzeichen-Tokens von einem Datenspeicher als Reaktion auf eine Datenanforderung von einem Zielknoten außerhalb einer berechtigten Verschlüsselungsvertrauenszone. Gemäß verschiedenen Aspekten der vorliegenden Offenbarung enthalten zweite verschlüsselte Daten Daten, die mit einem ersten Schlüssel verschlüsselt wurden, um erste verschlüsselte Daten zu erzeugen. Die ersten verschlüsselten Daten werden vorzugsweise mit einem zweiten Schlüssel verschlüsselt, um zweite verschlüsselte Daten zu erzeugen. Das erste Wasserzeichen-Token wird für die ersten verschlüsselten Daten erzeugt.

Gemäß verschiedenen Aspekten werden die zweiten verschlüsselten Daten in einem sicheren Transcoder empfangen, z.B. einem sicheren Transcoder, der gemäß verschiedenen Aspekten der vorliegenden Offenbarung beschrieben wird. Der Transcoder kann sich in dem Quellknoten, in dem Datenspeicher, in einem mit dem Quellknoten und dem Datenspeicher verbundenen Speichernetzwerk usw. befinden.

Eine berechtigte Verschlüsselungsvertrauenszone (z.B. eine berechtigte Verschlüsselungszone) weist vorzugsweise einen Quellknoten, der Daten unter Verwendung einer berechtigten Verschlüsselungsschicht in einem Datenspeicher speichert, den Datenspeicher, die berechtigte Verschlüsselungsschicht, einen sicheren Transcoder und einen vertrauenswürdigen Überprüfer auf. Gemäß einem bevorzugten Aspekt führt eine auf ihre Berechtigung geprüfte Verschlüsselungsschicht (z.B. eine berechtigte Verschlüsselungsschicht) in einem Hostsystem (z.B. einem Quellknoten) eine Berechtigungsprüfung der Anwendungen durch, die zu speichernde Daten erzeugen und/oder verarbeiten. Die Berechtigungsprüfung kann auf eine nach dem Stand der Technik bekannte Weise erfolgen. Gemäß verschiedenen Ansätzen muss eine Anwendung berechtigt sein, eine Verschlüsselung durchzuführen und/oder verschlüsselte Daten in einem Speichersystem zu speichern. Ein Hostsystem, ein Benutzer, ein System usw. können auf eine beliebige nach dem Stand der Technik bekannte Weise ermitteln, ob eine Anwendung oder eine Mehrzahl von Anwendungen berechtigt sind, bevor die Anwendung anfordert, verschlüsselte Daten aus dem Speichersystem zu lesen und/oder in das Speichersystem zu schreiben. Gemäß bevorzugten Aspekten werden unverschlüsselte Daten nicht in dem Speichersystem gespeichert.

Als Reaktion auf ein Ermitteln, dass die Anwendung für eine Verschlüsselung nicht berechtigt ist, blockiert die auf ihre Berechtigung geprüfte Verschlüsselungsschicht gemäß verschiedenen Aspekten die Leseanforderung, die Schreibanforderung usw. von der unberechtigten Anwendung. Gemäß manchen Aspekten kann das System den Vorfall protokollieren und/oder eine Warnmeldung an einen Benutzer des Systems senden, um auf einen möglichen Angriff von einem böswilligen Akteur hinzuweisen. Die Daten können ein beliebiges nach dem Stand der Technik bekanntes Datenformat aufweisen. Die Daten können in Gestalt von Datendateien, Chunks, Blöcken usw. oder in einer beliebigen Kombination hiervon vorliegen. Gemäß verschiedenen Ansätzen werden die Daten auf eine nach dem Stand der Technik bekannte Weise in der auf ihre Berechtigung geprüften Verschlüsselungsschicht empfangen. Gemäß bevorzugten Aspekten werden die Daten nur als Reaktion auf ein Ermitteln empfangen, dass die Anwendung, die die Daten sendet, berechtigt ist.

Gemäß einem Ansatz enthält die auf ihre Berechtigung geprüfte Verschlüsselungsschicht eine Vorfilterfunktion. Gemäß bevorzugten Aspekten führt die Vorfilterfunktion eine Verschlüsselungserkennungsfunktion durch, die ein Ermitteln enthält, ob die Daten vorverschlüsselt sind. Im Besonderen ermittelt die Verschlüsselungserkennungsfunktion des Vorfilters, ob die Daten zuvor mit einem beliebigen Verschlüsselungsschlüssel verschlüsselt wurden. Als Reaktion auf ein Ermitteln, dass die Daten verschlüsselt sind, kann die auf ihre Berechtigung geprüfte Verschlüsselungsschicht eine weitere Verarbeitung der Daten blockieren (z.B. kann ein Fehler ausgegeben werden, eine weitere Verschlüsselung der Daten kann blockiert werden, die Schreib- und/oder Leseanforderung wird zurückgewiesen usw.). Wie weiter oben beschrieben wird, kann der Fehler protokolliert und/oder eine Warnmeldung an einen Benutzer gesendet werden. Als Reaktion auf ein Ermitteln, dass die Daten verschlüsselt sind, blockiert die auf ihre Berechtigung geprüfte Verschlüsselungsschicht im Besonderen die Verschlüsselung der Daten. Gemäß einem beispielhaften Aspekt kann die auf ihre Berechtigung geprüfte Verschlüsselungsschicht eine Schreibanforderung für verschlüsselte Daten auch dann blockieren, wenn die Anforderung von einer berechtigten Anwendung stammt. Die auf ihre Berechtigung geprüfte Verschlüsselungsschicht verschlüsselt vorzugsweise nur unverschlüsselte Daten für berechtigte Anwendungen.

Die auf ihre Berechtigung geprüfte Verschlüsselungsschicht kann einen Verschlüsselungsschlüssel und/oder einen Wasserzeichenschlüssel für die Daten anfordern. Gemäß mindestens manchen Ansätzen werden der Verschlüsselungsschlüssel und der Wasserzeichenschlüssel von getrennten Schlüssel-Servern angefordert. Zum Beispiel kann der Verschlüsselungsschlüssel von einem Schlüssel-Server angefordert werden, und der Wasserzeichenschlüssel kann von einem Wasserzeichenschlüssel-Server angefordert werden. Gemäß anderen Aspekten werden der Verschlüsselungsschlüssel und der Wasserzeichenschlüssel von demselben Schlüssel-Server angefordert. Der bzw. die Schlüssel-Server können sich in dem Hostsystem befinden, von dem Hostsystem und/oder dem Speichersystem isoliert sein, sich in dem Speichersystem befinden usw. Gemäß bevorzugten Aspekten hat das Speichersystem keinen Zugriff auf die Verschlüsselungsschlüssel.

Gemäß verschiedenen Aspekten werden die zweiten verschlüsselten Daten durch die auf ihre Berechtigung geprüfte Verschlüsselungsschicht erzeugt, bevor die Daten an einen Speicher gesendet werden. Zum Beispiel kann ein Erzeugen der zweiten verschlüsselten Daten zunächst ein Verschlüsseln der Daten (z.B. Klartextdaten) unter Verwendung eines Verschlüsselungsschlüssels (z.B. eines ersten Schlüssels) enthalten. Der erste Schlüssel kann verwendet werden, um die Daten auf eine nach dem Stand der Technik bekannte Art zu verschlüsseln, um erste verschlüsselte Daten zu erhalten. Gemäß bevorzugten Aspekten ist der erste Schlüssel für die Anwendung nicht verfügbar. Der erste Schlüssel kann durch die auf ihre Berechtigung geprüfte Verschlüsselungsschicht angefordert und als Reaktion auf die Anforderung direkt an die auf ihre Berechtigung geprüfte Verschlüsselungsschicht gesendet werden, wobei die berechtigte Anwendung vorzugsweise übergangen wird. Gemäß verschiedenen Ansätzen werden die ersten verschlüsselten Daten mit einem zweiten Schlüssel verschlüsselt, um auf eine ähnliche Weise zweite verschlüsselte Daten zu erhalten

Gemäß verschiedenen Ansätzen kann die auf ihre Berechtigung geprüfte Verschlüsselungsschicht auf Grundlage der Berechtigungsnachweise der berechtigten Anwendung verschiedene hierin erörterte Schlüssel anfordern. Zum Beispiel kann jeder berechtigten Anwendung ein einziger Verschlüsselungsschlüssel und ein einziger Wasserzeichenschlüssel zugehörig sein. In einem weiteren Beispiel kann jeder berechtigten Anwendung ein Satz von Verschlüsselungsschlüsseln und ein Satz von Wasserzeichenschlüsseln zugehörig sein. Gemäß mindestens manchen der in der vorliegenden Offenbarung beschriebenen Aspekten kann jede Kombination von Anwendungen, Verschlüsselungsschlüsseln, Wasserzeichenschlüsseln usw. verwendet werden.

Gemäß bevorzugten Aspekten wird unter Verwendung eines Wasserzeichenschlüssels, der den ersten verschlüsselten Daten zugehörig ist (z.B. ein erster Wasserzeichenschlüssel), für die ersten verschlüsselten Daten ein Wasserzeichen erzeugt, und/oder unter Verwendung eines Wasserzeichenschlüssels, der den zweiten verschlüsselten Daten zugehörig ist (z.B. ein zweiter Wasserzeichenschlüssel), wird für die zweiten verschlüsselten Daten ein Wasserzeichen erzeugt. Ein Wasserzeichen, das für die ersten verschlüsselten Daten erzeugt wird, kann auch als ein erstes Wasserzeichen bezeichnet werden. Ein Wasserzeichen, das für die zweiten verschlüsselten Daten erzeugt wird, kann auch als ein zweites Wasserzeichen bezeichnet werden. Die in dem sicheren Transcoder empfangenen Wasserzeichen können das erste Wasserzeichen und/oder das zweite Wasserzeichen enthalten.

Gemäß verschiedenen Aspekten kann das Wasserzeichen der verschlüsselten Daten auf eine beliebige nach dem Stand der Technik bekannte Weise erzeugt werden. Gemäß einem Ansatz ist das Wasserzeichen ein Nachrichten-Berechtigungsprüfungscode auf Hash-Grundlage mit Schlüssel unter Verwendung des Wasserzeichenschlüssels und eines Wasserzeichen-Tokens, wobei dies auf eine Weise erfolgt, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.

Gemäß bevorzugten Aspekten wird unter Verwendung eines Wasserzeichen-Token-Schlüssels, der den ersten verschlüsselten Daten zugehörig ist (z.B. ein erster Wasserzeichen-Token-Schlüssel), für die ersten verschlüsselten Daten ein Wasserzeichen-Token erzeugt, und/oder unter Verwendung eines Wasserzeichen-Token-Schlüssels, der den zweiten verschlüsselten Daten zugehörig ist (z.B. ein zweiter Wasserzeichen-Token-Schlüssel), wird für die zweiten verschlüsselten Daten ein Wasserzeichen-Token erzeugt. Ein Wasserzeichen-Token, das für die ersten verschlüsselten Daten erzeugt wird, kann auch als ein erstes Wasserzeichen-Token bezeichnet werden. Ein Wasserzeichen-Token, das für die zweiten verschlüsselten Daten erzeugt wird, kann auch als ein zweites Wasserzeichen-Token bezeichnet werden. Das in dem sicheren Transcoder empfangene Wasserzeichen-Token kann das erste Wasserzeichen-Token und/oder das zweite Wasserzeichen-Token enthalten.

Gemäß verschiedenen Ansätzen kann ein Erzeugen eines Wasserzeichen-Tokens einen beliebigen Prozess eines Umwandelns der verschlüsselten Daten in eine zufällige Zeichenfolge (z.B. ein Token) enthalten, die keinen bedeutungsvollen Wert hat, wenn sie komprimiert wird. Jedes hierin erwähnte Token kann als Bezug auf die ursprünglichen Daten dienen, wobei das Token jedoch nicht dazu verwendet werden kann, diese Werte zu ermitteln (z.B. auf die Daten zuzugreifen). Gemäß mindestens manchen Ansätzen ist das Wasserzeichen-Token ein Nachrichten-Berechtigungsprüfungscode (MAC) der verschlüsselten Daten. Gemäß verschiedenen Ansätzen erzeugt die auf ihre Berechtigung geprüfte Verschlüsselungsschicht Metadaten, die dem Wasserzeichen und/oder dem Wasserzeichenschlüssel zugehörig sind. Gemäß manchen Ansätzen kann ein zugehöriges Wasserzeichen und/oder ein Wasserzeichenschlüssel verwendet werden, um ein Wasserzeichen-Token zu erzeugen. Auf ähnliche Weise können gemäß mindestens manchen Ansätzen ein Wasserzeichen-Token und/oder ein Wasserzeichen-Token-Schlüssel verwendet werden, um ein Wasserzeichen zu erzeugen.

Gemäß mindestens einem Ansatz werden ein erstes und zweites Wasserzeichen sowie ein erstes und zweites Wasserzeichen-Token erzeugt. Gemäß einem weiteren Ansatz werden nur ein erstes Wasserzeichen und ein erstes Wasserzeichen-Token erzeugt. Gemäß noch einem weiteren Ansatz werden nur ein zweites Wasserzeichen und ein zweites Wasserzeichen-Token erzeugt. Gemäß noch einem weiteren Ansatz werden nur ein erstes Wasserzeichen-Token und ein zweites Wasserzeichen erzeugt (z.B. bei hierin beschriebenen hybriden Ansätzen). Für den Fachmann dürfte beim Lesen der vorliegenden Offenbarung offensichtlich sein, dass jede Kombination von ersten und/oder zweiten Wasserzeichen, ersten und/oder zweiten Wasserzeichen-Token und ersten und/oder zweiten Wasserzeichen-Token-Schlüsseln mit dem zugehörigen Sicherheitsniveau verwendet werden kann, wobei dies durch den Fachmann bestimmbar wäre.

Bevor der sichere Transcoder die zweiten verschlüsselten Daten und die Wasserzeichen empfängt, kann die auf ihre Berechtigung geprüfte Verschlüsselungsschicht gemäß mindestens manchen Aspekten die zweiten verschlüsselten Daten und etwaige erzeugte Wasserzeichen in dem Datenspeicher speichern. Gemäß manchen Ansätzen kann das Speichersystem ein Teilsystem eines Computers sein, der das Verfahren ausführt, z.B. ein Datenspeicherlaufwerk, das Teil des Computers ist und/oder direkt mit diesem verbunden wird. Der Datenspeicher kann eine Überprüferfunktion enthalten, die Zugriff auf die Wasserzeichenschlüssel in einem Schlüssel-Server hat. Der Datenspeicher ist vorzugsweise berechtigt, auf eine nach dem Stand der Technik bekannte Weise gemäß verschiedenen hierin beschriebenen Berechtigungsrichtlinien auf die passenden Wasserzeichenschlüssel zuzugreifen. Gemäß anderen Ansätzen werden Metadaten, die dem Wasserzeichen und/oder dem Wasserzeichenschlüssel zugehörig sind, an den Datenspeicher gesendet. Der Datenspeicher kann auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte, auf Grundlage der Metadaten den zugehörigen Wasserzeichenschlüssel von dem Schlüssel-Server anfordern. Die Überprüferfunktion des Datenspeichers kann einen beliebigen entsprechenden Wasserzeichenschlüssel verwenden, um die Wasserzeichen zu überprüfen.

Die Überprüferfunktion des Datenspeichers kann auch Zugriff auf Wasserzeichen-Token-Schlüssel in einem Schlüssel-Server haben (der z.B. derselbe Schlüssel-Server, der die Wasserzeichenschlüssel enthält, oder aber ein anderer Schlüssel-Server sein kann). Der Datenspeicher ist vorzugsweise berechtigt, auf eine nach dem Stand der Technik bekannte Weise gemäß verschiedenen hierin beschriebenen Berechtigungsrichtlinien auf die passenden Wasserzeichen-Token-Schlüssel zuzugreifen. Die Überprüferfunktion des Datenspeichers kann einen beliebigen entsprechenden Wasserzeichen-Token-Schlüssel verwenden, um die Wasserzeichen-Token zu überprüfen.

Gemäß einem Aspekt wird ein zweites Wasserzeichen für die zweiten verschlüsselten Daten erzeugt. Die zweiten verschlüsselten Daten und das zweite Wasserzeichen können an den Datenspeicher gesendet werden, und der Datenspeicher hat Zugriff auf den zweiten Wasserzeichenschlüssel. Die Überprüferfunktion in dem Datenspeicher überprüft das zweite Wasserzeichen unter Verwendung des zweiten Wasserzeichenschlüssels, wie für den Fachmann beim Lesen der vorliegenden Offenbarung verständlich sein dürfte. Gemäß mindestens einem der oben beschriebenen Aspekte kann eine beliebige hierin beschriebene Wasserzeichenüberprüfung als „erfolgreich“ gelten, wenn die Wasserzeichen „übereinstimmen“.

Gemäß einem Ansatz des obigen Aspekts wird ein zweites Wasserzeichen-Token für die zweiten verschlüsselten Daten erzeugt. Der Datenspeicher kann den zweiten Wasserzeichen-Token-Schlüssel verwenden, um das zweite Wasserzeichen-Token zu überprüfen, wie für den Fachmann beim Lesen der vorliegenden Offenbarung verständlich sein dürfte.

Eine Operation 704 enthält ein Überprüfen des zweiten Wasserzeichens, das für die zweiten verschlüsselten Daten erzeugt wird. Gemäß dem Verfahren 700 empfängt der Transcoder zweite verschlüsselte Daten und ein erstes Wasserzeichen sowie ein zweites Wasserzeichen, wie weiter oben beschrieben wird. Der Transcoder ist vorzugsweise berechtigt, auf eine nach dem Stand der Technik bekannte Weise gemäß verschiedenen hierin beschriebenen Berechtigungsrichtlinien auf die passenden Wasserzeichenschlüssel zuzugreifen. Gemäß verschiedenen Aspekten weist der Transcoder eine Überprüferfunktion auf, die auf eine ähnliche Weise wie die weiter oben in Bezug auf den Datenspeicher beschriebene Überprüferfunktion beliebige der ersten Wasserzeichen, zweiten Wasserzeichen usw. überprüfen kann.

Eine Operation 706 enthält ein Entschlüsseln der zweiten verschlüsselten Daten unter Verwendung des zweiten Schlüssels, um die ersten verschlüsselten Daten zu erhalten. Gemäß bevorzugten Aspekten wird die Operation 704 als Reaktion auf eine erfolgreiche Überprüfung des zweiten Wasserzeichens in der Operation 702 durchgeführt. Der Transcoder ist vorzugsweise berechtigt, auf eine nach dem Stand der Technik bekannte Weise gemäß verschiedenen hierin beschriebenen Berechtigungsrichtlinien auf die passenden Verschlüsselungsschlüssel (z.B. den ersten Schlüssel, den zweiten Schlüssel usw.) zuzugreifen.

Eine Operation 708 enthält ein Überprüfen des ersten Wasserzeichens, das für die ersten verschlüsselten Daten erzeugt wird. Das Wasserzeichen, das für die ersten verschlüsselten Daten erzeugt wird, kann unter Verwendung des ersten Wasserzeichenschlüssels von einem Schlüssel-Server überprüft werden, wie weiter oben beschrieben wird.

Bei einer erfolgreichen Überprüfung des ersten Wasserzeichens enthält eine Operation 710 ein Senden der ersten verschlüsselten Daten an einen vertrauenswürdigen Überprüfer. Der vertrauenswürdige Überprüfer kann von dem Typ sein, wie er in den 5 und 6 sowie in der vorliegenden Offenbarung beschrieben wird. Ein vertrauenswürdiger Überprüfer kann konfiguriert werden, um mindestens manche der Aspekte des Verfahrens 800 durchzuführen. Gemäß verschiedenen Aspekten wird der vertrauenswürdige Überprüfer konfiguriert, um das erste Wasserzeichen-Token zu überprüfen, das für die ersten verschlüsselten Daten erzeugt wird, wobei der vertrauenswürdige Überprüfer auf eine ähnliche Weise wie der Datenspeicher und/oder der Transcoder Zugriff auf den ersten Wasserzeichen-Token-Schlüssel hat. Als Reaktion auf eine erfolgreiche Überprüfung des ersten Wasserzeichen-Tokens, das von dem sicheren Transcoder in einer Operation 712 empfangen wird, kann der vertrauenswürdige Überprüfer eine Überprüfungsnachricht an den sicheren Transcoder senden. Gemäß anderen Ansätzen wird der vertrauenswürdige Überprüfer konfiguriert, um ein Wasserzeichen und/oder Wasserzeichen-Token zu überprüfen, das für die ersten verschlüsselten Daten erzeugt wird. Der vertrauenswürdige Überprüfer kann konfiguriert werden, um eine Überprüfung des Wasserzeichens und/oder Wasserzeichen-Tokens, das für die ersten verschlüsselten Daten erzeugt wird, an einen Transcoder zu senden.

Als Reaktion auf ein Empfangen einer Überprüfung des ersten Wasserzeichen-Tokens von dem vertrauenswürdigen Überprüfer enthält die Operation 712 ein Verschlüsseln der ersten verschlüsselten Daten mit einem dritten Schlüssel, um dritte verschlüsselte Daten zu erzeugen. Gemäß bevorzugten Ansätzen hat der Transcoder Zugriff auf den dritten Schlüssel in dem Schlüssel-Server, wie dies in der Operation 706 beschrieben wird, und die Verschlüsselung wird auf eine nach dem Stand der Technik bekannte Weise durchgeführt.

Eine Operation 714 enthält ein Erzeugen eines dritten Wasserzeichens und/oder eines dritten Wasserzeichen-Tokens für die dritten verschlüsselten Daten. Gemäß verschiedenen hierin beschriebenen Aspekten kann das dritte Wasserzeichen unter Verwendung eines dritten Wasserzeichenschlüssels für die dritten verschlüsselten Daten erzeugt werden. Gemäß verschiedenen hierin beschriebenen Aspekten kann das dritte Wasserzeichen-Token unter Verwendung eines dritten Wasserzeichen-Token-Schlüssels für die dritten verschlüsselten Daten erzeugt werden.

Eine Operation 716 enthält ein Senden der dritten verschlüsselten Daten, der Wasserzeichen und des bzw. der Wasserzeichen-Token, z.B. des dritten Wasserzeichens und/oder des dritten Wasserzeichen-Tokens, an ein berechtigtes Ziel. Die dritten verschlüsselten Daten, die Wasserzeichen und das bzw. die Wasserzeichen-Token können auf eine nach dem Stand der Technik bekannte Weise an das berechtigte Ziel gesendet werden.

Gemäß einem alternativen Aspekt wird in der Operation 702 nur das zweite Wasserzeichen an den Transcoder gesendet. Das erste Wasserzeichen kann nicht erzeugt werden oder kann nicht an den Transcoder und/oder Datenspeicher gesendet werden. Der Transcoder kann die zweiten verschlüsselten Daten und das zweite Wasserzeichen lesen und das zweite Wasserzeichen - wie oben - unter Verwendung des zweiten Wasserzeichenschlüssels überprüfen. Der Transcoder kann die zweiten verschlüsselten Daten und das erste Wasserzeichen an einen vertrauenswürdigen Überprüfer senden, der konfiguriert wird, um das Wasserzeichen zu überprüfen, das für die zweiten verschlüsselten Daten erzeugt wird. Bei einer erfolgreichen Überprüfung des zweiten Wasserzeichens durch den vertrauenswürdigen Überprüfer kann der Transcoder die zweiten verschlüsselten Daten und das erste Wasserzeichen in den Datenspeicher schreiben.

Gemäß anderen Aspekten überprüft der Transcoder auch das erste Wasserzeichen-Token und/oder das zweite Wasserzeichen-Token auf eine Weise, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.

Gemäß verschiedenen Aspekten sendet der Transcoder die dritten verschlüsselten Daten und etwaige erzeugte Wasserzeichen und/oder Wasserzeichen-Token an ein berechtigtes Ziel. Das berechtigte Ziel hat gemäß Richtlinien, die durch einen Verwalter in dem Quellknoten festgelegt werden, und/oder gemäß hierin beschriebenen anderen Berechtigungsverfahren vorzugsweise Zugriff auf den dritten Schlüssel, den ersten Schlüssel, den ersten Wasserzeichenschlüssel und den dritten Wasserzeichenschlüssel. Das berechtigte Ziel wird konfiguriert, um das dritte Wasserzeichen unter Verwendung des dritten Wasserzeichenschlüssels zu überprüfen, wie dies weiter oben für eine entsprechende Überprüferfunktion in dem berechtigten Ziel beschrieben wird. Bei einer erfolgreichen Überprüfung des dritten Wasserzeichens kann das berechtigte Ziel die dritten verschlüsselten Daten unter Verwendung des dritten Schlüssels entschlüsseln, um die ersten verschlüsselten Daten zu erhalten. Das berechtigte Ziel überprüft vorzugsweise das erste Wasserzeichen unter Verwendung des ersten Wasserzeichenschlüssels, wie für den Fachmann beim Lesen der vorliegenden Offenbarung verständlich sein dürfte. Bei einer erfolgreichen Überprüfung des ersten Wasserzeichens kann das berechtigte Ziel die ersten verschlüsselten Daten unter Verwendung des ersten Schlüssels entschlüsseln, um die Daten (z.B. die Klartextdaten) zu erhalten. Das berechtigte Ziel kann die Daten für eine Verarbeitung gemäß einer beliebigen gewünschten Realisierung verwenden.

Gemäß mindestens manchen Aspekten hat das berechtigte Ziel außerdem Zugriff auf einen dritten Wasserzeichen-Token-Schlüssel und den ersten Wasserzeichen-Token-Schlüssel. Das berechtigte Ziel kann zusätzlich das dritte Wasserzeichen-Token und das erste Wasserzeichen-Token überprüfen, bevor auf Daten in der Klarform zugegriffen wird, wie für den Fachmann beim Lesen der vorliegenden Offenbarung verständlich sein dürfte.

Als Reaktion auf ein Ermitteln, dass eine wie auch immer geartete Überprüfung nicht erfolgreich ist, wird gemäß verschiedenen Aspekten die Speicherung der verschlüsselten Daten, etwaiger Wasserzeichen, etwaiger Wasserzeichen-Token usw. blockiert. Gemäß manchen Aspekten kann ein Blockieren einer Speicherung der verschlüsselten Daten, etwaiger Wasserzeichen, etwaiger Wasserzeichen-Token usw. eine vorübergehende Speicherung der Daten mit ausstehender Überprüfung nicht verhindern. So kann der Datenspeicher zum Beispiel die verschlüsselten Daten vorübergehend in einem Cache empfangen und speichern, solange die Überprüfung aussteht, wie für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.

Der Datenspeicher wird vorzugsweise konfiguriert, um die verschlüsselten Daten für eine Speicherung zu überprüfen, bevor ein Block geschrieben und/oder nachdem ein Block gelesen wird. Ein Block, dessen Überprüfung fehlschlägt, wird nicht in den Speicher geschrieben, und die gelesenen Daten werden entsprechend nicht an den Anforderer zurückgegeben. Gemäß verschiedenen Aspekten führt der Datenspeicher im Rahmen der Überprüfung unter Verwendung der verschlüsselten Daten und der Wasserzeichenschlüssel seine eigene, unabhängige Berechnung der Wasserzeichen durch. Wenn zugehörige Werte der verschlüsselten Daten und/oder der Wasserzeichen-Token nicht die Werte sind, die durch eine auf ihre Berechtigung geprüfte Verschlüsselungsschicht erzeugt wurden, schlägt die Überprüfung fehl.

Unter nunmehriger Bezugnahme auf 8 wird ein Ablaufplan eines Verfahrens 800 gemäß einem Aspekt gezeigt. Das Verfahren 800 kann gemäß der vorliegenden Erfindung in jeder der Umgebungen realisiert werden, die unter anderem in den 1 bis 7 sowie 9 bis 11 gemäß verschiedenen Aspekten dargestellt werden. Selbstverständlich können mehr oder weniger Operationen als in 8 ausdrücklich beschrieben in dem Verfahren 800 enthalten sein, wie für den Fachmann beim Lesen der vorliegenden Beschreibungen verständlich sein dürfte.

Jeder der Schritte des Verfahrens 800 kann durch jede geeignete Komponente der Betriebsumgebung durchgeführt werden. So kann das Verfahren 800 gemäß verschiedenen Aspekten zum Beispiel teilweise oder vollständig durch Computer oder durch eine andere Einheit mit einem oder mehreren darin enthaltenen Prozessoren durchgeführt werden. Der Prozessor, z.B. eine bzw. mehrere Verarbeitungsschaltungen, ein bzw. mehrere Chips und/oder ein bzw. mehrere Module, die in Hardware und/oder Software realisiert werden und vorzugsweise mindestens eine Hardware-Komponente enthalten, kann in jeder Einheit genutzt werden, um einen oder mehrere Schritte des Verfahrens 800 durchzuführen. Ohne darauf beschränkt zu sein, enthalten veranschaulichende Prozessoren eine anwendungsspezifische integrierte Schaltung (ASIC), ein im Feld programmierbares Logik-Array (FPGA) usw., Kombinationen hiervon oder jede andere geeignete Datenverarbeitungseinheit nach dem Stand der Technik.

Wie in 8 gezeigt, enthält das Verfahren 800 eine Operation 802. Die Operation 802 enthält ein Empfangen innerer verschlüsselter Daten durch einen vertrauenswürdigen Überprüfer mindestens teilweise auf Grundlage einer Datenanforderung von einem Zielknoten außerhalb einer berechtigten Verschlüsselungsvertrauenszone. Die Datenanforderung kann eine Datenschreibanforderung, eine Datenleseanforderung usw. enthalten. Die inneren verschlüsselten Daten enthalten Daten, die mit einem inneren Schlüssel verschlüsselt wurden, um die inneren verschlüsselten Daten zu erzeugen. Gemäß verschiedenen Ansätzen können die inneren verschlüsselten Daten mit „ersten verschlüsselten Daten“ austauschbar verwendet werden. Die inneren verschlüsselten Daten werden vorzugsweise von einem sicheren Transcoder in dem vertrauenswürdigen Überprüfer empfangen, wie bei der Operation 710 des Verfahrens 700 ausführlich beschrieben wird. Der vertrauenswürdige Überprüfer kann von dem Typ sein, wie er in den 5 und 6 sowie in der vorliegenden Offenbarung beschrieben wird.

Eine Operation 804 enthält ein Überprüfen eines inneren Wasserzeichen-Tokens, das für die inneren verschlüsselten Daten erzeugt wird. Das innere Wasserzeichen-Token wird für die inneren verschlüsselten Daten unter Verwendung eines inneren Wasserzeichen-Token-Schlüssels auf eine Weise erzeugt, die weiter oben für das erste Wasserzeichen-Token beschrieben wird, das für die ersten verschlüsselten Daten erzeugt wird. Gemäß bevorzugten Aspekten hat der vertrauenswürdige Überprüfer Zugriff auf den inneren Wasserzeichen-Token-Schlüssel, wie weiter oben ausführlich beschrieben wird, und überprüft das innere Wasserzeichen-Token gemäß mindestens manchen der hierin beschriebenen Aspekte.

Als Reaktion auf eine Datenschreibanforderung enthält das Verfahren 800 gemäß verschiedenen Aspekten ein Entschlüsseln der inneren verschlüsselten Daten unter Verwendung des inneren Schlüssels, um die Daten (z.B. die Klartextdaten) zu erhalten. Gemäß bevorzugten Aspekten werden die Datenschreibanforderung und die darauffolgende Entschlüsselung als Reaktion auf eine erfolgreiche Überprüfung des inneren Wasserzeichens in der Operation 804 durchgeführt. Der vertrauenswürdige Überprüfer ist vorzugsweise berechtigt, auf eine nach dem Stand der Technik bekannte Weise gemäß verschiedenen hierin beschriebenen Berechtigungsrichtlinien auf die passenden Verschlüsselungsschlüssel (z.B. den ersten Schlüssel usw.) zuzugreifen.

Als Reaktion auf die Datenschreibanforderung enthält das Verfahren 800 gemäß mindestens manchen Aspekten des Weiteren unter Verwendung einer Vorfilterfunktion ein Ermitteln, dass die Daten (z.B. das Ergebnis eines Entschlüsselns der inneren verschlüsselten Daten unter Verwendung des inneren Schlüssels, um die Daten zu erhalten) unverschlüsselt sind. Gemäß bevorzugten Aspekten führt die Vorfilterfunktion eine Verschlüsselungserkennungsfunktion durch, die ein Ermitteln enthält, ob die Daten vorverschlüsselt sind. Gemäß anderen Aspekten ermittelt die Verschlüsselungserkennungsfunktion des Vorfilters, ob die Daten mit einem beliebigen Verschlüsselungsschlüssel verschlüsselt sind. Als Reaktion auf ein Ermitteln, dass die Daten nicht verschlüsselt sind, kann der vertrauenswürdige Überprüfer eine weitere Verarbeitung der Daten blockieren (z.B. kann ein Fehler ausgegeben werden, eine weitere Verschlüsselung der Daten kann blockiert werden, die Schreib- und/oder Leseanforderung wird zurückgewiesen usw.). Wie weiter oben beschrieben wird, kann der Fehler protokolliert und/oder eine Warnmeldung an einen Benutzer gesendet werden.

Als Reaktion auf ein Empfangen einer Datenschreibanforderung enthält das Verfahren 800 gemäß mindestens manchen Aspekten des Weiteren ein Zurückgeben einer ersten Überprüfungsnachricht an einen Transcoder als Reaktion auf eine erfolgreiche Überprüfung des inneren Wasserzeichen-Tokens und die Ermittlung, dass die Daten unverschlüsselt sind. Diese Überprüfungsnachricht kann der Überprüfung entsprechen, die in der Operation 712 des Verfahrens 700 empfangen wird. Gemäß mindestens manchen der Aspekte, die weiter oben in Bezug auf das Verfahren 700 beschrieben werden, kann der Transcoder damit fortfahren, die der Datenschreibanforderung zugehörigen Daten zu verarbeiten.

Gemäß anderen Aspekten überprüft der vertrauenswürdigen Überprüfer außerdem ein inneres Wasserzeichen-Token, das für die inneren verschlüsselten Daten erzeugt wird, unter Verwendung eines inneren Wasserzeichen-Token-Schlüssels und gibt als Reaktion auf eine erfolgreiche Überprüfung eine zweite Überprüfungsnachricht an den sicheren Transcoder zurück, wobei dies auf eine Weise erfolgt, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.

Als Reaktion auf ein erfolgreiches Überprüfen des inneren Wasserzeichen-Tokens kann der vertrauenswürdige Überprüfer gemäß einem Aspekt einen neuen (z.B. anderen) inneren Wasserzeichen-Token-Schlüssel erhalten und ein neues (z.B. anderes) inneres Wasserzeichen-Token für die inneren verschlüsselten Daten erzeugen. Gemäß mindestens einem Ansatz kann das neue innere Wasserzeichen-Token unter Verwendung des neuen inneren Wasserzeichen-Token-Schlüssels und der inneren verschlüsselten Daten erzeugt werden. Das neue innere Wasserzeichen-Token kann an den Transcoder gesendet werden, der das neue innere Wasserzeichen-Token dann an das berechtigte Ziel sendet. Das berechtigte Ziel hat vorzugsweise Zugriff auf den neuen inneren Wasserzeichen-Token-Schlüssel und überprüft nach dem Empfang der dritten verschlüsselten Daten (z.B. innere verschlüsselte Daten, die in dem Transcoder mit einem dritten Verschlüsselungsschlüssel verschlüsselt werden, um dritte verschlüsselte Daten zu erhalten) zusätzlich das neue innere Wasserzeichen-Token. Wenn das Wasserzeichen-Token zum Erzeugen des Wasserzeichens verwendet wird, kann gemäß manchen Aspekten ein berechtigtes Ziel mit Zugriff auf den Wasserzeichen-Token-Schlüssel das Wasserzeichen und das Wasserzeichen-Token überprüfen, ohne Zugriff auf das Wasserzeichen-Token (z.B. von dem Transcoder oder von dem Datenspeicher) zu haben. Wenn das Wasserzeichen-Token und das Wasserzeichen hingegen unabhängig voneinander sind, werden sowohl das Wasserzeichen als auch das Wasserzeichen-Token unabhängig voneinander überprüft.

Gemäß einem weiteren Aspekt wird das bei der Wasserzeichenüberprüfung verwendete Wasserzeichen-Token nicht von dem Datenspeicher empfangen, sondern lokal erzeugt. So wird zum Beispiel für ein inneres Wasserzeichen-Token das bei der Wasserzeichenüberprüfung verwendete innere Wasserzeichen-Token durch den vertrauenswürdigen Überprüfer erzeugt. Für ein äußeres Wasserzeichen-Token wird das bei der Wasserzeichenüberprüfung verwendete äußere Wasserzeichen-Token durch den sicheren Transcoder erzeugt.

Als Reaktion auf ein Empfangen einer Datenleseanforderung erzeugt (z.B. berechnet) der vertrauenswürdige Überprüfer gemäß verschiedenen Aspekten ein neues inneres Wasserzeichen-Token. Gemäß einem beispielhaften Aspekt empfängt der vertrauenswürdige Überprüfer von dem Transcoder ein inneres Wasserzeichen-Token, das für die inneren verschlüsselten Daten erzeugt wird. Das innere Wasserzeichen-Token wird unter Verwendung eines ersten inneren Wasserzeichen-Token-Schlüssels für die inneren verschlüsselten Daten erzeugt, und der vertrauenswürdige Überprüfer überprüft das innere Wasserzeichen-Token, das für die inneren verschlüsselten Daten erzeugt wird, gemäß mindestens manchen der hierin beschriebenen Aspekte. Als Reaktion auf eine erfolgreiche Überprüfung des inneren Wasserzeichen-Tokens, das wie oben beschrieben für die inneren verschlüsselten Daten erzeugt wird, kann der vertrauenswürdige Überprüfer eine zweite Überprüfungsnachricht an den Transcoder zurückgeben.

Gemäß einem weiteren beispielhaften Aspekt überprüft der vertrauenswürdige Überprüfer als Reaktion auf ein Empfangen einer Datenleseanforderung das innere Wasserzeichen-Token nicht (z.B. wie in der Operation 804). Vielmehr erzeugt der vertrauenswürdige Überprüfer auf unabhängige Weise ein inneres Wasserzeichen-Token für die inneren verschlüsselten Daten unter Verwendung eines ersten inneren Wasserzeichen-Token-Schlüssels und gibt das innere Wasserzeichen-Token, das für die inneren verschlüsselten Daten erzeugt wird, an den Transcoder zurück.

Als Reaktion auf ein Empfangen einer Datenleseanforderung erhält der vertrauenswürdige Überprüfer gemäß noch einem weiteren Aspekt einen zweiten inneren Wasserzeichen-Token-Schlüssel (z.B. einen anderen Wasserzeichen-Token-Schlüssel als der erste innere Wasserzeichen-Token-Schlüssel) und erzeugt unter Verwendung des zweiten inneren Wasserzeichen-Token-Schlüssels und der inneren verschlüsselten Daten ein neues inneres Wasserzeichen-Token für die inneren verschlüsselten Daten. Der vertrauenswürdige Überprüfer kann das neue innere Wasserzeichen-Token, das für die inneren verschlüsselten Daten erzeugt wird, an den Transcoder zurückgeben, der das neue innere Wasserzeichen-Token dann an den Zielknoten zurückgibt.

Unter nunmehriger Bezugnahme auf 9 wird ein Ablaufplan einer beispielhaften Realisierung 900 gemäß einem Aspekt gezeigt. Die beispielhafte Realisierung 900 kann gemäß der vorliegenden Erfindung in jeder der Umgebungen realisiert werden, die unter anderem in den 1 bis 8 sowie 10 und 11 gemäß verschiedenen Aspekten dargestellt werden. Selbstverständlich können mehr oder weniger Operationen als in 9 ausdrücklich beschrieben in der beispielhaften Realisierung 900 enthalten sein, wie für den Fachmann beim Lesen der vorliegenden Beschreibungen verständlich sein dürfte.

Jeder der Schritte der beispielhaften Realisierung 900 kann durch jede geeignete Komponente der Betriebsumgebung durchgeführt werden. So kann die beispielhafte Realisierung 900 gemäß verschiedenen Aspekten zum Beispiel teilweise oder vollständig durch Computer oder durch eine andere Einheit mit einem oder mehreren darin enthaltenen Prozessoren durchgeführt werden. Der Prozessor, z.B. eine bzw. mehrere Verarbeitungsschaltungen, ein bzw. mehrere Chips und/oder ein bzw. mehrere Module, die in Hardware und/oder Software realisiert werden und vorzugsweise mindestens eine Hardware-Komponente enthalten, kann in jeder Einheit genutzt werden, um einen oder mehrere Schritte der beispielhaften Realisierung 900 durchzuführen. Ohne darauf beschränkt zu sein, enthalten veranschaulichende Prozessoren eine anwendungsspezifische integrierte Schaltung (ASIC), ein im Feld programmierbares Logik-Array (FPGA) usw., Kombinationen hiervon oder jede andere geeignete Datenverarbeitungseinheit nach dem Stand der Technik.

Die beispielhafte Realisierung 900 bezieht sich auf eine aus der Ferne erfolgende Leseanforderung durch einen Transcoder. Die Realisierung 900 verwendet mindestens manche der Komponenten, die in Bezug auf die 5 und 6 beschrieben werden. Es werden ähnliche Definitionen wie für 3 beschrieben, die, sofern nicht anderweitig angegeben, eine ähnliche Bedeutung und/oder Funktion haben können. Um Vielfache einer Komponente anzugeben, wird eine fortlaufende Nummerierung (z.B. ko1, ko2 usw.) verwendet. Zum Beispiel kann sich sowohl ko1 als auch ko2 auf Verschlüsselungsschlüssel beziehen, wobei eine unterschiedliche Nummerierung, sofern nicht anderweitig angemerkt, für verschiedene Verschlüsselungsschlüssel steht, wie für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.

Die beispielhafte Realisierung 900 bezieht sich auf die Verarbeitung einer einzelnen Anforderung. Ein hierin beschriebenes System kann jedoch auch in der Lage sein, mehrere Anforderungen zu verarbeiten, wie für den Fachmann offensichtlich sein dürfte. Gemäß mindestens manchen Ansätzen wird die beispielhafte Realisierung 900 für jede der Anforderungen wiederholt, sofern bzw. bis eine Fehlerbedingung angibt, dass keine zusätzliche Anforderung verarbeitet werden sollte (so z.B. gemäß nach dem Stand der Technik bekannten Ansätzen eine vorgegebene Anzahl von Anforderungen festgelegt werden). Wenn zum Beispiel ein Paket mit mehreren E/A-Anforderungen für eine Datei (z.B. Daten) empfangen wird, können die Anforderungen in einer beliebigen Reihenfolge ausgeführt werden, solange sich die Ergebnisse nicht von einem seriellen Ausführen einer jeden Anforderung in der Reihenfolge unterscheiden, in der die Anforderungen empfangen wurden, wobei dies auf eine Weise erfolgen würde, die für den Fachmann bestimmbar wäre.

Die beispielhafte Realisierung beginnt mit einer Entscheidung 902. Die Entscheidung 902 enthält ein Ermitteln, ob eine Anforderung eine gültige Anforderung ist (indem z.B. ermittelt wird, ob die Anforderung von einem berechtigten Anforderer stammt, wie weiter oben ausführlich beschrieben wird). Wenn dies der Fall ist, fährt die Entscheidung 902 mit einer Entscheidung 904 fort, die die Anforderung verarbeitet. Falls die Anforderung eine Schreibanforderung ist, fährt die Entscheidung 904 mit A fort (wie in 10 gezeigt und beschrieben). Wenn die Anforderung eine Leseanforderung ist, fährt die Entscheidung 904 mit einer Operation 906 fort. Die Entscheidung 904 kann ein Empfangen von Metadaten enthalten, die die Art von Anforderung angeben, die ihnen zugehörig ist (ob die Anforderung z.B. eine Leseanforderung, eine Schreibanforderung usw. ist). Gemäß der Verwendung in der vorliegenden Offenbarung können sich Metadaten auf Informationen beziehen, mit denen die Gültigkeit einer Anforderung und/oder die Art von Anforderung ermittelt werden kann, wie für den Fachmann verständlich sein dürfte.

Die Operation 906 enthält ein Lesen von cci, twi, wi, txi und xi aus einem Speicher. Die Operation 906 fährt mit einer Operation 908 fort, die ein Erhalten von kr1, h2 (z.B. der äußere Verschlüsselungsschlüssel bzw. der äußere Wasserzeichen-Token-Schlüssel) von einem oder mehreren Schlüssel-Servern gemäß hierin beschriebenen Aspekten enthält. Die Operation 908 fährt mit einer Operation 910 fort, die ein Berechnen des äußeren Wasserzeichen-Tokens txi' gemäß den verschiedenen hierin beschriebenen Aspekten enthält.

Eine Entscheidung 912 enthält ein Überprüfen, ob das äußere Wasserzeichen-Token txi' gültig ist. Ein Ermitteln, ob txi' gültig ist, enthält vorzugsweise ein Ermitteln, ob txi' mit txi übereinstimmt. Wenn das äußere Wasserzeichen-Token nicht gültig ist (z.B. die Überprüfung nicht erfolgreich ist), gibt die Entscheidung 912 in einer Operation 914 eine Fehlermeldung zurück. Wenn das äußere Wasserzeichen-Token gültig ist, fährt die Entscheidung 912 mit einer Operation 916 fort.

Die Operation 916 enthält ein Erhalten des äußeren Wasserzeichenschlüssels w2 von einem Schlüssel-Server gemäß verschiedenen hierin beschriebenen Aspekten. Die Operation 916 fährt mit einer Operation 918 fort, die ein Berechnen eines äußeren Wasserzeichens xi' enthält. Die Operation 918 fährt mit einer Entscheidung 920 fort, die ein Überprüfen enthält, ob das äußere Wasserzeichen xi' gültig ist. Ein Ermitteln, ob das äußere Wasserzeichen xi' gültig ist, enthält vorzugsweise ein Ermitteln, ob xi' mit xi übereinstimmt. Wenn das äußere Wasserzeichen xi' gültig ist, fährt die Entscheidung 920 mit einer Operation 922 fort. Wenn das äußere Wasserzeichen xi' nicht gültig ist, gibt die Entscheidung 920 in der Operation 914 eine Fehlermeldung zurück.

Eine Operation 922 enthält ein Entschlüsseln äußerer verschlüsselter Daten (z.B. cci), um die inneren verschlüsselten Daten zu erzeugen, wie bei verschiedenen hierin beschriebenen Ansätzen dargelegt wird. Wenn es bei der Entschlüsselung in einer Entscheidung 924 einen Fehler gibt, kann in der Operation 914 eine Fehlermeldung zurückgegeben werden. Wenn es bei der Entscheidung 924 keinen Fehler gibt, fährt die Entscheidung 924 mit einer Operation 926 fort. Die Operation 926 enthält ein Transcodieren des inneren Wasserzeichen-Tokens unter Verwendung eines vertrauenswürdigen Überprüfers, wie für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte (siehe 11). Die Operation 926 fährt mit einer Entscheidung 928 fort. Wenn es in der Entscheidung 928 einen Fehler beim Transcodieren des inneren Wasserzeichens gibt, kann in der Operation 914 eine Fehlermeldung zurückgegeben werden. Wenn bei der Entscheidung 928 kein Fehler erkannt wird, fährt die Entscheidung 928 mit einer Operation 930 fort.

Die Operation 930 enthält ein Erhalten eines inneren Wasserzeichenschlüssels w1 von einem Schlüssel-Server gemäß verschiedenen hierin beschriebenen Aspekten. Die Operation 930 fährt mit einer Operation 932 fort, die ein Berechnen des inneren Wasserzeichens wi' unter Verwendung von mindestens dem inneren Wasserzeichenschlüssel enthält. Nach der Berechnung des inneren Wasserzeichens enthält eine Entscheidung 934 ein Überprüfen, ob das innere Wasserzeichen gültig ist. Wenn das innere Wasserzeichen gültig ist, fährt die Entscheidung 934 mit einer Operation 936 fort. Wenn das innere Wasserzeichen nicht gültig ist, gibt die Entscheidung 934 in der Operation 914 eine Fehlermeldung zurück.

Die Operation 936 enthält ein Erhalten eines gemeinsam genutzten inneren Wasserzeichenschlüssels v1 von einem Schlüssel-Server, wie hierin beschrieben wird. Die Operation 936 fährt mit einer Operation 938 fort, die ein Berechnen eines gemeinsam genutzten inneren Wasserzeichens wi enthält. Die Operation 938 fährt mit einer Operation 940 fort, die ein Erhalten von ko1 und j2, einem gemeinsam genutzten äußeren Verschlüsselungsschlüssel bzw. einem gemeinsam genutzten äußeren Wasserzeichen-Token-Schlüssel, von einem oder mehreren Schlüssel-Servern gemäß mindestens manchen der hierin beschriebenen Aspekte enthält. Die Operation 940 fährt mit einer Operation 942 fort, die ein Verschlüsseln innerer verschlüsselter Daten ci enthält, um gemeinsam genutzte äußere verschlüsselte Daten sei zu erzeugen, wie weiter oben beschrieben wird. Die Operation 942 fährt mit einer Operation 944 fort, die ein Berechnen eines gemeinsam genutzten äußeren Wasserzeichen-Tokens tvi enthält, wie weiter oben beschrieben wird. Die Operation 944 fährt mit einer Operation 946 fort, die ein Berechnen eines gemeinsam genutzten äußeren Wasserzeichens vi enthält, wie weiter oben beschrieben wird. Die Operation 946 fährt mit einer Operation 948 fort, die ein Zurückgeben und/oder Senden von sci, twi, wi, tvi, vi an den Anforderer enthält.

Unter nunmehriger Bezugnahme auf 10 wird ein Ablaufplan einer beispielhaften Realisierung 1000 gemäß einem Aspekt gezeigt. Die beispielhafte Realisierung 1000 kann gemäß der vorliegenden Erfindung in jeder der Umgebungen realisiert werden, die unter anderem in den 1 bis 9 und 11 gemäß verschiedenen Aspekten dargestellt werden. Selbstverständlich können mehr oder weniger Operationen als in 10 ausdrücklich beschrieben in der beispielhaften Realisierung 1000 enthalten sein, wie für den Fachmann beim Lesen der vorliegenden Beschreibungen verständlich sein dürfte.

Jeder der Schritte der beispielhaften Realisierung 1000 kann durch jede geeignete Komponente der Betriebsumgebung durchgeführt werden. So kann die beispielhafte Realisierung 1000 gemäß verschiedenen Aspekten zum Beispiel teilweise oder vollständig durch Computer oder durch eine andere Einheit mit einem oder mehreren darin enthaltenen Prozessoren durchgeführt werden. Der Prozessor, z.B. eine bzw. mehrere Verarbeitungsschaltungen, ein bzw. mehrere Chips und/oder ein bzw. mehrere Module, die in Hardware und/oder Software realisiert werden und vorzugsweise mindestens eine Hardware-Komponente enthalten, kann in jeder Einheit genutzt werden, um einen oder mehrere Schritte der beispielhaften Realisierung 1000 durchzuführen. Veranschaulichende Prozessoren enthalten, ohne darauf beschränkt zu sein, eine anwendungsspezifische integrierte Schaltung (ASIC), ein Field-Pogrammable Gate Array (FPGA) usw., Kombinationen hiervon oder jede andere geeignete Datenverarbeitungseinheit nach dem Stand der Technik.

Die beispielhafte Realisierung 1000 bezieht sich auf eine aus der Ferne erfolgende Schreibanforderung durch einen Transcoder. Die Realisierung 1000 verwendet mindestens manche der Komponenten, die in Bezug auf die 5 und 6 beschrieben werden. Es werden ähnliche Definitionen wie für 3 beschrieben, die, sofern nicht anderweitig angegeben, eine ähnliche Bedeutung und/oder Funktion haben können. Um Vielfache einer Komponente anzugeben, wird eine fortlaufende Nummerierung (z.B. ko1, ko2 usw.) verwendet. Zum Beispiel kann sich sowohl ko1 als auch ko2 auf Verschlüsselungsschlüssel beziehen, wobei eine unterschiedliche Nummerierung, sofern nicht anderweitig angemerkt, für verschiedene Verschlüsselungsschlüssel steht, wie für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.

Eine Operation 1002 enthält ein Erhalten eines gemeinsam genutzten äußeren Wasserzeichenschlüssels v2 von einem Schlüssel-Server auf eine Weise, die gemäß verschiedenen Aspekten der vorliegenden Offenbarung beschrieben wird. Die Operation 1002 fährt mit einer Operation 1004 fort, die ein Erhalten eines gemeinsam genutzten äußeren Wasserzeichen-Token-Schlüssels j2 von einem Schlüssel-Server (demselben oder einem anderen Schlüssel-Server) auf eine Weise enthält, die gemäß verschiedenen Aspekten der vorliegenden Offenbarung beschrieben wird. Die Operation 1004 fährt mit einer Operation 1006 fort, die ein Berechnen eines äußeren Wasserzeichens xi' auf eine Weise enthält, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Die Operation 1006 fährt mit einer Entscheidung 1008 fort, die ermittelt, ob das äußere Wasserzeichen gültig ist. Wenn das äußere Wasserzeichen gültig ist, fährt die Entscheidung 1008 mit einer Operation 1010 fort. Wenn das äußere Wasserzeichen nicht gültig ist, gibt die Entscheidung 1008 in einer Operation 1012 gemäß den verschiedenen hierin beschriebenen Aspekten eine Fehlermeldung zurück.

Die Operation 1010 enthält ein Erhalten eines gemeinsam genutzten äußeren Wasserzeichenschlüssels ko1 von einem Schlüssel-Server, wie hierin beschrieben wird. Die Operation 1010 fährt mit einer Operation 1014 fort, die ein Entschlüsseln äußerer Daten enthält, um innere verschlüsselte Daten ci zu erzeugen, wobei dies auf eine Weise erfolgt, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Die Operation 1014 fährt mit einer Entscheidung 1016 fort, die ermittelt, ob beim Entschlüsseln der äußeren verschlüsselten Daten ein Fehler aufgetreten ist. Wenn kein Fehler aufgetreten ist, fährt die Entscheidung 1016 mit einer Operation 1018 fort. Wenn ein Fehler aufgetreten ist, gibt die Entscheidung 1016 in einer Operation 1012 eine Fehlermeldung zurück.

Die Operation 1018 enthält ein Erhalten eines gemeinsam genutzten inneren Wasserzeichenschlüssels v1 von einem Schlüssel-Server, wie hierin beschrieben wird. Die Operation 1018 fährt mit einer Operation 1020 fort, die ein Berechnen eines inneren Wasserzeichens wi' enthält. Eine Entscheidung 1022 ermittelt, ob das innere Wasserzeichen gültig ist. Wenn das innere Wasserzeichen gültig ist, fährt die Entscheidung 1022 mit einer Operation 1024 fort. Wenn das innere Wasserzeichen nicht gültig ist, gibt die Entscheidung 1022 in der Operation 1012 eine Fehlermeldung zurück.

Eine Operation 1024 enthält ein Anfordern einer vertrauenswürdigen Überprüfung der inneren verschlüsselten Daten. Gemäß bevorzugten Aspekten führt ein vertrauenswürdiger Überprüfer eine Entscheidung 1026 durch, die gemäß mindestens manchen der hierin beschriebenen Aspekte ermittelt, ob die inneren verschlüsselten Daten überprüft sind (siehe 11). Wenn die inneren verschlüsselten Daten überprüft sind, fährt die Entscheidung 1026 mit einer Operation 1028 fort. Wenn die inneren verschlüsselten Daten nicht überprüft sind, gibt die Entscheidung 1026 in der Operation 1012 eine Fehlermeldung zurück.

Die Operation 1028 enthält ein Erhalten eines inneren Wasserzeichenschlüssels w1 von einem Schlüssel-Server, wie weiter oben beschrieben wird. Die Operation 1028 fährt mit einer Operation 1030 fort, die ein Berechnen des neuen inneren Wasserzeichens wi unter Verwendung von mindestens dem inneren Wasserzeichenschlüssel enthält, wobei dies auf eine Weise erfolgt, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Die Operation 1030 fährt mit einer Operation 1032 fort, die ein Erhalten eines äußeren Verschlüsselungsschlüssels kr1 von einem Schlüssel-Server enthält, wie weiter oben beschrieben wird. Die Operation 1032 fährt mit einer Operation 1034 fort, die ein Verschlüsseln der inneren verschlüsselten Daten ci enthält, um äußere verschlüsselte Daten cci zu erhalten, wobei dies auf eine Weise erfolgt, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Die Operation 1034 fährt mit einer Operation 1036 fort, die ein Erhalten eines äußeren Wasserzeichen-Token-Schlüssels h2 von einem Schlüssel-Server enthält, wie weiter oben beschrieben wird. Die Operation 1036 fährt mit einer Operation 1038 fort, die ein Berechnen eines neuen äußeren Wasserzeichen-Tokens txi auf eine Weise enthält, die für den Fachmann aus der vorliegenden Offenbarung offensichtlich werden dürfte. Die Operation 1038 fährt mit einer Operation 1040 fort, die ein Erhalten eines äußeren Wasserzeichenschlüssels w2 von einem Schlüssel-Server enthält, wie weiter oben beschrieben wird. Die Operation 1040 fährt mit einer Operation 1042 fort, die ein Berechnen eines neuen äußeren Wasserzeichens xi unter Verwendung von mindestens dem äußeren Wasserzeichenschlüssel enthält, wobei dies auf eine Weise erfolgt, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Die Operation 1042 fährt mit einer Operation 1044 fort, die ein Schreiben innerer und äußerer Wasserzeichen, innerer und äußerer Wasserzeichen-Token und der äußeren verschlüsselten Daten (z.B. cci, twi, wi, txi, xi usw.) in den Speicher enthält, wobei dies als Teil der aus der Ferne erfolgenden Schreibanforderung durch einen Transcoder erfolgt.

Unter nunmehriger Bezugnahme auf 11 wird ein Ablaufplan einer beispielhaften Realisierung 1100 gemäß einem Aspekt gezeigt. Die beispielhafte Realisierung 1100 kann gemäß der vorliegenden Erfindung in jeder der Umgebungen realisiert werden, die unter anderem in den 1 bis 10 gemäß verschiedenen Aspekten dargestellt werden. Selbstverständlich können mehr oder weniger Operationen als in 11 ausdrücklich beschrieben in der beispielhaften Realisierung 1100 enthalten sein, wie für den Fachmann beim Lesen der vorliegenden Beschreibungen verständlich sein dürfte.

Jeder der Schritte der beispielhaften Realisierung 1100 kann durch jede geeignete Komponente der Betriebsumgebung durchgeführt werden. So kann die beispielhafte Realisierung 1100 gemäß verschiedenen Aspekten zum Beispiel teilweise oder vollständig durch Computer oder durch eine andere Einheit mit einem oder mehreren darin enthaltenen Prozessoren durchgeführt werden. Der Prozessor, z.B. eine bzw. mehrere Verarbeitungsschaltungen, ein bzw. mehrere Chips und/oder ein bzw. mehrere Module, die in Hardware und/oder Software realisiert werden und vorzugsweise mindestens eine Hardware-Komponente enthalten, kann in jeder Einheit genutzt werden, um einen oder mehrere Schritte der beispielhaften Realisierung 1100 durchzuführen. Veranschaulichende Prozessoren enthalten, ohne darauf beschränkt zu sein, eine anwendungsspezifische integrierte Schaltung (ASIC), ein Field-Pogrammable Gate Array (FPGA) usw., Kombinationen hiervon oder jede andere geeignete Datenverarbeitungseinheit nach dem Stand der Technik.

Die beispielhafte Realisierung 1100 stellt verschiedene beispielhafte Operationen eines vertrauenswürdigen Überprüfers dar. Die Realisierung 1100 verwendet mindestens manche der Komponenten, die in Bezug auf die 5 und 6 beschrieben werden. Es werden ähnliche Definitionen wie für 3 beschrieben, die, sofern nicht anderweitig angegeben, eine ähnliche Bedeutung und/oder Funktion haben können. Um Vielfache einer Komponente anzugeben, wird eine fortlaufende Nummerierung (z.B. ko1, ko2 usw.) verwendet. Zum Beispiel kann sich sowohl ko1 als auch ko2 auf Verschlüsselungsschlüssel beziehen, wobei eine unterschiedliche Nummerierung, sofern nicht anderweitig angemerkt, für verschiedene Verschlüsselungsschlüssel steht, wie für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.

Gemäß einem beliebigen der weiter oben ausführlich beschriebenen Ansätze enthält eine Operation 1102 ein Empfangen von Metadaten, inneren verschlüsselten Daten und einem inneren Wasserzeichen-Token von einem Transcoder in dem vertrauenswürdigen Überprüfer. Die Metadaten geben die Art von angeforderter Operation an. Die Operation 1102 fährt mit einer Entscheidung 1104 fort, die die Anforderung verarbeitet. Wenn die Anforderung eine Schreibanforderung ist, fährt die Entscheidung 1104 mit einer Operation 1106 fort. Wenn die Anforderung eine Leseanforderung ist, fährt die Entscheidung 1104 mit einer Operation 1108 fort. In der Operation 1106 wird das innere Wasserzeichen-Token j1 angefordert. In der Operation 1108 wird das innere Wasserzeichen-Token h1 angefordert. Sowohl die Entscheidung 1104 als auch die Operation 1108 fahren mit einer Operation 1110 fort, die unter Verwendung des in der vorherigen Operation angeforderten passenden Schlüssels das innere Wasserzeichen-Token twi' berechnet, wobei dies auf eine Weise erfolgt, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.

Die Operation 1110 fährt mit einer Entscheidung 1112 fort, die ermittelt, ob das innere Wasserzeichen-Token twi' gültig ist. Ein Ermitteln, ob das innere Wasserzeichen gültig ist, enthält vorzugsweise ein Ermitteln, ob twi' mit twi übereinstimmt. Wenn das innere Wasserzeichen-Token gültig ist, fährt die Entscheidung 1112 mit einer Operation 1114 fort. Wenn das innere Wasserzeichen-Token nicht gültig ist, schlägt die Überprüfung in einer Operation 1116 fehl. Gemäß mindestens manchen der hierin beschriebenen Aspekte kann in einer Operation 1118 eine Fehlermeldung zurückgegeben werden.

Die Entscheidung 1114 verarbeitet des Weiteren die Anforderung (z.B. mindestens teilweise auf Grundlage der Metadaten). Wenn die Anforderung eine Schreibanforderung ist, fährt die Entscheidung 1114 mit einer Operation 1120 fort. Wenn die Anforderung eine Leseanforderung ist, fährt die Entscheidung 1114 mit einer Operation 1122 fort. In der Operation 1120 wird der innere Verschlüsselungsschlüssel kp1 angefordert. In der Operation 1122 wird ein neuer innerer Wasserzeichen-Token-Schlüssel j1 angefordert.

Die Operation 1120 fährt mit einer Operation 1124 fort, die den in der Operation 1120 angeforderten inneren Verschlüsselungsschlüssel kp1 verwendet, um die inneren verschlüsselten Daten zu entschlüsseln und die Klartextdaten zu erhalten, wobei dies auf eine Weise erfolgt, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Eine Entscheidung 1126 ermittelt, ob es wie auch immer geartete Entschlüsselungsfehler gibt, und/oder, ob die Daten verschlüsselt sind. Wenn es wie auch immer geartete Fehler gibt und/oder die Daten noch verschlüsselt sind (z.B. durch einen Angreifer, der Klartext durch verschlüsselten Text ersetzt hat, usw.), gibt die Entscheidung 1126 in der Operation 1118 eine Fehlermeldung zurück. Wenn es keine Fehler gibt und die Daten in der Klarform vorliegen, fährt die Entscheidung 1126 mit einer Operation 1128 fort, die eine Anforderung eines inneren Wasserzeichen-Token-Schlüssels h1 enthält. Die Operation 1128 fährt mit einer Operation 1130 fort, die unter Verwendung des in der Operation 1128 angeforderten inneren Wasserzeichen-Token-Schlüssels h1 ein Berechnen eines neuen inneren Wasserzeichen-Tokens twi enthält, wobei dies auf eine Weise erfolgt, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte.

Die Operation 1122 fährt entsprechend mit einer Operation 1122 fort, die unter Verwendung des in der Operation 1128 angeforderten inneren Wasserzeichen-Token-Schlüssels j1 ein Berechnen eines neuen inneren Wasserzeichen-Tokens twi enthält, wobei dies auf eine Weise erfolgt, die für den Fachmann beim Lesen der vorliegenden Offenbarung offensichtlich sein dürfte. Gemäß verschiedenen Aspekten der vorliegenden Offenbarung fahren sowohl die Operation 1132 als auch die Operation 1130 mit einer Operation 1134 fort, die ein Zurückgeben einer Meldung über die erfolgreiche Überprüfung und/oder ein Zurückgeben des neuen inneren Wasserzeichen-Tokens an den Transcoder enthält.

Gemäß einem alternativen Aspekt wird das bei der Wasserzeichenüberprüfung verwendete Wasserzeichen-Token nicht von einem Speicher empfangen, sondern lokal durch den vertrauenswürdigen Überprüfer erzeugt. Der vertrauenswürdige Überprüfer kann das innere Wasserzeichen-Token unter Verwendung eines neuen (z.B. zweiten) inneren Wasserzeichen-Token-Schlüssels neu generieren und leitet das neue innere Wasserzeichen-Token an den sicheren Transcoder weiter. Der sichere Transcoder überprüft das innere Wasserzeichen-Token (das z.B. unter Verwendung eines ersten inneren Wasserzeichen-Token-Schlüssels erzeugt wird) und das neue innere Wasserzeichen-Token (das z.B. unter Verwendung des neuen inneren Wasserzeichen-Token-Schlüssels erzeugt wird).

Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt mit einem beliebigen möglichen Grad an technischer Integration handeln. Das Computerprogrammprodukt kann ein computerlesbares Speichermedium (oder computerlesbare Speichermedien) mit darauf gespeicherten computerlesbaren Programmanweisungen enthalten, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.

Bei dem computerlesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch eine Anweisungsausführungseinheit behalten und speichern kann. Bei dem computerlesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des computerlesbaren Speichermediums gehören die Folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (Random Access Memory, RAM), ein Nur-Lese-Speicher (Read-Only Memory, ROM) ein löschbarer programmierbarer Nur-Lese-Speicher (Erasable Programmable Read-Only Memory (EPROM) bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (Static Random Access Memory, SRAM), ein tragbarer CD-ROM, eine DVD (Digital Versatile Disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert werden, und jede geeignete Kombination daraus. Ein computerlesbares Speichermedium soll in der Verwendung hierin nicht als transitorische Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. Lichtwellenleiterkabel durchlaufende Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.

Hierin beschriebene computerlesbare Programmanweisungen können von einem computerlesbaren Speichermedium auf jeweilige Datenverarbeitungs-/ Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk (LAN), ein Weitverkehrsnetzwerk (WAN) und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt computerlesbare Programmanweisungen aus dem Netzwerk und leitet die computerlesbaren Programmanweisungen zur Speicherung in einem computerlesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.

Bei computerlesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction Set Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandseinstellende Daten, Konfigurationsdaten für eine integrierte Schaltung oder sowohl um Quellcode als auch um Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die computerlesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art von Netzwerk verbunden werden, zum Beispiel ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). Bei manchen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, im Feld programmierbare Gatter-Arrays (Field-Programmable Gate Arrays, FPGA) oder programmierbare Logik-Arrays (Programmable Logic Arrays, PLA) die computerlesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der computerlesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.

Aspekte der vorliegenden Erfindung werden hierin unter Bezugnahme auf Ablaufplandarstellungen und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufplandarstellungen und/oder der Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplandarstellungen und/oder den Blockschaubildern mittels computerlesbarer Programmanweisungen ausgeführt werden können.

Diese computerlesbaren Programmanweisungen können einem Prozessor eines Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block oder den Blöcken des Ablaufplans und/oder des Blockschaubilds festgelegten Funktionen/Schritte erzeugen. Diese computerlesbaren Programmanweisungen können auch auf einem computerlesbaren Speichermedium gespeichert werden, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, sodass das computerlesbare Speichermedium, auf dem Anweisungen gespeichert werden, ein Herstellungsprodukt aufweist, darunter Anweisungen, die Aspekte der bzw. des in dem Block bzw. den Blöcken der Ablaufpläne und/oder Blockschaubilder angegebenen Funktion/Schritts umsetzen.

Die computerlesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen computerrealisierten Prozess zu erzeugen, sodass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder Blockschaubilder festgelegten Funktionen/Schritte umsetzen.

Die Ablaufpläne und die Blockschaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zum Realisieren der bestimmten logischen Funktion bzw. Funktionen aufweisen. Bei manchen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zum Beispiel können zwei nacheinander gezeigte Blöcke in Wirklichkeit als ein Schritt erfolgen, im Wesentlichen gleichzeitig, teilweise oder vollständig zeitlich überlappend ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaubilder und/oder der Ablaufplandarstellungen sowie Kombinationen aus Blöcken in den Blockschaubildern und/oder den Ablaufplandarstellungen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, die die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.

Darüber hinaus kann ein System gemäß verschiedenen Ausführungsformen einen Prozessor und Logik enthalten, die mit dem Prozessor integriert und/oder durch diesen ausführbar ist, wobei die Logik so konfiguriert sein kann, dass sie einen oder mehrere der hier genannten Prozessschritte ausführt. Dabei bedeutet „integriert“, dass der Prozessor über Logik verfügt, die in Form von Hardware-Logik in ihn eingebettet ist, wie z.B. eine ASIC, ein FPGA usw. „Durch den Prozessor ausführbar“ bedeutet, dass es sich bei der Logik um Hardware-Logik; Software-Logik wie z.B. Firmware, ein Teil eines Betriebssystems, ein Teil eines Anwendungsprogramms; usw. oder um eine Kombination von Hardware- und Software-Logik handelt, auf die der Prozessor zugreifen kann und die so konfiguriert wird, dass sie den Prozessor veranlasst, bei Ausführung durch den Prozessor eine Funktionalität durchzuführen. Software-Logik kann in einem lokalen und/oder entfernt angeordneten Arbeitsspeicher eines beliebigen Arbeitsspeichertyps nach dem Stand der Technik gespeichert werden. Jeder Prozessor nach dem Stand der Technik kann verwendet werden, z.B. ein Software-Prozessormodul und/oder eine Hardware-Prozessormodul wie beispielsweise eine ASIC, ein FPGA, eine Zentraleinheit (CPU), eine integrierte Schaltung (IC), ein Grafikprozessor (GPU) usw.

Es dürfte offensichtlich sein, dass die verschiedenen Merkmale der vorgenannten Systeme und/oder Methodiken auf eine beliebige Weise kombiniert werden können, so dass sich aus den oben dargelegten Beschreibungen eine Mehrzahl von Kombinationen ergibt.

Des Weiteren dürfte klar sein, dass Ausführungsformen der vorliegenden Erfindung in Form eines Dienstes bereitgestellt werden können, der im Namen eines Kunden bereitgestellt wird, um Dienste auf Abruf (service on demand) anzubieten.

Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung wurden zum Zwecke der Veranschaulichung vorgelegt und sind nicht als vollständig oder auf die offenbarten Ausführungsformen beschränkt zu verstehen. Der Fachmann weiß, dass zahlreiche Modifikationen und Abwandlungen möglich sind, ohne vom inhaltlichen Umfang und gedanklichen Wesensgehalt der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Begrifflichkeit wurde gewählt, um die Grundsätze der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber marktgängigen Technologien bestmöglich zu erläutern bzw. anderen Fachleuten das Verständnis der hierin offenbarten Ausführungsformen zu ermöglichen.

Claims

System, aufweisend: eine auf ihre Berechtigung geprüfte Verschlüsselungsschicht, aufweisend Logik, die konfiguriert wird, um: Daten zu verschlüsseln, die in der auf ihre Berechtigung geprüften Verschlüsselungsschicht von einer berechtigten Anwendung in einem Quellknoten empfangen werden, wobei die Daten durch Verwenden eines ersten Schlüssels verschlüsselt werden, um erste verschlüsselte Daten zu erhalten; die ersten verschlüsselten Daten durch Verwenden eines zweiten Schlüssels zu verschlüsseln, um zweite verschlüsselte Daten zu erhalten; ein Wasserzeichen für die ersten verschlüsselten Daten und/oder ein Wasserzeichen für die zweiten verschlüsselten Daten zu erzeugen; und ein Wasserzeichen-Token für die ersten verschlüsselten Daten und/oder ein Wasserzeichen-Token für die zweiten verschlüsselten Daten zu erzeugen.
System nach Anspruch 1, aufweisend: einen vertrauenswürdigen Überprüfer, wobei der vertrauenswürdige Überprüfer konfiguriert wird, um ein Wasserzeichen und/oder ein Wasserzeichen-Token zu überprüfen, das für die ersten verschlüsselten Daten erzeugt wird, wobei der vertrauenswürdige Überprüfer konfiguriert wird, um eine Überprüfung des Wasserzeichens, das für die ersten verschlüsselten Daten erzeugt wird, an einen Transcoder zu senden.
System nach Anspruch 1, wobei die auf ihre Berechtigung geprüfte Verschlüsselungsschicht Logik aufweist, die konfiguriert wird, um zu veranlassen, dass die zweiten verschlüsselten Daten und das bzw. die erzeugten Wasserzeichen in einem Datenspeicher gespeichert werden, wobei jedes erzeugte Wasserzeichen durch Verwenden eines entsprechenden Wasserzeichenschlüssels erzeugt wird.
System nach Anspruch 3, wobei die auf ihre Berechtigung geprüfte Verschlüsselungsschicht Logik aufweist, die konfiguriert wird, um zu veranlassen, dass das bzw. die erzeugten Wasserzeichen-Token in dem Datenspeicher gespeichert werden, wobei jedes erzeugte Wasserzeichen-Token durch Verwenden eines entsprechenden Wasserzeichen-Token-Schlüssels erzeugt wird.
System nach Anspruch 3, wobei die auf ihre Berechtigung geprüfte Verschlüsselungsschicht Logik aufweist, die konfiguriert wird, um das Wasserzeichen für die zweiten verschlüsselten Daten zu erzeugen, wobei der Datenspeicher Zugriff auf den Wasserzeichenschlüssel hat, der dem Wasserzeichen zugehörig ist, das für die zweiten verschlüsselten Daten erzeugt wird, wobei der Datenspeicher konfiguriert wird, um das Wasserzeichen, das für die zweiten verschlüsselten Daten erzeugt wird, durch Verwenden des Wasserzeichenschlüssels zu überprüfen, der dem Wasserzeichen zugehörig ist, das für die zweiten verschlüsselten Daten erzeugt wird, wobei der Datenspeicher konfiguriert wird, um die zweiten verschlüsselten Daten und das bzw. die erzeugten Wasserzeichen nur bei einer erfolgreichen Überprüfung des Wasserzeichens zu speichern, das für die zweiten verschlüsselten Daten erzeugt wird.
System nach Anspruch 3, aufweisend: einen Transcoder, wobei die auf ihre Berechtigung geprüfte Anwendungsschicht Logik aufweist, die konfiguriert wird, um das Wasserzeichen für die zweiten verschlüsselten Daten zu erzeugen, wobei der Transcoder Logik aufweist, die konfiguriert wird, um: die zweiten verschlüsselten Daten und das Wasserzeichen, das für die zweiten verschlüsselten Daten erzeugt wird, aus dem Datenspeicher zu lesen; und das Wasserzeichen, das für die zweiten verschlüsselten Daten erzeugt wird, durch Verwenden des Wasserzeichenschlüssels zu überprüfen, der dem Wasserzeichen zugehörig ist, das für die zweiten verschlüsselten Daten erzeugt wird.
System nach Anspruch 3, aufweisend: einen Transcoder, wobei die auf ihre Berechtigung geprüfte Anwendungsschicht Logik aufweist, die konfiguriert wird, um das Wasserzeichen für die ersten verschlüsselten Daten zu erzeugen, wobei der Transcoder Logik aufweist, die konfiguriert wird, um: die zweiten verschlüsselten Daten und das Wasserzeichen, das für die ersten verschlüsselten Daten erzeugt wird, aus dem Datenspeicher zu lesen, wobei der Transcoder konfiguriert wird, um die zweiten verschlüsselten Daten durch Verwenden des ersten Schlüssels zu entschlüsseln, um die ersten verschlüsselten Daten zu erhalten, wobei der Transcoder konfiguriert wird, um das Wasserzeichen, das für die ersten verschlüsselten Daten erzeugt wird, durch Verwenden des Wasserzeichenschlüssels zu überprüfen, der dem Wasserzeichen zugehörig ist, das für die ersten verschlüsselten Daten erzeugt wird.
System nach Anspruch 4, aufweisend: einen Transcoder, wobei die auf ihre Berechtigung geprüfte Anwendungsschicht Logik aufweist, die konfiguriert wird, um das Wasserzeichen-Token für die zweiten verschlüsselten Daten zu erzeugen, wobei der Transcoder Logik aufweist, die konfiguriert wird, um: die zweiten verschlüsselten Daten und das Wasserzeichen-Token, das für die zweiten verschlüsselten Daten erzeugt wird, aus dem Datenspeicher zu lesen; und das Wasserzeichen-Token, das für die zweiten verschlüsselten Daten erzeugt wird, durch Verwenden des Wasserzeichen-Token-Schlüssels zu überprüfen, der dem Wasserzeichen-Token zugehörig ist, das für die zweiten verschlüsselten Daten erzeugt wird.
System nach Anspruch 4, aufweisend: einen Transcoder, wobei die auf ihre Berechtigung geprüfte Anwendungsschicht Logik aufweist, die konfiguriert wird, um das Wasserzeichen-Token für die ersten verschlüsselten Daten zu erzeugen, wobei der Transcoder Logik aufweist, die konfiguriert wird, um: die zweiten verschlüsselten Daten und das Wasserzeichen-Token, das für die ersten verschlüsselten Daten erzeugt wird, aus dem Datenspeicher zu lesen, wobei der Transcoder konfiguriert wird, um die zweiten verschlüsselten Daten durch Verwenden des ersten Schlüssels zu entschlüsseln, um die ersten verschlüsselten Daten zu erhalten, wobei der Transcoder konfiguriert wird, um das Wasserzeichen-Token, das für die ersten verschlüsselten Daten erzeugt wird, durch Verwenden des Wasserzeichen-Token-Schlüssels zu überprüfen, der dem Wasserzeichen-Token zugehörig ist, das für die ersten verschlüsselten Daten erzeugt wird.
System nach Anspruch 7, aufweisend: einen Transcoder, wobei der Transcoder Logik aufweist, die konfiguriert wird, um: die ersten verschlüsselten Daten durch Verwenden eines dritten Schlüssels zu verschlüsseln, um dritte verschlüsselte Daten zu erhalten, wobei der Transcoder konfiguriert wird, um durch Verwenden eines Wasserzeichenschlüssels, der den dritten verschlüsselten Daten zugehörig ist, ein Wasserzeichen für die dritten verschlüsselten Daten zu erzeugen; und die dritten verschlüsselten Daten und etwaige erzeugte Wasserzeichen an ein berechtigtes Ziel zu senden.
System nach Anspruch 10, wobei das berechtigte Ziel Logik aufweist, die konfiguriert wird, um: das Wasserzeichen, das für die dritten verschlüsselten Daten erzeugt wird, durch Verwenden des Wasserzeichenschlüssels, der den dritten verschlüsselten Daten zugehörig ist, zu überprüfen, die dritten verschlüsselten Daten durch Verwenden des dritten Schlüssels zu entschlüsseln, um die ersten verschlüsselten Daten zu erhalten, das Wasserzeichen, das für die ersten verschlüsselten Daten erzeugt wird, durch Verwenden des Wasserzeichenschlüssels zu überprüfen, der dem Wasserzeichen zugehörig ist, das für die ersten verschlüsselten Daten erzeugt wird; und als Reaktion auf eine erfolgreiche Überprüfung des Wasserzeichens, das für die dritten verschlüsselten Daten erzeugt wird, und des Wasserzeichens, das für die ersten verschlüsselten Daten erzeugt wird, die ersten verschlüsselten Daten durch Verwenden des ersten Schlüssels zu entschlüsseln, um die Daten zu erhalten.
Computerrealisiertes Verfahren, aufweisend: Empfangen zweiter verschlüsselter Daten, von Wasserzeichen und eines ersten Wasserzeichen-Tokens von einem Datenspeicher als Reaktion auf eine Datenanforderung von einem Zielknoten außerhalb einer berechtigten Verschlüsselungsvertrauenszone, wobei die zweiten verschlüsselten Daten Daten sind, die mit einem ersten Schlüssel verschlüsselt wurden, um erste verschlüsselte Daten zu erhalten, die dann mit einem zweiten Schlüssel verschlüsselt werden, um die zweiten verschlüsselten Daten zu erzeugen, wobei die Wasserzeichen ein erstes Wasserzeichen, das für die ersten verschlüsselten Daten erzeugt wird, und ein zweites Wasserzeichen enthalten, das für die zweiten verschlüsselten Daten erzeugt wird, wobei das erste Wasserzeichen-Token für die ersten verschlüsselten Daten erzeugt wird; Überprüfen des zweiten Wasserzeichens, das für die zweiten verschlüsselten Daten erzeugt wird; Entschlüsseln der zweiten verschlüsselten Daten durch Verwenden des zweiten Schlüssels, um die ersten verschlüsselten Daten zu erhalten, als Reaktion auf eine Überprüfung des zweiten Wasserzeichens; Überprüfen des ersten Wasserzeichens, das für die ersten verschlüsselten Daten erzeugt wird; Senden der ersten verschlüsselten Daten an einen vertrauenswürdigen Überprüfer als Reaktion auf ein Empfangen einer Überprüfung des ersten Wasserzeichens, wobei der vertrauenswürdige Überprüfer konfiguriert wird, um das erste Wasserzeichen-Token zu überprüfen, das für die ersten verschlüsselten Daten erzeugt wird; Verschlüsseln der ersten verschlüsselten Daten mit einem dritten Schlüssel, um dritte verschlüsselte Daten zu erzeugen, als Reaktion auf ein Empfangen einer Überprüfung des ersten Wasserzeichen-Tokens, das für die ersten verschlüsselten Daten erzeugt wird, von dem vertrauenswürdigen Überprüfer; Erzeugen eines dritten Wasserzeichens und/oder eines dritten Wasserzeichen-Tokens für die dritten verschlüsselten Daten; und Senden der dritten verschlüsselten Daten, der Wasserzeichen und des bzw. der Wasserzeichen-Token, z.B. des dritten Wasserzeichens und/oder des dritten Wasserzeichen-Tokens, an ein berechtigtes Ziel.
Computerrealisiertes Verfahren nach Anspruch 12, wobei der vertrauenswürdige Überprüfer konfiguriert wird, um durch Verwenden des ersten Schlüssels die ersten verschlüsselten Daten zu entschlüsseln, um die Daten zu erhalten.
Computerrealisiertes Verfahren nach Anspruch 12, wobei der vertrauenswürdige Überprüfer eine Vorfilterfunktion enthält, die konfiguriert wird, um zu überprüfen, dass die Daten nicht verschlüsselt sind, wobei der vertrauenswürdige Überprüfer die Überprüfung nur als Reaktion auf eine erfolgreiche Überprüfung sendet, dass die Daten nicht verschlüsselt sind.
Computerrealisiertes Verfahren, aufweisend: Empfangen innerer verschlüsselter Daten durch einen vertrauenswürdigen Überprüfer mindestens teilweise auf Grundlage einer Datenanforderung von einem Zielknoten außerhalb einer berechtigten Verschlüsselungsvertrauenszone, wobei die inneren verschlüsselten Daten Daten sind, die mit einem inneren Schlüssel verschlüsselt wurden, um die inneren verschlüsselten Daten zu erzeugen; und Überprüfen eines inneren Wasserzeichen-Tokens, das für die inneren verschlüsselten Daten erzeugt wird, durch den vertrauenswürdigen Überprüfer, wobei das innere Wasserzeichen-Token für die inneren verschlüsselten Daten erzeugt wird.
Computerrealisiertes Verfahren nach Anspruch 15, wobei die Datenanforderung eine Datenschreibanforderung ist, wobei das Verfahren aufweist: Entschlüsseln der inneren verschlüsselten Daten durch Verwenden des inneren Schlüssels durch den vertrauenswürdigen Überprüfer als Reaktion auf eine erfolgreiche Überprüfung des inneren Wasserzeichen-Tokens, um die Daten zu erhalten; Ermitteln durch den vertrauenswürdigen Überprüfer durch Verwenden einer Vorfilterfunktion, dass die Daten unverschlüsselt sind; und Zurückgeben einer ersten Überprüfungsnachricht an einen Transcoder durch den vertrauenswürdigen Überprüfer als Reaktion auf eine erfolgreiche Überprüfung des inneren Wasserzeichen-Tokens und die Ermittlung, dass die Daten unverschlüsselt sind.
Computerrealisiertes Verfahren nach Anspruch 15, wobei die Datenanforderung eine Datenleseanforderung ist, wobei das Verfahren aufweist: Erzeugen eines neuen inneren Wasserzeichen-Tokens durch den vertrauenswürdigen Überprüfer.
Computerrealisiertes Verfahren nach Anspruch 15, aufweisend ein Empfangen des Wasserzeichen-Tokens, das für die inneren verschlüsselten Daten erzeugt wird, von dem Transcoder durch den vertrauenswürdigen Überprüfer, wobei das innere Wasserzeichen-Token durch Verwenden eines ersten Wasserzeichen-Token-Schlüssels für die inneren verschlüsselten Daten erzeugt wird; Überprüfen des inneren Wasserzeichen-Tokens, das für die inneren verschlüsselten Daten erzeugt wird, durch den vertrauenswürdigen Überprüfer; und Zurückgeben einer zweiten Überprüfungsnachricht an den Transcoder durch den vertrauenswürdigen Überprüfer als Reaktion auf eine erfolgreiche Überprüfung des inneren Wasserzeichen-Tokens, das für die inneren verschlüsselten Daten erzeugt wird.
Computerrealisiertes Verfahren nach Anspruch 15, wobei das innere Wasserzeichen-Token, das für die inneren verschlüsselten Daten erzeugt wird, durch den vertrauenswürdigen Überprüfer nicht überprüft wird, wobei das innere Wasserzeichen-Token durch Verwenden eines ersten inneren Wasserzeichen-Token-Schlüssels für die inneren verschlüsselten Daten erzeugt wird; wobei das Verfahren ein Zurückgeben des inneren Wasserzeichen-Tokens, das für die inneren verschlüsselten Daten erzeugt wird, an den Transcoder durch den vertrauenswürdigen Überprüfer aufweist.
Computerrealisiertes Verfahren nach Anspruch 15, aufweisend ein Erhalten eines zweiten inneren Wasserzeichen-Token-Schlüssels durch den vertrauenswürdigen Überprüfer, wobei der zweite innere Wasserzeichen-Token-Schlüssel verwendet wird, um das neue innere Wasserzeichen-Token für die inneren verschlüsselten Daten zu erzeugen; und ein Zurückgeben des neuen inneren Wasserzeichen-Tokens, das für die inneren verschlüsselten Daten erzeugt wird, an den Transcoder durch den vertrauenswürdigen Überprüfer.
Computerprogrammprodukt, das in einem computerlesbaren Speichermedium gespeichert wird, aufweisend Computerprogrammcode, der bei Ausführung durch ein Informationsverarbeitungssystem die Schritte eines beliebigen Verfahrens der Ansprüche 12 bis 20 durchführt.