Die Sicherheitsarchitektur von Remio, unverblümt dargestellt.

§01 · Zusammenfassung

Remio ist eine Remote-Desktop-Anwendung, die auf einer Zero-Knowledge-Peer-to-Peer-Architektur aufbaut. Bildschirminhalte, Eingabedaten und Audio-Streams sind zwischen den Geräten mit dem branchenüblichen DTLS-SRTP Ende-zu-Ende-verschlüsselt — dem Sicherheitsmodell, auf das sich jedes WebRTC-basierte Produkt stützt. Anders als zentralisierte Lösungen hilft der Signalisierungsserver von Remio nur beim anfänglichen Verbindungsaufbau — er sieht, verarbeitet oder speichert nie Sitzungsdaten.

Es sind keine Konten erforderlich, keine Passwörter, in die man einbrechen könnte, keine zentrale Datenbank mit Zugangsdaten. Die Gerätekopplung nutzt sechsstellige Codes, die vom eigenen Bildschirm des Hosts abgelesen werden, und alle Sitzungsschlüssel sind flüchtig und mit Perfect Forward Secrecy versehen: Selbst wenn ein Schlüssel kompromittiert wird, bleiben vergangene und künftige Sitzungen kryptografisch sicher. Diese Architektur schließt ganze Kategorien von Angriffen aus, die Mitbewerber geplagt haben — weil es schlicht nichts zu stehlen gibt.

§02 · Bedrohungsmodell

Die Sicherheitsarchitektur von Remio ist gegen eine Reihe von Bedrohungsszenarien entworfen, die für die Nutzung von Remote Desktop im Unternehmen wie im privaten Umfeld relevant sind. Wir sind ausdrücklich darin, wovor wir schützen und wo die Vertrauensgrenzen verlaufen.

Bedrohungen, vor denen wir schützen

• Abhören. Alle Medien (Video, Audio) und Datenkanäle (Eingabe, Tastatur, Mauszeiger) sind mit SRTP beziehungsweise DTLS verschlüsselt. Ein Beobachter im Netzwerk sieht nur verschlüsselte Pakete und kann Sitzungsinhalte nicht rekonstruieren.
• Man-in-the-Middle (MITM). Der DTLS-Handschlag mit Prüfung des Zertifikat-Fingerabdrucks verhindert ein Abfangen. Der Signalisierungskanal nutzt TLS 1.3 mit Perfect Forward Secrecy.
• Kompromittierung des Servers. Selbst wenn unser Signalisierungsserver vollständig kompromittiert wird, erhalten Angreifer nur Zugriff auf Verbindungsmetadaten (IP-Adressen, Zeitstempel). Sitzungsinhalte werden nie über unsere Server übertragen oder darauf gespeichert.
• Unbefugter Zugriff. Die Kopplung per PIN erfordert physische Nähe oder die Kenntnis einer angezeigten PIN. Es gibt keine aus der Ferne erreichbare Datenbank mit Zugangsdaten, die man angreifen könnte.
• Diebstahl von Zugangsdaten. Keine Passwörter, keine Konten, kein zentraler Speicher für Zugangsdaten. Das Gerätevertrauen entsteht durch die PIN-Kopplung; Sitzungstoken (JWT) sind kurzlebig und an das Gerät gebunden.
• Wiedereinspielen von Sitzungen. Der in SRTP eingebaute Schutz vor Wiedereinspielung und die Sequenznummern von DTLS verhindern, dass abgefangene Pakete erneut eingespielt werden.
• Angriffe auf die Lieferkette. Alle Programmdateien von Remio sind codesigniert. macOS-Builds werden von Apple notarisiert. iOS-Builds werden ausschließlich über den App Store verteilt.

Vertrauensgrenzen

Unser Bedrohungsmodell legt ausdrücklich drei Vertrauensgrenzen fest:

1. Gerätegrenze. Jedem Gerät wird erst nach der PIN-Prüfung vertraut. Schutzmechanismen auf Ebene des Betriebssystems (Sandboxing, Schlüsselbund, Secure Enclave) schützen die Daten auf dem Gerät.
2. Netzwerkgrenze. Alle Daten auf dem Transportweg sind verschlüsselt. Wir gehen davon aus, dass das Netzwerk feindlich ist.
3. Servergrenze. Unsere eigenen Server gelten als nicht vertrauenswürdige Relays. Sie vermitteln Verbindungen, können aber Inhalte nicht einsehen.

