Ist das meine Signatur?

[Krishty]

Ich stelle Updates für meine Programme ins Internet.

Diese Updates habe ich signiert, mit schönem teurem Zertifikat.

Meine Software soll ein Update nur installieren, wenn es sicherstellen kann, dass das von mir kommt.

Wie macht man sowas?

Meine Überlegungen:

Ich habe keine Probleme, das Zertifikat aus der Datei zu extrahieren. Ich kriege dann natürlich alle Angaben, die dazugehören – Namen, Adresse, Handelsregistereintrag, usw. Aber natürlich wäre es idiotisch, das Zertifikat einfach nach „Krishty“ zu durchsuchen – dann würde ich auch Updates der pakistanischen Rapampamumbra Krishty Software Co. installieren statt nur meine.

Eine Unique ID für das Zertifikat – sofern es sie gibt (Public Key?) – wäre ebenso blöd, denn wenn das Zertifikat ausläuft und ich ein Neues beantrage, würde meine veraltete Software die ganzen neuen Updates von mir ablehnen, weil die UID sich geändert hat. Weil das alte Zertifikat weg ist, hätte ich keine Möglichkeit mehr, irgendein Update auszuliefern.

Durchsuche ich die Zertifikatsbeschreibung sowohl nach meinem Namen als auch nach Handelsregistereintrag (der ändert sich ja nicht so schnell)? Packt der Zertifikats-Provider eine persönliche ID ein, die sich auch bei weiteren Zertifikaten auf meinen Namen nicht ändert? Oder wie macht man das üblicherweise? Ich bin total verwirrt.

Nachtrag: Dieser Artikel hier vergleicht tatsächlich den Firmennamen:

Code: Alles auswählen

If codeSignature.Certificates(1).GetInfo(CAPICOM_CERT_INFO_SUBJECT_SIMPLE_NAME) <> "Concept Software Inc." Then
  isValid = False
End If

Code: Alles auswählen

