Mit véd valójában a VPN privát kulcsán lévő jelmondat

A VPN-kliens indításakor megjelenő kérés könnyen félreolvasható. Nem a VPN-fiók jelszava, nem az alagút jelszava, és beírása nem bizonyítja, hogy a kapcsolat biztonságos. Egy tárolt privátkulcs-reprezentációt nyit fel, hogy a kliens olvashassa a kulcsanyagot, és használhassa azt hitelesítésre. Minden, ami ezután történik, más kérdés.

A gyakorlatban a válasz a széleken csúszik el: az emberek azt feltételezik, hogy a jelmondat védi a futó alagutat, vagy hogy megváltoztatása visszavonja a már kiszivárgott kulcs egy példányát. Mindkét feltevés megbukik, méghozzá úgy, hogy a hitelesítő adat szabadon marad, miközben az üzemeltető azt hiszi, hogy rendben van.

Egy párbeszéd, több különböző titok

A privátkulcs jelmondata egy fájlt fejt vissza. A fiók jelszava egy szolgáltatásnál hitelesít. A PKCS#12 import jelszava egy kulcsot és annak tanúsítványát tartalmazó csomagot fejt vissza, és nem feltétlenül ugyanaz a karakterlánc, mint a kulcs saját jelmondata. Ezek a kérések szinte azonosnak tűnhetnek, és annak kitalálása, melyik titok hova kerül, az, amitől a kulcsok a rossz mezőbe ragadnak.

Maga az alagút titkosítása a negyedik dolog. Az adatcsatorna a kézfogás során egyeztetett munkamenetkulcsokat használ; a privátkulcs jelmondatának nincs szerepe az egyes csomagok védelmében. Ha valaki olvasni tudja a kulcsfájlt, megpróbálhatja offline kitalálni a jelmondatot, de ha csomagokat tud olvasni, a jelmondat irreleváns.

Mit fed a lemezen lévő titkosítás

A titkosított PEM kulcsnak két formája van, és a fejléc megmondja, melyik van Önnél. A modern PKCS#8 forma -----BEGIN ENCRYPTED PRIVATE KEY------rel kezdődik; a régi PEM forma, amely még gyakori a régebbi OpenVPN-beállításokban, -----BEGIN RSA PRIVATE KEY------rel kezdődik, és közvetlenül alatta Proc-Type: 4,ENCRYPTED és egy DEK-Info sort hordoz. A fájl a privát kulcsot a jelmondatából származtatott kulccsal titkosítva tárolja, általában jelszóalapú KDF-fel, megadott iterációszámmal vagy munkatényezővel. Az OpenSSL pkey dokumentáció ismerteti a formátumokat és a olvasáskor érvényes jelmondat-beállításokat.

Két következmény adódik. A gyenge jelmondat offline támadható olyan sebességgel, amit a KDF lehetővé tesz, ezért a fájlengedélyek és a biztonsági másolatokhoz való hozzáférés titkosított fájl esetén is számítanak. És a támadónak, aki csak a fájlt szerzi meg a jelmondat nélkül, találgatnia kell; aki a fájlt és a jelmondatot is megszerzi, annak megvan a kulcs, pontosan mintha soha nem lett volna titkosítva.

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

head -3 megmutatja a fejlécet, és régi fájlnál a titkosítást bizonyító Proc-Type és DEK-Info sorokat; egyetlen sor önmagában egyik irányban sem bizonyíték. A pkey sor kéri a jelmondatot, és csak a nyilvános felét írja ki, ami bizonyítja, hogy a fájl és a jelmondat működik a privát kulcs felfedése nélkül. Ne használja a -text-et ehhez az ellenőrzéshez: kiírja a privát összetevőket, privateExponent, prime1, prime2 és a többit, és ezt a kimenetet soha nem szabad sehova beilleszteni, sem jegybe, sem csevegésbe, sem naplóba. A PKCS#12 parancs azt is megmondja, van-e a csomagnak külön MAC- vagy titkosítási jelszava, amit érdemes tudni, mielőtt odaadja egy kollégának.

Mit nem véd többé, miután a kulcs betöltődött

A feloldás egyirányú esemény annak a folyamatnak. A kliens elkéri a kulcsot a KDF-től, visszafejti a fájlt, és a privát kulcsot addig tartja a memóriában, ameddig szüksége van rá. Attól a pillanattól a jelmondat semmit nem véd a futó munkamenetből: sem a folyamat memóriáját, sem a kernelmemóriaképet, sem a klienshez kapcsolt hibakeresési munkamenetet, sem a gép azon biztonsági másolatát, amely a kulcs használata közben készült.

Ez ugyanaz a határ, mint egy jelmondattal védett SSH-kulcs vagy egy jelszókezelő feloldott széfje esetében. Növeli a fájl nyugalmi állapotban való ellopásának költségét, és nem tesz semmit az Ön felhasználójaként futó kártevő, a klienstől aláírást kérő engedélyezett alkalmazás vagy a memóriát olvasni tudó rendszergazda ellen. Egy rétegként kezelje, ne olyan kontrollként, amely biztonságossá teszi a kulcsot az ottfelejtéshez.

Miért jön vissza folyton a kérés

Az a kliens, amely minden újracsatlakozáskor újra kérdez, nem feltétlenül hibás. Egyes kliensek a munkamenet idejére gyorsítótárazzák a jelmondatot, mások az operációs rendszer kulcstartójában tárolják, és megint mások olyan segédprogramra irányíthatók, amely szolgáltatja, tehát a viselkedés a klienstől és annak konfigurációjától függ, nem a kulcsfájltól.

Ha az ismétlődő kérés a valódi panasz, vizsgálja meg a kliens gyorsítótárazási és hitelesítési beállításait, mielőtt eltávolítja a titkosítást a kulcsról. A jelmondat eltávolítása védett fájlból egyszerű szöveges kulcsot csinál, és az újracsatlakozás csendessé válik az egyetlen nyugalmi kontroll árán, amely volt. A jobb válasz általában egy támogatott hitelesítőadat-tároló, ugyanazokkal a fájlengedélyekkel, amelyeket amúgy is használna.

Az elvesztés és a nyilvánosságra kerülés nem ugyanaz a javítás

Az elveszett jelmondat nem állítható helyre a tanúsítványból. A tanúsítvány nyilvános anyag, amely nevet köt egy kulcshoz; nincs benne visszaút a privát kulcshoz, és nincs benne utalás a jelmondatra. A gyakorlati lehetőségek a kulcs engedélyezett biztonsági másolata vagy az üzemeltető szokásos folyamatán keresztül kiadott új identitás. Aki a jelmondat 'helyreállítását' kínálja, annak kitalálását kínálja.

A nyilvánosságra kerülés más választ igényel. Ugyanazon kulcs új jelmondattal való újratitkosítása változatlanul hagyja a kulcsanyagot, így a máshol már feloldott példány továbbra is működik. A javítás a hitelesítő adat visszavonása vagy cseréje: adjon ki új kulcsot és tanúsítványt, ossza szét őket, és vonja ki a régit a partneroldalon. Amíg ez nem történik meg, a fájljelszó módosítása házimunka, nem elszigetelés. Csak akkor tartsa a régi fájlt a biztonsági másolatokon kívül, ha az új identitás működése megerősítést nyert, és jegyezze fel, melyik sorozatszám vagy ujjlenyomat váltotta fel.