ios-sikkerhet ios 9.0 eller nyere September 2015

Transkript

1 ios-sikkerhet ios 9.0 eller nyere September 2015

2 Innhold Side 4 Side 5 Side 10 Side 18 Side 27 Side 31 Introduksjon Systemsikkerhet Sikker oppstartssekvens Godkjenning av systemprogramvare Secure Enclave Touch ID Kryptering og databeskyttelse Maskinvarens sikkerhetsfunksjoner Beskyttelse av fildata Koder Databeskyttelsesklasser Beskyttelse av nøkkelringdata Tilgang til passord som er arkivert i Safari Nøkkeletuier Sikkerhetssertifiseringer og -programmer Appsikkerhet Appkodesignering Sikkerhetsprosesser ved kjøring Tillegg Appgrupper Databeskyttelse i apper Tilbehør HomeKit HealthKit Apple Watch Nettverkssikkerhet TLS VPN Wi-Fi Bluetooth Single Sign On AirDrop-sikkerhet Apple Pay Apple Pay-komponenter Hvordan Apple Pay bruker Secure Element Hvordan Apple Pay bruker NFC-kontrolleren Klargjøring av betalingskort Betalingsgodkjenning Transaksjonsspesifikk dynamisk sikkerhetskode Kontaktløs betaling med Apple Pay Betaling med Apple Pay i apper Lojalitetskort Midlertidig sperring, fjerning og sletting av kort 2

3 Side 38 Side 50 Side 56 Side 57 Side 58 Side 60 Internett-tjenester Apple-ID imessage FaceTime icloud icloud-nøkkelring Siri Kontinuitet Spotlight-forslag Enhetskontroller Kodebeskyttelse Sammenkoblingsmodellen i ios Konfigurasjonshåndheving Mobile Device Management (MDM) Programmet for enhetsregistrering Apple Configurator Enhetsrestriksjoner Restriksjoner for overvåkede enheter Fjernsletting Finn iphone og Aktiveringslås Kontroller for personvern Stedstjenester Tilgang til personlig informasjon Retningslinjer for personvern Avslutning En forpliktelse til å sørge for sikkerhet Ordliste Endringslogg for dokumentet 3

4 Introduksjon Programvare Maskinvare og firmware Databeskyttelsesklasse Secure Enclave Appsandkasse Brukerpartisjon (kryptert) OS-partisjon Filsystem Kjerne Krypteringsmotor Enhetsnøkkel Gruppenøkkel Apple-rotsertifikat Secure Element Sikkerhetsdiagrammet for ios gir en visuell oversikt over de ulike teknologiene som er beskrevet i dette dokumentet. Apple satte sikkerheten i høysetet da ios-plattformen ble utviklet. Da vi gikk i gang med å utvikle den beste mobilplattformen det var mulig å lage, dro vi nytte av mange års erfaring for å lage en helt ny arkitektur. Vi tok for oss sikkerhetsrisikoene i skrivebordsmiljøet og innførte en ny sikkerhetstankegang for utviklingen av ios. Vi utviklet og tok inn nyskapende funksjoner med standardinnstillinger som øker mobilsikkerheten og beskytter hele systemet. Det gjør at ios er et stort skritt framover når det gjelder sikkerhet for mobile enheter. Alle ios-enheter består av programvare, maskinvare og tjenester som er utviklet for å fungere sammen med maksimal sikkerhet og gi en åpen brukeropplevelse. ios beskytter ikke bare enheten og arkiverte data, men hele økosystemet, inkludert alt brukerne gjør lokalt, i nettverk og i de viktigste Internett-tjenestene. ios og ios-enheter har avanserte sikkerhetsfunksjoner samtidig som de er enkle å bruke. Mange av disse funksjonene er slått på som standard, slik at IT-avdelingen ikke trenger å utføre omfattende konfigurasjoner. Og de viktigste sikkerhetsfunksjonene, som enhetskryptering, kan ikke konfigureres, for å unngå at brukerne slår dem av ved en feiltakelse. Andre funksjoner, for eksempel Touch ID, forbedrer brukeropplevelsen ved å gjøre det enklere og mer intuitivt å gjøre enheten sikker. Dette dokumentet inneholder detaljert informasjon om hvordan sikkerhetsteknologi og -funksjoner er implementert i ios-plattformen. Det hjelper også bedrifter med å bruke sikkerhetsteknologi og -funksjoner i ios-plattformen sammen med egne regler og prosedyrer, slik at de kan dekke bedriftens spesifikke sikkerhetsbehov. Dokumentet er delt inn i følgende emner: Systemsikkerhet: Den integrerte og sikre programvaren og maskinvaren som er plattformen for iphone, ipad og ipod touch. Kryptering og databeskyttelse: Arkitekturen og utformingen som beskytter brukerdata hvis enheten er blitt borte eller stjålet, eller hvis en uautorisert person forsøker å bruke eller endre enheten. Appsikkerhet: Systemene som gjør at apper kan kjøre sikkert uten at det går på bekostning av plattformintegriteten. Nettverkssikkerhet: Nettverksprotokoller som følger bransjestandardene og som sørger for sikker godkjenning og kryptering ved dataoverføring. Apple Pay: Apples løsning for sikker betaling. Internett-tjenester: Apples nettverkbaserte infrastruktur for meldinger, synkronisering og sikkerhetskopier. Enhetskontroller: Metoder som hindrer uautorisert bruk av enheten og gjør det mulig å fjernslette den hvis den er blitt borte eller stjålet. Kontroller for personvern: Funksjoner i ios som kan brukes til å kontrollere tilgangen til Stedstjenester og brukerdata. 4

5 Systemsikkerhet Gå i DFU-modus (DFU = Device Firmware Upgrade) Når en enhet gjenopprettes etter at den har gått i DFU-modus, settes den tilbake i en kjent god tilstand der det er sikkert at det kun finnes uendret Apple-signert kode. En enhet kan settes i DFU-modus manuelt: Koble først enheten til en datamaskin ved hjelp av en USB-kabel, og hold deretter nede både Hjem- og Dvale/vekke-knappen. Etter 8 sekunder slipper du opp Dvale/vekke-knappen samtidig som du fortsatt holder nede Hjem-knappen. Merk: Ingenting vises på skjermen når enheten er i DFU-modus. Hvis Apple-logoen vises, har du holdt nede Dvale/vekke-knappen for lenge. Systemsikkerheten er bygd opp slik at både programvare og maskinvare sikres i alle kjernekomponenter i alle ios-enheter. Dette gjelder også oppstartsprosessen, programvareoppdateringer og Secure Enclave. Denne arkitekturen er vesentlig for sikkerheten i ios, og den står aldri i veien for enhetens brukervennlighet. Den tette integreringen av maskinvaren og programvaren på ios-enhetene sørger for at alle komponentene i systemet er godkjente og validerer systemet som helhet. Alle trinn blir analysert og godkjent for å sikre at maskinvaren og programvaren sammen gir optimal ytelse og riktig ressursbruk fra den første gangen enheten startes til programvareoppdateringer for ios og tredjepartsapper. Sikker oppstartssekvens De enkelte trinnene i oppstartsprosessen inneholder komponenter som Apple har signert kryptografisk for å sikre integriteten, og som bare fortsetter etter at godkjenningskjeden er bekreftet. Dette gjelder blant annet bootloaders, kjernen, kjernetillegg og baseband-firmwaren. Når en ios-enhet slås på, kjører prosessoren umiddelbart kode fra oppstarts-romen, som er skrivebeskyttet hukommelse. Denne koden kan ikke endres og kalles for maskinvarens «root of trust». Den implementeres når chipen produseres, og godkjenning er underforstått. Oppstarts-ROM-koden inneholder den offentlige Apple Root CA-nøkkelen, som brukes til å bekrefte at LLB-en (LLB = Low-Level Bootloader) er signert av Apple før innlasting. Dette er første trinn i godkjenningskjeden der hvert trinn sørger for at det neste er signert av Apple. Når LLB-en avslutter oppgaven, bekrefter den og kjører neste trinns bootloader, iboot, som bekrefter og kjører ios-kjernen. Den sikre oppstartssekvensen sørger for at programvare på laveste nivå ikke blir manipulert og at ios kun kjører på validerte Apple-enheter. For enheter med tilgang til mobilnettverk tar baseband-undersystemet også i bruk en egen lignende prosess for sikker oppstart med signert programvare og nøkler som er bekreftet av baseband-prosessoren. For enheter med A7-prosessor eller en nyere prosessor i A-serien tar Secure Enclavekoprosessoren også i bruk en sikker oppstartsprosess som sørger for at koprosessorens egen programvare er bekreftet og signert av Apple. Hvis ett trinn i oppstartsprosessen ikke kan laste eller bekrefte den neste prosessen, avsluttes oppstarten. Det vises et skjermbilde der brukeren bes om å koble til itunes. Dette kalles gjenopprettingsmodus. Hvis oppstarts-rom ikke kan laste eller bekrefte LLB, går den i DFU-modus (DFU = Device Firmware Upgrade). I begge tilfeller må enheten kobles til itunes via USB og gjenopprettes til standardinnstillinger. Du finner mer informasjon om hvordan enheten settes i gjenopprettingsmodus manuelt på support.apple.com/kb/ht1808?viewlocale=no_no. 5

