it-swarm-id.com

Keuntungan sertifikat klien untuk otentikasi klien?

Saya bukan pakar keamanan, jadi tolong tanyakan dalam komentar jika saya belum membuat pertanyaan saya cukup jelas untuk jawaban.

Skenario

Kami memiliki server yang menjalankan layanan WCF, dan sejumlah klien yang terhubung. Klien-klien ini sebenarnya adalah PC Linux yang kami bangun. Kami perlu menjalin komunikasi aman antara server kami dan klien kami (sekali lagi kami membangunnya, dan menyebarkannya ke situs pelanggan).

Klien mempercayai server

Kami akan menerapkan ini dengan memungkinkan klien untuk membuat koneksi tepercaya dengan server melalui penerapan komunikasi SSL.

Server mempercayai klien

Kami sekarang memiliki tugas untuk mengautentikasi klien. Jelas ini dilakukan dengan menyimpan semacam kredensial pada klien. Setelah klien terhubung, ia dapat mengirim kredensial ke server dan server dapat memvalidasinya.

Salah satu opsi untuk kredensial ini adalah menyimpan semacam Guid atau id/kata sandi lain yang dihasilkan oleh aplikasi berbasis WCF. Setelah menerima kredensial, layanan WCF melakukan pencarian dalam database dan memverifikasi mereka benar.

Pilihan lain adalah menggunakan Layanan Sertifikat untuk membuat sertifikat klien yang disalin ke pc klien sebelum dikirim keluar. Setelah membuat koneksi aman, klien mengirim sertifikat ke server yang mengotentikasi sertifikat dengan Layanan Sertifikat.

Pertanyaan

Apa keuntungan menggunakan sertifikat untuk membuktikan keaslian klien atas nama pengguna/panduan? Kerugian apa yang dimilikinya?

Tolong pertimbangkan:

  • Keamanan
  • Kompleksitas implementasi
  • Kompleksitas Integrasi pemrograman dengan aplikasi. Ini termasuk alur kerja pembuatan token otentikasi, mengaitkan metadata (otorisasi/asosiasi) yang sesuai, mengelola otentikasi seperti menonaktifkan akses, dll.
34
Shaun Rowan

Menyebarkan sertifikat klien bisa muat di sini. Keuntungan menggunakan cert atas nama pengguna agak sederhana. Siapa pun dapat mengetik nama pengguna dari perangkat klien apa pun. Jika Anda menggunakan kombinasi nama pengguna dengan panduan, maka "keamanan" atau jaminan bahwa klien terhubung dari perangkat klien yang dikenal/resmi tergantung pada kekuatan dan keunikan panduan. Jika ada cara untuk mengkloning atau menipu panduan (alamat mac dapat dipalsukan dengan mudah), maka tingkat jaminan akan menurun.

Sertifikat klien dapat digunakan untuk klien, dengan atau tanpa pemeriksaan validitas (selain dari tanggal validitas, cn, ski/aki, sidik jari, dll). Mekanisme pemeriksaan validitas berdasarkan permintaan seperti ocsp akan memerlukan pemeriksaan aplikasi server dengan server ocsp setiap kali klien menghubungkan/mencoba untuk auth. Tetapi dari uraian, saya tidak membaca bahwa pengecekan validitas sama pentingnya dengan mengikat sertifikat ke perangkat klien.

Satu detail penting dengan sertifikat klien (sertifikat pada umumnya) adalah yang dapat diekspor dan sebagian besar implementasi tidak mengunci portabilitas sertifikat. Terlepas dari apakah atau bagaimana sertifikat klien akan disimpan, tanpa tindakan yang tepat, sertifikat dapat dengan mudah disalin dari satu perangkat ke perangkat lainnya. Beberapa implementasi menyimpan sertifikat pada sistem file (file yang diakhiri dengan .cer, .der, .key, .crt biasanya merupakan indikasi bahwa sertifikat disimpan dalam sistem file). Implementasi yang lebih kuat (tergantung pada aplikasi) dapat menyimpan sertifikat dan kunci di keystore (yaitu Java penyimpanan kunci). Penyimpanan kunci dapat menambahkan perlindungan tambahan seperti memastikan kunci pribadi tidak dapat diekspor. Namun, jaminan bahwa kunci belum diekspor hanya sekuat penyimpanan kunci itu sendiri. Penyimpanan kunci perangkat keras (yaitu kartu pintar, usb hsm, ironkey, dll) menawarkan jaminan yang lebih kuat bahwa kunci pribadi tidak dapat diekspor daripada kunci toko perangkat lunak.

BTW, titik di atas juga mempengaruhi kunci server. Sebagian besar implementasi menyimpan kunci pribadi dalam penyimpanan kunci perangkat lunak dan biasanya ditandai dapat diekspor. Lebih lanjut, kunci pribadi biasanya tidak dilindungi kata sandi sehingga siapa pun yang memiliki akses ke server dapat pergi dengan kunci pribadi. Jika sertifikat dapat disalin, maka tidak menawarkan non-repudasi.

Untuk menjawab pertanyaan Anda, jika ada cara yang baik untuk meningkatkan id perangkat keras (panduan, nomor seri, sertifikat yang disimpan di HSM, dll), yang kemungkinan akan memberikan jaminan lebih daripada menggunakan id berbasis perangkat lunak (termasuk klien termasuk) . Menggunakan sertifikat klien dengan perlindungan kata sandi yang diaktifkan untuk akses kunci pribadi memberikan validasi yang sedikit lebih kuat karena klien tidak hanya perlu memiliki akses ke kunci pribadi tetapi juga kata sandi untuk menggunakannya.

Jika Anda memutuskan untuk menggunakan sertifikat klien, maka Anda harus membangun atau menggunakan infrastruktur PKI yang ada. Vendor seperti Codomo, Entrust, Symantec (sebelumnya vrsn, thawte, dan geotrust), Godaddy, dan banyak lainnya menawarkan infrastruktur publik dan swasta untuk digunakan. Namun biaya penerapan sertifikat klien berbasis perangkat lunak kemungkinan akan lebih tinggi daripada menggunakan id perangkat keras berbasis perangkat lunak atau bahkan mungkin id unik berbasis perangkat keras.

Jika ada, tentukan tingkat jaminan yang ingin Anda miliki dan putuskan apakah perangkat lunak, perangkat lunak + kata sandi, atau perangkat keras memadai.

19
bangdang

Dengan otentikasi sertifikat klien, rahasia (kunci pribadi) tidak pernah meninggalkan klien dan tidak pergi ke server. Apakah Anda mempercayai server atau tidak (toh Anda harus memeriksanya terlebih dahulu), kunci pribadi Anda tidak akan bocor. Ini merupakan keunggulan dibandingkan otentikasi berbasis-bentuk tradisional atau HTTP Basic.

Anda bahkan dapat menggunakan beberapa token kriptografi perangkat keras/kartu pintar yang dirancang sedemikian rupa sehingga kunci pribadi tidak pernah meninggalkan token (tanda tangan yang terlibat dalam jabat tangan TLS terjadi secara on-board).

Jika Anda menggunakan sertifikat klien dalam konteks Infrastruktur Kunci Publik (kemungkinan besar), Anda juga dapat menikmati manfaat yang ditawarkan oleh PKI. Ini sebagian besar berguna untuk struktur besar, tetapi Anda dapat:

  • Kenali identitas pengguna yang belum pernah Anda daftarkan sebelumnya.

    Ini untuk apa Otoritas Sertifikasi. Jika Anda mempercayai CA, Anda mempercayai sertifikat yang dikeluarkannya. Jika pengguna yang tidak dikenal masuk tanpa akun yang sudah ada sebelumnya ke sistem Anda, dan jika mereka memberikan sertifikat yang Anda percayai, Anda akan dapat mengenali identitas mereka, sebagaimana dijamin oleh CA. Anda mungkin atau mungkin tidak ingin mendapatkan detail lebih lanjut dari pengguna, tetapi identitas utama akan ditegaskan dengan CA dan akan meninggalkan jejak administrasi di sana.

  • Identitas yang sama yang dinyatakan oleh sertifikat dapat digunakan di beberapa situs web independen (asalkan mereka mempercayai CA yang sama), mungkin digunakan sebagai bentuk Single-Sign On.

  • Sertifikat yang dikompromikan dapat dicabut langsung oleh CA.

  • Melalui CA, Anda memisahkan masalah membuktikan identitas pengguna dari penyediaan layanan itu sendiri. Metode lain seperti OpenID juga mencapai tujuan ini, tetapi hampir tidak memberikan tingkat jaminan yang sama dengan apa yang dapat dilakukan CA (asalkan CA melakukan pekerjaan mereka dengan benar). Tingkat jaminan akan bervariasi tergantung pada kualitas CA.

    Keuntungan dengan ini adalah Anda dapat menerbitkan kembali sertifikat baru untuk pengguna yang sama dengan kunci yang berbeda (jika sertifikat sebelumnya telah kedaluwarsa atau jika kunci pribadi dikompromikan) dan menyimpan pengidentifikasi (Subjek) yang sama di semua sistem yang mempercayai ini CA.

(Anda juga dapat menggunakan sertifikat klien di luar konteks PKI, tetapi Anda harus menetapkan aturan kepercayaan Anda sendiri, yang bisa sangat membosankan.)

Sertifikat klien juga dapat digunakan secara terpisah dari protokol yang berjalan di atas SSL/TLS. Anda bahkan dapat menggunakannya untuk S/MIME misalnya, jika berlaku.

Keuntungan lain adalah bahwa, karena otentikasi tidak terjadi pada tingkat HTTP, itu efektif tanpa kewarganegaraan, jika hal-hal seperti REST gaya arsitektur penting bagi Anda.

Beberapa layanan web juga dapat menggunakan ini untuk keamanan tingkat pesan, sehingga berpotensi meninggalkan jejak audit untuk tidak menyangkal pesan-pesan tertentu jika perlu.

Kelemahan utama adalah bahwa Anda harus mendidik pengguna Anda untuk konsep dasar kriptografi kunci publik. Ini sangat penting jika Anda tidak menggunakan token perangkat keras (tetapi hanya menyimpan sertifikat dan kunci pribadi di dalam perangkat lunak pengguna).

  • Tidak seperti kata sandi, pengguna tidak akan mengingat kunci pribadi/cert. Mereka harus menggunakan mesin tempat sertifikat telah dipasang (atau di mana ada pembaca kartu yang cocok untuk solusi perangkat keras). Untuk mengambil jalan pintas, beberapa orang mungkin tergoda untuk tidak menjaga kunci privat mereka dengan hati-hati sebagaimana seharusnya (mereka biasanya dilindungi dengan kata sandi sendiri).

  • Saat menjelaskan, gagasan "sertifikat" dapat membingungkan. Bahkan para ahli terkadang mempersingkat kalimat. Jika Anda mengatakan "gunakan sertifikat Anda untuk masuk", yang Anda maksud sebenarnya adalah "gunakan kunci pribadi dan sertifikat Anda untuk masuk": kunci pribadi tersirat dalam ungkapan ini. Sebaliknya, jika seseorang memberi tahu Anda "kirimi saya sertifikat Anda", Anda tidak boleh menggunakan kunci pribadi Anda. Jika Anda mencari-cari dokumentasi, Anda akan menemukan sejumlah referensi untuk file PKCS # 12 (.p12 atau .pfx) dan file sertifikat PEM (.pem atau .crt, biasanya). Biasanya, yang pertama berisi kunci pribadi sedangkan yang kedua tidak (walaupun mungkin juga). Semua gagasan ini akan membingungkan pengguna kecuali mereka tahu apa yang mereka lakukan.

  • Antarmuka pengguna browser untuk sertifikat klien umumnya sangat buruk. Dari perspektif UI, cukup sulit untuk keluar dari situs web tempat Anda mengotentikasi dengan sertifikat klien (seperti HTTP Basic). (Itu membuat perlindungan CSRF menjadi lebih penting.) Jika klien Anda adalah "mesin" dan bukan pengguna melalui browser, ini tidak terlalu menjadi masalah.

Dalam hal infrastruktur, jika Anda tidak ingin menggunakan layanan CA komersial untuk sertifikat klien Anda, Anda harus menggunakan CA Anda sendiri. Perhatikan bahwa CA yang digunakan untuk otentikasi klien dapat independen dari CA yang digunakan untuk otentikasi server. Anda dapat menjalankan situs web dengan sertifikat yang dikeluarkan oleh CA terkenal tetapi memilikinya mempercayai sertifikat klien dari CA Anda sendiri. Ada berbagai alat untuk manajemen CA, termasuk yang open source . Beberapa bahkan dapat melakukan pembuatan kunci dalam peramban, sehingga kunci pribadi siap di peramban (sisi negatifnya adalah bahwa pengguna harus menggunakan kembali peramban yang sama untuk mengimpor sertifikat setelah dikeluarkan).

Konfigurasi server memerlukan pemahaman tertentu tentang apa sertifikatnya (sertifikat CA, sertifikat server), tetapi sebenarnya tidak terlalu rumit. Sebagian besar server mendukung cara ini.

Sertifikat klien hanya memberi Anda otentikasi. Anda mungkin masih perlu mendapatkan atribut lebih lanjut (mis. Dari LDAP atau basis data terhadap subjek sertifikat). Anda tentu perlu memiliki logika otorisasi di atas ini, seperti halnya untuk sistem otentikasi lainnya. Biasanya memetakan DN Subjek ke pengidentifikasi lokal di sistem Anda.

(Ada penggunaan lebih lanjut di mana Anda dapat mendelegasikan otentikasi menggunakan sertifikat proxy, atau meneruskan token otorisasi melalui sertifikat atribut, tetapi ini lebih tidak biasa dan tidak diterima oleh semua tumpukan perangkat lunak.)

19
Bruno