it-swarm-id.com

Bagaimana proses untuk sertifikat digital, tanda tangan, dan ssl bekerja?

Saya telah mencoba memahami bagaimana ssl bekerja. Alih-alih Alice dan Bob, mari pertimbangkan komunikasi klien dan server. Server memiliki sertifikat digital yang diperoleh dari CA. Ini juga memiliki kunci publik dan pribadi. Server ingin mengirim pesan ke Klien. Kunci publik server sudah tersedia untuk klien.

Dengan asumsi bahwa ssl handshake sudah selesai.

Server ke Klien:

  • Server melampirkan kunci publiknya ke pesan.
  • Menjalankan fungsi hash aktif (pesan + kunci publik). Hasilnya dikenal sebagai HMAC.
  • Enkripsi HMAC menggunakan kunci privatnya. Hasilnya disebut tanda tangan digital.
  • Kirim ke Klien bersama dengan sertifikat digital.
  • Klien memeriksa sertifikat dan menemukan bahwa itu dari Server yang diharapkan.
  • Dekripsi HMAC menggunakan kunci publik Server.
  • Jalankan fungsi hash (pesan + kunci publik) untuk mendapatkan pesan asli.

Client to Server

  • Klien menjalankan fungsi hash pada (pesan + kunci publik) dan kemudian mengenkripsi menggunakan kunci publik yang sama.
  • Server mendekripsi menggunakan kunci pribadi, menjalankan fungsi hash pada data yang dihasilkan untuk mendapatkan pesan.

Tolong beri tahu saya jika pemahaman saya benar.

27
John

Ada beberapa kebingungan dalam posting Anda. Pertama-tama, HMAC bukan fungsi hash . Lebih lanjut tentang HMAC nanti.

Fungsi Hash

A fungsi hash adalah algoritma yang sepenuhnya publik (tidak ada kunci dalam hal itu) yang menggabungkan sedikit dengan cara yang benar-benar tidak mungkin untuk dilepaskan: siapa pun dapat menjalankan fungsi hash pada data apa pun, tetapi menemukan data kembali dari hash output tampaknya jauh melampaui akal kita. Output hash memiliki ukuran tetap, biasanya 256 bit (dengan SHA-256) atau 512 bit (dengan SHA-512). Fungsi SHA- * yang menghasilkan 160 bit disebut SHA-1, bukan SHA-160, karena kriptografer yang dibiarkan menggunakan perangkat mereka sendiri dapat tetap masuk akal hanya selama itu, dan tentu saja tidak melebihi pint kelima.

Algoritma Tanda Tangan

A signature algoritma menggunakan sepasang kunci, yang secara matematis dihubungkan bersama, kunci pribadi dan kunci publik ( mengkomputasi ulang kunci privat dari kunci publik secara teoritis layak tetapi terlalu sulit untuk dilakukan dalam praktek, bahkan dengan Komputer Sungguh Besar, itulah sebabnya kunci publik dan dijadikan publik sementara kunci privat tetap privat). Menggunakan struktur matematika tombol, algoritma tanda tangan memungkinkan:

  • untuk menghasilkan tanda tangan pada beberapa data input, menggunakan kunci pribadi (tanda tangan adalah objek matematika yang cukup kompak, misalnya beberapa ratus byte untuk tanda tangan RSA khas);
  • untuk verifikasi tanda tangan pada beberapa data input, menggunakan kunci publik. Verifikasi mengambil sebagai parameter tanda tangan, data input, dan kunci publik, dan mengembalikan "sempurna, man!" atau "kawan, ini tidak cocok".

Untuk algoritma tanda tangan yang aman, seharusnya tidak layak untuk menghasilkan nilai tanda tangan dan memasukkan data sedemikian rupa sehingga algoritma verifikasi dengan kunci publik yang diberikan mengatakan "baik", kecuali Anda tahu kunci pribadi yang sesuai, dalam hal ini mudah dan efisien. Perhatikan cetakan kecil: tanpa kunci pribadi, Anda tidak dapat menyulap beberapa data dan nilai tanda tangan yang berfungsi dengan kunci publik, bahkan jika Anda dapat memilih data dan tanda tangan sesuai keinginan.