6 Godkjenning av systemprogramvare Med jevne mellomrom lanserer Apple programvareoppdateringer som retter opp sikkerhetsproblemer som har oppstått, og som også inneholder nye funksjoner. Disse programvareoppdateringene leveres samtidig til alle støttede enheter. Brukerne får varslinger om ios-oppdateringer på enheten og via itunes, og oppdateringene leveres trådløst. Det gjør at de nyeste sikkerhetsoppdateringene tas raskt i bruk. Oppstartsprosessen som er beskrevet ovenfor, bidrar til å sikre at det kun er Applesignert kode som kan installeres på en enhet. For å hindre at enheter nedgraderes til eldre versjoner som ikke har de nyeste sikkerhetsoppdateringene, bruker ios en prosess som kalles Godkjenning av systemprogramvare. Hvis det var mulig å nedgradere, kunne dette blitt utnyttet av uvedkommende som får tak i telefonen. De kunne da installert en eldre versjon av ios og utnyttet en sårbarhet som er rettet opp i den nyere versjonen. På en enhet med A7-prosessor eller nyere prosessor i A-serien tar Secure Enclavekoprosessoren også i bruk Godkjenning av systemprogramvare til å sikre integriteten til programvaren og hindre at det installeres nedgraderinger. Se «Secure Enclave» nedenfor. ios-programvareoppdateringer kan installeres på enheten enten via itunes eller trådløst (OTA). Hvis du bruker itunes, blir det lastet ned og installert en komplett iosinstallasjon. Trådløse programvareoppdateringer laster kun ned komponentene som kreves for å fullføre en oppdatering, noe som gir bedre nettverkseffektivitet enn å laste ned hele operativsystemet. I tillegg kan programvareoppdateringer bufres på en lokal nettverkstjener som kjører bufringstjenesten på OS X Server. Dermed trenger ikke ios-enheten tilgang til Apple-tjenere for å få tilgang til de nødvendige dataene i oppdateringen. Ved en ios-oppgradering kobler itunes (eller enheten, som ved OTAprogramvareoppdateringer) til Apples tjener for godkjenning av installeringen og sender den en liste med kryptografiske mål for hver del av pakken som skal installeres (for eksempel LLB, iboot, kjernen og OS-filen), en tilfeldig anti-repetisjonsverdi («nonce») og enhetens unike ID (ECID). Godkjenningstjeneren kontrollerer listen med målinger mot versjoner hvor det tillates installering. Hvis den finner samsvarende treff, legger den ECID til målingene og signerer resultatet. Tjeneren sender et komplett sett med signerte data til enheten som en del av oppgraderingsprosessen. Når ECID blir lagt til, tilpasses godkjenningen den aktuelle enheten. Når det bare er kjente målinger som godkjennes og signeres, sikrer tjeneren at oppdateringen skjer akkurat slik den ble levert av Apple. Sikkerhetskjeden sørger for at signaturen kommer fra Apple, og at målingen fra filene som kom fra disken, kombinert med enhetens ECID, samsvarer med det som ble omfattet av signaturen. Disse trinnene begrenser godkjenningen til én bestemt enhet, og gjør at en gammel ios-versjon fra én enhet ikke kan kopieres til en annen. «Nonce»-verdien hindrer uvedkommende i å lagre tjenerens svar og bruke det til å manipulere en enhet eller endre system-programvaren på andre måter. 6

7 Secure Enclave Secure Enclave er en koprosessor som er bygd inn i Apples A7-prosessor og senere prosessorer i A-serien. Den bruker en egen sikker oppstart og tilpasset programvareoppdatering som er adskilt fra programprosessoren. Den står for alle krypteringsoperasjonene for nøkkeladministrering for databeskyttelse og ivaretar integriteten til databeskyttelsen selv om kjernen er blitt kompromittert. Secure Enclave bruker kryptert hukommelse og har en maskinvarebasert generator for tilfeldige tall. Den har en mikrokjerne som bygger på L4-familien, med endringer av Apple. Kommunikasjon mellom Secure Enclave og programprosessoren er isolert til en interrupt-drevet postkasse og databuffere for delt hukommelse. En Secure Enclave klargjøres med en egen UID (Unique ID) under produksjonen som andre deler av systemet ikke får tilgang til og som Apple ikke kjenner. Når enheten starter, lages det en kortvarig nøkkel, som er integrert i UID-en og brukes til å kryptere den delen av enhetens hukommelse som tilhører Secure Enclave. Data som Secure Enclave arkiverer i filsystemet, krypteres dessuten med en nøkkel som er integrert i UID-en og en anti-repetisjonsteller. Secure Enclave er ansvarlig for å behandle fingeravtrykkdata fra Touch ID-sensoren. Den avgjør om det finnes et treff i de registrerte fingeravtrykkene og gir deretter tilgang eller tillater kjøp på vegne av brukeren. Kommunikasjonen mellom prosessoren og Touch ID-sensoren foregår via en buss for serielt eksternt grensesnitt. Prosessoren videresender dataene til Secure Enclave, men kan ikke lese dem. De krypteres og godkjennes med en øktnøkkel som dannes ved hjelp av enhetens delte nøkkel som klargjøres for Touch ID-sensoren og Secure Enclave. Utvekslingen av øktnøkler bruker AES-nøkkelinnpakning der begge sider oppgir en tilfeldig nøkkel som danner øktnøkkelen og bruker AES-CCM-transportkryptering. Touch ID Touch ID er fingeravtrykksystemet som gir sikker tilgang til enheten på en raskere og enklere måte. Denne teknologien kan lese fingeravtrykksdata fra alle vinkler, og den lærer mer om brukerens fingeravtrykk over tid. Sensoren fortsetter å utvide kartet over fingeravtrykk etter hvert som det registreres flere overlappende noder hver gang den brukes. Touch ID gjør det enklere å bruke lange, komplekse koder, for brukeren trenger ikke å angi dem like ofte. Touch ID løser også den upraktiske siden ved bruk av kodelås. Funksjonen erstatter ikke kodelåsen, men gir sikker tilgang til enheten på en rask og god måte. Touch ID og koder For å kunne bruke Touch ID må brukerne konfigurere enheten slik at det kreves en kode for å låse den opp. Når Touch ID skanner og gjenkjenner et registrert fingeravtrykk, låses enheten opp uten å be om koden for enheten. Koden kan alltid brukes i stedet for Touch ID og kreves fortsatt under gitte forutsetninger: Enheten har nettopp blitt slått på eller startet på nytt. Enheten har ikke vært låst opp på over 48 timer. Enheten har mottatt en fjernlåsingskommando. Etter at det er gjort fem mislykkede forsøk med fingeravtrykk. Når enheten konfigureres, eller når nye fingre registreres for Touch ID. 7

