Alfried Krupp von Bohlen und Halbach Stiftungslehrstuhl „Technik der Rechnernetze“ Institut für Experimentelle Mathematik und Institut für Informatik und Wirtschaftsinformatik

4. Essener Workshop „Neue Herausforderungen in der Netzsicherheit“

Sichere Mobilität und Dienstnutzung

in künftigen Netzen

15. - 16. April 2010

Abstracts

Gemeinsam organisiert von der ITG-Fachgruppe 5.2.2 Sicherheit in Netzen, der GI-Fachgruppe Sicherheit in Netzen (NETSEC) und der GI/ITG-Fachgruppe Kommunikation und verteilte Systeme (KUVS)

Seite 1 von 2 • NAC: Best practise guide

Was ist denn dieses NAC? Network Access Control, manche nennen es auch Network Admission Control oder einfach und kurz „NAC“ ist mittlerweile ein geläufiger Begriff in der IT Security Welt. Doch was steckt genau dahinter? Es ist immer wieder überraschend, wie sehr die Erwartungen und Vorstellungen zu NAC auseinander gehen. Manche verbinden hiermit eine schlichte Registrierung und Autorisierung von Endgeräten anhand der (nicht ganz so) eindeutigen MAC Adresse im IP Netzwerk. Andere hingegen verbinden mit NAC den Schutz des gesamten Netzwerkes vor Viren, Würmern und Netzwerkgeräten, die nicht den Unternehmensrichtlinien entsprechen. Oder auch eine Lösung für den kontrollierten Zugriff von Gästen wird als NAC bezeichnet. Die einfache Antwort auf die Frage ob dies denn nun NAC sei, lautet kurz: Ja. NAC beinhaltet eine Vielzahl von Prozessen, die den Zugang zum Netzwerk ermöglichen und gleichzeitig die Sicherheit sicherstellen sollen. Die einzelnen Prozesse oder auch Schritte sind:

- Detect Eindeutige Identifizierung und Lokalisierung von neuen Geräte am Netz

- Authenticate Eindeutige Authentifizierung der Identität der Nutzers und/oder Gerätes

- Assess Prüfung des Endgerätes auf Richtlinienkonformität und/oder Schwachstellen (Vulnerabilities)

- Authorize Zugangserlaubnis mit möglichen Beschränkungen (wie Quarantäne) basierend auf dem Ergebnis der Authenfizierung und des Assessments

- Remediate Beheben von Problemen und Sicherheitsmängeln – aber auch automatisierte Kommunikation mit den Nutzer (Hilfestellung, Statusmeldungen)

- Monitor Überprüfung des Nutzer und Geräteverhaltens während der gesamten Zeit am Netzwerk

- Contain Reaktive Quarantäne bei der Festellung von verdächtigen Verhalten des Endsystems

Seite 2 von 2 • NAC: Best practise guide

In den folgenden Kapiteln werden wir uns jeden dieser einzelnen Schritte genauer anschauen und uns mit den jeweiligen, ganz eigenen Herausforderungen auseinandersetzen. Manchmal gibt es mehrere Lösungen für ein Problem, welche gesondert durch kleine Infokästen dargestellt werden. Hier gilt, je grüner, desto besser, umfangreicher oder preiswerter. Ein Beispiel:

Vorbereitungen NAC ist, wenn es unternehmensweit eingeführt wird, ein umfangreiches Projekt, welches eine gute Vorbereitung voraussetzt. In der Tat ist dies sogar entscheidend für den Erfolg der späteren Umsetzung, da viele Probleme im Vorfeld erkannt und gelöst werden können. Dieses Dokument ist ein erster Schritt für genau jene Vorbereitungen. Alle nachfolgenden Kapitel stellen die verschiedenen Phasen der NAC Implementierung dar. Es mag erstaunlich erscheinen, aber der technische Ablauf ist in der Tat auch gleichzeitig der beste Ablauf für den Projektverlauf. Zuerst werden alle Endsysteme und Typen erfasst. Danach wird der beste Weg einer Autorisierung gemäß den Fähigkeiten der Endsysteme gewählt. Für viele endet hiermit schon NAC, was auch ausreichend ist um eigene Systeme und Gäste oder gar Eindringlinge zu ermitteln und im Netz zu isolieren. Der nächste große Block besteht aus dem Assessment, der Prüfung des Endsystems, und der Remediation. Das Ziel hier ist die Sicherstellung einer unternehmensweiten Richtlinie, die den Sicherheitszustand aller Endsysteme erkennt und darüber hinaus den Zugang in das Netzwerk über eine Autorisierung granular reguliert. Ein permanentes Monitoring stellt diesen Zustand auch über den eigentlichen Zugang hinaus sicher und ermöglicht es, jederzeit eine qualitative Aussage zur Sicherheit der gesamten IT Infrastruktur zu treffen. Einzig das Monitoring kann auch sinnvoll nach vorne in der Implementierung gezogen werden, nämlich direkt nach der „Detection“ Phase – falls auschliesslich ein reaktives Security Konzept realisiert werden soll.

Das Konzept Aller Anfang beginnt auf dem Papier oder besser gesagt, mit der Idee. Gerade diese Idee, die Frage „Warum wollen wir NAC?“, ist entscheidend für den Umfang des gesamten Projektes.

+ schnelle Implementierung + geringe Einstiegskosten + Anbindung an andere Applikationen - erhöhter Personalaufwand - hohe Folgekosten - mäßige Security Funktionalität - schlechte Skalierbarkeit

Fazit: Diese Löung eigenet sich nur für kleinere Unternehmen mit geringem Budget und kleinen Netzwerken. Der Einsatz in großen/schnell wachsenden Unternehmen ist nicht zu empfehlen. Einstiegskosten &

Wartung

Skalierbarkeit

Funktionsumfang

Adm

inistrativer Aufw

and

Sicherheitswert

Zusätzliche Funktionen (ausser Sicherheit)

Ein Telco Identity Enabler Konzept zur Verwaltung nutzerspezifischer Daten innerhalb von NGNs

Florian Deinert Peter Weik Fabian Förster TU Berlin Fraunhofer Institut FOKUS

florian.deinert@tu-berlin.de peter.weik, fabian.foerster@fokus.fraunhofer.de

Da es im Internet auf Applikationsebene keinen universellen Authentifizierungsmechanismus gibt, müssen

sich Benutzer heutzutage gegenüber jedem Dienstanbieter erneut authentifizieren und diesem Daten

bereitstellen, um Anwendungen personalisiert zu nutzen. Insbesondere der Erfolg des Web 2.0 hat dazu

geführt, dass jeder Internetnutzer heute eine Vielzahl von Nutzer IDs und Passwörtern zu verwalten hat, eine

Praxis, die nicht nur unkomfortabel sondern auch unsicher ist. Im Mobilfunk dagegen ist jedem Teilnehmer

eine eindeutige Identität, abgelegt auf einer Universal Integrated Circuit Card (UICC) zugeordnet. Die sichere

Authentifizierung und Authorisierung gegenüber dem Netzbetreiber geschieht automatisch nach der Freigabe

des Zugriffs durch eine PIN, ohne explizites Zutun des Benutzers.

Im Gegensatz zu geschlossenen Telekommunikationsinfrastrukturen wie ISDN oder GSM in denen der

Netzbetreiber als einziger Dienstanbieter auftritt, werden all-IP Next Generation Networks (NGNs)

Dienstplattformen mit offenen APIs für Telekommunikationsnetze (z.B. auf Basis der momentanen OMA Next

Generation Service Interfaces (NGSI)) bereitstellen, auf denen verschiedene Anbieter eine Vielzahl von

Applikationen selbst entwickeln sollen. Das Identity Management in solchen Architekturen ermöglicht den

Austausch nutzerspezifischer Daten nicht nur innerhalb der Domain des Netzbetreibers, sondern bietet vor

allem die Möglichkeit der kontrollierten Freigabe der aus verschiedenen Quellen aggregierten Attribute eines

NGN Nutzers, die kontrolliert und sicher über Domaingrenzen hinweg erfolgen kann. Die Frage lautet also:

wie können Identitäten in den Telekommunikationsnetzen zukünftig sicher verwaltet werden, um einen

Mehrwert für die Dienstewelt des Internets und vor allem für die Nutzer zu bieten?

Für die zentrale, sichere Speicherung und Administration von Identitätsdaten für NGNs wird von der ITU-T,

ETSI sowie der Open Mobile Alliance die Einführung eines Identity Enablers vorgeschlagen, jedoch im

wesentlichen bislang nur mit Anforderungen belegt. Der Identity Enabler wird vom

Telekommunikationsbetreiber administriert, um sowohl für interne als auch externe Anwendungen

Identitätsdienste anzubieten. Die Notwendigkeit eines Identity Enablers, so wie die Anforderungen an solch

eine universelle Identity Management Komponente wurden von der OMA, so wie von der ITU-T in [1] und [2]

analysiert. Demzufolge sollte ein Identity Enabler unter anderem folgende Möglichkeiten bieten:

- Sichere Authentifizierung von Benutzern und Diensten

- Konfiguration von Berechtigungen und Richtlinien (Policies)

- Einbindung von Identitätsdatendaten aus verschiedenen Quellen

- Verwaltung verschiedener Rollen (Personas)

- Unterstützung verschiedener Identity Management Technologien

Basierend auf diesen Anforderungen entwickelt die Technische Universität Berlin derzeit in Kooperation mit

dem Fraunhofer Institut FOKUS einen prototypischen Telco Identity Enabler namens GUIDE (Generic Unified

IDentity Enabler), der die beschriebenen Identitätsdienste in einer einzelnen Komponente integriert. GUIDE

kombiniert Identitätsmanagement Konzepte der OMA, 3GPP, ETSI [6] sowie ITU-T und ermöglicht es

Netzbetreibern, Identitätsdienste externen Partnern anzubieten [3] [4].

GUIDE ist ein Prototyp eines Telco ID Enablers [7], der mit Hilfe einer modularen Architektur und der Nutzung

offener Protokolle als verteiltes System implementiert ist. Konkrete IdM Protokolle,

Authentifizierungsmethoden, Attributquellen und Policy-Auswertungsmechanismen können über REST-

basierte Webservice-Schnittstellen dynamisch hinzugefügt oder entfernt werden.

Anstatt sich gegenüber jeder Anwendung einzeln zu authentifizieren, erfolgt der Identitätsnachweis

ausschließlich gegenüber dem Identity Enabler (Single Sign On). Dazu werden verschiedene sichere

Authentifizierungstechnologien, wie z.B. 3GPP’s Generic Bootstrapping Architecture (GBA) oder Hardware-

Token, alternativ zur Passwort Authentifizierung zur Verfügung gestellt. Biometrische Authentifizierungs-

Verfahren sind ebenfalls denkbar. Identitätsdaten enthalten oft auch sog. persönlich identifizierbare

Informationen (PII), die nicht jedem zur Verfügung gestellt werden dürfen. Einige Daten dürfen somit nur

unter bestimmten Umständen bzw. nur gegenüber bestimmten Diensten herausgegeben werden. Dazu

ermöglicht der Identity Enabler die Konfiguration von kaskadierenden Policies, d.h. Policies können sowohl

vom Endnutzer konfiguriert, als auch vom Netzwerkanbieter vorgegeben werden. Natürlich können anhand

von Policies auch rechtliche Vorgaben, wie z.B. Datenschutzaspekte, sichergestellt werden. Für die Erstellung

von Policies werden bei GUIDE die XML basierten Standards XACML so wie Common Policies genutzt.

Nutzerdaten eines NGN beinhalten personenbezogene Daten bzw Attribute (wie Adresse, Kontaktlisten) und

applikationsspezifische Daten wie Einstellungen. Diese Daten werden üblicherweise in verschiedenen

Datenbanken gespeichert. Der Identity Enabler ermöglicht die Einbindung von verschiedenen Attribut-

Quellen und stellt damit für externe Anwendungen eine virtuelle zentrale Datenbank mit

Identitätsinformationen bereit.

Eine digitale Identität ist eine Sammlung von Attributen, gekoppelt mit einem eindeutigen Identifier, die sich

eindeutig einem bestimmten Nutzer zuordnen lässt. Mit Hilfe des Identity Enablers lassen sich verschiedene

digitale Rollen, sogenannte Personas, erstellen und verwalten. Nach erfolgreicher Authentifizierung wählt der

Benutzer eine vorhandene Persona je nach Kontext aus, um sich mit dieser Identität gegenüber einer

Anwendung zu präsentieren. Da es kein einheitliches Protokoll für den Austausch von Identitätsdaten gibt,

unterstützt GUIDE die derzeit am weitesten verbreiteten Identity Management Technologien: SAML 2.0,

OpenID sowie demnächst Information Cards.

Die Prototyp-Implementierung des Identity Enablers GUIDE ist Teil der SOA Architektur des Open SOA Telco

Playgrounds am Fraunhofer Institut FOKUS [5]. Auch wenn die Verwendung eines Identity Enablers einen

neuen Angriffspunkt schafft, bietet dessen Einsatz ein zusätzliches Maß an Sicherheit, da Passwörter nicht

mehr in verschiedenen vermeintlich unsicheren Komponenten gespeichert werden.

[1]. International Telecommunication Union, NGN Identity Management Requirements and Use Cases, TD 62 (WP 4/13), 2009

[2] Open Mobile Alliance, Identity Management Framework Requirements, Candidate Version 1.0, 2005

[3] International Telecommunication Union, Draft Recommendation Y.2720, NGN Identity management framework, 2008

[4] 3GPP TR 33.924, Identity management and 3GPP security interworking, Identity management and Generic Authentication Architecture

(GAA) interworking, Release 9, 12/2009

[5] Open SOA Telco Playground, Fraunhofer FOKUS, www.opensoaplayground.org

[6] ETSI Identity Access Management for Networks and Services - http://portal.etsi.org/ins