§03 · Überblick über die Architektur

Remio trennt die Signalisierungsebene (Verbindungsaufbau) von der Datenebene (Streaming). Diese Trennung ist grundlegend für unseren Zero-Knowledge-Entwurf — der Server, der Ihnen beim Verbinden hilft, berührt nie die Daten, die Sie austauschen.

Signalisierung gegenüber Datenebene

Die einzige Aufgabe des Signalisierungsservers ist es, beim Verbindungsaufbau SDP-Offer/Answer und ICE-Kandidaten zwischen Geräten weiterzuleiten. Sobald die P2P-Verbindung steht, ist der Signalisierungsserver nicht mehr beteiligt.

Der Server kann den weitergeleiteten Inhalt nicht auswerten — er ist ein verschlüsselter binärer Blob, den nur das Zielgerät interpretieren kann. Das binäre Protokoll fügt eine zusätzliche Schicht an Struktur hinzu, die Injektionsangriffe im Vergleich zu einer Signalisierung auf JSON-Basis erschwert.

§04 · Verschlüsselungsschichten

Remio setzt auf eine mehrschichtige Verschlüsselungsstrategie, bei der jeder Kommunikationskanal das kryptografische Protokoll nutzt, das seinen Anforderungen am besten entspricht.

Perfect Forward Secrecy

Jede Remio-Sitzung erzeugt über den ECDHE-Schlüsselaustausch einen eigenen Satz flüchtiger Verschlüsselungsschlüssel.

• Die Kompromittierung des aktuellen Sitzungsschlüssels legt vergangene Sitzungen nicht offen.
• Die Kompromittierung des aktuellen Sitzungsschlüssels legt künftige Sitzungen nicht offen.
• Jedes Schlüsselpaar existiert nur für die Dauer einer einzelnen Sitzung.
• Schlüssel werden nie auf die Festplatte geschrieben — sie existieren nur im Arbeitsspeicher.

Cipher Suites

# Signalisierung — TLS-1.3-Cipher-Suites (in der Reihenfolge der Präferenz)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Medien — SRTP-Schutzprofil (Branchenstandard bei WebRTC)
SRTP_AES128_CM_SHA1_80   # AES-128 im Zählermodus, Authentifizierung mit HMAC-SHA1-80

# DTLS-Zertifikate
Selbstsigniertes ECDSA (P-256), außerhalb des Kanals über SDP-Fingerabdrücke geprüft

Schlüsselrotation

Schlüssel werden an den folgenden Grenzen automatisch rotiert:

• Sitzungsstart. Ein neuer DTLS-Handschlag erzeugt für jede Verbindung frische Schlüssel.
• SRTP-Schlüsselableitung. Medienschlüssel werden aus dem DTLS-Handschlag abgeleitet und sind pro Medienspur einzigartig.
• Wiederverbindung. Wird eine Sitzung unterbrochen und wieder verbunden, findet ein vollständig neuer Schlüsselaustausch statt.

§05 · Authentifizierung und Kopplung

Remio vermeidet bewusst die klassische Authentifizierung mit Benutzername und Passwort. Stattdessen nutzen wir ein Modell der Gerätekopplung per PIN, das die häufigsten Angriffswege in Remote-Desktop-Software beseitigt.

Kopplung per PIN

Wenn sich ein Client zum ersten Mal mit einem Host verbinden will, läuft der Vorgang so ab:

1. Der Host zeigt eine kurze numerische PIN auf seinem Bildschirm an (oder als QR-Code).
2. Der Client gibt die PIN ein, die über den Signalisierungskanal an den Host gesendet wird.
3. Der Host prüft die PIN und bestätigt oder lehnt die Kopplung ab.
4. Bei Erfolg wird eine Vertrauensbeziehung zwischen den Geräten hergestellt.
5. Spätere Verbindungen desselben Geräts erfordern keine erneute Kopplung.

Modell des Gerätevertrauens

