La differenza tra ‘encryption at rest’, ‘encryption in motion’ ed ‘encryption in process’. Il loro utilizzo a più livelli (layers) consente di garantire un generale livello di sicurezza più efficace e con un impatto pressoché nullo in termini di performance computazionali.
Nell’inevitabile transizione digitale delle Pubbliche amministrazioni e delle aziende il ricorso al cloud computing è la leva centrale per via dei suoi vantaggi, come la semplificazione e ottimizzazione della gestione delle risorse IT, la riduzione dei costi e l’abilitazione di nuove tecnologie.
Ma come avere nel cloud la sicurezza e la protezione dei dati, anche strategici e critici delle aziende e del Paese?
Tra le migliori soluzioni tecnologiche all’avanguardia disponibili sul mercato c’è la crittografia, in attesa “dell’algoritmo di crittografia nazionale”, annunciato il 7 settembre 2021 da Roberto Baldoni in risposta alla domanda di Cybersecurity Italia nel giorno della presentazione della Strategia Cloud Italia. “Ma non sarà una soluzione immediata”, ha aggiunto il dg dell’Agenzia per la Cybersicurezza Nazionale (ACN).
Ed anche in attesa della norma nazionale che regoli l’impiego della crittografia dei dati, ecco il confronto tra ‘encryption at rest’, ‘encryption in motion’ ed ‘encryption in process’.
I tre livelli di crittografia dei dati con i limiti dell’encryption at rest e dell’encryption in motion
Encryption at rest
I dati che si trovano su un qualunque tipo di sistema di storage, sono l’oggetto di questa tipologia di crittografia. Implementata spesso come un sistema di crittografia a chiave simmetrica, essa protegge i dati all’interno della loro destinazione finale perché si applica direttamente sullo storage. Dunque, anche in caso di smarrimento o furto dell’hardware (che di fatto funge da storage contenendo tutti i dati), senza avere la giusta chiave di crittografia non è possibile comprendere il suo reale contenuto. Come dice il nome “at rest” (a riposo), l’efficacia di questa soluzione è vincolata dalla condizione che il dato non si trovi in uno stato di elaborazione o transito. Se così fosse avremmo bisogno necessariamente di decifrare ogni cosa utilizzando la giusta chiave di crittografia e riportando il dato in chiaro ogni volta prima di effettuare ulteriori operazioni. Proteggere la chiave usata per cifrare/decifrare i dati diventa di vitale importanza. Decidere come gestire correttamente e in totale sicurezza la chiave, può determinare il successo o il fallimento dell’encryption at rest.
Encryption in motion
Una volta generati dei dati, questi solitamente, vengono trasferiti verso la destinazione dove potranno svolgere la funzione per cui sono stati creati. Raggiunta la loro meta, dovremo verificarne la loro integrità, nella speranza che niente sia andato storto e che il dato ottenuto dopo il trasferimento sia di fatto lo stesso inviato dalla sorgente. Il motivo per cui nasce la necessità di effettuare questa verifica è l’enorme quantità di incognite e pericoli che potrebbero celarsi all’interno del canale di comunicazione. A volte, il dato viene corrotto a causa di problemi strutturali nel canale fisico di trasferimento e in questo caso, nello scenario peggiore, il dato viene sostanzialmente distrutto. L’alterazione non è voluta ma è il risultato di un incidente e l’effetto sul dato è inequivocabile e ben visibile. Purtroppo, esiste anche il caso in cui si può verificare un’alterazione del dato, il cui effetto su di esso non è altrettanto visibile. Questo è il caso di un’alterazione volontaria e pianificata del dato in seguito ad una sua intercettazione. L’eventualità appena descritta, si verifica in presenza di un cosiddetto “Man-In-The Middle” (MITM). Se due end-point decidono di trasmettere i propri dati in chiaro si rendono vulnerabili all’attacco di un MITM, che intercetta i dati e li altera senza farsi notare da nessuno dei due endpoint.
Solitamente, il modo migliore per evitare questo scenario è l’applicazione di una soluzione di crittografia che cifra i dati in transito (encryption in motion) la quale può essere implementata in due modi distinti:
- crittografia simmetrica
- crittografia asimmetrica.
Nel primo caso i due endpoint concordano una chiave e la utilizzano per cifrare/decifrare i dati, ma in questo modo se il MITM riesce a intercettare la chiave, l’efficacia della soluzione viene completamente vanificata. Nel secondo caso, i due endpoint possiedono ciascuno un set di due chiavi diverse (chiave pubblica e privata correlate matematicamente). Con la chiave pubblica è possibile decifrare i dati, mentre con la chiave privata vengono cifrati e viceversa. Esistono molti algoritmi che implementano questa logica ed è assolutamente comune trovarli a supporto di svariati protocolli di rete. Spostare i dati non implica necessariamente l’utilizzo di due o più endpoint che si interfacciano con Internet, ma possiamo avere il caso in cui abbiamo l’esigenza di spostare i dati tra due o più nodi all’interno di un cluster. Anche in questo caso è certamente possibile applicare il concetto di Encryption in motion ma, l’efficacia di questa soluzione, potrebbe essere vanificata se gli endpoint coinvolti fossero compromessi a priori oppure, se il fornitore del canale di comunicazione decidesse di intercettare e cedere volontariamente i nostri dati a terzi.
L’Encryption in process
L’encryption at-rest e l’encryption in motion, anche se possiedono caratteristiche che li rendono approcci completamenti differenti, condividono la possibilità del loro impiego, in tutte quelle situazioni in cui si presenta la necessità di operare sul dato, riportando quest’ultimo sempre nella sua forma originale e dunque decifrarlo necessariamente. Una volta decifrato, il dato viene elaborato e indipendentemente dalla durata dell’elaborazione, risiederà infine all’interno della RAM. Per questo motivo, quando siamo in presenza di un un terminale compromesso è verosimile immaginare il caso in cui un hacker riesca ad effettuare con successo un “dump” della RAM attraverso un malware, recuperando così il dato originario in “chiaro”.
L’encryption in process, se implementata attraverso un algoritmo di crittografia omomorfica, permette di creare una funzione monomorfica che va a correlare il dato in chiaro con la sua controparte cifrata. In questo modo tutte le operazioni che prima potevano essere effettuate esclusivamente su dati in chiaro, sono eseguite direttamente su dati cifrati, con il vantaggio che le performance computazionali rimangono pressoché invariate. Seguendo la filosofia della Zero Trust Security, il sistema stesso sul quale sono elaborati i dati non è consapevole di cosa sta elaborando, ma l’elaborazione termina correttamente grazie alle proprietà dell’omomorfismo. In questo modo, anche in presenza di MITM (Men In The Middle) o di compromissione di un terminale per eseguire un “dump” della RAM, sarà impossibile qualunque esfiltrazione del dato in chiaro, proprio grazie alla presenza dell’encryption in process.
Conclusione: i vantaggi della crittografia omomorfica
In conclusione, la soluzione ideale sarebbe quella di creare uno stack di sicurezza a più livelli (layers): Encryption at rest, Encryption in motion ed Encryption in process, al fine di garantire un generale livello di sicurezza più efficace e con un impatto pressoché nullo in termini di performance computazionali.
Quindi, l’Encryption in process garantisce un ulteriore livello di sicurezza e protezione dei dati e si implementa grazie alla crittografia omomorfica. La crittografia omomorfica consente sia la crittografia dei dati e allo stesso tempo ne permette la loro elaborazione in forma criptata, senza dover condividere la chiave di decriptazione con le applicazioni.
Per essere più chiari, i dati presenti, anche se criptati, su una piattaforma cloud, non sono totalmente al sicuro, soprattutto se bisogna effettuare delle operazioni su di essi, poiché per elaborarli o manipolarli c’è bisogno di decifrarli.
La crittografia omomorfica, invece, può risolvere questo problema e fare in modo che le informazioni memorizzate nel cloud non debbano mai essere decifrate e che quindi siano sempre al sicuro.
