Door Tijs Hofmans

Redacteur

Trusted execution environments

Hoe veilig zijn beveiligde enclaves op chips?

Introductie

De presentatie van de iPhone 5s leek in veel opzichten op andere Apple-presentaties. Er was veel geklap om nieuwe features, zoals TouchID en de voor Nederland geldende 4g-ondersteuning. Er ging ook veel aandacht uit naar de nieuwe processor, die voor het eerst 64bit was. Juist daar werd het opvallend. Wie de presentatie anno 2020 terugkijkt, valt het wellicht op dat beveiliging amper wordt genoemd. Dat is heel anders dan nu, nu Apple security en privacy tot belangrijk en zelfs essentieel onderdeel van de iPhone heeft gemaakt. Sterker nog, in de presentatie wordt over een specifiek onderdeel niet eens gerept, hoewel juist dat onderdeel de toon zette voor de beveiliging die we nu kennen. Het gaat om de fysieke Secure Enclave, die de nieuwe vingerafdrukscanner beveiligt.

Met de Secure Enclave van Apple werd voor het eerst een dergelijke hardwarematige beveiligingsmodule toegepast in een smartphone. Apples A7-chip is niet de eerste soc die zoiets heeft. Het is slechts de implementatie van wat een trusted execution environment wordt genoemd, afgekort een tee. Er zijn ook andere benamingen voor; professionele Windows-gebruikers kennen wellicht tpm, een fysieke module die op het moederbord moet zitten voordat volledige Bitlocker-schijfencryptie mogelijk is. Verschillende chipfabrikanten hebben eigen implementaties; Apple noemt het de Secure Enclave, Intel gebruikt zowel Software Guard Extension als Trusted Execution Engine en AMD noemt hetzelfde proces Secure Encrypted Virtualization. Ze doen allemaal hetzelfde, maar net een beetje anders.

Afgesloten onderdeel

In essentie is een trusted execution environment niets anders dan een onderdeel van een system-on-a-chip dat afgesloten is van de rest van de soc. Er kunnen dan acties worden uitgevoerd in de tee die geheim blijven voor de rest van de chip. Denk daarbij aan het authenticeren via een wachtwoord of biometrie, of het signen van keys. In sommige gevallen is een tee virtueel en wordt de beveiliging softwarematig gedaan. In andere gevallen, zoals bij Apple in de A7-chip van de iPhone 5s, gaat het om een stuk hardware. Beide hebben voor- en nadelen, maar het belangrijkste punt is dat een trusted environment bepaalde zaken op een telefoon, tablet of computer een heel stuk veiliger maakt. In dit artikel kijken we naar wat een tee is, hoe het werkt en welke verschillende vormen er zijn.

Duizend namen, duizend definities

Als je het heel letterlijk - en lelijk - vertaalt, is een trusted execution environment een 'vertrouwde uitvoeringsomgeving'. De vertaling mag dan te wensen overlaten, de beschrijving zegt precies wat een tee is. Het is een vertrouwde omgeving, in dit geval op een soc, waarin belangrijke processen kunnen worden uitgevoerd die je liefst goed afgesloten wil hebben van andere processen op die soc.

Het idee om beveiligingsprocessen te isoleren is niet nieuw of zelfs recent. Jaren geleden bestond al de trend om die processen expres zo ingewikkeld te maken dat ze moeilijk te vinden waren voor bijvoorbeeld aanvallers. Dergelijke security through obscurity is inmiddels behoorlijk achterhaald en het is zowel simpeler als veiliger voor ontwikkelaars om beveiligde omgevingen als zodanig aan te duiden. Inmiddels zijn tee's dan ook ingeburgerd in de chipwereld.

'Tee' is een vergaarterm; hoe een chipfabrikant het uitvoert, verschilt. Een tee wordt soms ook een secure element genoemd, maar dat is de benaming voor een aparte standaard. De termen worden veelvuldig door elkaar gebruikt en niet altijd correct. Daarom is het handig om eerst wat begrippen te ontleden.

Trusted execution environment

