De beveiligingsarchitectuur van Remio, in duidelijke taal.

§01 · Samenvatting

Remio is een applicatie voor extern bureaublad, gebouwd op een zero-knowledge, peer-to-peer-architectuur. Scherminhoud, invoergegevens en audiostreams zijn end-to-end-versleuteld tussen apparaten met het standaard DTLS-SRTP — hetzelfde beveiligingsmodel waarop elk op WebRTC gebaseerd product leunt. Anders dan gecentraliseerde oplossingen helpt de signaleringsserver van Remio alleen bij het opzetten van de eerste verbinding — hij ziet, verwerkt of bewaart nooit sessiegegevens.

Er is geen account nodig, er zijn geen wachtwoorden om in te breken en geen centrale database met inloggegevens. Het koppelen van apparaten gaat met een QR-code of een apparaat-ID en pincode die van het eigen scherm van de host worden afgelezen, en alle sessiesleutels zijn kortstondig met Perfect Forward Secrecy: ook als een sleutel is gecompromitteerd, blijven eerdere en toekomstige sessies cryptografisch veilig. Deze architectuur sluit hele categorieën aanvallen uit die concurrenten hebben geteisterd — omdat er simpelweg niets te stelen is.

§02 · Dreigingsmodel

De beveiligingsarchitectuur van Remio is ontworpen tegen een reeks dreigingsscenario's die relevant zijn voor het gebruik van extern bureaublad, zowel in zakelijke als in persoonlijke context. We zijn duidelijk over waartegen we beschermen en waar de vertrouwensgrenzen liggen.

Dreigingen waartegen we beschermen

• Afluisteren. Alle media (video, audio) en datakanalen (invoer, toetsenbord, cursor) zijn versleuteld met respectievelijk SRTP en DTLS. Een waarnemer op het netwerk ziet alleen versleutelde pakketten en kan de sessie-inhoud niet reconstrueren.
• Man-in-the-middle (MITM). Een DTLS-handdruk met controle van de vingerafdruk van het certificaat voorkomt onderschepping. Het signaleringskanaal gebruikt TLS 1.3 met Perfect Forward Secrecy.
• Compromittering van de server. Zelfs als onze signaleringsserver volledig gecompromitteerd is, krijgen aanvallers alleen toegang tot verbindingsmetagegevens (ip-adressen, tijdstempels). Sessie-inhoud wordt nooit via onze servers verzonden of erop opgeslagen.
• Onbevoegde toegang. Koppelen vereist het scannen van de QR-code van de host, het typen van het apparaat-ID en de pincode die hij toont, of inloggen op hetzelfde Remio-account op beide apparaten. Er bestaat geen op afstand toegankelijke database met inloggegevens om aan te vallen.
• Diefstal van inloggegevens. Geen wachtwoorden, geen accounts, geen centrale opslag van inloggegevens. Vertrouwen in een apparaat wordt vastgesteld via koppelen met een pincode; sessietokens (JWT) zijn kortlevend en gebonden aan het apparaat.
• Herhalen van sessies. De ingebouwde bescherming tegen herhaling van SRTP en de volgnummers van DTLS voorkomen dat onderschepte pakketten opnieuw worden afgespeeld.
• Aanvallen op de toeleveringsketen. Alle Remio-binaries zijn voorzien van een codehandtekening. macOS-versies worden door Apple genotariseerd. iOS-versies worden uitsluitend via de App Store verspreid.

Vertrouwensgrenzen

Ons dreigingsmodel definieert uitdrukkelijk drie vertrouwensgrenzen:

1. Apparaatgrens. Elk apparaat wordt pas vertrouwd na verificatie van de pincode. Beveiliging op besturingssysteemniveau (sandboxing en de beschermde opslag van elk systeem, zoals de Sleutelhanger) beschermt gegevens op het apparaat.
2. Netwerkgrens. Alle gegevens tijdens het transport zijn versleuteld. We gaan ervan uit dat het netwerk vijandig is.
3. Servergrens. Onze eigen servers worden behandeld als onvertrouwde relays. Ze helpen verbindingen tot stand te brengen, maar kunnen de inhoud niet inzien.

§03 · Overzicht van de architectuur

Remio scheidt het signaleringsvlak (opzetten van verbindingen) van het datavlak (streaming). Deze scheiding is fundamenteel voor ons zero-knowledge-ontwerp — de server die je helpt te verbinden, komt nooit aan de gegevens die je uitwisselt.

Signalering versus datavlak

