Ipfs: Izin

Pada penyelidikan lebih lanjut, saya pikir satu-satunya hal yang hilang adalah kepemilikan gumpalan (mungkin tidak ada) dan izin baca berdasarkan daftar (atau beberapa) yang dikendalikan oleh pemilik (jika tidak tidak ada). Ini dapat dibangun di atas IPFS tanpa memodifikasi fs.

Anda akan lebih baik menggunakan kemampuan sebagai gantinya. Contoh naif: mengenkripsi file dengan beberapa rahasia, dan berbagi rahasia dengan orang-orang yang memiliki "izin baca".

Tepat. topi Lihat e-rights dan Tahoe-LAFS

—
Dikirim dari Kotak Surat

Pada Jum, 4 Sep 2015 jam 16:46, Mourad De Clerck [email protected]
menulis:

Anda akan lebih baik menggunakan kemampuan sebagai gantinya. Contoh naif: mengenkripsi file dengan beberapa rahasia, dan berbagi rahasia dengan orang-orang yang memiliki "izin baca".

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/ipfs/ipfs/issues/86#issuecomment -137755902

Enkripsi untuk mengelola izin adalah ide yang sangat buruk. Ini bekerja dengan baik dalam skenario optimis tetapi tidak bertahan dengan baik dalam kenyataan.

Misalnya, dengan asumsi bahwa file terenkripsi didistribusikan ke beberapa node dan menjangkau seseorang dengan niat jahat, maka mereka dapat berupaya mendekripsi file tersebut. Di dunia yang optimis, mereka gagal, dan semua orang bahagia. Ya!

Di dunia nyata, jika file telah dibuat beberapa waktu lalu, ada kemungkinan bahwa kesalahan dalam algoritma enkripsi telah ditemukan sejak saat itu. Atau, mungkin saja perangkat keras dekripsi khusus yang baru tersedia secara luas. Ini secara drastis akan mengurangi kompleksitas proses dekripsi. Karena tidak ada yang benar-benar memiliki file tersebut, tidak ada cara untuk menarik file yang ada dan menggantinya dengan versi baru yang dienkripsi dengan algoritme baru dan lebih aman. Bahkan jika Anda dapat melakukan sesuatu seperti ini, apa yang memberi tahu Anda bahwa node jahat tidak akan menyimpan versi file sebelumnya.

Pada akhirnya, tidak ada yang dapat mencegah file meninggalkan jaringan dalam hal keamanan dan privasi.

Alih-alih izin file, saya pikir akan lebih bermakna untuk melakukannya pada tingkat simpul. Pada dasarnya, sebuah node harus dapat menolak koneksi dari node lain berdasarkan paradigma daftar putih/daftar hitam. Ini akan memungkinkan orang membuat jaringan IPFS pribadi, sedikit seperti pelacak torrent bit pribadi, untuk berbagi data sensitif sambil menghindari kebocoran ke node jahat.

Mungkin kita bahkan dapat mempertimbangkan daftar hitam node yang didistribusikan secara global, disimpan di IPFS itu sendiri, untuk secara otomatis memblokir node berbahaya yang diketahui. Padahal, saya tidak tahu seberapa berguna ini mengingat identitas simpul dapat dengan mudah dibuat ulang melalui pasangan kunci baru.

Saya juga setuju bahwa enkripsi adalah cara paling mudah untuk melakukan ini.
Skema enkripsi dapat diretas, begitu juga dengan node. Pengguna hanya perlu
untuk menyadari potensi ini ketika mencoba memberikan kontrol akses
untuk gumpalan.
Pada 9 Sep 2015 18:48, "Etienne Maheu" [email protected] menulis:

Enkripsi untuk mengelola izin adalah ide yang sangat buruk. Ini bekerja dengan baik di
skenario optimis tetapi tidak bertahan dengan baik dalam kenyataan.

Misalnya, dengan asumsi bahwa file terenkripsi didistribusikan ke seluruh
beberapa node dan menjangkau seseorang dengan niat jahat, maka mereka bisa
berusaha keras untuk mendekripsi file. Di dunia yang optimis, mereka
gagal, dan semua orang senang. Ya!

