Apple vs FBI

Update 27 – Het Inzicht– mei 2016

In de rubriek Het Inzicht stellen wij bepaalde (technische) beveiligingsproblemen aan de orde. Dit keer gaat Matthijs Koot, security consultant bij Madison Gurkha, dieper in op het ‘Apple vs FBI’-verhaal.

Apple versus FBI

In februari jl. beval de FBI Apple mee te werken aan het doorzoeken van de iPhone van één van de (omgekomen) daders van de schietpartij in San Bernardino. Apple weigerde dat. De FBI ondernam juridische stappen, maar maakte vlak voor de eerste hoorzitting bekend de telefoon te kunnen ontgrendelen via een (vooralsnog) onbekende methode die tegen betaling is verworven van een (vooralsnog) onbekende derde. Hoe zat het precies met het FBI-bevel aan Apple? In dit Inzicht de zaken nog eens op een rijtje, met aandacht voor een aantal technische details van iOS.

 

Versleuteling: de UID en passcode
De telefoon van de dader betreft een iPhone 5c met iOS 9. Sinds iOS 8 is de ‘Data Protection’- functie, opslagversleuteling, standaard ingeschakeld. Op iOS 9 werkt dat op hoofdlijnen als volgt [Apple2015].

Er is sprake van twee geheime codes. De eerste geheime code is de ‘Passcode Key’, kortweg ‘passcode’: dat is de code die de gebruiker instelt bij ingebruikname van het iOS-device. iOS 9 vraagt de gebruiker een 6-cijferige code in te stellen, maar de gebruiker kan ook een veel langere alfanumerieke code opgeven.

De tweede geheime code is de ‘Hardware Key’, ook wel ‘Unique Identifier’ of kortweg ‘UID’: dat is een 256-bits AES-sleutel die tijdens het fabrikageproces van de CPU-chipset (A6, A7, A8, enz.) wordt gegenereerd en in de hardware zit ingebakken. Op iOS-devices met een A7-chipset of nieuwer, zoals de iPhone 5s en de iPhone 6, bevindt de UID zich in de ‘Secure Enclave’, een co-processor met een door Apple geminimaliseerde versie van ARM TrustZone. De iPhone 5c, het model waar het bij San Bernardino om gaat, heeft geen Secure Enclave. (Om dit Inzicht ook relevant te houden voor gebruikers van nieuwere iOS-devices, wordt toch enkele malen gerefereerd aan de Secure Enclave.)

ApplevsFBI

Figuur 1, afkomstig uit Apple’s documentatie, geeft weer welke sleutels worden gebruikt. Op iOS vindt de versleuteling plaats op bestandsniveau, afhankelijk van de ‘Protection Class’ die aan een bestand is toegewezen. Voor elk bestand wordt een random sleutel gegenereerd, de ‘File Key’: daarmee worden de gegevens in het bestand feitelijk versleuteld. Er zijn vier klassen: ‘Complete Protection’, ‘Protected Unless Open’, ‘Protected Until First User Authentication’ en ‘No Protection’. Elke klasse heeft een eigen sleutel, de ‘Class Key’, die wordt gebruikt om de ‘File Key’ te versleutelen. De versleutelde ‘File Key’ wordt opgeslagen in de metadata van het bestand. Die metadata zelf is versleuteld met een ‘File System Key’, die wordt gegenereerd tijdens de installatie van iOS en wordt opgeslagen in een snel wisbaar gedeelte van het flashgeheugen. De ‘File System Key’ dient louter als schakel in het mechanisme voor remote wipe en auto-erase. Wanneer de gebruiker de passcode wijzigt, wijzigt alleen de versleuteling van de ‘Class Keys’. Die werkwijze voorkomt dat bij elke wijziging van de passcode alle bestanden volledig opnieuw moeten worden versleuteld. De ‘File Key’ wijzigt dus niet. (Het is niet bekend hoe iOS de random sleutels genereert en hoe random deze precies zijn; bij iOS 7.)

