AMD doet de encryptie van TSME bij consumenten Ryzen verdwijnen en opent een vertrouwensdebat

AMD staat voor een ongemakkelijke controverse wegens een beveiligingsfunctie waarvan veel gevorderde gebruikers dachten dat deze beschikbaar was op consumentproc processors van het Ryzen-assortiment. De functie heet Transparent Secure Memory Encryption, oftewel TSME, en maakt het mogelijk om het hele RAM transparant te versleutelen vanaf de firmware, zonder dat het besturingssysteem hier direct bij betrokken hoeft te zijn. Het doel is om het risico op fysieke aanvallen op het geheugen te verkleinen, zoals cold boot-aanvallen, het extraheren van modules of het afluisteren van signalen via de DRAM-interface.

Het probleem is niet alleen dat TSME in bepaalde niet-ondersteunde Ryzen-processors na updates met AGESA 1.2.7.0 leek te verdwijnen. Het ernstigste is dat deze wijziging plaatsvond zonder duidelijke openbare verklaring van AMD, terwijl BIOS-instellingen nog steeds de optie aangeven dat de functie actief is, terwijl het systeem niet meer rapporteert dat het geheugen versleuteld is. Voor de gemiddelde gebruiker is het bovendien moeilijk om dat te controleren onder Windows.

Onderzoek, gestart door Ben Kilpatrick en maandenlang gevolgd op GitHub, wijst uit dat de ondersteuning van TSME gestopt is op consumenten-Ryzen, terwijl het nog wel actief is op Ryzen Pro-modellen. AMD heeft tot nu toe per e-mail aangegeven dat TSME een beveiligingsfunctie is die alleen op CPU’s van AMD PRO Technologies toegepast wordt. De vraag is of we te maken hebben met een regressie door firmware of met een productsegmentatie die niet voldoende gecommuniceerd is.

Wat is TSME en waarom is het belangrijk

TSME is een transparante variant van AMD’s geheugencversleuteling. In tegenstelling tot SME, dat het mogelijk maakt voor het besturingssysteem om specifieke geheugenpagina’s te versleutelen, werkt TSME vanaf de firmware en versleutelt het gehele RAM met een enkele sleutel die bij het opstarten gegenereerd wordt door de AMD Secure Processor. Als deze functie in de BIOS ingeschakeld en operationeel is, kan het systeem draaien zonder dat de gebruiker of het OS handmatig moet beheren welke pagina’s versleuteld zijn.

De hoofdtoepassing ligt in scenario’s waarin een aanvaller fysiek toegang kan krijgen tot de machine of het geheugen, bijvoorbeeld bij diefstal of fysieke inbraak. TSME biedt geen volledige bescherming tegen alle aanvallen en vervangt niet het versleutelen van de harde schijf, veilige opstartprocedures of goede authenticatie. Maar het voegt een extra laag toe: als iemand probeert data uit het RAM te halen buiten de normale werking van het systeem om, zouden die gegevens veel minder bruikbaar moeten zijn.

Het nuanceverschil is belangrijk omdat TSME werd gezien als een gebruiksvriendelijke laag voor niet-technische gebruikers, die niet willen of kunnen knoeien met kernelinstellingen, opstartopties of systeemondersteuning. Het volstond dat de BIOS de optie aanbood en dat de firmware dit correct activeerde.

Het ontdekking: de optie stond in BIOS, maar werkte niet

Het begon toen Ben Kilpatrick, Linux-gebruiker die bezorgd is over privacy, een nieuw systeem installeerde op een Ryzen 7 9700X en via de ingebouwde beveiligingsaudit ‘Host Security ID’ de status controleerde. Tot zijn verbazing bleek “Encrypted RAM” niet ondersteund, terwijl TSME wel ingeschakeld was in de BIOS.

