Kryptografie und

Verbindungsmanagement

von SMART Meter

Gateways: Internetquellen der Masterthesis

Kruetzen, Ingo [Wählen Sie das Datum aus]

Inhalt Admin-Magazin ....................................................................................................................................... 2

BitWorld ................................................................................................................................................ 14

BSI .......................................................................................................................................................... 18

Cassandra .............................................................................................................................................. 19

Cryptas ................................................................................................................................................... 20

CUBRID .................................................................................................................................................. 24

Curtalo ................................................................................................................................................... 27

TU Darmstadt ........................................................................................................................................ 31

Datenbank-Engines ............................................................................................................................... 50

ENBW ..................................................................................................................................................... 52

Heise ...................................................................................................................................................... 53

HS-Mannheim ........................................................................................................................................ 55

HU-Berlin ............................................................................................................................................... 57

InfoQ ...................................................................................................................................................... 76

IT-Administrator .................................................................................................................................... 94

IT-Wissen ............................................................................................................................................... 97

Krypto .................................................................................................................................................... 98

Meinberg ............................................................................................................................................. 101

Mintert ................................................................................................................................................ 102

Orientation in Objects ......................................................................................................................... 105

Pacemaker ........................................................................................................................................... 117

Regenachsen ....................................................................................................................................... 119

Microsoft Security ............................................................................................................................... 123

SSL........................................................................................................................................................ 125

UNI-Tübingen ...................................................................................................................................... 129

Zookeeper ............................................................................................................................................ 130

Admin-Magazin admin-magazin.de. Abgerufen am 01. 07 2013 von

http://www.admin-magazin.de/Das-Heft/2011/04/HA-Serie-Teil-1-Grundlagen-von-Pacemaker-und-Co

HA-Serie, Teil 1: Grundlagen von Pacemaker und Co.

Der Cluster-Leitstand

Aus ADMIN 04/2011

Martin Loschwitz

Unverzichtbarer Bestandteil eines Hochverfügbarkeits-Clusters ist ein Cluster-Manager, der im

Problemfall weiß, was zu tun ist. Mit Pacemaker liegt zum ersten Mal überhaupt ein brauchbarer

Cluster-Manager für Linux auf der Grundlage von Open Source vor.

Der Failover, also die Übernahme von Diensten eines havarierten Systems auf ein überlebendes, ist das wichtigste Prinzip eines Hochverfügbarkeits-Clusters. Damit der Failover funktioniert, benötigt man eine zentrale Software, die die Steuerung des Clusters übernimmt. Im Fachjargon heißt diese Software Cluster Manager. Ihre Hauptaufgabe ist es, alle Knoten eines Clusters auf Verfügbarkeit zu überprüfen. Darüber hinaus soll sie auch erkennen, wenn womöglich nur einzelne Programme auf einem ansonsten noch erreichbaren Knoten abgestürzt sind.

Ressourcen-Management und Kommunikation

Klassischerweise unterteilt sich das Cluster-Management in die beiden Komponenten Cluster Communication Management (CCM) und Cluster Resource Management (CRM). Für Linux steht mit Pacemaker ein reinrassiger Cluster Resource Manager zur Verfügung, der wahlweise mit den Cluster Communication Managern Corosync oder Heartbeat 3 betrieben werden kann (siehe auch Kasten "Die Geschichte von Pacemaker"). Pacemaker empfängt im Zusammenspiel von Heartbeat oder Corosync Informationen über die zwei oder mehr Knoten, überwacht deren Ressourcen und greift im Falle eines Fehlers ein.

Die Geschichte von Pacemaker

Wenn Sie sich schon mit dem Thema Cluster-Management unter Linux auseinandergesetzt haben, sind Ihnen vermutlich diverse Begriffe begegnet. Heartbeat, Pacemaker, Corosync, OpenAIS – Einsteigern fällt es oft schwer, zwischen den einzelnen Lösungen zu unterscheiden (Abbildung 6). Welche Komponente beherrscht welche Funktionen? Der folgende historische Abriss gibt einen Überblick über die wichtigsten Stationen von HA-Lösungen unter Linux.

Abbildung 6: Wie aus Heartbeat 1

Pacemaker wurde: Die Grafik gibt einen Überblick über rund elf Jahre Entwicklungsarbeit.

Grundsätzlich gilt: Linux hinkte sehr lange hinter anderen Systemen her, wenn es um das Thema Clustering ging. So steht beispielsweise Suns Cluster Suite für Solaris seit über 15 Jahren zur Verfügung. Andere Cluster-Manager wie Veritas haben eine ähnlich lange Versionsgeschichte. Linux hingegen konnte erst 1998 zum ersten Mal auf so etwas Ähnliches wie einen Cluster-Manager zurückgreifen: Heartbeat 1. Ursprünglich kam die Initiative von Alan Robertson, einem IBM-Entwickler. Dieser hatte sich bereits mit dem Thema Clustering beschäftigt und eine beachtliche Sammlung von Shellscripts verfasst. Für Heartbeat 1 fügte er diese zu einem Paket zusammen und schrieb einige Zeilen C-Code dazu, der diese Scripts in passender Reihenfolge aufrief und dafür sorgte, dass die Clusterknoten miteinander kommunizieren konnten.

Heartbeat 1 war allerdings in vielerlei Hinsicht sehr beschränkt. Zum einen war die im Artikel angesprochene Trennung zwischen den zwei Cluster-Komponenten – Ressourcen-Management und Cluster-Kommunikation – bei Heartbeat 1 auf Code-Ebene nicht umgesetzt. Stattdessen war die erste Heartbeat-Version ein großer monolithischer Code-Block. Auch im Hinblick auf die unterstützten Features war Heartbeat 1 als Lösung für Cluster-Management im Enterprise-Einsatz praktisch uninteressant. Denn es merkte zwar, wenn einer der vorhandenen Cluster-Knoten ausfiel, und konnte einen Failover initiieren. Ging dabei aber etwas schief, dann stoppte der Cluster-Manager alle Cluster-Ressourcen, und ein Eingreifen des Administrators war unvermeidlich. Außerdem fehlten überaus wichtige Features wie die Möglichkeit, einen Dienst innerhalb des Clusters zu überprüfen (Monitoring) und ihn neu zu starten, sollte er abgestürzt sein.

Red Hat war an Heartbeat 1 übrigens überhaupt nicht beteiligt; die Red Hat Cluster Suite, die bis heute Bestandteil von Red Hat Enterprise Linux ist, lag in Alpha-Versionen bereits 1996 vor und wurde seither konsequent weiterentwickelt.

Die technischen Unzulänglichkeiten von Heartbeat 1 glich später in den Augen vieler Admins ein neues Heartbeat 2 aus. Das kam allerdings erst 2005. Denn besonders dadurch, dass es immer wieder zu Meinungsverschiedenheiten zwischen Robertson und der Linux-HA Community kam, war es schwierig, einen gemeinsamen Nenner zu finden. Heartbeat 2 war letztlich in einer Art feindlicher Übernahme zu großen Teilen von Mitgliedern der HA-Community erarbeitet worden, Robertson spielte bei der Entwicklung letztendlich nur noch eine Nebenrolle.

Heartbeat 2 räumte zwar einige der Probleme aus, die Heartbeat 1 das Leben schwer gemacht hatten. Denn Heartbeat 2 führte die Trennung von Ressourcen- und Kommunikationsmanagement auf Code-Ebene ein und hatte erstmals Enterprise-Funktionen wie das Überwachen von Diensten. Das vermag aber nicht darüber hinwegzutäuschen, dass Heartbeat 2 bei seinem Erscheinen bereits veraltet war. Denn in den 6 Jahren zwischen den beiden Releases war in Sachen Hochverfügbarkeit einiges fernab von Linux-HA passiert.

Bereits 2001 hatte sich das Service Availability Forum gegründet, ein Industrie-Konsortium verschiedener großer Anbieter, das einen grundlegenden Standard für die Kommunikation in Multi-Node-Clustern schaffen wollte. Die erste Definition dieses Standards lag 2003 vor, gemeint ist die »Application Interface Specification « , kurz »AIS « .

Außerdem hatte Novell Ende 2003 den deutschen Linux-Distributor SUSE gekauft und wollte SUSE-Linux als Enterprise-Produkt in seine eigene Produktpalette einbauen. Schlagartig war damit auch bei SUSE ein sehr großes Interesse an HA-Diensten entstanden.

Zunächst lag nach der Veröffentlichung des AIS-Standards aber der Ball bei Red Hat. Red Hat stellte einen Entwickler ab, der den nunmehr verfügbaren Standard auf Code-Ebene umsetzen sollte. 2005 erschien die erste freie Implementierung von AIS, die auf den Namen »OpenAIS « hört. Schon damals war das Ziel, die Red Hat Cluster Suite auf den neuen Standard umzurüsten.

Schließlich ergriff Novell die Initiative: Mit Heartbeat 2 hatte man einen Cluster-Manager, der mittlerweile im Enterprise-Umfeld zu gebrauchen war. Obendrein war Heartbeat 2 auf Code-Ebene sinnvoll zu trennen – der Cluster Resource Manager und der Cluster Communication Manager waren separate Teile und leicht voneinander abzukoppeln. Das Unternehmen gab dem Australier Andrew Beekhof den Auftrag, den CRM aus Heartbeat 2 auf OpenAIS lauffähig zu machen. Das Resultat dieser Arbeit ist Pacemaker.

Durchaus bemerkenswert ist, dass Beekhof Pacemaker von Anfang an so konzipiert hat, dass er auch heute noch mit dem Cluster Communication Manager von Heartbeat 2 arbeiten kann. Dieser firmiert mittlerweile als Heartbeat 3. Bei Heartbeat 3 handelt es sich also nicht mehr um einen vollständigen Cluster-Manager.

Die letzte Wendung der Geschichte vom Clustering unter Linux wurde von Red Hat im Jahre 2007 initiiert, hat aber eher geringe Auswirkungen: Der Distributor beschloss, dass ihm OpenAIS als einzelnes Projekt zu groß ist, und spaltete OpenAIS nochmals auf – aus dem Projekt wurden die Komponenten, die sich ausschließlich mit der Cluster-Kommunikation beschäftigen, in ein eigenes Projekt namens Corosync ausgelagert. Als Ironie der Geschichte muss gelten, dass die übrigen Teile von OpenAIS nicht mehr weiterentwickelt werden – OpenAIS ist praktisch tot.

Damit steht fest: Wer gegenwärtig mit Linux-Systemen einen Cluster konstruieren möchte, nimmt dafür eine Kombination aus Pacemaker (Cluster Resource Manager) und entweder Corosync oder Heartbeat (Cluster Communication Manager).

Die Installation von Pacemaker fällt je nach Linux-Version unterschiedlich aus. Debian und Ubuntu liegen fertige Pakete bei. Wer RHEL 6 nutzt, braucht Red Hats HA-Addon; ganz ähnlich verhält es sich mit SLES: Auch hier ist der Erwerb der SUSE Linux High Availability Extension notwendig. Für andere Distributionen ist vermutlich Handarbeit angesagt. In allen

Fällen heißt das Paket, das Pacemaker enthält, allerdings »pacemaker « – es installiert benötige Software gleich mit.

Admins stehen zu Beginn der Installation vor der Entscheidung: Soll Pacemaker mit dem Heartbeat-3-CCM oder dem Corosync-CCM laufen? Im Alltag gibt es zwar kaum Funktionsunterschiede, doch beide Ansätze haben ihr Für und Wider.

Soll eine Applikation zum Einsatz kommen, die den DLM, also den Distributed Locking Manager, verwendet, ist Corosync Pflicht, denn Heartbeat unterstützt die Kommunikation mit dem DLM nicht. Auch wer ein Cluster-Setup auf Grundlage von RHEL oder SLES mit dem entsprechenden HA-Addon konstruiert, kommt nicht an Corosync vorbei; denn hier ist Corosync die einzige offiziell unterstützte Lösung. Wer aber Ubuntu oder Debian nutzt, kann sich zwischen Heartbeat und Corosync entscheiden.

Andere Gründe sprechen für Heartbeat: Es unterstützt seit jeher das Unicast-Protokoll für die Cluster-Kommunikation. Corosync kann das erst seit der aktuellen Version 1.3.0 – frühere Versionen kommunizierten nur per Multicast, was zu Naserümpfen bei Netzwerkern führt.

Außerdem bietet Corosync keine Unterstützung für den automatischen Wiederaufbau des Kommunikationspfads zwischen zwei Knoten. Das Feature heißt Automatic Link Recovery und ist bei Heartbeat Standard. Corosync dagegen merkt nichts davon, wenn der Kommunikationspfad zwischen zwei Knoten ausfällt und später wieder in Gang kommt. Es bedarf händischer Intervention.

Cluster-Praxis

Grau ist alle Theorie – der beste Weg, um Pacemaker zu verstehen, besteht darin, mit ihm zu arbeiten. Das Konfigurationsbeispiel dieses Artikels dreht sich um einen Zwei-Knoten-Cluster. Zwar sind theoretisch bis zu 255 Knoten möglich, real dürfte die Grenze des Machbaren aber bei rund 40 liegen.

Wenn man sich noch nicht für Corosync oder Heartbeat entschieden hat, ist diese Entscheidung jetzt fällig. Denn Pacemaker lässt sich nicht direkt von der Kommandozeile aus starten. Stattdessen handelt es sich bei ihm immer um ein Plugin, das entweder von Heartbeat oder von Corosync nachgeladen wird. Zuvor sind also immer Corosync oder eben Heartbeat zu installieren.

Die Corosync-Konfiguration

Alle großen Distributoren liefern bei ihren Corosync-Paketen die von den Autoren zur Verfügung gestellte Standard-Konfiguration mit. Das ist vor allem deshalb sehr praktisch, weil darin nur eine einzige Zeile zu verändern ist, damit Corosync läuft. Corosyncs Konfigurationsdatei ist »/etc/corosync/corosync.conf « (Abbildung 1); in der Standardversion dieser Datei findet sich ein einzelner Eintrag für einen Kommunikationsstring, der allerdings auf die Loopback-Adresse 127.0.0.1 konfiguriert ist. Hinter »bindnetaddr « in diesem »interface « -Eintrag gehört die Adresse eines Netzwerkes, über das die beiden Clusterknoten miteinander reden. Ist die Änderung vollzogen, kopiert man die Datei auf den anderen Knoten. Im Anschluss erstellt »corosync-

keygen « einen Authentifizierungsschlüssel in »/etc/corosync/authkey « , der ebenfalls auf den anderen Knoten zu kopieren ist. Danach genügt es, Corosync zu starten. Unter Debian

oder Ubuntu ist gegebenenfalls vorher noch in der Datei »/etc/default/corosync « Corosync zu aktivieren.

Abbildung 1: In den Ordnern

Übrigens: Wer einen zweiten Kommunikationsring verwenden will, kann einen »interface « -Eintrag nach dem Muster des bereits vorhandenen Absatzes hinzufügen, muss diesem aber eine entsprechend erhöhte »ringnumber « sowie eine andere Multicast-Adresse angeben. Außerdem ist in diesem Falle der Wert hinter »rrp_mode « auf »active « zu setzen.

Heartbeat konfigurieren

Wer statt Corosync lieber Heartbeat verwendet, bearbeitet für die Funktion des Cluster Communication Managers vor allem »ha.cf « in »/etc/ha.d « . Im Standard-Lieferumfang für Heartbeat fehlt diese Datei leider vollständig, sodass sie erst händisch anzulegen ist. Im Listing 1 finden Sie ein vollständiges Beispiel. Die einzelnen Zeilen haben diese Funktionen:

Listing 1

Exemplarische ha.cf

01 keepalive 2 02 warntime 20 03 deadtime 30 04 initdead 30 05 logfacility local0 06 bcast ethx 07 mcast br0 225.0.0.41 694 1 1 08 node alice 09 node bob 10 autojoin none 11 crm yes

• »keepalive 2 « sorgt dafür, dass Heartbeat alle 2 Sekunden alle anderen Cluster-Knoten

anpingt und auf Antwort wartet. Kommt auf diese Pings keine Antwort, schreibt Heartbeat

mit »warntime 20 « nach 20 Sekunden eine entsprechende Warnung ins Logfile. Nach 30

Sekunden erklärt Heartbeat einen Link zu einem Clusterknoten für tot, wenn »deadtime

30« gesetzt ist.

• »initdead 30 « legt fest, dass Heartbeat nach dem Programmstart bis zu 30 Sekunden wartet, bis alle festgelegten Clusterknoten vorhanden sind.

• »logfacility local0 « legt die Syslog-Facility fest, die Meldungen von Heartbeat

erhalten sollen.

• »bcast ethx « sowie »mcast br0 ... « legen die Kommunikationspfade fest, die

Heartbeat verwenden darf.

• »node alice « und »node bob « definieren von vornherein, welche Knoten im Cluster vorhanden sind.

• »autojoin none « verhindert, dass andere Clusterknoten automatisch in den Cluster-Verbund aufgenommen werden, ohne in der Konfigurationsdatei zu stehen.

• »crm yes « aktiviert Pacemaker. An dieser Stelle könnte auch »crm respawn « stehen. Der

Unterschied zwischen »yes « und »respawn « ist, dass bei Ersterem Heartbeat einen Reboot

des Servers initiiert, falls »crmd « unerwartet abstürzt. Mit »respawn « wird Pacemaker einfach neu gestartet.

Auch Heartbeat wünscht sich einen Authentifizierungsschlüssel, um sich bei den anderen Clusterknoten vorstellen zu können. Der Schlüssel liegt in »/etc/ha.d/authkeys « , bei Heartbeat gibt es aber kein Werkzeug, das diese Datei anlegt. Ein Beispiel – alle Teile mit Ausnahme von foobar sind zu übernehmen – könnte so aussehen:

auth 2 2 sha1 foobar

Ist »authkeys « an ihrem angestammten Platz, startet »/etc/init.d/heartbeat « Heartbeat sowie Pacemaker. Ob Pacemaker läuft, ist mit der obigen Konfiguration nach ungefähr einer Minute daran zu erkennen, dass »crm_mon -1 -rf « beide Clusterknoten als »online « sieht.

Kommunikationspfade

Ein abschließendes Wort zur Cluster-Konfiguration – grundsätzlich gilt: Die Knoten eines Clusters sollten redundant miteinander kommunizieren können, also mindestens zwei voneinander unabhängige Kommunikationspfade zur Verfügung haben. Falls ein Kommunikationspfad stirbt, steht der andere noch immer zur Verfügung. Sowohl Heartbeat als auch Corosync unterstützen Setups mit zwei Kommunikationspfaden. Achten Sie darauf, dass bei mindestens einem Kommunikationspfad eine direkte Verbindung zwischen den zwei Clusterknoten existiert – also eine, die nicht durch Switches geht. Wenn DRBD im Cluster zum Einsatz kommt, kann der zweite Pfad auch einen eventuellen Back-to-Back-Link verwenden.

Ressourcen

Zentral ist im Pacemaker-Kontext der Begriff der Ressource. Er wird einem im Cluster-Kontext immer wieder begegnen. Er meint nichts anderes als einen Dienst, der von Pacemaker verwaltet wird. Es kann sich also um eine DRBD-Ressource handeln, um eine MySQL-Instanz oder auch um eine IP-Adresse.

Pacemaker selbst ist der Ressourcen-Manager – aber wie wickelt er das Management von Ressourcen eigentlich ab? Wenn Pacemaker den Dienst MySQL starten soll, ruft das Programm nicht »/usr/sbin/mysqld « mit den passenden Parametern auf. Stattdessen bedient er sich einer eigenen Shell-basierten API. Außerdem verwendet Pacemaker einige Wasserträger, die ihm das Starten und Stoppen von Ressourcen abnehmen. Die Abbildung 2 zeigt, wie Dienste von Pacemaker gestartet werden.

Abbildung 2: Pacemaker startet eine

Applikation via Cluster Resource Manager, Local Resource Manager und Resource Agent.

Pacemaker, der – einmal gestartet – in der Prozess-Tabelle als »crmd « erscheint, läuft auf jedem Clusterknoten. Zusätzlich dazu läuft ebenso auf jedem Clusterknoten der Dienst »lrmd « , der »Local Resource Management Daemon « . Die einzige Aufgabe des LRMDs ist es, Befehle von Pacemaker auf der einen Seite entgegenzunehmen und im Anschluss Shell-Skripte aufzurufen, um den von Pacemaker gewünschten Vorgang durchzuführen.

Diese Shell-Skripte nennen sich im Cluster-Jargon »Resource Agents « . Sie sind dafür verantwortlich, das passende Binary mit den konfigurierten Parametern aufzurufen. Pacemaker unterstützt momentan drei Arten eben dieser Resource Agents: Zum einen Heartbeat-1-kompatible Agents, die allerdings als veraltet gelten, außerdem unterstützt es LSB-Agents, die gemeinhin auch als Init Scripts bezeichnet werden und schließlich gibt es noch die Königsklasse der Resource Agents: OCF-basierte Agents (Abbildung 3). Sie verwenden einen eigenen Standard, der speziell für die Benutzung im Cluster gestaltet worden ist. Grundsätzlich gilt: Damit ein Skript in Pacemaker als Resource-Agent eingesetzt werden kann, muss es mindestens die Parameter »start « , »stop « und »monitor « kennen. Vorsicht ist auf Debian-Systemen geboten, denn viele Init-Skripte bei Debian kennen das »monitor « -Argument nicht.

Abbildung 3: Die OCF-Resource-Agents

liegen typischerweise im Ordner

OCF-Resource-Agents weisen im Gegensatz zu den beiden anderen Gruppen eine Besonderheit auf, denn sie gehören jeweils zu einem eigenen »Provider « , sind also nochmals in Gruppen aufgeteilt. Der DRBD-Resource-Agent kommt vom Provider »linbit « , der Resource-Agent für das Mounten von Dateisystemen kommt vom Anbieter »heartbeat « . Die Anbieter der am häufigsten genutzten Resource Agents werden schnell geläufig. Und das ist gut so – wer regelmäßig Pacemaker-Cluster administriert, sollte sich jedenfalls die Namen der drei Kategorien sowie die Bezeichnung der wichtigsten OCF Resource Agents sehr gut merken.

Kommunikationspfade

Ein abschließendes Wort zur Cluster-Konfiguration – grundsätzlich gilt: Die Knoten eines Clusters sollten redundant miteinander kommunizieren können, also mindestens zwei voneinander unabhängige Kommunikationspfade zur Verfügung haben. Falls ein Kommunikationspfad stirbt, steht der andere noch immer zur Verfügung. Sowohl Heartbeat als auch Corosync unterstützen Setups mit zwei Kommunikationspfaden. Achten Sie darauf, dass bei mindestens einem Kommunikationspfad eine direkte Verbindung zwischen den zwei Clusterknoten existiert – also eine, die nicht durch Switches geht. Wenn DRBD im Cluster zum Einsatz kommt, kann der zweite Pfad auch einen eventuellen Back-to-Back-Link verwenden.

Ressourcen

Zentral ist im Pacemaker-Kontext der Begriff der Ressource. Er wird einem im Cluster-Kontext immer wieder begegnen. Er meint nichts anderes als einen Dienst, der von Pacemaker verwaltet wird. Es kann sich also um eine DRBD-Ressource handeln, um eine MySQL-Instanz oder auch um eine IP-Adresse.

Pacemaker selbst ist der Ressourcen-Manager – aber wie wickelt er das Management von Ressourcen eigentlich ab? Wenn Pacemaker den Dienst MySQL starten soll, ruft das Programm nicht »/usr/sbin/mysqld « mit den passenden Parametern auf. Stattdessen bedient er sich einer eigenen Shell-basierten API. Außerdem verwendet Pacemaker einige Wasserträger, die ihm das Starten und Stoppen von Ressourcen abnehmen. Die Abbildung 2 zeigt, wie Dienste von Pacemaker gestartet werden.

Abbildung 2: Pacemaker startet eine

Applikation via Cluster Resource Manager, Local Resource Manager und Resource Agent.

Pacemaker, der – einmal gestartet – in der Prozess-Tabelle als »crmd « erscheint, läuft auf jedem Clusterknoten. Zusätzlich dazu läuft ebenso auf jedem Clusterknoten der Dienst »lrmd « , der »Local Resource Management Daemon « . Die einzige Aufgabe des LRMDs ist es, Befehle von Pacemaker auf der einen Seite entgegenzunehmen und im Anschluss Shell-Skripte aufzurufen, um den von Pacemaker gewünschten Vorgang durchzuführen.

Diese Shell-Skripte nennen sich im Cluster-Jargon »Resource Agents « . Sie sind dafür verantwortlich, das passende Binary mit den konfigurierten Parametern aufzurufen. Pacemaker unterstützt momentan drei Arten eben dieser Resource Agents: Zum einen Heartbeat-1-kompatible Agents, die allerdings als veraltet gelten, außerdem unterstützt es

LSB-Agents, die gemeinhin auch als Init Scripts bezeichnet werden und schließlich gibt es noch die Königsklasse der Resource Agents: OCF-basierte Agents (Abbildung 3). Sie verwenden einen eigenen Standard, der speziell für die Benutzung im Cluster gestaltet worden ist. Grundsätzlich gilt: Damit ein Skript in Pacemaker als Resource-Agent eingesetzt werden kann, muss es mindestens die Parameter »start « , »stop « und »monitor « kennen. Vorsicht ist auf Debian-Systemen geboten, denn viele Init-Skripte bei Debian kennen das »monitor « -Argument nicht.

Abbildung 3: Die OCF-Resource-Agents

liegen typischerweise im Ordner

OCF-Resource-Agents weisen im Gegensatz zu den beiden anderen Gruppen eine Besonderheit auf, denn sie gehören jeweils zu einem eigenen »Provider « , sind also nochmals in Gruppen aufgeteilt. Der DRBD-Resource-Agent kommt vom Provider »linbit « , der Resource-Agent für das Mounten von Dateisystemen kommt vom Anbieter »heartbeat « . Die Anbieter der am häufigsten genutzten Resource Agents werden schnell geläufig. Und das ist gut so – wer regelmäßig Pacemaker-Cluster administriert, sollte sich jedenfalls die Namen der drei Kategorien sowie die Bezeichnung der wichtigsten OCF Resource Agents sehr gut merken.

Stonith und das Quorum

Ein Zwei-Knoten-Cluster wie im Beispiel leidet unter einem Problem, das sich auf das sogenannte Quorum bezieht. Das Quorum im Cluster-Kontext ist die Zahl der Clusterknoten, die mindestens vorhanden sein müssen, damit der Cluster-Manager den Cluster für funktional hält. Im Normalfall existieren zwei Knoten, und ein Quorum ist gegeben. Fällt allerdings ein Knoten aus, wäre kein Quorum mehr da. Pacemaker würde in der Standardkonfiguration alle Ressourcen anhalten und auf ein neues Quorum warten. Der Effekt ist freilich ungewollt. Deshalb gilt es, bei einem frischen Pacemaker-Cluster diesen Effekt abzustellen.

Ein entsprechender »property « -Eintrag existiert; er heißt »no-quorum-policy « . Der nötige Wert ist »ignore « . Er lässt sich mithilfe der CRM-Shell setzen: Mittels »crm configure « landet man direkt im Konfigurationsmodul von Pacemaker; der passende Befehl lautet danach » property no-quorum-policy="ignore" « . Übrigens: Die CRM-Shell unterstützt die automatische Komplettierung mittels [TAB] – hinter »no-quorum-policy= « hätte die CRM-Shell mit [TAB] beispielsweise alle möglichen Parameter aufgelistet, die für diesen Konfigurationswert vorhanden sind.

Für das Beispiel ist eine zweite Konfigurationsänderung notwendig, die sich auf STONITH bezieht. STONITH heißt »Shoot The Other Node In The Head « ; es handelt sich um einen Fencing-Mechanismus, der es Pacemaker auf einem Knoten des Clusters erlaubt, den anderen Knoten neu zu starten, sollte dieser Probleme verursachen. STONITH ist insbesondere im Kontext von Datensicherheit wichtig, weil sie verhindert, dass mehrere Knoten zeitgleich zum Beispiel dieselben Platten mounten. Dafür wird das konkurrierende System gewaltsam angehalten,

Die Technik wird üblicherweise mittels IPMI- oder ILO-Karten realisiert; aber auch andere Varianten existieren. In einem 2-Knoten-Cluster ist STONITH nicht zwingend notwendig – gerade dann nicht, wenn die Cluster-Knoten mehrere und voneinander unabhängige Kommunikationspfade haben. Im Beispiel bleibt es daher deaktiviert. Das geht mit »property stonith-enabled="false" « – ebenfalls im »configure « -Menü der CRM-Shell.

Die Änderung der Quorum-Policy sowie der STONITH-Funktion sind schließlich in den Cluster-Manager mittels »commit « zu übermitteln – das gilt für alle Änderungen, die wie beschrieben im »crm configure « -Menü der Shell ausgeführt werden.

Die erste Ressource

Grundsätzlich ist Pacemaker jetzt einsatzbereit – Gelegenheit, die erste Ressource in die Clusterkonfiguration zu übernehmen. Einzelne Ressourcen sind in Pacemaker stets »primitive « -Ressourcen; der Befehl, um sie in die CIB einzubauen, heißt genauso und gehört zum »configure « -Menü der CRM-Shell. Er kennt verschiedene Parameter und Optionen. Grundsätzlich hat er folgende Syntax:

primitive Name_der_Ressource RA-Klasse[:Provider]: Name-des-RA params Parameter

• Name der Ressource ist eine frei wählbare Zeichenkette. Die komplette Bezeichnung des

Ressource-Agents mag umständlich wirken, ist aber notwendig, um OCF-Agents

entsprechend abbilden zu können.

• RA-Klasse kann derzeit entsprechend der Erklärung weiter oben entweder »heartbeat « ,

»lsb « oder »ocf « sein. • Provider kommt nur bei OCF-Agents zum Einsatz und bezeichnet den Provider, der zu einem

OCF-Agent gehört – die eckigen Klammern sind in diesem Falle wegzulassen.

• Name des RA ist selbsterklärend.

• Das Schlüsselwort »params « legt Parameter fest, die sich auf die Konfiguration des Resource Agents beziehen.

[Tab] führt zu einer Übersicht aller Parameter, die der jeweilige Ressource-Agent unterstützt. Auch bei der Angabe des RAs ist es übrigens für jedes der drei Felder möglich, sich mit [Tab] eine Liste aller verfügbaren Einträge anzeigen zu lassen. Das hilft, falls der Name eines RAs nicht oder nur ungefähr bekannt ist.

Ein praktisches Beispiel: Pacemaker soll sich um die Verwaltung einer IP-Adresse kümmern. Der entsprechende Ressource-Agent dafür heißt »IPaddr2 « ; er ist ein OCF-Resource Agent vom Provider »heartbeat « und benötigt mindestens zwei Parameter – die eigentliche IP-Adresse und die Netmask dieser IP. Die passende Konfigurationszeile Zeile könnte so aussehen:

primitive p_ip1 ocf:heartbeat:IPaddr2 params ip=192 .168.0.10 cidr_netmask=24

Diese Konfigurationszeile führt dazu, dass Pacemaker im Falle eines Failovers die IP auf dem jeweils verbliebenen Cluster-Knoten mit genau diesen Parametern starten würde. Noch nicht abgedeckt ist im Beispiel die Situation, dass die IP-Adresse aus irgendwelchen Gründen von dem System, auf dem sie läuft, verschwindet. Es ist deshalb notwendig, die Ressource-Definition um eine »Operation « zu erweitern – nämlich um eine Monitoring-Operation. In

Ressource-Definitionen leiten sich Operationen mit dem Schlüsselwort »op« ein. Anders als bei den Parametern, wo nur einmal »params « steht, ist jede Operation mit »op« einzuleiten. Um dafür zu sorgen, dass Pacemaker in einem Interval von 15 Sekunden überprüft, ob die IP noch existiert, reicht es, am Ende der Zeile oben »op monitor interval=15s « einzufügen. Das sorgt für Ressourcen-Monitoring. Nach dem Hinzufügen einer Primitive-Ressource schaltet Pacemaker die neue Konfiguration durch »commit « scharf.

Statusinformationen über den Cluster sind für den Administrator wichtig. Mit »crm_mon« (Abbildung 4) steht ein Werkzeug zur Verfügung, um sich schnell einen Überblick über den Zustand des Systems zu verschaffen (Abbildung 5). »crm_mon -1 « zeigt den gegenwärtigen Zustand an und beendet sich danach wieder. Dagegen führt »crm_mon« zu einer Cluster-Konsole, die jeder neue Event aktualisiert. Erweitert um die Parameter »-rf « zeigt der CRM-Monitor auch Fehler sowie deaktivierte Ressourcen an.

Abbildung 5: Mittels des Werkzeugs

Abbildung 4: crm_mon

Im Cluster aufräumen

So wichtig wie das Hinzufügen von Ressourcen ist das Aufräumen des Clusters, wenn beim Hinzufügen etwas schiefgegangen ist. Wenn nämlich schon der erste Start einer Ressource auf einem Knoten fehlschlägt, unternimmt Pacemaker keine weiteren Versuche. Dann ist es nötig, die jeweilige Ressource mittels »crm resource cleanup Name« von der Shell aus aufzuräumen. Pacemaker setzt dann den »failcount « auf » « , vergisst also quasi, dass die Ressource nicht gestartet werden konnte. Ob das Aufräumen funktioniert hat, ist wiederum mittels »crm_mon -rf « herauszufinden.

Was kommt

Dieser einleitende Artikel kratzte nur an der Oberfläche dessen, was Pacemaker leisten kann. Die nächsten Teile der HA-Serie beschäftigen sich mit der Integration von DRBD-Ressourcen in Pacemaker und mit Abhängigkeiten zwischen einzelnen Ressourcen. Der dritte Artikel wird die Schaffung eines hochverfügbaren MySQL-Servers unter Verwendung von DRBD und Pacemaker beispielhaft demonstrieren. Der vierte Artikel beschäftigt sich mit dem Thema Virtualisierung im Clusterkontext.

BitWorld bitworld.de. Abgerufen am 03. 06 2013 von

http://www.bitworld.de/index.php/grundlagen/soap

Simple Object Access Protocol (SOAP)

Grundlagen - SOAP

Geschrieben von: Christian Jänicke

Samstag, 23. Januar 2010

WebServices verwenden das Simple Object Access Protocol (SOAP) als Kommunktationsprotokoll. SOAP ist ein auf XML basierendes Format, um Nachrichten zu versenden und ist sowohl Plattform- wie auch Sprachunabhängig.

Aufbau einer SOAP-Nachricht

Eine SOAP-Nachricht ist eine einfache XML-Struktur, die folgende Elemente enthält bzw. enthalten kann:

• ein Envelope Element

• ein Header Element (optional)

• ein Body Element mit optionalem Fault Element

Desweiteren unterliegen SOAP-Nachrichten bestimmten Einschränkungen, die im Folgenden zusammengefasst sind:

• Jede SOAP-Nachricht muss ein gültiges XML-Dokument sein

