Quelques définitions

La cryptologie, étymologiquement la science du secret, ne peut être vraiment considérée comme une science que depuis peu de temps.

Cette science englobe la cryptographie (l'écriture secrète) et la cryptanalyse (l'analyse de cette dernière).

La cryptographie s'attache à protéger des messages (pour des raisons de confidentialité) en s'aidant de secrets ou clés.

     Elle rend un message inintelligible à autre que qui-de-droit.

Chiffrement (ou cryptage) : transformation à l'aide d'une "clé", d'un message en clair (dit texte clair) en un message incompréhensible (dit texte chiffré) pour celui qui ne dispose pas de la clé de déchiffrement (en anglais encryption key ou private key pour la cryptographie asymétrique) 

Exemple : chiffrement par décalage, ou le code de César C'est une méthode de chiffrement très simple utilisée par Jules César (d'où le nom),dans ses correspondances secrètes. Le texte chiffré s'obtient en remplaçant chaque lettre du texte clair original par une lettre à distance fixe, toujours du même côté, dans l'ordre de l'alphabet. Pour les dernières lettres (dans le cas d'un décalage à droite), on reprend au début. Ce qui prouve que le besoin sécurité est ancien. vous pouvez tester ici http://www.cryptage.org/outil-crypto-cesar.html La machine ENIGMA utilisait le même concept , mais avec un décalage qui variait. Il a été estimé que le conflit en Europe a été écourté d'au minimum deux ans grâce à la cryptanalyse des codes allemands par Alan Turing entre autres.

il existe différents algorithmes

Algorithmes de chiffrement faible (facilement déchiffrables)

ROT13 (rotation de 13 caractères, sans clé) 

Chiffre de César (voir ci-dessus) 

Chiffre de Vigenère (introduit la notion de clé)

Algorithmes de cryptographie symétrique (à clé secrète)

Les algorithmes de chiffrement symétrique se fondent sur une même clé pour chiffrer et déchiffrer un message.

L'un des problèmes de cette technique est que la clé, qui doit rester totalement confidentielle, doit être transmise au correspondant de façon sûre.
La mise en œuvre peut s'avérer difficile, surtout avec un grand nombre de correspondants car il faut autant de clés que de correspondants.


Quelques algorithmes de chiffrement symétrique très utilisés :

• Chiffre de Vernam
• DES
• 3DES ou Triple DES
• AES (voir, par ex., la fonction SQL ENCRYPT_AES)
• RC4
• RC5
• MISTY1
  • et d'autres (voir la liste plus exhaustive d'algorithmes de cryptographie symétrique sur wikipedia).

Algorithmes de cryptographie asymétrique (à clé publique et privée)

Pour résoudre le problème de l'échange de clés, la cryptographie asymétrique a été mise au point dans les années 70. Elle se base sur le principe de deux clés :

• une publique, permettant le chiffrement 
• une privée, permettant le déchiffrement.

Comme son nom l'indique, la clé publique est mise à la disposition de quiconque désire chiffrer un message.
  Ce dernier ne pourra être déchiffré qu'avec la clé privée, qui doit rester confidentielle.


Quelques algorithmes de cryptographie asymétrique très utilisés :

• RSA (chiffrement et signature)
• DSA (signature)
• Protocole Diffie-Hellman (échange de clé)
  • et d'autres (voir cette liste plus complète d'algorithmes de cryptographie asymétrique sur wikipedia)

RSA a publié des standards nommés PKCS (Public Key Cryptography Standards)

• PKCS 1 : standard RSA
• PKCS 3 : Deffie-Hellman
• PKCS 6 : première version de la norme X509
  • X509
    norme ISO, certificat contenant une identité (host, organisation ou personne physique) et une clé publique associée
    -> c'est la base du HTTPS
    
    
• PKCS 7 = Utilisé pour signer et/ou chiffrer des messages (en réponse à PKCS 10, par ex.), extension .p7b (contient plusieurs certificats)
• PKCS 10 : Format des messages envoyés à une autorité de certification et demandant la signature d'une paire de clés
  
  format texte à la norme ASN 1 : extension .DER
  • codé en base64 et encadré de "-----BEGIN CERTIFICATE-----" et "-----END CERTIFICATE-----"
    cela donne le format PEM (.pem ou .cer ou .crt), les demandes (CSR) et les imports/exports, de certificats se font dans ce format
• PKCS 12 : format de fichier (.p12) utilisé pour stocker la clé privée et le certificat de clé publique correspondant, en les protégeant par un mot de passe.
  (utilisé par les keystore de java) contient toute la chaine des certificats (authorités ayant certifié ce certiticat)
  



Le principal inconvénient de RSA (et des autres) est la grande lenteur par rapport aux algorithmes à clés secrètes. RSA est par exemple 1000 fois plus lent que DES.


La cryptographie asymétrique est également utilisée pour assurer l'authenticité d'un message. L'empreinte du message est chiffrée à l'aide de la clé privée et est jointe au message. Les destinataires déchiffrent ensuite le cryptogramme à l'aide de la clé publique et retrouvent normalement l'empreinte. Cela leur assure que l'émetteur est bien l'auteur du message. On parle alors de signature.

 

