Google zet encryptie in Android L standaard aan

Met de introductie van Android L, de eerstvolgende Android-versie, wordt encryptie standaard ingeschakeld. Dat heeft Google bekendgemaakt. De encryptiesleutels zijn opgeslagen op het apparaat zelf; Google kan de politie dus geen toegang geven tot Android L-apparaten.

Android biedt al langer de mogelijkheid om de volledige flash-opslag te versleutelen, maar gebruikers moesten dat handmatig inschakelen. Dat in tegenstelling tot iOS, dat encryptie automatisch inschakelt op het moment dat de gebruiker een passcode invoert. Met de komst van Android L stapt Google ook over op automatische versleuteling, zo heeft het bedrijf laten weten aan de Washington Post.

De encryptiesleutels worden enkel opgeslagen op het apparaat zelf, waardoor Google de politie of de geheime dienst geen toegang kan geven tot de data op een apparaat. Apple kon dat lange tijd wel bij iPhones en iPads, maar donderdag kondigde het bedrijf aan dat daar een einde aan komt: met de introductie van iOS 8 kan Apple niet langer passcodes omzeilen.

Reacties (123)

[himlims_]

ben geen security expert, maar encryptiesleutels opslaan op device zelf. Is dat niet zoals briefje met pincode in de portemonnaie?

[Armin]

maar encryptiesleutels opslaan op device zelf. Is dat niet zoals briefje met pincode in de portemonnaie?

Dat lijkt inderdaad zo, maar die sleutels zelf staat er niet op, maar een soort afgeleide.

Er zijn verschillende varianten mogelijk, maar doorgaans wordt een ingewikkelde en zware berekening uitgevoerd op de sleutel en wordt de uitkomst van die som opgeslagen. Jouw wachtwoord/pincode is bovendien nodig om die berekening uit te kunnen voeren. Deze echter wordt niet opgeslagen.

Daarnaast is er soms hulp van speciale hardware om eventueel sleutels veilig op te kunnen slaan. Denk aan de optionele TPM chip bij Bitlocker (zoals o.a. in elke Windows Phone zit) of de AES encryptie die sommige Intel SSD controllers hebben.

Hoe dan ook, bij het invullen van het wachtwoord/pincode op je telefoon wordt dan die zelfde berekening met jouw ingevoerde wachtwoord gedaan. Zijn de uitkomsten identiek, weet de bootloader dat het wachtwoord correct was. Zijn de uitkomsten niet identiek, weet de bootloader dat de pincode/wachtwoord onjuist waren.

Zou je malifide firmware schrijven die toch probeert door te gaan, nog geen man overboord, want de berekening is zo gemaakt dat die zo goed als onmogelijk omgekeerd uit te voeren is. Je kunt dus niet met de op disk opgeslagen data, de correcte sleutel achterhalen. Blijft over brute-force proberen. Door echter de berekening zwaar genoeg te maken, is zelfs met speciale crack hardware zo verscrhikkelijk veel tijd nodig (meestal duizendeden jaren) dat het een kansloze zaak is.

Er zijn vele varianten, maar TrueCrypt disk encryptie gebruikte iets van 5000 lagen ('rounds') van herhaalde hash-berekeningen, zodat een aanvaller per geprobeerd wachtwoord 5000 berekeningen moet doen. Bij BitLocker van Microsoft moet een aanvaller zelfs meer dan een miljoen (!) complexe samengestelde SHA2 hash berekeningen per wachtwoord doen. Ik ken de detail niet van de Android disk encryptie, maar er zal een soortgelijk principe zijn.

[johnkeates]

Je hebt in het geval van de TPM dat je op TPM-niveau al hacks hebt, en in het geval van hash-based encryptie dat je de hash gebruikt voor de codering en de authenticatie maar je dus door het uitlezen van de hash (DMA attacks bijv.) zonder wachtwoord verder kan. Volgens mij was om die reden in elk geval BitLocker van Microsoft (en het oudere EFS) en Apple's FileVault niet meer zo veilig als het leek. Apple heeft volgens mij toen DMA in standby uitgezet en alleen als je interactief aangemeld bent nog aan (extern dan, zoals aansluit bussen en PCIe kaartjes), wat Microsoft gedaan heeft weet ik niet meer precies, maar die deed iets vergelijkbaars.

Op de embedded devices had je weer andere problemen. Samsung's KNOX werkte met hetzelfde idee, maar dat was erg eenvoudig te kraken bleek achteraf (heb de bron niet bij de hand, maar heeft dit jaar meerdere malen op Tweakers.net gestaan). In elk geval was het net als bij de TPM ook mogelijk om beveiligingsprocessors te undervolten om zo beveiligingen te omzeilen en bijv. eFuses niet leesbaar te maken.

Wel had je een langere tijd geleden al de optie om bepaalde soorten keys in CPU registers op te slaan, daarmee kan in elk geval een recente Linux kernel de keys veilig opslaan. Je kan ze namelijk niet extern uitlezen en zolang je systeem aan de software kant niet gecompromitteerd wordt zal je dus nooit de keys kunnen achterhalen. Bij een herstart of warm reboot (of reset) worden de registers altijd geleegd door het (her)opstarten van de CPU. Een stuk veiliger dan coldboot attacks waarbij bevroren RAM gewoon gelezen wordt en de keys voor iedereen te lezen zijn.