[7] GUIDE Prototyp eines Telco ID Enablers – http://id.open-ims.org

Network Access Challenges in a Future InternetChristoph Werle, Lars Völker

Institut für Telematik,Karlsruhe Institute of Technology,

Germany(werle, voelker)@kit.edu

I. INTRODUCTION

Network virtualization describes the concept of runningmultiple virtual networks (VNets) on top of a set of commonphysical resources, i.e., the substrate, in a controlled manner.The goal of network virtualization is to foster innovationnot only at the edge of the network as is often the casewith today’s overlay networks. Instead network virtualizationpromises to enable the deployment of nearly arbitrary networkarchitectures also within the network on a global scale in acompetitive environment [1].

For the time being, we will base on the network virtu-alization architecture developed within the 4WARD projectbut are also considering to evaluate our end user attachmentscheme with other network virtualization proposals in thefuture. 4WARD’s current network virtualization approach con-siders three main actors involved in the network virtualizationarchitecture (see Figure 1):

• Infrastructure Providers (InPs) own and maintain thephysical infrastructure and offer to lease out virtualizedparts of their infrastructure to third parties.

• In an interprovider environment, Virtual NetworkProviders (VNPs)—a role introduced mainly for busi-ness reasons, e.g., to handle contractual issues—assemblevirtual networks from the resources of one or moreInfrastructure Providers on behalf of Virtual NetworkOperators.

• Virtual Network Operators (VNOs) can subsequentlyoperate and manage the virtual network and install anydesired network architecture in their virtual networks. Ad-ditionally, they need to provide support for the end userattachment in the substrate, which allows authenticationof the end user prior to authorization to enter the virtualnetwork and configuration of the end user’s system.

II. END USER ATTACHMENT

In the face of many virtual networks, each providing specificservices with a potentially optimized network architecturerunning inside, it becomes critical to provide end users witha flexible way of attaching to their preferred set of virtualnetworks. For instance, a user may want to access his homeTV service, his closed company network as well as his homenetwork even while he is abroad, staying in a hotel. This sce-nario motivates the following objectives: a) The end user wantsto securely access multiple VNets from his current physicalnetwork access, b) connections to the various VNets should

Figure 1. Actors and Interfaces of the 4WARD VNet Architecture

be set up automatically while also taking authentication andauthorization into account, c) the solution should not dependon globally available IP connectivity as future networks mayuse different protocols.

We already briefly sketched a basic way to fulfill thisrequirement [2] using EAP as a core protocol due to its lowrequirements with regard to the EAP lower layer and its highflexibility of applicable authentication methods.

Figure 2 sketches the overall process:1) Attachment to the substrate access network depends on

access technology, e.g., Ethernet in this example.2) Authentication of the End User to his home network. This

consists of signaling with the Network Access Serverusing, e.g., 802.1X [3] and a suitable authenticationprotocol like EAP-TTLS [4]. The EAP-TTLS payload istransported by a AAA protocol, e.g., today’s Radius [5] orDiameter [6], between the NAS and a Local AAA Server.However, the usage of IP independent AAA protocols isa valid option. In the depicted case of roaming, the LocalAAA Server uses a suitable AAA protocol for communi-cation with the Home AAA Server. This combination ofprotocols allows the End User and Home AAA Server toauthenticate mutually.

3) Using the previously created authentication channel, sig-naling data can be exchanged between End User and theHome AAA Server. The Home AAA Server can in turncontact the VNet AAA Server(s) and the Local AAAServer to negotiate access of the End User to the VNet(s).

This allows for automatic attachment of the End User todifferent VNets initiated by the Home AAA Server. Ifrequired, the End User may optionally request attachmentto additional VNets, not known by the Home AAA server.

4) Using the existing signaling channel, either the EndUser or the Home AAA Server authenticate to the VNetAAA Server. The End User would do this by arbitrarycredentials, while the Home AAA Server may facilitatea pre-existing trust relation with the VNet AAA Server.

5) A virtual link between the End User and the VNet is cre-ated. This may be done without user interaction, so thatan adequate level of usability is being reached. The actualconstruction of the virtual link depends on the underlyingtechnology, e.g., available de-/multiplexing mechanisms.Before communication between the End User and theVNet can take place, it may be necessary that the end usersystem accquires and installs a protocol stack compatibleto the networking protocols used within the VNet. Forthis paper, however, the detailled construction of virtuallinks and the discovery and deployment of protocol stacksis out of scope.

One of the identified main challenges subsumes the auto-mated negotiation of multiplexing mechanisms towards theend user: Instead of dealing with a single link to the Internet(or maybe some static VPI/VCI pairs when using DSL for theprovisioning of triple play services), virtual networks requiredynamic negotiation of the mapping between a virtual networkand the substrate multiplexing used per virtual network.

SubstrateEnd User

Local AAA

HomeNetwork

Home AAA

e.g. EAP-TTLS or similarAuthentication

802.1xAAA Protocol

AAA Protocol

1

2

Signaling3

VNetAAA

VNet

4

3

5NAS

Figure 2. Step by Step End User Attachment

Besides others, challenges include:1) Multihoming To enable redundant connectivity to virtual

networks, end user attachment should support multipleconnections to a virtual network. These might consist ofmultiple connections via the same network access or ofmultiple connections via different network accesses, e.g.,UMTS and an ethernet connection.

2) Mobility When dealing with mobility, the question iswhether or to what extent mobility has to be dealt withwithin the virtual network and what can be taken care ofin the substrate.

3) Heterogeneity With mobility still in mind, heterogeneityquickly leads to the question if current standards, e.g.,Media-Independent Handover (MIH) [7] can be extendedto directly support connectivity to virtual networks during

the handover process or might even be used to realizeload-balancing.

4) Network Access Neutrality A network access providershould not restrict the virtual networks that may beaccessed. End users may have to provide a chargeableentity, however, that allows the network access providerto charge the end user for the provided services.

5) Accountability When multiple users connect to numer-ous virtual networks, which may require billing of theend user, accounting and accountability become veryimportant. It is not feasible for every user to set up aseparate contract with each virtual network providers,whose virtual network(s) the users wishes to access.

6) Identity Management What identities are involved in anetwork virtualization environment and how can they bemanaged with different requirements with regard to, e.g.,privacy per VNet.

III. CONCLUSION

In this paper, we discussed our proposed solution for enduser attachment and have pointed out its challenges in thecontext of network virtualization.

ACKNOWLEDGMENT

This work was carried out in parts within the researchproject 4WARD which is funded by the European Commissionwithin 7th Framework Programme.

REFERENCES

[1] G. Schaffrath, C. Werle, P. Papadimitriou, A. Feldmann, R. Bless,A. Greenhalgh, A. Wundsam, M. Kind, O. Maennel, and L. Mathy, “Net-work virtualization architecture: proposal and initial prototype,” in VISA’09: Proceedings of the 1st ACM workshop on Virtualized infrastructuresystems and architectures. ACM, 2009, pp. 63–72.

[2] C. Werle, L. Völker, and R. Bless, “Attachment of End Users to VirtualNetworks,” in 4th GI/ITG KuVS Workshop on The Future Internet, Zurich,Switzerland, Nov. 2009.

[3] LAN/MAN Standards Committee, “Port-Based Network Access Control,”IEEE Std 802.1X-2004, Nov. 2004.

[4] P. Funk and S. Blake-Wilson, “Extensible Authentication ProtocolTunneled Transport Layer Security Authenticated Protocol Version 0(EAP-TTLSv0),” RFC 5281 (Informational), Internet Engineering TaskForce, Aug. 2008. [Online]. Available: http://www.ietf.org/rfc/rfc5281.txt

[5] C. Rigney, S. Willens, A. Rubens, and W. Simpson, “RemoteAuthentication Dial In User Service (RADIUS),” RFC 2865 (DraftStandard), Internet Engineering Task Force, Jun. 2000, updated by RFCs2868, 3575, 5080. [Online]. Available: http://www.ietf.org/rfc/rfc2865.txt

[6] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko, “DiameterBase Protocol,” RFC 3588 (Proposed Standard), Internet EngineeringTask Force, Sep. 2003, updated by RFCs 5729, 5719. [Online].Available: http://www.ietf.org/rfc/rfc3588.txt

[7] IEEE, 802.21-2008 IEEE Standard for Local and Metropolitan AreaNetworks- Part 21: Media Independent Handover, Institute of Electricaland Electronics Engineers, Inc., Jan. 2009.

Evaluating IEEE 802.11s Against Security Requirements ofWireless Mesh Networks

Andre EgnersUMIC Research Center, RWTH Aachen University

Email: http://itsec.rwth-aachen.de/people

Abstract—Wireless Mesh Networks (WMNs) surely are one of the mostprominent trends for Next Generation Networks. Their future success,however, depends on their security features. We introduce detailedsecurity requirements for WMNs that can be used to analyze existingand future security architectures for WMNs. As an example we presentan analysis of IEEE 802.11s with respect to these security requirements.

I. INTRODUCTION

Wireless Mesh Networks (WMN) represent the fusion of ad-hocand infrastructure wireless networking. The infrastructure of WMNs,namely mesh routers, are connected in an ad-hoc fashion exhibitingall pros and cons. Clients can be part of the infrastructure providingrouting and connectivity for other clients that cannot directly reachmesh routers. The notion of coverage extension by using regularclients and the communication over a wireless backbone introducenew security threats. In [1] the new security challenges arising fromWMNs were identified as the detection of corrupted nodes, securemulti-hop routing and fairness wrt. to the distribution of networkresources. While these challenges are generally accepted in literature,a more detailed generally accepted list of security requirements forWMNs is still missing. As a consequence, it is hard to evaluatestrengths, weaknesses, and open issues of existing proposals such asthe IEEE 802.11s standard. In this paper we take a first step towardsdefining security requirements for WMNs and use them as basis toevaluate the security features provided by IEEE 802.11s [2].

II. SECURITY REQUIREMENTS

This section introduces communication patterns and security re-quirements wrt. Wireless Mesh Networks. In the following we willrefer to a mesh client as MC, mesh router as MR, mesh gatewayas MG and mesh access point as MAP. MCs can either be legacyclients or regular clients with mesh routing functionality. MRs are theentities forming the wireless backbone and connected to other MRsin a wireless fashion. MRs that also serve as first hop for networkaccess of MCs are referred to as MAPs. A MG provides access toother networks, e.g. to the Internet.

Communication Patterns in WMNs between the different networkentities include the following:

• MC ↔ MC, MC↔MR and MC ↔ MG• MR ↔ MG, MR ↔ MRMC↔MC communication refers to communication between two

clients located in the same WMN. MC↔MR communication refers tothe communication between MC and the associated MAP. MC↔MGcommunication refers to traffic destined to leave the WMN throughthe MG, e.g. to a destination somewhere on the Internet. This mayalso include management traffic, e.g. when communicating with aAAA-Server located outside of the WMN. MR↔MR communicationrefers to all traffic between MRs. MR↔MG communication canbe considered as special cases of MR↔MR. It may can includemanagement traffic, but also forwarded user traffic.

Confidentiality is required between two MCs to prevent interme-diate MRs, MCs and outsiders from eavesdropping on the com-munication. While encryption between MC and MR/MAP wouldprevent eavesdropping on the initial wireless connection, it does notsafeguard against eavesdropping by other MRs, MCs and outsiderslocated on the path segment after the initial hop. Therefore, werequire MC↔MG communication to be confidential. This counterseavesdropping threats originating from intermediate MRs, MAPs, andMCs. Additionally MR↔MR communication may also be confiden-tial. For example, if user traffic is confidential between MC↔MG,information who communicates with whom can still be leaked by therouting protocol.

Integrity and replay protection are both important for all of the in-troduced communication patterns. Just as confidentiality, integrity andreplay protection are both required between two MCs, MC↔MAP,and MC↔MG. However, integrity and replay protection are alsorequired for MR↔MR as well as MR↔MG communication. Notethat one can argue that assuming confidentiality of MC↔MG com-munication, integrity without additional confidentiality is sufficienton the first hop between MC↔MAP. The MAP can simply checkwhether the MC’s traffic is allowed to pass. Within the WMNintegrity can be attained between MRs in a hop-by-hop fashion andthe MRs checking the traffic for its legitimacy.

Access Control entails authentication and authorization of networkentities. It is required to control which entities are allowed toaccess the network. Entity authentication can be combined withkey establishment to bootstrap integrity and encryption mechanisms.Authentication is equally important for user and operator, since usersneed to ensure that the network is the one it claims to be, as wellas vice versa. Access control is required for MCs as well as newlyjoining MRs, MAPs, and MGs

Privacy is similar to confidentiality, but is not automaticallyachieved alongside. Privacy issues can for example arise whenauthenticating a MC to a MAP. Although the communication can bekept confidential between MAP and MC, the MAP could still learnidentity attributes of the MC. In context of mobility and repeatedauthentication, tracking also becomes an issue that cannot solelybe solved by keeping the communication between MC and MAPconfidential.

Availability in WMNs is of importance wrt. network access itself,as well as access to offered services and QoS parameters. Forexample, if a AAA-Server is used for access control, its availabilityis of vital importance for network access.

Fairness can directly be influenced by attacking the availability,since denying access to certain parts of the network can be consideredunfair. Fairness in wireless networks is, however, typically related toradio channel access and access to the available network bandwidth.This is of particular importance in WMNs, since multi-hop com-munication imposes additional challenges to the fair distribution ofbandwidth. MCs that communicate with a MG over multiple hops

share the available bandwidth with other nodes that are connected tothe routers on the respective path.

Non-repudiation is especially important in the context of correctbilling. It enables one or multiple service providers to securelydifferentiate users. With a mechanism in place, a user cannot denyhaving committed specific actions.

III. IEEE 802.11S - MESH NETWORKING

