Sécurité informatique et cryptographie

Chapitre 1 — Introduction à la sécurité

1.1) Différents types de risques

• Accès non autorisé aux ressources/services restreints.
• Usurpation d'identité.
• Accès à des données confidentielles.
• Falsification / contrefaçon.

1.2) Système qui fonctionne : Propriétés essentielles

Un système est fonctionnel s'il garantit :

• Disponibilité : Le système est opérationnel et accessible.
• Authentification : Vérifier l'identité des utilisateurs ("Qui est qui ?").
• Autorisation : Définir les droits d'accès ("Qui peut faire quoi ?").
• Responsabilité : Assurer la traçabilité des actions ("Qui a fait quoi ?").
• Intégrité : Détecter et prévenir les modifications malveillantes des données.
• Confidentialité : Protéger les données contre la divulgation non autorisée.

1.3) Attaque DDOS (Distributed Denial of Service)

Objectif : Surcharger un service pour le rendre indisponible.

Étapes clés d'une attaque DDOS :

1. Infection : Un attaquant infecte des PC qui deviennent des "zombies" ou "bots".
2. Contrôle : L'attaquant contrôle les zombies via un "botnet".
3. Attaque coordonnée : Les zombies envoient des milliers de requêtes (ex: "AlgaVent") à la cible.
4. Surcharge : Le serveur cible est submergé par les requêtes et finit par s'arrêter.

1.4) Authentification

Principe : Empêcher l'accès universel. Les prototypes et droits (rôle, mode, gestion de groupe, utilisateur) définissent ce qui est accessible par chacun.

1.5) Responsabilité

• Tout enregistrer dans des logs (connexion, activité, etc.).
• Ne pas mettre d'informations confidentielles dans les logs.
• Stocker les logs sur un serveur différent de celui du backend.
• Séparation des devoirs : La personne qui gère les logs ne doit pas pouvoir les modifier, et une personne doit les auditer régulièrement. Ceci assure que même si le système est compromis, les logs restent intacts.

1.6) Intégrité

Assurer que les données ne soient pas modifiées. Il faut protéger le système contre les modifications, falsifications, manipulations. La falsification ne peut pas toujours être empêchée, mais la détection est possible et cruciale !

1.7) Cryptographie VS Stéganographie

• Cryptographie : Transformer l'information pour la rendre illisible sans une clé (« Info cryptée »). Aujourd'hui, c'est la méthode privilégiée.
• Stéganographie : Cacher l'information elle-même, de sorte que son existence ne soit pas soupçonnée (« Cacher l'info »).

1.8) Résumé

Le secret est une faiblesse (ex: un code source open source est souvent plus sécurisé car audité par la communauté). Il faut être vigilant face aux attaques et lutter contre les vulnérabilités ('failles').

Chapitre 2 — Cryptographie & Hashage

2.1) Fonction de Hashage

Processus d'assignation de valeurs à des clés, créant une empreinte numérique unique (une "trace" ou "signature" des données).

• Un hash est unidirectionnel ("one-way") : facile à calculer dans un sens, difficile (voire impossible en pratique) à inverser.
• La sortie d'un hash a toujours une taille identique/constante, indépendamment de la taille de l'entrée.
• Une fonction de hachage efficace produit un hashage unique pour chaque entrée, permettant de détecter la moindre modification.

2.2) Algorithme de chiffrement

Un algorithme de chiffrement est bidirectionnel ("two-way") : il permet de chiffrer et de déchiffrer avec la clé appropriée.

Problème :

Parfois, la quantité de données à chiffrer est trop grande pour être traitée en une seule fois (problème de performance ou de ressources).

Pourquoi ne pas utiliser un buffer (tampon) ?

1. Risque d'attaque DDOS.
2. Un buffer trop grand est difficile à contrôler.
3. Trop coûteux et ne procure pas de protection supplémentaire.

Solution : Chiffrer par morceaux (blocs ou flux)

• Chiffrement par blocs (ex: AES) : Les données sont découpées en blocs de taille fixe et chiffrées bloc par bloc.
• Chiffrement par flux (ex: RC4) : Les données sont chiffrées bit par bit ou octet par octet.

2.3) Effet Avalanche

Un changement minime dans l'entrée (ex: 1 bit) provoque un changement massif dans la sortie (environ 50% des bits changent). Cela rend l'algorithme impossible à prédire ou à inverser.

2.4) Mots de passe

On ne stocke JAMAIS un mot de passe en clair dans la base de données !

Solution : Stocker son hash

Processus :

