Firmware-Sicherheit neu definieren

In einem kürzlich erschienenen Artikel wurde die Bedrohung durch Firmware-basierte Angriffe auf Serverplattformen hervorgehoben und detailliert erläutert, wie ein Service Provider wie Cloudflare seine Plattform verteidigen kann. Es wurde die Implementierung einer Hardware-Vertrauensbasis für die Code-Signierung kritischer Boot-Entitäten diskutiert, die es der Hardware ermöglicht, eine erste Verteidigungslinie zu werden, um sicherzustellen, dass die Serverhardware- und -softwareintegrität Vertrauen durch kryptografische Mittel aufbauen kann – und, was noch wichtiger ist, Kunden vor solchen Angriffen schützt . Der Artikel schloss mit einem Blick in die Zukunft und weist darauf hin, dass die Lösung zwar für die Gegenwart funktioniert, aber im Rahmen der kontinuierlichen Bemühungen um branchenweit beste Sicherheit immer Raum für Verbesserungen gibt.

Dieser Artikel setzt diese Diskussion fort, indem er potenziell nicht adressierte Vektoren betrachtet, die in aktuellen Plattformen inhärent sind, und eine Vorschau auf eine optimale Lösung zur Verhinderung von Firmware-Angriffen und zur Erhöhung der Plattformsicherheit auf der Grundlage des Trusted Control/Compute Unit (TCU)-Sicherheitsprozessors von Axiado bietet.

Vertrauen in Firmware verwurzeln

Das Kernproblem ist die implizite Annahme der Sicherheit der Root of Trust (RoT) in der Bootkette. An der Unified Extensible Firmware Interface (UEFI)-Firmware befindet sich die Annahme, dass das RoT kein potenzielles Angriffsziel ist. Diese Annahme hat sich als gefährlich erwiesen, wie die Zunahme von Firmware-basierten Angriffen im Laufe der Jahre zeigt und sich 2019 im Vergleich zu 2010 mehr als verzehnfacht hat. Hacker haben schnell erkannt, dass durch die Beschädigung dieser Firmware das Trusted Platform Module (TPM) Messungen für Remote-Bestätigungszwecke könnten ebenfalls verfälscht werden, da die Messungen auf der Interaktion mit der Firmware beruhen, um solche Messungen zu validieren (sie wird nicht umsonst „Root of Trust“ genannt). Um die Plattformintegrität zu gewährleisten, ist es zwingend erforderlich, dass die UEFI-Firmware selbst authentifiziert wird, d. h. beim RoT wird eine Richtlinie von Zero Trust erlassen.

Erste Lösung

Um dieses Problem zu beheben, haben Unternehmen den wichtigen Schritt unternommen, die UEFI-Firmware in ihren Servern mit Cloudflare unter Verwendung des AMD EPYC-Prozessors zu authentifizieren, der diese Authentifizierung unterstützt. Das Hardware-Sicherheits-Subsystem von EPYC namens AMD Secure Processor führt eine Funktion namens Platform Secure Boot (PSB) aus, die den ersten Block von UEFI authentifiziert, bevor die Haupt-CPU vom Reset freigegeben wird. PSB ist AMDs Implementierung der hardwarebasierten Boot-Integrität. Es ist besser als eine auf UEFI-Firmware basierende Vertrauenswürdigkeit, da sie durch eine in der Hardware verankerte Vertrauensbasis die Integrität und Authentizität des System-ROM-Image bestätigen soll, bevor es ausgeführt werden kann. Dazu führt es die folgenden Aktionen aus:

• Authentifiziert den ersten Block von BIOS/UEFI, bevor x86-CPUs vom Reset freigegeben werden.
• Authentifiziert den ROM-Inhalt des Systems bei jedem Start, nicht nur bei Updates.
• Verschiebt die UEFI Secure Boot Trust Chain auf unveränderliche Hardware.

