Arsitektur keamanan Remio, dinyatakan apa adanya.

§01 · Ringkasan eksekutif

Remio adalah aplikasi remote desktop yang dibangun di atas arsitektur zero-knowledge dan peer-to-peer. Isi layar, data input, dan aliran audio dienkripsi ujung ke ujung antar perangkat menggunakan DTLS-SRTP standar industri — model keamanan yang sama yang diandalkan setiap produk berbasis WebRTC. Tidak seperti solusi terpusat, server signaling Remio hanya memfasilitasi pembentukan koneksi awal — tidak pernah melihat, memproses, atau menyimpan data sesi.

Tidak ada akun yang diperlukan, tidak ada kata sandi yang bisa dibobol, tidak ada basis data kredensial pusat. Pemasangan perangkat memakai kode QR atau ID Perangkat dan PIN yang dibaca dari layar host itu sendiri, dan semua kunci sesi bersifat sementara dengan Perfect Forward Secrecy: bahkan jika sebuah kunci bocor, sesi masa lalu dan masa depan tetap aman secara kriptografis. Arsitektur ini menghapus seluruh kategori serangan yang menimpa para pesaing — karena memang tidak ada yang bisa dicuri.

§02 · Model ancaman

Arsitektur keamanan Remio dirancang terhadap sejumlah skenario ancaman yang relevan untuk penggunaan remote desktop di konteks perusahaan maupun pribadi. Kami eksplisit tentang apa yang kami lindungi dan di mana batas kepercayaannya.

Ancaman yang kami lindungi

• Penyadapan. Semua media (video, audio) dan kanal data (input, keyboard, kursor) masing-masing dienkripsi dengan SRTP dan DTLS. Pengamat jaringan hanya melihat paket terenkripsi tanpa kemampuan merekonstruksi isi sesi.
• Man-in-the-middle (MITM). Handshake DTLS dengan verifikasi sidik jari sertifikat mencegah intersepsi. Kanal signaling memakai TLS 1.3 dengan Perfect Forward Secrecy.
• Pembobolan server. Bahkan jika server signaling kami sepenuhnya dibobol, penyerang hanya mendapat akses ke metadata koneksi (alamat IP, stempel waktu). Isi sesi tidak pernah dikirim melalui, atau disimpan di, server kami.
• Akses tanpa izin. Pemasangan mengharuskan pemindaian kode QR host, mengetik ID Perangkat dan PIN yang ditampilkannya, atau masuk ke akun Remio yang sama di keduanya. Tidak ada basis data kredensial yang bisa diakses dari jarak jauh untuk diserang.
• Pencurian kredensial. Tanpa kata sandi, tanpa akun, tanpa penyimpanan kredensial pusat. Kepercayaan perangkat dibangun lewat pemasangan PIN; token sesi (JWT) berumur pendek dan terikat pada perangkat.
• Replay sesi. Perlindungan replay bawaan SRTP dan nomor urut DTLS mencegah paket yang ditangkap diputar ulang.
• Serangan rantai pasokan. Semua binary Remio ditandatangani kodenya. Build macOS dinotarisasi oleh Apple. Build iOS didistribusikan secara eksklusif lewat App Store.

Batas kepercayaan

Model ancaman kami mendefinisikan tiga batas kepercayaan secara eksplisit:

1. Batas perangkat. Setiap perangkat hanya dipercaya setelah verifikasi PIN. Perlindungan tingkat OS (sandboxing dan penyimpanan terlindungi tiap sistem, seperti Keychain) melindungi data di perangkat.
2. Batas jaringan. Semua data saat transit dienkripsi. Kami menganggap jaringan bersifat bermusuhan.
3. Batas server. Server kami sendiri diperlakukan sebagai relay yang tidak dipercaya. Server memfasilitasi koneksi tetapi tidak dapat memeriksa isi.

§03 · Ikhtisar arsitektur

Remio memisahkan bidang signaling (pembentukan koneksi) dari bidang data (streaming). Pemisahan ini mendasar bagi desain zero-knowledge kami — server yang membantu Anda terhubung tidak pernah menyentuh data yang Anda pertukarkan.