Recent IEEE effort to standardize wireless mesh networking isstill in draft status. As opposed to typical wireless network accesscontrol, i.e. 802.11i, this amendment discards the notion of supplicantand authenticator. 802.11s introduces a protocol to simultaneouslyauthenticate two arbitrary peers - both of which can initiate theauthentication protocol and do not necessarily have to be directneighbors. The new protocol is called Simultaneous Authenticationof Equals (SAE) and results in a pairwise master key (PMK) sharedbetween two peers. The authentication protocol assumes a pre-sharedsecret, namely a password to be known to all legitimate networkentities. A so-called Abbreviated Handshake is used for authenticatingpeers that already share a PMK, effectively using less messages thanSAE.

Simultaneous Authentication of Equals: The computations used bySAE are either based on Elliptic Curve Cryptography (ECC) or primemodulus finite cyclic groups. In the following we use the notation ofECC-based SAE in which P (x, y) represents a point on a publiclyknown elliptic curve of the form y2 = x3 + ax + b. By inv we referto the additive inverse element of a point on the elliptic curve.

SAE uses four messages to authenticate two peers in a simulta-neous fashion. The message flow of SAE between parties A and Bis depicted in Figure 1. In the first step the initiating peer generatesa password element (PWE) which represents a point on an ellipticcurve. The PWE is combined with a hash m containing a combinationof MAC addresses of the respective two peers by scalar multiplicationto N = PWE ×m. The initiating peer A constructs

• a commit scalar csA = (randA + maskA) mod r• and a commit element ceA = inv(maskA ×N).

