Datensicherheit Teil 3 GnuPG

Nachdem ich im letzten Artikel erläutert habe, warum für Email-Kommonikation PGP S/MIME vorziehe, möchte ich in diesem Teil möchte ich kurz zusammenfassen wie ich GPG einsetze. In der Vergangenheit war ich mir oft nicht sicher, welche Methode und welche Schlüssellängen am besten geeignet sind. Auch das Thema "GPG-Subkey" stand immer im Raum, da ich mit der Unterstützung in manchen Programmen einige Probleme hatte. Deswege möchte ich kurz meine Meinung zusammenfassen und ein paar Punkte benennen, die man beachten kann und teilweise auch sollte.
Für eilige oder faule Leser: Direkt zum Fazit

Allgemeines

Dieser Eintrag solle keine Anleitung zur Nutzung von GnuPG sein. Wenn das Thema für einen Leser neue ist, helfen die offizielle Website und die Wikipedia-Seite weiter. Als konkrete Anleitung kann z.B. dieser Guide helfen und diese Best practices und Applied Crypto Hardening sollte man auf jeden Fall berücksichtigen.

Schlüsselstruktur

GPG-Subkeys

Aus Sicherheitsgründen ist es eine gute Entscheidung, einen eigenen Schlüssel zum signieren anderer Schlüssel anzulegen. Dies ist auch bei x509 üblich, da übernimmt diese Rolle das Root- oder das 'Intermediate' Zertifikat. Im GPG Bereich ist es dabei üblich, dies mit dem 'Subkey' Feature von GPG selbst zu tun. Dies ist möglich, da man unter GPG zu jedem Schlüssel diverse Unterschlüssel (Subkeys) anlegen kann. Wichtig ist dabei nur zu bedenken, dass der Schutzbedarf des Hauptschlüssel größer ist, weswegen u.A. im Debian Wiki zu GPG-Subkeys eine ausführliche Anleitung zu finden ist. Ich persönlich bin kein Freund davon, mehrere UIDs oder mehr als maximal einen Subkey zu einem Schlüssel zu haben. Erstens ist der ganze Prozess um den privaten Hauptschlüssel zu entfernen sehr aufwändig; Des weiteren finde ich es sehr unübersichtlich, dass man die einzelnen UIDs eines Schlüssels nicht bestimmten Unterschlüsseln zuordnen kann. Manche Programme haben auch Probleme die Schlüssel sauber zu trennen und zeigen teilweise Informationen des Hauptschlüssels an, wenn man mit einem Subkey signieren möchte.

Ein alternativer Weg

Deswegen habe ich mich entschieden, einen normalen Schlüssel für das signieren von Schlüsseln anzulegen. Die Kommunikationsschlüssel sind somit keine Unterschlüssel, sondern ganz normale Schlüssel ( ein Schlüssel mit einem Unterschlüssel, um die Schlüssel für Signatur und Verschlüsselung zu trennen ). Der Hauptschlüssel wird auf einem separaten Speichermedium (verschlüsselt) gespeichert und genutzt um die Kommunikationsschlüssel manuell zu signieren.

Cipher und Schlüssellänge

Hauptschlüssel

Für den Hauptschlüssel kann man zwischen "RSA only" und "DSA" wählen. Eigentlich würde ich aus persönlichen und historischen Gründen zu DSA tendieren, da dies aber die Schlüssellänge auf 1024Bit beschränkt und intern SHA-128 verwendet wird, was nicht mehr als ausreichend sicher gilt, fällt diese Option weg. Es ist zu bedenken, dass der Hauptschlüssel i.d.R. eine länger Lebensdauer hat und somit sollten auch die kryptographischen Parameter so gewählt werden, dass in den nächsten Jahren von ausreichender Sicherheit ausgegangen werden kann.

Kommunikationsschlüssel

Für die kurzlebigen Kommunikationsschlüssel, hat man beide Möglichkeiten "RSA und RSA" oder "DSA und Elgamal". Leider haben beide Möglichkeiten einen Nach- und einen Vorteil. Ein Vorteil von "DSA und Elgamal" wäre, dass RSA und diese beiden Cipher auf verschiedenen mathematischen Problemen basieren. Sollte zukünftig also ein Algorithmus entdeckt werden, durch den man den RSA,DSA oder Elgamal Private-Key errechnen kann, so wären nie alle Schlüssel betroffen. Der Nachteil von DSA ist die bereits genannte Schlüssellänge und die Nutzung von SHA-1. Eine Lösung dafür wäre DSA-2 welches nicht mehr auf SHA-1 aufbaut und mehr als 1024 Bit nutzt. Leider sind diese Schlüssel noch nicht ganz ohne Kompatibilitätsprobleme zu nutzen, weswegen diese Lösung nocht etwas warten muss. Deswegen habe ich mich auch erstmal dafür entscheiden auch für die Kommunikation RSA zu verwenden. Es ist davon auszugehen, dass die Möglichkeit DSA-2 zu verwenden nicht so weit in der Zukunft liegt, wie eine Lösung für das Problem des diskreten Logarithmus oder der Faktorisierung großer Zahlen. Somit werde ich zu Schlüsseln auf Basis von DSA-2 wechseln, sobald dies kein Problem mehr darstellt.

Schlüsselänge

Als Schlüssellänge verwende ich für alle 3 Schlüssel 4096 Bit. Dies ist aber vor allem für den Hauptschlüssel wichtig. Die Koummikationsschlüssel kann man auch mit 2048Bit anlegen.

<h3>Fazit/Zusammenfassung</h3>

Folgende Methode habe ich für mich entdeckt, um mit GPG gut zurecht zukommen.

  1. Keinen GPG-Subkeys nutzen, sondern einen einen zusätzlichen Schlüssel zum Signieren der Schlüsseln verwenden
  2. Hauptschlüssel und beide Kommunikationsschlüssel als RSA-Keys anlegen, bis DSA-2 gut nutzbar ist
  3. Sobald DSA-2 verfügbar ist, RSA und DSA-2/Elgamal mischen um die Gesamtsicherheit zu erhöhen
  4. Der Hauptschlüssel sollte 4096 Bit haben, die Unteschlüssel 2048 oder auch 4096
Bei allen Empfehlungen handelt es sich lediglich um meine Meinung. Sollte jemand allerdings Bedenken im Bereich Sicherheit oder technischer Umsetzung haben, ist eine konstruktive Kritik gern gesehen.

Quellen

  1. Short key IDs are bad news
  2. Debian-Wiki GPG-Subkeys

Dennis Sivia

Dennis Sivia
I am passionate about technology and especially having a lot of fun with functional programming and computer science.

Getting started with Raspberry PI 3, Python and Elixir

Setup for implementing various raspberry sensors setups using elixir and python Continue reading

Elixir, Phoenix 1.3 , Elm and Webpack 3

Published on November 01, 2017

Prettier and Spacemacs

Published on October 31, 2017