Trusted execution environments

Hoe veilig zijn beveiligde enclaves op chips?

Hoe veilig zijn tee's?

Tee's zijn onder de streep dus goede manieren om data te beveiligen, maar geen enkele beveiliging is waterdicht. Is er iets te zeggen over hoe veilig deze methode is ten opzichte van andere beveiligingsmethoden? Daarvoor is het goed om eens te kijken naar de geschiedenis. Er zijn verschillende gevallen geweest waarin tee's zijn aangevallen, al moet je goed zoeken. In de meeste gevallen gaat het om onderzoeken die je vooral theoretisch kunt noemen, al dan niet in laboratoriumopstellingen, waarbij computerwetenschappers een methode hebben gevonden om bepaalde gegevens onder ideale omstandigheden te kunnen afluisteren.

Zo doken onderzoekers twee jaar geleden in de Secure Enclave van Apple. Tarjei Mandt, Mathew Solnik en David Wang presenteerden hun bevindingen op de BlackHat-securityconferentie. In het stuk probeerde het trio de precieze werking van Apples tee te achterhalen. Hoewel de onderzoekers concluderen dat de Secure Enclave een paar slimme beveiligingstrucs bevatte, noemen ze ook een paar potentiële kwetsbaarheden, zoals het gebrek aan memory layout randomization. Dat zijn echter theoretische bevindingen, die ze niet in het echt wisten uit te buiten. Later wist een andere beveiligingsonderzoeker zelfs de decryptiesleutel van de Secure Enclave te ontcijferen, waarmee hij vervolgens de versleutelde data kon afluisteren.

Ryzenfall

Zowel in Intel- als AMD-socs werden lekken ontdekt waarmee de tee kwetsbaar werdEr zijn ook verschillende gevallen bekend waarin tee's van bijvoorbeeld AMD kwetsbaar blijken. In 2018 kwamen diverse prominente lekken in zowel de Epyc-processors voor datacenters als de Ryzen-cpu's voorbij. Het ging feitelijk om één soort aanval waarmee AMD's Secure Processor werd bestookt. De lekken werden onderverdeeld in vier categorieën; Masterkey, Ryzenfall, Fallout en Chimera waren lekken waarmee de communicatie tussen de soc en de Secure Processor-chip kon worden afgeluisterd. Kort daarna bleken Duitse onderzoekers juist de softwareomgeving van AMD's Secure Encrypted Virtualization op Epyc-processors te kunnen omzeilen door de geheugenlay-out van de virtuele machine te mappen. Er zijn dus wel degelijk voorbeelden te zien van kwetsbaarheden in de tee's. Hoe vaak die in de praktijk worden ingezet, is echter de vraag. Misschien gebruiken geavanceerde staatshackers hier en daar eens een methode, maar er zijn nergens voorbeelden bekend waarbij de lekken op grote schaal worden misbruikt.

In de meeste gevallen waarin tee's worden gekraakt, is een rode draad te zien. Twee kwetsbaarheden in Qualcomms Secure Execution Environment betreffen allebei buffer overflows. Niet zo gek: de data van de tee naar de soc loopt via zo'n buffer en dat is vaak een van de weinige plekken waar de data te onderscheppen is. Praktisch is dat niet; voor de aanvallen is soms roottoegang nodig en het kan heel lang duren voordat data uitlekt. Bij een aanval duurde het bijvoorbeeld veertien uur voordat een onderzoeker een P-256-sleutel wist te achterhalen. In veel gevallen zijn de aanvallen ook niet persistent en verdwijnen ze na een reboot.

Een ander potentieel gevaar voor tee's zit in een ander soort kwetsbaarheden. Dat zijn de bugs in speculative execution, die de laatste jaren met regelmaat worden ontdekt. Dat gebeurt in zowel Intel- als AMD-cpu's. Een zo'n aanval werd zelfs specifiek opgezet om data uit tpm's af te lezen.

Theoretisch onderzoek

In de praktijk zijn de kwetsbaarheden moeilijk uit te buiten, zeker op grote schaalDe onderzoeken naar de lekken zitten vaak aan de academische kant. Ze zijn in de praktijk dan ook lastig uit te buiten. Er is veel tijd en kennis voor nodig, vaak ook veel geld en in sommige gevallen fysieke toegang tot een apparaat. Dat maakt, afhankelijk natuurlijk van je threat model, dat de ontdekte kwetsbaarheden weinig risico met zich meebrengen. Als het zoveel moeite kost om een wachtwoord van één gebruiker te achterhalen, loop je waarschijnlijk meer gevaar door ransomware of een goede spearphishingmail. Aan de andere kant zit er wel een risico aan microkernellekken dat bij gewone software lang niet altijd aanwezig is. Ze zijn bijvoorbeeld lastiger op te lossen doordat microkernel-updates een stuk moeilijker door te voeren zijn dan reguliere software-updates.

Conclusie

Trusted execution environments doen voornamelijk wat hun naam belooft. Ze bieden een veilige, vertrouwde omgeving op een chip voor het uitvoeren van belangrijke taken. Ondanks een paar incidenten rondom de veiligheid ervan is het een belangrijke beveiligingstrend, die waarschijnlijk niet snel zal verdwijnen, want zeg zelf: welke oplossing ligt meer voor de hand?

Reacties (67)

[Eonfge]

Wat ontbreekt in het artikel, is het stukje maatschappelijke kritiek die TPM modules hebben: ze ontnemen de eigenaar van een apparaat namelijk controle.

Stallman in heldere woorden:
https://www.gnu.org/philosophy/can-you-trust.html

In het geval van Apple, maakt het bijvoorbeeld bepaalde reparaties door derden onmogelijk. Ook kun je geen eigen OS vanaf een mac booten en zo maakt het de vendor-lock van bepaalde leveranciers weer een stukje groter.

Vrijheid en veiligheid (privacy) worden op die manier ook als een valse tegenstrijdigheid gepresenteerd. Wat velen vergeten is dat veiligheid zonder vrijheid, op elk moment kan worden ingetrokken zonder jou inspraak. Dit is bijvoorbeeld ook een van de redenen waarom VeraCrypt geen tpm ondersteund.

