Design: توقيع / التحقق من وحدة WASM

أعتقد أننا نحتاج أيضًا إلى المكافئ في تنسيق النص ، ربما شيء مثل: (signature ...) .

بالنسبة لـ CSP ، يمكن أن يكون التحقق من التوقيع قيد التشغيل عبر https؟ أو هل تعتقد أنه يجب تشغيله بشكل افتراضي؟

حسنًا ، "CSP & check": سيكون ذلك مبكرًا جدًا في العملية. سنحتاج إلى مفتاح عام (أو متعدد) للخادم أو أي مثيل آخر للتحقق ، ويجب أن يكون مفتاحًا عامًا باستخدام EC (منحنى مسير الشمس).

إذا كان مرتبطًا بخدمة تستند إلى HTTP (S) ، فسيكون من الضروري الوصول إلى المفتاح العام المقابل (مفتاح المنحنى البيضاوي). ربما يمكن تضمين المفتاح العام المقابل كسمة رأس HTTP لصفحة الويب التي تقوم بتحميل وحدات WASM.

بعد التوقيع على وحدات WASM ، يمكن جلبها من أي مكان والتحقق منها.

هل ستكون هناك منظمة واحدة (مضيف) توقع على ملفات WASM أم ستجلب صفحة ويب وحدات موقعة من عدة منظمات / موردين؟

في حالة وجود عدة مؤسسات ، إما إضافة "معرف المنظمة" إلى التوقيع نفسه ، أو تحديد نوع ما من SignerOrg كقسم إضافي (حجم ثابت أيضًا). قد تبدو العملية على النحو التالي: أولاً إرفاق SignerOrg Seciton ثم توقيع كلاهما (الوحدة النمطية الأصلية - رمز البايت - قسم Signerorg)

يبدو أنه يجب تحديد حالة الاستخدام والعملية أولاً ؛)

أود أن أفهم بشكل أفضل كيف تفشل آليات الويب الحالية للتوقيع والتحقق ، وكيف يمكن لدعم WebAssembly من الدرجة الأولى إصلاح ذلك. على وجه التحديد ، يحتوي الويب على HTTPS و Sub-Resource Integrity والتي ، على الرغم من أنها ليست مثالية بالتأكيد ، إلا أنها تفعل الكثير بالنسبة لنا بالفعل.

هل يمكنك أن تشرح بالتفصيل ما الذي ترغب في إصلاحه ، وكيف أن اقتراحك لا يحتوي على نفس المآزق؟

حسنًا ، يمكنني المحاولة

تُستخدم التواقيع المضمنة بالفعل لملفات PDF ، وثنائيات Win ، وبرامج التشغيل ، ومستندات XML ، وما إلى ذلك.
ما الذي قد تكون وحدات WebAssembly الموقعة مفيدة؟

فقط تخيل

• تطبيق ويب يقوم بتنفيذ كود WebAssembly لحساب البنوك- PIN.
• تطبيقات Rust / C ++ التي تستخدم WebAssembly لمحركات التنفيذ المضمنة ، وتقييم عقود العملة المشفرة
• HSM-s باستخدام WebAssembly bytecode لحساب PINs في الخادم الخلفي
• أجهزة إنترنت الأشياء التي يتم تجميع برامجها الثابتة باستخدام إصدارات محددة من وحدات WebAssembly المختلفة (تخزين / ربط المحتوى القابل للتوجيه)

في الحالة الأخيرة ، سيكون إصدار البرامج الثابتة لأجهزة إنترنت الأشياء عبارة عن قائمة بوحدات WebAssembly التي تستخدم إصدارات محددة. يمكن لأجهزة إنترنت الأشياء أن تنشر نسختها من وحدات WebAssembly إلى الأجهزة الأخرى المجاورة (http://www.korhal.io/whitepaper.pdf). لن تكون هناك حاجة إلى خادم تحديث مركزي.

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

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

لست مقتنعًا بأن هذه مشكلة يتم تناولها بشكل أفضل على مستوى WASM نفسها. يمكن إضافة التوقيعات على أي بيانات. لماذا يجب أن يكونوا جزءًا من اللغة نفسها؟

أيضًا ، يبدو لي أنك قد تكون مهتمًا بمعيار الاستجابات الموقعة من أصل HTTP .

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