Dies wird durch den AMD Platform Security Processor (PSP) erreicht, einen ARM Cortex-A5-Mikrocontroller, der ein unveränderlicher Teil des System-on-Chip (SoC) ist.

Mit diesem Ansatz hat Cloudflare eine Lösung ermöglicht, die die Authentifizierungsanforderungen der UEFI-Firmware zu erfüllen scheint.

Probleme mit UEFI Secure Boot

Nicht authentifizierte Controller

Eine gängige Komponente, die sich auf fast jedem Server befindet, ist ein Baseboard Management Controller (BMC). BMCs haben mehrere Verbindungen zum Hostsystem und bieten die Möglichkeit, Hardware zu überwachen, BIOS/UEFI-Firmware zu aktualisieren, Konsolenzugriff über serielle oder physische/virtuelle KVM zu gewähren, die Server aus- und wieder einzuschalten und Ereignisse zu protokollieren.

Als Teil der Boot-Kette adressiert die aktuelle PSB-Signiermethode nicht das Signieren des BMC, was die Erweiterung der Vertrauensgrenze auf einen Controller mit vielen Schnittstellen zu Systemkomponenten einschränkt.

Booten mit einer plattformspezifischen CPU

Die Integration der UEFI-Firmware-Authentifizierung in einen Block, der in die Haupt-CPU eines Servers integriert ist, führt zu logistischen Problemen im Bereich der Lagerhaltungseinheit (SKU)-Verwaltung. Ein solches Problem besteht darin, eine CPU an eine bestimmte Plattform zu sperren. Mit der UEFI-Authentifizierung und den zugehörigen kryptografischen Schlüsseln, die sowohl an den Code im integrierten Boot-Flash als auch an die AMD EPYC-CPU gebunden sind, müssen alle auf der Plattform vorhanden sein, damit der Server ordnungsgemäß booten kann. Dies schränkt jedoch die Möglichkeit ein, eine CPU auf diesem Motherboard zu aktualisieren oder zu ändern. Dieser Nebeneffekt wurde im Value-Added-Reseller-Markt beobachtet, da EPYC-Geräte, die die PSB-Funktion verwenden, nicht ausgetauscht werden können. Einige Unternehmen (wie HPE) haben diese Einschränkung erkannt und die PSB-Funktion in ihren EPYC-basierten Servern deaktiviert und sich stattdessen dafür entschieden, ihre UEFI-Firmware extern mit ihrer internen Siliziumlösung zu authentifizieren.

Axiado ist der Ansicht, dass ein externer Coprozessor, der die UEFI-Firmware-Authentifizierung handhabt und gleichzeitig CPU-Flexibilität ermöglicht, ideal für die gesamte Branche ist.

Herausforderungen mit mehreren Plattformen

Ein weiteres Problem im Zusammenhang mit der SKU-Verwaltung betrifft die Verwaltung von Plattformen mit potenziell mehreren sicheren Startmethoden. Eine Bereitstellung von Servern in einem Rechenzentrum kann eine Mischung aus Prozessoren wie Intel, AMD und Arm umfassen, die jeweils ihre Richtung zur Implementierung der UEFI-Firmware-Authentifizierung haben. Dieses Szenario kann zu einer übermäßigen Belastung bei der Verwaltung unterschiedlicher selbst entwickelter Secure-Boot-/Root-of-Trust-Methoden von jedem CPU-Anbieter führen.

Daher ist ein externer Coprozessor für die Handhabung der UEFI-Firmware-Authentifizierung mit CPU-Flexibilität ideal für die gesamte Branche.

Eine potenzielle zentrale Anlaufstelle für optimale Firmware-Sicherheit?

