Google Tink : cryptographie sûre de haut niveau

Tink est une bibliothèque cryptographique libre développée par l’équipe de cryptographie de Google, conçue pour fournir une cryptographie sûre et facile à utiliser. Sa motivation principale est d’empêcher les erreurs courantes d’utilisation de la cryptographie qui se produisent même chez des développeurs expérimentés utilisant des bibliothèques de bas niveau. L’API de Tink est conçue de sorte que l’opération correcte soit l’option la plus simple, ce qui rend difficile la création accidentelle de configurations non sécurisées.

Tink organise les clés en ensembles de clés plutôt que d’exposer des objets individuels de clé. Les applications utilisent des descripteurs d’ensemble de clés, et non des octets bruts de clé. Cette abstraction empêche l’exposition accidentelle des clés, permet une rotation transparente des clés et autorise le stockage des clés dans des systèmes distants de gestion des clés, sans que l’application voie directement le matériel cryptographique. Le concept d’ensemble de clés est au cœur de la conception sûre de Tink.

L’interface AEAD (chiffrement authentifié avec données associées) de Tink fournit des opérations de chiffrement et de déchiffrement. AeadFactory.getPrimitive(keyset) renvoie un objet Aead ; l’appel de aead.encrypt(plaintext, associatedData) renvoie un texte chiffré. Tink sélectionne automatiquement l’algorithme de chiffrement en fonction de l’ensemble de clés (par exemple, AES-256-GCM) et génère un nonce aléatoire. L’interface masque tous les détails de l’algorithme, la gestion des nonces et l’encodage du format.

L’interface MAC de Tink fournit des opérations de calcul et de vérification pour les codes d’authentification de message. MacFactory.getPrimitive(keyset) renvoie un objet Mac. mac.computeMac(data) renvoie le tag d’authentification ; mac.verifyMac(tag, data) le vérifie et lève une exception de sécurité si la vérification échoue. L’algorithme par défaut est HMAC-SHA256. L’interface évite les erreurs courantes, comme comparer des MAC à l’aide de l’égalité ordinaire des chaînes plutôt que d’une comparaison à temps constant.

Tink fournit des interfaces distinctes, PublicKeySign et PublicKeyVerify, pour les signatures numériques. Les objets de signature et de vérification sont dérivés de références de jeux de clés différentes, respectivement privée et publique, ce qui empêche d’utiliser accidentellement une clé privée pour la vérification, ou inversement. Les implémentations Ed25519 et ECDSA P-256 de Tink sont utilisées par défaut ; une version déterministe d’ECDSA est disponible pour éviter les vulnérabilités liées à l’aléa.

Les interfaces HybridEncrypt et HybridDecrypt de Tink implémentent ECIES (schéma de chiffrement intégré aux courbes elliptiques). Le chiffrement hybride combine un échange de clés asymétrique avec un chiffrement symétrique : l’expéditeur génère une clé éphémère, effectue un échange ECDH avec la clé publique du destinataire, dérive une clé symétrique et chiffre avec AEAD. Cela permet de chiffrer de grands messages à l’aide de clés asymétriques sans les surcoûts d’un chiffrement purement asymétrique.

La rotation des clés dans Tink est sûre et compatible avec les versions antérieures. Pour effectuer une rotation : générez une nouvelle clé et ajoutez-la au jeu de clés, définissez la nouvelle clé comme principale (les futurs chiffrements l’utiliseront), puis conservez les anciennes clés dans le jeu de clés afin de déchiffrer les textes chiffrés existants. Les anciens textes chiffrés continuent d’être déchiffrés, car les clés non principales restent disponibles pour le déchiffrement. Une fois que tous les anciens textes chiffrés ont été rechiffrés ou sont arrivés à expiration, supprimez les anciennes clés du jeu de clés.

Les jeux de clés Tink sont sérialisés au format JSON ou au format binaire Protocol Buffer. Le format JSON est lisible par les humains et utile pour le débogage. Le format binaire est plus compact pour la production. Les jeux de clés sérialisés contenant des clés privées doivent être chiffrés avant leur stockage. Tink permet de stocker des jeux de clés chiffrés au moyen d’un chiffrement symétrique AEAD standard, ou de déléguer leur stockage à un KMS.

Tink s’intègre aux principaux fournisseurs de KMS : AWS KMS, Google Cloud KMS et HashiCorp Vault. Au lieu de chiffrer les jeux de clés avec une clé AEAD locale, Tink enveloppe la clé de chiffrement du jeu de clés à l’aide du KMS. Le chiffrement réel du jeu de clés utilise une clé de chiffrement des données (DEK) générée localement, et la DEK est chiffrée par la clé de chiffrement des clés (KEK) du KMS. Cette méthode suit le modèle du chiffrement enveloppe utilisé par les fournisseurs cloud.

L’AEAD standard exige de charger l’intégralité du message en mémoire pour le chiffrement et le déchiffrement. L’interface AEAD en continu de Tink chiffre les fichiers volumineux par segments, ce qui permet de chiffrer et de déchiffrer en continu sans mettre en mémoire tampon l’intégralité du texte en clair. Chaque segment est authentifié indépendamment, et l’ordre ainsi que l’exhaustivité des segments sont vérifiés pendant le déchiffrement. Cette fonctionnalité est essentielle pour chiffrer des sauvegardes, des vidéos et d’autres fichiers volumineux.

Tink est disponible pour Java, Python, Go et C++, avec des API idiomatiques pour chaque langage. L’interopérabilité entre langages est garantie : un fichier chiffré avec Tink en Python peut être déchiffré avec Tink en Java. Tink convient ainsi aux systèmes composés de plusieurs services écrits dans différents langages et devant échanger des données chiffrées. Tink s’intègre également aux tampons de protocole pour une configuration des jeux de clés sûre du point de vue des types.

Lors de la rotation des clés Tink, que deviennent les textes chiffrés avec l’ancienne clé (non principale) ?

Récapitulatif de Tink : l’abstraction fondée sur les jeux de clés empêche l’exposition des clés brutes, l’interface AEAD masque la gestion des valeurs nonce et la sélection de l’algorithme, l’interface MAC utilise en interne une vérification à temps constant, les interfaces de signature numérique et de chiffrement hybride empêchent les usages incorrects de l’interface, la rotation des clés est compatible avec les versions antérieures (les anciennes clés permettent le déchiffrement jusqu’à leur suppression), l’intégration aux KMS suit le modèle du chiffrement enveloppe, l’AEAD en continu traite les fichiers volumineux et l’interopérabilité entre langages est garantie.