Freigeben über

System.Security.Cryptography.Xml.SignedXml-Klasse

Dieser Artikel enthält ergänzende Hinweise zur Referenzdokumentation für diese API.

Die SignedXml Klasse ist die .NET-Implementierung des World Wide Web Consortium (W3C) XML Signature Syntax and Processing Specification, auch als XMLDSIG (XML Digital Signature) bezeichnet. XMLDSIG ist eine standardsbasierte, interoperable Methode zum Signieren und Überprüfen aller oder eines Teils eines XML-Dokuments oder anderer Daten, die von einem Uniform Resource Identifier (URI) adressierbar sind.

Verwenden Sie die SignedXml Klasse, wenn Sie signierte XML-Daten zwischen Anwendungen oder Organisationen standardmäßig freigeben müssen. Alle mit dieser Klasse signierten Daten können von jeder konformen Implementierung der W3C-Spezifikation für XMLDSIG überprüft werden.

Mit der SignedXml Klasse können Sie die folgenden drei Arten digitaler XML-Signaturen erstellen:

Signaturtyp BESCHREIBUNG
Umhüllte Signatur Die Signatur ist in dem XML-Element enthalten, das signiert wird.
Enveloping-Signatur Der signierte XML-Code ist im <Signature> Element enthalten.
Interne getrennte Signatur Die Signatur und der signierte XML-Code befinden sich im selben Dokument, aber keines der Elemente enthält das andere.

Es gibt auch eine vierte Art von Signatur, die als externe getrennte Signatur bezeichnet wird, wenn sich die Daten und Signatur in separaten XML-Dokumenten befinden. Externe getrennte Signaturen werden von der SignedXml Klasse nicht unterstützt.

Struktur einer XML-Signatur

XMLDSIG erstellt ein <Signature> Element, das eine digitale Signatur eines XML-Dokuments oder anderer Daten enthält, die von einem URI adressierbar sind. Das <Signature> Element kann optional Informationen darüber enthalten, wo ein Schlüssel gefunden werden soll, der die Signatur überprüft und welcher kryptografische Algorithmus für die Signatur verwendet wurde. Die Grundstruktur lautet wie folgt:

<Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <Reference URI="">
        <Transforms>
          <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <DigestValue>Base64EncodedValue==</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>AnotherBase64EncodedValue===</SignatureValue>
</Signature>

