Android IKEv2: brugercertifikatet og CA'en har forskellige opgaver

En IKEv2-skærm i Android, der på én gang beder om et brugercertifikat og et CA-certifikat, ser ud til at ville det samme to gange. Det gør den ikke. IKEv2 autentificerer begge parter i begge retninger i samme udveksling, og telefonen har en anden rolle i hver retning: den skal bevise, hvem den er, og afgøre, hvilken gateway den tror på. Brugercertifikatet besvarer det første spørgsmål, den betroede CA det andet, og ingen af dem kan erstatte den anden.

To retninger af autentificering i én udveksling

IKEv2 opbygger en kontrolkanal i to faser. Den første forhandler algoritmer og nøgler; den anden, IKE_AUTH, bærer en AUTH-nyttelast fra hver side sammen med dens identitet. Nyttelasten er en signatur eller en MAC over udvekslingen og kontrolleres mod noget, modtageren allerede stoler på.

Gatewayen beviser sig selv med sit eget certifikat; telefonen validerer kæden op til en rod, den accepterer, og kontrollerer, at identiteten i certifikatet svarer til den gateway, den ville nå. Telefonen beviser sig selv med sine legitimationsoplysninger, og gatewayen kontrollerer dem mod den CA, der udstedte klientcertifikatet.

Det er hele mekanismen bag de to felter. Brugercertifikatet er telefonens udsagn om sig selv; CA-feltet er et udsagn om, hvem telefonen vil tro på. En profil med den ene men ikke den anden kan ikke gennemføre gensidig autentificering, og gentagne forsøg ændrer ikke det. Selv fejlene ser forskellige ud: uden en brugernøgle kan telefonen slet ikke signere, og uden et tillidsanker kan den ikke acceptere gatewayens certifikat.

Hvad Androids profilbygger kræver

Androids IKEv2-profilbygger udstiller hver autentificeringsmetode for sig, ikke som én certifikattilstand. Den digitale signaturmetode tager et brugercertifikat, en privat nøgle og en serverrod-CA; de øvrige tager et brugernavn og en adgangskode eller en på forhånd delt nøgle.

Læs den signatur grundigt, for den beskriver mekanismen ovenfor. Der er intet felt til brugerens private nøgle i brugernavn/adgangskode-metoden og intet felt til gatewayens tillidsanker i PSK-metoden, fordi de metoder beviser forskellige ting. En adgangskode i et certifikatfelt giver en profil, der fejler ved IKE_AUTH med en meddelelse, der ikke nævner nogen af dem.

Den dokumenterede private nøgletype til den digitale signaturmetode er RSA. En menu mærket IPsec eller certifikat betyder ikke ECDSA-understøttelse, og en profil bygget på den antagelse fejler i platformens API, før netværket overhovedet kommer ind.

Hvorfor et offentligt brugercertifikat ikke er nok

AUTH-nyttelasten er en signatur over udvekslingen lavet med klientens private nøgle. Det offentlige certifikat lader gatewayen kontrollere en signatur, men gør intet for telefonen, som har brug for nøglen for at skabe den. Kun at importere .crt og lade nøglen blive tilbage er den mest almindelige form for denne fejl.

Androids nøgleinfrastruktur afspejler det. Valg af en klientidentitet går gennem KeyChain, som kræver adgang til den tilsvarende private nøgle, ikke blot en certifikatpost. En tilmeldingspakke eller en enhedshåndteringsproces, der installerer parret sammen, er den normale vej til en brugbar identitet; håndkopiering af en fil er det sjældent.

Så de to elementer i profilen er ikke en certifikatpakke og en kopi af den. Det ene er et nøglepar, som platformen skal kunne signere med, det andet er et tillidsanker, den sammenligner med. Kontroller dem som to adskilte fakta: kan denne profil signere, og ved den, hvem den skal stole på?

Tillidsankre tilhører en applikation, ikke telefonen

En rod installeret i brugerlageret får ikke hver Android-applikation til at stole på den: siden Android 7 skal en app tilvælge det via sin netværkssikkerhedskonfiguration, og før den udgivelse blev brugerinstallerede CA'er accepteret langt bredere. Tillidskonfigurationen kan variere, og en VPN-klient, der selv styrer sit tillidsmateriale, ser måske aldrig brugerlageret. Derfor kan den samme CA-fil virke i én klient og se ignoreret ud i en anden.

Deraf følger to ejerskabsmodeller. En systemstyret profil bruger enhedens certifikatinstallation eller administratorregistrering og henviser derefter til den tilsigtede CA. En appstyret VPN holder sit eget tillidsmateriale og sin egen dokumenterede import, som kan være helt adskilt fra Androids indstillingsskærm. Det er også der, en brudt kæde repareres.

Afgør, hvilken model du er i, før du importerer noget, og bekræft derefter den aktive profils tillidsvalg. Hvis operatørens instruktioner og klientens menu er uenige, vinder klientens dokumenterede adfærd for den installation, men CA'en skal stadig komme fra operatøren ad en kanal, du kan verificere. Et filnavn er ikke bevis for, hvem der udstedte det.

Vælg tilstand, derefter filerne

Certifikattilstand kræver et klientnøglepar, den udstedende CA på gatewayens side, et tillidsanker til gatewayens certifikat og en forventning om, hvilken identitet certifikatet skal bære. Brugernavn og adgangskode erstatter nøgleparret med legitimationsoplysninger, men bevarer kravet om tillid til gatewayen. PSK erstatter begge med en delt hemmelighed og ændrer tillidsmodellen i stedet for at forenkle den.

Uanset hvad du vælger, så lad den normale validering være slået til. En indstilling uden verifikation fjerner den kontrol, CA-feltet findes for at udføre; den retter ikke et manglende tillidsanker. Det samme gælder accept af ethvert servercertifikat, fordi forbindelsen virker uden.

Kontroller derefter på det rigtige sted: importer materialet, forbind én gang, og bekræft i forbindelsens detaljer, at gatewayens identitet er den forventede, og at profilen angiver den metode, du havde til hensigt. En vellykket forbindelse med den forkerte metode er en konfiguration, du endnu ikke forstår, og den fejler, når operatøren strammer en politik.