if (!cert.Subject.StartsWith("CN=Concept Software Inc.") {
  isValid = false;
}

Nachtrag 2: Der .NET Security-Blog empfiehlt, den SHA-1 des öffentlichen Schlüssels zu vergleichen: https://blogs.msdn.microsoft.com/shawnf ... signature/

[Chromanoid]

Am einfachsten ist es denke ich auf einer festen Webseite eine Signatur für das Update zu hinterlegen. Sowas wie https://webseite.de/updates/${sha2} machen, das OK zurück gibt, wenn die SHA2-Signatur zu einem bekannten Update gehört (das kann eine einfache Textdatei nur mit diesem Inhalt sein). Dann kannst Du Dir das Beilegen von Zertifikaten und ggf. aufwendige Verifizierungsmaßnahmen sparen. Ggf. kann in der Textdatei, die über den Hash erreichbar ist, auch noch ein bisschen Inhalt stehen, der auch in dem Update steht, dann ist es noch etwas sicherer.

Wenn das ganze offline funktionieren soll, dann würde ich tatsächlich auch eher den Hash des Zertifikats nutzen. Man will ja nicht an dem Verfahren vorbeioperieren, sonst kann in irgendeiner komischen Zertifizierungsstelle plötzlich jemand ein ebenfalls getrustetes Zertifikat auf Deinem Namen ordern (https://security.googleblog.com/2015/10 ... urity.html).

Es gibt da auch irgendwas von Microsoft. Siehe https://msdn.microsoft.com/de-de/librar ... s.85).aspx das scheint aber teilweise veraltet zu sein.

[Krishty]

Microsofts Authenticode ist nicht veraltet, das gibt es nur schon sehr lange. Meines Wissens nach ist das immernoch Anforderung für Treiber (gibt sonst keinen WHQL-Stempel) :) Für .NET nutzt man Strong Named Assemblies, die sind so ähnlich (aber mit anderen/mehr Features).


Hmm … das mit der Webseite sehe ich sehr skeptisch:

1. die Webseite ist das unsicherste Glied
   • doppelt ausgestellte Zertifikate von einer Gammel-CAs gibt es, keine Frage – aber die Regel sind sie nicht
   • Zugriff auf meine Private Keys kriegt niemand – liegt auf separater Hardware und ich bemühe mich auch, das fein getrennt zu halten – und notfalls kann man das Zertifikat noch bei der CA revoken
   • Zugriff auf die Website, das ist eine recht realistische und alltäglich erfolgreiche Angriffsweise (ich sehe ja, wie viele Bots täglich Passwörter durchprobieren)
2. das Code Signing war u.a. genau gegen diesen Fall geplant – dass die User nicht verseucht werden, wenn jemand meine Webseite hackt und Viren-Updates streut
3. Man in the Middle wird damit wohl auch sehr einfach (schick einfach für jede Anfrage ok.txt zurück)
4. man wird Angriffe schwierig bis garnicht feststellen können
   • oder wann hast du das letzte Mal alle Dokumente deiner Domain aufgelistet und kontrolliert, welches da sein soll und welches nicht?
5. die Webseite wird es vielleicht in einigen Jahren nicht mehr geben, aber wenn der Update-Mechanismus mit gespeicherten Paketen dann immernoch funktionieren würde, wäre das toll

Davon ab eine Korrektur: Die Binaries sind mit einem Zeitstempel signiert, und das bedeutet, dass die Signaturen nicht „ablaufen“ können. Wenn ich z.B. 2018 melde, dass meine Schlüssel gestohlen wurden, und mein Zertifikat deshalb zurückgezogen wird – dann lassen sich die Binaries von 2017 noch immer problemlos installieren, weil sie 2017 signiert wurden, als mich die CA noch als vertrauenswürdig eingestuft hat.

[xq]

Grundlegend ist doch das Prinzip von digitalen Signaturen folgendes:
Du gibst deinen Public Key raus (sprich: du codest den beispielsweise in deiner Software hart rein) und signierst deine Patches mit dem Private Key. Damit kannst nur du valide Patches erzeugen und diese in der Software einspielen. Zur Sicherheit würde ich einen "aktiven" Schlüssel nehmen und noch eine zweite Methode, für den Fall, dass dein erster PrivKey irgendwie verloren geht.
Updates können eine Aktualisierung des Public Keys erlauben (die ja aber nur angenommen wird, wenn du das ganze signiert hast).

Deine Website kompromittieren dürfte damit also "kein Problem" sein, da ja die Software deinen Public Key kennt und ihn nicht von extern abfragt (gilt absolut zu vermeiden) und man ja auch auf deine Website keine gültigen Patches hochladen kann (da diese ja mit deinem PrivKey signiert sein müssen).

[Krishty]

Updates können eine Aktualisierung des Public Keys erlauben (die ja aber nur angenommen wird, wenn du das ganze signiert hast).

Kriegt mein nächstes Zertifikat denn das selbe Private/Public Key Pair? Nachtrag: Oft ja, manchmal nicht:

• die Schlüsselmethode wird wohl steigender Rechenleistung der Cracker angepasst (der Artikel nutzt noch 1024-Bit-Schlüssel, während man heute (vier Jahre später) bei 1536 und 2048 ist)
• wenn Admins ausgetauscht werden oder Personal die Firma verlässt, sollte man die Schlüssel wechseln
• je länger Schlüssel in Nutzung sind, desto mehr Leute kriegen sie zu Gesicht (egal, wie hoch die theoretische Sicherheit ist)

Das Problem ist dann:

• jetzt: Ich schreibe einen Updater, der Key 123 erwartet.
• Ich bringe Update 1 raus, mit 123 signiert.
• nächstes Jahr: mein Zertifikat läuft aus. Ich kriege ein neues. Key ist nun 456.
• Ich muss ein Update 2 mit dem alten Key 123 signieren (was nicht geht – abgelaufen), das einen neuen Updater liefert, der 456 statt 123 erwartet.
• Ich bringe Update 3 mit Key 456 raus. (Schlecht: Das muss über einen anderen Pfad verteilt werden als Updates 1 & 2, weil der alte Updater noch Key 123 erwartet.)
• Ab diesem Punkt müssen alle Installationen erstmal Update 2 mit Key 123 installieren, bevor sie zu Update 3 (dessen Key 456 sie nicht kennen) fortschreiten können – keine kumulativen Updates mehr möglich
• mit der Zeit wird das immer schlimmer

Darum frage ich, ob es in einem GlobalSign X.509 Felder oder Eigenschaften gibt, die meiner Identität zugeordnet sind (sich also nie ändern) anstatt einem spezifischen Zertifikat von mir.

Aus den Gründen oben (geheime Daten müssen ausgetauscht werden, wenn man den Admin feuert) sollte es bitte schon was Öffentliches sein.

Es gibt ein Subject-Feld. Darin steht mein Name, meine E-Mail-Adresse, Postadresse, …

Das als Ganzes ist natürlich wertlos, denn umziehen möchte ich schon gern. Das Feld gliedert sich aber in kleinere Attribute.

Eins davon ist Subject Distinguished Name.

Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN). The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer name field. A CA MAY issue more than one certificate with the same DN to the same subject entity.

