Signieren einer Firmware mit openssl

[Martin M. (capiman)]

Hallo,

ich möchte sicherstellen, dass ein Firmware-Download richtig ist
und das Firmware-Image, welches geladen wird, von mir ist.
Die Firmware ist in diesem File ein Image von mehreren 100MBytes.

Ok, ich stelle das Firmware-Image bereit und berechne eine Checksumme 
mit sha256 und stelle den Output ebenso bereit.
Nun kann ich beides auf das Board laden und die Checksumme erneut 
berechnen. Wenn sie identisch ist, wurde sie mit großer Sicherheit 
richtig übertragen und es fehlt z.B. hinten nicht ein Stück.

Nun zum Nachweis, dass die Datei von mir ist:
Ich generiere einen Public und einen Privat Key. Den Private Key behalte
ich, ganz geheim. Ich signiere die Firmware mit dem Private Key.
Mit dem Public Key kann ich nach dem Firmware-Download überprüfen,
ob die Datei von mir ist.

So weit die Theorie, wie ich mir das vorstelle. Stimmt dies so? Oder 
mach ich irgendwo einen Denkfehler?

1) Muss der Public Key schon vor dem Download zwingend auf dem Gerät 
vorhanden sein, oder kann ich den Public Key ebenso wie die Firmware und 
die *.sha256 Datei bereitstellen?
Ich vermute, wenn ich diese zum Download bereitstelle, dass ich dann 
eine Sicherheitlücke generiere, weil der Angreifer dann selbst einen 
Public/Private Key generieren kann, er mit seinem Private Key signieren 
und mir seinen Public Key unterschieben kann?

2) Nachdem meine Firmware mehrere 100MB groß ist, dauert das Berechnen 
der sha256 dementsprechend lange. Muss ich das Signieren ebenfalls auf 
der großen Firmware-Image-Datei ausführen? Oder würde es reichen, wäre 
es sicher, wenn ich die *.sha256 Datei signiere?
Ebenso bei der Prüfung dann sha256 von der Firmware-Datei berechne und 
dann die Signierung des Ergebnisses prüfe?

Ich habe folgenden Artikel gefunden:
https://www.elektronikpraxis.vogel.de/wie-man-firmware-und-dateien-in-embedded-systemen-schuetzt-gal-638110/
Dort ist dieses Bild verlinkt:
https://cdn1.vogel.de/-OM1FHd7retkH_gGCM1vaJnlJKI=/images.vogel.de/vogelonline/bdb/1275900/1275913/original.jpg
Es zeigt wie ich mir dies vorstelle.
Und dieses Bild zum Prüfen des Downloads auf dem Gerät:
https://cdn1.vogel.de/uIxKUn6vzNFJehA9yWidG6aazSM=/images.vogel.de/vogelonline/bdb/1275900/1275914/original.jpg

3) Ich verwende folgende Befehle mit openssl:

Bei mir, 1x:
openssl ecparam -name prime256v1 -genkey -noout -out privtest.pem
openssl ec -in privtest.pem -outform PEM -pubout -out public.pem
privtest.pem halte ich geheim, public.pem kommt aufs Gerät
(auf alle Geräte der gleiche public key, sonst müsste ich für jedes 
Gerät eine eigene Signierung durchführen und bereitstellen, also auch 
pro Gerät ein eigenes private/public key pair)

Jedes mal, wenn ich ein Firmware-Image-Update generiere:
sha256 firmware.bin > firmware.sha256.org
openssl dgst -sha256 -sign privtest.pem -out firmware.sign firmware.bin

Zum Prüfen, ob Download ok war
sha256 firmware.bin > firmware.sha256.new
Vergleich, ob firmware.sha256.org mit firmware.sha256.new identisch ist
openssl dgst -sha256 -verify public.pem -signature firmware.sign 
firmware.bin
Wenn Ausgabe "Verified OK", dann passt alles?

Gibt es irgendwelche Änderungen, die ich an den Befehlen unbedingt 
machen sollte? Oder andere Parameter? Kann ich "prime256v1" ohne 
Bedenken verwenden?
Gibt es zusätzliche Befehle, die ich unbedingt in Betracht ziehen 
sollte, weil ich mir sonst Sicherheitslücken einhandle?

Vielen Dank im Voraus!

Schöne Grüße,
Marie

[bingo (Gast)]

Mach das mal besser mit GPG https://wiki.ubuntuusers.de/GnuPG/

[Planloser (Gast)]

bingo schrieb:
> Mach das mal besser mit GPG https://wiki.ubuntuusers.de/GnuPG/

