Luk annoncen

Afsendelse af beskeder via iMessage er en populær måde at kommunikere mellem iOS-enheder og Mac-computere på. Titusmillioner af beskeder behandles af Apples servere dagligt, og i takt med at salget af Apple-bitte enheder vokser, vokser populariteten af ​​iMessage også. Men har du nogensinde tænkt over, hvordan dine beskeder er beskyttet mod potentielle angribere?

Apple udgav for nylig dokumenter der beskriver iOS-sikkerhed. Det beskriver fint de sikkerhedsmekanismer, der bruges i iOS - system, datakryptering og beskyttelse, applikationssikkerhed, netværkskommunikation, internettjenester og enhedssikkerhed. Hvis du forstår lidt om sikkerhed og ikke har et problem med engelsk, kan du finde iMessage på side nummer 20. Hvis ikke, vil jeg forsøge at beskrive princippet om iMessage-sikkerhed så klart som muligt.

Grundlaget for at sende beskeder er deres kryptering. For lægmænd er dette ofte forbundet med en procedure, hvor man krypterer beskeden med en nøgle, og modtageren dekrypterer den med denne nøgle. En sådan nøgle kaldes symmetrisk. Det kritiske punkt i denne proces er at overdrage nøglen til modtageren. Hvis en angriber fik fat i det, kunne de simpelthen dekryptere dine beskeder og udgive sig for at være modtageren. For at forenkle, forestil dig en æske med lås, hvori kun en nøgle passer, og med denne nøgle kan du indsætte og fjerne indholdet af æsken.

Heldigvis er der asymmetrisk kryptografi ved hjælp af to nøgler - offentlige og private. Princippet er, at alle kan kende din offentlige nøgle, selvfølgelig er det kun dig, der kender din private nøgle. Hvis nogen vil sende dig en besked, krypterer de den med din offentlige nøgle. Den krypterede besked kan derefter kun dekrypteres med din private nøgle. Hvis du forestiller dig en postkasse igen på en forenklet måde, så har den denne gang to låse. Med den offentlige nøgle kan enhver låse den op for at indsætte indhold, men kun dig med din private nøgle kan vælge den. For at være sikker vil jeg tilføje, at en besked krypteret med en offentlig nøgle ikke kan dekrypteres med denne offentlige nøgle.

Sådan fungerer sikkerhed i iMessage:

  • Når iMessage er aktiveret, genereres to nøglepar på enheden – 1280b RSA for at kryptere dataene og 256b ECDSA for at verificere, at dataene ikke er blevet manipuleret undervejs.
  • De to offentlige nøgler sendes til Apples Directory Service (IDS). De to private nøgler forbliver naturligvis kun gemt på enheden.
  • I IDS er offentlige nøgler knyttet til dit telefonnummer, e-mail og enhedsadresse i Apple Push Notification-tjenesten (APN).
  • Hvis nogen vil sende en besked til dig, vil deres enhed finde ud af din offentlige nøgle (eller flere offentlige nøgler, hvis du bruger iMessage på flere enheder) og APN-adresserne på dine enheder i IDS.
  • Han krypterer beskeden ved hjælp af 128b AES og signerer den med sin private nøgle. Hvis beskeden skal nå dig på flere enheder, gemmes og krypteres beskeden på Apples servere separat for hver af dem.
  • Nogle data, såsom tidsstempler, er slet ikke krypteret.
  • Al kommunikation foregår over TLS.
  • Længere beskeder og vedhæftede filer krypteres med en tilfældig nøgle på iCloud. Hvert sådant objekt har sin egen URI (adresse for noget på serveren).
  • Når beskeden er leveret til alle dine enheder, slettes den. Hvis det ikke bliver leveret til mindst én af dine enheder, efterlades det på serverne i 7 dage og slettes derefter.

Denne beskrivelse kan virke kompliceret for dig, men hvis du ser på billedet ovenfor, vil du helt sikkert forstå princippet. Fordelen ved et sådant sikkerhedssystem er, at det kun kan angribes udefra med rå magt. Nå, for nu, fordi angribere bliver klogere.

Den potentielle trussel ligger hos Apple selv. Dette skyldes, at han administrerer hele infrastrukturen af ​​nøgler, så i teorien kunne han tildele en anden enhed (et andet par offentlige og private nøgler) til din konto, for eksempel på grund af en retskendelse, hvor indgående beskeder kunne dekrypteres. Her har Apple dog sagt, at det ikke gør og vil gøre sådan noget.

kilder: TechCrunch, iOS-sikkerhed (februar 2014)
.