Android IKEv2: el certificat d'usuari i el CA fan feines diferents
Un camp demostra qui és el telèfon, l'altre decideix de quina passarel·la refiar-se. El perfil IKEv2 d'Android els manté separats.
Una pantalla IKEv2 d'Android que demana alhora un certificat d'usuari i un certificat de CA sembla que vulgui el mateix dues vegades. No és així. IKEv2 autentica totes dues parts en totes dues direccions dins d'un sol intercanvi, i el telèfon fa un paper diferent en cada direcció: ha de demostrar qui és i ha de decidir de quina passarel·la es refia. El certificat d'usuari respon la primera pregunta, el CA de confiança la segona, i cap no substitueix l'altre.
Dues direccions d'autenticació en un sol intercanvi
IKEv2 estableix un canal de control en dues fases. La primera negocia algoritmes i claus; la segona, IKE_AUTH, porta una càrrega AUTH de cada costat amb la seva identitat. La càrrega és una signatura o un MAC calculat sobre l'intercanvi i es verifica contra alguna cosa en què el receptor ja confia.
La passarel·la es demostra amb el seu propi certificat; el telèfon valida la cadena fins a una arrel que accepta i comprova que la identitat del certificat coincideixi amb la passarel·la que volia assolir. El telèfon es demostra amb les seves credencials, i la passarel·la les verifica contra el CA que va emetre el certificat de client.
Aquest és tot el mecanisme darrere dels dos camps. El certificat d'usuari és una declaració del telèfon sobre si mateix; el camp de CA és una declaració sobre de qui es refiarà. Un perfil amb un però sense l'altre no pot completar l'autenticació mútua, i repetir-ho no ho canvia. Fins i tot les fallades es veuen diferents: sense clau d'usuari el telèfon no pot signar, i sense ancoratge de confiança no pot acceptar el certificat de la passarel·la.
| 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 |
Què demana el constructor de perfils d'Android
El constructor de perfils IKEv2 d'Android exposa cada mètode d'autenticació per separat, no com un sol mode de certificat. El mètode de signatura digital pren un certificat d'usuari, una clau privada i un CA arrel del servidor; els altres prenen un nom d'usuari i una contrasenya, o una clau prèviament compartida.
Llegeixi aquesta signatura amb atenció, perquè és el mecanisme anterior escrit en forma d'API. No hi ha cap camp per a la clau privada de l'usuari al mètode de nom i contrasenya, ni cap camp per a l'ancoratge de confiança al mètode PSK, perquè aquests mètodes demostren coses diferents. Enganxar una contrasenya en un camp de certificat produeix un perfil que falla a IKE_AUTH amb un missatge que no nomena cap dels dos.
El tipus de clau privada documentat per al mètode de signatura digital és RSA. Un menú etiquetat IPsec o certificat no implica suport per a ECDSA, i un perfil construït sobre aquest supòsit falla a l'API de la plataforma abans que la xarxa hi entri.
Per què no n'hi ha prou amb un certificat d'usuari públic
La càrrega AUTH és una signatura sobre l'intercanvi feta amb la clau privada del client. El certificat públic permet a la passarel·la comprovar una signatura, però no fa res pel telèfon, que necessita la clau per produir-ne una. Importar només .crt i deixar la clau enrere és la forma més comuna d'aquesta fallada.
La infraestructura de claus d'Android ho reflecteix. Triar una identitat de client passa per KeyChain, que requereix accés a la clau privada corresponent, no només una entrada de certificat. Un paquet d'inscripció o un flux de gestió de dispositius que instal·li la parella és la manera normal d'obtenir una identitat usable; copiar un fitxer a mà normalment no ho és.
Així, els dos elements del perfil no són un paquet de certificats i el seu duplicat. Un és una parella de claus amb què la plataforma ha de poder signar, l'altre és un ancoratge de confiança amb què compara. Comprovi'ls com dos fets separats: pot signar aquest perfil i sap de qui refiar-se?
Els ancoratges de confiança són de l'aplicació, no del telèfon
Instal·lar una arrel a l'emmagatzematge d'usuari no fa que totes les aplicacions Android se'n refiïn: des d'Android 7 una aplicació ha d'acceptar-ho a través de la seva configuració de seguretat de xarxa, i abans d'aquella versió els CA instal·lats per l'usuari s'acceptaven molt més àmpliament. La configuració de confiança pot diferir, i un client VPN que gestiona el seu propi material de confiança pot no mirar mai l'emmagatzematge d'usuari. Per això el mateix fitxer de CA pot funcionar en un client i semblar ignorat en un altre.
Se'n deriven dos models de propietat. Un perfil gestionat pel sistema fa servir la instal·lació de certificats del dispositiu o l'alta d'administrador, i després el perfil fa referència al CA previst. Un VPN gestionat per l'aplicació manté el seu material de confiança i la seva importació documentada, que pot ser completament separada de la pantalla de configuració d'Android. És també on es repara una cadena trencada.
Decideixi en quin model és abans d'importar res i confirmi després la selecció de confiança del perfil actiu. Si les instruccions de l'operador i el menú del client no coincideixen, per a aquella instal·lació guanya el comportament documentat del client, però el CA ha de venir igualment de l'operador per un canal que pugui verificar. El nom d'un fitxer no és prova de qui el va emetre.
Triï el mode i després els fitxers
El mode de certificat necessita una parella de claus de client, el CA emissor a la banda de la passarel·la, un ancoratge de confiança per al certificat de la passarel·la i una expectativa de quina identitat ha de portar aquest certificat. El nom i la contrasenya substitueixen la parella per credencials però mantenen el requisit de confiança en la passarel·la. PSK substitueix tots dos per un secret compartit i canvia el model de confiança en lloc de simplificar-lo.
Triï el que triï, mantingui la validació normal activada. Una opció de no verificar elimina la comprovació per a la qual existeix el camp de CA; no arregla un ancoratge de confiança absent. El mateix val per acceptar qualsevol certificat de servidor perquè la connexió funciona sense.
Després verifiqui al lloc correcte: importi el material, connecti un cop i confirmi als detalls de la connexió que la identitat de la passarel·la és la que esperava i que el perfil informa del mètode que volia. Una connexió correcta amb el mètode equivocat és una configuració que encara no entén, i fallarà quan l'operador endureixi una política.