In de wereld van Linux is tpm controversieel, maar wel vrijblijvend ondersteund. Als je wilt kun je ze gebruiken, naar de kernel zal ze niet automatisch opstarten.

edit. spelfout.

[Reactie gewijzigd door Eonfge op 23 juli 2024 15:47]

[GertMenkel]

Is een TPM zo controversieel? Ik snap dat de T2-chip een probleem vormt voor softwarevrijheid maar in mijn dual boot setup heb ik geen enkel probleem om de TPM te gebruiken voor Bitlocker en daarnaast LUKS te gebruiken voor Linux.

Voor TPM's zijn standaarden en die zijn op desktopplatformen gewoon voor iedereen bruikbaar. Indien je de master key niet meer hebt omdat een proprietary systeem zoals Windows die heeft geconfigureerd kun je de TPM wissen en opnieuw instellen. Ik zie niet waarom Veracrypt daar zo'n moeite mee heeft. Er zijn natuurlijk andere redenen om de TPM niet te gebruiken (compatibility, lastig veiligheid van firmware checken, additioneel risico van interceptie, overheidsbackdoors) maar dit vind ik een redelijk zwak argument van Veracrypt.

Ik vind Intel SGX en dergelijke en apparaten waar de secure bootkkeys vergrendeld op Windows staan gevaarlijke vormen van softwarebeperking dan de TPM. Het offloaden van sleutelbeheer naar een fysiek apparaat dat bedoeld is om de sleutels veilig te houden vind ik geen slechte keuze.

Het artikel dat je linkt gaat dan ook niet over TPM's maar over TEE's, waar afhankelijk van het platform inderdaad flink wat mis mee is. Zelfs die systemen kunnen een bonus zijn voor computerveiligheid als ze open source en open hardware geïmplementeerd zouden zijn; een TEE op RiscV of POWER9 kan bijvoorbeeld een flink aantal voordelen opleveren als het aankomt op het verwerken van gevoelige data. Het concept is niet per se verkeerd omdat de meeste implementaties niet voor jou als consument niet te gebruiken zijn; slechts die implementaties zijn verkeerd en ik vind dat dat genoemd moet worden.

[Eonfge]

Ik snap dat de T2-chip een probleem vormt voor softwarevrijheid maar in mijn dual boot setup heb ik geen enkel probleem om de TPM te gebruiken voor Bitlocker en daarnaast LUKS te gebruiken voor Linux.

En de enige rede waarom dat mogelijk is, is omdat Secure Boot aangepast kan worden op jouw laptop. Als jouw laptop leverancier besluit dat Secure Boot afgesloten moet worden voor de eindgebruiker, dan is Linux geen optie meer.

Free Software Foundation erover in 2011, toen Secure Boot uit kwam:
https://www.fsf.org/campa...-boot-vs-restricted-boot/

TPM, SecureBoot en dergelijke zijn echter wel conceptueel aan elkaar gerelateerd. Het zijn allemaal systemen om veiligheid toe te voegen, maar er zit een achilleshiel in: Je bent afhankelijk van de medewerking van de fabrikant, als jij andere software wilt draaien. Dit zie je veel bij Android: Sommige fabrikanten staan jou toe om de Secure Bootloader te unlocken, andere niet.

Ben er dus niet direct hard op tegen, maar ik denk wel dat consumenten en bedrijven er van bewust moeten zijn hoe dit ze kan naaien als ze zelf geen override hebben.

[Reactie gewijzigd door Eonfge op 23 juli 2024 15:47]

[GertMenkel]

Tja, je bent natuurlijk altijd afhankelijk van de fabrikant. Zelfs bij redelijk open apparatuur als de Raspberry Pi en de PinePhone zitten stukken code en chips waar je geen controle over hebt.

Als jouw laptopleverancier besluit dat Linux geen optie is, heb je de verkeerde leverancier gekozen. Ik heb locked secure boot eigenlijk alleen gezien bij Microsoft-apparatuur en goedkope Chinese tablets met Windows erop. Iedere grote x86-moederbordleverancier ondersteunt het uitschakelen of het inladen van eigen keus in de secure bootinstellingen, aannemende dat je een wachtwoord op je uefi hebt gezet.

Secure boot lost een daadwerkelijk probleem op en de demonisering van dit soort technologieën is de reden dat ik het nooit met de FSF eens zal zijn. Het werd vanaf het begin af aan neergezet als plot van Microsoft om Linux uit te roeien (alsof ze Linux wat kan schelen). Linux zou prima een hoop security bypasses kunnen voorkomen als het secure boot op een nuttige manier zou implementeren maar daar lijkt weinig animo voor te zijn. Als tussenoplossing hebben we nu ondertekende GRUB binaries die het hele secure bootsysteem nagenoeg nutteloos maken.

[Eonfge]

Het werd vanaf het begin af aan neergezet als plot van Microsoft om Linux uit te roeien (alsof ze Linux wat kan schelen)

Vergeet niet hoe Microsoft in de jaren '00 over Linux sprak (Linux is cancer), en Microsoft heeft wel degelijk een reputatie voor het uitroeien van concurrenten door middel van het uitrollen van incompatibele, gesloten standaarden. Ze hebben er zelfs een term aan over gehouden:

https://en.wikipedia.org/...e,_extend,_and_extinguish

[field33P]

Echter is de afgelopen jaren juist gebleken dat Microsoft steeds meer gebruik is gaan maken van open standaarden zonder E³ uit te voeren. Dus het heeft alle blijk ervan dat er hysterie tegen Secure Boot gezaaid is.

[Eonfge]

Andere tijden. Microsoft ziet hun winst verdeling veranderen. Minder Windows en Office, meer Azure. Daarom beweegt Microsoft mee en daarom ondersteunen ze tegenwoordig ook Linux als server platform.

Vergeet ook niet dat Microsoft nog steeds licenties gebruikt zoals MIT, die EEE in de toekomst niet uitsluiten. Als ze morgen besluiten dat alle beveiligingsupdates voor .NET Core gesloten zijn, te huren voor 10.- euro per maand per processor(-core), dan kan dat.

[MSalters]

Wat je nu doet is exact dezelfde bangmakerij waarvan je twee posts hierboven Microsoft beschuldigde.

[hottestbrain]

