Zertifikate und Signierung von Freeware?

[jaenicke]

Die ElsterRootCA ist aber eben keine Standardausgabestelle. Deshalb lassen sich deren Zertifikate auch nicht einfach so validieren. Ich habe es ja ausprobiert.

[hanvas]

Zitat:

Wieso soll denn der Rechner das Zertifikat kennen? Da Elster heute eine reine Browseranwendung ist, wird lokal nichts installiert und auch kein Zertifikat im Zertifikatsspeicher abgelegt.

// EDIT:
Also bei mir kann das Zertifikat auf dem lokalen PC nicht verifiziert werden.

Ich habe auf einem meiner PCs das Elster Zertifikat eingesetzt um PDF und XML Dokumente vor Veränderungen zu schützen. Im Grunde eine Art Emulation der Funktionen einer Massensignaturkarte [1]. War eine Art Proof of Concept wie man ein TR-Resiscan kompatibles Verfahren ohne Massensignaturkarte sinnvoll umsetzen kann. Kann sein das ich dabei das Zertifikat selbst in den Zertifikatspeicher geladen habe. Da habe ich unterstellt das der OP das ähnlich gemacht hat. Aber das ändert doch nichts an dem was ich geschrieben habe ?

cu Ha-Jö

[1] Eine Exe scannt eine vorher festgelegte Anzahl Dokumente, exportiert diese als PDF und legt in jede der erzeugten PDFs eine versteckte GUID als Kennung ab. Paralell dazu wird eine vor dem Export eine vorher definierte Anzahl an zufälligen Dokumenten nochmal zum Prüfen vorgelegt - also angezeigt. Über all das wird ein Protokoll als PDF geführt, die GUIDs der einzelnen exportierten PDF Dateien finden sich im Protokoll wieder.

Die exportierten Dokumente werden mit einem Zertifikat versehen (in diesem Fall das Elster Zertifikat) und gegen Veränderungen geschützt, das Protokoll enthält Daten zum eingesetzten Zertifikat, dem Zeitpunkt / Zeitstempel des Scanns und wird mit einer qualifizierten Signatur versehen.

Auf braucht man keine Massensignaturkarte um Massen zu signieren.

[Wittenborner]

Zitat:

Zitat von Uwe Raabe (Beitrag 1534728)

Damit mag Windows vielleicht zufrieden sein, ich als installierender Anwender aber sicher nicht. So ein Elster-Zertifikat kann ja jeder haben und ich kann ja nicht unterscheiden, ob das nun dein Zertifikat ist oder das von dem bösen Hacker, der mir seinen Trojaner unterschieben will.

Schlimmer noch - ich habe mit meiner Aussage einen Bock geschossen. Das Zertifikat wird nur auf meinem eigenen Rechner als gültig erkannt (wohl weil ich es zuvor dort mal installiert hatte). Fazit: so nett die Idee mit dem Elster Zertifikat erscheinen mag, sie taugt nicht.

[himitsu]

Nutzen kann man es ja, aber wird halt wie ein "normales" Self-Signed behandelt.

Und ich weiß nicht, ob Fremde deine geheime Steuernummer kennen sollten.

[QuickAndDirty]

Zitat:

Zitat von Uwe Raabe (Beitrag 1534736)

Ich würde jedenfalls keine Software installieren, die nur mit einem solchen Zertifikat daher kommt.

Aber Software ganz ohne Codesigning Zertifikat dann schon eher ,oder?

Wie ist das mit den ganzen Apple Zertifikaten die man erzeuugt um Apps für den Appstore zu entwickeln? Kann man die zum Signieren von EXE files benutzen?

[Rollo62]

Zitat:

Zitat von QuickAndDirty (Beitrag 1534900)

Wie ist das mit den ganzen Apple Zertifikaten die man erzeuugt um Apps für den Appstore zu entwickeln? Kann man die zum Signieren von EXE files benutzen?

Selbst wenn, die "Kosten" ja auch 99 EUR / Jahr.

Das, was mich daran besonders stört, ist der gewaltige Preisaufschlag, den diese Firmen für "Virtuelles Nichts" veranschlagen.
Die Erstellungkosten liegen im Cent-Bereich, plus ein paar Kosten für Server und Verwaltung und etwas Kosten für die Identitätsprüfung,
das darf meiner Ansicht nach nicht mehr als 100-200 EUR / Jahr kosten, alles andere ist grober, vorsätzlicher Wucher.

