Unduhan di situs web terkadang memiliki checksum MD5, memungkinkan orang untuk mengkonfirmasi integritas file. Saya telah mendengar bahwa ini tidak hanya memungkinkan file yang rusak diidentifikasi secara instan sebelum menyebabkan masalah, tetapi juga agar perubahan berbahaya mudah dideteksi.
Saya mengikuti logika sejauh menyangkut korupsi file, tetapi jika seseorang dengan sengaja ingin mengunggah file jahat , maka mereka dapat menghasilkan MD5 checksum yang sesuai dan mempostingnya di situs unduhan beserta file yang diubah. Ini akan menipu siapa pun yang mengunduh file tersebut dengan berpikir bahwa file itu tidak diubah.
Bagaimana MD5 checksum dapat memberikan perlindungan terhadap file yang diubah secara sengaja jika tidak ada cara untuk mengetahui apakah checksum itu sendiri telah dikompromikan?
Jawaban:
Nah, Anda salah dengar, kalau begitu. Checksum MD5 (atau SHA atau apa pun) disediakan (di sebelah tautan unduhan, khusus ) hanya untuk memverifikasi unduhan yang benar. Satu-satunya hal yang ingin mereka jamin adalah Anda memiliki file yang sama dengan server. Tidak lebih, tidak kurang. Jika server dikompromikan, Anda SOL. Ini sangat sederhana.
sumber
Solusi yang digunakan oleh beberapa sistem manajemen paket seperti dpkg adalah menandatangani hash : gunakan hash sebagai input ke salah satu algoritma penandatanganan kunci publik. Lihat http://www.pgpi.org/doc/pgpintro/#p12
Jika Anda memiliki kunci publik dari penanda tangan, Anda dapat memverifikasi tanda tangan, yang membuktikan bahwa hash tidak dimodifikasi. Ini hanya membuat Anda memiliki masalah untuk mendapatkan kunci publik yang tepat di muka, meskipun jika seseorang pernah merusak distribusi kunci mereka juga harus merusak semua yang Anda bisa verifikasi dengan itu jika tidak Anda akan melihat bahwa ada sesuatu yang aneh sedang terjadi.
sumber
Asumsi Anda benar. Namun ada pengecualian. Jika server menyediakan file dan halaman di mana hash tidak dikelola oleh entitas yang sama. Dalam hal ini pengembang perangkat lunak mungkin ingin mengatakan "hei orang mengunduh ini dari tempat itu tetapi hanya percaya jika hash = xxxx". (Ini mungkin berguna untuk CDN sebagai contoh). Saya kira ini adalah alasan mengapa seseorang melakukannya sejak awal. Daripada yang lain hanya mengikuti berpikir betapa kerennya menunjukkan hash. Bahkan tidak berpikir betapa bergunanya bahkan file dan hash tidak berada di lokasi yang sama.
Setelah ini dikatakan, ini layak apa adanya. Jangan terlalu banyak berasumsi tentang keamanan seperti yang sudah dinyatakan orang lain. Jika dan hanya jika Anda benar-benar dapat mempercayai hash asli, maka file tersebut bagus. Kalau tidak, seorang penyerang dengan motivasi dan pengetahuan yang cukup dapat merusak file dan hash, bahkan jika ini ada di server yang berbeda dan dikelola oleh entitas yang berbeda.
sumber
Terkadang checksum disediakan dengan aman, tetapi unduhan tidak. Karena MD5 rusak , checksum MD5 keamanan memberikan lebih lemah daripada checksum lebih aman, tetapi sebelum MD5 rusak, MD5 yang disediakan dengan aman (mis. Yang ditandatangani dengan PGP atau GPG atau Gatekeeper, atau diambil alih HTTPS) yang cocok dengan MD5 dari unduhan adalah bukti kuat bahwa unduhan yang diterima adalah yang disediakan oleh server.
Saya telah menulis tentang kurangnya checksum yang aman selama bertahun-tahun, di sini .
Pengguna tidak boleh mengunduh file executable yang tidak dipercaya melalui jaringan yang tidak dipercaya dan menjalankannya, karena risiko serangan MITM. Lihat, misalnya "Ketidakamanan dalam sistem pembaruan otomatis" oleh P. Ruissen, R. Vloothuis.
Adendum 2014: Tidak, BUKAN itu salah "checksum yang diposting di halaman web digunakan untuk mendeteksi modifikasi berbahaya," karena ini ADALAH peran yang dapat mereka lakukan. Mereka memang membantu melindungi dari korupsi yang tidak disengaja, dan jika dilayani dengan HTTPS atau dengan tanda tangan yang terverifikasi (atau lebih baik, keduanya) membantu melindungi dari korupsi jahat! Saya telah mendapatkan checksum lebih dari HTTPS dan memverifikasi bahwa mereka cocok dengan unduhan HTTP berkali-kali.
Saat ini, binari sering didistribusikan dengan hash yang ditandatangani dan diverifikasi secara otomatis, tetapi bahkan ini tidak sepenuhnya aman .
Kutipan dari tautan di atas: "Aplikasi KeRanger ditandatangani dengan sertifikat pengembangan aplikasi Mac yang valid; oleh karena itu, aplikasi ini dapat mem-bypass perlindungan Gatekeeper Apple." ... "Apple sejak itu telah mencabut sertifikat yang disalahgunakan dan memperbarui tanda tangan antivirus XProtect, dan Proyek Transmisi telah menghapus installer jahat dari situs webnya. Palo Alto Networks juga memperbarui penyaringan URL dan Pencegahan Ancaman untuk menghentikan KeRanger dari sistem yang berdampak. Analisis Teknis
Kedua installer Transmisi terinfeksi KeRanger ditandatangani dengan sertifikat yang sah yang dikeluarkan oleh Apple. Pengembang yang mendaftar sertifikat ini adalah perusahaan Turki dengan ID Z7276PX673, yang berbeda dari ID pengembang yang digunakan untuk menandatangani versi sebelumnya dari penginstal Transmisi. Dalam informasi penandatanganan kode, kami menemukan bahwa pemasang ini dibuat dan ditandatangani pada pagi hari tanggal 4 Maret. "
Tambahan 2016:
@Cornstalks: Re. komentar Anda di bawah ini: Salah. Seperti yang baru-baru ini dicatat pada artikel Wikipedia serangan tabrakan yang Anda tautkan ke, "Pada 2007, serangan tabrakan awalan yang dipilih ditemukan terhadap MD5" dan "penyerang dapat memilih dua dokumen yang berbeda secara sewenang-wenang, dan kemudian menambahkan nilai terhitung yang berbeda yang menghasilkan keseluruhan dokumen yang memiliki nilai hash yang sama. " Jadi, bahkan jika MD5 disediakan dengan aman dan penyerang tidak dapat memodifikasinya, penyerang masih BISA menggunakan serangan tabrakan awalan-dipilih dengan malware yang dipilih-awalan yang mengandung malware, yang berarti MD5 TIDAK aman untuk tujuan crypto. Ini adalah alasan utama mengapa US-CERT mengatakan MD5 "harus dianggap rusak secara kriptografis dan tidak cocok untuk penggunaan lebih lanjut."
Beberapa hal lagi: CRC32 adalah sebuah checksum. MD5, SHA, dll. Lebih dari sekadar checksum; mereka dimaksudkan sebagai hash yang aman. Itu berarti mereka seharusnya sangat tahan terhadap serangan tabrakan. Tidak seperti checksum, hash aman yang dikomunikasikan dengan aman melindungi terhadap serangan man-in-the-middle (MITM) di mana MITM berada di antara server dan pengguna. Itu tidak melindungi terhadap serangan di mana server itu sendiri dikompromikan. Untuk melindunginya, orang biasanya mengandalkan sesuatu seperti PGP, GPG, Gatekeeper, dll.
sumber
Ini adalah alasan yang tepat mengapa checksum yang diposting sering membawa penafian yang mengatakan "Ini tidak dapat melindungi dari modifikasi file yang berbahaya". Jadi, jawaban singkatnya adalah "mereka tidak dapat memberikan perlindungan apa pun terhadap file yang sengaja diubah" (meskipun, jika halaman dikirim melalui HTTPS, HTTPS sendiri melindungi terhadap modifikasi; jika file tidak dikirim melalui HTTPS tetapi checksum adalah, maka itu mungkin membantu beberapa, tetapi bukan kasus umum). Siapa pun yang memberi tahu Anda bahwa checksum yang diposting di halaman web digunakan untuk mendeteksi modifikasi berbahaya adalah salah, karena ini bukan peran yang dapat mereka lakukan; semua yang mereka lakukan adalah membantu melindungi dari korupsi yang tidak disengaja , dan malas korupsi jahat (jika seseorang tidak repot-repot mencegat halaman memberi Anda checksum).
Jika Anda ingin melindungi dari modifikasi yang disengaja, Anda harus mencegah orang dari mengacaukan checksum, atau membuatnya mustahil bagi orang lain untuk menghasilkan checksum yang valid. Yang pertama dapat melibatkan memberikannya secara langsung atau serupa (sehingga checksum itu sendiri dipercaya); yang terakhir pergi ke algoritme tanda tangan digital (di mana Anda harus mendapatkan kunci publik dengan aman untuk pengunduh; di TLS, ini dilakukan dengan memercayai otoritas sertifikat secara langsung dan meminta mereka memverifikasi orang lain; itu juga dapat dilakukan melalui jaringan kepercayaan , tetapi intinya adalah bahwa sesuatu harus ditransfer dengan aman di beberapa titik, dan hanya memposting sesuatu di situs Anda tidak cukup).
sumber
Ini benar-benar masalah. Menampilkan checksum di situs yang sama dengan file yang diunduh tidak aman. Seseorang yang dapat mengubah file juga dapat mengubah checksum. Checksum harus ditunjukkan melalui sistem terpisah yang lengkap tetapi ini hampir tidak layak, karena bagaimana memberi tahu pengguna dengan cara yang aman di mana checksum dapat ditemukan.
Solusi yang mungkin adalah penggunaan file yang ditandatangani.
(BTW: MD5 tidak aman di mana pun dan tidak boleh digunakan lagi.)
sumber
Anda sepenuhnya benar. Tujuannya, maka, akan membuat kesalahan "jika" Anda - jika kita tahu bahwa hash kriptografi aman dari suatu file tidak terganggu, maka kami tahu bahwa file tersebut juga tidak dikompromikan.
Misalnya, jika Anda memposting hash file di situs web Anda, dan kemudian menautkan ke salinan file di server mirror pihak ketiga - praktik umum dalam distribusi perangkat lunak kuno-kuno - pengguna Anda dapat dilindungi terhadap beberapa jenis serangan. Jika server mirror berbahaya atau terganggu, tetapi situs web Anda baik-baik saja, mirror tidak akan dapat menumbangkan file Anda.
Jika situs web Anda menggunakan HTTPS, atau Anda menandatangani hash
gpg, file Anda juga dapat (sebagian besar) dilindungi dari penyerang jaringan seperti hotspot Wi-Fi berbahaya, simpul keluar Tor yang nakal, atau NSA.sumber
Anda tidak dapat mengubah MD5 checksum tanpa juga memodifikasi file. Jika Anda mengunduh file, maka unduh hash, dan kemudian perhitungan file Anda tidak sesuai dengan apa yang diberikan, apakah hash atau file salah atau tidak lengkap.
Jika Anda ingin "mengikat" file ke sesuatu yang eksternal, seperti penulis, mesin, dll. Itu harus ditandatangani , menggunakan proses tipe PKI dengan sertifikat. Pembuat file, dll. Dapat menandatangani file dengan kunci privatnya, dan Anda dapat memverifikasi tanda tangan dengan kunci publik, yang harus tersedia untuk umum, itu sendiri ditandatangani oleh CA baik oleh Anda dan penulis, dan dapat diunduh, lebih disukai dari beberapa lokasi.
Memodifikasi file akan membuat tanda tangan tidak valid, jadi ini dapat digunakan untuk memverifikasi integritas file juga.
sumber
Hash menunjukkan apakah versi file Anda ("unduhan") berbeda dari versi server. Mereka tidak memberikan jaminan keaslian file.
Tanda tangan digital (enkripsi asimetris + fungsi hash) dapat digunakan untuk memverifikasi bahwa file tersebut belum dimodifikasi oleh siapa pun yang tidak memiliki kunci pribadi yang sesuai.
Pembuat file mem-hash file dan mengenkripsi hash menggunakan kunci pribadi (rahasia) mereka. Dengan begitu, siapa pun dengan kunci publik (non-rahasia) yang sesuai dapat memverifikasi bahwa hash cocok dengan file, tetapi sementara konten file dapat dimodifikasi, tidak ada yang dapat mengganti hash yang sesuai dengan yang cocok dengan file (setelah hash didekripsi menggunakan menggunakan kunci publik) - kecuali jika mereka berhasil memaksa kunci privat, atau mendapatkan akses entah bagaimana.
Apa yang harus menghentikan Tuan "A. Hacker" dari hanya memodifikasi file, kemudian menandatanganinya dengan kunci pribadi mereka sendiri?
Untuk memvalidasi file, Anda harus membandingkan hash-nya dengan hash yang Anda peroleh dengan mendekripsi tanda tangan digital terkait. Jika Anda berpikir file tersebut dari "IMAwesome", maka Anda mendekripsi hash menggunakan kuncinya dan hash tidak cocok dengan file tersebut, karena hash dienkripsi menggunakan kunci A.Hacker.
Oleh karena itu, tanda tangan digital memungkinkan seseorang mendeteksi perubahan tidak disengaja dan jahat.
Tapi bagaimana kita bisa mendapatkan kunci publik IMAwesome? Bagaimana kita memastikan bahwa ketika kita memperoleh kuncinya, sebenarnya bukan kunci A.Hacker dilayani oleh server yang dikompromikan atau serangan manusia-di-tengah? Di sinilah rantai sertifikat dan sertifikat akar tepercaya masuk, tak satu pun di antaranya yang sepenuhnya aman [1] solusi untuk masalah ini, dan keduanya mungkin harus dijelaskan dengan baik di Wikipedia dan pada pertanyaan lain di SO.
[1] Setelah diperiksa, sertifikat root yang dikirimkan dengan OS Microsoft di PC kerja saya menyertakan sertifikat dari Pemerintah AS. Siapapun dengan akses ke kunci pribadi yang sesuai batuk NSA batuk karena dapat melayani konten untuk web browser yang melewati "apakah ada gembok di address bar" cek. Berapa banyak orang yang benar-benar akan repot mengklik gembok dan melihat siapa pasangan kunci yang digunakan untuk "mengamankan" koneksi?
sumber
Ini pertanyaan yang sangat bagus. Secara umum, penilaian Anda tentang manipulasi MD5 tepat. Tapi saya percaya nilai checksum MD5 pada unduhan adalah dangkal di terbaik. Mungkin setelah Anda mengunduh file, Anda dapat memeriksa MD5 yang Anda miliki terhadap sebuah situs web, tetapi saya cenderung melihat penyimpanan MD5 berdampingan sebagai "tanda terima" atau sesuatu yang baik untuk dimiliki tetapi tidak dapat diandalkan. Karena itu, saya umumnya tidak pernah peduli tentang checksum MD5 dari file yang diunduh, tetapi saya dapat berbicara dari pengalaman saya membuat proses MD5 berbasis server ad-hoc.
Pada dasarnya apa yang telah saya lakukan ketika seorang klien ingin menyapu sistem file untuk MD5 checksum adalah membuatnya dihasilkan ke file CSV yang memetakan nama file, path, MD5 — dan info file lainnya - ke dalam format data terstruktur yang kemudian saya telan. ke dalam basis data untuk perbandingan dan penyimpanan.
Jadi menggunakan contoh Anda, sementara MD5 checksum mungkin duduk di sebelah file di file teks itu sendiri, catatan otoritas MD5 checksum akan disimpan dalam sistem database yang tidak terhubung. Jadi jika seseorang entah bagaimana meretas ke fileshare untuk memanipulasi data, penyusup itu tidak akan memiliki akses ke catatan otoritas MD5 atau riwayat yang terhubung.
Baru-baru ini saya menemukan software perpustakaan yang bagus yang disebut ACE Audit manager yang pada dasarnya adalah aplikasi Java yang dirancang untuk duduk dan menonton filesystem untuk perubahan. Ini mencatat perubahan melalui perubahan MD5. Dan beroperasi pada filosofi yang sama dengan proses ad-hoc saya - menyimpan checksum dalam database - tetapi membawanya selangkah lebih maju tetapi membuat MD5 checksum MD checksum yang dikenal sebagai pohon hash atau pohon Merkle .
Jadi misalkan Anda memiliki 5 file dalam koleksi. Kelima file di ACE Audit manager kemudian akan mendapatkan yang lain — sebut saja “induk” —pilihan yang merupakan hash yang dihasilkan dari checksum 5 MD5 dari setiap file. Jadi jika seseorang mengutak-atik hanya satu file, hash untuk file akan berubah dan begitu juga hash untuk seluruh koleksi "induk".
Secara umum cara Anda perlu melihat MD5 checksum dan hash integritas terkait adalah kecuali mereka tidak terhubung ke beberapa penyimpanan tidak langsung untuk hash MD5 sendiri, mereka dapat rusak. Dan nilainya sebagai alat integritas data jangka panjang setara dengan kunci murah yang “gratis” di bagasi baru; jika Anda serius ingin mengunci bagasi Anda, Anda akan mendapatkan kunci yang tidak dapat dibuka dalam 5 detik dengan penjepit kertas.
sumber
kecepatan
Seringkali orang menemukan bahwa lebih cepat untuk (a) mengunduh file besar dari jaringan pengiriman konten (terdekat) yang tidak terpercaya (mirror terdekat), situs mirror, torrent peer, dll. Dan juga mengunduh file checksum pendek yang sesuai (seringkali SHA256; perangkat lunak yang lebih lama) sering menggunakan MD5) dari beberapa sumber tepercaya. Mereka merasa lambat untuk (b) mengunduh seluruh file besar secara langsung dari sumber yang tepercaya.
validasi
Seringkali orang tersebut menemukan bahwa semuanya valid - sumber (tepercaya dan tidak tepercaya) menyetujui checksum yang sama, dan menjalankan shasum (atau md5sum) dengan salah satu file checksum pendek itu (tidak masalah yang mana, ketika semuanya identik) ) menunjukkan bahwa file besar memiliki checksum yang cocok.
modifikasi
Anda benar bahwa ketika Mallory mengubah file besar yang tersimpan di beberapa situs unduhan, akan mudah bagi Mallory untuk juga merusak checksum untuk file itu di situs unduhan yang sama sehingga shasum (atau md5sum) dijalankan pada file checksum berbahaya itu akan tampaknya memvalidasi file besar. Tetapi file checksum itu bukan satu-satunya yang harus digunakan pengunduh untuk validasi.
Ketika pengunduh membandingkan file checksum berbahaya ke file checksum yang diunduh dari sumber tepercaya, jika checksum asli lolos satu kali saja, maka pengunduh akan melihat bahwa semuanya tidak valid, dan akan tahu bahwa ada sesuatu yang salah.
Seperti yang dikatakan cpast sebelumnya, jika checksum kriptografi yang baik ditransmisikan melalui koneksi tepercaya, itu dapat memberikan keamanan (yang diturunkan dari koneksi tepercaya).
Seperti yang dikatakan supercat sebelumnya, file checksum satu situs tidak membantu orang yang mengunduh file besar dari situs yang sama dan dengan cara yang sama mereka mengunduh file checksum - mereka membantu orang yang ingin mengunduh file dari situs lain.
Checksum kriptografi adalah bagian penting dari tanda tangan kunci publik praktis (seperti yang diterapkan dalam GnuPG dan perangkat lunak yang mendukung OpenPGP lainnya). Tanda tangan kunci publik memiliki beberapa keunggulan dibandingkan checksum saja.
sumber
Nah, Anda belum mendengar benar-benar salah . Tanda tangan digital sebenarnya adalah apa yang digunakan untuk mendeteksi perubahan berbahaya. Untuk beberapa alasan penting, hashing adalah bagian mendasar dari tanda tangan digital, karena hanya hash yang benar-benar ditandatangani , bukan keseluruhan file aslinya.
Yang sedang berkata, jika sumber tidak memberikan tanda tangan dari hash dan cara tepercaya untuk memverifikasinya , maka Anda benar, tidak ada perlindungan terhadap file yang sengaja diubah , tetapi hash masih berguna sebagai checksum terhadap kecelakaan. korupsi .
Berikut adalah contoh dunia nyata yang dapat mengklarifikasi semuanya. Bagian berikut ini sangat penting pada subjek:
sumber