DE102011118804A1 - Persistente Verschlüsselung mit XML Encrytion - Google Patents

Abstract

Viele Daten liegen heute schon in XML-Formaten vor, daher bietet sich XML Encryption zur Verschlüsselung dieser Daten an, allerdings ist hierbei kein gleichzeitiger Zugriff auf die Daten durch mehrere Nutzer möglich. Um eine persistente Verschlüsselung oder den Zugriff mehrerer Nutzer auf das gleiche Dokument zu gewährleisten, muss die Schlüsselinformation auch in der Klartextversion des XML-Dokuments erhalten bleiben. Dazu kann dem betreffenden Element ein Attribut hinzugefügt werden (5.a), das einen Datensatz wahlweise im gleichen Dokument oder extern referenziert. Der referenzierte Datenstaz enthält nähere Details zu z. B. verwendeten Algorithmen (5.b), Schlüsseln und weiteren Informationen (5.c). Bei dem referenzierten Schlüssel kann es sich um eine Referenz auf einen (verschlüsselten oder unverschlüsselten) Schlüssel handeln, der ebenfalls im gleichen Dokument oder extern referenziert wird. Das Verfahren ist auf alle Daten die im XML Format darstellbar sind anwendbar und eignet sich gleichermaßen zur Kurz- und Langzeit Persistierung für Daten in verschlüsselter Form. Hierbei ist es unerheblich ob die Daten zum Schutze einer Übertragen oder dauerhaften Ablage verschlüsselt persistiert werden sollen.

Description

