Perjalanan panjang dari RFC 4357 ke RFC 8645 atau cara mengelola kunci enkripsi

gambar

Seperti yang Anda ketahui, manajemen kunci adalah salah satu tugas paling sulit dalam kriptografi. Beberapa hari yang lalu, dokumen "Mekanisme Re-keying for Symmetric Keys" diterbitkan sebagai RFC 8645 . Ini adalah hasil dari dua setengah tahun kerja kelompok penelitian CFRG, yang menentukan pengembangan dan penggunaan kriptografi di IETF, dan didasarkan pada penelitian bertahun-tahun dan pengalaman spesialis Rusia. Selanjutnya, kami menjelaskan secara singkat apa inti dari RFC ini dan mengapa itu terjadi begitu saja.

Sedikit ketakutan ...


Pada 2016, dua peneliti Prancis dari Inria Institute menerbitkan deskripsi serangan Sweet32 . Gagasan yang mereka gunakan sangat sederhana dan didasarkan pada apa yang disebut "masalah ulang tahun" : jika kita menghitung nilai-nilai pemetaan acak f:Vn rightarrowVnlalu sekitar 2n/2tes dalam urutan yang dihasilkan setidaknya dua nilai bertepatan. Dari sudut pandang kriptografi, ini berarti bahwa cipher blok dengan panjang blok nbit tidak dapat dienkripsi pada satu tombol lagi 2n/2blok plaintext.



Serangan ini sudah dipertimbangkan secara rinci pada Habré , di sini kami hanya mencatat bahwa penulis mengambil keuntungan dari kenyataan bahwa beberapa perpustakaan kriptografi yang banyak digunakan tidak mengubah kunci sesi tepat waktu. Ini memungkinkan kami untuk mengumpulkan banyak data dan hanya menggunakan properti probabilistik yang ditentukan jika koneksi menggunakan cipher blok dengan panjang blok 64 bit. Ini segera memunculkan histeria serius di lingkungan kriptografi yang dekat mengenai perlunya penolakan mendesak terhadap sandi semacam itu.



Tapi apakah panjang blok itu?


Memang, apakah itu layak mengasingkan sandi hanya karena panjang bloknya pendek: bagaimana jika Anda mengubah kunci secara berkala? Ini dapat dilakukan dengan menggunakan fungsi derivasi kunci ( KDF ). Fungsi tersebut memungkinkan Anda untuk mendapatkan kunci baru berdasarkan yang lama, sambil mempertahankan properti keacakan kunci (lihat, misalnya, artikel ini ). Fungsi-fungsi tersebut, misalnya, ditentukan oleh rekomendasi standardisasi Rusia P 1323565.1.022-2018 dan P 50.1.113-2016 . Namun, ada satu "tetapi": ini adalah konversi yang cukup kompleks dan tidak terlalu cepat yang dibangun berdasarkan fungsi hash, yang secara signifikan akan memperlambat kecepatan enkripsi.

Apakah mungkin melakukan sesuatu lebih cepat?


Upaya semacam itu dilakukan pada tahun 2006 di RFC 4357 , di mana mekanisme CryptoPro Key Meshing diusulkan, yang menghasilkan kunci turunan dengan mengenkripsi konstanta tetap dengan cipher blok dalam mode penggantian sederhana.



Itu adalah algoritma yang sangat cepat, dengan praktis tidak berpengaruh pada kecepatan enkripsi dan melindungi terhadap situasi konyol seperti yang digunakan dalam Sweet32, dan juga, misalnya, terhadap serangan pada saluran samping. Namun, pada konferensi Ruscrypto 2015, ditunjukkan bahwa transformasi semacam itu mengurangi kekuatan set kunci, mis. dengan setiap kunci baru mengubah jumlah opsi pemilihan kunci yang mungkin berkurang. Penulis mencatat bahwa ini tidak memiliki dampak yang signifikan terhadap keamanan, tetapi tetap menarik apakah ini dapat dilakukan dengan lebih baik.



Ternyata tidak sesederhana itu


Sayangnya, mukjizat tidak ada, dan tidak mungkin untuk menawarkan mekanisme cepat yang sebanding dengan KDF konvensional, namun, kami dapat membuktikan keamanan beberapa skema yang dimodifikasi seperti Penyesuaian Kunci yang ditentukan untuk setiap mode enkripsi tertentu. Mekanisme inilah yang diusulkan dan dibenarkan untuk mode gamma CTR yang banyak digunakan (CTR-ACPKM, Perpanjangan Bahan Kriptografi Lanjutan) dan pengembangan insert simulasi OMAC (OMAC-ACPKM) dari standar domestik GOST R 34.13-2015.

Peringkat keamanan untuk mode-mode ini diperoleh dengan menggunakan apa yang disebut aparatus "Daya tahan yang bisa dibuktikan . "

Mode ini diadopsi di Rusia sebagai rekomendasi untuk standardisasi R 1323565.1.017-2018 .

Ini adalah cara bekerja dengan kunci yang memungkinkan alat kripto yang mengimplementasikan set Rusia TLS 1.2 kripto (didefinisikan dalam rekomendasi standardisasi R 1323565.1.020-2018 ) untuk memenuhi persyaratan perlindungan kriptografi Rusia untuk kelas tinggi.

Bekerja di IETF


Mekanisme yang dikembangkan sangat cocok sebagai jawaban untuk diskusi yang disebutkan di awal artikel tentang apakah harus ada sandi dengan panjang blok pendek atau tidak.

Pengembangan dokumen yang sesuai, yang kemudian menjadi RFC 8645, ditugaskan oleh ketua CFRG Kenny Paterson dan Alexei Melnikov oleh sekelompok pakar internasional yang dipimpin oleh Stanislav Smyshlyaev. Kontribusi untuk pengembangan dokumen akhir dibuat oleh Evgeny Alekseev, Ekaterina Smyshlyaeva dan Lilia Akhmetzyanova (CryptoPro), Shay Gueron (Universitas Haifa), Daniel Fox Franke (Akamai Technologies), serta mantan kepala IETF Rumah Russ (Keamanan Vigil); pada berbagai tahap, spesialis utama seperti Mihir Bellare (University of California), Scott Fleurer (Cisco), Yoav Nir (Checkpoint), Dmitry Belyavsky (Cryptocom) dan Paul Hoffman (ICANN) bergabung dalam pekerjaan ini.

Dibandingkan dengan rekomendasi Rusia, mekanisme ACPKM telah ditambahkan ke RFC ini untuk mode seperti CBC, CFB dan GCM, yang, seperti yang mungkin sudah Anda pahami, membutuhkan bukti terpisah .

Ringkasan


Seperti yang telah dicatat, terlepas dari kenyataan bahwa pendekatan yang diusulkan dalam beberapa hal tidak universal dan memerlukan pembenaran keamanan yang terpisah untuk setiap rezim individu, kami menghargai kecepatan tinggi, keamanan dari serangan seperti Sweet32 dan, paling tidak, serangan dari saluran samping.

Source: https://habr.com/ru/post/id465527/


All Articles