Seitdem das Stichwort Prism durch die Medien geistert, wird verstärkt über das Thema verschlüsselte Kommunkation berichtet und diskutiert. Dabei wird in der Berichterstattung häufig von PGP gesprochen. Doch was genau ist PGP und was kann es für euch tun?

PGP ist eine Abkürzung und steht für den Ausdruck “Pretty Good Privacy”. PGP selbst ist allerdings keine Verschlüsselung, sondern erstmal eine Anwendung zur Erstellung von öffentlichen und privaten Schlüsseln und digitalen Signaturen. PGP greift dafür auf verschiedene Verschlüsselungstechniken (Algorithmen) zurück. Diese sind meinem Kenntnisstand nach alle bekannt und wurden in der Vergangenheit bereits auf Schwachstellen untersucht.

An dieser Stelle sei angemerkt, daß die Sicherheit eines Algorithmus nicht dauerhaft ist. Die Einstufung eines Algorithmus kann schnell von sicher auf unsicher wechseln, wenn es effiziente Verfahren gibt, diesen zu “knacken”, oder, noch einfacher, die Rechenleistung verfügbarer Hardware stark genug zunimmt.

PGP ist für Privatpersonen ersteinmal frei verfügbar, kommerzielle Versionen gibt es für den Einsatz in Unternehmen.

Was genau könnt ihr nun mit PGP anstellen? Erstmal könnt ihr damit private und öffentliche Schlüsselzertifiate erzeugen. Damit könnt ihr Emailkommunikation verschlüsseln, eure Emails digital signieren oder auch Dateien verschlüsseln.

Auch wenn für die sichere Emailkommunikation zwei unterschiedliche Schlüssel verwendet werden (öffentlicher und privater Schlüssel, eine sog. asymmetrische Verschlüsselung), werden die Nachrichten selbst symmetrisch verschlüsselt, d.h. Verschlüsselung und Entschlüsselung nutzen den selben Schlüssel. Der Vorteil in einer symmetrischen Verschlüsselung liegt dabei in deutlich höherer Performanz, als bei asymetrischen Verfahren.

Warum aber gibt es dann zwei Schlüssel, die für PGP relevant sind? Ganz einfach. PGP arbeitet sowohl mit symmetrischer, als auch mit asymetrischer Verschlüsselung. Für die Nachrichten wird eine symmetrische Verschlüsselung benutzt. Diese hat erstmal nichts mit euren Schlüsseldateien zu tun. Vielmehr berechnet PGP für eure Nachricht einen sog. Session-Key (Einmal- oder Wegwerfschlüssel). Einfach gesprochen nimmt PGP eure Nachricht und komprimiert sie. Dann wird sie mit dem Einmalschlüssel verschlüsselt. Soweit so gut. Nun braucht man den Einmalschlüssel aber noch zum entschlüsseln. Da ihr den nicht kennt (und zu kennen braucht), kommen nun eure Schlüsseldateien zur Anwendung. PGP schnappt sich also den öffentlichen Schlüssel des Empängers (euren, wenn die Mail an euch geht) und verschlüsselt damit den Einmalschlüssel. Damit er nicht verloren geht, wird dieser mit der Nachricht verbunden und diese dann versendet.

Auf Empfängerseite läuft dieser Prozess dann genau umgekehrt ab. Allerdings kann der Einmalschlüssel nur mit dem privaten Schlüssel des Empfängers entschlüsset werden. Erst wenn das gemacht wurde, kann PGP die Nachricht selbst entschlüsseln und dekomprimieren, damit man sie am Ende lesen kann.

Klingt kompliziert, ist es aber eigentlich nicht. Wenn ihr erstmal eure PGP Schlüssel erstellt habt, könnt ihr euren privaten Schlüssel direkt in eurem Emailprogramme hinterlegen, sofern dieses PGP unterstützt. Anschliessend müsst ihr euren Kommunikationspartnern euren öffentlichen Schlüssel mitteilen, damit diese ihre Emails an euch entsprechend verschlüsseln kann. Die zur Entschlüsselung auf eurer Seite müsst ihr normalerweise nur euren Schlüssel “entsperren”, dazu gebt ihr euer Passwort, daß bei der Schlüsselerstellung festgelegt hab ein (sog. “Mantra”).

