Diverse Anwendungen komplexer kryptographischer und deterministischer Methoden zur Absicherung elektronischer Kommunikation in populären Weitverkehrsnetzen

• Kürzer: Absicherung elektronischer Kommunikation im Internet: Anwendungen kryptografischer und anderer sicherheitstechnischer Methoden
• Noch kürzer: Sicher ins Internet

• Organisation
• Vorlesungsnummer: 260085
• Datum: 06.10.2008-10.10.2008
• Uhrzeit: 10-16 Uhr
• Ort: Einsteinstraße 60, ZIV-Pool 3 (Erdgeschoss)
• URL: https://www.uni-muenster.de/ZIV/Lehre/Internet/
• Skriptmaterialien: am gleichen Ort
• Folien: https://www.uni-muenster.de/ZIV/Lehre/Internet/PublicKeyKryptografieFolien.pdf
• Ergänzende Literaturempfehlungen:
• Clifford Stoll, Kuckucksei, Fischer Taschenbuch, ISBN 3596139848
• Simon Singh, Geheime Botschaften, Dtv Taschenbuch, ISBN 3423330716
• Zahllose Artikel aus der Zeitschrift c't, Heise-Verlag
• Wikipedia-Artikel http://de.wikipedia.org zu »Internetprotokoll« und dort verlinkte Artikel
• Bruce Schneier, Applied Cryptography, Second Edition, John Wiley & Sons, ISBN 0471117099
• David Kahn, The Codebreakers, Scribner Book Company, ISBN 0684831309
• Virtuelle Maschinen:
• Ubuntu804 = Ubuntu 8.04 Installation + Updates + VMware-Anpassung
• WinXP3a = Windows XP Professional deutsch Service Pack 2 + autom. Updates + VMware-Anpassung
• WinXP3b = dito + Service Pack 3 per WindowsUpdate inkl. IE7
• WinXP3c = dito + Absicherung inkl. Internetoptionen
• WinXP3d = dito + Installation Firefox, Thunderbird, AdobeReader + Absicherung

• Motivation
• Wiedergewinnung von etwas Privatsphäre und Anonymität
• Wiedergewinnung von etwas vertraulichem Gedankenaustausch
• Schutz eigener Daten und Interessen
• Beispiel: Siemens verlor 1993/94 Vier-Mrd.-ICE-Südkorea-Auftrag: DGSE las Angebotfax, Alstom bot TGV günstiger
• Beispiel: eigene Verbeamtung
• Aufrechterhaltung der Nutzbarkeit des Rechners
• Vermeidung der Beihilfe zu Kriminalität und Terrorismus
• Vermeidung, das Ziel polizeilicher Ermittlungen zu werden
• Verdächtige unaufgeklärter Strafverfahren bleiben 10 Jahre im Polizeicomputer

• Geschichte des Internet
• http://www.zakon.org/robert/internet/timeline/
• 1957: Gründung ARPA (Advanced Research Projects Agency) im DoD (Department of Defense) nach Sputnik-Schock
• 1961: Erste Theorien zu paketorientierten Netzen
• 1966: Erste Planungen zum ARPANET
• 29.10.1969 22:30 PST (30.10.1969 07:30 MEZ) Erste Verbindung im ARPANET (Los Angeles - Menlo Park, knapp 600 km)
• 1969: 4 Rechner
• 1971: 23 Rechner in 15 Universitäten
• 1973: Erste interntionale Verbindungen
• 1982: Festlegung von TCP/IP (Transmission Control Protocol / Internet Protocol)
• 1984: 1.000 Rechner überschritten
• 1987: 10.000 Rechner überschritten
• 1989: 100.000 Rechner überschritten
• 1989: Vorschlag für konkretes Konzept eines World Wide Web beim CERN
• Dezember 1990: Erste World-Wide-Web-Verbindung beim CERN http://www.w3.org/2005/01/timelines/
• 1991: Entwicklung von PGP durch Phil Zimmermann http://www.philzimmermann.com
• 1992: 1.000.000 Rechner überschritten
• 1995: WWW übernimmt Spitzenposition bzgl. übertragener Datenmenge
• 1996: 10.000.000 Rechner überschritten
• 1996: Öffentliches Aufsehen durch staatliche Zensurmaßnahmen
• China: Nur polizeilich registrierte Nutzer
• Deutschland: Zensur von NetNews-Foren
• Saudi-Arabien: Zugang nur für Universitäten und Krankenhäuser
• Singapur: Religiöse und politische Internetseiten nur nach polizeilicher Registrierung
• Heute sind Zensur und Mitlesen omnipräsent, Beispiel Echelon.
• 2001: 100.000.000 Rechner überschritten
• Mitte 2006: Etwa 440.000.000 Rechner in 171 Ländern
• Ende 2006: über 100.000.000 WWW-Server

• Aufbau des Internet - Einführung
• Sehr gute Beschreibung aller Einzelheiten in Wikipedia http://de.wikipedia.org
• Das Internet = ein Netz von Netzen
• Gemeinsames Protokoll (formalisierte Sprache zwischen Computern) aller Computer in allen Netzen: IP (Internet Protocol)
• Darauf aufbauend viele Protokolle für Anwendungen: HTTP, SMTP, Telnet, FTP, IRC, ICQ, NNTP, ...
• Unabhängig vom Transportmedium: Kupfer, Glasfaser, Funk, Laser, Satellit
• Sogar Brieftauben möglich: RFCs 1149, 2549
• Wer Verbindung zum Internet hat, ist Bestandteil des Internet
• Es gibt keine Institution namens Internet und niemanden, der für das Internet verantwortlich ist
• Es gibt Teilbereiche, für die Institutionen verantwortlich sind:
• ICANN (Internet Corporation for Assigned Names and Numbers) betreibt IANA (Internet Assigned Numbers Authority)
• Regional Internet Registries: RIPE NCC (Réseaux IP Européens, Network Coordination Centre; Europa+Mittlerer Osten)
• Parallel dazu: AfriNIC (Afrika), APNIC (Asien+Pazifik), ARIN (Amerika), LACNIC (Lateinamerika+Karibik)
• Internet seit 1969, WWW erst ab 1991
• Viele Internetcafés bieten kein Internet, sondern nur WWW-Zugang
• WWW und E-Mail sind nur zwei von vielen Teilen des Internet! ICQ, SSH, Internet-Telefonie u.v.a.m.
• Internet nicht kostenlos: WWU+UKM+FH bezahlen etliche hunderttausend Euro pro Jahr für Anschlusskosten

