'Onderzoekers kraken verbeterde bescherming tegen ontgrendeltools uit iOS-bèta'

De usb restricted mode die Apple in een bètaversie van iOS 12 introduceert om usb-ontgrendeltools te bestrijden, zou al gekraakt zijn door een van de makers van dergelijke tools. Hoewel ze dit beweren, hebben ze tot nu toe nog geen demonstratie daarvan gegeven.

Eerder deze maand kwam uit dat Apple werkt aan een usb restricted mode voor iOS 12. Die houdt simpelweg in dat usb-apparaten niet met een iPhone kunnen interacteren tenzij deze in het afgelopen uur nog ontgrendeld is geweest. De telefoon kan dan alleen via usb geladen worden, dataverkeer wordt niet toegestaan. In eerdere versies van iOS zit deze maatregel ook, maar dan was de tijdsperiode een week. De kortere tijdsperiode zou ontgrendelingstools onbruikbaar maken.

In een e-mail die Motherboard in heeft gezien stelt een forensisch expert dat GrayShift, de ontwikkelaar van de GrayKey-ontgrendeltool, 'hard werkt om zijn tools future proof te maken en de maatregelen uit de bèta-build reeds heeft verslagen'. Een ander persoon in het e-mailgesprek stelt dat Grayshift 'enkele weken geleden usb restricted mode al behandeld heeft tijdens een webinar'.

Dergelijke ontgrendeltools worden aangeboden door niet alleen GrayShift, maar ook het Israëlische Cellebrite. Uit ander onderzoek van Motherboard zou blijken dat dergelijke tools in de praktijk aftrek vinden bij Amerikaanse politiekorpsen. GrayKey zou volgens Forbes 15.000 dollar kosten voor 300 uses, en 30.000 dollar voor onbeperkt gebruik. De tool zou werken op iOS 10 en 11, met ondersteuning voor iOS 9 in de toekomst. Het apparaat gebruikt technieken om zo snel mogelijk de ontsleutelingscode van een iPhone te brute forcen en daarbij de maatregelen tegen te veel verkeerd gegokte codes te omzeilen.

Beeld: MalwareBytes

Reacties (109)

Deels off topic maar in de US is het zo dat een face unlock/vinger print niet onder het'je hoeft geen bewijs tegen jezelf te leveren' principe valt. Dus dan hebben advocaten etc vaak er nog pincode op. Weet iemand hoe dit in NL zit?

Ontopic, zou Apple er nu misschien een check in gooien met dat je alleen een data connectie kan hebben met vertrouwde apparaten?

Uit een interessant artikel van een jaar geleden dat is gepubliceerd op de Correspondent, had ik begrepen dat hier (op het moment van schrijven) nog geen concrete jurisprudentie over bestaan. De agenten gaven in het artikel als voorbeeld dat ze bij een verdachte van kleinschalige internetoplichting de telefoon van deze persoon hadden ontgrendeld door deze tegen de vingers van de op dat moment geboeide verdachte aan te houden. Het zelfde zal ook wel werken met face-ID. De redenatie daar achter dat de verdachte niet gedwongen wordt om aan het onderzoek mee te verwerken, omdat de passieve aanwezigheid van de verdachte in die ruimte al voldoende was om het toestel te ontgrendelen. Het uiteindelijke doel van dit 'experiment' was om een concreet oordeel van de rechter te krijgen, zodat de politie in het vervolg weet of deze vorm van onderzoek niet onder de noemer 'verplicht meewerken tegen jezelf' valt.

Uit voorzorg hadden de rechercheurs de bewijs uit deze telefoon gescheiden van al het andere vergaarde bewijs. Dus wanneer een rechter definitief zou oordelen dat het bewijs van de telefoon niet rechtsgeldig verkregen was, dan hadden ze alsnog een zaak met het overige bewijs dat wel via gangbare methoden is vergaard.

Bron (achter een betaalmuur): https://decorrespondent.n...ckt/626738532651-4865feea

Ik ben benieuwd wat er uit komt dan. Voorlopig gebruik ik geen vingerafdruk scaners of andere biometrische toegangscontrole op mijn apparatuur.

Als je flink op je power button ramt schiet je iPhone in emergency mode en is je USB data uit, je biometrische unlock uit en kun je nood diensten bellen etc.

