¿Cómo se garantiza la seguridad de la clave privada RSA del servidor?

Para mayor seguridad, la clave privada debe guardarse en un HSM (o tarjeta inteligente que implementa un HSM mínimo). Es difícil extraer la clave privada de eso, especialmente de forma remota, excepto por un error o puerta trasera en la configuración o implementación del HSM. Esto se debe a que todos los algoritmos de firma buena (resp. Cifrado) tienen la propiedad de que no importa cuántas firmas (resp. Descifrado) se obtienen, es imposible deducir la clave privada o un equivalente funcional completo de eso.

El HSM también es valioso porque se evalúa en seguridad, incluso contra ataques de canal lateral como la sincronización, e intrínsecamente invulnerable a otros (como, fugas de una VM a otra debido a errores de supervisor o estados de caché de CPU física). Un HSM normalmente viene con medios para imponer roles de administrador / operador; ponga el HSM (normalmente, por defecto) en un modo seguro (no operativo); zeroise datos confidenciales sobre algunos ataques; hacer copias de seguridad cifradas de claves; En algún momento, las operaciones de registro. Además, algunos HSM proporcionan un aumento significativo del rendimiento en comparación con las soluciones de solo software.

Sin embargo, un atacante que obtiene acceso de root a un host con HSM mientras está operativo, puede realizar firmas o descifrados (el HSM solo hace necesario que el atacante tenga algunas habilidades especializadas en HSM). Por lo tanto, una intrusión persistente no detectada en una máquina que usa un HSM es casi tan buena para un atacante como obtener la clave privada; y en la mayoría de los casos de firmas, la revocación de la clave privada es necesaria si un atacante tuvo acceso temporal, por lo que el hecho de que no se pueda extraer la clave privada es discutible.

En la autenticación de clave pública SSH, hay dos pares de claves involucradas.

• El usuario mantiene el primer par que intenta autenticar en el servidor . La clave privada para cada usuario se mantiene en la estación de trabajo personal del usuario u otro sistema cliente , no en el servidor al que se realiza la conexión. Además, la clave pública de cada usuario se mantiene en el archivo "authorized_keys" de ese usuario y no en un repositorio central. Por lo tanto, no hay un equivalente del archivo de contraseña / sombra existente en el servidor para que lo robe un atacante.
• El servidor mantiene el segundo par, y está allí para autenticar el servidor al usuario . Si bien la clave privada de este par se mantiene en el servidor, es irrelevante porque no proporciona autenticación del usuario en el servidor. Más bien, es un paso adicional que garantiza (cuando se configura correctamente) que el usuario está haciendo una conexión con el mismo servidor al que se conectó por última vez con ese nombre o dirección (o bien se activan muchas alarmas y el cliente SSH puede rehusarse a conectarse) ).

En conjunto, esto significa que un atacante tendría que piratear cada sistema cliente para obtener acceso al servidor para ese usuario, en lugar de piratear el servidor directamente. Es mucho más trabajo que hackear el lado del servidor.

Sin embargo, significa que ahora el sistema cliente debe fortalecerse contra ataques, especialmente para un usuario de alto valor (como un administrador del sistema con acceso privilegiado en un servidor una vez autenticado) que tiene literalmente las teclas al reino ;-) en el cliente / estación de trabajo. Esto se mitiga en la mayoría de los casos al exigir que la clave privada del cliente se cifre con una frase de contraseña, lo que solo es factible cuando el usuario en cuestión es una persona individual y no una cuenta mecanizada o "bot".

También hay sistemas "reforzados" o "bloqueados" en los que es imposible eliminar las claves del servidor. Es necesario generar las claves & almacenado en otro lugar, y el servidor solo permite que una pequeña lista blanca de programas los utilice después de importarlos.

Incluso si uno obtiene la clave, también debería estar protegida por contraseña, y obtener esa contraseña sería difícil de adivinar / fuerza bruta si se hace correctamente.

Las fugas de las claves privadas del servidor probablemente ocurran. Pero no reciben tanta publicidad.

Cuando se ha filtrado una base de datos de contraseñas, muchos sitios deciden obligar a los usuarios a cambiar su contraseña. Obviamente, esto genera más publicidad que si el sitio reemplaza silenciosamente su clave secreta sin obligar a los usuarios a cambiar su contraseña. Dependiendo de su punto de vista, esto puede tener sentido o no. Ciertamente, hay situaciones en las que una clave privada filtrada haría que sea mucho más importante para los usuarios cambiar su contraseña que una base de datos de contraseñas filtrada.

Hay algunas razones por las que es más probable que ocurra la filtración de una base de datos de contraseñas que la filtración de una clave privada.

En primer lugar, SSL puede terminarse en un hardware separado de la aplicación real. Es más probable que exista una debilidad en la aplicación que en la implementación de SSL debido a que la aplicación a menudo es más complicada que el protocolo SSL y debido a que la aplicación no se ha revisado tan cuidadosamente.

Si se encuentra una debilidad en la aplicación, pero SSL se termina en otra computadora, entonces esa debilidad no dará acceso a la clave privada. Además, incluso si estaba en el mismo equipo, en algunas implementaciones, la clave privada se coloca en un hardware seguro, de modo que incluso la implementación de SSL no tiene acceso completo a la clave secreta.

Además, las bases de datos de contraseñas pueden filtrarse debido a vulnerabilidades de inyección de SQL, pero estas no dan acceso a las claves secretas de SSL.

Si se filtra la clave secreta, el administrador puede comunicarse con la CA para que se revoque el certificado. En principio, eso detendrá la amenaza planteada por la fuga.

Sin embargo, tan pronto como la clave secreta haya sido filtrada, podría ser abusada en ataques mitm. Tal ataque mitm podría dar al atacante acceso a las contraseñas en texto claro. Eso hace que la contraseña obtenida de esta manera sea más fácil de explotar que una de una base de datos de contraseñas filtrada, ya que cualquier persona con un poco de pista tendrá una contraseña de hash antes de guardarla.

Por otra parte, el uso de la fuerza bruta en una base de datos de contraseñas filtradas es probable que revele al menos algunas contraseñas de texto claro, y estas pueden ser objeto de abuso sin necesidad de montar un mitm-attack en primer lugar.

Por lo tanto, hay razones para requerir que los usuarios cambien su contraseña en cualquiera de los dos casos, cuál de los dos incidentes sería peor depende de muchos otros factores, incluida la fortaleza de la contraseña. Una contraseña segura permanecerá segura incluso en el caso de una base de datos de contraseñas filtrada (a menos que la base de datos de contraseñas esté almacenada sin cifrar), pero si se realiza un mitm-attack utilizando una clave privada filtrada, la fortaleza de la contraseña no hace ninguna diferencia.