الخلاصة

  • Base64 في MIME تمثيل قابل للعكس يهيئ جسم الرسالة للنقل؛ ولا يضيف سرية أو سلامة أو أصالة أو تفويضاً أو أماناً للتنفيذ.
  • يتطلب إيصال فك الترميز حفظ المدخل المشفر ونطاق كيان MIME والملف القاعدي وسياسة المفك وبصمة البايتات الناتجة ونتائج الأمن المستقلة.

وصل إلى فريق الاستجابة سجل يحتوي على رمز وصول مكتوباً كسلسلة طويلة من Base64. وصفه التقرير بأنه «مشفّر» لأنه لم يكن مقروءاً مباشرة. لكن أداة عامة أعادت الرمز خلال لحظة. لم يحدث كسر لتشفير؛ فقد نفذ المستجيب العملية العكسية التي صُممت الصيغة كي ينفذها أي مستقبل.

هذه الحدود جزء من قصة MIME نفسها. تسجل صفحة Nathaniel Borenstein لدى IETF خمس عشرة RFC، منها RFC 2045 وRFC 2046 وRFC 2049. وتروي صفحة Grinnell College المنشورة عام 2013 عمله على MIME في Bellcore، وتذكر أول رسالة MIME عام 1992 بما حملته من صورة وملف صوتي. كان الإنجاز جعل أنواع مختلفة من البيانات تعبر أنظمة بريد مقيدة من دون أن تتلف، لا منع غير المصرح لهم من قراءتها.

ما الذي يثبته حقل النقل؟

تعرّف RFC 2045 حقل Content-Transfer-Encoding بأنه يحدد التحويل المطبق على جسم الرسالة ومجال التمثيل الناتج. القيم 7bit و8bit وbinary لا تجري تحويلاً؛ أما quoted-printable وBase64 فتنقل المدخل إلى تمثيل ملائم لقناة مقيدة بسبع بتات.

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

وبذلك يثبت النجاح عبارة ضيقة: قبل هذا المفك هذا التمثيل، وفق هذه القواعد، وأنتج هذه البايتات. لا يثبت من أنشأها أو ما إذا كانت عُدلت قبل الترميز أو من يحق له قراءتها أو ما إذا كان تشغيلها آمناً.

الكيان المرئي ليس حدود الدليل

يعرض برنامج البريد مرفقاً واحداً، بينما تتكون MIME من كيانات متداخلة. حقل الترميز في رأس الرسالة يسري على جسمها؛ وإذا كان داخل كيان فإنه يسري على جسم ذلك الكيان وحده. وللأنواع المركبة مثل multipart وmessage قيود إضافية. فقدان هذه الحدود يجعل إعادة المعالجة لاحقاً غير قابلة للإثبات.

يمكن أن يملك التحقيق ثلاث بصمات مختلفة: الرسالة الخام، والجزء المكتوب بـBase64، والبايتات بعد الفك. قد تغير بوابة البريد التفاف السطور من دون تغيير الناتج. وقد تحمل رسالتان من مصدرين مختلفين بايتات متطابقة. حفظ الناتج وحده يمحو المصدر؛ ومقارنة النص وحده قد تخترع اختلافاً لا يوجد في المحتوى.

نوع الوسائط قرار آخر. توصي RFC 2046 بالتعامل المحافظ مع application/octet-stream: إزالة ترميز النقل ثم عرض حفظ البيانات، أو تمريرها إلى عملية يختارها المستخدم. فك الترميز ليس إذناً بالتنفيذ. اسم الملف وContent-Type مؤشرات للمعالجة وليسا إثباتاً تشفيرياً للهوية.

لا توجد صيغة Base64 واحدة بلا سياق

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

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

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

الإخفاء البصري ليس حماية حسابية

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

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

لا يعني ذلك أن Base64 فشل كأداة أمنية؛ فهو لم يكن أداة أمنية أصلاً. يبدأ الفشل عندما يعيد نموذج البيانات تسمية decoded إلى encrypted أو verified أو safe.

إيصال من ست طبقات

يحفظ الحقل الأول بصمة المدخل وحدود كيان MIME. ويسمي الثاني الملف المطبق: MIME Base64 أو base64url أو غيره. ويسجل الثالث إصدار المفك وسياسة الفراغ والمحارف والحشو. ويثبت الرابع النجاح أو الرفض وبصمة البايتات. ويطبق الخامس سياسة نوع الوسائط والتعامل الآمن بلا تشغيل تلقائي. ويربط السادس التوقيع والتشفير ومصادقة النقل والتفويض كلٌ في خانته.

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

نجح MIME الذي ساهم Borenstein في بنائه لأنه فصل وظائف تحتاج إلى التعاون من دون خلط سلطاتها. وينبغي أن يظل Base64 كذلك: إثباتاً على تمثيل قابل للعكس، لا بديلاً عن دليل الثقة.