Hintergrund

Firmware ist eine spezielle Art von Software, die hauptsächlich für die Steuerung und Kommunikation der zugrunde liegenden Hardware verwendet wird. Der Umfang der Firmware ist zu breit, verschiedene Bereiche der Firmware, die an Sicherheitsproblemen beteiligt sind, variieren stark. In diesem Artikel wird nur die Firmware beschrieben, die auf allgemeinen Computern wie Servern, Notebooks und Desktops ausgeführt wird.

Das aktuelle Problem

UEFI ist derzeit noch die Mainstream-Firmware-Lösung. Es gibt mehrere Probleme im UEFI-Ökosystem:

• Das Design der technischen Architektur berücksichtigt nicht die [komplexe Lieferkette] (https://hardwear.io/netherlands-2019/presentation/roots-of-trust-attestation-keynote-talk-hardwear-io-nl-2019.pdf), während sich die Referenzimplementierung von tianocore/EDK2 stark von der OEM-Fabrikimplementierung unterscheidet. Es ist nicht schwer herauszufinden, dass eine Reihe von SMM-basierten Funktionen in einigen OEM-Firmware durch Reverse Engineering und Tests implementiert wurden. SMM ist eine der risikoreichen Angriffsflächen in x86, da das Privileg seines Laufmodus, auch bekannt als “Ring -2”, sogar höher ist als “RING 0”. Dies ist der Hauptgrund, warum das Betriebssystem Schwierigkeiten hat, Bedrohungen unterhalb von Ring 0 zu erkennen.

• Die Fehler des Designs und der Implementierung führen zu einer Reihe von Firmware-Sicherheitsrisiken:

Die lange Lieferkette verlängert den Bugfix-Zyklus. Noch wichtiger ist, dass die Verzögerungen oder die Weigerung, bekannte Schwachstellen zu beheben, das Risiko für die Produktionsumgebung des Benutzers erhöhen.

• Nicht überprüfbar, die meisten OEM-Anbieter stellen den Benutzern keinen Quellcode der Firmware zur Verfügung. Das Audit auf Quellcode-Ebene ist nicht durchführbar. Vulnerablity Audit kann sich nur auf binäres Audit oder Fuzzer verlassen. Die Kosten für Audit auf Backdoor- oder Debug-Funktionen sind ohne Quellcode extrem hoch. Während Intel versucht, die Offenheit mit der Mindestplattform im Jahr 2019 anzugehen, lief die Abdeckung nicht wie erwartet.

‘‘Next-Gen’’’-Firmware

Im Winter 1999 startete Ron Minnich, ein Forscher am Los Alamos National Laboratory, ein Projekt namens [LinuxBIOS] (https://coreboot.org/images/5/5c/The_real_linuxbios.pdf), das entwickelt wurde, um proprietäre Firmware durch freie Software zu ersetzen, mit der philosophischen Idee, so wenig Code wie möglich in der Phase der Hardware-Initialisierung zu haben und eine Linux-basierte Nutzlast zu laden, um sich um den Rest zu kümmern, wenn die Hardware-Initialisierung abgeschlossen war. LinuxBIOS wurde später in coreboot umbenannt. Der heutige Coreboot unterstützt eine breite Palette von anderen Nutzlasten als Linux, und diese Architektur ist eine wichtige Grundlage für die Branche in den 2020er Jahren, da sie Firmware-Probleme erneut aufgreift und die Firmware der “nächsten Generation” untersucht, möglicherweise aufgrund von Unvermeidbarkeit und Wahrscheinlichkeit.

Die Branche hat seit den 2010er Jahren begonnen, verschiedene Firmware-Sicherheitsoptionen zu erkunden. Eine der Verified Boot-Lösungen von UEFI, auch bekannt als “Secure Boot”, die eine Vertrauenskette zur Validierung von Signaturen aufbaut, die im Marketing weit verbreitet ist. Eine weitere Option ist MeasuredBoot, aber es ist nicht als “Secure Boot” bekannt. Da nur eine begrenzte Anzahl von Chipsätzen TXT (wenn der Benutzer DRTM verwenden möchte) und andere Funktionen unter TCG-Spezifikation unterstützen, ist es schwierig, sie in UEFI zu implementieren. Im Jahr 2016 griff Trammell Hudson, ein Forscher beim Hedgefonds Two Sigma, auf die Philosophie von LinuxBIOS zurück, eine Linux-basierte Nutzlast namens [heads] (https://github.com/osresearch/heads) zu entwickeln, die über mehrere Sicherheitsfunktionen verfügt, darunter [measured boot] (https://media.ccc.de/v/33c3-8314-bootstraping_a_slightly_more_secure_laptop) und das Laden mit coreboot. Dies löst das Problem, das das UEFI-Ökosystem seit mehreren Jahren zu niedrigen Kosten zu lösen versucht, und die Branche baut weiterhin auf der 1999er Version der “Next Generation Firmware” -Architektur auf. Im Jahr 2017 entwickelten Google und die Heads-Community gemeinsam eine Nutzlast namens [NERF] (https://www.elinux.org/images/6/69/ELC_2FOCP_2FCEA_Oct._2017_NERF.pdf), die einen Modus zur Beibehaltung von PEI und zur Minimierung von DXE verwendet, um OEM-kompatibel mit UEFI-Firmware zu sein, aber es funktionierte nicht auf einigen Maschinenmodellen aufgrund von Umzugsproblemen. Ein weiteres Merkmal von NERF ist, dass das Userland auf Go Runtime basiert, und interessanterweise versucht NERF’s, Linux-basierte Nutzlastschemata auf eine standardisiertere Stufe zu bringen: LinuxBoot.

Wie Sie aus der obigen Abbildung ersehen können. LinuxBoot, die “Next-Generation-Firmware” -Architektur, ist immer noch nicht über die philosophische Idee des LinuxBIOS von 1999 hinaus, aber sein Ziel ist es, mehr Hardware-Initialisierungs-Firmware-Lösungen zu unterstützen.

VaultBoot: Das Herz von Gondor

VaultBoot ist eine Firmware-Payload, die sich stark auf Firmware-Sicherheit, Trusted Computing und erweiterten Schutz vor Bedrohungen konzentriert. VaultBoot kann die größten Vorteile bringen, wenn es mit Coreboot zusammenarbeitet, das in der Bereitstellungsphase von CBnT und anderen Tonnen von ACMs zusammenarbeitet.

VaultBoot ist auch mit der UEFI-Firmware des OEM kompatibel. HardenedVault ist ein langfristiger Mitwirkender in der Heads-Community. Die öffentliche Version von VaultBoot basiert also auf Heads, aber VaultBoot ist auch mit LinuxBoot kompatibel und bietet sowohl C- als auch Go-Laufzeitumgebungen.

Die wichtigsten Funktionen von VaultBoot:

• Verifizierter Start. Diese Funktion, die im UEFI-Kreis auch als Secure Boot bezeichnet wird, bedeutet, dass nur signierter Kernel sowie zugehörige Daten (z. B. initrd) geladen werden können, um im normalen Bootvorgang zu booten. Im UEFI-Kreis sollte die Signatur in derselben Datei des Kernels gespeichert werden, daher wird ein dediziertes Tool benötigt, und der Signaturprozess ist schwer zu bedienen. In Vaultboot wird der Signaturüberprüfungsprozess vom mitgelieferten gnupg-Tool durchgeführt. Ein dedizierter gnupg-Schlüsselbund, der die öffentlichen Schlüssel enthält, könnte in seinem Initrd gebündelt werden. Der Kernel, initrd und die Boot-Konfiguration des Betriebssystems würden durch den entsprechenden privaten Schlüssel in einer Smartcard gespeichert, und die Signatur würde in der Boot-Partition als separate Datei gespeichert werden, und die folgenden Signaturprozesse könnten im Betriebssystem durchgeführt werden, ohne die Kernel-Datei selbst zu ändern. Wenn die Signatur ungültig wird, wird der automatisierte Bootvorgang unterbrochen, und Vaultboot stellt eine Wiederherstellungsshell bereit, in der der Administrator das Betriebssystem manuell booten oder die Signaturkette reparieren kann.

• Gemessener Start. Wenn das Mainboard mit einem TPM ausgestattet ist, könnte Coreboot auch gebaut werden, um alle Komponenten zu messen, die es lädt (einschließlich der Nutzlast). Vaultboot kann auch mit TPM-Funktion (1 oder 2) erstellt werden. Wenn dies der Fall ist, kann es ein zufälliges Geheimnis in das TPM einschließen, gegen die PCRs, die Coreboot verwendet, um sich selbst zu messen, und das zufällige Geheimnis als TOTP im Boot-Prozess darstellen, damit der Administrator es überprüfen kann. Wenn die Firmware geändert wird, ändern sich die PCRs, und das vom Administrator verifizierte versiegelte Geheimnis kann nicht mehr aus dem TPM entsiegelt werden, um den Administrator vor unbeabsichtigten Änderungen der Firmware zu warnen. Dies könnte eine Form der lokalen Beglaubigung sein. Wenn die Überprüfung des TOTP im Bootvorgang unpraktisch ist, kann eine Remote-Bescheinigung verwendet werden. Wenn der geheime Schlüssel nicht entsiegelt werden konnte, wird der automatisierte Startvorgang unterbrochen, und es wird eine Wiederherstellungsshell bereitgestellt.

• Vault_SMM. Dies ist der einzigartige Härtungsmodus, der von HardenedVault entwickelt wurde und die Aktivierung von Härtungsfunktionen, die vom Chipsatz für die Nutzlaststufe bereitgestellt werden, verzögert, und VaultBoot verwendet SMM, um die Operationen auszuführen. Es gewährleistet Sicherheit und berücksichtigt gleichzeitig die Wartbarkeit und dieses Design, das von den Gründern von LinuxBIOS im Jahr 2019 unterstützt wurde. VaultBoot verwendet das SMM als Hochrisiko-Privilegierungsmodus nur zur Sicherheitshärtung, aber es ist erwähnenswert, dass diese Lösung mit Coreboot funktionieren muss, um sie zu nutzen.

• TPM-basierte FDE (Full-Disk Encryption). Wenn TPM verfügbar ist und das Betriebssystem während des Startvorgangs über ein LUKS zum Entsperren verfügt, kann Vaultboot dem LUKS einen zufälligen Schlüssel hinzufügen und den Schlüssel im TPM versiegeln (mit oder ohne Passphrase). Wenn der Schlüssel erfolgreich entsiegelt werden konnte, kopiert Vaultboot die initrd des Betriebssystems in sein tmpfs, hängt den Schlüssel und ein crypttab-Element an die kopierte initrd an und bootet das Betriebssystem mit der geänderten initrd, so dass das LUKS während des Startvorgangs durch den Schlüssel entsperrt wird. Nach dem Hinzufügen des Schlüssels wird der LUKS-Header in eine PCR vermessen, die eine der PCRs ist, gegen die der Entriegelungsschlüssel versiegelt ist. Wenn also die Firmware oder der LUKS-Header geändert wird, wird der Schlüssel nicht mehr entsiegelt und der automatisierte Bootvorgang wird unterbrochen. Natürlich, wenn die Firmware aktualisiert wird und / oder der LUKS-Header vom Benutzer absichtlich geändert wird, könnte ein neuer Schlüssel für das LUKS generiert und versiegelt werden, wenn es andere Möglichkeiten gibt, das LUKS zu entsperren, um den neuen Schlüssel hinzuzufügen.

• Parameterverschlüsselung über hardwareintegrierten Schlüsselaustausch. In TPMv2 wird ein neues Feature eingeführt, um die vertraulichen Parameter (z. B. den Klartext zum Versiegeln/Entsiegeln) mit einem Sitzungsschlüssel zu verschlüsseln, der mit in TPM generierten Schlüsseln ausgetauscht wird. Vaultboot nutzt diese Funktion, um physische Angriffe wie TPM Genie abzuwehren.

• Intel CSME. Es hängt vom Anwendungsfall ab. Für weitere Details lesen Sie bitte unseren Studienbericht.

Conclusion

Die Firmware läuft auf einer höheren Stufe als RING 0, wo sich das Betriebssystem befindet. Wenn das Bedrohungsmodell des Benutzers die Persistenz des Angreifers enthält, kann die Firmware-Sicherheit nicht ignoriert werden. Sowohl die unsinnige als auch die defensive Seite in diesem Bereich erhalten zunehmend die Aufmerksamkeit der Industrie. Das National Institute of Standards and Technology (NIST) hat 4 Sonderpublikationen zur Firmware-Sicherheit herausgegeben:

• NIST SP 800-147: BIOS Protection Guide, April 2011
• NIST SP 800-155: BIOS Integrity Measurement Guide, December 2011
• NIST SP 800-147B: Server BIOS Protection Guide, August 2014
• NIST SP 800-193: BIOS Platform Firmware Resilience Guide, May 2018

On May 26, 2021, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) unveiled the VBOS (Vulnerablity below the OS program at the RSA 2021 conference, which aims to protect the security of both operating systems and lower-level components, even though the confrontations at firmware level have never stopped in past 15 years. The VBOS program drag the covert warfare out on the table now. Although there are no systematic firmware security compliance guidelines in EU like those in the United States. But European Commission has funded a large number of open source chip and firmware security projects via Horizon 2020 which was launched in 2014. The German Federal Office for Information Security (BSI) has repeatedly publicly mentioned support and follow-up work for open source firmware. In 2019, BSI certified the network security products of genua GmbH, a German security vendor (no. BSI-DSZ-CC-1085-2019), to support open firmware system.

Am 26. Mai 2021 stellte die US-amerikanische Cybersecurity and Infrastructure Security Agency (CISA) auf der RSA 2021-Konferenz das Programm VBOS (Vulnerablity below the OS vor, das darauf abzielt, die Sicherheit sowohl von Betriebssystemen als auch von Komponenten auf niedrigerer Ebene zu schützen, auch wenn die Konfrontationen bei Das Firmware-Niveau hat in den letzten 15 Jahren nie aufgehört. Das VBOS-Programm zieht die verdeckte Kriegsführung jetzt auf den Tisch. Obwohl es in der EU keine systematischen Richtlinien zur Einhaltung der Firmware-Sicherheit wie in den Vereinigten Staaten gibt. Die Europäische Kommission hat jedoch eine große Anzahl von Open-Source-Chip- und Firmware-Sicherheitsprojekten über Horizon 2020 finanziert, das 2014 gestartet wurde. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat wiederholt öffentlich von Unterstützung und Folgearbeiten für Open-Source-Firmware gesprochen. Im Jahr 2019 zertifizierte das BSI die Netzwerksicherheitsprodukte der genua GmbH, einem deutschen Sicherheitsanbieter (Nr. BSI-DSZ-CC-1085-2019), für die Unterstützung eines offenen Firmware-Systems.

Im globalen Trend des Advanced Threat Protection ist Firmware einer der Kerne der allgemeinen Verteidigung. VaultBoot hat eine Reihe von Sicherheitsfunktionen entwickelt, die auf den aktuellen Angriffsflächen basieren. HardenedVault bietet derzeit eine Sicherheits-Firmware-Lösung für die KabyLake / CoffeeLake-Serverplattform für x86 an und die Unterstützung von arm64 sollte im Geschäftsjahr 2022 veröffentlicht werden.