Bagaimana seseorang bisa merancang email yang aman dan merusak diri sendiri?

Seperti yang diketahui sebagian besar dari Anda, email sangat tidak aman. Bahkan dengan koneksi aman SSL antara klien dan server yang mengirim email, pesan itu sendiri akan berbentuk teks biasa saat berpindah ke node di Internet, sehingga rentan terhadap penyadapan.

Pertimbangan lainnya adalah pengirim mungkin tidak ingin pesannya dapat dibaca - bahkan oleh penerima yang dituju - setelah beberapa waktu atau setelah dibaca satu kali. Ada beberapa alasan untuk hal ini; misalnya, pesan tersebut mungkin berisi informasi sensitif yang dapat diminta melalui panggilan pengadilan.

Solusinya (yang paling umum, menurut saya) adalah mengirimkan pesan ke pihak ketiga yang tepercaya, dan tautan ke pesan tersebut ke penerima, yang kemudian membaca pesan ini dari pihak ketiga. Atau pengirim dapat mengirimkan pesan terenkripsi (menggunakan enkripsi simetris) ke penerima dan mengirimkan kuncinya ke pihak ke-3.

Apa pun yang terjadi, ada masalah mendasar dalam pendekatan ini: jika pihak ketiga ini disusupi, semua upaya Anda akan sia-sia. Untuk contoh nyata insiden seperti ini, lihat bencana yang melibatkan Crypto AG yang berkolusi dengan NSA

Solusi lain yang saya lihat adalah Vanish, yang mengenkripsi pesan, membagi kunci menjadi beberapa bagian dan " menyimpan" potongan-potongan itu dalam DHT (yaitu Vuze DHT). Nilai-nilai ini dapat diakses dengan mudah dan andal hanya dengan mencari hash (hash dikirim bersama pesan). Setelah 8 jam, nilai-nilai ini hilang, dan bahkan penerima yang dituju tidak akan dapat membaca pesan tersebut. Dengan jutaan node, tidak ada satu pun titik kegagalan. Namun hal ini juga dipatahkan dengan melakukan serangan Sybil pada DHT (lihat halaman web Vanish untuk informasi lebih lanjut).

Jadi apakah ada yang punya ide tentang cara mencapai hal ini?

EDIT: Sepertinya saya tidak menjelaskannya dengan jelas. Perhatian utamanya bukanlah penerima yang sengaja menyimpan pesannya (saya tahu hal ini tidak mungkin dikendalikan), namun pesan tersebut tersedia di suatu tempat.

Misalnya, dalam bencana Enron, pengadilan memanggil mereka untuk meminta semua email di server mereka. Jika pesan telah dienkripsi dan kuncinya hilang selamanya, tidak ada gunanya bagi mereka jika memiliki pesan terenkripsi dan tidak memiliki kunci.


