Protokol Mudah Alih VMProto

Sila lihat Soalan Lazim untuk Golongan Teknikal.
Pembangun klien dikehendaki mematuhi Garis Panduan Keselamatan.

Halaman ini membincangkan lapisan asas penyulitan VMProto yang digunakan untuk sembang Awan (penyulitan pelayan-klien). Lihat juga:

Penerangan Umum

Protokol VMP Chat dibina di atas kriptografi standard industri dan primitif pengangkutan — blok pembinaan yang sama yang digunakan oleh setiap pemesej selamat moden. Tiada pembinaan sifer tersuai dan tiada format wayar proprietari; setiap lapisan adalah sesuatu yang boleh dikenali oleh juruaudit keselamatan dan disahkan terhadap spesifikasi yang diterbitkan.

Seni bina dibahagikan kepada tiga komponen yang hampir bebas:

  • Lapisan pengesahan: OAuth 2.0 dengan PKCE mengeluarkan token akses JWT berumur pendek yang disimpan dalam iOS Keychain atau Android Keystore yang disokong perkakasan. OS hanya mendedahkan rahsia ini selepas peranti dibuka kunci.
  • Lapisan pemesejan masa nyata: Socket.IO melalui TLS membawa peristiwa sembang, kehadiran, menaip, reaksi, dan resit baca dalam JSON. Kandungan mesej disulitkan hujung-ke-hujung dengan AES-256-GCM sebelum meninggalkan peranti — pelayan menyimpan teks sifer dan sampul kunci yang tidak dapat dinyahsulitkan.
  • Lapisan media & panggilan: Panggilan suara dan video berjalan pada LiveKit (sebuah WebRTC SFU) dengan penyulitan DTLS-SRTP hujung-ke-hujung pada setiap aliran media. Muat naik imej, video, suara, dan dokumen disulitkan pada keadaan rehat di pihak pelayan dengan AES-256-GCM.

iOS Swift Package dan aplikasi Android Kotlin berkongsi model domain yang sama, kontrak peristiwa Socket.IO yang sama, dan format wayar penyulitan yang sama. Mesej yang disulitkan pada iOS dinyahsulit bait demi bait pada Android dengan kunci bilik yang sama — dan sebaliknya. Kedua-dua klien adalah cermin fungsional 1:1 antara satu sama lain.

Ringkasan Komponen

Pengesahan & Pengurusan Token

Log masuk menggunakan OAuth 2.0 dengan PKCE — standard moden untuk pengesahan aplikasi natif. Aliran ini menghapuskan keseluruhan kelas serangan pemintasan authorization-code yang secara sejarah memberi kesan kepada klien OAuth awam.

Pelayan mengeluarkan sepasang JWT: token akses berumur pendek dan token muat semula yang berumur lebih lama. Kedua-duanya disimpan dalam storan selamat berakar perkakasan pada peranti anda:

  • iOS: Keychain natif — rahsia tidak tersedia sehingga peranti telah dibuka kunci sekurang-kurangnya sekali selepas but.
  • Android: keutamaan tersulit yang disokong perkakasan. Pada peranti dengan elemen selamat, kunci induk tidak pernah meninggalkan elemen tersebut.

Klien mengekalkan dua konteks token bebas (satu untuk sembang, satu untuk permukaan komuniti), supaya token yang dikeluarkan untuk satu tidak boleh secara tidak sengaja membenarkan permintaan kepada yang lain.

Token akses dimuat semula secara proaktif — lapisan rangkaian memuat semulanya sebelum tamat tempoh, mengelakkan kos perjalanan pergi balik permintaan yang gagal yang diikuti dengan percubaan semula. Muat semula disirikan supaya permintaan tamat tempoh serentak mencetuskan tepat satu muat semula, bukan banyak.

Log keluar membatalkan token muat semula di pihak pelayan, supaya peranti yang dicuri dengan token cache tidak boleh terus mengakses akaun setelah pengguna log keluar dari mana-mana tempat lain.

Pemesejan Masa Nyata

Penghantaran masa nyata berjalan pada Socket.IO dengan pelayan berskala mendatar di belakang load balancer, supaya mesej yang diterbitkan pada satu instans sampai kepada klien yang disambungkan ke mana-mana instans lain secara telus.

Klien melaksanakan pengendali sambung semula tersuai: pada putus sambungan, klien memuat semula token pengesahan terlebih dahulu, kemudian menyambung semula dengan token baharu. Mundur adalah eksponen, dihadkan pada 30 saat setiap percubaan untuk sehingga 10 percubaan.

