Contexte et motivation

L’auteur du projet badcert critique la complexité du processus ACME et la rotation fréquente des certificats TLS. Il propose une alternative de « protest certificate » où le seul élément contrôlable est la clé publique. En modifiant le module n d’une clé RSA, il insère un texte lisible dans le certificat sans toucher aux exigences de validation du serveur.

Mécanisme de génération de la clé vanity

Le schéma RSA standard utilise deux grands nombres premiers p et q pour former le module n = p·q. L’exposant public habituel est e = 65537 (0x10001) car il possède peu de bits à 1, ce qui accélère le chiffrement. L’auteur commence par choisir aléatoirement p, calcule n, puis modifie les octets supérieurs de n afin d’y placer le texte souhaité. Cette modification rend n non factorisable directement, mais il suffit de recomposer q = n / p. Comme q n’est généralement plus premier, il est arrondi puis incrémenté jusqu’à atteindre le prochain nombre premier, ce qui ne change que la moitié basse du produit.

# Exemple de multiplication et d’ajustement
58174124 * 918491824 = 53432457262362176
# après incrément jusqu’au prochain premier
58174124 * 918491843 = 53432458367670532

Le texte est placé dans la moitié haute de n afin qu’il survive aux petits ajustements de q. Pour une clé RSA‑2048, le module fournit environ 150 caractères base64 exploitables ; pour RSA‑4096, ce nombre monte à ~320 caractères, offrant largement d’espace pour des blagues ou des slogans.

Intégration dans le processus ACME

Une fois p et le q ajusté, l’auteur crée une paire RSA fonctionnelle et génère une CSR (Certificate Signing Request). Le CSR est soumis à une autorité de certification via le flux ACME habituel :

# génération d’une clé et d’une CSR
openssl req -new-key priv.pem -subj '/C=US/CN=example.com' -out cert_request
certbot certonly --manual --csr cert_request

Le texte caché apparaît dans le champ BEGIN CERTIFICATE du certificat délivré, visible avec openssl s_client et un filtre sed qui recherche le motif « ////…//// ».

Analyse de la sécurité et des limites

Modifier la moitié supérieure du module réduit l’entropie disponible. Le projet estime une perte d’environ 50 % d’entropie, voire 66 % selon les travaux de compression de clés RSA. Malgré cette réduction, la clé reste pratiquement sûre : la partie inférieure, qui change lors de l’ajustement de q, conserve suffisamment de bits aléatoires pour résister aux attaques classiques de factorisation. Cependant, la sécurité dépend de la taille du module ; une RSA‑2048 avec moitié supérieure fixe est nettement plus faible qu’une RSA‑4096 équivalente. De plus, la méthode repose sur la volonté de l’autorité de certification d’accepter un exposant e standard, ce qui n’est pas garanti pour tous les CAs.

En résumé, le projet démontre qu’il est possible d’insérer des messages visibles dans la clé publique d’un certificat TLS sans rompre la chaîne de confiance, tout en conservant une sécurité acceptable pour des usages non critiques. La technique expose toutefois les compromis entre liberté d’expression et robustesse cryptographique.