encryption security cryptography self-destruction
person quantumSoup    schedule 30.06.2010    source sumber
comment
Bagaimana jika selagi mereka bisa membacanya, mereka hanya menyalin dan menempelkan pesan tersebut? Atau ambil tangkapan layar? Atau menggunakan kamera digital untuk mengambil gambar layarnya?   -  person Christopher Tarquini    schedule 30.06.2010
comment
@ Chris-T Saya tidak terlalu khawatir jika penerima sengaja menyalin pesan tersebut, melainkan dia rajin menghapusnya.   -  person quantumSoup    schedule 30.06.2010
comment
Kedengarannya seperti pesan yang tidak tercatat. Pesan dienkripsi, dan selama percakapan, penerima dapat memverifikasi identitas pengirim, namun nantinya tidak bisa. Penting untuk diperhatikan bahwa penerima dapat menyimpan salinan permanen pesan dan identitas pengirim. Mereka tidak bisa membuktikan nanti siapa pengirimnya.   -  person Matthew Flaschen    schedule 30.06.2010
comment
Bagaimana dengan pihak keempat yang benar-benar sangat tepercaya? ;) Masalah Anda adalah pihak tepercaya dapat dikompromikan. Itu tidak terdengar seperti masalah teknologi dengan solusi teknologi.   -  person Paul Richter    schedule 30.06.2010
comment
@Paul Richter: Vanish berhasil mencapai (sebagian) hal itu, dengan membagi kunci menjadi beberapa bagian dan menyimpannya di node anonim yang tersebar di seluruh dunia. Node-node ini juga tidak tahu bahwa mereka menyimpan potongan-potongan kunci; karena dibangun di atas infrastruktur yang sudah ada (bittorrent DHT).   -  person quantumSoup    schedule 30.06.2010
comment
Jika pesan telah dienkripsi dan kuncinya hilang selamanya, tidak ada gunanya bagi mereka jika memiliki pesan terenkripsi dan tidak memiliki kunci. Kedengarannya seperti penyitaan bukti. Bisnis sering kali diharuskan menyimpan dokumen hanya karena alasan ini. Pengadilan kemungkinan besar tidak akan memberikan penilaian positif terhadap keputusan tersebut. Kami tidak bisa berbuat apa-apa. Algoritme enkripsi kami secara otomatis menghancurkan kuncinya.   -  person Matthew Flaschen    schedule 30.06.2010
comment
@Matthew Saya pikir ini hanya memenuhi syarat sebagai spoasi jika dokumen-dokumen ini relevan dengan proses hukum yang sedang berlangsung. Saya percaya komunikasi email harus bersifat pribadi, dan teknologi saat ini jelas menawarkan sedikit privasi.   -  person quantumSoup    schedule 30.06.2010
comment
Saya masih tidak dapat membayangkan pengadilan akan menyetujui permintaan maaf, Yang Mulia, semua email kami secara otomatis dimusnahkan setelah dibaca sebagai pembelaan.   -  person Dean Harding    schedule 30.06.2010
comment
Saya bukan ahli hukum, jadi saya tidak bisa mengatakan dengan pasti apa dampak dari tindakan tersebut. Tapi saya hanya menyebutkannya sebagai contoh; ini bisa memiliki kegunaan lain.   -  person quantumSoup    schedule 30.06.2010
comment
@Aircule, bisnis sering kali diharuskan menyimpan dokumen untuk mempersiapkan kemungkinan litigasi. Lihat skocpa.com/document_retention_recommendation.htm, khususnya Tidak ada batasan penyimpanan dokumen jika terjadi penipuan aktivitas telah terjadi. Jika Enron tidak melakukan aktivitas penipuan, saya tidak tahu siapa yang melakukannya.   -  person Matthew Flaschen    schedule 30.06.2010
comment
@Dean 'codeka' Harding: Saya tidak mengerti alasannya. Setiap badan usaha mempunyai hak untuk melindungi informasi rahasia dagang. Ada jenis dokumen tertentu yang wajib disimpan menurut undang-undang - seperti pembukuan misalnya, namun selebihnya terserah pada badan usaha. Dengan cara yang sama seperti entitas bisnis yang menerapkan aturan untuk merobek-robek semua dokumen kertas jika tidak diperlukan, maka hal ini dapat dilakukan dengan menggunakan 'surat yang dapat merusak dirinya sendiri'.   -  person sharptooth    schedule 30.06.2010
comment
@sharp, ada perbedaan besar antara menjaga rahasia dagang dari pesaing dan menghancurkan email karena kemungkinan panggilan pengadilan di masa depan.   -  person Matthew Flaschen    schedule 30.06.2010
comment
@Matthew Flaschen: Kita perlu membuktikan bahwa email dihancurkan untuk melindungi secara khusus terhadap kemungkinan panggilan pengadilan, bukan?   -  person sharptooth    schedule 30.06.2010
comment
@Matthew: Saya tahu ada dokumen yang harus disimpan oleh bisnis, tapi menurut saya sebagian besar korespondensi email termasuk dalam kategori itu. Faktanya, email Enron tersedia secara luas dan sering digunakan sebagai kumpulan data email sebenarnya. Menurut saya, tidak banyak dokumen yang secara hukum wajib mereka simpan di dalamnya.   -  person quantumSoup    schedule 30.06.2010
comment
@Matthew Flaschen: Juga, frasa Tidak ada batasan penyimpanan dokumen ketika aktivitas penipuan telah terjadi. jelas mengacu pada kasus ketika ada penyelidikan resmi - pihak tersebut tidak diperbolehkan menghancurkan dokumen apa pun berapa pun usianya selama penyelidikan sedang berlangsung, tetapi hal ini tidak berlaku sebelum aktivitas tersebut dicurigai atau ditemukan.   -  person sharptooth    schedule 30.06.2010
comment
@Aircule: di Australia (dan saya berasumsi banyak yurisdiksi) dokumen elektronik (misalnya email) diberikan pertimbangan yang sama seperti dokumen kertas/hard copy. Anda dapat mengatakan bahwa email pribadi tidak termasuk dalam kategori tersebut, namun kemudian: a) Anda tidak boleh menggunakan alamat email bisnis untuk mengirim email pribadi dan b) itu tidak akan membantu orang-orang Enron di mana banyak dari email tersebut < saya>sedang berhubungan dengan bisnis dan sedang mendiskusikan aktivitas penipuan. Tentu saja, jika Anda melakukan apa yang dilakukan Enron, maka menghancurkan barang bukti mungkin bukanlah kekhawatiran Anda!   -  person Dean Harding    schedule 30.06.2010