.NET core is open source. Zelfs al zouden ze dat wijzigen: forken en doorgaan.

[Eonfge]

Dan moet een concurrent (denk Amazon, IBM, Red Hat, Canonical) ook wel de mankracht hebben om het ontwikkelteam te vervangen, en het moet natuurlijk wel compatibel blijven. Het gros van de .Net ontwikkelaars is werknemer bij Microsoft, dus het is nog niet zo makkelijk om je eigen ontwikkeltraject op te zetten.

In de praktijk zal een agressieve speler (niet per se Microsoft) het veel subtieler spelen. Je maakt een Open Source systeem, en daarop bied je gewoon wat extra tools aan die handig zijn voor enterprises. Deze raken langzaam steeds meer ingeburgerd en uiteindelijk is 90% van de gebruikers afhankelijk van de toevoeging. Dan ga je langzaam de duimschroeven aandraaien en uiteindelijk komen je partners er niet meer onder uit om toch die licentie af te nemen, want een functionele zijstap maken is niet realistisch.

Voor een niet-Microsoft voorbeeld, Android: https://arstechnica.com/g...e-by-any-means-necessary/

Of Internet Explorer, of Silverlight, Microsoft Office, Microsoft Teams. Er is een rede dat deze producten vaak langs komen in grote anti-trust rechtzaken...

Dat iets Open Source is, zegt eigenlijk niet zo veel. de OSI definitie heeft niets ingebouwd om de rechten van (zakelijke-)gebruikers, nu en in de toekomst, te waarborgen. Dit is ook een grote breuk in idealen tussen de FSF en de OSI, want de FSF wil wel dat die rechten beschermt worden naar de toekomst.

Leuk detail voor de hele Java vs .Net discussie... Java biedt die juridische zekerheden naar de toekomst wel.

[CEx]

https://arstechnica.com/t...20billions%20of%20dollars.

Toepasselijk artikel, wel beter dan .Net, maar daar houdt het heel snel op.

[CEx]

Bangmakerij. Dat kan Microsoft niet zo maar doen. Ten eerste zal een rechter hier uiteindelijk een stokje voor steken. Ten tweede Microsoft neemt zelf een een hoop licenties af 'voor weinig', deze partners zullen ook niet blij zijn met zo'n move.

[Eonfge]

Heel dapper dat jij vertrouwen hebt in de doortastendheid en snelheid van de Europese mededingingsautoriteiten. Zeker na hun vorige successen in het verbreken van het Google of Microsoft monopolie.

Ik heb liever iets meer zekerheid dan dat.

[CEx]

Je loopt meer risico iedere keer dat je de auto instapt.

Ik en miljoenen met mij hebben die zekerheid niet nodig om Microsoft producten te gebruiken.

[WoutervOorschot]

Dan ligt het dus aan de fabrikant en niet aan de hardware. Zonder tpm kan (bijvoorbeeld) Apple het ook praktisch onmogelijk maken andere software op een mac te draaien.

Het klinkt als een beetje overdreven reactie van Stallman

[Reactie gewijzigd door WoutervOorschot op 23 juli 2024 15:47]

[MSalters]

Stallman's probleem is dat software een eigenaar heeft. Hij heeft de GPL bedacht als omweg, omdat hij de wet niet kan veranderen, maar de GPL biedt 90% van wat hij wil binnen de grenzen van de wet.

Alleen, zoals al hierboven gezegd, "TPM's ontnemen de eigenaar van een apparaat controle.". Inderdaad, die controle ligt bij de eigenaar van de software, niet de eigenaar van de hardware. En dat is wettelijk een heel ander concept. Microsoft is de eigenaar van Windows. Google is de eigenaar van Android. Zelfs een kale Linux is niet het eigendom van de gebruiker ervan.

[bzzzt]

Stallman is natuurlijk wel een van de twee extreme kanten van het spectrum. Niet dat hij geen punt heeft, maar er zijn ook voordelen aan de "Apple stijl" tpm aanpak, en dat is niet alleen maar standaard 'consumentje pesten' en winstbejag.

Door de T2 chip zijn bepaalde aanpassingen inderdaad niet mogelijk. Bv. het vervangen van de vingerafdruk lezer. Nu begrijp ik wel dat je als consument graag naar de goedkoopste onderdelen leverancier gaat, maar bedenk wel dat je die partij (en hun onderdelen bron) dan feitelijk toegang geeft tot een kritisch deel van de veiligheid van je systeem. Denk je eens in wat een schade een backdoor die een stiekem gecachede vingerafdruk combineert met een remote activatie daarvan zou kunnen doen.

Hetzelfde geldt voor goedkope batterijen en opladers (reputatieschade als ze slecht zijn voor Apple, mogelijk brandgevaar voor de consument in extreme gevallen).

[Eonfge]

Hiervoor heeft de GPL 3.0 (opgesteld door Stallman) een uitzonderingsregel:
https://www.gnu.org/licenses/gpl-faq.en.html#GiveUpKeys

Lang verhaal kort, als een officiële fabrikant binaries (of binaries op componenten) wilt verspreiden, en deze wilt signeren om zo de gebruiker te beschermen, dan mag dat. Apple zou in Stallman's woorden, prima hun officiële hardware mogen signeren om zo gebruikers te waarschuwen voor niet-officiële hardware.

Echter, dit mag een fabrikant niet gebruiker om de gebruikersvrijheden te blokkeren: Als de hardware dienst weigert zondert bepaalde certificaten, dan moet je de certificaten delen.

Dit is een belangrijk verschil tussen GPL V3 en GPL V2, welke geen hardware-sleutel fallback had:
https://en.wikipedia.org/wiki/Tivoization

[bzzzt]

Leuk gevonden van Stallman, maar daarom rennen bedrijven als Apple hard weg van alles wat met GPL te maken heeft...

Als je als fabrikant vindt dat je hardware niet correct werkt met niet originele onderdelen, waarom zou je dat toelaten? Alleen een waarschuwing geven suggereert dat je het ok vindt. Moet je dan ook nog garanderen dat alles werkt? En als je DRM zo makkelijk omzeild kan worden valt er in die film en TV store ook niks meer te verkopen want geen rechtenhouder accepteert het als het gebruikers zo makkelijk wordt gemaakt een kopietje te maken.

