L'architettura di sicurezza di Remio, spiegata con chiarezza.

§01 · Sintesi

Remio è un'applicazione di desktop remoto costruita su un'architettura peer-to-peer a conoscenza zero. Il contenuto dello schermo, i dati di input e i flussi audio sono cifrati end-to-end tra i dispositivi con DTLS-SRTP, lo standard del settore: lo stesso modello di sicurezza su cui si basa ogni prodotto basato su WebRTC. A differenza delle soluzioni centralizzate, il server di signaling di Remio si limita ad agevolare lo stabilirsi della connessione iniziale: non vede, non elabora e non conserva mai i dati della sessione.

Non è richiesto alcun account, non ci sono password da violare, non esiste un database centrale di credenziali. L'associazione dei dispositivi usa un codice QR oppure un ID dispositivo e un PIN letti sullo schermo dell'host stesso, e tutte le chiavi di sessione sono effimere con Perfect Forward Secrecy: anche se una chiave venisse compromessa, le sessioni passate e future restano al sicuro dal punto di vista crittografico. Questa architettura elimina intere categorie di attacchi che hanno afflitto i concorrenti, perché semplicemente non c'è nulla da rubare.

§02 · Modello delle minacce

L'architettura di sicurezza di Remio è progettata contro una serie di scenari di minaccia rilevanti per l'uso del desktop remoto sia in ambito aziendale sia personale. Siamo espliciti su ciò da cui ci proteggiamo e su dove si trovano i confini di fiducia.

Minacce da cui ci proteggiamo

• Intercettazione. Tutti i contenuti multimediali (video, audio) e i canali di dati (input, tastiera, cursore) sono cifrati rispettivamente con SRTP e DTLS. Un osservatore della rete vede solo pacchetti cifrati e non ha alcuna possibilità di ricostruire il contenuto della sessione.
• Attacco man-in-the-middle (MITM). La stretta di mano DTLS con verifica dell'impronta del certificato impedisce l'intercettazione. Il canale di signaling usa TLS 1.3 con Perfect Forward Secrecy.
• Compromissione del server. Anche se il nostro server di signaling fosse completamente compromesso, gli aggressori otterrebbero solo i metadati delle connessioni (indirizzi IP, marche temporali). Il contenuto della sessione non viene mai trasmesso attraverso i nostri server né conservato su di essi.
• Accesso non autorizzato. L'associazione richiede di scansionare il codice QR dell'host, di digitare l'ID dispositivo e il PIN che mostra, oppure di accedere allo stesso account Remio su entrambi. Non esiste alcun database di credenziali raggiungibile da remoto da attaccare.
• Furto di credenziali. Nessuna password, nessun account, nessun archivio centrale di credenziali. La fiducia nel dispositivo si stabilisce con l'associazione tramite PIN; i token di sessione (JWT) sono di breve durata e legati al dispositivo.
• Riproduzione della sessione. La protezione dalla riproduzione integrata in SRTP e i numeri di sequenza di DTLS impediscono di riprodurre i pacchetti catturati.
• Attacchi alla catena di fornitura. Tutti i file binari di Remio sono firmati. Le versioni per macOS sono autenticate da Apple (notarizzate). Le versioni per iOS sono distribuite esclusivamente tramite l'App Store.

Confini di fiducia

Il nostro modello delle minacce definisce esplicitamente tre confini di fiducia:

1. Confine del dispositivo. Ogni dispositivo è considerato affidabile solo dopo la verifica del PIN. Le protezioni a livello di sistema operativo (sandbox e archiviazione protetta di ciascun sistema, come il Portachiavi) proteggono i dati sul dispositivo.
2. Confine di rete. Tutti i dati in transito sono cifrati. Presumiamo che la rete sia ostile.
3. Confine del server. I nostri server sono trattati come relay non attendibili. Agevolano le connessioni ma non possono ispezionare il contenuto.

§03 · Panoramica dell'architettura

Remio separa il piano di signaling (configurazione della connessione) dal piano dei dati (streaming). Questa separazione è fondamentale per il nostro progetto a conoscenza zero: il server che ti aiuta a connetterti non tocca mai i dati che scambi.

Signaling e piano dei dati a confronto

