Cifrado simétrico vs. de clave pública nunha VPN: que fai cada un

A xente describe unha VPN como „a que usa cifrado de clave pública“ e despois imaxina cada paquete pechado co certificado do servidor. Esa imaxe é errónea dunha forma que importa cando se le un ficheiro de configuración ou unha captura de paquetes. A metade de clave pública dunha VPN consiste en demostrar quen é o par e acordar material secreto; a metade simétrica é a que protexe realmente o tráfico, paquete tras paquete, durante toda a vida da sesión.

As dúas metades teñen duracións distintas, modos de fallo distintos e cousas distintas que se poden publicar con seguridade. Unha vez separadas, preguntas como “RSA 2048 é máis feble que AES-128“ deixan de confundir, porque nunca foron comparables.

Tres operacións que se confunden

A criptografía de clave pública é un paraugas sobre polo menos tres operacións distintas. Unha sinatura demostra que o titular dunha clave privada aprobou unha mensaxe concreta. O acordo de claves permite a dous pares derivar un segredo compartido a partir de valores que intercambian en público. O cifrado de clave pública agocha datos baixo a clave pública de alguén de xeito que só a clave privada poida abrilo.

Os apertos de mans de VPN usan sobre todo as dúas primeiras. Un certificado non é unha clave de cifrado; é unha declaración asinada que liga un nome a unha clave pública e permite á outra banda decidir se confía na clave que acaba de recibir. O establecemento de claves de TLS 1.3, por exemplo, baséase no acordo de claves (EC)DHE máis sinaturas de certificado, non en cifrar a sesión coa clave pública do servidor.

Que produce realmente o aperto de mans

Nun aperto de mans moderno, cada banda xera un par de claves efémero, intercambia as metades públicas e calcula un segredo compartido que nunca cruza o cable. Ese segredo pasa despois por unha función de derivación de claves para producir claves separadas para cada dirección, ademais dos nonces e o material IV que necesita a capa de rexistro. WireGuard faino coa súa construción baseada en Noise; TLS 1.3 faino con HKDF sobre o transcrito do aperto de mans.

A credencial de longa duración — certificado e clave privada, ou unha clave WireGuard estática — autentica ese intercambio. Asina ou mestúrase no transcrito para que un descoñecido non poida completar o aperto de mans no lugar do par. Despois diso, a credencial non fai traballo por paquete. Se o fixese, cada paquete necesitaría unha operación de clave privada, e un túnel ocupado quedaría limitado pola operación máis lenta da pila.

Séguense dous efectos secundarios. Primeiro, as claves de sesión son novas cada vez, polo que un atacante que máis tarde roube a clave de longa duración non pode descifrar sesións gravadas antes, sempre que o acordo fose efémero. Segundo, unha clave de sesión filtrada compromete unha sesión, non a identidade.

Por que os datos masivos usan claves simétricas

Os cifrados simétricos manexan ben o volume: AES-GCM ou ChaCha20-Poly1305 procesan cada paquete cunha clave que xa está en memoria, autentican a cabeceira e incrementan un contador. A banda receptora comproba o nonce e a etiqueta de autenticación, e descarta todo o que falla ou se repite. Iso é o bastante barato para funcionar a velocidade de liña en hardware corrente, e a mesma construción dá confidencialidade e integridade nunha soa pasada.

A construción tamén é onde viven a maioría dos erros de implementación. Un nonce repetido en GCM rompe a confidencialidade e a autenticidade á vez, por iso os protocolos derivan claves por dirección e manteñen un contador ou unha época explícitos. Se se le unha captura de paquetes e a lonxitude do texto cifrado coincide co texto plano máis unha sobrecarga fixa, é a capa simétrica a que traballa, non unha operación de clave pública por paquete.

Duracións, renovación de claves e segredo cara adiante

As claves de sesión están feitas para caducar. TLS 1.3 permite unha mensaxe KeyUpdate para rotar as claves de tráfico; WireGuard renova unha sesión tras un tempo ou un número de mensaxes configurados e mantén brevemente a antiga para os paquetes en voo. OpenVPN renegocia as claves da súa canle de datos segundo un calendario, con reneg-sec controlando o intervalo.

Ningunha desas rotacións é o mesmo que renovar un certificado. Un certificado pode ser válido un ano mentres as claves de sesión cambian cada poucos minutos, e un certificado pódese substituír sen tocar as claves do túnel en funcionamento. Cando planifique unha caducidade, pregunte que obxecto está rotando; a resposta decide se os clientes se reconectan ou simplemente renovan claves.

Ler configuracións e diagnósticos sen mesturar obxectos

Na práctica elíxese un protocolo completo e as súas primitivas compatibles, non se monta un propio. A clave --tls-crypt de OpenVPN protexe a canle de control; a canle de datos usa cifrados simétricos negociados. As entradas PrivateKey e PublicKey de WireGuard son material de identidade, mentres que as súas claves de transporte se derivan internamente. Ler eses campos como o mesmo tipo de segredo leva a erros como pegar unha clave pública onde corresponde unha privada.

Manteña o material público separado do privado. Un certificado, unha clave pública de WireGuard e unha pegada son seguros de compartir nun tícket. Unha clave privada, unha clave precompartida e unha clave de sesión exportada non o son. Cando compare forzas, compare dentro dun tipo: un identificador de curva elíptica, un tamaño de módulo RSA e un tamaño de clave AES meden cousas distintas baixo supostos distintos. A especificación de TLS 1.3 é unha referencia útil sobre como encaixan as dúas capas, mesmo cando o túnel non é TLS.