XML Security
Ausarbeitung Alexander Haupt | Oktober 2003 | Seminar XML für Fortgeschrittene

Inhalt

  1. Motivation
  2. Grundbegriffe und -prinzipien
  3. Asymmetrisches Verfahren (Public Key)
  4. XML Signature
  5. XML Encryption
  6. Web Services Security Language (WSS)
  7. Referenzen

1. Motivation

Geschäftliche Transaktionen, besonders im sogenannten "Business to Business"-Bereich, finden heutzutage hauptsächlich über öffentliche und somit potentiell unsichere Weitverkehrsnetze statt. Sensible Kunden- und Geschäftsdaten werden sowohl innerhalb des Unternehmens ausgetauscht als auch zwischen Geschäftspartnern. Besonders das Aufkommen von externen Online-Dienstleistern, die ihre Dienste als sogenannten Webservice zur Verfügung stellen, hat den Bedarf an Sicherheitsstandards für den XML-basierten Datenaustausch verstärkt. Natürlich existieren mit SSL und VPN (Virtual Private Network) bereits Methoden, verschlüsselte Punkt-zu-Punkt Verbindungen herzustellen, allerdings sind diese Lösungen im konkreten Fall mit Nachteilen behaftet. Die angeführten Technologien stellen nämlich nur eine reine Transportsicherung dar, d.h. Sender und Empfänger der Daten nutzen entweder keine oder eine andere Art der Verschlüsselung für die Datenhaltung. Sobald der Transport abgeschlossen ist, sind alle sicherheitsrelevanten Informationen, die zum Beispiel zur Authentifizierung und Validierung benutzt werden können, verloren, da sie nicht direkter Bestandteil der übermittelten Daten sind.

Die wichtigsten Anforderungen an Sicherheitsstandards sind:

Public-Key-Verfahren erfüllen all diese Anforderungen und deshalb erläutert die folgende Arbeit Methoden, Public-Key-Verfahren mit XML-basiertem Nachrichtenaustausch zu verbindet. Dabei werden die Standards XML Encryption, XML Digital Signature und Web Service Security Language vorgestellt.

2. Grundbegriffe und -prinzipien

2.1 Begriffe

In den nachfolgenden Kapiteln werden folgende Begriffe gebraucht:

2.2 Grundprinzipien der Verschlüsselung

Ein zentrales Dogma der Kryptologie besagt, daß nicht die Geheimhaltung der Funktionalität einen guten Verschlüsselungsalgorithmus ausmacht, sondern die mit der bloßen Mathematik (Logarithmusproblem, Primzahlfaktoren) einhergehende zeitliche "Unmöglichkeit" der Berechnung.

2.2.1 Symmetrische Verschlüsselung

Symmetrische Verschlüsselung
Bei der symmetrischen Verschlüsselung besitzen sowohl der Sender als auch der Empfänger den gleichen Schlüssel. Das bedeutet, daß sowohl Ver- als auch Entschlüsselung mit dem gleichen Schlüssel geschehen. Diese Methode ist sehr schnell, da nur relativ kleine Schlüsselgrößen benötigt werden, typischerweise 128, 256 oder 512 Bit.
Vor der Kommunikation muß allerdings der gemeinsame Schlüssel über einen sicheren Kanal ausgetauscht werden, was sofort den gravierendsten Nachteil dieser Methode erkennen läßt: Bei einer großen Menge an Teilnehmern ist der Aufwand für die sichere Schlüsselverteilung unangemessen hoch.

2.2.2 Asymmetrische Verschlüsselung (Public-Key)

Asymmetrische Verschlüsselung Das Verfahren der asymmetrischen Verschlüsselung beruht auf einem Schlüsselpaar, welches invers zueinander einsetzbar ist: Mit dem einen Schlüssel verschlüsselte Daten können nur mit dem anderen Schlüssel wieder entschlüsselt werden. Schlüssel dieser Kategorie sind typischerweise größer als 1024 Bit, d.h. die Ver- und Entschlüsselung geschieht aufgrund der aufwendigeren Berechnung etwas langsamer.

3. Asymmetrisches Verfahren (Public-Key)

3.1 Der Austausch verschlüsselter Nachrichten

Der Austausch verschlüsselter Nachrichten mit Hilfe von öffentlichen und privaten Schlüsseln soll hier am Standardbeispiel Alice und Bob verdeutlicht werden:

images/bob2alice.gif