Van de passcode en de UID wordt via PBKDF2 een sleutel afgeleid. Het aantal PBKDF2- iteraties is volgens Apple zo afgestemd dat 80ms(hardwarematige) vertraging per inlogpoging wordt geïntroduceerd. Bestanden met de klasse ‘Complete Protection’ maken gebruik van een ‘Class Key’ die is versleuteld met een sleutel die wordt afgeleid van de passcode en UID. Dat geldt ook voor bestanden met de klassen ‘Protected Unless Open’ en ‘Protected Until First User Authentication’. Alleen bij bestanden met de klasse ‘No Protection’ is dat anders: de ‘Class Key’ van deze bestanden is versleuteld met alleen de UID. Dat is bijvoorbeeld nodig voor om het besturingssysteem te kunnen laten booten tot aan het passcodescherm. De ‘File Key’ en ‘Class Key’ worden vanaf A7-chipsets nimmer in het normale geheugen verwerkt; de ‘key wrapping’ (conform RFC 3394) vindt daar plaats binnen de Secure Enclave, en de Secure Enclave spreekt met minder vertrouwde delen van de hardware tijdelijke sleutels af als ‘toegangscontrole’ voor het versleutelen en ontsleutelen.

Hoe kom je achter de UID en passcode?
Hoe achterhaal je de passcode? Hoe random de passcode is, en of iets of iemand meegluurde toen de gebruiker deze instelde en sindsdien invoerde, is op voorhand niet te zeggen. Als de passcode alleen bij de (in dit geval overleden) dader bekend is, dan zal in beginsel moeten worden gedacht aan brute-force proberen. Het brute-forcen van een alfanumerieke passcode van 6 cijfers en kleine letters zou volgens Apple vanwege de 80ms(hardwarematige) vertraging maximaal 5.5 jaar duren. Gemiddeld zal het in de helft van die tijd lukken. Natuurlijk kunnen voor hand liggende combinaties eerst worden geprobeerd: ‘000000’, ‘123456’, ‘654321’, betekenisvolle datums, postcodes, enz.; met een beetje geluk is het dan veel eerder raak. Heel soms zal keyspace-reductie mogelijk zijn op basis van vetvlekken op het schermpje, daar waar zich toetsen van het on-screen toetsenbord bevinden.

Een eerste probleem bij het brute-forcen is dat iOS na 5 passcode-pogingen een minuut blokkering oplegt voordat een volgende poging kan worden gedaan; na 6 pogingen een blokkering van vijf minuten, etc.; en na 9 pogingen een blokkering van een uur. Na 10 foute pogingen moet het device op iTunes worden aangesloten om een restore uit te voeren. Daarbij gaan gegevens die op het device zijn toegevoegd sinds de laatste backup verloren, net als bijvoorbeeld de cache van on-screen toetsaanslagen (die, voor zover bekend, niet in de backup staat). Daarna zijn opnieuw 10 pogingen mogelijk. Op die manier kan een passcode in principe brute-force worden achterhaald, maar erg praktisch is dat niet.

Een tweede probleem is de auto-erase-functie: indien deze is ingeschakeld (standaard uitgeschakeld), dan wordt na 10 foute passcode-pogingen de ‘File System Key’ gewist. Op dat moment kunnen de bestandsmetadata en bestanden met de klasse ‘No Protection’ niet meer worden ontsleuteld, en het besturingssysteem daarom niet meer booten. (De documentatie van Apple vermeldt overigens niet wat bij de auto-erase gebeurt met de versleutelde bestanden en metadata, waaronder dus ook gebruikersgegevens; vermoedelijk blijven deze, versleuteld, in het flashgeheugen aanwezig.)

Dan de UID. Hoe achterhaal je die? Hoe random de UID is, en of iets of iemand meegluurde bij het fabricageproces, is niet bekend. Volgens Apple wordt de UID niet vastgelegd bij Apple of Apple’s leveranciers[Apple2015]. Op iOS-devices met de A6-chipset, zoals de iPhone 5c van de dader, is de UID volgens Snowden te achterhalen via ‘chip decapping’([Snowden2016]). Het is denkbaar dat de UID ook kan worden gevonden door deze uit het werkgeheugen van de A6-chipset te dumpen, mits de relevante pin-outs kunnen worden geïdentificeerd en chocola kan worden gemaakt van de signalen op die pins. Op devices met een Secure Enclave wordt de UID volgens Apple nooit in het werkgeheugen verwerkt, en zou dan (nog) veel moeilijker te achterhalen zijn.

