Xifratge simètric vs. de clau pública en una VPN: què fa cadascun

La gent descriu una VPN com „que fa servir xifratge de clau pública“ i després s'imagina cada paquet tancat amb el certificat del servidor. Aquesta imatge és errònia d'una manera que importa quan llegiu un fitxer de configuració o una captura de paquets. La meitat de clau pública d'una VPN tracta de demostrar qui és el parell i d'acordar material secret; la meitat simètrica és la que protegeix realment el trànsit, paquet rere paquet, durant tota la vida de la sessió.

Les dues meitats tenen durades diferents, maneres de fallar diferents i coses diferents que podeu publicar amb seguretat. Un cop les separeu, preguntes com „és RSA 2048 més feble que AES-128“ deixen de confondre, perquè mai no van ser comparables.

Tres operacions que es confonen

La criptografia de clau pública és un paraigua sobre almenys tres operacions diferents. Una signatura demostra que el titular d'una clau privada ha aprovat un missatge concret. L'acord de claus permet a dos parells derivar un secret compartit a partir de valors que intercanvien en públic. El xifratge de clau pública amaga les dades sota la clau pública d'algú de manera que només la clau privada les pot obrir.

Les apretades de mans de VPN fan servir sobretot les dues primeres. Un certificat no és una clau de xifratge; és una declaració signada que lliga un nom a una clau pública, cosa que permet a l'altra banda decidir si es refia de la clau que acaba de rebre. L'establiment de claus de TLS 1.3, per exemple, es basa en l'acord de claus (EC)DHE més signatures de certificat, no en xifrar la sessió amb la clau pública del servidor.

Què produeix realment l'apretada de mans

En una apretada de mans moderna, cada banda genera un parell de claus efímer, intercanvia les meitats públiques i calcula un secret compartit que mai no travessa el cable. Aquest secret passa llavors per una funció de derivació de claus per produir claus separades per a cada direcció, més els nonces i el material IV que necessita la capa de registre. WireGuard ho fa amb la seva construcció basada en Noise; TLS 1.3 ho fa amb HKDF sobre el transcripte de l'apretada de mans.

La credencial de llarg termini — certificat i clau privada, o una clau WireGuard estàtica — autentica aquest intercanvi. Signa o es barreja al transcripte perquè un desconegut no pugui completar l'apretada de mans en lloc del parell. Després d'això, la credencial no fa feina per paquet. Si ho fes, cada paquet necessitaria una operació de clau privada, i un túnel ocupat quedaria limitat per l'operació més lenta de la pila.

Se'n deriven dos efectes secundaris. Primer, les claus de sessió són noves cada vegada, i per això un atacant que més tard roba la clau de llarg termini no pot desxifrar sessions enregistrades abans, sempre que l'acord fos efímer. Segon, una clau de sessió filtrada compromet una sessió, no la identitat.

Per què les dades massives fan servir claus simètriques

Els xifratges simètrics suporten bé el volum: AES-GCM o ChaCha20-Poly1305 processen cada paquet amb una clau que ja és a la memòria, autentiquen la capçalera i incrementen un comptador. La banda receptora comprova el nonce i l'etiqueta d'autenticació, i descarta tot el que falla o es repeteix. Això és prou barat per funcionar a velocitat de línia en maquinari corrent, i la mateixa construcció dóna confidencialitat i integritat en una sola passada.

La construcció és també on viuen la majoria d'errors d'implementació. Un nonce repetit a GCM trenca la confidencialitat i l'autenticitat alhora, per això els protocols deriven claus per direcció i mantenen un comptador o una època explícits. Si llegiu una captura de paquets i la longitud del text xifrat coincideix amb el text pla més una sobrecàrrega fixa, és la capa simètrica que treballa, no una operació de clau pública per paquet.

Durades, renovació de claus i secreta futura

Les claus de sessió han de caducar. TLS 1.3 permet un missatge KeyUpdate per fer girar les claus de trànsit; WireGuard renova una sessió després d'un temps o un nombre de missatges configurats i manté breument l'antiga per als paquets en vol. OpenVPN renegocia les seves claus de canal de dades segons una planificació, amb reneg-sec controlant l'interval.

Cap d'aquestes rotacions no és el mateix que renovar un certificat. Un certificat pot ser vàlid un any mentre les claus de sessió canvien cada pocs minuts, i un certificat es pot substituir sense tocar les claus del túnel en funcionament. Quan planifiqueu una caducitat, pregunteu quin objecte esteu rotant; la resposta decideix si els clients es reconnecten o simplement renoven claus.

Llegir configuracions i diagnòstics sense barrejar objectes

A la pràctica, trieu un protocol complet i les seves primitives suportades, no munteu el vostre. La clau --tls-crypt d'OpenVPN protegeix el canal de control; el canal de dades fa servir xifratges simètrics negociats. Les entrades PrivateKey i PublicKey de WireGuard són material d'identitat, mentre que les seves claus de transport es deriven internament. Llegir aquests camps com el mateix tipus de secret porta a errors com enganxar una clau pública on pertoca una de privada.

Manteniu el material públic separable del privat. Un certificat, una clau pública de WireGuard i una empremta són segurs de compartir en un tiquet. Una clau privada, una clau prèviament compartida i una clau de sessió exportada no ho són. Quan compareu fortaleses, compareu dins d'un tipus: un identificador de corba el·líptica, una mida de mòdul RSA i una mida de clau AES mesuren coses diferents sota supòsits diferents. L'especificació de TLS 1.3 és una referència útil per a com encaixen les dues capes, fins i tot quan el vostre túnel no és TLS.