Apakah WPA2 dengan kunci yang dibagikan sebelumnya merupakan contoh bukti tanpa pengetahuan?


9

Saat mengatur titik akses dan memilih WPA2, seseorang harus secara manual memasukkan kunci yang dibagikan sebelumnya (kata sandi), PSK, ke dalam AP dan STA.

Kedua belah pihak, AP dan STA, harus saling mengautentikasi. Tetapi mereka harus melakukannya tanpa mengungkapkan PSK. Keduanya harus membuktikan kepada pihak lain bahwa mereka tahu PSK tanpa benar-benar mengirimkannya.

Apakah itu contoh bukti tanpa pengetahuan ?

Saya pikir itu, tetapi tidak ada yang sah muncul ketika saya google untuk bukti nol-pengetahuan dan WPA2 atau EPA-PSK (metode otentikasi yang digunakan).

Jawaban:


6

Dalam autentikasi, Anda sering menemukan bukti sandi tanpa pengetahuan (ZKPP). EAP sendiri merupakan kerangka kerja yang agak umum dan mungkin melibatkan pengungkapan identitas klien misalnya untuk mentransfernya ke lapisan otentikasi berikutnya seperti RADIUS.

PACE (BSI TR-03110) adalah salah satu contoh protokol ZKPP yang digunakan untuk otentikasi. EAP-SPEKE adalah hal lain.

Keamanan kunci bergantung pada penggunaan hanya bagian-bagian kunci dalam pertukaran antara klien dan server. Klien menawarkan nonce dienkripsi dengan kunci ke server. Oleh karena itu, server jahat menerima data yang dienkripsi dan menyimpan versi plaintext-nya. Ini bukan pengetahuan nol, karena dalam waktu yang terbatas server jahat mungkin mengumpulkan informasi yang cukup untuk memecahkan enkripsi AES-128.

Karenanya EAP-PSK tidak dapat dianggap sebagai contoh bukti sandi tanpa pengetahuan, meskipun skema otentikasi lain yang diusulkan berdasarkan EAP seperti EAP-SPEKE memiliki properti ini.

Untuk mengilustrasikan bagian bermasalah dari protokol EAP-PSK pertimbangkan aliran pesan seperti yang disajikan dalam RFC 4764.

Pesan pertama dikirim oleh server ke rekan ke:

  *  Send a 16-byte random challenge (RAND_S).  RAND_S was called RA
     in Section 3.2

  *  State its identity (ID_S).  ID_S was denoted by A in
     Section 3.2.

o Pesan kedua dikirim oleh rekan ke server ke:

  *  Send another 16-byte random challenge (RAND_P).  RAND_P was
     called RB in Section 3.2

  *  State its identity (ID_P).  ID_P was denoted by B in
     Section 3.2.

  *  Authenticate to the server by proving that it is able to
     compute a particular MAC (MAC_P), which is a function of the
     two challenges and AK:
     MAC_P = CMAC-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P)

o Pesan ketiga dikirim oleh server ke peer ke:

  *  Authenticate to the peer by proving that it is able to compute
     another MAC (MAC_S), which is a function of the peer's
     challenge and AK:
     MAC_S = CMAC-AES-128(AK, ID_S||RAND_P)

Di sini AK adalah bagian dari kunci rahasia yang digunakan pada tahap ini dan dapat diungkapkan ke server nakal yang dapat mendekripsi AES-128.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.