Management und Wissen

Extensible Markup Language

Sicherheitsrelevante XML-Anwendungen und -Erweiterungen

Von Hans Ydema, München

Die Extensible Markup Language (XML) erfasst Daten und Datenstruktur in einem Textdokument und erleichtert damit den Datenaustausch in heterogenen Umgebungen. Eine ganze Reihe von Aktivitäten und Erweiterungen zielt auf Sicherheitsanwendungen im E-Business und in Public Key Infrastructures (PKIs).

XML vereinfacht den Austausch von Daten zwischen Applikationen und über das Internet, wovon eine zunehmende Zahl von Unternehmen profitiert. Der vertrauliche Charakter digitaler Transaktionen und die potenziell schwerwiegenden Folgen einer abgefangenen oder gefälschten Nachricht erfordern gleichzeitig ein hohes Maß an Sicherheit. Eine Möglichkeit, diese zu gewährleisten, besteht darin, direkt die XML-Nachrichten zu sichern, aus deren Austausch eine Transaktion besteht. Wenn man die Vertraulichkeit, Integrität, Authentizität und Verbindlichkeit der zugrunde liegenden XML-Nachricht garantiert, können sich die beteiligten Parteien darauf verlassen, dass die per XML übertragene Online-Transaktion selbst ebenfalls sicher ist.

Um die vier Grundforderungen an sichere geschäftliche Transaktionen zu erfüllen, setzt man heute in der Regel digitale Zertifikate ein, um die ausgetauschten Daten zu verschlüsseln und digital zu signieren. Eine Public Key Infrastructure (PKI) sorgt dabei für die Ausgabe, die Pflege und den Widerruf der Zertifikate sowie der öffentlichen und geheimen Schlüssel. In der Praxis steht PKI für ein System von digitalen Zertifikaten, Zertifizierungs- und Registrierungsstellen, die die Gültigkeit der an einer elektronischen Transaktion beteiligten Parteien prüfen und bestätigen.

XML steht unter anderem für semantisch aufbereitete, strukturierte Daten, ist textbasiert und für die Anwendung im WWW entworfen (vgl. Kasten). Genau diese Eigenschaften, die XML für geschäftliche Transaktionen prädestinieren, stellen auch Herausforderungen in Sachen Verschlüsselung und digitale Signatur bei XML-Anwendungen dar. Ein Beispiel: Verschiedene Anwender tauschen XML-Daten aus, während ein XML-Transaktions-Dokument entsteht. Digitale Signaturen drücken dabei bestimmte Verpflichtungen oder Bestätigungen aus. Jeder einzelne Teilnehmer an diesem Prozess möchte dabei eigentlich nur denjenigen Teil des Dokuments signieren, für den er auch direkt verantwortlich ist. Standards für digitale Signaturen bieten üblicherweise weder die Syntax für eine solch spezielle Signatur noch enthalten sie Mechanismen, mit denen ausgedrückt werden kann, welchen Teil eines Dokuments eine bestimmte Person signieren möchte.

Zur Signatur und Verschlüsselung von Daten in XML-Dokumenten dienen zwei neue Verfahren: XML Signature [1] und XML Encryption [2]. Sie durchlaufen zurzeit den Standardisierungsprozess im Rahmen des World Wide Web Consortium (W3C). Beide Verfahren stellen ein XML-Schema (einen Satz von Markup-Tags) bereit, mit dem das Ergebnis einer digitalen Signatur oder der Verschlüsselung beliebiger Daten (in der Regel jedoch XML) erfasst wird.

XML Signature

Ein zentrales Merkmal von XML Signature ist die Möglichkeit, anstelle des gesamten XML-Dokuments nur Teile desselben zu signieren. Diese Flexibilität ist beispielsweise auch wichtig, um die Integrität bestimmter Elemente eines XML-Dokuments zu sichern, während andere Teile veränderlich bleiben: zum Beispiel in einem signierten XML-Formular, das an einen Benutzer geschickt wird, der es ausfüllen soll. Gälte die (Urheber-)Signatur für das gesamte XML-Formular, würde jede Eintragung sie ungültig machen.

Für die Platzierung der XML-Signatur gibt es grundsätzlich drei Möglichkeiten:

• 

