|
Online-Hilfe |
Update-Pakete
Allgemeines
Update-Pakete werden benutzt, um mit dem Router Dateien auszutauschen, die auf dem Router gespeichert oder ausgeführt werden sollen.
In jedem Update-Paket ist ein Manifest in Form einer Datei enthalten, dessen Einträge die enthaltenen Dateien beschreiben.
Das Manifest und die Dateien als unkomprimiertes tar-Archiv zusammen ergeben ein Update-Paket.
Bei den Dateien kann es sich um Firmware- oder Konfigurationsdateien sowie Container handeln.
Bereits gepackte Pakete (diese enthalten bereits ein MANIFEST) sind bereits für ein Update verwendbar.
Sollen verschiedene Update-Pakete in einem Paket zusammengefasst werden, zum Beispiel ein Container-Paket und eine ASCII-Konfiguration (wie im Beispiel unten), müssen die einzelnen Pakete zuerst entpackt werden und dann die darin enthaltenen Dateien zusammen mit dem Manifest zu einem gemeinsamen Update-Paket geschnürt werden.
Muss die Integrität eines Update-Pakets besonders abgesichert werden, ist es auch möglich, dieses zu signieren oder zu verschlüsseln und zu signieren.
Es kann auch erzwungen werden, dass der Router nur noch signierte Pakete akzeptiert.
Manifest
Das Manifest ist eine Textdatei (ASCII oder UTF-8 ohne BOM) mit dem Dateinamen "MANIFEST" (ohne Dateinamenserweiterung, z.B. .txt).
Es enthält Sektionen, die die Dateien im Archiv beschreiben.
Leere Zeilen werden ignoriert.
Groß- und Kleinschreibung wird unterschieden.
Jede Zeile muss mit einem Schlüsselwort beginnen, anschließend folgt das "="-Zeichen und der Wert.
Direkt vor und nach dem "=" sind keine Leerzeichen erlaubt.
Die Reihenfolge der Sektionen im Manifest bestimmt die Reihenfolge der Verarbeitung im Router.
Beispielsweise muss ein Container erst installiert werden, bevor er von seiner Konfiguration gestartet werden kann.
Eine neue Sektion wird mit dem Schlüsselwort "FILENAME" begonnen. Das Manifest sollte immer die erste Datei sein, die im Archiv enthalten ist.
Ein Update-Paket muss somit nicht komplett übertragen werden um erkennen zu können, was dieses Archiv enthält. Im Manifest enthaltene Schlüsselwörter sind:
Schlüsselwort | Bedeutung | zwingend erforderlich |
FILENAME | Dateiname der zu benutzenden Datei | ja |
FILETYPE | fest vorgegebener Text, der den Typ der Datei beschreibt | ja |
MD5SUM | MD5-Prüfsumme, um die Unversehrtheit der Datei zu prüfen | ja |
FILESIZE | Angabe der Größe der Datei in Bytes | nein |
DESCRIPTION | freier Text, der die zu benutzende Datei beschreibt | nein |
VERSION | Eine Versionsbezeichnung | bei jedem FILETYPE, der in der Tabelle unten mit einem * in der Bedeutung gekennzeichnet ist |
REQUIRED_SW | definiert die Version der Firmware, die vorhanden sein muss | bei FILETYPE "Incremental Software Update" |
KEY | definiert die Beschreibung des Schlüssels, der im Profil enthalten sein muss, um einen verschlüsselten Container entpacken zu können.
Der passende öffentliche Schlüssel wird automatisch verwendet. | nein |
Mögliche Einträge für den FILETYPE sind:
FILETYPE | Bedeutung |
Full Software Update | Die Datei ist ein Major-Update (1.0, 2.0, 3.0 usw.). * |
Incremental Software Update | Die Datei ist ein Minor-Update (2.1, 2.2, 2.2 usw.). * |
Binary Configuration | Die Datei ist ein Profil in Form einer Binärdatei. |
ASCII Configuration | Die Datei ist eine ASCII-Konfiguration, die nach dem Hochladen sofort ausgeführt und nicht gespeichert wird. |
Stored ASCII Configuration | Die Datei ist eine ASCII-Konfiguration, die nach dem Hochladen gespeichert und nicht ausgeführt wird. |
OpenVPN Configuration | Die Datei ist eine OpenVPN-Konfigurationsdatei (.ovpn), die nach dem Hochladen in die interne OpenVPN-Konfiguration übersetzt wird. |
Container | Die Datei ist ein Linux-Container. |
Licence | Die Datei ist eine Lizenz, die Funktionalität innerhalb eines Containers freischaltet. |
Container Configuration | Die Datei ist der als tar-Archiv gepackte Inhalt von /data/etc eines Containers. |
Full Storage | Die Datei ist eine als tar-Archiv gepackte Sammlung von Dateien für den Container-Storage; bereits vorhandene Ordner werden vor dem Hochladen gelöscht. |
Incremental Storage | Die Datei ist eine als tar-Archiv gepackte Sammlung von Dateien für den Container-Storage; nur bereits vorhandene Dateien werden beim Hochladen überschrieben. |
Bootloader | Die Datei ist der Bootloader, der die Firmware auf den Router lädt. * |
Rescuefs | Die Datei ist ein minimales Betriebssystem, das die Herstellung der Firmware auf dem Router nach einer sicheren Außerbetriebnahme mit Löschen des Speichers ermöglicht. * |
OEM Branding | Die Datei enthält individuelle Werkseinstellungen. |
DSL Firmware Update | Die Datei enthält eine Firmware für das DSL-Modem. * |
Beispiel eines Manifests für ein Firmware-Paket
FILENAME=update-2.0-to-2.1.bin
DESCRIPTION=Firmware
FILESIZE=1317296
MD5SUM=9f660c9f8420877bc13ee3b58fe5de35
FILETYPE=Incremental Software Update
VERSION=2.1
REQUIRED_SW=2.0
Beispiel eines Manifests für ein Profil-Paket
FILENAME=Profile
FILESIZE=17312
FILETYPE=Binary Configuration
DESCRIPTION=Profile: 'Profile', created on 2016-05-20 12:42:40
MD5SUM=3750def5c933925710196ae756cda1eb
Beispiel eines Manifests für ein ASCII-Konfigurations-Paket
FILENAME=ascii.txt
DESCRIPTION=ASCII config
MD5SUM=11d11f5bd994e6ad1294e14fe921de5f
FILETYPE=ASCII Configuration
Beispiel eines Manifests für ein Container-Paket
FILENAME=container_b334b401.tar.xz
DESCRIPTION=Container: 'container_b334b401', created on 2016-05-19 15:33:37
FILETYPE=Container
FILESIZE=1482168
MD5SUM=83b7e8d4dd10d07476e68b315c74ee2d
Beispiel eines Manifests für ein Container-Konfigurations-Paket
FILENAME=etc_container_b334b401
FILESIZE=346368
FILETYPE=Container configuration
DESCRIPTION=Configuration of container: 'container_b334b401'
MD5SUM=3bf7c35af8fe9bf5170ab10207953097
Beispiel eines Manifests für ein Lizenz-Paket
FILENAME=Application_Name
FILESIZE=1368
FILETYPE=Licence
DESCRIPTION=Activate feature set X'
MD5SUM=864333cf5977c2d3c9de99365516a073
Beispiel eines Manifests für ein inkrementelles Container-Storage-Paket
FILENAME=containers_inc.tar.gz
DESCRIPTION=Storage
FILESIZE=290
FILETYPE=Incremental Storage
MD5SUM=63b77afc746cee94a5cfe604ad1efe5a
Beispiel eines Manifests für ein Paket mit einem Container und einer ASCII-Konfiguration
FILENAME=container_b334b401.tar.xz
DESCRIPTION=Container: 'container_b334b401', created on 2016-05-19 15:33:37
FILETYPE=Container
FILESIZE=1482168
MD5SUM=83b7e8d4dd10d07476e68b315c74ee2d
FILENAME=ascii.txt
DESCRIPTION=ASCII config
MD5SUM=11d11f5bd994e6ad1294e14fe921de5f
FILETYPE=ASCII Configuration
Dieser Configuration Guide beschreibt die Vorgehensweise für das Signieren und Verschlüsseln von Update-Paketen.
Um ein Update-Paket im PKCS#7-Format zu signieren oder zu verschlüsseln und zu signieren, ist eine eigene Public-Key-Infrastruktur (PKI) erforderlich.
Das Zertifikat für die Verschlüsselung muss die Schlüsselverwendung (Key Usage) "Data Encipherment" und das Zertifikat für die Signatur "Digital Signature" gesetzt haben.
Zertifikate oder CRLs, die beim Verschlüsseln und/oder Signieren des Pakets im PKCS#7-Format angehängt werden können, werden ignoriert.
Zum Überprüfen/Entschlüsseln der Pakete müssen auf dem Router folgende Zertifikate und Schlüssel der PKI im Menü Administration auf der Seite Zertifikate hochgeladen werden:
- CA-Zertifikat auf dem die PKI basiert
- Zertifikat für die Verschlüsselung des Pakets
- Privater Schlüssel für die Verschlüsselung des Pakets
- Zertifikat für die Signierung des Pakets
Der private Schlüssel für die Signierung des Pakets darf auf dem Gerät nicht hinterlegt werden.
Für die Signierung und Verschlüsselung müssen unterschiedliche Schlüsselpaare verwendet werden.
Der Grund dafür ist, dass der private Schlüssel für die Entschlüsselung auf dem Gerät hinterlegt wird und eines der zahlreichen Feldgeräte leichter kompromittiert werden kann als ein Computer in der Zentrale.
Dem auf dem Gerät hinterlegten privaten Schlüssel für die Entschlüsselung wird deshalb für die Signierung nicht mehr vertraut.
Eine Verschlüsselung ohne Signierung wird nicht unterstützt, da hier keine Authentifizierung statt gefunden hat und der Mehraufwand für die zusätzliche Signierung nur gering ist.
Die Systemzeit (Datum) des Routers muss sich innerhalb des Gültigkeitszeitrums der Zertifikate befinden.
Pakete müssen zuerst verschlüsselt werden bevor das verschlüsselte Paket signiert wird.
Wird ein unverschlüsseltes Paket nur signiert, sind die unten aufgeführten Dateinamenerweiterungen anzupassen.
Verschlüsselung und Signierung erfolgen mit openssl cms mit folgenden Befehlsaufrufen:
Verschlüsseln
openssl cms -encrypt -aes-256-cbc -in upacket.tar -binary -outform DER -out upacket.tar.enc crypt.crt
Signieren
openssl cms -sign -nocerts -md sha256 -in upacket.tar.enc -nodetach -binary -signer trust.crt -inkey trust.pem -out upacket.tar.enc.sign -outform DER
Folgende Befehlsaufrufe können zu Testzwecken verwendet werden:
Überprüfen
openssl cms -verify -CAfile CA.crt -certfile trust.crt -in upacket.tar.enc.sign -inform DER -out upacket.tar.enc
Entschlüsseln
openssl cms -decrypt -recip crypt.crt -in upacket.tar.enc -inkey crypt.pem -inform DER -out upacket.tar
Signatur ohne Überprüfung entfernen
openssl cms -verify -noverify -in upacket.tar.sign -inform DER -out upacket.tar
Dabei gilt:
upacket.tar : Dateiname des zu signierenden/verschlüsselnden Update-Pakets
upacket.tar.enc : Dateiname des verschlüsselten Update-Pakets
upacket.tar.enc.sign : Dateiname des verschlüsselten und signierten Update-Pakets
crypt.crt : Zertifikat für die Verschlüsselung des Pakets
crypt.pem : Privater Schlüssel für die Verschlüsselung des Pakets
trust.crt : Zertifikat für die Signierung des Pakets
trust.pem : Privater Schlüssel für die Signierung des Pakets
Zurück zur Übersicht
|