De enige taak van de signaleringsserver is het doorgeven van SDP-offers/answers en ICE-kandidaten tussen apparaten tijdens het opzetten van de verbinding. Zodra de P2P-verbinding er is, is de signaleringsserver niet meer betrokken.

De server kan de doorgegeven inhoud niet lezen — het is een versleutelde binaire blob die alleen het doelapparaat kan interpreteren. Het binaire protocol voegt een extra laag structuur toe die injectieaanvallen moeilijker maakt dan bij signalering op basis van JSON.

§04 · Versleutelingslagen

Remio gebruikt een meerlagige versleutelingsstrategie waarbij elk communicatiekanaal het cryptografische protocol gebruikt dat het best bij de eisen past.

Perfect forward secrecy

Elke Remio-sessie genereert via ECDHE-sleuteluitwisseling een unieke set kortstondige versleutelingssleutels.

• Het compromitteren van de huidige sessiesleutel maakt eerdere sessies niet toegankelijk.
• Het compromitteren van de huidige sessiesleutel maakt toekomstige sessies niet toegankelijk.
• Elk sleutelpaar bestaat alleen voor de duur van één sessie.
• Sleutels worden nooit op schijf opgeslagen — ze bestaan alleen in het geheugen.

Cipher suites

# Signalering — TLS 1.3-cipher suites (in volgorde van voorkeur)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Media — SRTP-beschermingsprofiel (standaard in de WebRTC-branche)
SRTP_AES128_CM_SHA1_80   # AES-128 in tellermodus, HMAC-SHA1-80-authenticatie

# DTLS-certificaten
Zelfondertekend ECDSA (P-256), buiten het kanaal geverifieerd via SDP-vingerafdrukken

Sleutelrotatie

Sleutels worden automatisch vernieuwd op de volgende momenten:

• Start van de sessie. Een nieuwe DTLS-handdruk genereert voor elke verbinding nieuwe sleutels.
• Afleiding van SRTP-sleutels. Mediasleutels worden afgeleid van de DTLS-handdruk en zijn uniek per mediaspoor.
• Opnieuw verbinden. Als een sessie wordt onderbroken en opnieuw verbonden, vindt een volledig nieuwe sleuteluitwisseling plaats.

§05 · Authenticatie en koppelen

Remio vermijdt bewust traditionele authenticatie met gebruikersnaam en wachtwoord. In plaats daarvan gebruiken we een model voor het koppelen van apparaten met een pincode dat de meest voorkomende aanvalswegen in software voor extern bureaublad wegneemt.

Koppelen met een pincode

Wanneer een client voor de eerste keer met een host wil verbinden, verloopt het proces als volgt:

1. De host toont een korte numerieke pincode op zijn scherm (of als QR-code).
2. De client voert de pincode in, die via het signaleringskanaal naar de host wordt gestuurd.
3. De host valideert de pincode en bevestigt of weigert het koppelen.
4. Bij succes wordt een vertrouwensrelatie tussen apparaten opgebouwd.
5. Latere verbindingen vanaf hetzelfde apparaat hoeven niet opnieuw te worden gekoppeld.

Vertrouwensmodel voor apparaten

Eenmaal gekoppeld wordt elk apparaat geïdentificeerd door een unieke apparaat-ID. De host houdt een lokale lijst met vertrouwde apparaten bij. Deze vertrouwensrelatie is:

• Lokaal opgeslagen op het hostapparaat alleen, in de beschermde opslag die het systeem biedt — de Sleutelhanger op een Mac, versleutelde systeemopslag op Windows, een privébestand op Linux.
• Nooit verzonden — de server weet niet welke apparaten worden vertrouwd.
• Herroepbaar — de host kan een vertrouwd apparaat op elk moment verwijderen.

Sessietokens (JWT)

Na het koppelen worden kortlevende ondertekende tokens (24 uur geldig) gebruikt voor authenticatie bij de signaleringsserver.

Deze tokens authenticeren een apparaat bij de signaleringsserver voor het aanmaken van kamers en het doorgeven van berichten. Ze geven geen toegang tot sessie-inhoud, die wordt beschermd door een aparte DTLS-handdruk.

Toegang voor AI-agents (Remio MCP Server)

Remio breidt dit zelfde vertrouwensmodel uit naar AI-agents. Tools als Claude Code, Codex of de Claude-app kunnen je machines op afstand bedienen via de Remio MCP Server — en de beveiligingsgrens is identiek aan die welke een menselijke client passeert:

• Alles wordt afgeschermd door je inlog. Een agent kan alleen hosts bereiken die online zijn en gekoppeld aan het account waarmee jij je hebt geauthenticeerd (inloggen met Google of Apple, via OAuth). Geen geauthenticeerd account, geen tools.
• Remio is een tussenpersoon, geen bediener. De enige taak van de MCP-server is een reeks tools beschikbaar te stellen die zijn afgebakend tot je geauthenticeerde account en ze over te dragen aan de AI-tool die jij hebt gekozen om te verbinden. Remio kan zelf geen sessie met je machine starten — een host accepteert alleen verbindingen die bewijs tonen van de autorisatie van je account, precies zoals in het vertrouwensmodel voor apparaten hierboven.
• Hetzelfde versleutelde transport. Agentsessies lopen over dezelfde end-to-end-versleutelde kanalen die in §04 zijn beschreven. Onze servers zien nog steeds alleen versleutelde blobs — de zero-knowledge-eigenschappen uit §06 gelden ongewijzigd.
• Zichtbaar, afbreekbaar, vastgelegd. Een agentsessie wordt op de host getoond zolang ze loopt, kan direct worden beëindigd met een noodschakelaar en wordt vastgelegd in een lokaal auditlogboek.

§06 · Zero-knowledge-ontwerp

Zero-knowledge is bij Remio geen marketingterm — het is een architectonische beperking. Onze systemen zijn zo ontworpen dat sessie-inhoud structureel ontoegankelijk is voor Remio, zijn medewerkers of welke derde dan ook.

Wat onze servers kunnen zien

• Ip-adressen van apparaten die verbinden (nodig voor netwerken).
• Tijdstempels van verbindingen.
• Apparaat-ID's (ondoorzichtige identificatiecodes, niet gekoppeld aan persoonlijke informatie).
• Signaleringsmetagegevens: SDP-offer/answer-uitwisseling, ICE-kandidaten.

Wat onze servers niet kunnen zien

• Schermmhoud — videoframes zijn end-to-end met SRTP versleuteld.
• Audio — dezelfde SRTP-versleuteling als video.
• Invoergebeurtenissen — muis, toetsenbord en aanraking zijn met DTLS versleuteld.
• Cursorpositie — verzonden via een versleuteld datakanaal.
• Bestandsinhoud — elke bestandsoverdracht verloopt via versleutelde kanalen.
• Klembordgegevens — versleuteld datakanaal.
• Status van apps — welke apps je draait en waar je aan werkt.

Beleid voor bewaartermijnen

Door onze P2P-architectuur valt er in feite niets te bewaren:

• Sessie-inhoud. Nooit opgeslagen. Alleen een stream in realtime.
• Signaleringslogboeken. Verbindingsmetagegevens worden tot 30 dagen bewaard voor foutopsporing en daarna verwijderd. Bevatten geen sessie-inhoud.
• Gebruikersaccounts. Geen accounts nodig. Optionele Firebase Auth-gegevens worden beheerd door de infrastructuur van Google en kunnen door de gebruiker worden verwijderd.
• Apparaatinformatie. Lokaal opgeslagen op elk apparaat. Als je ervoor kiest in te loggen, wordt je apparatenlijst gesynchroniseerd met je account (zie het privacybeleid).

P2P-eerst-gegevensstroom

Bij de meeste verbindingen (waar NAT traversal slaagt) stromen de gegevens rechtstreeks tussen apparaten zonder een server aan te raken:

# Beste geval: direct P2P
Client <—— DTLS-SRTP (versleuteld) ——> Host
              ↑ Geen server betrokken

# Terugval: TURN-relay
Client <— DTLS-SRTP —> TURN-server <— DTLS-SRTP —> Host
                            ↑ Nog steeds E2E-versleuteld
                            ↑ Server ziet alleen versleutelde blobs

Zelfs in het terugvalscenario met een TURN-relay verwerkt de relayserver alleen versleutelde pakketten. Hij werkt als een domme pijp — hij kan de gegevens niet ontsleutelen, inspecteren of wijzigen.

§07 · Netwerkbeveiliging

Opzetten van de P2P-verbinding

Remio gebruikt het ICE-protocol (Interactive Connectivity Establishment) om het best mogelijke verbindingspad tussen apparaten te vinden:

1. Hostkandidaten — directe verbinding via het lokale netwerk op hetzelfde netwerk.
2. Server-reflexive kandidaten (STUN) — NAT traversal via STUN-servers om het openbare ip-adres te ontdekken.
3. Relaykandidaten (TURN) — versleutelde relay wanneer geen directe verbinding kan worden gemaakt.

