Sicherheit in Rechnernetzen: - Professur Datenschutz und ...
Sicherheit in Rechnernetzen: - Professur Datenschutz und ...
Sicherheit in Rechnernetzen: - Professur Datenschutz und ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
16<br />
A. Pfitzmann: Datensicherheit <strong>und</strong> Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr<br />
15<br />
A. Pfitzmann: Datensicherheit <strong>und</strong> Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr<br />
Trotz dieser Abschätzung des Angreifers sollte e<strong>in</strong> gegen ihn sicheres System mit<br />
vertretbarem Aufwand gebaut <strong>und</strong> betrieben werden können sowie für dieses System<br />
e<strong>in</strong> überzeugender Nachweis aller aufgestellten Schutzziele gel<strong>in</strong>gen.<br />
die Welt<br />
die Welt<br />
betrachtetes<br />
IT-Gesamtsystem<br />
betrachtetes<br />
IT-Gesamtsystem<br />
Die Lebensdauer des Systems hat nicht nur E<strong>in</strong>fluß auf die zu unterstellende Meß- <strong>und</strong> Gerätetechnik<br />
des künftigen Angreifers, sondern auch auf se<strong>in</strong>e Motivation, se<strong>in</strong>en Zeit- <strong>und</strong> Gelde<strong>in</strong>satz sowie<br />
se<strong>in</strong>e Risikobereitschaft. All dies kann durch politische Entwicklungen oder Steigerungen des Wertes<br />
(sei es ökonomisch oder politisch) der mit dem System verarbeiteten Daten oder der Abhängigkeit von<br />
Individuen, Organisationen oder gar Staaten vom Funktionieren des Systems drastisch zunehmen. Im<br />
Zweifelsfall sollte also nicht e<strong>in</strong>e genauere Risikoanalyse, die wegen der Unvorhersehbarkeit<br />
mancher dieser Entwicklungen nicht möglich ist, versucht werden, sondern der Aufwand sollte lieber<br />
<strong>in</strong> den Bau e<strong>in</strong>es gegen stärkere Angreifer sicheren Systems <strong>in</strong>vestiert werden.<br />
Systemteile<br />
des Angreifers<br />
Systemteile<br />
des Angreifers<br />
verändernder Angreifer<br />
beobachtender Angreifer<br />
1.3 Was bedeutet <strong>Sicherheit</strong> <strong>in</strong> <strong>Rechnernetzen</strong>?<br />
nur erlaubtes Verhalten auch verbotenes Verhalten<br />
Ohne Anspruch auf Vollständigkeit <strong>und</strong> Genauigkeit seien hier e<strong>in</strong>ige mögliche Schutzziele für<br />
Rechnernetze genannt. Sie werden <strong>in</strong> §5 vertieft behandelt, nachdem <strong>in</strong> §3 die dazu notwendigen<br />
begrifflichen <strong>und</strong> kryptologischen Gr<strong>und</strong>lagen dargestellt wurden.<br />
Bild 1-7: Beobachtender vs. verändernder Angreifer<br />
Schutzziel Vertraulichkeit<br />
• Nachrichten<strong>in</strong>halte sollen vor allen Instanzen außer dem Kommunikationpartner vertraulich<br />
bleiben.<br />
• Sender <strong>und</strong>/oder Empfänger von Nachrichten sollen vore<strong>in</strong>ander anonym bleiben <strong>und</strong> durch<br />
Unbeteiligte (<strong>in</strong>kl. Netzbetreiber) nicht beobachtet werden können.<br />
Schutzziel Integrität<br />
• Fälschungen von Nachrichten<strong>in</strong>halten (<strong>in</strong>kl. des Absenders) sollen erkannt werden.<br />
• Der Empfänger soll gegenüber Dritten nachweisen können, daß Instanz x die Nachricht y<br />
gesendet hat (<strong>und</strong> ggf. auch den Zeitpunkt, an dem dies geschah).<br />
• Der Absender soll das Absenden e<strong>in</strong>er Nachricht mit korrektem Inhalt beweisen können, möglichst<br />
sogar den Empfang der Nachricht (<strong>und</strong> ggf. auch den Zeitpunkt, an dem dies geschah).<br />
• Niemand kann dem Netzbetreiber Entgelte für erbrachte Dienstleistungen vorenthalten. Umgekehrt<br />
kann der Netzbetreiber nur für korrekt erbrachte Dienstleistungen Entgelte fordern.<br />
Zugegeben, die letzten drei Schutzziele unter Integrität zu fassen, ist etwas gezwungen! Alternativ<br />
müßten weitere Schutzziele e<strong>in</strong>geführt werden, was leicht <strong>in</strong>s Uferlose ausartet, vgl. das Ende von<br />
§1.2.1. Das letzte Schutzziel könnte allerd<strong>in</strong>gs auch unter Verfügbarkeit e<strong>in</strong>geordnet werden.<br />
In §1.2.2 wurde schon zwischen dummen oder zufälligen Fehlern <strong>und</strong> <strong>in</strong>telligenten zielgerichteten<br />
Angriffen unterschieden. Bei letzteren lohnt es sich, noch genauer zu unterscheiden: Wieviel Rechenkapazität<br />
wird dem Angreifer zugebilligt?<br />
Auf der sicheren Seite liegt man, wenn man ihm unbeschränkte Rechenkapazität zubilligt. Man<br />
spricht dann von e<strong>in</strong>em komplexitätstheoretisch unbeschränkten (oder kürzer: <strong>in</strong>formationstheoretischen)<br />
Angreifer. <strong>Sicherheit</strong>sbeweise s<strong>in</strong>d dann <strong>in</strong> der <strong>in</strong>formationstheoretischen Modellwelt von<br />
Claude Shannon zu führen, was <strong>in</strong> §3 genauer erläutert wird.<br />
Man riskiert etwas, wenn man annimmt, daß der Angreifer nur beschränkte Rechenkapazität<br />
(genauer: Berechnungsfähigkeiten) besitzt, z.B. große Zahlen <strong>in</strong> vernünftiger Zeit nicht <strong>in</strong> ihre Primfaktoren<br />
zerlegen kann, vgl. ebenfalls §3. Man spricht von e<strong>in</strong>em komplexitätstheoretisch beschränkten<br />
(oder kürzer: komplexitätstheoretischen) Angreifer. Hier kann man sich bezüglich der<br />
Hardware-Betriebsmittel <strong>und</strong> Algorithmenkenntnis des Angreifers irren. Das Hauptrisiko liegt, wie<br />
wir <strong>in</strong>sbesondere <strong>in</strong> §3 sehen werden, <strong>in</strong> e<strong>in</strong>er falschen E<strong>in</strong>schätzung der Algorithmenkenntnis.<br />
Schutzziel Verfügbarkeit<br />
• Das Rechnernetz ermöglicht Kommunikation zwischen allen Partnern, die dies wünschen (<strong>und</strong><br />
denen dies nicht verboten ist).<br />
Als Konkretisierung von komplexitätstheoretischen Angreifern, aber auch allgeme<strong>in</strong>, etwa bzgl.<br />
verwendbarer Meßtechnik, kann man Angreifer danach unterscheiden, wieviel Zeit <strong>und</strong> Geld sie<br />
haben <strong>und</strong> aufzuwenden bereit s<strong>in</strong>d. Und ganz untechnisch können sie Geld auch außerhalb des IT-<br />
Systems e<strong>in</strong>setzen: Bestechung von Menschen ist <strong>in</strong> vielen Situationen das wirksamste Mittel, um<br />
z.B. Entwerfer zum E<strong>in</strong>bau Trojanischer Pferde, Betreiber zur Manipulation des IT-Systems oder<br />
Zugangsberechtigte zur Zusammenarbeit zu bewegen.<br />
Diese Schutzziele s<strong>in</strong>d vielschichtig <strong>und</strong> gelten nicht für alle Beteiligten jeweils gleichstark. Je nach<br />
Kommunikationsgegenstand <strong>und</strong> -umstand werden e<strong>in</strong>zelne Schutzziele sogar für denselben Nutzer<br />
e<strong>in</strong>e unterschiedliche Bedeutung haben.<br />
1.4 Warum mehrseitige <strong>Sicherheit</strong>?<br />
Das Aufstellen e<strong>in</strong>es realistischen Angreifermodells ist e<strong>in</strong>e ähnliche Kunst wie das Abschätzen <strong>in</strong><br />
mathematischen Beweisen: Ist die Abschätzung zu grob, gel<strong>in</strong>gt der Beweis nicht mehr. Ist die<br />
Abschätzung zu fe<strong>in</strong>, wird der Beweis unnötig kompliziert, fehlerträchtig <strong>und</strong> wenig überzeugend.<br />
Bezogen auf Angreifermodelle bedeutet dies, daß oftmals unterstellt wird, daß alle möglichen<br />
Angriffspunkte <strong>und</strong> Angriffsarten zu e<strong>in</strong>em Angreifer komb<strong>in</strong>iert werden, obwohl man für die<br />
Realität hoffen kann, daß die diese Angriffspunkte kontrollierenden Instanzen nicht alle mite<strong>in</strong>ander<br />
konspirieren <strong>und</strong> perfekt abgestimmt handeln werden.<br />
Verallgeme<strong>in</strong>ern wir etwas:<br />
Wir möchten, daß möglichst jede(r) gegen jede(n) geschützt ist. Denn jede(r) kann durch Geräte<br />
mit Trojanischen Pferden, Bedienungsfehler, Eigen<strong>in</strong>teressen oder gar Bösartigkeiten die Schutz<strong>in</strong>teressen<br />
anderer bedrohen <strong>und</strong> muß deshalb aus deren Sicht als potentieller Angreifer gesehen werden.<br />
E<strong>in</strong> realistisches Angreifermodell sollte nicht nur alle momentan erwarteten<br />
Angreifer, sondern auch alle während der Lebensdauer des Systems zu erwartenden<br />
Angreifer abdecken. Es sollte e<strong>in</strong>fach se<strong>in</strong>, damit die nicht abgedeckten Restrisiken<br />
durch unerwartet starke Angreifer den vom System Betroffenen verständlich s<strong>in</strong>d.