Di dunia nyata, jika file telah dibuat beberapa waktu lalu, itu adalah
kemungkinan bahwa cacat dalam algoritma enkripsi telah ditemukan sejak saat itu.
Atau, mungkin saja perangkat keras dekripsi khusus baru menjadi luas
tersedia. Ini akan secara drastis mengurangi kerumitan dekripsi
proses. Karena tidak ada yang benar-benar memiliki file tersebut, tidak ada cara untuk menariknya
file yang ada dan menggantinya dengan versi baru yang dienkripsi dengan a
algoritma baru dan lebih aman. Bahkan jika kamu bisa melakukan sesuatu seperti ini, apa
memberi tahu Anda bahwa node jahat tidak akan menyimpan versi file sebelumnya
omong-omong.

Pada akhirnya, tidak ada yang dapat mencegah file meninggalkan jaringan
ketika datang ke keamanan dan privasi.

Alih-alih izin file, saya pikir akan lebih bermakna untuk melakukannya
pada tingkat simpul. Pada dasarnya, sebuah node harus dapat menolak koneksi
dari node lain berdasarkan paradigma daftar putih/daftar hitam. Ini akan membiarkan
orang membuat jaringan IPFS pribadi, sedikit seperti torrent bit pribadi
pelacak, untuk berbagi data sensitif sambil menghindari bocor ke yang berbahaya
simpul.

Mungkin kita bahkan dapat mempertimbangkan daftar hitam node yang didistribusikan secara global,
disimpan di IPFS itu sendiri, untuk secara otomatis memblokir node berbahaya yang diketahui.
Padahal, saya tidak tahu seberapa berguna ini mempertimbangkan identitas simpul
dapat dengan mudah dibuat ulang melalui pasangan kunci baru.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/ipfs/ipfs/issues/86#issuecomment -138988589.

@ekg Perbedaannya adalah jika ada kesalahan dalam cara mengamankan simpul, atau dalam sistem daftar putih itu sendiri, maka itu dapat diperbarui karena "Anda memegang kendali" semua simpul yang terpengaruh di jaringan Anda. Jika Anda memilih untuk mempercayai sebuah node, maka terserah Anda untuk memastikan bahwa itu aman. Jika muncul cacat, itu tidak berarti Anda membocorkan data, hanya saja Anda harus memperbaikinya secepatnya. Anda tidak dapat melakukan ini jika menyangkut enkripsi dalam sistem file terdistribusi. Jika file menggunakan enkripsi yang rusak, Anda tidak memiliki kesempatan kedua itu.

@kawazoe silakan baca model kemampuan . setiap skema izin tunggal dapat direpresentasikan dalam sistem kapabilitas, jadi ini adalah sistem yang _sangat unggul_. kertas berlimpah.

sebuah node harus dapat menolak koneksi dari node lain berdasarkan paradigma daftar putih/daftar hitam. Ini akan memungkinkan orang membuat jaringan IPFS pribadi, sedikit seperti pelacak torrent bit pribadi, untuk berbagi data sensitif sambil menghindari kebocoran ke node jahat.

ini sudah direncanakan, tetapi ortogonal.

@jbenet Saya tidak mengatakan bahwa kemampuannya buruk. Sangat bagus bahwa Anda berencana untuk menggunakan model ini. Apa yang saya katakan adalah bahwa ada perbedaan khas antara kemampuan Access dan kemampuan Baca (tidak peduli di tingkat mana atau bagaimana penerapannya) dan bahwa mengenkripsi data saja tidak cukup untuk membedakan keduanya.

Memiliki node yang mengontrol node mana yang diizinkan untuk mengambil file tertentu harus menjadi suatu hal. Mengenkripsi file tidak baik dalam beberapa skenario. Beberapa contoh:
Memiliki beberapa layanan media, di mana orang harus membayar untuk mengakses konten. Untuk menghemat bandwidth, menggunakan IPFS akan masuk akal, jika mereka dapat memastikan bahwa hanya mereka yang membayar yang dapat mengakses file, setidaknya melalui node mereka dan node pengguna yang jujur. Jika file dilindungi oleh enkripsi saja, itu hanya akan membutuhkan satu pengguna yang mengekstrak kunci per media, dan bajak laut dapat mencuri konten melalui IPFS. Tanpa enkripsi asinkron, Anda bahkan tidak dapat mengetahui pengguna mana yang mendistribusikan kunci, dan dengan enkripsi asinkron, Anda tidak mendapatkan keuntungan dari IPFS. Harap pertimbangkan kembali ini.