• Alle SOAP-Elemente müssen in folgendem Namespace deklariert sein: http://www.w3.org/2001/12/soap-envelope/

• Alle SOAP-Datentypen müssen in folgendem Namensraum deklariert sein: http://www.w3.org/2001/12/soap-encoding/

• In einer SOAP-Nachricht darf keine Dokumenttyp-Deklaration (DTD) enthalten sein

• In einer SOAP-Nachricht dürfen keine XML Processing Instructions enthalten sein

Beispiel:

<?xml version="1.0"?> <soap: Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelop e/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" soap:encodingStyle="http://www.w3.org/2001/12/s oap-encoding/"> <soap: Header> ... </soap: Header> <soap: Body> ... </soap: Body> </soap: Envelope>

Element: Envelope

Das Envelope Element ist das Wurzelelement einer SOAP-Nachricht und darf nur einmal pro Nachricht definiert werden. Jede SOAP-Nachricht muss ein Envelope Element enthalten.

Element: Header

Das Header Element ist optional und muss, sofern angegeben, das erste Element innerhalb des Envelope Elements sein. Im Header Element können beliebige Einträge abgelegt werden. Typischer weise enthalten Header Elemente Transaktionsdaten, Zugriffsdaten (Benutzername, Kennwort) oder Routinginformationen. Die Header Einträge müssen durch einen eigenen Namensraum (Namespace) deklariert werden.

<?xml version="1.0"?> <soap: Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelop e/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" soap:encodingStyle="http://www.w3.org/2001/12/s oap-encoding/" xmlns:myapp="http://www.bitworld.de/myapp/"> <soap: Header> <myapp:Authentication> <myapp:Username>chris</myapp:Username> <myapp:Password>encrypted</myapp:Password> </myapp:Authentication> </soap: Header> <soap: Body> ... </soap: Body> </soap: Envelope>

In dem Header Element können die Einträge durch zusätzliche SOAP-Attribute spezifiziert werden.

Attribut (Header Eintrag): actor

Eine SOAP-Nachricht kannüber verschiedene Knotenpunkte (Server) weitergereicht werden. Mit den Attribut actor kann ein Header Eintrag für einen bestimmten Knotenpunkt zur Auswertung markiert werden, d.h. nur der angegebene Knoten darf den Eintrag auswerten, alle anderen Knoten müssen diesen ignorieren. Der Attributwert ist entweder der URI des Knotenpunkttes, für den der Eintrag bestimmt ist, oder der reserviert URI http://schemas.xmlsoap.org/soap/action/next , welcher den aktuellen Knoten zur Auswertung des Header Eintrag auffordert.

Hat der aktuelle Knoten den Header Eintrag ausgeführt und ist er nicht der Zielknoten der SOAP-Nachricht, so werden alle für den aktuellen Knoten bestimmten Header Einträge aus der Nachricht entfernt und die Nachricht wird an den nächsten Knoten weitergeleitet.

<?xml version="1.0"?> <soap: Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelop e/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" soap:encodingStyle="http://www.w3.org/2001/12/s oap-encoding/" xmlns:myapp="http://www.bitworld.de/myapp/"> <soap: Header> <myapp:Authentication soap:actor="http://www.bitworld.de/auth/"> <myapp:Username>chris</myapp:Username> <myapp:Password>encrypted</myapp:Password>

</myapp:Authentication> </soap: Header> <soap: Body> ... </soap: Body> </soap: Envelope>

Attribut (Header Eintrag): mustUnderstand

Mit dem Attribut mustUnderstand kann ein Header Eintrag als zwingend notwendig gekennzeichnet werden. Der Empfänger der SOAP-Nachricht muss diesen Header Eintrag auswerten können, sonst muss der Empfänger die Nachricht ablehnen. Ein Wert von 1 kennzeichnet den Eintrag als zwingend notwendig, ein Wert von 0 kennzeichnet den Eintrag als optional.

Attribut (Header Eintrag): encodingStyle

Das Attribut encodingstyle definiert die Datentypen, die für den angegebenen Header Eintrag gültig sind.

Element: Body

In dem Body Element ist die eigentliche Nachricht enthalten. Alle Elemente der Nachricht sollten durch einen eigenen Namensraum gekennzeichnet werden.

<?xml version="1.0"?> <soap: Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelop e/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" soap:encodingStyle="http://www.w3.org/2001/12/s oap-encoding/" xmlns:myapp="http://www.bitworld.de/myapp/"> <soap: Body> <myapp:SayHello> <myapp:Name>Christian</myapp:Name> </myapp:SayHello> </soap: Body> </soap: Envelope>

Element: Fault

Es gibt ein spezielle Element, welches im Body angegeben werden kann: das Fault Element. Fault Elemente kennzeichnen Fehler, die bei der Verarbeitung der Nachricht aufgetreten sind. Folglich werden Fault Elementüberlicherweise in Antwort-Nachrichten angegeben, um den Sender der Nachrichtüber aufgetretene Fehler zu informieren.

Das Fault Element verfügtüber vier weitere Unterelemente:

Element (Fault): faultcode

Das Element faultcode gibt den Fehlercode des Fehlers an, der Aufgetreten ist. Es gibt vier mögliche Wert:

VersionMismatch Zeigt an, dass für das Envelope Element ein ungültiger Namensraum

angegeben wurde. (Der Namensraum definiert die SOAP Version)

MustUnderstand Ein mit dem Attribut mustUnderstand gekennzeichneter Header Eintrag kann

von dem aktuellen Knoten nicht verarbeitet werden.

Client Die SOAP-Nachricht konnte nicht verarbeitet werden.

Server Es ist ein interner Server-Fehler aufgetreten.

Element (Fault): faultstring

In dem Element faultstring kann eine Fehlerbeschreibung angegeben werden.

Element (Fault): faultactor

Das Element faultactor enthält die URI des Knotens, bei dem der Fehler aufgetreten ist.

Element (Fault): detail

In dem Element detail können zusätzliche Informationen zum Fehler angegeben werden (auch in XML-Form).

<?xml version="1.0"?> <soap: Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelop e/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" soap:encodingStyle="http://www.w3.org/2001/12/s oap-encoding/" xmlns:myserver="http://www.bitworld.de/myserver/"> <soap: Body> <soap: Fault> <soap: faultcode>Server<soap: /faultcode> <soap: faultstring>Too few parameters<soap: /faultstring> <soap: detail> <myserver:details> <myserver:message>Please enter your name< /myserver:message> </myserver:details> </soap: detail> </soap: Fault> </soap: Body> </soap: Envelope>

BSI

BSI.Bund.de. Abgerufen am 04. 06 2013 von https://www.bsi.bund.de/DE/Themen/SmartMeter/Schutzprofil_Security/security_module_node.html

Schutzprofil für das Sicherheitsmodul eines Smart Meter Gateways (BSI-CC-

PP-0077)

In einem intelligenten Messsystem bildet das Smart Meter Gateway (SMGW) die zentrale Kommunikationseinheit, die Messdaten von Zählern empfängt, speichert und diese für autorisierte Marktteilnehmer aufbereitet. Das SMGW ist damit eine wesentliche Komponente in den Netzendpunkten des intelligenten Energienetzes. Durch seine Kernaufgabe des Messdatenversands werden besondere Anforderungen hinsichtlich der Sicherheit an das SMGW gestellt. Insbesondere werden die Kommunikationsflüsse zwischen dem SMGWund den übrigen Komponenten und beteiligten Parteien des Smart-Metering-Systems auf kryptographischem Wege abgesichert. Das SMGW bedient sich hierzu eines Sicherheitsmoduls, das zum einen als sicherer Speicher für das dazu erforderliche Schlüsselmaterial dient und zum anderen für das SMGW selbst die Kernroutinen für Signaturerstellung und -prüfung, Schlüsselgenerierung, Schlüsselaushandlung sowie Zufallszahlengenerierung bereitstellt.

Um die Sicherheitsfunktionalität des Sicherheitsmoduls geeignet zu erfassen und festzuschreiben, wurde durch das BSI ein entsprechendes Schutzprofil für das Sicherheitsmodul erstellt.

Cassandra Apache, cassandra.apache.org. Abgerufen am 02. 07 2013 von

http://cassandra.apache.org/

The Apache Cassandra database is the right choice when you need scalability and high availability without compromising performance. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data. Cassandra's support for replicating across multiple datacenters is best-in-class, providing lower latency for your users and the peace of mind of knowing that you can survive regional outages.

Cassandra's data model offers the convenience of column indexes with the performance of log-structured updates, strong support for denormalization and materialized views, and powerful built-in caching.

Cryptas

cryptas.com. Abgerufen am 25. 06 2013 von http://www.cryptas.com/cryptas/wissen-unterstuetzung/digitale-signatur/typen-digitaler-signaturen.html

Digitale Signatur

Eine digitale Signatur als Analogon zur handschriftlichen Unterschrift sollte einige Anforderungen erfüllen. Anforderungen an die handschriftliche Unterschrift sind weder gesetzlich festgelegt, noch einheitlich verwendet werden, doch wird zumeist zur Authentizität und Verbindlichkeit auch

• Verifizierbarkeit: alle Personen müssen in der Lage sein, die Echtheit der Unterschrift zu

prüfen; und

• Nachrichtenabhängigkeit: die Unterschrift muss sich auf eine bestimmte Nachricht beziehen

und von dieser funktional abhängen,

gefordert, welche handschriftliche Unterschriften nur schwer, z.B. mit Unterschriftenblättern, sicherzustellen ist. Mehr dazu in rechtliche Anforderungen an digitale Signaturen. Digitale Signaturen erfüllen diese Eigenschaften viel besser, man beachte aber, dass digitale Signaturen keine Vertraulichkeit sicherstellen.

Alle Versuche mit symmetrischen Verfahren eine digitale Signatur zu konstruieren führen dazu, dass eine dritte vertrauenswürdige Partei herangezogen werden muss, die an der Erzeugung und Überprüfung beteiligt werden muss. Asymmetrische Verfahren bieten daher Vorteile. Die Authentizität und Verbindlichkeit wird so durch die Verwendung eines privaten Schlüssel erreicht, die Verifizierbarkeit mit dem öffentlichen Schlüssel, für die Nachrichtenabhängigkeit werden Hash-Funktionen oder die Verschlüsselung mit dem privaten Schlüssel herangezogen. Grundsätzlich gibt es zwei Arten von digitalen Unterschriften.

• Digital signature giving message recovery: Die Digital zu unterschreibende Nachricht wird in Blöcke geteilt und jeder Block wird einzeln mit dem Schlüssel des Unterzeichners signiert.

Eine kryptographische Verkettung oder eine (mitsignierte) Prüfsumme ist empfehlenswert.

• Digital signature with appendix: Aus der zu unterschreibenden Nachricht wird ein

kryptographischer Hash bestimmter Länge gebildet, und nur dieses wird mit dem privaten

Schlüssel des Unterzeichners verschlüsselt, bzw. signiert - die üblichere Variante. Zur

Überprüfung wird aus der Nachricht wiederum der Hash gebildet und mit dem übertragenen

signierten Hash-Wert verglichen.

Viel wichtiger als bei handschriftlichen Signaturen gehört zur Überprüfbarkeit der Gültigkeit von digitalen Signaturen auch der Erstellungszeitpunkt der digitalen Signatur, diese können mit Zeitstempeldiensten realisiert werden. Auch dem Umstand, dass solche Unterschriften " ablaufen " muss durch Nachsignierung Rechnung getragen werden.

Wenn andere Sicherheitsziele erreicht werden sollen können besondere Formen von digitalen Signaturen, wie blinde oder duale Signaturen eingesetzt werden.

Digitale Signatur digital Signature with appendix

Überprüfung einer digitalen Signatur

Die Verifikation einer Digitalen Signatur besteht aus der eigentlichen Signaturprüfung und der Prüfung auf die Gültigkeit des signierenden Zertifikates. Bei der Signaturprüfung wird mit dem öffentlichen Schlüssel, dem man aus dem Zertifikat kennt, der verschlüsselte Hash-Wert entschlüsselt. Über die signierten Daten wird ebenfalls ein Hash-Wert gerechnet und mit dem entschlüsselten Wert verglichen. Sind diese Werte identisch, ist klargestellt, dass die Daten unverändert sind und der, zum öffentlichen Schlüssel gehörende, private Schlüssel für die Signatur verwendet wurde. Die Identität und die Gültigkeit des Schlüsselpaares werden mit Hilfe der Trusted Third Party, der Zertifizierungsstelle, überprüft. Anhand des Widerrufsdienstes wird die Gültigkeit des Zertifikates geprüft und der Zertifizierungspfad bis zu einem Stammzertifikat aufgebaut. Die Zertifikate im Pfad werden natürlich ebenfalls einer Widerrufsprüfung unterzogen. Die Prüfung des Zertifizierungspfades ist eine Kaskade weiterer Signatur und Widerrufsprüfungen. Zusätzlich ist auch die Prüfung weiterer Eigenschaften der Zertifikate im Zertifizierungspfad sinnvoll, z.B. ist anhand der "Basic Constraints" zu überprüfen ob mit diesem Zertifikat weitere Zertifikate ausgestellt werden dürfen.

Formate für Digitale Signaturen

Die Datenstruktur der digitalen Signatur benötigt ein Format, das eventuell auch die originalen Daten aufnehmen kann, oder eine Referenz darauf beinhaltet.

PKCS#7 ist ein Standard der weit genutzt wurde. Heutzutage setzt man auf XML DigSig.

XML Digital Signature

Extensible Markup Language (XML) ist als flexibles, hoch erweiterbares Textformat zum Datentransport, prädestiniert für den Transport von komplexen Datenstrukturen. XML Encryption und XML Signature beschreiben Anforderungen für Verschlüsselung und Signatur von XML-Dokumenten sowie die Repräsentation dieser Daten (Chiffre, Signatur) durch eine XML Dokument. XKMS (XML Key Management Specification) beschäftigt sich

mit dem Management von Informationen über kryptographische Schlüssel mittels Webservices.

Die gemeinsam von IETF und W3C gestartete Normung einer XML Signatur Syntax und Verarbeitungsregeln sind in den XML Signature Requirements ist im IETF RFC 2807 oder http://www.w3.org/Signature/ veröffentlicht. Charakteristisch für eine XML Signatur ist die Möglichkeit nur Teile eines XML Dokuments zu signieren, was Flexibilität hinsichtlich mehrerer Signaturen bei der Erstellung, bzw. auch bei einer etwaigen Weiterverarbeitung gibt. Eine XML Signatur kann natürlich über unterschiedliche Daten (XML, HTML, Binaries,...) gelegt werden. Eine XML Signatur ist ein wohldefiniertes XML Dokument, wobei die Signatur über die kanonische Form eines "Signature Manifest" gerechnet wird.

XML Signatur Erstellung

1. Das Signatur-Manifest, die Liste der zu signierenden Daten, wird gesammelt, bzw. über URIs referenziert. 2. Über die zu signierenden Ressourcen wird einzeln der Hash-Wert gerechnet. Der Wert und die Metainformationen (Hash-Algorithmus) werden in "Reference"-Elementen zusammengefasst. 3. Die "Reference"-Elemente werden zu einem "SignedInfo" Element zusammengefasst, das zusätzlich Elemente über das Kanonisierungsverfahren und verwendete Signaturalgorithmus beinhaltet. 4. Über das SignedInfo-Element wird ein Hash-Wert gerechnet, signiert und als Wert in das "SignatureValue" Element übernommen. 5. Schlüsselinformationen, sprich Zertifikat und andere Informationen, werden in ein "KeyInfo"-Element gelegt. 6. "SignedInfo", "SignatureValue" und "KeyInfo" werden in ein Signaturelement platziert, und so die XML-Signatur darstellt.

Blinde Signaturen

Im Bereich des digitalen Geldes und Systemen zu Online Wahlen kommen oft Blinde Signaturen zum Einsatz um das Sicherheitsziel der Anonymität zu erreichen. Blinde Signaturen haben die grundlegende Eigenschaft, dass der Unterschreibende nicht sieht, was er signiert. Im Grunde wird nicht der Inhalt unterschrieben, sondern die Vorlage durch eine bestimmte Partei. Einerseits soll durch eine Unterschrift des Herausgebers von digitalem Geld die Gültigkeit des Zahlungsmittels bewiesen werden können, andererseits soll die Verwendung des Zahlungsmittels nicht verfolgt werden können. Grundsätzlich unterscheidet man mehrere Typen von blinden Unterschriften obwohl man im Allgemeinen stark blinde Signaturen meint, und nicht verdeckte, oder schwach blinde Signaturen: stark blinde Signaturen: Auch, wenn der Unterzeichner ein Dokument inklusive seiner

Unterschrift sieht, kann er es dem Besitzer nicht zuordnen. Durch Verwendung von "Blendfaktoren" bei der Erstellung bzw. Ausgabe, kann der Ausgebende von digitalen Werteinheiten oder Wahlzetteln später erkennen, dass es sich um gültige Geldeinheiten, oder Wahlzettel handelt, aber nicht an wen er diese ursprünglich ausgegeben hat.

Duale Signaturen

Duale Signaturen sind (oder waren), von SET (Secure Electronic Transaction) eingeführte, kryptographische Verfahren, ähnlich den digitalen Signaturen. Sie dienen dazu, zwei Nachrichten so miteinander zu verbinden, dass der Empfänger nur eine der beiden Nachrichten kennen muss, um die Authentizität des Senders überprüfen zu können. Bei SET wird so die Information über die Bestellung und die Kreditkarteninformation verknüpft, indem über beide Informationen ein eigener Hash-Wert gerechnet wird und dann auf die Verbindung dieser beiden nochmals ein ("dualer") Hash-Wert gerechnet wird, der sodann mit dem privaten Schlüssel des Bestellenden verschlüsselt wird - "dual signiert". Diese Signatur wird an beide einzelnen Nachrichten angefügt. Eine dual signierte Nachricht enthält zur Überprüfung der dualen Signatur, zusätzlich zur übertragenen Information den Hash-Wert des anderen Teils. Damit kann der Prüfende den "duale" Hash-Wert erstellen, der mit dem signierten Hash-Wert verglichen werden kann. Fazit: Der Händler kann keine Kreditkarteninformation einsehen, da er nur einen Hash-Wert davon erhält, die Bank sieht keine Bestellung, trotzdem sind beide Informationen verbunden signiert.

CUBRID

cubrid.org. Abgerufen am 20. 06 2013 von http://www.cubrid.org/manual/91/en/shard.html

Database Sharding

Horizontal partitioning

Horizontal partition is a design to partition the data for which schema is identical, based on the row, into multiple tables and store them. For example, 'User Table' with identical schema can be divided into 'User Table #0' in which users less than 13 years are stored and 'User Table #1' in which users 13 or greater than 13 years old.

Database sharding

Database sharding is to store data into physically separate databases through horizontal partitioning and to retrieve them. For example, it is a method to store users less than 13 years old in database 0 and store users 13 or greater than 13 years old in database 1 when 'User Table' is located through multiple database. In addition to performance, database sharding is used to distribute and save large data which cannot be saved into one database instance.

Each partitioned database is called a shard or database shard.

CUBRID SHARD

The CUBRID SHARD is middleware for database sharding and its characteristics are as follows:

• Middleware that is used to minimize changes in existing applications, allowing access to

transparently sharded data by using Java Database Connectivity (JDBC), a popular choice, or

CUBRID C Interface (CCI), which is CUBRID C API.

• In this function, a hint may be added to an existing query to indicate a shard in which the

query would be executed.

• It can be configured on backend shard DBs such as MySQL, as well as CUBRID.

• It guarantees the unique characteristics of certain transactions.

More details on each characteristic will be described in the next chapter.

CUBRID SHARD Terminologies

The terminologies used to describe CUBRID SHARD are as follows:

• shard DB : A database that includes a split table and data and processes user requests

• shard metadata : Configuration information for the operation of a CUBRID SHARD. It

analyzes the requested query and includes information to select a shard DB which will

execute a query and to create a database session with the shard DB.

• shard key (column) : A column used as an identifier to select a shard in the sharding table

• shard key data : A shard key value that corresponds to the hint to identify the shard from the

query • shard ID : An identifier to identify a shard DB

• shard proxy : A CUBRID middleware process that analyzes hints included in user queries and

sends requests to a shard DB which will process the query, based on the analyzed hint and

the shard metadata

Curtalo curtalo.de. Abgerufen am 02. 07 2013 von

http://www.curtalo.de/workshop/von-wie-apache-bis-wie-zookeeper/

Apache: Die Apache Software Foundation (ASF) ist eine Non-Profit-Organisation, die 1999 aus der US-amerikanischen Apache Group ausgegründet wurde. Das Ziel der ASF ist die Förderung, Weiterentwicklung und Standardisierung von Software-Projekten. In diesem Sinne hat sie es sich auch zum Ziel gesetzt, die Hadoop-Plattform und deren Software-Bibliotheken weiter auszubauen.

Avro : Avro ist ebenfalls ein Apache-Projekt, das als Teil von Hadoop entwickelt wurde. Das Framework dient der Serialisierung von Daten und unterstützt Remote Procedure Calls, also den Aufruf von Funktionen zwischen unterschiedlichen Systemen. Avro ist ein wichtiger Hadoop-Bestandteil, der für ein schnelles Processing zwischen verteilten Systemen essentiell ist.

Big Data: Der Begriff Big Data beschreibt in erster Linie ein Phänomen: den exponentiellen Anstieg des global existierenden Datenvolumens. Dabei spielt es keine Rolle, aus welchen Quellen diese Daten stammen – wichtig ist lediglich, dass sich die verfügbaren Informationen rasend vermehren und ihr Potenzial mit klassischen Lösungen kaum ausgeschöpft werden kann. Gängige Datenbank-, Datawarehousing- und Analysesysteme stoßen aufgrund der reinen Masse, aber auch aufgrund der Beschaffenheit der Daten an ihre Grenzen. Leistungsstarke Technologien zur Verarbeitung von Big Data werden deshalb unter anderem dazu in der Lage sein müssen, auch unstrukturierte Daten zu erfassen. Frameworks wie Hadoop basieren auf dem Prinzip verteilter Rechenoperationen und machen damit große Datenmengen handhabbar und produktiv nutzbar. Der Computerworld-Journalist Jaikumar Vijayan weist in seinem Artikel „Moving beyond Hadoop for big data needs“ jedoch darauf hin, dass bei allem Potenzial von Hadoop schon heute nicht nur die reine Fähigkeit, große Datensätze zu verarbeiten, sondern zudem die Geschwindigkeit, mit der dieses geschieht, von Bedeutung ist.

Cascading: Cascading ist ein Java-basiertes Anwendungs-Framework zur Entwicklung von Data Analytics- und Data Management-Anwendungen auf Basis von Hadoop. Der Tech-Blogger Don Burnett hat eine Präsentation zum Thema „Hadoop and the Cascading Toolkit“ auf Youtube veröffenlicht – eine nette Zusammenfassung für alle, die sich schnell einen Überblick verschaffen wollen.

Cassandra: Apache Cassandra ist ein einfaches, verteiltes, NoSQL-Datenbankverwaltungssystem für sehr große strukturierte Datenbanken. Es ist offen dokumentiert und als freie Software ebenfalls unter Apache-Lizenz erhältlich. Besondere Merkmale: Hohe Skalierbarkeit und Ausfallsicherheit.

CDH/CDH4: CDH steht für „Cloudera’s Distribution Including Apache Hadoop“ und ist nach Angaben von Cloudera die meist genutzte Hadoop-Lösung weltweit. Sie dient zur Bereitstellung großer Datenmengen und nutzt dabei sowohl die zentralen Elemente von Hadoop – also skalierbaren Speicher und eine verteilte Computing-Umgebung – als auch geschäftskritische Leistungsmerkmale wie Sicherheit, hohe Verfügbarkeit und die Integration mit bestehenden Hard- und Softwareumgebungen. CDH ist derzeit in Version 4 verfügbar.

Chukwa: Apache Chukwa ist ein Hadoop-Unterprojekt, das als Analysis- und Monitoring-System die Echtzeitüberwachung sehr großer, verteilter Systeme erlaubt. Eine sehr anschauliche Erklärung für alle, die mehr wissen möchten, gibt es hier.

Distributed Computing: Der vermutlich bekannteste Vorreiter für verteilte Rechenprozesse ist SETI@home – mehr als 2,3 Millionen Computernutzer haben sich zum leistungsstärksten virtuellen Großrechner der Welt zusammengeschlossen. Und damit ist das Prinzip Distributed Computing letztlich auch erklärt: Verteiltes Rechnen oder auch Dezentralisiertes Rechnen ist eine Technik der Anwendungsprogrammierung, bei der die einzelnen Prozesse einer verteilten Anwendung ein gemeinsames Ergebnis berechnen – zum Beispiel zur Suche nach außerirdischer Intelligenz. Dan Garcia von der University of California erklärt in einem Vorlesungsmitschnitt (Video) das Prinzip „Distributed Computing“ – interessant wird es ab Minute 13.

Doug Cutting: Schöpfer und Namensgeber von Hadoop, der das System nach dem Kuschelelefanten seiner Tochter benannte. Doug Cutting ist außerdem Chairman der Apache Software Foundation und der Chefentwickler von Cloudera.

Cloudera: Cloudera ist die wohl renommierteste Software-Schmiede für Apache Hadoop-basierte Lösungen und Dienstleistungen. Inhaber ist der Hadoop-Schöpfer und ASF-Vorsitzende Doug Cutting. Cloudera unterstützt die Apache Software Foundation sowohl mit finanziellen Mitteln als auch mit Manpower: Nach eigenen Angaben kommen über 50 Prozent der eigenen Entwicklungsleistungen der ASF zugute. In einem Interview mit Scott Swigart von der Open Source-Community PORT25 bezieht Amr Awadallah, CTO bei Cloudera, ausführlich Stellung zu allen relevanten Hadoop-Themen.

Eclipse: Eclipse ist eine beliebte Open Source-Entwicklungsplattform, die gerade in Hadoop-Umgebungen gerne von Entwicklern genutzt wird. Ein Beispiel für das Eclipse-Ecosystem ist BIRT, eine offene Business Intelligence- und Reporting-Lösung, über die sich auch Big Data visualisieren lässt.

Hadoop: Apache Hadoop ist ein freies, Java-basiertes Programmier-Framework, das die Verarbeitung sehr großer Datensätze in verteilten Rechenumgebungen unterstützt. Finanziert und verwaltet wird das Projekt von der gemeinnützig tätigen Apache Software Foundation (ASF). Die Erfassung und Nutzung von Big Data könnte aufgrund des immensen, polystrukturierten Datenvolumens ohne Processing-Technologien wie Hadoop gar nicht verarbeitet werden – nur über verteilte Systeme, die Tausende von Verbindungspunkten (Hardware-Nodes) und Abertausende von Bytes vereint, werden ein rapider Datenverkehr und ein effektives Data Processing vermutlich überhaupt erst möglich sein. Einen guten Überblick über die Möglichkeiten von Hadoop liefert dieser Beitrag von BARC-Analyst Dr. Carsten Bange und Martin Lange, Global Leader Open Source Integration bei Talend.

Hama: Apache Hama ist ein reines BSP (Bulk Synchronous Parallel)-Framework, das auf HDFS aufsetzt und für massive, wissenschaftliche Rechenprozesse wie beispielsweise Matrix-, Graph- oder Netzwerk-Algorithmen gedacht ist.

HBase: Apache HBase ist eine skalierbare, spaltenorientierte Datenbank (ein so genannter Key Value Store), über die sich sehr große Datenmengen innerhalb eines Hadoop-Clusters verwalten lassen. Im Gegensatz zu Hive beispielsweise besteht mit HBase die Möglichkeit, Daten zu manipulieren. Deshalb ist das System besonders für volatile (also flüchtige) Daten geeignet, die in kurzen Abständen aufgefrischt oder verändert werden. Auch Realtime-

Abfragen mit minimalen Latenzzeiten können mit HBase gut umgesetzt werden. Eine grundlegende Einführung in das Thema HBase gibt es in diesem Video.

Hadoop Distributed File Systems (HDFS): Das verteilte Dateisystem HDFS ist eine der Kernkomponenten von Hadoop. HDFS zeichnet sich durch seine hohe Ausfallsicherheit aus und wurde für den Betrieb auf kostengünstiger Hardware entwickelt. Die zentralen Ziele von HDFS: eine schnelle Fehlererkennung, eine schnelle Wiederherstellung von Daten sowie die Verwaltung von großen Datenbeständen im Petabyte-Bereich. Die FH Köln hat die entscheidenden Fakten zu HDFS im hauseigenen Online-Lexikon gut nachvollziehbar zusammengestellt.

Hive: Das Java-basierte Datawarehouse Apache Hive wurde ursprünglich von Google entwickelt, im Sommer 2008 stellte der Konzern das System jedoch der Open-Source-Gemeinde zur freien Weiterentwicklung zur Verfügung. Hive ergänzt Hadoop um Data-Warehouse-Funktionalitäten wie die Anfragesprache HQL und Indizes. HQL ist eine auf SQL basierende Abfragesprache und ermöglicht dem Entwickler somit die Verwendung einer SQL-ähnlichen Syntax. Hive lässt sich in HBase integrieren. Wer mehr über Hive und seine Unterschiede zu anderen Datenbanken erfahren möchte, erhält weitere Informationen im Online-Lexikon der Fachhochschule Köln.

Hortonworks : Das Unternehmen unter der Federführung von Eric Baldeschweiler ist 2011 aus dem Yahoo!-Team hervorgegangen, das sich maßgeblich an der Entwicklung von Hadoop beteiligt hat. Die Hortonworks Data Platform ist eine quelloffene, auf dem Hadoop-Framework basierende Komplettlösung, die aufeinander abgestimmte Komponenten – von der Verarbeitung der Daten bis zum Monitoring der Cluster – umfasst.

Mahout: Apache Mahout ist eine freie, in Java geschriebene Programmbibliothek unter Apache-Lizenz, die für verteiltes, maschinelles Lernen und Data Mining angelegt wurde. Die Software setzt ebenfalls auf Hadoop auf. Eine “Mahout in 3 Minuten”-Einführung gibt es hier.

MapReduce: Das Programmierframework MapReduce wurde 2004 von Google eingeführt und trägt seitdem maßgeblich dazu bei, die parallele und verteilte Verarbeitung von Daten so effizient wie möglich zu gestalten. Das Prinzip in einfachen Worten: Die MapReduce-Methode zerlegt eine Aufgabe in kleinste Teile, verteilt diese zur parallelen Verarbeitung auf möglichst viele Rechenknoten (mapping) und führt anschließend das Ergebnis zusammen (reduce). Ein kleines Programmierbeispiel für das Prinzip von MapReduce gibt es auf ScienceBlogs. In einer Seminararbeit der Berliner Humboldt-Universität heißt es: „Die Stärke von MapReduce liegt in der Einführung einer neuen Abstraktionsebene, die die technisch komplexen Aspekte der parallelen Programmierung wie Last- und Datenverteilung oder Fehlertoleranz innerhalb eines Frameworks vor dem Benutzer verbirgt. Ein Benutzer, der gegen die Schnittstellen des Frameworks programmiert, muss sich nur noch mit der Frage „Was soll berechnet werden?“ befassen und nicht mehr darauf konzentrieren, wie die Parallelverarbeitung läuft. Ein weiterer praktischer Vorteil von MapReduce ist die Möglichkeit, handelsübliche Standard-Hardware zu verwenden. Die Einführung in das Thema MapReduce von Stefan Bethge und Astrid Rheinländer kann als PDF heruntergeladen werden.

Pig: Apache Pig ist eine von Yahoo entwickelte Plattform zur Analyse großer Datenmengen, die 2007 in den Apache-Pool überging. Möglich ist die Analyse von Big Data durch eine einfache Skriptsprachen-Syntax, die Datenrelationen und deren Verarbeitung beschreibt. Pig-

Skripte werden automatisch in eine Anzahl Mapper- und Reducer-Prozesse des Hadoop-Frameworks übersetzt und ausgeführt. Auf diese Weise können Ad-hoc-Abfragen in großen Datenbeständen innerhalb einer Hadoop-Umgebung ausgeführt werden. Wirtschaftsinformatiker an der Universität Stralsund haben einen Interessanten Vergleich zwischen Pig und Hive veröffentlicht.

Serialisierung (Serialization): Diese Technologie ist essentiell für ein schnelles Processing von großen Datenmengen. Bei der Serialisierung wird der Zustand einzelner Datenelemente, den sogenannten Objekten, zusammen mit all ihren Verknüpfungen in eine Folge von Bytes umgewandelt. Objekte können ganz konkret einen bestimmten, vorab definierten Datentyp (Klasse) beschreiben. Das kann so etwas Pragmatisches wie beispielsweise die Angabe einer Adresse in den einzelnen Elementen Straße, Hausnummer, Postleitzahl und Ort sein. Die Serialisierung solcher Datenobjekte hat zahlreiche Vorteile, da Objekteigenschaften mit dieser Methode nicht separat gespeichert werden müssen und trotzdem auch außerhalb ihres Programmes weiterexistieren können. Diese Eigenschaften sind bei verteilten Systemen für ein effizientes Daten-Processing sehr wichtig. Eine ausführliche Erklärung bietet das Online-Lexikon IT-Wissen.

Yarn : Apache Yarn alias MapReduce 2.0 (MRv2) ist der Nachfolger der originalen MapReduce-Version. YARN trennt Jobtracker, Ressourcenverwaltung sowie Job-Scheduling und -Monitoring. Dafür stehen ein globaler Resource Manager (RM) und ein applikationsspezifischer Application Master (AM) zur Verfügung, wobei eine Applikation ein herkömmlicher MapReduce-Job oder eine komplexe Zusammenstellung sein kann. Mit Yarn soll der Einsatzbereich von Hadoop erweitert und die Geschwindigkeit der Hadoop-Operationen erhöht werden.

ZooKeeper: Apache ZooKeeper erledigt das zentralisierte Konfigurationsmanagement von Hadoop-Umgebungen. Es verwaltet die Konfiguration, das Naming oder auch Synchronisierungsprozesse innerhalb verteilter Systeme.

TU Darmstadt informatik.tu-darmstadt.de. Abgerufen am 15. 07 2013 von http://www.informatik.tu-

darmstadt.de/BS/Lehre/Sem98_99/T11/

Verifikation digitaler Signaturen

2 Kryptographische Grundlagen

In der Kryptographie unterscheidet man zwei verschiedene Arten der Verschlüsselung: die

symmetrische und die asymmetrische Verschlüsselung.

Bei der symmetrischen Verschlüsselung benutzen Sender und Empfänger einer Nachricht den gleichen Schlüssel zum Verschlüsseln und Entschlüsseln. Problematisch sind symmetrische Verfahren im Zusammenhang mit digitalen Signaturen aus verschiedenen Gründen. Die wichtigsten sind:

• Die Zahl der Schlüssel ist sehr groß, da jeweils zwei Teilnehmer einen gemeinsamen Schlüssel

vereinbaren. Bei n Teilnehmern sind das [(n(n-1))/ 2] Schlüssel.