1. L'utilisateur envoie son mot de passe (chiffré par TLS).
2. Le serveur :
   1. Déchiffre le mot de passe.
   2. Calcule son hash.
   3. Vérifie la correspondance avec le hash stocké.

Fonction de hash :

• Ne possède pas de clé, pas de secret.
• Les algorithmes sont publics, ce qui les rend pratiques et auditable.

Détail important :

Les hashs ont un nombre fixe de sorties. Il peut y avoir des collisions (deux entrées différentes produisant le même hash). L'objectif n'est pas de les éviter à tout prix, mais de les détecter et de les rendre difficiles à créer intentionnellement.

Jamais chiffrer un mot de passe : cela implique que l'administrateur aurait la clé de déchiffrement, ce qui est une faille de sécurité majeure.

2.5) Merkle-Damgård Construction

Méthode pour construire des fonctions de hachage à partir de fonctions de compression.

1. Découpage : Le message original est découpé en blocs de taille fixe.
2. Padding : Le dernier bloc est complété si nécessaire.
3. Initialisation : On commence à hacher le premier bloc, ce qui produit un hash intermédiaire.
4. Itération : Le hash du bloc précédent est combiné avec le bloc courant pour calculer le hash suivant, et ce processus se répète jusqu'à la fin.
5. Finalisation : L'effet avalanche est appliqué au dernier bloc pour détecter les modifications.

2.6) Attaque Anniversaire

Attaque exploitant la théorie des probabilités (paradoxe des anniversaires) pour trouver des collisions de hash. Il est plus facile de trouver deux personnes ayant le même anniversaire dans un groupe de 23 personnes que de trouver une personne ayant le même anniversaire qu'une personne spécifique.

2.7) Algorithme de chiffrement : Types

Rendre un message illisible sans la clé appropriée.

1. Chiffrement symétrique :

• Utilise la même clé pour chiffrer et déchiffrer.
• Exemple : AES.

2. Chiffrement asymétrique :

• Utilise une paire de clés :
  • Une clé publique (peut être partagée).
  • Une clé privée (doit rester secrète).
• On ne peut pas retrouver une clé privée à partir d'une clé publique.
• Exemple : RSA, Diffie-Hellman.

2.8) Le Salt (Sel)

• Une valeur aléatoire unique ajoutée à un mot de passe avant d'être haché.
• Chaque utilisateur aura un salt unique, même si le mot de passe est identique.
• Protège contre les attaques par dictionnaire et par tables arc-en-ciel (rainbow tables), en rendant chaque hash unique et en forçant une attaque par brute force pour chaque mot de passe salé.

2.9) Clés asymétriques

• Fonctionne par paire de clés : une pour chiffrer, une pour déchiffrer.
• Exemple : Alice chiffre avec la clé publique de Bob, Bob déchiffre avec sa clé privée.

Problème :

• L'échange initial de clés publiques.
• La complexité et le temps nécessaire pour chiffrer des grandes quantités de données.

2.9.1) RSA Key Exchange (Échange de clés RSA)

1. Alice génère une clé symétrique de session (rapide).
2. Alice chiffre cette clé de session avec la clé publique de Bob.
3. Bob reçoit le message chiffré et déchiffre la clé de session avec sa clé privée.
4. Alice et Bob utilisent ensuite cette clé de session symétrique pour échanger les messages.

Avantage :

Plus rapide pour échanger de grandes quantités de données une fois la clé de session établie.

Inconvénient :

Si la clé privée de Bob est compromise, un attaquant peut intercepter et déchiffrer tous les messages chiffrés avec cette clé de session.

2.10) Signature numérique

Permet d'authentifier l'expéditeur d'un message et de prouver que son contenu n'a pas été modifié après l'envoi.

1. L'expéditeur hache le message.
2. Il chiffre le hash avec sa clé privée (c'est la signature).
3. Il envoie le message et la signature.
4. Le destinataire hache le message reçu.
5. Il déchiffre la signature avec la clé publique de l'expéditeur.
6. Si les deux hashs correspondent, le message est authentique et intègre.

Chapitre 3 — Confiance, consensus et PKI

3.1) Consensus

Le consensus est un accord général sur l'état d'un système ou sur des informations critiques, comme l'authenticité des clés et des signatures.

• Objectif : Retrouver les clés publiques de leurs propriétaires et confirmer l'identité des utilisateurs.
• Les modèles de consensus de base cherchent à assurer un accord même face à des acteurs malveillants ou des pannes.

3.2) Homme du Milieu (Man-in-the-Middle - MITM)

Une attaque où un attaquant intercepte la communication entre deux parties qui pensent communiquer directement.