Das ist also tatsächlich meine Identität beim CA, und sie ist eindeutig (niemand außer mir darf sie nutzen) und konstant für alle weiteren Zertifikate, die ich beantrage. Außerdem ist sie öffentlich.

Normalerweise steht mein Name hinter dem CN=-Attribut (und das ist auch genau das, was der Code oben abfragt!), aber gemäß dieser Frage nutzen andere CAs auch mal nur O=.

Die Frage ist jetzt nur, inwieweit die CAs sich untereinander abgleichen, so dass mein GlobalSign-Krishty verhindert, dass sich bei Symantec jemand als Krishty anmeldet …

[xq]

jetzt: Ich schreibe einen Updater, der Key 123 erwartet.
Ich bringe Update 1 raus, mit 123 signiert.
nächstes Jahr: mein Zertifikat läuft aus. Ich kriege ein neues. Key ist nun 456.

Ich bin mir nicht sicher, ob ich da was falsch verstanden habe, aber den Private Key für ein Zertifikat ist ja nicht an das Zertifikat gebunden sondern im Endeffekt sagt das Zertifikat ja nur: "Wir als CA bestätigen, dass der Public Key ABC tatsächlich von Krishty ist."
Den Private Key sieht die CA ja niemals

Ich muss ein Update 2 mit dem alten Key 123 signieren (was nicht geht – abgelaufen), das einen neuen Updater liefert, der 456 statt 123 erwartet.

Klar kannst du das immer noch signieren, die Aussage ist ja nur "Wir als CA garantierten nicht mehr, dass dieses Update von Krishty signiert wurde", aber du kannst das Update immer noch mit 123 signieren und auch gegen 123 validieren

Ab diesem Punkt müssen alle Installationen erstmal Update 2 mit Key 123 installieren, bevor sie zu Update 3 (dessen Key 456 sie nicht kennen) fortschreiten können – keine kumulativen Updates mehr möglich

Ja, das stimmt wohl. Wobei man natürlich auch zwei Update-Pfade machen kann, einer für logische/day-to-day Updates und einen für Schlüsselupdates, die ja wesentlich seltener passieren

[Chromanoid]

@Krishty: Ich habe vorhin schon angefangen zu antworten. Hier ein paar Punkte zu Deiner vorherigen Antwort.

die Webseite ist das unsicherste Glied

Ja, das stimmt schon. Das Signieren der Updates wäre dann also immer noch eine interessante Absicherung, da reicht dann aber wahrscheinlich ein Zertifikat, das auf der Webseite abrufbar ist.

Man in the Middle wird damit wohl auch sehr einfach

Naja, so einfach, wie man eben die TLS-Kommunikation zwischen Anwendung und Webseite angreifen kann. Ich würde sagen, dass das erst mal als "sicher" gelten sollte.

Microsofts Authenticode ist nicht veraltet

Ich war etwas irritiert, weil man schnell zu veralteten MSDN-Seiten kommt, wenn man da ein paar "offiziellen" Links folgt...

