Registrarprotokoll PGP – digitale Signaturen und Technische Abläufe September 2005 Registrar Seminar

Verschlüsselung ältere Verschlüsselungsverfahren (Buchstabentausch, Einmalschlüssel, usw.) sind symmetrische Verfahren, d.h. sie verwenden einen geheimen Schlüssel, den beide Seiten kennen müssen  Problem: Schlüsselübermittlung

Pretty Good Privacy bezeichnet eine Gruppe von asymmetrischen Verschlüsselungsmechanismen, die in verschiedenen (untereinander kompatiblen) Programmen zum Einsatz kommen "asymmetrisch" bedeutet, es existiert ein zusammengehöriges Schlüsselpaar, ein öffentlicher (public) und ein geheimer (private) Key

Programme GnuPG (gpg v1.4.1), Kommandozeile eine freie Implementierung des Standards PGPfreeware (pgp v8.0.2), graphische Oberfläche die Entwicklung wird nun wieder fortgesetzt GnuPP/WinPA (v0.5.13), incl. plug-in für Outlook baut auf GnuPG auf und bietet graphische Oberfläche (Achtung: Bug - Versionsnummer)  Schlüssel und signierte Dokumente sind zwischen den Programmen austauschbar

Einsatzzwecke Verschlüsselung Schutz vertraulicher Inhalte vor dem unbefugten Zugriff für System aber nicht zu bearbeiten Authentifizierung Sicherstellen der Unversehrtheit und Herkunft eines Dokuments Text selbst bleibt weiterhin lesbar

Schlüsselerstellung enthält Name, -Adresse (optional) verwendet definierten Algorithmus (z.B. RSA) hat eine bestimmte Länge (z.B bits) hat einen Gültigkeitszeitraum (z.B. ewig) wird aus echten Zufallszahlen generiert hat einen eindeutigen key fingerprint gültig in Kombination mit der passphrase

-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.4 (AIX) Comment: For info see mQGiBDmH1/QRBAC9GmioBFprPNlgjpJlLoSdx76r/2ViAO3Fd74RhPKWj/NfuMmk QBCkxYdx3acRBtoqik5A6XIV2L5OgAashOdaiXFsypbTVoNxqe/GWIxz235hAfBe eyMx7rUb3RWBNzI7fcYTTCxCbpm8XduIJ951vAw1+8ljEllsoTohceQJuwCg3BU1 ciaJGE2Vlnr/3pfw7KLIzVsD/05a/Q1UI40TKOKy4dMRLKcryHBSnmhUbifuWXYG EjrDmL3SzVwfW8Kc6aKf70dZAC7vbUMGn39jr5WTC10TKxby5B8KoE9yTwlSeU4a N/wYeof1VxTyXHweoy80OfRCaSkHA5RqgVOOTMzyGCTEp5II6pPggydTIwcJJ3Mu CuvWBAC54JT2SrotJ+X1Cm9RVb8jvcb9BXkzK1r+DDhqp2m1Is6SsGCDS+84jSI6 =lKt END PGP PUBLIC KEY BLOCK----- pub 1024D/ D test pgp fingerprint = 5FD D599 1A3F 97BD E D sub 1024g/29C1C3C Schlüssel Jeder Schlüssel besteht aus einem „private“ und einem „public“ Teil, wobei nur der public key veröffentlich wird, der private key bleibt geheim. Dies kann auf sogenannten keyservern geschehen, von denen keys mit einem bestimmten fingerprint angefordert werden können.

Funktionen privatepublicpassphrase signieren XX verifizieren X verschlüsseln X entschlüsseln XX

Signieren Erstellen einer Datei od. Aufruf des PGP-Programms bzw. des plug-ins für den Mail-Clienten Eingabe des Paßwortes  jede nachträgliche Veränderung der Daten macht die Signatur ungültig!

Public Key wird ein public key übermittelt, so muß er vor der Verwendung in den eigenen Schlüsselbund (keyring) importiert werden

Zertifizierung – Clearing House pgp oder X.509 Zertifikate möglich im Gegensatz zum Web of Trust hierarchische Struktur in Österreich geregelt durch BGBl 1 Nr. 190/99 (SigG) Zertifizierungsstelle “Zertifizierungsdiensteanbieter”, § 2 Z 10 SigG z.B.: Datakom -

X509 Zertifikate Qualifizierte Signaturen nur mit zertifizierter Hardware, Dokumenttypen etc. Sichere Signaturen kein persönlicher Kontakt zur Keyerstellung nötig, auch automatisierbar

Praktische Aspekte größter Unsicherheitsfaktor: Wahl des und Umgang mit dem Passwort! nachträgliche „Bearbeitung“ des signierten Textes HTML-Formatierungen, Zeilenlänge und Zeichensätze durch die Mailprogramme (speziell bei Outlook default-Einstellungen) Unterschiede von pgp und gpg beim Umgang mit dem Tabulator (insbesondere am Zeilenende) GnuPA funktioniert nicht korrekt (Version 0.5) Einsatz eines dem Empfänger unbekannten Keys

Notifies keine Notifies bei –falsche/ungültige PGP Signatur –falsches Subject –korruptes XML

Befehle pgp +force -z PASSPHRASE -sta FILE gpg --no-tty --no-secmem-warning --force-v3-sigs -u 3DC2AE5C --passphrase-fd 0 <.PASSPHRASEFILE --clearsign FILE

Nameservercheck - Template alle konfigurierten Nameserver müssen im Template und im DNS sein mindestens 2 verschiedene IP Adressen bei Glue-Records müssen alle im DNS eingetragenen IP Adressen auch im Template sein ist eine remarks-Zeile ausgefüllt, muß es zu jeder nserver-Zeile einen remark geben

Nameservercheck bei Glue-Records müssen alle IP Adressen antworten alle Nameserver Hostnamen (+ SOA für die Zone) müssen bei der NS Abfrage nach dem Domainnamen auf den authoritativen Hosts zurückgeliefert werden (mit aa-flag)

Nameservercheck der MNAME im SOA-RR muß gültig sein die Mailadresse(n) im SOA-RR müssen gültig sein, d.h. RFC 2822 zusätzliche zu 2 IPv4 Adressen können IPv6 Adressen angeben werden