• L'attaquant peut lire, modifier, ou injecter des messages.
• Il se fait passer pour la partie A auprès de la partie B, et pour B auprès de A.

3.3) Principe de confiance & Autorités de Certification

La sécurité repose sur un certain niveau de confiance.

• On fait confiance à des tiers, les Autorités de Certification (CA).
• Les CA sont des entités qui émettent des certificats numériques.

3.4) Certificats et PKI (Public Key Infrastructure)

Les certificats numériques sont des "cartes d'identité" électroniques qui lient une clé publique à l'identité de son propriétaire.

La PKI est l'ensemble des règles, politiques, services et technologies nécessaires pour l'émission, la gestion et la révocation des certificats.

Exemple d'erreur CA :

Une CA doit être digne de confiance. Si une CA émet des certificats frauduleux ou est compromise, toute la chaîne de confiance est brisée.

3.4.2) Demande de signature de Certificat (CSR)

Un utilisateur génère une clé privée et une clé publique, puis crée une demande de certificat (CSR) contenant sa clé publique et son identité. Cette CSR est envoyée à une CA pour signature.

3.4.3) Démarches des certificats :

Les certificats ont une durée de validité limitée (ex: 2 mois). Ils doivent être régulièrement renouvelés ou révoqués s'ils sont compromis.

Chapitre 4 — Authentification & Contrôle d'accès

4.1) Différents types d'authentification

L'authentification consiste à vérifier l'identité d'un utilisateur ou d'une entité.

1. Ce que l'on sait :

• Mot de passe, PIN, phrase secrète.

2. Ce que l'on possède :

• Clé USB, carte à puce, jeton physique, smartphone.

3. Ce que l'on est :

• Empreinte digitale, reconnaissance faciale, iris, voix (biométrie).

4. Ce que l'on fait :

• Manie du clavier, signature, démarche (analyse comportementale).

5. Où l'on est :

• Localisation géographique, données GPS.

4.1.1) Authentification Multi-Facteurs (MFA)

Utilise au moins deux des facteurs d'authentification (ce que l'on sait, possède, est, etc.) pour renforcer la sécurité. Par exemple, mot de passe + code envoyé par SMS.

4.1.2) Appareils d'authentification / Jetons (Tokens)

Dispositifs physiques ou logiciels (ex: Google Authenticator) générant des codes uniques et temporaires (TOTP).

4.1.14) Salage des mots de passe

Chaque utilisateur a son propre sel public, garantissant que même si deux utilisateurs ont le même mot de passe, leurs hashs seront différents.

4.4) Contrôle d'accès (EOT)

Détermine ce que l'utilisateur authentifié est autorisé à faire (autorisation).

• Exemples : contrôle d'accès basé sur les rôles (RBAC), contrôle d'accès discrétionnaire (DAC), contrôle d'accès obligatoire (MAC).

Chapitre 5 — Sécurité Réseau & Protocoles

5.1) TLS (Transport Layer Security)

Protocole essentiel pour sécuriser les communications sur Internet (ex: HTTPS). TLS offre :

• Confidentialité : Chiffrement des données.
• Intégrité : Vérification que les données n'ont pas été altérées.
• Authentification : Le serveur est authentifié via un certificat signé par une CA (grâce à la PKI).
• Protection contre le rejet (non-répudiation) : Prouve l'origine des données.

Crée un "tunnel sécurisé" entre un client et un serveur.

5.2) Onion Network (Ex: Tor)

Réseau qui permet une navigation anonyme en acheminant le trafic à travers de multiples "nœuds" (relais).

• Deep Web : Contenu non indexé par les moteurs de recherche traditionnels, accessible via URL/IP directe (pas nécessairement illicite).
• Dark Web : Partie du Deep Web accessible uniquement via des réseaux anonymes comme Tor (Onion Network), souvent associé à des activités illicites mais offrant aussi une forte protection de la vie privée.

Fonctionnement d'Onion :

1. Le client demande la liste des nœuds de confiance (directory).
2. Le client construit un chemin de plusieurs nœuds (min. 3) pour atteindre le serveur cible.

> Impossible de faire de l'analyse de trafic : les nœuds ne connaissent ni l'expéditeur réel ni le destinataire final. Chaque nœud ne connaît que le nœud précédent et le nœud suivant.

5.3) Firewall (Pare-feu)

Système de sécurité qui gère et filtre le trafic réseau entrant et sortant. Il peut déclencher des alertes ou bloquer du contenu.

Types de Firewalls :

1. Firewall Basique (filtrage par paquets) :
   • Règles fixes basées sur IP source/destination, port, protocole, etc.
   • Peu coûteux, faible latence, faible consommation.
