Gestione e controllo del file del seme in un PRNG crittografico
Abbiamo potuto constatare, nel corso degli articoli precedenti, che un PRNG si comporta come un catalizzatore di entropia ed è in grado di produrre dati casuali dopo la prima ristrutturazione del seme, stante che, ad un eventuale riavvio della macchina, è necessario attendere che le sorgenti di casualità producano un sufficiente numero di eventi indispensabili al primo rinnovo del seme medesimo, così da poter contare, effettivamente, su dei dati casuali: subentra, durante questo ciclo, una condizione che non è assolutamente in grado di garantire imprevedibilità ad un malintenzionato.
Per ovviare a tale problema è necessario ricorrere ad un file del seme ricco di entropia ed a totale carico del PRNG, questi, successivamente al riavvio, leggerà il contenuto del file in oggetto utilizzando le fonti entropiche per evolversi in uno stato che possa offuscare qualsiasi tentativo di definizione. Espletata l'operazione descritta il file del seme dovrà essere scritto ex novo!
Il file del seme è generato ricorrendo ad una funzione che produrrà 64 byte di dati casuali da scrivere all'interno del file medesimo. Il numero di byte in oggetto si presta perfettamente per la risoluzione del problema prospettato, quindi è da considerare come approccio ideale in questo tipo di operazioni.
Aggiornare il file del seme
Il file del seme verrà inglobato all'interno di una funzione che dovrà soddisfare le seguenti incombenze:
- Lettura del file
- Verifica della lunghezza
- Rinnovo del file
- Riscrittura del file con nuovi dati casuali
È di estrema importanza fare in modo che la funzione non utilizzi, per alcun motivo, il PRNG, nel periodo che intercorre tra il rinnovo del seme e la scrittura dei nuovi dati nel file, questo perché, dopo un riavvio, il file in oggetto viene letto dalla funzione e i dati saranno impiegati appunto per il rinnovo. Potrebbe verificarsi, in questo frangente, una richiesta fraudolenta di dati casuali anticipatamente all'aggiornamento del file del seme: non appena tale richiesta è soddisfatta, un malintenzionato potrebbe riavviare il sistema e quindi far sì che vengano letti i medesimi dati del file del seme indispensabili al rinnovo del generatore.
Il verificarsi, a questo punto, di una richiesta legittima antecedente la scrittura del file del seme, produrrebbe gli stessi, identici, dati casuali che l'attaccante ha in precedenza acquisito, con tutte le conseguenze che ciò andrebbe a determinare, compresa la generazione di chiavi crittografiche associate agli output del generatore.
Il file del seme durante il riavvio della macchina
Una volta completata l'operazione di riavvio, il PRNG non disporrà di fonti entropiche da utilizzare nella produzione dei dati casuali, è questo il motivo della creazione di un file del seme, pertanto questi dovrà essere letto ed aggiornato in ogni fase di inizializzazione. Durante il ciclo di produttività, verrà incamerata dal sistema l'entropia offerta dalle varie fonti per essere successivamente introdotta nel file del seme.
In virtù di quanto affermato pare ragionevole riscrivere il file in anticipo sullo spegnimento del computer: ponderato che taluni apparati non avranno uno spegnimento regolare, il PRNG dovrebbe, tra l'altro, riscrivere il file ad intermezzi regolari. È buona prassi dunque garantire un adeguamento intervallato del file del seme dopo ogni appagamento entropico, quindi ad ogni spegnimento e con delle porzioni di tempo da adeguare alla propria piattaforma.
Procedure di cautela su file system
La procedura per una corretta implementazione del rinnovo legato al file del seme risulta sempre assai gravosa, infatti non ci si può permettere neppure una ripetizione dello stato del PRNG: nel caso specifico verrà utilizzato il file system per memorizzare al suo interno il file del seme, seppure questa strategia presenta ulteriori problemi dovuti al fatto che non sempre questa tipologia di file è progettata onde evitare possibili reiterazioni del medesimo stato del PGRN.
La prima considerazione da fare seguendo la strategia descritta è relativa alla copia completa del file system, infatti questa, al riavvio della macchina, sarà letta dal PRNG che effettuerà il rinnovo basandosi sui dati presenti nella copia medesima. Successivamente a questo, un eventuale ripristino del file system nella sua interezza, dopo il riavvio, comporterà, da parte del PRNG, l'acquisizione del medesimo seme. Ciò significa che, finché l'accumulatore non incamera entropia a sufficienza, il PRNG produrrà, nei due riavvi successivi, il medesimo output ed un malintenzionato potrebbe a quel punto acquisire i dati casuali che l'utente legittimo ha ottenuto dal PRNG.
Attualmente non si conoscono efficaci difese da contrapporre a questo tipo di assalto, infatti, se la strategia di backup del file system, ingloba al proprio interno, nella sua interezza, i parametri permanenti del sistema, è praticamente impossibile evitare che venga reiterato lo stato interno del PRNG. Una ipotetica soluzione potrebbe essere un hash del file del seme legato all'orario corrente, sempre che il malintenzionato non abbia a reimpostare il timer di sistema.
Identica soluzione potrebbe essere applicata se la strategia di backup garantisse l'impostazione di un contatore degli adeguamenti effettuati, infatti, nello specifico caso, potrebbero essere calcolati l'hash del file del seme e del contatore. La risoluzione di questo problema rimane comunque legata alla piattaforma in utilizzo, pertanto può essere solamente di natura contestuale ed andrà agita man mano che si presentano i casi.
Problema dell'atomicità negli adeguamenti
Esiste un altro problema che è legato all'atomicità degli aggiornamenti relativi al file system: buona parte dei sistemi, quando viene scritto un file del seme, aggiorna semplicemente alcuni buffer di memoria omettendo la scrittura dei dati sul disco se non in tempi successivi. Dovendo forzare, se ciò fosse effettivamente possibile, il sistema operativo ad eseguire la scrittura in analisi, buona parte delle unità disco verrebbero impegnate a bufferizzare i dati: rimarrebbe chiaramente ignoto il tempo impiegato per il trasbordo nei supporti magnetici.
Ogni rinnovo del file del seme esige l'aggiornamento prima che venga espletata qualsiasi richiesta, da parte dell'utente, di dati casuali ed essere pertanto sicuri che i dati medesimi vengano modificati nel supporto magnetico. Molti file system gestiscono disgiuntamente i dati e l'amministrazione dei medesimi, pertanto la riscrittura del file del seme potrebbe temporaneamente rendere inservibile la sua gestione all'interno del sistema. Ciò può essere dovuto anche ad altre cause, come la cessazione inaspettata della tensione di rete che produrrebbe un file seriamente danneggiato o completamente corrotto.
Esistono inoltre dei file system che dispongono di un "giornale" alfine di risolvere i problemi sopra illustrati, ricorrendo ad una tecnica in origine retaggio dei database aventi grandi dimensioni. Il giornale genera un elenco in sequenza di tutti gli aggiornamenti trascritti all'interno del file system, garantendo, se utilizzato nel giusto modo, la coerenza degli aggiornamenti medesimi.
È questo il motivo per cui un file system con a supporto il giornale è da considerare più affidabile, nonostante, anche in questo caso, non sia affatto garantita la conoscenza del tempo impiegato per la trascrizione degli aggiornamenti sui supporti di memorizzazione permanente.
Purtroppo, se il sistema operativo e l'hardware sul quale si opera non sono in grado di supportare completamente gli aggiornamenti atomici, sarà molto difficile trovare la soluzione ideale per il file del seme, ed anche in questo caso, i possibili e futuri adattamenti, sono strettamente connessi alla piattaforma in utilizzo.
Mariano Ortu vi saluta dalla terra dei nuraghi!
MegaLab.it rispetta la tua privacy. Per esercitare i tuoi diritti scrivi a: privacy@megalab.it .
Copyright 2008 MegaLab.it - Tutti i diritti sono riservati