E-Mail-Verschlüsselung mit GPG.  Von der Key-Erzeugung zur verschlüsselten E-Mail. Chemnitzer Linux-Tage 2011. 19.März 201...
Public Key Private Key Public Key Web of Trust E-Mail signieren E-Mail verschlüsseln Schlüssel signieren Key Server Schlüs...
Verschlüsselungsverfahren <ul><li>Symmetrische Verschlüsselung </li><ul><li>Zum Ver- und Entschlüsseln wird der gleiche Sc...
Problem des Schlüsselaustausches </li></ul>
Verschlüsselungsverfahren <ul><li>Asymmetrische Verschlüsselung </li><ul><li>Verschlüsselung mit Public Key
Entschlüsselung mit Private Key </li></ul><li>Geringere Anzahl benötigter Keys (1 pro Person)
Austausch von Schlüsseln vereinfacht </li></ul>
Verschlüsselungsverfahren <ul><li>Hybride Verschlüsselung </li><ul><li>Nachricht wird mit Zufallsschlüssel symmetrisch ver...
Schlüssel wird asymmetrisch verschlüsselt und mitgeliefert </li></ul></ul>
E-Mails verschlüsseln Absender Empfänger <ul><li>Absender verschlüsselt mit Public Key des Empfängers
Empfänger entschlüsselt mit eigenem Private Key
Empfänger muss Private Key besitzen
Absender muss Public Key des Empfängers haben </li></ul>
E-Mails signieren Absender Empfänger <ul><li>Absender signiert mit eigenem Private Key
Empfänger verifiziert mit Public Key des Absenders
Absender muss Private Key besitzen
Empfänger muss Public Key des Absenders haben </li></ul>
Was braucht man für gesicherte E-Mail? <ul><li>Beide Teilnehmer der E-Mail-Kommunikation müssen einen Key besitzen
Veröffentlicht wird nur der Public Key!
Private Key muss geheim bleiben!
Eigener Private Key durch „Mantra“ geschützt
„Mantra“ ist die „Schwachstelle des Systems“, kann aber beliebig lang sein </li></ul>
Verwaltung von Schlüsseln <ul><li>Verwaltung der Keys im Schlüsselbund
Steuerung über Kommandozeile oder grafische Tools
Besteht aus  </li><ul><li>Eigenem Schlüssel (privat und öffentlich)
Fremden Schlüsseln (öffentliche)
Nächste SlideShare
Wird geladen in …5
×

CLT 2011: E-Mail-Verschlüsselung mit GPG

1.940 Aufrufe

Veröffentlicht am

Folien erweitert um drei Fragen (und Antworten), die mir nach dem Vortrag gestellt wurden.

1 Kommentar
0 Gefällt mir
Statistik
Notizen
  • Technisch zwingend nötig für den Versand verschlüsselter Nachrichten (oder die Prüfung von Signaturen) ist zwar nur, dass man den öffentlichen Schlüssel (das Zertifikat) des Empfängers importiert, aber ungemein wichtig für das Sicherheitsniveau des ganzen Prozesses ist, dass man den importierten Schlüssel vor der Verwendung auch verifiziert, also dessen Fingerprint mit dem vergleicht, den man sich aus einer sicheren Quelle (nein, das ist keine Webseite) besorgt, also idealerweise durch persönlichen Kontakt (auf Papier), mit Einschränkungen auch telefonisch. Damit man die Verifikation auch erkennen kann, sollte man den Schlüssel anschließend zertifizieren (mit dem eigenen Schlüssel unterschreiben), im Zweifelsfall erst mal nur mit einer 'lokalen Signatur' (lsign, nicht für die Öffentlichkeit).

    Leider wird auch in dieser Präsentation die Schlüsselgültigkeit (validity) mit dem Zertifizierungsvertrauen (owner trust) verwechselt. Dieses spezielle Vertrauen ist nur für das Web of Trust (WoT) relevant und hat NICHTS damit zu tun, wie sicher man sich ist, dass der Schlüssel zu der fraglichen Person gehört. Leider ist die deutlich suboptimal Nomenklatur der Szene dem korrekten Verständnis nicht dienlich, aber so ist es nun mal. Die Korrektheit der Identität zeigt man an, indem man den fraglichen Schlüssel zertifiziert (d.h. mit seinem eigenen unterschreibt). Auf keinen Fall sollten Leute, die nicht GANZ genau wissen, was sie tun, das Zertifizierungsvertrauen eines fremden Schlüssels auf absolut (ultimate) setzen. Das hat nämlich völlig andere Folgen als typischerweise beabsichtigt, durchaus fatale Folgen.

    Wenn man nicht nur mal rumspielen will, sondern einen (potentiell) langlebigen Schlüssel erzeugt (einen für die Öffentlichkeit), dann lohnt es sich, vorher mal zu sichten, was gute Schlüssel von schlechten unterscheidet, weil sich manches im nachhinein nicht mehr (ohne Unannehmlichkeiten) ändern lässt:

    http://www.openpgp-schulungen.de/kurzinfo/schluesselqualitaet/
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.940
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
10
Kommentare
1
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

