Android IKEv2: a felhasználói tanúsítvány és a CA más feladatot lát el

Az Android IKEv2-képernyője, amely egyszerre kér felhasználói tanúsítványt és CA-tanúsítványt, úgy tűnik, mintha ugyanazt kérné kétszer. Nem így van. Az IKEv2 egyetlen csere keretében mindkét felet mindkét irányban hitelesíti, és a telefon mindkét irányban más szerepet játszik: bizonyítania kell, ki ő, és el kell döntenie, melyik átjáróban hisz. A felhasználói tanúsítvány az első kérdésre válaszol, a megbízható CA a másodikra, és egyik sem helyettesíti a másikat.

A hitelesítés két iránya egyetlen cserében

Az IKEv2 két fázisban épít vezérlőcsatornát. Az első algoritmusokról és kulcsokról tárgyal; a második, az IKE_AUTH, mindkét oldalról egy AUTH-terhet szállít az adott oldal identitásával együtt. A teher a cserére számított aláírás vagy MAC, és olyasmihez ellenőrzik, amiben a fogadó már megbízik.

Az átjáró a saját tanúsítványával bizonyítja magát, a telefon pedig a láncot egy általa elfogadott gyökériq ellenőrzi, és azt is, hogy a tanúsítvány identitása megegyezik-e a célzott átjáróval; a telefon a saját hitelesítő adataival bizonyítja magát, és az átjáró ezeket az ügyféltanúsítványt kiadó CA-val ellenőrzi.

Ez a teljes mechanizmus a két mező mögött. A felhasználói tanúsítvány a telefon nyilatkozata önmagáról; a CA-mező nyilatkozat arról, kiben fog hinni. Az egyikkel a másik nélküli profil nem tudja befejezni a kölcsönös hitelesítést, és az ismételt próbálkozás ezen nem változtat. Még a hibák is másképp néznek ki: felhasználói kulcs nélkül a telefon egyáltalán nem tud aláírni, megbízhatósági horgony nélkül nem tudja elfogadni az átjáró tanúsítványát.

Mit kér az Android profilépítője

Az Android IKEv2-profilépítője minden hitelesítési módot külön kínál, nem egyetlen tanúsítvány-módként. A digitális aláírás módja felhasználói tanúsítványt, privát kulcsot és kiszolgáló-gyökér CA-t vesz; a többiek felhasználónevet és jelszót vagy előre megosztott kulcsot.

Olvassa el figyelmesen ezt az aláírást, mert a fenti mechanizmust írja le. A felhasználónév-jelszó módban nincs mező a privát kulcsnak, a PSK módban pedig nincs mező az átjáró megbízhatósági horgonyának, mert ezek a módok más-más dolgot bizonyítanak. A tanúsítvány mezőjébe illesztett jelszó olyan profilt ad, amely az IKE_AUTH-nál elbukik egy üzenettel, amely egyiket sem nevezi meg.

A digitális aláírás módjához dokumentált privát kulcstípus az RSA. Az IPsec vagy tanúsítvány feliratú menü nem jelent ECDSA-támogatást, és az erre a feltevésre épített profil a platform API-jánál bukik el, mielőtt a hálózat egyáltalán szóba kerülne.

Miért nem elég egy nyilvános felhasználói tanúsítvány

Az AUTH-teher a cserére az ügyfél privát kulcsával készült aláírás. A nyilvános tanúsítvány engedi az átjárónak az aláírás ellenőrzését, de a telefonnak nem segít, mert az aláírás létrehozásához kulcs kell. Csak a .crt importálása és a kulcs hátrahagyása a hiba leggyakoribb formája.

Az Android kulcs-infrastruktúrája ezt tükrözi: az ügyfélidentitás kiválasztása a KeyChainen át megy, amely a megfelelő privát kulcshoz való hozzáférést igényel, nem csupán egy tanúsítványbejegyzést. Az a regisztrációs csomag vagy eszközkezelési folyamat, amely a párt együtt telepíti, a szokásos út a használható identitáshoz; a fájl kézi másolása általában nem az.

Tehát a profil két eleme nem tanúsítványköteg és annak másolata. Az egyik kulcspár, amellyel a platformnak alá kell tudnia írni, a másik megbízhatósági horgony, amelyhez hasonlít. Ellenőrizze őket két külön tényként: tud-e ez a profil aláírni, és tudja-e, kiben bízzon?

A megbízhatósági horgonyok az alkalmazáshoz tartoznak, nem a telefonhoz

A felhasználói tárolóba telepített gyökér nem teszi minden Android-alkalmazást bizalmassá iránta: az Android 7 óta az alkalmazásnak a hálózati biztonsági beállításain keresztül kell ezt választania, és e kiadás előtt a felhasználó által telepített CA-kat sokkal szélesebben elfogadták. A bizalmi beállítás alkalmazásonként eltérhet, és előfordulhat, hogy egy saját bizalmi anyagát kezelő VPN-kliens soha nem néz a felhasználói tárolóba. Ezért ugyanaz a CA-fájl működhet az egyik kliensben és tűnhet figyelmen kívül hagyottnak a másikban.

Ebből két tulajdonosi modell következik. A rendszer által kezelt profil az eszköz tanúsítványtelepítését vagy rendszergazdai regisztrációt használ, majd a szándékolt CA-ra hivatkozik. Az alkalmazás által kezelt VPN a saját bizalmi anyagát és saját dokumentált importját tartja, amely teljesen elkülönülhet az Android beállítási képernyőjétől. Itt javítják a megszakadt láncot is.

Döntse el, melyik modellben van, mielőtt bármit importál, majd erősítse meg az aktív profil bizalmi választását. Ha az üzemeltető utasításai és a kliens menüje ellentmondanak, annál a telepítésnél a kliens dokumentált viselkedése győz, de a CA-nak továbbra is az üzemeltetőtől kell jönnie egy ellenőrizhető csatornán. Egy fájlnév nem bizonyítja, ki adta ki.

Előbb a mód, aztán a fájlok

A tanúsítvány-módhoz ügyfélkulcs-pár, az átjáró oldalán a kiadó CA, megbízhatósági horgony az átjáró tanúsítványához és elvárás arról, milyen identitást kell hordoznia. A felhasználónév és jelszó hitelesítő adatokkal váltja fel a kulcspárt, de megtartja az átjáróba vetett bizalom követelményét. A PSK mindkettőt közös titokkal váltja fel, és inkább megváltoztatja, mint egyszerűsíti a bizalmi modellt.

Bármit is választ, hagyja bekapcsolva a szokásos ellenőrzést. Az ellenőrzés nélküli lehetőség eltávolítja azt az ellenőrzést, amelyre a CA-mező való; a hiányzó megbízhatósági horgonyt nem javítja. Ugyanez vonatkozik bármely kiszolgálótanúsítvány elfogadására azért, mert a kapcsolat nélküle is működik.

Aztán a megfelelő helyen ellenőrizze: importálja az anyagot, csatlakozzon egyszer, és a kapcsolat részleteiben erősítse meg, hogy az átjáró identitása a várt, és a profil a szándékolt módszert jelenti. A rossz módszerrel létrejött sikeres kapcsolat olyan konfiguráció, amelyet még nem ért, és el fog bukni, amikor az üzemeltető szigorít egy szabályt.