Was ist Tink?

Tink ist eine Open-Source-Kryptografiebibliothek, die von Kryptografen und Security Engineers bei Google geschrieben wurde. Die sicheren und einfachen APIs von Tink reduzieren häufige Fehler durch nutzungsorientiertes Design, sorgfältige Implementierung, Codeüberprüfungen und umfangreiche Tests. Im Abschnitt Zielvorhaben auf dieser Seite finden Sie weitere Informationen dazu, welche Ziele Tink erreichen sollte.

Tink unterstützt Nutzer ohne kryptografischen Hintergrund bei der sicheren Implementierung gängiger kryptografischer Aufgaben. Bei Google wurde Tink in Hunderten von Produkten und Systemen eingesetzt.

Warum sollte ich Tink verwenden?

Die wichtigsten Gründe für Tink sind:

  • Einfache Nutzung

    Die Kryptografie ist schwierig zu verstehen. Mit Tink können Sie mit nur wenigen Codezeilen Daten verschlüsseln oder signieren und dabei integrierte Sicherheitsgarantien nutzen. Tink kann Ihnen auch dabei helfen, Schlüssel zu rotieren oder Schlüssel mit externen Schlüsselverwaltungssystemen (Key Management Systems, KMS) zu sichern.

  • Es ist sicher

    Tink ergänzt bekannte Bibliotheken wie BoringSSL und Java Cryptography Architecture und zeigt sie direkt in den Schnittstellen an, damit Auditoren und Tools schnell Lücken finden können. Tink trennt auch potenziell gefährliche APIs, damit Sie sie überwachen können.

  • Es ist kompatibel

    Tink-Geheimtexte sind mit vorhandenen Kryptografiebibliotheken kompatibel. Tink unterstützt auch das Verschlüsseln oder Speichern von Schlüsseln in Amazon KMS, Google Cloud KMS, Android Keystore und iOS-Schlüsselbunden.

Wer nutzt Tink?

Tink wird von vielen Unternehmen wie Google, Square und Citadel sowie von Hunderten von Google Cloud-Kunden und Google Pay-Partnern verwendet. Tink unterstützt auch die Jetpack Security Library, die viele beliebte Android-Apps wie Slack, Adidas, AirBnb und Nextdoor sichert.

Tink-Tore

Was sind die Hauptziele von Tink im Vergleich zu anderen Kryptografiebibliotheken und was sind die Hauptmechanismen, die Tink verwendet, um diese Ziele zu erreichen?

Kurz gesagt hat Tink zwei Ziele:

  1. Kryptografische Agilität fördern: Nutzer sollten Schlüssel und Algorithmen auf einfache Weise ändern können.
  2. Sicherheitsüberprüfungen aktivieren: Tink ermöglicht Nutzern, Code zu schreiben, dessen Sicherheit lokal überprüft werden kann. Dazu werden Schnittstellen bereitgestellt, die klare Sicherheitsgarantien bieten.

Tink erreicht diese Ziele hauptsächlich mit folgenden Mechanismen:

  1. Tink bietet Primitive und Schnittstellen als wichtige Abstraktionen. Diese Abstraktionen ermöglichen es Nutzern, Code zu schreiben, der nicht den zu verwendenden Algorithmus, sondern das erwartete Sicherheitskonzept vorgibt.
  2. Tink verwendet das Konzept eines "Schlüsselsatzes", d. h. eines Satzes von Schlüsseln, die mit einem bestimmten Primitiv verknüpft sind. Nutzer schreiben Code, der mit mehreren Schlüsseln funktioniert.
  3. In Tink werden Schlüssel nicht nur durch das zugrunde liegende Schlüsselmaterial angegeben, sondern auch durch den kryptografischen Algorithmus und alle Parameter. Das bedeutet, dass ein Tink-Schlüssel immer eine eindeutige kryptografische Funktion aus allen möglichen verfügbaren Funktionen auswählt und keinen Raum für eine Interpretation lässt.

In den folgenden Abschnitten werden diese Konzepte ausführlicher erläutert.

Kryptografische Agilität

Nehmen wir als Beispiel das Buch Software Engineering bei Google, ein Buch über Erkenntnisse aus dem Bereich Software Engineering mit dem Untertitel „Lektionen aus der Programmierung im Laufe der Zeit“. Die Autoren geben große Anstrengungen, um die Implikationen der Tatsache zu verstehen, dass sich die Dinge ändern. Diese Tatsache hat sich auch stark auf das Design von Tink ausgewirkt. In der Kryptografie ist es wichtig, sich auf Veränderungen vorzubereiten. Schlüssel werden auslaufen und die Algorithmen funktionieren nicht mehr. Für viele Nutzer ist es von entscheidender Bedeutung, Schlüssel und Algorithmen austauschen zu können und gut vorbereitet zu sein.

Sicherheitsüberprüfungen und lokale Immobilien

Tink fördert die Verwendung von Schnittstellen wie unserer AEAD-Schnittstelle, mit der Nutzer Daten verschlüsseln können. Neben anderen Sicherheitsgarantien garantiert ein AEAD, dass mehrere Verschlüsselungen desselben Strings zu unterschiedlichen Geheimtexten führen.

Angenommen, ein Entwickler möchte eine vertrauliche ID in einem Nutzer-Cookie speichern, um zu sehen, wie dies verwendet werden kann. Er könnte eine Klasse wie die folgende zur Verfügung stellen:

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

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

Wenn ein Aead übergeben wird, werden die folgenden Attribute abgerufen:

  1. Der Code kommuniziert, dass IdEncrypter ein Verschlüsselungsschema mit den Sicherheitseigenschaften benötigt, die von Aead bereitgestellt werden. Alternativ würde eine DeterministicAead nicht ausreichen – die IdEncrypter erfordert, dass zwei Verschlüsselungen derselben ID unterschiedlich sind. Andererseits wäre es zu streng, eine Instanz eines AES GCM-Verschlüsselungsdienstes (eine bestimmte Instanz eines Aead) als Parameter zu verwenden: Jede Aead reicht aus, damit IdEncrypter seinen Zweck erfüllt, und es muss kein bestimmter Algorithmus sein.
  2. Bei einer Sicherheitsüberprüfung wird das berücksichtigt. Ein Sicherheitsprüfer muss nicht das gesamte Code-Repository durchsuchen, um festzustellen, ob jemand eine abgeleitete Klasse von Aead erstellt hat, die für die Verwendung mit IdEncrypter nicht sicher ist. Stattdessen stellt Tink die Sicherheitseigenschaften aller Aead-Objekte bereit, und der Prüfer kann prüfen, ob diese ausreichend sind.

Vor allem der zweite Punkt erfordert viel Sorgfalt. Nutzer bitten oft, Algorithmen hinzuzufügen, die „nicht ganz“ ein Aead sind. Der vorherige Punkt zeigt, warum dies gefährlich ist: Wenn eine Implementierung von Aead verfügbar ist, die nicht die erforderlichen Sicherheitsgarantien bietet, kann IdEncrypter unsicher werden. Der Entwickler, der eine Sicherheitsüberprüfung durchführt, muss dann zusätzlichen Code untersuchen, um zu prüfen, ob das Objekt korrekt instanziiert ist.