32.9 Verdeckte Kanäle und Anonymität
Eine im Normalfall (das heißt außerhalb von elektronischen Ausweisen und etwa dem Militär) weniger wichtige Sicherheitsproblematik, die allerdings für die Forschung und aus technischer Sicht sehr interessant ist, sind verdeckte Kanäle (engl. covert channels), die ein Themengebiet der Steganografie sind. [Fn. Bei der Steganografie geht es um das Verstecken von geheimen Informationen in unauffälligen Informationen, etwa Geheimtexte in Bildern.] Verdeckte Kanäle wurden 1973 von B. Lampson entdeckt und beziehen sich eigentlich auf die Informationsflüsse in Multi-Level-Secure-Systems (MLS), also Systemen mit verschiedenen Sicherheitsstufen. In solchen Systemen soll zum Beispiel ein Prozess mit Top-Secret-Einstufung nicht einfach Daten an einen Prozess mit Secret-Level-Einstufung senden können (man bezeichnet dieses als »No Write Down«-[NWD]-Problematik). Andersherum gedacht soll kein »Read Up« (NRU) möglich sein, also etwa ein Secret-Level-Prozess auf Daten des Top-Secret-Level-Prozesses zugreifen können.
Nun aber zurück zur Linux-Sicherheit. Verdeckte Kanäle können generell nämlich auch als parasitäre Kommunikationskanäle betrachtet werden. Dabei werden etwa Attribute oder zeitliche Werte als Informationsträger verwendet, die eigentlich nicht dazu gedacht sind, Informationen von Nutzern zu übertragen. Beispielsweise können geheime Informationen im Payload von ICMP-Paketen oder im TTL-Wert eines IPv4-Headers übertragen werden.
2004 hat Joanna Rutkowska einen passiven verdeckten Kanal (passive covert channel) in den Linux-Kernel implementiert, indem Sie die TCP ISN (Initial Sequence Number) durch verschlüsselte verdeckte Informationen ersetzte. Den zugehörigen Code, genannt NUSHU, finden Sie auf http://invisiblethings.org. Passiv ist ein solcher Kanal, da er keinen eigenen Traffic erzeugt, sondern vorhandenen Traffic, der von Benutzern generiert wird, vor dem Senden kernelseitig modifiziert.
Diverse weitere Implementierungen für den Userspace gibt es natürlich auch. Darunter etwa Ping Tunnel [Fn. Siehe http://www.cs.uit.no/~daniels/PingTunnel/] oder die Forschungsentwicklungen PHCCT (protocol hopping covert channel tool) und PCT (protocol channel tool) von einem der Autoren dieses Buches, [Fn. Siehe www.wendzel.de, dort finden Sie auch diverse weitere Publikationen meiner Wenigkeit zum Thema.], bei denen Protokollwechsel innerhalb von verdeckten Kanälen stattfinden oder durch einen verdeckten Protokollwechsel selbst sogar die eigentliche Information dargestellt wird. Verdeckte Kanäle sind heute über praktisch alle typischen Netzwerkprotokolle (zum Beispiel TCP, HTTP, DNS, UDP, NNTP, SMTP, POP3, ICMP, IPv6, VoIP, ...) möglich.
Die Detektion verdeckter Kanäle ist in der Praxis äußerst schwierig und aufwendig. Entweder muss schon während der Designphase von Systemen darauf geachtet werden, verdeckte Kanäle zumindest einzudämmen, oder es müssen (meist größere) Einschränkungen an einem System gemacht werden, um sie während des Betriebs einzudämmen. Eine hundertprozentige Vermeidung von Covert Channels ist im Normalfall ausgeschlossen. Sollten Sie sich mehr für diese sehr akademische Thematik interessieren, dann suchen Sie mit einer Suchmaschine Ihrer Wahl doch einmal nach wissenschaftlichen Veröffentlichungen zu den Themen Covert Flow Trees, Network Pumps, Shared Resource Matrix, Multilevel Secure Systems, Confinement Problem, Subliminal Channel oder Channel Capacity ;)
Ein angrenzendes Thema ist natürlich die Anonymität. Diese ist auch ohne Steganografie möglich, besonders durch den Einsatz von Kryptografie; sie kommt in diesem Bereich tatsächlich bei einigen freien Projekten zum Einsatz. Am bekanntesten dürfte wohl das Tor-Projekt (torproject.org) sein, bei dem kryptografisches Onion-Routing verwendet wird, um die Anonymität eines Benutzers zu gewährleisten. Onion-Routing basiert auf der 1981 von David Chaum eingeführten MIX, die auf asymmetrischer Kryptografie basiert.
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.