Nach der Kopplung wird jedes Gerät durch eine eindeutige Geräte-ID identifiziert. Der Host führt eine lokale Liste vertrauenswürdiger Geräte. Diese Vertrauensbeziehung ist:

• Lokal gespeichert, nur auf dem Host-Gerät, im Schlüsselbund des Betriebssystems.
• Nie übertragen — der Server weiß nicht, welchen Geräten vertraut wird.
• Widerrufbar — der Host kann ein vertrauenswürdiges Gerät jederzeit entfernen.

Sitzungstoken (JWT)

Nach der Kopplung werden kurzlebige signierte Token (Ablauf nach 24 Stunden) für die Authentifizierung am Signalisierungsserver genutzt.

Diese Token authentifizieren ein Gerät am Signalisierungsserver für das Erstellen von Räumen und das Weiterleiten von Nachrichten. Sie gewähren keinen Zugriff auf Sitzungsinhalte, die durch einen eigenen DTLS-Handschlag geschützt sind.

Zugriff für KI-Agenten (Remio MCP Server)

Remio dehnt dasselbe Vertrauensmodell auf KI-Agenten aus. Werkzeuge wie Claude Code, Codex oder die Claude-App können Ihre Rechner über den Remio MCP Server aus der Ferne bedienen — und die Sicherheitsgrenze ist identisch mit der, die ein menschlicher Client überschreitet:

• Alles ist durch Ihre Anmeldung abgesichert. Ein Agent kann nur Hosts erreichen, die online und mit dem Konto gekoppelt sind, mit dem Sie sich authentifiziert haben (Anmeldung mit Google oder Apple, über OAuth). Kein authentifiziertes Konto, keine Werkzeuge.
• Remio ist ein Vermittler, kein Bediener. Die einzige Aufgabe des MCP-Servers ist es, eine Reihe von Werkzeugen bereitzustellen, die auf Ihr authentifiziertes Konto zugeschnitten sind, und sie dem KI-Werkzeug zu übergeben, das Sie verbinden wollten. Remio kann von sich aus keine Sitzung mit Ihrem Rechner starten — ein Host nimmt nur Verbindungen an, die den Nachweis der Autorisierung Ihres Kontos vorlegen, genau wie beim oben beschriebenen Modell des Gerätevertrauens.
• Derselbe verschlüsselte Transport. Agentensitzungen laufen über dieselben Ende-zu-Ende-verschlüsselten Kanäle, die in §04 beschrieben sind. Unsere Server sehen weiterhin nur verschlüsselte Blobs — die Zero-Knowledge-Eigenschaften in §06 gelten unverändert.
• Sichtbar, abbrechbar, protokolliert. Eine Agentensitzung wird am Host angezeigt, solange sie läuft, lässt sich mit einem Notausschalter sofort beenden und wird in einem lokalen Protokoll aufgezeichnet.

§06 · Zero-Knowledge-Entwurf

Zero-Knowledge ist bei Remio kein Marketingbegriff — es ist eine architektonische Randbedingung. Unsere Systeme sind so entworfen, dass Sitzungsinhalte für Remio, seine Mitarbeiter oder jeden Dritten strukturell unzugänglich sind.

Was unsere Server sehen können

• IP-Adressen der sich verbindenden Geräte (für die Vernetzung erforderlich).
• Zeitstempel der Verbindungen.
• Geräte-IDs (undurchsichtige Kennungen, nicht an personenbezogene Daten gebunden).
• Signalisierungsmetadaten: Austausch von SDP-Offer/Answer, ICE-Kandidaten.

Was unsere Server nicht sehen können

• Bildschirminhalte — Videobilder sind mit SRTP Ende-zu-Ende-verschlüsselt.
• Audio — dieselbe SRTP-Verschlüsselung wie beim Video.
• Eingabeereignisse — Maus, Tastatur, Touch sind DTLS-verschlüsselt.
• Mauszeigerposition — über den verschlüsselten Datenkanal übertragen.
• Dateiinhalte — jede Dateiübertragung läuft über verschlüsselte Kanäle.
• Daten der Zwischenablage — verschlüsselter Datenkanal.
• Anwendungszustand — welche Apps Sie ausführen, woran Sie arbeiten.

