• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Wir kann man am geschicktesten Dateien nur mit Schluesseldateien signieren und decrypten

framp

Moderator
Teammitglied
Hintergrund:

Von mir gibt es ein Backuptool fuer Raspberries mit dem Namen raspiBackup. Dazu gibt es einen UIInstaller den man sich per curl von meiner Webseite runterladen und aufrufen kann. Sowohl der Installer als auch das eigentliche Backupscript muessen per root aufgerufen werden. Der SW Update kann mit den Scripts vorgenommen werden.

Das Tool gibt es jetzt schon ueber 10 Jahre und hat mittlerweile eine Menge Nutzer gefunden. Es wird Zeit dass ich die beiden Scripts signiere und bei der Installation pruefe ob die Scripts auch von mir stammen um moeglichen Missbrauch zu verhindern.

Erst hatte ich ueberlegt ein Debian Package fuer die 2 Scripts zu bauen und die entsprechenden Signier- und Verifikationsmoeglichkeiten zu nutzen. Zum einen finde ich fuer 2 Scripts ein Paket zu bauen overkill und zum zweiten funktioniert der SW Update nicht mehr so elegant wie bisher.

Somit habe ich mich mal in OpenGPG eingelesen und denke eine Loesung gefunden zu haben. Waere nett wenn sich Leute die sich mit der Thematik auskennen meinen Loesungsweg ansehen wuerden und Feedback geben ob das soweit OK ist oder verbesserungswuerdig oder vielleicht doch ein anderer Weg besser ist.

Vorgehensweise:
1) Ein OpenGPG Key wird von mir erstellt fuer eine eMail

Signieren:
2) Der Public Key wird als ASC exportiert und in meinem git Repo abgelegt
3) Die beiden Scripts werden mit meinem privaten Key signiert und als ASC im git Repo abgelegt

Decrypten:
4) Download des public ASC keys sowie der ASC signierten Scripte vom git
5) Der ASC public Key wird lokal vom von ASC in einen gpg Key 'dearmored'
6) Die ASC Scripts werden lokal von ASC in gpg Scripts 'dearmored'
7) Die beiden Scripts werden mit dem public gpg Key decrypted mit deren public Key Datei

Leider scheint es keine Moeglichkeit zu geben ASC Dateien direkt mit einem ASC Key zu decrypten. Deshalb der Umweg ueber dearmor.

Konkret wuerde das Decrypten wie folgt aussehen:
Bash:
gpg --batch --yes --dearmor raspiBackup_pub.asc # erstellt .asc.gpg aus dem pub key
gpg --batch --yes --dearmor raspiBackup.sh.asc # erstellt .asc.gpg fuer die scripts
gpg --batch --yes --no-default-keyring --keyring /home/framp/raspiBackup/keys/raspiBackup_pub.asc.gpg --output raspiBackup.sh --decrypt raspiBackup.sh.asc.gpg # decrpted die scripts

Any comments welcome :)
 

abgdf

Guru
Das Tool gibt es jetzt schon ueber 10 Jahre und hat mittlerweile eine Menge Nutzer gefunden. Es wird Zeit dass ich die beiden Scripts signiere und bei der Installation pruefe ob die Scripts auch von mir stammen um moeglichen Missbrauch zu verhindern.
Erst hatte ich ueberlegt ein Debian Package fuer die 2 Scripts zu bauen und die entsprechenden Signier- und Verifikationsmoeglichkeiten zu nutzen. Zum einen finde ich fuer 2 Scripts ein Paket zu bauen overkill und zum zweiten funktioniert der SW Update nicht mehr so elegant wie bisher.
Ach, wenn viele Leute das benutzen, und der Paketbau das Problem mit der Verifikation löst, dann würde ich es vielleicht doch damit versuchen.
 
OP
framp

framp

Moderator
Teammitglied
Die Verifikation ist mit einem Paket erschlagen. Aber leider kann ich dann den gesamte Code um den SW Update wegschmeissen und neu schreiben. Das will ich eigentlich vermeiden.

Auch denke ich dass ich das mit der Verifikation soweit verstanden habe. Ich will nur noch mal Feedback haben ob ich mich da nicht noch irgendwo irre und was aendern sollte.
 

/dev/null

Moderator
Teammitglied
Hallo @framp!

Also, ich würde mir da nicht so viel Stress machen.
Einfach auf der Downloadseite einen Hashwert und einen motivierenden Hinweis für den Anwender zum Überprüfen des Downloads anbringen und fertig.
Wer einigermaßen sicherheitsbewusst ist, der überprüft den Hash und wer dazu zu "bequem" ist, der lässt es eben sein. Zwingen kannst du eh niemand dazu.

vy 73 de Peter
 

abgdf