Beim Versand einer Nachricht an Alice verwendet Bob ihren öffentlichen Schlüssel, zu dem sie den geheimen privaten besitzt. Sobald die Nachricht verschlüsselt ist, kann sie niemand außer Alice, auch nicht Bob, wieder entschlüseln. Nach dem Empfang verwendet Alice ihren geheimen privaten Schlüssel, um Bobs Nachricht zu entschlüsseln und zu lesen.
Wenn Alice antwortet, tut sie dies in der gleichen Weise: Sie verwendet Bobs öffentlichen Schlüssel für die Verschlüsselung, der wiederum seinen privaten zur Entschlüsselung:

Bei der Antwort werden die Schlüssel entsprechend getauscht:
images/alice2bob.gif

3.2 Digitale Signatur

3.2.1 Identität des Absenders

Woher weiß Alice jedoch, daß tatsächlich Bob die Nachricht geschickt hat und nicht ein Dritter?
Lösung: Bob verschlüsselt die Nachricht erst mit seinem privatem Schüssel, und anschließend den erhaltenen Ciphertext mit Alice öffentlichem Schlüssel. So ist sichergestellt, daß Aber: In der Praxis verschlüsselt man aus Effizienzgründen nicht die ganze Nachricht mit seinem privaten Schlüssel, sondern verwendet sogenannte Hash-Funktionen zur Erzeugung eines eindeutigen Fingerabruckes der Nachricht.

3.2.2 Hash-Funktionen

Einen Algorithmus, der aus einer beliebig langen Zeichenkette A deterministisch eine Zeichenkette B fester Länge generiert (Hashwert, Fingerabdruck, Digest), nennt man Hash-Funktion. Sie besitzen folgende Eigenschaften: Beispiele: MD5, SHA1

3.2.3 Signierung von Nachrichten

Bob hasht seine Nachricht und verschlüsselt nur den Hashwert: Er signiert! Alice entschlüsselt den von Bob mitgeschickten Hashwert, hasht ebenfalls die Nachricht und vergleicht anschließend die beiden Werte. Weichen diese voneinander ab, ist die Nachricht während der Übermittlung verändert worden. Auch die geringste Veränderung an der Nachricht erzeugt einen völlig anderen Hashwert.

verify signature

3.2.4 Kombination: Verschlüsselt und Signiert

Eine Kombination von Verschlüsselung und Signierung hat offensichtlich mehrere Vorteile:

signed and encrypted

3.3 Zertifikate

3.3.1 Der Mann in der Mitte

Ein Problemm das als Man-In-The-Middle-Attack bekannt ist, besteht in der Tatsache, das sich trotz Verschlüsselter und Signierter Kommunikation die wahre Identität des Absenders nicht allein aus seinem verwendeten Schlüssel ergibt. Die Erzeugung eines Schlüsselpaares geschieht vom Besitzer selbst und somit kann der Schlüssel vom selben vorsätzlich mit falschen Informationen versehen sein, z.B. einem falschem Namen. Diesem Problem der sogenannten "fake keys" begegnet man durch eine geeignete Zertifizierung. Ein Zertifikat bescheinigt dem Inhaber eines öffentlichen Schlüssels die Tatsache, daß er der ist, der er vorgibt zu sein, also die Echtheit diverser in den öffentlichen Schlüssel eingebettete Daten, z.B. Name und email-Adresse.

3.3.2 Certificate Authorities (CAs)

Übergeordnete Autoritäten (Firmen, Regierungen, Institutionen usw.) vergeben Zertifikate, d.h. sie signieren öffentliche Schlüssel mit Ihrem privaten, wenn Sie sich "persönlich" von der Zusammengehörigkeit des Schlüssels und des Inhabers überzeugt haben.
Benutzer von Pretty Good Privacy (PGP) indes können jederzeit selber als CA fungieren und andere Schlüssel signieren. Dadurch baut sich ein ganzes Vertrauens- und Zertifizierungsnetzwerk auf.

4. XML Signature

4.1 Übersicht

XML Digital Signature ist eine W3C-Recommendation seit dem 12. Februar 2002. Der Standard beschreibt sowohl die Signierung beliebiger Elemente eines XML-Dokumentes als auch beliebiger, möglicherweise binärer externer Daten. Dabei müssen alle Elemente und Objekte per URI referenziert werden können. Alle relevanten Signaturdaten (Referenzen, Hashwert, Algorithmus, usw.) werden in das XML-Dokument eingebettet.

4.2 Einbettung

4.3 Besondere Methoden

4.4 Beispiel