Da ihr mit eurem privaten Schlüssel auch Nachrichten digital signieren könnt, bietet es sich an, euren öffentlichen Schlüssel in eine der öffentlichen Datenbanken einzutragen. Dann kann die Signatur direkt geprüft werden.

Die Funktionsweise der digitalen Signatur mit PGP ist dabei deutlich weniger komplex als die Verschlüsselung:

1. Aus der Nachricht wird eine Hashwert (Prüfsumme) berechnet
2. Hashwert wird mit dem privaten Schlüssel verschlüsselt
3. verschlüsselter Hashwert wird an die Nachricht angehängt

Zur Prüfung der Signatur kann der Hashwert mit eurem öffentlichen Schlüssel entschlüsselt und dann mit dem Hashwert der erhaltenen Nachricht verglichen werden.

Natürlich kann die Nachricht erst signiert und anschliessend noch verschlüsselt werden.

Es existieren noch ähnliche Verfahren auf dem Markt, z.B. openPGP, das unter Linux mit GnuPG genutzt werden kann.

Ob man Emails nun verschlüsseln muss, oder nicht, muss der Nutzer entscheiden. Ich für meinen Teil nutze verschlüsselte Emails kaum, bin aber ein großer Freund der digitalen Signatur. Ich habe hier bewusst auf eine Anleitung zur Erstellung der Schlüsseldateien und der Nutzung mit einem Emailprogramm verzichtet. Dazu gibt es in der Zwischenzeit mehr als genug Anleitungen im Netz ;).

Die wenigsten Nutzer werden den Unterschied zwischen den genannten Techniken wirklich bemerken. Daher ist es umso wichtiger, sich nochmal vor Augenn zu führen, worin die Unterschiede jetzt wirklich bestehen und welche Art der Präsentation für welchen Zweck am geeignetesten erscheint.

Fangen wir “unten” an. Die einfachste Form der Aufbereitung von Inhalten für mobile Endgeräte ist das responsive Design. Hierbei wird via CSS klar definiert, wie sich eine Webseite auf unterschiedlichen Ausgabemedien mit verscheidenen Auflösungen verhält. Der Vorteil hierbei liegt auf der Hand. Der Ersteller kommt erstmal mit HTML und CSS zurecht und kann auch ohne weitergehende Techniken schnell ansprechende Ergebnisse umsetzen.

Einschränkungen liegen insbesondere in der Verteilbarkeeit der Anwendungen. Webseiten können in den seltensten Fällen über einem Appstore verteilt werden. Der Autor ist daraf angewiesen, daß der Nutzer seinen Weg auf die Webseite findet. Man kann aber nicht von der großen Nutzerbasis des Appstores profitieren. Ausserdem kommen responsive Designs schnell an Ihre Grenzen, wenn die ursprüngliche Webseite eine recht komplexe (Navigations-)Struktur hat. So steigt bei besonders komplexen Gebilden der Aufwand für eine sinnvolle Anpassung der CSS Daten auf ein nicht mehr wirtschaftliches Niveau an. Spätestens dann ist zu überlegen, ob es nicht sinniger ist, auf andere Lösungen auszuweichen.

