Az előző részben már elhintettem, hogy Apple Pay-ről, meg jelszavakról, iMessage-ről is szó lesz majd, csak hát menet közben elfelejtettem, hogy volt közte sok minden más is. 🙂 Nem baj, most már biztosan el fogunk ide is jutni, ha pedig nem tudod, hogy mi ez az egész, akkor ajánlom figyelmedbe a korábbi 4 részt:
Jelszavak
Mindenki utálja a jelszavakat. Én is, noha sajnos nem nagyon van jelenleg egyszerűbb megoldás arra, hogy a saját privát szféránkat “egyszerű” módon megvédjük másoktól az internet világában (is).
Ajánlott jelszó
Éppen ezért, hogy a különféle weboldalakon és alkalmazásokban az Apple elősegítse azt, hogy ne mindenki ugyanazt a három egyszerű jelszót használja (mert azt könnyen megjegyzi), az iOS 12-vel bevezette az automatikusan generált, erős jelszó ajánlást. Ha megfigyelitek, ezek a rendszer által ajánlott jelszavak mindig tartalmaznak:
- 16 karakternyi kisbetűt és 1 nagybetűt
- 2 kötőjelet
- 1 számjegyet
Illetve technikai szinten még 71 bitnyi entrópiát. 🙂
Szóval amikor egy ilyen jelszót kapsz, akkor valahogy így néz ki:
myztav-zofvyk-7paGti
Gyenge jelszavak elleni védelem és tájékoztatás
Természetesen a rendszer megengedi, hogy a felhasználó felülbírálja ezt a döntést és megengedi, hogy saját jelszót használjunk. Azonban ilyenkor is bizonyos szabályok mentén akár figyelmeztet is minket. Ezek a szabályok a következőek:
- ugyanazon jelszó használata több alkalmazásban és/vagy weboldalon
- talál-e benne ismétlődésre utaló mintát (123123abab)
- van-e benne ismert helyettesítés (P@55word, P4ssw0rd)
- valamilyen felismerhető mintával rendelkezik-e (q1w2e3r4)
Ezek a szabályok a csak számokból álló PIN kódokra is igaz, mert sajnos még vannak olyan alkalmazások és/vagy weboldalak a világban, ahol csak számokból adható meg a fiókhoz tartozó jelszó.
Ha kíváncsiak vagytok, hogy rendelkeztek-e olyan jelszóval vagy jelszavakkal, amelyek a fenti szabályok ismeretében az iOS gyengének ítél, akkor a készüléken nyissátok meg a Beállítások – Jelszavak és fiókok – Weboldalak és App jelszavak listát. Itt keressétek a kicsi, felkiáltójeles háromszöges elemeket. Ha pedig az indoklás is érdekel miért felkiáltójeles, akkor az adott elemet megnyitva már olvashatjátok is a magyarázatot.
Jelszókitöltés
A jelszavak automatikus kitöltése az alkalmazásokban sem olyan egyszerű, mint azt elsőre gondolnánk. Biztos találkoztatok már azzal, hogy egy népszerű alkalmazásban a telepítést követően a rendszer felajánlja a felhasználónév – jelszó páros automatikus kitöltését. Erre úgy van lehetőség, hogy az alkalmazás fejlesztője egy speciális jogosultságot, a com.apple.developer.associated-domains-t beállítja. Ezek után, amikor az alkalmazás először mutatja a bejelentkezési képernyőt, az iOS maga egy TLS kapcsolaton keresztül felkeresi a társított weboldalt és meghatározott elérési útvonalakról megpróbál letölteni egy apple-app-site-association fájlt. Ha sikerül a fájlt letölteni és a benne tárolt információ megegyezik a com.apple.developer.associated-domains-ben lévővel, akkor mehet a jelszó automatikus kitöltése.
Az apple-app-site-association fájlt a következő két helyen keresi a rendszer:
- <domain>/apple-app-site-association
- <domain>/.well-known/apple-app-site-association
ahol a <domain> az adott weboldal címe, például: https://foursquare.com.
Jelszó megosztás AirDrop-on
Bár nem túl gyakori, de a mentett jelszavakat meg lehet osztani AirDrop-on keresztül is, viszont az így megosztható jelszavak az AirDrop beállításait teljes mértékben figyelmen kívül hagyja a rendszer és csak olyan személynek lehet továbbítani a jelszót, aki a névjegylistánkon rajta van. Ez egyébként az AirDrop – Contacts Only beállítása.
Jelszó megosztása Apple TV-vel
Képzeljük el, hogy frissen vettünk egy új Apple TV készüléket, elvégeztük a kezdeti beállításokat és elkezdenénk beállítani a kedvenc média alkalmazásaink: Spotify, Netflix stb. Ha tudatos és biztonságra törekvő felhasználók vagyunk, akkor nyilván az egyes szolgáltatásokhoz hosszú, biztonságos és eltérő jelszavakat használunk. Na most, ha láttatok már Apple TV távirányítót, akkor gyorsan rájöhettek, hogy ezeken a perifériákon a szövegbevitel sok mindenhez hasonlítható, de a kényelmeshez semmiképp. Szerencsére az Apple erre is gondolt. Amikor egy beviteli mezőt kiválasztasz az Apple TV alkalmazásban, akkor az Apple TV felajánlja, hogy a kért szöveget az iOS / iPadOS készülékeden is beviheted. Ennek a menete a következő:
- Bluetooth Low Energy protokoll (BLE) segítségével egy speciális jelet sugároz az Apple TV.
- Ha az Apple TV és az iOS / iPadOS készüléken is ugyanazt az Apple ID-t használják, akkor a két készülék összekapcsolását az Apple számunkra transzparens módon, titkosított, biztonságos módon megoldja.
- Ha azonban a két készülék eltérő Apple ID fiókhoz tartozik, akkor a két készülék párosításához egy PIN kód szükséges. Ezt a PIN kódot az Apple TV mutatja fel, a másik eszközön kell beírni. A PIN megadása után titkosított BLE kapcsolat jön létre. Hogy ezt a PIN-t a csatlakozó készüléken be lehessen vinni, ahhoz az iPhone-nak vagy iPad-nek:
- feloldva kell lennie és
- közel kell lennie az Apple TV távirányítójához.
És a legjobb kérdés amit eddig ebben a témában kaptam: “miért kell az Apple TV távirányítójához közel tenni a készüléket?” Nos azért, mert a távirányítón keresztül méri az Apple TV a készülék közelségét (felhasználva a Bluetooth jelerősséget – igen, az Apple TV távirányítója is Bluetooth-on keresztül kommunikál). Így győződik meg arról, hogy a csatlakoztatni kívánt készülék egy helységben van vele és nem mondjuk a szomszéd lakás teraszán.
Keychain
Az iCloud Keychain az egyik legkirályabb dolog, ami szerintem az Apple ökoszisztémában létezhet. Jelszavak, tanúsítványok tárolására hozták alapvetően létre és az egyik legjobb tulajdonsága az, hogy az azonos Apple ID alatt létező készülékek képesek egymás által tárolt adatokat megosztani. Például egy új regisztrációt csinálok egy weboldalon az iPad-en, akkor a szinkronizációt követően a mentett felhasználónév és jelszó a többi Apple készülékemen is elérhetővé válik.
Szinkronizálás
Amikor előszőr olvastam, hogy az Apple hogyan valósította meg a Keychain tartalmának szinkronizálását az eszközök között, bevallom elsőre nem is értettem. Körülbelül háromszor kellett átolvasnom, hogy megértsem. Szóval Keychain szinkronizálás következik. 🙂
- Amikor a iCloud Keychain-t legelőször bekapcsolják, az adott eszköz létrehoz egy “syncing circle”-t (továbbiakban kör). Ennek a körnek ő maga lesz az első, megbízható tagja. Minden tag a körben rendelkezik egy úgy nevezett “syncing identity”-vel (ami tulajdonképpen egy privát-publikus kulcs páros).
- Ezek után amikor a Keychain-t bekapcsolják egy második készüléken is (ugyanazon Apple ID alatt). Ekkor az iCloud Keychain észreveszi, hogy már létezik a kör, így a második készülék nem fog egy friss kört létrehozni, helyette jelezni fogja a felvételét a már meglévő körbe. Ehhez generál magának ez az eszköz is egy syncing identity-t.
- A sikeres syncing identity létrehozása után a második készülék összekészít egy “application ticket”-et (továbbiakban AI). Ebbe az AI-ba elhelyezi a saját publikus kulcsát.
- Hogy az összekészített AI-t a készülék az iCloud-ba fel tudja tölteni, megkéri a felhasználót, hogy adja meg a jelszavát. Így biztosítja azt, hogy az AI-ban tárolt információ a felhasználóhoz legyen kötve, és így lesz képes az első eszköz később olvasni és hitelesíteni azt.
- Sikeres feltöltés után, az első eszköz észreveszi, hogy az iCloud-ban megjelent egy AI. Az AI sikeres olvasásához az első eszköz is bekéri a felhasználótól a jelszót. A jelszó megadásával olvashatóvá és hitelesíthetővé válik az AI és ezzel egyidőben a második eszköz csatlakozási kérelmét is elfogadja a felhasználó.
- Végezetül, hogy az új eszköz tényleg bekerüljön a körbe, az első eszköz fogja és belerakja az AI-ból a második eszköz publikus kulcsát a körbe, majd újra aláírja mindkettejük syncing identity-jével illetve az iCloud jelszóból derivált kulccsal. Végezetül, a frissített kört feltölti a iCloud-ba.
Keychain helyreállítás (visszaszerzés)
Természetesen a legjobbakkal is megesik, hogy néha-néha egy homokszem csúszik a gépezetbe és kénytelenek vagyunk a helyreállításon keresztül visszaszerezni hozzáférésünk egy fiókhoz, rendszer, vagy jelen esetben a Keychain-ben tárolt adatainkhoz. Az Apple erre számos lehetőséget biztosít, azonban ezek száma véges. Legrosszabb esetben pedig végleg búcsút inthetünk az adatoknak és ez joggal van így.
Amikor a Keychain-hez való hozzáférés visszaszerzésének folyamata elindul, akkor a legelső lépés az, hogy a felhasználó azonosítja magát az Apple ID-hoz tartozó felhasználónévvel és jelszóval. Ha az azonosítás sikerült, akkor az iCloud mögött működő infrastruktúra egy szöveges üzenetben egy speciális kódot küld a felhasználónak a regisztrált telefonszámra. Az SMS-ben kapott kód megadása után utolsó lépésként a felhasználónak meg kell adnia az iCloud Security Code-ot. A HSM cluster a Secure Remote Password (SRP) protokoll használatával ellenőrzi, hogy a felhasználó által megadott kód helyes-e; magát a kódot az Apple egyébként nem ismerheti. A HSM cluster továbbá azt is ellenőrzi (a cluster minden tagja önállóan), hogy a felhasználó nem haladta-e meg az összes lehetséges próbálkozás számát (maximum 10). Ha a cluster összes tagja egyetért abban, hogy nekünk jogunk van hozzáférni a Keychain-ben tárolt adatokhoz, akkor végezetül ezt a jogot megkapjuk és a Keychain tartalma letölthetővé válik arra a készülékre, amin a folyamatot elindítottuk.
Pontosítás
Korábban azt írtam Twitter-en, hogy a Keychain recovery folyamatában 10+10 próbálkozásunk van összesen, mielőtt végleg tovaszáll a Keychain-hez való hozzáférésünk: 10 sikertelen próbálkozás után a HSM rendszer zárolja a kapcsolódó escrow rekordot és ezzel kényszerít minket arra, hogy az Apple-től újabb 10 próbálkozást kapjunk sikeres azonosítást követően. Valójában egy kicsit más a helyzet, lásd a következő bekezdést.
az iOS, iPadOS és macOS összesen 10 alkalommal engedi meg, hogy a Keychain-ben tárolt információhoz hozzáférést szerezzünk. Az első pár sikertelen próbálkozás után (nincs meghatározva, hogy mennyi az a pár) a rendszer automatikusan letiltja az escrow rekordot. Ekkor kötelességünk felhívni az Apple-t telefonon, átesni az azonosítási folyamaton. Ha az azonosítás sikeres volt, akkor megkapjuk a maradék próbálkozási lehetőséget. Ám ha ezután sem sikerül hozzáférést szerezni, amint elérjük az összesített 10 próbálkozást, a Keychain-ben tárolt adatainknak maximum már csak könnycseppekkel átitatott zsebkendőnkkel integethetünk, ugyanis az Apple a HSM modullal úgy védekezik a brute force támadás ellen, hogy megsemmisíti a rekordot.
Tehát a példa kedvéért megpróbáltuk feloldani a Keychain escrow rekordját négy alkalommal. A 4. próba után az iCloud lezárja a rekordot. Maradt még 6 próbálkozásunk, de ahhoz csak a telefonon keresztüli hitelesítés után férünk hozzá. Ha a maradék 6 próbával sem sikerült hozzáférnünk a Keychain-hez, akkor utána már nem is fogunk. Soha többé!
Apple Pay
Kis hazánkban tavaly májusban (2019. május 21-én) rajtolt el az OTP banknál az Apple Pay-jel történő fizetés lehetősége. Én is írtam róla pár bekezdést, ám most kicsit aláásunk a rendszernek és megnézzük, hogy a kényelmes funkciókon felül mi újság a biztonság háza táján.
Az Apple Pay megvalósításáért az úgy nevezett Secure Element (nem összekeverendő a Secure Enclave-vel) felel. A Secure Element egy speciális chip, amely megfelel a hatályos, elektronikus fizetési megoldásokat megvalósító iparági szabványnak és Java Card platformon funkcionál.
Szóval végső soron sajnos Steve Jobs (1955-2011) hiába tett ellene, hogy a Java valaha is Apple készülékbe kerüljön, azon Java fusson, ez nem valósult meg soha.
Amikor a telefonod vagy az órád egy POS terminálhoz tartod, akkor a POS terminál közvetlenül ezzel a Secure Element egységgel kommunikál, az NFC vezérlőn keresztül. Ez a kommunikáció teljes mértékben elkerüli a központi processzort, hiszen egy dedikált, hardveres buszon történik minden. A központi processzort azonban nem lehet figyelmen kívül hagyni akkor, amikor alkalmazáson belül szeretnénk vásárolni, bár igaz, hogy természetesen ekkor is teljes biztonságban, titkosítva történik a kommunikáció.
A tranzakció (fizetés) jóváhagyásáról egyébként a Secure Enclave gondoskodik, tehát a Secure Enclave engedélyezi, vagy tiltja meg, hogy a Secure Element-ből az információ kimenjen. A Secure Enclave és a Secure Element között a titkosított kommunikáció egy közös titkon (shared secret) alapul. Ennek a titoknak az alapját képezi a Secure Enclave és a Secure Element UID száma is. Mikor a kulcs létrejön, azt egy speciális HSM géppel olvassák ki a Secure Enclave-ből és töltik át a Secure Element-be.
Kártya digitalizálás
Amikor felhasználóként a bankkártyát hozzáadjuk az Apple Pay szolgáltatáshoz, akkor az alábbi folyamat játszódik le.
- A kártyaadatokat az Apple biztonságosan elküldi a kártyakibocsátóhoz.
- A kártyakibocsátó eldönti, hogy az adott kártya alkalmas-e arra, hogy az Apple Pay rendszerben használni lehessen.
- Ha nem, akkor folyamatnak vége. Ha alkalmas, akkor létrejön a megadott kártyaadatokból a Device Account Number (DAN).
- A generált DAN szám biztonságosan, titkosított formában jut el a Secure Element-ig. A bankkártya adatait, illetve a DAN számot sem látja az Apple. A bankkártya adatait nem is tárolják.
Device Account Number (DAN)
A DAN szám formára teljes mértékben a bankkártya 4×4 számsorozatára emlékeztet, azonban teljes mértékben az adott eszközre nézve egyedi. Tehát ha ugyanazt a bankkártyát ugyanazon a készüléken felveszed, majd letörlöd, minden egyes alkalommal más lesz a generált DAN szám. A DAN szám utolsó 4 számjegye (a bankkártyákhoz hasonlóan) megtekinthető a Beállítások – Wallet és Apple Pay – Adott bankkártya adatlapján.
A Secure Element-ben tárolt DAN szám soha nem kerül fel az Apple Pay szervereire, nem kerül bele az iCloud mentésbe és teljes mértékben izolált a rendszer többi részétől.
Messages
Az elmúlt évek egyik leghangosabb témája a szaksajtóban a valódi végponttól-végpontig történő titkosítás körül zajlott. A Viber, a WhatsApp, Google Hangouts mellett az Apple féle Messages infrastruktúra korát megelőzve rendelkezett ezzel a titkosítással. Lássuk hogyan működik az iMessage.
Üzenetek
A Messages szolgáltatás bekapcsolásakor az adott készüléken összesen négy kulcs generálódik (2 pár). Az egyik párt arra használja, hogy titkosítsa vele az üzeneteket, a másik párt pedig az üzenetek hitelesítésére. A kulcspárokból a privátokat természetesen az adott Apple ID-hoz tartozó Keychain-ben helyezi el a rendszer, a publikus kulcsokat pedig feltölti az Apple Identity Service-be (IDS).
Az Apple IDS szolgáltatása gondoskodik arról, hogy a világban ma működő összes Apple készülékhez társított APN (Apple Push Notification) azonosítóját, valamint a FaceTime és iMessagesben regisztrált telefonszámokat és email címeket tárolják, azokat egymáshoz társítsák. Tehát például az én esetemben az IDS-ben tárolt rekordom összesen 6 APN azonosítót (és ezzel együtt 5 publikus kulcsot) és 7 regisztrált elérhetőséget tartalmaz. Azért tartalmaz az IDS rekordom csak 5 publikus kulcsot, mert bár 6 Apple eszközöm van, abból csak 5 képes részt venni a Messages szolgáltatásban.
Az APN azonosító egyébként ahhoz kell, hogy az Apple képes legyen egyértelműen meghatározni azt, hogy a különféle értesítéseket mely készüléknek kell küldeni. APN azonosító nélkül egyetlen értesítést sem kapnál.
Érdekes, hogy az Apple nem egy szép “kerek” (2 valamilyen hatványa – kockavicc) számot választottak kulcsméretnek, hanem pontosan 1280-at. Tehát a generált kulcsok hossza 1280 bit. Gondolom ennek valamilyen kompatibilitási oka lehet – bár a dokumentum nem részletezi.
Amikor üzenetet küldünk egy másik iMessage szolgáltatásban résztvevő személynek, akkor a készülékünk a címzett publikus kulcsait az Apple IDS-ből letölti (bekékül a cím! :)). A küldő eszköz a címzett összes eszközéhez 88 bites, véletlenszerű értéket generál, majd fogja ezt a 88 bitnyi információt, a küldő és fogadó publikus kulcsát valamint az üzenetet és ezek kombinációjából egy 40 bites értéket derivál. A 88 + 40 bitnyi érték alkotja az üzenet titkosításához használt 128 bites kulcsot. A 40 bites érték segítségével lesz képes a fogadó fél az üzenet integritását ellenőrizni.
Ebből látható, hogy minden elküldött üzenetnek saját titkosító kulcsa van. Ezt az üzenetenkénti kulcsot fogadó eszköz publikus kulcsához társítják. A titkosított üzenetből és a hozzá tartozó kulcsból együttesen egy SHA-1 hash-t generál a küldő eszköz, majd ezt a hash-t aláírja a saját, privát kulcsával. Végül a titkosan, titkosított titok felkerül az APN szolgáltatásra, hogy eljusson a címzetthez.
Az üzenet váltás során keletkezett meta-adatok nincsenek titkosítva, az eszközök az APN infrastruktúrával forward secrecy TLS csatornán kommunikálnak.
Csatolmányok
Ugye a iMessage szolgáltatásban nem csak szöveget, hanem csatolmányokat is lehet küldeni (például fotókat). Mivel az APN 4 vagy 16 KB méretű üzeneteket képes csak továbbítani, ezért a csatolmányok kezelése másképp történik.
Amikor valami nagyot csatolunk egy üzenetünkhöz, akkor a rendszer a csatolt fájlt véletlenszerűen generált 256 bit hosszú kulccsal letitkosítja, majd a titkosított fájlt feltölti az iCloud-ra. A sikeres feltöltés után a csatolmányhoz tartozó kulcs és a csatolmányhoz tartozó egyedi azonosító (URI) a már korábban ismertetett módon kerül átadásra.
Find My szolgáltatás
Az Apple Find My (Lokátor????? Jézus. :D) szolgáltatását már nagy valószínűséggel mindenki ismeri. Amin az Apple dokumentumban nekem a téma kapcsán megakadt a szemem, az a szolgáltatás egyik új képessége: kikapcsolt (offline) eszközök megtalálására vonatkozik. A nagyon durva matematikai képletekbe nem bocsátkozom (akit érdekel egyébként a dokumentumban megnézheti, az Apple készséggel leírta), de dióhéjban a funkció – amely Bluetooth alapokon működik, messzebbről nézve a következőképpen működik.
Az elveszett eszköz (legyen E mint elveszett) a saját publikus kulcsát egy számlálóval kombinálva sugározza bele a nagyvilágba. Érdekes módon ez az üzenet pontosan akkora, hogy egyetlen Bluetooth üzenetben elfér és ezt a kulcsot 15 percenként cseréli. Amikor egy másik Apple készülék (M mint megtaláló) érzékeli E sugárzott üzenetét, akkor fogja és az érzékelt üzenetet valamint a saját helyzetét titkosítva továbbítja az Apple szolgáltatásához. Minél több M eszköztől érkezik információ E-ről, annál pontosabban behatárolható lesz E helyzete. E tulajdonosa egy másik Apple eszközön, vagy az iCloud.com-on bejelentkezve láthatja ezeket a jelentéseket, amiknek a tartalmát, a saját eszközén történő dekódolás után megtekinthet. az offline find my szolgáltatás automatikusan bekapcsolódik, miután az iOS 13, iPadOS 13.1 vagy a macOS 10.15 verzió telepítésre került.
Példa
Elhagyom a telefonom a parkban mert mondjuk leültem a padra és kicsúszott a zsebemből. Az offline find my képesség be van kapcsolva. Minél több olyan ember sétál el a pad mellett, aki Apple készülékkel rendelkezik, annál pontosabb helyzetet fogok kapni a készülékről, mondjuk az iPademen.
A bejegyzés kiemelt képét készítette:
Matt Seymour