<?xml version="1.0"?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

    <SOAP-ENV:Header>

        <ds:Signature>
             <ds:SignedInfo>

                  <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                  <ds:Reference URI="#GetSpecialDiscountedBookingForPartners">
                      <ds:Transforms>
                          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                          <!-- Weitere Transforms -->

                      </ds:Transforms>
                      <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                      <ds:DigestValue>
                          BIUddkjKKo2...
                      </ds:DigestValue>
                  </ds:Reference>
                  <!-- Weitere References -->

             </ds:SignedInfo>

             <ds:SignatureValue>
                 halHJghyf765....
             </ds:SignatureValue>

             <ds:KeyInfo>
                 <ds:KeyName>MyKeyIdentifier</ds:KeyName>

             </ds:KeyInfo>
        </ds:Signature>

        <!-- Weitere SOAP Header-Daten -->
    </SOAP-ENV:Header>

    <SOAP-ENV:Body>

        <s:GetSpecialDiscountedBookingForPartners
            xmlns:s="http://www.MyHotel.com/partnerservice/"
            ID="GetSpecialDiscountedBookingForPartners">
                 <!-- Methoden-Parameter -->
         </s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

4.5 Vorgehensweisen

4.5.1 Signierung

  1. Referenz(en) auf zu signierende Objekte erzeugen
    - Transformation auf Datenobjekt anwenden (optional)
    - Hashwert berechnen
    - <Reference>-Element erzeugen
  2. Signatur erzeugen
    - <SignedInfo>-Element erzeugen mit
          - <SignatureMethod>
          - <CanonicalizationMethod>
          - <Reference>*
    - <SignedInfo> normalisieren, Hashwert berechnen, als <Signature> speichern
    - Schlüssel-Informationen hinzufügen (optional)
    - Alles in ein <Signature>-Element einbetten

4.5.2 Validierung

  1. <SignedInfo>-Element normalisieren
  2. Integrität der Nachricht checken
    - Referenzen auflösen
    - Transformation(en) anwenden
    - Daten hashen
    - Berechnete Hashwerte mit übermittelten Hashwerten vergleichen
  3. Signatur verifizieren
    - <SignedInfo>-Element hashen
    - Übermittelten verschlüsselten Hashwert (Signatur) entschlüsseln
    - Beide Hashwerte miteinander vergleichen

Online-Validierer

5. XML Encryption

5.1 Übersicht

XML Encryption ist eine W3C-Recommendation seit Dezember 2002. Der Standard beschreibt analog zu XML Signature die Verschlüsselung von beliebigen Elementen eines XML-Dokumentes. Es können jedoch auch alle per URI referenzierbaren externen Objekte verschlüsselt werden, z.B. Bilder. Aufgrund der Konstruktion ist auch die Verschlüsselung bereits verschlüsselter Daten möglich (superencryption). Die Verwendung von XML Encryption ist wie XML Signature nicht auf SOAP-Dokumente beschränkt sondern kann in beliebigen XML-Dokumenten verwendet werden!
Ebenfalls analog zu XML Signature werden alle relevanten Daten (Hashwert, Algorithmen, Schlüssel, usw.) in das XML-Dokument eingebettet. Es können entweder das gesamte Dokument verschlüsselt werden, einzelne Elemente oder nur Elementinhalte.

5.2 Struktur

Die drei wichtigsten Elemente <EncryptionMethod>, <KeyInfo> und <CipherData> enthalten alle relevanten Angaben, die zum erfolgreichen Entschlüsseln der verschlüsselten Daten notwendig sind. <KeyInfo> beschreibt den zur Entschlüsselung benutzten Schlüssel, wie dieser zu beziehen ist usw. <CipherDate> beinhaltet die eigentlichen verschlüsselten Daten.
  
<EncryptedData Id? Type? MimeType? Encoding?>
    <EncryptionMethod>?
    <ds:KeyInfo>
        <EncryptedKey>?
        <AgreementMethod>?
        <ds:KeyName>?
        <ds:RetrievalMethod>?
        <ds:*>?
    </ds:KeyInfo>?
    <CipherData>
        <CipherValue>?
        <CipherReference URI?>?
    </CipherData>
    <EncryptionProperties>?
</EncryptedData>

5.3 Verschlüsselungsarten

Das Element <EncryptedData> ersetzt jeweils den zu verschlüsselnden Abschnitt im Dokument, egal ob es sich um Inhalte von Elementen oder um das komplette root-Element, respektive das gesamte Dokument handelt.

5.3.1 Elementinhalte

<?xml version="1.0"?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
            xmlns:s="http://www.MyHotel.com/partnerservice/"
            ID="GetSpecialDiscountedBookingForPartners">

            <xenc:EncryptedData
                 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                 Type="http://www.w3.org/2001/04/xmlenc#Content">
                 <xenc:EncryptionMethod
                     Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

                 <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                     <ds:KeyName>MyKeyIdentifier</ds:KeyName>
                 </ds:KeyInfo>
                 <xenc:CipherData>
                       <xenc:CipherValue>B457V645B45........</xenc:CipherValue>

                </xenc:CipherData>
            </xenc:EncryptedData>

         </s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