randA refers to a random number which is essential to computingthe key to be shared by both peers. maskA is another value used toblind the transferral of the random number. Upon reception of a peer’scommit, both peers are able to compute the same secret k using a pre-defined key derivation function F . k is derived by each party based onthe other party’s commit message, its own random random number,and N such that A computes k = F ((randA×(csB×N+ceB)) andB computes k = F ((randB × (csA×N + ceA)). The computationeffectively represents a password authenticated ECC Diffie-Hellmankey exchange. Both peers will then build a confirmation message,namely a hash of the secret k, a replay-protection counter and thepreviously exchanged cs and ce values. If the received confirmmessage equals the expected result, authentication is consideredsuccessful. If authentication was successful, both peers will generatea pairwise master key as PMK = H(k ‖ counter ‖ (csA + csB)mod r ‖ F (ceA +ceB)). Once a PMK has been successfully estab-lished, it can later on be used during the Abbreviated Handshake.

The PMK is used to construct a key hierarchy in which a 128-bit Abbreviated Handshake Key Confirmation Key (AKCK), a 256-bit Abbreviated Handshake Key Encryption Key (AKEK), and a 128-bit Mesh Temporal Key (MTK) are computed. The keys AKCK andAKEK are static in the sense that they can be used to provide dataorigin authenticity and data confidentiality in multiple runs of theAbbreviated Handshake and Group Key Handshake. The AKEK isused to encrypt the GTK during the Abbreviated Handshake. The

MTK is used to protect the communication between two peers andderived in a more dynamic manner by also using freshly generatedrandom numbers of both peers as input to the key derivation function.The PMK, AKCK and AKEK’s lifetime is limited by the password’slifetime, whereas the MTK should be regenerated on each peeringinstance.

A B

Fig. 1. ECC-based Simultaneous Authentication of Equals (SAE)

Abbreviated Handshake: The goal of the protocol is to generate afresh MTK between two peers that already share a PMK. The newMTK is randomized by using two fresh random numbers selected bythe peers. Since the peers share a PMK and therefore AKCK andalso AKEK, the exchange of the nonces can be integrity protected.The protocol consists of two messages, i.e. a Peering Open Framewhich also contains the random number and a Peering Confirm Framecontaining the nonce of the respective other peer.

Analysis: The proposed security features offered by the recentIEEE 802.11s draft are rudimentary and inflexible. Although, pass-word based network access can obsolete complex authentication andmanagement infrastructure, it introduces unnecessary inflexibility toa type of network that is supposed to be highly dynamic in nature.Once a peer knows the password in use he can access the network.Since the only additional identity attribute used in the protocols isthe MAC address of a peer, impersonation of arbitrary peers by otherpeers is possible. Since routers are also considered to be peers just asclients, an attacker in possession of the password could impersonatethe network to a client. The issue of excluding a specific client orrouter from the network is not addressed. The operator would have tochange the password used to control the network access, i.e. restartthe whole network.

IV. CONCLUSION

SAE and the Abbreviated Handshake allow for the establishment ofkeys between any two peers in a WMN. However, a password-basedauthentication seems ill fit to the flexibility requirements of WMNssuch as mobility and rejecting network entities after participating inthe network. In addition 802.11s does neither cover access controland MC↔MG communication protection, nor does it address privacy,fairness and availability requirements.

REFERENCES

[1] N. Ben Salem and J.-P. Hubaux, “Securing Wireless Mesh Networks,”Wireless Communications, IEEE, 2006.

[2] “IEEE 802.11s Task Group, Amendment: ESS Mesh Networking, IEEEP802.11s/D3.0.”

Protokolleffizienz in Wireless Mesh NetzwerkenAndreas Noack

Horst Gortz Institut fur IT-SicherheitRuhr Universitat Bochum

E-Mail: andreas.noack@rub.de

Jorg SchwenkHorst Gortz Institut fur IT-Sicherheit

Ruhr Universitat BochumE-Mail: joerg.schwenk@rub.de

I. EINLEITUNG

Wireless Mesh Netzwerke (WMN) bestehen aus einer dyna-mischen Menge von Teilnehmern, die zu einem vermaschtenNetzwerk zusammengefasst werden. Als Kommunikations-technologie kommen hier aktuelle WiFi-Standards zum Ein-satz, wie z.B. Bluetooth, ZigBee oder auch das herkommlicheWireless LAN nach IEEE 802.11.

Die Vermaschung darf genauso wie im heutigen Internetredundant sein. Zwischen zwei Teilnehmern durfen also meh-rere parallele Pfade mit unterschiedlichen Pfadkosten liegen.Die Teilnehmer in Wireless Mesh Netzwerken sind in der Re-gel statisch in ihrer Position, was eine weitere Gemeinsamkeitmit dem Internet darstellt. Die kabellose Kommunikation fuhrtaber im Gegensatz zum Internet zu einer großeren Dynamikder Verbindungen, da Funkverbindungen z.B. durch exter-ne Storungen wegfallen, aber auch neu hinzugefugt werdenkonnen. Die Gruppengroße in WMN ist dynamisch, WMN-Geraten ist das Betreten und Verlassen der Gruppe jederzeiterlaubt.

Wireless Mesh Netzwerke werden aktuell in vielen Berei-chen eingesetzt. Beispiele sind das Community Networking,bei dem sich Privatpersonen zu einem großen freien Netz-werk verbinden, um Informationen auszutauschen oder umgemeinsam eine Internetverbindung zu teilen. Ein Vorreiter imBereich Community Networking ist das Freifunk Projekt [3],das besonders im Raum Berlin eine große Beliebtheit erfahrt.Auch in der Industrie gewinnen WMN stetig an Bedeutung,beispielsweise lassen sich ganze Werkhallen [6], fur die eineherkommliche Kupfer- oder Glasfaserverkabelung zu teuerware, mit einem Mesh Netzwerk kostengunstig vernetzen.Letztlich gibt es auch im militarischen Bereich zahlreicheEinsatzmoglichkeiten fur WMN, z.B. fur die Erzeugung ei-ner Kommunikationsinfrastruktur in Krisengebieten oder Ge-fechtssituationen.

Netzwerkprotokolle sind Regeln, wie und zu welchem Zeit-punkt Datenpakete versendet werden. Diese Protokolle spie-len bei der Kommunikation zwischen Netzwerkteilnehmerneine große Rolle, denn sie finden fast uberall Anwendung.Zusatzlich zu den offensichtlichen Anwendungsfallen wie demInternetsurfen oder dem E-Mailen laufen im Hintergrund Netz-werkprotokolle, die die Funktionalitat oder die Sicherheit desNetzwerks gewahrleisten sollen.

In dieser Ausarbeitung beschaftigen wir uns mit der Mes-sung der Effizienz von Netzwerkprotokollen in Wireless MeshNetzwerken. Zu diesem Zweck schlagen wir ein Modell

fur die Berechnung der Effizienz von Netzwerkprotokol-len vor und demonstrieren dies am Fall von drei Grup-penschlusselaustauschprotokollen (Group Key Agreement).WMN verwenden Gruppenschlusselaustauschprotokolle, umauf der Basis von gemeinsamen Schlusselmaterials eine Ver-schlusselung und Authentifizierung der Nutzdaten zu etablie-ren. Diese Arbeit ist eine Weiterentwicklung von [7].

II. WIRELESS MESH NETZWERKE

Verglichen mit herkommlichen Funknetzwerken habenWMN besondere Eigenheiten. Da WMN meist aus vielen Teil-nehmern bestehen, gibt es auch sehr viele Funkverbindungen,die sich gegenseitig beeinflussen. Die dadurch entstehendeInterferenz hat in WMN mit vielen Teilnehmern einen großenEinfluss auf die Effizienz der Netzwerkprotokolle [4].

Weiterhin haben WMN einen Effizienzvorteil bei der Ver-wendung von lokalen Broadcastnachrichten an mehrere be-nachbarte Teilnehmer, denn diese Nachrichten konnen auf-grund des Funkstandards tatsachlich parallel ubertragen wer-den. Unterschieden werden hingegen globale Broadcastnach-richten, die von jedem Empfanger aktiv weitergeleitet werdenmussen und in WMN wegen der entstehenden Interferenz eherweniger effizient als in herkommlichen Netzwerken sind.

III. PROBABILISTISCHES EFFIZIENZ MODELL

Um die Effizienz der Protokolle vergleichbar zu machen,verwenden wir als Maßeinheit Timeslots (TS).

Definition: Timeslot. In einem interferenzfreien Kanal mitvoller Kapazitat ist ein Timeslot die Zeitspanne, die fur dasVersenden einer lokalen Broadcastnachricht mit maximalerGroße (MTU – Maximum Transfer Unit) benotigt wird.

Die Effizienz eines Netzwerkprotokolls setzt sich aus zweiSummanden zusammen. Der erste Summand ist die Anzahl derTimeslots (TS), die das Netzwerkprotokoll fur die Ausfuhrungbenotigt. Der zweite Summand ist die Anzahl der gleichzeitigubertragenen Nachrichten pro Timeslot (#Nachrichten

Timeslot ), um dieInterferenz in die Effizienzmessung mit einzubeziehen. Dabeiwird der zweite Summand mit einer Unbekannten x multipli-ziert, welche die physikalische Gegebenheiten des WMN wie-derspiegelt (Qualitat der WiFi-Gerate, Hintergrundrauschen,Hindernisse, uvm.).

Gesamtperformanz (TS) = Timeslots + x · # NachrichtenTimeslot

A. Annahme

Die endgultige physikalische Struktur (Topologie) desWMN ist uns unbekannt. Daher berechnen wir die Effizienzjedes Protokolls mit der optimalen Netzwerkstruktur (Bestcase). Als optimale Netzwerkstruktur nehmen wir die internelogische Struktur des Netzwerkprotokolls an.

B. Zahlweise der Nachrichten

• Eine Nachricht zu einem direkten Nachbarn zahlt als 1Nachricht.

• Eine Nachricht zu einem entfernten Nachbarn wird als#Hops Nachrichten gezahlt, wobei die #Hops die Zahlder weiterleitenden Knoten zwischen Start und Ziel ist.

C. Zahlweise der Timeslots

• Eine Nachricht zu einem direkten Nachbarn zahlt als 1Timeslot

• Bei simultan versendeten Nachrichten wird die #Hopsdes langsten Pfades in Timeslots berechnet.

D. Interferenz-Faktor x

Ein Protokoll ist maximal effizient, wenn lediglich dieAnzahl der Timeslots zur Protokollausfuhrung benotigt wer-den, keine interferenzbedingten zusatzlichen Timeslots. Dieminimale Effizienz entsteht, wenn jede einzelne Nachricht ineinem separaten Timeslot versendet wird (keine Parallelitat).Daraus folgt:

x ∈ [0, Timeslots− Timeslots2

#Nachrichten].

Mit zunehmender Große des Netzwerks wachst der maximaleWert fur den Interferenz-Faktor linear, ebenso wie die geo-graphische Große des Netzwerkes. Da beide Effekte einengegensatzlichen Effekt haben, kann fur unterschiedlich großeWMN mit den selben physikalischen Eigenschaften etwa einkonstanter Interferenz-Faktor x festgelegt werden.

IV. ERGEBNISSE

Wir haben drei Gruppenschlusselaustauschprotokolle aufihre Performanz in Wireless Mesh Netzwerken getestet:Burmester-Desmedt I (BD1 [1]), Burmester-Desmedt II (BD2[2]) und Tree Based Key Agreement (TBKA [8][5]).

BD1 hat eine logische Ring-Struktur und arbeitet in seinenzwei Phasen mit globaler Broadcastkommunikation. BD2 ver-wendet hingegen nur Multicastnachrichten und eine logischeBaumstruktur, die sich besser fur WMN eignet. TBKA hateine logische Linienstruktur, die sich in mehreren kleinerenRunden gut an ein WMN anpassen kann.

Abbildung 1 zeigt die Effizienz der drei Gruppen-schlusselaustauschverfahren in Wireless Mesh Netzwerken furTeilnehmerzahlen von funf bis 100 mit einem Interferenz-Faktor von x = 4, 45. Dieser Interferenz-Faktor ergibt sichaus einer Simulation der Protokolle in einem fur diesen Zweckentwickelten Simulator, ist jedoch fur jedes Wireless MeshNetzwerk (zumindest leicht) unterschiedlich.

Abbildung 1. Effizienz von Gruppenschlusselaustauschprotokollen in WMNmit dem Interferenz-Faktor x = 4, 45 in Timeslots (TS)

Es zeigt sich, dass sich das Tree Based Key AgreementProtokoll fur große Teilnehmerzahlen empfiehlt. Dies wirddurch die variable Struktur und viele kleine Protokollrunden,anstatt zwei großen wie bei den anderen Protokollen, erreicht.Bis zu einem Wert von ca. 15 Teilnehmern ist jedoch dasBurmester-Desmedt II Protokoll am effizientesten. Burmester-Desmedt I ist aufgrund seiner nicht besonders gut geeignetenlogischen Struktur und der teuren Broadcastkommunikationfur alle Netzwerkgroßen weit abgeschlagen.

V. ZUSAMMENFASSUNG UND AUSBLICK

In dieser Ausarbeitung haben wir ein probabilistisches Mo-dell fur die Effizienz Evaluierung von Netzwerkprotokollen inWireless Mesh Netzwerken vorgestellt. Die Ergebnisse dieserEvaluierungen konnen zur Entscheidungsfindung beitragenoder dazu verwendet werden, neue Protokolle in ihrer Effizienzfur WMN zur verbessern. Am Beispiel von drei reprasentativausgewahlten Gruppenschlusselaustauschprotokollen habenwir gezeigt, dass sich das Tree Based Key Agreement Pro-tokoll am besten fur große Mesh Netzwerke eignet.

Offene Punkte sind der praktische Nachweis der Ergebnissein einer Testumgebung, sowie das Evaluieren von und Ver-gleichen mit anderen Modellen fur die Performanzmessungin WMN. Eine ungeloste Aufgabe ist zudem die Entwick-lung eines effizienten (z.B. gruppenschlusselbasierten) undvollstandigen Sicherheitskonzeptes fur Wireless Mesh Netz-werke.

LITERATUR

[1] Mike Burmester and Yvo Desmedt. A secure and efficient conferencekey distribution system. In EUROCRYPT’94, volume 950 (LNCS), pages275–286, 1994.

[2] Mike Burmester and Yvo Desmedt. Efficient and secure conference keydistribution. In Cambridge Workshop on Security Protocols, volume 1189(LNCS), pages 119–129, 1996.

[3] Freifunk Community. Freifunk projekt webseite. http://start.freifunk.net/,2010.

[4] Tilman Frosch. Charakteristik von wireless mesh-netzwerken. Bachelor-thesis, Ruhr-Universitat Bochum, 2009.

[5] Yongdae Kim, Adrian Perrig, and Gene Tsudik. Tree-based group keyagreement. Cryptology ePrint Archive, Report 2002/009, 2002. http://eprint.iacr.org/.

[6] Marco Knodler. Praktische evalulation der einsatzfahigkeit eines draht-losen mesh-netzwerkes im industriellen umfeld. Diplomathesis, Ruhr-Universitat Bochum, 2009.

[7] Andreas Noack and Jorg Schwenk. Group key agreement for wirelessmesh networks. In 34th IEEE LCN & Workshops Conference Proceedings,pages 945–952, 2009.

[8] J. Schwenk, T. Martin, and R Schaffelhofer. Tree-based multicast keyagreement. In Communications and Multimedia Security 01, 2001.

Testbed Evaluation eines Black Hole-Angriffes auf ein Ad hoc Netz Christian Gottron, Pedro Larbig, André König, Matthias Hollick, Ralf Steinmetz

[Christian.Gottron;Pedro.Larbig;Andre.Koenig; Ralf.Steinmetz]@KOM.TU-Darmstadt.de Multimedia Kommunikation (KOM), Technische Universität Darmstadt

Matthias.Hollick@SEEMOO.TU-Darmstadt.de Secure Mobile Networking Lab (SEEMOO), Technische Universität Darmstadt

Mobile Ad hoc Netze (MANET) wurden in den letzten Jahren vielfach auf Robustheit und Sicherheit untersucht. Exsistieren-de Arbeiten evaluierten Angriffe und Gegenmaßnahmen primär theoretisch oder analytisch. Im Rahmen dieser Arbeit wird der Aufbau eines Testbeds am Institut für Multimedia Kommunikation an der TU-Darmstadt vorgestellt. Dabei entstandene Herausforderungen und Lösungsansätze werden herausgearbeitet. Innerhalb dieses Testbeds wird der Black Hole-Angriff analysiert. Die Ergebnisse dieser Arbeit zeigen, dass das AODV Protokoll mit Hilfe eines Filters stabilisiert werden kann, der Verbindungen verhindert, die nicht eine minimale Signalqualität aufweisen. Weiterhin zeigte sich, dass der Black Hole-Angriffe in einem Testbed einen starken Einfluss auf die Verfügbarkeit von Routen innerhalb des Netzes hat.

I. Motivation und Ziele In Katastrophenschutze Szenarien oder in der Car-to-Car-Kommunikation kann nicht von einer verfügbaren Infrastruk-tur ausgegangen werden. Aufgrund dessen können traditio-nelle Architekturen oft nicht angewandt werden. Da Mobile Ad hoc Netze (MANET) aufgrund ihrer dezentralen Eigen-schaft ohne Infrastruktur operieren, bieten sich diese als Er-satz der traditionellen Architekturen in einem solchen Szena-rio an. Es existieren diverse wissenschaftliche Arbeiten die sich mit MANETs befassen. Diese basieren meist auf theoretischen Modellen oder Simulationen. Dabei werden aufgrund der Komplexität Eigenschaften realer drahtloser Netze abstra-hiert was zu Abweichungen zwischen theoretischen und rea-len Ergebnissen führen kann [1]. Bisher wurden nur wenige Aspekte der MANETs aus praktischer Sicht betrachtet. Vor allem im Gebiet der Netzwerksicherheit existieren nur weni-ge Testbed-basierte Analysen von Angriffen und Gegenmaß-nahmen. Um solche Angriffsszenarien zu analysieren, wurde ein MANET Testbed aufgebaut. In dieser Arbeit wird die Aus-wirkung des Black Hole-Angriffs betrachtet. Das Ziel dieses Angriffs auf den Routing Algorithmus des Netzes ist es, möglichst viele Routen über einen bösartigen Knoten zu lei-ten. Daraufhin können die an den Angreifer gesendeten Da-ten verworfen oder untersucht und gespeichert werden, um das Netz zu stören bzw. Daten über die anderen Teilnehmer des Netzes zu sammeln.

II. Aufbau des Testbeds Das Testbed besteht aus 7 Lenovo Notebooks der R61 bzw. R61i Serie auf denen eine Ubuntu Distribution der Version 9.04 als Betriebssystem läuft. Das Ad hoc on demand Di-stance Vector (AODV) [2] Protokoll wurde für das Routing eingesetzt. Dieses reaktive Protokoll bietet sich aufgrund seiner weiten Verbreitung und Bekanntheit in wissenschaftli-chen Kreisen für erste Versuche in einem Testbed an, da vie-le theoretische Arbeiten als Referenz existieren. Es wird die AODV-UU [3] Implementierung verwendet, welche an der Uppsala Universität in Schweden entwickelt wurde. Diese ist für Netzwerke basierend auf dem IEEE 802.11 Standard ent-wickelt worden und wurde strikt nach dem AODV RFC imp-lementiert. Aufgrund einer Inkompatibilität zu dem neuen im Testbed verwendeten Linux Kernel 2.6.28, musste AODV-UU angepasst werden. Dadurch wurde allerdings die Funk-tionalität des Protokolls weder verändert noch eingeschränkt. Die Notebooks wurden innerhalb des Instituts für Multimedia Kommunikation an der TU-Darmstadt über mehrere Büro-räume verteilt und blieben dort stationär während der Versu-che. In Abbildung 1 ist die Aufteilung der Notebooks auf die einzelnen Räume dargestellt. Weiterhin sind alle Verbindun-

gen mit einer Qualität von über -70 dbm zwischen den ein-zelnen Teilnehmern des Netzes als Linien dargestellt. Diese Signalqualität hat sich in Vortests als zuverlässig erwiesen.

III. Evaluation des AODV Protokolls Die ersten Versuche bezüglich der Funktionalität der AODV Implementierung zeigten Verbindungsabbrüche in einem gesteigertem Maße bei Multi-Hop-Strecken. Diese wurden durch Gray Zones [1] hervorgeru-fen. Gray Zones entstehen durch die unterschiedliche Reichweite von Broadcast und Unicast Nach-richten. Während Broadcast Nach-richten mit niedrigerer Übertra-gungsrate gesendet werden und dementsprechend eine hohe Reichweite haben, werden Unicast Nachrichten mit maximaler Über-tragungsrate gesendet. Dies resul-tiert in einer niedrigeren Reichwei-te der Unicast Nachrichten in der die gesendeten Daten noch von einem Empfänger korrekt deko-diert werden können. Da die Rou-ting Nachrichten des AODV Pro-tokolls als Broadcast Nachrichten gesendet werden, haben sie eine höhere Reichweite als Datenpake-te, die über die etablierte Route per Unicast Nachricht gesendet werden. Dadurch werden Verbin-dungen zwischen Knoten aufge-baut und für Routen ausgewählt, über die Daten nicht zuver-lässig übertragen werden können. Weiterhin verwendet das Protokoll eine Metrik, die die kürzeste Routen (bezüglich der Anzahl der Hops) bevorzugt. Daraus ergibt sich, dass bei der Wahl des nächsten Knotens auf der Route jene Knoten be-vorzugt werden, die möglichst weit vom aktuellen Knoten entfernt liegen. Aufgrund dessen ist die Wahrscheinlichkeit, dass Knoten sich in der Gray Zone, also der Grenzzone zwi-schen der Reichweite der Broadcast und der Unicast Nach-richten, befinden hoch. Um die Gray Zone-Problematik zu vermeiden, schlagen Lundgren et al. [4] neben diversen anderen Ansätzen vor, die minimale akzeptierte Verbindungsqualität zwischen den Knoten durch einen Filter zu begrenzen. Dieser soll direkt in AODV implementiert werden. Als Folge dessen werden alle Pakete verworfen, die mit einer Signalqualität empfangen werden, die einen festgelegten Wert unterschreiten. Auf-grund des von Lundgren et al. verwendeten 802.11 Treibers konnten nach ihrer eigenen Aussage keine genauen Werte für die Signalqualität ermittelt werden. In unserem Testbed wur-de ebenfalls ein Filter verwendet der jedoch auf die genaue

1

2

4

3

5

6

7

B

A

Abb.1: Aufbau des Testbeds und Verteilung der Knoten

Tab.2: Erfolgreiche Datenübertragung zwi-schen Knotenpaaren in Szenario B

Tab.1: Erfolgreiche Datenübertragung zwischen Knotenpaaren in Szenario A

Signalqualität zurückgreifen kann. Dieser Filter wurde nicht direkt in AODV implementiert, sondern in Form eines MAC-Filters als separates Programm eingesetzt. Dieses kann unab-hängig von dem verwendeten Routing Protokoll eingesetzt werden. Mit Hilfe einer Erweiterung des aktuellen Linux Kernels, kann die Verbindungsqualität wesentlich genauer und zuverlässiger ermittelt werden. Weiterhin ist in dem hier beschriebenen Ansatz die Qualität als Durchschnittswert der n zuletzt empfangenen Nachrichten definiert. Dadurch wer-den starke Schwankungen vernachlässigt und die Routen im Allgemeinen stabiler. Aus einem direkten Vergleich eines MANETs mit und ohne Filter ging hervor, dass Multi-Hop-Routen, die ohne Filter aufgebaut wurden, wesentlich instabiler sind als jene, die mit Hilfe des Filters ermittelt wurden. Selbst Verbindungen die lediglich über einen einzelnen zwischenliegenden Knoten geroutet werden weisen Verluste von über 50% der gesende-ten Pakete auf. Wenn im gleichen Szenario ein Filter einge-setzt wird, können die Verluste auf etwa 5% reduziert wer-den. Passt man den Filter gezielt an das Szenario an, so redu-zieren sich die Verluste auf etwa 2%. Weiterhin entstehen durch den filterlosen Einsatz von AODV Latenzen die um den Faktor zehn höher sind im Vergleich zu einem Szenario mit Filter.

IV. Evaluation des Black Hole-Angriffs Fehlverhaltende Knoten die einen Black Hole-Angriff durch-führen, leiten möglichst viel Datenverkehr über sich. Diesen können sie dann verwerfen oder umleiten um somit das Netz zu stören. Um diesen Angriff möglichst erfolgreich zu imp-lementieren, antworten bösartige Knoten auf alle Anfragen nach Routen und geben an, eine gültige Route mit minimaler Distanz zum Zielknoten in ihrer Routingtabelle gespeichert zu haben. Sollte der anfragende Knoten näher am Zielknoten liegen als am Angreifer, so bleibt der Angriff ohne Folgen. Andernfalls wird der anfragende Knoten die vermeintlich optimale Route über den Angreifer für den Datenaustausch verwenden. Da die Effizienz dieses Angriffs stark von der Position des Angreifers innerhalb des Netzes abhängig ist, werden im Folgenden zwei Szenarien präsentiert. In Szenario A ist der Angreifer am Rand des Netzes positioniert, während in Sze-nario B der Angreifer an eine für den Angriff optimierte Po-sition innerhalb des Netzes platziert wurde. Hier ist anzu-nehmen, dass der zweite Angriff einen erkennbar größeren Einfluss auf das Netz hat. Die Position der Angreifer in bei-den Szenarien und die Anbindung an das MANETs sind in Abbildung 1 dargestellt. In beiden Szenarien werden die Verbindungen zwischen den Knoten des Netzes paarweise per Ping überprüft. Hierbei baut AODV-UU sowohl eine Hin- als auch eine Rückroute zwischen dem Knotenpaar auf. Da in einem realen Netz uni-direktionale Verbindungen aufgrund der variierenden Über-tragungsreichweiten der einzelnen Knoten entstehen können, muss auf eine solche Maßnahme zurückgegriffen werden. Daraus folgt allerdings, dass Routen nur dann erfolgreich aufgebaut werden können, wenn die Distanz zwischen beiden Knoten niedriger ist als die Distanz zwischen einem der bei-den Knoten und dem Angreifer. Dadurch erhaltenen wir sym-metrische Ergebnisse wie sie in Tabelle 1 und 2 zu sehen sind. Diese Tabellen zeigen die Wahrscheinlichkeit, das Kno-ten X eine Antwort auf ein Ping erhält, das er an Knoten Y gesendet hat (X, Y Є M, M={1, 2, 3, 4, 5, 6, 7}). Weiterhin wurden Routen, die durch den Black Hole-Angriff betroffen sind, zur Verdeutlichung grau hinterlegt. Das Ergebnis des Experiments in Szenario A zeigt, dass selbst ein Angreifer, der sich am Rande des Netzes befindet, dieses sehr stark beeinflussen kann. Wie in Tabelle 1 zu se-

hen ist, werden mehr als 50% aller Verbindungen gestört (graue hinterlegt). Im Fall der Verbindungen zwischen Kno-ten 2 und 5 bzw. 4 und 5 liegen Quell- und Zielknoten genau soweit von einander entfernt wie deren Entfernung zu dem Angreifer ist. Auf-grund dessen kann mit einer gewissen Wahrscheinlichkeit das Routing erfolg-reich beendet wer-den. In diesen Fäl-len erhält der an-fragende Knoten die Routing Nach-richt des legitimen Knotens vor der Nachricht des Angreifers. Da der Angreifer allerdings vor-gibt, dass seine Route aktueller ist, verwirft das AODV Pro-tokoll die korrekte Route zugunsten der vermeintlich gleich-langen und aktuelleren Route über den Angreifer. Dies er-laubt jedoch zumindest eine kurzfristige korrekte Datenüber-tragung. Weiterhin kommt es nach einer gewissen Zeit, in der der sendende Knoten keine Antwort erhält zu einem Timeout und einer erneuten Routenfindung. Hier kann es folglich wieder zu einem kurzzeitigen Datenaustausch kommen, be-vor der Angriff die Datenübertragung erneut stört. Im zweiten Szenario liegen die Verlustraten höher, da hier aufgrund der zentralen Lage des Angreifers lediglich Routen zu direkten Nachbarn aufgebaut werden können. Entspre-chend liegen die Verluste bei über 60% wie es der Tabelle 2 zu entnehmen ist (grau hinterlegt). Hierbei ist anzumer-ken, dass die Routen in Szenario B kom-plett gestört wurden und keinerlei Daten-transfer auf den be-einträchtigten Routen mehr übertragen werden konnte. Di-rekte Verbindungen zwischen Nachbarn können von Black Hole-Angriffen nicht unterbrochen werden, da für diese kein Multi-Hop-Routing Anfragen benötigt werden.

V. Zusammenfassung Im Laufe dieser Arbeit konnte ein Testbed aufgebaut werden, welches mit Hilfe der Optimierung des AODV Protokolls stabil lief. Weiterhin konnte festgestellt werden, dass Black Hole-Angriffe selbst in kleineren Netzen einen sehr großen Einfluss auf die Verfügbarkeit der Netzwerkknoten haben. So können Daten nur noch dann korrekt übertragen werden wenn (I) die Distanz zwischen den kommunizierenden Kno-ten kleiner ist als die Entfernung der Knoten zum Angreifer oder wenn (II) direkte Nachbarn miteinander kommunizie-ren.

VI. Literaturverzeichnis [1] H. Lundgren et al. : The Gray Zone Problem in IEEE 802.11b

based Ad hoc Networks; ACM SIGMOBILE 2002 [2] C. Perkins et al.: RFC 3561 Ad hoc On-Demand Distance Vec-

tor (AODV) Routing [3] E. Nordström: AODV-UU – CoReSoftware; Uppsala Univer-

sity, University Basel, http://core.it.uu.se/core/index.php /AODV-UU

[4] H. Lundgren et al.: Coping with Communication Gray Zones in IEEE802.11b based Ad hoc Networks; In proc. of the 5th ACM intern. WoWMoM’02

1 2 3 4 5 6 7

1 100% 0% 100% 0% 0% 0%

2 100% 100% 100% 14% 0% 0%

3 0% 100% 100% 100% 100% 0%

4 100% 100% 100% 13% 0% 0%

5 0% 15% 100% 16% 100% 100%

6 0% 0% 100% 0% 100% 100%

7 0% 0% 0% 0% 100% 100%

1 2 3 4 5 6 7

1 100% 0% 100% 0% 0% 0%

2 100% 100% 100% 0% 0% 0%

3 0% 100% 100% 100% 0% 0%

4 100% 100% 100% 0% 0% 0%

5 0% 0% 100% 0% 100% 0%

6 0% 0% 0% 0% 100% 100%

7 0% 0% 0% 0% 0% 100%

Wireless LAN und die Sicherheitsfrage untertage

Dipl. Ing. Christoph MüllerMineTronics GmbH, Germany

Andreas Noack, M.Sc.MineTronics GmbH, Germany

EinleitungWireless LAN findet mehr und mehr Bedeutung in der Industrie. Durch große Fortschritte in der Automatisierungstechnik, erreicht die Verbreitung sogar Anwendungen, die klassischerweise nichts mit der neuen Funktechnologie zu tun hatten.

Die MineTronics GmbH beschäftigt sich mit der IP-basierten Automatisierung und Vernetzung in untertägigen Industrieumgebungen. Seit einigen Jahren gehören IEEE 802.11 kompatible WLANs auch mehrere hundert Meter unter der Erde zur Standardausrüstung. Mittlerweile gibt es in einigen Bergwerken sogar Wireless LAN Infrastrukturen, die Tunnel mit einer Länge von vielen Kilometern abdecken.

Selbstverständlich ist die Frage der Netzwerk- und Datensicherheit untertage eine andere als im Internet oder für Wireless LAN Hotspots an öffentlichen Plätzen, denn die Tunnel sind nicht für jeden erreichbar und die Besuche von externen Personen werden protokolliert. Dennoch gibt es auch hier großen Bedarf an Sicherheitslösungen, da die Beurteilung ob ein Objekt sicherheitstechnisch schützenswert ist nicht nur von der Menge der potentiellen Angreifer abhängt, sondern auch von der Wertigkeit des Objekts. Beispielsweise kann ein (wenn auch unwahrscheinlicher) Hacker-Angriff auf eine große ferngesteuerte Mobilmaschine in einem für Personen freigegebenen Bereich zu schweren Personenschäden führen.

Sicherheitsanforderungen untertageIn Industrieanwendungen, besonders untertage, bekommen die Sicherheitsziele Vertraulichkeit, Authentizität und Verfügbarkeit andere Prioritäten als z.B. im Internet. Die Vertraulichkeit spielt aufgrund von einer nur eingeschränkten Zulassung von externen Personen eine untergeordnete Rolle.

Wichtiger ist die Authentizität der Nachrichten, besonders wenn es um hohe Wertigkeiten geht. Wird eine teure Maschine ferngesteuert, kann durch eine unabsichtliche oder vorsätzliche Fehlbedienung ein großer Schaden entstehen. Das steuernde System und der steuernde Nutzer müssen authentifiziert und authorisiert werden, um derartige Risiken zu minimieren.

Letztendlich spielt die Verfügbarkeit der Systeme eine große Rolle, die vor allem wirtschaftlich ausgeprägt ist. Ein temporärer Ausfall kann immensen wirtschaftlichen Schaden nach sich ziehen, in besonderen Fällen auch personellen (z.B. wenn die Verbindung zu einer ferngesteuerten mobilen Maschine durch Netzwerküberlast verzögert wird und ein Befehl die Maschine zu spät erreicht). Quality-of-Service und Hochverfügbarkeitsanwendungen haben hier eine große Bedeutung.

Ein BeispielszenarioEine führerlose Einschienenhängebahn (EHB) oder ein Zug zum Transport von Gütern untertage soll automatisiert werden. Die Bahn fährt durch einen Tunnel, der auch Personen zugänglich ist. Entlang des Tunnels werden IEEE 802.11b/g kompatible Accesspoints für den Untertageeinsatz verwendet, um eine nahezu lückenlose Funkinfrastruktur zu gewährleisten.

Da die EHB ferngesteuert werden soll, muss ein System implementiert werden, das die durch Roaming innerhalb des Tunnels entstehenden Latenzen und Verbindungsausfälle auf ein Mindestmaß minimiert. Aus diesem Grund werden die folgenden Überlegungen angestellt:

1.) Die Roamingzeiten normaler WiFi-Adapter (Verbindungsabbruch für mehrere Sekunden) muss stark minimiert werden.

2.) Jeweils vorne und hinten an der EHB wird ein WiFi-Adapter montiert, wobei beide Adapter die Steuerungsinformationen voll redundant kommunizieren.

3.) Der Einsatz von WPA ist zu riskant, da nach dem Roaming zu einem neuen Accesspoint mindestens ein 4-Wege-Handshake zur Schlüsselvereinbarung notwendig ist. Ein VPN-Endpunkt auf der EHB und an der Steuerkonsole ermöglichen auch im Roamingfall eine fortlaufende Verschlüsselung.

