La recette du cryptage

connexion, par l’instruction Set Encryption Password. L’instruction est une bonne méthode quand le même mot de passe doit être partagé sur des lignes dans une table ou sur des tables différentes.
Le mot de passe de cryptage est une chaîne de caractères dont la longueur doit être comprise entre 6 et 127 octets et dont la valeur est sensible à la casse (majuscules/minuscules). Pour aider les administrateurs et les programmeurs à mémoriser la valeur du mot de passe, l’instruction Set Encryption Password permet de stocker un indice facultatif (de 32 octets maximum) avec la valeur de données cryptée. L’exemple suivant montre comment fournir à DB2 la clé de cryptage et un indice :
CREATE TABLE emp ( SocialSecurity
VARCHAR FOR BIT DATA(56),
name VARCHAR(30)
SET ENCRYPTION PASSWORD = ‘atlantic’ WITH HINT=’ocean’
INSERT INTO emp VALUES( ENCRYPT(‘123456789’), ‘JENNA’)
SELECT GETHINT( SocialSecurity) FROM emp

L’instruction Set Encryption Password spécifie ‘atlantic’ comme valeur de clé de cryptage et ‘ocean’ comme valeur d’indice. Quand l’instruction Insert cryptera le numéro de sécurité sociale de l’employé, DB2 UDB stockera aussi la valeur de l’indice en même temps que la valeur cryptée dans cette colonne. Si un administrateur oublie la clé de cryptage, il pourra utiliser la fonction DB2 GetHint pour extraire la valeur d’indice ‘ocean’ qui lui rappellera que la clé de cryptage comporte un nom d’océan. La clé de cryptage spécifiée sur l’instruction Set Encryption Password est active jusqu’à ce que le job ou le groupe d’activation se termine.
On peut aussi faire varier le mot de passe de cryptage sur différentes lignes d’une table, en exécutant plusieurs fois l’instruction Set Password ou en spécifiant la valeur de la chaîne du mot de passe sur la fonction DB2 Encrypt. La fonction Encrypt permet trois paramètres d’entrée, mais le seul obligatoire est la chaîne de données d’entrée. Les paramètres facultatifs sont le mot de passe et l’indice. Voici un exemple d’exécution du même cryptage que dans l’exemple précédent :
INSERT INTO emp VALUES( ENCRYPT(‘123456789’),
‘atlantic’,’ocean’, ‘JENNA’)

Les deux derniers exemples démontrent que DB2 UDB permet aussi un nom synonyme de ENCRYPT parce que le nom de fonction officiel est en réalité ENCRYPT_RC2. RC2 est utilisé dans le nom de la fonction pour noter qu’un chiffre bloc RC2 avec un algorithme de cryptage de remplissage est utilisé pendant l’opération de cryptage. La fonction Encrypt obtient une clé secrète de 128 bits à partir de mots de passe, en utilisant un message digest MD5.
A l’évidence, on serait mal inspiré de coder en dur le mot de passe de cryptage et l’indice dans le code source de l’application. Il est plus judicieux de fournir ces valeurs via des variables d’hôtes ou des marqueurs de paramètres, afin que le mot de passe de cryptage soit moins visible aux yeux de celui qui scruterait le code source de l’application :
SET ENCRYPTION PASSWORD= :hostvar1 WITH HINT=:hostvar2
INSERT INTO emp VALUES( ENCRYPT(‘123456789’,?,?), ‘JENNA’)

Si l’application gère le cryptage et le décryptage des données, on peut sécuriser davantage la valeur du mot de passe en la stockant dans un objet liste de validation puis en l’extrayant le moment venu. Un objet liste de validation est préférable à d’autres types d’objets comme des espaces utilisateur ou des zones de données, parce qu’un objet liste de validation permet de crypter une portion de l’entrée de liste. Cela permet de stocker en toute sécurité le mot de passe de cryptage, en mode crypté.
Dans certains cas, il est utile de créer des index sur des données cryptées. Les correspondances exactes et les jointures des données cryptées utiliseront les index que vous aurez créés. Comme les données cryptées sont essentiellement des données binaires, le contrôle d’intervalle des données cryptées exigerait le balayage de tables et il faut donc l’éviter autant que possible.
Lorsque les recherches s’appliquent à une colonne cryptée, il faut utiliser les fonctions de cryptage en s’efforçant de réduire le nombre de valeurs qui sont décryptées dans la recherche. Ainsi, le meilleur moyen de recherche d’un utilisateur par son numéro de sécurité sociale consiste à utiliser la requête suivante, parce qu’elle évite de décrypter chaque numéro de sécurité sociale présent dans la table :
SELECT name FROM emp WHERE socialSecurity= ENCRYPT(‘111222333’);