Az Apple ökoszisztémában megvalósított funkcióról készülő sorozatom ma újabb epizódhoz érkezett. Tovább fogok haladni az anyaggal, mely már nem csoportosítható olyan könnyen, így ma lesz szó egyedi billentyűzetről, iCloud-ról, MFi kiegészítőkről, meg ami most itt a bekezdésben nem jutott eszembe.
Alkalmazás telepítés és futtatás
Minden egyes alkalommal amikor egy új (vagy egy korábban letörölt) alkalmazást töltesz le az App Store-ból, akkor a telepítés során a rendszer egy véletlenszerűen kiosztott és létrehozott könyvtárat rendel hozzá. Az alkalmazás ebben a neki szánt könyvtárban tárolhatja az ügyes-bajos dolgait. Ennek biztonsági előnye az, hogy nem lehet a fájlrendszer struktúrájából származtatott támadást olyan könnyen megvalósítani, hiszen minden egyes alkalmazás máshol helyezkedik el. Technikailag és gyakorlatilag is ha egymás után kétszer telepíted ugyanazt az alkalmazást, teljesen máshol lesz a fájlrendszerben.
Természetesen az alkalmazások az operációs rendszeren belül egy olyan felhasználó nevében futnak, akinek nincs semmilyen adminisztratív jogosultsága (non-privileged user). Az operációs rendszer saját fájlrendszere egy teljesen eltérő helyen helyezkedik el, annak állományait csak olvasni lehetséges.
Address Space Layout Randomization (ASLR)
Amikor egy alkalmazás vagy folyamat adatokat kíván olvasni a memóriából, vagy abba írni, akkor az operációs rendszer az ASLR segítségével a memória címeket véletlenszerűen osztja ki a folyamatnak. Így nehezebben lehet egy támadónak kikövetkeztetnie azt, hogy az általa keresett információ hol található meg a memóriában. Ez rendszerindításonként folyamatosan változik. Természetesen az operációs rendszer maga is használja ezt a képességet, csak úgy mint a gyári alkalmazások és az Xcode-ban is alapértelmezetten be van kapcsolva.
ARM Execute Never
A memóriában megtalálható egyes területeket a rendszer megjelölheti egy úgy nevezett XN (Execute Never) bittel. Az XN bit beállítása után az érintett memóriaterületen tárolt gépi kódon végrehajtás nem lehetséges. Ezt a képességet az ARM architektúra vezette be.
Extension-ök és jogosultságok
Ha egy alkalmazás rendelkezik önálló bővítménnyel (például egy a Today oldalra kirakható bővítménnyel), akkor a bővítmény pontosan ugyanazokkal az alkalmazás jogosultságokkal fog rendelkezni, mint az őt tartalmazó alkalmazás. Tehát például a MyTelenor alkalmazással érkező bővítmény amelyben megtekinthető az aktuális fogyasztás, képes az adatok háttérben történő frissítésére mert megörökölte az alkalmazástól.
Egy speciális ilyen bővítmény az egyedi billentyűzet. Kivétel nélkül az összes ilyen megoldás azért kéri az “Open Access” hozzáférést, hogy olyan operációs rendszer nyújtotta képességhez is hozzáférhessen, amihez amúgy nincs joga (más operációs rendszer szinten fog futni).
Például feltelepíted a SwiftKey-t mert tök király a magyar szótára. Rögtön az 1. lépések egyike az lesz, hogy engedélyezd számára az Open Access-t. Ha nem adod meg, akkor például nem fog tudni szinkronizálni, mert az operációs rendszer minden kommunikációhoz használható végponttól elvágja mindaddig, amíg az Open Access nincs számára engedélyezve.
Az egyedi billentyűzetek az Open Access engedély ellenében sem használhatók a készülék illetve a SIM PIN megadásához szükséges képernyőn, a jelszó mezőkön, illetve semmilyen egyéb olyan operációs rendszer nyújtotta API végponton, amin keresztül esetlegesen a bevitt szöveg szűrhető és/vagy rögzíthető lenne.
Az egyedi billentyűzetek használatát nem csak az Apple szabályozhatja, hanem MDM rendszerbe bevont készüléken az MDM adminisztrátor, de akár az adott alkalmazást fejlesztő cég is (banki alkalmazások többnyire ide tartoznak).
MFi azaz Made for iPhone / iPad / iPod
Az MFi jelzéssel ellátott kiegészítők mindenféle probléma nélkül működnek az Apple eszközökkel. Ez egy tanúsítvány, amit az Apple bocsát ki a kiegészítő gyártójának, ha az megfelel az Apple követelményeinek. Maga a tanúsítvány nem csak a Lightning csatlakozóval szerelt eszközökre vonatkozik, hanem a Bluetooth illesztéssel rendelkezőkre is, bár vitathatatlan, hogy előbbivel gyakrabban találkozunk.
Ahhoz, hogy a kiegészítő működjön az eszközzel, egy hitelesítési folyamaton át kell esnie, amelyet az iOS / iPadOS eszköz kezdeményez. Ezt a hitelesítési folyamatot a kiegészítőben megtalálható speciális IC teszi lehetővé, amelyet az Apple gyárt. A hitelesítési folyamat a következő lépésekből áll:
- Az iPhone / iPad megkéri a kiegészítőt, hogy bizonyítsa, az Apple által kiadott engedéllyel rendelkezik-e.
- Ha igen, akkor egy challenge-t (kérdést) küld neki, amire a kiegészítőnek egy hitelesített válasszal kell reagálnia.
- Ezt a választ az iOS / iPadOS ellenőrzi és ha mindent rendben talál, akkor mehet a buli.
Ha a kiegészítő bármelyik előbbi lépésen megbukik, akkor az illesztés csak és kizárólag az Universal Asynchronous Receiver-Transmitter (UART) interfész egy csökkentett részéhez fér hozzá, ami a következő kontrollokat teszi elérhetővé:
- analóg hang,
- hangerő szabályzás,
- lejátszás / Stop / szünet / előző – következő szám.
Az MFi képesítéssel rendelkező eszköz és az iPhone / iPad eszközök között a kapcsolat titkosított, a titkosítást az IC saját 1024 bites RSA kulccsal végzi. Ugyanerre a kommunikációs folyamatra épül az AirPlay és a CarPlay is.
Jelszóval védett jegyzet
Amikor jelszóval kívánunk levédeni egy jegyzetet a Jegyzetek (Notes) alkalmazásban, akkor első lépésként meg kell adnunk egy jelszót, ami nem ugyanaz, mint ami a készülék jelkódja. A megadott jelszóból a rendszer egy 16 byte-os kulcsot derivál, majd ezzel a kulccsal a teljes jegyzetet (beleértve a csatolmányokat is) titkosítja. Sikeres titkosítás esetén az eredeti jegyzetet törli a rendszer.
A titkosított jegyzetek több eszköz esetén végponttól – végpontig titkosítva vannak. A Notes appnak 3 percnél kell tovább a háttérben lennie, hogy a feloldott jegyzeteket automatikusan visszazárja. A megadott jelszót a beállításokban alaphelyzetbe lehet állítani, de ebben az esetben a korábban lezárt jegyzetek nem nyithatóak már meg. Szóval ha elfelejtjük a beállított jelszót akkor ezeknek a jegyzeteknek reszeltek. 😀
iCloud
Amikor fájlokat töltünk fel az iCloud-ba, a rendszer feltöltéskor bizonyos méretű szeletekre bontja a fájlt. Ezek a szeleteket AES 128-cal titkosítja, a hozzá tartozó SHA-256 kulcsot pedig az adott szelet tartalmából deriválja. A kulcsokat az Apple ID iCloud fiókban tárolja el. Így biztosítható az integritása a fájloknak, valamint az iCloud szolgáltatás mögött használt 3rd party szolgáltatók (Google Cloud Platform és Amazon Web Services) sem képesek az ott tárolt adatokat olvasni.
Amikor a készülékről egy mentést készítünk az iCloud-ba, akkor az Apple ID fiókunk jelszónak semmi köze a titkosított mentéshez, éppen ezért állítható vissza gond nélkül a mentés másik készülékre (ha az Apple ID bejelentkezés sikeres volt).
Az iCloud mentés tartalma egyébként:
- készüléken lévő videók és fotók (iCloud Photo Library-től független)
- névjegyek, naptáresemények, jegyzetek, emlékeztetők,
- eszköz beállítások,
- alkalmazás adatok,
- medical ID,
- HomeKit beállítások,
- üzenetek (ha nincs bekapcsolva a Messages in Cloud szinkronizáció)
A Messages in Cloud pedig akkor is visszatölthető, ha a készüléket nem mentésből állították vissza, mert a titkosításhoz használt kulcsot az iCloud Backup-ban (ha van) és a Keychain-ben is tárolja (márpedig a kettőből egy legalább létezik).
A bejegyzés kiemelt képét készítette:
Matt Seymour
