Model Keamanan

Bagaimana WindowsHelper melindungi PC + ponsel Anda, kriptografi apa yang kami gunakan, dan apa yang secara eksplisit tidak kami pertahankan. Terakhir diperbarui: 25-04-2026.

Siklus hidup kode penyandingan

Kode pemasangan adalah rahasia bersama yang menjadi asal setiap operasi kripto lainnya. Siklus hidup penuh:

[ Ponsel MEMBUAT kode acak 8 karakter ]
   ↓
[ Ponsel MENULIS kode + sessionId ke Firestore di dokumen pc_connections ]
   ↓
[ Ponsel MENAMPILKAN kode kepada pengguna di layar ]
   ↓
[ Pengguna MEMBACA kode dan mengetiknya di kolom masukan Companion ]
   ↓
[ Companion MENCARI di Firestore sesi menunggu yang cocok dengan kode ]
   ↓
[ Kedua sisi MENURUNKAN kunci enkripsi dari SHA-256(kode, sessionId) ]
   ↓
[ Kode TETAP di memori kedua sisi; tidak satu pun menulisnya ke Firestore ]
   ↓
[ Pemutusan / penyandingan ulang MENGHAPUS kode di kedua sisi ]

• Acak: kode yang dihasilkan melalui RNG yang aman secara kriptografis.
• Alfabet 30 karakter × 8 posisi ≈ 656 miliar kombinasi. Tidak menyertakan I, L, O, Z, 0, dan 1 untuk menghindari kerancuan visual, bukan karena alasan keamanan — ruang kode cukup padat sehingga jendela brute force 10 menit, dengan batas laju Firestore, tidak mungkin dilakukan.
• Disimpan terenkripsi di PC ini. Companion menyimpan kode di Registry akun Windows Anda, terenkripsi dengan DPAPI, agar dapat menyambung lagi setelah restart.
• Dihapus saat Anda memutus sambungan dan membersihkan sesi, mengganti kode, atau mencopot pemasangan. Menutup aplikasi tetap menyimpannya, agar Companion dapat menyambung lagi.

Kriptografi

AES-256-GCM (kerahasiaan perintah + integritas)

Setiap perintah yang dikirim melalui kabel dienkripsi dengan AES-256-GCM, mode enkripsi terotentikasi.

• Kunci: 256 bit, diturunkan sebagai SHA-256("WH_SECURE_{code}_{sessionId}_CMD_KEY").
• Nonce: 96 bit (12 byte), dihasilkan baru per pesan melalui Random.secure() di telepon atau RandomNumberGenerator di sisi Companion.
• Tag autentikasi: 128 bit (16 byte), ditambahkan ke ciphertext.
• Format kawat: AESGCM:<nonce_b64>:<ciphertext_b64>:<tag_b64>
• Keamanan penggunaan ulang nonce: Nonce 96-bit dari CSPRNG menjaga probabilitas tabrakan menurut paradoks ulang tahun di sekitar 2⁻³² sepanjang 2³² pesan pada satu kunci sesi — batas standar untuk nonce GCM acak, dan jauh melampaui volume perintah mana pun yang masuk akal.

HMAC-SHA256 (keaslian perintah)

Setiap perintah juga membawa tanda tangan HMAC sehingga telepon yang tidak mengetahui kode penyandingan tidak dapat memasukkan perintah meskipun dapat menulis ke Firestore.

• Kunci: 256 bits, derived as SHA-256("WH_SECURE_{code}_{sessionId}_HMAC_KEY"). Pisahkan dari kunci enkripsi.
• Ruang lingkup lapangan: HMAC-SHA256(hmacKey, commandId | ciphertext | sentAtMillis). Pipa-pipa tersebut adalah karakter pipa literal, bukan pembatas — tiga string yang digabungkan.
• Urutan verifikasi: HMAC diverifikasi sebelum dekripsi. Pesan palsu tidak menghabiskan satu siklus CPU pun untuk operasi kriptografi.

Model ancaman

