ليس سرا أن إحدى الأدوات المساعدة شائعة الاستخدام، والتي بدونها تكون حماية البيانات في الشبكات المفتوحة مستحيلة، هي تقنية الشهادات الرقمية. ومع ذلك، ليس سرا أن العيب الرئيسي للتكنولوجيا هو الثقة غير المشروطة في المراكز التي تصدر الشهادات الرقمية. اقترح مدير التكنولوجيا والابتكار في ENCRY أندري شمورا نهجًا جديدًا للتنظيم البنية التحتية للمفتاح العام (البنية التحتية للمفتاح العام، PKI)، والتي سوف تساعد في القضاء على أوجه القصور الحالية والتي تستخدم تكنولوجيا دفتر الأستاذ الموزع (بلوكشين). ولكن أول الأشياء أولا.
إذا كنت على دراية بكيفية عمل البنية الأساسية الحالية للمفتاح العام لديك وتعرف أوجه القصور الرئيسية فيها، فيمكنك الانتقال إلى ما نقترح تغييره أدناه.
ما هي التوقيعات والشهادات الرقمية؟يتضمن التفاعل على الإنترنت دائمًا نقل البيانات. لدينا جميعًا مصلحة في ضمان نقل البيانات بشكل آمن. ولكن ما هو الأمن؟ الخدمات الأمنية الأكثر طلبًا هي السرية والنزاهة والأصالة. ولهذا الغرض، تُستخدم حاليًا طرق التشفير غير المتماثل، أو التشفير باستخدام مفتاح عام.
لنبدأ بحقيقة أنه لاستخدام هذه الأساليب، يجب أن يكون لموضوعات التفاعل مفتاحان مقترنان فرديان - عام وسري. وبمساعدتهم يتم توفير الخدمات الأمنية التي ذكرناها أعلاه.
كيف يتم تحقيق سرية نقل المعلومات؟ قبل إرسال البيانات، يقوم المشترك المرسل بتشفير (تحويل التشفير) البيانات المفتوحة باستخدام المفتاح العام للمستلم، ويقوم المستلم بفك تشفير النص المشفر المستلم باستخدام المفتاح السري المقترن.
كيف يتم تحقيق سلامة وصحة المعلومات المرسلة؟ ولحل هذه المشكلة، تم إنشاء آلية أخرى. البيانات المفتوحة غير مشفرة، ولكن نتيجة تطبيق وظيفة التجزئة المشفرة - صورة "مضغوطة" لتسلسل بيانات الإدخال - يتم إرسالها في شكل مشفر. تسمى نتيجة هذا التجزئة "الملخص"، ويتم تشفيرها باستخدام المفتاح السري للمشترك المرسل ("الشاهد"). ونتيجة لتشفير الملخص، يتم الحصول على التوقيع الرقمي. ويتم إرساله مع النص الواضح إلى المشترك المتلقي ("المدقق"). يقوم بفك تشفير التوقيع الرقمي على المفتاح العام للشاهد ومقارنته بنتيجة تطبيق وظيفة تجزئة التشفير، والتي يحسبها المدقق بشكل مستقل بناءً على البيانات المفتوحة المستلمة. إذا كانت متطابقة، فهذا يشير إلى أن البيانات تم إرسالها بشكل صحيح وكامل بواسطة المشترك المرسل، ولم يتم تعديلها بواسطة مهاجم.
تستخدم معظم الموارد التي تعمل مع البيانات الشخصية ومعلومات الدفع (البنوك، وشركات التأمين، وشركات الطيران، وأنظمة الدفع، بالإضافة إلى البوابات الحكومية مثل خدمة الضرائب) بشكل فعال أساليب التشفير غير المتماثلة.
ما علاقة الشهادة الرقمية بها؟ انه سهل. تتضمن العمليتان الأولى والثانية مفاتيح عامة، وبما أنهما تلعبان دورًا مركزيًا، فمن المهم جدًا التأكد من أن المفاتيح تنتمي فعليًا إلى المرسل (الشاهد، في حالة التحقق من التوقيع) أو المستلم، وليست كذلك تم استبدالها بمفاتيح المهاجمين. ولهذا السبب توجد شهادات رقمية لضمان صحة وسلامة المفتاح العام.
ملاحظة: يتم التأكد من صحة وسلامة المفتاح العام بنفس الطريقة التي يتم بها التأكد من صحة وسلامة البيانات العامة، أي باستخدام التوقيع الرقمي الإلكتروني (EDS).
من أين تأتي الشهادات الرقمية؟تتولى سلطات التصديق الموثوقة، أو سلطات التصديق (CAs)، مسؤولية إصدار الشهادات الرقمية والحفاظ عليها. يطلب مقدم الطلب إصدار شهادة من CA، ويخضع لتحديد الهوية في مركز التسجيل (CR) ويحصل على شهادة من CA. يضمن CA أن المفتاح العام من الشهادة ينتمي بالضبط إلى الكيان الذي تم إصداره من أجله.
إذا لم تقم بتأكيد صحة المفتاح العام، فيمكن للمهاجم أثناء نقل/تخزين هذا المفتاح استبداله بمفتاحه الخاص. إذا حدث الاستبدال، فسيكون المهاجم قادرًا على فك تشفير كل ما يرسله المشترك المرسل إلى المشترك المتلقي، أو تغيير البيانات المفتوحة وفقًا لتقديره الخاص.
يتم استخدام الشهادات الرقمية حيثما يتوفر التشفير غير المتماثل. إحدى الشهادات الرقمية الأكثر شيوعًا هي شهادات SSL للاتصال الآمن عبر بروتوكول HTTPS. تشارك مئات الشركات المسجلة في ولايات قضائية مختلفة في إصدار شهادات SSL. تقع الحصة الرئيسية على خمسة إلى عشرة مراكز موثوقة كبيرة: IdenTrust، Comodo، GoDaddy، GlobalSign، DigiCert، CERTUM، Actalis، Secom، Trustwave.
يعد CA وCR من مكونات PKI، والتي تتضمن أيضًا:
- الدليل المفتوح - قاعدة بيانات عامة توفر تخزينًا آمنًا للشهادات الرقمية.
- قائمة الشهادات الملغاة - قاعدة بيانات عامة توفر تخزينًا آمنًا للشهادات الرقمية للمفاتيح العامة الملغاة (على سبيل المثال، بسبب اختراق مفتاح خاص مقترن). يمكن لموضوعات البنية التحتية الوصول بشكل مستقل إلى قاعدة البيانات هذه، أو يمكنهم استخدام بروتوكول حالة الشهادة عبر الإنترنت (OCSP) المتخصص، والذي يبسط عملية التحقق.
- مستخدمي الشهادة - موضوعات البنية التحتية للمفاتيح العمومية المخدومة التي أبرمت اتفاقية مستخدم مع سلطة التصديق وتحققت من التوقيع الرقمي و/أو تشفير البيانات بناءً على المفتاح العمومي من الشهادة.
- المتابعون - يتم تقديم موضوعات البنية التحتية للمفاتيح العمومية (PKI) التي تمتلك مفتاحًا سريًا مقترنًا بالمفتاح العام من الشهادة، والذين أبرموا اتفاقية مشترك مع CA. ويمكن للمشترك أن يكون مستخدمًا للشهادة في نفس الوقت.
ومن ثم، فإن الكيانات الموثوقة للبنية التحتية للمفتاح العام، والتي تشمل المراجع المصدقة والمكاتب الجاهزة والأدلة المفتوحة، تكون مسؤولة عن:
1. التحقق من صحة هوية مقدم الطلب.
2. ملف تعريف شهادة المفتاح العام.
3. إصدار شهادة المفتاح العام لمقدم الطلب الذي تم التأكد من هويته بشكل موثوق.
4. تغيير حالة شهادة المفتاح العام.
5. توفير معلومات حول الوضع الحالي لشهادة المفتاح العام.
عيوب الـ PKI، ما هي؟العيب الأساسي في البنية التحتية للمفاتيح العمومية هو وجود كيانات موثوقة.
يجب على المستخدمين الثقة دون قيد أو شرط في CA وCR. ولكن، كما تظهر الممارسة، فإن الثقة غير المشروطة محفوفة بعواقب وخيمة.
على مدى السنوات العشر الماضية، كانت هناك العديد من الفضائح الكبرى في هذا المجال المتعلقة بضعف البنية التحتية.
- في عام 2010، بدأت البرمجيات الخبيثة Stuxnet في الانتشار عبر الإنترنت، وتم توقيعها باستخدام شهادات رقمية مسروقة من RealTek وJMicron.
- في عام 2017، اتهمت جوجل شركة سيمانتك بإصدار عدد كبير من الشهادات المزورة. في ذلك الوقت، كانت شركة Symantec واحدة من أكبر المراجع المصدقة من حيث حجم الإنتاج. في متصفح Google Chrome 70، تم إيقاف دعم الشهادات الصادرة عن هذه الشركة والمراكز التابعة لها GeoTrust وThawte قبل 1 ديسمبر 2017.
لقد تم اختراق المراجع المصدقة، ونتيجة لذلك عانى الجميع - المراجع المصدقة نفسها، بالإضافة إلى المستخدمين والمشتركين. وقد تم تقويض الثقة في البنية التحتية. بالإضافة إلى ذلك، قد يتم حظر الشهادات الرقمية في سياق الصراعات السياسية، مما سيؤثر أيضًا على تشغيل العديد من الموارد. وهذا بالضبط ما كان يخشاه الإدارة الرئاسية الروسية منذ عدة سنوات، حيث ناقشوا في عام 2016 إمكانية إنشاء مركز شهادات حكومي من شأنه أن يصدر شهادات SSL للمواقع الموجودة على شبكة RuNet. الوضع الحالي هو أنه حتى بوابات الدولة في روسيا الشهادات الرقمية الصادرة عن الشركات الأمريكية Comodo أو Thawte (إحدى الشركات التابعة لشركة Symantec).
هناك مشكلة أخرى - السؤال المصادقة الأولية (المصادقة) للمستخدمين. كيفية التعرف على المستخدم الذي اتصل بالمرجع المصدق لطلب إصدار شهادة رقمية دون اتصال شخصي مباشر؟ الآن يتم حل هذه المشكلة ظرفيًا اعتمادًا على قدرات البنية التحتية. يتم أخذ شيء ما من السجلات المفتوحة (على سبيل المثال، معلومات حول الكيانات القانونية التي تطلب الشهادات)؛ في الحالات التي يكون فيها المتقدمون أفرادًا، يمكن استخدام مكاتب البنوك أو مكاتب البريد، حيث يتم تأكيد هويتهم باستخدام وثائق الهوية، على سبيل المثال، جواز السفر.
تعتبر مشكلة تزوير أوراق الاعتماد بغرض انتحال الشخصية مشكلة أساسية. دعونا نلاحظ أنه لا يوجد حل كامل لهذه المشكلة لأسباب نظرية المعلومات: دون الحصول على معلومات موثوقة مسبقا، فمن المستحيل تأكيد أو إنكار صحة موضوع معين. كقاعدة عامة، للتحقق من الضروري تقديم مجموعة من الوثائق التي تثبت هوية مقدم الطلب. هناك العديد من طرق التحقق المختلفة، ولكن لا يوفر أي منها ضمانًا كاملاً لصحة المستندات. وبناءً على ذلك، لا يمكن أيضًا ضمان صحة هوية مقدم الطلب.
كيف يمكن القضاء على هذه النواقص؟إذا كان من الممكن تفسير مشاكل البنية التحتية للمفاتيح العمومية في حالتها الحالية بالمركزية، فمن المنطقي افتراض أن اللامركزية ستساعد جزئيًا في القضاء على أوجه القصور المحددة.
لا تعني اللامركزية وجود كيانات موثوقة - إذا قمت بإنشائها البنية التحتية للمفتاح العام اللامركزية (البنية التحتية للمفتاح العام اللامركزي، دبكي)، فلن تكون هناك حاجة إلى CA أو CR. دعونا نتخلى عن مفهوم الشهادة الرقمية ونستخدم السجل الموزع لتخزين المعلومات حول المفاتيح العامة. في حالتنا، نسمي السجل قاعدة بيانات خطية تتكون من سجلات فردية (كتل) مرتبطة باستخدام تقنية blockchain. بدلاً من الشهادة الرقمية، سنقدم مفهوم “الإشعار”.
كيف ستبدو عملية تلقي الإشعارات والتحقق منها وإلغائها في DPKI المقترحة:
1. يقدم كل متقدم طلبًا للإخطار بشكل مستقل عن طريق ملء نموذج أثناء التسجيل، وبعد ذلك يقوم بإنشاء معاملة يتم تخزينها في تجمع متخصص.
2. يتم تخزين المعلومات المتعلقة بالمفتاح العام، بالإضافة إلى تفاصيل المالك وبيانات التعريف الأخرى، في سجل موزع، وليس في شهادة رقمية، والتي يكون CA مسؤولاً عن إصدارها في بنية مفاتيح عمومية مركزية.
3. يتم التحقق من صحة هوية مقدم الطلب بعد حدوثها من خلال الجهود المشتركة لمجتمع مستخدمي DPKI، وليس من خلال السجل التجاري.
4. يمكن لمالك هذا الإشعار فقط تغيير حالة المفتاح العام.
5. يمكن لأي شخص الوصول إلى دفتر الأستاذ الموزع والتحقق من الحالة الحالية للمفتاح العام.
ملحوظة: التحقق المجتمعي من هوية مقدم الطلب قد يبدو غير موثوق به للوهلة الأولى. ولكن يجب علينا أن نتذكر أن جميع مستخدمي الخدمات الرقمية في الوقت الحاضر يتركون حتماً بصمة رقمية، وسوف تستمر هذه العملية في اكتساب الزخم. السجلات الإلكترونية المفتوحة للكيانات القانونية، والخرائط، ورقمنة صور التضاريس، والشبكات الاجتماعية - كل هذه أدوات متاحة للجمهور. لقد تم استخدامها بنجاح أثناء التحقيقات من قبل الصحفيين ووكالات إنفاذ القانون. على سبيل المثال، يكفي التذكير بتحقيقات شركة Bellingcat أو فريق التحقيق المشترك JIT، الذي يدرس ملابسات تحطم طائرة بوينغ الماليزية.
إذًا كيف ستعمل البنية التحتية للمفتاح العام اللامركزي عمليًا؟ دعونا نتحدث عن وصف التكنولوجيا نفسها، والتي نحن براءة اختراع في عام 2018 ونحن نعتبرها بحق خبرتنا.
تخيل أن هناك مالكًا يمتلك العديد من المفاتيح العامة، حيث يمثل كل مفتاح معاملة معينة يتم تخزينها في السجل. في حالة عدم وجود CA، كيف يمكنك أن تفهم أن جميع المفاتيح تنتمي إلى هذا المالك بالذات؟ لحل هذه المشكلة، يتم إنشاء معاملة صفرية تحتوي على معلومات حول المالك ومحفظته (والتي يتم خصم عمولة وضع المعاملة في السجل منها). المعاملة الفارغة هي نوع من "المرساة" التي سيتم إرفاق المعاملات التالية ببيانات حول المفاتيح العامة بها. تحتوي كل معاملة على بنية بيانات متخصصة، أو بمعنى آخر، إشعار.
الإخطار عبارة عن مجموعة منظمة من البيانات تتكون من حقول وظيفية وتتضمن معلومات حول المفتاح العام للمالك، ويتم ضمان استمرارها عن طريق وضعها في أحد السجلات المرتبطة بالسجل الموزع.
السؤال المنطقي التالي هو كيف يتم تشكيل معاملة صفرية؟ المعاملة الفارغة - مثل المعاملات اللاحقة - عبارة عن تجميع لستة حقول بيانات. أثناء تكوين معاملة صفرية، يتم تضمين زوج المفاتيح للمحفظة (المفاتيح السرية العامة والمقترنة). يظهر هذا الزوج من المفاتيح في الوقت الذي يسجل فيه المستخدم محفظته، حيث سيتم خصم عمولة وضع معاملة صفرية في السجل، وبالتالي العمليات مع الإشعارات.
كما هو موضح في الشكل، يتم إنشاء ملخص المفتاح العام للمحفظة من خلال تطبيق وظائف التجزئة SHA256 وRIPEMD160 بشكل تسلسلي. هنا يكون RIPEMD160 مسؤولاً عن التمثيل المضغوط للبيانات التي لا يتجاوز عرضها 160 بت. وهذا أمر مهم لأن التسجيل ليس قاعدة بيانات رخيصة. يتم إدخال المفتاح العام نفسه في الحقل الخامس. يحتوي الحقل الأول على البيانات التي تنشئ اتصالاً بالمعاملة السابقة. بالنسبة للمعاملة الصفرية، لا يحتوي هذا الحقل على أي شيء، مما يميزه عن المعاملات اللاحقة. الحقل الثاني هو بيانات للتحقق من اتصال المعاملات. للإيجاز، سوف نسمي البيانات الموجودة في الحقلين الأول والثاني "رابط" و"تحقق"، على التوالي. يتم إنشاء محتويات هذه الحقول عن طريق التجزئة التكرارية، كما هو موضح من خلال ربط المعاملات الثانية والثالثة في الشكل أدناه.
يتم اعتماد البيانات من الحقول الخمسة الأولى من خلال التوقيع الإلكتروني، الذي يتم إنشاؤه باستخدام المفتاح السري للمحفظة.
هذا كل شيء، يتم إرسال المعاملة الفارغة إلى المجمع وبعد إدخال التحقق الناجح في السجل. الآن يمكنك "ربط" المعاملات التالية بها. دعونا نفكر في كيفية تشكيل المعاملات غير الصفر.
أول ما لفت انتباهك على الأرجح هو وفرة أزواج المفاتيح. بالإضافة إلى زوج مفاتيح المحفظة المألوف بالفعل، يتم استخدام أزواج المفاتيح العادية ومفاتيح الخدمة.
المفتاح العام العادي هو ما بدأ كل شيء من أجله. ويشارك هذا المفتاح في مختلف الإجراءات والعمليات التي تتكشف في العالم الخارجي (المعاملات المصرفية وغيرها، وتدفق المستندات، وما إلى ذلك). على سبيل المثال، يمكن استخدام مفتاح سري من زوج عادي لإنشاء التوقيعات الرقمية لمختلف المستندات - أوامر الدفع، وما إلى ذلك، ويمكن استخدام المفتاح العام للتحقق من هذا التوقيع الرقمي مع التنفيذ اللاحق لهذه التعليمات، بشرط أن يكون ذلك صالح.
يتم إصدار زوج الخدمة لموضوع DPKI المسجل. اسم هذا الزوج يتوافق مع الغرض منه. لاحظ أنه عند تكوين/التحقق من معاملة صفرية، لا يتم استخدام مفاتيح الخدمة.
دعونا نوضح الغرض من المفاتيح مرة أخرى:
- تُستخدم مفاتيح المحفظة لإنشاء/التحقق من كل من المعاملات الفارغة وأي معاملة أخرى غير فارغة. المفتاح الخاص للمحفظة معروف فقط لمالك المحفظة، وهو أيضًا مالك العديد من المفاتيح العامة العادية.
- يشبه المفتاح العام العادي في الغرض المفتاح العام الذي يتم إصدار شهادة له في بنية مفاتيح عمومية مركزية.
- ينتمي زوج مفاتيح الخدمة إلى DPKI. يتم إصدار المفتاح السري للجهات المسجلة ويستخدم عند إنشاء التوقيعات الرقمية للمعاملات (باستثناء المعاملات الصفرية). يُستخدم الجمهور للتحقق من التوقيع الرقمي الإلكتروني للمعاملة قبل نشرها في السجل.
وبالتالي، هناك مجموعتان من المفاتيح. يتضمن الأول مفاتيح الخدمة ومفاتيح المحفظة - فهي ذات معنى فقط في سياق DPKI. تتضمن المجموعة الثانية مفاتيح عادية - قد يختلف نطاقها ويتم تحديدها حسب مهام التطبيق التي يتم استخدامها فيها. وفي الوقت نفسه، يضمن DPKI سلامة وصحة المفاتيح العامة العادية.
ملاحظة: قد يكون زوج مفاتيح الخدمة معروفًا لكيانات DPKI المختلفة. على سبيل المثال، قد يكون هو نفسه بالنسبة للجميع. ولهذا السبب، عند إنشاء توقيع كل معاملة غير صفرية، يتم استخدام مفتاحين سريين، أحدهما هو مفتاح المحفظة - وهو معروف فقط لمالك المحفظة، وهو أيضًا مالك العديد من المعاملات العادية المفاتيح العامة. جميع المفاتيح لها معناها الخاص. على سبيل المثال، من الممكن دائمًا إثبات أن المعاملة قد تم إدخالها في السجل بواسطة موضوع DPKI مسجل، نظرًا لأن التوقيع تم إنشاؤه أيضًا على مفتاح خدمة سرية. ولا يمكن أن يكون هناك أي إساءة، مثل هجمات DOS، لأن المالك يدفع مقابل كل معاملة.
يتم تشكيل جميع المعاملات التي تتبع الصفر بطريقة مماثلة: يتم تشغيل المفتاح العام (وليس المحفظة، كما في حالة المعاملة الصفرية، ولكن من زوج مفاتيح عادي) من خلال وظيفتي التجزئة SHA256 وRIPEMD160. هذه هي الطريقة التي يتم بها تشكيل بيانات الحقل الثالث. يحتوي الحقل الرابع على معلومات مصاحبة (على سبيل المثال، معلومات حول الحالة الحالية، وتواريخ انتهاء الصلاحية، والطابع الزمني، ومعرفات خوارزميات التشفير المستخدمة، وما إلى ذلك). يحتوي الحقل الخامس على المفتاح العام من زوج مفاتيح الخدمة. وبمساعدتها، سيتم بعد ذلك التحقق من التوقيع الرقمي، وبالتالي سيتم نسخه. دعونا نبرر الحاجة إلى مثل هذا النهج.
تذكر أنه يتم إدخال المعاملة في المجمع وتخزينها هناك حتى تتم معالجتها. يرتبط التخزين في التجمع بمخاطر معينة - حيث يمكن تزوير بيانات المعاملات. يقوم المالك بتصديق بيانات المعاملة بتوقيع رقمي إلكتروني. تتم الإشارة بوضوح إلى المفتاح العام للتحقق من هذا التوقيع الرقمي في أحد حقول المعاملات ويتم إدخاله لاحقًا في السجل. تتمثل خصوصيات معالجة المعاملات في أن المهاجم قادر على تغيير البيانات وفقًا لتقديره الخاص ثم التحقق منها باستخدام مفتاحه السري، والإشارة إلى مفتاح عام مقترن للتحقق من التوقيع الرقمي في المعاملة. إذا تم ضمان الأصالة والنزاهة حصريًا من خلال التوقيع الرقمي، فلن يتم ملاحظة هذا التزوير. ومع ذلك، إذا كانت هناك، بالإضافة إلى التوقيع الرقمي، آلية إضافية تضمن أرشفة واستمرارية المعلومات المخزنة، فيمكن اكتشاف التزوير. للقيام بذلك، يكفي إدخال المفتاح العام الحقيقي للمالك في السجل. دعونا نشرح كيف يعمل هذا.
السماح للمهاجم بتزوير بيانات المعاملة. من وجهة نظر المفاتيح والتوقيعات الرقمية، الخيارات التالية ممكنة:
1. يضع المهاجم مفتاحه العام في المعاملة بينما يظل التوقيع الرقمي للمالك دون تغيير.
2. يقوم المهاجم بإنشاء توقيع رقمي على مفتاحه الخاص، لكنه يترك المفتاح العام للمالك دون تغيير.
3. يقوم المهاجم بإنشاء توقيع رقمي على مفتاحه الخاص ويضع مفتاحًا عامًا مقترنًا في المعاملة.
من الواضح أن الخيارين 1 و2 لا معنى لهما، حيث سيتم اكتشافهما دائمًا أثناء التحقق من التوقيع الرقمي. الخيار 3 فقط هو المنطقي، وإذا قام المهاجم بتكوين توقيع رقمي على مفتاحه السري الخاص، فإنه يضطر إلى حفظ مفتاح عام مقترن في المعاملة، يختلف عن المفتاح العام للمالك. هذه هي الطريقة الوحيدة للمهاجم لفرض بيانات مزورة.
لنفترض أن المالك لديه زوج ثابت من المفاتيح - خاص وعام. دع البيانات يتم التصديق عليها عن طريق التوقيع الرقمي باستخدام المفتاح السري من هذا الزوج، ويتم الإشارة إلى المفتاح العام في المعاملة. لنفترض أيضًا أن هذا المفتاح العام قد تم إدخاله مسبقًا في السجل وتم التحقق من صحته بشكل موثوق. ثم سيتم الإشارة إلى التزوير من خلال حقيقة أن المفتاح العام من المعاملة لا يتوافق مع المفتاح العام من السجل.
دعونا نلخص. عند معالجة بيانات المعاملة الأولى للمالك، من الضروري التحقق من صحة المفتاح العام الذي تم إدخاله في السجل. للقيام بذلك، اقرأ المفتاح من السجل وقارنه بالمفتاح العام الحقيقي للمالك داخل محيط الأمان (منطقة الحصانة النسبية). إذا تم تأكيد صحة المفتاح وتم ضمان استمراره عند وضعه، فيمكن تأكيد/دحض صحة المفتاح من المعاملة اللاحقة بسهولة عن طريق مقارنته بالمفتاح من السجل. بمعنى آخر، يتم استخدام المفتاح من التسجيل كعينة مرجعية. تتم معالجة جميع معاملات المالك الأخرى بالمثل.
يتم اعتماد المعاملة من خلال التوقيع الرقمي الإلكتروني - حيث تكون هناك حاجة إلى مفاتيح سرية، وليس مفتاحًا واحدًا، بل اثنين في وقت واحد - مفتاح الخدمة ومفتاح المحفظة. بفضل استخدام مفتاحين سريين، يتم ضمان المستوى الضروري من الأمان - بعد كل شيء، يمكن معرفة مفتاح الخدمة السري للمستخدمين الآخرين، في حين أن المفتاح السري للمحفظة معروف فقط لمالك زوج المفاتيح العادي. لقد أطلقنا على هذا التوقيع ذي المفتاحين اسم التوقيع الرقمي "الموحد".
يتم التحقق من المعاملات غير الفارغة باستخدام مفتاحين عامين: المحفظة ومفتاح الخدمة. يمكن تقسيم عملية التحقق إلى مرحلتين رئيسيتين: الأولى هي التحقق من ملخص المفتاح العام للمحفظة، والثانية هي التحقق من التوقيع الرقمي الإلكتروني للمعاملة، وهو نفس التوقيع الموحد الذي تم تشكيله باستخدام مفتاحين سريين ( المحفظة والخدمة). إذا تم تأكيد صحة التوقيع الرقمي، بعد التحقق الإضافي، يتم إدخال المعاملة في السجل.
قد يطرح سؤال منطقي: كيفية التحقق مما إذا كانت المعاملة تنتمي إلى سلسلة معينة ذات "الجذر" في شكل معاملة صفرية؟ ولهذا الغرض، تُستكمل عملية التحقق بمرحلة أخرى - التحقق من الاتصال. هذا هو المكان الذي سنحتاج فيه إلى البيانات من الحقلين الأولين، والتي تجاهلناها حتى الآن.
لنتخيل أننا بحاجة إلى التحقق مما إذا كانت المعاملة رقم 3 تأتي بالفعل بعد المعاملة رقم 2. للقيام بذلك، باستخدام طريقة التجزئة المدمجة، يتم حساب قيمة دالة التجزئة للبيانات من الحقول الثالث والرابع والخامس للمعاملة رقم 2. ثم يتم تنفيذ تسلسل البيانات من الحقل الأول للمعاملة رقم 3 وقيمة دالة التجزئة المجمعة التي تم الحصول عليها مسبقًا للبيانات من الحقول الثالث والرابع والخامس للمعاملة رقم 2. يتم تشغيل كل هذا أيضًا من خلال وظيفتي التجزئة SHA256 وRIPEMD160. إذا كانت القيمة المستلمة تطابق البيانات الموجودة في الحقل الثاني من المعاملة رقم 2، فسيتم تمرير الشيك وتأكيد الاتصال. ويظهر هذا بشكل أكثر وضوحا في الأشكال أدناه.
بشكل عام، تبدو تقنية إنشاء الإشعارات وإدخالها في السجل هكذا تمامًا. ويرد في الشكل التالي رسم توضيحي مرئي لعملية تشكيل سلسلة الإشعارات:
في هذا النص، لن نخوض في التفاصيل، التي لا شك أنها موجودة، ونعود لمناقشة فكرة البنية التحتية للمفتاح العام اللامركزية.
لذلك، بما أن مقدم الطلب نفسه يقدم طلبًا لتسجيل الإخطارات، التي لا يتم تخزينها في قاعدة بيانات CA، ولكن في التسجيل، فيجب مراعاة المكونات المعمارية الرئيسية لـ DPKI:
1. سجل الإخطارات الصالحة (RDN).
2. سجل الإخطارات الملغاة (RON).
3. سجل الإخطارات المعلقة (RPN).
يتم تخزين المعلومات حول المفاتيح العامة في RDN/RON/RPN في شكل قيم دالة التجزئة. ومن الجدير بالذكر أيضًا أن هذه يمكن أن تكون إما سجلات مختلفة، أو سلاسل مختلفة، أو حتى سلسلة واحدة كجزء من سجل واحد، عندما يتم إدخال معلومات حول حالة المفتاح العام العادي (الإلغاء، التعليق، وما إلى ذلك) في السجل. الحقل الرابع من بنية البيانات في شكل قيمة الكود المقابلة. هناك العديد من الخيارات المختلفة للتنفيذ المعماري لـ DPKI، ويعتمد اختيار واحد أو آخر على عدد من العوامل، على سبيل المثال، معايير التحسين مثل تكلفة الذاكرة طويلة المدى لتخزين المفاتيح العامة، وما إلى ذلك.
وبالتالي، قد يتبين أن DPKI، إن لم تكن أبسط، يمكن مقارنتها على الأقل بحل مركزي من حيث التعقيد المعماري.
ويبقى السؤال الرئيسي - ما هو السجل المناسب لتطبيق التكنولوجيا؟
الشرط الرئيسي للتسجيل هو القدرة على إنشاء المعاملات من أي نوع. أشهر مثال على دفتر الأستاذ هو شبكة Bitcoin. ولكن عند تنفيذ التكنولوجيا الموصوفة أعلاه، تنشأ بعض الصعوبات: القيود المفروضة على لغة البرمجة النصية الحالية، وعدم وجود الآليات اللازمة لمعالجة مجموعات البيانات التعسفية، وطرق توليد المعاملات من النوع التعسفي، وأكثر من ذلك بكثير.
لقد حاولنا في ENCRY حل المشكلات الموضحة أعلاه وقمنا بتطوير سجل، والذي في رأينا له عدد من المزايا وهي:
- يدعم عدة أنواع من المعاملات: يمكنه تبادل الأصول (أي إجراء المعاملات المالية) وإنشاء معاملات ذات بنية تعسفية،
- يمكن للمطورين الوصول إلى لغة البرمجة الخاصة PrismLang، والتي توفر المرونة اللازمة عند حل المشكلات التكنولوجية المختلفة،
- يتم توفير آلية لمعالجة مجموعات البيانات التعسفية.
إذا اتبعنا نهجًا مبسطًا، فسيتم تنفيذ التسلسل التالي من الإجراءات:
- يقوم مقدم الطلب بالتسجيل لدى DPKI ويتلقى محفظة رقمية. عنوان المحفظة هو قيمة التجزئة للمفتاح العام للمحفظة. المفتاح الخاص للمحفظة معروف فقط لمقدم الطلب.
- يتم منح الموضوع المسجل حق الوصول إلى المفتاح السري للخدمة.
- يُنشئ الموضوع معاملة صفرية ويتحقق منها بتوقيع رقمي باستخدام المفتاح السري للمحفظة.
- في حالة تكوين معاملة غير الصفر، يتم اعتمادها من خلال توقيع رقمي إلكتروني باستخدام مفتاحين سريين: المحفظة ومفتاح الخدمة.
- يقدم الموضوع معاملة إلى المجمع.
- تقرأ عقدة شبكة ENCRY المعاملة من التجمع وتتحقق من التوقيع الرقمي، بالإضافة إلى اتصال المعاملة.
- إذا كان التوقيع الرقمي صالحًا وتم تأكيد الاتصال، فإنه يقوم بإعداد المعاملة لإدخالها في السجل.
هنا يعمل السجل كقاعدة بيانات موزعة تقوم بتخزين معلومات حول الإشعارات الصالحة والملغاة والمعلقة.
وبطبيعة الحال، فإن اللامركزية ليست حلا سحريا. لا تختفي المشكلة الأساسية المتمثلة في مصادقة المستخدم الأساسي في أي مكان: إذا تم حاليًا التحقق من مقدم الطلب بواسطة السجل التجاري، فيُقترح في DPKI تفويض التحقق لأعضاء المجتمع، واستخدام الدافع المالي لتحفيز النشاط. تكنولوجيا التحقق مفتوحة المصدر معروفة جيدًا. وقد تم تأكيد فعالية هذا التحقق في الممارسة العملية. دعونا نتذكر مرة أخرى عددًا من التحقيقات رفيعة المستوى التي أجرتها مجلة Bellingcat على الإنترنت.
ولكن بشكل عام، تظهر الصورة التالية: تعد البنية التحتية للمفاتيح العامة (DPKI) فرصة لتصحيح العديد من أوجه القصور في البنية التحتية للمفاتيح العمومية المركزية، إن لم يكن كلها.
اشترك في مدونة Habrablog الخاصة بنا، ونحن نخطط لمواصلة تغطية أبحاثنا وتطويرنا ومتابعتها بشكل فعال ، إذا كنت لا تريد أن تفوتك أخبار أخرى حول مشاريع ENCRY.
المصدر: www.habr.com