Qu'est-ce que l'API Web Cryptography?
Avant d'entrer dans le vif du sujet d'aujourd'hui, l'API Web Cryptography, notez que toutes les photos ci-dessous sont disponibles ici en meilleure qualité.
Toute personne développant une application web avec une interface frontale peut avoir besoin d'effectuer des opérations cryptographiques telles que le hachage, le chiffrement ou la signature côté client (dans le code JavaScript). Ces habitudes conduisent à importer et utiliser des bibliothèques externes populaires comme crypto-js afin d’assurer la portabilité sur tous les navigateurs ciblés :
La bibliothèque fonctionne bien depuis des années, alors pourquoi devrais-je arrêter de l'utiliser ?
Ici, aucun troll n'est autorisé
L’objectif de ce blogpost n’est pas de dire que l’API Web Cryptography est la meilleure API ou que vous devez remplacer votre API cryptographique JavaScript existante par l’API Web Cryptography.
Le but est simplement de vous présenter ce qu’est l’API Web Cryptography et ce qu’elle offre.
Qu'est-ce que l'API Web Cryptography ?
D'après la RFC, il s'agit d'une :
“API JavaScript pour effectuer des opérations cryptographiques de base dans les applications web, telles que le hachage, la génération et la vérification de signatures, ainsi que le chiffrement et le déchiffrement. De plus, elle décrit une API permettant aux applications de générer et/ou de gérer le matériel de clés nécessaire pour réaliser ces opérations.”
Pour résumer, cela offre aux navigateurs des capacités natives pour effectuer différents types d'opérations cryptographiques via une API :
▪️ Générer des valeurs aléatoires de qualité cryptographique
▪️ Chiffrer et déchiffrer du contenu en utilisant des algorithmes de chiffrement symétriques ou asymétriques.
▪️ Signer et vérifier des signatures à l'aide d'algorithmes symétriques ou asymétriques
▪️ Dériver des clés et des bits à partir de clés de base ou d'une source de bits
▪️ Générer le hachage du contenu
En outre, il prend en charge les opérations relatives à la gestion des clés :
▪️ Générer des clés symétriques ou asymétriques pour différents types d'usages
▪️ Exporter/importer des clés en utilisant des méthodes sécurisées ou non sécurisées
L’API ne gère pas les aspects suivants (certains points de la liste ci-dessous ont été directement repris de la RFC) :
▪️ La persistance (sécurisée) des clés dans les systèmes de stockage du navigateur
▪️ La fourniture de clés dans certains types de stockage, tels que les éléments sécurisés ou les cartes à puce
▪️ La communication et la découverte des modules cryptographiques
▪️ La RFC n’impose aucune exigence normative quant à la manière dont les implémentations gèrent le matériel de clés une fois que toutes les références d’objet y afférentes ont été supprimées
Pourquoi l'API Web Cryptography n'est-elle pas le Graal ?
L'API offre des opérations cryptographiques de bas niveau, ce qui implique qu'il faut savoir exactement “ce que vous faites” lors de l'utilisation de ses différentes fonctionnalités. En effet, l'API ne vous protège pas contre une utilisation incorrecte des algorithmes cryptographiques supportés.
De plus, tout comme crypto-js, l'API prend en charge des algorithmes dépréciés tels que MD5, SHA1, le mode ECB d'AES, le mode CBC d'AES, etc. Ainsi, aucun avertissement ne sera généré si vous décidez d’en utiliser un, quel que soit le fait que votre usage soit légitime ou non.
De la même manière, l’API Web Cryptography ne vous avertira pas ni ne renverra d’erreur si vous créez ou utilisez une clé avec des usages plus larges que ceux réellement nécessaires pour les opérations cryptographiques effectuées.
Pour finir, tout comme crypto-js, l’API Web Cryptography vous laisse seul si vous avez besoin de stocker en toute sécurité une clé ou de communiquer avec des modules cryptographiques depuis du code JavaScript dans le navigateur.
Pourquoi devrais-je envisager l'API Web Cryptography ?
La cryptographie est un domaine extrêmement complexe et sujet aux erreurs. Même si vous respectez la norme, il est possible de créer un code vulnérable. Outre une utilisation incorrecte d'une bibliothèque cryptographique, l'un des pièges réside dans la qualité de l'implémentation des algorithmes supportés. En effet, ce type de problème est « invisible » pour la plupart des utilisateurs d'une bibliothèque cryptographique (y compris l'auteur de ce billet de blog), car il exige des compétences spécifiques pour identifier qu'une implémentation d'un algorithme cryptographique est non sécurisée.
Par exemple, comment vous assurer, de manière précise, que la bibliothèque cryptographique que vous utilisez :
▪️ Implémente correctement l'algorithme que vous souhaitez utiliser
▪️ Fournit une implémentation éprouvée
▪️ Corrige, de manière efficace, toute vulnérabilité de sécurité identifiée
▪️ Maintient, au fil du temps, les différentes implémentations des algorithmes supportés.
▪️ Est mise en oeuvre par des personnes disposant des compétences et de l'expérience requises
Voici l'API Web Cryptography. En l'utilisant, vous déléguez les validations ci-dessus aux fournisseurs de navigateurs, c'est-à-dire Google (Chrome), Mozilla (Firefox), Microsoft (Edge) et Apple (Safari) pour les principaux navigateurs. La section de la RFC intitulée “Underlying Cryptographic Implementation” définit la déclaration suivante :
“Cette spécification suppose, mais n'exige pas, que les agents utilisateurs conformes ne mettent pas en œuvre directement, et ne mettront pas en œuvre, des opérations cryptographiques au sein même de l'agent. Historiquement, de nombreux agents utilisateurs ont délégué les opérations cryptographiques, telles que celles utilisées dans TLS, à des API existantes disponibles dans le système d'exploitation sous-jacent ou à des modules tiers gérés indépendamment de l'agent.”
La RFC recommande aux fournisseurs de navigateurs de ne pas implémenter eux-mêmes les fonctions cryptographiques, mais plutôt de tirer parti de modules reconnus par l'industrie. Il est vrai qu'ici nous entrons dans une sorte de “delegationception” puisque vous faites confiance au navigateur qui délègue la gestion des opérations cryptographiques à une autre tierce partie.
De plus, l'utilisation de l'API Web Cryptography présente les avantages suivants :
▪️ Rendre plus difficile la réalisation “d'attaques sur la chaîne d'approvisionnement” de votre application
▪️ Offrir de meilleures performances pour le traitement cryptographique
La fin du syndrome du lapin blanc
D'un point de vue de la mise à jour, si un problème critique est identifié dans l'implémentation d'un algorithme, il ne sera plus nécessaire d'identifier en urgence quelles de vos applications web utilisent les versions vulnérables de la bibliothèque cryptographique, puis d'effectuer de multiples mises à jour et redéploiements. La mise à jour sera assurée via la fonction de mise à jour automatique de chaque navigateur, dont la plupart disposent désormais pour rester à jour.
Soyons honnêtes une seconde, admettons que des entités telles que Google, Mozilla, Microsoft ou Apple sont bien meilleures que votre entreprise (la mienne incluse) en matière de cryptographie et de gestion des correctifs. Par conséquent, même si nous sommes dans une délégation à deux niveaux, comme décrit dans la section précédente, le niveau de sécurité sera supérieur à celui obtenu si vous deviez patcher toutes vos applications vous-mêmes.
Niveau de support des navigateurs
En juin 2021, il était le suivant :
Capacités de l'API Web Cryptography
Cette section fournit un aperçu des capacités offertes actuellement par l'API Web Crypography (juin 2021).
La source provenait de la documentation de Mozilla combinée à la RFC, ainsi que d'une validation à l'aide des labs présentés (voir plus loin).
Algorithmes et operations supportés :
* Si vous utilisez un protocole non sécurisé pour une opération nécessitant HTTPS (dit secure context), l'erreur suivante sera levée (l'attribut subtle de l'objet crypto n'est pas défini) :
Format d'exportation de clé :
▪️ Raw: tampon de tableau contenant les octets bruts de la clé
▪️ PKCS #8
▪️ JSON Web Key
Éviter les problèmes cachés avec l'API
Voici un ensemble de points clés pour éviter les sièges de l'API Web Cryptography :
1️⃣ N'utilisez pas d'algorithmes dépréciés / Assurez-vous d'utiliser correctement un algorithme :
◾ Si vous avez le moindre doute concernant un algorithme ou son utilisation correcte, demandez conseil à un ami ou à un collègue compétent dans le domaine de la cryptographie.
◾ Douter et poser des questions est une attitude saine lorsqu'il s'agit de choisir ou d'utiliser correctement un algorithme cryptographique, comme dans la plupart des domaines de la vie.
2️⃣ N'utilisez pas la fonction getRandomValues() pour générer une clé, utilisez la fonction dédiée generateKey()
3️⃣ Lors de la génération d'une clé, spécifiez uniquement l'usage de la clé de manière cohérente via le paramètre nommé keyUsages de la fonction generateKey()
4️⃣ Si la clé que vous avez générée n'est pas destinée à être exportée, par exemple parce qu'elle sera utilisée uniquement pour une opération temporaire, marquez-la comme non extractible via le paramètre nommé extractable de la fonction generateKey(). En cas de doute, définissez ce paramètre sur false
◾ Attribuer la valeur false au paramètre extractable indique que la clé ne peut pas être exportée.
5️⃣ Ne présumez jamais que les systèmes de stockage (Local Storage, Session Storage, Indexed DB, etc.) fournis par le navigateur sont sécurisés du point de vue de l'accès au système (ils sont au moins sécurisés du point de vue de l'origine web et de l'accès via JavaScript).
6️⃣ Pour exporter une clé, utilisez toujours la fonction wrapKey() sauf si vous savez exactement ce que vous faites en utilisant la fonction exportKey().
Pourquoi ne devrais-je pas considérer les systèmes de stockage du navigateur comme sécurisés ?
Une fois générée, une clé (un objet CryptoKey en coulisses) n'expose à l'environnement JavaScript que des informations de métadonnées, telles que le type, les algorithmes, les usages de la clé, etc.
Il est requis par la RFC que le contenu de la clé ne soit pas accessible à l'environnement JavaScript – Voir ci-dessous, en jaune, le contenu exposé d'une CryptoKey lors de l'exécution :
The only way to access to the key content from the JavaScript environment is to export it via the exportKey() or wrapKey() function.
A common and quick reflex can be to use the exportKey() function and store the exported content of the key in the IndexedDB browser storage systems like suggested by the RFC in section named “Key Storage”.
A question comes to mind; does the browser protect the content stored in the IndexedDB storage when data is at rest?
Let’s verify…
La seule manière d'accéder au contenu de la clé depuis l'environnement JavaScript est de l'exporter via la fonction exportKey() ou wrapKey().
Un réflexe courant et rapide peut être d'utiliser la fonction exportKey() et de stocker le contenu exporté de la clé dans les systèmes de stockage du navigateur IndexedDB, comme le suggère la RFC dans la section intitulée “Key Storage”.
Une question se pose : le navigateur protège-t-il le contenu stocké dans IndexedDB lorsque les données sont au repos ?
Vérifions...
1️⃣ Stockez une clé exportée dans une IndexedDB en utilisant Firefox :
2️⃣ Vérifiez au niveau du système de fichiers s'il est possible d'accéder au contenu de la clé en lisant la base de données SQLite utilisée pour stocker les données d'IndexedDB :
Nous pouvons accéder au contenu stocké. 😔
Même opération avec Chrome, en notant qu'il utilise le format LevelDB au lieu de SQLite pour le stockage :
Nous pouvons également accéder au contenu stocké. 😔
Même test avec Edge (Edge utilise également le format LevelDB) :
Même résultat 😔
En conclusion, considérez les systèmes de stockage du navigateur comme non sécurisés du point de vue du système de fichiers. En effet, comme démontré ci-dessus, si vous utilisez la fonction non sécurisée exportKey() pour exporter la clé et que la valeur est stockée dans les systèmes de stockage du navigateur, alors le navigateur ne dispose pas d’une couche de protection contre l’accès direct à la valeur de la clé exportée via ses fichiers système.
Protection intégrée contre le Déni de Service local
Les navigateurs implémentent des protections empêchant l'utilisation des fonctions cryptographiques d'une manière susceptible de provoquer une instabilité ou des plantages du navigateur. Vous trouverez ci-dessous quelques exemples de limitations mises en œuvre.
Voici un exemple de limitation mise en œuvre dans la fonction getRandomValues() – La longueur de la requête ne peut pas dépasser 65 536 octets :
Un autre exemple de limitation est présenté ici dans la fonction encrypt() lorsqu'elle est utilisée avec une paire de clés asymétriques. Dans cet exemple, la donnée d'entrée à chiffrer est trop volumineuse :
Cependant, pour l'exemple ci-dessus, selon la manière dont la fonction cryptographique est appelée, il se peut qu'elle contourne la protection mentionnée et en déclenche une autre, ou non…
Lorsque ce test est effectué, il déclenche la protection sandbox sur Chrome et Edge, sans qu'à aucun moment le navigateur ne devienne instable :
Sur Firefox, le navigateur devient instable et doit être fermé via le gestionnaire de tâches. Regardez cette vidéo pour une démonstration complète du comportement.
Il n'est pas toujours nécessaire de faire un choix…
Il peut être tentant de remplacer toute bibliothèque cryptographique présente dans un projet par l'API Web Cryptography. L'auteur estime que ce n'est pas la meilleure solution pour la raison suivante découverte lors de son étude : l'API Web Cryptography offre des fonctionnalités cryptographiques de bas niveau, de sorte que son utilisation nécessite des compétences en cryptographie afin d'éviter d'introduire des vulnérabilités par une mauvaise utilisation de ses fonctionnalités ou des algorithmes.
La plupart des bibliothèques cryptographiques populaires, telles que crypto-js, fournissent des fonctionnalités cryptographiques de haut niveau afin de prendre en charge, en arrière-plan pour l'utilisateur, les décisions importantes relatives à la bonne utilisation des primitives cryptographiques et de l'empêcher ainsi d'utiliser de manière inappropriée, par exemple, l'algorithme AES ou le générateur de nombres pseudo-aléatoires.
De plus, les bibliothèques cryptographiques populaires, comme crypto-js, ont déjà commencé à utiliser l'API Web Cryptography en interne lorsqu'elle est disponible.
Le script PowerShell suivant récupère les résultats de la première page d'une recherche de packages “crypto” dans le registre NPM et tente de trouver toute référence à l'API Web Cryptography dans la base de code du dépôt Git source :
L'exécution du script a donné les résultats suivants :
Par conséquent, il n'est pas nécessaire de délaisser votre bibliothèque cryptographique préférée si elle supporte l'API Web Cryptography lorsqu'elle est disponible.
Le laboratoire
Afin d'expérimenter tous les éléments mentionnés dans cet article, un laboratoire a été créé.
Ce laboratoire présente l'interface utilisateur suivante et offre un terrain de jeu pour découvrir, explorer et tester les différentes fonctionnalités proposées par l'API de cryptographie Web.
Les fonctionnalités du laboratoire ont été testées sur la dernière version (en juin 2021) de Chrome, Firefox et Edge. Toutes les fonctionnalités ont été entièrement documentées afin de permettre un accès facile.
Toutes les opérations cryptographiques ont été centralisées dans un script JavaScript nommé “operations.js” pour faciliter la lecture et la compréhension du code ainsi que sa modification afin d'explorer des cas de test personnalisés.
L'ensemble des notes d'étude recueillies a été fourni afin de présenter toutes les informations, hypothèses et suppositions qui ont été utilisées lors de la création de ce billet de blog.
Conclusion
Cet article a exploré à la fois les nouvelles capacités et les écueils apportés par l'API Web Cryptography.
L'étude a permis de dégager les enseignements suivants :
1️⃣ Elle fournit des fonctionnalités cryptographiques de bas niveau, ce qui nécessite des compétences spécifiques dans le domaine de la cryptographie pour les utiliser judicieusement sans introduire de vulnérabilités.
2️⃣ Elle offre une couche commune de capacités cryptographiques au niveau du navigateur, permettant aux bibliothèques cryptographiques existantes de s'en appuyer pour fournir aux développeurs un ensemble de fonctionnalités cryptographiques de haut niveau et sûres. En effet, ces fonctionnalités de haut niveau prennent en charge, en coulisses pour le développeur, les décisions importantes relatives à la bonne utilisation des primitives cryptographiques, afin d'éviter tout mauvais usage.
3️⃣ Certaines parties de la RFC restent imprécises, obligeant un fournisseur de navigateur à suivre sa propre voie dans certains domaines, comme par exemple la sélection des composants cryptographiques tiers chargés de gérer les opérations cryptographiques ou le support des systèmes de gestion des clés. Cela peut conduire à des vulnérabilités et à des incompatibilités techniques dans certains navigateurs en fonction de ces décisions.
En guise de conclusion, les auteurs garderont cet arbre de décision en tête :
Auteurs
📍 Dominique Righetto
📍 Alexis Pain
📍 Julien Ehrhart