Maar je had ook (is al weer gedeeltelijk gepatcht) proof-of-concept hacks als Konboot waarmee je authenticate bij neppe beveiliging gewoon kan omzeilen, maar dat werkt natuurlijk met encryptie niet. Probleem met authenticatie is dat je uiteindelijk altijd ergens in je code een switch of if of jump statement hebt. Als je met een preloader het adres kan vastpinnen en altijd (bijv.) op 'true' kan zetten werkt elk wachtwoord bij het aanmelden.

[Blubber]

ben geen security expert, maar encryptiesleutels opslaan op device zelf. Is dat niet zoals briefje met pincode in de portemonnaie?

Nee, dat is hetzelfde als andere encryptie oplossingen doen. De sleutels staan in een los 'bestand' wat met je passcode geencrypt is. Zodoende kun jij je code aanpassen zonder dat de volledige flash opslag opnieuw geencrypt moet worden.

Het komt eerder neer op een briefje met de code van de kluis met je pincode, in een andere kluis .

[Reactie gewijzigd door Blubber op 26 juli 2024 07:49]

[mcDavid]

Dan nog, hoef je dus alleen maar de pincode/unlock pattern te raden en je kunt alle data decrypten. Je kunt je dus afvragen wat de toegevoegde waarde is. Het aantal mogelijke pincodes is dusdanig laag dat dit binnen enkele seconden te bruteforcen is.

[halofreak1990]

Een beetje OS laat echt geen onbeperkte fouten invoer toe, hoor. Daarnaast zal je op een telefoon, tenzij je een speciale robot hebt die het voor je doet, toch echt zelf alle mogelijke combinaties moeten invoeren om erin te komen. Dan lijkt me in 99% van de gevallen het kosten/baten plaatje erg tegenvallen.

[Jasper Janssen]

Die robots bestaan, sterker die bouw je voor een euro of 100 zelf. Die van de geheime diensten en politie zijn alleen wat steviger en kosten net iets meer.

Zo lang er geen wipe-na-n-fouten functie actief is bruteforce je zo'n telefoon zo.

[Blubber]

Dan nog, hoef je dus alleen maar de pincode/unlock pattern te raden en je kunt alle data decrypten. Je kunt je dus afvragen wat de toegevoegde waarde is. Het aantal mogelijke pincodes is dusdanig laag dat dit binnen enkele seconden te bruteforcen is.

Dat geldt voor elke vorm van beveiliging, het is zo sterk als de zwakste schakel, en dat is in dit geval inderdaad de passcode.

Maar het heeft zeker wel zin, als een partij er absoluut bij wilt vinden ze vast een manier om dat te bewerkstelligen. De vraag is of een beter wachtwoord daar echt bij helpt. Ik zie de passcode van mijn telefoon eerder als een middel om dieven buiten de deur te houden mocht dat ding ooit gejat worden. En dan is die encryptie waarschijnlijk voldoende.

[Thystan]

Je kunt ook een passkey invoeren (een woord bijvoorbeeld) en daar kun een correctbatterystaplehorse password inzetten. Wel irritant met unlocken de hele tijd, maar wel veilig.

[Aaargh!]

En dat is ook de manier waarop een secure-wipe gedaan wordt (iig op iOS). Het is niet nodig de hele flash te overschrijven, ze wissen alleen de encryptie-key en alle data is pleitte.

[Blubber]

En dat is ook de manier waarop een secure-wipe gedaan wordt (iig op iOS). Het is niet nodig de hele flash te overschrijven, ze wissen alleen de encryptie-key en alle data is pleitte.

Dat klopt ja, net als /tmp in OpenBSD .

[zarex]

[...]
Het komt eerder neer op een briefje met de code van de kluis met je pincode, in een andere kluis .

Goeie analogie!

[Kiswum]

Portemonnee met een slot erop, je kunt er pas bij als je ingelogd bent / de juiste sleutel hebt..

[Verwijderd]

En tegelijkertijd, wordt je versleutelde informatie, zoals je contactlijst, gps-lokatie, foto's, gezondheids gegevens etc. gewoon de hele tijd beschikbaar voor elke app die je installeerd via de API's.

Nee, deze encryptie beschermt in de praktijk, weinig van je prive-gegevens, zolang het rechten management voor apps nog niet volwassen is op het platform.

[Tsurany]

Deels waar, deels ook niet. Door informatie niet te versleutelen is het mogelijk om het geheugen van het apparaat uit te lezen en zo alle informaties te ontfutselen. Dus directe toegang tot de hardware zorgt er voor dat je data die op de telefoon staat tot in de kleinste details kan extraheren. Door gebruik te maken van encryptie kan dat in principe enkel met het juiste wachtwoord en zolang je via API's toegang krijgt.

Dan is er inderdaad nog het probleem dat apps veel te makkelijk via het permission systeem overal toegang toe hebben. Dit is deels te verhelpen door van te voren naar de permissions te kijken maar Google gaat ook een nieuw permission systeem introduceren met Android L waardoor we hier ook geen last meer van gaan hebben. Dan kan je on the fly permissies wel of niet toestaan.