Dat moet je ook nog maar het lukken tijdens een arrestatie.

Voor de Android gebruikers onder ons: als je telefoon vergrendelt wordt door een app die device administrator rechten heeft, dan wordt unlock met vingerafdruk ook uitgeschakeld. Nova Launcher kan dit bijvoorbeeld doen. Ik heb mijn Nova Launcher zo ingesteld dat als ik twee keer op m'n home screen druk, het scherm vergrendelt wordt en ik mijn pincode moet invoeren om weer te unlocken.

2.5 seconde lang volume omhoog of omlaag en de powerbutton tegelijk indrukken. Dan schiet ie ook meteen in emergency mode en schakelen inderdaad Face/TouchID ook uit.

Ongeoorloofd ontgrendelen met Face-ID kun je voorkomen door attention-aware in te schakelen. Mocht iemand dan je toestel willen ontgrendelen door 'm op je gezicht te richten, dan doe je je ogen dicht en mislukt de scan.

Ongeoorloofd ontgrendelen met Face-ID kun je voorkomen door attention-aware in te schakelen. Mocht iemand dan je toestel willen ontgrendelen door 'm op je gezicht te richten, dan doe je je ogen dicht en mislukt de scan.

Waardoor je gelijk een aanklacht voor obstructie of verzet bij arrestatie aan je broek hebt.

Ontopic, zou Apple er nu misschien een check in gooien met dat je alleen een data connectie kan hebben met vertrouwde apparaten?

Dat is niet echt praktisch als je vaak foto's e.d. wil kopiëren naar diverse computers, of voor development toestellen waarmee je apps ontwikkelt.
Die check bestaat trouwens al, als je je toestel in supervised mode zet kan je een pair lock erop ztten zodat nieuwe pairing records niet meer gegenereerd kunnen worden (je krijgt op onvertrouwde computers dan ook niet meer die 'trust this computer?' popup op je telefoon).

Het zou op zich wél fijn zijn als ze dat ook op unsupervised (lees: hoe de gemiddelse sterveling het heeft) toestellen makkelijk mogelijk maken.

Dat is niet echt praktisch als je vaak foto's e.d. wil kopiëren naar diverse computers, of voor development toestellen waarmee je apps ontwikkelt.

Waarom? Android doet dat nu al voor toegang via adb (vaak gebruikt op ontwikkeltoestellen). Meestal zul je die toestellen toch met een of hooguit een paar PC's gebruiken en je hioeft maar eenmalig toestemming te geven. Foto's uitwisselen gaat via een ander protocol maar dat kan bij iOS via iTunes misschien anders zijn.

iOS heeft dit ook, al een paar generaties. Je moet op je toestel aangeven dat je de aangesloten machine vertrouwd.

(je krijgt op onvertrouwde computers dan ook niet meer die 'trust this computer?' popup op je telefoon).

Die krijg je pas na het unlocken, dus als je de PIN weet of je vinger of gezicht bekend zijn bij de telefoon. Voordat je unlocked en toestemming geeft heb je van je PC geen toegang tot de data op de telefoon.

Alleen verziekt dat je filmrol omdat daar niets op datum staat maar perse op “date added”. Ik zoek nogsteeds een workaroud om oude foto’s te injecteren.

Tijd aanpassen naar gewenste datum, foto kopiëren, tijd terugzetten

Niet te doen met 3000+ foto’s

Ik mag aannemen dat ook iOS gewoon EXIF-data meeschrijft in de genomen foto's; er zijn diverse tools om deze informatie ook te gebruiken om foto's opnieuw te ordenen of te hernoemen.

Zeker, alleen heeft je filmrol er maling aan. Het verschijnt wel correct in “momenten” en albums, maar niet op juiste volgorde in de filmrol.

zou Apple er nu misschien een check in gooien met dat je alleen een data connectie kan hebben met vertrouwde apparaten?

Dat is wat Android nu al doet, je moet een keer bevestigen dat dat apparaat vertrouwd is en dan worden er encryptiesleutels uitgewisseld.

Dat is wat iOS natuurlijk ook gewoon doet maar evenals bij Android zitten in dit soort protocollen ook kleine foutjes. Als je het hoofd beveiliging overneemt van een bedrijf vind je die net wat makkelijker.

