Verteilung des Codesignaturzertifikats - Best Practices?

759
fsteff

Verteilung des Codesignaturzertifikats - Best Practices?

Hinweis: Ich bin ein absoluter Neuling, wenn es um Codesignierung und Softwarezertifikate geht. Ich habe versucht zu suchen und zu lesen, wie wir unser spezielles Problem lösen können, habe aber nichts Online-ähnliches gefunden.

Bisher war die Codesignierung für uns kein Problem, da wir an eingebetteten Systemen arbeiten, die auf Windows basieren, aber bei denen wir schlüsselfertige Lösungen liefern. Dann hat unser Antivirusprogramm (das obligatorisch ist!) Einige unserer Binaries (über alle Projekte hinweg) abgelehnt, und es scheint kein wirkliches Muster in dem zu sein, was es nicht mag. Nach wochenlangen Gesprächen mit dem Hersteller des Antivirenprogramms haben wir festgestellt, dass die Lösung für uns darin besteht, dass unsere Entwickler einen vom Scannen ausgeschlossenen Ordner haben (der zum Erstellen der Software verwendet wird), und dass wir während des Zertifikats Code-Signierung implementieren in der Antiviren-Anwendung (für begrenzte interne Verteilung und Testung unserer Software) aufgeführt.

Für den Moment setzen wir Code-Signing ein, nicht für die Sicherheit, sondern nur, um unsere Arbeit machen zu dürfen. Der Antivirus-Anbieter hat uns mitgeteilt, dass selbstsignierte Zertifikate nicht in die weiße Liste aufgenommen werden können - selbst wenn das sinnvoll wäre.

Unsere Entwickler befinden sich an fünf Standorten weltweit und wir suchen nach einer möglichst einfachen Lösung, um sicherzustellen, dass sie alle Code-Signing ausführen können (da sonst der von ihnen erstellte Code nicht getestet werden kann).

Wir hoffen, dass eine Art Zertifikatsverteilung möglich ist, vielleicht sogar mit Active Directory?

In nicht allzu ferner Zukunft werden wir Code-Signierung durchführen müssen, um unsere Softwaresicherheit tatsächlich zu überprüfen. Wenn wir also das verteilte Zertifikat verwenden, wäre es dann immer noch "sicher" für die Validierung zu verwenden? Ich denke nicht - was wundert mich, ob wir zwei Zertifikate haben und mit beiden unterschreiben könnten? Ein Zertifikat würde dann verteilt werden und es uns ermöglichen, zu bauen und zu testen, dann würde ein anderes für die Veröffentlichung verwendet werden.

Wir werden wahrscheinlich ein Microsoft Authenticode-Zertifikat verwenden - es sei denn, es gibt gute Gründe, dies nicht zu tun.

Soweit ich es verstehen kann, hat Microsoft seit dem 1. Februar 2017 ein Hardware-Sicherheitsmodul (HSM) für den Code-Signierungsprozess benötigt - wir hoffen, dass nicht jeder Entwickler einen eigenen HSM in seinem Computer benötigt!

Um meine Fragen zusammenzufassen:

  1. Für die Code-Signatur von Windows-Binärdateien ist ein HSM-Zertifikat erforderlich, oder gibt es andere (in dieser Situation) bessere Alternativen.
  2. Welche Möglichkeiten gibt es, ein Zertifikat an Entwickler zu verteilen? Die Verwendung von AD wäre schön, da sie bereits weltweit vorhanden ist.
  3. Wäre es in einem verteilten Setup möglich, das Signaturzertifikat geheim zu halten?
  4. Wäre die doppelte Signatur eine Option zur Erhöhung der Sicherheit? (Eine Signatur, um das Antivirus während des Tests zu schlagen, eine andere für die tatsächliche Sicherheit der freigegebenen Software.)
  5. Haben Sie eine bessere Lösung für uns?

Danke im Voraus.

-1

1 Antwort auf die Frage

1
harrymc

Für die Code-Signatur von Windows-Binärdateien ist ein HSM-Zertifikat erforderlich, oder gibt es andere (in dieser Situation) bessere Alternativen.

Ein Hardware Security Module (HSM) ist nur ein Hardwaretool für kryptografische Operationen wie Schlüsselverwaltung, Schlüsselaustausch, Verschlüsselung, Verifizierung und sichere Aufbewahrung. Es gibt kein HSM-Zertifikat, aber es gibt Zertifikate, die von einem HSM generiert werden.

Ich habe selbst kein HSM verwendet, aber ich würde mich bei Schlüsseln, die von einer solchen Hardware generiert werden, nicht sorgen. Sie können für den internen Gebrauch geeignet sein, für den externen Gebrauch müssen Sie jedoch Zertifikate verwenden, die von einer bekannten Zertifizierungsstelle (Certificate Authority, CA) erstellt wurden.

Let's Encrypt ist eine kostenlose Zertifizierungsstelle, die häufig verwendet wird. In meiner Organisation haben wir es vorgezogen, für den Vertrieb unserer Software eine bekannte Zertifizierungsstelle zu bezahlen.

Welche Möglichkeiten gibt es, ein Zertifikat an Entwickler zu verteilen? Die Verwendung von AD wäre schön, da sie bereits weltweit vorhanden ist.

Sie können AD verwenden, dies kann jedoch für einige Programmierer ein Overkill sein. Ich würde es nur für das Entwicklungszertifikat verwenden, während das Veröffentlichungszertifikat sehr sicher bleibt, möglicherweise selbst in einem verschlüsselten Container und unter der vollen und nicht gemeinsam genutzten Kontrolle nur einer vertrauenswürdigen Person (und möglicherweise einer Sicherungsperson).

Weitere Informationen finden Sie unter:

Wäre es in einem verteilten Setup möglich, das Signaturzertifikat geheim zu halten?

Nein, in dem Moment, in dem ein Geheimnis geteilt wird, ist es kein Geheimnis mehr. Bewahren Sie das Verteilungszertifikat wie oben beschrieben auf.

Wenn es jemals ausläuft, wird Ihr Zertifikat von allen Browsern und Anti-Virus-Produkten in einer schwarzen Liste aufgeführt, so dass Ihre gesamte verteilte Software unbrauchbar wird. Halten Sie es sicher, als ob Ihr Leben davon abhängt (zumindest Ihr kommerzielles Leben).

Wäre die doppelte Signatur eine Option zur Erhöhung der Sicherheit? (Eine Signatur, um das Antivirus während des Tests zu schlagen, eine andere für die tatsächliche Sicherheit der freigegebenen Software.)

Sicher, und ich würde es als Ihre einzige Möglichkeit ansehen. Das Entwicklungszertifikat kann auslaufen, aber es ist Ihnen egal, da die Personen, die es auslaufen würden, auch diejenigen sind, die in der Lage sind, die unsignierten Module auszuliefern.

Haben Sie eine bessere Lösung für uns?

Scheint so, als hättest du tief über das Thema nachgedacht. In Ihrer Situation hätte ich mich auch für eine solche Doppelzertifikatlösung entschieden.