• Aufbau des Internet - IP-Pakete (Internet Protocol)
• IP-Adressen = Adressen von Rechnern (Hausnummern), vier Ziffern aus 0...255
• ALSO: Jeder Rechner muss kennen: Eigene IP-Adresse (evtl. beim Rechnerstart per Rundruf »Wer bin ich?« erfragt)
• PRAXIS: ipconfig
• ALSO: Adressierung IP-Pakete: Von-IP-Adresse, An-IP-Adresse
• Paketinhalte können unterschiedlich interpretiert werden: Protokollnummer im Paketkopf: 1=ICMP, 6=TCP, 17=UDP, 47=GRE
• InternetControlMessageProtocol TransmissionControlProtocol UserDatagramProtocol GenericRoutingEncapsulation
• PRAXIS: ping 128.176.4.4 (ICMP Echo Request)
• Verknüpfung von lokalen Netzen via Router (von Microsoft Gateway genannt) (Haus mit Türen an verschiedenen Straßen)
• Lokale IP-Pakete direkt adressieren, nicht-lokale IP-Pakete an Router
• ALSO: Jeder Rechner muss kennen: Eigene IP-Adresse, Default-Router, Netmask
• Falls eigene IP-Adresse und Ziel-Adresse, durch Netmask betrachtet, gleich sind, lokal adressieren, sonst an Default-Router
• ALSO: Adressierung IP-Pakete: Von-IP-Adresse, An-IP-Adresse, Via-IP-Adresse
• Router nimmt Pakete, ersetzt Via-Adresse durch nächste Via-Adresse gemäß in ihm vorhandener Tabellen
• Router leitet über einen durch die Tabellen festgelegten Netzwerkanschluss (Haustür) weiter
• PRAXIS: Netmask: ipconfig/all, Routen: netstat -r
• Jeder Netzanschluss hat eigene IP-Adresse - ein Rechner kann mehrere IP-Adressen haben (Hausnummern an jeder Haustür)
• Router können Tabelleninhalte über das Internet (BGP über TCP oder eigene Protokolle 89=OSPF usw.), über statische Einträge usw. erhalten
• Pakete durch fehlerhafte Tabellen im Kreis? Schutz durch TTL-Angabe (Time To Live)
• Absender setzt TTL, jeder Router verringert TTL um eins, bei Null wird verworfen und Absender per ICMP (Internet Control Message Protocol) benachrichtigt
• PRAXIS: auf realer Maschine: tracert 128.176.4.4 (oder vorgreifend: tracert www.washington.edu)
• ALSO: Adressierung IP-Pakete: Von-IP-Adresse, An-IP-Adresse, Via-IP-Adresse, Time to Live (dazu Länge, Framentnummer usw.)
• Letzter Router setzt Via-IP-Adresse auf An-IP-Adresse
• ICMP-Pakete (Internet Control Message protocol) für Tests und Fehlermeldung: Echo Request (Ping), Echo Reply, Destination Unreachable, Time Exceeded usw.
• IP-Adressen werden von zentralen Internet-Registraren (RIPE, AfriNIC, APNIC, ARIN, LACNIC) über lokale Registrare (DENIC usw.) blockweise vergeben
• Uni Münster hat 128.176.0.0 bis 128.176.255.255, auch als 128.176.0.0/255.255.0.0 oder 128.176.0.0/16 geschrieben
• Gewisse private IP-Adressbereiche 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 darf jeder verwenden, aber nicht nach außen durchlassen
• IP-Adressbereich 127.0.0.0/8 bezeichnet immer den eigenen Rechner, unabhängig von sonst zugewiesenen IP-Adressen
• Pakete können zwischendurch in Teilpakete fragmentiert werden (Medien haben maximale Paketgröße: MTU = Maximum Transmission Unit)
• Nächste Via-Station re-assembliert Fragmente

• Aufbau des Internet - UDP/IP-Pakete (User Datagram Protocol)
• Ein Rechner kann mehrere Dienste beherbergen: Jeder Dienst hat eindeutige Portnummer (Zimmernummer) aus 1...65536
• Well-Known Port Numbers: Überlicherweise benutzen bestimmte Dienste bestimmte Portnummern, Liste bei IANA
• Mehrere Programme können gleichzeitig auf das Internet zugreifen: Zum Zuordnen der Antwortpakete ebenfalls Portnummern nötig
• ALSO: Adressierung UDP/IP-Pakete: Von-IP-Adresse, Von-Portnummer, An-IP-Adresse, An-Portnummer, Via-IP-Adresse, Protokoll 17=UDP, Time To Live usw.
• Gut für Audio/Video/Telefonie, wo einzelne Paketverluste nicht schaden (gibt Ruckler, oder Knacken)
• Gut für Kommunikation in kleinen Mengen, wo alle Daten in ein Paket passen (Nameserverabfragen usw.)

• Aufbau des Internet - TCP/IP-Pakete (Transmission Control Protocol)
• IP-/ICMP-/UDP-Pakete können verloren gehen (z.B. Router-Überlastung), keine überwachte Verbindung, nur kleine Datenmengen pro Paket
• TCP/IP sorgt für Eingangsbestätigungen und bei deren Ausbleiben für Retransmission von Paketen, virtuelle Verbindungen möglich
• Portnummern wie bei UDP (aber eigenes Protokoll, daher eigener Nummernsatz: Gelbe und blaue Zimmertüren jeweils von 1...65535)
• Sequenznummern zur Paketsortierung (Pakete können sich überholen)
• Flaggen SYN, ACK, FIN, RST und mehr für Pakettyp: Verbindungsaufbau, -bestätigung, Daten, -bestätigung, Verbindungsabbau, -bestätigung, Rücksetzung
• Verbindungaufbau (3-Wege-Handshake): Hin: SYN-Paket, Zurück: SYN+ACK-Paket, Hin: ACK-Paket
• Paketfilter können Verbindungsaufbau unterdrücken, indem sie das SYN-Paket nicht durchlassen
• Verbindungsabbau analog mit FIN statt SYN, gewaltsam mit RST
• Flusssteuerung: Datenpakete werden mit ACK bestätigt, sonst erfolgt Retransmission:
• TCP-Window: Wie viele noch unbestätigte Daten (-pakete) maximal unterwegs sein dürfen
• TCP/IP-Verbindungen werden eindeutig erkannt an Kombination: Client-IP-Adresse, Client-Port, Server-IP-Adresse, Server-Port
• PRAXIS: netstat, netstat -a

• Aufbau des Internet - Funktionsweise von Paketfiltern
• Einzelne IP-Pakete werden untersucht
• Paketfilter können in sichtbaren Routern oder auch unsichtbar in »intelligenten Leitungen« stecken
• Mögliche Entscheidungskriterien: Jede Kombination aus:
• Richtung
• Quell-IP-Adresse, Ziel-IP-Adresse
• Protokollnummer (1=ICMP, 6=TCP, 17=UDP, 47=GRE usw.)
• Bei ICMP: Pakettyp (Echo Request, Echo Reply, Host Unreachable usw.)
• Bei TCP und UDP: Quell-Portnummer, Ziel-Portnummer
• Bei TCP: Flags (SYN, ACK, FIN, RST usw.)
• Weitere Eigenschaften wie Länge, Fragmentierung, Seriennummer usw.
• Externe Informationen wie Uhrzeit usw.
• Bei Paketfiltern auf Quell- oder Zielsystem: Welches Programm hat den Port geöffnet
• Aber nicht: Wer bzw. welches Programm hat diesem Programm den Auftrag gegeben, den Port zu öffnen
• (Trojanische Pferde können Outlook Express oder Internet Explorer bitten, Informationen weiterzugeben)
• Inhalte schlechtes Kriterium, da über beliebig viele Pakete verteilt
• Kein Virenschutz möglich - Virenscanner bleiben unverzichtbar
• Kein Inhaltsfilter/Jugendschutz - dafür Application Firewalls nötig, die den Datenstrom zusammenbauen und komplett analysieren
• Kein Filter aufgrund von WWW- oder Mail-Adressen - diese stehen irgendwo im Datenstrom, dafür wären Application Firewalls nötig
• Kein Filter aufgrund von Rechnernamen - die Pakete enthalten nur die Adressen, viele Namen haben gleiche Adresse
• Beispiel: Eingehende WWW-Anfrage filtern: Eingehendes Paket, Protokoll TCP, Ziel-Portnummer 80, Flags SYN=1 ACK=0 FIN=0 RST=0
• Reaktionsmöglichkeiten: Paket wegwerfen, durchlassen, abändern, Antwortpaket (meist mit RST=Verbindungsabbruch) generieren
• Stateful Packet Filter: Ändert Regeln abhängig von durchlaufenden Paketen
• erlaubt z.B. bestimmte eingehende Pakete nur, wenn vorher durch ein ausgehendes Paket angefordert und Zeitfenster eingehalten
• Auch Lastverteilung denkbar: Pakete verschiedener Verbindungen werden unterschiedlich weitergeleitet (WWU: POP, IMAP, WWW)
• PRAXIS: Windows-TCP-Paketfilterung - sehr eingeschränkte Funktionalität (aktivieren, keine TCP-Ports zulassen, IP-Protokoll nur 47 (GRE) für VPN)
• PRAXIS: Windows-Firewall - eingeschränkte Funktionalität (aktivieren, keine Ausnahmen zulassen)
• Die meisten »Desktop Firewalls« sind nur Paketfilter mit mehr oder weniger eingeschränkter Funktionalität
• PRAXIS: Linux-IPTables - volle Funktionalität
• Reinitialisierung (habe ich in /etc/rc.local, was eigentlich zu spät ist):
• /sbin/iptables -F # Alte Regeln weg
• /sbin/iptables -X 2>/dev/null # Alte Chains weg
• /sbin/iptables -P INPUT DROP # Nichts herein, falls nicht anders gesagt
• /sbin/iptables -P FORWARD DROP # Nichts hindurch, falls nicht anders gesagt
• /sbin/iptables -P OUTPUT ACCEPT # Alles heraus, falls nicht anders gesagt
• /sbin/iptables -N both # Neue Chain (um doppelte Regeln zu vermeiden)
• /sbin/iptables -A INPUT -j both # Hinein-Pakete und
• /sbin/iptables -A FORWARD -j both # Hindurch-Pakete gleich behandeln
• Erlaubnisse:
• /sbin/iptables -A both -i lo -j ACCEPT # Interne Verbindungen (Interface »lo« = localhost)
• /sbin/iptables -A both -p icmp -m icmp --icmp-type any -j ACCEPT # ICMP, mit ping testen
• /sbin/iptables -A both -m tcp -p tcp ! --tcp-flags SYN,RST,ACK SYN -j ACCEPT # Alles TCP außer SYN-Paketen
• Verbotsantworten:
• /sbin/iptables -A both -m tcp -p tcp --dport 113 --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with tcp-reset # ident-Rückfragen
• Ausgefeilter mit Stateful-Filterung (habe ich in /etc/rc.local)
• /sbin/iptables -A both -m state --state ESTABLISHED,RELATED -j ACCEPT # bestehende/assoziierte Verbindungen
• /sbin/iptables -A both -m state --state NEW -i lo -j ACCEPT # lokale Verbindungen
• /sbin/iptables -A both -m state --state NEW -i vmnet+ -j ACCEPT # virtuelle Maschinen
• /sbin/iptables -A both -m state --state NEW -p tcp --dport 113 -j REJECT --reject-with tcp-reset # ident-Rückfragen