• Der Austausch von Schlüsseln kann nicht auf dem gleichen Medium geschehen.

• Da beide Teilnehmer den gleichen Schlüssel besitzen, könnte im Streitfall nicht nachgewiesen

werden, wer von beiden mit dem Schlüssel die Unterschrift geleistet hat.

Mit asymmetrischen Verfahren kann man die oben beschriebenen Probleme lösen. Deshalb werden

sie bei digitalen Signaturen eingesetzt.

2.1 Asymmetrische Verschlüsselung

Die Idee der asymmetrische Verschlüsselung wurde erstmals im Jahr 1976 von Diffie und Hellman in

ihrem Aufsatz "New Directions in Cryptography" [DH76] veröffentlicht. Darin führen die Autoren das

Prinzip asymmetrischer Kryptographie ein. Doch erst 1978 stellten Rivest, Shamir und Adleman mit

RSA das erste asymmetrische Verschlüsselungsverfahren vor [RSA78]. Das nach seinen Autoren

genannte Verfahren ist inzwischen zum de-facto Standard geworden.

Asymmetrische Verschlüsselung funktioniert in folgender Weise: Jeder Teilnehmer erzeugt sich ein Schlüsselpaar bestehend aus einem öffentlichen Schlüssel e und einem geheimen Schlüssel d. Das System ist so konzipiert, daß der private Schlüssel aus dem öffentlichen Schlüssel nur in nicht vertretbarer Zeit zu berechnen ist1.

Wenn Alice eine Nachricht m an Bob schicken möchte, benötigt sie Bobs öffentlichen Schlüssel eBob. Diesen bekommt sie entweder von Bob persönlich oder aus einem öffentlichen Schlüssel-Verzeichnis.

Alice benutzt die Verschlüsselungsfunktion E und berechnet die verschlüsselte Nachricht c mit

c = EeBob (m)

Sie schickt Bob diese verschlüsselte Nachricht c und dieser benutzt die Entschlüsselungsfunktion D,

um mit Hilfe seines privaten Schlüssels dBob die ursprüngliche Nachricht m wiederherzustellen:

DdBob (c) = m

Abbildung 1: Asymmetrische Verschlüsselung

2.2 Digitale Signatur

In umgekehrter Weise lassen sich mit asymmetrischen Verfahren auch digitale Signaturen erzeugen.

Der Schlüssel zum Überprüfen einer Signatur ist öffentlich, während der Schlüssel zum Signieren

geheim gehalten werden muß.

Alice berechnet aus dem zu unterschreibenden Text m (evtl. zusammen mit Informationen über den Zeitpunkt der digitalen Signatur (siehe Kap. 2.5.4)) mit ihrem geheimen Signierschlüssel dAlice und einem Signieralgorithmus S einen Wert sig: die sogenannte digitale Signatur. Diese Signatur wird auch Authentikator genannt.

sig = SdAlice(m)

Sie verschickt den Text zusammen mit der digitalen Signatur (m,sig) an Bob (siehe Abb. 2). Will dieser

die Echtheit des bei ihm eingegangenen Textes überprüfen, so verifiziert er mit Hilfe eines

Verifikationsalgorithmus V und dem öffentlichen Schlüssel eAlice von Alice die digitale Signatur sig.

VeAlice(m) = sig ?

Die Vorgehensweise bei der Verifikation einer digitalen Signatur wird in Kapitel 4 ausführlicher

beschrieben. In der Praxis bestimmt man zunächst, vor allem aus Performanz-Gründen, einen

sogenannten Hashwert (siehe Kap. 2.3) aus dem zu signierenden Text und berechnet zu diesem eine

digitale Signatur.

Abbildung 2: Erzeugen einer digitale Signatur

Voraussetzung für das Funktionieren dieses Konzeptes ist die authentische Kenntnis des öffentlichen Schlüssels des Kommunikationspartners. Erreicht werden kann dies durch eine direkte, persönliche Schlüsselübergabe oder durch ein digital signiertes Zertifikat (siehe Kap. 2.4) eines vertrauenswürdigen Dritten.

Durch eine digitale Signatur kann man die Verbindlichkeit des Inhalts für den Sender einer Nachricht sicherstellen.

2.3 Hashfunktionen

Eine Hashfunktion (genauer: Einweg-Hashfunktion) ist eine effizient zu berechnende, mathematische

Funktion, die eine Zeichenkette variable Länge auf eine Zeichenkette fester Länge abbildet. Der

Zweck liegt darin, einen "Fingerabdruck" der Eingabe zu erzeugen, der alle Bytes der Eingabe

berücksichtigt. Der Hashwert selbst ist meist erheblich kürzer als der Text (typischerweise 128 - 126

bit lang). In der Kryptographie kann man anhand des Hashwertes eines Dokuments überprüfen, ob

der Text verändert wurde.

Um dies zu ermöglichen, werden an eine Hashfunktion besondere Anforderungen gestellt: Sie muß kollisionsresistent sein, d.h. es muß eine ein-eindeutige Beziehung zwischen Ursprungstext und Hashwert bestehen, was natürlich in der Realität nicht möglich ist, wenn eine Menge beliebig langer Zeichenketten auf eine (viel kleinere) Menge Zeichenketten fester Länge abgebildet wird. Zumindest muß es unmöglich (oder nicht effizient möglich) sein, zu einem gegebenen Hashwert einen Text zu finden, der diesen Hashwert erzeugt (Einwegfunktion)2.

Beispiele für Hashfunktionen sind MD4, MD5, SHA-1 und RIPEMD-160.

2.4 Zertifikat

Ein Zertifikat ist im elektronischen Geschäftsverkehr das Äquivalent zum Personalausweis. Technisch

gesehen besteht es im einfachsten Fall aus drei Komponenten: dem Namen und dem öffentlichen

Schlüssel des Teilnehmers, sowie einer Angabe, wie lange das Zertifikat gültig ist.

Zertifikate bestätigen also die Authentizität (d.h. die Zugehörigkeit eines Schlüssels zu einer Person) und die Integrität (d.h. die Unverfälschtheit) dieses öffentlichen Schlüssels.

Der Aufbau und Inhalt von Zertifikaten wurde 1988 von CCITT (heute ITU) genormt. Nach mehrmaligen Überarbeitungen liegt der X.509-Standard heute in der Version 3 vor3. Ein Beispiel-Zertifikat sieht folgendermaßen aus:

Version: 2 (X.509v3-1996) SubjectName: CN=Alice, OU=FB 20, O =TUD, L=Darmstadt, C=DE IssuerName: CN=CA, O=TEST, C=DE SerialNumber: 3 (decimal) Validity - NotBefore: Mon Aug 10 20:09:56 1 998 (980810180956Z) NotAfter: Tue Aug 10 20:09:56 1 999 (990810180956Z) Public Key Fingerprint: 18C9 9692 00E8 6F9B 1 688 A1BA 965E 0D18 SubjectKey: Algorithm RSA (OID 1. 2.840.113549.1.1.1), NULL Certificate extensions: Authority Key Identifier: 9183 7942 BFC7 D7 85 A7C5 BFBF 1648 A729 35ED 1511 Subject Key Identifier: 6812 CDBF 0A5A 0D D6 A92B 87F9 F1EE 99EB B58A 9FC0 Key Usage: (CRITICAL) digita lSignature nonRepudiation keyEnc ipherment dataEncipherment Basic Constraints: NOT allowed to ac t as a CA ! Signature: Algorithm md5WithRsaE ncryption (OID 1.2.840.113549.1.1.4), NULL Certificate Fingerprint: 1D:F6:A4:5A:48:18:CE:C2:BA:90:F9:FC:4 E:06:89:20 X.509v3-Zertifikate schaffen Interoperabilität zwischen den einzelnen Komponenten einer

Zertifizierungsinfrastruktur (siehe Kap. 2.5). Wichtige Erweiterungen dieser dritten Version werden in

Kapitel 5.2 beschrieben.

Neben Personen-Zertifikaten gibt noch eine andere Art von Zertifikaten: das Attribut-Zertifikat. Es bestätigt, daß eine Person mit öffentlichem Schlüssel xyz berechtigt ist, bestimmte Aufgaben zu erfüllen (z.B daß sie Arzt oder Rechtsanwalt ist, oder daß sie in einem Fall zeichnungsberechtigt ist). Es ist nur in Verbindung mit einem Personen-Zertifikat gültig. Ein Teilnehmer kann verschiedene Attributzertifikate besitzen und so in verschiedenen Rollen handeln.

2.5 Zertifizierungsinfrastruktur und Zertifizierungspfad

Die Infrastruktur zur Ausgabe und Verwaltung privater und öffentlicher Schlüssel wird

Zertifizierungsinfrastruktur (public-key-infrastructure (PKI)) genannt. Unmittelbar daran beteiligt sind

die Zertifizierungsstellen (certification authority (CA)), die Registrierungsstellen (registration

authority (RA)) und die Kunden mit einem Signier- bzw. Verifiziersystem. Außerdem wird ein

Verzeichnisdienst (directory service (DIR)) und ein Zeitstempeldienst (time stamping service (TSS))

benötigt.

Der Aufnahmevorgang läuft prinzipiell wie folgt ab: Der Kunde beantragt bei der RA ein Zertifikat für digitale Signatur. Die RA prüft den Antrag und die Identität des Kunden und leitet ihn an die CA weiter. Nun gibt es zwei Alternativen: die CA erzeugt daraufhin das gewünschte Schlüsselpaar für den Kunden oder erhält alternativ vom Kunden den öffentlichen Schlüssel eines selbsterzeugten Schlüsselpaares4. Die CA darf in keinem Fälle technisch in der Lage sein, den privaten Schlüssel des Kunden zu lesen.

Der öffentliche Schlüssel wird von der CA in einem Zertifikat integriert. Im Zertifikat können zusätzliche Erweiterungen angegeben werden, die die Nutzung des Schlüssels einschränken (siehe Kapitel 5.2). Dieses Zertifikat wird mit dem privaten Schlüssel der CA signiert und kann damit nicht mehr verfälscht werden. Jedes von der CA ausgestellte Zertifikat erhält eine innhalb der CA eindeutige Seriennummer. Der private Schlüssel sollte mindestens paßwortgeschützt auf der Festplatte des Kunden oder besser auf seiner SmartCard gespeichert werden.

Abbildung 3: Aufnahme in die Zertifizierungsinfrastruktur

Die zertifizierten Schlüssel werden in einem vom Verzeichnisdienst betriebenen allgemein zugänglichen Verzeichnis - beispielsweise nach dem X.500-Standard [ X.500 ]) abgelegt. Alle Teilnehmer können so das Zertifikat eines anderen Teilnehmers zum Prüfen einer Signatur abrufen.

In einer solchen Zertifizierungsinfrastruktur können Authentizität und Integrität zu Zertifikaten fremder CAs geprüft werden, indem der öffentliche Prüfschlüssel der fremden CA anhand eines "Zertifikatspfades" überprüft wird5 . Unter einem Zertifizierungspfad versteht man die Kette aller Zertifikate vom Teilnehmer-Zertifikat über das Zertifikat der CA, die das Teilnehmer-Zertifikat ausgestellt hat, bis zur höchsten Ebene in der CA-Hierarchie - der Root-CA. Die Root-CA ist die von allen anerkannte Wurzelinstanz der PKI

Das CCITT normte 1988 dieses Konzept des asymmetrischen Schlüsselmanagements im X.509-Standard (in einer überarbeiteten Version unter [X.509]).

2.5.1 Zertifizierungsstellen

Zertifizierungsstellen (CAs) sind dafür zuständig, Teilnehmerzertifikate auszustellen und damit

Teilnehmern die authentische und verbindliche Kommunikation innerhalb der

Zertifizierungsinfrastruktur zu ermöglichen.

CAs können mit unterschiedlich starken Zertifizierungsrichtlinien ("Security Policies") betrieben werden (sogenannte Policy Certification Authorities (PCAs)). Die Policy beschreibt dabei die Sicherheitsanforderungen, denen eine CA unterliegt. Zum Beispiel wird darin beschrieben, wie stark die CA die Identität des Kunden geprüft hat.6

Die wohl bekannteste kommerzielle Zertifizierungsstellen betreibt die US-amerikanische Firma VeriSign.

2.5.2 Sperrliste

Jede CA führt eine Sperrliste (certificate revocation list (CRL)), auf die mit Hilfe des

Verzeichnisdienstes alle Teilnehmer Zugriff haben. Hier werden alle zurückgenommenen Zertifikate

(anhand der Seriennummer) mit einem Rücknahmedatum abgespeichert. Gründe für eine

Rücknahme können beispielsweise der Verlust oder die Kompromittierung des privaten Schlüssels

sein.

Beachtet werden sollte aber, daß abgelaufene Zertifikate, das sind Zertifikate, deren Gültigkeitszeitraum überschritten ist, nicht mehr in der CRL geführt werden. So wird zum Beispiel ein kompromittiertes Zertifikat nach Ablauf nirgendwo mehr als kompromittiert vermerkt.

2.5.3 Verzeichnisdienst

Die Aufgabe des Verzeichnisdienstes ist es, den Kunden der Zertifizierungsinfrastruktur, die

Zertifikatsanfragen stellen, Zertifikate zu schicken. Die Sperrliste wird ebenfalls vom

Verzeichnisdienst verwaltet und sollte jederzeit aktuell abrufbar sein.

2.5.4 Zeitstempeldienst

Zeitstempel werden in Verbindung mit digitale

Signaturen dazu benutzt, das Dokument an

einen bestimmten Zeitpunkt zu binden. Das

Dokument wird dazu zuerst vom Urheber

signiert und anschließend wird ein Zeitstempel

angebracht. Dieser besteht dabei vereinfacht

aus einer Signatur (erzeugt mit dem geheimen

Schlüssel des TSS) von bestimmten Daten der

Umwelt, die sich prüfen, nachträglich nicht

fälschen und nicht vorherbestimmen lassen (z.B

Temperatur-Angaben, Lottozahlen, Börsenkurse

etc.) und einer Zeitangabe. Es gibt auch eine

Möglichkeit, Zeitstempel ohne Signatur

auszustellen. Weitere Informationen und eine

kommerzielle Implementierung sind bei Surety

Technologies7 erhältlich. Zeitstempel sind auch

im Zusammenhang mit dem genauen Zeitpunkt

der Sperrung eines Zertifikates, der

Nichtabstreitbarkeit einer geleisteten

Unterschrift und der Langzeitspeicherung von

entscheidender Bedeutung8.

Abbildung 4: Zeitstempel

3 Pretty Good Privacy

Pretty Good Privacy (PGP)9 ist ein frei verfügbares (nicht kommerziellen Bereich) und auf vielen

Plattformen lauffähiges Programm zur Verschlüsselung von Daten und EMails, das ursprünglich 1991

von Philip Zimmermann entwickelt wurde10. PGP ist das im privaten wie im geschäftlichen Bereich

am weitesten verbreitete Kryptowerkzeug. Die Beliebtheit in Deutschland ist sicherlich Initiativen

gegen die drohende Krypto-Regulierung durch die Bundesregierung zu verdanken11. PGP liegt

mittlerweile in der Version 6.0 vor und gestattet starke Kryptographie.

3.1 Schlüsselerstellung

Zur Schlüsselgenerierung benötigt PGP eine Zufallszahl. Da in einem Computer keine Quelle

wirklicher Zufallszahlen vorhanden ist, kreiert der Benutzer durch zufällige Bewegungen mit dem

Maus eine Zufallszahl. Der private Schlüssel ist paßwortgeschützt. Die Datei mit dem privaten

Schlüsselring - dem private-key ring - und die Datei mit den öffentlichen Schlüsseln - dem public-key

ring - werden auf der Festplatte des lokalen Rechners abgelegt. Bei jedem Zugriff auf den privaten

Schlüssel verlangt das Programm die Eingabe des Paßwortes, um mit diesem die Daten zu

entschlüsseln.

3.2 Schlüsselverwaltung

Nachdem ein Benutzer ein Schlüsselpaar erzeugt hat, gibt er seinen öffentlichen Schlüssel auf einem

Weg seiner Wahl bekannt, zum Beispiel über sogenannte Key-Server (z.B. [PGP-Serv]) oder durch

persönlichen Austausch. Die Authentizität des Schlüssels wird durch Vergleich des Hashwertes (PGP-

Fingerprint) über einen vertrauenswürdigen (authentischen) Kanal, meist ein Telefonat, festgestellt.

Dieser konzeptionelle Ansatz ist Ausdruck von Zimmermanns Mißtrauen gegenüber jeder Big-

Brother-fähigen zentralen Instanz, wie es CAs in einer PKI darstellen.

PGP setzt auf verteilte Schlüsselverwaltung. Es gibt keine Instanzen zur Schlüsselverwaltung. Jeder Benutzer verwaltet seinen öffentlichen Schlüsselring selbst. Die Benutzer unterzeichnen ihre öffentlichen Schlüssel gegenseitig und schaffen so eine zusammenhängende Gemeinschaft von PGP-Benutzern (siehe 3.3). Das Ziel, ist ein "Netz des Vertrauens" (web of trust) zu schaffen, welches eine Verallgemeinerung der "Zertifizierungshierarchien" darstellt.12

3.3 Zertifizierung

Jeder Eintrag im public-key-ring besitzt ein Feld für die Schlüssellegitimation, das anzeigt, in welchem

Maße der Benutzer der Gültigkeit des Schlüssels traut. Ein weiteres Feld gibt an, wie weit der

Benutzer dem Unterzeichner zutraut, die öffentlichen Schlüssel anderer Benutzer zu zertifizieren. So

ist es also möglich, die Zertifikate gewisser Aussteller komplett zu ignorieren13. Das Prinzip der

Schlüsseleinführung wird in Abbildung 5 an einem Beispiel beschrieben.

Wenn Alice beispielsweise mit Carol sicher kommunizieren möchte, könnte Alice ihren öffentlichen Schlüssel Bob direkt aushändigen. Da Bob Alice kennt, unterzeichnet er ihren öffentlichen Schlüssel. Dann gibt er ihr den unterschriebenen Schlüssel zurück und behält eine Kopie für sich. Alice schickt Carol nun eine Kopie ihres von Bob unterschriebenen öffentlichen Schlüssels. Carol, die bereits über Bobs öffentlichen Schlüssel (aus einer früheren Kommunikation) verfügt und Bobs Schlüssel vertraut, verifiziert dessen Unterschrift auf Alices Schlüssel und vertraut damit auch Alices Schlüssel. Somit hat Bob Alice bei Carol eingeführt.

Abbildung 5: Prinzip der Schlüsseleinführung in PGP

PGP sieht kein spezielles Verfahren vor, um Vertrauen herzustellen. Die Benutzer entscheiden selbst, wen sie für zuverlässig halten und wen nicht. Man spricht deshalb auch bei PGP von einer Selbstzertifizierung.

3.4 Sperrung von Zertifikaten

Die Schlüsselrücknahme ist das schwächste Glied im PGP-System. Es gibt keine Garantie, daß ein

kompromittierter Schlüssel nicht von irgend jemandem verwendet wird.

Wird Alices Schlüssel gestohlen, kann sie ein sogenanntes Schlüsselzurücknahmezertifikat (key revocation certificate) losschicken. Da aber die Schlüsselverteilung bei Bedarf und durch Mund-zu-Mund-Propaganda erfolgt, gibt es keinerlei Garantie, daß dieses Zertifikat alle erreicht, die Alices Schlüssel in ihrem Schlüsselring haben. Alice muß außerdem das Schlüsselrücknahmezertifikat mit ihrem privaten Schlüssel unterschreiben. Hat sie diesen jedoch verloren, kann sie ihren Schlüssel nicht zurücknehmen. Es ist aber möglich, sich schon vorher ein Schlüsselrücknahmezertifikat zu erstellen und aufzubewahren, falls es irgendwann benötigt wird.

Neben einer Rücknahme besteht seit Version 5.0 auch die Möglichkeit, bei der Schlüsselerstellung eine Lebensdauer des Schlüssels zu vereinbaren, so daß der Schlüssel nach einer bestimmten Zeit automatisch ungültig wird.

3.5 Bewertung von PGP

Unter kryptographischen Gesichtspunkten sind die Verfahren und Algorithmen, die in PGP verwendet

werden kaum zu beanstanden. Lediglich der Hash-Algorithmus MD5<14 wird inzwischen als nicht

mehr ganz so sicher angesehen15. Ein wesentlicher Faktor für die Sicherheit von PGP ist die

sachgemäße Bedienung, da dem Benutzer viele Freiheiten gelassen werden. Eine leichtfertige

Benutzung und unkundiger Gebrauch kann das Ziel des "Web of Trust" - auch für alle anderen

Benutzer - zunichte machen.

3.5.1 Stärken von PGP

PGP hat unbestreitbare Stärken, die es für viele Anwendungsbereiche attraktiv machen: Es

• ist seit mehreren Jahren erprobt

• liegt im Quellcode vor, so daß es auf Sicherheitslücken, Implementierungsfehler oder

"Hintertürchen" überprüft werden konnte und kann

• ist plattformunabhängig - Portierungen existieren für DOS, Windows, MacOS und fast alle gängigen UNIX-Varianten

• hat große Verbreitung erlangt

• ist unabhängig von einer bestimmten Zertifizierungs- oder Registrierungsinfrastruktur und

damit auch besonders für geschlossene Benutzergruppen geeignet, die auf diese Weise

vertraulich und authentisch kommunizieren können

• wenige Aufgaben werden der Zertifizierungsinfrastruktur übertragen

• ist sehr flexibel einsetzbar, auch in hierarchisch strukturierten Zertifizierungsumgebungen.

Beispiel hierfür ist die Zertifizierungsinfrastruktur des Individual Network e. V. [HeRS98].

3.5.2 Schwächen von PGP

Es gibt jedoch auch einige Schwächen in der Konzeption und Fehler in der Implementierung. G.

Howland beschreibt unter [Howl97] einige Kuriositäten mit PGP. Darüber hinaus gibt es aber

ernstere Angriffe.

• Das folgende Szenario ist mit der Version 2.6.3ia möglich: Mit einem widerrufenen Schlüssel

können vor dem Widerruf andere Schlüssel zertifiziert worden sein. Auch wenn für einen

bestimmten Schlüssel bereits ein Widerruf vorliegt, zeigt PGP bei einem Keyring-Check die mit diesem Schlüssel unterschriebenen Zertifikate weiterhin als "gültig" an.

• Ebenso hat PGP eine digitale Unterschrift als "gültig" verifiziert, deren Erstellungsdatum

ausweislich eben diesen Programmes in der Zukunft liegt, und die - angeblich - erzeugt

wurde (eher: "...erzeugt worden sein wird"), bevor der zum Signieren verwendete Schlüssel

überhaupt existierte16.

• Aufgrund des Selbstzertifierungskonzeptes von PGP gelang es im Sommer 1997

Unbekannten, "exponierte" Schlüssel mit falschem Namen in öffentliche Key-Server

einzuschleusen, um andere PGP-Anwender zu verwirren und die betreffenden CAs zu

diskreditieren.

Diese Art der Angriffe sind in der aktuellen Version 6.0 größtenteils behoben worden: Es wurden

Plausibilitätstests für Gültigkeitszeiträume und Funktionsbeschränkungen für Schlüssel eingeführt.

Doch bleiben einige designbedingte Schwächen: Die Verteilung von Rücknahmezertifikaten und damit die Gültigkeitsprüfung von Zertifikaten ist unzureichend gelöst. Die Verfügbarkeit eines öffentlichen Schlüssels über einen Key-Server sagt nichts über dessen Authentizität aus! Durch die Selbstzertifizierung wird im allgemeinen keinen Verbindlichkeit erreicht, sondern nur Integrität. Es sei denn, der Benutzer eines öffentlichen Schlüssels überzeugt sich - beispielsweise telefonisch - von der Authentizität des öffentlichen Schlüssels. Zu bemerken ist auch, daß PGP konzeptbedingt nicht Signaturgesetz konform ist und sich auch nur mit größtem Aufwand anpassen ließe. Dennoch ist PGP der de-facto Standard für sichere Kommunikation via EMail.

4 Verifikation digitaler Signaturen

Wie Kapitel 2.2 erläutert, läßt sich mit Hilfe einer digitalen Signatur Integrität (Unverändertheit) und

Authentizität (verbindliche Zuordnung der Nachricht zu einer Person) erreichen. Der Verifikation

einer digitalen Signatur kommt hier eine entscheidende Bedeutung zu. Sie muß den Empfänger von

der Integrität und der Authentizität des Absenders überzeugen.

Als Grundlage für komplexere Szenarien schauen wir uns zunächst eine einfache Verifikation eines signierten Dokuments an. Abbildung 6 veranschaulicht diesen einfachen Prüfungsvorgang einer digitalen Signatur.

Bob bekommt von Alice ein signiertes Dokument (m,sig). Er möchte entscheiden, ob Alice das Dokument wirklich unterschrieben hat. Dazu trennt er Dokument m und Signatur sig. Bob errechnet aus dem Dokument m mit Hilfe einer Hashfunktion H den Fingerabdruck H(m) des Dokuments.

Er benötigt zur Verifikation auch den öffentlichen Schlüssel eAlice von Alice. Hier gibt es zwei Alternativen: Wenn Bob oft mit Alice kommuniziert, hat er den Schlüssel eAlice bereits und

muß sich beim Verzeichnisdienst vergewissern, daß der Schlüssel nicht gesperrt wurde. Kennt Bob Alice nicht, so fordert er vom Verzeichnisdienst Alices öffentlichen Schlüssel eAlice an.

Jetzt benutzt Bob den Fingerabdruck H(m) und den öffentlichen Schlüssel eAlice mit der Verifikationsfunktion V und erhält einen Wert, den er mit der Signatur sig vergleicht. Stimmen beide überein, ist die Verifikation erfolgreich.

VeAlice(H(m)) = sig ?

Abbildung 6: Signaturprüfung in einer PKI

Hätte Alice - um Bob zu betrügen - den Text nachträglich verändert, wäre der von Bob berechnete Fingerabdruck H(m) verschieden gewesen von dem, den Alice zum Erzeugen der Signatur benutzt hat. Hätte Alice mit einem falschen Schlüssel unterschrieben, hätte Bob ebenfalls bei der Verifikation einen anderen Wert sig erhalten. Er hätte in jedem Fall den Betrug bemerkt.

4.1 Der nicht-triviale Verifikationsfall

In der Praxis ist die Verifikation ist aber meist nicht so trivial wie in dem eben beschriebenen Fall. Es

stellen sich beispielsweise folgende Probleme:

• Was geschieht mit einem signierten Dokument, wenn der Verifikationszeitpunkt nach dem Gültigkeitszeitraum des Zertifikates liegt, das zum Unterschreiben benutzt wurde?

• Wie kann man sicherstellen, daß der Zeitpunkt der Signatur authentisch ist? Die Systemuhr

des PCs bietet hier keine Sicherheit.

• Wie kann man eine Signatur überprüfen, wenn der zuständige Verzeichnisdienst gerade nicht verfügbar ist?

• Wie kann man gefälschte Signaturen erkennen?

Die meisten Problemfälle treten immer dann auf, wenn der Signierzeitpunkt und der

Verifizierzeitpunkt relativ lange auseinander liegen.

4.2 Gültigkeitsmodelle

Die mathematische Prüfung einer Signatur ist einfach. Es muß aber festgelegt werden, welche

Bedingungen die Gültigkeitszeiträume der Zertifikate entlang der Zertifizierungspfades erfüllen

müssen.

Gültigkeitsmodelle beschreiben, welche Eigenschaften zu welchen Zeitpunkten erfüllt sein müssen, um eine Signatur als gültig zu bewerten. Die beiden bekanntesten Modelle sind das Schalen- und das Kettenmodell. Ein aktueller Algorithmus zur Verifizierung eines Zertifikates entlang eines Zertifizierungspfades in einer X.509-PKI ist in einem Dokument der PKIX ([RFC2459]) ausführlich beschrieben.

4.2.1 Verifikation zum Verifikationszeitpunkt (Schalenmodell nach PEM)

Dieses Gültigkeitsmodell wird im PEM-Standard [RFC 1421-1424] beschrieben. PEM ist ein Akronym

für "Privacy Enhancement for Internet Electronic Mail"17. Das PEM-Protokoll war der erste Ansatz,

Verschlüsselung, Authentisierung, Nachrichtenintegrität und Schlüsselverwaltung bei elektonischem

Nachrichtenverkehr zu gewährleisten.Die Gültigkeit von Schlüsseln und Zertifikaten ist gemäß

RFC1422 wie folgt definiert18:

• Ein Schlüssel(-paar) ist zu einem bestimmten Zeitpunkt genau dann gültig, wenn zu diesem Zeitpunkt der zugehörige Zertifizierungspfad gültig ist.

• Ein Zertifizierungspfad ist zu einem bestimmten Zeitpunkt ganau dann gültig, wenn alle in

ihm enthaltenen Zertifikate zu diesem Zeitpunkt gültig sind.

• Ein Zertifikat ist zu einem bestimmten Zeitpunkt genau dann gültig, wenn

o die Signatur des Zertifikates gültig ist.

o der fragliche Zeitpunkt innerhalb des Gültigkeitszeitraums des Zertifikates liegt.

o das Zertifikat nicht in der zum Zeitpunkt der Prüfung aktuellen Sperrliste der

ausstellenden Zertifizierungsstelle enthalten ist oder das Zertifikat enthalten ist, der angegebene Sperrzeitpunkt jedoch nach dem fraglichen Zeitpunkt liegt.

Veranschaulicht wird die obige Beschreibung in Abbildung 7. Die ersten drei Zeilen stellen die

Gültigkeitsdauer der Zertifikate von der Root-CA, der CA und des Teilnehmers dar. Auf der Zeitachse

ist mit einem weißen Kreis der Signierzeitpunkt und mit einer grauen Raute der

Verifikationszeitpunkt aufgetragen. Die Pfeile symbolisieren, zu welchem Zeitpunkt das Zertifikat des

jeweils Ausstellenden (Zeile darüber) gültig sein muß.

Abbildung 7: Schalenmodell nach PEM

4.2.2 Modifiziertes Schalenmodell

Das modifizierte Schalenmodell entspricht dem eben beschriebenen Modell nach PEM mit der

besonderen Randbedingung, daß für die Überprüfung eines Zertifikatspfades der Zeitpunkt der

Dokumentsignaturbildung herangezogen wird und nicht wie nach PEM üblich der aktuelle Zeitpunkt

(Abb. 8).

Abbildung 8: Modifiziertes Schalenmodell

4.2.3 Verifikation zum Signierzeitpunkt (Kettenmodell)

Das Kettenmodell hat schwächere Kriterien, ein Zertifikat als gültig zu bewerten. Es wird nur

gefordert, daß jedes Zertifikat im Zeitpunkt seiner Anwendung gültig war. Das bedeutet: zum

Signierzeitpunkt des Dokuments muß das Teilnehmer-Zertifikat ZTN gültig gewesen sein. Zum

Zeitpunkt der Zertifizierung desTeilnehmer-Zertifikates muß das CA-Zertifikat ZCA gültig gewesen sein

usw. (siehe Abb. 9). Ob ein Zertifikat seit der Dokumentsignatur gesperrt wurde, bleibt in diesem

Modell unberücksichtigt.

Abbildung 9: Kettenmodell

4.3 Bewertung der Gültigkeitsmodelle anhand von Problemfällen

Um die vorgestellten Gültigkeitsmodelle beurteilen zu können, werden jetzt einige Szenarien

vorgestellt, in denen das CA-Zertifikat kompromittiert wurde. Dies sind Angriffe auf eine PKI mit

großem Gefährdungspotential und natürlich alleine nicht maßgebend für eine objektive Bewertung.

Sie sollen aber zeigen, daß die drei Gültigkeitsmodelle in den einzelnen Szenarien zu

unterschiedlichen Prüfungsergebnissen gelangen. In Abbildung 10 sind diese Szenarien dargestellt.

Die folgende Tabelle gibt die Resultate der drei Gültigkeitsmodelle in den fünf verschiedenen Szenarien wieder:

Modell Gültigkeit

A B C D E

Schalenmodell nein nein nein nein nein

Modifiziertes Schalenmodell nein nein ja ja ja

Kettenmodell ja ja ja ja ja

Besonderheiten der einzelnen Gültigkeitsmodelle sind:

1. Schalenmodell

o Zertifikatprüfung und Sperrabfrage erfolgt zum Prüfzeitpunkt.

o Es wird nicht überprüft, ob das Zertifikat zum Signierzeitpunkt gültig war. o Mit Hilfe eines kompromitterten CA-Schlüssel können TN-Zertifikate gefälscht und

darauf basierende Signaturen erzeugt werden.

2. Modifiziertes Schalenmodell

o Es können auch Signaturen als gültig geprüft werden, deren Zertifikat zum aktuellen

Zeitpunkt bereits abgelaufen ist.

o Die Gültigkeit des Zertifikates bleibt nicht von der Rücknahme des CA-Zertifikates

unberührt.

3. Kettenmodell

o Einfacher als Schalenmodell, besonders bei vielen Zertifikaten.

o Gültigkeitsdefinition ist unpassend,da der Zeitraum zwischen Zertifizierung eines

Zertifikates und dessen Anwendung (Signatur) wird nicht berücksichtigt.

o Bei sehr wichtigen Vertragsabschlüssen wäre eine Positiv-Verzeichnisabfrage zum

Prüfungszeitpunkt nötig

Problematisch ist, daß abgelaufene Zertifikate nicht mehr in der CRL geführt werden. Der

Kompromittierungszeitpunkt kann nicht mehr bestimmt werden.

Abbildung 10: Problematische Szenarien

Alle Gültigkeitsmodelle gehen davon aus, daß der Zertifizierungspfad zum Beginn der Prüfung bekannt ist. Was passiert aber, wenn auf eine Anfrage an den Verzeichnisdienst mehrere Antworten zurückgeliefert werden. Das kann vorkommen, wenn eine CA mehrere

Schlüsselpaare zur Signatur benutzt; anhand des Namens kann nicht auf den richtigen Schlüssel geschlossen werden. Der Prüfalgorithmus muß dann alle möglichen Wege ausprobieren. Hier treten Probleme aus der Graphentheorie auf, da statt einem hierarchischen Baum eine Netzstruktur zu traversieren ist.

Keines der Modelle berücksichtigt den Grund für die Sperrung eines Zertifikates. Es ist ein großer Unterschied, ob ein Schlüssel verloren oder kompromittiert wurde. Wurde der Schlüssel nur verloren, bleiben alle signierten Dokumente bzw. Zertifikate gültig. Dies gilt für die CA- wie auch für Teilnehmer-Schlüssel. Das Schalenmodell ist nicht praktikabel, da es zu streng ist. Bei der Langzeitspeicherung von Dokumenten und der damit verbundenen Prüfung nach Ablauf des Teilnehmer-Zertifikates prüft das Schalenmodell die Signatur als ungültig. Das Kettenmodell ist - wegen seines schwachen Gültigkeitsbegriffs - nicht anwendbar. Es bildet aber die Basis interoperabeler Verfahren für das Signaturgesetz19.

