RSA o ECDHE para los certificados x.509: ¿qué hace cada uno?

2

Soy relativamente nuevo en los certificados x.509, pero recientemente he estado buscando en el candado de conexión https en la parte superior de la pantalla. En ciertos sitios web, al hacer clic en el botón me informa que el sitio se está conectando de manera segura a través de un intercambio de claves, ECDHE, y estas claves están firmadas con RSA. Pero, cuando abro el certificado completo para el sitio, la clave pública es RSA 2048 bits. Esto me confundió, ya que pensé que la clave pública debería ser ECC de 256 bits, y no una clave RSA, ya que el intercambio de claves es ECC, y no RSA.

Probablemente me esté perdiendo algo realmente obvio, pero cualquier ayuda sería apreciada.

    
pregunta Sam Gregg 01.02.2017 - 21:41
fuente

3 respuestas

2

Las claves públicas / privadas son (bastante) estáticas y normalmente son 2048 bits o incluso 4096 bits; se usan al principio de la negociación TLS, para verificar la identidad del sitio (y la del cliente, en el caso de un certificado de cliente) y para negociar usando encriptación asimétrica una nueva clave que será a) compartida entre el cliente y el servidor, b) única para esta conexión yc) simétrica. Esta es la clave que realmente se intercambia y es más corta y la que se usa para el transporte real.

El cifrado asimétrico es (relativamente) lento, es por eso que la sesión en realidad está cifrada con un cifrado simétrico.

    
respondido por el crovers 01.02.2017 - 21:47
fuente
2

Un esquema de intercambio de claves consta de dos algoritmos:

  • Algoritmos de generación de claves, que seleccionan aleatoriamente un par de llaves;
  • Un algoritmo de intercambio de claves, que toma como entrada su clave privada y la clave pública de la parte remota, y genera un secreto compartido.

Un esquema de firma es un triple de algoritmos:

  • Un algoritmo de generación de claves, que selecciona aleatoriamente un par de llaves.
  • Un algoritmo de firma, que toma un mensaje y una clave privada y genera una firma.
  • Un algoritmo de verificación, que toma un mensaje, una firma y una clave pública, y genera un booleano que indica si la combinación es válida.

Para realizar un intercambio de clave efímero autenticado, las partes deben acordar un esquema de intercambio de clave y un esquema de firma, y deben tener una clave pública autenticada de la firma. Entonces:

  1. Ambas partes generan su propio par de claves de intercambio de claves efímeras;
  2. Ambas partes firman su clave pública de intercambio de clave efímera;
  3. Ambas partes envían su clave pública de intercambio de clave efímera a la otra, junto con la firma de esa clave;
  4. Ambas partes verifican la firma en la clave pública de intercambio de clave efímera del otro y abortan si no es válida;
  5. Ambas partes ahora usan su clave privada de intercambio de clave efímera y la clave pública de intercambio de clave efímera del otro para calcular el secreto compartido.

Esto también puede hacerse haciendo que solo una de las partes firme su clave pública de intercambio de clave efímera. Así es como normalmente hacemos HTTPS, por ejemplo. La otra parte, a continuación, no obtiene ninguna garantía de que la otra persona sea quien dice ser.

Puede elegir cualquier combinación de firma y algoritmos Diffie-Hellman para esto. No importa si el esquema de firma es RSA y el esquema de intercambio de claves es ECDH. En ese caso, el paso # 1 usa el algoritmo de generación de claves ECDH para generar un par de llaves ECDHE, y luego el paso # 2 usa el algoritmo de firma RSA para firmar esa clave pública ECDHE. Al algoritmo de firma no le importa que el mensaje que está firmando sea una clave pública de ECDHE: solo son datos para que una parte firme y luego la otra para verificar.

Otra cosa a tener en cuenta es que el título de tu pregunta revela que estás confundido acerca de algo:

  

RSA o ECDHE para los certificados x.509: ¿qué hace cada uno?

ECDHE no está involucrado en el certificado. El certificado contiene una clave de firma pública , los metadatos que describen a su propietario y las firmas para ayudar al destinatario a autenticar que los metadatos son precisos. El algoritmo de firma más popular utilizado en los certificados es RSA. ECDSA es otra alternativa. ECDH no es relevante, porque no es un algoritmo de firma.

Con los certificados, el algoritmo de boceto anterior se modificaría agregando dos pasos al principio:

  1. Ambas partes se envían sus certificados entre sí.
  2. Ambas partes usan su PKI para verificar el certificado del otro y abortan si no es válido.

Luego, el procedimiento continúa utilizando las claves adjuntas del certificado para firmar y verificar el intercambio de claves.

    
respondido por el Luis Casillas 02.02.2017 - 02:43
fuente
1

Preguntas relacionadas:

Respuesta corta: una sesión TLS tiene los siguientes cuatro pasos principales: (algo simplificado)

  1. El cliente y el servidor están de acuerdo con una suite de cifrado, mi navegador y security.stackexchange.com acordaron con TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) , así que usemos eso como ejemplo.
  2. El cliente obliga al servidor a probar quién es haciendo una firma de clave pública de los datos proporcionados por el cliente. En nuestro ejemplo, usaría RSA .
  3. El cliente y el servidor realizan un intercambio de claves para establecer una clave de sesión. En nuestro ejemplo, usarán ECDHE con la curva secp256r1 . El servidor firmará los mensajes ECDHE con su clave RSA solo para evitar un ataque de intermediario.
  4. Una vez que se haya establecido una clave de sesión y ambos lados (y nadie más) tengan una copia de la misma, usarán esta clave de sesión con un cifrado simétrico para el resto de la sesión, en nuestro ejemplo AES-128-GCM .
respondido por el Mike Ounsworth 02.02.2017 - 00:04
fuente

Lea otras preguntas en las etiquetas