Az alábbi cikket Ys. írta a 0x90 blogon, és mivel a cikksorozata kapcsolódik az iPhone-hoz, mi érdekesnek gondoljuk a számotokra is, így ezeket engedelmével egymás után át is emelnénk ide, a Szifonra.

***

A fájlrendszerek titkosítása az a terület, aminek kapcsán rengeteg félinformáció és tévhit kering, még szakmai körökben is.

Tényleg titkosítva van minden fájl az iPhone-okon és iPadeken? Igen.

Tényleg külön kulcs van minden fájlhoz? Tényleg.

Tényleg hardveres AES-t használ a titkosítás? Tényleg, komolyan.

Ezek szerint hátradőlhetünk, hogy király, nem kell többé aggódnunk azon, hogy ellopják az eszközünket, mert a támadó úgyse tud vele mit kezdeni? Nos, nem egészen.

Legelőször is némi törióra. Amikor megjelent az iPhone 3GS kiadása, akkor mutatkozott be az a fícsör, ami igénybe vette az integrált hardveres AES-egységet, effektíve full-disk titkosítást hozva a mobilpiacra. A 3GS esetében azonban kissé kontraintuitív módon nem a biztonság bizalmassági kontrollok javítása volt a cél az AES használatával, hanem az, hogy minél gyorsabban törölni lehessen (illetve használhatatlanná lehessen tenni) az eszközön lévő adatokat. Ez pedig azt jelentette, hogy az egyik partíción megtalálható volt clear text formátumban a másik partíciót nyitó kulcs – no comment. Azóta sok víz lefolyt a Dunán és sok minden változott a világban, de az iPhone-okban (és újabban az iPadeken) lévő AES titkosítóegység maradt és köszöni szépen, jól van és az iOS4-es kiadásával már valóban titkosítási célokat szolgál.

Mindennek az alapja a hardver, ami esetünkben egy kutyaközönséges NAND tároló, aminek a mérete változik attól függően, hogy mennyi memóriával rendelkező modellt emeljük le a polcról a boltban. Ez tartalmazza az eszközön tárolt adatokat, azonban maga a fájlrendszer csak egy szegmens a sok közül.

1. BOOT szegmens. Az Apple alacsony szintű bootloaderét tartalmazza.
2. PLOG szegmens. Ez a szegmens elsősorban kriptográfiai kulcsokat, keybageket és ilyesmiket tárol. Három fontos kulcs lakik itt: BAGI, Dkey és az EMF! kulcs. Wipe során ezt a területet küldjük meg napalmmal. Tároli tt az eszköz egy security időpecsétet is, ami biztosítja, hogy ne lehessen downgrade-elni (ha valaki pl. próbálta iOS4-ről visszagyógyítani 3-asra az eszközét és úgy tűnt, hogy brickelte, sok esetben visszahozhatja, ha ezt a területet matatja megfelelő céleszközzel).
3. NVM. Az NVRAM paramétereit tároljuk itt.
4. FIRM. Itt lakik a firmware, a második lépcsős bootloader és az az almás logó, amiben boot alkalmával gyönyörködhetünk.
5. FSYS. Ez maga a titkosított fájlrendszer az ő két partíciójával (ugye az egyik read-only alapból és az oprendszert tartalmazza, míg a másikra lehet zenéket meg fotókat másolni és a telepített appok is ott laknak).
6. RSRV. A NAND tároló utolsó pár blokkját nem lehet se írni, se olvasni.

Igen, valóban titkosított minden fájl a fájlrendszerben. A tényleges kriptográfiai motor eléggé bonyolult, nem is írom le minden részét (pl. alapból minden fájlhoz nem egy, hanem két kulcs tartozik az egyszerű wipe-olhatóság biztosítására), de az alapokat egyszerűen el lehet mondani. Akit részleteiben érdekel a dolog, az ide kattintson.

