Enkripsi surel adalah enkripsi pesan elektronik untuk melindungi konten agar tidak dibaca oleh entitas selain penerima yang dimaksud. Enkripsi surel juga dapat mencakup otentikasi.

Dengan desain asli dari protokol email, komunikasi antara server email adalah teks biasa, yang menimbulkan risiko keamanan yang besar. Selama bertahun-tahun, berbagai mekanisme telah diusulkan untuk mengenkripsi komunikasi antara server email. Enkripsi dapat terjadi pada tingkat transportasi (alias "hop by hop ") atau end-to-end. Enkripsi layer Transport sering kali lebih mudah diatur dan digunakan; enkripsi end-to-end memberikan pertahanan yang lebih kuat, tetapi bisa lebih sulit untuk diatur dan digunakan [1]

Enkripsi Tingkat Pengangkutan sunting

Salah satu ekstensi enkripsi email yang paling umum digunakan adalah STARTTLS. Ini adalah lapisan TLS (SSL) di atas komunikasi plaintext, yang memungkinkan server email untuk meningkatkan komunikasi plaintext mereka ke komunikasi terenkripsi. Dengan asumsi bahwa server email pada pengirim dan sisi Penerima mendukung komunikasi terenkripsi, sebuah penyadapan mengintai komunikasi antara server mail tidak dapat menggunakan Sniffer untuk melihat isi email. Ekstensi STARTTLS serupa ada untuk komunikasi antara klien email dan server email (Lihat IMAP4 dan POP3, seperti yang dinyatakan oleh RFC 2595). STARTTLS dapat digunakan terlepas dari apakah isi email dienkripsi menggunakan protokol lain.

Pesan terenkripsi terungkap, dan dapat diubah oleh, relay email menengah. Dengan kata lain, enkripsi terjadi antara relay SMTP individu, bukan antara pengirim dan Penerima. Ini memiliki konsekuensi baik dan buruk. Sebuah kunci sifat positif dari enkripsi lapisan transportasi adalah bahwa pengguna tidak perlu melakukan atau mengubah apa pun; enkripsi secara otomatis terjadi saat mereka mengirim email. Selain itu, karena menerima organisasi dapat mendekripsi email tanpa kerja sama dari pengguna akhir, menerima organisasi dapat menjalankan pemindai virus dan filter spam sebelum mengirimkan email ke penerima. Namun, ini juga berarti bahwa organisasi Penerima dan siapa pun yang menerobos masuk ke dalam sistem email organisasi itu (kecuali jika langkah lebih lanjut diambil) dapat dengan mudah membaca atau memodifikasi email. Jika organisasi Penerima dianggap sebagai ancaman, maka enkripsi end-to-end diperlukan. Electronic Frontier Foundation mendorong penggunaan STARTTLS, dan telah meluncurkan inisiatif ' STARTTLS di mana-mana ' untuk membuatnya sederhana dan mudah bagi semua orang untuk membantu memastikan komunikasi mereka (melalui email) tidak rentan terhadap pengawasan massal. [2]

Dukungan untuk STARTTLS telah menjadi sangat umum; Google melaporkan bahwa di GMail 90% email masuk dan 90% email keluar dienkripsi menggunakan STARTTLS oleh 2018-07-24. [3]

Verifikasi sertifikat wajib secara historis tidak layak untuk pengiriman surat Internet tanpa informasi tambahan, karena banyak Sertifikat tidak dapat diverifikasi dan beberapa pengiriman email ingin gagal dalam kasus tersebut. [4]
Akibatnya, sebagian besar email yang dikirim melalui TLS hanya menggunakan enkripsi oportunistik. DANE adalah standar yang diusulkan yang membuat transisi tambahan untuk diverifikasi enkripsi untuk pengiriman surat Internet mungkin. [5]
Proyek STARTTLS EVERYWHERE menggunakan pendekatan alternatif: mereka mendukung "daftar preload" dari server email yang telah berjanji untuk mendukung STARTTLS, yang dapat membantu mendeteksi dan mencegah serangan downgrade.

Enkripsi Ujung ke Ujung sunting

Enkripsi end-to-end, data dienkripsi dan didekripsi hanya pada titik akhir. Dengan kata lain, sebuah email yang dikirim dengan enkripsi end-to-end akan dienkripsi pada sumber, tidak dapat dibaca oleh penyedia layanan seperti Gmail dalam transit, dan kemudian didekripsi pada titik akhir. Krusial, email hanya akan didekripsi untuk pengguna akhir di komputer mereka dan akan tetap dalam bentuk terenkripsi dan tidak terbaca ke layanan email seperti Gmail, yang tidak akan memiliki kunci yang tersedia untuk mendekripsi itu. [6]
Beberapa layanan email mengintegrasikan enkripsi end-to-end secara otomatis.