En delen van certificaten? Zodat je concurrentie geholpen wordt? Zodat staatshackers makkelijker op telefoons van journalisten kunnen kijken? Zodat advertentie-partijen het OS kunnen aanpassen om nog beter te tracken? Dat gaat gewoon niet gebeuren en ik vind het niet raar dat Apple dat niet wil.

[Eonfge]

Natuurlijk hoef je geen garantie te geven op onderdelen van anderen. De GPL heeft hier geen mening over, want dit valt niet onder auteurs- en contractrecht, maar consumentenrecht.

En als je DRM zo makkelijk omzeild kan worden valt er in die film en TV store ook niks meer te verkopen want geen rechtenhouder accepteert het als het gebruikers zo makkelijk wordt gemaakt een kopietje te maken.

Dit zie je af en toe inderdaad langs komen op Linux. Laatst heeft HBO heel Linux in de ban gedaan... Maar ja, GPL eist dat apparatuur die van jou is, naar jouw bevelen luistert en niet naar wensen van TV fabrikanten en media conglomeraten.

En delen van certificaten? Zodat je concurrentie geholpen wordt?

Als het goed is, concurreert een fabrikant met betere producten voor betere prijzen. Juist andersom, wanneer jij een gesloten ecosysteem mag handhaven, dan krijg je een vendor-lock en hoef je helemaal niet meer te innoveren.

Zodat staatshackers makkelijker op telefoons van journalisten kunnen kijken?

Security by Obscurity. Als jouw beveiligingsmodel afhankelijk is van een verborgen sleutel op de hardware welke elke staatshacker kan kopen in de winkel... dan is jouw beveiliging al gekraakt.

[bzzzt]

Natuurlijk hoef je geen garantie te geven op onderdelen van anderen. De GPL heeft hier geen mening over, want dit valt niet onder auteurs- en contractrecht, maar consumentenrecht.

Je vergeet daarbij wel dat reputatieschade een ding is. Als de grote massa mensen jouw apparaten voorziet van goedkope onderdelen krijgt daardoor jouw spul een slechte naam. Persoonlijk zou ik die vrijheid wel willen maar ik begrijp dat fabrikanten daar niet op zitten te wachten.

Dit zie je af en toe inderdaad langs komen op Linux. Laatst heeft HBO heel Linux in de ban gedaan... Maar ja, GPL eist dat apparatuur die van jou is, naar jouw bevelen luistert en niet naar wensen van TV fabrikanten en media conglomeraten.

De GPL is geen wet, en geen persoon dus heeft niets te eisen. Je mag kiezen alleen GPL software te gebruiken, maar dan moet je jezelf zo'n beetje alle mainstream content ontzeggen.

Als het goed is, concurreert een fabrikant met betere producten voor betere prijzen. Juist andersom, wanneer jij een gesloten ecosysteem mag handhaven, dan krijg je een vendor-lock en hoef je helemaal niet meer te innoveren.

Als het mogelijk is dingen efficiënter te doen zal je zien dat een gesloten ecosysteem je niet redt van disruptie.

Security by Obscurity. Als jouw beveiligingsmodel afhankelijk is van een verborgen sleutel op de hardware welke elke staatshacker kan kopen in de winkel... dan is jouw beveiliging al gekraakt.

Zo'n beetje alle 2FA oplossingen maken gebruik van een verborgen sleutel in hardware. Zijn die allemaal al gekraakt?
Met 'staatshacker' bedoel ik een partij die 'onbeperkt' geld heeft om dingen te doen als backdoors in smartphone onderdelen (software en hardware) te installeren en exploiteren. Het afdwingen van 'valide' onderdelen door een fabrikant voorkomt dat vreemde partijen software of hardwarewijzigingen die niet altijd in jouw voordeel zijn doorvoeren.

[MSalters]

Stallman leeft dan natuurlijk ook in een ander tijdperk. Tegenwoordig wil je als gebruiker niet dat de software van je vingerafdrukscanner vervangen wordt. Wie zou dat doen? Dan moet je denken aan de NSA of één van hun collega-organisaties. Apple staat juist aan de kant van de gebruikers. Dat is een omkering van de rollen die Stallman niet voorzien had.

[Q]

In het geval van Apple, maakt het bijvoorbeeld bepaalde reparaties door derden onmogelijk. Ook kun je geen eigen OS vanaf een mac booten en zo maakt het de vendor-lock van bepaalde leveranciers weer een stukje groter

Naar mijn weten is het geen enkel probleem om Linux op een Mac te draaien. Dus ik vraag me af wat je hier mee bedoeld.

[dec0de]

Linux ondersteund geen T2 chip (de T1 ging nog dacht ik). En op de ARM macs kan het alleen nog gevirtualiseerd. (Bron: interview van craig federighi met MKBHD)

Apple maakt namelijk niks bekend over de T2 chip, en voordat je bij de opslag kan komen moet je al met de T2 chip praten.

[Q]

Naar mijn weten kun je de secure boot opties uitzetten als je dat wilt. Hoe dat gaat lopen bij ARM macs weet ik niet, maar ik vraag me af of de soep zo heet wordt gegeten?

https://support.apple.com/en-us/HT208198

Heb je een link naar dat interview of leesbaar bronmateriaal?

[sfranken]

n het geval van Apple, maakt het bijvoorbeeld bepaalde reparaties door derden onmogelijk. Ook kun je geen eigen OS vanaf een mac booten en zo maakt het de vendor-lock van bepaalde leveranciers weer een stukje groter.

Is dat zo? Ik heb hier Fedora draaiend op een Mac Pro (een ronde, dat wel) en bij een kennis op een 27 inch 2019 iMac. Hetzelfde werd jaren geleden ook geroepen in paniek over UEFI en de keys die je nodig zou hebben om 'iets anders dan Windows' te kunnen booten. Dat bleek achteraf ook een storm in een glas water

[Eonfge]

De arch wiki is redelijk helder:
https://wiki.archlinux.org/index.php/Mac

Nieuwe MacBooks met een T2 beveiligingschip (die gene afgebeeld bovenaan dit artikel) bieden geen ondersteuning voor Linux. Je kunt het een beetje werkend krijgen, maar niet zo goed dat je het als daily driver kunt gebruiken.

