رموز التحقق من الرسالة

رموز مصادقة الرسائل

الوصف

MAC (رمز مصادقة الرسالة) هو قدرٌ صغير من المعلومات يمكن استعماله للتحقّق من أصالة الرسالة وسلامتها (authenticity and integrity). وتُسمَّى هذه الرموز غالبًا «وسومًا» (tags). وتُنتج خوارزمية MAC من رسالة ذات طول عشوائي ومفتاح سرّي ذي طول ثابت الوسمَ نفسه. وتأتي خوارزمية MAC مصحوبة بخوارزمية تحقّق تأخذ رسالة ومفتاحًا ووسمًا، وتخبرك ما إذا كان الوسم صالحًا أم لا. (وليس من الضروري دائمًا أن تكفي إعادة حساب الوسم والتحقّق من تطابقه؛ فكثير من خوارزميات MAC الآمنة عشوائية، وتُنتج وسمًا مختلفًا في كلّ مرّة تُطبَّق فيها.)

ولاحظ أنّنا نقول هنا «رسالة» بدلًا من «نصّ صريح» أو «نصّ مشفَّر». وهذا الغموض مقصود. ففي هذا الكتاب يهمّنا في المقام الأول استعمال MAC كوسيلة لتحقيق التشفير المصادَق (authenticated encryption)، لذا ستكون الرسالة دائمًا نصًّا مشفَّرًا. ومع ذلك، لا يوجد ما يمنع تطبيق MAC على رسالة نصّ صريح. بل إنّنا سنرى أمثلة على أنظمة تشفير مصادَق آمنة تسمح صراحةً بإرسال معلومات مصادَق عليها (لكن غير مشفَّرة) إلى جانب النصّ المشفَّر المصادَق عليه.

وكثيرًا ما، إن كان كلّ ما تريده هو الحديث عن أصالة رسالة بعينها وسلامتها، فإنّ من الأنسب عمليًا استعمال خوارزمية توقيع (signature algorithm)، وسنتحدّث عنها في فصل لاحق. أمّا الآن فكلّ ما تحتاج إلى معرفته هو أنّ مصطلح «التوقيع» يبقى عادةً محجوزًا للخوارزميات اللامتماثلة، في حين يتناول هذا الفصل الخوارزميات المتماثلة.

رموز MAC الآمنة

لم نحدّد بعد بدقّة الخصائص التي نريدها من رمز MAC آمن.

وسنصمد في مواجهة مهاجم نشط. وسيُجري المهاجم هجوم رسالة مختارة (chosen message attack). أي أنّ المهاجم سيطلب منّا الوسم الخاصّ بأيّ عدد من الرسائل m_i، وسنجيب بصدق بالوسم المناسب t_i.

ثمّ سيحاول المهاجم أن ينتج تزويرًا وجوديًّا (existential forgery)، وهي طريقة فخمة لقول إنّهم سيُنتج بعض تركيبات (m, t) الجديدة الصالحة. والهدف الواضح للمهاجم هو القدرة على إنتاج وسوم صالحة t^{\prime} لرسائل جديدة m^{\prime} يختارها هو. وسنعدّ MAC غير آمن أيضًا إذا تمكّن المهاجم من حساب وسم جديد مختلف وصالح t^{\prime} لرسالة m_i سبق أن أعطيناه وسمًا صالحًا لها.

لماذا يأخذ MAC مفتاحًا سرّيًا؟

إن كنت قد تعاملت من قبل مع التحقّق من سلامة رسالة، فقد استعملت على الأرجح مجاميع اختبار (checksums) مثل CRC32 أو Adler32، أو حتى تجزئات تشفيرية (مثل عائلة SHA)، لحساب مجموع اختبار للرسالة (قد يسمّيونه، بحسب الخوارزمية ومَن تُخاطبه، «تجزئة» أو «digest» أيضًا).

ولنفترض أنّك توزّع حزمة برمجية. فلدينا بعض ملفات tarball التي تحوي شيفرة مصدرية، وربّما بعض الحزم الثنائية لأنظمة التشغيل الشائعة. ثمّ تضع بعض التجزئات (الآمنة تشفيريًا!) بجوارها مباشرةً، بحيث يستطيع أيّ شخص ينزّلها التحقّق من التجزئات والطمأنينة إلى أنّه نزّل ما ظنّ أنّه نزّله.

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

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

دمج MAC مع الرسالة