Tee beschrijft een proces waarbij een specifiek gedeelte van een soc wordt aangewezen om bepaalde beveiligde processen uit te voeren. Dat kan zowel gevirtualiseerd met software gebeuren als fysiek met een aparte hardwarechip. Meestal is het een combinatie van beide.

Tee is ook een officiële standaard van het GlobalPlatform. In de praktijk is het een allesomvattende term om het bovenstaande proces te beschrijven. Een trusted environment wordt meestal een tee genoemd, zelfs als het niet officieel door de standaardisatieorganisatie als zodanig is erkend.

Tee's worden gebruikt voor een hoeveelheid toepassingen. Sleutelbeheer is een belangrijke, maar tee's worden ook gebruikt voor digital rights management, tweestapsverificatie en remote attestation. Daar gaan we verderop in dit artikel dieper op in.

Secure element

Een secure element is een andere standaard dan tee, maar in feite doet het hetzelfde. Het verzorgt beveiligde processen, maar vaak in een andere fysieke vorm. Se's zitten doorgaans in betaalkaarten of smartcards in de vorm van een kleine chip. Communicatie vanaf een se gaat in de meeste gevallen over nfc.

Secure Enclave

De term Secure Enclave wordt in de volksmond nogal eens gebruikt om een tee te beschrijven, maar dat is net als een navigatiesysteem TomTom noemen of jaloezieën Luxaflex. De Secure Enclave is Apples merknaam voor de implementatie van een trusted environment in iPhones en Macs. Ook andere fabrikanten gebruiken hun eigen namen, al worden die niet zo vaak gebruikt als die van Apple.

Trusted platform module

Trusted platform modules of tpm's zijn een specifieke implementatie van trusted environments die ook weer een eigen standaard hebben. Dat maakt het gemakkelijker voor fabrikanten om er iets omheen te bouwen. De internationale norm ISO/IEC 11889 werd in 2009 opgezet door de Trusted Computing Group en wordt door veel fabrikanten gebruikt.

Waar trusted execution environments voor veel verschillende doelen kunnen worden gebruikt, zijn tpm's vooral bedoeld voor encryptie. Ze kunnen geen tweestapsverificatie verzorgen of niet altijd aan secure boot doen, maar ze hebben wel een random number generator en worden gebruikt voor zowel het aanmaken en opslaan van cryptografische sleutels als remote attestation.

Trusted platform modules zijn ook los te koop

Hoe werkt het?

Er zijn verschillende methodes om een aparte securityomgeving te creëren. In sommige gevallen, zoals Arm doet met zijn bekende TrustZone, gebeurt dat virtueel. Er wordt een virtuele silo in de microkernel aangemaakt, waarop vervolgens via de firmware cryptografische berekeningen worden gedaan. Dergelijke virtualisatie is al oud; Arm begon er al mee in 2004 in de ARMv6K-infrastructuur.

Beveiliging via firmware brengt echter risico's met zich mee. Malware kan de software op verschillende manieren aanvallen. Dat dat niet ondenkbaar is, bleek bijvoorbeeld vorig jaar, toen onderzoekers een manier vonden om de Secure World-tee van Qualcomm-socs te kraken. Secure World is gebaseerd op TrustZone en werkt volledig virtueel. Toegegeven, het lek was in de praktijk lastig uit te buiten, maar toch komen er met regelmaat dergelijke kwetsbaarheden voorbij.

Fysieke chip

Een tee is vaak een fysieke chip op de soc, meestal een ARM-chipSteeds vaker wordt daarom gebruikgemaakt van fysieke trusted execution environments. Dat kan op twee manieren. In de meeste gevallen zit de fysieke die op de soc zelf en is het een op zichzelf staande chipset, maar dan kleiner dan de hoofd-cpu. De meeste fabrikanten maken gebruik van een ARM-core, bijvoorbeeld de ARMv7- en ARMv8-cpu's in de T1- en T2-chips, die Apple in zijn MacBooks gebruikt. De cpu's draaien op een eigen L4-based microkernel en hebben een bepaalde hoeveelheid opslaggeheugen. Omdat die chips gebruikmaken van ARM-kernen, gaat het vaak om een eigen, dikwijls aangepaste implementatie van TrustZone. Het is dan aan de fabrikant om er een eigen microcode en de cryptografische protocollen omheen te schrijven.