Mesej dinyahduplikasi di pihak klien dengan cache kecil dalam ingatan bagi ID mesej terkini, supaya walaupun pelayan melakukan fan-out untuk jaminan penghantaran, anda tidak pernah melihat gelembung pendua dalam sembang kumpulan yang sibuk.

Kedua-dua klien berkongsi set peristiwa masa nyata yang sama: mesej baharu dan dikemas kini, status mesej, penunjuk menaip, kehadiran, reaksi, perubahan sekatan, kemas kini bilik dan ahli. Kedua-dua platform memerhatikan kosa kata yang sama, supaya ciri yang dihantar pada satu klien berkelakuan secara identik pada yang lain.

Jika tembok api korporat menyekat WebSockets, Socket.IO secara telus turun ke long-polling — kebanyakan aduan “aplikasi ini tidak berfungsi pada Wi-Fi pejabat saya” hilang sebagai akibatnya.

Penyulitan Hujung-ke-Hujung

Kandungan mesej disulitkan pada peranti anda sebelum ia mencapai pelayan. Sifer ialah AES-256-GCM — pembinaan penyulitan terotentikasi yang ditakrifkan dalam NIST SP 800-38D dan distandardkan sebagai suite sifer lalai dalam TLS 1.3.

  • Kunci: kunci bilik simetri 256-bit, satu setiap perbualan.
  • Nonce: nilai 96-bit baharu yang dihasilkan setiap mesej — saiz yang disyorkan NIST untuk GCM, dengan kebarangkalian perlanggaran yang boleh diabaikan pada mana-mana skala realistik.
  • Tag pengesahan: 128 bit, dilampirkan pada teks sifer. Sebarang gangguan — oleh pelayan, penyerang rangkaian, atau imej cakera forensik — dikesan semasa nyahsulit; sifer enggan memulangkan plaintext yang salah secara senyap.
  • Keserasian merentas platform: mesej yang disulitkan pada iOS dinyahsulit pada Android (dan sebaliknya) dengan kunci bilik yang sama. Kedua-dua klien berkongsi format penyulitan yang sama.

Kunci bilik itu sendiri dibungkus di bawah Key Encryption Key (KEK) yang diterbitkan setiap pengguna, dan KEK tidak pernah meninggalkan peranti anda. Pelayan menyimpan sampul kunci yang dibungkus — supaya peranti baharu boleh menyegerakkan sejarah anda selepas log masuk — tetapi tidak boleh membuka bungkusannya. Kebocoran pangkalan data hanya menghasilkan teks sifer.

Perkhidmatan penyulitan menolak untuk menyulitkan langsung apabila kunci hilang — tiada fallback senyap kepada plaintext. Pelayan tidak pernah boleh menerima mesej dalam bentuk jelas kerana ralat di pihak klien.

Panggilan Suara & Video

Panggilan suara dan video berjalan pada LiveKit, sebuah Selective Forwarding Unit (SFU) yang dibina di atas WebRTC. Seni bina SFU bermakna setiap peserta tambahan menambah kos O(1) setiap klien — seni bina yang sama dengan Google Meet dan Zoom, dan secara substansial lebih murah daripada mesh peer-to-peer selepas empat peserta.

Setiap aliran media WebRTC disulitkan hujung-ke-hujung dengan DTLS-SRTP, sebagaimana diamanatkan oleh spesifikasi WebRTC. Token akses bilik berumur pendek (15 minit) dan terikat kepada satu bilik — token yang ditangkap dalam transit tamat tempoh dengan cepat dan tidak boleh dimainkan semula di tempat lain.

Setiap klien berintegrasi dengan permukaan panggilan natif platform:

  • iOS — CallKit + PushKit: panggilan masuk menunjukkan UI terima/tolak skrin kunci sistem dengan foto kenalan, berintegrasi dengan aplikasi Recents iPhone, dan menyokong butang terima fon kepala Bluetooth. Tolakan VoIP membangunkan aplikasi sebelum anda menyedari pemberitahuan, supaya panggilan berdering walaupun apabila aplikasi telah dimatikan.
  • Android — perkhidmatan latar depan untuk panggilan telefon: perkhidmatan panggilan bertahan dalam mod Doze dan task-killer OEM yang agresif (Vivo, Xiaomi, Samsung semuanya menyenarai putih jenis perkhidmatan ini). Muatan panggilan tiba melalui pemberitahuan tolak, berdering melalui nada dering sistem, dan mempersembahkan pemberitahuan skrin penuh.