Weiterhin werden Überlegungen zur Systemsicherheit angstellt. Beispielsweise verhindert eine Firewall unerlaubten Zugriff auf die Steuerungstechnik der EHB.

Anhand dieses Beispiels werden die besonderen Anforderungen an die Kommunikation und Sicherheit in der Bergbauindustrie dargestellt. Ein ähnliches Pilotprojekt wurde 2005-2007 auf einem Bergwerk in Deutschland realisiert.

1 9 . M ä r z 2 0 1 0 Thema: Sicherheit von (Funk-) Stand ard s in d er H aus automatis ation I nhal t D i e H a u s a u t o m a t i s a t i o n f i n d e t l a n g s a m a b e r s i c h e r d e n W e g i n v i e l e H e i m e . Ei n i g e B e i s p i e l e f i n d e n s i c h i n d e r b r e i t e n V e r m a r k t u n g v o n W ä r m e m e n g e n z ä h l e r , F u n k s t e c k d o s e n , W e t t e r s t a t i o n e n , A l a r m a n l a g e n , F u n k -G a r a g e n t o r a n t r i e b e o d e r F u n k g a s m e l d e r . S i e a l l e h a b e n g e m e i n s a m , d a s s s i e e n t w e d e r D a t e n v o n e i n e m T r a n s p o n d e r e m p f a n g e n o d e r D a t e n a n e i n e n R e c e i v e r ü b e r m i t t e l n . S o f e r n d i e s e D a t e n a u c h K o m m a n d o s z u r S t e u e r u n g d e r Ei n h e i t e n a u s t a u s c h e n , b e s t e h t d a s R i s i k o , d a s s m i t H i l f e v o n g e z i e l t e n A n g r i f f e n a u f b e k a n n t e D e s i g n - o d e r I m p l e m e n t i e r u n g s s c h w a c h s t e l l e n , d i e G e r ä t e k o m p r o m i t t i e r t w e r d e n k ö n n e n . D a h e r w u r d e n e i n i g e b e k a n n t e n P r o d u k t e u n d d i e ö f f e n t l i c h v e r f ü g b a r e n P r o t o k o l l s p e z i f i k a t i o n e n a u f S i c h e r h e i t u n t e r s u c h t . I n d e m V o r t r a g w e r d e n d i e F u n k t s t a n d a r d s f ü r d e n H e i m b e r e i c h i m F r e q u e n z b e r e i c h 4 3 3 M H Z , 8 9 8 M H Z ( EU ) u n d 9 1 5 M H Z ( U S A ) k u r z v o r g e s t e l l t . A u f B a s i s d i e s e r G r u n d l a g e n w u r d e n d i v e r s e P r o t o k o l l e u n d h e r s t e l l e r s p e z i f i s c h e n L ö s u n g e n k o n z i p i e r t . Es s o l l e n h i e r b e i d i e S i c h e r h e i t s m e r k m a l e d i e s e r P r o t o k o l l e a n h a n d e i n i g e r I m p l e m e n t i e r u n g e n , z . B . F S 2 0 , K a K u u n d X 1 0 , v o r g e s t e l l t w e r d e n . D e s W e i t e r e n w u r d e n a u c h g r u n d s ä t z l i c h e R i s i k e n ( z . B . R e p l a y-A t t a c k e n ) b e t r a c h t e t , d i e A n g r i f f e a u f n i c h t -ö f f e n t l i c h e P r o t o k o l l e o d e r S t a n d a r d s b e s c h r e i b e n . M ö g l i c h e A n g r i f f s s z e n a r i e n s o l l e n a n B e i s p i e l e n v o n F u n k m o d u l e n ( w i e z . B . F u n k s t e c k d o s e n o d e r H a n d s e n d e r n v o n A l a r m a n l a g e n ) p r ä s e n t i e r t w e r d e n . D i e G r u n d l a g e f ü r d i e p r a k t i s c h e D u r c h f ü h r u n g d e r T e s t s z e n a r i e n u n d A n g r i f f e b i l d e t e i n G e r ä t a u f B a s i s e i n e s A t m e l A T m e g a 3 2 8 -C h i p s ( A r d u i n o ä h n l i c h e s M o d u l ) m i t z u s ä t z l i c h e n Er w e i t e r u n g e n ( h i e r T r a n s p o n d e r u n d T r a n s c e i v e r ). H i e r d u r c h i s t d a s G e r ä t i n d e r L a g e u n t e r s c h i e d l i c h m o d u l i e r t e D a t e n s t r ö m e a u f B a s i s v o n O O K u n d F S K z u e m p f a n g e n o d e r z u s e n d e n . I m p l e m e n t i e r u n g e n v o n B e i s p i e l p r o g r a m m e n s o l l e n d i e A n f ä l l i g k e i t e n f ü r B r u t e -F o r c e -A n g r i f f e , S n i f f i n g u n d R e p l a y-A t t a c k e n p r a k t i s c h d e m o n s t r i e r e n . I n e i n e m k u r z e n Ex k u r s w e r d e n d i e R i s i k e n a u c h a u f a l t e r n a t i v e Ü b e r t r a g u n g s m e d i e n ( h i e r X 1 0 -P o w e r l i n e -T e c h n o l o g i e i m H a u s s t r o m n e t z ) e v a l u i e r t . R ef erent N a m e : K o s a n o v i c V o r n a m e : V o j i s l a v A k a d e m i s c h e r T i t e l : D i p l o m B e t r i e b s w i r t Z u s a t z q u a l i f i k a t i o n : C I S A , I S O / I EC 2 7 0 0 1 L e a d A u d i t o r , 2 7 0 0 1 L e a d A u d i t o r a u f B a s i s v o n I T -G r u n d s c h u t z U n t e r n e h m e n ( i n k l . R e c h t s f o r m ): K P M G D T G A G P o s t a n s c h r i f t d e s U n t e r n e h m e n s : A l f r e d s t r a s s e 2 7 7 , 4 5 1 3 3 Es s e n T e l e f o n : ( 0 2 0 1 ) 4 5 5 -8 9 3 3 F a x : ( 0 2 0 1 ) 4 5 5 -6 8 7 5 H a n d y: ( 0 1 7 4 ) 3 4 4 6 6 4 6 E-M a i l : v k o s a n o v i c @ k p m g . c o m