Buiten de soc

Een chip kan ook fysiek buiten de soc worden geplaatst. Onder andere Google doet dat sinds 2018 in de Pixel 3-smartphones. Daarin zit een trusted execution environment in de vorm van de Titan M-chip. In tegenstelling tot Apples Secure Enclave of Intels Secure Guard Extensions zit de Titan M op een andere plek op het moederbord. Oldskool Windows-gebruikers of huidige Enterprise-gebruikers kennen misschien nog een andere vorm van deze chips. Trusted platform modules of tpm's zijn fysieke modules die op het moederbord kunnen worden gezet. Ze zijn bijvoorbeeld nodig om Windows' Bitlocker-schijfencryptie te gebruiken.

Bitlocker werkt alleen met een tpm

Sleutels matchen

Aangezien Apple de eerste was die Secure Enclaves op mobiele apparaten implementeerde, is het een goed idee de iPhone te pakken als illustratief voorbeeld van hoe tee's werken. Neem bijvoorbeeld Keychain, Apples eigen wachtwoordopslag voor iOS en inmiddels macOS. Keychain is een veilige opslag van verschillende soorten data. De meest voor de hand liggende zijn wachtwoorden. Vanaf de iPhone 5s wordt daar de Secure Enclave voor gebruikt, die dus fysiek op de soc zit.

De Secure Enclave van Apple heeft onder andere een versleuteld geheugen, een random number generator voor het genereren van sleutels en nog een paar andere functies. Keychain is eigenlijk niets meer dan een SQLite-database op de iPhone zelf. In die database staan wachtwoorden die zijn versleuteld. De Secure Enclave maakt daarvoor symmetrische Elliptic-curve-encryptiesleutels aan en slaat de privésleutel op. De public key kan worden verzonden naar de rest van de soc en worden gebruikt om de data daar lokaal te versleutelen. Op het moment dat een wachtwoord ontsleuteld moet worden, gebeurt dat aanvankelijk op de Secure Enclave en wordt een shared secret gebruikt waarmee op de gewone soc kan worden geverifieerd of de sleutels overeen komen.

Daarbij is het ook belangrijk te weten dat de sleutel zelf de Secure Enclave niet verlaat, want dan zou die te onderscheppen zijn. In plaats daarvan wordt de check op de Secure Enclave-processor gedaan en wordt er een ja of nee doorgegeven aan de hoofdprocessor; klopt deze key of klopt hij niet? Dat dat een stuk veiliger is dan die berekening op de hoofdprocessor uitvoeren, mag duidelijk zijn.

Preloaden

Overigens gebruikt Keychain zowel encryptie van metadata van het wachtwoord als een secret key voor het daadwerkelijke wachtwoord. Beide worden beschermd door de Secure Enclave, maar in het eerste geval haalt de applicatieprocessor de data alvast op via een cache, terwijl de secret key volledig door de Secure Enclave wordt gehaald. Dat gebeurt met het oog op snelheid. Hetzelfde gebeurt bij de meeste andere tee-applicaties. Ook bij een secure boot wordt bijvoorbeeld het rich execution environment, het 'normale' besturingssysteem, vaak tegelijk geladen.

Het aanmaken van de sleutels en het decrypten van versleutelde data gebeurt dus allemaal lokaal in de chip om te voorkomen dat de data kan uitlekken. Het geheim van de chef is vervolgens hoe de trusted execution environment communiceert met de rest van de soc. Daar zijn verschillende manieren voor. Voor implementaties op basis van TrustZone heeft Arm bijvoorbeeld eigen software gemaakt, maar fabrikanten kunnen er ook zelf iets van maken. Die kunnen ervoor kiezen er een eigen microkernel voor te schrijven of gebruik te maken van bestaande microkernels. Een voorbeeld daarvan is MobiCore van Trustonic. Er zijn daarnaast verschillende initiatieven die proberen om een open source, gratis microkernel op basis van Linux te bouwen die fabrikanten voor tee's kunnen gebruiken.