[kwikstaart]

Mijn telefoon is laatst gestolen. Ik had 'm versleuteld. Toch wel een fijn idee dat iemand niet bij m'n data kan. Daarom gaat het voor 99.99% van de gevallen.

[RebelwaClue]

Al is dat zeker een minpunt, deze toegang wordt wel aangegeven bij installatie.

[Montaner]

De applicatie geeft aan waarvoor toegang gevraagd wordt. Als je dat niet wil, installeer je de applicatie toch niet? En als tweaker root je je toestel maar, en schakel je die toegang na installatie uit.

Wel leuk dat je het op Android schuift, maar Apple gaat nu dus deels het zelfde doen in iOS 8. Blijkbaar zit er toch wel iets in wat goed werkt.

Misschien eens handig om te googlen op encryptie. Of wou je zeggen dat je bv. met TrueCrypt ook beschermd bent terwijl je pc ingelogd en open staat?

[aryan1171]

Echter, als je de standaard encryptie op android inschakelt, en deze combineert met Xprivacy (Xposed module), dan kom je al een heel eind. Ik heb zelf sinds kort er veel onderzoek naar gedaan, er is aardig wat je kan doen om ervoor te zorgen dat ongewensten geen toegang kunnen krijgen tot je apparatuur.

Xprivacy, encryption aan, Secdroid hardening, ADB uitgeschakeld, root uitgeschakeld, en de standaard AppOps configureren om systeem apps ook geen toegang te geven.

Hier kom je al een heel eind mee!

[mkools24]

Tja als je ook maar enige waarde hecht aan je privacy moet je gewoon geen mobiele telefoon nemen of zelfs helemaal niet meer op internet zitten. Dit is echt weer zo'n marketingstunt.

Bijv ook bij Apple zeggen ze dat ze zelf niet kunnen decrypten en daardoor ook geen info aan de NSA kunnen verstrekken. Wie gelooft dat nog in deze tijd met al die tereurdreigingen.

[Verwijderd]

Bijv ook bij Apple zeggen ze dat ze zelf niet kunnen decrypten en daardoor ook geen info aan de NSA kunnen verstrekken. Wie gelooft dat nog in deze tijd met al die tereurdreigingen.

Dat Apple (of Google, MS, etc.) de opslag van een device niet kan decrypten, kan prima waarheid zijn. Dit zegt echter niets over dat een derde het niet kan decrypten. Hiervoor zijn meerdere attack-vectors mogelijk (bijv. foutieve PRG).

Daarnaast zijn er attack-vectors die decryptie omzeilen (bijv. Finfisher-malware).

[Grrrrrene]

Als apps met die gegevens moeten werken, moet het gedecrypt worden en in die staat kan het naar derden verstuurd worden. Dus zo'n statement is maar half waar natuurlijk

[Verwijderd]

Precies, dat geef ik aan met de laatste regel. Desalniettemin is je conclusie dat zo'n statement half waar is, onjuist.

[TheStef]

In theorie heb je gelijk, maar dan moet je ook ergens op de hei gaan zitten, dan ben 99% zeker.

Maar het is alleen maar goed dat bedrijven zoals Apple en Google hier meer en meer een punt van gaan maken, helemaal privacy-zeker ben je nooit, maar iedere stap naar meer en betere privacy is een stap in de goede richting.

[Lightmanone1984]

Offtopic: De hei... ik was daar aflopen mei. Ik had -midden- op de hei volledig bereik GSM en vol bereik met 3G.

On topic: ik vraag me af hoeveel dit echt uithaalt voor gebruikers.

[Herko_ter_Horst]

Op de hei? Ben je gek man! Daar wordt je constant in de gaten gehouden door die webcams die zogenaamd voor vogel- en wildliefhebbers zijn... Nee hoor, dat zijn gewoon AIVD/NSA cams die de gevaarlijke natuurterroristen en kinderpornografen in de gaten houden!!!1!!
</aluhoedje>

[mkools24]

Dat vind ik bij Google toch weer wat minder dan bij Facebook, wat ook iedereen gebruikt ook mensen met een iPhone en daar hoor je dan niemand over, vreemd.

Google's verdienmodel is reclame en inderdaad als je gmail gebruikt leest Google mee om advertenties af te stemmen op jou interesses. Ook als je bijv. het woordje bijlage gebruikt in je mail en je voegt geen bijlage toe attendeert Google je daarop maar dat zijn allemaal automatische processen waar ik op zich nog wel mee kan leven. Een computer die meeleest boeit me niet zo, als alle Google medewerkers nou alles van jou gaan uitpluizen wordt het een ander verhaal.

Tenslotte heb ik liever advertenties waar ik iets mee kan dan bijv. een advertentie over maandverband die totaal niet op mij van toepassing is. Ik denk dat zelfs de adverteerder daar niet op zit te wachten.

[Waterbeesje]

Jouw gegevens die Google verzamelt, worden anders niet meer verkocht aan derde partijen. Da's al heel wat.

Er zijn zat bedrijven (met name de makers van die oh zo grappige duffe spelletjes waar je 10 min mee zoet bent) die gegevens gewoon combineren uit 10 verschillende apps, en lekker doorverkopen aan andere partijen die je gaan platmailen/spammen/bellen/smssen. Onder andere het complete telefoonboek en accountlijst zijn interessant, en de meeste mensen interesseert het toch niets of weten het gewoonweg niet...