وكما ذكرنا من قبل، التشفير غير المصادَق أمر سيّئ. ولهذا قدّمنا رموز MAC. وبالطبع، كي يكون MAC نافعًا، لا بدّ أن يصل إلى المستقبِل. وبما أنّنا نتحدّث الآن صراحةً عن مصادقة التشفير، فلنتوقّف عن استعمال كلمة «رسالة» ونستعمل بدلًا منها «نصّ صريح» و«نصّ مشفَّر» الأقلّ التباسًا.

وهناك ثلاث طرق شائعة لدمج نصّ مشفَّر مع MAC.

#. صادِق وشفِّر معًا. تصادق على النصّ الصريح وتشفّره كلٌّ على حدة. وهكذا يفعل SSH. بالرموز: C = E(K_C, P)، وt = MAC(K_M, P)، وترسل النصّ المشفَّر C والوسم t معًا. #. صادِق ثمّ شفِّر. تصادق على النصّ الصريح ثمّ تشفّر تركيبة النصّ الصريح ووسم المصادقة. وهكذا تفعل TLS عادةً. بالرموز: t = MAC(K_M, P)، وC = E(K_C, P \| t)، ولا ترسل إلّا C. (لا تحتاج إلى إرسال t، لأنّه جزء مشفَّر أصلًا ضمن C.) #. شفِّر ثمّ صادِق. تشفّر النصّ الصريح وتحسب MAC لذلك النصّ المشفَّر. وهكذا يفعل IPSec. بالرموز: C = E(K_C, P)، وt = MAC(K_M, C)، وترسل C وt معًا.

وقد دُرست جميع هذه الخيارات وقُورنت على نطاق واسع. krawczyk:order bellare:maccomposition والآن نعرف أنّ «شفِّر ثمّ صادِق» هو الخيار الأفضل على نحو قاطع من بينها. وهو أفضل خيار إلى حدٍّ لافت، لدرجة أنّ Moxie Marlinspike، باحث أمن معلومات محترم، يضع مبدأًيسمّيه «مبدأ الفناء التشفيري» (The Cryptographic Doom Principle) لأيّ نظام لا يتبع هذا النمط moxie:doom. ويؤكّد Moxie أنّ أيّ نظام يفعل أيّ شيء قبل التحقّق من MAC محكوم بالفناء. فكلا النمطين «صادِق وشفِّر معًا» و«صادِق ثمّ شفِّر» يفرضان عليك فكّ تشفير شيء ما قبل أن تتمكّن من التحقّق من المصادقة.

صادِق ثمّ شفِّر

«صادِق ثمّ شفِّر» خيار رديء، لكنّه خيار رديء خفيّ. فقد يظلّ قابلًا للإثبات أنه آمن، وإنّما فقط في ظروف معيّنة. krawczyk:order

للوهلة الأولى، يبدو أنّ هذا النظام يعمل. صحيح أنّ عليك فكّ التشفير قبل أن تفعل أيّ شيء، لكنّ ذلك لم يبدُ لكثير من خَبَراء التشفير، بمن فيهم مصمّمو TLS، مشكلة كبيرة.

وفعلًا، قبل الدراسة المقارنة الدقيقة لآليات التركيب المختلفة، فضّل كثيرون هذا التصميم. ففي نقدٍ لـ IPSec، رأى Schneier وFerguson، وهما خَبَراء تشفير مخضرمان، أنّ استعمال IPSec لِ«شفِّر ثمّ صادِق» خللًا، وفضّلا «صادِق ثمّ شفِّر» الخاصّ بـ TLS. schneier:ipsec وقد يكون لهما في ذلك حجّة تبدو معقولة آنذاك، لكنّ هذا النقد صار متجاوزًا تمامًا بفضل أمن «شفِّر ثمّ صادِق» القابل للإثبات. krawczyk:order bellare:maccomposition

TODO: اشرح هجوم Vaudenay على حشو CBC vaudenay:cbcpadding

صادِق وشفِّر معًا

«صادِق وشفِّر معًا» له مشكلات خطيرة. فبما أنّ الوسم مصادِق على النصّ الصريح وأنّ ذلك الوسم جزء من الرسالة المُرسَلة، فسيتمكّن المهاجم من تمييز أنّ رسالتين نصّيين صريحتين متطابقتين، لأنّ وسمَيهما سيكونان متطابقين أيضًا. وهذا يؤدّي في الجوهر إلى المشكلة نفسها التي رأيناها في وضع ECB، حيث يستطيع المهاجم تمييز كتل متطابقة. وهذه مشكلة خطيرة، حتى وإن لم يستطع فكّ تشفير تلك الكتل.

