Suggerimento su crittografia asimmetrica (crittografia ibrida) per file di grandi dimensioni

Non una risposta, ma hai chiesto suggerimenti e questo sarebbe molto per i commenti (SX).

(0) openssl pkcs8 -topk8 ... -v2 aes-128-cbc -nocrypt è fuorviante al meglio se non è sbagliato. Se il file di output non è crittografato, non importa quale algoritmo non viene utilizzato per crittografarlo.

(1) openssl enc -pass file: (o -kfile ) legge la prima riga del file come string e la usa come password (non chiave) con un PBKDF debole. Hai byte casuali per 'password', quindi il PBKDF debole è solo sciocco, ma c'è una probabilità del 12% che uno dei byte casuali sia NL o null e che la chiave abbia un'entropia ridotta e circa il 6% di probabilità che lo farà avere abbastanza bassa entropia da rompere. Utilizza il valore rand -hex come chiave con -K maiuscolo; oppure usa rand -hex o converti in base64 (ognuno dei quali dà tutto-alfanumerico) e lascia che il PBKDF (banalmente) lo distillhi.

(2) CBC non è autenticato e un po 'malleabile (anche se non è così male come le modalità di flusso) e non si aggiunge l'autenticazione. Se un utente malintenzionato vuole che il tuo dispositivo accetti un file modificato , probabilmente lo può dopo una buona quantità di lavoro, anche se i dettagli dipendono dai tuoi file e dai tuoi dispositivi.

(3) CBC richiede riempimento e openssl enc utilizza PKCS # 5 e non si autentica; se il tuo dispositivo è osservabile, questo probabilmente fornisce un oracolo di riempimento. Se un utente malintenzionato può fornire file creati e rilevare se il tuo dispositivo decifra o meno correttamente, può rapidamente interrompere la crittografia.

(4) Ma perché stai crittografando comunque? Questo firmware è segreto? La maggior parte del firmware non lo è, e nella maggior parte delle applicazioni in cui il firmware è scaricato, l'importante è integrity e autenticità , cioè caricare solo il firmware autorizzato mentre si rifiuta il firmware manomesso o contraffatto. La crittografia in generale non è progettata per farlo, e questa crittografia in particolare non lo fa. Se quello che vuoi è integrità e autenticità, usa la firma non la crittografia, come indicato da @ P4cK3tHuNt3R.

EDIT: in particolare per l'autenticazione è possibile utilizzare la firma digitale

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

o usa il formato CMS che combina e separa i dati per te

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 diversi possibili MAC, ma dalla linea di comando HMAC è più semplice

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 supporta una varietà di hash, ma a meno che non sia necessario considerare altri fattori, utilizzerei sha256 o sha512, quest'ultimo soprattutto su macchine a 64 bit. Gli hash ora ufficialmente interrotti o in pericolo per la firma generale (MD5, SHA1) sarebbero effettivamente al sicuro nella tua applicazione, ma può essere complicato e scadente per giustificare le persone, quindi basta evitare il problema.

Se vuoi veramente l'autenticazione di e di crittografia, anche se non credo che ne hai bisogno, le modalità di crittografia autenticate GCM e CCM (che fanno entrambe le cose contemporaneamente) sono disponibili in openssl libreria ma non (attualmente?) in riga di comando, quindi è più semplice crittografare e quindi autenticarsi con uno qualsiasi dei precedenti. La chiave (per così dire) è criptare quindi autenticare e viceversa verificare quindi decrittografare; ciò blocca la malleabilità e l'oracolo che si applicano alla crittografia CBC non protetta (e molti altri).

Come ho capito il problema che stai cercando di proteggere il file del firmware sul web quando è necessario aggiornare la scheda (Aggiornamento firmware), correggimi se ho torto. Perché stai mescolando la crittografia simmetrica e asimmetrica del tutto, anche tu puoi raggiungere il tuo obiettivo usando solo la crittografia asimmetrica. Come hai detto, stai generando le coppie di chiavi pubbliche e private, quindi utilizza la tua chiave pubblica per crittografare il file e decrittalo a bordo utilizzando la chiave privata. Ridurrà anche il tempo di calcolo. Il problema principale sarà come memorizzare la chiave privata a bordo. Qui devi trovare un approccio diverso, in modo che nessuno possa conoscere la chiave privata dopo aver eseguito l'inversione del tuo hardware.

Quindi scegli l'opzione 1 ma senza chiave simmetrica per la crittografia e la decrittografia del firmware. La firma della firma del firmware che hai menzionato nell'opzione 2 è errata. Si prega di seguire questo link per conoscere il processo di firma Firma digitale