Bicara tentang PAKE

Sekarang mari kita bicara tentang keamanan informasi. Publikasi ini didedikasikan untuk peluncuran kursus "Keamanan Informasi Kriptografis" , yang akan dimulai pada 30 Mei. Ayo pergi.

Aturan pertama PAKE: jangan pernah bicara tentang PAKE. Aturan kedua PAKE menyatakan bahwa aturan pertama adalah omong kosong, karena PAKE atau Password Key Authenticated Key Exchange (rus. Pertukaran kunci dengan otentikasi kata sandi) adalah salah satu teknologi paling berguna yang praktis tidak pernah digunakan di mana pun. Ini harus dilaksanakan sedapat mungkin, tetapi tidak sesederhana itu.




Untuk memahami mengapa kita berbicara tentang omong kosong, mari kita lihat masalah sebenarnya.

Misalkan saya bekerja dengan server yang menyimpan kata sandi pengguna. Ada cara tradisional untuk menyimpan - hashing setiap kata sandi pengguna dan menyimpan hasilnya dalam basis data kata sandi. Ada banyak ide tentang cara menangani proses hash. Rekomendasi yang paling umum saat ini adalah menggunakan fungsi hashing kata sandi memory-hard (seperti scrypt atau argon2 (dengan garam unik ) untuk setiap kata sandi), dan kemudian menyimpan hasil hash. Ada beberapa pendapat berbeda tentang fungsi hash mana yang harus digunakan dan apakah itu dapat menggunakan beberapa nilai rahasia (disebut "pepper" ), tetapi untuk saat ini kita tidak akan membicarakannya.

Terlepas dari pendekatan yang Anda pilih, semua solusi ini memiliki satu kelemahan:
Ketika pengguna kembali untuk masuk ke situs, ia masih perlu mengirim kata sandi (terbuka) ke server untuk melakukan verifikasi .

Kebutuhan ini dapat menyebabkan konsekuensi yang tidak menyenangkan jika server Anda pernah dikompromikan atau jika pengembang Anda membuat beberapa kesalahan bodoh. Misalnya, pada awal tahun lalu, Twitter meminta semua penggunanya (dan ini 330 juta!) Untuk mengubah kata sandi - karena ternyata perusahaan tersebut menyimpan kata sandi teks (tanpa hash).

Saat ini, masalah masuk tidak dengan cara apa pun bertentangan dengan manfaat hashing kata sandi. Namun, Anda perlu menemukan solusi yang lebih baik: di mana kata sandi tidak akan pernah dikirim ke server dalam teks yang jelas. Alat kriptografi yang akan membantu kita mencapai ini adalah PAKE, dan khususnya, protokol baru yang disebut OPAQUE, yang akan kita bahas di akhir artikel ini.

Apa itu PAKE?

Protokol PAKE, yang pertama kali diusulkan oleh Bellovin dan Merritt , adalah sejenis protokol pertukaran kunci . Protokol pertukaran kunci (atau "perjanjian kunci") dirancang untuk membantu kedua pihak (sebut saja klien dan server) menyepakati kunci bersama menggunakan kriptografi kunci publik. Protokol pertukaran kunci paling awal (misalnya, Diffie-Hellman klasik) tidak sah, yang membuatnya rentan terhadap serangan seperti man-in-the-middle . Fitur khas dari protokol PAKE adalah klien mengautentikasi ke server dengan kata sandi. Untuk alasan yang jelas, diasumsikan bahwa kata sandi atau hashnya sudah diketahui oleh server, yang memungkinkan verifikasi.

Jika hanya itu yang dibutuhkan, protokol PAKE akan mudah dibangun. Tetapi yang membuat PAKE sangat berguna adalah PAKE juga memberikan perlindungan kata sandi klien. Jaminan yang lebih serius dapat dirumuskan sebagai berikut: setelah upaya untuk memasuki sistem (berhasil atau tidak berhasil), klien dan server hanya akan tahu jika kata sandi klien cocok dengan nilai yang diharapkan oleh server, dan tidak ada lagi informasi tambahan. Ini adalah pertahanan yang cukup bagus. Faktanya, ini tidak berbeda dari apa yang kami butuhkan dari bukti pengungkapan nol .

Representasi ideal dari protokol PAKE. Input dari kedua sisi termasuk beberapa keacakan, yang tidak ditampilkan di sini. Eavesdropper tidak perlu mengetahui kunci rahasia bersama K, yang itu sendiri acak dan bukan fungsi kata sandi.

Tentu saja, masalah nyata dengan PAKE adalah bahwa banyak pengembang tidak ingin menjalankan protokol "pertukaran kunci" sejak awal! Mereka hanya ingin memastikan pengguna mengetahui kata sandi.