Volgens mij valt het pryvacy schenden van Google relatief nog enigszins mee t.o.v. diverse andere partijen. Alles blijft in eigen huis (m.u.v. the patriot act uiteraard)

[vdvoort]

Voor Google is de NSA gewoon een concurrent.

Dat jij niet ondertussen moe bent van jezelf, onbegrijpelijk. Zie je echt alleen maar haten op Google in de comments, zeer irritant. Laat het Google nieuws dan toch gewoon links liggen en bespaar jezelf de energie.

[johnkeates]

Stel dat het asymmetrische encryptie zou betreffen, dan is het nog beter: met encryptiesleutels kan je wel coderen maar niet decoderen!

[Armin]

Aangezien je telefoon zowel moet kunnen lezen als schrijven, heeft dat weinig zin. Immers dan zou men alsnog beide sleutels moeten opslaan op die telefoon. Bovendien is asymetrische encryptie op disk verschrikkelijk traag ...

[johnkeates]

Je zou natuurlijk een asymmetrische encryptie kunnen gebruiken om een symmetrische key te coderen. Een gebruiker moet dan eerst zijn/haar code invoeren voor dat het systeem de data kan ontgrendelen. Ik dacht dat Apple iets dergelijks deed in iOS, maar in elk geval heb je dat met Linux zo als je LUKS gebruikt. De keys zijn symmetrisch maar asymmetrisch gecodeerd.

SSL werkt dacht ik op dezelfde manier. De digitale ondertekening is asymmetrisch maar de data codering is weer symmetrisch.

[Armin]

Je zou natuurlijk een asymmetrische encryptie kunnen gebruiken om een symmetrische key te coderen

Dan moeten nog steeds beide sleutes op het apparaat staan.

Asymetrische encryptie is enkel nuttig indien één van de sleutels niet op het apparaat hoeft te staan. Denk aan TLS en PGP.

Ik dacht dat Apple iets dergelijks deed in iOS,

Wellicht ergens in iOS maar niet qua disk encryptie.

Het kan wél bij iCloud achtig constructies waarbij de server (cloud) de ene sleuitel heeft en de client (jowu telefoon) de andere. (Al begreep ik dat iCloud dat ook zo niet deed.)

SSL werkt dacht ik op dezelfde manier. De digitale ondertekening is asymmetrisch maar de data codering is weer symmetrisch

Klopt en daar is het ook handig, want de private key van de server krijg jij dus nooit als client. Daar is het immers een kant die encryptie doet, en de andere kant decryptie. Anders dan bij disk encryptie waar dezelffde 'persoon' beide doet.

[johnkeates]

Nee, dan hoeven niet beide sleutels op het apparaat te staan.

Als je als gebruiker een code moet intoetsen bij het opstarten kan je die dus gebruiken om je symmetrische key te decoderen. Dat is juist het punt met asymmetrische encryptie.

De symmetrische key staat dan gecodeerd op je toestel. De asymmetrische private key om hem te decoderen weet alleen de gebruiker. Dat is ook hoe Apple het doet (ik heb het even opgezocht) met secure storage op de flash chips.

[Armin]

Nee, dan hoeven niet beide sleutels op het apparaat te staan.

Jawel, asymetrisch wil enkel zeggen een sleutel voor encoderen en een voor decoderen. Jouw telefoon moet beide kunnen en dus beide sleutels hebben.

Het wachtwoord in deze heeft hier geen invloed op. Dat is enkel een manier om de sleutel te genereren. Dat kan ook met symetrische encryptie en is dus veel beter. Immers er is veel minder rekenkracht nodig bij symetrische encryptie voor dezelfde brute-force veiligheid.

De symmetrische key staat dan gecodeerd op je toestel. De asymmetrische private key om hem te decoderen weet alleen de gebruiker

Ik snap je verwarring. Wat jij de private key noemt (het wachtworod) is echter niet de key, maar een 'input' om de - in dit geval symetrische - key te genereren.

Bij asymetrische enryptie zou je in aanvulling van de ene sleutel, en het wachtwoord nog een derde element nodig hebben. Deze zou dan geheim moeten zijn voor zowel de gebruiker als jouw apparaat.

Maar dat kan evident niet als jij en je apparaat vervolgens de data moet kunnen lezen. Dat is anders dan bij SSL/TLS of PGP, waar jij data die je stuurt niet zelf hoeft te kunnen ontsleutelen, en de server de data die het jouw verstuurt ook niet zelf hoeft te kunnen ontsleutelen.

[johnkeates]

Hmm, de laatste keer dat ik RSA en AES implementeerde werkte het toch echt zo. Behalve als de wiskunde opeens anders werkt is het sinds vorig jaar toch nog hetzelfde...

1. Genereer een AES key
2. Genereer een RSA keypair
3. Codeer je AES key met je RSA codeersleutel (asymmetrisch)
4. Codeer je RSA decodeersleutel met je password (symmetrisch)
5 Gooi je AES key en je RSA key weg

