Transmitir información encriptada a SaaS utilizando AES

Question

Transmitir información encriptada a SaaS utilizando AES

#1 de Stephane (1 votos)
#2 de J.A.K. (0 votos)

0

Soy nuevo en todo lo relacionado con el cifrado. He estado leyendo mucho sobre esto últimamente pero todavía tengo algunas preguntas. Por lo tanto, tengo la tarea de crear una solución de inicio de sesión en nuestro lado que transmita de forma segura la información de nuestros servidores a un SaaS.

Esta información es altamente confidencial (aunque no las contraseñas) y por eso necesitamos cifrarla. Lo que estoy tratando de comprender es cómo hago para enviar información sobre cómo descifrar esta información a SaaS. En este momento lo tengo configurado en .net que lo cifro usando AES con una clave de 256b bit, 128 bit IV, usando el relleno PKCS7 y el modo de cifrado CBC. He leído información conflictiva sobre si debo o no cambiar la clave y la IV cada vez que no. Si cambio la clave y la IV cada vez, ¿cómo le digo esto a mi SaaS de forma segura para que puedan descifrar la información? ¿Hay alguna otra práctica mejor que deba hacer para enviar esta información a SaaS para que sea descifrada?

web-application encryption aes

pregunta ios85 15.09.2016 - 14:55

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application encryption aes

Ejemplo de neutralización del registro - ¡Ayúdame a entender! Mediawiki / Nginx / Php en Ubuntu 14.04 está siendo atacado

score 1 · Answer 1

Primero, sugiero que no intentes reinventar la rueda : a partir de tu descripción, ya estás fuera de tu alcance y deberías intentar construir tu propia seguridad de esta manera (incluso si utilizas buenas primitivas).

Básicamente, primero debe comprender si desea proteger sus datos en tránsito o en reposo (o ambos).

Si desea cifrar datos en tránsito , entonces use TLS . Puede analizar qué tipo de certificado o autenticación, reflexionar sobre qué soporte necesita, pero en ningún momento debe intentar reemplazarlo con algo propio.

Si desea cifrar datos en reposo , las cosas son un poco menos claras . Sin embargo, la regla general sigue siendo la misma: elija un conjunto de estándares que se ajuste a sus necesidades ( S / MIME , PGP , PKCS # 12 para nombrar algunos ejemplos) y usa eso. Descubrirá rápidamente que la parte difícil no es el cifrado sino la gestión de claves : almacena sus claves criptográficas de forma segura y al mismo tiempo les permite ser utilizado cuando sea necesario es un verdadero desafío en casi todos los casos.

Sin embargo, aquí hay un par de respuestas a sus preguntas:

Los IV deben volver a generarse para CADA mensaje y nunca volver a usarse. Ese es un requisito para que el CBC sea "seguro". (tenga en cuenta que, personalmente, cuando tuve que lidiar con CBC preferiría suspender los datos con un solo bloque de datos aleatorios que descartaría al descifrar. Me resultó más fácil tratar con ellos que hacer un seguimiento de las IV). p>

La clave, sin embargo, es secreta. Dependiendo de su necesidad exacta, puede ser estático (que nunca cambia durante el funcionamiento normal) o dinámico (podría ser único para cada mensaje y derivarse de un protocolo de intercambio de claves o generarse aleatoriamente antes de ser cifrado con un cifrado asimétrico como RSA ) .

Hablando de CBC , sepa que NO se considera un modo seguro: puede ser vulnerable a ataques de oráculo de relleno .

score 0 · Answer 2

Sí, para todas las aplicaciones que requieran una seguridad sólida, reusar las claves es una mala idea (código de rodar de tos para toser tos). Pero cambiarlos sin transmitir siempre fue un problema difícil. Luego apareció el cifrado asimétrico.

Creo que lo que estás buscando es el protocolo de intercambio de clave efímero Diffie-Hellman. Esta es una forma de renegociar claves sin que un intruso pueda adquirir la clave.

Más información