Als de UID niet bekend is, dan zou ook díe moeten worden geraden, wil men kunnen brute-forcen via het rechtstreeks aanspreken van het flashgeheugen in plaats van de normale kanalen. Aangezien de UID 256 bits lang is, is dat onwerkbaar. Vanaf de A7-chipset zou het vanwege de Secure Enclave bovendien niet mogelijk zijn om op deze wijze een brute-force-aanval uit te voeren, omdat de extra vertraging per inlogpoging dan niet door de iOS-software, maar door de Secure Enclave wordt afgedwongen. Om die vertraging te omzeilen zou aangepaste Secure Enclave-firmware nodig zijn.

Ten overvloede: bestanden met de klasse ‘No Protection’ zijn toegankelijk voor een ieder met fysieke toegang tot het device, zonder de passcode te kennen. De FBI kan dus reeds bij de gegevens in die bestanden; maar zal daar weinig spannends vinden. (Ontwikkelaars van iOS-apps beslissen trouwens zelf welke klasse ze toepassen voor opslag van gebruikergegevens, en zouden dus ook ‘No Protection’ kunnen kiezen; in dat geval zijn de gegevens niet beschermd bij diefstal of verlies van het device.)

Het FBI-bevel
De FBI eiste van Apple een methode die 1) “will bypass or disable the auto-erase function whether or not it has been enabled”, en 2) “will enable the FBI to submit passcodes to [the device] for testing electronically via the physical device port, Bluetooth, Wi-Fi, or other protocol available on [the device]” (want de passcode kan normaal alleen via het on-screen toetsenbord worden ingevoerd), en 3) “will ensure that when the FBI submits passcodes to [the device], software running on the device will not purposefully introduce any additional delay between passcode attempts (...)”. De FBI wil dus ongelimiteerd en zonder softwarematig geïntroduceerde vertraging tussen passcode-pogingen geautomatiseerd passcodes kunnen uitproberen via een kabeltje, Bluetooth of Wi-Fi, zonder te riskeren dat de auto-erase-functie wordt getriggerd.

Er is op iOS-devices sprake van twee geheime codes: de Passcode Key en de Hardware Key

Technisch gezien kan Apple aan de eis van de FBI voldoen door een aangepaste versie van iOS beschikbaar te stellen. Een Apple-executive sprak in die context over “GovtOS”, anderen trokken “FBI” en “iOS” samen tot “FBiOS”. Het iOSbeveiligingsmodel maakt dat nieuwe iOS-firmware door een iOS-device alleen wordt geaccepteerd indien deze digitaal is ondertekend onder Apple’s eigen root CA, waarvan het certificaat op iOSdevices is opgeslagen (in de BootROM). Zonder zo’n ondertekening weigert een iOS-device de firmware. Een door Apple ondertekende variant van iOS zou via de Device Firmware Upgrade-functie (DFU) als ramdisk in het werkgeheugen van een inbeslaggenomen device moeten worden geladen en uitgevoerd. Dat kan zonder passcode. Indien de gebruiker de Find My iPhone-functie heeft ingeschakeld, zijn Apple ID-credentials nodig, maar daarvoor zou Apple eventueel een bypass kunnen maken voor de FBI.

Op devices met een A7-chipset of nieuwer worden de extra vertraging en auto-erase afgedwongen door de Secure Enclave. Maar naar verluidt zou de L4-firmware die in de Secure Enclave draait door Apple zelf te updaten zou zijn, zónder dat gebruikersdata wordt gewist [Guido2016, Kelley2016]. Als dat klopt, wat toch enigszins saillant zou lijken, dan kan Apple technisch gezien ook voor devices met een A7-chipset of nieuwer voldoen aan dit FBI-bevel.

De FBI stelt in haar bevel dat de aangepaste iOSfirmware alléén moet kunnen worden uitgevoerd op het device waarop het bevel betrekking heeft, gebaseerd op unieke identifiers: “serial numbers, ECID, IMEI, etc.”. Door de aangepaste firmware te binden aan unieke identifiers wordt het risico op misbruik teruggebracht, aangenomen dat de gebruikte identifiers op een vergrendeld device niet zomaar te vervalsen zijn. Maar de FBI heeft dus niet gevraagd om generieke firmware die tegen om het even welk iOS-device kan worden ingezet.