De ICE-agent test alle kandidaatparen tegelijk en kiest het pad met de laagste latentie en de grootste betrouwbaarheid. Direct P2P heeft altijd de voorkeur.

Configureerbaar transportbeleid

Verbindingen geven standaard de voorkeur aan direct P2P, met automatische terugval op de versleutelde relay. Strengere beleidsregels — al het verkeer door de relay forceren, of het ontdekken van het lokale netwerk helemaal overslaan — zijn beschikbaar voor afgeschermde netwerkomgevingen.

Beperking van het aantal verzoeken

De signaleringsserver past strenge beperkingen toe om misbruik te voorkomen:

Verlopen limieters worden automatisch opgeruimd met een interval van 5 minuten en een TTL van 10 minuten, zodat uitputting van het geheugen door gedistribueerde aanvallen wordt voorkomen.

DDoS-bescherming

Onze signaleringsinfrastructuur wordt beschermd door Cloudflare, dat zorgt voor:

• Anycast-DNS met een wereldwijd edge-netwerk.
• DDoS-bestrijding op laag 3, 4 en 7.
• Web Application Firewall (WAF).
• Beperking van het aantal verzoeken aan de edge voordat het verkeer de oorsprong bereikt.
• Detectie van bots en uitdagingspagina's.

§08 · Clientbeveiliging

Remio maakt gebruik van de volledige beveiligingsstack van elk besturingssysteem om lokale gegevens te beschermen en de integriteit van de applicatie te waarborgen.

macOS

• Integratie met de Sleutelhanger. Alle gevoelige gegevens (vertrouwenstokens van apparaten, JWT) worden opgeslagen in de macOS-Sleutelhanger, beschermd door de inloggegevens van de gebruiker en hardwareversleuteling.
• App Sandbox. Remio draait in een sandboxomgeving met minimale rechten. Schermopname en toegankelijkheid vereisen uitdrukkelijke goedkeuring van de gebruiker.
• Codehandtekening. Alle versies zijn ondertekend met Apple Developer-certificaten.
• Notarisatie. macOS-versies worden door Apple genotariseerd, wat bevestigt dat ze vrij zijn van bekende malware.
• Hardened runtime. Voorkomt code-injectie, het kapen van bibliotheken en debuggen in productieversies.

iOS

• App Transport Security (ATS). Alle netwerkverbindingen moeten HTTPS/TLS gebruiken. Er zijn geen uitzonderingen ingesteld.
• Gegevensbescherming. Items in de Sleutelhanger zijn versleuteld met sleutels die het apparaat uit zijn eigen hardware afleidt, en items die als alleen-dit-apparaat zijn gemarkeerd, verlaten het apparaat nooit, zelfs niet in een back-up.
• Keychain Services. Inloggegevens van apparaten worden opgeslagen in de iOS-Sleutelhanger met de beschermingsklasse kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly.
• Beoordeling door de App Store. Alle iOS-versies doorlopen het beveiligingsbeoordelingsproces van Apple.
• Geen gegevens op de achtergrond. De app verzamelt of verzendt geen gegevens wanneer hij op de achtergrond staat.

Codehandtekening & verificatie

# De macOS-binary van Remio verifiëren — 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 · Incidentafhandeling

Staat van dienst op het gebied van beveiliging

Sinds februari 2026 heeft Remio geen geschiedenis van beveiligingsinbreuken of -incidenten. Onze zero-knowledge-architectuur verkleint het aanvalsoppervlak aanzienlijk — er is geen centrale database met inloggegevens of sessiegegevens om op te richten.

Kwetsbaarheden melden

We moedigen verantwoorde bekendmaking door beveiligingsonderzoekers aan. Als je een mogelijke kwetsbaarheid ontdekt:

1. Mail security@remio.net met een gedetailleerde beschrijving.
2. Voeg indien van toepassing stappen toe om het te reproduceren.
3. We bevestigen de ontvangst binnen 48 uur.
4. We streven ernaar bevestigde kwetsbaarheden binnen 30 dagen op te lossen.
5. Melders worden vermeld in ons beveiligingslogboek met wijzigingen, tenzij ze liever anoniem blijven.

Beleid voor verantwoorde bekendmaking

• We vragen om een termijn van 90 dagen vóór openbare bekendmaking.
• We stellen geen juridische stappen in tegen onderzoekers die te goeder trouw handelen.
• We geven prioriteit aan oplossingen op basis van ernst: kritiek, hoog, gemiddeld, laag.
• Een formeel bugbountyprogramma staat op onze roadmap.

