Vendor-Lock: EPYC-Prozessoren können auf bestimmte Hersteller beschränkt sein

[HWL News Bot]

Zunächst einmal vorweg: Das in der Folge beschriebene Problem rund um einen Vendor-Lock bei den EPYC-Prozessoren ist nicht neu. Für Käufer der Prozessoren über den normalen Handel stellt es auch kein Problem dar und auch grundsätzlich gilt für den Gebrauchtmarkt nicht, dass sich EPYC-Prozessoren nicht mehr in anderen Servern bzw. auf anderen Mainboards verwenden lassen, aber eine derartige Einschränkung scheint dennoch auf größeres Interesse zu stoßen und daher sollte man das Thema auch einmal besprechen.
... weiterlesen

 

[Nonaamee]

Und inwiefern ist das jetzt sicherer, wenn die CPU nur auf einem bestimmten Mainboard laufen kann?
Wenn mein Angreifer soweit kommt und physischen Zugriff auf meinen Server hat, habe ich doch ganz andere Probleme als eine ausgetauschte CPU. Oder ist das so wie mit Autoradios, dass die nach Diebstahl gelockt sind und sich somit nicht mehr lohnt

 

[preisi]

Und inwiefern ist das jetzt sicherer, wenn die CPU nur auf einem bestimmten Mainboard laufen kann?
Wenn mein Angreifer soweit kommt und physischen Zugriff auf meinen Server hat, habe ich doch ganz andere Probleme als eine ausgetauschte CPU. Oder ist das so wie mit Autoradios, dass die nach Diebstahl gelockt sind und sich somit nicht mehr lohnt

Die Idee ist eben, dass ein Angreifer mit physischen Zugriff nicht einfach so deine Firmware austauschen kann um auf diese Weise z.B. indirekt die Festplattencrypto zu umgehen (Stichwort "Evil Maid Attack"). Natürlich würde hier auch ein normaler Keylogger ausreichen um beim nächsten Bootvorgang das Passwort mitzulesen, aber einen solchen entdeckt und entfernt man leicher als bösartige Firmware welche zudem noch tiefer im System verankert ist.

Aber irgendwie ist die Umsetzung von AMDs PSB nicht ganz überzeugend. Ich würde also eher auf OpenTitan bzw Microsofts Project Cerberus setzen sobald diese irgendwann allgemein verfügbar sind. Dann gibts zumindest keinen Vendorlock und man kann die CPU auch noch problemlos woanders einbauen..

 

[java4ever]

Das Ziel ist imho nicht eine Sicherheitsbarriere bei physischem Zugriff.
Hat ein Angreifer physischen Zugriff hast du sowieso verloren.

Was verhindert werden soll ist in meinen Augen ein Überschreiben des UEFI mit einer unsignierten Variante (Rootkit). Die hat dann logischerweise nicht die Schlüssel des originalen UEFIs und die CPU weigert sich zu booten.

 

[H_M_Murdock]

Danke für die Erläuterung, jetzt hab ich's auch kapiert.
Man will nicht die CPU ans System binden sondern quasi das UEFI an die CPU.

Heißt bei physischem Zugriff müsste ich das UEFI mitsamt der CPU tauschen, beim viel größeren Problem dass ich eine Software einschleusen kann bekomme ich aber kein manipuliertes UEFI gebootet.

Wäre natürlich im Sinne des Gebrauchtmarkts wünschenswert die CPU zumindest hinterher wieder "unlocken" zu können, aber damit das Sicher ist müsste es auf einem Weg statt finden können der per Software auf dem entsprechenden System in dem die CPU originalerweise läuft nicht machbar ist, sonst liefert man die Hintertür ja gleich mit.

 

[preisi]

Naja, eigentlich geht es darum, das System während des Bootvorgangs besonders zu schützen. Normalerweise ist zu diesem Zeitpunkt das System am unsichersten da hier noch kein Betriebsystem läuft welches im Idealfall seine eigenen Sicherheitsmechanismen mit sich bringt. Vor allem bei der eigentlichen Initialisierungsphase wird halt erstmal *irgendein* Code aus einem Speicher geladen um die CPU zu "starten". Und hier wird eben erstmal nicht die Integrität dieses Codes verifiziert. Auch nicht vom UEFI. Heißt sobald ein Angreifer hier ansetzt, kann er quasi beliebigen Code ausführen ohne das es irgendwer merken würde. Deswegen will man hier eine "Root of Trust" etablieren und entsprechend auch diese Initialisierung der Hardware entsprechend zu verifizieren. Also ja, man kann es als Schutzmechanismus für das UEFI sehen, aber zumindest andere Sicherheitschips können noch mehr wie z.B. Attestation und KeyStorage.

 

[tStorm]

Das Thema wäre viel spannender, wenn es auf Intelseite wäre. Man was hätte ich da wieder Spaß beim Lesen des Bashings.

 

[blazethelight]

Liegt wohl eher daran, dass Intel in der Vergangenheit gezeigt hat, wie anfällig die Intel Management Engines gegen Manipulationen waren, welche auch lange Zeit nicht geschlossen waren.
Selbst das BIOS / UEFI war / ist nicht so sicher, wie Intel Marketing Folien versprechen.

 

[jdl]

Natürlich würde hier auch ein normaler Keylogger ausreichen um beim nächsten Bootvorgang das Passwort mitzulesen, aber einen solchen entdeckt und entfernt man leicher als bösartige Firmware welche zudem noch tiefer im System verankert ist.

Es gibt bereits Keylogger, die im Tastaturcontroller integriert sind. Die findest Du als Normalsterblicher nie.