MIF29 cryptographie et sécurité

L’authentification désigne le processus visant à vérifier qu’une entité (personne, service, machine) est bien légitime pour accéder au système.

Authentification versus autorisation

Différences entre

• Authentification (authentication 🇬🇧) : vérifier/prouver qui est l’entité (e.g., mot de passe, certificat, hmac)
• Autorisation (authorization 🇬🇧): vérifier si l’entité a le droit (contrôle d’accès)

Voir Authentication vs. Authorization.

Les facteurs de validation pour l’authentification

• Ce que je sais (knowledge factors)
  • PIN, mot de pass, passphrase, question de sécurité
• Ce que je possède (ownership factors)
  • carte à puce, clef usb, téléphone, jeton,
• Ce que je suis (inherence factors)
  • empreintes digitales, rétine, voix, visage, ADN.

👉 Pour le dernier, on parle plutôt d’identification, car il n’y a pas de secret.

Briques cryptographiques

Principales primitives 🧱

• 🎲 Nombres aléatoires
• #️⃣ Fonctions de hachage
• 🔑 Chiffrement symétrique
• 🔒 Chiffrement asymétrique
• ✉️ Message authentifié
• 🔏 Signature

Des primitives aux applications

• Primitive cryptographique : e.g., RSA
  • Schéma cryptographique : e.g., PKCS#1 OAEP
    • Protocole cryptographique : e.g., TLS 1.3
      • Application : vous êtes ici 👈

Génération de (grands) nombres (pseudo-)aléatoires

Référence (practical cryptography).

• Différence entre qualité cryptographique CSPRNG et PRNG
  • e.g., instructions RDRAND

Fonctions de hachage

Référence (practical cryptography).

• e.g., SHA-2 (SHA-256, SHA-512),
• e.g., SipHash utilisé dans Python PEP456 – Secure and interchangeable hash algorithm, Node.js …

Propriétés d’une fonction de hachage cryptographique

• Efficacité : le calcul de h(m) doit être efficace
• Résistance aux collisions
  • la probabilité de trouver m et m' différents tels que h(m)=h(m') est négligeable
• Résistante à la seconde pré-image
  • connaissant m, la probabilité de trouver m' différent de m t.q. h(m)=h(m') est négligeable
• Résistante à la première pré-image (ou one-wayness)
  • connaissant d, la probabilité de trouver m t.q. d=h(m) est négligeable

Lien entre les propriétés

Théorème : collision resistant => 2nd-preimage resistant => is one-way

Voir 8.11 Security without collision resistance (Boneh, Shoup, 2023).

Remarques

• La seconde implication est vraie seulement si h compresse suffisamment.
  • c’est le cas pour les algorithmes de hash usuels.
• Pour la structure de données table de hachage, ou juste one-way si la table est critique ou même moins.

Chiffrement symétrique

Dit à clef secrète ou partagée. Référence (practical cryptography).

• Par bloc, e.g., AES,
  • avec un mode d’opération, e.g., GCM, CTR
• Par flux, dit aussi synchrone, e.g., ChaCha20
• 🚀 Très performants e.g., instructions AES-NI,
  • Des ordres de grandeur plus rapide que RSA.

Chiffrement asymétrique

Dit à clef publique. Référence (practical cryptography).

• e.g., RSA, ECC, Pailler, voir la première partie de MIF29

Message Authentication Code

Référence (practical cryptography).

• e.g., HMAC
• Combiné au chiffrement, on parle de chiffrement authentifié
  • e.g., Chacha20-Poly1305 ou certains modes AES comme AES-GCM

Signature

Référence (practical cryptography).

• e.g., RSA, ECDSA

💡 MAC et signature visent l’authentification (au sens cryptographique) dans le cadre symétrique ou asymétrique. 💡

Exemple: Hash-based Message Authentication Code – HMAC

• Utilise une fonction de hachage (e.g., SHA-2).
• Ajoute une preuve (tag) au message, Authenticated Encryption with Associated Data – AEAD
• Le tag prouve l’authenticité du message :
  • comme une forme de signature, mais dans le cadre symétrique ;
  • seul un détenteur de la clef peut le produire ;
  • e.g., champ signature JSON Web Token.

Définition dans le cas symétrique

\mathsf{HMAC}_k(m) = h(\bar{k} \oplus \mathsf{opad} \| h(\bar{k} \oplus \mathsf{ipad} \| m))

