AES Advanced Encryption Standard in MYSQL e PHP per campi sensibili

Può risultare necessario crittografare campi definibili “sensibili” che risiedono nelle tabelle di un RDBMS MySQL. Nonostante abbia un costo computazionale non banale e può risultare sconveniente in termini di manipolazione, adottare questa tipologia di gestione dei dati può risultare necessario per prevenire dump illeciti.

Resta il fatto che adottare una crittografia dei dati sulle tabelle non è nell’indole dei DBMS poiché "scomodi", di difficile manipolazione, e sostanzialmente quest'ultimi non sono progettati per scopi simili. Proteggere il canale di comunicazione, avere un accurata gestione degli accessi (sia in termini di firewall che nel reparto IT) e dei logs restano fattori chiave per la sicurezza dei dati. Nel caso in cui si vogliano proteggere i dati di accesso è anche importante fattore la creazione di un authentication server scorporato e a sua volta massicciamente blindato.

Per garantire una gestione della base crittografica in maniera efficace è necessario che le funzioni di crypt e decrypt siano parallelamente disponibili sia lato server, nel caso in questione mediante Php, sia lato SQL. Prenderemo come riferimento il metodo crittografico AES-128-CBC disponibile sia su Php mediante le funzioni di openssl che nativamente su MySQL. (Versione di riferimento adoperata 5.7.33). 

/* SHOW DEFAULT block_encryption_mode for the sesssion */
SELECT @@SESSION.block_encryption_mode;

/* SET DEFAULT block_encryption_mode for the sesssion */
SET @@SESSION.block_encryption_mode = 'aes-128-cbc';

La scelta di una chiave a 128 bit dà un buon livello di sicurezza, al momento in cui scrivo a marzo 2022, è possibile aumentare la complessità della chiave con ovviamente costi superiori. La modalità scelta di default su MySQL è la CBC (Cipher Block Chaining), vi sono numerosissime trattazioni reperibili ovunque di cui non entro nel merito poiché ridondare, troppo, informazioni non arricchisce ma inquina! L'utilizzo di passphrase superiori alla lunghezza del vettore di inizializzazione forniranno due cyphertext differenti.

 Il vettore di inizializzazione, IV (initialization vector), è generato casualmente in prima istanza poi riutilizzato per ogni decriptazione. La scelta del numero dei vettori può avere granularità differente a seconda di come si voglia gestire la crittografia nel database. Ad esempio potremmo averne uno per ogni campo, uno per ogni tabella, uno per ogni database o uno per tutto il progetto.

IV è un blocco di bit a lunghezza fissa utilizzato per inizializzare lo stato di un cifrario a flusso, oppure di un cifrario a blocchi come nel nostro caso CBC. Bisogna tenere in considerazione che IV può essere noto ad un eventuale attaccante e che l’utilizzo dello stesso IV per più campi, tabelle e database può facilitare la crittoanalisi.

Si utilizza MySQL per la generazione del vettore (IV) e si converte in HEX per poterlo gestire e salvare nel progetto.

/* IV */

SELECT HEX(RANDOM_BYTES(16));

/*
IV = 4D1A146690E0CC8F168DA24DF0A201E7
*/

Su MySQL adotteremo le funzioni native di AES

SELECT HEX(AES_ENCRYPT('Ciao','passphrase',UNHEX('4D1A146690E0CC8F168DA24DF0A201E7')));

/* 732904A94861A7AE3AF74CD8DA76E475 */

SELECT CONVERT(AES_DECRYPT(UNHEX('732904A94861A7AE3AF74CD8DA76E475'),'passphrase',UNHEX('4D1A146690E0CC8F168DA24DF0A201E7'))USING utf8) AS `TEST`;

/* Ciao */

In PhP le due funzione per  crypt e decrypt che daranno i medesimi risultati.  

Avendo un doppio supporto php/mysql è possibile gestire in maniera decisamente più tollerabile la crittografia, prevedendo anche query di ordinamento, previo decrypt al volo anche se con un costo elevato. Trattandosi però di dati sensibili di tipo descrittivo spesso il loro ordinamento è necessario in operazioni di backend, report e una accurata progettazione relazionale ammette l’utilizzo di capi descrittivi per poche se non alcune operazioni di aggregazione complesse.