Warum wird empfohlen, den privaten Schlüssel für die Assembly-Signatur in Open-Source-Repositorys einzubinden?

Question

Nach MSDN ist es eine empfohlene Praxis umfassen sowohl die privaten und öffentlichen Schlüssel für einen starken Namens Baugruppen in das öffentliche Source-Control-System verwendet, wenn Sie Open-Source-Software zu entwickeln sind:

Wenn Sie Wenn Sie ein Open-Source-Entwickler sind und die Identitätsvorteile einer Assembly mit starkem Namen möchten, sollten Sie den privaten Schlüssel, der einer Assembly zugeordnet ist, in Ihr Quellcodeverwaltungssystem einchecken.

Das ist etwas, das mich sehr verwirrt. Den privaten Schlüssel öffentlich machen? Würde nicht der ganze Zweck und die Sicherheit der asymmetrischen Kryptographie in diesem Fall besiegt werden?

Ich sehe in dem gleichen Artikel diese Notiz:

Verlassen Sie sich nicht auf starke Namen für die Sicherheit. Sie bieten nur eine einzigartige Identität.

Dies hilft nicht, meine Verwirrung zu reduzieren. Warum dann ein Private-Public-Schlüsselpaar verwenden, wenn Sicherheit nicht das Ziel ist? Ist der starke Benennungsmechanismus in .NET mit privat-öffentlichen Schlüsselpaaren in einer unangemessenen Weise? Ich vermute, dass ich vermisse oder etwas falsch verstehe.

Answer 1

Starke Namensunterschrift ist nicht für die Sicherheit, es ist die Eindeutigkeit zu garantieren. Es ist so, wenn zwei Leute machen, haben Sie eine Weise, sie im GAC auseinander zu erzählen.

Wenn Sie eine Open-Source-Bibliothek haben und möchten, dass die MyOpenSource.dll v1.0.0.0 Ihres Endbenutzers als Ersatz für die freigegebene MyOpenSource.dll v1.0.0.0 verwendet werden kann, müssen sowohl die Kopie des Benutzers als auch die offizielle Kopie mit demselben Schlüssel (oder beide müssen überhaupt nicht signiert sein). Deshalb würdest du es verteilen wollen.

Der starke Name Schlüssel ist nicht für "Dies ist eine offizielle, unveränderte Kopie von MyOpenSource.dll", das ist, was Authenticode signing ist. Es dient nur dazu, Namenskollisionen von verschiedenen Publishern zu verhindern.

Answer 2

Ich stimme nicht zu, dass die Unterzeichnung Ihrer Assemblies keine Rolle in der Sicherheit spielt. Ja, es wird verwendet, um eine Baugruppe zu identifizieren. Und standardmäßig wird die Signatur NICHT erzwungen. Insofern, ja, die Sicherheit wird nicht direkt nur durch das Signieren beeinflusst. Sie können jedoch Ihr Schlüsselpaar verwenden, um die Signaturprüfung zu erzwingen, ohne für ein CA-Zertifikat ausstellen zu müssen. Um dies zu tun, aber Sie müssen P/diese Funktion aufrufen:

Imports System.Runtime.InteropServices 

Friend Class NativeMethods 
    <DllImport("mscoree.dll", CharSet:=CharSet.Unicode)> _ 
    Public Shared Function StrongNameSignatureVerificationEx(wszFilePath As String, fForceVerification As Byte, ByRef pfWasVerified As Byte) As Boolean 
    End Function 
End Class 

Von dort Design eine Basisklasse, die Ihre geschützten Baugruppen aus erben können:

Imports System.Reflection 
Imports System.Security.Cryptography 

Public Class SignedClassBase 
    Shared Sub New() 
     VerifyAssemblySignature(Assembly.GetCallingAssembly()) 
    End Sub 

    Public Sub New() 
     VerifyAssemblySignature(Assembly.GetCallingAssembly()) 
    End Sub 

    Private Shared Sub VerifyAssemblySignature(assembly As Assembly) 
     Dim wasVerified As Boolean 
     If Not (NativeMethods.StrongNameSignatureVerificationEx(assembly.Location, True, wasVerified) AndAlso wasVerified) Then 
      Throw New CryptographicException("Verification failed: Assembly signature did not match.") 
     End If 
    End Sub 
End Class 

Und dann rufen Sie den Basiskonstruktor von abgeleiteten Klasse: Now

Public Class Utils 
    Inherits SignedClassBase 

    Shared Sub New() 
     RuntimeHelpers.RunClassConstructor(GetType(SignedClassBase).TypeHandle) 
    End Sub 

    Public Sub New() 
     MyBase.New() 
    End Sub 
End Class 

wenn eine modifizierte Anordnung instanziiert wird, wird ein aus dem Cryptographic Basisklassenkonstruktor werfen, von der abgeleiteten Klasse verhindert verwendet wird.

So, während die Code-Signatur nicht direkt an die Sicherheit gebunden ist, kann die erzwungene Assembly-Signatur definitiv zu der Sicherheit beitragen, die Sie bereits haben, in Verbindung mit starker Verschleierung, wo nötig. In dieser Hinsicht MUSS der private Schlüssel geheim bleiben.Das Teilen des privaten Schlüssels in einem Open-Source-Projekt ist einfach eine Möglichkeit, den beteiligten Entwicklern das Leben zu erleichtern. Es wäre VIEL besser, stattdessen die Assemblys als Teil des offiziellen Build-Prozesses zu signieren und Ihren privaten Schlüssel vollständig geheim zu halten. Andernfalls kann jeder eine Assembly mit möglicherweise bösartigem Code neu kompilieren und mit Ihrem privaten Schlüssel signieren und verfälschte Kopien Ihres Projekts verteilen.