• Kompromi perangkat fisik: Ponsel/tablet surveyor dicuri atau disita di lapangan
• Ekstraksi database lokal: File SQLite/GeoPackage diekstrak via ADB, backup iTunes, atau akses root/jailbreak
• Manipulasi data offline: Penyerang memodifikasi geometri, atribut, atau metadata sebelum sinkronisasi
• Replay attack saat sinkronisasi: Paket data lama dikirim ulang untuk menimpa pembaruan legitimate
• Kunci enkripsi statis: Kunci hardcoded di aplikasi diekstrak melalui reverse engineering

Perbedaan fundamental: tidak ada server yang tersedia untuk memvalidasi, mencabut akses, atau memutar kunci secara real-time. Semua keputusan keamanan harus dieksekusi lokal di perangkat edge.

Karakteristik Workflow Lapangan Indonesia

Konteks operasional di Indonesia menambah kompleksitas:

• Durasi offline: 3-30 hari untuk tim survei hutan, peta perkebunan, atau pemetaan pulau terpencil
• Perangkat heterogen: Campuran Android (versi 8-14), iOS, laptop rugged, drone dengan storage onboard
• Tim rotasi: Surveyor berganti shift; perangkat dibagikan antar personel
• Konektivitas burst: Sinkronisasi hanya saat sampai pos jaga dengan VSAT/4G, atau via data mule (flash disk dikirim fisik)
• Regulasi UU PDP & Peraturan BSSN: Data spasial tertentu (batas administrasi, titik strategis) wajib enkripsi at-rest dan audit trail

Arsitektur Keamanan Lapisan Ganda untuk Edge Offline

Lapisan 1: Enkripsi Database Lokal dengan Kunci Turunan Perangkat

Setiap perangkat lapangan harus memiliki database terenkripsi yang unik, tidak berbagi master key global. Pola yang direkomendasikan:

// Konsep arsitektur kunci (pseudocode)
DeviceMasterKey = HKDF(master_seed, device_unique_id + "WebGIS-Field")
DatabaseKey = HKDF(DeviceMasterKey, "db-encryption-v1")
KeyEncryptionKey = HKDF(DeviceMasterKey, "key-wrap-v1")

Implementasi praktis:

• SQLCipher untuk SQLite/GeoPackage (AES-256, PBKDF2 256k iterasi)
• SQLite Encryption Extension (SEE) alternatif komersial dengan performa lebih baik
• iOS Data Protection + Android Keystore/StrongBox untuk menyimpan DeviceMasterKey di hardware-backed keystore
• Zero-knowledge provisioning: Kunci dibuat di perangkat saat inisialisasi pertama, tidak pernah dikirim ke server

Penting: Hindari hardcoded salt atau static IV. Gunakan per-database random salt disimpan di header file terenkripsi.

Lapisan 2: Autentikasi Tanpa Jaringan via Sertifikat Perangkat

Gantikan password/PIN dengan autentikasi berbasis sertifikat X.509 yang dikelola sepenuhnya di perangkat:

1. Provisioning awal (di kantor, online):
   • CA internal menerbitkan sertifikat perangkat (valid 1-2 tahun)
   • Sertifikat + kunci privat disimpan di Android Keystore (StrongBox) / iOS Secure Enclave
   • Tidak bisa diekspor (setExtractable(false))
2. Autentikasi harian (offline):
   • Aplikasi meminta biometric prompt (sidik jari/face ID)
   • Keystore/Enclave menandatangani challenge acak dengan kunci privat
   • Tanda tangan diverifikasi lokal menggunakan sertifikat publik perangkat
   • Jika valid → kunci database didekripsi di memori
3. Pencabutan (saat online):
   • Server memeriksa CRL/OCSP saat sinkronisasi
   • Perangkat dicoret → sertifikat dicabut → kunci database tidak bisa dibuka

Keuntungan: Tidak ada shared secret, tahan terhadap shoulder surfing, dan non-repudiation bawaan (siapa yang membuka database terekam di log hardware).

Lapisan 3: Integritas Data & Tamper-Evident Logging

Setiap modifikasi data spasial harus menghasilkan bukti kriptografis yang tidak bisa dipalsukan offline:

// Struktur entry log tamper-evident
{
  "seq": 1247,
  "timestamp": "2024-01-15T06:42:11Z",  // dari GPS/clock terpercaya
  "user_cert_sha256": "a1b2...",
  "operation": "UPDATE_GEOMETRY",
  "feature_id": "plot-8842",
  "prev_hash": "e3f4...",  // hash entry sebelumnya
  "data_hash": "sha256(new_geometry + attributes)",
  "signature": "ECDSA_P256(priv_key, prev_hash + data_hash)"
}

