¿Mi envío de información cifrada es seguro?

2

Por favor, tengan paciencia conmigo, ya que no soy un experto en seguridad. Tengo un servidor y un cliente. En el servidor, estoy cifrando un mensaje muy secreto (utilizando AES256-GCM para ocultar la información y proteger su integridad) que enviaré al cliente. Aunque el cliente nunca descifrará este mensaje, solo lo recibirá del servidor y lo enviará de vuelta al servidor con sus solicitudes. Mi servidor descifra y recibe el mensaje secreto que necesita para procesar otra información. Necesito asegurarme de que el cliente nunca sabrá de los contenidos dentro del mensaje. Estoy usando javascript (NodeJS) para mi código de servidor y se ve así (espero que sea fácil de leer y fácil de entender):

var crypto = require('crypto'); //get crypto library
var algorithm = 'aes-256-gcm'; // select which algorithm I want to use
var password = '3zTvzr3p67VC61jmV54rIYu1545x4TlY'; //Random generated 256bit key

function encrypt(text) {
  var iv = crypto.randomBytes(128) // generate a random 128bit iv for every encryption
  var cipher = crypto.createCipheriv(algorithm, password, iv)
  var encrypted = cipher.update(text, 'utf8', 'hex')
  encrypted += cipher.final('hex');
  var tag = cipher.getAuthTag();
  var enc = {
    content: encrypted,
    tag: tag.toString('hex')
  };

sendToClientOverInternet(enc,iv); //send the encrypted content + the iv to client over the internet

}

function decrypt(encrypted) {
  var decipher = crypto.createDecipheriv(algorithm, password, iv)
  decipher.setAuthTag(new Buffer(encrypted.tag, 'hex'));
  var dec = decipher.update(encrypted.content, 'hex', 'utf8')
  dec += decipher.final('utf8');
  return dec;
}

Me preocupan más los procesos y los métodos de encriptación que se oponen a la seguridad de la infraestructura. Con eso, podemos asumir que mi servidor es completamente seguro y que nunca se accederá a la contraseña codificada en mi código y que el transporte de datos a través de Internet se realiza a través de ssl.

Mi código con mis preguntas:

1) Primero, generé una clave global de 32 bytes de forma segura y aleatoria.

P: ¿Es este el tamaño correcto? ¿Alguna forma de mejorar la clave?

2) Tengo un método de cifrado que toma un poco de texto y lo cifra utilizando AES256-GCM. Luego toma este objeto cifrado y, junto con el iv (128 bit de seguridad generado aleatoriamente para cada mensaje) lo envía al cliente. El cliente, si lo deseaba, ahora podría ver este objeto cifrado y el iv.

P: ¿Es necesario proteger la integridad de los datos mediante GCM? Si utilizo CTR, ¿no sería imposible para el pirata informático descifrar y cambiar el mensaje de todas formas sin la clave? Entonces, ¿es GCM 'excesivo'? ¿Es seguro para el usuario enviar el iv y tenerlo accesible? ¿Es un 128 bit iv lo suficientemente largo? ¿Alguna gran mejora que pueda hacer aquí?

3) Tengo un método de descifrado que toma mi cadena cifrada y la descifra.

P: (No creo que se deba mejorar nada aquí).

Cualquier mejora o sugerencia sería muy apreciada.

    
pregunta user2924127 18.01.2016 - 23:53
fuente

2 respuestas

4

Supongo que el cliente y el servidor se comunican a través de algún canal seguro, por ejemplo. TLS? De lo contrario, cualquier persona sentada en el cable puede montar un ataque de repetición , es decir, interceptar el texto cifrado enviado al cliente y enviar ese texto cifrado a el servidor para hacerse pasar por el destinatario deseado.

A partir de los comentarios, parece que está utilizando el texto cifrado que se pasa al cliente como una forma de no mantener el estado en el servidor. Más específicamente, envía un mensaje al cliente de su estado cifrado y luego le pide que lo devuelva y descifre / procese ese estado al llegar. Si ya está almacenando las claves de cifrado, ¿es realmente mucho más difícil refactorizar el almacenamiento de tokens de sesión?

Con respecto a su pregunta usando GCM

  • El iv (o nonce como se llama generalmente en modo GCM) se envía junto con el texto cifrado, la seguridad de GCM no se basa en que el iv sea secreto, solo que nunca se reutiliza, por lo que 128 bits de aleatoriedad son correctos (aunque como afirma la respuesta de Xander, hay ataques teóricos contra ivs que no son de 96 bits). Siempre que su clave tenga suficiente entropía, debería estar bien.
  • GCM soluciona algunos de los problemas que tienen otros modos. CTR (que mencionó) y CBC, por ejemplo, tienen ataques de cambio de bits en su contra, donde el texto cifrado se puede modificar sin conocer la clave para producir cambios significativos en el texto plano. Los modos CBC y CTR requerirían un MAC del texto cifrado enviado junto con ellos para verificar su integridad. Entonces, si bien es posible usar estos modos de manera segura, se requieren un par de pasos más que GCM.

En conclusión, esta construcción es poco ortodoxa, y un mecanismo como los tokens de sesión mejoraría el rendimiento (y daría el beneficio de ser un método probado y comprobado). Si debe seguir esta ruta, GCM debería estar bien para mantener los datos protegidos del cliente.

    
respondido por el puzzlepalace 19.01.2016 - 09:23
fuente
3

En general, todo parece razonable, pero hay un par de elementos para revisar:

  • En primer lugar, la nota de la respuesta de Puzzlepalace sobre la necesidad de TLS es definitivamente la más importante. Y preferiblemente HSTS también, si puedes.

  • En segundo lugar, hay ataques teóricos (leídos, no prácticos) en GCM con nonces (IV) con longitudes distintas de 96 bits. Entonces, aunque esto no sea crítico, ciertamente sería una práctica recomendada acortar su nonce de 128 bits a 96.

  • Tercera y finalmente, administración de claves. Las claves deben almacenarse en un lugar seguro, y definitivamente no en el código fuente. No deben comprometerse con el control de la fuente, almacenarse en texto sin cifrar, compartirse entre entornos, ser conocidos por usuarios distintos de los operadores del entorno y rotarse regularmente. Entonces, esto prácticamente descarta tener sus claves en el propio código fuente de la aplicación.

No soy un experto en Nodos de ninguna manera, pero aparte de esos problemas, pero el enfoque es ciertamente bueno.

    
respondido por el Xander 19.01.2016 - 17:09
fuente

Lea otras preguntas en las etiquetas