Nathaniel Borenstein et l'encodage Base64 qui n'a jamais promis la confidentialité

Résumé

• Dans MIME, Base64 rend un corps transportable et réversible ; il ne le chiffre pas et n'atteste ni son origine, ni son intégrité, ni sa sûreté.
• Une preuve exploitable conserve la forme reçue, le périmètre MIME, le profil de décodage, les octets produits et les contrôles de sécurité séparés.

Lors d'une migration d'archives, deux pièces jointes obtiennent des empreintes différentes avant décodage. L'une contient des retours à la ligne supplémentaires ; l'autre non. Après décodage, leurs octets sont identiques. L'équipe conclut d'abord à une altération, puis comprend qu'elle comparait des emballages de transport. Le lendemain, elle commet l'erreur inverse : elle déduit de l'identité des octets que les deux messages ont la même origine.

MIME permet précisément d'éviter ces raccourcis. Le profil IETF de Nathaniel Borenstein lui attribue notamment les RFC 2045, 2046 et 2049. La notice publiée par Grinnell College en 2013 rappelle ses travaux chez Bellcore et le premier message MIME de 1992, avec une photographie et un fichier sonore. Cette innovation répondait à un problème d'interopérabilité : faire traverser à des données variées une messagerie conçue pour un univers plus étroit.

Une transformation, pas un sceau

La RFC 2045 donne au champ Content-Transfer-Encoding deux fonctions. Il indique la transformation appliquée au corps et le domaine de la représentation obtenue. 7bit, 8bit et binary ne transforment rien ; quoted-printable et Base64 ramènent des données dans un espace compatible avec un transport 7 bits.

Pour une séquence valide, le mécanisme impose un résultat de décodage bien défini, ou constate que la séquence est illégale. Cette propriété permet de récupérer les octets. Elle ne désigne pas leur auteur et ne leur attribue pas de niveau de confiance. La RFC ajoute que plusieurs encodages équivalents peuvent être produits et que le nom du transfert n'établit pas le type du média.

Une trace decode=success répond donc à une question étroite : ce décodeur, sous ces règles, a accepté cette représentation. Elle ne signifie ni « document authentique », ni « contenu confidentiel », ni « programme autorisé ».

Le périmètre se trouve dans l'entité MIME

L'interface montre souvent un message et sa pièce jointe comme deux objets simples. La structure MIME est pourtant imbriquée. Un champ de transfert placé dans l'en-tête du message porte sur son corps ; placé dans une entité, il ne porte que sur le corps de cette entité. Les types composites multipart et message imposent leurs propres restrictions.

Il faut donc distinguer l'empreinte du message brut, celle du segment encodé et celle des octets décodés. Une passerelle peut replier un en-tête ou modifier des fins de ligne sans changer la charge utile finale. Deux envois distincts peuvent aussi aboutir au même fichier. Conserver uniquement le résultat efface le chemin ; conserver uniquement l'enveloppe empêche de comparer le contenu réel.

Le type de média appartient encore à une autre couche. La RFC 2046 recommande une conduite prudente pour application/octet-stream : retirer l'encodage de transfert, puis proposer d'enregistrer les données ou de les transmettre à un traitement choisi par l'utilisateur. Décoder n'est pas exécuter. Une extension de fichier ou un Content-Type reste une déclaration à confronter à une politique de manipulation.

Le mot Base64 ne suffit pas

La RFC 4648 explique pourquoi un profil explicite est nécessaire. Selon la spécification appelante, les retours à la ligne, le bourrage =, les caractères hors alphabet et même l'alphabet peuvent être traités différemment. MIME autorise certains caractères ignorés ; un autre protocole peut exiger le rejet. Base64url emploie un alphabet distinct et ne doit pas être confondu avec Base64.

La forme canonique compte également. Des bits de bourrage non nuls peuvent permettre à plusieurs chaînes de représenter les mêmes octets. Les caractères ignorés peuvent servir de canal caché, contourner une comparaison textuelle ou déclencher un défaut d'implémentation. Ainsi, l'empreinte des seuls octets décodés ne prouve pas que l'entrée était canonique ; l'empreinte de la seule chaîne ne prouve pas que le contenu différait.

Un registre sérieux note le profil, la version du décodeur et sa politique. Sans cela, un durcissement futur peut transformer silencieusement une entrée acceptée en rejet, tandis que les anciens journaux continuent d'afficher le même mot « Base64 ».

Voir moins ne signifie pas protéger

La section sécurité de la RFC 4648 est directe : l'encodage de base peut rendre une information moins reconnaissable à l'œil, mais n'apporte aucune confidentialité calculatoire et n'ajoute aucune entropie au texte clair. Il n'existe ni clé secrète, ni contrôle d'accès. Toute personne disposant de la représentation peut tenter le décodage.

L'intégrité et l'authenticité ne viennent pas davantage de l'alphabet. Une empreinte prouve une égalité avec une valeur connue, pas l'identité de celui qui l'a fournie. Une signature ou un MAC lie des octets à une clé selon des règles données ; la légitimité de cette clé reste une décision distincte. Le chiffrement authentifié peut protéger une charge, mais Base64 ne prouve pas qu'il a été appliqué.

Dire cela ne rabaisse pas MIME. Une bonne couche technique refuse justement les pouvoirs qu'elle n'a pas. Le danger apparaît dans les applications qui transforment décodé en vérifié, ou utilisent Base64 comme méthode de masquage dans un journal accessible.

Le reçu à six étages

Le reçu opérationnel devrait d'abord conserver l'empreinte de la représentation reçue et les limites exactes de l'entité. Il nomme ensuite le profil applicable. Il consigne la politique du décodeur — espaces, caractères étrangers, bourrage — puis le résultat et l'empreinte des octets. Une cinquième étape applique les règles de type et de manipulation sans exécution automatique. La dernière rattache séparément signature, chiffrement, authentification du transport et autorisation.

Une case vide est informative. Si aucune signature n'a été contrôlée, le registre ne doit pas convertir la réussite du décodage en validation implicite. Si seule une liaison TLS a protégé un tronçon, cette portée limitée doit rester visible.

Le succès de MIME vient de frontières explicites entre des fonctions qui devaient coopérer. La même méthode protège aujourd'hui les décisions : Base64 atteste une représentation réversible dans un cadre donné, et rien au-delà.