Fonctions de hachage

Une fonction de hachage (Hash) est une fonction qui convertit un grand ensemble en un plus petit ensemble, l'empreinte.
 Ce n'est pas du chiffrement, car Il est impossible de la déchiffrer pour revenir à la donnée d'origine.


code d'authentification de message, ou MAC en anglais est un code accompagnant des données dans le but d'assurer leur intégrité, permettant de vérifier qu'elles n'ont subi aucune modification, après une transmission par exemple.

 

HMAC, de l'anglais keyed-hash message authentication code est un type de code MAC, calculé en utilisant une fonction de hachage en combinaison avec une clé secrète.
Il peut être utilisé pour vérifier simultanément l'intégrité de données et l'authenticité d'un message.

N'importe quelle fonction de hachage, comme MD5 ou SHA-1, peut être utilisée dans le calcul d'un HMAC ; le nom de l'algorithme résultant est HMAC-MD5 ou HMAC-SHA-1.


Quelques fonctions de hachage très utilisées :

• MD5  (vous pouvez tester ici http://www.cryptage.org/outil-crypto-hachage.html)
• SHA-1 
• SHA-256 ou SHA-512
  • le signatures des jetons JWT, sont cryptées
    • les jetons JWT contiennent :
      • une entête
      • des données "utiles" (payload)
      • une signature, qui est le résultat de l'entête (codée en base64URL) et des données (codées en base64URL), cryptées avec :
        • RS256 , RS512 (RSA with SHA256/512) c'est à dire des clés asymétriques
        • HS256, HS512 (HMAC with SHA256/512) c'est à dire des clés symétriques
  • (voir cette liste plus complète d'algorithmes de hachage sur wikipedia)
  • Enfin, testez les fonctions de hachage sur ce site https://emn178.github.io/online-tools/
    

•Ne confondez pas hachage, qui est du chiffrement, et codage qui est de la codification, comme, par exemple, base64

•  Voyez notre exemple en RPG dans les freeware de volubis.fr ou celui de scott Klement
  
  • Base64URL est un codage base64 compatible avec les URL ("+" est remplacé par "-" et "/" par"_")
  

 PROTOCOLES sécurisés

Transport Layer Security (TLS) , et son prédécesseur Secure Sockets Layer (SSL), sont des protocoles de sécurisation des échanges sur Internet.

Le protocole SSL a été développé à l'origine par Netscape. Il évolue en version 3, puis est banni en 2014, à la suite de la faille POODLE, ce bannissement est ratifié en juin 2015.

L'IETF en a poursuivi le développement en le rebaptisant Transport Layer Security (TLS). La dernière version (publiée en Août 2018) est TLS 1.3.

Ces protocoles fonctionnent suivant un mode client/serveur et permettent de satisfaire les objectifs de sécurité suivants :

• l'authentification du serveur (certificat émis par une autorité de confiance)
• la confidentialité des données échangées (la session est chiffrée)

La mise en œuvre est facilitée par le fait que les protocoles de la couche application, comme HTTP, n'ont pas à être profondément modifiés pour utiliser une connexion sécurisée, mais seulement implémentés au-dessus de SSL/TLS, ce qui pour HTTP a donné le protocole HTTPS, pour FTP FTPS, TELNETS, etc..

Rappel du modèle ISO à 7 couches (inspiré de SNA qui avait 6 couches)

les serveurs utilisent alors un port IP spécifique (443 pour HTTPS, 992 pour TELNETS)

     Session 5250 basée sur TELNETS

Lorsqu'un utilisateur se connecte à un site web qui utilise TLS, les étapes suivantes ont lieu :

1. le navigateur du client envoie au serveur une demande de mise en place de connexion sécurisée par TLS.
2. Le serveur envoie au client son certificat : celui-ci contient sa clé publique, ses informations (nom de la société, adresse postale, pays, e-mail de contact...) ainsi qu'une signature numérique.
3. Le navigateur du client tente de vérifier la signature numérique du certificat du serveur en utilisant les clés publiques contenues dans les certificats des autorités de certifications (AC) intégrés par défaut dans le navigateur.
   1. Si l'une d'entre elles fonctionne, le navigateur web en déduit le nom de l'autorité de certification qui a signé le certificat envoyé par le serveur. Il vérifie que celui-ci n'est pas expiré puis envoie une demande OCSP à cette autorité pour vérifier que le certificat du serveur n'a pas été révoqué.Le logo affiché ->
   2. Si aucune d'entre elles ne fonctionne, le navigateur web tente de vérifier la signature numérique du certificat du serveur à l'aide de la clé publique contenue dans celui-ci.
      1. En cas de réussite, cela signifie que le serveur web a lui-même signé son certificat.
         
         Un message d'avertissement s'affiche alors sur le navigateur web, prévenant l'utilisateur que l'identité du serveur n'a pas été vérifiée par une autorité de certification et qu'il peut donc s'agir potentiellement d'un site frauduleux. Logo alors utilisé
      2. En cas d'échec, le certificat est invalide, la connexion ne peut pas aboutir.
4. Le navigateur du client génère une clé de chiffrement symétrique (à la différence des clés privés et publiques utilisés par les certificats qui sont asymétriques), appelée clé de session, qu'il chiffre à l'aide de la clé publique contenue dans le certificat du serveur puis transmet cette clé de session au serveur.
5. Le serveur déchiffre la clé de session envoyée par le client grâce à sa clé privée.
6. Le client et le serveur commencent à s'échanger des données en chiffrant celles-ci avec la clé de session qu'ils ont en commun.
   
   On considère à partir de ce moment que la connexion TLS est alors établie entre le client et le serveur.
7. Une fois la connexion terminée (déconnexion volontaire ou timeout), le serveur révoque la clé de session

Information concernant un certificat

Tel qu'affiché par le navigateur (ici Firefox)

Détail du certificat (Autorités de certification , CA)

Algorithme :

ET IBM i ?

•Les clés

peuvent être stockées dans des magasins de clé (keystore), il en existe 4

• Cryptographic Services keystore pour les API de cryptographie
• Digital certificate manager, certificate store (pour DCM)
• CCA keystore (utilisé par les Co-processeurs 4767/4764)
• JCE keystore, utilisé par Java

  les fournisseurs de service de cryptographie pouvant être :

• Java Cryptography, le standard du monde java
• IBM i Cryptographic Services (un jeu d'APi, proposé par IBM i)
• Network Authentication Service (Kerberos utilisé dans le cadre d'un SSO EIM)
• IBM i TLS et JSSE, utilisés par la couche transport (HTTPS, par exemple)

• Dans ce dernier cas, les niveaux (protocoles et algorithmes) acceptés, sont gérés par les valeurs systèmes : QSSLPCL, QSSLCSLCTL et QSSLCSL.

• QSSLPCL indique les protocoles acceptés
  • la valeur *OPsys implique les valeurs suivantes (en fonction des versions)

• Version	QSSLPCL *OPSYS
  7.4	*TLSV1.3 *TLSV1.2
  7.3	*TLSV1.2 *TLSV1.1 *TLSV1
  7.2	*TLSV1.2 *TLSV1.1 *TLSV1
  7.1	*TLSV1 *SSLV3
  6.1	*TLSV1 *SSLV3

• QSSLCSPCTL indique le fonctionnement par défaut
  • *OPSYS les algorithmes sont gérés automatiquement par l'OS.
  • *USRDFN : la liste des algorithmes est éditable (voir QSSLCSP)
• QSSLCSP : liste des algorithmes de chiffrement à utiliser (si *USRDFN)
  

ici sur une version 7.3 (cela peut varier en fonction des PTF)

• il y a déjà eu des changements en version 7.3 sur algorithmes (cipher) supportés :
  • les Rivest Cipher 4 (RC4) 128-bit ont disparus.
  • Les algorithmesGalois/Counter Mode (GCM) sont maintenant prioritaires devant les algho Cipher Block Chaining (CBC)
  • Tous les algorithmes à moins de 128-bit ont disparus.
  • Mais vous pouvez forcer par QSSLCSLCTL = *USRDFN
• Protocoles de sécurité et algorithmes de chiffrement en version 7.4 :
  • SSL v2, n'est plus admis
  • les protocoles TLSv1.1 et TLSv1.0 ne sont plus actifs, par défaut
  • les algorithmes suivants, ne sont plus intégrés QSSLCSLCTL = *OPSYS.
    • Triple Des (3DES)
    • Cipher BlockChaining (CBC)
    • RSA key pair
  • Sont désormais, en standard :
    • AES_128_GCM_SHA256
    • AES_256_GCM_SHA384
    • CHACHA20_POLY1305_SHA256
    • ECDHE_ECDSA_AES_128_GCM_SHA256
    • ECDHE_ECDSA_AES_256_GCM_SHA384
    • CDHE_RSA_AES_128_GCM_SHA256
    • ECDHE_RSA_AES_256_GCM_SHA384

• Si vous avez besoin de ces algorithmes dépréciés (après les avoir ajoutés à QSSLCSL par WRKSYSVAL) ou de ces protocoles :
  • il faut les autoriser dans SST , macro TLSCONFIG dans Advanced Analysis (STRSST/Start a service tool / 4 / 1 / 2 / 14)
    • -eligibleDefaultProtocols:<ProtocolNumber>
    • -eligibleDefaultCipherSuites:<cipherSuiteNumber>
• TLSv1.3 est ajouté par défaut
  • là aussi, utiliser la macro TLSCONFIG dans Adanced Analysis pour l'enlever
    
    

Voyez ensuite :

• Notre cours sur HTTPS et TELNETS.
• et notre cours OpenSSL, OpenSSH sous PASE

Copyright © 1995,2019 VOLUBIS