Google maakt firmware Titan M-beveiligingschip van Pixel 3 open source

Google maakt de broncode van de firmware van zijn Titan M-beveiligingschips onder een opensourcelicentie beschikbaar. Beveiligingsdeskundigen kunnen daardoor de code nalopen op eventuele onvolkomenheden.

Google geeft de broncode ergens in de komende maanden 'volledig vrij', meldt Xiaowen Xin, projectmanager security bij Google, aan Wired. Google onthulde bij de bekendmaking van de Pixel 3 en Pixel 3 XL dat het een zelf ontworpen beveiligingschip in de smartphones had geïntegreerd.

In een toelichting verduidelijkt Google dat de chip moet helpen de bootprocedure te beveiligen en een rol speelt bij de opslag van toegangscodes van gebruikers en de decryptie als de juiste code op het lockscherm is ingevoerd. Daarnaast zorgt de chip voor de opslag van privésleutels, ook van apps van derde partijen, en helpt de hardware bij autorisatie, onder andere voor betalingen.

De Titan M is een verkleinde versie van de Titan-chip die Google voor de servers van het Google Cloud Platform inzet. Deze chip bevat onder andere een coprocessor voor cryptografie, een hardwarematige random number generator, eigen ram en afgeschermde flashopslag.

Links de Titan, rechts de Titan M

Reacties (32)

[Christoxz]

Is dit gewoon puur toeval, of is het een reactie van Google betreft dat het gelukt is om root toegang te krijgen?
nieuws: Ontwikkelaar slaagt erin om roottoegang te krijgen op de Pixel 3-smar...

[Verwijderd]

Denk het niet, Google heeft genoeg coders in dienst dat ze de firmware zelf ook kunnen patchen. Het vrijgeven van de broncode opent juist de weg naar exploits, dus makkelijker rooten. In dit geval gaat het Google duidelijk om de peerreview.

Google is ook niet specifiek tegen rooten, alleen de beveiligingsimplicaties die het met zich mee brengt. In de begin jaren waren roothacks exploits in de kernel welke ook misbruikt kunnen worden door kwaadwillende. ZO maak ik het nog regelmatig mee dat iemand met een hele oude telefoon bij me komt waar adware in de rootimage staat, dat krijg je alleen weg met een complete reflash. Via het OS zoiets uit kunnen voeren, dat wil je gewoon niet. Dat het allemaal zeer doelgericht via unlocked bootloaders moet gaan is een keuze die de gebruiker maakt en heeft Google weinig over te zeggen.

Dit is ook in lijn met Google's beleid: "jou apparaat, jou keuzes". Standaard hebben ze een hoop voorzieningen, maar als je dat niet wil kan je het ook wegdoen. Apple denkt daar dan weer anders over, de Secure Enclave Processor van Apple is wel het een en andere over bekend maar niet veel, om maar even iets te noemen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:01]

[kaas-schaaf]

Het vrijgeven van de broncode opent juist de weg naar exploits, dus makkelijker rooten.

Je geeft het al aan maar deze zin maakt de nuance wat raar dus ter addendum:

Dit wil je dus voorkomen door de boel te opensourcen en te reviewen. Maar het is wel een kip-ei verhaal in dat geval.
Meestal zorgt het OS'en er voor dat de duur van openbaring voor exploits afneemt en dat er meer gevonden worden (in het openbaar zijnde dus).

Het is echter aan te namen dat deze exploits voor iedereen vindbaar zijn en dus bij non-OS software gewoon misbruikt kunnen/zullen worden alleen dan door een selectere groep en niet gepatched worden.

[Reactie gewijzigd door kaas-schaaf op 22 juli 2024 16:01]

[Verwijderd]

Dit wil je dus voorkomen door de boel te opensourcen en te reviewen. Maar het is wel een kip-ei verhaal in dat geval.

Security through obscurity werkt niet, dat hadden we in de jaren 90 al gezien.

[kaas-schaaf]

Zoals ik de vorige twee posts als is duidelijk gemaakt onder het expliciet te noemen.

[Verwijderd]

Volgens mij legt de zin daarna het al uit: "In dit geval gaat het Google duidelijk om de peerreview".

[Cerberus_tm]

Maar de Pixel 3 mag je van Google blijkbaar niet rooten, anders zou die ontwikkelaar er niet in hoeven te "slagen" om de telefoon te rooten? Hoe zit dat dan: is de Pixel nu wel of niet open?

[flipkipse]

