Android IKEv2: brukarsertifikatet og CA-en gjer ulike oppgåver

Ein IKEv2-skjerm i Android som bed om både eit brukarsertifikat og eit CA-sertifikat på same tid, ser ut som han bed om det same to gonger. Det gjer han ikkje. IKEv2 autentiserer begge partar i begge retningar i same utveksling, og telefonen har ulik rolle i kvar retning: han må prova kven han er og avgjera kva gateway han trur på. Brukarsertifikatet svarar på det første spørsmålet, den betrudde CA-en på det andre, og ingen av dei erstattar den andre.

To retningar av autentisering i éi utveksling

IKEv2 byggjer ein kontrollkanal i to fasar. Den første forhandlar algoritmar og nøklar; den andre, IKE_AUTH, ber éi AUTH-nyttelast frå kvar side saman med identiteten hennar. Nyttelasta er ein signatur eller ein MAC over utvekslinga, og ho vert verifisert mot noko mottakaren alt stolar på.

Gatewayen provar seg med sitt eige sertifikat, og telefonen validerer kjeda opp til ei rot han godtek og kontrollerer at identiteten i sertifikatet passar med gatewayen han ville nå; telefonen provar seg med sine legitimasjonar, og gatewayen verifiserer dei mot CA-en som gav ut klient sertifikatet.

Det er heile mekanismen bak dei to felta. Brukarsertifikatet er telefonen sitt utsegn om seg sjølv; CA-feltet er eit utsegn om kven han vil tru på. Ein profil med det eine men ikkje det andre kan ikkje fullføra gjensidig autentisering, og gjentekne forsøk endrar ikkje det. Sjølv feila ser ulike ut: utan ein brukarnøkel kan telefonen ikkje signera i det heile, og utan eit tillitsanker kan han ikkje godta sertifikatet til gatewayen.

Kva Android-profilbyggjaren krev

Android sin IKEv2-profilbyggjar tilbyr kvar autentiseringsmetode for seg, ikkje som éin sertifikatmodus. Den digitale signaturmetoden tek eit brukarsertifikat, ein privat nøkel og ein serverrot-CA; dei andre tek eit brukarnamn og passord, eller ein nøkel som er delt på førehand.

Les den signaturen nøye, for han skildrar mekanismen ovanfor. Det finst ikkje noko felt for den private nøkelen i brukarnamn- og passordmetoden, og ikkje noko felt for tillitsankeret til gatewayen i PSK, fordi desse metodane provar ulike ting. Eit passord limt inn i eit sertifikatfelt gjev ein profil som feilar ved IKE_AUTH med ei melding som ikkje nemner nokon av dei.

Den dokumenterte private nøkeltypen for den digitale signaturmetoden er RSA. Ei meny merkt IPsec eller sertifikat tyder ikkje ECDSA-støtte, og ein profil bygd på den føresetnaden feilar i API-et til plattformen før nettet i det heile er med.

Kvifor eit offentleg brukarsertifikat ikkje er nok

AUTH-nyttelasta er ein signatur over utvekslinga laga med den private nøkelen til klienten. Det offentlege sertifikatet lèt gatewayen kontrollera ein signatur, men gjer ingenting for telefonen, som treng nøkelen for å laga han. Å importera berre .crt og lata nøkelen liggja att er den vanlegaste forma for denne feilen.

Nøkelinfrastrukturen i Android speglar dette: val av klientidentitet går gjennom KeyChain, som krev tilgang til den tilhøyrande private nøkelen, ikkje berre ei sertifikatoppføring. Ein registreringspakke eller ein einingadministrasjonsflyt som installerer paret saman, er den normale vegen til ein brukande identitet; handkopiering av ei fil er det sjeldan.

Så dei to elementa i profilen er ikkje ein sertifikatbunt og ein kopi av han. Det eine er eit nøkelpar som plattformen må kunna signera med, det andre er eit tillitsanker han samanliknar med. Kontroller dei som to åtskilde fakta: kan denne profilen signera, og veit han kven han skal stole på?

Tillitsanker høyrer til ein applikasjon, ikkje telefonen

Ei rot installert i brukarlageret gjer ikkje kvar Android-applikasjon trygg på ho: sidan Android 7 må ein app velja det gjennom nettverks tryggleikskonfigurasjonen sin, og før den utgåva vart brukarinstallerte CA-ar godtekne mykje breiare. Tillitskonfigurasjonen kan variera, og ein VPN-klient som styrer sitt eige tillitsmateriale, ser kanskje aldri i brukarlageret. Difor kan den same CA-fila verka i ein klient og sjå oversedd ut i ein annan.

Av dette følgjer to eigarmodellar. Ein systemstyrt profil nyttar sertifikatinstallasjonen til eininga eller administratorregistrering og viser deretter til den tiltenkte CA-en. Ein appstyrt VPN held på sitt eige tillitsmateriale og sin eigen dokumenterte import, som kan vera heilt åtskild frå innstillingsskjermen i Android. Det er òg der ei broten kjeda vert reparert.

Avgjer kva modell du er i før du importerer noko, og stadfest deretter tillitsvalet til den aktive profilen. Viss instruksjonane til operatøren og menyen til klienten er usamde, vinn den dokumenterte åtferda til klienten for den installasjonen, men CA-en må framleis koma frå operatøren gjennom ein kanal du kan verifisera. Eit filnamn er ikkje prov for kven som gav det ut.

Vel modus, deretter filene

Sertifikatmodusen krev eit klientnøkelpar, den utgivande CA-en på gateway-sida, eit tillitsanker for sertifikatet til gatewayen og ei forventing om kva identitet sertifikatet skal bera. Brukarnamn og passord erstattar nøkelparet med legitimasjon, men held på tillitskravet til gatewayen. PSK erstattar begge med ein delt løyndom og endrar tillitsmodellen i staden for å forenkla han.

Kva du enn vel, lat den normale valideringa vera på. Eit alternativ utan verifisering fjernar kontrollen som CA-feltet finst for; det reparerer ikkje eit manglande tillitsanker. Det same gjeld å godta eit kva som helst serversertifikat fordi sambandet verkar utan.

Kontroller deretter på rett stad: importer materialet, kople til éin gong, og stadfest i tilkoplingsdetaljane at identiteten til gatewayen er den venta og at profilen rapporterer metoden du hadde tenkt. Eit vellukka samband med feil metode er ein konfigurasjon du enno ikkje forstår, og han vil feila når operatøren strammar inn ein policy.