Ancaman	Status	Catatan
Penyadap di jaringan lokal	Dimitigasi	Teks sandi AES-GCM tidak tembus cahaya bagi pengamat MITM.
Menguping di server Firestore	Dimitigasi	Google melihat blob AESGCM:..., bukan perintah.
Penyerang yang dapat menulis ke Firestore namun tidak mengetahui kodenya	Dimitigasi	Verifikasi HMAC gagal; Companion mencatat penolakan dan menolak menjalankannya.
Penyerang yang memecahkan/memphis kode penyandingan	Sisa	Mereka dapat mengeluarkan perintah seolah-olah mereka adalah penggunanya. Mitigasi: memutar kode dari menu baki.
Memutar ulang perintah yang direkam	Sisa	sentAtMillis terikat HMAC; Companion belum menerapkan jendela masa berlaku. Perbaikan mendatang akan menambahkan masa kedaluwarsa.
Penyerang tidak diautentikasi dalam mode LAN	Dimitigasi	Jabat tangan pasangan WebSocket memvalidasi kode; Gerbang HMAC + AES setiap perintah berikutnya.
Ponsel yang disusupi dengan kunci penyandingan yang dicuri	Sisa	Tidak dapat dibedakan dari "pengguna itu sendiri". Mitigasi: batas kecepatan (10 cmd/mnt) + konfirmasi perintah destruktif memerlukan klik di sisi PC.
Perintah salah ketik dari aplikasi telepon	Dimitigasi	Daftar izin di sisi ponsel memblokir awalan yang tidak dikenal; pemeriksaan awal di sisi Companion memblokir perintah yang menyasar layanan yang tidak ada.
Perintah destruktif dijalankan secara tidak sengaja	Dimitigasi	Jendela di sisi Companion meminta klik pengguna untuk menyetujui Remove-Item, Format-Volume, reg delete, shutdown /r, dan sejenisnya.
Proses PowerShell macet/tidak berjalan	Dimitigasi	Setiap perintah dibatasi waktu — 5 menit secara bawaan, 45 untuk perbaikan berdurasi panjang, 60 pada batas keras — dan seluruh pohon proses dihentikan.
Companion .exe mengganggu antara pengunduhan dan pengoperasian	Dimitigasi	SHA-256 dipublikasikan di companion-version.json; pengguna dapat memeriksanya. Penandatanganan Authenticode direncanakan sebelum peluncuran.
Companion kondisi sensitif kebocoran bocor	Dimitigasi	Laporan kerusakan + penulisan balik kesalahan Firestore dibersihkan %USERPROFILE% / %MACHINE% / %USER%.
Perangkat dicuri, kunci pemasangan Registry tetap ada	Dimitigasi	Kode penyandingan yang ada dienkripsi dengan Windows DPAPI (per akun), sehingga tidak dapat dibaca dari disk yang disalin atau akun Windows lain.

Di luar jangkauan

Hal-hal yang secara eksplisit tidak dilindungi WindowsHelper:

• Akun Windows disusupi menjalankan pendampingnya. Kami berasumsi PC pengguna adalah miliknya. Penyerang dengan admin di PC pengguna telah menang.
• Biner aplikasi telepon yang disusupi. Kami tidak menyetujui build Android/iOS yang dirancang untuk mencegah gangguan di luar apa yang disediakan oleh toko aplikasi platform.
• Lawan tingkat negara yang punya sumber daya untuk membobol Firestore milik Google atau otoritas sertifikat yang menopang HTTPS. Produk ini ditujukan untuk ancaman tingkat pengguna biasa — peretas amatir, pengintip iseng, anggota rumah tangga yang kesal — bukan pemerintah.
• Serangan kanal samping pada AES-GCM lewat analisis daya / elektromagnetik. Companion bukan kartu pintar.

Pengungkapan

• Surel support@windowshelper.app dengan subjek [security].
• Harap sertakan nomor versi, langkah repro, dampak, dan perbaikan ideal.
• Kami berupaya membalas dalam 48 jam dan menilai tingkat keparahan dalam seminggu. Masalah berat mendapat rilis di luar siklus biasa.
• Jangka waktu pengungkapan: 90 hari sejak laporan awal, atau lebih awal berdasarkan kesepakatan bersama.
• Saat ini tidak ada hadiah bug berbayar — kami memberi kredit kepada reporter dalam catatan rilis (dengan izin).