TODO: اشرح كيف يعمل هذا في SSH (انظر مقالة Moxie في الفناء)

محاولة ساذجة بدوالّ التجزئة

تتضمّن طرق بناء MAC كثيرة دوالّ التجزئة. وأبسط ما يمكن تخيّله على الأرجح هو وضع المفتاح السرّي في مقدّمة الرسالة ثمّ تجزئة الكلّ:

t = H(k \| m)

وتُسمَّى هذه المنظومة عادةً «بادئة-MAC» (Prefix-MAC)، لأنّها خوارزمية MAC تعمل باستعمال المفتاح السرّي بادئةً.

وتضمن دالة التجزئة الآمنة تشفيريًا H بضعة أمور مهمّة لنا هنا:

• يكون الوسم t سهل الحساب؛ فدالة التجزئة H نفسها سريعة عادةً إلى حدٍّ كبير. وفي حالات كثيرة نستطيع حساب الجزء المشترك من المفتاح مسبقًا، فلا نضطر إلّا إلى تجزئة الرسالة نفسها.
• معطاة أيّ عدد من الوسوم، لا يستطيع المهاجم «عكس» دالة التجزئة لاستعادة k، وهو ما كان سيمكّنه من تزوير رسائل اعتباطية.
• معطاة أيّ عدد من الوسوم، لا يستطيع المهاجم «إرجاع» دالة التجزئة إلى الوراء لاستعادة H(k)، وهو ما كان قد يسمح له بتزوير رسائل شبه اعتباطية.

وهناك تحفّظ صغير: فنحن نفترض أنّ المفتاح السرّي k ذا إنتروبيا كافية. وإلّا واجهنا المشكلة نفسها التي واجهناها مع تخزين كلمات المرور باستعمال دوالّ التجزئة: فيستطيع المهاجم ببساطة أن يجرّب كلّ قيمة لـk حتى يطابق إحداها. وحين يفعل ذلك، يكون قد عثر على k الصحيح على الأرجح. لكنّ هذا ليس فشلًا في MAC بالمعنى الدقيق: فإذا كان مفتاحك السرّي ذا إنتروبيا قليلة إلى حدٍّ يجعل تجريبها جميعًا ممكنًا للمهاجم، فقد خسرتَ الأمر سلفًا، مهما اخترتَ من خوارزميات MAC.

كسر بادئة-MAC

وبالرغم من شيوعها إلى حدٍّ كبير، فإنّ هذه الخوارزمية غير آمنة فعليًا لأغلب دوالّ التجزئة H (الآمنة تشفيريًا!)، ومنها SHA-2.

وكما رأينا في فصل دوالّ التجزئة، فإنّ كثيرًا من دوالّ التجزئة، مثل MD5 وSHA-0 وSHA-1 وSHA-2، تحشو الرسالة بحشو يمكن التنبّؤ به قبل إنتاج التجزئة الخارجة. وتُعدّ التجزئة الخارجة الشيء نفسه كالحالة الداخلية لدالة التجزئة. وهذه مشكلة: فباستطاع المهاجم استعمال هذه الخصائص لتزوير الرسائل.

أوّلًا، يستعمل المهاجم التجزئة بوصفها الحالة الداخلية لدالة التجزئة. وتقابل تلك الحالة الحالة التي تحصل عليها حين تجزّئ k \| m \| p، حيث k هو المفتاح السرّي، وm هي الرسالة، وp هو ذلك الحشو القابل للتنبّؤ به. الآن يجعل المهاجم دالة التجزئة تستهلك بعض البايتات الجديدة: وهي رسالته المختارة m^{\prime}. وأصبحت الحالة الداخلية لدالة التجزئة الآن هي ما تحصل عليه حين تغذيها بـk \| m \| p \| m^{\prime}. ثمّ يطلب المهاجم من دالة التجزئة أن تنتج تجزئة. ومرةً أخرى تلحق دالة التجزئة حشوًا، فصرنا الآن عند k \| m \| p \| m^{\prime} \| p^{\prime}. ويخرج المهاجم تلك التجزئة بوصفها الوسم. وهذا هو بالضبط الشيء نفسه الذي يحدث عند حساب وسم الرسالة m \| p \| m^{\prime} تحت المفتاح السرّي k. إذن، نجح المهاجم في تزوير وسم لرسالة جديدة، ووقفًا لتعريفنا، فإنّ MAC غير آمن.

