RNG dalam sistem medis: celah senyap pada pseudonim dan PKCE

Sistem informasi medis memakai bilangan acak untuk membuat pengenal, rahasia sesi, dan bukti dalam alur otorisasi. Keluaran yang kehilangan ketidakpastian tetap bisa lolos pemeriksaan panjang, tipe, dan format. Akibatnya, aplikasi terlihat normal ketika lapisan keamanan di bawahnya sudah melemah. Pola kegagalan ini sulit ditemukan melalui pemantauan fungsi bisnis saja.

Insiden Coldcard menunjukkan konfigurasi pembangkit bilangan acak (random number generator/RNG) yang keliru bisa menurunkan keamanan tanpa menghentikan pembuatan rahasia. Produsen kemudian memperbaiki jalur pembangkitan untuk nilai baru. Namun, Coinkite menyatakan pembaruan firmware tidak mengubah atau memperbaiki seed yang sudah dibuat. Sistem medis menghadapi persoalan serupa ketika nilai lama telah masuk ke basis data atau dibagikan kepada pihak lain.

Pseudonim tidak cukup dinilai dari bentuknya

Pseudonimisasi mengganti pengenal langsung dengan pseudonim agar hubungan dengan identitas tidak tampak pada kumpulan data kerja. Pseudonim bisa dibuat secara acak atau melalui transformasi yang konsisten. Keduanya membutuhkan perlindungan atas tabel penghubung, kunci, dan aturan pembuatan nilai. Pseudonim yang panjang dan unik belum membuktikan proses di belakangnya aman.

NIST SP 800-188 meminta organisasi menilai risiko sebelum melepas data hasil deidentifikasi dan menguji kemungkinan identifikasi ulang. Panduan itu tidak menempatkan penggantian nama sebagai jaminan tunggal. Atribut usia, lokasi, tanggal layanan, atau data lain masih bisa membuka hubungan dengan seseorang. Karena itu, mutu RNG harus diperiksa bersama model berbagi data dan pengendalian akses.

Generator yang mudah ditebak menambah jalur serangan ketika pseudonim dimaksudkan untuk sulit ditebak atau dipindai. Penyerang mungkin mempersempit ruang pengenal tanpa menyentuh tabel penghubung. Meski demikian, kelemahan RNG bukan satu-satunya penyebab identifikasi ulang. Kesimpulan risiko tetap memerlukan pemeriksaan struktur data, informasi eksternal, dan akses penerima.

UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi menggolongkan data dan informasi kesehatan sebagai data pribadi spesifik. Pseudonimisasi tidak menghapus kebutuhan dasar pemrosesan, pembatasan tujuan, keamanan, dan pertanggungjawaban. Pengelola sistem perlu mencatat cara pengenal dibuat dan pihak yang pernah menerimanya. Catatan itu menentukan ruang penelusuran ketika generator kemudian diketahui bermasalah.

PKCE bergantung pada rahasia yang sulit ditebak

SMART on FHIR mengatur cara aplikasi memperoleh otorisasi untuk mengakses data melalui Fast Healthcare Interoperability Resources (FHIR), standar pertukaran data medis. Kerangka ini menggunakan OAuth 2.0 dan Proof Key for Code Exchange (PKCE). Aplikasi membuat code_verifier, lalu mengirim hasil turunannya sebagai code_challenge. Server memeriksa pasangan itu sebelum menukar kode otorisasi dengan token akses.

RFC 7636 menetapkan code_verifier sebagai string acak kriptografis berentropi tinggi sepanjang 43 hingga 128 karakter. Dokumen tersebut merekomendasikan 32 oktet keluaran dari generator yang sesuai sebelum pengodean base64url. Panjang string hanya memenuhi bentuk protokol. Ketidakmampuan penyerang menebaknya bergantung pada sumber acak dan penerapannya.