Het uitlekken van zo’n GovtOS-image heeft, op ‘t eerste oog, alleen gevolgen voor de veiligheid van één device. Het manipuleren van dat image om het geschikt te maken voor een ander device, of generiek te maken, eist ten minste dat een aanvaller het image zo weet te manipuleren dat een collision optreedt in het hashalgoritme dat wordt gebruikt bij het genereren van de ondertekening (de ‘SHSH-blob’). De kans dat zo’n aanval kan worden uitgevoerd vóórdat de hele wereld alweer op de volgende versie van iOS draait, en de uitgelekte GovtOS-image z’n waarde heeft verloren, is waarschijnlijk klein, maar ook niet uit te sluiten. De FBI stelt in haar bevel (daarom?) dat de firmware on-site bij Apple zelf, dus op de Apple-campus in Cupertino, op het device mag worden geladen. Als de firmware de fysieke grenzen van de Apple-campus nimmer verlaat, is er minder gelegenheid voor ongewenste distributie (resteert de insider threat).

De FBI eiste iOS-firmware die auto-erase en passcode delays uitschakelt, en toestaat passcodes (geautomatiseerd) uit te proberen zonder die op het scherm in te toetsen

Het werken met een device-specifiek GovtOSimage betekent dat voor elk toekomstig te onderzoeken device een nieuw image moet worden gemaakt. Tenzij de FBI toegang heeft tot de iOS-broncode en de private key die Apple gebruikt voor ondertekening, moet Apple dat doen. Het is best mogelijk een voldoende veilige interface op te zetten tussen de FBI en Apple. De FBI zou de relevante versie-informatie en unieke identifiers aan Apple kunnen toezenden, en Apple vervolgens, eventueel na een out-of-band controle, een nieuw GovtOS-image genereren.

Als de FBI de rechtszaak had voortgezet en Apple was blijven weigeren, zou de FBI volgens mediaberichten van plan zijn bruutweg toegang te eisen tot de iOS-broncode en Apple’s private key. Volgens weer andere mediaberichten zou dat bij andere bedrijven reeds zijn gebeurd, op grond van de FISA.

Backdoor-light
Het feit dat Apple in staat is een iOS-variant te maken die via DFU kan worsden geladen, kan in zekere zin al worden opgevat als backdoor. Zij het eentje waarbij nog steeds de passcode moet worden geraden; een backdoor-light, zeg maar.

Het is niet uitgesloten dat andere methoden bestaan om gegevens te achterhalen of de passcode te brute-forcen; voor de iPhone 5c bleek dat laatste het geval. Indien een gebruiker iCloud-backups heeft ingeschakeld, dan staat een gedeelte van de gegevens op servers van Apple, versleuteld met een sleutel die bekend is bij Apple (dus zonder passcode of UID). En indien een device binnen 48 uur sinds de laatste ontgrendeling niet is uitgeschakeld of gereboot, en wordt gekoppeld met een computer die door het device reeds wordt vertrouwd, is het eveneens mogelijk om toegang tot sommige gegevens te krijgen: dan start de synchronisatie namelijk zonder dat de passcode opnieuw hoeft te worden ingevoerd. Maar dat zijn toevalstreffers die zich in de opsporingspraktijk vermoedelijk zelden voordoen, en waarbij bovendien onbekend blijft of er belangrijke gegevens op het device staan die niet in de backup staan. (Bij San Bernardino bleek dat trouwens niet het geval.)

Techbedrijven en overheden
Bij San Bernardino staat buiten kijf dat het gaat om een dader van de moord op 14 personen, is de betrokkene dood, en heeft de eigenaar van de telefoon, de werkgever van de dader, toestemming gegeven voor ontgrendeling. Tóch weigert Apple. ‘Apple vs FBI’ gaat dus niet over de (on)mogelijkheid om toegang te krijgen tot gegevens op deze ene iPhone, maar om de vraag in hoeverre van techbedrijven mag worden verlangd dat zij inspanningen leveren ter ondersteuning van opsporingsen inlichtingenwerk. Ook de (legitieme) vijand gebruikt moderne technologie en kan beschikken over een niveau van beveiliging dat, kijkend naar bijvoorbeeld iOS-devices met de Secure Enclave, toch behoorlijk hoog begint te worden. Dat is niet goed of fout; het is gewoon een realiteit.

