Sugerencia sobre cifrado asimétrico (cifrado híbrido) para archivos grandes

1

Usaremos los siguientes comandos para cifrar el archivo de firmware en el servidor y eso se descifrará en la placa incorporada usando el comando de descifrado que se menciona a continuación,

El siguiente comando se utilizará para generar una clave simétrica de 128 bits de longitud

openssl rand 16 > ./symmetric.key

utilizaremos los siguientes comandos para crear claves privadas y públicas en formato PKCS # 8

openssl genrsa 4096 | openssl pkcs8 -inform PEM -topk8 -v2 aes-128-cbc -nocrypt -out keyfile.pem
openssl pkey -inform PEM -in keyfile.pem -pubout -out keyfile_pkcs.pub

Para cifrar el firmware utilizaremos el siguiente comando

openssl enc  -in firmware.tar -aes-128-cbc -salt -out firmware.enc -pass file:./symmetric.key

Tenemos dos opciones para cifrar / descifrar la clave simétrica en el lado del tablero,

Opción 1 . Cifre la clave simétrica usando una clave pública en el servidor y descifrela usando una clave privada en la placa.

Pensamos en usar los siguientes conjuntos de comandos,

openssl pkeyutl -encrypt -pubin -inkey keyfile_pkcs.pub -in symmetric.key -out symmetric.key.enc
openssl pkeyutl -decrypt -inkey keyfile.pem -in symmetric.key.enc -out decrypted_symmetric.key

Opción 2 . Cifre (firme) usando una clave privada en el servidor y descifre (verificar, recupere) usando una clave pública en el tablero. Pensamos en utilizar los siguientes conjuntos de comandos,

openssl pkeyutl -sign -inkey keyfile.pem -in symmetric.key -out symmetric.key.enc
openssl pkeyutl -verifyrecover -pubin -inkey keyfile_pkcs.pub -in symmetric.key.enc -out decrypted_symmetric.key

EDIT Solo para completar el comando para descifrar el archivo de firmware con una clave simétrica.

openssl enc -d -aes-128-cbc -in firmware.enc -pass file:./decrypted_symmetric.key -out firmware.tar

Ahora que somos nuevos en esta criptografía y OpenSSL, tenemos las siguientes dudas,

  

Duda 1 : ¿Qué opción elegir para cifrar la clave simétrica? (opción   1 o la opción 2)

     

Duda 2 : ¿Sugieres alguna mejora en los comandos anteriores? Lo ves   ¿Algún problema en este método?

¿Alguna otra sugerencia / corrección / punteros?

    
pregunta AnkurTank 17.06.2016 - 16:59
fuente

2 respuestas

2

No es una respuesta, pero solicitó sugerencias y esto sería mucho para comentarios (SX).

(0) openssl pkcs8 -topk8 ... -v2 aes-128-cbc -nocrypt es engañoso en el mejor de los casos, si no está mal. Si el archivo de salida no está cifrado, no importa qué algoritmo no se utilice para cifrarlo.

(1) openssl enc -pass file: (o -kfile ) lee la primera línea del archivo como una cadena , y la usa como contraseña (no clave) con un PBKDF débil. Tiene bytes aleatorios para 'contraseña', por lo que el débil PBKDF es tonto, no está roto, pero hay un 12% de probabilidad de que uno de los bytes aleatorios sea NL o nulo y la clave reduzca la entropía y un 6% de probabilidad tener la entropía lo suficientemente baja como para ser rota. Use el valor de rand -hex como clave con -K en mayúsculas; o use rand -hex o conviértalo a base64 (cualquiera de los dos da todo alfanumérico) y deje que el PBKDF (trivialmente) lo destile.

(2) El CBC no está autenticado y es algo maleable (aunque no es tan malo como los modos de transmisión) y no se agrega la autenticación. Si un atacante quiere que su dispositivo acepte un archivo alterado , es probable que puedan hacerlo después de una buena cantidad de trabajo, aunque los detalles dependen de su (s) archivo (s) y su (s) dispositivo (s).