Die Hauptteile dieser Struktur sind:

  • Das <CanonicalizationMethod>-Element

    Gibt die Regeln zum Umschreiben des Signature Elements aus XML/Text in Bytes für die Signaturüberprüfung an. Der Standardwert in .NET lautet http://www.w3.org/TR/2001/REC-xml-c14n-20010315, der einen vertrauenswürdigen Algorithmus identifiziert. Dieses Element wird durch die SignedInfo.CanonicalizationMethod Eigenschaft dargestellt.

  • Das <SignatureMethod>-Element

    Gibt den Algorithmus an, der für die Signaturgenerierung und -validierung verwendet wird und auf das <Signature>-Element angewendet wurde, um den Wert in <SignatureValue> zu erzeugen. Im vorherigen Beispiel identifiziert der Wert http://www.w3.org/2000/09/xmldsig#rsa-sha1 eine RSA PKCS1 SHA-1-Signatur. Aufgrund von Kollisionsproblemen mit SHA-1 empfiehlt Microsoft ein Sicherheitsmodell, das auf SHA-256 oder höher basiert. Dieses Element wird durch die SignatureMethod Eigenschaft dargestellt.

  • Das <SignatureValue>-Element

    Gibt die kryptografische Signatur für das <Signature> Element an. Wenn diese Signatur nicht überprüft wird, wurde ein Teil des <Signature> Blocks manipuliert, und das Dokument wird als ungültig angesehen. Solange der <CanonicalizationMethod> Wert vertrauenswürdig ist, ist dieser Wert sehr resistent gegen Manipulationen. Dieses Element wird durch die SignatureValue Eigenschaft dargestellt.

  • Das URI Attribut des <Reference> Elements

    Gibt ein Datenobjekt mithilfe eines URI-Verweises an. Dieses Attribut wird durch die Reference.Uri Eigenschaft dargestellt.

    • Wenn Sie das URI-Attribut nicht angeben, das heißt, wenn Sie die Eigenschaft Reference.Uri auf null setzen, bedeutet dies, dass die empfangende Anwendung die Identität des Objekts kennen soll. In den meisten Fällen führt ein null URI zu einer Ausnahme, die ausgelöst wird. Verwenden Sie keinen null URI, es sei denn, Ihre Anwendung arbeitet mit einem Protokoll zusammen, das ihn erfordert.

    • Wenn Sie das URI Attribut auf eine leere Zeichenfolge festlegen, wird angegeben, dass das Stammelement des Dokuments signiert wird, eine Form der umschlagigen Signatur.

    • Wenn der Wert des Attributs URI mit #beginnt, muss der Wert in ein Element im aktuellen Dokument aufgelöst werden. Dieses Formular kann mit jedem der unterstützten Signaturtypen verwendet werden (Umhüllungssignatur, umschließende Signatur oder interne getrennte Signatur).

    • Alles andere gilt als getrennte externe Ressourcen-Signatur und wird von der SignedXml Klasse nicht unterstützt.

  • Das <Transforms>-Element

    Enthält eine sortierte Liste von <Transform>-Elementen, die beschreiben, wie der Unterzeichner das Datenobjekt abgerufen hat, das verarbeitet wurde. Ein Transformationsalgorithmus ähnelt der kanonischen Methode, aber anstatt das <Signature> Element neu zu schreiben, wird der vom URI Attribut des <Reference> Elements identifizierte Inhalt neu geschrieben. Das <Transforms> Element wird durch die TransformChain Klasse dargestellt.

    • Jeder Transformations-Algorithmus ist so definiert, dass er entweder XML (ein XPath-Knoten-Set) oder Bytes als Eingabe akzeptiert. Wenn sich das Format der aktuellen Daten von den Transformationseingabeanforderungen unterscheidet, werden Konvertierungsregeln angewendet.

    • Jeder Transformationsalgorithmus wird entweder als XML- oder Byte-Code als Ausgabe definiert.

    • Wenn die Ausgabe des letzten Transformationsalgorithmus nicht in Bytes definiert ist (oder keine Transformationen angegeben wurden), wird die Kanonisierungsmethode als implizite Transformation verwendet (auch wenn ein anderer Algorithmus im <CanonicalizationMethod> Element angegeben wurde).

    • Ein Wert http://www.w3.org/2000/09/xmldsig#enveloped-signature für den Transformationsalgorithmus codiert eine Regel, die als Entfernen des <Signature> Elements aus dem Dokument interpretiert wird. Andernfalls wird ein Prüfer einer eingehüllten Signatur das Dokument einschließlich der Signatur verarbeiten, aber der Unterzeichner hätte das Dokument überprüft, bevor die Signatur angewendet wurde, was zu unterschiedlichen Ergebnissen führt.

  • Das <DigestMethod>-Element

    Identifiziert die Digest- (kryptographischer Hash-) Methode, um auf den durch das Attribut URI des Elements <Reference> identifizierten transformierten Inhalt anzuwenden. Dies wird durch die Reference.DigestMethod Eigenschaft dargestellt.

Auswählen einer Kanonisierungsmethode

Sofern Sie nicht mit einer Spezifikation interagieren, die die Verwendung eines anderen Wertes vorschreibt, empfehlen wir Ihnen, die standardmäßige .NET Kanonisierungsmethode zu verwenden, d.h. den XML-C14N 1.0 Algorithmus, dessen Wert http://www.w3.org/TR/2001/REC-xml-c14n-20010315 ist. Der XML-C14N 1.0-Algorithmus muss von allen Implementierungen von XMLDSIG unterstützt werden, insbesondere da es sich um eine implizite endgültige Transformation handelt, die angewendet werden soll.

Es gibt Versionen von Kanonisierungsalgorithmen, die das Beibehalten von Kommentaren unterstützen. Kommentarerhaltende Kanonisierungsmethoden werden nicht empfohlen, da sie das Prinzip „signieren, was man sieht“ verletzen. Das heißt, die Kommentare in einem <Signature> Element ändern nicht die Verarbeitungslogik für die Ausführung der Signatur, sondern lediglich den Signaturwert. Wenn sie mit einem schwachen Signaturalgorithmus kombiniert werden, ermöglicht das Einfügen von Kommentaren einem Angreifer unnötigen Spielraum, um eine Hash-Kollision zu erzwingen, sodass ein manipuliertes Dokument legitim erscheint. In .NET Framework werden standardmäßig nur integrierte Kanonisierer unterstützt. Zur Unterstützung zusätzlicher oder angepasster Kanonisierer siehe die Eigenschaft SafeCanonicalizationMethods. Wenn das Dokument eine Kanonisierungsmethode verwendet, die nicht in der durch die SafeCanonicalizationMethods Eigenschaft dargestellten Sammlung enthalten ist, dann gibt die CheckSignature Methode false zurück.

