Ipfs: أذونات

في مزيد من التحقيق ، أعتقد أن الشيء الوحيد المفقود هو ملكية blob (ربما لا شيء) وقراءة الأذونات بناءً على قائمة (أو عدة) يتحكم فيها المالك (إن لم يكن لا شيء). يمكن بناء هذا فوق IPFS دون تعديل fs الأساسي.

سيكون من الأفضل استخدام القدرات بدلاً من ذلك. مثال ساذج: تشفير الملف ببعض السر ، ومشاركة السر مع الأشخاص الذين لديهم "إذن قراءة".

بالضبط. قبعات. انظر الحقوق الإلكترونية و Tahoe-LAFS

-
مرسل من صندوق البريد

يوم الجمعة 4 سبتمبر 2015 الساعة 4:46 مساءً ، إرسال إشعارات من Mourad De [email protected]
كتب:

سيكون من الأفضل استخدام القدرات بدلاً من ذلك. مثال ساذج: تشفير الملف ببعض السر ، ومشاركة السر مع الأشخاص الذين لديهم "إذن قراءة".

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/ipfs/ipfs/issues/86#issuecomment -137755902

التشفير لإدارة الإذن فكرة سيئة للغاية. إنه يعمل بشكل جيد في السيناريوهات المتفائلة لكنه لا يثبت نفسه جيدًا في الواقع.

على سبيل المثال ، بافتراض أن ملفًا مشفرًا يتم توزيعه عبر عقد متعددة والوصول إلى شخص لديه نوايا خبيثة ، فيمكنهم بذل بعض الجهد لفك تشفير الملف. في عالم متفائل يفشلون والجميع سعداء. بلى!

في العالم الحقيقي ، إذا تم إنشاء الملف منذ فترة ، فمن المحتمل أنه تم العثور على عيب في خوارزمية التشفير منذ ذلك الحين. أو ، من الممكن أن تصبح أجهزة فك التشفير الخاصة الجديدة متاحة على نطاق واسع. هذا من شأنه أن يقلل بشكل كبير من تعقيد عملية فك التشفير. نظرًا لعدم امتلاك أي شخص للملف حقًا ، فلا توجد طريقة لسحب الملف الحالي واستبداله بإصدار جديد مشفر بخوارزمية جديدة وأكثر أمانًا. حتى لو كان بإمكانك فعل شيء كهذا ، فإن ما يخبرك بأن العقدة الخبيثة لن تحتفظ بالإصدار السابق من الملف على أي حال.

في النهاية ، لا شيء يتفوق على منع الملف من مغادرة الشبكة عندما يتعلق الأمر بالأمان والخصوصية.

بدلاً من أذونات الملفات ، أعتقد أنه سيكون من الأفضل القيام بذلك على مستوى العقدة. بشكل أساسي ، يجب أن تكون العقدة قادرة على رفض الاتصالات من العقد الأخرى بناءً على نموذج القائمة البيضاء / القائمة السوداء. سيسمح هذا للأشخاص بإنشاء شبكة IPFS خاصة ، تشبه إلى حد ما متتبعات التورنت الخاصة ، لمشاركة البيانات الحساسة مع تجنب التسرب إلى عقدة ضارة.

ربما يمكننا حتى التفكير في قائمة سوداء موزعة عالميًا للعقد ، مخزنة على IPFS نفسها ، لحظر العقد الضارة المعروفة تلقائيًا. على الرغم من ذلك ، لا أعرف مدى فائدة هذا في التفكير في إمكانية إعادة إنشاء هوية العقدة ببساطة من خلال زوج مفاتيح جديد.

أوافق أيضًا على أن التشفير هو أسهل طريقة للقيام بذلك.
يمكن اختراق أنظمة التشفير ، ولكن يمكن اختراق العقد أيضًا. يحتاج المستخدمون ببساطة
لتكون على دراية بهذه الإمكانات عند محاولة توفير التحكم في الوصول
إلى النقط.
في 9 سبتمبر 2015 ، 6:48 مساءً ، كتب "Etienne Maheu" [email protected] :

التشفير لإدارة الإذن فكرة سيئة للغاية. يعمل بشكل جيد في
سيناريوهات متفائلة لكنها لا تثبت نفسها جيدًا في الواقع.

على سبيل المثال ، بافتراض أن ملفًا مشفرًا يتم توزيعه عبر
عدة عقد وتصل إلى شخص ما بنوايا خبيثة ، عندها يمكنهم ذلك
بذل بعض الجهد في فك تشفير الملف. في عالم متفائل ، هم
تفشل والجميع سعداء. بلى!