Dit detail leidde tot een technische analyse met betrokkenheid van AMD-ingenieurs, gebruikers en MSI, de fabrikant van het moederbord. Tests met verschillende firmwareversies en processormodellen lieten zien dat bepaalde Ryzen-consumentenmodellen TSME activeerden met oudere firmware, maar dat dit na AGESA 1.2.7.0 verdween (toonde als niet-ondersteund). Ryzen Pro-modellen hielden wel ondersteuning.

Het meest zorgwekkende is niet dat een functie kan verdwijnen, dat kan door zakelijke keuzes, certificeringseisen, firmwarefouten of hardware-beperkingen komen. Wat problematisch is, is dat een beveiligingsoptie in BIOS wel actief kan lijken, terwijl deze in werkelijkheid niet functioneert in het systeem.

Firmwarebug of productsegmentatie

De grote vraag blijft of AMD per ongeluk TSME heeft uitgeschakeld op consumenten-Ryzen of dat het juist heeft gereserveerd voor Ryzen Pro en EPYC. Het verschil is significant. Als het een bug is, moet deze worden gerepareerd. Als het een strategische keuze betreft, moet dat duidelijk gecommuniceerd worden, omdat het invloed heeft op gebruikersverwachtingen over veiligheid.

Het wordt complexer omdat AMD-ingenieurs in het verleden TSME als beschikbaar of verwachte functionaliteit beschreven hadden op niet-Pro Ryzen-processors, mits de BIOS dit ondersteunde. Dit staat haaks op de nieuwe communicatie dat TSME uitsluitend voor CPU’s onder AMD PRO-technologie zou zijn.

Het stilzwijgen van AMD helpt niet. Een ingenieur liet weten dat hij verder geen informatie kon delen. Het kan een begrijpelijke beperking zijn in een technische repository, maar het laat onzekerheid bestaan bij gebruikers die willen weten of hun systeem nog echt beschermd wordt of dat ze nooit meer op een dergelijke ondersteuning konden rekenen.

Waarom het niet voor alle gebruikers hetzelfde is

Voor de meeste thuisgebruikers zal het verlies van TSME de dagelijkse risico’s niet sterk veranderen. Aanvallen op RAM vereisen fysieke toegang of zeer specifieke hardwareomstandigheden. Het is geen kwetsbaarheid die direct vanaf internet te exploiteren is, noch een fout die alle Ryzen-systemen automatisch onveilig maakt.

Het wordt ernstiger bij laptops, machines die reizen, professionele gebruikers met gevoelige data, journalisten, advocaten, activisten, onderzoekers en organisaties waar fysieke diefstal of inbeslagname reëel is. In zulke gevallen biedt geheugencodering een extra beschermlaag omdat geheime sleutels, sessies, tokens en andere gevoelige gegevens tijdelijk in RAM kunnen blijven hangen.

De juiste interpretatie is niet alarmistisch. Maar het is ook niet verstandig om de zaak te minimaliseren. Fysieke beveiliging bestaat precies om te beschermen als de digitale barrières niet voldoende blijken te zijn.

TSME vervangt niet de harde schijf encryptie

Een veelgemaakte fout is het verwarren van geheugencodering met schijfversleuteling. Het zijn verschillende lagen. BitLocker, LUKS, FileVault of vergelijkbare oplossingen beschermen opgeslagen gegevens wanneer de computer uitstaat of correct is vergrendeld. TSME beschermt de inhoud van RAM tegen fysiek uitlezen, terwijl het systeem actief, gesuspend of in vergrendelstaat is, en cachegeheugen in gebruik is.

Wanneer een laptop is uitgeschakeld en versleuteld, is schijfversleuteling de voornaamste bescherming. Als de machine aanstaat, ontgrendeld of gesuspend is, en de sleutels in RAM aanwezig zijn, kunnen fysieke aanvallen data proberen uit te lezen. Daar komen technologieën als TSME of AMD Memory Guard dan van pas.

Voor gebruikers die zich fysiek bedreigd voelen, blijft het advies om het apparaat volledig uit te schakelen bij transport en niet alleen te suspenden. Combineer versleuteling van de schijf, TPM, Secure Boot, sterke wachtwoorden en beleidslijnen voor fysieke beveiliging.

