Mitä VPN:n yksityisavaimen salalause oikeastaan suojaa

Kehote, joka ilmestyy VPN-asiakasohjelman käynnistyessä, on helppo lukea väärin. Se ei ole VPN-tilin salasana, se ei ole tunnelin salasana, eikä sen syöttäminen todista yhteyden olevan turvallinen. Se avaa yhden tallennetun yksityisavaimen esityksen, jotta asiakasohjelma voi lukea avainmateriaalin ja käyttää sitä tunnistautumiseen. Kaikki sen jälkeen tapahtuva on toinen kysymys.

Käytännössä vastaus menee pieleen reunoilla: ihmiset olettavat salalauseen suojaavan käynnissä olevaa tunnelia tai että sen vaihtaminen peruuttaa jo vuotaneen avaimen kopion. Molemmat oletukset pettävät, ja molemmat pettävät niin, että tunnistetieto jää paljaaksi operaattorin uskoessa asian hoidetun.

Yksi valintaikkuna, useita eri salaisuuksia

Yksityisavaimen salalause purkaa tiedoston salauksen. Tilin salasana todentaa sinut palvelulle. PKCS#12-tuonnin salasana purkaa paketin, joka sisältää avaimen ja sen varmenteen, eikä se välttämättä ole sama merkkijono kuin avaimen oma salalause. Nämä kehotteet voivat näyttää lähes identtisiltä, ja arvaaminen, mikä salaisuus menee mihinkin, on syy siihen, miksi avaimet päätyvät liimatuiksi väärään kenttään.

Tunnelin oma salaus on neljäs asia. Datakanava käyttää kättelyn aikana neuvoteltuja istuntoavaimia; yksityisavaimen salalauseella ei ole mitään roolia yksittäisten pakettien suojaamisessa. Jos joku voi lukea avaintiedoston, hän voi yrittää arvata salalauseen offline-tilassa, mutta jos hän voi lukea paketteja, salalause on merkityksetön.

Mitä levyllä oleva salaus kattaa

Salattu PEM-avain on kahdessa muodossa, ja otsake kertoo, kumpi sinulla on. Nykyaikainen PKCS#8-muoto alkaa merkillä -----BEGIN ENCRYPTED PRIVATE KEY-----; vanha PEM-muoto, joka on yhä yleinen vanhemmissa OpenVPN-asennuksissa, alkaa merkillä -----BEGIN RSA PRIVATE KEY----- ja sisältää Proc-Type: 4,ENCRYPTED ja rivin DEK-Info heti sen alla. Tiedosto sisältää yksityisavaimen salattuna avaimella, joka on johdettu salalauseestasi, tyypillisesti salasanaan perustuvalla KDF:llä, jolla on ilmoitettu iteraatiomäärä tai työkerroin. OpenSSL pkey -dokumentaatio kattaa muodot ja salalauseen valinnat, joita lukemisessa sovelletaan.

Seuraa kaksi seurausta. Heikko salalause on hyökättävissä offline-tilassa millä tahansa nopeudella, jonka KDF sallii, joten tiedoston käyttöoikeudet ja pääsy varmuuskopioihin ovat edelleen tärkeitä, vaikka tiedosto olisi salattu. Ja hyökkääjä, joka saa vain tiedoston ilman salalausetta, joutuu arvaamaan; se, joka saa tiedoston ja salalauseen, saa avaimen, aivan kuin sitä ei olisi koskaan salattu.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 näyttää otsakkeen ja vanhassa tiedostossa rivit Proc-Type ja DEK-Info, jotka todistavat salauksen; yksi rivi yksin ei ole todiste kumpaankaan suuntaan. Rivi pkey kysyy salalauseen ja tulostaa vain julkisen puolen, mikä todistaa, että tiedosto ja salalause toimivat paljastamatta yksityisavainta. Älä käytä -text tähän tarkistukseen: se tulostaa yksityiset osat, privateExponent, prime1, prime2 ja loput, eikä sitä tulostetta saa koskaan liittää mihinkään, ei tikettiin, chattiin eikä lokiin. PKCS#12-komento kertoo myös, onko paketissa erillinen MAC- tai salaussalasana, mikä on hyvä tietää ennen kuin annat sen kollegalle.