Die check zit er al in. Als je een data connectie over USB wil starten moet je eerst op het device op Trust drukken.

https://support.apple.com/nl-nl/ht202778

[Reactie gewijzigd door johnkeates op 17 juni 2018 15:32]

Als deze tooling werkt middels bruteforcing. Dan zouden ze toch beter brute force detectie in kunnen bouwen?

Dat zit standaard al in iOS, echter bypassed deze tool dit. Je kunt in iOS tevens aanvinken om al je gegevens te wissen na 10 poginen, echter werkt dat ook niet bij deze tool.

Het enige wat je tegen deze tool kan doen, is een custom passphrase instellen (dus pin code met alfanumerieke karakters), dan werkt de GrayKey standaard niet en dient de partij die over dit apparaat beschikt een wordlist mee te geven. Je bent dan natuurlijk nog steeds niet veilig, alleen gaat het een heel stuk langer duren.

Een techniek is het maken van een kopie, en daar tegen te bruteforcen.
Als de kopie zichzelf vergrendeld begin je opnieuw met een schone kopie van het origineel

Dat is niet wat hier gebeurt , maar even ter illustratie dat dat niet altijd mogelijk is.

Maar je kan dat wel heel moeilijk maken. De teller en het crypto gedeelte kan je in een Secure Element plaatsen. Dat gaat heel lastig worden om die daar uit te krijgen en je kan er ook niet zomaar een kopie van maken.

[Reactie gewijzigd door GekkePrutser op 17 juni 2018 13:39]

Dat zit er al in, maar als je de NAND of SSD lossoldeert, dupliceert, een bruteforce doet en hem laat wissen, dan gaat de teller weer op 0 en kan je de chip opnieuw dupliceren en het nog een keer proberen.

Niet met een Secure Element. Die kan je niet zomaar uitlezen. Die zijn juist gemaakt om dat te voorkomen.

Volgens mij zit dit er al in sinds de iPhone 5S trouwens, dus ik ben benieuwd wat voor truc ze gebruiken om het toch te kunnen doen. Misschien een bug in de encryptie code?

[Reactie gewijzigd door GekkePrutser op 17 juni 2018 15:48]

Nee, je leest niet de secure element, maar de SSD. Dan laat je daarna de SE het ding wissen als je brute force bezig bent, en als de software van de SE dan z'n teller op 0 zet kan je opnieuw aan de slag. Dat kon in elk geval tot aan de 5C nog dacht ik, om dat de wipe call maar 1x gedaan wordt.

De fix daarna was dat de keys gedropt werden, en dat de on-SSD data een device key kreeg zodat je zowel de passcode als de device key nodig had.

[Reactie gewijzigd door johnkeates op 17 juni 2018 15:57]

Ja maar als je zowel de crypto key als de teller in de secure element zet, dan kan dat dus niet. Want die kan je niet kopieren en de SE zal het na 10 pogingen gewoon voorgoed opgeven. Een goede SE wist zijn interne crypto keys ook bij een wipe.

In de 5C kon het inderdaad nog omdat die nog geen secure element had. Die is pas geintroduceerd samen met de vingerafdrukscanner, en wordt sindsdien ook voor dit soort dingen gebruikt.

Een secure element is eigenlijk een soort smartcard chip, vergelijkbaar met wat er in een SIM kaart of een pinpas zit. Na een X aantal pogingen is het gewoon af. Daarom denk ik ook dat ze hier een andere methode gebruiken.

[Reactie gewijzigd door GekkePrutser op 17 juni 2018 15:59]

Ik weet wat een SE is ;-) Waar ik op doel is dat de SE in elk geval nog tot iOS 11 gewoon na een reset de NAND blijft lezen.

Dus normaal met wipe data optie aan:
1. Brute force
2. SE wist NAND/SSD
3. Telefoon kan je een restore geven en weer gebruiken (na iCloud unlock)

Als je de storage chip dupliceert:
1. Chip lossolderen
2. Chip dupliceren
3. Duplicaat terugsolderen
4. Brute force
5. SE wist NAND/SSD
6. Chip lossolderen
7. Chip opnieuw schrijven
8. Chip terugsolderen
9. Nieuwe brute force doen