L'unica responsabilità del server di signaling è inoltrare le offerte/risposte SDP e i candidati ICE tra i dispositivi durante la configurazione della connessione. Una volta stabilita la connessione P2P, il server di signaling non è più coinvolto.

Il server non può interpretare il contenuto inoltrato: è un blob binario cifrato che solo il dispositivo di destinazione può interpretare. Il protocollo binario aggiunge un ulteriore livello di struttura che rende più difficili gli attacchi di iniezione rispetto a un signaling basato su JSON.

§04 · Livelli di crittografia

Remio adotta una strategia di crittografia a più livelli in cui ogni canale di comunicazione usa il protocollo crittografico più adatto alle sue esigenze.

Perfect forward secrecy

Ogni sessione di Remio genera un insieme unico di chiavi di crittografia effimere tramite lo scambio di chiavi ECDHE.

• Compromettere la chiave della sessione corrente non espone le sessioni passate.
• Compromettere la chiave della sessione corrente non espone le sessioni future.
• Ogni coppia di chiavi esiste solo per la durata di una singola sessione.
• Le chiavi non vengono mai scritte su disco: esistono solo in memoria.

Suite di cifratura

# Signaling — TLS 1.3 cipher suites (in order of preference)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Media — SRTP protection profile (WebRTC industry default)
SRTP_AES128_CM_SHA1_80   # AES-128 counter mode, HMAC-SHA1-80 auth

# DTLS certificates
Self-signed ECDSA (P-256), verified out-of-band via SDP fingerprints

Rotazione delle chiavi

Le chiavi vengono ruotate automaticamente nei seguenti momenti:

• Avvio della sessione. Una nuova stretta di mano DTLS genera chiavi nuove per ogni connessione.
• Derivazione delle chiavi SRTP. Le chiavi dei contenuti multimediali derivano dalla stretta di mano DTLS e sono uniche per ogni traccia.
• Riconnessione. Se una sessione viene interrotta e ristabilita, avviene un nuovo scambio di chiavi completamente nuovo.

§05 · Autenticazione e associazione

Remio evita deliberatamente la tradizionale autenticazione con nome utente e password. Usiamo invece un modello di associazione dei dispositivi basato su PIN che elimina i vettori di attacco più comuni nel software di desktop remoto.

Associazione basata su PIN

Quando un client vuole connettersi a un host per la prima volta, il processo funziona così:

1. L'host mostra sul suo schermo un breve PIN numerico (o come codice QR).
2. Il client inserisce il PIN, che viene inviato all'host attraverso il canale di signaling.
3. L'host convalida il PIN e conferma o rifiuta l'associazione.
4. In caso di successo si stabilisce una relazione di fiducia tra dispositivi.
5. Le connessioni successive dallo stesso dispositivo non richiedono una nuova associazione.

Modello di fiducia dei dispositivi

Una volta associato, ogni dispositivo è identificato da un ID dispositivo univoco. L'host mantiene un elenco locale dei dispositivi attendibili. Questa relazione di fiducia è:

• Conservata in locale solo sul dispositivo host, nell'archiviazione protetta che il suo sistema offre: il Portachiavi su un Mac, l'archiviazione di sistema cifrata su Windows, un file privato su Linux.
• Mai trasmessa: il server non sa quali dispositivi siano attendibili.
• Revocabile: l'host può rimuovere un dispositivo attendibile in qualsiasi momento.

Token di sessione (JWT)

Dopo l'associazione, per l'autenticazione sul server di signaling vengono usati token firmati di breve durata (scadenza di 24 ore).

Questi token autenticano un dispositivo sul server di signaling per la creazione della stanza e l'inoltro dei messaggi. Non concedono l'accesso al contenuto della sessione, che è protetto da una stretta di mano DTLS separata.

Accesso degli agenti IA (Remio MCP Server)

Remio estende lo stesso modello di fiducia agli agenti IA. Strumenti come Claude Code, Codex o l'app Claude possono gestire i tuoi computer da remoto tramite il Remio MCP Server, e il confine di sicurezza è identico a quello che attraversa un client umano:

• Tutto è subordinato al tuo accesso. Un agente può raggiungere solo gli host che sono online e associati all'account con cui tu ti sei autenticato (accesso con Google o Apple, tramite OAuth). Senza un account autenticato, nessuno strumento.
• Remio è un intermediario, non un operatore. L'unico compito del server MCP è esporre un insieme di strumenti limitati al tuo account autenticato e consegnarli allo strumento di IA che tu hai scelto di collegare. Remio non può avviare da solo una sessione con il tuo computer: un host accetta solo connessioni che presentano la prova dell'autorizzazione del tuo account, esattamente come nel modello di fiducia dei dispositivi qui sopra.
• Stesso trasporto cifrato. Le sessioni degli agenti viaggiano negli stessi canali cifrati end-to-end descritti nel §04. I nostri server vedono comunque solo blob cifrati: le proprietà di conoscenza zero del §06 valgono senza modifiche.
• Visibile, interrompibile, verificabile. Una sessione di agente viene mostrata sull'host mentre è in corso, può essere terminata all'istante con un interruttore di emergenza ed è registrata in un registro di verifica locale.

§06 · Progetto a conoscenza zero

La conoscenza zero non è un termine di marketing per Remio: è un vincolo architetturale. I nostri sistemi sono progettati in modo che il contenuto della sessione sia strutturalmente inaccessibile a Remio, ai suoi dipendenti o a qualsiasi terza parte.

Cosa possono vedere i nostri server

• Gli indirizzi IP dei dispositivi che si connettono (necessari per la rete).
• Le marche temporali delle connessioni.
• Gli ID dei dispositivi (identificatori opachi, non legati a informazioni personali).
• I metadati di signaling: scambio di offerte/risposte SDP, candidati ICE.

Cosa non possono vedere i nostri server

• Il contenuto dello schermo: i fotogrammi video sono cifrati end-to-end con SRTP.
• L'audio: la stessa crittografia SRTP del video.
• Gli eventi di input: mouse, tastiera e tocco sono cifrati con DTLS.
• La posizione del cursore: trasmessa tramite il canale dati cifrato.
• Il contenuto dei file: qualsiasi trasferimento di file avviene su canali cifrati.
• I dati degli appunti: canale dati cifrato.
• Lo stato delle applicazioni: quali app stai usando, a cosa stai lavorando.

Politica di conservazione dei dati

Grazie alla nostra architettura P2P, in pratica non c'è nulla da conservare:

• Contenuto della sessione. Mai conservato. Solo flusso in tempo reale.
• Registri di signaling. I metadati delle connessioni vengono conservati fino a 30 giorni per il debug, poi eliminati. Non contengono alcun contenuto della sessione.
• Account utente. Nessun account richiesto. I dati facoltativi di Firebase Auth sono gestiti dall'infrastruttura di Google e possono essere eliminati dall'utente.
• Informazioni sul dispositivo. Conservate in locale su ciascun dispositivo. Se scegli di accedere, l'elenco dei tuoi dispositivi si sincronizza con il tuo account (vedi l'informativa sulla privacy).

Flusso di dati con priorità al P2P

