Hachage n’est pas cryptage ! De la sécurité des données chiffrées dans les SGBDR

De plus en plus de jeunes développeurs confondent la technique du hachage et le chiffrement des données. Voici un point sur le sujet…

Qu’est-ce que le hachage ?

Le hachage consiste à calculer une donnée de petite dimension à partir d’une donnée de grande dimension afin de s’en servir comme repère dans différents processus algorithmique. La valeur obtenu par hachage est un nombre ou une chaine binaire et dans ce dernier cas généralement représentée en hexadécimal.
Les algorithmes de hachage les plus connus sont : MD2, MD4, MD5 (16 octets / 128 bits en sortie), SHA (ou SHA-0), SHA-1 (20 octets / 160 bits en sortie), SHA-2 (224 à 512 bits), Whirlpoll (64 octets / 512 bits).
On trouvera la description des algorithmes de calcul de ces fonctions de hachage aux URL suivantes :

  • MD2 : http://tools.ietf.org/html/rfc1319
  • MD4 : http://tools.ietf.org/search/rfc1320
  • MD5 : http://fr.wikipedia.org/wiki/MD5
  • SHA : http://fr.wikipedia.org/wiki/SHA-0
  • SHA1 : http://fr.wikipedia.org/wiki/SHA-1
  • SHA2 : http://fr.wikipedia.org/wiki/SHA-2
  • Whirlpool : http://www.seas.gwu.edu/~poorvi/Classes/CS381_2007/Whirlpool.pdf
  • La valeur en sortie est de taille fixe quel que soit la longueur de l’information d’entrée. Du point de vue des mathématiques il ne peut s’agir d’un processus de cryptage puisque le cryptage produit des données dont le volume est au moins aussi important que le volume des données en entrée, voir beaucoup plus lorsque les données d’entrée sont de petits volumes.
    Certains logiciels utilisent leurs propres algorithmes pour générer des valeurs de hachage. Par exemple SQL Server implémente les fonctions CHECKSUM, BINARY_CHECKSUM et CHECKSUM_AGG pour calculer un entier 32 bits à partir d’une valeur, d’une expression ou d’une liste d’expression ou de valeurs combinées, soit pour une ligne, soit pour une colonne.
    On trouvera un exemple de l’algorithme utilisé à l’URL suivante : http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=70832

    Le hachage entraîne fatalement des collisions, c’est à dire que différentes informations peuvent produire une même valeur de hachage.

    Voici un exemple de collision de hachage avec la fonction MD5…
    Pour PostGreSQL :

    SELECT md5(E'\\xd131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70'::bytea)
    UNION ALL
    SELECT md5(E'\\xd131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70'::bytea)

    Pour MS SQL Server :

    SELECT HASHBYTES('md5', 0xd131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f8955ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5bd8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70)
    UNION ALL
    SELECT HASHBYTES('md5', 0xd131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f8955ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5bd8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70)

    le 20e octet est différent dans les deux chaines hexadécimales passées en argument.

    Le hachage n’est pas non plus réversible. Il n’existe pas de fonction permettant à coup sûr de retrouver l’information initiale partant de la valeur hachée. La possibilité de collisions s’oppose à la bijection impérativement nécessaire à déterminer une fonction réciproque.

    Le but du hachage n’est donc pas de crypter des données mais de donner une « empreinte » à une donnée.

    Qu’est-ce que le cryptage ?

    Le cryptage est l’ensemble des processus permettant à une donnée d’être transformée en une autre incompréhensible pour qui ne connais pas la donnée originale, puis, partant de la transformation, d’être retransformée en donnée d’origine.
    Le cryptage nécessite donc l’existence de deux traitements conjoints et bijectifs : l’un de cryptage, l’autre de décryptage. On parle alors de correspondance univoque entre l’ensemble des données en clair et l’ensemble des données cryptées.
    Le chiffrement est un sous ensemble du cryptage qui consiste à utiliser des fonctions mathématiques afin de crypter et de décrypter. Néanmoins il en existe d’autres comme par exemple la stéganographie…

    Les techniques modernes de cryptage en matière informatique sont basées sur le chiffrement à l’aide d’algorithmes à clefs :

  • la même clef servant à crypter et décrypter, on parle alors de chiffrement symétrique (il faut garder sa clef secrète)
  • une clef sert à chiffrer une autre à déchiffrer, on parle alors de chiffrement asymétrique (on peut rendre publique l’une des deux clefs)
  • L’algorithme est connu et la clef de décryptage est confidentielle. La sécurité est basée sur la complexité d’un possible déchiffrement par une attaque de type « force brute » (essais de décryptage par toutes une série de clef probables).
    La complexité du chiffrement est liée à l’algorithme et à la longueur de la clef. Les algorithmes à clef asymétriques étant plus fiables car plus complexes, mais aussi plus couteux en temps de traitement.

    Principaux algorithmes (et longueur de clef) :

  • symétrique : DES (56 bits), TRIPLE_DES (128 ou 192 bits), RC2, RC4, RC4_128 (128 bits), AES (128 à 256 bits)
  • asymétrique : RSA_512 (512 bits), RSA_1024 (1024 bits), RSA_2048 (2048 bits)
  • NOTA : les algorithmes de type RC sont aujourd’hui considérés comme peu fiables et ne doivent plus être utilisés en production, car ils sont faciles à casser. RC2 fût longtemps utilisé par Lotus Notes. RC4 est encore utilisé pour protéger les informations d’un réseau wifi avec clef WEP ou WPA.

    Emploi du hachage

    Les tous premiers emplois du hachage ont été une pseudo cryptographie à sens unique destinée à vérifier la justesse d’une information connue. Le principe est assez simple : on calcule une valeur de hachage sur des informations confidentielle et on stocke cette valeur plutôt que les informations.
    Si quelqu’un vient avec les données originales que l’on hache avec le même algorithme, alors les deux valeurs (le hachage calculé et le hachage stocké) sont identiques; On suppose alors que les données sont les mêmes, ce qui, du fait des collisions potentielles est paradoxalement faux.
    Mais avant l’an 2000, exploiter un véritable mécanisme de cryptage était considéré comme un crime et passible d’une peine de prison. C’est pourquoi le hachage prit de l’ampleur avant que deux choses ne se produisent :

  • la découverte de techniques d’attaques permettant de « casser » ou de semer le trouble concernant le hachage (par exemple la génération de collisions)
  • la liberté légale de crypter des données, introduite en droit français peu après la directive européenne 2000/31/CE du 8 juin 2000 sur le commerce électronique, suite à l’affaire Zimmermann et son outil PGP.
  • Dès lors les algorithmes de cryptage ont remplacé la plupart des processus de hachage sauf dans les systèmes encore en vigueur dont ils constituent une part essentiel du fonctionnement.

    Néanmoins le hachage peut rendre d’inestimables services. Il est notablement utilisé dans les systèmes informatiques distribués ou dans la gestion du parallélisme d’accès à des ressources d’un système, notamment pour situer une information.
    Ainsi dans un système de bases de données distribuées on calculera une clef de hachage sur les éléments d’authentification de l’utilisateur et sur cette clef on calculera un modulo en fonction du nombre de nÅ“uds dans le maillage du système distribué.
    Par exemple pour un site web comme fnac.com il existe de nombreux serveurs de bases de données, chacun ayant en table tous les produits à vendre, mais un client n’existant que sur un seul des serveurs.
    Tant que l’utilisateur navigue anonymement on route ses requêtes sur le serveur le moins chargé à l’instant t;
    Dès qu’il est authentifié ou calcule une clef de hachage sur son mail + mot de passe, puis on calcule un modulo en fonction du nombre de serveurs et on route dorénavant toutes ses requêtes sur le serveur dont l’indice correspond au modulo, puisque c’est seulement sur ce serveur que le client est connu.

    Le même algorithme est appliqué dans certains moteurs de bases de données relationnelles pour gérer des traitements en parallèle ou diminuer le temps de traitement. Par exemple pour résoudre une jointure (hash join) ou un groupage (hash group)

    Emploi de la cryptographie

    La cryptographie sert à rendre confidentielles certaines informations qui ne pourrons être décryptées que par ceux qui connaisse la façon de crypter et donc de décrypter.
    Elle permet aussi l’authentification, par le biais de certificat qui sont des documents liant une identité à une clef par le biais d’une signature (tiers de confiance) et permettent d’avoir la certitude sur l’origine d’une entité.

    Signature de documents et authentification

    La signature numérique (ou signature électronique) permet de garantir l’intégrité d’un document électronique et par là même d’en authentifier l’auteur.
    Elle fonctionne à l’aide d’une clef asymétrique ou d’un certificat, et une fonction de hachage :

  • l’auteur calcule une valeurs de hachage par le biais de la fonction de hachage considérée puis crypte cette information de hachage qui constitue la signature du document électronique. Cette signature est incorporée au document.
  • lors de la réception le destinataire calcule une valeur de hachage sur le document sans tenir compte de la signature, puis décrypte la signature à l’aide de la clef publique. Si les deux valeurs (la signature incorporée et la signature nouvellement calculées) sont identiques, alors le document à toutes les chances d’être authentique.
  • Il est par exemple possible de « signer » un programme informatique (exécutable ou DLL).

    Chiffrement de données

    Un exemple typique de chiffrement est la communication d’information confidentielle par email. En effet, les données d’un email peuvent être interceptées sur le réseau Internet, ce à quoi s’emploient certaines organisations telles que la NSA.

    La confidentialité des données stockées notamment dans les bases de données nécessite parfois du chiffrement. C’est le cas des données des cartes bancaires ou des données personnelles notamment dans certains domaines sensibles comme la politique, le syndicalisme, la religion ou la santé.
    Dans ce dernier secteur, la Loi française impose des standards de chiffrement très élevées lorsque ces données sont accessibles sur Internet (Décret n° 2006-6 relatif à l’hébergement de données de santé à caractère personnel).

    Certains SGBDR incorporent des services de génération et de gestion de clefs, de cryptage/décryptage et d’authentification par certificat. C’est par exemple le cas d’Oracle ou de MS SQL Server qui sont leurs propres autorités de certifications et stockent les clefs dans les bases.
    D’autres SGBDR propose des fonctions de cryptage/décryptage sans la gestion des clefs, ce qui pose le problème de la conservation des clefs… C’est le cas de MySQL et de PostGreSQL qui nécessite un tiers externe de certification et obligent à véhiculer les clefs d’une manière ou d’une autre, souvent par le biais de fichiers sur le serveur…
    Le chiffrement des données dans les bases de données posent d’ailleurs d’autres problèmes :

  • le cassage aisé du code, si les données ne sont pas « salées »
  • la rapidité d’accès à l’information
  • la volumétrie de stockage des données cryptées
  • la difficulté de recherches performantes
  • Le salage est abordé au paragraphe suivant et constitue une faille de sécurité importante en son absence.

    La rapidité d’accès à l’information est notablement diminuée par le fait de crypter et décrypter en permanence

    La volumétrie des données cryptées est plus importante en général que lorsque les données ne sont pas cryptées

    Enfin, il est très difficile de rendre les recherches performantes dès lors que les données sont cryptées et salées par le simple fait qu’il est impossible d’utiliser un index et que par conséquent, il faut lire séquentiellement toutes les données et les décrypter avant d’effectuer la comparaison.

    Il faut aussi faire très attention dans les bases de données au recoupement des données qui permettrait, même avec un chiffrage, de trouver certaines données. En effet, toutes les informations ne sont pas chiffrées et heureusement sinon les performances seraient catastrophiques et la base inexploitable… Mais imaginons une base de données dans laquelle nous savons qu’un des patients est un général argentin… Si ces informations figurent en clair et que, comme il est probable, il y a peu d’argentins et peu de généraux dans les données, alors il est facile de trouver ou figure cet individu dans la base et par là même de retrouver de fil en aiguille certaines informations comme son prochain rendez-vous de chimio !

    Pour pallier à ce dernier inconvénient, une autre solution de chiffrement dans les bases données est basée sur le cryptage du stockage et non plus des données (TDE ou Transparent Data Encryption que l’on trouve notamment chez Oracle et MS SQL Server). Les données sont alors manipulées en clair en mémoire et de façon optimisé (utilisation des index) alors qu’elles figurent de manière chiffrées dans les fichiers (données des tables en index et journal de transactions), le cryptage/décryptage étant assurée à la volée lors des entrées / sorties au niveau du disque.

    Enfin, certains SGBDR (Oracle, MS SQL Server) permmettent d’utiliser des boitiers externes de chiffrement inviolables (HSM ou Hardware Security Module) que l’on place sur le réseau et qui sont utilisés par le serveur SQL. En cas de tentative d’accès au boitier, les clefs sont automatiquement détruites.
    Un exemple d’utilisation d’un HMS en pratique est celui qui protège les données personnelles confidentielles de santé des agents territoriaux de France (environ 2 millions d’individus) par le biais d’un HSM et d’un serveur de bases de données Microsoft SQL Server,

    Salage

    Le salage, est une méthode permettant de renforcer la sécurité des informations cryptées en y ajoutant une donnée supplémentaire afin d’empêcher que deux informations identiques conduisent aux mêmes données chiffrées. Le but du salage est de lutter contre une attaque par analyse fréquentielle.
    Le cas est classique dans les bases de données. En effet, lorsque le système concentre beaucoup de données, il est fréquent de trouver des informations identiques (redondances) comme c’est par exemple le cas des noms de famille (MARTIN, DURAND, LEFEBVRE…)
    Dès lors une analyse basées sur la fréquence d’apparition des redondances permettrait assez rapidement de casser le code.
    Pour pallier à cet inconvénient, certains SGBDR comme Oracle ou SQL Server intègrent automatiquement un salage pour que deux données identiques donnent deux codes chiffrés différents.

    NOTA : les serveurs de bases de données comme MySQL ou PostGreSQL ne permettent pas d’utiliser un salage automatique des données lors de l’utilisation des fonctions de cryptage.

    Bases de données et chiffrement

    À la lecture des paragraphes précédent, il apparait clair que les solutions de chiffrement actuelles dans les bases de données « libres » comme PostGreSQL ou MySQL sont incapable de procurer une sécurité suffisante :

  • les clefs sont généralement stockées en fichiers sur le serveur et non dans la base et sont par conséquent lisible par tout utilisateur ayant accès au serveur;
  • le chiffrement n’est pas « salé » et par conséquent une attaque du code par analyse fréquentielle est possible;
  • ces serveurs ne permettent pas d’utiliser des boitiers de type HSM, qui s’avèrent particulièrement intéressant pour les données bancaires (code des cartes de paiement) ou de santé (données personnelles);
  • un service de chiffrement du stockage de type TDE n’est pas intégré dans de tels serveur ce qui fait par exemple qu’un fichier de données ou une sauvegarde volée donne tout le temps au voleur de déchiffrer par recoupement.
  • comme la clef ne figure pas dans la base, elle doit être transmise en clair dans les requêtes. Elle figure donc dans les routines (fonctions PG/PLSQL de PostGreSQL par exemple) comme dans les requêtes des appliciations clientes.
  • le code généré est généralement assez court et permet plus aisément une attaque
  • Exemple de chiffrement de données dans les bases de données

    Avec PostGreSQL, extension pgcrypto avec algorithme AES :

    CREATE EXTENSION pgcrypto;

    CREATE TABLE T_NOM
    (NOM         VARCHAR(32),
     NOM_CRYPTE  bytea);

    INSERT INTO T_NOM (NOM)
    VALUES ('MARTIN'),
           ('DUPONT'),
           ('MARTIN'),
           ('DURAND');

    Cryptage :

    UPDATE T_NOM
    SET    NOM_CRYPTE = encrypt(CAST(NOM AS bytea), 'Le petit chat est mort.', 'aes');
    SELECT * FROM T_NOM;

    NOM        NOM_CRYPTE
    ---------- ---------------------------------------------------------------
    MARTIN     \212\306\335\270\27615\334\33021o\212\271\252a\277\302
    DUPONT     \343\331\307-\202\203\301|(\247M32+\177\301\265
    MARTIN     \212\306\335\270\27615\334\33021o\212\271\252a\277\302
    DURAND     3513\252\23627^M21,3002]w\326\227

    Décryptage :

    SELECT NOM, CAST(decrypt(NOM_CRYPTE, 'Le petit chat est mort.', 'aes') AS VARCHAR(32)) AS NOM_CLAIR
    FROM   T_NOM;

    NOM        NOM_CLAIR
    ---------- ---------------------------------------------------------------
    MARTIN     MARTIN
    DUPONT     DUPONT
    MARTIN     MARTIN
    DURAND     DURAND

    Comme on le voit, le mot de passe de la clef de cryptage est passée en clair lors de l’utilisation des fonctions de cryptage et décryptage.
    Le chiffrement de MARTIN a donné deux fois le même code, la longueur du code est d’une quinzaine d’octets…

    Avec SQL Server (chiffrement intégré dans toutes les versions) algorithme AES :

    -- création d'une clef de cryptage de niveau base de données
    -- permettant la génération de clefs de cryptage interne
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Le petit chat est mort.';
    GO

    -- création d'une clef de cryptage avec algorithme ASE clef à 256 bits
    CREATE SYMMETRIC KEY MA_CLEF
    WITH ALGORITHM = AES_256
        ENCRYPTION BY PASSWORD = 'P@ssw0rd !';
    GO    

    CREATE TABLE T_NOM
    (NOM         VARCHAR(32),
     NOM_CRYPTE  VARBINARY(256));

    INSERT INTO T_NOM (NOM)
    VALUES ('MARTIN'),
           ('DUPONT'),
           ('MARTIN'),
           ('DURAND');

    Cryptage :

    -- ouverture de la clef pour la session
    -- peut être fait côté serveur dans un déclencheur FOR LOGON et dans ce cas
    -- le mot de passe ne sera pas codé dans les applis ni transmis dans le réseau
    OPEN SYMMETRIC KEY MA_CLEF
    DECRYPTION BY PASSWORD = 'P@ssw0rd !';
           
    -- la fonction KEY_GUID permet de retrouver la clef primaire informatique
    -- (de type GUID) de la clef de cryptage pour pouvoir l'utiliser
    UPDATE T_NOM
    SET    NOM_CRYPTE = ENCRYPTBYKEY(KEY_GUID('MA_CLEF'), NOM);
    SELECT * FROM T_NOM;

    NOM          NOM_CRYPTE
    ------------ ------------------------------------------------------------------------------------------------------------
    MARTIN       0x00AC31E101131E408D190F626A5F757801000000519DC1A3C61A63A66EA857F7E9BBE649E09989B0E718CDFE861BE27CFAEA68B8
    DUPONT       0x00AC31E101131E408D190F626A5F7578010000000BECCA5469AFF7771675C1D9FB7103A1807FE2430FBF1922C56A990CBC3BA6FF
    MARTIN       0x00AC31E101131E408D190F626A5F757801000000B496C2D5DC5D92D4303B05B86457042767CC4382F852B29BFA1B0A66BB566388
    DURAND       0x00AC31E101131E408D190F626A5F757801000000121A2325A435CD72E830B255089C25CA24CF0A7FD2C693F66819FE5493FDD0F0

    Décryptage :

    -- la clef étant ouverte, on a pas besoin du mot de passe pour décryptage
    SELECT NOM, CAST(DECRYPTBYKEY(NOM_CRYPTE) AS VARCHAR(32)) AS NOM_CLAIR
    FROM T_NOM;

    NOM          NOM_CLAIR
    ------------ --------------
    MARTIN       MARTIN
    DUPONT       DUPONT
    MARTIN       MARTIN
    DURAND       DURAND    

    CLOSE SYMMETRIC KEY MA_CLEF;

    Le mot de passe de la clef n’est pas passé pour crypter et décrypter. L’ouverture de la clef peut être automatisée côté serveur par un déclencheur FOR LOGON.
    Le chiffrement de MARTIN a donné deux codes différents et la longueur du code est de 52 octets…
    On peut aussi utiliser un certificat à la place du mot de passe.

    Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES
    Expert  S.G.B.D  relationnelles   et   langage  S.Q.L
    Moste  Valuable  Professionnal  Microsoft  SQL Server
    Société SQLspot  :  modélisation, conseil, formation,
    optimisation,  audit,  tuning,  administration  SGBDR
    Enseignant: CNAM PACA, ISEN Toulon, CESI Aix en Prov.

    L’entreprise SQL Spot
    Le site web sur le SQL et les SGBDR

    MVP Microsoft SQL Server

    Une réflexion au sujet de « Hachage n’est pas cryptage ! De la sécurité des données chiffrées dans les SGBDR »

    Laisser un commentaire