#+TITLE: Simplicity Arriving Too Late to Save a Drowning PKI? #+AUTHOR: Werner Koch #+EMAIL: wk@g10code.com #+DATE: 2010-11-11 Thu #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en #+OPTIONS: H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t #+OPTIONS: TeX:t LaTeX:nil skip:nil d:nil todo:t pri:nil tags:not-in-toc #+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 path:http://orgmode.org/org-info.js #+EXPORT_SELECT_TAGS: export #+EXPORT_EXCLUDE_TAGS: noexport #+LINK_UP: #+LINK_HOME: #+XSLT: #+STARTUP: beamer #+LaTeX_CLASS: beamer #+LaTeX_CLASS_OPTIONS: [bigger] #+BEAMER_FRAME_LEVEL: 2 #+latex_header: \mode{\usetheme{Singapore}} #+COLUMNS: %40ITEM %10BEAMER_env(Env) %9BEAMER_envargs(Env Args) %4BEAMER_col(Col) %10BEAMER_extra(Extra) # - Für einen Kurs ohne Eisberge # # - Super Crypto aber das System hat Problem unter der Wasserlinie * PK Intro ** Public-Key Kryptographie - Öffentlicher Teil zum Verschlüsseln und zur Prüfung von Signaturen - Geheimgehaltener Teil zum Entschlüsseln und Signieren - Bekannte Algorithmen: RSA, DSA, Elgamal, ECC ** Schlüsselverteilung *** Individuell - per Email - per Diskette etc. *** Über bekannte Webadressen - Speichern des Keys auf der Kontaktseite - Beispiele: CERTs, Datenschutzzentrum *** Über zentrale Server - Das Netz der OpenPGP Keyserver Vorteil: syncronisiert - LDAP Server Nachteile: Unkoordiniert; viele individuelle Server ** Wozu dienen PKIs - Verteilen der Schlüssel - Aufdecken und Verhindern von MitM Angriffen - Widerrufsverwaltung ** Wozu dienen PKIs wirklich - Geschäftsmodell der Serversteuer * PKI Technik ** #+begin_center #+ATTR_LaTeX: width=0.9\textwidth [[./RMS_Titanic_3.jpg]] #+end_center #** Geschichte :B_note: # #Befehlspyriamide die wahrscheinlich aus dem Militar stammt: Klare #Regeln, harte Strafen für Nichteinhaltung dieser Regeln, streng #hierarchisch. X.509 ist so aufgebaut worden. Die Idee war eine globales #System um jedes Objekt (und die meine hier auch Menschen) eindeutig zu #identifizieren. Funktioniert in der Theorie gut, banale #Alltragsfragen machen es aber schon schwieriger: Vertretungsregelung - #dar man seinen Arbeitsplatz jemals wieder tauschen, .... Das System #wird komplexer und komplexer. Aber existiert (in der #Theorie). In der Praxis fehlt die einheitliche Root (DNSSEC weiss von #den Probleme auch zu Berichten). Verislime hat es endgültig ad #Absurdum geführt nachdem erkannt wurde wie man mit dem RSA Patent doch #geld scheffeln kann. # ** X.509: Die göttliche Idee --- Kritik nicht erwünscht /Designed by Committee/ - In den 80er Jahren von der ITU als Authentifizierungsverfahren für das X.500 Verzeichnis entwickelt - Basiert auf einem streng hierarchischen System mit nur einer Wurzel - X.500 wurde niemals wirklich realisiert - X.509 hat in verschiedenen Ausprägungen überlebt aber mit vielen Wurzelinstanzen ** PGP: Hilfe für Graswurzelbewegungen /Ad-hoc Lösung/ - Web-of-Trust (WoT) als Vertrauensmodell von PGP 2. - Dezentraler Ansatz - Funktionsfähig ohne direkte Kosten und ohne zentrale Verwaltung - Weit verbreitet unter Technikern Das WoT reflektierte am besten die Wirklichkeit der Kommunikation vor ~10 Jahren. ** OpenPGP: Wir können PGP und alles andere auch /IETF Kompromiss/ - Basiert auf PGP 2 - Erweitert um nützliche Features - Erweitert um Features für eine X.509 Architektur - Der Standard beschreibt nur Features aber kein PKI **** Notes :B_note: Ermöglicht einige Interessante und nützliche Erweiterungen für das WoT aber aber viele Feature, die zwar gut definierit sind aber nicht wirklich benutzt werden, da sie eigenlich nur ein Superset von X.509 sind und das hat sich ja schon als ungeeignet erwiesen. Aber gut, es soll ja was verkauft werden (PGP an NAI dann an PGP Corp jetzt an Symantec ;-) * Probleme ** #+begin_center #+ATTR_LaTeX: center, width=0.5\textwidth [[file:Titanic_iceberg.jpg]] #+end_center ** Die Standards #+begin_quote Das Schöne an Standards ist, daß jeder sich seinen eigenen aussuchen kann. #+end_quote ** Der X.509 Standard #+begin_verse You can't be a real country unless you have a beer and an airline. It helps if you have some kind of a football team, or some nuclear weapons, but at the very least you need a beer. -- Frank Zappa And an X.509 profile. -- Peter Gutmann #+end_verse - Profile in allen möglichen Varianten und Mischungen - X.509 benutzt ASN.1 basierte Kodierungen ** Der OpenPGP Standard - OpenPGP hat einen eindeutigen Standard - Basiert auf dem IETF Konsens - Implementierungen wurden mit dem Standard entwickelt - Gegenseitige Tests ** Auffinden von Schlüsseln *** X.509 - X.500 sollte es regeln --- gibt es aber nicht - LDAP Server --- nur welcher - Es gibt im LDAP keinen Standard wo die Zertifikate gespeichert sind *** OpenPGP - De-facto Standard: SKS Keyserver (z.B. keys.gnupg.net) - ASCII Armor für Webseiten - OpenPGP Mail Header als Referenz ** Die Kosten - Schulungen für Admins - Zertifikate laufen ab und müßen neu beschafft werden - Webshops arbeiten nicht, da das Zertifikat abgelaufen ist - CRLs sind nicht erreichbar - Hohe indirekte Kosten wg. schlechter Verfügbarkeit ** X.509 Realität Laut dem EFF SSL Obervatory (Defcon 18, 2010): - 1482 CA Zertifikate in Windows oder Firefox - 641 Organisationen - Alleine 300.000 Server Zertifikate von GoDaddy - 192.168.1.2 z.B. von Equifax zertifiziert - Mehr als 6000 Zertifikate für "localhost" - Hunderte von Sub-CAs zertifiziert. ** OpenPGP Realität Funktioniert leidlich, da - kaum technische Probleme - gegenseitige Hilfe üblich ist - _das WoT meist ignoriert wird_ ** Die Wartbarkeit Oh je. ** Die vermeintliche Sicherheit - *Der Standard*: Warnungen werden ignoriert. - Ein Aufschrei sobald das Ignorieren von Warnungen schwieriger gemacht wird - Crypto MiTM sind mehr als selten, da nicht notwendig - Wichtiges Maßnahme z.Z.: 2048 Bit Keys: #+begin_quote Formal notice given of rearrangement of deck chairs on RMS PKItanic #+end_quote ** Das Verständniss - Benutzername + Passwort sind halbwegs verständlich - Erklärung von Zertifikatsketten? - CRL erklären? - Warum Schlüsselauswahl? ** Das User Interface *** PKIs sind ein realitätsfernes System *** Entspricht nicht dem Benutzerverhalten *** Spiegelt nicht die Struktur des Netzes wieder **** Note :B_noteNH: Das eigentliche Problem ist die Realitätsferne des Systems "PKI" - egal in welcher Ausformung. Es entspricht nicht der gewöhlichesn Benutzung des Netzes und der damit implizit erwarteten Eigenschaften (die Mail kann ausser mir und den Empfängern niemand lesen, das Geld kann ich sicher überweisen, mit meinem Namen kann kein Schindluder getrieben werden, die bestellte Ware kommt auch). Im Netz ist man eine Email Adresse (oder ein Facebook Account) und keine Person die sich auf eine PKI abbilden läßt oder lassen will. Es gibt in der Bevölkerung ein weites Misstrauen Telefonnummern und Snail Adressen zu veröffentlichen - das wird verstanden. Die "virtuelle" Identität einer Mailadresse ist aber nicht fassbar. Und damit auch keine PKI; selbst das Web of Trust kann von der breiten Menge der Benutzer nicht verstanden werden. #* Die Betrachtungsweisen # #** The User # #** The Hacker # #** The Admin # #** The Manager # # We can't solve this problem, if he things that spending money on # PKI is a good thing, let him do so. * Lösungen ** Sind Lösungen noch möglich? - Eine radikale Vereinfachung ist gefragt - Die PKI sollte der Struktur des Netzes entsprechen - Warnmeldungen so selten wie möglich und mit Handlungsanweisungen ** 1. Versuch (PKA) /Public-Key-Association/ - Idee: Identitäten (Fingerprints) an das DNS binden. - Sicherheit liegt allein im DNS - Vorhandene und sehr gut skalierende Infrastuktur - Einfaches Auffinden von Schlüsseln - Seit vielen Jahren in GnuPG vorhanden ** 2. Versuch (SSH) /Secure Shell - Admins Liebling/ - Die einfachste PKI die vorstellbar ist - Auch ohne Vergleich der Host-Keys relativ sicher - Änderung des Host-Keys bewirkt deutliche Warnung - Leicht zu verstehen ** Was nun? - Selbstsignierte X.509 Zertifikate - Standard OpenPGP Keys und Option --always-trust - Das SSH Modell wird benutzt - Design eines sehr guten UI für den Fehlerfall ** Was nun? (lynx) *** Webbrowser - Speichern: Domainname, Fingerprint - Keine Prüfung der Zertifikatskette - Warnung falls gespeicherter Fingerprint nicht mehr übereinstimmt ** Was nun? (mail) *** Email etc. - Speichern: Absendername, Fingerprint - Normale Prüfung - Signatur gültig wenn Absendername + Fingerprint übereinstimmen. ** Was nun? (/etc) *** Andere Anwendungen - Software muss i.d.R. öfter erneuert werden als Zertifikate - Signaturprüfung mit eingebettetem Zertifikat - Zertifikat im Binary oder Extradatei *** Spezielle Lösungen für Online Banking etc. - Apps müssen nicht nur für iFoos sein. ** Was muss gemacht werden? *** UI Design *** Plugins für Firefox und Internet Exploder *** Mailer anpasssen *** Wie kann GnuPG helfen? - Neues Trustmodeel (ala PKA) - Datenbank für Mail Adressen und Schlüssel - Kontakthistorie (letzte 5 Kontakte) - Neue Flags und Calls in GPGME um dies zu representieren * Infos ** URLs *** PKA Beschreibung: [[ftp://ftp.g10code.com/people/werner/talks/pka-intro.ps.gz]] *** X.509 Style Guide: [[http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt]] *** EFF SSL Observatory: [[https://www.eff.org/observatory]]