01 –Einleitung - [choerbaert.org [ˈχœrbɛrt]]

01 –Einleitung
Bedrohungen, Sicherheitsziele und Anforderungen
Bedrohung
– mögliches Ereignis/Sequenz zur Verletzung der Sicherheitsziele (Möglichkeit eines Angriffs)
Sicherheitsziele
– Vertraulichkeit (Ressourcen nur bestimmten Personen zugänglich machen, Anonymität)
– Datenintegrität (Erkennen von Änderungen, Nachrichterzeuger muss erkennbar sein)
– Zurechenbarkeit (Verantwortlicher für geschehene Vorgänge bestimmen)
– kontrollierter Zugriff (Zugriff beschränkbar)
– Verfügbarkeit (Dienste verfügbar und korrektes Arbeiten)
Arten von Bedrohungen
– Masquerade (falsche Identität)
– Eavesdropping (Mitlesen von anderen Daten, passiver Angriff)
– Authorisierungsverletzung (unbefugtes Nutzen von Ressourcen/Diensten)
– Verlust/Modifikation von Informationen
– Abstreiten von Kommunikationsereignissen (“ich wars nicht”)
– Fälschung von Informationen (Erzeugen von neuen Informationen im Namen eines Anderen)
– Sabotage (Verfügbarkeit/korrektes Arbeiten eines Dienstes verhindern)
Gegenmaßnahmen
– Prävention - vor einem Angriff (Verschlüsselung, Firewall)
– Erkennung - während oder nach einem Angriff (Verkehr/Aktionen aufzeichnen und auswerten)
– Reaktion - während oder nach einem Angriff (System säubern)
Maßnahmen gegen Bedrohungen (Prävention)
– physikalische Sicherheit (Zugriff beschränken)
– Personalsicherheit (Sicherheitstraining)
– administrative Sicherheit (Kontrolle neuer Software, Auswertung von Angriffen)
– Abstrahlsicherheit (Abhören)
– Mediensicherheit (Prüfen neuer Medien, sicheres Vernichten)
– Lebenszykluskontrollen (Systemdesign, Implementation, Evaluierung, Dokumentation)
– Rechner-/Systemsicherheit (Schutz von Informationen während Speicherung/Verarbeitung, Schutz der Systeme)
– Kommunikationssicherheit (Schutz von Informationen während Übertragung, Schutz der
Kommunikationsinfrastruktur)
Sicherheitsdienste
– Begriff: abstrakter Dienst zur Gewährleistung einer Sicherheitseigenschaft
– Authentisierung: Prüfen von Identitäten
– Datenintegrität: Erkennen von Erzeuger und Modifikation der Daten
– Vertraulichkeit: Schützen von Daten
– Zugriffskontrolle
– Nicht-Abstreitbarkeit (vertrauenswürdiger, unabhängiger Dritte benötigt)
02 – Denial of Service
Allgemeines
– Ziel: Dienstqualität reduzieren, Dienste außer Betrieb nehmen
DoS-Kategorien und Beispiele
Angriffstechniken
– Ressourcenzerstörung: Dienst außer Betrieb nehmen, zB durch Buffer-Overrun
– Ressourcenerschöpfung: Speicherung unnötiger Informationen, hoher Traffic, teure Berechnungen, Reservierungen
Ressourcenzerstörung
– Ausnutzung von Implementierungsschwächen
– Protokollabweichung (inkorrekte Protokollausführung)
– zB Paketfragmente schicken, letztes Fragment zurück behalten → Speichererschöpfung
Ressourcenerschöpfung
– TCP-SYN-Flut mit gefälschter Absenderadresse
– DDoS: Angreifer dringt in mehrere Systeme ein, installiert DoS-Software
– Teil der Systeme als Master, kontrollieren jeweils weitere Systeme
– Reflektornetzwerke als weitere Angreifer
– Master-Slave-Victim, Master-Slave-Reflector-Victim
Gegenmaßnahmen
Schutz
– Hacking: gute Administration, Firewall, Logging, Intrusion-Detection
– Implementierungsschwächen: Code Reviews, Stresstests
– Protokollabweichung: fehlertolerante Protokolle, Logging, Intrusion-Detection, Fragmente irgendwann wegwerfen,
DoS-bewusste Protokolle
– Schutz vor Ressourcenerschöpfung:
– Ratenkontrolle (Systemleistung beschränken)
– Authentisierung und Accounting
– teure Berechnungen in Protokollen vermeiden
– zustandslose Protokolle bis zur Authentisierung zum Schutz vor Speichererschöpfung
– bösartiger Verkehr:
– Adressbereiche deaktivieren
– gefälschte Quelladressen (Hauptproblem von DoS):
– Ingress Filtering der ISPs
– Verifizieren mit Hilfe von Cookies
– Reflektor-Angriffe: ICMP-Echo-Requests verbieten
Authentisierung
– kryptografisches Protokoll
– Varianten:
– Nachrichtenauthentisierung (Nachricht stammt von bestimmter Instanz und liegt unverändert vor)
– Instanzenauthentisierung (Passwort, Schlüssel, Fingerabdruck)
– Prüfen der Aktualität von Nachrichten: Zeitstempel oder Zufallszahl (mit Geheimnis manipulieren)
– Kategorien:
– vermittelte Authentisierung: vertrauenswürdiger Dritte für jede Authentisierung (Dritter wird Flaschenhals,
single point of failure, kann alles mitlesen)
– direkte Authentisierung: braucht asymmetrische Kryptografie oder vorher ausgemachte geheime Schlüssel
Ressourcenerschöpfung der CPU
– Authentisierungsanfragen mit ungültiger Signatur/Sitzungsschlüssel (Angreifer muss Nachrichten vom Opfer
empfangen oder erraten können)
– dafür anfällig: SSL beim Aushandeln des Sitzungsschlüssel, teure RSA-Operationen benötigt → Client erstellt
zufälligen Schlüssel mit öffentlichem Schlüssel des Servers, Server entschlüsselt mit geheimen Schlüssel
Gegenmaßnahme zur CPU-Erschöpfung: Client Puzzles
– Server generiert Aufgabe für Client
– Anforderungen:
Erzeugen und Überprüfen einfach für Server
Schwierigkeitsgrad der Aufgabe dynamisch nach Serverlast einstellbar
Aufgabe von gängiger Hardware lösbar (Desktop, Handy)
Vorberechnungen von Lösungen unmöglich
Server braucht keine Clientdaten speichern
Umsetzung:
– Server schickt periodisch per Broadcast Zufallszahl NS, Schwierigkeitsgrad k
– Client generiert Zufallszahl NC, muss Zahl X so wählen dass H(C, NS, NC, X) = 00000 (ersten k Bits der
Hashfunktion müssen 0 sein)
–
–
–
–
–
–
Gegenmaßnahme zur Speichererschöpfung
– Informationsspeicherung auf Serverseite verhindern, Informationen in Nachrichten integrieren
Anfragequelle per Cookie prüfen
– vor Bearbeiten der Anfrage Cookie zurück an Client schicken, Cookie darf nicht erraten werden können →
Erkennen von Spoofingangriffen
– erleichtert Erschöpfung von Kommunikationsbandbreite (Angriff aber einfach erkennbar)
Adressspoofing verhindern: Ingress Filtering
– ISPs (Router) blockieren Paket, wenn Quelladresse ungültig ist (nicht aus eigenem Netz stammt)
– Probleme:
– Mobile-IP (vermeidet zusätzliches Tunneling)
– großer Verwaltungsaufwand
– nicht überall verfügbar
– ISPs wollen keinen Traffic blockieren
Erkennen von bösartigen Knoten
Identifizieren von bösen Knoten
– DDoS Attack-Tree: Victim → Routers → Attackers. Welche Knoten greifen an? Welche Router sind auf diesem
Pfad?
– Annahmen:
– Angreifer können jedes beliebige Paket erzeugen
– Zusammenarbeit von mehreren Angreifern
– Angreifer kennen Gegenmaßnahmen
– Pakete können zufällig ankommen oder verloren gehen
– Vielzahl an unterschiedlichen Paketen
– Weg zwischen Angreifer und Opfer bleibt für gewisse Dauer gleich
– Router können nur beschränkte Aufgaben bearbeiten
– Router sind in der Regel nicht kompromittiert
– Lösungen:
– Network Logging (Informationen/Pfad von Paketen)
– Attack Path Traceback (Pfad durch Netzwerk zurückverfolgen)
Anforderungen/Charakteristiken einer Lösung
– muss ISP mitmachen? müssen alle mitmachen?
– benötigte Menge an Paketen, um Pfad rekonstruieren zu können
– Ressourcenoverhead der Router pro Paket (Verarbeitung, Speicher, Bandbreite)
– Einfachheit der Umgehung der Lösung: wie einfach?
– Angreifbarkeit der Lösung: kann Mechanismus selber angegriffen werden oder durch spezielle Pakete manipuliert
werden?
– Skalierbarkeit: wie skaliert Mechanismus mit größeren/zusätzlichen Netzwerken?
– Schwächung: sinnvolle Ergebnisse wenn mehrere Systeme auf Pfad kompromittiert wurden?
– Leistungsfähigkeit bei DDoS: sinnvolle Ergebnisse bei unterschiedlichen Angriffspfaden?
– Leistungsfähigkeit bei Pakettransformation (Fragmentierung, Tunneling, ...)
Beteiligung vom ISP
– nicht daran interessiert, Bezahlung pro Traffic
– welcher Traffic ist böse? böse für wen?
– teuer (Infrastruktur, Management, Administration)
– partielle Beteiligung: dennoch nützlich? Angreifer von diesen ISPs auffindbar?
Menge an Paketen zum Finden der Angriffsquelle
– verschiedene Angriffstypen:
– Erschöpfung der Bandbreite, kontinuierlicher Fluss an Paketen, Paketflut
– ein oder mehrere Angreifer
– wenige, Zielgerichtete Pakete
Ressourcenoverhead
– wie viel zusätzliche Arbeit pro Paket?
– wie viel Information muss gespeichert werden? für jedes Paket?
– Kommunikation unter den Routern notwendig? wie viel zusätzliche Bandbreite?
Logging
– Local network logging: alle Router loggen allen Verkehr → zu viel Overhead, skaliert nicht
– aggregiertes Logging:
– zentraler „Tracking Router“, sämtlicher Verkehr durchgeleitet, loggt alles → single point of failure,
skaliert nicht
– Source Path Identification Engine (SPIE, Hash-based IP Traceback):
– Data Generation Agent (DGA): in Routern, schicken Teil des Traffics an Collection & Reduction Agents
– SPIE Collection & Reduction Agents (SCAR): speichert Paketinformationen
– SPIE Traceback Manager (STM): verfolgt Angriffe zurück mit Hilfe von SCAR
Source Path Identification
– gespeicherte Information pro Paket: konstante Felder im IP-Header + ersten 8 Bytes vom Payload
– gehashed in Bloom Filter
Traceback
– Angriffspfad zurück durch Netzwerk verfolgen
– Typen:
– Input Debugging
– Controlled Flooding
– ICMP Traceback
– Probabilistic Packet Marking („IP-Traceback“)
Input Debugging
– Pfad per Hand zurück verfolgen, Administrator/ISP informieren
– Admin ermittelt Herkunft der Pakete, informiert nächsten ISP
– Nachteile: umständlich, langsam, teuer
Controlled Flooding
– einfacher DoS-Angriff: Leitungen des Netzwerkes sind stark beansprucht
– vom Opfer aus in Richtung Quelle Last erzeugen, schauen ob weniger bösartiger Traffic ankommt
– Nachteile: zusätzliche Last wird erzeugt, bei Hochgeschwindigkeitsleitungen nicht erkennbar
ICMP Traceback
– Router schickt Empfängerinformationen über Pakete
– zufällig jedes x-te Paket markieren („out-of-band“, ICMP iTrace an Paketempfänger): TTL auf 255, Zeitstempel,
Routeradresse, vorhergehend/folgenden Hop, Kopie des Payloads
– Nachteile:
– zusätzlicher Traffic
– Vielzahl an Paketen zur Pfadrekonstruktion benötigt
– Opfer muss viele iTrace-Nachrichten analysieren
– Firewalls blockieren oft ICMP
– Fälschung von iTrace-Nachrichten möglich (Signierung? teure Verifikation → Angreifer kann leicht hohe
Last erzeugen)
Probabilistic Packet Marking („IP-Traceback“)
– Ansatz wie bei ICMP Traceback
– weitergeleitete Pakete mit niedriger Wahrscheinlichkeit direkt markiert („in-band“, kein zusätzlicher Traffic),
verschiedene Methoden möglich
– PPM Marking: Node Append: jeder Knoten hängt seine Adresse an Paket (kompletter Pfad rekonstruierbar) →
hoher Overhead bei kleinen Paketen, Paketfragmentierung möglich
– PPM Marking: Node Sampling: neues IP-Header-Feld, mit Wahrscheinlichkeit p Router reinschreiben
– Nachteile: zusätzliches Feld, Router nahe des Angreifers werden oft im Feld überschrieben, bei DDos Pfad
–
–
–
–
schwierig zu rekonstruieren
PPM Marking: Edge Sampling, Marking: Kantenmarkierung (Start-/Zielrouter, Distanz), Opfer kann Angriffsbaum
rekonstruieren
PPM Encoding: zusätzliche Informationen im IP-Header (Identification-Feld), XOR von Start-/Ziel-IP, nur
Fragmente von Kanteninformationen übertragen
Vorteile: stabil, sinnvolle Resultate unter partieller Beteiligung, keine zusätzliche Bandbreite, wenig
Verarbeitungsaufwand für Router
Nachteile: hauptsächlich nur für Bandbreitenerschöpfung (viele Pakete benötigt, fragmentierte Pakete nutzlos),
Opfer benötigt viel Speicher und Verarbeitungsaufwand, Authentisierung benötigt (hoher Aufwand)
Weitere Ansätze
– Hop Count Filtering: kann man gefälschte Absenderadressen an Hand von Paketdaten erkennen?
– Angreifer kann jedes Feld im IP-Header fälschen, außer TTL
– führt Distanz der IP-Adresse zu diesem TTL-Wert?
– Nachteil: Angreifer kann Initialwert auf jeden beliebigen Wert setzen
– Aggregate Based Congestion Control: Angriff in Backbone bereits erkennbar?
– Angriff generiert Ansammlung an ähnlichem Verkehr, häufige IP-Adressen von gedroppten Paketen
werden gezählt
– Traffic limitieren, vorhergehenden Router informieren
– Nachteil: Angreifer kann Mechanismus dazu missbrauchen Anderen den Traffic zu limitieren
– Secure Overlay Services / Onion Routing: Angriffe durch Verstecken der Dienste verhindern
– Hierarchie/Schichten um Server herum, Knoten in Hierarchie nach Vertrauen gruppieren
– Verkehr nur entlang Hierarchie leiten (mehrere Eintrittspunkte)
03 – Routing and DNS Security
Hintergrundinformationen zum Routing
Netzwerkschicht
– Funktionen: Pfadbestimmung, Weiterleitung, Verbindungsaufbau
– Routingprotokoll, Routingtabelle
– CIDR: Classless InterDomain Routing: Adressenformat a.b.c.d/x, x = Anzahl an Bits für Host-Adresse, „Longest
match routing“
– Routing Verfahren:
– Distance Vector Routing: iterativ, selbstterminierend, verteilt, Distanztabelle in jedem Router
– Link-State Routing: Dijkstra, Kosten zu allen Knoten bekannt, Distanzen über Fluten an andere Router
geschickt
– Robustheit bei Kompromittierung: LS: falsche Linkkosten, DV: falsche Pfadkosten
Hierarchisches Routing
– zweistufige Hierarchie im Internet
– Router zu Autonomen Systemen (AS) zusammenfassen, nutzen intern „intra-AS“-Routing
– Gateway Router: intra-AS Routing zu Routern in ihrem AS, inter-AS Routing zu anderen Gateway Router
– Routing auf zwei Ebenen:
– Intra-AS: Routing Information Protocol (RIP, Distance Vector), Open Shortest Path First (OSPF, Link
State)
– Inter-AS: Border Gateway Protocol (BGP, Path Vector)
Routing Information Protocol (RIP)
– Distance Vector Algorithmus, Distanz = Anzahl Hops, alle 30s über Advertisement ausgetauscht
– Link-Ausfall: nach 180s kein Advertisement = Link tot, neue Routen berechnen, austauschen
– Routingtabelle: erstellt von Prozess route-d, Advertisements über UDP verschickt
Open Shortest Path First (OSPF)
– Link State Algorithmus, Flutphase, Topologiekarte an jedem Knoten, per Dijkstra beste Wege bestimmen
– Vorteile gegenüber RIP:
– TCP für Nachrichten
– mehrere Pfade mit gleichen Kosten erlaubt
– unterschiedliche Distanzbestimmung (Bandbreite, Delay)
– hierarchisches OSPF für große Netze
Border Gateway Protocol (BGP)
– Path Vector Algorithmus, ähnlich zu Distance Vector, zusätzlich zu Kosten auch noch AS auf dem Weg mitteilen
zur Vermeidung von Schleifen
– TCP zur Nachrichtenmitteilung untereinander
Routingprotokollbedrohungen und Gegemaßnahmen
Bedrohungen von Routingprotokollen
– Bedrohungsquellen: Link/Router von Angreifer kontrolliert
– Auswirkungen:
– Bekanntmachen von Routing-Informationen
– Täuschen von anderen Routern
– Traffic stehlen
– Wirkungsbereich: einzelner Knoten, Teil des Netzwerks, komplettes Internet
– Wirkungsdauer: während Attacke, für gewisse Zeit
Auswirkungen von Bedrohungen
– auf das globale Netzwerk:
– Netzwerkstau, Überlastung
– schwarzes Loch, Pakete verschwinden
– Schleife (Stau und verschwinden)
– Abtrennen von Netzteilen
– häufige Routenwechsel
– Instabilität des Routingprotokolls
– Routingüberlastung
–
auf ein bestimmtes Netzwerk/Host
– Delay, längere Routen
– Abtrennung, Teil glaubt er ist vom Netzwerk abgeschnitten
– Aushungern
– Abhören
– kontrollierte Übertragung, Angreifer kann einzelne Pakete verzögern, löschen, modifizieren
Erkennbare Bedrohungen
– Bekanntmachen von Routing-Informationen: Routing-Nachrichten abhören, Verkehr analysieren
– Masquerade: sich als ein anderes System ausgeben, zum Vorbereiten weiterer Angriffe
– Einmischen: Austausch von Routinginformationen verzögern/unterbinden, Synchronisation zerstören →
(teilweiser) Ausfall des Routings
– Fälschen von Routing-Informationen:
– Overclaiming: bessere Route angeben als vorhanden, einkommender Verkehr steigt
– Underclaiming: schlechtere Routen angeben, Verkehr wird ferngehalten
– Ressourcenerschöpfung: z.B. durch häufige Routenveränderung → Routing verschlechtern/verhindern
– Ressourcenzerstörung:
– Link: physikalisch oder durch starke Störung
– Knoten: physikalisch oder durch Schwächen in der Software
Inter-AS Routing Bedrohungen
– hauptsächlich BGP betreffend
– Ziele:
– Teile des Internets außer Betrieb nehmen durch Stören der Routing-Tabellen
– alternative Pfade anpreisen
– AS außer Betrieb nehmen
– schwarze Löcher erzeugen
– Realisierung:
– falsche IP-Adressbereiche ankündigen
– unautorisierte Präfixe in Routingtabelle einfügen
– Modifizieren oder Fälschen von Routingnachrichten
– Ressourcenzerstörung
Absichern von BGP
– Nachrichten verifizieren:
– Router akzeptieren nur Nachrichten von direkt verbundenen Knoten: BGP TTL Security Hack (BTSH),
Routingnachrichten mit TTL 255 verschicken, nur Nachrichten mit TTL ≥ 254 annehmen
– Authentisieren von Routingnachrichten:
– TCP MD5 Signatur: Hashfunktion MD5 + Geheimnis als Option im TCP-Segment
– Nachteil: wie Geheimnis zwischen Routern aushandeln? aufwändig, fehleranfällig
– IPSec: Authentisierung, Schutz vor Wiedereinspielung von IP-Paketen
– Probleme: falsche Routen können immer noch veröffentlicht werden
Probleme trotz BGP Sicherheit
– Besitz von Adressbereichen und Routen: wer darf für welche werben?
– AS-Authentisierung: wem wurde AS-Nummer zugewiesen?
– Routerauthentisierung und -autorisierung: authentische Router?
– Routenrückziehung: wer darf Routen zurückziehen?
Secure Border Gateway Protocol (S-BGP)
– IPSec zwischen Routern
– Public-Key-Infrastruktur zur Identifikation von BGP-Routern und AS-Besitzern über Zertifikate
– Bescheinigungen zum Werben für Adressbereiche
– Validierung von BGP-Updates über Zertifikate
S-BGP Zertifikate und Bescheinigungen
– ICANN gibt Zertifikate über Adressbereiche an große Provider raus
– ICANN gibt Zertifikate über AS-Nummern raus, Router werden AS zugeordnet → Entstehung von beworbenen
Pfaden kann zurückverfolgt werden
– Bescheinigungen:
– Adressbescheinigungen: prüfen, ob AS zum Bewerben eines Adressbereichs autorisiert ist
– Routebescheinigungen: prüfen, ob AS zum Bewerben eines Pfades autorisiert ist
– jedes Update hat ein oder mehrere Adressbescheinigungen und eine Menge von Routebescheinigungen
–
Zertifikatrückzugslisten
Validieren einer Route mit S-BGP
– eine Adressbescheinigung pro Organisation, der ein erreichbarer Adressblock gehört
– eine Routenbescheinigung von jedem AS entlang des Pfades
– ein Zertifikat von jedem AS entlang des Pfades
– kein Zertifikat darf zurückgezogen worden sein
Verteilung der Zertifikate
– Server an Netzwerkaccesspoints (Verbindung zwischen mehreren BGPs)
– Zertifikate/Rückzugslisten einzeln herunterladbar
Performanceprobleme
– Platte: Speicherung der Zertifikate/Rückzugslisten
– CPU: Validieren der Zertifikate/Rückzugslisten
– Bescheinigungen: im Router gespeichert, validiert
– Bandbreite: Übertragung von Zertifikaten/Bescheinigungen
S-BGP Schwächen
– Rückzug von Routen, könnten neu beworben werden mit altem Zertifikat
– fehlender Umsatz
– kryptografische Operationen für Zertifikate (asymmetrisch, hoher Aufwand)
– jeder Router muss mitmachen
– Public-Key-Intrastruktur benötigt, wem kann man ausreichend vertrauen?
Alternative Ansätze:
– S-A (Signature Amortisation): optimiert Signatursystem, weniger rechenaufwändig
– SPV (Secure Path Vector): nur symmetrische Kryptografie
– IRV (Interdomain Route Validation): Server in AS überprüfen Routen
– soBGP (secure origin BGP): ohne PKI
Signature Amortisation (S-A)
– Beobachtung: Nachrichten werden häufiger geprüft als signiert, S-BGP nutzt DSA zum Signieren
– Prüfen mit RSA (unter bestimmten Bedingungen) schneller als DSA, aber längere Schlüssel benötigt
– kein Gewinn :(
– Signature Amortisation Across Peers (S-A-P):
– gleiche Signatur für unterschiedliche Partner, weniger Aufwand benötigt, Gewinn durch RSA-Nutzung
steigt
– Signature Amortisation Across Buffers (S-A-B):
– Hash-Baum
– Beobachtung: Router akzeptieren neue Nachrichten erst nach Ablauf eines Intervalls → nur eine Signatur
für alle Nachrichten innerhalb des Intervalls, wenn sie gepuffert werden
– S-A-P und S-A-B schließen sich gegenseitig aus, führen beide zu etwas geringerem Aufwand
Secure Path Vector Protocol
– Lamport-Signaturen:
– Beobachtung: digitale Signaturen sind aufgrund asymmetrischer Kryptografie aufwändig
– Lösung: Lamport-Signaturen, nutzen kryptografische Hashfunktionen
– Nachteile: lange Signaturen/Schlüssel, jeder Schlüssel nur einmal verwendbar
– HORS-Signaturen:
– mehr als einen Teil des privaten Schlüssels veröffentlichen → mehrere Hashfunktionen
– Nachteile: zu kompliziert, angreifbar unter bestimmten topologischen Bedingungen, hoher
Kommunikationsaufwand
Interdomain Route Validation (IRV)
– BGP-Erweiterung: zentraler IRV-Server in teilnehmenden AS (muss nicht in jedem sein)
– lernen Routen von lokalen Routern
– BGP-Update validiert durch Befragen der IRV-Server
– Authentisierung über IPSec, TLS, PKI möglich
– Vorteile: Schutz vor Fehlkonfigurationen und primitiven Attacken
– Nachteile: IRV-Server könnten kompromittiert sein
secure origin BGP (soBGP)
– im Vergleich zu S-BGP ohne PKI, kein funktionierendes Routing benötigt, keine vollständige Beteiligung benötigt
– neue Security-Nachricht zum Transport von Zertifikaten (Routenbescheinigungen)
– AuthCerts (Adressbescheinigungen), EntityCerts (AS Zertifikate), PolicyCerts (jeder AS informiert über BGPVerbindungen zu anderen AS)
– Implementierungsmöglichkeiten:
– Router am Rand verarbeiten Zertifikate (wie S-BGP)
– interne Server verarbeiten Zertifikate (wie IRV)
– Kompromiss zwischen den ersten beiden Möglichkeiten: Router tauschen Informationen aus, interner
Server erledigt Rechenarbeit
– Web of Trust: direktes/indirektes Vertrauen
– Nachteile: kein Sicherheitsbeweis (keine Adressbescheinigung von Drittem), Fälschung von PolicyCerts möglich
Nachteile von kryptografiebasierten Ansätzen
– Berechnung und Kommunikation aufwändig
– PKI-Infrastruktur benötigt
– inkrementelle Verbreitung liefert nur geringen Sicherheitsgewinn
– Idee: verfügbare Informationen zum Prüfen der Glaubwürdigkeit von Update-Nachrichten nutzen, Ansätze:
– Pretty Good BGP
– Topology-based Analysis
– Stable Route Information Objects
– Monitoring TCP Flows
Pretty Good BGP
– Beobachtung: Hälfte aller gefälschten Absender/Präfixe halten kürzer als 24h
– nicht zu schnell reagieren → Zeit für zweiten Validierungsprozess (manuell, nach Warnungen schauen)
– funktionierende Routen/Präfixe für h Tage in Datenbank speichern
– bei Update in Datenbank nach Route schauen, gelten für s Tage als verdächtig, erst danach in DB gespeichert
– verdächtige Routen erstmal nicht benutzen
– Nachteile: neue Subpräfixe werden erstmal nicht beachtet, lange andauernde Angriffe führen zum Erfolg
Topology-based Analysis
– Beobachtung: Internet weist bestimmte Struktur auf: dicht verbundene Kernknoten, äußere Knoten mit wenigen
Nachbarn
– Verbindungsgraph: Router sind Knoten, Links sind Kanten, aus Route-Updates aufgebaut
– Kernknoten werden im Graph zusammengefasst, äußere Knoten in Cluster eingeteilt
– geografische Informationen über WHOIS, geografische Distanz zwischen Clustern
– Path modification (Cluster, Kern, Cluster, Kern, Cluster): normaler Pfad verläuft von Quellcluster über Kernnetz zu
Zielcluster
– Path truncation (Cluster, Cluster, Kern, Cluster): Pfad zwischen zwei Clustern muss durch Kernbereich
– Vorteile: einfacher Algorithmus, geringe Kosten
– Nachteile: verlässliche geografische Daten schwer zu erhalten, zusätzliche Anforderung, nur für Pfadangriffe,
Angriffe innerhalb eines Clusters nicht entdeckt
Stable Route Information Objects
– Routen ändern sich dynamisch, gibt aber nur zwei Routinginformationen (Objekte):
– direkte Links zwischen benachbarten Systemen (ändern sich sehr selten)
– Präfix-/Herkunftassoziation (welcher Betreiber hat welche Adressen)
– Inter-domain routing hat stabile Infrastruktur, stabile Objekte
– Updates über Datenbank mit alten Informationen vergleichen (ähnlich wie frühere Ansätze, aber mit direkten
Links)
– jeden Link aus Update überprüfen, unbekannte als verdächtig markieren, für jeden AS prüfen ob Präfix in
Datenbank
– Datenbank über Heuristic verbessern:
– kurzzeitige Objekte/Links entfernen
– Routenupdates, die keinen Vorteil für Angreifer darstellen, sind ungefährlich
– zwei benachbarte AS haben ähnliche Adressbereiche
– AS können ihre Adressbereiche in bestimmten Grenzen erweitern
Monitoring TCP Flows
– TCP-Verkehr überwachen
– Route existiert: Verkehr kommt auch an, vollständige TCP-Verbindungen
– Nachteile: unvollständige TCP-Verbindungen nicht unbedingt Hinweis auf ein Problem, Angreifer kann TCP-SYN-
–
Flut erzeugen oder TCP-Verbindungen simulieren
Gegenmaßnahmen: Router droppt zufällige SYN-Pakete, prüft auf erneute Übertragung → Dienstqualität leidet
DNS-Sicherheitsprobleme
Absichern von Domain Name System (DNS)
– DNS unterstützt keine Datenintegrität oder Authentifikation
– Bedrohungen: DoS, Datenauthentizität-/integrität
– Komponenten:
– Authoritative Server: verwalten DNS-Zonen, Top-Level-Domain (TLD) Server verwalten Subdomains,
Lastverteilung über Master/Slaves
– Recursive (Caching) Server: lokale Proxys für DNS-Aufrufe mit zeitlich begrenztem Zwischenspeicher
– Resolver: Software auf Clientsystemen
– DNS-Eintrag (Resource Records, RR):
– name, ttl, class (Internet), typ (Host-Adresse, Nameserver, Mail..), rdata (resource data, Inhalt)
– Datenfluss:
– ZoneFile mit Name/IP des Rechners, befindet sich im Auth-Server, erhält dynamische Updates über
geänderte Resource Records
– Auth-Server hat mehrere Slaves, die für ihn arbeiten, und Caching-Server, die Client-Anfragen
beantworten
Rekursive und Iterative Anfragen
– rekursiv: angefragter Server kümmert sich um Problem bis es gelöst wird, stellt ggf. weitere Fragen an andere
Server, Antworten landet im Cache
– iterativ: wenn angefragter Server Frage nicht beantworten kann, liefert er Adresse zum nächsten Server, der die
Frage ggf. beantworten kann, zurück
DNS Sicherheitsprobleme
– Robustheit gegenüber DDoS
– Robustheit gegenüber Datenkorruption/Fälschungen (Cache Poisoning)
DNS-Bedrohung DDoS
– kurze Anfragen, ggf. lange Antworten (zB „Tippfehler“ in TLDs)
– rekursive Server generieren Last auf weiteren Servern
– rekursive Server als Reflektor zum Fluten eines Opfers (gefälschte Absenderadresse, Lösung siehe DoS-Kapitel)
Robustheit gegenüber DDoS
– DNS-Server absichern: Updates, Firewall
– Redundanz: mehrere Namensserver für Root (“.“), TLDs, ...
– Anycast: IP-Präfix von verschiedenen Orten aus bewerben
DNS-Bedrohung Datenintegrität
– manipuliertes ZoneFile
– unautorisierte Updates
– unautorisierte Auth-Server, manipulierte Slaves
– Kommunikation zwischen Auth-Server und Caching-Server stören (Cache Poisoning)
– Kommunikation zwischen Caching-Server und Resolver stören
DNS-Bedrohung: Datenkorruption / Cache Poisoning
– alle Resource Records werden am lokalen DNS-Server gecached
– DNS-Slaves replizieren ZoneFiles vom Master
– normaler DNS-Aufruf: Client stellt Frage an lokalen DNS-Server, dieser antwortet entweder direkt (Antwort im
Cache noch nicht abgelaufen), oder fragt Auth-Server
– Probleme: statischer Port in alten DNS-Severn, Quell-ID zum Identifizieren der Nachricht sequentiell gewählt
– Cache Poisoning:
– Ziel: falsche IP-Adresse in Slave-/Caching-Server einschleusen → unbemerkte Umleitung von Adressen
– DNS läuft über UDP, kein Handshake :(
– Ablauf:
– Angreifer hat eigenen Auth-Server, fragt DNS-Server nach Informationen über eigenem AuthServer, kennt dadurch Port und Quell-ID der Serverantwort
– Angreifer fragt nach Zieldomain, schickt sofort gefälschte Antwort an DNS-Server mit Port und
QID+1, wird vom DNS-Sever übernommen wenn schneller als Auth-Server → Zieldomain hat
andere IP bekommen
–
Lösungen:
– kryptografisch sicherer Zufallsgenerator
– Angriff nur dann, wenn Eintrag in DNS-Server veraltet (2 Tage bei Namensservern, Sekunden bis
Stunden bei Organisationen)
– Cache Poisoning nicht komplett gelöst → Bruteforce :(
Robustheit gegenüber Datenkorruption: Split-Split DNS
– Ziel: Cache Poisoning von externen Maschinen vermeiden
– Idee: Funktion des Namensserver aufteilen: Namensauflösung (Rechner über Welt informieren),
Domaininformationen (Welt über eigene Rechner informieren)
– interner Server: Namensauflösung, hinter Firewall, keine Anfrage von außen
– externe Server: Auth-Server für Domains, akzeptiert externe Anfragen, aber keine externen Updates
– Transfer von ZoneFiles vom externen Server zum Internen erlaubt
Robustheit gegenüber Datenkorruption: Datenintegrität mit TSIG Resource Record
– Signaturen zum Sichern des Datentransfers zwischen Master und Slave, symmetrischer Schlüssel an beiden Enden
– Signatur in Resource Record mit übertragen
– Nachteil: aufgrund symmetrischer Kryptografie aufwändig, viele Keys benötigt
Robustheit gegenüber Datenkorruption: Datenintegrität mit DNSSEC
– Ziele: Authentizität und Integrität von Resoure Records, Erkennen von Datenkorruption und Spoofing
– kein Schutz vor DoS (erleichtert ihn sogar) oder vor inkorrekten Daten (solange korrekt signiert)
– PublicKey-Kryptografie, Schlüssel über Resource Records verteilt
– Resource Records sind mit privatem Schlüssel einer autorisierten Instanz signiert, öffentliche Schlüssel bekannt
– Hierarchie: Schlüssel von ChildZones authentifiziert von Eltern → Vertrauenskette (sonst nur Vertrauensinseln)
– nur root zone key signing key (KSK) benötigt zum Signieren von weiteren Schlüsseln, wird manuell verbreitet
– kein Zurückziehen von Schlüsseln, Schlüssel haben kurze Lebensdauer
– abgewehrte Bedrohungen: Cache Poisoning, geänderte Zonendaten
– Vorteile: nicht autorisierte, gefälschte DNS-Records werden vermieden
– Nachteile: Komplexität (Signieren, prüfen, Key-Verteilung) erleichtert DoS-Angriffe, Zonen komplett auslesbar
(zB alle Rechnernamen), manuelle Verteilung der Anchor-Schlüssel benötigt
04 – Sicherheitsgerechte Systementwürfe und -implementierungen
Probleme praktischer Systemsicherheit
– unmöglich, Sicherheit eines komplexen Systems zu beweisen
– Software ist die Wurzel der meisten Sicherheitsprobleme
– Ursachen:
– Größe und Komplexität moderner Systeme
– low-level Programmiersprachen anfällig für einfache Angriffe
– leicht erweiterbare Systeme, boshafter Code einschleusbar
– geringe Vielfalt an unterschiedlichen Systemen
Angriffsarten
– Ursprung: remote (Einbruch durch Softwareschwachstelle), lokal (Benutzer erlangt zusätzliche Berechtigungen)
– Techniken:
– Buffer overflow: Daten werden in falsche Speicherbereiche geschrieben
– Race condition: nicht-atomare Ausführungen werden von anderen Operationen unterbrochen
– Vertrauensausnutzung: von Programmeingaben oder Programmumgebungen
Buffer overflow
– Stack Smashing: über Puffergrenze hinweg in Stack schreiben → beliebiger Code auf System ausführbar,
Rücksprungadressen veränderbar
– Gegenmaßnahmen: Funktionen mit automatischer Überprüfung der Grenzen einsetzen oder selber explizit
überprüfen
– Privilege Escalation: höhere Rechte anderer Prozesse ausnutzen
– Heap: dynamisch allozierte Variablen (malloc, new)
– Stack: aufgerufene Prozeduren
– Stack und Heap dynamisch angelegt, Größe steht vorher nicht fest
– Stack wächst von oben nach unten (auf x86)
– Heapoverflow: schwierig, stark abhängig von Programmcode, Betriebssystemversion etc.
Race Conditions
– zwei sich ausschließende Ereignisse werden gleichzeitig ausgeführt
– Bedingung, die während der Ausführung gelten soll, wird am Anfang der Ausführung überprüft
– Angreifer manipuliert etwas, so dass Bedingung später nicht mehr gilt
– sehr schwer aufzuspüren, schwer zu beheben :(
Ausnutzen von Vertrauen
– Annahme, dass von vornherein alles unsicher ist, Vertrauen sollte nur wenn unbedingt nötig ausgeweitet werden
– Vertrauensproblem von Eingaben:
– Eingaben, die explizit vom Client zum Server geschickt werden
– Eingaben, die implizit vom aufrufenden Prozess vererbt werden
– Eingaben, die implizit via Umgebungsvariablen mitgegeben werden
– Eingaben über das Netzwerk nie trauen
– vererbte Zustände aufräumen: umask, Signale, Ressourcenlimits
– Umgebungsvariablen: prüfen, ggf. auf sichere Werte setzen oder ganz entfernen
– Format-String-Attacken:
– printf-Familie (C/C++), printf(username) statt printf(“%s“, username)
– kann aufgrund variabler Parameteranzahl zum Auslesen von anderen Speicherbereichen ausgenutzt
werden:
– username = “%d%d%d“ liest 3 Integer vom Stack, obwohl ursprünglich kein Parameter
übergeben wurde. “%10$d“ liest 10 Integer vom Stack
– Schreiben auf Stack ist auch möglich: “%n“
➔ Schreiben von fast allen Werten auf fast alle Speicheradressen möglich
– Client-Software: kann von Angreifer modifiziert/ersetzt werden
– niemals Code von anderen annehmen und ausführen
Gegenmaßnahmen
– Probleme:
– Lücken können nur behoben werden, wenn sie bekannt sind
– Patches können neue Lücken erzeugen, beheben nur die Symptome und werden oft nicht eingespielt
– beim Entwerfen und Implementieren an Sicherheit denken:
– Qualitätssicherer einstellen
–
–
–
–
–
–
–
Sicherheit in allen Phasen der Entwicklung bedenken
Programmierer ausbilden unsichere Konstrukte zu vermeiden
Code-Audits:
– Schwachstellen identifizieren
– sicherheitsrelevante Dinge dokumentieren
– Stellen überprüfen, an denen Eingaben entgegengenommen werden
– spezielle Programme einsetzen
Zugriffsrechte auf ein Minimum beschränken, höhere Zugriffsrechte so kurz wie möglich gewähren
Schaden begrenzen, evtl. durch einsperren
Komplexität vermeiden
oft genutzte Bibliotheken verwenden
05 – Intrusion Detection Systems
Motivation
–
–
–
Angriff: Aktion oder Reihe von Aktionen mit der Absicht Vertraulichkeit/Integrität/Verfügbarkeit eines Systems zu
stören
Verteidigungen: Prävention, Erkennung, Reaktion
Prävention reicht nicht aus:
– zu aufwändig, sich gegen alle potentiellen Angriffe zu schützen
– Mechanismen können versagen oder werden falsch eingesetzt
Ziele und Aufgaben von IDS
Ziele und Klassifikation von IDS
– Ziele: Überwachen und Erkennen von Angriffen und Missbrauch
– Möglichkeiten:
– Erkennen von Angriffen und Angreifern
– Erkennen von Systemmissbrauch
– Schadensbegrenzung
– Lernen zum Verbessern der Prävention
– Klassifikation:
– Bezug:
– host-basiert: Analysieren von Systemereignissen
– netzwerkbasiert: Analysieren von ausgetauschten Informationen (IP-Pakete, Verbindungen)
– hybrid: beides
– Analysezeitpunt: online oder hinterher
Host vs. Netzwerk Intrusion Detection
– HIDS:
– arbeitet mit Informationen vom System: Logs, Zeitstempel
– Angriffe von Insidern leicht erkennbar: Dateimodifikationen, unzulässige Zugriffe auf Dateien,
Installation von Trojanern oder Rootkits
– Probleme:
– muss auf jedem System installiert sein
– produziert viele Informationen
– oft keine Echtzeitprüfung
– Verwaltung von vielen Systemen schwierig
– NIDS:
– arbeitet mit Informationen vom Netzwerk: Pakete abhören
– Signaturerkennung, Protokolldekodierung, statistische Anomalieerkennung
– Erkennen von DoS, Buffer-Overflows, ungültige Pakete, Angriffe auf Anwendungsebene, SpoofingAngriffe, Portscans
– oft in Netzwerkhubs genutzt
Aufgaben von IDS
– Audit: Sammeln von Daten, Vorverarbeitung
– Erkennung:
– automatische Analyse
– Missbrauchserkennung (Signaturanalyse)
– Anomalieerkennung
– Arten von Fehlern: false positive, false negative
– Reaktion: Alarm, Gegenmaßnahmen
Anforderungen
– hohe Genauigkeit (niedrige Rate an „false positives/negatives“)
– einfache Integration, Konfiguration und Verwaltung
– autonomer, fehlertoleranter Ablauf
– Selbstschutz
Aufzeichnen von Audit-Daten
elementare Sicherheitsfunktion
sicherheitsrelevante Ereignisse aufzeichnen
liefert Informationen über: Zugriff von wem, wann, wo, wie, wessen Ressource
benötigt Integritätsschutz, sonst kann Angreifer Spuren verwischen
Arten von Audit-Daten
– Ereignisse im Rechners:
– Öffnen von Dateien
– Ausführen von Programmen
– Zugriffsverletzungen
– falsche Passworteingaben
– Ereignisse im Netzwerk:
– Verbindungsaufbau und -abbau
– versendete Pakete
– Signalereignisse (ICMP)
–
–
–
–
Anomalie- und Missbraucherkennung
Erkennen von Missbrauch
– Angriffserkennung über spezifizierte Angriffssignatur
– Signatur:
– Analysieren von Schwächen und vergangenen Attacken, die vom Audit aufgenommen wurden
– Festlegen von Regeln, die Angriffe spezifizieren
– Vorteile:
– effizient
– gute Erkennung von spezifizierten Angriffen
– Nachteile:
– Angriffe müssen vorher bekannt sein um spezifiziert werden zu können
– hoher Aufwand bei der Spezifizierung
– Signaturdatenbank muss ständig aktualisiert werden, sonst hohe Rate an false negatives
– abnormale Verhalten nicht erkennbar
Erkennen von Anomalien
– Idee: Verhalten erkennen, die von normalen Verhalten abweichen
– Verhalten: Dauer der Benutzung, Einloggzeiten, Intensität der Dateisystemnutzung, ausgeführte Programme
– normales Verhalten kann statistisch beschrieben werden → Lernphase erforderlich
– Analyse: Referenz mit aufgezeichneten Verhalten vergleichen
– Vorteile: Erkennen von unbekannten Angriffen und Angriffsszenarien
– Nachteile:
– Datenschutz, Privatsphäre bei Erfassung von Benutzerdaten
– ständige Aktualisierung der Verhaltensmuster erforderlich
– hohe Zahl an false positives
– Angriffe, die ähnlich des Standardverhaltens sind, nicht erkennbar
– teure Realisierung
Probleme von IDS
– Audit-Daten:
– viel Speicherplatz benötigt, Untersuchung muss so weit wie möglich automatisiert werden
– verteiltes Speichern: Transfer notwendig, lokales Speichern: hohe Systemlast
– Schutz vor Veränderung notwendig
– enthalten nur sehr wenig nützliche Informationen
– Datenschutz:
– Daten zum Identifizieren der Benutzer werden geloggt (UserID, Verzeichnisnamen)
– gesammelte Informationen können missbraucht werden
– psychologische Last durch Überwachung
– Lösung: Daten anonymisieren, nur bei Vorfällen auf UserID zurückführbar
– begrenzte Effizienz der Analyse: meist nur zentrale Auswertung, keine partielle → Performanceflaschenhals
– hohe Zahl an false positives
– Selbstschutz
– hoher Verwaltungsaufwand
– Kooperation zwischen mehreren IDS
06 – Security in Wireless Sensor Networks
Einführung
Charakteristik von drahtlosen Sensornetzwerken
– bis zu tausend kleine, billige Sensoren, die über ein drahtloses Interface miteinander kommunizieren
– über Basisstation mit herkömmlichen Netzen verbunden
– Distanz zwischen Sensor und Basisstation wird über multi-hop Kommunikation überbrückt
– begrenzte Ressourcen aufgrund begrenzt verfügbarer Energie
– typische Anwendungen:
– Umgebung überwachen: Erdbeben, Feuererkennung
– Überwachung von Grundstücken
– Militär: Truppenkoordination
– typisches Kommunikationsmuster:
– Anwendung benötigt Informationen aus bestimmten geografischen Gebiet
– Basisstation(en) schicken Broadcastanfrage
– Sensoren leiten Anfrage weiter und beantworten sie
Abgrenzung zu Ad hoc Netzen
– je nach Anwendung sehr dünn oder dicht besetzte Netze
– Interaktion mit Umgebung verursacht sehr unterschiedlich starken Verkehr
– Größe sehr variabel
– Energie sehr knapp, Batterie oder Umwelt als Quelle
– Selbstkonfiguration, kein menschlicher Eingriff möglich
– Verlässlichkeit/Dienstgüte, Auslieferung der angeforderten Informationen zählt
Sicherheitsziele
– Kompromittierung verhindern, kompromittierte Sensorknoten dürfen Sicherheit des Netzes nicht gefährden
– Verfügbarkeit von Diensten:
– Robustheit gegenüber DoS
– Schutz vor Energiediebstahl
– korrektes Routen von Nachrichten
– Vertraulichkeit und Integrität von Daten: Schutz vor Abhören und Manipulation
– besondere Herausforderung aufgrund:
– geringe Ressourcen (Speicher, Zeit, Energie)
– unfaires Gleichgewicht: schwache Knoten, starke Angreifer
Bedrohungen und Gegenmaßnahmen
– physische:
– Tampering (Knoten stehlen und manipulieren): Tamper-proofing (Selbstzerstörung), Knoten verstecken
– Jamming (Funk stören): breites Frequenzspektrum, Nachrichten mit Prioritäten, kleinere Perioden
– Link:
– Kollisionen: Fehlerkorrektur
– Erschöpfung: Limitierung der Rate
– Ungerechtigkeit: kleine Rahmen
– Netzwerk:
– gierige Knoten, Übertragung fremder Informationen: Redundanz, Überprüfungen
– Homing (Finden von Knoten durch geografische Informationen): Verschlüsselung
– Fehlleitungen von Nachrichten: Filter, Autorisierung, Überwachung
– schwarzes Loch: Autorisierung, Überwachung, Redundanz
– Transport:
– Flutung: Client Puzzles
– Desynchronisierung: auf authentische Nachrichten prüfen
Routingbedrohungen
– gefälschte, modifizierte, wiedereingespielte Informationen, zB zum Konstruieren von Schleifen (Energiefresser)
– Fälschen von Acknowledgements: vortäuschen, dass Knoten noch lebt
– selektives Weiterleiten: kontrollieren, welche Informationen weitergeleitet oder gestört werden
– Sinkhole (Verkehr anziehen) zum Vorbereiten von selektiven Weiterleiten
– mehrere Identitäten simulieren: Effektivität von fehlertolerantem multi-path Routing reduzieren
– Wurmloch: Nachrichten über schnelle Links weiterleiten zum Täuschen des Routingprotokolls
– Hello shouting: Routinginformationen mit höherer Energie wiedereinspielen
Gegenmaßnahmen zu Routingbedrohungen
– Fälschung:
– Authentisierung
– einzelner Gruppenschlüssel: unsicher, einzelne Kompromittierung führt zum Ausfall
– jeder Knoten gemeinsamer Schlüssel mit Basisstation: benachbarte Knoten handeln Schlüssel über
Basisstation aus
– Simulierung mehrerer Identitäten: Anzahl der Nachbarn pro Knoten beschränken, zB durch Schlüsselvergabe
– Hello shouting, Wurmlöcher, Sinkholes: nicht komplett verhinderbar
– Selektives Routen: durch multi-path Routing Schaden begrenzen
Energieeffiziente Vertraulichkeit und Integrität
Sichern von Vertraulichkeit und Integrität
– Hauptherausforderung:
– Implementationsbeschränkungen (Instruktionen, Speicher, Geschwindigkeit)
– sehr wenig Energie zum Rechnen und Senden
– Knoten können kompromittiert werden
– verbreitete Sicherheitsverfahren, die aufgrund der Beschränkungen wegfallen:
– asymmetrische Kryptografie zu teuer (Rechenkosten, lange Signaturen)
– Public-Key-Management auf Zertifikaten basiert und mit Schlüsselrücknahmen unmöglich
– symmetrische Kryptografie auch schwierig zu realisieren
– Beispielansätze:
– SNEP für Ende-zu-Ende Sicherheit zwischen Knoten und Basisstation
– μTESLA zur Authentifizierung von Broadcastkommunikation
Sensor Network Encryption Protocol (SNEP)
– Ziel: effiziente Ende-zu-Ende Sicherheit
– Sicherheiten:
– Vertraulichkeit
– Integrität/Authentisierung
– Schutz vor Wiedereinspielung
– Kommunikationsmuster:
– Knoten zur Basisstation
– Basisstation zu individuellen Knoten (spezifische Anfragen)
– Basisstation zu allen Knoten → μTESLA
– Designentscheidungen:
– keine asymmetrische Kryptografie
– alle kryptografischen Funktionen aus einem Blockcode generieren
– Ausnutzung des gemeinsamen Zustandes zur Vermeidung von Kommunikationsoverhead (Senden von
Informationen unnötig wenn schon bekannt)
SNEP Vertrauensmodel
– zwei Kommunikationspartner (Basisstation und Knoten) A, B haben gemeinsamen Masterschlüssel XAB, daraus
individuelle Sitzungsschlüssel abgeleitet
– aus Masterschlüssel vier Sitzungsschlüssel abgeleitet: Vertraulichkeit (CKAB und CKBA) und Integrität (IKAB und
IKBA)
– basierend auf RC5-Algorithmus mit Counter-Modus (Zähler) als gemeinsamer Zustand
– Problem: verloren gegangene Nachrichten oder gleichzeitiges Senden führt zu unterschiedlichem Zustand
– Lösung: probieren verschiedener Zählern oder Resynchronisation (über Basisstation, multi-hop!) notwendig
(benötigt beides Energie, Angriffspunkt für DoS)
– Schutz vor Wiedereinspielung automatisch durch Verschlüsselung über Counter-Modus
SNEP Knoten-zu-Knoten Schlüsselvereinbarung
– A schickt Zufallszahl an B, B schickt diese + eigene Zufallszahl + Prüfwert an Basisstation
– Basisstation generiert Schlüssel, verschickt diesen verschlüsselt an A und B (Schlüssel = Zufallszahlen)
– Zufallszahlen sichern Aktualität der Nachricht
– Probleme:
– keine Schlüsselaushandlung mit mehreren Knoten
– weder A noch B wissen, ob Kommunikationspartner Schlüssel empfangen hat
– Basisstation kennt Aktualität der Nachricht nicht
Authentische Broadcasts
Authentische Broadcasts mit μTESLA
– Anforderungen:
– asymmetrische Kryptografie zum Verhindern von gefälschten Nachrichten
– klassische asymmetrische Signaturen sind zu teuer (Berechnung, Speicher, Transfer)
– Idee:
– verzögerte Bekanntmachung von Schlüsseln (Schlüssel für bestimmten Zeitraum gültig, wird anschließend
erst veröffentlicht)
– benötigt lose synchronisierte Uhren
– ursprüngliches TESLA (Timed Efficient Stream Loss-tolerant Authentication): Grundidee ist invertierte Benutzung
von Hash-Ketten
– Unterschiede von μTESLA:
– TESLA nutzt asymmetrische Signaturen, μTESLA basiert auf symmetrischer Kryptografie (SNEP)
– μTESLA veröffentlicht Schlüssel nur einmal pro Zeitintervall
μTESLA Funktionen
– Sendereinrichtung:
– wählt Länge n für Schlüsselkette und generiert Zufallswert Kn
– berechnet invertierte Hash-Kette (invertiert, damit man mit einem Hash-Wert nicht den nächsten
berechnen kann)
– Broadcasten von authentisierten Paketen:
– Zeit wird in gleichlange Intervalle Ti eingeteilt
– in Zeitintervall Ti wird Paket mit Schlüssel Ki authentisiert
– Schlüssel Ki wird im Zeitintervall i+x (zB x=2) veröffentlicht
– Verifizieren von Paketen:
– Empfänger muss Uhrzeit kennen, maximale Zeitabweichung und Intervalllänge
– Paket muss mit Zeit Ti gespeichert werden bis Schlüssel veröffentlicht wird
– alle Pakete, die mit bereits veröffentlichtem Schlüssel authentisiert wurden, müssen verworfen werden
– Broadcast durch Sensorknoten:
– mit SNEP gesichertes Paket an Basisstation senden
– Basisstation sendet Broadcast
– Grund: Knoten haben nicht genug Speicher für Schlüsselketten
– Nachteile:
– nicht synchronisierte Uhren können zum Einspielen von Fälschungen genutzt werden
– Schlüssel müssen schnell veröffentlicht werden, Knoten können nicht viele Pakete speichern
Alternative Ansätze zur Schlüsselverwaltung
–
–
–
–
verbreitete Ansätze wenig brauchbar:
– asymmetrische Kryptografie: sehr ressourcenintensiv
– vermittelte Schlüsselverwaltung (Schlüssel zwischen Basisstation und Knoten vorverteilt): Vorverteilung
benötigt, Sicherheitsprobleme bei Kompromittierung
neue Ansätze:
– nachbarschaftsbasierter Schlüsselaustausch: LEAP
– probabilistische Schlüsselverteilung
Anforderungen einer Schlüsselverwaltung:
– anfällige Knoten, können gestohlen und kompromittiert werden:
– Knoten können in feindlichem, schwer zu beschützendem Gebiet verteilt werden
– kein teures Tamper-proofing, kryptografische Schlüssel können ausgelesen werden
– einzelne Kompromittierung soll Sicherheit des Netzes nicht gefährden
– kein vorheriges Wissen über Aufstellung der Knoten: automatische Konfiguration erforderlich
– Ressourcenrestriktion
– In-network processing: zu starke Abhängigkeit von Basisstation führt zu ineffizienter Kommunikation
(und macht sie zu einem attraktiven Ziel für Angriffe)
– späteres Hinzufügen von Sensorknoten: aufgrund Kompromittierung, Energieausfall, Defekt
Kriterien zur Bewertung von Schlüsselverwaltungsmethoden:
– Resistenz gegenüber Kompromittierung: wie viele Kommunikationsbeziehungen werden durch einzelne
Kompromittierung beeinflusst?
– Resistenz gegenüber replizierte/neue Knoten:
– Einsetzen von neuen, bösen Knoten möglich?
– Replizieren kompromittierter Knoten möglich?
– Ausschließen von kompromittierten Knoten möglich?
–
Skalierung: Größe des Netzes durch Schlüsselverwaltung begrenzt?
Localized Encryption and Authentication Protocol (LEAP)
– Ziel: automatisches und effizientes Einrichten von Sicherheitsbeziehungen während einer Initialisierungsphase
nach Installierung der Knoten
– Schlüsseleinrichtung für Beziehungen zwischen:
– Basisstation und Knoten mit individuellen Schlüsseln
– Sensoren und ihren Nachbarn mit paarweisen Schlüsseln
– Sensoren, die ein Cluster formen, mit Clusterschlüsseln
– allen Sensoren mit einem Gruppenschlüssel
– Einrichten der Schlüssel:
– jeder Knoten mit individuellen Schlüssel ausgestattet, welcher nur ihm und der Basisstation bekannt ist
– Basisstation generiert diese über Masterschlüssel und Knotenidentität (spart Speicher auf Basisstation)
– Einrichtung von paarweisen Schlüssel:
– Nachbarschaft der Knoten nach Aussetzung nicht immer vorher bekannt
– kleines Zeitintervall, in dem Knoten vor Angreifern sicher sind
– Knoten berechnen Masterschlüssel über Gruppenschlüssel
– Knoten entdecken Nachbarn und schicken ihnen ihre Identität und Zufallszahl
– Empfängerknoten berechnet MAC (Message Authentication Code)
– Sender berechnet das gleiche für Empfängerknoten → gemeinsamer Schlüssel
– nach Ablauf des Zeitintervalls wird Masterschlüssel gelöscht
– Schema kann erweitert werden zum Berechnen von paarweisen Schlüsseln für Knoten zwischen mehreren
Hops
– Einrichten von Clusterschlüsseln
– Knoten generiert Clusterschlüssel, sendet ihn verschlüsselt an andere Knoten
– Nachbarn entschlüsseln Nachrichten mit paarweisem Schlüssel
– Einrichten von multi-hop paarweisen Schlüsseln: andere Knoten als Proxys nutzen
– Einrichten von Gruppenschlüsseln:
– Basisstation generiert zufälligen Schlüssel, sendet ihn verschlüsselt zu lokalem Cluster
– Cluster senden Schlüssel mit ihrem eigenen Clusterkey verschlüsselt weiter
– Zurückziehen von Knoten
– wird von Basisstation mit Hilfe von μTESLA ausgeführt (Zeitsynchronisation benötigt)
– Basisstation sendet Broadcast, nach Ablauf des Zeitintervalls wird Schlüssel dafür veröffentlicht
– Bemerkungen zu Sicherheitsaspekten:
– Auslieferung der Knoten mit verschiedenen Masterschlüsseln bringt keinen Sicherheitsgewinn
– Synchronisation der Zeit zum aushandeln von paarweisen Schlüsseln kritisch:
– Knoten kennen Startpunkt nicht, Signal notwendig?
– Signal kann übersehen oder nicht empfangen werden → Masterschlüssel wird nicht verworfen
– Kompromittierung vor Löschung des Schlüssels gefährdet Sensornetz
– Nutzen der Zufallszahl beim Aushandeln des paarweisen Schlüssels?
– paarweise Schlüssel nur ganz am Anfang ausgehandelt → Wiedereinspielung zwecklos
– Zufallszahl wird beim Berechnen des Schlüssels gar nicht verwendet
– Clusterkeyprotokoll ermöglicht keine Authentifizierung der erhaltenen Schlüssel:
– Angreifer kann zufällige Nachricht schicken, führt zum Überschreiben des Schlüssels (→DoS)
– Einsatz von MAC würde dies verhindern
Probabilistische Schlüsselverwaltung
– Grund: gemeinsamer Gruppenschlüssel führt zu geringer Sicherheit, individuelle Schlüssel zwischen allen Knoten
zu teuer
– Idee:
– jedem Knoten zufällig einen Schlüsselring mit einer kleinen Anzahl an Schlüsseln aus einem großen
Schlüsselpool geben
– Knoten entdecken Schlüssel, die sie mit anderen Nachbarn teilen
– richtige Anpassung der Größe von Schlüsselpool und Schlüsselring ermöglicht ausreichenden Grad an
Sicherheit
– drei Phasen:
– Vorverteilung der Schlüssel
– Entdecken gemeinsamer Schlüssel
– Einrichten von Pfadschlüssel
Vorverteilung
– Erzeugen eines großen Schlüsselpools
– für jeden Sensorknoten zufällig k Schlüssel auswählen
–
–
Sensor-ID mit Schlüssel-ID in Basisstation speichern
gemeinsamen Schlüssel zur sicheren Kommunikation mit Sensor in Basisstation speichern
Entdeckungsphase
– nach Aussetzen der Knoten entdecken Knoten ihre Nachbarn → topologischer Zufallsgraph entsteht
– Knoten können entweder ihre Schlüssel-ID bekannt geben (unsicher, Angreifer bekommt mit wer welche Schlüssel
hat), oder Liste an IDs verschlüsselt broadcasten → andere Knoten müssen alle ihre Schlüssel durchprobieren
Einrichten der Pfadschlüssel
– Pfadschlüssel werden an Knoten verteilt, die keine gemeinsamen Schlüssel haben, aber über zwei oder mehr Links
verbunden sind
– genauer Ablauf nicht weiter spezifiziert
Zurückziehen von Knoten
– wenn Knoten kompromittiert wurde, müssen alle Schlüssel seines Rings zurückgezogen werden
– Basisstation generiert Signaturschlüssel, sendet ihn verschlüsselt zu jedem Knoten
– anschließend sendet er Liste an Schlüsseln, die zurückgezogen werden müssen
– führt zum Ausschluss des kompromittierten Sensors, und eventuell ein paar Knoten mehr
– Nachteil: kompromittierter Knoten kann Nachricht zum Zurückziehen von Knoten selber generieren
Modifizierung der Vorverteilung
– Bedingung, dass mehrere gemeinsame Schlüssel existieren müssen (q-composite scheme):
– Vorteil: Angreifer hat weniger Nutzen vom Kompromittieren eines einzelnen Knotens
– Nachteil: Schlüsselpool muss verkleinert werden, damit Wahrscheinlichkeit von gemeinsamen Schlüsseln
steigt
– Multipath key reinforcement:
– Idee: Weg zwischen zwei Knoten wird genutzt, um Zufallswerte zu übertragen und darüber neuen,
sicheren Schlüssel zu generieren
– je mehr Pfade genutzt werden, desto schwieriger wird es für einen Angreifer alle zu überwachen
Sicherheitsbemerkungen zu probabilistischer Schlüsselverwaltung
– hohe Wahrscheinlichkeit von gemeinsamen Schlüsseln zweier Knoten spielt Angreifer in die Hände:
– Angreifer, der mehr als einen Knoten kompromittiert hat, hat hohe Wahrscheinlichkeit mit jedem anderen
Knoten mindestens einen gemeinsamen Schlüssel zu besitzen
– existiert auch mit q-composite scheme aufgrund reduzierter Größe des Schlüsselpools
– Entdecken von kompromittierten Knoten bleibt offene Frage
– keine Knoten-zu-Knoten Authentisierung
Sichere Datenaggregation
–
–
–
Ziel: Sicherstellen der Datenintegrität
(schlechte) Möglichkeiten:
– jeder Knoten fügt MAC zu seinen Daten hinzu, wird an Basisstation gesendet → Datenaggregation in
Basisstation, hohe Übertragungskosten
– nur der Knoten fügt MAC hinzu, der Daten gesammelt hat → kompromittierter Knoten kann falsches
Ergebnis weiter schicken
Idee:
– mehrere Knoten sammeln Daten und signieren ihre Ergebnisse → zwischen Basisstation und Knoten
individueller Schlüssel benötigt
– einige Knoten arbeiten als Sammelknoten („data fusion nodes“), aggregieren auch Daten und schicken
Ergebnis zur Basisstation, zusätzlich noch Aggregierungsfunktion über Nachbarn anwenden oder einzelne
MACs der Nachbarn anfügen (als Zeugen)
Variante 1: (m+1) out of (m+1) voting scheme
– alle Knoten senden MAC zu Sammelknoten
– Sammelknoten berechnet neuen MAC über alle erhaltenen Hashs, schickt MAC und Identität der erzeugenden
Knoten an Basis
– Basisstation nimmt Resultat und berechnet über Hash und Identitäten die Einzelresultate
– Nachteil: wenn ein Knoten falsche MAC schickt, wird aggregierte Information von Basisstation abgelehnt → DoSAngriff möglich
Variante 2: n out of m+1 voting scheme
– Sammelknoten sendet alle MACs
– Basisstation prüft, ob mindestens n von m+1 MACs übereinstimmen
– Vorteil: robuster gegenüber Angriffen
– Nachteil: höherer Kommunikationsaufwand
Erhalten eines Ergebnisses bei Kompromittierung des Sammelknotens
– Basisstation wählt anderen Knoten als Sammelknoten aus
Bemerkungen
– alle Daten werden im Klartext übertragen, Angreifer kann einfach gültige MACs abhören
– Angreifer kann Nachrichten wiedereinspielen
– Ausbesserung:
– fehlende Verifikation → Aktualitätsprüfung über Zufallszahl, die von der Basisstation regelmäßig verteilt
wird, oder Zeitstempel (benötigt Synchronisation)
– warum Ergebnisse nicht direkt zur Basisstation sondern über Sammelknoten?
– Angreifer kann falsche MACs verschicken → DoS
Schlussfolgerung
– Optimierung ist der beste Freund des Angreifers
– Sicherheit lernt man am besten von Fehlern