• Stand der Technik
• Das Thema der Datenverschlüsselung ist nicht neu und wird durch mehrere auf dem Markt erhältliche Technologien adressiert. Die Lösungskonzepte basieren vorwiegend auf einem über das Web zugänglichen Datenraum, welcher wiederum auf einem verteilten Server-Cluster beruht. Zu nennen wären hier Produkte wie Microsoft Sharepoint oder Dokumentenmanagementsysteme wie z. B. OpenText. Bis auf wenige Ausnahmen bieten diese Systeme keinerlei kryptografischen Schutz für die gespeicherten Dokumente. Bei den wenigen Produkten, die eine Verschlusselungsfunktionalität bieten, liegen die verwendeten kryptografischen Schlüssel in der Obhut des Betreibers der Plattform und bieten somit keinen adäquaten Schutz für die Dokumente.
• Dateiverschlüsselungssysteme (wie z. B. TrueCrypt oder eCryptFS) bieten in der Regel nur lokalen Schutz. Beim Einsatz in Cloud-Storage-Szenarien werden diese Systeme schnell ineffizient, weil das komplette virtuelle Laufwerk, welches das verschlüsselte Dateisystem enthält, auf das genutzte Gerät geladen werden müsste. Dies ist aufgrund von Ressourcenbeschränkungen nicht möglich. Auch ergeben sich Probleme beim gleichzeitigen Zugriff mehrerer Nutzer.
• Einen weiteren Ansatz für die Verschlüsselung der Daten bietet PGP. PGP wird heutzutage häufig für die Verschlüsselung der E-Mails und einzelnen Dateien eingesetzt. Damit ist PGP für eine persistente Verschlüsselung viel besser geeignet als die Systeme, die das ganze Laufwerk verschlüsseln. Auf der anderen Seite bietet dieser Standard auch keine Unterstützung beim gleichzeitigen Zugriff von mehreren Nutzern auf das System. Ein modulares Konzept der Datenverschlüsselung ist hier erforderlich.
• SSL/TLS wird eingesetzt um eine Punkt-zu-Punkt-Sicherung der übertragenen gewährleisten zu können. Da die Daten nur auf der Transport-Ebene geschützt werden, ist dieses Konzept für eine persistente Dateiverschlüsselung nicht geeignet. Die Vertraulichkeit der Daten muss nämlich auf der Nachrichten-Ebene behandelt werden, damit diese in der verschlüsselten Form auch gespeichert werden können.
• XML Encryption wird bereits eingesetzt, um Daten auf der Nachrichten-Ebene zu schützen verschlüsselt zu übertragen. Es ist Bestandteil fast aller Webservice-Sicherheitsspezifikationen. Wir gehen über diesen Stand der Technik hinaus, indem wir XML Encryption erstmals zur persistenten Datenspeicherung einsetzen.
• Problem
• Viele Daten liegen heute schon in XML-Formaten vor, daher bietet sich XML Encryption zur Verschlüsselung dieser Daten an.
• XML Encryption ist sehr modular konzipiert: Es ist möglich, das ganze Dokument zu verschlüsseln, einzelne Unterelemente zu verschlüsseln, oder nur den Inhalt von Elementen zu verschlüsseln. In einer bevorzugten Implementierung der vorliegenden Patentidee werden einzelne Unterelemente eines gegebenen XML-Dokuments verschlüsselt.
• XML Encryption wird heute ausschließlich zur Absicherung der Übertragung von XML-Daten eingesetzt: Bei der Entschlüsselung geht die Information über den verwendeten Algorithmus und den verwendeten Schlüssel verloren, da das <KeyInfo>-Element (bzw. andere Elemente, die ähnliche Funktionen übernehmen) gelöscht wird. Bei der Verschlüsselung muss daher ein neuer symmetrischer Schlüssel, und ggf. auch ein neuer Algorithmus, gewählt werden.
• Es ist klar, dass solch eine persistente Verschlüsselung von Daten bei der verschlüsselten Datenspeicherung, bzw. ein gleichzeitiger Zugriff mehrerer Nutzer auf dieselben verschlüsselten Daten, nicht möglich ist.
• Lösung
• Diesen Mangel beheben wir durch die in Patentanspruch 1–10 aufgeführten Merkmale.
• Um eine persistente Verschlüsselung oder den Zugriff mehrerer Nutzer auf das gleiche Dokument zu gewährleisten, muss die Schlüsselinformation auch in der Klartextversion des XML-Dokuments erhalten bleiben. Hierzu gibt es prinzipiell zwei Möglichkeiten:
• • Möglichkeit 1: Das Key Info-Element (oder ein anderes Schlüssel-beschreibendes Element) bleibt im Klartext-Dokument erhalten. Ein Nachteil dieser Lösung besteht darin, dass unter Umständen auf den Klartext eine Schemavalidierung angewandt wird, und dass in diesem XML Schema das <KeyInfo>-Element nicht vorkommt. Generell könnte es zu Problemen bei der Datenverarbeitung des Klartextes kommen, wenn ein zusätzliches Element eingeführt wird.
• • Möglichkeit 2: Die Schlüsselinformation wird lokal z. B. in einer Datenbank abgelegt, und eine Referenz auf den entsprechenden Datenbank-Eintrag wird als XML-Attribut im Klartext-Dokument gespeichert. Dies ist unsere bevorzugte Lösung, da fast jedes XML-Schema eine Erweiterungsoption für Attribute vorsieht. Anwendungen, die die entschlüsselten Daten verarbeiten, werden in der Regel ihnen unbekannte Attribute ignorieren. Eine Gefahr besteht aber darin, dass während der Datenverarbeitung Attribute gelöscht werden. Hier müssen für die einzelnen Anwendungen (Browser, Textverarbeitung, Tabellenkalkulation, Terminverwaltung, ...) geeignete ID-Attribute gewählt werden.
• Allgemeines Funktionsschema der Lösung
• Das zu schützende Verfahren beschreibt einen Schutzmechanismus für öffentlich zugängliche Daten, welche z. B. auf mit dem Internet verbundenen Servern abgelegt sein können (Cloud Computing basierter Speicher, z. B. Amazon S3, Dropbox).
• Zum Schutz der Vetraulichkeit der Daten werden die Nutzdaten in verschlüsselter Form abgelegt. Zur Verwaltung und evtl. Indexierung der Daten (z. B. zur Suche oder zum Schnellzugriff) ist zusätzlich das Hinzufügen von unverschlüsselten META-Daten möglich.
• Die Innovation des Verfahrens ist die Inklusion von Informationen zur Rekonstruktion des Verschlüsselungsschlüssels im Klartext des Dokuments. Dies soll am Beispiel in erläutert werden. Die Referenzierung des Dokumetenschlüssels erfolgt in diesem Beispiel wahlweise durch die Verwendung einer Element-Referenz URI='#Dk1' (kenntlich gemacht durch Bezugsbezeichner 1.a) oder durch die Verwendung eines eindeutigen Identifikators <ds:KeyName>Dk1</ds:KeyName> (1.b).
• Der Datensatz aus wird in dieser Form „in der Cloud” abgespeichert. Wird der Datensatz auf ein Endgerät geladen, so muss dort der Schlüssel mit dem Namen „GkA”, der über URI='http://127.0.0.1/getKey?name=GkA' referenziert wird (1.c), dort vorhanden sein. Dies kann ein Public Key-Schlüsselpaar sein, oder ein symmetrischer Schlüssel. Nach Möglichkeit sollte dieser Schlüssel so gepeichert sein, dass er gegen Auslesen gesichert ist.
• Mit Hilfe des Schlüssels „GkA” kann dann zunächst der Inhalt von /Dokument/EncryptedKey/CipherData/CipherValue (1.d) entschlüsselt werden. Der Klartext ist der Schlüssel, der unter dem Namen „Dk1” referenziert wird. Mit diesem Schlüssel wird nun /Dokument/EncryptedData/CipherData/CipherValue (1.e) entschlüsselt; das Ergebnis ist das Element/Document/Data (2.a), das in dargestellt ist.
• Attribut-basierte Lösung
• Wie in Listing 2 zu sehen ist, wird das Attribut/Wertepaar „enc='pers-223323227987'” (2.b) nach der Entschlüsselung in das XML-Klartextelement eingefügt. Der Attributwert wird dabei vom Endgerät festgelegt, und stellt einen eindeutigen Verweis auf einen Datenbankeintrag dar, in dem der in angegebene Datensatz gespeichert ist. Das Klartextdokument darf jetzt unter der Vorgabe verarbeitet werden, dass der Wert des enc-Attributs nicht verändert wird.
• Soll das veränderte Dokument jetzt wieder gespeichert werden, so wird dazu der gleiche Schlüssel verwendet, der auch zum Entschlüsseln verwendet wurde. Dazu geht die Software auf dem Endgerät wie folgt vor:
• • Mithilfe des Wertes des „enc”-Attributs wird das in dargestellte <EncryptedKey>-Element (Teil 2) wieder aus der Datenbank gelesen.
• • Mithilfe des Schlüssels „GkA” wird der Schlüssel „Dk1” aus dem Unterelement <CipherValue> (3.a) dieses Elements entschlüsselt.
• • Mithilfe von „Dk1” wird das mit dem „enc”-Attribut markierte Element, unter Verwendung des in gespeicherten Verschlüsselungsalgorithmus (3.b) verschlüsselt.
• • Der so entstandene verschlüsselte Text wird Base64-enkodiert und in das <CipherValue>-Element eingefügt (3.c).
• • Das <Data>-Element aus wird durch das so entstandene <EncryptedData>-Element aus (Teil 1) ersetzt. Es stellt in diesem Beispiel das erste Kindelement des Wurzelelements <Document> dar.
• • Als zweites Kindelement des <Document>-Elements aus wird das <EncryptedKey>-Element aus (Teil 2) eingefügt.
• • Die Metainformation des gesamten Dokuments wird aktualisiert; z. B. wird ein ID-Attribut mit dem Wert „Nutzdaten” zum Element <EncryptedData> hinzugefügt (3.d).
• Es sind neben dieser konkreten Realisierung weitere Realisierungen innerhalb des durch den XML Encryption-Standard vorgegebenen Rahmen möglich.
• KeyInfo-basierte Lösung
• Der nächste Ansatz für eine persistente Speicherung bietet das Speichern des gesamten <KeyInfo>-Elementes in dem entschlüsselten Dokument an. Dabei muss die Entscheidung getroffen werden, wo das <KeyInfo>-Element beibehalten wird. Dies ist davon abhängig, wie das XML Schema des zu verarbeiteten Dokumentes aussieht und wo Möglichkeiten bestehen das Dokument zu erweitern, ohne die Verarbeitungs-Logik zu verletzen.
• Ein Beispiel dieser Lösung gibt . Wie in diesem Dokument zu sehen ist, wird das <EncryptedData>-Element direkt in das Element mit den entschlüsselten Daten hinzugefügt (4.a). Das Element <EncryptedKey> wird in diesem Fall als direktes Kind des Root-Elementes hinzugefügt (4.b).
• Abhängig vom XML Schema und von der Dokument-bearbeitenden Logik können die Stellen für die KeyInfo-beschreibende Elemente beliebig verschoben werden. Dabei muss aber sichergestellt werden, dass die Verschlüsselungs-Komponente weiß, welche Elemente wieder verschlüsselt werden müssen.
• Das Klartextdokument darf jetzt unter der Vorgabe verarbeitet werden, dass die Elemente <EncryptedKey> und <EncryptedData> nicht verändert wird.
• Soll das veränderte Dokument jetzt wieder in die Cloud geschickt werden, so wird dazu der gleiche Schlüssel verwendet, der auch zum Entschlüsseln verwendet wurde. Dazu geht die Software auf dem Endgerät wie folgt vor:
• • Mithilfe der Position des <EncryptedData>-Elementes (oder einem zusätzlichen Eintrag in diesem Element) wird festgestellt (4.a), dass das <Data>-Element verschlüsselt werden muss. Dafür muss der „aes128-cbc”-Algorithmus und der Schlüssel „Dk1” benutzt werden (entnommen aus 4.c und 4.d).
• • Das <EncryptedKey>-Element mit der Id='Dk1' (4.b) wird gesucht und mithilfe des Schlüssels „GkA” (4.e) aus dem Unterelement <CipherValue> dieses Elements (4.f) entschlüsselt.
• • Mithilfe von „Dk1” wird das <Data>-Element (4.g) verschlüsselt, wobei das <EncryptedData>-Element (4.a) dabei nicht berücksichtigt wird und nicht mitverschlüsselt wird.
• • Die so entstandenen verschlüsselten Daten werden Base64-codiert und in das <CipherValue>-Element gelegt (4.h).
• • Anschließend wird das Dokument analog zu strukturiert.
• Es sind neben dieser konkreten Realisierung weitere Realisierungen innerhalb des durch den XML Encryption-Standard vorgegebenen Rahmen möglich.

