¿Un hash firmado revela alguna información sobre el mensaje original?

4

Como parte del cifrado de extremo a extremo de mi aplicación, estoy siguiendo el procedimiento estándar de usar RSA para intercambiar la clave temporal AES256. Actualmente, cuando A decide la clave para enviar a B, la cifra con la clave pública de B. Todo esto está participando a través de una conexión TLS al servidor. Sin embargo, B está tomando la clave en la fe ciega de que proviene de A. Por supuesto, no es como si alguien pudiera enviar a B la clave AES256. Debe iniciar sesión primero en el servidor antes de que esté dispuesto a pasar mensajes a A. La clave AES256 también se envía solo durante la configuración de una sesión entre A y B que B tendría que haber aceptado antes. El servidor también verificará que haya un inicio de sesión solicitado entre X y B antes de enviar algo a B y que realmente es X con lo que B quiere tener una sesión. El objetivo de extremo a extremo es evitar que el servidor sepa lo que está pasando entre A y B (incluso si es el mío).

Pensé que hacer que A incluyera un hash firmado de la clave a B le aseguraría a B que la clave realmente provenía de A. Sin embargo, Java en Android no puede cifrar el hash firmado porque es exactamente de 2048 bits ( como se esperaba). ¿Habría algún peligro con solo transmitir el hash firmado (Java RSA con SHA512) a plena vista? Según tengo entendido, los hashes son forzados a la fuerza bruta, lo que en este punto, de todos modos, es mejor que fueres la fuerza de la clave AES.

Editar: Como parece que la gente está llegando al corazón del problema: el cifrado sobre UDP, lo que está hecho está hecho. Voy a escribir cómo lo estoy haciendo actualmente. Es mi propio proyecto personal, así que doy la bienvenida a cualquier mejora. No estoy apegado emocionalmente al método actual.

(Todo esto tiene lugar sobre una conexión TLS existente ya que el socket "comando" es TCP)

  • A genera la clave AES256 usando SecureRandom de java.
  • A obtiene una copia de la clave pública de B del servidor.
  • A envía una clave de cifrado RSA a B mediante el uso de RSA / NONE / OAEPWithSHA1AndMGF1Padding de android. Esto se elige para el relleno OAEP que (por lo que he leído) suena como el mejor método para hacer que la entrada a RSA se vea lo más aleatoria posible para evitar que la salida tenga ciertas características basadas en la entrada.
  • B recibe el mensaje y envía un comando "ok" al servidor que le dice a A.

(El resto tiene lugar sobre UDP liso)

  • A envía un mensaje a B usando AES / GCM / NoPadding del cifrado de Android. Se eligió GCM porque (por lo que he leído) es el mejor método para "cortar" los datos en partes seguras. Se supone que GCM debe contener un MAC, así que asumo que se encarga de la autenticación para mí. Se crea una instancia de una nueva instancia de cifrado para cada bloque de datos. Estoy asumiendo que el cifrado de android.init se encarga de la IV (nuevo para cada bloque). Después de cifrar. los datos se envían [longitud IV; IV; datos AES256 / GCM]. Por lo que he leído, el IV es como una sal que se usa para prevenir ataques precalculados. Normalmente, en una base de datos, la sal se almacena en texto plano, por lo que en este caso se transmite en formato plano. (Si no fuera así, se crea un problema de regresión infinita).
  • B realiza el proceso inverso y envía una respuesta a A utilizando el método descrito anteriormente.

Se utiliza una nueva clave AES256 para cada sesión entre las 2 para el secreto hacia adelante. En términos de reproducción, los datos de texto sin formato tienen un número de secuencia. He visto fallas de descifrado de MAC en los registros al usar LTE al comienzo de la sesión. No he tenido una explicación plausible de por qué.

    
pregunta AAccount 18.03.2018 - 03:16
fuente

1 respuesta

4

Creo que este es un caso del problema XY . Está intentando permitir la autenticación en su esquema de protocolo y está preguntando cómo hacerlo de manera segura utilizando un método que implícitamente asuma que es necesario. La realidad es que ya hay muchas formas de probar que una clave dada es auténtica sin enviar un hash de la clave. Le sugiero que lea en cómo TLS proporciona autenticación sin firmar realmente la clave de la sesión. Como ese es el tema de otra pregunta, responderé específicamente si el hash firmado de un mensaje (como una clave compartida) revela información sobre el contenido del mensaje original (tl; dr la respuesta es no, no lo hace).

Firmar un mensaje implica calcular el hash del mensaje y firmar el hash. Debido a que la firma depende solo del valor del hash, podemos ignorar la firma de manera segura. No da más información sobre el mensaje que el hash en sí. Entonces, ¿podemos atacar el hash?

Un ataque que le permitiría a alguien aprender información sobre la entrada a una función hash dado que solo el resumen en sí mismo se denomina (primer) ataque de preimagen. Más específicamente, este es un ataque contra alguna función de hash f donde, dado un solo digesto h , uno puede encontrar un mensaje arbitrario m tal que f (m) = h más rápido que la búsqueda exhaustiva. Todos los hash criptográficos modernos * , como SHA-512, son conjeturados para ser resistentes a la preimagen. Como tal, proporcionar el hash a un mensaje no proporciona información sobre el mensaje en sí. La única forma posible de que un atacante pueda encontrar el mensaje es si es lo suficientemente corto como para que sea posible forzar bruscamente el mensaje hasta que se encuentre un hash correspondiente.

Para futuras referencias, hay tres clases de ataques contra una función de cifrado criptográfico f :

  • Ataque Preimage : dado h donde f (m) = h , encuentra cualquier m ' tal que f (m ') = h .

  • 2do ataque de preimagen - Dado m , encuentre cualquier m ' tal que m ≠ m' y f (m) = f (m ') .

  • Ataque de colisión : encuentre cualquier par de m y m ' de manera que m ≠ m' y f (m) = f (m ') .

Se supone que un hash criptográfico ininterrumpido con una longitud de resumen de n tiene una resistencia en la primera pre-imagen y en la segunda preimagen de 2 n y una resistencia de colisión de 2 n / 2 . Este es el caso de SHA-512.

* Formalmente, un hash criptográfico resistente a la colisión y preimagen se define como una función que asigna una entrada de longitud arbitraria a una salida de longitud fija. Para un espacio de mensajes de {0,1} * y algunos n fijos, el algoritmo para la función de hash criptográfica f se define como {0, 1} * → {0,1} n . Esto se explica con más detalle en una respuesta en Crypto.SE .

    
respondido por el forest 18.03.2018 - 03:29
fuente

Lea otras preguntas en las etiquetas