Dat Apple zegt zes tot tien engineers twee tot vier weken te moeten inzetten om de gevraagde software te maken, soit; dat gaat over kosten en beschikbaarheid van personeel. Er zijn belangrijkere vragen: als Apple dit verzoek inwilligt, moeten dan ook andere techbedrijven dit soort verzoeken tegemoet zien? Moet een medewerkingsplicht zich kunnen uitstrekken tot het op afstand laten inschakelen van een microfoon of camera? En tot toegang tot broncode en geheime sleutels? Moeten verzoeken van andere landen worden ingewilligd? Wie beslist daarover, en hoe?

Betogen dat techbedrijven per definitie geen medewerking moeten verlenen aan opsporingsdiensten en inlichtingen- en veiligheidsdiensten, staat gelijk aan het ontkennen van de rechtsstaat. In een rechtsstaat worden belangen immers altijd tegen elkaar afgewogen, en zijn er geen belangen die te allen tijde als troefkaart kunnen worden gespeeld. In verschillende rechtsstaten, waaronder Nederland, is reeds sprake van bepaalde medewerkingsplichten: bijvoorbeeld de plicht voor aanbieders van openbare communicatienetwerken om aftapbaar te zijn. Discussie over medewerkingsplichten ging en gaat, ook in het debat over de Wiv20xx, niet of nauwelijks om een principieel ‘voor’ of ‘tegen’, maar vooral over voorwaarden (kosten, verantwoordelijkheden, beveiliging, schade), toezicht, en wettelijke waarborgen (bescherming van grondrechten, noodzaak/proportionaliteit/subsidiariteit).

Dat misbruik niet is uit te sluiten, bleek ook bij tapvoorzieningen: zo werd de mobiele telefoon van de premier van Griekenland aldaar illegaal afgeluisterd via (zeer verfijnde) spyware op een tapvoorziening bij de betrokken telecomaanbieder [Spectrum2005]. Zo’n incident is echter geen bewijs dat tapvoorzieningen massaal onveilig zijn en worden misbruikt door onbevoegden (of bevoegden). Gezonde skepsis over opsporings- en inlichtingenbevoegdheden is een deugd, maar vooralsnog moet worden vastgesteld dat er weinig voorbeelden bekend zijn van (overtuigende) casussen van misbruik. Als het klopt dat bij de NSA in een decennium tijd een dozijn LOVEINT-incidenten hebben gespeeld, en er niet óók tientallen of honderden niet-opgemerkte gevallen van oneigenlijk gebruik zijn, is dat toch niet heel slecht voor zo’n enorme organisatie. Zonder daarmee de ernst van die incidenten te ontkennen of te concluderen dat de status quo helemaal jofel is. Het blijft tandenknarsen.

Afsluiting
Had Apple moeten meewerken aan het verzoek van de FBI? Er zijn op z’n minst heldere voorwaarden, waarborgen en effectief toezicht nodig. De huidige situatie, waarin de FBI vertrouwt op een (generieke) 0-day is in elk geval minder florissant dan dat de FBI is genoodzaakt tot (specifieke) medewerking van Apple. Het is denkbaar dat de FBI de derde partij al langer voor handen had en simpelweg hoopte dat Apple onder druk zou buigen voor het bevel, zodat de FBI meer dan één methode zou hebben zonder daadwerkelijk een juridisch precedent te veroorzaken. Want ook voor de FBI is de uitkomst van zo’n rechtszaak onzeker, zoals hen duidelijk zal zijn geworden uit de massale bijval die Apple vanuit de (advocaten van de) Amerikaanse techsector en burgerrechtenbewegingen wist aan te wakkeren.

[Apple2015] (versie september 2015, bezocht 2 april 2016), https://www.apple.com/business/docs/iOS_Security_Guide.pdf
[Guido2016] https://blog.trailofbits.com/2016/02/17/apple-can-comply-with-the-fbi-court-order/
[Kelley2016] https://twitter.com/JohnHedge/status/699882614212075520
[Snowden2016] http://www.ibtimes.co.uk/apple-vs-fbi-snowden-says-decapping-can-crack-iphone-used-by-san-bernardino-attacker-syed-farook-1545397
[Spectrum2005] http://spectrum.ieee.org/telecom/security/the-athens-affair

 

@Secura 2018
Webdesign Studio HB / webdevelopment Medusa