Claims (10)

1. Verfahren zu verschlüsselten Speicherung von Daten im XML-Format, dadurch gekennzeichnet, dass ein paralleler Zugriff mehrerer Nutzer möglich ist.
2. Verfahren nach Patentanspruch 1, dadurch gekennzeichnet, dass auch ein Schreibzugriff möglich ist.
3. Verfahren nach Patentanspruch 1 oder 2, dadurch gekennzeichnet, dass bei Entschlüsselung die Information zum verwendeten Schlüssel lokal gespeichert wird und dem Klartext eine Referenz auf diesen gespeicherten Schlüssel zugefügt wird.
4. Verfahren nach Patentanspruch 3, dadurch gekennzeichnet, dass die Referenz ein Attribut ist.
5. Verfahren nach Patentanspruch 3, dadurch gekennzeichnet, dass die Referenz ein Unterelement ist.
6. Verfahren nach Patentanspruch 3, dadurch gekennzeichnet, dass die Referenz im Textblock erfolgt.
7. Verfahren nach Patentanspruch 1 oder 2, dadurch gekennzeichnet, dass ein paralleler Zugriff mehrerer Nutzer aufgeteilt in mehrere Gruppen möglich ist.
8. Verfahren nach Patentanspruch 1 oder 2, dadurch gekennzeichnet, dass die Verschlüsselung sowohl symmetrisch als auch asymmetrisch erfolgen kann.
9. Verfahren nach Patentanspruch 1 oder 2, dadurch gekennzeichnet, dass die Verschlüsselung durch Kombination symmetrischer und asymmetrischer Verfahren erfolgt.
10. Verfahren nach Patentanspruch 3, dadurch gekennzeichnet, dass die Referenz selbst verschlüsselt abgelegt wird.

Images