Android IKEv2: käyttäjän varmenne ja CA tekevät eri tehtäviä
Toinen kenttä todistaa, mikä puhelin on, toinen päättää, mihin yhdyskäytävään voi luottaa. Androidin IKEv2-profiili pitää ne erillään.
Androidin IKEv2-näyttö, joka pyytää samalla kertaa sekä käyttäjän varmennetta että CA-varmennetta, näyttää pyytävän samaa asiaa kahdesti. Näin ei ole. IKEv2 todentaa molemmat osapuolet molempiin suuntiin yhdessä vaihdossa, ja puhelimella on eri rooli kummassakin suunnassa: sen on todistettava kuka se on ja päätettävä, mihin yhdyskäytävään se uskoo. Käyttäjän varmenne vastaa ensimmäiseen kysymykseen, luotettu CA toiseen, eikä kumpikaan korvaa toista.
Kaksi todentamisen suuntaa yhdessä vaihdossa
IKEv2 rakentaa ohjauskanavan kahdessa vaiheessa. Ensimmäinen neuvottelee algoritmit ja avaimet; toinen, IKE_AUTH, kuljettaa kummaltakin puolelta yhden AUTH-hyötykuorman ja sen identiteetin. Hyötykuorma on vaihdon yli laskettu allekirjoitus tai MAC, ja se varmennetaan jotain vastaan, johon vastaanottaja luottaa jo ennestään.
Yhdyskäytävä todistaa itsensä omalla varmenteellaan; puhelin varmistaa ketjun juureen, johon se luottaa, ja sen, että varmenteen identiteetti vastaa sitä yhdyskäytävää, johon se halusi päästä. uhelin todistaa itsensä tunnuksillaan, ja yhdyskäytävä varmistaa ne sitä CA:ta vastaan, joka myönsi asiakkaan varmenteen.
Siinä on koko mekanismi kahden kentän takana. Käyttäjän varmenne on puhelimen väite itsestään; CA-kenttä on väite siitä, ketä puhelin uskoo. Profiili, jossa on toinen mutta ei toista, ei saa vastavuoroista todentamista valmiiksi, eikä uudelleen yrittäminen muuta sitä. Jopa virheet näyttävät erilaisilta: ilman käyttäjän avainta puhelin ei voi allekirjoittaa lainkaan, ilman luottamuksen ankkuria se ei voi hyväksyä yhdyskäytävän varmennetta.
| 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 |
Mitä Androidin profiilinrakentaja vaatii
Androidin IKEv2-profiilinrakentaja tarjoaa jokaisen todentamismenetelmän erikseen, ei yhtenä varmennetilana. Digitaalisen allekirjoituksen menetelmä ottaa käyttäjän varmenteen, yksityisen avaimen ja palvelimen juuri-CA:n; muut ottavat käyttäjätunnuksen ja salasanan tai ennalta jaetun avaimen.
Lue tuo allekirjoitus tarkkaan, sillä se kuvaa yllä olevan mekanismin. Käyttäjätunnus- ja salasanamenetelmässä ei ole yksityisen avaimen kenttää eikä PSK-menetelmässä yhdyskäytävän luottamuksen ankkurin kenttää, koska ne menetelmät todistavat eri asioita. Varmennekenttään liitetty salasana antaa profiilin, joka epäonnistuu IKE_AUTHissa viestillä, joka ei nimeä kumpaakaan.
Digitaalisen allekirjoituksen menetelmän dokumentoitu yksityisen avaimen tyyppi on RSA. IPsec- tai varmenne-niminen valikko ei tarkoita ECDSA-tukea, ja siihen oletukseen rakennettu profiili epäonnistuu alustan APIssa ennen kuin verkko on edes mukana.
Miksi pelkkä julkinen käyttäjän varmenne ei riitä
AUTH-hyötykuorma on allekirjoitus vaihdon yli asiakkaan yksityisellä avaimella. Julkinen varmenne antaa yhdyskäytävän tarkistaa allekirjoituksen, mutta ei tee puhelimelle mitään, sillä puhelin tarvitsee avaimen sen tuottamiseen. Vain .crt tiedoston tuonti ja avaimen jättäminen taakse on tämän virheen yleisin muoto.
Androidin avaininfrastruktuuri heijastaa tätä. Asiakasidentiteetin valinta kulkee KeyChainin kautta, joka vaatii pääsyn vastaavaan yksityiseen avaimeen, ei vain varmennemerkintää. Rekisteröintipaketti tai laitehallinnan työnkulku, joka asentaa parin yhdessä, on tavallinen tie käyttökelpoiseen identiteettiin; tiedoston kopioiminen käsin ei yleensä ole.
Profiilin kaksi osaa eivät siis ole varmennepaketti ja sen kopio. Toinen on avainpari, jolla alustan on voitava allekirjoittaa, toinen on luottamuksen ankkuri, johon se vertaa. Tarkista ne kahtena erillisenä tosiasiana: voiko tämä profiili allekirjoittaa ja tietääkö se, ketä uskoa?
Luottamuksen ankkurit kuuluvat sovellukselle, ei puhelimelle
Käyttäjän varastoon asennettu juuri ei saa jokaista Android-sovellusta luottamaan siihen: Android 7:stä lähtien sovelluksen on valittava se verkkoturvallisuusasetuksillaan, ja ennen sitä julkaisua käyttäjän asentamat CA:t hyväksyttiin paljon laajemmin. Luottamusasetukset voivat vaihdella sovelluksittain, eikä VPN-asiakas, joka hallitsee omia luottamustietojaan, ehkä koskaan katso käyttäjän varastoa. Siksi sama CA-tiedosto voi toimia yhdessä asiakkaassa ja näyttää ohitetulta toisessa.
Tästä seuraa kaksi omistusmallia. Järjestelmän hallitsema profiili käyttää laitteen varmenneasennusta tai järjestelmänvalvojan rekisteröintiä ja viittaa sitten aiottuun CA:han. Sovelluksen hallitsema VPN pitää omat luottamustietonsa ja oman dokumentoidun tuontinsa, joka voi olla täysin erillään Androidin asetusnäytöstä. Siellä myös korjataan katkennut ketju.
Päätä, missä mallissa olet, ennen kuin tuot mitään, ja vahvista sen jälkeen aktiivisen profiilin luottamusvalinta. Jos operaattorin ohjeet ja asiakkaan valikko ovat ristiriidassa, kyseisessä asennuksessa voittaa asiakkaan dokumentoitu käyttäytyminen, mutta CA:n on silti tultava operaattorilta kanavaa pitkin, jonka voit varmistaa. Tiedoston nimi ei ole todiste siitä, kuka sen myönsi.
Valitse ensin tila, sitten tiedostot
Varmennetila tarvitsee asiakkaan avainparin, myöntävän CA:n yhdyskäytävän puolella, luottamuksen ankkurin yhdyskäytävän varmenteelle ja odotuksen siitä, mikä identiteetti varmenteessa on oltava. Käyttäjätunnus ja salasana korvaavat avainparin tunnuksilla mutta säilyttävät vaatimuksen luottaa yhdyskäytävään. PSK korvaa molemmat jaetulla salaisuudella ja muuttaa luottamusmallia sen sijaan, että yksinkertaistaisi sitä.
Mitä tahansa valitsetkin, pidä tavallinen vahvistus päällä. Ei vahvisteta -vaihtoehto poistaa sen tarkistuksen, jota varten CA-kenttä on olemassa; se ei korjaa puuttuvaa luottamuksen ankkuria. Sama koskee minkä tahansa palvelinvarmensteen hyväksymistä siksi, että yhteys toimii ilman sitä.
Tarkista sitten oikeassa paikassa: tuo tiedot, yhdistä kerran ja vahvista yhteyden tiedoissa, että yhdyskäytävän identiteetti on odotettu ja että profiili ilmoittaa menetelmän, jota tarkoitit. Onnistunut yhteys väärällä menetelmällä on asetelma, jota et vielä ymmärrä, ja se epäonnistuu, kun operaattori kiristää käytäntöä.