WebCryptoAPI : le chiffrement entre dans la quatrième dimension

Avec le WebCryptoAPI du W3C, le chiffrement va passer dans la quatrième dimension. Le WebCryptoAPI offrira la possibilité de mettre en place des technologies de chiffrement directement au niveau d’une application web ; les appels aux fonctions de chiffrement étant directement effectués depuis le code JavaScript.

4^ème dimension

Avec le WebCryptoAPI du W3C, il s'agit clairement d'accompagner la sécurisation des applications Cloud et de la mobilité. Le navigateur Web étant désormais au cœur des usages et du poste de travail et des applications mobiles.

Le WebCryptoAPI consiste à proposer une API permettant d’opérer le chiffrement de données directement depuis un script en JavaScript. Avec le WebCryptoAPI, une application web pourra négocier ou distribuer des clefs de chiffrement, réaliser des opérations de (dé)-chiffrement (symétrique ou asymétrique), calculer des condensats (ou hashcodes), mais aussi générer ou vérifier des signatures électroniques.

le WebCryptoAPI pour sécuriser les usages de demain

Le WebCryptoAPI permettra de chiffrer de façon native et intégrée les données les plus sensibles d'une application. Le chiffrement gagnera en finesse. Les clefs de chiffrement pourront être négociées au niveau de l’application web et non plus uniquement entre le navigateur Internet et le serveur web comme c’est actuellement le cas.

Il faut donc voir le WebCryptoAPI comme l’arrivée de la troisième dimension dans le monde des navigateurs Internet. Une application utilisant le WebCryptoAPI pourra sécuriser/chiffrer elle-même ses données applicatives en s’affranchissant du chiffrement mis en place sur la couche de transport.

Les cas d'usage du W3C vous donneront plus d'exemples sur ce que WebCryptoAPI devrait  permettre (dans les domaines de la banque en ligne, de la diffusion de vidéos, mais aussi du mail ou des services de stockage de fichiers comme les Dropbox, etc...). A noter la forte implication de Netflix qui voit dans ce standard le futur pour la diffusion des contenus vidéos (films, séries, …) directement et nativement depuis un navigateur Internet, le tout sans plugin propriétaire.

les 3 autres dimensions du chiffrement

• La première dimension du chiffrement correspond au chiffrement des données via des tunnels VPN (historiquement en IPSEC et plus récemment en VPN-SSL). C'est le grand classique dans lequel tous les flux sont chiffrés sans distinction aucune. Avec un tunnel VPN, les données n'étant chiffrées que sur leur chemin (ou "en transit") d'un point vers un autre.
   
• La deuxième dimension du chiffrement s'appuie sur SSL/TLS, chiffrement nativement présent dans tous les navigateurs Internet. A contrario d'une approche de type VPN, ce chiffrement est réalisé pour une application précise uniquement (HTTP, SMTP, ...) et non pas plusieurs à la fois. On reste sur un chiffrement de type "transport" et donc pour sécuriser des données entre deux points.
   
• La troisième dimension du chiffrement déporte la fonction au niveau d'une application précise. Le chiffrement devient spécifique à l'application et ne peut être changé ou modifié dans un développement particulier (alors qu'un VPN IPSEC/SSL est en mesure de chiffrer quasiment tout type de flux ou de données, idem pour chiffrement de type SSL/TLS). Dans la troisième dimension du chiffrement, on retrouve des OpenPGP, du S/MIME. Il est nécessaire de déployer un logiciel spécifique et compatible entre les deux parties souhaitant communiquer entre-elles.

Avec la troisième dimension, les données sont chiffrées en mode transport, mais aussi lors de leur stockage. Ce que ne permet ni la première ni la deuxième dimension, qui sont toutes deux exclusivement dédiées à la sécurisation du transport des données.

mixage de dimensions à prévoir

La deuxième dimension (SSL/TLS) ne devrait pas être mise au rebut pour être remplacée par la 4^ème dimension (WebCryptoAPI). En effet, une couche de transport sécurisée comme SSL/TLS offre des avantages et une simplicité de mise en œuvre incomparables.

On devrait donc voir progressivement la montée des applications utilisant le WebCryptoAPI au sein de sessions SSL/TLS qui deviendront à terme l'équivalent 3.0 des VPN IPSEC que l’on connaît actuellement.

des implémentations jeunes mais prometteuses

Microsoft a récemment publié son implémentation de WebCryptoAPI du W3C (Microsoft Research JavaScript Cryptography Library). Compatible avec un large éventail de navigateurs (IE8,9,10,11, Firefox, Chrome, Opera, et Safari), elle marque un tournant et devrait accélérer l’adoption du WebCryptoAPI et des applications utilisant cette API. A l’heure actuelle, cela semble être l’implémentation la plus mature.

Google travaille aussi sur le support des WebCrytoAPI dans les navigateurs maison Chrome et sa déclinaison ouverte Chromium. Le suivi des développements est accessible via le bug tracker.

Enfin, la librairie PolyCrypt propose une implémentation WebCryptoAPI en 100% JavaScript. Une bonne opportunité de faire quelques tests (mais guère plus, cf. le warning ci-dessous). Si vous souhaitez faire des tests et voir comment cela fonctionne, un site web propose quelques formulaires (le code source étant disponible sur GitHub).

attention au 100% JavaScript

Que ceux qui se disent « cool, une librairie crypto en 100% Javascript ! » fassent attention, restent lucides et n’utilisent ces librairies qu’à des fins de test. En effet, et comme cela est expliqué en long et en large par Matasano Security « Javascript Cryptography Considered Harmful », la crypto en Javascript n’est pas sécurisée. En deux mots, il est nécessaire (mais pas suffisant) que la crypto soit mise en œuvre via une librairie externe qui sera elle appelée depuis du code JavaScript.
 

Jean-François (Jeff) Audenard

crédit photo © Julien Eichinger - Fotolia.com