Lapisan privasi Newton membuat klaim keamanan yang presisi: ketika data pribadi dienkripsi dan diunggah, ciphertext secara kriptografis terikat pada kebijakan tertentu dan rantai tertentu.
Coba putar ulang sampul terenkripsi yang sama itu di tempat lain—kebijakan yang berbeda, rantai yang berbeda—dan pemeriksaan autentikasi langsung gagal.
Dekripsi ditolak. Saya ingin melihat tepatnya apa yang dicakup oleh "terikat pada", dan, yang tak kalah penting, apa yang tidak dicakup.
Ini rumus aslinya.
Data autentikasi tambahan yang melekat pada enkripsi dihitung dari tepat dua masukan: klien kebijakan dan ID rantai, di-hash bersama.
Hash itu menjadi bagian dari apa yang diautentikasi oleh algoritme enkripsi bersama dengan ciphertext itu sendiri.
Jika salah satu input berubah — kebijakan yang berbeda, chain yang berbeda — seluruh tag autentikasi rusak, dan algoritme menolak untuk mendekripsi.
Itu jaminan yang kuat dan cakupannya jelas, dan persis jenis perlindungan yang Anda ingin miliki untuk melawan upaya seseorang mengambil payload terenkripsi yang valid lalu menggunakannya kembali dalam konteks yang sebenarnya tidak pernah dimaksudkan.
Namun, pemanggilan unggah yang membawa ciphertext ini tidak hanya membawa ciphertext dan dua nilai terikat tersebut.
Ia juga membawa waktu-ke-hidup (time-to-live) — sebuah nilai yang menentukan berapa lama potongan data ini dimaksudkan untuk tetap valid atau bisa diambil sebelum kedaluwarsa.
Dan ketika saya memeriksa apa yang benar-benar masuk ke rumus data yang diautentikasi, TTL tidak ada di dalamnya.
Rumusnya mencakup tepat dua hal: klien kebijakan, ID chain. Tidak ada yang lain.
Itu perbedaan yang nyata, bukan sekadar teknis. Field yang terautentikasi adalah yang jika dimanipulasi akan merusak bukti kriptografis dan otomatis terdeteksi.
Field yang tidak terautentikasi adalah field yang sistem secara sederhana mempercayainya sebagaimana adanya, karena tidak ada apa pun di enkripsi itu sendiri yang mengawasinya.
Klien kebijakan dan ID chain berada di kategori pertama.
TTL, berdasarkan yang terdokumentasi, berada di bagian kedua.
Ini menimbulkan pertanyaan spesifik yang bisa diuji: jika seseorang yang mampu mencegat atau mengirim ulang permintaan unggahan ini hanya mengubah TTL — tanpa menyentuh ciphertext, klien kebijakan, dan ID chain sama sekali — apakah pemeriksaan autentikasinya bahkan akan menyadari?
Berdasarkan rumus seperti yang tertulis, seharusnya tidak.
Ciphertext masih akan terdekripsi dengan bersih, karena tidak ada apa pun tentang manipulasi TTL yang menyentuh dua nilai yang benar-benar dicek oleh algoritme.
Datanya tetap persis seperti yang dienkripsi oleh pengirim asli. Yang berubah diam-diam hanya masa simpan (shelf life) nya.
Hal ini lebih penting daripada yang mungkin terlihat pada awalnya, karena TTL bukan sekadar metadata dekoratif — TTL adalah kontrol keamanan itu sendiri.
Ini kemungkinan adalah yang membatasi seberapa lama potongan data terenkripsi yang sensitif masih akan diproses oleh sistem, masih bisa diambil, dan masih dianggap sebagai sesuatu yang masih berlaku.
TTL yang dipersingkat bisa menyebabkan data yang sah menjadi kedaluwarsa lebih cepat dan gagal secara diam-diam pada alur kerja yang bergantung padanya.
TTL yang diperpanjang bisa membuat data sensitif tetap hidup dan bisa diambil dengan baik jauh setelah pihak asli bermaksud agar hal itu menjadi penting.
Tidak ada yang perlu memecahkan enkripsi.
Keduanya tidak memicu satu pemeriksaan integritas yang terdokumentasi dilakukan oleh sistem.
Saya ingin presisi tentang apa yang tidak saya klaim.
Saya tidak tahu apakah celah ini benar-benar bisa dieksploitasi end-to-end — itu bergantung pada hal-hal yang tidak tercakup dalam dokumentasi, seperti apakah Gateway secara independen mengikat TTL di blockchain pada saat unggah dengan cara yang tidak bisa diubah setelahnya, apakah permintaan unggahan itu sendiri berjalan melalui kanal dengan perlindungan integritas pada level transport yang akan mendeteksi manipulasi sebelum sampai ke lapisan ini, atau apakah TTL diperlakukan sebagai sekadar saran, bukan sesuatu yang krusial untuk keamanan sejak awal.
Semuanya bisa menutup celah sepenuhnya, dan tidak satupun dari itu akan muncul di rumus AAD itu sendiri, karena perlindungan tersebut bersifat lapisan di atasnya, bukan berada di dalamnya.
Jadi pertanyaan yang terbuka itu tepat: apakah nilai TTL diikat di mana pun secara imutabel dan bisa dicek pada saat unggah — di-chain, atau di dalam beberapa struktur lain yang diautentikasi — atau apakah TTL diterima begitu saja sebagai parameter pada pemanggilan RPC, dipercaya dengan cara yang sama seperti field permintaan yang tidak terautentikasi?
Dokumentasi menjelaskan dengan tepat apa yang dilindungi oleh enkripsi itu sendiri.
Ia tidak mengatakan apa pun tentang apa yang melindungi nilai yang terikat waktu (time-bound) yang menentukan seberapa lama perlindungan itu bahkan seharusnya bertahan.