5 Angriffe auf die Zertifizierungsinfrastruktur

In diesem Abschnitt werden einige aktive Angriffe auf die Zertifizierungsinfrastruktur beschrieben20.

Der zweite Teil befaßt sich dann mit Erweiterungen von X.509v3-Zertifikaten, die Möglichkeiten

bieten, einige dieser Angriffe zu erkennen oder zu vereiteln.

5.1 Auswahl aktiver Angriffe

5.1.1 Kompromittierung der Teilnehmer-Schlüssels

Wenn der private Schlüssel eines Teilnehmers kompromittiert wurde, hat der Angreifer die

Möglichkeit, Dokumente mit korrekten digitalen Signatur des Teilnehmers zu versehen. Der

Empfänger kann den Betrug nicht feststellen.

Der Teilnehmer muß, nachdem er die Kompromittierung bemerkt hat, sein Zertifikat widerrufen (erfolgt durch Eintrag in der CRL), damit alle potentiellen Empfänger falsch signierter Dokumente den Betrug erkennen. Anschließend muß er ein neues Schlüsselpaar erzeugen und für dieses ein Zertifikat bei der CA beantragen. Früher signierte Dokumente, die zeitgestempelt sind, behalten ihre Authentizität. Alle anderen müssen bei Bedarf mit dem neuen privaten Schlüssel erneut signiert werden.

5.1.2 Abstreiten der eigenen Signatur

Ein Teilnehmer kann seinen eigenen Schlüssel als ungültig erklären und damit geleistete

Unterschriften (in einem bestimmten Zeitraum) als ungültig abstreiten. Abhilfe kann in wichtigen

Angelegenheiten geschaffen werden, indem der Empfänger auf einer Signatur durch den

Zeitstempeldienst (siehe Kap. 2.5.4) besteht.

5.1.3 Untergeschobener falscher Public Key

Wenn der öffentliche Schlüssel zum Prüfen einer Signatur falsch ist, d.h. die Bindung zwischen

Schlüssel und Zertifikat (bzw. Identität) nicht korrekt ist, kann keine Prüfung erfolgen. Im

allgemeinen kann der Empfänger nicht entscheiden, ob der Public Key falsch ist, oder ob das

Dokument nachträglich verändert wurde.

5.1.4 CA Kompromittierung

Wenn der private Schlüssel der CA kompromittiert wird, kann ein Angreifer ein neues Zertifikat mit

dem Namen und der Seriennummer eines alten Zertifikates, aber mit einem neuen Public Key

erzeugen. Anfragen an den Verzeichnisdienst liefern dann zurück, daß das Zertifikat gültig war. Der

Grund dafür ist, daß der Verzeichnisdienst Zertifikate anhand des Namens und der Seriennummer,

aber nicht anhand des Public Key identifiziert.

Damit im Falle einer Kompromittierung des CA-Schlüssels der Angreifer nicht in den Besitz aller Zertifikate kommt, könnte man statt des signierten Teilnehmer-Zertifikats nur den Hashwert davon zusammen mit einem Zeitstempel abspeichern.

5.1.5 CRL nicht verfügbar

Wenn die CRL bei der Überprüfung des Zertifikats nicht verfügbar ist, kann nicht geprüft werden, ob

ein bestimmtes Zertifikat widerrufen wurde oder nicht.

5.1.6 Untergeschobene (alte) CRL

Der Benutzer kann nicht feststellen, ob die erhaltene CRL die aktuellste ist. Der in der CRL

angegebene Gültigkeitszeitraum der CRL sagt nichts darüber aus, ob vor dem Ablauf nicht schon eine

neue CRL existiert hat, bzw. ob die verfügbare CRL auch die aktuelle ist. Abhilfe würde hier die

Möglichkeit einer Positiv-Abfrage beim Verzeichnisdienst schaffen.

5.1.7 Zerstörung der CA

Sichere Kommunikation ist nicht mehr möglich. Hier spielt des Schlagwort "Verletzlichkeit der

Gesellschaft" bzw. des Gesamtsystems eine entscheidende Rolle. Dieses Thema wird zum Beispiel

ausführlich in [Hamm93] diskutiert.

Bei all diesen Angriffen wird davon ausgegangen, daß die eingesetzte Software nicht manipuliert wurde und das Gesamtsystem konsistent läuft. Man spricht in diesem Zusammenhang auch von Trusted Operating Systems - sicherheitsgeprüfte Betriebssysteme, die einem bestimmten Sicherheitsniveau genügen. Ohne diese Annahme multiplizieren sich die Angriffsmöglichkeiten.

5.2 X.509v3 Erweiterungen - Ansätze zum Ausgleich der Schwächen

Für Zertifikate im X.509-Standard (siehe Kap. 2.4) gibt es zahlreiche Erweiterungen, die in ein

Zertifikat mit aufgenommen werden können. Durch sie kann der Einsatz des Zertifikates beschränkt

werden. Jeder Zertifikat-Inhaber bekommt nur so viele Rechte wie er benötigt. Die wichtigsten

Erweiterungen sind hier knapp erläutert. Näheres findet sich in [X.509v3].

key usage

ist ein Bitfeld, mit dem angezeigt werden kann, für welche Nutzung der in dem Zertifikat

enthaltene Schlüssel gedacht ist. So kann zum Beispiel der Schlüssel nur zum Signieren, aber

nicht zum Verschlüsseln von Daten eingesetzt werden.

key usage period

gibt dem Unterzeichner die Möglichkeit, einen Zeitraum anzugeben, in dem der private

Schlüssel zum Signieren benutzt werden darf. Diese Angabe ist zusätzlich zum

Gültigkeitszeitraums des Zertifikates.

authority key identifier

schafft eine Möglichkeit, den richtigen Public Key der Zertifizierungsstelle zu finden, falls die

CA mehrere Schlüsselpaare benutzt.

subject key identifier

dient zur Identifikation des richtigen öffentlichen Schlüssels des Teilnehmers. (siehe

authority key identifier)

certificate policy

enthält Informationen zur Policy, unter welcher der Schlüssel signiert wurde und für welche

Zwecke der Schlüssel zu gebrauchen ist. Applikationen, die bestimmte Policy-Anforderungen

stellen, vergleichen beim Überprüfen des Zertifikates ihre eigene Liste von Policy-Vorgaben

mit denen im Zertifikat.

policy mapping

werden benötigt, da möglicherweise verschiedene Aussteller ihre Policies unterschiedlich

bezeichnen. Hier können Paare von Policies angegeben werden, die vom Aussteller des

Zertifikates als vergleichbar eingestuft werden.

basic constraints

gibt Auskunft darüber, ob ein Zertifikat einer CA vorliegt, mit dem man weitere Zertifikate

ausstellen kann, oder nicht.

policy constraints

können benutzt werden, um policy mapping zu verhindern. Es kann auch gefordert werden,

daß jedes Zertifikat im Zertifizierungspfad einer bestimmten Policy unterliegt.

6 Beweiswert digital signierter Dokumente

Mit der Verbreitung digitaler Signaturen sind auch Risiken verbunden. Insbesondere wächst die

Abhängigkeit vom fehlerfreien Funktionieren dieser Technik. Bei Ausfall steht im elektronischen

Rechtsverkehr die eigenhändige Unterschrift als Ersatz nicht zu Verfügung. Außerdem fehlen für

elektronische Kommunikation die rechtlichen Formvorschriften. Es liegen kaum empirischen

Erkenntnisse vor.

Die technische Gültigkeit, wie sie in den vorangegangenen Kapiteln beschrieben wurde, reicht bei weitem nicht aus, um die rechtliche Gültigkeit zu zeigen. Es müssen Gesetze geschaffen werden, die den Beweiswert der digitalen Signatur vor Gericht regeln. Das technische Prüfergebnis muß dem jeweiligen Anwendungskontext entsprechend interpretiert werden.

Kettenmodell-(Un)Gültigkeitsprüfung allein ist rechtsunwirksam. Das wird an den drei folgenden Beispielen deutlich:

1. Kaufvertrag: Prüfergebnis: "Signatur gültig" (Begründung: Zertifikatsperrung nach

Signierzeitpunkt) - aber Vertrag ungültig, da Signierer nachweislich im Krankenhaus im Koma lag und nicht signieren konnte.

2. Strafanzeige: Prüfergebnis: "Signatur ungültig" (Begründung: Zertifikat abgelaufen) - aber

unerheblich, da eine strafrechtliche Verfolgungspflicht besteht.

3. Mandantenschreiben: Prüfergebnis: "Prüfung unmöglich" (Sperrdienst außer Betrieb) - aber

derAnwalt muß sofort über Revisionsantrag entscheiden.

Ein Lösungsvorschlag ist: Statt eines Einheitsgültigkeitsmodells sollten rechtsabhängige Varianten

spezifiziert werden. Ein Gültigkeitsmodell allein kann nicht allen Problemfällen gerecht werden. Der

Verifizierer gibt dem Prüfwerkzeug eine Konfiguration des Prüfprozesses mit, in der Gültigkeitsmodell

und Prioritäten der Prüfung festgelegt werden. Die Prüfanwendung liefert das Prüfungsergebnis in

einer einheitlich kodierten Form (was wurde wie geprüft). Die Interpretation findet im jeweiligen

Anwendungssystem statt.

Wichtig ist im Zusammenhang mit digitalen Signaturen auch die Darstellungskomponente eines Signier- und Verifikationssystems. Wenn der Signierer nicht das unterschreibt, was er auf dem Bildschirm sieht, kann mit digitalen Signaturen keine Rechtsverbindlichkeit erreicht werden. Ein Beispiel hierfür gibt Fox in [Fox97a]. Dabei wird ausgenutzt, daß verschiedene Anwendungen Sonderzeichen - spezifische Zeichen oberhalb des 7-bit ASCII-Zeichensatzes unterschiedlich interprtierem (oder auch ignorieren).

Es muß eine Trennung zwischen Anwendung (Interpretation des Prüfergebnisses), Prüftool (technische Prüfung) und der Darstellungskomponente erfolgen.

Wichtig ist, daß das Signaturgesetz (SigG) und die Signaturverordnung einige Bedingungen sicherer Anwendung und SigG-Gültigkeit digitaler Signaturen regelt, nicht die Rechtsgültigkeit signierter Dokumente.

Datenbank-Engines

db-engines.com. Abgerufen am 19. 06 2013 von http://db-engines.com/de/article/Sharding

Sharding

Sharding ist eine Methode der Datenbankpartitionierung. Dabei wird ein Datenbestand in mehrere Teile aufgeteilt und jeweils von einer eigenen Serverinstanz verwaltet. Z.B. Personen werden je nach Anfangsbuchstaben auf drei Server aufgeteilt: A-F, G-O, P-Z. Wann immer eine Person gespeichert oder über den Namen abgefragt wird, wird zuerst der zuständige Server bestimmt, an den der Request weitergeleitet wird.

Vorteile

Mittels Sharding können umfangreiche Datenmengen verwaltet werden, welche die Kapazitäten eines einzelnen Servers sprengen würden. Da die einzelnen Teile von einer eigenen Serverinstanz verwaltet werden, werden nicht nur die Daten selbst, sondern auch die dafür benötige Rechenleistung aufgeteilt.

Partitionsstrategie

Die Methode der Aufteilung, die sog. Partitionsstrategie, spielt dabei eine entscheidende Rolle. Das obige Beispiel der Aufteilung nach Anfangsbuchstaben hat den Vorteil, dass auch Abfragen sortiert nach dem Aufteilungskriterium leicht möglich sind. Ein gravierender Nachteil ist allerdings, dass das Hinzufügen weiterer Server umfangreiches Umspeichern erfordert. Daher werden, vor allem in Szenarien mit Dutzenden oder Hunderten Server, eher Hash-basierte Verfahren verwendet. Dabei kommen sog. konsistente Hash-Funktionen zum Einsatz, welche die Anzahl der in diesen Fällen notwendigen Umspeicherungen minimieren.

Nachteile und Restriktionen

Der größte Nachteil des Shardings ist natürlich, dass ein Zugriff über andere Kriterien als das Aufteilungskriterium unverhältnismäßig aufwändig ist. Abfragen über andere Kriterien oder Joins müssen i.A. auf alle Server aufgeteilt werden. Das Datenmodell und die Zugriffspfade müssen so designed werden, dass derartige Zugriffe nur selten oder gar nicht vorkommen, sonst werden die Vorteile des Shardings zunichte gemacht.

Diese Notwendigkeit macht Sharding zu einer attraktiven Methode vor allem für NoSQL-Systeme, bei denen typischerweise Joins ohnehin nicht unterstützt werden, und auch Zugriffe über Sekundärschlüssel eher eine Ausnahme sind. Somit lässt sich Sharding für diese Systeme vergleichsweise einfach implementieren. Man kann sogar sagen, dass das relativ problemlose Sharding einer der Hauptgründe für den rasch steigenden Einsatz von NoSQL-Systemen ist.

Sharding und Replikation

Bei mehreren NoSQL-Systemen wird Sharding und Replikation auf elegante und effizient Weise verknüpft, etwa bei Cassandra und Riak. Dabei wird z.B. in einer ringförmigen Anordnung der Server jeder Shard auch gleichzeitig auf einen oder mehrere nachfolgende Server im Ring repliziert. Somit hält jeder Server jeweils eine Kopie mehrerer Shards. Durch

diese Anordnung und die dazugehörigen komplexen Datenabgleichsmechanismen entstehen sehr flexible und fehlertolerante Systeme, welche auch mit sehr großen Datenmengen befüllt werden können.

Applikationsseitiges Sharding

Ein Sharding-Mechanismus kann natürlich auch in der Datenbankapplikation implementiert werden, indem über eine Partitionsstrategie auf unabhängig voneinander arbeitende Server zugegriffen wird. Eine derartige Nachimplentierung von Serverfunktionalität ist aber nicht nur aufwändig und fehleranfällig, sie stößt bei komplexeren Szenarien auch rasch an Grenzen. Im Zweifelsfall ist bei der Notwendigkeit von Sharding ein Umstieg auf ein Datenbank-managementsystem, welches von sich aus Sharding unterstützt, immer vorzuziehen.

ENBW ENBW.com. Abgerufen am 08. 07 2013 von

https://www.enbw.com/demo-kundenzentrum/#

Heise

Heise.de. Abgerufen am 07. 07 2013 von http://www.heise.de/newsticker/meldung/Energie-sparen-mit-dem-Stromzaehler-202105.html

Energie sparen mit dem Stromzähler

Der vernetzte Stromzähler der EnBW soll den Stromverbrauch nahtlos überwachen und nebenbei Standby-Energieschleudern enttarnen. Ab dem Sommer will die EnBW in Baden-Württemberg ihren Stromkunden einen intelligenten Stromzähler ins Heimnetz hängen, der eine sekundengenaue Abfrage der aktuell gezogenen Leistung, umgangssprachlich Stromverbrauch, per PC ermöglicht. Mit dem Gerät soll man nicht nur Standby-Energiefressern auf die Schliche kommen, sondern gar potenzielle Gefahrenquellen entdecken können. Als Beispiel für Ersteres führt die EnBW eine Espressomaschine an, die im Standby das Wasser warm hält, damit der Kaffee möglichst schnell bereit steht. Allein diese Komfortfunktion verursacht über 30 Euro Stromkosten pro Jahr. Demgegenüber macht das Aufbrühen von fünf Tassen Espresso täglich ohne Standby nur zwei Euro aus, auch wenn man etwas länger warten muss. Auch deutlich weniger auffällige Standby-Stromschleudern wie Hifi-Anlagen soll man aufdecken können, denn das Gerät zeigt die durchgehende Leistung aufs Watt genau an, heißt es. Mit Gefahrenvermeidung meint die EnBW, dass man beispielsweise beim Verlassen der Wohnung automatisch informiert wird, wenn bestimmte Verbraucher wie etwa der Elektroherd noch eingeschaltet sind.

Der Zähler meldet den aktuellen Verbrauch über einen bestehenden Breitband-Internetanschluss an den Stromlieferanten. Dafür besitzt er ein integriertes Powerline-Modul, das von Devolo stammt. Ein mitgeliefertes Gegenstück im üblichen Steckernetzteilformat schließt man per LAN-Kabel an seinen Heimrouter an. Da der Zähler alle Viertelstunde ein

Update schickt, ist eine DSL-Flatrate sinnvoll. Er puffert die Messwerte aber auch bis zu drei Monate lang, falls jemand seinen Internetzugang selten nutzt und dann manuell aktiviert. Im Pilotversuch, der mit zweimal 1000 Kunden seit Sommer 2007 läuft, geschieht die XML-Datenübermittlung noch im Klartext per http über Port 8080, sodass man mit recht geringem Aufwand verfolgen kann, welche Daten das Heim verlassen. Der Regelbetrieb wird dagegen verschlüsselt per https geschehen. Das wird Datenschützern nicht schmecken, aber wohl kaum zu vermeiden sein, damit Bastler nicht mittels angepasster Firewall-Regeln im Eigenbaurouter ihre Stromkosten drücken.

Das auf der Hannover Messe in Halle 13, Stand C10 zu sehende System ist indes nicht aus reiner Nächstenliebe entstanden. Vielmehr hat die EU den Stromlieferanten ins Stammbuch geschrieben, dass sie ihren Kunden bis 2012 die Energiekosten monatlich transparent machen müssen. Das dürfte auf eine monatliche Abrechnung wie beim Telefonanschluss oder Handy hinauslaufen, wenn die EU-Vorgabe einst in nationales Recht umgesetzt ist. Da aber kaum ein Kunde alle vier Wochen eine Postkarte mit dem aktuellen Zählerstand ausfüllen will und auch die Versorger ihre Ableser gewiss nicht zwölfmal so oft wie bisher herumschicken wollen, ist der Einsatz intelligenter Zähler mittelfristig unausweichlich.

Für die fernere Zukunft strebt die EnBW an, mit Haustechnikherstellern wie Miele oder Bauknecht zu kooperieren, damit sich energieintensive Hausgeräte fernsteuern lassen. So soll der Kunde beispielsweise sein Brot nachts zu einem günstigeren Niedrigtarif backen. Den Stromlieferanten beschert die Fernsteuerbarkeit den Vorteil, ihre Netzauslastung besser steuern zu können. Zur Höhe der Tarife mochte EnBW noch keine Details nennen. heise online konnte lediglich erfahren, dass geringe Installationskosten, eine monatliche Grundgebühr sowie eine zwölfmonatige Mindestbindung anfallen. (ea)

HS-Mannheim

hs-mannheim.de. Abgerufen am 27. 06 2013 von http://www.am.hs-mannheim.de/KryptoLern/elgamal-signatur.php?p=467&g=2&a=127&k=213&h=100&h2=&debug=on

ElGamal Signaturverfahren

Benutzte Werte:

p: 467

g: 2

a: 127

k: 213

h: 100

Öffentlicher Schlüssel:

A = g^a mod p

= 2 ^ 127 mod 467

= 132

Der öffentliche Schlüssel besteht aus dem Tripel (p,g,A) = (467, 2, 132)

Der private Schlüssel besteht aus den beiden Zahlen (p,a) = (467, 127)

Signieren:

r = g^k mod p

= 2 ^ 213 mod 467

= 29

s = k^-1 * (h(x) - a*r) mod (p-1)