• b taille de bloc en bits utilisée par h
• \bar{k} la clef (complétée avec des 0 si |k|<b )
• \mathsf{ipad} et \mathsf{opad} deux blocks de b bits
  • 0x36 et 0x5c répétés

Voir Keyed-Hashing for Message Authentication.

Références sur la cryptographie

• https://www.crypto101.io/ : niveau introduction, pour les développeurs
• https://cryptobook.nakov.com/ : plus détaillé, sans trop de maths, recommandé
• https://toc.cryptobook.us/ : très détaillé et spécialisé mais fait autorité

Remarque : les briques de bases sont interdépendantes, par exemple le mode AES-CTR est une forme de chiffrement par flux qui lui-même est assimilable à un CSPRNG, voir par exemple /dev/urandom du kernel Linux.

A Research Agenda Acknowledging the Persistence of Passwords

Despite countless attempts and near-universal desire to replace passwords, they’re more widely used than ever. The authors assert that, in many instances, passwords are the best-fit solution […].

Among security experts, there is near-unanimous agreement on the desirability of replacing passwords. Yet, this meta-goal is accepted without an understanding of what exactly is required of a replacement or what will improve once they are replaced.

Avec h une fonction de hachage, le protocole usuel de vérification :

1. A_i \to B: \langle A_i, pw_i \rangle
2. B \to A_i: OK si \langle A_i, h(pw_i) \rangle \in \mathrm{pt}

Le vérificateur stocke les paires \langle A_i, h(pw_i) \rangle dans la table des mots de passe \mathrm{pt}

maintainer:OYnL8rCBbf7rc
edgar:C8Z6wDFKm5bV6
patrick:58kk0mpCjpL9o
edwin:.8cBf8RFZqfvI
frank:gvEFH2KSvYZS2
jaap:NMS4yrkEfQz9c

On ne stocke pas les mots de passes en clair, mais on reste exposé à une attaque hors ligne si on connaît \mathrm{pt}.

☢️ Dans ce protocole les mots de passe circulent en clair, il est donc nécessaire d’avoir un canal de communication sécurisé entre les partenaires, typiquement TLS/HTTPS. ☢️

🤔 Passer A_i \to B: \langle A_i, h(pw_i) \rangle ne change pas la sécurité, car on peut rejouer le haché.

Attaques et contre-mesures

On a un compromis temps/mémoire en calculant les hachés à l’avance.

• On calcule et stocke des \langle pw_i, h(pw_i) \rangle dans \mathrm{t}
• On indexe \mathrm{t} sur h(pw_i).
• Pour casser \langle A_i, h(pw_i) \rangle \in \mathrm{pt}, il suffit d’une recherche dichotomique sur \mathrm{t}.

La méthode des rainbow tables est un très beau compromis entre calculer tous les hash à l’avance et tout calculer à la volée, voir Making a Faster Cryptanalytic Time-Memory Trade-Off

Pour un alphabet \Sigma, il y a |\Sigma| ^ n mots de passe de longueurs n. On peut parcourir intelligemment \Sigma ^ n

• Force brute (bruteforce)
• Dictionnaires (langue naturelle, jargon, ad hoc)
  • Au sens large, en millions de mots
• Heuristique (extension d’un dictionnaire par règles)
• Bientôt avec un LLM, voir par exemple PassGPT, arXiv.

🧰 john et hashcat.

Benchmark sur hashcat

OpenCL API (OpenCL 3.0 CUDA 12.1.109) [...]
========================================================================
* Device #1: NVIDIA GeForce GTX 1650, 3520/4095 MB (1023 MB allocatable), 14MCU

* (MD5) 11823.4 MH/s [...]
* (SHA1) 3724.8 MH/s [...]
* (SHA2-256) 1587.3 MH/s [...]
* (SHA2-512) 462.9 MH/s [...]
* (NTLM) 20751.5 MH/s [...]
* (NetNTLMv1 / NetNTLMv1+ESS) 10998.3 MH/s [...]
* (bcrypt $2*$, Blowfish (Unix)) [I : 32] 7333 H/s [...]

Combien de temps pour explorer tous les mots de passe de longueur n avec 62 caractères autorisés ?

def pretty(n):
    nb = (2**6) ** n
    return f"{n:2}", f"{nb / 11.8E9:.2e} sec", f"{nb:,} pwd"

[print(*pretty(n)) for n in range(4, 17)]

 4 1.42e-03 sec 16,777,216 pwd
 5 9.10e-02 sec 1,073,741,824 pwd
 6 5.82e+00 sec 68,719,476,736 pwd
 7 3.73e+02 sec 4,398,046,511,104 pwd
 8 2.39e+04 sec 281,474,976,710,656 pwd
 9 1.53e+06 sec 18,014,398,509,481,984 pwd