• Die Signatur kann eingebettet sein (enveloped): Das XML-Fragment, das die Signatur darstellt, wird in die signierte Quell-XML eingefügt.
• Die Signatur kann als Umschlag fungieren (enveloping), der die Quell-XML umschließt.
• Die Signatur kann unabhängig vorliegen (external): Sie wird separat von der Quelle aufbewahrt, entweder in demselben oder in einem anderen XML-Dokument.

Listing 1 ist ein Beispiel für eine getrennt aufbewahrte externe XML-Signatur. Sie wird gemäß dem URI-Attribut des <Reference>-Elements für eine Webseite berechnet. Die Signaturdaten selbst sind im Element <SignatureValue> gespeichert.

<?xml version="1.0"?>
<Signature Id="MyFirstSignature" xmlns=http://www.w3.org/2000/09/xmldsig#>
    <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
        <Reference URI="http://www.entrust.com/index.html">
            <Transforms>
                <Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
        </Reference>
    </SignedInfo>
    <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
</Signature>

Bei Eingang der Signatur wird diese nach dem üblichen Ablauf für DSA-Signaturen geprüft:

• Digest-Berechnung des Elements <SignedInfo>,
• Einsatz des öffentlichen Verifizierungsschlüssels zur Kodierung des Hash-Werts und
• Prüfen, ob das Element <SignatureValue> denselben Wert hat wie der verschlüsselte Hash-Wert.

Die Tatsache, dass XML-Dokumente häufig nicht für sich allein stehen, macht die Signatur von XML-Dateien noch komplizierter: XML-Dokumente können auf XML-Schemata, auf Document Type Definitions (DTDs), externe Entities und Stylesheets zurückgreifen. Der Inhalt solcher ergänzender Dateien kann sich auf den Inhalt und die Präsentation der XML-Dokumente auswirken und möglicherweise dieselben Sicherheitsvorkehrungen erfordern wie die XML-Dateien selbst. Zum Beispiel: Ein externes XSL-Stylesheet legt fest, wie Daten innerhalb des XML-Dokuments <stockPurchaseConfirm> einem Benutzer zur Online-Bestätigung vorgelegt werden. Die Anzeige des Elements <commissionCharged> (anfallende Provision) in einer 24-Punkt-Schrift kann nützlich sein, um eventuellen Einwänden entgegenzutreten, die Gebühren seien im Kleingedruckten untergegangen. Wenn nun das Stylesheet selbst signiert und vielleicht auch beglaubigt wurde, könnte man den Einwand eines Kunden, die Schrift sei zu klein gewesen, gut widerlegen.

XML Encryption

Bei der Übertragung eines XML-Dokuments über das Internet sichern Protokolle wie SSL (TLS), S/MIME oder PKCS entweder den Übertragungsweg oder das gesamte XML-Dokument, um die Vertraulichkeit der XML-Nachricht zu schützen. Es gibt jedoch auch Szenarien, in denen nur bestimmte Teile eines XML-Dokuments verschlüsselt werden müssen oder sollen – wenn etwa bestimmte Daten geheim bleiben müssen, während nichtvertrauliche Daten zu bearbeiten sein sollen. Nehmen wir als Beispiel eine Personalakte. Um sicherzugehen, dass nur autorisierte Mitarbeiter das Element <salary> (Gehalt) sehen können, wurde dessen Inhalt verschlüsselt und durch das Element <EncryptedData> ersetzt. Da die übrigen Informationen im Klartext vorliegen, lassen sie sich jedoch ohne weiteres verarbeiten, beispielsweise um festzustellen, wie viele Mitarbeiter den Titel "Senior Analyst" tragen.

<?xml version="1.0"?>
<employee id="b3456">
    <name>John Smith</name>
    <title>Senior Analyst</title>
    <salary>
        <xenc:EncryptedData xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc' Type="NodeList">
            <xenc:CipherText>AbCd....wXYZ</xenc:CipherText>
        </xenc:EncryptedData>
    </salary>
</employee>

Ein XML-Schema legt fest, welche Datenstrukturen in einer XML-Nachricht zulässig sind, wie diese Strukturen miteinander in Beziehung stehen und es liefert Informationen über deren Typ. Die Verschlüsselung von Daten in einem XML-Dokument hat durch die Verschleierung der Inhalte ernsthafte Auswirkungen auf die Gültigkeit in Bezug auf das zugrunde liegende Schema. Bei XML-Signaturen ist das übrigens kein Problem. Obwohl die Signatur zwar potenziell die zugrunde liegende XML-Struktur verändert, sorgt der dabei eingesetzte XML-Namespace-Mechanismus [15] dafür, dass die Tags der XML-Signatur nicht mit den Tags der XML-Quell-Datei in Konflikt geraten.