Richtlinie zur Datenaufbewahrung

Aufgrund unserer P2P-Architektur gibt es faktisch nichts aufzubewahren:

• Sitzungsinhalte. Nie gespeichert. Nur Echtzeit-Stream.
• Signalisierungsprotokolle. Verbindungsmetadaten werden bis zu 30 Tage zur Fehlersuche aufbewahrt, dann gelöscht. Sie enthalten keine Sitzungsinhalte.
• Nutzerkonten. Keine Konten erforderlich. Optionale Daten von Firebase Auth werden von der Infrastruktur von Google verwaltet und können vom Nutzer gelöscht werden.
• Geräteinformationen. Auf jedem Gerät lokal gespeichert. Wenn Sie sich anmelden, wird Ihre Geräteliste mit Ihrem Konto synchronisiert (siehe die Datenschutzerklärung).

P2P-orientierter Datenfluss

Bei der Mehrheit der Verbindungen (wo NAT-Traversal gelingt) fließen die Daten direkt zwischen den Geräten, ohne einen Server zu berühren:

# Bestfall: direktes P2P
Client <—— DTLS-SRTP (verschlüsselt) ——> Host
              ↑ Kein Server beteiligt

# Rückfall: TURN-Relay
Client <— DTLS-SRTP —> TURN-Server <— DTLS-SRTP —> Host
                            ↑ Weiterhin Ende-zu-Ende-verschlüsselt
                            ↑ Server sieht nur verschlüsselte Blobs

Selbst im Rückfallszenario über das TURN-Relay verarbeitet der Relay-Server nur verschlüsselte Pakete. Er arbeitet als dummes Rohr — er kann die Daten weder entschlüsseln noch einsehen noch verändern.

§07 · Netzwerksicherheit

Aufbau der P2P-Verbindung

Remio nutzt das Protokoll ICE (Interactive Connectivity Establishment), um den bestmöglichen Verbindungspfad zwischen Geräten zu finden:

1. Host-Kandidaten — direkte LAN-Verbindung im selben Netzwerk.
2. Server-reflexive Kandidaten (STUN) — NAT-Traversal über STUN-Server, um die öffentliche IP zu ermitteln.
3. Relay-Kandidaten (TURN) — verschlüsseltes Relay, wenn sich keine direkte Verbindung herstellen lässt.

Der ICE-Agent prüft alle Kandidatenpaare gleichzeitig und wählt den Pfad mit der niedrigsten Latenz und der höchsten Zuverlässigkeit. Direktes P2P wird immer bevorzugt.

Konfigurierbare Transportrichtlinien

Verbindungen bevorzugen standardmäßig direktes P2P mit automatischem Rückfall auf das verschlüsselte Relay. Strengere Richtlinien — den gesamten Datenverkehr über das Relay zu zwingen oder die LAN-Erkennung ganz zu überspringen — stehen für abgeriegelte Netzwerkumgebungen zur Verfügung.

Begrenzung der Anfragerate

Der Signalisierungsserver setzt eine strikte Begrenzung der Anfragerate ein, um Missbrauch zu verhindern:

Abgelaufene Ratenbegrenzer werden in einem Intervall von 5 Minuten mit einer TTL von 10 Minuten automatisch bereinigt, was die Erschöpfung des Arbeitsspeichers durch verteilte Angriffe verhindert.

DDoS-Schutz

Unsere Signalisierungsinfrastruktur wird von Cloudflare geschützt, was Folgendes bietet:

• Anycast-DNS mit einem globalen Edge-Netzwerk.
• DDoS-Abwehr auf den Schichten 3, 4 und 7.
• Web Application Firewall (WAF).
• Ratenbegrenzung am Rand, bevor der Datenverkehr den Ursprungsserver erreicht.
• Bot-Erkennung und Challenge-Seiten.

§08 · Client-Sicherheit

Remio nutzt den vollständigen Sicherheits-Stack jedes Betriebssystems, um lokale Daten zu schützen und die Integrität der Anwendung sicherzustellen.

macOS