die Webseite wird es vielleicht in einigen Jahren nicht mehr geben, aber wenn der Update-Mechanismus mit gespeicherten Paketen dann immernoch funktionieren würde, wäre das toll

Ich kann mir kaum einen "bombensicheren" Weg vorstellen, das hinzukriegen. Wenn der Schlüssel gestohlen wurde und keine offizielle Stelle weiß welche Updates wirklich gültig sind, dann kann man das doch gar nicht sicherstellen.

Davon ab eine Korrektur: Die Binaries sind mit einem Zeitstempel signiert, und das bedeutet, dass die Signaturen nicht „ablaufen“ können. Wenn ich z.B. 2018 melde, dass meine Schlüssel gestohlen wurden, und mein Zertifikat deshalb zurückgezogen wird – dann lassen sich die Binaries von 2017 noch immer problemlos installieren, weil sie 2017 signiert wurden, als mich die CA noch als vertrauenswürdig eingestuft hat.

Siehe Punkt davor. Das verstehe ich nicht. Dann könnte man sich doch "alte" Updates ausdenken und in Umlauf bringen?

Der folgende Vorschlag ist mit einem dicken "Don't Roll Your Own Crypto" gekennzeichnet :)
Du könntest einfach einen Public-Key in Deine Anwendung einbauen. Der muss nicht von irgendeiner Stelle abgesichert sein. Mit dem korrespondierenden Private Key kannst Du dann Updates erzeugen. Der in der Anwendung gespeicherte Public Key müsste durch ein Update auch austauschbar sein. Das schlimmste, was dadurch passiert, ist, dass eine gewisse Reihenfolge beim Einspielen von Updates eingehalten werden muss.

[Krishty]

Ich bin mir nicht sicher, ob ich da was falsch verstanden habe, aber den Private Key für ein Zertifikat ist ja nicht an das Zertifikat gebunden sondern im Endeffekt sagt das Zertifikat ja nur: "Wir als CA bestätigen, dass der Public Key ABC tatsächlich von Krishty ist."
Den Private Key sieht die CA ja niemals

Moment, Moment – der CA bestätigt mir erstmal nur, dass das Zertifikat gültig ist. Wie ich herausfinde, dass es meins ist, ist ja gerade die Frage des Threads! Aber das mit dem Key hat sich eh erledigt (vorheriger Beitrag) …

Man in the Middle wird damit wohl auch sehr einfach

Naja, so einfach, wie man eben die TLS-Kommunikation zwischen Anwendung und Webseite angreifen kann. Ich würde sagen, dass das erst mal als "sicher" gelten sollte.

Stimmt; das war daneben!

die Webseite wird es vielleicht in einigen Jahren nicht mehr geben, aber wenn der Update-Mechanismus mit gespeicherten Paketen dann immernoch funktionieren würde, wäre das toll

Ich kann mir kaum einen "bombensicheren" Weg vorstellen, dass hinzukriegen. Wenn der Schlüssel gestohlen wurde und keine offizielle Stelle weiß welche Updates wirklich gültig sind, dann kann man das doch gar nicht sicherstellen.

Nein; ich meinte damit den viel wahrscheinlicheren Fall, dass ich alles hinschmeiße und Schafe züchten gehe. Wenn man sich meine Programme/Updates selber wo anders saugt oder von einem Backup installiert, soll das Setup nicht fehlschlagen, bloß weil meine Webseite nicht mehr existiert.

Davon ab eine Korrektur: Die Binaries sind mit einem Zeitstempel signiert, und das bedeutet, dass die Signaturen nicht „ablaufen“ können. Wenn ich z.B. 2018 melde, dass meine Schlüssel gestohlen wurden, und mein Zertifikat deshalb zurückgezogen wird – dann lassen sich die Binaries von 2017 noch immer problemlos installieren, weil sie 2017 signiert wurden, als mich die CA noch als vertrauenswürdig eingestuft hat.

Siehe Punkt davor. Das verstehe ich nicht. Dann könnte man sich doch "alte" Updates ausdenken und in Umlauf bringen?

Nein, dafür müsstest du eine anerkannte Timestamp Authority (z.B. eine große CA) sein.

