يمكن للمتصفح تشغيل تشفير قوي؛ لكن الشيفرة التي تصل إليه يجب أن تظل جديرة بالثقة.
يمكن للمتصفح إجراء التشفير التام بين الطرفين محليًا، بما في ذلك تأسيس المفاتيح لما بعد الكم، دون تثبيت تطبيق مراسلة أصلي. ليس السؤال الصعب هو ما إذا كانت العمليات الرياضية تستطيع العمل داخل علامة تبويب، بل ما إذا كان التطبيق الذي يُسلَّم للمستخدم، وطريقة التعامل مع المفاتيح، ومسار التحديث، جديرة بالثقة التي تتطلبها المحادثة.
قد يكون الوصول عبر الويب مريحًا عندما يتعذر التثبيت. لكنه لا يجعل التطبيق محصنًا من الرقابة، أو اختراق الاستضافة، أو الإضافات الخبيثة، أو اختراق الجهاز.
اللبنات التشفيرية في المتصفح
تتيح WebCrypto عمليات منخفضة المستوى للتشفير واشتقاق المفاتيح والتوقيع وإدارة المفاتيح. توفر التطبيقات الشائعة بدائيات مثل AES-GCM وECDH. هذه العمليات لبنات بناء، وليست بروتوكول مراسلة كاملًا يوفّر المصادقة.
يمكن لتطبيق ويب إضافة تنفيذ خضع للمراجعة لـ ML-KEM باستخدام JavaScript أو WebAssembly عندما لا تتوفر واجهة API الأصلية المطلوبة. يتغير دعم المتصفحات، لذا ينبغي للمطورين اختبار توفر الميزات في الإصدارات المستهدفة بدقة بدل افتراض أن كل المتصفحات تقدم الخوارزميات نفسها.
يبدو التدفق الهجين على المستوى المفاهيمي كما يلي:
- توليد مفاتيح مناسبة باستخدام عشوائية آمنة تشفيريًا.
- التحقق من أصالة مواد مفاتيح الطرف الآخر باستخدام آلية الهوية في البروتوكول.
- الحصول على مساهمات السر المشترك الكلاسيكية وتلك الخاصة بما بعد الكم.
- دمجها باستخدام جدول اشتقاق المفاتيح المحدد وسياق المحادثة.
- استخدام المفاتيح المشتقة للتشفير الموثَّق، مع التعامل الصحيح مع nonce والحالة.
هذا مخطط توضيحي، وليس وصفة تنفيذ. يضع FIPS 203 معيار ML-KEM؛ لكنه لا يمنح اعتمادًا لتطبيق متصفح بعينه ولا يحدد كل خطوة في بروتوكول دردشة.
التسليم عبر HTTPS جزء من نموذج الثقة
يوفر الخادم عادةً شيفرة JavaScript وWebAssembly التي ستعالج النص الصريح. ويمكن لتطبيق عُدّل بصورة خبيثة قراءة رسالة قبل تشفيرها أو بعد فك تشفيرها، حتى لو كانت مكتبته التشفيرية تستخدم خوارزميات سليمة.
يساعد HTTPS على توثيق مصدر التسليم وحمايته من التدخل عبر الشبكة. لكنه لا يثبت أن مشغّل الموقع الأصلي، أو نظام نشره، أو اعتمادياته لم تتعرض للاختراق. وصفحة ويب عادية عبر HTTPS ليست تلقائيًا حزمة تطبيق موقعة بصورة مستقلة.
تناقش الاعتبارات الأمنية لـ WebCrypto لدى W3C حقن السكربتات والحاجة إلى حماية سلامة التطبيق. تقلل سياسة أمن المحتوى، والإدارة الدقيقة للاعتماديات، وغيرها من ضوابط أمن الويب المخاطر، لكن أيًا منها لا يحوّل سكربتًا اعتباطيًا من المصدر نفسه إلى مراقب غير موثوق لا يستطيع لمس بيانات التطبيق.
تشترك WebAssembly أيضًا في الحدود الأمنية للتطبيق. تحد بيئتها المعزولة من الوصول إلى المضيف عبر واجهات محددة؛ لكنها لا تجعل الصفحة التي تستدعيها جديرة بالثقة. وترجمة C إلى Wasm لا تجعل لغة المصدر آمنة من حيث الذاكرة.
المفاتيح لا توجد بالضرورة في RAM فقط
قد يحتفظ تطبيق المراسلة في المتصفح بالمفاتيح أو بالحالة المشفرة بصورة دائمة ليتمكن المستخدم من العودة إلى الهوية نفسها. وقد يقدم أيضًا ربط الأجهزة أو الاستعادة المشفرة. يجب توثيق هذه السلوكيات بدل افتراض عدم وجودها.
من الأسئلة الجديرة بالطرح:
- ما المفاتيح التي تُحفظ بصورة دائمة، وفي أي مخزن داخل المتصفح؟
- ماذا يحدث عند مسح بيانات الموقع أو انتهاء جلسة التصفح الخاص؟
- هل يظل المفتاح غير القابل للاستخراج قابلًا للاستخدام بواسطة شيفرة خبيثة تعمل في سياق التطبيق؟
- هل يستطيع تحديث وصل حديثًا الوصول إلى الحالة المحلية القديمة؟
- هل تعيد الاستعادة الهوية أم سجل الرسائل أم كليهما؟
يقيّد مفتاح WebCrypto غير القابل للاستخراج التصدير عبر واجهة API. لكنه لا يمنع وحده شيفرة التطبيق العدائية من طلب عمليات مسموح بها أو جمع النص الصريح.
لعملاء الويب والعملاء الأصليين مفاضلات مختلفة
| المسألة | عميل المتصفح | العميل الأصلي |
|---|---|---|
| التوزيع | الموقع الأصلي والاستضافة ومسار تحديث الويب | متجر التطبيقات أو مسار توزيع الحزم وتوقيعها |
| الحفظ المحلي الدائم | تخزين المتصفح وسلوك ملفه الشخصي | تخزين التطبيقات في نظام التشغيل ودورة حياة التطبيق |
| سطح التعرض | سكربتات من المصدر نفسه وإضافات وثغرات المتصفح | اعتماديات التطبيق وثغرات نظام التشغيل أو التطبيق |
| الإتاحة | نطاق يمكن الوصول إليه وخدمات الشبكة المطلوبة | يظل التطبيق المثبّت بحاجة إلى خدمات الشبكة المطلوبة له |
لا يثبت أي من العمودين تفوق خيار دون فحص التنفيذ. قد يظل تطبيق الويب متاحًا بعد إزالته من متجر التطبيقات، لكن حجب النطاق أو غياب مسار شبكي قد يمنع الوصول إليه مع ذلك.
قِس الأداء بدل تقديم الوعود
يستخدم ML-KEM-768 مفتاح تغليف بحجم 1,184 بايت ونصًا مشفرًا بحجم 1,088 بايت وفق FIPS 203. تساعد هذه الأحجام على تفسير سبب جدولة البروتوكولات لتحديثات KEM بدل إرفاق مواد جديدة بكل رسالة قصيرة. وليست قياسات لعرض النطاق أو السرعة للتطبيق بأكمله.
يحدد اختبار الأداء المفيد المتصفح والجهاز والبنية البرمجية وطريقة الإحماء والعملية المقاسة وتوزيع الأزمنة. ينبغي تضمين بدء الصفحة وتحميل الوحدات واستخدام الذاكرة والأجهزة محدودة القدرة وأعباء الشبكة الإضافية. وتتطلب ادعاءات مثل «أقل من ملي ثانيتين على جميع الهواتف الحديثة» قياسات منشورة؛ وهذا المقال لا يقدمها.
تطبيق ذلك على Livara
يوثّق عرض الأمان لدى Livara بروتوكول LVR1 وحدود الاستعادة فيه. ويعرض Proof Lab عمليات محلية مختارة من P-256 وHKDF وAES-GCM؛ وتستثني الصفحة صراحةً التركيب الكامل لـ LVR1/LGS1 من نطاق منصة الاختبار تلك. لذلك لا يثبت نجاح العرض أمن جميع شيفرات الويب المنشورة.
قبل إجراء محادثة حساسة في المتصفح، استخدم عميلًا أصيلًا تجري صيانته، وراجع نموذج التهديد الحالي، واحمِ الملف الشخصي للمتصفح، وتحقق من الطرف الآخر عبر عملية فحص المفاتيح المدعومة. يمكن أن تجتمع الراحة والتشفير المفيد، بشرط بقاء حدود التسليم عبر الويب ضمن التقييم.
