Android IKEv2: it brûkerssertifikaat en de CA dogge ferskillend wurk
It iene fjild bewist wa't de telefoan is, it oare beslút oan hokker gateway te fertrouwen. It IKEv2-profyl yn Android hâldt se skieden.
In IKEv2-skerm yn Android dat tagelyk om in brûkerssertifikaat en in CA-sertifikaat freget, liket itselde twa kear te wollen. Dat is net sa. IKEv2 ferifiearret beide partijen yn beide rjochtingen yn ien útwikseling, en de telefoan spilet yn elke rjochting in oare rol: hy moat bewize wa't er is en beslute hokker gateway er leaut. It brûkerssertifikaat beantwurdet de earste fraach, de fertroude CA de twadde, en gjin fan beide ferfangt de oare.
Twa rjochtingen fan ferifikaasje yn ien útwikseling
IKEv2 bout in kontrôlekanaal yn twa fazen. De earste ûnderhannelet algoritmen en kaai; de twadde, IKE_AUTH, draacht ien AUTH-lading fan elk part mei syn identiteit. De lading is in hantekening of in MAC oer de útwikseling en wurdt ferifiearre tsjin wat de ûntfanger al fertrout.
De gateway bewist himsels mei syn eigen sertifikaat, en de telefoan ferifiearret de keatling oant in woartel dy't er akseptearret en kontrolearret dat de identiteit by de gateway past dy't er berikke woe; de telefoan bewist himsels mei syn eigen bewiis, dat de gateway tsjin de CA ferifiearret dy't it kliïntsertifikaat útjûn hat.
Dat is it hiele meganisme efter de beide fjilden. It brûkerssertifikaat is in ferklearring fan de telefoan oer himsels; it CA-fjild is in ferklearring oer wa't er leauwe sil. In profyl mei ien mar net de oare kin gjin wjersidige ferifikaasje ôfmeitsje, en opnij besykje feroaret dat net. Sels de flaters sjogge oars út: sûnder brûkerskaai kin de telefoan hielendal net hantekeningje, sûnder fertrouwensanker kin er it sertifikaat fan de gateway net akseptearje.
| 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-profylbouwer freget
De IKEv2-profylbouwer fan Android biedt elke ferifikaasjemetoade apart oan, net as ien sertifikaatmodus. De metoade mei digitaale hantekening nimt in brûkerssertifikaat, in privee kaai en in woartel-CA fan de tsjinner; de oaren nimme in brûkersnamme en wachtwurd, of in foarôf dielde kaai.
Lês dy hantekening goed, want dy beskriuwt it meganisme hjirboppe. Yn de metoade brûkersnamme en wachtwurd is gjin fjild foar de privee kaai, en yn PSK gjin fjild foar it fertrouwensanker fan de gateway, om't dy metoaden oare dingen bewize. In wachtwurd yn in sertifikaatfjild jout in profyl dat by IKE_AUTH mist, mei in berjocht dat gjin fan beide neamt.
It dokumintearre type privee kaai foar de metoade mei digitaale hantekening is RSA. In menu mei it label IPsec of sertifikaat betsjut gjin stipe foar ECDSA, en in profyl boud op dy oanname mist by de API fan it platfoarm noch foar't it netwurk belutsen is.
Wêrom in iepenbier brûkerssertifikaat allinnich net genôch is
De AUTH-lading is in hantekening oer de útwikseling, makke mei de privee kaai fan de kliïnt. It iepenbiere sertifikaat lit de gateway in hantekening kontrolearje, mar docht neat foar de telefoan, dy't de kaai nedich hat om ien te meitsjen. Allinnich .crt ymportearje en de kaai efterlitte is de meast foarkommende foarm fan dizze flater.
De kaai-ynfrastruktuer fan Android wjerspegelet dat: in kliïntidentiteit kieze giet fia KeyChain, dat tagong freget ta de byhearrende privee kaai, net allinnich in sertifikaatynskriuwing. In ynskriuwingspakket of in apparaatbehear dat it pear tegearre ynstallearret is de gewoane wei nei in brûkber identiteit; in triem mei de hân kopiearje meast net.
De beide ûnderdielen binne dus gjin sertifikaatbondel en in kopy dêrfan. Ien is in kaaipear dêr't it platfoarm mei hantekeningje moat, it oare is in fertrouwensanker dêr't it mei ferget. Kontrolearje se as twa aparte feiten: kin dit profyl hantekeningje, en wit it wa't te fertrouwen?
Fertrouwensankers hearre by in applikaasje, net by de telefoan
In woartel yn it brûkersopslach plakke makket net dat elke Android-applikaasje dy fertrout: fan Android 7 ôf moat in app dat kieze fia syn netwurkfeiligenskonfiguraasje, en foar dy ferzje waarden troch de brûker ynstallearre CA's folle breder akseptearre. De fertrouwenskonfiguraasje kin ferskille, en in VPN-kliïnt dy't syn eigen fertrouwensmateriaal beheart sjocht miskien nea yn it brûkersopslach. Dêrom kin deselde CA-triem yn ien kliïnt wurkje en yn in oare negearre lykje.
Dêrút folgje twa eigendomsmodellen. In systeembeheard profyl brûkt de sertifikaatynstallaasje fan it apparaat of in administraasje-ynskriuwing en ferwiist dan nei de bedoelde CA. In app-beheard VPN hâldt syn eigen fertrouwensmateriaal en syn eigen dokumintearre ymport, dy't folslein los fan it Android-ynstellingsskerm wêze kin. Dêr wurdt ek in brutsen keatling reparearre.
Beslút yn hokker model jo sitte foar't jo wat ymportearje, en befêstigje dêrnei de fertrouwenskar fan it aktive profyl. As de ynstruksjes fan de operator en it menu fan de kliïnt net oerienkomme, wint foar dy ynstallaasje it dokumintearre gedrach fan de kliïnt, mar de CA moat noch altyd fan de operator komme fia in kanaal dat jo ferifiearje kinne. In triemnamm is gjin bewiis fan wa't it útjûn hat.
Kies earst de modus, dan de triemen
De sertifikaatmodus freget in kaaipear fan de kliïnt, de útjaande CA oan de kant fan de gateway, in fertrouwensanker foar it sertifikaat fan de gateway en in ferwachting fan hokker identiteit dat sertifikaat drage moat. Brûkersnamme en wachtwurd ferfange it kaaipear troch bewiis mar hâlde de eask fan fertrouwen yn de gateway. PSK ferfangt beide troch in dield geheim en feroaret it fertrouwensmodel yn stee fan it te ferienfâldigjen.
Hokker jo ek kieze, lit de normale falidaasje oan. In opsje sûnder ferifikaasje hellet de kontrôle wei dêr't it CA-fjild foar bestiet; it reparearret gjin ûntbrekkend fertrouwensanker. Itselsde jildt foar it akseptearjen fan hokker tsjinnersertifikaat dan ek om't de ferbining derûnder wurket.
Ferifiearje dan op it goede plak: ymportearje it materiaal, ferbyn ien kear, en befêstigje yn de details fan de ferbining dat de identiteit fan de gateway de ferwachte is en dat it profyl de metoade meldt dy't jo bedoelden. In slagge ferbining mei de ferkearde metoade is in konfiguraasje dy't jo noch net begripe, en dy sil mislearje as de operator in belied ferskerpet.