Zertifikate und Signierung von Freeware?

[Uwe Raabe]

Zitat von Harry Stahl:

es erscheint dann ein Passwortfenster, wo ich das Passwort eingeben muss

Dieses interaktive Signieren, bei dem der Benutzer ein Passwort eingeben, einen Knopf drücken oder seinen Fingerabdruck oder sein Gesicht präsentieren muss, ist für einen automatisierten Build-Prozess schlichtweg nicht durchführbar. Ohne die Möglichkeit einer automatischen Signierung durch einen Build-Agent auf einer virtuellen Maschine ist das für professionelle Softwareentwicklung einfach nicht zu gebrauchen.

Erfreulicherweise scheint sich ja bei VSoft in dieser Richtung was zu tun: https://en.delphipraxis.net/topic/12...&comment=96095

[Harry Stahl]

Zitat von Uwe Raabe:

Zitat von Harry Stahl:

es erscheint dann ein Passwortfenster, wo ich das Passwort eingeben muss

Dieses interaktive Signieren, bei dem der Benutzer ein Passwort eingeben, einen Knopf drücken oder seinen Fingerabdruck oder sein Gesicht präsentieren muss, ist für einen automatisierten Build-Prozess schlichtweg nicht durchführbar. Ohne die Möglichkeit einer automatischen Signierung durch einen Build-Agent auf einer virtuellen Maschine ist das für professionelle Softwareentwicklung einfach nicht zu gebrauchen.

Erfreulicherweise scheint sich ja bei VSoft in dieser Richtung was zu tun: https://en.delphipraxis.net/topic/12...&comment=96095

Also mich stört es kaum, da ich ja so oft nicht eine neue Programmversion herausgebe. Dann muss ich zweimal ein Passwort eingeben (z.B. Signierung der Exe und Signierung des Setup-Programms), das kostet mich vielleicht 4 Sekunden. Gleichzeitig wird es sicherer, weil Passwörter nicht in Batch-Dateien eingespeichert sind oder privat-keys irgendwo frei zugänglich im Dateisystem gespeichert sind.

Hängt also wohl mehr von den Gesamtumständen ab...

[Uwe Raabe]

Es hängt davon ab, ob man einen automatisches Build-System hat, bei dem man den Build-Prozess über einen Klick auf den Start-Button des jeweiligen Projekts auf einem Dashboard (eine Webpage) startet und eben nicht vor dem ausführenden Rechner sitzt und mal eben den USB-Stick einstecken kann.

Die physikalische Basis meines Build-Systems steht im Keller und hat nicht mal einen Bildschirm, eine Tastatur oder eine Maus. Selbst wenn, würde der Build-Prozess gar nicht interaktiv ablaufen, so dass ein manuelles Eingreifen gar nicht möglich wäre (zumindest nicht ohne erheblichen Aufwand).

[himitsu]

Jo, wenn ein automatisiertes System die Anwendung bereitstellt bereitstellen soll, dann ist es echt sowas blöd unbenutzbar.

'nen Roboter, der mit einen künstlichen Finger dran stupst.
https://www.youtube.com/watch?v=Q_3f6OC9p0s

Wenn diese Bereitstellung aber nur intern ist und für die Kunden es (seltener) manuell erstellt wird, dann könnte man es schon so (umständlich) machen.
Für das Interne könnte man ja schließlich auch ein SelfSigned-Zertifikat benutzen.

Zitat:

... steht im Keller und hat nicht mal einen Bildschirm, eine Tastatur oder eine Maus. Selbst wenn, würde der Build-Prozess gar nicht interaktiv ablaufen ...

So einen USB-Stick mit Taster/Fingerabdruck/..., denn könntest du bei dir lokal angesteckt haben und im Keller wird über einen virtuellen USB-Port via LAN drauf zugegriffen.

Aber eigentlich hatte ich mir sowas eher mal andersrum vorgestellt (und viele Andere auch),
also der Stick steckt irgendwo in einem Host/NAS/sonstwo und via LAN kann sich der oder können sich die Entwickler diesen auf einen virtuellen USB-Port bei sich durchschleifen ... jeweils Einer, wer ihn grade braucht.

[jaenicke]

Certum wurde ja schon verlinkt. Und dort gibt es auch eine Clouud Signierung. Da kann man ein Token am Handy freischalten und kann dann 2 Stunden lang ohne Eingabe signieren. Das ist ein Kompromiss. Ähnliche Lösungen gibt es wohl auch, bei denen man nicht so oft etwas bestätigen muss.

Gut daran ist, dass der Server Anzeichen für einen Missbrauch erkennen kann und selbst bei Bekanntwerden der Zugangsdaten das weitere Signieren problemlos unterbunden werden kann.

[Uwe Raabe]

Vincent Parrett von VSoft beschäftigt sich ja schon eine ganze Weile mit dem Thema (siehe Code Signing with USB Tokens). Es gibt offenbar Tokens, mit denen man automatisch signieren kann - man muss nur sein Zertifikat bei jemandem erwerben, der solche Tokens verwendet.

Problematisch scheint aber die Bereitstellung eines solchen Tokens über das Netzwerk zu sein. Man könnte nun das Token auf einem dedizierten Build-Agent bereitstellen, der dann exklusiv für das Signieren zuständig ist. Das hat allerdings den Nachteil, dass die zu signierenden Dateien auf diesen Agent transportiert werden müssen und nach der Signierung potentiell auch wieder zurück müssen. Diese Verzögerung möchte man sicher vermeiden.