Als je nu bij je data die je met de key van stap 1 wil komen doe je:

1. Voer je password in, hiermee krijg je je RSA decodeer sleutel uit stap 4 terug.

2. Voer je RSA decodeer sleutel + je AES sleutel die je met RSA gecodeerd had in stap 3.

3. Gebruik je gedecodeerde AES sleutel voor je storage encryptie/decryptie tot dat je je device weer lockt.

Je apparaat hoeft niks te lezen als je er zelf niet bij hoeft. Je kan kan het gewoon bij locken/unlocken doen. Of bij opstarten/uitzetten.

Illustratie voor LUKS:

http://nnc3.com/LinuxMag/...rypt/images/fig2-luks.png

Daar gaat dat precies zo. Het is een bewezen techniek waarmee je nooit toegankelijke sleutels op je apparaat hoeft te hebben en is niet afhankelijk van een TPM of iets dergelijks. En met de juiste kernel patches kan je ook zorgen dat je keys nooit in het RAM komen wat DMA en coldboot attacks tegen gaat. Zolang je CPU veilig is kan je het dus als 'onkraakbaar' zien.

[Reactie gewijzigd door johnkeates op 26 juli 2024 07:49]

[Armin]

Hmm, de laatste keer dat ik RSA en AES implementeerde werkte het toch echt zo. Behalve als de wiskunde opeens anders werkt is het sinds vorig jaar toch nog hetzelfde...

Klopt maar wat jij beschrijft is key-generation en opslag/terughalen. Daar kun je inderdaad RSA of een ander asymetrisch algorithme voor gebruiken. Hoeft niet kan.

Uiteindelijk echter zoals je zelf aangeeft codeer je het met je symetrische key. Jouw tweede stap 3. Immers AES encryptie is symetrisch.

Dus key-generation etc kan asymetrisch, maar de encryptie zélf is 100% symetrisch.

Dat is eigenlijk altijd symetrisch gezien de enorme performance nadelen van asymetrisch plus dat het nihil voordeel heeft om de encryptie zélf asymetrisch te doen. Immers jouw telefoon moet zowel kunnen lezen als schrijven, en dus per definitie zowel de public als private keys hebben indien je toch asymetrische encryptie zou gebruiken. Jouw stap 3 zou dan twee sleutels opleveren. Een voor lezen, en een voor schrijven.

[johnkeates]

Uiteraard is je flash encryptie symmetrisch, maar gezien je met AES en bijbehorende AES accelerators lange sleutels kan gebruiken zou je AES flink veilig kunnen houden. Die lange key kan je dan niet-leesbaar op je device opslaan met een asymmetrische key die dan weer heel moeilijk te kraken is. Op die manier heb je snelle data encryptie die niet makkelijk te kraken is door de lange key, maar kan je een kortere key gebruiken door hem asymmetrisch te coderen. Een korte asymmetrische key is nog altijd veiliger dan een korte symmetrische key (nouja, dat hangt natuurlijk van je gekozen algoritme af) om dat over het algemeen symmetrische encryptie sneller is en daarmee ook sneller te bruteforcen is.

Dus, snelheid + veiligheid = (bijv.) AES + RSA. En om je RSA key goed te beveiligen moet je die weer coderen. Om dat je niet zomaar je private en public keys kan bepalen (nouja, het kan wel, maar dan moet je je parameters op een of andere manier van een user password aflezen wat altijd minder entropy aan bits oplevert dan een random groot getal) moet je dus een goede set RSA keys genereren en die dan op hun beurt met een user password via bijv. RFC 2898 zodat je een stevige AES key hebt die dan niet op je device staat maar toch via een normal user password te herstellen is.

Precies zoals ik in het plaatje van LUKS bedoel dus. Het doel is om geen bruikbare keys op je device te hebben, en op die manier kan je dat a la industry standard doen.

[Reactie gewijzigd door johnkeates op 26 juli 2024 07:49]

[Armin]

Waar, maar dat is dus geheel wat anders dan asymetrische encryptie gebruiken. Wat jij beshrijft is de methode om de symetrische key te beschermen.

Jij gebruikt in jouw voorbeeld een enkelvoudige RSA key. Dat is makkelijk en een betrouwbaar algorithme. Nadeel is dat het heel erg veel bits nodig heeft. Om een 128bit AES key te beschermen moet je al een 2048bits RSA key gebruiken. Daarnaast is het afhankelijk van de kracht van het gekozen wachtwoord. Is dat zwak is je disk encryptie key ook makkelijk te kraken.

Om die reden wordt bovenstaand algorithme meestal niet gebruikt voor disk encryptie, maar wordt een complexe meervoudige hash gebruikt.

Voordeel daarvan is dat je de sterkte kunt aanpassen aan de tijd. Immers jouw encryptie-algorithme is vast qua sterkte. Indien het over X jaar gebroken is, moet je als fabrikant een nieuwe encryptie bedenken. Bij hash voer je gewoon meer rounds uit. Zo werkten o.a. BitLocker en TrueCrypt disk encryptie.

Daarnaas is het bij toepassen van veel rounds (BitLocker doet dat, TrueCrypt helaas niet zoals uit de audit bleek) beter beschermt tegen slechte passwords. Immers je moet nog steeds alle rounds uitvoeren als je brute force wilt kraken.