ويُسمَّى هذا الهجوم هجوم تمديد الطول، لأنّك تمدّ رسالة صالحة. أما الحشو p الواقع في الوسط، الذي بدأ كحشو للرسالة الأصلية ثمّ صار مجرّد بيانات في وسط، فيُسمّى حشو اللصق (glue padding)، لأنّه يلصق الرسالة الأصلية m برسالة المهاجم m^{\prime} معًا.

قد يبدو هذا الهجوم مسألة أكاديمية إلى حدٍّ كبير، وبعيدًا كلّ البعد عن مشكلة عملية. قد نكون برهنا على أنّ MAC غير آمن وفق تعريفنا، لكنّ الوسوم الوحيدة التي يستطيع المهاجم تزويرها بنجاح هي وسوم لتعديلات محدودة جدًا على رسائل حقيقية. وتحديدًا، لا يستطيع المهاجم إلّا تزوير وسوم لرسالة تتكوّن من رسالة أرسلناها، يليها بعض البيانات الثنائية العشوائية، يليها ما يختاره المهاجم. لكنّه يتبيّن أنّ هذا يكفي في أنظمة كثيرة لإحداث كسور حقيقية. خُذ شيفرة بايثون التالية التي تحلّل تسلسل أزواج من نوع k1=v1&k2=v2&...:

أدرك أنّ هناك طرقًا أقصر لكتابة تلك الدالة. وأنا أحاول أن أجعلها مفهومة لمعظم المبرمجين، لا ممتعة لِخبراء بايثون.

def parse(s):
    pairs = s.split("&")
    parsed = {}
    for pair in pairs:
        key, value = pair.split("=")
        parsed[key] = value
    return parsed

ولا تتذكّر دالة التحليل إلّا آخر قيمة لمفتاح معيّن: فالقيم السابقة في القاموس تُستبدَل. ونتيجةً لذلك، يستطيع المهاجم الذي ينفّذ هجوم تمديد الطول أن يسيطر فعليًا على القاموس المحلَّل بالكامل.

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

وتركيب بادئة-MAC آمن فعليًا مع كثير من دوالّ التجزئة الحالية (في عصر SHA-3)، مثل Keccak وBLAKE(2). بل إنّ مواصفات دوالّ التجزئة هذه توصي به بوصفه MAC آمنًا وسريعًا. فهي تستعمل تقنيات متنوّعة لصدّ هجمات تمديد الطول: فمثلًا، يتتبّع BLAKE عدد البتّات التي جُزّئت حتى الآن، بينما لدى BLAKE2 علم (flag) يُشير إلى كتلة معيّنة بوصفها الأخيرة.

التنويعات

