Middleware-Forschung - Embedded System Software

Software ubiquitärer Systeme
Middleware-Forschung
Olaf Spinczyk
Arbeitsgruppe Eingebettete Systemsoftware
Lehrstuhl für Informatik 12
TU Dortmund
[email protected]
http://ess.cs.uni-dortmund.de/~os/
http://ess.cs.tu-dortmund.de/DE/Teaching/SS2012/SuS/
1
Inhalt
●
Stand der Kunst
●
Maßschneiderung
Energieverbrauch
Kontext
Sicherheit
Zusammenfassung
●
●
●
●
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)
04.4 – Middleware-Forschung
3
Stand der Kunst: Querschnittsthemen
(Bisher betrachtet: OSEK/COM+NM, UPnP)
●
●
Kontext
●
OSEK:
Liste der aktiven Knoten,
periodische Zustandsnachrichten
●
UPnP:
Ereignisverteilung (publish-subscribe)
Sicherheit
●
OSEK:
Vernachlässigt, da abgeschlossenes System
●
UPnP:
Spät aufgenommen,
„klassische“ kryptographische Verfahren
04.4 – Middleware-Forschung
4
Inhalt
●
Stand der Kunst
●
Maßschneiderung
Energieverbrauch
Kontext
Sicherheit
Zusammenfassung
●
●
●
●
04.4 – Middleware-Forschung
5
Statische Maßschneiderung (1)
Beispiel: nORB [1]
●
Anwendungsspezifische Vereinfachungen bzgl. ...
●
unterstützter Datentypen
- Beispielsweise wird der CORBA-Datentyp Any häufig nicht benötigt
●
der Kommunkationsprotokolle
- Weglassen unbenötigter Nachrichtentypen (der CORBA-Spezifikation)
●
des Lebenszyklusmodells von Objekten
- Objekte müssen nicht unbedingt dynamisch erzeugt und zerstört werden
●
der serverseitigen Objektsuche bei Methodenaufrufen
- Beispielsweise lineare Suche statt Hash-Tabelle
●
des serverseitiger Kontrollflusses
- Direkter Aufruf der Methode des Objekts aus dem
Nachrichtenbehandlungs-Prozess der Middleware.
04.4 – Middleware-Forschung
6
Statische Maßschneiderung (2)
Beispiel: nORB [1] – Ergebnis
04.4 – Middleware-Forschung
7
Dynamische Maßschneiderung (1)
●
Motivation
●
Szenario: Mobiles ubiquitäre Systeme 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ührt 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.
- Dynamik würde hier Ressourcen verschwenden → Beides muss gehen!
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“
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“
interface
interface DynamicConfigurator
DynamicConfigurator {{
typedef
typedef sequence<string>
sequence<string> stringList;
stringList;
typedef
typedef sequence<octet>
sequence<octet> impCode;
impCode;
stringList
stringList listLoadedComponents();
listLoadedComponents();
stringList
listHooks
stringList listHooks (in
(in string
string compName);
compName);
short
short loadComponent
loadComponent (in
(in string
string impName,
impName,
in
in string
string params);
params);
void
void deleteComponent
deleteComponent (in
(in string
string name);
name);
void
void createHook(in
createHook(in compName,
compName, in
in hookName);
hookName);
void
deleteHook(in
compName,
in
hookName);
void deleteHook(in compName, in hookName);
void
void hookComponent
hookComponent (in
(in string
string compName,
compName,
in
in string
string targetCompName,
targetCompName,
in
in string
string hookName);
hookName);
string
string getHookedComponent(in
getHookedComponent(in string
string compName,
compName,
in
string
hookName);
in string hookName);
void
void uploadComponent
uploadComponent (in
(in string
string impName,
impName,
in
in impCode
impCode binCode);
binCode);
void
void deleteStoredComponent
deleteStoredComponent ((
in
in string
string categoryName,
categoryName, in
in impName);
}}
04.4 – Middleware-Forschung
10
Dynamische Maßschneiderung (4)
●
Beispiel UIC [2] – Ergebnis
Speicherplatzverbrauch einiger UIC-Varianten:
Plugins
Plugins für
für
UIC
UIC HybridMultipersonality
HybridMultipersonality
04.4 – Middleware-Forschung
11
Fazit Maßschneiderung
●
Viele Ähnlichkeiten zu Techniken im BS-Bereich
●
Statische Maßschneiderung: wie in eCos
- zur Reduktion der Codegröße, hier in nORB
●
Meta-Objekte und Reflektion: wie in Apertos
- 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.
04.4 – Middleware-Forschung
12
Inhalt
●
Stand der Kunst
●
Maßschneiderung
Energieverbrauch
Kontext
Sicherheit
Zusammenfassung
●
●
●
●
04.4 – Middleware-Forschung
13
Power Management in UC Middleware
●
Motivation
●
Szenario: In einem Haushalt gibt es diverse mobile ubiquitäre
Systeme
-
●
Gegenstände können sich melden, wenn sie gesucht werden
Fernbedienungen liegen in jedem Raum
Bewegungssensoren dienen der Beleuchtungssteuerung
Drahtlose Wetterstationen melden Messwerte
…
Problem: Die Bewohner sind im Urlaub.
- Keiner hat etwas davon
- Strom wird verschwendet
- Akku-/Batterielaufzeiten werden unnötig verkürzt
●
Lösung: Deaktivierung unbenötigter Geräte im Netzwerk
- Anwendung von Stromsparmodi
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?
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.
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.
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 tti i teilt
teilt nn22
dem
dem Cluster
Cluster Head
Head nn1 mit,
mit, dass
dass er
er für
für ttsd
1
sd
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 verbleiben
verbleiben Schlafdauer.
Schlafdauer.
 Obwohl
Obwohl nn2 inaktiv
inaktiv war,
war, lehnt
lehnt der
der
2
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 Service
Service Discovery
Discovery Anfrage
Anfrage gestellt
gestellt
hatte.
hatte.
04.4 – Middleware-Forschung
18
Sandman Power Management [4] (4)
●
●
Erhaltung der Netzwerkkonnektivität
Cluster Heads werden für das Routing genutzt
Voraussetzung
CH 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)
04.4 – Middleware-Forschung
19
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.
●
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
04.4 – Middleware-Forschung

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
Gruppen von
von 44 Geräten.
Geräten.
 Es
