Ho intenzione di creare un programma di crittografia per un dispositivo incorporato con le seguenti caratteristiche:
- La CPU è compatibile Intel 80186 @ ~ 20 MHz
- 128 KB di RAM, di cui ho ~ 20 KB a disposizione per scopi di crittografia
- dimensione binaria dell'applicazione limitata a 128 KB, ma mi piacerebbe mantenere la parte di crittografia < 16 KB
- archiviazione persistente nella memoria Flash
Questi sono i requisiti:
- crittografare piccoli file di testo e bitmap < 32 KB
- Posso sempre decrittografare l'intero file in RAM, ad esempio, non ho bisogno dell'accesso casuale
- i file crittografati non sono "bloccati" dall'hardware, cioè possono essere trasferiti su un PC in qualsiasi momento, quindi voglio proteggermi da qualcuno che ruba il dispositivo e prova a decodificare i dati
- Non sono preoccupato per gli exploit del software, i keylogger e così via (presumo di non prendere mai in prestito il dispositivo a nessuno e tenerlo sotto il mio cuscino di notte, e suppongo anche che la NSA non irrompa in casa per cloroformio un exploit mirato)
Sono ben lungi dall'essere un esperto di crittografia, ma ho passato un po 'di tempo a leggere Wikipedia su AES, le modalità di cifratura a blocchi e gli algoritmi di derivazione chiave, e ho anche letto " Se stai digitando le lettere AES nel tuo codice, lo stai facendo male ". Tutto questo mi ha fatto dubitare di riuscire a dare dei limiti all'hardware e alla mia conoscenza superficiale del soggetto, ma ci proverò.
I seguenti passaggi spiegano cosa intendo fare:
- Ho intenzione di seguire la procedura di base delineata in questa risposta , ovvero: crittografia con AES in modalità CBC, derivazione chiave con PBKDF2, random salt, random IV.
- Poiché preferirei AES-256 invece di AES-128, userei PBKDF2 con SHA-512 in modo da poter ricavare una chiave di doppia lunghezza.
- Non esiste alcuna fonte affidabile di numeri casuali sul dispositivo incorporato, quindi il mio piano è di far generare all'utente la chiave casuale (k1) su un PC e trasferirla (probabilmente digitandola manualmente). Questo non dovrebbe essere un problema perché si verifica solo una volta, cioè io uso la stessa chiave (k1) per crittografare qualsiasi numero di file.
- Il gioco / saggio "Se stai digitando le lettere AES nel tuo codice, lo stai facendo male" indica i pericoli di un utente malintenzionato che ha il controllo sul processo di crittografia, cioè chi può fornire un testo in chiaro arbitrario e è crittografato, perché questo abilita tutti i tipi di attacchi da canale laterale come "error oracle". Ho ragione di presumere che questo non è un problema per me perché l'autore dell'attacco può solo vedere i miei file crittografati?
- La mia comprensione è che dovrei generare un IV casuale e sale per ogni singola crittografia in modo da evitare risultati identici per lo stesso testo in chiaro. Ma la IV e il sale devono essere numeri casuali strongmente crittografati? Il meglio che posso fare sarebbe un Mersenne Twister (o preferibilmente qualcosa di più efficiente) seminato con hash (concat (tempo, voltaggio della batteria)); ma questo è necessario? Conservo sia IV che sale in testo normale comunque, quindi devo solo assicurarmi che siano diversi ogni volta, non preoccuparti della loro prevedibilità.
- Ho intenzione di utilizzare questa implementazione o una delle implementazioni collegate qui , ovviamente dopo averle verificate con i vettori di test NIST. C'è qualcos'altro da verificare quando si sceglie un'implementazione?
Sarei grato per i commenti che mi dicevano quali parti sono sbagliate, non sicure o dovrebbero essere migliorate. Inoltre, se è disponibile un'implementazione AES-256 affidabile per Intel 80186, mi piacerebbe saperlo. E infine, se pensi che sia senza speranza, non esitare a dirmelo.