Qu'est-ce que Tink ?

Tink est une bibliothèque de cryptographie Open Source écrite par des cryptographes et des ingénieurs en sécurité de Google. Les API simples et sécurisées de Tink réduisent les pièges courants grâce à une conception centrée sur l'utilisateur, à une implémentation soignée et à des examens de code, ainsi qu'à des tests approfondis. Consultez la section Objectifs de cette page pour en savoir plus sur les objectifs pour lesquels Tink a été conçu.

Tink aide les utilisateurs sans expérience en cryptographie à implémenter en toute sécurité des tâches cryptographiques courantes. Chez Google, Tink a été déployé dans des centaines de produits et de systèmes.

Pourquoi utiliser Tink ?

Voici les raisons les plus importantes d'utiliser Tink:

  • Simplicité d'utilisation

    La cryptographie est difficile à comprendre. Avec Tink, vous pouvez chiffrer ou signer des données avec des garanties de sécurité intégrées en quelques lignes de code seulement. Tink peut également vous aider à alterner des clés ou à sécuriser des clés à l'aide de systèmes de gestion de clés externes.

  • La sécurité

    Tink ajoute des protections de sécurité en plus des bibliothèques bien connues telles que BoringSSL et Java Cryptography Architecture, et les affiche directement dans les interfaces, de sorte que les auditeurs et les outils puissent rapidement identifier des lacunes. Tink sépare également les API potentiellement dangereuses afin que vous puissiez les surveiller.

  • Il est compatible

    Les textes chiffrés Tink sont compatibles avec les bibliothèques de cryptographie existantes. Tink accepte également le chiffrement ou le stockage de clés dans Amazon KMS, Google Cloud KMS, Android Keystore et le trousseau iOS.

Qui utilise Tink ?

Tink est largement utilisé par de nombreuses entreprises, dont Google, Square et citadelle, ainsi que par des centaines de clients Google Cloud et de partenaires Google Pay. Tink alimente également la bibliothèque de sécurité Jetpack, qui sécurise de nombreuses applications Android populaires telles que Slack, Adidas, AirBnb et Nextdoor.

Objectifs Tink

Quels sont les principaux objectifs de Tink par rapport aux autres bibliothèques cryptographiques, et quels sont les principaux mécanismes qu'utilise Tink pour atteindre ces objectifs ?

En bref, Tink a deux objectifs:

  1. Promouvoir l'agilité cryptographique: les utilisateurs doivent pouvoir modifier les clés et les algorithmes de manière simple.
  2. Activer les examens de sécurité: Tink vise à permettre aux utilisateurs d'écrire du code dont la sécurité peut être examinée localement, en fournissant des interfaces qui offrent des garanties de sécurité claires.

Les principaux mécanismes utilisés par Tink pour atteindre ces objectifs sont les suivants:

  1. Tink fournit des primitives et des interfaces comme des abstractions importantes. Ces abstractions permettent aux utilisateurs d'écrire du code qui ne spécifie pas l'algorithme exact à utiliser, mais qui spécifie la notion de sécurité attendue.
  2. Tink utilise la notion de "keyset", qui est un ensemble de clés associées à une primitive particulière. Les utilisateurs écrivent donc du code compatible avec plusieurs clés.
  3. Dans Tink, les clés ne sont pas seulement spécifiées par le matériel sous-jacent, mais aussi par l'algorithme cryptographique et par tous les paramètres. Cela signifie qu'une clé Tink sélectionne toujours une fonction cryptographique unique parmi toutes les fonctions possibles qui peuvent exister, et ne laisse aucune place à l'interprétation.

Les sections suivantes expliquent ces concepts plus en détail.

Agilité cryptographique

Prenons l'exemple de Software Engineering at Google, un livre sur les leçons apprises dans le domaine de l'ingénierie logicielle, qui a pour sous-titre "Leçons à tirer de la programmation au fil du temps". Dans celle-ci, les auteurs font tout leur possible pour implorer les implications du fait que les choses changent. Ce fait a également eu un impact sur une grande partie de la conception de Tink. En cryptographie, il est important de se préparer au changement. Les clés seront divulguées et les algorithmes seront cassés. Pour de nombreux utilisateurs, il est essentiel de pouvoir changer de clé et d'algorithme, et il est donc prudent d'être préparés.

Examens de sécurité et établissements locaux

Tink favorise l'utilisation d'interfaces, telles que notre interface AEAD, qui permet aux utilisateurs de chiffrer des données. Parmi d'autres garanties de sécurité, un AEAD garantit que plusieurs chiffrements de la même chaîne génèrent des textes chiffrés différents.

Pour voir comment cela peut être utilisé, supposons qu'un ingénieur souhaite stocker un ID sensible dans un cookie utilisateur. Ils peuvent proposer une classe comme celle-ci:

class IdEncrypter {
  public static IdEncrypter createFromAead(Aead aead);

  public String encrypt(long id) throws GeneralSecurityException;
  public long decrypt(String encrypted) throws GeneralSecurityException;
};

La transmission d'un Aead permet d'obtenir les propriétés suivantes:

  1. Le code indique que pour que IdEncrypter effectue sa tâche, il a besoin d'un schéma de chiffrement avec les propriétés de sécurité fournies par un Aead. Sinon, un DeterministicAead ne suffirait pas, car IdEncrypter exige que deux chiffrements du même ID soient différents. En revanche, prendre comme paramètre une instance d'un chiffreur AES GCM (une instance particulière de Aead) serait trop strict: tout Aead est suffisant pour que IdEncrypter fasse son travail, et il n'est pas nécessaire qu'il s'agisse d'un algorithme spécifique.
  2. Un examen de sécurité peut prendre ce point en compte. Un examinateur de sécurité n'a pas besoin de parcourir l'intégralité du dépôt de code pour vérifier si quelqu'un a créé une sous-classe de Aead qui n'est pas sécurisée pour une utilisation avec IdEncrypter. À la place, Tink fournit les propriétés de sécurité de tous les objets Aead, que l'examinateur peut vérifier.

Le deuxième point en particulier demande beaucoup d'attention. Les utilisateurs demandent souvent à ajouter des algorithmes qui ne sont pas tout à fait des Aead. Le point précédent montre pourquoi cela est dangereux: si une implémentation de Aead n'offre pas les garanties de sécurité requises, IdEncrypter peut ne plus être sécurisé, et l'ingénieur effectuant un examen de sécurité doit examiner du code supplémentaire pour vérifier que l'objet est correctement instancié.