Protokol penting untuk enkripsi email end-to-end meliputi:

OpenPGP adalah standar enkripsi data yang memungkinkan pengguna akhir untuk mengenkripsi isi email. Ada berbagai perangkat lunak dan plugin email-client yang memungkinkan pengguna untuk mengenkripsi pesan menggunakan kunci publik Penerima sebelum mengirimnya. Pada intinya, OpenPGP menggunakan skema kriptografi kunci publik di mana setiap alamat email dikaitkan dengan pasangan kunci publik/privat. OpenPGP menyediakan cara bagi pengguna akhir untuk mengenkripsi email tanpa dukungan dari server dan pastikan bahwa hanya penerima yang dituju dapat membacanya. Namun, ada masalah kegunaan dengan OpenPGP-itu mengharuskan pengguna untuk mengatur pasangan kunci publik/privat dan membuat kunci publik tersedia secara luas. Selain itu, melindungi hanya konten email, dan bukan metadata — pihak yang tidak dipercaya masih dapat mengamati siapa yang mengirim email kepada siapa. Kelemahan umum dari skema enkripsi end to end-di mana server tidak memiliki kunci dekripsi-adalah bahwa itu membuat pencarian sisi server hampir mustahil, sehingga berdampak kegunaan.

Demonstrasi sunting

Email ditandatangani dan dienkripsi melalui internet demonstrasi telah menunjukkan bahwa organisasi dapat berkolaborasi secara efektif menggunakan email yang aman. Hambatan sebelumnya untuk adopsi diatasi, termasuk penggunaan jembatan PKI untuk menyediakan infrastruktur kunci publik yang terukur (PKI) dan penggunaan penjaga keamanan jaringan yang memeriksa konten terenkripsi yang lewat dan keluar dari batas jaringan korporat untuk menghindari enkripsi yang digunakan untuk menyembunyikan malware pengenalan dan kebocoran informasi.

Menyiapkan Dan Menggunakan Enkripsi Email sunting

Enkripsi lapisan Transport menggunakan STARTTLS harus disiapkan oleh organisasi Penerima. Ini biasanya mudah; sertifikat yang sah harus diperoleh dan STARTTLS harus diaktifkan pada server email organisasi Penerima. Untuk mencegah organisasi serangan downgrade dapat mengirim domain mereka ke ' STARTTLS daftar kebijakan ' [7]
Sebagian besar klien email berfitur lengkap memberikan dukungan asli untuk email aman S/MIME (penandatanganan digital dan enkripsi pesan menggunakan sertifikat). Opsi enkripsi lainnya termasuk PGP dan GNU Privacy Guard (GnuPG). Perangkat lunak bebas dan komersial (aplikasi desktop, webmail dan add-on) juga tersedia. [8]
Sementara PGP dapat melindungi pesan, itu juga bisa sulit untuk digunakan dengan cara yang benar. Peneliti di Carnegie Mellon University menerbitkan sebuah makalah di 1999 menunjukkan bahwa kebanyakan orang tidak bisa mencari cara untuk menandatangani dan mengenkripsi pesan menggunakan versi PGP saat ini. [9]

Delapan tahun kemudian, kelompok peneliti Carnegie Mellon lain menerbitkan makalah tindak lanjut yang mengatakan bahwa meskipun versi PGP yang lebih baru membuatnya mudah untuk mendekripsi pesan, kebanyakan orang masih berjuang dengan mengenkripsi dan menandatangani pesan, mencari dan memverifikasi kunci enkripsi publik orang lain, dan berbagi kunci mereka sendiri. [10]
Karena enkripsi bisa sulit bagi pengguna, manajer keamanan dan kepatuhan di perusahaan dan lembaga pemerintah mengotomatisasi proses untuk karyawan dan Eksekutif dengan menggunakan peralatan dan layanan enkripsi yang mengotomatisasi enkripsi. Daripada mengandalkan kerjasama sukarela, enkripsi otomatis, berdasarkan kebijakan yang ditetapkan, mengambil keputusan dan proses dari tangan pengguna. Email dirutekan melalui alat Gateway yang telah dikonfigurasi untuk memastikan kepatuhan terhadap kebijakan peraturan dan keamanan. Email yang memerlukannya secara otomatis dienkripsi dan dikirim. [11]
Jika Penerima bekerja di organisasi yang menggunakan alat gerbang enkripsi yang sama, email secara otomatis didekripsi, membuat proses transparan kepada pengguna. Penerima yang tidak berada di belakang gerbang enkripsi kemudian perlu mengambil langkah tambahan, baik pengadaan kunci publik, atau masuk ke portal online untuk mengambil pesan.

Referensi sunting

  1. ^ "Email encryption in transit - Gmail Help". support.google.com. Diakses tanggal 2019-07-02.