Apple avslører ios sikkerhetsdetaljer

Du har hørt nå at Apple kunngjorde et nytt bug-bounty-program på den nylige Black Hat-konferansen. I et uvanlig utseende ga Ivan Krstic, Apples sjef for sikkerhetsteknikk og arkitektur kunngjøringen selv. Men det var bare de siste 10 minuttene av en 50-minutters presentasjon. I løpet av de første 40 minuttene tok Krstic et dypt dykk uten enestående i tre komponenter av iOS-sikkerhet. Og på det dype, mener jeg badysfærisk.

Min generelle takeaway var en følelse av ærefrykt for hvor grundig disse systemene beskytter brukerdata, selv fra Apple selv. Jeg skal prøve å formidle det som ble sagt, uten å bli for teknisk.

Herdet WebKit JIT-kartlegging

Beklager, det er det det heter. JIT står for Just In Time, og viser til måten Javascript-koden er samlet på rett tid for utførelsen. "Dette er nødvendig for JavaScript med høy ytelse, " forklarte Krstic. "Men kodesigneringspolitikken må være avslappet. JIT-kompilatoren avgir ny, usignert kode. En angriper som administrerte et angrep på hvor som helst kan skrive ut vilkårlig kode."

For litt bakgrunn kan minneområder markeres med lese-, skrive- og utføringsrettigheter. Denne skillet, introdusert for aldre siden, sluppet ut angrep som utførte kode i områder viet til data. I korte trekk innebærer Apples løsning en teknikk som setter det kompilerte JavaScript i et minneområde som bare tillater utførelse. Prosesser kan ikke lese hva som er der eller skrive nye data. Det er litt mer enn det, men denne endringen, spesifikk for iOS 10, utsletter en hel rekke mulige angrep.

Sikker enklavprosessor

Programmer på en Apple-enhet kjøres i en CPU som kalles Application Processor, eller AP. Moderne Apple-enheter har en helt egen CPU som kalles Secure Enclave Processor, eller SEP. "SEP-en er beskyttet av en sterk kryptografisk hovednøkkel fra brukerens passord, " sa Krstic. "Frakoblet angrep er ikke mulig. Det omgir angrepsoverflaten på AP, selv når AP har blitt kompromittert. Det arbitrer all brukertilgang og administrerer sitt eget krypterte minne. Ved første initialisering bruker den en ekte tilfeldig tallgenerator for å lage en unik enhetsnøkkel i prosessoren. Den kan ikke eksporteres, og den er lagret i uforanderlig sikker ROM."

Krstic fortsatte med å forklare hvordan enheten bruker fire typer interne sikkerhetsnøkler med forskjellige egenskaper. Type A eksisterer bare når enheten er ulåst. Type B er en alltid til stede offentlig nøkkel, pluss en privat nøkkel som finnes når enheten er låst opp. Type C kommer i gang første gang enheten låses opp etter oppstart. Og type D er alltid tilgjengelig.

Presentasjonen gikk videre til en rekke alvorlig kompliserte diagrammer. En gikk gjennom prosessen med å starte og låse opp enheten, og viste hvordan hver tastetype ble opprettet og lagret. Hver fil på enheten din har sin egen, unike krypteringsnøkkel; et annet diagram viste den intrikate dansen som lar SEP autentisere og dekryptere filen mens de viktige sikkerhetsnøklene er i seg selv. En annen forklarte den komplekse prosessen som gjør det mulig for deg å velge "Oppdater senere." Og enda en gang gjennom prosessen som gjør det mulig å låse opp via berørings-ID uten å holde hovedtasten synlig på noen måte.

Den viktigste takeawayen fra denne delen av samtalen er at Apple virkelig, virkelig har tenkt gjennom hva som kreves for å administrere kryptering fullstendig i Secure Enclave Processor, uten å tvinge brukeren til å gå til mye problemer i det hele tatt. Hvis du ønsker å se diagrammene for deg selv, kan du sjekke Krstics fullstendige presentasjon.