[pfismvg]

Vaak zitten die sleutels tegenwoordig ook in aparte microchips... de sleutel gegevens kun je slechts uit de chip halen door het juiste wachtwoord aan die chip te geven. zonder wachtwoord kun je er gewoon niet bij.

Nu zijn een aantal van die chips weer te "hacken" door de chip open te slijpen en met een microscoop te bekijken, of met naaldjes direct op de IC verbindingen te maken en de keys uit te lezen... maar de kans dat je die chip sloopt voordat je hem kan uitlezen is vrij groot en onbereikbaar voor de meeste van ons Tweakers...

Een zelfde mechanisme zit bijvoorbeeld al in je bankpas. de Chip op je bankpas weet jouw pincode. je kan die pincode echter niet uitlezen. je kan slechts vragen aan de chip of een pincode juist of fout is.
Als je alleen bovenstaande beveiliging gebruikt zou je door simpelweg van 0000 tot 9999 alle pincodes doorlopen en vragen of die code juist is achter de code kunnen komen... vandaar dat de chip zichzelf blockeert na een x aantal foute codes.

[Jasper Janssen]

Gezien het feit dat je bij veel bank/creditcard systemen je pincode zelf kan kiezen bij activatie of op een later moment wijzigen zonder een nieuwe pas kan het niet in *alle* gevallen zo werken.

[Armin]

Klopt, de sleutel en de pincode kunnen afhankelijk van het algorithme onafhankelijk zijn.

Bij oude chipknip stijl transcties moet de pincode (of waarschijnlijker een afgeleide) inderdaad de chip zitten, maar bij meer klassieke PIN-stijl transacties waar altijd een connectie met de bank gemaakt wordt niet.

[Plainside]

Niet precies.
In een zin zou je het zo kunnen zeggen maar in de werkelijkheid werkt het anders, als je bijvoorbeeld 1234 als scherm lock hebt dan zal daar een encryptie over gaan die alleen de telefoon zelf snapt.
Die versleutelt 1234 naar bijvoorbeeld abcd om het echt super simpel te zeggen.
Natuurijk werkt het op een telefoon heel anders waarschijnlijk maar dit is een basis van encryptie.

Ik ben er geen expert op maar volgens mij zit het zo een beetje in elkaar .

[i-chat]

nou in werkelijkheid zit je er nogal een stuk naast, zie ook de uitleg boven je

die lock is gewoon een code of pin, waarmee je een lijstje met wachtwoorden kunt beveiligen, weet je de code niet dan kun je het lijstje met wachtwoorden niet ontcijferen / ontsleutelen...

[Verwijderd]

Volgens mij wordt vaak een klein bestandje met de key daarin geencrypt door je wachtwoord, of in dit geval bijvoorbeeld het lock pattern. Vervolgens kan met die key de rest geencrypt worden.

[Probook8979]

Hoe komt t toch dat IOS voldoende heeft aan 1 gig Ram terwijl anderen minimaal 2 Gig nodig hebben, ligt dat alleen aan het OS of zijn er nog andere oorzaken?

[AmbroosV]

Het heeft wel veel voordelen hoor. Echt zware apps durven op iOS zelfs al eens crashen door een gebrek aan RAM. Safari moet heel dikwijls tabs opnieuw laden, ... Op mijn Xperia Z2 met 3GB daarentegen ben ik dikwijls aangenaam verrast als een app die ik drie dagen geleden heb gebruikt nog in exact dezelfde staat terug opengaat. Zelfde met tabs in Chrome, die blijven schijnbaar eindeloos open zolang er genoeg RAM is!

[raro007]

hier leggen ze ook uit de verschillen van ios en android multitasking http://www.extremetech.co...-works-on-android-and-ios
als je goed leest is het ook erg duidelijk waarom android meer vraagt dan ios.

[RebelwaClue]

Omdat in de meeste gevallen op een iPhone apps die je opstart bevroren worden als je een andere app start. Terwijl bij Android reutelen ze lekker door. Daarom hoor je vaak dat Android echt multitasking kent. Of het ook nuttig is, is een tweede overigens.

[Soldaatje]

Het is niet dat Android het nodig heeft maar het kan wel sneller zijn bij zware apps.

[halofreak1990]

Lichtelijk off-topic, maar anyway, iOS is geoptimaliseerd voor de hardware waar het op draait. Windows Phone is geoptimaliseerd om vloeiend te draaien op de door Microsoft gestelde minimum hardware. Bij Android... geen idee, maar gezien de in vergelijking belachelijk hoge systeemeisen in combinatie met apps, kan ik niet anders concluderen dat er niet of nauwelijks geoptimaliseerd wordt. In ieder geval niet op het gebied van apps.

[henk1994]

Het is nu nog makkelijker om telefoons te stelen en vervolgens te wissen. Nadat er 10 keer een verkeerde code is ingevoerd wordt er een Factory reset uitgevoerd.... De data is dan weliswaar weg, maar het toestel kan daarna niet meer op afstand geblokkeerd worden

[Loekie]

