Delay Signing von Assemblies

Geschrieben von: Christoph Wille
Kategorie: .NET Allgemein

Assemblies unter .NET müssen signiert werden, wenn sie in den Global Assembly Cache (GAC) installiert werden sollen. Auch sonst sollten Assemblies signiert werden, da die Runtime dann überprüfen kann, ob die zu ladende Assembly mit der übereinstimmt, die zum Kompilierungszeitpunkt verwendet wurde. Dies passiert mittels Public und Private Keys, und wir werden uns heute mit der Frage auseinandersetzen, ob es denn klug ist, einem Entwickler den Private Key der Firma zu geben.

Zuerst zur Klärung der rein technischen Fragen. Der Private Key wird vom Komponentenhersteller verwendet, um den über die Assembly errechneten Hash zu signieren. In die Assembly wird der Public Key (vorher, und somit ist dieser Teil des Hashes) eingebettet, mit dem der Hash verfizierbar ist. Stimmt eingebetteter Hash und der nachgerechnete Hash überein, ist die Assembly vom Hersteller und unverändert.

Besitzt jemand den Private Key, kann er also immer gültige Assemblies herstellen. Ohne diesen Key geht gar nichts. Daher gilt, gerät der Key in falsche Hände, kann die Firma nicht mehr erfolgreich abstreiten, daß ein Code nicht von ihnen kam - weil ja gültig signiert wurde.

Kein Problem denkt man sich - meine Programmierer sind ja zuverlässig, und unsere Firewall ist gut. Nur, was passiert zB wenn ein Mitarbeiter der Zugang zu den Keys hatte, unter unerfreulichen Bedingungen geht/gegangen wird? Sind Sie sich dann noch immer sicher, daß Ihre Keys nicht den Weg nach außen finden werden?

Der sicherste Weg ist, daß Programmierer zum Entwicklungszeitpunkt die Private Keys nicht brauchen - erst wenn das Produkt die Firma verläßt, wird signiert. Doch halt - wie kommen dann die Public Keys und Hashes in die Assemblies? Das passiert über Delay Signing, das es den Programmieren erlaubt, diese einzubetten, aber die Signierung später durch eine andere Person nachgeholt werden kann.

Ein Praxisbeispiel

An einem Beispiel läßt es sich am leichtesten verstehen, wie man vorzugehen hat - und wie es in der Praxis funktionieren kann. Dazu habe ich ein Projekt mit einer Assembly und einer Applikation erstellt (mittels #develop):

Das HelloAssembly Projekt ist die Komponente unserer Firma. Die Applikation, die diese Komponente einsetzt, ist HelloTestApp. Die helloassembly.dll soll in den Global Assembly Cache installiert werden, daher braucht man ein Keypair für die Signierung (generatekeypair.bat):

sn -k keypair.bin

Damit wird ein Schlüsselpaar - Public und Private Key - erstellt. Dies wird im normalen Falle des sofortigen Signierens in der Datei AssemblyInfo.cs dann so verwendet:

[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("keypair.bin")

Damit kann man helloassembly.dll sofort in den GAC installieren (gacinstall.bat):

gacutil -i helloassembly.dll

Und in unserer (tollen) Testapplikation verwenden:

Durch diese Referenz wird der Public Key Token (die verkürzte Version des Public Keys) der helloassembly.dll in das Manifest unserer Applikation eingebaut:

Ab sofort kann uns niemand mehr eine gefälschte helloassembly.dll unterschieben - außer er hat den Private Key zur Verfügung. Und das hätte der Programmierer, weil er das Key Pair hat. Erwischt.

Delay Signing in der Praxis

Also wie sorgt man dafür, daß der Programmierer den Private Key nicht hat? Nun, man gibt ihm den Key einfach nicht, man teilt das Key Pair auf (extractpublickey.bat):

sn -p keypair.bin pubkey.bin

Dadurch erhält man in pubkey.bin den öffentlichen Schlüssel: diesen gibt man dem Programmierer. Die Datei keypair.bin hingegen wandert auf eine Diskette in den Safe, möglichst kryptographisch gesichert sodaß man mehr als ein Person braucht, um sie wieder entschlüsseln zu können.

Der Programmierer kann die Assembly nun Delay-Signen, und das passiert wieder über die Assembly Information der Komponente (AssemblyInfoDelaySign.cs):

using System.Reflection;
using System.Runtime.CompilerServices;

[assembly: AssemblyTitle("")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("AlphaSierraPapa")]
[assembly: AssemblyProduct("")]
[assembly: AssemblyCopyright("")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

[assembly: AssemblyVersion("1.0.0.0")]

// Delay Signing enabled
[assembly: AssemblyDelaySign(true)]
[assembly: AssemblyKeyFile("pubkey.bin")]

Dadurch daß die Assembly jetzt keinen signierten Hash mehr hat, funktioniert der Verification Check nicht mehr, das Installieren in den GAC schlägt fehl:

Um dieses Problem zu umgehen, muß der Programmierer der Komponente die Assembly vom Verification Checking ausnehmen (reg4verificationskipping.bat):

sn -Vr HelloAssembly.dll

Und jetzt geht das Installieren in den GAC auch wieder - genauso wie es wieder möglich ist, andere Assemblies gegen diese zu linken.

Was muß man nun aber tun, damit man die Assembly zum Kunden ausliefern kann? Sie muß signiert werden, und zwar mit Hilfe der weggesperrten keypair.bin Datei und dem Skript beforeshipping.bat:

sn -R helloassembly.dll keypair.bin

Und damit ist die Komponente vollständig signiert. Der Programmierer kann die ganze Zeit entwicklen und testen, und erst kurz bevor die Komponente das Haus verläßt, wird der signierte Hash eingefügt. So läuft auch die Entwicklung der Base Class Library (BCL) bei Microsoft.

Schlußbemerkung

Auf den ersten Blick mag das Problem des Private Key in Händen des Programmierers gering im Vergleich zum Aufwand des Delay Signings sein - doch stellen Sie sich vor, was passiert, wenn Sie nicht abstreiten können, daß ein Virus / was auch immer nicht von Ihrer Firma kommt.

Download des Codes

Klicken Sie hier, um den Download zu starten.

Links zu anderen Sites

#develop (SharpDevelop)
Delay Signing an Assembly
Signing an Assembly with a Strong Name
Strong Name Tool (Sn.exe)

Wenn Sie jetzt Fragen haben...

Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten.

Eine weitere sehr hilfreiche Resource ist das deutsche ASP.NET Wiki, das als zentrale Anlaufstelle für Tips, Tricks, Know How und alles Nützliche was man in seinem Alltag als (ASP).NET-Entwickler so braucht und entdeckt gedacht ist.

Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.

Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.