Signaling vs. bidang data

Satu-satunya tanggung jawab server signaling adalah meneruskan SDP offer/answer dan kandidat ICE antar perangkat selama pembentukan koneksi. Begitu koneksi P2P terbentuk, server signaling tidak lagi terlibat.

Server tidak dapat mengurai isi yang diteruskan — isinya blob biner terenkripsi yang hanya bisa ditafsirkan perangkat tujuan. Protokol biner menambah satu lapisan struktur yang membuat serangan injeksi lebih sulit dibandingkan signaling berbasis JSON.

§04 · Lapisan enkripsi

Remio memakai strategi enkripsi berlapis, di mana setiap kanal komunikasi menggunakan protokol kriptografi yang paling sesuai dengan kebutuhannya.

Perfect forward secrecy

Setiap sesi Remio menghasilkan satu set kunci enkripsi sementara yang unik lewat pertukaran kunci ECDHE.

• Bocornya kunci sesi saat ini tidak membuka sesi masa lalu.
• Bocornya kunci sesi saat ini tidak membuka sesi masa depan.
• Setiap pasangan kunci hanya ada selama satu sesi.
• Kunci tidak pernah disimpan ke disk — hanya ada di memori.

Cipher suite

# 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

Rotasi kunci

Kunci dirotasi secara otomatis pada batas-batas berikut:

• Awal sesi. Handshake DTLS baru menghasilkan kunci segar untuk setiap koneksi.
• Penurunan kunci SRTP. Kunci media diturunkan dari handshake DTLS dan unik per trek media.
• Koneksi ulang. Jika sesi terputus lalu tersambung kembali, pertukaran kunci yang sepenuhnya baru terjadi.

§05 · Autentikasi dan pemasangan

Remio sengaja menghindari autentikasi nama pengguna/kata sandi tradisional. Sebagai gantinya, kami memakai model pemasangan perangkat berbasis PIN yang menghilangkan vektor serangan paling umum pada perangkat lunak remote desktop.

Pemasangan berbasis PIN

Saat klien ingin terhubung ke host untuk pertama kali, prosesnya berjalan sebagai berikut:

1. Host menampilkan PIN numerik singkat di layarnya (atau sebagai kode QR).
2. Klien memasukkan PIN, yang dikirim lewat kanal signaling ke host.
3. Host memvalidasi PIN dan mengonfirmasi atau menolak pemasangan.
4. Jika berhasil, sebuah hubungan kepercayaan perangkat terbentuk.
5. Koneksi berikutnya dari perangkat yang sama tidak memerlukan pemasangan ulang.

Model kepercayaan perangkat

Setelah dipasangkan, setiap perangkat diidentifikasi dengan ID perangkat yang unik. Host menyimpan daftar lokal perangkat tepercaya. Hubungan kepercayaan ini:

• Disimpan secara lokal hanya di perangkat host, dalam penyimpanan terlindungi yang disediakan sistemnya — Keychain di Mac, penyimpanan sistem terenkripsi di Windows, file privat di Linux.
• Tidak pernah dikirim — server tidak tahu perangkat mana yang tepercaya.
• Dapat dicabut — host bisa menghapus perangkat tepercaya kapan saja.

Token sesi (JWT)

Setelah pemasangan, token bertanda tangan berumur pendek (kedaluwarsa 24 jam) dipakai untuk autentikasi ke server signaling.

Token ini mengautentikasi perangkat ke server signaling untuk pembuatan ruang dan peneruslaan pesan. Token ini tidak memberi akses ke isi sesi, yang dilindungi oleh handshake DTLS terpisah.

Akses agen AI (Remio MCP Server)

Remio memperluas model kepercayaan yang sama ini ke agen AI. Alat seperti Claude Code, Codex, atau aplikasi Claude dapat mengoperasikan mesin Anda dari jarak jauh lewat Remio MCP Server — dan batas keamanannya identik dengan yang dilewati klien manusia:

• Semuanya dibatasi oleh proses masuk Anda. Agen hanya bisa menjangkau host yang online dan dipasangkan ke akun yang Anda gunakan untuk autentikasi (masuk Google atau Apple, lewat OAuth). Tanpa akun terautentikasi, tanpa alat.
• Remio adalah perantara, bukan operator. Satu-satunya tugas server MCP adalah mengekspos sekumpulan alat yang dibatasi pada akun terautentikasi Anda dan menyerahkannya ke alat AI yang Anda pilih untuk dihubungkan. Remio tidak bisa memulai sesi dengan mesin Anda sendiri — host hanya menerima koneksi yang menyertakan bukti otorisasi akun Anda, persis seperti model kepercayaan perangkat di atas.
• Transport terenkripsi yang sama. Sesi agen berjalan di kanal terenkripsi ujung ke ujung yang sama seperti dijelaskan di §04. Server kami tetap hanya melihat blob terenkripsi — sifat zero-knowledge di §06 berlaku tanpa perubahan.
• Terlihat, dapat dimatikan, diaudit. Sesi agen ditampilkan di host selama berjalan, dapat diakhiri seketika dengan tombol kill, dan dicatat dalam log audit lokal.

§06 · Desain zero-knowledge

Zero-knowledge bukan istilah pemasaran di Remio — ini adalah batasan arsitektural. Sistem kami dirancang agar isi sesi secara struktural tidak dapat diakses oleh Remio, karyawannya, atau pihak ketiga mana pun.

Yang dapat dilihat server kami

• Alamat IP perangkat yang terhubung (diperlukan untuk jaringan).
• Stempel waktu koneksi.
• ID perangkat (pengenal buram, tidak terkait informasi pribadi).
• Metadata signaling: pertukaran SDP offer/answer, kandidat ICE.

Yang tidak dapat dilihat server kami

• Isi layar — frame video dienkripsi SRTP ujung ke ujung.
• Audio — enkripsi SRTP yang sama seperti video.
• Peristiwa input — mouse, keyboard, sentuhan dienkripsi DTLS.
• Posisi kursor — dikirim lewat kanal data terenkripsi.
• Isi file — setiap transfer file terjadi lewat kanal terenkripsi.
• Data papan klip — kanal data terenkripsi.
• Keadaan aplikasi — aplikasi apa yang Anda jalankan, apa yang sedang Anda kerjakan.

Kebijakan retensi data

Karena arsitektur P2P kami, pada dasarnya tidak ada yang perlu disimpan:

• Isi sesi. Tidak pernah disimpan. Hanya aliran real time.
• Log signaling. Metadata koneksi disimpan hingga 30 hari untuk debugging, lalu dihapus. Tidak berisi isi sesi.
• Akun pengguna. Tidak ada akun yang diperlukan. Data Firebase Auth opsional dikelola oleh infrastruktur Google dan dapat dihapus oleh pengguna.
• Informasi perangkat. Disimpan secara lokal di setiap perangkat. Jika Anda memilih masuk, daftar perangkat Anda disinkronkan ke akun Anda (lihat kebijakan privasi).

Alur data yang mengutamakan P2P

Pada sebagian besar koneksi (saat NAT traversal berhasil), data mengalir langsung antar perangkat tanpa menyentuh server mana pun:

# 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

Bahkan pada skenario cadangan relay TURN, server relay hanya menangani paket terenkripsi. Server bertindak sebagai pipa bodoh — tidak dapat mendekripsi, memeriksa, atau mengubah data.

§07 · Keamanan jaringan

Pembentukan koneksi P2P

Remio memakai protokol ICE (Interactive Connectivity Establishment) untuk menemukan jalur koneksi terbaik antar perangkat:

1. Kandidat host — koneksi LAN langsung di jaringan yang sama.
2. Kandidat server-reflexive (STUN) — NAT traversal lewat server STUN untuk menemukan IP publik.
3. Kandidat relay (TURN) — relay terenkripsi saat koneksi langsung tidak bisa dibentuk.

Agen ICE menguji semua pasangan kandidat secara bersamaan dan memilih jalur dengan latensi terendah dan paling andal. P2P langsung selalu diutamakan.

Kebijakan transport yang dapat dikonfigurasi