Probleem met de nieuwere software op de SE is dat de device keys ook gedropt worden en dan kan een teruggeplaatste storage chip nog steeds niet gelezen worden. Maar voor dat dat het geval was, kon je dus zo aal brute force aanvallen doen als je maar wil.

[Reactie gewijzigd door johnkeates op 17 juni 2018 17:01]

En daarom ook

en daarbij de maatregelen tegen te veel verkeerd gegokte codes te omzeilen.

Het is nog een bèta versie, dus maar even afwachten of ze het in de final nog kunnen.

Als ze het al kunnen. Als Apple dit succesvol implementeert dan zien die gasten hun inkomsten opdrogen natuurlijk. Daar gaat je 30K per apparaat.

[Reactie gewijzigd door WhatsappHack op 17 juni 2018 13:29]

30k of zelfs de 50k voor de ongelimiteerde versie is echt niks voor een overheid. Een exploit voor 2 volle iOS versies die zo weinig kost en zo simpel is om in te zetten is de natte droom van elke staat.
Ik vraag me eerder af hoe goed de contracten van GrayShift zijn dat Apple nog steeds dit apparaat niet in handen heeft. Dat en onder wat voor voorwaarden hun methode nog werkt.

Voor de overheid is het niets, maar voor die gasten is het een leuke inkomstenbron. Als het apparaat niet meer werkt dan wordt het al snel obsolete, zeker als het met iOS patches valt te verhelpen gezien het aantal gebruikers dat snel upgrade naar de nieuwste versie van iOS altijd torenhoog is.

Ik weet niet of dat aan de contracten ligt. De FBI en lokale politiediensten hebben er natuurlijk op geen enkele manier baat bij om het apparaat met Apple te delen, en het wordt niet verkocht aan andere partijen. Apple zal het dus via-via moeten zien te regelen. Of misschien hebben ze er al eentje en maken ze hier een schijnbeweging.

Waarschijnlijk heeft Apple het apparaat wel in handen, maar dat gaan ze natuurlijk niet aan iedereen vertellen.

Dan wordt het weer lobbyen door de FBI, maar die heeft tegenwoordig niet zo'n beste verhouding met Trump dus die zal wel niet heel hard lopen om hun ter wille te zijn.

Ik vind het inderdaad wel bijzonder dat GrayShift het nu al bekend maakt want inderdaad het gevolg is dat Apple nog strengere maatregelen gaat nemen.

Het idee van hij moet binnen het uur ontgrendeld geweest zijn is best leuk maar zou dat niet vrij simpel te beïnvloeden zijn door die telefoon in een kist te leggen zodat hij geen GSM signalen meer ontvangt van echte providers en dat in dat kistje je eigen GSM provider antenne zit die constant andere een tijd stuurt om te kijken of de telefoon daar positief op reageert, doet hij dat eenmaal dan is het een kwestie van die tijd vasthouden.

Dus bv de telefoon is in beslag genomen op 1-1-2018 om 12u dus dan stel je je eigen GSM provider tijd en datum in zodat hij de telefoon laat denken dat het 1-1-2018 11u is en werkt dat niet dan 10u, dan 9u enz. enz. net zo lang tot de gsm zich wel via USB laat beinvloeden, dat is dan toch zo gevonden en daarna kan alsnog het brute-forcen gestart worden.

Of denk ik nu veel te simpel.

Menig software timer vermeid dit probleem dus het lijkt me sterk dat het zo simpel is. Wel een creatieve manier om zoiets aan te pakken en dat is wel de manier om zo'n exploit chain op te zetten.

Misschien kan dat maar aangezien een telefoon ook een ingebouwde klok heeft kun je die timer natuurlijk ook op de interne klok laten lopen. En als de tijd opeens achteruit lijkt te lopen lijkt me dat ook een reden om de vergrendeling accuut in te schakelen.

Of een speciale zendmast gebruiken die de tijd nie veranderd. Dan heb je contact en tijd genoeg om eea te doen. En zo moeilijk is dat niet.

Paar punten die mee spelen in dit soort situaties;
1) iOS is gecompileerd 5GB (miljoenen regels code, een byte kan het verschil maken)
2) Er zitten alsnog onderdelen van 3th party vendors in een iPhone
3) Deze GrayKey is ontwikkeld in samenwerking met een voormalig beveligingsmedewerker van Apple
4) Het is niet bekend onder wat voor voorwaarde de GrayKey nog werkt icm iOS 12