SMART App Launch versi 2.2.0 mewajibkan aplikasi mendukung PKCE. Server wajib mendukung metode S256 dan dilarang mendukung metode plain. Aturan itu melindungi hubungan antara verifier dan challenge selama pertukaran. Aturan tersebut tidak menguji apakah aplikasi memakai RNG kriptografis saat membuat verifier.

Verifier yang mudah ditebak bisa memenuhi panjang dan karakter yang diwajibkan. Server tetap menemukan kecocokan karena challenge memang dibuat dari nilai yang sama. Log otorisasi lalu menunjukkan transaksi berhasil, bukan peringatan atas entropi rendah. Pemeriksaan implementasi perlu mengikuti asal nilai hingga fungsi RNG yang benar-benar dipanggil.

Uji sumber entropi berbeda dari uji fungsi aplikasi

Bilangan acak kriptografis biasanya berasal dari sumber entropi dan generator bit acak deterministik. Sumber entropi memasok ketidakpastian dari proses fisik atau sistem. Generator kemudian mengembangkan bahan itu menjadi aliran keluaran. Keduanya perlu dinilai sebagai komponen terpisah.

NIST SP 800-90B menetapkan prinsip desain, validasi, dan uji kesehatan untuk sumber entropi. Standar itu mencakup pengujian saat mulai bekerja dan pemantauan berkelanjutan terhadap kegagalan besar sumber derau. Penilaian min-entropi juga memeriksa seberapa mudah keluaran diprediksi. Uji tersebut tidak menggantikan pemeriksaan konfigurasi aplikasi atau hasil kompilasi.

Tim pengelola perlu membedakan tiga bukti. Bukti pertama menunjukkan sumber entropi lulus validasi yang relevan. Bukti kedua memastikan aplikasi produksi memanggil generator yang dimaksud dan berhenti ketika sumber wajib gagal. Bukti ketiga menghubungkan versi, konfigurasi, log, serta nilai yang telah diterbitkan agar dampak bisa ditelusuri.

Pengujian statistik atas sampel keluaran juga memiliki batas. Aliran deterministik bisa tampak seragam tanpa membawa ketidakpastian yang memadai. Sebaliknya, satu pola yang tampak ganjil belum membuktikan generator rusak. Penilaian harus memeriksa model sumber, perkiraan entropi, uji kesehatan, dan jalur integrasi.

Perbaikan dimulai dari inventaris nilai lama

Temuan RNG yang lemah tidak selesai ketika pustaka atau konfigurasi diganti. Organisasi perlu mengetahui nilai apa yang dibuat, sejak versi mana, dan ke sistem mana nilai tersebut berpindah. Pseudonim riset, verifier yang berumur singkat, kunci, dan token memiliki masa risiko berbeda. Prioritas penanganannya tidak bisa disamakan.

Nilai sementara mungkin sudah kedaluwarsa sebelum cacat ditemukan. Pseudonim dalam kumpulan data riset bisa bertahan bertahun-tahun dan tersalin ke banyak penerima. Pengelola perlu menilai apakah penggantian pengenal memutus kesinambungan penelitian atau justru mengurangi paparan. Keputusan itu membutuhkan inventaris distribusi dan catatan versi, bukan asumsi dari usia sistem.

Sampai artikel ini disusun, kami belum menemukan dokumen resmi Indonesia yang menetapkan pengujian RNG khusus untuk sistem informasi medis. Standar IETF, HL7, dan NIST memberi dasar teknis, tetapi tidak membuktikan penerapan pada fasilitas kesehatan Indonesia. Kesenjangan dokumen publik juga menghalangi perbandingan tingkat kesiapan antar-rumah sakit. Klaim kepatuhan atau kematangan nasional belum memiliki dasar yang cukup.

RNG menjadi titik buta ketika sistem hanya memeriksa apakah proses selesai. Pseudonim dan PKCE menunjukkan dua dampak berbeda dari sumber masalah yang sama. Pengendalian yang lebih kuat menghubungkan validasi entropi, konfigurasi produksi, serta penelusuran nilai lama. Tanpa tiga bukti itu, keluaran yang tampak benar belum menunjukkan perlindungan bekerja.