= (431 * (100 - 127*29) mod (467 - 1)

= 51

Verifizieren:

Erste Bedingung:

1 ≤ r < p:

1 ≤ 29 < 467

⇒ Erste Bedingung erfüllt.

Zweite Bedingung: A^r * r^s mod p = g^h(x) mod p

links = A^r * r^s mod p

= 132^29 * 29^51 mod 467

= 216 * 176 mod 467

= 189

rechts = g^h(x) mod p

= 2^100 mod 467

= 189

⇒ Zweite Bedingung erfüllt.

HU-Berlin

edoc.hu-berlin.de. Abgerufen am 21. 06 2013 von http://edoc.hu-berlin.de/master/ohst-daniel-2004-04-20/HTML/chapter3.html

3 Grundlagen elektronischer Signaturen und Zeitstempel

↓13

Kryptografische Algorithmen und Verfahren sind ein wesentlicher Bestandteil einer Lösung für die langfristige Sicherung von digitalen Dokumenten. In diesem Kapitel sollen die wesentlichen Begriffe eingeführt werden, die zum weiteren Verständnis notwendig sind. Es folgt eine Übersicht zu den rechtlichen Rahmenbedingungen des Einsatzes dieser Verfahren in Deutschland sowie zu den technischen Standards, die bei ihrer Implementation eingesetzt werden. Abschließend werden aktuelle Einsatzbeispiele sowie Probleme und Trends aufgezeigt.

3.1 Kryptografische Begriffe und Verfahren

Die Kryptografie ist die Wissenschaft vom Entwickeln von Algorithmen und Verfahren für sichere Kommunikation. Im Gegenzug beschäftigt sich die Kryptoanalyse mit Methoden zum Kompromittieren und Brechen dieser Verfahren. Wesentliche Grundanforderungen an sichere Kommunikation, die mit Hilfe kryptografischer Algorithmen erfüllt werden können, sind u.a. :

• Vertraulichkeit (Schutz von Daten vor unberechtigter Kenntnisnahme)

• Integrität (Schutz von Daten vor unberechtigter Veränderung)

• Authentizität (Sichere Identifikation von Kommunikationspartnern)

• Verbindlichkeit (Nichtabstreitbarkeit von Kommunikation)

↓14

Die folgenden Abschnitte sollen in knapper Form wesentliche kryptografische Begriffe und Verfahren einführen. Dabei wird Wert auf eine allgemein verständliche Darstellung gelegt, für eine intensivere Betrachtung der zugrunde liegenden mathematischen Grundlagen und Protokolle sei auf [Schneier96] oder auch viele andere Online-Quellen verwiesen. Für eine gute Darstellung der historischen Entwicklung von Kryptoalgorithmen kann [Bauer94] empfohlen werden.

3.1.1 Symmetrische Verschlüsselung

Bei diesem Verschlüsselungsverfahren wird ein Klartext unter Anwendung eines Schlüssels nach einem Algorithmus in einen Geheimtext überführt, der durch die Benutzung desselben Schlüssels wieder entschlüsselt werden kann. In der digitalen Welt wird ein Schlüssel durch eine Bitfolge bestimmter Länge dargestellt, der nach einem bestimmten Algorithmus mit dem digitalen Klartext verknüpft wird, um den Geheimtext zu erhalten. Da für Ver- und Entschlüsselung ein und derselbe Schlüssel genutzt wird, werden diese Verfahren als symmetrisch bezeichnet. Offensichtlich müssen sich Absender und Empfänger vorher auf

sicherem Weg auf den Schlüssel einigen. Die folgende Grafik illustriert ein typisches Ablaufschema einer symmetrischen Verschlüsselung.

Abbildung 3.1 Symmetrische Verschlüsselung

↓15

Ein bekannter Vertreter für symmetrische Algorithmen ist der Data Encryption Standard (DES), der bereits 1977 vorgestellt wurde und mit einer Schlüssellänge von 56 Bit arbeitet. Da diese Länge heute nicht mehr als sicher eingestuft ist, wird eine Variante, der Triple-DES, eingesetzt, der mit zwei oder drei Schlüsseln nach dem Grundalgorithmus arbeitet. Dieser Algorithmus ist lange Zeit der Verschlüsselungsstandard der US-amerikanischen Regierungsbehörden gewesen und soll durch seinen Nachfolger, den Advanced Encryption Standard (AES), der mit Schlüssellängen zwischen 128 und 256 Bit arbeitet, ersetzt werden. Weitere Beispiele sind IDEA, Blowfish, CAST oder RC4.

Symmetrische Verfahren erlauben eine schnelle und bei entsprechender Schlüssellänge sichere Verschlüsselung von Daten. Grundsätzlich problematisch ist die Vorab-Einigung auf einen Schlüssel zwischen je zwei Kommunikationspartnern. Dies kann durch Master-Key-Verfahren (Ableitung von Schlüsseln aus einem Hauptschlüssel) oder durch die nachfolgend beschriebenen asymmetrischen Verfahren gelöst werden.

3.1.2 Asymmetrische Verschlüsselung

Bei dieser Art der Verschlüsselung besitzt jeder Kommunikationspartner ein Schlüsselpaar – einen öffentlichen und einen privaten Schlüssel. Der Absender einer Nachricht verschlüsselt dabei die Daten mit dem öffentlichen Schlüssel des Empfängers, der die Nachricht dann mit seinem privaten Schlüssel entschlüsselt. Das bedeutet, dass der öffentliche Schlüssel problemlos allen Kommunikationspartnern zur Verfügung gestellt werden kann. Die beiden Schlüssel stehen in einer mathematischen Beziehung zueinander, können aber praktisch nicht

aus dem jeweils anderen abgeleitet werden. Die folgende Grafik zeigt den Ablauf einer Verschlüsselung und Entschlüsselung.

↓16

Abbildung 3.2 Asymmetrische Verschlüsselungsverfahren

Der bekannteste Vertreter dieser Algorithmen ist RSA (Rivest, Shamir, Adleman), der mit variablen Schlüssellängen (üblicherweise 1024-4096 Bit) arbeitet.

Asymmetrische Algorithmen haben den Vorteil, dass nur jeweils ein Schlüsselpaar pro Kommunikationspartner benötigt wird; es ist also im Gegensatz zu den symmetrischen kein Schlüsselaustausch vorab notwendig. Allerdings tritt hier das Problem auf, dass der Absender sich auf sichere Weise davon überzeugen muss, dass der ihm vorliegende öffentliche Schlüssel auch tatsächlich der Person des gewünschten Empfängers gehört. Dies wird mit Hilfe von Zertifikaten vertrauenswürdiger Stellen gelöst, die solch eine Zuordnung beglaubigen. Asymmetrische Algorithmen werden häufig für die Realisierung elektronischer Signaturen eingesetzt, wie im weiteren Verlauf des Kapitel beschrieben wird. Des Weiteren arbeiten asymmetrische Algorithmen mit größeren Schlüssellängen und benötigen wesentlich mehr Zeit für die Operationen als symmetrische Algorithmen. In der Praxis wird deshalb häufig die so genannte Hybrid-Verschlüsselung eingesetzt, bei der zunächst ein zufälliger symmetrischer Schlüssel gewählt wird, mit dem die Daten verschlüsselt werden. Anschließend wird nur dieser Schlüssel mit dem asymmetrischen Verfahren übertragen. Die nachstehende Grafik illustriert diesen Vorgang.

↓17

Abbildung 3.3 Hybride Verschlüsselung

3.1.3 Zertifikate

Der Einsatz asymmetrischer Verfahren erfordert ein Schlüsselmanagement, um einen sicheren und effektiven Einsatz zu ermöglichen. Im wesentlichen müssen folgende allgemeine Anforderungen erfüllt werden:

• Realisierung der Bindung öffentlicher Schlüssel an die jeweiligen Inhaber

• Vertrauenswürdige Beschaffung öffentlicher Schlüssel

• Abrufbarkeit von Informationen zu ungültigen Schlüsseln (z.B. nach Kompromittierung)

↓18

Zur Lösung werden Public-Key-Infrastrukturen (PKI) mit Zertifikaten eingesetzt. Ein Zertifikat ist eine elektronische Bestätigung bzw. Unterschrift einer vertrauenswürdigen Instanz unter einen öffentlichen Schlüssel einer Person. Diese Instanz wird auch als Certification Authority bezeichnet. Eine Zertifizierung kann auch hierarchisch über mehrere Stufen erfolgen. Ein Zertifikat enthält Angaben zum Aussteller, zum Inhaber, zur Gültigkeitsdauer, zu verwendeten kryptografischen Verfahren sowie Merkmale zur Verwendung des Zertifikats.

Das oberste Zertifikat, das meist selbst durch den Inhaber unterschrieben ist, wird als Root-Zertifikat (im Beispiel hisolutions3) bezeichnet. Der Aussteller eines Zertifikats muss sich in geeigneter Weise von der Identität des Antragstellers überzeugen. Dies kann auf unterschiedlichen Sicherheitsniveaus durchgeführt werden, für eine einfache Identifizierung reicht z.B. die Rückmeldung zu einer E-Mail aus, während für höchste Ansprüche der Antragsteller persönlich unter Vorlage seiner Personaldokumente identifiziert wird. Eine Zertifizierungsinstanz hält weiterhin ein Verzeichnis von zertifizierten öffentlichen Schlüsseln und ein Verzeichnis ungültiger Schlüssel (Certificate Revocation List) bereit.

3.1.4 Hash-Funktionen

↓19

Um die Integrität von Daten bei einer Übertragung zu sichern oder auch die Authentizität gegenüber dem Empfänger nachzuweisen, ist eine Operation über der gesamten Datenmenge vielfach zu langsam. An dieser Stelle werden Hash-Verfahren genutzt, die in der Lage sind, ein beliebig großes Dokument auf einen so genannten Fingerprint oder Hash-Wert konstanter Größe abzubilden. Zur Integritätssicherung wird dann nur noch mit diesem Wert gearbeitet. Hash-Verfahren haben folgende grundlegende Eigenschaften:

• Das Originaldokument kann nicht aus aus dem Hashwert erzeugt werden. Dies ist leicht

einzusehen, da der Hashwert wesentlich kürzer ist und damit die Information des Originals

verloren geht. • Es ist praktisch unmöglich, zwei Dokumente mit demselben Hashwert zu finden. Das

bedeutet, dass selbst zwei Textdateien, die sich nur in einem Byte unterscheiden,

vollkommen verschiedene Hash-Werte erzeugen. Selbstverständlich gibt es eine unendliche

Anzahl von Paaren von Dokumenten, die denselben Hashwert erzeugen, es ist jedoch äußerst

schwer, solche Paare zu finden.

Der heute am häufigsten eingesetzte Hash-Algorithmus ist der Secure Hash Algorithm (SHA-1), der mit einer Länge von 160 Bit arbeitet.

3.1.5 Signaturen

↓20

Mit elektronischen Signaturen wird versucht, ein Äquivalent zur eigenhändigen Unterschrift in der digitalen Welt zu schaffen. Wesentliche Funktionen der eigenhändigen Unterschrift sind:

• die Identitätsfunktion (sichert die Identität des Ausstellers),

• die Echtheitsfunktion (garantiert, dass der unterschriebene Text auch vom

Unterschreibenden stammt) ,

• die Abschlussfunktion (kennzeichnet den Text als endgültige und verbindliche Version),

• Warnfunktion (Schutz des Unterzeichners vor Übereilung), • Rechtsverbindlichkeit.

Die elektronische Signatur kann durch Nutzung von asymmetrischen Kryptoverfahren realisiert werden. Im Beispiel des RSA-Verfahrens wird der private Schlüssel des Absender genutzt, um die zu signierenden Daten bzw. ihren Hashwert zu verschlüsseln. Signatur und Klartext werden an den Empfänger übertragen. Dieser nutzt den öffentlichen Schlüssel des Absenders zur Prüfung des empfangenen Dokuments. Hier spielen dann wieder Zertifikate eine Rolle, damit der Empfänger auf geeignete Weise die Identität des Signierers und die Gültigkeit des verwendeten Schlüssels prüfen kann.

↓21

Abbildung 3.4 Elektronische Signatur

Eine spezielle Form von Signaturen sind Zeitstempel. Dabei wird die Signatur unter ein Dokument zusammen mit einer Zeitangabe erzeugt. Der Signierer sollte eine vertrauenswürdige Institution sein, um die Authentizität der Zeitinformation sicherzustellen. Ein Zeitstempel gibt also an, dass das zugrunde liegende Dokument spätestens zum angegebenen Zeitpunkt existiert hat. Damit eignen sich Zeitstempel hervorragend, um Signaturzeitpunkte authentisch festzuhalten, da die Gültigkeitsprüfung von verwendeten Zertifikaten immer auf diesen Zeitpunkt erfolgen muss.

In Bezug auf die anfangs formulierten Eigenschaften der eigenhändigen Unterschrift, kann folgende Bewertung bei Einsatz der elektronischen Signatur vorgenommen werden:

↓22

• Identitätsfunktion

Diese wird über das auf einer Chipkarte oder auch nur einer Datei gespeicherte persönliche

Zertifikat des Nutzers hergestellt. Die Verwendung des Signaturschlüssels kann erst nach

Eingabe einer PIN für eine Chipkarte oder einer Passphrase erfolgen. Eine zweifelsfreie

Zuordnung zur signierenden Person kann dadurch nicht hergestellt werden. Eine Chipkarte

kann gestohlen und eine PIN ausgespäht oder erpresst werden. Perspektivisch ist der Einsatz von biometrischen Merkmalen denkbar, die eine bessere Personenzuordnung ermöglichen.

• Echtheitsfunktion

Die Echtheit des signierten Dokuments wird durch Prüfung des erzeugten Hash-Werts

nachgewiesen. Dieser wird aber im Endeffekt nur über einer Bitfolge erzeugt und sagt nichts

über die konkrete Präsentation am Bildschirm aus, die der Signierer gesehen hat. Mögliche

Lösungen sind Standardpräsentationen für Dokumententypen [Pordesch01].

• AbschlussfunktionDurch die elektronische Signatur unter den Hash-Wert des Dokuments

lässt sich eine hohe Verbindlichkeit nachweisen. Jede anschließende Dokumentänderung

würde bei einer Prüfung sofort bemerkt werden. Wichtig ist jedoch auch wieder die Prüfung

dessen, was signiert wurde.

• Warnfunktion

Die Bedeutung einer eigenhändigen Unterschrift ist jedem sofort begreiflich. Niemand gibt

seine Unterschrift leichtfertig ab. Die Hemmschwelle ist deutlich geringer, wenn man nur

eine Chipkarte stecken und eine sechsstellige PIN eingeben muss. Zukünftig muss durch

technische Maßnahmen sichergestellt werden, dass dem Signierenden die Bedeutung seiner

Operationen bewusst ist.

• Rechtsverbindlichkeit Wie im Abschnitt „Rechtliche Rahmenbedingungen“ in diesem Kapitel noch ausführlicher

dargestellt wird, ist mit der Verabschiedung des Formanpassungsgesetzes 2001 die

qualifizierte elektronische Signatur der gesetzlich geforderten Schriftform in vielen Fällen

gleichgestellt.

3.2 Rechtliche Rahmenbedingungen

Das „Gesetz zur digitalen Signatur“, das am 1.8.1997 in Kraft trat, hatte zum Ziel, Rahmenbedingungen für digitale Signaturen zu schaffen, unter denen ihr Einsatz als sicher gelten kann. Während das Gesetz selbst im Wesentlichen nur Zielvorgaben enthielt, wurden in der gleichzeitig veröffentlichten Signaturverordnung sowie in den Maßnahmekatalogen auch konkrete technische und administrative Vorgaben gemacht. Es wurden jedoch keine rechtlichen oder prozessualen Regelungen verabschiedet. Vielmehr sollte durch die Sicherheitsvermutung des Gesetzes (digitale Signaturen, die die Anforderungen des Gesetzes und der Verordnungen erfüllen, können als sicher gelten) eine Verbesserung im Rahmen der freien Beweiswürdigung vor Gericht erreicht werden.

Das deutsche Signaturgesetz war das erste im EU-Rahmen, jedoch war abzusehen, dass eine Reihe von Ländern eigene Gesetze verabschieden würde. Um die nationalen Vorhaben zu harmonisieren, wurde im Jahre 2000 die „Richtlinie über gemeinschaftliche Rahmenbedingungen für elektronische Signaturen“ [SigRL00] verabschiedet. Die wesentlichen Ziele waren

↓23

• die Schaffung einer Basis für einheitliche gesetzliche Signatur-Regelungen in der EU, • die Stärkung von Vertrauen in die neuen Technologien und Erhöhung ihrer Akzeptanz,

• die Förderung des elektronischen Geschäftsverkehrs

• sowie die Gewährleistung der Freiheit des Binnenmarktes.

Wesentliche Punkte der Richtlinie sind

• die Einführung von drei Klassen von Signaturen (einfache, fortgeschrittene, qualifizierte),

• eine eingeschränkte Technik-Offenheit, die auch Signaturen zulässt, die nicht auf

asymmetrischen Verfahren beruhen; Einführung des allgemeineren Begriffs der

elektronischen Signatur,

• die Definition von Anforderungen an Signaturerstellungseinheiten und technische

Komponenten für Anbieter von Zertifizierungsdiensten und Anwendungskomponenten,

• die grundsätzliche Genehmigungsfreiheit für Zertifizierungsdienste und die freiwillige

Möglichkeit der Akkreditierung, • ein Diskriminierungsverbot für einfache Signaturen,

• eine Gleichstellung der qualifizierten Signatur mit der eigenhändigen Unterschrift, aber keine

Regelung zu gesetzlichen Formerfordernissen,

• die Einführung von Haftungsregelungen für Zertifizierungsdiensteanbieter

• sowie Regelungen zur Anerkennung von ausländischer Zertifikaten.

↓24

Die Anforderungen der Signaturrichtlinie wurden in dem geänderten Signaturgesetz von 2001 [SigG01] berücksichtigt. Die beweisrechtlichen Vorschriften wurden außerhalb des Signaturgesetzes erlassen. Die wesentlichen Regelungen des neuen Signaturgesetzes werden nachstehend beschrieben.

Die in der Richtlinie aufgeführten drei Klassen von Signaturen werden im Gesetz wie folgt definiert:

• Elektronische Signaturen: „Daten in elektronischer Form, die anderen elektronischen Daten beigefügt oder logisch mit ihnen verknüpft sind und die zur Authentifizierung dienen“. Beispiele hierfür sind eine eingescannte Unterschrift auf einem Fax oder auch nur eine getippte Unterschrift unter einem per E-Mail eingereichten Schriftsatz.

↓25

• Fortgeschrittene Signaturen sind elektronische Signaturen, die zusätzlich:

• ausschließlich dem Signaturschlüssel-Inhaber zugeordnet sind, • die Identifizierung des Signaturschlüssel-Inhabers ermöglichen,

• mit Mitteln erzeugt werden, die der Signaturschlüssel-Inhaber unter seiner alleinigen

Kontrolle halten kann,

• mit den Daten, auf die sie sich beziehen, so verknüpft sind, dass eine nachträgliche

Veränderung der Daten erkannt werden kann.

In der Gesetzesbegründung wird ausdrücklich PGP als Beispiel für fortgeschrittene Signaturen genannt. In neueren Untersuchungen [Rossnagel03b] kommt man jedoch nach genauerer Betrachtung der Anforderungen zu der Schlussfolgerung, dass reine Softwarelösungen im Allgemeinen nur einfache elektronische Signaturen erzeugen können. Fortgeschrittene Signaturen können jedoch z.B. von einer PGP-PKI mit chipkartenbasierter Schlüsselspeicherung erzeugt werden.

↓26

• Qualifizierte Signaturen sind fortgeschrittene Signaturen, die

• auf einem zum Zeitpunkt ihrer Erzeugung gültigen qualifizierten Zertifikat beruhen

• mit einer sicheren Signaturerstellungseinheit erzeugt wurden.

Nur für diese Art von Signaturen werden im Gesetz Regelungen und technische Maßnahmen im Rahmen der Signaturverordnung und der Maßnahmenkataloge definiert. Der Begriff des

Zertifizierungsdiensteanbieters bezieht sich nur auf Dienste, die qualifizierte Zertifikate ausstellen.

↓27

Sichere Signaturerstellungseinheiten sind Software- oder Hardwareeinheiten zur Speicherung und Anwendung des jeweiligen Signaturschlüssels, die bestimmten Anforderungen genügen. Für qualifizierte Signaturen ist dies derzeit die Chipkarte selbst. Signaturanwendungskomponenten sind Software- und Hardwareeinheiten, die Daten dem Prozess der Signaturerstellung zuführen und qualifizierte Signaturen und Zertifikate prüfen können.

Ein qualifiziertes Zertifikat besteht im Wesentlichen aus folgenden Angaben:

• Unverwechselbarer Name oder Pseudonym • Kryptografische Schlüssel und verwendete Algorithmen

• Gültigkeitszeitraum

• Name des Zertifizierungsdiensteanbieters und Land

• Angaben zur Selbstbeschränkung

• Attribute (berufsrechtliche Zulassung, Vertretung Dritter)

↓28

Der Zertifizierungsdiensteanbieter muss den Antragsteller vor der Ausstellung des Zertifikats zuverlässig identifizieren. Dies erfolgt in der Regel durch die direkte Vorlage von Personaldokumenten beim Anbieter oder durch die Nutzung anderer etablierter Verfahren, wie z.B. PostIdent.

Das Signaturgesetz legt weiterhin Anforderungen an den Betrieb eines Zertifizierungsdienstes fest, der grundsätzlich genehmigungsfrei ist. Es muss jedoch ein geeigneter Nachweis der Zuverlässigkeit und der Sachkunde geführt werden. Dies erfolgt durch ein vorzulegendes Sicherheitskonzept, das die Fachkunde der im Betrieb tätigen Personen und die Einhaltung der gesetzlichen Vorschriften und der technischen Vorgaben für die eingesetzten Produkte bestätigt. Dabei können Teilaufgaben eines Dienstes an Dritte ausgelagert werden, wenn diese angemessen in das Sicherheitskonzept einbezogen werden. So nutzen z.B. die Bundesnotarkammern die Infrastruktur des Anbieters Signtrust und übernehmen nur Teilaufgaben, wie z.B. die Registrierung der Antragsteller. Weiterhin muss der Zertifizierungsdiensteanbieter die geforderte Deckungsvorsorge im Falle einer Verletzung der gesetzlichen Vorschriften oder eines Fehler der eingesetzten Produkte nachweisen. Diese beträgt pro Fall 250.000 EUR. Für die eingesetzten Signaturerstellungseinheiten sowie für die technischen Komponenten der Zertifizierungsdienste ist die Bestätigung einer gesetzlich anerkannten Prüfstelle, wie z.B. des TÜV-IT, erforderlich. Für Signaturanwendungskomponenten ist eine Erklärung des Herstellers ausreichend.

Zur Erhöhung des Vertrauens in die Dienstleistungen eines Zertifizierungsdiensteanbieters sieht das Gesetz die freiwillige Möglichkeit der Akkreditierung vor. Hierbei wird durch die Behörde oder ein beauftragtes Unternehmen eine umfassende Prüfung der Implementation des Sicherheitskonzepts durchgeführt. Danach erhält der Anbieter ein Gütesiegel und kann sich

im Rechts- und Geschäftsverkehr auf die nachgewiesene Sicherheit berufen. Die Prüfung wird in regelmäßigen Abständen wiederholt. Die Root-Zertifikate für den Anbieter werden durch die RegTP ausgestellt. Ausgestellte Zertifikate sind noch mindestens 30 Jahre nach Ablauf der Gültigkeit überprüfbar zu halten, im Gegensatz zu 5 Jahren bei nicht akkreditierten. Bei Aufgabe des Diensts oder der Insolvenz des Anbieters sorgt die RegTP für die Übernahme der Verträge durch einen anderen Anbieter.

↓29

Auf den Webseiten der RegTP werden Listen mit den akkreditierten Anbietern sowie den Bestätigungen für Hardware- und Softwareprodukte veröffentlicht.

Parallel zum Signaturgesetz wurde die Signaturverordnung [SigV01] erlassen, die detailliertere Vorgaben zur Umsetzung der gesetzlichen Regelungen macht, so z.B. zum Inhalt des Sicherheitskonzepts und der Dokumentation, zur Arbeit von Prüf- und Bestätigungsstellen und zur Prüfung von technischen Komponenten.

Mit dem Formanpassungsgesetz 2001 [FormAnpG01] wurde eine Reihe von Gesetzen ergänzt und geändert, um die Gleichstellung von eigenhändiger Unterschrift und elektronischer Signatur in vielen Bereichen zu erreichen.

↓30

In §126 BGB wird festgelegt: „Die schriftliche Form kann durch die elektronische Form ersetzt werden, wenn sich nicht aus dem Gesetz etwas anderes ergibt.“ Für jene Regelungen, in denen die Schriftform gesetzlich festgelegt wurde, ist §126a ergänzt worden, der bestimmt: „Soll die gesetzlich vorgeschriebene schriftliche Form durch die elektronische Form ersetzt werden, so muss der Aussteller der Erklärung dieser seinen Namen hinzufügen und das elektronische Dokumente mit einer qualifizierten Signatur nach dem Signaturgesetz versehen“. Die Nutzung einer elektronischen Signatur wird für eine Reihe von Fällen explizit ausgeschlossen, wie z.B. für die Ausstellung von Zeugnissen oder die Abgabe von Bürgschaftserklärungen. Dennoch kann eine Vielzahl von Rechtsgeschäften nun auch in elektronischer Form abgeschlossen werden, ohne die Beweiswirkung vor Gericht zu verlieren. Dazu wurde die Zivilprozessordnung geändert, die jetzt in §292 bestimmt: „Der Anschein der Echtheit einer in elektronischer Form (§ 126a des BGB) vorliegenden Willenserklärung, der sich auf Grund der Prüfung nach dem Signaturgesetz ergibt, kann nur durch Tatsachen erschüttert werden, die ernstliche Zweifel daran begründen, dass die Erklärung mit dem Willen des Signaturschlüssel-Inhabers abgegeben worden ist.“ Während auch einfache elektronische Signaturen als Beweismittel im Prozess im Rahmen der freien Beweiswürdigung beigebracht werden konnten, wird hiermit für qualifizierte Signaturen eine gesetzliche Vermutung angeordnet. Damit erhöht sich insbesondere für den Empfänger einer Signatur die Sicherheit, da nicht er nachweisen muss, dass die Signatur auf korrekte Weise erstellt wurde. Vielmehr muss der Signaturschlüssel-Inhaber ernstliche Zweifel an der gesetzeskonformen Signaturerstellung vorbringen. Die Prüfung der Signatur nach dem Signaturgesetz besteht im Wesentlichen also darin zu prüfen, ob ein qualifiziertes Zertifikat vorliegt, das zum Zeitpunkt der Signaturerstellung nicht gesperrt war, ob eine sichere Signaturerstellungseinheit und sichere Anwendungskomponenten genutzt wurden. Gegebenenfalls kann auch die Prüfung der technischen Komponenten des Zertifizierungsdiensteanbieters einbezogen werden. Hier zeigen sich dann die Vorteile einer

Akkreditierung, da diese Prüfung schon vorab durch die zuständige Behörde durchgeführt wurde. Problematisch ist bei akkreditierten Signaturen die Prüfung auf die Verwendung von bestätigten Anwendungskomponenten, wie sie für akkreditierte Anbieter vorgeschrieben sind. Da es aus technischen Gründen nicht ohne weiteres möglich ist, den Signaturschlüssel-Inhaber zur Nutzung bestätigter Komponenten zu zwingen, ist hier die Sicherheit der zu prüfenden Signatur angreifbar. Nach [Jungermann02] sind diese Faktoren im Rahmen des Erschütterungsbeweises zu berücksichtigen.

3.3 Technische Standards und Regelungen

Zur Implementation von elektronischen Signaturen sind vielfältige Festlegungen zu den Strukturen der verwendeten Konstrukte (Zertifikate, Signaturen, Zeitstempel, Verzeichnisse usw.) und zu ihrer inhaltlichen Ausgestaltung als auch zu Prozessen und Kommunikation zwischen verschiedenen Diensten und ihren Objekten zu treffen. Diese Festlegungen erfolgen üblicherweise im Rahmen von Standards verschiedener internationaler und nationaler Organisationen. Der folgende Abschnitt soll nur einen sehr kurzen Überblick zu der Vielzahl existierender Standards sowie Harmonisierungsbestrebungen und neueren Entwicklungen geben.

Die Internet Engineering Task Force (IETF) ist eine der wichtigsten Organisationen im Bereich Internetstandards und veröffentlicht die so genannten RFCs (Request for Comments). Im europäischen Rahmen veröffentlicht das European Telecommunications Standard Institute (ETSI) Standards für den Bereich Telekommunikation, wie z.B. ETSI 101903 zu XAdES (XML Advanced Digital Signatures).

↓31

Ein wichtiges Standardisierungsprojekt ist ISIS-MTT, das vom Teletrust-Verein initiiert wurde. Die besondere Bedeutung besteht darin, dass auch die konkrete Implementation von Formaten und Diensten berücksichtigt wird, um eine hohe Interoperabilität zwischen Public Key Infrastrukturen zu erreichen. Die wesentlichen Ziele von ISIS-MTT sind:

• die Auswahl von existierenden technischen Standards, die für das Anwendungsgebiet

relevant sind und durch die Nutzer implementiert werden müssen,

• die Reduzierung von Implementationsvarianten um die Interoperabilität zu erhöhen und

Kosten für Implementation und Tests zu senken,

• die Ergänzung der referenzierten Standards um Aspekte, die für die Erreichung der

Interoperabilität notwendig sind.

Eine Übersicht zu den einbezogenen Standards zeigt die folgende Abbildung (aus [Fiedler03]):

↓32

Der Standard bietet trotz der Formulierung von Implementationsdetails durch Profile genügend Gestaltungsspielraum. Des Weiteren wurde ein Testbed für ISIS-MTT entwickelt, das es Anwendungsentwicklern ermöglicht, ihre Produkte auf Standard-Konformität zu testen. Dies hat wesentlich zur Erhöhung der Akzeptanz beigetragen. Die deutschen Trustcenter haben bereits ihren Betrieb auf ISIS-MTT umgestellt oder werden dies noch im Laufe des Jahres tun, was eine wesentliche Verbesserung in der Anwendung elektronischer Signaturen verspricht. So lassen sich dann Signaturen von Fremdanbietern mit der eigenen Anwendung prüfen oder auf einfachere Art und Weise die Dienste mehrerer Anbieter nutzen.

Eine weitere vielversprechende Entwicklung bei Standards für elektronische Signaturen sind XML-Signaturen. XML hat sich in vielen Bereichen als Austauschformat für strukturierte Daten etabliert, z.B. in Business-Workflows zur Datenübertragung zwischen den Prozessschritten. Vorteilhaft ist hierbei die leichte Erfassbarkeit und Flexibilität der XML-Strukturen. So ist es nur folgerichtig, die Möglichkeit zu schaffen, XML-Dateien oder bestimmte Teile davon mit elektronischen Signaturen zu versehen, um während des Prozesses die Authentizität und Integrität transportierter Daten zu sichern. Die XML Signature Working Group hat im RFC 3275 dazu einen entsprechenden Vorschlag unterbreitet. Mit dem ETSI-Standard 101903 wurden XML-Strukturen vorgeschlagen, um die langfristige Verfügbarkeit von Signaturen zu sichern, wie z.B. Erneuerung von Signaturen oder die Speicherung von Prüfinformationen zur Zertifikatskette.

↓33

Weitere technische Anforderungen ergeben sich aus dem Signaturgesetz bzw. seinen nachgeordneten Dokumenten, wie der Signaturverordnung oder den Maßnahmekatalogen des BSI. Hier werden konkrete Vorgaben für die Implementation von Diensten und Kriterien für die Prüfung von Komponenten formuliert. So wird z.B. für die Signaturerstellungseinheiten (sofern sie für qualifizierte Signaturen genutzt werden sollen) die Prüftiefe EAL4 oder E3 nach den „Common Criteria for Information Technology Security Evaluation“ bzw. den ITSEC-Kriterien gefordert. Des Weiteren wird jährlich ein Dokument veröffentlicht, das die Sicherheitseignung von verwendeten kryptografischen Algorithmen für die nächsten Jahre bewertet und das insbesondere für die Langzeitarchivierung von Signaturen bedeutsam ist [BSI03].

3.4 Aktuelle Einsatzbereiche von Signaturen und Zeitstempeln

Obwohl Deutschland mit der Einführung des Signaturgesetzes 1997 schon sehr früh rechtliche Regelungen für elektronische Signaturen formulierte, um ihnen zu einem breiten Einsatz zu verhelfen, ist die Zahl der Nutzer und der sinnvollen Anwendungen bis heute noch als gering einzustufen. Derzeitig arbeiten sechs nach dem Signaturgesetz akkreditierte Trustcenter (Authentidate, Datev, D-Trust, Signtrust, TC Trustcenter und Telesec), die auch eine eigene Infrastruktur aufgebaut haben. Weitere 18 Trustcenter besitzen ebenfalls eine Akkreditierung, nutzen jedoch zu großen Teilen die Infrastruktur der vorgenannten Anbieter und führen selbst im Allgemeinen nur die Registrierungs-Dienstleistungen durch. Somit sind bereits in den letzten Jahren große Investitionen in diesem Bereich vorgenommen worden, die derzeit noch unzureichend durch Anwendungen kompensiert werden.

Während die Nutzung von elektronischen Signaturen bei Privatkunden eher gering ist, nehmen die Anwendungsfelder im Businessumfeld zu. So arbeitet Authentidate, als Spezialist für Zeitstempeldienste, derzeit an Projekten zur automatisierten Erzeugung von qualifizierten Zeitstempeln in Workflow-und Archivsystemen, so z.B. im Bundesministerium für Wirtschaft und Arbeit. Bei der Kaufmännischen Krankenkasse (KKH) wurde die Erfassung der Arbeitgeber-Beitragsnachweise komplett auf die elektronische Archivierung umgestellt, was erhebliche Kosten im Vergleich zur Archivierung der Papierunterlagen einspart. Während es im Geschäftsumfeld durchaus eine Vielzahl von Projektansätzen aber auch schon erfolgreich umgesetzten Lösungen gibt, ist die Verfügbarkeit von Lösungen für Privatpersonen deutlich eingeschränkter. Dies hat unterschiedliche Ursachen, die im Abschnitt „Probleme und Trends“ noch einmal genauer dargestellt werden. Der Mobilfunkanbieter T-Online bietet seit einiger Zeit die Möglichkeit, sowohl Rechnung als auch Einzelverbindungsnachweis mit einer qualifizierten Signatur versehen elektronisch abzurufen. Diese werden vom Finanzamt anerkannt [StÄndG01]. Dabei muss der Nutzer nicht einmal eine eigene Signaturinfrastruktur besitzen.

↓34

Mit dem Projekt Media@komm wird in drei Modellstädten (Bremen, Esslingen, Nürnberg) die virtuelle Stadt modellhaft entwickelt. Ein Teilbereich umfasst auch die Ausgabe von Chipkarten zur Erzeugung von qualifizierten Signaturen an die Bürger, damit diese Dienstleistungen der Behörden auch auf elektronischem Wege in Anspruch nehmen können. So sind über 100 Anwendungen von der Beantragung von KfZ-Kennzeichen bis zu Bauanträgen online durchführbar. Die Signaturkomponenten werden den Bürgern hierbei zum stark ermäßigten Preis von 15 EUR zur Verfügung gestellt.

Es existiert noch eine Reihe weiterer Projekte, die größtenteils jedoch Pilotcharakter in kleinen Nutzergruppen haben, wie z.B. der Zugriff auf Rentenkonten der BfA.

Um die Nutzung elektronischer Signaturen voran zu bringen und dabei alle relevanten Partner zu beteiligen, wurde am 3. April 2003 das „Bündnis für elektronische Signaturen“ gegründet. Die Gründungspartner stammen aus den Bereichen Öffentliche Verwaltung, Banken, Versicherung, Trustcenter und Pilotprojekte. Ziele des Bündnisses sind

↓35

• die Schaffung eines investitionsfreundlichen Klimas auf Basis gemeinsamer Standards für

Anwendung elektronischer Signaturen

• sowie die Entwicklung realistischer Geschäftsmodelle für interoperable Infrastrukturen und

wirtschaftliche Anwendungen

Die Ziele sollen durch Umsetzung so genannter Konvergenzziele erreicht werden:

• Standardkonformität der Komponenten (PKI-Dienste, Chipkarten, Chipkartenleser, PKI-

Anwendungen)

• Multifunktionale Chipkarte • Einheitliche Sicherheitsniveaus für PKI-Anwendungen

• Ermöglichung des Einsatzes qualifizierter Signaturen

↓36

Die Ziele sollen bis Ende 2005 erreicht werden. Jeder Teilnehmer entscheidet jedoch selbst darüber, wie und in welchen Schritten dies durchgeführt wird. Das Bündnis wird mit anderen Initiativen oder Projekten, wie z.B. mit D21 oder E-Government SAGA, koordiniert. Banken und Sparkassen sehen sich aufgrund ihrer langjährigen Erfahrungen im Bereich Karten-Rollout in der Lage, auch für ihre Kunden Chipkarten mit Signaturfunktionalität anzubieten. Die Ausgabe ist schon im Rahmen von Pilotprojekten erfolgt, die EC-Karte soll um Chips erweitert werden, die auch Signaturen erzeugen können.

Die Nutzung von elektronischen Signaturen ist erst an wenigen Hochschulen vorgesehen oder schon eingeführt. Die Universität Dortmund versieht die im System ELDORADO veröffentlichten Hochschulschriften mit digitalen Signaturen für die PDF-Dokumente [UBDO03]. Im Archiv-System MONARCH der Technischen Universität Chemnitz werden mehrere Hash-Werte für Dokumente erzeugt und mit einer PGP-Signatur versehen. An der HU Berlin werden qualifizierte Signaturen mit Anbieterakkreditierung verwendet, um die archivierten Dateien zu sichern. Die Empfehlungen der Deutschen Initiative für Netzwerkinformation (DINI) sehen ebenfalls die Nutzung gesetzeskonformer Signaturen für die Dokumentensicherung vor [DINI02].

3.5 Aspekte der Langzeitarchivierung elektronischer Signaturen

In vielen Anwendungsbereichen ist es notwendig, Dokumente über einen langen Zeitraum aufzubewahren. Dies ergibt sich oft schon aus gesetzlichen Regelungen. Im Übrigen sind Dokumente so lange aufzubewahren, wie der Inhalt eine vertragliche oder eine andere rechtliche Wirkung entfalten kann.

↓37

Elektronische Signaturen und die zugrunde liegenden Dokumente müssen genau wie papiergebundene Publikationen ebenfalls einem Archivierungsprozess unterworfen werden. Im Kapitel 2 wurde bereits die Problematik der Langzeitarchivierung von digitalen Dokumenten kurz angerissen, hier sollen spezielle Aspekte betrachtet werden, die sich für Signaturen ergeben.

Die kryptografischen Algorithmen, die die Basis für die Implementation elektronischer Signaturen darstellen, können im Laufe der Zeit ihre Sicherheitseignung verlieren. Zum einen besteht die Möglichkeit, dass durch die ständig steigenden Rechenkapazitäten oder die optimierte Implementation von Algorithmen die verwendete Schlüssellänge nicht mehr ausreicht, um eine Brute-Force-Attack zu überstehen. Hierbei werden systematisch alle möglichen Schlüssel ausprobiert, was vielfach durch verteilte Rechnernetzwerke realisiert wird. So konnte z.B. ein 56-Bit Schlüssel bei DES-Verschlüsselung im Jahre 1999 schon nach 23 Stunden ermittelt werden. Im selben Jahr wurde ein 512-Bit Schlüssel für RSA ermittelt, für den allerdings gute fünf Monate Rechenzeit erforderlich waren [Clayton01]. Die Verlängerung eines Schlüssels lässt jedoch den Aufwand für seine Ermittlung exponentiell steigen. Die RegTP veröffentlicht einmal pro Jahr ein Dokument, in dem sichere Algorithmen und empfohlene Schlüssellängen für die jeweils kommenden sechs Jahre aufgeführt werden [RegTP03a]. So ist z.B. RSA mit 1024 Bit noch als ausreichend sicher bis Ende 2008 angesehen. Die Empfehlung lautet allerdings schon heute, Schlüssel mit 2048 Bit einzusetzen.

Eine andere Möglichkeit des Verlusts der Sicherheitseignung, ist das vollständige oder teilweise Brechen des Algorithmus. Die hier verwendeten Algorithmen basieren auf schwer, d.h. nur mit exponentiellem Aufwand, lösbaren Problemen, so z.B. der Primzahl-Faktorisierung. Auch wenn derzeit keine Methoden zur effizienten Berechnung bekannt sind, bedeutet dass nicht, dass es nicht möglich ist. Die Wahrscheinlichkeit dafür ist jedoch sehr gering. Es lässt sich für viele Fälle mathematisch nicht beweisen, dass es keine bessere Berechnungsmöglichkeit gibt.

↓38

Unabhängig von der Sicherheitseignung von Algorithmen müssen zur langfristigen Prüfbarkeit von Signaturen auch die Prüfvoraussetzungen erfüllt sein, z.B. sind Gültigkeits- und Sperrinformationen zu Zertifikaten verfügbar zu halten. Dies kann durch eine entsprechende Gewährleistung des Zertifizierungsdiensteanbieters erfolgen, der im akkreditierten Fall Zertifikate noch mindestens 30 Jahre nach Gültigkeitsende aufbewahren muss, oder durch zeitgestempelte OCSP-Antworten.

Es ist also möglich, dass eine heute mit einem 1024-Bit-Schlüssel erzeugte Signatur in 10 Jahren nicht mehr als gültig anzusehen ist, da sie zu diesem Zeitpunkt mit einem vergleichsweise geringen Rechenaufwand gefälscht werden könnte. Die Signatur ist also rechtzeitig vorher mit einer größeren Schlüssellänge oder einem anderen Algorithmus neu zu signieren.

Nach §6 (1) SigG hat ein Zertifizierungsdiensteanbieter seine Kunden darüber zu unterrichten, dass Signaturen bei Bedarf zu erneuern sind. Die SigV führt hier weitere Details aus: „Die Daten sind unter Einschluss der alten Signatur mit einer neuen qualifizierten

Signatur und einem qualifizierten Zeitstempel zu versehen.“ Es herrscht inzwischen Einigkeit darüber, dass - obwohl das Gesetz hier von Signatur und Zeitstempel spricht - ein qualifizierter Zeitstempel ausreichend ist, da er ja auch nur eine spezielle Art der Signatur darstellt (vgl. [RossnagelFDPB03c]). Dies ermöglicht die Auslagerung des Vorgangs der Neusignatur an einen externen Dienstleister, da kein Zugriff auf die Originaldokumente erforderlich ist. Falls der genutzte Hash-Algorithmus unsicher wird, ist ein Zugriff auf die Dokumente nötig, um einen neuen und sicheren Hashwert zu erzeugen. Um das Risiko zu minimieren, durch die wegfallende Sicherheitseignung eines Algorithmus aufwändige Prozeduren durchführen zu müssen oder sogar den Beweiswert von Signaturen zu verlieren, gibt es Konzepte für den Einsatz multipler Kryptografie, wie z.B. in [Maseberg02], wo dies am Beispiel einer Fail-Safe PKI demonstriert wird.

↓39

Es existieren verschiedene Ansätze zur technischen Realisierung der Langzeitsicherung von Signaturen. Eine recht neue Entwicklung sind die XML Advanced Digital Signatures (XAdES), die im ETSI-Standard 101903 definiert sind. Hierbei werden verschiedene Möglichkeiten beschrieben, mit XML-Signaturen Prüfinformationen für Signaturen abzubilden, z.B. komplette Zertifikatsketten oder Gültigkeitsinformationen mit Zertifikaten, die durch Zeitstempel abgesichert sind. In Deutschland hat sich das Projekt „Archisig“ besonders mit dem Thema Langzeitarchivierung von Signaturen beschäftigt. Das Projekt, das im medizinischen Umfeld angesiedelt ist, hat es sich zum Ziel gesetzt, Archivierungs-Technologien so zu erweitern, dass eine langfristige Prüfbarkeit elektronischer Signaturen ermöglicht wird. Es werden Systemarchitekturen dafür entwickelt und prototypisch umgesetzt. Im Rahmen des Projekts ist ein Konzept für die signaturgesetzkonforme Erneuerung qualifizierter Signaturen entwickelt worden[BrandnerP03].

3.6 Probleme und Trends

Wie bereits in den vorangegangen Erläuterungen teilweise angedeutet wurde, ist die Nutzung elektronischer Signaturen derzeit nicht unproblematisch. Eine Vielzahl technischer, organisatorischer, rechtlicher und auch kultureller Fragen ist zu beantworten, um ihnen zu einer breiten Nutzung zu verhelfen. Einige dieser Probleme und eine mögliche zukünftige Entwicklung sollen in diesem Abschnitt aufgezeigt werden.

Wesentlich für den Erfolg elektronischer Signaturen wird die Verfügbarkeit von sicheren und dennoch einfach zu bedienenden Anwendungskomponenten unter Berücksichtigung einer sicheren Signaturerstellungsumgebung sein. Der akkreditierte Zertifizierungsdiensteanbieter TC Trustcenter hat gerade den Auftrag vom BSI erhalten, Anforderungen an eine Standard-PC Umgebung zu definieren, die eine sichere Erstellung von Signaturen erlaubt [TC03]. Dies ist von besonderer Bedeutung, da im Gegensatz zu den Signaturerstellungseinheiten (Chipkarten) sowie den technischen Komponenten für Zertifizierungsdienste der ZDA die Anwenderumgebung nur sehr eingeschränkt kontrollieren werden kann. Es ist aber sicherzustellen, dass z.B. keine Daten auf dem Weg von der Anwendung zur Chipkarte manipuliert werden oder durch so genannte „Trojaner“ die Anwendung während des Signiervorgangs manipuliert wird. Die Anwendungen sollte eine Präsentation von Standard-Dateiformaten integrieren, um dem Nutzer transparent zu machen, welcher Inhalt eigentlich signiert wird. Des Weiteren sollten die technischen Interoperabilitäts-Standards umgesetzt sein, um auch Signaturen von

Fremdanbietern prüfbar zu halten. Eine Prüfung sollte auch möglich sein, ohne dass der Empfänger einer Signatur selbst einen Signaturschlüssel besitzt.

↓40

Vielfach wird der Schutz des privaten Schlüssels auf der Chipkarte durch die PIN kritisiert, da dies keine besonders hohe Sicherheit darstellt. Eine PIN kann bei entsprechender krimineller Energie durch technische Verfahren, aber auch durch einfaches Ausspähen oder andere „Social Engineering“-Verfahren [Mitnick03] in Erfahrung gebracht werden. Das Merken einer Zahl mit 6 Stellen stellt keine besonders hohe Bindung der Person des Besitzers an den Signaturschlüssel dar. Geeigneter ist die Nutzung biometrischer Merkmale, wie z.B. eines Fingerabdrucks oder auch der eigenhändigen Unterschrift, die entsprechend digitalisiert als Identifikation dienen kann.

Die derzeitig von Trustcentern eingesetzten Infrastrukturen sind nicht ohne weiteres interoperabel, d.h. die vom Trustcenter A ausgestellte Signatur hat nicht zwingend ein Format, das eine Gültigkeitsprüfung mit Anwendungen von Trustcenter B ermöglicht. Dies gilt auch für Zertifikate, Zeitstempel oder andere Strukturen. Wünschenswert ist es jedoch, auch Signaturen von Fremdanbietern prüfen zu können und dabei auf Sperrlisten oder OCSP-Responder zugreifen zu können. Hier verspricht der Standard ISIS-MTT Abhilfe, der inzwischen weitgehend akzeptiert ist [Fiedler03]. Alle deutschen akkreditierten Trustcenter haben eine Umstellung in diesem Jahr schon durchgeführt oder werden sie noch abschließen. Es bleibt abzuwarten, ob dann tatsächlich Anwendungskomponenten zur Verfügung stehen, die diese neuen Möglichkeiten auch nutzen können.

Das Problem der Langzeitarchivierung von Signaturen und mögliche Lösungen wurden bereits ausführlicher angesprochen. Auch hier ist zu erwarten, dass sich Standards für die Archivierung etablieren werden und marktreife Produkte zur Verfügung stehen. Um in den entsprechenden Fällen Neusignaturen in großem Umfang durchführen zu können, werden sich Dienstleister am Markt etablieren, die dies professionell anbieten. Um z.B. den Beweiswert von Signaturen zu erhalten, muss sich der Empfänger der Signatur beizeiten darum kümmern, mit neuen Algorithmen zu signieren. Da er u.U. nicht einmal die Infrastruktur zur Erzeugung von Zeitstempeln oder zum Berechnen neuer Hash-Werte besitzt, wird er hier das Angebot dieser Dienstleister in Anspruch nehmen.

↓41

Gegenwärtig hat ein Anwender noch einige Hürden zu überwinden, um elektronische Signaturen nutzen zu können: Es sind zunächst umfangreiche (papiergebundene) Antragsformulare zur Identifizierung auszufüllen, zusätzlich werden ein Chipkartenleser und die entsprechende Anwendung benötigt. Dies ist mit Kosten verbunden, die durchschnittlich 100 EUR betragen. Hinzu kommt eine meist jährlich zu entrichtende Gebühr für die Nutzung der Dienste des ZDA. In Anbetracht der derzeit geringen Anzahl der für die meisten Nutzer zugänglichen Anwendungen, wie z.B. Online-Banking, ist es nicht verwunderlich, dass bisher nur eine absolute Minderheit im Besitz einer Chipkarte mit einem Signaturschlüssel ist. Das ließe sich ändern, wenn diese Funktionalität zusätzlich dort angeboten wird, wo heute schon eine hohe Marktdurchdringung herrscht, sei es durch gesetzliche Grundlage, wie z.B. bei einem elektronischen Personalausweis, oder bei Mobiltelefonen, von denen inzwischen über 40 Millionen in Deutschland existieren. Denkbar wäre, dass der hier sowieso schon

vorhandene Chip um Signaturfunktionen erweitert wird, die dann mobil genutzt werden könnten. Eine zuverlässige Identifizierung der Personen ist durch das Antragsverfahren der Mobilfunkdienstleister bereits heute weitgehend gewährleistet. Schließlich ist die breite Nutzung von Signaturen aber an die Verfügbarkeit sinnvoller Anwendungen geknüpft, die den Bürgern einen spürbaren Vorteil bringen.

Ein weiterer Kritikpunkt ist eine mögliche juristische und technische Überregulierung der elektronischen Signatur. Durch die vielen Vorschriften des Signaturgesetzes und seiner nachgeordneten Regelungen, wie z.B. den Maßnahmenkatalogen, wird versucht, ein durchgängig sehr hohes Sicherheitsniveau zu erreichen. Dies kann jedoch eine Etablierung von Lösungen, basierend auf qualifizierten, Signaturen erschweren. Vielfach wird diskutiert, ob nicht auch fortgeschrittene Signaturen mit eventuellen Erweiterungen ein ausreichendes Sicherheitsniveau bieten, vor allem dann, wenn sie von besonders vertrauenswürdigen Institutionen, wie z.B. Banken, herausgegeben werden. Dass die breite Nutzung qualifizierter Signaturen offenbar nicht unproblematisch ist, zeigt auch das Beispiel „ELSTER-Signatur“, bei dem Steuererklärungen digital signiert beim Finanzamt abgeliefert werden können. Hier sind so genannte „qualifizierte Signaturen mit Einschränkungen“ ausdrücklich im Rahmen einer Übergangsphase zugelassen. In der Begründung zur Änderung der Abgabenverordnung heißt es: „Die bei einer 'qualifizierten elektronischen Signatur' erforderliche kostenpflichtige Einschaltung einer Zertifizierungsstelle sowie die unzureichende Verbreitung und Nutzung der dafür erforderlichen sicheren Signaturerstellungseinheit (Kartenleser) dürften zumindest in der nahen Zukunft den angestrebten zügigen Aufbau der elektronischen Kommunikation zwischen den Steuerpflichtigen und der Finanzverwaltung noch erheblich behindern. Insbesondere würde die Weiterentwicklung des Projekts ELSTER (Verzicht auf Steuererklärungen in 'Papierform') gefährdet.“ Auch beim Thema Einreichung von elektronischen Rechnungen beim Finanzamt wird vielfach das geforderte Sicherheitsniveau kritisiert. Während dort die Abgabenordnung eine qualifizierte Signatur fordert, brauchen Rechnungen in Papierform z.T. nicht einmal handschriftlich unterschrieben werden oder müssen – bis zu einem bestimmten Rechnungsbetrag – nicht einmal den Namen des Empfängers enthalten. Ähnliches gilt für die Einreichung von vorbereitenden und bestimmenden Schriftsätzen bei Gericht [Splittgerber03]. Es ist zu erwarten, dass in den kommenden Jahren weitere Änderungen am Signaturgesetz vorgenommen werden, um den Erfahrungen aus der Praxis Rechnung zu tragen.

InfoQ

infoq.com. Abgerufen am 03. 06 2013 von http://www.infoq.com/articles/designing-restful-http-apps-roth

This article gives a short overview about the basics of RESTful HTTP and discusses typical issues that developers face when they design RESTful HTTP applications. It shows how to apply the REST architecture style in practice. It describes commonly used approaches to name URIs, discusses how to interact with resources through the Uniform interface, when to use PUT or POST and how to support non-CRUD operations.

REST is a style, not a standard. There is neither a REST RFC, nor a REST protocol specification nor something similar. The REST architecture style has been described in the dissertation of Roy Fielding, one of the principal authors of the HTTP and URI specification. An architecture style such as REST defines a set of high-level architectures decisions which is implemented by an application. Applications which implement a dedicated architecture style will use the same patterns and other architectural elements such as caching or distribution strategies in the same way. Roy Fielding described REST as an architecture style which attempts “to minimize latency and network communication, while at the same time maximizing the independence and scalability of component implementations"

Even though REST is heavily influenced by the Web-Technology, in theory the REST architecture style is not bound to HTTP. However, HTTP is the only relevant instance of the REST. For this reason this article describes REST implemented by using HTTP. Often this is called RESTful HTTP.

Related Vendor Content

A Unified Mobile Architecture for the Modern Data Center

Mobile Middleware Buyer’s Guide

API Patterns for Cloud & Mobile

451 Group Analyst Report: Review of Intel & Mashery API Management Platform

API Management - Application Security Made Easy

Related Sponsor

*Video: Amazon Web Services Security Overview *Video: Scaling APIs across Multiple properties

The idea behind RESTful HTTP is to use the existing features and capabilities of the WEB. REST does not invent new technologies, components or services. RESTful HTTP defines the principles and constrains to use the existing WEB-Standards in a better way.

Resources

Resources are the key abstractions in REST. They are the remote accessible objects of the application. A resource is a unit of identification. Everything that might be accessed or be manipulated remotely could be a resource. Resources can be static, which means the state of the resource will not change over the time. On the other side other resources can have a high degree of variance in their state over time. Both types of resources are vaild types.

For instance, the classes, shown in Figure 1, could easily be mapped to such resources. Mapping entity classes such as Hotel or Room to resources will not be very comprehensible for object oriented designers. The same is true for mapping control classes which represent coordination, transactions, or control of other classes.

Figure 1: Example analysis model

The analysis model is a good starting point for identifying resources. However, there is not necessarily a one-to-one mapping. For instance, the <Hotel>.listOccupancy() operation can also be modelled as resources. Further more there could also be resources which represents (parts of) some entities. The primary drivers of the resource design are networking aspects and not the object model.

Any important resource is reachable through a unique identifier. RESTful HTTP uses URIs to identify resources. URIs are providing identification that is common across the Web. They contain everything the client needs to interact with the referred resource.

How to name Resource Identifiers?

Even though RESTful HTTP does not specify how a URI path have to be structured, in practice often specific naming schemas for the URI path is used. URI naming schemas help to debug and trace applications. Often a URI contains the resource type name followed by an identifier to address a dedicated resource. Such a URI will not contain verbs which indicate a business operation to process. It is only used to address resources. Figure (a1) shows an example URI of a Hotel resource. Alternatively the same Hotel can be accessed by URI (a2). A resource can be refered by more than one URI.

(a1) http://localhost/hotel/656bcee2-28d2-404b-891b (a2) http://127.0.0.1/hotel/656bcee2-28d2-404b-891b (b) http://localhost/hotel/656bcee2-28d2-404b-891b/ Room/4 (c) http://localhost/hotel/656bcee2-28d2-404b-891b/ Reservation/15

(d) http://localhost/hotel/656bcee2-28d2-404b-891b/ Room/4/Reservation/15 (e) http://localhost/hotel/656bcee2-28d2-404b-891b/ Room/4/Reservation/15v7 (f) http://localhost/hotel/656bcee2-28d2-404b-891bv 12

Figure 2: Examples of addressing resources

URIs can also be used by resources to establish relationships between resource representations. For instance a Hotel representation will refer the assigned Room resources by using a URI, not by using a plain Room id. Using a plain id would force the caller to construct a URI by accessing the resource. The caller would not be able to access the resource without additional context knowledge such as the host name or the base URI path.

Hyperlinks are used by clients to navigate through the resources. RESTful APIs are hypertext-driven, which means by getting a Hotel representation the client will be able to navigate to the assigned Room representations and the assigned Reservation representations.

In practice, classes such as shown in figure 1 will often be mapped in the sense of business objects. This means the URI stays persistent throughout the lifecycle of the business object. If an new resource is created, a new URI will be allocated. After deleting the resource the URI becomes invalid. The URI (a), (b), (c) and (d) are examples of such identifiers. On the other side a URI can also be used to referring object snapshots. For instance the URI (e) and (f) would refer such a snapshot by including a version identifier within the URI.

URIs can also addresses "sub" resources as shown in example (b), (c), (d) and (e). Often aggregated objects will be mapped to sub-resources such as the Room which is aggregated by the Hotel . Aggregated objects do not have their own lifecycle and if the parent object is deleted, all aggregated objects will also be deleted.

However, if a “sub" resource can be moved from one parent resource to another one it should not include the parent resource identifier within the URI. For instance the Reservation , shown in Figure 1 can be assigned to another Room. A Reservation resource URI which contains the Room identifier such as shown in (d) will become invalid, if the Room instance identifier changes. If such a Reservation URI is referred by another resource, this will be a problem. To avoid invalid URIs the Reservation could be addressed such as shown in (c).

Normally the resource URIs are controlled by the server. The clients do not have to understand the resource URI namespace structure to access the resource. For instance using the URI structure (c) or the URI structure (d) will have the same effects for the client.

Uniform Resource interface

To simplify the overall system architecture the REST architecture style includes the concept of a Uniform Interface. The Uniform Interface consists of a constrained set of well-defined operations to access and manipulate resources. The same interface is used regardless of the resource. If the client interacts with a Hotel resource, a Room resource or a CreditScore resource the interface will be the same. The Uniform Interface is independent to the resource URI. No IDL-like files are required describing the available methods.

The interface of RESTful HTTP is widely used and very popular. It consists of the standard HTTP methods such as GET, PUT or POST which is used by internet browsers to retrieve pages and to send data. Unfortunately a lot of developers believe implementing a RESTful application just means to use HTTP in a direct way, which it is not. For instance the HTTP methods have to be implemented according to the HTTP specification. Using a GET method to create or to modify objects violates the HTTP specification.

Uniform Interface applied

Fielding's dissertation does not include a table, a list or something else which describes in detail when and how to use the different HTTP verbs. For the most methods such as GET or DELETE it becomes clear by reading the HTTP specification. This is not true for POST and partial updates. In practice different approaches exists to perform partial updates on resources which will be discussed below.

Table 1 list the typical usage of the most important methods GET, DELETE, PUT and POST

Important Methods

Typical Usage Typical Status Codes Safe? Idempotent?

GET - retrieve a representation

- retrieve a representation if modified (caching)

200 (OK) - the representation is sent in the response

204 (no content) - the resource has an empty representation

301 (Moved Permanently) - the resource URI has been updated

303 (See Other) - e.g. load balancing

304 (not modified) - the resource has not been modified (caching)

400 (bad request) - indicates a bad request (e.g. wrong parameter)

404 (not found) - the resource does not exits

406 (not acceptable) - the server does not support the required representation

500 (internal server error) - generic error response

yes yes

503 (Service Unavailable) - The server is currently unable to handle the request

DELETE - delete the resource

200 (OK) - the resource has been deleted

301 (Moved Permanently) - the resource URI has been updated 303 (See Other) - e.g. load balancing

400 (bad request) - indicates a bad request 404 (not found) - the resource does not exits 409 (conflict) - general conflict

500 (internal server error) - generic error response 503 (Service Unavailable) - The server is currently unable to handle the request

no yes

PUT

- create a resource with client-side managed instance id

- update a resource by replacing

- update a resource by replacing if not modified (optimistic locking)

200 (OK) - if an existing resource has been updated 201 (created) - if a new resource is created

301 (Moved Permanently) - the resource URI has been updated

303 (See Other) - e.g. load balancing

400 (bad request) - indicates a bad request

404 (not found) - the resource does not exits

406 (not acceptable) - the server does not support the required representation

409 (conflict) - general

no yes

conflict

412 (Precondition Failed) e.g. conflict by performing conditional update

415 (unsupported media type) - received representation is not supported

500 (internal server error) - generic

error response

503 (Service Unavailable) - The

server is currently unable to

handle the request

POST

- create a resource with server-side managed (auto generated) instance id

- create a sub-resource

- partial update of a resource

- partial update a resource if not modified (optimistic locking)

200 (OK) - if an existing resource has been updated 201 (created) - if a new resource is created 202 (accepted) - accepted for processing but not been completed (Async processing)

301 (Moved Permanently) - the resource URI has been updated 303 (See Other) - e.g. load balancing

400 (bad request) - indicates a bad request 404 (not found) - the resource does not exits 406 (not acceptable) - the server does not support the required representation 409 (conflict) - general conflict 412 (Precondition Failed) e.g. conflict by performing conditional update 415 (unsupported media type) - received representation is

no no

not supported

500 (internal server error) - generic error response 503 (Service Unavailable) - The server is currently unable to handle the request

Table 1: Example of a Uniform Interface

Representations

Resources will always be manipulated through representations. A resource will never be transmitted over the network. Instead representations of a resource are transmitted. A representation consists of data and metadata describing the data. For instance the Content-Type header of a HTTP message is such a metadata attribute.

Figure 3 shows how to retrieve a representation by using Java. This example uses the HttpClient of the Java HTTP library xLightweb which is maintained by the author.

HttpClient httpClient = new HttpClient(); IHttpRequest request = new GetRequest(centralHotelU RI); IHttpResponse response = httpClient.call(request);

Figure 3: Java example to retrieve a representation

By performing the HTTP client's call method, an http request will be sent, which requests a representation of the Hotel resource. The returned representation, shown in Figure 4, also includes a Content-Type header which indicates the media type of the entity-body.

REQUEST: GET /hotel/656bcee2-28d2-404b-891b HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 277 Content-Type: application/x-www-form-urlencoded classification=Comfort&name=Central&RoomURI=http%3A %2F%2Flocalhost%2Fhotel%2F 656bcee2-28d2-404b-891b%2FRoom%2F2&RoomURI=http%3A%2F%2Flocalhost%2Fho tel%2F6 56bcee2-28d2-404b-891b%2FRoom%2F1

Figure 4: RESTful HTTP interaction

How to support specific representations?

Sometimes only a reduced set of attributes should be received to avoid transferring large data sets. In practice, one approach to determine the attributes of a representation is to support addressing specific attributes as shown in figure 5.

REQUEST: GET /hotel/656bcee2-28d2-404b-891b/classification H TTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/x-www-form-urlencoded RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 26 Content-Type: application/x-www-form-urlencoded; ch arset=utf-8 classification=Comfort

Figure 5: Attribute filtering

The GET call, shown in figure 5, requests only one attribute. To request more than one attribute the required attributes could be separated by using a comma as shown in figure 6.

REQUEST: GET /hotel/656bcee2-28d2-404b-891b/classification,n ame HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/x-www-form-urlencoded RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 43 Content-Type: application/x-www-form-urlencoded; ch arset=utf-8 classification=Comfort&name=Central

Figure 6: Multiattribute filtering

Another way to determine the required attributes is to use a query parameter which lists the required attributes as shown in figure 7. Query parameter will also be used to define query conditions or more complex filter or query criteria.

REQUEST: GET /hotel/656bcee2-28d2-404b-891b?reqAttr=classifi cation&reqAttr=name HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/x-www-form-urlencoded RESPONSE:

HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 43 Content-Type: application/x-www-form-urlencoded; ch arset=utf-8 classification=Comfort&name=Central

Figure 7: Query-String

In the examples above the server always returns a representation which is encoded by the media type application/x-www-form-urlencoded . Essentially this media type encodes an entity as a list of key-value-pairs. The key-value approach is very easy to understand. Unfortunately it will not fit well, if more complex data structures have to be encoded. Further more this media type does not support a binding of scalar data types such as Integer,

Boolean or Date . For this reason often XML, JSON or Atom is used to represent resources (JSON also does not define the binding of the Date type).

HttpClient httpClient = new HttpClient(); IHttpRequest request = new GetRequest(centralHotelU RI); request.setHeader("Accept", "application/json"); IHttpResponse response = httpClient.call(request); String jsonString = response.getBlockingBody().read String(); JSONObject jsonObject = (JSONObject) JSONSerializer .toJSON(jsonString); HotelHotel= (Hotel) JSONObject.toBean(jsonObject, H otel.class);

Figure 8: Requesting a JSON representation

By setting the request accept header, the client is able to request for a specific representation encoding. Figure 8 shows how to request a representation of the media type application/json . The returned response message shown in figure 9 will be mapped to a Hotel bean by using the library JSONlib.

REQUEST: GET /hotel/656bcee2-28d2-404b-891b HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/json RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 263 Content-Type: application/json; charset=utf-8 {"classification":"Comfort", "name":"Central", "RoomURI":["http://localhost/hotel/656bcee2-28d2-40 4b-891b/Room/1", "http://localhost/hotel/656bcee2-28d2-404b-8 91b/Room/2"]}

Figure 9: JSON representation

How to signal errors?

What happens if the server does not support the required representation? Figure 10 shows a HTTP interaction which requests for a XML representation of the resource. If the server does not support the required representation, it will return a HTTP 406 response indicating to refuse to service the request.

REQUEST: GET /hotel/656bcee2-28d2-404b-891b HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: text/xml RESPONSE: HTTP/1.1 406 No match for accept header Server: xLightweb/2.6 Content-Length: 1468 Content-Type: text/html; charset=iso-8859-1 <html> <head> <meta http-equiv="Content-Type" content="text /html; charset=ISO-8859-1"/> <title>Error 406 No match for accept header</ title> </head> <body> <h2>HTTP ERROR: 406</h2><pre>No match for ac cept header</pre> ... </body> </html>

Figure 10: Unsupported representation

A RESTful HTTP server application has to return the status code according to the HTTP specification. The first digit of the status code identifies the type of the result. 1xx indicates a provisional response, 2xx a successful response, 3xx a redirect, 4xx a client error and 5xx a server error. Misusing the response code or always returning a 200 response, which contains an application specific response in the body is a bad idea.

Client agents and intermediaries also evaluate the response code. For instance xLightweb's HttpClient pools persistent HTTP connections by default. After an HTTP interaction a persistent HTTP connection will be returned into an internal pool for reuse. This will only be done for healthy connection. For instance connections will not be returned if a 5xx status code is received.

Sometimes specific clients require a more precise status code. One approach to do this is to add an X-Header, which details the HTTP status code as shown in figure 11.

REQUEST: POST /Guest/ HTTP/1.1

Host: localhost User-Agent: xLightweb/2.6 Content-Length: 94 Content-Type: application/x-www-form-urlencoded zip=30314&lastName=Gump&street=42+Plantation+Street &firstName=Forest&country=US& city=Baytown&state=LA RESPONSE: HTTP/1.1 400 Bad Request Server: xLightweb/2.6 Content-Length: 55 Content-Type: text/plain; charset=utf-8 X-Enhanced-Status: BAD_ADDR_ZIP AddressException: bad zip code 99566

Figure 11: Enhanced staus code

Often the detailed error code is only necessary to diagnose programming errors. Although a HTTP status code is often less expressive than a detailed error code, in most cases they are sufficient for the client to handle the error correctly. Another approach is to include the detailed error code into the response body

PUTting or POSTing?

In contrast to popular RPC approaches the HTTP methods do not only vary in the method name. Properties such as idempotency or safety play an important role for HTTP methods. Idempotency and safety varies for the different HTTP methods.

HttpClient httpClient = new HttpClient(); String[] params = new String[] { "firstName=Forest" , "lastName=Gump", "street=42 Plantation Street", "zip=30314", "city=Baytown", "state=LA", "country=US"}; IHttpRequest request = new PutRequest(gumpURI, para ms); IHttpResponse response = httpClient.call(request);

Figure 12: Performing a PUT method

For instance figure 12 and 13 show a PUT interaction to create a new Guest resource. A PUT method stores the enclosed resource under the supplied Request-URI. The URI will be determined on the client-side. If the Request-URI refers to an already existing resource, this resource will be replaced by the new one. For this reason the PUT method will be used to create a new resource as well as to update an existing resource. However, by using PUT, the complete state of the resource has to be transferred. The update request to set the zip field has to include all other fields of the Guest resource such as firstName or city .

REQUEST: PUT Hotel/guest/bc45-9aa3-3f22d HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Content-Length: 94 Content-Type: application/x-www-form-urlencoded zip=30314&lastName=Gump&street=42+Plantation+Street &firstName=Forest&country=US& city=Baytown&state=LA RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 36 Content-Type: text/plain; charset=utf-8 Location: http://localhost/guest/bc45-9aa3-3f22d The guest resource has been updated.

Figure 13: HTTP PUT interaction

The PUT method is idempotent. An idempotent method means that the result of a successful performed request is independent of the number of times it is executed. For instance you can execute a PUT method to update the Hotel resource as many times as you like, the result of a successful execution will always be the same. If two PUT methods occur simultaneously, one of them will win and determine the final state of the resource. The DELETE method is also idempotent. If a PUT method occurs concurrently to a DELETE method, the resourced will be updated or deleted, but nothing in between.

If you are not sure if the execution of a PUT or DELETE was successful and you did not get a status code such as 409 (Conflict) or 417 (Expectation Failed) , re-execute it. No additional reliability protocols are necessary to avoid duplicated request. In general a duplicated request does not matter.

This is not true for the POST method, because the POST method is not idempotent. Take care by executing the same POST method twice. The missing idempotency is the reason why a browser always pops up a warning dialog when you retry a POST request. The POST method will be used to create a resource without determining an instance-specific id on the client-side. For instance figure 14 shows a HTTP interaction to create a Hotel resource by performing a POST method. Typically the client sends the POST request by using a URI which contains the URI base path and the resource type name.

REQUEST: POST /HotelHTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Content-Length: 35 Content-Type: application/x-www-form-urlencoded; ch arset=utf-8 Accept: text/plain classification=Comfort&name=Central

RESPONSE: HTTP/1.1 201 Created Server: xLightweb/2.6 Content-Length: 40 Content-Type: text/plain; charset=utf-8 Location: http://localhost/hotel/656bcee2-28d2-404b -891b the Hotelresource has been created

Figure 14: HTTP POST interaction (create)

Often the POST method will also be used to update parts of the resource. For instance sending a PUT requests which contains only the classification to update the Hotel resource violates HTTP. This is not true for the POST method. The POST method is neither idempotent nor safe. Figure 15 shows such a partial update by using a POST method.

REQUEST: POST /hotel/0ae526f0-9c3d HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Content-Length: 19 Content-Type: application/x-www-form-urlencoded; ch arset=utf-8 Accept: text/plain classification=First+Class RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 52 Content-Type: text/plain; charset=utf-8 the Hotelresource has been updated (classification)

Figure 15: HTTP POST interaction (update)

Partial update can also be performed by using the PATCH method. The PATCH method is a specialized method to apply partial modifications to a resource. A PATCH request includes a patch document which will be applied to the resource identified by the Request-URI. However, the PATCH RFC is in draft.

Using HTTP caching

To improve the scalability and to reduce the server load RESTful HTTP applications can make use of the WEB-Infrastructure caching features. HTTP recognizes caching as an integral part of the WEB infrastructure. For instance the HTTP protocol defines specific message headers to support caching. If the server sets such headers, clients such as HTTP clients or Web caching proxies will be able to support efficient caching strategies.

HttpClient httpClient = new HttpClient(); httpClient.setCacheMaxSizeKB(500000);

IHttpRequest request = new GetRequest(centralHotelU RI + "/classification"); request.setHeader("Accept", "text/plain"); IHttpResponse response = httpClient.call(request); String classification = response.getBlockingBody.re adString(); // ... sometime later re-execute the request response = httpClient.call(request); classification = response.getBlockingBody.readStrin g();

Figure 16: Client-side caching interaction

For instance figure 16 shows a repeated GET call. By setting the cache max size larger than 0 the caching support of the HttpClient is activated. If the response contains freshness headers such as Expires or Cache-Control: max-age , the response will be cached by the HttpClient. These headers tell how long the associated representation is fresh for. If the same request is performed within this period of time, the HttpClient will serve the request using the cache and avoid a repeated network call. On the network, shown in figure 17, only one HTTP interaction in total occurs. Caching intermediaries such as WEB proxies implement the same behaviour. In this case the cache can be shared between different clients.

REQUEST: GET /hotel/656bcee2-28d2-404b-891b/classification H TTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: text/plain RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Cache-Control: public, max-age=60 Content-Length: 26 Content-Type: text/plain; charset=utf-8 comfort

Figure 17: HTTP response including an expire header

The expiration model works very well for static resources. Unfortunately, this is not true for dynamic resources where changes in resource state occur frequently and unpredictably. HTTP supports caching dynamic resources by validation headers such as Last-Modified and ETag. In contrast to the expiration model, the validation model do not save a network request. However, executing a conditional GET can safe expensive operations to generate and transmit a response body. The conditional GET shown in figure 18 (2. request) contains an additional Last-Modified header which holds the last modified date of the cached response. If the resource is not changed, the server will reply with a 304 (Not Modified) response.

1. REQUEST: GET /hotel/656bcee2-28d2-404b-891b/Reservation/1 HT TP/1.1 Host: localhost User-Agent: xLightweb/2.6

Accept: application/x-www-form-urlencoded 1. RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 252 Content-Type: application/x-www-form-urlencoded Last-Modified: Mon, 01 Jun 2009 08:56:18 GMT from=2009-06-01T09%3A49%3A09.718&to=2009-06-05T09%3 A49%3A09.718&guestURI= http%3A%2F%2Flocalhost%2Fguest%2Fbc45-9aa3-3f22d&Ro omURI=http%3A%2F%2F localhost%2Fhotel%2F656bcee2-28d2-404b-891b%2FRoom% 2F1 2. REQUEST: GET /hotel/0ae526f0-9c3d/Reservation/1 HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/x-www-form-urlencoded If-Modified-Since: Mon, 01 Jun 2009 08:56:18 GMT 2. RESPONSE: HTTP/1.1 304 Not Modified Server: xLightweb/2.6 Last-Modified: Mon, 01 Jun 2009 08:56:18 GMT

Figure 18: Validation-based caching

Do not store application state on the server-side

A RESTful HTTP interaction has to be stateless. This means each request contains all information which is required to process the request. The client is responsible for the application state. A RESTful server does not have to retain the application state between requests. The Server is responsible for the resource state not for the application state. Servers and intermediaries are able to understand the request and response in isolation. Web caching proxies do have all the information to handle the messages correctly and to manage their caches.

This stateless approach is a fundamental principle to implement high-scalable, high-available applications. In general statelessness enables that each client request can be served by different servers. A server can be replaced by another one for each request. As traffic increases, new servers are added. If a server fails, it will be remove from the cluster. For a more detailed explanation on load balancing and fail-over refer to the article Server load balancing architectures.

Supporting non-CRUD operations

Often developers wonder how to map non-CRUD (Create-Read-Update-Delete) operations to resources. It is obviously that Create, Read, Update and Delete operations will map very well to resource methods. However, RESTful HTTP is not limited to CRUD-oriented applications.

Figure 19: RESTful HTTP Resources

For instance the creditScoreCheck class shown in figure 19 provides a non-CRUD operation creditScore (...) which consumes an address, calculates the score and returns it. Such an operation can be implemented by a CreditScoreResource which represents the result of the computation. Figure 20 shows the GET call which passes over the address to process and retrieves the CreditScoreResource representation. The query parameters are used to identify the CreditScoreResource . The GET method is safe and cacheable which fits very well to non-functional behaviour of the CreditScore Check's creditScore (...) method. The result of the score calculation can be cached for a period of time. As shown in figure 20 the response includes a cache header to enable clients and intermediaries to cache the response.

REQUEST: GET /CreditScore/?zip=30314&lastName=Gump&street=42 +Plantation+Street& firstName=Forest&country=US&city=Baytown&sta te=LA HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/x-www-form-urlencoded RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 31 Content-Type: application/x-www-form-urlencoded Cache-Control: public, no-transform, max-age=300 scorecard=Excellent&points=92

Figure 20: Non-CRUD HTTP GET interaction

This example also shows the limit of the GET method. Although the HTTP specification does not specify any maximum length of a URL, practical limits are imposed by clients, intermediaries and servers. For this reason sending a large entity by using a GET query-parameter can fail caused by intermediary and servers which limits the URL length.

An alternative solution is performing a POST method which will also be cacheable, if indicated. As shown in figure 21 first a POST request will be performed to create a virtual resource CreditScoreResource . The input address data is encoded by the mime type text/card. After calculating the score the server sends a 201 (created) response which includes the URI of the created CreditScoreResource . The POST response is cacheable if indicated as shown in the example. By performing a GET request the credit score will be fetched. The GET response also includes a cache control header. If the client re-executes these two requests immediately, all responses can be served by the cache.

1. REQUEST: POST /CreditScore/ HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Content-Length: 198 Content-Type: text/x-vcard Accept: application/x-www-form-urlencoded BEGIN:VCARD VERSION:2.1 N:Gump;Forest;;;; FN:Forest Gump ADR;HOME:;;42 Plantation St.;Baytown;LA;30314;US LABEL;HOME;ENCODING=QUOTED-PRINTABLE:42 Plantation St.=0D=0A30314 Baytown=0D=0ALA US END:VCARD 1. RESPONSE: HTTP/1.1 201 Created Server: xLightweb/2.6 Cache-Control: public, no-transform, max-age=300 Content-Length: 40 Content-Type: text/plain; charset=utf-8 Location: http://localhost/CreditScore/l00000001-l0 000005c the credit score resource has been created 2. REQUEST: GET /CreditScore/l00000001-l0000005c HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 2. RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 31 Content-Type: application/x-www-form-urlencoded Cache-Control: public, no-transform, max-age=300

scorecard=Excellent&points=92

Figure 21: Non-CRUD HTTP POST interaction

There are also some variants of this approach. Instead of returning a 201 response a 301

(Moved Permanently) redirect response could be returned. The 301 redirect response is cacheable by default. Another variant which avoids a second request is to add the representation of the newly create CreditScoreResource to the 201 response.

Conclusion

Most SOA architectures such as SOAP or CORBA try to map the class model, such as shown in Figure 1, more or less one-to-one for remote access. Typically, such SOA architectures are highly focused on transparent mapping of programming language objects. The mapping is easy to understand and very traceable. However aspects such as distribution and scalability are reduced to playing a second role.

In contrast, the major driver of the REST architecture style is distribution and scalability. The design of a RESTful HTTP interface is driven by networking aspects, not by language binding aspects. RESTful HTTP does not try to encapsulate aspects, which are difficult to hide such as network latency, network robustness or network bandwidth.

RESTful HTTP applications use the HTTP protocol in a direct way without any abstraction layer. There are no REST specific data field such as error fields or security token fields. RESTful HTTP applications will just use the capability of the WEB. Designing RESTful HTTP interfaces means that the remote interface designer has to think in HTTP. Often this leads to an additional step within the development cycle.

However, RESTful HTTP allows implementing very scalable and robust applications. Especially companies which provide web applications for a very large user group such as WebMailing or SocialNetworking applications can benefit from the REST architecture style. Often such applications have to scale very high and very fast. Further more, such companies often have to run their application on a low-budget infrastructure which is built on widely-used standard components and software

IT-Administrator it-administrator.de. Abgerufen am 24. 07 2013 von

http://www.it-administrator.de/themen/server_client/grundlagen/98988.html

Hochverfügbarkeit

In unserer Grundlagen-Rubrik erklären wir wichtige Aufgaben und Technologien aus dem

Arbeitsalltag eines Netzwerk- und Systemadministrators. Hier erfahren Sie anhand prägnanter

Erklärungen zu den wichtigsten Begriffen des jeweiligen Themenfeldes Hintergründe und

Zusammenhänge in kompakter, praxisnaher Form.

In der heutigen Arbeitswelt ist die Verfügbarkeit der IT-Systeme und -Komponenten die Grundlage

für den reibungslosen Ablauf der unternehmensinternen Geschäftsprozesse. Ist beispielsweise der E-

Mailserver nicht verfügbar, können die Anwender keine E-Mails verschicken, steht das

Warenwirtschaftssystem still, stockt die Produktion und so weiter. Die Verfügbarkeit wird als

Verhältnis aus fehlerbedingter Ausfallzeit und Gesamtzeit eines Systems gemessen. Das Ziel der

Hochverfügbarkeit (High Availability, HA) in der IT ist es, die Systeme auch dann verfügbar zu halten,

wenn eine oder mehrere für das Funktionieren notwendigen Komponenten ausfallen.

Definition von Hochverfügbarkeit

Das Institute of Electrical and Electronics Engineers (IEEE) definiert Hochverfügbarkeit als

Verfügbarkeit der IT-Ressourcen im Falle eines Ausfalls von Systemkomponenten. Ein System gilt also

dann als hochverfügbar, wenn eine Anwendung auch im Fehlerfall weiterhin verfügbar ist und ohne

unmittelbaren menschlichen Eingriff weiter genutzt werden kann. In der Konsequenz heißt dies, dass

der Anwender keine oder nur eine kurze Unterbrechung wahrnimmt. Hochverfügbarkeit bezeichnet

die Fähigkeit eines Systems, bei Ausfall einer seiner Komponenten einen uneingeschränkten Betrieb

zu gewährleisten.

Verfügbarkeitsklassen

Die letzte Definition beschreibt ein System auch bei einer kurzen Unterbrechung als hochverfügbar,

was uns direkt zu der Einteilung in Verfügbarkeitsklassen führt. Allerdings wird die Frage, ab welcher

Verfügbarkeitsklasse ein System als hochverfügbar einzustufen ist, wird je nach Definition der

Verfügbarkeit unterschiedlich beantwortet.

Bei einer Verfügbarkeit von 99 Prozent (Ausfall von etwa vier Tagen pro Jahr) ist in der Regel noch

keine Hochverfügbarkeit erreicht, diese prozentuale Verfügbarkeit wird heutzutage bei qualitativ

hochwertigen EDV-Komponenten als normal betrachtet. Hochverfügbarkeit wird erst ab einem Wert

von 99,9 Prozent oder höher erreicht. Die weitere Steigerung der Verfügbarkeit wird durch das

"Anhängen" weiterer 9en erreicht:

- Verfügbarkeit 99 Prozent entspricht einer Ausfallzeit von etwa 87 Stunden/Jahr

- Verfügbarkeit 99,9 Prozent entspricht einer Ausfallzeit von etwa 8:46 Stunden/Jahr.

- Verfügbarkeit 99,99 Prozent entspricht einer Ausfallzeit von etwa 53 Minuten/Jahr

- Verfügbarkeit 99,999 Prozent entspricht einer Ausfallzeit von etwa 5 Minuten/Jahr

- Verfügbarkeit 99,9999 Prozent entspricht einer Ausfallzeit von etwa 32 Sekunden/Jahr

In dieser Form wird die Hochverfügbarkeit von IT-Komponenten heute am Markt angeboten,

beziehungsweise klassifizieren sich Produkte, die Hochverfügbarkeit sicherstellen sollen an Hand

dieser Werte.

Availability Environment Classification

Dabei ist es naheliegend, das letztgenannte Produkte um teurer werden, je mehr 9en sie aufweisen.

Daher ist es vor einer – teilweise nicht unerheblichen – Investition in einer derartige Technologie

wichtig, sich zu fragen, wie verfügbar die im Unternehmen eingesetzten IT-Systeme eigentlich sein

sollen. Dafür gibt die Harvard Research Group (HRG) in ihrer Einteilung der Hochverfügbarkeit in

"Availability Environment Classification (AEC)" in sechs Klassen einen guten Hinweis:

- AEC-0 (Conventional): Funktion kann unterbrochen werden, Datenintegrität ist nicht essentiell.

- AEC-1 (Highly Reliable): Funktion kann unterbrochen werden, Datenintegrität muss jedoch

gewährleistet sein.

- AEC-2 (High Availability) Funktion darf nur innerhalb festgelegter Zeiten oder zur Hauptbetriebszeit

minimal unterbrochen werden.

- AEC-3 (Fault Resilient); Funktion muss innerhalb festgelegter Zeiten oder während der

Hauptbetriebszeit ununterbrochen aufrechterhalten werden.

- AEC-4 (Fault Tolerant): Funktion muss ununterbrochen aufrechterhalten werden, 24/7-Betrieb muss

gewährleistet sein.

- AEC-5 (Disaster Tolerant): Funktion muss unter allen Umständen verfügbar sein.

Weitere Kenngrößen

Im Umfeld der Hochverfügbarkeit gibt einige weitere wichtige Kenngrößen, die über die reine

Messung der Ausfallzeit hinausgehen. Diese beschreiben zum einen das Verhalten des

hochverfügbaren Systems und erlauben zum anderen den Vergleich unterschiedlicher HA-Produkte

beziehungsweise Anbietern:

- Mean Time Between Failure (MTBF): mittlere ausfallfreie Zeit eines Systems

- Mean Time To Repair (MTTR): mittlere Dauer für die Wiederherstellung nach einem Ausfall

- Mean Time Between Crash (MTBC): mittlere ausfallfreie Zeit eines Betriebssystems

Technische Umsetzung von Hochverfügbarkeit

Generell streben HA-Systeme danach, sogenannte Single-Point-of-Failure-Risiken (SPOF) zu

eliminieren (ein SPOF ist eine einzelne Komponente, deren Versagen zum Ausfall des gesamten

Systems führt). Ein Hersteller eines hochverfügbaren Systems muss dieses mit folgenden Merkmalen

ausstatten: Redundanz kritischer Systemkomponenten sowie fehlertolerantes und robustes

Verhalten des Gesamtsystems. Typische Beispiele für solche Komponenten sind unterbrechungsfreie

Stromversorgungen, doppelte Netzteile oder der Einsatz von RAID-Systemen. Weiter kommen

Techniken zur Serverspiegelung oder auch redundante Cluster zum Einsatz.

In der IT-Infrastruktur hat die Hochverfügbarkeit folgende Ausprägungen: Als Cold-Standby werden

HA-Lösungen bezeichnet, bei denen die Anwendungen des Rechners im Fehlerfalle auf einem

Ersatzrechner zur Verfügung stehen. Hot-Standby bezeichnet Systeme, bei denen die Anwendungen

des Rechners im Fehlerfalle auf einem Ersatzrechner zur Verfügung stehen, dieser jedoch die Arbeit

sofort nach Ausfall des primären Rechners aufnimmt. In Cluster-Systemen sind mehrere Rechner sind

miteinander gekoppelt, sie erscheinen nach außen als ein einziger Rechner. Cluster können sich im

Fehlerfall unterschiedlich verhalten, es wird zwischen Failover und Takeover unterschieden. Failover

heißt, dass im Fehlerfall die Anwendung auf einem anderen Rechner im Cluster neu gestartet wird.

Takeover bedeutet, dass die Dienste auf zwei oder mehreren Servern gleichzeitig aktiv sind. Fällt ein

Server aus, so schaltet der Cluster auf einen anderen Server um.

IT-Wissen itwissen.info. Abgerufen am 10. 03 2013 von

http://www.itwissen.info/definition/lexikon/transport-layer-security-TLS-TLS-Protokoll.html

TLS-Protokoll

Transport Layer Security (TLS) ist eine Weiterentwicklung des SSL-Protokolls durch die Internet

Engineering Task Force (IETF), die das SSL-Protokoll 1999 in Transport Layer Security umbenannte.

Der aktuelle Standard ist in RFC 5246 beschrieben und ist von 2008.

Das TLS-Protokoll ist abwärtskompatibel zum SSL-Protokoll, es wird vorwiegend im Web-Umfeld eingesetzt und dort vor Allem zur Absicherung von HTTP-Verbindungen und für kommerzielle Transaktionen. TLS-Security bildet eine generische Sicherungsschicht oberhalb der Transportschicht und benutzt das TCP-Protokoll als verbindungsorientiertes Transportprotokoll. TLS arbeitet mit einer 128-Bit-Verschlüsselung, es wird für die Verschlüsselung von Mails eingesetzt. Um die Integrität der E-Mails zu überwachen und nichtautorisierte Zugriffe auf den Mail-Server zu verhindern, nutzt Transport Layer Security eine zertifikatbasierte Authentifizierung.

Die Schichtenstruktur des TLS-Protokolls für die Verschlüsselung der Applikationsdaten

Zur Authentifizierung der Daten unterstützt das TSL-Protokoll den Hashed Message Authentication Code (HMAC) und erzeugt das Schlüsselmaterial. Das TLS-Protokoll nutzt den TLS-Record-Layer, der für die Verschlüsselung der Anwendungsdaten sorgt, mit den darauf aufsetzenden Protokollen Alert, Change Cipher Spec., Handshake und Application Data. Über das TLS-Handshake-Protokoll einigen sich die Peers darauf mit welchen Algorithmen verschlüsselt und authentifiziert werden soll. TLS arbeitet mit vier verschiedenen Schlüsseln: jeweils einen zum Ver- und Entschlüsseln und je einen zur Authentifizierung der ankommenden und abgehenden Datenpakete.

Das TLS-Protokoll wird nicht nur im Web-Umfeld mit HTTP eingesetzt, sondern auch in Verbindung mit anderen Anwendungsprotokollen wie für den Abruf von E-Mails über das Post Office Protocol (POP) oder über das Internet Message Access Protocol (IMAP). In WLANs wird TLS in Verbindung mit dem Extensible Authentication Protocol (EAP), EAP-TLS, für den sicheren Austausch der Authentifizierungsdaten eingesetzt. Da das EAP-TLS von beiden Kommunikationspartnern Zertifikate verlangt, ist man auf EAP-TTLS, dem Tunneled TLS, übergegangen.

Krypto Krypto.mufuku.de. Abgerufen am 20. 06 2013 von

http://krypto.mufuku.de/2006-10-19/symmetrisch-asymmetrisch/

Symmetrisch, asymmetrisch? Publiziert am 19. Oktober 2006 von Pawel

Um die Anwenduung von Kryptosystemen zu verstehen, sollte man die verschiedenen Grundprinzipien in der Verschlüsselung auseinanderhalten können:

• Symmetrische Verschlüsselungsverfahren

• Asymmetrische Verschlüsselungsverfahren

• Hybride Verschlüsselungsverfahren

Symmetrische Verfahren

Diese Verfahren zeichnen sich durch die Tatsache aus, dass sowohl für die Verschlüsselung in Geheimtext als auch für die Entschlüsselung in Klartext der exakt selbe Schlüssel verwendet wird.

Im Artikel über die funktionsweise der Verschlüsselung wurden bereits mehrere Beispiele der symmetrischen Kryptoverfahren genannt – darunter der Cäsarchiffre, die Skytale und Enigma.

Die größte Problematik der symmetrischen Verfahren besteht beim unsicheren Schlüsselaustausch. Eine chiffrierte Nachricht kann zwar gefahrlos verschickt werden, nicht aber der Schlüssel. Um vor Angriffen geschützt zu sein, muss für den Transport des Schlüssels also unbedingt ein sicherer Kanal gewährleistet sein.

Asymmetrische Verfahren

Asymmetrische Systeme haben die wichtige Eigenschaft mit Schlüsselpaaren zu arbeiten. Hierbei wird ein Schlüssel zur Verschlüsselung (Public Key) und ein anderer Schlüssel zur Entschlüsselung der Nachricht (Private Key) verwendet.

Der öffentliche Schlüssel wird, wie der Name sagt, öffentlich gemacht. Jeder Anwender kann diesen Schlüssel benutzen, um an den Eigentümer eine Nachricht zu Versenden, die durch Verschlüsselung entstanden ist.

Der geheime Schlüssel wird vom Besitzer geheim gehalten. Er dient dazu, an ihn gesendete, verschlüsselte Nachrichten (Geheimtexte) zu entschlüsseln.

Die Vorteile:

• Kennt ein Angreifer den öffentlichen Schlüssel, so kann er daraus weder auf die

verschlüsselte Nachricht noch den geheimen Schlüssel schließen

• Der öffentliche Schlüssel kann ohne Bedenken auch über unsichere Kanäle verschickt werden

Asymmetrische Verfahren sind ein relativ neues Gebiet der Kryptographie. Eine wichtige Vorarbeit für die asymmetrischen Verfahren sind die Arbeiten von Whitfield Diffie, Martin Hellman und Ralph Merkle zum geheimen Schlüsselaustausch Anfang der 1970er Jahre. Im Sommer 1975 veröffentlichten Diffie und Hellman eine Idee zur asymmetrischen Verschlüsselung, ohne jedoch ein genaues Verfahren zu kennen. Der Durchbruch gelang Ronald L. Rivest, Adi Shamir und Leonard M. Adleman, die 1977 das RSA-Verfahren entwickelten. Es gilt bis heute als sicheres Verfahren und hat außerdem den großen Vorteil, in beiden Richtungen eingesetzt werden zu können.

Populär wurde asymmetrische Kryptographie besonders durch das 1991 veröffentlichte Programm Pretty Good Privacy (PGP). Mit PGP konnten nun auch private Anwender auf

relativ einfache Art und Weise die Vorteile eines Public- und Private-Key-Systems nutzen und sich z. B. abhörsichere E-Mails schicken.

Hybride Systeme

Heutzutage wird in den meisten Kryptosystemen, die mit sogenannter “starker Kryptographie” arbeiten hybrid verschlüsselt.

Da asymmetrische Verfahren extrem rechenaufwändig sind, bedient man sich oft einer Kombination aus symmetrischer und asymmetrischer Kryptographie.

Symmetric-key algorithms are generally much less computationally intensive than asymmetric key algorithms. In practice, this means that a quality asymmetric key algorithm is hundreds or thousands of times slower than a quality symmetric key algorithm.

Dabei wird zu Beginn einer Sitzung zwischen beiden Partnern ein asymmetrisch verschlüsselter Schlüssel ausgetauscht, der anschließend für eine ressourcenschonende symmetrische Verschlüsselung genutzt wird.

Als häufig genutztes Beispiel wäre der Secure Sockets Layer (SSL) zu nennen, der für sicherheitskritische Anwendungen im Online-Bereich genutzt wird – z. B. für E-Commerce oder Onlinebanking. SSL funktioniert in modernen Browsern sehr unauffällig und ist daran zu erkennen, dass das Übertragungsprotokoll https:// (statt http://) genutzt wird.

(Anmerkung: PGP arbeitet streng genommen auch in einem Hybridverfahren, da nicht der gesamte Geheimtext asymmetrisch verschlüsselt wird, sondern lediglich ein im Geheimtext verborgener Schlüssel, mit dem der Rest der Nachricht symmetrisch verschlüsselt ist.)

Meinberg meinberg.de. Abgerufen am 12. 07 2013 von

http://www.meinberg.de/german/faq/faq_37.htm

Was ist der Unterschied zwischen NTP und SNTP?

SNTP (Simple Network Time Protocol) und NTP (Network Time Protocol) sind genau genommen keine

verschiedenen Netzwerkprotokolle. Es handelt sich hierbei vielmehr um zwei verschiedene

Einsatzgebiete für das Network Time Protocol.

Während ein vollwertiger NTP-Server bzw. Client eine sehr hohe Genauigkeit und die Vermeidung von plötzlichen Zeitsprüngen durch den Einsatz verschiedener mathematischer Verfahren und vorsichtige Nachführung der Systemuhr erreicht, ist SNTP lediglich für einfache Anwendungen geeignet, ohne große Anforderungen an Genauigkeit und Zuverlässigkeit.

Durch die Vernachlässigung von Driftwerten und bei vielen SNTP-Implementierungen vereinfachte Methoden zur Korrektur der Systemzeit (meist durch einfaches, hartes Setzen) ist die Qualität der Zeitsynchronisation eines SNTP-Clients fast immer schlechter als die eines Clients, der eine vollwertige NTP-Implementierung verwendet.

SNTP in der aktuellen Version 4 wird in RFC 2030 definiert, dort heisst es (Zitat): "It is strongly recommended that SNTP be used only at the extremities of the synchronization subnet. SNTP clients should operate only at the leaves (highest stratum) of the subnet and in configurations where no NTP or SNTP client is dependent on another SNTP client for synchronization. SNTP servers should operate only at the root (stratum 1) of the subnet and then only in configurations where no other source of synchronization other than a reliable radio or modem time service is available. The full degree of reliability ordinarily expected of primary servers is possible only using the redundant sources, diverse subnet paths and crafted algorithms of a full NTP implementation."(Zitat Ende)

Sinngemäss übersetzt: "Es wird sehr empfohlen, SNTP nur an den "äusseren Extremitäten" einer Synchronisationsstruktur zu verwenden. SNTP Clients sollten nur an den Endpunkten eingesetzt werden und nur in Konfigurationen, in denen kein NTP oder SNTP Client von einem anderen SNTP Client im Bezug auf Zeitsynchronisation abhängt. SNTP Server sollten ausschliesslich an der Spitze der Synchronisationsstruktur (Stratum 1) eingesetzt werden. Und auch nur dann, wenn keine andere Synchronisationsquelle als eine verlässliche Funkuhr oder Modembasierende Zeitreferenz verwendet werden soll."

Die volle Zuverlässigkeit, die allgemein von primären Zeitservern erwartet wird, ist nur möglich, wenn die redundanten Zeitquellen, unterschiedlichen Subnetz-Pfade und ausgearbeiteten Algorithmen einer vollwertigen NTP-Implementierung verwendet werden."

Somit kann die Bezeichnung "NTP-kompatibler Zeitserver oder -client" per Definition sowohl auf Systeme mit vollwertiger NTP-Implementierung angewendet werden, als auch auf alle anderen Produkte, die lediglich das NTP-Protokoll verwenden aber im Bezug auf Verlässlichkeit, Sicherheit und Genauigkeit nur um ein Vielfaches schlechtere Werte erreichen.

Mintert

mintert.com. Abgerufen am 2013. 08 07 von http://www.mintert.com/xml/

XML-Beratung, -Schulung und

-Software-Entwicklung

Ich setze seit 1993 SGML und seit 1998 XML ein. Mit dieser Erfahrung stehe ich Ihnen als kompetenter Dienstleister zur Verfügung.

Für Auftragsanfragen sprechen Sie mich bevorzugt bei Linkwerk an, oder nehmen Sie gleich telefonisch Kontakt auf: 0177 216 70 80. Ich freue mich auf Ihren Anruf und bin gespannt, wie ich Ihnen helfen kann.

Was ist XML?

In einem Satz: XML ist ein Datenformat für Fachleute verschiedener Branchen, das die hochautomatisierte Verarbeitung von Text und Daten ermöglicht, weil XML eine strenge Strukturierung erlaubt, so dass in geeigneten Anwendungsfällen große Rationalisierungsgewinne zu realisieren sind.

Noch Fragen? ;-) — Im Laufe der Jahre habe ich eine große Zahl von Texten über XML geschrieben. Eine Reihe davon ist unten verlinkt. Darüber hinaus gibt es gute Einführungen auf verschiedenen Sites im Internet. Je nach Ihrem technischen Hintergrund mag zum Beispiel die XML-Beschreibung bei Wikipedia einen guten Einstieg darstellen. Ich möchte den vielen Grundlagentexten hier keinen weiteren hinzufügen.

