Az Apple feltárja az iOS biztonsági részleteit

Mostantól hallotta, hogy az Apple bejelentette egy új hibaelhárító programot a közelmúltbeli Black Hat konferencián. Szokatlan megjelenés mellett Ivan Krstic, az Apple biztonsági mérnöki és építészeti vezetője maga tette közzé a bejelentést. De ez csak egy 50 perces előadás utolsó 10 perce volt. Az első 40 percben a Krstic példátlan mély merülést tett az iOS biztonság három elemébe. És mélyen a fürdoszférikusnak értem.

Teljes átvételemtől félelmet éreztem abban, hogy ezek a rendszerek miként védik a felhasználói adatokat, még magát az Apple-től is. Megpróbálom továbbadni azt, amit mondtak, anélkül, hogy túl technikai lenne.

Edzett WebKit JIT leképezés

Sajnálom, így hívják. A JIT a Just In Time kifejezést jelenti, és utal arra, hogy a Javascript kód miként fordul elő a végrehajtáshoz szükséges időben. "Ez szükséges a nagy teljesítményű JavaScripthez" - magyarázta Krstic. "De a kód-aláírási politikát enyhíteni kell. A JIT-fordító új, aláíratlan kódot bocsát ki. A támadó, aki bárhol írt támadást sikerült, tetszőleges kód futtatását teheti lehetővé."

Egy kis háttér szempontjából a memória területeit meg lehet jelölni olvasási, írási és végrehajtási engedélyekkel. Ez a megkülönböztetés, amelyet évszázadok óta vezettek be, elcsábította a támadásokat, amelyek kódot hajtottak végre az adatoknak szentelt területeken. Röviden: az Apple megoldása magában foglalja azt a technikát, amellyel a lefordított JavaScriptet memóriaterületre helyezik, amely csak a végrehajtást engedélyezi. A folyamatok nem tudják olvasni az ott található információkat, vagy új adatokat nem tudnak írni. Ennél kissé több, de ez az iOS 10-re jellemző változás a lehetséges támadások egész sorát törli el.

Biztonságos enklávé processzor

Az Apple készülékeken az alkalmazásprocesszornak vagy AP-nek nevezett CPU-n futnak az alkalmazások. A modern Apple eszközök teljesen különálló processzorral rendelkeznek, amelyet Secure Enclave Processornak (SEP) hívnak. "A SEP-t egy erős titkosítási mesterkulcs védi a felhasználó jelszavától" - mondta Krstic. "Offline támadás nem lehetséges. Ez elkerüli az AP támadó felületét, még akkor is, ha az AP kompromittálódott. Kiválasztja az összes felhasználói hozzáférést és kezeli a saját titkosított memóriáját. Az első inicializáláskor egy valódi véletlenszám-generátort használ, hogy hozzon létre egy egyedi eszközkulcs a processzoron belül. Ez nem exportálható, és változatlan biztonságos ROM-ban tárolva."

Krstic folytatta annak magyarázatát, hogy az eszköz hogyan használ négyféle típusú, eltérő tulajdonságokkal rendelkező belső biztonsági kulcsot. Az A típus csak akkor létezik, ha az eszköz fel van oldva. A B típus mindig jelenlévő nyilvános kulcs, valamint egy privát kulcs, amely az eszköz feloldásakor létezik. A C típus akkor létezik, amikor az eszközt először oldják fel indítás után. És a D típus mindig rendelkezésre áll.

A bemutató számos komolyan bonyolult diagramra váltott. Az egyik végigjárta a rendszer indításának és feloldásának folyamatát, megmutatva, hogy az egyes kulcstípusok hogyan készültek és tárolódtak. A készüléken lévő minden fájlnak megvan a saját, egyedi titkosítási kulcsa; egy másik ábra azt a bonyolult táncot mutatta, amely lehetővé teszi a SEP számára a fájl hitelesítését és visszafejtését, miközben az alapvető biztonsági kulcsokat magában tartja. Egy másik magyarázta a komplex folyamatot, amely lehetővé teszi, hogy a "Frissítés később" lehetőséget választhassa. És újabb lépés történt a folyamaton, amely lehetővé teszi az érintőazonosító segítségével történő feloldást anélkül, hogy a fő kulcsot bármilyen módon látnánk.

A beszélgetés e részéből az a kulcstartó tény, hogy az Apple valóban, nagyon gondosan átgondolta, hogy mi szükséges-e a titkosítás teljes kezeléséhez a Secure Enclave processzoron belül anélkül, hogy a felhasználót egyáltalán sok bajra kényszerítené. Ha saját magának szeretné látni ezeket a rajzokat, nézd meg a Krstic teljes bemutatóját.

