لماذا لا تكفي براهين المعرفة الصفرية وحدها لحماية خصوصية المستخدم

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

هذا الوعد حقيقي، لكنه أضيق مما يبدو.

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

هذه المقالة مقتبسة من عرض قدم إلى NGI TrustChain في سبتمبر 2024. الفكرة الأساسية بسيطة: براهين المعرفة الصفرية لبنة مهمة للمشاركة المدنية الخاصة، لكن خصوصية المستخدم خاصية تخص النظام بأكمله.

لماذا تدخل الهوية إلى المنصات المدنية؟

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

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

هناك طرق عدة لذلك، ولكل منها تنازلات:

الأنظمة البيومترية قد تقدم التفرد، لكنها تخلق مخاطر خطيرة على الخصوصية والسلامة.
أنظمة الرسم الاجتماعي قد تكون مفيدة في بعض السياقات، لكنها صعبة التوسع وغالبا لا تقدم ضمانات خصوصية قوية.
نماذج web of trust الهجينة قد تنجح في مجتمعات معينة، لكنها عادة تقدم تفردا أضعف.
أوراق الاعتماد الحكومية أو المؤسسية قد تقدم ضمانات أقوى، لكنها يجب ألا تتحول إلى طبقة مراقبة.

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

ما الذي تجيده براهين المعرفة الصفرية؟

في تدفق مبسط لأوراق الاعتماد توجد ثلاث جهات:

المصدر يؤكد شيئا عن شخص ما ويصدر ورقة اعتماد.
الحامل يخزن ورقة الاعتماد ويقرر متى يستخدمها.
المتحقق يفحص برهانا مشتقا من ورقة الاعتماد.

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

توجد عدة مسارات تقنية تدعم هذا النمط. أوراق اعتماد BBS+ تسمح بالكشف الانتقائي وبراهين غير قابلة للربط. مسارات أخرى تستخدم أوراق اعتماد merkelized و ZK-SNARKs لجعل الصيغ القابلة للربط أكثر محافظة على الخصوصية. وقد تجعل zkVM العامة إثبات حقائق عن أوراق اعتماد أمنية موجودة أسهل في المستقبل.

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

هذا يحل مشكلة مهمة، لكنه لا يحل كل مشكلات الخصوصية.

نموذج التهديد: الحامل أولا

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

يتطلب ذلك نموذجا للتهديد أشد من النموذج الشائع في معظم المنصات الاجتماعية:

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

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

بقية جبل الخصوصية الجليدي

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

الإفصاح الزائد

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

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

البيانات الوصفية للشبكة

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

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

ملفات تعريف الارتباط ووسطاء البيانات

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

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

البريد والهاتف واسترجاع الحساب

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

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

المعرفات الدائمة

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

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

الارتباط الزمني

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

ينبغي للمصممين التعامل مع الطوابع الزمنية كبيانات حساسة. التجميع، والإرسال المؤجل، وتقليل السجلات، وفصل المصادقة عن عرض البرهان، كلها تقلل خطر الارتباط.

المحافظ والأجهزة وسلسلة التوريد

قد يكون البرهان سليما تشفيريا، لكن المحفظة أو العميل قد يسرب بيانات حساسة. محفظة مغلقة قد ترسل telemetry. SDK مخترق قد يكشف سمات. واجهة خبيثة قد تطلب أكثر مما يفهمه المستخدم.

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

الاستدلال السلوكي

يمكن للتعلم الآلي استنتاج الهوية من أنماط تبدو غير مهمة وحدها: أسلوب الكتابة، وأوقات النشاط، وسلوك الجهاز، وأنماط الموقع، وتاريخ التفاعل كلها قد تضيق مجموعة المجهولية.

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

بنية أفضل لبراهين مجهولة بشكل موثوق

ينبغي تصميم تدفق أوراق الاعتماد الحافظ للخصوصية على افتراض أن المتحقق يريد معرفة أكثر مما ينبغي.

كحد أدنى، على منصة مدنية تستخدم براهين المعرفة الصفرية أن تراعي المبادئ التالية:

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

الهدف ليس براهين مجهولة فقط. الهدف مجهولية موثوقة: نظام يستطيع فيه المستخدمون والمدققون والمجتمع المدني فحص ما إذا كانت وعود الخصوصية تطابق السلوك الفعلي للمنصة.

تحديات مفتوحة

ما زال هناك عمل صعب.

أولا، تجربة المستخدم ليست جيدة بما يكفي. معظم الناس لا يستطيعون التفكير في schemas أوراق الاعتماد، أو الكشف الانتقائي، أو طلبات البرهان، أو عدم قابلية ربط المصدر، أو هجمات الارتباط. المنتج الآمن يجب أن يشرح خصائص الخصوصية من دون مطالبة المستخدمين بأن يصبحوا خبراء تشفير.

ثانيا، منظومة أوراق الاعتماد مجزأة. BBS+ و SD-JWT ورخص القيادة المحمولة وشرائح الجوازات وأوراق الاعتماد merkelized وبراهين zkVM كلها تقدم تنازلات مختلفة. تحتاج المنصات المدنية إلى قابلية تشغيل بيني من دون الهبوط إلى أضعف قاسم مشترك للخصوصية.

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

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

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

الخلاصة

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

لكن البراهين ليست نظام الخصوصية كله. يستطيع المتحقق مهاجمة الطبقات المحيطة: السمات، والبيانات الوصفية، وملفات تعريف الارتباط، والبريد، والهاتف، والمعرفات الدائمة، والتوقيت، والمحافظ، والأجهزة، وأنماط السلوك.

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

الدرس العملي واضح: استخدموا المعرفة الصفرية، لكن لا تتوقفوا عندها.