Anforderungen an die XML-Verschlüsselung (XML Encryption Requirements)

Inhaltsverzeichnis

1. Einleitung
2. Prizipien des Designs und der Anwendungsbereich
3. Anforderungen zur partiellen Verschlüsselung und die Anforderungen des Dokuments XML Encryption Syntax and Processing.
   1. Encryption Data Model and Syntax
   2. Objekte
   3. Verarbeitung
   4. Algorithmen und Strukturen
   5. Sicherheit
   6. Koordination
   7. Geistiges Eigentum
4. Verweise

1. Einleitung

Die Recommendation XML 1.0 [XML] spezifiziert die Syntax einer Klasse bestimmter Quellen, die XML-Dokumente genannt werden. Diese Spezifikation schlägt die Anforderungen für eine XML-Syntax und XML-Verarbeitung zur Verschlüsselung von digitalem Inhalt vor, eingeschlossen XML-Dokumentfragmente und Protokollmeldungen.

2. Prizipien des Designs und der Anwendungsbereich

Dieser Bereich beschreibt übergeordnete Prizipien des Designs und die Definition des Geltungsbereichs. Diese Prizipien sind Ausdruck einer Absicht/Motivation. Wie diese Motivationen realisiert werden, wird in den unten stehenden Abschnitten beschrieben.

1. Die Spezifikation XML Encryption muss beschreiben, wie XML verwendet werden muss, um eine digital verschlüsselte Internet-Quelle zu beschreiben (XML selbst auch eingeschlossen) {prop1, prop2}. Die XML-Beschreibung der verschlüsselten Quelle muss ein Objekt erster Klasse sein (z.B. referenzierbar und infolgedessen beschreibbar, signierbar usw.), und muss von einem bestimmten Elementtyp repräsentiert werden.
   1. Diese Spezifikation muss die Verschlüsselung eines XML-Dokumentfragments oder die Verschlüsselung eines ganzen XML-Dokuments vorsehen.
      1. Die Feinheit der Verschlüsselung in einem XML-Dokument ist begrenzt auf Elemente (eingeschlossen Start-/End-Tags) oder Elementinhalte (zwischen den Start- und End-Tags) {prop2, WS, FTF1}.

         Nach einer langen Diskussion über die Anforderungen, die Komplexität und die Alternativen der Attributverschlüsselung {List: Hallam-Baker, Simon, Reagle} hat die Arbeitsgruppe entschieden, mit der Forderung einer Elementverschlüsselung fortzufahren. Weiterhin ist die Arbeitsgruppe aber offen für diesbezügliche Kommentare, für Versuche und die Einreichung von Vorschlägen zur Attributverschlüsselung oder Alternativen, die die Forderung erfüllen, empfindliche Attributwerte zu verschlüsseln.

   2. Die Spezifikation muss das Trennen von Verschlüsselunginformationen aus verschlüsselten Daten vorsehen, und Verweismechanismen für die Adressierung von Verschlüsselungsinformationen in verschlüsselten Datenbereichen unterstützen und umgekehrt. {HP: R3.7, prop2}
   3. Die Spezifikation muss die Mehrfachverschlüsselung von Daten erlauben (z.B. die Verschlüsselung von XML-Dokumenten, in denen schon einige Elemente verschlüsselt sind) {prop1, prop2}. Mehrfach verschlüsselte Daten müssen die gleiche Syntax und Semantik verwenden wie alle anderen verschlüsselten Daten.
2. Die Spezifikation muss einen Mechanismus beschreiben, der die Übertragung von Verschlüsselungsinformationen zu einem Empfänger vorsieht. Die Struktur muss so flexibel sein, dass zahlreiche Anforderungen einer Anwendung erfüllt werden, eingeschlossen:
   1. die Übertragung eines kodierten Schlüsselwerts, der an den Empfänger mittels eines asymmetrischen oder symmetrischen Schlüssels gerichtet ist
   2. die Zuweisung eines Namens oder eines URI-Verweises zu einem bekannten Schlüssel.

   Es muss möglich sein (auch wenn es nicht notwendig ist), Schlüsselinformationen als Teil einer verschlüsselten XML-Datenrepräsentation einzuschließen oder auf externe Schlüsselinformationen zu verweisen. Zusätzlich müssen Schlüssel in der Lage sein (auch wenn es nicht notwendig ist), die Daten, die sie verschlüsseln, zu identifizieren.

