Bundesamt für Sicherheit in der Informationstechnik

M 4.489 Abgesicherter und authentisierter Bootprozess bei eingebetteten Systemen

Verantwortlich für Initiierung: Behörden-/Unternehmensleitung, IT-Sicherheitsbeauftragter

Verantwortlich für Umsetzung: Beschaffer, Entwickler, Planer

Der Bootprozess eines eingebetteten Systems darf nicht kompromittierbar sein. Es darf nicht möglich sein, von unauthentisierten Bootmedien zu starten oder Daten zu übernehmen. Es muss sichergestellt werden, dass die verwendete Software von einer autorisierten Instanz geschrieben oder freigegeben wurde.

Der Bootprozess sollte abgesichert sein, indem der Bootloader die Integrität des Betriebssystems überprüft und es nur dann lädt, wenn es als korrekt eingestuft wurde. Das Betriebssystem sollte nur starten, wenn der Bootloader durch eine Rückwärtsprüfung als vertrauenswürdig bestätigt wurde.

Dies kann mittels asymmetrischer Kryptografieverfahren überprüft werden. Aktuell (Stand 2015) kommen dafür z. B. Elliptic Curve Digital Signature Algorithm (ECDSA) und RSA (Rivest, Shamir und Adleman) in Kombination mit SHA (secure hash algorithm) in Frage. Von der Original-Software wird ein Hashwert berechnet und mit dem privaten Schlüssel des Herausgebers signiert. Überprüft wird er mit dem öffentlichen Schlüssel. Die Authentizität des öffentlichen Schlüssels muss über PKI -Verfahren sichergestellt werden.

Ein sicherer Bootprozess sollte in Stufen ausgeführt werden. Zuerst muss ein minimaler, bei der Herstellung fest in das ROM programmierter Bootloader (ROM-Loader) ablaufen. Dieser muss über einen vorher fest einprogrammierten kryptographischen Schlüssel verfügen, um seinerseits die digitale Signatur des nächsten Boot-Loaders zu verifizieren. Diesen anfänglichen Verifikationsschlüssel muss die Hardware bereitstellen, er kann über eine einmal programmierbare Sicherung in das ROM integriert oder in einem lokalen Trusted Platform Module ( TPM ) abgelegt werden, siehe hierzu auch M 4.483 Einsatz kryptographischer Prozessoren bzw. Koprozessoren (Trusted Platform Module) bei eingebetteten Systemen . Der ROM-Loader lädt einen weiteren Boot Loader mit mehr Funktionen, der dann das Betriebssystem oder wiederum einen Loader startet. Die Signatur muss ebenfalls im hardwaregeschützten Bereich gespeichert sein, weil mit dem Signaturschlüssel geprüft wird, ob die Komponenten in der zweiten (und ggf. weiteren) Stufe des Boot-Ablaufs echt sind. Die auszuführende Software kann mehrstufig geladen werden, wobei die Signatur der jeweils nächsten Stufe von der aktuellen Stufe geprüft wird. Scheitert eine Signaturverifikation oder wird eine Verbindung unterbrochen, muss angenommen werden, dass der sichere Zustand verletzt ist.

Oft werden in eingebetteten Systemen keine x86 basierten Computer mit BIOS (Basic Input/Output System) oder UEFI (Unified Extensible Firmware Interface) sondern ARM basierte Geräte mit dem Universal Boot Loader (U-Boot) eingesetzt. Die TCG bezieht sich in ihren Spezifikationen aber insbesondere auf eine Implementierung des RTM im pre- BIOS bzw. im UEFI in denen der RTM besonders zu schützen ist. Auf ARM Plattformen gibt es in vielen Fällen allerdings bereits ohne Trusted Computing die Möglichkeit eines gesicherten Starts von Software, wie z. B. ARM Secure Boot oder von nur einmal beschreibbarem Speicher, der auch gegen physische Manipulationen geschützt ist.

Prüffragen:

  • Wird die Integrität des Betriebssystems durch den Bootloader überprüft?

  • Wird die Integrität des Bootloaders durch das Betriebssystem überprüft?

  • Ist ein mehrstufiges Boot-Konzept mit kryptografisch sicherer Überprüfung der Einzelschritte realisiert?

  • Wird ein sicherer Hardware-Vertrauensanker verwendet?

  • Wird im Falle eines ARM-basierten eingebetteten Systems ARM Secure Boot genutzt?

  • Wird im Falle von UEFI Secure Boot genutzt?

Stand: 15. EL Stand 2016