Les données existent dans trois états fondamentaux. En transit : lorsqu'elles voyagent d'un point A à un point B sur le réseau. Au repos : lorsqu'elles dorment sur un disque dur, dans une base de données, dans le cloud. En traitement : lorsqu'un processeur les manipule activement, les calcule, les compare. Pendant des décennies, nous avons maîtrisé les deux premiers. Le troisième était l'angle mort de la cryptographie — et c'est précisément là que se jouent les attaques les plus sophistiquées.
Premier état : données en transit
TLS 1.3 est devenu le standard incontournable. Par rapport à son prédécesseur TLS 1.2, il supprime les suites de chiffrement vulnérables (RC4, MD5, SHA-1), réduit la latence du handshake à un seul aller-retour, et impose le Perfect Forward Secrecy — ce qui signifie que compromettre la clé privée du serveur aujourd'hui ne permet pas de déchiffrer des communications passées capturées.
Au-delà du protocole, trois pratiques renforcent la sécurité en transit :
- HSTS (HTTP Strict Transport Security) avec le flag preload : force les navigateurs à ne jamais accéder au site en HTTP, même lors du premier accès.
- Certificate Pinning : dans les applications mobiles, liez l'application à un certificat ou une clé publique spécifique. Un certificat frauduleux — même émis par une CA de confiance compromise — sera rejeté.
- mTLS (mutual TLS) : authentification bidirectionnelle. Indispensable dans les architectures microservices : chaque service prouve son identité à l'autre avant d'établir la connexion.
Le vecteur d'attaque principal reste le man-in-the-middle : interception, réécriture ou rejeu du trafic. TLS 1.3 + HSTS + certificate pinning ferment la quasi-totalité de cette surface.
Deuxième état : données au repos
AES-256-GCM (Advanced Encryption Standard, mode Galois/Counter) est le standard de référence. Il combine chiffrement et authentification des données — ce qui signifie qu'une modification des données chiffrées sera détectée à la décryption. C'est ce qu'on appelle le chiffrement authentifié.
Plusieurs niveaux de protection au repos méritent attention :
- Chiffrement du disque : LUKS (Linux), BitLocker (Windows), FileVault (macOS). Protège contre le vol physique du support. Transparent pour l'application.
- Chiffrement de la base de données : Transparent Data Encryption (TDE) dans MySQL/PostgreSQL. Protège les fichiers de données mais pas contre un attaquant ayant accès au SGBD en fonctionnement.
- Chiffrement au niveau colonne : les données sensibles (numéros de carte, identifiants nationaux) sont chiffrées avant insertion. Même un accès DBA ne donne pas accès aux données en clair. La clé est gérée séparément.
- Gestion des clés : c'est le maillon critique. Un HSM (Hardware Security Module) ou un KMS cloud (AWS KMS, GCP Cloud KMS) isole les clés du reste de l'infrastructure. La règle d'or : ne jamais stocker clé et données chiffrées au même endroit.
Une erreur fréquente : chiffrer les données mais laisser les clés dans le même dépôt Git, la même base de données, ou le même fichier de configuration. Le chiffrement sans gestion des clés est une illusion de sécurité.
Troisième état : données en traitement — l'angle mort
Voici le problème fondamental : pour traiter une donnée, un processeur doit la voir en clair. Dès qu'une donnée entre en mémoire RAM pour être calculée, elle est — au sens strict — exposée. Un adversaire avec accès à la mémoire physique (DMA attack), à l'hyperviseur d'une VM cloud, ou à un processus root compromis peut la lire.
Deux approches émergent pour résoudre ce problème :
1. Le Confidential Computing (TEE — Trusted Execution Environment)
Intel SGX, AMD SEV, et ARM TrustZone créent des enclaves matérielles isolées — des zones de mémoire chiffrées par le processeur lui-même, inaccessibles même au système d'exploitation ou à l'hyperviseur. Le code et les données dans l'enclave sont protégés. Microsoft Azure Confidential Computing, Google Cloud Confidential VMs et AWS Nitro Enclaves s'appuient sur ces technologies.
Cas d'usage concret : un hôpital peut envoyer des données patient chiffrées à un cloud externe pour analyse IA, sans jamais exposer les données en clair au fournisseur cloud. L'analyse se fait dans l'enclave.
2. Le Chiffrement Homomorphe (FHE — Fully Homomorphic Encryption)
Le FHE est conceptuellement révolutionnaire : il permet d'effectuer des calculs directement sur des données chiffrées, sans jamais les déchiffrer. Le résultat, une fois déchiffré, est identique à ce qu'on aurait obtenu en calculant sur les données en clair. f(Enc(x)) = Enc(f(x)).
Un exemple parlant : une banque peut vérifier si votre score de crédit dépasse un seuil, sans jamais voir votre score. Le calcul se fait sur la version chiffrée. Seul vous pouvez déchiffrer le résultat binaire (oui/non).
La limite actuelle du FHE : la performance. Les opérations FHE sont entre 1 000 et 1 000 000 fois plus lentes que leurs équivalents en clair. Les bibliothèques comme TFHE, OpenFHE et Microsoft SEAL progressent rapidement, mais le FHE reste cantonné à des cas d'usage spécifiques à haute valeur.
La menace qui change tout : l'informatique quantique
Les ordinateurs quantiques — via l'algorithme de Shor — pourront factoriser les grands entiers exponentiellement plus vite qu'un ordinateur classique. RSA et ECC (Elliptic Curve Cryptography), les fondements du chiffrement asymétrique moderne, seront brisés. TLS lui-même repose sur ces algorithmes pour l'échange de clés.
La riposte est en cours. Le NIST a standardisé en 2024 les premiers algorithmes post-quantiques : CRYSTALS-Kyber pour l'encapsulation de clés, CRYSTALS-Dilithium et FALCON pour les signatures numériques. Ces algorithmes reposent sur des problèmes mathématiques résistants aux attaques quantiques (réseaux euclidiens).
La stratégie recommandée dès aujourd'hui : architecture crypto-agile. Séparez les algorithmes de chiffrement du reste du code de manière à pouvoir les remplacer sans refactoring massif. L'échéance quantique est incertaine, mais les systèmes déployés aujourd'hui devront survivre jusqu'à cette menace.
Ce que cela signifie concrètement pour une fintech africaine
Les trois états du chiffrement ne sont pas des considérations académiques. Pour une plateforme comme Séko — qui séquestre des fonds entre parties — la compromission d'une transaction au repos ou en transit peut être catastrophique. La réalité du contexte UEMOA ajoute une contrainte : infrastructure cloud mixte, protocoles mobiles (USSD, mobile money APIs), interfaces parfois en HTTP faute de certificat valide.
La priorité immédiate : TLS 1.3 partout, gestion des clés externalisée dès que possible, chiffrement colonne pour les données financières sensibles. Le FHE et le TEE sont des horizons à planifier. La crypto-agilité, une décision d'architecture à prendre dès aujourd'hui.