[sfranken]

De nieuwe iMacs hebben, zover ik kan valideren vanaf hier, ook een T2 chip. Het was inderdaad even een gedoe om dat werkende te krijgen, maar installeren ging gewoon goed hoor. De enige "extra" stap was eerst in recovery mode starten, terminal openen en "csrutil disable" uitvoeren. Anders zie je inderdaad de disk in dat ding niet.

[Blokker_1999]

TPM is een implementatie van een TEE, maar niet elke TEE is een TPM module (zoals de T2 chip van Apple bijvoorbeeld)

Er is ook niet veel mis met een TEE, zolang je weet dat deze er is en zolang je deze kan en mag negeren. Iets wat op de meeste computers nog altijd het geval is. Belangrijkste uitzondering daarop is Apple.

Verder zijn veiligheid en privacy wel met elkaar verbonden, maar zeker geen synoniemen van elkaar.

[The Zep Man]

TPM is een implementatie van een TEE, maar niet elke TEE is een TPM module

De TPM kan je beter vergelijken met een smartcard. Een TEE is een actief onderdeel zodra je de computer aanzet (en soms zelfs als die 'uit' staat). Een TPM werkt enkel als die wordt aangesproken vanuit een untrusted omgeving (vanuit de BIOS/UEFI, vanuit de boot loader, en vanuit het OS). Als de TPM niet wordt aangesproken dan doet die ook niets.

Er is ook niet veel mis met een TEE, zolang je weet dat deze er is en zolang je deze kan en mag negeren.

In Intel AMT, een management onderdeel van Intel ME (een TEE), en in Intel MEE zelf zijn in het verleden kwetsbaarheden aangetroffen, en updates zijn niet altijd beschikbaar. Intel ME is zonder hacks niet te neutraliseren, en kan nooit volledig verwijderd worden omdat de CPU anders na 30 minuten zichzelf uitschakelt.

Negeren kan, maar de keuze aan de eigenaar van het apparaat geven is altijd beter. De facto beveiliging is goed, maar ze zouden vrijheid niet in de weg mogen staan. Secure Boot op x86? OK. Zet het uit. Secure Boot op ARM (Windows RT machines)? Niet uit te schakelen. Waarom moet er een verschil zijn, als de hardware niet in eigendom van de fabrikant is?

[edit]
Vroeger was de TPM een aparte chip. Tegenwoordig spreekt men vaak van een virtual TPM, die vanuit een TEE wordt aangeboden. De logische werking en aansturing zijn hetzelfde.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 15:47]

[martijnvanegdom]

Overigens AES 256 is een symmetrische encryptie standaard niet een a-symmetrische.. (Zoals RSA dat wel is) dus het is niet correct wat er geschreven word.

Ik ben niet zo bekend met Keychain, maar ik verwacht dat er een a-symmetrisch private key word gebruikt om een symmetrische secure op te slaan.. de a-symmetrische algoritme zijn rekentechnisch vaak erg duur

[Mr.B]

Overigens AES 256 is een symmetrische encryptie standaard niet een a-symmetrische.. (Zoals RSA dat wel is) dus het is niet correct wat er geschreven word.

Precies, jammer dat dit minimale stukje technische verdieping niet gegeven wordt in het artikel. Meer details via https://darthnull.org/sec.../31/secure-enclave-ecies/ en https://medium.com/@alx.g...e-stored-keys-8f7c81227f4

[.oisyn]

Ah ja, zoiets zei ik hier ook al.

maar ik verwacht dat er een a-symmetrisch private key word gebruikt om een symmetrische secure op te slaan

Dat kan, maar je kunt je afvragen wat het nut is van het opslaan van een versleutelde AES-sleutel. De SE zal in ieder geval een sleutel moeten onthouden. Dan kan ie ook net zo goed de AES-sleutel zelf onthouden, dan hoeft er helemaal geen asymmetrische versleuteling aan de pas te komen. Het unlocken gaat meestal met biometrische data (Touch ID), die ook opgeslagen is.

[Razr]

Zo’n chip is de beste plek voor de NSA of andere soortgelijke instantie om een stukje software te plaatsen (Apple en Google moeten meewerken toch, volgens Snowden). Als ik het goed begrijp kunnen ze dan alles met je telefoon zonder dat de rest van je telefoon het weet? Of in ieder geval als de sleutelgeneratie daar plaatsvind inhaken op alle encryptie?

(even theoretisch, oprecht waarom een -1?)

[Reactie gewijzigd door Razr op 23 juli 2024 15:47]

[arjankoole]

De tpm heeft maar zeer beperkte communicatie met de buitenwereld (als het goed is alleen processor/SoC). Dus nee, als de NSA in je de tpm zou zitten, kunnen ze er niet zomaar alles mee. Ze moeten nog steeds fysiek toegang hebben. In de regel is het zo, dat je bij fysieke toegang ook al verloren bent. (Want dan zijn andere, meer eenvoudige hacks) mogelijk.

Als mensen over de NSA beginnen, zeker in Linux hoek, vraag ik wel eens of ze selinux gebruiken, en zo ja: of ze wisten dat de NSA dat geschreven heeft.

Maar zelfs als, dan is het de vraag of de fabrikanten mee zouden werken aan zoiets, omdat het op eigen bodem ongrondwettelijk is. Recent heeft de NSA op hun donder gehad van de rechter daarvoor (1 niveau onder SCOTUS). De NSA kan best veel flikken, en geniet heel bescherming, maar er zijn grenzen, en als ze steeds opnieuw betrapt worden op het breken van de grondwet, krijgen ze echt wel problemen. De NSA mag immers absoluut niet Amerikaanse staatsburgers op eigen bodem bespioneren.

Daarnaast denk ik, dat als ze wel Google, Apple, qualcomm, etc zouden dwingen om dergelijke aanpassingen te doen, het snel zou uitlekken, omdat vertrouwen juist het belangrijke basis principe voor het gebuik van tpm is. Aangezien in veel gevallen (zeker in het geval van Apple) de productie niet door de fabrikant zelf wordt gedaan, is het onmogelijk zulke ingebouwde kwetsbaarheden geheim te houden. Dus of via de fabrikant, of de daadwerkelijke chipmaker zou het waarschijnlijk uitlekken.