Guru
@framp: Also, der normale Weg ist doch, daß man den Code veröffentlicht und unter eine bestimmte Lizenz stellt, z.B. unter die GNU GPL.
Das hast Du gemacht, der Code ist auf Github, und die Lizenzeinbindung ist soweit ich sehe korrekt. Das ist doch schonmal gut.
Dann kann man noch eine Signatur anbieten, mit der die Authentizität der Daten überprüft werden kann, z.B. mit md5sum. Aber warum sollte man das tun, wenn der Code auf Deiner Github-Seite ist? Wenn jemand Deine Github-Seite gehackt hätte, könnte er auch die Signatur verändern. Und wenn sie nicht gehackt wurde, wäre doch ziemlich klar, daß der Code von Deiner Github-Seite und deshalb von Dir ist.
Und wenn jemand den Code von Deiner Github-Seite heruntergeladen und danach verändert hätte, dann dürfte er das ja laut der GNU GPL, das wäre ja zulässig.
Soll keine Kritik sein, ich finde toll, daß Du solche Skripte anbietest. Ich verstehe nur noch nicht, warum Du da mit Verschlüsselung arbeiten willst.
 
Zuletzt bearbeitet:

Sauerland

Ultimate Guru
@abgdf
Dann kann man noch eine Signatur anbieten, mit der die Authentizität der Daten überprüft werden kann, z.B. mit md5sum.
Das wäre dann nur, die Datei auf Veränderung zu untersuchen.

Beim openSUSE ISO download wird z. B. eine sha1sum Datei angeboten, die mit einem Schlüssel signiert ist.
Anhand der entsprechenden asc-Datei kann man dann feststellen, ob die Signatur der sha1sum stimmt.
Und mit der sha1sum kann man das ISO auf Fehler überprüfen.
Das selbst ISO ist nicht signiert.

Siehe z.B.
SDB:Download help - openSUSE Wiki
SDB:Download-Hilfe – openSUSE Wiki
 
OP
framp

framp

Moderator
Teammitglied
Speziell im Raspberrybereich gibt es viele Leute die von Windows kommen und froh sind wenn sie ihre Raspberry auf der Linux laeuft dazu gebracht haben das zu tun was sie soll. Diesen will ich ermoeglichen relativ einfach ihre kostbaren Muehen zu sichern. Aber diese werden definitiv nicht pruefen ob eine signierte MD5SUM stimmt sondern einfach meinen Installer als root aufrufen der alles soweit installiert. Der Installer muss einfach die Pruefungen unter der Decke vornehmen.

Der Code liegt im github aber der Installer holt sich den Code von meiner Webseite da der Code noch einen Buildprozess durchlaufen muss.

D.h. der Installationsprozess sieht wie folgt aus:
1) Download eines initialen Installerscripts (a) als normaler User
2) Aufruf den Installers (b) per root

Der Updateprozess sieht so aus:
1) Aufruf von raspiBackup (c) als root mit der Option -U um auf neue SW Staende zu pruefen und die ggf upzudaten

In allen Faellen muessen die Scripts als root ausgefuehrt werden. Wenn es nun irgendjemand schafft (a), (b) oder (c) zu modifizieren kann jemand unerwuenschte Dinge auf den Systemen anstellen :mad:. Davor moechte ich die Nutzer (bin ich uebrigens auch - use what you publish:) ) moeglichst schuetzen.

Deshalb mein Ansatz (b) und (c) zu signieren. Der Installer (b) wie auch raspiBackup (c) beim Update prueft mit meinem public key den ich in github ablegen will ob die Dateien mit keinem private Key signiert wurden. Somit sind (b) und (c) gegen unbefugte Aenderungen geschuetzt. Das Problem ist noch der initiale Installer (a). Der unterliegt keinem Bauprozess und den will ich auch in github ablegen mit der Annahme das github secure bzw vertrauenswuerdig ist.

Meine primaere Frage ist ob das dearmor von den Keys soweit OK ist da ich keine pubkey Infrastruktur nutzen will.
 
OP
framp

framp

Moderator
Teammitglied
Ich habe mir jetzt noch mal genauer angesehen wie verschiedene SW vor Manipulation gesichert wird. letzendlich fehlt bei mir noch ein Schriit umd das 100% sicher zu machen: Ich muss noch einen SHA meines public Keys sicher ablegen damit wenn jemand die SW mit seinem eigenen Key signiert ueber den SHA festgestellt werden kann dass der SW Signierer nicht ich ist. Das zu testen ist dann natuerlich ein manueller Prozess und werden wohl auch nur sehr wenige Nutzer nach dem Download durchfueren. Aber die Verifikation mit meinem public key wo dann meine eMail auftaucht sollte schon sehr viel Trust geben :)
 
Oben