War diese Seite hilfreich?
Ihr Feedback ist uns wichtig. Teilen Sie uns Ihre Meinung mit.
Weiteres Feedback?
1500 verbleibende Zeichen
Exportieren (0) Drucken
Alle erweitern
Erweitern Minimieren

Verzögertes Signieren von Assemblies

Veröffentlicht: 23. Aug 2005
Von Mathias Schiffer

Versehen Sie Ihre Assemblies mit einem Strong Name, zeigt dies zur Zeit des Kompilierens seine Auswirkungen. Oft ist dies aber weder erwünscht noch möglich. Abhilfe schafft die Technik des verzögerten Signierens von Assemblies.

Es gibt mehrere Gründe dafür, dass eine Assembly nicht signiert werden kann. Beispielsweise erhält nicht jeder Entwickler, der eine signierte Assembly abzuliefern hat, das Vertrauen der Geschäftsführung so weit, dass er Zugriff auf den für das Signieren notwendigen privaten Schlüssel der Firma erhält. Zu anderen möglichen Gründen zählt beispielsweise auch das Problem, dass Codeverschleierungen an MSIL-Code nach dem Signieren einer Assembly definitorisch nicht mehr möglich sind (siehe auch MSDN Quickie "Schützen Sie .NET-Code vor neugierigen Augen!"

Verzögertes Signieren mit Attributen und SN.EXE

Abhilfe für solche Szenarien bietet die Technik des verzögerten Signierens ("Delayed Signing"), durch die im resultierenden Assembly-Manifest lediglich der öffentliche Schlüssel hinterlegt sowie Platz für die benötigten Signaturdaten reserviert wird. Die betroffene Assembly wird also vorläufig nicht vollständig signiert.

Das klingt nicht kompliziert und ist es zum Glück auch nicht: Sie geben in Ihrem Sourcecode im AssemblyInfo-Modul neben dem für einen starken Namen ohnehin benötigten AssemblyKeyFileAttribute (nur öffentlicher Schlüssel) zusätzlich lediglich das Attribut AssemblyDelaySignAttribute an und setzen dessen Wert auf True.

' Attribute für Visual Basic:
<Assembly: AssemblyKeyFileAttribute("PublicKey.snk")> 
<Assembly: AssemblyDelaySignAttribute(True)>

// Attribute für C#:
[assembly: AssemblyKeyFileAttribute("PublicKey.snk")]
[assembly: AssemblyDelaySignAttribute(true)]

Die hierbei notwendige Datei mit dem öffentlichen Schlüssel erhalten Sie mithilfe des "Strong Name"-Tools SN.EXE aus dem .NET Framework. Grundlage ist dabei die Schlüsselpaar-Datei, die den privaten und den öffentlichen Schlüssel enthält. Die Datei für den öffentlichen Schlüssel muss Ihnen also vorab vom Inhaber der geschützten Schlüsselpaar-Datei übergeben werden. So einfach lässt sich die benötigte Datei erzeugen:

SN.EXE -P FullKey.snk PublicKey.snk

Wer im Besitz der vollständigen Schlüsselpaardatei für die Vergabe des Strong Names ist, kann die Assembly zu einem späteren Zeitpunkt (etwa nach der Verschleierung oder im Zuge der finalen Zusammenstellung einer Distribution) wie folgt gültig signieren:

SN.EXE -R Assembly.dll FullKey.snk

Arbeiten ohne benötigten Strong Name

Eine nicht abschließend signierte Assembly trägt natürlich (noch) keinen Strong Name. Dieser wird ja erst bei der abschließenden Signierung verfügbar und positiv zu kontrollieren. Dies kann sich bei weiteren Entwicklungs- und Debug-Arbeiten als hinderlich herausstellen.

Sie können jedoch zur Abhilfe die Prüfung auf eine gültige Signatur für die Assembly vorübergehend deaktivieren. Auch hierfür verwenden Sie das Werkzeug SN.EXE:

SN.EXE -Vr Assembly.dll

Vergessen Sie bitte keinesfalls, diese die Sicherheit gefährdende Änderung später wieder aufzuheben:

SN.EXE -Vu Assembly.dll

Sofern Ihnen die Rolle zukommt, die abschließende Signatur zu vergeben, sollten Sie im gleichen Zuge immer auch hierauf einen prüfenden Blick werfen.

Mathias Schiffer widmet sich als freier Softwareentwickler und Technologievermittler größeren Projekten ebenso wie arbeitserleichternden Alltagslösungen. Seit Jahren gibt er sein Wissen in unzähligen Publikationen und Beratungen auch an andere Entwickler und Entscheider weiter. Sie erreichen ihn per E-Mail an die Adresse Schiffer@mvps.org.


Anzeigen:
© 2015 Microsoft