Ik zou graag een optie toevoegen aan je lijstje
E) Geen van het bovenstaande.

GrayKey is een voorbeeld van een van de leveranciers van dergelijke tools, wie weet hun status?

@DLeijen wanneer was de laatste grote lek [...] ? Wellicht kan je beter stellen, wanneer was de laatste publiekelijk bekend gestelde grote lek [...] ?

Er is nog geen enkel bewijs voor de claims, kan net zo goed dit bedrijf zijn dat probeert inkomsten te redden totdat iOS 12 uitkomt en het toch niet blijkt te kunnen.

En hoezo slecht met beveiliging? Wanneer was de laatste grote lek die gebruikersdata vrijgaf bij Apple?

Apple heeft zo zijn security bugs hoor net als ieder ander dat ook heeft vergis je niet.

APPLE-SA-2018-06-01-1 macOS High Sierra 10.13.5, Security Update 2018-003 Sierra, Security Update 2018-003 El Capitan

APPLE-SA-2018-06-01-2 Safari 11.1.1

APPLE-SA-2018-06-01-3 iCloud for Windows 7.5

APPLE-SA-2018-06-01-4 iOS 11.4

APPLE-SA-2018-06-01-5 watchOS 4.3.1

APPLE-SA-2018-06-01-6 tvOS 11.4

APPLE-SA-2018-06-01-7 iTunes 12.7.5 for Windows

Dat er security patches zijn weet ik ook wel, net nog een geïnstalleerd, maar wanneer is er voor het laatst een lek geweest dat niet op tijd gedicht was en misbruikt is?

Precies! We weten helemaal niet over de hack zelf. Wat we wèl weten is dat, als het al waar is, ze een beta hebben gekraakt. De security jongens en meisjes van Apple zijn niet helemaal gek natuurlijk. Ze zullen er wel op geanticipeerd hebben dat iemand dit voor elkaar zou kunnen krijgen. Wat mij dus opvalt is dat de onderzoekers dit nu bekend maken. Dat was onder de jailbreakers niet de norm, zodra je een jailbreak van een beta te pakken had hield je je kaarten tegen de borst totdat Apple met een release kwam. En dan werd die uitgebracht.

[Reactie gewijzigd door OMX2000 op 18 juni 2018 01:42]

Erm ja die krakers zijn zo goed, die krijgen daar een stuk meer betaald waarschijnlijk dan bij Apple zelf (of elk andere tech firma).

Zie het van deze kant: Iemand die de beveiliging kraakt heeft gelijk een (erg goed) verkoopbaar product, deze personen zijn dus de R&D en Productie van het bedrijf gecombineerd en waarschijnlijk zal het een relatief klein team zijn.

Dat is speculatie. Ja ze zullen er veel voor betaald krijgen, maar da’s eenmalig. Terwijl de Apple engineers meerdere jaren in dienst zullen zijn, maw ze hebben een heel goed betaalde baan die niet afhankelijks van het eventuele vinden van een hack/kraak.

Hoe lang duurt een brute force ontgrendeling?

Dat ligt aan de lengte van je code. Een numerieke code van 4 cijfers is gemiddeld slechts een paar minuten werk. Een numerieke code wordt tenminste 8 cijfers aangeraden, maar het beste is het gebruik van een wachtzin met letters, cijfers en symbolen.

Een kennis met een iPhone 8 moest een code van minimaal 6 cijfers instellen. Als ze de oude truc (eerste keer direct invoeren, 2e keer 1 sec wachten, daarna wachttijd steeds verdubbelen) hanteren kan dat erg lang duren.

Standaard 6 cijfers, maar als je goed kijkt zie je bij de installatie dat de keus voor 4 cijfers er ook nog gewoon is.

ligt aan vele factoren waaronder de cpu waar je de bruteforce op uitvoert.

Het blijft een race tegen elkaar. Het was te verwachten dat men een work around of nieuwe methode zou vinden maar dit is wel heel erg snel.

Jammer dat er nog geen bewijs is geleverd hoewel misschien begrijpelijk gezien die methode daarna snel onmogelijk zal worden gemaakt (indien mogelijk).