Statt dessen möchte ich meine persönliche Sichtweise auf den Nutzen von XML wiedergeben.

XML — Für und Wider

Um die Jahrtausendwende wurde XML mit großen Erwartungen verknüpft. Die Gartner Group prophezeite By the year-end 2002, XML's impact on publishing (in particular) and technology (in general) will be as profound as the Web's impact is today., während die Burton Group etwas allgemeiner, aber nicht weniger hoch ansetzte und schrieb XML will be like oxygen in the networked environment of the twenty-first century: vital, pervasive, and taken for granted.

Was ist aus diesen Prognosen geworden? Sie sind eingetreten, aber anders als viele gedacht haben. XML ist tatsächlich allgegenwärtig, wir sehen es nur nicht (immer). Vermutlich kommt kein modernes Kommunikationsgerät neu auf den Markt, das nicht irgendwie mit XML zu tun hat. Selbst in meinem Mobiltelefon anno 2004 steckte XML zur Konfiguration. Und wenn ein Gerät nicht XML in sich trägt, besteht eine gute Chance, dass XML beim Dokumentationsprozess eine Rolle spielte.

Damit sind die beiden wesentlichen Einsatzbereiche genannt. XML als Format irgendwelcher Daten im "Innern" einer Software, eines Geräts oder beim Datenaustausch, und XML zur Erfassung von Dokumenten.