في العالم الحقيقي ، إذا تم إنشاء الملف منذ فترة ، فسيكون كذلك
من الممكن أنه تم العثور على خلل في خوارزمية التشفير منذ ذلك الحين.
أو ، من الممكن أن تنتشر أجهزة فك التشفير الخاصة الجديدة على نطاق واسع
متوفرة. هذا من شأنه أن يقلل بشكل كبير من تعقيد فك التشفير
معالجة. نظرًا لعدم امتلاك أي شخص للملف حقًا ، فلا توجد طريقة لسحب ملف
موجود واستبدله بإصدار جديد مشفر بامتداد
خوارزمية جديدة وأكثر أمانًا. حتى لو كان بإمكانك فعل شيء كهذا ، ماذا
يخبرك أن العقدة الضارة لن تحتفظ بالإصدار السابق من الملف
على أي حال.

في النهاية ، لا شيء يتفوق على منع الملف من مغادرة الشبكة
عندما يتعلق الأمر بالأمان والخصوصية.

بدلاً من أذونات الملفات ، أعتقد أنه سيكون أكثر فائدة للقيام بذلك
على مستوى العقدة. في الأساس ، يجب أن تكون العقدة قادرة على رفض الاتصالات
من العقد الأخرى على أساس نموذج القائمة البيضاء / القائمة السوداء. هذا من شأنه أن يسمح
يقوم الأشخاص بإنشاء شبكة IPFS خاصة ، تشبه إلى حد ما ملفات التورنت الخاصة
أجهزة التتبع ، لمشاركة البيانات الحساسة مع تجنب التسريب إلى البرامج الضارة
العقدة.

ربما يمكننا التفكير في وضع قائمة سوداء للعقد موزعة عالميًا ،
المخزنة على IPFS نفسه ، لحظر العقد الضارة المعروفة تلقائيًا.
رغم ذلك ، لا أعرف مدى فائدة هذا في التفكير في هوية العقدة
يمكن إعادة إنشائه ببساطة من خلال زوج مفاتيح جديد.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/ipfs/ipfs/issues/86#issuecomment -138988589.

ekg الاختلاف هو أنه إذا كان هناك خلل في كيفية تأمين العقدة ، أو في نظام القائمة البيضاء نفسه ، فيمكن تحديثه لأنك "تتحكم" في جميع العقد المتأثرة في شبكتك. إذا اخترت الوثوق بالعقدة ، فالأمر متروك لك للتأكد من أنها آمنة. إذا ظهر خطأ ، فهذا لا يعني أنك قمت بتسريب البيانات ، فقط يجب عليك إصلاحها في أسرع وقت ممكن. لا يمكنك القيام بذلك عندما يتعلق الأمر بالتشفير في نظام ملفات موزع. إذا كان الملف يستخدم تشفيرًا معطلًا ، فلن تكون لديك الفرصة الثانية.

kawazoe يرجى قراءة نماذج القدرات . يمكن تمثيل كل مخطط إذن فردي في نظام قدرة ، لذلك فهو نظام _ متفوق تمامًا. تكثر الأوراق.

يجب أن تكون العقدة قادرة على رفض الاتصالات من العقد الأخرى بناءً على نموذج القائمة البيضاء / القائمة السوداء. سيسمح هذا للأشخاص بإنشاء شبكة IPFS خاصة ، تشبه إلى حد ما متتبعات التورنت الخاصة ، لمشاركة البيانات الحساسة مع تجنب التسرب إلى عقدة ضارة.

هذا مخطط بالفعل ، لكن متعامد.

jbenet أنا لا أقول أن القدرات سيئة. إنه لأمر رائع أن تخطط لاستخدام هذا النموذج. ما أقوله هو أن هناك فرقًا مميزًا بين إمكانية الوصول وإمكانية القراءة (بغض النظر عن المستوى أو كيفية تنفيذها) وأن تشفير البيانات وحده لا يكفي للتمييز بين الاثنين.

يجب أن يكون وجود عقدة تتحكم في العقد التي يُسمح لها باسترداد ملف معين شيئًا. لا يفيد تشفير الملفات في بعض السيناريوهات. بعض الأمثلة:
لديك بعض الخدمات الإعلامية ، حيث يتعين على الأشخاص الدفع للوصول إلى المحتوى. للتوفير على النطاق الترددي ، سيكون استخدام IPFS منطقيًا ، إذا كان بإمكانهم التأكد من أن أولئك الذين دفعوا فقط يمكنهم الوصول إلى الملفات ، على الأقل من خلال عقدهم وعقد المستخدمين الشرفاء. إذا كانت الملفات محمية بالتشفير فقط ، فسيتطلب الأمر فقط مستخدمًا واحدًا يستخرج المفتاح لكل وسيط ، ويمكن للقراصنة سرقة المحتوى من خلال IPFS. بدون التشفير غير المتزامن ، لا يمكنك حتى معرفة المستخدمين الذين وزعوا المفتاح ، ومع التشفير غير المتزامن ، لا تحصل على مزايا IPFS. يرجى إعادة النظر في هذا.

