Pengertian teoritis white-box

Oct 02 2020

Apakah ada gagasan yang secara teoritis aman tentang white-box?

Saya telah membaca tentang white-box [ 1 , 2 , 3 ] baru-baru ini. Tampaknya kotak putih berhubungan dengan kebingungan kode dan tidak diketahui apakah kotak putih yang sempurna itu ada.

Saya penasaran tentang gagasan teoretis di balik ini. Untuk stream cipher, gagasan teoretisnya adalah PRF. Untuk block cipher adalah PRP. Untuk fungsi hash, ini adalah fungsi satu arah. Apakah ada sesuatu yang sebanding dengan white-box?

Saya mencari sesuatu yang belum tentu praktis, tetapi kami benar-benar dapat menunjukkan bahwa ini mencapai kotak putih yang sempurna, seperti kode yang benar-benar acak atau semacamnya.

MEMPERBARUI. Saya samar-samar ingat membaca sesuatu di baris

Kotak putih akan dimungkinkan jika ada memori super besar. Memori dapat dimuat sebagai tabel pencarian dengan teks biasa sebagai kunci pencarian dan teks sandi sebagai nilai pencarian. Karena kunci enkripsi tidak terlibat dalam tabel pencarian (telah digunakan sebelumnya untuk membuat tabel pencarian), kunci enkripsi tidak dapat dipulihkan tetapi enkripsi masih dimungkinkan.

Tapi saya tidak bisa mendapatkan kembali sumbernya. Apakah ada yang tahu tentang itu?

Jawaban

6 Serpent27 Oct 02 2020 at 07:28

Karena saya kira kami menganggap ini sebagai pertanyaan crypto, dan bukan rekayasa balik, saya akan memberikan jawaban formal.

Tujuan kripto kotak putih, seperti yang diterima secara umum, adalah untuk menyembunyikan kunci yang digunakan untuk melakukan beberapa operasi kriptografi. The masalah dengan sistem tersebut adalah bahwa algoritma itu sendiri harus tahu kuncinya; cukup sulit untuk berhasil mengenkripsi atau mendekripsi sesuatu dengan kunci yang tidak Anda ketahui.

Dalam kasus apa pun di mana algoritme mengetahui kunci yang digunakannya untuk melakukan operasi kriptografi, insinyur balik dapat dengan mudah mengambil kunci dari memori algoritme. Anda dapat mencoba menghalangi upaya teknisi balik untuk melakukannya, tetapi rekayasa balik bukanlah masalah NP-complete; sebenarnya cukup mudah bagi seseorang dengan keterampilan yang diperlukan.

Mungkin Anda tidak memuat kunci, tetapi beberapa operasi satu arah berdasarkan kunci ... Selamat! Anda hanya menggunakan kunci yang berbeda, dan tidak mengubah properti keamanan apa pun.

Katakanlah Anda menggunakan beberapa masukan, melakukan beberapa kalkulasi yang tidak dapat dipahami, dan menggunakan nilai yang dihasilkan sebagai kuncinya ... Selamat! Anda juga tidak melakukan apa-apa, karena seluruh tugas seorang insinyur terbalik adalah menguraikan kode yang tampaknya "tidak dapat dipahami", dan mereka cenderung cukup ahli dalam hal itu.

Selain itu, tidak ada yang menghentikan mereka untuk menjalankan kalkulasi itu sendiri. Mereka tidak perlu memahami kode untuk menjalankannya. Anda dapat mencoba berbagai teknik untuk mencegahnya melakukannya, dan itu disebut anti-rekayasa balik. Tapi itu tidak secara teoritis, atau praktis, dapat menghentikan insinyur mundur yang layak.

Beberapa hari yang lalu saya ditugasi merekayasa balik sampel malware yang mencoba menggunakan sistem kotak putih semacam itu untuk mencegah saya memahami fungsinya. Saya mendekripsi setiap string terenkripsi dalam sampel dan saat ini menunggu persetujuan untuk mengupload sampel rekayasa-balik ke GitHub publik saya.

Singkatnya, crypto kotak putih tidak berfungsi.

6 fgrieu Oct 02 2020 at 06:53

Perhatian: Kriptografi Kotak Putih berada di luar zona nyaman saya, dan saya belum mengikuti perkembangan terbaru di lapangan. Berikut ini adalah pendapat saya saat ini, yang saya sampaikan dengan harapan melihatnya tertantang, dan belajar dalam prosesnya.

Seperti yang saya lihat, tujuan tradisional Kriptografi Kotak Putih (dan yang paling diinginkan industri) adalah merancang perangkat lunak yang menghitung transformasi kriptografi kunci publik standar (seperti PRP yang dikunci, idealnya AES) dengan contoh tertentu dari kunci rahasia tertanam dalam perangkat lunak, sehingga perangkat lunak yang membocorkan tidak membocorkan kunci tersebut.

Saya tahu tidak ada klaim serius bahwa ini bahkan hampir tercapai. Sebaliknya, kompetisi WBC yang berfokus pada tujuan di atas dengan AES sebagai PRP memiliki AFAIK, semuanya berakhir dengan ekstraksi kunci yang cepat.

Sehubungan dengan tujuan tersebut, tampaknya kita bahkan tidak memiliki WBC yang aman, dan dengan demikian secara teoritis lebih aman WBC. Berbeda dengan situasi yang lebih baik dalam kripto simetris, di mana kita secara praktis memiliki PRP dan PRF yang aman, tetapi tidak ada konstruksi yang secara teoritis aman dari prinsip pertama.

Namun varian WBC seperti yang didefinisikan di atas secara praktis layak jika kita mengizinkan untuk membangun transformasi kunci dengan WBC dalam pikiran: misalnya sepele untuk membuat implementasi WBC yang praktis aman dari AES-256 yang mirip WES-256, yang didefinisikan sebagai: $$\begin{align} \text{WES-256}:\quad&\{0,1\}^{256}\times\{0,1\}^{128}\to\{0,1\}^{128}\\ &P\mapsto\text{WES-256}(K,P)\underset{\text{def}}=\text{AES-256}(\text{SHA-256}(K),P) \end{align}$$

Jika kita mengambil definisi varian tersebut, keamanan WBC mengikuti dari konstruksi yang lebih tradisional.

Kesimpulan saya adalah bahwa saya tidak tahu definisi yang baik tentang tujuan teoritis WBC, sehingga tidak dapat menjawab pertanyaan itu!

2 Fractalic Oct 04 2020 at 13:50

Bukan jawaban utama, tapi sesuatu yang bermanfaat.

Ada gagasan tentang ketidakmampuan , yang mengharuskan sulit untuk mengompresi implementasi kotak putih besar yang disengaja. Meskipun sulit dicapai untuk cipher yang ada, mudah untuk mendesain cipher simetris baru dengan implementasi yang tidak dapat dimampatkan.

Mengapa? Ide utamanya mungkin adalah untuk mencegah serangan pengangkatan kode: mengekstrak katakanlah, 1GB dari ponsel jauh lebih sulit daripada 128 bit kunci rahasia. Terutama, dalam serangan besar-besaran, katakanlah, oleh malware. Tentu saja, dalam praktiknya, industri enggan menggunakan implementasi seperti itu, karena tidak ada yang mau memakan penyimpanan 1GB secara gratis.

Bagaimana? Misalnya, pertimbangkan Jaringan Feistel di mana fungsi Feistel dipotong instance AES (menggunakan kunci master, atau lebih baik diturunkan darinya). Dalam implementasi yang tidak dapat dimampatkan, kita akan meletakkan fungsi ini sebagai tabel pencarian (kita memotongnya untuk mendapatkan ukuran yang diinginkan). Tidak sulit untuk menunjukkan bahwa mengompresi skema menyiratkan non-randomness dari AES, sehingga incompressibility direduksi menjadi keamanan AES.