Datenorientiertes XML

Der erste Fall ist vergleichsweise einfach. XML besitzt gewisse Eigenschaften, deren Nutzen man im Lichte eines konkreten Einsatzszenarios abwägen und sich dann dafür oder dagegen entscheiden kann. Manchmal mag ein Entwickler XML nicht und es treten Alternativen wie JSON oder YAML in Erscheinung.

Ich empfinde Grundsatzdiskussionen, welche der genannten Techniken die bessere sei, als müßig. Die Entscheidung kann pragmatisch bei Betrachtung einer zu lösenden Aufgabe getroffen werden. Eins sollte man dabei aber nicht vergessen: Die Ausbildung der beteiligten Entwickler. Wer einmal wirklich gut in der Verarbeitung von XML ist, ist universell einsetzbar. XML kommt in so vielen verschiedenen Situationen zum Einsatz, dass das entsprechende Know-how wertvoll ist.

Gleichzeitig habe ich festgestellt, dass nur wenige Entwickler tiefes Know-how in den Techniken der XML-Familie haben. Viele streifen die Technik, glauben, mit ein paar Tags sei alles erledigt und lassen sehr viel Potential ungenutzt.

Dokumentenorientiertes XML

Der zweite Fall, der Einsatz von XML bei dokumentenorientierten Aufgaben, ist sehr viel schwieriger. Ein Grund ist die Tatsache, dass die fraglichen Dokumente in der Regel nicht von IT'lern geschrieben werden. Nicht-Techniker tun sich jedoch schwer mit der als sperrig empfundenen Technik. Bequeme Editoren sind teuer und – wenngleich sie einen hohen Komfort bieten – sind sie anders zu bedienen als die bekannte Textverarbeitung.

Diese Untiefen eins XML-Projekts muss man vorsichtig umschiffen. Setzt man XML in der technischen Dokumentation ein, sind die Mitarbeiter meist belastbarer. In Fachverlagen, die neben einer internen Redaktion auch noch externe Autoren einsetzen, ist es schwieriger. Eine Lösung kann in der ausgiebigen und kontinuierlichen Qualifizierung der Mitarbeiter bestehen. Das kostet Geld, zusätzlich zu etwaigen teuren Editoren. Eine Alternative ist die Schaffung einer Brücke zwischen den als einfach empfundenen Eingabeprogrammen (z.B. Word) und der XML-Welt. Abgesehen davon, dass auch Word teuer ist, wird es meist als "sowieso vorhanden" betrachtet. Es ist durchaus eine Überlegung Wert, ob man nach Umstellung auf XML auf einige Office-Lizenzen verzichten kann. Darüber hinaus ist die Brücke der häufigste Weg, den wir in vielen Projekten für unsere Kunden implementiert haben.

XML hat sich in den mehr als 10 Jahren seines Bestehens als feste Technik etabliert. Potential besitzt die Sprache dort, wo sie wegen geringer Erfahung von Entwicklern unter ihren Möglichkeiten eingesetzt wird. Für Nicht-Techniker ist XML nicht so einfach (geworden), wie ursprünglich erhofft/erwartet/ersehnt. Beide Fälle sind der Grund dafür, dass ich nach wie vor als XML-Berater und mit meiner Firma Linkwerk in der XML-Software-Entwicklung tätig bin. Neben der Beratung über den richtigen Einsatz der XML-Techniken — DTDs, XML-Schema, XSLT, XPath, XQuery u.a. — spielt für uns das Thema XML Content Management eine wichtige Rolle. Linkwerk ist ein System-neutraler Dienstleister, weshalb wir gerne als unabhängiger Projektbegleiter bereits vor der Auswahl eines Produkts beauftragt werden. Wir haben für Kunden vieler Branchen gearbeitet, unter anderem für die Luftfahrt, die Telekommunikation, den Maschinenbau, das Bauwesen und die IT. Wenn Sie weitere Fragen haben, sprechen Sie mich gerne an; bevorzugt telefonisch.

Eigene Texte über XML

Ich habe viel über XML geschrieben und setze diese Arbeit bei aktuellen Anlässen fort. Aktuelle Veröffentlichungen oder die Bekanntgabe derselben finden Sie im Blog meiner Firma Linkwerk.

Die nachfolgende Auflistung enthält vor allem alte Texte. Die darin gemachten Aussagen entsprechen jeweils meiner damaligen Sichtweise. Sichtweisen können sich ändern; mit mehr als eineinhalb Jahrzehnten Erfahrung wäre alles andere auch überraschend. Trotzdem stelle ich die alten Texte hier zur Verfügung. Einerseits weil sie für Themeneinsteiger immer noch gute Dienste leisten können, andererseits weil sie wertvolle Erkenntnisse darüber liefern können, wie sich die Betrachtung und Bewertung einer Technik über die Zeit verändern kann.

Orientation in Objects

oio.de. Abgerufen am 03. 06 2013 von http://www.oio.de/public/xml/rest-webservices.htm

REST Web Services

Eine Einführung

Autor: Thomas Bayer

Orientation in Objects GmbH

Thomas Bayer

Datum: November 2002

Abstract

Web Services werden meist mit SOAP oder XML-RPC in Verbindung gebracht. Mit REpresentational State Transfer oder kurz REST, einem Architekturstil, können ebenfalls Web Services realisiert werden. Dieser Artikel beschreibt REST anhand eines Beispiels und erläutert Aspekte wie Sicherheit und Skalierbarkeit. Unterschiede zu einer RPC Middleware werden mit einem Vergleich zwischen REST und SOAP aufgezeigt.

Einleitung

Neben SOAP und XML-RPC gibt es eine weitere Alternative für die Realisierung von Web Services. Thomas Roy Fielding beschreibt in seiner Dissertation einen Architekturstil, den er REpresentational State Transfer Architektur oder kurz REST nennt.

REST basiert auf Prinzipien, die in der größten verteilten Anwendung eingesetzt werden - dem World Wide Web. Das World Wide Web stellt selbst eine gigantische REST Anwendung dar. Viele Suchmaschinen, Shops oder Buchungssysteme sind ohne Absicht bereits als REST basierter Web Services verfügbar.

Die REpresentational State Transfer Architektur ist ein Architektur Modell, welches beschreibt, wie das Web funktionieren sollte. Das Modell soll als Anleitung und als Referenz für zukünftiger Erweiterungen dienen.

REST ist kein Produkt oder Standard. REST beschreibt, wie Web Standards in einer Web gerechten Weise einsetzt werden können.

1 Beispiel einer REST Anwendung

Ein Onlineshop soll als Beispiel für eine RESTful Anwendung dienen. In der Anwendung gibt es Kunden, die Artikel in Warenkörbe aufnehmen können.

Jedes einzelne Objekt der Anwendung wie Artikel oder Kunde stellt eine Resource dar, die extern über eine URL erreichbar ist. Mit dem folgenden Aufruf ist in der Beispielanwendung der Warenkorb mit der Nummer 5873 erreichbar.

GET /warenkorb/5873

Beispiel 1: Aufruf Warenkorb #5873

Wie das Ergebnis einer Anfrage repräsentiert wird, ist bei REST nicht spezifiziert. Zwischen Client und Server muss ein gemeinsames Verständnis über die Bedeutung der Repräsentation vorhanden sein. Die Verwendung von XML macht es leicht, die Repräsenation sowohl für Menschen als auch für Maschinen verständlich zu gestalten. Das Ergebnis der Warenkorbabfrage könnte wie folgt aussehen:

HTTP/1.1 200 OK Content-Type: text/xml <?xml version="1.0"?> <warenkorb xmlns:xlink="http://www.w3.org/1999/xlin k"> <kunde xlink:href="http://shop.oio.de/kunde/587 3"> 5873</kunde> <position nr="1" menge="5"> <artikel xlink:href="http://shop.oio.de/ar tikel/4501" nr="4501"> <beschreibung>Dauerlutscher</beschreib ung> </artikel> </position> <position nr="2" menge="2"> <artikel xlink:href="http://shop.oio.de/ar tikel/5860" nr="5860"> <beschreibung>Earl Grey Tea</beschrei bung> </artikel> </position> </warenkorb>

Beispiel 2: Repräsentation eines Warenkorbes

Die Antwort des Servers enthält wie aus Listing 1. ersichtlich ein XML Dokument, welches von Natur aus mit zahlreichen XML Standards kompatibel ist und weiterverarbeitet werden kann. Die Anwort kann mittels einer XSLT Transformation beispielsweise in HTML, SVG oder PDF umgewandelt werden. Das Dokument kann auf weitere Resourcen mit XLink und XPointer verweisen. Mit XPath oder XQuery können Abfragen an das Dokument formuliert werden.

Der Warenkorb enthält zwei Positionen und den zugehörigen Kunden. Die Positionen verweisen mittels XLink auf weitere Resourcen, die Artikel. Der Client kann einen Link verfolgen und die Repräsentation eines Artikels anfordern. Er welchselt auf diese Weise von einem Status in einen anderen.

GET /artikel/5860

Beispiel 3: Artikelwechsel mittels XLink

Mit jedem Dokument kann der Client tiefer in die Anwendung einsteigen. Als Einstiegspunkt reicht eine einzige URL aus. Die Idee der aus dem Web bekannten Hypertext Dokumente

wird auf Web Services übertragen. Abbildund 1. zeigt einen Graphen, der sich durch die Verzeigerung aufspannt. Der Client kann sich über Verweise von Resource zu Resource durchhangeln.

Abbildung 1: Navigation über Links u. HTTP GET

1.1 Bestellen - oder Operation auf dem Server auslösen

In einem guten Schwarztee darf Kandis Zucker nicht fehlen. Die Bestellung muss um diesen wichtigen Artikel erweitert werden. Angenommen Kandis Zucker hätte die Artikelnummer 961. Für das Hinzufügen einer untergeordneten Resource oder den Aufruf von Logik, die auf dem Server eine Statusänderung hervorruft wird die Methode POST verwendet. Die folgende POST Anfrage fügt dem Warekorb den Artikel Kandis Zucker mit der Artikelnummer 961 hinzu.

POST /warenkorb/5873 artikelnummer=961

Beispiel 4: POST Anfrage

1.2 Anlegen von neuen Resourcen

Für das Anlegen neuer Resourcen, die nicht anderen Resourcen zugeordnet sind, kann die HTTP Methode PUT verwendet werden.

PUT /artikel <artikel> <beschreibung-kurz>Rooibusch Tee</beschreibung-ku rz> <beschreibung> Feiner namibischer Rooibusch Tee </beschreibung> <preis>2,80</preis> <einheit>100g</einheit> </artikel>

Beispiel 5: PUT Anfrage

Das Ergebnis des PUT Aufrufes liefert über HTTP eine URL zum neu angelegten Artikel. Mit dem Anlegen wurde ein neues Objekt erzeugt, dass von weiteren Clients verwendet werden kann.

HTTP/1.1 201 OK Content-Type: text/xml; Content-Length: 30 http://shop.oio.de/artikel/6005

Beispiel 6: Antwort auf einen PUT

Listing 3. zeigt die Antwort des Servers. Der HTTP Status Code 201 bedeutet "created", d.h. eine neue Resource wurde angelegt. Im Body der Nachricht steht ein Verweis auf die neu erzeugte Resource, den Rooibusch Tee.

1.3 Löschen von Resourcen

Die neu angelegte Resource kann mit der folgenden HTTP DELETE Anfrage wieder gelöscht werden.

DELETE /artikel/6005

Beispiel 7: Löschen von Resourcen

Das Beispiel hat gezeigt, wie mit Resourcen, HTTP Methoden und URIs gearbeitet werden kann. Die folgenden Abschnitte vertiefen die verwendeten Konzepte.

2 Die Welt von REST

2.1 Resourcen

Web Seiten, Bilder und CGI Skripte bzw. Servlets stellen Resourcen dar, die über URLs adressiert und angesprochen werden können. Eine Web Anwendung stellt eine Ansammlung von Resourcen dar. Mit HTTP können Nachrichten an die Resourcen gesendet werden, beispielsweise durch den Aufruf einer Seite im Browser.

Eine direkte Manipulation einer Resource ist nicht vorgesehen. Jeder Zugriff erfolgt indirekt über die der Resouce zugeordnete URI.

Abbildung 2: Routing von SOAP Messages

Die Semantik des HTTP Protokolls wurde in REST übernommen. Eine zentrale Rolle bei REST spielen die HTTP Methoden GET, PUT, POST und DELETE. Sie stellen die "Verben" dar, die auf "Hauptwörter" bzw. Resourcen, angewandet werden können. Mit diesem begrenzten Vorrat von vier Methoden müßten alle Anwendungsfälle generisch abgedeckt werden können.

2.2 Repräsentationen

Die Repräsentation einer Resource kann auf weitere Resourcen verweisen. Folgt ein Client einem Link in einer Repräsenation, so gelangt er von einem Zustand in einen anderen.

Weshalb die Bezeichnung REpresentational State Transfer verwendet wird, wird aus dem folgendem Szenario deutlich. Ein Web Browser fordert eine Seite, oder allgemeiner eine Resource über eine URL an. Ein HTML Dokument, welches eine Repräsentation der Resource darstellt, wird vom Server zum Client übertragen. Das HTML Dokument kann Links enthalten, die auf weitere Resourcen im Web verweisen. Navigiert der Client zu einer neuen Seite, so verändert er seinen Zustand, er welchselt oder macht einen Transfer zu einem neuen Zustand durch. Über Repräsentationen wird ein Tranfer von einem Status in einen anderen Status durchgeführt.

2.3 Die Methoden

Das Interface von REST ist generisch. Es müssen keine Protokoll-Konventionen bekannt sein, damit Client und Server sich verständigen können. Die folgende Aufzählung beschreibt die Bedeutung der HTTP Methoden, wie sie von REST verwendet werden.

• GET: Get fragt die Repräsentation einer Resource ab. Requests sollten frei von Seiteneffekten sein. GET Requests können beliebig oft abgeschickt werden. Man kann einen Client für seine Auswirkungen nicht in die Verantwortung ziehen. D. h. ein GET kann bedenkenlos abgeschickt werden.

• POST: Mit POST kann einer Resource etwas hinzugefügt werden. Beispielsweise könnte eine Ware zu einem Warenkorb hinzugefügt werden. POST ist nicht frei von Seiteneffekten. Beispielsweise können durch einen POST Aufruf Felder in einer Datenbank verändert oder Prozesse auf dem Server gestartet werden.

• PUT: Neue Resourcen können mit PUT erzeugt oder der Inhalt bestehender Resourcen kann mit PUT ersetzt werden.

• DELETE: Resourcen können mit DELETE gelöscht werden.

Jede REST Resource besitzt über die HTTP Methoden GET, POST, PUT und DELETE eine generische Schnittstelle. Mit diesen vier Methoden können die meisten Anwendungsfälle abgedeckt werden. Viele Anwendungen, die SQL verwenden benutzen auch nur die generischen Befehle SELECT, INSERT, UPDATE und DELETE.

2.4 Nachrichten

Sämtliche Dokument Typen können in REST Anwendungen übertragen werden. Beispielsweise werden im Web u.a. HTML, GIF und PDF Dateien verwendet. Für die Übertragung von strukturierten Daten eignet sich XML. XML Dokumente können XLink für Verweise benutzen. Wer eine Anwendung mit REST realisieren möchte muss kein neues Format erlernen. Man kann bereits bekannte Formate verwenden.

Nachrichten sind in REST selbstbeschreibend. In einer Nachricht muss alles enthalten sein, um die Nachricht zu interpretieren. Für die Interpretation einer Nachricht ist kein Wissen über vorherige oder spätere Nachrichten notwendig. Der Status einer Anwendung wird durch den Inhalt einer oder mehrerer Hypertext Dokumente repräsentiert.

2.5 Status und Session

Der Server kennt seinen Status. Für den Clientstatus oder Sessions zu seinen Clients interessiert er sich nicht. Der Client verwaltet seinen Status selbst. Er entscheidet auch, über die Reihenfolge, in der er verschiedene Methoden auf dem Server aufruft.

In REST Anwendungen wird meist keine spezielle Funktionalität für den Login benötigt. Alle Resourcen lassen sich mit verfügbaren Web Technologien wie zum Beispiel HTTP und HTTPS authentifizieren und autorisieren.

3 REST und Sicherheit

Die Vision von CORBA als galaktischer Objektbus hat sich nicht wie von seinen Verfechtern prophezeit erfüllt. Der Grund lag neben der Komplexität von CORBA daran, dass Firmen- und Organisationsnetze zunehmend durch Firewalls geschützt wurden. Das von CORBA verwendete Protokoll IIOP wird von den meisten Firewalls geblockt.

Die Tatsache, daß die meisten Firewalls HTTP für das Surfen im Web zulassen wird ausgenutzt, um beliebige Nachrichten über Firewalls zu übertragen. SOAP und XML-RPC verwenden das Anwendungsprotokoll HTTP als reines Transportprotokoll, indem Sie Anfragen und Antworten in HTTP einpacken. Mit dem Tunneling ist eine Objektkommunikation trotz Firewalls wieder möglich.

Für die bestehenden Firewalls und Administatoren sehen alle SOAP oder XML-RPC Nachrichten gleich aus. Es handelt sich um einen HTTP Post. Um die Bedeutung einer Nachricht zu verstehen, muß der SOAP Body betrachtet werden, der nichts mit HTTP und den Dingen zu tun hat, die ein Administrator oder eine Firewall im Normalfall kennen.

Eine REST basierte Anwendung verwendet für seine Nachrichten HTTP Methoden und URLs. Firewalls sind mit HTTP und URLs vertraut. Sie können nach Methoden und URLs filtern. Zum Beispiel läßt sich über eine Firewall der Zugriff auf eine REST Anwendung auf einen Lesezugriff beschränken, indem nur GET Anfragen von Externen erlaubt werden.

Die Bedeutung einer Nachricht geht in einer REST Anwendung aus den HTTP Anfragen hervor. Das Zugriffsprotokoll eines Web Servers verrät, welche Aktionen durchgeführt wurden. Aus dem Protokoll in Listing 4. geht hervor, dass der Warenkorb 6 und die Artikel 5 und 12 ausgelesen wurden. Mit dem folgenden POST wurde wahrscheinlich dem Warenkorb eine Ware hinzugefügt. Anschließend wird der Warenkorb bestellt und die neu erzeute Bestellung ausgelesen.

hermes.oio.de - - [26/Nov/2002:12:43:07 +0100] "GET /warenkorb/6 HTTP/1.1" 200 hermes.oio.de - - [26/Nov/2002:12:43:08 +0100] "GET /artikel/12 HTTP/1.1" 200 hermes.oio.de - - [26/Nov/2002:12:43:08 +0100] "GET /artikel/5 HTTP/1.1" 200 hermes.oio.de - - [26/Nov/2002:12:43:09 +0100] "POST /warenkorb/6 HTTP/1.1" 200 hermes.oio.de - - [26/Nov/2002:12:43:13 +0100] "POST /warenkorb/6 HTTP/1.1" 200 hermes.oio.de - - [26/Nov/2002:12:43:14 +0100] "GET /bestellung/3 HTTP/1.1" 200