Hinweis

Eine extrem defensive Anwendung kann alle Werte, von denen sie nicht erwartet, dass sie von Signierern verwendet werden, aus der SafeCanonicalizationMethods-Collection entfernen.

Sind die Referenzwerte vor Manipulationen geschützt?

Ja, die <Reference> Werte sind vor Manipulationen geschützt. .NET überprüft die <SignatureValue> Berechnung vor der Verarbeitung der <Reference> Werte und der zugehörigen Transformationen und wird frühzeitig abbrechen, um potenziell schädliche Anweisungen zu vermeiden.

Auswählen der zu signierenden Elemente

Es wird empfohlen, den Wert "" für das URI Attribut zu verwenden (oder die Uri Eigenschaft auf eine leere Zeichenfolge festzulegen), falls möglich. Dies bedeutet, dass das gesamte Dokument für die Digestberechnung berücksichtigt wird, was bedeutet, dass das gesamte Dokument vor Manipulationen geschützt ist.

Es ist sehr üblich, Werte in Form von Ankern wie #foo zu sehen URI , wobei auf ein Element verwiesen wird, dessen ID-Attribut "foo" lautet. Leider ist es einfach, dass dies manipuliert wird, da dies nur den Inhalt des Zielelements und nicht den Kontext enthält. Der Missbrauch dieser Unterscheidung ist als XML Signature Wrapping (XSW) bekannt.

Wenn Ihre Anwendung Kommentare als semantisch betrachtet (was bei XML nicht üblich ist), sollten Sie "#xpointer(/)" anstelle von "" und "#xpointer(id('foo')))" anstelle von "#foo" verwenden. Die #xpointer-Versionen werden so interpretiert, dass sie Kommentare einschließen, während die Kurznamenformen Kommentare ausschließen.

Wenn Sie Dokumente akzeptieren müssen, die nur teilweise geschützt sind, und Sie sicherstellen möchten, dass Sie denselben Inhalt lesen, den die Signatur geschützt hat, verwenden Sie die GetIdElement Methode.

Sicherheitsüberlegungen zum KeyInfo-Element

Die Daten im optionalen <KeyInfo> Element (d. h. in der KeyInfo Eigenschaft), die einen Schlüssel zum Überprüfen der Signatur enthält, sollten nicht als vertrauenswürdig angesehen werden.

Insbesondere wenn der KeyInfo-Wert einen nackten RSA-, DSA- oder ECDSA-öffentlichen Schlüssel darstellt, könnte das Dokument manipuliert worden sein, obwohl die CheckSignature-Methode meldet, dass die Signatur gültig ist. Dies kann passieren, da die Entität, die die Manipulation durchführt, nur einen neuen Schlüssel generieren und das manipulierte Dokument mit diesem neuen Schlüssel erneut signieren muss. Es sei denn, Ihre Anwendung überprüft, ob der öffentliche Schlüssel ein erwarteter Wert ist, sollte das Dokument so behandelt werden, als ob es manipuliert wurde. Dies erfordert, dass Ihre Anwendung den im Dokument eingebetteten öffentlichen Schlüssel untersucht und anhand einer Liste bekannter Werte für den Dokumentkontext überprüft. Wenn das Dokument beispielsweise verstanden werden könnte, dass es von einem bekannten Benutzer ausgestellt wird, überprüfen Sie den Schlüssel anhand einer Liste bekannter Schlüssel, die von diesem Benutzer verwendet werden.

Sie können den Schlüssel auch nach der Verarbeitung des Dokuments überprüfen, indem Sie die CheckSignatureReturningKey Methode verwenden, anstatt die CheckSignature Methode zu verwenden. Für die optimale Sicherheit sollten Sie den Schlüssel jedoch vorher überprüfen.

Alternativ können Sie die registrierten öffentlichen Schlüssel des Benutzers ausprobieren, anstatt den Inhalt des <KeyInfo> Elements zu lesen.

Sicherheitsüberlegungen zum X509Data-Element

Das optionale <X509Data> Element ist ein untergeordnetes Element des <KeyInfo> Elements und enthält mindestens ein X509-Zertifikat oder einen Bezeichner für X509-Zertifikate. Die Daten im <X509Data> Element sollten ebenfalls nicht inhärent vertrauenswürdig sein.