Proces voor incidentafhandeling

In het geval van een bevestigd beveiligingsprobleem:

1. Indamming. Getroffen systemen binnen 1 uur isoleren.
2. Beoordeling. Reikwijdte en impact binnen 24 uur vaststellen.
3. Communicatie. Getroffen gebruikers binnen 72 uur informeren (conform de AVG).
4. Herstel. Patches uitrollen via de infrastructuur voor automatische updates.
5. Evaluatie achteraf. Een transparantierapport publiceren.

§10 · Naleving

Gereedheid voor de AVG

De zero-knowledge-architectuur van Remio is van nature AVG-vriendelijk, omdat we de gegevensverzameling tot het absolute technische minimum beperken:

• Gegevensminimalisatie. We verzamelen alleen wat nodig is om een verbinding tot stand te brengen.
• Recht op wissing. Omdat we geen gebruikersinhoud opslaan, valt er niets te verwijderen. Optionele accountgegevens kunnen op verzoek worden verwijderd.
• Overdraagbaarheid van gegevens. Vertrouwensgegevens van apparaten worden lokaal opgeslagen en door de gebruiker beheerd.
• Toestemming. Koppelen met een pincode is een uitdrukkelijk toestemmingsmechanisme voor elk apparaat.
• Geen grensoverschrijdende doorgifte van inhoud. P2P-verbindingen houden gegevens tussen apparaten; ze komen nooit op onze infrastructuur.

SOC 2

Nog niet aanwezig

• Onafhankelijke beveiligingsaudit — er is nog geen penetratietest of codebeoordeling door een derde partij uitgevoerd.
• SOC 2 Type I — nog geen rapport.
• SOC 2 Type II — nog geen rapport.
• Bugbountyprogramma — formele beloningen voor verantwoorde bekendmaking.

Dataresidentie

Omdat Remio P2P-eerst is, staan sessiegegevens waar je apparaten staan. Je gegevens verlaten nooit de directe verbinding tussen je apparaten. De signaleringsserver (gehost bij Cloudflare en DigitalOcean) verwerkt alleen verbindingsmetagegevens — en die metagegevens zijn niet gekoppeld aan persoonlijke informatie.

§11 · Vergelijking met alternatieven

De branche van extern bureaublad is geteisterd door opzienbarende beveiligingsinbreuken. Zo verschilt de architectuur van Remio fundamenteel van gecentraliseerde alternatieven.

Waarom gecentraliseerde architecturen falen

Het fundamentele probleem met gecentraliseerde diensten voor extern bureaublad is dat één enkele inbreuk alle gebruikers kan treffen. Toen de productieservers van AnyDesk in februari 2024 werden gehackt, stalen aanvallers certificaten voor codehandtekeningen, waarmee ze mogelijk malware konden verspreiden vermomd als legitieme AnyDesk-software. Alle gebruikerswachtwoorden moesten worden gereset.

Toen APT29 (een door de Russische staat gesteunde groep) in juni 2024 het bedrijfsnetwerk van TeamViewer binnendrong, riep dat vragen op over de integriteit van het product zelf — omdat een gecentraliseerde architectuur betekent dat de leverancier technisch in staat is bij sessies te komen.

Remio sluit deze klasse aanvallen volledig uit. Een inbreuk op onze signaleringsserver levert alleen verbindingsmetagegevens op. Er zijn geen inloggegevens om te stelen, geen sessies om bij te komen, geen certificaten waarmee kwaadaardige software kan worden ondertekend die op de apparaten van onze gebruikers gericht is.

§12 · Conclusie

De beveiliging van Remio is geen verzameling functies die op een product is vastgeschroefd — ze is het gevolg van architectuurkeuzes die vanaf de eerste dag zijn gemaakt. Door te kiezen voor P2P in plaats van gecentraliseerd, koppelen met een pincode in plaats van wachtwoorden en zero-knowledge in plaats van gegevens verzamelen, hebben we een extern bureaublad gebouwd waarin beveiliging de standaardtoestand is, geen optionele upgrade.

We geloven dat privacy niet optioneel is en dat vertrouwen moet worden verdiend door transparantie, niet geëist via gebruiksvoorwaarden. Dit whitepaper is onderdeel van die toezegging.

Voor vragen, beveiligingsbeoordelingen voor het bedrijfsleven of om een kwetsbaarheid te melden:

• Vragen over beveiliging: security@remio.net
• Zakelijke verkoop: enterprise@remio.net
• Algemeen: hello@remio.net