Hal yang hebat tentang PAKE adalah bahwa use case "hanya login" cukup mudah dijalankan. Misalkan saya memiliki protokol PAKE standar yang memungkinkan klien dan server menyetujui kunci umum K. Jika dia tahu kata sandi yang benar (dan hanya dalam hal ini), maka yang perlu kita implementasikan adalah pemeriksaan sederhana yang diterima kedua pihak kunci yang sama. (Ini dapat dilakukan, misalnya, jika para pihak menggunakannya untuk menghitung beberapa fungsi kriptografi dan memverifikasi hasilnya.) Dengan demikian, PAKE dapat berguna bahkan jika Anda hanya ingin memverifikasi kata sandi.

SRP: PAKE, sekitar waktu itu sudah lupa

Konsep PAKE tampaknya memberikan keuntungan keamanan yang jelas atas pendekatan naif yang kita gunakan saat ini untuk memasuki server. Dan metode itu sendiri sudah tua, dalam arti bahwa PAKE telah dikenal sejak 1992! Meskipun demikian, cahaya tidak pernah melihatnya. Mengapa ini terjadi?

Ada beberapa alasan yang jelas. Yang paling jelas terkait dengan keterbatasan Internet: jauh lebih mudah untuk meletakkan formulir kata sandi di halaman web daripada menerapkan kriptografi mewah di browser. Namun, penjelasan ini tidak cukup. Bahkan aplikasi asli jarang menerapkan PAKE untuk operasi login. Penjelasan lain yang mungkin terkait dengan paten , meskipun sebagian besar sudah berakhir. Bagi saya, ada dua kemungkinan alasan untuk tidak memiliki PAKE:

• Kurangnya implementasi PAKE berkualitas tinggi dalam bahasa populer, yang membuatnya sulit untuk digunakan;
• Spesialis kriptografi tidak menyampaikan esensi dan nilai pekerjaan mereka dengan buruk, sehingga kebanyakan orang bahkan tidak tahu bahwa PAKE ada sama sekali.

Terlepas dari kenyataan bahwa saya mengatakan bahwa PAKE tidak digunakan sekarang, masih ada pengecualian pada aturan.

Ada satu protokol hebat yang dikembangkan pada tahun 1998 oleh Tom Wu (jangan dikelirukan dengan Tim Wu), yang disebut "SRP" (kependekan dari "Secure Remote Password"). Faktanya, ini hanya PAKE tiga tahap dengan beberapa fungsi tambahan yang tidak diimplementasikan pada karya pertama. Sejauh yang saya tahu, SRP berbeda karena itu adalah protokol PAKE paling umum di dunia. Saya akan memberikan dua bukti dari pernyataan ini:

1. SRP distandarisasi sebagai ciphersuite TLS dan diimplementasikan di perpustakaan seperti, misalnya, OpenSSL , meskipun tampaknya tidak ada yang menggunakannya secara khusus.
2. Apple menggunakan SRP secara ekstensif dalam iCloud Key Vault-nya

Fakta kedua dengan sendirinya bisa menjadikan SRP salah satu protokol kriptografi yang paling banyak digunakan di dunia, jumlah perangkat yang perangko Apple begitu besar. Dan tidak ada yang lucu.

Fakta bahwa industri telah menerima SRP tentu baik, tetapi di sisi lain, dan tidak terlalu. Sebagian besar karena meskipun dukungan PAKE keren, SRP sendiri bukan implementasi PAKE terbaik. Saya berpikir untuk pergi ke hutan diskusi tentang SRP, tetapi pidato ini sudah berjalan lama, dan saya menyimpang dari cerita tentang protokol yang sangat bagus, yang akan kita bicarakan di bawah ini. Jika Anda masih tertarik dengan diskusi tentang SRP, saya membawanya ke sini .

Alih-alih detail yang tidak perlu ini, izinkan saya menulis ringkasan singkat tentang pemikiran saya tentang SRP:

1. SRP melakukan beberapa hal dengan benar. Pertama, tidak seperti PAKE versi sebelumnya, Anda tidak perlu menyimpan kata sandi mentah di server (atau, yang setara, hash yang dapat digunakan oleh penyerang alih-alih kata sandi). Sebagai gantinya, server menyimpan "verifier," yang merupakan fungsi satu arah dari hash kata sandi. Ini berarti bahwa kebocoran basis data kata sandi tidak memungkinkan penyerang untuk segera mengganti pengguna hanya jika ia tidak melakukan serangan kamus yang lebih mahal. (Nama teknis untuk ini adalah PAKE “asimetris”.)
2. Ada berita yang lebih baik, versi SRP saat ini (v4 v6a) belum diretas!
3. Namun (jangan tersinggung oleh pengembang) arsitektur protokol SRP benar-benar gila, dan versi sebelumnya diretas beberapa kali - itulah sebabnya kami sekarang memiliki versi 6a. Plus, "bukti keselamatan" dalam artikel penelitian asli sebenarnya tidak membuktikan apa-apa .
4. SRP saat ini didasarkan pada bilangan bulat (akhir), dan karena berbagai alasan (lihat ayat 3 di atas) arsitekturnya jelas tidak dapat ditransfer ke kurva elips. Ini membutuhkan lebih banyak bandwidth dan perhitungan, sehingga SRP tidak dapat mengambil keuntungan dari banyak peningkatan kinerja yang telah kami kembangkan dalam pengaya seperti Curve25519 .
5. SRP rentan terhadap serangan pra-komputasi karena memberikan garam pengguna kepada penyerang yang dapat memulai sesi SRP. Ini berarti bahwa saya dapat meminta server untuk garam Anda dan membangun kamus hash kata sandi potensial sebelum server dikompromikan.
6. Terlepas dari semua kekurangan ini, SRP sangat sederhana, dan juga dilengkapi dengan kode kerja. Selain itu, OpenSSL memiliki kode kerja yang bahkan terintegrasi dengan TLS, yang membuatnya relatif mudah diimplementasikan.

Dari semua poin ini, yang terakhir hampir pasti bertanggung jawab atas (relatif) tingkat keberhasilan komersial yang SRP raih dibandingkan protokol PAKE lainnya. Dia tidak sempurna, tetapi nyata. Inilah yang ingin saya sampaikan kepada pakar keamanan kriptografi.

OPAQUE: PAKE generasi baru

Ketika saya mulai berpikir tentang PAKE beberapa bulan yang lalu, saya tidak bisa tidak mencatat bahwa sebagian besar implementasi yang ada berkinerja buruk. Mereka juga memiliki masalah, seperti dalam SRP, baik mengharuskan pengguna untuk menyimpan kata sandi (atau kata sandi efektif) di server, atau "garam" ditunjukkan kepada penyerang, memberikan kesempatan untuk melakukan serangan sebelum menghitung.

Kemudian, pada awal tahun lalu, Jarecki, Kravczyk dan Xu mengungkapkan kepada dunia sebuah protokol baru yang disebut OPAQUE . Ini memiliki sejumlah keunggulan signifikan:

1. Itu dapat diimplementasikan bahkan jika ada masalah Diffie-Hellman dan logaritma diskrit. Ini berarti bahwa, tidak seperti SRP, ia dapat dengan mudah dipakai menggunakan kurva elips yang efektif.
2. Bahkan lebih baik: OPAQUE tidak mengungkapkan garam kepada penyerang. Dia memecahkan masalah ini dengan menggunakan "PRF pelupa" untuk menggabungkan garam dengan kata sandi sehingga klien tidak menerima garam dan server tidak menerima kata sandi.
3. OPAQUE berfungsi dengan fungsi hashing kata sandi apa pun. Karena semua pekerjaan hashing dilakukan pada klien, OPAQUE sebenarnya dapat mengambil beban dari server, membebaskan layanan online, misalnya, untuk menggunakan pengaturan keamanan yang sangat produktif, misalnya, mengkonfigurasi scrypt dengan banyak RAM .
4. Dalam hal jumlah dan eksponen pesan, OPAQUE tidak jauh berbeda dengan SRP. Tetapi karena ini dapat diimplementasikan dengan parameter yang lebih efisien, kemungkinan akan bekerja jauh lebih efisien.
5. Tidak seperti SRP, OPAQUE memiliki bukti keamanan yang masuk akal (dalam model yang sangat kuat).

Bahkan ada proposal Internet Draft untuk OPAQUE, yang bisa Anda baca di sini. Sayangnya, saat ini saya tidak tahu apa-apa tentang kualitas implementasi kode, kecuali bahwa sudah ada beberapa implementasi potensial. Saya harap masalah ini segera beres.
Protokol OPAQUE lengkap tercantum di bawah ini. Di sisa bagian ini, saya akan berbicara tentang cara kerjanya.

Masalah 1: Menjaga garam tetap rahasia. Seperti yang saya sebutkan di atas, masalah utama dengan PAKE versi sebelumnya adalah kebutuhan untuk mentransfer garam dari server ke klien (masih belum diautentikasi). Ini memungkinkan penyerang melakukan serangan sebelum menghitung di mana ia dapat membuat kamus berdasarkan data yang diterima.

Masalahnya di sini adalah bahwa garam biasanya diteruskan ke fungsi hash (mis. Scrypt) bersama dengan kata sandi. Secara intuitif, seseorang perlu menghitung fungsi ini. Jika itu adalah server, maka server akan melihat kata sandi, yang membunuh makna apa pun. Jika ini klien, maka dia butuh garam.

Secara teoritis, Anda dapat mengatasi masalah ini dengan menghitung fungsi hashing kata sandi menggunakan protokol komputasi dua pihak yang aman (2PC) . Dalam praktiknya, solusi semacam itu hampir pasti tidak akan efektif, terutama karena fungsi hashing kata sandi rumit dan menghabiskan waktu. Ini akan sangat meningkatkan kompleksitas sistem 2PC mana pun.

OPAQUE menjalankannya sebagai berikut. Itu meninggalkan hash kata sandi di sisi klien, tetapi tidak menunjukkan garam. Sebagai gantinya, ia menggunakan protokol dua arah khusus yang disebut PRF pelupa untuk menghitung garam lain (sebut saja itu salt2) sehingga klien dapat menggunakan salt2 dalam fungsi hash tetapi tidak dapat mengakses garam asli.

Ini berfungsi seperti ini:

Server menyimpan "garam", dan klien memiliki kata sandi.salt2 = PRF (garam, kata sandi), ini dihitung antara klien dan server menggunakan protokol di mana klien tidak akan pernah mengenali garam dan server akan mengetahui kata sandi. Klien menerima salt2K = PasswordHash (salt2, kata sandi) - dan semua ini dipertimbangkan pada klien.

Implementasi aktual dari pelupa PRF dapat dilakukan dengan menggunakan beberapa elemen kelompok dan eksponen. Bahkan lebih baik, jika klien memasukkan kata sandi yang salah, maka protokol menerima nilai dummy "salt2", yang tidak mengatakan apa-apa tentang nilai sebenarnya dari garam.

Masalah 2: Bukti bahwa klien menerima kunci yang benar K. Tentu saja, saat ini klien telah menerima kunci K, tetapi server tidak tahu apa itu. Server juga tidak tahu apakah ini kunci yang benar.

Solusi OPAQUE didasarkan pada ide lama Gentry, Mackenzie dan Ramzan . Ketika pengguna pertama kali masuk ke server, server menghasilkan kunci publik dan pribadi yang dapat diandalkan untuk protokol perjanjian aman (misalnya, HMQV) dan mengenkripsi kunci pribadi yang diterima di bawah K bersama dengan kunci publik server. Hasil cipher terotentikasi (dan kunci publik) disimpan dalam basis data kata sandi.

C = Enkripsi (K, kunci rahasia klien | kunci publik server)


Versi lengkap dari protokol OPAQUE, kutipan dari artikel .

Ketika klien ingin mengautentikasi menggunakan protokol OPAQUE, server mengirimkan kode C yang tersimpan. Jika klien memasukkan kata sandi yang benar pada tahap pertama, ia bisa mendapatkan K , dan mendekripsi sandi ini. Kalau tidak, itu tidak berguna. Menggunakan kunci rahasia kabel, dia sekarang dapat menjalankan protokol perjanjian standar dengan kunci yang diautentikasi untuk menyelesaikan jabat tangan. (Server memeriksa input klien dengan memeriksa mereka terhadap salinan kunci publik klien, dan klien melakukan hal yang sama.)

Sekarang mari kita kumpulkan semuanya. Semua langkah ini dapat digabungkan menjadi satu protokol, yang memiliki jumlah langkah yang sama dengan SRP. Jika Anda tidak memperhatikan langkah-langkah verifikasi, itu akan terlihat seperti protokol di atas. Pada prinsipnya, idenya hanya dalam dua pesan: satu dari klien, dan yang kedua dikirim kembali ke server.

Aspek terakhir dari karya OPAQUE adalah bahwa ia memiliki bukti keamanan yang baik yang memberitahu kita bahwa protokol yang dihasilkan dapat dianggap aman jika kita mengambil satu atau lebih logaritma diskrit dalam model oracle acak, yang merupakan asumsi standar, yang tampaknya merupakan asumsi standar, yang tampaknya , terjadi di pengaturan yang kami gunakan.

Kesimpulan

Jadi, singkatnya, kami memiliki teknologi andal yang dapat membuat proses penggunaan kata sandi jauh lebih mudah, dan juga memungkinkan kami untuk menanganinya dengan lebih efisien - dengan banyak parameter hashing dan lebih banyak beban kerja di sisi klien. Mengapa ini tidak digunakan di mana-mana? Mungkin dalam beberapa tahun ke depan semuanya akan berubah. Waktu akan memberi tahu.

Menurut tradisi yang ada, kami menunggu komentar Anda dan mengundang Anda untuk mengunjungi hari buka pintu , yang akan diadakan pada tanggal 27 Mei oleh guru kami, cryptanalyst Elena Kirshanova .