eh nee.
Bij ons bedrijf werken we nog wel eens met iPhones en die kun je weggooien als de oude gebruiker niet de factory reset uitvoert. 10 keer verkeerde code levert geen reset op.
Ben android-fan, maar vind dat wel een sterk punt in privacy-opzicht.

[RebelwaClue]

Dit is prima in te stellen met een mobile device management tool als Airwatch. Al ben je dan afhankelijk van een derde partij.

[Loekie]

Mjah, optie om foon qua nieuwprijs in mindering te krijgen bij niet correct inleveren doet ook wonderen Verder doen we absoluut niet zuur, krijgt men doorgaans het laatste type en bij defecten geen kosten, dus een stokje als dit achter de deur lost dat op.
Dat airwatch is wel nice, maar zware overkill voor ons. We hoeven onze gebruikers niet te volgen.

[Reactie gewijzigd door Loekie op 26 juli 2024 07:49]

[RebelwaClue]

Hahaha dat werkt ook ja. Al hadden we laatst een iPhone ter reparatie met find my iphone nog aan, gebruiker wist het wachtwoord niet meer en het AppleID stond op een mail adres die niet meer bestond. Was ook een telefoon die we nu konden gebruiken voor onderdelen.

[_David_]

Dat kan je toch gewoon zelf instellen op je iPhone? Android heeft dat niet eens zo ver ik weet.

[RebelwaClue]

Android heeft dat ook, maar hou er rekening mee dat als je geen encrypted telefoon hebt, (Android haalt alleen de pointers weg naar die data) de data terug te halen is en bij een versleutelde telefoon niet. Beetje vergelijkbaar hoe FAT bestanden 'verwijderd'. Overigens geldt dit voor oudere Android versies, weet niet of dit vanaf Kitkat nog zo is.

[Reactie gewijzigd door RebelwaClue op 26 juli 2024 07:49]

[Verwijderd]

Android beschikt sinds 3.x over dm-crypt. Daarnaast beschikt 4.4 over SELinux, ECDSA en SCRYPT.

[Jasper Janssen]

Het punt met apple is dat sinds ios 6 of 7, tenzij jij als gebruiker (volledig logged in met je icloud account) de beveiliging (find my iphone) uitzet voordat je de telefoon afgeeft, kan hij alleen geactiveerd worden door apple's servers met *die* apple account. Dus ook als hij volledig gewist wordt doordat je tig keer de verkeerde code ingeeft, zorgt Apple ervoor dat het een brick is tenzij hij met jouw account unlocked wordt.

Dit is ook de reden dat ze in de apple store je altijd de find my iphone uit laten zetten voordat ze hem innemen voor reparatie/vervanging.

[njitter]

dat kan altijd al.. booten in recovery en een reset uitvoeren.

[Kliko]

Wat doet dit met de performance op een (huidige) telefoon?
Zal hij tijdens het opstarten langzamer zijn omdat alle gemount/gedecrypt moet worden?
Of wordt dit 'on the fly' gedaan?

[henk1994]

Het opstarten kan iets langer duren omdat de bestanden dan gedecrypt moeten worden, maar verder merk je er weinig van

[HKLM_]

Momenteel heb ik op mijn Android toestel encryptie aan staan. Bij het opstarten / rebooten van de telefoon dient eerst de encryptie sleutel /pin te worden opgevoerd voordat android verder kan booten. Het opstarten van je telefoon duurt hierdoor wel tussen de 5 & 10 seconden langer helaas.

[_David_]

Je moet alleen tijdens een coldboot je pincode weer opnieuw invoeren voordat hij je /data partition decrypt, geen performance hit in Android zelf

[pkhoe]

Mijn oude Nexus 4 is niet trager met ingeschakelde encryptie.

[Blubber]

Goede ontwikkeling, ik neem aan dat dit geen betrekking heeft op de SD kaart?

[Dannisi]

De huidige manier wel, die doet ook de SD.
Hopelijk kan je dit uitzetten, of kan de recovery de SD ontsleutelen, want anders gaan custom roms lastig worden.

[Blubber]

De huidige manier wel, die doet ook de SD.
Hopelijk kan je dit uitzetten, of kan de recovery de SD ontsleutelen, want anders gaan custom roms lastig worden.

Mmm, zorgt er dus ook voor dat je die SD kaart niet ergens anders in kunt stoppen. Ik ben zelf geen android gebruiker, ik heb geen idee hoe vaak men dit doet.

[looc]

Niet vaak tot gewoon niet uit mijn ervaringen.
SD kaartje wordt in mijn omgeving gebruikt, omdat er simpelweg niet genoeg ruimte is op de telefoon zelf

[Verwijderd]

Ik wissel nog wel eens van telefoon en verhuis mijn 32GB met filmpjes en foto's eenvoudig mee. Dat wordt dan dus een heel stuk lastiger/tijdrovender.

[Alphalorne]

Ja dat leek mij dus ook. Of je zal gewoon kunnen decrypten alvorend de kaart te verhuizen.

[Dannisi]

In 4.4 is de enige manier om de encryptie eraf te krijgen een hard reset.

[dimitrimissinne]