[Mr777]

Intel heeft zijn Management Engine en AMD heeft zijn Platform Security Processor, dat is wel voldoende als achterpoortje voor de NSA en de andere "alphabet boys". Die dingen zitten er echt niet in voor de gebruiker van de pc.

[N8w8]

De ME heeft allerlei zinnige toepassingen voor gebruikers, zie bijv hier.
Dat dat ook te exploiten is door kwaadwillenden betekent niet vanzelf dat er een groot complot is.
Het lijkt me waarschijnlijker dat dat gewoon ligt aan dat die ME is gemaakt door mensen, ipv omnipotente superwezens.

[Sandor_Clegane]

Dat hoeft niet perse, je kunt het op deze manier mogelijk maken om binaries te draaien die gewoon een andere signature hebben maar wel door de TPM als juist worden geverifieerd. Dus de code die bijvoorbeeld je wachtwoorden oplepelt kan dan ook door een derde worden opgevraagd als deze de juiste signature heeft.

Die binaries kun je natuurlijk prima via het netwerk op een computer plaatsen.

[Eonfge]

Vergeet Blowback niet. Het is niet handig om een backdoor te bouwen in de software en hardware die door alle Amerikanen wordt gebruikt:

https://www.schneier.com/...6/04/details_about_j.html
https://blog.cryptography...2/22/on-juniper-backdoor/

In de praktijk heeft de Juniper Router backdoor, de Russen en Chinesen meer geholpen dan de NSA

[GertMenkel]

Mwah, ik denk dat het makkelijker is om code in een PCIe-apparaat te stoppen, die hebben vaak ten minste gewoon toegang tot het volledige geheugen. De T2-chip mogelijk ook, maar dat vereist het omzeilen van een hoop beveiliging van Apple en Apple verzet zich in alle macht tegen pogingen om de sleutels tot hun koninkrijk af te geven.

De random number generator in je processor is denk ik nuttiger als backdoor dan een chip die wat security regelt. Met genoeg geld kun je al gewoon een proces schrijven dat op de meeste TEE's draait (en dus ondetecteerbaar is) en dan noem je het gewoon "DRM". Het onderscheppen van de sleutel uit een TPM is daarmee niet mogelijk, maar ik betwijfel of de NSA dat nodig heeft. TPM's hebben over de jaren genoeg kwetsbaarheden gehad, ik denk niet dat het zo'n probleem is om zo'n apparaat kraken. Zodra de NSA een backdoor in de TPM's heeft, kunnen mensen daar achter komen en daarmee riskeert de NSA hun invloed: niemand zal een backdoorchip meer gaan kopen en er zal een flinke stap worden gemaakt in de veiligheidssystemen van computers waardoor oude aanvallen niet meer werken.

Kortgezegd: theoretisch ja, in de praktijk bijzonder onhandig en waarschijnlijk slechter dan het alternatief.

[Bob de Slager]

(even theoretisch, oprecht waarom een -1?)

Omdat... Snowden. Dat is toch een beetje als de mening van een coca cola drinker aanhalen over de interne bedrijfprocessen op de juridische afdeling van Coca-Cola op het hoofdkantoor. Lekker boeiend, en waarom zou je daar naar refereren?

Het is in praktisch ieder land gebruikelijk dat de veiligheidsdiensten kunnen samenwerken met commerciele ondernemingen binnen een juridisch kader. Het enige relevante verschil tussen landen zijn de checks & balances die dat mogelijk maken en documentatie ervan.

[j-phone]

Je bent geen fan van een persoon die illegale praktijken van veiligheidsdiensten op hun eigen bevolking openbaart?

[Bob de Slager]

Dat is niet wat hij gedaan heeft. Hij heeft staatsgeheimen doorgespeeld aan vijandige (mafia)staten, in dienst van diezelfde (mafia)staten zonder ooit binnen de NSA organisatie zijn zogenaamde bezwaren te melden.

Ook was hij al data aan het stelen van de NSA voordat hij volgens hemzelf een openbaring had over burgerrechten.

Deze beste man is een stuk gereedschap van schurkenstaten om het alziend oog in het arsenaal van de democratie (de NSA) minder effectief te maken.

[j-phone]

Maar de NSA is toch veroordeelt door de informatie die Snowden vrijgaf?

En met Trump aan de macht is de NSA al snel een alziend oog van een schurkenstaat aan het worden.

[Bob de Slager]

Je kan een illegale werkwijze in je overheidinstelling gewoon aankaarten bij de "inspector general".

Vervolgens moet er wat mee gebeuren of via politiek (we passen de wet aan) of juridisch (een rechter mag een bindende uitspraak doen). Dus waarom staatsgeheimen gaan uitdelen...

Schurkenstaat in wording of niet, niet alle instituties gaan zomaar overstag, en je kan ook niet zomaar even een trekpop neerzetten.

(Al moet ik zeggen dat er weinig over is van de Republikeinse partij, ooit in een ver verleden de partij met focus op law&order en nationale veiligheid).

[j-phone]

En toch kan je niet alles bedekken met de mantel der 'staatsgeheim', macht concentreerd zich dan maar al te makkelijk in een klein centrum. Het wordt dan heel lastig om aan te pakken, ook door de instituties in een land die maar al te makkelijk te ondermijnen en zelfs chantabel zijn. Zeker door een NSA.

Anyway, dank je voor de verheldering van je standpunt. Zelf blijf ik van mening dat klokkeluiders, in dit soort gevallen, een trendbreuk teweeg kunnen brengen en ook awereness kweken.

[Eonfge]

@Q reactie op de verkeerde plek gezet

-----

Uitgebreide wiki:
https://wiki.archlinux.org/index.php/Mac

Lang verhaal kort, sinds de introductie van TPM modules in Macs, is het installeren van Linux niet eenvoudig.

Daarnaast mis je de kern van mijn opmerkingopmerking, namelijk dat TPM-modules door fabrikanten kunnen worden gebruikt om legitieme eigenaren in de weg te zitten

[Reactie gewijzigd door Eonfge op 23 juli 2024 15:47]

[Q]

@Eonfge helder verder!