8 Når Touch ID er aktivert, låses enheten umiddelbart når det trykkes på Dvale/vekkeknappen. Brukere som kun bruker kode, angir ofte utvidet tid før enheten låses, slik at de slipper å angi koden hver gang de bruker enheten. Med Touch ID låses enheten hver gang den går i dvale og krever et fingeravtrykk eller en kode for å vekkes. Touch ID kan læres opp til å gjenkjenne inntil fem ulike fingre. Hvis én finger er registrert, er sjansen for at den tilfeldigvis skal være lik en annen 1: Touch ID tillater imidlertid kun fem mislykkede forsøk på å få enheten til å gjenkjenne fingeravtrykk før brukeren må skrive inn en kode for å få tilgang. Andre bruksområder for Touch ID Touch ID kan også konfigureres til å godkjenne kjøp fra itunes Store, App Store og ibooks Store, slik at brukerne slipper å oppgi passordet for Apple-ID. Når de velger å godkjenne et kjøp, utveksles godkjenningskjennetegn mellom enheten og butikken. Kjennetegnet og den kryptografiske «nonce»-verdien (tilfeldig engangskode) oppbevares i Secure Enclave. «Nonce»-verdien signeres med en Secure Enclave-nøkkel som deles av alle enhetene og itunes Store. Touch ID kan også brukes med Apple Pay, Apples løsning for sikker betaling. Du finner mer informasjon i kapitlet Apple Pay i dette dokumentet. Dessuten kan tredjepartsapper bruke API-er levert av systemet til å be brukeren om å godkjenne ved hjelp av Touch ID eller ved å oppgi koden. Appen får kun beskjed om godkjenningen lyktes eller ikke. Den får ikke tilgang til Touch ID eller dataene som er tilknyttet det registrerte fingeravtrykket. Nøkkelringobjektene kan også beskyttes med Touch ID. Da kreves det et gjenkjent fingeravtrykk eller at koden på enheten oppgis for at de skal bli frigitt av Secured Enclave. App-utviklere har også API-er som kan bekrefte at en kode er blitt angitt av brukeren og kan derfor godkjenne eller låse opp nøkkelringobjekter ved hjelp av Touch ID. Med ios 9 kan utviklerne kreve at API-operasjoner for Touch ID ikke faller tilbake til et programpassord eller koden på enheten. Sammen med muligheten til å kunne hente en oversikt over statusen til registrerte fingre, gjør dette det mulig å bruke Touch ID som en faktor nummer to i sikkerhetssensitive apper. Touch ID-sikkerhet Fingeravtrykksensoren er kun aktiv når den berøringsfølsomme stålringen som ligger rundt Hjem-knappen, oppfatter berøring fra en finger. Det setter i gang det avanserte bildesystemet som skanner fingeren og sender bildet til Secure Enclave. Rasterbildet lagres midlertidig i kryptert hukommelse i Secure Enclave mens det vektoriseres for å bli analysert,. Deretter kastes det. Analysen bruker en prosess der mønsterlinjer i underhuden tegnes opp. I denne prosessen går ørsmå biter med informasjon tapt, informasjon som hadde vært nødvendig om brukerens fingeravtrykk skulle rekonstrueres. Resultatet er et nodekart som lagres uten identitetsinformasjon i et kryptert format som kun kan leses av Secure Enclave. Det sendes aldri til Apple og sikkerhetskopieres ikke til icloud eller itunes. 8

9 Hvordan Touch ID låser opp en ios-enhet Hvis Touch ID er slått av, kastes nøklene for databeskyttelsesklassen Fullført, som oppbevares i Secure Enclave, når en enhet låses. Filene og nøkkelringobjektene i denne klassen er ikke tilgjengelige før brukeren låser opp enheten ved å oppgi koden. Hvis Touch ID er slått på, kastes ikke nøklene når enheten låses. De blir i stedet pakket med en nøkkel som gis til Touch ID-undersystemet i Secure Enclave. Når en bruker forsøker å låse opp enheten og Touch ID gjenkjenner brukerens fingeravtrykk, oppgir den nøkkelen for å pakke ut databeskyttelsesnøklene, og enheten låses opp. Denne prosessen sørger for ytterligere beskyttelse ved å kreve at undersystemene for databeskyttelse og Touch ID samarbeider for at enheten skal låses opp. Nøklene som er nødvendige for at Touch ID skal låse opp enheten, går tapt hvis enheten starter på nytt, og kastes av Secure Enclave etter 48 timer eller fem mislykkede forsøk med Touch ID. 9

10 Kryptering og databeskyttelse Den sikre oppstartssekvensen, kodesignering og sikkerhetsprosesser ved kjøring bidrar alle til å sikre at kun godkjent kode og godkjente apper kan kjøres på en enhet. ios har ytterligere krypterings- og databeskyttelsesfunksjoner for å verne brukerdata, til og med i tilfeller der andre deler av sikkerhetsinfrastrukturen er kompromittert (for eksempel hvis det er gjort uautoriserte endringer på en enhet). Dette gir både brukere og IT-administratorer viktige fordeler med beskyttelse av personlig informasjon og bedriftsinformasjon til enhver tid og metoder for umiddelbar og fullstendig fjernsletting hvis enheten blir borte eller stjålet. Maskinvarens sikkerhetsfunksjoner På mobile enheter er hastighet og strømeffektivitet avgjørende. Krypteringsoperasjoner er komplekse og kan føre til problemer med ytelse og batteritid hvis dette ikke tas hensyn til når operasjonen utformes og implementeres. Alle ios-enheter har en egen AES 256-krypteringsmotor bygd inn i DMA-banen mellom flashlagringsplassen og systemets hovedhukommelse. Det gir svært effektiv filkryptering. Enhetens unike ID (UID) og enhetens gruppe-id (GID) er unike AES 256-bits nøkler som brennes (UID) eller kompileres (GID) inn i programprosessoren og Secure Enclave under produksjon. Ingen programvare eller firmware kan lese dem direkte. De kan bare se resultatet av krypterings- eller dekrypteringsoperasjonene som utføres av egne AES-motorer som er implementert i silisium og bruker UID-en eller GID-en som nøkkel. Dessuten kan UID-en og GID-en til Secure Enclave kun brukes av AES-motoren som er dedikert til Secure Enclave. UID-ene er unike for hver enhet og registreres ikke av Apple eller noen av deres leverandører. GID-ene er felles for alle prosessorene i en enhetsklasse (for eksempel alle enhetene som bruker Apple A8-prosessoren), og de brukes til oppgaver som ikke er sikkerhetskritiske, som ved levering av systemprogramvare under installering og gjenoppretting. Ved å integrere disse nøklene i silisiumet er de bedre beskyttet mot at noen manipulerer eller omgår dem eller får tak i dem utenfor AES-motoren. UID-ene og GID-ene er heller ikke tilgjengelige via JTAG eller andre feilsøkingsgrensesnitt. Slette alt innhold og alle innstillinger Valget «Slett alt innhold og alle innstillinger» under Innstillinger tilintetgjør alle nøklene i Effaceable Storage og gjør alle brukerdata på enheten kryptografisk utilgjengelige. Derfor er det en ideell måte å sikre at all personlig informasjon fjernes fra en enhet på før den gis til andre eller sendes til service. Viktig: Ikke bruk «Slett alt innhold og alle innstillinger» før det er tatt sikkerhetskopi av enheten for det finnes ingen måte å gjenopprette de slettede dataene på. UID-en gjør at data kan knyttes kryptografisk til en bestemt enhet. Nøkkelhierarkiet som beskytter filsystemet, inneholder for eksempel UID-en, slik at hvis hukommelseschipene flyttes fysisk fra én enhet til en annen, blir filene utilgjengelige. UID-en er ikke knyttet til annen identifikasjon på enheten. Med unntak av UID og GID opprettes alle andre krypteringsnøkler av en generator i systemet som genererer tilfeldige tall (RNG) ved hjelp av en algoritme som er basert på CTR_DRBG. Systementropien genereres fra tidsvariasjoner under oppstart, i tillegg til fra tidsavbrudd når enheten har startet opp. Nøkler som er generert i Secure Enclave, bruker en ekte maskinvarebasert generator for tilfeldige tall basert på flere ringoscillatorer som etterbehandles med CTR_DRBG. Det er like viktig å kunne slette nøkler på en sikker måte som det er å lage dem. Dette er særlig utfordrende på flashlagringsplassen der slitasjeutjevning kan bety at flere kopier av data må slettes. Derfor har ios-enheter en egen funksjon for sikker sletting av data. Funksjonen kalles Effaceable Storage. Funksjonen bruker den underliggende lagringsteknologien (for eksempel NAND) til direkte håndtering og sletting av et lite antall blokker som ligger på et svært lavt nivå. 10

