Apple afslører ios sikkerhedsoplysninger

Du har hørt nu, at Apple annoncerede et nyt bug-bonusprogram på den nylige Black Hat-konference. I en usædvanlig udseende afgav Ivan Krstic, Apples chef for sikkerhedsteknik og arkitektur, meddelelsen selv. Men det var bare de sidste 10 minutter af en 50-minutters præsentation. I de første 40 minutter tog Krstic et hidtil uset dybt dykk i tre komponenter af iOS-sikkerhed. Og dybt, jeg mener badysfærisk.

Min samlede takeaway var en ærefrygt for, hvor grundigt disse systemer beskytter brugerdata, selv fra Apple selv. Jeg vil prøve at formidle det, der blev sagt, uden at blive for teknisk.

Hærdet WebKit JIT-kortlægning

Beklager, det hedder det. JIT står for Just In Time og henviser til den måde, hvorpå Javascript-kode er samlet lige i tide til dens udførelse. "Dette er nødvendigt for JavaScript med høj ydeevne, " forklarede Krstic. "Men kodesigneringspolitikken skal lempes. JIT-kompilatoren udsender ny, usigneret kode. En angriber, der administrerede et angreb overalt overalt, kunne muliggøre udførelse af vilkårlig kode."

For en lille baggrund kan hukommelsesområder markeres med læse-, skrive- og udførelsestilladelser. Denne sondring, der blev indført for aldre siden, slukede angreb, der udførte kode i områder, der var afsat til data. Kort fortalt involverer Apples løsning en teknik, der sætter det kompilerede JavaScript i et hukommelsesområde, der kun tillader udførelse. Processer kan ikke læse hvad der er eller skrive nye data. Der er lidt mere ved det end det, men denne ændring, der er specifik for iOS 10, udsletter en lang række mulige angreb.

Sikker enklaveprocessor

Programmer på en Apple-enhed kører i en CPU kaldet Application Processor eller AP. Moderne Apple-enheder har en helt separat CPU kaldet Secure Enclave Processor eller SEP. "SEP'en er beskyttet af en stærk kryptografisk hovednøgle fra brugerens adgangskode, " sagde Krstic. "Offline-angreb er ikke muligt. Det adskiller angreboverfladen på AP, selv når AP er blevet kompromitteret. Det voldgører al brugeradgang og administrerer sin egen krypterede hukommelse. Ved første initialisering bruger den en ægte tilfældig nummergenerator til at skabe en unik enhedens nøgle i processoren. Den kan ikke eksporteres, og den er gemt i en uforanderlig sikker ROM."

Krstic fortsatte med at forklare, hvordan enheden bruger fire typer interne sikkerhedstaster med forskellige egenskaber. Type A findes kun, når enheden er låst op. Type B er en altid til stede offentlig nøgle plus en privat nøgle, der findes, når enheden er låst op. Type C kommer i gang første gang enheden låses op efter opstart. Og type D er altid tilgængelig.

Præsentationen gik videre til en række alvorligt indviklede diagrammer. En gik gennem processen med at starte og låse enheden op og vise, hvordan hver tastetype blev oprettet og gemt. Hver fil på din enhed har sin egen unikke krypteringsnøgle; et andet diagram viste den komplicerede dans, der lader SEP autentificere og dekryptere filen, mens de vigtige sikkerhedstaster er inde i sig selv. En anden forklarede den komplekse proces, der gør det muligt for dig at vælge "Opdater senere." Og endnu en gang gik gennem processen, der tillader oplåsning via touch-id uden at holde hovedtasten synlig på nogen måde.

Den vigtigste afhentning fra denne del af samtalen er, at Apple virkelig, virkelig har tænkt igennem, hvad der kræves for at administrere kryptering helt inde i Secure Enclave-processoren, uden at tvinge brugeren til at gå til store problemer overhovedet. Hvis du gerne vil se disse diagrammer for dig selv, så tjek Krstic's fulde præsentation.

Synkronisering af hemmeligheder