Mekanisme ini memungkinkan deteksi:

• Penghapusan entry log (rantai hash putus)
• Modifikasi data tanpa log (hash tidak cocok)
• Penyisipan entry palsu (tidak bisa ditandatangani tanpa kunci privat perangkat)

Saar sinkronisasi, server memverifikasi rantai hash dan semua tanda tangan. Entry yang gagal diverifikasi ditandai dan dikuarantinakan untuk investigasi.

Strategi Sinkronisasi Aman: Dari Offline ke Online

Desain Conflict Resolution yang Tahancryptographic

Konflik data terjadi ketika data yang sama dimodifikasi offline di beberapa perangkat, atau di perangkat dan server. Pendekatan standar “last write wins” berbahaya untuk data spasial. Gunakan model CRDT (Conflict-free Replicated Data Type) atau Operational Transform dengan verifikasi kriptografis:

• Version vector per fitur: Setiap fitur membawa vektor versi per perangkat
• Merge deterministic: Aturan merge terdefinisi di kode (bukan keputusan manual)
• Bukti merge: Hasil merge ditandatangani oleh kunci server + kunci perangkat asal
• Audit trail lengkap: Semua versi disimpan, tidak ada data yang terhapus permanen

Contoh aturan merge untuk geometri polygon lahan:

1. Jika hanya atribut berubah → gabung atribut (union)
2. Jika geometri berubah di kedua sisi → hitung union geometri, flag untuk review manual
3. Jika satu sisi menghapus fitur → soft delete (flag deleted=true), geometri dipertahankan

Protokol Sinkronisasi dengan Forward Secrecy

Meskipun offline bertahun-tahun, sinkronisasi tidak boleh mengungkap kunci lama. Gunakan Double Ratchet atau Signal Protocol yang disesuaikan untuk batch sync:</p

// Ringkasan alur kunci sinkronisasi
1. Device & Server punya shared root key (dari provisioning awal)
2. Setiap sesi sinkronisasi:
   - Device generate ephemeral key pair (X25519)
   - Kirim public key + signed device cert
   - Server verifikasi cert, generate ephemeral key pair
   - DH shared secret = X25519(device_priv, server_pub)
   - Session key = HKDF(root_key, DH_shared)
   - Root key = HKDF(root_key, DH_shared + "next")  // forward secrecy
3. Semua payload sinkronisasi dienkripsi AES-GCM dengan session key
4. Setelah selesai, session key dibuang
5. Compromise session key tidak membuka sinkronisasi sebelumnya/selanjutnya

Ini memastikan: kompromi kunci sesi saat ini tidak membocorkan data sinkronisasi masa lalu atau masa depan.

Penanganan Data Mule (Sinkronisasi Fisik)

Di wilayah tanpa sinyal sama sekali, data dibawa fisik via flash disk/HDD ke titik konektivitas. Risiko: media hilang, dicuri, atau dimodifikasi di jalan. Mitigasi:

• Enkripsi media: Seluruh volume flash disk dienkripsi VeraCrypt/LUKS dengan passphrase yang dikirim via channel terpisah (SMS/Telegram terenkripsi/telepon)
• Integritas media: File manifesto JSON berisi SHA-256 setiap file + ditandatangani kunci privat perangkat
• Tamper-evident seal: Segel fisik bernomor unik pada port USB/flash disk
• Chain of custody log: Formulir digital ditandatangani setiap penyerah-penerima

Manajemen Kunci Jangka Panjang Tanpa Koneksi

Masalah Key Rotation Offline

Standar industri merekomendasikan rotasi kunci enkripsi setiap 90-365 hari. Tapi perangkat offline 6 bulan tidak bisa menerima kunci baru dari server. Solusi:</p

Pendekatan Hierarchical Deterministic Key Derivation

Gunakan struktur mirip BIP-32/BIP-44 untuk menghasilkan kunci periode dari master seed:

MasterSeed (256-bit, di HSM/Keystore perangkat)
  └── m/44'/1'/0'  // purpose=44, coin_type=1 (WebGIS), account=0
        └── 0'     // change=0 (external)
              ├── 0  // periode 0: hari 1-90
              ├── 1  // periode 1: hari 91-180
              ├── 2  // periode 2: hari 181-270
              └── ...

KunciPeriode(n) = HDDerive(MasterSeed, path="m/44'/1'/0'/0/" + n)
DatabaseKeyPeriode(n) = HKDF(KunciPeriode(n), "db-enc")

Keuntungan:

• Server dan perangkat sinkronisasi tanpa pertukaran kunci — keduanya menghitung kunci yang sama dari master seed dan nomor periode
• Forward secrecy: Kompromi kunci periode-n tidak mengungkap periode <n
• Key escrow opsional: Master seed dibagi via Shamir Secret Sharing ke 3 pejabat (kepala tim, IT security, manajer operasi) — butuh 2 dari 3 untuk recovery