Das kann mach auch anders sehen:
https://www.golem.de/news/verschluesselung-gpg-muss-endlich-weg-2102-153820.html

[Imonbln (Gast)]

Marie M. schrieb:
> 1) Muss der Public Key schon vor dem Download zwingend auf dem Gerät
> vorhanden sein, oder kann ich den Public Key ebenso wie die Firmware und
> die *.sha256 Datei bereitstellen?

Was ist denn das Threat-model?

Wenn du nur sicherstellen willst das alles richtig übertragen würde, 
dann reichen ein paar crc Checksumme. Weil du aber Crypto machst ich an, 
du willst Sicherstellen, das kein Angreifer die Firmware Modifiziert 
hat, dann sollte der Public Key schon auf dem Gerät sein (am besten in 
einen TPM 2.0 oder wenigstens auf ein OTP Speicher)

Idealerweise nimmt man für Sowas aber nicht einfach ein paar 
private/public Keys, sondern setzt eine PKI auf.

Dann erzeugst Du Dir eine Root-CA und mindestens eine Sub-CA und 
überprüfst ob Deine Firmware mit einem Key Signiert ist der von einer 
Sub-CA Deiner vertrauensvollen Root CA beglaubigt ist. Das ermöglicht es 
Dir die Keys gelegentlich auszutauschen. Ansonsten kannst Du Probleme 
bekommen, wenn Deine Firmware lange im Feld ist und die Gefahr besteht, 
das eine Keys komprimiert wurden. Ideal erwiese prüft Deine Firmware 
Update auch vorher, ob das Zertifikat mit welchen signiert wurde, 
widerrufen wurden ist, aber das kann je nach Gerät schwierig sein.

Marie M. schrieb:
> Muss ich das Signieren ebenfalls auf
> der großen Firmware-Image-Datei ausführen? Oder würde es reichen, wäre
> es sicher, wenn ich die *.sha256 Datei signiere?

Es reicht völlig, wenn Du den Hash signierst.

Marie M. schrieb:
> Ebenso bei der Prüfung dann sha256 von der Firmware-Datei berechne und
> dann die Signierung des Ergebnisses prüfe?

Warum nicht andersrum, erst die Signatur Prüfen und nur wenn diese 
Stimmt nochmal den Hash Berechnen, das Spart vielleicht Zeit?

Marie M. schrieb:
> 3) Ich verwende folgende Befehle mit openssl:

Ich empfehle Dir hier Professioneller zu werden. Die Signatur der 
Firmware sollte mithilfe eines PKCs11 Token oder ähnlicher Technologie 
erfolgen, am besten auch gleich auch einer NUC welche Airgapped ist und 
kein Persistenten Speicher hat. Nur so kannst Du sicherstellen das Dein 
Geheimer-Key auch geheim bleibt.

Der Token kommt, wenn Du ihn nicht brauchst in einen Safe und die NUC 
wird versiegelt.

Marie M. schrieb:
> Gibt es irgendwelche Änderungen, die ich an den Befehlen unbedingt
> machen sollte? Oder andere Parameter? Kann ich "prime256v1" ohne
> Bedenken verwenden?

Ja nein vielleicht, das kommt auf Dein Threadmodel und Deine 
Requirements an. Ich empfehle den Stride Model Ansatz zu wählen, um das 
Model zu erstellen. Danach kannst Du die Fage selbst beantworten. Aber 
das ist Arbeit, welche man machen muss, wenn man Security ernst nimmt.

bingo schrieb:
> Mach das mal besser mit GPG https://wiki.ubuntuusers.de/GnuPG/

Warum? einfach nur ein Buzzword ohne Erklärung ist nicht hilfreich in 
einer Diskussion. Was kann der TO mit GPG besser einfacher sicherer 
machen?

[Jim M. (turboj)]

Das Ganze gäbe es übrigens fertich für NordicSemi NRF5x Chips, denn der 
von Nordic bereitgestellte Bootloader funktioniert wie vom OP 
beschrieben. Source Code für den µC ist im NRF SDK.

Den PC Teil haben sie aber mit Python und nicht mit OpenSSL gelöst IIRC.

Hintergrund dieses Aufwands ist das man bei Firmware Updates über 
Bluetooth nicht das Device bricken will.

[und jetzt aber weg (Gast)]

Firmware von mehreren 100MBytes. Kriegst du die je stabil zum Laufen ?

[Martin M. (capiman)]

Es gibt auch größere Systeme als single chip uC.
Im Umfeld von Linux m.E. keine Besonderheit mehr...