Validar la clave utilizada para cifrar los datos sin enviar la clave

Question

Validar la clave utilizada para cifrar los datos sin enviar la clave

#1 de dark_st3alth (1 votos)
#2 de DDS (1 votos)
#3 de Serge Ballesta (1 votos)

1

Dado: algunos datos ( D ) cifrados con la clave ( K ), lo que resulta en la carga útil cifrada ( E ). ¿Es posible enviar E (junto con cualquier otra cosa requerida) a un servidor para almacenar? Y luego verificar que se usó K para cifrar los datos originales que resultaron en E , sin enviar K en formato de texto sin formato?

El propósito de esto es que un usuario que no conoce los datos originales desea tener acceso a ellos y solo conoce K (se les proporcionó). Deben mostrar al servidor que saben que K se utilizó para cifrar los datos antes de que el servidor les devuelva E para el descifrado real. Obviamente, todo este proceso no debe revelar el texto sin formato K al servidor ni debe enviarse a través de la red. Para que cualquier persona que vea la red o se siente en el servidor no tenga acceso gratuito a K .

Una posible solución que se me ocurrió es enviar una versión con hash local de K con E para el almacenamiento en el servidor que luego se puede verificar con otra versión con hash local de K más tarde. Si los dos valores de hash de K (el enviado en la solicitud y el almacenado en el servidor) coinciden, entonces K era correcto en lo que respecta al servidor .

¿Puede ver algún problema con la solución anterior o puede sugerir un enfoque más seguro?

Editar: En este sistema hipotético, los usuarios son anónimos, por lo que la autenticación del usuario no puede ser parte de la solución. Un usuario simplemente deberá proporcionar al servidor algún tipo de token que demuestre que tiene conocimiento de lo que es K . Si es correcto, el servidor responderá con E , si es incorrecto, no devolverá nada.

hash encryption

pregunta Speedy 10.01.2017 - 02:29

fuente

3 respuestas

Lea otras preguntas en las etiquetas hash encryption

¿Cómo almaceno los datos de sesión en un servidor de forma segura? Cómo afecta la longitud de la clave simétrica a TLS si la PK del servidor es fuerte

score 1 · Answer 1

Esto parece ser una pregunta de autenticación y autorización, a menos que me equivoque. Desea autenticar y autorizar a los usuarios con un solo código / cadena / clave.

Las claves de cifrado están diseñadas para mantenerse secretas, se llaman "claves secretas" por una razón. No hay razón para que un intermediario (el servidor) almacene ninguna forma de ello. Esto finalmente aumentaría la superficie de ataque sin necesidad.

Sugeriría usar dos secretos alternativos, en los cuales los hashes se almacenan en el servidor. El primero sería de los datos, de modo que solo los usuarios que puedan demostrar el conocimiento de los datos a través de un hash puedan ser autorizados. El segundo sería el secreto alternativo, de modo que si se comprometiera (como leer los datos de un sistema de archivos), el atacante aún no tendría idea de cuál es el verdadero secreto.

Esto no solo tendría el beneficio de una mayor seguridad (revocar el secreto alternativo) sino que también agrega un nivel de autorización, ya que solo los autorizados deben conocer el hash de los datos.

score 1 · Answer 2

También recomiendo que haya dos claves. La primera clave (K ') es para la autenticación (establecer el conocimiento de una clave). La segunda clave se utiliza para descifrar E. Dado que el servidor no devuelve D y no tiene el requisito de conocer K, el servidor no necesita conocer K.

El usuario presenta K 'al servidor. El servidor mantiene una copia hash de K 'para su verificación. De esa manera K nunca pasa por la red. Incluso si alguien obtuvo K 'y E, todavía no puede descifrar E sin K.

score 1 · Answer 3

El problema en su algoritmo, es que los mismos datos se intercambiarán muchas veces. Si un atacante puede obtener una vez la versión de hash de la clave, podrá devolverla a voluntad y recibirá una E.

Al menos, el servidor debe enviar una cadena aleatoria, y el usuario debe devolver la cadena codificada con K (o un hash de ella). De esa manera, debería ser inmune a los ataques de reproducción siempre que la cadena aleatoria utilice un generador aleatorio criptográficamente seguro.

Pero en términos generales, una clave simétrica debe ser un secreto, y un secreto compartido entre más de dos personas ya no es un secreto. Tal vez podría echar un vistazo a criptografía de clave pública que se utiliza, por ejemplo, en correos cifrados:

los datos están cifrados con una clave aleatoria
la clave está encriptada con las claves públicas de todos los destinatarios
la carga útil son los datos cifrados con todas las versiones cifradas de la clave

De esta manera, la clave secreta se usa solo una vez: incluso si se comprometió, nunca se reutilizará, y solo las personas que tengan las claves privadas pueden decodificar el mensaje