Nella maggior parte delle connessioni (quando l'attraversamento del NAT riesce), i dati scorrono direttamente tra i dispositivi senza toccare alcun server:

# Best case: direct P2P
Client <—— DTLS-SRTP (encrypted) ——> Host
              ↑ No server involvement

# Fallback: TURN relay
Client <— DTLS-SRTP —> TURN server <— DTLS-SRTP —> Host
                            ↑ Still E2E encrypted
                            ↑ Server sees only encrypted blobs

Anche nello scenario di ripiego con relay TURN, il server relay gestisce solo pacchetti cifrati. Funziona come un semplice tubo: non può decifrare, ispezionare né modificare i dati.

§07 · Sicurezza di rete

Stabilimento della connessione P2P

Remio usa il protocollo ICE (Interactive Connectivity Establishment) per trovare il miglior percorso di connessione possibile tra i dispositivi:

1. Candidati host: connessione LAN diretta sulla stessa rete.
2. Candidati server-reflexive (STUN): attraversamento del NAT tramite server STUN per scoprire l'IP pubblico.
3. Candidati relay (TURN): relay cifrato quando non si può stabilire una connessione diretta.

L'agente ICE verifica contemporaneamente tutte le coppie di candidati e seleziona il percorso con la latenza più bassa e più affidabile. Si preferisce sempre il P2P diretto.

Criteri di trasporto configurabili

Per impostazione predefinita le connessioni preferiscono il P2P diretto con ripiego automatico sul relay cifrato. Criteri più rigidi, come forzare tutto il traffico attraverso il relay o saltare del tutto il rilevamento della LAN, sono disponibili per gli ambienti di rete molto restrittivi.

Limitazione della frequenza

Il server di signaling applica una limitazione aggressiva della frequenza per prevenire gli abusi:

I limitatori scaduti vengono ripuliti automaticamente a intervalli di 5 minuti con un TTL di 10 minuti, evitando l'esaurimento della memoria causato da attacchi distribuiti.

Protezione DDoS

La nostra infrastruttura di signaling è protetta da Cloudflare, che offre:

• DNS anycast con una rete globale di edge.
• Mitigazione DDoS ai livelli 3, 4 e 7.
• Web Application Firewall (WAF).
• Limitazione della frequenza sull'edge prima che il traffico raggiunga l'origine.
• Rilevamento dei bot e pagine di verifica.

§08 · Sicurezza del client

Remio sfrutta l'intero stack di sicurezza di ciascun sistema operativo per proteggere i dati locali e garantire l'integrità dell'applicazione.

macOS

• Integrazione con il Portachiavi. Tutti i dati sensibili (token di fiducia dei dispositivi, JWT) sono conservati nel Portachiavi di macOS, protetto dalle credenziali di accesso dell'utente e dalla crittografia hardware.
• App Sandbox. Remio funziona in un ambiente isolato con permessi minimi. L'acquisizione dello schermo e l'accessibilità richiedono l'approvazione esplicita dell'utente.
• Firma del codice. Tutte le versioni sono firmate con certificati Apple Developer.
• Notarizzazione. Le versioni per macOS sono notarizzate da Apple, a conferma che sono prive di malware noto.
• Runtime protetto. Impedisce l'iniezione di codice, il dirottamento delle librerie e il debug nelle versioni di produzione.

iOS

• App Transport Security (ATS). Tutte le connessioni di rete devono usare HTTPS/TLS. Nessuna eccezione configurata.
• Protezione dei dati. Gli elementi del Portachiavi sono cifrati con chiavi che il dispositivo ricava dal proprio hardware, e gli elementi contrassegnati come solo per questo dispositivo non lo lasciano mai, nemmeno in un backup.
• Servizi del Portachiavi. Le credenziali del dispositivo sono conservate nel Portachiavi di iOS con la classe di protezione kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly.
• Revisione dell'App Store. Tutte le versioni per iOS superano il processo di revisione della sicurezza di Apple.
• Nessun dato in background. L'app non raccoglie né trasmette dati quando è in background.

Firma del codice e verifica

# Verify Remio macOS binary — 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 · Risposta agli incidenti

Storico della sicurezza

A febbraio 2026, Remio non ha alcuno storico di violazioni o incidenti di sicurezza. La nostra architettura a conoscenza zero riduce in modo significativo la superficie di attacco: non esiste un database centrale di credenziali o di dati di sessione da prendere di mira.

Segnalazione delle vulnerabilità

Incoraggiamo la divulgazione responsabile da parte dei ricercatori di sicurezza. Se scopri una potenziale vulnerabilità:

1. Scrivi a security@remio.net con una descrizione dettagliata.
2. Includi i passaggi per riprodurla, se applicabile.
3. Confermiamo la ricezione entro 48 ore.
4. Puntiamo a risolvere le vulnerabilità confermate entro 30 giorni.
5. I segnalatori sono citati nel nostro registro delle modifiche di sicurezza, a meno che non preferiscano restare anonimi.

Politica di divulgazione responsabile

• Chiediamo una finestra di divulgazione di 90 giorni prima della divulgazione pubblica.
• Non intraprendiamo azioni legali contro i ricercatori che agiscono in buona fede.
• Diamo priorità alle correzioni in base alla gravità: critica, alta, media, bassa.
• Un programma formale di bug bounty è nella nostra roadmap.

Processo di risposta agli incidenti

In caso di problema di sicurezza confermato:

1. Contenimento. Isolare i sistemi interessati entro 1 ora.
2. Valutazione. Determinare portata e impatto entro 24 ore.
3. Comunicazione. Avvisare gli utenti interessati entro 72 ore (nel rispetto del GDPR).
4. Correzione. Distribuire le patch tramite l'infrastruttura di aggiornamento automatico.
5. Analisi a posteriori. Pubblicare un rapporto di trasparenza.

§10 · Conformità

Predisposizione al GDPR

L'architettura a conoscenza zero di Remio è per sua natura favorevole al GDPR perché riduciamo la raccolta di dati al minimo tecnico assoluto:

• Minimizzazione dei dati. Raccogliamo solo ciò che serve per stabilire la connessione.
• Diritto alla cancellazione. Dato che non conserviamo i contenuti degli utenti, non c'è nulla da eliminare. I dati facoltativi dell'account possono essere eliminati su richiesta.
• Portabilità dei dati. I dati di fiducia dei dispositivi sono conservati in locale e controllati dall'utente.
• Consenso. L'associazione con PIN è un meccanismo di consenso esplicito per ciascun dispositivo.
• Nessun trasferimento transfrontaliero dei contenuti. Le connessioni P2P tengono i dati tra i dispositivi; non entrano mai nella nostra infrastruttura.

SOC 2

Non ancora disponibile

• Audit di sicurezza indipendente: non è stato ancora eseguito alcun penetration test né revisione del codice da parte di terzi.
• SOC 2 Tipo I: ancora nessun rapporto.
• SOC 2 Tipo II: ancora nessun rapporto.
• Programma di bug bounty: ricompense formali per la divulgazione responsabile.

Residenza dei dati

Dato che Remio dà priorità al P2P, i dati della sessione risiedono ovunque si trovino i tuoi dispositivi. I tuoi dati non lasciano mai la connessione diretta tra i tuoi dispositivi. Il server di signaling (ospitato con Cloudflare e DigitalOcean) elabora solo metadati di connessione, e questi metadati non sono collegati ad alcuna informazione personale.

§11 · Confronto con le alternative

Il settore del desktop remoto è stato afflitto da violazioni di sicurezza molto note. Ecco come l'architettura di Remio si differenzia in modo sostanziale dalle alternative centralizzate.

Perché le architetture centralizzate falliscono

Il problema fondamentale dei servizi di desktop remoto centralizzati è che una sola violazione può compromettere tutti gli utenti. Quando i server di produzione di AnyDesk sono stati violati nel febbraio 2024, gli aggressori hanno rubato i certificati di firma del codice, potendo così potenzialmente distribuire malware camuffato da software AnyDesk legittimo. Tutte le password degli utenti hanno dovuto essere reimpostate.

Quando APT29 (un gruppo sostenuto dallo Stato russo) ha violato la rete aziendale di TeamViewer nel giugno 2024, sono sorti dubbi sull'integrità del prodotto stesso, perché un'architettura centralizzata significa che il fornitore ha la capacità tecnica di accedere alle sessioni.

Remio elimina del tutto questa classe di attacchi. Una violazione del nostro server di signaling restituisce solo metadati di connessione. Non ci sono credenziali da rubare, sessioni a cui accedere, certificati che si possano usare per firmare software dannoso rivolto ai dispositivi dei nostri utenti.

§12 · Conclusione

La sicurezza di Remio non è un insieme di funzioni aggiunte a un prodotto: è la conseguenza di scelte architetturali fatte fin dal primo giorno. Scegliendo il P2P al posto del centralizzato, l'associazione con PIN al posto delle password e la conoscenza zero al posto della raccolta di dati, abbiamo costruito un desktop remoto in cui la sicurezza è lo stato predefinito, non un upgrade facoltativo.

Crediamo che la privacy non sia facoltativa e che la fiducia vada guadagnata con la trasparenza, non pretesa con i termini di servizio. Questo whitepaper fa parte di questo impegno.

Per domande, verifiche di sicurezza aziendali o per segnalare una vulnerabilità:

• Richieste sulla sicurezza: security@remio.net
• Vendite aziendali: enterprise@remio.net
• Generale: hello@remio.net