Firmwarebeveiliging opnieuw definiëren

Een recent artikel benadrukte de dreiging van op firmware gebaseerde aanvallen op serverplatforms en legde in detail uit hoe een serviceprovider als Cloudflare zijn platform kan verdedigen. Het besprak de implementatie van een hardware root of trust voor code-signing kritische boot-entiteiten, waardoor de hardware een eerste verdedigingslinie kan worden om ervoor te zorgen dat serverhardware en software-integriteit vertrouwen kan ontlenen door middel van cryptografische middelen - en nog belangrijker, klanten beschermen tegen dergelijke aanvallen . Het artikel werd afgesloten met een blik op de toekomst en gaf aan dat hoewel de oplossing voor het heden werkt, er altijd ruimte is voor verbetering als onderdeel van een voortdurende inspanning om de beste beveiliging in de sector te bieden.

Dit artikel zet deze discussie voort door potentieel ongeadresseerde vectoren te bekijken die inherent zijn aan huidige platforms en een voorbeeld te geven van een optimale oplossing voor het voorkomen van firmware-aanvallen en het naar een hoger niveau tillen van platformbeveiliging, gebaseerd op Axiado's vertrouwde control/compute unit (TCU) beveiligingsprocessor.

Wortel vertrouwen in firmware

Het belangrijkste probleem is de impliciete aanname van de veiligheid van de root of trust (RoT) in de opstartketen. Gelegen op de Unified Extensible Firmware Interface (UEFI)-firmware, wordt aangenomen dat de RoT geen potentieel doelwit is voor een aanval. Deze veronderstelling is gevaarlijk gebleken, zoals blijkt uit de groei van op firmware gebaseerde aanvallen door de jaren heen, en in het bijzonder meer dan vertienvoudigd in 2019 in vergelijking met 2010. Hackers realiseerden zich al snel dat door deze firmware te corrumperen, Trusted Platform Module (TPM) metingen voor attestdoeleinden op afstand kunnen ook worden beschadigd, aangezien de metingen afhankelijk zijn van interactie met de firmware om dergelijke metingen te valideren (het wordt niet voor niets "root of trust" genoemd). Om de platformintegriteit te garanderen, is het noodzakelijk dat de UEFI-firmware zelf wordt geverifieerd, dat wil zeggen dat er een beleid van nulvertrouwen wordt ingevoerd bij de RoT.

Eerste oplossing

Om dit probleem aan te pakken, hebben bedrijven de belangrijke stap genomen om de UEFI-firmware op hun servers te authenticeren met Cloudflare met behulp van de AMD EPYC-processor die deze authenticatie ondersteunt. Het hardwarebeveiligingssubsysteem van EPYC, genaamd de AMD Secure Processor, voert een functie uit met de naam platform secure boot (PSB) die het eerste blok van UEFI verifieert voordat de hoofd-CPU wordt vrijgegeven voor het resetten. PSB is AMD's implementatie van hardware-geroote opstartintegriteit. Het is beter dan op UEFI-firmware gebaseerde root of trust, omdat het bedoeld is om, door een root of trust, verankerd in de hardware, de integriteit en authenticiteit van het systeem-ROM-image te bevestigen voordat het kan worden uitgevoerd. Het doet dit door de volgende acties uit te voeren:

• Authenticeert het eerste blok van BIOS/UEFI voordat x86-CPU's vrijgeven van reset.
• Authenticeert de inhoud van het alleen-lezen geheugen (ROM) van het systeem bij elke keer opstarten, niet alleen tijdens updates.
• Verplaatst de UEFI-vertrouwensketen voor veilig opstarten naar onveranderlijke hardware.

Dit wordt bereikt door de AMD-platformbeveiligingsprocessor (PSP), een ARM Cortex-A5-microcontroller die een onveranderlijk onderdeel is van het systeem op chip (SoC).

Met deze aanpak heeft Cloudflare een oplossing mogelijk gemaakt die lijkt te voldoen aan de UEFI-firmware-authenticatiebehoeften.

Problemen met UEFI veilig opstarten

Niet-geverifieerde controllers

Een veelgebruikt onderdeel dat op bijna elke server zit, is een baseboard management controller (BMC). BMC's hebben meerdere verbindingen met het hostsysteem en bieden de mogelijkheid om hardware te bewaken, BIOS/UEFI-firmware te flashen, consoletoegang te verlenen via seriële of fysieke/virtuele KVM, de servers uit te schakelen en gebeurtenissen te loggen.

Als onderdeel van de opstartketen houdt de huidige PSB-methode van ondertekenen geen rekening met het ondertekenen van de BMC, wat het uitbreiden van de vertrouwensgrens beperkt tot een controller die veel interfaces heeft met systeemcomponenten.

Opstarten met een platformspecifieke CPU

Het opnemen van UEFI-firmware-authenticatie in een blok dat is ingebouwd in de hoofd-CPU van een server, introduceert logistieke problemen op het gebied van voorraadbeheer (SKU)-beheer. Een voorbeeld van zo'n probleem is het vergrendelen van een CPU op een bepaald platform. Met UEFI-authenticatie en gerelateerde cryptografische sleutels die zijn gekoppeld aan zowel de code in de ingebouwde opstartflitser als aan de AMD EPYC-CPU, moet alles aanwezig zijn op het platform om de server correct te laten opstarten. Dit beperkt echter de mogelijkheid om een ​​CPU op dat moederbord te upgraden of te wijzigen. Dit neveneffect is waargenomen in de markt voor wederverkopers met toegevoegde waarde, aangezien EPYC-apparaten die de PSB-functie gebruiken niet kunnen worden uitgewisseld. Sommige bedrijven (zoals HPE) hebben deze beperking erkend en hebben de PSB-functie uitgeschakeld in hun op EPYC gebaseerde servers, en hebben ervoor gekozen om hun UEFI-firmware extern te authenticeren met hun interne siliciumoplossing.