[Reactie gewijzigd door Bor op 17 juni 2018 13:03]

Ik vind het ook heel erg snel. Wellicht dat Apple maar eens moet gaan kijken naar microkernel op basis van Rust of zo.

De wereld heeft een veilig besturingssysteem nodig.

[Reactie gewijzigd door ArtGod op 17 juni 2018 13:17]

Apple is bezig met hun software omzetten naar Swift waar je ook een hoop van de standaard C bugs vermeid.

Swift maakt het ook niet magisch veilig, heeft ook zijn bugs. Met standaard c is niets mis, probleem is gewoon dat een hoop mensen niet meer weten wat echt programmeren is. Je hebt steeds snellere hardware nodig om hetzelfde te kunnen, omdat men met steeds 'omslachtigere' frameworks werkt.

Libraries geport van Objective C naar Swift zijn sneller. Puristisch geneuzel over 'echt programmeren' doet er niet toe als een applicatie niet alleen sneller ontwikkeld kan worden, leesbaarder is, beter onderhoudbaar blijft maar ook nog eens beter presteert in een moderne taal.

Edit: Trouwens; de claim over veiligheid kwam van @ArtGod. Ik zeg alleen dat Apple al gebruik maakt van een taal die pointers en buffers automatisch regelt.

[Reactie gewijzigd door MiesvanderLippe op 17 juni 2018 19:05]

Hoe uitgebreider de taal en hoe groter het framework, hoe groter de kans op niet ontdekte veiligheid issues. Daarnaast, hoe basale de taal, bijvoorbeeld native C of Assembler, hoe meer controle op de wijze waarop code wordt uitgevoerd.

Daarnaast is het ook een feit dat bij een hogere taal, je afhankelijk bent van de compiler en je tegen het issue aan loopt zoals bugs in de gegenereerde code door fouten in de compiler.

Daarnaast is snelheid van de code vanuit security oogpunt totaal niet gewenst. Een pincode, password check mag best wel een seconde duren, of zelfs 2 seconden. Daarnaast is een timeout van 5 seconden of meer bij een fout ook ideaal. De reden is simpel, hiermee maak je brute force onmogelijk.

Bovendien, iedere taal die voorziet in garbage collection zodat men zelf geen objecten hoeft op te schonen is per definitie onveilig omdat gevoelige informatie altijd langer in het geheugen blijft staan dan strikt noodzakelijk is.

Mijn originele comment was bedoelt als reactie op de suggestie dat Rust Apple haar problemen op zou lossen. Dat Apple al bezig is naar de overstap op een modernere taal die dezelfde problemen oplost als Rust zou doen (alleen dan veel beter naar mijn mening).

Naar mijn idee kun je veel dingen beter oplossen op het niveau van de taal of de compiler dan telkens in code. Compiler bugs zijn stukken zeldzamer dan bugs in C code en kunnen met 1 update aangepakt worden. Dat heeft niks met goed kunnen programmeren te maken maar met onderhoud, overzicht en leesbaarheid (zie FB, Microsoft, Apple, Linux etc).

Enfin, dat je schrijft dat veiligheid voort kan komen uit hoe langzaam je taal is wekt bij mij al flink zorgen op. Als dat is hoe je er over denkt wordt ik al een beetje nerveus.

P.S. een ingebouwde GC betekent natuurlijk niet dat je zelf niks mag aanraken.

Dan lees je het niet helemaal correct. Bij bepaalde functionaliteit is snelheid niet benodigd. Wanneer je ook in de source duikt van bijvoorbeeld Linux dan zal je zien dat er zelfs comments opgenomen zijn dat het de voorkeur heeft om bepaalde routines niet te optimaliseren op snelheid.

Snelle code is goed waar het nodig is, langzame code met vertraging is goed bij andere zaken zoals bijvoorbeeld authenticatie.

Een voorbeeld, een ftp Server welke vanaf Internet te benaderen is en die op iedere login poging binnen een fractie van een seconde reageert zal dmv brute force langdurig worden aangevallen. Een server die pas na 5 Seconden reageert met een prompt en 25 seconden opnieuw na fout wachtwoord zal na 1 poging al worden overgeslagen. Een best practice voor bijvoorbeeld een secure SMTP server is pas input na 25-29 seconden te accepteren waardoor spam bots na 1 connectie poging een deur verder gaan.