Volgens mij vecht google hier al jaren niet meer tegen. Maar laten ze het gewoon maar toe.

Ik ben ook van mening dat de beste aanval is, zorgen dat je eigen software zo goed is en lang support heeft, dat de gebruiker niet over op een custom rom hoeft.

[Verwijderd]

Interesseert Google denk ik weinig. Het zijn vooral DRM houders en misschien banken die dit "eng" vinden en Google aanmoedigen er wat tegen te doen.

Een beetje hetzelfde als Netflix/Hulu vs VPN's. Zelf vinden ze het prima (want meer inkomsten), maar om gezeur met rechthebbenden te voorkomen nemen ze af en toe een maatregel, die vervolgens alles behalve waterdicht blijkt.

[Alw4ysFresh]

Net als de Google Nexus-serie behoren de Google Pixel-smartphones tot de gemakkelijkste apparaten om de bootloader, root en de aangepaste ROM's en kernels te installeren. De 2018 Google Pixel 3 en Google Pixel 3 XL zullen geen uitzondering zijn.

Bron: XDA

Maar het is inderdaad heel gemakkelijk om op Nexus en Pixel smartphones te unlocken over een paar dagen zal er weer een TWRP Recovery beschikbaar zijn en zullen er aangepaste ROM's beschikbaar komen.

[leuk_he]

deze root togang wil zeggen dat je de bootloader instelt om unsigned rom's te laden. Het is geen hack hoor. de fabrikant van het apparaat geeft je gewoon de sleutels om unsigned rom's te laden.

een paar jaar geleden zaten er soms bugs in het OS waarmee het lukt root te draaien op een gelockte bootlader, maar daar ik sinds een paar jaar niet veel meer over gehoord.

[vliegendekat]

Mooi! Kunnen we die firmware dan ook compileren en kunnen we dan ook onze eigen binairy naar die Titan chip schrijven?

Ik meen me te herinneren dat Google dat juist onmogelijk had gemaakt met die TITAN-chips. Als wij aan moeten nemen dat de software op die chips overeenkomt met de software waar wij de source van zien, dan heeft het nog nauwelijks toegevoegde waarde en is het alleen maar een methode om de hardware nog verder op slot te zetten.

[Reactie gewijzigd door vliegendekat op 22 juli 2024 16:01]

[Verwijderd]

Denk dat dat moeilijk wordt, de Titan M chip heeft volgens Google een secured flash. Wat dat inhoudt weet ik niet, maar in de praktijk betekent het meestal dat de lijntjes om de flash te programmeren verbroken zijn met een laser of via fuses.

De Titan M chip is een geheel onafhankelijk SoC met een eigen processor en geheugen. Misschien dat er egens een exploit mogelijk is, maar dat zal lastig zijn,

Verifiëren van de functie is dan wel heel makkelijk. Denk maar aan tools als sandsifter die alle verbogen hoekjes van een processor in kaart kunnen brengen. Je kijkt in de code, je geeft het commando aan de chip en verifieert het resultaat. Daarnaast kan je de chip bombarderen met een hoop commandos om te kijken wat het doet. Als er iets ongedocumenteerd tussen zit dan heb je dat zo gevonden.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:01]

[vliegendekat]

Denk dat dat moeilijk wordt, de Titan M chip heeft volgens Google een secured flash. Wat dat inhoudt weet ik niet, maar in de praktijk betekent het meestal dat de lijntjes om de flash te programmeren verbroken zijn met een laser of via fuses.

De Titan M chip is een geheel onafhankelijk SoC met een eigen processor en geheugen. Misschien dat er egens een exploit mogelijk is, maar dat zal lastig zijn,

Verifiëren van de functie is dan wel heel makkelijk. Denk maar aan tools als sandsifter die alle verbogen hoekjes van een processor in kaart kunnen brengen. Je kijkt in de code, je geeft het commando aan de chip en verifieert het resultaat. Daarnaast kan je de chip bombarderen met een hoop commandos om te kijken wat het doet. Als er iets ongedocumenteerd tussen zit dan heb je dat zo gevonden.

Sandsifter zal niet werken, omdat de chip waarschijnlijk in een beveiligde package zit en een brute-force beveiliging heeft. Een secured flash kan net zoveel betekenen als "de data staat versleuteld in het flash en de decryptiesleutel blijft ten alle tijden in de CPU" (Dit is overigens in grote lijnen het security-model van de iPhone).

