الرأي: Enterprise Blockchains Redux: كيف تكون غير متوافق مع NIST دون كسر البنك

رأي من أندرياس فرويند ، عضو مجموعة المصالح EEA Mainnet

نادرًا ما تحدثت بلوكتشين عن مشكلة مستقلة عن الصعود والهبوط في أسواق العملات المشفرة ، والتي يمكن أن تعرقل اعتماد بلوكتشين على المدى الطويل خارج التعامل المباشر مع المستهلك وبعض حالات استخدام B2B: خوارزميات تشفير Blockchain ليست متوافقة مع NIST وهو عامل رئيسي في تحقيق الامتثال لقانون إدارة أمن المعلومات الفيدرالي (FISMA)! يعد الامتثال NIST / FISMA ، أو ما يعادله خارج الولايات المتحدة ، أمرًا مهمًا عندما تتعامل المؤسسات مع الحكومات أو المؤسسات التي تتعامل بانتظام مع المؤسسات التي تتعامل مع الحكومات.

لماذا لا تتوافق Blockchains عادةً مع NIST؟ حسنًا ، السبب الرئيسي هو أن Blockchains ولدت من عدم الثقة العميق في أي شيء تديره الحكومة وتؤيده في أعقاب الركود العظيم في عام 2008 ؛ بما في ذلك خوارزميات التشفير المعتمدة من الحكومة. على أي حال ، لم يتم الانتهاء من خوارزمية التجزئة SHA-3 المقبولة على نطاق واسع اليوم حتى عام 2015 بعد أن اتخذت بلوكتشين مثل Ethereum خياراتها بالفعل بشأن خوارزميات التجزئة. لذلك ، فإن معظم سلاسل الكتل مثل Ethereum تستخدم خوارزميات ليست فقط معتمدة من NIST ، ولكن NIST توصي بعدم استخدامها. ملاحظة ، هناك بلوكشين متوافقة مع NIST مثل Simba-Chain أو Fabric تعمل على LinuxONE من IBM. ومع ذلك ، فهي عالية التكلفة ويصعب إدارتها في الإنتاج[1]  كما علمت الشركات بعد إنفاق عشرات الملايين من الدولارات على رسوم الاستشارات والتنفيذ. ومما يزيد مشكلة التكلفة تعقيدًا أنها غالبًا لا تسفر عن نتائج الأعمال المتوقعة لأن حالات الاستخدام المختارة لم تكن مناسبة لـ Blockchains لتبدأ بها! تتمثل الفكرة الرئيسية للمناقشة أدناه في أن أي نهج جديد من بلوكتشين للمؤسسات يجب أن يعالج ليس فقط امتثال NIST ولكن أيضًا تعقيد التكلفة والإدارة بشكل فعال لجذب رعاة أعمال جدد.

هل هذا يعني أن كل شيء ميؤوس منه بالنسبة لـ Blockchain في مؤسسة عندما يكون التوافق مع NIST والتكلفة وتعقيد الإدارة مصدر قلق؟

لحسن الحظ ، الجواب لا ، ليس ميؤوسا منه. ليس تافها ، ولكن ليس ميؤوسا منه.

لفهم ما يعنيه هذا ، دعنا نلخص خصائص التطبيقات المستندة إلى Blockchain يمكن يملك:

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

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

قبل أن نتقدم على أنفسنا ، دعنا نتوقف هنا ونناقش كيف ترتبط هذه الخصائص بتوافق NIST. للوهلة الأولى ، ليس كثيرًا ، لكن دعنا نتصفح كل خاصية ونناقش آثارها بمزيد من التفصيل. أولاً ، على الرغم من ذلك ، من الجدير بالذكر أنه للحصول على أذونات سلطة التشغيل (ATO) من حكومة ، مثل حكومة الولايات المتحدة[2]، لا بأس في استخدام خوارزميات تشفير غير متوافقة مع NIST ، أو خوارزميات لم يبدِ رأي NIST بشأنها ، طالما أن هذه الخوارزميات ليست أساسية لأمان التطبيق وخصوصية بياناته. على سبيل المثال ، تحتاج إلى إثبات أن العقد قد تم تنفيذه في يوم محدد ولم يتم تغييره منذ ذلك الحين. باستخدام Blockchain ، يمكن للمرء أن يشكل بصمة مشفرة باستخدام تجزئة تشفير (معتمدة من NIST) للعقد ، ثم يثبت هذا التجزئة على Blockchain (عام) والذي يوفر ، بمجرد تضمينه في الكتلة ، طابعًا زمنيًا يمكن إثباته من خلال مجموعة من رقم الكتلة وتجزئة الكتلة والطابع الزمني. إذا تمت إعادة تنظيم Blockchain ، على سبيل المثال من خلال هجوم بنسبة 51٪ ، فسيظل من الممكن إجراء المعاملة مع تجزئة العقد ، وكتلها وإدراجها في بلوك تشين آخر (عام). لذلك ، فإن أمان Blockchain الأصلي (العام) ليس أساسيًا لحالة الاستخدام.

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

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