11 Beskyttelse av fildata I tillegg til de innebygde funksjonene for maskinvarekryptering i ios-enheter bruker Apple en teknologi som kalles databeskyttelse til å beskytte data i flashhukommelsen ytterligere. Med databeskyttelse kan enheten svare på vanlige aktiviteter som for eksempel innkommende telefonsamtaler, men teknologien gjør det også mulig med høynivå-kryptering av brukerdata. Viktige systemapper, for eksempel Meldinger, Mail, Kalender, Kontakter, Bilder og Helse-informasjon, bruker databeskyttelse som standard, og tredjepartsapper som er installert på ios 7 eller nyere, får denne beskyttelsen automatisk. Databeskyttelse implementeres ved å lage og administrere et hierarki av nøkler og er basert på maskinvarekrypteringen som er innebygd i alle ios-enheter Databeskyttelse styres ved at hver enkelt fil tilordnes til en klasse, og tilgjengeligheten bestemmes av om klassenøklene er låst opp. Oversikt over arkitekturen Hver gang det opprettes en fil på datapartisjonen, lager databeskyttelsen en ny 256-bits nøkkel (den «filspesifikke» nøkkelen) og gir den til den maskinvarebaserte AES-motoren, som bruker nøkkelen til å kryptere filen når den skrives til flashhukommelsen i AES CBC-modus. (På enheter med A8-prosessor brukes AES-XTS.) Initialiseringsvektoren (IV) beregnes med blokken innarbeidet i filen og kryptert med SHA-1-hashen til den filspesifikke nøkkelen. Den filspesifikke nøkkelen pakkes med én av flere klassenøkler, avhengig av under hvilke omstendigheter det skal være mulig å få tilgang til filen. I likhet med alle andre innpakninger utføres denne ved hjelp av NIST AES-nøkkelinnpakning, i henhold til RFC Den innpakkede filspesifikke nøkkelen oppbevares i filens metadata. Når en fil åpnes, dekrypteres metadataene med filsystemnøkkelen, og den innpakkede filspesifikke nøkkelen og en notasjon om hvilken beskyttelsesklasse den tilhører, avdekkes. Den filspesifikke nøkkelen pakkes ut med klassenøkkelen og gis til den maskinvarebaserte AES-motoren som dekrypterer filen når den leses fra flashhukommelsen. All håndtering av innpakkede filnøkler skjer i Secure Enclave. Filnøkkelen legges aldri åpen for programprosessoren. Ved oppstart blir Secure Enclave enig med AES-motoren om en kortvarig nøkkel. Når Secure Enclave pakker ut nøklene til en fil, pakkes nøklene på nytt med den kortvarige nøkkelen og sendes tilbake til programprosessoren. Metadataene i alle filene i filsystemet er kryptert med en tilfeldig nøkkel som opprettes når ios installeres første gang, eller når enheten slettes av en bruker. Filsystemnøkkelen lagres i Effaceable Storage. Ettersom nøkkelen oppbevares på enheten, brukes den ikke til å holde dataene konfidensielle. Den er i stedet utformet for å kunne slettes raskt ved behov (av brukeren med innstillingen «Slett alt innhold og alle innstillinger» eller av en bruker eller administrator med en kommando for fjernsletting fra en MDM-tjener (Mobile Device Management), Exchange ActiveSync eller icloud). Når nøkkelen slettes slik, blir alle filer kryptografisk utilgjengelige. Maskinvarenøkkel Filsystemnøkkel Kodenøkkel Klassenøkkel Filmetadata Filnøkkel Filinnhold 11

12 Innholdet i en fil krypteres med en filspesifikk nøkkel, som pakkes med en klassenøkkel og lagres i filens metadata, som så krypteres med filsystemnøkkelen. Klassenøkkelen beskyttes av maskinvarens UID, og noen klasser beskyttes også av brukerens kode. Dette hierarkiet gir både fleksibilitet og ytelse. Det er for eksempel kun nødvendig å pakke den filspesifikke nøkkelen på nytt for å endre klassen til en fil, og ved kodeendringer er det kun klassenøkkelen som pakkes på nytt. Viktig om koder Hvis et langt passord som inneholder kun tall oppgis, vises et numerisk tastatur på låst skjerm i stedet for hele tastaturet. Det kan være enklere å oppgi en lengre numerisk kode enn en kortere alfanumerisk kode, og det gir den samme sikkerheten. Forsinkelser mellom kodeforsøk Forsøk Iverksatt forsinkelse 1-4 ingen 5 1 minutt 6 5 minutter minutter 9 1 time Koder Når brukeren angir en kode for enheten, aktiveres databeskyttelsen automatisk. ios støtter alfanumeriske koder på seks sifre, fire sifre og vilkårlig lengde. Koden låser opp enheten og sørger i tillegg for entropi for visse krypteringsnøkler. Det betyr at uvedkommende ikke kan få tilgang til dataene i spesifikke beskyttelsesklasser uten koden. Koden er integrert i enhetens UID, slik at brute-force-forsøk må skje på enheten som er under angrep. Et høyt iterasjonstall brukes til å gjøre hvert forsøk på å tippe passordet tregere. Iterasjonstallet er kalibrert slik at ett forsøk tar om lag 80 millisekunder. Det betyr at det vil ta over 5½ år å prøve alle kombinasjoner av alfanumeriske koder på seks tegn med små bokstaver og tall. Jo sterkere koden er, jo sterkere blir krypteringsnøkkelen. Touch ID kan benyttes til å forbedre denne ligningen ved at den gjør brukeren i stand til å opprette en mye sterkere kode enn det som ellers hadde vært praktisk å bruke. Dette øker den effektive mengden entropi som beskytter krypteringsnøklene som brukes til databeskyttelse, uten at det går utover brukeropplevelsen når ios-enheten skal låses opp mange ganger i løpet av dagen. For å gjøre brute-force-angrep for å tippe koden enda mindre fristende, er det en funksjon som øker tidsforsinkelsen hver gang det angis en ugyldig kode på låst skjerm. Hvis Innstillinger > Touch ID og kode > Slett data er slått på, slettes innholdet på enheten automatisk etter at det er gjort ti mislykkede forsøk etter hverandre på å oppgi koden. Denne innstillingen er også tilgjengelig som administrative retningslinjer via MDM og Exchange ActiveSync, og det kan angis en lavere grense. På enheter som har en A7-prosessor eller en nyere prosessor i A-serien, er det Secure Enclave som håndhever forsinkelsene. Hvis enheten startes på nytt når en tidsforsinkelse er iverksatt, gjelder forsinkelsen fortsatt, og tidtakingen begynner på nytt for gjeldende periode. Databeskyttelsesklasser Når det opprettes en ny fil på en ios-enhet, tildeles den en klasse av appen som oppretter den. Hver klasse bruker ulike retningslinjer for å avgjøre når data er tilgjengelig. De grunnleggende klassene og retningslinjene er beskrevet nedenfor: Komplett beskyttelse (NSFileProtectionComplete): Klassenøkkelen er beskyttet av en nøkkel avledet fra brukerkoden og enhetens UID. Kort tid etter at enheten låses av brukeren (10 sekunder hvis innstillingen for Krev passord er Umiddelbart) kastes den dekrypterte klassenøkkelen. Da blir alle data i denne klassen utilgjengelige til brukeren oppgir koden på nytt eller låser opp enheten med Touch ID. 12

