Lucky 13.

Lucky 13 (CVE-2013-0169) a ete divulgue en fevrier 2013 par Nadhem AlFardan et Kenny Paterson de l'Information Security Group de Royal Holloway, Universite de Londres. C'est une variante par canal temporel de l'attaque par oracle de padding de Serge Vaudenay (2002) ; elle vise toutes les suites CBC de SSL 3.0 et TLS 1.0–1.2 (et DTLS), qui utilisent MAC-then-encrypt avec HMAC.

Le nombre 13 designe les octets constants d'en-tete TLS et de numero de sequence couverts par le MAC. Comme HMAC-SHA1 traite les donnees par blocs de 64 octets, le nombre d'appels a la fonction de compression — donc le temps de verification — depend du nombre d'octets de padding du record. Un attaquant man-in-the-middle qui injecte des chiffres forges mesure ces ecarts de l'ordre de la sous-microseconde sur de nombreux essais pour savoir si le texte clair suppose a produit un padding valide, reconstruisant octet par octet comme BEAST ou POODLE. Les resultats d'origine recuperaient le texte clair complet en DTLS et des octets partiels en TLS, demontres sur OpenSSL et GnuTLS.

Les contre-mesures a temps constant — calculer toujours un nombre fixe de blocs HMAC — ont ete livrees dans OpenSSL 1.0.1d, GnuTLS et NSS. Le correctif durable consiste a abandonner CBC au profit des suites AEAD comme AES-GCM et ChaCha20-Poly1305, imposees par TLS 1.3.

flowchart TD
  A[Le MITM injecte un record TLS-CBC forge] --> B[Le serveur dechiffre et retire le padding]
  B --> C{Longueur du padding}
  C -->|plus de padding| D[Moins de blocs HMAC-SHA1 - plus rapide]
  C -->|moins de padding| E[Plus de blocs HMAC - plus lent]
  D --> F[L'attaquant mesure le temps de verification du MAC]
  E --> F
  F --> G[Statistiques sur des millions d'essais]
  G --> H[L'oracle de padding recupere un octet de texte clair]