(3) CBC requiere relleno y openssl enc usa PKCS # 5, y usted no se autentica; Si su dispositivo es observable, esto probablemente da un oráculo de relleno. Si un atacante puede proporcionar archivos diseñados y detectar si su dispositivo se descifra con éxito o no, pueden romper su cifrado rápidamente.

(4) Pero ¿por qué estás cifrando de todos modos? ¿Es este firmware secreto? La mayoría del firmware no lo es, y en la mayoría de las aplicaciones donde el firmware se descarga, lo importante es integridad y autenticidad , es decir, cargar solo el firmware autorizado mientras se rechaza el firmware falsificado o falsificado. El cifrado en general no está diseñado para hacer eso, y este cifrado en particular no lo hace. Si lo que desea es integridad y autenticidad, utilice la firma y no el cifrado, como apunta @ P4cK3tHuNt3R.

EDITAR: específicamente para la autenticación, puede utilizar la firma digital

openssl dgst -$hash -sign privatekeyfile >sigfile 
# combine the pieces for transmission then separate and 
openssl dgst -$hash -verify publickeyfile -signature sigfile

o use el formato CMS que combina y separa los datos por usted

openssl cms -sign -signer certfile [-inkey keyfile_if_not_in_certfile] -outform der
openssl cms -verify -inform der [-CAfile/CApath unless your root or selfsigned is in default truststore]
# assumes the transfer process handles binary, as most do nowadays;
# if not use -outform and -inform PEM, or default SMIME with -text 
# to add/strip dummy headers presuming your data isn't proper MIME

o varios MAC posibles, pero desde la línea de comandos HMAC es más fácil

openssl dgst -$hash -hmac keystring 
# at each and and compare
# note you can't easily use an arbitrary (binary) key here
# but HMAC construction inherently distills up to one hash input block
# worth of key so just use about 128 bits of entropy in hex or base64

openssl admite una variedad de hashes, pero a menos que necesite considerar otros factores, usaría sha256 o sha512, este último especialmente en máquinas de 64 bits. Los hash ahora oficialmente rotos o en peligro para la firma general (MD5, SHA1) serían realmente seguros en su aplicación su , pero eso puede ser complicado y consumir mucho tiempo para justificar a las personas, así que evite el problema.

Si realmente desea la autenticación y de encriptación, aunque como antes no creo que la necesite, los modos de encriptación autenticados GCM y CCM (que hacen las dos cosas a la vez) están disponibles en openssl biblioteca pero no (¿actualmente?) en la línea de comandos, así que lo más fácil es simplemente cifrar y luego autenticar con cualquiera de los anteriores. La clave (como si fuera) es encriptar luego autenticar y, a la inversa, verificar luego descifrar; esto bloquea la maleabilidad y el oráculo que se aplican al cifrado no protegido CBC (y a la mayoría de los demás).

    
respondido por el dave_thompson_085 18.06.2016 - 16:27
fuente
1

Como entendí el problema, está intentando proteger el archivo de firmware a través de la web cuando se debe actualizar la placa (Actualización de firmware), corríjame si me equivoco. Por qué está mezclando la criptografía simétrica y asimétrica por completo, incluso puede lograr su objetivo utilizando solo la criptografía asimétrica. Como mencionó, está generando los pares de claves pública y privada, así que use su clave pública para cifrar el archivo y luego descifrelo a bordo con la clave privada. También reducirá el tiempo de cálculo. El principal problema será cómo almacenar la clave privada a bordo. Aquí debe crear un enfoque diferente, para que nadie conozca la clave privada después de revertir, etc., su hardware.

Elija su opción 1 pero sin clave simétrica para el cifrado y descifrado de firmware. La firma de firma de firmware que ha mencionado en la segunda opción es incorrecta. Por favor siga este enlace para conocer el proceso de firma. Firma digital

    
respondido por el P4cK3tHuNt3R 17.06.2016 - 18:06
fuente

Lea otras preguntas en las etiquetas