Jawaban (8)


arrow_upward
1
arrow_downward

(Penafian: Saya tidak membaca detail tentang serangan Vanish atau Sybil, yang mungkin mirip dengan yang ada di bawah)

Pertama-tama: Pesan email umumnya berukuran cukup kecil, khususnya. dibandingkan dengan video youtube berukuran 50 MB, Anda dapat mengunduh 10 kali sehari atau lebih. Berdasarkan hal ini saya mendasarkan asumsi bahwa penyimpanan dan bandwidth tidak menjadi perhatian nyata di sini.

Enkripsi, dalam pengertian umum, memasukkan bagian ke dalam sistem Anda yang sulit dipahami, dan karenanya sulit diverifikasi. (bayangkan keajaiban openssl yang biasa dilakukan semua orang, namun 99% orang benar-benar memahaminya; jika beberapa langkah X pada HOWTO akan mengatakan "sekarang buka situs X dan unggah *.cer *.pem dan *.csr" untuk memverifikasi langkah-langkahnya 1 hingga X-1, saya kira 1 dari 10 orang akan melakukannya)

Menggabungkan dua pengamatan, saran saya untuk sistem yang aman(*) dan dapat dimengerti:

Katakanlah Anda memiliki pesan M sebesar 10 kb. Ambil N kali 10 kb dari /dev/(u)random, mungkin dari sumber acak berbasis perangkat keras, sebut saja K(0) hingga K(N-1). Gunakan operasi xor sederhana untuk menghitung

K(N) = M^K(0)^K(1)^...^K(N-1)

sekarang, menurut definisi

M = K(0)^K(1)^...^K(N)

yaitu untuk memahami pesan Anda memerlukan semua K. Simpan K dengan N pihak yang berbeda (kurang lebih tepercaya), menggunakan protokol apa pun yang Anda suka, dengan nama 256 bit acak.

Untuk mengirim pesan, kirim N link ke K.

Untuk menghancurkan sebuah pesan, pastikan setidaknya satu K dihapus.
(*) dalam hal keamanan, sistem akan sama amannya dengan pihak teraman yang menghosting K.

Jangan mengambil N yang tetap, jangan memiliki jumlah K yang tetap pada satu node per pesan (yaitu menempatkan 0-10 K dari satu pesan pada node yang sama) untuk membuat serangan brute force menjadi sulit, bahkan bagi mereka yang memiliki akses ke semua node yang menyimpan kunci.

Catatan: ini tentu saja memerlukan beberapa perangkat lunak tambahan, seperti halnya solusi apa pun, tetapi kompleksitas plugin/alat yang diperlukan minimal.

person mvds    schedule 17.07.2010
comment
Hal ini serupa dengan apa yang dilakukan Vanish; kecuali Anda dapat mengubah jumlah bagian penting yang Anda perlukan untuk memulihkan pesan, dan bagian penting ini didistribusikan ke jutaan node. - person quantumSoup; 17.07.2010

arrow_upward
1
arrow_downward

Bagian penghancuran diri sangat sulit, karena pengguna dapat mengambil tangkapan layar dan menyimpan tangkapan layar tidak terenkripsi di disknya, dll. Jadi menurut saya Anda tidak memiliki kesempatan untuk menerapkannya (akan selalu ada jalan, bahkan jika Anda menautkan ke halaman eksternal). Namun Anda dapat meminta penerima untuk menghapusnya setelahnya.

