Tengo la necesidad de que alguien más cifre datos secretos con mi clave pública que luego pueda descifrar con mi clave privada. He producido un par de claves pública / privada RSA con OpenSSL, les di la clave pública y tengo todo funcionando.
Más recientemente, alguien señaló que estamos sujetos a un posible ataque man-in-the-middle donde los malos aceptarían mi clave pública y pasarían su propia clave pública al otro lado. El otro lado cifraría diligentemente los datos secretos, se los pasaría al MITM, quien los descifraría y volvería a cifrarlos con mi clave pública antes de pasarlos a mí sin que yo lo supiera. La solución recomendada es que mi clave pública esté firmada por una CA en la que la otra parte confíe antes de pasarla.
Como experimento, produje un CSR que pude firmar con mi propia CA, pero el certificado resultante también contiene la clave privada (encriptada). Preferiría no pasar mi clave secreta a nadie más, cifrada o no.
¿Hay alguna manera de que se firme mi clave pública?
Comentarios
- ¿El certificado contiene una clave privada? ¿Eh? ¿Cómo te las arreglaste para hacer esto? ¿Puedes publicar ese archivo en pastebin.com? (Rehacerlo con un segundo par de claves para que no ‘ no tenga que compartir el original).
- Creo que estoy empezando a comprender. Aunque necesito la clave privada para producir una CSR, la CSR y el certificado resultante no contienen la clave privada. Un certificado es efectivamente una clave pública firmada que es exactamente lo que quiero.
Responder
Firmar una clave pública es efectivamente un certificado. Estos son los pasos que tomo para producir un certificado de clave pública que pueda distribuir a otros para que puedan comunicarse de manera segura conmigo:
Configuración
- Genere las claves privadas:
openssl genrsa -out private.pem 2048
- Genere las claves públicas:
openssl rsa -in private.pem -outform PEM -pubout -out public.pem
- Cree una CSR (solicitud de firma de certificado)
openssl req -new -key private.pem -out certificate.csr
- Cree un certificado autofirmado (puede compartir este certificado)
openssl x509 -req -days 365 -in certificate.csr -signkey private.pem -out certificate.crt
Encriptación
openssl rsautl -encrypt -inkey private.pem -keyform PEM -in data> encrypted_data
Descifrando
- Extraiga la clave pública de los certificados
openssl x509 -pubkey -noout -in certificate.crt> certpubkey.pem
- Descifrar los datos
openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data> datos
Si tiene la intención de que su clave sea firmada por una CA, tendrá que enviar su archivo CSR (y algo de dinero en efectivo) a la CA de su elección, ellos le darán el certificado que puede usar en lugar del certificado autofirmado. mencionado en los pasos anteriores.
Comentarios
- Esto es un poco al revés de lo que estoy preguntando, pero servirá para fines de discusión. Para que la otra parte pueda descifrar, necesitan la clave pública extraída por mí que está sujeta al ataque MITM o necesitan el certificado completo que incluye la clave privada (cifrada)
- @ user1683793 El el otro extremo necesita dos certificados. El primero de los cuales ya deberían tener (el certificado CA autofirmado). El segundo contiene la clave pública que desea verificar y está firmado con el certificado CA (utilizando la clave privada CA asociada). La validez del segundo certificado se prueba utilizando la clave pública en el certificado CA. Las claves privadas siempre se mantienen privadas.
- Creo que quieres » -encrypt » y » -decrypt » en lugar de » -sign » y » -verify «. (Detalles aquí: czeskis.com/random/openssl-encrypt-file.html )
- No funciona: 2. Descifrar los datos no me funcionó. Con:
openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > dataobtengo este error / msg:A private key is needed for this operation - Sección
Setup, el paso2dapublic.pem; no ‘ t se usa en más pasos. ¿Cuál es el uso de esa clave pública cuando la CSR se genera con clave privada?
Respuesta
Debe haber tres entidades involucradas en el proceso:
- El remitente: usted
- El destinatario: el usuario
- Autoridad de certificación: tercero de confianza (o usted, en algunos casos)
El proceso que mantiene las cosas seguras es «El remitente», genera un par de claves (públicas y privadas). Me gusta referirme a estos como llave y candado para una mejor visualización. La clave (privada) nunca debe dejar la posesión del remitente, por eso se la llama clave privada.
El remitente genera una solicitud de firma de certificado (CSR) con la clave pública (bloqueo ) que se reenvía a la autoridad de certificación (tercero de confianza), la autoridad de certificación firma la clave pública (candado) con la clave privada de la autoridad de certificación.
La autoridad de certificación envía ahora la clave pública «Los remitentes» que está firmado por la clave privada de las Autoridades de Certificación de nuevo a «El Remitente», que ahora es el certificado.
El Receptor obtiene el certificado (digamos a través del navegador web) y verifica que es válido con la clave pública de las Autoridades de Certificación que tienen tanto «El Remitente» como «El Receptor», ya que son el tercero de confianza. Una vez verificada, se puede confiar en que la clave pública en el certificado * sea la clave pública del «Remitente» sin alteraciones.
Si «El Receptor» necesita enviar datos a «El Remitente», usaría la clave pública del certificado de confianza para cifrar los datos en cipertexto que luego se pasa a «El remitente». Dado que solo la clave privada de «El remitente» puede descifrar el texto cifrado que se cifró con la clave pública de «El remitente» a cualquier persona en el medio tiene esencialmente texto inútil y confuso.
En ciertos casos, «El Remitente» puede generar su propia Autoridad de Certificación firmando su propia CSR con un conjunto diferente de claves o autofirmando con el mismo conjunto de En este caso, la clave pública del «Remitente» debe ser conocida por ambas partes a través de un canal seguro para tener confianza. En el software, puede incluir un certificado en el entregable que se puede utilizar como tercero de confianza.
* confiable solo es válido si la autoridad de certificación mantiene una CRL (lista de revocación de certificados) y todas las partes supervisan la lista para garantizar que el certificado emitido no se haya comprometido. El caso en el que la autoridad certificadora está comprometida y la clave privada se filtra existe y cuando eso sucede, el agente comprometido puede usar la clave privada para generar un certificado confiable que imita al «Remitente» , en ese caso es posible un MITM y el MITM puede recibir datos de «El remitente», descifrar, almacenar, cifrar con un certificado válido que se parezca a «El remitente», y luego pasarlo a «El receptor».
Responder
Saque la clave privada encriptada de la copia del certificado de CA que creó (cuando se la dio a otras personas). La clave privada no no es necesario estar allí a menos que vaya a utilizarlo para firmar un certificado que contenga otro er clave pública.
Cuando envíe su clave pública, envíe un certificado completo (excepto la clave privada), firmado con la clave privada de CA asociada. Para verificar la validez de la clave pública que contiene, debe verificar el hash del certificado con el hash cifrado (que se cifró con la clave privada de la CA). Esto se descifra utilizando la clave pública de la CA . Si el descifrado es exitoso y el hash coincide con el hash del certificado, entonces se puede confiar en la información dentro del certificado.
También hay más que solo cifrado, por ejemplo, un ataque de reproducción en el que un atacante envía datos cifrados previamente guardados. TLS cubre mucho más de lo que la persona promedio pensaría, y no se recomienda en absoluto implementar un sistema similar. Use TLS siempre que sea posible para cualquier cosa que tenga la intención de ser privada.