مخططات توقيع المجموعة مع إمكانية التتبع الموزع (أو كيفية فتح توقيع إلى حد ما)

الصورة من قبل آن لور Delva

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

تسمح توقيعات المجموعة ، التي قدمها Chaum و Van Heyst ، لأحد أعضاء المجموعة بالتوقيع بشكل مجهول نيابة عن المجموعة ، مع إتاحة إمكانية تتبع هوية الموقّع في الحالات الخاصة. بمعنى أنه يمكن للمشاركين في المجموعة التحقق باستخدام مفاتيح التحقق من أن التوقيع تم إنشاؤه بالفعل من قبل شخص ما في المجموعة ، لكنهم لا يستطيعون تحديد هوية من. في حالة وجود خلافات أو سوء سلوك ، تستخدم سلطة التتبع مفتاح التتبع الخاص بها لتتبع الموقِّع.

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

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

مجموعة التواقيع مع التتبع الموزعة في اللولب

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

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

يمكننا القيام بذلك باستخدام توقيعات المجموعة ذات التتبع الموزع ، من خلال جعل كل عقدة شبكة تعمل كسلطة إنصاف وتتطلب عددًا من السلطات لفتح وتتبع التوقيعات.

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

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

من تدفقنا نستنتج متطلبات الأمان التي نسعى إليها:

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

المتطلبات الهامة الأخرى هي: دعم التغيير الديناميكي للموقّعين والمتتبعين ، ولا تتطلب الإعداد الموثوق.

مخطط توقيع المرشح

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

في ورقة كتبها Blomer et. al ، "تواقيع المجموعة القصيرة ذات التتبع الموزع" ، تم توسيع مخطط BBS لدعم التتبع الموزع. يتم تحقيق ذلك بالطريقة التالية. في مخطط BBS ، جزء من التوقيع هو تشفير (جزء من) المفتاح السري ، وفتح مبالغ لفك تشفير هذا النص المشفر. في الورقة التي كتبها Blomer يغيرون التشفير إلى تشفير العتبة. يتكون فتح التوقيع من عمليتين ، الأولى تنتج حصة مفتوحة من التوقيع ، والثانية تجمع عددًا أدنى من المشاركات لفك تشفير مفتاح الموقِّع. التعديل الآخر الذي قاموا به هو إضافة عنصر إضافي إلى المفتاح السري والذي لا يعرفه سوى المستخدم وليس سلطات الإنصاف. هذا يضمن أن سلطات الإنصاف لا تستطيع التوقيع نيابة عن الأعضاء الآخرين.

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

حجم التوقيع

يبلغ طول نظام توقيع مجموعة BBS وفقًا للمعايير التي اقترحها المؤلفون 1،533 بت. هذا مماثل لحجم توقيع RSA ، الذي يبلغ طوله 1024 أو 2048 بت للتوقيعات ذات الأمان المشابه. لا تؤدي إضافة التتبع الموزع إلى جعل التوقيع أطول ، لكن التعقيد يتطلب أن يتم حساب الاستيفاء متعدد الحدود من أجل الجمع بين المشاركات.

بالنسبة لإثبات المعرفة الصفري للمعرفة ، فإن هذا الحجم كبير نسبياً وهو مكلف لحسابه. بالنسبة للمعلمات المقترحة في الورقة ، يبلغ طولها 3،520 بت ، وهو ما يصل إلى طول توقيع يبلغ إجماليه 0553 بت.

حجم المشاركات التوقيع 340 بت لكل سهم.

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

* قراءة الأوراق البيضاء الأجرام السماوية: https://www.orbs.com/white-papers

انضم إلى مجتمع الأجرام السماوية:

  • برقية: https://t.me/orbs_network
  • تويتر: https://twitter.com/orbs_network
  • Reddit: https://www.reddit.com/r/ORBS_Network/
  • جيثب: https://github.com/orbs-network