Szenario für starken Namen
Aktualisiert: November 2007
Im folgenden Szenario wird kurz umrissen, wie eine Assembly mit einem starken Namen signiert und wie später mit diesem Namen auf sie verwiesen wird.
Assembly A wird auf eine der folgenden Weisen mit einem starken Namen erstellt:
Verwenden einer Entwicklungsumgebung, die das Erstellen starker Namen unterstützt, wie z. B. Visual Studio 2005.
Erstellen eines kryptografischen Schlüsselpaars mithilfe des Strong Name-Tools (Sn.exe) und Zuweisen dieses Schlüsselpaars zur Assembly unter Verwendung eines Befehlszeilencompilers oder mit dem Assemblylinker (Al.exe). Das Windows Software Development Kit (SDK) stellt sowohl Sn.exe als auch Al.exe zur Verfügung.
Die Entwicklungsumgebung oder das Tool signiert den Hash der Datei, die das Assemblymanifest enthält, mit dem privaten Schlüssel des Entwicklers. Diese digitale Signatur wird in der PE (Portable Executable)-Datei gespeichert, die das Manifest von Assembly A enthält.
Assembly B ist ein Consumer von Assembly A. Der Referenzabschnitt des Manifests von Assembly B enthält ein Token, das den öffentlichen Schlüssel von Assembly A repräsentiert. Ein Token ist ein Teilabschnitt des vollständigen öffentlichen Schlüssels und wird aus Platzgründen oft an Stelle des eigentlichen Schlüssels verwendet.
Die Common Language Runtime überprüft die starke Namenssignatur, wenn die Assembly im globalen Assemblycache platziert wird. Wenn während der Laufzeit eine Bindung über einen starken Namen erfolgt, vergleicht die Common Language Runtime den Schlüssel, der im Manifest von Assembly B gespeichert ist, mit dem Schlüssel, der zum Generieren des starken Namens von Assembly A verwendet wurde. Wenn die Sicherheitsüberprüfungen durch .NET Framework und die Bindung erfolgreich sind, ist für Assembly B sichergestellt, dass die Bits von Assembly A nicht verändert wurden und tatsächlich von den Entwicklern von Assembly A stammen.
.gif "Hinweis") Hinweis: |
|---|
Dieses Szenario deckt keine Fragen der Vertrauenswürdigkeit ab. Assemblys können neben starken Namen auch vollständige Microsoft Authenticode-Signaturen tragen. Authenticode-Signaturen enthalten ein Zertifikat, das Vertrauenswürdigkeit bescheinigt. Beachten Sie unbedingt, dass starke Namen es nicht erforderlich machen, Code auf diese Weise zu signieren. Die Schlüssel zum Generieren einer starken Namenssignatur müssen in der Tat nicht mit denen übereinstimmen, die zum Erstellen der Authenticode-Signatur verwendet werden. |
Umgehen der Signaturüberprüfung für vertrauenswürdige Assemblys
Ab .NET Framework Version 3.5 Service Pack 1 werden Signaturen mit starkem Namen nicht überprüft, wenn ein Assembly in eine vollständig vertrauenswürdige Anwendungsdomäne geladen wird, wie etwa die Standardanwendungsdomäne für die Zone MyComputer. Dies wird als Strong-Name-Bypass-Feature bezeichnet. In einer vollständig vertrauenswürdigen Umgebung sind Forderungen nach StrongNameIdentityPermission für signierte, vollständig vertrauenswürdige Assemblys immer erfolgreich, unabhängig von deren Signatur. Das Strong-Name-Bypass-Feature vermeidet in dieser Situation den Aufwand der Überprüfung der Signatur mit starkem Namen für vollständig vertrauenswürdige Assemblys. Dies ermöglicht ein schnelleres Laden der Assemblys.
Das Bypass-Feature gilt für jede Assembly, die mit einem starken Namen signiert ist und die folgenden Eigenschaften aufweist:
Voll vertrauenswürdig ohne StrongName-Beweis (hat z. B. MyComputer-Zonenbeweis).
Geladen in eine voll vertrauenswürdige AppDomain.
Geladen von einem Speicherort unter der ApplicationBase-Eigenschaft von diesem AppDomain.
Nicht verzögert signiert.
Dieses Feature kann für einzelne Anwendungen oder einen Computer deaktiviert werden. Siehe Gewusst wie: Deaktivieren des Strong-Name-Bypass-Features.