10 9.77e+07 sec 1,152,921,504,606,846,976 pwd
11 6.25e+09 sec 73,786,976,294,838,206,464 pwd
12 4.00e+11 sec 4,722,366,482,869,645,213,696 pwd
13 2.56e+13 sec 302,231,454,903,657,293,676,544 pwd
14 1.64e+15 sec 19,342,813,113,834,066,795,298,816 pwd
15 1.05e+17 sec 1,237,940,039,285,380,274,899,124,224 pwd
16 6.71e+18 sec 79,228,162,514,264,337,593,543,950,336 pwd

Table de nombre de hachés par seconde fonction de |\Sigma| et n sur un cluster selon la fonction.

Ever wondered what a #hashstack @hashcat cluster of 448x RTX 2080s could do for #password #cracking? How about 31.8 TH/s on NTLM, 17.7 TH/s on MD5

Contre-mesures

online

On essaie et on attend la réponse du vérificateur :

• Limiter le nombre d’essais ;
• Mettre un captcha pour éviter les bots ;
• Bannir, temporiser après échec.

Pour l’utilisabilité, il faut une procédure de récupération ou de changement de mot de passe, mais attention à sa sécurité, car la surface d’attaque est augmentée. Voir CAPEC-50: Password Recovery Exploitation.

offline

On dispose de \mathrm{pt}, on cherche pw t.q. pt=h(pw).

• 🧂 Éviter les compromis temps/mémoire
  • en ajoutant un aléa appelé un sel
• 🐢 Rendre l’attaque complexe en temps
  • en prenant une fonction h lente,
• 🐘 Rendre l’attaque complexe en mémoire
  • avec h qui nécessite inévitablement de la mémoire
  • limite les performances des circuits ASIC dédiés.

💡 Les fonctions sûres pour dériver des mots de passes sont appelées Key Derivation Function – KDF. Par exemple, pour élargir un secret à la taille d’un bloc (e.g., 32 octets) dans le chiffrement symétrique.

L’ajout de sel

On ajoute une donnée aléatoire non confidentielle au mot de passe, le sel.

Dans une table des mots de passes salés, le vérificateur stocke les paires \langle A_i, s_i, h(pw_i,s_i) \rangle :

maintainer:ef$OYnL8rCBbf7rc
edgar:01$C8Z6wDFKm5bV6
patrick:45$58kk0mpCjpL9o
edwin:a5$.8cBf8RFZqfvI

Challenge-Response Authentication

Principe général de CHAP, CRAM ou SCRAM : rendre le processus d’authentification dynamique.

Exemple méthode SCRAM(RFC5802) :

• scram-sha-256 dans PostgreSQL
• Improved Password-Based Authentication in MongoDB 3.0: SCRAM (part. 1) (part. 2)

Difficulté

Que stocker côté serveur ?

Extrait de la motivation dans MongoDB :

These attacks provide justification for SCRAM’s design, as it is specifically intended to counter them.

• Eavesdropping […]
• Replay […]
• Database Compromise […]
• Malicious Server […]

Exemples d’authentification par mot de passe

Authentification Linux

Les hachés sont stockés dans /etc/shadow, avec différentes méthodes :

• crypt : DES
• $1$ : MD5
• $2$, $2a$, $2b$ : bcrypt (sur Blowfish)
• $5$, $6$ : SHA-2
• $y$ : yescrypt

Exemples, voir unix.stackexchange.com

    > mkpasswd -m sha-512 --salt abcdefgh
    $6$u2bvcyi0$76I3KxGizdl/PENw[...]4FUhEBcKcg.

    > openssl passwd -6 -salt abcdefgh
    $6$u2bvcyi0$76I3KxGizdl/PENw[...]4FUhEBcKcg.

Authentification HTTP

On ne parle pas ici d’HTTPS mais des moyens inclus dans HTTP (Basic, Digest, Bearer, etc.) pour l’authentification.

Voir HTTP authentication et WWW-Authenticate sur MDN.

HTTP Basic

RFC 7617 - The ‘Basic’ HTTP Authentication Scheme

• On calcule base64(login:password).
• On transmet l’en-tête Authorization: Basic.

HTTP Digest

RFC 7616 - HTTP Digest Access Authentication

