Az előző két részben (első rész, második rész) megtudhattátok, hogy hogyan is épül fel a hardver szintjén a készülék már ami a biztonsági képességeket illeti. Azt is megtudhattátok, hogy miként élvezi a szoftver az alatta működő hardver nyújtotta lehetőségeket és pár nagyon alap szintű képesség is ismertetésre került.
Aki olvasta a Twitteren a #journeyinapplesecurity hashtag alatt írt tweetjeim, azoknak ez a bejegyzés sok údonsággal nem fog szolgálni, ám mégis jobb lehet összefoglalva, egy helyen, kevesebb félregépeléssel újraolvasni őket. 🙂
Apple Watch párosítása
Amikor az Apple Watch párosítása megkezdődik, az Apple Watch a folyamat elején egy speciális – egyébként szemet gyönyörködtető – animációt jelenít meg a kijelzőjén, amit a telefon kamerájával kell leolvasni. Először azt hittem, hogy ez amolyan Apple féle showelem, de kiderült, hogy nem az. Ebbe az animációba az óra egy speciális titkot (shared secret) kódol bele. Ezzel a titokkal képes a telefon és az óra a kezdeti kapcsolatot felépíteni.
Miután a kezdeti kapcsolat felépült, az óra és a telefon kicserélik egymás között egymás publikus kulcsát. Miután a kulcscsere megtörtént, bontják a régi kapcsolatot aminek titkosítása ezzel a shared secret kulccsal volt védve, majd újrakapcsolódnak egymáshoz a már kicserélt kulcsokkal. Így biztosítható, hogy a két eszköz között a kapcsolat titkosított legyen. Hogyan?
Mindkét készüléken egy-egy kulcs pár van. Ezek a kulcspárok tartalmaznak egy privát és egy publikus kulcsot. Ahogy a nevük is mutatja, a publikus kulcsot oda lehet adni másnak, a privátot nem (ez történik a kulcscsere során: a telefon odaadja a publikus kulcsát az órának és viszont).
Amikor a telefon információt akar megosztani az órával, akkor az üzenetet a telefon a saját privát kulcsával titkosítja. Mivel az óra rendelkezik a telefon által használt privátkulcs publikus párjával, az üzenetet képes lesz értelmezni annak segítségével. Amikor pedig fordítva történik a kommunikáció, az óra az üzenetet titkosítja a saját privát kulcsával, majd azt a telefon az óra publikus kulcsával képes értelmezni.
Végezetül, az Apple Watch 15 percenként lecseréli a titkosításhoz használt kulcsokat (rolling key encryption), ezzel biztosítva a folyamatos biztonságot.
Fájlok titkosítása
Akik olvasták az első részt azok emlékezhetnek egy dedikált AES titkosítást végző modulra. Nos, ennek az AES modulnak köszönhetően amikor egy fájl keletkezik a készüléken (például készítenek egy képet), akkor a rendszer ennek a dedikált AES modulnak köszönhetően egy speciális 256 bit hosszú kulcsot készít annak tartalma alapján, végül titkosítja azt. Ennek több előnye is van:
- ha véletlenül kompromittálódna (kitudódna) egy kulcs, azzal csak az a fájl válna olvashatóvá, amelyik fájlt azzal titkosították,
- telefon alaphelyzetbe állításakor nem kell a teljes háttértár tartalmát biztonságosan törölni (ami a flash / SSD típusú háttértárolóknál nem is olyan könnyű), elég a fájlok titkosításához használt összes kulcsot törölni.
Ezeket a kulcsokat nem a háttértárolón tárolják, hanem az AES modulban, így kívülről egyáltalán nem elérhető, ráadásul:
- iPhone 7/8/X és Series 3-as készülékeken ezek a kulcsok már recovery módban sem férhetőek hozzá,
- iPhone XS/XR/11 és Series 4-es eszközöktől kezdve pedig már DFU módban sem.
Mit jelent a 256 bites kulcs védelme érthetően? Vegyünk egy 2 bites (22) kulcsot. A 2 bites kulcs értékkészlete: 00, 01, 10, 11, tehát maximum 4 elemet kell kipróbálnom, hogy megtaláljam a helyes értéket. Ezzel szemben a 256 bites (2256) kulccsal már 1,1 × 1077 méretűre nő ez az értékkészlet. Ez nullákkal kifejezve: 110 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 lehetséges érték. Senkinek nincs arra ideje, hogy erőből megtalálja egy ekkora értékkészletben azt az egyetlent, amire szüksége van.
Forrás: How does AES encryption work?
Keychain
A Keychain (vagy iCloud Keychain) egy roppant hasznos funkció, főleg ha az embernek több almás eszköze van. A Keychain egy olyan speciális adatbázis, amelyben az iOS / macOS képes tárolni a mentett jelszavakat, beállításokat, publikus és privát kulcsokat, tanúsítványokat, szóval kb. mindent. Végezetül ezt a sok-sok adatot szinkronban tartja a többi eszközöddel és a felhővel is (erről még később lesz szó).
A Keychain egy speciális SQLite adatbázis, ami egyetlen fájlban tárolja az érzékeny adatainkat. Ehhez a fájlhoz iOS szinten egyetlen egy folyamat, a securityd férhet hozzá. A Keychain-ben tárolt elemek titkosítása két szinten valósul meg. Az első szinten minden benne tárolt adat titkosítva van, így az avatatlan szemek semmit sem látnak abból, hogy mi van benne, csak a korábban említett securityd folyamat. Ennek az előnye az, hogy így a megfelelő interfészeken keresztül a keresés könnyen és időveszteség nélkül megvalósítható. Amint szükség van egy adatra (mondjuk egy weboldalhoz tartozó bejelentkezési információra), akkor lép életbe a második szint. A második szint ugyanis a Keychain-ben tárolt egyes elemekhez tartozó jelszó titkosítását jelenti.
Úgy képzeljétek ezt el, hogy van egy nagy szekrényetek, aminek az ajtaja zárt. Csak a megfelelő kulccsal tudjátok a szekrényt kinyitni. A szekrényen belül végtelen számú egyéb, kulccsal zárt fiók van. Minden fiókra rá van írva, hogy mi található benne (keresés). Ha azonban az egyik fiókból ki akarjátok venni azt, ami benne van, akkor szükségetek lesz a fiók kulcsára is.
A Keychain-ben természetesen lehetnek olyan elemek is, amelyek csak és kizárólag azon az egy készüléken értelmezhetőek. Ezek az elemek rendelkeznek egy speciális meta-adattal, az úgy nevezett “This device only” attribútummal. Azokat az elemeket a szinkronizációs mechanizmus, amelyek rendelkeznek ezzel a beállítással, nem szinkronizálja a többi eszközzel. Ilyen elem lehet például egy Device Certificate (eszköz tanúsítvány) mondjuk a céges VPN csatlakozáshoz.
És hogyha ez még mind nem lenne eléggé biztonságos, a legutolsó védvonal az ACL-ek. Az ACL-ek olyan szabályok, amelyeket a Keychain-ben tárolt elemek hozzáféréséhez lehet beállítani. Ezekre egyszerű szabályként gondoljatok, amik engedélyezik az adott elemhez való hozzáférést, ha a bennük foglalt feltételeknek eleget tesznek.
Erre is mondok egy példát: a netbank alkalmazásom csak addig engedélyezi a Face / Touch ID használatát a belépéshez, amíg rendszer szinten azokban nem történt változás. Ha mégis, akkor jelkódot kér (aztán újra bekapcsolható a Touch / Face ID). Ebben az esetben az ACL a netbank appom bejelentkezési adatához úgy szólt, hogy amíg a Touch / Face ID beállítások nem módosultak, addig mehet a buli.
Csatlakoztatott kiegészítők és a jelkód kitalálása
Megpróbálni feltörni az adott készülék jelkódját csak és kizárólag magán a készüléken lehetne, mert amikor beállítjuk a jelkódot, akkor annak eltárolásakor azt összekuszálják a készülék UID számával.
Azokra a kiegészítőkre, amelyeket a Lightning csatlakozón keresztül dugtak fel készülékre, 30 napig emlékszik. Ez azt jelenti, hogy csak és kizárólag azok a kiegészítők működnek a készülékkel annak lezárt formájában, amelyek ezen a 30 napos listán rajtavannak. Minden egyéb esetben az adatkommunikáció nem engedélyezett, csak ha feloldjuk a készülékünket. A lezárt formában való kiegészítők működése abban az esetben megszakad, ha egy eddig teljesen ismeretlen kiegészítőt dugnak a készülékre.
Keybag-ek
Az iOS összesen 5 úgynevezett keybag-et használ. Ezek a zsákok a különféle titkosítási osztályokhoz tartoznak:
- User
- Device
- Backup
- Escrow
- iCloud backup
Ahhoz, hogy egy jelkóddal védett készüléken a felhasználó nyomkodása nélkül sikerrel végbemenjen egy szoftverfrissítés, egy Unlock Token-re van szükség. Egyszerre egy Unlock Token létezhet a rendszerben. Az Unlock Token létrehozásához szükség van arra, hogy felhasználó megadja a jelkódját. Ha a felhasználó megadta azt, akkor a jelkódból, a Secure Enclave speciális azonosítójából és az escrow keybag saját azonosítójából együttesen keletkezik ez az Unlock Token, ami 20 percig lesz érvényes. Minden újonnan létrehozott token automatikusan érvényteleníti a korábbiakat.
Az Unlock Token egyetlen egy esetben lehet 8 óráig érvényes a 20 perc helyett:
- ha a készülék legalább iOS 12-n fut, és
- be van kapcsolva az automatikus szoftverfrissítés, és
- van is a készülékhez szoftverfrissítés, és
- és a felhasználó a “Telepítés később” frissítési módot választotta.
Az iPhone 6S vagy régebbi készülékeknél a tokenhez tartozik egy speciális, szigorúan monoton növekvő számláló, amelyet a Secure Enclave-ben tartanak nyílván. Ezt a számlálót a rendszer léptette (növelte), amikor:
- a tokent felhasználták, vagy
- az újraindítás utáni első feloldás megtörtént, vagy
- a frissítést elhalasztották, vagy
- egy speciális időzítő érvénytelenítette a tokent.
iPhone 6S vagy újabb készülékeken ez a speciális számláló már nem létezik, szimplán a Secure Enclave erre vonatkozó képességét használják. Ugyanitt érdekes megemlíteni, hogy egészen az iOS 13-ig ezt a tokent a létrehozása után azonnal kimásolták a készülék tárhelyére a Secure Enclave-ből. Az iOS 13 és az iPadOS 13.1-től kezdve viszont már erre nincs szükség.
A bejegyzés kiemelt képét készítette:
Matt Seymour