يمكن أن يعمل تقييم التأثير أعلاه الآن كقائمة مراجعة لاحتياجات الامتثال لـ NIST لتطبيق Blockchain ، بالنظر إلى متطلبات حالة الاستخدام المحددة لهذا التطبيق.

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

الجواب: إثباتات المعرفة الصفرية (ZKPs)

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

هناك العديد من أنواع ZKPs المفيدة - Merkle Proofs و Pedersen Commitments و Bulletproofs و ZK-SNARKs و ZK-STARKs وما إلى ذلك. المفتاح هو استخدام خوارزميات التشفير المتوافقة مع NIST أو غير المتوافقة مع NIST عند استخدام ZKPs. خلاف ذلك ، اذهب لذلك! ZKPs هي أداة رائعة للمؤسسات لتلبية متطلبات خصوصية البيانات الداخلية والتنظيمية.

نحن الآن في مكان لتقديم توصية معقولة حول كيفية إنشاء تطبيق مؤسسة قائم على Blockchain متوافق مع (وليس) NIST - مخطط.

تكاليف النشر والتشغيل الفعلية غير متاحة للجمهور ، ولكن بناءً على معرفة المؤلفين ، تتراوح بين ثمانية أرقام ورائعة بالدولار الأمريكي مع تكاليف التشغيل عادةً في نطاق 15-25٪ - راجع أيضًا بعض المراجع هنا و هنا. تعد نطاقات التكلفة هذه نموذجية لتطبيقات وعمليات أنظمة المؤسسات واسعة النطاق مثل أنظمة تخطيط موارد المؤسسات (ERP).

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

كما يوضح الشكل ، نبدأ بمكدس برامج المؤسسة التقليدية في الأعلى - أولاً ، طبقة التطبيق ، ثم طبقة تجريد التطبيق ثم طبقة البرامج الوسيطة - مع كل التوافق المطلوب ، مثل توافق NIST المدمج. في الجزء السفلي من المكدس ، لدينا Blockchain عامة لأن ذلك يغني عن حاجة الشركات لبناء اتحادات معقدة ، وإنفاق الكثير من المال ، والسماح لها بالتحرك بسرعة أكبر مع تطوير منتجات جديدة. بين الطبقة الوسيطة وطبقة Blockchain العامة ، توجد طبقة المعالجة "السحرية" التي تركز على الخصوصية والسرعة. نظرًا لأن المكدس سيستخدم ZKPs للحفاظ على الخصوصية ولا يستخدم بشكل أساسي الأصول الرقمية التي تم إنشاؤها على Blockchain العامة ، فقد اختفت فجأة المخاوف السابقة بشأن استخدام Blockchains العامة. كما يشير السهمان لأعلى ولأسفل على يسار الشكل ، يزداد أمان المكدس أثناء انتقالنا من الطبقة العليا إلى الأسفل ، Blockchain العامة. يحدث العكس تمامًا مع الخصائص الرئيسية الثلاثة الأخرى - الخصوصية والسرعة والتحكم ؛ تزداد من الطبقة السفلية إلى الطبقة العليا حيث تتمتع مؤسسة واحدة بالتحكم الكامل في جميع البيانات ، وبالتالي يمكنها ضمان الخصوصية مع الحفاظ على السرعة / قابلية التوسع العالية حتى بالنسبة للبيانات الأكثر حساسية. هذا لا يعني ، مع ذلك ، أن الخصوصية والسرعة والتحكم منخفضان في الجزء السفلي من المكدس ، بل يعني فقط أنه أعلى في الطبقات العليا من المكدس منه في الأسفل.