"Seharusnya tidak layak" berarti bahwa semua cryptographers pintar di dunia bekerja di sana selama beberapa tahun dan belum menemukan cara untuk melakukannya, bahkan setelah pint kelima.

Sebagian besar (sebenarnya, semua) algoritma tanda tangan mulai dengan memproses data input dengan fungsi hash, dan kemudian bekerja pada nilai hash saja. Ini karena algoritma tanda tangan membutuhkan objek matematika dalam beberapa set yang diberikan yang ukurannya terbatas, sehingga mereka perlu bekerja pada nilai yang "tidak terlalu besar", seperti output dari fungsi hash. Karena sifat fungsi hash, semuanya berjalan dengan baik (menandatangani output hash sama seperti menandatangani input hash).

Pertukaran Kunci dan Enkripsi Asimetris

A key exchange protocol adalah protokol di mana kedua pihak saling melempar objek matematika, setiap objek mungkin dihubungkan dengan beberapa nilai rahasia yang mereka simpan untuk mereka, dengan cara yang mirip dengan publik/pasangan kunci pribadi. Pada akhir pertukaran kunci, kedua belah pihak dapat menghitung "nilai" yang sama (objek matematika lain) yang benar-benar menghindari pemahaman siapa pun yang mengamati bit yang dipertukarkan pada kawat. Salah satu jenis umum dari algoritma pertukaran kunci adalah enkripsi asimetris. Enkripsi asimetris menggunakan pasangan kunci publik/pribadi (tidak harus sama dengan algoritma tanda tangan):

  • Dengan kunci publik Anda dapat mengenkripsi sepotong data. Data itu biasanya dibatasi ukurannya (mis. Tidak lebih dari 117 byte untuk RSA dengan kunci publik 1024-bit). Hasil enkripsi adalah, coba tebak, objek matematika yang dapat dikodekan ke dalam urutan byte.
  • Dengan kunci pribadi, Anda dapat mendekripsi, yaitu melakukan operasi terbalik dan memulihkan data input awal. Diasumsikan bahwa tanpa kunci pribadi, keberuntungan sulit.

Kemudian protokol pertukaran kunci berjalan sebagai berikut: satu pihak memilih nilai acak (urutan byte acak), mengenkripsi itu dengan kunci publik rekan, dan mengirimkannya. Rekan menggunakan kunci pribadinya untuk mendekripsi, dan memulihkan nilai acak, yang merupakan rahasia bersama.

Penjelasan historis tanda tangan adalah: "enkripsi dengan kunci pribadi, dekripsi dengan kunci publik". Lupakan penjelasan itu. Ini salah. Mungkin benar hanya untuk algoritma tertentu (RSA), dan, sekali lagi, hanya untuk RSA versi bastardized yang sebenarnya gagal memiliki keamanan yang layak. Jadi no , tanda tangan digital bukan enkripsi asimetris "terbalik".

Kriptografi Simetris

Setelah dua pihak memiliki nilai rahasia bersama, mereka dapat menggunakan kriptografi simetris untuk bertukar data lebih lanjut dengan cara rahasia. Ini disebut simetris karena kedua belah pihak memiliki kunci yang sama, yaitu pengetahuan yang sama, yaitu kekuatan yang sama. Tidak ada lagi dikotomi pribadi/publik. Dua primitif digunakan:

  • Enkripsi simetris : cara membuat data dan menguraikannya nanti.
  • Kode Otentikasi Pesan : a "checksum kunci": hanya orang yang mengetahui kunci rahasia yang dapat menghitung MAC pada beberapa data (seperti algoritme tanda tangan di mana kunci privat dan publik identik - jadi kunci "publik" sebaiknya tidak publik!).

HMAC adalah sejenis MAC yang dibangun di atas fungsi hash dengan cara yang cerdas, karena ada banyak cara yang tidak cerdas untuk melakukannya, dan yang gagal karena detail halus pada apa yang disediakan fungsi hash dan tidak tersedia.

