Manchmal schaue ich mich nach einem Thema um, über das ich schreiben kann, und stelle fest, dass es eines gibt, von dem ich annehme, dass ich es behandelt habe, aber beim Suchen entdecke, dass ich es nicht getan habe. Eines dieser Themen ist der gemessene Start und der vertrauenswürdige Start, der manchmal irreführend als "sicherer Start" bezeichnet wird. Es gibt bestimmte Verfahren, die diese Begriffe mit Großbuchstaben verwenden (z. B. Secure Boot), die ich in diesem Artikel zu vermeiden versuche. Ich interessiere mich mehr für die generischen Prozesse – und einen großen potenziellen Untergang – als für den Versuch, auf Einzelheiten einzugehen. Was folgt, ist ein (stark bearbeiteter) Auszug aus meinem in Kürze erscheinenden Buch über Vertrauen in die Datenverarbeitung und die Cloud für Wiley.
Weitere Linux-Ressourcen
- Spickzettel für Linux-Befehle
- Spickzettel für fortgeschrittene Linux-Befehle
- Kostenloser Online-Kurs:RHEL Technical Overview
- Spickzettel für Linux-Netzwerke
- SELinux-Spickzettel
- Spickzettel für allgemeine Linux-Befehle
- Was sind Linux-Container?
- Unsere neuesten Linux-Artikel
Um zu verstehen, was mit dem gemessenen Booten und dem vertrauenswürdigen Booten erreicht werden soll, sehen Sie sich den Linux-Virtualisierungsstapel an:die Komponenten, die Sie ausführen, wenn Sie virtuelle Maschinen (VMs) auf einer Linux-Maschine verwenden möchten. Diese Beschreibung ist wohl zu stark vereinfacht, aber (wie ich oben angemerkt habe) interessieren mich nicht die Einzelheiten, sondern das, was ich zu erreichen versuche. Ich werde mich auf die unteren vier Schichten konzentrieren (auf einer ziemlich einfachen Abstraktionsebene):CPU/Management-Engine; BIOS/EFI; Firmware; und Hypervisor, aber ich denke auch nur an eine Ebene über der CPU/Verwaltungs-Engine, die ein Trusted Platform Module (TPM) und einige Anweisungen zur Durchführung eines der beiden Prozesse (gemessener Start) zwischenschaltet und Trusted Boot ). Sobald das System zu booten beginnt, wird das TPM ausgelöst und nimmt seine Arbeit auf. Alternative Roots of Trust, wie z. B. Hardware-Sicherheitsmodule (HSMs), könnten ebenfalls verwendet werden, aber ich werde in meinem Beispiel TPMs verwenden, das häufigste Beispiel in diesem Zusammenhang.
In beiden Fällen (vertrauenswürdiger Start und gemessener Start) beginnt der grundlegende Ablauf damit, dass das TPM eine Messung der BIOS/EFI-Schicht durchführt. Bei dieser Messung werden die von dieser Schicht auszuführenden binären Anweisungen überprüft und ein kryptografischer Hash des binären Abbilds erstellt. Der erzeugte Hash wird dann in einem von mehreren „Slots“ des Platform Configuration Register (PCR) im TPM gespeichert. Diese können als Speicherstücke betrachtet werden, die später gelesen werden können – entweder durch das TPM für seine Zwecke oder durch Entitäten außerhalb des TPM – aber die nicht mehr geändert werden können, sobald sie geschrieben wurden. Diese Speicherstücke sind von dem Zeitpunkt an, an dem sie ursprünglich geschrieben wurden, integritätsgeschützt. Dadurch wird sichergestellt, dass ein einmal vom TPM in einen PCR geschriebener Wert für die Lebensdauer des Systems bis zum Ausschalten oder Neustart als konstant angesehen werden kann.
Nach der Messung der BIOS/EFI-Schicht wird die nächste Schicht (Firmware) gemessen. In diesem Fall wird der resultierende Hash mit dem vorherigen Hash (der im PCR-Slot gespeichert wurde) kombiniert und dann ebenfalls in einem PCR-Slot gespeichert. Der Prozess wird fortgesetzt, bis alle am Prozess beteiligten Schichten gemessen und die Ergebnisse der Hashes gespeichert wurden. Es gibt (manchmal recht komplexe) Prozesse, um die ursprünglichen TPM-Werte einzurichten (ich habe der Einfachheit halber einige der untergeordneten Schritte im Prozess übersprungen) und (hoffentlich autorisierte) Änderungen an den Ebenen für Upgrades oder Sicherheitspatches zuzulassen , zum Beispiel. Dieser „gemessene Boot“-Prozess ermöglicht es Entitäten, das TPM nach Abschluss des Prozesses abzufragen und zu prüfen, ob die Werte in den PCR-Slots den erwarteten Werten entsprechen, die mit „bekanntermaßen guten“ Versionen der verschiedenen Schichten vorberechnet wurden – das heißt , vorgeprüfte Versionen, deren Herkunft und Integrität bereits festgestellt wurden.
Es gibt verschiedene Protokolle, um Parteien extern zu erlauben an das System, um die Werte zu überprüfen (z. B. über eine Netzwerkverbindung), die das TPM als korrekt bestätigt:Der Prozess des Empfangens und Überprüfens solcher Werte von einem externen System wird als „Remote-Bestätigung“ bezeichnet.
Mit diesem Prozess – gemessenem Booten – können Sie herausfinden, ob die Grundlagen Ihres Systems – die untersten Schichten – so sind, wie Sie denken. Aber was, wenn sie es nicht sind? Measured boot (was angesichts des Namens nicht überraschend ist) misst, führt aber keine anderen Aktionen aus.
Die Alternative „Trusted Boot“ geht noch einen Schritt weiter. Wenn ein vertrauenswürdiger Boot-Prozess durchgeführt wird, misst der Prozess nicht nur jeden Wert, sondern führt gleichzeitig auch eine Prüfung gegen einen bekannten (und erwarteten!) guten Wert durch. Wenn die Prüfung fehlschlägt, wird der Prozess angehalten und das Booten des Systems schlägt fehl. Das mag nach einem ziemlich extremen Ansatz klingen, ein System anzugehen, aber manchmal ist es absolut der richtige. Wenn das betreffende System möglicherweise kompromittiert wurde – was eine wahrscheinliche Schlussfolgerung ist, die Sie aus dem Scheitern eines vertrauenswürdigen Boot-Prozesses ziehen können –, ist es besser, wenn es überhaupt nicht verfügbar ist, als dass es aufgrund fehlerhafter Erwartungen ausgeführt wird.
Das ist alles sehr gut, wenn ich der Besitzer des zu messenden Systems bin, alle verschiedenen zu messenden Komponenten (und die Messungen) überprüft habe und froh bin, dass das, was gebootet wird, meinen Wünschen entspricht. Aber was ist, wenn ich zum Beispiel ein System in der Cloud verwende oder ein System, das jemand anderem gehört und von ihm verwaltet wird? In diesem Fall vertraue ich dem Cloud-Anbieter (oder Eigentümer/Manager) zwei Dinge:
- Alle Messungen korrekt durchführen und mir korrekte Ergebnisse melden
- Etwas aufbauen, dem ich von vornherein vertrauen sollte
Das ist das Problem mit der Nomenklatur „Trusted Boot“ und, noch schlimmer, „Secure Boot“. Beide implizieren, dass eine absolute, objektive Eigenschaft eines Systems festgestellt wurde – es ist „vertrauenswürdig“ oder „sicher“ – wenn dies eindeutig nicht der Fall ist. Offensichtlich wäre es unfair, von den Designern solcher Prozesse zu erwarten, sie nach den Fehlerzuständen zu benennen – „nicht vertrauenswürdiger Start“ oder „unsicherer Start“ –, aber es sei denn, ich kann mir sehr sicher sein, dass ich dem Eigentümer des Systems vertraue, dass er diesen Schritt ausführt zwei völlig richtig (und in meinem besten Interesse als Benutzer des Systems und nicht in ihrem als Eigentümer), dann kann ich keine stärkeren Behauptungen aufstellen.
Es besteht eine enorme Versuchung, ein System zu nehmen, das einen vertrauenswürdigen Boot-Prozess durchlaufen hat, und es als „vertrauenswürdiges System“ zu bezeichnen, wenn es das Allerbeste ist Behauptung, die Sie machen können, ist, dass die bestimmten Schichten, die im gemessenen und/oder vertrauenswürdigen Startprozess gemessen wurden, als diejenigen bestätigt wurden, die der Prozess erwartet. Ein solcher Prozess sagt überhaupt nichts über die Eignung der Schichten aus, Verhaltenszusicherungen zu liefern, noch über die Korrektheit (oder Eignung, Verhaltenszusicherungen zu liefern) aller darauf folgenden Schichten.
Es ist wichtig zu beachten, dass Entwickler von TPMs ziemlich klar sind, was behauptet wird, und dass Behauptungen über Vertrauen sorgfältig und sparsam gemacht werden sollten. Unglücklicherweise machen es die Komplexität von Systemen, das allgemein geringe Verständnis von Vertrauen und die Komplexität von Kontext und transitivem Vertrauen Systementwicklern und -implementierern sehr leicht, das Falsche zu tun und anzunehmen, dass jedes System, das erfolgreich eine Leistung erbracht hat, a Der vertrauenswürdige Boot-Prozess kann als „vertrauenswürdig“ betrachtet werden. Es ist auch äußerst wichtig, sich daran zu erinnern, dass TPMs als Hardware-Vertrauenswurzeln einen der besten verfügbaren Mechanismen zum Aufbau einer Vertrauenskette in Systemen bieten, die Sie möglicherweise entwerfen oder implementieren, und ich plane, bald einen Artikel darüber zu schreiben.
- Obwohl sich das als viel herausstellt schwieriger als erwartet!
Dieser Artikel wurde ursprünglich auf Alice, Eve, and Bob veröffentlicht und wird mit Genehmigung des Autors nachgedruckt.