Android IKEv2: certificatul de utilizator și CA au sarcini diferite
Un câmp dovedește cine este telefonul, celălalt decide în ce gateway să ai încredere. Profilul IKEv2 din Android le ține separate.
Un ecran IKEv2 din Android care cere simultan un certificat de utilizator și un certificat CA pare să ceară același lucru de două ori. Nu este așa. IKEv2 autentifică ambele părți în ambele direcții într-un singur schimb, iar telefonul are un rol diferit în fiecare direcție: trebuie să demonstreze cine este și să decidă în ce gateway crede. Certificatul de utilizator răspunde la prima întrebare, CA de încredere la a doua, și niciunul nu îl înlocuiește pe celălalt.
Două direcții de autentificare într-un singur schimb
IKEv2 construiește un canal de control în două faze. Prima negociază algoritmi și chei; a doua, IKE_AUTH, transportă un payload AUTH de la fiecare parte împreună cu identitatea ei. Payload-ul este o semnătură sau un MAC peste schimb și este verificat față de ceva în care receptorul are deja încredere.
Gateway-ul se dovedește cu propriul certificat, iar telefonul validează lanțul până la o rădăcină pe care o acceptă și verifică dacă identitatea din certificat corespunde gateway-ului vizat; telefonul se dovedește cu propriile credențiale, iar gateway-ul le verifică față de CA care a emis certificatul de client.
Acesta este întregul mecanism din spatele celor două câmpuri. Certificatul de utilizator este o declarație a telefonului despre sine; câmpul CA este o declarație despre în cine va crede. Un profil cu unul fără celălalt nu finalizează autentificarea reciprocă, iar reluarea nu schimbă asta. Chiar și eșecurile arată diferit: fără cheie de utilizator telefonul nu poate semna, iar fără ancoră de încredere nu poate accepta certificatul gateway-ului.
| 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 |
Ce cere constructorul de profiluri din Android
Constructorul de profiluri IKEv2 din Android expune fiecare metodă de autentificare separat, nu ca un singur mod de certificat. Metoda semnăturii digitale ia un certificat de utilizator, o cheie privată și o CA rădăcină de server; celelalte iau un nume de utilizator și o parolă, sau o cheie partajată în prealabil.
Citiți cu atenție acea semnătură, pentru că descrie mecanismul de mai sus. Nu există câmp pentru cheia privată în metoda cu nume și parolă și nici câmp pentru ancora de încredere a gateway-ului în PSK, pentru că aceste metode dovedesc lucruri diferite. O parolă lipită într-un câmp de certificat produce un profil care eșuează la IKE_AUTH cu un mesaj care nu numește niciunul dintre ele.
Tipul de cheie privată documentat pentru semnătura digitală este RSA. Un meniu etichetat IPsec sau certificat nu implică suport ECDSA, iar un profil construit pe această presupunere eșuează în API-ul platformei înainte să apară rețeaua.
De ce un certificat public nu este suficient
Payload-ul AUTH este o semnătură peste schimb făcută cu cheia privată a clientului. Certificatul public permite gateway-ului să verifice o semnătură, dar nu face nimic pentru telefon, care are nevoie de cheie ca să o producă. Importul doar al fișierului .crt și lăsarea cheii în urmă este cea mai frecventă formă a acestei erori.
Infrastructura de chei a Android reflectă asta: alegerea unei identități de client trece prin KeyChain, care cere acces la cheia privată corespunzătoare, nu doar o intrare de certificat. Un pachet de înrolare sau un flux de administrare a dispozitivelor care instalează perechea împreună este calea normală; copierea manuală a fișierului de obicei nu este.
Așadar cele două elemente nu sunt un pachet de certificate și duplicatul lui. Unul este o pereche de chei cu care platforma trebuie să poată semna, celălalt este o ancoră de încredere cu care compară. Verificați-le ca două fapte separate: poate acest profil să semneze și știe în cine să aibă încredere?
Ancorele de încredere aparțin aplicației, nu telefonului
O rădăcină instalată în depozitul utilizatorului nu face fiecare aplicație Android să aibă încredere în ea: din Android 7 o aplicație trebuie să opteze prin configurația de securitate a rețelei, iar înainte de acea versiune CA-urile instalate de utilizator erau acceptate mult mai larg. Configurația de încredere poate varia, iar un client VPN care își administrează propriul material de încredere poate să nu se uite niciodată în depozit. De aceea același fișier CA poate funcționa într-un client și părea ignorat în altul.
Rezultă două modele. Un profil administrat de sistem folosește instalarea certificatelor dispozitivului sau înrolarea administratorului și apoi face referire la CA dorită. Un VPN administrat de aplicație își păstrează propriul material de încredere și propria importare documentată, care poate fi complet separată de ecranul de setări Android. Tot acolo se repară un lanț rupt.
Decideți în ce model sunteți înainte de a importa ceva, apoi confirmați selecția de încredere a profilului activ. Dacă instrucțiunile operatorului și meniul clientului nu coincid, pentru acea instalare câștigă comportamentul documentat al clientului, dar CA trebuie totuși să vină de la operator printr-un canal pe care îl puteți verifica. Numele unui fișier nu este dovada cine l-a emis.
Alegeți modul, apoi fișierele
Modul certificat cere o pereche de chei de client, CA emitentă pe partea gateway-ului, o ancoră de încredere pentru certificatul gateway-ului și o așteptare privind identitatea pe care trebuie să o poarte. Numele și parola înlocuiesc perechea cu credențiale, dar păstrează cerința de încredere în gateway. PSK le înlocuiește pe ambele cu un secret partajat și schimbă modelul de încredere în loc să îl simplifice.
Orice ați alege, lăsați validarea normală activă. O opțiune fără verificare elimină verificarea pentru care există câmpul CA; nu repară o ancoră de încredere lipsă. La fel pentru acceptarea oricărui certificat de server pentru că conexiunea funcționează fără el.
Apoi verificați în locul potrivit: importați materialul, conectați-vă o dată și confirmați în detalii că identitatea gateway-ului este cea așteptată și că profilul raportează metoda dorită. O conexiune reușită cu metoda greșită este o configurație pe care încă nu o înțelegeți și va eșua când operatorul înăsprește o politică.