13 Beskyttet hvis de ikke er åpne (NSFileProtectionCompleteUnlessOpen): Det kan hende at noen filer må skrives mens enheten er låst. Et godt eksempel på dette er et e-postvedlegg som lastes ned i bakgrunnen. Dette er det mulig å få til ved hjelp av asymmetrisk elliptisk kurvekryptering (ECDH over Curve25519). Den vanlige filspesifikke nøkkelen er beskyttet av en nøkkel som er avledet med One-Pass Diffie-Hellman Key Agreement som beskrevet i NIST SP A. Den kortvarige offentlige nøkkelen for avtalen lagres sammen med den innpakkede filspesifikke nøkkelen. KDF er Concatenation Key Derivation Function (Approved Alternative 1) som beskrevet i i NIST SP A. AlgorithmID utelates. PartyUInfo og PartyVInfo er henholdsvis den kortvarige og den statiske offentlige nøkkelen. SHA-256 brukes som hashing-funksjonen. Med det samme filen lukkes, slettes den filspesifikke nøkkelen fra hukommelsen. For å åpne filen igjen lages den delte hemmeligheten på nytt ved hjelp av den private nøkkelen for klassen Beskyttet hvis de ikke er åpne og filens kortvarige offentlige nøkkel. Filens hash brukes til å pakke ut den filspesifikke nøkkelen, som så brukes til å dekryptere filen. Beskyttet til første brukergodkjenning (NSFileProtectionCompleteUntilFirstUserAuthentication): Denne klassen oppfører seg på samme måte som Komplett beskyttelse med unntak av at den dekrypterte klassenøkkelen ikke fjernes fra hukommelsen når enheten er låst. Beskyttelsen i denne klassen kan minne om volumkryptering for stasjonære enheter, og den beskytter data mot angrep som inkluderer omstart. Dette er standardklassen for alle appdata fra tredjeparter som ikke er tilordnet en annen databeskyttelsesklasse. Ingen beskyttelse (NSFileProtectionNone): Denne klassenøkkelen beskyttes kun med UID-en og oppbevares i Effaceable Storage. Fordi alle nøklene som kreves for å dekryptere filer i denne klassen lagres på enheten, er den eneste fordelen med krypteringen rask fjernsletting. Hvis en fil ikke har fått tilordnet en databeskyttelsesklasse, lagres den likevel i kryptert form. (Det samme gjelder alle data på en ios-enhet.) Beskyttelse av nøkkelringdata Mange apper må håndtere passord og andre korte, men sensitive data, som nøkler og påloggingsinformasjon. ios-nøkkelringen oppbevarer objektene på en sikker måte. Nøkkelringen implementeres som en SQLite-database som er lagret i filsystemet. Det er bare én database, og securityd-daemonen avgjør hvilke nøkkelringobjekter hver prosess eller app har tilgang til. API-er for nøkkelringtilgang sender spørringer til daemonen, som igjen spør om appens rettigheter når det gjelder «keychain-access-groups», «application-identifier» og «application-group». I stedet for å begrense tilgangen til én enkelt prosess gjør tilgangsgrupper det mulig for apper å dele nøkkelringobjekter. Nøkkelringobjekter kan bare deles av apper fra samme utvikler. Apper fra tredjeparter må derfor bruke tilgangsgrupper med et prefiks de har fått tildelt av ios-utviklerprogrammet via programgrupper. Prefikskravet og egenarten til programgruppen håndheves gjennom kodesignering, klargjøringsprofiler og ios-utviklerprogrammet. 13

14 Komponenter i et nøkkelringobjekt Sammen med tilgangsgruppen inneholder hvert nøkkelringobjekt administrative metadata (for eksempel tidsmerker for «opprettet» og «sist oppdatert»). Det inneholder også SHA-1-hasher for attributtene som brukes til å sende forespørsler for objektet (for eksempel kontoog tjenernavn) slik at oppslag er mulig uten at hvert enkelt objekt dekrypteres. Det inneholder også krypteringsdata, som inkluderer følgende: Versjonsnummer ACL-data (ACL = Access control list) Verdi som viser hvilken beskyttelsesklasse objektet er plassert i Objektspesifikk nøkkel pakket med nøkkelen for beskyttelsesklassen Ordliste for attributter som beskriver objektet (slik det sendes videre til SecItemAdd), kodet som en binær plist og kryptert med den objektspesifikke nøkkelen Krypteringen er AES 128 i GCM (Galois/ Counter Mode). Tilgangsgruppen er tatt med i attributtene og beskyttes av GMAC-etiketten som beregnes under krypteringen. Nøkkelringdata beskyttes med en klassestruktur tilsvarende den som brukes til beskyttelse av fildata. Disse klassene fungerer på tilsvarende måte som klassene for beskyttelse av fildata, men de bruker egne nøkler og inngår i API-er som har andre navn. Tilgjengelighet Beskyttelse av fildata Beskyttelse av nøkkelringdata Når ulåst NSFileProtectionComplete ksecattraccessiblewhenunlocked Når låst NSFileProtectionCompleteUnlessOpen N/A Første gang enheten låses opp NSFileProtectionCompleteUntilFirstUserAuthentication ksecattraccessibleafterfirstunlock Alltid NSFileProtectionNone ksecattraccessiblealways Kode aktivert N/A ksecattraccessible- WhenPasscodeSetThisDeviceOnly Apper som benytter seg av tjenester for oppdatering i bakgrunnen, kan bruke ksecattraccessibleafterfirstunlock for nøkkelringobjekter som de trenger tilgang til under bakgrunnsoppdateringer. Klassen ksecattraccessiblewhenpasscodesetthisdeviceonly oppfører seg på samme måte som ksecattraccessiblewhenunlocked, men den er kun tilgjengelig når enheten er konfigurert med at kode må oppgis. Denne klassen finnes kun i systemnøkkeletuiet. Den synkroniseres ikke med icloud-nøkkelringen, blir ikke sikkerhetskopiert og tas ikke med i deponeringsnøkkeletuier. Hvis koden fjernes eller tilbakestilles, gjøres objektene ubrukelige ved at klassenøklene kastes. Andre nøkkelringklasser har en «bare denne enheten»-motpart som alltid er beskyttet av UID-en ved kopiering fra enheten under en sikkerhetskopiering. Den er derfor ubrukelig hvis den gjenopprettes på en annen enhet. Apple har sørget for en nøye gjennomtenkt balanse mellom sikkerhet og brukervennlighet ved å velge nøkkelringklasser som avhenger av hvilken type informasjon som sikres og når ios har bruk for den. Et VPN-sertifikat må for eksempel alltid være tilgjengelig slik at enheten har en kontinuerlig tilkobling. Det er imidlertid klassifisert som «ikke-migrerende» og kan derfor ikke flyttes til en annen enhet. Følgende klassebeskyttelse gjelder for nøkkelringobjekter som er opprettet av ios: Objekt Wi-Fi-passord E-postkontoer Exchange-kontoer VPN-passord LDAP, CalDAV, CardDAV Kjennetegn for kontoer på sosiale nettverk Krypteringsnøkler for Handoff-annonse icloud-kjennetegn Passord for Hjemmedeling Finn iphone-kjennetegn Talemeldinger itunes-sikkerhetskopi Safari-passord Bokmerker i Safari VPN-sertifikater Bluetooth -nøkler Tilgjengelig Første gang enheten låses opp Første gang enheten låses opp Første gang enheten låses opp Første gang enheten låses opp Første gang enheten låses opp Første gang enheten låses opp Første gang enheten låses opp Første gang enheten låses opp Når ulåst Alltid Alltid Når ulåst, ikke-migrerende Når ulåst Når ulåst Alltid, ikke-migrerende Alltid, ikke-migrerende 14