Mielőtt agyhúgykövet kaptok a továbbiaktól, nagyon fontos észben tartani, hogy a fájlrendszer titkosítása alapvetően arra lett kitalálva, hogy ha az eszközből kiforrasztják a NAND tárolót és olvasni próbálják, ne tudjanak mit kezdeni vele, plusz triviálisan lehessen, minimális írással wipe-olni. Amikor a cucc áram alatt van és még az iOS is fut, a lent leírt dolgok teljesen transzparensek felhasználói szempontból és sok esetben fejlesztőileg is.

Az első fontos dolog, amiről beszélni kell, az az, hogy a fájlok között védelmi szempontból különböző csoportok léteznek, a hivatalos terminológiában ezeket a csoportokat Protection Classoknak hívják. A nevek ismerősek lehetnek a keychaines felsorolásból, ami nem véletlen, ugyanis pontosan ugyanarra a logikára működik ez is.

Alapból mindenki külön AES-kulccsal van titkosítva és ha törlünk egy fájlt, akkor a hozzá tartozó kulcsot eltávolítjuk a kulcstárból. (Ez egyébként zseniális megoldás, ugyanis a fájlhoz tartozó NAND-területet nem kell ilyenkor matatni, urambocsá’ felülírni, ugyanis a NAND fizikai tulajdonságai miatt meglepően kevés alkalommal újraírható technológia.) Az egy Protection Classhoz tartozó fájlok kulcsai egy-egy közös master kulccsal vannak titkosítva, és az oprendszer ezeket a master kulcsokat a Classnak megfelelő módon kezeli. A master kulcsok egy keybag nevű csodában laknak a PLOG szegmensben, szintén titkosítva. Mik ezek a classok?

• NSFileProtectionNone: Azok a fájlok, amik igazából nem védettek, csak látszólag. A hozzájuk tartozó master kulcs az eszköz fizikai azonosítójából és egy pár jól definiált paraméterből származik, a támadó az eszközhöz fizikailag hozzáférve ki tudja számolni ezt a kulcsot, de ha sikerül felbootolnia az iOS-t, akkor az API hívások plain-textben adják vissza a fájlok tartalmát. Az eszközön lévő dolgok 99%-a ilyen – alapból csak a júzer mailboxához tartozó lokális cache nem tartozik ide.
• NSFileProtectionComplete: Amikor az eszköz le van csukva (azaz a júzer nem tudja toszogálni az ikonokat a képernyőn), ezek a fájlok is el vannak engedve. A hozzájuk tartozó master kulcsot a júzer PIN-jéből/jelszavából származtatjuk, akárcsak a keychainnél és amíg sötét a képernyő, a memóriában sincs példány a kulcsból – elvileg.
• NSFileProtectionCompleteUnlessOpen: a fájl alapból be van csukva boot után egészen addig, amíg de nem kriptálják (ugye az igekötő :-P), és utána is csak akkor elérhető a tartalma, ha nyitva van az eszköz.
• NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication: a fájl alapból be van csukva boot után, de az első alkalommal, amikor a júzer kioldja a PIN-zárat, kinyílk és újraindításig nyitva is marad írásra (azaz becache-eli az oprendszer a hozzájuk tartozó írási kulcsot), viszont olvasni csak akkor lehet ezután, ha ki van nyitva az eszköz. További perverzióként az ide tartozó fájlok aszimmetrikus kripóval vannak titkosítva, és kulcspár tartozik hozzájuk.

A PLOG tárolón lévő három kulcsról ígértem még infót az előbb. Az EMF kulcs szükséges ahhoz, hogy bármit tudjunk csinálni az eszközön, azaz egy fájl feloldásához szükséges az EMF kulcs is, függetlenül attól, hogy melyik Protection Classba tartozik. Ezt a kulcsot használjuk a HFS journal titkosítására is – ha ezt a kulcsot megküldjük napalmmal, akkor az egész fájlrendszer nyithatatlan, effektíve szemét. A BAGI kulcs a system kulccsal titkosított fájlok kulcsainak kulcsa, míg a Dkey a NSFileProtectionNone Classba tartozó fájlokat nyitja.