Um beim Beispiel einer Personalakte zu bleiben: Wenn das Schema für die Personalakte festlegt, dass das Element <salary> zwingend vorhanden sein muss, so wird die verschlüsselte Akte ungültig, wenn dieses Element durch <EncryptedData> ersetzt wird. Wenn man – wie im Beispiel-Listing – nur den Inhalt des Elements und nicht die Start- und End-Tags verschlüsselt, dann vermeidet man zwar strukturelle Gültigkeitsfehler. Gegen eine im Schema vorgenommene Festlegung eines Datentyps würde man damit aber immer noch verstoßen, weil beispielsweise das Element <salary> keine Daten des Typs "Währung" mehr enthält.

SOAP

Das Simple Object Access Protocol (SOAP) ist ein einfaches Protokoll für die Übertragung von XML-Dokumenten in einer verteilten Rechnerumgebung. SOAP besteht aus drei Elementen: einem Umschlag für XML-Nachrichten, einem Satz von Kodierungsregeln, der Instanzen von anwendungsspezifischen Datentypen beschreibt, sowie einer Konvention für die Darstellung von Remote Procedure Calls (RPCs) und Antworten darauf. Der SOAP-Umschlag besteht aus zwei Teilen: Header und Body. Der Header ist ein allgemeiner Mechanismus für Erweiterungen einer SOAP-Nachricht. Der Body ist ein Behälter für die XML-Anwendungsdaten und entspricht der eigentlichen geschäftlichen Nachricht.

SOAP selbst enthält keine Sicherheitsfunktionen, sondern greift zum Zwecke der Authentifizierung und zur Sicherung der Integrität und Vertraulichkeit der Daten auf Sicherheitselemente der Transportschicht zurück (z. B. SSL). Will man eine durchgängige End-to-End-Sicherheit, so ist das jedoch unbefriedigend. Das gilt beispielsweise für den Fall, dass ein XML-Dokument teilweise über HTTP und teilweise über SMTP übertragen wird. In einem solchen Szenario müssten Sicherheitsinformationen bei jedem Protokollwechsel von einem Transportweg auf den nächsten übertragen werden – während der Umsetzung von HTTP zu SMTP wären die Daten kurzzeitig im Klartext zugänglich.

Anstatt sich auf Mechanismen der Transportschicht zu verlassen, zielen neue Vorschläge daher darauf ab, die SOAP-Nachrichten selbst um Sicherheitselemente zu ergänzen [5]. Geschehen soll dies durch das Einfügen von XML-Signature- und XML-Encryption-Tags im Header der SOAP-Nachricht. Dadurch werden die Nachrichten unmittelbar geschützt, was sowohl eine durchgängige Sicherheit als auch das zwischenzeitliche Bearbeiten nicht geschützter Daten ermöglicht.

Listing 3 zeigt das Skelett einer SOAP-Nachricht für einen Aktienkurs-Service. Die Daten der Aktie wurden durch ein <EncryptedData>-Element ersetzt. Sämtliche weiteren Informationen, die man zur Entschlüsselung dieses chiffrierten Textes benötigt, befinden sich im SOAP-Header.

<?xml version="1.0"?>
<soap:Envelope>
    <soap:Header>
        <Encryption>
            <KeyInfo>.....</KeyInfo>
        </Encryption> 
    </soap:Header>
    <soap:Body>
        <StockQuote>
            <EncryptedData>k%$#989hskdf&</EncryptedData>
        </StockQuote>
    </soap:Body>
</soap:Envelope>

Trust Services

XML ist auch eine Schlüsseltechnologie in der neuen Web-Services-Architektur, die von IBM, Oracle und Microsoft unterstützt wird. Web-Services sind eigenständige und modulare Anwendungen, die durch XML-Nachrichten über das Internet beschrieben, publiziert, lokalisiert und aufgerufen werden können. Durch ihren losen Zusammenhang sowie dynamisches Aufspüren und Einbinden externer Funktionen in Echtzeit befreien Web-Services Anwendungen von der Komplexität und den Details anderer Komponenten und schaffen so flexiblere und anpassungsfähigere Systeme.

