Apple geeft ios-beveiligingsdetails vrij

Je hebt inmiddels gehoord dat Apple op de recente Black Hat-conferentie een nieuw bug-bounty-programma heeft aangekondigd. In een ongewone verschijning deed Ivan Krstic, hoofd van Apple voor beveiligingstechniek en architectuur, de aankondiging zelf. Maar dat was slechts de laatste 10 minuten van een presentatie van 50 minuten. De eerste 40 minuten nam Krstic een ongekende diep duik in drie componenten van iOS-beveiliging. En met diep bedoel ik bathyspheric.

Mijn algemene afhaalmaaltijd was een gevoel van ontzag voor hoe grondig deze systemen gebruikersgegevens beschermen, zelfs tegen Apple zelf. Ik zal proberen over te brengen wat er is gezegd, zonder al te technisch te worden.

Geharde WebKit JIT-mapping

Sorry, zo heet het. JIT staat voor Just In Time en verwijst naar de manier waarop JavaScript-code net op tijd wordt gecompileerd voor uitvoering. "Dit is nodig voor krachtige JavaScript", legt Krstic uit. "Maar het beleid voor het ondertekenen van codes moet worden versoepeld. De JIT-compiler zendt nieuwe, niet-ondertekende code uit. Een aanvaller die een schrijf-overal-aanval heeft beheerd, kan de uitvoering van willekeurige code mogelijk maken."

Voor een beetje achtergrond kunnen geheugengebieden worden gemarkeerd met lees-, schrijf- en uitvoeringsrechten. Dat onderscheid, dat eeuwen geleden werd geïntroduceerd, vernietigde aanvallen die code uitvoerden in gebieden die waren gewijd aan gegevens. In het kort, de oplossing van Apple omvat een techniek die het gecompileerde JavaScript in een geheugengebied plaatst dat alleen uitvoering toestaat. Processen kunnen niet lezen wat er is of nieuwe gegevens schrijven. Er is iets meer aan de hand, maar deze verandering, specifiek voor iOS 10, vernietigt een hele reeks mogelijke aanvallen.

Secure Enclave-processor

Toepassingen op een Apple-apparaat worden uitgevoerd in een CPU die de toepassingsprocessor of AP wordt genoemd. Moderne Apple-apparaten hebben een volledig gescheiden CPU, de Secure Enclave Processor of SEP. "De SEP wordt beschermd door een sterke cryptografische hoofdsleutel van de toegangscode van de gebruiker", aldus Krstic. "Offline aanval is niet mogelijk. Het omzeilt het aanvalsoppervlak van het AP, zelfs wanneer het AP gecompromitteerd is. Het bemiddelt alle gebruikerstoegang en beheert zijn eigen gecodeerde geheugen. Bij de eerste initialisatie gebruikt het een echte willekeurige nummergenerator om een ​​uniek apparaatsleutel in de processor. Het is niet exporteerbaar en het is opgeslagen in een onveranderlijke beveiligde ROM."

Krstic legde vervolgens uit hoe het apparaat vier soorten interne beveiligingssleutels gebruikt met verschillende kenmerken. Type A bestaat alleen wanneer het apparaat is ontgrendeld. Type B is een altijd aanwezige openbare sleutel, plus een privésleutel die bestaat wanneer het apparaat wordt ontgrendeld. Type C ontstaat wanneer het apparaat voor het eerst wordt ontgrendeld na het opstarten. En type D is altijd beschikbaar.

De presentatie ging verder met een aantal serieus ingewikkelde diagrammen. Eén stapte door het proces van het opstarten en ontgrendelen van het apparaat en liet zien hoe elk sleuteltype werd gemaakt en opgeslagen. Elk bestand op uw apparaat heeft zijn eigen, unieke coderingssleutel; een ander diagram toonde de ingewikkelde dans waarmee de SEP dat bestand kan authenticeren en decoderen terwijl de essentiële beveiligingssleutels in zichzelf worden bewaard. Een ander legde het complexe proces uit dat het mogelijk maakt om "Later bijwerken" te kiezen. En nog een andere liep door het proces dat ontgrendeling via touch ID mogelijk maakt zonder de hoofdsleutel op enigerlei wijze zichtbaar te houden.

Het belangrijkste aspect van dit deel van het gesprek is dat Apple echt, echt heeft nagedacht over wat nodig is om de codering volledig in de Secure Enclave-processor te beheren, zonder de gebruiker te dwingen om veel moeite te doen. Als je die diagrammen zelf wilt zien, bekijk dan de volledige presentatie van de Krstic.