Hogy áll ez az egész össze? Amikor bekapcsoljuk az eszközt és felbootol az iOS, egyedül az NSFileProtectionNone Classba tartozó fájlokhoz rendelt Dkey kulcs nyitható (illetve kiolvasható a NAND tárolóról), a többi Protection Classhoz tartozó fájlok megnyitásakor hibát kapunk. A többihez a júzernek legalább egyszer fel kell oldania az iOS screen lockot a PIN kódjával – amikor megteszi, a PIN-ből turbóznak egy AES-kulcsot, ami kinyitja a többi három Classhoz tartozó keybaget. A NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication fájlokhoz tartozó írási kulcsot is becache-eli az oprendszer (lévén ugye innentől már kikapcsolásig írhatóak az ide tartozó fájlok). A júzer nyomogat-húzogat, az appok nyitogatják a fájlokat az iOS API-n keresztül és olvassák-írják őket. A júzer egyszer csak abbahagyja a nyomogatást és lecsukja az eszközt (vagy lejár a screen timeout), ekkor elfelejtjük a PIN-ből derivált AES-kulcsot, a NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication osztályú fájlok olvasási kulcsát és a NSFileProtectionCompleteUnlessOpen fájlok szimmetrikus kulcsát. Amikor le van csukva az eszköz, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication osztályú fájlokat lehet írni a becache-elt írási kulccsal, de olvasni őket nem lehet (nincs ugye meg a megfelelő kulcs) – plusz ugye a NSFileProtectionNone osztályú fájlokkal bármit lehet csinálni, benne van a memóriában a Dkey. Egyszerű, nem?

A fenti rész kicsit kusza lehet egy olvasásra – ha tényleg mélyen érdekel a kulcskezelés, olvass bele ebbe a doksiba a 19.oldal környékén és szörnyülködj a hajtogatnivaló kriptográfiai ábrákon.

És most mi van, jöhet a kérdés. Hol van a szar a palacsintában?

Megmondom.

1. A fájlok titkosításához használt kulcsok közül a legtöbb fájlhoz tartozó master kulcs kitalálható (NSFileProtectionNone).
2. Ha már fut az iOS, a titkosítási móka 99%-a teljesen transzparens. Minden külön védelmet nem kapott fájlhoz hozzáférünk egy USB kábelen keresztül, tulajdonképpen semmi jelentősége annak, hogy maguk a fájlok fizikai szinten titkosítva vannak. Az iExplorer nevű csodával a telepített appok által írt fájlokat is matatni lehet, nem csak a “publikus” részét a fájlrendszernek.
3. A keybageket a PLOG szegmensben tároljuk, emiatt ha valaki ehhez hozzáfér, ki tudja nyerni az egyes fájlokat nyitó kulcsokat. Egyedül az Apple bizalmi lánca akadályozza meg, hogy olyan app kerüljön ki az AppStore-ba, ami ezt megteszi. Ha jailbreakelt az eszköz, akkor lehet rá dd-t is tenni, innét meg ugye reszeltek az eldugott szegmensekben lévő adatok bizalmasságának.
4. Ami titkosítás ér is valamit, az a júzer PIN-jén/jelszaván múlik. Erről többet nem is mondanék: az alap négyjegyű PIN alig húsz perc alatt feltörhető.
5. A HFS naplóz és ez totál szívás wipe szempontjából. Amikor az iOS töröl egy fájlt, az általa elfoglalt területet írhatóvá nyilvánítja és a metaadatok közül kitörli (végleg) az egyedi EMF-fel titkosított AES-kulcsát. Idáig jó a dolog, ugyanis enélkül a kulcs nélkül esélytelenek vagyunk kiniytni a fájlt – csakhogy ugye ott van az a fránya HFS, ami rögzíti a törölt metaadatokat, így a törölt AES-kulcsot is. A HFS journal pedig az EMF kulccsal van titkosítva, amit meg ugye ismerünk, vagy legalábbis az oprendszerből kinyerhető – erre mondják polkorrekten, hogy hát, van még fejlődési potenciál a dologban, de az irány jó.