Daarnaast mis je de kern van mijn opmerkingopmerking, namelijk dat TPM-modules door fabrikanten kunnen worden gebruikt om legitieme eigenaren in de weg te zitten

Zijn daar concrete en niet-esoterische voorbeelden van? Iets wat ook resoneert bij de doorsnee Tweaker?

[Blokker_1999]

Apple dat niet langer toestaat dat je zelf onderdelen vervangt of herstellingen uitvoert.

[Q]

Is daar hard bewijs voor? Volgens mij werkt het nog steeds prima en kan ik Linux installeren op moderne Apple hardware (mac).

[Reactie gewijzigd door Q op 23 juli 2024 15:47]

[GertMenkel]

Door de T2-chip kun je op veel macs de SSD niet meer vervangen (want de sleutel staat daarop). Als je Linux met de T2-chip kan laten samenwerken heb je waarschijnlijk geen last van deze problemen, maar als je macOS wil blijven gebruiken heb je dat wel. Apple gebruikt namelijk cryptografische sleutels om hardware te verifiëren en daarmee te voorkomen dat je zomaar apparaten kan vervangen. Het moederbord en de vingerafdruklezer zijn daar voorbeelden van, maar met een enkele firmwareupdate volgt je batterij of je scherm. Daar zitten securityvoordelen aan maar die wegen compleet niet op tegen de nadelen, gezien Apple zich in het verleden al heeft opgesteld tegen alle vormen van reparatie door derden.

[Q]

Heb je linkjes met hard bewijs want volgens mij klopt dit niet en kun je SSD’s voor zover ze niet vadt gesoldeerd zitten gewoon vervangen.

[GertMenkel]

Bijvoorbeeld: SSD-modules installeren of vervangen in uw Mac Pro (2019)

Okee, je kunt hem wel vervangen als je maar accepteert dat je de hele SSD wist, als je maar een tweede Mac, een USB C-to-C-kabel en een compatible SSD koopt. Je kunt niet opstarten van een niet-Apple-schijf, dus je zit vast aan Apple-hardware (al is het maar om een boot drive te hebben). Dit kan overigens pas sinds drie maanden omdat de SSD's eerder niet te verkrijgen waren, dus deze mogelijkheid is me ontglipt. Ik gebruik om deze exacte reden dan ook geen Apple-apparatuur.

[Q]

De soep wordt duidelijk niet zo heet gegeten als dat jij hier loopt te beweren

Je toont zelf aan dat er wel wat aandachtspunten zijn, maar dat het allemaal prima kan.

Mijn vermoeden dat er niets van klopt, is dus bevestigd.

Bovendien boot ik als mac mini gebruiker zelf van een externe SSD.

Ik proef bij jou helaas weer een soort emotionele / politieke aversie jegens Apple die dan met niet-onderbouwde beweringen wordt onderbouwd, maar uiteindelijk klopt het niet.

[GertMenkel]

Ja, ik ben tegen de handelspraktijken van Apple, maar ik heb wel begrip voor hun beweegredenen en als jij de voordelen van hun hardwareprogramma vindt opwegen tegen de nadelen, vind ik ook zeker dat je gebruik moet blijven maken van hun apparatuur.

Als ik als consument een standaard-SSD koop of er eentje uit een oude Mac haal en deze in een nieuwe Mac stop, doet hij het niet; dat is de crux van het probleem. Ja, ik kan het laten werken door de Apple-SSD te wipen of door de SSD in het tweede slot te plaatsen met hulp van iemand in mijn omgeving die een Mac heeft, maar laten we realistisch blijven: Apple voorkomt hier duidelijk dat jij als consument je hardware vervangt. Als het antwoord op "hoe vervang ik mijn kapotte SSD" is "koop een SSD bij Apple en een tweede Mac" dan vind ik niet dat je dat onderdeel als "vervangbaar" kan noemen.

Dat Apple tegenwoordig via officiële kanalen SSD's verkoopt is iets waar ik vandaag pas achter ben gekomen, de laatste keer dat ik naar het iEcosystem heb gekeken was dat namelijk alleen mogelijk via de support van Apple. Ik vermoed dat alle aandacht die ze van de Amerikaanse politiek hebben gekregen ze heeft doen bewegen naar het verbeteren van de vrijheden die hun klanten over hun hardware hebben. Ik ben blij dat het vervangen sinds een paar maanden kan, ook al vind ik de prijs die ze vragen behoorlijk. Het blijft echter zo dat je een Apple-SSD nodig hebt om de Mac Pro op te starten, dat die SSD moet zijn geassocieerd met je T2-chip en dat tot voor kort die SSD's niet te verkrijgen waren zonder ze via het serviceprogramma van Apple te laten bestellen in een winkel. Ik ben ook zeer benieuwd of je externe opstartschijf nog steeds werkt als je de interne SSD eruit haalt, want voor zover ik heb kunnen vinden wordt het bootproces gestart op de T2-SSD. Wellicht hebben ze de T2 voor de Mini anders geprogrammeerd dan die voor de Pro, dat zou kunnen. Als dat niet zo is, is de Mini inderdaad wel degelijk te onderhouden.

De vingerafdruklezer in de touch bar kan overigens dus niet zelf worden vervangen en de T2 controleert wel degelijk de hardware door middel van cryptografische sleutels. Momenteel wordt er weinig mee gedaan als er een mismatch is, maar een update voor de T2 firmware kan daar snel verandering in brengen. Op hun telefoons hebben ze zulke features bijvoorbeeld al geactiveerd en moet een batterij worden geassocieerd met je telefoon als je die installeert voordat de telefoon hem als okay accepteert, ook al is het een origineel onderdeel (dat je overigens zelf niet legaal nieuw kan krijgen). Het vervangen van het scherm kan zomaar leiden tot gebrickte telefoons als Apple de volgende update weer besluit geen andere schermen te tolereren.

Ik wil niet pretenderen dat Apple net zo erg is als John Deere maar iedere release worden iMacs/Macbooks/iPads/iPhones weer ietsje lastiger om zelf onderdelen in te vervangen. Met de aankomende Macs gebaseerd op hun eigen chips verwacht ik dat de iMacs weer een stapje dichter naar de beperkingen van iOS toegaan; bootcamp wordt onmogelijk dus de ondersteuning voor alternatieve besturingssystemen kan compleet worden laten vallen en de recente vereiste dat iedere applicatie door Apple online geverifieerd moet worden (niet per se ondertekend) voor deze mag draaien vind ik een duidelijk teken dat Apple meer macht in zijn ecosysteem wil hebben en nu ze volledig hardware-onafhankelijk beginnen raken van algemene hardware zoals Intel is het alleen maar logisch dat ze die kans grijpen.

