AltStore nicht installierbar; Bildschirmfoto von Natalie Kagelmacher
In der EU muss Apple ja seit nicht allzu langer Zeit das „Sideloading“ (engl. für wörtl. „Seitenladen“, bedeutet „manuelles Installieren von Software ausserhalb offizieller App-Stores“) zulassen.
Die Idee ist ganz einfach: Wer in der EU lebt, soll die Möglichkeit haben, auf iPhone und iPad, alternative App-Stores zu installieren und dann darüber Apps zu installieren. Somit wäre Apples App-Store-Monopol endlich vorbei.
Naja, zumindest in der Theorie …
Wer einen alternativen App-Store betreiben will, muss dafür von Apple abgesegnet sein, und alle Apps in diesem alternativen App-Store müssen ebenfalls von Apple abgesegnet sein (im Sinne einer Kryptographischen Signatur). Apple argumentiert hier mit dem Punkt „Sicherheit“, was ich zumindest teilweise nachvollziehen kann. Das ist ähnlich wie auf dem Mac, wo die meisten Applikationen von Apple signiert und notarisiert werden, jedoch (schon immer) ausserhalb des App-Stores bezogen werden konnten (sogar ganz ohne Apple-Absegnung).
Ob das nun gut oder schlecht ist, sei erstmal dahingestellt.
Dass Apple noch immer absegnen muss (oder will) ist ein bekannter Kritikpunkt, weshalb ich den in diesem Artikel nicht weiter vertiefen will. Vielmehr möchte ich mich auf einen anderen Aspekt fokussieren:
Ich habe das ganze mal testen wollen und ein meiner Meinung nach signifikantes Problem gefunden.
Ich habe mir für den Test ein iPhone XS aus Deutschland besorgt. Das ist eines der ältesten Modelle, auf dem das zurzeit neueste Betriebssystem von Apple (iOS 18) weiterhin unterstützt ist. Ich habe die neueste Version von iOS (18.3.1) aufgespielt und es dann für die erstmalige Einrichtung gestartet.
Eine der ersten Fragen ist nach dem Land. Ich habe Deutschland gewählt – was auch korrekt war, da ich den Test tatsächlich in Deutschland durchgeführt habe, da Apples Richtlinien erwähnen, man müsse sich auch in dem Land aufhalten.
So … ich gehe also durch alle Fragen, richte das Gerät ein – bewusst ohne Apple-Konto – und deinstalliere dann alle vorinstallierten Apps soweit möglich.
Jetzt habe ich ein deutsches iPhone, welches auf Deutschland eingestellt ist und sich in Deutschland befindet und mit einem deutschen WLAN verbunden ist. Alle Standard-Apps sind deinstalliert, bis auf:
Fotos
Kamera
App-Store
Einstellungen
Telefon
iMessage
Safari
Diese lassen sich nämlich nicht löschen.
Nun würde ich gerne Apps beziehen – da ich kein Apple Konto wünsche, geht das nicht über den offiziellen App-Store – also mache ich das, was ich als EU Bürgerin in der EU nun können sollte: Ich suche nach einem alternativen App-Store.
Ich treffe auf den bekannten AltStore – welcher sogar durch Apple abgesegnet ist und eine Version für die EU bereitstellt – also möchte ich den nun beziehen.
In der Theorie sollte ich jetzt einfach auf eine Taste „Download“ auf der offiziellen Webseite von AltStore tippen können und dann sollte ich den haben …
… geht aber nicht. Ich bekomme eine Meldung (auf Englisch), dass ich für die Installation von AltStore nicht qualifiziere: You are not eligible to install apps from «alstore.io».
Ich bekomme jedoch eine Taste für mehr Informationen, welche mich nach dem Antippen auf eine Apple-Webseite weiterleitet. Da finde ich auch heraus, was das Problem ist: Die Tatsache, dass ich EU-Bürgerin bin und das in der EU erworbene iPhone auch in der EU nutze, ist anscheinend egal, und entschieden wird ganz einfach daher, ob das Land des Apple-Kontos ein EU-Land ist.
Das Problem dahinter ist wie folgt: Mir wird weiterhin ein Apple-Konto aufgezwungen. Ohne Apple-Konto und Anmeldung im Apple App-Store kann ich auch keine alternativen App-Stores oder Apps installieren.
Die Alternative existiert also gar nicht. Apple hat weiterhin das Monopol.
Nun an meine Leser:innen: Falls Dich so etwas stört, teile diesen Artikel, um Bewusstsein zu schaffen. Ich persönlich finde, dass Apple hier definitiv noch zu weit geht.
Den Satz habt ihr bestimmt schon mal gehört, vermutlich von Prominenten: «Ich wurde gehackt».
Die Wahrheit jedoch ist, dass diese Opfer meistens nicht wirklich «gehackt» wurden – zumindest nicht im technischen Sinne – und stattdessen einfach deren Nutzername und Passwort missbraucht worden sind.
Das Stichwort ist «Credential Stuffing». Es ist ein Angriff, bei dem bekannte Nutzernamen und Passwörter eines Opfers auf allen Webseiten genutzt und missbraucht werden.
Woher kommen Nutzername und Passwort? Ganz einfach: meistens ein Datenleck bei einem Online-Dienst, auf dem ein Nutzerkonto vorhanden war, oder alternativ bei einem Phishing-Angriff, wobei das Opfer ausgetrickst wird, sich auf einer gefälschten Webseite einzuloggen, die vorgaukelt, legitim zu sein und dabei die Anmeldedaten abgreift.
Und jetzt das Problem: Wer immer den gleichen Nutzernamen (bzw. E-Mail-Adresse) und dazu das gleiche Passwort nutzt, der stellt im Grunde sicher, dass ein Angreifer überall freien Zugriff auf jedes Konto hat.
Deshalb sollte auf jeder Webseite ein anderes, zufälliges Passwort verwendet werden. Wer dann «gehackt» wird, muss nicht befürchten, dass die Anmeldedaten dann auf weiteren Webseiten missbraucht werden können. Eine weitere Massnahme für erweiterten Schutz – sofern angeboten – ist es, die Zwei-Faktor-Authentifizierung ebenfalls zu aktivieren.
Bei jeder Webseite ein anderes Passwort zu nutzen, schützt vor Missbrauch bei Datenlecks, und die Zwei-Faktor-Authentifizierung schützt – zumindest begrenzt – bei Phishing-Attacken (vor erneuter Nutzung).
Aber wie merke ich mir so viele Passwörter?
Ganz einfach: gar nicht. Das ist die Aufgabe eines Passwort-Managers. Der speichert die Passwörter verschlüsselt ab und kann auch für jede Webseite ein sicheres Passwort generieren.
Passwort-Manager gibt es heutzutage viele, aber welche sind gut? Das kommt auf die individuellen Bedürfnisse an. Wer z. B. voll und ganz im Apple-Ökosystem ist, dem empfehle ich Apple’s eingebauter Passwort-Manager, da der sicher und einfach zu bedienen ist und sich mit allen Geräten automatisch synchronisiert. Wer wiederum verschiedene Systeme nutzt, dem empfehle ich Bitwarden, da dieser Open-Source und kostenlos ist und auf verschiedenen Plattformen läuft. Zuletzt empfehle ich – erweiterten Nutzern – KeePass bzw. Programme, die das KeePass-Format nutzen wie z. B. «KeePass XC» auf verschiedenen Desktop-Systemen oder «Strongbox» spezifisch am Mac. Passt jedoch auf: Wer KeePass und Derivate nutzt, muss sich selbst um die Datenbank und deren Backups kümmern. Eine Möglichkeit wäre es, die Datenbank in der Cloud zu speichern. Wem das zu viel ist, bleibt besser bei den eingebauten Lösungen oder nutzt Bitwarden.
Es gibt auch bezahlte Lösungen, da kann ich aber keine Empfehlungen abgeben, da ich solche bis jetzt selbst nicht nutzte. Zuletzt möchte ich noch dringend von LastPass abraten, da sie über die Jahre wiederholt Sicherheitsvorfälle hatten.
Wer diesen Beitrag gelesen hat und das gleiche Passwort immer wieder verwendet, sollte ernsthaft darüber nachdenken, zu einem Passwort-Manager zu wechseln, um auf der sicheren Seite zu stehen. Der Passwort-Manager selbst sollte natürlich wiederum – im Falle einer gehosteten Lösung – auch mit Zwei-Faktor-Authentifizierung abgesichert sein.
Telegram, der Messenger Dienst, der 2013 erschien, ist inzwischen sehr populär.
Gut zehn Jahre ist es her, ich kann mich noch gut an damals erinnern. Damals, wie heute auch, warb Telegram damit ein schneller, extrem sicherer und privater Messenger zu sein. Angeblich mit starker Verschlüsselung.
Was viele nicht wissen: Die versprochene Verschlüsselung existiert nicht wirklich, oder zumindest nicht so, wie man es erwarten würde. Telegram hat nämlich technisch gesehen Zugriff auf die Nachrichten, und somit ist die Privatsphäre nicht auf technischer Basis abgesichert, sprich, es besteht keine Garantie.
Eine technische Absicherung wäre, wenn Telegram Ende-zu-Ende-Verschlüsselung nutzen würde, sodass niemand, nicht einmal Telegram, darauf Zugriff hätten. Dies ist leider nicht der Fall[1][2].
Telegram nutzt zwar sogenannte Transportverschlüsselung, aber das ist heutzutage üblich. Google und Facebook nutzen dies z. B. auch, in Form von «HTTPS» (das Schloss im Browser), und das schützt nur das Abhören der Leitung, nicht jedoch von den Betreibern selbst.
Es wird ausserdem versprochen, dass die Daten in den Datenzentren verschlüsselt sind, was zwar gut ist, aber auch nur vor lokalen Angriffen in den Datenzentren schützt. Telegram hat nach wie vor alle eure Nachrichten und Daten. Das ist der Grund weshalb ihr alle eure Geräte löschen oder gar zerstören könnt, dann auf einem neuen Gerät anmelden, und alle eure Nachrichten sind da. Es ist eben alles in der «Cloud». So nennt das sogar Telegram selbst.
Dies bedeutet: Wer Telegram nutzt, muss der Plattform einfach vertrauen. Es ist möglich, dass Telegram sich auch wirklich an die Versprechen hält und momentan alle Gespräche vertraulich behandelt werden. Das Problem natürlich dabei ist immer das gleiche bei solchen Dingen: Wir können nicht in die Zukunft schauen. Vielleicht wird Telegram eines Tages aufgekauft, oder die interne Meinung zur Privatsphäre ändert sich. Dann liegen die Daten bereits da.
Eins muss man Telegram jedoch lassen: Es hat sehr viele tolle Funktionen, die bei anderen Messengern fehlen. Da ist es für mich keine Überraschung, dass es so beliebt ist. Wobei ich anmerken muss, dass manche Funktionen halt einfach nicht oder schwer mit Privatsphäre möglich sind. Telegram kann z. B. alle Nachrichten nahtlos übersetzen, das wird erreicht in dem die Nachrichten zur Übersetzung an Google gesendet werden. Ein Messenger, der für Privatsphäre steht, kann sich so etwas nicht leisten. Dies bedeutet, dass ein alternativer Messenger, der wirklich für Privatsphäre steht, wie das inzwischen bekannte «Signal», nicht zwingend schlechter ist, weil es so etwas nicht kann, sondern weil es halt einfach nicht mit dem Ziel «Privatsphäre» vereinbar ist.
So, und jetzt abschliessend zu einem schönen 180: Ich schreibe hier ja niemandem etwas vor, und wer Telegram bereits nutzt und dies weiterhin tun möchte, dem möchte ich mitteilen, dass ich meine (sehr sporadischen) Beiträge inzwischen auch auf meinen Telegram Kanal veröffentliche.
Jetzt klinge ich vielleicht etwas heuchlerisch, und das hätte ich damals auch so gedacht. Aber heutzutage sind mir zwei Dinge klar:
Es ist einfach ein weiterer Weg, Menschen zu erreichen, eine zusätzliche Alternative zu RSS und Fedi.
Die Menschen, die Telegram auf alle Fälle meiden würden, sind vermutlich die Menschen, die auch nichts von meinen Beiträgen entnehmen können, weil sie es bereits wissen. Es ist gut, die Menschen da zu erreichen, wo es auch Sinn ergibt. 🙂
Das war es auch schon für heute! Hinterlasst gerne eure Gedanken in den Kommentaren hier, oder auf Fedi oder gar auf Telegram. 😉
[1]Zusatz: Danke an Max, der mich daran erinnert hat, dass Telegram Ende-zu-Ende-Verschlüsselung in Form von «geheimen Chats» anbietet. Das muss natürlich zur Vollständigkeit gesagt sein. Das Problem dabei ist natürlich, dass es nicht in der Standardfunktion drinnen ist. Die geheimen Chats haben reduzierte Funktionalität, darunter z. B. dass es nur mit einem Gerät auf einmal geht und ich kann natürlich nicht kontrollieren, ob mich anderen Menschen mit einem geheimen Chat kontaktieren werden. Ich glaube, die meisten würden es einfach nicht nutzen, daher ist es wichtig, dass so etwas als Standard drinnen ist. Darum geht es in meinem Artikel auch um die Standardfunktion, so wie die meisten es wohl erleben würden.
[2]Zusatz: Danke an Alex, der mich daran erinnert hat, dass Telegram-Telefonate standardmässig Ende-zu-Ende-Verschlüsselung nutzen.
Datenschutz-Bingo; mit freundlicher Genehmigung von @kleinphi
Dieser Beitrag ist, seltsamerweise, an Diejenigen gerichtet, die Datenschutz bereits verstehen.
Ein Thema, dass mir schon seit Jahren den Kopf zerbricht, ist: «Wie kommuniziere ich Datenschutz-relevante Themen?», oder anders gesagt, wie kommuniziere ich, dass Datenschutz wichtig ist?
Ich glaube, es gibt dazu aber schon genügend Erklärungen im Netz, die das Thema weitaus eloquenter beschreiben, als ich dies jemals könnte.
Natürlich, ist es ein komplexes Thema, und es würde somit auch bedeuten, dass sich die Menschen intensiv damit auseinandersetzen müssten. Ich glaube nicht, dass es sehr realistisch ist, dies von allen, oder auch nur einem grösseren Teil der Menschen, zu erwarten.
Es gibt auch andere Ansätze, wo mit kleinen Argumenten versucht wird, zumindest klarzustellen, dass Privatsphäre wichtig ist. Wie z.B. «Wenn du, wie du sagst, nichts zu verbergen hast, gib mir doch mal dein Smartphone, damit ich deine Nachrichten lesen kann.» oder «Du machst doch auf Toilette auch die Tür zu».
Diese Antworten sind vielleicht gut, um kurz zu veranschaulichen, dass wir doch irgendwie alle Privatsphäre möchten. Ich glaube aber auch, dass solche Argumente, das Ziel weit verfehlen. Denn im Grunde, wissen wir doch alle irgendwie schon, dass wir Privatsphäre brauchen. Nur deshalb funktioniert das Argument ja.
Daher möchte ich heute nichts predigen, sondern einen anderen Ansatz wählen, und stattdessen versuchen zu verstehen, und ein paar Beobachtungen und Gedanken teilen.
Ich glaube, um das Ganze zu verstehen, müssen wir sehr weit zurückgehen: In unsere Kindheit. Erinnert Ihr Euch, an die Geschichten von damals? Gut gegen böse, und gut siegt immer über böse. Das ist die Art von Geschichten, mit denen wir vermutlich alle aufgewachsen sind.
Im Erwachsenenalter, geht es mit so Geschichten eigentlich weiter. Wie oft habt Ihr eigentlichen einen Film gesehen, wo das böse gewinnt? Oder Krimi-Fernsehserien, wo die Polizei mal nicht die guten sind?
Jetzt fragt Ihr Euch vielleicht, was das mit Datenschutz zu tun hat. Es hat sich aber gezeigt, wer regelmässig solche Krimis im Fernsehen sieht, auch ein Gefühl dafür bekommt, dass «das System» auch so wie im Fernsehen dargestellt wird, funktioniert. Da «das System» sehr positiv dargestellt wird, ist dann das Weltbild gegenüber dem System positiv.
Der Punkt: Ich glaube, wer nicht informiert ist, und glaubt, «das System» funktioniert fehlerlos, und ebenfalls glaubt, gut siegt immer über böse, der kann mit gutem Gefühl sagen: «Wer nichts zu verbergen hat, hat auch nichts zu befürchten». Macht dann doch aus der Perspektive auch irgendwie Sinn, oder?
Ich habe dieses lustige Gehirn, dass zu viel nachdenkt, und sich Fragen stellt, die sich normale Menschen nicht so wirklich stellen. Wenn ich z.B. Bedenken zu einem Produkt, Lebensmittel, Material usw. habe, und dies auf meine spezielle Art und Weise äussere, kommt eigentlich meistens die Antwort: «Die würden das doch nicht machen, wenn es dir schaden würde!»
Da ist wieder dieser Glaube, dass doch irgendwie alles gut sein wird. Dass das Rechtssystem funktioniert, dass die Gesetze dich beschützen, und die Firmen sich daran halten, und sowieso nur dein Bestes wollen. Gut siegt halt eben über böse, wird geglaubt.
Jetzt kommen wir zurück zu unserem vorherigen Beispiel: «Wenn du, wie du sagst, nichts zu verbergen hast, gib mir doch mal dein Smartphone, damit ich deine Nachrichten lesen kann.»
Was ist hier eigentlich anders? Warum wird da gezögert oder abgelehnt? Ich habe da einen Gedanken zu. Wir Menschen haben eigentlich alle irgendwelche Erfahrungen mit anderen Menschen. Gute sowie schlechte. Und wir haben das Bewusstsein, dass nicht alle Menschen das Wohl anderer im Sinn haben.
Ich glaube, dieses selbe Bewusstsein fehlt gegenüber «dem System». Wir haben alle als Menschen mit Menschen zu tun, aber selten mit dem Rechtssystem, den Gesetzen, den Firmen, den Behörden, der (echten) Politik.
«Das System» ist abstrakt und gesichtslos. Wer sich auf Facebook registriert, sieht kein Gesicht, welches sagt «Gib mir mal dein Smartphone, ich möchte deine Nachrichten lesen», und sieht stattdessen eine Firma, welche unter Gesetzen steht, welche einen beschützen sollten, zusammen mit dem Glauben «die würden ja nicht den eigenen Kunden schaden».
Ich glaube also, das benötigte Bewusstsein, ist zum Teil schon da, aber eben nur gegenüber anderen Menschen mit Gesichtern.
Wir können also aufhören, über Datenschutz zu reden, solange die Menschen eine rosarote Brille anhaben, und müssen stattdessen die rosarote Brille durchbrechen.
Wie schaffen wir das? Mit Aufklärung. Aber da sind wir doch irgendwie am Anfang gelangt, und können uns wider den Kopf darüber zerbrechen.
Wer den Beitrag jetzt als sinnlos empfindet: Der Sinn war es, eine mögliche Art des Denkens und Weltbildes aufzuzeigen. Denn nur wer das Gegenüber versteht, kann auch effektiv kommunizieren.
Nun müsst ihr euch im Grunde selber eine Frage stellen: «Wie ist mein eigenes Weltbild, und was hat mich damals eigentlich auf Datenschutz sensibilisiert?»
Vielleicht, wenn Ihr diese Frage beantworten könnt, könnt ihr es auch kommunizieren. Ich sehe jetzt schon, ich werde tief in Gedanken gehen müssen, um diese Frage für mich selber zu beantworten.
Am 04. September dieses Jahres, erhielt ich eine seltsame E-Mail. Eine «Update-Erinnerung» von WinRAR. Ich solle auf Version 6.23 updaten.
Da ist natürlich einer der ersten Gedanken: Ein Versuch, mir Schadsoftware unterzujubeln.
Die E-Mail besagt, dass zwei Sicherheitslücken behoben worden sind.
Irgendwie hatte ich das Gefühl, dass diese E-Mail legitim ist. Also habe ich nachgeforscht und es waren tatsächlich zwei kritische Lücken behoben worden. Also natürlich schnell auf den Windows Rechnern ein Update von der offiziellen Seite durchgeführt.
Am 18. Oktober, kam ein Blogbeitrag von Google, der besagt, dass die WinRAR Sicherheitslücken von Regierungen ausgenutzt wurden.
Spezifisch wird die Sicherheitslücke CVE-2023-38831 behandelt.
Wer sich jetzt fragt, was WinRAR ist: Es ist ein Archivierungsprogramm, welches komprimierte Archive erstellen und entpacken kann.
Die bestimmte Sicherheitslücke, die wir uns heute anschauen, betrifft das Entpacken von ZIP Archiven. Es ist nämlich möglich, ein ZIP Archiv zu erstellen, sodass, wenn es mit WinRAR entpackt wird, Schadsoftware ausgeführt wird.
Wer jetzt nicht die Details wissen will, und einfach geschützt sein will, soll auf WinRAR Version 6.23 oder neuer updaten.
Nun zu den Details:
Windows erlaubt es nicht, Leerzeichen in der Dateierweiterung zu haben. Also eine Datei namens «Bild.png_» wäre ungültig (Leerzeichen hier als Underscore dargestellt).
Wenn sich in einem ZIP Archiv eine Datei namens «Bild.png_» und ein Ordner gleichen Namens befinden, wird beim Doppelklick auf die Datei, sowohl die Datei als auch der Ordner extrahiert.
Also packt der Angreifer in den Ordner namens «Bild.png_» auch die Datei «Bild.png_.exe«, denn die wird ja gleich mit extrahiert.
Der Ablauf des Angriffs:
Das Opfer möchte die harmlose Datei Bild.png_, und bekommt ebenfalls Bild.png_/Bild.png_.exe extrahiert.
WinRAR ruft nun Bild.png_ auf, was laut Windows nicht gültig ist. Windows jedoch versucht schlau zu sein, und iteriert sich durch den Ordner mit einer Liste fest verbauter Erweiterungen: «.pif, .com, .exe, .bat, .lnk, .cmd» und trifft dabei auf Bild.png_.exe, und führt es aus.
Und schon ist das Opfer infiziert.
Warum Windows dies macht? Ich nehme an, es ist die gleiche Autovervollständigung wie wenn ich Programm.exe habe, und in der CMD lediglich Programm eingeben kann.
Das ist sehr einfach auszunutzen, und dabei noch so effektiv. Das ist natürlich für Regierungen sehr attraktiv. Wer jetzt wissen will, wie dies von Regierungen ausgenutzt wurde, dem empfehle ich den Blogbeitrag von Google (auf Englisch), siehe dazu die Quellen unten.
Asymmetrische Verschlüsselung; Public Domain; openclipart.org
Stellt Euch vor, Ihr möchtet mit jemandem über das Internet kommunizieren. Der einfachste Weg ist es, die Daten einfach von A nach B zu senden. Das würdet natürlich nicht Ihr von Hand machen, sondern irgendein Programm, wie z.B. eine Messenger App.
Natürlich werden die Daten (z.B. die Nachricht) bei einem Messenger Dienst nicht direkt von Euch an den Empfänger gesendet, sondern eben über den Dienst. Dies bedeutet, die Nachricht kommt zuerst beim Dienst über einen sogenannten Server an, und wird von da an, an den Empfänger geleitet.
So einen Server dazwischen zu haben, bietet einige Vorteile: z.B. kann der Server die Nachricht zwischenspeichern, während der Empfänger offline ist, und die Nachricht später zustellen. Probleme mit Firewalls, IPv4-Mangel (CG-NAT) usw. fallen auch weg.
Jedoch ist es so, dass wenn Daten übers Internet von A nach B gesendet werden (egal ob über Server oder nicht), erst einmal jeder auf der Leitung mitlesen kann.
Transportverschlüsselung
Damit dies nicht mehr passiert, ist es heute Standard, eine sogenannte Transportverschlüsselung einzusetzen (damals SSL, heute TLS). Das heisst, die Daten in der Leitung werden verschlüsselt, damit niemand auf der Leitung mitlesen kann. Der Server selbst (also der Anbieter), hat den Schlüssel, und liest auf dem Weg mit.
Vertrauen und Datenlecks
Natürlich bedeutet dies, Ihr müsst dem Anbieter vertrauen, die Daten nicht zu missbrauchen. Falls die Nachrichten beim Anbieter gespeichert sind, müsst Ihr auch darauf vertrauen, dass der Anbieter kompetent ist, und eine sichere Infrastruktur betreibt, das Personal gut geschult ist, und es nicht zu einem Datenleck kommt.
Was, wenn der Anbieter ehrlich und vertrauenswürdig ist, aber eines Tages aufgekauft wird, von einem Käufer mit gewissen Interessen an den Daten? Was, wenn es einmal zu einem «Hack»-Angriff kommt?
Wie wir heutzutage wissen, kommt es immer wieder zu Datenmissbrauch und Datenlecks. Was, wenn Ihr also im Vertrauen mit einer anderen Person schreiben möchtet? Was, wenn es sensible Nachrichten sind?
Hier kommt Ende-zu-Ende-Verschlüsselung ins Spiel
Was wir über Server, Leitung und Transportverschlüsselung gelernt haben, bleibt erst einmal gleich. Jedoch kommt jetzt noch eine Schicht hinzu.
Bei Ende-zu-Ende-Verschlüsselung werden die Daten von einem Ende zum anderen Ende verschlüsselt. Dies bedeutet, der Sender hat einen Schlüssel auf dem Gerät, und der Empfänger hat ebenfalls einen.
Weder die Leitung noch der Anbieter können mitlesen. Ausser natürlich Metadaten.
Metadaten
Da der Anbieter natürlich weiterhin dazwischen sitzt und die Nachrichten verteilt, muss er mindestens wissen, wohin die Nachricht gehen soll. Er kann die Nachricht nicht lesen, aber weiss, wohin sie gehen soll. Obwohl es eigentlich technisch gesehen reichen würde, nur zu wissen wohin, schauen sich die meisten Anbieter auch an, woher die Nachricht kam (dies kann auch zum Schutz vor Missbrauch sein, wenn z.B. jemand ungewöhnlich viele Nachrichten automatisiert verteilt, sprich, Spam). Wenn die Anbieter dann auch noch Datum und Uhrzeit speichern, können sie sehen, wer mit wem und wann. Diese Daten werden Metadaten genannt.
Die Nachrichten sind somit sicher, die Metadaten nicht. Aber es ist eine deutliche Verbesserung, wenn die Nachrichten jetzt nicht mehr gelesen werden können.
Es ist natürlich möglich, mit «nur» den Metadaten, einiges herauszufinden. Wenn bekannt ist, wer mit wem wann kommuniziert, lassen sich ganze soziale Graphen erstellen. Wenn diese Daten dann mit anderen Daten zusammenkommen, welche einige der Gesprächsteilnehmer de-anonymisiert (z.B. da die eindeutig zuweisende Telefonnummer bekannt ist), ist es zumindest möglich Schlüsse zu ziehen.
Aber jetzt bitte nicht falsch verstehen: Das ist nicht ein Problem von Ende-zu-Ende-Verschlüsselung, sondern ein generelles Problem mit Metadaten. Ich möchte nur klarmachen, wo die Grenzen der Verschlüsselung stehen. Ihr solltet auf jeden Fall, wenn möglich, immer Ende-zu-Ende-Verschlüsselung nutzen.
Ende-zu-Ende-Verschlüsselung, auch für Speicher
Ende-zu-Ende-Verschlüsselung ist nicht auf Kommunikation beschränkt. Dies kann auch für sogenannte Cloud-Speicher eingesetzt werden. Entweder durch den Anbieter unterstützt (z.B. Apple’s iCloud), oder mit eigenen Mitteln wie z.B. Cryptomator.
Dabei sind die «Enden» Eure Geräte, welche Ihr synchronisiert. Das Prinzip ist das gleiche: Die Geräte haben die Schlüssel, der Anbieter nicht.
Aber auch da gibt es Metadaten wie Zeitstempel, Dateigrösse und in manchen Fällen sogar Dateinamen.
Limits der Enden
Jetzt aber ein wichtiger Punkt: Ende-zu-Ende-Verschlüsselung ist keine Magie, und nur so sicher wie Eure «Enden». Wenn Ihr mit jemandem kommuniziert, und die andere Person macht ein Bildschirmfoto von den Nachrichten und teilt dieses Foto, hilft Euch die Verschlüsselung auch nicht weiter.
Oder vielleicht hat eines der Enden irgendwelche «Malware» («Schadsoftware»).
Die Verschlüsselung ist, wie vieles in der IT-Sicherheit, halt eben nur eine Schicht von vielen, und leider kein Hexenwerk.
Englische Abkürzung
Übrigens: Auf Englisch nennt sich Ende-zu-Ende-Verschlüsselung «End-to-End-Encryption», da «to» und «two» ähnlich klingen, wird abgekürzt zu «E2EE».
Fazit
Wenn Ihr die Option habt, solltet Ihr immer Ende-zu-Ende-Verschlüsselung (E2EE) nutzen, und immer darauf achten, dass Eure Enden auch sicher sind. Wie man so schön sagt: Vertrauen ist gut, Kontrolle ist besser.
Ich hoffe, ich konnte das Thema verständlich erklären.
In meinem Blog habe ich schon auf verschiedensten Arten das Thema Verschlüsselung angesprochen, und auch heute geht es um das Thema, genauer gesagt um ein technisches Detail der Kryptographie.
Dieses Detail wird euch in Zukunft hoffentlich helfen, bessere Entscheidungen zu treffen, wenn es um die Schlüssellänge geht.
Und zwar geht es um «Security Level», oder zu Deutsch, «Sicherheitslevel». Dieses «Level» beschreibt die Stärke eines Kryptographischen Algorithmus und der gewählten Schlüssellänge, gemessen in Bits.
Klingt erst einmal kompliziert, ist es technisch gesehen auch, aber ich werde es einmal so erläutern, dass es für alle, die es interessiert, in der Praxis nutzbar ist:
Falls Ihr schon einmal Verschlüsselung eingesetzt habt, habt Ihr vielleicht bereits von verschiedenen Algorithmen wie «AES», «RSA» und «ECC» gehört. Und falls Ihr auch schon Schlüssel generiert habt, gab es die Wahl einer sogenannten Schlüssellänge.
Dies kommt z.B. vor, wenn Ihr Eure Festplatte verschlüsselt, einen PGP oder S/MIME Schüssel generiert, und vielem mehr. Wer die eigene Festplatte verschlüsseln will, nutzt dafür üblicherweise den Algorithmus «AES» und hat die Wahl zwischen Schlüssellängen von 128, 192 oder 256 Bits. Wer E-Mails verschlüsseln will, nutzt dafür meist «RSA» und hat Schlüssellängen von 2048, 3072 oder 4096 Bits zur Auswahl.
Jetzt kommt natürlich die Frage: Wie stehen AES-128 und RSA-2048 zueinander? Welches ist sicherer? Wie vergleiche ich?
Ein Leihe würde vielleicht denken: Grösserer Schlüssel bedeutet sicherer. Das trifft innerhalb eines Algorithmus auch zu. Wenn jedoch zwei verschiedene Algorithmen verglichen werden, funktioniert dies nicht und das «Sicherheitslevel» kommt ins Spiel.
Die Mathematik dahinter zu erklären würde über das Ziel dieses Blogs hinausschiessen, aber es reicht zu wissen, dass für einen bestimmten Algorithmus und Schlüssellänge berechnet werden kann, wie rechenaufwändig es wäre diese Verschlüsselung zu knacken. Der Aufwand wird in Bits ausgegeben.
Zufälligerweise ist es oft so, dass bei symmetrischer Verschlüsselung wie AES, die Schlüssellänge und das Sicherheitslevel ein und dasselbe sind. So hat AES-128 ein Sicherheitslevel von 128 Bits.
Bei elliptischen Kurven (ECC), ist die Daumenregel, dass die Schlüssellänge durch zwei geteilt, das Sicherheitslevel ergibt. Somit hat ECC-256 Bits ebenfalls ein Sicherheitslevel von 128 Bits, und ist in der Stärke somit äquivalent zu AES-128.
Bei RSA gibt es leider keine Daumenregel, aber ich kann euch verraten, dass RSA-2048 112 Bits an Sicherheit bietet, und somit schwächer als AES-128 und ECC-256 ist.
Hier eine hilfreiche Tabelle:
Stärke[2]
AES (Länge)[2]
RSA (Länge)[2]
ECC (Länge)[2]
80 Bits
Nicht verfügbar
1024 Bits
160 Bits
112 Bits
Nicht verfügbar
2048 Bits
224 Bits
128 Bits
128 Bits
3072 Bits
256 Bits
192 Bits
192 Bits
7680 Bits[1]
384 Bits
256 Bits
256 Bits
15360 Bits[1]
512 Bits
Bits an Sicherheit pro Bits an Schlüssellänge per Algorithmus
Grundsätzlich wollt Ihr heutzutage ein Sicherheitslevel von mindestens 128 Bits. Somit solltet Ihr AES-128, RSA-3072 und ECC-256 verwenden, und nichts darunter. Gerne dürft ihr aber darüber gehen.
[1]Tipp: Wenn Ihr mehr Sicherheit wollt, macht es bei RSA keinen Sinn höher als eine Schlüssellänge von 3072 Bits zu gehen, da der Rechenaufwand schnell in die Höhe schiesst, ohne grossen Gewinn. Meine Empfehlung ist es daher, einfach ganz auf ECC umzusteigen.
[2]Achtung: Es ist wichtig, das Sicherheitslevel und die Schlüssellänge nicht zu verwechseln. Dies kann schnell passiert sein, da beides in Bits gemessen wird.
Ich hoffe, dieser Beitrag konnte euch weiterhelfen, und das Mysterium der Schlüssellänge lüften. Das ist leider eines dieser Dinge, welches oft nirgendwo erklärt wird, aber welches meiner Meinung nach zu einem soliden Grundwissen gehören sollte (zumindest für diejenigen, die Verschlüsselung selber einsetzen).
PS, wer sich zu der Tabelle fragt, wo RSA mit 4096 Bit Schlüssel hin verschwunden ist: Dazu gibt es bedauerlicherweise keine offiziellen Berechnungen, von denen ich wüsste. Ihr könnte aber von der Tabelle entnehmen, dass die Sicherheit zwischen 128 und 192 Bits liegen muss.
Im heutigen Beitrag geht es etwas erweitert daher, und die Zielgruppe sind diejenigen, die bereits PGP nutzen, oder das Basiswissen erweitern möchten.
Normalerweise, wenn Sie einen Schlüssel generieren, erhalten Sie standardmässig einen RSA Schlüsselpaar (meistens mit einer Länge von 2048 oder 4096 Bits), wobei der Hauptschlüssel zertifizieren und signieren kann, und ein separater Unterschlüssel für die Verschlüsselung generiert wird. Standardmässig laufen keine der Schlüssel ab.
Wir können das jedoch optimieren!
Ich muss aber klar bemerken, dass es hier nicht um eine 08/15 Anwendung von PGP geht, sondern um eine erweiterte Anwendung, die für die meisten Menschen vermutlich eher als «unpraktisch» empfunden wird. Wer jedoch interessiert daran ist, zu wissen, wie es theoretisch gehen könnte, oder meint dies zu benötigen, darf gerne weiterlesen. Ich habe euch aber gewarnt! 🙂
Schauen wir uns die Punkte etwas genauer an:
RSA und Curve25519
RSA wird mittlerweile langsam durch elliptische Kurven wie z.B. Curve25519 abgelöst.
Den Algorithmus zu erklären, wäre für diesen Beitrag etwas zu viel, aber einen kurzen Überblick: Beide Verfahren nutzen natürlich ein unlösbares Problem in der Mathematik. Bei RSA geht es um Primzahlen, und bei Curve25519 um elliptische Kurven. Wobei die einzige «Lösung» den privaten Schlüssel ausfindig zu machen, im «ausprobieren bis gefunden» besteht, was mit heutiger Technik «endlos» dauern würde.
Das Interessante jedoch: Schlüssel mit Curve25519 sind immer 256-Bit lang. Was aber wichtig ist zu verstehen: 256-Bit Curve25519 Schlüssel sind nicht weniger sicher, nur weil sie kürzer sind! Es ist eine ganz andere Problemstellung, und ein direkter Vergleich ist schwierig, aber grob gesagt, Curve25519 mit 256-Bit, hat etwa die Stärke von RSA mit 3072-Bit. Beides gilt heutzutage als sicher.
Beide Verfahren sind natürlich sinngemäss rechenaufwendig, elliptische Kurven sind jedoch «leichter», wenn der Schlüssel bekannt ist. Das macht Curve25519 somit schneller, womit es für schwächere Hardware besser geeignet ist. Bemerkbar macht sich dies teilweise z.B. mit einem Hardware-Sicherheitsschlüssel, wobei der mit RSA Schlüssel vergleichbarer Stärke, deutlich mehr rechnen muss.
RSA hat den klaren Vorteil, alt zu sein, also sprich: Weiter verbreitet, besser unterstützt, erweiterte Kompatibilität. Wer z.B. seinen PGP Schlüssel mit Curve25519 auf seinen YubiKey laden möchte, braucht dafür mindestens einen YubiKey 5, mit Firmware Version 5.2 oder neuer (verfügbar seit ca. Ende 2020).
Es ist natürlich unmöglich in die Zukunft zu sehen, aber ich behaupte jetzt einfach mal, dass elliptische Kurven, zumindest vorerst, die nahe Zukunft sind, und wir werden somit spezifisch auf Curve25519 setzen.
Subkeys (Unterschlüssel)
Wie zuvor erwähnt, wird standardmässig ein Hauptschlüssel generiert, der zertifizieren und signieren kann, mit einem Unterschlüssel für die Verschlüsselung.
Der Nachteil dabei: Wenn der Schlüssel abhandenkommt, muss der widerrufen werden, ihr müsst einen neuen Schlüssel generieren, den mit allen euren Kontakten teilen, und den Fingerabdruck neu verifizieren lassen. Das ist aufwendig und kann vermieden werden!
Stattdessen empfehle ich einen Hauptschlüssel zu generieren, der nur zertifizieren kann, und drei Unterschlüssel zu generieren, und zwar je einen für Verschlüsselung, Signatur und Authentifizierung (kann z.B. für SSH verwendet werden).
Der Hauptschlüssel wird dann nur noch für Änderungen am Schlüsselpaar genutzt, wie z.B. das Ändern von Ablaufdaten, Erstellung oder Widerrufung von Unterschlüsseln, das Hinzufügen von Identitäten, usw. Der Trick dabei: Der Hauptschlüssel wird sicher offline aufbewahrt (z.B. auf mehrere USB-Sticks verschlüsselt abgespeichert, und in einen Brandschutzsafe, Bankschliessfach, oder realistischer «in der einen Schublade mit Krimskrams» usw.) und dann vom Computer gelöscht. Ihr nutzt dann nur noch die Unterschlüssel für alltägliche Aufgaben, und holt den Hauptschlüssel nur hervor, wenn ihr was am Schlüsselpaar ändern müsst.
Wenn die Unterschlüssel kompromittiert wurden, holt ihr den Hauptschlüssel hervor (auf einem sauberen Gerät), widerruft einfach die Unterschlüssel, generiert neue, und verteilt den neuen öffentlichen Schlüssel. Das Gute daran: Der Fingerabdruck ist unverändert. Der stammt nämlich vom Hauptschlüssel, welcher jedoch nicht kompromittiert wurde, da der zum Zeitpunkt des «Vorfalls» nicht auf dem Computer vorhanden war.
Das ist eigentlich die «korrekte» Art der Schlüsselverwaltung. Warum dies nicht Standard ist, kann ich nicht sagen. Meine Vermutung: Es ist für die meisten einfach zu aufwendig, eine Zertifizierungsstelle zu spielen. Für Endverbraucher ist ja schon die «normale» Art von PGP zu viel.
Tipp: Ihr müsst den USB-Stick nicht separat verschlüsseln, einfaches FAT32 oder exFAT reicht aus, denn, sofern Ihr ein Passwort definiert habt, wird der Schlüssel verschlüsselt abgespeichert. Bedenkt einfach, dass das Passwort stark sein muss, denn es ist das Einzige, was den Schlüssel beschützt. Ich empfehle jedoch ein robusteres Dateisystem, je nachdem, was Ihr für ein Betriebssystem nutzt.
Ablaufdatum
Es ist «best practice» Schlüsseln immer ein Ablaufdatum zu vergeben. Das hat auch praktische Gründe: Ich habe es schon oft gesehen, dass einige ein Schlüsselpaar generierten, und dann den Schlüssel verloren. Wenn dann kein Widerrufs-Zertifikat existiert, bleibt der Schlüssel gültig, auch wenn nicht mehr nutzbar. Wenn der Schlüssel dann auf einem altmodischen Schlüsselserver ist (nicht empfohlen), wo der Schlüssel nicht gelöscht werden kann, wird man weiterhin E-Mails erhalten, die nicht geöffnet werden können. Das Einzige, was euch dann noch rettet, ist ein Ablaufdatum. Es ist nämlich immer möglich, das Ablaufdatum eines vorhandenen Schlüssels zu verlängern, nicht jedoch umgekehrt.
Meine Empfehlung, als Richtlinie, die Ihr anpassen könnt: dem Hauptschlüssel eine Lebensdauer von 5 Jahren zuweisen, und den Unterschlüsseln jeweils ein Jahr. Dann, einmal jährlich, holt ihr den Hauptschlüssel hervor, und rotiert die Unterschlüssel. Das bedeutet, neue Unterschlüssel generieren (1 Jahr), und die alten ablaufen lassen, und evtl. auf einen USB-Stick verschieben. Falls die Schlüssel abhandenkommen, werden somit höchstens 1 Jahr an E-Mails entschlüsselbar. Falls ihr oft auf alte E-Mails zugreift, könnt ihr die Schlüssel auch auf dem Rechner lassen, geniesst aber nicht den erweiterten Schutz.
Wer YubiKeys nutzt, aber auch oft alte E-Mails öffnen muss, der muss stattdessen einfach das Ablaufdatum der Unterschlüssel verlängern. Das liegt daran, dass YubiKeys nur drei Keyslots haben, und ältere Unterschlüssel somit nicht draufpassen. Der Vorteil jedoch ist: Die Schlüssel können nicht ausgelesen werden, die Gefahr der Kompromittierung ist also gering (der Angreifer müsste an den YubiKey sowie die PIN gelangen, Malware kann den Schlüssel nicht auslesen).
Zwischenbemerkung
So, bald werden wir gemeinsam ein Schlüsselpaar generieren. Ich möchte aber klar betonen: Was ich hier beschreibe, ist nicht die übliche Art PGP zu nutzen, und für die meisten ist es unpraktisch und ohne grossen Gewinn. Wenn ihr aber James Bond spielen wollt, lest weiter.
Generierung der Schlüssel à la James Bond
Wir werden GnuPG (gpg) im Terminal verwenden. Ich nutze für dieses Beispiel GnuPG/MacGPG2 Version 2.2.41.
Wir werden GnuPG im Expertenmodus starten:
gpg --full-gen-key --expert
Folgendes ist zu sehen:
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(9) ECC and ECC
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(13) Existing key
(14) Existing key from card
Your selection?
Wir wählen 11, um unsere eigenen Angaben … anzugeben. 😄
Possible actions for a ECDSA/EdDSA key: Sign Certify Authenticate
Current allowed actions: Sign Certify
(S) Toggle the sign capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection?
Wir sehen nun, dass der Schlüssel momentan «Sign» und «Certify» kann. Wir wollen aber nur Zertifizierung, geben also «S» ein, um «Sign» zu deaktivieren. Wir sollten nun nur noch «Certify» sehen, und geben somit «Q» ein, um zu beenden.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
Da es sich hierbei um den Hauptschlüssel geht, wollen wir, dass der in 5 Jahren abläuft und geben somit «5y» ein, überprüfen das Ablaufdatum, und wenn alles korrekt ist, bestätigen wir mit «y».
GnuPG needs to construct a user ID to identify your key.
Real name:
So, jetzt werdet Ihr drei Fragen gestellt. Ihr müsst euren Namen eingeben (das muss nicht der rechtliche Name sein!), mit Enter bestätigen, dann die E-Mail-Adresse, erneut mit Enter bestätigen, und zuletzt noch einen Kommentar, den ihr auslassen könnt, und erneut mit Enter bestätigen. Am Ende wird euch die «USER-ID» angezeigt, wenn alles gut aussieht, bestätigt ihr mit dem Buchstaben «O».
Nun müsst ihr ein Passwort eingeben, womit der Schlüssel geschützt wird. Ihr müsst euch dieses Passwort gut merken, oder noch besser, zufällig generieren und im Passwortmanager abspeichern.
Der Hauptschlüssel ist nun generiert! Ihr solltet auch gleich Infos dazu angezeigt bekommen:
gpg: revocation certificate stored as '/Users/nat/.gnupg/openpgp-revocs.d/9F67C23D80C185EAD0B99A4C5BF2C3D0C08EA34F.rev'
public and secret key created and signed.
pub ed25519/0x5BF2C3D0C08EA34F 2023-09-02 [C] [expires: 2028-08-31]
Key fingerprint = 9F67 C23D 80C1 85EA D0B9 9A4C 5BF2 C3D0 C08E A34F
uid Natalie Kagelmacher <+@kagel.ch>
Ihr seht da «revocation certificate», am besten gleich die Datei in den Passwortmanager und/oder auf USB-Sticks. Das ist das Widerrufs-Zertifikat, wenn der Schlüssel abhandenkommen sollte (damit könnt ihr den Schlüssel als ungültig erklären).
Das wird übrigens auch gleich mein echter neuer Schlüssel, ich habe jedoch den Benutzernamen vor dem @ mit einem Plus ersetzt, wegen Spambots. Es ist jedoch in Wirklichkeit «nat». 😉
So, jetzt geht es aber noch weiter … ziemlich mühsam!
gpg --edit-key --expert +@kagel.ch
Mit diesem Befehl editieren wir den Schlüssel, um Unterschlüssel zu erstellen. Ersetzt die E-Mail-Adresse natürlich mit der eigenen.
Ihr solltet nun in einem interaktiven Modus sein. Gebt «addkey» ein und bestätigt mit Enter. Wir geben wieder 11 ein, und sollten nun auswählen können, was wir möchten. Wir sollten «Sign» sehen, und bestätigen somit mit Q, und wählen 1 für Curve25519, geben 1y für das Ablaufdatum ein, bestätigen mit y, dann nochmal y, geben das bestehende Passwort ein, geben «save» ein, um den Fortschritt nicht zu verlieren. Nun rufen wir wieder den --edit-key Befehl ein, und machen das Ganze erneut, aber diesmal für Encrypt und Authenticate (also nicht immer die Option 11!). Das Ganze sieht in etwa so aus:
❯ gpg --edit-key --expert +@kagel.ch
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(12) ECC (encrypt only)
(13) Existing key
(14) Existing key from card
Your selection? 11
Possible actions for a ECDSA/EdDSA key: Sign Authenticate
Current allowed actions: Sign
(S) Toggle the sign capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? q
Please select which elliptic curve you want:
(1) Curve 25519
(3) NIST P-256
(4) NIST P-384
(5) NIST P-521
(6) Brainpool P-256
(7) Brainpool P-384
(8) Brainpool P-512
(9) secp256k1
Your selection? 1
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1y
Key expires at Sun Sep 1 06:28:46 2024 CEST
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
sec ed25519/0x5BF2C3D0C08EA34F
created: 2023-09-02 expires: 2028-08-31 usage: C
trust: ultimate validity: ultimate
ssb ed25519/0x2B31C35FF98972EE
created: 2023-09-02 expires: 2024-09-01 usage: S
[ultimate] (1). Natalie Kagelmacher <+@kagel.ch>
gpg> save
❯ gpg --edit-key --expert +@kagel.ch
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(12) ECC (encrypt only)
(13) Existing key
(14) Existing key from card
Your selection? 12
Please select which elliptic curve you want:
(1) Curve 25519
(3) NIST P-256
(4) NIST P-384
(5) NIST P-521
(6) Brainpool P-256
(7) Brainpool P-384
(8) Brainpool P-512
(9) secp256k1
Your selection? 1
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1y
Key expires at Sun Sep 1 06:33:48 2024 CEST
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
sec ed25519/0x5BF2C3D0C08EA34F
created: 2023-09-02 expires: 2028-08-31 usage: C
trust: ultimate validity: ultimate
ssb ed25519/0x2B31C35FF98972EE
created: 2023-09-02 expires: 2024-09-01 usage: S
ssb cv25519/0xB04C0BF9FC8DF669
created: 2023-09-02 expires: 2024-09-01 usage: E
[ultimate] (1). Natalie Kagelmacher <+@kagel.ch>
gpg> save
❯ gpg --edit-key --expert +@kagel.ch
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
(7) DSA (set your own capabilities)
(8) RSA (set your own capabilities)
(10) ECC (sign only)
(11) ECC (set your own capabilities)
(12) ECC (encrypt only)
(13) Existing key
(14) Existing key from card
Your selection? 11
Possible actions for a ECDSA/EdDSA key: Sign Authenticate
Current allowed actions: Sign
(S) Toggle the sign capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? s
Possible actions for a ECDSA/EdDSA key: Sign Authenticate
Current allowed actions:
(S) Toggle the sign capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? a
Possible actions for a ECDSA/EdDSA key: Sign Authenticate
Current allowed actions: Authenticate
(S) Toggle the sign capability
(A) Toggle the authenticate capability
(Q) Finished
Your selection? q
Please select which elliptic curve you want:
(1) Curve 25519
(3) NIST P-256
(4) NIST P-384
(5) NIST P-521
(6) Brainpool P-256
(7) Brainpool P-384
(8) Brainpool P-512
(9) secp256k1
Your selection? 1
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1y
Key expires at Sun Sep 1 06:34:23 2024 CEST
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
sec ed25519/0x5BF2C3D0C08EA34F
created: 2023-09-02 expires: 2028-08-31 usage: C
trust: ultimate validity: ultimate
ssb ed25519/0x2B31C35FF98972EE
created: 2023-09-02 expires: 2024-09-01 usage: S
ssb cv25519/0xB04C0BF9FC8DF669
created: 2023-09-02 expires: 2024-09-01 usage: E
ssb ed25519/0xDC9F9AAE257CDF7D
created: 2023-09-02 expires: 2024-09-01 usage: A
[ultimate] (1). Natalie Kagelmacher <+@kagel.ch>
gpg> save
Wenn ihr am Ende vier Schlüssel habt, mit jeweils C, S, E und A, habt ihr alles richtig gemacht!
Schlüssel sichern und löschen
Aber, ich habe euch gewarnt. Wir sind noch nicht fertig!
Nun machen wir Backups von den Schlüsseln. Einmal komplett, und einmal nur die Subkeys. Beide Backups kommen ebenfalls auf den USB-Stick. Dann löschen wir den Schlüssel vom Rechner, und importieren nur die Subkeys wider rein. Wer einen YubiKey nutzen möchte, würde danach die Subkeys auf den YubiKey verschieben.
❯ gpg --export-secret-keys -a +@kagel.ch > PRIVATE_COMPLETE_+@kagel.ch.asc
❯ gpg --export-secret-subkeys -a +@kagel.ch > PRIVATE_SUBKEYS_+@kagel.ch.asc
❯ gpg --export -a +@kagel.ch > PUBLIC_+@kagel.ch.asc
Nachdem die Schlüssel mehrmals auf USB-Sticks gesichert sind, löschen wir sie vom GnuPG Schlüsselbund:
gpg --delete-secret-keys +@kagel.ch
Ihr werdet mehrmals gefragt, und ihr müsst mehrmals bestätigen. Das ist quasi die Plastik-Schutzkappe, bevor ihr auf den grossen roten Knopf hauen könnt.
Nun importieren wir die Subkeys:
gpg --import PRIVATE_SUBKEYS_+@kagel.ch.asc
Wenn Ihr nun erneut gpg -k +@kagel.ch eingebt, kann es sein, dass ihr vor dem Hauptschlüssel ein # steht. Dies bedeutet, der Hauptschlüssel ist nicht im Schlüsselbund, das ist korrekt so. In meinem Falle wird dies im Terminal nicht dargestellt, jedoch im GUI sehe ich neben «Card» nun ein «#».
Wir sind nun eigentlich fertig!
Wer noch weitergehen will, verschiebt die Schlüssel auf einen YubiKey oder ähnlich, wieder mit dem --edit-key Befehl, aber diesmal anstelle von «addkey» gebt ihr «keytocard» ein und befolgt die Schritte. Am besten im Herstellerhandbuch eures spezifischen Hardware-Schlüssels nachschlagen, wie ihr dies am besten macht.
SSH
Euer SSH public key erhält ihr übrigens so (mit eurer Adresse ersetzen):
gpg --export-ssh-key +@kagel.ch
Wie ihr GnuPG als SSH Agent nutzt, ist ein Thema für ein anderes Mal.
Fazit
Sofern ihr dem Artikel nachgegangen seid, habt ihr möglicherweise, das bestmögliche PGP Setup. Es ist nicht wirklich realistisch, ich hoffe jedoch sehr, es hat trotzdem irgendwie weitergeholfen oder war zumindest Spass! 😊
Diesen Artikel zu verfassen, hat unerwartet doch noch mehrere Stunden gedauert. Es ist immer wieder erstaunlich wie leicht es ist dies zu unterschätzen! Ich frage mich, ob ich so ein Ko-fi einrichten soll. Einen Kaffee könnte ich nun nämlich wirklich gebrauchen. 😅☕️
Heute geht es um ein Thema, das mir sehr am Herzen liegt: Datenschutz.
Ich bin momentan auf Stellensuche. Inzwischen ist es mehr als 10 Jahre her, dass ich auf Stellensuche war, und die Zeiten haben sich definitiv geändert.
Stellensuche Damals
Ich ging ins BIZ (Berufsinformationszentrum), wo ich nach einer Liste an offenen Stellen (Informatik/Applikationsentwicklung) in der Region fragte, und bekam zwei volle A4 Seiten im Querformat ausgedruckt.
Dann suchte ich mir raus, was interessant klang, schrieb die Bewerbungen, und druckte dann einen Stapel aus (natürlich mit personalisierten Bewerbungsschreiben!), ging zur Post, und gut ist.
Die Antworten kamen dann per Post oder Telefonat. Bei Absage war eine personalisierte Begründung dabei.
Stellensuche Heute
Was schon einmal anders ist, ist, dass ich alle Stellen online finden kann. Das ist praktisch und spart Zeit.
Ich bin jedoch altmodisch und würde noch heute die Bewerbungen auf Papierweg einreichen, wenn es denn möglich wäre. Nicht weil ich mich digital nicht auskenne, sondern eben gerade, weil ich mich auskenne.
Heutzutage akzeptieren viele IT Firmen anscheinend keine Bewerbungen auf dem Postweg mehr, und wollen stattdessen eine von vielen Jobplattformen nutzen, wo die Bewerbungsunterlagen als PDF hochgeladen werden.
Dann kommt evtl. eine automatisierte E-Mail an, dass die Bewerbung erhalten wurde, und bei Absage auch eine automatisierte E-Mail, ohne Begründung.
Das ist zwar unpersönlich, aber nicht das eigentliche Problem.
Das Problem mit der Digitalisierung
Das Übermitteln der Bewerbung als PDF finde ich an sich nicht problematisch, wenn es denn sicher und datenschutzkonform passieren würde.
Das Problem liegt eigentlich darin, was (in der Praxis oft) im Hintergrund passiert.
Oftmals geht die Bewerbung eben nicht direkt an die Firma, wo ein Mensch diese anschaut und im Falle einer Absage, löscht, sondern über einen von vielen Dienstleistern, die ein Portal für das Hochladen bereitstellen.
Diese Dienstleister und dessen Portale sind teilweise amerikanisch, wo Datenschutz ohnehin ein Fremdwort ist. Die Bewerbung wird dann nach dem Hochladen per Software gescannt, um mögliche Datenpunkte zu extrahieren. Teilweise wird auch KI eingesetzt, die Daten für weitere Analysen verschluckt. Manche Dienstleister behalten sich das Recht vor, die Daten für gewerbliche Zwecke zu verwenden (vllt. wäre das Wort missbrauchen das bessere).
Die Daten werden dann auch möglichst permanent gespeichert und verarbeitet, selbst lange nach einer Absage, wo die Datenspeicherung eigentlich nicht mehr zweckmässig ist.
Wer für Datenschutz und KI sensibilisiert ist, der wird verstehen, dass diese jetzige Situation bereits ein Horrorszenario ist.
Wer das Thema noch nicht versteht, dem wird es jetzt vermutlich schwerfallen, das Problem zu sehen. Es sind eigentlich mehrere Probleme, die zwei wichtigsten jedoch sind «Datenschutz» und «Ethik beim Einsatz von KI» (aber auch wie fehlerbehaftet KI oft ist).
Diese beiden Themen müssen jedoch warten, weil sie ihre eigenen Artikel verdient haben.
Zwang zur Einwilligung
Natürlich muss vor dem Hochladen, der Datenschutzerklärung und somit der Datenverarbeitung zugestimmt werden.
In der EU gilt die DSGVO, da muss eine Einwilligung zur Datenverarbeitung komplett freiwillig erfolgen, ansonsten ist die Einwilligung nicht gültig.
Alleine schon «Melde dich zum Newsletter an und erhalte einen 10-Euro-Gutschein» ist in der EU nicht rechtens, da die Übergabe der E-Mail-Adresse nicht komplett freiwillig, sondern unter einem Lockangebot erfolgte.
Gleichermassen betrachte ich die Einwilligung zur Datenverarbeitung bei der Stellensuche (zumindest in der EU) als ungültig, da einem Stellensuchenden ohne Alternative auf dem Postweg, keine Wahl gelassen wird, und die Nutzung des Portals (und somit die Einwilligung) erzwungen wird. Es könnte vielleicht auch argumentiert werden, dass es trotz Alternative auf dem Postweg nicht gültig wäre, da die Alternative mit erheblichem Mehraufwand verbunden ist (einfach ein Gedanke).
Aber ich bin in der Schweiz, diese ist nicht in der EU und somit gilt auch nicht die DSGVO. In der Schweiz wird Datenschutz grossgeschrieben, aber eben nur geschrieben. In der Praxis gibt es oft gar keinen Datenschutz, und wenn, dann wird diese eben durch das Akzeptieren einer Datenschutzerklärung ausgehebelt (was in der EU nicht so einfach gehen würde, zumindest nicht rechtlich). Dies ist aber ein Thema, welches auch einen eigenen Artikel verdient hat.
Fazit
Für aufgeklärte Menschen ist die Situation ziemlich frustrierend, vor allem weil der Zwang besteht. Wenn mir Datenschutz etwas bedeutet, dann nutze ich halt kein Facebook. Dies ist meine Entscheidung.
Bei der Stellensuche jedoch, da wird mir die Entscheidung oft genommen.
Ein Schlaumeier würde jetzt sagen «Dann bewirb dich nicht!», tja, vielleicht wenn ich einen Topf voll Gold finde, lasse ich es sein.
Eine Sorge, die ich dabei hatte, war Spam. Denn ohne Cloudflare, werden Bots nicht schon bei der Verbindung gekappt, sondern haben vollen Zugriff auf den Blog.
Da das Moderieren von Spam kurzfristig viel Zeit kosten kann, ist es sinnvoll eine Softwarelösung einzusetzen, die zumindest eindeutigen Spam erkennt und automatisch in den Spam-Ordner verschiebt.
Dieser Blog ist noch jung, somit war Spam in den Kommentaren ohnehin nicht solch ein grosses Problem (jedoch im Kontaktformular). Inzwischen habe ich jedoch so einiges an Kommentarspam erhalten, und kann somit auch berichten, dass mein Spam-Schutz zuverlässig funktioniert.
Akismet, nein Danke!
Jetzt denken vielleicht einige von euch an Akismet, welches ein Plugin ist, dass mit WordPress standardmässig mitinstalliert wird, und von Automattic betrieben wird, die Firma, die auch WordPress entwickelt.
Da Akismet jedoch eine Cloud-Lösung ist, welche nicht nur den Kommentar, sondern auch die Nutzerdaten wie E-Mail-Adresse, Namen, Webseite und IP-Adresse überträgt, empfinde ich dies von einer Datenschutzperspektive eher als problematisch.
Das geht jedoch auch anders, denn mit Antispam Bee, ist es auch möglich Kommentare Lokal und ohne Cloud auf Spam zu prüfen.
Antispam Bee: Ohne Cloud
Aber aufgepasst: Die GeoIP- sowie die Spracherkennungsfunktion von Antispam Bee nutzen Cloud. Deshalb habe ich diese Optionen deaktiviert. Soweit sind diese Funktionen auch unnötig für mich. Mit GeoIP wird anhand der IP-Adresse das Land ermittelt, und es ist möglich gewisse Länder zu blockieren oder umgekehrt auf diese zu beschränken. Grundsätzlich halte ich solch eine Funktion für problematisch. Was, wenn einer meiner Leser in den Ferien meinen Blog liest, und aus dem Ausland kommentiert? Das würde dann nicht gehen. Ausserdem werden oft mit IP-Adressen grenzüberschreitend gehandelt, daher ist die Ländererkennung nicht immer richtig. Die Spracherkennung jedoch wäre interessant, um Kommentare auf Deutsch zu beschränken (viel Spam ist z. B. auf Englisch und Russisch), aber einen Cloud-Dienst dafür zu nutzen ist es mir nicht wert.
Antispam Bee Funktionsweise
Antispam Bee nutzt verschiedene Techniken, um Spam zu erkennen. Die effektivste Technik, die auch garantiert keine echten Kommentare blockiert, ist wohl der «Honeypot» («Honigtopf»). Dabei wird ein unsichtbares Feld in die Kommentare gesetzt, die ein Mensch nicht sehen kann, ein Bot jedoch schon. D.H., wenn das Feld ausgefüllt wurde, war es unmöglich ein normaler Besucher, und der Kommentar war Spam.
Eine andere Methode ist es auf BB Code zu prüfen. Das ist eine Art der Formatierung, die in Foren verwendet wird. Da WordPress dieses nicht unterstützt, kann beim Vorhandensein von BB Code von Forum Spam ausgegangen werden.
Zu guter Letzt, kann die Kommentar-Zeit genutzt werden. Ein Mensch wird wohl nicht innerhalb von 2 Sekunden einen Kommentar verfassen, besonders nicht, weil ja normalerweise vor dem Kommentieren ja der Artikel gelesen oder zumindest überflogen wird, was schon länger als diese 2 Sekunden dauert. Ein Spambot jedoch kommentiert direkt, in Geschwindigkeiten, die ein Mensch einfach nicht hinbekommt.
Es gibt noch mehr Wege, wie Antispam Bee Spam entdeckt, aber das sind so die Drei, die ich kurz vorstellen wollte, da diese einfach und dennoch effektiv sind.
Ich empfehle die Cloud Funktionen (Länder- sowie Spracherkennung) zu deaktivieren. Auch ohne diese Funktionen kam bis jetzt kein Spam durch.
Ich hoffe, der Artikel hat euch weitergeholfen!
PS Falls ihr von Akismet auf Antispam Bee wechselt, nicht vergessen das Akismet Plugin zu deaktivieren, um Konflikte zu vermeiden!