Beispiel 8: Protokoll einer REST Anwendung

In SOAP sind alle wesentlichen Parameter in der Nachricht kodiert. Ein Firewall Administrator hat wenig Einfluß und bleibt meist außen vor. Es besteht die Gefahr, dass SOAP zukünftig in einigen Firewallinstallationen ausgefiltert werden wird. Mit REST

basierten Anwendungen können Administratoren leichter eingebunden werden. Sie bekommen die Möglichkeit mit Ihren Mitteln und Tools zu Protokollieren und zu Filtern. Die Bereitschaft REST nicht zu blockieren ist damit wesentlich größer. Ein generelles Blockieren von REST ist auch nicht möglich, es sei denn, der Zugriff auf das Web wird komplett gesperrt.

4 Merkmale einer REST Anwendung

Die folgenden Merkmale kennzeichen den REST Stil.

• Die Kommunikation erfolgt auf Abruf. Der Client ist aktiv und fordert vom passiven Server eine Repräsentation an, bzw. modifiziert eine Resource.

• Resourcen, die Objekte der Anwendung, besitzen eine ihnen zugeordnete URI, mit der sie adressiert werden können.

• Die Representation einer Resource kann als Dokument vom Client angefordert werden.

• Repräsentationen können auf weitere Resourcen verweisen, die ihrerseits wieder Repräsentationen liefern, die wiederum auf Resourcen verweisen können.

• Der Server verfolgt keinen Clientstatus. Jede Anfrage an den Server muss alle Informationen beinhalten, die zum Interpretieren der Anfrage notwendig sind.

• Caches werden unterstützt. Der Server kann seine Antwort als Cache fähig oder nicht Cache fähig kennzeichnen.

5 Vorteile von REST

5.1 Skalierbarkeit

Das enorme Wachstum des World Wide Web hat gezeigt, in welchem Ausmaß Web Technologien skalieren. Millionen Benutzer verwenden Resourcen, die von vielen Tausend Servern angeboten werden. Proxys und Caches erhöhen die Performance. Komponenten wie Server, Proxys und Web Anwendungen können einzeln installiert und gewartet werden.

Es gibt eine Fülle von Formaten von HTML und SVG bis AVI. Selbst neue Formate können über MIME Types leicht hinzugefügt werden. Die größe der übertragenen Dokumente schwankt von wenigen Bytes bis zu vielen Megabytes.

Im Web werden mit Cookies und URL Rewriting auf das statuslose HTTP künstlich Session aufgesetzt, die stateful sind. In diesem Punkt weicht REST vom Web ab. Interaktionen sind in REST stateless- jede Operation steht für sich. Alle notwendigen Informationen sind in den Repräsentationen der Resourcen enthalten. Mit HTTP gibt es keine Grenzen zwischen den Anwendungen. Durch die Verfolgung eines Links kann man, ohne es zu beabsichtigen, zu einer völlig anderen Anwendung gelangen. Da alle Interaktionen statuslos sind, muss daher bei einem Wechsel von einem Server zu einem anderen kein Status zwischen den Servern propagiert werden. Dies hat positive Auswirkungen auf die Skalierbarkeit einer Anwendung.

5.2 Anbindung von Fremdsystemen

In keiner anderen Anwendung sind so viele Legacy Systeme wie im Web integriert. Über verschiedene Gateways kann auf eine Fülle von Systemen zugegriffen werden. Die Details von Fremdsystemen werden hinter Schnittstellen versteckt.

5.3 Unabhängig installierbare Komponenten

Für Komponenten kann in einer REST Anwendung unabhängig voneinander das Deployment durchgeführt werden. Im Web kann ja auch der Inhalt einzelner Seiten ausgetauscht werden, ohne weitere Seiten anzupassen. Für sehr große Systeme, wie das World Wide Web oder der eMail Dienst im Internet, ist ein unabhängiges Deployment eine Grundvoraussetzung.

5.4 Komposition von Diensten

Einzelne REST Services können leicht zusammen genutzt werden. Genau genommen gibt es keine REST Services. Es gibt nur Resourcen, die angeboten werden. Über den globalen und universellen Adressraum der URIs können die Grenzen einer Anwendung leicht überschritten werden. Eine Dokument verweist einfach auf eine Resource, die sich in einer anderen Organisation befindet.

6 Vergleich von REST und SOAP

Bei SOAP handelt es sich um eine RPC Middleware [1], die HTTP oder SMTP als Transportprotokoll und XML als Nachrichtenformat verwendet. Der Vollständigkeit halber muss erwähnt werden, dass mit SOAP with Attachments auch Dokumente übertragen werden können.

Die Zustellung von SOAP Nachrichten ist vergleichbar mit der Funktionsweise einer Hauspost. Die Briefkörbe der Mitarbeiter können nicht direkt adressiert werden. Alle Briefe werden bei der Hauspost angeliefert. Die Hauspost muss vor einer Zustellung die Briefe öffnen und entscheidet dann, aufgrund des Inhaltes, an wen die Nachricht weitergeleitet wird. In einer REST Anwendung sind die Briefkörbe direkt adressierbar. Mit der SOAP Spezifikation 1.2 nähert sich in diesem Punkt SOAP an REST an. Zukünftig können Methoden auch außerhalb des Bodys spezifiziert werden.

SOAP Nachrichten werden immer an einen Endpunkt adressiert, der von einem SOAP Router, oder auch Dispatcher genannt, implementiert wird. SOAP Router werden mit einem Servlet oder einem CGI Skript realisiert. Aus Abbildung 3 ist ersichtlich, dass alle Aufrufe zunächst an den Dispatcher gerichtet werden. Jede Nachricht ist ein HTTP POST an die selbe Adresse.

Abbildung 3: Routing von SOAP Messages

SOAP ist ein Protokollbaukasten, mit dem jeder Entwickler seine eigenen Anwendungsprotokolle entwickelt. Das Protokoll beschreibt den genauen Aufbau einer Anfrage und einer Antwort. Die Beschreibung der Anfrage und Antwort stellt einen starren Rahmen dar, aus dem nicht leicht ausgebrochen werden kann. Möchte der Server weitere Informationen als bisher liefern, so kann er das nicht über die bestehende Schnittstelle tun. Damit die bereits installierten Clients kompatibel bleiben, ist ein neuer Web Service notwendig. Mit REST kann der Server zusätzliche Informationen liefern und das Interface des Web Service kann unverändert bleiben. In SOAP fehlt die Möglichkeit zur schrittweisen Evolution bestehender Web Services.

Ein ganz entscheidender Unterschied zwischen REST und SOAP ist der Adressraum. REST bietet mit den URIs einen globalen Adressraum, über den jede Resource adressiert werden kann. Bei REST steht die Resource im Vordergrund. Einen Service im eigentlichen Sinne gibt es bei REST nicht.

6.1 Proxy Server

Eine RESTful Anwendung besteht aus einer Vielzahl von URLs, auf die die Clients zugreifen können. Wird über einen Proxy Server auf eine REST Anwendung zugegriffen, so kann ein normaler Proxyserver wie z.B. der beliebte Squid eine Entscheidung anhand der URL treffen, ob er einen Zugriff erlauben oder verhindern soll. Der Zugriff auf jedes Objekt kann im Proxy und im Web Server protokolliert werden. Da alle SOAP Anfragen meist über eine URL

geroutet werden, hat ein Proxy oder Web Server keine Möglichkeit über die URL eine Entscheidung zu treffen. In RESTful Anwendungen kann beispielsweise der Zugriff auf alle URLs mit dem folgenden Muster verboten werden:

deny http://shop.oio.de/artikel/delete/*

Beispiel 9: Zugriff auf URL verbieten

Mit REST ist das Cachen von GET Aufrufen möglich. SOAP verwendet dagegen ausschließlich die POST Methode, die nicht gecacht wird.

6.2 Generische Schnittstelle

REST bietet mit den Methoden GET, POST, PUT und DELETE ein generisches Interface. In SOAP müssen alle Methoden für jede Anwendung selbst definiert werden. Die Entwicklung von generischen Tools und Diensten im Web wird dadurch behindert.

6.3 Standards

REST empfiehlt die Verwendung von etablierten Standards. Dem Entwickler stehen beispielsweise die folgenden "Technologien" zur Verfügung:

• URIs für die Adressierung • HTTP Methoden für den Zugriff • XML, XHTML, HTML, PNG, ... für die Datenformate • MIME Typen

Zentral sind die Standards für HTTP und URIs. Für die Formate der Repräsentationen können dagegen beliebige Formate eingesetzt werden. Auch zukünftige Technologien können verwendet werden.

Für SOAP wird jetzt erst eine Reihe von Standards wie WSDL, UDDI, WS-Security, WS-Transactions oder BPEL4WS neu geschaffen, die ausschließlich für SOAP gedacht sind. Bei den Standards für REST handelt es sich um "richtige" Web Standards, die für viele Zwecke, nicht nur für REST, eingesetzt werden können.

7 Wie erstellt man eine REST Anwendung...

... oder macht eine bestehende Anwendung RESTful? Verteilte Anwendungen basieren auf Funktionen oder Methoden, die auf Objekten arbeiten. Der Client kann über entfernte Methoden auf die Objekte des Servers zugreifen. Eine REST Anwendung macht Ihre Objekte über URIs nach außen sichtbar. Geschäftsobjekte müssen über eine URL erreichbar sein und mit einem Dokument, vorzugsweise in XML, repräsentiert werden können.

Der Kern eines REST Servers unterscheidet sich nicht von einer RPC Anwendung. Der Unterschied liegt in der Schnittstelle, die sich bei REST grundlegend von einer RPC Anwendung unterscheidet. REST verwendet die HTTP Methoden, die auf über URI adressierbare Resourcen arbeiten, während RPC ein komponentenbasiertes Interface mit spezialisierten Methoden oder Funktionen zur Verfügung stellt.

8 REST und das Semantische Web

Bei SOAP und REST muss der Client die Nachrichten des Servers zu interpretieren verstehen. Mit RDF als Nachrichtenformat und entsprechenden Interferenz-Maschinen wären Clients denkbar, die zur Laufzeit lernen können. Roger L. Costello schreibt in seiner Präsentation Representational State Transfer [2] :

... ,dynamic learning of response data combined with dynamic reasoning of link traversals would yield a self-reasoning automata. This is the next step of the Web!

9 Grenzen von REST

REST verwendet für den Transport HTTP und transportiert ganze Repräsentationen von Objekten zum Client. Bei Internetanwendungen, die sowieso mit einer hohen Verzögerungszeit rechnen müssen ist dies in Ordnung. Zwischen spezialisierten lokalen Servern z.B. zwischen Application Server und Datenbank benötigt man effizientere Protokolle wie CORBA, RMI oder DCOM.

Das Serialisieren und Deserialisieren von und nach XML wird in REST nicht angesprochen. Der Programmierer muss sich selbst darum kümmern oder ein XML Binding Framework einsetzen.

REST ist ein Architekturstil, der für große Anwendungen mit unbekannter Anzahl von Anwendern und Objekten geeignet ist.

10 Toolunterstützung

REST basiert auf eingeführten Standards, für die es bereits eine Unzahl von Tools gibt. REST fähig sind Web Server wie Apache oder IIS, Web Container wie Tomcat und Proxy Server wie Squid. Spezialisierte REST Tools sind nicht notwendig. Es ist durchaus denkbar, dass zukünftig Bibliotheken, Frameworks oder Tools die Entwicklung von REST Anwendungen gezielt unterstützen.

11 Öffentliche REST Services

Es gibt bereits eine Reihe von öffentlichen Web Services, die bewußt RESTful Schnittstellen verwenden. Zu den bekannteren gehören Web Services von Amazon, Google oder O'Reillys Meerkat.

Einige Dienste im Web wie beispielsweise Wiki Webs sind von Haus aus zumindest teilweise REST konform.

Pacemaker

clusterlabs.org. Abgerufen am 05. 07 2013 von http://clusterlabs.org/

Pacemaker is an Open Source, High Availability resource manager suitable for both small and large clusters.

"Someone said something awesome about Pacemaker here." - Anon

Features

• Detection and recovery of machine and application-level failures • Supports practically any redundancy configuration

• Supports both quorate and resource-driven clusters

• Configurable strategies for dealing with quorum loss (when multiple machines fail)

• Supports application startup/shutdown ordering, regardless machine(s) the applications are

on

• Supports applications that must/must-not run on the same machine

• Supports applications which need to be active on multiple machines

• Supports applications with multiple modes (eg. master/slave)

• Provably correct response to any failure or cluster state. The cluster's response to any stimuli can be tested offline before the condition exists

Background

Pacemaker has been around since 2004 and is primarily a collaborative effort between Red Hat and Novell, however we also receive considerable help and support from the folks at LinBit and the community in general.

The core Pacemaker team is made up of full-time developers from Australia, USA, Austria, Germany, and China. Contributions to the code or documentation are always welcome.

Pacemaker ships with most modern enterprise distributions and has been deployed in many critical environments including Deutsche Flugsicherung GmbH (DFS) which uses Pacemaker with Heartbeat to ensure its air traffic control systems are always available

Currently Andrew Beekhof is the project lead for Pacemaker.

Configuration Tools

Pacemaker's internal configuration format is XML, which is great for machines but terrible for humans. The community's best minds have created GUIs and Shells to hide the XML and allow the configuration to be viewed and updated in a more human friendly format.

Command Line Interfaces (Shells)

crmsh - The original configuration shell for Pacemaker. Written and maintained by SUSE, it may be used either as an interactive shell with tab completion, for single commands directly on the shell's command line or as batch mode scripting tool.

pcs - An alternate vision for a full cluster lifecycle configuration shell and web based GUI. Handles everything from cluster installation through to resource configuration and status.

GUI Tools

pygui - The original GUI for Pacemaker written in Python by IBM China. Mostly deprecated on SLES in favor of Hawk

hawk - Hawk is a web-based GUI for managing and monitoring Pacemaker HA clusters. It is generally intended to be run on every node in the cluster, so that you can just point your web browser at any node to access it. It is documented as part of the SUSE Linux Enterprise High Availability Extension documentation

LCMC - The Linux Cluster Management Console (LCMC) is a GUI with an inovative approach for representing the status of and relationships between cluster services. It uses SSH to let you install, configure and manage clusters from your desktop.

pcs - An alternate vision for a full cluster lifecycle configuration shell and web based GUI. Handles everything from cluster installation through to resource configuration and status.

Other Add-ons

booth - The Booth cluster ticket manager extends Pacemaker to support geographically distributed clustering. It does this by managing the granting and revoking of 'tickets' which authorizes one of the cluster sites, potentially located in geographically dispersed locations, to run certain resources.

Regenachsen

regenachsen.de. Abgerufen am 27. 06 2013 von http://www.regenechsen.de/phpwcms/index.php?krypto_asym_eg

Asymmetrische Verfahren: ElGamal

Asymmetrische Verfahren: ElGamal

In PGP, GnuPG und in S/MIME wird für die Verschlüsselung des Sitzungsschlüssels ein

asymmetrisches Verfahren gewählt. Neben RSA ist hier Diffie-Hellmann und ElGamal vorgesehen .

In diesem Kapitel soll die grundlegende Funktionsweise und der Vorgang für das Verfahren nach

ElGamal [Selke][Schneier][Gerold][Gerold, Vorlesung TU München] beschrieben werden. Die

Darstellung richtet sich nicht an Mathematiker und Kryptospezialisten, sondern an einfache,

interessierte Anwender von Krypto-Software.

Das Verfahren wurde 1985 von ElGamal veröffentlicht. Es eignet sich sowohl zur Verschlüsselung als

auch für digitale Signaturen. Seine Sicherheit beruht auf der Schwierigkeit, diskrete Logarithmen zu

bestimmen. Das heißt, es ist einfach eine Zahl mit einer anderen zu potenzieren (y=ab), aber zur Zeit

ist kein mathematisches Verfahren bekannt, diesen Prozess ohne Kenntnis von b korrekt

umzukehren, ohne raten zu müssen.

1. Schritt

Zunächst benötigen wir eine große Primzahl Z. Sicherheitshalber sollte diese Zahl um Eins verringert

und dann halbiert (Z-1)/2 ebenfalls prim sein. Je nach Schlüssellänge ist diese Zahl viele Bit lang, in

unserem Falle soll ihr Wert aber nur 11 betragen.

2. Schritt

Wir benötigen zwei weitere beliebige Zahlen y und g, die größer als Eins, aber kleiner als die Zahl Z

sein müssen. Nehmen wir für unser Beispiel y=2 und g=3. Aus diesen Werten, zusammen mit Z,

bilden wir:

p=yg mod Z

Also y wird mit g potenziert, durch Z geteilt und der Rest wird als p weiterverwertet. p, y und Z sind

öffentlich und werden auch im öffentlichen Schlüssel verwendet. g dagegen ist geheim und darf nie

veröffentlicht werden.

Betrachten wir das Ergebnis in unserem Beispiel:

p = 23 mod 11

= 8/11

= 0 Rest 8

p = 8

Damit hätten wir bis jetzt: Z = 11 p = 8 y = 2 g = 3

Verschlüsselung

Die Klartextnachricht soll lauten: 05070810

Die zu verschlüsselnde Nachricht muss einen Wert aufweisen, der kleiner als Z ist, sonst muss er in

Teile zerlegt werden. Für unser Beispiel gilt daher für die Nachricht:

05 07 08 10

Der Absender benötigt noch eine zufällige Zahl x, die größer Eins, aber kleiner Z-1 sein muss und

keinen gemeinsamen Teiler mit Z haben soll. Wir nehmen den Wert x=5 an. Der Absender erzeugt

zunächst mal die Hilfsgröße c1:

c1= yx mod Z

und außerdem für jeden zu verschlüsselnden Klartextteil

c2=(k px) mod Z mit k= Klartextteil.

In unserem Beispiel wäre c1 damit

c1

= 25 mod 11

= 32/11

= 2 Rest 10

c1 = 10

und für c2 ergäbe sich mit k=05

c2

= (5*85) mod 11

= 163840/11

= 14894 Rest 6

usw.

k c2

05 06

07 04

08 03

10 01

Die chiffrierte Nachricht lautet 06 04 03 01

Zusätzlich wird der Wert c1=10 übermittelt.

Entschlüsselung

Der Empfänger weiß nichts von der Hilfszahl x, benötigt diese aber für die Rückrechnung auch nicht.

Für die Entschlüsselung gilt

k= (c2 c1(Z-1-g)) mod Z

Im ersten Teil der Nachricht 06 ergibt dies:

k

= (6*10(11-1-3)) mod 11

= (6*107) mod 11

= 6*10000000/11

= 5454545 Rest 5

c2 k

06 05

04 07

03 08

01 10

Die Darstellung zeigt, dass ähnlich wie bei RSA der Vorgang sehr simpel und die Mathematik nicht

schwierig ist (sieht man mal vom Umgang mit sehr großen Zahlen ab). Sie ist bewusst sehr einfach

gewählt und hat, dem besseren Verständnis dienend, unrealistisch kleine Werte verwendet.

Microsoft Security

msdn.Microsoft.com. Abgerufen am 10. 06 2013 von http://msdn.microsoft.com/en-us/library/windows/desktop/aa380513%28v=vs.85%29.aspx

TLS Handshake Protocol 24 out of 32 rated this helpful - Rate this topic

The Transport Layer Security (TLS) Handshake Protocol is responsible for the authentication and key exchange necessary to establish or resume secure sessions. When establishing a secure session, the Handshake Protocol manages the following:

• Cipher suite negotiation

• Authentication of the server and optionally, the client

• Session key information exchange.

Cipher Suite Negotiation

The client and server make contact and choose the cipher suite that will be used throughout their message exchange.

Authentication

In TLS, a server proves its identity to the client. The client might also need to prove its identity to the server. PKI, the use of public/private key pairs, is the basis of this authentication. The exact method used for authentication is determined by the cipher suite negotiated.

Key Exchange

The client and server exchange random numbers and a special number called the Pre-Master Secret. These numbers are combined with additional data permitting client and server to create their shared secret, called the Master Secret. The Master Secret is used by client and server to generate the write MAC secret, which is the session key used for hashing, and the write key, which is the session key used for encryption.

Establishing a Secure Session by Using TLS

The TLS Handshake Protocol involves the following steps:

1. The client sends a "Client hello" message to the server, along with the client's random value

and supported cipher suites. 2. The server responds by sending a "Server hello" message to the client, along with the

server's random value.

3. The server sends its certificate to the client for authentication and may request a certificate

from the client. The server sends the "Server hello done" message.

4. If the server has requested a certificate from the client, the client sends it.

5. The client creates a random Pre-Master Secret and encrypts it with the public key from the

server's certificate, sending the encrypted Pre-Master Secret to the server.

6. The server receives the Pre-Master Secret. The server and client each generate the Master

Secret and session keys based on the Pre-Master Secret.

7. The client sends "Change cipher spec" notification to server to indicate that the client will

start using the new session keys for hashing and encrypting messages. Client also sends

"Client finished" message.

8. Server receives "Change cipher spec" and switches its record layer security state to

symmetric encryption using the session keys. Server sends "Server finished" message to the

client.

9. Client and server can now exchange application data over the secured channel they have

established. All messages sent from client to server and from server to client are encrypted

using session key.

Resuming a Secure Session by Using TLS

1. The client sends a "Client hello" message using the Session ID of the session to be resumed. 2. The server checks its session cache for a matching Session ID. If a match is found, and the

server is able to resume the session, it sends a "Server hello" message with the Session ID.

Note If a session ID match is not found, the server generates a new session ID and the TLS

client and server perform a full handshake.

3. Client and server must exchange "Change cipher spec" messages and send "Client finished"

and "Server finished" messages.

4. Client and server can now resume application data exchange over the secure channel.

SSL

SSL.de. Abgerufen am 10. 06 2013 von https://www.ssl.de/ssl.html

W i e f u n k t i o n i e r t S S L

TCP/IP:

Sicher und unsicher zugleich

SSL ist die Abkürzung für Secure Socket Layer.

Mit Layer sind die Transportschichten angesprochen, mit denen der

Datenaustausch zwischen zwei Rechner bildhaft dargestellt wird. Auf

der obersten Ebene sind die Anwendungen angeordnet. Ganz unten

befindet sich in dem Modell die Hardware.

Im Idealfall lassen sich sieben Schichten definieren, denen sich

wiederum im Idealfall jeweils ein Protokoll oder Programm zuordnen

läßt. Alle Schichten tragen dazu bei, den Datenfluß zwischen den

beiden Rechnern sicherzustellen.

Im wirklichen Leben paßt das Modell nicht immer so ideal. Das

Übertragungsprotokoll TCP/IP deckt mit seinen zwei Komponenten

(TCP und IP) mindestens vier Schichten ab. Das Protokoll ist eine Art

Esperanto in der Rechnerwelt. Mit Ausnahme der Zuse-Rechner

unterstützen wohl alle Rechner und Betriebssysteme TCP/IP (findige

Tüftler haben sogar dem ZX81 TCP/IP beigebracht).

Es ist einfach zu implementieren, robust und sicher -- betriebssicher.

Als TCP/IP vor fast 30 Jahren erfunden wurde, stand vor allem die

Absicht im Vordergrund, eine ausfallsichere und stabile Verbindung

mit hoher Betriebssicherheit zu schaffen. Die Sicherheit und

Authenzität der übermittelten Daten spielte eine untergeordnete

Rolle.

Neue Schichten Mit TCP/IP war der Wunsch nach sicheren Verbindungen im Sinne von

Datensicherheit nicht zu verwirklichen. Ohne TCP/IP gibt es kein

Internet.

Die Firma Netscape löste das Problem auf folgende elegante Weise:

Die Entwickler erweiterten TCP/IP um zwei weitere Schichten.

SSL Record Protokoll

SSL Handshake Protocol

Das erklärt auch die Bezeichnung »Layer«; Sie liegen funktional

zwischen dem Aufgabenbereich von TCP/IP und den Anwendungen.

Diese beiden Schichten liegen bildlich betrachtet unmittelbar

aufeinander und werden darum von einigen Autoren auch als eine

einzige Schicht angesprochen. Obgleich sich in diesen beiden

Schichten während einer sicheren Verbindung allerlei Software-Know-

How austobt, ist sie für die angrenzenden Schichten transparent:

Weder die Anwendung (der Browser, noch die unter der dem SLL-

Protokoll liegende Transportschicht bemerken das Wirken des SLL-

Protokoll. Im Klartext: SSL erfordert weder Änderungen vorhandener

Anwendungen noch neue Transportprotokolle.

Während einer sicheren Verbindung kommunizieren die beteiligten

Rechner ausschließlich über den Mechanismus, der von SSL bereit

gestellt wird. Steht die sichere Verbindung nicht zur Verfügung,

schaltet sich das SSL-Protokoll aus.

Sicherheit durch SSL Das SSL-Protokoll schafft unter drei Gesichtspunkten sichere

Verbindungen:

1. Die Verbindung ist im besten Sinne privat, weil ihr Inhalt nur verschlüsselt über das Netz geht.

2. Die Identität des Servers steht fest.

3. Wirkungungsvolle Algorithmen prüfen, ob die Daten

vollständig und unverändert ihren jeweiligen Empfänger

erreichen.

Das SSL-Protokoll wird dadurch initiiert, daß dem bekannten http ein s

angehängt wird: https://www.ssl.de.

Das ist für den Browser der Anlaß, vom angesprochenen Server ein

Zertifikat und seinen öffentlichen Schlüssel abzufordern. Dieser

Schlüssel wird zusammen mit einer Prüfsumme und einer ID an den

Browser zurückgemeldet. Diese Informationen werden von einigen

wenigen Zertifizierungsfirmen errechnet. Die bekannteste ist VeriSign.

Die Firma Thawte in Südafrika gehört zu Versign.

Der Browser prüft anhand der übermittelten Daten, ob er wirklich mit

dem Server verbunden ist, der in der URL angegeben ist. Ist das der

Fall, gibt der Browser dem Anwender eine entsprechende

Information: Beim Internet Explorer schließt sich das Bügelschloß, der

Navigator/Communicator signalisiert eine sichere Seite durch den

intakten Schlüssel. Beim Firefox ist zusätzlich die ganze URL im Adress-

Feld gelb unterlegt.

In der folgenden Phase verständigen sich die beiden Rechner auf

einen symmetrischen Schlüssel (Session Key). Da diese Absprache in

asymmetrischer Verschlüsselung vollzogen wird, ist die Sicherheit

gegeben. Der Browser schickt dem Server vor dem Beginn des

eigentlichen Datenaustausches einige Testnachrichten, die der Server

nur beantworten kann, wenn es wirklich der Server ist, der er zu sein

vorgibt.

Zertifizierung Im Zentrum des SSL-Protokoll steht das digitale Schüsselpaar aus

öffentlichem und privaten Schlüssel des Servers sowie die ID der

Zertifizierungsstelle. Jeder virtuelle Webserver benötigt ein eigenes

Schlüsselpaar, weil bei der ID unter anderem der Domain-Namen

einfließt.

Jede SSL-geschützte Homepage benötigt eine eigene IP-Adresse.

Provider, die auf ihren Servern tausende und abertausende Präsenzen

auf einer einzigen Maschine und unter einer einzigen IP-Adresse

betreiben, müssen darum beim Bereitstellen eines SSL-Zertifikates

passen oder zu technischen Hilfsmittel greifen.

So funktioniert der Trick:

Der Browser des Besuchers verbindet sich nicht mit der eigentlichen

Bestellseite, sondern mit einem Spezialserver (SSL-Proxy) des

Providers. Nur bis dahin ist die Verbindung dann gesichert. Der Proxy-

Server leitet die Informationen des Besuchers dann auf das eigentliche

Ziel, zum Beispiel eine Bestellseite, weiter. Die Weiterleitung von dem

SSL-Proxy zur Bestellseite ist dann nicht mehr gesichert. Das kann

schon eine Einbuße an Sicherheit bedeuten, wenn im Netz des

Providers viele Kundenserver untergebracht werden, die gegebenfalls

den nunmehr ungeschützen Datenstrom abhören können.

Was nicht gesichert ist: Das SSL-Protokoll sichert die Übertragung zwischen einer Domain auf

einem Webserver und dem Besucher dieser Domain. Der On-Line-

Kunde (Besucher) kann sich ziemlich sicher sein, daß seine

Kreditkartennummer auf dem Weg von seinem Rechner zum Server

des Shop-Betreiber gegen Ausforschung geschützt ist. Was dann mit

den gesichert übertragenen Daten weiter passiert, ist jenseits dessen,

was durch das SSL-Protokoll geregelt ist. Für den Kunden, der im

Vertrauen auf die SSL-Sicherung seine Kontoinformationen kundgibt,

ist nicht erkennbar, wie der Shop-Betreiber diese Informationen

weiterverarbeitet. Es sind Fälle bekannt geworden, bei denen der

Datenverarbeiter die gesichert übertagenen Daten anschließend

ungesichert auf dem Server gespeichert hat. Nach einem

erfolgreichen Hacker-Angriff waren die sensiblen Daten plötzlich in

falschen Händen. Wir lernen daraus: SSL-Schützt nicht vor

Schlamperei und Leichtsinn.

� Online per SSL Sicher ist es, wenn der Empfänger die Daten über eine

gleichfalls SSL-gesicherte Verbindung über den Browser oder

per SSL-gesichertem POP3-Abruf abruft und anschließend auf dem Server löscht. Ob der Empfänger Ihrer

Kreditkartennummer das auch wirklich tut, kann er Ihnen nur

selber sagen. Das SSL-Protokoll ist nur für die Anlieferung der

Daten zum Server zuständig, nicht für das Ausliefern.

Das bedeutet allerdings, daß der Shop-Betreiber regelmäßig

manuell tätig werden muß. Das ist natürlich etwas unpraktisch

und lästig.

� eMail

Bequemer ist es, wenn die Bestellung mit den

Bezahlinformationen in einem Abwasch per eMail ins Büro

kommt. Viele Shop-Betreiber und andere Nutzer von SSL-

gesicherter Datenübertragung fassen die übermittelten Daten mit den anderen Bestelldaten zu einer handlichen Textdatei

zusammen, die als eMail den Empfänger erreicht.

Das ist ungefähr so, als ob man seine wertvolle Fracht mit

großem Aufwand durch alle Fährnisse dieser Welt geschafft

hätte, um sie dann unbewacht im Wartesaal des

Hauptbahnhofes abzustellen.

� PGP-verschlüsselt

Besser ist es, die gesammelten Informationen vor dem

Versenden als eMail auf dem Server per PGP zu verschlüsseln.

Die so gesicherte Datei kann man getrost versenden. Niemand, mit Ausnahme des Empfängers, kann die

Informationen lesen. Das erfordert seitens des Shop-Anbieters

beziehungsweise seitens des Providers einen gewissen

Mehraufwand. Allerdings handelt es sich um einen einmaligen

Vorgang. Der laufende Betrieb ist so einfach wie eMails

abholen.

Wer für vertrauliche Informationen eine SSL-gesicherte Übertragung

nutzt, kann leider nicht erkennen, ob dem Empfänger diese Daten

solchen Mehraufwand wert sind. Wenn Shop-Betreiber die Sicherheit

der Kundendaten mehr wert ist, sollten sie dieses auf der Homepage

deutlich hervorheben.

Denn das SSL-Protokoll ist nur die halbe Sicherheit.

Folgende Faustregeln bieten einen ersten Anhalt, welche Sicherheit

der Betreiber einer Webseite bieten kann.

� Websites, die auf den Servern bekannter Massenhostern

liegen, bieten wegen der dort üblichen Mehrfachnutzung der IP-Adressen nur die Nutzung eines SSL-Proxy.

Das ist ein SSL-Server, der vor alle anderen Webpräsenzen

geschaltet ist. Die Daten werden nur bis zu diesem Server

gesichert übertragen und dann ungesichert an die

Webpräsenz weitergereicht.

� Die Fertig-Shops der Massenhoster bieten im Regelfall die

Möglichkeit, die Daten per SSL-gesicherten Web-Interface

abzufragen oder sich die Informationen per SSL-gesicherter

eMail zusenden zu lassen. � Informationen, die auf www.ssl.de gesammelt werden, gehen

dem Empfänger standardmäßig PGP-verschlüsselt zu.

UNI-Tübingen

informatik.uni-tuebingen.de. Abgerufen am 27. 06 2013 von http://www-ti.informatik.uni-tuebingen.de/~reinhard/krypto/German/deutsch.html

4.2 ElGamal

Das ElGamal-Verfahren beruht auf der Schwierigkeit, diskrete Logarithmen zu berechen, also der

Bestimmung von a aus bekanntem beta = alphaa(mod p), wobei p eine Primzahl ist.

Wie beim RSA-Verfahren können mit der hier vorgestellten Form nur Zahlen verschlüsselt werden;

Texte müssen wieder entsprechend kodiert werden.

Das ElGamal-Verfahren besteht aus drei Schritten

1. Schlüsselerzeugung: o Wähle eine große Primzahl p (vgl. 2.3.2), so daß (p - 1) / 2 ebenfalls Primzahl ist* (vgl.

2.3.1).

N sei die Anzahl der Bits von p.

o Wähle eine Basis alpha < p.

o Wähle einen geheimen Schlüssel a < p.

o Berechne beta = alphaa(mod p)

o Veröffentliche p, alpha und beta als öffentlichen Schlüssel.

2. Verschlüsselung einer Nachricht:

o Zerlege den Klartext in Blöcke zu je N - 1 Bit (evtl. auffüllen). o Wähle geheime Zufallszahl k, die zu p - 1 teilerfremd ist, also ggT(k, p - 1) = 1 (vgl. 2.1)

o Berechne für jeden Block x den Geheimtext

e (x, k) = (y1, y2), wobei

y1 = alphak(mod p) und y2 = betakx (mod p).

Dabei sind y1 und y2 jeweils Geheimtextblöcke der Länge N.

3. Entschlüsselung:

o Zerlege den Geheimtext in N-Bit Blöcke

o Für jeweils zwei aufeinanderfolgende Blöcke y1 und y2 löse

y1a x = y2 (mod p)

nach x auf. Also ist

d (y1, y2) = x = y2 (y1a )-1 (mod p)

der gesuchte Klartextblock.

* Für den Spezialfall, daß (p - 1) / 2 ebenfalls eine Primzahl ist, gibt einen effizienten Algorithmus zur

Berechnung des diskreten Logarithmus.

Zookeeper

Apache, zookeeper.apache.org. Abgerufen am 02. 06 2013 von http://zookeeper.apache.org/

ZooKeeper is a centralized service for maintaining configuration information, naming, providing

distributed synchronization, and providing group services. All of these kinds of services are used in

some form or another by distributed applications. Each time they are implemented there is a lot of

work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty

of implementing these kinds of services, applications initially usually skimp on them ,which make

them brittle in the presence of change and difficult to manage. Even when done correctly, different

implementations of these services lead to management complexity when the applications are

deployed.