Laufbahn in Kurzform V o j i s l a v K o s a n o v i c v e r f ü g t ü b e r s i e b e n J a h r e B e r u f s e r f a h r u n g i m I T -U m f e l d u n d v e r t r i t t i n n e r h a l b d e r K P M G d i e S c h w e r p u n k t e A p p l i k a t i o n s s i c h e r h e i t , T e l e k o m m u n i k a t i o n u n d m o b i l e S i c h e r h e i t . H a u p t b e r u f l i c h i s t H e r r K o s a n o v i c s e i t 2 0 0 2 i m B e r e i c h I T A d v i s o r y m i t F o k u s a u f I T -S i c h e r h e i t b e i K P M G t ä t i g . V o r s e i n e m E i n t r i t t b e i d e r K P M G w a r V o j i s l a v K o s a n o v i c i m C a l l c e n t e r d e r C o m m e r z b a n k i n d e n B e r e i c h e n T K -A n l a g e n , C T I u n d I V R t ä t i g .

Security in Smart Grid Environments – Improving IEC 62351

Steffen Fries Siemens AG

Corporate Technology Germany

steffen.fries@siemens.com

Abstract— Information security has gained tremen-

dous importance for energy distribution and energy

automation systems over the last years. Standards like

IEC61850 offer communication services and data mod-

els for communication in energy automation. IEC 61850

is flanked by the standard IEC 62351 that especially

addresses security and specifies technical requirements,

which have to be met by vendors. Especially, vendors

that cover the entire energy automation chain with their

product portfolio face new demanding challenges im-

posed by new use cases that come with the rise of the

Smart Grid. This contribution depicts the current state

of the standardization of IEC 62351, gives an overview

of current and new use cases, which are not completely

covered, and discusses potential enhancements of the

standard to address new use cases. The enhancements

allow multiple parallel distinguishable sessions based on

MMS and proper authentication as well as authoriza-

tion.

Keywords – Smart Grid, Security, Energy

Automation

I. INTRODUCTION

Decentralized energy generation (e.g., solar cells) is getting more momentum to fight global warming and to cope with the increasing local demand of energy. Building a Smart Energy Grid, by introduc-ing decentralized energy generators into the current distribution network poses great challenges for the energy transmission, distribution, and control net-works from the physical as well as from the commu-nication side. Security is a basic requirement for such applications to ensure a safe and reliable operation of the energy grid.

IEC 61850 is a popular standard for communica-tion in the domain of energy automation. It is as-sumed to be the successor of the currently used stan-dards IEC 60870-4-104 and DNP3 also for the North American region. IEC 61850 addresses the data ex-change on process level, field level, and station level and defines abstract communication services that are mapped on existing protocols (e.g., MMS1, Web

1 Manufacturing Message Specification

Services, TCP/IP, and Ethernet). Security is ad-dressed in an associated standard IEC 62351.

Today, IEC 61850 is mainly used for reporting status and sampled value information from Intelligent Electronic Devices (IED) to Substation automation controller as well as for command transport from Substation automation controller to IEDs. It also addresses the communication directly between IEDs using the Ethernet instead of dedicated wires.

In the near future it is expected that the related use cases will be widened in scope. Smart Home scenar-ios in combination with the Smart Grid will allow people to understand how their household uses en-ergy, manage energy use better, and reduce their carbon footprint. It will also allow customers to feed energy back into the smart grid and to participate on energy market places.

This requires better control of the energy grid to ensure the safe transportation and distribution of available energy within the physical energy network. Especially fast load changes or changes in the energy provisioning through decentralized resources need to be managed to ensure a consistent high quality en-ergy supply.

New scenarios will influence the current energy automation architecture in terms of a additional com-ponents introduced, like smart meters or energy gate-ways, which connect households directly to the smart grid. This poses new requirements to security like the provisioning of appropriate credentials to end cus-tomers to enable secured communication as well as authorization of energy providers to invoke certain actions at the household site. Furthermore, it is also expected roles leading to new participating parties in the communication architecture will be introduced, which most likely will lead to new or changed trust relations. An example is a gateway service provider in Smart Grid scenarios, which concentrate the con-nections of a high number of smart home energy gateways.

II. SECURE ENERGY AUTOMATION BASED ON IEC62351

In contrast to office networks, automation net-works have different requirements to security ser-vices as shown in the following figure.

Confidentiality (Data)

Integrity (Data)

Availability / Reliability

Non-Repudiation

High

Medium

Medium

Medium

Low – Medium

High

High

High

Office EA-Network

Component Lifetime Short - medium Long

Figure 1: Comparison Office/Automation security

For these security services IEC 62351 defines in currently 7 parts explicit measures for TCP based and serial protocols used directly in substation auto-mation deploying IEC 61850 and IEC 60870-x pro-tocols as well as in adjacent communication proto-cols supporting energy automation, like ICCP (TASE.2) used for control center communication. A clear goal of the standardization of IEC62351 is the assurance of end-to-end security.

For TCP based communication this is achieved by relying on TLS and on integrity protection based on keyed hashes or digital signatures for serial links, Ethernet links or application layer connections.

Nevertheless, there is a gap between the security services defined on network layer and the ones de-fined on application layer, when considering espe-cially the new scenarios addressed by smart grid use cases.

III. MISSING PIECES IN IEC62351

Part 4 of IEC 612351 specifies procedures, proto-col enhancements, and algorithms targeting the secu-rity of applications utilizing the MMS. MMS is an international standard (ISO 9506) defining a messag-ing system for transferring real time process data and supervisory control information either between net-worked devices or in communication with computer applications.

The security in Part 4 is defined as two profiles targeting transport security as T-Profile on one hand and application security as A-Profile. The T-Profile describes the protection of information, which is exchanged over TCP using TLS. The A-Profile de-fines security services on application layer, targeting mainly authentication. The authentication itself is

performed only during connection establishment on application layer using the MMS initiate command. Moreover this authentication does not provide appli-cation layer message integrity and is also not used to form a session. A session in this context crypto-graphically binds the authentication performed dur-ing the connection setup with the subsequent mes-sages exchanged between the communicating peers. Thus, in the current stage of the standard messages on application layer are not protected regarding their integrity. To achieve integrity protection, the applica-tion of the T-Profile is being referred.

Combining A-Profile and T-Profile provides a connection allowing for authentication, integrity protection and confidentiality. This approach works fine in scenarios, where the transport connection spans the same entities as the application connections and may be sufficient for many energy automation scenarios. But it may not cope with all use cases in the smart grid. As soon as there is a difference in transport connection endpoints and application con-nection endpoints, security problems may arise.

An example scenario is given through proxy com-bining different connections or to multicast a single command to several other connections. Here, the T-Profile is terminated by the proxy, while the applica-tion connection may be established end-to-end. Hence, no end-to-end application level integrity is provided. Such a scenario is called a multi-hop con-nection from a transport level view and would re-quire that the proxy is a trusted intermediate host, which cannot be guaranteed in many scenarios.

The presentation depicts smart grid use cases in which the shortcomings of IEC 62351 are evident and suggests potential enhancements of the standard based on existing approaches from multimedia re-lated standards.

REFERENCES [1] RFC 5246: The Transport Layer Security (TLS) Protocol,

Version 1.2, T. Dierks, E Rescorla, August 2008 [2] ISO-IEC 61850, Part 8-1: Specific Communication Service

Mapping (SCSM) – Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3, May 2004

[3] ISO-IEC 62351, Part 4: Communication Network and System Security – Profiles Including MMS, October 2006

[4] ISO-IEC 62351, Part 5: Security for IEC 60870 and De-rivatives, February 2007

[5] ISO-IEC 62351, Part 6: Security for IEC 61850, October 2006

IRON - Intelligent Reaction on Network Events

Ingo Bente Jorg Vieweg Josef von Helden

Fachhochschule HannoverRicklinger Stadtweg 120, 30459 Hannover

{ingo.bente, joerg.vieweg, josef.vonhelden}@fh-hannover.de

1 Einleitung

Korrekt funktionierende IT-Infrastrukturen sindheutzutage sowohl im privaten als auch im berufli-chen Umfeld oft unerlasslich. Gleichzeitig wird dieBedrohungslage fur solche Infrastrukturen immer kri-tischer. Neben der durch mobile Endgerate verur-sachten dynamischen Struktur heutiger Netze istauch die steigende Professionalitat der Hacker furdie verscharfte Sicherheitslage verantwortlich. Wirt-schaftsspionage wird immer mehr zu einem rentablenSpezialgebiet der so genannten Underground Econo-my1, und damit auch zu einer Gefahr fur deutscheUnternehmen. Der verursachte Schaden lasst sich da-bei nur schwer beziffern. Schatzungen zufolge sollenallerdings alleine von chinesischen Hackern pro JahrDaten im Wert von 40-50 Milliarden US-Dollar ausUS-Unternehmen gestohlen werden2.

Um moderne IT-Infrastrukturen vor den aktuel-len Bedrohungen zu schutzen, haben sich verschiede-ne, technische Sicherheitsmechanismen etabliert: Fire-walls, Virtual Private Networks, Network Access Con-trol Ansatze sowie Intrusion Detection und PreventionSysteme sind einige davon. Obwohl diese Komponen-ten das Sicherheitsniveau aktueller IT-Infrastrukturensignifikant erhohen und mittlerweile zum De-Facto-Standard geworden sind, resultiert aus ihrer momen-tanen Anwendung ein gravierender Nachteil: Die Si-cherheitskomponenten arbeiten in der Regel isoliertvoneinander. Die verschiedenen Systeme haben je-weils eine eigene Sicht auf den aktuellen Zustandder zu schutzenden IT-Infrastruktur. Der Gesamtzu-stand, welcher sich aus diesen einzelnen Sichten zu-sammensetzt, ist den einzelnen Sicherheitstools aller-dings nicht bekannt, obwohl dieser fur ihre Funktions-weise durchaus relevant sein kann. So konnen Intru-sion Detection Systeme bei Anomalien oft nur dieVerantwortlichen per E-Mail oder Log-Meldung be-nachrichtigen. Wurden andere Systeme wie eine Net-work Access Control Losung oder die Firewall dieSicht des Intrusion Detection Systems ebenfalls ken-nen, konnten automatisch wirksame Reaktionen aufeine erkannte Anomalie eingeleitet werden.

Die isoliert voneinander arbeitenden Sicherheitsme-chanismen sind daher auch ein Grund dafur, dass dieeingangs genannten Angriffe auf IT-Infrastrukturenzur IT-gestutzten Wirtschaftsspionage so erfolgreich

1http://www.gdata.de/uploads/media/Whitepaper_Underground_Economy_9_2009_DE.pdf

2http://online.wsj.com/article/SB125616872684400273.html

sind. Effektive Gegenmaßnahmen sind mit aktuell ein-gesetzten Sicherheitssystemen moglich, konnen aber,wenn eine akute Bedrohung erkannt worden ist, auf-grund mangelnder Integration oft erst zu spat umge-setzt werden.

2 IF-MAP

Um die geforderte Integration realisieren zu konnen,ist eine Technologie erforderlich, durch die die Sich-ten der einzelnen Sicherheitssysteme zu einer Gesamt-sicht aggregiert werden konnen. Kernanforderungensind ein gemeinsames Datenformat sowie eine inter-operable Schnittstelle, mit der die einzelnen SystemeDaten austauschen konnen.

Die Trusted Computing Group hat im Mai 2008mit der IF-MAP-Spezifikation3 eine offene, Hersteller-unabhangige Spezifikation veroffentlicht, die die ge-stellten Anforderungen erfullt, und so als Basis furdie erfolgreiche Integration vorhandener Sicherheits-systeme dienen konnte. Eine Server innerhalb des zuschutzenden Netzwerkes, der so genannte MetadataAccess Point (MAP), ist dafur verantwortlich, denaktuellen Zustand des Netzwerkes abzubilden. DieserZustand wird anhand eines vorgegebenen Formatesfur Metadaten beschrieben und kann (sicherheitsrele-vante) Informationen wie angemeldete Benutzer, ver-wendete IP-Adressen oder erkannte Anomalien ent-halten. Uber eine standardisierte Schnittstelle (IF-MAP) konnen Metadaten von diesem Server abge-fragt oder neue Metadaten veroffentlicht werden. In-nerhalb des MAP Servers werden die veroffentlichtenMetadaten in Form eines Graphen verwaltet. Damitbietet sich die Moglichkeit, an zentraler Stelle eineGesamtsicht auf den aktuellen Status eines Netzwer-kes zu etablieren. Durch Korrelation der vorhandenenMetadaten konnen außerdem sicherheitsrelevante In-formationen abgeleitet werden.