Det er forfærdeligt praktisk, at du kan synkronisere dine data mellem flere Apple-enheder. HomeKit giver dig mulighed for at administrere IoT-enheder, AutoUnlock får din Mac til at låse op, når din Apple Watch er i nærheden, dine fotos synkroniseres gennem iCloud osv. Men sikkerhedsmæssig er synkronisering et problem.

"Traditionelle tilgange er ikke gode, " sagde Krstic. "En måde er at få brugeren til at indtaste en stærk 'sokkeskuffenøgle' ​​på alle enheder; miste den, og adgangen til hemmelighederne går tabt. Den anden måde er at indpakke dataene i en afledt nøgle, der lader dataene blive eksponeret for kontoudbyder."

"Vi havde et antal mål her, " fortsatte Krstic. "Hemmeligheder skal være tilgængelige på alle enheder, beskyttet af stærk crypto. Brugere kan gendanne hemmeligheder, selvom de mister alle tilsluttede enheder. Data udsættes ikke for Apple, og der er ingen mulighed for et brute-force-angreb."

Godkendelse i det grundlæggende iCloud Keychain-system er enkelt. Hver enhed har sit eget nøglepar, og for at tilføje en ny enhed til synkroniseringscirklen, skal du godkende den fra en af ​​din eksisterende enhed. Apples backend er ikke involveret; det har intet privilegium. Hvis en bruger mister adgang til alle enheder, kan adgang genvindes ved hjælp af både iCloud Security Key og iCloud adgangskoden.

Krstic forklarede meget detaljeret, hvordan Apple administrerer dette system uden at lade den mindste mulighed åbne for, at nogen, inklusive nogen hos Apple, kunne få adgang til data fra bagenden. Systemet involverer, hvad der kaldes admin-kort, oprettet på det tidspunkt, hvor en ny flåde af kryptoservere tages i brug. "Administrationskort oprettes i en sikker ceremoni, når flåden er idriftsat og opbevares i separate fysiske pengeskabe, som de er i forvaring af tre forskellige organisationer hos Apple, i manipulationssikre bevisposer, " sagde Krstic.

Denne situation varer kun, indtil flåden faktisk er taget i brug. På det tidspunkt sagde Krstic, "Vi lægger admin kortene gennem en ny envejs hash-funktion." Han trak en klart anvendt blender under podiet og fortsatte, "Ja, en tur gennem blenderen." Når flåden af ​​kryptoservere er aktiv, kan den ikke opdateres eller ændres på nogen måde, ikke engang af Apple, fordi admin-kortene er blevet ødelagt. Hvis det sker, at der virkelig kræves en opdatering, skal Apple dreje en ny flåde op og sende en softwareopdatering, der får brugerenheder til at oprette forbindelse til den nye flåde.

”Hvorfor gør vi dette, ” sagde Krstic. "Hvorfor tager vi dette sidste skridt, der er ekstremt usædvanligt? Vi gør meget for at konstruere sikkerhedssystemerne til at give tillid. Når data forlader enheden, er indsatsen endnu højere. Vi er nødt til at opretholde denne tillid. Hvis vi holder besiddelse af disse admin-kort, er der en mulighed, der ikke er sandt. Det er hvor alvorligt vi tager vores mission om brugerdata."

Spurgt, "Har du gjort dette på grund af FBI-anmodninger om oplysninger?" Krstic svarede: "Jeg er ingeniør. Jeg kan kun svare på spørgsmål om, hvorfor jeg præsenterede i dag." OK, fair nok. Men jeg tror, ​​at spørgeren havde ret. At fremstille et selvstændigt system, som du ikke engang kan ændre dig selv, er en temmelig god måde at forhindre en anden i at foretage uønskede ændringer.

Jeg håber, at jeg har overbragt detaljeringsniveauet i Krstic's tale uden at få dine øjne til at glasere. At bedømme efter skravlen, da gruppen spredte sig, var de sande geek på byniveau i rummet meget imponeret.