3. Die Verschlüsselungsmechanismen müssen einfach sein: Beschreibe, wie digitaler Inhalt, XML-Dokumente und Fragmente davon verschlüsselt/entschlüsselt werden {Reagle}
   1. Nur Informationen, die für die Entschlüsselung notwendig sind, müssen vorgesehen werden. {Reagle} Die Spezifikation muss die effiziente Entschlüsselung von verschlüsselten Daten und diesbezüblichen Informationen erlauben, wenn die Gruppen sich auf eine Verschlüsselungsweise und Schlüsselmaterial vorab verständigt haben. So muss die Spezifikation kein Attribut vorschreiben, das beschreibt, wie die Daten verschlüsselt werden.
   2. Diese Spezifikation gibt keine Auskunft über den Ort einer sicheren Anwendung, sollte ein Schlüssel angegeben werden.
   3. Diese Spezifikation gibt keine Auskunft über Authentisierung. {List: Reagle, WS}
   4. Diese Spezifikation gibt keine Auskunft über Zugangsberechtigungen und Zugangskontrolle. {List: Reagle, Simon, Kudoh, WS}
4. Die Arbeitsgruppe (WG - Working Group) muss bereits existierende Spezifikationen verwenden, es sei denn, sie kann die Notwendigkeit für eine neue nachhaltig rechtfertigen. {Reagle} Zum Beispiel sollte sie DOM oder Information Set als Datenmodell für XML-Teile verwenden und Canonical XML für die Kanonisierung, sofern nicht ein triftiger Grund für eine Alternative spricht.
5. Die Spezifikation muss ein minimales (erweiterbares) Spektrum an Algorithmen und Schlüsselstrukturen angeben, um die Anforderungen der Interoperabilität zu erfüllen. {Reagle}
6. Die Spezifikation sollte sich um ein Minimum an Optionalität und um ein Maximum an Erweiterbarkeit bemühen, so dass die Spezifikation zügig implementiert werden kann.
7. Wann immer es möglich ist, ist jede Verschlüsselungsquelle, bzw. jeder Algorithmus ein Objekt erster Klasse (welches auch verschlüsselt oder signiert werden kann), und wird durch einen URI identifiziert. {prop1, prop2}

3. Anforderungen

1. Encryption Data Model und Syntax

1. Das XML-Datenmodell, das von XML-Encryption zur Identifizierung oder zur Repräsentation von verarbeiteten Daten verwendet wird, muss basieren auf:
   1. einer einfachen, aneinandergereihten Untermenge des Datenmodells (z.B. Element, Attribut usw.) und Eigenschaften (z.B. child, parent, localname, prefix usw.). {WS}

      Die WG testet diese Anforderungen zur Zeit noch im Zusammenhang mit der Implementierung unter Verwendung von Baum- und Event-basierten Parsern.

2. XML-Verschlüsselung kann auf jede Internetquelle angewendet werden -- eingeschlossen Inhalte, die kein XML sind. {prop1, prop2} Siehe auch Anforderungen: Objekte.
   1. Wenn ein Objekt verschlüsselt wird, das nicht XML ist (z.B. externe Daten), wird die Information, die nötig ist, um dem Empfänger bei der Entschlüsselung zu helfen, in einer Instanz von XML eingeschlossen (z.B. die Verschlüsselungsmethode, Schlüsselinformationen usw.). Die Entscheidung, die verschlüsselten Objektverschlüselungsdaten als base64-verschlüsseltes CDATA in dieses XML einzubinden, oder einfach nur einen Verweis auf die Oktettreihe der kodierten Daten anzulegen, liegt bei der Anwendung. In beiden Fällen müssen die verschlüsselten Daten wieder den Datentyp des originalen Objekts annehmen. {TimBL, Dillaway} 

