GnuPG/HowTo: Subkeys tauschen: Unterschied zwischen den Versionen
K (+Wie tausche ich nun meine Subkeys? (stub)) |
(→Warum Subkeys tauschen?: typos) |
||
| (5 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
| Zeile 3: | Zeile 3: | ||
== Was sind Subkeys? == | == Was sind Subkeys? == | ||
Ein OpenPGP Key besteht aus | Ein OpenPGP-Key besteht aus mehreren Teilen: Der erste Teil ist der sogenannte ''primary key''. Von ihm werden der Fingerprint und die KeyID abgeleitet. Er ist das zentrale Element und als einziges im gesamten Schlüssel nicht austauschbar. Neben ihm existieren die User-IDs, welche Name, Kommentar und E-Mail-Adresse speichern. Der dritte Teil sind die sogenannten Subkeys. Alle Teile eines OpenPGP-Keys können Signaturen tragen. Ablaufdaten und Präferenzlisten liegen in den sogenannten [[Selbstsignatur]]en. Die Subkeys sind zusätzlich zum primären Schlüssel benutzte kryptographische Schlüssel. Sie sind dazu gedacht, bestimmte (beim Erzeugen festgelegte) Funktionen, wie Verschlüsselung, zu übernehmen. Dies ist der Standardfall, wenn der primäre Schlüssel zum Beispiel keine Verschlüsselung kann (weil der Algorithmus dies schlichtweg nicht kann). | ||
Die möglichen Aufgaben eines Schlüssels sind: '''C - Certify''' - | Die möglichen Aufgaben eines Schlüssels sind: '''C - Certify''' - andere Schüssel oder User-IDs beglaubigen; dies kann nur der primäre Schlüssel. '''S - Sign''' - signieren, '''E - Encrypt''' - verschlüsseln und '''A - authenticate''' - nicht-OpenPGP-spezifische Aufgaben wie [[SSH]] oder [[X.509]]. | ||
== Warum Subkeys tauschen? == | |||
Subkeys sind genauso wie jeder andere Teil eines Kryptosystems Ziel von Angriffen. Ein regelmäßiges Tauschen, das heißt das Anlegen von neuen und das Verwerfen von alten, kann helfen die Sicherheit zu erhöhen indem das Zeitfenster, in dem die Schlüssel valide sind - und somit auch das Zeitfenster für Angriffe - verkürzt wird. | |||
Das Tauschen der Subkeys ist aber nur bedingt hilfreich, da der primäre Schlüssel nicht getauscht werden kann. Wird dieser kompromittiert, so können Subkeys nach Belieben auch vom Angreifer getauscht werden. Das Tauschen der Subkeys hilft also nur um Angriffe zu erschweren. | |||
== Wie tausche ich nun meine Subkeys? == | |||
Als erstes öffnen wir den key mittels ''--edit-key'': | |||
$ gpg --edit-key 0x01234567 | |||
Danach sollte man etwas sehen ähnlich diesem Listing: | |||
pub 1024D/5E384C0A created: 2007-09-23 expires: never usage: SC | |||
trust: ultimate validity: ultimate | |||
sub 2048g/8A5C6FFE created: 2007-09-23 expires: never usage: E | |||
Hier listet uns GnuPG das Key Material auf. Der erste Eintrag ''pub'' gibt den primären Schlüssel an. Der folgende Eintrag ''sub'' einen Subkey für Verschlüsselung (''usage: E''). Diesen Subkey wollen wir im Beispiel ersetzen. Hierzu erzeugen wir erst einmal einen neuen Subkey: | |||
Command> addkey | |||
Wir bekommen nun eine Liste möglicher Subkey Typen angezeigt, diese variiert von GnuPGP Version zu Version und von den eigenen Einstellungen: | |||
Please select what kind of key you want: | |||
(2) DSA (sign only) | |||
(3) DSA (set your own capabilities) | |||
(4) Elgamal (encrypt only) | |||
(5) RSA (sign only) | |||
(6) RSA (encrypt only) | |||
(7) RSA (set your own capabilities) | |||
Da wir ja einen Encrypton key Type ''g'' also Elgamal tauschen wollen erzeugen wir nun wieder einen Elgamal key in dem wir mit '4' bestätigen. | |||
Danach werden wir nach der Größe gefragt (nicht bei allen Typen). Wir können einfach den selben wert wie beim Alten schlüssel nehmen oder uns auf den Default verlassen. Zu klein sollte man die Schlüssel allerdings nicht wählen da diese dann leichter zu knacken sind. Zu groß zu wählen ist genauso kontraproduktive da dies nur unnötige Rechenzeit bei allen aktionen bedeutet und keine weitere Sicherheit bringt. Im Gegenteil, von einigen Verfahren ist sogar bekannt das sie bei zunehmender Schlüssellänge wieder unsicherer werden. Auch ist zu bedenken das die doppelte länge nicht die doppelte Sicherheit sondern eine vielfach höhere Sicherheit bedeutet da diese exponentiell und nicht proportional von einander abhängen. Als grobe Richtwerte kann man aber annehmen das kein verfahren mit unter 1024 Bits benutzt werden sollte, Schlüssel über 4096 Bit sind auch wenig sinnig. | |||
Nach der Eingabe der Länge wird man nach dem Verfalldatum gefragt. Je nach Schlüssellänge und Verwendungs Zweck sind in der regel 1 bis 8 jahre gute werte. Im Folgenden entscheiden wir uns im Beispiel für zwei Jahre mittels der Eingabe '2y'. | |||
Zur Sicherheit fragt GnuPG noch einmal nach ob das Datum stimme, dies bestätigen wir mit 'y'. | |||
Als Letztes werden wir gefragt ob wir den Schlüssel wirklich erzeugen wollen. Auch das bestätigen wir mit 'y'. | |||
Nun sollten wir das neue Key listing erhalten: | |||
pub 1024D/5E384C0A created: 2007-09-23 expires: never usage: SC | |||
trust: ultimate validity: ultimate | |||
sub 2048g/8A5C6FFE created: 2007-09-23 expires: never usage: E | |||
sub 2048g/06A765E2 created: 2009-05-03 expires: 2011-05-03 usage: E | |||
Der nächste Schritt ist das festlegen eines neuen Verfalldatums für den alten Subkey. Hierzu müssen wir erst einmal den richtigen subkey auswählen. Dies machen wir mittels des Befehls ''key' gefolgt von der Nummer des Subkeys. Dabei trägt der erste Subkey die Nummer 1, der zweite die 2 und so weiter. In Falle dieses Beispiels also: | |||
Command> key 1 | |||
Danach bekommen wir das Listing nun erneut angezeigt. Der aktive Subkey wird nun mittels '*' markiert: | |||
pub 1024D/5E384C0A created: 2007-09-23 expires: never usage: SC | |||
trust: ultimate validity: ultimate | |||
sub<font color="red">*</font> 2048g/8A5C6FFE created: 2007-09-23 expires: never usage: E | |||
sub 2048g/06A765E2 created: 2009-05-03 expires: 2011-05-03 usage: E | |||
Nun können wir mittels 'expire' das Verfalldatum für den Subkey setzen: | |||
Command> expire | |||
Da es der Erfahrung nach eine weile dauert bis alle ihre Keys einmal Aktuallisiert haben sollten wir einen gewissen Spielraum hier geben. Ich Benutz in meinem Falle einmal 6 Monate, angegeben durch '6m'. GnuPG fragt mich wie oben erneut ob das Datum korrekt ist. Ist es das kann man es bestätigen und man bekommt erneut das key listing: | |||
pub 1024D/5E384C0A created: 2007-09-23 expires: never usage: SC | |||
trust: ultimate validity: ultimate | |||
sub* 2048g/8A5C6FFE created: 2007-09-23 <font color="red">expires: 2009-10-30</font> usage: E | |||
sub 2048g/06A765E2 created: 2009-05-03 expires: 2011-05-03 usage: E | |||
Di Obigen Schritte können wir nun für alle Subkeys durchführen die wir ersetzen möchten. Sind wir fertig müssen wir den key mittels 'save' speichern: | |||
Command> save | |||
Danach können wir ihn mittels '--send-key' auf die keyserver hoch laden: | |||
$ gpg --send-key 0x01234567 | |||
Es kann weiterhin Hilfreich sein dem ein oder anderen Kommunikationspartner direkt eine neue Kopie zukommen zu lassen und es sollten ggf. existierende Kopien auf der eigenen Homepage oder ähnliches aktualisiert werden. | |||
== Weblinks == | == Weblinks == | ||
Aktuelle Version vom 13. September 2013, 22:46 Uhr
Dieses HowTo soll kurz erläutern wie man mit GnuPG Subkeys tauscht und warum dies sinnvoll sein kann.
Was sind Subkeys?[Bearbeiten]
Ein OpenPGP-Key besteht aus mehreren Teilen: Der erste Teil ist der sogenannte primary key. Von ihm werden der Fingerprint und die KeyID abgeleitet. Er ist das zentrale Element und als einziges im gesamten Schlüssel nicht austauschbar. Neben ihm existieren die User-IDs, welche Name, Kommentar und E-Mail-Adresse speichern. Der dritte Teil sind die sogenannten Subkeys. Alle Teile eines OpenPGP-Keys können Signaturen tragen. Ablaufdaten und Präferenzlisten liegen in den sogenannten Selbstsignaturen. Die Subkeys sind zusätzlich zum primären Schlüssel benutzte kryptographische Schlüssel. Sie sind dazu gedacht, bestimmte (beim Erzeugen festgelegte) Funktionen, wie Verschlüsselung, zu übernehmen. Dies ist der Standardfall, wenn der primäre Schlüssel zum Beispiel keine Verschlüsselung kann (weil der Algorithmus dies schlichtweg nicht kann).
Die möglichen Aufgaben eines Schlüssels sind: C - Certify - andere Schüssel oder User-IDs beglaubigen; dies kann nur der primäre Schlüssel. S - Sign - signieren, E - Encrypt - verschlüsseln und A - authenticate - nicht-OpenPGP-spezifische Aufgaben wie SSH oder X.509.
Warum Subkeys tauschen?[Bearbeiten]
Subkeys sind genauso wie jeder andere Teil eines Kryptosystems Ziel von Angriffen. Ein regelmäßiges Tauschen, das heißt das Anlegen von neuen und das Verwerfen von alten, kann helfen die Sicherheit zu erhöhen indem das Zeitfenster, in dem die Schlüssel valide sind - und somit auch das Zeitfenster für Angriffe - verkürzt wird.
Das Tauschen der Subkeys ist aber nur bedingt hilfreich, da der primäre Schlüssel nicht getauscht werden kann. Wird dieser kompromittiert, so können Subkeys nach Belieben auch vom Angreifer getauscht werden. Das Tauschen der Subkeys hilft also nur um Angriffe zu erschweren.
Wie tausche ich nun meine Subkeys?[Bearbeiten]
Als erstes öffnen wir den key mittels --edit-key:
$ gpg --edit-key 0x01234567
Danach sollte man etwas sehen ähnlich diesem Listing:
pub 1024D/5E384C0A created: 2007-09-23 expires: never usage: SC
trust: ultimate validity: ultimate
sub 2048g/8A5C6FFE created: 2007-09-23 expires: never usage: E
Hier listet uns GnuPG das Key Material auf. Der erste Eintrag pub gibt den primären Schlüssel an. Der folgende Eintrag sub einen Subkey für Verschlüsselung (usage: E). Diesen Subkey wollen wir im Beispiel ersetzen. Hierzu erzeugen wir erst einmal einen neuen Subkey:
Command> addkey
Wir bekommen nun eine Liste möglicher Subkey Typen angezeigt, diese variiert von GnuPGP Version zu Version und von den eigenen Einstellungen:
Please select what kind of key you want: (2) DSA (sign only) (3) DSA (set your own capabilities) (4) Elgamal (encrypt only) (5) RSA (sign only) (6) RSA (encrypt only) (7) RSA (set your own capabilities)
Da wir ja einen Encrypton key Type g also Elgamal tauschen wollen erzeugen wir nun wieder einen Elgamal key in dem wir mit '4' bestätigen.
Danach werden wir nach der Größe gefragt (nicht bei allen Typen). Wir können einfach den selben wert wie beim Alten schlüssel nehmen oder uns auf den Default verlassen. Zu klein sollte man die Schlüssel allerdings nicht wählen da diese dann leichter zu knacken sind. Zu groß zu wählen ist genauso kontraproduktive da dies nur unnötige Rechenzeit bei allen aktionen bedeutet und keine weitere Sicherheit bringt. Im Gegenteil, von einigen Verfahren ist sogar bekannt das sie bei zunehmender Schlüssellänge wieder unsicherer werden. Auch ist zu bedenken das die doppelte länge nicht die doppelte Sicherheit sondern eine vielfach höhere Sicherheit bedeutet da diese exponentiell und nicht proportional von einander abhängen. Als grobe Richtwerte kann man aber annehmen das kein verfahren mit unter 1024 Bits benutzt werden sollte, Schlüssel über 4096 Bit sind auch wenig sinnig.
Nach der Eingabe der Länge wird man nach dem Verfalldatum gefragt. Je nach Schlüssellänge und Verwendungs Zweck sind in der regel 1 bis 8 jahre gute werte. Im Folgenden entscheiden wir uns im Beispiel für zwei Jahre mittels der Eingabe '2y'.
Zur Sicherheit fragt GnuPG noch einmal nach ob das Datum stimme, dies bestätigen wir mit 'y'.
Als Letztes werden wir gefragt ob wir den Schlüssel wirklich erzeugen wollen. Auch das bestätigen wir mit 'y'.
Nun sollten wir das neue Key listing erhalten:
pub 1024D/5E384C0A created: 2007-09-23 expires: never usage: SC
trust: ultimate validity: ultimate
sub 2048g/8A5C6FFE created: 2007-09-23 expires: never usage: E
sub 2048g/06A765E2 created: 2009-05-03 expires: 2011-05-03 usage: E
Der nächste Schritt ist das festlegen eines neuen Verfalldatums für den alten Subkey. Hierzu müssen wir erst einmal den richtigen subkey auswählen. Dies machen wir mittels des Befehls key' gefolgt von der Nummer des Subkeys. Dabei trägt der erste Subkey die Nummer 1, der zweite die 2 und so weiter. In Falle dieses Beispiels also:
Command> key 1
Danach bekommen wir das Listing nun erneut angezeigt. Der aktive Subkey wird nun mittels '*' markiert:
pub 1024D/5E384C0A created: 2007-09-23 expires: never usage: SC
trust: ultimate validity: ultimate
sub* 2048g/8A5C6FFE created: 2007-09-23 expires: never usage: E
sub 2048g/06A765E2 created: 2009-05-03 expires: 2011-05-03 usage: E
Nun können wir mittels 'expire' das Verfalldatum für den Subkey setzen:
Command> expire
Da es der Erfahrung nach eine weile dauert bis alle ihre Keys einmal Aktuallisiert haben sollten wir einen gewissen Spielraum hier geben. Ich Benutz in meinem Falle einmal 6 Monate, angegeben durch '6m'. GnuPG fragt mich wie oben erneut ob das Datum korrekt ist. Ist es das kann man es bestätigen und man bekommt erneut das key listing:
pub 1024D/5E384C0A created: 2007-09-23 expires: never usage: SC
trust: ultimate validity: ultimate
sub* 2048g/8A5C6FFE created: 2007-09-23 expires: 2009-10-30 usage: E
sub 2048g/06A765E2 created: 2009-05-03 expires: 2011-05-03 usage: E
Di Obigen Schritte können wir nun für alle Subkeys durchführen die wir ersetzen möchten. Sind wir fertig müssen wir den key mittels 'save' speichern:
Command> save
Danach können wir ihn mittels '--send-key' auf die keyserver hoch laden:
$ gpg --send-key 0x01234567
Es kann weiterhin Hilfreich sein dem ein oder anderen Kommunikationspartner direkt eine neue Kopie zukommen zu lassen und es sollten ggf. existierende Kopien auf der eigenen Homepage oder ähnliches aktualisiert werden.
Weblinks[Bearbeiten]
Dieser Artikel ist leider sehr kurz. Also: Sei mutig und mache aus ihm bitte einen guten Artikel, wenn du mehr zum Thema „GnuPG/HowTo: Subkeys tauschen” weißt.