• Aufbau des Internet - Rechnernamen, Nameserver
• IP-Adressen nicht nutzerfreundlich, Namen besser
• Nameserver (meist über UDP) wandeln Namen in IP-Adressen um
• Mehrere Namen für einen Rechner möglich: Kanonischer Name, Aliasname (Beispiel: news und sagnix), häufig für dienstbezogene Namen genutzt
• ALSO: Jeder Rechner muss kennen: Eigene IP-Adresse, Default-Router, Netmask, Nameserver
• Mehrere Nameserver wegen Ausfallsicherheit möglich
• PRAXIS: ipconfig/all, ping zivunix, nslookup zivunix
• Mehrere Adressen für einen Namen möglich: Lastverteilung

• Aufbau des Internet - Domain Name Server (DNS)
• Verschiedene Einrichtungen möchten gerne gleiche Namen verwenden: Welcher »www« ist gemeint?
• Abhilfe: Domains: www.jura.uni-muenster.de = Rechner www in 3rd-Level-Domain jura in 2nd-Level-Domain uni-muenster in Toplevel-Domain de
• Rechnernamen ohne Domainangabe werden in eigener Domain gesucht
• ALSO: Jeder Rechner muss kennen: Eigene IP-Adresse, Default-Router, Netmask, Nameserver, eigene Domain
• Domain-Hierarchie unabhängig von Netz-Topologie: Rechner völlig unterschiedlicher Adressen können in einer Domain zusammengefasst werden
• Jede Domain hat einen oder mehrere Domain Name Server
• Jeder Nameserver kennt: Rechner der eigenen Domain, Nameserver unter- und übergeordneter Domains
• Oberhalb der Toplevel-Domainserver gibt es Root-Domain-Server (Politikum: Die meisten indirekt unter Kontrolle der US-Regierung)
• Toplevel-Domains: anfangs: net, org, com, edu, gov, mil; später Länderdomains: de, ch, at, eu usw; neu: info, biz, name usw.
• Politikum: ICANN beschließt über neue Topleveldomains. Zu viel Einfluss der US-Regierung.
• Vergabe von Subdomains durch NIC (Network Information Center) der übergeordneten Domain: uni-muenster.de durch DENIC, jura durch uns
• PRAXIS: nslookup (www, mail, pop, imap; auch mit verschiedenen Domains)

• Aufbau des Internet - Mail-Exchanger und andere Records
• Ein A-Record im Nameserver liefert die IP-Adresse zu einem Rechnernamen
• Ein CNAME-Record liefert zu einem Rechnernamen einen anderen Rechnernamen (Alias, in Münster wenig genutzt)
• Ein NS-Record liefert einen zuständigen Nameserver (meist mehrere)
• Ein MX-Record liefert den Rechnernamen zu einer Maildomain (uni-muenster.de in perske@uni-muenster.de)
• Zu einer Maildomain kann es mehrere MX-Einträge mit gleicher oder unterschiedlicher Priorität geben
• Falls kein MX-Record, dann gilt der A-Record (aber manche Software fehlerhaft)
• PRAXIS: nslookup -q=mx, nslookup -q=any; host -a; dig any (www, www.uni-muenster.de, www.uni-ms.de, ...)
• Rückwärtsauflösung möglich falls ordentlich gepflegt: zu a.b.c.d gehört PTR-Record für d.c.b.a.in-addr.arpa
• PRAXIS: nslookup -q=ptr 4.4.176.128.in-addr.arpa (oder -q=any)

• Aufbau des Internet - NAT (Network Address Translation)
• IP-Adressraum extrem knapp
• NAT ermöglicht vielen Rechnern, unter der gleichen IP-Adresse nach außen aufzutreten
• Lokal können private IP-Adressen verwendet werden
• Ausgehende Verbindungen gehen über NAT-Router, der ersetzt lokale Adressen und Portnummern durch eigene
• NAT-Router merkt sich in Tabelle, wie er Adressen in Antwortpaketen zurückübersetzen muss
• Unaufgeforderte Pakete werden weggeworfen (es sei denn, es gibt dafür spezielle, händisch gepflegte Tabelleneinträge)
• NAT wird benutzt beispielsweise:
• Von VMware, damit die virtuelle Maschine die IP-Adresse der realen Maschine mitbenutzen können
• Von Einwahlroutern, damit die eine zugewiesene IP-Adresse von einem ganzen lokalen Netz benutzt werden kann
• Von Lastverteilern, die eingehende Verbindungen auf verschiedene Server verteilen
• NAT ist schon eine sehr gute Paketfilter-Firewall, weil unaufgeforderte Pakete gar nicht erst ankommen

• Aufbau des Internet - Richtige Firewalls
• Application Firewalls auf Anwendungs-Ebene in DMZ (Demilitarized Zone) zusätzlich zu Paketfiltern
• Datenströme werden zusammengesetzt und per getrennter Verbindung weitergeleitet
• Vom Internet aus sollte nur die Firewall sichtbar sein, die stellvertretend (als Proxy) für die Clients handelt
• Ermöglicht Virenfilterung, Content-Filterung (Jugendschutz) usw.
• Richtige Firewalls bestehen nicht nur aus mehreren Systemen, sondern aus einem komplexen Konzept
• PS: Jugendschutz hat im Grundgesetz höheren Stellenwert als Meinungs- und Pressefreiheit!
• Intrusion Prevention Systeme (wie von der Uni eingesetzt)
• Sammeln Informationen aus durchlaufenden Daten und korrelieren diese
• Aktivieren Paketfilter, sobald verdächtige Konstellationen auftreten