2. Objekte

1. Es muss möglich sein, den originalen Typ (z.B. XML CDATA, image/gif) der verschlüsselten Daten anzugeben um den Entschlüsselungvorgang zu unterstützen. Für nicht-XML-Daten, sollten bereits existierende MIME-Typdefinitionen [MIME] verwendet werden. 
2. Binäre Daten müssen als Base64 verschlüsselt werden, wenn sie in XML dargestellt werden. {FTF1}
3. Diese Spezifikation muss kein Verpackungsformat für Nicht-XML-Daten (z.B. MIME-Objekte) definieren, die sich von den verschlüsselten Informationen unterscheiden, die in der Syntax der XML-Encryption beschrieben sind.
4. Die Spezifikation braucht kein Verpackungsformat zu definieren, das die Beziehung zwischen verschlüsselten Objekten beschreibt. Zum Beispiel wird die Spezifikation nicht angeben, wie eine Anwendung anzeigen kann, dass mehrere verschlüsselte Objekte die Verschlüsselung des gleichen Objekts sind, nur in unterschiedlichen "Verpackungen" (Verschlüsselungen, Kompression usw.). {prop3: offene Frage 2, ausgeräumt in FTF1}

3. Verarbeitung

1. Verarbeiten  {WS}
   1. Anwendungen für XML Encryption müssen die XML-Namensräume [XML-namespaces] unterstützen.
   2. Anwendungen für XML Encryption müssen XML Schema [ XML-schema] in der Form unterstützen, dass sie XML Encrytion Instanzen erzeugen, die konform zum den Encryption Schema Definitionen sind. {Reagle}
   3. Implementierungen der Spezifikation sollten mit existierenden XML-Parsern und Schema-Implementierungen zusammenarbeiten. Jedoch können sich Veränderungen an bestimmten DOM- und/oder XML-Parser-Implementierungen als nützlich erweisen, um die Anwendungsentwicklung zu vereinfachen oder die Runtime-Effizienz zu verbessern. Auf diese Details geht die Spezifikation XML Encryption nicht ein.
2. XML-Instanzvalidität {WS}
   1. Verschlüsselte Instanzen müssen wohlgeformt sein, aber sie müssen nicht gültig gegenüber ihrer eigentlichen Definition sein (z.B. verstecken Anwendungen, die die Elementstruktur verschlüsseln, sinnvollerweise diese Struktur).
   2. Autoren von Instanzen, die verschlüsselte Instanzen validieren wollen, müssen eine der folgenden Varianten wählen:
      1. Das originale Schema so schreiben, als würden die erzeugten Instanzen validiert werden, deren Änderungen in Ihrer Struktur und die Inklusion von Elementtypen auf dem Namensraum von XML-Encryption beruhen.
      2. Ein Post-Encryption Schema angeben, um verschlüsselte Daten zu validieren.
      3. Nur PCDATA-Text von Elementinhalten verschlüsseln und deren Verschlüsselungs- und Schlüsselinformationen in einem externen Dokument ablegen. (Dies erfordert eine feinkörnige ausgelagerte /externe Verschlüsselung.)
3. Das Verarbeitungsmodell muss mit Hilfe von XML, DOM oder Information Set Technologie beschrieben werden und Implementierungen können auf anwendungsbezogener Logik basieren (z.B. XPath und DOM werden nicht für eine Implementierung benötigt). {List: Ferguson, FTF1}

   Die WG (Arbeitsgruppe) arbeitet noch an ihrem Verständnis für die Anforderungen des Verarbeitungsmodells im Lichte der Implementierungsserfahrung.

4. Das Verweismodell muss auf den Grundlagen von XML-Signature beruhen Verweisverarbeitungsmodell [XMLDSIG] mit den beiden folgenden Anforderungen:
   1. Wie empfohlen in [XMLDSIG], sollte jede Fragmentverarbeitung als Teil der Transformation angegeben werden, wenn ein Verweismechanismus Transformationen unterstützt.
   2. Unterstützt ein Verweismechanismus keine Transformationen, sollten Anwendungen die dokumentintern verweisenden XPointer '#xpointer(/)' und '#xpointer(id("ID"))' unterstützen.
