¿Qué riesgos son inherentes a la conexión a un servidor de clave pública no confiable?

Tu preocupación es muy válida.

En 2000, Ralf Senderek descubrió un error en las versiones comerciales de NAI 5.5.x hasta 6.5.3 de PGP: clave -Experimentos . Fue especialmente embarazoso porque implicaba la implementación de la capacidad "Clave de descifrado adicional (ADK)" (con objetivos similares a la custodia de claves), un aspecto del software comercial PGP al que muchos ya se habían opuesto en principio. Permitió que un atacante modificara la clave de un usuario (certificado) para agregar su propia clave como una clave de descifrado adicional, y así descifrar los mensajes interceptados realizados con las versiones vulnerables de PGP. NAI lanzó versiones fijas muy rápidamente, y también actualizó los servidores de llaves para detectar ese problema y dos problemas relacionados con los revocadores designados; consulte La respuesta de Zimmerman . Tenga en cuenta que GnuPG se niega a admitir ADK en absoluto.

Aquí hay otro ejemplo, aunque no con los servidores de claves o PGP. En 2010, se observó un ataque de desbordamiento de búfer que "permite la ejecución de código arbitrario" para al menos un producto con certificados X.509. En ese caso, realmente sucedió durante una conversación con un punto final no confiable: Vulnerabilidad de desbordamiento del búfer de procesamiento de certificados de yaSSL - CNET

¿Cómo puedes evitar este tipo de problemas? En este caso específico, por supuesto, es mejor obtener las claves de forma directa y segura de las personas con las que desea mantener correspondencia. Enumero los protocolos que son más seguros que el protocolo de servidor de claves HKP tradicional (pero no estandarizado e inseguro) en ¿No debería buscarse la clave GPG? ¿conexión segura? .

Más allá de eso, se aplica la higiene general del software. Utilice software bien estudiado de personas conocidas por sus prácticas seguras, mantenga su software actualizado, tenga cuidado de dónde obtiene cualquier tipo de datos que procesa en su computadora, minimice su superficie de ataque, compartimente su procesamiento de datos, etc.

No estoy seguro de si hay algo específico para OpenPGP, pero el problema que describe no parece ser específico en este contexto.

Que yo sepa, los ataques que conducen a la ejecución de código arbitrario (por ejemplo, basado en desbordamientos de búfer) podrían suceder en el procesamiento de cualquier tipo de datos no confiables a priori que puedan procesarse. Ya sea que ocurra en el código que procesó una clave con formato incorrecto o cualquier otra forma de datos, probablemente no importa mucho en este contexto.

Cada vez que ejecuta un código que procesa algunos datos en los que aún no confía (y de una manera en la que confía), desea que el código esté libre de errores, al menos libre de errores que podrían conducir a un código arbitrario Ejecución u otros problemas de seguridad. Si los datos son utilizados posteriormente por un mecanismo de seguridad es una preocupación secundaria en este caso. (Por supuesto, también desea que la implementación de la verificación de firma necesaria sea correcta. Ahí es donde importa por motivos de seguridad).

El mismo tipo de problema podría ocurrir con cualquier pila TLS basada en X.509, por ejemplo. Desearía que la pila TLS no permitiera que los certificados mal formados dejen que un atacante controle su sistema (de nuevo, eso es cierto para cualquier sistema que procesa una cantidad de bytes que no conoce de antemano). La validación y la verificación correctas del certificado que le permitirán confiar en la conexión TLS establecida una vez que el protocolo de enlace se haya completado con éxito es muy importante, pero solo una cuestión secundaria, entonces.

Creo que la principal diferencia en comparación con otros tipos de datos radica en la dificultad de implementar este tipo de código correctamente. Las estructuras de almacenamiento utilizadas en el contexto de PGP o X.509 tienden a confiar en ASN.1, que puede ser tan clara como el barro en muchos casos. Escribir un código libre de errores relacionado con ASN.1 no es fácil (IMHO).

Creo que la cita de Thomas (" ... no debería confiar en el servidor de claves ... ") tuvo más que ver con el hecho de que no puede confiar en el servidor de claves como entidad que avala por la llave que sirve. Esto es solo un servicio de alojamiento, a diferencia de un editor / editor / autor.