Es bewegen
bewegen sich
sich Gruppen
Gruppen
von
von 10
10 Geräten.
Geräten.
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!
04.4 – Middleware-Forschung
22
Inhalt
●
Stand der Kunst
●
●
Maßschneiderung
Energieverbrauch
Kontext
Sicherheit
●
Zusammenfassung
●
●
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“
04.4 – Middleware-Forschung
24
CAMUS: Kontextgewahre Middleware
●
(Context-Aware Middleware for URC Systems) [5]
●
Vernetzung von Service-Robotern mit intelligenten Umgebungen
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
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
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“
Quelle: Wikipedia
●
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, ...
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
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.
04.4 – Middleware-Forschung
31
CAMUS: Struktur der Context Engine
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
04.4 – Middleware-Forschung
33
Inhalt
●
Stand der Kunst
●
Maßschneiderung
Energieverbrauch
Kontext
Sicherheit
Zusammenfassung
●
●
●
●
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“
● „Man-in-the-Middle“
● „Playback“
●
●
Sich als ein anderer ausgeben
Datenstrom filtern und verändern
Aufgezeichnete Daten wieder abspielen
Passive Angriffe
„Eavesdropping“
● „Traffic Analysis“
●
Daten abhören
Datenverkehr analysieren (Protokolle)
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.
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
●
Modifiziertes „Learning Parity
with Noise“ Verfahren
04.4 – Middleware-Forschung
G3
„---“
G4
„secret“?
G1
„secret“
gut
böse
G2
„secret“
gut
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
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!
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
04.4 – Middleware-Forschung
40
Inhalt
●
Stand der Kunst
●
Maßschneiderung
Energieverbrauch
Kontext
Sicherheit
Zusammenfassung
●
●
●
●
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 Optimierungspotential
durch schichtübergreifende Betrachungen.
04.4 – Middleware-Forschung
42
Literatur (1)
[1]
[2]
[3]
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 RealTime 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-R-2000-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 aspectoriented programming. In Proceedings of the 6th international
Workshop on Software Engineering and Middleware (SEM '06),
2006.
04.4 – Middleware-Forschung
43
Literatur (2)
[4]
[5]
[6]
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
Context-Awareness 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.
04.4 – Middleware-Forschung
44
Literatur (3)
[7]
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.
04.4 – Middleware-Forschung
45