Axiado is van mening dat een externe coprocessor die UEFI-firmware-authenticatie afhandelt en tegelijkertijd CPU-flexibiliteit mogelijk maakt, ideaal is voor de industrie in het algemeen.

Uitdagingen met meerdere platforms

Een ander probleem met betrekking tot SKU-beheer heeft betrekking op het beheer van platforms met mogelijk meerdere veilige opstartmethoden. Een datacenter-implementatie van servers kan een mix van processors omvatten, zoals Intel, AMD en Arm, elk met hun richting voor het implementeren van UEFI-firmware-authenticatie. Dit scenario kan leiden tot overmatige belasting met het beheer van verschillende in eigen beheer ontwikkelde veilige-boot/root-of-trust-methodologieën van elke CPU-leverancier.

Daarom is een externe coprocessor voor het verwerken van UEFI-firmware-authenticatie met CPU-flexibiliteit ideaal voor de industrie in het algemeen.

Een potentiële one-stop-shop voor optimale firmware-beveiliging?

Een oplossing die een one-stop-shop voor beveiligingsbehoeften mogelijk maakt en tegelijkertijd de firmware-beveiliging verbetert en geen componenten aan de stuklijst toevoegt, is Axiado's vertrouwde control/compute unit (TCU) coprocessor. Dit biedt de beste UEFI-firmware-authenticatie voor een uniforme veilige opstartoplossing voor alle SKU's, ongeacht de keuze van een bedrijf in de belangrijkste CPU-leverancier, en dit alles zonder componenten aan het platform toe te voegen.

Als coprocessor in een server neemt Axiado TCU de rol van de Baseboard Management Controller (BMC)-chip op zich, zodat er voor dit apparaat geen extra ruimte op de server nodig is. De TCU is verantwoordelijk voor de attestering van alle componenten in het systeem, inclusief zichzelf. Het biedt een aantrekkelijke oplossing voor het consolideren van componenten door alle legacy-functionaliteit te ondersteunen die van een BMC-apparaat wordt verwacht, en door extra functionaliteit te bevatten waarmee TCU de rol kan spelen van de Trusted Platform Module (TPM) en Complex Programmable Logic Device (CPLD) op servers.

De kern van TCU wordt gevormd door Axiado's gepatenteerde veilige kluistechnologie, die fraudebestendige, onveranderlijke op hardware gebaseerde UEFI-firmware-authenticatie en veilig opstarten biedt. Deze technologie omvat onder andere bescherming tegen differentiële vermogensanalyse-aanvallen die worden gebruikt om cryptografische sleutels te reverse-engineeren die hackers toegang geven tot versleutelde privé-informatie.

De TCU bevat een veilige AI-technologie met een speciaal neuraal netwerkprocessor (NNP)-subsysteem dat is ontworpen om het normale gedrag van het apparaat te modelleren en zo afwijkingen te identificeren die kunnen wijzen op de aanwezigheid van een aanval. Dit maakt het mogelijk om alle noodzakelijke tegenmaatregelen te nemen om het systeem te beschermen voorafgaand aan aanvallen, ook die welke niet formeel zijn geïdentificeerd. Bovendien heeft de NNP verbindingen met verschillende I/O's van het apparaat, zodat het het normale gedrag kan modelleren en anomalieën van het serverplatform in het algemeen kan identificeren, waardoor de beschermende straal van de TCU tegen hackpogingen wordt vergroot.

Door een beveiligingscoprocessor-oplossing aan te bieden, lost Axiado de problemen op die in dit artikel worden gepresenteerd met betrekking tot SKU-aanbiedingen. Ten eerste minimaliseert een enkele oplossing het aantal aanvalsoppervlakken dat hackers kunnen proberen te misbruiken in een hele SKU-reeks. Men hoeft zich niet te beschermen tegen aanvallen op AMD, Intel, Arm en beveiligingsoplossingen van andere leveranciers. Dit vereenvoudigt ook het beheer en onderhoud van server-SKU-implementaties, waardoor het aantal varianten van platformsoftware/firmware-updates wordt geminimaliseerd. Ten tweede, door het beveiligde opstartsubsysteem over te hevelen naar de TCU, wordt de CPU niet langer vergrendeld op de specifieke serverhardware. Men kan dan vrij zijn om CPU's van verschillende hardwarevarianten te mixen en matchen en upgrades uit te voeren zonder de taak te hoeven uitvoeren om de CPU te configureren voor de specifieke hardware waarop deze is geïnstalleerd.

Samenvattend, de TCU-coprocessor biedt een uniforme en veilige hardwaregebaseerde UEFI-firmwarebeschermingsoplossing voor al zijn platforms, met de mogelijkheid om nieuwe aanvallen te leren voordat ze zelfs formeel worden erkend. Dit maakt een veilig netwerk mogelijk dat wordt aangedreven door krachtige en veelzijdige CPU-subsystemen, samen met een netwerk dat gemakkelijker te beheren en te onderhouden is.