2. Stateful Firewall :
   • Connaît l'état des connexions (sessions).
   • Plus intelligent, mais plus coûteux et plus de latence.
3. Firewall Applicatif (WAF) :
   • Filtre le contenu au niveau applicatif (HTTP, FTP).
   • Utilise l'IA pour l'analyse comportementale et le contrôle d'accès.
   • Très puissant, mais très coûteux, grande latence, forte consommation.
4. Next-Generation Firewall (NGFW) :
   • Intègre toutes les fonctionnalités précédentes + détection d'intrusion, isolation du trafic, tests en VM.
   • Extrêmement coûteux et complexe.

5.4) Topologie Réseau & Sécurité

La conception du réseau est fondamentale pour la sécurité.

• Réseaux / Sous-réseaux : Segmentation pour isoler les domaines de confiance.
• Détection d'Hardware Rogue : Identifier les équipements non autorisés.
• DMZ (Demilitarized Zone) : Zone réseau isolée pour les serveurs publics (web, mail) afin de les protéger du réseau interne.

> À retenir : Toujours tout fermer ce qui n'est pas nécessaire (ports, prises, etc.). Blacklister par défaut et autoriser explicitement si besoin.

> Mentalité Zero-Trust : Ne faire confiance à personne, vérifier chaque connexion et utilisateur, même à l'intérieur du réseau.

5.5) Authentification Réseau (RADIUS)

RADIUS (Remote Authentication Dial-In User Service) est un serveur qui joue le rôle de AAA (Authentification, Autorisation, Comptabilité) dans un réseau local.

• Vérifie qui a le droit de se connecter et quels accès il a.
• Souvent utilisé avec le protocole 802.1X et un tunnel TLS.

Étapes d'authentification RADIUS :

1. Supplicant : L'appareil demande l'accès au réseau.
2. Authenticator : Un équipement réseau (point d'accès, switch) renvoie la demande au serveur AAA (RADIUS).
3. Serveur d'authentification (RADIUS) :
   • Le client envoie une requête EAP.
   • Le serveur répond EAP-REQUEST/ACCESS-REJECT et indique si EAP-TLS sera utilisé.
4. Ouverture des ports réseau : Si l'authentification réussit.

5.6) DNS Security (DNSSEC)

Attaque DNS classique : un pirate redirige le trafic vers des IPs frauduleuses en envoyant des enregistrements DNS falsifiés.

Cas d'attaques DNS :

1. Système infecté : Le pirate modifie le cache DNS local de la victime.
2. Enregistrements falsifiés : Le pirate envoie de faux enregistrements DNS à un Resolver ciblant des domaines légitimes.

> DNSSEC (Domain Name System Security Extensions) est une norme qui ajoute des signatures cryptographiques aux données DNS, créant une chaîne de confiance pour garantir l'authenticité et l'intégrité des réponses DNS.

Organisation du DNS en zones et chaîne de confiance DNSSEC :

• Le DNS est organisé hiérarchiquement en zones (racine ".", .be, esi-bru.be...).
• Chaque zone possède des clés pour signer ses enregistrements (ZSK - Zone Signing Key).
• La clé publique d'une zone est placée chez son parent (ex: esi-bru.be chez .be).
• Le parent signe la clé publique de l'enfant avec sa propre clé privée (KSK - Key Signing Key).
• Cela forme une chaîne de confiance depuis la racine.

5.7) DNSSEC : Principe de vérification

Le principe est de suivre la chaîne de confiance depuis la racine DNS jusqu'au domaine final.

À chaque étape :

• Le resolver récupère les enregistrements et les clés publiques de la zone.
• Il vérifie les signatures en utilisant la clé publique du parent.

Processus de résolution avec DNSSEC :

1. Le client demande l'IP d'un domaine (ex: poesi.esi-bru.be) à son resolver local.
2. Le resolver, inconnu, interroge un serveur racine.
3. Le serveur racine renvoie la liste des serveurs .be et signe sa réponse. Le resolver vérifie cette signature avec la clé racine préalablement connue et digne de confiance.
4. Même principe pour interroger les serveurs .be, puis esi-bru.be, jusqu'à poesi.esi-bru.be.
5. Une fois toutes les signatures vérifiées, le resolver sait que la réponse n'a pas été modifiée et renvoie l'IP au client avec la garantie d'authenticité DNSSEC.

> Note pratique : En réalité, ce sont les hashs des clés qui sont signés pour des raisons de performance et de stockage. La logique est similaire au stockage sécurisé des mots de passe.