Android IKEv2: het gebruikerscertificaat en de CA doen verschillend werk
Het ene veld bewijst wie de telefoon is, het andere bepaalt welke gateway te vertrouwen. Het IKEv2-profiel in Android houdt ze gescheiden.
Een IKEv2-scherm in Android dat tegelijk om een gebruikerscertificaat en een CA-certificaat vraagt, lijkt hetzelfde twee keer te willen. Dat is niet zo. IKEv2 authenticeert beide partijen in beide richtingen binnen één uitwisseling, en de telefoon speelt in elke richting een andere rol: hij moet bewijzen wie hij is en beslissen welke gateway hij gelooft. Het gebruikerscertificaat beantwoordt de eerste vraag, de vertrouwde CA de tweede, en geen van beide vervangt de ander.
Twee richtingen van authenticatie in één uitwisseling
IKEv2 bouwt een besturingskanaal in twee fasen. De eerste onderhandelt algoritmen en sleutels; de tweede, IKE_AUTH, draagt één AUTH-lading van elke kant met zijn identiteit. Die lading is een handtekening of MAC over de uitwisseling en wordt geverifieerd tegen iets wat de ontvanger al vertrouwt.
De gateway bewijst zich met zijn eigen certificaat, en de telefoon valideert de keten tot een wortel die hij accepteert en controleert of de identiteit in het certificaat past bij de gateway die hij wilde bereiken; de telefoon bewijst zich met zijn inloggegevens, en de gateway verifieert die tegen de CA die het klantcertificaat heeft uitgegeven.
Dat is het hele mechanisme achter de twee velden. Het gebruikerscertificaat is een verklaring van de telefoon over zichzelf; het CA-veld is een verklaring over wie hij zal geloven. Een profiel met het ene maar niet het andere kan wederzijdse authenticatie niet voltooien, en opnieuw proberen verandert dat niet. Zelfs de fouten zien er anders uit: zonder gebruikerssleutel kan de telefoon niet ondertekenen, zonder vertrouwensanker kan hij het certificaat van de gateway niet accepteren.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Wat de Android-profielbouwer vraagt
De IKEv2-profielbouwer van Android biedt elke authenticatiemethode apart aan, niet als één certificaatmodus. De digitale handtekeningmethode neemt een gebruikerscertificaat, een privésleutel en een serverwortel-CA; de andere nemen een gebruikersnaam en wachtwoord, of een vooraf gedeelde sleutel.
Lees die handtekening goed, want hij beschrijft het mechanisme hierboven. Er is geen veld voor de privésleutel in de methode met gebruikersnaam en wachtwoord, en geen veld voor het vertrouwensanker van de gateway in PSK, omdat die methoden verschillende dingen bewijzen. Een wachtwoord in een certificaatveld levert een profiel op dat bij IKE_AUTH faalt met een melding die geen van beide noemt.
Het gedocumenteerde type privésleutel voor de digitale handtekening is RSA. Een menu met het label IPsec of certificaat betekent geen ECDSA-ondersteuning, en een profiel dat op die aanname is gebouwd faalt in de API van het platform voordat het netwerk erbij komt.
Waarom een openbaar gebruikerscertificaat niet genoeg is
De AUTH-lading is een handtekening over de uitwisseling, gemaakt met de privésleutel van de client. Het openbare certificaat laat de gateway een handtekening controleren, maar doet niets voor de telefoon, die de sleutel nodig heeft om er een te maken. Alleen .crt importeren en de sleutel achterlaten is de meest voorkomende vorm van deze fout.
De sleutelinfrastructuur van Android weerspiegelt dat: een klantidentiteit kiezen gaat via KeyChain, dat toegang tot de bijbehorende privésleutel vereist, niet alleen een certificaatinvoer. Een registratiepakket of apparaatbeheer dat het paar samen installeert is de normale weg naar een bruikbare identiteit; een bestand met de hand kopiëren meestal niet.
De twee onderdelen in het profiel zijn dus geen certificaatbundel en een kopie ervan. Het ene is een sleutelpaar waarmee het platform moet kunnen ondertekenen, het andere een vertrouwensanker waarmee het vergelijkt. Controleer ze als twee aparte feiten: kan dit profiel ondertekenen, en weet het wie te vertrouwen?
Vertrouwensankers horen bij een toepassing, niet bij de telefoon
Een wortel in het gebruikersarchief zorgt er niet voor dat elke Android-app die vertrouwt: sinds Android 7 moet een app dat kiezen via zijn netwerkbeveiligingsconfiguratie, en voor die versie werden door de gebruiker geïnstalleerde CA’s veel breder geaccepteerd. De vertrouwensconfiguratie kan verschillen, en een VPN-client die zijn eigen vertrouwensmateriaal beheert, kijkt misschien nooit in het archief. Daarom kan hetzelfde CA-bestand in de ene client werken en in de andere genegeerd lijken.
Daaruit volgen twee eigendomsmodellen. Een door het systeem beheerd profiel gebruikt de certificaatinstallatie van het apparaat of beheerdersregistratie en verwijst dan naar de bedoelde CA. Een door de app beheerde VPN houdt zijn eigen vertrouwensmateriaal en zijn eigen gedocumenteerde import, die volledig los kan staan van het instellingenscherm van Android. Daar wordt ook een gebroken keten gerepareerd.
Bepaal in welk model je zit voordat je iets importeert, en bevestig daarna de vertrouwenskeuze van het actieve profiel. Als de instructies van de operator en het menu van de client verschillen, wint voor die installatie het gedocumenteerde gedrag van de client, maar de CA moet nog steeds via een verifieerbaar kanaal van de operator komen. Een bestandsnaam is geen bewijs van wie hem heeft uitgegeven.
Eerst de modus, dan de bestanden
De certificaatmodus vereist een sleutelpaar van de client, de uitgevende CA aan de gatewayzijde, een vertrouwensanker voor het certificaat van de gateway en een verwachting welke identiteit dat certificaat moet dragen. Gebruikersnaam en wachtwoord vervangen het sleutelpaar door inloggegevens maar houden de vertrouwenseis aan de gateway. PSK vervangt beide door een gedeeld geheim en verandert het vertrouwensmodel in plaats van het te vereenvoudigen.
Wat je ook kiest, laat de normale validatie aan. Een optie zonder verificatie haalt de controle weg waarvoor het CA-veld bestaat; een ontbrekend vertrouwensanker repareert het niet. Hetzelfde geldt voor het accepteren van elk servercertificaat omdat de verbinding er zonder werkt.
Controleer daarna op de juiste plek: importeer het materiaal, verbind één keer en bevestig in de verbindingsdetails dat de identiteit van de gateway de verwachte is en dat het profiel de methode meldt die je bedoelde. Een geslaagde verbinding met de verkeerde methode is een configuratie die je nog niet begrijpt, en die faalt wanneer de operator een beleid aanscherpt.