5.3.2 Einzelne Elemente

<?xml version="1.0"?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Body>

        <xenc:EncryptedData
             xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
             Type="http://www.w3.org/2001/04/xmlenc#Element">
             <xenc:EncryptionMethod
                 Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
             <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

                 <ds:KeyName>MyKeyIdentifier</ds:KeyName>
             </ds:KeyInfo>
             <xenc:CipherData>
                   <xenc:CipherValue>B457V645B45........</xenc:CipherValue>
             </xenc:CipherData>

        </xenc:EncryptedData>

    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

5.3.3 Komplettes Dokument

<?xml version='1.0'?>
<EncryptedData
    xmlns="http://www.w3.org/2001/04/xmlenc#"
    MimeType="text/xml">
    <EncryptionMethod
        Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:KeyName>MyKeyIdentifier</ds:KeyName>
    </ds:KeyInfo>

    <CipherData>
      <CipherValue>B457V645B45........</CipherValue>
    </CipherData>
</EncryptedData>

6. Web Services Security Language

6.1 Entwicklung und Eigenschaften

Die Web Services Security Language (WS-Security, WSS) setzt auf XML Signature und XML Encryption auf und konzentriert sich auf die Anwendung von Sicherheitsstandards im Bereich Webservices. WSS ist demzufolge speziell für den Einsatz in SOAP-Umgebungen konzipiert. Bereits 1999 veröffentlichten Microsoft und IBM in Zusammenarbeit mit VeriSign die ersten einzelnen Stücke zu einem Framework, das Microsoft Global XML Architecture (GXA) taufte und in dessen Kontext zwischenzeitlich bereits mehrere Drafts veröffentlicht wurden. Die Webservice Security Language bildet zusammen mit Webservice Trust Language und der Webservice SecurityPolicy Language die Säulen dieser Architektur und ist potent genug, auch komplexeren Anforderungen an eine moderne Sicherheitsstruktur für webbasierte Dienste zu erfüllen. Die Aufgabe der Entwicklung zu einem tatsächlichen Standard wurde mittlerweile an OASIS übergeben.
SOAP und WSS
WSS läßt analog zu XML Encryption viele Freiräume bei der Verwendung von Algorithmen, Schlüsseltypen und ähnlichem. Sicherheitstoken können beliebige Schlüssel, Passwort/Benutzername, vorzugsweise aber X.509 Zertifikate sein. Der Vorschlag hält sich in den meisten Fällen eng an die Standards XML Encryption und Security, definiert aber einige Einschränkungen und Erweiterungen, die der Interoperabilität zugute kommen.

Für einen tieferen Einstieg in diese Thematik verweise ich auf die entsprechenden Webseiten.

6.2 Beispiel

<?xml version="1.0" encoding="utf-8"?>
<SOAP:Envelope
    xmlns:SOAP="http://www.w3.org/2001/12/soap-envelope"
    xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/xx/secext"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <SOAP:Header>
        
        <wsse:Security>
            <wsse:BinarySecurityToken
                ValueType="wsse:X509v3"
                EncodingType="wsse:Base64Binary"
                wsu:Id="MyTourOperatorCertificate">
                   LKSAJDFLKASJDlkjlkj243kj;lkjLKJ...
            </wsse:BinarySecurityToken>

            <ds:Signature>
                <ds:SignedInfo>
                    <ds:CanonicalizationMethod 
                        Algorithm="http://www.w3.org/2001/10/xml -exc-c14n# "/>
                    <ds:SignatureMethod
                        Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                    <ds:Reference URI="#myDiscountRequestBody">
                        <ds:Transforms>
                            <ds:Transform
                                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                        </ds:Transforms>
                        <ds:DigestMethod
                            Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                        <ds:DigestValue>BSDFHJYK21f...</ds:DigestValue>
                    </ds:Reference>

                </ds:SignedInfo>
                <ds:SignatureValue>
                    GKLKAJFLASKJ52kjKJKLJ345KKKJ...
                </ds:SignatureValue>
                <ds:KeyInfo>
                    <wsse:SecurityTokenReference>
                        <wsse:Reference URI="#MyTourOperatorCertificate"/>
                    </wsse:SecurityTokenReference>
                </ds:KeyInfo>
            </ds:Signature>
        </wsse:Security>
        
    </SOAP:Header>

    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
            xmlns:s="http://www.MyHotel.com/partnerservice/"
            ID="myDiscountRequestBody">
                 <!--Parameters passed with the method call-->
         </s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

7. Referenzen

(C) 2003 Alexander Haupt (haupt/at\informatik.hu-berlin.de)