Als je dit als klant waardeert omdat je de veiligheid en garantie dat de boel blijft werken belangrijker vindt dan het zelf beheren en onderhouden van je systeem, is dat prima; de keuze ligt aan jou. Voor veruit de meeste mensen zijn de T2-beperkingen een feature, geen probleem.

[Q]

Ik vind het zelf wat moeilijk om in het artikel de essentie te begrijpen van wat een Trusted Execution Environment nu werkelijk is en doet.

Wat is het fundamentele security risico / wat zijn de fundamentele security risico's en wat zijn nu precies de mechanismes om die risico's te mitigeren?

Voorbeeld: ik heb een Apple Mac en als ik een wachtwoord invoer bij keychain kan ik al mijn plain text wachtwoorden met mijn oogjes bekijken. Maar als dat kan, dan kunnen al die wachtwoorden ook door software bekeken worden / gestolen, of mis ik hier een punt? Ik moet wel regelmatig mijn wachtwoord invullen maar malware kan die prima afvangen.

Dus wat is in deze context nu de meerwaarde van een Trusted Execution Environment?

Ik leer dat het soms een gevirtualiseerde oplossing is voor iets en soms wordt het in hardware uitgevoerd (als onderdeel van de SoC of als een apparte chip). Maar wat doet het nu precies?

Zoals ik het begrijp is de essentie dat een 'tee' functioneert als een soort orakel. Je kunt nooit bij het cryptografische materiaal komen (afhankelijk van wat het doet), je kunt alleen toetsen (ja/nee) bij het orakel (de Trusted Execution Oplossing) of de credentials juist zijn of niet.

Wat heb je hier aan? Dat je nooit een identiteit kunt spoofen, je moet de fysieke controle hebben over een stukje harware. Ik kan dus nooit op het enterprise netwerk komen door credentials van een gestolen laptop te gebruiken (een voorbeeld). En ik kan beschermen tegen een evil-maid attack.

In het geval van Apple's iPhones wordt de vingerafdruk / Face-id data in de 'secure enclave' opgeslagen, zodat dit soort biometrische informatie nooit van het device gestolen kan worden, zelfs niet als de telefoon gehacked wordt.

Sommige aspecten worden wel besproken in het artikel maar veel later pas.

Ik denk dat ik als leek liever eerst wat concrete voorbeelden (scenario's) zou willen zien in het artikel om te begrijpen wat de risico's zijn, hoe 'tee's' hier een rol spelen bij de mitigatie om een beter gevoel voor de context te krijgen. Ik heb persoonlijk iets minder affiniteit met de geschiedenis/history, dat mag verder op in het artikel, als ik wat meer context heb.

[Reactie gewijzigd door Q op 23 juli 2024 15:47]

[Sandor_Clegane]

De TPM functioneert als een trusted third party. Net als met certificaten heb je een trusted third party die in staat voor de validiteit van een certificaat en dat diegene die het certificaat heeft ook daadwerkelijk is wie hij zegt dat hij is ( hoe dat in de praktijk gaat, laten we even in het midden ) en in dit geval is dat een TPM.

In je voorbeeld kan de binary die je wachtwoorden opvraagt aan de hand van zijn software signature door de TPM worden gechecked of deze daadwerkelijk overeenkomt met wat er verwacht wordt. Komt het niet overeen dan werkt het niet. Bijvoorbeeld of het wel de signature van Apple heeft.

Het kan nog veel meer maar in essentie is het een "known good" van waaruit je het systeem kunt "opbouwen". Mijn kernel heeft de juiste signature, dus er is niet mee geklooid, de services die deze kernel dus opstart worden ook gechecked en als ze de juiste signature hebben, gechecked door de TPM, dan worden ze opgestart etc. etc. Zo kun je, als je dit doorzet, instaan voor de integriteit van het complete systeem.

Edit: een TPM is nu onderdeel van TEE? Oh man, standaarden.

Oh en als je wilt zien hoe veilig zoiets is: https://www.youtube.com/watch?v=Ec4NgWRE8ik
Hier een aantal mensen die de TEE van de Nvidia Tegra omzeilen voor het hacken van de Nintendo Switch.

[Reactie gewijzigd door Sandor_Clegane op 23 juli 2024 15:47]

[xFeverr]

Overigens kan je Bitlocker ook zonder TPM gebruiken. Je moet dit aanzetten via group policies, maar je kan dus ook met een wachtwoord of USB-stick gebruik maken van Bitlocker.

Maar ik zou het bij de TPM houden als het kan.

[ShellGhost]

Zonder GPO kan dit ook: https://support.microsoft...turn-on-device-encryption
De enige vereiste is dat je minimaal W10 Pro nodig hebt. Home ondersteund het niet.

[Jim80]

We zijn op het punt gekomen dat software en microcode zo complex, onoverzichtelijk en lek is geworden dat we het in dure hardware moeten gaan oplossen

[Xieoxer]

Wat ik mis in het artikel is, dat een tee vaak pas na paar jaar gekraakt wordt. In die jaren ben je als gebruiker veilig. Zo ver ik nu weer is de huidige Apple T2 chip nog niet gekraakt. Deze chip zit zowel op alle iDevices als MacBooks. De intergratie zal op de MacBook alleen maar beter worden als ze overstappen naar hun eigen chip. Mijn vermoeden is tevens dat er binnenkort T3 aangekondigd wordt, waardoor Apple weer vooruit loopt qua beveiliging.

[Reactie gewijzigd door Xieoxer op 23 juli 2024 15:47]

[DennusB]

Wat een tof artikel! Heb er echt weer het een en ander van geleerd

[intraxi]

Foutje in het artikel:
Qq
De Secure Enclave maakt daarvoor symetrische Elliptic-curve-encryptiesleutels aan en slaat de privésleutel op.
Unqq
Asymetrisch...