Einen Schritt weiter geht die Web-App. auch hierbei handelt es sich erstmal um HTML und CSS. Oft beobachtet man den Einsatz spezieller Frameworks, z.B. jQuery Mobile, um die Optik, als auch die Handhabung der eigenen Seite an gängige Mobilgerätestandards anzupassen. Hierbei ist dann aber zu beachten, daß das HTML-Markup im direkten Vergleich zu einer responsive Webseite u.U. angepasst werden muss. jQuery Mobile nutzt z.B. eigene Attribute für HTML Elmente um diverse Funktionen bereitzustellen. Ausserdem bringt es eigenes Caching mit, was einige Einschränkungen bei der Umsetzung des HTML Quellcodes bedingt. Grundsätzlich eigenen sich Web-Apps aber schon sehr gut, um eine eigene Anwendung mit möglichst einfachen Mitteln auf die Geräte der Nutzer zu bringen. Sie lassen sich z.B. mit einem eigenen Icon auf den Startbildschirm legen und integrieren sich somit schon recht gut in mpbile Systeme. Allerdings fehlt auch hier die Möglichkeit die Anwendung über einen Appstore zu verteilen. Dafür können die Web-Apps aber problemfrei auf der technischen Infrastruktur bestehender Webseiten bzw. Onlineapplikationen aufsetzen und hier die Nutzbarkeit sinnvoll auf mobile Geräte übertragen. Auch für eine Erweiterung einer bestehenden, großen Seite mag die Web-App der richtige Ansatz sein. Sie ermöglicht eine saubere Trennung zwischen mobiler Inhalte und der eigentlichen Webseite. Dadurch lassen sich ggf. die reinen Inhaltsmengen auf ein übersichtlicheres Maß reduzieren.

Man muß aber ganz klar sagen, daß der Einstieg etwas aufwendiger ist, als bei einer reinen responsive Webseite. So ist es erforderlich die Dokumentation des verwendeten Frameworks zu konsultieren und ggf. das Markup des Quelltextes zu modifizieren. Je nach eingesetztem System können dann noch weitere Arbeiten dazukommen, immerhin muss beispielsweise ein CMS wissen, welches Markp ausgegeben werden soll, d.h. es muss vom System erkannt werden, welches Gerät der Nutzer verwendet. Nicht zu vergessen sind evtl. Bugs in den verwendeten Frameworks, die euch einige graue Haare bereiten können.

