Appleplatformbiztonság tavasza

Átírás

1 Appleplatformbiztonság 2020 tavasza

2 Tartalom Bevezetés az ba 5 Elköteleződés a biztonság mellett 6 Hardverbiztonság és biometrika 8 A hardverbiztonság áttekintése 8 Secure Enclave 9 Dedikált AES-motor 10 Touch ID és Face ID 12 A mikrofon hardveres leválasztása a Mac gépen és ipaden 18 Expressz kártya energiatakarékos móddal az iphone-ban 18 Rendszerbiztonság 19 A rendszerbiztonság áttekintése 19 Véletlenszám-generátor 19 Biztonságos rendszerindítás 20 Biztonságos szoftverfrissítések 30 Az operációs rendszer integritása az ios és ipados rendszer esetén 31 Az operációs rendszer integritása a macos rendszer esetén 33 Rendszerbiztonság a watchos rendszerben 40 Titkosítás és Data Protection 43 A titkosítás és a Data Protection áttekintése 43 A felhasználók személyes adatainak védelme az Apple által 43 Az Apple File System szerepe 44 A Data Protection az ios és ipados rendszerben 45 Titkosítás a macos rendszerben 51 Jelkódok és jelszavak 58 Hitelesítés és digitális aláírás 60 Kulcstartók 62 2

3 Alkalmazásbiztonság 66 Az alkalmazásbiztonság áttekintése 66 Alkalmazásbiztonság az ios és ipados rendszerben 67 Alkalmazásbiztonság a macos rendszerben 73 Biztonsági funkciók a Jegyzetek alkalmazásban 77 Biztonsági funkciók a Parancsok alkalmazásban 78 Szolgáltatásbiztonság 79 A szolgáltatásbiztonság áttekintése 79 Apple ID és felügyelt Apple ID 79 icloud 82 Jelkód- és jelszókezelés 85 Apple Pay 92 imessage 107 Csevegés vállalkozásokkal 110 FaceTime 111 Lokátor 111 Átjárhatóság 115 Hálózati biztonság 119 A hálózati biztonság áttekintése 119 TLS hálózati biztonság 119 Virtuális magánhálózatok (VPN-ek) 121 Wi-Fi-biztonság 122 Bluetooth-biztonság 125 Ultraszéles sávú technológia 127 Egyszeri bejelentkezés 127 AirDrop-biztonság 128 Wi-Fi-jelszavak megosztása 129 A macos tűzfala 130 Fejlesztői készletek 131 A fejlesztői készletek áttekintése 131 HomeKit 131 HealthKit 137 CloudKit 139 SiriKit 140 DriverKit 141 ReplayKit 141 Kamera és ARKit 143 3

4 Biztonságos eszközfelügyelet 144 A biztonságos eszközfelügyelet áttekintése 144 Párosítási modell 144 A jelkód és a jelszó beállításainak kezelése 145 Konfiguráció kényszerítése 146 Mobileszköz-felügyelet (MDM) 147 Automatizált eszközfelíratás 148 Apple Configurator Eszközkoordináció 150 Eszközkorlátozások 150 Aktiválási zár 150 Elveszett mód, távoli törlés és távoli zárolás 152 Megosztott ipad 153 Képernyőidő 154 Az Apple biztonsági és adatvédelmi tanúsítványai 157 Az Apple biztonsági és adatvédelmi tanúsítványainak áttekintése 157 Apple védelmi biztonság 158 Szójegyzék 161 A dokumentum módosításának előzményei 166 4

5 Bevezetés az ba Az Apple a biztonságot a platformjainak középpontjába tervezi. Az Apple a világ legfejlettebb mobil operációs rendszerének létrehozásában szerzett tapasztalatára építve olyan biztonsági architektúrákat hozott létre, amelyek megfelelnek a mobileszközök, órák, asztali számítógépek és otthoni eszközök sajátos követelményeinek. Minden Apple-eszközben összefonódik az együttműködésre tervezett hardver, szoftver és a szolgáltatások, hogy maximális legyen a biztonság, és átlátható legyen a felhasználói élmény a személyes információk biztonságban tartásának céljából. A kritikus biztonsági funkciókat egyéni biztonsági hardver látja el. A szoftveres védelmek gondoskodnak az operációs rendszer és a külső alkalmazások biztonságáról. A szolgáltatások mechanizmust nyújtanak a biztonságos és időbeni szoftverfrissítéseknek, biztonságosabb alkalmazásökoszisztémát működtetnek, biztonságossá teszik a kommunikációt és a fizetéseket, és gondoskodnak a biztonságos felhasználói élményről az interneten. Az Apple-eszközök nem csupán az eszközt és a rajta lévő adatokat védik, hanem a teljes ökoszisztémát, beleértve az összes olyan műveletet, amelyet a felhasználók helyben, a hálózaton és a fő internetszolgáltatások segítségével végeznek el. A termékeink tervezésekor az egyszerűség, az intuitív használat és a teljesítmény pont annyira fontos szempont, mint a biztonság. A főbb biztonsági funkciók, mint a hardveres eszköztitkosítás, nem kapcsolhatók ki véletlenül. Más funkciók, például a Touch ID és a Face ID azáltal javítják a felhasználói élményt, hogy egyszerűbbé és intuitívabbá teszik az eszköz védelmét. Mivel pedig számos ilyen funkció alapértelmezésben be van kapcsolva, a felhasználóknak vagy IT-osztályoknak nem kell hosszadalmas konfigurálásokat végezniük. Jelen dokumentáció azzal kapcsolatban nyújt részleteket, hogy a biztonsági technológiák és funkciók hogyan vannak implementálva az Apple-platformokon belül. Segít továbbá a szervezeteknek, hogy az Apple platformbiztonsági technológiáját és funkcióit a saját irányelveikkel és eljárásaikkal kombinálják, és így megfeleljenek a speciális biztonsági igényeknek. A tartalom a következő témakörökre oszlik: Hardverbiztonság és biometrika: Az Apple-eszközök biztonságának alapját képező hardver, beleértve a Secure Enclave processzort, a különálló AES titkosítási motort, a Touch ID-t és a Face ID-t. Rendszerbiztonság: Azok az integrált hardveres és szoftveres funkciók, amelyek az Apple operációs rendszerein gondoskodnak a rendszerindítás, frissítés és folyamatos működés biztonságáról. Titkosítás és Data Protection: Az az architektúra és kialakítás, amely védi a felhasználói adatokat, ha az eszköz elvész vagy ellopják, illetve ha illetéktelen személy vagy folyamat próbálja meg használni vagy módosítani. 5

6 Alkalmazásbiztonság: Azok a szoftverek és szolgáltatások, amelyek biztonságos alkalmazás-ökoszisztémát nyújtanak, és lehetővé teszik, hogy az alkalmazások biztonságosan, a platformintegritást nem veszélyeztetve fussanak. Szolgáltatásbiztonság: Apple-szolgáltatások azonosításhoz, jelszókezeléshez, fizetésekhez, kommunikációhoz és az elveszett eszközök megtalálásához. Hálózati biztonság: Olyan iparági szabványnak számító hálózati protokollok, amelyek gondoskodnak a biztonságos hitelesítésről és az adatok titkosításáról átvitel közben. Fejlesztői készletek: Ezek a keretrendszerek gondoskodnak az otthon és az egészség biztonságos és privát felügyeletéről, valamint külső alkalmazásokra is kiterjesztik az Apple eszközeinek és szolgáltatásainak képességeit. Biztonságos eszközfelügyelet: Az itt bemutatott módszerek lehetővé teszik az Appleeszközök felügyeletét, a jogosulatlan használat megelőzését és a távoli törlést, ha az eszköz elveszne, vagy ellopnák. Biztonsági és adatvédelmi tanúsítványok Az ISO-tanúsítványokra, kriptográfiai érvényesítésre, Common Criteria-tanúsítványra és a Commercial Solutions for Classified (CSfC) programra vonatkozó információk. Elköteleződés a biztonság mellett Az Apple elkötelezett amellett, hogy (a személyes adatok védelmére tervezett) kiemelkedő adatvédelmi és biztonsági technológiákkal és (a nagyvállalati környezetben található vállalati adatokat őrző) átfogó eljárásokkal védje az ügyfeleit. Az Apple az Apple biztonsági díjjal jutalmazza a kutatókat azért a munkáért, amelyet a sebezhetőségek feltárásába fektetnek. A program részleteit és a díjkategóriákat a security-bounty/ weboldalon találja meg. Külön biztonsági csoportot tartunk fenn az összes Apple-termék támogatására. A csoport mind a fejlesztés alatt álló, mind a már kiadott termékekhez biztonsági auditot és tesztelést nyújt. Az Apple csoportja ezenkívül biztonsági eszközöket és képzéseket is nyújt, és aktívan figyeli az új biztonsági problémákra vonatkozó veszélyeket és jelentéseket. Az Apple a Forum of Incident Response and Security Teams (FIRST) tagja. Az Apple továbbra is feszegeti a határokat a biztonság és adatvédelem lehetőségeinek terén. A Lokátor például meglévő kriptográfiai primitívek használatával teszi lehetővé az offline Mac gép elosztott megkeresésének úttörő funkcióját anélkül, hogy bárkinek, beleértve az Apple-t is, felfedné a folyamatban érintett felhasználók személyazonosságát vagy tartózkodási helyét. A Mac gép firmware-e biztonságának növelése érdekében az Apple felhasználta az oldaltáblákat, hogy a rendszerindítási folyamat olyan korai szakaszában letiltsa a perifériáktól érkező illetéktelen hozzáférést, amikor a RAM még nem töltődik be. Mivel a támadók egyre kifinomultabb technikákkal próbálnak visszaélni, az Apple dinamikusan szabályozza az iphone és ipad memória-végrehajtási jogosultságait, más mobileszközöknek el nem érhető egyéni CPU-utasításokat hasznosítva a rendszer kompromittálásának megakadályozására. Az új biztonsági funkciók kifejlesztése mellett ugyanilyen fontos, hogy az új funkciók fejlesztésének középpontjában a személyes adatok védelme és a biztonság áll. Annak érdekében, hogy a legtöbbet hozhassák ki a platformokba épített, kiterjedt biztonsági funkciókból, arra biztatjuk a szervezeteket, hogy az IT- és biztonsági irányelveik áttekintésével gondoskodjanak arról, hogy maximálisan kihasználják a platformok által kínált biztonságtechnológiai rétegeket. 6

7 Ha további információt szeretne arról, hogyan jelenthet problémákat az Apple-nek, és hogyan iratkozhat fel a biztonsági értesítésekre, tekintse meg a következőt: Biztonsági vagy adatvédelmi rés bejelentése. Az Apple hisz abban, hogy a személyes adatok védelme alapvető emberi jog, és számos beépített vezérlőt és beállítást biztosít, amelyekkel a felhasználók eldönthetik, hogyan és mikor használhatják az alkalmazások az információikat, valamint milyen információkat használhatnak. Az Apple adatok védelmével kapcsolatos megközelítéséről, az Apple-eszközökön található adatvédelmi vezérlőkről és az Apple adatvédelmi szabályzatáról további információkat a oldalon talál. Megjegyzés: Ha másképp nincs jelölve, akkor ez a dokumentáció a következő operációsrendszer-verziókra vonatkozik: ios 13.4, ipados 13.4, macos , tvos 13.4 és watchos

8 Hardverbiztonság és biometrika A hardverbiztonság áttekintése A biztonságos szoftvernek a hardverbe épített biztonsági alapokra van szüksége. Az Apple-eszközöknél ezért, legyen szó ios, ipados, macos, watchos vagy tvos rendszerről, a biztonsági funkciók a lapkákba vannak tervezve. Ezek magukban foglalják a rendszerbiztonsági funkciókat működtető egyéni CPU-képességeket és a biztonsági funkciókra tervezett lapkákat. A legfontosabb komponens a Secure Enclave társprocesszor, amely az összes modern ios-, ipados-, watchos- és tvos-eszközben, valamint az Apple T2 Security chippel szerelt összes Mac gépben megjelenik. A Secure Enclave biztosítja az alapokat a tárolt adatok titkosításához, a macos biztonságos rendszerindításához és a biometrikai funkciókhoz. Az összes modern iphone, ipad, valamint a T2 chippel szerelt Mac gépek dedikált AEShardvermotort tartalmaznak, amely a hátteret nyújtja a késleltetés nélküli titkosításhoz a fájlok írása és olvasása közben. Ez gondoskodik arról, hogy a Data Protection és a FileVault megóvja a felhasználó fájljait anélkül, hogy felfedné a hosszú élettartamú titkosítási kulcsokat a CPU-nak vagy az operációs rendszernek. Ha további információra kíváncsi azzal kapcsolatban, hogy melyik Apple-hardver tartalmazza a Secure Enclave processzort, tekintse meg a következő részt: A Secure Enclave áttekintése. Az Apple-eszközök biztonságos rendszerindítása gondoskodik arról, hogy a szoftverek legalacsonyabb szintje nincs illetéktelenül módosítva, és indításkor csak az Apple-től származó megbízható operációsrendszer-szoftver töltődik be. ios- és ipados-eszközök esetén a biztonság a rendszerindító ROM nevű, nem módosítható kóddal kezdődik, amely a chip gyártása közben kerül a helyére, és a megbízhatóság hardveres gyökereként ismert. A T2 chippel szerelt Mac gépek esetén a biztonságos rendszerindítás megbízhatósága magával a T2 chippel kezdődik. (A T2 és a Secure Enclave is végrehajtja a saját biztonságos rendszerindítási folyamatait.) A Secure Enclave engedélyezi az Apple-eszközök Touch ID és Face ID funkcióját, amelyekkel a felhasználó biometrikus adatainak biztonságos tárolása mellett nyújt biztonságos hitelesítést. Ennek köszönhetően a felhasználókat hosszabb és komplexebb jelkódok és jelszavak őrzik, ugyanakkor számtalan helyzetben élvezhetik a gyors hitelesítés kényelmét. Az Apple-eszközök biztonsági funkcióit a kizárólag az Apple által elérhető lapkaterv, hardver, szoftver és szolgáltatások kombinációja teszi lehetővé. 8

9 Secure Enclave A Secure Enclave áttekintése A Secure Enclave egy olyan hardveralapú kulcskezelőt tartalmazó biztonsági segédprocesszor, amely el van szigetelve a fő processzortól, hogy a biztonság egy további rétegét nyújthassa. A Secure Enclave az iphone, az ipad, a Mac gép, az Apple TV, az Apple Watch és a HomePod bizonyos verzióinak hardveres funkciója; ezek a verziók következők: iphone 5s (vagy újabb) ipad Air (vagy újabb) A T1 chippel vagy Apple T2 Security chippel szerelt Mac gépek 4. generációs vagy újabb Apple TV Apple Watch Series 1 (vagy újabb) HomePod A kulcsadatok titkosítva vannak a Secure Enclave egylapkás rendszerében (SoC), amely véletlenszám-generátort is tartalmaz. A Secure Enclave akkor is megtartja kriptográfiai műveleteinek integritását, ha az eszköz kernelét feltörik. A Secure Enclave és az alkalmazásprocesszor közötti kommunikáció szigorúan szabályozva van azáltal, hogy megszakításvezérelt postafiókra és megosztott memóriaadat-pufferekre van korlátozva. A Secure Enclave processzor. Külön Boot ROM és visszajátszás-ellenes szolgáltatások Dedikált rendszerindítási ROM A Secure Enclave tartalmaz dedikált Secure Enclave rendszerindítási ROM-ot. Az alkalmazásprocesszor rendszerindítási ROM-jához hasonlóan a Secure Enclave rendszerindítási ROM-ja sem módosítható kód, amely a megbízhatóság hardveres gyökerét alakítja ki a Secure Enclave számára. Ez az összetevő futtat egy egyéni L4-es mikrokernelen alapuló Secure Enclave OS-t is. A Secure Enclave operációs rendszert az Apple írja alá, a Secure Enclave rendszerindítási ROM ellenőrzi, és testreszabott szoftverfrissítési folyamaton keresztül frissül. 9

10 Amikor az eszköz elindul, a Secure Enclave rendszerindítási ROM-ja rövid élettartamú memóriavédelmi kulcsot hoz létre, amelyet összecsomóz az eszköz egyedi azonosítójával (UID), és ez a kulcs titkosítja az eszköz memóriaterében a Secure Enclave részét. Az Apple A7 kivételével a memóriavédelmi kulcs a Secure Enclave-memóriát is hitelesíti. A11 (és újabb) és S4 SoC-k esetén integritásfa gátolja meg a biztonsági szempontból kritikus Secure Enclave-memória visszajátszását, és ezt a fát a chipre szerelt SRAM-ban tárolt memóriavédelmi kulcs és nonce-ok hitelesítik. Az ios és az ipados rendszeren a fájlok a Secure Enclave UID-jával és visszajátszást gátló nonce-szal összekapcsolt kulccsal vannak titkosítva az adatkötetre való íráskor. A9 (és újabb) SoC-k esetén a visszajátszást gátló nonce a hardveres véletlenszám-generátor által generált entrópiát használja. A visszajátszást gátló nonce támogatása egy dedikált, nem felejtő memóriájú integrált áramkörben (IC) van. Az Apple T2 Security Chippel rendelkező Mac gépek esetén a FileVault kulcshierarchiája hasonlóan hozzá van kötve a Secure Enclave UID-jához. A12 (és újabb) és S4 SoC-vel szerelt eszközök esetén a Secure Enclave össze van párosítva biztonságos tárolójú integrált áramkörrel a visszajátszást gátló nonce tárolásához. A biztonságos tárolójú integrált áramkör nem módosítható ROM-kóddal, véletlenszámgenerátorral, kriptográfiai motorokkal és az illetéktelen fizikai módosítás észlelésének képességével rendelkezik. A nonce-ok olvasásához és frissítéséhez a Secure Enclave és a tároló integrált áramkör olyan biztonságos protokollt alkalmaz, amely biztosítja a nonce-ok kizárólagos elérését. Visszajátszást gátló szolgáltatások A Secure Enclave visszajátszás elleni szolgáltatásaival visszahívhatók az adatok olyan eseményekből, amelyek a visszajátszás-ellenes határokat jelzik. Ilyenek többek között: Jelkód módosítása A Touch ID vagy a Face ID engedélyezése vagy letiltása Touch ID-ujjlenyomat vagy Face ID-arc hozzáadása vagy eltávolítása A Touch ID vagy a Face ID visszaállítása Apple Pay-kártya hozzáadása vagy eltávolítása Összes tartalom és beállítás törlése Dedikált AES-motor A Secure Enclave processzorral rendelkező minden Apple-eszköz rendelkezik dedikált AES-256 kriptográfiai motorral, amely a flash-tároló és a fő rendszermemória közötti DMA-útba van építve, így a fájltitkosítás rendkívül hatékony. Az A9 vagy újabb A-sorozatú processzorok esetében a flash-tároló elszigetelt buszon van, amely csak a DMA kriptográfiai motoron keresztül fér hozzá a felhasználói adatokat tartalmazó memóriához. A Secure Enclave biztonságosan generálja a saját kulcsait egyedi azonosítókat (UID-k), az eszköz csoportazonosítóit (GID-k) és másokat, és szükség esetén biztonságosan törli a mentett kulcsokat. Ezek a kulcsok AES-256 bites kulcsok, amelyek gyártás során bele vannak égetve (az UID) vagy fordítva (a GID) a Secure Enclave processzorba. Sem szoftver, sem firmware nem képes ezeket közvetlenül olvasni; csak az olyan titkosítási vagy visszafejtési művelet eredményét láthatják, amelyet a lapkába épített dedikált AES-motorok adnak, amikor ezeket az UID-kat vagy GID-kat használják kulcsként. 10

11 Mind az alkalmazásprocesszor, mind a Secure Enclave processzor saját UID-val és GID-val rendelkezik, és a Secure Enclave UID-ját és GID-ját a Secure Enclave dedikált AES-motorja használhatja. A UID-k és GID-k nem érhetők el sem a Joint Test Action Group (JTAG), sem más hibakereső interfészek használatával. Az AES kriptográfiai motor támogatja a késleltetés nélküli titkosítást a DMA-úton az Apple T2 Security chippel szerelt Mac gépek esetén. Kriptográfiai kulcsok generálása Minden egyes Secure Enclave generálja a saját UID-ját (egyedi azonosítóját) a gyártási folyamat során. Mivel a UID egyedi minden eszközön, és mivel teljes mértékben a Secure Enclave processzoron belül generálódik, nem pedig az eszközön kívüli gyártási rendszerben, a UID nem érhető el, és nem is tárolható sem az Apple, sem valamely beszállítója által. Ez az Apple A8 processzor utáni minden SoC-re érvényes. A Secure Enclave processzoron futó szoftver felhasználja a UID-t az eszközspecifikus titkok védelméhez. A UID segítségével az adatok kriptográfiailag egy adott eszközhöz köthetők. A fájlrendszert védő kulcshierarchia például tartalmazza a UID-t, így ha a belső SSD-tároló fizikailag másik eszközre kerül, a fájlok nem lesznek elérhetők. A UID nem kapcsolódik az eszköz semelyik másik azonosítójához. Egyéb védett, eszközspecifikus titkok közé tartoznak a Touch ID és Face ID adatai. Az Apple T2 Security chiphez nem csatlakoztatott eszközökön lévő tárolók nem kapják meg ezt a szintű titkosítást. Például az USB-n csatlakoztatott külső tárolóeszközök és a 2019-es Mac Próhoz hozzáadott PCIealapú tárolók sincsenek a T2-es chippel titkosítva. Eszközszinten az eszközcsoport-azonosító (GID) található, amely közös egy adott eszközosztály összes processzorában (például az Apple A8 processzort használó összes eszköz). A UID-n és GID-n kívül az ios- és ipados-eszközök összes egyéb kriptográfiai kulcsát a rendszer véletlenszám-generátora (RNG) hozza létre a CTR_DRBG-n alapuló algoritmus használatával. A rendszer entrópiája a rendszerindításkor bekövetkező időzítési variációkból generálódik, amelyhez hozzáadódik az eszköz rendszerindítása utáni megszakított időzítés. A Secure Enclave processzoron belül generált kulcsok annak valódi, hardveres véletlenszám-generátorát használják; ez többszörös gyűrűs oszcillátoron alapul, amelynek jelét CTR_DRBG dolgozza fel utólag. 11

12 Adatok biztonságos törlése A mentett kulcsok biztonságos törlése éppannyira fontos, mint a generálásuk. Ez különösen nagy kihívást jelent a flash-tárolók esetén, ahol az elhasználódás kiegyenlítése miatt az adatok több példányát is törölni kell. A probléma megoldása érdekében a Secure Enclave processzorral szerelt eszközök rendelkeznek egy elvethető tárhely nevű dedikált funkcióval, amelynek célja az adatok biztonságos törlése. Ez a funkció hozzáfér a mögöttes tárolótechnológiához (például NAND), hogy nagyon alacsony szinten közvetlenül megcímezhessen és törölhessen néhány blokkot. Touch ID és Face ID A Touch ID és a Face ID áttekintése A jelkódok és jelszavak kritikus fontosságúak az Apple-eszközök biztonságában, de a felhasználóknak gyorsan hozzá kell tudniuk férni az eszközeikhez, akár naponta százszor is. A biometrikus hitelesítés lehetővé teszi az erős jelkód megtartását vagy akár meg is erősíti a jelkódot vagy jelszót, mivel azt nem kell gyakran megadni, miközben egy ujjmozdulattal vagy pillantással biztosítja a gyors feloldás kényelmét. A Touch ID és a Face ID nem váltja le a jelszót vagy a jelkódot, de a legtöbb esetben gyorsabbá és egyszerűbbé teszi a hozzáférést. Touch ID-biztonság A Touch ID egy ujjnyomérzékelő rendszer, amely segítségével gyorsabban és könnyebben férhet hozzá a támogatott Apple-eszközökhöz. A technológia bármely szögből beolvassa az ujjnyomadatokat, és idővel egyre többet tanul meg a felhasználó ujjnyomáról, ugyanis az érzékelő bővíti az ujjnyom térképét, ahogy az egyes használatokkal egymást fedő csomópontokat észlel. A Touch ID érzékelővel rendelkező Apple-eszközök feloldhatók ujjnyom segítségével. A Touch ID nem helyettesíti az eszköz jelkódját vagy a felhasználói jelszót; ezekre továbbra is szükség van az eszköz indítása, újraindítása, illetve Mac gépen a kijelentkezés után. Bizonyos alkalmazásokban a Touch ID is használható az eszköz jelkódja vagy a felhasználói jelszó helyett például jelszóval védett jegyzetek feloldásához a Jegyzetek alkalmazásban, a kulcskarika által védett webhelyek feloldásához és a támogatott alkalmazások jelszavainak feloldásához. Bizonyos helyzetekben azonban az eszköz jelkódja vagy a felhasználó jelszava mindig szükséges. Ilyen például, ha módosítani szeretné a meglévő eszközjelkódot vagy felhasználói jelszót, vagy ha el szeretné távolítani a meglévő ujjnyomregisztrációkat, vagy újakat szeretne létrehozni. 12

13 Amikor az ujjnyomérzékelő ujj érintését észleli, aktiválja a fejlett képalkotó tömböt, hogy olvassa be az ujjnyomot, és elküldi a beszkennelt képet a Secure Enclave processzornak. A processzor és a Touch ID érzékelő közötti kommunikáció soros periferiális interfészbuszon keresztül zajlik. A processzor továbbítja az adatokat a Secure Enclave processzornak, de nem tudja olvasni azokat. Olyan munkameneti kulccsal van titkosítva és hitelesítve, amely az egyes Touch ID érzékelőhöz és az annak megfelelő Secure Enclave processzorhoz a gyártás során készült megosztott kulcs használatával jön létre. A megosztott kulcs erős, véletlenszerű, és minden egyes Touch ID esetében különbözik. A munkameneti kulcsegyeztetés AES-kulcscsomagolást használ; ennek során mindkét oldal véletlenszerű kulcsot biztosít, amely kialakítja a munkameneti kulcsot, és AES-CCM átviteli titkosítást használ. A rendszer a raszterképet, miközben vektorképet állít elő belőle az elemzéshez, átmenetileg a Secure Enclave processzoron belüli titkosított memóriában tárolja, azután pedig elveti. A rendszer az elemzéskor a bőrlécirány szögének hozzárendeléséhez a bőr alatti réteget használja; ez veszteséges folyamat, amely során a felhasználó tényleges ujjnyomának visszaállításához szükséges részletadatok elvesznek. Az eredményként kapott csomóponttérkép titkosított formában, személyazonossági adatok nélkül tárolódik, és csak a Secure Enclave képes olvasni. Ezek az adatok soha nem hagyják el az eszközt. Nem kapja meg őket az Apple, és az eszközről készült biztonsági mentésbe sem kerülnek bele. Face ID-biztonság A Face ID használatával egyetlen pillantással biztonságosan feloldhatók a támogatott Apple-eszközök. A TrueDepth kamerarendszer által lehetővé tett, intuitív és biztonságos hitelesítési módot kínál; ez a rendszer a fejlett technológiáinak köszönhetően biztonságosan leképezi a felhasználó arcának geometriáját. A Face ID neurális hálózatok segítségével határozza meg a figyelmet, az egyezést, és védi ki a csalást, így a felhasználó egyetlen pillantással feloldhatja az eszközt. A Face ID automatikusan adaptálódik a megjelenésbeli változásokhoz, és gondosan őrködik a felhasználó biometrikus adatainak védelme és biztonsága felett. A Face ID úgy lett kialakítva, hogy meggyőződjön a felhasználói figyelemről, robusztus hitelesítést nyújtson alacsony hibás egyezési aránnyal, és csökkentse mind a digitális, mind a fizikai csalás lehetőségét. A TrueDepth kamera automatikusan keresi a felhasználó arcát, amikor az a Face IDval rendelkező Apple-eszközt felemeli, vagy a képernyőjére koppint, hogy felébressze, valamint akkor is, amikor ezek az eszközök megpróbálják hitelesíteni a felhasználót, hogy bejövő értesítést jeleníthessenek meg, illetve amikor egy támogatott alkalmazás Face ID-hitelesítést kér. Arc érzékelésekor a Face ID meggyőződik a figyelemről és a feloldás szándékáról azáltal, hogy észleli, hogy a felhasználó szeme nyitva van, és az eszközre irányul a figyelme; a kisegítő lehetőségek használhatóságáért ez a funkció ki van kapcsolva, ha a VoiceOver be van kapcsolva, és szükség esetén külön is kikapcsolható. 13

14 A TrueDepth kamera, miután meggyőződött a figyelő arc jelenlétéről, több mint infravörös pontot bocsát ki és olvas be az arc mélységtérképéről, továbbá egy kétdimenziós infravörös térképet is. Ezekből az adatokból kétdimenziós képek és mélységtérképek jönnek létre, amelyeket a rendszer digitálisan aláír, és elküld a Secure Enclave processzornak. A digitális és fizikai csalások elkerülése érdekében a TrueDepth kamera randomizálja a kétdimenziós képek és mélységtérképek sorrendjét, és eszközspecifikus véletlenszerű mintát vetít ki. A SoC neurális motorjának egy része amely a Secure Enclave processzoron belül van védve matematikai reprezentációvá alakítja az adatokat, és összehasonlítja ezt a reprezentációt a regisztrált arcadatokkal. A regisztrált arcadat maga is egy matematikai reprezentáció, amely a felhasználó arcának számos pózból készült felvételeiből készül. Touch ID, Face ID, jelkódok és jelszavak A felhasználónak, ahhoz, hogy Touch ID-t vagy a Face ID-t használhassa, úgy kell beállítania az eszközt, hogy jelkód vagy jelszó legyen szükséges a feloldásához. Ha a Touch ID vagy a Face ID sikeres egyezést észlel, a felhasználó eszköze felold, anélkül, hogy az eszköz jelkódját vagy jelszavát kérné. Ezáltal sokkal praktikusabbá válik a hosszabb, komplexebb jelkód vagy jelszó használata, mivel a felhasználónak nem kell olyan sűrűn megadnia. A Touch ID és a Face ID nem helyettesíti a felhasználói jelkódot vagy jelszót, viszont könnyen elérhetővé teszi az eszközt észszerű határokon és időkorlátokon belül. Ez azért fontos, mert az erős jelkód vagy jelszó adja az alapját annak, ahogyan a felhasználó ios-, ipados-, macos- vagy watchos-eszköze kriptográfiailag védi az adatait. Ha az eszköz jelkódját vagy jelszavát meg kell adni A felhasználók bármikor használhatják a jelkódjukat vagy jelszavukat a Touch ID vagy a Face ID helyett, de vannak olyan helyzetek, amikor a biometrikus azonosítók nem engedélyezettek. A biztonság szempontjából fontos következő műveletekhez mindig meg kell adni a jelkódot vagy jelszót: A szoftver frissítése Az eszköz törlése Jelkódbeállítások megtekintése vagy módosítása Konfigurációs profilok telepítése A Biztonság és adatvédelem beállításpanel feloldása a Rendszerbeállításokban a Mac gépen A Felhasználók és csoportok beállításpanel feloldása a Rendszerbeállításokban a Mac gépen (ha a FileVault be van kapcsolva) Jelkód vagy jelszó szükséges akkor is, ha az eszköz a következő állapotokban van: Az eszköz most lett bekapcsolva vagy újraindítva A felhasználó kijelentkezett a Mac-fiókjából (vagy még nem jelentkezett be) A felhasználó több mint 48 órája nem oldotta fel az eszközét. A felhasználó 156 órája (hat és fél napja) nem használata a jelkódját vagy jelszavát, és nem használt biometrikus azonosítót az eszköz feloldásához az elmúlt 4 órában. Az eszköz távoli zárolási parancsot kapott 14

15 A kikapcsolásból/vészhelyzeti módból való kilépés után; ehhez egyszerre nyomva kell tartani a hangerőgombot és az altatás/felébresztés gombot 2 másodpercig, majd a Mégsem gombot kell megnyomni Öt egymást követő sikertelen biometrikus azonosítási kísérlet után (használhatósági szempontok miatt az eszköz azonban már korábban felajánlhatja a jelkód vagy jelszó megadását a biometrikus adatok helyett) Ha a Touch ID vagy a Face ID be van kapcsolva az iphone-on vagy ipaden, az eszköz automatikusan zárolódik az alvás/ébresztés gomb megnyomásával, valamint az eszköz mindig zárolja magát, amikor elalszik. A Touch ID-nak és a Face ID-nak sikeres egyeztetésre vagy opcionálisan a jelkódra van szüksége minden ébredés után. Annak a valószínűsége, hogy egy tetszőleges személy fel tudja oldani a felhasználó iphone-ját, ipadjét vagy Mac gépét 1: a Touch ID esetén és 1: a Face ID esetén. Ez a valószínűség növekszik, ha több ujjnyomot (öt ujjnyommal legfeljebb 1: ig) vagy arcot (két arccal legfeljebb 1: ig) regisztrál. A további biztonság érdekében mind a Touch ID, mind a Face ID csak öt sikertelen azonosítási kísérletet engedélyez, ezek után meg kell adni a jelkódot vagy jelszót a felhasználó eszközének vagy fiókjának az eléréséhez. Face ID esetén a hamis egyezés valószínűsége különböző a felhasználóra hasonlító ikrek és testvérek esetén, illetve 13 év alatti gyermekek esetén (mivel a megkülönböztető arcjegyek még nem fejlődtek ki teljesen). Ha a felhasználó számára ez aggodalomra ad okot, az Apple a jelkódot ajánlja a hitelesítéshez. Arcegyeztetés Az arcegyeztetés a Secure Enclave processzoron belül történik, kifejezetten erre a célra betanított neurális hálózatok segítségével. Az Apple az arcegyeztető neurális hálózatokat több mint egymilliárd kép segítségével tanította be; ezek között infravörös és mélységi képek is megtalálhatók, amelyeket olyan kutatásokból nyert, ahol a résztvevők korábban ebbe beleegyeztek. Az Apple ezután a világ minden tájáról származó résztvevőkkel együttműködve olyan reprezentatív csoportot alakított ki a személyekből, amely figyelembe veszi a nemet, az életkort, az etnikumot és más tényezőket. A felméréseket szükség szerint bővítették, hogy nagyfokú pontosságot nyújthassanak a különféle felhasználók számára. A Face ID úgy készült, hogy használható legyen kalap, sál, szemüveg, kontaktlencse és sok napszemüveg viselésével. Használható továbbá beltérben, kültérben, és teljes sötétségben is. Egy további neurális hálózat, amely arra van betanítva, hogy észlelje és kivédje a csalást, meggátolja az eszköz fotóval vagy maszkkal történő feloldását. A Face ID adatai, beleértve a felhasználó arcának matematikai reprezentációját, titkosítva vannak, és csak a Secure Enclave számára érhetők el. Ezek az adatok soha nem hagyják el az eszközt. Nem kapja meg őket az Apple, és az eszközről készült biztonsági mentésbe sem kerülnek bele. A rendszer normál működés közben a Face ID következő adatait menti, titkosítva, kizárólag a Secure Enclave általi használatra: A felhasználó arcának a regisztráció során kiszámított matematikai reprezentációi. A felhasználó arcának bizonyos feloldási kísérletek közben kapott matematikai reprezentációi, ha a Face ID úgy ítéli meg, hogy azok hasznosak a jövőbeli egyeztetéshez A normál működés közben rögzített arcképeket a rendszer nem tárolja, hanem azonnal elveti, amint kiszámolta a matematikai reprezentációt a regisztrációhoz vagy a regisztrált Face ID-adatokkal való összehasonlításhoz. 15

16 A Face ID-egyeztetés javítása A Face ID az egyeztetési teljesítmény javítása érdekében, és hogy lépést tartson az arc és a kinézet természetes változásával, idővel bővíti a tárolt matematikai reprezentációt. Sikeres egyeztetés esetén a Face ID az adatok elvetése előtt felhasználhatja az újonnan kiszámított matematikai reprezentációt ha a minősége megfelelő véges számú további egyeztetéshez. Hasonlóképpen, ha a Face ID nem ismeri fel az arcot, de az egyezés minősége meghalad egy bizonyos küszöböt, és a felhasználó a sikertelen próbálkozás után azonnal megadja a jelkódot, akkor a Face ID egy újabb felvételt készít, és bővíti a regisztrált Face ID-adatokat az újonnan kiszámított matematikai reprezentációval. A rendszer elveti ezeket az új Face ID-adatokat, ha a felhasználó nem egyeztet velük tovább, illetve egy véges számú egyeztetés után. A bővítési folyamatokkal a Face ID lépést tud tartani a felhasználó arcszőrzetének vagy sminkjének drámai változásaival, miközben minimálisra csökkenti a téves egyezést. Eszköz vagy felhasználói fiók feloldása Ha a Touch ID vagy a Face ID ki van kapcsolva, akkor a rendszer az eszköz vagy fiók zárolásakor a Data Protection legmagasabb osztályának kulcsait amelyek a Secure Enclave processzorban vannak elveti. Az osztályba tartozó fájlok és Kulcskarika-elemek nem érhetők el, amíg a felhasználó fel nem oldja az eszközt vagy fiókot azáltal, hogy megadja a jelkódot vagy jelszót. Ha a Touch ID vagy a Face ID be van kapcsolva, akkor a rendszer nem veti el a kulcsokat az eszköz vagy fiók zárolásakor, hanem egy kulcsba csomagolja őket, és átadja azokat a Secure Enclave processzoron belüli Touch ID vagy Face ID alrendszernek. Amikor a felhasználó megpróbálja feloldani az eszközt vagy fiókot, ha az eszköz sikeres egyezést észlel, átadja a kulcsot a Data Protection-kulcsok kicsomagolásához, és az eszköz vagy fiók felold. Ez a folyamat további védelmet nyújt azáltal, hogy együttműködésre kötelezi a Data Protection funkciót és a Touch ID vagy Face ID alrendszereket az eszköz feloldása érdekében. Amikor az eszköz újraindul, azok a kulcsok, amelyekkel a Touch ID vagy Face ID feloldja az eszközt vagy fiókot, elvesznek; a Secure Enclave akkor veti el őket, ha teljesül egy olyan feltétel, amelyhez jelkód vagy jelszó megadása szükséges. Biztonságos vásárlás az Apple Payjel A felhasználó használhatja a Touch ID-t és a Face ID-t az Apple Payjel, hogy könnyen és biztonságosan vásárolhasson az áruházakban, alkalmazásokban és a weben. Ha hitelesíteni szeretne egy áruházon belüli vásárlást a Face ID-val, akkor a felhasználónak először meg kell erősítenie a vásárlási szándékát az oldalsó gomb dupla megnyomásával. Ez a dupla kattintás egy közvetlenül a Secure Enclave-hez kapcsolt fizikai gesztussal jelzi a felhasználó szándékát, és ezt a rosszindulatú folyamatok nem képesek meghamisítani. Ezután a felhasználó elvégzi a hitelesítést a Face ID használatával, és utána az érintés nélküli fizetés olvasójához közel helyezi az eszközt. Kiválasztható másik Apple Pay fizetési módszer a Face ID-hitelesítés után; ehhez ismételt hitelesítés szükséges, de a felhasználónak nem kell újból duplán megnyomnia az oldalsó gombot. 16

17 A felhasználó úgy fizet alkalmazásokon belül és a weben, hogy megerősíti a szándékát az oldalsó gomb dupla megnyomásával, majd a fizetés engedélyezéséhez hitelesítést végez a Face ID segítségével. Ha az Apple Pay-tranzakció nem teljesül az oldalsó gomb dupla megnyomását követő 60 másodpercen belül, akkor a felhasználónak ismételt dupla gombnyomással kell megerősítenie a szándékát. A Touch ID esetén a fizetési szándékot a Touch ID érzékelőt aktiváló mozdulat és a felhasználó ujjlenyomatának sikeres ellenőrzése erősíti meg. A Touch ID és a Face ID egyéb használatai A külső alkalmazások a rendszer által biztosított API-kkal kérhetik, hogy a felhasználó hitelesítse magát Touch ID-val vagy Face ID-val, illetve jelkóddal vagy jelszóval, és a Touch ID-t támogató alkalmazások automatikusan támogatják a Face ID-t minden módosítás nélkül. A Touch ID vagy a Face ID használatakor az alkalmazás csak arról kap értesítést, hogy a hitelesítés sikeres volt-e; nem fér hozzá sem a Touch ID, sem a Face ID funkcióhoz, sem a regisztrált felhasználóhoz társított adatokhoz. Kulcskarika-elemek védelme A Kulcskarika-elemeket is lehet a Touch ID vagy a Face ID segítségével védeni; ekkor a Secure Enclave csak a sikeres egyeztetés, illetve az eszköz jelkódjának vagy a fiók jelszavának megadása után oldja fel ezeket az elemeket. Az alkalmazásfejlesztők API-k segítségével ellenőrzik, hogy a felhasználó beállított-e jelkódot vagy jelszót, mielőtt a Touch ID vagy a Face ID használatát, illetve a jelkód vagy jelszó megadását kérnék a Kulcskarika-elemek feloldásához. Az alkalmazásfejlesztők a következőket tehetik: Megkövetelhetik, hogy a hitelesítési API-műveletek ne fogadják el tartalék lehetőségként az alkalmazásjelszót vagy az eszköz jelkódját. Lekérdezhetik, hogy a felhasználó regisztrálva van-e, így a Touch ID vagy a Face ID használható másodlagos faktorként a biztonságra érzékeny alkalmazásokban. ECC-kulcsokat generálhatnak és használhatnak a Secure Enclave processzoron belül, amelyeket a Touch ID vagy a Face ID véd. Az ezekkel a kulcsokkal végzett műveletek mindig a Secure Enclave processzoron belül történnek, miután az engedélyezi a használatukat. Vásárlások elvégzése és jóváhagyása A felhasználó konfigurálhatja a Touch ID-t vagy a Face ID-t, hogy az jóváhagyja az itunes Store-ban, az App Store-ban, az Apple Booksban és más helyeken végzett vásárlásokat, így nem kell megadnia az Apple ID jelszavát. ios 11 és újabb verzió, illetve macos és újabb verzió esetén az áruház kérelmének aláírásával a Touch ID és a Face ID által védett Secure Enclave ECC-kulcsok végzik a vásárlás hitelesítését. 17

18 A mikrofon hardveres leválasztása a Mac gépen és ipaden Az Apple T2 Security chippel szerelt minden hordozható Mac gép hardveres leválasztással rendelkezik, hogy a mikrofon biztosan ki legyen kapcsolva, amikor a fedél le van csukva. A T2 chippel szerelt 13 hüvelykes MacBook Pro és MacBook Air, valamint a 2019-es és későbbi, 15 hüvelykes MacBook Pro esetén ez a leválasztás magában a hardverben történik. A leválasztás megakadályozza, hogy bármely szoftver aktiválja a mikrofont, amikor a fedél le van csukva még a macos rendszeren gyökér- vagy kerneljogosultságokkal rendelkező szoftverek, sőt magán a T2 chipen lévő szoftver sem képes rá. (A kamera nincs hardveresen leválasztva, mivel a látóterét teljesen elzárja a lecsukott fedél.) A 2020-tól kiadott ipad-modelleken leválasztható a hardvermikrofon. Amikor MFIkompatibilis tok (amelyeket többek közt az Apple értékesít) csatlakozik az ipadhez, és a tok be van csukva, a mikrofon le van választva a hardverben, így a mikrofon hangadatai nem állnak rendelkezésre egyetlen szoftvernek sem még root- vagy kerneljogosultsággal rendelkezőknek sem ipados-en, illetve a firmware módosításakor sem. Expressz kártya energiatakarékos móddal az iphone-ban Még akkor is lehet elegendő energia az akkumulátorban az Expressz kártya-tranzakciókhoz, ha az ios nem fut, mert az iphone-nak töltődnie kell. A támogatott iphone-eszközök automatikusan támogatják ezt a funkciót a következő esetekben: Expressz tömegközlekedési kártyaként kijelölt tömegközlekedési kártya Diákigazolvány bekapcsolt Expressz móddal Az oldalsó gomb megnyomásával megjelenik az alacsony töltöttség ikonja, valamint egy felirat, amely jelzi, hogy az Expressz kártyák használhatók. Az NFC-vezérlő ugyanolyan feltételekkel hajtja végre az Expressz kártyák tranzakcióit, mint amikor az ios fut, kivéve, hogy a tranzakciókat csak haptikus értesítések jelzik. Nem jelenik meg látható értesítés. A funkció nem érhető el, amikor a felhasználó által kezdeményezett normál leállítás történt. 18

19 Rendszerbiztonság A rendszerbiztonság áttekintése Az Apple-hardver egyedi képességeire épülő rendszerbiztonságot úgy terveztük, hogy maximalizálja az Apple-eszközök operációs rendszereinek biztonságát anélkül, hogy feláldozná érte a használhatóságot. A rendszerbiztonságba beletartozik a rendszerindítási folyamat, a szoftverfrissítések és az operációs rendszer működtetése. A biztonságos rendszerindítás a hardverben kezdődik, és olyan megbízhatósági láncolatot épít ki a szoftveren keresztül, amelyben minden egyes lépés gondoskodik arról, hogy a következő lépés megfelelően működik, mielőtt átadná az irányítást. A biztonsági modell nemcsak az Apple-eszközök alapértelmezett rendszerindítását támogatja, hanem az ios-, ipados- és macos-eszközök visszaállításának és frissítésének számos módját is. Az ios, ipados és macos legfrissebb verziói a legbiztonságosabbak. A szoftverfrissítési mechanizmus nem csupán időben frissíti az Apple-eszközöket az Apple megbízható szoftvereit is szállítja. A frissítési rendszer még a leminősítési támadásokat is képes megakadályozni, így az eszközök nem állíthatók vissza az operációs rendszer korábbi verziójára (olyanra, amelyet a támadó fel tud törni) a felhasználói adatok ellopása érdekében. Végezetül pedig az Apple-eszközök rendszerindítási és futásidejű védelmeket kínálnak, így integritásukat a műveletek közben is megőrzik. Ezek a védelmek jelentősen eltérnek az ios-, ipados- és macos-eszközök között, az általuk támogatott képességek rendkívül eltérő halmaza és ebből következőleg az általuk kivédendő támadások alapján. Véletlenszám-generátor A kriptográfiai álvéletlenszám-generátorok (CPRNG-k) a biztonságos szoftverek fontos építőkövei. Ennek érdekében az Apple megbízható szoftveres CPRNG-t alkalmaz az ios, ipados, macos, tvos és watchos rendszerek kerneleiben. Ennek a felelőssége a rendszerből származó nyers entrópia összesítése és biztonságos véletlen számok biztosítása a fogyasztók számára mind a kernelben, mind a felhasználói térben. Entrópiaforrások A kernel CPRNG több entrópiaforrásból táplálkozik a rendszerindítás és az eszköz élettartama alatt. A következők tartoznak ide (az elérhetőség függvényében): A Secure Enclave hardveres RNG-je A rendszerindítás során összegyűjtött időalapú vibrálás 19

20 A hardvermegszakításokból összegyűjtött entrópia Az entrópia rendszerindítások közötti megmaradásáért használt forrásfájl Az Intel véletlenszám-utasításai, például az RDSEED és RDRAND (csak macos) A kernel CPRNG A kernel CPRNG egy Fortuna-alapú kialakítás, amely 256 bites titkosítást céloz. Kiemelkedő minőségű véletlen számokat biztosít a felhasználói tér fogyasztói számára a következő API-k használatával: A getentropy(2) rendszerhívás A véletlen eszköz, például /dev/random A kernel CPRNG a felhasználó által megadott entrópiát a véletlen eszközbe történő írásokon keresztül fogadja el. Biztonságos rendszerindítás Az ios és az ipados biztonságos rendszerindítási folyamata Az indítási folyamat minden egyes lépése az Apple által kriptográfiailag aláírt összetevőket tartalmaz, hogy gondoskodjon az integritásról, és csak a megbízhatósági lánc ellenőrzése után lépjen tovább. Ebbe beletartoznak a rendszerbetöltők, a kernel, a kernelbővítmények és az alapsáv firmware. Ez a biztonságos rendszerindítási lánc gondoskodik arról, hogy a szoftverek legalsó szintje nem módosul illetéktelenül. Amikor bekapcsolja az ios- vagy ipados-eszközt, annak alkalmazásprocesszora kódot hajt végre az írásvédett memóriából, más néven a Boot ROM-ból. Ez a nem módosítható kód, más néven a megbízhatóság hardvergyökere a chip gyártása során készül el, és implicit módon megbízható. A Boot ROM-kód tartalmazza az Apple gyökértanúsítványkibocsátójának nyilvános kulcsát ez használatos annak ellenőrzésére, hogy az iboot rendszerbetöltő alá van-e írva az Apple által, mielőtt az betöltődne. Ez a megbízhatósági lánc első lépése, amelyben minden lépés ellenőrzi, hogy a következő lépést aláírta-e az Apple. Amikor az iboot elvégzi a feladatát, ellenőrzi és futtatja az ios vagy az ipados kernelét. A9 vagy korábbi A sorozatú processzorral rendelkező eszközök esetén a Boot ROM betölti és ellenőrzi a további alacsony szintű rendszerbetöltő (LLB) fokozatot, amely betölti és ellenőrzi az ibootot. A következő fokozatok betöltésének vagy ellenőrzésének a sikertelenségét a hardvertől függően eltérően kezeli a rendszer: A Boot ROM nem tudja betölteni az LLB-t (régebbi eszközök esetén): Eszköz firmwarefrissítési (DFU) módja LLB vagy iboot: Helyreállító mód Az eszközt mindkét esetben az ituneshoz (macos vagy korábbi esetén) vagy a Finderhez (macos vagy újabb esetén) kell USB-n keresztül csatlakoztatni, és vissza kell állítani az alapértelmezett gyári beállításokra. A rendszerindítási folyamat regiszterével (BPR) a Secure Enclave korlátozza a felhasználói adatok elérését a különböző módokban, és ez frissül, mielőtt a rendszer a következő módokba lép: 20

21 DFU-mód: A Boot ROM állítja be az Apple A12 vagy újabb SoC-vel rendelkező eszközökön. Helyreállító mód: Az iboot állítja be az Apple A10, S2 vagy újabb SoC-vel rendelkező eszközök esetén Mobilhálózati eléréssel rendelkező eszközök esetén az alapsávalrendszer is használja a saját hasonló folyamatát a biztonságos rendszerindításhoz; az aláírt szoftvereket és kulcsokat az alapsávprocesszor ellenőrzi. A Secure Enclave társprocesszor is alkalmaz biztonságos rendszerindítási folyamatot, ezzel győződik meg arról, hogy a saját, különálló szoftverét az Apple ellenőrizte és aláírta. macos rendszerindítási módok A Mac gépek rendszerindítási folyamata Amikor bekapcsolja az Apple T2 Security chippel szerelt Mac gépet, a chip kódot hajt végre a Boot ROM nevű írásvédett memóriából. Ez a nem módosítható kód, más néven a megbízhatóság hardvergyökere a chip gyártása során készül el, a sérülékenységek ellen auditálva van, és implicit módon megbízható. A Boot ROM-kód tartalmazza az Apple gyökértanúsítvány-kibocsátójának nyilvános kulcsát; ez használatos annak ellenőrzésére, hogy az iboot rendszerbetöltő alá van-e írva az Apple privát kulcsa által, mielőtt az betöltődne. Ez a megbízhatósági lánc első lépése. Az iboot ellenőrzi a T2 chipen lévő kernel és a kernelbővítmény kódját, ami pedig ezt követően ellenőrzi az Intel UEFIfirmware-t. Az UEFI-firmware és a társított aláírás kezdetben csak a T2 chip számára érhetők el. macos biztonságos rendszerindítási lánc. 21

22 Az ellenőrzés után az UEFI-firmware képe hozzárendelődik a T2 chip memóriájának egy részéhez. Ezt a memóriát az Intel processzor a továbbfejlesztett soros perifériainterfészen (espi) keresztül éri el. Amikor az Intel processzor először indul el, beolvassa az UEFIfirmware-t a espi-n keresztül a T2 chipen található, integritás-ellenőrzésen és memóriahozzárendelésen átesett firmware-másolatból. A megbízhatósági lánc kiértékelése az Intel processzoron folytatódik; az UEFI-firmware kiértékeli a boot.efi (a macos rendszerbetöltője) aláírását. Az Intel által biztosított macos biztonságos rendszerindítási aláírások ugyanabban az Image4 formátumban vannak tárolva az ios, az ipados és a T2 chip biztonságos rendszerindítása esetén, és az Image4- fájlokat értelmező kód ugyanaz a megerősített kód az aktuális ios és ipados biztonságos rendszerindítási implementációban. A boot.efi ezután ellenőrzi az új, immutablekernel nevű fájl aláírását. Ha a biztonságos rendszerindítás engedélyezve van, az immutablekernel fájl a macos rendszerindításához szükséges Apple-kernelbővítmények teljes készletét reprezentálja. A biztonságos rendszerindítási irányelv az immutablekernel átadásakor megáll, és ezután a macos biztonsági irányelvek (például a Rendszerintegritás-védelem és az aláírt kernelbővítmények) lépnek életbe. Ha a folyamat során bármi hiba vagy sikertelen művelet történik, a Mac gép macoshelyreállítás módba, Apple T2 Security chip helyreállító módba vagy Apple T2 Security chip DFU-módba lép. A Mac gépek rendszerindítási módjainak áttekintése A Mac gépek számos rendszerindítási móddal rendelkeznek; ezek elérhetők rendszerindításkor olyan billentyűkombinációk megnyomásával, amelyeket UEFI-firmware vagy a rendszerindító felismer. Néhány rendszerindítási mód, például az egyetlen felhasználós mód, nem fog működni, amíg a biztonsági irányelv át nincs állítva Nincs biztonság értékre a Rendszerindítás-védelem segédprogramban. Mód Billentyűkombináció Leírás macos rendszerindítás Nincs Az UEFI-firmware átadja a folyamatot a macos rendszerindítónak (ez egy UEFI-alkalmazás), amely átadja a folyamatot a macos kernelének. A Mac gép normál rendszerindításakor, ha a FileVault be van kapcsolva, a macos rendszerindító megjeleníti a bejelentkezési képernyőt, hogy a jelszóval visszafejthesse a tárhelyet. Indításkezelő Alt ( ) Az UEFI-firmware elindítja a beépített UEFI-alkalmazást, amely megjeleníti a felhasználónak a rendszerindító lemez kiválasztásának felületét. Céllemezmód (TDM) T Az UEFI-firmware elindítja a beépített UEFI-alkalmazást, amely a beépített tárolóeszközt nyers, blokkalapú eszközként fedi fel FireWire-, Thunderbolt- vagy USBkapcsolaton, illetve ezek bármely kombinációján keresztül (a Mac gép modelljétől függően). 22

23 Mód Billentyűkombináció Leírás Egyetlen felhasználó mód Cmd ( )-S A macos kernel átadja az -s kapcsolót a launchd argumentumvektorának, ezután a launchd egyfelhasználós rendszerhéjat hoz létre a Konzol alkalmazás tty eszközében. Megjegyzés: Ha a felhasználó kilép a rendszerhéjból, a macos folytatja a rendszerindítást a bejelentkezési ablak megjelenítéséhez. Visszaállítási operációs rendszer Cmd ( )-R Az UEFI-firmware minimálisra csökkentett macos rendszert tölt be a belső tárhelyen lévő aláírt lemezképfájlból (.dmg). Internetes visszaállítási operációs rendszer Alt ( )-Cmd ( )-R Az aláírt lemezkép letöltődik az internetről HTTP használatával. Diagnosztika D Az UEFI-firmware minimális UEFIdiagnosztikai környezetet tölt be a belső tárhelyen lévő aláírt lemezképfájlból. Internetes diagnosztika Alt ( )-D Az aláírt lemezkép letöltődik az internetről HTTP használatával. Netes rendszerindítás (Apple T2 Security chippel nem rendelkező Mac gépek esetén) N Az UEFI-firmware letölti a macos rendszerindítót a helyi TFTPszerverről, a rendszerindító letölti a macos kerneljét ugyanarról a TFTPszerverről, és a macos kernelje felcsatolja a fájlrendszert NFS- vagy HTTP-alapú hálózati megosztásból. Windows-rendszerindítás Nincs Ha a Windows a BootCamppel lett telepítve, akkor az UEFI-firmware átadja a folyamatot a Windowsrendszerindítónak, ami pedig átadja a folyamatot a Windows kernelének. A visszaállítási operációs rendszer és a diagnosztikai környezet a Mac gépeken A visszaállítási operációs rendszer teljesen elkülönül a fő macos operációs rendszertől, és a teljes tartalma a BaseSystem.dmg nevű lemezképfájlban található. Van ezenkívül egy társított BaseSystem.chunklist nevű fájl is, amely a BaseSystem.dmg integritását ellenőrzi. A chunklist-fájl a BaseSystem.dmg 10 MB-os darabjaiból készült hashek sorozata. Az UEFI-firmware kiértékeli a chunklist-fájl aláírását, és utána darabonként egyesével kiértékeli a BaseSystem.dmg kép hasheit, így gondoskodik arról, hogy azok megfelelnek a chunklistben szereplő aláírt tartalomnak. Ha bármelyik hash nem egyezik, a helyi visszaállítási operációs rendszerből történő rendszerindítás megszakad, és az UEFIfirmware megpróbálja helyette az internetes visszaállításból indítani a rendszert. 23

24 Ha a hitelesítés sikeresen lefut, az UEFI-firmware felcsatolja a BaseSystem.dmg képet RAM-meghajtóként, és elindítja a benne tárolt boot.efi fájlt. Az UEFI-firmware számára nem szükséges a boot.efi külön ellenőrzése, és a boot.efi számára sem szükséges a kernel ellenőrzése, mivel az operációs rendszer kész tartalmaira (amelyeknek ezek az elemek csupán részhalmazai) már megtörtént az integritás ellenőrzése. A helyi diagnosztikai környezet indításának folyamata majdnem ugyanaz, mint a visszaállítási operációs rendszer indítási folyamata. Külön AppleDiagnostics.dmg és AppleDiagnostics.chunklist fájlokat használ a rendszer, de ezek ellenőrzése azonos a BaseSystem-fájlok ellenőrzésével. A boot.efi indítása helyett az UEFI-firmware a dmgképen belül egy diags.efi nevű fájlt indít, amelynek az a szerepe, hogy egy sor más UEFIillesztőprogramot hívjon meg; ezek kommunikálnak a hardverrel, és ellenőrzik az esetleges hibáit. Az internetes visszaállítási operációs rendszer és a diagnosztikai környezet a Mac gépeken Ha hiba történik a helyi visszaállítási vagy diagnosztikai környezet indítása közben, az UEFI-firmware megpróbálja ezek helyett letölteni a képeket az internetről. A felhasználó is kérheti a képek internetről való letöltését, ha speciális billentyűkombinációkat nyom meg a rendszerindítás közben. Az OS Recovery Serverről letöltött lemezképek és chunklist-fájlok integritásának ellenőrzése ugyanúgy történik, mint a tárolóeszközről beszerzett képek esetén. Az OS Recovery Serverrel a kapcsolat HTTP-protokollú, de az integritás ellenőrzése a teljes letöltött tartalmon lefut a korábban leírtaknak megfelelően, és ekképpen a támadók nem képesek a kapcsolatban kárt tenni a hálózat irányításával. Ha egyetlen darab integritásellenőrzése sikertelen, akkor az OS Recovery Server 11 alkalommal kap újbóli kérelmet, mielőtt a rendszer megszakítja a folyamatot, és hibát jelez. Microsoft Windows-rendszerindítás a Mac gépeken Alapértelmezés szerint a biztonságos rendszerindítást támogató Mac gépek csak az Apple által aláírt tartalmat támogatják. Az Apple azonban a Boot Camp-telepítések biztonságának növeléséért a Windows biztonságos rendszerindítását is támogatja. Az UEFI-firmware tartalmazza a Microsoft-rendszerbetöltők hitelesítéséhez használt Microsoft Windows Production CA 2011 tanúsítvány másolatát. Megjegyzés: A Microsoft Corporation UEFI CA 2011 tanúsítványhoz jelenleg nincs megbízhatóság, amely lehetővé tenné a Microsoft-partnerek által aláírt kód ellenőrzését. Az UEFI CA használata elterjedt az egyéb operációs rendszerek, például a Linux-változatok rendszerbetöltőinek hitelességének ellenőrzésére. A Windows biztonságos rendszerindításának támogatása alapértelmezés szerint nincs bekapcsolva; a Boot Camp asszisztens (BCA) használatával kell bekapcsolni. Amikor a felhasználó a BCA-t futtatja, a macos átkonfigurálódik úgy, hogy megbízza a Microsoft belsőleg aláírt kódját a rendszerindítás közben. A BCA lefutása után, ha a macos sikertelen az Apple belső megbízhatóságának hitelesítésében a biztonságos rendszerindítás során, akkor az UEFI-firmware megpróbálja kiértékelni az objektum megbízhatóságát az UEFI biztonságos rendszerindítási formátum szerint. Ha a megbízhatóság kiértékelése sikeres, a Mac gép a Windows rendszerindítását folytatja. Ellenkező esetben a Mac gép a macos-helyreállítás módba lép, és tájékoztatja a felhasználót a megbízhatóság sikertelen kiértékeléséről. 24

25 A rendszerindítási folyamat Apple T2 Security chippel nem rendelkező Mac gépek esetén Az Apple T2 Security chippel nem rendelkező Mac gépek nem támogatják a biztonságos rendszerindítást. Az UEFI-firmware ezért a macos rendszerindítóját (boot.efi) ellenőrzés nélkül tölti be a fájlrendszerből, és a betöltő ellenőrzés nélkül tölti be a kernelt (prelinkedkernel) a fájlrendszerből. A rendszerindítási lánc védelme érdekében a felhasználóknak a következő biztonsági mechanizmusok mindegyikét célszerű bekapcsolniuk: Rendszerintegritás-védelem: Alapértelmezés szerint be van kapcsolva; védi a rendszerindítót és a kernelt a futó macos rendszeren belüli rosszindulatú írási műveletek ellen. FileVault: Kétféleképpen kapcsolható be: a felhasználó vagy egy mobileszköz-felügyeleti (MDM) rendszergazda által. A funkció véd a fizikailag jelen lévő támadó ellen, ha az Céllemez módban megpróbálná felülírni a rendszerindítót. Firmware-jelszó: Kétféleképpen kapcsolható be: a felhasználó vagy egy mobileszközfelügyeleti (MDM) rendszergazda által. Megakadályozza, hogy a fizikailag jelen lévő támadó alternatív rendszerindítási módot (például visszaállítási operációs rendszer, egyetlen felhasználós mód vagy céllemez mód) indítson, amelyből a rendszerindító felülírható. A beállítás megakadályozza továbbá az alternatív adathordozóról történő rendszerindítást is, amivel a támadó a rendszerindítót felülíró kódot futtathatna. A feloldási folyamat Apple T2 Security chippel nem rendelkező Mac gépek esetén. 25

26 Rendszerindítás-védelem segédprogram A Rendszerindítás-védelem segédprogram áttekintése A Rendszerindítás-védelem segédprogram a korábbi Firmware-jelszó segédprogramot cseréli. Az Apple T2 Security chippel rendelkező Mac gépeken ez a segédprogram a biztonsági irányelvekre vonatkozó beállítások nagyobb halmazát kezeli. A T2 chippel nem rendelkező Mac gépek továbbra is a Firmware-jelszó segédprogramot használják. A segédprogram úgy érhető el, ha a visszaállítási operációs rendszert indítja el, és a Rendszerindítás-védelem segédprogramot választja a Segédprogramok menüből. A kritikus rendszerbiztonsági irányelvek vezérlőinek (például a biztonságos rendszerindítás vagy a SIP) a visszaállítási operációs rendszerbe való helyezése azzal az előnnyel jár, hogy a teljes operációs rendszer integritásának ellenőrzése megtörténik. Ez gondoskodik arról, hogy a Mac gépbe hatolt támadó kód ne tudja könnyedén megszemélyesíteni a felhasználót a további biztonsági irányelvek kikapcsolása érdekében. Rendszerindítás-védelem segédprogram. A kritikus irányelvek módosításához mostantól hitelesítés szükséges, még Helyreállító módban is. Ez a funkció csak a T2 chippel szerelt Mac gépeken érhető el. Amikor a felhasználó először indítja el a Rendszerindítás-védelem segédprogramot, az aktuálisan betöltött macos-helyreállításhoz társított elsődleges macos-telepítés rendszergazdai jelszavát kell megadnia. Ha nincs rendszergazda, akkor létre kell hozni egyet az irányelv módosítása előtt. A T2 chip megköveteli, hogy a Mac gép aktuálisan a macoshelyreállításba legyen betöltve, és hogy az irányelv módosítása előtt történjen meg a Secure Enclave processzorba mentett hitelesítő adattal való hitelesítés. A biztonsági irányelvek módosításainak két implicit követelménye van. A macos-helyreállításnak a következőket kell teljesítenie: A T2 chiphez közvetlenül kapcsolt tárolóeszközről kell betöltődnie, mivel a más eszközökön lévő partíciók nem rendelkeznek a Secure Enclave processzorban tárolt, a belső tárolóeszközhöz kapcsolt hitelesítő adatokkal. 26

27 APFS-alapú köteten kell lennie, mivel a Secure Enclave processzornak küldött, visszaállításhoz használt hitelesítő adatok tárolása csak a meghajtó APFS-kötetének Preboot részén támogatott. A HFS+ formátumú kötetek nem képesek a biztonságos rendszerindításra. Ez az irányelv csak az Apple T2 Security chippel rendelkező Mac gépek Rendszerindításvédelem segédprogramjában jelenik meg. Azzal együtt, hogy az esetek nagy részében nem szükséges módosítani a biztonságos rendszerindítási irányelvet, a felhasználóké a végső döntés az eszközük beállításaiban, és az igényeiknek megfelelően dönthetnek úgy, hogy kikapcsolják vagy leminősítik a Mac gép biztonságos rendszerindítás funkcióját. Amikor ebben az alkalmazásban módosítja a biztonságos rendszerindítási irányelveket, azok csak az Intel processzoron ellenőrzött megbízhatósági lánc kiértékelésére vonatkoznak. A Biztonságos rendszerindítás a T2 chippel beállítás mindig érvényes. A biztonságos rendszerindítási irányelv a következő három beállításra konfigurálható: Teljes biztonság, Közepes biztonság és Nincs biztonság. A Nincs biztonság beállítás teljesen kikapcsolja a biztonságos rendszerindítási kiértékelést az Intel processzoron, és a felhasználó tetszése szerinti rendszerindítást hajthat végre. Teljes biztonság rendszerindítási irányelv Az alapértelmezett beállítás a Teljes biztonság, és ez úgy viselkedik, mint az ios és az ipados. Amikor a szoftver le van töltve, és készen áll a telepítésre, akkor a macos a szoftverrel érkező globális aláírás helyett az ios és ipados esetén használt Applealáírószerverrel kommunikál, és új, személyre szabott aláírást kér. Az aláírás akkor személyre szabott, ha tartalmazza az ECID-et jelen esetben ez egy, a T2 chipre jellemző egyedi azonosító az aláírási kérelem részeként. Ekkor az aláírószerver által visszaadott aláírás egyedi, és csak az adott T2 chippel használható. Amikor a Teljes biztonság irányelv van érvényben, az UEFI-firmware gondoskodik arról, hogy a kapott aláírás nemcsak az Apple által van aláírva, hanem kifejezetten az adott Mac gép számára van aláírva, így lényegében az adott Mac géphez és az adott macos-verzióhoz köti. Az online aláírószerver használata a visszaforgatási támadások ellen is jobb védelmet nyújt, mint a tipikus globális aláírási megközelítések. Globális aláírórendszerben a biztonsági alapidőszak sokszor válthatott, az olyan rendszer, amelyik nem ismeri a legújabb firmware-t, nem fogja ezt észlelni. Ha például a számítógép azt észleli, hogy még az 1. biztonsági alapidőszakban van, akkor elfogadja a 2. biztonsági alapidőszakból származó szoftvert, még akkor is, ha az aktuális biztonsági alapidőszak az 5. Az ios- és ipadostípusú, online aláírórendszer esetén az aláírószerver visszautasíthatja az olyan szoftverek számára az aláírást, amelyek nem a legújabb biztonsági alapidőszakban vannak. Továbbá, ha a támadó sebezhetőséget fedez fel a biztonsági alapidőszak váltása után, nem használhatja fel csak úgy az A rendszerből a korábbi biztonsági alapidőszakból származó sebezhető szoftvert, hogy a B rendszerre alkalmazva megtámadja azt. Az a tény, hogy a korábbi biztonsági alapidőszakból származó sebezhető szoftver az A rendszerre volt személyre szabva, meggátolja, hogy átvihető és ezáltal támadásra használható legyen B rendszer esetén. Mindezek a mechanizmusok együttműködnek, hogy sokkal erősebben biztosítsák, hogy a támadók ne tudjanak szándékosan sebezhető szoftvert elhelyezni a számítógépen, és így képesek legyenek a legújabb szoftver által nyújtott védelmeket kijátszani. A Mac gép rendszergazdai felhasználónevének és jelszavának birtokában lévő felhasználó továbbra is kiválaszthatja a számára legjobban használható biztonsági irányelvet. 27

28 Közepes biztonság rendszerindítási irányelv A Közepes biztonság bizonyos fokig az UEFI biztonságos rendszerindítási helyzethez hasonlít, ahol a szállító (itt az Apple) digitális aláírást generál a kódhoz, hogy ezzel igazolja a szállítótól való származását. A támadók ekképpen nem illeszthetnek be alá nem írt kódot. Erre az aláírásra globális aláírásként hivatkozunk, mivel bármely Mac gépen bármennyi ideig használható, amíg az adott Mac gépek Közepes biztonság irányelvet használnak. Sem az ios, sem az ipados, sem a T2 chip nem támogatja a globális aláírásokat. A globális aláírási sémák korlátozása a visszaforgatási támadás megakadályozásával van összefüggésben. A visszaforgatási támadás esetén a támadó egy korábbi, de szabályszerű és helyesen aláírt, ismert sebezhetőséggel rendelkező szoftvert helyez el a rendszeren, és kihasználja a sebezhetőségeket a rendszer feletti irányítás megszerzésére. Számos globális aláírási rendszer egyáltalán nem próbálja kivédeni a visszaforgatási támadásokat. Azok, amelyek mégis, gyakran a biztonsági verzió vagy biztonsági alapidőszak használatán keresztül teszik ezt. Ez egy olyan számot jelent, amelyet jellemzően aláírás véd, és a rendszer az aláírás ellenőrzése után értékeli ki. A számítógépnek biztonságos állandó tárolóra van szüksége, hogy nyomon kövesse a biztonsági alapidőszak aláírt kódban észlelt legnagyobb értékét, és hogy letilthassa az összes olyan kódot még ha megfelelően alá is vannak írva, amelynél a biztonsági alapidőszak ennél kisebb értékű. A biztonsági alapidőszakot lecserélni kívánó szállító új biztonsági alapidőszakkal írja alá a szoftvert, olyannal, amelyik nagyobb a korábban kiadott szoftver által tartalmazottnál. A firmware olyan értéket észlel a biztonsági alapidőszakban, amely nagyobb a biztonságos tárolójában lévőnél, és frissíti a tárolóban lévő biztonsági alapidőszak értékét. Ezután visszautasít minden olyan korábbi, aláírt kódot, amelynek a biztonsági alapidőszaka kisebb, mint a legutóbbi tárolt érték. Ha a rendszer nem rendelkezik biztonságos tárolóval, a támadó egyszerűen visszaforgathatja a biztonsági alapidőszak értékét, és ezután visszaforgathatja a szoftvert, és kihasználhatja a gyenge pontokat. Ezért van az, hogy sok olyan rendszer, amely implementálja a biztonsági alapidőszakokat, a biztonsági alapidőszakok számát egy egyszer programozható biztosítéktömbben tárolja. A beégetett biztosítékokban nem módosítható az érték. Ennek van egy olyan korlátozása, hogy ha a támadó egyszerűen beégetheti az összes biztosítékot, hogy az összes aláírást érvénytelenítse, és így visszafordíthatatlanul megakadályozza az operációs rendszer elindítását. Az Apple globális aláírási sémája nem tartalmaz biztonsági alapidőszakot, mivel azok a rendszerek nem rugalmasak, és gyakran okoznak jelentős használhatósági problémákat. A visszaforgatás elleni védelem érdekében jobb az alapértelmezett Teljes biztonság mód használata, amely nagyban hasonlít az ios és ipados viselkedéséhez. Azoknak a felhasználóknak, akik szeretnék kiaknázni a visszaforgatás elleni védelmet, célszerű megtartani a Teljes biztonság irányelvet. Azoknak a felhasználóknak, akik nem tudják kihasználni a Teljes biztonság módot, a Közepes biztonság mód áll a rendelkezésére. Rendszerindítási adathordozó irányelv A rendszerindítási adathordozó irányelv csak az Apple T2 Security chippel rendelkező Mac gépeken jelenik meg, és teljesen független a biztonságos rendszerindítás irányelvtől. Még ha a felhasználó le is tiltja a biztonságos rendszerindítást, ez a művelet nem módosítja azt az alapértelmezett viselkedést, hogy csak a T2 chiphez közvetlenül csatlakoztatott tárolóeszközről engedélyezett a rendszerindítás. 28

29 Korábban a Mac gépek alapértelmezés szerint képesek voltak külső eszközről indítani a rendszert. Ebben a megközelítésben az eszközzel fizikailag rendelkező támadónak lehetősége volt önkényes kódot futtatnia a rendszerindító köteten. Az olyan védelmi kombinációknak köszönhetően, mint a FileVault és a SecureBoot, nincs olyan ismert architekturális gyengeség, amelyen keresztül a külső köteten kódot futtató támadó hozzáférhetne a felhasználói adatokhoz a felhasználó jelszava nélkül. A támadó azonban még ideiglenes önkényes kód végrehajtásával is képes lehet úgy manipulálni a Mac gépet, hogy előkészítsen a támadó által irányított adatokat, amellyel kihasználja az Apple számára ismeretlen gyengeségeket. Az önkényes kód létrehozása így magában hordozza annak a lehetőségét, hogy a felhasználói rendszerindítás sérül, és az erre épülő felhasználói adatok is sérülnek. Az Apple a T2 chippel rendelkező Mac gépek esetén módosította a külső rendszerindítás alapértelmezését letiltottra, így a felhasználónak ki kell kapcsolnia ezt a beállítást. A T2 chippel nem rendelkező Mac gépeken a felhasználók bármikor beállíthatnak firmware-jelszót, ha be szeretnék kapcsolni az alapértelmezésben letiltott beállítást. A firmware-jelszavak azonban nem olyan jól ismertek, és csak kevés adaptáció történt rájuk. Az irányelv módosításával az Apple úgy módosítja a Mac gép viselkedését, hogy alapértelmezésben a legjobb védelmet kínálja, ahelyett hogy a felhasználóra terhelné a beállítás aktiválását. A firmware jelszavas védelme A macos támogatja a Firmware-jelszó funkció használatát, hogy megakadályozza az adott Mac gépen a firmware nem szándékos módosításait. A Firmware-jelszó beállításával megakadályozható az alternatív rendszerindítási módok használata, mint például a visszaállítási operációs rendszer vagy az egyetlen felhasználó mód, illetve a jogosulatlan kötetről való rendszerindítás és a céllemez módban való rendszerindítás. A Firmware-jelszó legalapvetőbb módja a visszaállítási operációs rendszer Firmwarejelszó segédprogramjából érhető el az Apple T2 Security chippel nem rendelkező Mac gépek esetén; T2 chippel rendelkező Mac gépek esetén a Rendszerindítás-védelem segédprogramból érhető el. A speciális beállítások (például jelszókérés lehetősége minden rendszerindításkor) a firmwarepasswd parancssori eszközből érhetők el a macos rendszerben. A rendszerindítási folyamat Apple T2 Security chippel nem rendelkező Mac gépek esetén részben leírtaknak megfelelően, a firmware-jelszó beállítása különösen fontos annak érdekében, hogy csökkentse a támadás kockázatát T2 chippel nem rendelkező Mac gépeken a fizikailag jelen lévő támadó esetén (például számítógépes laboratóriumban vagy irodai környezetben). A firmware-jelszó megakadályozhatja, hogy a támadó a visszaállítási operációs rendszert indítsa el, ahol ki tudná kapcsolni a Rendszerintegritás-védelem funkciót. Az alternatív adathordozóról való rendszerindítás kikapcsolásával a támadó nem képes végrehajtani privilegizált kódot másik operációs rendszerből, hogy a perifériás firmware-eket támadja. A Firmware-jelszó visszaállítása mechanizmus segíti a jelszavukat elfelejtő felhasználókat. Ha a felhasználó a rendszerindítás során megnyom egy billentyűkombinációt, modellspecifikus karakterláncot kap, amelyet meg kell adnia az AppleCare-nek. Az AppleCare digitálisan aláír egy erőforrást, amelynek az aláírását az egységes erőforrásazonosító (URI) ellenőrzi. Ha az aláírás érvényes, és a tartalom az adott Mac géphez tartozik, akkor az UEFI-firmware eltávolítja a firmware-jelszót. 29

30 Azon felhasználók számára, akik csak saját maguknak szeretnék engedélyezni a firmware-jelszó szoftveres eltávolítását, a -disable-reset-capability kapcsoló áll rendelkezésre a firmwarepasswd parancssori eszközben a macos rendszerben. A kapcsoló beállítása előtt a felhasználónak el kell fogadnia, hogy ha a jelszót elfelejti, és ezért el kell távolítani, akkor őt terheli a művelet elvégzéséhez szükséges alaplapcsere költsége. Azoknak a szervezeteknek, akik meg szeretnék óvni a Mac gépeiket külső támadóktól és az alkalmazottaktól, be kell állítaniuk firmware-jelszót a szervezeti tulajdonban lévő rendszereken. Ez a következőképpen érhető el az eszközön: Az előkészítési időszak során a firmwarepasswd parancssori eszköz manuális használatával A firmwarepasswd parancssori eszközt használó külső felügyeleti eszközökkel Mobileszköz-felügyelet (MDM) használatával Biztonságos szoftverfrissítések A biztonságos szoftverfrissítések áttekintése Az Apple rendszeresen ad ki szoftverfrissítéseket, hogy védelmet nyújtson a felmerülő biztonsági kockázatokkal szemben, és hogy új funkciókat nyújtson; ezek a frissítések az összes támogatott eszközön párhuzamosan megjelennek. Az ios- és ipados-eszközök felhasználói értesítést kapnak a frissítésről az eszközön és az ituneson keresztül (macos és korábbi verzió) vagy a Finderen keresztül (macos és újabb verzió). A macos frissítései a Rendszerbeállításokban érhetők el. A frissítések vezeték nélküli módon érkeznek, hogy a rendszer minél hamarabb átvegye a legújabb biztonsági javításokat. Az indítási folyamat gondoskodik arról, hogy csak az Apple által aláírt kód települhessen. A Rendszerszoftver hitelesítése például biztosítja, hogy az operációs rendszer verzióinak csak az Apple aláírt, szabályszerű verziói telepíthetők az ios- és ipados-eszközökre, illetve az olyan Mac gépekre, amelyeken a Teljes biztonság beállítás van biztonságos rendszerindítási irányelvként konfigurálva a Rendszerindítás-védelem segédprogramban. Ez a rendszer megakadályozza, hogy az ios- és ipados-eszközöket leminősítsék a legújabb biztonsági frissítéseket nem tartalmazó, korábbi verziókra, és ennek segítségével az Apple képes megelőzni a hasonló leminősítést macos rendszeren is. Ezen védelem nélkül az eszközt birtokló támadó telepíthetné az ios vagy ipados korábbi verzióját, és kihasználhatná az újabb verziókban javított sebezhetőséget. Ezenkívül, amikor az eszköz fizikailag Mac géphez van csatlakoztatva, az ios vagy ipados teljes másolata letöltődik és települ. A vezeték nélküli kapcsolaton (OTA) érkező szoftverfrissítések esetén csak a frissítés elvégzéséhez szükséges komponensek töltődnek le; a teljes operációs rendszer letöltésének mellőzése javítja a hálózati teljesítményt. Ezen túlmenően a szoftverfrissítések gyorsítótárazhatók macos és újabb verziójú Mac gépen, ha a Tartalom-gyorsítótárazás be van kapcsolva, így az ios- és ipadoseszközöknek nem kell ismét letölteniük a szükséges frissítéseket az internetről. A frissítési folyamat elvégzéséhez továbbra is csatlakozniuk kell az Apple szervereihez. 30

31 A biztonságos szoftverfrissítés folyamata A frissítések során kapcsolat jön létre az Apple telepítéshitelesítési szerverével, amely tartalmaz egy listát a telepítendő telepítési csomag egyes részeire (például iboot, a kernel, az operációs rendszer képe) vonatkozó kriptográfiai mérésekről, egy véletlenszerű, visszajátszás elleni értéket (nonce) és az eszköz egyedi exkluzív chipazonosítóját (ECID). A hitelesítési szerver összeveti a bemutatott méréslistát az engedélyezett verziójú telepítésekkel, és ha egyezést talál, hozzáadja az ECID-et a méréshez, és aláírja az eredményt. A szerver a frissítési folyamat részeként egy teljes, aláírt adathalmazt ad át az eszköznek. Az ECID hozzáadása személyre szabja a kérelmező eszköz hitelesítését. A szerver azáltal, hogy csak az ismert méréseket hitelesíti és írja alá, gondoskodik arról, hogy a frissítés pontosan az Apple által kért módon zajlik. A megbízhatósági lánc rendszerindításkori kiértékelése ellenőrzi, hogy az aláírás az Appletől származik-e, és hogy a tárolóeszközről betöltött elem mérése az eszköz ECID-jével kombinálva megfelel-e az aláírás által lefedett értéknek. Ezek a lépések gondoskodnak arról, hogy a hitelesítés egy adott eszközre történik, és hogy az ios, ipados vagy az Apple T2 Security chip másik eszközről származó korábbi firmware-verziója nem másolható át. A nonce megakadályozza, hogy a támadó mentse a szerver válaszát, és felhasználja azt, hogy illetéktelenül módosítsa az eszközt, vagy más módon módosítsa a rendszerszoftvert. Secure Enclave processzorral rendelkező eszköz esetén a Secure Enclave társprocesszor a rendszerszoftver hitelesítésével gondoskodik a szoftverének integritásáról, és megakadályozza a leminősítő telepítéseket. Az operációs rendszer integritása az ios és ipados rendszer esetén Az ios és az ipados rendszerbiztonságának áttekintése Az Apple az ios platformot a biztonság középpontba helyezésével tervezte. Amikor a lehető legjobb mobilplatformot terveztük megalkotni, több évtizednyi tapasztalatból merítettünk a teljesen új architektúra felépítésére. Szem előtt tartottuk az asztali környezet biztonsági veszélyforrásait, és új megközelítéssel vágtunk bele az ios megtervezésébe. Olyan innovatív funkciókat fejlesztettünk ki és építettünk be, amelyek szorosabbra veszik a mobileszközök biztonságát, és alapértelmezés szerint a teljes rendszert védik. Ennek eredményeképpen az ios, és következésképpen az ipados hatalmas ugrást jelentenek a mobileszközök biztonságában. A kernel integritásának védelme Miután az ios és ipados kernelének incializálása megtörtént, a Kernelintegritás-védelem (KIP) bekapcsol, hogy megakadályozza a kernel és az illesztőprogramok kódjának módosítását. A memóriavezérlő védett régiót biztosít a fizikai memóriában, amelyet az iboot használ a kernel és a kernelbővítmények betöltéséhez. Ha a rendszerindítás kész, a memóriavezérlő elutasítja a fizikai memória védett területére történő írásokat. Ezenkívül az alkalmazásprocesszor memóriakezelő egysége (MMU) úgy van konfigurálva, hogy megakadályozza a fizikai memóriában lévő privilegizált kódnak a védett memóriaterületen kívüli hozzárendelését, valamint hogy megakadályozza a fizikai memória írható hozzárendeléseit a kernelmemória területén belül. 31

32 Az átkonfigurálás megakadályozása érdekében a KIP bekapcsolásához használt hardver a rendszerindítási folyamat befejezése után zárolódik. A KIP az Apple A10 és S4 SoC-kkel kezdve van támogatva. Az Apple A11 Bionic SoC esetén új hardverprimitív került a rendszerbe. Ez a primitív olyan CPU-regisztert tartalmaz, amely gyorsan korlátozza a szálankénti jogosultságokat. Ezekkel a gyors jogosultságkorlátozásokkal (APRR) az ios és ipados képes a végrehajtási jogosultságokat eltávolítani a memóriából a rendszerhívásból eredő terhelés és az oldaltábla bejárása vagy ürítése nélkül. Rendszertársprocesszor integritásának védelme A társprocesszor firmware-je számos kritikus rendszerfeladatot kezel ilyen például a Secure Enclave, a képérzékelő processzor és a Motion társprocesszor. Ebből következően ennek a biztonsága kulcsfontosságú a teljes rendszer biztonsága érdekében. Az Apple, annak érdekében, hogy megakadályozza a társprocesszor firmware-jének módosítását, a rendszertársprocesszor integritásának védelme (SCIP) nevű mechanizmust alkalmazza, amelyet az Apple A12 és S4 SoC-kkel kezdődően támogatnak az SoC-k. Az SCIP a kernelintegritás-védelemhez nagyon hasonlóan működik: Rendszerindításkor az iboot betölti az egyes társprocesszorok firmware-jét a védett, foglalt és a KIP-területtől elválasztott memóriaterületre. Az iboot úgy konfigurálja az egyes társprocesszorok memóriáját, hogy megakadályozza a következőket: Végrehajtható hozzárendelések a védett memóriaterület-részen kívül Írható hozzárendelések a védett memóriaterület-részen belül Rendszerindításkor továbbá a Secure Enclave operációs rendszere van használatban az SCIP Secure Enclave processzorhoz való konfigurálásához. Ha a rendszerindítási folyamat kész, az SCIP bekapcsolásához használt hardver zárolódik az átkonfigurálás megelőzése érdekében. Mutatóhitelesítési kódok A mutatóhitelesítési kódok (PAC-k) támogatása az Apple A12 és S4 SoC-kkel kezdődik, és segítségükkel kivédhetők a memóriasérülési hibákkal való visszaélések. A rendszerszoftver és a beépített alkalmazások a PAC használatával akadályozzák meg a függvénymutatók és visszatérési címek (kódmutatók) módosítását. A PAC öt titkos, 128 bites értékkel írja alá a kernelutasításokat és az adatokat, és a felhasználói térben zajló mindegy egyes folyamatnak megvan a saját B kulcsa. Az elemek az alábbi táblázatnak megfelelően vannak sózva és aláírva: Elem Kulcs Só Függvény visszatérési címe IB Tárhelycím Függvénymutató IA 0 Blokkhívási függvény IA Tárhelycím Objective-C metódus gyorsítótára IB Tárhelycím + osztály + kiválasztó C++ V-táblabejegyzések IA Tárhelycím + hash (felismerhetetlen metódus neve) 32

33 Elem Kulcs Só Kiszámított ugrási cím IA Hash (függvénynév) Kernelszál állapota GA Felhasználói szálak állapotának regiszterei IA Tárhelycím C++ V-táblamutatók DA 0 Az aláírási érték a 64 bites mutató tetején lévő, nem használt kitöltő bitekben tárolódik. A rendszer a használat előtt ellenőrzi az aláírást, és a kitöltés vissza van állítva, hogy a mutató címe biztosan működjön. Az ellenőrzés sikertelensége olyan speciális érték beállítását eredményezi, amely érvényteleníti a címet, továbbá ios 13 és ipados 13.1 esetén megszakad a folyamat. Ez az ellenőrzés sok támadás számára megnöveli a nehézséget, például a visszatérés-orientált (ROP) támadás számára is, amely úgy próbálja meg rávenni az eszközt a meglévő kód rosszindulatú végrehajtására, hogy manipulálja a függvények veremben tárolt visszatérési címeit. A PAC-k az Apple A12 és S4 SoC-kkel kezdődően vannak támogatva. Oldalvédelmi réteg Az ios és az ipados oldalvédelmi rétege (PPL) védi a felhasználói tér kódját a módosítástól, miután a kódaláírás ellenőrzése megtörtént. A KIP-re és az APRR-re épülve gondosan ellenőrzi az oldaltábla-engedélyek felülírásait, és így gondoskodik arról, hogy csak a PPL módosíthassa a felhasználói kódot és oldaltáblákat tartalmazó védett oldalakat. A rendszer még sérült kernel esetén is nagy mértékben csökkenti a támadási felületet azáltal, hogy a kódintegritást a teljes rendszerben kikényszeríti. Az operációs rendszer integritása a macos rendszer esetén A macos rendszerbiztonságának áttekintése Az Apple a hardver, szoftver és szolgáltatások olyan integrált megközelítésével tervezte a macos platformot, amely kialakításánál fogva biztonságot nyújt, és könnyen konfigurálhatóvá, telepíthetővé és kezelhetővé teszi. A macos tartalmazza azokat a főbb biztonsági technológiákat, amelyekre az IT-szakembereknek szükségük van, hogy megvédjék a vállalati adatokat, és integrációt hajthassanak végre biztonságos vállalati hálózati környezetekben. Az Apple együttműködött szabványügyi testületekkel is, hogy megfeleljen a legújabb biztonsági tanúsítványoknak. 33

34 A Mac gépek firmware-biztonsága Az UEFI-firmware biztonságának áttekintése 2006 óta az Intel-alapú processzorral rendelkező Mac gépek a bővíthető firmwareinterfész (EFI) 1. vagy 2. verziójú fejlesztési csomagján (DK) alapuló Intel-firmware-t használnak. Az EDK2-alapú kód megfelel az egyesített bővíthető firmware-interfész (UEFI) specifikációjának. Ez a szakasz az Intel-firmware-re UEFI-firmware-ként hivatkozik. Az UEFI-firmware az első végrehajtott kód volt az Intel chipen. Annak érdekében, hogy megakadályozzák az UEFI-firmware-t tároló firmware-tároló chiphez fizikailag kapcsolódó támadásokat, a Mac gépek új architektúrát kaptak 2017-ben, és a megbízhatóságot az Apple T2 Security chipben tárolt UEFI-firmwareben gyökereztetik. Az ilyen Mac gépeken az UEFI-firmware megbízhatósági gyökere kifejezetten a T2 firmware-je. Ez a kialakítás a T2 chipet bízza meg azzal, hogy védje az UEFI-firmware-t (és a teljes biztonságos rendszerindítást) a tartós fertőzéstől, majdnem ugyanolyan módon, ahogy az A sorozatú SoC-k védik a rendszerindítást ios és ipados esetén. Az Apple T2 Security chip nélküli Mac gépek esetén a megbízhatóság gyökere az UEFI-firmware számára az a chip, amelyben a firmware tárolva van. Az UEFI-firmware frissítéseit az Apple digitálisan aláírja, és a firmware ellenőrzi, mielőtt frissíti a tárolót. A visszaforgatási támadások megakadályozása érdekében a frissítéseknek mindig kötelezően újabb verziójúnak kell lenniük a meglévőnél. A Mac géphez fizikailag hozzáférő támadó azonban hardverrel hozzáférhet a firmware-t tároló chiphez, és rosszindulatú tartalommal frissítheti a chipet. Hasonlóképpen az is az UEFI-firmware maradandó fertőzéséhez vezethet, ha sebezhetőségek találhatók az UEFI-firmware korai rendszerindítási folyamatában (mielőtt az korlátozza a tároló chip írhatóságát). Ez olyan hardverarchitektúrás korlátozás, amely általános az Intel-alapú PC-kben, és jelen van a T2 chip nélküli Mac gépekben is. Ennek a korlátozásnak a feloldására a Mac gépek új architektúrát kaptak, amely az UEFIfirmware megbízhatósági gyökerét az Apple T2 Security chipbe helyezi. Az ilyen Mac gépeken az UEFI-firmware megbízhatósági gyökere kifejezetten a T2 firmware-je, a szakasz későbbi részében, a macos rendszerindítási szakaszban leírtaknak megfelelően. A támadó csak úgy fertőzheti meg tartósan az UEFI-firmware-t, ha tartósan megfertőzi a T2 firmware-jét. Intel Management Engine (ME) Az Intel Management Engine (ME) firmware az UEFI-firmware-ben tárolt egyik részkomponens. Az ME az Intel chipek egy különálló processzora és alrendszere használható távoli felügyeletre, védett hang és videó céljára, valamint a biztonság javítására. A támadási felület csökkentése érdekében a Mac gépek egyéni ME-firmware-t futtatnak, amelyből a komponensek nagy része el van távolítva. Ennek köszönhetően a Mac gép ME-firmware-je kisebb, mint az Intel által elérhetővé tett minimális build. Következésképpen sok olyan komponens (például az Active Management Technology), amely a múltban a biztonsági kutatók által nyilvános támadások célpontja lett, nincs jelen a Mac gépek ME-firmware-jében. Az ME elsődleges felhasználási területe a hang és a videó másolásvédelme a csak Intel-alapú grafikus kártyával rendelkező Mac gépeken. 34

35 Rendszerkezelési mód (SMM) Az Intel processzorok rendelkeznek egy, a normál működéstől eltérő speciális végrehajtási móddal. A rendszerkezelési mód (SMM) eredeti célja az időérzékeny műveletek, például az energiagazdálkodás kezelése volt. Az ilyen műveletek végrehajtására azonban a Mac gépek hagyományosan a System Management Controller (SMC) nevű különálló mikrovezérlőt használták. Az SMC többé már nem különálló mikrovezérlő; integrálva lett az Apple T2 Security chipbe. A biztonságos rendszerindítást támogató PC-ken az SMM egy további szereppel rendelkezik; olyan védett végrehajtási környezet, amely kizárólagos hozzáférést kaphat a biztonságra érzékeny tartalomhoz, mint amilyen az UEFI-firmware tároló chipjén lévő kód és biztonsági irányelv írási elérése. Szerepéből fakadóan a támadók gyakran szemelik ki maguknak az SMM végrehajtási környezetbe való betörést a jogosultságok megemelésére, hogy olyan műveleteket hajthassanak végre, amelyeket a kernel nem tud, és így potenciálisan megtörjék a biztonságos rendszerindítást. Mac gépeken az SMM végrehajtási környezet a lehető legkisebb mértékben van használva, és nincs biztonsági határ szerepe a biztonságos rendszerindítás céljára. A biztonságos rendszerindítás így akkor is sértetlen, ha az SMM sérül. A T2 chipen a jogosultsághatár az a művelet, amelyet a chip kizárólagos módon végre tud hajtani. DMA-védelmek A számítógépek akkor érnek el nagy átvitelt a nagy sebességű interfészeken, mint a PCIe, FireWire, Thunderbolt és USB, ha támogatják a perifériákról való közvetlen memóriaelérést (DMA). Azaz úgy kell tudniuk olvasni és írni a RAM-ban, hogy az Intel processzort nem vonják be a folyamatba óta a Mac gépek számos technológiát implementáltak a DMA védelmére, és ezek a legjobb és legátfogóbb DMA-védelmi készletet jelentik minden PC esetében. Az Intel Virtualization Technology for Directed IO (VT-d) olyan technológia, amelyet 2012 óta támogatnak a Mac gépek, és először az OS X 10.9 alkalmazta, hogy védje a kernelt attól, hogy rosszindulatú perifériák felülírják a memóriában. Azonban a rosszindulatú perifériák felülírhatják a kódot és az adatokat az UEFI-firmware futása közben a rendszerindítás biztonságának megváltozatásához. A macos frissítette az UEFIfirmware-t az VT-d-kompatibilis Mac számítógéphez, hogy azok a VT-d-t használják a rosszindulatú FireWire- és Thunderbolt-perifériák elleni védelemhez. El is szigeteli továbbá a perifériákat, így azok csak a saját memóriatartományaikat látják, a többi periféria memóriáját nem. Az UEFI-ben futó Ethernet-periféria például nem tudja olvasni a tároló periféria memóriáját. Az UEFI-firmware-ben lévő DMA-védelmek tovább lettek fejlesztve a macos rendszerben, hogy az inicializálást az UEFI-firmware indítási sorrendjének korábbi szakaszába helyezzék, és védelmet nyújtsanak a következők ellen: Rosszindulatú belső perifériás processzorok a PCIe-buszon Biztonsági kutatók által bemutatott Message Signaled Interrupt (MSI) osztályú támadások 35

36 Az Apple T2 Security chippel rendelkező összes Mac gép továbbfejlesztett DMAvédelemmel rendelkezik, ahol az inicializálás a lehető legkorábban történik. A védelem még azelőtt bekapcsol, hogy a RAM elérhető lenne az UEFI-firmware számára. Ez védelmet nyújt az esetlegesen futó, és DMA-ra képes, sérült PCIe nulla buszos eszközök ellen (mint például az Intel ME) abban a pillanatban, hogy a RAM elérhetővé válik. Ezt a védelmet a T2 chip nélküli Mac gépek is megkapták a macos rendszerben. Option ROM-ok Mind a Thunderbolt-, mind a PCIe-eszközök rendelkezhetnek úgy nevezett Option ROMmal (OROM), amely fizikailag csatlakozik az eszközhöz. (Ez általában nem igazi ROM, hanem olyan újraírható chip, amely a firmware-t tárolja.) UEFI-alapú rendszerek esetén a firmware jellemzően UEFI-illesztőprogram, amelyet az UEFI-firmware olvas be és hajt végre. A végrehajtott kódnak azt a hardvert kell inicializálnia és konfigurálnia, amelyre be lett olvasva, hogy a hardver a firmware többi része számára is használható legyen. Erre a képességre azért van szükség, hogy a speciális külső hardver a rendszerindítás legkorábbi szakaszaiban is be tudjon töltődni és működni tudjon például külső RAID-tömbről való rendszerindítás esetén. Mivel azonban az OROM-ok általában újraírhatók, ha a támadó felülírja a szabályszerű periféria OROM-ját, akkor a támadó kódja a rendszerindítás korai szakaszában végrehajtódik, és képes illetéktelenül módosítani a végrehajtási környezetet, és megsérteni a következőkben betöltött szoftverek integritását. Hasonlóképpen, a támadó akkor képes lenne rosszindulatú kód végrehajtására, ha saját rosszindulatú eszközét viszi be a rendszerbe. 36

37 A macos rendszerben a 2011 után értékesített Mac gépek viselkedése úgy módosult, hogy ne hajtsa végre alapértelmezésben az OROM-okat a Mac gép rendszerindításakor, hacsak a felhasználó egy speciális billentyűkombinációt meg nem nyom. Ez a billentyűkombináció védelmet nyújtott a macos rendszerindítási sorrendjébe nem szándékosan bevitt rosszindulatú OROM-ok ellen. A Firmware-jelszó segédprogram alapértelmezett viselkedése is módosult: ha a felhasználó firmware-jelszót állít be, az OROM-ok nem tudnak végrehajtódni, még ha a felhasználó meg is nyomja a billentyűkombinációt. Ez védelmet nyújtott az ellen, ha a fizikailag jelen lévő támadó rosszindulatú OROM-ot szeretett volna a rendszerbe juttatni. Azon felhasználók számára, akik továbbra is szeretnék futtatni az OROM-okat, miközben be van állítva firmware-jelszó, konfigurálható egy nem alapértelmezett beállítás a macos firmwarepasswd parancssori eszközében. Option ROM (OROM) homokozó. OROM-homokozó A macos rendszerben az UEFI-firmware úgy frissült, hogy homokozót és jogosultságmegvonást tartalmazzon az OROM-ok számára. Az UEFI-firmware jellemzően a 0. körnek nevezett, legmagasabb Intel CPU jogosultsági szinten hajtja végre az összes kódot, beleértve az OROM-okat, és egyetlen megosztott virtuálismemória-teret biztosít az összes kód és adat számára. A 0. kör az a jogosultsági szint, amelyen a macos kernele is fut, az alsóbb jogosultsági szintű 3. körön pedig az alkalmazások futnak. Az OROM-homokozó visszaveszi az OROM-ok jogosultsági szintjét azáltal, hogy a kernelhez hasonlóan elkülönített virtuális memóriát használ, és azután az OROM-okat a 3. körön futtatja. 37

38 A homokozó jelentősen korlátozza továbbá mind az OROM-ok által hívható interfészeket (ez hasonlít a kernelekben a rendszerhívásokhoz), mind azokat az eszköztípusokat, amelyekre az OROM regisztrálhat (ez az alkalmazások fehérlistájához hasonlít). Ennek a kialakításnak az előnye, hogy a rosszindulatú OROM-ok többé nem képesek közvetlenül írni sehova a 0. körű memóriában; helyette egy nagyon keskeny és nagy jól meghatározott homokozóinterfészre korlátozódnak. Ez a korlátozott interfész jelentősen csökkenti a támadási felületet, és arra kényszeríti a támadót, hogy először lépjen ki a homokozóból, és emelje meg a jogosultságot. Perifériák firmware-biztonsága A Mac gépek számos olyan beépített perifériás processzorral rendelkezik, amelyek bizonyos feladatot látnak el, például hálózatkezelés, grafika, teljesítménygazdálkodás vagy az olyan buszok kezelése, mint az USB és a Thunderbolt. A perifériás firmware-ek gyakran egyetlen célra készülnek, és sokkal kisebb teljesítményűek, mint az Intel processzor. Az olyan beépített perifériák azonban, amelyek nem implementálnak megfelelő biztonságot, célpontjaivá válnak a könnyebben kihasználható célpontokat kereső támadóknak, és tartósan megfertőzhetik az operációs rendszert. Ha a támadó megfertőzte a perifériás processzor firmware-jét, célba veheti az Intel processzor szoftverét, vagy közvetlenül elfoghat érzékeny adatokat (az Ethernet-eszközök például látják a nem titkosított csomagok tartalmát). Az Apple stratégiai szempontból külső beszállítókkal dolgozik, hogy (ahol csak lehet) csökkentse a szükséges perifériás processzorok számát, illetve hogy elkerülje a firmware-t igénylő kialakításokat. Amikor azonban firmware-re van szükség, erőfeszítéseket tesz, hogy a támadó ne hatolhasson be a processzorba. Ez a következőképpen érhető el: A processzor olyan módban való futtatása, amelyben indításkor letölti az Intel processzorból az ellenőrzött firmware-t Gondoskodás arról, hogy a perifériás processzor implementálja a saját biztonságos rendszerindítási láncát, amelyben minden rendszerindításkor ellenőrzi a saját firmwarejét Az Apple együttműködik a beszállítókkal, hogy auditálja az implementációikat, és javítsa a terveket, hogy olyan javasolt tulajdonságokkal rendelkezzenek, mint: Gondoskodás a minimális kriptográfiai erősségről Az ismert helytelen firmware-ek erős visszahívása Hibakereső interfészek letiltása A firmware-ek aláírása az Apple által irányított hardverbiztonsági modulokban (HSM-ek) tárolt kriptográfiai kulcsokkal Az elmúlt években az Apple együttműködött néhány külső beszállítóval, hogy adoptálják az ios-, ipados-eszközök és a T2 Security chippel rendelkező Mac gépekével azonos Image4 adatstruktúrákat, ellenőrzési kódot és aláírási infrastruktúrát. Ha sem a tárolómentes működés, sem a tároló, plusz biztonságos rendszerindítás nem oldható meg, akkor a kialakítás megköveteli, hogy a tartós tárhely frissítése előtt a firmware-frissítések kriptográfiailag aláírtak és ellenőrzöttek legyenek. 38

39 Kötelező hozzáférés-szabályozások A macos kötelező hozzáférés-szabályozásokat is használ ezek olyan irányelvek, amelyek a fejlesztő által létrehozott, nem felülírható biztonsági korlátozásokat állítanak be. Ez a megközelítés eltér a feltételes hozzáférés-szabályozásoktól, ami lehetővé teszi a felhasználók számára, hogy igényeik szerint felülírják a biztonsági irányelveket. A kötelező hozzáférés-szabályozások nem láthatók a felhasználók számára, de ezek jelentik a mögöttes technológiát számos fontos funkció esetén, mint például a homokozó, a szülői felügyelet, a felügyelt beállítások, a bővítmények és a rendszerintegritás-védelem. Rendszerintegritás-védelem Az OS X és az újabb verziók rendelkeznek a Rendszerintegritás-védelem nevű rendszerszintű védelemmel; ez a funkció bizonyos kritikus fájlrendszerhelyek esetén az írásvédett helyekre korlátozza a komponenseket, hogy a rosszindulatú kódok ne tudják azokat módosítani. A Rendszerintegritás-védelem számítógép-specifikus beállítás, amely alapértelmezés szerint be van kapcsolva, amikor a felhasználó OS X vagy újabb rendszerre frissít; kikapcsolásával elvész a fizikai tárolóeszközön lévő összes partíció védelme. A macos a rendszeren futó összes folyamatra alkalmazza ezt a biztonsági irányelvet, függetlenül attól, hogy az a homokozóban fut, vagy rendszergazdai jogosultságokkal rendelkezik. Kernelbővítmények A kernelbővítmények (KEXT-ek) használata már nem javasolt a macos rendszer esetén. A KEXT-ek kockázatot jelentenek az operációs rendszer integritására és megbízhatóságára, és a felhasználóknak célszerűbb olyan megoldásokat keresniük, amelyekhez nem szükséges a kernel bővítése. Ha macos esetén a fejlesztők bővíteni szeretnék a macos képességeit, akkor a kernelszint helyett a felhasználói térben futó rendszerbővítményeket telepíthetnek és felügyelhetnek. A rendszerbővítmények azáltal, hogy a felhasználói térben futnak, növelik a macos stabilitását és biztonságát. Míg a KEXT-ek felépítésükből adódóan teljes hozzáféréssel rendelkeznek az operációs rendszerhez, addig a felhasználói térben futó bővítmények csak a megadott funkciójukhoz szükséges jogosultságokkal rendelkeznek. A felhasználók olyan keretrendszerek használatával, mint a DriverKt, EndpointSecurity és NetworkExtension, USB- és HID-illesztőprogramokat, végpontbiztonsági eszközöket (például adatvesztés-megelőzési és más végpontügynököket), illetve VPN- és hálózati eszközöket írhatnak mindezt KEXT-ek írása nélkül. A külső biztonsági ügynököket csak akkor célszerű használni, ha ki tudják használni ezeket az API-kat, vagy ha robusztus térképpel rendelkeznek a feléjük való és a kerneltől eltávolodó átmenetre. A macos továbbra is biztosítja a kernelbővítmény mechanizmusát, hogy a kód dinamikusan betölthető legyen a kernelbe anélkül, hogy újból össze kellene állítani, vagy újra kellene csatolni. A biztonság növelése érdekében felhasználói beleegyezés szükséges a macos rendszerrel vagy később telepített kernelbővítmények betöltéséhez. Ennek a neve Felhasználó által jóváhagyott kernelbővítmény betöltése. A kernelbővítmény jóváhagyásához rendszergazdai felhatalmazás szükséges. A kernelbővítményhez nem szükséges felhatalmazás, ha: a macos rendszerre való frissítés előtt telepítve voltak a Mac gépre; 39

40 korábban jóváhagyott bővítményeket cserélnek; jogosultak betöltődni felhasználói beleegyezés nélkül a macos-visszaállításból való indulás során az spctl parancssori eszköz használatával; jogosultak betöltődni mobileszköz-felügyeleti (MDM) konfiguráció használatával. A macos rendszerrel kezdve a felhasználók az MDM segítségével megadhatják azon kernelbővítmények listáját, amelyek felhasználói beleegyezés nélkül betöltődhetnek. Ehhez a lehetőséghez olyan Mac gép szükséges, amely az Apple School Manager, Apple Business Manager vagy felhasználói MDM-feliratkozás használatával MDM-be feliratkozott macos rendszert futtat. Rendszerbiztonság a watchos rendszerben A watchos rendszerbiztonságának áttekintése Az Apple Watch az ios és ipados számára készült biztonsági funkciókat és technológiát használja, hogy védje az eszközön lévő adatokat, és védje a párosított iphone-nal, valamint az interneten keresztül végzett kommunikációt. Ezek olyan technológiákat foglalnak magukban, mint a Data Protection és a Kulcskarika elérésének szabályozása. A felhasználó jelkódja is össze van csomózva az eszköz UID-jával biztonsági kulcsok létrehozásáért. Az Apple Watch iphone-nal való párosításának biztonságossá tételéhez a kulcsegyeztetés sávon kívüli (OOB) folyammattal történik, amelyet a Bluetooth Low Energy (BLE) kapcsolat közös titka követ. Az Apple Watch animált mintát jelenít meg, amelyet az iphone kamerája rögzít. A minta olyan kódolt titkot tartalmaz, amelyet a BLE 4.1 sávon kívüli párosítás használ. Szükség esetén a standard BLE-jelkulcsbevitel használható tartalék párosítási módszerként. Amikor a BLE-munkamenet létrejött és titkosítottá vált a Bluetooth Core Specification szabványban elérhető legmagasabb biztonsági protokoll használatával, az Apple Watch és az iphone kulcsokat egyeztet az Apple-identitásszolgáltatásból (IDS) átvett folyamattal Az imessage áttekintése részben leírtak szerint. A kulcsok egyeztetése után a rendszer elveti a Bluetooth-munkamenetkulcsot, és az Apple Watch és az iphone közötti minden kommunikáció az IDS használatával van titkosítva; a titkosított Bluetooth-, Wi-Fi- és mobilhálózati kapcsolatok másodlagos titkosítási réteget nyújtanak. A Low Energy Bluetooth cím 15 perces időközönként vált, hogy csökkentse az eszköz helyi követhetőségének kockázatát, amelyet az állandó azonosító sugárzása jelentene. Az adatokat streamelő alkalmazások támogatása érdekében titkosítás történik a FaceTime részben leírt módszerekkel, amelyek vagy a párosított iphone által biztosított IDSszolgáltatást használják, vagy közvetlen internetkapcsolatot. Az Apple Watch a fájlok és a kulcskarikaelemek hardveres titkosítású tárolását és osztályalapú védelmét implementálja, jelen dokumentum Titkosítás és Data Protection című részében leírtaknak megfelelően. A rendszer szabályozott elérésű kulcstartókat is használ a kulcskarikaelemekhez. Az óra és az iphone közötti kommunikációhoz használt kulcsok szintén osztályalapú védelemmel vannak védve. 40

41 Amikor az Apple Watch nincs a Bluetooth-tartományon belül, a rendszer Wi-Fi-t vagy mobilhálózatot használ. Az Apple Watch automatikusan csatlakozik azokhoz a Wi-Fihálózatokhoz, amelyekhez a párosított iphone már csatlakozott, és a hitelesítő adataik szinkronizálódtak az Apple Watchra, amikor mindkét eszköz tartományon belül volt. Az automatikus csatlakozás hálózatalapon konfigurálható az Apple Watch Beállítások alkalmazásának Wi-Fi szakaszában. Azokhoz a Wi-Fi-hálózatokhoz, amelyekhez még egyetlen eszköz sem csatlakozott korábban, manuálisan lehet csatlakozni az Apple Watch Beállítások alkalmazásának Wi-Fi szakaszában. Amikor az Apple Watch és az iphone tartományon kívül van, az Apple Watch közvetlenül kapcsolódik az icloud és a Gmail szervereihez a levelek beolvasásához, nem pedig a párosított iphone-nal szinkronizálja a Mail-adatokat az interneten keresztül. Gmailfiókok esetén a felhasználónak hitelesítenie kell magát a Google-nál az iphone Óra alkalmazásának Mail szakaszában. A Google-tól fogadott OAuth-tokent az eszköz az Apple Watchra küldi titkosítva az Apple-identitásszolgáltatáson (IDS) keresztül, hogy a Mail be tudja olvasni. A rendszer soha nem használja ezt az OAuth-tokent az iphone-ról a Gmailszerverrel való csatlakozáshoz. Ha a csuklóérzékelés engedélyezve van, az eszköz automatikusan zárolódik röviddel azután, hogy nem érzékeli a felhasználó csuklóját. Ha a csuklóérzékelés le van tiltva, a Kapcsolóvezérlés lehetőséget nyújt az Apple Watch zárolására. Amikor az Apple Watch zárolva van, az Apple Pay csak az óra jelkódjának megadásával használható. A csuklóérzékelés az iphone Apple Watch alkalmazásával kapcsolható ki. A beállítás ki is kényszeríthető mobileszköz-felügyeleti (MDM) megoldás használatával. A párosított iphone is képes feloldani az órát, ha az óra a felhasználó csuklóján van. Ennek eléréséhez a párosítás során kialakított kulcsokkal hitelesített kapcsolatot kell létrehozni. Az iphone elküldi a kulcsot, amellyel az óra feloldja a Data Protection-kulcsait. Az iphone nem ismeri és nem is kapja meg az óra jelkódját. Ez a funkció az iphone Apple Watch alkalmazásával kapcsolható ki. Az Apple Watch egyszerre csak egy iphone-nal párosítható. Az iphone, amikor megszűnik a párosítás, arra ad utasítást, hogy minden tartalom és adat törlődjön az Apple Watchról. Az Apple Watch konfigurálható úgy, hogy ugyanazon az éjjelen kapjon rendszerszoftverfrissítést. Ha további információra kíváncsi az Apple Watch jelkódjának frissítés közben történő tárolásáról és felhasználásáról, olvassa el a Kulcstartók című részt. Ha bekapcsolja a Lokátort a párosított iphone-on, akkor engedélyezi az aktiválási zár használatát az Apple Watchon. Az aktiválási zárral nehezebb használni vagy eladni az elveszett vagy ellopott Apple Watchot. Az aktiválási zár megköveteli a felhasználó Apple ID-ját és jelszavát az Apple Watch párosításának megszüntetéséhez, törléséhez vagy újbóli aktiválásához. Az Apple Watch használata a macos rendszerrel Automatikus feloldás az Apple Watchcsal macos rendszerben Az Apple Watch segítségével a felhasználó automatikusan feloldhatja a Mac gépét. A Bluetooth Low Energy (BLE) és a társközi Wi-Fi segítségével az Apple Watch biztonságosan feloldhatja a Mac gépet, ha kellően közel vannak egymáshoz az eszközök. Ehhez konfigurált kétlépéses hitelesítéssel (TFA) rendelkező icloud-fiók szükséges. 41

42 Ha engedélyezi, hogy az Apple Watch feloldja a Mac gépet, automatikus feloldású identitások funkciót használó biztonságos kapcsolat jön létre. A Mac véletlenszerű, egyszer használatos feloldási titkot hoz létre, és a kapcsolaton keresztül átadja az Apple Watchnak. A titok az Apple Watchon tárolódik, és csak akkor érhető el, amikor az Apple Watch fel van oldva. A feloldási token nem a felhasználó jelszava. A feloldási művelet során a Mac BLE segítségével hoz létre kapcsolatot az Apple Watchcsal. Ezután biztonságos kapcsolat épül ki a két eszköz között, amely az első engedélyezéskor használt megosztott kulcsokat használja. A Mac és az Apple Watch ezután társközi Wi-Fi-t és a biztonságos kapcsolatból származtatott biztonságos kulcsot használ a két eszköz közötti távolság meghatározásához. Ha az eszközök tartományon belül vannak, a biztonságos kapcsolaton megtörténik az előzetesen megosztott titok átvitele a Mac gép feloldásához. A sikeres feloldás után a Mac gép lecseréli az aktuális feloldási titkot egy új, egyszer használatos feloldási titokra, és a kapcsolaton keresztül átadja az új feloldási titkot az Apple Watchnak. Jóváhagyás az Apple Watchcsal Ha engedélyezve van az automatikus feloldás az Apple Watchcsal, akkor az Apple Watch használható a Touch ID helyett, vagy azzal együtt, a jóváhagyási és hitelesítési kérelmek elfogadásához a következőktől: Jogosultságot kérelmező macos- és Apple-alkalmazások Hitelesítést kérelmező külső alkalmazások Mentett Safari-jelszavak Biztonsági jegyzetek 42

43 Titkosítás és Data Protection A titkosítás és a Data Protection áttekintése A biztonságos rendszerindítási lánc, a rendszerbiztonsági és az alkalmazásbiztonsági képességek mind segítenek gondoskodni arról, hogy az eszközön csak megbízható kódok és alkalmazások fussanak. Az Apple-eszközök további titkosítási funkciókkal őrzik a felhasználók adatait, még akkor is, ha a biztonsági infrastruktúra más részei meghibásodnak (ha például az eszköz elvész, vagy nem megbízható kódot futtat). Ezek a funkciók előnyöket nyújtanak mind a felhasználók, mind az IT-rendszergazdák számára, folyamatosan védik a személyes és vállalati adatokat, és lehetőséget biztosítanak az adatok azonnali és teljes törlésére abban az esetben, ha az eszközt ellopják, vagy elvész. Az ios- és ipados-eszközök egy Data Protection nevű fájltitkosítási metódust használnak, a Mac gépeken pedig a FileVault nevű technológia titkosítja a kötetet. Mindkét modell a Secure Enclave dedikált chipjén tárolja a kulcskezelési hierarchiáit (SEP-t használó eszközök esetén), és mindkét modellt a dedikált AES-motort használja a teljes sebességű titkosításhoz, és hogy biztosítsa, hogy a hosszú életű titkosítási kulcsok soha ne kerüljenek a kernel operációs rendszerhez vagy a CPU-hoz (ahol feltörhetnék őket). Ezenfelül az operációs rendszer kernelje hozzáférés-vezérlőkkel akadályozza meg az adatokhoz való jogosultatlan hozzáférést. Ezek a vezérlők gyakran az alkalmazások sandboxba helyezéseként vannak megvalósítva (ami korlátozza, milyen adatokhoz fér hozzá egy alkalmazás), valamint Adatszéfek használatával. Az Adatszéfek fordított sandboxként foghatók fel. Az alkalmazás által végrehajtható hívások korlátozása helyett az Adatszéfek attól függetlenül korlátozzák a védett adatokhoz való hozzáférést (ismételten, a kerneltől független fájltitkosítással), hogy a kiinduló folyamat sandboxban van-e. A felhasználók személyes adatainak védelme az Apple által A tárolt adatok titkosításán felül az Apple-eszközök számos technika (például az Adatszéf) használatával segítenek megakadályozni azt, hogy az alkalmazások engedély nélkül hozzáférjenek a felhasználó személyes adataihoz. Az ios és ipados Beállítások alkalmazásában, valamint a macos Rendszerbeállítások alkalmazásában a felhasználók megtekinthetik, hogy mely alkalmazásoknak adtak engedélyt bizonyos információk elérésére, valamint megadhatják és visszavonhatják a további hozzáférést. A hozzáférés kényszerítve van a következőknél: ios, ipados és macos: Naptárak, Kamera, Kontaktok, mikrofon, Fotók, Emlékeztetők, Hangfelismerés 43

44 ios és ipados: Bluetooth, Otthon, Média, médiaalkalmazások és Apple Music, Mozgás és fitnesz ios és watchos: Egészség macos: Bevitelfigyelés (például a megnyomott billentyűk), rákérdezés, képernyőfelvétel (állófelvételek és videók), Rendszerbeállítások Az ios 13.4 és az ipados 13.4 rendszertől a harmadik felek alkalmazásainak adatai automatikusan egy Adatszéfben vannak védve. Es segít megakadályozni az adatokhoz való jogosulatlan hozzáférést még az olyan folyamatok esetén is, amelyek nincsenek sandboxban. Ha a felhasználó bejelentkezik az icloudba, az ios és ipados alkalmazásai alapértelmezés szerint hozzáférést kapnak az icloud Drive-hoz. A felhasználó a Beállítások alkalmazásban szabályozhatja az egyes alkalmazások hozzáférését. Az ios és az ipados ezenkívül olyan korlátozásokat biztosít, amelyek meggátolják a mobileszköz-felügyeleti (MDM) megoldás vagy a felhasználó által telepített alkalmazások és fiókok közötti adatmozgásokat. Az Apple File System szerepe Az Apple File System (APFS) olyan szabadalmazott fájlrendszer, amelynek tervezésekor a titkosítás kiemelt szerepet játszott. Az APFS minden Apple-platformon használható ios, ipados, macos, tvos és watchos esetén is. A Flash/SSD-tárolóra optimalizált rendszer erős titkosítást, írásnál másolt metaadatokat, tárhelymegosztást, a fájlok és mappák klónozását, pillanatfelvételeket, gyors könyvtár-szinkronizálást, atomic safesave primitíveket és továbbfejlesztett fájlrendszeralapokat kínál, valamint egyedi írásnál másolásos kialakítást, amely I/O-egyesítést kínál a teljesítmény maximalizálásához az adatok megbízhatósága mellett. Az APFS igény szerint osztja ki a tárhelyet. Ha egyetlen APFS-tárolónak több kötete is van, akkor a tároló szabad területe meg van osztva, és szükség szerint felosztható az egyes kötetek között. Az egyes kötetek csak az egész tároló egy részét használják, így az elérhető tárhely a tároló teljes mérete, csökkentve a tároló összes kötetében használt tárhellyel. A macos rendszerben a Mac indításához használt APFS-tárolónak legalább öt kötettel kell rendelkeznie, amelyből az első három el van rejtve a felhasználó elől: Előzetes rendszerindítási kötet: a tároló összes rendszerkötetének indításához szükséges adatokat tartalmazza VM-kötet: a macos használja lapozófájl-tárhelyként Helyreállító kötet: a visszaállítási operációs rendszert tartalmazza Rendszerkötet: a következőket tartalmazza: A Mac gép indításához szükséges összes fájl A macos által natívan telepített összes alkalmazás (az eddig az /Applications mappában lévő alkalmazások most már a /System/Applications mappában találhatók) Adatkötet: a módosuló adatokat tartalmazza, például: A felhasználó mappájában tárolt összes tartalom, beleértve a fotókat, zenéket, videókat és dokumentumokat 44

45 A felhasználó által telepített alkalmazások, beleértve az AppleScript- és Automatoralkalmazásokat A felhasználó, szervezet vagy külső alkalmazások által telepített egyéni keretrendszerek és démonok A felhasználó tulajdonát képező és általa írható helyek, például /Applications, / Library, /Users, /Volumes, /usr/local, /private, /var és /tmp Minden további System kötethez egy Data kötet van létrehozva. A Preboot, a VM és a Recovery kötet meg van osztva, de nincs megkettőzve. Megjegyzés: Alapértelmezés szerint a folyamatok nem írhatnak a System kötetre, még az Apple-rendszerfolyamatok sem. A Data Protection az ios és ipados rendszerben A Data Protection áttekintése Az ios és ipados rendszerben az Apple egy Data Protection nevű technológiával védi az eszköz flash-tárolóján tárolt adatokat. A Data Protection segítségével az eszköz válaszolhat olyan általános eseményekre, mint a bejövő telefonhívás, miközben a felhasználói adatok magas szinten védve maradnak. Az olyan lényeges rendszeralkalmazások, mint az Üzenetek, a Mail, a Naptár, a Kontaktok, a Fotók és az Egészségadatok alapértelmezés szerint használják a Data Protectiont, és az ios 7 vagy újabb, illetve az ipados 13.1 rendszeren telepített külső alkalmazások automatikusan megkapják ezt a védelmet. Implementáció A Data Protection egy kulcshierarchia megalkotásából és kezeléséből áll rendszerbe, és a minden egyes ios- és ipados-eszközbe beépített hardveres titkosítási technológiára épül. A Data Protection fájlalapon van szabályozva; minden fájlhoz egy osztályt rendel, és az elérhetőség attól függ, hogy az osztály kulcsa fel van-e oldva. Az Apple File System (APFS) segítségével a fájlrendszer mostantól képes tovább bontani a kulcsokat méretalapon (ahol a fájl egyes részei eltérő kulcsokkal rendelkezhetnek). Architektúra Az ios és ipados rendszerben a tárhely két APFS-kötetre oszlik: Rendszerkötet: A rendszertartalom a rendszerköteten tárolódik, a felhasználói adatok pedig az adatköteten. Adatkötet: Amikor egy fájl létrejön az adatköteten, a Data Protection egy új 256 bites kulcsot (fájlalapú kulcsot) hoz létre, és átadja a hardver AES-motorjának, amely a kulcs segítségével titkosítja a fájlt, miközben a flash-tárolóba íródik. A titkosítás XTS módú AES 128 algoritmust használ, ahol a 256 bites fájlalapú kulcs fel van osztva, hogy mind a 128 bites finomhangolási kulcsot, mind a 128 bites titkosítási kulcsot tartalmazza. 45

46 Az adatfájlok létrehozásának és védelmének módja Az A7, S2 vagy S3 SoC rendszerű eszközökön az AES-CBC használatos. Az inicializálási vektor kiszámításához a blokk el van tolva a fájlba, és a fájlalapú kulcs SHA-1 hash értékével van titkosítva. A fájlalapú (vagy méretalapú) kulcs a számos osztály valamelyik kulcsával van titkosítva, a fájl elérhetőségének körülményeitől függően. Ez a művelet a NIST AES-kulcscsomagolás használatával történik, más RFC 3394 algoritmust használ csomagolásokhoz hasonlóan. A becsomagolt fájlalapú kulcs a fájl metaadataiban tárolódik. Az APFS formátumot használó eszközök támogathatják a fájlok klónozását (ún. zero copy a másolás írásnál technológiával). Ha a fájl klónozása megtörtént, a klón mindkét fele új kulcsot kap a beérkező írások fogadásához, így az új adatok új kulccsal íródnak a tárhelyre. A fájl idővel több méretből (vagy töredékből) is állhat, mindegyik más-más kulcshoz rendelve. A fájlt felépítő összes méretet azonban azonos osztályú kulcs őrzi. Amikor megnyitja a fájlt, annak metaadatai vissza lesznek fejtve a fájlrendszer kulcsával, ami felfedi a becsomagolt fájlalapú kulcsot és egy megjegyzést arra vonatkozóan, hogy melyik osztály védi. A fájlalapú (vagy méretalapú) kulcsot kicsomagolja a rendszer az osztálykulccsal, és átadja a hardveres AES-motornak, ami visszafejti a fájlt a flashtárolóból történő kiolvasás közben. A becsomagolt fájlkulcsokra vonatkozó minden kezelési művelet a Secure Enclave részben történik, a fájlkulcs soha nincs közvetlenül felfedve az Intel processzornak. Rendszerindításkor a Secure Enclave rövid élettartamú kulcsban állapodik meg az AES-motorral. Amikor a Secure Enclave kicsomagolja a fájl kulcsait, átcsomagolja őket a rövid élettartamú kulccsal, és visszaküldi az alkalmazásprocesszorhoz. Az adatkötet fájlrendszerében lévő összes fájl metaadata véletlenszerű méretű kulccsal van titkosítva, amely az ios vagy ipados első telepítésekor jön létre, vagy amikor a felhasználó törli az eszközt. A kulcsot egy kulcscsomagoló kulcs titkosítja és csomagolja be, amelyet csak a Secure Enclave ismer hosszú távú tárolóként. A kulcscsomagoló kulcs az eszköz minden törlésekor módosul. Az A9 (és újabb) SoC rendszerek esetén a Secure Enclave az entrópiára támaszkodik, amelyet visszajátszást gátló nonce támogat, hogy biztosítsa az elvethetőséget, és más eszközök mellett a kulcscsomagoló kulcsot is megvédje. A fájlalapú és a méretalapú kulcsokhoz hasonlóan az adatkötet metaadatkulcsa sincs soha felfedve az alkalmazásprocesszornak; ehelyett a Secure Enclave egy rövid élettartamú, rendszerindításonkénti verziót biztosít. Tároláskor a titkosított fájlrendszerkulcs újból be van csomagolva egy elvethető kulcsba, amely Elvethető tárhelyben tárolódik. Ez a kulcs nem biztosít további biztonságot az adatoknak. Ennek a szerepe, hogy igény szerint gyorsan törölhető legyen (a felhasználó által az Összes tartalom és beállítás törlése beállítással, vagy felhasználó vagy rendszergazda által a mobileszköz-felügyeleti (MDM) megoldás, a Microsoft Exchange ActiveSync vagy az icloud távolból kiadott törlés parancsával). A kulcs ilyen módon való törlése kriptográfiailag elérhetetlenné teszi az összes fájlt. A fájl tartalma egy vagy több fájlalapú (vagy méretalapú) kulccsal lehet titkosítva, amelyek pedig osztálykulccsal vannak csomagolva, és a fájl metaadataiban tárolva; ez utóbbi pedig a fájlrendszer kulcsával van titkosítva. Az osztálykulcsot a hardver UID-ja védi, és bizonyos osztályok esetén a felhasználó jelkódja. Ez a hierarchia mind rugalmasságot, mind teljesítményt biztosít. A fájl osztályának módosításához például elég csupán a fájlalapú kulcsát átcsomagolni, a jelkód módosítása pedig csak átcsomagolja az osztálykulcsot. 46

47 Data Protection-osztályok Amikor új fájl jön létre az ios- vagy ipados-eszközön, a létrehozó alkalmazás osztályt rendel hozzá. Minden osztály más irányelvek szerint határozza meg, hogy az adatok mikor érhetők el. Az alapvető osztályokat és irányelveket a következő részek ismertetik. Complete Protection (NSFileProtectionComplete): Az osztály kulcsát a felhasználó jelkódjából és az eszköz UID-jából képzett kulcs védi. Nem sokkal azután, hogy a felhasználó zárolja az eszközt (10 másodperccel, ha a Jelszó szükséges beállítás értéke Azonnal), a visszafejtett osztálykulcsot a rendszer elveti, így az osztályba tartozó összes adat elérhetetlenné válik, amíg a felhasználó újból meg nem adja a jelkódot, vagy fel nem oldja az eszközt a Touch ID vagy a Face ID használatával. Protected Unless Open (NSFileProtectionCompleteUnlessOpen): Bizonyos fájlok írása szükséges lehet, miközben az eszköz zárolva van. Jó példa erre a háttérben letöltődő levélmelléklet. A viselkedés eléréséhez az aszimmetrikus elliptikus görbére épülő kriptográfia (ECDH a Curve25519-es görbén). A szokásos fájlalapú kulcsot olyan kulcs védi, amely az egylépéses Diffie-Hellman kulcsmegállapodásból származik (leírása: NIST SP A). A megállapodás rövid élettartamú nyilvános kulcsa a becsomagolt fájlalapú kulccsal együtt tárolódik. A KDF az összevont kulcsszármaztatási függvény (elfogadott 1. alternatíva), leírása a NIST SP A fejezetében található. Az AlgorithmID ki van hagyva. A PartyUInfo és a PartyVInfo a rövid élettartamú és statikus nyilvános kulcsok. A kivonatoló függvény az SHA-256. A fájl bezárása után a fájlalapú kulcs törlődik a memóriából. Ha újból meg szeretné nyitni a fájlt, akkor a rendszer ismét létrehozza a közös titkot a Protected Unless Open osztály privát kulcsával és a fájl rövid élettartamú nyilvános kulcsával; ezek használatosak a fájlalapú kulcs kicsomagolásához, amelyet a rendszer később a fájl visszafejtéséhez használ. Protected Until First User Authentication (NSFileProtectionCompleteUntilFirstUserAuthentication): Ez az osztály ugyanúgy viselkedik, mint a Complete Protection, azzal a különbséggel, hogy a visszafejtett osztálykulcs nincs eltávolítva a memóriából, amikor az eszköz zárolva van. Az osztály által nyújtott védelem hasonló tulajdonságokkal rendelkezik, mint az asztali teljes kötetes titkosítás, és megvédi az adatokat az olyan támadásoktól, amelyekben újraindítás szerepel. Ez az alapértelmezett osztály az összes olyan külső féltől származó alkalmazás adatai esetén, amelyek egyébként nincsenek Data Protection osztályhoz rendelve. No Protection (NSFileProtectionNone): Az osztálykulcsot csak az UID védi, és az elvethető tárhelyben van tárolva. Mivel az ebbe az osztályba tartozó fájlok visszafejtéséhez szükséges összes kulcs az eszközön tárolódik, a titkosítás csak a gyors távoli törlés előnyével rendelkezik. Még ha egy fájl nincs Data Protection osztályhoz rendelve, akkor is titkosított formában tárolódik (mint az ios- és ipados-eszközökön lévő összes adat). 47

48 Data Protection osztálykulcs Osztály A osztály: Complete Protection B osztály: Protected Unless Open C osztály: Protected Until First User Authentication D osztály: No Protection Védelem típusa (NSFileProtection Complete) (NSFileProtection Complete UnlessOpen) (NSFileProtection Complete UntilFirstUserAuthentication) (NSFileProtection None) Védett kulcsok elérése helyreállítási módokban Az Apple A10, A11 és S3 SoC rendszerű eszközökön a felhasználó jelkódja által védett osztálykulcsok nem érhetők el helyreállítási módban. Az A12 és S4 SoC kiterjeszti ezt a védelmet az eszköz firmware-frissítési (DFU) módjára. A Secure Enclave AES-motorja zárolható szoftverkezdő bitekkel rendelkezik. Amikor a kulcsok létrejönnek az UID-ból, ezek a kezdő bitek szerepelnek a kulcsszármaztatási függvényben, hogy további kulcshierarchiákat hozzanak létre. Az Apple A10 és S3 SoC rendszerrel kezdve a kezdő bit kifejezetten azért van, hogy elkülönítse a felhasználó jelkódja által védett kulcsokat. A kezdő bit be van állítva olyan kulcsoknál, ahol szükséges a felhasználó jelkódja (beleértve a Data Protection A, B és C osztály kulcsait), és törölve van olyan kulcsoknál, amelyekhez nem szükséges a felhasználó jelkódja (beleértve a fájlrendszer metaadatainak kulcsát és a D osztály kulcsait). Az A12 SoC rendszeren a Secure Enclave rendszerindító ROM-ja zárolja a jelkód kezdő bitjét, ha az alkalmazásprocesszor DFU vagy helyreállítási módba lép. Ha a jelkód kezdő bitje zárolva van, nem engedélyezettek a módosítására irányuló műveletek, így a felhasználó jelkódjával védett adatokhoz nem lehet hozzáférni. Az Apple A10, A11, S3 és S4 SoC rendszeren a jelkód kezdő bitjét a Secure Enclave operációs rendszer zárolja, ha az eszköz helyreállítási módba lép. A Secure Enclave rendszerindító ROM-ja és operációs rendszere is ellenőrzi a rendszerindítási folyamat regiszterét (BPR-t), hogy biztonsággal meg tudja határozni az aktuális módot. Ezenkívül az ios 13 és az ipados 13.1 vagy újabb verzióban A10 vagy újabb eszköz esetén minden felhasználói adat kriptográfiailag elérhetetlenné válik, amikor az eszköz helyreállítási módban indul. Ennek eléréséhez egy további kezdő bit jelenik meg, amelynek beállítása vezérli a médiakulcs elérhetőségét, ami pedig szükséges a fájlok metaadatainak (így a fájlok tartalmának) az eléréséhez a Data Protection által titkosított köteten. Ez a védelem az összes osztály (A, B, C és D) védett fájljait átfogja, nem csupán azokat, amelyekhez a felhasználó jelkódja szükséges. Ha az eszköz vissza lesz állítva, miután DFU módba lépett, akkor visszaáll egy ismert helyes állapot, ahol bizonyosan csak a módosítatlan, Apple által aláírt kód van jelen. A DFU mód manuálisan érhető el. A következő Apple támogatási cikkek ismertetik, hogyan helyezhető az eszköz DFU módba: 48

49 Eszköz iphone, ipad, ipod touch Apple TV Cikk Ha elfelejtette az iphone, az ipad vagy az ipod touch jelkódját, vagy ha a készülék le van tiltva Az Apple TV visszaállítása A Kulcskarika adatvédelme és adatosztályai A Kulcskarika adatvédelmének áttekintése Sok alkalmazásnak kell jelszavakat és más, rövid, de érzékeny adatbiteket kezelnie, mint például kulcsok és bejelentkezési hitelesítő adatok. Az ios és ipados Kulcskarikája biztonságos módon képes tárolni ezeket az elemeket. A Kulcskarikán lévő elemek két különféle AES-256-GCM kulccsal vannak titkosítva, egy táblakulccsal (metaadat) és egy soralapú kulccsal (titkos kulcs). A Kulcskarika metaadatai (az összes attribútum, kivéve a ksecvalue) a metaadatkulccsal vannak titkosítva, hogy gyorsabb legyen a keresés, míg a titkos érték (ksecvaluedata) a titkos kulccsal van titkosítva. A metaadatkulcsot a Secure Enclave védi, de az alkalmazásprocesszorban van gyorsítótárazva, hogy gyorsan lehessen lekérdezéseket futtatni a kulcskarikán. A titkos kulcsnak mindig szüksége van a Secure Enclave processzoron keresztüli útra. A Kulcskarika a fájlrendszeren tárolt SQLite adatbázisként van implementálva. Csak egyetlen adatbázis van, és a securityd démon határozza meg, hogy melyik Kulcskarikaelemet érhetik el az egyes folyamatok vagy alkalmazások. A Kulcskarika-elérés API-jai a démont hívják meg, ami pedig lekérdezi az alkalmazás Keychain-access-groups, application-identifier és application-group jogosultságait. A hozzáférési csoportok nem csupán egyetlen folyamatra korlátozzák a hozzáférést, hanem engedélyezik a Kulcskarikaelemek megosztását az alkalmazások között. A Kulcskarika-elemek csak azonos fejlesztőtől származó alkalmazások között oszthatók meg. Ennek kezeléséhez a rendszer megköveteli a külső alkalmazásoktól, hogy hozzáférési csoportokat használjanak, amelyekhez az Apple Developer Program alkalmazáscsoportokon keresztül előtagot rendel. Az előtag követelménye és az alkalmazáscsoport egyedisége a kódaláíráson, az előkészítési profilokon és az Apple Developer Programon keresztül van kikényszerítve. A Kulcskarika-adatok a fájlok adatvédelméhez használt osztálystruktúrához hasonlóan van védve. Ezek az osztályok hasonlóan viselkednek, mint a fájlok adatvédelmi osztályai, de saját kulcsokat használnak, és másként elnevezett API-k részei. Elérhetőség Fájlok adatvédelme Kulcskarika-adatvédelem Amikor fel van oldva NSFileProtection Complete ksecattraccessible WhenUnlocked Amikor zárolva van Első feloldás után NSFileProtection Complete Unless Open NSFileProtection Complete Until FirstUserAuthentication N/A ksecattraccessible AfterFirstUnlock Mindig NSFileProtection None ksecattraccessible Always 49

50 Elérhetőség Fájlok adatvédelme Kulcskarika-adatvédelem Amikor a jelkód engedélyezett N/A ksecattraccessible WhenPasscode SetThisDevice Only A háttérfrissítési szolgáltatást használó alkalmazások használhatják a ksecattraccessibleafterfirstunlock osztályt azokhoz a Kulcskarika-elemekhez, amelyeket a háttérbeli frissítések során kell elérni. A ksecattraccessiblewhenpasscodesetthisdeviceonly ugyanúgy viselkedik, mint a ksecattraccessiblewhenunlocked, de csak olyankor érhető el, ha az eszköz jelkóddal van konfigurálva. Ez az osztály csak a Kulcstartó rendszerben létezik, és a következő érvényes rá: Nem szinkronizálódik az icloud-kulcskarikára Nem készül róla biztonsági mentés Nem szerepel a zálogkulcstartókon Ha a jelkód el van távolítva vagy vissza van állítva, az elemek használhatatlanná válnak az osztálykulcsok elvetése miatt. Más Kulcskarika-osztályokhoz tartozik egy Csak ez az eszköz pár, amelyet mindig az UID véd, amikor biztonsági mentés során átmásolódik az eszközről, használhatatlanná téve, ha másik eszközön állítják vissza. Az Apple gondos egyensúlyt teremtett a biztonság és a használhatóság között azáltal, hogy olyan Kulcskarika-osztályokat választott, amelyek a védetté tett információtól és attól függnek, hogy az ios és ipados rendszernek mikor van rájuk szüksége. A VPN-tanúsítványnak például állandóan elérhetőnek kell lennie, hogy az eszköz fenntartsa a folyamatos kapcsolatot, az elem viszont a nem költöztethető tulajdonsággal rendelkezik, így nem vihető át másik eszközre. Kulcskarika-adatosztályok védelmei Az ios és ipados által létrehozott Kulcskarika-elemek esetén a következő osztályvédelmek vannak kikényszerítve: Elem Wi-Fi-jelszavak Mail-fiókok Microsoft Exchange Active Sync-fiókok VPN-jelszavak LDAP, CalDAV, CardDAV Közösségi hálózatok fiókjainak hitelesítő adatai Handoff-hirdetés titkosítási kulcsai icloud hitelesítő adatai Otthoni megosztás jelszava Safari-jelszavak Elérhetőség Első feloldás után Első feloldás után Első feloldás után Első feloldás után Első feloldás után Első feloldás után Első feloldás után Első feloldás után Amikor fel van oldva Amikor fel van oldva 50

51 Elem Safari-könyvjelzők itunes biztonsági mentés VPN-tanúsítványok Bluetooth kulcsok Apple Push Notification szolgáltatás (APNs) hitelesítő adatai icloud-tanúsítványok és privát kulcs imessage-kulcsok Konfigurációs profil által telepített tanúsítványok és privát kulcsok SIM PIN Lokátor hitelesítő adatai Hangposta Elérhetőség Amikor fel van oldva Amikor fel van oldva, nem költöztethető Mindig, nem költöztethető Mindig, nem költöztethető Mindig, nem költöztethető Mindig, nem költöztethető Mindig, nem költöztethető Mindig, nem költöztethető Mindig, nem költöztethető Mindig Mindig A Kulcskarika-elérés szabályozása A kulcskarikák hozzáférés-vezérlési listákkal (ACL-ekkel) állítják be az elérhetőség és hitelesítés követelményeire vonatkozó irányelveket. Az elemek beállíthatnak olyan feltételeket, amelyekhez a felhasználó jelenléte szükséges, annak előírásával, hogy csak a Touch ID vagy a Face ID által végzett hitelesítéssel vagy az eszköz jelkódjának megadásával érhetők el. Az elemek elérése azzal is korlátozható, ha be van állítva, hogy a Touch ID vagy a Face ID regisztrációja nem változott az elem hozzáadása óta. Ez a korlátozás meggátolja, hogy a támadó hozzáadja a saját ujjlenyomatát, és elérje a Kulcskarika-elemet. Az ACL-ek kiértékelése a Secure Enclave processzoron belül történik, és csak akkor kapja meg őket a kernel, ha a megadott korlátozásoknak megfelelnek. Titkosítás a macos rendszerben A belső kötet titkosítása, ha a FileVault be van kapcsolva A Mac OS X 10.3 és újabb rendszerek esetén a Mac gépeken elérhető a FileVault; ez egy beépített titkosítási képesség, ami védetté teszi az adatokat. A FileVault az AES- XTS adattitkosítási algoritmussal véd teljes köteteket a belső és az eltávolítható tárolóeszközökön. Az Apple T2 Security chippel szerelt Mac gépeken a T2 chippel közvetlenül összekapcsolt, titkosított belső tárolóeszközök kihasználják a chip hardverbiztonsági képességeit. Ha a felhasználó bekapcsolta a FileVault funkciót a Mac gépen, akkor meg kell adnia a hitelesítő adatait a rendszerindítási folyamat során. 51

52 Érvényes bejelentkezési hitelesítő adatok vagy kriptográfiai visszaállítási kulcs nélkül a belső APFS kötet titkosítva marad (macos esetén ebbe beletartozik a rendszerés az adatkötet), és védve van a jogosulatlan hozzáféréstől, még akkor is, ha a fizikai tárolóeszközt eltávolítják, és másik számítógéphez csatlakoztatják. A T2 chippel szerelt Mac gépeken a belső kötet titkosítását kulcsok hierarchiájának megalkotása és kezelése implementálja, és a chipbe épített hardveres titkosítási technológiákra épül. A kulcshierarchia úgy lett kialakítva, hogy párhuzamosan négy célt is elérjen: A felhasználó jelszavának megkövetelése a visszafejtéshez A rendszer védelme, ha a Mac gépből eltávolított tárolóeszközt közvetlen, nyers erőt alkalmazó támadás éri Gyors és biztonságos módszer biztosítása a tartalom törléséhez a szükséges kriptográfiai anyagok törlésén keresztül. A jelszó (és így a fájlok védelméhez használ titkosítási kulcs) módosításának engedélyezése a felhasználó számára anélkül, hogy a teljes kötetet újra kellene titkosítani A belső kötet titkosítása, ha a FileVault be van kapcsolva a macos rendszeren. A T2 chippel szerelt Mac gépeken a FileVault-kulcsot érintő minden kezelési művelet a Secure Enclave processzorban történik; a titkosítási kulcsok soha nincsenek közvetlenül felfedve az Intel processzornak. Alapértelmezés szerint minden APFS-kötet kötetkulccsal jön létre. A kötetek és a metaadatok tartalma ezzel a kötetkulccsal van titkosítva, ami pedig az osztálykulcsba van csomagolva. Az osztálykulcsot a felhasználó jelszavának és a hardver UID-jának kombinációja védi, ha a FileVault be van kapcsolva. Ez a védelem az alapértelmezett a T2 chippel szerelt Mac gépeken. Megjegyzés: Az eltávolítható tárolóeszközök titkosítása nem használja fel az Apple T2 Security chip biztonsági képességeit, és a titkosításuk úgy zajlik, ahogy a T2 chip nélküli Mac gépeken. 52

53 A belső kötet titkosítása, ha a FileVault ki van kapcsolva A kötet akkor is titkosítva lesz, ha a FileVault nincs bekapcsolva az Apple T2 Security chippel szerelt Mac gépen a Beállítási asszisztens kezdeti folyamata során, ilyenkor azonban a kötetkulcsot csak a hardver UID-ja védi a Secure Enclave processzorban. A belső kötet titkosítása, ha a FileVault ki van kapcsolva a macos rendszeren. Ha a felhasználó később kapcsolja be a FileVaultot ez a folyamat azonnali, hiszen az adatok már korábban titkosítva lettek, akkor egy lejátszást gátló mechanizmus megakadályozza, hogy a (csak a hardver UID-ján alapuló) korábbi kulcs használható legyen a kötet visszafejtésére. A kötetet ekkor a felhasználó jelszavának és a hardver UID-jának kombinációja védi, a korábban leírtaknak megfelelően. FileVault-kötetek törlése A kötet törlésekor a kötetkulcsot biztonságosan törli a Secure Enclave. Ez meggátolja, hogy ezzel a kulccsal később akár csak a Secure Enclave segítségével is hozzá lehessen férni. Ezenkívül minden kötetkulcsot médiakulcsba csomagol a rendszer. A médiakulcs nem nyújt további adatbiztonságot; ennek az a célja, hogy gyorsan és biztonságosan törölni lehessen az adatokat, hiszen enélkül a visszafejtés lehetetlen. A médiakulcs az elvethető tárhelyen van, és az a funkciója, hogy igény szerint gyorsan törölni lehessen például a távoli törléssel a Lokátor segítségével, vagy ha az eszköz regisztrálva van mobileszköz-felügyeleti (MDM) szolgáltatásban. Az elvethető tárhely hozzáfér a mögöttes tárolótechnológiához (például NAND), hogy nagyon alacsony szinten közvetlenül megcímezhessen és törölhessen néhány blokkot. A médiakulcs ilyen módon való törlése kriptográfiailag elérhetetlenné teszi a kötetet. A nyers erővel végzett támadások és a rosszindulatú szoftverek kivédése A nyers erővel végzett támadások kivédéséért a Mac gép a rendszerindításkor legfeljebb 30 jelszókísérletet engedélyez a bejelentkezési ablakban vagy Céllemez mód használatakor, és a helytelen próbálkozásokkal együtt nő a várakozási idő. A késleltetést a T2 chip Secure Enclave társprocesszora kényszeríti ki. Ha a Mac gép a késleltetés közben újraindul, a késleltetés továbbra is érvényben marad, és az időzítő újraindítja az aktuális periódust. 53

54 Ezek a korlátok megszűnnek, ha a felhasználó sikeresen bejelentkezett a Mac gépre (hogy a rosszindulatú szoftverek ne tudjanak a felhasználó jelszavának támadásával végleges adatvesztést okozni), de újraindítás után ismét érvényben lesznek. Ha a 30 próbálkozás kimerül, 10 újabb próbálkozás áll rendelkezésre a macos helyreállítási módban. Ha ezek is kimerülnek, akkor 60 további próbálkozás lehetséges minden egyes FileVault helyreállítási mechanizmushoz (icloud-visszaállítás, FileVault-visszaállítási kulcs és szervezeti kulcs), így a próbálkozások maximuma 180. Ha ezek a további lehetőségek elfogynak, a Secure Enclave nem dolgozza fel a kötet visszafejtésére vagy a jelszó ellenőrzésére irányuló kérelmeket, és a meghajtón lévő adatok elvesznek. Ha vállalati körülmények között szeretné megvédeni az adatait, az IT-osztálynak definiálni és kényszeríteni kell a FileVault konfigurációs irányelveit a mobileszköz-felügyelet (MDM) használatával. A szervezetek számos módon felügyelhetik a titkosított köteteket, beleértve az intézményi visszaállítási kulcsokat, személyes visszaállítási kulcsokat (ezek zálogként opcionálisan az MDM-mel tárolhatók) vagy a kettő kombinációját. A kulcsok cseréje is beállítható irányelvként az MDM-ben. Késleltetés jelszókísérletek között Próbálkozás Kényszerített késleltetés 1 14 Nincs perc perc perc óra A FileVault kezelése A SecureToken használata A macos és újabb verziókban az Apple File System (APFS) módosítja a FileVault titkosítási kulcsok generálásának módját. A macos korábbi verzióiban a CoreStorageköteteken a FileVault titkosítási folyamatban használt kulcsok akkor jöttek létre, amikor a felhasználó vagy szervezet bekapcsolta a FileVault funkciót a Mac gépen. Az APFSkötetű macos rendszer esetén a kulcsok vagy a felhasználó létrehozásakor, vagy a felhasználónak a Mac gépre való első bejelentkezésekor generálódnak. A titkosítási kulcsok implementálása, generálásuk időpontja és tárolásuk módja a SecureToken része. A SecureToken a kulcstitkosítási kulcs (KEK) becsomagolt verziója, amelyet a felhasználó jelszava véd. Amikor a FileVault APFS-köteten áll rendszerbe, a felhasználó továbbra is elvégezheti a következőket: Meglévő eszközök és folyamatok használata, például a személyes visszaállítási kulcs (PRK) mobileszköz-felügyeleti (MDM) megoldásban való zálogba helyezése Szervezeti visszaállítási kulcs (IRK) létrehozása és használata A FileVault engedélyezésének késleltetése, amíg a felhasználó be- vagy kijelentkezik a Mac gépen 54

55 A Bootstrap Token használata A macos új funkciót vezet be a Bootstrap Tokent, amely SecureTokent biztosít mind a mobilfiókokhoz, mind az opcionális, eszközregisztráció által létrehozott rendszergazdai fiókhoz ( felügyelt rendszergazda ). A felügyelt rendszergazda létrehozható MDM-megoldás konfigurálásával, amely létrehozza a fiókot az Apple School Manager vagy az Apple Business Manager használatakor végrehajtott regisztrációs folyamat során. A következő szükséges a macos Bootstrap Token funkciójának használatához: A Mac gép regisztrálása MDM-ben az Apple School Manager vagy az Apple Business Manager használatával MDM-forgalmazói támogatás Megjegyzés: A macos nem képes automatikusan létrehozni Bootstrap Tokent a telepítés alatt, ha a helyi felhasználói fiók létrehozása teljesen ki van hagyva. macos vagy újabb rendszeren létrejön egy Bootstrap Token, amely zálogba van adva az MDM-nek, amikor az első olyan felhasználó bejelentkezik, akinél a SecureToken engedélyezve van, ha az MDM-megoldás támogatja ezt a funkciót. A Bootstrap Token a profiles parancssori eszköz használatával is létrehozható és zálogba adható az MDM-nek, ha szükséges. Ha a felhasználó maga telepíti a Mac gépet Amikor a felhasználó saját maga telepíti a Mac gépet, az IT-osztály nem készíti elő az eszközt. Minden irányelv és konfiguráció a mobileszköz-felügyeleti (MDM) megoldás vagy konfigurációkezelési eszközök használatával van biztosítva. A kezdeti helyi rendszergazdai fiók létrehozása a Beállítási asszisztens használatával történik, és a felhasználó megkapja a SecureTokent. Ha az MDM-megoldás támogatja a Bootstrap Token funkciót, és erről tájékoztatja a Mac gépet az MDM-regisztráció során, akkor a Mac gép generálja a Bootstrap Tokent, és zálogba adja az MDM-megoldásnak. Ha egy Mac gép regisztrálva van egy MDM-megoldásban, akkor az elérhető MDMfunkcióktól függően a kezdeti fiók használható rendszergazdafiókként vagy helyi fiókként. Ha a felhasználó leminősül normál felhasználóvá az MDM-megoldás használatával, a felhasználó automatikusan megkapja a SecureTokent. Ha a felhasználó leminősül, akkor a macos rendszertől kezdve nem generálódik Bootstrap Token. Megjegyzés: Ha a Beállítási asszisztensben a helyi felhasználói fiók létrehozása teljes mértékben kimarad az MDM használatával, és helyette mobil fiókokkal rendelkező címtárszolgáltatást használnak, a címtárfelhasználó nem kapja meg a SecureTokent a bejelentkezés során, és nem generálódik Bootstrap Token. Ha a Mac gépen nincs SecureToken-felhasználó, a mobil fiókhoz továbbra is engedélyezhető a FileVault a késleltetett engedélyezéssel, és a felhasználó megkapja a SecureTokent, amikor a FileVault bekapcsolt állapotba kerül. Miután a felhasználó számára engedélyezve lesz a SecureToken, macos és újabb rendszeren automatikusan létrejön egy Bootstrap Token, amely zálogba lesz adva az MDM-megoldásnak a bejelentkezéskor, ha az támogatja ezt a funkciót. 55

56 A fenti forgatókönyvek mindegyikére igaz, hogy mivel az első és elsődleges felhasználó megkapja a SecureTokent, ezért engedélyezhetők a FileVault használatára késleltetett engedélyezéssel. A késleltetett engedélyezés bekapcsolja a FileVault funkciót, de az aktiválását késleltesse addig, amíg egy felhasználó be- vagy kijelentkezik a Mac gépen. Azt is testre lehet szabni, hogy a felhasználó kihagyhatja-e a FileVault bekapcsolását (opcionálisan adott számú alkalommal). A végeredmény az, hogy a Mac gép elsődleges felhasználója akár helyi felhasználó, akár valamilyen mobil fiók képes feloldani a tárolóeszközt, ha az FileVault segítségével van titkosítva. Azokon a Mac gépeken, ahol Bootstrap Token volt generálva és az MDM-megoldásnak zálogba adva, ha a jövőben a felügyelt rendszergazda bejelentkezik a Mac gépre, a Bootstrap Token segítségével automatikusan megkapja a SecureTokent, azaz a fiókhoz engedélyezve lesz a FileVault, és feloldhatja a FileVault-kötetet. A felhasználó a következő paranccsal módosíthatja, hogy a felügyelt adminisztrátori fiók feloldhatja-e a kötetet: fdesetup remove -user. Ha a Mac gépet egy szervezet készíti elő Ha a Mac gépet a szervezet előkészíti, mielőtt a felhasználónak adná, az IT-osztály végzi a telepítést. A macos Beállítási asszisztensében létrehozott, a Mac gép előkészítéséhez vagy beállításához használt helyi rendszergazdai fiók megkapja a SecureTokent. macos esetén, ha az MDM-megoldás támogatja a Bootstrap Token funkciót, akkor a Bootstrap Token is a macos telepítési folyamata során jön létre és kerül zálogba az MDMmegoldásban. Ha a felügyelt rendszergazdai fiók egy későbbi időpontban bejelentkezik a Mac gépen, akkor a Bootstrap Token segítségével automatikusan megkapja a SecureTokent. Ha a Mac gép címtárszolgáltatáshoz kapcsolódik, mobil fiókok létrehozására van konfigurálva, és nincs Bootstrap Token, akkor a címtárszolgáltatás felhasználóinak az első bejelentkezéskor meg kell adniuk egy meglévő SecureToken-rendszergazdai felhasználónevet és jelszót, hogy az ő fiókjuk is megkapja a SecureTokent. A Mac gép telepítéséhez használt helyi rendszergazdai hitelesítő adatokat meg kell adni. Ha a SecureToken nem szükséges, a felhasználó a Megkerülés gombra kattint. macos vagy újabb verzió esetén a SecureToken párbeszédablak teljesen le is tiltható, ha a FileVault nem lesz használatban a mobil fiókokkal. Ha le szeretné tiltani a SecureToken párbeszédablakot, alkalmazzon egyéni beállításokat tartalmazó konfigurációs profilt az MDM-megoldásból a következő kulcsokkal és értékekkel: Beállítás Domén Kulcs Érték Érték com.apple.mcx cachedaccounts.askforsecure TokenAuthBypass Igaz Ha az MDM-megoldás támogatja a Bootstrap Token funkciót, és a Mac gép létrehozott egyet, amely az MDM-megoldásnak zálogba lett adva, akkor a mobil fiókos felhasználók számára nem jelenik meg ez az adatkérés. Ezek a felhasználók automatikusan megkapják a SecureTokent a bejelentkezéskor. 56

57 Ha további helyi felhasználókra van szükség a Mac gépen a címtárszolgáltatás felhasználói fiókja helyett, akkor azok a helyi felhasználók automatikusan megkapják a SecureTokent, amikor SecureTokennel rendelkező rendszergazda hozza létre őket a Rendszerbeállítások > Felhasználók és csoportok menüpontban. Ha a parancssorral kell létrehozni a helyi felhasználókat, a sysadminctl parancssori eszköz használható a felhasználók létrehozásához és a SecureToken számukra történő engedélyezéséhez. Ilyen forgatókönyvek esetén a következő felhasználók feloldhatják a FileVault-titkosítással rendelkező kötetet: Az előkészítéshez használt eredeti helyi rendszergazda Minden olyan további címtárszolgáltatásbeli felhasználó, aki megkapja a SecureTokent a bejelentkezés során, akár interaktívan a párbeszédpanel segítségével, akár automatikusan a Bootstrap Tokennel A Rendszerbeállításokban létrehozott minden új helyi felhasználó A felhasználó az fdesetup remove -user paranccsal módosíthatja, hogy bizonyos fiókok feloldhatják-e a tárolóeszközt. A fent leírt munkafolyamatok használatakor a SecureTokent a macos kezeli, és nem szükséges további konfiguráció, sem szkript; az implementáció részévé válik, és nem kell aktívan kezelni, sem manipulálni. Parancssori eszközök használata A Bootstrap Token, a FileVault és a SecureToken kezeléséhez parancssori eszközök állnak rendelkezésre. A Bootstrap Token általában a Mac gépen generálódik, és zálogba kerül a mobileszköz-felügyeleti (MDM) megoldásba a macos telepítése során, miután az MDMmegoldás közli a Mac géppel, hogy támogatja a funkciót. A Bootstrap Token azonban a már telepített Mac gépen is generálható. Ilyen például, ha az MDM-megoldás támogatást ad a funkcióhoz a macos kezdeti telepítése után. macos vagy újabb rendszeren létrejön egy Bootstrap Token, amely zálogba van adva az MDM-nek, amikor az első olyan felhasználó bejelentkezik, akinél a SecureToken engedélyezve van, ha az MDM-megoldás támogatja ezt a funkciót. Így nem kell annyiszor használni a profiles parancssori eszközt az eszköz beállítása után Bootstrap Token létrehozásához és az MDM-megoldásnak való zálogba adásához. A profiles parancssori eszköznek több lehetősége is van a Bootstrap Tokennel való kommunikációra. sudo profiles install -type bootstraptoken: Ez a parancs új Bootstrap Tokent generál, és zálogba adja az MDM-megoldásnak. A parancshoz kötelező a meglévő SecureToken rendszergazdai információ a Bootstrap Token kezdeti generálásához, az MDM-megoldásnak támogatnia kell a funkciót, és a Mac gép sorozatszámának meg kell jelennie az Apple School Managerben vagy Apple Business Managerben, és regisztrálni kell az MDM-megoldásban. sudo profiles remove -type bootstraptoken: Eltávolítja a Mac gépen és az MDM-megoldásban meglévő Bootstrap Tokent. sudo profiles status -type bootstraptoken: Visszaadja, hogy az MDMmegoldás támogatja-e a Bootstrap Token funkciót, és hogy mi a Bootstrap Token aktuális állapota a Mac gépen. 57

58 Az fdesetup parancssori eszköz Az MDM-konfigurációkkal vagy az fdesetup parancssori eszközzel konfigurálható a FileVault. macos és újabb verziók esetén elavulttá válik az fdesetup azon funkciója, hogy a felhasználónév és jelszó megadásával bekapcsolható a FileVault, és nem lesz felismerve a jövőbeli kiadásokban. Ehelyett célszerű az MDM segítségével a késleltetett engedélyezés használata. Ha további információt szeretne az fdesetup parancssori eszközzel kapcsolatban, indítsa el a Terminal alkalmazást, és adja ki a man fdesetup vagy az fdesetup help parancsot. Az sysadminctl parancssori eszköz A sysadminctl parancssori eszköz kifejezetten a Mac gépen lévő felhasználói fiókok SecureToken-állapotának módosítására használható. A műveletet csak körültekintéssel és csak szükség esetén szabad elvégezni. Ha a sysadminctl paranccsal módosítja a felhasználó SecureToken-állapotát, mindig meg kell adni egy létező, SecureTokent használó rendszergazda felhasználónevét és jelszavát, akár interaktív módon, akár a parancs megfelelő kapcsolóinak használatával. Mind a sysadminctl, mind a Rendszerbeállítások meggátolják, hogy a Mac gép utolsó rendszergazdáját vagy SecureTokent használó felhasználóját törölje. Ha a további helyi felhasználók létrehozása szkriptelve van a sysadminctl használatával, akkor azok a felhasználók csak akkor kapják meg a SecureTokent, ha megadja egy aktuálisan SecureTokent használó rendszergazda hitelesítő adatait akár interaktívan, akár közvetlenül a sysadminctl -adminuser és -adminpassword kapcsolóival. A használatra vonatkozó további útmutatásért használja a sysadminctl -h parancsot. Jelkódok és jelszavak Jelkódok Ha a felhasználó jelkódot állít be az eszközön, akkor automatikusan engedélyezi a Data Protection funkciót. Az ios és az ipados hat számjegyű, négy számjegyű és tetszőleges hosszúságú alfanumerikus jelkódokat támogat. A jelkód azonkívül, hogy feloldja az eszközt, entrópiát biztosít bizonyos titkosítási kulcsok számára. Ez azt jelenti, hogy még ha a támadó birtokában is van az eszköznek, a jelkód nélkül nem fér hozzá a megadott védelmi osztályokba tartozó adatokhoz. A jelkód össze van csomózva az eszköz UID-jával, így a nyers erőt alkalmazó támadásokat magán az eszközön kell végrehajtani. A próbálkozásokat az iterációk nagy száma lassítja. Az iterációk száma úgy van beállítva, hogy egy próbálkozás nagyjából 80 ezredmásodpercig tartson. Ez azt jelenti, hogy több mint öt és fél év kellene ahhoz, hogy a hat karakteres alfanumerikus jelkód összes kombinációját kisbetűkkel és számokkal együtt kipróbálják. Minél erősebb a felhasználó jelkódja, annál erősebb a titkosítási kulcs. A Touch ID és a Face ID segítségével még tovább növelhető a biztonság azáltal, hogy így a felhasználó az egyébként praktikusnál sokkal erősebb jelkódot hozhat létre. Ezzel az eljárással növelhető a Data Protection funkcióhoz használt titkosítási kulcsokat védő entrópia tényleges mennyisége anélkül, hogy romlana a felhasználói élmény, amikor naponta többször feloldja az ios- vagy ipados-eszközt. 58

59 A nyers erőt használó támadások további elhárítására a Zárolási képernyőn megadott helytelen jelkódok növelik a késleltetést. Ha a Beállítások > Touch ID és jelkód > Adatok törlése be van kapcsolva, az eszköz automatikusan törlődik, ha 10 egymást követő alkalommal helytelen adják meg a jelkódot. Az egymás után megadott, azonos helytelen jelkódok nem számítanak bele a korlátba. Ez a beállítás adminisztratív irányelvként is elérhető olyan mobileszköz-felügyeleti (MDM) megoldáson keresztül, amely támogatja ezt a funkciót és a Microsoft Exchange ActiveSync protokollt, és beállítható alacsonyabb küszöbre. A Secure Enclave processzorral rendelkező eszközökön a késleltetést a Secure Enclave segédprocesszor kényszeríti ki. Ha az eszköz a késleltetés közben újraindul, a késleltetés továbbra is érvényben marad, és az időzítő újraindítja az aktuális periódust. Hosszabb jelkódok megadása Ha csak számokat tartalmazó, hosszabb jelkódot ad meg, numerikus billentyűzet jelenik meg a Zárolási képernyőn a teljes billentyűzet helyett. A számokból álló hosszabb jelkód megadása egyszerűbb lehet, mint egy rövidebb alfanumerikus jelkódé, miközben hasonló biztonságot nyújt. A felhasználók a Beállítások > Jelkód menü Jelkódbeállítások részén található Egyéni alfanumerikus kód lehetőséget választva adhatnak meg hosszabb alfanumerikus jelkódot. Késleltetés jelkódkísérletek között Próbálkozás Kényszerített késleltetés 1 4 Nincs 5 1 perc 6 5 perc perc 9 1 óra Adatkapcsolatok biztonságos aktiválása A megtartott használhatóság melletti biztonságnövelés érdekében kötelező a Touch ID, Face ID vagy jelkód megadása, amikor Lightning, USB vagy Smart Connector interfészen keresztül szeretne adatkapcsolatot aktiválni, ha a közelmúltban nem jött létre adatkapcsolat. Ez korlátozza a támadási felületet a fizikailag csatlakoztatott eszközök ellen, mint amilyenek a rosszindulatú töltők, miközben megfelelő időkorlátok között tartja a más kiegészítők használatát. Ha több mint egy óra telt el az ios- vagy ipados-eszköz zárolása vagy egy kiegészítő adatkapcsolatának lezárása óta, az eszköz csak akkor engedélyezi új adatkapcsolat kialakítását, ha feloldják. Ezen egy óra alatt csak olyan kiegészítőkkel van engedélyezve az adatkapcsolat, amelyek az eszköz feloldott állapotában lettek csatlakoztatva. A rendszer 30 napig megjegyzi ezeket a kiegészítőket a csatlakozásuk után. Ha ebben az időszakban ismeretlen kiegészítő próbál meg adatkapcsolatot nyitni, azzal letiltja a Lightning, USB és Smart Connector interfészeken keresztüli összes adatkapcsolatot, amíg az eszköz ismét fel nincs oldva. Ez az egy órás időszak: 59

60 Arra szolgál, hogy a Machez, PC-hez, kiegészítőkhöz vagy vezetékes CarPlayhez gyakran csatlakozó felhasználóknak ne kelljen az eszköz minden csatlakoztatásakor megadniuk a jelkódot. Kötelező, mivel a kiegészítők ökoszisztémája nem biztosít kriptográfiailag megbízható módot a kiegészítők ellenőrzésére az adatkapcsolat felépítése előtt. Ezenkívül, ha több mint három napja nem épült fel adatkapcsolat egy kiegészítővel, akkor az eszköz nem fog engedélyezni új adatkapcsolatokat közvetlenül a zárolása után. Ez növeli a védelmet olyan felhasználók számára, akik nem gyakran használnak ilyen kiegészítőket. A Lightning, USB és Smart Connector interfészen keresztüli kapcsolatok akkor is le vannak tiltva, ha az eszköz olyan állapotban van, amikor jelkódot kell megadni a biometrikus hitelesítés ismételt engedélyezéséhez. A felhasználó dönthet úgy, hogy újból engedélyezi a mindig élő adatkapcsolatokat a Beállításokban (bizonyos segítő eszközök beállítása automatikusan elvégzi ezt a műveletet). A jelszavak funkciója Az Apple T2 Security chippel szerelt Mac gépeken a jelszó hasonló funkciót tölt be, mint a fenti jelkódok, azzal a különbséggel, hogy a generált kulcs a FileVault-titkosításhoz használatos, nem pedig az adatvédelemhez. A macos ezenkívül további jelszóvisszaállítási lehetőségeket is kínál: icloud-visszaállítás FileVault-visszaállítás FileVault szervezeti kulcs Hitelesítés és digitális aláírás Digitális aláírás és titkosítás Hozzáférés-szabályozási lista A Kulcskarika-adatokat hozzáférés-szabályozási listák (ACL-ek) particionálják és védik. Ennek eredményeképpen a külső alkalmazások által tárolt hitelesítő adatokat nem érhetik el eltérő személyazonosságú alkalmazások, hacsak a felhasználó erre külön engedélyt nem ad. Ez a védelem biztosítja azt a mechanizmust, amely védi az Apple-eszközön lévő bejelentkezési adatokat a szervezet számos alkalmazását és szolgáltatását átfogóan. 60

61 Mail A Mail alkalmazásban a felhasználó digitálisan aláírt és titkosított üzeneteket küldhetnek. A Mail automatikusan felismeri a megfelelő RFC 5322 formátumú, kis- és nagybetűket megkülönböztető -cím alanyát vagy az alany alternatív nevét a digitális aláírási és titkosítási tanúsítványokon a kompatibilis intelligens kártyák csatolt PIV-tokenén. Ha egy konfigurált -fiók megfelel a csatolt PIV-tokenben lévő valamelyik digitális aláírási vagy titkosítási tanúsítványnak, akkor a Mail automatikusan megjeleníti az aláírás gombot az új üzenet ablakának eszközsorán. Ha a Mail rendelkezik a címzett titkosítási tanúsítványával, vagy fel tudja azt fedezni a Microsoft Exchange globális címlistáján (GAL), akkor nyitott lakat ikon jelenik meg az új üzenet eszközsorán. A zárt lakat ikon azt jelzi, hogy az üzenet a címzett nyilvános kulcsával titkosítva lesz elküldve. Üzenetalapú S/MIME Az ios, ipados és a macos támogatja az üzenetalapú S/MIME használatát. Ez azt jelenti, hogy az S/MIME-felhasználók kiválaszthatják, hogy alapértelmezés szerint minden üzenetet aláírnak és titkosítanak, vagy egyesével írják alá és titkosítják az üzeneteket. Az S/MIME protokollal használt identitások átvihetők Apple-eszközökre konfigurációs profillal, mobileszköz-felügyeleti (MDM) megoldással, az egyszerű tanúsítványregisztrációs protokollal (SCEP) vagy a Microsoft Active Directory hitelesítésszolgáltatóval. Intelligens kártyák A macos és az újabb verziók natívan támogatják a személyazonosságot megerősítő (PIV) kártyákat. Ezeket a kártyákat széles körben használják a kereskedelmi és államigazgatási szervezetek a kétlépéses hitelesítéshez, digitális aláíráshoz és titkosításhoz. Az intelligens kártyákon egy vagy több digitális személyazonosság található, amelyek egy pár nyilvános és privát kulcsból és a társított tanúsítványból állnak. Ha feloldja az intelligens kártyát a személyes azonosító számmal (PIN), akkor hozzáférhet a hitelesítéshez, titkosításhoz és aláíráshoz használt privát kulcsokhoz. A tanúsítvány meghatározza, hogy a kulcs mire használható, milyen attribútumok társulnak hozzá, és hogy hitelesítésszolgáltató (CA) érvényesítette-e (aláírta-e). Az intelligens kártyák használhatók kétlépéses hitelesítéshez. A kártya feloldásához szükséges két faktor egyik eleme valami, ami a felhasználó birtokában van (a kártya) és valami, amit a felhasználó tud (a PIN). A macos és az újabb verziók ezenkívül natívan támogatják az intelligens kártyás bejelentkezési ablakok hitelesítését és a klienstanúsítványok hitelesítését webhelyekhez a Safariban. Ezek a rendszerek támogatják továbbá a kulcspárral (PKINIT) végzett Kerberos-hitelesítést a Kerberos által támogatott szolgáltatásokhoz való egyszeri bejelentkezés érdekében. Az okoskártyákról és a macosről további információkat a Telepítési referencia Mac géphez Az okoskártya-integráció bemutatása című részében talál. 61

62 Titkosított lemezképek A macos rendszeren a titkosított lemezképek biztonsági tárolóként szolgálnak, amelyeken a felhasználók az érzékeny dokumentumaikat és más fájljaikat tárolhatják és vihetik át. A titkosított lemezképeket az /Alkalmazások/Segédprogramok/ mappában található Lemezkezelő hozza létre. A lemezképek 128 vagy 256 bites titkosítással titkosíthatók. A felcsatolt lemezkép a Mac géphez csatlakoztatott helyi kötetnek minősül, így a felhasználók a benne tárolt fájlokat és mappákat másolhatják, áthelyezhetik és megnyithatják. A FileVault segítségével a lemezkép tartalma valós időben van titkosítva és visszafejtve. Titkosított lemezképek esetén a felhasználók biztonságosan cserélhetik a dokumentumokat, fájlokat és mappákat azáltal, hogy eltávolítható hordozóeszközre mentik a titkosított lemezképet, -üzenet mellékleteként elküldik, vagy távoli szerveren tárolják. A titkosított lemezképekre vonatkozó további információk: a Lemezkezelő felhasználói útmutatója. Kulcskarika-architektúra a macos rendszerben A macos egy Kulcskarika nevű biztonságos tárhellyel rendelkezik, ahol kényelmesen és biztonságosan tárolhatók a felhasználónevek és jelszavak, beleértve a digitális személyazonosságokat, titkosítási kulcsokat és biztonsági jegyzeteket. A Kulcskarikahozzáférésen keresztül érhető el az /Alkalmazások/Segédprogramok/ mappában. A kulcskarika használatával nem szükséges megadni az egyes erőforrásokhoz tartozó bejelentkezési adatokat sőt, emlékezni sem kell rájuk. Minden Mac-felhasználó számára létrejön egy kezdeti alapértelmezett kulcskarika, de a felhasználók adott célokra további kulcskarikákat is létrehozhatnak. A felhasználói kulcskarikákon kívül a macos számos rendszerszintű kulcskarikát használ; ezek tartják karban a nem felhasználóhoz kötött hitesítési eszközöket, például a hálózati hitelesítő adatokat és a nyilvánoskulcs-infrastruktúra (PKI) személyazonosságait. Az egyik ilyen kulcskarika, a rendszergyökér, nem kikapcsolható, és az internetes PKI gyökértanúsítvány-kibocsátó (CA) tanúsítványait tárolja, hogy ezzel segítse az olyan hétköznapi feladatokat, mint az online bankolás és az e-kereskedelem. A felhasználó hasonlóan telepíthet belsőleg előkészített CA-tanúsítványokat a felügyelt Mac gépekre, hogy segítse a belső webhelyek és szolgáltatások érvényesítését. Kulcstartók A kulcstartók áttekintése az ios és ipados rendszerben Mind a fájl, mind a Kulcskarika Data Protection osztályok kulcsait a kulcstartókban gyűjti össze és kezeli a rendszer. Az ios és az ipados a következő kulcstartókat használja: felhasználó, eszköz, biztonsági mentés, zálog és icloud biztonsági mentés. Felhasználói kulcstartó A felhasználói kulcstartó az a hely, ahol az eszköz normál használata során alkalmazott becsomagolt osztálykulcsok vannak. Ha például megadja a jelkódot, az NSFileProtectionComplete betöltődik a felhasználói kulcstartóból, és kicsomagolódik. Ez az elem egy bináris tulajdonságlista (.plist) fájl, amely a No Protection osztályban található. 62

63 Az A9-nél korábbi SoC rendszerrel szerelt eszközök esetén a.plist fájl tartalma az elvethető tárhelyen tárolt kulccsal van titkosítva. A rendszer törli és újragenerálja a kulcsot minden alkalommal, amikor a felhasználó módosítja a jelkódját, hogy továbbadja a biztonságot a kulcstartóknak. A9 vagy újabb SoC rendszerrel szerelt eszközök esetén a.plist fájl olyan kulcsot tartalmaz, amely jelzi, hogy a kulcstartó olyan zárt tárolóban van, amelyet a Secure Enclave által vezérelt lejátszás elleni nonce-a véd. A felhasználó kulcstartóját a Secure Enclave kezeli, és erről kérdezhető le az eszköz zárolási állapota. Csak akkor jelenti, hogy az eszköz fel van oldva, ha a felhasználói kulcstartóban lévő összes osztálykulcs elérhető, és sikeresen ki van csomagolva. Eszközkulcstartó Az eszközkulcstartóban az eszközre jellemző adatokat magukban foglaló műveletekhez használt becsomagolt kulcsok találhatók. A megosztott használatra konfigurált ios- és ipados-eszközöknek bizonyos esetekben hozzá kell férniük a hitelesítési adatokhoz azelőtt, hogy bármely felhasználó bejelentkezett volna; ezért olyan kulcstartó szükséges, amelyet nem véd a felhasználó jelkódja. Az ios és az ipados nem támogatja a fájlrendszer felhasználónkénti kriptográfiai elkülönítését, vagyis a rendszer az eszközkulcstartóból származó osztálykulcsokkal csomagolja be a fájlalapú kulcsokat. A Kulcskarika viszont a felhasználó kulcstartójából származó osztálykulcsokkal védi a felhasználó Kulcskarikájának elemeit. Ha az iosvagy ipados-eszköz egyetlen felhasználóhoz van konfigurálva (ez az alapértelmezett konfiguráció), akkor az eszközkulcstartó és a felhasználói kulcstartó megegyezik, és a felhasználó jelkódja védi őket. Biztonsági mentés kulcstartója A biztonsági mentés kulcstartója akkor jön létre, amikor az itunes (macos vagy korábbi verzió), illetve a Finder (macos vagy újabb verzió) titkosított biztonsági mentést hoz létre, és azon a számítógépen tárolja, amelyre az eszközről biztonsági mentés készült. Új kulcstartó jön létre új kulcsokkal, és a mentett adatok ezekkel az új kulcsokkal vannak újból titkosítva. A korábban kifejtetteknek megfelelően a nem költöztethető Kulcskarika-elemek a UID-ból származtatott kulccsal maradnak becsomagolva, így visszaállíthatók azon az eszközön, amelyikről eredetileg mentve voltak, más eszközön azonban nem érhetők el. A kulcstartón amelyet az itunesban (macos vagy korábbi verzió) vagy a Finderben (macos vagy újabb verzió) beállított jelszó véd a PBKDF2 10 millió iterációja fut le. A nagy iterációs szám ellenére ez nincs eszközhöz kötve, így a több számítógépen párhuzamosan futtatott nyers erős támadás elméletileg megpróbálható a biztonsági kulcstartó ellen. Ez a fenyegetés megfelelően erős jelszóval csökkenthető. Ha a felhasználó a titkosítás mellőzését választja, akkor a biztonsági mentés fájljai nem lesznek titkosítva, függetlenül a Data Protection-osztálytól, a Kulcskarika viszont védve marad a UID-ból származtatott kulccsal. A Kulcskarika-elemek ezért költöznek csak akkor az új eszközre, ha a be van állítva jelszó a biztonsági mentéshez. 63

64 Zálogkulcstartó A zálogkulcstartó az itunes-szinkronizáláshoz és a mobileszköz-felügyelethez (MDM) szükséges. Ezzel a kulcstartóval az itunes anélkül képes biztonsági mentés és szinkronizálást végezni, hogy a felhasználó megadná a jelkódját, valamint lehetővé teszi, hogy az MDM-megoldás távolról törölje a felhasználó jelkódját. Az itunesszal való szinkronizáláshoz használt számítógépen vagy az eszközt távolról kezelő MDMmegoldáson található. A zálogkulcstartó javítja a felhasználói élményt az eszköz szinkronizálása során, akkor ugyanis valószínűleg minden adatosztályhoz hozzá kell férni. Amikor a jelkóddal zárolt eszköz először csatlakozik az ituneshoz, a felhasználónak meg kell adnia a jelkódját. Ezután az eszköz létrehoz egy zálogkulcstartót, amely ugyanazokat az osztálykulcsokat tartalmazza, mint amelyek az eszközön vannak használatban; ezt a kulcstartót újonnan generált kulcs védi. A zálogkulcstartó és az azt védő kulcs fel vannak osztva az eszköz és az állomás vagy szerver között; az eszközön tárolt adatok a Protected Until First User Authentication osztályba tartoznak. Ezért kell megadni az eszköz jelkódját, mielőtt a felhasználó biztonsági mentést végez az itunesszal az újraindítás után először. Távoli (OTA) szoftverfrissítés esetén a felhasználónak meg kell adnia a jelkódját a frissítés megkezdésekor. Ezzel biztonságosan létrejön egy egyszer használatos feloldási token, amely a frissítés után feloldja a felhasználó kulcstartóját. Ez a token csak a felhasználó jelkódjának megadásával generálható, és minden korábban generált token érvénytelenné válik, ha a felhasználó jelkódja módosul. Az egyszeri feloldási tokenek használhatók a szoftverfrissítések felügyelt és nem felügyelt telepítéséhez. A Secure Enclave monoton számlálójának aktuális értékéből, a kulcstartó UUID-jából és a Secure Enclave UID-jából származtatott kulccsal vannak titkosítva. Az A9-nél korábbi SoC rendszerű eszközök esetén, ha a Secure Enclave processzorban az egyszer használatos feloldási token számlálója növekszik, akkor minden meglévő token érvénytelenné válik. A számláló értéke növekszik, ha a token használatba kerül, ha az újraindított eszközt feloldják, amikor a szoftverfrissítés megszakad (akár a felhasználó, akár a rendszer által), vagy ha a token irányelvi időzítője lejár. Az A9 (és újabb) SoC rendszereken az egyszeri feloldási token már nem függ a számlálóktól, sem az elvethető tárhelytől. Ehelyett a Secure Enclave által vezérelt, visszajátszást gátló nonce védi. Az egyszeri feloldási token 20 perc után lejár a felügyelt szoftverfrissítések esetén. Az ios 13 előtti rendszerek esetén a tokent a Secure Enclave processzorból exportálja a rendszer, és az elvethető tárhelyre írja. Az irányelvi időzítő lépteti a számlálót, ha az eszköz nem indul újra 20 percen belül. ios 13 és ipados 13.1 esetén a token a Secure Enclave által védett tárolóba kerül. Nem felügyelt szoftverfrissítésre akkor kerül sor, ha a rendszer elérhető frissítést észlel, és: az automatikus frissítések konfigurálva vannak ios 12 (vagy újabb) rendszeren; vagy a felhasználó a Telepítés később lehetőséget választja, amikor értesítést kap a frissítésről. 64

65 Miután a felhasználó megadta a jelkódot, egy egyszeri feloldási token generálódik, és a Secure Enclave processzorban legfeljebb 8 óráig érvényes maradhat. Ha a frissítés még nem történt meg, akkor ez az egyszeri feloldási token minden zárolással megsemmisül, és minden ezt követő feloldással újból létrejön. Minden feloldás újraindítja a 8 órás időkeretet. A 8 óra leteltével az irányelvi időzítő érvényteleníti az egyszeri feloldási tokent. icloud biztonsági mentés kulcstartója Az icloud biztonsági mentés kulcstartója hasonló a biztonsági mentés kulcstartójához. A kulcstartó összes osztálykulcsa aszimmetrikus (a Curve25519 használatával, mint Protected Unless Open Data Protection osztály esetén). Aszimmetrikus kulcstartó használatos a biztonsági mentéshez is az icloud-kulcskarika kulcskarika-visszaállítási folyamatában. 65

66 Alkalmazásbiztonság Az alkalmazásbiztonság áttekintése Az alkalmazások a modern biztonsági architektúra legfontosabb elemei közé tartoznak. Bár az alkalmazások fantasztikus produktivitást nyújtanak a felhasználók számára, ugyanakkor negatív hatással lehetnek a rendszer biztonságára és a felhasználó adataira, ha a kezelésük nem megfelelő. Emiatt az Apple többrétegű védelmet kínál, hogy az alkalmazások mentesek legyenek az ismert rosszindulatú szoftverektől, és ne legyenek illetéktelenül módosítva. További védelmi megoldások kikényszerítik, hogy az alkalmazásokból a felhasználói adatok elérése gondos vizsgálattal történjen. Ezek a biztonsági szabályozások stabil, biztonságos platformot nyújtanak az alkalmazások számára, így fejlesztők ezrei alkalmazások százezreit szállíthatják az ios, ipados és macos rendszerekre anélkül, hogy a rendszer integritása veszélybe kerülne. A felhasználók pedig hozzáférhetnek ezekhez az alkalmazásokhoz az Apple-eszközeiken anélkül, hogy félniük kellene a vírusoktól, rosszindulatú szoftverektől vagy jogosulatlan támadásoktól. Az iphone-on, ipaden és ipod touchon minden alkalmazás az App Store-ból származik, hogy a legszigorúbb szabályozás alá essenek az alkalmazások pedig a homokozóban vannak. A Mac gépen számos alkalmazás szintén az App Store-ból érkezik, de a Mac gép felhasználói az internetről letöltött alkalmazásokat is használhatnak. Az internetes letöltések biztonságos támogatása érdekében a macos további szabályozásokat használ. Először is, a macos és újabb verziók esetén a Mac-alkalmazásokat indítás előtt az Apple-nek hitelesítenie kell. Ez a követelmény gondoskodik róla, hogy az alkalmazások mentesek a rosszindulatú szoftverektől, így nem szükséges az App Store-on keresztül biztosítani őket. Ezenkívül a macos a legkorszerűbb antivírus-védelemmel blokkolja és szükség esetén eltávolítja a rosszindulatú szoftvereket. A platformokon átívelő további szabályozóként a homokozó segít megvédeni a felhasználói adatokat attól, hogy az alkalmazások illetéktelenül férjenek hozzájuk. A macos rendszerben a kritikus területen lévő adatok maguk is homokozóban vannak, ami gondoskodik arról, hogy a felhasználók kezében marad a fájlok elérésének irányítása minden alkalmazásban az Íróasztal, a Dokumentumok, a Letöltések és más helyek esetén, függetlenül attól, hogy a hozzáférést kérő alkalmazások maguk homokozóban vannak-e vagy sem. 66

67 Natív funkció Nem jóváhagyott pluginok listája, nem jóváhagyott Safari-bővítmények listája Fájlkarantén XProtect/Yara-aláírások MRT (Rosszindulatú szoftvereket eltávolító eszköz) Gatekeeper eficheck (Szükséges az Apple T2 Security chippel nem rendelkező Mac gépek esetén) Alkalmazástűzfal Csomagszűrő (pf) Rendszerintegritás-védelem Kötelező hozzáférés-szabályozások KEXT-kizárási lista Kötelező alkalmazás-kódaláírás Alkalmazáshitelesítés Harmadik fél ekvivalens megoldása Vírus-/rosszindulatúszoftver-definíciók Vírus-/rosszindulatúszoftver-definíciók Vírus-/rosszindulatúszoftver-definíciók Végpontvédelem Végpontvédelem. Kényszeríti az alkalmazások kódaláírását, hogy csak a megbízható szoftverek futhassanak. Végpontvédelem rootkitészlelés Végpontvédelem tűzfal Tűzfalmegoldások Ezt csak az Apple tudja biztosítani Ezt csak az Apple tudja biztosítani Ezt csak az Apple tudja biztosítani Ezt csak az Apple tudja biztosítani Ezt csak az Apple tudja biztosítani Alkalmazásbiztonság az ios és ipados rendszerben Az ios és az ipados alkalmazásbiztonságának áttekintése Más mobilplatformoktól eltérően az ios és az ipados nem engedélyezi a felhasználóknak, hogy potenciálisan rosszindulatú, alá nem írt, webhelyekről származó alkalmazásokat telepítsenek, vagy nem megbízható alkalmazásokat futtassanak. Futásidőben a kódaláírás minden végrehajtható memóriaoldalt megvizsgál, miközben betöltődnek, így ellenőrzi, hogy az alkalmazás nem módosult a telepítése vagy a legutóbbi frissítése óta. Ha az alkalmazás ellenőrizhetően jóváhagyott forrásból származik, az ios és az ipados biztonsági lépésekkel kényszeríti ki, hogy az ne módosíthasson más alkalmazást, sem a rendszer többi részét. 67

68 Az alkalmazáskód aláírásának folyamata Kötelező kódaláírás Az ios és az ipados kernele az indulás után szabályozza, hogy mely folyamatok és alkalmazások futhatnak. Az ios és az ipados megköveteli, hogy minden végrehajtható kód az Apple által kibocsátott tanúsítvánnyal legyen aláírva, így gondoskodik arról, hogy minden alkalmazás ismert és jóváhagyott forrásból származik, és nincs illetéktelenül módosítva. Az eszközzel együtt érkező alkalmazásokat, például a Mailt és a Safarit az Apple írja alá. A külső alkalmazásokat is érvényesíteni és aláírni kell az Apple által kibocsátott tanúsítvánnyal. A kötelező kódaláírás kiterjeszti a megbízhatósági lánc fogalmát az operációs rendszerről az alkalmazásokra, és meggátolja, hogy külső alkalmazások alá nem írt kóderőforrásokat vagy önmagát módosító kódot töltsenek be. Az alkalmazások aláírásának módja a fejlesztők számára A tanúsítvány érvényesítése Ahhoz, hogy a fejlesztők ios- és ipados-eszközökhöz fejlesszenek és telepíthessenek alkalmazásokat, regisztrálniuk kell az Apple-nél, és csatlakozniuk kell az Apple Developer Programhoz. Az Apple a tanúsítvány kiadása előtt ellenőrzi a fejlesztők valódi személyét, legyen szó természetes személyről vagy vállalkozásról. A tanúsítvány segítségével a fejlesztők aláírhatják az alkalmazásaikat, és terjesztésre beküldhetik az App Storeba. Ennek eredményeképpen az App Store-ban lévő összes alkalmazás azonosítható személytől vagy szervezettől származik, és ez elrettentőleg hat a rosszindulatú alkalmazások létrehozására. Az alkalmazásokat az Apple is ellenőrzi, hogy az általános működésük megfeleljen a leírtaknak, és ne tartalmazzanak nyilvánvaló hibákat és egyéb észlelhető problémákat. A már leírt technológia mellett ez az áttekintési folyamat is arról gondoskodik, hogy a felhasználók megbízhatnak a vásárolt alkalmazások minőségében. A dinamikus függvénytárak ellenőrzése Az ios és az ipados lehetővé teszi, hogy a fejlesztők keretrendszereket ágyazzanak be az alkalmazásokba, amelyeket az alkalmazások maguk, vagy az alkalmazásokba ágyazott bővítmények használhatnak. Azért, hogy megvédje saját magát és más alkalmazásokat attól, hogy külső féltől származó kódot töltsenek be a címzési helyükön belül, a rendszer ellenőrzi a kódaláírást az összes olyan dinamikus függvénytár esetén, amelyekhez a folyamatok indításkor kapcsolódnak. Ez az ellenőrzés a csoportazonosító segítségével történik, amely az Apple által kibocsátott tanúsítványból nyerhető ki. A csoportazonosító egy 10 karakterből álló alfanumerikus karakterlánc például 1A2B3C4D5F. A programok kapcsolódhatnak a rendszerrel együtt szállított vagy bármely más függvénytárakhoz, ha azok csoportazonosítója azonos a kódaláírásban és a fő végrehajtható részben. Mivel a rendszer részeiként szállított végrehajtható elemeknek nincs csoportazonosítójuk, ezért ezek csak a rendszerrel együtt szállított függvénytárakhoz kapcsolódhatnak. Vállalati alkalmazások ellenőrzése A vállalkozások írhatnak házon belül használatos alkalmazásokat, amelyeket terjeszthetnek az alkalmazottaik számára. A vállalkozások és szervezetek pályázhatnak az Apple Developer Enterprise Programba (ADEP) D-U-N-S számmal. Az Apple a személyazonosság és a megfelelőség ellenőrzése után hagyja jóvá a pályázókat. Ha a szervezet az ADEP tagja lett, regisztrálhat előkészítési profil megszerzésére, amely segítségével a házon belüli alkalmazások futhatnak a feljogosított eszközökön. 68

69 A felhasználóknak a házon belüli alkalmazások futtatásához telepíteni kell az előkészítési profilt. Ez a profil gondoskodik arról, hogy a szervezet által kívánt felhasználók képesek betölteni az alkalmazásokat az ios- és ipados-eszközeikre. A mobileszköz-felügyelet (MDM) segítségével telepített alkalmazások maguktól értetődően megbízhatók, mivel a szervezet és az eszköz közötti viszony már létrejött. Egyéb esetekben a felhasználóknak jóvá kell hagyniuk az alkalmazás előkészítési profilját a beállításokban. A szervezetek letilthatják a felhasználókat az ismeretlen fejlesztőktől származó alkalmazások elfogadásától. Bármely vállalati alkalmazás esetén az eszköznek pozitív megerősítést kell kapnia az Apple-től, hogy az alkalmazás futása engedélyezett. A futásidejű folyamatok biztonsága Homokozó Minden külső féltől származó alkalmazás a homokozóban van, vagyis nem érhetik el a más alkalmazások által tárolt fájlokat, illetve nem végezhetnek módosításokat az eszközön. A homokozó megakadályozza, hogy az alkalmazások más alkalmazások által tárolt adatokat gyűjtsenek össze vagy módosítsanak. Minden alkalmazásnak saját könyvtára van a fájljaihoz, amelynek hozzárendelése véletlenszerűen történik az alkalmazás telepítésekor. Ha a külső féltől származó alkalmazásnak a saját információin túl is hozzá kell férnie információkhoz, azt csak az ios és ipados által kifejezetten biztosított szolgáltatások használatával teszi. A rendszerfájlok és -erőforrások szintén védve vannak a felhasználó alkalmazásaitól. Az ios és az ipados legnagyobb része a nem emelt jogosultságú mobile felhasználói térben fut, mint az összes külső féltől származó alkalmazás. Az operációs rendszer teljes partíciója írásvédettként van felcsatolva. A szükségtelen eszközök, mint a távoli bejelentkezéses szolgáltatások, nem képezik részét a rendszerszoftvernek, és az API-k nem engedélyezik az alkalmazásoknak, hogy megemeljék saját jogosultságaikat más alkalmazások, illetve az ios vagy az ipados módosításához. Jogosultságok használata Meghatározott jogosultságok szabályozzák, hogy a külső féltől származó alkalmazások milyen felhasználói adatokhoz és funkciókhoz (például icloud), valamint bővítményekhez férhetnek hozzá. A jogosultságok olyan kulcs-érték párok, amelyek be vannak jelentkezve az alkalmazásokba, és a futásidejű tényezőkön (például UNIX-felhasználóazonosítón) túl engedélyezik a hitelesítést. A jogosultságok nem módosíthatók, mivel digitálisan vannak aláírva. A jogosultságokat széles körben használják a rendszeralkalmazások és démonok, hogy olyan meghatározott, privilegizált műveleteket hajtsanak végre, amelyekhez más esetekben a folyamatnak gyökérfolyamatként kellene futnia. Ez nagyban csökkenti annak a lehetőségét, hogy egy sérült rendszeralkalmazás vagy démon kiterjessze a privilégiumait. Az alkalmazások ezenkívül csak háttérfeldolgozást végezhetnek a rendszer által biztosított API-kon keresztül. Ennek segítségével az alkalmazások a teljesítmény vagy az akkumulátor élettartamának jelentős csökkentése nélkül működhetnek tovább. 69

70 További védelmi lépések A címtérkiosztás véletlenszerűvé tétele A címtérkiosztás véletlenszerűvé tétele (ASLR) a sérült memória okozta hibák kihasználása ellen véd. A beépített alkalmazások az ASLR segítségével gondoskodnak arról, hogy minden memóriaterület véletlenszerű legyen az indításkor. A végrehajtható kódok, rendszerfüggvénytárak és kapcsolódó programozási konstruktumok memóriacímének véletlenszerű elrendezése sok kifinomult visszaélés lehetőségét csökkenti. A return-tolibc támadás például arra próbálja rávenni az eszközt, hogy rosszindulatú kódot hajtson végre azáltal, hogy a verem és a rendszerfüggvénytárak memóriacímét manipulálja. Ezek elhelyezkedésének véletlenszerűvé tételével a támadás sokkal nehezebben hajtható végre, különösen több eszközön át. Az Xcode, az ios és az ipados fejlesztői környezetei automatikusan bekapcsolt ASLR-támogatással állítják össze a külső féltől származó programokat. Execute Never Az ios és az ipados az ARM Execute Never (XN) funkciójával további védelmet biztosít; ez a funkció bizonyos memóriaoldalakat végre nem hajthatóként jelöl meg. Az írhatóként és végrehajthatóként megjelölt memóriaoldalakat csak a szigorúan szabályozott feltételek mellett működő alkalmazások használhatják. A kernel ellenőrzi, hogy jelen van-e a csak az Apple által biztosított dinamikus kódaláírási jogosultság. Még ebben az esetben is csak egyetlen mmap-hívás végezhető el a végrehajtható és írható oldal kéréséhez, amely véletlenszerű címet kap. A Safari ezt a funkciót használja a JavaScript JIT-összeállítójához. Bővítmények támogatása Az ios és ipados rendszerekben az alkalmazások más alkalmazásoknak nyújthatnak funkciókat a bővítmények segítségével. A bővítmények alkalmazásba csomagolt, speciális célú aláírt végrehajtható bináris fájlok. A telepítés során a rendszer automatikusan észleli a bővítményeket, és egyeztetési rendszer használatával elérhetővé teszi őket más alkalmazások számára. Bővítési pontok Bővítési pontnak nevezik a rendszer azon területét, amely támogatja a bővítményeket. Minden bővítési pont API-kat biztosít, és irányelveket kényszerít ki az adott területre. A rendszer az egyes bővítési pontokra jellemző egyező szabályok alapján meghatározza, hogy mely bővítmények érhetők el. A rendszer automatikusan, szükség szerint elindítja a bővítményfolyamatokat, és kezeli az életciklusukat. A jogosultságok segítségével a bővítmények elérhetősége korlátozható adott rendszeralkalmazásokra. A Ma nézet widget például csak az Értesítési központban jelenik meg, és a megosztási bővítmény csak a Megosztás panelről érhető el. Példák a bővítési pontokra: Ma widgetek, Megosztás, Műveletek, Fotószerkesztés, Fájlszolgáltató és Egyéni billentyűzet. 70

71 A bővítmények kommunikálási módja A bővítmények a saját címterükben futnak. A bővítmény és az azt aktiváló alkalmazás kommunikációjához a rendszer keretrendszere által felügyelt, folyamatok közötti kommunikáció használatos. Nem férnek hozzá egymás fájljaihoz vagy memóriaterületeihez. A bővítmények úgy vannak tervezve, hogy egymástól, az őket tartalmazó alkalmazásoktól és az őket használó alkalmazásoktól elkülönüljenek. A homokozóban vannak, mint a többi, külső féltől származó alkalmazás, és tárolójuk elkülönül a tartalmazó alkalmazás tárolójától. Az adatvédelmi vezérlőjük azonban ugyanaz, mint a tartalmazó alkalmazásé. Ha tehát a felhasználó engedélyezi, hogy a Kontaktok hozzáférjen egy alkalmazáshoz, ez az engedély kiterjed az alkalmazásba épített bővítményekre, az alkalmazás által aktivált bővítményekre viszont nem. Az egyéni billentyűzetek használata Az egyéni billentyűzetek speciális bővítmények, mivel a felhasználó az egész rendszerre engedélyezi őket. Az engedélyezés után a billentyűzetbővítmény a jelkódbemenet és a biztonságos szövegnézet mezőn kívül minden szövegmezőhöz használatos. A felhasználói adatok átvitelének korlátozása érdekében az egyéni billentyűzetek alapértelmezés szerint nagyon korlátozó homokozóban futnak, amely blokkolja a hálózat elérését, a más folyamatok nevében hálózati műveleteket végrehajtó szolgáltatások elérését és az olyan API-k elérését, amelyek lehetővé tennék, hogy a bővítmény kiszűrje a gépelési adatokat. Az egyéni billentyűzetek fejlesztői kérhetik, hogy a bővítményük Nyitott hozzáféréssel rendelkezzen, ami lehetővé teszi, hogy a rendszer a felhasználó beleegyezése után az alapértelmezett homokozóban futtassa a bővítményt. Az MDM és a bővítmények A mobileszköz-felügyelet (MDM) megoldásban regisztrált eszközök esetén a dokumentum- és billentyűzetbővítmények követik a Managed Open In szabályokat. Az MDM-megoldás például meggátolhatja, hogy a felhasználó felügyelt alkalmazásból nem felügyelt dokumentumszolgáltatóba exportáljon dokumentumot, vagy hogy nem felügyelt billentyűzetet használjon felügyelt alkalmazásban. A fejlesztők ezenkívül meggátolhatják a külső féltől származó billentyűzetbővítmények használatát az alkalmazásaikban. Az adatvédelem átvétele az alkalmazásokban Az ios és ipados rendszerhez készült ios Software Development Kit (SDK) API-k teljes készletét kínálja, amellyel a külső és a házon belüli fejlesztők könnyen átvehetik az Adatvédelem beállításait, valamint segít az alkalmazásokban a legmagasabb szintű védelmet elérni. Az adatvédelem elérhető fájlok és adatbázisok API-jaihoz, beleértve az NSFFileManager, a CoreData, az NSData és az SQLite adatbázisokat. A Mail alkalmazás adatbázisa (mellékletekkel együtt), a felügyelt könyvek, a Safari könyvjelzői, az alkalmazások indítóképei és a helyadatok szintén titkosítva vannak tárolva, a kulcsokat pedig a felhasználó eszközön használt jelkódja védi. A Naptár (a mellékletek nélkül), a Kontaktok, az Emlékeztetők, a Jegyzetek, az Üzenetek és a Fotók a Protected Until First User Authentication adatvédelmi jogosultságot használják. Azok a felhasználó által telepített alkalmazások, amelyek nem használnak meghatározott adatvédelmi osztályt, alapértelmezés szerint a Protected Until First User Authentication jogosultságot kapják. 71

72 Csatlakozás alkalmazáscsoporthoz Egy adott fejlesztői fiókhoz tartozó alkalmazások és bővítmények megoszthatják egymással tartalmaikat, ha egy alkalmazáscsoport részeként vannak konfigurálva. A fejlesztőn múlik, hogy létrehozza-e a megfelelő csoportokat az Apple Developer Portalon, és feltünteti-e a kívánt alkalmazásokat és bővítményeket. Az alkalmazások, miután alkalmazáscsoport részeként lettek konfigurálva, a következőkhöz férnek hozzá: Megosztott tároló a köteten, amely mindaddig az eszközön marad, amíg a csoport legalább egy alkalmazása telepítve van Megosztott beállítások Megosztott Kulcskarika-elemek Az Apple Developer Portal gondoskodik arról, hogy az alkalmazások csoportazonosítói (GID) az alkalmazások ökoszisztémájában egyediek legyenek. Kiegészítők ellenőrzése A Made for iphone, ipad és ipod touch (MFi) licencprogram ellenőrzött kiegészítőgyártókat biztosít az ipod Accessories Protocolhoz (iap) és a szükséges támogatási hardverösszetevőkhöz. Amikor az MFi-kiegészítő ios- vagy ipados-eszközzel kommunikál Lightning-csatlakozó vagy Bluetooth segítségével, az eszköz megkéri a kiegészítőt, hogy bizonyítsa az Apple általi feljogosítottságát azáltal, hogy az Apple által biztosított tanúsítvánnyal válaszol, amelyet az eszköz ellenőriz. Az eszköz ezután kérést küld, amelyre a kiegészítőnek aláírt válasszal kell válaszolnia. A folyamatot teljes egészében egy egyéni integrált áramkör (IC) végzi, amelyet az Apple biztosít a jóváhagyott kiegészítőgyártóknak, és amely transzparens a kiegészítő felé. A kiegészítők különféle átviteli módokhoz és funkciókhoz kérhetnek hozzáférést például digitális hangfolyamhoz a Lightning-kábelen keresztül vagy Bluetoothon keresztül biztosított helyadatokhoz. A hitelesítési IC gondoskodik arról, hogy csak a jóváhagyott kiegészítők kapnak teljes hozzáférést az eszközhöz. Ha a kiegészítő nem támogatja a hitelesítést, akkor a hozzáférése az analóg hangra és a hanglejátszás soros vezérlőinek egy kis részhalmazára (UART) korlátozódik. Az AirPlay ezenkívül a hitelesítési IC-vel ellenőrzi, hogy a vevőkészüléket az Apple jóváhagyta-e. Az AirPlay audio- és a CarPlay videostreamjei az MFi-SAP (biztonságos hozzáférésű protokoll) protokollt használják, amelyek CTR-módú AES-128 típusú eljárással titkosítják a kiegészítő és az eszköz közötti kommunikációt. A rövid élettartamú kulcsok cseréje az ECDH-kulcscserével (Curve25519) történik, és a hitelesítési IC 1024 bites RSAkulcsával vannak aláírva a Station-to-Station (STS) protokoll részeként. 72

73 Alkalmazásbiztonság a macos rendszerben A macos alkalmazásbiztonságának áttekintése A macos alkalmazásbiztonsága számos egymást fedő rétegből áll az első ezek közül az a beállítás, hogy csak az App Store-ból származó, aláírt és megbízható alkalmazást futtat. A macos ezenkívül rétegzett védelemmel győződik meg arról, hogy az internetről letöltött alkalmazások mentesek az ismert rosszindulatú szoftverektől. Technológiákat kínál a rosszindulatú szoftverek észlelésére és eltávolítására, és további védelmet nyújt arra, hogy a nem megbízható alkalmazások ne férjenek hozzá a felhasználói adatokhoz. Végezetül pedig a macos felhasználói kiválaszthatják a számukra legmegfelelőbb biztonsági modellt akár az alá nem írt és nem megbízható kódot is futtathatják. Az alkalmazáskód aláírásának folyamata a macos rendszeren Az App Store-ból származó alkalmazásokat az Apple aláírja, így biztosítva, hogy azok nincsenek illetéktelenül módosítva. Az Apple az Apple-eszközökkel érkező összes alkalmazást aláírja. macos esetén az App Store-on kívül terjesztett alkalmazásokat a fejlesztőnek alá kell írnia egy, az Apple által kibocsátott fejlesztőazonosítói tanúsítvánnyal (és privát kulccsal), és azt az Apple-nek hitelesítenie kell, hogy az alapértelmezett Gatekeeperbeállítások mellett futhassanak. A házon belül fejlesztett alkalmazásokat is alá kell írni egy, az Apple által kibocsátott fejlesztőazonosítóval, hogy a felhasználók ellenőrizhessék az integritásukat. A macos rendszeren a kódaláírás és a hitelesítés egymástól függetlenül zajlik és eltérő személyek is végrehajthatják ezeket, és más-más célokat szolgálnak. A kódot a fejlesztő írja alá a saját fejlesztőazonosítói tanúsítványával (amelyet az Apple bocsát ki), és ennek az aláírásnak az ellenőrzése a biztosíték a felhasználónak, hogy a fejlesztő szoftvere nem módosult illetéktelenül, amióta összeállította és aláírta. A hitelesítést a szoftverterjesztési lánc bármely szereplője elvégezheti; ez a művelet arra biztosíték, hogy az Apple is megkapta a kódot a rosszindulatú szoftverek iránti ellenőrzésre, és nem talált ismert rosszindulatú szoftvert. A hitelesítés végeredménye egy jegy, amelyet az Apple szerverei tárolnak, és amely opcionálisan az alkalmazáshoz csatolható (bárki által) anélkül, hogy ezzel a fejlesztő aláírása érvénytelenné válna. A kötelező hozzáférés-szabályzók (MAC-k) megkövetelik a kódaláírást a rendszer által védett jogosultságok engedélyezéséhez. A tűzfalon való átjutást kérő alkalmazásokat például a megfelelő MAC-jogosultsággal kell aláírni. 73

74 Gatekeeper és futásidejű védelem Gatekeeper A macos egy Gatekeeper nevű technológiát biztosít, amely gondoskodik arról, hogy alapértelmezés szerint csak megbízható szoftver fusson a felhasználó Mac gépén. Amikor a felhasználó az App Store-on kívülről tölt le és nyit meg alkalmazást, plugint vagy telepítőcsomagot, a Gatekeeper ellenőrzi, hogy a szoftver beazonosítható fejlesztőtől származik-e, az Apple hitelesítette-e, hogy mentes az ismert rosszindulatú tartalomtól, valamint hogy nincs-e módosítva. A Gatekeeper ezenkívül a felhasználó beleegyezését is kéri a letöltött szoftver első megnyitása előtt, így gondoskodva arról, hogy a felhasználó nehogy akarata ellenére egyszerű adatfájlnak hitt végrehajtható kódot futtasson. Alapértelmezés szerint a Gatekeeper gondoskodik arról, hogy minden letöltött szoftver az App Store által legyen aláírva, vagy regisztrált fejlesztő által legyen aláírva és az Apple által hitelesítve. Mind az App Store ellenőrzési folyamata, mind a hitelesítési folyamat biztosítja, hogy az alkalmazások nem tartalmaznak ismert rosszindulatú szoftvert. Ezért a macos rendszeren az összes szoftver ellenőrizve van a rosszindulatú tartalom tekintetében az első megnyitáskor, függetlenül attól, hogy hogyan érkezett a Mac gépre. A felhasználók és a szervezetek választhatják azt a lehetőséget, hogy csak az App Store-ból telepített szoftvereket engedélyezik. A felhasználók felülírhatják továbbá a Gatekeeper irányelveit, így bármely szoftvert megnyithatják, ha a mobileszköz-felügyeleti (MDM) megoldás nem korlátozza. A szervezetek az MDM segítségével konfigurálhatják a Gatekeeper beállításait, beleértve a változó személyazonossággal aláírt szoftverek engedélyezését. Szükség esetén a Gatekeeper teljesen ki is kapcsolható. A Gatekeeper védelmet nyújt az ártalmatlan alkalmazásokkal érkező rosszindulatú pluginok ellen, vagyis amikor az alkalmazás használata rosszindulatú plugin betöltését váltja ki a felhasználó tudta nélkül. Szükség esetén a Gatekeeper véletlenszerű, írásvédett helyekről nyitja meg az alkalmazásokat, ezzel meggátolva az alkalmazással együtt terjesztett pluginok automatikus betöltését. Futásidejű védelem A rendszerfájlok, az erőforrások és a kernel védve van a felhasználó alkalmazásterületétől. Az App Store-ból származó összes alkalmazás homokozóban fut, hogy korlátozva legyen a más alkalmazások által tárolt adatok elérésében. Ha az App Store-ból származó bármely alkalmazásnak másik alkalmazás adatait kell elérnie, akkor ezt csak a macos által biztosított API-k és szolgáltatások használatával teheti meg. 74

75 Védelem a rosszindulatú szoftverek ellen XProtect A macos XProtect nevű, beépített, korszerű vírusvédelmi technológiája aláírás-alapú észlelést használ a rosszindulatú programok elleni védelmi észleléséhez, amelynek használata támogatja a vírusvédelmi és rosszindulatú programok elleni bevált védelmi eljárásokat. A rendszer YARA-aláírásokat használ, amelyeket az Apple rendszeresen frissít. Az Apple figyeli az új rosszindulatú szoftvereket és deformációkat, és a rendszerfrissítésektől függetlenül automatikusan frissíti az aláírásokat, hogy megvédje a Mac gépeket a rosszindulatú szoftverek okozta fertőzésektől. Az XProtect automatikusan észleli és blokkolja az ismert rosszindulatú szoftverek végrehajtását. macos vagy újabb verzió esetén az XProtect ismert rosszindulatú tartalmat keres, ha az alkalmazás: először indul el; módosul. Ha az XProtect ismert rosszindulatú szoftvert észlel, a szoftvert blokkolja, értesíti a felhasználót, és felkínálja annak a lehetőségét, hogy a Kukába helyezze a szoftvert. Rosszindulatú szoftvereket eltávolító eszköz Ha a rosszindulatú szoftver bekerül a Mac gépbe, a macos rendelkezik technológiákkal a fertőzés kijavítására. A Rosszindulatú szoftvereket eltávolító eszköz (MRT) a macos egy olyan motorja, amely az Apple-től származó (rendszeradatfájlok automatikus frissítései és biztonsági frissítések részeként kapott) automatikus frissítések alapján hatástalanítja a fertőzéseket. Az Apple azonkívül, hogy figyeli az ökoszisztémában a rosszindulatú szoftverek tevékenységeit, hogy vissza tudja hívni a fejlesztők azonosítóit (ha van ilyen), és XProtect-frissítéseket bocsáthasson ki, az MRT rendszerhez is ad ki frissítéseket, hogy el lehessen távolítani a rosszindulatú szoftvereket az érintett rendszerekből, ha azok az automatikus biztonsági frissítések fogadására vannak konfigurálva. Az MRT eltávolítja a rosszindulatú kódokat a frissített információk megkapásakor, és folyamatosan keresi a fertőzéseket az újraindításkor és bejelentkezéskor. Az MRT nem indítja újra automatikusan a Mac gépet. Automatikus biztonsági frissítések Az Apple automatikusan kiadja az XProtect és a rosszindulatú szoftvereket eltávolító eszköz frissítéseit a fenyegetésekkel kapcsolatos legújabb információk alapján. Alapértelmezés szerint a macos naponta ellenőrzi a frissítéseket. Az automatikus biztonsági frissítésekkel kapcsolatos további tudnivalókért tekintse meg ezt az Appletámogatási cikket: Automatikus biztonsági frissítések 75

76 Alkalmazások fájlelérésének szabályozása Az Apple nézete szerint a felhasználóknak teljes átláthatóságot, beleegyezést és szabályozást kell biztosítani arra vonatkozóan, hogy az alkalmazások hogyan használják az adataikat. A macos rendszerben ezt a modellt a rendszer kényszeríti ki, hogy minden alkalmazás megkapja a felhasználó beleegyezését, mielőtt hozzáfér a Dokumentumok, Letöltések, Íróasztal, az icloud Drive vagy a hálózati kötetek fájljaihoz. A macos és újabb rendszereken kifejezetten hozzá kell adni a Rendszerbeállításokban azokat az alkalmazásokat, amelyeknek a teljes tárhelyeszközhöz hozzá kell férniük. Ezenkívül a kisegítő lehetőségek és az automatizálás képességeihez a felhasználó engedélye szükséges, hogy ne lehessen megkerülni más védelmeket. A hozzáférési irányelvtől függően a felhasználónak esetleg választania kell, vagy módosítania kell a beállítást a Rendszerbeállítások > Biztonság és adatvédelem > Adatvédelem menüpontban: Elem Az alkalmazás a felhasználótól kér döntést A felhasználónak módosítania kell az adatvédelmi beállításokat Kisegítő lehetőségek Hozzáférés a teljes tárolóeszközhöz Fájlok és mappák Megjegyzés: Beleértve: Íróasztal, Dokumentumok, Letöltések, hálózati kötetek és eltávolítható kötetek Automatizálás (Apple-események) A felhasználó Kukájában lévő elemek védve vannak minden olyan alkalmazástól, amelyek a Teljes hozzáférés a lemezhez jogosultságot használják, és a felhasználó nem fog kérést kapni az alkalmazás-hozzáférés engedélyezésére. Ha a felhasználó hozzá szeretne férni a fájlokhoz, először át kell őket helyeznie a Kukából másik helyre. Ha a felhasználó engedélyezi a FileVault funkciót a Mac gépen, akkor érvényes hitelesítő adatokat kell megadnia, mielőtt folytatná a rendszerindítási folyamatot, és speciális indítási módokhoz férhetne hozzá. Érvényes bejelentkezési hitelesítő adatok vagy visszaállítási kulcs nélkül a teljes kötet titkosítva marad, és védve van a jogosulatlan hozzáféréstől, még akkor is, ha a fizikai tárolóeszközt eltávolítják, és másik számítógéphez csatlakoztatják. Ha vállalati körülmények között szeretné megvédeni az adatait, az IT-osztálynak definiálni és kényszeríteni kell a FileVault konfigurációs irányelveit a mobileszköz-felügyelet (MDM) használatával. A szervezetek számos módon felügyelhetik a titkosított köteteket, beleértve az intézményi visszaállítási kulcsokat, személyes visszaállítási kulcsokat (ezek zálogként opcionálisan az MDM-mel tárolhatók) vagy a kettő kombinációját. A kulcsok cseréje is beállítható irányelvként az MDM-ben. 76

77 Biztonsági funkciók a Jegyzetek alkalmazásban Biztonsági jegyzetek A Jegyzetek alkalmazás része a biztonsági jegyzetek funkció, amellyel a felhasználók bizonyos jegyzetek tartalmát védhetik meg. A biztonsági jegyzetek végponttól végpontig vannak titkosítva a felhasználó által megadott jelszóval; ezt meg kell adni, ha meg szeretné tekinteni a jegyzeteket az ios, ipados, macos rendszeren, valamint az icloud webhelyen. Minden icloud-fiók (beleértve a Saját eszközöm eszközfiókokat) eltérő jelszóval rendelkezhet. Amikor a felhasználó biztonságossá teszi a jegyzetet, a rendszer 16 bájtos kulcsot hoz létre a felhasználó jelszavából PBKDF2 és SHA256 titkosítás segítségével. A jegyzet és mellékleteinek titkosítása AES-GCM használatával történik. Az új rekordok a Core Datában és a CloudKitben jönnek létre, ezek tárolják a titkosított jegyzetet, a mellékleteket, címkét és inicializálási vektort. A rekord létrejötte után az eredeti titkosítatlan adatok törlődnek. A titkosítást támogató mellékletek közé tartoznak a képek, skiccek, táblázatok, térképek és webhelyek. Más típusú mellékleteket tartalmazó jegyzetek nem titkosíthatók, és a nem támogatott mellékletek nem adhatók hozzá a biztonsági jegyzetekhez. A biztonsági jegyzet megtekintéséhez a felhasználóknak meg kell adniuk a jelszavukat, vagy hitelesíteniük kell magukat a Touch ID vagy a Face ID segítségével. A felhasználó sikeres hitelesítése után a Jegyzetek biztonsági munkamenetet nyit meg, ahol megtekinthet és létrehozhat biztonsági jegyzeteket. Amíg a biztonságos munkamenet meg van nyitva, a felhasználó megtekinthet és biztonságossá tehet további jegyzeteket minden egyéb hitelesítés nélkül. A biztonsági munkamenet azonban csak a megadott jelszóval rendelkező jegyzetekre vonatkozik. A más jelszóval védett jegyzetek esetén a felhasználónak továbbra is hitelesítenie kell magát. A biztonsági munkamenet bezárul, ha: A felhasználó a Zárolás most gombra kattint a Jegyzetekben A Jegyzetek több mint 3 percig a háttérben van (macos esetén 8 percig) Az ios- vagy ipados-eszköz zárolódik Ha módosítani szeretné a biztonsági jegyzet jelszavát, akkor a felhasználónak meg kell adni az aktuális jelszót, mivel a Touch ID és a Face ID nem érhető el a jelszó módosításához. Az új jelszó kiválasztása után a Jegyzetek alkalmazás újracsomagolja az azonos fiókban meglévő, az előző jelszóval titkosított összes jegyzet kulcsát. Ha a felhasználó egymás után háromszor helytelenül adja meg a jelszót, a Jegyzetek emlékeztetőt jelenít meg, ha a felhasználó megadott olyat a beállítás során. Ha a felhasználó még így sem emlékszik a jelszóra, akkor visszaállíthatja azt a Jegyzetek beállításaiban. Ezzel a funkcióval a felhasználó új biztonsági jegyzeteket hozhat létre új jelszóval, a korábban védett jegyzeteit azonban így nem tekintheti meg. A korábban védetté tett jegyzetek akkor tekinthetők meg, ha a felhasználó emlékszik a korábbi jelszóra. A jelszó visszaállításához a felhasználó icloud-fiókjának jelszava szükséges. 77

78 Megosztott jegyzetek Azok a jegyzetek, amelyek nincsenek végponttól végpontig jelszóval titkosítva, megoszthatók másokkal. A megosztott jegyzetek továbbra is a CloudKit által titkosított adattípust használják minden olyan szöveg vagy melléklet esetén, amelyet a felhasználó a jegyzetbe visz. Az eszközök mindig a CKRecord osztályban titkosított kulccsal vannak titkosítva. A metaadatok, például a létrehozás és a módosítás dátuma nincsenek titkosítva. A CloudKit felügyeli azt a folyamatot, amellyel a résztvevők titkosíthatják és visszafejthetik egymás adatait. Biztonsági funkciók a Parancsok alkalmazásban A Parancsok alkalmazás parancsai igény szerint szinkronizálhatók az Apple-eszközök között az icloud segítségével. A parancsok meg is oszthatók másokkal az icloudon keresztül. A parancsok helyben tárolódnak, titkosított formában. Az egyéni parancsok sokoldalúak hasonlóak a szkriptekhez és a programokhoz. Amikor parancsokat tölt le az internetről, a felhasználó figyelmeztetést kap arról, hogy az Apple nem ellenőrizte a parancsot, és lehetőséget kap megvizsgálni azt. A rosszindulatú parancsok elleni védekezés céljából a rendszer letölti a rosszindulatú szoftverek frissített definícióit, hogy futásidőben azonosítsa a rosszindulatú parancsokat. Az egyéni parancsok futtathatnak a Safariban felhasználói JavaScript-fájlokat a webhelyeken, ha a megosztás lapról vannak meghívva. A rendszer az említett, rosszindulatú szoftverek definíciói alapján ellenőrzi a JavaScript-fájlt, hogy kivédje az olyan rosszindulatú JavaScript-fájlokat, amelyek például olyan helyzetbe csalják a felhasználót, hogy az szkriptet futtasson közösségimédia-webhelyeken, amelyek aztán összegyűjtik az adatait. A rendszer felkéri a felhasználót, amikor először futtat JavaScript-fájlt egy doménen, hogy engedélyezze a JavaScriptet tartalmazó parancsok futtatását az adott domén weboldalán. 78

79 Szolgáltatásbiztonság A szolgáltatásbiztonság áttekintése Az Apple robusztus szolgáltatáskészletet állított össze, amellyel a felhasználók jobban és produktívabban használhatják eszközeiket. Ezen szolgáltatások közé tartozik az Apple ID, az icloud, a Bejelentkezés az Apple-lel, az Apple Pay, az imessage, a FaceTime és a Lokátor. Ezek a szolgáltatások hatékony lehetőségeket biztosítanak a felhőalapú tárolásra és szinkronizálásra, hitelesítésre, fizetésre, üzenetküldésre, kommunikációra és egyebekre, miközben védik a felhasználó adatait és az adataik biztonságát. Megjegyzés: Nem minden Apple-szolgáltatás és -tartalom érhető el az összes országban és régióban. Apple ID és felügyelt Apple ID Az Apple ID és a felügyelt Apple ID áttekintése Az Apple ID olyan szolgáltatás, amellyel bejelentkezhet az Apple-szolgáltatásokba, mint amilyen az icloud, imessage, FaceTime, az itunes Store, App Store, Apple TV alkalmazás, Book Store és sok más. Fontos, hogy a felhasználók biztonságban tartsák az Apple IDjukat, hogy megakadályozzák a fiókjuk jogosulatlan elérését. Ennek eléréséhez az Apple ID-khoz a következőknek megfelelő, erős jelszavak szükségesek: Legalább 8 karakter hosszúnak kell lenniük Betűket és számokat is tartalmazniuk kell Egymás után legfeljebb háromszor szerepelhet bennük ugyanaz a karakter Nem lehetnek általánosan használt jelszavak Célszerű túlteljesíteni ezeket az irányelveket, és további karakterekkel és írásjelekkel még erősebbé tenni a jelszavakat. Az Apple t és/vagy push-értesítést küld, amikor a felhasználók fiókjaiban fontos módosítások történnek például ha a jelszó vagy a számlázási adatok módosulnak, vagy az Apple ID-val új eszközön jelentkeznek be. Ha bármi gyanúsat észlel, célszerű azonnal megváltoztatni az Apple ID jelszavát. 79

80 Az Apple ezenkívül számos, a felhasználói fiókok védelmére tervezett irányelvet és eljárást alkalmaz. Ezek közé tartozik a bejelentkezési és jelszóváltoztatási próbálkozások számának korlátozása, a csalás aktív figyelése, amellyel bekövetkezésük pillanatában lehet azonosítani a támadásokat, valamint az irányelvek rendszeres frissítése; ez utóbbival az Apple képes alkalmazkodni a felhasználó biztonságát esetleg veszélyeztető új információkhoz. Megjegyzés: A felügyelt Apple ID-kra vonatkozó jelszóirányelvet az Apple School Manager vagy az Apple Business Manager rendszergazdája állítja be. Kétlépéses hitelesítés az Apple ID-val Annak érdekében, hogy a felhasználók még nagyobb biztonságban tudják a fiókjukat, az Apple kétlépéses hitelesítést kínál ez egy további biztonsági réteg az Apple ID-khoz. Ennek célja azt biztosítani, hogy csak a fiók tulajdonosa férhessen hozzá a fiókhoz, még akkor is, ha másik személy is ismeri a jelszót. A kétlépéses hitelesítés esetén a felhasználó fiókja csak a megbízható eszközökön érhető el, például a felhasználó iphone-ja, ipadje, ipod toucha vagy Mac gépe; más eszközökön a hozzáférés csak azután lehetséges, hogy elvégzett egy ellenőrzést a megbízható eszközök vagy egy megbízható telefonszám segítségével. Amikor az első alkalommal jelentkezik be egy új eszközön, két információ szükséges: az Apple ID jelszava és egy hat számjegyű ellenőrző kód, amely a felhasználó megbízható eszközén olvasható, vagy a megbízható telefonszámra érkezik. A kód megadásával a felhasználó megerősíti, hogy megbízik az új eszközben, és biztonságos rajta a bejelentkezés. Mivel önmagába a jelszó már nem elég a felhasználói fiók eléréséhez, a kétlépéses hitelesítés növeli a felhasználó Apple ID-jának és az Apple-nél tárol minden személyes információjának a biztonságát. A hitelesítés közvetlenül az ios, ipados, macos, tvos, watchos rendszerbe, valamint az Apple webhelyei által használt hitelesítési rendszerekbe integrálódik. Amikor a felhasználó Apple-webhelyre jelentkezik be webböngészővel, akkor a felhasználó icloud-fiókjához társított minden megbízható eszközre egy második lépéses kérelem érkezik, és ez a webes munkamenet jóváhagyását kéri. Olyan esetekben, amikor a felhasználó az Apple-webhelyre megbízható eszközön lévő böngészőből jelentkezik be, akkor a kód magán a használt eszközön jelenik meg. A kód megadása jóváhagyja a webes munkamenetet a felhasználó megbízható eszköze számára. Fiók helyreállítása A jelszó elfelejtése esetén az Apple ID-fiók helyreállítható. Ehhez egy megbízató eszközzel alaphelyzetbe kell állítani az Apple ID-jelszót. Ha nem érhető el egy megbízható eszköz sem, de a jelszó ismert, akkor egy megbízható telefonszám használható az SMSellenőrzéssel végrehajtott hitelesítéshez. Ezenfelül az SMS-ellenőrzéssel együtt egy előzőleg használt jelkód is használható az Apple ID azonnali alaphelyzetbe állításához. Ha ezek a lehetőségek nem érhetők el, akkor a fiók-helyreállítási eljárást kell követni. Lásd a következő Apple támogatási cikket: Az Apple ID visszaállítása, ha nem sikerül a jelszó alaphelyzetbe állítása. 80

81 Kétlépcsős ellenőrzés az Apple ID-val Az Apple 2013 óta biztosítja a kétlépcsős ellenőrzés nevű hasonló biztonsági módszert. Amikor a kétlépcsős ellenőrzés engedélyezve van, a felhasználó identitását ellenőrizni kell a felhasználó egyik megbízható eszközére küldött ideiglenes kóddal. Kétlépcsős ellenőrzés szükséges a felhasználó Apple ID-fiókinformációinak módosítása előtt; az icloudba, imessage-be, FaceTime-ba vagy Game Centerbe való bejelentkezés előtt; valamint az itunes Store-ban, az App Store-ban, az Apple TV alkalmazásban vagy az Apple Booksban új eszközzel végrehajtott vásárlás előtt. A felhasználók kapnak továbbá egy 14 karakteres visszaállítási kulcsot, amelyet biztonságos helyen kell őrizniük arra az esetre, ha elfelejtenék a jelszavukat, vagy elveszítenék a megbízható eszközeiket. A legtöbb új felhasználónak célszerű a kétlépcsős hitelesítést használnia, vannak azonban helyzetek, amikor mégis a kétlépcsős ellenőrzés a javasolt. Felügyelt Apple ID-k A felügyelt Apple ID hasonlóan működik, mint az Apple ID, viszont vállalati vagy oktatási intézmény birtokolja és szabályozza. A szervezetek visszaállíthatják a jelszavakat, korlátozhatják a vásárlásokat és a kommunikációt (például a FaceTime és az Üzenetek használatát), és szerepalapú jogosultságokat állíthatnak be az alkalmazottak, munkatársak, tanárok és tanulók számára. Felügyelt Apple ID-k esetén bizonyos szolgáltatások le vannak tiltva (például az Apple Pay, az icloud-kulcskarika, a HomeKit és a Lokátor). Felügyelt Apple ID-k vizsgálata A felügyelt Apple ID-k a vizsgálatot is támogatják; ennek segítségével a szervezetek megfelelhetnek a jogi és adatvédelmi szabályozásoknak. Az Apple School Managerrendszergazda, -menedzser vagy -tanár megvizsgálhat adott Felügyelt Apple ID-fiókokat. A vizsgálók csak a szervezet hierarchiájában alattuk lévő fiókokat figyelhetik. A tanárok például figyelhetik a tanulókat, a menedzserek vizsgálhatják a tanárokat és a tanulókat, a rendszergazdák pedig vizsgálhatják a menedzsereket, a tanárokat és a tanulókat. Amikor vizsgálói hitelesítő adatokra van szükség az Apple School Manager használatával, akkor speciális fiók jön létre, amely csak azokhoz a felügyelt Apple ID-khoz fér hozzá, amelyekre a vizsgálati kérelem érvényes. A vizsgáló olvashatja és módosíthatja a felhasználó icloudban vagy a CloudKitet használó alkalmazásokban tárolt tartalmait. Az összes auditálási célú hozzáférés naplózva van az Apple School Managerben. A napló tartalmazza a vizsgáló személyét, azt a felügyelt Apple ID-t, amelyhez a vizsgáló hozzáférést kért, a kérelem időpontját, és azt a tényt, hogy a vizsgálat megtörtént-e. Felügyelt Apple ID-k és személyes eszközök A felügyelt Apple ID-k saját tulajdonú ios- és ipados-eszközökkel és Mac gépekkel is használhatók. A tanulók az icloudba az intézmény által kibocsátott felügyelt Apple ID-val és egy további otthoni jelszóval jelentkeznek be, amely az Apple ID kétlépéses hitelesítési folyamatának második faktoraként szolgál. Amikor felügyelt Apple ID-t használ a személyes eszközön, az icloud-kulcskarika nem érhető el, és az intézmény korlátozhat más funkciókat is, mint például a FaceTime vagy az Üzenetek. Minden olyan icloud-dokumentum, amelyet a tanulók bejelentkezve hoznak létre, az ebben a szakaszban korábban leírt audit hatálya alá esik. 81

82 icloud Az icloud áttekintése Az icloud tárolja a felhasználó kontaktjait, naptárait, fotóit, dokumentumait és más elemeit, és ezeket automatikusan naprakészen tartja az összes eszközön. Az icloudot külső alkalmazások is használhatják dokumentumok és a fejlesztő által meghatározott fő alkalmazásadatok tárolására és szinkronizálására. A felhasználók az icloudot egy Apple ID-val való bejelentkezéssel és a használni kívánt szolgáltatások kiválasztásával állítják be. Bizonyos icloud-funkciókat, az icloud Drive-ot és az icloud biztonsági mentést letilthatják az IT-rendszergazdák a mobileszköz-felügyeletet (MDM) konfigurációs profiljaival. A szolgáltatás független a tárolt tartalomtól, és minden fájltartalmat azonos módon, bájtok gyűjteményeként tárol. Az icloud darabokra bont minden fájlt, és AES-128 titkosítással, valamint az egyes darabok tartalmából származtatott SHA-256 algoritmusú kulccsal titkosít minden fájlt. A kulcsok és a fájl metaadatait az Apple a felhasználó icloud-fiókjában tárolja. A fájl titkosított darabjait (a felhasználót azonosító információk és a kulcsok nélkül) az Apple mind a saját, mind külső tároló szolgáltatásokban tárolja például az Amazon Web Servicesben vagy a Google Cloud Platformban, de ezek a partnerek nem rendelkeznek a szervereiken tárolt felhasználói adatok visszafejtéséhez szükséges kulccsal. icloud Drive Az icloud Drive fiókalapú kulcsokat ad hozzá az icloudban tárolt dokumentumok védelméhez. Az icloud Drive feldarabolja és titkosítja a fájltartalmakat, és a titkosított darabokat harmadik fél szolgáltatásaival tárolja. A fájltartalomkulcsok azonban az icloud Drive metaadataival együtt tárolt rekordkulcsokba vannak csomagolva. Ezeket a rekordkulcsokat viszont a felhasználó icloud Drive-szolgáltatáskulcsa védi, amely a felhasználó icloud-fiókjával együtt tárolódik. A felhasználók az icloud-dokumentumok metaadataihoz az icloudban végzett hitelesítés után férnek hozzá, azonban az icloud Drive-tárhely védett részeit csak az icloud Drive szolgáltatáskulcsával fedhetik fel. icloud Drive biztonsági mentés Az icloud Wi-Fi használatával naponta készít biztonsági mentést az információkról beleértve az eszközbeállításokat, alkalmazásadatokat, a Filmtekercsen lévő fotókat és videókat és az Üzenetek alkalmazás beszélgetéseit. Az icloud a tartalmat titkosítással biztosítja, amikor elküldi az interneten, titkosított formában tárolja, és biztonságos tokeneket használ a hitelesítéshez. Az icloud biztonsági mentés csak akkor zajlik, amikor az eszköz zárolva van, hálózati áramforráshoz csatlakozik, és Wi-Fi segítségével kapcsolódik az internetre. Az ios és ipados rendszerben használt titkosítás miatt az icloud biztonsági mentés úgy működik, hogy megőrizze az adatok biztonságát, és lehetővé tegye a fokozatos, nem felügyelt biztonsági mentést és visszaállítást. Ha a fájlok olyan Data Protection-osztályban jönnek létre, amely nem érhető el az eszköz zárolt állapotában, akkor a fájlalapú kulcsok az icloud biztonsági mentés kulcstartójáról származó osztálykulcsok használatával lesznek titkosítva, és biztonsági mentés készül róluk az icloudba az eredeti, titkosított állapotban. Az átvitel során minden fájl titkosítva van, tárolás során pedig fiókalapú kulcsokkal vannak titkosítva, a CloudKit részben leírtak szerint. 82

83 Az icloud biztonsági mentés kulcstartója aszimmetrikus (Curve25519) kulcsokat tartalmaz a Data Protection-osztályokhoz, amelyek nem érhetők el, amikor az eszköz zárolva van. A biztonsági mentés készlete a felhasználó icloud-fiókjában található, és a felhasználó fájljait és az icloud biztonsági mentés kulcstartóját tartalmazza. Az icloud biztonsági mentés kulcstartóját véletlenszerű kulcs védi, amely szintén a biztonsági mentés készletében tárolódik. (A rendszer nem használja a felhasználó icloud-jelszavát a titkosításhoz, így az icloud-jelszó módosítása nem érvényteleníti a meglévő biztonsági mentéseket.) Amíg a felhasználó Kulcskarika-adatbázisáról az icloudba készül biztonsági mentés, addig UID-val összecsomózott kulcs védi. Ennek köszönhetően a Kulcskarika csak arra az eszközre állítható vissza, amelyről származik, és senki más, még az Apple sem képes elolvasni a felhasználó Kulcskarikáján lévő elemeket. Visszaállítás során a biztonsági mentésben szereplő fájlok, az icloud biztonsági mentés kulcstartója és a kulcstartó kulcsa a felhasználó icloud-fiókjából van beolvasva. Az icloud biztonsági mentés kulcstartójának visszafejtése saját kulcsával történik; ezután a kulcstartóban lévő fájlalapú kulcsokkal a rendszer visszafejti a biztonsági mentésben lévő fájlokat, és ezeket új fájlként a fájlrendszerbe írja, amivel a megfelelő Data Protectionosztállyal ismét titkosítja őket. Az icloud biztonsági mentés tartalma A következő tartalom kerül be az icloud biztonsági mentésbe: A megvásárolt zenék, filmek, tv-műsorok, alkalmazások és könyvek rekordjai. A felhasználó icloud biztonsági mentésében szerepelnek a felhasználó eszközén jelen lévő megvásárolt tartalmakkal kapcsolatos információk, de maga a megvásárolt tartalom nem. Amikor a felhasználó visszaállítja az adatokat az icloud biztonsági mentésből, a megvásárolt tartalom automatikusan letöltődik az itunes Store-ból, App Storeból, Apple TV alkalmazásból vagy az Apple Booksból. Bizonyos típusú tartalom nem töltődik le automatikusan minden országban vagy régióban, és a korábbi vásárlások elérhetetlenek lehetnek, ha visszatérítést kapott utánuk, vagy többé már nem érhetők el az áruházban. A teljes vásárlástörténet a felhasználó Apple ID-jához van társítva. A felhasználó eszközein lévő fotók és videók. Tartsa szem előtt, hogy ha a felhasználó bekapcsolja az icloud-fotókat ios 8.1, ipados 13.1 vagy OS X (vagy újabb) rendszer esetén, akkor a fotók és videók már az icloudban vannak, így nem fognak szerepelni a felhasználó icloud biztonsági mentésében: ios 8.1 és újabb ipados 13.1 OS X és újabb Kontaktok, naptáresemények, emlékeztetők és jegyzetek Eszközbeállítások Alkalmazásadatok A Főképernyő és az alkalmazások elrendezése HomeKit-konfiguráció Orvosiazonosító-adatok A vizuális Hangposta jelszava (a biztonsági mentés során használt SIM-kártya szükséges hozzá) 83

84 imessage, Csevegés vállalkozásokkal, szöveges (SMS) és MMS-üzenetek (a biztonsági mentés során használt SIM-kártya szükséges hozzá) Ha az Üzenetek az icloudban funkció be van kapcsolva, az imessage, a Csevegés vállalkozásokkal, valamint szöveges (SMS) és MMS-üzenetek el vannak távolítva a felhasználó meglévő icloud biztonsági mentéséből, és helyette az Üzenetek végponttól végpontig titkosított CloudKit-tárolójában vannak. A felhasználó icloud biztonsági mentése tárolja a tároló kulcsát. Ha a felhasználó ezt követőn kikapcsolja az icloud biztonsági mentést, akkor a tároló kulcsa elvész, az új kulcs pedig csak az icloud-kulcskarikán lesz megtalálható (ez nem érhető el sem az Apple, sem külső felek számára), és a tárolóba írt új adatokat nem lehet a korábbi tárolókulccsal visszafejteni. A rendszer az icloud biztonsági mentésben szereplő üzenetek visszaállításához használt kulcsot két helyen helyezi el: az icloud-kulcskarikán, illetve egy biztonsági mentést a CloudKitben. A CloudKitben található biztonsági mentés akkor készül el, ha az icloud biztonsági mentés be van kapcsolva, és feltétel nélkül visszaáll, függetlenül attól, hogy a felhasználó visszaállítja-e az icloud biztonsági mentést vagy sem. CloudKit végponttól végpontig történő titkosítás Az icloud biztonság áttekintése című Apple támogatási cikkben felsorolt számos Appleszolgáltatás végponttól végpontig történő titkosítást alkalmaz, amelyben a CloudKitszolgáltatáskulcsot az icloud-kulcskarika szinkronizálása védi. Ezen CloudKit-tárolók számára a kulcshierarchia gyökere az icloud-kulcskarikában van, és ezért az icloudkulcskarika biztonsági jellemzőit használja vagyis a kulcsok csak a felhasználó megbízható eszközein érhetők el, az Apple és külső felek számára nem. Ha elvész a hozzáférés az icloud-kulcskarikához, a CloudKitben lévő adatok alaphelyzetbe állnak. Ha pedig az adatok elérhetők megbízható helyi eszközről, akkor újra feltöltődnek a CloudKitbe. További információk: Az icloud-kulcskarika zálogbiztonsága. Az Üzenetek az icloudban is CloudKit végponttól végpontig történő titkosítást alkalmaz az icloud-kulcskarika szinkronizálásával védett CloudKit-szolgáltatáskulccsal. Ha a felhasználó engedélyezte az icloud biztonsági mentést, az Üzenetek az icloudban tárolójának CloudKit-szolgáltatáskulcsáról biztonsági mentés készül az icloudba, hogy a felhasználó visszaállíthassa az üzeneteit, még akkor is, ha elveszti a hozzáférést az icloudkulcskarikához és a megbízható eszközeihez. Az icloud-szolgáltatáskulcs lecserélődik, amikor a felhasználó kikapcsolja az icloud biztonsági mentést. Helyzet Hozzáférés megbízható eszközhöz Nincs megbízható eszköz Az icloud biztonsági mentés be van kapcsolva, és a felhasználó hozzáfér a megbízható eszközhöz Az icloud biztonsági mentés be van kapcsolva, és a felhasználó nem fér hozzá megbízható eszközhöz Az icloud biztonsági mentés ki van kapcsolva, és a felhasználó hozzáfér a megbízható eszközhöz A felhasználó visszaállítási lehetőségei CloudKit végponttól végpontig történő titkosítás esetén Az adat-visszaállítás megbízható eszközzel vagy az icloud-kulcskarikával lehetséges. Az adat-visszaállítás csak az icloud-kulcskarikával történő visszaállítással lehetséges. Az adat-visszaállítás az icloud biztonsági mentéssel, megbízható eszközzel vagy az icloud-kulcskarikával lehetséges. Az adat-visszaállítás az icloud biztonsági mentéssel vagy az icloud-kulcskarikával lehetséges. Az adat-visszaállítás megbízható eszközzel vagy az icloud-kulcskarikával lehetséges. 84

85 Helyzet A biztonsági mentés ki van kapcsolva, és a felhasználó nem fér hozzá megbízható eszközhöz A felhasználó visszaállítási lehetőségei CloudKit végponttól végpontig történő titkosítás esetén Az adat-visszaállítás csak az icloud-kulcskarikával történő visszaállítással lehetséges. Jelkód- és jelszókezelés A jelkód- és jelszókezelés áttekintése Az ios, az ipados és a macos számos funkcióval könnyíti meg a felhasználóknak, hogy biztonságosan és kényelmesen hitelesíthessék magukat olyan külső alkalmazásokban és webhelyeken, amelyek jelszóval végzik a hitelesítést. A legkönnyebben úgy kezelhetők a jelszavak, ha nem is kell használni őket. A Bejelentkezés az Apple-lel funkcióval úgy jelentkezhet be külső alkalmazásokba és webhelyekre, hogy nem kell további fiókot vagy jelszót létrehoznia és kezelnie, és közben védelmet biztosít az Apple ID kétlépéses hitelesítésével a bejelentkezéshez. A Bejelentkezés az Apple-lel funkciót nem támogató webhelyek esetén az Automatikus erős jelszó segítségével a felhasználó eszköze képes automatikusan létrehozni, szinkronizálni és megadni egyedi erős jelszavakat a webhelyekhez és alkalmazásokhoz. ios és ipados esetén a jelszavak egy speciális, a felhasználó által szabályozott és kezelhető, Jelszavak automatikus kitöltése kulcskarikára kerülnek, ha a Beállítások > Jelszavak és fiókok > Webhely- és alkalmazásjelszavak menüpontba lép. macos esetén a mentett jelszavak a Safari Jelszavak beállításaiban kezelhetők. Ez a szinkronizálási rendszer a felhasználó által manuálisan létrehozott jelszavak szinkronizálásához is használható. Bejelentkezés az Apple-lel A Bejelentkezés az Apple-lel funkció az adatvédelmet szolgáló alternatíva más egyszeri bejelentkezéses rendszerekhez. Az egy koppintással történő bejelentkezés kényelmét és hatékonyságát kínálja, miközben több átláthatóságot és irányítást ad a felhasználónak a saját személyes adatai felett. A Bejelentkezés az Apple-lel segítségével a felhasználó beállít egy fiókot, majd a meglévő Apple ID használatával jelentkezik be az alkalmazásokba és webhelyekre, ezáltal több irányítása marad a személyes adatai felett. Az alkalmazások csak a felhasználónevet és az -címet kérhetik fiók beállításakor, és a felhasználónak mindig van választása: Megoszthatja a személyes -címét az alkalmazással, vagy megtarthatja azt privátnak, és helyette használhatja az Apple új, privát -továbbítási szolgáltatását. Az -továbbítási szolgáltatás egy egyedi, anonimizált -címet oszt meg, amely a felhasználó személyes címére továbbítja a leveleket, így továbbra is értesülhet a fejlesztőtől származó hasznos információkról, viszont megtarthat egy bizonyos fokú privát szférát és a személyes adatai feletti irányítást. 85

86 A Bejelentkezés az Apple-lel a biztonság jegyében készült. A Bejelentkezés az Apple-lel minden felhasználójának kötelező bekapcsolni a kétlépéses hitelesítést. A kétlépéses hitelesítéssel nemcsak a felhasználó Apple ID-ja maradhat biztonságban, hanem az alkalmazásokkal létrehozott fiókok is. Az Apple ezenkívül kifejlesztett és integrált egy adatvédelmet támogató, csalásellenes jelet a Bejelentkezés az Apple-lel funkcióba, amely segítségével a fejlesztők megbizonyosodhatnak afelől, hogy az új felhasználók valódi személyek, nem pedig botok vagy szkript által létrehozott fiókok. Automatikus erős jelszó Ha az icloud-kulcskarika be van kapcsolva, az ios, az ipados és a macos erős, véletlenszerű, egyedi jelszavakat hoz létre, amikor a felhasználó jelszót hoz létre vagy módosít a Safariban egy webhelyen. ios és ipados esetén az automatikus erős jelszavak alkalmazások esetén is elérhetők. A felhasználó csak akkor nem használ erős jelszavakat, ha kikapcsolja a funkciót. A generált jelszavak a kulcskarikára kerülnek, és ha az icloudkulcskarika be van kapcsolva, akkor szinkronizálódnak az eszközökre. Alapértelmezés szerint az ios és ipados által generált jelszavak 20 karakter hosszúak. Tartalmaznak egy számjegyet, egy nagybetűt, két kötőjelet és 16 kisbetűt. Ezek a generált jelszavak erősek, 71 bites entrópiával rendelkeznek. A generált jelszavak olyan heurisztikán alapulnak, amely meghatározza, hogy egy adott beviteli mező jelszó létrehozására szolgál. Ha a heurisztikának nem sikerül felismernie a jelszókontextust a jelszó létrehozásához, az alkalmazásfejlesztők beállíthatják a UITextContentType.newPassword értéket a szövegmezőn, és a webfejlesztők beállíthatják az autocomplete="new-password" értéket az <input> elemhez. Az alkalmazások és a webhelyek szabályok segítségével gondoskodhatnak arról, hogy a generált jelszavak kompatibilisek a vonatkozó szolgáltatásokkal. A fejlesztők a UITextInputPasswordRules vagy a passwordrules attribútum használatával adják meg ezeket a szabályokat az <input> elemeknél. Az eszközök ezután a szabályoknak megfelelő legerősebb jelszót generálják. Jelszó automatikus kitöltése A jelszó automatikus kitöltése automatikusan beírja a kulcskarikán tárolt hitelesítő adatokat. Az icloud-kulcskarika-kezelő és a Jelszó automatikus kitöltése funkció a következőket kínálja: Hitelesítő adatok kitöltése alkalmazásokban és webhelyeken Erős jelszavak generálása Jelszavak mentése alkalmazásokban és a Safariban megnyitott webhelyeken A jelszavak biztonságos megosztása a felhasználó kontaktjaival Jelszó megadása a közelben lévő, hitelesítő adatokat kérelmező Apple TV-nek A jelszavak generálása és mentése alkalmazásokon belül, valamint a jelszavak megadása az Apple TV-nek csak ios és ipados rendszeren érhető el. 86

87 A jelszó automatikus kitöltése alkalmazásokban Az ios és az ipados megadhatják a mentett felhasználóneveket és jelszavakat az alkalmazások hitelesítő adatokhoz kapcsolódó mezőiben, hasonlóan ahhoz, ahogy a jelszó automatikus kitöltése működik a Safariban. ios és ipados esetén a felhasználó a funkció használatához a kulcs lehetőségre koppint a szoftver billentyűzetének QuickType során. macos esetén a Mac Catalyst segítségével összeállított alkalmazások esetén a Jelszavak legördülő menü jelenik meg a hitelesítő adatokhoz kapcsolódó mezőkben. Ha az alkalmazás szorosan ahhoz a webhelyhez van társítva, amely ugyanazt az appleapp-site-association fájl által támogatott, alkalmazás-webhely társítási mechanizmust használja, akkor az ios és az ipados QuickType sora és a macos legördülő menüje közvetlenül javasolja az alkalmazásban megadandó hitelesítő adatokat, ha bármelyik mentve van a Jelszó automatikus kitöltése kulcskarikára. Ennek segítségével a felhasználók azonos biztonsági tulajdonságokkal fedhetik fel a Safariban mentett hitelesítő adatokat az alkalmazások számára, viszont az alkalmazásoknak nem kell API-t adaptálniuk. A Jelszó automatikus kitöltése nem fed fel hitelesítő adatokat az alkalmazásoknak mindaddig, amíg a felhasználó bele nem egyezik a hitelesítő adat alkalmazásnak való felfedésébe. A hitelesítő adatok listájának beolvasása az alkalmazás folyamatától külön történik. Ha az alkalmazás és a webhely kapcsolata megbízható, és a felhasználó hitelesítő adatokat küld el egy alkalmazáson belül, az ios és az ipados felkínálhatja a felhasználónak a hitelesítő adatok mentését a Jelszó automatikus kitöltése kulcskarikára a jövőbeli használathoz. Alkalmazások hozzáférése a mentett jelkódokhoz Az ios- és ipados-alkalmazások a következő két API segítségével kommunikálhatnak a Jelszó automatikus kitöltése kulcskarikával: SecRequestSharedWebCredential SecAddSharedWebCredential Az ios-, ipados- és macos-alkalmazások kérhetik a Jelszó automatikus kitöltése kulcskarika segítségét, hogy az ASAuthorizationPasswordProvider használatával bejelentkeztessék a felhasználót. A jelszószolgáltató és annak kérelme használható a Bejelentkezés az Apple-lel funkcióval együtt, így ugyanaz az API-hívás segíti a felhasználókat bejelentkezni egy alkalmazásba, attól független, hogy a felhasználó fiókja jelszóalapú, vagy a Bejelentkezés az Apple-lel funkcióval jött-e létre. Az alkalmazások csak akkor férnek hozzá a mentett jelszavakhoz, ha az alkalmazásfejlesztő és a webhelyadminisztrátor jóváhagyták, és a felhasználó is beleegyezett. Az alkalmazásfejlesztők úgy fejezik ki a Safari által mentett jelszavak elérésére vonatkozó céljukat, hogy jogosultságot építenek be az alkalmazásba. Ez a jogosultság felsorolja a társított webhelyek teljesen minősített doménneveit, és a webhelyeknek egy fájlt kell elhelyezniük a szervereiken, amely felsorolja az Apple által jóváhagyott alkalmazások egyedi alkalmazásazonosítóit. Amikor a com.apple.developer.associated-domains jogosultsággal rendelkező alkalmazás települ, az ios és az ipados TLS-kérelmet indít minden egyes felsorolt webhelyhez, és a következő fájlok egyikét kéri: apple-app-site-association 87

88 .well-known/apple-app-site-association Ha a fájl felsorolja a telepített alkalmazás alkalmazásazonosítóját, akkor az ios és az ipados megbízható kapcsolattal rendelkezőként jelöli meg a webhelyet és az alkalmazást. A két API-hoz irányuló hívások közül csak a megbízható kapcsolattal rendelkezők adnak felkérést a felhasználónak, akinek beleegyezését kell adnia, mielőtt a folyamat bármely jelszót felfed az alkalmazásnak, frissít vagy töröl. Jelszavak ismételt használata és erősségének auditja A Jelszó automatikus kitöltése kulcskarika ios, ipados és macos rendszeren elérhető jelszólistája jelzi, hogy a felhasználó mely mentett jelszavai vannak más webhelyeken is használatban, illetve hogy mely jelszavak gyengék. Ha több szolgáltatáshoz is ugyanazt a jelszót használja, akkor az adott fiókokat sebezhetővé teszi az ún. credential stuffing támadás ellen. Ha egy szolgáltatást feltörnek, és a jelszavak kiszivárognak, a támadók megpróbálhatják felhasználni ugyanazokat a hitelesítő adatokat más szolgáltatásokban is, hogy további fiókokhoz férjenek hozzá. A jelszavak akkor tekinthetők gyengének, ha a támadó könnyen kitalálhatja őket. Az ios, ipados és macos észleli a könnyen megjegyezhető jelszó létrehozásához használt általános mintákat, például szótárban található szó használata, elterjedt karakterhelyettesítések (például j3lsz0 használata a jelszó helyett), a billentyűzeten található mintázatok (például q12we34r a QWERTZ billentyűzet esetén), vagy ismétlődő sorozatok (például ). Ezeket a mintákat gyakran használják a szolgáltatások minimális követelményeinek megfelelő jelszavak létrehozásához, de a nyers erőt használó támadók is gyakran alkalmazzák ezeket. Mivel sok szolgáltatáshoz kifejezetten négy vagy hat számjegyű PIN-kód szükséges, az ilyen rövid jelkódok kiértékelése más szabályokkal történik. A PIN-kódok akkor tekinthetők gyengének, ha a legelterjedtebb PIN-kódok közé tartoznak, ha növekvő vagy csökkenő sorozatot alkotnak, például 1234 vagy 8765, vagy ha ismétlődő mintát követnek, például vagy A jelszavak listájában a gyenge és többször használt jelszavak meg vannak jelölve. Ha a felhasználó a Safariban nagyon gyenge mentett jelszóval jelentkezik be egy webhelyre, például a leggyakrabban használt jelszavak valamelyikével, akkor figyelmeztetés javasolja, hogy frissítsen automatikus erős jelszóra. Jelszavak küldése más felhasználóknak vagy eszközöknek AirDrop Ha az icloud be van kapcsolva, a felhasználók az AirDrop segítségével másik eszközre küldhetnek át mentett hitelesítő adatokat beleértve a webhely címét, a felhasználónevet és a jelszót. A hitelesítő adatok AirDroppal végzett küldése mindig a Csak kontaktok módban történik, függetlenül a felhasználó beállításaitól. A fogadó eszközön a felhasználó jóváhagyása után a hitelesítő adatok a felhasználó Jelszó automatikus kitöltése kulcskarikájára kerülnek. 88

89 Apple TV A Jelszó automatikus kitöltése funkcióval kitölthetők a hitelesítő adatok az Apple TV készüléken. Amikor a felhasználó felhasználónév vagy jelszó mezőre fókuszál a tvos rendszeren, az Apple TV kérést hirdet meg a Jelszó automatikus kitöltése funkció igénybevételéhez Bluetooth Low Energy (BLE) használatával. A közelben lévő bármely iphone, ipad vagy ipod touch kérést jelenít meg arra vonatkozólag, hogy a felhasználó ossza meg a hitelesítő adatokat az Apple TV-vel. A titkosítási módszer a következőképpen alakul ki: Ha az eszköz és az Apple TV ugyanazt az icloud-fiókot használja, az eszközök közötti titkosítás automatikus. Ha az eszköz az Apple TV által használttól eltérő icloud-fiókba van bejelentkezve, a felhasználó kérést kap, hogy PIN-kód használatával alakítson ki titkosított kapcsolatot. Az adatkérés fogadásához az iphone-nak az Apple TV-hez párosított Siri Remote távirányító közelében és feloldott állapotban kell lennie, hogy a kérés megjelenjen. Miután létrejött a titkosított kapcsolat BLE-csatolású titkosítás használatával, az Apple TV megkapja a hitelesítő adatokat, és azok automatikusan bekerülnek az alkalmazás megfelelő szövegmezőibe. Hitelesítő adatok szolgáltatóinak bővítménye ios és ipados rendszeren a felhasználók hitelesítő adatok szolgáltatójaként jelölhetnek ki egy megfelelő külső alkalmazást, amely így a Jelszavak és fiókok beállításaiban az Automatikus kitöltés részben fog szerepelni. Ez a mechanizmus bővítményekre épül. A hitelesítő adatok szolgáltatójának bővítménye számára előírás, hogy nézetet biztosítson a hitelesítő adatokhoz, és opcionálisan ellássa metaadatokkal az ios és ipados rendszert a mentett hitelesítő adatokra vonatkozóan, így azok közvetlenül a QuickType soron felkínálhatók. A metaadatok közé tartozik a hitelesítő adatok webhelye és a társított felhasználónév, a jelszó viszont nem. Az ios és az ipados kapcsolatba lép a bővítménnyel a jelszó beszerzése érdekében, amikor a felhasználó be szeretné azt írni egy alkalmazásba vagy a Safariban megnyitott webhelyre. A hitelesítő adatok metaadatai a bővítményszolgáltató homokozójában vannak, és az alkalmazás eltávolításakor automatikusan törlődnek. icloud-kulcskarika Az icloud-kulcskarika áttekintése Az icloud-kulcskarika segítségével a felhasználók biztonságosan szinkronizálhatják a jelszavaikat az ios- és ipados-eszközök, valamint a Mac gépek között anélkül, hogy felfednék ezeket az információkat az Apple számára. Az erős adatvédelem és biztonság mellet az icloud-kulcskarika kialakítását és architektúráját nagyban befolyásolta a könnyű használhatóság és a kulcskarikák visszaállíthatóságának célja. Az icloud-kulcskarika két szolgáltatásból áll: kulcskarika-szinkronizálás és kulcskarika-visszaállítás. Az Apple úgy tervezte az icloud-kulcskarikát és a kulcskarika-visszaállítást, hogy a felhasználó jelszavai még a következő körülmények között is védve legyenek: A felhasználó icloud-fiókja sérült. Az icloud külső támadó vagy alkalmazott által sérült. 89

90 Külső fél hozzáfér a felhasználói fiókokhoz. Kulcskarika-szinkronizálás Amikor a felhasználó először kapcsolja be az icloud-kulcskarikát, az eszköz megbízhatósági kört alakít ki, és szinkronizálási identitást hoz létre saját maga számára. A szinkronizálási identitás egy privát és egy nyilvános kulcsból áll. A szinkronizálási identitás nyilvános kulcsa a körbe kerül, a kör pedig kettős aláírást kap: először a szinkronizálási identitás privát kulcsától, azután pedig egy aszimmetrikus görbe típusú kulcstól (P-256 használatával), amely a felhasználó icloud-fiókjának jelszavából származik. A körrel együtt tárolódnak azok a paraméterek (véletlenszerű só és iterációk), amelyek a felhasználó icloud-jelszaván alapuló kulcs létrehozásához használatosak. Az aláírt szinkronizálási kör a felhasználói icloud kulcs-érték tárterületére kerül. Csak a felhasználó icloud-jelszavának ismeretében olvasható, és csak akkor módosítható érvényesen, ha rendelkezik a tagjának szinkronizálási identitásához tartozó privát kulccsal. Amikor a felhasználó bekapcsolja az icloud-kulcskarikát egy másik eszközön, az icloudkulcskarika érzékeli, hogy a felhasználó már korábban kialakított egy olyan szinkronizálási kört az icloudban, amelynek nem tagja. Az eszköz létrehozza a szinkronizálási identitásának kulcspárját, majd alkalmazásjegyet készít, amellyel kérelmezi a tagságát a körben. A jegy az eszköz szinkronizálási identitásának nyilvános kulcsából áll, és a felhasználónak hitelesítenie kell magát az icloud-jelszavával. Az elliptikus kulcs generálásának paraméterei az icloudból származnak, az alkalmazásjegy pedig a generált kulccsal van aláírva. Az alkalmazásjegy végül az icloudba kerül. Az első alkalmazás, amely észleli, hogy alkalmazásjegy érkezett, megkéri a felhasználót, hogy fogadja el az új eszköz csatlakozását a szinkronizálási körhöz. A felhasználó megadja az icloud-jelszavát, és így az alkalmazásjegyet az egyező privát kulcs általi aláírással érvényesíti. Ekkor a körhöz való csatlakozás kérelmét generáló felhasználó csatlakozhat. Amikor a felhasználó jóváhagyja, hogy az új eszköz csatlakozzon a körhöz, az első eszköz hozzáadja az új tag nyilvános kulcsát a szinkronizálási körhöz, és ismét aláírja mind a szinkronizálási identitásával, mind a felhasználó icloud-jelszavából származtatott kulccsal. Az új szinkronizálási kör az icloudba kerül, ahol a kör új tagja hasonlóképpen aláírja. Az aláírási körnek most már két tagja van, és mindegyik tag rendelkezik a társának nyilvános kulcsával. Ekkor a helyzetnek leginkább megfelelő módon elkezdik az egyes Kulcskarika-elemek egyeztetését az icloud kulcs-érték tárhelyén keresztül, vagy eltárolják őket a CloudKitben. Ha a kör mindkét tagja rendelkezik ugyanazzal az elemmel, akkor a legújabb módosítási dátumú szinkronizálódik. A folyamat kihagyja azokat az elemeket, ahol mindkét tag rendelkezik az elemmel, és a módosítás dátuma azonos. Minden szinkronizált elem titkosítva van, így csak a felhasználó megbízhatósági körébe tartozó eszközök képesek visszafejteni; sem más eszköz, sem az Apple nem tudja visszafejteni azokat. A folyamat megismétlődik, amikor új eszközök csatlakoznak a szinkronizálási körhöz. Amikor például egy harmadik eszköz csatlakozik, a megerősítés a felhasználó mindkét másik eszközén megjelenik. A felhasználó az új tagot bármelyik eszközéről jóváhagyhatja. Az új társak hozzáadásával mindegyik társ szinkronizálódik az újjal, hogy az összes tag azonos Kulcskarika-elemekkel rendelkezzen. 90

91 A teljes Kulcskarika azonban nincs szinkronizálva. Bizonyos elemek eszközspecifikusak, például a VPN-identitások, és ezek nem hagyhatják el az eszközt. Csak a ksecattrsynchronizable attribútummal rendelkező elemek szinkronizálódnak. Az Apple ezt az attribútumot a Safari-felhasználóadatokhoz (beleértve a felhasználóneveket, jelszavakat és hitelkártyaszámokat), valamint a Wi-Fi-jelszavakhoz és HomeKit titkosítási kulcsokhoz állítja be. Alapértelmezés szerint nem szinkronizálódnak továbbá a külső alkalmazások által hozzáadott Kulcskarika-elemek. A fejlesztőknek be kell állítaniuk a ksecattrsynchronizable attribútumot, amikor elemeket adnak a Kulcskarikához. Az icloud-kulcskarika visszaállítása A Kulcskarika-visszaállítás segítségével a felhasználók opcionálisan az Apple-nél zálogba helyezhetik a kulcskarikájukat; az Apple nem képes elolvasni a rajta tárolt jelszavakat és más adatokat. A Kulcskarika-visszaállítás még akkor is biztonsági hálót kínál az adatvesztés ellen, ha a felhasználó csak egy eszközzel rendelkezik. Ez különösen akkor fontos, ha a felhasználó a Safarival generál véletlenszerű, erős jelszavakat a webes fiókokhoz, mivel azok a jelszavak csupán a Kulcskarikán léteznek. A Kulcskarika-visszaállítás sarokköve a másodlagos hitelesítés és biztonságos zálogszolgáltatás, amelyet az Apple kifejezetten ennek a funkciónak a támogatására hozott létre. A felhasználó kulcskarikája erős jelszóval van titkosítva, és a zálogszolgáltatás csak akkor adja ki a kulcskarika másolatát, ha a szigorú feltételek teljesülnek. Erős jelkód többféleképpen is kialakítható: Ha a felhasználói fiókhoz engedélyezve van a kétlépéses hitelesítés, az eszköz jelkódjával lehet visszaállítani a zálogba helyezett kulcskarikát. Ha a kétlépéses hitelesítés nincs beállítva, a felhasználónak icloud biztonsági kódot kell létrehoznia egy hat számjegyű jelkód megadásával. Alternatív megoldásként, a kétlépéses hitelesítés nélkül a felhasználó megadhatja a saját hosszabb kódját, illetve az eszköz is létrehozhat kriptográfiailag véletlenszerű kódot, amelyet a felhasználó feljegyezhet. Sok felhasználó szereti ezen a ponton zálogba helyezni a kulcstartóját az Applenél. A folyamat során az ios-, ipados vagy macos-eszköz exportálja a felhasználó kulcskarikájának másolatát, aszimmetrikus kulcstartóban lévő kulcsokba csomagolva titkosítja, és elhelyezi a felhasználó icloudjának kulcsértéktároló területén. A kulcstartót becsomagolja a felhasználó icloud biztonsági kódja és a zálogrekordot tároló hardverbiztonsági modul (HSM) klaszterének nyilvános kulcsa. Ez lesz a felhasználó icloud-zálogrekordja. Ha a felhasználó elfogadja a kriptográfiailag véletlenszerű biztonsági kódot, és nem a sajátját adja meg, illetve nem négy számjegyű értéket használ, akkor nincs szükség zálogrekordra. Ehelyett közvetlenül az icloud biztonsági kódjába csomagolódik a véletlenszerű kulcs. A biztonsági kód kialakításán túl a felhasználóknak telefonszámot is regisztrálniuk kell. Ez egy másodlagos hitelesítési réteget kínál a kulcskarika-visszaállítás során. A felhasználó kap egy SMS-t, amelyre válaszolnia kell, hogy továbbléphessen a visszaállítással. 91

92 Az icloud-kulcskarika zálogbiztonsága Az icloud biztonságos infrastruktúrát kínál a kulcskarika záloghoz, így gondoskodik arról, hogy csak a jogosultsággal rendelkező felhasználók és eszközök hajthassák végre a visszaállítást. A topográfiailag az icloud mögé helyezett HSM-klaszterek védik a zálogrekordokat. A korábban leírtaknak megfelelően mindegyik rendelkezik egy kulccsal, amellyel titkosítja a felügyelete alatt lévő a zálogrekordokat. A kulcskarika visszaállításához a felhasználónak hitelesítenie kell magát az icloud-fiókjával és jelszavával, és válaszolnia kell a regisztrált telefonszámra kapott SMS-re. Ha ez megtörtént, a felhasználónak meg kell adnia az icloud biztonsági kódot. A HSM-klaszter Secure Remote Password (SRP) használatával ellenőrzi, hogy a felhasználó ismeri-e az icloud biztonsági kódot; az Apple nem ismeri meg magát a kódot. A továbbiakban leírtaknak megfelelően a klaszter minden egyes tagja egymástól függetlenül ellenőrzi, hogy a felhasználó nem lépte-e túl a rekordok visszaszerzéséhez engedélyezett próbálkozások maximális számát. Ha többségi egyetértés van, a klaszter kicsomagolja a zálogrekordot, és elküldi a felhasználó eszközére. Ezután az eszköz az icloud biztonsági kódjával kicsomagolja a felhasználó kulcskarikájának titkosításához használt véletlenszerű kulcsot. A rendszer ezzel a kulccsal visszafejti az icloud kulcsértéktárolójából visszaszerzett kulcskarikát, és visszaállítja az eszközön. Az ios, ipados és macos csak 10 próbálkozást engedélyez a zálogrekord hitelesítéséhez és visszaszerzéséhez. Sorozatos sikertelen próbálkozások után a rekord zárolódik, és a felhasználónak fel kell hívnia az Apple-támogatást, ha további próbálkozásokhoz szeretne jutni. A 10. sikertelen próbálkozás után a HSM-klaszter megsemmisíti a zálogrekordot, és a kulcskarika visszavonhatatlanul elvész. Ez védelmet biztosít a rekord kiolvasására irányuló, nyers erővel végzett támadások ellen a kulcskarika megsemmisítésének árán. Ezek az irányelvek a HSM firmware-jébe vannak kódolva. A firmware módosítását lehetővé tevő adminisztratív hozzáférési kártyák meg lettek semmisítve. A firmware módosítására vagy a privát kulcs elérésére irányuló bármely próbálkozás hatására a HSM-klaszter törli a privát kulcsot. Ebben az esetben a klaszter által védett kulcskarika tulajdonosa üzenetet kap arról, hogy a zálogrekord elveszett. A felhasználó ismét regisztrálhat. A Safari integrációja az icloud-kulcskarikával A Safari képes automatikusan generálni kriptográfiailag erős véletlenszerű karakterláncokat a webhelyek jelszavaiként; ezeket a kulcskarika tárolja, és szinkronizálódnak más eszközökre. A kulcskarikaelemek az Apple szerverein keresztül kerülnek át egyik eszközről a másikra, de titkosítva vannak olyan módon, hogy az Apple és más eszközök nem tudják olvasni a tartalmukat. Apple Pay Az Apple Pay áttekintése Az Apple Pay segítségével a felhasználók a támogatott ios-eszközökkel, ipaddel, Mac géppel és Apple Watchcsal könnyen, biztonságosan és privát módon fizethetnek az áruházakban, alkalmazásokban és a weben a Safariban. Hozzáadhatnak továbbá Apple Pay-kompatibilis tömegközlekedési kártyákat az Apple Wallethoz. A felhasználók számára egyszerű, és mind hardveres, mind szoftveres integrált biztonsággal készült. 92

93 Az Apple Pay úgy lett tervezve, hogy védje a felhasználó személyes adatait. Az Apple Pay nem gyűjti a felhasználóhoz köthető tranzakcióadatokat. A fizetési tranzakciók a felhasználó, a kereskedő és a kártyakibocsátó között zajlanak. Az Apple Pay komponensei Secure Element A Secure Element iparági szabványnak minősülő, tanúsítvánnyal ellátott, Java Card platformot futtató chip, amely megfelel az elektronikus fizetések pénzügyi követelményeinek. A Secure Element IC és a Java Card platform az EMVCo biztonsági kiértékelési folyamat szerinti tanúsítvánnyal rendelkeznek. A biztonsági kiértékelés sikeres teljesítése után az EMVCo az IC-re és a platformra vonatkozó egyedi tanúsítványt bocsát ki. A Secure Element IC tanúsítása a Common Criteria szabvány szerint történt. NFC-vezérlő Az NFC-vezérlő kezeli a kis hatótávolságú kommunikáció protokolljait, és irányítja a kommunikációt az alkalmazásprocesszor és a Secure Element között, valamint a Secure Element és az értékesítési terminál között. Apple Wallet Az Apple Wallet segítségével a felhasználó hozzáadhat és kezelhet hitelkártyákat, bankkártyákat és áruházi kártyákat, és fizetéseket végezhet az Apple Payjel. Az Apple Walletban a felhasználók megtekinthetik a kártyáikat és a kártyakibocsátó által biztosított további információkat, például a kártyakibocsátó adatvédelmi irányelveit, a legutóbbi tranzakciókat és más adatokat. A felhasználók a következő helyeken is hozzáadhatnak kártyákat az Apple Payhez: Az ios és ipados Beállítási asszisztens és Beállítások alkalmazása Az Apple Watch Óra alkalmazása A Touch ID-val rendelkező Mac gépek Rendszerbeállítások alkalmazásában a Wallet és Apple Pay menüpontban Az Apple Wallet ezenkívül lehetővé teszi a felhasználóknak, hogy tömegközlekedési kártyákat, jutalomkártyákat, beszállókártyákat, jegyeket, ajándékkártyákat, diákigazolványokat és más kártyákat adjanak hozzá és kezeljenek. Secure Enclave Az iphone-on, ipaden, Apple Watchon és a Touch ID-val rendelkező Mac gépeken a Secure Enclave kezeli a hitelesítési folyamatot, és lehetővé teszi, hogy a fizetési folyamat végbemenjen. Apple Watch esetén az eszközt fel kell oldani, és a felhasználónak duplán meg kell nyomni az oldalsó gombot. Az eszköz érzékeli a dupla megnyomást, és közvetlenül továbbadja a Secure Elementnek vagy a Secure Enclave-nek (ha elérhetők), anélkül, hogy a folyamat áthaladna az alkalmazásprocesszoron. 93

94 Apple Pay-szerverek Az Apple Pay szerverei kezeli a hitelkártyák, bankkártyák, tömegközlekedési kártyák és diákigazolványok beállítását és előkészítését a Wallet alkalmazásban. A szerverek kezelik továbbá a Secure Elementben tárolt eszközfiókszámokat. Ezek kommunikálnak mind az eszközzel, mind a fizetési hálózat vagy kártyakibocsátó szervereivel. Az Apple Pay szerverei felelősek továbbá a fizetési hitelesítő adatok újbóli titkosításáért az alkalmazásokon belüli fizetések esetén. Hogyan használja az Apple Pay a Secure Elementet és az NFC-vezérlőt? Secure Element A Secure Element tartalmaz egy speciálisan az Apple Pay kezeléséhez tervezett alkalmazást. Tartalmaz továbbá fizetési hálózatok vagy kártyakibocsátók által tanúsított alkalmazásokat is. A hitelkártyák, bankkártyák vagy prepaid kártyák adatai olyan kulcsokkal titkosítva vannak elküldve a fizetési hálózatról vagy a kártyakibocsátótól az alkalmazásokhoz, amelyeket csak a fizetési hálózat vagy kártyakibocsátó és az alkalmazások biztonsági doménje ismer. Az adatok az alkalmazásokban tárolódnak, és a Secure Element biztonsági funkciói védik őket. Tranzakció közben a terminál dedikált hardverbuszon keresztül közvetlenül a Secure Elementtel kommunikál a kis hatótávolságú kommunikáció (NFC) vezérlőjén keresztül. NFC-vezérlő Az NFC-vezérlő a Secure Element átjárójaként gondoskodik arról, hogy minden érintés nélküli fizetési tranzakció az eszköz közvetlen közelében lévő értékesítési terminál használatával történik. Az NFC-vezérlő csak a hatótávolságon belül lévő termináltól érkező fizetési kérelmeket jelöli meg érintés nélküli tranzakcióként. Miután a hitelkártyás, bankkártyás vagy prepaid kártyás (köztük az áruházi kártyás) fizetéseket a kártyatulajdonos Touch ID-val, Face ID-val vagy jelkóddal, illetve a feloldott Apple Watch oldalsó gombjának dupla megnyomásával jóváhagyja, kizárólagosan a vezérlő irányítja a fizetési alkalmazások által a Secure Elementben előkészített érintés nélküli válaszokat az NFC-mezőhöz. Ennek következtében az érintés nélküli fizetési tranzakciók fizetéshitelesítéseinek részletei a helyi NFC-mezőre korlátozódnak, és soha nincsenek felfedve az alkalmazásprocesszor számára. Ezzel szemben az alkalmazásokon belüli vagy a weben történő fizetések fizetéshitelesítéseinek részletei az alkalmazásprocesszoron keresztül vannak irányítva, de csak azután, hogy a Secure Element titkosította azokat az Apple Pay szerverei számára. 94

95 Hitel-, bank- és prepaid kártyák A hitel-, bank- és prepaid kártyák Apple Payjel való előkészítésének áttekintése Amikor a felhasználó hozzáad egy hitelkártyát, bankkártyát vagy prepaid kártyát (beleértve az áruházi kártyákat is) az Apple Wallethoz, az Apple biztonságosan elküldi a kártyaadatokat a felhasználó fiókjára és eszközére vonatkozó más adatokkal együtt a kártyakibocsátónak vagy a kártyakibocsátó felhatalmazott szolgáltatójának. Ezen információk felhasználásával a kártyakibocsátó eldönti, hogy jóváhagyja-e a kártya hozzáadását az Apple Wallethoz. Az Apple Pay a kártya előkészítésének részeként három szerveroldali hívással küldi és fogadja a kártyakibocsátóval vagy hálózattal végzett kommunikációt: kötelező mezők, kártya ellenőrzése, valamint csatolás és előkészítés. A kártyakibocsátó vagy a hálózat ezekkel a hívásokkal ellenőrzi, hagyja jóvá és adja hozzá a kártyákat az Apple Wallethoz. Ezek a kliens-szerver munkamenetek TLS v1.2 titkosítást használnak. A teljes kártyaszámok sem az eszközön, sem az Apple Pay szerverein nem tárolódnak. Ehelyett egy egyedi eszközfiókszám jön létre, amelyet a rendszer titkosít és a Secure Elementben tárol. Ez az egyedi eszközfiókszám olyan módon van titkosítva, hogy az Apple ne tudjon hozzáférni. Az eszközfiókszám egyedi, és különbözik a legtöbb hitelkártya- vagy bankkártyaszámtól; a kártyakibocsátó vagy a fizetési hálózat megakadályozhatja ennek használatát mágnescsíkos kártyán, telefonon vagy webhelyeken. A Secure Elementben lévő eszközfiókszám sosem tárolódik az Apple Pay szerverein, nem kerül be az icloud biztonsági mentésbe, és el van szigetelve a ios, az ipados, a watchos rendszertől, valamint a Touch ID-val rendelkező Mac gépektől. Az Apple Watchcsal használt kártyákat az Apple Pay számára az iphone Apple Watch alkalmazása vagy a kártyakibocsátó iphone-alkalmazása készíti elő. Az Apple Watchhoz akkor lehet a kártyát hozzáadni, ha az óra a Bluetooth-kommunikáció tartományán belül van. A kártyák regisztrációja az Apple Watchcsal való használatra speciális, és külön eszközfiókszámmal rendelkeznek, amely az Apple Watch Secure Elementjében tárolódik. A hozzáadott hitelkártyák, bankkártyák vagy prepaid kártyák (beleértve az áruházi kártyákat is) megjelennek a Beállítási asszisztens használata során egy kártyalistában azokon az eszközökön, amelyek ugyanabba az icloud-fiókba vannak bejelentkezve. A kártyák mindaddig a listában maradnak, amíg legalább egy eszközön aktívak. A kártyák törlődnek a listáról, ha 7 napja minden eszközről el vannak távolítva. Ehhez a funkcióhoz be kell kapcsolni a kétlépéses hitelesítést a megfelelő icloud-fiókban. Hitelkártyák és bankkártyák manuális hozzáadása az Apple Payhez A kártya manuális hozzáadása során a név, a kártyaszám, a lejárati dátum és a CVV-kód segíti az előkészítési folyamatot. A felhasználó a Beállítások, a Wallet vagy az Apple Watch alkalmazásból tudja megadni ezeket az információkat begépeléssel vagy az eszköz kamerájának használatával. Amikor a kamera rögzíti a kártyaadatokat, az Apple megpróbálja kitölteni a nevet, kártyaszámot és lejárati dátumot. Soha nem menti a fotót az eszközre, és nem tárolja azt a fotókönyvtárban. Az összes mező kitöltése után a kártya ellenőrzése folyamat a CVV-kód kivételével ellenőrzi a mezőket. Az adatokat ezután titkosítva elküldi az Apple Pay szerverének. 95

96 Ha a kártya ellenőrzése folyamat során felhasználási feltételek azonosítója tér vissza, az Apple letölti és megjeleníti a kártyakibocsátó felhasználási feltételeit a felhasználó számára. Ha a felhasználó elfogadja a felhasználási feltételeket, az Apple elküldi az elfogadott feltételek azonosítóját, valamint a CVV-kódot a csatolás és előkészítés folyamatnak. A csatolási és előkészítési folyamat részeként az Apple az eszközről származó információkat oszt meg a kártyakibocsátóval vagy hálózattal; ilyen információk például: információk a felhasználó itunes- vagy App Store-fiókbeli tevékenységéről (például, hogy a felhasználónak az itunesban hosszú tranzakciótörténete van-e), a felhasználó eszközével kapcsolatos információk (például a felhasználó eszközének telefonszáma, neve és modellje, valamint az Apple Pay beállításához szükséges bármely további csatlakozó Appleeszköz), valamint a felhasználó közelítőleges tartózkodási helye a kártya hozzáadásának időpontjában (ha a felhasználó bekapcsolta Helymeghatározás funkciót). Ezen információk felhasználásával a kártyakibocsátó eldönti, hogy jóváhagyja-e a kártya hozzáadását az Apple Payhez. A csatolás és előkészítés folyamat részeként két dolog történik: Az eszköz elkezdi letölteni a hitel- vagy bankkártyát reprezentáló Wallet-jegyfájlt. Az eszköz elkezdi a kártyát a Secure Elementhez kötni. A jegyfájl tartalmazza a kártya képének letöltéséhez szükséges URL-t, a kártya metaadatait, például kontaktinformációkat, a kibocsátó vonatkozó alkalmazását és a támogatott funkciókat. A jegy állapotát is tartalmazza, amiben olyan információkat vannak, mint hogy a Secure Element megszemélyesítése befejeződött-e; hogy a kártyakibocsátó felfüggesztette-e a kártyát; vagy hogy szükséges-e további ellenőrzés, mielőtt a kártyával fizetni lehet az Apple Pay segítségével. Hitelkártyák és bankkártyák hozzáadása az Apple Payhez itunes Storefiókból Előfordulhat, hogy az itunesban rögzített hitelkártya vagy bankkártya esetén a felhasználónak ismét meg kell adnia az Apple ID jelszavát. A kártyaszám itunesból való beolvasása megtörténik, és inicializálódik a kártya ellenőrzése folyamat. Ha a kártya használható az Apple Payjel, akkor az eszköz letölti és megjeleníti a felhasználási feltételeket, majd továbbküldi a feltételek azonosítóját és a kártya biztonsági kódját a csatolás és előkészítés folyamatnak. További ellenőrzési lépés is lehetséges az itunesfiókban rögzített kártyák esetén. Hitelkártyák és bankkártyák hozzáadása a kártyakibocsátó alkalmazásából Ha az alkalmazás regisztrálva van az Apple Payjel való használatra, a kulcsok létrejönnek az alkalmazáshoz és a kártyakibocsátó szerveréhez. Ezekkel a kulcsokkal vannak titkosítva a kártyakibocsátónak küldött kártyaadatok, és ez megakadályozza, hogy az Apple-eszköz elolvassa az információkat. Az előkészítési folyamat hasonló a korábban ismertetett, manuálisan hozzáadott kártyákéhoz, kivéve, hogy a CVV hiányában egyszer használatos jelszavak vannak alkalmazva. 96

97 További ellenőrzés az Apple Payjel A kártyakibocsátó dönti el, hogy a hitelkártyához vagy bankkártyához van-e szükség további ellenőrzésre. Attól függően, hogy a kártyakibocsátó mit ajánl fel, a felhasználó választhat a további ellenőrzések különféle lehetőségeiből, például szöveges üzenet, , ügyfélszolgálati hívás, vagy jóváhagyott külső alkalmazásban használt módszer. A szöveges üzenet és az esetén a felhasználó a kibocsátónál tárolt kontaktadatokból választhat. Ekkor egy kódot kap, amelyet meg kell adnia a Wallet alkalmazásban, a Beállításokban vagy az Apple Watch alkalmazásban. Az ügyfélszolgálat vagy az alkalmazás segítségével végzett ellenőrzés esetén a kibocsátó a saját kommunikációs folyamatát végzi el. Fizetések hitelesítése az Apple Payjel A Secure Enclave processzorral rendelkező eszközök esetén a Secure Element csak akkor engedélyezi a fizetés elvégzését, ha jóváhagyást kap a Secure Enclave processzortól. iphone és ipad esetén ez annak a megerősítését jelenti, hogy a felhasználó elvégezte a hitelesítést a Touch ID, Face ID vagy az eszköz jelkódja segítségével. Ha elérhető, akkor a Touch ID vagy a Face ID az alapértelmezett módszer, de a jelkód minden esetben használható. Az eszköz automatikusan felkínálja a jelkód használatát, ha háromszor nem sikerült az ujjnyom vagy kétszer az arc egyeztetése; öt sikertelen próbálkozás után a jelkód megadása kötelező. A jelkód akkor is kötelező, amikor a Touch ID vagy a Face ID nincs konfigurálva, vagy nincs bekapcsolva az Apple Pay számára. Apple Watch esetén a fizetéshez az eszközt fel kell oldani a jelkóddal, és duplán meg kell nyomni az oldalsó gombot. A Secure Enclave és Secure Element közötti kommunikáció soros interfészen zajlik; a Secure Element a NFC-vezérlőhöz van kapcsolva, ami pedig az alkalmazásprocesszorhoz. A Secure Enclave és a Secure Element, habár nincsenek közvetlenül összekötve, képesek biztonságosan kommunikálni a gyártási folyamat során előkészített, megosztott párosítási kulcs segítségével. A kommunikáció titkosítása és hitelesítése AES algoritmuson alapul; mindkét oldal kriptográfiai nonce-okkal védekezik a visszajátszási támadások ellen. A párosítási kulcs a Secure Enclave processzorban generálódik a UID-kulcsából és a Secure Element egyedi azonosítójából. A párosítási kulcs ezután a gyárban biztonságos módon átkerül a Secure Enclave processzorból a hardverbiztonsági modulba (HSM), amely rendelkezik azzal a kulcsanyaggal, amely a párosítás kulcs Secure Elementbe való beszúrásához szükséges. Tranzakcióhitelesítés Amikor a felhasználó hitelesíti a tranzakciót, amely egy, a Secure Enclave felé kommunikált fizikai kézmozdulatot tartalmaz, a Secure Enclave egy hitelesítési random (AR) értékhez kötve elküldi a Secure Elementnek a hitelesítés típusával és a tranzakció típusával (érintés nélküli vagy alkalmazáson belüli) kapcsolatos aláírt adatokat. Az AR a Secure Enclave processzorban generálódik, amikor a felhasználó először készíti elő a hitelkártyát, és érvényben marad, amíg az Apple Pay be van kapcsolva; a Secure Enclave titkosítási és visszaforgatás elleni mechanizmusa védi. Biztonságosan átkerül a Secure Elementbe a párosítási kulcson keresztül. Új AR-érték fogadásakor a Secure Element a korábban hozzáadott kártyákat töröltként jelöli meg. 97

98 Tranzakcióspecifikus dinamikus biztonsági kód az Apple Payben A fizetési alkalmazásokból származó fizetési tranzakciók fizetési kriptogramot és eszközfiókszámot tartalmaznak. A rendszer a kriptogram (egy egyszer használatos kód) kiszámításához tranzakciószámlálót és kulcsot használ. A tranzakciószámláló minden új tranzakcióval növekszik. A kulcs a fizetési alkalmazásban a személyre szabás során jön létre, és a fizetési hálózat és/vagy a kártyakibocsátó számára ismert. A fizetési sémától függően más adatok is használhatók a számítás során, beleértve a következőket: A terminál véletlen száma (NFC-tranzakciók esetén) Apple Pay szerveroldali nonce (alkalmazásokon belüli tranzakciókhoz) Ezeket a biztonsági kódokat megkapja a fizetési hálózat és a kártyakibocsátó, és ezek segítségével ellenőrizheti a kibocsátó az egyes tranzakciókat. A biztonsági kódok hossza a tranzakció típusától függően változhat. Fizetés hitelkártyákkal és bankkártyákkal az áruházakban az Apple Pay használatával Ha az iphone vagy az Apple Watch be van kapcsolva, és NFC-mezőt észlel, felkínálja a felhasználónak a kért kártyát (ha az automatikus kiválasztás be van kapcsolva ahhoz a kártyához) vagy az alapértelmezett kártyát, amely a Beállításban van megadva. A felhasználó a Wallet alkalmazást is megnyithatja, és kiválaszthatja a kártyát, vagy ha az eszköz zárolva van: Megnyomhatja duplán a Főgombot a Touch ID-val rendelkező eszközök esetén Megnyomhatja duplán az oldalsó gombot a Face ID-val rendelkező eszközök esetén A fizetési információk elküldése előtt a felhasználónak ezután hitelesítenie kell magát a Touch ID vagy a Face ID használatával vagy a jelkóddal. Ha az Apple Watch fel van oldva, akkor az oldalsó gomb dupla megnyomása aktiválja az alapértelmezett kártyát a fizetéshez. A felhasználói hitelesítés nélkül a rendszer nem küld fizetési információkat. Miután a felhasználó elvégezte a hitelesítést, az eszközfiókszám és egy tranzakcióspecifikus dinamikus biztonsági kód használatával történik a fizetés feldolgozása. Sem az Apple, sem a felhasználó eszköze nem küldi el a teljes hitelkártyavagy bankkártyaszámot a kereskedőknek. Az Apple fogadhat anonim tranzakcióadatokat, például a tranzakció időpontja és helye; ezek az adatok segítenek az Apple Pay és más Apple-termékek és -szolgáltatások fejlesztésében. Fizetés hitelkártyákkal és bankkártyákkal az alkalmazásokban az Apple Pay használatával Az Apple Payjel továbbá vásárolhat az ios-, ipados- és Apple Watch-alkalmazásokban. Amikor a felhasználó Apple Payt használó alkalmazáson belül fizet, az Apple megkapja a titkosított tranzakcióadatokat. Mielőtt a fejlesztőnek vagy a kereskedőnek elküldené az adatokat, újból titkosítja őket egy fejlesztőspecifikus kulccsal. Az Apple Pay megtartja az anonim tranzakcióadatokat, például a vásárlás körülbelüli összege. Ez az információ nem köthető a felhasználóhoz, és sohasem tartalmazza a felhasználó által vásárolt termék nevét. 98

99 Amikor az alkalmazás Apple Pay fizetési tranzakciót indít, az Apple Pay szerverei még azelőtt fogadják a titkosított tranzakciót az eszközről, mielőtt a kereskedő megkapná azt. Az Apple Pay szerverei ezután újból titkosítják a tranzakciót egy kereskedőspecifikus kulccsal, mielőtt továbbítanák a kereskedőnek. Amikor egy alkalmazás fizetést kérelmez, API-t hív annak meghatározására, hogy az eszköz támogatja-e az Apple Payt, és hogy a felhasználó rendelkezik-e olyan hitelkártyával vagy bankkártyával, amellyel elvégezhető a fizetés a kereskedő által elfogadott fizetési hálózaton. Az alkalmazás a tranzakció feldolgozásához és teljesítéséhez szükséges összes információt elkéri, például a számlázási és szállítási címet és a kapcsolattartási adatokat. Ezután az alkalmazás megkéri az ios, ipados vagy watchos rendszert, hogy mutassa be azt az Apple Pay-lapot, amely az információkat kéri az alkalmazás számára, valamint elkéri a további szükséges információkat, például a használandó kártyát. Az alkalmazás ekkor megkapja a végső szállítási költség kiszámításához szükséges város, állam és postai irányítószám adatokat. Az alkalmazás nem kapja meg a kért információk teljes halmazát, amíg a felhasználó nem hitelesíti a fizetést a Touch ID-val, Face IDval vagy az eszköz jelkódjával. A fizetés hitelesítése után az Apple Pay-lapon szereplő információkat megkapja a kereskedő. Fizetéshitelesítés az alkalmazásban Amikor a felhasználó hitelesíti a fizetést, hívás indul az Apple Pay-szerverekhez a kriptográfiai nonce-ok beszerzéséért; ez hasonló ahhoz az értékhez, amelyet az NFCterminál ad vissza az áruházon belüli tranzakciók esetén. A nonce a tranzakcióadatokkal együtt a Secure Elementbe kerül, hogy egy Apple-kulccsal titkosított fizetési hitelesítő adatot generáljon. Amikor a titkosított fizetési hitelesítő adat kijön a Secure Elementből, akkor átkerül az Apple Pay-szerverekre, ezek visszafejtik a hitelesítő adatot, ellenőrzik a hitelesítő adatban szereplő nonce-ot az Apple Pay-szerverek által eredetileg küldött nonce segítségével, és újból titkosítják a fizetési hitelesítő adatot a kereskedőazonosítóhoz társított kereskedőkulccsal. A fizetés ekkor visszajut az eszközhöz, amely az API-n keresztül visszaadja azt az alkalmazásnak. Az alkalmazás ezután a kereskedő rendszerébe továbbítja az adatot feldolgozásra. A kereskedő a feldolgozáshoz a privát kulcsával tudja visszafejteni a fizetési hitelesítő adatot. Ez az Apple szervereitől kapott aláírással együtt lehetővé teszi a kereskedőnek, hogy megbizonyosodjon arról, hogy a tranzakció valóban az adott kereskedőnek van címezve. Az API-knak olyan jogosultságra van szükségük, amely megadja a támogatott kereskedőazonosítókat. Az alkalmazás további adatokat is elküldhet a Secure Elementnek aláírásra (például rendelésszámot vagy ügyfélidentitást), amelyekkel gondoskodik arról, hogy a tranzakció nem téríthető el másik ügyfél felé. Ezt az alkalmazásfejlesztő éri el, aki megadhatja az applicationdata tulajdonságot a PKPaymentRequest osztályban. Ennek az adatnak egy hashe szerepel a titkosított fizetési adatokban. Ezután a kereskedő felelőssége annak ellenőrzése, hogy az ő applicationdata hashe megfelel-e annak, amelyik a fizetési adatokban szerepel. Fizetés hitelkártyákkal és bankkártyákkal a weben az Apple Pay használatával Az Apple Pay segítségével végezhet fizetést a webhelyeken iphone, ipad és Apple Watch segítségével. Az Apple Pay-tranzakciók elindíthatók a Mac gépen is, és befejezhetők Apple Payt használó iphone-on vagy Apple Watchon, ha azonos icloud-fiókot használ. 99

100 Az Apple Pay akkor használható a weben, ha az összes részt vevő webhely regisztrál az Apple-nél. Az Apple-szerverek ellenőrzik a doménnevet, és TLS-klienstanúsítványt bocsátanak ki. Az Apple Payt támogató webhelyeknek kötelező a tartalmukat HTTPS protokollon biztosítaniuk. A webhelyeknek minden egyes tranzakcióhoz biztonságos és egyedi kereskedelmi munkamenetet kell kialakítaniuk egy Apple-szerverrel az Apple által kibocsátott TLS-klienstanúsítvány segítségével. A kereskedői munkamenet adatait az Apple aláírja. Ha a kereskedői munkamenet aláírásának ellenőrzése megtörtént, a webhely lekérdezheti, hogy a felhasználó rendelkezik-e Apple Payt használó eszközzel, és hogy van-e aktivált hitelkártya, bankkártya vagy prepaid kártya az eszközön. Egyéb részletek nincsenek megosztva. Ha a felhasználó nem szeretné megosztani ezeket az információkat, letilthatja az Apple Pay-lekérdezéseket a Safari adatvédelmi beállításaiban az ios, ipados és macos rendszerben. A kereskedői munkamenet ellenőrzése után minden biztonsági és adatvédelmi lépés azonos azzal, mintha a felhasználó alkalmazásban fizetne. Ha a felhasználó fizetéssel kapcsolatos információkat küld a Mac gépről iphone-ra vagy Apple Watchra, az Apple Pay Handoffja a végponttól végpontig titkosított Apple identitásszolgáltatás (IDS) protokollal küldi a fizetéssel kapcsolatos adatokat a felhasználó Mac gépe és a hitelesítést végző eszköz között. Az IDS a felhasználó eszközének kulcsaival végzi a titkosítást, így más eszköz nem tudja visszafejteni ezt az információt, és a kulcsokhoz az Apple sem fér hozzá. Az Apple Pay Handoff esetén az eszközfelderítés tartalmazza a felhasználó hitelkártyáinak egyedi azonosítóját, valamint bizonyos metaadatokat. A folyamat nem osztja meg a felhasználó eszközspecifikus fiókszámát; az továbbra is biztonságosan tárolódik a felhasználó iphone-ján vagy Apple Watchán. Az Apple biztonságosan viszi át továbbá a felhasználó legutóbb használt kapcsolattartási, szállítási és számlázási címeit az icloud-kulcskarikán keresztül. Miután a felhasználó hitelesítette a fizetést a Touch ID-val, Face ID-val, jelkóddal, vagy duplán megnyomta az Apple Watch oldalsó gombját, az egyes webhelyek kereskedői tanúsítványához egyedileg titkosított fizetési token biztonságosan átkerül a felhasználó iphone-járól vagy Apple Watcháról a Mac gépére, ahonnan a rendszer továbbítja a kereskedő webhelyére. Csak az egymás közelében lévő eszközök kérelmezhetnek és fejezhetnek be fizetést. A közelséget Bluetooth Low Energy (BLE) hirdetmények határozzák meg. Érintés nélküli jegyek az Apple Payben A támogatott jegyek kompatibilis NFC-terminálokra való átviteléhez az Apple az Apple Wallet hozzáadott-értékű szolgáltatás (Apple VAS) protokollt használja. A VAS-protokoll implementálható érintés nélküli terminálokon, és az NFC-t használja a támogatott Appleeszközökkel végzett kommunikáció során. A VAS-protokoll rövid hatótávú, és használható az érintés nélküli jegyekhez függetlenül vagy Apple Pay-tranzakció részeként. Amikor a felhasználó az eszközt NFC-terminál közelébe helyezi, a terminál inicializálja a jegyinformációk fogadását azáltal, hogy kérelmet küld a jegynek. Ha a felhasználó rendelkezik a jegyszolgáltató azonosítóját hordozó jeggyel, akkor a rendszer felkéri, hogy hitelesítse annak használatát a Touch ID, Face ID vagy jelkód segítségével. A jegyinformációk, az időbélyegző és egy egyszer használatos véletlenszerű ECDH P-256 kulcs, valamint a jegyszolgáltató nyilvános kulcsának felhasználásával titkosítási kulcs készül a jegyadatok számára, és ezt kapja meg a terminál. 100

101 ios 12 és ios 13 esetén a felhasználó manuálisan kiválaszthat egy jegyet, mielőtt bemutatja azt a kereskedő NFC-termináljának. ios 13.1 és újabb rendszer esetén a jegyszolgáltató konfigurálhatja úgy a manuálisan kiválasztott jegyeket, hogy a felhasználói hitelesítés kötelező legyen, vagy hitelesítés nélkül is használhatók legyenek. Kártyák használhatatlanná tétele az Apple Pay számára A Secure Elementhez adott hitelkártyák, bankkártyák és prepaid kártyák csak akkor használhatók, ha a Secure Element megkapja ugyanazt a párosító kulcsot és AR-értéket használó hitelesítést, amely a kártya hozzáadásakor volt használatban. Új AR-érték fogadásakor a Secure Element a korábban hozzáadott kártyákat töröltként jelöli meg. Ennek segítségével az operációs rendszer arra utasíthatja a Secure Enclave processzort, hogy az tegye használhatatlanná a kártyákat a saját AR-példányának érvénytelennek jelölésével a következő szcenáriók esetén: Módszer Ha a jelkód le van tiltva Ha a jelszó le van tiltva A felhasználó kijelentkezik az icloudból A felhasználó az Összes tartalom és beállítás törlése lehetőséget választja Az eszköz helyreállítási módból állt vissza Párosítás törlése Eszköz iphone, ipad, Apple Watch Mac iphone, ipad, Mac, Apple Watch iphone, ipad, Apple Watch iphone, ipad, Mac, Apple Watch Apple Watch Kártyák felfüggesztése, eltávolítása és törlése A felhasználó felfüggesztheti az Apple Pay funkciót az iphone-on, ipaden és az Apple Watchon, ha az eszközt Elveszett módba helyezi a Lokátor funkcióval. A felhasználó továbbá el is távolíthatja és törölheti a kártyáit az Apple Payből a Lokátor funkcióval, az icloud.com webhellyel vagy közvetlenül az eszközön a Wallet alkalmazással. Apple Watch esetén a kártyák eltávolíthatók az icloud-beállítások használatával, az iphone Apple Watch alkalmazásával és közvetlenül az órán. A kártyakibocsátó vagy a vonatkozó fizetési hálózat megakadályozhatja a fizetéseket az eszközön lévő kártyák felfüggesztésével vagy az Apple Payből való eltávolításával, még ha az eszköz offline állapotban is van, és nem csatlakozik mobilhálózathoz vagy Wi-Fi-hálózathoz. A felhasználó is megkérheti a kártyakibocsátót, hogy függessze fel a kártyákat, vagy távolítsa el őket az Apple Payből. Ezenkívül, amikor a felhasználó törli a teljes eszközt az Összes tartalom és beállítás törlése vagy a Lokátor használatával, vagy az eszköz visszaállításával, az ios-, ipadosés macos-eszközök arra utasítják a Secure Elementet, hogy jelölje töröltként a kártyákat. Ennek eredményeképpen a kártyák használhatatlan állapotba kerülnek mindaddig, amíg az Apple Pay szervereivel sikerül felvenni a kapcsolatot, hogy a kártyák teljesen törlődjenek a Secure Elementből. A Secure Enclave ettől függetlenül érvénytelennek jelöli az AR-t, így a korábban regisztrált kártyák esetén a további fizetéshitelesítések nem lehetségesek. Amikor az eszköz online állapotba kerül, megpróbál kapcsolatba lépni az Apple Pay szervereivel, hogy a Secure Elementben lévő összes kártya törlődjön. 101

102 Apple Cash ios 11.2 és újabb, valamint watchos 4.2 és újabb rendszer esetén az Apple Pay segítségével a felhasználók egymás között pénzt küldhetnek, fogadhatnak és kérhetnek az iphone-on, ipaden vagy Apple Watchon. A felhasználó által fogadott pénz Apple Cash-fiókba kerül, amely elérhető a Wallet alkalmazásban vagy a Beállítások > Wallet és Apple Pay menüpontban minden olyan kompatibilis eszközön, amelyen a felhasználó bejelentkezett az Apple ID-jával. Ha a felhasználó egy másik személynek szeretne fizetni az Apple Cash segítségével, akkor be kell jelentkeznie az icloud-fiókjába egy Apple Cash-kompatibilis eszközön, és kétlépéses hitelesítést kell használnia az icloud-fiókjában. Amikor először állítja be az Apple Casht, akkor ugyanazokat az információk, mint amelyeket a hitelkártya vagy bankkártya hozzáadásakor ad hozzá, megoszthatjuk partnerbankunkkal, a Green Dot Bankkal és az Apple Payments Inc. vállalattal, amely teljesen a tulajdonunkban álló leányvállalat, és amely azért jött létre, hogy megvédjük a felhasználók adatait azáltal, hogy Apple többi részétől elkülönítve tároljuk és dolgozzuk fel az információkat olyan módon, hogy az Apple többi része ezekről nem tud. Ezek az információk kizárólag hibaelhárítási, csalásmegelőzési és a törvényi előírásoknak való megfelelési célokat szolgálnak. A pénzigénylések és -átutalások kezdeményezése az Üzenetek alkalmazáson belül vagy a Siri megkérésével történik. Amikor a felhasználó pénzt szeretne küldeni, az imessage megjeleníti az Apple Pay lapját. Először mindig az Apple Cash-egyenlegből vonódik le az összeg. Szükség esetén további összegek vonódnak le a felhasználó által a Wallet alkalmazáshoz hozzáadott második hitelkártyáról vagy bankkártyáról. A Wallet alkalmazás Apple Cash-kártyája használható az Apple Payjel áruházakban, alkalmazásokban és a weben végzett fizetésekhez. Az Apple Cash-fiókban lévő pénz bankszámlára is átutalható. A másik felhasználótól fogadott pénzen túl az Apple Cashfiókhoz a Wallet alkalmazásban lévő bankkártyáról vagy prepaid kártyáról is adható pénz. Az Apple Payments Inc. a tranzakció elvégzése után tárolhatja és felhasználhatja a felhasználó tranzakcióadatait hibaelhárítási, csalásmegelőzési és a törvényi előírásoknak való megfelelési célok érdekében. Az Apple többi része számára nem ismert, hogy a pénz kihez érkezik, kitől ered, és hogy a felhasználó hol vásárolt az Apple Cash-kártyájával. Amikor a felhasználó pénzt küld az Apple Payjel, pénzt ad egy Apple Cash-fiókhoz, vagy pénzt utal át bankszámlára, akkor hívást kezdeményez az Apple Pay szervereihez, hogy beszerezze a kriptográfiai nonce-ot, amely hasonló ahhoz az értékhez, amelyet az Apple Pay kap vissza az alkalmazásokon belül. A nonce a tranzakcióadatokkal együtt a Secure Elementbe kerül, hogy fizetési aláírást generáljon. Amikor a fizetési aláírás kijön a Secure Elementből, áthalad az Apple Pay szerverein. Az Apple Pay szerverei a fizetési aláírással és a nonce-szal ellenőrzik a tranzakció hitelességét, integritását és helyességét. Ezután megkezdődik a pénzátutalás, és a felhasználó értesítést kap a befejezett tranzakcióról. Ha a tranzakcióban szerepel hitelkártya vagy bankkártya az Apple Cashnek való pénzküldésre, pénz küldésére másik felhasználóhoz, vagy kiegészítő összeg biztosítására, ha az Apple Cash egyenlege elégtelen, akkor a titkosított fizetési hitelesítő adat is létrejön, és a rendszer elküldi az Apple Pay szervereinek; az adat hasonló ahhoz, amelyet az Apple Pay használ alkalmazásokon belül és webhelyeken. 102

103 Ha az Apple Cash-fiók egyenlege átlép egy bizonyos összeget, vagy ha szokatlan tevékenység észlelhető, a felhasználó felkérést kap a személyazonosságának igazolására. A felhasználó személyazonosságának ellenőrzésére használt információk például a társadalombiztosítási szám, illetve a kérdésekre adott válaszok (például korábbi lakcím megerősítése) biztonságosan kerülnek át az Apple partneréhez, és titkosítva vannak az ő kulcsukkal. Az Apple nem tudja visszafejteni ezeket az adatokat. Apple Card Az Apple Card használata a Wallet alkalmazásban ios 12.4 és újabb, macos és újabb, watchos 5.3 és újabb rendszer esetén az Apple Card használható az Apple Payjel az áruházakban, alkalmazásokban és a weben végzett vásárlásokhoz. Ha a felhasználó Apple Cardot szeretne igényelni, akkor be kell jelentkeznie az icloudfiókjába egy Apple Pay-kompatibilis ios- vagy ipados-eszközön, és kétlépéses hitelesítést kell használnia az icloud-fiókjában. Ha az igénylést jóváhagyják, az Apple Card elérhetővé válik a Wallet alkalmazásban vagy a Beállítások > Wallet és Apple Pay menüpontban minden olyan kompatibilis eszközön, amelyen a felhasználó bejelentkezett az Apple IDjával. Az Apple Card igénylésekor a felhasználó személyazonossági adatait az Apple identitásszolgáltató partnerei biztonságosan ellenőrzik, majd megosztják a Goldman Sachs Bank USA vállalattal a személyazonosság és a hitelképesség kiértékelése érdekében. Az igénylés során megadott olyan információk továbbítása, mint a társadalombiztosítási szám vagy a személyazonosításra szolgáló dokumentum képe, titkosítva történik az Apple identitásszolgáltató partnerei és/vagy a Goldman Sachs Bank USA számára, a titkosításhoz pedig az adott vállalat kulcsai használatosak. Az Apple nem tudja visszafejteni ezeket az adatokat. A rendszer biztonságosan továbbítja az igénylés során megadott bejövő információkat és a számlázáshoz használt bankszámlaadatokat a Goldman Sachs Bank USA vállalatnak, az ő kulcsukkal titkosítva. A bankszámlaadatok a kulcskarikára kerülnek. Az Apple nem tudja visszafejteni ezeket az adatokat. Amikor a felhasználó Apple Cardot ad hozzá a Wallet alkalmazáshoz, akkor előfordulhat, hogy ugyanazok az információk, mint amelyeket a hitelkártya vagy bankkártya hozzáadásakor ad hozzá, meg lesznek osztva az Apple partnerbankjával, a Goldman Sachs Bank USA bankkal és az Apple Payments Inc. vállalattal. Ezek az információk kizárólag hibaelhárítási, csalásmegelőzési és a törvényi előírásoknak való megfelelési célokat szolgálnak. A Wallet alkalmazásban fizikai kártya is igényelhető az Apple Cardból. Miután a felhasználó megkapta a fizikai kártyát, a kártya aktiválásához a fizikai kártya lezárt borítékjában található NFC-címke szükséges. A címke minden kártya esetén egyedi, és nem használható másik felhasználó kártyájának aktiválásához. Alternatív megoldásként a kártya manuálisan is aktiválható a Wallet beállításaiban. A felhasználó ezenkívül bármikor zárolhatja a kártyát (illetve feloldhatja a zárolást) a Wallet alkalmazásban. 103

104 Az Apple Card-fizetések és az Apple Wallet-jegyek részletei Az Apple Card-fiókkal történő fizetések elvégezhetők az ios rendszer Wallet alkalmazásából az Apple Cash és egy bankszámla segítségével. Az Apple Cash és a bankszámla segítségével a számlabefizetések ütemezhetők ismétlődőre vagy adott dátumú, egyszeri alkalomra. Amikor a felhasználó fizetést végez, a rendszer hívást küld az Apple Pay-szerverekhez, hogy az Apple Cashhez hasonló kriptográfiai nonce-ot szerezzen be. A nonce a beállított fizetésadatokkal együtt a Secure Elementbe kerül, hogy aláírást generáljon. Amikor a fizetési aláírás kijön a Secure Elementből, áthalad az Apple Pay szerverein. A fizetés hitelesítésének, integritásának és helyességének ellenőrzését az aláíráson és a nonce-on keresztül az Apple Pay szerverei végzik, és a megrendelés ezután átkerül a Goldman Sachs Bank USA vállalathoz feldolgozásra. Ha a felhasználó meg szeretné jeleníteni az Apple Card számának részleteit a jegyben a Wallet alkalmazással, akkor hitelesítenie kell magát a Face ID-val, Touch ID-val vagy a jelkóddal. A felhasználó lecserélheti ezt az adatot a kártya információs részében, és ez letiltja az előzőt. Tömegközlekedési kártyák a Wallet alkalmazásban A felhasználók számos globális piacon hozzáadhatnak tömegközlekedési kártyákat a Wallet alkalmazáshoz, az iphone és az Apple Watch támogatott modelljein. A közlekedési vállalattól függően ez elvégezhető úgy, hogy a felhasználó az értéket és a tömegközlekedési jegyet átviszi a fizikai kártyáról a digitális Apple Wallet-reprezentációba, vagy úgy, hogy új tömegközlekedési kártyát készít elő a Wallet alkalmazásban a Wallet alkalmazáson belül vagy a tömegközlekedési kártya kibocsátójának alkalmazásán belül. Miután a felhasználó hozzáadta a tömegközlekedési kártyát a Wallet alkalmazáshoz, az utazás érvényesítéséhez elegendő az iphone-t vagy az Apple Watchot a közlekedési leolvasóegységhez tartani. Bizonyos kártyákkal fizetések is végezhetők. A hozzáadott tömegközlekedési kártyák a felhasználó icloud-fiókjához vannak társítva. Ha a felhasználó több kártyát is a Wallet alkalmazáshoz ad, akkor az Apple vagy a tömegközlekedési kártya kibocsátója képes lehet összekapcsolni a kártyák között a felhasználó személyes adatait és a társított fiókinformációkat. A tömegközlekedési kártyákat és a tranzakciókat kriptográfiai kulcsok hierarchikus készlete védi. A felhasználóknak kártyaspecifikus információkat kell megadniuk, miközben átutalják az egyenleget a fizikai kártyáról a Wallet alkalmazásba. Előfordulhat, hogy a felhasználóknak ezenkívül személyes adatok megadásával kell bizonyítaniuk, hogy birtokában vannak a kártyának. Amikor jegyeket visz át az iphone-ról az Apple Watchra, az átvitel közben mindkét eszköznek csatlakoznia kell az internetre. Az egyenleg feltölthető hitelkártyáról, bankkártyáról és prepaid kártyáról a Wallet alkalmazáson keresztül vagy a tömegközlekedési kártya kibocsátójának alkalmazásából. Az Apple Pay használatával végzett egyenlegfeltöltés biztonságának leírása a Fizetés hitelkártyákkal és bankkártyákkal az alkalmazásokban az Apple Pay használatával című részben olvasható. Annak a folyamatnak a leírása, amikor a tömegközlekedési kártyát a tömegközlekedési kártya kibocsátójának alkalmazásában készíti elő, a Hitelkártyák és bankkártyák hozzáadása a kártyakibocsátó alkalmazásából című részben olvasható. 104

105 Ha a fizikai kártyáról történő előkészítés támogatva van, akkor a tömegközlekedési kártya kibocsátója rendelkezik a fizikai kártya hitelesítéséhez és a felhasználó által megadott adatok ellenőrzéséhez szükséges kriptográfiai kulcsokkal. Az adatok ellenőrzése után a rendszer képes eszközfiókszámot létrehozni a Secure Elementhez, és képes aktiválni az újonnan hozzáadott jegyet a Wallet alkalmazásban az átutalt egyenleggel. Bizonyos városokban, miután megtörtént a fizikai kártyáról az előkészítés, a fizikai kártya letiltódik. Mindegyik típusú előkészítési folyamat végén a tömegközlekedési kártya egyenlege az eszközön tárolódik; a rendszer titkosítja és a Secure Element kijelölt alkalmazásában tárolja. A közlekedési vállalat rendelkezik azokkal a kulcsokkal, amelyekkel el lehet végezni a kártyaadatokkal kapcsolatos kriptográfiai műveleteket az egyenleget érintő tranzakciók esetén. Alapértelmezés szerint a felhasználók zökkenőmentes Expressz tömegközlekedési élményt élvezhetnek, amellyel Touch ID, Face ID vagy jelkód nélkül fizethetnek és utazhatnak. Bekapcsolt Expressz mód mellett a közelben lévő érintés nélküli kártyaolvasók hozzáférhetnek az olyan információkhoz, mint a legutóbb felkeresett állomások, tranzakciótörténet és további jegyek. A felhasználó bekapcsolhatja a Touch ID-val, Face ID-val vagy jelkóddal végzett hitelesítés követelményét a Wallet és Apple Pay beállításaiban az Expressz tömegközlekedés kikapcsolásával. Csakúgy, mint más Apple Pay-kártyák esetén, a felhasználók felfüggeszthetik vagy eltávolíthatják a tömegközlekedési kártyákat a következő műveletekkel: Az eszköz távoli törlése a Lokátor segítségével Az Elveszett mód bekapcsolása a Lokátor segítségével A mobileszköz-felügyelet (MDM) távoli törlési parancsa Az összes kártya eltávolítása az Apple ID-fiók oldaláról Az összes kártya eltávolítása az icloud.com webhelyről Az összes kártya eltávolítása a Wallet alkalmazásból Az összes kártya eltávolítása a kibocsátó alkalmazásából Az Apple Pay-szerverek értesítik a közlekedési vállalatot, hogy függessze fel vagy tiltsa le az érintett kártyákat. Ha a felhasználó eltávolítja a tömegközlekedési kártyát egy online eszközből, úgy nyerheti vissza az egyenleget, ha azonos Apple ID-val bejelentkezett eszközhöz adja vissza. Ha az eszköz offline, ki van kapcsolva vagy használhatatlan, az egyenleg visszaállítása nem minden esetben lehetséges. Hitelkártyák és bankkártyák tömegközlekedéshez a Wallet alkalmazásban Bizonyos városokban a tömegközlekedési leolvasóegységeken használhatók az EMVkártyák az utazás fizetéséhez; amikor a felhasználó a hitelkártyát vagy bankkártyát a kártyaolvasóhoz emeli, csak olyan mértékű felhasználóhitelesítés szükséges, mint a Fizetés hitelkártyákkal és bankkártyákkal az áruházakban esetén. 105

106 ios 12.3 és újabb rendszerek esetén a Wallet alkalmazásban meglévő bizonyos EMV hitel-/bankkártyákon engedélyezhető az Expressz tömegközlekedés, amely segítségével a felhasználó Touch ID, Face ID vagy jelkód nélkül fizetheti az utazást a támogatott közlekedési vállalatoknál. Amikor a felhasználó EMV hitel- vagy bankkártyát készít elő, akkor a Wallet alkalmazásban először megadott kártyán engedélyezve lesz az Expressz tömegközlekedés. A felhasználó a Wallet alkalmazásban a kártyán lévő Továbbiak gombra koppintva kapcsolhatja ki az Expressz tömegközlekedés funkciót a kártya esetén; ehhez az Expresszközlekedés beállításai > Nincs lehetőségre kell koppintani. A felhasználó a Wallet alkalmazáson keresztül másik hitel- vagy bankkártyát is beállíthat Expressz tömegközlekedési kártyának. A Touch ID, Face ID vagy a jelkód használata kötelező, ha másik kártyát szeretne kiválasztani az Expressz tömegközlekedés funkcióhoz, vagy újból engedélyezni szeretné a meglévőt. Az Apple Card és az Apple Cash használható az Expressz tömegközlekedés funkcióhoz. Diákigazolványok a Wallet alkalmazásban ios 12 és újabb rendszer esetén a vevő campusok hallgatói, oktatói és más munkatársai hozzáadhatják diákigazolványaikat a Wallet alkalmazáshoz az iphone és az Apple Watch támogatott modelljein, hogy hozzáférjenek bizonyos helyekhez, és fizessenek a kártyaelfogadó helyeken. A felhasználó a kártyakibocsátó vagy a részt vevő iskola által nyújtott alkalmazáson keresztül tudja hozzáadni a diákigazolványát a Wallet alkalmazáshoz. Technikai szempontból a művelet ugyanúgy zajlik, mint a Hitelkártyák és bankkártyák hozzáadása a kártyakibocsátó alkalmazásából szakaszban leírtak esetén. A kibocsátó alkalmazásoknak ezenkívül támogatniuk kell a kétlépéses hitelesítést a diákigazolványokhoz való hozzáférést védő fiókok esetén. Az egyes kártyák legfeljebb két támogatott, azonos Apple ID-val bejelentkezett Apple-eszközön állíthatók be egyszerre. Amikor diákigazolványt ad hozzá a Wallet alkalmazáshoz, alapértelmezés szerint az Expressz mód be van kapcsolva. Az Expressz módban lévő diákigazolványok a Touch ID-val, Face ID-val vagy jelkóddal végzett hitelesítés, illetve Apple Watch esetén az oldalsó gomb dupla megnyomása nélkül kommunikálnak az őket elfogadó terminálokkal. A felhasználó a Wallet alkalmazásban a kártyán lévő Továbbiak gombra koppinthat, és kikapcsolhatja az Expressz tömegközlekedés módot a funkció letiltásához. A Touch ID, Face ID vagy a jelkód használata kötelező, ha újból engedélyezni szeretné az Expressz módot. A diákigazolványok letilthatók vagy eltávolíthatók a következő műveletekkel: Az eszköz távoli törlése a Lokátor segítségével Az Elveszett mód bekapcsolása a Lokátor segítségével A mobileszköz-felügyelet (MDM) távoli törlési parancsa Az összes kártya eltávolítása az Apple ID-fiók oldaláról Az összes kártya eltávolítása az icloud.com webhelyről Az összes kártya eltávolítása a Wallet alkalmazásból Az összes kártya eltávolítása a kibocsátó alkalmazásából 106

107 imessage Az imessage áttekintése Az Apple imessage az ios- és ipados-eszközökhöz, az Apple Watchhoz és a Mac gépekhez készült üzenetküldő szolgáltatás. Az imessage támogatja a szövegek küldését, a mellékletek küldését (például fotók, kontaktok, helyek, linkek), és a közvetlenül az üzenethez csatolt mellékletek küldését, mint amilyen a helyeslést kifejező ikon. Az üzenetek a felhasználó összes regisztrált eszközén megjelennek, így a beszélgetés bármely eszközről folytatható. Az imessage nagy mértékben használja az Apple Push Notification szolgáltatást (APNs). Az Apple nem naplózza az üzenet vagy a mellékletek tartalmát; ezeket végponttól végpontig tartó titkosítás védi, így csak a feladó és a címzett férhet hozzájuk. Az Apple nem tudja visszafejteni az adatokat. Amikor a felhasználó egy eszközön bekapcsolja az imessage-et, az eszköz titkosítást és aláírási kulcspárt generál a szolgáltatáshoz. Titkosítás céljára a rendszer rendelkezik titkosítási RSA 1280 bites kulccsal, valamint titkosítási EC 256 bites kulccsal a NIST P-256 görbén. Az aláírásokhoz ECDSA 256 bites aláírókulcsok használatosak. A privát kulcsok az eszköz kulcskarikájára vannak mentve, és csak az első feloldás után érhetők el. A rendszer a nyilvános kulcsokat az Apple-identitásszolgáltatásba (IDS) küldi, ahol felhasználó telefonszámához és -címéhez társulnak az eszköz APNs-címével együtt. Ahogy a felhasználó további eszközöket kapcsol be az imessage használatába, azok titkosítási és nyilvános aláírókulcsai, APNs-címei és a társított telefonszámok is hozzáadódnak a címtárszolgáltatáshoz. A felhasználó további -címeket is hozzáadhat; ezek ellenőrzése megerősítési linkkel történik. A telefonszámokat a szolgáltatói hálózat és a SIM-kártya ellenőrzi. Bizonyos hálózatok esetén ehhez SMS szükséges (ha az SMS nem ingyenes, akkor a felhasználó megerősítési párbeszédablakot kap). A telefonszám ellenőrzése az imessage-en kívül további rendszerszolgáltatás esetén is szükséges lehet, például a FaceTime és az icloud esetén. A felhasználó összes regisztrált eszköze figyelmeztető üzenetet jelenít meg, amikor új eszközt, telefonszámot vagy -címet ad hozzá. Hogyan küld és fogad üzeneteket az imessage? A felhasználó az imessage-beszélgetés első lépéseként címet vagy nevet ad meg. Telefonszám vagy -cím megadásakor az eszköz kapcsolatba lép az Appleidentitásszolgáltatással (IDS), hogy beszerezze a címzetthez társított összes eszköz nyilvános kulcsait és APNs-címeit. Név megadásakor az eszköz először a felhasználó Kontaktok alkalmazását használja a névhez társított telefonszámok és -címek beolvasásához, majd az IDS-ből beolvassa a nyilvános kulcsokat és APNs-címeket. 107

108 A felhasználó kimenő üzenete külön-külön titkosítva van a címzett minden egyes eszköze esetén. A rendszer a fogadó eszközök nyilvános titkosítási és aláírókulcsait az IDS-ből olvassa be. A küldő eszköz minden egyes fogadó eszközhöz véletlenszerű 88 bites értéket generál, és HMAC-SHA256 kulcsként használja azt, hogy a küldő és a fogadó nyilvános kulcsából, valamint a szövegből származtatott 40 bites értéket hozzon létre. A 88 bites és 40 bites értékek összefűzése 128 bites kulcsot eredményez, amely CTR módú AES használatával titkosítja az üzenetet. A 40 bites értéket a fogadó oldal a visszafejtett szöveg integritásának ellenőrzésére használja. Ez az üzenetalapú AES-kulcs a fogadó eszköz nyilvános kulcsára alkalmazott RSA-OAEP sémával van titkosítva. A titkosított üzenetszöveg és a titkosított üzenetkulcs kombinációja SHA-1 függvénnyel van hashelve, és a hash ECDSA algoritmussal van aláírva a feladó eszköz privát aláírókulcsának használatával. Az ios 13 és ipados 13.1 rendszerekkel kezdve az eszközök használhatnak ECIES-titkosítást az RSA-titkosítás helyett. Az így létrejövő üzenetek minden egyes fogadó eszköz esetén tartalmazzák a titkosított üzenetszöveget, a titkosított üzenetkulcsot és a feladó digitális aláírását. A rendszer ezután kézbesítésre elküldi őket az APNs számára. A metaadatok, mint az időbélyegző és az APNs-továbbítási információk nincsenek titkosítva. Az APNs-sel végzett kommunikáció sérülés utáni titkosságvédelemmel ellátott TLS-csatornával zajlik. 108

109 Az APNs legfeljebb csak 4 kb és 16 kb méretű üzeneteket tud átjátszani, az ios vagy ipados verziójától függően. Ha az üzenet szövege túl hosszú, vagy ha melléklet (például fotó) is tartozik hozzá, a melléklet CTR módú AES-titkosítást kap véletlenszerűen generált 256 bites kulccsal, és a rendszer feltölti azt az icloudba. A rendszer a melléklet AESkulcsát, annak URI-ját, és a titkosított formájának SHA-1 hashét elküldi az imessage-üzenet tartalmaként; a megbízhatóságot és integritást normál imessage-titkosítás védi, az alábbi ábrán látható módon. Hogyan küld és fogad üzeneteket az imessage? Csoportos beszélgetések esetén a folyamat minden egyes felhasználó és eszköz esetén megismétlődik. A fogadó oldalon mindegyik eszköz megkapja a saját példányát az APNs-től, és ha szükséges, beolvassa a mellékletet az icloudból. A feladó bejövő telefonszáma vagy -címe egyeztetve van a címzett kontaktjaival, így ha lehetséges, név jelenik meg. Az üzenet a kézbesítéskor törlődik az APNs-ről, mint minden push-értesítés. Más APNsértesítésektől eltérően azonban az imessage-üzenetek várólistára kerülnek az offline eszközökre való kézbesítéshez. Az üzenetek legfeljebb 30 napig tárolódnak. Név és fotó megosztása az imessage-ben Az imessage Név és fotó megosztása funkciójával a felhasználó nevet és fotót oszthat meg az imessage használatával. A felhasználó kiválaszthatja a Saját kártya információit, vagy testreszabhatja a nevet, és bevonhat tetszőleges képet. Az imessage Név és fotó megosztása funkció kétlépéses rendszerben terjeszti a nevet és a fotót. 109

110 Az adatok mezőkre vannak tovább osztva; mindegyik egymástól függetlenül van titkosítva és hitelesítve, valamint az alábbi folyamattal együtt is hitelesítve vannak. Három mező van: Név Fotó Fotófájl neve Az adatok létrehozásának első lépéseként az eszközön véletlenszerűen generálódik egy 128 bites rekordkulcs. A rekordkulcsot a HKDF-HMAC-SHA256 deriválja, hogy három alkulcsot hozzon létre: Kulcs 1:Kulcs 2:Kulcs 3 = HKDF(rekordkulcs, becenevek ). Minden mezőhöz véletlenszerű 96 bites IV generálódik, és az adatok AES-CTR és Kulcs 1 használatával titkosítva lesznek. Ezután a rendszer üzenethitelesítési kódot (MAC) számol a Kulcs 2-t használó HMAC-SHA256 segítségével, és lefedi a mezőnevet, a mező IV-t és a mező ciphertextjét. Végezetül a rendszer összefűzi az egyedi mező MAC-értékeket, és a MAC-értéket a Kulcs 3-at használó HMAC-SHA256 segítségével kiszámolja. A 256 bites MAC a titkosított adatok mellett van tárolva. A MAC első 128 bitjét RecordID-ként használja a rendszer. Ez a titkosított rekord a CloudKit nyilvános adatbázisában, a RecordID helyen tárolódik. Ez a rekord soha nem módosul, és amikor a felhasználó módosítja a nevét és a fotóját, mindig új titkosított rekord generálódik. Amikor az 1. felhasználó megosztja a nevét és a fotóját a 2. felhasználó-val, akkor a titkosított imessage-adatcsomagban elküldi a rekordkulcsot a rekordazonosítóval együtt. Amikor a 2. felhasználó fogadja ezt az imessage-adatcsomagot, észleli, hogy az adatcsomag a becenév és a fotó rekordazonosítóját és kulcsát tartalmazza. A 2. felhasználó eszköze ekkor felkeresi a nyilvános CloudKit-adatbázist, hogy beszerezze a titkosított nevet és fotót a rekordazonosítóval, és elküldi azokat az imessage-en keresztül. A fogadás után a 2. felhasználó eszköze visszafejti az adatcsomagot, és magával a rekordazonosítóval ellenőrzi az aláírást. Ha ez a művelet sikeres, akkor a 2. felhasználó megkapja a nevet és a fotót, és kiválaszthatja, hogy hozzáadja-e a kontaktokhoz, vagy az Üzenetekben használja-e. Csevegés vállalkozásokkal A Csevegés vállalkozásokkal olyan üzenetküldő szolgáltatás, amellyel a felhasználók vállalkozásokkal kommunikálhatnak az Üzenetek alkalmazás használatával. Csak a felhasználó kezdeményezheti a beszélgetést, és a vállalkozás csupán a felhasználó elhomályosított azonosítóját látja. A vállalkozás nem kapja meg a felhasználó telefonszámát, -címét vagy icloud-fiókadatait. Amikor a felhasználó az Apple-lel cseveg, az Apple a felhasználó Apple ID-jához társított Csevegés vállalkozásokkal azonosítóját kapja meg. A felhasználó dönti el, hogy szeretne-e kommunikálni. Ha a felhasználó törli a Csevegés vállalkozásokkal beszélgetést, azzal eltávolítja az Üzenetek alkalmazásból, és blokkolja a vállalkozást a felhasználónak küldött további üzenetekben. A vállalkozásnak küldött üzenetek egyesével titkosítva vannak a felhasználó eszköze és az Apple üzenetküldő szerverei között. Az Apple üzenetküldő szerverei visszafejtik az üzeneteket, és TLS segítségével továbbítják őket a vállalkozásnak. A vállalkozások válaszai hasonlóképpen TLS használatával érik el az Apple üzenetküldő szervereit, amelyek azután újból titkosítják az üzenetet a felhasználó eszköze számára. Csakúgy, mint az imessage esetén, az üzenetek legfeljebb 30 napig várólistára kerülnek az eszközökre való kézbesítéshez. 110

111 FaceTime A FaceTime az Apple video- és hanghívási szolgáltatása. Az imessage-hez hasonlóan a FaceTime-hívások is az Apple Push Notification szolgáltatást (APNs) használják, hogy létrehozzák a kezdeti kapcsolatot a felhasználó regisztrált eszközeivel. A FaceTimehívások hang-/videotartalmát végponttól végpontig tartó titkosítás védi, így csak a feladó és a címzett férhet hozzájuk. Az Apple nem tudja visszafejteni az adatokat. A kezdeti FaceTime-kapcsolat az Apple-szerverek infrastruktúráján keresztül épül fel; ezek továbbítják a felhasználók regisztrált eszközei között az adatcsomagokat. Az eszközök az átjátszott kapcsolaton APNs-értesítések és Session Traversal Utilities for NAT (STUN) üzenetek használatával ellenőrzik az identitástanúsítványaikat, és minden munkamenethez közös titkot hoznak létre. A közös titok használatával munkamenetkulcsokat származtatnak a Secure Real-time Transport Protocolt (SRTP) használó, streamelt médiacsatornákhoz. Az SRTP-csomagok Counter módú AES-256 és HMAC-SHA1 használatával vannak titkosítva. A FaceTime a kezdeti kapcsolat és biztonság beállítása után STUN és Internet Connectivity Establishment (ICE) segítségével alakítja ki a társközi kapcsolatot az eszközök között, ha lehetséges. A csoportos FaceTime funkcióval a FaceTime akár 33 résztvevőt is támogat egyszerre. A klasszikus kétszereplős FaceTime-hoz hasonlóan a hívások végponttól végpontig titkosítva vannak a meghívott résztvevők eszközei között. Azzal együtt, hogy a csoportos FaceTime a kétszereplős FaceTime infrastruktúrájának és kialakításának nagy részét felhasználja, a csoportos FaceTime-hívások egy új, kulcskialakító mechanizmussal rendelkeznek az Apple-identitásszolgáltatás (IDS) által biztosított hitelességen felül. Ez a protokoll sérülés utáni titkosságvédelmet kínál, azaz akkor sem kerülnek nyilvánosságra a korábbi hívások tartalmai, ha a felhasználó eszköze sérül. A munkamenetkulcsok AES-SIV használatával vannak titkosítva, és rövid élettartamú P-256 ECDH kulcsokkal rendelkező ECIESkonstrukció használatával vannak szétosztva a résztvevők között. Amikor új telefonszám vagy -cím adódik hozzá a folyamatban lévő csoportos FaceTime-híváshoz, az aktív eszközök új médiakulcsot alakítanak ki, és sosem osztják meg a korábban használt kulcsokat az újonnan meghívott eszközökkel. Lokátor A Lokátor funkció áttekintése A Lokátor alkalmazás az iphone keresése és a Barátok keresése alkalmazást egyesíti ios, ipados és macos rendszer esetén. A Lokátor képes segíteni a felhasználóknak az elveszett eszközök, még az offline Mac gépek megkeresésében is. Az online eszközök egyszerűen jelenthetik a helyzetüket a felhasználónak az icloudon keresztül. A Lokátor offline működésnél rövid Bluetooth-jeleket küld az elveszett eszközről, amelyeket a közelben használt Apple-eszközök képesek észlelni. Ezután ezek a közeli eszközök továbbküldik az elveszett eszköz észlelt helyzetét az icloudba, hogy a felhasználók megtalálhassák a Lokátor alkalmazásban. A folyamat alatt a részt vevő felhasználók személyes adatai végig védve vannak. A Lokátor még offline és alvó Mac géppel is működik. 111

112 A Bluetooth és a világ minden táján százmillió számra használt ios-, ipados- és macoseszközök segítségével a felhasználó megkeresheti a hiányzó eszközt, még ha az nem is képes Wi-Fi-re vagy mobilhálózatra csatlakozni. Minden olyan ios-, ipados- és macos-eszköz, amelyen az offline keresés be van kapcsolva a Lokátor beállításaiban, képes kereső eszközként működni. Ez azt jelenti, hogy az eszköz képes érzékelni egy másik, hiányzó offline eszközt Bluetooth segítségével, és azután a hálózati kapcsolata segítségével egy közelítő helyzetet tud jelenteni a tulajdonosnak. Amikor az eszközön be van kapcsolva az offline keresés, az azt is jelenti, hogy más résztvevők is megtalálhatják az eszközt ugyanilyen módon. Ez a teljes interakció végponttól végpontig titkosítva van, névtelen, és úgy tervezték, hogy takarékoskodjon az akkumulátor- és az adathasználattal, így csupán minimálisan befolyásolja az akkumulátor élettartamát, a mobiladat-előfizetést, valamint a felhasználói adatok is védve maradnak. Megjegyzés: Előfordulhat, hogy a Lokátor nem érhető el minden országban vagy régióban. Végponttól végpontig történő titkosítás a Lokátor funkcióban A Lokátor fejlett nyilvánoskulcs-titkosítási alapokra épül. Ha az offline keresés be van kapcsolva a Lokátor beállításaiban, akkor egy {d,p} jelölésű EC P-224 privát titkosítású kulcspár generálódik közvetlenül az eszközön; a d a privát kulcs, és a P nyilvános kulcs. Ezenkívül egy 256 bites SK 0 titok és egy i számláló van nullával inicializálva. A rendszer soha nem küldi el a privát kulcspárt és a titkot az Apple-nek, és csak a felhasználó többi eszközével van szinkronizálva az icloud-kulcskarikát használó, végponttól végpontig terjedő titkosítással. A titok és a számláló segítségével van származtatva az aktuális SK i szimmetrikus kulcs a következő rekurzív konstrukcióval: SK i = KDF(SK i-1, update ) Az SK i kulcs alapján a rendszer az u i és v i nagy, egész számokat számítja ki, ahol (u i,v i ) = KDF(SK i, diversify ). Ezután mind a d jelű P-224 privát kulcs, mind a hozzá kapcsolódó P jelű nyilvános kulcs affin transzformációval van származtatva; ahol két egész szám használatos a rövid élettartamú kulcspár kiszámításához: a származtatott privát kulcs a d i, ahol d i = u i * d + v i (a P-224 görbe sorrendjének modulója) és a hozzá kapcsolódó nyilvános rész a P i, amelynek kiértékelése P i = u i *P + v i *G. Amikor az eszköz elvész, és nem képes Wi-Fi-re vagy mobilhálózatra csatlakozni például egy parkban a padon felejtett MacBook, korlátozott ideig, Bluetooth-adatcsomagban rendszeres időközönként sugározni kezdi a származtatott P i nyilvános kulcsot. A P-224 használatával a nyilvános kulcs reprezentációja egyetlen Bluetooth-adatcsomagban elfér. A közelben lévő eszközök segíthetnek az offline eszköz megtalálásában azáltal, hogy a nyilvános kulcshoz titkosítják a saját helyzetüket. A nyilvános kulcs körülbelül 15 percenként újra cserélődik a számláló megnövelt értékét és a fenti folyamatot használva, így a felhasználó nem követhető állandó azonosítóval. A származtatási mechanizmus meggátolja, hogy a számos P i nyilvános kulcs azonos eszközhöz legyen kötve. 112

113 Hiányzó eszközök megkeresése a Lokátorban Minden olyan Apple-eszköz, amely Bluetooth-tartományon belül van, és be van rajta kapcsolva az offline keresés, képes észlelni ezt a jelet, és képes olvasni a sugárzott P i kulcsot. A kereső eszköz ECIES-konstrukcióval és a sugárzott P i nyilvános kulccsal titkosítja az aktuális helyinformációit, és továbbítja az Apple-nek. Ez a titkosított hely olyan szerverindexhez társul, amely a Bluetooth-adatcsomag P-224 P i nyilvános kulcsának SHA- 26 hasheként van kiszámítva. Az Apple soha nem rendelkezik a visszafejtési kulccsal, így az Apple nem képes elolvasni a kereső által titkosított helyet. A hiányzó eszköz tulajdonosa visszaállíthatja az indexet, és visszafejtheti a titkosított helyet. A mód, ahogy a Lokátor megkeresi az eszközöket. 113

114 A hiányzó eszköz keresésekor a rendszer megbecsüli a számlálóértékek várható tartományát a keresés időszakára. Az eredeti privát d P-224 kulcs és a keresési időszak számlálóértékeinek tartományára vonatkozó SK i titokértékek ismeretében a tulajdonos rekonstruálhatja a {d i, SHA-256(P i )} értékhalmazokat a teljes keresési időszakra vonatkozóan. A tulajdonosnak a hiányzó eszköz megkereséséhez használt eszköze ezután lekérdezést küldhet a szerverre az SHA-256(P i ) indexértékek halmazával, és letöltheti a titkosított helyeket. A Lokátor alkalmazás ezután helyben visszafejti a titkosított helyeket az egyező d i privát kulcsokkal, és az alkalmazáson belül megjeleníti a hiányzó eszköz közelítőleges helyét. A több kereső eszközről származó helyzetjelentéseket a tulajdonos alkalmazása kombinálja, hogy pontosabb helyzetet kaphasson. A mód, ahogy a tulajdonos megismeri az eszköz helyzetét a Lokátorból. Ha a felhasználó bekapcsolta az iphone keresése funkciót az eszközön, akkor az offline keresés alapértelmezés szerint bekapcsolódik, amikor ios 13, ipados 13.1, illetve macos rendszerre frissíti az eszközt. Ez gondoskodik arról, hogy minden felhasználónak a lehető legjobb esélye van, hogy megtalálja az eszközét, ha az elveszne. Ha azonban a felhasználó bármikor úgy dönt, hogy nem szeretne részt venni, kikapcsolhatja az offline keresést az eszköz Lokátor-beállításaiban. Ha az offline keresés ki van kapcsolva, az eszköz nem működik keresőként, és nem is észlelhető más kereső eszközök által. A felhasználó továbbra is megkeresheti az eszközt, ameddig az képes Wi-Fi-re vagy mobilhálózatra kapcsolódni. A felhasználók és eszközök névtelenségének megőrzése a Lokátorban Azon túlmenően, hogy a hely- és más adatok teljes mértékben titkosítva maradnak, a résztvevők személyazonossága is rejtve marad mind egymás, mind az Apple előtt. A kereső eszközök által az Apple-nek küldött adatforgalom nem tartalmaz hitelesítési információt sem a tartalmi, sem a fejléc részben. Ennek eredményeképpen az Apple nem ismeri sem a kereső személyét, sem a megtalált eszköz tulajdonosát. Az Apple nem naplóz továbbá olyan információt, amely felfedné a kereső személyazonosságát, és nem tart meg olyan információt, amely segítségével bárki kapcsolatba hozhatná egymással a keresőt és a tulajdonost. Az eszköz tulajdonosa csak a titkosított helyinformációt kapja meg; ezt a Lokátor alkalmazás visszafejti és megjeleníti, de nem jelzi, hogy ki találta meg az eszközt. 114

115 Offline eszközök megtekintése a Lokátorban Amikor valaki megtalál egy hiányzó offline eszközt, a felhasználó értesítést és t kap arról, hogy az eszközt megtalálták. A felhasználó a Lokátor alkalmazás megnyitásával és az Eszközök lap kiválasztásával tekintheti meg a hiányzó eszköz helyét. A Lokátor nem üres térképen jeleníti meg az eszközt, mint ahogy a megtalálás előtt tette volna, hanem térképhelyet jelenít meg közelítő címmel és az eszköz észlelése óta eltelt időt. Ha további helyzetjelentések érkeznek, az aktuális hely és időbélyegző automatikusan frissül. A felhasználók nem tudnak ugyan hangot lejátszani offline eszközön, sem távolról törölni nem képesek, viszont a helyadatokkal visszakövethetik a lépéseiket, vagy más műveletet is elvégezhetnek a visszaszerzésért. Átjárhatóság Az Átjárhatóság áttekintése Az Átjárhatóság az olyan technológiák, mint az icloud, a Bluetooth és a Wi-Fi segítségével teszi lehetővé, hogy a felhasználók az egyik eszközön elkezdett tevékenységet egy másikon folytathassák; telefonhívásokat kezdeményezzenek és fogadjanak, szöveges üzenetek küldjenek és fogadjanak, és megosszák a mobilinternet-kapcsolatot. Handoff Ha a felhasználó ios-, ipados- és macos-eszközei egymáshoz közel vannak, akkor a Handoff segítségével átadhatja egyik eszközről a másikra azt, amin éppen dolgozik. A Handoff segítségével a felhasználók az eszközváltás után azonnal folytathatják a munkát. Amikor a felhasználó bejelentkezik az icloudba egy másik Handoff-kompatibilis eszközön, a két eszköz sávon kívüli Bluetooth Low Energy (BLE) 4.2 párosítást alakít ki APNs használatával. Az egyes üzenetek titkosítása hasonlít ahhoz, ahogy az üzenetek az imessage-ben vannak titkosítva. Az eszközök párosítása után minden eszköz szimmetrikus 256 bites AES-kulcsot generál, amely az eszköz kulcskarikáján tárolódik. Ez a kulcs visszajátszást gátló lépésekkel együtt képes GCM módú AES-256 módszerrel titkosítani és hitelesíteni azokat a BLE-hirdetményeket, amelyek az icloudon keresztül párosított más eszközöknek kommunikálják az eszköz aktuális tevékenységét. Amikor az eszköz első alkalommal fogad egy új kulcstól hirdetményt, BLE-kapcsolatot alakít ki a küldő eszközzel, és hirdetménytitkosítási kulcsegyeztetést hajt végre. Ez a kapcsolat normál BLE 4.2 titkosítással az egyes üzenetek titkosításával van védve; ez a folyamat hasonló ahhoz, ahogy az imessage titkosítva van. Bizonyos helyzetekben az üzenetek küldése APNs használatával történik, nem pedig BLE-vel. A tevékenység-adatcsomag védelme és átvitele az imessage-dzsel azonos módon történik. Handoff natív alkalmazások és webhelyek között A Handoff lehetővé teszi, hogy a natív ios-, ipados- és macos-alkalmazások az alkalmazásfejlesztő által szabályszerűen irányított doménekben található webhelyeken folytathassák a felhasználói tevékenységet. Lehetővé teszi továbbá, hogy a natív alkalmazás felhasználói tevékenysége webböngészőben folytatódjon. 115

116 Annak érdekében, hogy a natív alkalmazások ne folytathassák a tevékenységet a nem a fejlesztő által irányított webhelyeken, az alkalmazásnak bizonyítania kell a szabályszerű irányítást azon a webdoménen, ahol folytatni szeretné a tevékenységet. A webhely doménje feletti irányítás a megosztott webes hitelesítő adatok mechanizmusának használatával alakul ki. További részletek: Alkalmazások hozzáférése a mentett jelkódokhoz. A rendszernek hitelesítenie kell az alkalmazás doménnév feletti irányítását, mielőtt az alkalmazás engedélyt kapna a felhasználói tevékenység Handoffjának elfogadásához. A weboldal Handoffjának a forrása bármely olyan böngésző lehet, amely adoptálta a Handoff API-kat. Amikor a felhasználó weboldalt tekint meg, a rendszer a titkosított Handoff-hirdetmény bájtjaiban hirdeti meg a domén nevét. Csak a felhasználó többi eszköze képes visszafejteni a hirdetmény bájtjait. A fogadó eszközön a rendszer észleli, hogy egy telepített natív alkalmazás Handoffot fogad a hirdetett doménnévtől, és Handoff-lehetőségként megjeleníti a natív alkalmazás ikonját. A natív alkalmazás indításkor megkapja a teljes URL-címet és a weboldal címét. Más információ nem jut át a böngészőből a natív alkalmazásba. Ellenkező irányban viszont a natív alkalmazás megadhat tartalék URL-címet arra az esetre, ha a Handoffot fogadó eszközön nincs telepítve ugyanaz a natív alkalmazás. Ebben az esetben a rendszer a felhasználó alapértelmezett böngészőjét jeleníti meg a Handoffalkalmazás lehetőségeként (ha az adott böngésző adoptálta a Handoff API-kat). Handoffkérelem esetén a böngésző elindul, és megkapja a forrásalkalmazás által megadott tartalék URL-címet. Nincs korlátozás arra vonatkozóan, hogy a tartalék URL-cím csak a natív alkalmazás fejlesztője által irányított doménnéven lehet. Nagyobb adatmennyiségek Handoffja A Handoff alapvető funkcióin túl bizonyos alkalmazások használhatnak olyan API-kat, amelyek támogatják nagyobb adatmennyiségek küldését az Apple által létrehozott társközi Wi-Fi-technológiával (az AirDrophoz hasonló módon). A Mail alkalmazás például ilyen APIval támogatja a nagy mellékleteket tartalmazó levélpiszkozatok Handoffját. Amikor egy alkalmazás ezt a lehetőséget használja, a két eszköz közötti egyeztetés ugyanúgy indul, mint a Handoff esetében. A fogadó eszköz azonban, miután megkapta a kezdeti adatcsomagot Bluetooth Low Energy (BLE) használatával, új kapcsolatot kezdeményez Wi-Fi-n keresztül. A kapcsolat titkosítva van (TLS-sel), ami egyezteti az icloud-identitásaik tanúsítványait. A tanúsítványokban szereplő identitást a rendszerek a felhasználó identitásával ellenőrzik. Az adatcsomag további adatai ezen a titkosított kapcsolaton keresztül mennek az átvitel befejezéséig. Univerzális vágólap Az Univerzális vágólap a Handoffot használja, hogy biztonságosan átvigye a felhasználó vágólapjának tartalmát az eszközök között, így a felhasználó másolhat tartalmat az egyik eszközön, és beillesztheti a másikon. A tartalom védelme ugyanolyan módon történik, mint más Handoff-adatok esetén, és alapértelmezés szerint meg van osztva az Univerzális vágólappal, hacsak az alkalmazásfejlesztő nem tiltotta le a megosztást. Az alkalmazások hozzáférnek a vágólap adataihoz, függetlenül attól, hogy a felhasználó beillesztette-e a vágólapot az alkalmazásba. Az Univerzális vágólappal ez a hozzáférés ki van terjesztve a felhasználó többi eszközén lévő alkalmazásra (az icloud-bejelentkezés szerint). 116

117 iphone-mobilhívás továbbítása Ha a felhasználó Mac gépe, ipadje, ipod toucha vagy HomePodja az iphone-jával azonos Wi-Fi-hálózaton van, akkor az eszköz képes telefonhívásokat kezdeményezni és fogadni az iphone mobiladat-kapcsolatán keresztül. A konfigurációhoz az eszközöknek azonos Apple ID-fiókkal kell bejelentkezniük mind az icloudba, mind a FaceTime-ba. Bejövő hívás érkezésekor az összes konfigurált eszköz értesítést kap az Apple Push Notification szolgáltatás (APNs) segítségével, és mindegyik értesítés az imessage-ével azonos, végponttól végpontig történő titkosítást használ. Az azonos hálózaton lévő eszközök a bejövő hívás felhasználói felületét jelenítik meg. A hívás fogadásakor a hang zökkenőmentesen átkerül a felhasználó iphone-járól a két eszköz közötti biztonságos társközi kapcsolat használatával. Amikor az egyik eszköz fogadja a hívást, a közelben lévő, iclouddal párosított eszközök csengése abbamarad a Bluetooth Low Energy (BLE) protokollon keresztüli hirdetés használatával. A hirdetés bájtjait ugyanaz a metódus titkosítja, mint a Handoff hirdetéseit. A kimenő hívások is zökkenőmentesen továbbítódnak az iphone-ra az APNs segítségével, és a hang hasonlóképpen halad át az eszközök közötti biztonságos társközi kapcsolaton. A felhasználó letilthatja a telefonhívás továbbítását, ha kikapcsolja az Phone-mobilhívások lehetőséget a FaceTime beállításaiban. Az iphone Üzenettovábbítás funkciója Az Üzenettovábbítás automatikusan átküldi az iphone-ra érkező SMS-üzeneteket a felhasználó regisztrált ipadjére, ipod touchára vagy Mac gépére. Minden eszköznek ugyanazzal az Apple ID-fiókkal kell bejelentkeznie az imessage szolgáltatásba. Ha az Üzenettovábbítás be van kapcsolva, a regisztráció automatikus a felhasználó megbízhatósági körébe tartozó eszközein, ha a kétlépéses hitelesítés be van kapcsolva. Ellenkező esetben a regisztrációt minden eszközön ellenőrizni kell az iphone által generált, véletlenszerű, hat számjegyű numerikus kóddal. Az eszközök összekapcsolása után az iphone titkosítja a bejövő SMS-üzeneteket, és továbbítja minden egyes eszközre, az imessage részben leírt módszer segítségével. A válaszok az iphone-ra érkeznek, ugyanezzel a módszerrel, majd az iphone a választ szöveges üzenetként küldi el a szolgáltató SMS-továbbítási mechanizmusával. Az Üzenettovábbítás az Üzenetek beállításaiban kapcsolható be és ki. Instant Hotspot Az Instant Hotspotot támogató ios- és ipados-eszközök Bluetooth Low Energy (BLE) segítségével fedezik fel az azonos icloud-fiókba vagy a Családi megosztással használt fiókokban (ios 13 és ipados rendszeren) bejelentkezett eszközöket, illetve ennek segítségével kommunikálnak. Az OS X és újabb verziójú kompatibilis Mac gépek ugyanezzel a technológiával fedezik fel az Instant Hotspotot használó ios- és ipadoseszközöket, illetve ennek segítségével kommunikálnak. 117

118 Amikor a felhasználó először megnyitja a Wi-Fi beállításait egy eszközön, az eszköz BLE-hirdetményt bocsát ki, amely tartalmaz egy olyan azonosítót, amelyben az azonos icloud-fiókba bejelentkezett minden eszköz megegyezik. Az azonosító az icloud-fiókhoz kapcsolt és rendszeresen váltogatott DSID-ből (Destination Signaling Identifier céljelzési azonosító) generálódik. Amikor az azonos icloud-fiókba bejelentkezett más eszközök kellő közelségben vannak, és támogatják a személyes hotspotot, érzékelik a jelet, és válaszukban jelzik, hogy készen állnak az Instant Hotspot használatára. Amikor egy Családi megosztásban nem szereplő felhasználó kiválasztja az iphone-t vagy ipadet a személyes hotspot céljaként, a személyes hotspot bekapcsolására vonatkozó kérelem érkezik az eszközre. A kérelem BLE-titkosítást használó kapcsolaton keresztül érkezik, és a kérelem az imessage-titkosításhoz hasonlóan van titkosítva. Az eszköz ekkor ugyanazon a BLE-kapcsolaton keresztül ugyanazt az üzenetalapú titkosítást használva válaszol a személyes hotspot kapcsolatadataival. A Családi megosztásban lévő felhasználóknál a Személyes hotspot kapcsolati információi biztonságosan vannak megosztva egy olyan módszerrel, amely hasonlít a HomeKiteszközök által az információk szinkronizálásához használt módszerhez. A felhasználók között hotspotinformációkat megosztó kapcsolat egy ECDH (Curve25519) ideiglenes kulccsal van titkosítva, amely a felhasználó vonatkozó eszközspecifikus Ed25519 nyilvános kulcsaival van hitelesítve. A használt nyilvános kulcsok azok a kulcsok, amelyek előzőleg az IDS-szel szinkronizálva lettek a Családi megosztás tagjai között a Családi megosztás létrehozásakor. 118

119 Hálózati biztonság A hálózati biztonság áttekintése Apple-eszközökön tárolt adatok védelme érdekében az Apple által beépített védelmi rendszereken túl a szervezetek számos intézkedést is tehetnek, amellyel védhetik az eszközök között haladó információkat. Ezen védelmi lépések összessége a hálózati biztonság körébe tartozik. A felhasználóknak el kell érniük a vállalati hálózatokat a világ minden tájáról, így gondoskodni kell arról, hogy van jogosultságuk, és az adataik védettek az átvitel során. Ezen biztonsági célok elérése érdekében az ios, ipados és macos integrálja a bizonyított technológiákat és a legújabb szabványokat mind a Wi-Fi-, mind a mobiladat-alapú hálózati kapcsolatok számára. Ezért van az, hogy az operációs rendszereink szabványos hálózati protokollokat használnak a hitelesített, jogosultságokkal ellátott és titkosított kommunikációhoz, és ezekhez fejlesztői hozzáférést is biztosítanak. TLS hálózati biztonság Az ios, az ipados és a macos támogatja a Transport Layer Security (TLS v1.0, TLS v1.1, TLS v1.2, TLS v1.3) és a Datagram Transport Layer Security (DTLS) protokollt. A TLS-protokoll támogatja az AES-128 és az AES-256 titkosítást, és a sérülés utáni titkosságvédelemmel rendelkező titkosítási készleteket részesíti előnyben. Az olyan internetes alkalmazások, mint a Safari, a Naptár és a Mail, automatikusan ezzel a protokollal engedélyezik az eszköz és a hálózati szolgáltatások közötti titkosított kommunikációs csatornát. A magas szintű API-k (mint a CFNetwork) megkönnyítik a fejlesztők számára a TLS adaptálását az alkalmazásaikban, míg az alacsony szintű API-k (Network.framework) finomra hangolt szabályozást biztosítanak. A CFNetwork nem engedélyezi az SSL v3 verziót, és a WebKitet használó alkalmazások (például a Safari) nem hozhatnak létre SSLv3-kapcsolatot. 119

120 ios 11 és újabb, illetve macos és újabb esetén az SHA-1 tanúsítványok már nincsenek engedélyezve TLS-kapcsolatokhoz, hacsak a felhasználó meg nem bízik azokban. A 2048 bitnél rövidebb RSA-kulcsot tartalmazó tanúsítványok nincsenek engedélyezve. Az RC4 szimmetrikus titkosítási készlet elavult az ios 10 és a macos verzióban. Alapértelmezés szerint a Secure Transport API-kkal implementált TLSklienseken és -szervereken nincs engedélyezve az RC4 titkosítási készlet, és nem tudnak kapcsolódni, ha az RC4 az egyetlen elérhető titkosítási készlet. A nagyobb biztonság érdekében az RC4-et megkövetelő szolgáltatásokat és alkalmazásokat frissíteni kell modern, biztonságos titkosítási készlet használatához. ios 12.1 rendszeren a október 15. után a rendszer által megbízhatónak tartott gyökértanúsítványból kiadott tanúsítványokat naplózni kell megbízható tanúsítvány-átláthatósági naplóban, hogy a TLS-kapcsolatok engedélyezve legyenek. ios 12.2 esetén a TLS 1.3 alapértelmezés szerint engedélyezve van a Network.framework és NSURLSession API-k számára. A Secure Transport API-kat használó TLS-kliensek nem használhatják a TLS 1.3 verziót. Alkalmazás-átviteli biztonság Az alkalmazás-átviteli biztonság megadja az alapértelmezett kapcsolati követelményeket, így az alkalmazások a bevált gyakorlatokhoz tartják magukat a biztonságos kapcsolatok érdekében, amikor az SURLConnection, CFURL vagy NSURLSession APIkat használják. Alapértelmezés szerint az alkalmazás-átviteli biztonság korlátozza a titkosítás kiválasztását, hogy csak a sérülés utáni titkosságvédelmet biztosító készletek szerepeljenek, nevezetesen az ECDHE_ECDSA_AES és az ECDHE_RSA_AES GCM vagy CBC módban. Az alkalmazások kikapcsolhatják a sérülés utáni titkosságvédelmet doménenként; ebben az esetben a rendszer hozzáadja az RSA_AES algoritmust az elérhető titkosítások készletéhez. A szervereknek támogatniuk kell a TLS v1.2 verziót és a sérülés utáni titkosságvédelmet, a tanúsítványoknak pedig érvényesnek kell lenniük, és SHA-256 vagy erősebb aláírással kell rendelkezniük, legalább 2048 bites RSA-kulccsal vagy 256 bites elliptikus görbe típusú kulccsal. Az ezeknek a követelményeknek meg nem felelő hálózati kapcsolatok nem jönnek létre, hacsak az alkalmazás felül nem vezérli az alkalmazás-átviteli biztonságot. Az érvénytelen tanúsítványok mindig azonnali hibával és a kapcsolat megszakadásával járnak. Az alkalmazás-átviteli biztonság automatikusan érvényes az ios 9 vagy újabb és a macos vagy újabb rendszerhez összeállított alkalmazásokra. 120

121 A tanúsítványok érvényességének ellenőrzése A TLS-tanúsítvány megbízható állapotának kiértékelése a kialakított iparági szabványok szerint történik, ahogy az RFC 5280 szabványban le van írva, és magában foglalja az olyan elterjedőben lévő szabványokat, mint az RFC 6962 (Tanúsítványok átláthatósága). ios 11 és újabb, illetve macos és újabb rendszer esetén az Apple-eszközök rendszeresen frissülnek a visszahívott és korlátozott tanúsítványok listájával. A lista alapját a tanúsítvány-visszahívási listák (CRL-ek) képezik, amelyeket az Apple által megbízhatónak tartott, beépített gyökértanúsítvány-kibocsátók, valamint alárendelt tanúsítványkibocsátóik tesznek közzé. A lista tartalmazhat az Apple által meghatározott korlátozásokat is. A rendszer lekérdezi ezt az információt, amikor hálózati API-függvény hoz létre biztonságos kapcsolatot. Ha túl sok visszahívott tanúsítvány van egy tanúsítványkibocsátó esetén ahhoz, hogy egyesével szerepeljenek a listán, a megbízhatóság kiértékelése megkövetelhet helyette a tanúsítvány állapotára vonatkozó online választ (OCSP), és ha a válasz nem érhető el, a megbízhatóság kiértékelése sikertelen lesz. Virtuális magánhálózatok (VPN-ek) A biztonságos hálózati szolgáltatások, mint a virtuális magánhálózat használata jellemzően minimális beállítást és konfigurációt igényel, hogy használható legyen az ios-, ipados- és macos-eszközökön. Ezek az eszközök használhatók az olyan VPN-szerverekkel, amelyek támogatják a következő protokollokat és hitelesítési módszereket: IKEv2/IPSec közös titokkal végzett hitelesítéssel, RSA-tanúsítványok, ECDSAtanúsítványok, EAP-MSCHAPv2 vagy EAP-TLS SSL-VPN az App Store-ból származó megfelelő kliensalkalmazás használatával L2TP/IPSec MS-CHAPV2 jelszó általi hitelesítéssel és közös titok általi (ios, ipados és macos), illetve RSA SecurID vagy CRYPTOCard általi (csak macos) számítógéphitelesítéssel Cisco IPSec jelszó, RSA SecurID vagy CRYPTOCard általi felhasználó-hitelesítéssel és közös titok és tanúsítványok általi számítógép-hitelesítéssel (csak macos) Az ios, ipados és a macos a következőket támogatja: Igény szerinti VPN: Tanúsítványalapú hitelesítést használó hálózatokhoz. Az ITirányelvek VPN-konfigurációs profillal határozzák meg, hogy mely doménekhez szükséges VPN-kapcsolat. Alkalmazásonkénti VPN: A VPN-kapcsolatok részletesebb szabályozhatóságáért. A mobileszköz-felügyeleti (MDM) megoldások minden egyes kapcsolathoz és megadott doménekhez meghatározhatnak kapcsolatot a Safariban. Ezzel elérhető, hogy a biztonságos adatok mindig a vállalati hálózaton mennek és a felhasználó személyes adatai nem. 121

122 Mindig bekapcsolt VPN: Konfigurálható MDM-megoldáson keresztül felügyelt és az Apple Configurator 2, Apple School Manager vagy Apple Business Manager alkalmazáson keresztül koordinált eszközökhöz. Ennek köszönhetően a felhasználónak nem szükséges bekapcsolni a VPN-t a védelem aktiválásához, amikor mobiladatvagy Wi-Fi-hálózatra csatlakozik. A mindig bekapcsolt VPN segítségével a szervezet teljes mértékben vezérelheti az eszközön bonyolított forgalmat azáltal, hogy minden IP-forgalmat a szervezethez irányít. Az alapértelmezett alagútprotokoll, az IKEv2 adattitkosítással teszi biztonságossá az átvitelt. A szervezet figyelheti az eszközein a bejövő és kimenő forgalmat, biztonságossá teheti az adatait a hálózatán belül, és korlátozhatja az eszközök internetelérését. Wi-Fi-biztonság Protokollbiztonság Minden Apple-platform támogatja az iparági szabványnak minősülő Wi-Fi-hitelesítési és -titkosítási protokollokat, hogy hitelesített hozzáférést és megbízhatóságot nyújtson, amikor a következő, biztonságos vezeték nélküli hálózatokhoz csatlakozik. WPA2 Personal WPA2 Enterprise WPA2/WPA3 Transitional WPA3 Personal WPA3 Enterprise WPA3 Enterprise 192 bites biztonság A WPA2 és WPA3 hitelesítik az összes kapcsolatot, és 128 bites AES titkosítást nyújtanak, hogy a vezeték nélkül küldött adatok megbízhatók maradjanak. Ezzel a felhasználók a legmagasabb szinten biztosíthatják, hogy az adataik védettek maradnak a kommunikációk Wi-Fi-hálózaton keresztüli küldése és fogadása közben. A WPA3 a következőkön van támogatva: iphone 7 vagy újabb 5. generációs ipad vagy újabb Apple TV 4K vagy újabb modell Apple Watch Series 3 vagy újabb A ac és újabb szabványú, 2013 végi és újabb Mac gépek Az újabb eszközök támogatják a WPA3 Enterprise 192 bites biztonságú hitelesítést (beleértve a 256 bites AES titkosítás támogatását), amikor kompatibilis, vezeték nélküli hozzáférési pontokhoz csatlakoznak. Ez még erősebb adatvédelmet nyújt, amikor a forgalom a vezeték nélküli hálózaton zajlik. A WPA3 Enterprise 192 bites biztonság támogatva van az iphone 11, az iphone 11 Pro, az iphone 11 Pro Max és az újabb ios- és ipados-eszközökön. Azon túl, hogy védi a vezeték nélkül küldött adatokat, az Apple-platformok kiterjesztik a WPA2 és WPA3 szintű védelmet egyéni és csoportos küldésű kezelési keretekre a w szabványban definiált Protected Management Frame (védett felügyeleti keret PMF) szolgáltatáson keresztül. A PMF-támogatás a következőkön érhető el: 122

123 iphone 6 és újabb ipad Air 2 vagy újabb 4. generációs vagy újabb Apple TV Apple Watch Series 3 vagy újabb A ac és újabb szabványú, 2013 végi és újabb Mac gépek A 802.1X támogatásával az Apple-eszközök a RADIUS hitelesítési környezetek széles skálájába integrálhatók. A támogatott 802.1X vezeték nélküli hitelesítési módok: EAP-TLS, EAP-TTLS, EAP-FAST, EAP-SIM, PEAPv0 és PEAPv1. Elavult protokollok Az Apple-termékek a következő elavult Wi-Fi hitelesítési és titkosítási protokollokat támogatják: WEP Open, 40 és 104 bites kulcsokkal WEP Shared, 40 és 104 bites kulcsokkal Dinamikus WEP Ideiglenes kulcsintegritás protokoll (TKIP) WPA WPA/WPA2 Transitional Ezek a protokollok már nem tekinthetők biztonságosnak, és nem célszerű használni ezeket kompatibilitási, megbízhatósági, teljesítményre vonatkozó és biztonsági okokból. Csak a visszamenőleges kompatibilitás miatt vannak támogatva, és a jövőbeli szoftververziókból kikerülhetnek. Minden Wi-Fi-implementációt rendkívül ajánlott WPA3 Personal vagy WPA3 Enterprise protokollra cserélni, hogy a létező legrobusztusabb, legbiztonságosabb és leginkább kompatibilis legyen a Wi-Fi-kapcsolat. Wi-Fi-adatvédelem MAC-cím randomizálása Az Apple-platformok randomizált közegelérés-vezérlési (MAC) címet használnak, amikor Wi-Fi-hálózathoz nem csatlakozva szkennelik a Wi-Fi-t. Ezek a szkennelések használhatók ismert Wi-Fi-hálózat megkeresésére, és a hozzá való csatlakozásra, vagy a Helymeghatározás segítésére a földrajzi korlátozást használó alkalmazások esetén, mint például a helyalapú emlékeztetők, vagy hely rögzítése az Apple Térképek alkalmazásban. Nincsenek randomizálva azok a Wi-Fi-szkennelések, amelyek egy előnyben részesített Wi- Fi-hálózathoz való csatlakozáskor történnek. Az Apple-platformok olyan esetben is randomizált MAC-címet használnak, amikor az előnyben részesített hálózatok bővített kiürítési (epno) szkennelését végzi, amikor az eszköz nincs társítva Wi-Fi-hálózathoz, vagy ha a processzora alszik. Az epnoszkennelések olyankor futnak, amikor az eszköz a Helymeghatározást használja a földrajzi korlátozást használó alkalmazások esetén, mint például a helyalapú emlékeztetők, vagy hely rögzítése az Apple Térképek alkalmazásban. 123

124 Mivel az eszköz MAC-címe módosul, amikor leválasztódik a Wi-Fi-hálózatról, a cím nem használható az eszköz állandó követésére a Wi-Fi-forgalom passzív megfigyelőivel, még ha az eszköz mobilhálózathoz kapcsolódik is. Az Apple tájékoztatta a Wi-Fi-gyártókat arról, hogy az ios- és ipados Wi-Fi-szkennelései randomizált MAC-címet használnak, és sem az Apple, sem a gyártók nem képesek előre megjósolni ezeket a randomizált MAC-címeket. A Wi-Fi MAC-címek randomizálása támogatva van az iphone 5 és újabb verziókon. Wi-Fi-keretsorrend számainak randomizálása A Wi-Fi-keretek sorszámot is tartalmaznak; ezt használja az alacsony szintű protokoll a hatékony és megbízható Wi-Fi-kommunikációhoz. Mivel ezek a sorszámok minden egyes átvitt kerettel növekednek, használhatók arra, hogy a Wi-Fi-szkennelések közben átvitt információkat az azonos eszköz által átvitt más keretekkel összekapcsolják. Ennek kivédése érdekében az Apple-eszközök randomizálják a sorszámokat, amikor a MAC-cím új, randomizált címre módosul. Ebbe beletartozik a sorszámok randomizálása minden olyan új szkennelési kérés esetén, amely akkor inicializálódik, amikor az eszköz nincs társítva. A randomizáció a következő eszközökön van támogatva: iphone 7 vagy újabb 5. generációs ipad vagy újabb Apple TV 4K vagy újabb modell Apple Watch Series 3 vagy újabb imac Pro (Retina 5K, 27 hüvelykes, 2017) vagy újabb modell MacBook Pro (13 hüvelykes, 2018) vagy újabb modell MacBook Pro (15 hüvelykes, 2018) vagy újabb modell MacBook Air (Retina, 13 hüvelykes, 2018) vagy újabb modell Mac mini (2018) vagy újabb modell imac (Retina 4K, 21,5 hüvelykes, 2019) vagy újabb modell imac (Retina 5K, 27 hüvelykes, 2019) vagy újabb modell Mac Pro (2019) vagy újabb modell Wi-Fi-kapcsolatok és rejtett hálózatok Kapcsolatok Az Apple randomizált MAC-címeket generál az AirDrophoz és AirPlayhez használt társközi Wi-Fi-kapcsolatokhoz. A rendszer randomizált címet használ (SIM-kártyával rendelkező) ios- és ipados-eszközök esetén a személyes hotspothoz, illetve macos esetén az internetmegosztáshoz. Az ilyen hálózati interfészek indításakor új, véletlenszerű címek generálódnak, és szükség szerint egymástól független egyedi címeket generál a rendszer az egyes interfészekhez. 124

125 Rejtett hálózatok A Wi-Fi-hálózatokat a szolgáltatáskészlet-azonosítónak (SSID) nevezett hálózati név azonosítja. Bizonyos Wi-Fi-hálózatok úgy vannak konfigurálva, hogy elrejtsék az SSID-jüket, ami azt jelenti, hogy a vezeték nélküli hozzáférési pont nem teszi közzé a hálózat nevét. Ezeket rejtett hálózatoknak nevezik. Az iphone 6s és az újabb verziók automatikusan észlelik, ha a hálózat rejtett. Ha a hálózat rejtett, az ios- és ipados-eszköz olyan próbát küld, amelynek a kérelmében szerepel az SSID ellenkező esetben nem. Ez megakadályozza, hogy az eszköz sugározza olyan rejtett hálózatok nevét, amelyekhez a felhasználó korábban már csatlakozott, így még jobban gondoskodik az adatvédelemről. A rejtett hálózatok okozta adatvédelmi problémák csökkentése érdekében az iphone 6s és újabb verziók automatikusan észlelik, ha a hálózat rejtett. Ha a hálózat nem rejtett, az iosés ipados-eszköz nem küld olyan próbát, amelynek a kérelmében szerepel az SSID. Ezzel megakadályozza, hogy közzétegye az ismert, nem rejtett hálózatok nevét, és így rejtve marad, hogy azokat a hálózatokat keresi. Platformvédelmek Az Apple operációs rendszerek védik az eszközt a hálózati processzor firmware-jének sérülékenysége ellen; a hálózatvezérlők, beleértve a Wi-Fi-t, csak korlátozottan férnek hozzá az alkalmazásprocesszor memóriájához. Amikor USB vagy SDIO van használatban interfészként a hálózati processzorral, a hálózati processzor nem inicializálhat közvetlen memóriaelérésű (DMA) tranzakciókat az alkalmazásprocesszor felé. PCIe használata esetén minden egyes hálózati processzor a saját, elszigetelt PCIebuszán van. A PCIe-buszon lévő IOMMU tovább korlátozza a hálózat DMA-hozzáférését, hogy csak a saját hálózati csomagjait és ellenőrzési struktúráit tartalmazó memóriához és erőforrásokhoz férjen hozzá. Bluetooth-biztonság Az Apple-eszközök kétféle Bluetooth-technológiát használnak: Bluetooth Classic és Bluetooth Low Energy (BLE). A Bluetooth-biztonsági modell mindkét verzió esetén a következő kiemelt biztonsági funkciókkal rendelkezik: Párosítás: Egy vagy több, megosztott titokkal rendelkező kulcs létrehozásának folyamata Kötés: A párosítás során létrehozott kulcsok tárolása, hogy a következő kapcsolódások során is használhatók legyenek, és így megbízható eszközpár alakuljon ki Hitelesítés: Annak ellenőrzése, hogy a két eszköz azonos kulcsokkal rendelkezik Titkosítás: Az üzenet megbízhatósága Üzenetintegritás: Az üzenetek hamisítása elleni védelem Biztonságos egyszerű párosítás: A passzív lehallgatás elleni védelem, és közbeékelődéses (MITM) típusú támadás elleni védelem A Bluetooth 4.1 verziója hozzáadta a biztonságos kapcsolatok funkciót a BR/EDR fizikai átvitelekhez. A biztonsági funkciók az összes típusú Bluetooth esetében a következők: 125

126 Támogatás Bluetooth Classic Bluetooth Low Energy Párosítás P-256 elliptikus görbe FIPS által jóváhagyott algoritmusok (AES-CMAC és P-256 elliptikus görbe) Kötés Hitelesítés Titkosítás Üzenetintegritás Biztonságos egyszerű párosítás: Védelem a passzív lehallgatás ellen A párosítási információk biztonságos helyen tárolódnak az ios-, ipados-, macos-, tvos- és watchos-eszközökön FIPS által jóváhagyott algoritmusok (HMAC-SHA-256 és AES-CTR) AES-CCM kriptográfia a vezérlőben végrehajtva AES-CCM használata az üzenetintegritás céljára Elliptikus görbe Diffie-Hellmancsere (ECDHE) A párosítási információk biztonságos helyen tárolódnak az ios-, ipados-, macos-, tvos- és watchos-eszközökön FIPS által jóváhagyott algoritmusok AES-CCM kriptográfia a vezérlőben végrehajtva AES-CCM használata az üzenetintegritás céljára Elliptikus görbe Diffie-Hellmancsere (ECDHE) Biztonságos egyszerű párosítás: A közbeékelődéses (MITM) típusú támadások elleni védelem Két, felhasználó által támogatott numerikus módszer: numerikus összehasonlítás vagy jelkulcsbevitel Két, felhasználó által támogatott numerikus módszer: numerikus összehasonlítás vagy jelkulcsbevitel A párosításhoz felhasználói válasz szükséges, beleértve az összes nem MITM párosítási módot Bluetooth 4.1 és újabb 2015 végi imac és újabb MacBook Pro 2015 eleje és újabb ios 9 és újabb ipados 13.1 és újabb macos és újabb tvos 9 és újabb watch OS 2.0 és újabb Bluetooth 4.2 és újabb iphone 6 és újabb ios 9 és újabb ipados 13.1 és újabb macos és újabb tvos 9 és újabb watch OS 2.0 és újabb Adatvédelem a Bluetooth Low Energy esetében A felhasználói adatok védelme érdekében a BLE rendelkezik a következő két funkcióval: címek randomizációja és átviteleket átfogó kulcsszármaztatás. A címrandomizáció csökkenti annak a lehetőségét, hogy a BLE-eszközt hosszú időn át lehessen követni, azáltal, hogy rendszeres időközönként módosítja a Bluetooth-eszköz címét. Ahhoz, hogy az ezt az adatvédelmi funkciót használó eszköz újra tudjon csatlakozni az ismert eszközökhöz, az eszköz címének, vagyis a privát címnek a másik eszköz által feloldhatónak kell lenni. A privát cím generálása az eszköz feloldó identitáskulcsával (IRK) történik, amelyet a párosítási folyamat során egyeztet. 126

127 Az ios 13 és az ipados 13.1 képes az átviteleket átfogóan származtatni a csatolókulcsokat. A BLE segítségével generált csatolókulcs például használható Bluetooth Classic csatolókulcs származtatására. Az Apple ezenkívül hozzáadta a Bluetooth Classic felől a BLE felé irányuló támogatást olyan eszközök esetén, amelyek támogatják a Bluetooth Core Specification 4.1 verzióban bevezetett Secured Connections funkciót (lásd a Bluetooth Core Specification 5.1 szabványt). Ultraszéles sávú technológia Az Apple által tervezett új U1 chip ultraszéles sávú technológiát használ a térbeli tudatossághoz ennek segítségévél az iphone 11, az iphone 11 Pro és az iphone 11 Pro Max képes az U1-gyel szerelt Apple-eszközök helyét pontosan meghatározni. Az ultraszéles sávú technológia a más támogatott Apple-eszközökben is megtalálható technológiával randomizálja az adatokat: A MAC-címek randomizálása más támogatott Apple-eszközökhöz hasonlóan Wi-Fi-keretsorrend számainak randomizálása Egyszeri bejelentkezés Egyszeri bejelentkezés Az ios és az ipados a vállalati hálózatokban történő hitelesítést az egyszeri bejelentkezéssel (SSO) támogatja. Az SSO használható a Kerberos-alapú hálózatokkal a felhasználók hitelesítésére, akik így hozzáférnek a számukra elérhető szolgáltatásokhoz. Az SSO használható számos hálózati tevékenységhez, a biztonságos Safarimunkamenetektől kezdve a külső alkalmazásokig. A tanúsítványalapú hitelesítés (például PKINIT) is támogatva van. A macos a Kerberos használatával támogatja a vállalati hálózatokban történő hitelesítést. Az alkalmazások a Kerberost használhatják a felhasználók hitelesítésére, akik így hozzáférnek a számukra elérhető szolgáltatásokhoz. A Kerberos használható számos hálózati tevékenységhez is, a biztonságos Safari-munkamenetektől kezdve a fájlrendszer hitelesítésén át a külső alkalmazásokig. A tanúsítványalapú hitelesítés (PKINIT) is támogatva van, ehhez azonban a fejlesztői API alkalmazásadaptációja szükséges. Az ios, ipados és macos rendszeren az SSO SPNEGO tokeneket és a HTTP Negotiate protokollt használja a Kerberos-alapú hitelesítési átjárókon és a Kerberos-jegyeket támogató, Windows-alapú integrált hitelesítési rendszereken. Az SSO-támogatás a nyílt forráskódú Heimdal projekten alapul. A következő titkosítási típusok vannak támogatva az ios, ipados és macos rendszerekben: AES-128-CTS-HMAC-SHA1-96 AES-256-CTS-HMAC-SHA1-96 DES3-CBC-SHA1 ARCFOUR-HMAC-MD5 127

128 A Safari támogatja az SSO-t, és a szabványos ios- és ipados-hálózatkezelési APIkat használó külső alkalmazások is konfigurálhatók ennek használatára. Az SSO konfigurálásához az ios és az ipados támogatja az olyan konfigurációs profil típusú adatcsomagot, amely lehetővé teszi a mobileszköz-felügyeleti (MDM) megoldások számára a szükséges beállítások átküldését. Ebbe beletartozik a felhasználó résztvevőnevének (vagyis az Active Directory felhasználói fióknak) és a Kerberos-tartománynak a beállítása, valamint annak beállítása, hogy mely alkalmazások és Safari web URL-címek használhatják az SSO-t. A macos rendszeren a Kerberos konfigurálásához szerezzen be jegyeket a Ticket Viewer segítségével, jelentkezzen be a Windows Active Directory doménbe, vagy használja a kinit parancssori eszközt. Bővíthető egyszeri bejelentkezés Az alkalmazásfejlesztők megadhatják a saját egyszeri bejelentkezéses implementációjukat SSO-bővítmények segítségével. A rendszer akkor hívja meg az SSO-bővítményeket, amikor a natív vagy webes alkalmazásnak hitelesítésszolgáltatót kell igénybe vennie a felhasználó hitelesítéséhez. A fejlesztők kétféle bővítményt tehetnek elérhetővé: olyat, amelyik HTTPSprotokollra irányít át, és olyat, amelyik kérdés/válasz mechanizmust használt, például a Kerberos. Ezáltal a bővíthető egyszeri bejelentkezés képes támogatni az OpenID, OAuth, SAML2 és Kerberos hitelesítési sémákat. Az egyszeri bejelentkezéses bővítmény használatához az alkalmazás használhatja az AuthenticationServices API-t, vagy hagyatkozhat az operációs rendszer által kínált URLelfogási mechanizmusra. A WebKit és a CFNetwork olyan elfogási réteget kínál, amely zökkenőmentesen támogatja minden natív vagy WebKit-alkalmazás esetén az egyszeri bejelentkezést. Ahhoz, hogy a rendszer egyszeri bejelentkezéses bővítményt hívjon meg, rendszergazda által biztosított konfigurációt kell telepíteni mobileszköz-felügyeleti (MDM) profilon keresztül. Ezenkívül az átirányítás típusú bővítményeknek az Associated Domains adatcsomaggal kell bizonyítaniuk, hogy az általuk támogatott identitásszerver tud a jelenlétükről. Az operációs rendszerrel csak a Kerberos SSO bővítmény érkezik. AirDrop-biztonság Az AirDrop funkciót támogató Apple-eszközök Bluetooth Low Energy (BLE) és az Apple által létrehozott társközi Wi-Fi technológiával küldik a fájlokat és információkat a közeli eszközöknek, beleértve az AirDrop funkciót használó ios-eszközöket, ha ios 7 vagy újabb verziójúak, és a Mac gépeket, ha OS X vagy újabb verziójúak. Az eszközök közötti kommunikációt a Wi-Fi-rádió biztosítja, így nincs szükség internetkapcsolatra, sem vezeték nélküli hozzáférési pontra (AP). macos esetén a kapcsolatot TLS titkosítja. Alapértelmezésben az AirDrop-megosztás Csak kontaktok értékre van beállítva. Igény szerint használhatja az AirDrop funkciót a bárkivel való megosztásra, illetve ki is kapcsolhatja teljesen. A szervezetek a mobileszköz-felügyeleti (MDM) megoldással felügyelt eszközök és alkalmazások esetén korlátozhatják az AirDrop használatát. 128

129 Az AirDrop működése Az AirDrop icloud-szolgáltatásokkal segíti a felhasználóknak a hitelesítést. Amikor a felhasználó bejelentkezik az icloudba, akkor 2048 bites RSA-identitás tárolódik az eszközön, és amikor a felhasználó engedélyezi az AirDropot, akkor egy rövid AirDrop-identitáshash jön létre a felhasználó Apple ID-jához társított -címek és telefonszámok alapján. Amikor a felhasználó az AirDrop használatával oszt meg egy elemet, a küldő eszköz AirDrop-jelet bocsát ki BLE segítségével, és ez a jel tartalmazza a rövid AirDropidentitáshasht. A közelben és ébren lévő más Apple-eszközök, ha be van kapcsolva rajtuk az AirDrop, észlelik a jelet, és társközi Wi-Fi-vel válaszolnak, így a küldő eszköz felfedezheti a válaszoló eszközök identitását. Csak kontaktok módban a rendszer a fogadott rövid AirDrop identitáshasht összehasonlítja a fogadó eszköz Kontaktok alkalmazásában lévő személyek hasheivel. Ha egyezést talál, akkor a fogadó eszköz társközi Wi-Fi segítségével válaszol az identitásinformációival. Ha nincs egyezés, az eszköz nem válaszol. Mindenki módban nagyjából ugyanez az folyamat zajlik. A fogadó eszköz azonban akkor is válaszol, ha nincs egyezés az eszköz Kontaktok alkalmazásában. A küldő eszköz ekkor inicializálja az AirDrop-kapcsolatot társközi Wi-Fi használatával, és ezen a kapcsolaton keresztül elküldi a hosszú identitáshasht a fogadó eszköznek. Ha a hosszú identitáshash megegyezik a fogadó eszköz Kontaktok alkalmazásában egy ismert személlyel, akkor a fogadó a hosszú identitáshashével válaszol. Ha a hash ellenőrzése megtörtént, a fogadó utóneve és (ha megtalálható a Kontaktokban) fotója megjelenik a küldő AirDrop alkalmazásának megosztási lapján. ios és ipados esetén ezek a Személyek vagy Eszközök részben jelennek meg. A nem ellenőrzött vagy nem hitelesített eszközök a küldő AirDrop alkalmazásának megosztási lapján sziluett ikonnal és eszköznévvel jelennek meg, ahogy a Beállítások > Általános > Névjegy > Név részben meg van adva. ios és ipados esetén ezek az eszközök az AirDrop megosztási lapjának Mások részében szerepelnek. A küldő felhasználó ekkor kiválaszthatja, hogy kivel osztja meg a tartalmat. A felhasználó kiválasztása után a küldő eszköz titkosított (TLS) kapcsolatot inicializál a fogadó eszközzel, és ennek során egyeztetik az icloud-identitástanúsítványaikat. A tanúsítványokban szereplő identitást a rendszerek az egyes felhasználók Kontaktok alkalmazásával összevetve ellenőrzik. Ha a tanúsítványok ellenőrzése sikeres, a fogadó felhasználó kérést kap a bejövő adatok elfogadására az azonosított felhasználótól vagy eszköztől. Ha több fogadó van kiválasztva, akkor a folyamat minden egyes cél esetén megismétlődik. Wi-Fi-jelszavak megosztása A Wi-Fi-jelszavak megosztását támogató ios- és ipados-eszközök az AirDrophoz hasonló mechanizmussal küldik egyik eszközről a másikra a Wi-Fi-jelszót. 129

130 Amikor a felhasználó kiválaszt egy Wi-Fi-hálózatot (kérelmező), és meg kell adnia a Wi- Fi-jelszót, az Apple-eszköz Bluetooth Low Energy (BLE) hirdetményt indít, amely jelzik, hogy kéri a Wi-Fi-jelszót. Ha a közelben és ébren lévő többi Apple-eszköz rendelkezik a kiválasztott Wi-Fi-hálózat jelszavával, akkor BLE segítségével csatlakozik a kérelmező eszközhöz. A Wi-Fi-jelszóval rendelkező eszköznek (adományozónak) szüksége van a kérelmező Kontaktok-adataira, és a kérelmezőnek az AirDrophoz hasonló mechanizmussal bizonyítania kell az identitását. Az identitás bizonyítása után az adományozó elküldi a kérelmezőnek a jelkódot, amellyel az csatlakozhat a hálózathoz. A szervezetek a mobileszköz-felügyeleti (MDM) megoldással felügyelt eszközök és alkalmazások esetén korlátozhatják a Wi-Fi-jelszavak megosztásának használatát. A macos tűzfala A macos beépített tűzfallal védi a Mac gépet a hálózati hozzáféréses és szolgáltatásmegtagadási támadásoktól. A tűzfal a Rendszerbeállítások Biztonság és adatvédelem paneljén konfigurálható, és a következő konfigurációkat támogatja: Az összes bejövő kapcsolat blokkolása az alkalmazástól függetlenül A bejövő kapcsolatokat fogadásának automatikus engedélyezése a beépített szoftverek számára A bejövő kapcsolatokat fogadásának automatikus engedélyezése a letöltött és aláírt szoftverek számára Hozzáférés hozzáadása és elutasítása a felhasználó által kiválasztott alkalmazások alapján A Mac letiltása az ICMP-próbák és portszkennelési kérelmek megválaszolásáról 130

131 Fejlesztői készletek A fejlesztői készletek áttekintése Az Apple számos keretrendszer segítségével segíti a külső fejlesztőket az Appleszolgáltatások kiterjesztésében. Ezek a keretrendszerek a felhasználói biztonságot és adatvédelmet szem előtt tartva készültek: HomeKit HealthKit CloudKit SiriKit DriverKit ReplayKit Kamera és ARKit HomeKit HomeKit-identitás A HomeKit olyan automatizálási infrastruktúrát kínál az otthonához, amely felhasználja az icloud, az ios, az ipados és a macos biztonságát, hogy megvédje és szinkronizálja a személyes adatokat anélkül, hogy felfedné azokat az Apple számára. A HomeKit-identitás és -biztonság az Ed25519 nyilvános-privát kulcspárokon alapul. Az Ed25519 kulcspár a HomeKit minden felhasználójánál generálódik az ios-, ipados- és macos-eszközökön, és ez lesz a felhasználók HomeKit-identitása. Ezzel hitelesíthető a kommunikáció az ios-, ipados- és macos-eszközök között, valamint az ios-, ipados- és macos-eszközök és -kiegészítők között. A Kulcskarikán tárolt és csak a titkosított Kulcskarika biztonsági mentésben szereplő kulcsok az icloud-kulcskarika segítségével szinkronizálódnak, ahol az elérhető. A HomePod és az Apple TV a kulcsokat a koppintásos beállítás vagy az alább leírt beállítási mód használatával kapják meg. A párosított Apple Watchra a kulcsok az iphone-ról kerülnek át az Apple identitásszolgáltatás (IDS) használatával. 131

132 Kommunikáció HomeKit-kiegészítőkkel A HomeKit-kiegészítők maguknak generálják az Ed25519 kulcspárjukat, amelyet az ios-, ipados- és macos-eszközökkel folytatott kommunikációhoz használnak. Ha a kiegészítő visszaáll a gyári beállításokra, új kulcspár generálódik. Ha kapcsolatot szeretne teremteni az ios-, ipados- és macos-eszköz és a HomeKitkiegészítő között, a kulcsok kicseréléséhez a (3072 bites) biztonságos távoli jelszó protokollt használja a rendszer, amely során a felhasználó az ios- vagy ipados-eszközön beírja a kiegészítő gyártója által megadott nyolc számjegyű kódot, és ezt a rendszer CHACHA20-POLY1305 AEAD használatával, HKDF-SHA-512 függvénnyel származtatott kulcsokkal titkosítja. A beállítás során a kiegészítő MFi-tanúsítványát is ellenőrzi a rendszer. Az MFi-chip nélküli kiegészítők beépíthetik a szoftveres hitelesítést ios 11.3 és újabb verziók esetén. Amikor az ios-, ipados- és macos-eszköz, valamint a HomeKit-kiegészítő a használat során kommunikálnak, mindegyikük a fenti folyamatban leírt módon kicserélt kulcsokkal hitelesíti egymást. Minden munkamenet Station-to-Station (STS) protokollal épül fel, és HKDF-SHA-512 függvénnyel származtatott kulcsokkal van titkosítva, munkamenetalapú Curve25519-kulcsokkal. Ez mind az IP-alapú, mind a Bluetooth Low Energy (BLE) kiegészítőkre érvényes. A sugárzásos értesítéseket támogató BLE-eszközök esetén a kiegészítő sugárzástitkosítási kulcsot kap a párosított ios-, ipados vagy macos-eszköztől a biztonságos munkamenet idejére. Ezzel a kulccsal történik a kiegészítő állapotának módosulására vonatkozó adatok titkosítása; az értesítések BLE-hirdetményekkel történnek. A sugárzástitkosítási kulcs HKDF-SHA-512 függvénnyel származtatott kulcs, az adatok pedig a CHACHA20-POLY1305 hitelesített titkosítás társított adatokkal (AEAD) algoritmussal vannak titkosítva. A sugárzástitkosítási kulcsot rendszeresen módosítja az ios-, ipados- vagy macos-eszköz, és az icloud segítségével szinkronizálódik más eszközökre az Adatok szinkronizálása eszközök és felhasználók között című részben leírtak szerint. HomeKit helyi adattár A HomeKit a felhasználó ios-, ipados- és macos-eszközén tárol adatokat az otthonokról, kiegészítőkről, szcenáriókról és felhasználókról. Ezek az adatok a felhasználó HomeKitidentitásából származtatott kulcsokkal és egy véletlenszerű nonce-szal titkosítva vannak tárolva. A HomeKit-adatok ezenkívül a Protected Until First User Authentication Data Protection-osztállyal vannak tárolva. A HomeKit-adatok csak titkosított biztonsági mentésekbe kerülnek bele, így például a titkosítatlan itunes biztonsági mentések nem tartalmaznak HomeKit-adatokat. Adatok szinkronizálása eszközök és felhasználók között A HomeKit-adatok az icloud és az icloud-kulcskarika használatával szinkronizálhatók a felhasználó ios-, ipados és macos-eszközei között. A HomeKit-adatok a szinkronizálás során a felhasználó HomeKit-identitásából származtatott kulcsokkal és egy véletlenszerű nonce-szal vannak titkosítva. A szinkronizálás közben az adatok átlátszatlan blobként vannak kezelve. A legfrissebb blob az icloudban van tárolva a szinkronizálás lehetővé tételéhez, de más célra nincs felhasználva. Az elem tartalma nem érhető el az átvitel és az icloudban történő tárolás során, mivel olyan kulcsokkal van titkosítva, amelyek csak a felhasználó ios-, ipados- és macos-eszközein érhetők el. 132

133 A HomeKit-adatok szinkronizálva vannak az egyazon otthonban lakó összes felhasználó között is. A folyamat olyan hitelesítést használ, amely azonos azzal, amit az ios-, ipadosés macos-eszköz, valamint a HomeKit-kiegészítő használ egymás között. A hitelesítés az Ed25519 nyilvános kulcsokon alapul, amelyeket a rendszer kicserél az eszközök között, amikor a felhasználót hozzáadja az otthonhoz. Miután az új felhasználó hozzá lett adva az otthonhoz, minden további kommunikáció Station-to-Station (STS) protokollal és munkamenet-alapú kulcsokkal van hitelesítve és titkosítva. Az otthont a HomeKitben eredetileg létrehozó felhasználó vagy másik, szerkesztési jogosultsággal rendelkező felhasználó adhat hozzá új felhasználókat. A tulajdonos eszköze úgy konfigurálja az új felhasználó kiegészítőit a nyilvános kulcsokkal, hogy a kiegészítő hitelesíthesse az új felhasználót, és parancsokat fogadhasson tőle. Amikor szerkesztési jogosultsággal rendelkező felhasználó ad hozzá új felhasználót, a folyamat az otthoni központba kerül a művelet véglegesítéséhez. Az Apple TV előkészítésének folyamata a HomeKittel való használatra automatikusan megtörténik, amikor a felhasználó bejelentkezik az icloudba. Az icloud-fiókban be kell kapcsolni a kétlépéses hitelesítést. Az Apple TV és a tulajdonos eszköze ideiglenes Ed25519 nyilvános kulcsokat cserélnek az icloudon keresztül. Ha a tulajdonos eszköze és az Apple TV azonos helyi hálózaton vannak, a rendszer az ideiglenes kulcsok segítségével teszi biztonságossá a kapcsolatot a helyi hálózaton, Station-to-Station (STS) protokoll és munkamenet-alapú kulcsok használatával. A folyamat olyan hitelesítést használ, amely azonos azzal, amit az ios-, ipados- és macos-eszköz, valamint a HomeKit-kiegészítő használ egymás között. A tulajdonos eszköze ezen a biztonságos helyi kapcsolaton keresztül viszi át a felhasználó Ed25519 nyilvános-privát kulcspárját az Apple TV-re. Ezek a kulcsok használatosak azután az Apple TV és a HomeKit-kiegészítők, valamint a HomeKit-otthon részét képező Apple TV és más ios-, ipados- és macos-eszközök közötti kommunikációhoz. Ha a felhasználónak nincs több eszköze, és nem ad hozzáférést más felhasználóknak az otthona eléréséhez, akkor a HomeKit-adatok nincsenek az icloudba szinkronizálva. Otthon-adatok és -alkalmazások Az otthoni adatok alkalmazások általi elérését a felhasználó adatvédelmi beállításai szabályozzák. A felhasználók kérést kapnak a hozzáférés megadásához, amikor az alkalmazások otthoni adatokat kérnek, hasonlóan a Kontaktokhoz, a Fotókhoz és más ios-, ipados és macos-adatforrásokhoz. Ha a felhasználó jóváhagyja, az alkalmazások hozzáférnek a helyiségek és a kiegészítők neveihez, és hogy melyik kiegészítő melyik helyiségben van, valamint további információkhoz, amelyek a HomeKit fejlesztői dokumentációjában vannak részletezve: HomeKit és Siri A Siri segítségével kiegészítők kérdezhetők le és vezérelhetők, és szcenáriók aktiválhatók. A Siri névtelenül kap minimális információkat az otthon konfigurációjáról, hogy a parancsok felismeréséhez rendelkezzen a helyiségek, kiegészítők és szcenáriók neveivel. A Sirinek küldött hanganyag jelezhet bizonyos kiegészítőket vagy parancsokat, de az ilyen Siriadatok nincsenek más Apple-funkciókhoz társítva, mint például a HomeKit. 133

134 HomeKit IP-kamerák A HomeKit rendszerben az IP-kamerák a video- és hangstreamet közvetlenül azokra az ios-, ipados- és macos-eszközre küldik, amelyek a helyi hálózaton elérik a streamet. A streamek az ios-, ipados- és macos-eszközön, valamint az IP-kamerán véletlenszerűen generált kulcsokkal vannak titkosítva; a kulcsokat a kamera a biztonságos HomeKitmunkameneten keresztül kapja meg. Ha az ios-, ipados- vagy macos-eszköz nincs a helyi hálózaton, a titkosított streamek az otthoni központon keresztül jutnak el az eszközre. Az otthoni központ nem fejti vissza a streameket, és csak átjátszóként működik az ios-, ipados- és macos-eszköz, valamint az IP-kamera között. Amikor egy alkalmazás megjeleníti a felhasználónak a HomeKit IP-kamera videóját, a HomeKit a videó képkockáit külön rendszerfolyamatban dolgozza fel, így az alkalmazás nem fér hozzá a videostreamhez, és nem képes tárolni azt. Az alkalmazásoknak ezenkívül nem engedélyezett a képernyőképek készítése a streamből. HomeKit biztonságos videó A HomeKit anélkül kínál végponttól végpontig titkosított és rejtett módot a HomeKit IPkamerák klipjeinek rögzítéséhez, elemzéséhez és megtekintéséhez, hogy felfedné a videotartalmat a Apple vagy harmadik fél előtt. Amikor az IP-kamera mozgást észlel, a videoklipek közvetlenül az otthoni központként működő Apple-eszközre lesznek elküldve az adott otthoni központ és az IP-kamera közti közvetlen helyi hálózati kapcsolaton. A helyi hálózati kapcsolat olyan, munkamenet-alapú HKDF-SHA-512 származtatott kulcspárral van titkosítva, amelyről az otthoni központ és az IP-kamera közötti HomeKitmunkameneten keresztül jön létre megállapodás. A HomeKit visszafejti a hang- és videostreamet az otthoni központon, és helyileg elemzi a videó képkockáit, hogy tartalmaznak-e jelentős eseményt. Jelentős esemény észlelésekor a HomeKit titkosítja a videoklipet AES-256-GCM kódolás használatával, egy véletlenszerűen generált AES- 256 kulccsal. Ezenfelül a HomeKit létrehoz poszterképkockákat az egyes videoklipekhez, majd ezeket a poszterképkockákat ugyanazzal az AES-256 kulccsal titkosítja. A titkosított poszterképkockák, illetve a hang- és video-adatok az icloud-szerverekre lesznek feltöltve. Az egyes klipek kapcsolódó metaadatai, beleértve a titkosítási kulcsot is, a CloudKitbe lesznek feltöltve az icloud végponttól végpontig terjedő titkosításával. Amikor az Otthon alkalmazással tekinti meg egy kamera klipjeit, az adatok az icloudból vannak letöltve, és a streameket visszafejtő kulcsok helyileg, az icloud végponttól végpontig terjedő titkosításával vannak kicsomagolva. A titkosított videotartalom a szerverekről van streamelve, és helyileg, az ios eszközön van visszafejtve a megtekintőben való megjelenítés előtt. Minden videoklip-munkamenet alszakaszokká bontható, ahol az egyes alszakaszok a saját egyedi kulcsukkal titkosítják a tartalomstreamet. HomeKit-routerek A HomeKitet támogató routerek lehetővé teszik, hogy a felhasználó növelje az otthoni hálózat biztonságát a HomeKit-kiegészítők által a helyi hálózat és az internet eléréséhez használt Wi-Fi beállításával. Ezek az eszközök támogatják a PPSK-hitelesítést is, ezért a kiegészítők hozzáadhatók a Wi-Fi-hálózathoz egy olyan kulccsal, amely a kiegészítőhöz tartozik, és szükség esetén visszavonható. Ez azzal javítja a biztonságot, hogy nem fedi fel a fő Wi-Fi-jelszót a kiegészítők előtt, illetve lehetővé teszi, hogy a router biztonságosan azonosítson egy kiegészítőt még akkor is, ha annak MAC-címe megváltozik. Az Otthon alkalmazással a felhasználók a következők szerint konfigurálhatják a kiegészítők csoportjaihoz való hozzáférést: 134

135 Nincs korlátozás: Korlátlan hozzáférés engedélyezése az internethez és a helyi hálózathoz. Automatikus: Ez az alapértelmezett beállítás. Hozzáférés engedélyezése az internethez és a helyi hálózathoz a kiegészítő gyártója által az Apple számára biztosított webhelyek és helyi portok listája alapján. Ez a lista tartalmazza az összes webhelyet és portot, amelyekre a kiegészítőnek szüksége van a megfelelő működéshez. (A Nincs korlátozás van érvényben, amíg ilyen lista nem érhető el.) Korlátozás az Otthonra: Nincs hozzáférés az internethez vagy a helyi hálózathoz, kivéve azokat a kapcsolatokat, amelyekre a HomeKitnek szüksége van a kiegészítő helyi hálózaton való felfedezéséhez és vezérléséhez (beleértve az otthoni központból származó csatlakozásokat a távirányítás támogatásához). A PPSK egy olyan erős, kiegészítőspecifikus WPA2 Personal-jelszó, amelyet automatikusan generál a HomeKit, és vissza van vonva, amikor a kiegészítőt később eltávolítják az Otthonból. A HomeKit PPSK használatával adja hozzá a kiegészítőket a Wi-Fi-hálózathoz a HomeKit-routerrel konfigurált Otthonban. (A router hozzáadása előtt a Wi-Fi-hálózathoz adott kiegészítők megtartják a meglévő bejelentkezési adataikat.) További biztonsági intézkedésként a felhasználónak konfigurálnia kell a HomeKit-routert a router gyártójának alkalmazásával, hogy az alkalmazás ellenőrizhesse, hogy a felhasználó rendelkezik-e hozzáféréssel a routerhez, és hozzáadhatja-e azt az Otthon alkalmazáshoz. icloud távoli elérés HomeKit-kiegészítők esetén Néhány régi HomeKit-kiegészítőnek szüksége van arra, hogy közvetlenül az icloudhoz csatlakozzon, hogy lehetővé tegye az ios-, ipados- és macos-eszközöknek a kiegészítő vezérlését, ha a Bluetooth vagy Wi-Fi-kommunikáció nem érhető el. Az otthoni központon (például HomePod, Apple TV vagy ipad) keresztüli távoli elérés használata javasolt, ha az elérhető. Az icloud távoli elérés továbbra is támogatott a régi eszközök számára, és gondosan úgy lett tervezve, hogy a kiegészítők úgy vezérelhetők, és úgy küldhetnek értesítéseket, hogy ne fedjék fel az Apple számára, hogy mik a kiegészítők, vagy hogy milyen parancsok és értesítések küldése történik. A HomeKit nem küld információkat az otthonról az icloud távoli elérésen keresztül. Amikor a felhasználó parancsot küld az icloud távoli elérés használatával, a kiegészítő és az ios-, ipados- és macos-eszköz kölcsönösen hitelesítve van, és az adatok a helyi kapcsolatoknál leírt eljárás szerint vannak titkosítva. A kommunikáció tartalma titkosítva van, és az Apple számára nem látható. Az icloudon keresztüli címzés a beállítási folyamat során regisztrált icloud-azonosítókon alapul. 135

136 Az icloud távoli elérést támogató kiegészítők a kiegészítő beállítási folyamata során elő vannak készítve. Az előkészítési folyamat azzal kezdődik, amikor a felhasználó bejelentkezik az icloudba. Ezután az ios- és ipados-eszköz megkéri a kiegészítőt, hogy írja alá a kihívást az Apple hitelesítési segédprocesszorral, amely minden Built for HomeKit jellel rendelkező kiegészítő része. A kiegészítő a prime256v1 elliptikus görbe kulcsokat is generálja, és a nyilvános kulcsokat elküldi az ios- és ipados-eszköznek az aláírt kihívással és a hitelesítési segédprocesszor X.509 tanúsítványával együtt. A rendszer ezekkel kér tanúsítványt a kiegészítőhöz az icloud előkészítési szervertől. A tanúsítványt a kiegészítő tárolja, de az nem tartalmaz a kiegészítő azonosíthatóságára vonatkozó információt, csak azt, hogy jogosultságot nyert a HomeKit icloudon keresztüli távoli eléréséhez. Az előkészítést végző ios- és ipados-eszköz olyan tárolót is küld a kiegészítőnek, amely az icloud távoli elérési szerverhez való kapcsolódáshoz szükséges URL-címet és más információkat tartalmaz. Ez az információ nem felhasználó- vagy kiegészítőspecifikus. Minden kiegészítő regisztrálja az engedélyezett felhasználók listáját az icloud távoli elérési szerveren. Ezek a felhasználók megkapják a kiegészítő vezérlésének jogosultságát attól a felhasználótól, aki a kiegészítőt az otthonhoz adta. A felhasználóknak az icloud-szerver azonosítót biztosít, és a felhasználók hozzárendelhetők egy icloud-fiókhoz, hogy értesítési üzeneteket és válaszokat kapjanak a kiegészítőktől. Hasonlóképpen, a kiegészítők rendelkeznek az icloud által kibocsátott azonosítókkal, ezek az azonosítók viszont átlátszatlanok, és nem fednek fel információt magáról a kiegészítőről. Amikor egy kiegészítő a HomeKit icloud távoli elérési szerveréhez kapcsolódik, bemutatja a tanúsítványát és az engedélyét. Az engedélyt egy másik icloud-szerver bocsátja ki, és nem egyedi a kiegészítőkre vonatkozóan. Amikor a kiegészítő engedélyt kér, a kérelemben felsorolja a gyártót, a modellt és a firmware verzióját. A kérelemmel együtt nem lesz elküldve a felhasználót vagy az otthont azonosító információ. Az adatvédelem érdekében az engedélyt kiadó szerverrel való kapcsolat nincs hitelesítve. Az icloud távoli elérési szerverhez a kiegészítők HTTP/2 protokollal kapcsolódnak, amelyet TLS v1.2 tesz biztonságossá AES-128-GCM és SHA-256 segítségével. A kiegészítő nyitva tartja a kapcsolatot az icloud távoli elérési szerverhez, hogy fogadhassa a bejövő üzeneteket, és elküldhesse a válaszokat és kimenő üzeneteket az ios-, ipados- és macos-eszközöknek. HomeKit TV-távirányító kiegészítők A külső HomeKit TV-távirányító kiegészítők HID-eseményeket és Siri-hangot biztosítanak olyan társított Apple TV készülékhez, amelyet az Otthon alkalmazással adott hozzá. A HID-események az Apple TV és a távirányító közötti biztonságos munkameneten keresztül vannak elküldve. A Sirit kezelni képes TV-távirányító akkor küldi a hangadatot az Apple TV számára, ha a felhasználó kifejezetten aktiválja a mikrofont a távirányítón a dedikált Siri-gombbal. A hangrészletek közvetlenül az Apple TV készülékhez mennek az Apple TV és a távirányító közötti dedikált helyi hálózati kapcsolaton. A helyi hálózati kapcsolat olyan, munkamenet-alapú HKDF-SHA-512 származtatott kulcspárral van titkosítva, amelyről az Apple TV és TV-távirányító közötti HomeKit-munkameneten keresztül jön létre megállapodás. A HomeKit az Apple TV készüléken fejti vissza a hangrészleteket, és továbbítja azokat a Siri alkalmazásnak, ahol ugyanaz az adatvédelem érvényes rá, mint a többi Siri-hangbevitelre. 136

137 A HomeKit-otthonok Apple TV-profiljai Amikor a HomeKit-otthon felhasználója hozzáadja a profilját az otthoni Apple TV tulajdonosához, akkor a felhasználó hozzáférést kap a tévéműsorokhoz, zenékhez és podcastokhoz. Az egyes felhasználók Apple TV készüléken való profilhasználatával kapcsolatos beállítások meg vannak osztva a tulajdonos icloud-fiókjával az icloud végponttól végpontig tartó titkosítása használatával. Az adatok tulajdonosai az egyes felhasználók, és a tulajdonossal írásvédetten vannak megosztva. Az otthon minden felhasználója módosíthatja ezeket az értékeket az Otthon alkalmazásból, a tulajdonos Apple TV készüléke pedig ezeket a beállításokat használja. Amikor egy beállítást bekapcsol, a felhasználó itunes-fiókja elérhetővé válik az Apple TV készüléken. Amikor egy beállítást kikapcsol, akkor a felhasználóhoz tartozó összes adat és fiók törlődik az Apple TV készülékről. A kezdeti CloudKit-megosztást a felhasználó eszköze és tokenje inicializálja, hogy a biztonságos CloudKit-megosztás ugyanazon a biztonságos csatornán közlekedjen, amely az otthon felhasználói közötti adatok szinkronizálására használatos. HealthKit A HealthKit áttekintése A HealthKit az egészségi és fitneszalkalmazásokból, valamint az egészségügyi intézményektől származó adatokat tárolja és összesíti. A HealthKit közvetlenül együttműködik az egészségi és fitneszeszközökkel, például a kompatibilis Bluetooth Low Energy (BLE) pulzusszámlálókkal és a számos ios-eszközbe épített mozgási segédprocesszorral. A HealthKitnek az egészségi és fitneszalkalmazásokkal, egészségügyi szervezetekkel és egészségi és fitneszeszközökkel végzett összes interakciójához a felhasználó engedélye szükséges. Az adatok a Protected Unless Open nevű Data Protection-osztályban vannak tárolva. Az adatok hozzáférhetősége az eszköz zárolása után 10 perccel megszűnik, és az adatok csak akkor lesznek újból elérhetők, ha a felhasználó megadja a jelkódját, vagy a Touch ID vagy Face ID segítségével feloldja az eszközt. A HealthKit a kezelési adatokat is összesíti, amikor új adatok válnak elérhetővé; ilyen adatok például az adatok hozzáférési engedélyei, a HealthKithez csatlakoztatott eszközök nevei és az adatok indításához használt ütemezési információk. Ezek az adatok a Protected Until First User Authentication Data Protection-osztállyal vannak tárolva. Az ideiglenes naplófájlok olyan egészségügyi rekordokat tárolnak, amelyek az eszköz zárolásakor generálódnak, például amikor a felhasználó edz. Ezek a Protected Unless Open nevű Data Protection-osztályban vannak tárolva. Amikor az eszköz fel van oldva, az ideiglenes naplófájlok az elsődleges egészségügyi adatbázisba importálódnak, és az összevonás után törlődnek. Az Egészség-adatok tárolhatók az icloudban. Az Egészség-adatok végponttól végpontig történő titkosításához az ios 12 vagy újabb verziónak kétlépéses hitelesítés kell alkalmaznia. Ellenkező esetben a felhasználó adatai titkosítva vannak ugyan a tárolás és az átvitel közben, de nem végponttól végpontig. Miután a felhasználó bekapcsolta a kétlépéses hitelesítést, és ios 12 vagy újabb rendszerre frissített, a felhasználó Egészségadatai migrálva lesznek a végponttól végpontig történő titkosítás érdekében. 137

138 Ha a felhasználó biztonsági mentést készít az eszközről az itunes használatával (macos és korábbi esetén) vagy a Finder használatával (macos és újabb esetén), az Egészség-adatok csak a titkosított biztonsági mentésekbe kerülnek be. A klinikai egészségügyi rekordok és az Egészség-adatok integritása Klinikai egészségügyi rekordok A felhasználók az Egészség alkalmazáson belül bejelentkezhetnek a támogatott egészségügyi rendszerekbe, ahol beszerezhetik a klinikai egészségügyi rekordjaik másolatát. Amikor a felhasználó egészségügyi rendszerhez kapcsolódik, akkor OAuth 2 klienshitelesítési bejelentkező adatokkal hitelesíti magát. A csatlakozás után a klinikai egészségügyi rekordok közvetlenül az egészségügyi intézménytől töltődnek le TLS v1.3 védett protokollon keresztül. A letöltés után az egészségügyi rekordok biztonságosan vannak tárolva a többi Egészség-adattal együtt. Az Egészség-adatok integritása Az adatbázisban tárolt adatok az egyes adatrekordok eredetét nyomon követő metaadatokat is tartalmazzák. A metaadatok között egy alkalmazásazonosító is szerepel, amely azonosítja, hogy melyik alkalmazás tárolta a rekordot. Ezenkívül további metaadatelem tartalmazhatja a rekord digitálisan aláírt másolatát. Ennek az a célja, hogy biztosítsa a megbízható eszköz által generált rekordok adatintegritását. A digitális aláíráshoz használt formátum az RFC 5652 szabvány szerinti Cryptographic Message Syntax (CMS). Az Egészség-adatok elérése külső alkalmazások által A HealthKit API-hoz való hozzáférést jogosultságok szabályozzák, és az alkalmazásoknak meg kell felelniük az adatok felhasználási módjára vonatkozó korlátozásoknak. Az alkalmazások számára például nem engedélyezett az egészségügyi adatok reklámcélra való használata. Az alkalmazásoknak továbbá adatvédelmi nyilatkozatot kell nyújtaniuk a felhasználók számára, amely részletezi az egészségügyi adatok felhasználását. Az egészségügyi adatok alkalmazások általi elérését a felhasználó adatvédelmi beállításai szabályozzák. A felhasználók kérést kapnak a hozzáférés megadásához, amikor az alkalmazások egészségügyi adatokat kérnek, hasonlóan a Kontaktokhoz, a Fotókhoz és más ios-adatforrásokhoz. Az egészségügyi adatok esetében azonban az alkalmazások külön-külön hozzáférést kapnak az adatok olvasásához és írásához, valamint külön hozzáférést az egyes típusú egészségügyi adatokhoz. A felhasználók az egészségügyi adatok eléréséhez megadott engedélyeket megtekinthetik és visszavonhatják a Beállítások > Egészség > Adatelérés és eszközök menüpontban. 138

139 Ha az alkalmazásnak van jogosultsága az adatok írására, akkor írás közben olvashatja is az adatokat. Ha olvasási jogosultsága van, akkor az összes erőforrás által írt adatokat olvashatja. Az alkalmazások azonban nem ismerik a más alkalmazásoknak biztosított jogosultságokat. Ezenkívül az alkalmazások nem tudják biztosan meghatározni, hogy van-e jogosultságuk az egészségügyi adatok olvasásához. Ha az alkalmazásnak nincs olvasási jogosultsága, akkor a lekérdezései nem adnak vissza adatot az üres adatbázis ugyanezt a választ adná vissza. Ez meggátolja, hogy az alkalmazások következtessenek a felhasználó egészségügyi állapotára azáltal, hogy megtanulják a felhasználó által nyomon követett adatok típusát. A felhasználó orvosi azonosítója Az Egészség alkalmazásban a felhasználók kitölthet egy Orvosi azonosító nevű űrlapot, amely az orvosi vészhelyzetben fontos adatokat tartalmazza. Az adatok megadása és frissítése manuálisan történik, és nincsenek szinkronizálva az egészségügyi adatbázisokban lévő információkkal. Az Orvosi azonosító megtekintéséhez koppintson a Vészhelyzet gombra a zárolási képernyőn. Ezek az információk a No Protection nevű Data Protection-osztállyal vannak tárolva az eszközön, így az eszköz jelkódjának megadása nélkül is elérhetők. Az Orvosi azonosító választható funkció; lehetővé teszi a felhasználók számára, hogy egyensúlyba hozzák a biztonság és az adatvédelem kérdését. Az adatok bekerülnek az icloud biztonsági mentésbe, és nem szinkronizálódnak az eszközök között a CloudKit segítségével. CloudKit A CloudKit segítségével az alkalmazásfejlesztők kulcs-érték adatokat, strukturált adatokat és eszközöket tárolhatnak az icloudban. A CloudKit elérését alkalmazásjogosultságok szabályozzák. A CloudKit a nyilvános és a privát adatbázisokat is támogatja. A nyilvános adatbázisokat az alkalmazások összes példánya használja, általában általános eszközök céljára, és nincsenek titkosítva. A privát adatbázisok a felhasználó adatait tárolják. 139

140 Az icloud Drive esetében a CloudKit fiókalapú kulcsokkal védi a felhasználó privát adatbázisában tárolt információkat, és más icloud-szolgáltatásokhoz hasonlóan a fájlok külső szolgáltatások segítségével vannak csonkítva, titkosítva és tárolva. A CloudKit kulcshierarchiát használ, hasonlóan a Data Protection funkcióhoz. A fájlalapú kulcsok a CloudKit Record kulcsaival vannak csomagolva. A Record kulcsokat viszont az egész zónát átfogó kulcs védi, amelyet a felhasználó CloudKit-szolgáltatáskulcsa véd. A CloudKitszolgáltatáskulcs a felhasználó icloud-fiókjában van tárolva, és csak akkor válik elérhetővé, ha a felhasználó azonosította magát az icloudban. CloudKit végponttól végpontig történő titkosítás. SiriKit A Siri az alkalmazásbővítményi rendszer segítségével kommunikál külső alkalmazásokkal. A Siri az eszközön hozzáfér a felhasználó kontaktadataihoz, és az eszköz aktuális helyéhez. A Siri azonban, mielőtt hozzáférést adna az adatokhoz egy alkalmazás számára, ellenőrzi az alkalmazás felhasználó által vezérelt hozzáférési jogosultságait. A Siri ezeknek a jogosultságoknak megfelelően csak a felhasználói hanganyag vonatkozó részét adja át az alkalmazásbővítménynek. Ha például egy alkalmazásnak nincs jogosultsága a kontaktadatok eléréséhez, a Siri nem fogja feloldani a kapcsolatot olyan felhasználói kérések esetében, mint például Pay my mother 10 dollars using Payment App ( Küldj az anyámnak 10 dollárt a Fizetés alkalmazással ). Ebben az esetben az alkalmazás csak a szó szerinti my mother ( az anyámnak ) kifejezést kapja meg. Ha azonban a felhasználó engedélyezte az alkalmazás számára a kontaktadatok elérését, az alkalmazás a felhasználó anyjára vonatkozó feloldott információt kapja meg. Ha a személyek közötti kapcsolatot az üzenet törzse tartalmazza Tell my mother on MessageApp that my brother is awesome ( Mondd meg anyámnak a MessageApp-pal, hogy az öcsém fantasztikus ), a Siri nem oldja fel az öcsém részt, függetlenül az alkalmazás engedélyeitől. A SiriKitet használó alkalmazások alkalmazás- és felhasználóspecifikus szótárt küldhetnek a Sirinek, például a felhasználó kontaktjainak neveit. Ez az információ lehetővé teszi a Siri beszédfelismerésének és természetes nyelvi értésének az alkalmazáshoz tartozó szavak felismerését, és egy véletlenszerű azonosítóval van társítva. Az egyéni információk elérhetők maradnak mindaddig, amíg az azonosító használatban van, vagy amíg a felhasználó le nem tiltja az alkalmazás Siri-integrációját a Beállításokban, vagy amíg a SiriKitet használó alkalmazás el nincs távolítva. 140