Bei der Überprüfung eines Dokuments mit dem eingebetteten <X509Data> Element überprüft .NET nur, dass die Daten in ein X509-Zertifikat aufgelöst werden, dessen öffentlicher Schlüssel erfolgreich zum Überprüfen der Dokumentsignatur verwendet werden kann. Im Gegensatz zum Aufruf der CheckSignature-Methode mit dem verifySignatureOnly-Parameter, der auf false festgelegt ist, wird keine Widerrufsprüfung durchgeführt, kein verkettetes Vertrauen geprüft und kein Ablaufdatum verifiziert. Selbst wenn Ihre Anwendung das Zertifikat selbst extrahiert und es an die CheckSignature-Methode übergibt, wobei der verifySignatureOnly-Parameter auf false festgelegt ist, reicht dies dennoch nicht aus, um die Manipulation von Dokumenten zu verhindern. Das Zertifikat muss noch dahingehend überprüft werden, ob es für das zu signierende Dokument geeignet ist.

Die Verwendung eines eingebetteten Signaturzertifikats kann nützliche Schlüsselrotationsstrategien bieten, egal ob im <X509Data> Abschnitt oder im Dokumentinhalt. Bei Verwendung dieses Ansatzes sollte eine Anwendung das Zertifikat manuell extrahieren und eine Überprüfung wie folgt durchführen:

  • Das Zertifikat wurde direkt oder über eine Kette von einer Zertifizierungsstelle ausgestellt, deren öffentliches Zertifikat in die Anwendung eingebettet ist.

    Die Verwendung der vom Betriebssystem bereitgestellten Vertrauensliste ohne zusätzliche Überprüfungen, wie etwa eines bekannten Subjektnamens, reicht nicht aus, um Manipulationen in SignedXml zu verhindern.

  • Das Zertifikat wird daraufhin überprüft, dass es zum Zeitpunkt der Signierung des Dokuments (oder „jetzt“, wenn das Dokument nahezu in Echtzeit verarbeitet wird) noch nicht abgelaufen ist.

  • Überprüfen Sie bei Zertifikaten mit langer Lebensdauer, die von einer Zertifizierungsstelle ausgestellt wurden, die den Widerruf unterstützt, ob das Zertifikat nicht widerrufen wurde.

  • Der Betreff des Zertifikats wird als geeignet für das aktuelle Dokument verifiziert.

Auswählen des Transformationsalgorithmus

Wenn Sie mit einer Spezifikation zusammenarbeiten, die bestimmte Werte (z. B. XrML) diktieren, müssen Sie die Spezifikation befolgen. Wenn Sie über eine eingebettete Signatur verfügen (z. B. beim Signieren des gesamten Dokuments), müssen Sie http://www.w3.org/2000/09/xmldsig#enveloped-signature verwenden (dargestellt durch die XmlDsigEnvelopedSignatureTransform Klasse). Sie können auch die implizite XML-C14N Transformation angeben, aber es ist nicht erforderlich. Für eine umschließende oder getrennte Signatur sind keine Transformationen erforderlich. Die implizite XML-C14N Transformation kümmert sich um alles.

Mit dem im Microsoft Security Bulletin MS16-035 eingeführten Sicherheitsupdate hat .NET die Transformationen eingeschränkt, die standardmäßig bei der Dokumentüberprüfung verwendet werden können, wobei nicht vertrauenswürdige Transformationen immer CheckSignature zurückgeben false. Insbesondere transformationen, die zusätzliche Eingaben erfordern (angegeben als untergeordnete Elemente in der XML) sind aufgrund ihrer Gefährdung durch böswillige Benutzer nicht mehr zulässig. W3C empfiehlt, die XPath- und XSLT-Transformationen zu vermeiden, d. h. die beiden haupttransformationen, die von diesen Einschränkungen betroffen sind.

Das Problem mit externen Verweisen

Wenn eine Anwendung nicht überprüft, ob externe Verweise für den aktuellen Kontext geeignet erscheinen, können sie auf eine Weise missbraucht werden, die für viele Sicherheitsrisiken (einschließlich Denial of Service, Distributed Reflection Denial of Service, Information Disclosure, Signature Bypass und Remote Code Execution) sorgt. Auch wenn eine Anwendung den externen Verweis-URI überprüfen würde, bleibt das Problem bestehen, dass die Ressource zweimal geladen wird: einmal, wenn Ihre Anwendung sie liest, und einmal, wenn SignedXml sie liest. Da es keine Garantie gibt, dass der Lese- und Dokumentationsvorgang denselben Inhalt aufweist, bietet die Signatur keine Vertrauenswürdigkeit.

In Anbetracht der Risiken externer Verweise wird SignedXml eine Ausnahme auslösen, wenn ein externer Verweis gefunden wird. Weitere Informationen zu diesem Problem finden Sie im KB-Artikel 3148821.