Eine Lösung, die einen One-Stop-Shop für Sicherheitsanforderungen ermöglicht und gleichzeitig die Firmware-Sicherheit verbessert und der Stückliste keine Komponenten hinzufügt, ist der Trusted Control/Compute Unit (TCU) Coprozessor von Axiado. Dies bietet erstklassige UEFI-Firmware-Authentifizierung für eine einheitliche sichere Boot-Lösung für alle SKUs, unabhängig von der Wahl des Unternehmens als Haupt-CPU-Anbieter, und das alles ohne Hinzufügen von Komponenten zur Plattform.

Als Coprozessor in einem Server übernimmt Axiado TCU die Rolle des Baseboard Management Controller (BMC)-Chips, sodass für dieses Gerät kein zusätzlicher Speicherplatz auf dem Server benötigt wird. Die TCU ist für die Attestierung aller Komponenten des Systems, einschließlich ihrer selbst, verantwortlich. Es bietet eine attraktive Lösung zur Komponentenkonsolidierung, indem es alle von einem BMC-Gerät erwarteten Legacy-Funktionen unterstützt und zusätzliche Funktionen enthält, die es der TCU ermöglichen, die Rolle des Trusted Platform Module (TPM) und des komplexen programmierbaren Logikbausteins (CPLD) auf Servern zu übernehmen.

Das Herzstück der TCU ist die patentierte Secure Vault-Technologie von Axiado, die manipulationssichere, unveränderliche hardwarebasierte UEFI-Firmware-Authentifizierung und sicheres Booten bietet. Diese Technologie umfasst unter anderem Schutz gegen differenzielle Leistungsanalyse-Angriffe, die verwendet werden, um kryptografische Schlüssel zurückzuentwickeln, die Hackern Zugriff auf verschlüsselte private Informationen ermöglichen.

Die TCU enthält eine sichere KI-Technologie mit einem dedizierten neuronalen Netzwerkprozessor (NNP)-Subsystem, das das normale Verhalten des Geräts modellieren und so Anomalien identifizieren kann, die auf das Vorhandensein eines Angriffs hinweisen könnten. Auf diese Weise können alle notwendigen Gegenmaßnahmen zum Schutz des Systems vor Angriffen eingeleitet werden, auch vor Angriffen, die nicht offiziell identifiziert wurden. Darüber hinaus verfügt der NNP über Verbindungen zu verschiedenen I/Os des Geräts, sodass er das normale Verhalten modellieren und Anomalien der Serverplattform insgesamt erkennen kann, wodurch der Schutzradius der TCU gegen Hackerversuche erweitert wird.

Durch das Angebot einer Sicherheits-Coprozessorlösung löst Axiado die in diesem Artikel vorgestellten Probleme in Bezug auf SKU-Angebote. Erstens minimiert eine einzige Lösung die Anzahl der Angriffsflächen, die Hacker versuchen können, über eine gesamte SKU-Reihe hinweg auszunutzen. Vor Angriffen auf die Sicherheitslösungen von AMD, Intel, Arm und anderen Anbietern muss man sich nicht schützen. Dies vereinfacht auch die Verwaltung und Wartung von Server-SKU-Bereitstellungen und minimiert die Anzahl der Plattform-Software-/Firmware-Update-Varianten. Zweitens ist die CPU durch das Auslagern des sicheren Boot-Subsystems auf die TCU nicht mehr an die spezifische Serverhardware gebunden. Es steht Ihnen dann frei, CPUs über verschiedene Hardwarevarianten hinweg zu kombinieren und Upgrades durchzuführen, ohne die CPU für die spezifische Hardware konfigurieren zu müssen, auf der sie installiert ist.

Zusammenfassend bietet der TCU-Coprozessor eine einheitliche und sichere hardwarebasierte UEFI-Firmware-Schutzlösung für alle seine Plattformen mit der Fähigkeit, neue Angriffe zu erlernen, bevor sie überhaupt formal erkannt werden. Dies ermöglicht ein sicheres Netzwerk mit leistungsstarken und funktionsreichen CPU-Subsystemen sowie ein Netzwerk, das einfacher zu verwalten und zu warten ist.