CLT 2011: E-Mail-Verschlüsselung mit GPG

  1. 2. E-Mail-Verschlüsselung mit GPG. Von der Key-Erzeugung zur verschlüsselten E-Mail. Chemnitzer Linux-Tage 2011. 19.März 2011 | Vortrag
  2. 3. Public Key Private Key Public Key Web of Trust E-Mail signieren E-Mail verschlüsseln Schlüssel signieren Key Server Schlüsselbund Key Signing Party Private Key Schlüssel signieren Key Server Key Signing Party E-Mail verschlüsseln Web of Trust Schlüsselbund E-Mail signieren ???
  3. 4. Verschlüsselungsverfahren <ul><li>Symmetrische Verschlüsselung </li><ul><li>Zum Ver- und Entschlüsseln wird der gleiche Schlüssel genutzt </li></ul><li>Hohe Anzahl benötigter Schlüssel (1 pro Paar)
  4. 5. Problem des Schlüsselaustausches </li></ul>
  5. 6. Verschlüsselungsverfahren <ul><li>Asymmetrische Verschlüsselung </li><ul><li>Verschlüsselung mit Public Key
  6. 7. Entschlüsselung mit Private Key </li></ul><li>Geringere Anzahl benötigter Keys (1 pro Person)
  7. 8. Austausch von Schlüsseln vereinfacht </li></ul>
  8. 9. Verschlüsselungsverfahren <ul><li>Hybride Verschlüsselung </li><ul><li>Nachricht wird mit Zufallsschlüssel symmetrisch verschlüsselt
  9. 10. Schlüssel wird asymmetrisch verschlüsselt und mitgeliefert </li></ul></ul>
  10. 11. E-Mails verschlüsseln Absender Empfänger <ul><li>Absender verschlüsselt mit Public Key des Empfängers
  11. 12. Empfänger entschlüsselt mit eigenem Private Key
  12. 13. Empfänger muss Private Key besitzen
  13. 14. Absender muss Public Key des Empfängers haben </li></ul>
  14. 15. E-Mails signieren Absender Empfänger <ul><li>Absender signiert mit eigenem Private Key
  15. 16. Empfänger verifiziert mit Public Key des Absenders
  16. 17. Absender muss Private Key besitzen
  17. 18. Empfänger muss Public Key des Absenders haben </li></ul>
  18. 19. Was braucht man für gesicherte E-Mail? <ul><li>Beide Teilnehmer der E-Mail-Kommunikation müssen einen Key besitzen
  19. 20. Veröffentlicht wird nur der Public Key!
  20. 21. Private Key muss geheim bleiben!
  21. 22. Eigener Private Key durch „Mantra“ geschützt
  22. 23. „Mantra“ ist die „Schwachstelle des Systems“, kann aber beliebig lang sein </li></ul>
  23. 24. Verwaltung von Schlüsseln <ul><li>Verwaltung der Keys im Schlüsselbund
  24. 25. Steuerung über Kommandozeile oder grafische Tools
  25. 26. Besteht aus </li><ul><li>Eigenem Schlüssel (privat und öffentlich)
  26. 27. Fremden Schlüsseln (öffentliche)
  27. 28. Angaben zu Vertrauen und Gültigkeit </li></ul></ul>
  28. 29. Einen Key erzeugen <ul><li>Kommandozeile mit gpg
  29. 30. gpg --gen-key
  30. 31. Schritt-für-Schritt geführte Erzeugung des Keys
  31. 32. Grafische Tools, z.B. KGpg </li></ul>
  32. 33. Was dann? <ul><li>Schlüssel selbst signieren, um Echtheit des Schlüssels sicherzustellen
  33. 34. gpg --edit-key Key-ID sign </li></ul>
  34. 35. Was dann? <ul><li>Schlüssel selbst signieren, um Echtheit des Schlüssels sicherzustellen
  35. 36. Widerrufsurkunde erstellen
  36. 37. gpg --output revoke.asc --gen-revoke Key-ID </li></ul>
  37. 38. Was dann? <ul><li>Schlüssel selbst signieren, um Echtheit des Schlüssels sicherzustellen
  38. 39. Widerrufsurkunde erstellen
  39. 40. Key exportieren
  40. 41. gpg --armor --export Key-ID </li></ul>
  41. 42. Was dann? <ul><li>Schlüssel selbst signieren, um Echtheit des Schlüssels sicherzustellen
  42. 43. Widerrufsurkunde erstellen
  43. 44. Key exportieren
  44. 45. Fingerprint und Key-ID bekannt machen </li></ul>
  45. 46. Einen Key veröffentlichen <ul><li>Persönliche Weitergabe
  46. 47. Veröffentlichung auf eigener Homepage, als Text oder Download
  47. 48. Auf Key-Servern, z.B. </li><ul><li>wwwkeys.de.pgp.net
  48. 49. wwwkeys.eu.pgp.net
  49. 50. gpg-keyserver.de </li></ul><li>Die Keyserver synchronisieren sich untereinander! </li></ul>
  50. 51. Andere Keys suchen, finden und importieren <ul><li>Suche nach Key-ID oder nach Namen auf Keyservern
  51. 52. Direkter Import von persönlich erhaltenen oder von Webseiten importierten Keys
  52. 53. gpg --search-keys Key-ID
  53. 54. gpg --recv-keys Key-ID
  54. 55. gpg --import Key-File </li></ul>
  55. 56. Das „Web of Trust“ <ul><li>Importierte Schlüssel können signiert werden
  56. 57. Jedem Schlüssel kann eine (Eigentümer-)Vertrauensstufe zugewiesen werden: </li><ul><li>Unbekannt (q)
  57. 58. Kein Vertrauen (n)
  58. 59. Teilweises Vertrauen (m)
  59. 60. Volles Vertrauen (f) </li></ul><li>Davon abhängig ist das Vertrauen in den Schlüssel selbst
  60. 61. Vertrauen ist vollständig, wenn </li><ul><li>Der Schlüssel selbst oder
  61. 62. Von einem Schlüssel vollsten Vertrauens oder
  62. 63. Von min. 3 Schlüsseln teilweisen Vertrauens unterzeichnet wurde und
  63. 64. Die so entstandene Kette nicht zu lang ist (5 Schritte) </li></ul></ul>
  64. 65. Das „Web of Trust“ <ul>K </ul><ul>C </ul><ul>J </ul><ul>I </ul><ul>A </ul><ul>ICH </ul><ul>E </ul><ul>F </ul><ul>G </ul><ul>D </ul><ul>B </ul><ul>H </ul><ul>m </ul><ul>f </ul><ul>n </ul><ul>m </ul><ul>m </ul><ul>m </ul><ul>f </ul>
  65. 66. Andere Keys signieren <ul><li>Wichtig! Eigentümer authentifizieren </li><ul><li>Über Fingerprint
  66. 67. Über Ausweisdokumente </li></ul><li>z.B. bei Key-Signing-Partys
  67. 68. Signierten Key an Eigentümer zurückgeben
  68. 69. Veröffentlichung sollte durch Eigentümer selbst erfolgen! </li></ul>
  69. 70. Signatur durch CAcert <ul><li>Voraussetzungen: </li><ul><li>eigenes CAcert-Zertifikat
  70. 71. mindestens 50 Assurance Points
  71. 72. Namen im Schlüssel und im Cacert-Zertifikat müssen überein stimmen! </li></ul><li>(Quelle: http://wiki.cacert.org/PgpSigning) </li></ul>
  72. 73. E-Mails verschlüsseln und signieren <ul><li>Text auf Kommandozeile verschlüsseln und als E-Mail versenden
  73. 74. Verschiedene Hilfsprogramme zur Signierung und Verschlüsselung, z.B. </li><ul><li>Kmail / Kontact (KDE) -> Kgpg
  74. 75. Gnome -> Seahorse
  75. 76. Thunderbird -> enigmail
  76. 77. Div. Webmailer -> Browser Add-Ons, wie FireGPG für Firefox </li></ul></ul><ul>Entwicklung eingestellt ---------------------------- </ul>
  77. 78. Fragen? Anmerkungen? Danke für die Aufmerksamkeit! Folien bei Slideshare http://www.slideshare.net/birgithuesken
  78. 79. Fragen und Antworten nach dem Vortrag <ul><ul><li>Mein Key ist abgelaufen. Kann ich trotzdem doch E-Mails damit entschlüsseln? Ja, das geht. Der Key kann immer noch zu Entschlüsselung genutzt werden. Was nicht mehr geht, ist die Verschlüsselung mit dem Public Key und die Signierung mit dem Private Key. Es können nach Ablauf des Schlüssels also keine neuen Verschlüsselungen durchgeführt werden
  79. 80. Mein Key läuft ab, hat aber viele wertvolle Signaturen. Kann ich die retten, in dem ich meinen neuen Key mit dem alten unterschreibe? Nein, das geht nicht. Man kann aber den Key editiert und das Ablaufdatum ändern. </li></ul></ul>
  80. 81. Fragen und Antworten nach dem Vortrag <ul><ul><li>Kann ich einen Key, für den ich keine Widerrufsurkunde habe, den ich aber aus verschiedenen Gründen nicht mehr nutzen kann, von Keyservern entfernen lassen? Nein, aus zwei Gründen: 1. Ich muss den Betreibern der Keyserver nachweisen können, dass ich wirklich der Eigentümer des Keys bin. Und das genau geht mit der Widerrufsurkunde. 2. Einmal veröffentlichte Keys werden nicht von den Servern gelöscht, weil sie ja prinzipiell für die Signatur von anderen Keys verwendet worden sein können. Wird der Key jetzt gelöscht, ist die Signatur nicht mehr nachvollziehbar. Aus diesem Grunde werden übrigens auch widerrufene Keys nicht von den Server gelöscht, sondern nur als „widerrufen“ gekennzeichnet! Dieses Vorgehen sorgt zwar für „Karteileichen“ auf den Keyservern, der Nachteil ist aber nicht so groß wie die ggf. massenweise Erzeugung nicht mehr zuzuordnender Signaturen! </li></ul></ul>
  81. 82. Impressum Birgit Hüsken HS Niederrhein KIS – IT Servicemanagement Reinarzstr.49 47805 Krefeld E-Mail birgit.huesken@hs-niederrhein.de Tel. +49-2151-822-3225 Fax +49-2151-822-85-3225

×