Alternatieve toepassingen van tee's

Tot nu toe hebben we het vooral gehad over de beveiligingsaspecten van tee's. Daar staan ze ook vooral om bekend. Kijk alleen al naar de namen die verschillende fabrikanten ervoor gebruiken: Secure Enclaves, Secure Encrypted Virtualisation, Software Guard Extensions... Maar om welke beveiligingsfuncties gaat het precies? Het is namelijk meer dan alleen het ver- en ontsleutelen van data. Een andere belangrijke vraag is welke alternatieve gebruiken tee's hebben, want beveiliging is zeker niet de enige functie.

Drm

Trusted execution environments zijn uitermate geschikt voor digital rights management. Dat is bijvoorbeeld terug te zien op de website van GlobalPlatform, dat regelmatig 'premium content' noemt bij het formuleren van de standaard. Voorbeelden van drm-implementatie in tee's zijn Microsofts PlayReady-technologie en Sony's bescherming voor mediaspelers. Daarbij wordt drm-bescherming in de afgezonderde silo geplaatst en uitgewisseld met de mediaspeler. Alleen als die twee sleutels overeenkomen, kan een gebruiker iets bekijken. Omdat de drm-codecs zelf diep zijn weggestopt, is het voor piraten lastig te kopiëren.

Tweestapsverificatie

Beveiligde enclaves zijn behalve voor encryptie ook geschikt voor tweestapsverificatie en drmOp het gebied van beveiliging worden tee's nu vooral gebruikt voor het uitvoeren van cryptografische berekeningen en het authenticeren van gebruikers. Dat laatste kun je doortrekken in een staaltje 'securityception' waarbij tee's voor tweestapsverificatie worden ingezet. Het idee erachter is logisch. Voor tweestapsverificatie geldt het oude principe dat je 'iets dat je hebt of bent', kunt gebruiken voor authenticatie. We schreven daar eerder over in een achtergrondartikel over de toekomst van het wachtwoord. Het 'hebben' betreft meestal een fysieke token, zoals een beveiligingssleutel, maar je kunt ook biometrische authenticatie gebruiken om te bewijzen dat je inlogt. Het probleem dat door die twee vormen van tweestapsverificatie wordt opgelost, is dat inloggen met een sms, e-mail of totp-code overal ter wereld kan gebeuren. Met een fysieke token of biometrische authenticatie kan inloggen alleen vanaf dezelfde fysieke plek als waar je op dat moment bent.

Als je die redenering doortrekt, kun je zien hoe tee's geschikt zijn voor tweestapsverificatie. Het is immers een afgesloten gedeelte waardoor de veiligheid gewaarborgd is, maar tegelijk bewijst het wel dat de gebruiker toegang heeft tot het fysieke apparaat waarop hij inlogt.

In de praktijk is 2fa op tee's nog niet erg ingeburgerd. Dat ligt vooral aan de verschillende implementaties. Zo keken twee onderzoekers van de Radboud Universiteit en de Universiteit Twente een paar jaar geleden naar zowel Intels SGX als Arm's TrustZone in combinatie met 2fa. Hun conclusie was dat de specifieke implementaties net een aantal functies misten om het proces echt veiliger te maken dan andere vormen van 2fa. Zo miste Intel een veilige input voor gebruikersdata en heeft TrustZone te veel variaties om een universeel systeem te bouwen. Bovendien heeft TrustZone daar niet de juiste software-implementatie voor, concluderen de onderzoekers.

Toch is de droom van 2fa in tee's niet helemaal dood. Er zijn initiatieven om de fido-standaard, die onder andere veel gebruikt wordt in fysieke securitysleutels, te integreren in tee's. Google doet dat bijvoorbeeld op de Titan M-chip, die van dezelfde hardware gebruikmaakt als de Titan Key. Ook het GlobalPlatform heeft fido sinds 2018 in de tee-api opgenomen. Dat kunnen softwaremakers gebruiken, al gebeurt dat nog niet veel. Een wel veelgebruikte implementatie is Microsofts Hello, dat via tpm's in laptops loopt.

