GPGKeys

Aus C3D2
Version vom 24. Januar 2009, 19:29 Uhr von KonradRosenbaum (Diskussion | Beiträge) (vererst einigermaßen komplett)
Zur Navigation springen Zur Suche springen

Dieser Artikel versucht(!!) zu erklären wie ein GPG/PGP Schlüssel so funktioniert. Wer die Begriffe verwirrend findet sollte erst einmal auf Wikipedia zum Thema Asymmetrische Kryptographie lesen. Zu GPG selbst gibt es gute Dokumentation - die bitte auch lesen falls der Artikel verwirrend klingt.

Standards

PGP ist bei der IETF standardisiert.

  • RFC1991 - das obsolete PGP 2.x Format
  • RFC2440 - das von den meisten eingesetzte Format von 1998
  • RFC4880 - der aktuelle RFC von 2007
  • es wird im Moment (Stand Anfang 2009) gesammelt was alles im nächsten RFC angegangen werden soll

Web Of Trust

Hinter dem Web Of Trust steckt die Idee dass Nutzer sich gegenseitig zertifizieren können. Dazu werden Signaturen folgendermaßen interpretiert:

  • der Signierer bestätigt die Identität des Schlüsselinhabers
  • der Signierer delegiert einen kleinen Teil seiner eigenen Signier-Kompetenz auf den Schlüsselinhaber

Das bedeutet: wenn ich Nutzer Alice als voll vertrauenswürdig einstufe und er Nutzer Bob, Charly, und Dave signiert hat, dann bewerte ich eine Signatur von Dave als 1/3 so gut wie eine von Alice. Sollte ein Key Signaturen von Bob, Charly und Dave haben ist das für mich gleichbedeutet mit einer Signatur von Alice.

Vergleich X.509

