Crypter pour une protection maximale

Par exemple, un programme de traitement de commande doit pouvoir extraire un numéro de carte de crédit associé à un article en retard, pour différer le paiement jusqu’à la livraison. Bien sûr, le programme a besoin du numéro complet et pas seulement des quatre derniers chiffres, mais vous voulez que ce nombre ne puisse être extrait que pour des opérations autorisées bien précises, comme débiter ou facturer au moment de la livraison.

Les primitives de cryptage intégrées de DB2 permettent cela. Mais vous devrez soigner le cryptage pour ne laisser aucune brèche à d’éventuelles attaques. L’ IBM i a un ensemble complet de fonctions de cryptage intégrées dans l’OS sous forme d’API, et ces fonctions sont accessibles depuis SQL via ENCRYPT et DECRYPT. Elles sont simples à utiliser, mais attention à la sécurité ! Par exemple, pour crypter une colonne lors de l’insertion d’une ligne, il suffit de passer deux arguments à ENCRYPT():

INSERT INTO Orders VALUES(…,ENCRYPT(PayMethod, ‘r0zeBud’);

Ce faisant, le numéro de carte de crédit dans PayMethod est crypté à l’aide de la clé « r0zeBud » ; les données cryptées sont écrites dans la table au lieu du numéro de carte de crédit en clair. Cela semble simple mais il y a quelques pièges. Premièrement, les données cryptées sont en général plus longues que l’entrée non cryptée, et donc la colonne ciblée doit pouvoir recevoir la valeur maximale résultante. La formule permettant de calculer la longueur de colonnes n’est pas complexe, mais elle comporte des cas spéciaux. Reportez-vous au Redbook d’IBM IBM System i Security: Protecting i5/OS Data with Encryption, chapitre 10, pour des détails complets.

Deuxièmement, il est fortement déconseillé de stocker des clefs de cryptage sous forme de chaînes littérales dans des programmes. Il vaut bien mieux les stocker hors des programmes et des bases de données, peut-être dans un objet zone de données IBM i, accessible à des programmes, mais hors de portée d’un SQL malveillant. Vous pourriez protéger cet objet par la sécurité de ressources native. Vous pourriez ajouter une autre couche de protection en cryptant toutes les clés de cryptage stockées à l’aide d’une clef maîtresse : l’IBM i prend cela en charge et vous trouverez des détails dans le Redbook mentionné ci-dessus.

Dès lors que votre programme a extrait une clé de cryptage du stockage externe, il peut en faire une clé par défaut pour éviter de la passer sur chaque instruction SQL. L’instruction SET ENCRYPTION PASSWORD accomplit ceci :

SET ENCRYPTION PASSWORD = ‘encryption-key’;

Notons au passage que le processus de cryptage SQL possède un attribut de cryptage supplémentaire appelé indice (hint). Un indice est une chaîne arbitraire qui peut être extraite avec un champ crypté pour rappeler à un utilisateur étourdi le mot de passe réel. En principe, vous n’utiliserez pas les indices pour le cryptage SQL programmatique. Il est plutôt destiné aux dialogues ID/mot de passe utilisateur, comme pense-bête en cas d’oubli du mot de passe. Nous ne développerons pas davantage les indices ici.

Dès que vous aurez défini un mot de passe par défaut, toutes les opérations ENCRYPT et DECRYPT suivantes l’utiliseront comme clé de cryptage/décryptage.

Cela nous amène au décryptage. On s’en doute, la fonction DECRYPT est pratiquement l’inverse de ENCRYPT, à cela près que l’opération comporte quatre fonctions séparées : DECRYPT_CHAR, DECRYPT_BIT, DECRYPT_BINARY, et DECRYPT_DB. La fonction la plus courante est DECRYPT_CHAR, qui renvoie des valeurs non cryptées sous la forme d’une chaîne de caractères à un seul octet. DECRYPT_DB fait la même chose, mais utilise des caractères à deux octets, plus pratiques pour des données localisées codées avec des jeux de caractères alternés. Les fonctions DECRYPT_BINARY et DECRYPT_BIT renvoient des valeurs binaires utiles pour certaines applications spécialisées. Vous n’en aurez probablement jamais besoin.

Comme avec ENCRYPT, vous passez une ou deux valeurs à DECRYPT_CHAR et ses semblables : un nom de colonne contenant des données cryptées est la clé de décryptage ; ou, si vous avez utilisé SET ENCRYPTION PASSWORD, juste le nom de colonne :

SET ENCRYPTION PASSWORD = ‘decryption-key’;
SELECT DECRYPT_CHAR(PayMethod) FROM Orders;

Comme le cryptage SQL utilise toujours des clés symétriques, la clé de décryptage doit être de même valeur que celle utilisée auparavant avec ENCRYPT.

Si vos anciennes applications utilisent l’accès base de données natif IBM i plutôt que SQL, vous pouvez leur offrir automatiquement le cryptage/décryptage par le biais des déclencheurs et des vues SQL. Pour cela, vous définissez des déclencheurs Before Insert et Before Update pour crypter des colonnes lors de l’écriture des données, et des vues qui invoquent DECRYPT_CHAR() selon les besoins pour décrypter les colonnes. Vous pouvez accéder aux vues comme des fichiers logiques ordinaires dans des programmes IBM i HLL, ce qui vous dispense de modifier ou même de recompiler des programmes natifs pour tenir compte des données cryptées.

ENCRYPT et DECRYPT fournissent les outils de base pour crypter des colonnes SQL, mais vous pouvez construire par-dessus pour créer des contrôles d’accès rigoureux. Ainsi, vous pourriez utiliser une clé de cryptage unique pour chaque ligne d’une table, afin qu’une clé compromise n’expose que le contenu de cette ligne plutôt que toute la table.