Android IKEv2: die gebruiker-sertifikaat en die CA doen verskillende take
Een veld bewys wie die foon is, die ander besluit watter poort vertrou kan word. Android se IKEv2-profiel hou hulle apart omdat die handskud dit vereis.
’n Android IKEv2-skerm wat terselfdertyd om ’n gebruiker-sertifikaat en ’n CA-sertifikaat vra, lyk of dit dieselfde ding twee keer wil h@e. Dit is nie. IKEv2 verifieer albei partye in albei rigtings binne een uitruiling, en die foon speel in elke rigting ’n ander rol: dit moet bewys wie dit is en besluit watter poort dit glo. Die gebruiker-sertifikaat beantwoord die eerste vraag, die vertroude CA die tweede, en nie een kan die ander vervang nie.
Twee rigtings van verifikasie in een uitruiling
IKEv2 bou ’n beheerkanaal in twee fases op. Die eerste onderhandel algoritmes en sleutels; die tweede, IKE_AUTH, dra een AUTH-lading van elke kant saam met daardie kant se identiteit. Die lading is ’n handtekening of ’n MAC oor die uitruiling, en dit word geverifieer teen iets wat die ontvanger reeds vertrou.
Die poort bewys homself met sy eie sertifikaat; die foon valideer die ketting tot by ’n wortel wat dit vertrou en kontroleer dat die identiteit by die poort pas wat dit wou bereik. Die foon bewys homself met sy eie geloofsbrief, wat die poort teen die CA verifieer wat die kliënt-sertifikaat uitgereik het.
Dit is die hele meganisme agter die twee velde. Die gebruiker-sertifikaat is ’n verklaring oor die foon self; die CA-veld is ’n verklaring oor wie die foon sal glo. ’n Profiel met een maar nie die ander kan nie wedersydse verifikasie voltooi nie, en herprobeer verander dit nie. Die foute lyk selfs anders: sonder ’n gebruiker-sleutel kan die foon glad nie onderteken nie; sonder ’n vertrouensanker kan dit nie die poort se sertifikaat aanvaar nie.
| 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 die Android-profielbouer vra
Android se IKEv2-profielbouer bied elke verifikasiemetode afsonderlik aan, nie as een sertifikaat-modus nie. Die digitale-handtekening-metode neem ’n gebruiker-sertifikaat, ’n private sleutel en ’n bediener-wortel-CA; die ander neem ’n gebruikersnaam en wagwoord, of ’n vooraf-gedeelde sleutel.
Lees daardie handtekening mooi, want dit verwoord die meganisme hierbo. Daar is geen veld vir die gebruiker se private sleutel in die gebruikersnaam/wagwoord-metode nie, en geen veld vir die poort se vertrouensanker in die PSK-metode nie, omdat daardie metodes verskillende dinge bewys. Om ’n wagwoord in ’n sertifikaatveld te plak, lewer ’n profiel wat by IKE_AUTH misluk met ’n boodskap wat nie een van die twee noem nie.
Die gedokumenteerde private-sleutel-tipe vir die digitale-handtekening-metode is RSA. ’n Kieslys met die naam IPsec of sertifikaat impliseer nie ECDSA-ondersteuning nie, en ’n profiel wat op daardie aanname gebou is, misluk by die platform-API nog voor die netwerk betrokke is.
Waarom ’n publieke gebruiker-sertifikaat alleen nie genoeg is nie
Die AUTH-lading is ’n handtekening oor die uitruiling met die kliënt se private sleutel. Die publieke sertifikaat laat die poort ’n handtekening kontroleer; dit doen niks vir die foon nie, want die foon het die sleutel nodig om een te produseer. Om net die .crt in te voer en die sleutel agter te laat is die mees algemene weergawe van hierdie fout.
Android se sleutelinfrastruktuur weerspieël dit. Om ’n kliënt-identiteit te kies gaan deur KeyChain, wat toegang tot die ooreenstemmende private sleutel vereis, nie net ’n sertifikaat-inskrywing nie. ’n Inskrywingspakket of toestelbestuur-werkvloei wat die paar saam installeer, is die normale manier om ’n bruikbare identiteit te kry; om ’n sertifikaatlêer met die hand te kopieer gewoonlik nie.
Die twee items in die profiel is dus nie ’n sertifikaatbondel en ’n duplikaat daarvan nie. Een is ’n sleutelpaar waarmee die platform moet kan onderteken, die ander is ’n vertrouensanker waarmee dit vergelyk. Kontroleer hulle as twee aparte feite: kan hierdie profiel onderteken, en weet dit wie om te vertrou?
Vertrouensankers hoort by ’n toepassing, nie by die foon nie
Om ’n wortel in die gebruikerstoordepot te installeer, maak nie elke Android-toepassing vertrou nie: sedert Android 7 moet ’n toepassing daarvoor intree deur sy netwerksekuriteit-konfigurasie, en voor daardie weergawe is gebruiker-geïnstalleerde CA’s baie wyer aanvaar. Vertrouenskonfigurasie kan per toepassing verskil, en ’n VPN-kliënt wat sy eie vertrouensmateriaal bestuur, kyk dalk nooit na die gebruikerstoordepot nie. Daarom kan dieselfde CA-lêer in een kliënt werk en in ’n ander geïgnoreer lyk.
Twee eienaarskapsmodelle volg. ’n Stelselbestuurde profiel gebruik die toestel se sertifikaatinstallasie of administrateur-inskrywing, en die profiel verwys dan na die bedoelde CA. ’n Toepassingsbestuurde VPN hou sy eie vertrouensmateriaal en sy eie gedokumenteerde invoer, wat heeltemal apart van die Android-instellingskerm kan wees. Dis ook waar jy ’n gebroke ketting herstel: in die CA-stoordepot en profielkeuse vir die stelselbestuurde geval, in die kliënt se eie invoerskerm vir die toepassingsbestuurde een.
Besluit in watter model jy is voordat jy iets invoer, en bevestig daarna die aktiewe profiel se vertrouenskeuse. As die operateur se instruksies en die kliënt se kieslys verskil, wen die kliënt se gedokumenteerde gedrag vir daardie installasie, maar die CA moet steeds van die operateur kom deur ’n kanaal wat jy kan verifieer. ’n Lêernaam is nie bewys van wie dit uitgereik het nie.
Kies die modus, dan die lêers
Sertifikaat-modus benodig ’n kliënt-sleutelpaar, die uitreikende CA aan die poort se kant, ’n vertrouensanker vir die poort se sertifikaat, en ’n verwagting van watter identiteit daardie sertifikaat moet dra. Gebruikersnaam/wagwoord vervang die sleutelpaar met geloofsbriewe maar hou die poort-vertrouensvereiste. PSK vervang albei met ’n gedeelde geheim en verander die vertrouensmodel eerder as om dit te vereenvoudig.
Watter een jy ook kies, hou normale validering aan. ’n Opsie om nie te verifieer nie verwyder die kontrole waarvoor die CA-veld bestaan; dit herstel nie ’n ontbrekende vertrouensanker nie. Dieselfde geld om enige bediener-sertifikaat te aanvaar omdat die verbinding daarsonder werk.
Verifieer dan op die regte plek: voer die materiaal in, verbind een keer, en bevestig in die kliënt se verbindingsbesonderhede dat die poort se identiteit die een is wat jy verwag het en dat die profiel die metode rapporteer wat jy bedoel het. ’n Suksesvolle verbinding met die verkeerde metode is ’n konfigurasie wat jy nog nie verstaan nie, en dit sal faal wanneer die operateur ’n beleid verskerp.