Systeme, die mit dem MAP Server kommunizie-ren, werden als MAP Clients bezeichnet. Die Kommu-nikation basiert auf einem Publish-Search-SubscribeModell, bei dem sowohl synchron als auch asynchronMAP-Daten ausgetauscht werden konnen.

Technologisch setzt IF-MAP auf eine Reihe vonetablierten Standardtechnologien. Als Framework zurUbertragung der Metadaten kommt das SOAP-Protokoll in Kombination mit HTTP(S) zum Einsatz.

3http://www.trustedcomputinggroup.org/resources/tnc_ifmap_binding_for_soap_specification

1

MAP Clients

MetadataAccessPoint

Korrelations-Algorithmen

Metadata

Location Network

Security Topology

Metadaten-Modell

MAP Server

iptables Snort Nagios DHCPOpen Source Tools

Internet

WLAN

TNC@FHH NAC

IF-MAP API

Mobile Endgeräte

Abbildung 1: IRON Architektur einer IF-MAP IT-Infrastruktur.

Das Format der Metadaten ist durch XML-Schematabeschrieben. Auf diese Weise konnen etablierte Sicher-heitssysteme, die um MAP Client Funktionen erwei-tert worden sind, beliebige Metadaten uber den aktu-ellen Status des Netzwerkes austauschen.

3 IRON

In dem Forschungsprojekt Intelligent Reaction OnNetwork Events (IRON)4 der Fachhochschule Hanno-ver wird die Praktikabilitat und die Effektivitat desvorgestellten IF-MAP Ansatzes untersucht. Das Zielist es, eine prototypische Implementierung einer umIF-MAP Funktionen erweiterten IT-Infrastruktur zuentwickeln. Bedrohungsszenarien, in denen IF-MAPeinen Sicherheitsgewinn verspricht, werden analysiertund innerhalb einer Testumgebung simuliert.

Zu den Kernkomponenten, die innerhalb des Pro-jektes entwickelt werden, zahlen ein MAP Server so-wie verschiedene MAP Clients. Die Strategie bei derEntwicklung der MAP Clients ist es, etablierte OpenSource Software um IF-MAP Funktionen zu erwei-tern. Dazu zahlen unter anderem der ISC DHCPD,Snort, Nagios und iptables (vgl. Abbildung 1).

Die zuvor angedeutete, automatische Reaktion aufeine vom Intrustion Detection System erkannte An-omalie konnte beispielsweise wie folgt realisiert wer-den:• Die Firewall und das Network Access Control

System eines Netzwerkes fungieren als MAPClients. Uber die Subscribe-Operation veranlas-sen beide den MAP Server, sie uber Anomalie-Meldungen des Intrusion Detection Systems zuinformieren.

• Das Intrusion Detection System veroffentlicht beieiner erkannten Anomalie relevante Informatio-nen (Art der Anomalie, Quelle, verursachenderBenutzer) per Publish-Operation in dem MAPServer.

• Der MAP Server erkennt die aktiven, passendenSubscriptions der Firewall und des Network Ac-cess Control Systems und informiert diese ent-sprechend.

• Firewall und NAC System konnen nun auf dieAnomalie reagieren, zum Beispiel durch eine An-

4http://trust.inform.fh-hannover.de/joomla/index.php/projects/iron

passung ihrer Konfiguration um verdachtigen,ausgehenden Traffic zu unterbinden oder der Iso-lation des verursachenden Endgerates in einemgeschutzten Segment des Netzwerkes.

Neben der Erhohung der Sicherheit kann IF-MAPaber auch fur Managementaspekte zum Einsatz kom-men. So konnen die im MAP-Server gesammelten In-formationen beispielsweise zum Flottenmanagementverwendet werden (z.B. durch eine Zuordnung vonEndpunkten zu verschiedenen Teilen des Netzwerks).

4 Forschungsbedarf: IF-MAP++

IF-MAP ist eine noch sehr junge Technologie. Sieschafft eine grundlegende Basis, um durch die Korrela-tion von Metadaten und der dadurch moglichen Inte-gration vorhandener Sicherheitstools das Sicherheits-niveau fur aktuelle IT-Infrastrukturen zu erhohen.Um das volle Potential des Ansatzes der Metadaten-Korrelation ausschopfen zu konnen, bedarf es weitererForschungsarbeiten, unter anderem in den folgendenBereichen:• Metadatenvokabularien. Das generische Format

der Metadaten ist zwar vorgegeben (XML- Sche-ma), um reale Szenarien addressieren zu konnen,sind aber darauf zugeschnittene Vokabularienfur Metadaten notwendig (Netzwerk-Sicherheit,Geoinformationen).

• Interdomain MAP. IF-MAP ist momentan aufdie Anwendung innerhalb einer administrativenDomain beschrankt. Eine Kommunikation zwi-schen MAP Servern verschiedener Domanen istnicht vorgesehen.

• Korrelations-Algorithmen. Die IF-MAP Spezifi-kation macht keine Angaben daruber, wie die in-nerhalb des MAP Servers enthaltenen Metadateneffektiv korreliert werden konnen. Da der aufge-baute Metadatengraph, abhangig von den Ein-satzszenarien, sehr komplex werden kann, sinddafur entsprechende Algorithmen zu entwickeln.

5 Zusammenfassung und Ausblick

Die IF-MAP Spezifikation der Trusted ComputingGroup ist ein vielversprechender Ansatz zur Erhohungder Sicherheit aktueller IT-Infrastrukturen. Beson-ders hervorzuheben ist, dass IF-MAP auf vorhande-nen Technologien basiert und explizit das Ziel ver-folgt, durch relativ geringe Modifikationen vorhande-ner Sicherheitsmechanismen ein hohes Maß an Sicher-heit zu generieren.

Vorhandene Software enthalt bislang nur verein-zelt IF-MAP-Funktionalitat. Das Projekt IRON derFHH erweitert Open Source Software um IF-MAP-Funktionalitat und analysiert Effektivitat und Prak-tikabilitat von IF-MAP. Um das volle Potential ei-nes Metadaten-Korrelationsansatzes ausschopfen zukonnen, bedarf es weiterer Forschungsarbeiten in denBereichen Metadatenvokabular, Interdomain MAPund Korrelations-Algorithmen.

2

Eine datenschutzfreundliche, ortsbezogene Groupware furdas iPhone

Julian Dax, Marcel Heupel, Mohamed Bourimi, Dogan KesdoganLehrbereich fur IT-Sicherheit im Institut fur Wirtschaftsinformatik an der Universitat Siegen

dax@fb5.uni-siegen.de

1 Motivation und Problemstellung

Der Bedarf zur Kooperation erfahrt zunehmende Bedeutung in unserer IT-orientierten Weltv.a. in Verbindung mit dem Mobilitatsaspekt. Es werden mobile Gemeinschaften (Com-munities) gebildet in denen Daten und Erfahrungen ausgetauscht werden, im beruflichenals auch im privaten Alltag. Dabei verlieren die Benutzer die Kontrolle uber Ihre privatenDaten mit steigender Tendenz. Ein Beweis fur die Sensibilitat von Datenmissbrauchfol-gerungen sind die Reaktionen auf die periodischen Skandale. Datenschutz wird als dermeist kritische Faktor fur den Erfolg von Kooperation in mobilen Situationen. Der Standder Forschung zeigt, dass eine vollstandige Beseitigung des Datenmissbrauchs unmoglichist, v.a. in kooperativen Situationen, da diese meistens server-seitige Komponenten ein-setzen [BKH+09]. Neuste Studien zeigen, dass Benutzer trotz Anonmysierung mit einerFehlerrate von 12% in sozialen Netzwerken erkannt werden [NS09]. In diesem Beitrag,schildern wir neue Moglichkeiten zur Verbesserung des Datenschutzes besonders in mobi-len kooperativen Situationen. Dabei fuhren wir neue Konzepte und Architekturen ein, dieden Benutzern bessere Kontrolle uber Daten und Interaktion ermoglichen.

2 Anforderungen und Ansatz

Im Rahmen des EU Projektes PICOS (www.picos-project.eu), wurde eine serverzentrischeArchitektur zur Unterstutzung mobiler Communities entwickelt. Dabei wurden Labor- undFeldversuche in Osterreich und Deutschland mit einer reprasentativen Anzahl von Benut-zern durchgefuhrt, mit dem Ergebnis, dass u.A. bei diesen Nutzern der Bedarf nach einerSteigerung des Datenschutzes von personlichen Daten erkennbar war [MB10]. Schwer-punkt dieses Beitrages ist es, Moglichkeiten aufzuzeigen, die Wahrung der Privatsphareder Mitglieder mobiler Gemeinschaften zu steigern, besonders im Hinblick auf ortsbezo-gene Dienste (Location Based Services; LBS) und Awareness (Gruppenbewusstsein) so-wie Kommunikation. Grundlage dieser Arbeit liefert vor allem, die bereits durchgefuhrteprototypische Entwicklung einer iPhone-basierten Anwendung, welche eine aktive Ang-ler Gemeinschaft in verschiedenen kooperativen mobilen LBS-Szenarien unterstutzen soll

[MB10].

Die Anwendung ermoglicht es den Benutzern eine Datenbank von Wasserlaufen (bzw.Gewassern) und Angelplatzen (sog. Spots), innerhalb dieser Gewassern, zu durchstobern.Benutzer konnen auch selbst Gewasser und aggregierte Angelplatze hinzufugen, falls sieam System angemeldet sind. Den Benutzern steht außerdem ein Kommunikationsdienstfur asynchrone als auch synchrone Nachrichten (basierend auf dem Jabber Protocol XMPPund E-Mail sowie Push-Nachrichten). Die Server-Seite der Anwenung besteht aus einemeJabberd- und einem kooperativen Server und deren Architektur ausfuhrlich in [LB08]beschrieben wird. Datenschutzfreundliche Beitrage zu dieser Architektur bestehen darin,Angelplatze mit einem Unscharfe-Faktor versehen zu konnen. Die aktuelle Position desBenutzers wird nicht auf einem Server gespeichert, sondern nur auf dem Client und wirddirekt mittels XMPP-Nachrichten von Nutzer zu Nutzer gesendet (P2P Modus). Ein Be-nutzer muss einem anderen Benutzer auf seiner Freundesliste ausdrucklich erlauben seinePosition sehen zu konnen, bevor die Nachricht mit der Position versendet wird. Unsere Im-plementierung unterstutzt das freie Auswahlen der aktuellen Position, was es dem Benut-zer ermoglicht falsche Koordinaten zu senden. Dabei sind alle Nachrichten verschlusseltum ein Abhoren zu vermeiden, das besonders fur den Hoster des XMPP Servers sonst ein-fach moglich ware. Um datenschutzfreundliche Awareness zu ermoglichen bietet der Cli-ent detaillierte Einstellungsmoglichkeiten. Dabei handelt es sich u.A., um die Moglichkeitden eigenen Online-Statues gegenuber bestimmten oder allen Benutzern in der Freundes-liste zu verstecken. Ferner unterstutzt unsere Architektur mehrere Topologien, die sich vonP2P uber unterschiedliche Gruppen-zentrische Konstellationen (z.B. mit Trennung oderohne Trennung von gemeinsamen Daten von solchen, die die Interaktion sowie Awaren-ess betreffen) bis zu einer reinen serverzentrischen Topologie, wie wir sie aus popularensozialen Net zwerken wie MySpace oder Facebook kennen. Momentan wird die Appli-kation auch im Rahmen von Evaluationen eingesetzt mit dem Ziel neue Anfordrungenzu sammeln, die unsere Losungsansatze und -Konzepte betreffen (z.B. Interoperabilitatder Daten). Erste Akzeptanz zeigt die Moglichkeiten eines realistischen Einsatzes solcherLosungen in der nahen Zukunft.

Literatur

[BKH+09] Mohamed Bourimi, Falk Kuhnel, Jorg M. Haake, Dhiah el Diehn I. Abou-Tair undDogan Kesdogan. Tailoring Collaboration According Privacy Needs in Real-IdentityCollaborative Systems. In CRIWG, Seiten 110–125, 2009.

[LB08] Stephan Lukosch und Mohamed Bourimi. Towards an Enhanced Adaptability and Usa-bility of Web-based Collaborative Systems. International Journal of Cooperative Infor-mation Systems, Special Issue on ’Design, Implementation of Groupware, Seiten 467–494, 2008.

[MB10] Eva Ganglbauer Thomas Barth Julian Dax Marcel Heupel Dogan Kesdogan Moha-med Bourimi, Bernd Ueberschaer. Building Usable and Privacy-preserving MobileCollaborative Applications for Real-life Communities: A Case Study Based Report.In iSociety 2010, (ANGENOMMEN, IM DRUCK), 2010.

[NS09] Arvind Narayanan und Vitaly Shmatikov. De-anonymizing Social Networks. 2009.

B.Eng. Jochen Kühner

Einsatz von SPIT-Filternmit der open Source PBX

Asterisk Version 1.4

Hochschule Pforzheim

Gliederung

1. Problemstellung................................................................................................1

2. Ziele und Hypothesen.......................................................................................1

3. Methodenübersicht...........................................................................................1

I