Der folgende Vorschlag ist mit einem dicken "Don't Roll Your Own Crypto" gekennzeichnet :)

“We Rolled Our Own Crypto”
Pieter Bruegel the Elder, c. 1562
Oil on Panel

Nein. Die Zertifizierung ist von Leuten etabliert worden, die klüger als du und ich sind. Das Zertifikat brauche ich sowieso (sonst kommt man ab Windows 10 kaum auf den Rechner des Users), darum möchte ich das auch für die Identifizierung nutzen.

[Chromanoid]

Davon ab eine Korrektur: Die Binaries sind mit einem Zeitstempel signiert, und das bedeutet, dass die Signaturen nicht „ablaufen“ können. Wenn ich z.B. 2018 melde, dass meine Schlüssel gestohlen wurden, und mein Zertifikat deshalb zurückgezogen wird – dann lassen sich die Binaries von 2017 noch immer problemlos installieren, weil sie 2017 signiert wurden, als mich die CA noch als vertrauenswürdig eingestuft hat.

Siehe Punkt davor. Das verstehe ich nicht. Dann könnte man sich doch "alte" Updates ausdenken und in Umlauf bringen?

Nein, dafür müsstest du eine anerkannte Timestamp Authority (z.B. eine große CA) sein.

Ah, d.h. Du würdest pro Update auch mit der CA einen Trusted Timestamp bauen. Ich frage mich nur, was passiert, wenn die mal ihr Zertifikat ablaufen lassen oder die aus dem Windows Truststore fliegen etc.

Du solltest auf jeden Fall ein Flag bereitstellen das die Prüfung deaktiviert. Dann wird Krishtine Junior im XFZ-Forum sich nicht über Krishty den uralten Schafzüchter ärgern, wenn sie seine coole alte Anwendung aus Präaussteigerzeiten mit allen Updates zum Laufen kriegen will :)


Ich glaube mit dem Subject Key Identifier wärst Du auf der richtigen Spur. Ups, das war Quatsch. Du willst es ja umgekehrt, also mehrere Zertifikate ein Key und nicht ein Key aus mehreren Zertifikaten...

For end entity certificates, the subject key identifier extension provides a means for identifying certificates containing the particular public key used in an application. Where an end entity has obtained multiple certificates, especially from multiple CAs, the subject key identifier provides a means to quickly identify the set of certificates containing a particular public key. To assist applications in identifying the appropriate end entity certificate, this extension SHOULD be included in all end entity certificates.
[...]
Where a key identifier has not been previously established, this specification RECOMMENDS use of one of these methods for generating keyIdentifiers or use of a similar method that uses a different hash algorithm. Where a key identifier has been previously established, the CA SHOULD use the previously established identifier.

https://tools.ietf.org/html/rfc5280#section-4.2.1.2

[Alexander Kornrumpf]

Mein laienhaftes (!) Verständnis:

1) "Moment, Moment – der CA bestätigt mir erstmal nur, dass das Zertifikat gültig ist. Wie ich herausfinde, dass es meins ist, ist ja gerade die Frage des Thread!"

Ihr redet aneinander vorbei. Die CA bestätigt dir "nur", dass das Zertifikat gültig ist, aber der _Inhalt_ des Zertifikats ist das was MasterQ sagte, und die CA bestätigt dir ja die Gültigkeit des Inhalts. Der ganze Sinn eines Zertifikats ist es einen Public Key auf eine Identität zu mappen. Die Definition einer Identität ist offensichtlich, dass sie sich nicht ändert. Ich kann dir nicht sagen welches Feld du dazu im Einzelnen prüfen musst. Im Grunde ist es natürlich auch dir überlassen, welche Kombination an Werten du als hinreichend zur Feststellung deiner Identität erachtest und der Vereinbarung zwischen dir und der CA überlassen, wie du diese Werte auf das Zertifikat bekommst :)

Offensichtlich darfst du (aus den Gründen, die du selbst erkannt hast) jedenfalls gerade nicht den Public Key prüfen, denn wenn du anfängst selbst Keys zu verwalten brauchst du überhaupt kein Zertifikat (was je nach Projektgröße auch eine Option wäre). Das Beispiel in deinem Posting tut also zumindest prinzipiell das Richtige.