5. Transformationen  {WS}
   1. Verschlüsselungstransformationen: Die Spezifikation muss keine zusätzlichen Transformationen als Teil der Verschlüsselung und Entschlüsselung von Daten vorsehen; Transformationen von Daten, die verschlüsselt/entschlüsselt sind, müssen von der Anwendung vollzogen werden. Zum Beispiel könnte die Kompression so ablaufen, dass der Inhalt komprimiert wird und die Daten in einer XML-Kompressionssyntax eingehüllt werden und dann verschlüsselt werden. {FTF1}
6. Verschlüsselung und Signaturen
   1. Die Spezifikation muss Möglichkeiten empfehlen, XML-Signature mit XML-Encryption so zu verwenden, dass mehrere Gruppen wahlweise Dokumentfragmente, die bereits verschlüsselt und signiert sind, verschlüsseln und signieren können. Empfänger sollten einfach feststellen können, ob Daten vor der Signaturüberprüfung entschlüsselt werden müssen oder nicht.
      1. Anwendungen haben die folgenden Möglichkeiten:
         1. Werden Daten verschlüsselt, wird auch deren Signatur verschlüsselt; folglich können die Signaturen, die man sehen kann, validiert werden. (Jedoch ist das mit abgetrennten Signaturen nicht immer einfach zu erreichen..){List: Finney}
         2. Die Signaturtransformation "Decrypt-Except" [XML-DSIG-Decrypt] anwenden. Sie funktioniert wie folgt: Wird eine Entschlüsselungstransformation in der laufenden Ausführung der Signaturtransformation entdeckt, werden alle verschlüsselten Inhalte in dem Dokument entschlüsselt, außer denen, die durch eine Verweisaufzählung ausgeschlossen wurden. {List: Maruyama, FTF1}.
7. Die Verschlüsselung und die XML-Verarbeitung sollte sein:
   1. schnell {List: Ferguson}
   2. speichereffizient {List: Ferguson}
   3. kompatibel zu Baum- und Event-basierten Parsern {List: Ferguson}.

4. Algorithmen und Strukturen

1. Die Lösung muss mit willkürlichen Verschlüsselungsalgorithmen zusammenarbeiten, eingeschlossen symmetrische und asymmetrische Schlüsselschemata, sowie dynamische Verhandlung von Schlüsselmaterial. {prop1, prop2}
2. Die Spezifikation muss einen obligatorischen Algorithmus angeben oder auf einen verweisen, um einen Algorithmus zu implementieren, der für die meisten Standardanwendungen geeignet ist.
   1. Stream Encryption Algorithmen {FTF1}
      1. keine
   2. Block Encryption Algorithmen {FTF1}
      1. AES mit CMS-Schlüssellänge muss implementiert werden
      2. 3DES muss implementiert werden -- das kann eventuell vernachlässigt werden, wenn AES ausgereift ist.
      3. AES kann optional mit anderen Schlüssellängen implementiert werden.
   3. Verkettungsmodi {FTF1}
      1. CBC (Cipher Block Chaining) mit PKCS#5 kann optional implementiert werden.
   4. Schlüsseltransport {FTF1}
      1. RSA-OAEP mit AES muss implementiert werden.
      2. RSA-v1.5 mit 3DES muss implementiert werden --das kann eventuell vernachlässigt werden, wenn AES ausgereift ist.
   5. Key Agreement {FTF1}
      1. Diffie-Hellman kann optional implementiert werden.
   6. Symmetric Key Wrap {FTF1}
      1. AES KeyWrap ist erforderlich -- sobald es endgültig spezifiziert ist.
      2. CMS-KeyWrap-3DES ist erforderlich.
   7. Message Integrity
      1. AES/3DES mit SHA1 kann optional implementiert werden.
   8. Authentisierung {FTF1}
      1. Es wird empfohlen, XML Signature [XMLDSIG] zu implementieren.
   9. Kanonisierung {FTF1}
      1. Canonical XML kann optional implementiert werden.
   10. Kompression {FTF1}
       1. keine