Ik wil de mogelijkheid om de firmware van die chip te "updaten", met daarbij de eis dat tijdens de update de sleutels voor de versleuteling worden weggegooid en opnieuw gegenereerd. Als die chip van Google niet op zo'n manier werkt kan die chip, security-technisch gezien, er net zo goed niet in zitten.

Of heeft Google elke vorm van controle en updaten gewoon onmogelijk gemaakt?
Zo ja, dan zijn we geen steek verder dan TPM's en smartcards. Het gaat er immers om dat er geen systeem-update kan worden toegepast voordat de user zijn pincode heeft ingegeven. Een smartcard kan ik tenminste nog ergens uit trekken (of niet insteken) als ik het niet (meer) vertrouw. Bij die TITAN-chip wordt dat lastig.

Ik vrees echt dat dit gewoon marketing is om ons een hele productlijn door de neus te duwen die wij feitelijk niet zelf bezitten en waarmee we steeds weer net niet kunnen doen wat we zouden willen. Geweldig voor het marktaandeel van Google, maar rampzalig voor de concurrentie en voor ons als consument.

[Reactie gewijzigd door vliegendekat op 22 juli 2024 16:01]

[Verwijderd]

Sandsifter zal niet werken, omdat de chip waarschijnlijk in een beveiligde package zit en een brute-force beveiliging heeft.

Wat is volgens jou een beveiligde package?

[vliegendekat]

Wat is volgens jou een beveiligde package?

Een raster van capacitieve sensordraden (ala touchpad/touchscreen) om de CPU heen. Als daar een verstoring in zit wist de CPU van de chip de crypto-keys of hij gaat heel erg langzaam draaien om een aanvaller tegen te werken.

Dit is overigens best wel standaard, want het zit in al onze bankpassen, simkaarten, pin-terminals en ook in bijv de Yubikeys.

[Verwijderd]

Aha, LDS. En dat gaat hoe werken volgens jou?

[vliegendekat]

Aha, LDS. En dat gaat hoe werken volgens jou?

Men weet dat er een bepaald magnetisch veld hoort te staan over het raster dat er rondom de chip ligt. De eerste keer dat de chip stroom krijgt, worden die waarden opgemeten en opgeslagen in een stukje geheugen dat "write once" is. Als in de toekomst waarden worden gemeten die afwijken van wat er de eerste keer gemeten is, neemt de chip aan dat hij open is gemaakt en daarop onderneemt deze maatregelen.

Welke maatregelen dat zijn is afhankelijk van het geconfigureerde beleid. Het kan zijn dat de kloksnelheid van bijv 33 MHz, naar 500 KHz wordt teruggebracht om de aanvaller te irriteren, maar het kan ook zijn dat de chip bij de eerste gelegenheid begint met het wissen van het geheugen waar zijn cryptografische sleutels zijn opgeslagen.

De data die in een externe chip wordt opgeslagen wordt iig al binnen die mesh versleuteld, de sleutel zelf staat in een stukje speciaal geheugen binnen de mesh en de rest van de data die de chip nodig heeft kan dan zonder problemen op een externe chip worden opgeslagen. Sommige secure elements hebben zelfs het geheugen volledig versleuteld en het volledige geheugen dan ook nog eens binnen de mesh zitten.

Onze betaalterminals hebben dan ook nog eens een secure element aan boord dat continu van stroom voorzien moet worden en de sleutels in SRAM heeft opgeslagen zodat men continu kan checken of het magnetisch veld niet significant is veranderd sinds de eerste power-on. Iedere terminal heeft ook zijn eigen individuele crypto-key aan boord en zo voorts. U kunt hier bijna eindeloos mee doorgaan.

Een pin transactie heeft in ieder geval een handtekening nodig van de bankpas, de betaalterminal waar de pinpas in zit en van de aanbieder van de betaalterminal voordat de systemen uberhaupt beginnen met het "In behandeling nemen" van de transactie. Iedere afzonderlijke handtekening wordt dan ook weer in een ander apparaat (en anders in ieder geval in een andere chip) gezet, om het vertrouwen in een gesloten, closed source, keten te verstevigen.

Ik verwacht dan ook zeer zeker niet dat Google met zijn TITAN-chip ook maar in de buurt van een dergelijke beveiligingsniveau. Het is immers maar één bouwsteen waar zij nu hun hele beleid aan ophangen en dan kunnen wij de werking daarvan waarschijnlijk niet eens inspecteren.

In dit kader is het, mijns inziens, beveiligingstechnisch vragen om ellende. Google moet minimaal mijn sim-kaart in de keten opnemen en anders de boel opensourcen voordat ik hier vertrouwen in heb.