• Anbindung an den Schlüsselbund. Alle sensiblen Daten (Vertrauenstoken der Geräte, JWT) werden im macOS-Schlüsselbund gespeichert, geschützt durch die Anmeldedaten des Nutzers und Hardware-Verschlüsselung.
• App-Sandbox. Remio läuft in einer Sandbox-Umgebung mit minimalen Berechtigungen. Bildschirmaufnahme und Bedienungshilfen erfordern die ausdrückliche Zustimmung des Nutzers.
• Codesignierung. Alle Builds sind mit Apple-Developer-Zertifikaten signiert.
• Notarisierung. macOS-Builds werden von Apple notarisiert, was bestätigt, dass sie frei von bekannter Schadsoftware sind.
• Hardened Runtime. Verhindert Code-Injektion, das Kapern von Bibliotheken und Debugging in Produktions-Builds.

iOS

• App Transport Security (ATS). Alle Netzwerkverbindungen müssen HTTPS/TLS nutzen. Keine Ausnahmen konfiguriert.
• Secure Enclave. Wo verfügbar, werden kryptografische Schlüssel in der Secure-Enclave-Hardware erzeugt und gespeichert.
• Keychain Services. Geräte-Zugangsdaten werden im iOS-Schlüsselbund mit der Schutzklasse kSecAttrAccessibleWhenUnlockedThisDeviceOnly gespeichert.
• Prüfung durch den App Store. Alle iOS-Builds durchlaufen das Sicherheitsprüfverfahren von Apple.
• Keine Hintergrunddaten. Die App erhebt oder überträgt keine Daten, wenn sie im Hintergrund ist.

Codesignierung & Verifizierung

# Die macOS-Binärdatei von Remio prüfen — verify_signature.sh
$ codesign --verify --deep --strict "Remio Host.app"
# Remio Host.app: valid on disk

$ spctl --assess --verbose "Remio Host.app"
# Remio Host.app: accepted
# source=Notarized Developer ID

§09 · Reaktion auf Sicherheitsvorfälle

Sicherheitsbilanz

Stand Februar 2026 hat Remio keine Geschichte von Sicherheitseinbrüchen oder -vorfällen. Unsere Zero-Knowledge-Architektur verkleinert die Angriffsfläche erheblich — es gibt keine zentrale Datenbank mit Zugangsdaten oder Sitzungsdaten, auf die man es abgesehen haben könnte.

Meldung von Schwachstellen

Wir befürworten verantwortungsvolle Offenlegung durch Sicherheitsforscher. Wenn Sie eine mögliche Schwachstelle entdecken:

1. Schreiben Sie eine E-Mail an [email protected] mit einer detaillierten Beschreibung.
2. Fügen Sie, falls zutreffend, Schritte zur Reproduktion bei.
3. Wir bestätigen den Eingang innerhalb von 48 Stunden.
4. Wir streben an, bestätigte Schwachstellen innerhalb von 30 Tagen zu beheben.
5. Meldende werden in unserem Sicherheits-Änderungsprotokoll genannt, es sei denn, sie bevorzugen Anonymität.

Richtlinie zur verantwortungsvollen Offenlegung

• Wir bitten um ein Offenlegungsfenster von 90 Tagen vor der öffentlichen Bekanntgabe.
• Wir verfolgen Forscher, die in gutem Glauben handeln, nicht rechtlich.
• Wir priorisieren Korrekturen nach Schweregrad: kritisch, hoch, mittel, niedrig.
• Ein förmliches Bug-Bounty-Programm steht auf unserer Roadmap.

Ablauf der Reaktion auf Vorfälle

Im Falle eines bestätigten Sicherheitsproblems:

1. Eindämmung. Betroffene Systeme innerhalb von 1 Stunde isolieren.
2. Bewertung. Umfang und Auswirkungen innerhalb von 24 Stunden bestimmen.
3. Kommunikation. Betroffene Nutzer innerhalb von 72 Stunden benachrichtigen (DSGVO-konform).
4. Behebung. Patches über die Infrastruktur für automatische Updates ausrollen.
5. Nachbesprechung. Einen Transparenzbericht veröffentlichen.

§10 · Compliance

Bereitschaft für die DSGVO

