¿Por qué no podemos cambiar de AES a algo asimétrico? Entonces, una clave privada no necesita ser compartida con el cliente; en lugar de compartir una clave pública con ellos.
El concepto
Supondré que te refieres a un cryptosystem híbrido , ya que cifrar todo con algoritmos asimétricos sería lento para dispositivos integrados como baratos) enrutadores. TLS (usado en HTTPS) usa lo mismo: la clave pública se envía al navegador, la usan para intercambiar una clave secreta (generada aleatoriamente para cada conexión), y desde allí usa AES o ChaCha20 para intercambiar datos (cifrados usando la aleatoria clave).
En las redes WPA2-PSK, puede descifrar el tráfico de todos los clientes si conoce la clave precompartida (PSK) y pudo capturar el protocolo de enlace que tuvo lugar al comienzo de la conexión. ¿Por qué no utilizamos el cifrado asimétrico, que permite que solo el destinatario descifre nuestro mensaje? Funcionaría así:
Uno no puede configurar un AP sin conocer el PSK, ya que nunca podrían descifrar la clave aleatoria.
El problema: verificación de clave pública
Hay un problema aquí: ¿cómo sabes que recibiste la clave pública correcta al conectarte? Cualquiera podría enviarle una clave pública, también un atacante, y su cliente estaría cifrando la clave aleatoria con la clave pública del atacante. El atacante puede descifrar su tráfico y retransmitirlo al AP, por lo que no tiene idea de que está siendo interceptado.
Por qué no se puede utilizar un sistema de CA
En HTTPS, esto se resuelve con el sistema de CA, donde hay terceros de confianza que pueden firmar su clave pública. Cualquiera que se conecte al sitio web verificará que esté firmado por un tercero de confianza. Esto funciona porque una CA puede comprobar fácilmente si alguien posee un dominio: "Solo firmaré su certificado para example.com , si coloca el código 1ZTHrM5OM14fe2ce en example.com/verification ". Esto no es posible para una red WiFi ya que requiere proximidad física, y no existe el concepto de tener un nombre de dominio único.
Comprobando la huella digital
SSH resuelve esto mostrando la huella digital al cliente, algo como " 192.168.1.1 tiene la huella digital SHA256:1OBS2zY... , ¿desea continuar?" Si continúa, almacenará la huella digital (FP) y la dirección IP o el dominio al que se estaba conectando, por lo que puede verificar que no haya cambiado desde la última vez.
Esto también es posible con WiFi (después del primer uso, el FP se almacenará con el SSID). El problema es que la FP completa debe comunicarse al cliente y el usuario debe verificar cada byte. ¿Ve a sus abuelos revisando cuidadosamente si Wa3rQOGlqo coincide con el FP publicado por el propietario de la red? Si marca solo unos pocos bytes al principio y / o al final, es trivial generar una clave pública cuyo FP coincida con el principio y / o el final. También hace que sea más difícil reemplazar tu AP, ya que necesitarías transferir la clave privada (o reconfigurar cada dispositivo conectado para confiar en el nuevo FP).
¿Cuál es el punto de esto otra vez?
Pero ¿por qué molestarse? La AP ya demostró que conoce el PSK. ¿Por qué queremos tener una verificación adicional?
Bueno, el objetivo principal de usar criptografía asimétrica en lugar de criptografía simétrica, es evitar que los clientes lean el tráfico de cada uno. Cualquier persona con conocimiento del PSK puede configurar un AP falso e interceptar el tráfico. Por lo tanto, es necesario emplear un esquema que verifique que se usó la clave pública correcta.
Conclusión
Como no hay una forma fácil de hacer esto, supongo. Pero no conozco ninguna literatura en la que esto haya sido discutido y rechazado. O cualquier norma propuesta que nunca llegó a ser de uso generalizado.
Definitivamente se podría hacer como se describe anteriormente si las personas están dispuestas a verificar las huellas digitales, pero podría ser más fácil simplemente conectar una VPN si desea proteger su tráfico.
AES es muy rápido, incluso en software no es malo, pero con la aceleración de hardware es bastante fácil mantenerse al día con altas tasas de datos sin tener bloques de aceleración de hardware enormes y locos.
Puede buscar puntos de referencia de velocidad para varias operaciones de criptografía. Notará que la mayoría de las veces se dan RSA / ECC a tiempo para realizar una única operación de descifrado, o un único intercambio de clave.
Para darle un poco de apoyo en el lodo, podemos ver los núcleos de IP del hardware del mismo proveedor y el uso de la velocidad / los recursos. Usaré IPcores.com ya que tienen ambos tipos de núcleos, es solo una compañía aleatoria que usé como ejemplo. En hardware, usaré su "número de puertas" publicado para darle algo de escala; más puertas significa que se necesita más hardware en el chip = más caro.
Para Un núcleo de ECC de IPCores.com se trata de 10K puertas. Para AES Core de IPCores.com se trata de 3K gates.
El núcleo de AES anuncia 0.8bits / reloj, por lo que, por ejemplo, ejecutarlo a 100MHz le daría un rendimiento de 80Mbits / sec (10MByte / sec). Fácilmente podría ir más rápido que eso o ejecutar un núcleo más grande (pero procesa más a la vez) para lograr casi cualquier velocidad de bits que necesite, ya que el núcleo de 3000 puertas es la opción más lenta.
El núcleo de ECC no publica una tasa de bits, pero dice unos 5000 muls / segundo (el núcleo no es una implementación completa de ECC, por lo que se necesitan otras cosas). Pero debería darte la sensación de que esto no está ni remotamente cerca del rendimiento requerido para realizar el descifrado de datos real a la tasa de datos completa necesaria.
El otro problema asociado con el intercambio de tamaño / velocidad es que un núcleo más grande que se ejecute más rápido va a ser un gran consumo de energía, por lo que también tendrá problemas con el consumo de energía de la batería.
Pero creo que si empiezas a realizar algunos experimentos con velocidades criptográficas asimétricas, te ayudará a entender por qué no utilizamos criptografía asimétrica en todas partes, y solo para intercambiar información crítica antes de cambiar a un cifrado simétrico.
Debido a que los dispositivos inalámbricos tienen menos cantidad de RAM y almacenamiento, sería difícil realizar operaciones de administración de claves que se requieren para que funcione un algoritmo de cifrado asimétrico.