Un navigateur peut exécuter une cryptographie robuste ; il faut néanmoins faire confiance au code qui lui est livré.
Un navigateur peut effectuer localement un chiffrement de bout en bout, y compris l’établissement de clés post-quantique, sans installer d’application native de messagerie. La question difficile n’est pas de savoir si les mathématiques peuvent s’exécuter dans un onglet. Elle est de savoir si l’application livrée, la gestion des clés et le mécanisme de mise à jour méritent la confiance qu’exige la conversation.
Un accès web peut être pratique lorsqu’une installation est impossible. Il ne rend pas l’application insensible à la censure, à un hébergement compromis, aux extensions malveillantes ou à un appareil compromis.
Les briques cryptographiques du navigateur
WebCrypto expose des opérations de bas niveau pour le chiffrement, la dérivation de clés, la signature et la gestion des clés. Les implémentations courantes fournissent des primitives comme AES-GCM et ECDH. Ces opérations sont des briques, pas un protocole complet de messagerie authentifiée.
Une application web peut ajouter une implémentation examinée de ML-KEM en JavaScript ou WebAssembly lorsque l’API native nécessaire n’est pas disponible. La prise en charge par les navigateurs évolue : les développeurs doivent donc tester les fonctionnalités des versions cibles exactes au lieu de supposer que tous proposent les mêmes algorithmes.
Un déroulement hybride conceptuel est le suivant :
- Générer des clés appropriées avec un aléa cryptographiquement sûr.
- Authentifier les éléments de clé du correspondant au moyen du mécanisme d’identité du protocole.
- Obtenir les contributions classiques et post-quantiques au secret partagé.
- Les combiner selon le schéma de dérivation de clés spécifié et le contexte de la conversation.
- Utiliser les clés dérivées pour le chiffrement authentifié, avec une gestion correcte des nonces et de l’état.
Il s’agit d’un aperçu explicatif, pas d’une recette d’implémentation. FIPS 203 normalise ML-KEM ; cette norme ne certifie pas une application de navigateur particulière et ne définit pas toutes les étapes d’un protocole de discussion.
La livraison par HTTPS fait partie du modèle de confiance
Le serveur fournit normalement le JavaScript et le WebAssembly qui traiteront le texte en clair. Une application modifiée à des fins malveillantes peut lire un message avant son chiffrement ou après son déchiffrement, même si sa bibliothèque cryptographique utilise des algorithmes solides.
HTTPS aide à authentifier la livraison et à la protéger contre les interférences sur le réseau. Il ne prouve pas que l’opérateur de l’origine, son système de déploiement ou ses dépendances ne sont pas compromis. Une page HTTPS ordinaire n’est pas automatiquement un paquet applicatif signé de manière indépendante.
Les considérations de sécurité WebCrypto du W3C abordent l’injection de scripts et la nécessité de protéger l’intégrité de l’application. Content Security Policy, une gestion attentive des dépendances et d’autres contrôles de sécurité web réduisent les risques, mais aucun ne transforme un script arbitraire de même origine en observateur non fiable incapable de toucher aux données de l’application.
WebAssembly partage également le périmètre de sécurité de l’application. Son bac à sable limite l’accès à l’hôte par des interfaces définies ; il ne rend pas fiable la page qui l’appelle. Compiler du C en Wasm ne rend pas le langage source sûr du point de vue de la mémoire.
Les clés n’existent pas nécessairement uniquement en RAM
Une messagerie dans le navigateur peut conserver des clés ou un état chiffré afin que l’utilisateur retrouve la même identité. Elle peut aussi proposer l’association d’appareils ou une récupération chiffrée. Ces comportements doivent être documentés plutôt que supposés inexistants.
Voici des questions utiles :
- Quelles clés sont conservées, et dans quel stockage du navigateur ?
- Que se passe-t-il lorsque les données du site sont effacées ou qu’une session de navigation privée se termine ?
- Une clé non extractible reste-t-elle utilisable par un code malveillant exécuté dans le contexte de l’application ?
- Une mise à jour nouvellement livrée peut-elle accéder à un ancien état local ?
- La récupération restaure-t-elle l’identité, l’historique des messages ou les deux ?
Une clé WebCrypto non extractible restreint l’exportation par l’API. Cela n’empêche pas à lui seul du code applicatif hostile de demander des opérations autorisées ou de collecter du texte en clair.
Les clients web et natifs impliquent des compromis différents
| Aspect | Client dans le navigateur | Client natif |
|---|---|---|
| Distribution | Origine, hébergement et chaîne de mise à jour web | Boutique d’applications ou distribution de paquets et chaîne de signature |
| Persistance locale | Stockage du navigateur et comportement du profil | Stockage applicatif du système d’exploitation et cycle de vie de l’application |
| Exposition | Scripts de même origine, extensions et vulnérabilités du navigateur | Dépendances applicatives et vulnérabilités du système ou de l’application |
| Disponibilité | Domaine accessible et services réseau nécessaires | L’application installée a toujours besoin des services réseau qu’elle requiert |
Aucune colonne ne désigne un gagnant sans examen de l’implémentation. Une application web peut rester accessible après son retrait d’une boutique, mais un domaine bloqué ou une route réseau absente peuvent toujours empêcher l’accès.
Mesurer les performances plutôt que les promettre
Selon FIPS 203, ML-KEM-768 utilise une clé d’encapsulation de 1 184 octets et un texte chiffré de 1 088 octets. Ces tailles expliquent pourquoi des protocoles peuvent planifier les mises à jour KEM plutôt que joindre de nouveaux éléments à chaque message court. Elles ne mesurent ni la bande passante ni la vitesse d’une application entière.
Un benchmark utile précise le navigateur, l’appareil, la version compilée, la méthode de préchauffage, l’opération mesurée et la distribution des durées. Il faut inclure le démarrage de la page, le chargement des modules, l’utilisation mémoire, les appareils peu puissants et le surcoût réseau. Des affirmations telles que « moins de deux millisecondes sur tous les téléphones modernes » exigent des mesures publiées ; cet article n’en fournit pas.
Application de ces principes à Livara
La présentation de la sécurité de Livara documente LVR1 et les limites de sa récupération. Son Proof Lab démontre certaines opérations locales P-256, HKDF et AES-GCM ; la page place explicitement la composition complète LVR1/LGS1 hors de ce banc d’essai. Une démonstration réussie ne prouve donc pas la sécurité de l’ensemble du code web distribué.
Avant une conversation sensible dans le navigateur, utilisez un client authentique et maintenu, consultez le modèle de menace actuel, protégez le profil du navigateur et vérifiez votre correspondant à l’aide de la procédure prise en charge de vérification des clés. Commodité et cryptographie utile peuvent coexister, à condition que le périmètre de livraison web reste inclus dans l’évaluation.
