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 keychain az a témakör, amivel kapcsolatban sok esetben még a tapasztalt iOS-es fejlesztők sincsenek teljesen képben. Ez egyrészt betudható annak, hogy az Apple igencsak csínján bánik a fejlesztőknek szóló, biztonságról szóló dokumentációval, pedig találni egy-két érdemi whitepapert és konferenciaelőadást, meg pár könyvet a témában.

Kezdjük az alapokkal. A keychain egy védett tároló, amit oprendszerszintű kontrollok védenek és arra szolgál, hogy mindenféle védendő adatot aggassanak rá. Egyrészt használja maga az iOS is pl. a wifi kulcsok tárolására, de az utólag telepített alkalmazások is pakolhatnak rá. A megtervezésekor követett alapgondolat az volt, hogy titkosítottan történik az adatok tárolása és csak a megfelelően feljogosított alkalmazások olvashatják ki a saját maguk által felpakolt adatokat, illetve azokat, amikhez hozzáférhetnek.

A keychain API (a Data Protection API része) egy sereg lehetőséget és beállítást biztosít arra, hogy milyen módon korlátozzák a fejlesztők a kulcsok és a ráaggatott kulcsok használhatóságát. Például:

• kSecAttrAccessibleAlways: az adott kulcs mindig elérhető
• kSecAttrAccessibleWhenUnlocked: az adott kulcs csak akkor elérhető, ha az eszközön fel van oldva a screen lock
• kSecAttrAccessibleAfterFirstUnlock: a kulcs akkor érhető csak el, ha az eszköz bekapcsolása óta legalább egyszer feloldották a screen lockot. Az ellen jelent némi védelmet, hogy a támadó újraindítja az eszközt és úgy próbál cigánykodni
• Mindezek mellé még betehető a ThisDeviceOnly kitétel az egyes attribútumok végére (Apple API nomenklatúra FTW), ami annyit jelent, hogy a keychain adott bejegyzése nem hagyhatja el az eszközt, nem migrálható másik eszközre. Pl. kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly.

Hogy azonosítják magukat az alkalmazások az iOS számára? Mi van akkor, ha új verziót küldtünk ki a marketre, aminek el kéne érnie a régi által odapakolt kulcsokat? A megoldás nagyon (már-már arcpirítóan) egyszerű: az alkalmazásokhoz tartozó Provisioning Profile-ban van benne azon kulcsok listája, amikhez az alkalmazás hozzáférhet. Például:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN”
“http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>application-identifier</key>
<string>hu.Whatever.BlahApp</string>
<key>get-task-allow</key>
<true/>
<key>keychain-access-group</key>
<array>
<string>hu.Whatever.BlahApp</string>
</array>
</dict>
</plist>

A keychaint nem érdemes nagyon túlmisztifikálni: egy tök mezei sqlite3 adatbázisról van szó, ami a /var/Keychains könyvtárban lakik. Ami a titkosítást illeti, a tényleges titkosító kulcs a felhasználó PIN-jéből/jelszavából jön és ha nincs beállítva ilyen, akkor ismert és statikus. Amikor mentést készítünk az eszközről, a keychain tartalma kis kiíródik, de titkosítva ezzel a kulccsal. Jailbreakelt eszköznél hozzá lehet férni magához az sqlite adatbázishoz fájlszinten is.

Érdemes megjegyezni, hogy a keychain tartalma nem része a telepítési csomagnak, azaz amikor az app felkúszik egy szűz eszközre, az általa használt keychain az első indításig mindenképpen üres lesz. Sőt, ha átvisszük a telepítőt egy másik eszközre, akkor a keychain tartalma marad a helyén a régi eszközön. Ezt érdemes észben tartani, amikor kulcsok meglétét (és tartalmát) ellenőrizzük és például jelszóhash-t tárolunk bennük.

Ami fontos:

1. A keychain nem nyújt védelmet, ha az eszköz jailbreakelt. Itt a tool, amivel ki lehet nyerni mindent.
2. A keychain nem ér semmit, ha nincs PIN vagy ha gyenge.