Android IKEv2: brukersertifikatet og CA-en gjør forskjellige jobber

En IKEv2-skjerm i Android som ber om både et brukersertifikat og et CA-sertifikat samtidig, ser ut som den ber om det samme to ganger. Det gjør den ikke. IKEv2 autentiserer begge parter i begge retninger i samme utveksling, og telefonen har en annen rolle i hver retning: den må 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 av autentisering i én utveksling

IKEv2 bygger en kontrollkanal i to faser. Den første forhandler algoritmer og nøkler; den andre, IKE_AUTH, bærer en AUTH-nyttelast fra hver side sammen med dens identitet. Nyttelasten er en signatur eller en MAC over utvekslingen, og den verifiseres mot noe mottakeren allerede stoler på.

Gatewayen beviser seg med sitt eget sertifikat, og telefonen validerer kjeden opp til en rot den godtar og kontrollerer at identiteten i sertifikatet stemmer med gatewayen den ville nå; telefonen beviser seg med sine legitimasjoner, og gatewayen verifiserer dem mot CA-en som utstedte klientsertifikatet.

Det er hele mekanismen bak de to feltene. Brukersertifikatet er telefonens utsagn om seg selv; CA-feltet er et utsagn om hvem den vil tro på. En profil med det ene men ikke det andre kan ikke fullføre gjensidig autentisering, og gjentatte forsøk endrer ikke det. Selv feilene ser forskjellige ut: uten en brukernøkkel kan telefonen ikke signere i det hele tatt, og uten et tillitsanker kan den ikke godta gatewayens sertifikat.

Hva Androids profilbygger krever

Androids IKEv2-profilbygger tilbyr hver autentiseringsmetode for seg, ikke som én sertifikatmodus. Den digitale signaturmetoden tar et brukersertifikat, en privat nøkkel og en serverrot-CA; de andre tar et brukernavn og passord, eller en forhåndsdelt nøkkel.

Les den signaturen nøye, for den beskriver mekanismen over. Det finnes ikke noe felt for brukerens private nøkkel i brukernavn- og passordmetoden, og ikke noe felt for gatewayens tillitsanker i PSK, fordi disse metodene beviser forskjellige ting. Et passord limt inn i et sertifikatfelt gir en profil som feiler ved IKE_AUTH med en melding som ikke navngir noen av dem.

Den dokumenterte private nøkkeltypen for den digitale signaturmetoden er RSA. En meny merket IPsec eller sertifikat betyr ikke ECDSA-støtte, og en profil bygget på den antakelsen feiler i plattformens API før nettverket i det hele tatt er involvert.

Hvorfor et offentlig brukersertifikat ikke er nok

AUTH-nyttelasten er en signatur over utvekslingen laget med klientens private nøkkel. Det offentlige sertifikatet lar gatewayen kontrollere en signatur, men gjør ingenting for telefonen, som trenger nøkkelen for å lage den. Å importere bare .crt og la nøkkelen ligge igjen er den vanligste formen for denne feilen.

Androids nøkkelinfrastruktur gjenspeiler det: valg 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; håndkopiering av en fil er det sjelden.

Så de to elementene i profilen er 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 med. 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 installert i brukerlageret gjør ikke hver Android-applikasjon tillitsfull til den: siden Android 7 må en app velge det gjennom sin nettverkssikkerhetskonfigurasjon, og før den utgivelsen ble brukerinstallerte CA-er akseptert langt bredere. Tillitskonfigurasjonen kan variere, og en VPN-klient som administrerer sitt eget tillitsmateriale, ser kanskje aldri i brukerlageret. Derfor kan den samme CA-filen virke i én klient og se ignorert ut i en annen.

Derav følger to eierskapsmodeller. 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 Androids innstillingsskjerm. Det er også der en brutt kjede repareres.

Bestem hvilken modell du er i før du importerer noe, og bekreft deretter den aktive profilens tillitsvalg. Hvis operatørens instruksjoner og klientens meny er uenige, vinner klientens dokumenterte oppførsel for den installasjonen, men CA-en må fortsatt komme fra operatøren gjennom en kanal du kan verifisere. Et filnavn er ikke bevis for hvem som utstedte det.

Velg modus, 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 legitimasjon, 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 normale valideringen være på. Et alternativ uten verifisering fjerner kontrollen som CA-feltet finnes for; det reparerer ikke et manglende tillitsanker. Det samme gjelder å godta et hvilket som helst serversertifikat fordi forbindelsen virker uten.

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