15 Kjennetegn for Apples pushvarslingstjeneste (APNs) Sertifikater og privat nøkkel for icloud imessage-nøkler Sertifikater og private nøkler installert av konfigurasjonsprofilen PIN-kode for SIM-kort Alltid, ikke-migrerende Alltid, ikke-migrerende Alltid, ikke-migrerende Alltid, ikke-migrerende Alltid, ikke-migrerende Tilgangskontroll for nøkkelring Nøkkelringer kan bruke tilgangskontrollister (ACL-er) til å angi retningslinjer for tilgang og godkjenningskrav. Objekter kan fastsette betingelser som krever brukerens tilstedeværelse ved å angi at det ikke er mulig å få tilgang til dem med mindre brukeren godkjennes ved hjelp av Touch ID eller ved å oppgi koden på enheten. ACL-er vurderes i Secure Enclave og frigis kun til kjernen hvis de spesifikke kravene som gjelder for dem, er oppfylt. Tilgang til passord som er arkivert i Safari ios-apper kan samhandle med nøkkelringobjekter som er arkivert av Safari, om autoutfylling av passord ved hjelp av disse to API-ene: SecRequestSharedWebCredential SecAddSharedWebCredential Det gis kun tilgang hvis det er godkjent av både apputvikleren og nettsidens administrator, og hvis brukeren har samtykket. Apputviklerne uttrykker at de har til hensikt å få tilgang til passord som er arkivert i Safari, ved å ta med en rettighet for dette i appen. Rettigheten inneholder en liste over de fullt kvalifiserte domenenavnene til tilknyttede nettsider. Nettsidene må plassere en fil på tjeneren som inneholder en liste over de unike app-id-ene til apper som de har godkjent. Når en app med rettigheten com.apple.developer.associated-domains blir installert, foretar ios en TLS-forespørsel til alle nettsidene som står på listen, og ber om fil/apple-app-side-tilknytningen. Hvis app-id-en til appen som installeres, står på listen i filen, gir ios nettsiden og appen et merke som viser at de har en godkjent relasjon. Kun når det er en godkjent relasjon vil spørringer til disse to API-ene resultere i en forespørsel til brukeren, som må samtykke før passord gis til appen eller oppdateres eller slettes. Nøkkeletuier Nøklene for databeskyttelsesklassen for både fil og nøkkelring samles inn og administreres i nøkkeletuier. ios bruker følgende fire nøkkeletuier: system, sikkerhetskopiering, deponering og icloud-sikkerhetskopiering. Systemnøkkeletuiet er der hvor de innpakkede klassenøklene som brukes i vanlig drift av enheten, er lagret. Når for eksempel en kode oppgis, lastes nøkkelen NSFileProtectionComplete inn fra systemnøkkeletuiet og pakkes ut. Det er en binær plist som er lagret i klassen Ingen beskyttelse, men innholdet i den er kryptert med en nøkkel som oppbevares i Effaceable Storage. For å gi såkalt «forward security» til nøkkeletuiene blir denne nøkkelen slettet og generert på nytt hver gang en bruker endrer koden. Kjernetillegget AppleKeyStore administrerer systemnøkkeletuiet og kan spørres om låsestatusen til en enhet. Den rapporterer at enheten kun låses opp hvis alle klassenøklene i systemnøkkeletuiet er tilgjengelige og utpakningen har vært vellykket. Nøkkeletuiet for sikkerhetskopiering blir opprettet når itunes tar en kryptert sikkerhetskopi og denne lagres på samme datamaskin som sikkerhetskopier av enheten. Det opprettes et nytt nøkkeletui med et nytt nøkkelsett, og de sikkerhetskopierte 15

16 dataene krypteres på nytt til disse nye nøklene. Som forklart tidligere blir nøkkelringobjekter som er ikke-migrerende, værende innpakket med den UID-avledede nøkkelen. Dermed kan de gjenopprettes til enheten som det opprinnelig ble tatt sikkerhetskopi av dem fra, men det er umulig å få tilgang til dem på en annen enhet. Nøkkeletuiet er beskyttet med passordet som er angitt i itunes, kjørt gjennom iterasjoner av PBKDF2. Til tross for det store antallet iterasjoner, er det ingen tilknytninger til en bestemt enhet, og et brute-force-angrep som skjer parallelt mot mange datamaskiner kan derfor teoretisk forsøkes utført på nøkkeletuiet for sikkerhetskopiering. Denne trusselen kan reduseres med et sterkt nok passord. Hvis en bruker velger ikke å kryptere en itunes-sikkerhetskopi, krypteres ikke sikkerhetskopifilene uansett hvilken databeskyttelsesklasse de har, men nøkkelringen er fortsatt beskyttet med en UID-avledet nøkkel. Dette er grunnen til at nøkkelringobjekter migrerer til en ny enhet kun hvis det er angitt et passord for sikkerhetskopiering. Deponeringsnøkkeletuiet brukes til itunes-synkronisering og MDM. Dette nøkkeletuiet gjør det mulig for itunes å sikkerhetskopiere og synkronisere uten å be brukeren om å oppgi koden, og det gjør det mulig for en MDM-tjener å fjernslette brukerens kode. Det lagres på datamaskinen som brukes til å synkronisere med itunes, eller på MDMtjeneren som administrerer enheten. Deponeringsnøkkeletuiet forbedrer brukeropplevelsen under enhetssynkronisering, som kan kreve tilgang til alle dataklasser. Når en enhet som er låst med kode kobles til itunes for første gang, bes brukeren om å oppgi koden. Enheten oppretter deretter et deponeringsnøkkeletui som inneholder nøklene i samme klasse som de som brukes på enheten, og beskyttet av en nøkkel som nettopp er blitt generert. Deponeringsnøkkeletuiet og nøkkelen som beskytter det, deles mellom enheten og verten eller tjeneren, og dataene lagres på enheten i klassen Beskyttet til første brukergjenkjenning. Dette er grunnen til at koden på enheten må oppgis før brukeren tar sikkerhetskopi ved hjelp ved av itunes for første gang etter en omstart. Hvis det er en OTA-programvareoppdatering, blir brukeren bedt om å oppgi koden ved igangsetting av oppdateringen. Dette brukes til å opprette et kjennetegn for engangsopplåsing på en sikker måte. Det låser opp systemnøkkeletuiet etter oppdateringen. Dette kjennetegnet kan ikke genereres uten at brukerens kode oppgis, og eventuelle kjennetegn som er generert tidligere, blir ugyldiggjort hvis brukeren endrer koden på enheten. Kjennetegn for engangsopplåsing er for installering av en programvareoppdatering som utføres enten i forgrunnen eller i bakgrunnen. De krypteres med en nøkkel som er avledet fra gjeldende verdi til en monoton teller i Secure Enclave, nøkkeletuiets UUID og UID-en til Secure Enclave. Hvis telleren for kjennetegnet for engangsopplåsing i SEP-en økes trinnvis, blir alle eksisterende kjennetegn ugyldige. Telleren økes trinnvis når et kjennetegn brukes, etter at en enhet som er startet på nytt, låses opp for første gang, når en programvareoppdatering blir avbrutt (av brukeren eller av systemet) eller når retningslinje-tidtakeren for et kjennetegn er utløpt. Kjennetegnet for engangsopplåsing for programvareoppdateringer i forgrunnen utløper etter 20 minutter. Dette kjennetegnet eksporteres fra Secure Enclave og skrives til Effaceable Storage. En retningslinje-tidtaker øker telleren trinnvis hvis enheten ikke har startet på nytt i løpet av 20 minutter. For programvareoppdateringer som utføres i bakgrunnen, som angis når brukeren velger «Installer senere» når han eller hun varsles om oppdateringen, kan programprosessoren holde liv i kjennetegnet for engangsopplåsing i Secure Enclave i inntil 8 timer. Deretter øker en retningslinje-tidtaker telleren trinnvis. 16