Geheimen synchroniseren

Het is ontzettend handig dat je je gegevens tussen meerdere Apple-apparaten kunt synchroniseren. Met HomeKit kun je IoT-apparaten beheren, AutoUnlock laat je Mac ontgrendelen wanneer je Apple Watch in de buurt is, je foto's worden gesynchroniseerd via iCloud, enzovoort. Maar qua beveiliging is synchroniseren een probleem.

"Traditionele benaderingen zijn niet goed, " zei Krstic. "Eén manier is om de gebruiker een sterke 'sokladesleutel' op alle apparaten in te voeren; deze te verliezen en de toegang tot de geheimen gaat verloren. De andere manier is om de gegevens in een afgeleide sleutel te verpakken die de gegevens blootstelt aan de accountprovider."

"We hadden hier een aantal doelen, " vervolgde Krstic. "Geheimen moeten op alle apparaten beschikbaar zijn, beschermd door sterke crypto. Gebruikers kunnen geheimen herstellen, zelfs als ze alle verbonden apparaten verliezen. Gegevens worden niet blootgesteld aan Apple, en er is geen mogelijkheid tot een brute-force aanval."

Verificatie in het standaard iCloud-sleutelhangersysteem is eenvoudig. Elk apparaat heeft zijn eigen sleutelpaar en om een ​​nieuw apparaat aan de synchronisatiecirkel toe te voegen, moet u het van een van uw bestaande apparaat goedkeuren. De backend van Apple is niet betrokken; het heeft geen voorrecht. Als een gebruiker de toegang tot alle apparaten verliest, kan de toegang worden hersteld met behulp van zowel de iCloud-beveiligingssleutel als het iCloud-wachtwoord.

Krstic legde uitvoerig uit hoe Apple dit systeem beheert zonder de minste mogelijkheid open te laten dat iemand, inclusief iedereen bij Apple, toegang heeft tot gegevens van de back-end. Het systeem omvat zogenaamde admin-kaarten, gemaakt op het moment dat een nieuwe vloot crypto-servers in gebruik wordt genomen. "Admin-kaarten worden gemaakt tijdens een beveiligde ceremonie wanneer de vloot in bedrijf wordt gesteld en opgeslagen in afzonderlijke fysieke kluizen in bewaring van drie verschillende organisaties bij Apple, in verzegelde bewijszakken", aldus Krstic.

Die situatie duurt slechts totdat de vloot daadwerkelijk in gebruik wordt genomen. Op dat moment zei Krstic: "We hebben de admin-kaarten een nieuwe eenrichtingshash-functie gegeven." Hij trok een duidelijk gebruikte blender onder het podium en vervolgde: "Ja, een reis door de blender." Zodra de vloot van crypto-servers actief is, kan deze op geen enkele manier worden bijgewerkt of gewijzigd, zelfs niet door Apple, omdat de admin-kaarten zijn vernietigd. Als het echt nodig is om een ​​update uit te voeren, moet Apple een nieuwe vloot op gang brengen en een software-update sturen waarmee gebruikersapparaten verbinding kunnen maken met de nieuwe vloot.

"Waarom doen we dit", zei Krstic. "Waarom zetten we deze laatste stap die buitengewoon ongebruikelijk is? We doen er alles aan om de beveiligingssystemen te engineeren om vertrouwen te bieden. Wanneer gegevens het apparaat verlaten, is de inzet nog groter. We moeten dat vertrouwen behouden. Als we bezit blijven houden die admin-kaarten, de mogelijkheid is niet waar. Dat is hoe serieus we onze missie over gebruikersgegevens nemen."

Gevraagd: "Heb je dit gedaan vanwege de FBI-verzoeken om informatie?" Krstic antwoordde: "Ik ben een ingenieur. Ik kan alleen vragen beantwoorden over waarom ik vandaag presenteerde." OK, eerlijk genoeg. Maar ik denk dat de vragensteller gelijk had. Het is een redelijk goede manier om te voorkomen dat iemand anders ongewenste wijzigingen aanbrengt.

Ik hoop dat ik het detailniveau in Krstic's toespraak heb overgebracht zonder je ogen te laten glanzen. Te oordelen naar het geratel toen de groep zich verspreidde, waren de echte beveiligingsgeeks op byte-niveau in de kamer zeer onder de indruk.