Wat is dat dan als beveiliging als je traag gaat werken? Het heeft dan namelijk ook nadelen voor de echte gebruikers.. een server die pas na 5/25 seconden reageert vind ik onacceptabel, en een server die je laat bruteforcen is ook niet goed opgezet (na een paar pogingen moet je toch echt gewoon gaan blokken of DAN dus pas die traagheid gaan introduceren).
Maargoed, ieder zo zijn/haar eigen gedachte over wat wel acceptabel is en wat niet. Alles op dat gebied is in the eye of the beholder.

Kan best zijn dat snelheid niet gewenst is vanuit security oogpunt, maar als je snelheid gaat opofferen om wat veiliger te kunnen zijn, en daardoor de werkzaamheden een stuk trager gaan worden, dan wordt het nut van die security ook een stuk minder interessant.
En ben het eens wat betreft GC, erg handig, maar het zorgt er wel voor dat men gewoon met steeds minder dingen rekening houdt en er ook niet meer naar kunnen handelen als er problemen voor doen, omdat ze geen idee hebben van hoe de interne werking is (wat dus ook weer zorgt dat het lastiger wordt om een workaround te maken/bedenken zodra het nodig is).

Een beveiliging die gebruikt maakt van routines die 100.000 hashes per seconde kan uitrekenen is veel makkelijker te brute forces dan een beveiliging die 10 hashes / seconde kan uitrekenen.
Terwijl voor datacom een ultra snelle hash routine een vereiste is om enige bandbreedte te kunnen halen.

Kortom het gebruik van hashes als SHA1, SHA2, MD5, etc. etc. als basis voor beveiliging is een onhandige keus... Beter is een hash algerithme dat gewoon meer tijd nodig heeft per hash.
Dat geldt ook voor login processen. Die zijn uitstekend te ontwikkelen dat die 1 a 2 keer een gebruiker niet/nauwelijks hinderen door bv. tijd tussen activeren en eerste code cijfer/letter en interval tussen code cijfers/letters te meten... Te snel.. dan = poging tot inbraak, voldoende traag dan voorlopig ok. en zodra er een keer of 3 fout geraden is beginnen met verdubbelen van intervallen.

Pincode met alleen cijfers... is ook slechts een beperkt domein, idem bij 4 cijfers.. max 10000 pogingen nodig voor een geldige code gevonden wordt. m.i. zou na 6 missers gedurende enige tijd 5 minuten ook een geldige code afgekeurd moeten worden. en als de eerste poging na toestaan van allen de correcte code ook fout is ook die tijd verdubbelen...
van de 3 en 6 uit bovenstaande mag ook 4 en 8 of 5 en 9 oid gemaakt worden maar niet veel groter.

wat een onzin dat je een trage hash routine zou willen. Een sterke hash kan ook rustig snel zijn, is dan gewoon puur afhankelijk van de gebruikte hardware. En timen tussen code/letter is wel erg onzinnig, zeker omdat genoeg mensen dingen gebruiken als passwordmanagers etc.
En na 6 missers, ja dan mag het wel 5 minuten (of zelfs langer) duren voordat er opnieuw gepobeerd kan worden, maar die 6 codes moeten wel gewoon binnen een fractie van een seconde afgehandeld kunnen zijn.

Een trage hash betekent niet dat je heel veel vertraging tijdens aanloggen zou hebben.....
Alleen heel veel tijd voor het raden van ww.

Met 100.000 hash/seconde is een rainbow table zo aangelegd voor een bepaalde hash onder bepaalde condities. Als een hash algorithme 10 hashes/ seconde kan uitrekenen kost het aanleggen van een set rainbow tables 1000 keer zo lang....
Voor jou is het verschil in wacht tijd 0.1 - 0.000001 seconde.
Zelfs met een hash die er 1 seconde over zou doen om van ww -> gehashde versie te gaan is geen probleem, 1 seconde vertraging / logon..., maar in bulk hashes uitrekenen /rainbow tables zijn niet haalbaar meer.
Dus een trage password hash routine heeft zeker voordelen tov. een snelle.

Daarnaast heb ik het over dat ook het correcte password na 3 missers afgekeurd moet worden.
Dan is immers niet meer te bepalen of een ww. wel of niet geraden is... (Dit is trouwens een veel toegepast inbraak ontwijkings methode).