Enkripsi di sisi lain tidak menjadi masalah sama sekali. Saya tidak akan mengandalkan TLS karena meskipun pengirim dan klien menggunakannya, mungkin ada email lain yang tidak bergantung dan mereka mungkin menyimpan pesan sebagai teks biasa. Jadi, cara terbaik adalah dengan mengenkripsinya secara eksplisit.

Misalnya saya menggunakan GnuPG untuk (hampir) semua email yang saya tulis, yang didasarkan pada beberapa metode enkripsi asimetris. Di sini saya tahu bahwa hanya mereka yang telah saya berikan izin secara eksplisit yang dapat membaca email, dan karena ada plug-in yang tersedia untuk hampir semua MUA populer, saya juga cukup memudahkan penerima untuk membaca email. (Jadi, tidak ada yang perlu mengenkripsi email secara manual dan mungkin lupa menghapus pesan tidak terenkripsi dari disk...). Dan dimungkinkan juga untuk mencabut kuncinya, misalnya jika seseorang telah mencuri kunci pribadi Anda (yang biasanya tetap dienkripsi).

Menurut pendapat saya, GnuPG (atau alternatifnya S/MIME) harus digunakan setiap saat, karena hal itu juga akan membantu mempersulit pengiriman spam. Tapi itu mungkin hanya salah satu mimpi konyolku;)

person tux21b    schedule 19.07.2010

arrow_upward
1
arrow_downward

Ada begitu banyak cara berbeda untuk melakukannya yang semuanya memiliki sisi baik dan buruknya, Anda hanya perlu memilih salah satu yang tepat untuk skenario Anda. Saya pikir cara terbaik untuk melakukannya sama dengan solusi 'paling umum' Anda. Pihak ketiga yang tepercaya seharusnya adalah Anda - Anda membuat situs web sendiri, dengan otentikasi Anda sendiri yang digunakan. Maka Anda tidak perlu memberikan kunci hipotetis Anda kepada siapa pun.

Anda dapat menggunakan metode sertifikasi dua arah dengan membuat perangkat lunak klien Anda sendiri yang dapat membaca email, dan pengguna memiliki sertifikatnya sendiri. Lebih baik aman daripada menyesal!

person Joel Kennedy    schedule 19.07.2010

arrow_upward
0
arrow_downward

Jika penerima mengetahui bahwa pesan tersebut nantinya mungkin tidak dapat dibaca dan mereka menganggap pesan tersebut berharga, niat mereka adalah untuk menyimpannya, sehingga mereka akan mencoba untuk menggagalkan perlindungan tersebut.

Begitu seseorang melihat pesan yang tidak terenkripsi - artinya dalam bentuk apa pun yang dapat dipahami - baik sebagai teks atau gambar di layar - mereka dapat menyimpannya dan melakukan apa pun yang mereka inginkan. Semua tindakan dengan kunci dan sebagainya hanya membuat penanganan pesan menjadi tidak nyaman, tetapi tidak mencegah ekstraksi teks.

Salah satu caranya adalah dengan menggunakan perangkat keras yang dapat menghancurkan dirinya sendiri seperti dalam Mission Impossible - perangkat keras tersebut akan menampilkan pesan dan kemudian menghancurkannya, namun seperti yang Anda lihat, hal ini juga merepotkan - penerima harus memahami pesan tersebut dengan melihatnya. hanya sekali yang tidak selalu memungkinkan.

Jadi mengingat fakta bahwa penerima mungkin tertarik untuk menumbangkan perlindungan dan perlindungan dapat ditumbangkan, gagasan tersebut kemungkinan besar tidak akan berfungsi sebagaimana mestinya tetapi pasti akan membuat penanganan pesan menjadi kurang nyaman.