• On reçoit un HTTP 401 Unauthorized avec un challenge dans l’en-tête WWW-Authenticate
• On calcule H=(HA1, nonce, nc, cnonce, qop, HA2) avec
  • HA1=H(user:realm:password)
  • HA2=H(method:uri_path)
• On transmet l’en-tête Authorization: Digest

Autres modes

• RFC 7804 - Salted Challenge Response HTTP Authentication Mechanism
• RFC 5054 - Using the Secure Remote Password (SRP) Protocol for TLS Authentication

Recommandations

Gestion des mots de passes serveur

Voir OWASP Authentication cheat sheet

• Implement Proper Password Strength Controls
• Implement Secure Password Recovery Mechanism
• Store Passwords in a Secure Fashion
• Compare Password Hashes Using Safe Functions
• Transmit Passwords Only Over TLS
• Require Re-authentication for Sensitive Features

OWASP : password storage cheat sheet, voir la section Password Hashing Algorithms

Argon2 is a password-hashing function that summarizes the state of the art in the design of memory-hard functions and can be used to hash passwords for credential storage, key derivation, or other applications.

Argon2 le gagnant du concours PHC est nativement salé 🧂, coûteux en temps 🐢 et en mémoire 🐘.

👉 Voir par exemple le wrapper JavaScript ou celui Python.

Pour les utilisateurs finaux

⚠️ Utiliser un gestionnaire de mots de passe comme https://keepass.info/ ou https://keepassxc.org/. ⚠️

Extrait du rapport d’audit de Zaur Molotnikov.

KeePassXC provides sufficient cryptographic protection (confidentiality, integrity and authenticity) to the confidential information the user is storing in the database, given that the user selects a strong authentication method.

🚨 Problème majeur des systèmes à clefs publiques : l’authentification. 🚨

On peut transmettre les clefs publiques sur un canal non sûr pour ensuite établir un canal sécurisé (en choisissant une clef secrète commune aux parties), mais comment assurer effectivement qu’il s’agit du bon interlocuteur ? 🤔

Certificats

🔏 Les certificats (X509) capturent les relations de la forme A dit que K est bien la clef publique de B. Un certificat contient :

• L’identité du certificateur.
• L’identité du certifié.
• La clef publique du certifié.
• La date d’émission et la date limite de validité.
• Numéro de série, algorithmes utilisés, etc.
• La signature des contenus précédents avec la clef (secrète !) du certificateur.

🤔 Comment avoir confiance dans le certificateur ?

Solution 1, distribuée, à la https://gnupg.org/

• Chacun crée son propre certificat qu’il signe lui-même.
• Chacun certifie qui il veut avec différent niveau de confiance.
  • Cela crée un réseau de confiance.
• On décide individuellement si on a assez de recommandations pour valider une identité.

Solution 2, centralisée

• Chacun fait confiance à une liste de tiers (dits, de confiance).
• Ces autorités de certification se certifient elles-mêmes (racine) et entre-elles.
  • ce sont les seules du réseau à le faire ;
• Les autorités délèguent pour créer des chaînes de certification.
  • Elles sont les racines de la forêt des relations de délégations.

🤯 Et à la racine, à quelles autorités fait-on confiance, implicitement ?! 🤯

👉 Voir Mozilla Included CA Certificate List qui fait de remarquables efforts de transparence à ce sujet.

Création de certificat / PKI

Chaîne de certification

Certificat auto-signé (racine)

    Data:
        Version: 3 (0x2)
        Serial Number:
            11:75:4f:19:da:09:eb:08:00:40:77:e9:6d:20:60:4f:39:73:60:1c
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = FR, ST = Some-State, O = UCBL, CN = TIW4
        Validity
            Not Before: Sep 12 12:10:30 2020 GMT
            Not After : Sep 12 12:10:30 2021 GMT
        Subject: C = FR, ST = Some-State, O = UCBL, CN = TIW4
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
         ...

🗒️ Généralement de longue durée, avec des clefs de grandes tailles.

💡 La gestion des clefs est un problème difficile et technique, voir par exemple https://pki-tutorial.readthedocs.io/en/latest/ pour la mise en place de PKI – Public Key Infrastructures avec OpenSSL.

🧑‍⚖️ Le problème de la révocation en particulier, via les Certificate Revocation List – CRL ou mieux, via Online Certificate Status Protocol – OCSP.

Don’t roll your own crypto

Cryptanalyse “traditionnelle”

Maintenance et dépendance logicielle

Plus récemment, l’exemple de l’attaque sur xz :

🔖 Timeline of the xz open source attack et Everything I know about the XZ backdoor.