Letzer Evolutionsschritt an dieser stelle wären die Nativen Apps. Diese bieten einige Vorteile, da sich im Normalfall direkt für das jeweilige Zielsystem entwickelt oder zumindest darauf abgestimmt werden. Das bietet, neben der Vermarktbarkeit über den jeweiligen Appstore, Vorteile bei der Performanz und ggf. bei Anbindung an weitere Systemapplikationen, da die native App ja direkt auf dem System installiert wird und damit nicht den den strengen Einschränkungen browserbasierter Applikationen unterliegt. Der Einstieg in die native App-Programmierung ist aber dann nochmal einen Tacken aufwendiger als bei den Web-Apps. je nachdem, welche Programmiersprache eingesetzt wird (Java, C#, etc…), von HTML/XML-basierten Frameworks, bei denen dann ggf. noch eine Konvertierung mit externen Werkzeugen, wie z.B. PhoneGap, notwendig ist. Klar im Vorteil sind native Apps in jedem Fall bei Anwendungen mit hohen Hardwareanforderungen, z.B. Spiele, da diese bsp. direkt von hardwarebeschleunigter Grafik profitieren können.

Lässt sich also abschliessend sagen, welches Vorgehen das Beste ist? Nein. Für jedes Anwendungsszenario gibt es eine passende Lösung. Das hängt dann, wie so oft, vom Einsatzzweck und nicht zuletzt vom zur Verfügung stehenden Entwicklungsbudget ab.

Ein auf den ersten Blick nicht Web-verwandtes Thema. Doch hat die letzte Black Hat gezeigt, daß die Integration “des Internets” in Kraftfahrzeugen ein sehr interessantes Thema ist. Aber auch die Hausautomation steht dem in nichts nach, wenn man sich ein wenig mit dem Thema beschäftigt.

Prinzipiell ist das Ziel der Hausautomation ersteinmal einen Mehrwert für den Hausbesitzer zu schaffen. Dieser besteht ersteinmal in einem Zugewinn an Komfort. Sicherlich ist es bequemer einen Knopf zu drücken um einen Rolladen zu schliessen, als diesen Vorgang manuell durchzuführen. Die neueste Generation der Haussteuerungen geht aber noch einen Schritt weiter. So reicht es nun nicht mehr, die Komfortfunktionen über im Haus verteilte Steuereinheiten zu bedienen, sondern müssen diese nun auch von ausserhalb, also direkt über das Internet steuerbar sein.

Die Idee mag ja ganz nett sein, aber jedem Nutzer sollte genau an diesem Punkt klar sein, daß Geräte, die über das Internet erreichbar sind auch potentiell angreifbar sind. Man möge zwar argumentieren, daß es für einen “Hacker” ja kaum interessant sein dürfte bei mir zuhause das Licht ein- oder auszuschalten, aber dem möchte ich hier direkt wiedersprechen. Im Gegenteil bieten sich hier einige Bedrohungszenarien, die für einen Angreifer potentiell interessant sein könnten.

Stellt euch mal vor, euere neue Haustechnik läuft Amok. Rolläden schliessen und öffnen, die Heizung dreht im Hochsommer richtig auf, eure Türen öffnen von allein zu den unmöglichsten Uhrzeiten. Übertrieben? Ich denke nicht. Dieses Verhalten würde euch langfristig in den Wahnsinn treiben. Der Angreifer kann sich nun zurücklehnen und warten, bis ihr weichgekocht seit. Dann stellt er seine Forderungen. Freigabe der Haustechnik durch Zahlung eines bestimmten Betrages. Bumm. Erwischt.

Wenn ihr jetzt meint, man könnte das System doch einfach vom Netz trennen oder abschalten, so wird ein cleverer Angreifer dies vorausgesehen haben und entsprechende Sicherungsmaßnahmen ergriffen haben. Ein Ausbau kommt in den meißten Fällen wohl auch kaum infrage, wenn die Komponenten bereits tief in eurer Haustechnik integriert sind.

Was also tun? Einerseits könnte man bewusst auf diese ganzen Spielereien verzichten. Wir haben auch vor kurzem neu gebaut und uns bewusst gegen diesen Schnick-schnack entschieden. Nicht nur das Gefahrenpotentiial war hier ausschlaggebend, sondern auch die Kosten. Steuerungssysteme sind in der Anschaffung immer deutlich teurer als manuelle Komponenten, aber, wchtiger noch, man findet wenig Informationen darüber, wie hoch der Stromverbrauch dieser ganzen elektrischen Helferlein ist. Ausserdem müssen mögliche Ersatzteilkosten bei Defekten ebenso in Betracht gezogen werden, wie Notlaufeigenschaften bei Stromausfall. Was nutzen mir elektrische Rollläden, wenn ich sie nicht ohne weiteres benutzen kann, wenn der Strom weg ist?

Ihr müsst bei derartigen Systemen immer abwägen, ob ihr diese wirklich braucht, oder einfach nur haben wollt, und wenn das der Fall ist, welchen Preis ihr bereit seid zuhlen.
Aber selsbst, wenn ihr bewusst auf derartige Systeme verzichtet, wird man wohl langfristig nicht ganz ohne auskommen. Immer mehr Haushaltsgeräte vom Kühlschrank über die Waschmaschine zum Fernseher sind bereits internetfähig, wbei hier zumindest noch die Option besteht die Geräte ohne Netzzugang zu betreiben. Wer aber nun ein wenig zurückdenkt, der wird sich direkt ins Gedächtnis rufen, daß gerade diese Geräte Teil der Informationskette zur Einführung von IPv6 waren (Internet der Dinge). Dort wurde die Öffentlichkeit informiert, daß der Adressraum bei immer mehr internetfähigen Geräten knapp wird. Überlegt man aber mal logisch, ist diese Argumentation ersteinmal nicht 100% schlüssig, denn wo werden Haushaltsgeräte in der Regel betrieben? Richtig, zuhause. Dort hat man in der Regel einen Internetzugang und ein nachgeschaltetes privates Netz(werk). Ins Internet gibt es exakt eine Leitung, alle Geräte im privaten Netz teilen sich diese und nutzen somit für die Anbindung ins Internet exakt eine IP Adresse. Intern werden private IP Adressen genutzt, die für die Anbindung nach draussen erstmal keine Relevanz haben. Einen Sinn ergibt das erst, wenn man in Betracht zieht, daß künftige Haushaltsgeräte mit fest verbauten Mobilfunkmodulen und damit eigenem Netztzgnng verkauft werden. Dann steigt in der Tat der Bedarf an IP- Adressen an, da jedes Gerät selbst eine Verbindung ins Netz herstellt. Natürlich ist das alles super. Eure Geräte werden dann automatisch mit Softwareupdates versorgt, funktionieren besser und effizienter oder bekommen neue, tolle Funktionen. Toll, oder? Dumm, wenn man bedenkt, was noch möglich ist. Stellt euch mal vor, der Hersteller möchte oder muss seine Gewinne erhöhen. Nun könnte es ja dummerweise passieren, daß ein Update das Energiemanagement eures Gerätes durcheinander bringt, eine teure Reparatur oder eine Neuanschaffung wären die Folgt.

Wenn ihr bis hierhin noch lebt, euch also eure Spülmaschine oder der Staubsauger noch nicht umgebracht oder in den finanziellen Ruin getrieben haben, wollt ihr vielleicht doch mal euer Domizil verlassen. Interessanterweise hört es ja nicht an der Haustür auf. Es kommen ja auch immer mehr Autos nicht ohne Internetzugang aus. In der aktuellen Werbekampagne eines deutschen Herstellers wird z.B. direkt aus dem FahEs kommen ja auch immer mehr Autos nicht ohne Internetzugang aus. In der aktuellen Werbekampagne eines deutschen Herstellers wird z.B. direkt aus dem Fahzeug eine Email versendet. Das mag komfortabel sein, birgt aber meines Erachtens nach ein hohes Gefahrenpotential.

Hierbei geht es mir weniger um Eingriffe von außen. Wie auf der letzten Black Hat eindruckvoll gezeigt sind Fahrzeuge mit CAN Bus potentiell von außen angreifbar, doch sehe ich hier die Ablenkung des Fahrers als größere Gefahr. Wer heute mal in der Stadt ein wenig darauf achtet, der wird feststellen, daß erschreckend viele Fahrzeugführer bereits jetzt mit Mobiltelefonen oder Infotainmentsystemen beschäftigt sind und dementsprechend Ihre Augen NICHT dort haben, wo sie hingehören, nämlich auf der Straße. Solange der Gesetzgeber hier nicht eingreift und verbrindlich vorschreibt, daß alle nicht fahrrelvanten Funktionen während der Fahrt deaktiviert sind, bleibt das Ablenkungs- und damit auch das Gehfahrnpotential hoch.

Spannnend sind die Entwicklungen in jedem Fall und wir können davon ausgehen, daß auch die Hersteller irgendwann auf sichere Applikationen setzen. Ich würde allerdings nur eine Haussteuerung einsetzen, die ich selbst entworfen und geschrieben habe. Dann kenne ich das System wenigstens in- und auswendig ;)

