Dalam masa pandemi ini, Google dan Apple bekerja sama dalam proyek untuk penelusuran kontak yang tetap menjaga privasi. Ini merupakan salah satu dari beberapa protokol tracing yang saat ini sedang bersaing di berbagai negara. Sebagian protokol yang direncanakan di berbagai negara sifatnya tersentralisasi, dan sebagian terdesentralisasi. Apple dan Google membuat protokol terdesentralisasi dan menyerahkan masalah pembuatan aplikasi untuk end user ke masing-masing negara.
Saat ini hampir semua ponsel sudah memiliki fitur Bluetooth Low Energy (BLE). BLE ini sekarang digunakan untuk koneksi berbagai device yang sudah sangat populer, misalnya jam pintar dan timbangan pintar. Dengan protokol contact tracing, BLE bisa digunakan untuk menyiarkan data yang mengumumkan keberadaan kita dan sekaligus mencatat keberadaan ponsel-ponsel di sekitar kita. Jika ada orang yang kemudian hari didapati positif, kita bisa diberi tahu jika pernah berdekatan dengan orang tersebut.
Protokol Google/Apple Privacy-Preserving Contact Tracing Project dibuat diilhami oleh protokol DP-3T (Decentralized Privacy-Preserving Proximity Tracing). Salah satu alasan Google dan Apple mengimplementasikan ini di level sistem operasi karena berbagai batasan aplikasi biasa ketika mengakses bluetooth di latar belakang. Dengan implementasi dari Apple dan Google, kendali bluetooth ini bisa dilakukan di level sistem operasi dan akan lebih mulus dan hemat batere. Google dan Apple juga merupakan dua penguasa sistem operasi mobile saat ini dan jika keduanya membuat protokol yang kompatibel, maka dipastikan bisa berjalan lancar untuk hampir semua orang.
Contents
Penjelasan Awam
Google dan Apple hanya membuat fungsi-fungsi (atau istilah tepatnya API: application programming interface) untuk bagian encounter logging (pencatatan ketika terjadi kontak). Masalah pelaporan dan penanganan lebih lanjut diserahkan ke masing-masing yang berwenang di suatu negara. Kabar terakhir menyatakan bahwa Google dan Apple hanya akan menyetujui satu aplikasi per negara, kecuali jika memang penanganan dilakukan per propinsi atau per negara bagian di suatu negara.
Sebuah aplikasi contact tracing yang memakai protokol dari Google/Apple tidak boleh memiliki permission untuk mengakses lokasi saat ini (tidak akan disetujui masuk Google Play/App Store). Jadi aplikasi yang dibuat menggunakan protokol ini harus benar-benar menjaga privasi penggunanya. Tapi masalah privasi ini kadang tidak disukai banyak negara yang ingin mengetahui di mana lokasi kejadian seputar COVID 19 ini, jadi banyak negara merencanakan protokol masing-masing.
Saya sederhanakan cara kerjanya seperti ini:
- Setiap saat ponsel kita menyiarkan waktu saat ini yang terenkripsi dengan kunci tertentu (jadi yang diterima device lain seolah-olah hanya bilangan acak). Kunci ini berganti tiap 10 menit. Ponsel akan menyimpan semua kunci yang dipakai dalam 14 hari terakhir
- Ponsel kita mendengarkan semua data terenkripsi yang disiarkan ponsel sekitar dan menyimpan sampai 14 hari (tanpa bisa mengetahui apa makna masing-masing angka ini)
- Jika suatu saat seseorang positif, maka semua kunci 14 hari terakhir dari orang tersebut bisa diupload ke suatu situs (dengan persetujuan dokter)
- Aplikasi akan mendownload semua kunci pasien positif dari website terpercaya dan mencoba membuka semua bilangan terenkripsi yang pernah diterima. Jika ada kunci yang cocok maka Anda mungkin tertular
Teknis
Nah sekarang masuk kebagian teknis bagaimana protokol ini bekerja. Ada dua bagian penting: bagaimana data ditransmisikan dan apa yang terjadi ketika ada yang positif COVID 19.
Transmisi data
Setiap device Bluetooth Low Energy (BLE) akan memiliki berbagai fitur yang bisa dilakukan (misalnya: headset bisa memiliki fitur mikrofon dan memiliki fitur status baterenya bisa dibaca). Semua fitur ini disebutkan dalam daftar layanan (service) yang bisa dilakukan oleh sebuah device (misalnya: “saya melayani permintaan pengecekan status batere saat ini”). Masing-masing service ini memiliki ID unik tertentu.
Dalam implementasi contact tracing. Setiap ponsel akan mengimplementasikan BLE service dengan ID 0xFD6F (Exposure Notification Service) dengan advertising Payload (isi data) sebesar 20 byte. Data ini terdiri dari dua bagian: 16 Byte Rolling Proximity Identifier (RPI terenkripsi) dan Associated Encrypted Metadata (AEM, juga terenkripsi).
Sebagai catatan, dalam dunia Bluetooth Low Energy, istilah “Advertising payload” tidak ada hubungannya dengan iklan komersial. Sebuah device biasanya akan mengumumkan (atau dalam istilah BLE: mengiklankan) kepada dunia: saya ini jenis device X (misalnya ponsel) dengan nama tertentu (misalnya: “Ponsel Joe”). Karena yang digunakan adalah Advertising payload, maka protokol ini cepat (tidak butuh handshake ataupun proses koneksi ke device lain).
Setiap hari (tiap 1440 menit) setiap ponsel akan menghasilkan Temporary Exposure Key (TEK) dengan random number generator yang aman. TEK ini panjangnya 16 byte. Dari TEK ini dihasilkan dua key: RPI Key dan AEM Key dengan algoritma HKDF (HMAC-based Extract-and-Expand Key Derivation Function, standar RFC 5869). Intinya: jika kita punya TEK, maka kita bisa membuat RPI key dan AEM key, tapi tidak bisa sebaliknya: jika mengetaui RPI Key dan/atau AEM Key saat ini, tidak bisa tahu TEK.
Berbagai algoritma protokol ini memakai waktu (jam berapa) saat ini, tapi resolusi yang dipakai bukan dalam detik melainkan durasi 10 menit. Jadi sebelum masuk ke algoritma tertentu, waktu saat ini dibuat diskrit dengan interval 10 menit (60 detik x 10). Nomor interval saat ini (EIntervalNumber) formulanya adalah UNIX TimeStamp dibagi (60*10), tipe datanya adalah unsigned integer 32 bit.
Device diwajibkan menyimpan 14 key dari 2 minggu terakhir. Setiap 10 menit RPI key dan AEM key baru dihasilkan. RPI Key dihasilkan berdasarkan TEK hari ini menggunakan salt “EN-RPIK”. RPI adalah data yang dienkrip dengan RPI Key. Data ini berisi string “EN-RPI” diikuti 6 byte NUL (0x00), dan diakhiri dengan nomor interval (EIntervalNumber) saat ini.
Di dalam protokol didefinisikan metadata 4 byte (Associated Metadata) yang isinya tidak disebutkan apa, hanya dinyatakan bahwa ini tidak untuk mengidentifikasi user. Di masa depan kemungkinan data ini diisi dengan RSSI (Received signal strength indication) alias kuatnya signal bluetooth untuk memperkirakan jarak. AEM Key dihasilkan menggunakan salt “EN-AEMK”. Metadata dienkrip dengan AES-CTR (bukan AES biasa) menggunakan AEM Key untuk membuat AEM.
Diagnosis Positif
Bagian berikutnya adalah: apa yang terjadi jika seseorang positif kena COVID-19. Apple dan Google tidak memberikan server untuk mengupload informasi ini, ini harus disediakan masing-masing pembuat aplikasi dari satu negara. Tapi format file data untuk pertukaran informasi dibuatkan standardnya.
Ketika seseorang positif terkena COVID 19, maka dokter bisa memberikan akses ke aplikasi pasien agar pasien bisa mengupload TEK 14 hari terakhir ke server (server masing-masing aplikasi/negara, bukan servernya Apple atau Google). Masalah siapa yang bisa memberi hak upload ini ditentukan masing-masing pembuat aplikasi/masing-masing negara.
TEK ini hanya ukurannya 16 byte x 14 hari = 224 byte. TEK ini tidak pernah ditransfer ke server jika tidak ada diagnosa positif. Jadi data yang diupload pasien positif sangat kecil. Andaikan ada 5000 pasien baru dalam sehari, maka datanya hanya 1.2Mb yang perlu didownload setiap hari. Dari TEK bisa dihasilkan RPK Key dan AEM key, jadi tidak perlu mengupload seluruh key yang dihasilkan tiap 10 menit.
Lalu bagaimana dengan data yang diterima dari device sekitar selama kita bepergian, tidakkah ukurannya akan besar? Andaikan tiap menit selama 24 jam kita bertemu 100 orang (angka ini sangat tinggi), maka kita butuh: 1440 (menit) x 100 orang x 20 byte data = 2.8 Mb. Andaikan data yang disimpan lebih dari 20 byte (mungkin ada informasi tambahan), tetap saja data yang disimpan sangat kecil, tidak lebih dari ukuran beberapa foto.
Setelah mendapatkan semua key, ponsel seorang pengguna bisa mencoba mendekrip semua data yang pernah diterimanya dari ponsel sekitar. Jika ada data yang berhasil didekrip (akan menghasilkan string “EN-RPIK” di prefixnya), maka bisa dicek apakah semua data lain bisa didekripsi, dan jika benar, maka pengguna ponsel tersebut pernah melakukan kontak/berdekatan dengan penderita dan perlu ditest apakah positif tertular atau tidak. Atau mungkin cukup bijaksana untuk mengkarantina diri.
Keamanan
Protokol contact tracing ini cukup sederhana dan menarik dan bisa diimplementasikan dengan mudah menggunakan device lain non ponsel (misalnya kita ingin device smartwatch untuk tracing). Dari segi privasi, protokolnya cukup aman.
Masih ada kemungkinan seseorang membuat tracker berdasarkan protokol ini, tapi effortnya cukup besar dan menurut saya tidak praktis. Misalnya begini: saya bisa membuat device yang mendengarkan semua ponsel dengan ESP32 (harga: sekitar 5 USD), dan saya letakkan device ini di beberapa tempat. Jika saya menaruh ini di banyak tempat, lalu ada orang yang positif, saya bisa mengecek log di berbagai tempat, mana saja yang dikunjungi orang tersebut. Dalam kasus tertentu mencocokkan waktu dengan kamera CCTV bisa cukup untuk mengidentifikasi seseorang (meski intervalnya 10 menit). Tapi pencocokkan ini hanya bisa dilakukan jika orang tersebut positif dan mengupload TEK-nya.
Penutup
Cerita di posting ini dirangkum dari informasi yang tersedia di situs Apple dan Google dan saya sederhanakan ceritanya. Protokol yang lebih detail dan akurat bisa dilihat di:
https://www.apple.com/covid19/contacttracing (Apple)
Dan
https://www.google.com/covid19/exposurenotifications/ (Google)
Dokumen yang tersedia sangat lengkap, bahkan sampai contoh penggunaan API-nya.