Wie jedermann mit SSLeay, der frei verfügbaren Implementierung von Netscapes Secure Socket Layer, und einem Patch für den Apache-Server seine Web-Seiten ohne die Gefahr des Ausspähens durch Fremde präsentieren kann, hat iX schon in der Ausgabe 6/96 [[#literatur 2]] gezeigt. Damals benutzte der sichere Server ein selbstunterschriebenes Zertifikat für seine Authentifizierung. Zugleich wurde darauf hingewiesen, daß für ernsthafte Anwendungen im Internet das Zertifikat einer anerkannten Beglaubigungsstelle notwendig ist, damit der argwöhnische Besucher den Zertifikatsangaben Vertrauen schenkt. Innerhalb geschlossener Nutzergruppen dagegen, zum Beispiel im Intranet einer Firma, besitzt die Beglaubigung durch eine interne Einrichtung eine höhere Aussagekraft. Dieser Artikel zeigt nicht nur, wie sich mit Hilfe von SSLeay eine eigene Beglaubigungsstelle zur Zertifikatsvergabe für Web-Server und -Browser einrichten läßt, sondern auch, wie über den Client-Authentication-Mechanismus eine sichere Authentifizierung der Web-Nutzer möglich ist.
Die Unterstützung des SSL-Sicherheitsstandards gehört bei den aktuellen Versionen praktisch aller kommerziellen Web-Server zur Grundausstattung. Netcraft listet in der Januarausgabe des Web-Server-Reports neben knapp 270 000 regulären Apache-Sites immerhin etwa 19 000 Server (insbesondere Stronghold, Apache-SSL) auf, die um SSL-Fähigkeiten erweitert wurden. Zudem läßt Netcrafts Entscheidung, dem Freeware-Report der Servernutzung in Kooperation mit OReilly ein 895-Dollar-Pendant über die Verbreitung von HTTPS-Sites gegenüberzustellen, auf ein wachsendes Interesse an dieser Problematik auf Managementebene schließen.
Zu einem SSL-Web-Server gehört immer ein Zertifikat. Das Ausstellen übernimmt meist eine netzweit tätige, allgemein akzeptierte Beglaubigungsstelle wie Verisign oder Thawte Consulting. (Akzeptanz kann dabei sowohl vom Benutzer gewählt als auch mit dem Browser ausgeliefert und vom Benutzer aus Unkenntnis nicht verändert bedeuten.) Leider ist die wünschenswerte Anbietervielfalt noch nicht am Markt etabliert, und insbesondere mancher Serverbetreiber außerhalb der USA muß die Abwicklung der Zertifikatsanforderung über eine ausländische Firma tätigen. Aber eine deutliche Belebung innerhalb des nächsten Jahres ist mit Sicherheit zu erwarten.
Beim Einsatz von Public-Key-Techniken im firmeninternen Netz sieht die Lage etwas besser aus. Neben einigen dicken Brocken aus der Gründerzeit der X.500-Verzeichnisse gibt es Produkte (oder sie sind zumindest angekündigt) von größeren (Netscape, Microsoft) und kleineren (Xcert) Firmen. Darüber hinaus bieten beispielsweise die oben genannten Beglaubigungsstellen Zertifizierungsdienste im Intranet an. Und schließlich bleibt die Möglichkeit, selbst Hand anzulegen. Auch bei einer Outsourcing-Lösung kann es nicht schaden, sich zuvor mit der Materie vertraut zu machen.
Seit der Version 0.5.0 gehört zu SSLeay ein Programm namens ca, das die Grundfunktionen einer Zertifikatsmanagementsoftware - Anzeige und Signierung von Zertifikaten - besser als das (weiterhin vorhandene) x509-Programm erfüllt. ca unterstützt den Einsatz von Konfigurationsdateien (siehe SSLeay und die Konfiguration), wodurch Kommandozeilen mit einer ständig wachsenden Anzahl von zehn oder mehr sich stets wiederholender Parameter entfallen. Das Programm liest eine Zertifikatsanforderung ein, überprüft deren formale Richtigkeit (zum Beispiel die korrekte digitale Signatur des Anfordernden), die Übereinstimmung mit den Richtlinien für die Beglaubigung dieser Zertifikatsklasse (Policy) sowie die Einmaligkeit der Anforderung. Nach erfolgreichem Abschluß aller Prüfungen erfolgt die Signierung des neuen Zertifikats. Weiterhin kann ca Rücknahmelisten mit den Seriennummern ungültiger Zertifikate erstellen. Allerdings unterstreicht Autor Eric Young stets den Demonstrationscharakter des Programms und weist darauf hin, daß beispielsweise die Rücknahme eines Zertifikates nicht zum Funktionsumfang gehöre, sondern daß Scripts dies erledigen müssen.
Da die Vielzahl der benötigten Optionen (siehe Undokumentiert: Variablen und Parameter von ca), das notwendige Vorhandensein bestimmter Dateien und Verzeichnisse sowie der Mangel an Dokumentation den Anwenderkreis auf eine kleine Gruppe von Enthusiasten - Leute, die statt eines Buches lieber einen guten Quelltext lesen - einschränken würde, enthält die SSL-Distribution einen Wrapper in Form des Shell-Scripts CA.sh. Damit sind zumindest die Basisfunktionen einer Beglaubigungsstelle (Initialisieren sowie Erstellen von neuen Anforderungen, Zertifikaten und Sperrlisten) - unter Beibehaltung von Standardwerten - nachvollziehbar. Ein anderer Ansatz ist das Verpacken der Funktionen in eine grafische Oberfläche (zum Beispiel http://www.easterngraphics.com/certs/tkca).
Die in diesem Artikel anhand von Beispielen vorgestellte Vorgehensweise ähnelt der von CA.sh. Listing 1 zeigt ein Shell-Script, das als Parameter den (Kurz-)Namen der Beglaubigungsstelle erwartet und die für eine Konfiguration nach Listing 2 notwendigen Verzeichnisse und Dateien erzeugt. Die Verzeichnisse für die Beglaubigungstellen werden unterhalb von /usr/local/CA angelegt. Anschließend erzeugt req das Zertifikat der Certification Authority (CA). Als Konfigurationsdatei dient dabei ssleayRq.cnf (die kompletten Listings sind wie üblich über den Listingsservice erhältlich, außerdem siehe Quellen), das den Batchmodus des Programms nutzt und alle Werte bis auf den allgemeinen Namen (Common Name, hier für den Namen der Beglaubigungsstelle verwendet) vorgibt. Nötige Angaben des Benutzers sind ServerCA und ClientCA.
Zur Verifizierung eines Serverzertifikats muß das Zertifikat der Server-CA den Browsern mitgeteilt werden. Wie in Kasten Nachladen beschrieben, stellt ein WWW-Server DER-kodierte Zertifikate mit dem MIME-Type application/x-x509-ca-cert zum Download bereit. Die notwendige Konvertierung hat das x509-Programm in Listing 1 bereits vorgenommen. Um das Zertifikat mit dem benötigten MIME-Type zu verschicken, gibt es zwei Möglichkeiten. Zum einen läßt sich eine bestimmte Dateierweiterung per Web-Server fest mit einem MIME-Type verbinden. Bei Apache erledigt das folgender Eintrag in der Datei srm.conf:
AddType application/x-x509-ca-cert .der
Nachteil hierbei ist, daß die Dateierweiterung .der nicht nur auf Zertifikate der Server-CA, sondern auch auf Server- oder Clientzertifikate zutreffen könnte. Deshalb übernimmt diese Aufgabe alternativ das CGI-Programm aus Listing 3. Wichtig ist dabei das Voranstellen eines definierten Wurzelverzeichnisses in Kombination mit der relativen Pfadinformation aus PATH_INFO. Entnähme man - wie es häufig geschieht - den Namen der Datei, die das Zertifikat enthält, der Variable QUERY_STRING, könnten Böswillige dieses Script dazu mißbrauchen, aus dem Rootverzeichnis des Web-Servers auszubrechen und beliebige Dateien vom Host zu laden.
Nun sind die Beglaubigungsstellen einsatzbereit und warten auf die ersten Zertifikatsanforderungen, die zunftgemäß per WWW erfolgen sollen. Zuvor jedoch eine deutliche Warnung: Die hier vorgestellte Lösung hat lediglich Modellcharakter. Zwar kann sie aus funktioneller Sicht durchaus als Bescheinigungsstelle gelten, für einen sinnvollen Einsatz in der Praxis wäre allerdings noch erheblich mehr zu tun. So findet etwa außer einem formalen Check der Request-Signatur keinerlei Überprüfung statt, ob Angaben wie die Zugehörigkeit zu einer bestimmten Verwaltungseinheit stimmen.
Auch ist die offene Aufbewahrung des wertvollen privaten Schlüssels der Beglaubigungsstelle auf einem öffentlich zugänglichen Web-Server abzulehnen. Da spielt es keine Rolle, ob der Key gänzlich unverschlüsselt oder nur das notwendige Paßwort in einem CGI-Script zu finden ist. Für eine ernsthafte Beglaubigungsstelle gelten da andere Maßstäbe (siehe Artikel Herrschende Richtlinien).
Als erstes zur Server-CA, da sich diese etwas einfacher realisieren läßt. Dazu bedarf es zunächst eines schlichten Formulars (siehe Listingsservice), das den zuvor vom Webadmin erstellten Request im PKCS#10-Format per Copy&Paste entgegennimmt und ihn an den Server postet. Für die Erstellung des Request liegen dem Server Werkzeuge bei, beim Apache-SSL ist es das req-Programm. Der Server bearbeitet die Anforderung mit Hilfe eines weiteren Scripts (siehe Listing 4). Läuft die Erstellung des Zertifikats fehlerfrei ab, wird es zurück an den Browser geschickt (und hoffentlich gespeichert), ansonsten verzweigt das Script auf eine Fehlerseite.
Zuerst nimmt postit2 die URL-Dekodierung der Daten vor. postit2 ist eine vom Autor vorgenommene Erweiterung des postit-Programms der NCSA-Utilities für das Common Gateway Interface (siehe Quellen). Es dekodiert die mit der POST-Methode an den Server gesendeten Daten und gibt diese zeilenweise als Name-Value-Paare aus. Der Separator ist über die Option -s veränderbar. Standardmäßig sind Leerzeichen eingestellt.
Anschließend entfernt der Stream-Editor sed Namen und Separator. Übrig bleibt die eigentliche Zertifikatsanforderung, die das ca-Programm bearbeitet. Ausgaben von stderr - neben möglichen Fehlermeldungen Angaben zum Ablauf des Zertifizierungsprozesses - landen in server.log. Die Abfrage des Exit-Codes ermöglicht eine einfache Fehlererkennung. Zwar ist keine feingranulare Diagnose möglich (ca kennt nur die Exit-Codes 0 und 1), aber für eine kleine Fehlermeldung an den Nutzer reicht es allemal. Das Zertifikat kann nach dem Speichern sofort in die Konfiguration des Secure-Servers eingetragen und zu seiner Authentifizierung benutzt werden.
Weiter gehts mit den Clientzertifikaten. Leider läßt sich hier nur das Vorgehen für den Netscape Navigator zeigen. Microsoft scheint nicht bereit zu sein, die notwendigen Informationen komplett zur Verfügung zu stellen, wenn man nicht zu den Oberen X (X <<<10, <<< steht für vermutlich deutlich kleiner als) im Geschäft gehört (siehe Nachladen von Zertifikaten).
Eine Anforderung erstellt der Navigator im SPKAC-Format (Signed Public Key and Challenge). Da dieses keinerlei Angaben zum Namen enthält, muß der Browser die Werte der Namenskomponenten anderweitig übermitteln. Die einfachste Lösung ist die Übertragung im selben Formular. Verwendet man das über den Listingsservice erhältiche Script ns-enroll.html, erscheint beim Abschicken im Browser ein Fenster, das auf den Vorgang der Schlüsselgenerierung hinweist. Achtung: den Schlüssel generiert der Navigator nur beim ersten Senden! Falls der Nutzer lediglich die Namensangaben ändert und er das Formular erneut mit dem alten Schlüssel abschickt, kann der Navigator das neue Zertifikat nicht mehr zuordnen, da der dazugehörige private Schlüssel schon vergeben ist. Die Anforderung eines neuen Zertifikats erfordert daher ein Reload des Formulars.
Listing 5 bearbeitet den Request. Zunächst nimmt auch hier postit2 die URL-Dekodierung der Parameter vor und entfernt dabei aufgrund der Option -i (ignore) gleichzeitig die Zeilenwechsel im Wert des SPKAC-Attributs. Anschließend löscht sed Zeilen mit Attributen ohne Wert, die entstehen, wenn ein Eingabefeld im Formular freibleibt. Geschähe dies nicht, enthielte das Zertifikat Namenskomponenten mit dem Wert eines leeren Strings.
Die so enstandene Datei besitzt verblüffende Ähnlichkeit mit einer Konfigurationsdatei. Das ist auch beabsichtigt, denn das Laden eines Request im SPKAC-Format erfolgt mit den gleichen Routinen wie eine Konfiguration. Damit ist die maximale Zeilenlänge, die SSLeay in crypto/conf/conf.c definiert, auf 512 Zeichen begrenzt. Längere Zeilen liest ca (wohl aufgrund eines Bugs) nicht sauber ein. Also ist entweder die Konstante BUFSIZE heraufzusetzen, die SSLeay-Quellen sind zu ändern oder ein Backslash als Escape-Zeichen müßte die Zeilen des Attributwertes verbinden. Solange allerdings die Länge des CHALLENGE-Attributs kleiner als etwa 200 Zeichen ist (eine vernünftige Annahme), gibt es keine Probleme.
Im Erfolgsfall schickt das Script das fertige Zertifikat mit dem korrekten MIME-Type versehen an den Browser zurück. Treten Probleme auf, bekommt der Nutzer eine Fehlermeldung.
An diesem Punkt stellt sich die Frage nach dem How-to der Benutzung von Client-Authentication. Jeder Server besitzt seine eigene Vorgehensweise für die Aktivierung der Authentifizierung und die Ableitung entsprechender Zugriffsrechte. Als Beispiel soll der aus [[#literatur 2]] bekannte freie Apache-SSL-Server dienen. Die aktuelle Version heißt apache_1.1.1+1.3.ssl. Der Patch läuft mit Apache 1.1.3 und SSLeay 0.6.6 - vorausgesetzt, man verpaßt in apache_ssl.c allen Vorkommen von mit SSL_TXT beginnenden Konstanten das neue Präfix SSL2_TXT. Eine entsprechende Befehlszeile könnte so aussehen:
mv apache_ssl.c apache_ssl.c.orig && sed \ s/SSL_TXT/SSL2_TXT/<apache_ssl.c.orig>\ apache_ssl.c
Vor dem Kompilieren sind im Makefile für das Target certificate die Pfade zu SSLeay richtig zu setzen - es sei denn, man benutzt zum Erstellen des Zertifikats gleich die soeben aufgebaute Online-Server-CA. Die Konfiguration der normalen Umgebung wie Log-Dateien oder Verzeichnisse mit CGI-Dateien erfolgt zunächst wie gewohnt. Erst danach sind ein paar SSL-spezifische Optionen gefordert.
Mit der vorliegenden Version ist es endlich möglich, SSL- und Nicht-SSL-Server gleichzeitig mit einer Konfiguration laufen zu lassen. Dazu bedarf es allerdings eines kleinen Tricks (siehe Listing 6). Statt des Portschlüsselworts legt die Listendirektive die Ports fest, auf denen der Server arbeiten soll (gewöhnlich die Ports 80 für http und 443 für https). Für die Konfiguration der entstehenden virtuellen Server gibt es separate Virtual-Host-Sektionen. Die Konfiguration des Hauptservers selbst wäre zwar prinzipiell überflüssig, aber der SSL-Patch arbeitet ein wenig unsauber. Die Konfiguration des Hauptservers muß der eines SSL-Servers entsprechen. Beim Start erzeugt er die etwas verwirrende Ausgabe Reading certificate und key for server hostname:443, die man aber getrost ignorieren kann. Die minimal notwendige Menge von SSL-Direktiven geht aus Listing 6 hervor (der Listingsservice enthält eine ausführlichere mit deutschen Kommentaren).
Wichtig sind insbesondere SSLCertificateFile (enthält das Zertifikat und eventuell den privaten Schlüssel) sowie gegebenenfalls SSLCertificateKeyFile. Als äußerst ungünstig erweist sich hier ein Paßwortschutz des Schlüssels, der einen automatischen Reboot praktisch unmöglich macht: der Apache-Server verlangt nach einem Paßwort und verweigert bis zu dessen Eingabe jegliche Arbeit. Ohne die Verschlüsselung gewährleistet der sorgfältige Schutz des privaten Schlüssels durch entsprechende Dateizugriffsrechte eine gewisse Sicherheit. Andere Lösungen hören sich oft etwas abenteuerlich an. Zum Beispiel eine Realisierung, bei der ein speziell gesicherter Rechner innerhalb einer definierten Zeitspanne nach dem Boot-Beginn des Serverrechners den Schlüssel über eine direkt angeschlossene serielle Leitung freigibt...
Die Verwendung von Clientzertifikaten erfordert zusätzlich die Direktiven SSLVerifyClient sowie gegebenenfalls SSLVerifyDepth und SSLCACertificatePath beziehungsweise SSLCACertificateFile. Die beiden letztgenannten sorgen dafür, daß der Server die Zertifikate der ausgebenden Stellen finden kann - eine Vorausetzung für die Gültigkeitsprüfung einer Signatur. SSLVerifyDepth gibt an, wie lang die Kette vom vorgelegten bis zum Zertifikat der Beglaubigungsstelle sein darf. Letzteres zeichnet sich durch die Signatur mit dem privaten Schlüssel aus. Alle Glieder der Kette müssen vorhanden sein, also als Zertifikat vorliegen. Fehlt diese Option, gilt eine Tiefe von zehn. Bei Verwendung von SSLCACertificatePath - diese Methode, jedes Zertifikat in einer eigenen Datei zu speichern, ist der Standard bei SSLeay - darf der eigenartig erscheinende Link (ln -s [...] `x509 -hash [...]`.0) nicht vergessen werden. Denn dieser führt ohne erschöpfendes Durchsuchen aller Dateien schnell zum Besitzer eines Zertifikats.
SSLVerifyClient kann zwei nutzbare Werte annehmen. 0 erfordert kein Zertifikat, bei 2 muß ein gültiges vorhanden sein. Den Wert 1 (Client kann, muß aber kein Zertifikat vorweisen) haben die Browser durch ihre Art der Handhabung nutzlos gemacht. Besitzt der Navigator ein falsches, das heißt nicht akzeptiertes Zertifikat, kann der Nutzer dessen Verschicken nur mit Cancel stoppen - und damit die gesamte Übertragung. Besitzt der Navigator kein Zertifikat, wirft er gleich das Handtuch. So recht funktionieren will es ohnehin nur, wenn die automatische Selektion der zu verwendenden Zertifikate ausgeschaltet ist, sonst bleibt die Verbindung trotz sauberen SSL-Handshakes (Verhandlungen vor Übertragung von Nutzdaten) hängen. Laut Jeff Weinstein, dem Chef-Kryptoentwickler von Netscape, sind es bekannte Probleme, die auf die fehlende offizielle Unterstützung von Clientzertifikaten bei der SSL-2.0-Implementierung zurückzuführen seien. Ach wenn doch SSLeay nur schon SSL 3.0 beherrschen würde...
Noch niederschmetternder sind die Ergebnisse bei Verwendung des Internet Explorer. Dieser Browser beendet den SSL-Handshake offenbar gar nicht, wenn ein Zertifikat gefordert ist. Bleibt als vielsagende Fehlermeldung: Die Serververbindung konnte nicht hergestellt werden. Nicht mal das gute Verisign-Zertifikat kommt durch. Ist aber nicht so schlimm, da der Explorer ja ohnehin keine Zertifikate von uns haben wollte. Wie schön so etwas prinzipiell laufen kann, zeigt SSLeay selbst: s_client -host localhost -port 8446 baut problemlos eine Verbindung auf.
Richtig interessant wirds mit der Option SSLFakeBasicAuth. Damit kann der Webadmin endlich auf Grundlage der im Zertifikat verankerten Identität Zugriffsrechte feinerer Granularität vergeben. Bislang konnte ein Zertifikatsbesitzer auf den gesamten Site zugreifen. Die Idee von Ben Laurie als Autor des Patches ist recht pfiffig und ermöglicht dem eingefuchsten Administrator die einfache Anwendung. Gleichzeitig hat er damit aber auch eine gewisse Inflexibilität fortgeschrieben.
Die Funktionsweise ist recht einfach: wenn SSLFakeBasicAuth aktiviert und ein gültiges Zertifkat akzeptiert ist, fügt das SSL-Modul in die interne Tabelle mit den erkannten (aber noch nicht verarbeiteten) Header-Zeilen eine weitere für die Authentifizierung nach dem Basic-Authentication-Schema ein. Als Nutzername dient der Name des Zertifikatsbesitzers, als Paßwort der String password. Das verdeutlicht, warum das SSL-Modul in der Konfigurationsliste ganz unten stehen und somit als erstes aktiviert werden soll: Das Erzeugen der Header-Zeile muß eben vor der Abfrage durch das BasicAuth-Modul geschehen.
Zur weiteren Konfiguration ergänzt der Webadmin die entsprechende Paßwortdatei um den neuen Benutzer. Dessen Namen gibt das x509-Programm mit der Option -subject preis, die Darstellung des Strings password kann verschlüsselt beispielsweise als xxj31ZMTZzkVA erfolgen. Für den Eintrag benutzt man entweder htpasswd oder hängt ihn einfach hinten an:
echo "x509 -noout -subject -in \ certfile":¥xj31ZMTZzkVA>>user_file
Kann der Surfer kein gültiges Zertifikat vorweisen, muß er sich auf herkömmliche Weise mit Nutzernamen und Paßwort anmelden. Zumindest im Prinzip. Eine nach Meinung des Autors inkonsequente Vorgehensweise verhindet dies: SSLFakeBasicAuth überschreibt einen vorhandenen Authorization-Header gnadenlos mit dem zuvor schon nicht akzeptierten Nutzernamen aus dem Zertifikat und eine neue Runde beginnt mit der Eingabe von Name und Paßwort.
Abhilfe ist simpel: vor dem Eintragen des Authorization-Header muß eine Überprüfung stehen, ob der tatsächliche Header aus dem HTTP-Request vorhanden ist (siehe Patch im Listingsservice). Zur Verdeutlichung des Effekts verlangt die Beispielkonfiguration in [listings.html Listing 6] auf Port 8446 eine Authentifizierung mittels Basic Authentication Scheme und ein noch nicht abgelaufenes Zertifikat. Die Nutzerdatei enthält zwei Einträge für den Namen test und einen Zertifikatsinhaber. Wird beim ersten Zugriff das richtige Zertifikat gewählt, bemerkt der Nutzer die geforderte Authentifizierung nicht. Bei einem neuen Versuch mit dem falschen Zertifikat jedoch muß er sich wie gewohnt mit seinem Nutzernamen anmelden (und danach erneut das Zertifikat auswählen).
Was bleibt zu tun? Eigentlich fast alles, angefangen von der Interpretation der rechtlichen Gegebenheiten über das Erstellen einer Policy und deren Durchsetzung bis hin zum Überprüfen der Angaben in der Zertifikatsanforderung. Darüber hinaus muß man sich um die Verbreitung der entsprechenden CA-Zertifikate und deren Akzeptanz kümmern. Für den Einsatz im Internet ist sicher die Inanspruchnahme der Dienste einer etablierten Beglaubigungsstelle kostengünstiger. Für Inhouse-Lösungen bietet das Vorliegen der kompletten Quelltexte grenzenlose Flexibilität und eine Menge Anregungen.
HOLGER REIF
ist wissenschaftlicher Mitarbeiter an der TU Ilmenau. Im Fachgebiet Telematik bearbeitet er die Schwerpunkte Netzdienste, Sicherheit und elektronische Zahlungssysteme.
Literatur
[1] Markus Breilmann; Sicherheit; Schlüsselpostition; Authentifizierung in offenen Netzen; iX 10/96, S. 102 ff.
[2] Holger Reif; Netzsicherheit; Schlüsselfertig; Secure Socket Layer: Verschlüsseln und Zertifizieren mit SSLeay; iX 6/96, S. 128 ff.
[3] Netscape; Netscape Certificate Specifications
[4] Microsoft; Client Authentication (www.microsoft.com/intdev/security/misf3.htm)
[5] Verisign; Web Site Client Authentication (www.verisign.com/repository/clientauth/clientauth.htm) Using Digital Ids
| iX-TRACT |
|
Dieser Text ist der Zeitschriften-Ausgabe 04/1997 von iX entnommen.
iOS, Android, Windows Phone 7 und HTML5 - das neue Sonderheft von heise Developer führt Einsteiger und Profis in die Programmierung mobiler Geräte ein.