17 Nøkkeletuiet for icloud-sikkerhetskopiering ligner nøkkeletuiet for sikkerhetskopiering. Alle klassenøkler i dette nøkkeletuiet er asymmetriske (bruker Curve25519, i likhet med databeskyttelsesklassen Beskytt hvis de ikke er åpne), slik at icloudsikkerhetskopieringer kan utføres i bakgrunnen. De krypterte dataene leses fra enheten og sendes til icloud for alle databeskyttelsesklassene unntatt Ingen beskyttelse. De tilsvarende klassenøklene beskyttes av icloud-nøkler. Nøklene i nøkkelringklassen blir pakket med en UID-avledet nøkkel på samme måte som en ukryptert itunessikkerhetskopi. Et asymmetrisk nøkkeletui brukes også til sikkerhetskopien når det gjelder nøkkelringgjenoppretting for icloud-nøkkelringen. Sikkerhetssertifiseringer og -programmer Kryptografisk validering (FIPS 140-2) Det er blitt kontrollert at krypteringsmodulene i ios er i henhold til amerikanske Federal Information Processing Standards (FIPS) nivå 1 etter hver nylansering fra ios 6. ios 9 har de samme krypteringsmodulene som ios 8, men Apple sender alltid inn modulene i nylanseringer for at de skal bli kontrollert på nytt. Dette programmet validerer integriteten til krypteringsoperasjonene for Apple-apper og tredjepartsapper som har rett til å bruke krypteringstjenestene i ios. Sertifisering etter felles kriterier (ISO 15408) Apple har allerede begynt arbeidet for å få ios-sertifisering i henhold til CCC-programmet (Common Criteria Certification). De to første sertifiseringene som er aktive for øyeblikket, gjelder Mobile Device Fundamental Protection Profile v2.0 (MDFPP2) og VPN IPSecPP1.4 Client Protection Profile (VPNIPSecPP1.4). Apple har inntatt en aktiv rolle i ITC (International Technical Community) når det gjelder å utvikle PP-er (Protection Profiles) som for øyeblikket ikke er tilgjengelige, for å evaluere nøkkelteknologi for mobilsikkerhet. Apple fortsetter med å vurdere og arbeide for å få sertifiseringer i henhold til nye og oppdaterte versjoner av PP-ene som er tilgjengelige i dag. Commercial Solutions for Classified (CSfC) Der hvor det er aktuelt har Apple også sendt inn ios-plattformen og ulike tjenester for at de skal bli ført opp på listen Commercial Solutions for Classified (CSfC) Program Components List. Helt spesifikt gjelder dette ios for mobilplattform og IKEv2-klienten for IPSec VPN-klienten (kun IKEv2 Always-On VPN). Etter hvert som Apples plattformer og tjenester gis sertifisering i henhold til Common Criteria Certifications, vil de også bli sendt inn for å bli tatt med på listen CSfC Program Component List. Håndbøker for sikkerhetskonfigurasjon Apple har samarbeidet med myndigheter over hele verden med tanke på å lage håndbøker med instruksjoner og anbefalinger for hvordan et sikrere miljø kan opprettholdes, også kjent som «device hardening». Disse håndbøkene gir kortfattet og kvalitetssikret informasjon om hvordan funksjoner i ios skal konfigureres og brukes for å gi bedre beskyttelse. Du finner mer informasjon om sikkerhetssertifiseringer, valideringer og veiledning for ios på 17

18 Appsikkerhet Apper er noen av de mest kritiske elementene i en moderne arkitektur for mobilsikkerhet. Appene gir utrolige produktivitetsforbedringer for brukerne, men de kan også ha en negativ innvirkning på systemets sikkerhet, stabilitet og brukerdata hvis de ikke håndteres på riktig måte. Dette er grunnen til at ios inneholder flere lag med beskyttelse for å sikre at appene er signerte og bekreftet og at sandkasseteknologi benyttes for å beskytte brukerdata. Disse elementene gir en stabil og sikker plattform for apper og gjør det mulig for tusenvis av utviklere å lage hundretusenvis av apper på ios uten at det påvirker systemets integritet. Og brukerne kan få tilgang til disse appene på ios-enhetene uten å være redd for virus, skadelig programvare eller uautoriserte angrep. Appkodesignering Når ios-kjernen har startet, kontrollerer den hvilke brukerprosesser og apper som kan kjøres. ios krever at all kjørbar kode skal være signert med et sertifikat utstedt av Apple for å sikre at alle apper kommer fra en kjent og godkjent kilde og ikke er manipulert. Apper som følger med enheten, som Mail og Safari, er signert av Apple. Tredjepartsapper må også valideres og signeres med et sertifikat utstedt av Apple. Obligatorisk kodesignering utvider godkjenningskjedekonseptet fra OS til apper og hindrer at tredjepartsapper laster inn usignerte koderessurser eller bruker selvmodifiserende kode. For å kunne utvikle og installere apper på ios-enheter må utviklere registrere seg hos Apple og bli med i ios-utviklerprogrammet. Den ekte identiteten til hver utvikler, uansett om dette er en person eller en bedrift, kontrolleres av Apple før sertifikatet utstedes. Sertifikatet gjør at utviklere kan signere apper og sende dem til App Store for distribusjon. Følgelig er alle apper i App Store sendt inn av en identifiserbar person eller organisasjon, og det virker forebyggende mot skadelige apper. Appene blir også gjennomgått av Apple for å sikre at de fungerer som beskrevet, og at de ikke inneholder åpenbare feil eller andre problemer. I tillegg til teknologien vi allerede har nevnt, gir denne prosessen kundene tillit til kvaliteten på appene de kjøper. ios tillater at utviklerne bygger inn rammeverk i appene, som kan brukes av appen selv eller av tilleggene som er innebygd i appen. For å beskytte systemet og andre apper mot innlasting av tredjepartskode i adresseområdet, utfører systemet en validering av kodesignaturen til alle dynamiske bibliotek som en prosess oppretter koblinger til ved oppstart. Denne bekreftelsen gjennomføres ved hjelp av team-id-en som trekkes ut fra et sertifikat utstedt av Apple. En team-id er en alfanumerisk streng på 10 tegn, for eksempel 1A2B3C4D5F. Et program kan opprette en kobling til et hvilket som helst plattformbibliotek som leveres sammen med systemet, eller et hvilket som helst bibliotek med samme team-id i kodesignaturen som hovedprogramfilen. Fordi de kjørbare filene som leveres som en del av systemet, ikke har en team-id, kan de kun opprette en kobling til bibliotek som leveres med selve systemet. Rapport om ios-sikkerhet Oktober