مشاكل بادئة-MAC دفعت الناس إلى ابتكار تنويعات ذكية من كلّ نوع. فمثلًا، لماذا لا نضيف المفتاح إلى النهاية بدلًا من البداية (t = H(m \| k)، أو «MAC اللاحقة» (suffix-MAC) إن شئت)؟ أو ربّما ينبغي ألّا نلحق المفتاح بالطرفين احتياطًا (t = H(k \| m \| k)، وربّما «MAC شطيرة» (sandwich-MAC)؟

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

وقد أنتج التشفير رموز MAC أقوى بكثير، وسنراها في الأقسام القليلة التالية. ولا توجد أسباب جيّدة للامتناع عن استعمالها.

HMAC

HMAC هو معيار لإنتاج MAC باستخدام دالة تجزئة تشفيرية كمعامل. وأُدخل في سنة 1996 في بحث قدّمه Bellare وCanetti وKrawczyk. وقد نفّذت كثير من البروتوكولات في ذلك الوقت محاولات خاصةّ بها لمصادقة الرسائل باستعمال دوالّ التجزئة. وقد أخفقت معظم تلك المحاولات. وكان هدف ذلك البحث تحديدًا هو إنتاج MAC يمكن إثبات أمنه، ولا يتطلّب شيئًا يتجاوز مفتاحًا سرّيًا ودالة تجزئة.

ومن مزايا HMAC الجيّدة أنّ له برهان أمن إلى حدٍّ ما قويًّا. فطالما كانت دالة التجزئة الأساسية دالة شبه عشوائية (pseudorandom function)، فإنّ HMAC نفسه دالة شبه عشوائية أيضًا. ولا يلزم حتى أن تكون دالة التجزئة الأساسية مقاومة للتصادم ليكون HMAC MAC آمنًا. hmac:proof2 وقد أُدخل هذا البرهان بعد HMAC نفسه، وطابق ما لوحظ في الواقع: فبرغم أنّ MD5، وإلى حدٍّ أقلّ SHA-0، تعرّضا لهجمات تصادم خطيرة، بدت تركيبات HMAC المبنية على تلك الدوالّ آمنة تمامًا.

وأكبر فرق بين HMAC وبين بادئة-MAC أو تنويعاتها هو أنّ الرسالة تمرّ عبر دالة التجزئة مرّتين، وتُدمج مع المفتاح قبل كلّ مرّة. وعلى نحو بصريّ يبدو HMAC هكذا:

ولعلّ الشيء المفاجئ الوحيد هنا هما الثابتان p_{inner} (الحشو الداخلي، أي مقدار طول كتلة واحدة من دالة التجزئة من بايتات 0x36) وp_{outer} (الحشو الخارجي، أي مقدار طول كتلة واحدة من بايتات 0x5c). وهذان ضروريّان ليعمل برهان أمن HMAC؛ أمّا قيمتاهما بعينهما فليستا مهمّتين كثيرًا، ما دام الثابتان مختلفَين.

ويُجرى XOR للوسادتَين مع المفتاح قبل استعمالهما. وتُضاف النتيجة إمّا إلى مقدّمة الرسالة الأصلية (للحشو الداخلي p_{inner}) أو إلى التجزئة الوسيطة (للحشو الخارجي p_{outer}). ولأنّهما تُضافان في المقدّمة، يمكن حساب الحالة الداخلية لدالة التجزئة بعد معالجة المقدّمتين مسبقًا، ممّا يوفّر بضع دورات من زمن حساب MAC.

رموز MAC ذات الاستعمال الواحد

حتى الآن، افترضنا دائمًا أنّ دوالّ MAC يمكن استعمالها بمفتاح واحد لإنتاج رموز MAC آمنة لعدد كبير جدًّا من الرسائل. وفي المقابل، فإنّ رموز MAC ذات الاستعمال الواحد (one-time MACs) هي دوالّ MAC لا يمكن استعمالها بأمان إلّا مرّة واحدة بمفتاح واحد. وقد يبدو ذلك فكرة سخيفة، بما أنّنا تحدّثنا من قبل عن رموز MAC الآمنة الاعتيادية. إذ يبدو أنّ خوارزمية لا تعمل إلّا مرّة واحدة موضوعًا للشفقة على أيّ حال. لكنّ لها عدّة مزايا كبيرة:

• يمكن تقييمها بسرعة مذهلة، حتى للرسائل الضخمة جدًّا.
• لها برهان أمن مقنع يعتمد على المعلومات التي يحملها الوسم.
• ثمّة تركيبة تحوّل رمز MAC ذي الاستعمال الواحد إلى MAC آمن متعدّد الاستعمالات، ممّا يزيل المشكلة الرئيسة. ومن الأمثلة النموذجية البسيطة على هذه الرموز (one-time MACs) يتكوّن من عملية ضرب وجمع بسيطَين ناطقين على عدد أوّلي (prime) كبير p. وفي هذه الحالة، يتكوّن المفتاح السرّي من عددين عشوائيين حقًّا هما a وb، كلاهما بين 1 وp:

$$t \equiv m \cdot a + b \pmod p$$

ولا يعمل هذا المثال البسيط إلّا على رسائل من كتلة واحدة m، وعلى عدد أوّلي p أكبر قليلًا من أكبر m. ويمكن تمديده لدعم رسائل M أكبر مكوّنة من كتل m_i باستعمال متعدّد حدود (polynomial) خاصّ بالرسالة اسمه P:

$$t \equiv \underbrace{(m_n \cdot a^n + \cdots + m_1 \cdot a)}_{P(M, a)} + b \pmod p$$

قد يبدو هذا قدرًا كبيرًا من الحساب، لكنّ هذا المتعدّد يمكن تقييمه بكفاءة بأن تُخرِج العامل المشترك a تكراريًّا (وتُسمّى هذه الطريقة أيضًا قاعدة هورنر (Horner's rule)):

$$P(M, a) \equiv a \cdot (a \cdot (a \cdot (\cdots) + m_2) + m_1) + b \pmod p$$

وبحساب كلّ عملية ضرب ناطقًا على p، تبقى الأرقام صغيرة بما يريح.

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

ومثل وسادة المرّة الواحدة تمامًا، تعتمد حجّة الأمن على خاصيتين مهمّتين جدًّا في المفتاحَين a, b:

• لا بدّ أن يكونا عشوائيَّين حقًّا.
• لا بدّ أن يُستعمل كلٌّ منهما مرّة واحدة على الأكثر.

إعادة استعمال a وb

إعادة استعمال :math:a و:math:b

وسنبيّن أنّ مثال MAC الذي عندنا غير آمن إذا استُعمل لمصادقة رسالتين m_1, m_2 بالمفتاح نفسه (a, b):

$$\begin{aligned} t_1 &\equiv m_1 \cdot a + b \pmod p \\ t_2 &\equiv m_2 \cdot a + b \pmod p \end{aligned}$$

ويمكن للمهاجم إعادة بناء a, b بعمليات حساب نمطيّة بسيطة:

ولمزيد من التذكير بالحساب النمطي، بما في ذلك شرح المقلوب النمطي، راجع الملحق <modular-arithmetic>. $$\begin{aligned} t_1 - t_2 &\equiv (m_1 \cdot a + b) - (m_2 \cdot a + b) \pmod p \\ &\Downarrow \text{(remove parentheses)} \\ t_1 - t_2 &\equiv m_1 \cdot a + b - m_2 \cdot a - b \pmod p \\ &\Downarrow \text{($b$ and $-b$ cancel out)} \\ t_1 - t_2 &\equiv m_1 \cdot a - m_2 \cdot a \pmod p \\ &\Downarrow \text{(factor out $a$)} \\ t_1 - t_2 &\equiv a \cdot (m_1 - m_2) \pmod p \\ &\Downarrow \text{(flip sides, multiply by inverse of $(m\_1 - m\_2)$)} \\ a &\equiv (t_1 - t_2)(m_1 - m_2)^{-1} \pmod p \end{aligned}$$

وبإدخال a في معادلة t_1 أو t_2 نحصل على b:

$$\begin{aligned} t_1 &\equiv m_1 \cdot a + b \pmod p \\ &\Downarrow \text{(reorder terms)}\\ b &\equiv t_1 - m_1 \cdot a \pmod p \end{aligned}$$

وكما ترى، فإنّ إعادة استعمال المفتاح مرّة واحدة فقط — كما في وسادات المرّة الواحدة — تسبّب فشلًا تامًّا للنظام التشفيري في حفظ الخصوصية أو السلامة، أيًّا منهما كان موضوع البحث. ونتيجةً لذلك، فإنّ رموز MAC ذات الاستعمال الواحد (one-time MACs) خطيرة قليلًا عند استعمالها مباشرةً. ولحسن الحظّ، يمكن معالجة هذا الضعف بتركيبة تُسمّى Carter-Wegman MAC، وسنراها في القسم التالي.

Carter-Wegman MAC

وكما سبق أن قلنا، فالمشكلة الواضحة في رموز MAC ذات الاستعمال الواحد (one-time MACs) هي عمليّتها المحدودة. ولحسن الحظّ، يتبيّن أنّ ثمّة تركيبة تُسمّى Carter-Wegman MAC تحوّل أيّ رمز MAC آمن ذي استعمال واحد إلى MAC آمن متعدّد الاستعمالات، مع الحفاظ على معظم فائدة الأداء.

والفكرة وراء Carter-Wegman MAC هي أنّك تستطيع استعمال رمز MAC ذي الاستعمال الواحد (one-time MAC) O لإنتاج وسمٍ لجزء البيانات الأكبر، ثمّ تشفير رقم فريد (nonce) n باستعمال دالة شبه عشوائية F، مثل شيفرة كتلة، لحماية ذلك الوسم أحادي الاستعمال:

CW((k_1, k_2), n, M) = F(k_1, n) \xor O(k_2, M)

ما دامت F دالة شبه عشوائية آمنة، فإنّ تشفير الرقم الفريد (nonce) غير متوقّع على الإطلاق. وبعيون المهاجم، هذا يعني أنّ عملية XOR ستقلب بشكل عشوائي بتّات وسم الرمز MAC ذي الاستعمال الواحد (one-time MAC) وهو O(k_2, M). ولأنّ هذا يغطّي القيمة الحقيقية لوسم الرمز MAC ذي الاستعمال الواحد، لا يستطيع المهاجم تنفيذ الحيل الجبرية التي رأيناها مع الرموز ذات الاستعمال الواحد (one-time MACs) لاستعادة المفتاح عند استعماله أكثر من مرّة.

وتذكّر أنّ رموز Carter-Wegman MAC (Carter-Wegman MACs) تأخذ مفتاحَين مختلفَين k_1 وk_2، وأنّ رموز Carter-Wegman MAC (Carter-Wegman MACs) متّصلة بـالرموز ذات الاستعمال الواحد (one-time MACs)، بعضها يأخذ أيضًا مفتاحَين مختلفَين هما a وb، لكنّهما ليسا المفتاحَين نفسيهما. فـk_2 في Carter-Wegman MAC هو المفتاح الوحيد الذي يُمرَّر إلى الرمز MAC ذي الاستعمال الواحد (one-time MAC) السريع O. فإذا كان ذلك الرمز أحادي الاستعمال السريع هو مثالنا السابق الذي يأخذ مفتاحَين a وb، لكان على k_2 أن يتفرّع إلى هذين المفتاحَين. ويصبح عندئذٍ مفتاح Carter-Wegman MAC هو (k_1, k_2) = (k_1, (a, b)).

ويمكنك أن ترى كيف تستغلّ Carter-Wegman MAC (Carter-Wegman MAC) مزايا كلا نوعَي رموز MAC بالنظر إلى حدَّي المعادلة كلٌّ على حدة. في F(k_1, n)، تكون F مجرّد دالة شبه عشوائية اعتيادية، مثل شيفرة كتلة. وهي بطيئة إلى حدٍّ كبير مقارنةً بالرمز MAC أحادي الاستعمال. لكنّ دخلها، وهو الرقم الفريد (nonce)، صغير جدًّا. والخرج غير المتوقّع لشيفرة الكتل يغطّي خرج الرمز MAC أحادي الاستعمال. أمّا في الحدّ الثاني O(k_2, M)، فلا يتعامل الرمز MAC سريع الاستعمال الوحيد (one-time MAC) O السريع جدًّا إلّا مع رسالة الدخل الكبيرة M.

وهذه التركيبات، ومنها بصفة خاصة Poly1305-AES، تمثّل اليوم بعض أفضل ما توصّل إليه دوالّ MAC. وقد يكون البحث (umac) وتقرير RFC (rfc4418) الخاصّ بدالة MAC أقدم ذات صلة (UMAC) مصدرين جيّدين لمعلومات إضافية، إذ يتعمّقان في كيفية تطبيق Carter-Wegman MAC (Carter-Wegman MAC) العملي ولماذا.

أوضاع التشفير المصادَق

حتى الآن، كنّا نفصل دائمًا بين التشفير والمصادقة، ونشرح الحاجة إلى كليهما. ومعظم الاتصالات الآمنة التي تُنشأ كلّ يوم تفصل بينهما أيضًا: فهي تعامل التشفير والمصادقة على أنّهما خطوتان مختلفتان جوهريًّا.

وبدلًا من ذلك، يمكننا جعل المصادقة جزءًا جوهريًّا من وضع التشغيل (mode of operation). فبعد كلّ شيء، رأينا من قبل أنّ التشفير غير المصادَق لا يكاد يكون ما تريده أبدًا؛ فهو في أفضل الأحوال شيء تضطرّ أحيانًا إلى تحمّله. ومن المنطقي استعمال تركيبات لا تضمن خصوصية تدفّق اعتباطي فحسب، بل سلامته أيضًا.

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

AEAD

AEAD ميزة في بعض أوضاع التشفير المصادَق. وتُسمَّى أوضاع التشغيل هذه أوضاع AEAD (AEAD modes). وتبدأ من افتراض أنّ كثيرًا من الرسائل تتكوّن في الحقيقة من جزأين:

• المحتوى الفعليّ نفسه
• بيانات وصفية (metadata): بيانات عن المحتوى

وفي كثير من الحالات ينبغي أن تكون البيانات الوصفية نصًّا صريحًا، في حين ينبغي أن يكون المحتوى نفسه مشفَّرًا. وينبغي أن تكون الرسالة كاملة مصادَقًا عليها: فلا ينبغي أن يستطيع المهاجم العبث بالبيانات الوصفية وتبقى الرسالة الناتجة مقبولة.

ولنتّخذ بديلًا للبريد الإلكترونيّ مثالًا لنظام تشفير. فقد تحوي البيانات الوصفية عن المحتوى على المستقبِل المقصود. ونريد بالتأكيد تشفير المحتوى نفسه ومصادقته، بحيث لا يقرأه إلّا ذلك المستقبِل. أما البيانات الوصفية فينبغي أن تكون نصًّا صريحًا: إذ يجب أن تعرف خوادم البريد الإلكترونيّة المنفّذة لتسليم الرسالة أيّ مستقبِل تُرسَل إليها.

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

وتعالج أوضاع AEAD (AEAD modes) هذه المشكلة بتوفير طريقة محدّدة لإضافة البيانات الوصفية إلى المحتوى المشفَّر، بحيث تُصادق على المحتوى المشفَّر مع البيانات الوصفية معًا، لا على القطعتين كلٌّ على حدة:

وضع OCB

متقدّم

وعادةً ما سترغب في استعمال نظام تشفير أعلى مستوى بكثير، مثل OpenPGP أو NaCl أو TLS.

وضع OCB (OCB mode) هو وضع AEAD (AEAD mode) من أوضاع التشغيل. وهو إحدى أقدم أوضاع AEAD (AEAD modes) التي تطوّرت.

وكما ترى، يبدو معظم هذا النظام مشابهًا إلى حدٍّ كبير لـوضع ECB (ECB mode). واسم OCB مشابه أيضًا لـ«الكتاب الإلكتروني الشيفري» (electronic codebook). لكنّ OCB لا يشترك في مشكلات الأمان التي يملكها وضع ECB، إذ توجد فروق مهمّة عدّة، مثل الإزاحات \Delta_i المقدَّمة في كلّ عملية تشفير كتلة على حدة.

وبكونه وضع AEAD (AEAD mode)، يوفّر وضع OCB (OCB mode) وسم مصادقة آمنًا تشفيريًا هو t، الذي يُبنى من X، وهي مجمّع اختباري (checksum) بسيط جدًّا (غير آمن تشفيريًا بذاته) للنصّ الصريح. وهناك أيضًا وسم منفصل آخر هو t_a، الذي يصادق على بيانات AEAD الوصفية. ويُحسب وسم البيانات الوصفية t_a على النحو التالي:

ولهذا التصميم عدد من الخصائص المثيرة. فمثلًا، هو سريع جدًّا: إذ لا يحتاج إلّا نحو عملية واحدة لشيفرة الكتل لكلّ كتلة مشفَّرة أو كتلة بيانات وصفية، إضافةً إلى عملية واحدة إضافية لشيفرة الكتل للوسم النهائي. كما أنّ الإزاحات (\Delta_i) سهلة الحساب إلى حدٍّ متطرّف. وكتلة المجمّع X هي مجرّد كلّ كتل النصّ الصريح P_i مجمّعة معًا باستخدام XOR. وأخيرًا، يُعدّ وضع OCB (OCB mode) سهل الحساب على التوازي؛ إذ لا يعتمد سوى وسم المصادقة النهائي على كلّ المعلومات السابقة.

ويأتي وضع OCB (OCB mode) أيضًا بمخطّط حشو مدمج: إذ يتصرّف بطريقة تختلف قليلًا عندما لا يكون النصّ الصريح أو نصّ المصادقة مضاعفات دقيقة لحجم الكتلة. وهذا يعني أنّه، بخلاف حشو PKCS#5/PKCS#7، لا توجد كتلة كاملة «مهدورة» من الحشو إذا وقع النصّ الصريح من مضاعفات حجم الكتلة.

ورغم امتلاك وضع OCB (OCB mode) عدة خصائص مثيرة في صالحه، فإنّه لم يحظَ بنفس القدر من الاهتمام الذي حظيت به بعض البدائل؛ ومن الأسباب الرئيسة أنّه مشمول ببراءة. وبرغم توفّر عدد من تراخيص براءات الاختراع، بما فيها رخصة مجانية لبرمجيات المصادر المفتوحة، فإنّ ذلك لا يبدو أنّه أثّر كثيرًا في مقدار استعمال وضع OCB (OCB mode) في الميدان. ocb:license

وضع GCM

متقدّم

وعادةً ما سترغب في استعمال نظام تشفير أعلى مستوى بكثير، مثل OpenPGP أو NaCl أو TLS.

ويُعدّ وضع GCM (GCM mode) وضع AEAD (AEAD mode) يقع في متلازمة المختصر المتكرّر (RAS، أي redundant acronym syndrome): فـGCM نفسها اختصار لعبارة «وضع العدّاد الغالاوي» (Galois Counter Mode). وقد صُيغ في منشور خاصّ من NIST gcm، ويكاد ينحصر في مزيج من وضع CTR الكلاسيكي مع Carter-Wegman MAC. ويمكن استعمال ذلك MAC وحده أيضًا، وهو ما يُسمّى GMAC.

المصادقة

وضع GCM (GCM mode) (ومنه بالتالي GMAC)