Penanganan Key Compromise Saat Offline

Jika surveyor melapor perangkat dicuri di hari ke-15 (periode 0):

1. Tim di kantor menandai perangkat sebagai compromised di server
2. Server menerbitkan Certificate Revocation List (CRL) dengan serial number sertifikat perangkat
3. Perangkat lain yang sinkronisasi nanti akan menolak data dari perangkat dicuri (verifikasi CRL)
4. Data yang sudah tersinkronisasi sebelum pencurian tetap valid — hanya data baru dari perangkat itu yang ditolak
5. Perangkat pengganti diprovisioning dengan sertifikat baru, master seed baru

Tidak perlu re-encrypt database lama di server — kunci periode lama sudah diketahui server dari derivasi HD.

Implementasi per Sektor: Studi Kasus Konseptual

Kehutanan: Inventaris Hutan Produksi (30 Hari Offline)

Profil: 5 tim × 3 orang, 15 tablet Android rugged, area 50.000 ha Kalimantan Tengah.

Kontrol Khusus:

• Geofencing kunci: Database hanya bisa dibuka jika GPS mendeteksi lokasi di area tugas (radius 5 km dari basecamp). Mencegah akses data di kota.
• Auto-wipe: 3x gagal biometrik → hapus DeviceMasterKey dari Keystore (data tidak bisa dipulihkan tanpa master seed escrow)
• Sinkronisasi bertahap: Data prioritas (titik ilegal logging, kebakaran) dikirim via SMS gateway terenkripsi saat sinyal lemah; data bulk menunggu VSAT

Perkebunan: Pemetaan Blok Kelapa Sawit (Rotasi 14 Hari)

Profil: 50 surveyor, shift 2 minggu, perangkat dibagikan antar shift.

Kontrol Khusus:

• Multi-user per perangkat: Setiap surveyor punya sertifikat sendiri; Keystore menyimpan 10+ sertifikat. Login = pilih nama + biometrik.
• Audit trail per orang: Setiap edit fitur tertanda tangan sertifikat surveyor aktif — akuntabilitas individual meski perangkat shared.
• Rapid provisioning: CA internal di laptop koordinator lapangan (offline CA via smallstep/cfssl) menerbitkan sertifikat baru surveyor baru dalam 2 menit tanpa internet.

Kelautan: Pemetaan Terumbu Karang via Drone (Offline 7 Hari di Kapal)

Profil: Drone + laptop rugged di kapal survei, 2 TB data citra + vektor per hari.

Kontrol Khusus:

• Hardware encryption: NVMe drive dengan AES-256 hardware (OPAL 2.0/TCG), kunci di TPM 2.0 laptop
• Immutable storage: Data mentah drone ditulis sekali (WORM) via software-defined storage — tidak bisa dimodifikasi tim di kapal
• Pre-commit verification: Sebelum sinkronisasi ke server pusat, data diverifikasi checksum & signature di laptop koordinator

Checklist Kesiapan Keamanan Offline-First

Tantangan Implementasi & Solusi Praktis

1. Performa Enkripsi di Perangkat Endah

Enkripsi AES-256 per halaman database (4 KB) menambah overhead 5-15% pada operasi read/write. Solusi:

• Gunakan AES-NI / ARM Crypto Extensions (tersedia di semua CPU modern)
• Batch write: kumpulkan edit di memori, commit sekali per 5 detik
• Indeks spasial (R-tree) tetap di dalam database terenkripsi — jangan pindahkan ke file terpisah

2. Ukuran Aplikasi & Update Offline

Aplikasi WebGIS offline-first (mbtiles, vector tiles, database) bisa >5 GB. Update via Play Store/App Store butuh bandwidth. Solusi:

• Delta update: Hanya kirim file yang berubah (bsdiff/courgette)
• Sideload update: File APK/IPA + asset dienkripsi, dikirim via data mule, diinstall via MDM atau manual
• Verifikasi signature: Update harus ditandatangani kunci release organisasi, diverifikasi sebelum install

3. Jam Sistem & Timestamp Offline

Timestamp dari jam sistem tidak bisa dipercaya (bisa diubah user). Solusi:

• GPS time sebagai referensi utama (akurasi ±100 ns)
• Trusted timestamp counter: Monotonic counter di TPM/Keystore (tidak bisa di-set mundur)
• Logika validasi: Server menolak entry dengan timestamp > sekarang + 5 menit atau < last_sync – 1 hari

4. Kepatuhan UU PDP & Regulasi Sektoral

Data spasial tertentu dikategorikan Data Pribadi Sensitif (lokasi rumah warga, titik sumber daya strategis) atau Data Strategis Nasional. Implikasi:

• DPIA (Data Protection Impact Assessment) wajib sebelum deployment offline-first
• Data minimization: Hanya bawa data yang dibutuhkan tugas (subset spatial + atribut minimal)
• Retention policy: Hapus data lokal otomatis setelah sinkronisasi terverifikasi + grace period 7 hari
• Breach notification: Jika perangkat dicuri dengan data sensitif → lapor ke Kominfo & BSSN dalam 3×24 jam (UU PDP Pasal 46)

Roadmap Kematangan Keamanan Offline-First

Organisasi sebaiknya menargetkan **Level 3 dalam 12-18 bulan** untuk operasi lapangan skala menengah-besar. Level 4-5 memerlukan investasi R&D dan kemitraan vendor hardware.

Kesimpulan

Keamanan Keamanan Infrastruktur Jaringan WebGIS untuk operasi offline-first bukan sekadar menambahkan enkripsi ke database lokal. Ia membutuhkan arsitektur lengkap yang mencakup: derivasi kunci hierarkis tanpa server, autentikasi berbasis hardware yang non-repudiable, logging tamper-evident yang diverifikasi kriptografis, protokol sinkronisasi dengan forward secrecy, dan strategi manajemen kompromi kunci yang berfungsi tanpa koneksi jaringan.

Dengan pendekatan ini, organisasi di Indonesia — dari Kementerian Kehutanan, perusahaan perkebunan, Badan Geologi, hingga BPBD — dapat mengamankan pengumpulan data spasial di wilayah terpencil tanpa mengorbankan integritas, keakuntabilitas, maupun kepatuhan regulasi. Kunci suksesnya: **desain keamanan yang mengasumsikan offline sebagai default, bukan pengecualian**.

FAQ

Apakah enkripsi database lokal cukup melindungi data jika perangkat dicuri?

Enkripsi database (SQLCipher/SEE) dengan kunci di hardware keystore (StrongBox/Secure Enclave/TPM) memberikan perlindungan kuat. Namun, jika penyerang memiliki akses fisik tak terbatas, waktu lama, dan kemampuan hardware attack (side-channel, fault injection, decapping), tidak ada jaminan absolut. Oleh karena itu: (1) aktifkan auto-wipe setelah N gagal autentikasi, (2) gunakan geofencing akses, (3) batasi data sensitif yang dibawa ke lapangan (data minimization).

Bagaimana cara memverifikasi integritas data yang disinkronkan via data mule (flash disk)?

Gunakan manifesto file (JSON) yang berisi: daftar file, SHA-256 masing-masing, timestamp, device ID, dan ditandatangani kunci privat perangkat (ECDSA P-256). Di sisi penerima, verifikasi tanda tangan dengan sertifikat publik perangkat, lalu bandingkan hash file. Jika ada ketidaksesuaian → tolak dan investigasi.

Apakah HD key derivation (BIP-32 style) aman untuk rotasi kunci database?

Ya, asalkan: (1) master seed 256-bit dihasilkan CSPRNG dan disimpan di HSM/Keystore hardware, (2) path derivasi standar (m/44’/1’/0’/0/n) dengan hardened derivation (tanda apostrof) agar kompromi child key tidak bocorkan parent, (3) periode kunci cukup pendek (90 hari) untuk membatasi jendela eksposur. Ini adalah pola yang terbukti di kriptografi wallet kripto dan adaptif untuk WebGIS.

Bagaimana menangani surveyor yang berganti perangkat di tengah tugas (misal tablet rusak)?

Gunakan offline CA (misal smallstep atau cfssl di laptop koordinator) untuk menerbitkan sertifikat baru ke perangkat pengganti dalam hitungan menit. Data dari perangkat lama yang sudah tersinkronisasi ke server tetap valid. Perangkat baru memulai dengan periode kunci saat ini (derivasi dari master seed yang sama). Jika master seed tidak tersedia di lapangan, gunakan key escrow Shamir (2-of-3) untuk merecovery master seed ke perangkat baru.

Apakah pendekatan ini memenuhi persyaratan ISO 27001 / SNI ISO 27001?

Ya, dengan catatan: (A.8.2.4) Manajemen kunci kriptografis — HD derivation + hardware keystore + escrow memenuhi. (A.8.1.1) Inventaris aset — setiap perangkat punya sertifikat unik & tercatat. (A.12.4.1) Logging kejadian — tamper-evident log memenuhi. (A.13.2.1) Perlindungan informasi transfer — enkripsi media fisik + signature memenuhi. (A.16.1) Manajemen insiden — auto-wipe + CRL + breach notification flow memenuhi. Dokumentasikan semua kontrol dalam Statement of Applicability.