[Verwijderd]

Aha, en wat als er nou een vuiltje op de PCB zit, of een mug? Wat als ik mijn probe elders op de PCB zet? De Titan chip is waarschijnlijk verbonden met iets anders toch? Kan toch mijn probe ook op de pinnen van dat andere zetten, blijf ik lekker uit de buurt. Ik snap het niet zo goed, hoe zou dit alles moeten werken?

Laat ik het zo zeggen, heb je ook een fototje van dit alles, een elektronenmicroscoop (hint hint) zou dit alles op de gevoelige plaat kunnen zetten. Misschien als ik het zie dat ik het beter begrijp.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:01]

[leuk_he]

https://blog.google/produ...ur-most-secure-phone-yet/

Last, but not least, to prevent tampering, Titan M is built with insider attack resistance. The firmware on Titan M will never be updated unless you have entered your passcode, meaning bad actors cannot bypass your lock screen to update the firmware to a malicious version.

Het is dus in ieder geval technisch mogelijk de firmware te updaten.

maar hoe je in dat geval de chain beveiligd, hoe voorkom je dat iemand een firmware maakt die zegt " ja ik ben origineel", maar ondertussen dat niet is, is me een raadsel.

Beetje hetzelfde verhaal als magisk. dat is een root module die zeg "nee hoor, er is geen root"

ik denk dat google wil zeggen " trust me, i am the google firmware"

[vliegendekat]

De vraag is nu: Kan de firmware een update krijgen zonder de crypto-keys te wissen of herinitialiseren? Zo ja, dan hebben we het eerste beveiligingsprobleem al gevonden.

Die bluetooth FIDO Titan-tokens van Google waren namelijk ook al niet helemaal fris. (De usb-versies waren wel ok). Ik meen ook dat Yubico om vergelijkbare redenen geen bluetooth versie op de markt heeft gebracht.

Het lijkt erop dat het aantal security-incidenten en blunders bij Google de laatste tijd fors aan het toenemen is. Dit jaar alleen al vage Titan-tokens, Plus en een spectaculair lek in Google Cloud Platform. Het lijkt erop dat ze het nieuwe Microsoft aan het worden zijn.

[lilmonkey]

Google heeft er natuurlijk vrij weinig belang bij om stiekem een minder goede firmware te shippen.

[Verwijderd]

Het gaat niet om "goede" firmware. Het gaat om de mogelijkheid van Google om er expres backdoors in te zetten. De open source karakter betekent niks als de code niet dezelfde is als wat er op de chip staat. En dit is alleen maar te verifiëren als je deze chip op zijn minst kan uitlezen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:01]

[lilmonkey]

Dat is precies wat ik bedoelde. Daar heeft Google geen belang bij; het hele punt van deze chip is immers beveiliging. Als ze kwade wil hadden, hadden ze die chip überhaupt niet geïntroduceerd.

[vliegendekat]

Dat is precies wat ik bedoelde. Daar heeft Google geen belang bij; het hele punt van deze chip is immers beveiliging. Als ze kwade wil hadden, hadden ze die chip überhaupt niet geïntroduceerd.

Helaas gaat dat wel volledig in tegen het principe "Trust but verify".
Dat is nogal een belangrijk mantra in de beveiligingswereld, omdat dit het minimaal vereiste niveau van beveiliging aangeeft.

[Alw4ysFresh]

Ik denk als we de geruchten mogen geloven dat Google hun eigen SoC maakt het zeer waarschijnlijk dat deze chip in de SoC zal verschijnen in toekomstige smartphones. Iets wat momenteel niet mogelijk is omdat ze de SoC gebruiken van Qualcomm.

[Reactie gewijzigd door Alw4ysFresh op 22 juli 2024 16:01]

[Christoxz]

Google onthulde bij de bekendmaking van de Pixel 3 en Pixel 3 XL dat het een zelf ontworpen beveiligingschip in de smartphones had geïntegreerd.

Deze chip zit al in de Pixel 3.

[Alw4ysFresh]

Ik weet dat maar ik bedoel dat de chip waarschijnlijk als Google hun eigen SoC maakt dat ze hem in de SoC zetten.

[Christoxz]

Excuus verkeerd gelezen! Ik snap hem nu, was nog ochtend..!

[PeRKoniX]

Die munt eronder ook "In God We Trust". Ik vind het wel passend

[Ravhin]

...all others provide data

[Aardedraadje]

Inderdaad best ironisch