Beveiligingssleutels zoals die van Yubico en Feitian werken op basis van de fido-standaard

Secure boot

Veel tee-implementaties worden gebruikt om apparaten veilig te starten. Fabrikanten gebruiken verschillende manieren om secure boots op te zetten, maar in essentie wordt eerst een tee gestart waarin een certificaat wordt gecontroleerd op authenticiteit. Dat certificaat garandeert dat de software elke keer hetzelfde is. Wanneer er dus bijvoorbeeld een rootkit wordt opgestart in de uefi of bios matchen de certificaten niet meer.

Remote attestation

Tpm's kunnen tee's voorzien van remote attestationSommige tpm's kunnen helpen met remote attestation. Dat is een proces waarbij de combinatie van hard- en software van een afstand kan worden gevalideerd. Trusted platform modules kunnen worden gebruikt om een key pair aan te maken dat vervolgens wordt gedeeld tussen de client, dus de tpm, en een server. Dat is voornamelijk interessant voor enterpriseomgevingen. Daar kunnen systeembeheerders controleren welke apparaten wel en welke niet met een netwerk verbinding kunnen maken.

Tee's in de vorm van een tpm hebben verschillende voordelen voor remote attestation. De sleutels worden bijvoorbeeld met een geverifieerde module aangemaakt en zijn niet te exporteren door externe partijen. Dat maakt authenticatie op afstand mogelijk door die authenticatie aan hardware te verbinden, net als bij het concept van 'iets dat je hebt', dat we bij tweestapsverificatie beschreven.

Verschillende vendor-implementaties

Inmiddels hebben alle chipfabrikanten wel een eigen vorm van tee's, met veel onderlinge verschillen. Sommige fabrikanten hebben bijvoorbeeld een puur softwarematige oplossing en andere kiezen juist voor een hardwarematige. In slechts een paar gevallen hebben de fabrikanten een eigen tee gebouwd. In het merendeel van die versies maken de fabrikanten gebruik van TrustZone van Arm. Ook als bedrijven een hardware-implementatie hebben, zoals Apples Secure Enclave, gaat het vaak gewoon om een aangepaste versie van TrustZone.

Arm

Dat de basis van veel tee's in Arm's TrustZone ligt, is niet gek, want TrustZone bestaat al jaren en werkt bewezen goed. ARM Cortex-processors draaien hun eigen besturingssysteem op een aparte core. TrustZone werkt op zowel Cortex-A- als Cortex-M-cores, al zit er verschil in functionaliteit tussen die twee. Op de ARMv8-M gaat de dataoverdracht tussen de beveiligde en niet-beveiligde gedeelten via hardware.

Intel

Intel vat zijn tee's samen onder de noemer Trusted Execution Technology. Dat maakt gebruik van een trusted platform module om een hardwarematige enclave te maken. Daarnaast heeft Intel een softwarematige manier om zulke enclaves te bouwen: Software Guard Extensions.

AMD

AMD maakt sinds 2013 gebruik van Secure Encrypted Virtualization. Dat is een software-implementatie die in sommige gevallen samengaat met een fysieke microprocessor, de Platform Security Processor. Die PSP draait op AMD's eigen firmware. Hij wordt gebruikt voor het genereren van sleutels en het valideren van het bootproces.

In 2013 was er nog discussie over die firmware. AMD houdt die closed source, net als concurrent Intel, vanwege de veiligheid. Fans vroegen na de introductie om meer openheid rondom het platform, omdat ze wilden weten of de technologie hun gegevens echt veilig kon houden. Inmiddels is die discussie grotendeels uitgedoofd, mede doordat er tot nu toe weinig incidenten rondom SEV zijn geweest.

Apple Secure Enclave