Koneksi secara default mengutamakan P2P langsung dengan cadangan otomatis ke relay terenkripsi. Kebijakan yang lebih ketat — memaksa semua lalu lintas lewat relay, atau melewati penemuan LAN sepenuhnya — tersedia untuk lingkungan jaringan yang terkunci.

Pembatasan laju

Server signaling menerapkan pembatasan laju yang agresif untuk mencegah penyalahgunaan:

Pembatas laju yang kedaluwarsa dibersihkan otomatis dengan interval 5 menit dan TTL 10 menit, mencegah kehabisan memori akibat serangan terdistribusi.

Perlindungan DDoS

Infrastruktur signaling kami dilindungi oleh Cloudflare, yang menyediakan:

• DNS Anycast dengan jaringan edge global.
• Mitigasi DDoS Layer 3, 4, dan 7.
• Web Application Firewall (WAF).
• Pembatasan laju di edge sebelum lalu lintas mencapai origin.
• Deteksi bot dan halaman tantangan.

§08 · Keamanan klien

Remio memanfaatkan seluruh tumpukan keamanan setiap sistem operasi untuk melindungi data lokal dan memastikan integritas aplikasi.

macOS

• Integrasi Keychain. Semua data sensitif (token kepercayaan perangkat, JWT) disimpan di Keychain macOS, dilindungi oleh kredensial login pengguna dan enkripsi perangkat keras.
• App Sandbox. Remio berjalan di lingkungan sandbox dengan izin minimal. Perekaman layar dan aksesibilitas memerlukan persetujuan eksplisit pengguna.
• Penandatanganan kode. Semua build ditandatangani dengan sertifikat Apple Developer.
• Notarisasi. Build macOS dinotarisasi oleh Apple, yang memastikan bebas dari malware yang dikenal.
• Hardened runtime. Mencegah injeksi kode, pembajakan pustaka, dan debugging pada build produksi.

iOS

• App Transport Security (ATS). Semua koneksi jaringan harus memakai HTTPS/TLS. Tidak ada pengecualian yang dikonfigurasi.
• Perlindungan data. Item Keychain dienkripsi dengan kunci yang diturunkan perangkat dari perangkat kerasnya sendiri, dan item yang ditandai hanya-perangkat-ini tidak pernah meninggalkannya, bahkan dalam cadangan.
• Keychain Services. Kredensial perangkat disimpan di Keychain iOS dengan kelas perlindungan kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly.
• Tinjauan App Store. Semua build iOS melewati proses tinjauan keamanan Apple.
• Tanpa data latar belakang. Aplikasi tidak mengumpulkan atau mengirim data saat berada di latar belakang.

Penandatanganan kode & verifikasi

# 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 · Respons insiden

Rekam jejak keamanan

Per Februari 2026, Remio tidak punya riwayat pembobolan atau insiden keamanan. Arsitektur zero-knowledge kami secara signifikan mengurangi permukaan serangan — tidak ada basis data kredensial atau data sesi pusat yang bisa disasar.

Pelaporan kerentanan

Kami mendorong pengungkapan yang bertanggung jawab dari para peneliti keamanan. Jika Anda menemukan potensi kerentanan:

1. Kirim email ke security@remio.net dengan deskripsi rinci.
2. Sertakan langkah reproduksi, jika berlaku.
3. Kami mengonfirmasi penerimaan dalam 48 jam.
4. Kami berupaya menyelesaikan kerentanan yang terkonfirmasi dalam 30 hari.
5. Pelapor dicantumkan dalam changelog keamanan kami, kecuali mereka lebih suka anonim.

Kebijakan pengungkapan yang bertanggung jawab

• Kami meminta jendela pengungkapan 90 hari sebelum pengungkapan publik.
• Kami tidak menempuh tindakan hukum terhadap peneliti yang bertindak dengan itikad baik.
• Kami memprioritaskan perbaikan berdasarkan tingkat keparahan: kritis, tinggi, sedang, rendah.
• Program bug bounty resmi ada di roadmap kami.

Proses respons insiden

Jika terjadi masalah keamanan yang terkonfirmasi:

1. Pembatasan. Isolasi sistem yang terdampak dalam 1 jam.
2. Penilaian. Tentukan cakupan dan dampak dalam 24 jam.
3. Komunikasi. Beri tahu pengguna yang terdampak dalam 72 jam (sesuai GDPR).
4. Perbaikan. Terapkan patch lewat infrastruktur pembaruan otomatis.
5. Post-mortem. Terbitkan laporan transparansi.

§10 · Kepatuhan

Kesiapan GDPR

Arsitektur zero-knowledge Remio pada dasarnya ramah GDPR karena kami meminimalkan pengumpulan data hingga minimum teknis mutlak:

• Minimalisasi data. Kami hanya mengumpulkan yang diperlukan untuk pembentukan koneksi.
• Hak penghapusan. Karena kami tidak menyimpan konten pengguna, tidak ada yang perlu dihapus. Data akun opsional dapat dihapus atas permintaan.
• Portabilitas data. Data kepercayaan perangkat disimpan secara lokal dan dikendalikan pengguna.
• Persetujuan. Pemasangan PIN adalah mekanisme persetujuan eksplisit untuk setiap perangkat.
• Tanpa transfer data konten lintas batas. Koneksi P2P menjaga data antar perangkat; data tidak pernah masuk ke infrastruktur kami.

SOC 2

Belum tersedia

• Audit keamanan independen — belum ada uji penetrasi atau tinjauan kode oleh pihak ketiga.
• SOC 2 Type I — belum ada laporan.
• SOC 2 Type II — belum ada laporan.
• Program bug bounty — imbalan resmi untuk pengungkapan yang bertanggung jawab.

Residensi data

Karena Remio mengutamakan P2P, data sesi berada di mana pun perangkat Anda berada. Data Anda tidak pernah meninggalkan koneksi langsung antar perangkat Anda. Server signaling (di-host di Cloudflare dan DigitalOcean) hanya memproses metadata koneksi — dan metadata ini tidak terkait informasi pribadi apa pun.

§11 · Perbandingan dengan alternatif

Industri remote desktop dilanda pembobolan keamanan yang menjadi sorotan. Berikut perbedaan mendasar arsitektur Remio dari alternatif terpusat.

Mengapa arsitektur terpusat gagal

Masalah mendasar layanan remote desktop terpusat adalah satu pembobolan dapat membahayakan semua pengguna. Saat server produksi AnyDesk dibobol pada Februari 2024, penyerang mencuri sertifikat penandatanganan kode, yang berpotensi memungkinkan mereka mendistribusikan malware yang menyamar sebagai perangkat lunak AnyDesk yang sah. Semua kata sandi pengguna harus direset.

Saat APT29 (kelompok yang didukung negara Rusia) membobol jaringan korporat TeamViewer pada Juni 2024, hal itu memunculkan pertanyaan tentang integritas produk itu sendiri — karena arsitektur terpusat berarti vendor memiliki kemampuan teknis untuk mengakses sesi.

Remio menghilangkan kelas serangan ini sepenuhnya. Pembobolan server signaling kami hanya menghasilkan metadata koneksi. Tidak ada kredensial untuk dicuri, tidak ada sesi untuk diakses, tidak ada sertifikat yang bisa dipakai menandatangani perangkat lunak berbahaya yang menyasar perangkat pengguna kami.

§12 · Kesimpulan

Keamanan Remio bukan sekumpulan fitur yang ditempelkan pada produk — melainkan konsekuensi dari keputusan arsitektur yang diambil sejak hari pertama. Dengan memilih P2P ketimbang terpusat, pemasangan PIN ketimbang kata sandi, dan zero-knowledge ketimbang pengumpulan data, kami membangun remote desktop di mana keamanan adalah keadaan default, bukan peningkatan opsional.

Kami percaya bahwa privasi bukan pilihan, dan bahwa kepercayaan harus diperoleh lewat transparansi, bukan dituntut lewat ketentuan layanan. Whitepaper ini adalah bagian dari komitmen itu.

Untuk pertanyaan, tinjauan keamanan perusahaan, atau melaporkan kerentanan:

• Pertanyaan keamanan: security@remio.net
• Penjualan enterprise: enterprise@remio.net
• Umum: hello@remio.net