Böse Schlüssel werden zum Problem für GnuPG

Ein Forscherteam hat demonstriert, wie einfach sich die IDs zu GnuPG-Schlüsseln fälschen lassen und kurzerhand böse Duplikate des kompletten Strong-Sets erzeugt. Das umfasst rund 50.000 besonders eng vernetzte und vertrauenswürdige Schlüssel.

 

Jeder PGP- respektive GnuPG-Schlüssel hat eine ID. Traditionell ist das ein 32-Bit-Wert wie 0xB3B2A12C in hexadezimaler Darstellung, der eigentlich eindeutig sein sollte. Jetzt haben Richard Klafter und Eric Swanson gezeigt, dass sie mit spezieller Software ganz gezielt Schlüssel für bestimmte PGP-IDs erstellen können. Dank der Parallelisierung via OpenCL, die auch GPUs mit einbezieht, dauert das im Schnitt nur noch 4 Sekunden pro Key. Die Forscher haben als Demonstration das komplette Strong Set geklont und in einen eigenen Key-Server gesteckt.

 

Der Angriff knackt also keineswegs die GnuPG-Verschlüsselung; er demonstriert vielmehr, dass es sehr einfach sein kann, einem nachlässigen GnuPG-Anwender falsche Schlüssel unterzuschieben. Es genügt nämlich keineswegs, die ID zu checken und vielleicht noch einen Blick auf die Unterschriften eines Keys zu werfen.

 

Das PGP Strong Set besteht aus über 50.000 Schlüsseln, bei denen viele und hochwertige Unterschriften die Echtheit bestätigen. Diese Unterschriften haben die Forscher jedoch mit den gefälschten Schlüsseln ebenfalls nachgeahmt. Wer also nur einen Blick auf die Unterschriften wirft, und dort so renommierte Namen wie den der c't Kryptokampagne entdeckt, kann schnell auf eine solche Fälschung hereinfallen. Achtung, dieser Link führt auf einen gefälschten Schlüssel auf dem bösen Key-Server der Forscher.

Schutz vor Klonen

Der wichtigste Schutz vor solchen Klonen ist das Überprüfen der Fingerabdrücke. Wenn man einmal in einem direkten Gespräch mit seinem Gegenüber den Fingerabdruck der Schlüssels abgeglichen hat, kann man sicher sein, dass der Schlüssel echt ist. In der Praxis hat es sich bewährt, sich zumindest drei zufällig ausgewählte Blöcke – etwa den zweiten, den dritt- und vorletzten vorlesen zu lassen und zu überprüfen. Die Fingerabdrücke der Schlüssel zur c't-Kryptokampagne lauten übrigens

ID: 0xDAFFB000 / 0x2bae3cf6daffb000
A3B5 24C2 01A0 D0F2 355E 5D1F 2BAE 3CF6 DAFF B000
ID: 0xB3B2A12C / 0xdbd245fcb3b2a12c
19ED 6E14 58EB A451 C5E8 0871 DBD2 45FC B3B2 A12C

Sie finden sie auch in gedruckter Form im Impressum jeder c't-Ausgabe

Darüber hinaus gibt es auch bereits 64-bittige IDs. Doch die finden bislang kaum Verwendung. Selbst das zentrale Kommandozeilen-Programm gpg lässt sie sich nur mit einem weitgehend unbekannten, zusätzlichen Parameter entlocken:

gpg --fingerprint --keyid-format LONG

Angesichts der Tatsache, dass die Kollisionen für die 32-Bit-IDs schon seit über 10 Jahren bekannt sind, ist es umso erstaunlicher, dass die meisten Tools und Programme immer noch mit 32-Bit-IDs hantieren. Zumindest die Keyserver nutzen jedoch bereits intern die 64-Bit-IDs. Auch gpg akzeptiert sie klaglos an Stelle der kurzen 32-Bit-IDs.