19 Bedrifter har også muligheten til å skrive interne apper for bruk i organisasjonen og distribuere dem til de ansatte. Bedrifter og organisasjoner kan søke om opptak til Apple Developer Enterprise Program (ADEP) med et D-U-N-S-nummer. Apple godkjenner søkere etter å ha fått bekreftet identiteten deres og at de oppfyller kravene. Når en organisasjon blir medlem av ADEP, kan den registrere seg og få en klargjøringsprofil som tillater interne apper å kjøre på enheter som den godkjenner. Brukerne må ha klargjøringsprofilen installert for å kunne kjøre interne apper. Dette sikrer at kun brukere som organisasjonen vil skal bruke appen, kan laste den inn på iosenheten. Apper som er installert via MDM godkjennes underforstått fordi det allerede er etablert et forhold mellom organisasjonen og enheten. Hvis ikke må brukerne godkjenne appens klargjøringsprofil under Innstillinger. Organisasjoner kan hindre brukere i å godkjenne apper fra ukjente utviklere. Første gang en bedriftsapp startes, må enheten motta positiv bekreftelse fra Apple om at appen har tillatelse til å kjøre. Til forskjell fra andre mobilplattformer tillater ikke ios at brukerne installerer usignerte apper som kan være skadelige, fra nettsider, eller at de kjører kode som ikke er godkjent. Når appen kjøres, kontrolleres kodesignaturen til alle kjørbare hukommelsessider etter hvert som de lastes inn for å være sikker på at appen ikke er blitt endret etter at den ble installert eller siste gang den ble oppdatert. Sikkerhetsprosesser ved kjøring Når en app er bekreftet å være fra en godkjent kilde, setter ios i verk sikkerhetstiltak som er utarbeidet for å hindre at appen kompromitterer andre apper eller resten av systemet. Alle tredjepartsapper begrenses av sandkasseteknologi, slik at de ikke får tilgang til filer som er lagret av andre apper, og ikke lov til å gjøre endringer på enheten. Dette hindrer at apper samler eller gjør endringer i informasjon som er lagret av andre apper. Alle apper har en unik hjemmekatalog for filene sine, som tildeles tilfeldig når appen installeres. Hvis en tredjepartsapp trenger tilgang til informasjon som ikke tilhører den selv, får den det kun ved å bruke tjenester som uttrykkelig kommer fra ios. Systemfiler og -ressurser skjermes også mot brukerens apper. Mesteparten av ios kjører som brukeren «mobile» uten rettigheter, og det samme gjør alle tredjepartsapper. Hele ios-partisjonen aktiveres med skrivebeskyttelse. Unødvendige verktøy, for eksempel tjenester for fjernpålogging, tas ikke med i systemprogramvaren, og API-er tillater ikke at apper utvider sine egne rettigheter for å endre andre apper eller selve ios. Tilgangen som tredjepartsapper har til brukerinformasjon og funksjoner som icloud og tilleggsfunksjoner, kontrolleres ved hjelp av rettighetserklæringer. Rettigheter er nøkkelverdipar som er knyttet til en app, og som tillater godkjenning utover kjøretidsfaktorer som unix bruker-id. Siden rettigheter er signert digitalt, kan de ikke endres. Rettigheter brukes i stor grad av systemapper og daemoner for å utføre spesifikke privilegerte handlinger som ellers ville kreve at prosessen kjører som «root»-bruker. Det reduserer muligheten for at noen lurer til seg tilgang gjennom et kompromittert systemprogram eller en daemon. Dessuten kan apper kun utføre bakgrunnsbehandling gjennom API-er levert av systemet. Dette gjør det mulig for apper å fortsette å fungere uten dårligere ytelse og uten at batteritiden påvirkes i stor grad. 19

20 ASLR (Address space layout randomization) hindrer uvedkommende i å utnytte feil i hukommelsen. Innebygde apper bruker ASLR for å sikre at alle hukommelsesområder randomiseres ved oppstart. Tilfeldig plassering av hukommelsesadressene til kjørbar kode, systembiblioteker og relatert programmering reduserer faren for avanserte former for utnyttelse. Et «return-to-libc»-angrep forsøker for eksempel å lure en enhet til å kjøre skadelig kode ved å manipulere hukommelsesadressene til stabler og systembiblioteker. Tilfeldig plassering av disse gjør det vanskeligere å utføre angrepet, særlig på flere enheter. Xcode, utviklingsmiljøet til ios, kompilerer automatisk tredjepartsapper med ASLR-støtte slått på. Ytterligere beskyttelse kommer fra ios ved hjelp av ARMs XN-funksjon (Execute Never), som merker hukommelsessider som ikke-kjørbare. Hukommelsessider som er merket som både skrivbare og kjørbare, kan bare brukes av apper under nøye kontrollerte forhold: Kjernen kontrollerer at den finner den dynamiske kodesigneringsrettigheten som kun Apple har. Selv da er det kun mulig å foreta ett enkelt mmap-anrop for å be om en kjørbar og skrivbar side, som blir gitt en tilfeldig adresse. Safari bruker denne funksjonaliteten til JavaScript JIT-kompilatoren. Tillegg ios tillater at apper gir funksjonalitet til andre apper gjennom tillegg. Tillegg er signerte kjørbare programfiler for spesielle formål som er pakket sammen med appen. Systemet gjenkjenner automatisk tillegg ved installering og gjør dem tilgjengelige for andre apper ved hjelp av et gjenkjenningssystem. Et systemområde som støtter tillegg, kalles et tilleggspunkt. Hvert tilleggspunkt leverer API-er og håndhever retningslinjer for dette området. Systemet avgjør hvilke tillegg som er tilgjengelige, basert på spesifikke gjenkjenningsregler for tilleggspunktet. Systemet starter automatisk tilleggsprosesser etter behov og administrerer levetiden deres. Rettigheter kan brukes til å begrense tilgang til tillegg til bestemte systemprogrammer. En widget for I dag-visning vises for eksempel kun i Varslingssenter, og et delingstillegg er kun tilgjengelig i Deling-panelet. Tilleggspunktene er I dag-widgeter, Share, Custom actions, Photo Editing, Document Provider og Custom Keyboard. Tillegg kjører i sitt eget adresseområde. Kommunikasjon mellom tillegget og appen som den ble aktivert fra, skjer via kommunikasjon mellom prosesser med systemets rammeverk som mellomledd. De har ikke tilgang til hverandres filer eller hukommelsesområder. Tillegg er laget slik at de skal holdes atskilt fra hverandre, fra appen de tilhører og fra appene som bruker dem. Som alle andre tredjepartsapper begrenses de av sandkasseteknologi og har en beholder som er atskilt fra beholderen til appen de tilhører. De deler imidlertid samme tilgang til kontroller for personvern som beholderappen. Så hvis en bruker gir Kontakter tilgang til en app, videreføres denne tilgangen til tilleggene som er innebygd i appen, men ikke til tilleggene som aktiveres av appen. Tilpassede tastaturer er en spesiell type tillegg fordi de aktiveres av brukeren for hele systemet. Når tillegget er aktivert, brukes det til alle tekstfelt unntatt inntasting av kode og eventuell visning av sikker tekst. På grunn av personvernet er det standard at tilpassede tastaturer kjøres i en sandkasse med strenge begrensninger som blokkerer tilgang til nettverket, til tjenester som utfører nettverksoperasjoner på vegne av en prosess, og til API-er som ville latt tillegget eksfiltrere inntastede data. Utviklere av tilpassede tastaturer kan be om å få åpen tilgang for tillegget de lager. Da kan systemet kjøre tillegget i standardsandkassen etter å ha fått samtykke fra brukeren. 20