Remios Zero-Knowledge-Architektur ist von Natur aus DSGVO-freundlich, weil wir die Datenerhebung auf das absolute technische Minimum beschränken:

• Datenminimierung. Wir erheben nur, was für den Verbindungsaufbau notwendig ist.
• Recht auf Löschung. Da wir keine Nutzerinhalte speichern, gibt es nichts zu löschen. Optionale Kontodaten können auf Anfrage gelöscht werden.
• Datenübertragbarkeit. Daten zum Gerätevertrauen werden lokal gespeichert und vom Nutzer kontrolliert.
• Einwilligung. Die Kopplung per PIN ist ein ausdrücklicher Einwilligungsmechanismus für jedes Gerät.
• Keine grenzüberschreitende Übermittlung von Inhalten. P2P-Verbindungen halten die Daten zwischen den Geräten; sie gelangen nie in unsere Infrastruktur.

Roadmap zu SOC 2

Geplante Compliance-Meilensteine

• Unabhängiges Sicherheitsaudit — professionelle Penetrationstests und Code-Review, für 2026 geplant.
• SOC 2 Type I — erste Bewertung der organisatorischen Kontrollen.
• SOC 2 Type II — fortlaufende Überprüfung der Compliance.
• Bug-Bounty-Programm — förmliche Belohnungen für verantwortungsvolle Offenlegung.

Datenresidenz

Weil Remio P2P-orientiert ist, liegen Sitzungsdaten dort, wo Ihre Geräte sind. Ihre Daten verlassen nie die direkte Verbindung zwischen Ihren Geräten. Der Signalisierungsserver (gehostet bei Cloudflare und DigitalOcean) verarbeitet nur Verbindungsmetadaten — und diese Metadaten sind an keine personenbezogenen Daten gebunden.

§11 · Vergleich mit Alternativen

Die Remote-Desktop-Branche wurde von aufsehenerregenden Sicherheitseinbrüchen geplagt. So unterscheidet sich die Architektur von Remio grundlegend von zentralisierten Alternativen.

Warum zentralisierte Architekturen scheitern

Das grundlegende Problem zentralisierter Remote-Desktop-Dienste ist, dass ein einziger Einbruch alle Nutzer gefährden kann. Als die Produktivserver von AnyDesk im Februar 2024 geknackt wurden, stahlen Angreifer Zertifikate zur Codesignierung, womit sie womöglich Schadsoftware als legitime AnyDesk-Software getarnt verteilen konnten. Alle Passwörter der Nutzer mussten zurückgesetzt werden.

Als APT29 (eine staatlich unterstützte russische Gruppe) im Juni 2024 das Firmennetzwerk von TeamViewer knackte, warf das Fragen zur Integrität des Produkts selbst auf — denn eine zentralisierte Architektur bedeutet, dass der Anbieter technisch in der Lage ist, auf Sitzungen zuzugreifen.

Remio schließt diese Angriffsklasse vollständig aus. Ein Einbruch in unseren Signalisierungsserver liefert nur Verbindungsmetadaten. Es gibt keine Zugangsdaten zu stehlen, keine Sitzungen, auf die man zugreifen könnte, keine Zertifikate, mit denen sich Schadsoftware signieren ließe, die auf die Geräte unserer Nutzer zielt.

§12 · Fazit

Die Sicherheit von Remio ist keine Reihe von Funktionen, die an ein Produkt drangeschraubt wurden — sie ist die Folge von Architekturentscheidungen vom ersten Tag an. Indem wir P2P statt zentralisiert, Kopplung per PIN statt Passwörtern und Zero-Knowledge statt Datenerhebung gewählt haben, haben wir einen Remote Desktop gebaut, bei dem Sicherheit der Standardzustand ist, kein optionales Upgrade.

Wir glauben, dass Datenschutz nicht optional ist und dass Vertrauen durch Transparenz verdient werden sollte, nicht durch Nutzungsbedingungen eingefordert. Dieses Whitepaper ist Teil dieser Verpflichtung.

Für Fragen, Sicherheitsprüfungen im Unternehmen oder um eine Schwachstelle zu melden:

• Sicherheitsanfragen: [email protected]
• Vertrieb für Unternehmen: [email protected]
• Allgemein: [email protected]