3. Schlüsselstrukturen
   1. Umfang: es müssen nur Schlüsselstrukturen definiert sein, die von den obligatorischen und empfohlenen Algorithmen gefordert werden. {Reagle}
   2. Die Spezifikation sollte nicht angeben, wie der betreffende Empfänger von Schlüsselinformationen im optionalen Attribut "hint" angegeben wird. {prop3: open issue 1, FTF1}
   3. Die Spezifikation sollte die Syntax für Schlüsselinformationen der Spezifikation XML Signature (das Element dsig:KeyInfo) im höchst möglichen Maße unterstützen.{prop3, FTF1}

5. Sicherheit

Die Spezifikation XML Encryption muss eine Erörterung über mögliche Verwundbarkeiten enthalten und empfohlene Vorgehensweisen, wenn das definierte Verarbeitungsmodell in einem breiten Anwendungskontext verwendet wird. Auch wenn es unmöglich ist, alle Anwendungsgebiete vorauszusagen wie ein XML Encryption Standard verwendet werden kann, sollten die Benutzer gewarnt werden, wie mögliche subtile Schwächen eingebaut werden können.

Es müssen mindestens die folgenden Arten der Verwundbarkeit angegeben werden.

1. Sicherheitsaspekte, die von bekannten Plain-Text- und Datenlängen-Informationen herrühren.
   1. Ein Angreifer könnte die originalen Strukturen des Plain-Text über dessen Schema kennen. {List: Wiley}
   2. Ein Angreifer könnte die Längen und die Redundanz der Plain-Text-Daten kennen. {List: Finney}
2. Verarbeitung von ungültigen entschlüsselten Daten, wenn kein Mechanismus zur Integritätsprüfung in Verbindung mit der Verschlüsselung verwendet wird. {List: Lambert, FTF1}
3. Mögliche Schwachpunkte als Ergebnis der Kombination von Signierung und Verschlüsselung.
   1. Signieren vor dem Verschlüsseln: die Signatur könnte Informationen über die Daten offenlegen, die nun verschlüsselt worden sind, wenn keine adäquaten Vorkehrungen getroffen werden (wie z.B. eine verschlüsselte zufällige Zeichenkette vor dem Hashing an den Plain-Text anzuhängen). {List: Finney}
   2. Verschlüsseln vor dem Signieren: Benutzer könnten versehentlich verschlüsselte Daten mit der Semantik (e.g., asserts or agrees to) der unverschlüsselten Form der Daten signieren. [XMLDSIG: Nur das, was zu "sehen" ist, sollte signiert werden.]. Zusätzlich könnte es mehrere (Daten, Schlüssel) Paare geben, die zu denselben verschlüsselten Daten führen. Deshalb muss sehr große Sorgfalt bei der Wahl der Verschlüsselungsfunktion oder des Signierungsprozesses walten, um die Möglichkeit einer Signaturrückweisung zu verringern. (z.B. "Ich hab das nicht gesagt, ich habe eine andere Nachricht signiert, die unter einem anderen Schlüssel verschlüsselt wurde.") {List: Wang, Ashwood}.
4. Die Spezifikation sollte Anwendungsdesigner und Benutzer warnen, Informationen über verschlüsselte Daten zu offenbaren.
   1. Über jede Semantik, die sich aus einem URI ergeben kann.

6. Koordination

Die Spezifikation XML Encryption sollte die Anforderungen der folgenden Anwendungen erfüllen (wie auch unterstützen) oder mit den folgenden Anwendungen zusammenarbeiten:

• XW3C XML Signature {Reagle}
• W3C XML Protocols {Reagle}
• Oasis XML-Based Security Services TC (SSTC) {Reagle}
• Synchronized Multimedia Integration Language. {List: Simon}

Um sicherzustellen, dass die oben genannten Forderungen hinreichend erfüllt sind, muss die Spezifikation XML Encryption von ernannten Mitgliedern folgender Communities überprüft werden:

• XML Signature WG
• XML Protocol
• XML Schema WG
• XML Core WG
• Internationalization IG

8. Geistiges Eigentum

1. Die Spezifikation sollte keine behindernden Technologien enthalten: Sie sollte keine Inhalte besitzen, die Lizenzgebühren für die Implementierung und die Verwendung erforderlich machen. {List: Ferguson}

   "Von den Mitgliedern der XML Encryption Working Group und jeder anderen Working Group, die in der XML Encryption Activity mitgewirkt haben, wird erwartet, dass sie geistiges Eigentum, das sie in diesem Bereich besitzen, freigeben. Geistiges Eigentum, das grundlegend für die Implementierung der Spezifikationen ist, die von dieser Activity hervorgebracht wurden, muss zumindest für die Lizensierung auf der Royalty-Free-Basis verfügbar sein. Auf Vorschlag der Working Group und des Direktors des W3C, können Technologien eventuell akzeptiert werden, wenn sie zu vernünftigen und nicht-diskriminierenden Konditionen lizensiert sind." XML Encryption Charter.

4. Verweise

C2000

Crypto 2000 XML Encryption BoF. Santa Barbara, CA. 24. August

DOM

Document Object Model Core, Level 3. Arnaud Le Hors. W3C Working Draft. Januar 2001.
http://www.w3.org/TR/DOM-Level-3-Core/core.html

FTF1

XML Encryption Face-to-Face. Boston, MA. März 2000

HP

Requirements and Goals for the Design of an 'XML Encryption Standard'. Gerald Huck und Arne Priewe. November 2000.

InfoSet

XML Information Set, W3C Proposed Recommendation. John Cowan. August 2001.

http://www.w3.org/TR/2001/PR-xml-infoset-20010810/

List

XML Encryption List (eine nicht moderierte und ungeprüfte öffentliche Mailing-Liste).

MIME

RFC2046. MIME Part Two: Media Types  November 1996.

http://rfc.net/rfc2046.html

MyProof

MyProof Position Paper On XML Encryption. Steve Wiley.

prop1

XML Encryption strawman proposal. Ed Simon und Brian LaMacchia. 09. Aug 2000.

prop2

Another proposal of XML Encryption. Takeshi Imamura. 14. Aug 2000.

prop3

XML Encryption Syntax and Processing. Dillaway, Fox, Imamura, LaMacchia, Maruyama, Schaad, Simon. Dezember 2000.

WS

W3C XML Encryption Workshop [minutes]. SanFrancisco. 02. November 2000.

XML

Extensible Markup Language (XML) 1.0 Recommendation. T. Bray, J. Paoli, C. M. Sperberg-McQueen. Februar 1998.

http://www.w3.org/TR/1998/REC-xml-19980210

XML-C14N

Canonical XML. W3C Recommendation. J. Boyer. März 2001.

http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.ietf.org/rfc/rfc3076.txt

XML-ns

Namespaces in XML Recommendation. T. Bray, D. Hollander, A. Layman. Januar 1999.

http://www.w3.org/TR/1999/REC-xml-names-19990114/

XML-schema

XML Schema Part 1: Structures W3C Recommendation. D. Beech, M. Maloney, N. Mendelsohn, H. Thompson. Mai 2001.

http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
XML Schema Part 2: Datatypes W3C Recommendation. P. Biron, A. Malhotra. Mai 2001.

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

XMLDSIG

XML-Signature Syntax and Processing. W3C Proposed Recommendation. D. Eastlake, J. Reagle, und D. Solo. August 2001.

http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/

XML-DSIG-Decrypt

Decryption Transform for XML Signature. W3C Working Draft. T. Imamura und H. Maruyama.

http://www.w3.org/TR/2001/WD-xmlenc-decrypt-20010626

XSet

Full Fidelity Information Set Representation. Jonathan Borden. XML-Dev

http://lists.xml.org/archives/xml-dev/200008/msg00239.html

URI

RFC2396. Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August 1998
http://www.ietf.org/rfc/rfc2396.txt