Sertifikat

A sertifikat adalah wadah untuk kunci publik. Dengan alat yang dijelaskan di atas, orang dapat mulai membayangkan bahwa server akan memiliki kunci publik, yang akan digunakan klien untuk melakukan pertukaran kunci dengan server. Tetapi bagaimana klien memastikan bahwa ia menggunakan kunci publik server yang tepat, dan bukan penyerang yang licik, seorang penjahat yang secara cerdik menyamar sebagai server? Di situlah sertifikat berperan. Sertifikat adalah ditandatangani oleh seseorang yang berspesialisasi dalam memverifikasi identitas fisik; ini disebut a Otoritas Sertifikat. CA memenuhi server "dalam kehidupan nyata" (misalnya di sebuah bar), memverifikasi identitas server, mendapatkan kunci publik server dari server sendiri, dan menandatangani keseluruhan lot (identitas server dan kunci publik). Ini menghasilkan bundel yang bagus yang disebut sertifikat. Sertifikat mewakili jaminan oleh CA bahwa nama dan kunci publik cocok satu sama lain (mudah-mudahan, CA tidak terlalu mudah tertipu, sehingga jaminan dapat diandalkan - lebih disukai, CA tidak not tandatangani sertifikat setelah pint kelima).

Klien, setelah melihat sertifikat, dapat memverifikasi tanda tangan pada sertifikat relatif ke kunci publik CA, dan dengan demikian mendapatkan kepercayaan bahwa kunci publik server benar-benar milik server yang dimaksud.

Tapi, Anda akan memberi tahu saya, apa yang telah kita dapatkan? Kita masih harus tahu kunci publik, yaitu kunci publik CA. Bagaimana kami memverifikasi itu? Ya, kita bisa menggunakan yang lain CA. Ini hanya memindahkan masalah, tetapi bisa berakhir dengan masalah mengetahui a priori kunci publik yang unik atau sedikit dari über-CA yang tidak ditandatangani oleh orang lain. Dengan penuh pertimbangan, Microsoft menyematkan sekitar seratus "kunci publik root" (juga disebut "trust anchors") jauh di dalam Internet Explorer itu sendiri. Di sinilah kepercayaan berasal (tepatnya, Anda kehilangan basis kepercayaan Anda kepada perusahaan Redmond - sekarang Anda mengerti bagaimana Bill Gates menjadi orang terkaya di dunia?).