Ich habe in den letzten Jahren eine Menge CM-Systeme gesehen. Typo3, Joomla, Drupal, Wordpress usw. Einige Projekte ware eigene, andere habe ich übernommen. Dabei bekommt man einen wunderbaren und gleichzeit z.T. haarsträubenden Einblick in die Arbeitsweise einiger Webtätigen. Ich kann es ja irgendwo nachvollziehen, daß manche Kollegen Ihrem Spieltrieb folgen und viele Erweiterungen ausprobieren.

Es gibt auch prinzipiell keine Einwände dagegen dies zu tun. Aber, dafür nutzt man eigene Testinstallationen der jeweiligen Systeme und kein Produktivsystem. Besonders erschreckend ist, daß sogar einige professionell auftretende Agenturen es hier nicht so genau zu nehmen. So sind mir im letzten Jahr Typo3 Installationen unter die Augen gekommen, bei denen scheinbar erstmal jede Erweiterung, die zum jeweiligen Zeitpunkt verfügbar war, installiert worde, obwohl sie im System gar nicht genutzt wird.

Warum macht man das? Gute Frage, auf die ich so allerdings auch keine Antwort habe. Ich könnte mir nur vorstellen, daß man hier aus Gründen der Vereinfachung einfach eine “Standardinstallation geschnürt hat, und diese dann in jedem Projekt verwendet hat. Dann ergibt sich aber anschliessend zwangsläufig die Frage, warum man vor Start des Livebetriebs diese überflüssigen Erweiterungen nicht entfernt hat.