De onderliggende uitdaging: een onzichtbare functie voor de gebruiker

Het meest zorgwekkende is dat een beveiligingsfunctie kan activeren in BIOS, maar dat de werkelijke status niet duidelijk zichtbaar is voor de gebruiker in Windows of standaardhulpprogramma’s. Dit creëert een vals gevoel van bescherming: de gebruiker denkt dat hij beschermd is, terwijl dat misschien niet zo is.

In Linux kan men het controleren met fwupd, HSI, logs en geavanceerde technische tests. Maar dat vereist kennis en inzet. Onder Windows is het nog moeilijker doordat er geen eenvoudige geïntegreerde tool bestaat die duidelijk aangeeft of de RAM-versleuteling via TSME actief is.

In de beveiliging is transparantie net zo belangrijk als de functionaliteit. Een bescherming die zonder waarschuwing verdwijnt, kan uiteindelijk schadelijker zijn dan nooit geboden bescherming, omdat gebruikers erop vertrouwen dat het er is.

AMD Pro, EPYC en de zakelijke waarde van beveiliging

De positionering van AMD lijkt te passen bij een gangbare marktstrategie: bepaalde functies, vooral op het gebied van beheer, beveiliging en management, reserveren voor professionele modellen. AMD Pro en EPYC zijn ontworpen voor bedrijven, beheerde omgevingen, werkstations, servers en situaties waarin veiligheid een verkooppunt is.

Het probleem is dat TSME niet volledig los stond van de consumentengeneratie Ryzen. BIOS-instellingen die het exposeerden, gebruikers die het activeerden, en systemen die met TSME leken te werken, suggereerden dat het toegankelijk was. Als AMD het wil beperken tot de Pro-serie, had dit duidelijker moeten worden gecommuniceerd.

Segregatie is op zich niet onrechtmatig. Bedrijven maken er gebruik van om verschillende productlijnen te onderscheiden. Wat problematisch is, is dat hardwarefuncties zonder goede communicatie worden beperkt of uitgeschakeld, vooral als dat betrekking heeft op beveiliging en vertrouwelijkheid.

Wat kunnen gebruikers nu doen

Gebruikers die geheugencodering nodig hebben, moeten eerst beoordelen of ze dat risico waard vinden. Voor een desktop op zolder is dat wellicht niet relevant, maar voor een laptop met gevoelige data kan dat wel zo zijn.

Op Linux-systemen is het aan te raden om het status te controleren met tools zoals fwupdmgr security. Als “Encrypted RAM” niet ondersteund wordt, of niet-ondersteund is, dan moet je voorzichtig zijn. Bij Windows is het moeilijker om dat direct te checken; het is daarom verstandig om niet blind te vertrouwen dat TSME actief is op Ryzen-systemen die geen Pro-variant zijn, tenzij je een betrouwbare technische verificatie hebt.

Voor industriële en zakelijke toepassingen is het belangrijk om het hardware- en firmwarebeleid te herzien: is geheugencodering onderdeel van de vereisten? Welke CPU’s en firmwareversies ondersteunen dat precies? In dat geval is het verstandig om de IT-beveiliging te herzien en te zorgen dat de eisen duidelijk gecommuniceerd worden.

Een kleine, maar symbolische crisis

De onmiddellijke technische impact is voor de meeste gebruikers beperkt, maar de symbolische waarde is groter. AMD heeft jarenlang een goede reputatie opgebouwd onder enthousiastelingen, ontwikkelaars en Linux-gebruikers door CPU’s aan te bieden die concurrerend en vaak voorzien van geavanceerde functies waren—soms zelfs breder dan de zakelijke markt. Het verdwijnen van een veiligheidstechnologie op een ondoorzichtige wijze ondermijnt dat vertrouwen.

Het onderstreept ook een ongemakkelijke realiteit: modern hardware hangt niet alleen af van de fysieke componenten, maar sterk van het firmware. Een CPU kan fysiek de capaciteit hebben om iets te doen, maar of het actief wordt of niet, bepaalt de firmware. De koper weet niet altijd wat die na een update nog kan of mag.