Mitä se lakkaa suojaamasta, kun avain on ladattu

Avaaminen on kyseiselle prosessille yksisuuntainen tapahtuma. Asiakasohjelma pyytää avaimen KDF:ltä, purkaa tiedoston salauksen ja pitää yksityisavainta muistissa niin kauan kuin tarvitsee. Siitä hetkestä lähtien salalause ei suojaa käynnissä olevasta istunnosta mitään: ei prosessin muistia, ei ytimen vedosta, ei asiakasohjelmaan liitettyä virheenkorjausistuntoa eikä koneen varmuuskopiota, joka on otettu avaimen ollessa käytössä.

Tämä on sama raja kuin salalauseella varustetulla SSH-avaimella tai salasananhallinnan avatulla holvilla. Se nostaa tiedoston lepotilassa varastamisen kustannuksia eikä tee mitään käyttäjänäsi pyörivää haittaohjelmaa, asiakasohjelmaa allekirjoittamaan pyytävää valtuutettua sovellusta tai muistia lukevaa ylläpitäjää vastaan. Käsittele sitä yhtenä kerroksena, ei valvontana, joka tekee avaimen turvalliseksi jättää lojumaan.

Miksi kehote palaa jatkuvasti

Asiakasohjelma, joka kysyy uudelleen joka yhdistämiskerralla, ei välttämättä ole rikki. Jotkut asiakasohjelmat välimuistittavat salalauseen istuntoa varten, jotkut tallentavat sen käyttöjärjestelmän avainnippuun, ja jotkut voidaan ohjata apuriavustajaan, joka toimittaa sen, joten käyttäytyminen riippuu asiakasohjelmasta ja sen kokoonpanosta, ei avaintiedostosta.

Jos toistuva kehote on varsinainen valitus, tutki asiakasohjelman välimuisti- ja todentamisasetukset ennen kuin poistat salauksen avaimesta. Salalauseen poistaminen muuttaa suojatun tiedoston selkokieliseksi avaimeksi, ja uudelleenyhdistäminen hiljenee ainoan lepotilavalvonnan kustannuksella. Parempi vastaus on yleensä tuettu tunnistetietovarasto samoilla tiedoston käyttöoikeuksilla, joita käyttäisit muutenkin.

Menetys ja paljastuminen eivät ole sama korjaus

Kadonnutta salalausetta ei voi palauttaa varmenteesta. Varmenne on julkista materiaalia, joka sitoo nimen avaimeen; se ei sisällä polkua takaisin yksityisavaimeen eikä vihjettä salalauseesta. Käytännön vaihtoehdot ovat avaimen valtuutettu varmuuskopio tai operaattorin tavallisen prosessin kautta myönnetty uusi identiteetti. Jokainen, joka tarjoaa salalauseen 'palauttamista', tarjoaa sen arvaamista.

Paljastuminen vaatii erilaisen vastauksen. Saman avaimen uudelleensalaus uudella salalauseella jättää avainmateriaalin ennalleen, joten kopio, joka on jo avattu muualla, toimii edelleen. Korjaus on tunnistetiedon peruuttaminen tai korvaaminen: myönnä uusi avain ja varmenne, jaa ne ja poista vanha käytöstä vastapuolella. Siihen asti tiedoston salasanan vaihtaminen on taloudenpitoa, ei eristämistä. Pidä vanha tiedosto poissa varmuuskopioista vasta kun uusi identiteetti on todettu toimivaksi, ja kirjaa, mikä sarjanumero tai sormenjälki korvasi sen.