SuS-04.4: Middleware-Forschung
Werbung
Software ubiquitärer Systeme (SuS) Middleware-Forschung https://ess.cs.tu-dortmund.de/DE/Teaching/SS2016/SuS/ Horst Schirmeier, Olaf Spinczyk [email protected] https://ess.cs.tu-dortmund.de/~hsc AG Eingebettete Systemsoftware Informatik 12, TU Dortmund Inhalt ● Stand der Kunst ● Maßschneiderung ● Energieverbrauch ● Kontext ● Sicherheit ● Zusammenfassung 14.06.2016 SuS: 04.4 Middleware-Forschung 2 Stand der Kunst: Querschnittsthemen (Bisher betrachtet: OSEK/COM+NM, UPnP) ● ● Maßschneiderung – OSEK: Durch OIL/Codegenerierung und Conformance Classes – UPnP: Praktisch nicht Energiesparen – OSEK: Mechanismus zum kollektiven Moduswechsel – UPnP: Erweiterung seit 2007 (UPnP Low Power Architecture) 14.06.2016 SuS: 04.4 Middleware-Forschung 3 Stand der Kunst: Querschnittsthemen (Bisher betrachtet: OSEK/COM+NM, UPnP) ● ● Kontext – OSEK: – UPnP: Liste der aktiven Knoten, periodische Zustandsnachrichten Ereignisverteilung (publish-subscribe) Sicherheit – – OSEK: UPnP: 14.06.2016 Vernachlässigt, da abgeschlossenes System Spät aufgenommen, „klassische“ kryptographische Verfahren SuS: 04.4 Middleware-Forschung 4 Inhalt ● Stand der Kunst ● Maßschneiderung ● Energieverbrauch ● Kontext ● Sicherheit ● Zusammenfassung 14.06.2016 SuS: 04.4 Middleware-Forschung 5 Statische Maßschneiderung (1) Beispiel: nORB [1] ● Anwendungsspezifische Vereinfachungen bzgl. … – unterstützter Datentypen ● – der Kommunikationsprotokolle ● – Objekte müssen nicht unbedingt dynamisch erzeugt und zerstört werden der serverseitigen Objektsuche bei Methodenaufrufen ● – Weglassen unbenötigter Nachrichtentypen (der CORBA-Spezifikation) des Lebenszyklusmodells von Objekten ● – Beispielsweise wird der CORBA-Datentyp Any häufig nicht benötigt Beispielsweise lineare Suche statt Hash-Tabelle des serverseitiger Kontrollflusses ● 14.06.2016 Direkter Aufruf der Methode des Objekts aus dem Nachrichtenbehandlungs-Prozess der Middleware. SuS: 04.4 Middleware-Forschung 6 Statische Maßschneiderung (2) Beispiel: nORB [1] – Ergebnis 14.06.2016 SuS: 04.4 Middleware-Forschung 7 Dynamische Maßschneiderung (1) ● Motivation – Szenario: Mobiles ubiquitäres System in neuem Kontext ● ● ● Benutzer betritt einen Raum. Beleuchtung spricht CORBA. Stereo-Anlage spricht UPnP. – Problem: Das mobile Gerät kann nicht statisch auf alle Eventualitäten vorbereitet sein. – Lösung: Geräte führen eine standardisierte Service Discovery durch ● ● ● – Die CORBA- und UPnP-Merkmale werden dynamisch nachgeladen und installiert. Der Benutzer steuert den Raum nach seinen Wünschen Beim Verlassen des Raumes werden die nun unbenötigten Merkmale automatisch wieder entfernt. Aber Achtung: Die Middleware der stationären Geräte müsste nicht adaptierbar sein. ● 14.06.2016 Dynamik würde hier Ressourcen verschwenden → Beides muss gehen! SuS: 04.4 Middleware-Forschung 8 Dynamische Maßschneiderung (2) Beispiel: UIC (Universally Interoperable Core) [2] ● Eine modulare reflektive UC-Middleware ● Motto: „What you need is what you get“ ● Unterstützt Interoperabilität in Form statischer oder dynamischer „Personalities“ 14.06.2016 SuS: 04.4 Middleware-Forschung 9 Dynamische Maßschneiderung (3) ● Der Dynamic Configurator stellt den Reflektionsmechnismus zur Verfügung – Er hat selbst eine CORBA-Schnittstelle Der „UIC-Multipersonality Core“ 14.06.2016 interface interface DynamicConfigurator { typedef typedef sequence<string> sequence<string> stringList; typedef typedef sequence<octet> sequence<octet> impCode; stringList stringList listLoadedComponents(); listLoadedComponents(); stringList stringList listHooks listHooks (in (in string compName); short short loadComponent loadComponent (in (in string impName, in in string string params); params); void void deleteComponent deleteComponent (in (in string name); void void createHook(in createHook(in compName, in hookName); void void deleteHook(in deleteHook(in compName, in hookName); void void hookComponent hookComponent (in (in string compName, in in string string targetCompName, targetCompName, in in string string hookName); hookName); string string getHookedComponent(in string compName, in in string string hookName); hookName); void void uploadComponent uploadComponent (in (in string impName, in in impCode impCode binCode); binCode); void void deleteStoredComponent deleteStoredComponent ( in in string string categoryName, categoryName, in in impName); impName); 10 SuS: 04.4 Middleware-Forschung } Dynamische Maßschneiderung (4) Beispiel: UIC [2] – Ergebnis ● Speicherplatzverbrauch einiger UIC-Varianten: Plugins Plugins für für UIC HybridMultipersonality UIC HybridMultipersonality 14.06.2016 SuS: 04.4 Middleware-Forschung 11 Fazit Maßschneiderung ● Viele Ähnlichkeiten zu Techniken im BS-Bereich – Statische Maßschneiderung: wie in eCos ● – Meta-Objekte und Reflektion: wie in Apertos ● – ➔ zur Reduktion der Codegröße, hier in nORB zur dynamischen Rekonfigurierung, hier in UIC Gibt es auch AOP (wie in CiAO)? Na klar! [3] Lediglich die Merkmale sind domänenspezifisch. Die Techniken zur Maßschneiderung sind übertragbar. 14.06.2016 SuS: 04.4 Middleware-Forschung 12 Inhalt ● Stand der Kunst ● Maßschneiderung ● Energieverbrauch ● Kontext ● Sicherheit ● Zusammenfassung 14.06.2016 SuS: 04.4 Middleware-Forschung 13 Power Management in UC Middleware ● Motivation – Szenario: In einem Haushalt gibt es diverse mobile ubiquitäre Systeme ● ● ● ● ● – Problem: Die Bewohner sind im Urlaub. ● ● ● – Gegenstände können sich melden, wenn sie gesucht werden Fernbedienungen liegen in jedem Raum Bewegungssensoren dienen der Beleuchtungssteuerung Drahtlose Wetterstationen melden Messwerte … Keiner hat etwas davon Strom wird verschwendet Akku-/Batterielaufzeiten werden unnötig verkürzt Lösung: Deaktivierung unbenötigter Geräte im Netzwerk ● 14.06.2016 Anwendung von Stromsparmodi SuS: 04.4 Middleware-Forschung 14 Power Management: Herausforderungen ● Planung der Zustandsübergänge – ● Service Discovery – ● Wie entdeckt man Dienste auf schlafenden Knoten? Erhaltung der Netzwerkkonnektivität – ● Wann darf ein Knoten schlafen, wann wacht er wieder auf? Wie kann trotz schlafender Knoten das Routing im Ad-hoc-Netzwerk weiter funktionieren? Interaktionslatenzen – Wie verändern sich die Reaktionszeiten des Systems? 14.06.2016 SuS: 04.4 Middleware-Forschung 15 Sandman Power Management [4] (1) Planung der Zustandsübergänge ● Übergang in den Schlafzustand – Nach einer definierten Zeit der Inaktivität – Durch den ausdrücklichen Wunsch der Anwendung (des Dienstes) – Nicht, wenn es noch ausstehende Dienstanforderungen gibt – Nicht, während noch eine Session läuft ● ● – Eine Session gruppiert eine Reihe von Aufrufen Durch Einsatz von Leases wird dafür gesorgt, dass Sessions auch enden können, selbst wenn ein Klient während der Session terminiert. Klient und Dienst können Inaktivitätsphasen aushandeln. 14.06.2016 SuS: 04.4 Middleware-Forschung 16 Sandman Power Management [4] (2) Service Discovery ● Problem: – ● Schlafende Geräte können nicht auf Service-Discovery-Anfragen reagieren. Ihre Dienste sind nicht auffindbar. Lösung: – Benachbarte Geräte mit dem gleichen „Mobilitätsmuster“ bilden Cluster. ● – Beispiele: Alle mobile Geräte in einem Raum, in einem Fahrzeug oder in der Kleidung. Solche Cluster sind vergleichsweise stabil. Jedes Cluster bestimmt einen Cluster Head, der Service-Discovery-Anfragen für schlafende Knoten des Clusters beantworten kann. 14.06.2016 SuS: 04.4 Middleware-Forschung 17 Sandman Power Management [4] (3) ● Zusammenfassung: Übergang → Schlafzustand – Cluster wurde bereits gebildet Nach Nach einer einer Zeit Zeit der der Inaktivität Inaktivität ttii teilt teilt nn22 dem dem Cluster Cluster Head Head nn11 mit, mit, dass dass er er für für ttsdsd schlafen schlafen möchte. möchte. Der Der Cluster Cluster Head Head antwortet antwortet mit mit der der erlaubten erlaubten Schlafdauer Schlafdauer ttss.. Ein Ein Klient Klient sucht sucht nach nach einem einem Dienst Dienst und und erfährt, erfährt, dass dass nn22 diesen diesen anbietet anbietet inkl. inkl.der der evtl. evtl.noch noch verbleibenden verbleibenden Schlafdauer. Schlafdauer. Obwohl Obwohl nn22 inaktiv inaktiv war, war,lehnt lehnt der der Cluster Cluster Head Head den den Übergang Übergang in in den den Schlafmodus Schlafmodus ab, ab,da da kurz kurz zuvor zuvor ein ein Klient Klient eine eine ServiceServiceDiscovery-Anfrage Discovery-Anfrage gestellt gestellt hatte. hatte. 14.06.2016 SuS: 04.4 Middleware-Forschung 18 Sandman Power Management [4] (4) Erhaltung der Netzwerkkonnektivität ● Cluster Heads werden für das Routing genutzt ● Voraussetzung: ● ● – Cluster Head kann alle Knoten erreichen, die auch die schlafenden Knoten erreichen könnten ➔ Erweiterung des Clustering-Algorithmus: Nur Knoten, die die gleichen Nachbarschaftbeziehungen haben, dürfen ein Cluster bilden. Nachteile: – Kleinere Cluster – Nachbarschaftsgraph muss regelmäßig kontrolliert werden ➔ Zusätzlicher Aufwand und Energieverbrauch Lösungsansatz: Trade-off zwischen Konnektivität und Energieverbrauch durch Parameter beeinflussen (kaum Kontrollen, Nachbarschaftstoleranz) 19 14.06.2016 SuS: 04.4 Middleware-Forschung – Sandman Power Management [4] (5) Interaktionslatenzen ● Kooperative Planung der Schlafphasen im Cluster – ● Der Cluster Head hat durch das vorgestellte Protokoll die volle Kontrolle. Bisher zwei Verfahren: – Zwei Knoten, die die gleichen Dienste anbieten, haben symmetrisch überlappende Schlafphasen. Dadurch wird die Wartezeit bis ein Gerät erwacht minimiert. – Ein Gerät aus einer Gruppe mit dem gleichen Dienst bleibt wach. Es erfolgt ein Wechsel dieses wachen Geräts nach dem Round Robin Prinzip. 14.06.2016 SuS: 04.4 Middleware-Forschung 20 Sandman Power Management [4] (6) Projektergebnisse ● Im Simulator zeigt sich eine Ersparnis – ● Reale Hardware hat häufig lang dauernde Zustandsübergänge – ● bis zu 60% pro Gerät iPAQ: WLAN 10s! Vernachlässigtes Problem: – Energiegewahre Dienstauswahl 14.06.2016 Einzelne Einzelne mobile mobile Geräte Geräte bewegen bewegen sich sich mit mit 2m/s. 2m/s. Es Es bewegen bewegen sich sich jeweils jeweils Gruppen von 4 Geräten. Gruppen von 4 Geräten. Es Es bewegen bewegen sich sich Gruppen Gruppen von von 10 Geräten. 10 Geräten. SuS: 04.4 Middleware-Forschung 21 Fazit Power Management ● ● ● Power Management im ubiquitären Netz stellt viele neue Herausforderungen – Eine neue Dimension im Vergleich zum lokalen Power Management des Betriebssystems! – Diverse weitere Forschungsprojekte Wie passt das Power Management des Betriebssystems und das der Middleware zusammen? – Was soll die Middleware über Ein/Ausgabe-Aktivitäten erfahren? – Sollte das Betriebssystem mehr über andere Knoten im Netz wissen? – Das Thema Stromsparen zieht sich durch viele Schichten im Hardware-/Software-Stapel. Gibt es hier Optimierungspotential? Viele offene Fragen! 14.06.2016 SuS: 04.4 Middleware-Forschung 22 Inhalt ● Stand der Kunst ● Maßschneiderung ● Energieverbrauch ● Kontext ● Sicherheit ● Zusammenfassung 14.06.2016 SuS: 04.4 Middleware-Forschung 23 Kontext & Middleware: Motivation ● ● ● Ziel: – Applikationen sollen „Informationen“ über den Kontext erhalten. – Applikationen sollen „Wissen“, was die Kontextinformationen „bedeuten“, um sinnvoll darauf reagieren zu können. Probleme: – Sensoren liefern ganz unterschiedliche Daten. Bevor sie zu brauchbaren Informationen werden, müssen sie interpretiert werden. – In einem verteilten System können auch Sensoren anderer Knoten für die lokalen Applikationen relevant sein. – Unterschiedliche Sensordaten müssen evtl. zum Zwecke von Schlussfolgerungen kombiniert werden. – Jede Applikation erzeugt sich bisher ein eigenes Kontextmodell. Lösung: – „Kontext-gewahre Middleware“ 14.06.2016 SuS: 04.4 Middleware-Forschung 24 CAMUS: Kontextgewahre Middleware ● (Context-Aware Middleware for URC Systems) [5] – Vernetzung von Service-Robotern mit intelligenten Umgebungen 14.06.2016 SuS: 04.4 Middleware-Forschung 25 CAMUS: Funktionen ● Netzwerkweite Sammlung und Verteilung – ● Veredelung der Sensordaten – ● ... von Benutzern und Objekten Bereitstellung einer speziellen Programmiersprache – ● … zur Repräsentation und Manipulation von Kontext Automatische Lokalisierung – ● … zu höherwertigen Kontextinformationen durch logische Schlussfolgerungen Ein universelles Datenmodell – ● … von Kontextinformationen … für kontextgewahre Anwendungen (Java-Erweiterung) Ein Service-Framework – … für die einfache Erweiterung durch zusätzliche Sensoren und Integration von Legacy-Code 14.06.2016 SuS: 04.4 Middleware-Forschung 26 CAMUS: Funktionen ● Netzwerkweite Sammlung und Verteilung – ● Veredelung der Sensordaten – ● ... von Benutzern und Objekten Bereitstellung einer speziellen Programmiersprache – ● … zur Repräsentation und Manipulation von Kontext Automatische Lokalisierung – ● … zu höherwertigen Kontextinformationen durch logische Schlussfolgerungen Ein universelles Datenmodell – ● … von Kontextinformationen … für kontextgewahre Anwendungen (Java-Erweiterung) Ein Service-Framework – … für die einfache Erweiterung durch zusätzliche Sensoren und Integration von Legacy-Code 14.06.2016 SuS: 04.4 Middleware-Forschung 27 CAMUS: Kontextrepräsentation (1) Erfolgt mit Hilfe von Ontologien in der Sprache OWL – Ontologien beschreiben die Begriffe einer Domäne und ihre Beziehungen in formaler Weise – Ontologien sind auch Grundlage des „Semantic Web“ 14.06.2016 uelle: Wikipedia ● SuS: 04.4 Middleware-Forschung 28 CAMUS: Kontextrepräsentation (2) ● Shared Ontology enthält allgemeine Begriffe – ● Activity, Device, Environment, Information Source, Person Domain Ontology kommt applikationsspezifisch dazu – Meeting, Projector, ... 14.06.2016 SuS: 04.4 Middleware-Forschung 29 CAMUS: Kontextabhängigkeit ● ● Mit Hilfe von Kontextanfragen (in RDQL) lässt sich kontextabhängiges Verhalten implementieren, z.B. – Ein angemeldeter Teilnehmer eines Treffens befindet sich in dem Raum, in dem das Treffen stattfindet. – Ohne vorgegebene Ontologie wären solche Anfragen sehr viel schwieriger Unterstützt wird zudem das automatische Zustellen von Events bei Eintreten einer bestimmten Kontexteigenschaft 14.06.2016 SuS: 04.4 Middleware-Forschung 30 CAMUS: Inferenzregeln ● Dienen dazu, höherwertige Kontextinformationen automatisch zu ermitteln, z.B. – Eine Person, die sich in einem Raum befindet, in dem ein Treffen stattfindet, ist ein Teilnehmer. 14.06.2016 SuS: 04.4 Middleware-Forschung 31 CAMUS: Struktur der Context Engine 14.06.2016 SuS: 04.4 Middleware-Forschung 32 Fazit Kontext ● ● Ubiquitäre Middleware muss Anwendungen die Möglichkeit geben, auf Kontext zu reagieren. – Daraus ergeben sich viele neue Problemstellungen – Diverse neue Funktionseinheiten Ontologien werden erfolgreich als Basis für die Kontextrepräsentation genutzt – ● Es gibt auch andere Möglichkeiten. Für Ontologien existieren aber (Web-)Standards → OWL, RDFS … Ontologien können auch um anwendungsspezifische Inferenzregeln erweitert werden 14.06.2016 SuS: 04.4 Middleware-Forschung 33 Inhalt ● Stand der Kunst ● Maßschneiderung ● Energieverbrauch ● Kontext ● Sicherheit ● Zusammenfassung 14.06.2016 SuS: 04.4 Middleware-Forschung 34 Sicherheit: Eigenschaften + Gefahren ● Zusammenarbeit und Kommunikation sind unvermeidlich ● Knoten verarbeiten schützenswerte (private) Daten ● Ubiquitäre Netze sind offen und dynamisch ● Knoten sind ungeschützt und können manipuliert werden Gefahren ● ● Aktive Angriffe: – „Masquerade“ – Sich als ein anderer ausgeben – „Man-in-the-Middle“ – Datenstrom filtern und verändern – „Playback“ – Aufgezeichnete Daten wieder abspielen Passive Angriffe: – „Eavesdropping“ – Daten abhören – „Traffic Analysis“ – Datenverkehr analysieren (Protokolle) 14.06.2016 SuS: 04.4 Middleware-Forschung 35 Sicherheit: Herausforderungen ● ● Privatsphäre: – Schützenswerte Daten müssen verschlüsselt werden – Benutzerdefinierbare Policies Zugangskontrolle: – ● Interaktionen ausschließlich mit berechtigten Knoten Vertrauensmodelle: – Knoten werden beurteilt nach früheren Erfahrungen, Empfehlungen von anderen Knoten und deren Ruf – Klassische Schutzmechanismen beruhen ausschließlich auf der Identifikation von Kommunikationspartnern. 14.06.2016 SuS: 04.4 Middleware-Forschung 36 Beispiel: ILDD in S-MARKS [7] ● ● ● S-MARKS: Eine in Hinblick auf Sicherheit entwickelte Middleware für ubiquitäre Systeme ILDD: „Impregnable Lightweight Device Discovery“ Problemstellung: – Wenn ein neues Gerät auftaucht, soll erkannt werden, ob es gutoder bösartig ist. – Es sollen auf keinen Fall Dienste bösartiger Geräte benutzt werden – ● Bösartige Geräte könnten mithören Lösungsansatz: – G3 „---“ G4 „secret“? böse G1 „secret“ gut G2 „secret“ gut Modifiziertes „Learning Parity with Noise“-Verfahren 14.06.2016 SuS: 04.4 Middleware-Forschung 37 „Learning Parity with Noise“ [7] ● Knoten H soll sich bei zweitem Knoten C authentifizieren ● H und C haben ein gemeinsames Geheimnis ● – Bitvektor x der Länge N – Das Geheimnis darf nicht direkt übertragen werden! C berechnet Zufallsvektor c und schickt diesen an H – ● H berechnet r = c · x (ein Bit) und schickt es zurück. – ● ● „response“ C prüft die Richtigkeit Da die Wahrscheinlichkeit eines Zufallstreffers bei 50% liegt, sollte der Vorgang mehrfach durchgeführt werden. – ● „challenge“ Leider wird es damit aber auch leichter das Geheimnis zu ermitteln H erzeugt bewusst mit zum Teil falsche Bits (P < 50%) – Damit wird das Erlernen des Geheimnisses NP-hart 14.06.2016 SuS: 04.4 Middleware-Forschung 38 Anwendung von LPN in ILDD ● ● ● ● Die Gruppe der gutartigen Knoten wählt einen Führer. Alle Knoten schicken (wie C) an den neuen Knoten (wie H) eine „challenge“ Der neue Knoten berechnet die „response“ und antwortet. Alle Ergebnisse werden überprüft und an den Führer gemeldet. – ● ● Eine „Empfehlung“ für den neuen Knoten (wahr/falsch) Wenn die Anzahl der Empfehlungen einen Schwellwert überschreitet wird der Knoten als gutartig eingestuft Immer wieder abweichende Empfehlungen werden erkannt und ausgefiltert. – Evtl. ist hier ein bösartiger Knoten in der Gruppe! 14.06.2016 SuS: 04.4 Middleware-Forschung 39 Fazit Sicherheit ● ● ● ● Ubiquitäre Netze stellten besondere Sicherheitsanforderungen Es gibt keine zentralen Instanzen Middleware sollte dieses berücksichtigen und entsprechende Verfahren anbieten Es gibt in diesem Bereich diverse aktuelle Forschungsarbeiten 14.06.2016 SuS: 04.4 Middleware-Forschung 40 Inhalt ● Stand der Kunst ● Maßschneiderung ● Energieverbrauch ● Kontext ● Sicherheit ● Zusammenfassung 14.06.2016 SuS: 04.4 Middleware-Forschung 41 Zusammenfassung ● Im Bereich der Middleware für ubiquitäre Systeme sind noch viele Fragen ungelöst. – ● Bei der Maßschneiderung sind die eingesetzten Techniken aus dem Betriebssystembereich übertragbar – ● Ein aktuelles Forschungsgebiet In anderen Bereichen sind die Forschungsfragen eher domänenspezifisch. Teilweise stellt sich die Frage der Verantwortlichkeiten von Schichten und des Optimierungspotentials durch schichtübergreifende Betrachtungen. 14.06.2016 SuS: 04.4 Middleware-Forschung 42 Literatur (1) [1] [2] [3] 14.06.2016 V. Subramonian, G. Xing, C. Gill, C. Lu and R. Cytron, Middleware Specialization for Memory-Constrained Networked Embedded Systems. In Proceedings of the 10th IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), 2004. M. Roman, F. Kon, and R. Campbell, Reflective Middleware: from Your Desk to Your Hand. Technical Report. UMI Order Number: UIUCDCS-R2000-2195., University of Illinois at Urbana-Champaign, 2000. N. Cacho, T. Batista, A. Garcia, C. Sant'Anna, G. and Blair. Improving modularity of reflective middleware with aspect-oriented programming. In Proceedings of the 6th international Workshop on Software Engineering and Middleware (SEM '06), 2006. SuS: 04.4 Middleware-Forschung 43 Literatur (2) [4] [5] [6] 14.06.2016 G. Schiele, M. Handte, and C. Becker, Experiences in Designing an Energy-Aware Middleware for Pervasive Computing. In Proceedings of the 2008 Sixth Annual IEEE international Conference on Pervasive Computing and Communications (PERCOM). IEEE Computer Society, 2008. A. Moon, H. Kim, K. Lee, and H. Kim. Designing CAMUS based ContextAwareness for Pervasive Home Environments. In Proceedings of the 2006 international Conference on Hybrid information Technology Volume 01 (ICHIT). IEEE Computer Society, pages 666-672, 2006. S. I. Ahamed, M. M. Haque, and K. M. Asif. S-MARKS: A Middleware Secure by Design for the Pervasive Computing Environment. In Proceedings of the international Conference on information Technology (ITNG). IEEE Computer Society, pages 303-310, 2007. SuS: 04.4 Middleware-Forschung 44 Literatur (3) [7] 14.06.2016 N. J. Hopper and M. Blum. Secure Human Identification Protocols. In Proceedings of the 7th international Conference on the theory and Application of Cryptology and information Security: Advances in Cryptology. C. Boyd, Ed. Lecture Notes In Computer Science, vol. 2248. Springer-Verlag, London, pages 52-66, 2001. SuS: 04.4 Middleware-Forschung 45