[~ # ~] ssl [~ # ~]

Sekarang mari kita satukan semuanya, dalam protokol SSL, yang sekarang dikenal sebagai TLS ("SSL" adalah nama protokol ketika itu adalah properti dari Netscape Perusahaan).

Klien ingin berbicara dengan server. Ia mengirim pesan ("ClientHello") yang berisi banyak data administratif, seperti daftar algoritma enkripsi yang didukung klien.

Server merespons ("ServerHello") dengan memberi tahu algoritma mana yang akan digunakan; kemudian server mengirim sertifikatnya ("Sertifikat"), mungkin dengan beberapa sertifikat CA jika klien mungkin membutuhkannya (bukan sertifikat root, tetapi sertifikat perantara, underling-CA).

Klien memverifikasi sertifikat server dan mengekstrak kunci publik server dari itu. Klien menghasilkan nilai acak ("rahasia pra-master"), mengenkripsi dengan kunci publik server, dan mengirimkan itu ke server ("ClientKeyExchange").

Server mendekripsi pesan, memperoleh pre-master, dan mengambil darinya kunci rahasia untuk enkripsi simetris dan MAC. Klien melakukan perhitungan yang sama.

Klien mengirim pesan verifikasi ("Selesai") yang dienkripsi dan di-MAC dengan kunci yang diturunkan. Server memverifikasi bahwa pesan Selesai tepat, dan mengirimkan pesan "Selesai" sendiri sebagai tanggapan. Pada saat itu, baik klien dan server memiliki semua kunci simetris yang mereka butuhkan, dan tahu bahwa "jabat tangan" telah berhasil. Data aplikasi (mis. Permintaan HTTP) kemudian dipertukarkan, menggunakan enkripsi simetris dan MAC.

Tidak ada kunci publik atau sertifikat yang terlibat dalam proses di luar jabat tangan. Enkripsi hanya simetris (mis. 3DES, AES atau RC4) dan MAC (biasanya HMAC dengan SHA-1 atau SHA-256).

38
Tom Leek

Setelah banyak perjuangan. Saya memiliki pemahaman di bawah ini tentang perbedaan antara SSL, enkripsi kunci Asymmetric, Digital Certificate (DC) dan Digital Signature (DS).

Apa itu Digital Certificate, juga dikenal sebagai sertifikat kunci publik?

DC adalah dokumen elektronik yang menggunakan tanda tangan digital untuk mengikat kunci publik dengan informasi identitas seperti nama, alamat, dll

Isi sertifikat: Sertifikat kunci publik

Yang paling penting adalah, Signature-Algorithm, Issuer dan Public Key.

Apa itu enkripsi kunci asimetris dan tanda tangan digital?

Dijelaskan dengan contoh.

Kedua mesin memiliki sepasang kunci kriptografi - kunci enkripsi publik dan kunci dekripsi pribadi.

Machine-A memiliki akses ke kunci publik dan sertifikat Machine-B.
Mesin-B memiliki akses ke kunci publik dan sertifikat Machine-A.

Mesin-A ke Mesin-B

Di Mesin-A:

  • Hash_function (Data) = Hash
  • Enkripsi (Hash) menggunakan kunci pribadi Machine-A = DS
  • Lampirkan Data ke DS dan DC = Data + DS + DC
  • Enkripsi (Data + DS + DC) menggunakan kunci publik Machine-B.
  • Kirim ke Machine-B.

Di Mesin-B:

  • Dekripsi (Data + DS + DC) menggunakan kunci pribadi Machine-B.
  • Verifikasi DC untuk mengotentikasi Mesin-A.
  • Decrypt (DS) menggunakan kunci publik Machine-A = Hash # 1
  • Hash_function (Data) = Hash # 2
  • if (Hash # 1 == Hash # 2) Data dan tanda tangan valid.

Mesin-B ke Mesin-A

Prosesnya sekarang justru kebalikan dari yang di atas.

Apa itu SSL/TLS?

Protokol TLS memungkinkan aplikasi klien/server untuk berkomunikasi di seluruh jaringan dengan cara yang dirancang untuk mencegah menguping dan merusak. Di sebagian besar komunikasi Client-Server, hanya Server yang perlu diautentikasi. TLS merampingkan enkripsi kunci Asimetris untuk memanfaatkan fenomena ini secara efektif. Secure Sockets Layer

Contoh Klien dan Server.

Server memiliki sertifikat digital yang diperoleh dari CA. Ini juga memiliki kunci publik dan pribadi.

Pengguna mengklik URL yang dimulai dengan

https: //

Koneksi aman diperlukan untuk sesi ini. Browser membuat koneksi TCP pada HTTPS TCP Port 443.

  1. Klien> Server: SYN
  2. Klien <Server: SYN + ACK
  3. Klien> Server: ACK

    Jabat tangan SSL pada koneksi TCP baru:

  4. Klien> Server: CLIENT_HELLO

    Klien mengirim perintah CLIENT_HELLO ke server, yang meliputi:

    • Versi SSL dan TLS tertinggi yang didukung oleh klien.
    • Cipers didukung oleh klien. Cipher terdaftar sesuai urutan preferensi.
    • Metode kompresi data yang didukung oleh klien.
    • ID sesi. Jika klien memulai sesi SSL baru, ID sesi adalah 0.
    • Data acak yang dihasilkan oleh klien untuk digunakan dalam proses pembuatan kunci.
  5. Klien <Server: SERVER_HELLO

    Server mengirimkan perintah SERVER_HELLO ke klien, yang meliputi:

    • Versi SSL atau TLS yang akan digunakan untuk sesi SSL.
    • Cipher yang akan digunakan untuk sesi SSL.
    • Metode kompresi data yang akan digunakan untuk sesi SSL.
    • ID sesi untuk sesi SSL.
    • Data acak yang dihasilkan oleh server untuk digunakan dalam proses pembuatan kunci.
  6. Klien <Server: CERTIFICATE (KEY PUBLIC)

    Server mengirimkan perintah CERTIFICATE. Ini termasuk sertifikat server.

  7. Klien <Server: SERVER_DONE

    Server mengirim perintah SERVER_DONE. Perintah ini menunjukkan bahwa server telah menyelesaikan fase jabat tangan SSL ini.

  8. Klien> Server: CERTIFICATE_VERIFY

    Klien memberi tahu server bahwa ia telah memverifikasi sertifikat server

  9. Klien> Server:

    Dengan menggunakan semua data yang dihasilkan dalam jabat tangan sejauh ini, klien (dengan kerja sama server, tergantung pada cipher yang digunakan) menciptakan rahasia pra-master untuk sesi tersebut, mengenkripsi dengan kunci publik server (diperoleh dari sertifikat server) ), dan kemudian mengirim rahasia pra-master terenkripsi ke server.

    Server menggunakan kunci privatnya untuk mendekripsi rahasia pra-master, dan kemudian melakukan serangkaian langkah-langkah untuk menghasilkan rahasia master.

    Klien juga melakukan serangkaian langkah yang sama pada rahasia pra-master untuk menghasilkan rahasia master yang sama.

    Catatan: Dalam situasi di mana klien perlu diautentikasi, klien juga menandatangani sepotong data lain yang unik untuk jabat tangan ini dan dikenal oleh klien dan server. Dalam hal ini, klien mengirim data yang ditandatangani dan sertifikat milik klien ke server bersama dengan rahasia pra-master terenkripsi.

  10. Klien <> Server:

    Baik klien dan server menggunakan rahasia utama untuk menghasilkan kunci sesi, yang merupakan kunci simetris yang digunakan untuk mengenkripsi dan mendekripsi informasi yang dipertukarkan selama sesi SSL dan untuk memverifikasi integritasnya.

    Catatan: Mulai sekarang enkripsi kunci simetrisnya.

  11. Klien> Server:

    Klien mengirim pesan ke server yang memberitahukan bahwa pesan di masa depan dari klien akan dienkripsi dengan kunci sesi.

  12. Klien> Server: SELESAI

    Klien kemudian mengirimkan pesan terpisah (terenkripsi) yang menunjukkan bahwa bagian dari jabat tangan selesai.

  13. Klien <Server:

    Server mengirim pesan ke klien yang memberitahukan bahwa pesan di masa mendatang dari server akan dienkripsi dengan kunci sesi.

  14. Klien <Server: SELESAI

    Server mengirimkan pesan terpisah (terenkripsi) yang menunjukkan bahwa bagian dari jabat tangan selesai.

    Jabat tangan SSL sekarang selesai dan sesi dimulai. Klien dan server menggunakan kunci sesi untuk mengenkripsi dan mendekripsi data yang mereka kirim satu sama lain dan untuk memvalidasi integritasnya.

4
John

Untuk penjelasan lebih rinci "di bawah tenda", saya juga dapat menyarankan artikel berikut: Beberapa Milidetik Pertama dari Koneksi HTTPS oleh Jeff Moser. Artikel ini menggunakan tangkapan paket dari sesi komunikasi HTTPS untuk menggambarkan bagaimana protokol bekerja. Sangat menarik untuk melihat hal-hal yang kita bicarakan dalam aksi dan membersihkan banyak tempat "gelap".

2
George

Tidak terlalu; sertifikat hanya berlaku saat jabat tangan SSL awal atau selama negosiasi ulang SSL. Setelah itu, cipher simetris seperti AES, (3) DES, atau RC4 akan digunakan. Crypto kunci-publik umumnya lebih mahal daripada crypto simetris, sehingga pada umumnya digunakan untuk menyetujui kunci simetris pada awalnya.

1
Steve Dispensa