Wenn ihr euch jetzt fragt, was daran so tragisch ist, und man könne die Erweiterung ja später vielleicht einmal gebrauchen, dem sei gesagt: Jede Erweiterung eines CMS bedeutet neuen Code. Jeder zusätzliche Code bedeutet einerseits mehr (unnötige) Systemlast beim Betrieb der Seite. Schlimmer noch, jede zusätzliche Codezeile kann potentiell die Sicherheit des Systems gefährden! Insbesondere, wenn System und Erweiterungen nicht regelmäßig aktualisiert werden, steigte das Risiko für unbefugte Zugriffe auf die Seite stark an. Hat man Glück, toben sich nur ein paar Skript-Kiddies auf der Seite aus und machen das Layout kaputt. Hat man Pech, und es mit einem Profi zu tun, ist auch schnell der komplette Server, auf dem die Seite liegt in Gefahr.

Insbesondere komplexere Systeme wie Typo3 oder Wordpress mit hunderten verfügbarer und im schlimmsten Fall dutzenden installieren Erweiterungen sind meiner Einschätzung nach besonders anfällig. Dummerweise gibt es, im Gegensatz zu z.B. App Stores einiger Mobiltelefonhersteller keine tiefergehenden Qualitätskontrollen oder Zugangshürden für die Repositories der CMS Erweiterungen, wobei in neueren Typo3 Versionen zumindest darauf hingewiesen wird, wenn eine Erweiterung als potentiell gefährlich eingestuft ist.

Daher mein Tip an euch: Wenn ihr ein CMS benutzt, dann installiert nur die Erweiterungen, die ihr unbedingt braucht. Verzichtet auf unnötige Spielereien und fragt euch immer, ob ihr für diesen oder jenen Einsatzzweck wirklich eine Erweiterung braucht. Viele Dinge lassen sich – ein wenig Kreativität vorausgesetzt – auch mit “Bordmitteln” erledigen, ohne dafür eine extra Erweiterung installieren oder selbst schreiben zu müssen.

Haltet eure Systeme aktuell und kümmert euch regelmäßig um Backups der Dateien und Datenbanken. Wenn ihr dasd berücksichtigt, solltet ihr eure Seiten eigentlich relativ sicher betreiben können.

Wenn ihr eine Typo3 Webseite betreibt und zusätzlich die Erweiterung Direct Mail nutzt, habt ihr euch evtl. schonmal gewünscht einen Newsletter “ausser der Reihe”, mit einem anderen Template zu versenden. Nun gibt es dazu einige Infos im Netz, aber die sind z.T. recht aufwendig.

Wichtig ist, daß ihr eure Newsletter aus Inhaltsseiten innerhalb eurer Typo3 Umgebung generiert. In diesem Fall könnt ihr nämlich eurer “Sonder”-Newsseite ein komplett neues Template zuweisen, ohne irgendwie an der Konfigration rumzubasteln.

So könnt ihr recht simpel mehrere Teplates für eure Newsletter verwenden, ohne aufwendige Anpassungen. Dazu erstellt ihr für die Seite einfach einen neuen Template-Datensatz legt hier das alternative Template ab, bzw. bindet einen zentral im System hinterlegten Datensatz ein. Fertig.