Android IKEv2: brukersertifikatet og CA-sertifikatet har ulike oppgaver

En IKEv2-skjerm i Android som ber om både et brukersertifikat og et CA-sertifikat samtidig, ser ut til å be om det samme to ganger. Slik er det ikke. IKEv2 autentiserer begge sider i begge retninger i én utveksling, og telefonen har forskjellig rolle i hver retning: den skal bevise hvem den er, og avgjøre hvilken gateway den tror på. Brukersertifikatet svarer på det første spørsmålet, den betrodde CA-en på det andre, og ingen av dem erstatter den andre.

To retninger for autentisering i én utveksling

IKEv2 etablerer en kontrollkanal i to faser. Fasen først forhandler om algoritmer og nøkler; fasen deretter, IKE_AUTH, frakter en AUTH-nyttelast fra hver side sammen med identiteten til siden. Nyttelasten er en signatur eller en MAC over utvekslingen, og den verifiseres mot noe mottakeren allerede har tillit til.

Gatewayen beviser sin identitet med sitt eget sertifikat, og telefonen validerer kjeden fram til en rot den godtar og kontrollerer at identiteten i sertifikatet samsvarer med gatewayen den ønsket å nå; telefonen beviser sin identitet med sine egne legitimasjoner, og gatewayen verifiserer dem mot CA-en som utstedte klient sertifikatet.

Dette er hele mekanismen bak de to feltene. Brukersertifikatet er telefonens erklæring om seg selv; CA-feltet er en erklæring om hvem den vil tro på. En profil som har det ene men ikke det andre, kan ikke fullføre gjensidig autentisering, og gjentatte forsøk endrer ikke på det. Selv feilene ser forskjellige ut: uten brukernøkkel kan telefonen ikke signere i det hele tatt, og uten tillitsanker kan den ikke godta sertifikatet til gatewayen.

Hva profilbyggeren i Android krever

IKEv2-profilbyggeren i Android tilbyr hver autentiseringsmetode hver for seg, ikke som én sertifikatmodus. Metoden for digital signatur tar et brukersertifikat, en privat nøkkel og en serverrot-CA; de øvrige tar brukernavn og passord, eller en nøkkel som er delt på forhånd.

Les den signaturen nøye, fordi den beskriver mekanismen ovenfor. Det finnes ikke noe felt for den private nøkkelen i metoden med brukernavn og passord, og ikke noe felt for gatewayens tillitsanker i PSK, fordi disse metodene beviser forskjellige ting. Et passord som limes inn i et sertifikatfelt gir en profil som feiler ved IKE_AUTH, med en melding som ikke nevner noen av dem.

Den dokumenterte typen privat nøkkel for metoden med digital signatur er RSA. En meny merket IPsec eller sertifikat betyr ikke støtte for ECDSA, og en profil som bygges på den antakelsen, feiler i API-et til plattformen før nettverket i det hele tatt er inne i bildet.

Hvorfor et offentlig brukersertifikat ikke er tilstrekkelig

AUTH-nyttelasten er en signatur over utvekslingen som er laget med den private nøkkelen til klienten. Det offentlige sertifikatet lar gatewayen kontrollere en signatur, men gjør ingenting for telefonen, som trenger nøkkelen for å produsere den. Å importere bare .crt og la nøkkelen bli igjen er den vanligste varianten av denne feilen.

Nøkkelinfrastrukturen i Android gjenspeiler dette: valget av klientidentitet går gjennom KeyChain, som krever tilgang til den tilhørende private nøkkelen, ikke bare en sertifikatoppføring. En registreringspakke eller en enhetsadministrasjonsflyt som installerer paret sammen, er den normale veien til en brukbar identitet; å kopiere en fil for hånd er det vanligvis ikke.

De to elementene i profilen er altså ikke en sertifikatbunt og en kopi av den. Det ene er et nøkkelpar som plattformen må kunne signere med, det andre er et tillitsanker den sammenligner mot. Kontroller dem som to atskilte fakta: kan denne profilen signere, og vet den hvem den skal stole på?

Tillitsankre tilhører en applikasjon, ikke telefonen

En rot som installeres i brukerlageret, gjør ikke at hver Android-applikasjon stoler på den: siden Android 7 må en app velge dette gjennom sin egen nettverkssikkerhetskonfigurasjon, og før den utgivelsen ble brukerinstallerte CA-er godtatt langt bredere. Tillitskonfigurasjonen kan variere, og en VPN-klient som selv administrerer tillitsmaterialet sitt, ser kanskje aldri i brukerlageret. Derfor kan den samme CA-filen virke i én klient og virke ignorert i en annen.

To eierskapsmodeller følger av dette. En systemadministrert profil bruker enhetens sertifikatinstallasjon eller administratorregistrering, og refererer deretter til den tiltenkte CA-en. En appadministrert VPN beholder sitt eget tillitsmateriale og sin egen dokumenterte import, som kan være helt atskilt fra innstillingsskjermen i Android. Det er også der en brutt kjede repareres.

Bestem hvilken modell du befinner deg i før du importerer noe, og bekreft deretter tillitsvalget til den aktive profilen. Hvis instruksjonene fra operatøren og menyen i klienten ikke stemmer overens, vinner den dokumenterte oppførselen til klienten for den installasjonen, men CA-en må fortsatt komme fra operatøren gjennom en kanal du kan verifisere. Et filnavn er ikke bevis på hvem som utstedte det.

Velg modus først, deretter filene

Sertifikatmodusen krever et klientnøkkelpar, den utstedende CA-en på gateway-siden, et tillitsanker for gatewayens sertifikat og en forventning om hvilken identitet sertifikatet skal bære. Brukernavn og passord erstatter nøkkelparet med legitimasjoner, men beholder tillitskravet til gatewayen. PSK erstatter begge med en delt hemmelighet og endrer tillitsmodellen i stedet for å forenkle den.

Uansett hva du velger, la den vanlige valideringen være slått på. Et alternativ uten verifisering fjerner den kontrollen som CA-feltet finnes for; det reparerer ikke et manglende tillitsanker. Det samme gjelder å godta hvilket som helst serversertifikat fordi forbindelsen virker uten det.

Deretter kontrollerer du på riktig sted: importer materialet, koble til én gang, og bekreft i tilkoblingsdetaljene at gatewayens identitet er den forventede, og at profilen rapporterer den metoden du hadde til hensikt. En vellykket tilkobling med feil metode er en konfigurasjon du ennå ikke forstår, og den vil feile når operatøren skjerper en policy.