Cara untuk mengimplementasikannya, adalah node yang dimintai file akan menanyakan beberapa otoritas, apakah node yang mencoba mengakses file diizinkan untuk melakukannya, dan bertindak berdasarkan itu. Seharusnya tidak terlalu sulit untuk melakukan itu, dan pasti akan ada pengguna.

@jcgruenhage Anda dapat membuat setiap pengguna jaringan berada di jaringan pribadi yang sama. (lihat https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-284341649 untuk info lebih lanjut tentang jaringan pribadi)

Selain itu, Anda mungkin dapat menerapkan ini sebagai ekstensi bitswap khusus, tetapi kemudian Anda mengalami beberapa masalah aneh, mencoba memiliki konten 'pribadi' yang tidak terenkripsi saat masih terhubung ke jaringan utama. Bagaimana jika seseorang di luar 'grup yang diizinkan' mendapatkan file melalui beberapa cara lain (dan memiliki hash yang sama) dan kemudian sebuah simpul di grup yang diizinkan mengambilnya (mungkin bagian dari beberapa arsip lain yang mereka unduh). Haruskah mereka kemudian menyajikan file ke rekan lain yang memintanya karena berasal dari sumber yang tidak dilindungi?

Fitur jaringan pribadi terlihat menarik, tetapi itu akan memaksa orang untuk memiliki simpul yang sepenuhnya terpisah untuk mengakses konten ini, dan saya ragu itulah yang diinginkan kebanyakan orang. Juga, di sana kami memiliki satu kunci lagi yang perlu dikompromikan, alih-alih otoritas pusat yang memiliki kendali atas siapa yang mendapatkan file tersebut.

Tentang apakah sebuah node harus membagikan file jika mereka mendapatkannya dari tempat lain, bagaimana mereka bisa tahu, bahwa file tersebut memiliki akses terbatas? Saya kira berbagi itu baik-baik saja, karena hal yang saya coba pastikan hanya jika seseorang "mencuri" file, bahwa node server yang telah menyematkan file, dan node dari pengguna yang jujur ​​tidak melakukan unduhan super cepat, karena mereka dapat mengunduhnya dari semua node itu juga, tetapi hanya dari pengguna yang tidak begitu jujur.

@jcgruenhage Saya setuju tentang ketidaknyamanan membutuhkan jaringan pribadi.

Juga, tidak jelas seberapa banyak jaringan pribadi membantu karena setelah mendekripsi data, pengguna yang tidak jujur ​​dapat segera mengunggah data ini ke jaringan publik. Harap perbaiki saya jika ada yang mencegah ini.

Jika jaringan pribadi memiliki maksimal dua node maka node yang jujur ​​akan tahu bahwa node lain membocorkan data secara tidak jujur. Izinkan lebih dari dua node di jaringan pribadi, dan determinisme kebocoran hilang.

Bahkan di jaringan pribadi dua simpul, simpul yang jujur ​​tidak akan segera tahu bahwa datanya bocor. Waktu akan berlalu, dan pada saat itu data mungkin sudah setengah jalan melintasi galaksi.

Solusi yang mungkin adalah menambahkan id simpul terenkripsi / id pelacak selama dekripsi file. Dengan demikian setiap pengguna mendapatkan salinan yang sedikit dimodifikasi dari setiap file yang berisi id pelacak/simpul yang unik untuk mereka. File yang didekripsi akan selalu berbeda dari aslinya, tetapi yang asli akan tetap tidak berubah dan dapat diverifikasi.

Node penjaga yang terkait dengan jaringan pribadi dapat memantau jaringan publik untuk nilai pelacak ini. Dengan cara ini, adalah mungkin untuk mendeteksi asal kebocoran pada waktu yang tepat.

