Blog, IT Security

Kryptographie mit Google Tink und Vault

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

YouTube immer entsperren

Das IT-Security Meetup Kassel ist ein Netzwerk von Experten und Interessierten zum Thema IT-Sicherheit. Eingeladen sind alle, die sich beruflich oder aus persönlichem Interesse mit Fragen der IT-Sicherheit auseinandersetzen und in einen fachlichen Austausch mit Gleichgesinnten treten wollen. Eines der Themen: Kryptographie.

Mit Dominik Schadow hatte das ITSMKS einen namhaften Experten für die sichere Softwareentwicklung mit Java zu Gast, der uns mit Google Tink und Vault gleich zwei wichtige Kryptotools vorgestellt und uns mit Demos in ihre Handhabung eingewiesen hat.

Hier ein kurzer Rückblick zu seinem Talk. Wer richtig in die Materie einsteigen will, der möge das o. g. Video anschauen.

"Ich will doch nur verschlüsseln ..."

Sensible Benutzerdaten sicher zu speichern, ist ein absolutes Muss bei Webanwendungen. Von der Entwicklung eines eigenen Kryptoalgorithmus mit Java träumen zum Glück aber nur wenige Entwickler – sicheren Standards sei Dank. Aber auch mit diesen Standards bleibt Kryptographie mit Plain Java eine aufwendige und fehleranfällige Angelegenheit.

Dass es mit ausgewählten Bibliotheken oder Services auch einfacher geht und wir nicht alles von Grund auf selbst entwickeln müssen, zeigt diese Session. Unser Ziel: Daten sicher zu speichern, ohne versteckte Fehler zu produzieren oder Aufwände unnötig in die Höhe zu treiben.

Welcher Kryptoalgorithmus ist der Richtige?

Schon bei der Entscheidung, ob wir symmetrisch oder asymmetrisch verschlüsseln wollen, stehen wir vor einer Vielzahl an Möglichkeiten. Zusätzlich kompliziert wird es, wenn wir den Algorithmus, für den wir uns entschieden haben, selbst konfigurieren müssen. Denn jetzt müssen wir entscheiden, welche kryptografische Eigenschaften er haben, welchem Modus Operandi er folgen oder wie das Padding aussehen soll. Auch die Frage nach dem Key Management und der Key Rotation ist entscheidend.

Üblich sind zwei Kryptographie-Varianten:

Entweder wir nutzen eine (Java-) Kryptobibliothek in unserem eigenen Code und implementieren selbst (d. h. wir nutzen die Bibliothek, implementieren aber keinen eigenen Algorithmus). Die Bibliothek sollte einfach zu nutzen sein und sichere Defaults zur Verfügung stellen.
Oder wir nutzen einen Kryptoservice, der z. B. per REST aufgerufen werden kann und unserer Anwendung Kryptofunktionalität zur Verfügung stellt.

Dominik Schadow stellt uns in seinem Vortrag zwei Tools vor, die diese Anforderungen erfüllen. Welches Tool das jeweils am besten geeignete ist, hängt wie so oft vom Projekt ab und lässt sich nicht allgemein beantworten.

Google Tink - open source, plattformunabhängig

Google Tink ist eine einfach zu nutzende Open-Source-Bibliothek, bei der nur sehr wenig konfiguriert werden muss. Vom Padding über den Modus Operandi bis hin zur Generierung von Zufallszahlen oder All-in-one-Konstruktionen wird alles von Tink selbst initialisiert. Tink

ist multilingual und plattformunabhängig – es funktioniert mit Java, Android, C++, Obj-C und Go (Python und JavaScript),
ist einfach zu konfigurieren, weil kein Überangebot besteht – es gibt nur ausgewählte symmetrische, asymmetrische und hybride Algorithmen (zzgl. solcher für Signaturen und MAC, die dieser Vortrag nicht berührt),
erkennt dank AEAD (Authenticated Encryption with Associated Data) Modifikationen im Ciphertext.

Google Tink schont Ressourcen

In Plain Java müssen rund um die Kryptoperationen rund zehn Exceptions gecatcht werden. Google Tink kennt mit GeneralSecurityException nur eine einzige Exception und kapselt alles weitere darin – sehr praktisch! Außerdem ist Google Tink speichersparend, weil die Bibliothek auf die genutzten Algorithmen reduziert werden kann.

Ein großer Vorteil von Google Tink ist die Key Rotation innerhalb einer Key-Familie („within the same primitive“): Dabei erstellt Tink innerhalb des Keysets eine neue Version, die alte wird archiviert. So steht diese für „passive“ Operationen wie die Entschlüsselung von alten Daten weiterhin zur Verfügung. „Aktive“ Operationen, etwa das Verschlüsseln von Daten, nutzen nur noch die neue Version. Diese einfache Möglichkeit, neue Schlüsselversionen zu erzeugen erleichtert deren regelmäßige Nutzung und kann so verhindern, dass Schlüssel nie ausgetauscht werden.