Ich habe jedoch im Bereich Zertifikate bisher schon vieles gesehen, von 1000 EUR bis Ende offen, und das quasi ohne Gegenwert,
weil weder Identität garantiert wird, noch irgendeine Verantwortung übernommen wird.
Zum Beispiel für echte Zertifikate einer Prüfstelle wie TÜV, SGS usw., bekommt man zum ähnlichen Preis eine komplette technische Prüfung
mit Messung, Prüfbericht und Zertifikat von einer akkreditierten Stelle.
Auch das ist sicher oft überteuert, aber zumindest hat es einen entsprechenden, höheren Gegenwert als ein Signaturzertifikat.

Das Einzige, was wirklich helfen würde, wäre, wenn sich jetzt alle Entwickler mal vor den Zentralen Microsoft, Apple, Google, Mozilla, usw.
festkleben und protestieren würden und die Herausgabe transparenter Kostenaufstellungen und Preisreduzierungen fordern würden. :-D

(aber sowas passiert ja in der wirklichen Welt ja nicht ... :cry: )

[QuickAndDirty]

Zitat:

Zitat von Rollo62 (Beitrag 1534902)

(aber sowas passiert ja in der wirklichen Welt ja nicht ... :cry: )

Du musst halt Arbeitslos/Student sein mit reichen Eltern am besten Einzelkind mit Aussicht auf Erbschaft von nem Zweithaus... aber diese Leute interessiert eher welches bild über ihre eigne Tugendhaftigkeit sie auf Instagram verbreiten können. Leute die genig haben von dem FANG Monopol, können es sich nicht leisten sich irgendwo festzukleben.
(btw. Netflix... das hätte ein monopol bleiben sollen)

Vermutlich würde meine Frau mich auch nicht mehr ernstnehmen, wenn ich meinen Standpunkt dadurch klar machen würde, dass ich mich bei uns im Treppenhaus festklebe.

Was du mir sagen willst ist , wir können die APP Zertifikate aus dem Mac exportieren und unsere EXE Datei damit signieren?

[himitsu]

Zitat:

Zitat von QuickAndDirty (Beitrag 1534905)

Was du mir sagen willst ist , wir können die APP Zertifikate aus dem Mac exportieren und unsere EXE Datei damit signieren?

Er fragte auch nur, obs ginge.

Aber was sollte Microsoft ein Zertifikat von Apple interessieren?
Bzw. gibt es denn eine RootCA davon, welche Windows kennt, um jenes Zertifikat verifizieren zu können?

[Rollo62]

Zitat:

Zitat von QuickAndDirty (Beitrag 1534905)

Vermutlich würde meine Frau mich auch nicht mehr ernstnehmen, wenn ich meinen Standpunkt dadurch klar machen würde, dass ich mich bei uns im Treppenhaus festklebe.

:-D:-D Das ist eine schöne Vorstellung, ich glaube, ich probier das mal aus. :thumb:

[himitsu]

Deine Eltern sollten sich dort ankleben.

> Eltern haften für ihre Kinder



Wie bereits mehrfach erwähnt, kann man so einige Zertifikate nutzen, zum Signieren,
aber das Prüfen ist die Herausforderung ... entweder man registriert es selbst oder man nutzt im System bekannte Rootzertifikate.

[QuickAndDirty]

Sind die rootzertifkate die Apple für den Appstore und die Entwicklerzertifikate benutzt in Windows und in Browsern bekannt?

[schmidts1981]

Ja, die Root-Zertifikate, die Apple für den App Store und Entwicklerzertifikate nutzt, sind in den meisten Betriebssystemen, einschließlich Windows und gängigen Browsern, in den vertrauenswürdigen Zertifikatspeichern enthalten. Diese Zertifikate stammen oft von bekannten Zertifizierungsstellen, die weltweit anerkannt sind. Du kannst in Windows unter „Zertifikatverwaltung“ nachschauen, ob die entsprechenden Root-Zertifikate vorhanden sind. Normalerweise sollte es keine Probleme mit der Erkennung in Browsern oder dem System geben.

[Hobbycoder]

Ich bin grad über das hier gestolpert

https://marketmix.com/de/windows-app...ode-signieren/

Soweit ich das gesehen habe, kann man ein günstiges SSL-OV-Zertifikat nehmen, was bei 5 Jahre nur knapp $50 kostet. Klingt für mich schon mal sehr interessant.

[Papaschlumpf73]

Zitat:

Zitat von Hobbycoder (Beitrag 1540787)

Soweit ich das gesehen habe, kann man ein günstiges SSL-OV-Zertifikat nehmen, was bei 5 Jahre nur knapp $50 kostet. Klingt für mich schon mal sehr interessant.