An diesem Punkt setzt der aktuell von VSoft entwickelte Code-Signing-Server an, der in dem bereits weiter oben von mir verlinkten Post in der Englischen DP erwähnt wird. Zusammen mit einem geeigneten Token sollte das den von mir beschriebenen Anforderungen genügen.

Mein aktuelles Zertifikat (ohne Token) läuft noch bis April 2026. Ich gehe davon aus, dass sich bis dahin eine stabile Lösung herausgebildet hat. Bis dahin werde ich wohl auch meine aktuelle ESX-Server Umgebung auf eine Proxmox-basierte Lösung migriert haben. Da VSoft intern auch Proxmox im Einsatz hat, stehen die Chancen gut, dass es damit dann funktioniert.

[jaenicke]

Sinnvoller wäre es, wenn man es der signierten Datei ansehen könnte, ob sie ohne Passworteingabe signiert wurde (und damit potentiell gefährlicher ist) oder mit manueller Eingabe eines Passworts (so dass das Vertrauen entsprechend höher ist). Dann könnte man dementsprechend unterscheiden.

[Uwe Raabe]

Zitat von jaenicke:

ob sie ohne Passworteingabe signiert wurde (und damit potentiell gefährlicher ist) oder mit manueller Eingabe eines Passworts (so dass das Vertrauen entsprechend höher ist).

Auch bei der automatischen Signatur muss man wohl ein Passwort eingeben, halt nur nicht bei jedem Signiervorgang. Ohne Passwort oder sonstige Identifikation kommt man gar nicht an das Zertifikat auf dem Token ran. Wie bei allen Szenarien, bei denen Zugangsdaten gecached werden, ist ein entsprechendes Vertrauen in das Zielsystem eine unabdingbare Voraussetzung. Das gilt für einen irgendwie gearteten digitalen Store auf dem Rechner genauso wie für das Post-It am Bildschirm.

Ich sehe auch nicht, warum das wiederholte Eingeben des Passworts beim Signieren ein höheres Vertrauen genießen sollte. Ich würde mehr einem System vertrauen, wo der Zertifikat/Passwort-Inhaber das Passwort an einer geschützten Stelle hinterlegt und den Zugriff darauf mit den im Build-System vorhandenen Bordmitteln regelt (so können nur solche Dateien signiert werden, die im Build-System erzeugt werden), als dass das Passwort allen Entwicklern mitgeteilt wird, die dann jede beliebige Exe damit signieren können - und mit einem Flag in der Signatur auch noch ein höheres Vertrauen vermitteln?

Es ist ja leider oft so, dass Sicherheit, die mit Ineffizienz einher kommt, schon sehr bald umgangen wird. Idealerweise sollte Sicherheit (hier das Signieren) intrinsisch und transparent sein: nicht abschaltbar und dem Benutzer keine zusätzlichen Tasks aufbürdend, damit er es gar nicht in Versuchung kommt es abzuschalten.

[jaenicke]

Zitat von Uwe Raabe:

Auch bei der automatischen Signatur muss man wohl ein Passwort eingeben, halt nur nicht bei jedem Signiervorgang.

Das verstehe ich anders:
https://www.ssl.com/de/leiten/Codesi...tomatisierung/

Zitat von Uwe Raabe:

als dass das Passwort allen Entwicklern mitgeteilt wird, die dann jede beliebige Exe damit signieren können - und mit einem Flag in der Signatur auch noch ein höheres Vertrauen vermitteln?

Wenn alle Entwickler für die Auslieferung der Dateien zuständig sind, passt das natürlich weniger gut in das Szenario. In den meisten Firmen dürften dafür aber deutlich weniger Personen verantwortlich sein.

Die echte Signierung ist ja nicht für alle Tests erforderlich, sondern nur für die tatsächlichen Kandidaten für eine Auslieferung. Aus Sicherheitsgründen ist das auch sinnvoll, wenn man die echten Signaturen nur einsetzt, wo es wirklich erforderlich ist. Aktuell ist es aber leider oft so, dass einfach alles ohne Prüfung signiert wird, so dass ein Angreifer nur den passenden Code ins Repository bekommen muss und sehr einfach eine signierte Exe bekommt.

[Uwe Raabe]

Zitat von jaenicke:

Das verstehe ich anders:
https://www.ssl.com/de/leiten/Codesi...tomatisierung/

Na ja, auch da lässt es sich so automatisieren, dass man eben nicht jedes mal das Passwort eingeben muss (So automatisieren Sie die EV-Code-Signierung mit SignTool.exe oder Certutil.exe unter Verwendung von eSigner CKA (Cloud Key Adapter)). Das Verfahren entspricht im Grunde dem, was Vincent in seinem Blog-Artikel im Abschnitt Prompting for Passwords beschreibt (Stichwort Single Logon).

Zitat von jaenicke:

Aus Sicherheitsgründen ist das auch sinnvoll, wenn man die echten Signaturen nur einsetzt, wo es wirklich erforderlich ist. Aktuell ist es aber leider oft so, dass einfach alles ohne Prüfung signiert wird, so dass ein Angreifer nur den passenden Code ins Repository bekommen muss und sehr einfach eine signierte Exe bekommt.

Genau darauf bezog sich ja die Einschränkung, den Zugriff darauf mit den im Build-System vorhandenen Bordmitteln zu regeln. Natürlich darf in so einem System nicht irgendwer die Signierungstask in irgendein Build-Projekt einbinden. Das fällt dann eben auch unter diese Rubrik:

Zitat von jaenicke:

In den meisten Firmen dürften dafür aber deutlich weniger Personen verantwortlich sein.