Google Tink senkt die Fehlerquote

Im Java Keystore ist nahezu alles speicherbar, was entfernt mit Kryptographie zu tun hat: Public Keys, Private Keys, Zertifikate, Passwörter usw. Hinzukommt ein riesiges Kommandozeilentool mit unzähligen Parametern. All das ein Meer an potenziellen Fehlerquellen.

Tink nutzt stattdessen Keysets. Ein Keyset ist eine Key Collection, die nur zweckgebundene und sortenreine Sammlungen enthält. Das verringert die Fehlerquote, weil keine ungültigen Kombinationen und unzulässige Vermischungen möglich sind.

Aber ACHTUNG: Google Tink speichert Keysets als Plaintext JSON, während im Java Keystore alles verschlüsselt werden kann. Das ist zunächst ein Manko, kann aber mithilfe der Cloud neutralisiert werden – dazu mehr im o. g. Vortragsvideo.

Vault von HashiCorp

Secret Management mit Vault

Häufig müssen vertrauliche digitale Daten zentral und sicher gespeichert werden. Ein passendes Tool dafür steht mit Hashicorp Vault zur Verfügung: Vault verwaltet zentral den Zugriff auf Geheimnisse auf Grundlage vertrauenswürdiger Anwendungsquellen und Benutzeridentitäten. Vault ist umfangreich erweiterbar und kann im eigenen Projekt um zahlreiche Dienste einfach per Konfiguration erweitert werden.

Encryption as a Service mit Vault

Einer dieser Dienste ist das Transit Backend. Dieses bietet praktisch Cryptography as a Service an: Dazu gehört das Ver- und Entschlüsseln von Daten ebenso wie deren Signatur oder die Berechnung des Hashwertes sowie die Generierung von Zufallszahlen.

Hierbei werden lediglich die Schlüssel in Vault gespeichert. Ankommende Daten werden mit dem gewünschten Schlüssel dann ver- oder entschlüsselt und wieder an den Aufrufen zurückgeschickt. Vault übernimmt die Schlüsselverwaltung und bietet eine einfache Schlüsselrotation an. Über die Kommandozeile oder per Web UI lässt sich dann konfigurieren, welche Version(en) aktiv sind und zur Ver- oder Entschlüsselung genutzt werden können.

Auf Vault wird per REST-Schnittstelle oder Kommandozeile zugegriffen. Das ist bei der Nutzung des Transit Backends nicht anders: Der Java Code selbst hat mit der Verschlüsselung nichts mehr zu tun und kümmert sich nur um den Aufruf des jeweiligen Endpoints. Beim Spring Framework stehen dafür sogar Klassen zur Verfügung, die eine große Ähnlichkeit mit dem RestTemplate aufweisen und es dem Entwickler besonders einfach machen. Da hierbei sensible Daten übertragen werden, ist die Transportverschlüsselung mittels HTTPS an dieser Stelle aber ein Muss.

Kryptographie in der Cloud? Vertrauenssache

Jeder Cloud-Anbieter bietet ein KMS (Key Management System) an: AWS KMS, Azure Key Vault, Google Cloud KMS … Üblicherweise wird dort nur der Masterkey gespeichert. Die Nutzung solcher Dienste setzt allerdings voraus, dass wir der Cloud vertrauen – und das ist Abwägungssache, wie auch der Einsatz von Google Tink oder Vault selbst.

Ein Beispiel: Google Tink lässt sich sehr gut mit AWS KMS oder dem Google Cloud KMS ergänzen. Dabei wird der Masterkey zur Verschlüsselung des jeweiligen Keys genutzt, kein Schlüssel wird mehr im Klartext gespeichert. Allerdings besitzt der Cloud-Anbieter dann den Masterkey und kann damit prinzipiell all unsere Daten entschlüsseln.

Zum Schluss drei Faustregeln

Google Tink ist nur dann wirklich sinnvoll, wenn alle Beteiligten Tink nutzen. Denn Tink (JSON) ist mit dem Java Keystore nicht kompatibel, ein Schlüsselaustausch ist nur über Umwege möglich.
Vault bringt einen gewissen Aufwand mit und ist für kleinere Anwendungen ggf. überdimensioniert – denn es müssen nicht nur Zugriffe konfiguriert und überwacht werden, das Tool muss auch regelmäßig gepatcht und in Produktivumgebungen hochverfügbar gehalten werden. Das Vault Transit Backend sollten wir bei kleineren Projekten nur dann nutzen, wenn Vault bereits im Umfeld der Anwendung zur Verfügung steht.
Entwicklung ist nur die halbe Miete – für Real-Life-Security müssen wir das ganze DevOps-Spektrum einbeziehen.