2) "Die Frage ist jetzt nur, inwieweit die CAs sich untereinander abgleichen, so dass mein GlobalSign-Krishty verhindert, dass sich bei Symantec jemand als Krishty anmeldet …"

Jain. Offensichtlich ist das dasselbe Problem, wie das ich kein Zertifikat für microsoft.com bekommen darf. Offensichtlich sollte das theoretisch nicht möglich sein. Meines Wissens wird, wenn ich das versuchen würde, praktisch nicht geprüft, ob es bei einer anderen CA ein Zertifikat für microsoft.com gibt (was kein Problem wäre, warum sollten sie nicht zwei CAs beauftragen dürfen) sondern ob mir microsoft.com gehört. Was ich natürlich nicht nachweisen kann. Analog sollte jede CA prüfen ob der Antragsteller, der behauptet Krishty zu sein, auch wirklich Krishty _ist_. Remember es geht um Identität.

Ebenso offensichtlich kannst du alle drei Monate bei fefe nachlesen, dass das nicht immer funktioniert, weil es böse und oder inkompetente Menschen gibt. Ich denke damit wirst du einfach leben müssen, wenn du nicht deine eigene Lösung ausrollen willst. Also wie immer, eigentlich.

[antisteo]

Also signierte Updates baue ich meist mit OpenSSL - da liefert man den Pubkey mit der Software aus und jedes Update muss eine Signatur mitbringen, die anhand des Pubkey nachgeprüft werden kann.

Quellcode: https://github.com/launix-de/bashbundle

[Alexander Kornrumpf]

Also signierte Updates baue ich meist mit OpenSSL - da liefert man den Pubkey mit der Software aus und jedes Update muss eine Signatur mitbringen, die anhand des Pubkey nachgeprüft werden kann.

Quellcode: https://github.com/launix-de/bashbundle

Ja, wie das geht haben wir hoffentlich alle verstanden. Aber was machst du, wenn dir das Schlüsselpaar abhanden kommt? Krishty sagt dann der CA Bescheid.

[Krishty]

Ich habe mich jetzt für das Subject entschieden, wie im Beispielcode ganz oben. Ich habe den StackOverflow-Hinweis bedacht, dass man an die Daten nicht nur per CN=-Feld kommt, sondern auch durch O= und O = .

Ich habe noch keine Zertifikate ersetzen müssen oder so; darum kann ich recht wenig dazu sagen, wie gut oder schlecht es funktioniert. Die Kunden kriegen jedenfalls signierte Pakete.

Danke an alle!

[Krishty]

Ich ergänze das, denn man zerreißt sich gerade das Maul über den chinesischen Browser, der so ziemlich jeden Sicherheitsfehler macht, den man machen kann.

Zumindest eines macht er richtig: Er prüft bei Updates, ob die EXE vom Hersteller kommt – so, wie wir das hier im Thread besprochen haben. Durch die Signatur kann ein Mittelsmann das Update nicht manipulieren.

Leider reicht das nicht: Man muss außerdem sicherstellen, dass es sich bei der gültig zertifizierten Datei wirklich um eine neuere Produktversion handelt als die installierte. Ein Mittelsmann könnte das Update nämlich sonst gegen eine veraltete Version mit bekannten Sicherheitslücken austauschen, die ja ebenfalls vom Hersteller signiert ist. Wenn er die Lücken in der veralteten Version günstig ausnutzen kann und die Kontrolle übernimmt, kann sogar eine manipulierte Version des neuesten Updates nachgeschoben werden, damit der Anwender nichts merkt.

(YMMV, denn der Angriff des Mittelsmannes gelingt nur, wenn die Verbindung nicht ordentlich verschlüsselt ist. Aber man will ja sicher gehen.)

Daher nicht nur im Zertifikat CN= und O= testen, sondern auch die Payload daraufhin prüfen, ob es sich tatsächlich um die erwarteten Daten handelt.