Google voegt Adiantum-schijfencryptie toe aan Android voor budgetsmartphones

Google heeft een encryptiemethode ontwikkeld voor smartphones met chips die geen hardwarematige encryptie voor aes hebben, zoals budgettoestellen. De encryptie is gebaseerd op het ChaCha-streamcipher.

Google legt de reden van de ontwikkeling van Adiantum en de details achter de encryptie uit op zijn Security Blog. Google verplicht full disk-encryptie al sinds 2015 sinds de komst van Android 6.0, maar Android ondersteunt hiervoor aes-256 en bij langzamere system-on-chips leidt dit tot matige prestaties. Google houdt een grens aan van 50MiB/s. Komt de doorvoer daaronder dan geldt de verplichting niet.

Bij smartphones met chips op basis van ARMv8 speelt dit niet vanwege de Cryptography Extensions, die hardwarematige versnelling van aes-encryptie bieden. Met name budgetsmartphones en andere apparaten met goedkope chips vielen tot nu toe vaak buiten de boot. Google noemt de oude ARM Cortex-A7 als processor zonder hardwarematige versnelling, die te langzaam is voor aes.

Google heeft daarom een alternatief ontworpen in de vorm van Adiantum. Het bedrijf zet hiervoor een variant van het ChaCha-streamcipher in, waarbij op aes gebaseerde technieken zijn geïntegreerd. Adiantum biedt aanzienlijke prestatiewinsten ten opzichte van aes-256 op een Cortex-A7, stelt Google.

Het bedrijf gebruikte in 2014 al ChaCha20 bij een tls-suite voor de beveiliging van https-verbindingen. Voor Adiantum koos het bedrijf voor ChaCha12, waarbij het getal voor het aantal rounds staat. Hoe meer rounds, hoe veiliger de encryptie. Hoewel Google daarmee flinke concessies lijkt te doen, stelt het dat ChaCha12 nog wel even mee kan omdat round-8 nog niet gekraakt is, hoewel in 2008 al de 7-variant doorbroken werd.

Fabrikanten kunnen Adiantum inschakelen bij Android Pie-smartphone die bij aes de 50MiB/s niet halen. Boven die grens adviseert Google het gebruik van aes. Adiantum wordt onderdeel van Android Q. Google heeft zijn werk gepubliceerd in een paper met de titel Adiantum: length-preserving encryption for entry-level processors.

Reacties (14)

[N8w8]

Ter info, je kan dit ook gebruiken op een "gewone" Linux bak.
Bijvoorbeeld sinds 2 maanden zit het in Debian.
De meeste CPUs hebben natuurlijk hardware AES, maar mijn Athlon II X2 niet.
Zou een grote verbetering zijn.

[marc1990]

Ik vraag mij altijd af wat voordelen zijn van full disk encryption zijn. Is het locken en unlocken van flash device niet genoeg? Dan hoef je niet hele tijd iets aan hebben staan wat continue stream aan data moet encode en decode. Of moet je het pad tussen het flash device en SoC als onbetrouwbaar aanmerken(zeker gezien je wel merkt als iemand telefoon even los haalt en er iets in soldeert)? Of zie ik hier iets over het hoofd?

[WhatsappHack]

Als je schijf gejat wordt (of in beslag genomen wordt, whatever) kan men zonder sleutel niets uitlezen. Dat is het voordeel.

[marc1990]

Of je nu disk encryption toepast of flash device eerst moet unlocken. Je bent in beide gevallen nog altijd een sleutel nodig.
Oke, ingeval fysieke schrijven zal je de schrijven er uit kunnen halen. Maar dit is niet mogelijk met flash geheugen. (wat toch all zeer lange in telefoons zit)

Je moet er dan natuurlijk wel voor zorgen dat het flash device altijd terug valt in lock state(bevoorbeeld naar n tijd en bij reset/lost power). Maar zolang als flash controller op die/wafer in locked state is, is er geen mogelijkheid om de flash array te lezen.

[WhatsappHack]

Eh? Om data te versleutelen/ontsleutelen zal er toch echt ergens een key(pair) moeten zijn. Misschien dat je doelt op hardwarematige encryptie (Eg: AES-chip/functie op de SoC) die volautomatisch werkt dankzij de software op je toestel, maar onder de motorkap wordt daar dus gewoon encryptie op toegepast en de sleutels in bijv. een keybag opgeslagen die unlockt op basis van de unlockcode van je toestel. Je merkt er zelf dus vrij weinig van omdat de soft- en hardware dit zelf al oplossen en zeer gebruiksvriendelijk maken, maar daar wordt dus wel degelijk encryptie op toegepast.

Als er geen encryptie op wordt toegepast, dan kan je flashgeheugen gewoon uitlezen... Het is niet zo dat al het flashgeheugen zichzelf standaard encrypt ofzo. Dit artikel gaat over toestellen die grove problemen hebben met de encryptie (vanwege het ontbreken van de juiste hardware), dus stel dat ze die encryptie nu simpelweg niet toepassen vanwege de performance hit: dan is je opslag dus niet veilig.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 00:29]

[GekkePrutser]

Als het niet geencrypt is kan je via de bootloader alles al lezen (fastboot).

En de bootloader moet de flash kunnen unlocken anders kan hij niet booten.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 00:29]

[Jeroenneman]

Het had Google nog meer gesierd als ze gewoon hardware matige eisen hadden gesteld aan nieuwe Android toestellen. Gewoon verplicht hardware matige versnelling van AES.

[lololig]

Dan worden fabrikanten boos omdat ze geen goedkope toestellen met oude chips kunnen maken

[Zapato]

Telefoons alleen voor de rijken.

[Trommelrem]

Een TPM kost echt geen drol. Waarom kunnen ze budgettelefoons daar niet gewoon mee uitrusten?

[Glashelder]

Wat kan een TPM toevoegen in dit geval dan? Een TPM is alleen maar een veilige plaats om keys op te slaan. De TPM verwerkt zelf toch geen streams?

[Trommelrem]

TPM slaat Bitlocker sleutels op.

[Glashelder]

Ja dat zeg ik toch ook?

Een TPM decrypt/encrypt alleen geen streams en daarom zou het in deze usecase geen probleem oplossen.

[RoamingZombie]

Voor 2 seconden las ik Adamantium en dacht ik, cool!!

Daarna was ik teleurgesteld.