Digitale XML-Signatur
Die Spezifikation "XML-Signature Syntax and Processing (XML Signature)" definiert XML-Syntax- und -Verarbeitungsregeln, mit denen digitale Signaturen für digitale Inhalte erstellt und überprüft werden können. Die Spezifikation wurde vom World Wide Web Consortium (W3C) und der Internet Engineering Task Force (IETF) gemeinsam entwickelt.
XML Signature führt keine neuen Verschlüsselungsalgorithmen ein. WebSphere Application Server verwendet XML Signature mit vorhandenen Algorithmen, wie z. B. RSA, HMAC und SHA1. XML Signature definiert viele Methoden zur Beschreibung von Schlüsselinformationen und ermöglicht die Definition einer neuen Methode.
- <person first="John" last="Smith"/>
- <person last="Smith" first="John"></person>
C14N ist ein Prozess, mit dem XML-Informationen kanonisiert werden können. Wählen Sie einen geeigneten C14N-Algorithmus aus, da die zu kanonisierenden Informationen von diesem Algorithmus abhängig sind. Einer der wichtigsten C14N-Algorithmen, Exclusive XML Canonicalization, kanonisiert das Codierungsschema für Zeichen, die Attributreihenfolge, Namespace-Deklarationen usw. Der Algorithmus kanonisiert keine Leerzeichen außerhalb von Tags, Namespace-Präfixen oder Darstellungen von Datentypen.
XML Signature in der Spezifikation Web Services Security-Core
Die Spezifikation Web Services Security-Core (WSS-Core) definiert eine Standardmethode, mit der SOAP-Nachrichten (Simple Object Access Protocol) eine XML-Signatur einbinden. Sie können fast alle XML-Signatur-Features in WSS-Core verwenden, mit Ausnahme von Enveloped Signature und Enveloping Signature. WSS-Core enthält einige Empfehlungen, z. B. die exklusive Kanonisierung für den C14N-Algorithmus, und einige zusätzliche Features, z. B. SecurityTokenReference and KeyIdentifier. Der KeyIdentifier ist der Wert des Feldes SubjectKeyIdentifier im X.509-Zertifikat. Nähere Informationen zu KeyIdentifier finden Sie unter "Reference to a Subject Key Identifier" in der Dokumentation OASIS Web Services Security X.509 Certificate Token Profile.
- Nachrichtenintegrität
- Ein Nachrichtenempfänger kann bestätigen, dass Abschnitte der Nachricht, nachdem diese durch einen Schlüssel signiert wurden, nicht durch Angreifer oder versehentlich geändert wurden.
- Authentifizierung
- Sie können davon ausgehen, dass eine gültige Signatur ein Eigentumsnachweis ist. Eine Nachricht mit einem digitalen Zertifikat, das von einer Zertifizierungsstelle ausgestellt wurde, sowie eine Signatur in der Nachricht, die von einem öffentlichen Schlüssel im Zertifikat validiert wurde, beweisen, dass der Aussteller den entsprechenden privaten Schlüssel besitzt. Der Empfänger kann den Aussteller authentifizieren, indem er die Vertrauenswürdigkeit des Zertifikats überprüft.
XML Signature in der aktuellen Spezifikation
XML Signature wird in Web Services Security unterstützt, eine API (Application Programming Interface) ist jedoch nicht verfügbar. Die aktuelle Implementierung hat viele fest codierte Abläufe und einige Konfigurationselemente, die von Benutzern bedient werden können. Lesen Sie den Abschnitt "Client für Überprüfung der digitalen Signatur von Antworten konfigurieren: Nachrichtenabschnitte überprüfen", bevor Sie den Client für die digitale Signatur konfigurieren. Lesen Sie den Abschnitt "Server für Überprüfung der digitalen Signatur von Anforderungen konfigurieren: Nachrichtenabschnitte überprüfen", bevor Sie den Server für die digitale Signatur konfigurieren.
Sicherheitsaspekte:
Bei einem Angriff durch Nachrichtenaufzeichnung und -wiederholung greift der Angreifer auf die Zeilen zu, empfängt eine signierte Nachricht und gibt die Nachricht dann an den Empfänger zurück. In diesem Fall empfängt der Empfänger dieselbe Nachricht zweimal und kann beide verarbeiten, vorausgesetzt, die Signaturen sind gültig. Die Verarbeitung beider Nachrichten kann den Empfänger schädigen, wenn die Nachricht eine Geldforderung ist. Wenn Sie bei der Nachrichtenaufzeichnung und -wiederholung die signierte Generierungszeitmarke und die signierte Ablaufzeit verwenden, können Sie die Zahl der Angriffe reduzieren. Dies ist jedoch keine vollständige Lösung. Eine Nachricht muss einen Nonce-Wert haben, um diese Angriffe zu verhindern, und der Empfänger muss eine Nachricht, die einen verarbeiteten Nonce enthält, zurückweisen. Die aktuelle Implementierung bietet kein Standardverfahren zur Generierung und Überprüfung von Nonce-Werten in Nachrichten. Bei WebSphere Application Server Version 5.1 wird der Nonce nur in Benutzernamenstoken unterstützt. Das Profil von Benutzernamenstoken enthält konkrete Szenarien zur Verwendung des Nonce in Benutzernamenstoken. Anwendungen verarbeiten Nonces (wie z. B. Seriennummern), die signiert werden müssen.