Dat was ook mijn eerste gedachte. Tenzij er natuurlijk de optie is om je SD-kaart niet te encrypten, maar laat dat nu net de plaats zijn waar bij veel mensen een hoop persoonlijke informatie te vinden valt. Dan hebben ze wel geen toegang tot de smartphone zelf maar hebben ze misschien meer dan genoeg aan de data op je SD-kaart.
Misschien kan er wel voor gezorgd worden dat er een encryptietool met de bewuste sleutels op de SD-kaart geplaatst wordt van zodra de encryptie op je smartphone actief komt, zodat je die los van de smartphone kunt ontgrendelen met je passcode...

Edit: typo

[Reactie gewijzigd door dimitrimissinne op 26 juli 2024 07:49]

[Verwijderd]

Ik ben bang dat voor custom roms er gepartioneerd moet worden. Een speciale partitie voor je nandroid/recovery die niet encrypted is. De nandorid (het image) moet je uiteindelijk ook weer kunnen encrypten als je de boel safe wilt houden. Feit is dat je bij een boot in recovery je een partitie moet kunnen aanspreken waar je al of niet encrypted nandroid backup op staat. Geen flauw idee of dit mogelijk is, maar zou ik zelf wel op prijs stellen. Ik wil eigenlijk wel encrypten maar dat ik dan geen nadroid backup van internal of sd storage kan terug zetten is groot gemis.

[Thekilldevilhil]

Mijn 64GB kaart zit vol met muziek (letterlijk vol...) maar hij is er sinds dag 1 nooit uit geweest. Ik gooi de data er altijd van de pc via de telefoon opde SD kaart.

[Reactie gewijzigd door Thekilldevilhil op 26 juli 2024 07:49]

[Trommelrem]

Is er ook een mogelijkheid om met een TPM te werken? Ik heb zo'n vermoeden dat 90% van de gebruikers z'n unlockcode niet eens weet, omdat zo'n unlockcode al gauw 64 karakters kan zijn.

[Verwijderd]

De unlockcode is versleuteld met je zelfgekozen wachtwoord of numerieke code (PIN of dat pattern slide dingetje bijvoorbeeld). Je hoeft alleen je eigen code dus in te toetsen, dan wordt automatisch de unlockcode ontsleuteld en gebruikt om het toestel te ontsleutelen. Zoals eerder genoemd in de comments komt het neer op de volgende analogie:

Een briefje met de encryptiesleutel, in een kluis met je eigen code. Dat briefje gebruikt je toestel om alles te ontgrendelen maar je moet de kluis daarvoor wel open krijgen.

[Trommelrem]

Maar als je een TPM hebt, dan hoef je helemaal geen code in te voeren, totdat er een wijziging is aan de hardware. Je hebt dan alleen een recovery key nodig. Dat is voor gebruikers veel gemakkelijker.

[Jasper Janssen]

Maar dat wil je helemaal niet.

Als je mobiele telefoon 'open' is totdat de stroom wegvalt ben je gewoon screwed, want je hoeft dan als aanvaller er alleen maar op tijd een microUSBtje in te steken om alles te hebben. Met vaste PCs werkt dat anders.

[Trommelrem]

De kabel kan toch worden afgeschermd achter de TPM?

[Jasper Janssen]

Meer als: als het open is totdat ie stroom verliest, en je zorgt dat ie nooit stroom verliest, dan heb je er niet veel aan. En mobiele telefoons verliezen onder normale omstandigheden nooit de stroom.

Dit werkt wel veel beter bij een vaste PC die als ie gejat wordt normaal gesproken *wel* stroomloos raakt.

[Soldaatje]

En de versies vóór L konden die wel gedecrypt worden door derden als encryptie handmatig geactiveerd is?

[_David_]

Nee, het was toen alleen nog niet standaard ingeschakeld.

[Verwijderd]

Versies voor de L en na de L kunnen gewoon door Google of veiligheidsdiensten ontgrendeld worden. Of zijn we nu echt allemaal zo naief geworden en werkelijk geloven dat Google of Apple met deze maatregelen opeens de telefoons ontoegankelijk maken voor de NSA? Hebben jullie nu helemaal niks geleerd van Snowden?

[pkhoe]

Ik hoop wel dat de encryptie in Android L uit te schakelen is. Het zelf kunnen inschakelen is voor de meeste Android gebruikers genoeg lijkt mij.

[i-chat]

neej op zijn minst moet het standaard aan staan, elke gebruiker die niet weet waarom het uit zo moeten, heeft er baat bij dat het standaard aan staat,

en maar mijn telefoon wordt er traag van, of, ja maar ik heb niets te verbergen zijn geen geldige opties, zulke mensen horen 24/7 close up te worden gefilmt, zodat wij ook eens kunnen lachen,

[DummyXL]

Werkt de verkenner optie dan nog in bijv. Ubuntu om dingen te verplaatsen?

[_David_]

Ja zodra je je pincode invoert decrypt Android je /data partition en kan je er weer bij.

[Remcom00]

Voorheen kon je je Android toestel niet encrypten als je geroot was, hopelijk gaat rooten dus niet voor problemen zorgen of kan je de encryptie gewoon uitzetten.

[Loekie]

Moderne recoveries ondersteunen encryption gewoon(iig TWRP en vermoedelijk CWM ook wel).
Tegenwoordig boot ik alleen de recovery(dus niet flashen) en dan flash ik de rom/root ik.