الآن ، ماذا عن طبقة / شبكة المعالجة "السحرية"؟

إليك ما يمكن أن تفعله هذه الطبقة باستخدام التكنولوجيا الحالية لتلبية متطلبات المؤسسة:

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

باختصار ، طبقة المعالجة "السحرية" لها

• نفس ضمانات الأمان المستخدمة في Blockchain العامة ،
• 100-1000 ضعف قابلية التوسع ،
• ضمان توافر البيانات ،
• الحفاظ على الخصوصية في جميع الأوقات ،
• رسوم معاملات أقل بكثير ،
• إمكانية التحقق من جميع البراهين من قبل أي شخص على Blockchain العامة
• يسمح لـ KYC و AML

هذا يبدو جيدا جدا ليكون صحيحا. هل هذه التكنولوجيا موجودة بالفعل؟ الإجابة هي نعم ، وتعمل شركات مثل Starkware و Aztec و zkSync وغيرها على جعل تقنيات ZK-Rollup “Layer 2” جاهزة تمامًا للمؤسسات. ينصب التركيز في كل هذه الجهود على Ethereum العامة لأنها توفر أعلى ضمانات أمان (عدد المعدنين / المدققين وإجمالي القيمة المقفلة (TVL)) ، جنبًا إلى جنب مع دعم التشفير المطلوب المدمج في طبقة التنفيذ الخاصة به.

بطبيعة الحال ، ليس هذا هو النهج الوحيد الممكن لتطبيق قائم على Blockchain للحصول على ATO حكومي. ومع ذلك ، فهو نهج مباشر إلى حد ما ، وهو مفهوم الآن جيدًا.

إذن ما هي الشبكة هنا؟

الشركات لديها الآن

• A الإطار لتقييم احتياجات حالة الاستخدام مقابل خصائص Blockchain ، وكيف يمكن تلبية هذه الاحتياجات من خلال تطبيقات المؤسسات القائمة على Blockchain والتي يمكنها الحصول على ATO حكومي.
• A مخطط لإنشاء تطبيقات مؤسسية قائمة على Blockchain بطريقة تسمح لهم بالحصول على ATO حكومي بينما ، كما هو موضح في الشكل أعلاه ، يسمح أيضًا بمزايا إضافية:
  • ثقة أعلى من خلال Blockchains العامة ، وإمكانية التحقق العامة وخصوصية فرض التشفير
  • أقل تكلفة من خلال إمكانية التدقيق الأسهل (التحقق من أن ZKPs سريع ورخيص) وتجميع المعاملات الفاخرة (تجميعات) في تطبيق الطبقة الثانية
  • معالجة أسرع من خلال موازاة الحوسبة ، والمزيد من المعاملات من خلال المجموعات ، وبصمة Blockchain أصغر نظرًا لأنه من المفترض أن تكون Blockchain العامة بطيئة حسب التصميم من أجل توفير المزيد من الأمان
  • المزيد من المرونة والاختيار من خلال القدرة على امتلاك أصول تقليدية لدعم أصول التشفير على Blockchain ، وتكامل أبسط بين Layer 2 و Blockchain العامة ، وسهولة توسيع أصول الطبقة 2 إلى أنظمة DeFi الإيكولوجية الحالية على سبيل المثال

في الختام ، من المهم ملاحظة أنه في مثال حكومة الولايات المتحدة ، لا يقتصر الحصول على ATO لنظام المعلومات على القطع الأثرية المشفرة ووحدات التشفير. تمثل هذه جزءًا مهمًا من ضوابط الأمان التي تم تحديدها أثناء عملية إدارة المخاطر اللازمة للحصول على ATO ، كما هو مدرج وموضح بالتفصيل في NIST SP 800-37 Rev 2 و NIST FIPS-199. تتضمن العملية أيضًا عناصر مثل مصادقة / ترخيص المستخدم في ظل سيناريوهات الاستخدام المختلفة ، وضوابط تغيير النظام والعملية ، والتعافي من الكوارث ، واستمرارية الأعمال.

هل توافق ATO / NIST لتطبيقات Blockchain مناسب لعملك؟ تود مجموعة عمل EEA ATO مدخلاتك. الرجاء التواصل .

تابعنا علي  تويتر, لينكدين: و  فيسبوك للبقاء على اطلاع دائم بجميع الأمور في المنطقة الاقتصادية الأوروبية.