X.509 (z.B. Basis von SSL) benutzt einen hierarchischen Ansatz. D.h. eine kleine Gruppe von Root-CAs (CA=Certificate Authority) signiert Nutzerzertifikate (a'ka public keys). Eine Root-CA kann das Recht zum Signieren an eine Sub-CA weiterreichen, wodurch sich Ketten von Zertifikaten zwischen Nutzer und Root-CA bilden können. Es ist jedoch nicht möglich dass ein Nutzer einen anderen Nutzer zertifiziert.

Meist haben Root-CAs Auflagen, wie exakt sie Identitäten festellen müssen und wie sie mit Zertifikaten umzugehen haben. Das bedeutet nicht dass sie es korrekt machen oder sich sonderlich kompetent dabei anstellen...

Kritik von Web Of Trust

Die größte Kritik am Web Of Trust kommt daher dass nicht zwischen Identitätsbestätigung und Vertrauen unterschieden wird. D.h. ich kann nicht sagen "Ich kann bestätigen dass Bobs Key zu Bob gehört aber ich vertraue dem Knaben nicht!".

Per Standard kann man diese feinen Unterschiede durchaus speichern, aber in der Praxis wird dies dem Nutzer von PGP/GPG nicht angeboten. Einziger Workaround ist eine maximale Vertrauenstiefe von 0 und explizites Eintragen der vertrauenswürdigen Keys in die GPG Konfiguration.

Key Aufbau

Public und Secret Key unterscheiden sich dahingehend, dass der Secret-Key nur das geheime Schlüsslematerial (aus dem sich das öffentliche berechnen läßt) und die UIDs enthält. Der Public Key enthält das öffentliche Schlüsselmaterial, UIDs und beliebig viele Signaturen.

Der Schlüssel ist als Hierarchie gespeichert:

  • Main-Key
    • UID 1
      • 1-n SelfSigs
      • beliebige UID-Sigs
    • UID 2
      • 1-n SelfSigs
      • beliebige UID-Sigs
    • ... UID n ...
    • Sub-Key 1
      • SubKeySig
    • Sub-Key 2
      • SubKeySig
    • ...

Main-Key

Dies ist der kryptographische Schlüssel mit dem der ganze PGP Key identifiziert wird. Dies ist grundsätzlich ein Signatur-fähiger Key (sonst funktioniert der Rest technisch nicht). Sollte dieser Key kompromittiert werden wird auch der Rest wertlos. Bei der heute üblichen Kombination DSA/ElGamal ist dies der DSA Key. Normalerweise ist dieser Key auch für alle Signaturen zuständig, in Spezialsetups mit zusätzlichen Signaturkeys macht er immerhin alle internen Key-Signaturen.

UID

Die UID (User IDentification) ist ein beliebiger String (in neueren Setups auch ein Bild), der den Nutzer des Schlüssels identifizieren soll. Üblicherweise ist dies ein Name und eine e-Mail-Adresse, da PGP/GPG normalerweise für Mail benutzt wird.

Man darf eine PGP UID natürlich nicht mit dem verwechseln was ein Beamter meint, wenn der "identifizieren" sagt - für letzteres wird normalerweise eine physische Wohnadresse oder eine Personummer und nicht eine eMail-Adresse verwendet.

SelfSig

Dies ist eine Signatur mit dem Main-Key unter einer UID. Dies bindet die UID an das kryptographische Material (Main- und Sub-Keys), das in diesem PGP Key gespeichert ist. Eine SelfSig kann ein Ablaufdatum haben.

UID Sigs

Mit einer Signatur unter einer UID bestätigt ein Nutzer, dass er diese Identität und ihre Zugehörigkeit zum Key geprüft hat. Im Web Of Trust drückt er damit auch ein wenig Vertrauen für den Besitzer des Keys aus.

Man beachte, dass nicht etwa pauschal der Key, sondern jede UID einzeln unterschrieben wird. Man sollte vor dem Signieren also wirklich jede UID einzeln prüfen, bevor man sie unterschreibt.

Sub-Key, SubKeySig

Ein Sub-Key bekommt Aufgaben vom Main-Key übertragen. Im normalen DSA/ElGamal-Setup ist der ElGamal Key der einzige Sub-Key und bekommt vom DSA Key die Aufgabe der Verschlüsselung (die DSA ja nicht kann) übertragen. Die SubKeySig stellt sicher, dass der SubKey korrekt an den Main-Key gebunden ist (sonst könnte man ja einen beliebigen SubKey druntermogeln).

SubKeys werden ausschließlich vom Main-Key signiert. Niemals von einem anderen Nutzer oder von einem anderen SubKey.

Key Signing Party

"Lockeres Beisammensein von PGP Nutzern unter ständigem Murmeln magischer Zahlen."

Hier soll es nicht um die Organisation einer KSP gehen, sondern um die Elemente dabei:

  • "KeyID und Fingerprint mitbringen!"
    • die KeyID dient dazu den Key von einem Server zu ziehen
    • der Fingerprint dient dazu den Key zu identifizieren
  • "Ausweis zeigen"
    • dies dient lediglich dazu den Namen und den Besitzer als real zu identifizieren - da PGP Keys üblicherweise sonst keine Ausweisdaten enthalten ist es müsig den Rest verifizieren zu wollen
    • wenn man nicht darauf besteht mit realen Personen und echten Namen zu kommunizieren, z.B. wenn man gut mit Pseudonymen leben kann, kann man auch darauf verzichten

Was gerne vergessen wird ist folgende wichtige Prozedur:

  1. Key vom Server ziehen
  2. Fingerprint vergleichen (abbrechen wenn er nicht passt!!!)
  3. Key lokal signieren (falls das Mail-Programm auf Signaturen besteht)
  4. eine verschlüsselte Testmail an JEDE UID des Keys senden (mit unterschiedlichen Zufallsstrings)
    • Zuordnung zwischen KeyID, String, UID sollte irgendwo gespeichert werden
  1. (für begrenzte Zeit) auf Antwort warten
  2. wenn Antwort kommt kann die jeweilige UID richtig signiert werden
    • der Absender ist egal (manche senden nur auf einer Mailaddi, aber empfangen dutzende)
    • der Zufallsstring muss stimmen
    • der Zufallsstring bestimmt welche UID signiert wird (siehe oben)
    • die Antwort muss nicht unbedingt verschlüsselt sein, da wir ja bitte keine Zufallsstrings wiederverwenden
  1. Signaturen auf Keyserver hochladen oder exportierten Key an Besitzer schicken
  2. Wenn keine Antwort kommt: lokale Signaturen wieder löschen

Wir erinnern uns: es wird die UID signiert und die enthält eine Mailadresse, also müssen wir auch den Zusammenhang zwischen Key und Mailadresse prüfen bevor wir ihn mit einer Signatur bestätigen. Genau dies tut der obige Algorithmus.

Erzeugung eines Zufallsstrings, z.B.: md5sum

Key Rot

Schlüssel altern. Es wird allgemein empfohlen Schlüssel (egal ob symmetrisch oder asymmetrisch) nur für eine begrenzte Zeit zu benutzen. Dies hat verschiedene Gründe:

  • Attacken werden mit der Zeit besser (nie schlechter) - sowohl technisch (CPU-Power) also auch mathematisch (schnellere Algorithmen)
  • Je länger ein Key benutzt wird, umso mehr Zeit hat ein Angreifer auch um ihn zu knacken, um damit noch Schaden anrichten zu können
  • Jede Benutzung des Keys gibt einem potentiellen Angreifer weiteres Material zum Knacken des Schlüssels
    • zum einen ist jede Signatur ein weiteres "Orakel" an dem ein Kandidat getestet werden kann
    • zum anderen gibt jede Signatur Bruchteile von Bits des Schlüssels preis
  • Je länger ein Key benutzt wird, umso höher ist auch das Risiko dass man ihn mal mit einer kaputten Implementation benutzt hat:
    • DSA versagt katastrophal wenn der Zufallsgenerator schlecht ist (der Key gilt danach als kompromittiert)
    • RSA versagt wenn die Kodierung des Hashes sich nicht strikt an die Vorschriften hält
    • ElGamal ist ebenfalls empfindlich gegen schlechten Zufall (im Signaturmodus)

Literatur:

  • Bruce Schneier
    • "Applied Cryptography"
    • "Practical Cryptography"

Empfehlungen:

  • symmetischer Key (CBC mode): 20 Mio Blöcke (AES: 1 Block = 8 Bytes)
  • SSL-Key für HTTPS: 1 Jahr
  • andere asymmetrische Keys (z.B. PGP): 5 Jahre
Abgerufen von „https://wiki.c3d2.de/w/index.php?title=GPGKeys&oldid=10567“