Freigeben über

System.Security.Cryptography.Xml.SignedXml-Klasse

  • Artikel

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
Briefumschlagsignatur Die Signatur ist in dem XML-Element enthalten, das signiert wird.
Abgeschrägte 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 anderen Elemente enthält.

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 Standard Teile 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, die auf das <Signature> Element angewendet wurde, um den Wert in <SignatureValue>. 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, d. h., die Eigenschaft auf "festlegen Reference.Uri " null, 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 null keinen URI, es sei denn, Ihre Anwendung arbeitet mit einem Protokoll zusammen, das sie 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 (umschlagsignierte Signatur, Abgeschrägte Signatur oder interne getrennte Signatur).

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

  • Das <Transforms>-Element

    Enthält eine sortierte Liste von <Transform> Elementen, die beschreiben, wie der Signierer das Datenobjekt abgerufen hat, das verdaut 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 Transformationsalgorithmus wird entweder als XML (ein XPath-Knotensatz) oder Byte als Eingabe definiert. 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 umschlägen Signatur das Dokument einschließlich der Signatur digestieren, aber der Signierer hätte das Dokument verdaut, bevor die Signatur angewendet wurde, was zu verschiedenen Antworten führt.

  • Das <DigestMethod>-Element

    Identifies the digest (cryptographic hash) method to apply on the transformed content identified by the URI attribute of the <Reference> element. Dies wird durch die Reference.DigestMethod Eigenschaft dargestellt.

Auswählen einer kanonischen Methode

Es sei denn, die Zusammenarbeit mit einer Spezifikation, die die Verwendung eines anderen Werts erfordert, empfehlen wir, die standardmäßige .NET-Kanonisierungsmethode zu verwenden, bei der es sich um den XML-C14N 1.0-Algorithmus handelt, dessen Wert lautet http://www.w3.org/TR/2001/REC-xml-c14n-20010315. 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. Kommentarbasierte Kanonisierungsmethoden werden nicht empfohlen, da sie gegen das Prinzip "Zeichen, was gesehen wird" verstoßen. 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 es einem Angreifer, unnötige Freiheit, einen Hashkonflikt zu erzwingen, wodurch ein manipuliertes Dokument legitim erscheint. In .NET Framework werden standardmäßig nur integrierte kanonischeIzer unterstützt. Informationen zur Unterstützung zusätzlicher oder benutzerdefinierter Kanonisierer finden Sie in der SafeCanonicalizationMethods Eigenschaft. Wenn das Dokument eine kanonische Methode verwendet, die sich nicht in der Auflistung befindet, die durch die SafeCanonicalizationMethods Eigenschaft dargestellt wird, wird die CheckSignature Methode zurückgegeben false.

Hinweis

Eine extrem defensive Anwendung kann alle Werte entfernen, die von Signierern nicht aus der SafeCanonicalizationMethods Sammlung verwendet werden.

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 abgebrochen, um potenziell schädliche Verarbeitungsanweisungen 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. Diese Unterscheidung wird als XML-Signaturumbruch (XSW) bezeichnet.

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 als Kommentare interpretiert, während die Kurznamenformulare 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. die Eigenschaft), die KeyInfo einen Schlüssel zum Überprüfen der Signatur enthält, sollten nicht vertrauenswürdig sein.

Wenn der KeyInfo Wert einen offenen RSA-, DSA- oder ECDSA-öffentlichen Schlüssel darstellt, könnte das Dokument trotz der CheckSignature Methodenberichterstattung, dass die Signatur gültig ist, manipuliert worden sein. 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 zu lesen, was sich <KeyInfo> im Element befindet.

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 Aufrufen der CheckSignature Methode mit dem verifySignatureOnly Parametersatz falsewird keine Sperrüberprüfung ausgeführt, keine Kettenvertrauensstellung überprüft und kein Ablauf überprüft. Selbst wenn ihre Anwendung das Zertifikat selbst extrahiert und an die CheckSignature Methode übergibt, auf die der verifySignatureOnly Parameter festgelegt falseist, reicht dies dennoch nicht aus, um die Manipulation von Dokumenten zu verhindern. Das Zertifikat muss nach wie vor überprüft werden, damit das Dokument signiert wird.

Die Verwendung eines eingebetteten Signaturzertifikats kann nützliche Schlüsseldrehungsstrategien bereitstellen, sei es 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, z. B. einen bekannten Antragstellernamen, reicht nicht aus, um Manipulationen SignedXmlzu verhindern.

  • Das Zertifikat wird überprüft, ob es zum Zeitpunkt der Dokumentsignierung (oder "jetzt" für die Nahezu-Echtzeit-Dokumentverarbeitung 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 Antragsteller des Zertifikats wird entsprechend dem aktuellen Dokument überprüft.

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 umschlagige Signatur verfügen (z. B. beim Signieren des gesamten Dokuments), müssen Sie dies verwenden http://www.w3.org/2000/09/xmldsig#enveloped-signature (dargestellt durch die XmlDsigEnvelopedSignatureTransform Klasse). Sie können auch die implizite XML-C14N-Transformation angeben, aber es ist nicht erforderlich. Für eine abgeschrägte oder getrennte Signatur sind keine Transformationen erforderlich. Die implizite XML-C14N-Transformation kümmert sich um alles.

Mit der vom Microsoft Security Bulletin MS16-035 eingeführten Sicherheit hat .NET eingeschränkt, welche Transformationen standardmäßig bei der Dokumentüberprüfung verwendet werden können, wobei nicht vertrauenswürdige Transformationen immer CheckSignature zurückgegeben falsewerden. 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. Dies sind die beiden Standard Transformationen, 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. Selbst wenn eine Anwendung den externen Verweis-URI überprüfen würde, würde es erneut Standard ein Problem der Ressource zweimal geladen: einmal, wenn die Anwendung sie liest, und einmal, wenn SignedXml sie gelesen wird. Da es keine Garantie gibt, dass die Anwendung die Schritte zum Lesen und Dokumentieren desselben Inhalts liest und dokumentiert, bietet die Signatur keine Vertrauenswürdigkeit.

Aufgrund der Risiken externer Verweise wird eine Ausnahme ausgelöst, SignedXml wenn ein externer Verweis auftritt. Weitere Informationen zu diesem Problem finden Sie im KB-Artikel 3148821.