Nesten hver dag dukker det opp nyheter på nettet om nok et hackerangrep, eller om informasjonslekkasjer fra brukernes iCloud. De fleste av dem beskytter ganske enkelt ikke profilen sin tilstrekkelig, og er derfor utsatt for enkel hacking.
Så hvordan kan du pålitelig beskytte deg selv? La oss fortelle deg hvordan.
Angi et dynamisk passord
Dette er ikke en spesiell kombinasjon som endrer seg selv. Dette er passordet du kommer opp med. Det må bare skiftes med jevne mellomrom. Og helst uten å legge til ett tall eller bokstav om gangen.
Et godt passord bør være minst 8 tegn langt, inkludert store og små bokstaver, tall og ulike symboler. Et eksempel er hJil5 &% GAf.
Slå på tofaktorautentisering
Denne metoden regnes som den mest pålitelige på grunn av det faktum at den krever bekreftelse av oppføring fra en annen enhet enten via SMS eller push-melding.
Trinn 1... Gå til Innstillinger -> iCloud. Vi trykker på Apple ID.
Steg 2... Klikk på Passord og sikkerhet.
Trinn 3... Trykk på Aktiver tofaktorautentisering.
Bruke en passordbehandler
Å bruke komplekse passord er en tøff oppgave fordi du må ha dem alle i hodet. Safari har innebygd passordbehandling, noe som er godt nok hvis du bruker nettleseren på alle enhetene dine.
Imidlertid tilbyr frittstående programmer ekstra funksjonalitet. Vi kan anbefale 1Password. Hovedpassordet som kreves for å logge på appen, er ikke lagret i iOS-nøkkelringen. Brute-force-beskyttelse er garantert av SHA512 og PBKDF2, og hver oppføring i databasen din er kryptert med en 256-bits nøkkel (AES).
Som lar deg lagre kontoinformasjon og kredittkortnumre.
I kontakt med
Som et resultat kan alle data synkroniseres med pålitelige enheter. Mac, iPhone, iPad og iPod Touch som er koblet sammen med en.
Denne utviklingen av hendelser beviser nok en gang avhengigheten eple fra iCloud, og øker ansvaret til administratorene av selskapets skytjeneste, som er forpliktet til å ivareta sikkerheten til brukernes personopplysninger.
eple publisert et spesielt materiale om implementering av sikkerheten og personvernet til brukere i tjenesten iCloud... Med en utgang OS X Mavericks reglene er litt oppdatert.
Vurder å jobbe i iCloud i detaljer. Hvis brukeren logger på kontoen sin på siden iCloud.com gjennom en nettleser, er alle øktene beskyttet av et SSL-sertifikat, inkludert trafikk som sirkulerer mellom enheter og tjenester iCloud... Eventuelle data i webapplikasjoner iCloud, som er tilgjengelig via nettgrensesnittet eller andre grunnleggende applikasjoner iOS / OS X er kryptert på serveren. De eneste unntakene er IMAP-postservere. For å kryptere data som er lagret på IMAP-servere, bør du bruke ekstra S/MIME-kryptering, som støttes av alle e-postklienter eple.
V eple oppgi også at tilgang til grunnleggende applikasjoner som Mail, Contacts og Calendar skjer via sikre tokens som ikke sørger for lagring av passord fra iCloud på dingser og datamaskiner.
"Selv om du bestemmer deg for å bruke tredjepartsapplikasjoner for å få tilgang til iCloud, blir brukernavnet og passordet ditt sendt via en kryptert SSL-tilkobling,» varslet fra eple.
Om funksjonene og Finn vennene mine i apple-selskapet forsikrer de at koordinatene til stedet registreres kun på forespørsel fra brukeren. Disse funksjonene bruker minst 128-bit AES-kryptering. De siste posisjonsdataene lagres på servere eple: for Finn vennene mine lagringstiden er 2 timer, og i 24 timer. Da slettes all informasjon.
For lagring av passord og kredittkortnumre på servere iCloud eple bruker 256-bit AES-kryptering og "asymmetrisk elliptisk kurvekryptografi og symmetriske nøkler" for å sikre sikkerheten til personopplysninger. Disse standard krypteringsmetodene brukes til både overføring og lagring av data i skyen.
Når det gjelder kredittkortnumre lagret med Nøkkelbunter så inn iCloud kun kortnummer og utløpsdatoer lagres, ikke sikkerhetskoder (cvv), som legges inn manuelt i nettskjemaer. I tillegg kommer data fra Nøkkelbunter er ikke en del av sikkerhetskopien i iCloud.
Hvis du vil unngå å sikkerhetskopiere dataene dine til Nøkkelring da bør du hoppe over trinnet med å generere sikkerhetskoden når du konfigurerer Nøkkelbunter... Dette vil sikre at dataene dine er fra Nøkkelbunter lagres lokalt og kun synkronisert med enhetene brukeren bruker. Det må huskes at i dette tilfellet (uten å bruke en sikkerhetskode) eple vil ikke kunne gjenopprette dataene dine fra Nøkkelbunter.
Selskapet understreker at de ikke får tilgang til krypteringsnøklene for Nøkkelbunter ettersom de opprettes lokalt på brukernes enheter.
Å bruke Nøkkelhaug på iPhone, iPod touch og iPad, bør alle enheter fungere på basen og på datamaskiner Mac skal installeres OS X Mavericks... Bruken av funksjonen avhenger av regionen der brukeren bor.
ICloud Music Library gjør det enkelt å flytte bilder og videoer mellom enheter. Dette betyr at mediene våre lagres et sted på serverne, og også hele tiden beveger seg online mellom oss og serverne. Men er disse dataene trygge?
Hvordan beskytter Apple bilder?
Alle data som overføres til iCloud-mediebiblioteket er beskyttet i farten med minst AES-kryptering med en nøkkellengde på minst 128 biter. Beskyttelse utføres både under overføring og lagring av data.
Krypteringsnøklene overføres ikke under noen omstendigheter til tredjeparter.
Denne setningen, hentet fra Apples offisielle supportside, understreker at du kan være trygg på dataene dine.
Ved overføring av data til servere eller ved nedlasting av data fra iCloud, brukes den ende-til-ende kryptering... Dette betyr at selv om noen fanger opp disse dataene (men hva hvis!), vil han ikke kunne se bildet eller videoen.
Apple bruker AES og SHA for sterk kryptering og hashing av data. Mange finansinstitusjoner bruker disse standardene.
I sitt sikkerhetsdokument skriver Apple:
Hver fil er delt og kryptert av iCloud ved hjelp av AES-128 og en nøkkel hentet fra innholdet i hver del ved hjelp av SHA-256. Nøklene og filmetadataene lagres av Apple på deres iCloud-konto. De krypterte delene av filen lagres uten brukeridentifiserende informasjon ved å bruke lagringstjenester som Amazon S3 og Windows Azure.
Slike forholdsregler er gode nok til å lagre bilder av millioner av brukere over hele verden.
Apple er følsomme for personvernspørsmål. Derfor, i systeminnstillingene, er en hel seksjon viet til det. Der kan du tillate/nekte tilgang til bildene dine for ulike applikasjoner.
Også, hvert program som trenger tilgang til bildet, ved første gangs bruk, sørg for å spørre brukeren om det. Dette er gjort for at Apple ikke skal ha spørsmål om hvordan dette eller det bildet havnet for eksempel på Instagram.
Hvor kommer private bilder av kjendiser fra iCloud fra med jevne mellomrom? Hvorfor vises artiklene «Enda en lekkasje i iCloud» av og til? Dessverre kan ingen mengde kryptering redde deg fra menneskelig dumhet. I 100 prosent av tilfellene vil såkalte hackere ganske enkelt brute-force iCloud-passordet. Men Apple har gjort alt for å sikre at dette aldri skjer.
c) Sørg for å angi et sterkt passord på iOS-enhetene og datamaskinene dine. Eksempel: Datamaskinen din faller i feil hender. Det er et enkelt passord. Og passordet fra datamaskinen åpner ikke bare tilgang til det, men også tilgang til nøkkelringen.
Å lagre passord sikkert og synkronisere dem på tvers av enheter er ikke en lett oppgave. For omtrent et år siden introduserte Apple verden for iCloud Keychain, dens sentraliserte passordbutikk for OS X og iOS. La oss prøve å finne ut hvor og hvordan brukerpassord lagres, hvilke potensielle risikoer det medfører, og om Apple teknisk sett er i stand til å få tilgang til dekrypterte data som er lagret på serverne deres. Selskapet hevder at slik tilgang er umulig, men for å bekrefte eller avkrefte dette er det nødvendig å forstå hvordan iCloud-nøkkelringen fungerer.
iCloud 101
Faktisk er iCloud ikke bare én tjeneste, det er et generisk markedsføringsnavn for Apples utvalg av skytjenester. Dette inkluderer synkronisering av innstillinger, dokumenter og bilder, og Finn min telefon for å finne tapte eller stjålne enheter, og iCloud Backup for sikkerhetskopiering til skyen, og nå er her iCloud nøkkelring for sikker synkronisering av passord og kredittkortnumre mellom enheter basert på iOS og OS X...
Hver iCloud-tjeneste er plassert på sitt eget tredjenivådomene, for eksempel pXX-keyvalueservice.icloud.com, der XX er nummeret til servergruppen som er ansvarlig for å behandle forespørsler fra gjeldende bruker; dette nummeret kan være forskjellig for forskjellige Apple-ID-er; nyere kontoer har vanligvis en høyere verdi for denne telleren.
ICloud sikkerhetskode
Før du dykker inn i iCloud nøkkelring-analyse, la oss ta en titt på hvordan denne tjenesten er konfigurert. Når iCloud-nøkkelring er slått på, blir brukeren bedt om å komme opp med og skrive inn en iCloud-sikkerhetskode (iCloud-sikkerhetskode, heretter - iCSC). Som standard lar inndataskjemaet deg bruke en firesifret numerisk kode, men ved å klikke på koblingen "Avanserte alternativer" kan du fortsatt bruke en mer kompleks kode eller til og med la enheten generere en sterk tilfeldig kode.
Vi vet nå at dataene i iCloud Keychain er beskyttet av iCSC. Vel, la oss prøve å finne ut nøyaktig hvordan denne beskyttelsen er implementert!
Trafikkavlytting eller man-in-the-midten
Det første trinnet i å analysere nettverkstjenester er ofte å få tilgang til nettverkstrafikken mellom klienten og serveren. Når det gjelder iCloud, er det to nyheter for oss: gode og dårlige. Det dårlige er at all (vel, eller i det minste det overveldende flertallet av den) trafikk er beskyttet av TLS / SSL, det vil si at den er kryptert og kan ikke "leses" av et vanlig passivt angrep. Den gode nyheten er at Apple ga alle som ønsker å utforske iCloud en gave og ikke bruker sertifikatfesting, noe som gjør det enkelt å organisere et mann-i-midten-angrep og dekryptere den avlyttede trafikken. For dette er det nok:
- Plasser den eksperimentelle iOS-enheten på det samme Wi-Fi-nettverket som den avskjærende datamaskinen.
- Installer en avskjærende proxy-server (som Burp, Charles Proxy eller lignende) på datamaskinen.
- Importer TLS / SSL-sertifikatet til den installerte proxy-serveren til iOS-enheten (detaljer i hjelpen til den spesifikke proxyen).
- I Wi-Fi-nettverksinnstillingene på iOS-enheten (Innstillinger → Wi-Fi → Nettverksnavn → HTTP-proxy), spesifiser IP-adressen til den avskjærende datamaskinen i Wi-Fi-nettverket og porten som proxy-serveren lytter til.
Hvis alt er gjort riktig, vil all trafikken mellom enheten og iCloud være på et øyeblikk. Og fra avskjæringen av denne trafikken vil det tydelig sees at iCloud-nøkkelringen er bygget på grunnlag av to iCloud-tjenester: com.apple.Dataclass.KeyValue og com.apple.Dataclass.KeychainSync - både ved førstegangs og gjentatt påkobling på andre iOS-enheter utveksler den data med disse tjenestene.
Den første tjenesten er ikke ny og var blant de første funksjonene til iCloud; det er mye brukt av programmer for å synkronisere innstillinger. Den andre er ny og åpenbart utviklet spesielt for iCloud nøkkelring (selv om funksjonaliteten teoretisk lar deg bruke den til andre formål). La oss se nærmere på disse tjenestene.
com.apple.Dataclass.KeyValue
Som nevnt ovenfor, er dette en av tjenestene som brukes av iCloud Keychain. Mange eksisterende applikasjoner bruker den til å synkronisere små mengder data (innstillinger, bokmerker og lignende). Hver oppføring lagret av denne tjenesten er knyttet til en pakke-ID og et butikknavn. Følgelig, for å motta de lagrede dataene fra tjenesten, er det også nødvendig å oppgi disse identifikatorene. Innenfor iCloud nøkkelring brukes denne tjenesten til å synkronisere nøkkelringposter i kryptert form. Denne prosessen er beskrevet i tilstrekkelig detalj i iOS-sikkerhetsdokumentet under Nøkkelringsynkronisering og Hvordan nøkkelringsynkronisering fungerer.
Synkronisering av nøkkelring
Når en bruker først slår på iCloud-nøkkelringen, oppretter enheten en sirkel av tillit og synkroniseringsidentitet (offentlige og private nøkler) for gjeldende enhet. Den offentlige nøkkelen til dette paret plasseres i en "tillitssirkel" og denne "sirkelen" signeres to ganger: først med enhetens private synkroniseringsnøkkel, og deretter med en asymmetrisk nøkkel (basert på elliptisk kryptografi) avledet fra brukerens iCloud-passord . Dessuten lagrer "sirkelen" parametere for å beregne nøkkelen fra passordet, for eksempel salt og antall iterasjoner.
Den signerte "sirkelen" lagres i nøkkel / verdi-lagring. Den kan ikke leses uten å kjenne brukerens iCloud-passord og kan ikke endres uten å kjenne den private nøkkelen til en av enhetene som er lagt til i sirkelen.
Når en bruker slår på iCloud-nøkkelring på en annen enhet, får den enheten tilgang til nøkkel-/verdilagringen i iCloud og legger merke til at brukeren allerede har en "tillitskrets" og at den nye enheten ikke er inkludert i den. Enheten genererer synkroniseringsnøkler og en kvittering for forespørsel om kretsmedlemskap. Kvitteringen inneholder enhetens offentlige synkroniseringsnøkkel og er signert med en nøkkel hentet fra brukerens iCloud-passord ved å bruke nøkkelgenereringsparametrene hentet fra nøkkel-/verdilageret. Den signerte kvitteringen legges deretter i Nøkkel / Verdi-lageret.
Den første enheten ser den nye kvitteringen og viser brukeren en melding om at den nye enheten ber om å bli lagt til i tillitskretsen. Brukeren skriver inn iCloud-passordet og signaturen til kvitteringen kontrolleres for korrekthet. Dette beviser at brukeren som genererte forespørselen om å legge til enheten, skrev inn riktig passord da han opprettet kvitteringen.
Etter at brukeren har bekreftet å legge til enheten i kretsen, legger den første enheten til den nye enhetens offentlige synkroniseringsnøkkel til kretsen og signerer den på nytt to ganger ved å bruke dens private synkroniseringsnøkkel og ved hjelp av nøkkelen hentet fra brukerens iCloud-passord. Den nye "sirkelen" lagres i iCloud, og den nye enheten signerer den på samme måte.
Hvordan nøkkelringsynkronisering fungerer
Nå er det to enheter i «tillitssirkelen», og hver av dem kjenner de offentlige nøklene for synkronisering av andre enheter. De begynner å utveksle nøkkelringposter via iCloud Key / Verdilagring. Hvis den samme posten er tilstede på begge enhetene, vil prioritet bli gitt til endringen på et senere tidspunkt. Hvis endringstiden for et opptak i iCloud og på enheten er den samme, er ikke opptaket synkronisert. Hver synkroniseringsoppføring er kryptert spesifikt for målenheten; den kan ikke dekrypteres av andre enheter eller Apple. I tillegg er opptaket ikke permanent lagret i iCloud – det overskrives av de nye synkroniserte opptakene.
Denne prosessen gjentas for hver ny enhet som legges til i tillitskretsen. For eksempel, hvis en tredje enhet legges til i sirkelen, vil bekreftelsesforespørselen vises på de to andre enhetene. Brukeren kan bekrefte tillegget på hvilken som helst av dem. Etter hvert som nye enheter legges til, synkroniseres hver enhet i sirkelen med de nye for å sikre at settet med oppføringer er det samme på alle enheter.
Det skal bemerkes at ikke hele nøkkelringen er synkronisert. Noen oppføringer er knyttet til enheten (som VPN-kontoer) og bør ikke forlate enheten. Bare poster som har kSecAttrSynchronizable-attributtet synkroniseres. Apple har satt dette attributtet for Safari-brukerdata (inkludert brukernavn, passord og kredittkortnumre) og for Wi-Fi-passord.
Som standard synkroniseres heller ikke opptak fra tredjepartsapper. For å synkronisere dem, må utviklere eksplisitt angi kSecAttrSynchronizable-attributtet når de legger til en oppføring i nøkkelringen.
iCloud nøkkelring fungerer med to lagringsenheter:
- com.apple.security.cloudkeychainproxy3
- com.apple.sbd3
Den første butikken brukes visstnok til å opprettholde en liste over pålitelige enheter (enheter i "tillitssirkelen" mellom hvilke passordsynkronisering er tillatt), for å legge til nye enheter til denne listen, og for å synkronisere oppføringer mellom enheter (i samsvar med mekanismen beskrevet ovenfor).
Den andre lagringen er beregnet på å sikkerhetskopiere og gjenopprette nøkkelringposter til nye enheter (for eksempel når det ikke er andre enheter i "tillitskretsen") og inneholder krypterte nøkkelringposter og relatert informasjon.
Dermed lagres nøkkelringposter i vanlig nøkkel-/verdilagring (com.apple.securebackup.record). Disse postene er kryptert med et sett med nøkler som er lagret der (BackupKeybag). Men dette settet med nøkler er passordbeskyttet. Hvor kommer dette passordet fra? Hva er Apples Password Escrow Service? Deretter vil vi prøve å finne ut av det.
apple.Dataclass.KeychainSync
Dette er en ny tjeneste, den oppsto relativt nylig: for første gang dukket støtten opp i betaversjoner av iOS 7, deretter var den fraværende i iOS 7.0–7.0.2 og ble lagt til på nytt i iOS 7.0.3, som ble utgitt samtidig med utgivelsen av OS X Mavericks. Dette er passorddeponeringstjenesten nevnt ovenfor (tjenesteadressen er pXX-escrowproxy.icloud.com).
Tjenesten er designet for å lagre brukerhemmeligheter på en sikker måte og lar brukeren gjenopprette disse hemmelighetene etter vellykket autentisering. For vellykket autentisering trenger du følgende:
- iCloud-autentiseringstoken, oppnådd i bytte mot Apple-ID og passord under innledende autentisering til iCloud (standard autentiseringsmetode for de fleste iCloud-tjenester);
- iCloud sikkerhetskode (iCSC);
- en sekssifret numerisk kode sendt av Apples servere til mobiltelefonnummeret knyttet til brukeren.
Dette ser bra ut i teorien, men for å finne ut om teori er det samme som praksis, må vi revidere escrow-klientprogrammet. På iOS og OS X heter dette programmet com.apple.lakitu. Beskrivelsen av prosessen med reversering og revisjon er utenfor rammen av artikkelen, så la oss gå rett til resultatene.
Tilgjengelige kommandoer
com.apple.lakitu-revisjonen lar deg definere en liste over kommandoer implementert av escrow-tjenesten. Det tilsvarende skjermbildet viser kommandoene og beskrivelsene deres. Jeg vil spesielt dvele ved den siste kommandoen - med dens hjelp er det mulig å endre telefonnummeret knyttet til gjeldende konto. Tilstedeværelsen av denne kommandoen gjør multifaktorautentiseringen som brukes til gjenoppretting av iCloud nøkkelring (Apple ID-passord + iCSC + enhet) merkbart mindre pålitelig, siden den eliminerer en av faktorene. Interessant nok tillater ikke iOS-brukergrensesnittet deg å utføre denne kommandoen - den har rett og slett ikke et slikt alternativ (i det minste fant jeg det ikke).
Det særegne ved denne kommandoen, som skiller den fra alle andre, er at den krever autentisering med Apple ID-passordet og vil ikke fungere hvis iCloud-tokenet brukes til autentisering (andre kommandoer fungerer med token-autentisering). Dette tjener som ekstra beskyttelse for teamet og indikerer at systemdesignerne har tatt skritt for å forbedre sikkerheten. Det er imidlertid ikke helt klart hvorfor denne kommandoen i det hele tatt er til stede i systemet.
Gjenoppretting av deponerte data
For å motta de deponerte dataene, utføres følgende protokoll:
- Klienten ber om en liste over deponerte poster (/ get_records).
- Klienten ber om et tilknyttet telefonnummer, som serveren vil sende en bekreftelseskode til (/get_sms_targets).
- Klienten starter generering og levering av en bekreftelseskode (/gener_sms_challenge).
- Etter at brukeren har skrevet inn iCSC og SMS-bekreftelseskoden, starter klienten et autentiseringsforsøk ved å bruke SRP-6a-protokollen (/ srp_init).
- Etter å ha mottatt et svar fra serveren, utfører klienten beregningene foreskrevet av SRP-6a-protokollen og ber om de deponerte dataene (/gjenoppretting).
- Hvis klienten er vellykket autentisert, returnerer serveren de deponerte dataene, etter å ha kryptert dem tidligere på nøkkelen generert under SRP-6a-protokolloperasjonen (hvis protokollen fungerte vellykket, beregnet både serveren og klienten denne delte nøkkelen).
Det er viktig å merke seg at telefonnummeret hentet i trinn 2 utelukkende brukes til behovene til brukergrensesnittet, det vil si for å vise brukeren nummeret som bekreftelseskoden skal sendes til, og i trinn 3 gjør ikke klienten send serveren nummeret som bekreftelseskoden skal sendes til.
Sikkert eksternt passord
I trinn 4 starter klienten SRP-6a-protokollen. Secure Remote Password (SRP) er en passordautentiseringsprotokoll som er beskyttet mot avlytting og man-in-the-midten-angrep. Dermed, for eksempel, når du bruker denne protokollen, er det umulig å fange opp passord-hashen og deretter prøve å gjenopprette den, rett og slett fordi ingen hash blir overført.
Apple bruker den mest avanserte versjonen av protokollen, SRP-6a. Dette alternativet instruerer å avslutte tilkoblingen hvis autentisering mislykkes. I tillegg tillater Apple bare ti mislykkede autentiseringsforsøk for en gitt tjeneste, hvoretter alle påfølgende forsøk blokkeres.
En detaljert beskrivelse av SRP-protokollen og dens matematiske grunnlag er utenfor rammen av denne artikkelen, men for fullstendighetens skyld er det nedenfor en privat versjon som brukes av tjenesten com.apple.Dataclass.KeychainSync.
SHA-256 brukes som hash-funksjonen H, og 2048-bits gruppen fra RFC 5054 "Using the Secure Remote Password (SRP) Protocol for TLS Authentication" brukes som gruppen (N, g). Protokollen kjører som følger:
- Enheten genererer en tilfeldig verdi a, beregner A = g ^ a mod N, der N og g er parametrene til 2048-bits gruppen fra RFC 5054, og sender en melding til serveren som inneholder bruker-IDen, den beregnede verdien av A og SMS-bekreftelseskoden. DsID-verdien, en unik numerisk brukeridentifikator, brukes som brukeridentifikator.
- Etter å ha mottatt meldingen, genererer serveren en tilfeldig verdi b og beregner B = k * v + g ^ b mod N, der k er faktoren definert i SRP-6a som k = H (N, g), v = g ^ H (Salt, iCSC) mod N er en passordbekreftelse lagret på serveren (analog av en passordhash), Salt er et tilfeldig salt som genereres når du oppretter en konto. Serveren sender en melding til klienten som inneholder B og Salt.
- Ved hjelp av enkle matematiske transformasjoner beregner klienten og serveren felles sesjonsnøkkel K. Dette fullfører den første delen av protokollen – generering av nøkkelen – og nå må klienten og serveren sørge for at de får samme K-verdi.
- Klienten beregner M = H (H (N) XOR H (g) | H (ID) | Salt | A | B | K), et bevis på at han kjenner K, og sender M og SMS-bekreftelseskoden til serveren. Serveren beregner også M og sammenligner det mottatte fra klienten og den beregnede verdien; hvis de ikke samsvarer, avslutter serveren protokollkjøringen og avslutter tilkoblingen.
- Serveren beviser kunnskap om K til klienten ved å beregne og sende H (A, M, K). Nå har begge parter i protokollen ikke bare utarbeidet en felles nøkkel, men også sørget for at denne nøkkelen er lik for begge parter. Når det gjelder deponeringstjenesten, returnerer serveren også en tilfeldig initialiseringsvektor IV og en deponeringspost kryptert på den delte nøkkelen K ved hjelp av AES-algoritmen i CBC-modus.
Å bruke SRP for ekstra beskyttelse av brukerdata, forbedrer etter min mening sikkerheten til systemet fra eksterne angrep, om ikke annet fordi det lar deg effektivt motstå forsøk på brute force iCSC: du kan prøve bare ett passord per tilkobling til tjenesten . Etter flere mislykkede forsøk blir kontoen (innenfor rammen av å jobbe med deponeringstjenesten) overført til myklåstilstand og midlertidig blokkert, og etter ti mislykkede forsøk blir kontoen låst fullstendig og videre arbeid med deponeringstjenesten er kun mulig etter at iCSC for kontoen er tilbakestilt.
Samtidig beskytter ikke bruken av SRP mot interne trusler på noen måte. Det deponerte passordet lagres på Apples servere, så det kan antas at Apple kan få tilgang til det om nødvendig. I dette tilfellet, hvis passordet ikke ble beskyttet (for eksempel kryptert) før deponering, kan dette føre til et fullstendig kompromittering av nøkkelringoppføringene som er lagret i iCloud, siden det deponerte passordet vil tillate dekryptering av krypteringsnøkler, og de - nøkkelringoppføringer (se på com. apple.Dataclass.KeyValue).
I iOS-sikkerhetsdokumentet oppgir Apple imidlertid at spesialiserte maskinvaresikkerhetsmoduler (HSM) brukes til å lagre deponerte poster og at deponerte data ikke er tilgjengelige.
Deponeringssikkerhet
iCloud gir en sikker infrastruktur for nøkkelring-deponering, og sikrer at nøkkelring kun gjenopprettes av autoriserte brukere og enheter. HSM-klynger beskytter deponerte poster. Hver klynge har sin egen krypteringsnøkkel som brukes til å beskytte postene.
For å gjenopprette nøkkelringen må brukeren autentisere seg med iCloud-brukernavnet og passordet og svare på SMS-en som sendes. Når dette er gjort, må brukeren angi en iCloud-sikkerhetskode (iCSC). HSM-klyngen verifiserer riktigheten av iCSC ved hjelp av SRP-protokollen; iCSC blir ikke overført til Apple-servere. Hver node i klyngen, uavhengig av de andre, sjekker om brukeren har overskredet det maksimale antallet datainnhentingsforsøk. Hvis verifiseringen er vellykket på de fleste nodene, dekrypterer klyngen den deponerte posten og returnerer den til brukeren.
Enheten bruker deretter iCSC for å dekryptere den deponerte posten og få passordet som brukes til å kryptere nøkkelringpostene. Ved å bruke dette passordet dekrypteres nøkkelringen hentet fra nøkkel-/verdilagringen og gjenopprettes til enheten. Bare ti forsøk på å autentisere og hente de deponerte dataene er tillatt. Etter flere mislykkede forsøk blokkeres opptaket og brukeren må kontakte support for å oppheve blokkeringen. Etter det tiende mislykkede forsøket ødelegger HSM-klyngen den deponerte posten. Dette gir beskyttelse mot brute-force-angrep rettet mot å få rekord.
Dessverre er det ikke mulig å verifisere om HSM-er faktisk brukes. Hvis alt er sant og HSM ikke tillater å lese dataene som er lagret i dem, kan det hevdes at iCloud-nøkkelring-dataene er beskyttet mot interne trusler. Men igjen, dessverre, er det umulig å bevise eller motbevise bruken av HSM og umuligheten av å lese data fra dem.
Det gjenstår en annen måte å beskytte data mot en intern trussel - å beskytte de deponerte dataene på enheten før de overføres til Apples servere. Av Apples beskrivelse følger det (og reverseringen bekrefter dette) at slik beskyttelse er brukt – det deponerte passordet er forhåndskryptert ved hjelp av iCSC. I dette tilfellet avhenger selvsagt sikkerhetsnivået (fra den interne trusselen) direkte av kompleksiteten til iCSC, og standard iCSC med fire tegn gir ikke tilstrekkelig beskyttelse.
Så vi har funnet ut hvordan de enkelte elementene i systemet fungerer, og nå er tiden inne for å se på hele systemet.
Sette alt sammen
Diagrammet viser arbeidet til iCloud Keychain når det gjelder deponering og gjenoppretting av nøkkelringposter. Systemet fungerer som følger:
- Enheten genererer et sett med tilfeldige nøkler (i Apple-terminologi - nøkkelveske) for å kryptere nøkkelringposter.
- Enheten krypterer nøkkelringoppføringene (med kSecAttrSynchronizable-attributtet satt) ved å bruke nøkkelsettet generert i forrige trinn, og lagrer de krypterte oppføringene i nøkkel-/verdilageret com.apple.sbd3 (nøkkel com.apple.securebackup.record).
- Enheten genererer et tilfeldig passord som består av seks grupper på fire tegn hver (entropien til et slikt passord er omtrent 124 biter), krypterer settet med nøkler generert i trinn 1 med dette passordet, og lagrer det krypterte settet med nøkler i nøkkelen / Verdilagring com.apple. sbd3 (BackupKeybag).
- Enheten krypterer det tilfeldige passordet som ble generert i forrige trinn ved hjelp av nøkkelen hentet fra brukerens iCloud-sikkerhetskode og setter inn det krypterte passordet til com.apple.Dataclass.KeychainSync-tjenesten.
Når du setter opp iCloud nøkkelring, kan brukeren bruke en kompleks eller tilfeldig iCSC i stedet for standard firesifrede kode. Hvis en kompleks kode brukes, endres ikke innskuddssystemets mekanisme; den eneste forskjellen er at nøkkelen for kryptering av det tilfeldige passordet vil bli beregnet ikke fra den firesifrede iCSC, men fra den mer komplekse som er angitt av brukeren.
Med en tilfeldig kode brukes ikke undersystemet for deponering av passord i det hele tatt. I dette tilfellet er det tilfeldige passordet som genereres av systemet iCSC, og brukerens oppgave er å huske og lagre det trygt. Nøkkelringoppføringer er fortsatt kryptert og lagret i nøkkel-/verdilageret com.apple.sbd3, men tjenesten com.apple.Dataclass.KeychainSync brukes ikke.
konklusjoner
Vi kan trygt si at fra et teknisk synspunkt (det vil si at vi ikke vurderer sosial ingeniørkunst) og i forhold til eksterne trusler (det vil si ikke Apple), er sikkerheten til iCloud Keychain-deponeringstjenesten på et tilstrekkelig nivå: takket være bruken av SRP-protokollen, selv om iCloud-passordet er kompromittert, vil ikke angriperen få tilgang til nøkkelringpostene, siden dette i tillegg krever en iCloud-sikkerhetskode, og det er betydelig vanskelig å gjenta denne koden.
Samtidig, ved å bruke en annen iCloud-nøkkelringmekanisme - passordsynkronisering, kan en angriper som har kompromittert iCloud-passordet og har kort fysisk tilgang til en av brukerens enheter fullstendig kompromittere iCloud-nøkkelringen: for dette er det nok å legge til angriperens enheten til "tillitskretsen" til brukerens enheter , og for dette er det nok å kjenne iCloud-passordet og ha kortsiktig tilgang til brukerens enhet for å bekrefte forespørselen om å legge til en ny enhet i "kretsen".
Hvis vi vurderer beskyttelse mot interne trusler (det vil si Apple eller noen med tilgang til Apples servere), så i dette tilfellet ser ikke sikkerheten til deponeringstjenesten så rosenrød ut. Apples påstander om bruk av HSM-er og manglende evne til å lese data fra dem har ingen avgjørende bevis, og den kryptografiske beskyttelsen av de deponerte dataene er knyttet til iCloud-sikkerhetskoden, med standardinnstillingene ekstremt svake og lar alle som er i stand til utdrag fra Apple-servere (eller HSM-er) deponerte poster, gjenopprett din firesifrede iCloud-sikkerhetskode nesten umiddelbart.
Når det gjelder en kompleks alfanumerisk kode, blir dette angrepet vanskeligere ettersom antall mulige passord øker. Hvis iCloud-nøkkelring er konfigurert til å bruke en tilfeldig kode, er ikke deponeringstjenesten involvert i det hele tatt, noe som effektivt gjør denne angrepsvektoren umulig.
Det maksimale sikkerhetsnivået (selvfølgelig ikke medregnet den fullstendige nedleggelsen av iCloud-nøkkelringen) er sikret når du bruker en tilfeldig kode - og ikke så mye fordi en slik kode er vanskeligere å finne, men fordi passorddeponeringsundersystemet ikke er involvert , og derfor reduseres angrepsflaten. Men bekvemmeligheten av dette alternativet overlater selvfølgelig mye å være ønsket.
ICloud nøkkelring er en uerstattelig assistent for å holde viktig og hemmelig informasjon. Alle passord lagres fra Safari-applikasjonen til skylagringen. Det er ikke nødvendig å skrive ned eller huske komplekse passord selv, en haug med nøkler vil hjelpe deg med å huske og åpne alt.
Hvis du bruker iCloud Keychain-appen, skriv inn iCloud-sikkerhetskoden. Koden kan være sekssifret, numerisk eller alfanumerisk, eller genereres automatisk. Denne koden lar deg gjenopprette data hvis enheten går tapt, samt utføre visse handlinger når du identifiserer en bruker. Dette er ekstra beskyttelse, men koden skal være slik at du ikke glemmer og husker den. Hvis du taster inn koden feil, og til og med flere ganger, vil nøkkelringen bli blokkert på denne enheten. For å gjenoppta arbeidet, kontakt Apples tekniske tjenester for å autentisere og låse opp.
Ved aktivering av nøklene kan du hoppe over å taste inn sikkerhetskoden og hoppe over dette trinnet, da blir ikke informasjonen lagret i skyen.
Buntoppsett
Hvis det er umulig å bekrefte påloggingen fra en annen enhet til applikasjonen på den nye enheten, bruk sikkerhetskoden, etter å ha skrevet inn den, bekrefte tilkoblingen via SMS. På en hvilken som helst Apple-enhet, for å konfigurere applikasjonen, gå til "Innstillinger"-menyen, velg "iCloud", se etter en applikasjon med taster. Når du klikker på programikonet, vises en bryter, skyv den for å aktivere. Skriv inn ID-passordet ditt og fortsett med instruksjonene. Nå har du tilgang til den viktigste funksjonen - automatiseringen av å legge inn eventuelle passord og koder. Betal enkelt for kjøp, gå til nettsteder, send e-post uten å nøle.
Kredittkortsikkerhet
Hvelvet inneholder kredittkortnumre og deres utløpsdatoer. Sikkerhetsnumrene forblir ikke i minnet. Hvis du kobler fra programmet, slettes ikke dataene.
Noen problemer ved bruk av applikasjonen og måter å løse dem på
Kode ikke mottatt på SMS
- Sørg for at dette telefonnummeret er knyttet til kontoen din.
- Sjekk tariffplanen din for å finne ut om SMS-varsler er forbudt.
Sjekk nummeret som er knyttet til kontoen gå til "Innstillinger", velg "iCloud nøkkelring", gå til fanen "Avansert". Et telefonnummer legges inn i delen "Bekreftelsesnummer".
Sosiale passord vises ikke på enheter
I "Innstillinger"-delen åpner du "Safari" og går til "Autofullfør". Kontroller at kontoen for navn og passord fungerer. Hvis du slår av denne funksjonen, huskes ikke passord. Trykk deretter Hjem og sjekk ut Safari. Hvis programvinduet er svart, deaktiver "Privat tilgang"-modus.
Noen ganger gir ikke populære nettsteder tillatelse til å lagre de besøkendes passord, så passordene deres vil ikke bli lagret.
Hvis du mister tilgangen til en av enhetene
Hvis du mister tilgangen til en av enhetene, må du opprette en annen sikkerhetskode. Gå til "Innstillinger", velg applikasjonen, gå til fanen "Avansert". Velg "Bekreft med sikkerhetskode" og velg fanen "Glemt kode". Aktiver Tilbakestill nøkkelring. Bekreft handlingene dine og opprett et nytt passord.
Melding om kodeendring
Hvis meldingen om endringen av sikkerhetskoden vises, må du ikke ignorere den. Det er ikke nødvendig å oppdatere sikkerhetskoden, men systemet må oppdateres. Hvis du ikke følger disse trinnene, vises meldingen igjen. Hvis du ignorerer denne meldingen og ikke svarer ved å krysse av for «ikke nå», vil nøkkelringen bli slått av etter den tredje feilen. Synkronisering vil ikke forekomme på andre enheter, og det vil være umulig å gjenopprette applikasjonen via nettstedet.
Når denne meldingen vises, er det mulig å oppdatere. Klikk "opprett" og følg de foreslåtte handlingene.
Feil kode tastet inn mange ganger
Hvis du taster inn feil kode flere ganger, vil koblingen bli deaktivert. Skynøkkelringen vil ganske enkelt bli slettet. Bekreft denne enheten med en annen eller tilbakestill appen.
Slå av tjenesten på alle enheter
Hvis du slår av denne tjenesten fra alle enheter, vil pakken din bli fjernet fra skyen. For å gjenoppta arbeidet, konfigurer tjenesten på nytt.
Hver gang du oppdaterer programvaren til en hvilken som helst Apple-enhet, må du også rekonfigurere bunteren. For å gjøre dette, gå til iCloud-innstillingene og slå på tastene ved å flytte glidebryteren. Følg deretter instruksjonene og konfigurer enheten på nytt.
Sikkerhet
Apple overholder retningslinjene for konfidensialitet, og informasjon mottatt fra brukere av produktene deres avsløres ikke. Informasjonen overføres i kryptert form, nøklene kan ikke overføres til noen andre. Informasjon om plasseringen av gadgeten vil ikke lagres i mer enn en dag i skyen, og deretter slettes den permanent.
Hvis du har problemer med sammenkoblingen, sjekk innstillingene i enheten.
