Der Aufbau sicherer IT-Systeme ist eine komplexe und anspruchsvolle Aufgabe, da verschiedene Bedingungen erfüllt werden müssen, damit ein System umfassend sicher ist. Eine grundlegende Bedingung, die gewährleistet werden muss, ist die Integrität des Systems, d. h. die Sicherstellung, dass sich das System immer in der beabsichtigten Weise verhält. In der Regel bedeutet dies, dass sichergestellt werden muss, dass die Software, d.h. der veränderliche Teil, der Verhaltens eines Systems definiert, nicht verändert wurde. Dieses Ziel kann auf verschiedene Weise erreicht werden. In diesem Artikel wird ein Sicherheitsdienst namens "Secure Boot" vorgestellt und erklärt, einer der Sicherheitsdienste, die Sanctuary bietet. Er stellt sicher, dass Software, die beim Systemstart geladen wird, nicht manipuliert wurde, z. B. durch ein Rootkit oder ein anderer Advanced Persistent Threats (APT; deutsche Übersetzung "fortgeschrittene andauernde Bedrohung").
Secure Boot prüft schrittweise die Integrität der Softwarekomponenten (z.B. boot loader, Betriebssystem und Applikationen) eines Systems während dessen Starts. Bevor eine Softwarekomponente ausgeführt wird, wird ihre Integrität geprüft. Der Verifizierungsprozess wird von der Anfangskomponente E0 des Boot-Prozesses der Plattform (z.B. UEFI-Code) gestartet und iterativ von allen Komponenten E1 … En, die danach ausgeführt werden, fortgesetzt, bis die letzte Komponente En+1 verifiziert und ausgeführt wurde (vgl. Abbildung 1).
Da die Integrität jeder Komponente Ei vor ihrer Ausführung von ihrem Vorgänger Ei-1 überprüft wird, werden nur bekannte (d.h. authentische) Softwarekomponenten geladen und ausgeführt. Wenn die Integrität einer Softwarekomponente nicht erfolgreich geprüft werden kann, sind verschiedene Reaktionen möglich. Beispielsweise kann das System die Ausführung stoppen (auch "fail secure mode" genannt) oder es kann eine authentische Fallback-Version der Softwarekomponente verwenden werden, deren Integritätsprüfung fehlgeschlagen ist. Die Integritätsprüfung einer Komponente ist nur dann sinnvoll, wenn die Komponente, die die Prüfung durchführt, selbst korrekt ist und somit die Prüfung auch korrekt durchführt. Daher muss die Ausgangskomponente E0 vertrauenswürdig sein und wird oft als Vertrauensanker (Englisch Root of Trust; abgekürzt RoT) bezeichnet. Das bedeutet, dass die Integrität von E0 ohne deren explizite Prüfung gegeben sein muss, und entsprechend, dass sie gegen (Software-)Angriffe geschützt werden muss. Eine übliche Methode die Integrität der RoT sicherzustellen, ist durch Speicherung des Codes und der Daten von E0 in nicht-schreibbarem Speicher (Englisch Read-only Memory; abgekürzt ROM), da sie somit nach er initialen Produktion des Systems nicht mehr verändert werden kann. Ausgehenden von der RoT wird die Integrität aller anderen Komponenten E1 … En dadurch sichergestellt, dass die Integrität jeder Komponente E1 durch ihren Vorgänger Ei-1 überprüft wird, bevor Ei ausgeführt wird.
Welche Methode zur Überprüfung der Integrität einer Komponente verwendet wird, hängt dabei von den Anforderungen der Anwendung ab. Der gängigste Ansatz besteht darin, dass der Secure-Boot-Mechanismus einen Integritätsmesswert (IMW) berechnet, bei dem es sich in der Regel um den kryptografischen Hash-Digest des Binärcodes der zu überprüfenden Softwarekomponente handelt. Der IMW wird dann mit einem Referenzmesswert verglichen, der in der Regel vom Plattformhersteller, dem Plattformbenutzer oder dem Softwareanbieter zertifiziert ist. Stimmt der vom Secure-Boot-Mechanismus berechnete IMW mit dem zertifizierten Referenzmesswert überein, ist die Integrität der Softwarekomponente bestätigt.
Reihenfolge der Integritätsüberprüfung
Wie zuvor erläutert, muss sichergestellt werden, dass die Integrität jeder Softwarekomponente vor ihrer Ausführung überprüft wird. Abgesehen von dieser Grundregel gibt es keine weiteren Einschränkungen bezüglich der Reihenfolge der Integritätsprüfung und der Ausführung von Softwarekomponenten. Das bedeutet, dass die Integrität der Softwarekomponente En von jeder Softwarekomponente E0 … En-1, die vor En ausgeführt wird, überprüft werden kann.
Abbildung 2 veranschaulicht ein solches Szenario, bei dem die Integrität der Softwarekomponenten E1, E2 und E3 von der Softwarekomponente E0 überprüft wird (Schritt 1, 2 und 3 in Abbildung 2), bevor E1, E2 oder E3 ausgeführt wird (Schritt 4, 6 und 7 in Abbildung 2). In ähnlicher Weise verifiziert E1 Entität E4 (Schritt 5 in Abbildung 2), obwohl E1 nicht direkt vor E4 geladen wird. Dennoch wird in diesem Beispiel die Integrität jeder Softwarekomponente überprüft, bevor sie geladen wird.
Referenzmesswerte
Die Integrität und Authentizität der Referenzmesswerte müssen gewährleistet sein. Je nach den Anforderungen an die Flexibilität des Secure-Boot-Mechanismus sind verschiedene Ansätze zur Speicherung und Verwaltung von Referenzmesswerten möglich.
In Softwarekomponenten eingebettet Referenzmesswert
Ein Ansatz zur Verwaltung der Referenzmesswerte besteht darin, den Referenzmesswert der Softwarekomponente Ei in die Vorgängerkomponente Ei-1 einzubetten, die die Integrität von Ei verifiziert, wie in Abbildung 3 dargestellt. Die Ausgangskomponente E0 enthält das Referenzmesswert von E1, bezeichnet als M(E1), d.h. den erwarteten Integritätsmesswert von E1. Die Integrität von M(E1) wird durch denselben Mechanismus geschützt, der auch die Integrität von E0 selbst gewährleistet. Die Integrität der eigentlichen Softwarekomponente E1' wird von E0 überprüft, bevor E1' ausgeführt wird. Genauer gesagt berechnet E0 den Hashwert des Binärcodes von E1', bezeichnet als M(E1') (Schritt 1 in Abbildung 3), und vergleicht das Ergebnis mit dem in E0 gespeicherten Referenzmesswert M(E1) (Schritt 2 in Abbildung 3). Die Überprüfung der Integrität von E1' ist nur dann erfolgreich, wenn M(E1') mit M(E1) übereinstimmt. Ist dies der Fall, wird E1' ausgeführt (Schritt 3 in Abbildung 3) und übernimmt die Rolle von E0, d.h. E1' misst den Binärcode von E2' und führt E2' nur dann aus, wenn seine Messung M(E2') mit der Referenzmesswert M(E2) der Softwarekomponente E2 übereinstimmt, der in E1' gespeichert ist. Dieser Prozess wird so lange fortgesetzt, bis die Integrität aller Softwarekomponenten überprüft wurde.
Eine wesentliche Einschränkung dieses Ansatzes ist seine mangelnde Flexibilität. Insbesondere erfordert die Aktualisierung der Softwarekomponente Ei die Aktualisierung der Referenzmesswerte in allen Softwarekomponenten Ej mit j < i.
Referenzmesswerte in zentraler Datenbank verwaltet
Ein flexiblerer Ansatz als der zuvor beschriebene Einbettungsansatz ist die Verwaltung der Referenzmesswerte in einer zentralen Datenbank, wie in Abbildung 4 dargestellt. Bevor die Ausgangskomponente E0 die Ausführung an die Komponente E1' übergibt, prüft sie die Integrität von E1'. Wie zuvor misst E0 den Binärcode von E1' und vergleicht das Ergebnis M(E1') mit dem Referenzmesswert M(E1) von E1. Dieses Mal wird der Referenzmesswert jedoch in einer zentralen Datenbank gespeichert, die von allen Softwarekomponenten, die eine Integritätsprüfung durchführen, gelesen werden kann. Um die Authentizität und Integrität der Referenzmesswerte zu gewährleisten, muss die Integrität der Datenbank geschützt werden. Eine Möglichkeit, die Integrität der Datenbank zu schützen, besteht darin, dieselbe Methode zu verwenden, die zum Schutz der Integrität der Ausgangskomponente E0 verwendet wird, oder E0 zur Überprüfung der Integrität der Datenbank einzusetzen.
Diese Methode ermöglicht die flexible Aktualisierung einzelner Softwarekomponenten. Allerdings erfordert die Aktualisierung von Softwarekomponenten eine authentische Aktualisierung der entsprechenden Referenzmesswerte in der Datenbank.
Referenzmesswert-Zertifikate
Der praktikabelste Ansatz zur Implementierung von Secure Boot ist die Verwendung digitaler Signaturen (Zertifikate), um die Integrität und Authentizität der Referenzmesswerte zu gewährleisten. Dieser Ansatz ist in Abbildung 5 dargestellt. Der Referenzmesswert jeder Softwarekomponente ist in einem digitalen Zertifikat bereitgestellt, das von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde. Bei der Zertifizierungsstelle kann es sich um den Plattformhersteller, den Plattformnutzer und/oder einen Softwareanbieter handeln. Das Zertifikat muss nicht in einem geschützten Speicher vorgehalten werden, da seine Authentizität und Integrität durch die enthaltenen digitale Signatur σpk sichergestellt wird. Bevor die initiale Komponente E0 die Ausführung an E1' übergibt, überprüft sie die Integrität von E1'. Auch hier misst E0 die Binärdateien von E1' und vergleicht M(E1') mit dem Referenzmesswert M(E1) von E1', der im Zertifikat enthalten ist. Die Echtheit des Referenzmesswerts selbst wird überprüft, indem das Zertifikat mit dem authentischen öffentlichen Signaturschlüssel pk der signierenden Stelle verifiziert wird.
Bei der Aktualisierung einer Komponente En muss ein neues Zertifikat für die Version von En ausgestellt und auf der Plattform gespeichert werden. Da das Zertifikat mit demselben öffentlichen Signaturschlüssel pk validiert werden kann, müssen weder die Entität E0 noch der geschützte Speicher, der pk enthält, aktualisiert werden. Da E0 und pk während der Lebensdauer der Plattform selten oder gar nicht aktualisiert werden müssen, kann ein einfacher hardwarebasierter Schutz wie ROM verwendet werden, um ihre Integrität und Authentizität zu schützen.
Revocation
In Secure-Boot-Systemen kann ein Widerruf (Revocation) erforderlich sein, da entweder eine Entität En nicht mehr vertrauenswürdig ist und nicht mehr ausgeführt werden darf, z.B. weil eine Schwachstelle in ihrem Code entdeckt wurde und eine aktualisierte Version En* veröffentlicht wurde, oder weil ein Signaturschlüssel, der zur Authentifizierung von Code-Zertifikaten verwendet wird, kompromittiert wurde.
Im ersten Fall muss der Referenzmesswert M(E1) zurückgezogen und durch einen aktualisierten Wert M(E1*) ersetzt werden. Je nach der verwendeten Secure-Boot-Variante erfordert dies die Aktualisierung der Vorgängerkomponenten von E1 mit einem aktualisierten eingebetteten Referenzmesswert (M(E1*)), die Aktualisierung der zentralen Referenzmesswertdatenbank oder die Erstellung eines neuen Zertifikats für M(E1*). Bei allen Varianten muss die Authentizität der Aktualisierungen gewährleistet sein.
Im zweiten Fall muss das Secure-Boot-System erfahren, dass der kompromittierte Schlüssel die Integrität einer Entität En oder die Authentizität und Integrität anderer Schlüssel nicht mehr gewährleisten kann, z. B. falls ein Public Key Infrastructure (PKI) im sicheren Boot-System verwendet wird.
In allen Fällen muss die Widerrufsinformation dem Secure-Boot-System zur Verfügung gestellt werden. Wenn ein Gerät nicht kompromittiert ist, kann es die aktualisierten Informationen über das Netz abrufen, z.B. in Form einer Revokationsliste (Englisch Certificate Revocation List; abgekürzt CRL), um Zertifikate zu widerrufen. Ein Gerät unter der Kontrolle eines Angreifers, z.B. ein Gerät, auf dem der Angreifer eine Schwachstelle in einer Entität Ei ausgenutzt hat, wird die Widerrufsinformationen nicht freiwillig aktualisieren. In diesen Fällen muss die Aktualisierung erzwungen werden, z. B. können Zertifikate mit einem Verfallsdatum ausgestellt werden, das eine Aktualisierung nach Ablauf der Gültigkeitsdauer des Zertifikats erforderlich macht. Diese Lösungen setzen jedoch voraus, dass das Secure-Boot-System aktualisierte Informationen erhalten kann, etwa über das Netzwerk. Um Angriffe wie Rollback-Angriffe zu verhindern, müssen Geräte bei diesem Ansatz außerdem die neuesten Widerrufsinformationen sicher speichern oder die Versionsinformationen mit einem sicheren monotonen Zähler verwalten. Um die Aktualität der Widerrufsrinformationen zu gewährleisten, benötigen die Geräte Zugang zu zuverlässigen Zeitinformationen.
