Crittografazione e DB2 for i

Encryption

il problema era questo: 

• Memorizzare credenziali in tabella e utilizzarle all'interno di programmi RPGLE per accedere via FTP ad altri sistemi
• Le credenziali non devono essere visibili agli utenti, QSECOFR compreso

Cos'è la Crittografia

La parola crittografia deriva dall'unione di due parole greche: κρυπτóς (kryptós) che significa "nascosto", e γραφία (graphía) che significa "scrittura". La crittografia tratta delle "scritture nascoste", ovvero dei metodi per rendere un messaggio "offuscato" in modo da non essere comprensibile a persone non autorizzate a leggerlo. Un tale messaggio si chiama comunemente crittogramma.(Wiki)

Qualche parola chiave

• HASH - E' un algoritmo che fornisce una stringa di lunghezza fissa a fronte di una stringa a lunghezza variabile; si tratta di un algoritmo monodirezionale tale per cui a fronte di una stringa si ottiene (ragionevolmente) una ed una sola stringa di output. Gli algoritmi più noti sono MD5, SHA1, SHA2.

• Crittografia - Algoritmo che permette di rendere incomprensibile una stringa utilizzando un'altra stringa (chiave); nel caso dells Cr.Simmetrica la chiave è la stessa sia per criptare che per decretare, nel caso della Crittografia asimmetrica si utilizzano due chiavi (Chiave pubblica e chiave privata).

E sul DB2?

La crittografazione su db2 è supportata dalla V5R3 e permette la crittografazione dei dati per colonna; la chiave di crittografazione puo' essere differente da riga a riga e da colonna e colonna. E' supportata solo da interfaccia SQL (un altro ottimo motivo per abbandonare le DDS); qualora si desideri intervenire su applicazioni esistenti è possibile, con l'ausilio di TriggerSQL e di Viste, modificare l'applicazione per utilizzare appieno le funzionalità di Crypt/DeCrypt.


Gli algoritmi utilizzati

• V5R3: RC2 la chiave di Crittografazione viene generata da un hash della password con algoritmo MD5 (Fino alla V5R3 è prerequisito l'installazione di IBM Cryptographic Access Provider 128-bit (5722-AC3); dalla V5R4 il supporto è incorporato nell'OS)
• V5R4: oltre a RC2 viene implementato l'algoritmo 3DES: la chiave di Crittografazione viene generata da un hash della password con algoritmo SHA1
• 6.1: viene implementato l'algoritmo AES
• 7.1: nessuna nuova implementazione, viene però rilasciato il supporto alle procedure di Colonna (FIELDPROC) che permettono di manipolare le informazioni prima di inserirle in tabella (e prima di leggerle)

Tipi di dato ammessi
Per usare le funzioni di Encrypt/DeCrypt occorre che la colonna sia di tipo

BINARY
VARBINARY
CHAR FOR BIT DATA
VARCHAR FOR BIT DATA
BLOB

Se invece volessimo crearlo con le DDS occorre impostare il tipo dato H (esadecimale) che forza il CCSID a 65535

A seconda dell'utilizzo dell'HINT o del uno non utilizzo il dimensionameno del campo segue questa semplice regola (Tabella)

Le funzioni del DB2

Si tratta (ad esclusione dell'implementazione delle FIELDPROC) di algoritmi bidirezionali, con una sola chiave per criptare e decrittare: crittografazione SIMMETRICA.

a fronte delle funzioni di Crypt è disponibile la funzione di decrypt:

Si utilizza l'appropriata funzione dipendentemente dal tipo di dato della tabella: CHAR FOR BIT DATA, VARCHAR FOR BIT DATA, BINARY, VARBINARY, BLOB
Il parametro integer permette di scegliere il CCSID nel quale esprimere il risultato della funzione, obbligatorio con CHAR e DB

Una prova...

creo una tabella


inserisco una riga specificando la password di crypt nell'insert


imposto la Password come variabile SQL e inserisco la riga omettendo la password


leggo...




ora le stesse operazione, creando pero' una tabella che prevede l'HINT

La tabella deve avere una colonna adeguata a contenere dati criptati
Posso inserire la password di crypt/decrypt negli statement di Insert/select oppure impostare la variabile SQL encryption password
utilizzo la funzione ENCRYPT_RC2 per crittografare e la DECRYPT_CHAR per decriptare.








Non è tutto rose e viole: le prestazioni in scrittura non sono eccelse, ma, considerando che si tratta di tabelle utilizzate per la maggior parte delle volle in lettura non mi preoccuperei più di tanto


La mia nuova tabella




CREATE TABLE MYMY.PWSSO00F (                         
  PSPKY INTEGER GENERATED ALWAYS AS IDENTITY (         
  START WITH 1 INCREMENT BY 1                          
  NO MINVALUE NO MAXVALUE                              
  NO CYCLE NO ORDER                                    
  CACHE 20 ),                                          
  PSATT CHAR(1) CCSID 280 NOT NULL DEFAULT '' ,        
  PSIDE CHAR(10) CCSID 280 NOT NULL DEFAULT '',        
  PSSYS CHAR(50) CCSID 280 NOT NULL DEFAULT '',        
  PSUSR CHAR(50) CCSID 280 NOT NULL DEFAULT '' ,       
  PSPWD VARCHAR(96) FOR BIT DATA,                      
  PTIMI TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP , 
  PUSEI CHAR(10) CCSID 280 NOT NULL DEFAULT ''
  CONSTRAINT MYMY.PWSSO00F_PK PRIMARY KEY( PSPKY ) ,
  CONSTRAINT MYMY.PWSSO00F_UK UNIQUE     ( PSIDE ) )        


exec sql                                           
  SELECT 
         psusr,                                    
         decrypt_char(pspwd, 'a$rc0bal3n0!123'),     
         pssys                                     
         into :$RmtUser ,                          
               :$RmtPass ,                          
               :$RmtHost                            
   FROM PWSSO00F a                                 
   where psIde='challenge'
   optimize for 1 row;








Come accennato all'inizio del post esiste la possibilità di utilizzare un triggerSQL per memorizzare i dati; in questo modo da qualsiasi programma (anche RPG quindi) la scrittura del record viene modificata criptando il dato. Va anche detto che una soluzione di questo genere ci espone ad attacchi: il trigger SQL è derivabile quindi la password può' diventare visibile: si potrebbe introdurre nel trigger un FUNCTION che reperisca la password (anch'essa derivabile o comunque richiamabile, non vedo grandi soluzioni all'orizzonte)…