Wat ’n wagfrase op ’n VPN-privaatsleutel werklik beskerm

Die opdrag wat verskyn wanneer ’n VPN-kliënt begin, is maklik om verkeerd te lees. Dit is nie die VPN-rekeningwagwoord nie, dit is nie die wagwoord vir die tonnel nie, en om dit in te voer bewys nie dat die verbinding veilig is nie. Dit ontsluit een gestoorde voorstelling van ’n privaatsleutel sodat die kliënt die sleutelmateriaal kan lees en dit vir verifikasie kan gebruik. Alles wat daarna gebeur, is ’n ander vraag.

Waar die antwoord in die praktyk verkeerd loop, is by die rande: mense aanvaar dat die wagfrase die aktiewe tonnel beskerm, of dat die verandering daarvan ’n kopie van die sleutel wat reeds uitgelek het, herroep. Albei aannames faal, en albei faal op maniere wat ’n geloofsbrief blootstel terwyl die operateur glo dit is hanteer.

Een dialoog, verskeie verskillende geheime

’n Wagfrase vir ’n privaatsleutel ontsluit ’n lêer. ’n Rekeningwagwoord verifieer jou by ’n diens. ’n PKCS#12-invoerwagwoord ontsluit ’n bondel wat ’n sleutel en sy sertifikaat bevat, en dit is dalk nie dieselfde string as die sleutel se eie wagfrase nie. Hierdie opdragte kan byna identies lyk, en om te raai watter geheim waar hoort, is hoe sleutels in die verkeerde veld beland.

Die tonnel se eie enkripsie is ’n vierde ding. Die datakanaal gebruik sessiesleutels wat tydens die handdruk beding word; die privaatsleutel se wagfrase speel geen rol in die beskerming van individuele pakkette nie. As iemand die sleutellêer kan lees, kan hy die wagfrase vanlyn probeer raai, maar as hy pakkette kan lees, is die wagfrase irrelevant.

Wat die enkripsie op skyf dek

’n Geënkripteerde PEM-sleutel kom in twee vorme voor, en die kop wys watter een jy het. Die moderne PKCS#8-vorm begin met -----BEGIN ENCRYPTED PRIVATE KEY-----; die ouer PEM-vorm, wat nog algemeen in ouer OpenVPN-opstellings voorkom, begin met -----BEGIN RSA PRIVATE KEY----- en bevat Proc-Type: 4,ENCRYPTED en ’n DEK-Info-lyn net daaronder. Die lêer hou die privaatsleutel geënkripteer onder ’n sleutel wat van jou wagfrase afgelei is, gewoonlik deur ’n wagwoordgebaseerde KDF met ’n vermelde iterasietelling of werkfaktor. Die OpenSSL pkey-dokumentasie dek die formate en die wagfrase-opsies wat geld wanneer een gelees word.

Twee gevolge volg. ’n Swak wagfrase kan vanlyn aangeval word teen die tempo wat die KDF toelaat, so lêertoestemmings en toegang tot rugsteun bly belangrik selfs wanneer die lêer geënkripteer is. En ’n aanvaller wat net die lêer sonder die wagfrase kry, moet raai; een wat die lêer en die wagfrase kry, het die sleutel, presies asof dit nooit geënkripteer is nie.

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

head -3 wys die kop en, op ’n ouer lêer, die Proc-Type- en DEK-Info-lyne wat enkripsie bewys; een lyn alleen is nie in enige rigting bewys nie. Die pkey-lyn vra vir die wagfrase en druk net die publieke helfte, wat bewys dat die lêer en die wagfrase werk sonder om die privaatsleutel bloot te stel. Moenie -text vir daardie kontrole gebruik nie: dit druk die private komponente, privateExponent, prime1, prime2 en die res, en daardie uitset moet nooit enige plek geplak word nie, nie ’n kaartjie, ’n klets of ’n logboek nie. Die PKCS#12-opdrag sê ook of die bondel ’n aparte MAC- of enkripsiewagwoord het, wat die moeite werd is om te weet voordat jy dit aan ’n kollega gee.

Wat dit ophou beskerm sodra die sleutel gelaai is

Ontsluiting is ’n eenrigting-gebeurtenis vir daardie proses. Die kliënt vra die KDF om die sleutel, ontsyfer die lêer en hou die privaatsleutel in die geheue solank as wat dit nodig het. Van daardie oomblik af beskerm die wagfrase niks omtrent die aktiewe sessie nie: nie die prosesgeheue nie, nie ’n kernuitleg nie, nie ’n ontfoutingsessie wat aan die kliënt gekoppel is nie, en nie ’n rugsteun van die masjien wat geneem is terwyl die sleutel in gebruik was nie.

Dit is dieselfde grens as ’n SSH-sleutel met ’n wagfrase, of ’n wagwoordbestuurder se ontslote kluis. Dit verhoog die koste om die lêer in rus te steel en doen niks teen wanware wat as jou gebruiker loop nie, ’n gemagtigde toepassing wat die kliënt vra om te onderteken, of ’n administrateur wat geheue kan lees. Behandel dit as een laag, nie as die beheer wat ’n sleutel veilig maak om rond te laat lê nie.

Waarom die opdrag bly terugkom

’n Kliënt wat by elke herverbinding weer vra, is nie noodwendig stukkend nie. Sommige kliënte kas die wagfrase vir die sessie, sommige stoor dit in die bedryfstelsel se sleutelring, en sommige kan na ’n helper verwys word wat dit verskaf, so watter gedrag jy kry, hang af van die kliënt en sy konfigurasie, nie van die sleutellêer nie.

As die herhaalde opdrag die werklike klag is, ondersoek die kliënt se kas- en verifikasie-opsies voordat jy enkripsie van die sleutel verwyder. Om die wagfrase te stroop, verander ’n beskermde lêer in ’n gewone tekssleutel, en die herverbinding word stil ten koste van die enigste beheer in rus wat jy gehad het. ’n Beter antwoord is gewoonlik ’n ondersteunde geloofsbriefstoor met dieselfde lêertoestemmings wat jy in elk geval sou gebruik.

Verlies en blootstelling is nie dieselfde herstel nie

’n Verlore wagfrase kan nie uit die sertifikaat herstel word nie. Die sertifikaat is publieke materiaal wat ’n naam aan ’n sleutel bind; dit bevat geen pad terug na die privaatsleutel nie en geen wenk oor die wagfrase nie. Die praktiese opsies is ’n gemagtigde rugsteun van die sleutel, of ’n nuwe identiteit wat deur die operateur se normale proses uitgereik word. Enigiemand wat aanbied om die wagfrase te 'herstel', bied aan om dit te raai.

Blootstelling vra ’n ander reaksie. Om dieselfde sleutel met ’n nuwe wagfrase te herënkripteer, laat die sleutelmateriaal onveranderd, so ’n kopie wat elders reeds ontsluit is, werk steeds. Die herstel is om die geloofsbrief te herroep of te vervang: reik ’n nuwe sleutel en sertifikaat uit, versprei dit, en trek die ou een by die eweknie terug. Tot dit gebeur, is die verandering van die lêerwagwoord huishouding, nie inperking nie. Hou die ou lêer uit rugsteun net nadat die nuwe identiteit bevestig is dat dit werk, en teken aan watter reeksnommer of vingerafdruk dit vervang het.