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

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).

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