Ich kann eine manuelle Referenzvalidierung erfolgreich durchführen (jedes referenzierte Element kanonisieren - & gt; SHA1 - & gt; Base64 - & gt; überprüfen, ob es der gleiche DigestValue-Inhalt ist), aber ich versage mit der Überprüfung des SignatureValue. Hier ist die SignedInfo zum Kanonisieren und Hash:
%Vor%Nachdem ich alle Leerzeichen zwischen den Tags entfernt habe (und damit das ganze Element in eine einzige Zeile gebracht habe), erhalte ich diesen sha1-Digest (in Base64):
6l26iBH7il / yrCQW6eEfv / VqAVo =
Nun erwarte ich nach der Entschlüsselung des SignatureValue-Inhalts denselben Digest zu finden, aber ich erhalte einen anderen und längeren Wert:
MCEwCQYFKW4DAhoFAAQU3M24VwKG02yUu6jEH + u6R4N8Ig =
Hier ist ein Java-Code für die Entschlüsselung:
%Vor%Die Sache, die mich sehr verwirrt, ist, dass die zwei Digests unterschiedliche Größe haben, aber natürlich muss ich auch genau den gleichen Wert von den zwei Berechnungen erhalten. Irgendwelche Vorschläge? Danke.
MCEwCQYFKw4DAhoFAAQU3M24VwKG02yUu6jlEH+u6R4N8Ig= ist die Base64-Kodierung für eine DER-kodierte ASN.1-Struktur: a SEQUENCE enthält zuerst eine AlgorithmIdentifier (die besagt, dass dies SHA-1 ist, ohne Parameter, da SHA-1 keine akzeptiert). dann ein OCTET STRING , das den tatsächlichen 20-Byte-Wert enthält. Im Hexadezimalformat lautet der Wert: dccdb8570286d36c94bba8e5107faee91e0df088 .
Diese ASN.1-Struktur ist Teil des Standard RSA-Signatur -Mechanismus. Sie verwenden RSA Entschlüsselung , um auf diese nicht standardmäßige Struktur zuzugreifen. Sie sind wirklich glücklich, überhaupt etwas zu bekommen, da RSA-Verschlüsselung und RSA-Signatur zwei verschiedene Algorithmen sind. Es kommt vor, dass beide von der gleichen Art von Schlüsselpaaren leben und dass die "alten" (aka "PKCS # 1 v1.5") Signatur- und Verschlüsselungsschemata ähnliche Padding-Techniken verwenden (ähnlich aber nicht identisch; es ist schon ein wenig überraschend, dass die Java-Implementierung von RSA im Entschlüsselungsmodus den Signatur-Padding nicht erstickt hat).
Wie auch immer, 6l26iBH7il/yrCQW6eEfv/VqAVo= ist die Base64-Kodierung für einen 20-Byte-Wert, der in hexadezimaler Schreibweise lautet: ea5dba8811fb8a5ff2ac2416e9e11fbff56a015a . Dies erhalten Sie, indem Sie die oben gezeigte XML-Struktur hashen, nachdem Sie alle Leerzeichen zwischen den Tags entfernt haben. Das Entfernen aller Leerzeichen ist nicht korrekte Kanonisierung. Soweit ich weiß, wird Whitespace nur zwischen Attributen innerhalb der Tags beeinflusst, aber externe Whitespaces müssen unverändert bleiben (außer für die Zeilenende-Normalisierung [das LF / CR + LF-Ding]).
Der Wert, der für die Signaturgenerierung verwendet wurde ( dccdb85... ), kann durch Verwendung des von Ihnen angezeigten XML-Objekts und durch Entfernen der führenden Leerzeichen ermittelt werden. Um es klar zu sagen: Sie kopieren + fügen das XML in eine Datei ein und entfernen dann die führenden Leerzeichen (0 bis 3 Leerzeichen) in jeder Zeile. Sie stellen sicher, dass alle Zeilenenden ein einzelnes LF (0x0A Byte) verwenden und Sie das letzte LF entfernen (das direkt nach </ds:SignedInfo> ). Die resultierende Datei muss eine Länge von 930 Byte haben, und ihr SHA-1-Hash ist der erwartete dccdb85... -Wert.
Wenn Sie Ihr bestimmtes XML-Token betrachten, kann ich Ihnen ein paar Dinge sagen.
Sie verwenden die Canonicalization-Methode Exklusives XML Canonicalization Version 1.0 . Dies ist ein sehr WICHTIGER Faktor um sicherzustellen, dass Sie die richtigen Digest-Werte und die Signatur erstellen.
Sie verwenden die gleiche Canonicalization-Methode sowohl für die Berechnung der Referenzauszüge als auch für die Kanonisierung der SignedInfo vor dem Erstellen der Signatur.
Die Spezifikation für Exclusive XML Canonicalizaiton Version 1.0 wird von W3C erstellt und ist in der jeweiligen W3C-Empfehlung
Ich habe gerade einen ausführlichen Artikel geschrieben, in dem der Validierungsprozess der XML-Signatur beschrieben wird. Der Artikel befindet sich unter mein Blog . Es beschreibt den Prozess viel detaillierter als meine Antwort, da die XML-Signatur viele Feinheiten aufweist. Es enthält auch Links zu gängigen Spezifikationen und RFCs.
Tags und Links java soap web-services cryptography xml-signature