طريقة لتنفيذ ذلك ، تتمثل في أن العقدة المطلوبة للملف ستطلب من بعض المصادر ، ما إذا كانت العقدة التي تحاول الوصول إلى الملف مسموحًا لها بالقيام بذلك ، وتتصرف بناءً على ذلك. لا ينبغي أن يكون من الصعب جدًا القيام بذلك أيضًا ، وبالتأكيد سيكون هناك مستخدمون.

jcgruenhage يمكن أن يكون كل مستخدم للشبكة على نفس الشبكة الخاصة. (راجع https://github.com/ipfs/go-ipfs/issues/3397#issuecomment-284341649 لمزيد من المعلومات حول الشبكات الخاصة)

بصرف النظر عن ذلك ، يمكنك تنفيذ هذا كملحق bitswap خاص ، ولكن بعد ذلك تواجه مشكلتين غريبتين ، تحاول الحصول على محتوى "خاص" غير مشفر بينما لا تزال متصلاً بالشبكة الأساسية. ماذا لو حصل شخص ما خارج "المجموعة المسموح بها" على الملف من خلال بعض الوسائل الأخرى (ولديه نفس التجزئة) ثم حصلت عليه عقدة في المجموعة المسموح بها (ربما جزء منه من أرشيف آخر قاموا بتنزيله). هل يجب عليهم بعد ذلك تقديم الملفات إلى أقران آخرين طلبوها لأنها جاءت من مصدر غير محمي؟

تبدو ميزة الشبكة الخاصة مثيرة للاهتمام ، لكنها ستجبر الأشخاص على الحصول على عقدة منفصلة تمامًا للوصول إلى هذا المحتوى ، وأشك في أن هذا هو ما يريده معظم الناس. أيضًا ، لدينا مرة أخرى مفتاح واحد يجب اختراقه ، بدلاً من سلطة مركزية تتحكم في من يحصل على الملف.

حول ما إذا كان يجب على العقدة مشاركة الملف إذا حصلوا عليه من مكان آخر ، كيف يجب أن يعرفوا حتى أن الملف قد قام بتقييد الوصول بعد ذلك؟ أعتقد أن مشاركته جيدة ، لأن الشيء الذي أحاول التأكد منه هو أنه إذا "سرق" شخص ما الملف ، فإن عُقد الخادم التي قامت بتثبيت الملفات وعقد المستخدمين الصادقين لا تقوم بتنزيلاتهم بسرعة فائقة ، لأنه يمكنهم أيضًا تنزيله من كل تلك العقد ، ولكن فقط من هؤلاء المستخدمين غير الشرفاء.

jcgruenhage أوافق على الإزعاج الناتج عن طلب شبكة خاصة.

أيضًا ، ليس من الواضح مقدار المساعدة التي تقدمها الشبكة الخاصة لأنه عند فك تشفير البيانات ، يمكن للمستخدم غير النزيه تحميل هذه البيانات على الفور إلى الشبكة العامة. الرجاء تصحيح لي إذا كان هناك شيء يمنع هذا.

إذا كانت الشبكة الخاصة تحتوي على عقدتين كحد أقصى ، فستعرف العقدة الصادقة أن العقدة الأخرى تقوم بتسريب البيانات بطريقة غير شريفة. السماح بأكثر من عقدتين في الشبكة الخاصة ، وفقدان حتمية التسرب.

حتى في الشبكة الخاصة ذات العقدتين ، لن تعرف العقدة الصادقة على الفور أن البيانات تتسرب. سينقضي الوقت ، وعند هذه النقطة قد تكون البيانات في منتصف الطريق عبر المجرة.

أحد الحلول الممكنة هو إضافة معرف / معرف عقدة مشفر أثناء فك تشفير الملف. وبذلك يحصل كل مستخدم على نسخة معدلة قليلاً من كل ملف يحتوي على معرف التتبع / العقدة الفريد له. ستكون الملفات التي تم فك تشفيرها مختلفة دائمًا عن الأصل ، ولكن سيظل الأصل غير قابل للتغيير ويمكن التحقق منه.

يمكن للعقد الخافرة المتعلقة بالشبكة الخاصة مراقبة الشبكة العامة لقيم التتبع هذه. بهذه الطريقة ، سيكون من الممكن اكتشاف مصدر التسرب في الوقت المناسب.

هذا لن يمنع عقدة على شبكة خاصة واحدة من تسرب البيانات إلى شبكة خاصة أخرى.

لا يمكنك منع المستخدمين من مشاركة الملفات ، ولكن يجب أن تكون قادرًا على منعهم من استخدام البنية التحتية الخاصة بك لذلك ، ولكن لا يوجد حاليًا نظام توزيع ملفات موزع يقوم بذلك حتى الآن.

jcgruenhage hrm ... هذه حالة استخدام مثيرة للاهتمام. من شأنه أن يشارك كل
عقدة تسأل الخادم عن كل كتلة يتم طلبها؟ أو المصادقة
يرسل الخادم قائمة كبيرة من الأقران المسموح لهم والمحتوى الذي هم
يسمح باستخدام؟

في الجمعة ، 2 يونيو 2017 ، 09:19 يناير Christian Grünhage [email protected]
كتب:

لا يمكنك منع المستخدمين من مشاركة الملفات ، ولكن يجب أن تكون قادرًا على ذلك
منعهم من استخدام البنية التحتية الخاصة بك لذلك ، ولكن لا يوجد حاليًا
نظام توزيع الملفات الموزعة الذي يقوم بذلك حتى الآن.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/ipfs/ipfs/issues/86#issuecomment-305836646 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/ABL4HGtd8flt7agdikQeIrSk59vnTZzvks5sADYlgaJpZM4F3vN7
.

تم بناء ميزة الشبكات الخاصة على مفهوم الثقة الكاملة لأقرانك في PNet.

قد تكون الخطوة التالية هي نظام القدرة حيث يمكنك السماح لبعض العقد بالوصول إلى بعض الملفات. سيكون الفاعل الضار في هذا المخطط قادرًا على تسريب البيانات التي لديه القدرة عليها فقط ، بالنظر إلى أن العقد الأخرى التي لديها القدرة على ملف معين تعمل بشكل جيد.

nueverest كما قال jcgruenhage ، بمجرد أن يتمكن المستخدم من الوصول إلى ملف ويمكنه فك تشفيره ، يمكنه نسخه إلى محرك أقراص USB ونشره في مكان آخر.

بالنسبة لي الأهم هو الملكية --- أريد التأكد من أن الملف قد تم تعديله من قبل شخص أثق به. تتمثل إحدى طرق القيام بذلك في تشفير الملف واستخدام مفتاح فك التشفير كجزء من اسم الملف - لذلك بمجرد حساب التجزئة للملف الذي تم فك تشفيره ، سأعرف أن الشخص الوحيد الذي يعرف مفتاح التشفير يمكنه فعل ذلك .

من المحتمل أنها ليست الطريقة الأفضل ، لكن هل يتم تنفيذها في مكان ما؟

الملفات التي تم تسميتها بواسطة مسارات /ipfs (على سبيل المثال ، / ipfs / QmSVyMxF5W5NFTJxKWhhdVjqnhhFmsqjFgSrbPovp5bzwF) غير قابلة للتغيير لذا لا ينبغي أن تكون هذه مشكلة. الملفات التي تم تسميتها بواسطة مسار /ipns/... قابلة للتغيير ولكنها موقعة من قبل المؤلف (مالك اسم IPNS).

ومع ذلك ، إذا كنت تحصل على مسارات /ipfs/... خارج النطاق وتريد تحديد التأليف ، فستحتاج على الأرجح إلى توقيع البيانات (يمكن القيام بذلك باستخدام ، على سبيل المثال ، gnupg).

ملاحظة: من المحتمل أن نبني في النهاية نظام ملفات قابل للتغيير مثل SUNDR. من المحتمل أن يحمل نظام الملفات هذا معلومات التأليف. من المحتمل أيضًا أن نسمح بالبيانات الوصفية التعسفية في المستقبل (يمكن أن يحمل ذلك ، من الناحية النظرية ، معلومات التأليف).

risenjbenet هل يمكنك وصف (أو الارتباط بالوصف) كيف يمكن استخدام نماذج الإمكانيات لمنع الملفات المصرح بها على عقدة IPFS من مغادرة تلك العقدة باستثناء طالب معتمد؟ هل توجد ميزة نموذج قدرة صريحة في IPFS؟ لقد بحثت في جميع أنحاء عن وثائق حول هذا ولكن لم أجد أي شيء واضح.

مرحبًا @ vdods - نترك المشكلات في هذا الريبو مفتوحة لأغراض مرجعية ، ولكن نطلب إجراء مناقشة المتابعة في https://discuss.ipfs.io/ (والتي تتم مراقبتها بنشاط). الرجاء النشر هناك - شكرا لك!