Städte installieren Überwachungssysteme für die öffentliche Sicherheit und intelligente Transportsysteme sind startbereit für eine Zukunft, in der Autos von alleine fahren oder zumindest von Verkehrssystemen beim Fahren unterstützt werden. Ein elementarer Bestandteil solcher Systeme sind industrielle Computing-Plattformen, die Cloud-Computing unterstützen. Die zentrale Herausforderung bei diesen Systemen stellt die Datensicherheit dar. Der Knackpunkt ist nicht nur der Input und Output im Anwenderbereich, sondern vor allem der Schutz der Low-Level-Betriebssystem-Integrität – einschließlich Boot-Loader und BIOS. Beim Endkunden hat der Besitzer eines Endgeräts, wie zum Beispiel ein Stromanbieter, keine Kontrolle über die physische Sicherheit des Geräts. Dabei stellt sich die Frage, wie bei den zunehmenden Abläufen in der industriellen Cloud, die Sicherheit gewährleistet werden kann.
VPNs und Paketfilterung sind notwendig, erfüllen allerdings nur einen Teil der Sicherheits-Anforderungen. Computing-Plattformen, die an öffentlichen Standorten installiert werden, erfordern zuverlässige Garantien für die physische Sicherheit der Endgeräte.
Das leisten TPMs
Diesen Bedarf erfüllt das Trusted Platform Module, kurz TPM. Das Besondere daran ist, dass es einen Hardware-Standard definiert, der permanent kryptografische Schlüssel in die physische Zusammensetzung eines Geräts integriert. Dadurch ist es möglich, jede Computing-Plattform und jedes Netzwerkgerät mit einer praktisch undurchdringbaren Verschlüsselung sowie AAA-Layern zu versehen. Das sind Sicherheitsprotokolle zur Authentifizierung, Autorisierung und Kontenverwaltung, englisch Authentication, Authorization, Accounting genannt. Diese schützen sowohl die gesamte Software und die Daten, als auch die physische Zusammensetzung eines Geräts, einschließlich Chipset und Peripherie.
Da die Ziffern für jedes Gerät einzigartig sind, ermöglicht das TPM die Integration der niedrigsten Ebenen von Gerätesoftware und Firmware mit physischer Layer-Sicherheit. Dadurch können Plattformen entwickelt werden, die jegliche physische Veränderung oder Interferenz in der normalen Funktion der Geräte erkennen und gegebenenfalls den Notabschaltbefehl geben. Wenn ein Client Zugriff auf eine VPN anfordert, antwortet der Server mittels eines verschlüsselten, asymmetrischen Handshakes, der alle Root-Keys oder Passwörter vor der öffentlichen Einsicht versteckt. Durch diesen Prozess tauschen VPN-Server und Client verschlüsselte Nachrichten aus, die den Client authentifizieren und es dem Server ermöglichen, auf das dezentrale Netzwerk zuzugreifen.
Das TPM erstellt einen spezifischen kryptografischen Schlüssel für jedes individuelle Gerät und zwar hartkodiert innerhalb der Plattform selbst. Geräte können diesen Schlüssel dazu nutzen weitere Schlüssel zu generieren und Hardware-Komponenten innerhalb des Systems zu authentifizieren. Das System kann ein Read-Only-Betriebssystem mit einem sicheren Schlüssel codieren und lokal in einem Hardware-basierten Konfigurations-Register (PCR) speichern. Das Programm erkennt somit jegliche Veränderung am Betriebssystem.
Softwareunterstützung für TPMs gibt es unter anderem von Microsoft und Cisco. Außerdem bieten Open Source Projekte, wie GNU/Linux, zahlreiche Pakete an, die frei angepasst, erweitert und integriert werden können. Diese Systeme ermöglichen dem TPM eine Reihe von Notfall-Sicherheitsmaßnahmen, wie etwa normale, korrigierende Wartung, Alarme und eine komplette Systemabschaltung. Der Nutzer hat somit viele Verwendungsmöglichkeiten, wie Passwortverwaltung, Festplattenverschlüsselung, Binden und Versiegeln einer ganzen Plattform (Hard- und Software), sowie die dezentrale Konfiguration und Verwaltung mittels Masseninstallationssoftware.
Boot-Prozess authentifiziert sich selbst
Es gibt jedoch ein Problem, das TPMs nicht lösen: Die Möglichkeit eines „Man-in-the-Middle-Angriffs“. Bei so einer Attacke wird dem TPM vorgespielt, dass ein lokales Laufwerk oder Speicher-Cache als Boot-Loader dient. Tatsächlich kommt dafür jedoch ein Proxy-Image oder -Cache zum Einsatz. Sobald das Betriebssystem durch das TPM validiert und autorisiert wurde, beginnt der Boot-Loader damit, eben dieses vom Drive-Image zu laden. Wenn es der Angreifer schafft einen Datenlogger in den Prozess einzuklinken, kann er den Schlüssel von der Hardware lösen. Ab diesem Punkt ist die gesamte Plattform angreifbar. Absichern gegen solche Angriffe lässt sich ein System durch einen Boot-Vorgang, der zuerst den Kernel authentifiziert.
Es wurden bereits zahlreiche Designs von Samsung, Windows und einigen anderen großen Herstellern, für sichere Boot-Technologien entwickelt. Die meisten dieser Designs setzen die symmetrische Schlüsseltechnologie ein, um einen Hash zu erstellen, der dann entweder in einem flüchtigen Speicher oder im lokalen Datenspeicher zusammengetragen wird. Diese Methode verhindert allerdings nicht die direkte Manipulation des ganzen Betriebssystem-Images oder den Angriff auf Vektoren, die den flüchtigen Speicher verfälschen oder anderweitig manipulierbar machen. Zusätzlich leiden viele dieser Designs unter einer oder mehreren Schwächen, wie keine randomisierte Ziffer zu integrieren, diese Ziffer in ROM zu speichern und unter einem übermäßig Ressourcen bindenden, mehrstufigen Prozess.
Lösen lässt sich dieses Problem durch die Integration der Ziffer und des Authentifizierungs-Systems, direkt in den Boot-Loader. Ein sicheres Boot-System dieser Art nimmt einen randomisierten kryptografischen Startwert aus dem Kernel der Plattform und hängt ihn mittels bitweiser Operation an den Platz im Kernel, von dem er entnommen wurde.
Nach der Erstellung des Schlüssels, generiert das System mit einem vom TPM oder einem vom Anwender eingegebenen Hauptschlüssel, einen kryptografischen Hash. Von dem Zeitpunkt an nutzt der Boot-Loader, immer wenn das System bootet, seinen lokal gespeicherten Chiffrierschlüssel zur Entschlüsselung des Hashs. Außerdem überprüft er damit, wie der Originalschlüssel generiert wurde und danach den Kernel selbst, um sicherzustellen, dass es zu keinen Veränderungen an diesem gekommen ist. Sollte dieser Fall eintreten, schließt das System den Boot-Prozess und verhindert das Booten so lange, bis ein Techniker die Diskrepanz korrigiert hat. Das System ist somit vor Man-in-the-Middle-Angriffen geschützt. Auch wenn ein TPM nicht unbedingt notwendig dafür ist, bietet es eine leistungsfähige Ergänzung des sicheren Boot-Prozesses.
Ein sicherer Boot-Prozess dieser Art kann nur in einem Read-Only-System eingesetzt werden, in dem Kernel und Betriebssystem sich nicht ändern. Gegenüber anderen Systemen besitzt es einige Vorteile. Beispielsweise den Startwert, der auf jeder genutzten Plattform anders ist, was das Erkennen des Schlüssels verhindert. Er ist auch vor Hackern, die über den Root-Key verfügen und ihre eigenen Schlüssel generieren, geschützt. Für einen solchen Angriff müssten sie feststellen, welcher Teil des Kernels genau genutzt wurde, um den Startschlüssel zu generieren. Das ist praktisch unmöglich.
Außerdem wird diese Herangehensweise, innerhalb des Boot-Sektors der Plattform, komplett vom Boot-Loader gehandhabt. Dieser benötigt sowohl den flüchtigen Speicher nicht, als auch keine Speicherung von Dateien im lokalen Datenspeicher. Der Einsatz eines Read-Only-Systems ist außerdem eine ökonomische Lösung in Bezug auf Ressourcennutzung, Geschwindigkeit und Komplexität.
Gegen Input abschotten
Eine der wichtigsten Funktionen eines Embedded-Computing-Geräts ist seine mögliche Sperrung für jede Art von Eingabeschnittstellen. Das heißt, alle Konsolen- und USB-Schnittstellen müssen abschaltbar sein, damit sie nicht für Virusinfektionen oder Cracking-Versuche genutzt werden können. Durch eine Risk-Plattform, die ein TPM nutzt, besteht eine starke Verschlüsselung, die VPN Tunneling und eine volle Schnittstellenkontrolle bietet. In vielerlei dezentrale oder Cloud-Anwendungen kann ein Computer mit entsprechend entwickelter Sicherheit eingesetzt werden. Sämtliche Funktionen sind in Moxas UC-8100, einer kompakten, leistungsfähigen Embedded-Computing-Plattform, für verteilte Anwendungen, vereint.