Dieses Konzept ist besonders für die Bereiche PKI und Sicherheit von Bedeutung. Schließlich verwenden Programmierer ihre Zeit lieber für die Entwicklung von Anwendungen als mit dem Erlernen kryptografischer Feinheiten, um Sicherheitsfunktionen in ihre Anwendungen zu integrieren. Ein Trust-Service ist ein Web-Service, der sicherheitsrelevante Funktionen für andere Anwendungen bereitstellt, die die Angebote des Trust-Service mithilfe von XML-Nachrichten (wahrscheinlich auf Basis von SOAP) abrufen.

Neben dem Wunsch nach mehr Interoperabilität zwischen den Lösungen verschiedener PKI-Anbieter ist es vor allem dieses Trust-Service-Konzept, das die Integration von XML innerhalb der PKI- und Sicherheitsinfrastruktur so attraktiv macht. Hierbei sind zwei Initiativen besonders erwähnenswert: XML Key Management Specification (XKMS) und Security Assertions Markup Language (SAML).

XKMS

XKMS ist ein vorgeschlagener Standard für den Umgang mit zertifizierten Schlüsseln [7]. Anstatt komplizierte Funktionen für die Verwaltung von PKI-Schlüsseln über Toolkits oder APIs in Anwendungen zu integrieren, ermöglicht XKMS die Ausgliederung dieser PKI-Funktionen in externe Services. Der Anwendungsentwickler muss dann nur noch wissen, wie er die betreffenden XML-Nachrichten zu erstellen beziehungsweise zu bearbeiten hat, mit denen die ausgelagerten Funktionen aufgerufen werden. Listing 4 zeigt ein Beispiel für eine XKMS-Anfrage, die den durch das <KeyID>-Element spezifizierten Schlüssel widerruft.

<? xml version="1.0"?>
<Request>
    <Prototype>
        <AssertionStatus>Invalid</AssertionStatus>
        <KeyID>unique_key_identifier</KeyID>
        <ds:KeyInfo> ... </ds:KeyInfo>
    </Prototype>
    <AuthInfo>
        <AuthUserInfo>
            <ProofOfPossession>[RSA-Sign]</ProofOfPossession>
        </AuthUserInfo>
    </AuthInfo>
    <Respond>
        <string>KeyName</string>
    </Respond>
</Request>

SAML

SAML [8] ist eine Initiative der Organization for the Advancement of Structured Information Standards (OASIS). Ihr Ziel ist eine standardisierte Definition von Benutzerauthentifizierungen, Autorisierungen, Berechtigungen und Profilinformationen in XML-Dokumenten.

Sowohl im B2B- als auch im B2C-Sektor kann sich eine einzelne Transaktion heute über mehrere Unternehmen, Websites und Handelsplätze erstrecken, die jeweils mit eigenen Authentifizierungs- und Autorisierungsverfahren arbeiten. Unternehmen benötigen daher ein offenes, standardisiertes System, mit dem sie Vertrauensketten über Firmengrenzen, heterogene Plattformen und Lösungen verschiedener Anbieter hinweg aufbauen können, sodass der Endbenutzer bei seinen Transaktionen eine nahtlose Umgebung vorfindet.

Ein Beispiel hierfür könnte eine Single-Sign-On-Anwendung (SSO) sein, bei der sich ein Benutzer an einer Website anmelden muss und sich alsdann ohne weitere Authentifizierung zu anderen geschützten Websites innerhalb eines Handelsverbunds "durchklicken" kann, da im Hintergrund – für den Anwender unsichtbar – die entsprechenden Zugangsinformationen weitergereicht werden.

Fazit

Die Zukunft des E-Business ist ein verteiltes Netzwerk miteinander verbundener Unternehmen, die dynamisch untereinander agieren, Informationen austauschen und Geschäfte tätigen. Die Möglichkeit, mit Firmen auf gesicherter Basis zu verkehren, die man bisher vielleicht nicht einmal kannte, ist wegen der potenziellen Kosteneinsparungen und der gewonnenen Flexibilität durchaus reizvoll. Allerdings muss dabei sichergestellt sein, dass die beteiligten Partner die Botschaften des jeweils anderen richtig verstehen und dass die Mitteilungen selbst auch vertrauenswürdig sind. XML und PKI erfüllen gemeinsam genau diese Anforderungen und bilden somit zwei Eckpfeiler einer derartigen zukünftigen E-Business-Plattform.

Hans Ydema ist Geschäftsführer von  Entrust Deutschland.

© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 3/2001, Seite 20

Zurück zum Inhalt