• Gefahren - Angriffswege gegen ein einzelnes System und Sicherungsmaßnahmen
• Einzelnes System heißt nicht unbedingt ein einzelner Rechner

• Gefahren - Böse konstruierte IP-Pakete (WinNuke, Ping O'Death) nutzen Betriebssystemfehler
• Keinerlei Schutzprogramme (Desktop Firewall, Antivirensoftware usw.) auf dem Rechner können helfen!
• Einziger zuverlässiger Schutz: Beseitigung des Fehlers (Betriebssystemaktualisierung)
• Unzuverlässiger Schutz: Externe Paketfilter (nur falls so konfiguriert, dass diese Pakete hängen bleiben)
• Folgen: Denial Of Service oder gar Einbruch mit kompletter Übernahme des Rechners
• PRAXIS: Windows-Update einstellen, Linux-Update einstellen

• Gefahren - Fehler in nicht benötigter Software
• Deinstallieren: Was nicht da ist, kann auch keine Fehler haben
• Gilt insbesondere auch für Windows-Komponenten

• Gefahren - Distributed Denial Of Service
• Die Atombombe des Internets: (Zig)Tausende von Rechnern greifen gleichzeitig auf einen bestimmten Rechner zu
• Die vielen Rechner wurden mit anderen Mitteln übernommen
• Wegen der Überlastung des Netzanschlusses kommen zu wenig echte Pakete zeitgerecht an: Zusammenbruch der Verbindung

• Gefahren - Viren allgemein (keine genaue Definition)
• Software, die sich verbreitet (»Würmer« aus eigener Kraft, »Viren« durch Mithilfe anderer Software oder des Nutzers)
• Software, die Schaden ausübt (gegenüber dem befallenen System oder gar gegenüber Dritten)

• Gefahren - Böse konstruierte IP-Daten nutzern Softwarefehler in Dienstprogrammen
• »Würmer« verbreiten sich auf diesem Weg, ohne dass der Nutzer mithelfen muss
• Zuverlässiger Schutz: Beseitigung des Fehlers (Softwareaktualisierung) oder Abschaltung des Dienstprogramms
• Unzuverlässiger Schutz gegen Buffer-Overflow-Fehler durch Ausführungsverhinderung
• PRAXIS: Windows: Start | Systemsteuerung | Leistung und Wartung | System | Erweitert | Systemleistung | Einstellungen | Datenausführungsverhinderung | für alle aktivieren
• Neuere 64-Bit-Prozessoren können das besser (Not-eXecute-Flag auf Speicherbereiche)
• Sinnvoll wäre: Unnötige Dienstprogramme deaktivieren
• Problem: Hunderte von Autostartmöglichkeiten unter Windows
• Desktop Firewalls schützen gegen Ausnutzung von Softwarefehlern in versehentlich (!) gestarteten Dienstprogrammen
• nur falls entsprechend konfiguriert (wer das kann, weiß meist aber auch den versehentlichen Start zu verhindern)
• dies ist der einzige echte Schutz, den Desktop Firewalls bieten
• Kein Schutz: Antivirensoftware
• Falls das Dienstprogramm nicht mit Administrator-Rechten läuft, sind die Folgen für das befallene System begrenzt
• Niemals irgendwelche Software als Administrator ausführen außer wenn unbedingt notwendig!
• Spam-Verbreitung und Angriffe gegen Dritte sind aber auch ohne Administratorrechte möglich.
• PRAXIS: Eingeschränkte Nutzer einrichten: Start | Systemsteuerung | Benutzerkonten
• (Computeradministrator-Konto Verwalter existiert bereits.)
• Neues Konto erstellen | Nutzer | Weiter | Eingeschränkt | Konto erstellen
• Konto ändern | Verwalter | Kennwort erstellen | Kennwort und Hinweis eingeben | Kennwort erstellen
• Konto ändern | Nutzer | Kennwort erstellen | Kennwort und Hinweis eingeben | Kennwort erstellen
• PRAXIS: Unangenehmen Hintergrund für Verwalter einrichten

• Gefahren - Bootsektor-Viren und Programm-Viren
• Verbreitung über Austausch von Datenträgern (Boot-Disketten) oder Programmdateien, lange Zeit schlimmste Plage
• Betriebssystem (Bootsektor-Virus) bzw. Programm (Programm-Virus) wurde scheinbar normal gestartet
• aber jede eingelegte Diskette und jede beschreibbare Programmdatei wurde infiziert
• Kein Schutz durch Paketfilter - erst die Summe vieler Pakete kann ein Programm-Virus ergeben
• Einziger zuverlässiger Schutz
• Niemals den Rechner starten, wenn fremde Medien in den Laufwerken liegen
• Ausnahmslos niemals unbekannte Programme starten
• Unzuverlässiger Schutz:
• (Nach Erstinstallation) Boot-Reihenfolge im BIOS so ändern, dass nur von der eingebauten Festplatte gebootet wird
• (Nicht gegen Bootviren) On-Access-Antivirensoftware, die jeden Lese- und jeden Schreibzugriff prüft
• Schützt nur gegen bekannte Viren, nicht gegen unbekannte und nur manchmal gegen polymorphe.
• Heutige Viren fast alle polymorph
• Falls keine Backdoor im Virus: Rettung nach Booten vom sauberen Medium durch Virenscanner und -säuberer (z. B. Knoppicillin)
• PRAXIS: Nachschlagen von »Bagle.c« auf http://vil.nai.com (legte perMail-Server durch ca. 100 Verseuchungen pro Sekunde lahm)
• PRAXIS: Virenschutz installieren
• (Als Nutzer) Download von Testviren: http://www.eicar.org/anti_virus_test_file.htm
• (Als Verwalter) Installation von Sophos Antivirus (ohne Sophos Client Firewall)
• (Als Nutzer) Testviren öffnen (testet Scan-on-access)
• (Als Verwalter) Festplatte prüfen (Scan-on-demand)

• Gefahren - Makro-Viren
• Wie Programm-Viren, aber nicht als eigenständige Programme, sondern als Makros in Office-Dokumenten
• Schutzmaßnahmen analog zu Programmviren:
• Niemals unbekannte Office-Dateien starten; On-Access-Antivirensoftware
• Grundsatz: Office-Dokumente niemals im DOC- oder XLS-Format verbreiten, sondern in makrofreie Formate (PDF, RTF, ...) umwandeln
• PRAXIS: Word-Dokument als RTF oder PDF speichern

• Gefahren - E-Mail-Viren
• Eigentlich keine Viren, sondern trojanische Pferde: Werden erst nach bewusst vom Nutzer durchgeführtem Öffnen aktiv
• Verbreitung per automatisch generierter E-Mails
• Empfänger- und Absender- (!) Adressen aus lokalen Adressbüchern, E-Mail-Ordnern, temporären (Internet- und sonst.) Dateien
• Kein Schutz durch Paketfilter - erst die Summe vieler Pakete kann ein E-Mail-Virus ergeben
• Unzuverlässige Schutzmaßnahmen
• Niemals unbekannte Anlagen öffnen - auch wenn sie scheinbar von Bekannten stammen
• E-Mail- und On-Access-Antivirensoftware
• Namenstäuschungen vermeiden: Iloveyou.bmp.exe
• PRAXIS: Vollständige Dateinamen anzeigen lassen (als Verwalter und als Nutzer)
• Start | Systemsteuerung | Darstellung und Designs | Ordneroptionen | Ansicht | Erweiterte Einstellungen | Erweiterungen bei bekannten Dateitypen ausblenden: AUS | Übernehmen | Alle zurücksetzen | Ja | OK
• PRAXIS: In der Registry alle NeverShowExt umbenennen nach ExNeverShowExt (ca. 11 Einträge)

• Gefahren - WWW-Viren
• Eigentlich trojanische Pferde, die zusammen mit dem Inhalt von bösartigen WWW-Seiten untergeschoben werden
• Häufig unter Ausnutzung von Browser-Fehlern
• Unzuverlässige Schutzmaßnahmen
• Beseitigung der Browserfehler (Softwareaktualisierung)
• Defensive Browser-Konfiguration
• Zum Surfen eine virtuelle Maschine benutzen
• Niemals Links aus zweifelhafter Quelle folgen
• IE hat gegenüber alternativen Browsern aufgeholt; alle haben Sicherheitsprobleme
• PRAXIS: Absicherung des Internet Explorer nach Anleitung

• Gefahren - Dialer
• Trojanisches Pferd oder Virus, welches als Schadfunktion teure 0190, 0900- oder 118-Nummern anruft
• Gleiche Schutzmaßnahmen wie gegen andere Viren und trojanische Pferde
• Anti-Dialer ist analog zu Antivirensoftware ein mäßig guter Schutz, kann umgangen werden
• Besser und viel komfortabler: DSL-Flatrate benutzen, Modems und ISDN-Karten raus, Verbindung zum Telefonnetz physisch trennen

• Gefahren - Spyware
• Trojanisches Pferd, welches neben der gewünschten Funktion auch Informationen an den Hersteller oder Dritte weitergibt
• Gleiche Schutzmaßnahmen wie gegen andere Viren und trojanische Pferde
• Gegen dumme Spyware schützen Desktop Firewalls, die den Programmnamen kontrollieren
• Kluge Spyware benutzt zugelassene Programme (Internet Explorer, svchost usw.) zur Datenübermittlung
• Anti-Spyware ist analog zu Antivirensoftware ein mäßig guter Schutz
• Selbst seriöse Softwarehäuser wie Microsoft, Opera u.a. stellen Spyware her (wieso benutzen Sie noch Windows? Das ist Spyware!)

• Gefahren - Phishing
• Keine Weiterverbreitung, Keine Schadfunktion, trotzdem trojanisches Pferd
• Nutzer wird dazu verleitet, auf einer nicht vertrauenswürdigen WWW-Seite schützenswerte persönliche Daten (PINs, TANs) preiszugeben
• Zuverlässige Schutzmaßnahmen
• Niemals Links zum Homebanking folgen, immer die richtige Adresse selbst eintippen (ggf. Lesezeichen)
• Gehirn einschalten! Banken verbreiten niemals Mitteilungen per E-Mail!
• Zertifikat genauestens prüfen (später)
• Zusätzlich für Homebanking eine eigene virtuelle Maschine benutzen, die bei jedem Start den gleichen Zustand besitzt

• Gefahren - Social Engeneering
• »Hier ist Ihre Bank, es gibt ein Problem, wir helfen Ihnen, können Sie uns drei TANs geben?«
• Kann sich alles verdammt echt anhören
• Niemals weich werden, niemals PINs, TANs oder auch nur Kontonummern oder ähnliche Daten herausgeben.
• Analog bei Inkasso-Aufforderungen usw.
• Es sind schon Betrugsopfer deshalb auf dem Schaden sitzen geblieben, weil sie dem Betrüger ihre Kontonummer gegeben haben (Gerichtsurteile).

• Gefahren - Weitere betrügerische Aktionen
• Polizeimitteilungen per E-Mail-Kettenbrief: Niemals weiterleiten, niemals beachten
• Hoaxes: Virenwarnungen per E-Mail-Kettenbrief: Niemals weiterleiten, niemals beachten
• Die angeblichen Reparaturanleitungen schädigen in Wirklichkeit das eigene System
• Keine seriöse Einrichtung startet Kettenbriefe
• Geschäftsangebote, Hilfegesuche bei Geldtransfer usw.
• Genau wie in der Zeitung: Unseriös, niemals beachten
• »Nigeria-Connection« und ähnliche: Die »Mithilfe« ist in Wirklichkeit Geldwäsche.
• Jobangebote mit leichtem Verdienst, Kaufangebote u. ä.: Häufig soll man erst Geld bezahlen und hört dann nie wieder was
• Andere Formen:
• Bei eBay zuviel bezahlt: Rückerstattung auf anderes Konto = Geldwäsche; Nur an Ursprungskonto zurück!
• Immer gesundes Misstrauen behalten: Sie sind über das Internet viel einfacher für die Gauner erreichbar

• Gefahren - Bedienungsfehler
• Die Ursache für 99 % aller Probleme befindet sich zwischen Bildschirm und Rückenlehne
• Beschränkung der Folgen
• Regelmäßiges Backup durchführen
• Neuinstallation häufig schneller als Reparatur, aber Konfiguration nachzuvollziehen ist schwierig
• Mehrstufiges, aber handhabbares Backup-Konzept angepasst an individuelle Anforderungen entwickeln
• Restore üben!
• Arbeiten als eingeschränkter Nutzer
• Problem: Zu sichernde Dateien liegen bei Windows quer über das ganze System verteilt
• Image-Backup alle paar Wochen ernsthaft in Betracht ziehen: Booten von Knoppicillin oder Life-CD
• mount /dev/hda /mnt ; dd if=/dev/zero of=/mnt/null bs=10M ; rm /mnt/null ; umount /mnt # spart Platz beim Komprimieren
• mount /dev/hdb1 /mnt ; gzip </dev/hda >/mnt/hda-datum.gz ; umount /mnt # kopiert komprimiert
• mount /dev/hdb1 /mnt ; gunzip </mnt/hda-datum.gz >/dev/hda ; umount /mnt # restauriert
• Vor dem Einschlafen starten

• Gefahren - Datenverlust durch Defekt oder Diebstahl
• Backup-Medien wegschließen (feuersicherer Tresor)
• Backups an getrennten Orten aufbewahren

• Gefahren - Datenpreisgabe durch Diebstahl
• Backup-Medien wegschließen (feuersicherer Tresor)
• Backup-Daten verschlüsseln (entfällt bei verschlüsselten Dateien, falls zum Backup nicht entschlüsselt wird)
• Verschlüsselte Backups sind wertlos, wenn der Schlüssel fehlt
• Backups von verschlüsselten Daten lassen sich nicht leider komprimieren
• Aber manches Verschlüsselungswerkzeug komprimiert vor dem Verschlüsseln
• Komplettes Dateisystem oder zumindest vertrauliche Dateien verschlüsseln
• Verschlüsselung hilft nicht gegen Online-Angriffe
• PRAXIS: Komplett verschlüsseltes Ubuntu aus Alternate Install CD aufsetzen

• Gefahren - Physische Gewalt
• Bauliche Sicherungsmaßnahmen

• Zusammenfassung der Sicherungsmaßnahmen gegen Angriffe auf einzelnes System
• Betriebssystem- und Softwareaktualisierung - das Fundament der ganzen Burg, extrem wichtig
• Vernünftige Softwarekonfiguration, welche ungewolltes Aktivieren von Schadprogrammen erschwert - die Burgmauer, extrem wichtig
• Nicht als Administrator, sondern als eingeschränkter Nutzer arbeiten - Schießpulver wegschließen, extrem wichtig
• Unangenehmen Hintergrund für Verwalterkonten einrichten - das Warnschild an der Pulverkammertür, wichtig
• Gehirn und gesunden Menschenverstand einschalten und nicht auf alles doppelklicken - die Wachen am Burgtor, extrem wichtig
• Dateinamen vollständig anzeigen - Maskierungsverbot, damit die Burgtorwachen nicht getäuscht werden
• Antiviren-Software - sehr wichtig, Wachsoldaten im Inneren der Burg gegen Feinde, die die Mauer bereits überwunden habe, aber nur gegen bekannte Feinde
• Datenausführungsverhinderung - wichtig, verstärkt das Fundament durch Leimmatten, an denen Durchbuddler hängen bleiben, aber nur bei bestimmten Löchern
• Desktop Firewall / Paketfilter (eingehend) - versperrt versehentlich geöffnete Türen, aber nur diese - als Zusatzschutz sinnvoll
• Desktop Firewall / Paketfilter (ausgehend) - versperrt nur dummen Halunken den Weg ins Internet - nur Schadensbegrenzung im Katastrophenfall
• Anti-Dialer-Software - versperrt nur dummen Halunken den Weg ins Telefonnetz - nur Schadensbegrenzung im Katastrophenfall
• Anti-Spyware-Software - Hilfstruppen für Wachsoldaten (Antiviren-Software), erkennt vielleicht weitere Feinde
• Regelmäßiges vernünftig organisiertes Backup = Bergfried mit Fluchttunnel in neue Burg, letzter Rückzug im Katastrophenfall - extrem wichtig
• Verschlüsselung = Optimale Tarnung bei der Flucht vor Räubern, individuell unterschiedlich wichtig
• Deinstallation nicht benötigter Software - keine Bäume oder Bauwerke in der Nähe der Burgmauer, die den Feinden nützen könnten
• NAT-Router - eine Burg um die Burg, schützt auch gegen böse konstruierte IP-Pakete u. ä., extrem wichtig
• Bauliche Maßnahmen gegen Diebstahl und Feuer
• Schulung zur Wachsamkeit

• Hinweise zu Firefox 3 und Thunderbird 2
• Absicherung Firefox 3
• Extras | Einstellungen:
• Allgemein: Startseite einstellen
• Inhalt | JavaScript | Erweitert...: Alles aus
• Datenschutz | Cookies: Nicht von Drittanbietern, nur bis Firefox geschlossen wird
• Sicherheit: Passwörter nicht speichern
• Sicherheit | Warnmeldungen | Einstellungen: »wenn eine verschlüsselte Seite« aus, sonst ein
• Firefox erkennt häufig nicht, wenn verschlüsselte Seiten unverschlüsselte Elemente enthalten
• Kompatibilität Thunderbird 2 mit Rest der Welt
• Extras | Einstellungen
• Verfassen | Allgemein | Ein: ... "quoted-printable" ... verwenden
• Ansicht | Formatierung | Schriftarten und Kodierung... | Zeichenkodierungen
• Ausgehende Nachrichten: Unicode (UTF-8)
• Eingehende Nachrichten: Westlich (ISO-8859-1)
• Ein: Standard-Zeichenkodierung für Antworten verwenden
• Extras | Konten | Verfassen & Adressieren:
• Aus: Nachrichten im HTML-Format verfassen
• Thunderbird 2: Sicherungsmaßnahmen:
• Extras | Einstellungen
• Datenschutz | Passwörter: Wenn überhaupt Passwörter gespeichert werden, dann natürlich mit Master-Passwort absichern!
• Erweitert | Allgemein: Aus: Bei Adressen aus dem Adressbuch nur den Namen anzeigen
• Erweitert | Allgemein | Empfangsbestätigungen: Nie eine Empfangsbestätigung senden
• Extras | Konten | ... | Server-Einstellungen
• Wenn vom Provider angeboten: Verschlüsselte Verbindung verwenden (ZIV: SSL)
• Wenn vom Provider angeboten: Sichere Authentifizierung (ZIV: nein)
• Extras | Konten | ... | S/MIME-Sicherheit
• Zertifikate verwenden, wie später im Kurs gelernt
• Extras | Konten | Postausgang-Server | ... | Bearbeiten...
• Wenn vom Provider angeboten: Verschlüsselte Verbindung verwenden (ZIV: TLS)

• Spuren im Netz
• Im Internet gibt es weniger Anonymität als auf der Straße: Jeder darf Kameras aufstellen
• Nationale Datenschutzgesetze im internationalen Netz de facto unwirksam
• Echelon (USA+UK hören gesamten transatlantischen Daten- und Fernmeldeverkehr ab)
• Jeder protokolliert: Einwahl, Webserver, Mailserver, häufig sogar Router
• Anhand der Logs sind IP-Adressen den Personen zuzuordnen
• In Deutschland Fernmeldegeheimnis: Herausgabe nur auf richterliche Anordnung gemäß §§ 100 StPO ff.
• Aber auch Vorratsdatenspeicherung
• Einbrecher sind meist nicht an Daten interessiert, sondern daran, sich hinter Ihnen zu verstecken!
• Sorglosigkeit ist Beihilfe zum Terrorismus: Schon jetzt existieren Bot-Netze mit 100.000 befallenen fernsteuerbaren Rechnern.
• Virenschreiber werden durch Spammer bezahlt; Spammer versenden Millionen Mails für 100 Dollar

• E-Mail-Kopfzeilen
• Geben Hinweise auf den Ursprung einer E-Mail, zeigen viele, meist fälschbare Spuren
• Ausführlich: http://www.uni-muenster.de/ZIV/Hinweise/EMailBelaestigung.html

• Angriffswege gegen Kommunikation verschiedener Systeme und Sicherungsmaßnahmen
• Unabhängig davon ob einzelnes IP-Paket, E-Mail, Webseite oder Sonstiges

• Probleme bei der Nachrichtenübermittlung
• Problem: Die Nachricht kommt nicht beim Empfänger an
• Problem: Die Nachricht wird unterwegs von Dritten gelesen
• Problem: Die Nachricht wird unterwegs von Dritten geändert
• Problem: Dritte senden eine falsche Nachricht ab

• Problemlösung Kryptographie
• Verschlüsselung
• verhindert Lesen durch Dritte
• Elektronische (Digitale) Signatur
• beweist die Identität des Absenders
• beweist die Unverändertheit der Nachricht
• Hilft nicht gegen Verlust einer Nachricht

• Symmetrische Kryptographie (Secret-Key-Systeme)
• Meist gleicher Schlüssel zum Verschlüsseln und Entschlüsseln
• Meist gleicher Schlüssel zum Signieren und Verifizieren
• Je zwei Teilnehmer benötigen einen Schlüssel
• Beide müssen Schlüssel streng geheim halten
• Anzahl Schlüssel wächst quadratisch mit der Teilnehmerzahl

• Wie helfen Secret-Key-Systeme?
• Verschlüsseln verhindert Abhören
• Verschlüsseln = Signieren (bei geeigneten Systemen), daher
• Erfolgreiches Entschlüsseln beweist Unversehrtheit
• Erfolgreiches Entschlüsseln beweist korrekten Absender
• DEMO: an Caesar-Chiffre

• Eigenschaften von Secret-Key-Systemen
• Rechenoperationen sind schnell
• Beliebige Zahlen als Schlüssel
• ab 128-Bit-Schlüssel gelten als sicher (2 hoch 128 Möglichkeiten)
• Weniger als 64 Bit sind unsicher (alle Schlüssel ausprobieren)
• Beispiele
• Geheimschriften, DES, RC5, IDEA, Blowfish, Rijndael (AES)
• Asymmetrische Kryptographie (Public-Key-Systeme)
• Nicht Einzelschlüssel, sondern Schlüsselpaare
• Getrennte Schlüssel zum Verschlüsseln und Entschlüsseln
• Getrennte Schlüssel zum Signieren und Verifizieren
• Aus einem Schlüssel kann der andere nicht berechnet werden
• Schlüssel zum Entschlüsseln und Signieren streng geheim
• Schlüssel zum Verschlüsseln und Verifizieren öffentlich
• Pro Teilnehmer nur ein Schlüsselpaar (oder zwei)
• Anzahl Schlüssel wächst linear mit Teilnehmerzahl
• Bildlich: Offene Vorhängeschlösser werden verteilt, nur der Empfänger hat den Schlüssel

• GRAFIK: Signieren und Verschlüsseln + Entschlüsseln und Verifizieren

• Wie helfen Public-Key-Systeme?
• Nur ein bis zwei Schlüsselpaare pro Teilnehmer
• Verschlüsseln und Signieren unabhängig voneinander
• Verschlüsseln verhindert Abhören
• Verifizieren der Signatur beweist korrekten Absender
• Verifizieren der Signatur beweist Unversehrtheit
• Neue Gefahr: Unterschieben falscher öffentlicher Schlüssel

• Eigenschaften von Public-Key-Systemen
• Rechenoperationen sind meist sehr langsam (große Zahlen)
• Nur Zahlen mit bestimmten Eigenschaften als Schlüssel
• Systeme auf Basis großer Primzahlen
• Beispiele: RSA, ElGamal/DH, Rabin, ...
• 2048-Bit-Schlüssel gelten als sicher
• 512-Bit-Schlüssel werden unsicher (Faktorisierung)
• Systeme auf Basis elliptischer Kurven
• 170-Bit-Schlüssel gelten als sicher
• Andere Systeme, auch Nur-Signier-Verfahren: DSS, ...

• Misch-Systeme
• Vorteile beider Systeme nutzen
• Secret-Key-Systeme für große Datenmengen (Geschwindigkeit)
• Public-Key-Systeme für kleine Datenmengen (Schlüsselverwaltung)
• Kryptografische Essenzen zur Datenreduktion

• Kryptographische Essenzen (Fingerprints)
• Mathematische Hash-Funktion, Einweg-Funktion
• Erzeugt aus Texten (Daten) beliebiger Länge eine Essenz
• Essenz sehr kurz, meist 128 oder 160 Bit
• Es ist praktisch unmöglich,
• zu einer gegebenen Essenz einen Text zu finden
• zwei ungleiche Texte mit gleicher Essenz zu finden (Geburtstagsangriff)
• QUIZ: Wie viele Leute in einem Raum, bis >50% für gleichen Geburtstag? 23
• DEMO: 4 Ich-schulde-100-Texte und 4 Ich-schulde-10000-Texte = 16 Kollisionsmöglichkeiten
• Bei je 2^64 Texten (64 Leerzeichen einfach oder doppelt) = 2^128 Kollisionsmöglichkeiten
• Abhilfe: Jedes nicht selbst erstellte Dokument vor dem Signieren leicht verändern
• Dadurch Fälschungssicherheit auf 1:2^128 statt 1:2^64 usw.
• Beispiele: MD2, MD5, SHA-1, RIPE-MD, ...

• GRAFIK: Signieren und Verschlüsseln (1-6) + Entschlüsseln und Verifizieren (1-6)

• Signieren
• Mit geheimem Schlüssel des Senders
• Essenz aus Nachricht bilden
• Essenz mit Public-Key-System verschlüsseln, ergibt Signatur

• Verifizieren
• Mit öffentlichem Schlüssel des Senders
• Gefahr: Habe ich den richtigen Schlüssel?
• Signatur entschlüsseln
• Zum Vergleich: Essenz aus Nachricht bilden
• Wenn beide Ergebnisse gleich, ist Verifizieren gelungen.

• Verschlüsseln
• Mit öffentlichem Schlüssel des Empfängers
• Gefahr: Habe ich den richtigen Schlüssel?
• Mit Zufallszahl für Secret-Key-System
• Gefahr: Zufallszahl muss zufällig sein
• Nachricht (mit Signatur) mit Secret-Key-System verschlüsseln
• Auch bei mehreren Empfängern nur einmal
• An alle Empfänger übermitteln
• Zufallszahl mit Public-Key-System verschlüsseln
• Für jeden Empfänger einzeln
• An jeden (oder alle) Empfänger übermitteln

• Entschlüsseln
• Mit geheimem Schlüssel des Empfängers
• Die mit dem eigenen Schlüssel verschlüsselte Zufallszahl heraussuchen
• Zufallszahl mit Public-Key-System entschlüsseln
• Nachricht (mit Signatur) mit Secret-Key-System entschlüsseln

• Anwendungen, die Public-Key-Systeme nutzen
• PGP-Familie für E-Mail u. a.
• PGP (Pretty Good Privacy)
• GnuPG (Gnu Privacy Guard), auch in perMail oder Enigmail für Mozilla Thunderbird
• PRAXIS: Schlüsselerzeugung mit perMail
• PRAXIS: Mit perMail Schlüssel an andere Kursteilnehmer versenden
• PRAXIS: Mit perMail signierte und/oder verschlüsselte E-Mails an andere Kursteilnehmer versenden
• X.509-Familie für alles Mögliche
• S/MIME (Secure Multipurpose Internet Mail Extensions) für E-Mail:
• Microsoft Outlook,
• Mozilla Thunderbird
• SSL (Secure Sockets Layer) für WWW, POP, IMAP, News usw.
• Bei SSL hat häufig nur der Server ein Schlüsselpaar
• SSH (Secure SHell) statt Rlogin (Telnet), Rsh, Rcp (Ftp), Rdist
• SSH zum Tunneln von X11- und anderen Verbindungen
• u. v. a. m.

• Schlüsselverwaltung bei Public-Key-Systemen
• Key-Server mit öffentlichen Schlüsseln
• Gefahr: Untergeschobener Schlüssel mit falscher Identität
• Mögliche Problemlösungen
• »Sichere« Übergabe des Schlüssels
• Persönliche Schlüsselübergabe oder
• Unsichere Schlüsselübergabe plus persönliche Übergabe der Essenz des Schlüssels
• Ausweiskontrolle, falls nicht persönlich bekannt
• Telefon-Vergleich der Essenz des Schlüssels (bei bekannter Stimme)
• Beglaubigungen (Zertifikate) vertrauenswürdiger Dritter
• PRAXIS: https://mein-ziv.uni-muenster.de/testca/
• PRAXIS: CA-Zertifikat mit Firefox importieren und gültig schalten
• PRAXIS: Fingerprintkontrolle (absolut wichtig bei Homebanking, später mehr)
• MD5 Fingerprint=34:BC:0E:B8:BE:49:B8:18:2E:0F:B4:49:9A:3B:62:BB
• SHA1 Fingerprint=AF:FF:14:61:66:A5:FA:66:2F:1D:46:51:A2:64:B3:F5:58:AA:25:E2
• PRAXIS: CA-Import in Thunderbird (Firefox: Rechtsklick, Ziel speichern unter; Thunderbird-Import)
• PRAXIS: PKCS#12-Datei aus Firefox nach Thunderbird (oder Outlook oder ...)
• PRAXIS: Signierte und später verschlüsselte E-Mails mit Thunderbird

• Zertifikate
• Zertifikate sind elektronisch signierte Beglaubigungen
• Festgelegte Formate (PGP, X.509, ...)
• »Dieser öffentliche Schlüssel gehört zu dieser Identität«
• Weitere Angaben (Gültigkeitsdauer, ...)
• Jeder kann Zertifikate ausstellen
• Nicht obskuren Firmen Geld in den Rachen schmeißen!
• Zur Kontrolle der öffentliche Schlüssel des Ausstellers
• Aus sicherer Quelle besorgen!
• Empfänger entscheidet, ob er dem Aussteller traut
• Ohne Vertrauen das Zertifikat nicht akzeptieren!

• Zertifizierung
• Inhaber gibt öffentlichen Schlüssel »sicher« an Zertifizierer
• Zertifizierer erstellt Zertifikat mit geheimem Schlüssel
• Inhaber oder Zertifizierer geben »unsicher« Zertifikat weiter

• GRAFIK: Zertifikate (1-6)

• Zertifikatkontrolle
• Partner erhält »sicher« öff. Schlüssel des Zertifizierers Z
• Partner erhält »unsicher« öff. Schlüssel und Zertifikat von X
• Partner verifiziert Zertifikat mit öff. Z-Schlüssel
• Partner vertraut Zertifizierer
• Dann weiß Partner, dass der öff. Schlüssel wirklich X gehört

• Zertifizierungsstellen
• CA = Certification Authority
• Zertifikate können unter Beachtung unterschiedlich hoher Sicherheitsanforderungen ausgestellt werden
• Je höher die Sicherheitsanforderung, desto höher die Vertrauenswürdigkeit (Beweiswert) der Zertifikate
• Sicherheitsanforderungen werden in Zertifizierungsrichtlinien (Policy) beschrieben
• Zertifizierungsstellen verpflichten sich, Zertifikate nur unter Beachtung der Policy auszustellen

• Zertifizierungsketten
• Nicht immer ist »sichere« Quelle für öffentlichen Zertifizierungs-Schlüssel erreichbar
• Aber öffentlicher Zertifizierungs-Schlüssel kann selbst durch Dritten zertifiziert sein
• Und dessen Schlüssel durch einen Vierten usw.
• OK, falls:
• Letzter öffentlicher Schlüssel der Kette aus »sicherer« Quelle erhalten
• Und jedes Zertifikat der Kette erfolgreich verifiziert
• Und jeder Zertifizierer der Kette voll vertrauenswürdig
• Bei PGP ist man selbst das Ende der Kette

• GRAFIK: Zertifikate (7)

• Zertifizierungsketten
• Ich weiß, der Schlüssel von X ist echt (valid), denn:
• Ich habe »unsicher« Schlüssel und Zertifikat von X erhalten
• Und das Zertifikat von X wurde von Z ausgestellt
• Und ich vertraue (trust) den Zertifikaten von Z
• Und ich weiß, der Schlüssel von Z ist echt (valid), denn:
• Ich habe »unsicher« Schlüssel und Zertifikat von Z erhalten
• Und das Zertifikat von Z wurde von Z2 ausgestellt
• Und ich vertraue (trust) den Zertifikaten von Z2
• Und ich weiß, der Schlüssel von Z2 ist echt (valid), denn:
• Ich habe den Schlüssel von Z2 »sicher« erhalten (oder bin Z2)

• Zertifizierungshierarchien
• Ketten können in Hierarchien gegliedert werden
• Bei PGP möglich, bei X.509 quasi zwingend
• Beispiel: DFN-Zertifizierungshierarchie
• 1. Telekom Root CA
• 2. DFN-PCA (Policy Certification Authority)
• 3. WWUCA, DFN-User-CA, andere CAs in den Einrichtungen
• 4. Nutzer, WWW-Server, ...
• Kreuz-Zertifizierungen zwischen Hierarchien (DFN, c't, ...)
• PRAXIS: Zertifikate von http://www.uni-muenster.de/WWUCA/ importieren
• PRAXIS: Zertifizierungsketten mit Firefox nachvollziehen:
• Manuell anhand DFN-PKI-Hierarchie
• Halbautomatisch beim Überprüfen einer signierten E-Mail

• Standard-Format X.509
• Verwendung bei S/MIME (E-Mail), SSL/TLS (WWW-Server), ...
• Problem bei X.509-Implementierungen: Verordnetes Vertrauen
• Oft nicht einstellbar, wem ich traue und wem nicht
• Falls ich der Wurzel traue, traue ich allen Gliedern
• Gängige WWW-Browser enthalten bereits öffentliche Schlüssel etlicher Zertifizierungsstellen
• Diesen Ausstellern wird vom Browser automatisch getraut
• Sehr sinnvoll für geschlossene Nutzergruppen
• Einfachere Handhabung durch fehlende Einstellmöglichkeiten
• Heutige Programme ungünstig für weltweite E-Mails

• Widerruf
• Bei Kompromittierung vor Ablauf der Gültigkeit
• PGP
• Widerruf durch Schlüsselbesitzer
• Signiert mit geheimem Schlüssel des Inhabers
• Verteilung über Keyserver usw. unzuverlässig
• X.509
• Widerruf durch Zertifizierungsstelle
• Signiert mit öff. Schlüssel der Zertifizierungsstelle
• Verteilung über CRLs (Certificate Revocation List)
• periodisch, Gültigkeitsdauer von CRLs beschränkt
• Alternative: Online Certificate Status Protocol OCSP
• PRAXIS: CRLs von DFN-PCA und WWUCA importieren

• Verbindungsaufbau mit einem SSL-Server
• Abhörsichere Verbindungen mit HTTP- (WWW-) Servern
• genauso: SMTP, POP, IMAP (E-Mail), NNTP (NetNews), ...
• Nur Server benötigt Schlüsselpaar mit Zertifikaten
• Client kann sich mit eigenen Zertifikaten ausweisen
• Transport Level Security TLS 1.0 = RFC 2246, vormals SSL
• Keine Datenübertragung, bevor Verschlüsselung etabliert ist:
• Client: Hallo, ..., diese Methoden sind akzeptabel; Kommen
• Methoden = Verschlüsselung, Wer sich ausweist, Kompression
• Server: Hallo, ..., diese Methode wähle ich
• Server: Hier mein öffentlicher Schlüssel mit Zertifikaten
• Client überprüft alles, u. a.
• Stimmt Server-IP-Adresse mit Angabe im Zertifikat überein?
• Ist Server-Zertifikat in Ordnung?
• Ggf. Nutzer fragen, ob Zertifikat akzeptabel
• Server: Gib Client-Zertifikat einer dieser CAs/Typen
• Client: Hier mein öffentlicher Schlüssel mit Zertifikaten, ...
• Client: Hier Schlüsseldaten, mit Server-Schlüssel verschlüsselt
• Beide berechnen Sitzungsschlüssel aus Schlüsseldaten
• Umschaltung auf Secret-Key-Verschlüsselung mit Sitzungsschlüssel
• Client: Hier meine Prüfsumme über alles Bisherige; Kommen
• Server überprüft alles (ggf. auch Client-Zertifikat)
• Server: Hier meine Prüfsumme über alles Bisherige; Fertig
• Client überprüft alles; Fertig
• Verschlüsselte Übertragung der Daten beginnt.

• PRAXIS: Homebanking mit http://www.sparda-ms.de -> SpardaNet-Banking
• Immer die Adresse eintippen oder aus Bookmark; nie einem Link dorthin folgen!
• SHA1 Fingerprint=3b:21:06:25:11:06:f6:8c:8a:54:f5:c8:7a:a3:10:fc:fc:73:c5:a3
• »Überprüfen Sie unser Zertifikat« ist Augenwischerei! (Kann nachgemacht werden)
• Meine Sicherheitsmaßnahmen:
• Fingerprint persönlich in Geschäftsstelle erfragt.
• Virtuelle Maschine, die beim Ausschalten alle Änderungen vergisst (auch Viren und Updates, falls welche wären)
• Ubuntu auf verschlüsseltem Dateisystem, fertig vorbereitete Bookmarks
• IPTables, die nur ausgehende HTTPS-Verbindungen zu den beiden IP-Adressen von banking.sparda.de erlauben
• Virtuelle Maschine läuft auf einer stark gesicherten realen Maschine hinter NAT-Router (sonst Angriff auf Boot-Partition)

• Falls Zeit: Dialogverbindungen mit SSH

• Falls Zeit: SSH-Tunnel

• Falls Zeit: VPN-Tunnel
• unverschlüsselt, aber sichere Passwortkontrolle: vpn-internet.uni-muenster.de
• verschlüsselt: CISCO-Client

• Falls Zeit: Steganographie
• http://www.uni-muenster.de/ZIV/Lehre/Internet/Stegano.txt

• Falls Zeit: Quantenkryptographie
• Seit kurzem kommerzielles Produkt, funktioniert über zig Kilometer
• http://de.wikipedia.org/wiki/Quantenkryptografie

Diese Seite:

• :: Seite empfehlen
• :: Seite kommentieren, Link öffnet neues Fenster