Synkronisere hemmeligheter

Det er veldig praktisk at du kan synkronisere dataene dine mellom flere Apple-enheter. HomeKit lar deg administrere IoT-enheter, AutoUnlock får Mac-en til å låse opp når Apple Watch er i nærheten, bildene dine synkroniseres gjennom iCloud, og så videre. Men sikkerhetsmessig er synkronisering et problem.

"Tradisjonelle tilnærminger er ikke bra, " sa Krstic. "En måte er å få brukeren til å legge inn en sterk 'sokkeskuffnøkkel' på alle enheter; miste den og tilgangen til hemmelighetene går tapt. Den andre måten er å pakke inn dataene i en avledet nøkkel som etterlater dataene eksponert for kontoleverandør."

"Vi hadde en rekke mål her, " fortsatte Krstic. "Hemmeligheter må være tilgjengelige på alle enheter, beskyttet av sterk krypto. Brukere kan gjenopprette hemmeligheter selv om de mister alle tilkoblede enheter. Data blir ikke utsatt for Apple, og det er ingen mulighet for et brute-force angrep."

Godkjenning i det grunnleggende iCloud Keychain-systemet er enkelt. Hver enhet har sitt eget nøkkelpar, og for å legge til en ny enhet i synkroniseringssirkelen, må du godkjenne den fra en av din eksisterende enhet. Apples backend er ikke involvert; det har ingen privilegier. Hvis en bruker mister tilgangen til alle enheter, kan tilgangen gjenvinnes ved å bruke både iCloud Security Key og iCloud-passordet.

Krstic forklarte i detalj hvordan Apple administrerer dette systemet uten å forlate den minste mulighet for at noen, inkludert noen på Apple, kunne få tilgang til data fra baksiden. Systemet involverer det som kalles admin kort, opprettet på det tidspunktet en ny flåte av krypto-servere blir satt i gang. "Administrasjonskort opprettes i en sikker seremoni når flåten blir satt i gang, og lagres i separate fysiske safer i varetekt av tre forskjellige organisasjoner på Apple, i sabotasjebevisede bevisposer, " sa Krstic.

Denne situasjonen varer bare til flåten faktisk er satt i drift. Den gang sa Krstic, "Vi legger administrasjonskortene gjennom en ny enveis hasjfunksjon." Han trakk en tydelig brukt blender fra under pallen og fortsatte: "Ja, en tur gjennom mikseren." Når flåten av krypto-servere er aktiv, kan den ikke oppdateres eller modifiseres på noen måte, ikke engang av Apple, fordi admin-kortene er ødelagt. Hvis det hender at det virkelig kreves en oppdatering, må Apple spinne opp en ny flåte og sende ut en programvareoppdatering som får brukerenheter til å koble seg til den nye flåten.

"Hvorfor gjør vi dette, " sa Krstic. "Hvorfor tar vi dette siste trinnet som er ekstremt uvanlig? Vi legger stor vekt på å konstruere sikkerhetssystemene for å gi tillit. Når data forlater enheten, er innsatsen enda høyere. Vi må opprettholde den tilliten. Hvis vi holder inne på de admin-kortene, er det en mulighet som ikke stemmer. Det er hvor alvorlig vi tar vårt oppdrag om brukerdata."

Spurt: "Gjorde du dette på grunn av FBI-forespørsler om informasjon?" Krstic svarte: "Jeg er ingeniør. Jeg kan bare svare på spørsmål om hvorfor jeg presenterte i dag." Ok greit nok. Men jeg tror spørsmålet hadde rett. Å lage et selvforsynt system som du ikke en gang kan endre deg selv er en ganske god måte å forhindre at noen andre gjør uønskede endringer.

Jeg håper jeg har formidlet detaljnivået i Krstics tale uten å få øynene dine til å glans. Å dømme etter skravling da gruppen spredte seg, var de sanne sikkerhetsgeeksene på bynivå i rommet sterkt imponert.