Deze afhankelijkheid groeit verder in complexiteit: beveiliging, virtualisatie, performance management, energiebeheer, mitigaties en bedrijfsfuncties worden gedeeld tussen silicium, firmware, BIOS en OS. Als één laag zonder waarschuwing verandert, blijft de gebruiker in het duister.

AMD moet uitleg geven

AMD kan dit nog rechtzetten door transparant te zijn. Als het een regressie betreft, moet het dat erkennen en corrigeren. Als het een strategische keuze was, moet dat duidelijk gemaakt worden—welke CPU’s ondersteunen TSME, vanaf welke firmwareversie en onder welke voorwaarden? Wat moeten gebruikers weten als zij TSME actief hadden? Als de functie nooit officieel ondersteund werd door AMD voor consument- Ryzen, moet dat ook helder gecommuniceerd worden.

De ergste situatie is dat dit in een grijze zone blijft hangen, zonder duidelijkheid. In beveiliging kost ambiguïteit vertrouwen. Geavanceerde gebruikers accepteren dat bepaalde functies voor professionele hardware gereserveerd zijn, maar niet dat functies verdwijnen zonder waarschuwing terwijl de BIOS nog aangeeft dat ze er zijn.

De vraag blijft: wanneer een beveiligingsfunctie afhankelijk is van firmware en beleidskeuzes, hoe weet de gebruiker dan daadwerkelijk welke bescherming hij heeft?

De belangrijkste les is dat geheugencodering niet slechts een technische optie is. Het is een belofte van bescherming. Als die belofte wordt verbroken, moet de fabrikant dat duidelijk maken.

Veelgestelde vragen

Wat is er precies gebeurd met TSME op Ryzen voor consumenten?

Gebruikers en onderzoekers constateren dat TSME in sommige Ryzen-consumentenmodellen niet meer wordt weergegeven als ondersteund na firmware met AGESA 1.2.7.0, terwijl het bij Ryzen Pro-modellen wel blijft werken.

Wat is TSME?

TSME, Transparent Secure Memory Encryption, is een functie waarbij de hele RAM-inhoud transparant versleuteld wordt met een sleutel die bij het opstarten wordt gegenereerd door de AMD Secure Processor.

Is het een remote kwetsbaarheid?

Nee. Het grootste risico ligt bij fysieke aanvallen zoals cold boot, module-extractie of signalen afluisteren via de DRAM-interface. Het stelt niet direct de deur open voor aanvallen vanaf internet.

Welke gebruikers worden het meest getroffen?

Gebruikers van gevoelige laptops, professionals met vertrouwelijke data, journalisten, activisten, organisaties met fysieke beveiligingsrisico’s en anderen die afhankelijk waren van geheugencodering als beveiligingsmaatregel.

Heeft AMD dit officieel verklaard?

Niet in technische details. Tot nu toe is de officiële verklaring dat TSME deel uitmaakt van AMD PRO Technologies en bedoeld is voor CPU’s onder die vlag. Er wordt niet expliciet gezegd of het bijwerken of niet werken het gevolg is van een bug, beleidswijziging of validatieprobleem.

Hoe kun je controleren of TSME actief is?

Op Linux kan dat via tools als fwupd en HSI, maar dat vereist technische kennis. Op Windows is er geen eenvoudige manier om dat snel te controleren.

Wat te doen als geheugencodering wel nodig is?

Gebruik hardware die het officieel ondersteunt, zoals Ryzen Pro of EPYC. Zorg dat firmware up-to-date is, activeer schijfversleuteling, TPM en Secure Boot, en schakel het apparaat volledig uit bij fysieke risico’s.

Bronnen:
Ars Technica
Tom’s Hardware
AMD Developer Documentation
AMD Memory Encryption White Paper
AMD Memory Guard White Paper
Linux Kernel Documentation
fwupd
GitHub AMDESE
MSI
TechSpot
PC Perspective

via: tomshardware