Du hast deinen Node eingerichtet, dich mit dem Standardkanal verbunden und angefangen, Nachrichten zu senden. Es fühlt sich privat an: kein Mobilfunkanbieter, kein Server, kein mit deinem Namen verknüpftes Konto. Aber „off-grid“ ist nicht dasselbe wie „privat“, und die Meshtastic-Dokumentation selbst spricht offen darüber, wo hier die Grenze verläuft. Hier erfährst du, was tatsächlich verschlüsselt ist, was nicht und was du ändern solltest, wenn dir Privatsphäre wichtig ist.
## Kanäle: verschlüsselt, aber nur so privat wie der Schlüssel
Jeder Meshtastic-Kanal wird mit einem vorab geteilten Schlüssel (PSK) mittels AES256-CTR verschlüsselt. Dieser Teil ist solide; AES256 gilt als quantenresistent und niemand knackt das durch Brute-Force. Der Haken ist nicht der Algorithmus, sondern der Schlüssel.
Ab Werk tritt jedes Gerät demselben Standardkanal bei, LongFast, und verwendet denselben öffentlich bekannten Schlüssel: `AQ==` (die Base64-Form eines einzelnen Bytes, `0x01`). Dieser Schlüssel ist fest in den Quellcode der Meshtastic-Firmware eingebettet und auf jedem weltweit verkauften Standardgerät identisch. Er existiert absichtlich für die Erkennung und das Onboarding, damit Nodes von Fremden sich finden und Nachrichten füreinander weiterleiten können. Er war nie dazu gedacht, Inhalte privat zu halten.
Das Ergebnis: Nachrichten auf LongFast sind zwar technisch verschlüsselt, aber praktisch öffentlich. Jeder, der ein Meshtastic-Funkgerät in Reichweite hat oder den Firmware-Quellcode gelesen hat – also wir alle –, kann alles entschlüsseln, was dort gesendet wird.
**Die Lösung ist einfach:** Erstelle deinen eigenen Kanal mit einem zufällig generierten AES256-Schlüssel, gib ihm einen Namen, den nur deine Gruppe kennt, und teile die Einladung (QR-Code oder Schlüssel) „out-of-band“ persönlich, über Signal oder einen anderen Weg, der nicht das Mesh selbst ist. In der offiziellen App erscheint dies als grünes Schloss-Symbol, sobald es sich um einen Nicht-Standard-Schlüssel handelt. Diese eine Änderung ist das größte Privatsphäre-Upgrade, das jedem Meshtastic-Nutzer zur Verfügung steht.
## Direktnachrichten: besser als früher
Frühe Meshtastic-DMs waren lediglich kanalverschlüsselte Nachrichten, die an einen bestimmten Node adressiert waren; jeder mit dem Kanal-PSK konnte sie technisch lesen. Firmware 2.5 hat dies mit einem echten Upgrade behoben: Direktnachrichten und Admin-Nachrichten (die Befehle zur Fernkonfiguration eines Nodes) verwenden nun Public-Key-Kryptographie, einen x25519-Schlüsselaustausch kombiniert mit AES-CCM, zwischen zwei Nodes, auf denen 2.5.0 oder neuer läuft.
Dies bietet dir drei Dinge, die das alte System nicht hatte: Vertraulichkeit, Authentifizierung (du weißt, dass die Nachricht tatsächlich von diesem Node stammt) und Integrität (sie wurde während der Übertragung nicht verändert) – aber nur, sobald beide Nodes öffentliche Schlüssel ausgetauscht haben. Wenn du oder die Person, der du schreibst, noch eine ältere Firmware nutzt oder noch keine Schlüssel ausgetauscht habt, gilt diese Garantie nicht.
Ein Vorbehalt, den man kennen sollte: Der Schlüsselaustausch selbst vertraut dem öffentlichen Schlüssel, den eine Node-Nummer zuerst ankündigt, ein Modell namens „Trust On First Use“ (TOFU). Es gibt keine zentrale Instanz, die Schlüssel signiert. Wenn ein Angreifer also eine Node-Nummer imitiert, bevor der echte Besitzer dies tut, vertrauen spätere Austausche dem falschen Schlüssel. Für die meisten Hobby- und Community-Anwendungen ist dies ein geringfügiges theoretisches Risiko; für alles Sensible sollte man sich dessen bewusst sein.
## Was niemals verschlüsselt ist, egal was du tust
Dies ist der Teil, den die Leute übersehen. Jedes Meshtastic-Paket hat einen Header, der konstruktionsbedingt im Klartext übertragen wird, da relayende Nodes ihn lesen müssen, um das Paket weiterzuleiten: Absender-ID, Ziel-ID, Paket-ID, Hop-Limit und Kanal-Hash. Die Verschlüsselung schützt die Nutzlast, nicht die Metadaten.
In der Praxis bedeutet das: Jeder mit einem Funkgerät und einem Laptop kann sehen, wer mit wem spricht, wie oft und ungefähr wo (über Signalstärke und mehrere Empfangspunkte), selbst wenn er kein einziges Wort der eigentlichen Nachricht lesen kann. Wenn dein Bedrohungsmodell jemanden umfasst, den deine Bewegungsmuster oder dein Kontaktnetzwerk interessieren, nicht nur dein Nachrichteninhalt, dann löst Verschlüsselung allein das Problem nicht – das tun betriebliche Gewohnheiten (regelmäßiges Ändern der Node-Namen, Begrenzung der Übertragungshäufigkeit, bewusste Auswahl, wer sich auf deinem privaten Kanal befindet).
## Ein kurzer Realitätscheck zur Quantenresistenz
AES256, das für die Kanalverschlüsselung verwendet wird, gilt allgemein als sicher gegen zukünftige Quantencomputer. Der x25519-Schlüsselaustausch, der für die DM-Authentifizierung verwendet wird, ist dies nicht. Das trifft jedoch auf fast die gesamte heute verwendete Public-Key-Kryptographie zu, und aktuelle post-quanten-sichere Verfahren passen nicht in ein LoRa-Paket und laufen nicht auf den stromsparenden Mikrocontrollern, die Meshtastic-Geräte verwenden. Es ist ein bekannter, dokumentierter Kompromiss, kein Versehen, und kein Grund, auf die Funktion zu verzichten.
## Praktische Checkliste
Wenn du heute einen Node einrichtest, ist das hier entscheidend:
- Aktualisiere jeden Node, den du kontrollierst, auf Firmware 2.5 oder höher, damit DMs und Admin-Befehle den Schutz durch Public-Key-Kryptographie erhalten anstelle des alten PSK-Systems.
- Erstelle einen privaten Kanal mit einem zufällig generierten AES256-Schlüssel für alles, was nicht für die Öffentlichkeit bestimmt ist. Behalte LongFast nur für die Erkennung bei.
- Teile Kanalschlüssel „out-of-band“ mit, sende niemals den Schlüssel eines neuen Kanals über das Mesh selbst oder über LongFast.
- Denke daran, dass Header immer sichtbar sind. Gehe nicht davon aus, dass „verschlüsselt“ auch „unverfolgbar“ bedeutet.
- Wenn du vermutest, dass ein Kanalschlüssel kompromittiert wurde, generiere ihn neu und verteile ihn erneut. Es gibt keinen Widerrufmechanismus, ein kompromittierter Schlüssel bleibt es, bis du ihn änderst.
## Wo man anfangen sollte
Jedes von uns geführte, Meshtastic-fähige Gerät, [WisMesh Pocket V2], [Heltec V3/V4] und die [RAKwireless WisBlock]-Reihe, wird so ausgeliefert, dass es die neueste Firmware ausführen kann. Die oben genannten 2.5+-Schutzmaßnahmen sind also nur ein Firmware-Update entfernt, falls noch nicht geschehen. Wenn du ein privates Mesh für ein Team, eine Familie oder eine Veranstaltung aufbaust, nimm dir fünf Minuten Zeit, um deinen eigenen Kanalschlüssel zu erstellen, bevor du das erste Gerät ausgibst – es ist das günstigste Sicherheits-Upgrade, das du jemals machen wirst.