Wer probiert's als erster aus? Ich habe leider kein eigenes SSL-Zertifikat - das gehört IONOS.

[jaenicke]

Zitat:

Zitat von Hobbycoder (Beitrag 1540787)

Soweit ich das gesehen habe, kann man ein günstiges SSL-OV-Zertifikat nehmen, was bei 5 Jahre nur knapp $50 kostet. Klingt für mich schon mal sehr interessant.

Das kann man machen, aber damit kommt wohl trotzdem eine Smartscreen Meldung, die nur etwas entschärft ist. Selbst ausprobiert habe ich das nicht.

[Harry Stahl]

Ich habe noch was preisgünstiges gefunden: https://shop.certum.eu/standard-code...onic-code.html

3 Jahre für 329 Euro, bis 16.09 gibt es mit dem Code LUCKY13 einen Nachlass von 13%. (Die haben da auch was für OpenSource für ca. 25 Euro pro jahr).

Vor 30 Minuten bestellt und eben per IDNOW einen Online-Verfication Process durchgeführt. Das ging flott.

Mal sehen, wie der Rest abläuft...

[mytbo]

Zitat:

Zitat von Harry Stahl (Beitrag 1540807)

Mal sehen, wie der Rest abläuft...

Kannst du den Prozess ausführlich beschreiben, welche Dokumente du vorhalten musstest und für welches Card Reader Set du dich entschieden hast? Die Bewertungen für IDnow bei Google und Trustpilot sind nicht so toll.

Bis bald...
Thomas

[jaenicke]

IDNow hat den Vorteil, dass es dort mit dem digitalen Personalausweis schnell und ohne nervige Videotelefonate geht. Ich nehme an, dass das auch hier so geht. Damit hatte ich noch nie Probleme bei anderen Identifizierungen.

[Harry Stahl]

Das mit IDNOW lief völlig problemlos, wie erwartet.

Nur ich Basel hab bei der Bestellung nicht aufgepasst und mir ein Produkt geordert, dass voraussetzt, dass ich selber einen Card-Reader und eine compatible Karte habe. Das habe ich leider erst im letzten Schritt gemerkt, als das Zertifikat generiert werden sollte.

Mal schaun was nun. Habe denen vorgeschlagen meine Bestellung zu ändern und auf das Set mit USB-Stick zu wechseln (kostet nur 30,-- Euro mehr).

[Harry Stahl]

Zitat:

Zitat von mytbo (Beitrag 1540820)

Zitat:

Zitat von Harry Stahl (Beitrag 1540807)

Mal sehen, wie der Rest abläuft...

Kannst du den Prozess ausführlich beschreiben, welche Dokumente du vorhalten musstest und für welches Card Reader Set du dich entschieden hast? Die Bewertungen für IDnow bei Google und Trustpilot sind nicht so toll.

Bis bald...
Thomas

Ich musste nur meinen Personal-Ausweis vorhalten (und mich selber einmal zum Abgleich ins Bild rücken).

Ich habe mich für das "Standard Code signing set" (USB-Set) entschieden. Man erhält dann eine Sim-Karte, die man dann in den USB-Stick stecken kann:

https://shop.certum.eu/standard-code-signing-set.html

War ein wenig gefrickel, mit Download von Treiber und so weiter, aber letzlich alles machbar, funktioniert und ist gut.

Ich benutzte das Signtool und es erscheint dann ein Passwortfenster, wo ich das Passwort eingeben muss, das zuvor auf der Karte gespeichert wurde.

Ich war zuvor ein wenig skeptisch, ob das alles bei meiner etwas ungewöhnlichen Konstellation (Linux als Host, Windows als Client in VM) läuft, aber den Stick konnte ich als Gerät in die Windows-VM übernehmen und kann da benutzt werden.

[Uwe Raabe]

Zitat:

Zitat von Harry Stahl (Beitrag 1542111)

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:

Zitat von Uwe Raabe (Beitrag 1542112)

Zitat:

Zitat von Harry Stahl (Beitrag 1542111)

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. :lol:
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:

Zitat von jaenicke (Beitrag 1542126)

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:

Zitat von Uwe Raabe (Beitrag 1542127)

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:

Zitat von Uwe Raabe (Beitrag 1542127)

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:

Zitat von jaenicke (Beitrag 1542134)

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:

Zitat von jaenicke (Beitrag 1542134)

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:

Zitat von jaenicke (Beitrag 1542134)

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