Pretty Good Privacy, purement et simplement, P.2

La figure 1 montre notre clé telle qu’elle apparaît dans le WinPT Key Manager. Bien que l’on ne voit qu’un élément dans la liste, l’outil a en réalité créé deux clés : une en utilisant l’algorithme DSA et une en utilisant l’algorithme ElGamal. La clé DSA est utilisée pour la signature et l’authentification, et la clé ElGamal pour le cryptage. La clé ElGamal fournit la paire clé publique/clé privée utilisée pour la composante de cryptographie par clé asymétrique de PGP. A noter que notre clé est accompagnée d’un identificateur, ou key ID.

Chaque clé dans notre fichier de clés a un identificateur unique. GnuPG for Windows stocke les données de clés qui nous intéressent dans deux fichiers : pubring.gpg contient les clés publiques et secring.gpg contient notre clé privée. Bien que nous utilisions un produit de type Windows pour gérer nos fichiers de clés, nous pouvons garder les fichiers de clés sur notre System i et y accéder à distance via un lecteur associé ou transférer périodiquement les fichiers de clés d’une machine Windows sur notre System i.

En utilisant WinPT, vous pouvez modifier l’emplacement des fichiers de clés en changeant les paramètres sous Edit|Preferences| GPG Preferences. Pour les besoins de cet exemple, j’ai placé les fichiers de clés dans un répertoire appelé « /keyfiles » sur mon System i. Pour avoir quelque chose d’intéressant à crypter, copions un fichier de données dans un fichier stream et traduisons- le en format CSV. Sur mon serveur System i, j’ai une table nommée CUSTMAST dans une bibliothèque appelée EXAMPLES. Ici, nous la copions dans un fichier stream appelé custmast.csv dans le répertoire /datafiles :

CPYTOIMPF
FROMFILE(EXAMPLES/CUSTMAST)
TOSTMF(‘/datafiles/custmast.csv’)
STMFCODPAG(*PCASCII) RCDDLM(*CRLF)

La figure 2 montre les paramètres de la commande ENCRYPT que nous utilisons pour crypter notre fichier. Nous spécifions le fichier que nous voulons crypter et l’endroit où nous voulons placer la sortie cryptée. L’utilitaire ajoute un .asc au nom du fichier si nous demandons ASCII armor ou un .bpg au fichier s’il est binaire.

Par conséquent, nous pouvons spécifier sans risque que le répertoire cible est le même que celui qui contient le fichier non crypté. Nous spécifions que nous voulons à la fois l’intégrité ASCII armor et hash. Nous indiquons aussi l’emplacement et le nom du fichier contenant nos clés publiques et le key ID de la clé que nous voulons utiliser (préfacée avec « 0x » pour indiquer que la valeur est en hexadécimal).

Une fois crypté, notre fichier est codé en ASCII, de sorte que nous pouvons examiner son contenu avec l’outil Edit File ou Windows Notepad. La figure 3 montre un exemple du contenu crypté du fichier. Pour amener ce fichier dans l’autre direction, nous utilisons la commande DECRYPT. Comme on le voit dans la figure 4, les paramètres sont similaires à la commande ENCRYPT. Nous spécifions le fichier que nous voulons décrypter et où il doit aller.

Attention : la commande DECRYPT débarrasse le fichier de son extension .asc ou .bpg et, s’il existe un fichier de même nom, elle l’écrasera sans crier gare. Nous indiquons l’emplacement et le nom du fichier contenant notre clé privée et la phrase de passe associée à celle-ci. Soyez très prudents : quiconque possède votre fichier de clés privées et votre phrase de passe peut mettre en péril les données cryptées que vous recevez.

Faites donc le nécessaire pour sécuriser vos fichiers de clés, faire expirer périodiquement les clés, et changer les phrases de passe de manière régulière et aussi quand des collaborateurs importants quittent la société. Il n’est pas bon de coder en dur une phrase de passe en texte clair dans un programme CL. Vous pourriez même vous exposer en invoquant la commande DECRYPT dans une session telnet non cryptée (non SSL).