Apple was de eerste partij die een dergelijke beveiligde omgeving naar de smartphone bracht. De Secure Enclave zit sinds de iPhone 5s op de A-chips van het bedrijf, beginnend met de A7. Veel is er niet bekend over de technische werking van de Secure Enclave. Die begon als een ARM Cortex A5-processor; in nieuwere modellen is het een ARM Cortex A8.

Apples Secure Enclave is gebaseerd op TrustZones techniek, maar het bedrijf heeft daar eigen aanpassingen aan gedaan. Zo gebruikt Apple een eigen technologie genaamd Secure Mailbox om de A-socs te laten communiceren met de Secure Enclave-hardware, maar de precieze werking is vanzelfsprekend Apples geheim.

Google

Google is een van de laatste bedrijven die met een eigen afgezonderde chip voor securityzaken kwamen. Het bedrijf plaatste in 2018 voor het eerst de Titan Key in de Pixel 3. Inmiddels heeft het bedrijf een tweede versie uitgebracht: de Titan M. De Titan-chips zijn deels bedoeld om secure booting uit te voeren, wat Google al onder Project Treble ondersteunde in Android 4.4 en hoger. Aan de andere kant regelt de Titan M ook verschillende beveiligingsaspecten, zoals de ontgrendeling van de telefoon via biometrie, en het slaat privésleutels op die op basis van Androids KeyStore worden aangemaakt. Sinds Android 9 zit er een api in het besturingssysteem, genaamd StrongBox KeyMaster, waarmee onder andere een random number generator in de Titan-chip kan worden aangeroepen, en sleutels met rsa 2048- en aes 256-encryptie kunnen worden aangemaakt en opgeslagen.

Google heeft daarnaast een eigen microkernel geschreven voor tee's op Android. Trusty werkt ook op basis van ARM's TrustZone en is een puur softwarematige virtualisatie die Android-fabrikanten kunnen gebruiken als de soc in hun telefoon geen tee-chip heeft.

Samsung

Samsung maakte altijd gebruik van Arm's TrustZone, maar gebruikt sinds de Galaxy S20 een fysieke chip als tee.

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)

Wijzig sortering
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 7 september 2020 08:52]

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.
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 7 september 2020 08:52]

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.
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
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.
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.
Wat je nu doet is exact dezelfde bangmakerij waarvan je twee posts hierboven Microsoft beschuldigde.
.NET core is open source. Zelfs al zouden ze dat wijzigen: forken en doorgaan.
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.
https://arstechnica.com/t...20billions%20of%20dollars.

Toepasselijk artikel, wel beter dan .Net, maar daar houdt het heel snel op.
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.
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.
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.
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 7 september 2020 14:02]

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.
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).
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
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.
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.
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.
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.
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.
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.
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?
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
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.
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.
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.
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 7 september 2020 08:39]

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
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
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.
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 7 september 2020 07:11]

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.
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.
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.
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.
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 :D
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.
(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.
Je bent geen fan van een persoon die illegale praktijken van veiligheidsdiensten op hun eigen bevolking openbaart?
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.
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.
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).
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.
@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 7 september 2020 06:49]

@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?
Apple dat niet langer toestaat dat je zelf onderdelen vervangt of herstellingen uitvoert.
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 7 september 2020 07:37]

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.
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.
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.
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.
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.
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 7 september 2020 07:05]

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 7 september 2020 08:52]

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.
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.
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 8)7
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 7 september 2020 07:59]

Wat een tof artikel! Heb er echt weer het een en ander van geleerd :)
Foutje in het artikel:
Qq
De Secure Enclave maakt daarvoor symetrische Elliptic-curve-encryptiesleutels aan en slaat de privésleutel op.
Unqq
Asymetrisch...

Kies score Let op: Beoordeel reacties objectief. De kwaliteit van de argumentatie is leidend voor de beoordeling van een reactie, niet of een mening overeenkomt met die van jou.

Een uitgebreider overzicht van de werking van het moderatiesysteem vind je in de Moderatie FAQ

Rapporteer misbruik van moderaties in Frontpagemoderatie.



Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone SE (2022) LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S22 Garmin fēnix 7 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee