Saya memahami PKI dengan cukup baik dari sudut pandang konseptual - yaitu kunci pribadi / kunci publik - matematika di belakangnya, penggunaan hash & enkripsi untuk menandatangani sertifikat, Penandatanganan Digital atas Transaksi atau Dokumen dll. Saya juga telah bekerja pada proyek di mana terbuka Perpustakaan C digunakan dengan sertifikat untuk mengamankan komunikasi dan otentikasi. Saya juga sangat akrab dengan alat baris perintah openssl.
Namun, saya memiliki sedikit pengalaman dengan proyek-proyek yang diaktifkan PKI berbasis web & karenanya saya mencoba merancang dan membuat kode proyek pribadi untuk memahami ini dengan lebih baik.
Persyaratan
Ini adalah situs web untuk bank. Semua pengguna Internet Banking diizinkan menggunakan sertifikat apa pun yang dikeluarkan oleh beberapa CA yang dikenal (verisign, Thawte, titipan, dll.). Bank tidak bertanggung jawab atas pengadaan sertifikat untuk pengguna. Sertifikat ini akan digunakan untuk otentikasi ke situs web bank. Platform / OS dll masih belum diperbaiki.
Rancangan
Saya bertanya-tanya apa cara terbaik untuk melakukan otentikasi.
Saya melihat bahwa Apache memiliki cara untuk mengaktifkan 2 cara ssl - dalam hal ini, saya pikir menavigasi ke situs web secara otomatis akan meminta sertifikat dari pengguna. Tetapi saya tidak yakin apakah ini sudah cukup karena tampaknya semua yang diverifikasi adalah apakah suatu sertifikat ditandatangani oleh CA yang tepercaya & mungkin juga apakah itu termasuk dalam daftar putih garis subjek sertifikat dll. Tetapi ini tidak cukup untuk kasus bank karena Anda harus dapat mengaitkan seorang pengguna bank dengan sertifikat.
IIS tampaknya memiliki cara dimana saya dapat memiliki sertifikat yang disimpan untuk setiap pengguna di Active Directory. Inilah yang saya mengerti dari membaca beberapa artikel MSDN. Anda mengaktifkan 2 way SSL di IIS & kemudian ketika pengguna mencoba menavigasi ke situs web, IIS akan mengirim permintaan ke browser dengan daftar CA yang disetujui dan browser akan membiarkan pengguna memilih sertifikat yang sesuai dari certstore-nya dan mengirimkannya. untuk backend. Saya berasumsi bahwa IIS akan melakukan 2 hal
- Pastikan bahwa pengguna memiliki kunci pribadi yang terkait dengan sertifikat tersebut (dengan berdasarkan negosiasi penutup)
- Berdasarkan Pemetaan Sertifikat Pengguna AD, IIS akan melaporkan nama pengguna ke aplikasi.
Lakukan kejelasan otentikasi dengan memanggil fungsi crypto, tergantung pada tergantung pada server web untuk melakukannya.
- Perlihatkan layar pengguna tempat ia mengunggah sertifikat dan aplikasi memastikan pengguna memiliki kunci pribadi yang terkait dengan sertifikat (dengan meminta front-end untuk menandatangani beberapa string menggunakan sertifikat).
- Aplikasi ini memiliki database beberapa data disimpan yang memungkinkan setiap pengguna untuk dipetakan ke userid-nya. Ini mungkin
- seluruh sertifikat yang terkait dengan masing-masing userid
- CA dan nomor seri cert yang sesuai dengan setiap id pengguna.
Saya bertanya-tanya mana yang merupakan metode yang umum digunakan? Apa praktik terbaik? Jika saya harus memilih nomor 3, apa cara terbaik untuk melakukan ini?
Sesuatu yang juga dapat dengan mudah bekerja dengan aplikasi smartphone akan menjadi bonus tambahan.
Memperbarui
Izinkan saya mengklarifikasi pernyataan saya "kode bagian otentikasi sendiri" karena beberapa jawaban tampaknya menunjukkan bahwa itu telah disalahpahami - buruk saya karena tidak jelas.
Ini tidak berarti saya sendiri yang menulis kripto. Itu hanya berarti saya benar-benar akan memanggil rutin kripto secara eksplisit daripada bergantung pada IIS atau server web lainnya melakukannya secara implisit.
sumber
Jawaban:
Sementara saya benar-benar ingin menjawab masalah demi masalah, saya pikir saya akan membahas topik ini dengan topik:
Otorisasi / Otentikasi
OK, hal pertama yang pertama. Sebagai contoh, Anda membutuhkan keduanya:
Dari sisi otorisasi, Anda memiliki masalah dalam mengetahui proses yang digunakan untuk menghubungkan DN subjek pengguna Anda ke rekening bank mereka. Mengingat besarnya transaksi, Anda pasti ingin memiliki proses yang kuat untuk ini, dan tidak ada satu pun cara yang tepat di sini. Anda harus berkonsultasi dengan bank, dan mungkin pengacara, untuk mencari tahu bagaimana melakukan ini sesuai dengan kebijakan.
SSL, Otentikasi Klien / Server, Bukti Kunci Pribadi
Protokol SSL selalu menyertakan otentikasi server, dengan pengaturan opsional tambahan untuk otorisasi sisi klien. Anda benar dengan # 1 di Apache yang menawarkan pengaturan yang menambahkan Otentikasi Klien oleh PKI, dan Anda dapat menyediakannya dengan daftar CA tepercaya. Selama pengaturan sesi SSL yang membutuhkan Otentikasi Klien melalui PKI - Anda akan mendapatkan bukti kunci pribadi.
Opsi # 1 atau opsi # 2 akan menyediakan ini - baik Apache dan IIS dapat dikonfigurasi dengan cara ini. Praktik terbaik, saya akan mengambil salah satu dari menggulung solusi Anda sendiri. # 3 mendekati aturan "jangan tulis crypto Anda sendiri". Dengan asumsi bahwa Anda dapat mengikat transaksi Anda dengan keberadaan sesi SSL terotentikasi, tidak ada alasan untuk menggulirkan transaksi Anda sendiri.
Juga - di salah satu opsi # 1 atau opsi # 2, ada cara untuk mendapatkan seluruh sertifikat Anda, dan dari sana, ke bagian mana pun dari sertifikat. Biasanya DN Subjek dan / atau nomor seri sertifikat digunakan untuk menentukan identitas pengguna untuk tujuan otorisasi.
Dalam hal "penggunaan umum" - semua server web utama cukup umum. IIS, Apache, Tomcat, dan banyak lainnya dapat dikonfigurasi dengan SSL auth klien. Keputusan dari sana sebagian besar didasarkan pada implementasi secara keseluruhan. Server web utama memiliki semua cara untuk mendapatkan akses ke sertifikat yang disediakan dalam sesi SSL, yang merupakan apa yang Anda perlukan untuk verifikasi yang lebih terperinci.
Pengesahan Verifikasi Sertifikat
Minimal, Anda harus:
Mengingat tingginya taruhan perbankan, Anda mungkin juga ingin memverifikasi status pencabutan sertifikat - jika kunci pribadi pengguna hilang atau dicuri, sertifikat mereka harus dicabut.
IIS mungkin memiliki kait untuk verifikasi OCSP atau CRL - ini cenderung menjadi jenis sistem yang lebih komprehensif (pegangan tangan!), Tapi saya tidak ingat dari atas kepala saya. Saya juga tidak ingat apakah itu akan memaksa Anda untuk menggunakan produk Microsoft untuk ini. Untuk Apache, Anda hampir pasti harus membuat kode atau menambahkan pada cek OCSP / CRL. Saya percaya ini memiliki kaitan selama pembentukan sesi SSL - biasanya pemeriksaan ini dilakukan satu kali ketika sesi SSL diatur.
Otorisasi
Pada # 1 vs. # 2 - Anda benar bahwa IIS memiliki beberapa fungsionalitas bawaan yang akan mengikat sertifikat yang disediakan dalam sesi SSL ke repositori AD. Ini adalah salah satu kasus di mana Microsoft berusaha keras untuk membuatnya mudah untuk membeli dan menggunakan lebih banyak produk itu. :) Ada nuansa bagaimana IIS mengikat ke dalam AD yang berada di luar lingkup pertanyaan ini dan di luar ingatan langsung saya. Saya telah melakukan beberapa hal yang cukup gila dengan IIS dan AD, dan pemikiran umum saya adalah ketika Anda melakukan sesuatu yang relatif sederhana seperti menarik nama pengguna berdasarkan sertifikat dari repositori AD - Anda mungkin baik-baik saja. Saat Anda mengalami masalah penyimpanan data yang lebih kompleks, pencarian AD yang aneh, dan hal-hal gila (tapi sah) dengan PKI, Anda
Dengan IIS, bahkan masih - Anda akan perlu sesuatu ditambahkan ke struktur AD Anda, atau di tempat lain, mengikat nama pengguna ke rekening bank. Biasanya di perbankan, pengguna memiliki banyak akun. Dan 2 pengguna dapat memiliki akun bersama, jadi ini adalah hubungan banyak ke banyak.
Untuk # 1 - ya, Anda perlu menulis pencarian Anda sendiri. Anda perlu kode: - database atau hirarki LDAP yang menghubungkan sertifikat ke pengguna dan pengguna ke rekening bank pengguna. Bagian unik yang dijamin dari sertifikat adalah nomor seri + penerbit DN. Seringkali DN Subjek akan berfungsi, tetapi tidak dijamin di semua sistem PKI.
Begitulah biasanya pengembang menggunakan PKI untuk otentikasi kelas atas dengan Apache melakukannya. Setelah bekerja di sejumlah sistem ini, saya belum menemukan kasus penggunaan kembali yang mudah, jadi saya tidak pernah benar-benar melihatnya sebagai minus besar - saya harus memiliki sesuatu yang terspesialisasi baik cara, karena peran / hak istimewa adalah tidak pernah mudah.
Ini terdengar seperti campuran # 1 dan # 3 - saran kuat saya adalah - gunakan kemampuan asli dari aplikasi / server web apa pun yang Anda gunakan untuk membuat sesi SSL. Itu akan membiarkan browser untuk setup server dengan permintaan sertifikat berlangsung dalam cara standar, praktik terbaik,. Dari sana, dengan Apache, Anda harus menggulung sistem otorisasi Anda sendiri. IIS akan memberikan gagasan Microsoft tentang bagaimana ini harus bekerja untuk Anda.
Gotchas yang dikenal
Lakukan banyak pengujian browser. Dari tahun ke tahun, peramban ke peramban, saya menemukan gotcha dengan penanganan sesi SSL. Merantai sesi SSL dengan benar ke serangkaian permintaan halaman web dan memastikan bahwa logout ditangani dengan benar adalah area terbesar yang menjadi perhatian. Dan itu banyak hubungannya dengan server dan perangkat lunak browser. SSL cukup stabil sehingga ketika berfungsi, biasanya berfungsi, meskipun mungkin ada masalah IE vs yang lainnya.
Secara khusus, terakhir kali saya melakukan ini, pertanyaan tentang force coding dan sesi time out adalah masalah besar.
Ponsel Pintar
Baik. Keberuntungan. adalah tentang semua yang bisa saya katakan. Saya sama sekali bukan pengembang aplikasi seluler, tetapi kesan saya sejauh ini adalah bahwa di ponsel pintar rata-rata, penanganan sertifikat PKI tidak setara atau tidak ada.
Saya sangat ingin dibuktikan salah.
sumber
Sertifikat pribadi berfungsi dengan baik untuk pembaruan sertifikat secara berkala (yang memiliki proses yang cukup kuat di belakangnya) dan dapat diimplementasikan sebagai otentikasi "tanpa kata sandi" yang disukai pelanggan
tetapi di mana gagal itu
perlu diketahui bahwa sertifikat pribadi modern dengan penandatanganan sha-2 tidak berfungsi dengan Safari di iPad dan banyak peramban modern. Ini karena sertifikat pribadi tidak pernah benar-benar lepas landas seperti yang diperkirakan oleh otoritas sertifikasi. Menerbitkan 30.000 sertifikat (apa yang kami lakukan) harganya hampir sama per sertifikat dengan beberapa jenis token perangkat keras.
Strategi Anda untuk memungkinkan pelanggan menemukan sertifikat sendiri tidak benar-benar valid. Sulit menemukan pemasok sertifikat pribadi saat ini dan harganya cukup mahal - Anda perlu memastikan bahwa kasing bisnis berfungsi jika tidak, pelanggan tidak akan membelinya.
sumber
Oke, banyak yang terjadi di sini. Hal pertama yang pertama, otentikasi sertifikat klien tidak berguna jika tidak didukung pada titik akhir. Jadi, kami memiliki pos hebat dari Intrepidus yang membahas dasar-dasar otentikasi klien untuk aplikasi ponsel cerdas .
Selanjutnya, izinkan saya sangat menyarankan Anda untuk tidak menyusun kode rutin otentikasi sendiri. Ada banyak perpustakaan besar yang diperiksa yang menangani ini. Anda akan menyelamatkan sendiri fungsionalitas dan bug keamanan dengan menjalankannya dengan perpustakaan yang sudah dewasa untuk auth. Menggunakan perpustakaan yang sudah matang dan sudah diperiksa untuk ini pasti akan menjadi praktik terbaik.
Praktik terbaik berikutnya adalah menggunakan direktori untuk menangani klien Anda: pemetaan sertifikat. Jadi, Anda akan melihat AD atau LDAP. Seperti yang Anda sebutkan, Windows dan IIS membuat ini sangat mulus untuk Anda. IIS.net memiliki ikhtisar yang baik tentang konfigurasi pemetaan sertifikat di bawah IIS .
Jika Anda menggunakan Apache, ini tidak semudah itu. Sepertinya mod_authz_ldap melakukan pemetaan sertifikat klien, tapi saya belum secara pribadi bekerja dengannya.
Sehingga membawa kita pada logistik untuk benar-benar mengimplementasikan sesuatu seperti ini. Anda tidak menandatangani sertifikat pengguna, jadi Anda perlu proses ketat untuk pengguna yang mengirimkan sertifikat mereka dan meminta aplikasi Anda mempublikasikannya ke direktori. Saya ingin melihat dua faktor untuk ini, dengan kata sandi dan pesan teks atau panggilan ke nomor tepercaya. Saya akan mengirim email kepada pengguna untuk memberi tahu mereka bahwa sertifikat telah ditambahkan ke akun mereka. Saya akan membiarkan pengguna menghapus pemetaan sertifikat pengguna melalui halaman manajemen akun mereka di aplikasi.
Saya akan melihat apa yang Google dan Facebook lakukan untuk mengatur cookie untuk perangkat tepercaya untuk menghindari dua faktor. Saya akan memiliki perangkat baru auth dengan dua faktor sebelum mengizinkan auth hanya-sertifikat.
Saya juga akan berpikir tentang bagaimana menangani sertifikat pengguna yang dicabut. Ini berarti memeriksa daftar pencabutan sertifikat eksternal (CRL). Apa yang Anda lakukan jika sertifikat klien tidak memiliki titik distribusi CRL yang ditentukan? Apakah Anda memeriksa CRL setiap kali pengguna masuk, atau secara terjadwal sebagai bagian dari suatu pekerjaan, karena kemungkinan hanya ada sedikit CRL yang digunakan?
Sungguh, ini bermuara pada: bagaimana saya tahu saya bisa percaya bahwa sertifikat pengguna belum dikompromikan, dan bagaimana saya percaya bahwa saya bisa memetakan sertifikat X ke pengguna Y.
sumber