Ini tidak akan mencegah node di satu jaringan pribadi membocorkan data ke jaringan pribadi lain.

Anda tidak dapat mencegah pengguna berbagi file, tetapi Anda harus dapat mencegah mereka menggunakan infrastruktur Anda untuk itu, tetapi saat ini belum ada sistem distribusi file terdistribusi yang melakukan hal ini.

@jcgruenhage hrm ... Itu usecase yang menarik. Akankah masing-masing berpartisipasi?
node menanyakan server tentang setiap blok yang diminta? Atau akankah auth
server mengirimkan daftar besar rekan yang diizinkan dan konten apa mereka
diperbolehkan untuk digunakan?

Pada Jumat, 2 Jun 2017, 09:19 Jan Christian Grünhage [email protected]
menulis:

Anda tidak dapat mencegah pengguna berbagi file, tetapi Anda harus dapat
mencegah mereka menggunakan infrastruktur Anda untuk itu, tetapi saat ini tidak ada
sistem distribusi file terdistribusi yang belum melakukan ini.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/ipfs/ipfs/issues/86#issuecomment-305836646 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ABL4HGtd8flt7agdikQeIrSk59vnTZzvks5sADYlgaJpZM4F3vN7
.

Fitur Jaringan Pribadi dibangun di atas konsep kepercayaan penuh dari rekan-rekan PNet Anda.

Langkah selanjutnya adalah sistem kapabilitas di mana Anda dapat mengizinkan beberapa node mengakses beberapa file. Aktor jahat dalam skema itu hanya dapat membocorkan data yang dia miliki, mengingat node lain yang memiliki kemampuan untuk file yang diberikan berperilaku baik.

@nueverest seperti yang dikatakan @jcgruenhage , begitu pengguna memiliki akses ke file dan dapat mendekripsinya, dia dapat menyalinnya ke stik USB dan menerbitkannya di tempat lain.

Bagi saya yang lebih penting adalah kepemilikan --- saya ingin memastikan bahwa file tersebut dimodifikasi oleh seseorang yang saya percayai. Salah satu cara untuk melakukannya adalah dengan mengenkripsi file dan menggunakan kunci dekripsi sebagai bagian dari nama file --- jadi setelah hash-sum dihitung untuk file yang didekripsi, saya akan tahu bahwa hanya orang yang mengetahui kunci enkripsi yang dapat melakukannya .

Kemungkinan itu bukan cara terbaik, tetapi apakah itu diterapkan di suatu tempat?

File yang diberi nama oleh jalur /ipfs (misalnya, /ipfs/QmSVyMxF5W5NFTJxKWhhdVjqnhhFmsqjFgSrbPovp5bzwF) tidak dapat diubah, jadi ini seharusnya tidak menjadi masalah. File yang diberi nama oleh jalur /ipns/... dapat diubah tetapi ditandatangani oleh pembuatnya (pemilik nama IPNS).

Namun, jika Anda mendapatkan /ipfs/... jalur di luar batas dan ingin menentukan kepengarangan, Anda mungkin perlu menandatangani data (dapat dilakukan dengan, misalnya, gnupg).

Catatan: Kami kemungkinan besar pada akhirnya akan membangun sistem file yang dapat diubah seperti SUNDR. Sistem file itu kemungkinan akan membawa informasi kepengarangan. Kami kemungkinan juga akan mengizinkan metadata arbitrer di masa mendatang (yang secara teori dapat membawa informasi kepengarangan).

@risen @jbenet Bisakah Anda menjelaskan (atau menautkan ke deskripsi) bagaimana model kemampuan dapat digunakan untuk mencegah file yang diizinkan pada node IPFS meninggalkan node itu kecuali ke pemohon yang berwenang? Apakah ada fitur model kemampuan eksplisit di IPFS? Saya telah mencari-cari dokumentasi tentang ini tetapi belum menemukan sesuatu yang eksplisit.

Hai @vdods -- kami membiarkan masalah dalam repo ini terbuka untuk tujuan referensi, tetapi meminta diskusi lanjutan terjadi di https://discuss.ipfs.io/ (yang dipantau secara aktif). Silakan posting di sana -- terima kasih!