person sharptooth    schedule 30.06.2010
comment
Sekali lagi, saya tidak terlalu khawatir jika penerima dengan sengaja menyalin pesan tersebut, namun dia memiliki ketekunan untuk menghapusnya. - person quantumSoup; 30.06.2010
comment
Itu tidak akan berhasil – begitu mereka memiliki sesuatu yang mereka anggap menarik, mereka akan menyimpannya. Jika mereka melihat bahwa informasi tersebut sangat berharga, mereka akan berusaha keras untuk mem-backup pesan tersebut agar dapat dibaca nanti. Sama seperti pencadangan biasa - Anda merasa ada sesuatu yang berharga dan Anda membuat cadangan sebelum hilang. - person sharptooth; 30.06.2010
comment
Saya yakin Anda salah mengartikan maksud si penanya dan maksud pertanyaannya. - person Justin L.; 30.06.2010
comment
Keamanan selalu ada harganya. Namun hal ini tidak seharusnya membuat hidup penerimanya menjadi lebih sulit; klien khusus dapat membuka dan membuat pesan secara normal. Satu-satunya kerumitan adalah menginstal ini. Seringkali email yang kembali menghantui Anda belum tentu sengaja disimpan sejak awal. Memiliki ini hanya akan memastikan pesan-pesan ini tidak dapat dibaca tanpa upaya dari penerima. - person quantumSoup; 30.06.2010

arrow_upward
0
arrow_downward

Jika format HTML digunakan, Anda dapat memiliki aset referensi pesan yang dapat Anda hapus di kemudian hari. Jika pesan dibuka di kemudian hari, pengguna akan melihat tautan rusak..

person Don    schedule 13.07.2010
comment
Hal ini tidak dapat diterima karena memerlukan pihak ketiga tepercaya yang menyimpan aset tersebut. - person quantumSoup; 13.07.2010
comment
Setiap jalan adalah pihak ketiga atau milik Anda dan 99,9% dari pihak ketiga akan menyimpan aset untuk jangka waktu yang lama. Dengan menggunakan ide HTML Anda dapat: membagi email menjadi beberapa segmen, menjadikan setiap segmen sebagai gambar, mengenkripsi setiap gambar, berbagi kunci dengan penerima, menyimpan gambar di berbagai situs pihak ketiga. Atau Anda dapat menjalankan mesin virtual yang memiliki gambar beku ketika Anda perlu mengirimkan jenis komunikasi ini dan mengembalikannya ke keadaan beku saat dimatikan, tidak ada data yang disimpan. - person Don; 14.07.2010

arrow_upward
0
arrow_downward

Jika lingkungan Anda memungkinkan, Anda dapat menggunakan lingkungan boot tepercaya untuk memastikan bahwa boot tepercaya loader telah digunakan untuk mem-boot kernel tepercaya, yang dapat memverifikasi bahwa klien email tepercaya digunakan untuk menerima email sebelum mengirimkannya. Lihat pengesahan jarak jauh.

Klien email bertanggung jawab untuk menghapus email secara bertanggung jawab dan tepat waktu -- mungkin hanya mengandalkan penyimpanan dalam memori dan meminta memori yang tidak dapat ditukar ke disk.

Tentu saja, bug dapat terjadi dalam program, namun mekanisme ini dapat memastikan tidak ada jalur yang disengaja untuk menyimpan email.

person sarnold    schedule 19.07.2010

arrow_upward
0
arrow_downward

Masalahnya, seperti yang Anda gambarkan, terdengar sangat mirip dengan masalah yang dibahas oleh Vanish, dan dibahas panjang lebar dalam makalah mereka. Seperti yang Anda ketahui, implementasi pertama mereka ditemukan memiliki kelemahan, namun tampaknya ini merupakan kelemahan implementasi daripada kelemahan mendasar, dan oleh karena itu mungkin dapat diperbaiki.

Vanish juga cukup terkenal sehingga merupakan target serangan yang jelas, yang berarti kelemahan di dalamnya memiliki peluang besar untuk ditemukan, dipublikasikan, dan diperbaiki.

Oleh karena itu, pilihan terbaik Anda mungkin adalah menunggu Vanish versi 2. Dengan perangkat lunak keamanan, meluncurkan perangkat lunak Anda sendiri hampir tidak pernah merupakan ide yang baik, dan mendapatkan sesuatu dari kelompok keamanan akademis yang mapan jauh lebih aman.

person Norman Gray    schedule 19.07.2010

arrow_upward
0
arrow_downward

IMO, solusi paling praktis untuk situasi ini adalah menggunakan klien IM Pidgin dengan Off-the-Record (tanpa logging) dan pidgin-encrypt (enkripsi asimetris ujung ke ujung) secara bersamaan. Pesan tersebut akan dimusnahkan segera setelah jendela obrolan ditutup, dan dalam keadaan darurat, Anda cukup mencabut komputer untuk menutup jendela obrolan.

person Lie Ryan    schedule 11.04.2012