Crittografia AES su dispositivo incorporato: può essere sicuro?

10

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.

    
posta Moritz Beutel 08.02.2015 - 12:15
fonte

2 risposte

3

Non specifichi un caso d'uso per questo, quindi è difficile capire le limitazioni e se questo è "sicuro".

Non hai menzionato l'utilizzo di un HMAC, ma presumo che tu sia a conoscenza della necessità di uno sotto determinate applicazioni.

Si desidera utilizzare AES-256 su AES-128, ma non specificare il perché. AES-256 richiede 14 round, contro solo 10 per AES-128, quindi AES-128 è considerevolmente più veloce, il che può essere significativo nell'ambiente molto limitato con cui si ha a che fare (parole a 16 bit per esempio). AES-128 è già estremamente sicuro, e c'è poca o nessuna sicurezza aggiuntiva offerta da uno spazio chiavi più grande, specialmente se si utilizzano password digitate dall'utente che non hanno quasi mai un pieno di 128 bit di entropia.

IV non ha bisogno di essere imprevedibile (la IV deve essere nota comunque a qualsiasi attaccante). L'unica cosa importante di una flebo è che non viene riutilizzato. Personalmente userei un seme casuale che viene sottoposto a hashing ogni volta che un nuovo file viene crittografato, e i risultati salvano l'hash casuale. Il prossimo IV sarà sempre prevedibile, ma dato abbastanza entropia iniziale non verrà mai riutilizzato, anche a livello globale su tutti i dispositivi.

    
risposta data 16.03.2015 - 19:40
fonte
2

La sicurezza di questo schema dipende esattamente da ciò che l'aggressore è in grado di leggere. Ricorda che il dispositivo incorporato sta eseguendo la decrittografia, quindi ha chiaramente tutte le parti necessarie per farlo (dati crittografati, chiave e algoritmo)

  • Se l'attaccante ha qualche tipo di collegamento di debug al sistema (ad es. JTAG) - Game Over (immediatamente e senza sforzo). L'attaccante può solo leggere il contenuto decrittografato dalla RAM.

  • Se può leggere solo i tuoi file di dati e il tuo tasto AES è uno di loro - Game Over.

  • Se può leggere solo i tuoi file di dati e la tua chiave AES è incorporata nel codice in una memoria separata - Ok (forse).

  • Se può leggere sia i file di dati che la memoria del codice e il codice AES è memorizzato nel codice - Game Over. L'attaccante non ha nemmeno bisogno di decodificare la chiave, può solo eseguire il codice e lasciarlo scaricare in memoria il contenuto decrittografato. Trovare ambienti virtuali in grado di eseguire codice x86 è banale.

  • Se può leggere sia i file di dati che la memoria di codice, ma il codice estrae la chiave AES da una memoria sicura on-die progettata esplicitamente per la protezione della chiave a prova di manomissione - Dovrebbe essere ok. A meno che l'attaccante non possa far sì che il microcontrollore esegua codice modificato e copia i dati decrittografati dalla memoria del microcontrollore.

  • Se può leggere i file di dati e il tasto AES è memorizzato in una memoria sicura, ma quella memoria non è on-die - Non va bene. L'attaccante può rubare la chiave mentre viene trasmessa tra lo storage sicuro e il core del processore. Più difficile degli attacchi solo software, ma ancora insicuri.

Fondamentalmente, la protezione del codice e dei dati off-chip richiede un chip progettato con fusibili per bruciare l'interfaccia di debug, il codice memorizzato su chip con tutti gli accessi esterni negati da quegli stessi fusibili, dati crittografati e una chiave antimanomissione integrata Conservazione. È molto improbabile che un chip dell'era 80186 abbia queste caratteristiche (specialmente la seconda), sebbene sulla base delle dimensioni della memoria e della frequenza del clock, questo è un clone 80186 moderno che potrebbe.

    
risposta data 16.03.2015 - 20:02
fonte

Leggi altre domande sui tag