1. ProblemstellungSeit vor mehr als 25 Jahren die erste Email versandt wurde, wurde diese kostengünstige und einfache Variante zu kommunizieren immer beliebter. Heute sind leider mehr als 85,7% 1 des weltweiten Email-Verkehrs SPAM-E-Mails. In der Mitte der neunziger Jahre wurden SPAM-Filter entwickelt, um dieser lästigen und zeitraubenden Form von unerwünschter Werbung, welche zudem noch hohe Kosten verursacht, Einhalt zu gebieten. Die gleiche Problematik scheint sich heute für die relativ neue Form der Telefonie, nämlich bei Voice over Internet Protocol (VoIP), zu wiederholen. Aufgrund der Tatsache, dass VoIP genau wie E-Mail zum Null-Tarif verfügbar ist, lässt es sich ebenfalls missbrauchen und für Werbezwecke in ähnlicher Art und Weise als bei der E-Mail-Kommunikation verwenden. Der sogenannte Spam over Internet Telephony (SPIT) könnte somit zu einem ernstzunehmenden Problem2 werden.

2. Ziele und HypothesenAn der Hochschule Pforzheim wird seit September 2008 innerhalb des "Securitas"-Forschungsprojekts3 eine Anti-SPIT-Anwendung entwickelt. Dieses SPIT-Filter-System (Abbildung 1) wird zwischen das WAN / LAN (Wide Area Network / Local Area Network) beziehungsweise das klassische Telefonnetz (ISDN / PSTN) und das (VoIP-) Telefon geschaltet. Es funktioniert ähnlich wie eine Firewall oder ein SPAM-Filter. Das System sortiert eingehende Anrufe vor und versucht dadurch SPIT-Anrufe auf ein Minimum zu reduzieren.

Jedem Teilnehmer des Systems ist es möglich, sein persönliches SPIT-Filter-System individuell ein- oder auszuschalten. Das System kann mit einem aus der Emailwelt bekannten SPAM-Filter verglichen werden. Wurde ein Anruf als SPIT eingestuft, so wird der Anruf nicht an den Zielteilnehmer sondern an dessen SPIT-Mailbox weitergeleitet. Bei keinem SPIT Verdacht wird der Anruf in der üblichen Art und Weise mit dem Zielteilnehmer verbunden. Diese Entscheidung muss sorgfältig getroffen werden. Der Algorithmus muss in kurzer Zeit ausgeführt werden um sicherzustellen, dass der Anrufer nicht zu lange warten muss oder gar den Anruf vor dem Ende des Testdurchlaufs beendet.

3. MethodenübersichtDas SPIT-Filter-System wurde mittels eines Open Source VoIP PBX-Servers, einem Asterisk Server in der Version 1.4, realisiert. Alle Filterfunktionen wurden ohne weitere sonstige Erweiterungen mittels einzelner Makros im Wählplan des Asterisk-Servers realisiert. Der Asterisk Server wurde lediglich um eine Datenbankanbindung an eine MySQL-Datenbank mittels Open Database Connectivity (ODBC) zum persistieren der Kommunikationsdaten, Einstellungen und SPIT-Wahrscheinlichkeiten erweitert. Für das SPIT-Filter-System wurde eine Kaskade von unterschiedlichen Einzelfiltern entwickelt. Drei Grundprüfungen und zwei erweiterte Kontrollen überprüfen, ob ein eingehender Anruf als SPIT eingestuft wird oder nicht. Jede Kontrolle, bestanden oder nicht, ändert den so genannten temporären SPIT-Level. Dieser temporäre SPIT-Level gilt nur für den aktuellen Anruf, wird nicht persistent gespeichert und am Ende des Verfahrens gibt er an, ob der Anruf SPIT frei ist oder nicht.Die erste der drei Grundprüfungen, der so genannte "Time-Check" überprüft, ob innerhalb von einer Minute weniger als fünf Anrufe von der gleichen Absenderadresse (IP-Adresse oder

1http://www.kaspersky.com/news?id=2075759662http://www.heise.de/netze/Erste-groessere-Attacke-gegen-deutsche-VoIP-Nutzer--/news/meldung/1163353http://www.hs-pforzheim.de/De-de/Forschung/securitas/projektbeschreibung/Seiten/Inhaltseite.aspx

1

Abbildung 1: SPIT-Filter-System

Anrufer-ID) getätigt wurden. Mehr als fünf Anrufe pro Minute wird als ein Indikator für eine Anrufmaschine gewertet, was zu einer Erhöhung des temporären SPIT-Levels um fünf Punkte führt.Die zweite Stufe überprüft, ob die Anrufer-ID (CID) übertragen wird oder ob diese unterdrückt ist. Bei einer unterdrückten CID führt auch dies zu einer Erhöhung des temporären SPIT-Levels um fünf Zähler.In einem dritten Schritt wird die lokale Datenbank überprüft, um festzustellen ob sie bereits einen Eintrag für die Kommunikationsparameter des aktuellen Anrufers enthält. Je nach Ergebnis der Anfrage wird der temporäre SPIT-Level wie folgt gesetzt: Ist der in der Datenbank hinterlegte SPIT-Level ≦ fünf, so bleibt der temporären SPIT-Level unverändert. Ist der hinterlegte SPIT-Level jedoch höher als fünf, so wird der in der Datenbank hinterlegte Wert zu dem Wert des temporären SPIT-Levels addiert. War für die Kommunikationsparameter des Anrufers kein Eintrag hinterlegt, so wird der Wert des temporären SPIT-Levels für diesen Anruf um fünf erhöht.Wenn alle drei Grundprüfungen ohne Erhöhung des temporären SPIT-Levels bestanden wurden, wird der Anruf ohne weitere Prüfung an die gewählte Rufnummer weitergeleitet. Bei einem Wert des temporären SPIT-Levels größer neun wird das Gespräch eindeutig als SPIT klassifiziert werden und wird direkt auf die SPIT-Mailbox verbunden. Wenn der temporäre SPIT-Level jedoch bis dahin zwischen eins und neun liegt, so werden noch zwei erweiterte Kontrollen durchgeführt. In der ersten Stufe, der „Maschinenerkennung“, wird die Leitung beantwortet, also „abgehoben“, jedoch wird im Sprachkanal weiterhin ein Rufton übertragen. Bei einem menschlichen Anrufer wird erwartet, dass er ohne zu sprechen wartet bis das klingeln aufhört, während ein automatisierter SPIT-Aufruf sofort nach dem Zustandekommen der Verbindung mit dem Übertragen seiner Werbebotschaft beginnen würde. Wenn auf dem Kanal nun während des eingespielten Ruftons innerhalb einer vorgegebenen Zeitspanne Leistung in Form eines Audio-Signals detektiert wird, so wird der Anruf als potentieller SPIT-Anruf eingestuft und an eine weitere Kontrollstufe übergeben. Wird keine Leistung detektiert, so wird der Anrufer an die von Ihm gewählte Rufnummer durchgestellt. Im Falle der Einstufung als potentieller SPIT-Anruf wird der Anrufer noch einem letzten Test unterzogen, dem „Turing Test“. Hierbei wird der Anrufer zur Eingabe einer zufällig generierten Zahl aufgerufen. Eine Anrufmaschine würde in diesem Fall keine Zahl senden und somit als SPIT-Anruf klassifiziert werden. Einem Menschen der versehentlich, beispielsweise aufgrund einer lauten Umgebung, in dieser Teststufe landete wird somit die Möglichkeit gegeben sich durch die Eingabe der geforderten Zahl als Mensch zu identifizieren. Das erfolgreiche Beenden des „Turing Tests“ führt den Anrufer zum gewünschten Teilnehmer, konnte die Testaufgabe jedoch nicht innerhalb von 20 Sekunden gelöst werden führt dies den Anruf auf die SPIT-Mailbox.Vor dem letztendlichen Durchstellen des Anrufs, sei es zum angewählten Teilnehmer oder auf die SPIT-Mailbox, wird nochmals überprüft ob die lokale Datenbank bereits einen Eintrag für die Kommunikationsparameter des aktuellen Anrufers enthält. Ist dies der Fall, so wird bei der Einstufung des Anrufs als SPIT-Anruf der in der Datenbank hinterlegte SPIT-Level um zwei Zähler inkrementiert, bei der Einstufung als normaler Anruf wird der SPIT-Level für den hinterlegten Anrufer um einen Zähler dekrementiert. Waren in der Datenbank noch keine Daten für den Anrufer hinterlegt, so werden die Kommunikationsparameter für den Anrufer in dieser neu angelegt. Im Falle eines SPIT-Anrufs geschieht dies mit einem SPIT-Level von neun, im Falle eines normalen Anrufs mit einem SPIT-Level von fünf. Nach dieser Stufe ist der automatisierte Durchlauf durch das SPIT-Filter-System beendet und der Anrufer wurde entweder mit dem gewünschten Teilnehmer verbunden oder landete auf der SPIT-Mailbox.Nachdem ein Gespräch geführt wurde, kann dieses durch die Anwahl einer bestimmten Nummer nachträglich durch den Angerufenen bewertet werden. Nach Anwahl der Nummer wird ein Bewertungssystem gestartet und teilt dem Anrufenden die als letzte Verbindung zu ihm gespeicherte Rufnummer mit. Durch die Eingabe von Kennzahlen kann nun dieser Anrufer bewertet werden. Durch die Wahl der Kennzahl Null wird der Anrufer als SPIT-Anruf bewertet und sein SPIT-Level in der Datenbank um fünf Zähler inkrementiert. Bei einer Bewertung mittels der Kennzahl Eins, wird der Anrufer als normaler Anrufer eingestuft und sein SPIT-Level in der Datenbank um fünf Zähler dekrementiert. Mit der Kennzahl Acht kann der SPIT-Level des letzten Anrufers auf Null gesetzt werden, während die Neun den SPIT-Level auf 25 setzt und somit für das sofortige Ausfiltern des Anrufers beim nächsten Verbindungsversuch mit dem Teilnehmer sorgen wird.

2

A Proof of Concept Implementation and Evaluation of a Zero Configuration Authentication Option for EAP-TLS

Carolin LatzeDepartment of Informatics

University of FribourgBd. de Perolles 90

1700 FribourgSwitzerland

Ulrich Ultes-NitscheDepartment of Informatics

University of FribourgBd. de Perolles 90

1700 FribourgSwitzerland

Almost all the authentication protocols used in IEEE 802.11 based networks require the distribution or retrieval of user credentials before the first connect of a user. Obviously when talking about commercial public wireless LANs, such a pre-authentication process is absolutely necessary. However, there might be cases when such a preauthentication process does only introduce more complexity. One could imagine a company network where all new devices are registered and whitelisted using their MAC address. Since MAC filtering is not very secure, it might be desired to reconfigure the devices automatically on first connect to use a more secure authentication method like EAP-TLS. In 2007, [1] presented a TLS extension that allows to use the Trusted Platform Module (TPM) Identity certificates as TLS client certificates. Since the TPM is a trusted entity that can be identified uniquely worldwide and since the process of obtaining TPM Identity certificates can be automated, such certificates are perfectly suited for a zero configuration scheme in EAP-TLS. The basic idea behind that scheme is to allow the client to request a new certificate during the TLS handshake after the server sent its list of acceptable Certificate Authorities (CAs). This talk gives a short introduction into the theory of the EAP-TLS zero configuration option published first in [2]. Furthermore, a (yet unpublished) proof of concept implementation will be shown that allows to evaluate the concept. The implementation has been done using the gnutls TLS library [3] and shows pretty good results regarding performance and usability. Furthermore in order to evaluate the correction of the zero configuration option, a theoretical proof will be presented based on the logic presented in [4].

Bibliography

[1] C.Latze, U.Ultes-Nische, F.Baumgartner: Strong Mutual Authentication in a User-Friendly Way in EAP-TLS, 15th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2007), Split - Dubrovnik, Croatia, September 2007

[2] C.Latze, U.Ultes-Nitsche, F.Baumgartner: Towards a Zero Configuration Authentication Scheme for 802.11 Based Networks, IEEE Conference on Local Computer Networks (LCN 2008), Montreal, Canada, October 2008

[3] http://www.gnutls.org[4] N. Durgin, J. Mitchell, D. Pavlovic: A compositional logic for protocol correctness, Proceedings

of the 14th IEEE Computer Security Foundations Workshop, 2001

DTLS Mobility

R. Seggelmann∗ M. Tuxen†

March 19, 2010

Abstract

The Datagram Transport Layer Security (DTLS) [1] protocol is a modification of Transport LayerSecurity (TLS) [2] to provide encryption and authentication to unreliable and message-orientedtransport protocols, such as UDP. In [4] an extension to DTLS is described which adds a probingmechanism. This can be used to for various goals including path MTU discovery or dead peerdetection.

DTLS Mobility extends the DTLS protocol to allow the DTLS end-points to change the IP-address and/or port number. Therefore it combines the concept of transport layer mobility withthe security concepts provided by DTLS. DTLS Mobility can be used by all DTLS/UDP-basedapplications or by any application, when used for providing a DTLS based tunnel.

This contribution describes the required changes and extensions of DTLS to provide DTLSMobility. In particular, the following issues are addressed:

1. Identification of DTLS connections.

2. Detection of IP-address and/or port number changes.

3. Signaling of IP-address and/or port number changes.

4. Detection of path specific parameter like the MTU on route changes (see [3] for path MTUdiscovery).

5. Interaction with middle-boxes.

References

[1] E. Rescorla and N. Modadugu. Datagram Transport Layer Security. RFC 4347, April 2006.

[2] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2RFC 5246, August 2008.

[3] M. Mathis and J. Heffner. Packetization Layer Path MTU Discovery. RFC 4821, March 2007.

[4] R. Seggelmann and M. Tuxen. Transport Layer Security and Datagram Transport Layer Secu-rity Heartbeat Extension. draft-seggelmann-tls-dtls-heartbeat-02 (work in progress), Febru-ary 2010.

∗Munster University of Applied Sciences, Steinfurt, Germany - seggelmann@fh-muenster.de†Munster University of Applied Sciences, Steinfurt, Germany - tuexen@fh-muenster.de