Maar alles is relatief, want hoe lang een hash algorithme duurt is afhankelijk van de gebruikte hardware..

De maximale snelheid van Objective-C ligt op zo goed als (%je verschil) op die van C. Swift kan ook unsafe pointers gebruiken en dan krijg je meestal het zelfde als C. Je hebt dan nog steeds alle problemen van C overigens. Maar de standard library van Swift is doorgaans sneller en veiliger dan de equivalenten in Objective-C

Maar de applicatie wordt niet leesbaarder of beter onderhoudbaar of beter presteert.. En als Swift beter presteert dan Objective C dan ligt dat eerder aan de implementatie van Apple van hun Objective C (wat dus niet hetzelfde is als standaard C).

Ik vind het ook heel erg snel. Wellicht dat Apple maar eens moet gaan kijken naar microkernel op basis van Rust of zo.

De wereld heeft een veilig besturingssysteem nodig.

Wat versta je onder veilig.


De partijen die het het hardst nodig hebben, hebben totaal verschillende motieven.

Aan de ene kant heb je bedrijven (kapitaal, voorsprong) die hun geheimen niet willen delen,
aan de andere kant heb je criminelen/misdadigers die ook hun geheimen niet willen delen.

Het is een utopie om te veronderstellen dat er een dienst of apparaat zal ontstaan die zoiets (commercieel) zal aanbieden.

Dat zijn de enige twee uitersten? Waar is de gewone huis-tuin-en-keuken-gebruiker die niks illegaals op z'n toestel doet maar liever niet heeft dat de politie (of een andere partij) al die data gaat uitpluizen, mocht ie per ongeluk tussen de voetbalhooligans of demonstranten terecht komen.

Ik bedoel, in theorie heb ik niks te verbergen. Ik doe geen illegale dingen en heb geen illegale documenten op m'n telefoon staan. Maar mocht ik per ongeluk in een situatie verzeild raken waarin de politie m'n telefoon wil uitlezen (en dat kan een simpele aanrijding zijn, als ze bijvoorbeeld het vermoeden hebben dat ik zat te whatsappen), dan heb ik liever dat mijn volkomen legale data ook echt volkomen van mij blijft. Ik heb niet veel vertrouwen in de politie, af en toe wordt er wel eens een mol opgepakt, maar ik denk dat veel politiepersoneel gewoon corrupt is. Je moet maar afwachten waar je data uiteindelijk weer terecht komt, hoe oninteressant die data verder ook is.

Dus, fijn dat Apple zoveel moeite doet om mijn data van mij te laten blijven.

Rust maakt niet iets magisch veilig.

Het zou een goede zet zijn van apple dat ze de beta juist gebruiken om te kijken hoe bijvoorbeeld graykey werkt en dat dit gelogd wordt naar Apple. Zodat ze het in de final release kunnen dichten.

Je kan er wel vanuit gaan dat er in de labs van GrayShift geen ontvangst is hoor. Of in ieder geval dat de toestellen absoluut geen verbinding naar buiten kunnen maken.

Durf te wedden dat apple dit hardwarematig in de toekomstige devices gaat aanpakken zodat het niet te kraken is.

Dat was ook het doel van Secure Enclave, maar het lijkt er dus op dat Celebrite en GrayShift een gat hebben gevonden in dat systeem. Het is wachten tot Apple dat weet te patchen.

Ik zou graag een paar opties hebben in het settings menu:

- alle lightning apparaten blokkeren
- alleen +5 / aarde activeren, data over lightning blokkeren
- bluetooth pairing blokkeren (bluetooth uit bestaat natuurlijk al)

Uitzetten van connectiviteit die je niet gebruikt is een good practice: reducen van de ruimte waarop je kunt aanvallen.
Ik denk dat veel mensen niets doen met lightning / USB behalve laden. En datvladen wordt ook contactloos.

Nadeel van het volledig blokkeren van Lightning 'data', betekend dat je deze ook zelf nooit meer kunt herstellen via DFU-modus. Als je de normale optie aan hebt van iOS, kan dat na een uur ook niet, maar als je dan een crash krijgt, heb je dan een uur de tijd om te herstellen.