¿Generando certificados X.509 deterministas?

Por el momento, no veo un gran problema aquí, al menos, desde el PoV del propio algoritmo.

1. Siembra un PRNG con, por ejemplo, un hash de tu frase clave.
2. Use el PRNG para generar el par de claves RSA.
3. Use una biblioteca para generar el certificado, poniendo su material clave en él.

El determinismo se logra mediante el uso de PRNG sembrado con la misma frase clave (probablemente salado y puesto, por ejemplo, SHA-256), por lo que la salida es la misma para la misma entrada. Todos los algoritmos requeridos se pueden implementar fácilmente en Python, o el código existente se puede reutilizar, por ejemplo. Python-RSA . El único ajuste requerido sería usar su PRNG en lugar de lo que está usando ahora.

El punto 3 es la parte más difícil ya que no soy un gran experto en bibliotecas, pero esto parece ser parte de otro problema (generar un certificado a partir de material clave existente). Esto cae en la categoría "cuál es la mejor biblioteca para ...".

Como de costumbre: azotar su propio cripto generalmente se desanima y desaprueba, a menos que usted sea Bruce Schneier. ;-)

Como lo indica @Dmitry, lo que imaginas es factible. La generación de pares de claves RSA, en realidad cualquier generación de pares de claves, se alimenta de un PRNG ; El PRNG en sí mismo es un algoritmo determinista que "extiende" una semilla aleatoria inicial a una secuencia arbitrariamente larga de bytes pseudoaleatorios. Podría usar una función de hash de contraseña segura y utilizar el valor de hash resultante como semilla para un PRNG.

Sin embargo, hay algunos problemas secundarios que pueden ser molestos. Por ejemplo:

• El hash de contraseña funciona mejor cuando hay un salt , que no es secreto pero se debe almacenar en algún lugar.
• Cambiar tu contraseña implica cambiar tu clave privada, lo que generalmente es bastante inconveniente.
• La clave pública (que es pública) se puede usar como prueba para un ataque de diccionario sin conexión : los atacantes pueden probar las contraseñas "en casa" hasta que se encuentre una coincidencia con la clave pública conocida.

Amplié más sobre ese tema en esta respuesta .

Recuerde que el certificado (que contiene la clave pública) debe almacenarse en algún lugar, ya que no puede volver a crearlo a partir de la contraseña (el certificado está firmado por la CA y no puede volver a calcular esa firma, ya que no eres tu propio CA). Podría generar su clave privada "normalmente", cifrarla con un sistema de cifrado basado en contraseña y almacenarla junto con el certificado; esto sería equivalente, desde un punto de vista de seguridad, a la derivación de clave de contraseña a RSA; pero al menos funcionaría con los formatos y herramientas existentes (podría usar PKCS # 12, también conocido como "pfx", como el formato de archivo protegido por contraseña para el certificado y la clave privada).

El certificado X509 está, básicamente, hecho de varios tipos de información:

• Los datos declarativos del certificado, que incluyen todo lo que los certificados reclaman sobre el propietario de la clave (principalmente lo que encuentra en los campos de asunto del certificado, pero también comúnmente son OID gusta)
• Los datos de alcance del certificado (por ejemplo: uso de clave, período de validez, etc.)
• La mitad pública del par de claves asociadas con el certificado.
• La información de la cadena de confianza del certificado (que garantiza que los datos declarativos y de alcance son correctos) y los datos de revocación
• Algunos campos técnicos (qué algoritmo se usa, cuál es el número de serie del certificado, etc.)

Puede poner cualquier cosa que desee en los datos declarativos y de alcance y puede controlar lo que está en los campos técnicos (en su mayoría) siempre que su CA acepte validar su certificado cuando lo envíe (o mientras esté utilizando certificados autofirmados).

La parte de clave pública del certificado está dictada por cualquier algoritmo de clave que haya decidido utilizar. Podría usar la misma clave para todos sus certificados, aunque no le sugiero que lo haga: no hay una razón válida para hacerlo en la práctica y podría poner en peligro la seguridad de todo el sistema, dependiendo de cómo se utilicen las claves.

Finalmente, la información de confianza incluye principalmente la referencia del emisor (que en su mayoría puede decidir o, al menos, saber de antemano en la mayoría de los casos) y la firma digital de todo el certificado (que no tiene forma de conocer o controlar) ). El uso de un certificado autofirmado no le ayudaría, en este caso, ya que la única forma de que las dos firmas sean 100% idénticas sería que todas las partes de los datos de la firma también sean idénticas: también puede hacer una copia. del certificado original en lugar de firmarlo dos veces.

La buena noticia, sin embargo, es que si bien no debe usar la misma clave para varios certificados, no tiene que hacerlo. Simplemente puede crear su propia CA y hacer que su aplicación verifique todos los certificados contra esa raíz de la CA: eso permitirá a todos sus usuarios verificar las claves que está distribuyendo, incluidas las claves futuras, sin necesidad de debilitar la infraestructura al reutilizar una Conjunto fijo de llaves.

Fijar la autoridad del certificado, en lugar del certificado hoja, es un poco más complejo de implementar, pero también es más flexible y permite un uso más complejo de los escenarios.