Ennek a posztsorozatnak az előző (és egyben első) részében bemutattam, hogy miért és hogyan kezdtem el a sorozatban feldolgozott téma után érdeklődni. A mai részben továbbhaladok a rendszer általános biztonsági funkcióira, képességeire. 🙂
Az Apple abban a kivételes helyzetben van, hogy a maga által készített szoftverhez ők maguk tervezik a hardvert is, ezért sokkal biztonságosabb platformot képesek megalkotni mint a konkurencia. Ez lehetővé teszi, hogy olyan egyedi képességeket alakítson ki a szoftver és a hardver együttes működésével amelyre a konkurencia (működési modelljéből fakadóan) nem mindig képes. Ezzel nem azt mondom, hogy az Apple a hegytetőn álló vár, a konkurencia meg a völgyben lévő aknamező, de kétségtelen az egy kézben lét előnye.
Bekapcsolástól a főképernyőig
A szoftver-hardver szoros összeillesztése az Apple eszközöknél rögtön a készülék bekapcsolása után életbe lép. Ezt biztonságos indításnak (angolul secure boot-nak) hívjuk. A secure boot lényege, hogy az indítási lépések között a vezérlés csak és kizárólag akkor kerül átadásra, amikor az előző lépést végrehajtó fél teljes mértékben meggyőződik a következő lépést végrehajtó fél helyes működéséről (chain of trust).
Az iOS secure boot folyamatában résztvevő minden komponenst az Apple kriptográfiailag aláír, ezzel hitelesíti és biztosítja azok integritását a legalacsonyabb szinten. Ebbe beletartozik a:
- bootloader (feladata az operációs rendszer számára előkészíteni a hardvert)
- kernel (az operációs rendszer magja)
- kernel extensions (a kernelhez tartozó opcionális bővítmények)
- baseband firmware (a baseband processzor belső vezérlőszoftvere – ettől tudsz telefonálni)
A gyakorlatban ez úgy néz ki, hogy rögtön a bekapcsolás után a processzor (CPU) egy sor olyan kódot hajt végre, amit a boot ROM-ból olvas ki. A boot ROM-ban tárolt utasításkészlet a gyártás során áll elő (“kerül bele”) és csak olvasni lehet, írni nem. A boot ROM-ban tárolt információ lesz egyébként a “chain of trust” gyökere, mert tartalmazza az Apple saját, legfelső szintű tanúsítványához (root CA) tartozó publikus kulcsot (itt letölthető és megtekinthető).
Következő lépésként, boot ROM-ból kiolvasott Apple root CA publikus kulcsával ellenőrzik az iBoot bootloader-t is, aláírta-e az Apple. Ha igen, elindul a betöltése (első szintje a chain of trust-nak). Amikor a bootloader befejezte a feladatát, egy újabb aláírás ellenőrzés történik, most már az iOS kernel a vizsgálat tárgya. Ha a kernel-t is az Apple írta alá, akkor elkezdődik annak a betöltése (2. szintje a chain of trust-nak) és ezen szisztéma szerint megy a rendszer a 3., a 4., stb. szintekre.
Attól függően, hogy a fenti lánc hol szakad meg (valami oknál fogva), más-más állapotba kerül a készülék:
- ha a boot ROM nem tudja átadni a vezérlést az iBoot bootlader-nek, akkor kerül a készülék DFU módba,
- ha pedig az iBoot után a kernel betöltése nem lehetséges, akkor pedig Recovery (helyreállítási) módba kerül a készülék.
Akár DFU, akár helyreállítási módba kerül a készülék, mindkét esetben számítógép kell a folyamat befejezéséhez.
A baseband processzornak és a Secure Enclave processzorok saját secure boot mechanizmussal rendelkeznek.
Frissítés
Amikor frissíteni kívánjuk a készüléket, mi ugyan nem látjuk, de a háttérben is nagyon komoly erőfeszítések történnek arra, hogy az biztonságos és sikeres legyen.
A frissítés során első lépésként a telefon csatlakozik az Apple telepítő és jóváhagyó szerveréhez. A csatlakozás után a telefon nagyon sok paramétert és információt elküld, de ezek között a legfontosabb kettő:
- az eszköz egyedi ECID száma
- egy vissza-, újrajátszást meggátoló véletlen értéket (nonce).
A szerver a kapott adatok alapján ellenőrzi, hogy milyen frissítést kell előállítania a készüléknek. Ha van frissítés a telefontól kapott adatok alapján, akkor a szerver a frissítő csomagot ellátja a készülék ECID számával, majd hitelesítésként aláírja, majd visszaküldi a készüléknek.
Az ECID szám használatával az Apple a frissítést az adott készülékre testreszabja, egyedivé teszi.
A telefon, a válaszként kapott frissítési csomagon ellenőrzi, hogy az ECID szám és a küldött paraméterek egyeznek-e azzal, amit korábban elküldött, illetve azt is, hogy a választ tényleg az Apple hitelesítette (a secure boot-ban tárolt publikus kulcs alapján). Ezek a lépések biztosítják azt, hogy csak olyan szoftver telepíthető a készülékre, amit az Apple a tárgyban forgó készülékre jóváhagyott.
Ezért is “fontosak” azok a hírek, amikor azt olvashatjátok a szaksajtóban, hogy az Apple visszavonta az X.Y verziójú iOS frissítés aláírását, mert ilyenkor a készülék már nem tudja sikeresen ellenőrizni az adott verziót. Egyszerűen a secure ROM-ban tárolt Apple kulcs segítségével történő érvényesítésen az adott iOS verzió el fog bukni.
Amíg az Apple aláírja az adott iOS verziót, a DFU mód segítségével minden gond nélkül telepíthető a készülékre.
A korábban említett nonce egy olyan speciális paraméter, amely lehetetlenné teszi azt, hogy egy rosszindulatú személy a szerver válaszát elmentve, később a folyamatot “újra játszva” kárt okozzon.
Az operációs rendszer integritása
Most, hogy már bekapcsoltuk a készüléket és tudjuk, hogy a frissítés is komplex folyamat (biztonság szempontból), nézzük meg, hogy egy működő rendszer során is mennyi minden zajlik a háttérben, hogy a rendszer integritása (érintetlensége) megmaradjon.
Kernel Integrity Protection
A Kernel Integrity Protection (KIP) funkciója röviden az, hogy meggátolja az operációs rendszer és a szükséges meghajtó szoftverek kódjának megváltoztatását. Ezt úgy érik el, hogy a boot folyamán a memória vezérlő egy dedikált és védett memóriaterületet biztosít az iBoot bootloader számára, ahova az a kernel-t és a szükséges meghajtó programokat betölti. A boot folyamat végén a memória vezérlő végül lezárja a “kaput”, így a későbbiekben minden írási kísérletet elutasít.
A KIP az iPhone 7 és Series 4 órától érhető el.
System Coprocessor Integrity Protection
A fő processzoron kívül számos egyéb segédprocesszor (mozgásérzékelő, Secure Enclave, kamera szenzor, stb.) található a készülékekben. Ezeknek a processzoroknak a működését a firmware biztosítja. A System Coprocessor Integrity Protection (SCIP) működése teljes mértékben hasonlít a KIP-hez; az iBoot egy dedikált és védett memóriaterületre tölti be a processzorok firmware-t. A KIP és a SCIP által használt, védett memóriaterület egyébként teljesen szeparált.
A SCIP az iPhone XS/XR és Series 4 órától érhető el.
Pointer Authentication Codes
Szintén az iPhone XS/XR és Series 4 vagy újabb készülékek rendelkeznek Pointer Authentication Codes (PAC) támogatással. A PAC lényege, hogy meggátolja a memória címzések módosítását, korrumpálását, mivel azokat az erre generált kulcsokkal aláírják. Így nem módosíthatóak anélkül, hogy az integritásuk megmaradjon.
Találtam egy részletes anyagot a témáról a Qualcomm oldalán (csak haladóknak, bitgörbítőknek). 🙂
Page Protection Layer
Az utolsó kicsit nehezen érthető védelmi funkció a Page Protection Layer (PPL). Ennek a védelmi mechanizmusnak az a feladata, hogy – hasonlóan a KIP-hez, minden módosítási kísérletet meggátoljon a memóriában tárolt felhasználói adatokon, miután a kód aláírásának ellenőrzése megtörtént.
A következő részben már onnan fogom folytatni, ahol Twitteren elkezdtem, aki azokat olvasta, sok újdonságot már nem fog találni, maximum kevesebb félregépelést. 🙂
A bejegyzés kiemelt képét készítette:
Matt Seymour