Penghalaan audio mengesan fon kepala Bluetooth dan berwayar secara automatik, menggunakan earpiece untuk panggilan suara dan speakerphone untuk video, dan menggunakan pembatalan gema dan gating mikrofon semasa panggilan.

Pengangkutan & TLS

Setiap bait yang meninggalkan peranti — panggilan API, bingkai masa nyata, atau muat naik media — bergerak melalui TLS 1.2 atau lebih tinggi. Lapisan pengangkutan menyediakan jaminan standard: kerahsiaan, integriti, dan kerahsiaan hadapan saluran itu sendiri. Lapisan aplikasi menambah penyulitan hujung-ke-hujung di atasnya.

Kedua-dua klien menambah lapisan defense-in-depth di atas TLS:

  • Android — certificate pinning: sijil pengeluaran disematkan pada lapisan rangkaian, digunakan secara seragam pada setiap klien HTTP dan image loader dalam aplikasi. Proksi korporat penjenayah atau CA negara-bangsa tidak boleh secara senyap memintas sambungan.
  • iOS — App Transport Security: ATS menguatkuasakan TLS 1.2+ dengan suite sifer kerahsiaan hadapan dan kesahihan sijil pada peringkat OS untuk setiap permintaan rangkaian.

Klien HTTP membezakan sumber yang boleh berubah daripada yang tidak boleh berubah melalui pengepala cache-control: URL media dicache selama 24 jam (mereka beralamat kandungan dan tidak boleh berubah), profil pengguna selama 10 minit, dan keadaan sensitif yang boleh berubah tidak pernah di-HTTP-cache. Data bilik dan mesej tidak di-HTTP-cache langsung — storan tempatan pada peranti adalah sumber kebenaran untuk itu.

Lapisan masa nyata merundingkan pengangkutan terbaik yang tersedia: WebSocket di mana mungkin, HTTP long-polling sebagai fallback. Pada Android, klien menunggu OS mengesahkan jangkauan internet sebenar sebelum menyambung semula, supaya percubaan sambung semula tidak menyala pada Wi-Fi captive-portal di mana OS belum mengesahkan jangkauan internet sebenar.

Storan Tempatan & Luar Talian

Aplikasi adalah luar talian dahulu. Senarai sembang, sejarah mesej, kenalan, draf, dan kiraan belum dibaca dibuka serta-merta pada cold start — walaupun di dalam pesawat.

  • Android: empat pangkalan data on-device berasingan — chat, community, auth, dan block-state — setiap satu dengan skema sendiri dan domain crash, supaya kerosakan dalam satu tidak boleh merosakkan yang lain. Carian mesej yang diindeks mengekalkan penatalan kekal lancar walaupun dalam bilik dengan puluhan ribu mesej. AES-256-GCM setiap mesej diaplikasikan sebelum kekal — apa yang hidup pada cakera ialah teks sifer.
  • iOS: lapisan storan berasaskan protokol yang direka supaya aplikasi hos boleh menukar mana-mana enjin pangkalan data tanpa menyentuh protokol repositori di atasnya.

Di pihak pelayan, keadaan dibahagikan merentasi pangkalan data yang paling sesuai dengan setiap corak akses: storan rasional untuk akaun, kenalan, peranti, dan metadata bilik; storan wide-column untuk badan mesej, di-shard setiap bilik dan disusun mengikut kebaruan — corak beban kerja yang sama yang digunakan WhatsApp dan Discord; dan cache dalam ingatan untuk kehadiran, menaip, dan data panas berumur pendek.

Media yang dimuat naik disulitkan pada keadaan rehat di pelayan dengan AES-256-GCM dan tamat tempoh selepas 30 hari. Pengguna boleh memilih untuk menyertai sandaran Google Drive, dalam hal ini fail tersulit hidup di Drive milik pengguna sendiri — bukan storan platform.

Ringkasan

VMP Messenger dibina di atas kriptografi standard industri dan pengangkutan — blok pembinaan yang sama yang digunakan oleh setiap pemesej selamat moden:

  • AES-256-GCM untuk penyulitan mesej.
  • OAuth 2.0 dengan PKCE dan JWT untuk pengesahan.
  • TLS 1.2+ untuk pengangkutan, dengan certificate pinning pada klien Android.
  • DTLS-SRTP untuk media suara dan video, dikuatkuasakan oleh lapisan WebRTC.
  • Storan selamat berakar perkakasan pada peranti untuk token dan kunci penyulitan setiap bilik.

Setiap lapisan dipetakan kepada spesifikasi yang diterbitkan — tiada pembinaan sifer proprietari dan tiada format wayar tertutup.