Titkok szinkronizálása

Rendkívül kényelmes, hogy szinkronizálja adatait több Apple eszköz között. A HomeKit lehetővé teszi az IoT-eszközök kezelését, az AutoUnlock lehetővé teszi a Mac feloldását, ha a közelben található az Apple Watch, a fényképek szinkronizálódnak az iCloudon keresztül, és így tovább. Biztonsági szempontból azonban a szinkronizálás problémát jelent.

"A hagyományos megközelítés nem jó" - mondta Krstic. "Az egyik módszer az, ha a felhasználót erős 'zoknifiók-kulcsot' írja be minden eszközre; elveszíti azt, és elveszíti a titkokhoz való hozzáférést. A másik módszer az, hogy az adatokat egy származtatott kulcsba csomagoljuk, amely az adatokat kiteszi a fiók szolgáltató."

"Számos célunk volt itt" - folytatta Krstic. "A titkoknak minden eszközben rendelkezésre kell állniuk, erős titkosítással védve. A felhasználók még akkor is helyreállíthatják a titkokat, ha elveszítik az összes csatlakoztatott eszközt. Az adatok nem vannak kitéve az Apple hatásának, és nincs lehetőség brutális erőszakos támadásra."

A hitelesítés az alapvető iCloud kulcstartó rendszerben egyszerű. Minden eszköznek megvan a saját kulcspártja, és ahhoz, hogy új eszközt hozzáadhasson a szinkronizálási körhöz, jóvá kell hagynia egy meglévő eszközéből. Az Apple háttérprogramja nem vesz részt; nincs kiváltsága. Ha a felhasználó elveszíti az összes eszközhöz való hozzáférést, akkor a hozzáférést az iCloud biztonsági kulcs és az iCloud jelszó segítségével is meg lehet kapni.

Krstic nagyon részletesen kifejtette, hogy az Apple miként kezeli ezt a rendszert, anélkül hogy nyitva állna annak a legkisebb esélye, hogy bárki, beleértve az Apple bárkit, hozzáférhessen az adatokhoz a hátsó oldalról. A rendszer magában foglalja az úgynevezett admin kártyákat, amelyeket akkor hoztak létre, amikor egy új kriptoszerver-flottát üzembe helyeztek. "A rendszergazdai kártyákat egy biztonságos ünnepségen hozzák létre, amikor a flottát üzembe helyezik, és külön fizikai széfben tárolják az Apple három különböző szervezetének őrizetében, hamisításbiztos bizonyítékzsákokban" - mondta Krstic.

Ez a helyzet csak addig tart, amíg a flotta ténylegesen üzembe nem áll. Abban az időben, mondta Krstic, "Az admin kártyákat új, egyirányú hash-funkción keresztül vezettük be." Húzva egy egyértelműen használt turmixgépet a dobogó alól, folytatta: "Igen, út a turmixgépbe." Miután a titkosítási szerverek flottája aktív, azt semmilyen módon nem lehet frissíteni vagy módosítani, még az Apple sem, mert az admin kártyák megsemmisültek. Ha előfordul, hogy valóban frissítésre van szükség, az Apple-nek fel kell állítania egy új flottát, és el kell küldenie egy szoftverfrissítést, amely a felhasználói eszközöket csatlakoztatja az új flottához.

"Miért csináljuk ezt" - mondta Krstic. "Miért vesszük ezt az utolsó rendkívül szokatlan lépést? Nagyon nagy erőfeszítéseket teszünk a biztonsági rendszerek tervezésére, hogy bizalmat nyújtsunk. Amikor az adatok elhagyják az eszközt, a tét még magasabb. Meg kell őriznünk ezt a bizalmat. ezeket a rendszergazdai kártyákat, lehetséges, hogy ez nem igaz. Így vesszük komolyan a felhasználói adatokkal kapcsolatos küldetésünket."

Megkérdezte: "Megtette ezt az FBI információkérése miatt?" Krstic válaszolt: "Mérnök vagyok. Csak olyan kérdésekre tudok válaszolni, amelyek miatt ma bemutattam." Oké, elég tisztességes. De azt hiszem, hogy a kérdezőnek igaza volt. Az önálló rendszer létrehozása, amelyet még önmagát sem módosíthat, elég jó módja annak, hogy megakadályozzon valakit a nem kívánt változtatásoktól.

Remélem, hogy részletesebben átadtam Krstic beszélgetésének anélkül, hogy a szemét átgázoltam volna. A beszélgetés alapján, ahogy a csoport szétszóródott, a helyiség igazi bájt szintű biztonsági geeksgei nagy hatással voltak.