Ich plane, Software-Updates über USB-Sticks auf Offline-Maschinen zu veröffentlichen.
Machies werden abgesetzt und möglicherweise viele Jahre vor Ort sein.
Während dieser Zeit werden neue Entwickler eingestellt und entlassen.
Ich habe vor, GnuPG zu verwenden, um die Updates auf dem USB-Stick zu überprüfen, bevor sie installiert werden.
Es wird einen Hauptschlüssel geben, und jeder Entwickler erhält seinen eigenen Entwicklerschlüssel.
Die Entwicklerschlüssel werden vom Hauptschlüssel signiert. Die bereitgestellten Maschinen vertrauen voll und ganz auf den Hauptschlüssel. Die bereitgestellten Maschinen verfügen jedoch nicht über alle Entwicklerschlüssel.
Wie kann ich den bereitgestellten Computern erklären, dass sie mit unbekannten Schlüsseln signierten Paketen vertrauen können? Wenn diese unbekannten Schlüssel vom voll vertrauenswürdigen Hauptschlüssel signiert werden?
In meinen Tests schlägt gpg --verify package.tar.gz.sig fehl, da der öffentliche Schlüssel NICHT bekannt ist.
Um den Schlüssel mit gpg --verify zu akzeptieren, muss ich zunächst --import developer_123.key gpg eingeben.
Das überprüft jedoch nicht, ob der neue Schlüssel vom vertrauenswürdigen Master signiert wurde!
Ich kann einen neuen Rogue_developer-Schlüssel erstellen, der nicht vom vertrauenswürdigen Master signiert ist, den importieren und dann das Paket von gpg --verify authentifizieren.
Ich glaube, ich verstehe ein grundlegendes Verständnis dafür, wie dieser Prozess funktionieren soll.
Sollte ich ...
1) Erlaube allen Entwicklern, mit dem Hauptschlüssel zu unterschreiben (schlechte Idee, der Schlüssel wird durchgesickert und ich kann ihn nicht widerrufen, ohne die bereitgestellten Maschinen neu zu kalibrieren!)
2) Den exportierten Entwicklerschlüssel bündeln mit dem USB-Update.
Aber wie überprüfe ich, ob der Master vor dem Importieren eine Signatur unterzeichnet hat?
3) Wenn es eine Möglichkeit gibt zu überprüfen, dass das Paket mit einem von meinem vertrauenswürdigen Master signierten Schlüssel signiert wurde, ohne diesen Schlüssel importieren zu müssen?
4) An etwas anderes, woran ich nicht gedacht wurde?
Ich bin mir sicher, dass ich etwas falsch verstehe ... Als ich der Meinung war, dass das vollständige Vertrauen des Meisters bedeuten sollte, dass wir auch Schlüssel validieren, die von diesem vertrauenswürdigen Schlüssel signiert wurden?
Aber wie funktioniert das?
Danke für alle Hinweise!
Chris
EDIT:
Ich habe zum Testen einen echten Entwickler (DVKey) und einen Angreifer (ROKey) erstellt.
DVKey wird vom Master-Schlüssel signiert, der voll vertrauenswürdig ist. ROKey ist NICHT mit dem Hauptschlüssel signiert. Bei der Überprüfung eines vom DVKey signierten Pakets bekomme ich
[cds @ notebook ~] $ gpg --homedir FMHOME --verify ArchLinuxARM-rpi-2-latest.tar.gz.sig
gpg: Annahme signierter Daten in 'ArchLinuxARM-rpi-2-latest.tar.gz'
: Signatur gemacht Mi 18 Nov 2015 21:15:55 GMT mit der RSA-Schlüssel-ID B90C2061
gpg: Gute Signatur von "DVKey" [full]
[cds @ notebook ~] $ echo $?
0
Beachten Sie, dass gpg '0' (Erfolg) zurückgegeben hat.
Wenn ich das Schurkenpaket verifiziere, bekomme ich
[cds @ notebook ~] $ gpg --homedir FMHOME --verify Untitled.log.sig
gpg: Annahme von signierten Daten in 'Untitled.log'
gpg: Signatur mit Mi. 18.11.2015 21:23:03 GMT mit der RSA-Schlüssel-ID EEF5033E
gpg: Gute Signatur von "ROKey" [unbekannt]
gpg: WARNUNG: Dieser Schlüssel ist nicht mit einer vertrauenswürdigen Signatur zertifiziert!
gpg: Es gibt keinen Hinweis darauf, dass die Signatur dem Eigentümer gehört.
Primärschlüssel-Fingerprint: C00D C1EE 4670 2FE9 4B8D D03E 4DC6 8D9C EEF5 033E
[cds @ notebook ~] $ echo $?
0
Beachten Sie, dass ich eine Warnung erhalten habe! gpg gab jedoch immer noch '0' zurück, Erfolg. Ich brauche das Fehlen einer vertrauenswürdigen Signatur, um ein FAILURE zu sein.
Noch einmal Danke.